Сравнение кодеков для видео. Обсуждение, тесты, необходимый софт

[AlexB17]

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

[RBF]

По поводу VC1 (WMV9 AP) есть картинки.
Примерно вот такого различия в качестве между H264 и VC1 на битрейте 450 кбит/сек можно ожидать:

VC1 (WMV9 AP)
http://rbf.nm.ru/VC1.jpg

H264
http://rbf.nm.ru/H264.jpg

[SilentSpider]

RBF
Примерно вот такого различия в качестве между H264 и VC1 на битрейте 450 кбит/сек можно ожидать:
Кошмар. И это кодек нового поколения? С таким жутким мылом. И сцену я бы для кодека сильно сложной не назвал...

[Digit_All]

http://www.compression.ru/video/codec_comparison/introduction.html - это что касается кадров

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

SilentSpider
а с чего вы взяли что это VC-1 и оптимальные настройки, я могу надписи местами поменять и утверждать обратное :) вы любитель уважаемый :)

[SilentSpider]

Digit_All
а с чего вы взяли что это VC-1 и оптимальные настройки, я могу надписи местами поменять и утверждать обратное
Не можете, моя прелессть. Потому что я представляю, какую картину должен давать H264. И сделать такие настройки кодека, чтобы ТАК, извиняюсь, усрать картинку - это надо постараться. Это раз. Два - кто такой RBF - я знаю. По двум форумам. Кто такой вы - я не знаю. И пока у меня гораздо больше оснований доверять ему, нежели вам. Во всяком случае в области корректности результатов.
это что касается кадров
Ну и? Сделайте свое, сравните, выложите результаты. BTW - и сделайте так, чтобы тест был достоверным. Ибо пока вы машете чапаевской саблей и между делом слегка хамите.
вы любитель уважаемый
Считайте что предупреждение вы уже получили. В следующий раз будете дискутировать с зеркалом.

[Force]

Я самый маленький и ничего не знаю :). Скажу только, что верхний скрин у RBF'а представлен в искаженной цветовой гамме (когда открыто 2 плеера, второй открывает видео в несколько высветленном варианте). Поэтому качество НАСТОЛЬКО отличается, хотя даже если это учесть, то VC1 всё равно выглядит хуже. Кстати, кто-нибудь подскажет, чем можно снимать скриншоты у видео? А то я PrintScreen'ом пользуюсь... Ы.

А тест хочу провести скорее для себя, ибо уже тестировал на реальных фрагментах другие кодеки (VP7, XVID), но результатами не удовлетворился, все они проиграли x264. Правда, XVID ещё потестю, но уже скорее локально, то есть, если будет что интересное сказать - скажу, а нет - так и фиг с ним.

Тест же мой довольно СУБЪЕКТИВЕН, поэтому можете относитьсяк нему как угодно, так как тестю, как говорил, для себя. Но сам по себе он довольно специфичен, так как сравниваю x264 и его коммерческого конкурента, которого слил на днях. Это крякнутая версия MainConcept 2.0.15. Так оказалось, что она не настолько крута, как говорят. Да, кодит быстро, но качество у неё реально хуже. Это даже визуально видно. Да, я слышал, что это не самая новая, не самая крутая версия и т.д. и т.п. Но на официальном сайте именно она значится как последняя, и я нахожу эти слухи несколько странными... Я сравнивал её с версией x264 - 557. Хотел с последней сравнить - 564, но поскольку я маленький и хуже всех, то банально забыл её обновить в папке Program Files :). Так вот, результаты оказались следующими:

Количество фреймов: 5019 (дабы лучше проверить распределение битрейта) (почему 19? не спрашивайте, это секрет! :laugh: )
Разрешение: 704x416

Материал: умеренно динамичный. Фильм "Последний Уик-Энд", от фрейма 23982 до 29000 (поэтому и 19 :laugh: ).


Время кодирования, сек:
MC - 3581
x264 - 3840

Используемые настройки:
Bitrate: 1742

MC
Prifile: High
Level: 5.1
Use B-Pictures 3 (в Обсерватории вычитал, что b-frames = B-Pictures - 1, но при подстановке "4" видео начинает дергаться, словно какие-то кадры выпадают, качество же меняется незначительно, всё равно уступая x264)
Use B-Slices as Reference: on
Multiple Slices: off

Reference Frames: 16
Search Mode: 8x8 (там есть 16х16, но оно стоит выше по списку, и я предположил, что оно хуже, в инструкции же ничего дельного не написано, может вы просвятите?)
Subpixel Mode: Quarter

