Pull to refresh

Легенды и мифы современных реализаций x265/HEVC или x264 vs x265 в сравнении скриншотов

Working with video *

Удивительно, но факт — стандарту сжатия видео High Efficiency Video Coding (HEVC) уже более трех лет. Существуют не только программные, но и аппаратные решения для кодирования и даже бытовые медиаплееры с поддержкой этого формата. Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки. Теоретически оно наверняка так и есть и я совершенно ничего не имею против самого стандарта, всей этой высшей математики, множественности профайлов и объективной оценки субъективного восприятия психофизиологических параметров с помощью PSNR. Побудительным мотивом для написания этой антинаучной статьи послужила чистая недоверчивость, желание самостоятельно пощупать имеющиеся на данный момент свободные реализации кодировщиков видео в этот формат (x265) и сравнить результаты со старым добрым x264.

Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe), не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством и не верю в магические двухкнопочные программы, которые могут «закодировать быстро и хорошо». Еще я не верю в демократию, антивирусы и современное высшее образование, но это уже чисто мои проблемы не имеющие отношения в кодированию видео :)
А теперь, зарядившись изрядной долей скептицизма возьмем один из скомпилированных вариантов свободного кодировщика x265, а точнее восьмибитовую GCC сборку 1.7+286 и все дальнейшие действия будем производить с ней.
В этом пункте, кстати, моя недоверчивость опять взбрыкнула и пришлось потратить около 6 часов для сравнения 11 разных сборок с разных сайтов чтобы ее успокоить. Оказалось что результаты кодирования с аналогичными параметрами были идентичны до степени смешения, а время кодирования отличалось не больше чем на 5-6 процентов.
Для начала, возьмем в качестве исходника упомянутый выше отрывок из Аватара брызги-дерево-туман и чтобы исключить тормоза декодера, сохраним 100 кадров и из него в виде несжатого YUV4MPEG2 файла, который в дальнейшем и будет кодироваться. В x265 по умолчанию применяется CRF метод сжатия с постоянным качеством, поэтому закодируем и в x264 тоже в режиме CRF с показателем качества 17.2. Цифра взята не с потолка, а опытным путем выяснено что любое увеличение этой цифры ведет к понижению и битрейта и качества картинки на выходе, а уменьшение только повышает битрейт без какого-либо заметного увеличения качества. Конечно же остальные параметры кодирования были тоже на максимуме и в результате получился сжатый файл с битрейтом 17.6 Mb/s (что почти в 2 раза ниже исходных 31 Mb/s на BD диске). Время кодирования 100 кадров — 40 секунд. Качество картинки получилось почти идентичным по сравнению с исходником и даже не стоит выкладывать сравнение. В дальнейшем мы будем сравнивать 12-й В-кадр файла x264-17.2.mkv с разными вариантами кодирования в HEVC.

x265 радует нас множеством готовых пресетов, но нас конечно же будет интересовать самый последний — placebo. На самом деле даже placebo не обеспечивает максимальные установки, но об этом чуть позже. По умолчанию x265 кодирует с показателем качества 28 (возможно в этом и есть глубокий смысл, но я его не уловил). С такими установками битрейт выходного файла получается менее 2 Mb/s (для 1080p) и вместо картинки на выходе такое мыло, что и смотреть невозможно и сравнивать смысла нет. Поэтому на первый раз ужесточим условия совсем немного и воспользуемся максимально короткой командной строкой
"E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m"  --crf 23 --preset placebo --output "E:\Video\avatar\x265-test1.mkv"
В результате у нас получится файл с битрейтом 5.4 Mb/s. Время кодирования чуть менее 7 минут. Качество в принципе не плохое, но пока до x264 далеко. На ссылке сравнение скриншотов общим весом около 6 Мб на сайте screenshotcomparison.com (виноват, но я не знаю другого удобного способа сравнивать скриншоты)

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

Попытка #2, crf 20, битрейт 9050 kb/s — лучше, но все равно не то


А вот тут пора вспомнить что пресет placebo использует далеко не самые максимально возможные параметры. Наиболее важные здесь --me star (при максимальном значении full) и --subme 5 (при максимальном 7). Попробуем ужесточить условия и вручную сказать
"E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m" --preset placebo --me full --subme 7 --psy-rd 0.5 --psy-rdoq 0.5 --output "E:\Video\avatar\x265-test1.mkv"
Сразу же становится понятным почему разработчики не рискнули вставить в «максимальный» профайл максимальные значения параметров. Время кодирования увеличилось более чем в 10 раз

И стоил ли результат этих жертв? не уверен…
Итак попытка #3, crf 20, -me full --subme 7, битрейт 9045 kb/s — 77 минут кодирования


И тут же сравнение результатов пресета placebo с вручную заданными -me full --subme 7


Выкидываем вручную заданные me, subme и ползем дальше.
Попытка #4, crf 18, битрейт 12922 kb/s — почти хорошо, но x264 пока лучше


Теперь посмотрим что будет если закодировать в x265 с тем же битрейтом что и x264 и с максимальными параметрами.
Этого же битрейта удалось достичь при значении crf 16.2. В этот раз кодирование заняло 90 минут.
Ссылка на файл

Результаты очень близки, но все же x264 сохранил чуть больше деталей и добавил чуть меньше мыла.
Вывод: Текущие реализации x265 проигрывают по качеству x264 на высоких битрейтах.

Вот мы и подошли к основному посылу всей статьи. Форматы сжатия видео вместе со всем остальным миром катятся в сторону упрощения и отупления населения. Никому не интересно иметь потребителя, который разглядывает скриншоты сравнений, борется за каждый лишний пиксель искажений, вчитывается в параметры кодирования и т.д. Все затачивается на максимально быстрые и смешные профайлы кодирования с минимальными битрейтами. Наверняка на низких битрейтах x265 будет иметь значительное преимущество над x264. Хотя и там и там будет масса искажений и мыла, но у x264 будет больше. Проверим.
Попытка #5, x265 5371 kb/s, x264 5374 kb/s


А вот и не отгадали :) Даже на родном для x265 битрейте x264 выглядит поприличнее.

Выводы делайте сами, а я с надеждой жду объективной критики :)
Tags:
Hubs:
Total votes 28: ↑17 and ↓11 +6
Views 66K
Comments 97
Comments Comments 97