265 кодек: K-Lite Codec Pack добавил поддержку x265 – x265 | All about modern codec

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

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

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

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

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

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

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

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

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

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

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

И для кодека 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 анимация использует сжатие, так что она не всецело отражает разницу, но все исходники будут размещены в самом низу статьи, и с ними может ознакомится любой желающий.

Нажмите на изображение чтобы открыть анимацию (2,6 МБ)

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

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

Видео состоит из 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 в стоке, на котором проводилось кодирование, поэтому говоря про скорость кодирования, она на «быстрых» пресетах идентичная и время заполнено в таблице ниже:

Время кодирования в формате «минуты:секунды»

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

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

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

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

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

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

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

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

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

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

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

Оценки качества кодирования по 10-ти бальной системе

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

Графики зависимости качество кодирования от пресета настроек кодирования

Стоит отметить, что пресеты для 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).

Соотношение качество/производительность. Зелёный треугольник — результат RTX 2070 в сравнении с i9 9900k

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

Соотношение качества/производительность. Зелёный треугольник — результат RTX 2070.

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

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

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

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

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

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

Видео на YouTube канале "Этот компьютер"

play

Стоит ли покупать самые бюджетные GTX 1650 Super?

play

InfoCAST #028 | Необычные устройства на CES 2020 и др. новости января

play

Устаревание видеокарт NVIDIA vs AMD Radeon

play

AMD RADEON | Драйвера 2016 vs 2020 | RX 470

play

Intel, AMD и Nvidia на CES 2020

play

Уточнение к видео про VRM (про работу даблеров)

play

Новости канала "Этот компьютер" и важные объявления.

play

Железные ожидания от 2020 года

play

InfoCAST #027 | Весь "железный" 2019 год в одном видео

play

VRM. Что такое, зачем? Фазы и цепи питания.

play

Архитектура Intel Sunny Cove (Ice Lake)

play

Микроархитектура Zen2

Первый видеокодек на машинном обучении кардинально превзошёл все существующие кодеки, в том числе H.265 и VP9


Примеры реконструкции фрагмента видео, сжатого разными кодеками с примерно одинаковым значением BPP (бит на пиксель). Сравнительные результаты тестирования см. под катом

Исследователи из компании WaveOne утверждают, что близки к революции в области видеокомпрессии. При обработке видео высокого разрешения 1080p их новый кодек на машинном обучении сжимает видео примерно на 20%лучше, чем самые современные традиционные видеокодеки, такие как H.265 и VP9. А на видео «стандартной чёткости» (SD/VGA, 640×480) разница достигает 60%.

Разработчики называют нынешние методы видеокомпрессии, которые реализованы в H.265 и VP9, «древними» по стандартам современных технологий: «За последние 20 лет основы существующих алгоритмов сжатия видео существенно не изменились, — пишут авторы научной работы во введении своей статьи. — Хотя они очень хорошо спроектированы и тщательно настроены, но остаются жёстко запрограммированными и как таковые не могут адаптироваться к растущему спросу и всё более разностороннему спектру применения видеоматериалов, куда входят обмен в социальные СМИ, обнаружение объектов, потоковое вещание виртуальной реальности и так далее».

Применение машинного обучения должно наконец перенести технологии видеокомпрессии в 21 век. Новый алгоритм сжатия значительно превосходит существующие видеокодеки. «Насколько нам известно, это первый метод машинного обучения, который показал такой результат», — говорят они.

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

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

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

Новый подход, который представили учёные, впервые использует машинное обучение для улучшения обоих этих методов сжатия. Так, при сжатии движения методы машинного обучения команды нашли новые избыточности на основе движения, которые обычные кодеки никогда не были в состоянии обнаружить, а тем более использовать. Например, поворот головы человека из фронтального вида в профиль всегда даёт аналогичный результат: «Традиционные кодеки не смогут предсказать профиль лица исходя из фронтального вида», — пишут авторы научной работы. Напротив, новый кодек изучает эти виды пространственно-временных шаблонов и использует их для прогнозирования будущих кадров.

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

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

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

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


Примеры реконструкции фрагмента, сжатого разными кодеками с примерно одинаковым значением BPP показывает заметное преимущество кодека WaveOne


Карты оптического потока H.265 (слева) и кодека WaveOne (справа) на одинаковом битрейте

Однако новый подход не лишен некоторых недостатков, отмечает издание MIT Technology Review. Пожалуй, главным недостатком является низкая вычислительная эффективность, то есть время, необходимое для кодирования и декодирования видео. На платформе Nvidia Tesla V100 и на видео VGA-размера новый декодер работает со средней скоростью около 10 кадров в секунду, а кодер и вовсе со скоростью около 2 кадров в секунду. Такие скорости просто невозможно применить в прямых видеотрансляциях, да и при офлайновом кодировании материалов новый кодер будет иметь весьма ограниченную сферу использования.

