Кодирование видео

[Daniel5555]

Вчера у нас в чате была интересная беседа на тему кодирования видео. Думаю, что эта тема интересна очень многим, поэтому я решил не откладывать это дело в долгий ящик и открыть тему об этом.

Здесь я расскажу немного о том, что я знаю о кодировании видео и какие практические советы из этого можно извлечь, в целом этот пост будет краткой технической запиской.

Для начала поговорим о том, по какой причине я заинтересовался этой темой, то есть какой у меня бэкграунд...

Некоторое время назад мне потребовалось перегнать большое количество видео из формата MPEG2 в формат h264. Причина заключалась в том, что MPEG2 это очень старый стандарт и он относительно малоэффективен по сравнению с h264. Эти видео нужно было залить в интернет, а место на диске в интернете стоит недешево, к тому же такие видео сложно и долго качать. Поэтому в какой-то момент, намучавшись с файлообменниками, мне пришла в голову замечательная идея перегнать их в h264 и сэкономить всем нервы.

При этом требования к кодированию были такими же, как почти у всех, то есть максимальное качество (соответствующее оригиналу) при минимально возможном размере (и битрейте, соответственно). Масла в огонь подливал тот факт, что эти видео были не какими-то, а записями программ фигурного катания, обычно в разрешении FullHD.

Дело в том, что программы с фигурным катанием - это очень особый и интересный вид видео. На мой взгляд, это один из наисложнейших видов видео, более сложный чем аниме и фильмы. И эт так, потому что в фигурном катании большую часть программы все движется - и фигурист, и бэкграунд, причем бэкграунд часто очень детальный (на FullHD видео можно разглядеть лица людей), поэтому такие видео являются очень сложными для сжатия. С другой стороны, их специфика еще и заключается в том, что большая их часть является записью с ТВ, как правило, не самого лучшего качества, поэтому его желательно вообще не терять, так как оно не является очень хорошим изначально.

Для начала, основы основ...

Все цифровые видео в данный момент являются сжатыми, будь то файлы на вашем компьютере, Blu Ray диски, трансляции ТВ и цифровые записи фильмов в кинотеатре. Причина для этого достаточно простая - несжатое видео занимает просто неадекватное количество места.

Если представить видео, как серию кадров (фотографий), в которой каждый пиксель является 24-битным числом, то получается, что запись 1 часа при частоте кадров 30 в секунду в видео с разрешением FullHD занимает 24*1920*1080*30*60*60 = 5374771200000 бита, или 625 гигабайт. Из этого становится очевидным, что необходимо какое-то сжатие.

Самый базовый вид сжатия - это сжатие отдельной фотографии/кадра тем же алгоритмом, который используется при сжатии статичных изображений. Например, если какой-то пиксель одного и того же цвета повторяется подряд (например, вся верхняя часть кадра является темной), то вместо того, чтобы записывать каждый пиксель отдельно, можно записать, что определенное количество пикселей, начиная с определенного пикселя, имеют одинаковый цвет, и таким образом, выразить в меньшем числе байт идентичное количество информации ("10 черных пикселей" вместо "черный, черный, черный, ...").

Такой вид сжатия не подразумевает, естественно, потерю качества. Можно сделать это сжатие более агрессивным, например объединять не только пиксели одного цвета, но пиксели очень схожих цветов. Тогда во многих случаях разница будет незаметна, но на хороших мониторах будет видно, что некоторые пиксели в сжатой версии "перекрасились" в другой цвет. Это уже потеря качества. При агрессивном сжатии такого типа появляются характерные квадратики одного цвета, которые выпадают из общего фона изображения. Это характерно для многих изображений в формате JPEG.

Базовые основы алгоритмов для сжатия видео

После того, как был применен базовый метод сжатия для каждого отдельного кадра, можно пойти дальше и начать применять алгоритмы, которые учитывают особенности видео. Почти все современные алгоритмы сжатия видео построены на одном и том же принципе.

