Влияние пресетов кодирования x.264 и x.265 на качество видео

Видео-версия этой статьи

Зачем нам кодеки и почему есть разное качество кодирования

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

Для реализации этой идеи внедряются специальные алгоритмы (программы), называемые кодеками, которыми и совершается компрессия данных. Но, к сожалению, компрессия происходит с потерей информации, то есть после декомпрессии видео оно становится менее качественным, появляются разнообразные проблемы среди которых:

• Уменьшение цветов (более грубые градиенты)
• Усреднение соседних областей (потеря детализации и чёткости)
• Ухудшение качества движущихся объектов (разрывы на объектах, артефакты, нарушения границ объектов, смешение объектов с фоном)

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

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

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

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

Какие есть пресеты настроек

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

• Ultra Fast
• Super Fast
• Very Fast
• Faster
• Fast
• Medium
• Slow
• Slower
• Very Slow
• Placebo

Названия пресетов передают их суть. А если точнее характеризуют скорость кодирования видео. То есть пресет «Ultra Fast» позволяет кодировать видео ультрабыстро, «Slow» — кодировать медленно, а самый «прожорливый» — «Placebo» и вовсе придуман был просто «чтобы было» и чтобы показать, что такое качество тоже возможно, но возможность его реального применения — это скорее самовнушение, чем действительность.

С пресетами разобрались. Теперь надо разбираться с методикой тестирования и критериями и оценками качества.

Методика тестирования

И это сейчас самое важное. В целом — тестов пресетов кодеков и так много, но есть проблемы с методикой, а вернее с тем, что обычные методики не предполагают контроля того насколько сложная сцена. А именно сложность сцены влияет на качество кодирования.

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

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

Задача не тривиальная и, забегая вперёд, оценки будут субъективными, так как оценки я буду ставить… умозрительно, на основе визуальных дефектов. Тем не менее — даже чтобы глазами посмотреть на разницу эту разницу надо как-то сгенерировать и выбрать точные метрики для отслеживания качества.

Оценивать предлагаю по вот этому тестовому кадру:

В нём есть довольно много интересных мест, которые будут меняться при сжатии.

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

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

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

Видео состоит из 11 градаций изменений сложности кодирования от 0-ой, самой простой сложности, до 10-ой, самой сложной. При переходе на каждую следующую градацию в картинку добавляется 100 дополнительных фигур, таким образом на 0-ой сложности число фигур — 0, а на 10 сложности число фигур — 1000.

Однако говорить о строгой линейности прироста сложности я бы не стал. Фигуры пересекаются друг с другом и трудно судить — становится сложнее кодировать из-за этого или проще при увеличении числа фигур. Тем не менее — приращение энтропии близко к линейному.

Остаётся только учесть последний фактор — а именно то, что нельзя оставлять тестовую часть картинки статичной. При кодировании статические объекты лучше сохраняются неизменными, а мы хотим получить данные не по сохранению статических объектов при кодировании, мы хотим получить проявление дефектов в общем случае.

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

Итого у нас выходит 20 пресетов кодирования, по 10 на x.264 и x.265, и в каждом из 20 пресетов по 11 результатов тестирования по одному для каждого уровня сложности. То есть в сумме — 220 изображений. Ссылки на оригиналы находится в конце статьи.

Чтобы сжать видео первоначально было получено несжатое видео (55 секунд объёмом примерно в 20 ГБ) в Vegas Pro 15. Само видео я передать не могу в силу его размера, но проект видео в Vegas Pro можно скачать «тут«.

Далее это несжатое видео было сжато в программе MeGUI (скачать можно тут). Программа выполняет скрипт программы AviSynth, которую можно скачать тут. Самый простой скрипт будет если поместить видео и сам скрипт формата *.avs и программу MeGUI в одну папку и скрипт можно создать текстовым редактором (например блокнотом), вписав:

AVISource(«%Video_name%.avi»)
ConvertToYV12()

С соответствующими настройками кодирования с постоянным ограниченным битрейтом в 10 Мбит/с.

Результаты

Далее нам надо оценить результаты. И я хочу остановится на сложностях 6 и 10. Сложность 6 отражает довольно высокую нагрузку, реально достижимую в видео. Сложность 10 просто самая большая.

Нам необходимо заполнить таблицу:

Учитывая методику тестирования появляется одна проблема, связанная с объёмом видеофайла более 20 ГБ. С быстрыми кодированиями производительность ограничивалась скоростью чтения с SSD накопителя, а не Intel Core i9 9900k в стоке, на котором проводилось кодирование, поэтому говоря про скорость кодирования, она на «быстрых» пресетах идентичная и время заполнено в таблице ниже:

В виде графика эти данные выглядят так:

Видно, что время требующееся на сжатие — стремительно увеличивается с изменением пресета качества, по вертикали измерения в секундах.

Далее я дал субъективные оценки качества изображения для сложности 6 и сложности 10.

Приоритеты при оценке были следующими:

1. Сохранение форм и чёткости
2. Сохранение цветов, полутонов, градиентов
3. Отсутствие артефактов

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