Rate Distortion Optimization: on
Fast Intra Decisions: off
Fast Inter Decisions: off

Из того, что менял в Additional Settings:
Use Hadamard Transform: yes (в документации сказано, что улучшает картинку)
SAR выставил 1:1
Всё остальное по умолчанию.


x264
"C:\Program Files\x264\x264.exe" --progress --pass 3 --bitrate 1742 --stats "x264.stats" --ipratio 1.40 --pbratio 1.30 --ratetol 1.0 --qpmin 8 --qpmax 50 --qpstep 4 --scenecut 40 --min-keyint 25 --keyint 300 --direct auto --8x8dct --ref 8 --mixed-refs --analyse all --b-pyramid --weightb --bframes 3 --b-bias -10 --subme 6 --me umh --merange 16 --sar 1:1 --threads 1 --filter 0:0 --no-psnr --no-ssim --b-rdo --trellis 1 --no-fast-pskip --no-dct-decimate --bime --aq-strength 0.3 --aq-sensitivity 15 --vbv-bufsize 0.9 --quiet -o "video.264" "lol.avs"

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

Преимущество в 259 секунд MC кодека над х264 выглядит просто смешно по сравнению с:
- его платностью (500 БАКСОВ за ЭТО??? я лучше видюху новую куплю :) ),
- его громоздкостью (20 Мб против 300 кб у x264),
- неудобством его настройки (которые имеют обыкновение сбрасываться, если не сохранить профиль, а если сохранить, то для другого видео его придётся полностью перелопачивать),
- пройгрышем в качестве,
- некоторой глюковатостью (как, например, случай с "B-Pictures: 4")
- ограниченностью настроек вообще (САМЫЙ значительный фактор).

Ограниченность настроек является самым большим пройгрышем всех кодеков, обладающих интерфейсом (кстати, именно поэтому я не использую GUI для x264). По этой же причиние ему, x264, проиграл и VP7 в моих тестах, тоже вывернутый на максимум... И опять таки, x264 при этом не был на максимуме, причем далеко! Его великий и ужасный режим exhaustive search, убийственно медленный, но являющийся, пожалуй, самым МОЩНЫМ оружием, способным удерживать его на вершине качества (заметьте, не скорости), может творить чудеса даже на СВЕРХнизких битрейтах (ниже 150 kbps) вытягивая изображение на достойный уровень (речь идет о небольших разрешениях видео). А пренебрегаемый многими режим advanced quanization избавит картинку от назойливых квадратов на полутонах...

Поэтому лично для себя ещё раз нашёл аргумент в пользу x264.

Скрины (http://darkfate.ru/index.cgi?show=files/force/lwe.7z) (представлены в несколько искаженной цветовой гамме, как верхний скрин у RBF'а, но это не мешает сделать их визуальное сравнение, так как они все одинаково искажены :)) (2.73 Mb в архиве 7z).

Префиксы скринов:
h - MainConcept
x - x264
mc - MainConcept с параметром "B-Pictures: 4"

--------------------

SSIM тест оказался обескураживающим:

MC - 81.20902454
x264 - 81.41894222

На мой взгляд, разница заметно ощутимее, нежели эти показатели. Хммм... Вот тебе и научился делать ssim-тест. Может я что-то не так замутил? Сравнивал я пожатое видео с непокоцанный шумодавами видео-потоком, который всего лишь был обрезан по краям и ресайзен до нужного размера. Ко всему прочему у меня отказался работать параметр lumimask=true, сказав, что аргумент had the wrong type. Этот параметр как-то влияет на тест?

[RBF]

Force
Я самый маленький и ничего не знаю
Маленький да удаленький, быстро смекнул, что сейчас самое актуальное - это сравнение H264 кодеков между собой, а не с другими кодеками, где и так все ясно ;)
верхний скрин у RBF'а представлен в искаженной цветовой гамме (когда открыто 2 плеера, второй открывает видео в несколько высветленном варианте
Да нет, про эту фишку я знаю, просто VC1 на самом деле закодировал светлее.
Преимущество в 259 секунд MC кодека над х264 выглядит просто смешно по сравнению
Ты кодировал x264 первый турбо проход? У MC оба прохода идут с одинаковой скоростью.
Да есть версия, где настроек больше и можно также настроить первый турбо проход, но в остальном кручение всех этих дополнительных настроек большого прироста в качестве не даст, так что особо не переживай, что у тебя нет полной версии энкодера (который сам по себе тоже весит меньше метра) :)
Да, я слышал, что это не самая новая, не самая крутая версия и т.д. и т.п. Но на официальном сайте именно она значится как последняя
Да там далеко не новая версия. О том как ее обновить я написал тебе в личку. Так что придется тестировать снова :)