Этот принцип заключается в том, что видеофайл не хранит все кадры, которые присутствуют в видео, целиком. Вместо этого, он хранит целиком только некоторые отдельные кадры, которые я в дальнейшем буду называть кейфреймами. Их число значительно меньше, чем общее число кадров для видео. Остальные кадры, которые не являются кейфреймами, не хранятся целиком в видео, а хранятся они в виде различий этого конкретного кадра и ближайшего к нему кейфрейма. То есть, для реконструкции кадра берется его кейфрейм и на этот кейфрейм накладываются различия.

При таком способе кодирования восстановленный кадр может не иметь потерь в качестве, так как мы можем восстановить 100% информации об этом кадре на основе кейфрейма и этих различий, и это можно обосновать математически.

Из этой схемы сжатия сразу же выходит несколько очевидных последствий:

1. Эффективность кодирования зависит от параметров алгоритма сжатия и от этих же параметров зависит качество. Качество мы определяем как соответствие оригиналу, чем выше соответствие, тем выше качество.
2. Разные алгоритмы и один и тот же алгоритм при разных параметрах и условиях, будут показывать разную эффективность. Эффективность мы определяем как соотношение качества и битрейта.

Например, если мы имеем дело с трансляцией через интернет, то алгоритм сжатия не может заглянуть "вперед" файла. Он получает информацию, вставляет кейфрейм, какое-то время вставляет различия до тех пор, пока их количество не станет таким большим, что ему будет выгоднее вставить новый кейфрейм, чем продолжать вставлять различия. В таком случае, ему потребуется больший битрейт, чтобы достичь определенного качества.

Если мы имеем дело с файлом на диске, то алгоритм имеет возможность просканировать весь файл, выбрать в нем те кейфреймы, которые наиболее эффективны, и вставить между ними различия уже зная, с чем именно он имеет дело. Например, он может ставить различия не только после кейфрейма, но и до него, если окажется, что это эффективнее (например, мы имеем кейфремы на 0:15 и 0:16, до 0:15,5 используются различия с прошлым кейфремом, с 0:15,5 до 0:16 с последующим кейфреймом). Таким образом, качество кодирования при таком же битрейте окажется выше, чем в случае с трансляцией, где алгоритм был вынужден действовать "на глазок".

Параметры так же кардинальное влияют на эффективность. По сути дела параметры алгоритма задают его скорость. При высокой скорости алгоритм будет вынужден принимать быстрые решения и, как следствие, жертвовать качеством. При медленной скорости, компьютер сможет проанализировать каждый кадр в отдельности по отношению к другим кадрам и, в итоге, выбрать наиболее оптимальный вариант для кодирования каждого отдельного кадра.

Реализация в коде

Хотя до этого мы говорили о том, как кодирование видео выглядит визуально, следует учитывать, что современные алгоритмы сжатия представляют собой сверхсложные математические формулы, которые очень трудно соотнести с тем, что мы видим на экране. Так же нужно учитывать особенности компьютерной архитектуры и тот факт, что компьютеры по сути дела являются глупыми машинами, которые понятия не имеют о том, что именно они обрабатывают. Для них вся информация является числами, а сжатие любой информации является поиском паттернов между этими числами.

Некоторые люди, используя исключительно формулы, утверждают, что математически любое перекодирование видео приводит к ухудшению качества, а так же, что чем больше используется при кодировании процессоров, тем ниже будет качество. Хотя это действительно так с математической точки зрения, я лично не уверен, что это действительно обязано происходить на практике. Дело в том, что количество потерянной информации в реальности может занимать меньше одного пикселя и не приводить к погрешности в этом самом пикселе, что означает, что на практике никаких потерь нет. Это особенно очевидно в случае с потерей качества в результате многопоточной обработки, о практическом проявлении которой я ни разу не слышал.

Что вызывает потерю качества

Потерю качества видео вызывают, фундаментально, три вещи:

1. Необходимость запихнуть видео в определенный битрейт, когда ему нужен больший битрейт. Поэтому я не рекомендую использовать какой-либо лимит для битрейта (что нужно делать вместо этого, я напишу ниже). Вместо этого нужно дать алгоритму свободу в выборе битрейта - он сам всегда старается выбрать наименьший битрейт. Таким образом для статичного изображения в течении нескольких секунд в видео потребуется очень маленький битрейт. Для сцены с большим количеством движения потребуется очень высокий битрейт.