Я дал оценки от 1 (наихудший результат) до 10 (неотличимый от оригинала) с градациями в 0,5 балла. Баллы выше 1 я ставил за удовлетворительный результат, оценку 1 я ставил за неудовлетворительный результат. То есть 1 балл — это не оценка качества, а отсутствие оценки (в сортах …. пиксельной каши не разбираюсь).

Оценки проводились для сложности 6 и 10.

Сложность сцены 6

Для сложности 6 результаты занесены в таблицу:

Эти же данные в виде графиков представлены ниже:

Стоит отметить, что пресеты для x.264 очень нелинейно прирощают качество. Между качествами Slower и Very Slow кодека x.264 находятся все результаты для x.265 кроме Ultra Fast. При этом до пресета Fast в x.264 я результаты счёл неудовлетворительными. В то время как пресеты Very Slow и Placebo на x.264 оказались лучшими по качеству, чем Very Slow и Placebo на x.265.

Также предлагаю провести расчёт удельного качества в зависимости от потраченного времени. Но предупреждаю, что я хоть и пытался оценивать качество линейно, но в реальности субъективной оценкой линейности не добиться, так что графики представленные ниже имеют примерный характер. Результаты для кодирования выполненного с ограничением в SSD не учитываются.

Чем величина по вертикали больше, тем выше показатель удельного качества. То есть оценивается оправданность временных затрат.

С точки зрения математики, при анализе субъективных оценок качества, наиболее выгодным является пресет настроек Medium кодека x.265. То есть пресет позволяет получить приемлемое качество с приемлемыми затратами производительности.

Также видно для x.265, что дальнейший рост времени кодирования плохо компенсирует возрастающее качество.

Для x.264 ситуация иная. Качество приростает примерно с той же «скоростью», что и затрачиваемое на кодирование время (за исключением Placebo).

Сложность сцены 10

Далее оценим аналогичные параметры для максимальной сложности видео.

На максимальной сложности нелинейность качества на x.264 становится ещё выше, и расслоение качества на x.265 так же становится больше. При этом стоит отметить, что для placebo x.265 я поставил оценку 7,5, что ниже, чем Very Slow для x.264.

Полученные изменения привели к тому, что при увеличении сложности самого видео ситуация с x.264 становится лучше, и пресет Slower позволяет добиться хорошего соотношения качества/производительности, но этот пресет всё равно не обходит по этому показателю Medium x.265.

Выводы

В тесте не затронут вопрос производительности в реальном времени, а именно этот параметр важен для стрима, где и применяется софтверное кодирование. В настоящее время для старших процессоров intel на сокете 1151 v.2 с одновременной игрой в саму игру — достижим пресет medium для кодека x.264. Для старших процессоров AMD на сокете AM4 достижим пресет Slow для кодека x.264. В реальных задачах (уровень сложности 6) разница между пресетами есть, и достаточно ли она велика для того чтобы на основе неё делать выбор для стримменогового компьютера — решать только вам. Также стоит сказать, что существенно более высокое качество видео способен обеспечить пресет Slower, но для работы с ним в 1080p 60 FPS в реальном времени процессоров пока нет.

Ещё стоит отметить существенно большую чёткость изображения на средних пресетах x.265 в сравнении с x.264. Изображение полученное с пресетом x.265 Ultra Fast сопоставимо с изображением с пресетом slow x.264.

x.265 Ultra Fast требует существенно меньших затрат ресурсов, но поддержки кодека x.265 популярными стриминговыми сервисами нет.

Гипотетически достижимый сейчас пресет medium x.265 для кодирования в реальном времени и стриминга обеспечивал бы существенно более качественную картинку, чем технически недостижимый сейчас x.264 Slower.

Всё вышеописанное справедливо только для софтверного кодирования которое имеет лучшие характеристики качества/битрейт. При использовании аппаратного ускорения и кодировании в h.264 и h.265, при возможности выбора динамического битрейта и более высоких значений среднего битрейта кодирование видеокартой будет существенно лучше по соотношению качества/производительности, но хуже по соотношению качество/битрейт.

Тем не менее для монтажа видео и его вывода не в масштабах реального времени целесообразно применять аппаратное кодирование.

Для сравнения в архиве с оригиналами сжатых видео находится видео полученное RTX 2070 с динамическим битрейтом и средним битрейтом в 20 Мб/с, с объёмом в 133 МБ, против 93 для Placebo h.264.

Кодирование видео заняло около 24 секунд и для 6-ой сложности получено качество ~8 баллов (примерно как x.265 medium и существенно лучше x.264 Slower).

Для 10-ой сложности качество при аппаратном кодировании RTX 2070 примерно соответствует x.265 Very Slow.

При этом производительность в кодировании/декодировании видео у видеокарт RTX 20** и GTX 16** (за исключением GTX 1650 не Super) — идентичная.

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

Ссылки для скачивания исходных файлов:

Проект для Vegas Pro для создания не сжатого видео: тут (12 МБ)

Стоп кадры из тестовых видео: тут (502 МБ) (упаковано в архив 7-zip)

Видео зарендеренные с разными пресетами кодеков: тут (1,76 ГБ) (упаковано в архив 7-zip)