режим advanced quanization
adaptive quanization

Ну и SSIM тест не делал, так как ещё не умею. Даже ещё не пробовал. Просто скажите, если делать его через AviSynth, то библиотеку ssim.dll откуда брать, и как юзать? Документация есть?
Вот статья для начинающих по avisynt - http://www.ixbt.com/divideo/avisynth1.shtml

Документация в самом инсталяторе ависинта, благодаря команде переводчиков, которую собрал Физик теперь на русском (я тоже внес свою скромненькую лепту).

ssim (http://rbf.nm.ru/SSIM.rar)
Скрипт примерно такой:

a=MPEG2Source("D:\film.d2v",idct=2).Crop(0,76,-0,-76).LanczosResize(720,304).Trim(0,5000)
b=DirectShowSource("D:\film.mp4",fps=25).Trim(0,5000)
return ssim (a,b,"D:\results.csv","D:\averageSSIM.txt", lumimask=true)

[Force]

Да нет, про эту фишку я знаю, просто VC1 на самом деле закодировал светлее.
Ясно, тогда жесть ваще!
Ты кодировал x264 первый турбо проход?
Блин, забыл сказать! :) Все проходы одинаковые, что у x264, что у MC.

adaptive quanization
Точняк, спасибо! :)

Ладно, значит, будем смотреть, что можно улучшить, и что из этого всего выйдет...

[Digit_All]

Quote: "Да нет, про эту фишку я знаю, просто VC1 на самом деле закодировал светлее."

-v_median 0 - и фишку отключили, если же отключена, то
-v_mslevel 4

это не фишка, а настройки...

[Force]

Digit_All, настройки чего?

[SilentSpider]

Digit_All
это не фишка, а настройки...
Угу. А мыло - это тоже настройка, надо полагать?

[Force]

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

[Digit_All]

Угу. А мыло - это тоже настройка, надо полагать?

Возможно, настроек у WMV 9 AP хватает, я толком сам не разобрался до конца поэтому и тест тормозит. Кроме того нужен правильно подготволеный материал, т.к. пофиксеный скрипт некорректно работает с .avs файлами. А оригинальный скрипт и WM Encoder 9 не понимает его вообще.

Quote: Но настройкой такой эффект назвать трудно...

В VC-1 есть настройка которая позволяет экономить битрейт выдавая подобный "светлый" эффект.

[Digit_All]

Кроме того http://forum.doom9.org/showthread.php?t=116044 список ошибок AviSynth 2.56 и среди них есть:

Corrected colours in YUV ColorBars, Now match BT.801-1.

Давайте вспомним что:

одним из FourCC цветового пространства YUV а для цифрового видео правильно YCbCr является YV12, т.е. данная последовательность отображения цветов в плоскостях Y Cb и Cr, для корректного определения метрики SSIM при помощи ависинт плугина. Следовательно если в YUV имелась ошибка, то она же могла иметься и в результатах исследований сделаных упомянутым образом.

[SilentSpider]

Digit_All
Но настройкой такой эффект назвать трудно...
Интересно. Давайте все же конкретизируем. Вариантов тут два - либо RBF намеренно или случайно настроил кодек так, что он стал выдавать эту жуткую муть, либо кодек не столь уж хорош. Относительно первого варианта - у меня нет оснований так предполагать, да и у вас, как я понимаю, нет данных, делающих результаты теста ничтожными. Есть данные? ОК, приведите. Сделайте наконец свой тест. Хотя бы на дефолтных установках кодеков. Продемонстрируйте что вы можете, а то это начинает надоедать.

Corrected colours in YUV ColorBars
Гм. А вы вообще в курсе - ЗАЧЕМ этот фильтр?
"Фильтр ColorBars производит видеоклип, содержащий цветные полосы SMPTE, смасштабированные к любому размеру изображения. Произведенный клип имеет следующие параметры: разрешение - 640x480, глубина цвета - RGB32 [диапазон 16-235], частота кадров - 29.97 fps, длительность - 1 час."

PS - Для общей информации. Я знаю несколько релиз-групп, которые предпочитали кодировать в WMV. Cейчас они все перешли на x.264. К чему бы?

[RBF]

Digit_All
Речь была о другой фишке, как сказал Force
В VC-1 есть настройка которая позволяет экономить битрейт выдавая подобный "светлый" эффект.
-v_median не дает такого сильного осветляющего эффекта, а -v_mslevel вообще к этому отношение не имеет. YUV ColorBars тоже :)
Такое сильное осветление было из-за глюка кодека при кодировании avs.

