[AlexB17]

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

[RBF]

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

VC1 (WMV9 AP)


H264

RBF

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

Кошмар. И это кодек нового поколения? С таким жутким мылом. И сцену я бы для кодека сильно сложной не назвал...

[Digit_All]

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

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

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

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? не спрашивайте, это секрет! )
Разрешение: 704x416

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


Время кодирования, сек:
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.

Скрины (представлены в несколько искаженной цветовой гамме, как верхний скрин у 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
Скрипт примерно такой:

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, настройки чего?