2. Малое количество времени для анализа. Поэтому на стримах при определенном битрейте качество всегда ниже, чем в перекодировании с оригинала при таком же битрейте. Так же для максимального качества потребуется дать алгоритму наиболее широкие лимиты для анализа.

3. Использование "психологических" трюков, например сознательное сжатие с потерями кадров, которые находятся в сценах с движением. Во время просмотра видео эти потери, возможно, незаметные, но если остановить видео, то становится видно, что все объекты являются замыленными. Чаще всего, впрочем, это замылевание видно и во время просмотра.

Какое сжатие используется на практике в повседневной жизни

На данный момент стандартом для сжатия видео является формат h264, который используется почти повсеместно. Этот формат позволяет сжать видео с отличным качеством при относительно небольшом размере. Видео в формате h264 занимает около 30% от размера видео в формате MPEG2 при таком же самом качестве.

В жизни чаще всего мы сталкиваемся с этим и другими форматами в следущих контекстах:

1. YouTube - используется h264. Качество обычно так себе, часто оно сильно зависит от качества оригинала и обычно оно тоже так себе изначально. Алгоритм сам по себе явно очень хитрый, но на практике качество видео 720p соответствует аналогичному 360p в высоком качестве, а 1080p качеству 720p. Но есть исключения.

Следует заметить, что заявленное и реальное разрешение видео это не одно и то же. Заявленное разрешение видео - это разрешение файла. Реальное разрешение - это разрешение, при котором каждый пиксель видео является реальным, то есть он передает уникальную информацию (и не является частью блока данных, который дал, скажем, квадрату 16 x 16 среднее значение пикселей, которые составляли в оригинале этот квадрат).

2. Цифровое телевиденье - чаще всего h264 или другой подобный алгоритм. По сути дела это тоже самое, что стрим, со всеми его недостатками. Битрейт зависит от стандарта цифрового телевиденья, может составлять 20 mbps, а может и 7... Список стандартов и их характеристик можно посмотреть на Википедии, в целом качество ниже идеального, но обычно очень хорошее.

3. Blu Ray диски. Их битрейт составляет до 40 mbps и это качество обычно считается идеальном или референсным. Тем не менее, следует учитывать, что параметры алгоритма для кодирования этих дисков не являются максимально агрессивными из-за спецификаций Blu Ray проигрывателей. Иначе говоря, часто возможен вариант, когда либо качество могло бы быть выше при таком же битрейте, либо такое же качество можно было бы вместить в значительно более низкий битрейт.

Так же некоторые диски являются плохо сделанными, например они являются апскейлом DVD-версии, либо используются неоптимальные параметры для алгоритма кодирования. Это часто происходит со старыми фильмами или аниме.

Хорошо сделанные Blu Ray диски, например релизы современных американских фильмов, чаще всего можно назвать обладающими идеальным качеством.

4. Цифровое кино. В цифровом кино не используются алгоритмы сжатия, которые используют различия между кадрами вместо самих кадров. Вместо этого цифровой формат кодирует отдельно каждый кадр, как если бы это было отдельным изображением, и останавливается на этом. В результате цифровые записи для кинотеатров занимают очень много места, например, 300 гигабайт и более, и отдельный фильм записывается на отдельном жестком диске, который так же обычно является специальном диском с высокой скоростью передачи данных. Таким образом, исключается использование каких-либо "психологических" методов для сжатия.

В целом, вопрос о том, обладает ли цифровое кино лучшим качеством, чем хорошо сделанные Blu Ray диски, не является закрытым. В теории, реконструкция кадра через кейфрейм и различия не вызывает никаких потерь в качестве, однако на практике необходимость уложиться в битрейт, константу качества (о ней ниже), лимиты в заданных параметрах алгоритма, наконец, ошибки в самом алгоритме или имплементации, могут вызвать потери. Если отказаться от такой схемы кодирования в принципе, то эти потери исключены.

