CEO, Solveig Multimedia
0,0
рейтинг
11 января в 17:32

Сравнение HEVC кодеков от МГУ. Как улучшить результаты

В октябре 2015 был выпущен очередной отчет сравнения кодеков в ВМиК МГУ, на этот раз туда вошло несколько кодеков формата HEVC.

Исходной точкой к исследованию стало то, что мы заметили разницу в пресетах в тестах для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный с несколькими GOP. При этом для единственного описанного в открытом отчете файла “Apple Tree” кодер x264 оказался лучше x265 при быстром перекодированим на графиках зависимости SSIM от битрейта без учета скорости кодирования. Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить указанную картину.

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

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

О проекте



Задача кодирования видео при обработке мультимедиа, будь то передача, монтаж или редактирование, хранение, возникает постоянно как при разработке приложений и сервисов, так и при их настройке в момент использования. В силу большого количества популярных видеокодеков, даже зачастую одного типа, выбрать из них оптимальный, а затем задать правильные настройки, непросто. Вероятно, руководствуясь подобными соображениями, в лаборатории компьютерной графики и мультимедиа при факультете вычислительной математики и кибернетики (ВМиК) МГУ с 2000х ведется работа над проектом сравнения видеокодеков.

В октябре 2015 года был опубликован отчет сравнения кодеков, в котором участвуют некоторые кодеки формата HEVC, а так же несколько других, активно разрабатываемых в настоящее время. В качестве «эталонного» принят компрессор x264. Одним из интересных в отчете является компрессор x265, именно его изучением и займемся.
В качестве инструмента для анализа будем использовать SolveigMM Zond 265, анализатор файлов HEVC/H.265 и AVC/H.264.

image


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





Опишем методику. Сравнение в отчете проводится по критериям битрейт-качество (SSIM, PSNR)-скорость.Описанная в отчете методика для сравнения соотношения битрейт/метрика качества (пункт C.4) следующая.
Выбираем несколько значений битрейта (например, 7 значений: 1, 2, 4, 6, 8, 10 и 12 Mbps), для них считаем необходимые метрики качества для каждого кодека.

Отмечаем полученные значения на графике: метрика качества (ось абсцисс) – битрейт (ось ординат).

  1. Линейно интерполируем.
  2. Выбираем максимально большой диапазон, на котором все графики определены, и находим площади под всеми графиками на нем.
  3. В качестве меры качества определенного кодека (или пресета) берем отношение его площади к площади для эталонного кодека. Чем меньше полученное число, тем эффективнее кодек.

За эталонный выберем x265 с пресетом, выбранным в отчете (таблица 1). В отчете используется не последняя версия компрессора, ее можно найти здесь: x265 1.5+460-ac85c775620f. Однако при использовании последней версии принципиально ничего не меняется.
Используемые пресеты компрессоров указаны в таблице 1 (для платформы desktop).

Риппинг
x265 -p veryslow --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS%
Универсальное кодирование
x265 -p medium --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS%
Быстрое перекодирование
x265 -p ultrafast --ref 3 --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS%
Таблица 1. Настройки компрессора x265 отчета «MSU HEVC Video Codec Comparison»

Для получения рекомендаций модификации пресетов проводим тестирование всех настроек, из которых они состоят – какой вклад в качество и скорость вносит каждая составляющая. План здесь следующий.
  1. Кодируем файл, меняя каждый параметр пресета: от быстрого перекодирования к универсальному, от универсального к «риппингу». При этом сохраняем время кодирования.
  2. Вычисляем меру качества (как площадь, указанную выше) и относительное время кодирования (минимальное значение FPS кодирования для файла «пресет-измененный параметр» относительно всех выбранных значений битрейта).
  3. Из таблицы, состоящей из изменяемого параметра, меры качества, минимального FPS, выбираем параметры, которые можно использовать для улучшения пресетов.