ALL
Обновил VC1 кодек, сильное осветление пропало при любых настройках. Но замыливание конечно осталось.
Битрейт по прежнему 450 kbps
VC1 (http://rbf.nm.ru/VC.png)
H264 (http://rbf.nm.ru/H264.png)
Могу выложить ролики, если кому интересно.

VC1 не является кодеком нового поколения.
Первые библиотеки этого кодека были включены в одно из обновлений WMP10 еще в 2002 году (правда, этого никто не заметил :))
Потом была процедура утверждения VC1 в SMPTE (в ISO не утвержден).
Стандарт H264 был завершен только в 2003 году.
В инете можно встретить заявления M$ что при тестах эксперты визуально больше предпочли VC1, чем H264, но этот тест проводился тогда, когда просто еще не было достаточно совершенных реализаций H264 кодека.
По сути VC1 это Mpeg4 ASP+loopfilter, ну еще некоторые усовершенствования алгоритмов поиска движения, взятые в основном из стандарта H264, но все взять было нельзя, из-за патентных ограничений.
Т.е. по совокупной сложности алгоритмов сжатия VC1 уступает H264, за счет чего теоретически должен быстрее декодироваться (правда после выхода CoreAVC эта разница нивелирована). Из-за разности алгоритмов, VC1 дает или больше квадратов или больше мылит, когда loopfilter пытается сгладить эти квадраты, обращайте на это внимание при сравнении.
Теоретически можно еще увеличивать эффективность сжатия в рамках утвержденных профайлов VC1, но это будет сказываться на скорости, по упомянутым выше причинам.
(кстати подобная ситуация наблюдается и с VP7).

[SilentSpider]

RBF
Спасибо за информацию.
Могу выложить ролики, если кому интересно.
Да в общем-то и так все понятно. Вряд ли в динамике станет лучше.
VC1 не является кодеком нового поколения.
Первые библиотеки этого кодека были включены в одно из обновлений WMP10 еще в 2002 году (правда, этого никто не заметил )
Потом была процедура утверждения VC1 в SMPTE (в ISO не утвержден).
Но позиционируется то он как весь из себя улучшеный продвинутый и т.п. ;)
Ладно, ждем результатов эпохального тестирования от Digit_All.

[Force]

Отчет:

Сравнение обновленной версии MC и x264 показало тот же результат. В MC появились дополнительные параметры поиска, невероятно замедляющие процесс кодирования (чуть ли не втрое!), но даже они не позволили достичь такого же качества, с каким кодирует x264 на более низких настройках. Короче, вывод: обновленный Main Concept H264 Encoder уступает бесплатному x264!

Есть ещё какие-нибудь кандидаты, способные побить x264? Я что-то слышал про некий Atheme (или как там его), о котором все отзываются только положительно. Это кодер?

[RBF]

Force
Atheme входит в Неро рекод.
А по каким параметрам MC уступает x264, поконкретнее.

[Force]

А по каким параметрам MC уступает x264, поконкретнее.
Ну, во-первых, если MC выкрутить на максимум, то время кодирования у него возрастает настолько, что оказывается даже больше чем у x264 (с теми миоими настройками, которые я приводил чуть выше), но качество при это ВСЁ РАВНО уступает. Если новые функции поставить в режим Fast - то видео кодируется довольно шустро.

Пример приблизительного времени:

1000 frames

MC Fast: ~350 sec;
x264: ~500sec;
MC Complex: 950sec.

Самое лучшее качество, как я и говорил у x264. Есть правда несколько нюансов...

1. На глаз режимы MC Complex и Fast практически идентичны, поэтому обладатели мониторов с невысокой насыщенностью цветов разницы не увидят вообще, зато, как видно, скорость кодирования возросла почти втрое!
2. Несмотря на то, что x264 порвал MC как Тузик резиновый набалдашник от вантуза :), обладатели всё тех же не очень ярких дисплеев тоже разницы не заметят, а как показал SSIM тест, проведенный на самых первых кусках - она минимальна и нужна только таким придирчивым челам как я. :)
3. MC пожалуй подойдет тем, кто готов пожертвовать минимальным качеством ради скоости.

Тестирование проводилось только на высоких битрейтах - от 1000 kbps, поэтому трудно судить о крутизне MC на небольших инетных роликах. А поскольку мне иногда приходится заниматься созданием оных, то возможно вскоре я доложу и об этом тесте. Правда не думаю, что результаты хоть как-то изменяться...

А 40 Мб слить по модему без возмжности пауз и дозакачек - это мой личный рекорд! :) :)