Цифровая копия фильма для кинотеатров считается его идеальной версией и она полностью соответствует оригиналу (мастер-версии). Исключением являются случаи, когда мастер-версия в очень высоком разрешении (разрешение в обычных кинотеатрах несколько выше FullHD, в IMAX-кинотеатрах разрешение это 8K), либо когда она записана на пленке. Пленка не обладает сама по себе более высоким качеством, чем цифровые версии, некоторые пленочные версии по качеству хуже, чем современное FullHD, некоторые лучше. Установить разрешение записи на пленке достаточно сложно на практике.

5. Файлы на компьютерах.

Здесь есть все. Есть очень хорошо скодированные файлы небольшего размера в прекрасном качестве, есть невообразимое дерьмище размером в десятки гигабайт.

Практические рекомендации по кодированию видео

Здесь я дам рекомендации по поводу того, как кодировать видео с направленностью на оригинальное качество и минимальный размер. Для начала, нам потребуется позабыть о битрейте, который сам по себе к качеству имеет опосредственное отношение, и познакомиться с другим параметром под названием Constant Ratefactor, который тоже имеет опосредственное отношение к качеству, но который гораздо полезнее битрейта. Иногда этот параметр называют "Качество" ("Quality"), но на самом деле это не качество.

Этот параметр, если буквально, является константой, ориентируясь на которую, алгоритм выбирает какое количество информации выделять для определенной сцены в зависимости от других параметров. Это константа необходима потому, что компьютеры, как я уже говорил, являются глупыми и понятия не имеют о том, видео какого качества они выдают. Они могут применять алгоритм до бесконечности по отношению к определенной сцене и они способны, в буквальном смысле слова, раздувать размер сцены до бесконечности, например из 100 мегабайт сделать 10 гигабайт при таком же качестве.

Поэтому необходимо задать определенные границы, при достижении которых алгоритм останавливается и записывает результат. В качестве такой границы может служить максимальный или средний битрейт, но я его не советую, так как его выбрать достаточно сложно. Вместо этого лучше взять именно Constant Ratefactor, который дает меньше вариантов и менее ограничивает сам алгоритм.

Точное значение Constant Ratefactor можно выбрать только эмпирически. Сам параметр влияет на качество экспоненциально и чем он ниже, тем выше качество. Например, CRF=1 выдает гигантские файлы, которые всегда гораздо больше оригинала по размеру.

Я лично использую CRF=23 потому, что это минимальное рекомендованное значение для FullHD видео, однако, возможно, что оно сильно завышенное для моих параметров, представленных ниже.

Однако CRF не определяет качество. Определяют качество непосредственно параметры алгоритма, то есть насколько сильный задан анализ видео. Для одинаковых CRF можно получить совершенно разные результаты при разных параметрах.

Если параметры "мягкие", то алгоритм будет слабо анализировать файл и ему потребуется больше места для высокого качества. Так как CRF ограничивает место, то дойдя до лимита, алгоритм просто запишет что есть, и продолжит обработку. Если параметры задают очень дотошный анализ, то алгоритму потребуется меньше места для высокого качества, а значит, когда он дойдет до лимита, то ему хватит места, чтобы записать видео в максимальном качестве.

В качества кодека я рекомендую использовать x264. Это state of art кодек h264 с открытым кодом, который по эффективности является наилучшим в индустрии. Он выжымает по максимуму все возможности формата h264. При этом следует заметить, что он практически никогда не используется для создания коммерческих Blu Ray дисков.

Для управления этим кодеком существует огромное количесво графических оболочек разной степени паршивости. Я лично использую Handbrake, но наверняка есть и лучшие.

Для моих нужд я использовал для Constant Ratefactor значение 23. Для параметров алгоритма я задал максимальные значения в рамках "нормы". Эти параметры выглядят вот так в командной строке Handbrake:

ref=6:bframes=5:b-adapt=2:direct=auto:me=tesa:subme=10:merange=64:analyse=all:trellis=2:no-dct-decimate=1

Идея заключается в том, чтобы произвести максимально строгий анализ видео. При этом я не вижу смысла в том, чтобы проводить кодирование в два захода, поскольку во время первого и единственного из них мы проводим строгий анализ. Первый заход, в случае с двумя заходами, обычно служит для того, чтобы грубо прикинуть сложность сцен до финального захода и повысить, таким образом, его эффективность, но в нашем случае наши параметры делают этот первый заход бессмысленным.