Ограничимся параметрами пресетов для универсального кодирования и для «риппинга» (табл. 2), раскрывая параметры «-p medium» и «-p ultrafast». Добавим к ним еще два, упущенные в отчете: «--keyint -1 --tune ssim». Перечисленными параметрами будем дополнять пресеты для быстрого и универсального перекодирования соответственно.
Универсальное кодирование
--rc-lookahead 20 --scenecut 40 --ctu 64 --min-cu-size 8 --bframes 4 --b-adapt 2 --subme 1 --me hex --early-skip --sao --signhide --weightp --rd 3 --aq-strength 1.0 --aq-mode 1 --cutree --no-fast-intra
«Риппинг»
--weightb --amp --rect --rc-lookahead 40 --bframes 8 --tu-inter-depth 3 --tu-intra-depth 3 --rd 6 --rdoq 2 --psy-rdoq 1.0 --subme 4 --max-merge 4 --me star --ref 5 --b-intra --lookahead-slices 0
Таблица 2. Параметры-кандидаты на модификацию пресетов отчета «MSU HEVC Video Codec Comparison»


Тестирование



Ссылка для скачивания тестовой последовательности «Apple Tree» (рис. 1), используемой в бесплатной версии отчета, не указана. Выберем аналогичную, используя ее ключевую особенность – крупный план, большое количество мелких деталей. Например «big_buck_bunny_1080p_h264.mov», интервал в 338 кадров с 24 секунды:

ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 00:00:24 -frames:v 338 -c:v rawvideo -pix_fmt yuv420p sample.yuv

image
Рисунок 1. Характеристика последовательности «Apple Tree»

Для того чтобы при реализации трех шагов плана, указанного выше, не тратить много времени на выписывание необходимых чисел из интерфейса Zond 265, удобно использовать его возможность работы в командной строке (таблица 3):
zond265_x64 %COMPRESSED_FILE% -iref %REFERENCE_420P_FILE% -nowait -report t=quality,statstream qm=SSIM o=%TARGET_CSV_FILE%
Список всех параметров, а также их подробное описание можно посмотреть на странице документации Zond 265.

Параметр
Описание
-iref
Задание референсного YUV файла
-report
Указание режима работы Zond 265 в командной строке
t=quality,statstream
Здесь выбрана генерация двух отчетов: качества и статистики о видеопотоке
qm=SSIM
Метрика качества для вычисления
o
Путь до файла отчета в формате CSV
-nowait
Без пауз, Zond 265 должен сам переходить от файла к файлу без задержек
Таблица 3. Параметры Zond 265 командной строки, необходимые для составления скрипта

Вот два скрипта для Python 2.7: один для кодирования 266 файлов (20 настроек для первого, 18 настроек для второго пресета, для 7 значений битрейта: 1, 2, 4, 6, 8, 10, 12 Mbps), второй для составления отчета в формате CSV (файл – отношение FPS кодирования к эталонной конфигурации – отношение метрики SSIM к эталонной конфигурации).
Как видно из таблиц отчетов для фрагмента файла «big_buck_bunny_1080p_h264.mov» (таблицы 5 и 6), модифицировать конфигурации можно, например, так, как указано в таблице 4. Напомним, для улучшения эффективности значение «Мера качества» должно быть меньше единицы, а значение «Относительное время кодирования» – больше единицы.
Тест выполнен на компьютере следующей конфигурации: Intel Core i7-2600@3.4 GHz, 16 GB RAM. Наибольшее улучшение качества дает параметр «--min-cu-size 8» для конфигурации быстрого кодирования, для универсального кодирования – параметр «--rdoq-level 2» (но он же более всего замедляет кодирование).

Быстрое перекодирование
x265 -p ultrafast --ref 3 --rc-lookahead 20 --min-cu-size 8 --bframes 4 --early-skip --cutree --tune ssim --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS%
Универсальное кодирование
x265 -p medium --weightb --bframes 8 --tu-intra-depth 3 --psy-rdoq 1.0 --b-intra --lookahead-slices 0 --tune ssim --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS%
Таблица 4. Модификация пресетов отчета «MSU HEVC Video Codec Comparison» для увеличения эффективности кодирования при той же скорости кодирования

Таблица 5. Отчет о модификации пресета быстрого перекодирования
image
Таблица 5. Отчет о модификации пресета быстрого перекодирования


Таблица 6. Отчет о модификации пресета универсального кодирования
image
Таблица 6. Отчет о модификации пресета универсального кодирования


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

