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

[Black Cat]

Ты что-то все путаешь. Если применять со 100% соответствием C++ (и C) стандарты, то во всех проверках, где более одного условия, будет несколько инструкций типа JE на уровне ассемблера. То есть,

Именно. Стандарт перекладывает эти разбиения на плечи компилятора. В случае if(pointer && pointer->bool) постоянное вычесление правого значения это постоянное разменовывание разыменовывание NULL. С учетом того, что это общеупотребительный прием сомневаюсь, что это оптимизируется

[Daniel5555]

 

Ты что-то все путаешь. Если применять со 100% соответствием C++ (и C) стандарты, то во всех проверках, где более одного условия, будет несколько инструкций типа JE на уровне ассемблера. То есть,

Именно. Стандарт перекладывает эти разбиения на плечи компилятора. В случае if(pointer && pointer->bool) постоянное вычесление правого значения это постоянное разменовывание разыменовывание NULL. С учетом того, что это общеупотребительный прием сомневаюсь, что это оптимизируется

 

 

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

 

Но есть исключения, о которых я уже говорил :)

[Daniel5555]

Мне нужна ваша помощь...

 

Я наконец-то провел еще пару тестов. В данном случае тесты проводились с гораздо более качественным источником. Это Full HD видео в формате h264 взятое без каких-либо изменений с коммерческого Blu-Ray диска. К моему сожалению, оно тоже не идеальное, но хотя бы намного лучше чем то, с чем я работал ранее.

 

С него я сделал несколько копий с настройками, которые приведены в первом посту темы, но с разными значениями RF. Задача заключается в том, чтобы понять, на каком значении RF качество соответствует оригиналу (возможно, ни на одном, но я думаю, что все-таки такой вариант есть).

 

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

 

Оригинал (1,21 гигабайт):

https://mega.co.nz/#!pt9FxSYT!T_JZeWJ7-G50jTqSlrRP4wqo5B_cUPU3n6Dzf6SXL3U

 

RF=23 (117 мегабайт):

https://mega.co.nz/#!44EBhDDZ!C5HXIHNCLVtRu26VEtEkyUF6sSzyxfPk1LzKwt00Z28

 

RF=22 (135 мегабайт):

https://mega.co.nz/#!U80VxLhL!PXdLWsmVSCq7C572-whXvUdCEJ9aR44wBxiapcOQLlc

 

RF=21 (156 мегабайт):

https://mega.co.nz/#!BksFQTDA!On35IXBNChtbbBjqTSFmI4XhqY2XlzEtGBbZrhJluSc

 

RF=20 (184 мегабайта):

https://mega.co.nz/#!UhtxHYaT!IdcJ2sfp5tFWeH3S8VtFwJaRK5Lvqwb0b00LResihz4

 

RF=19 (217 мегабайт):

https://mega.co.nz/#!lxtCATbQ!PqI1i7NJKJwj1cFC2CkhSGMJeZTsGYqAeFS9usEa2SA

 

RF=18 (259 мегабайт):

https://mega.co.nz/#!0tNUyT6Y!0_O-GVB4ccwau8SkW8saHgpfCR62tRZvabOu7tQLYcc

Изменено 10 августа, 2015 пользователем Daniel5555

[N^2]

 

Мне нужна ваша помощь...

 

на том сайте надо зарегиться чтобы просмотреть?

[Daniel5555]

на том сайте надо зарегиться чтобы просмотреть?

Насколько я знаю, нет.

[N^2]

Насколько я знаю, нет.

не могу глянуть, просит ключ дешифровки  

[Daniel5555]

не могу глянуть, просит ключ дешифровки  

 

Скопируй в адресную строку всю ссылку. Ключ дешифровки находится после восклицательного знака.

 

Added: В любом случае, отредактировал пост, теперь все должно быть по клику.

[Daniel5555]

Еще один тест, теперь анимация. Попробую еще добавить тестов. Оригинал с коммерческого Blu Ray диска.

 

Оригинал (127 мегабайт):

https://mega.co.nz/#!l5kGBZAa!ilTk4jUFkJI79wzO6I52PG1Ebe17KvhJc1WKi5AViOo

 

RF=18, настройки из первого поста темы, как обычно (24 мегабайта):

https://mega.co.nz/#!VwMVhJob!25tugL4YEyur8PUAKnwWEHNQ8lsTXKZp2oEX1BofQ9A

 

Added: не обращайте внимание на "</span>" в ссылках, это какой-то баг, но сама ссылка рабочая.

[Uncle Vёder]

Сам спрашивал, сам и отвечаю.

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

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

Варианты тут следующие:

CBR (constant bitrate, постоянный битрейт). Здесь всё просто. Соотношение допустимого объёма ко времени видео устанавливается жёстко в виде "верхнего предела". Алгоритм будет всегда стремится к этому пределу и заканчивать обработку, когда предел достигнут. Таким образом можно точно спрогнозировать размер выходного файла.

VBR (variable bitrate, переменный битрейт). Здесь параметров уже задаётся три штуки: минимальный битрейт, максимальный, и средний. Алгоритм кодирования видео в таком случае при анализе кадров оценивает их "сложность" (с помощью некой математической метрики) и либо понижает битрейт относительно среднего, либо наоборот повышает. При этом собирается статистика по уже обработанным фрагментам видео, чтобы удержать среднее значение битрейта в заданных рамках. Такой подход даёт более высокое качество картинки, чем CBR, и при этом размер файла на выходе всё так же легко прогнозируется, поскольку прямо зависит от заданного значения среднего битрейта.

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

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