Более того, скорости декодера недостаточно даже для просмотра видеоролика, сжатого этим кодеком, на обычном персональном компьютере. То есть для просмотра этих видеороликов даже в минимальном качестве SD в данный момент требуется целый вычислительный кластер с несколькими графическими ускорителями. А для просмотра видео в качестве HD (1080p) понадобится целая компьютерная ферма.

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

Бенчмарки


В тестировании принимали участие все ведущие коммерческие кодеки HEVC/H.265, AVC/H.264, VP9 и HEVC HM 16.0 в эталонной реализации. Для первых трёх использовался Ffmpeg, а для последнего — официальная реализация. Все кодеки были максимально настроены, насколько позволили знания исследователей. Например, для удаления B-фреймов использовался H.264/5 с опцией bframes=0, в кодеке аналогичная процедура осуществлялась настройкой -auto-alt-ref 0 -lag-in-frames 0 и так далее. Для максимизации производительности на соответствие метрике MS-SSIM, естественно, кодеки запускались с флагом -ssim.

Все кодеки проверяли на стандартной базе видеороликов в форматах SD и HD, которые часто используются для оценки алгоритмов сжатия видео. Для SD-качества использовалась библиотека видео в разрешении VGA от e Consumer Digital Video Library (CDVL). Она содержит 34 видеоролика с общей длиной 15 650 кадров. Для HD использовался набор данных Xiph 1080p: 22 видеоролика общей длиной 11 680 кадров. Все видеоролики 1080p были обрезаны по центру до высоты 1024 (в данный подход нейросеть исследователей способна обрабатывать только измерения с размерностями, кратными 32 по каждой стороне).

Различные результаты тестирования показаны на диаграммах ниже:

  • средние значения MS-SSIM для всех видеороликов в наборе для каждого кодека;
  • сравнение размеров файла при усреднении значения MS-SSIM для всех кодеков;
  • влияние различных компонентов кодека WaveOne на качество сжатия (нижняя диаграмма).


Результаты тестирования на наборе видеороликов низкого разрешения (SD)


Результаты тестирования на наборе видеороликов высокого разрешения (HD)


Влияние различных компонентов кодека WaveOne на качество сжатия

Не стоит удивляться такому высокому уровню сжатия и кардинальному превосходству над традиционными видеокодеками. Данная работа во многом основана на предыдущих научных статьях, где описываются различные методы сжатия статичных изображений на базе машинного зрения. Все они намного превосходят по уровню и качеству сжатия традиционные алгоритмы. Например, см. работы G. Toderici, S. M. O’Malley, S. J. Hwang, D. Vincent, D. Minnen, S. Baluja, M. Covell, R. Sukthankar. Variable rate image compression with recurrent neural networks, 2015; G. Toderici, D. Vincent, N. Johnston, S. J. Hwang, D. Minnen, J. Shor, M. Covell. Full resolution image compression with recurrent neural networks, 2016; J. Balle, V. Laparra, E. P. Simoncelli. End-to-end optimized image compression, 2016; N. Johnston, D. Vincent, D. Minnen, M. Covell, S. Singh, T. Chinen, S. J. Hwang, J. Shor, G. Toderici. Improved lossy image compression with priming and spatially adaptive bit rates for recurrent networks, 2017 и другие. В этих работах показано, как обученные нейросети заново изобретают многие техники сжатия изображений, которые были изобретены человеком и раньше вручную прописывались для применения традиционными алгоритмами сжатия.

Прогресс в области ML-сжатия статических изображений неизбежно привёл к появлению первых видеокодеков, основанных на машинном обучении. С увеличением производительности графических ускорителей именно реализация видеокодеков стала первым кандидатом. До настоящего момента существовала только единственная попытка создать видеокодек на машинном обучении. Она описана в работе C.-Y. Wu, N. Singhal, and P. Krahenbuhl. Video compression through image interpolation, которая опубликована в ECCV (2018). Та система сначала кодирует ключевые кадры, а затем использует иерархическую интерполяцию кадров между ними. Она демонстрирует эффективность кодирования примерно как у традиционного кодека AVC/H.264. Как видим, сейчас исследователям удалось значительно превзойти это достижение.