Конфигурация
Мера качества
Относительное время кодирования
Быстрое перекодирование (эталон)
1
1
Быстрое перекодирование, модифицированное
0.69
0.97
Универсальное перекодирование (эталон)
1
1
Универсальное перекодирование, модифицированное
0.85
0.94
Таблица 7. Эффективность кодирования с использованием измененных пресетов относительно пресетов отчета «MSU HEVC Video Codec Comparison»

Попробуем взглянуть, на что повлияло изменение опций – откроем в Zond 265 файл, закодированный измененным пресетом при быстром перекодировании для битрейта 8 Mbps и сравним его с файлом, закодированным неизмененным пресетом. Размер максимального блока кодирования остался прежним, и равен 32x32 (область «--ctu 32»). Но размер минимального блока уменьшился с 16 до 8 (область «--min-cu-size 8»), именно этот параметр дал наибольшее увеличение качества. Увеличилось число B-кадров с 3 до 4 (область «--bframes 4»), но при этом увеличилось и максимальное число «референсных» кадров (область «--ref 4»). Областью «SSIM» выделены максимальные значения графиков SSIM/PSNR для трех компонент: яркости (Luma) и двух компонент цветности (Cb, Cr). Они увеличились с 0.9623-0.9966 до 0.9771-0.9991. Оставшиеся дополнительные параметры (--rc-lookahead 20 --early-skip --cutree) влияют на алгоритм кодирования, а не на тип получившегося видео, это отражается, главным образом, на скорости кодирования (см. табл. 5). Надо отметить, визуально картинка декодированного кадра изменилась – артефакты кодирования теперь не видно.

image
Рисунок 2. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией быстрого кодирования

Аналогично можно проверить параметры закодированного файла с измененным и неизмененным пресетом универсального кодирования (рисунок 3). Размер минимальных разбиений TU не изменился и остался равным 4x4 (область «--tu-intra-depth 3»), количество B-кадров осталось неизменным и равно 3 (область «--bframes 3»). SSIM увеличился с 0.9789-0.9994 до 0.9811-0.9992. По сравнению с конфигурацией быстрого перекодирования увеличился размер максимального блока, стал равным 64x64 (область «--ctu 64»), добавился SAO фильтр (область «--sao»).

image
Рисунок 3. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией универсального кодирования

Таким образом, на основе проведенного тестирования предложен список опций для улучшения эффективности кодирования (улучшение значения метрики SSIM при том же битрейте и скорости кодирования) для конфигураций быстрого и универсального кодирования. С использованием предложенных изменений для файла с большим количеством мелких деталей, значение интегральной «меры качества» отчета «MSU HEVC Video Codec Comparison» при быстром перекидировании улучшилось на 31%, а при универсальном – на 15%, при этом скорость кодирования изменилась несущественно. Т.к. тестирование проведено для каждой опции отдельно, то на практике можно выбирать и использовать лишь некоторые удобные опции, а не весь предложенный список.

Ссылки



  1. HEVC Video Codecs Comparison
  2. Blender Foundation | www.blender.org
  3. Zond 265 home page