Небольшая ремарка относительно аудио: это отдельная тема, но на практике можно считать, что AAC при битрейте в 192 kbps является lossless.

По теме

http://git.videolan.org/?p=x264.git;a=blob_plain;f=doc/ratecontrol.txt;hb=HEAD - краткое описание алгоритмов и различий между ними

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.7528&rep=rep1&type=pdf - более развернуто

Сэмплы

Здесь вы можете посмотреть на практические результаты.

 

В качестве оригинала используется MPEG2 запись с японского ТВ. Она относительно высокого качества.
Размер файла составляет 1,2 гигабайт.

Линк: https://mega.co.nz/#!F8UkTLhZ!1pCom9WpnyK44aDXVqBuirY3Mvv7NvhjhFO_enJA4AE

С нее была сделана копия с параметрами, представленными выше.
Размер файла составляет 286 мегабайт.

Линк: https://mega.co.nz/#!8xMSUZoJ!BvvRgkoEJdpjAcNbLrhNCdQ7Nqg8Aa5zvgdtecD8moQ

В заключение

Это, что называется, не результат учебы, а ее процесс. В этом тексте могут быть ошибки. Мне нужно провести больше тестов и проверить различные варианты.

Комментарии, вопросы, мнения?

Изменено 5 апреля, 2015 пользователем Daniel5555
Исправлена опечатка.

[Uncle Vёder]

Да, действительно интересная тема.

 

Хотелось бы поподробнее раскрыть следующие вопросы:

1. Практическая польза от использования многопроходного кодирования (2х, 3х), сравнение производительности многопроходного кодирования с однопроходным, но с изначально строгим анализом.

2. Практика применения GPGPU для кодирования. Об этом часто любят говорить, и с большим пафосом, но на деле почему-то всё плохо с софтом, который это может.

[DupaVoz]

кейфреймами

Они, к слову, на русском и зовутся "ключевыми кадрами".

 

Я вот сколько ни сталкивался с темой кодирования, всегда не мог понять одну вещь. Наверно, это немного оффтоп, но всё же, может, кто знает: какого чёрта, можно иметь два файла, у которых почти идентичны mediainfo, но при этом один будет воспроизводиться телеком, а другой нет. И если сравнивать те самые кодеки, то разницы там точно нет. Значит, дело в чём-то ещё, но в чём? Что ещё может влиять?

2. Практика применения GPGPU для кодирования. Об этом часто любят говорить, и с большим пафосом, но на деле почему-то всё плохо с софтом, который это может.

Ты, например, про CUDA? Вроде ж с ним никаких проблем нет.

[Daniel5555]

1. Практическая польза от использования многопроходного кодирования (2х, 3х), сравнение производительности многопроходного кодирования с однопроходным, но с изначально строгим анализом.

Это нужно проверять на практике.

 

Но, с моей точки зрения, от многопроходного кодирования со строгим анализом пользы нет. По сути по время первого прохода алгоритм грубо прикидывает, сколько информации нужно выделить какой сцене, то есть он задает аналог CRF. Второй проход просто кодирует видео используя этот параметр с теми настройками анализа, которые были заданы пользователем.

 

В моем случае CRF задает сам пользователь. Если CRF задан плохо, то от этого будут проблемы, но если CRF задает компьютер, то это тоже не будет идеальным вариантом (к тому же пользователь все равно задаст лимит, просто это будет битрейт вместо CRF).

 

Если же проход только один и анализ строгий, то он будет анализировать достаточное число кадров и достаточно хорошо, чтобы прийти к таким же результатам, как при двухпроходном варианте. Причем однопроходной вариант при этом будет быстрее, если настройки анализа такие же, так как мы не тратим время на первый проход, который всего лишь задает аналог CRF.

 

Трехпроходной анализ, естественно, тем более не имеет смысла.

 