Статья «Выученное сжатие видео» опубликована 16 ноября 2018 года на сайте препринтов arXiv.org (arXiv:1811.06981). Авторы научной работы — Орен Риппель (Oren Rippel), Санджей Наир (Sanjay Nair), Карисса Лью (Carissa Lew), Стив Брэнсон (Steve Branson), Александер Андерсон (Alexander G. Anderson), Любомир Бурдев (Lubomir Bourdev).



Лучший комментарий Stas911:
Altaisky: Статья про видеокодек и ни одного видео. Нечего было показать?
Stas911: Они ещё декодируют первый кадр. Проявите терпение.

Сравнение x265 и x264 для кодирования по заданному качеству CRF (02.2014)

Сравнивалось качество и скорость кодирования двух кодеков:
* x264 версия core 142 (64-бита, gcc)
* x265 версия 0.6+258 (64-бита, gcc)

Входные данные

Для сравнения использовался входной файл «1_CrowdRun_1080p25.yuv» из набора
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/
Разрешение файла 1920х1080 (FullHD) 25 кадров в секунду. Цветовое пространство YUV 4:2:0. Исходный размер файла 760 Мбайт. Ролик содержит всего 250 кадров.

Процесс сравнения

Файл кодировался на разных CRF от 15 до 30. Каждым из кодеков на разных пресетах. Дополнительные ключи не задавались.
Пресеты для кодирования x264: slower, veryslow, placebo
Пресеты для кодирования x265: medium, slow, slower, veryslow. (placebo не использовался из-за астрономического времени на кодирование)

Строчка для кодирования x264:
x264.exe --input-res 1920x1080 --fps 25 --level 4.1 --preset veryslow --crf 15 -o output.264 result.yuv

Строчка для кодирования x265:
x265.exe --input-res 1920x1080 --fps 25 --level 4.1 --preset veryslow --crf 15 --input-depth 8 --o output.hevc result.yuv

Далее измерялось время кодирования и размер выходного файла для каждого запуска.

Графики и таблицы сравнения

Время кодирования:
Подробная таблица (время кодирования в секундах, меньше лучше)

CRF x264 slower x264 veryslow x264 placebo x265 medium x265
slow
x265 slower x265 veryslow
15 86 117 234 159 249 1865 2790
16 80 114 221 158 243 1763 2634
17 74 102 214 149 235 1626 2437
18 68 94 202 146 232 1514 2304
19 65 89 191 135 218 1347 2057
20 60 86 181 125 203 1218 1863
21 56 76 172 115 192 1092 1689
22 53 71 163 109 181 976 1519
23 50 65 158 108 165 887 1387
24 46 61 151 101 162 813 1292
25 43 57 142 99 150 766 1223
26 40 55 140 92 148 756 1141
27 41 52 136 89 140 668 1058
28 37 50 128 87 137 616 1002
29 35 48 126 84 138 582 949
30 35 45 124 82 131 542 893

Размер файла (в байтах):
Подробная таблица (размер файла в байтах, меньше лучше)

CRF x264
slower
x264 veryslow x264 placebo x265 medium x265
slow
x265 slower x265 veryslow
15 101522180 98322238 98454048 88274724 92652594 85629715 85893115
16 87201610 84153321 84276669 76424310 80086971 73636295 73792032
17 74397615 71529541 71575680 65869119 68154675 62282396 62447838
18 63132654 60554101 60538386 56103534 57254828 52021685 52219113
19 53377996 51042367 51018164 47020395 46973227 42563037 42738755
20 44898840 42853079 42861909 39876377 39459522 35672061 35782799
21 37813482 36109833 36182195 33567197 32675539 29519116 29605900
22 32078403 30654724 30782369 28285038 27155876 24410097 24516145
23 27528735 26395066 26530552 23973363 22642812 20382010 20461329
24 23875254 22943666 23048636 20466459 18983059 17137993 17185619
25 20796190 19988388 20081942 17587743 16004565 14525220 14550284
26 18124475 17429621 17524443 14969665 13454918 12257475 12282829
27 15819902 15225342 15326830 12663043 11304791 10369316 10384867
28 13827338 13307218 13411572 10791089 9551058 8848979 8838106
29 12069990 11619505 11732465 9213056 8133832 7628134 7613975
30 10526933 10139473 10262268 7881534 6974773 6612335 6597796

Процент уменьшения размера файла по сравнению с x264 placebo для x265 veryslow (больше лучше)

Как видно процент уменьшения изменяется от 12 до 35, что весьма значительно. Кодек x265 работает эффективнее на высоких CRF.

Процент уменьшения размера файла по сравнению с x264 placebo для x265 medium (больше лучше)


Как видно процент уменьшения изменяется от 8 до 23, что тоже весьма впечатляет, так как время кодирования на настройках medium даже меньше чем у placebo x264 и лишь слегка уступает x264 veryslow.