@DmitryVergeles
карма
8,0
рейтинг 0,0
CEO, Solveig Multimedia
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (11)

  • 0
    Надо отметить, визуально картинка декодированного кадра изменилась – артефакты кодирования теперь не видно.
    А помоему наоборот, стало только хуже (обратите внимание на траву рядом с корнями дерева, она стала более размытой):
    ultrafast.265: https://habrastorage.org/files/882/274/084/8822740841fb44d9946d200e41a0e851.png
    ultrafast_corrected.265: https://habrastorage.org/files/fc7/2d2/0c4/fc72d20c49cc4e97922a97451534e223.png
    Главное всё-таки это не SSIM, а визуальное качество.
    • 0
      Здравствуйте stepik777б

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

      dl.dropboxusercontent.com/u/102689788/original-ultrafast-8MBit-frame3.png
      dl.dropboxusercontent.com/u/102689788/corrected-ultrafast-8MBit-frame3.png

      Относительно SSIM, мы придерживались методики, указанной в открытом отчете, а там все опирается на вычисление этой метрики.
      • 0
        Когда-то давно — больше 10 лет назад — было очень модно показывать пары кадров в качестве аргумента, что один кодек лучше другого. При этом в подавляющем большинстве кодеков по целому ряду причин в смысле качества идут колебательные процессы и найти пары кадров, где кодек А лучше кодека Б (и наоборот, особенно если они примерно равны) обычно не очень сложно даже вручную.

        В итоге мы просто включили в качестве стандартной опции в наш MSU Video Quality Measurement Tool сравнительный анализ двух файлов с оригиналом, который позволял автоматически выдавать на двух сжатых последовательностях 10 кадров, на которых кодек А, сильнее всего выигрывает у кодека Б (и наоборот).

        Народ тогда вволю повеселился, помнится )))

        При этом субъективные тесты (когда, например, люди вслепую голосуют какая последовательность лучше) MSU (как и многие) также уже много лет проводит. Просто они сложнее, дороже и меньше последовательность аккуратно сравнить позволяют.

  • +1
    Коллеги!

    Наверное все-таки не очень корректно так сравнивать.

    У MSU:
    • Все пресеты предоставляют авторы кодеков, все кодеки выравниваются по скорости на заранее заявленном железе.
    • Всего используется 21 последовательность.
    • Сравнение проводится больше 10 лет и основная интрига в том, что часть последовательностей меняется с прошлого года, причем новые последовательности неизвестны авторам кодеков, т.е. принимаются меры, чтобы авторы не затачивали пресеты под конкретные последовательности

    У вас одна последовательность, на которой вы руками подобрали лучшие параметры.

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

    А теперь внимание, вопрос: А можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?

    Ибо вот это реально будет интересно и полезно! ) И авторы спасибо скажут. Даже если 3-5% будет — это будет круто.

    Привет Элекарду и Томску! )
    • 0
      Здравствуйте 3Dvideo,

      Прошу прощения за медленный ответ.

      Выравнивание по скорости мы учли. Относительно того, что использовали одну последовательность, исходной точкой к исследованию было то, что мы заметили разницу в профилях для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный и с двумя GOP.

      Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить картину, указанную в открытом отчете для исследуемого файла (несколько удивило, что при быстром перекодировании x264 оказался лучше x265 — на графике в открытом отчете для зависимости SSIM от битрейта без учета времени). Выбранный нами фрагмент похож (как нам кажется) на описание файла открытого отчета, и графики для него получаются похожими на те, что указаны, поэтому можно считать аналогом.

      Результат для совокупности файлов может оказаться другим, но, как минимум, для этого файла указание нескольких упомянутых опций (типа «keyint» и «tunessim») способно реабилитировать x265.

      К сожалению у нас не было доступа к последовательностям из тестов
      • 0
        Похоже я плохо пояснил.

        Представьте себя автором кодека. В принципе можно заточиться под последовательности этого года, но в следующем они сменятся, причем неизвестным образом. Может слабо, как в прошлом году, а может сильно как в поза-позапрошлом. И вам нужно выдать пресет не зная, какие последовательности будут в тесте.

        А идут авторы кодеков на это, поскольку такой тест очень близок к тестам, которые все равно (пусть часто менее масштабно, чем мы) делают те, кто кодеки покупает (оптом и дорого ;). И в реальной работе критично, чтобы кодек (в отведенных рамках) быстро и эффективно адаптировался под неизвестные последовательности. Т.е. слепой тест ближе к реальности и реально стимулирует улучшение кодека. Тем более, что оно реально всегда возможно.

        А заточиться под известную последовательность, да еще одну, да еще специфическую… Именно поэтому безмерно актуален заданный выше вопрос: можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?

        И это будет интересно всем, именно если последовательности будут достаточно разнородны, настолько, что результат будет воспроизведется на другом (неизвестном вам) наборе последовательностей. И в такой постановке даже 3-5% стабильного улучшения — это очень круто. И это путь, по которому ежегодно улучшают работу кодеков (ускоряя куски кода, улучшая адаптивность rate control и т.д.).

        P.S. И к слову о последовательности. Почему вы ссылаетесь на А.1 «Apple Tree», вам последовательность A.2 “Bunny” ничего не напоминает? :))) compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf#subsection.a.A.2 Из каких соображений вы взяли как аналог самую короткую последовательность отчета, при том, что следующая за ней — фактически та самая?

        • 0
          спасибо за критику. видоизменили вступление

          Исходной точкой к исследованию стало то, что мы заметили разницу в пресетах в тестах для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный с несколькими GOP. При этом для единственного описанного в открытом отчете файла “Apple Tree” кодер x264 оказался лучше x265 при быстром перекодированим на графиках зависимости SSIM от битрейта без учета скорости кодирования. Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить указанную картину.

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

          Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования. Однако их можно рекомендовать как отправную точку при поиске возможностей увеличения эффективности кодирования x265.
  • 0
    Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования.
    В таком случае, надеюсь, вы понимаете, что минимально грамотный человек при желании может взять ваш «улучшающий» пресет и показать, как на «аналогичных» последовательностях он будет, например, в полтора-два раза просаживать показатели. Найти такие последовательности будет реально не так сложно. Тем более вы все скрипты выложили. ;-)))

    И дальше вы все равно вернетесь к основному вопросу, над которым плотно годами работают авторы кодеков: Как улучшить показатели без заточки на широком наборе последовательностей, т.ч. вслепую.

    И по поводу «реабилитации х265», как вашей основной цели. Надо сказать, что в принципе ситуация, когда кодек старого стандарта оказывается лучше нового — это нормально. В истории много раз бывало, что на отдельных примерах MPEG-1 был лучше MPEG-2, MPEG-2 был лучше MPEG-4, MPEG-4 лучше H.264. Тем более на относительно молодых реализациях, которые только-только падать перестали. Десять лет назад мы рапортовали пачками баги в сырых реализациях Н.264 разных авторов, сейчас та же самая картина у HECV. Это скоро пройдет, за счет реального улучшения кодеков (х264, например, очень хорошо подрос за 10 лет).
  • 0
    так мы же не против, для этого все и выложили в открытый доступ )
    Случаи бывали разные, согласен. но это не тот случай, как мы считаем.

    Вот, кстати соответствующая статья, на нужном количестве стримов. Жаль не наша :)
    www.bbc.co.uk/rd/blog/2016/01/h-dot-265-slash-hevc-vs-h-dot-264-slash-avc-50-percent-bit-rate-savings-verified
    • 0
      но это не тот случай, как мы считаем
      А зря. Обратите внимание, что по нашим замерам x265 пока в среднем заметно хуже, чем х264 на 20 последовательностях. Там работа явно только начата.

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

      Вот, кстати соответствующая статья, на нужном количестве стримов. Жаль не наша :)
      Читал. Там «папа» HEVC в авторах, они лучше, чем то-либо знали на чем и как гонять. И у них, обратите внимание, вообще не учитывается время, т.е. в этом плане довольно академический результат. При этом они получили 44% улучшения по PSNR (и 59% — MOS).

      Впрочем приоткрывая тайну ) скажу, что у мы скоро опубликуем сравнение HEVC кодеков на 4K последовательностях (на которых HEVC конкурировать заметно легче). На них по нашим замерам у лучшего HEVC кодека 45% улучшения (почти как у процитированных вами товарищей), при том, что он БЫСТРЕЕ х264. А вот это уже для индустрии реально очень интересно и мега-круто.

      PS Имейте ввиду, что если просто отвечаете, а не в ответ мне, мне ваш ответ не приходит (тут надо приноровиться к интерфейсу). Случайно увидел.
    • 0
      Случаи бывали разные, согласен. но это не тот случай, как мы считаем.
      Из свежего, что назвывается ). Вчера общался с коллегаим из Рутьюба. Они протестировали х265 (сами независимо), увидели, что он значительно хуже х264, пришли в ужас насколько и решили тему HEVC вообще закрыть на какое-то время. В общем-то я им сказал ровно то же самое, что и вам — дайте авторам время. Но не в этом дело — там было конкретное разочарование вообще в HEVC (особенно учитывая его проблемы с отчислениями), на фоне завышенных ожиданий от прочитанных фонфарных откликов.

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

      Вот такие свежие впечатления.

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