Сравнение технологий аппаратного транскодирования
Можно ли чем-то заменить NVIDIA? Если уж не для нейросетей, то для транскодирования видео, которое в медиапроизводстве занимает очень значительное место и требует больших вычислительных ресурсов.
В этой статье попытаемся выяснить, есть ли у аппаратной платформы NVIDIA альтернативы в задачах обработки и кодирования видео, и можно ли её заменить чем-то более доступным во всех смыслах: и по возможности закупки на рынке РФ, и по цене.
Меня зовут Дмитрий Митяев, я почти 30 лет в IT, работал в области авиастроения, занимался анализом качества видеокодирования в NVIDIA, продолжаю интересоваться этим и сейчас — в RUTUBE TECH. В этой статье покажу результаты сравнения качества кодирования видео на различных аппаратных платформах: CPU, GPU NVIDIA, Intel, Mac и Rockchip.
Этот анализ будет полезен, если вы, как и мы, исследуете, на что можно заменить NVIDIA, чтобы оптимизировать затраты на железо и нивелировать риски, связанные с недоступностью определенных карт. Если такая задача вам пока не актуальна, то, возможно, вам будет любопытно узнать о метриках сравнения относительно субъективного параметра «качество» видео и способах тестирования кодеков. Пригодится для стримингов, кинотеатров, видеохостингов или домашней лаборатории.
Основные понятия и теоретическая база
Под процессом кодирования видео подразумевается сжатие видеопотока с определёнными параметрами. Например, для того, чтобы сделать архивное видео используются одни параметры — можно сжимать подольше, но с большим качеством. Чтобы транслировать игру, нужна меньшая нагрузка на систему, быстрое кодирование и допустимый ущерб качеству. В зависимости от используемых параметров результирующее видео может отличаться по объёму в десятки раз.
Кодек — это реализация спецификации алгоритма сжатия, а также, что немаловажно, спецификации алгоритма декодирования, то есть раскодирования сжатого потока в формат, подходящий для отображения. Разные реализации одного и того же стандарта, вообще говоря, при декодировании должны давать бинарно одинаковые кадры.
Основные стандарты и их реализации:
Стандарт | Реализации (библиотеки) |
H.264 | x264, NVENC H264, RKMPP H264, QSV, Videotoolbox |
HEVC | x265, NVENC HEVC, RKMPP HEVC, QSV HEVC |
VP8/VP9 | libvpx |
AV1 | libaom, svtav1, Rav1e, Dav1d (декодирование) |
H.266 | Uvg266, Fraunhofer VVEnc, x266 |
В рамках данного исследования мы ограничимся H.264 — достаточно старым, но по-прежнему популярным стандартом, который занимает значительную часть рынка и поддерживается максимальным количеством устройств.
Библиотека может быть написана как только для процессора, так и под разнообразное железо: видеокарты, специализированные карты FPGA (программируемые матрицы), ASIC (специализированные микросхемы). Например, в аппаратных комплексах видеофиксации могут быть свои реализации, оптимизированные конкретно под задачи хранения видео с камер наблюдения.
Библиотеки под процессоры обычно выигрывают по качеству кодирования, так как имеют больше степеней свободы и возможностей оптимизации. При неограниченном бюджете и наличии множества серверов, которые можно занять видеокодированием, в общем случае по качеству лучшим вариантом будет libx264. Однако аппаратные реализации как правило дают лучшие результаты по соотношению цена-качество, плотности упаковки в датацентре, энергопотреблении. Какие из них будут выгоднее в каком случае, мы как раз и хотим выяснить.
В сравнении мы не рассматриваем решения на базе ASIC и FPGA (Netint и Xilinx) по причине их практической недоступности и относительно высокой стоимости. То же самое касается Apple M4 — на сегодняшний день его стоимость приближается к картам NVIDIA, хотя и есть ожидания, что по качеству картинки новый кодек будет лучше, чем M2, и скорее всего в будущем мы сделаем новое исследование и опубликуем его результаты.
Метрики качества
Чтобы сравнить разные способы кодирования, нам нужно оценить качество перекодированного видео, и сопоставить затраченные на это ресурсы: производительность, цену самого оборудования, размер видео и т.д. Но как минимум, нужна методика оценки качества видео.
Методы оценки качества видео делятся на методы с использованием оригинала и без. В первом случае у нас есть исходное видео, которое мы сжимали с определёнными параметрами, и мы можем сравнивать с ним полученный результат. Во втором — просто набор готовых кадров, качество которых необходимо оценить по каким-то эвристическим методикам. Последние сейчас в основном реализуются с помощью моделей машинного обучения, самые заметные из них: NR-VMAF, NIQE, PIQE, BRISQUE. Методы без оригинала в рамках данной статьи мы рассматривать не будем.
Среди методов с оригиналом самое большое распространение получили: VMAF, PSNR, SSIM и их производные, созданные под решение конкретных проблем присущих стандартным реализациям. Реже используется CIEDE2000 — цветовая дистанция между сравниваемыми кадрами. В рамках исследования использовались различные методы оценки качества, как правило результаты валидировались по нескольким метрикам. Рассмотрим, каждую из них.
PSNR — пиковое соотношение сигнал/шум. Размерность — дБ.
где — максимальное значение уровня сигнала. В случае 8-битного кодирования видео
PSNR показывает, какое количество шума внесено кодеком при сжатии видео. Фактически представляет собой среднеквадратическую ошибку: берутся два кадра (из оригинала и получившегося видео) и попиксельно вычитается одно значение из другого, возводится в квадрат и делится на количество пикселей в кадре. Конечно, берутся значения по каналам. В зависимости от формата кодирования пикселя при усреднении используются веса по каналам. Например, для yuv444 у каждого канала вес –1, так как количество кодируемой информации в каждом канале (плоскости, если говорить о структуре хранения информации по кадру) одинаковое — используется одинаковое количество бит. А вот для yuv420 под яркостный канал отводится большее количество бит и вес при усреднении больше, чем у каналов цветности (подробнее с кодированием пикселей можно ознакомится, например, в этой статье на википедии).
Например, так выглядит фрагмент кода для подсчёта среднеквадратической ошибки по плоскостям в реализации фильтра PSNR в FFMPEG:
...
for (int c = 0; c < s->nb_components; c++)
mse += comp_mse[c] * s->planeweight[c];
SSIM — показывает, насколько структурно один кадр близок к другому.
Фактически это корреляция между двумя случайными величинами (между средними значениями окон сравниваемых кадров).
— средние значения окон X и Y,
— дисперсия значений окон X и Y,
— ковариационный момент значений окон X и Y,
— коэффициенты для балансирования отношения.
VMAF — метрика качества, разработанная Netflix.
Основная цель VMAF — оценить качество видео максимально приближенно к субъективной, человеческой оценке. Она состоит из трёх компонент:
Visual Information Fidelity (VIF) — степень искажения;
Detail Loss Metric (DLM) — степень потери деталей;
Mean Co-Located Pixel Difference (MCPD) — степень разницы между кадрами.
Выход из трёх компонент загоняется в регрессионную модель. В поставке входят уже обученные модели для разных размеров кадров. При необходимости можно обучить модель на своих видео.
Работает гораздо дольше, чем более простые с вычислительной точки зрения PSNR или SSIM, но есть реализация на GPU.
Сравнение на диапазоне битрейтов — RD-Curves
Для корректного сравнения, конечно, недостаточно просто закодировать два видео и получить финальную метрику качества. Необходимо рассматривать как разные сцены, так и разные битрейты. А для полной картины — диапазон битрейтов, для того, чтобы определить поведение кодека на интересующем диапазоне. Ведь обычно, конечный пользователь в течение просмотра может получать видео с разным битрейтом в зависимости от пропускной способности сети в данный конкретный момент.
Предположим, что мы уже провели кодирование исходного видео в разные битрейты с помощью программной реализации x264 и одной из аппаратных платформ и нарисовали две кривые, проходящие через точки, полученные после подсчёта качества с помощью VMAF.
Если вы уже работали с кривыми RD, то скорее всего обратили внимание, что график перевёрнут: по оси X — качество, по оси Y — битрейт. Обычно графики строят относительно битрейта (по оси X) и смотрят на качество при фиксированном битрейте. Однако у нас обратная задача: определить, какое количество битрейта тратит тот или кодек для кодирования с определённым качеством. Чтобы не поворачивать голову и не подвергать шейные позвонки риску, перевернём сам график. На нём более высокая кривая означает, что кодеку необходимо больше битрейта для получения того же качества.
Визуальная оценка — это хорошо и наглядно. Но что можно сделать, чтобы получить объективные числа для сравнения? Например, первое, что приходит на ум — значения на границах измеряемого диапазона качества. Это даст представление о разнице реализаций в самом худшем качестве и в самом лучшем. Значения на границах: 20,6% и 25,9%. Но, пожалуй, объективного представления о разнице два числа не дадут — на всём диапазоне могут быть совсем иные соотношения. Посмотрим ближе к середине: при значении VMAF = 65 разница между двумя способами кодирования составляет 29,4%. при значении 80 — 30,1%. И так далее — можно до бесконечности добавлять отношения на интересующих точках.
Чтобы перевести этот набор значений в разных точках в один показатель, используем подход Bjontegaard Delta Bitrate (BD-BR), предложенный в 2001 году норвежским учёным Йисле Бьонтегором (Gisle Bjontegaard).
По сути это отношение площадей под этими кривыми, рассчитывается следующим образом:
Для каждого набора точек конкретного кодека используем полином для получения функции, описывающей поведение этой кривой.
Интегрируем на общем отрезке, т.е. получаем площадь под каждой кривой.
Вычисляем отношение между этими площадями.
Метод даёт ответ на вопрос, во сколько раз битрейт одного кодека должен отличается от другого при кодировании с одинаковым качеством. Таким образом, если, например, в маркетинговом проспекте написано, что AV1 на 30% лучше, чем HEVC, то это значит, что кодеку AV1 нужно на 30% меньше битрейта для достижения такого же качества (оценённого по какой-либо методологии).
В этом примере мы использовали метрику VMAF, но, очевидно, что под капотом может быть любая другая метрика, которую мы сочтём показательной для нашей задачи.
Метод Бьонтегора не лишён недостатков. Он хорошо работает, когда функция зависимости битрейта от качества монотонно возрастает. Если же на графике много выбросов, то метод не даст адекватных результатов. Чтобы с этим справиться, можно дополнительно поработать с данными. Например, команда лаборатории компьютерной графики и мультимедиа при факультете ВМК МГУ (проект compression.ru) использует метод BSQ-Rate. Однако в целом вопрос, нужно ли «лечить» некорректные данные, на мой взгляд, дискуссионный. Если кодек при увеличении битрейта не даёт возрастающие величины качества, то насколько можно вообще оценить его качество? Ведь он фактически работает непредсказуемо.
Условия измерений
Для сравнительного анализа использовались следующие платформы:
libx264 (CPU) в качестве эталона;
Orange Pi 5 Plus, Rockchip RK3588, кодек RKMPP, цена ≈ 12 000 ₽;
Intel N100, кодек QSV, цена ≈ 18 000 ₽;
Mac Mini, кодек Videotoolbox, цена ≈ 30 000 ₽;
NVIDIA RTX A4000, кодек NVENC, цена ≈ 120 000 ₽.
В качестве тестовых образцов мы выбрали 21 видео, в которых присутствуют разные особенности, например, большое количество деталей, быстродвижущиеся объекты, контрастные или наоборот очень близкие цвета и т. д. Исходные видео в разрешении 4K перекодировались в 8 меньших размеров кадров по 10 вариантов битрейтов, равномерно распределённых внутри характерного для данного разрешения отрезка.
Размер кадра | Битрейты |
2160p | [1 Мбит/с, ..., 13 Мбит/с] |
1140p | [671 кбит/с, ..., 8,3 Мбит/с] |
1080p | [461 кбит/с, ..., 5,7 Мбит/с] |
720p | [260 кбит/с, ..., 3,2 Мбит/с] |
480p | [148 кбит/с, ..., 1,8 Мбит/с] |
360p | [95 кбит/с, ..., 1,2 Мбит/с] |
232p | [49 кбит/с, ..., 611 кбит/с] |
144p | [27 кбит/с, ..., 343 кбит/с] |
Сделано это для того, чтобы:
получить более полную картину распределения качества по диапазону;
захватить разные битрейты, которые соответствуют разным условиям просмотра, режимам контроля битрейта и пропускной способности сети в стриминге.
Параметры кодирования
Результат кодирования может отличаться в зависимости от параметров. Так как наш тест независимый и мы хотим узнать максимальные возможности каждой платформы, подбирались такие настройки кодеков, которые были бы оптимальны на тестовом наборе. Использовался FFMPEG версии 7.1.1. (кроме QSV), остальные параметры ниже (жирным выделено основное, на что стоит обратить внимание):
libx264:
-c:v libx264 -preset fast -g 50 -b:v {BITRATE} -bufsize {BITRATE/FRAMERATE} -maxrate {BITRATE} -minrate {BITRATE} -x264opts no-sliced-threads:no-psy=1:aq-mode=0 -tune zerolatency -profile:v {PROFILE} -level:v {LEVEL} -vsync passthrough
NVENC:
-c:v h264_nvenc -no-scenecut 1 -g 50 -preset p4 -tune ll -b:v {BITRATE} -profile:v {PROFILE} -level:v {LEVEL} -vsync passthrough
RKMPP:
-c:v h264_rkmpp -g 50 -b:v {BITRATE} -bufsize {BITRATE}*1.5 -maxrate {BITRATE}*1.3 -level:v {LEVEL} -profile:v {PROFILE} -rc_mode VBR -vsync passthrough
QSV (кодирование с помощью утилиты в поставке к SDK):
h264 -b {BITRATE} -f {FRAMERATE} -u veryslow -hw
Videotoolbox (нет ручек, за которые можно было бы подёргать для настройки кодека, использовались только параметры для установки битрейта):
-c:v h264_videotoolbox -g 50 -b:v {BITRATE} -profile:v {PROFILE} -level:v {LEVEL} -vsync passthrough
Пресеты для x264 и NVENC были выбраны как «средние» по качеству/скорости. Для QSV был выбран самый медленный и самый качественный veryslow
, так как только он смог как-то тягаться с остальными.
Хочу обратить внимание на параметр -vsync passthrough
(ныне заменённый на -fps_mode passthrough
). Параметр важен для последовательности кадров на выходе кодека. Алгоритм кодека может решать пропускать или добавлять кадры — в таких местах метрики качества будут проседать. Параметр заставляет кодек использовать ту же последовательность кадров на выходе, что и на входе.
Результаты сравнения
Сначала посмотрим на усреднённые результаты сравнения разных платформ кодирования по метрике VMAF, а далее рассмотрим частные случаи и углубимся в детали.
В таблице ниже представлено сравнение кодеков с эталонным libx264 для размеров кадров 360p, 1080p и 2160p. Значения приведены относительно libx264, т. е. отрицательное значение в таблице означает, что для получения такого же качества сравниваемому кодеку нужно на столько процентов больше битрейта. Положительное значение — кодек справился лучше libx264 и сэкономил x% битрейта.
BD-BR VMAF 360p | BD-BR VMAF 1080p | BD-BR VMAF 4K | |
NVENC | -12.9% | -3.7% | -1.9% |
RKMPP | -19.9% | -18.4% | -15.3% |
QSV | -20.0% | -23.4% | -21.2% |
VideoToolbox | -30.3% | -28.4% | -18.0% |
Если не вдаваться в частности отдельных сценариев, то кодеки расположились в таком порядке по увеличению битрейта относительно libx264: NVENC, RKMPP, QSV, VideoToolbox. Ожидаемо, намного более дорогие NVIDIA выигрывают по качеству кодирования.
Теперь рассмотрим детальнее отдельные характерные сцены и то, насколько кодеки с ними справились.
Пример 1: смена относительно статичных сцен с движением посередине.
Кодек | BD-BR VMAF (libx264) - 360p |
NVENC | -11% |
RKMPP | -29% |
QSV | -23% |
VideoToolbox | -50% |
В принципе характерная картина для данного исследования: лучше других выглядит NVENC, хуже — VideoToolbox на Mac. Ниже графики сравнения, где кривая ниже — лучше (требуется меньше битрейта для того же качества).
Пример 2: примитивная графика, плоские цвета. Это, пожалуй, самый простой вариант для кодеков и все они справились примерно одинаково.
Кодек | BD-BR VMAF (libx264) - 360p |
NVENC | -2.31% |
RKMPP | -17.50% |
QSV | -5.74% |
VideoToolbox | -10.73% |
NVENC опять лучше других, хуже всех — RKMPP.
Пример 3: практически статическая картина, но с большим количеством деталей.
Кодек | BD-BR VMAF (libx264) - 360p |
NVENC | -21.48% |
RKMPP | 8.27% |
QSV | -43.85% |
VideoToolbox | -57.37% |
Здесь RKMPP обогнал даже libx264, VideoToolbox в аутсайдерах.
Пример 4: много размытых деталей, градиенты.
Очень часто на таких сценах, а также на водной ряби у кодека NVIDIA появляется много артефактов и пикселизация. Что мы и видим в данном тесте.
Кодек | BD-BR VMAF (libx264) - 360p |
NVENC | -33.29% |
RKMPP | -21.03% |
QSV | -8.10% |
VideoToolbox | -14.48% |
Пример 5: как и в примере 4 тут дым, но видео с относительно статичным фоном. На этот раз сравниваем кодирование для 2160p.
Кодек | BD-BR VMAF (libx264) - 2160p |
NVENC | -24.22% |
RKMPP | -23.26% |
QSV | -38.90% |
VideoToolbox | -57.10% |
NVENC и RKMPP справляются примерно одинаково, VideoToolbox — хуже всех и с приличным отставанием.
Пример 6: статичный фон и много движения в центре кадра, разрешение 2160p.
Кодек | BD-BR VMAF (libx264) - 2160p |
NVENC | 5.65% |
RKMPP | -11.10% |
QSV | -17.65% |
VideoToolbox | -1.23% |
NVIDIA даже лучше libx264, QSV — в аутсайдерах. Интересно, что VideoToolbox на Mac в этом случае тоже справился хорошо.
Пример 7: большая область с подвижными объектами, 1080p.
Кодек | BD-BR VMAF (libx264) - 1080p |
NVENC | 2.56% |
RKMPP | -35.32% |
QSV | -11.17% |
VideoToolbox | -19.06% |
NVIDIA как и в прошлом примере справляется даже лучше, чем софтверный кодек. RKMPP — не справляется.
Пример 8: много деталей, много движения — сложная сцена для всех кодеков.
Кодек | BD-BR VMAF (libx264) - 1080p |
NVENC | 14.03% |
RKMPP | -18.58% |
QSV | -12.99% |
VideoToolBox | -12.49% |
NVENC опять на высоте. Остальные кодеки ведут себя примерно одинаково и требуют больше битрейта для того же качества. Пологая кривая на графике говорит о том, что на более низких битрейтах у всех будет с качеством не очень.
Энергопотребление
Для оценки отношения производительности и энергопотребления рассмотрим только крайние случаи: CPU, GPU и SoC.
Для корректного замера производительности кодирование запускалось в несколько потоков, чтобы загрузить все кодеры. Количество параллельных потоков подбиралось так, чтобы общая производительность была максимальной.
Ниже диаграмма с относительным энергопотреблением, рассчитанным на произведённый кадр.
Ожидаемо система на процессоре потребляет гораздо больше энергии для сжатия такого же количества кадров, чем GPU и SoC (System on Chip). Меньше всего энергии тратит Rockchip — пиковая нагрузка составила порядка 5 Вт (только кодирование, т.е. никаких других задач на процессоре не выполнялось), энергопотребление при полной нагрузке не превышает 20Вт. Интересно отметить, что по производительности Rockchip достаточно близок к A4000.
Декодирование: также проверили, насколько кодеки корректно работают при декодировании. Выяснилось, что все выдают бинарно идентичные кадры на выходе из декодера. Это важно, если для оценки качества используются сжатые входные видео. Если какой-то декодер будет выдавать отличные от других кадры на вход расчёта метрики качества, то корректность такого сравнения под большим вопросом.
Итого
Верхнеуровневые выводы нашего исследования следующие.
Кодек | Преимущества | Недостатки |
libx264 | Почти всегда качество выше | Высокое энергопотребление |
NVENC | Хорошо справляется с большинством сцен | Есть проблемы с размытыми объектами, цена |
RKMPP | Стоимость, скорость | Качество ниже |
QSV | Стоимость | Интеграция с FFMPEG |
VideoToolbox | Качество |
Что и когда выбрать:
Libx264 — если у вас много серверов и их некуда приспособить, либо есть жёсткое требование вытянуть максимум качества при ограниченном битрейте.
NVENC — лидер в реализации кодека в железе, сбалансированное решение по качеству и быстродействию.
RKMPP — самый дешёвый и самый энергосберегающий вариант. Имеет смысл использовать, если нет жёстких требований к качеству картинки или сцены в основном статичны.
QSV — близок по качеству к RKMPP, но дороже и медленнее.
VideoToolbox — самый дорогой из альтернатив и в то же время даёт самое низкое качество. Можно использовать, если он у вас уже есть для других целей и качество картинки не очень важно.
Представленные результаты хоть и не являются полновесными, но достаточно хорошо отражают общее поведение рассмотренных кодеков. За кадром остался интересный вариант с Apple M4, который ожидается, что должен показать более высокое качество, чем его предшественник. Также не хотелось бы сбрасывать со счетов аппаратные реализации вроде NetInt или Xilinx.
И, конечно, крайне интересно будет взглянуть на результаты работы разных реализаций AV1 и H.266. Единичные тесты качества последнего меня лично сильно удивили и есть интерес провести полноценный анализ — подписывайтесь на этот блог и канал, чтобы узнать о результатах будущих исследований.
В канале Смотри за IT рассказываем о создании медиасервисов, инженерных тонкостях, продуктовых находках и полезных мероприятиях, делимся видео выступлений и кадрами из жизни команд Цифровых активов «Газпром-Медиа Холдинга» таких, как RUTUBE, PREMIER, Yappy.