Визуальное качество


Сравнение кусочка картинки (500×300) для разных CRF на x264 (placebo) и x265 (veryslow). Слева x264, справа x265. Цифры в углу обозначают значение CRF:

Как видно на низких CRF x265 гораздо сильнее мажет картинку. И там где на x264 ещё читаются номера на x265 это сделать уже затруднительно.

Кадр номер 100 для x264 и x265 на CRF=30:
x264:

x265:

Рекомендую открыть оба скриншота в браузере и переключаться между ними. Невооруженным взглядом видно, что качество у x265 намного хуже, чем у x264 для одного значения CRF.

Выводы и наблюдения

  1. Кодирование x265 на одном значении CRF дает размер файла меньше чем x264 (12-35% для veryslow)
  2. Кодирование x265 на пресетах veryslow и slower дает примерно одинаковый размер файла. Slower при этом иногда даже меньше, чем Veryslow. Считается при этом почти в два раза быстрее. Однако и тот и другой пресет серьезно проигрывают по времени счета x264 в десятки раз, даже когда x264 считает на placebo. На обработку одного кадра уходит 3-10 секунд.
  3. Кодирование x265 на пресетах slow и medium (дефолт) по скорости работает на уровне placebo от x264 и чуть быстрее. Размер файла также меньше чем у x264. Пресет medium работает лучше slow на маленьких CRF.
  4. В целом x265 дает меньший размер файла, чем x264 почти в любых случаях и его вполне можно использовать как замену x264, особенно на больших значениях CRF.
  5. К текущим недостаткам ещё можно отнести тот факт, что декодер x265 потребляет гораздо больше вычислительных ресурсов, чем декодер x264. И чем меньше CRF тем мощнее требуется компьютер. Например на CRF=15 мой ноутбук (Core i7) уже не тянет проигрывание видео в x265.

Важные вопросы требующие ответов

  1. Одинаково ли трактуется значение CRF в кодеках x264 и x265. Корректно ли сравнивать между собой файлы закодированные на одном CRF двумя этими кодеками? Судя по сравнению скриншотов сравнивать напрямую некорректно.
  2. Одинаковое ли визуальное качество у двух файлов с одним CRF, но закодированном на разных пресетах в рамках одного кодека? Ответ нужен и для x264 и для x265

Как кодировать видео? | x265

В данный момент идет активная разработка энкодера, но он все ещё находится в состоянии «бета»-версии. Работает медленно и не очень эффективно. Релизы новых версий выходят очень часто.

Что требуется?

Выберите один из методов:

  1. Скачайте исходники из официального репозитория и скомпилируйте энкодер x265.exe под свою систему.
  2. Скачайте одну из последних сборок x265.exe с нашего сайта.
  3. Используйте программу кодирования с графической оболочкой (см. конец страницы).

Использование энкодера x265 из командной строки

Энкодер берет на вход файлы в формате YUV или Y4M. Размер картинки (ширина и высота), а также частота кадров (FPS) должны быть заданы. Кодирование запускается с командной строки, по аналогии с x264. Кодировать можно с постоянным битрейтом (флаг —bitrate) или с постоянным качеством (флаг —crf). Пример для постоянного битрейта:

x265.exe input.yuv --input-res 1920x1080 --fps 50 --bitrate 14000 --input-depth 8 -o output.x265

Пример для постоянного качества:

x265.exe input.yuv --input-res 1920x1080 --fps 50 --crf 17 --input-depth 8 -o output.x265

На выходе будет файл в сыром формате x265: output.x265 Разработчики подготовили набор параметров для соотношений время/качество кодирования. Эти параметры задаются с помощью флага —preset. Полный список (от самого быстрого до самого медленного): ultrafast, faster, fast, medium, slow, veryslow, placebo. По умолчанию используется пресет ‘medium’. Пример для установки пресета:

x265.exe input.yuv --input-res 1920x1080 --fps 50 --crf 17 --input-depth 8 --preset veryslow -o output.x265

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

x265.exe input.y4m --q 17 --merange 64 --frames all --ref 4 --max-merge 3 --rect --hash 2 --me 3 --b 6 --b-adapt 1 --rd 2 --rc-lookahead 60 --input-depth 16 --tu-inter-depth=3 --tu-intra-depth=3 --no-tskip --no-tskip-fast --wpp --subme 2 --s 32 --F 6 --o video.hevc

Подробности можно посмотреть в документации здесь (PDF на английском).

Графические оболочки для легкого кодирования

Baka Encoder

Отправить ответ

avatar
  Подписаться  
Уведомление о