Loren Merritt писал уже много лет назад (в 2007 вроде) на форумах, что, вообще говоря, в итоге (по состоянию результата) нет разницы между двухпроходным и однопроходным кодированием. Это просто два разных подхода, через которые можно прийти к одним и тем же результатам. В итоге, вроде как, получается что однопроходной вариант является самым разумным, хотя в то время сторонников двухпроходного кодирования было больше. Не знаю, как сейчас. Причем тогда x264 не был таким хорошим, как сейчас. Сейчас у них анализ гораздо более строгий и эффективный.

 

 

 

2. Практика применения GPGPU для кодирования. Об этом часто любят говорить, и с большим пафосом, но на деле почему-то всё плохо с софтом, который это может.

Я слышал об этом, но я не видел результатов. Если это так, то у меня есть две версии на этот счет:

 

1. Это связано не столько с софтом, сколько с ограничением оборудования. Ядра видеокарт являются очень простыми по сравнению с ядрами процессоров. Их очень много и поэтому они хороши в некоторых задачах, но анализ видео, скорее всего, для них является слишком сложной задачей.

 

Например, для видеокарт не существует flow control на уровне отдельного ядра, только на уровне блока. То есть если имеется код типа

 

if (condition)

{

...

}

else

{

...

}

 

То весь блок произведет операции находящиеся как в if, так и в else, если есть хоть одно ядро в треде у которого значение condition отличается от значения в тредах других ядер. Возможно, что даже если такого треда нет, то блок все равно будет исполнен.

 

У этих ядер очень маленький кэш и так далее.

 

То есть, когда говорят про низкое качество кодирования, я думаю в первую очередь об архитектурных ограничениях видеокарт. Одно дело просто умножить две матрицы, и другое дело это проводить сложный анализ достаточно большой структуры.

 

Видеокарты хорошо служат для быстрого кодирования видео, но вряд ли они хорошо служат для кодирования с высоким качеством. Хотя я не знаю нынешней ситуации, возможно это поменялось.

 

2. Можно вспомнить ту самую формулу, которая гласит, что с увеличением числа процессоров падает качество, но по-моему это ерунда, если честно.

 

 

 

Я вот сколько ни сталкивался с темой кодирования, всегда не мог понять одну вещь. Наверно, это немного оффтоп, но всё же, может, кто знает: какого чёрта, можно иметь два файла, у которых почти идентичны mediainfo, но при этом один будет воспроизводиться телеком, а другой нет. И если сравнивать те самые кодеки, то разницы там точно нет. Значит, дело в чём-то ещё, но в чём? Что ещё может влиять?

Это зависит от настроек энкодера, то есть с какими настройками алгоритма был скодирован файл.

 

Например, мои настройки создают файлы, которые, насколько я знаю, не совместимы с Apple TV. Я точно не помню почему, но, в качестве примера, у специализированного устройства, будь то телек, или какая-нибудь приставка, может быть лимит на ref=3, то есть если этих reference фреймов в видео больше, то оно не сможет его раскодировать, потому что у него недостаточно памяти или еще по какой причине.

 

Если я кодирую с ref=6, то не означает автоматически, что там будет именно 6 reference фреймов, так как алгоритм всегда старается сделать, чтоб их было как можно меньше, так что, в зависимости от видео, может и не будет нигде ситуации, где reference фреймов будет больше 3, и тогда файл будет совместим. Но если окажется, что их будет больше, а так, скорее всего, и будет, то файл будет нечитаемым на таком устройстве.

 

Для компьютеров это неактуально, так как у нас универсальные и достаточно мощные процессоры, и много памяти, так что все упирается в софт. Для телеков и других устройств обычно существуют строгие ограничения на то, как именно должен быть сделан файл для того, что гарантировать его воспроизведение. Кодек при этом один и тот же, так как кодек это просто спецификация того, что есть и может быть в файле (что такое все эти reference фреймы и прочее), но конкретное количество задается про создании файла и в итоге файл может быть как очень простым, так и очень сложным по структуре (и, соответственно, разным по качеству и агрессивности сжатия).

Изменено 5 апреля, 2015 пользователем Daniel5555
Исправлена опечатка.

[Uncle Vёder]

Видеокарты хорошо служат для быстрого кодирования видео, но вряд ли они хорошо служат для кодирования с высоким качеством.

