Videoforum - форум о видео и не только! - Сравнение кодеков XViD и h264

Эту тему можно также назвать "Качественное кодирование кодеком x264".
Скачиваем последнюю версию кодека x264.exe с авторского сайта. На день написания статьи это:
[Для просмотра данной ссылки нужно зарегистрироваться]
Программа x264.exe является самодостаточной DOS-программой. Для её запуска нужно написать "Блокнотом" bat-файл. Вначале пишем такой bat-файл:
x264.exe --fullhelp
pause
Запустив этот файл, мы увидим полный список оригинальных опций, их краткое описание, а в квадратных скобках – значение по умолчанию. Если ты планируешь освоить кодирование в h264, то рекомендую откопировать всё это добро в Word-файл.
Приступаем к сравнению. Для меня абсолютной истиной, не подлежащей никакому пересмотру, является кодирование на постоянном квантизёре, который должен быть одинаков для всех кадров: I, P и B. При таком подходе качество файлов h264 и XViD должно быть одинаковым (а так ли это на самом деле, мы посмотрим). Для оценки кодеков нужно сравнивать конечный объём файлов.
В x264 есть, кроме кодирования чисто на постоянном квантизёре, ещё некоторая промежуточная возможность – CRF. Что переводится как "Качество, основанное на переменном битрейте". В этом режиме включается оценка скорости движения. Более быстрые и динамичные сцены будут кодироваться с меньшим качеством, чем медленные, потому что в быстрых сценах, по мнению разработчиков данной функции, будто бы качество кодирования не столь заметно, как в медленных сценах. Я сразу и бесповоротно отметаю CRF: качество – всё, мелочная экономия – на помойку. У меня ты найдёшь только QP.
Кодированию могут предшествовать различные операции – деинтерлейсинг, обрезка, ресайз. Для меня также является непреложной истиной, что все эти операции нужно проводить какой-либо отличной от кодека программой, лучше всего Avisynth. На тяжкую долю кодека должен приходиться только собственно процесс кодирования, и ничего больше. Хотя бы потому, что в Avisynth мы можем выбирать и настраивать алгоритм всех этих операций.
В качестве исходника для сравнения кодеков я использовал мульт "По следам бременских музыкантов" Full HD.
Пишем скрипт:
LoadPlugin("ffms2.dll")
LoadPlugin("SplineResize.dll")
LoadPlugin("YCbCrChannelMixer.dll")
FFVideoSource("По следам.mkv", fpsnum=25000, fpsden=1000, seekmode=0)
AssumeFPS(25)
Spline144Resize(720, 576, 240, 0, -240, -0)
YCbCrChannelMixer(1., 0.0993116622408317, 0.191699549740832, -37.2494351336529, 0.989853808245085, -0.110652512296676, 15.4622341186036, -0.0724529613336014, 0.983397823259837, 11.3990576734419, 0, 255, 0, 255)
Про плагин YCbCrChannelMixer написано здесь:
[Для просмотра данной ссылки нужно зарегистрироваться]
Как видим, в этом скрипте есть обрезка чёрных полос слева и справа и ресайз до 720x576.
При первом открытии этого скрипта будет произведена индексация файла-исходника, что займёт какое-то время. Поэтому первый раз я бы рекомендовал открывать скрипт Виртуал Дабом. Заодно и посмотреть, всё ли в порядке.
Важно! Когда я писал о сжатии кодеком XViD, то я рекомендовал подавать на кодек видео в формате RGB. Мелочный покадровый просмотр показал, что XViD даёт более точное соответствие исходнику, если мы подадим на него RGB. С кодеком x264.exe всё обстоит с точностью до наоборот. Для получения наиболее точного соответствия оригиналу на вход x264.exe следует подавать видео именно в планарном формате YV12.
Большинство исходников находятся в планарном формате YV12. Если нам нужно провести какие-либо операции, например, деинтерлейсинг, ресайз, обрезку, удаление шума и т.д., то нужно стремиться проводить эти операции именно в формате YV12, без преобразования формата. Подавляющее большинство плагинов Avisynth работают именно с планарными форматами. Но если всё-таки нам почему-либо потребовалось преобразовать планарный формат в RGB, то перед подачей на x264.exe я очень рекомендую преобразовать его в YV12.
Немножко теории. Если подаваемое на x264.exe видео находится в формате, отличном от YV12, например, в RGB, то по умолчанию x264.exe вначале преобразует его в YV12 по алгоритму 601, потом будет сжимать. В процессе преобразования RGB в YV12 на некоторых участках изображения могут произойти искажения исходной геометрии. Незначительные, но всё-таки неприятно. Если мы подадим на вход YV12, то x264.exe сразу начнёт его сжимать. В этом случае никаких искажений геометрии не произойдёт.
Мы можем определённой опцией заставить x264.exe кодировать в RGB, но тогда объём возрастёт иногда раза в 2, а качество практически не улучшится. Поэтому будем считать, что кодирование по умолчанию в YV12 есть наилучший вариант.
Следует понимать, что если мы подали на вход кодера x264.exe изображение в формате YV12, то кодер будет его просто, не рассуждая, в упор, кодировать, не производя никаких преобразований форматов. Кодер не может знать, по какому алгоритму – 601 или 709 – закодирован пришедший к нему со стороны YV12. Он сразу же начнёт его, как он есть, сжимать в h264. Наш тестовый исходник после прохождения через YCbCrChannelMixer находится в 601. Поэтому при просмотре его нужно декодировать по 601. Если бы мы не вставили в скрипт YCbCrChannelMixer, то при просмотре нам нужно было бы декодировать по 709.
Таким образом, в любом случае, каким бы способом и (или) какой бы программой ты ни сжимал, следует обстряпать дело так, чтобы на вход x264.exe изображение подавалось в формате YV12. Все мои разработки с этого форума по конвертированию можно применить, как они есть, к x264.exe, с одной существенной разницей: в скриптах не должно быть ConvertToRGB24, а заканчиваться скрипт должен YCbCrChannelMixer.
Итак, предварительные операции завершены. Приступаем к кодированию.
Кодировать в h264 будем таким bat-файлом:
x264.exe -b 16 --b-adapt 2 --no-deblock -q 18 --ipratio 1 --pbratio 1 --no-psy --trellis 1 --no-fast-pskip --no-dct-decimate --deadzone-inter 0 --deadzone-intra 0 -m 9 --sar 4:3 -o wq.mkv ffmpeg.avs
pause
Объяснение опций:
-b 16 – задаёт максимальное количество B-кадров, которое кодер может пустить подряд. Установлено максимально возможное значение для данной опции. "Может" здесь не означает "обязан": в зависимости от содержания кадров кодер может пустить подряд от 0 до 16 кадров.
--b-adapt 2 – включение самого продвинутого алгоритма определения того, сколько же на самом деле нужно в каждом конкретном месте фильма пустить подряд B-кадров, чтобы получить наилучшее сжатие.
Опции -b 16 и --b-adapt 2 в совокупности дают уменьшение объёма конечного файла где-то в районе 1%, а время кодирования увеличивают раза в два. На качество полученного изображения не влияют. Так что их, в принципе, можно опустить.
--no-deblock – отключение деблокинга. Деблокинг мажет мелкие детали, и на этапе кодирования я рекомендую его всегда отключать.
-q 18 – включение кодирования на постоянном квантизёре = 18. Квантизёр 18 в h264 соответствует квантизёру 2 в XViD-е.
--ipratio 1 --pbratio 1 – заставляет кодировать P-кадры и B-кадры с тем же самым квантизёром, что и I-кадры. Одинаковый квантизёр для всех кадров – это для меня такая древнеегипетская святыня, которая не обсуждается. Очень рекомендую всегда делать именно так.
--no-psy – отключение всех психо визуальных прибамбасов. Мой добрый жреческий совет: всегда отключай все психо визуальные алгоритмы, что бы по этому поводу кто ни гнусавил. Психо визуальные алгоритмы искажают оригинальное изображение в угоду мелочной битрейтной экономии. Например, потери чёткости тонких прожилок растений вызваны этим вредоносным алгоритмом.
--trellis 1 – включение треллиса для макроблоков, как это и произошло бы по умолчанию. Макроблок – это кусок изображения размером 16x16 пикселей. Trellis равномерно размазывает имеющееся мелкое зерно и шумы по всему макроблоку. По сути, Trellis является, в некотором смысле слова, шумодавом. Притом весьма хорошим: не создаёт ни радужности, ни призраков. Особенно его действие заметно на тёмных зазернённых сценах. Исследуя эту функцию, я практически не нашёл таких полезных объектов, которые бы Trellis размазывал. Только зерно и шумы. Интересное наблюдение: с включённым Trellis размер тёмных средне зазернённых сцен получается раза в 2 меньше, чем без него. К слову, Trellis есть и в XViD. Но там он не работает с Custom-матрицами.
--no-fast-pskip – отключение ускорителя для кодирования P-кадров. Все мерзости, которые хоть на долю процента ухудшают качество, должны быть безжалостно отключены!
--no-dct-decimate – отключение коэффициента пороговой обработки для P-кадров. В руководствах пишется, что если эту функцию отключить, то увеличится размер конечного файла при незначительном улучшении видео. На каком месте растут глаза у тех, кто пишет о "незначительном улучшении"? Если эту функцию не отключать, то детализация ухудшится очень даже значительно. Это особенно заметно на чётких кадрах с большим разрешением. Однозначно отключаем.
--deadzone-inter 0 --deadzone-intra 0 – отключение ещё одной мерзости. Мёртвые зоны экономят чуть-чуть битрейта на мало изменяемых участках, ухудшая тем самым качество. На помойку!
-m 9 – улучшение полупиксельной точности. 9 означает продвинутый алгоритм для всех кадров. Включение этой опции слегка увеличивает соответствие закодированного кадра исходнику, в особенности на тёмных и туманных кадрах.
--sar 4:3 – задание соотношения сторон для конечного видео, подобно тому, как мы это делали при кодировании XViD-ом.
-o wq.mkv – имя выходного файла.
И заканчиваются опции именем входного файла, который пишется без всяких знаков. В нашем примере это скрипт ffmpeg.avs.
Есть ещё несколько опций, которые для процессора – надорвись, а реальное уменьшение объёма конечного файла от которых ничтожное. Например, -A all – разрешает кодеру производить дополнительный поиск всех допустимых размеров макроблоков, или --me esa – режим оценки движения "исчерпывающий". Я их не включил в командную строку, и тебе не рекомендую.
Поехали. Запускаем bat-файл, и спокойно ждём.
Вот сжатие завершено.
Теперь нам для сравнения нужно этот же самый поток кадров, выходящий со скрипта и находящийся в формате YV12, напрямую подать на XViD. Делаем это так. Открываем этот же самый скрипт в Виртуал Дабе. "Video" – точка у "Fast recompress". Задаём все параметры XViD-а, как описано в моей статье про кодирование в XViD. Кодируем. Конечно, при таком подходе на XViD мы подаём не RGB, а планарный YV12, но для объективности сделаем именно так. Тем более что для XViD разница при подаче на него RGB и YV12 на самом деле очень незначительна.
Сравниваем.
Если за базу сравнения взять XViD, то получаем экономию объёма 27%.
Если провести подобные исследования на фильмах, то получим экономию такого же порядка – 25-30%.
Ух ты, как здорово!
Теперь исследуем самый главный древнеегипетский параметр – качество, которое есть всё и по отношению к которому всё остальное есть ничто.
Вначале определимся с термином "исходник". Под исходником я понимаю изображение, подаваемое со скрипта на кодер. А не что-то другое. Открываем скрипт в Виртуал Дабе. Выходим на интересующий нас кадр. Сохраняем его в формате bmp. Это будет "Исходник.bmp".
Разжимаем полученный h264. Для получения объективной картины в декодере нужно отключить деблокинг и любую другую постобработку. В ffdshow это сделать элементарно. Получили кадр "h264 YV12.bmp".
Разжимаем файл avi, сжатый кодеком XViD. Тоже отключаем в декодере деблокинг. Этот файл нужно декодировать до RGB по алгоритму 601. Потому что на вход XViD-а мы подали YV12, закодированный по 601. Получили кадр "XViD.bmp".
Удалим из скрипта YCbCrChannelMixer, а на его место впишем ConvertToRGB24(matrix="rec709", interlaced=false)
Снова запустим кодирующий bat-файл. Получим h264 файл, в котором при кодировании видео было подано на кодер в формате RGB. Разжав этот файл, получим кадр "h264 RGB.bmp".
Начинаем сравнивать. Для получения объективного изображения в просмотровщике отключаем сглаживание.
Начинаем с кадра 7650. Видим, что в "h264 RGB.bmp" контуры огня под котлом слегка играют по отношению к исходнику. В кадре 7680 такая игра особенно заметна на платье принцессы. Этого вполне достаточно для подтверждения выдвинутого в начале статьи тезиса о том, что не следует подавать на вход кодера x264.exe видео в формате RGB. Больше с RGB экспериментировать не будем.
Сравниваем "h264 YV12.bmp" и "Исходник.bmp". У "h264 YV12.bmp" слегка меньше зерна на стенке котла, что даже лучше.
Теперь сравним "h264 YV12.bmp" и "XViD.bmp". Разница почти не заметна. Всё-таки XViD со жреческими настройками хорошая штука. Но всё же приглядимся внимательно. На туманных частях кадра 7850 – это где поверхность холма, и на тёмных кадрах, некоторая разница имеется. "h264 YV12.bmp" точнее соответствует "Исходник.bmp", чем "XViD.bmp".
Вот мы и получили долгожданный математически точный результат сравнения: при правильных – я подчёркиваю, при правильных! – настройках x264.exe получается видео, чуть более точно приближенное к исходнику, чем видео, сжатое XViD-ом. А объём h264-файла получается на 25-30% меньше, чем объём XViD-файла.
Данную тему можно считать реквиемом XViD-у. Так помянем XViD: хорошая была софтинушка. Бесплатная. Свою статью про качественное кодирование в XViD я не буду убирать с этого форума: пусть висит, как памятник.
В этой статье логически точно, без общих разглагольствований о "современном" и "устаревшем" софте было доказано превосходство одной программы над другой.
Предвижу, сравнение кодеков заинтересует многих, и могут появиться альтернативные варианты исследований. Форум = демократия. Во избежание лишней переписи: лично я буду отвечать только на те посты, в которых рассматриваются способы, позволяющие добраться абсолютно до всех настроек кодера. С удовольствием обсужу иные опции bat-файла, позволяющие достигнуть ещё лучшего качества.