Многопроходное кодирование позволяет получить максимально возможное качество видео, когда нам нужно, чтобы результирующий размер файла вписывался в определённыё рамки. Но собственно зачем это может быть нужно? Как правило, раньше стандартный DVDrip весил 600-700МБ, чтобы влезать на CD-болванку. Для длинных фильмов или более качественных версий рипы разбивали уже на два таких куска. Когда в массы пошло HD-видео, стали популярны варианты рипов, соответствующие объёмам дисков DVD5 или DVD9.

Но у нас-то на дворе 2015 год. Использование оптических носителей давно потеряло актуальность. Поэтому и точный размер файла на выходе не так важен. Достаточно ограничить его некими "рамками приличия", а там пусть уже алгоритм сам решает, как ему лучше поступить.

Для объективной математической оценки качества в алгоритмах кодирования видео в любом случае используется метрика PSNR, но меняется способ, которым она задаётся. В случае с CBR/VBR параметры PSNR являются переменными и алгоритм должен вычислять их на ходу, постоянно пытаясь вписаться в заданные рамки битрейта, и по сути не зная "что будет дальше". Поэтому для достижения нормальных показателей качества требуется обработка в несколько проходов для более точной оценки, и по этой же причине потоковое видео всегда будет хуже качеством при тех же границах битрейта.

CQP (constant quantization parameter) - это просто константа, которой мы изначально и определяем PSNR. Алгоритму теперь не нужно заниматься предсказаниями, он просто выполняет фиксированное количество квантований, достигая требуемого соотношения сигнал/шум. Таким образом можно спрогнозировать выходное качество, а для кодирования требуется только один проход.

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

Вот тут и появляется CRF (constant ratefactor), о котором так много уже сказал Даниэль. Если в случае с CBR/VBR параметр QP динамически меняется, чтобы вписаться в битрейт, а в CQP он фиксированный, то в CRF он изменяется в зависимости от того, насколько много в сцене движения (для этого используются отдельные алгоритмы). Мы так же задаём базовую константу для PSNR, но кодек теперь может увеличивать количество квантований (и соответственно степень сжатия), если считает это нужным. В результате визуально видео будет неотличимо от закодированного с CQP, но будет занимать меньше места.

Да, CRF это "фишка" энкодеров x264 и x265. Другой софт, насколько мне известно, такую методику не поддерживает.

Краткие выводы:

1. Нет решительно никаких причин использовать CBR в любом виде, это прошлый век.

2. Если нужно получить на выходе файл строго заданного размера, стоит использовать VBR в несколько проходов. Это будет долго, но качественно.

3. Если жёстких требований к размеру выходного файла нет, нужно использовать QP. Так гораздо проще спрогнозировать выходное качество, и для кодирования нужен только один проход.

4. Степень сжатия можно улучшить, если использовать CRF вместо CQP в энкодерах x264/x265.

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

Ответ на второй вопрос плавно вытекает из первого. Да, GPGPU позволяет хорошо распараллелить процесс кодирования отдельных фрагментов. Но при разбиении видео на огромное число маленьких кусочков снижается эффективност сжатия, т.к. не получится так же хорошо выделять все типы кадров (а в том же H.264 их аж три типа: B, I, P, да каждый ещё и с разновидностями). Кроме того, опять же из-за слишком сильного распараллеливания невозможно применить многопроходное кодирование, поскольку процесс-то во многом последовательный.

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

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

[Daniel5555]

...

Спасибо огромное за пост.

 

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

 

Ответ на второй вопрос плавно вытекает из первого. Да, GPGPU позволяет хорошо распараллелить процесс кодирования отдельных фрагментов. Но при разбиении видео на огромное число маленьких кусочков снижается эффективност сжатия, т.к. не получится так же хорошо выделять все типы кадров (а в том же H.264 их аж три типа: B, I, P, да каждый ещё и с разновидностями). Кроме того, опять же из-за слишком сильного распараллеливания невозможно применить многопроходное кодирование, поскольку процесс-то во многом последовательный.

Я не совсем понял, что ты именно хотел сказать здесь.

 

Проблемы с кодированием через GPU, как я уже говорил, скорее всего вытекают из-за их архитектурных ограничений. Косвенно об этом говорили сами разработчики x264, хотя вначале они были настроены достаточно оптимистично.

 

То есть именно сам факт массивного распараллеливания не имеет особого значения - если бы ядра были такими же, как x86-ядро процессора, то никаких проблем бы не было. Но эти ядра гораздо проще и на них невозможно сделать реализацию сложных алгоритмов для глубокого анализа. В любом случае, алгоритмы работают с маленькими кусочками - если не ошибаюсь, 8 на 8 пикселей или 16 на 16 пикселей, и это никак не зависит от того, используется CPU или GPU.

 

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

 

Из моего опыта, конкретное количество B-кадров вообще никак не влияет на качество, но чуть-чуть влияет на размер. Если их, скажем, b-frames=5, то размер файла будет немного меньше, чем с b-frames=1. Воспроизведение видео будет более требовательно к оборудованию, если в нем много B-кадров.