Интересная теория. Поддержка GPGPU действительно встречалась мне в основном как раз во всяком говнософте для быстрого кодирования, хотя в более-менее серьёзных проектах её не видно.

Возможно, для кодирования с высоким качеством оно действительно не годится.

Хотя, говоря о серьёзном софте, GPGPU кодек (даже несколько их) есть например в Sony Vegas. Правда, они и там работают через раз (например, отказываются работать на картах AMD HD7800 и HD7900, хотя поддержка OpenCL заявлена и со стороны кодека и со стороны видеокарты).

[DupaVoz]

Ништяк ответ, спасибо. Покопаю я эти новые знания.

[Black Cat]

if (condition)

{

...

}

else

{

...

}

в контексте вычислений это на самом деле не проблема

result = condition * (...) + !condition * (...)

стандартная задачка для собеседований)

[Аюпа]

result = condition * (...) + !condition * (...)

 

Ну проблема ж как я понимаю, что в таком случае вычислять придется по обеим скобкам, а в случае ветвления - только по той, которая выбрана.

[Black Cat]

Ну проблема ж как я понимаю, что в таком случае вычислять придется по обеим скобкам, а в случае ветвления - только по той, которая выбрана.

Аюп там перед одной скобкой умножение на 0 всегда, выражение в скобках вычисляться не будет. Изменено 8 апреля, 2015 пользователем Areldar

[Daniel5555]

Я сделал версию с CRF=28 с того же оригинала и такими же параметрами, какие представлены в первом посте:

 

ref=6:bframes=5:b-adapt=2:direct=auto:me=tesa:subme=10:merange=64:analyse=all:trellis=2:no-dct-decimate=1

 

Размер файла составляет 140 мегабайт.

 

Линк: https://mega.co.nz/#!thcRULha!jSOhBuE0GHHmVn537QhEoT_CP6c4gDLgDNWv8pD45WU

 

Как и ожидалось, там есть падение качества за счет уменьшения размера, однако меня удивило качество видео в движении. Разница заметна, но не настолько чтобы понять, что размер видео уменьшился на половину. Этот результат весьма интересен.

 

Обычно CRF рекомендуют в значениях от 28 до 18. Эмпирически, у меня есть ощущение, что CRF=23 должно хватать любому видео, но мне нужно проверить с оригиналом гораздо лучшего качества, чем мой нынешний.

 

Разница между видео в скриншотах:

 

CRF 23

CRF 28

 

CRF 23

 

CRF 28

 

Скорее всего, CRF=23 для моего оригинала это слишком много из-за его низкого качества. По логике, скорее всего следующий тест следует провести с CRF=25, но было бы интересно посмотреть на разницу во всех вариантах между CRF=23 и CRF=28. Если у кого-то есть время и/или мощный процессор, был бы признателен.

 

 

 

if (condition)
{
...
}
else
{
...
}

в контексте вычислений это на самом деле не проблема
result = condition * (...) + !condition * (...)
стандартная задачка для собеседований)

 

 

 

 

Ну проблема ж как я понимаю, что в таком случае вычислять придется по обеим скобкам, а в случае ветвления - только по той, которая выбрана.

Аюп там перед одной скобкой умножение на 0 всегда, выражение в скобках вычисляться не будет.

 

 

Это какая-то ерунда.

 

В блоках ядер видеокарт они все исполняют одну и ту же инструкцию в один момент времени. У них нет отдельного планировщика на ядро, только на целый блок.

 

Более конкретно, если имеется код вида

 

if (array[threadIdx.x] > 10)

{

...

}

else

{

...

}

 

Если блок состоит из 32 ядер и array[0..15] содержит числа >10, а п array[16..31] числа =<10, весь блок ядер выполнит как вариант if, так и блок else. Половина блока ядер выполнит по-настоящему инструкции блока if, в то время как другая половина выполнит те же самые инструкции, просто их результат будет автоматически выброшен. Затем тоже самое произойдет с блоком else.

 

В твоем варианте result = (array[threadIdx.x] > 10)*(...) + (!(array[threadIdx.x] > 10))*(...) произойдет тоже самое. Все ядра выполнят все инструкции, просто они выполнят умножение на ноль в первой или во второй части.