Методология бенчмарка кодеков Фора Софт

Кратко

Бенчмарк кодеков стоит ровно столько, сколько стоит метод за ним, поэтому мы публикуем метод до первого результата. Мы измеряем на реальном клиентском контенте, кодируем зафиксированными и полностью раскрытыми версиями и настройками кодеров, оцениваем именованной метрикой и моделью, агрегируем покадровые оценки вместе с доверительным интервалом и сводим экономию кодеков к BD-rate, вычисленному так, как рекомендует исследование. Каждое число в этом блоке несёт полный провенанс – контент, кодеры, настройки, модель метрики и дату, – чтобы скептик мог его воспроизвести. Прочтите это первым: результаты остального Блока 7 стоят на правилах, заданных здесь.

Почему это важно

Большинству бенчмарков кодеков в интернете нельзя доверять – и не потому, что авторы нечестны, а потому, что метод скрыт. Вендор заявляет «на 30% лучше» без названия метрики, без версии кодера, без набора контента и без способа это проверить. Эта статья – для инженера, оценщика кодеков или технического руководителя, который собирается читать наши сравнения кодеков и кодеров и хочет знать, как именно сделаны цифры, прежде чем им верить. Это ещё и рабочий шаблон: если вы запускаете свой бенчмарк, правила отсюда не дадут вам обмануть самих себя. Мы публикуем метод первым, чтобы у следующих данных была опора.

Почему методология идёт впереди результатов

Результат бенчмарка – это утверждение о мире, а утверждение стоит ровно столько, сколько читатель может проверить. Когда вендор кодека говорит, что один кодер лучше другого, полезный вопрос – никогда не «насколько?», а «измерено как, на чём, с какими настройками?». Без этих ответов заголовочное число – маркетинг, а не измерение.

Этот блок – бенчмарки Фора Софт – существует, чтобы публиковать числа, которые другие инженеры смогут цитировать, а число цитируемо, только если воспроизводимо. Поэтому метод записан первым. Всё в следующих сравнениях кодеков и кодеров (сравнение кодеков на реальном контенте, сравнение кодеров, как результаты меняются по типу контента и BD-rate на наших цифрах) подчиняется правилам, заданным здесь.

Мир стандартов решил эту задачу давно – идеей общих условий тестирования (common test conditions, CTC): фиксированный опубликованный рецепт, который точно говорит, какие последовательности, какие настройки и какие измерения обязано использовать каждое сравнение, чтобы две лаборатории, прогнав один тест, получили сопоставимые ответы. Alliance for Open Media публикует CTC для AV1; Joint Video Experts Team публикует его для своих кодеков (AOM CTC; JVET-J1010, 2018). Наша методология переносит эту дисциплину в реалистичный для стриминга контекст. Принцип тот же: запиши рецепт – и следуй ему каждый раз.

Нажмите, чтобы увеличить

Набор контента: реальные кадры, а не только привычные тест-клипы

Результаты по качеству зависят от контента, поэтому первое решение в любом бенчмарке – на чём измерять, и именно его чаще всего принимают плохо. Кодек, побеждающий на чистом медленном тест-клипе, может проигрывать на зерне, быстром движении или экранном тексте. Измерьте на неправильном контенте – и заголовочное число верно лишь для этого контента.

Привычный сокращённый путь – взять стандартные академические тест-последовательности: короткие безупречные клипы, которые есть у всех, что делает результаты сопоставимыми между статьями. Мы используем набор таких эталонных клипов именно поэтому: они позволяют любому сверить наши числа с опубликованными работами. Но одних стандартных клипов недостаточно, чтобы представить то, что кодирует реальный продукт. Поэтому мы также измеряем на реальном клиентском контенте – на тех кадрах, что действительно обрабатывают наши проекты по стримингу, конференцсвязи, e-learning, OTT и видеонаблюдению, – с разрешения и в виде агрегированных чисел, без узнаваемых кадров.

Этот набор контента охватывает категории, нагружающие кодеки по-разному: игровое кино и ТВ, анимация, спорт с быстрым движением, экранный и презентационный контент, «говорящие головы» конференцсвязи и пользовательское видео (UGC). Каждая ведёт себя под сжатием по-своему – в этом весь смысл статьи как результаты меняются по типу контента. Несколько правил держат набор честным:

• Источник – безупречный мастер. Каждый клип – это высококачественный mezzanine или оригинал, а не пере-кодирование. Бенчмарк против уже сжатого источника измеряет не то: вы наградите кодер за точное копирование чужих артефактов.
• Цветовой формат и разрешение зафиксированы и указаны. Мы сообщаем chroma-субдискретизацию (4:2:0, если не указано иное), битность, разрешение и число кадров для каждого прогона, потому что сравнение метрик корректно, только когда они совпадают.
• Клипы достаточно длинные, чтобы быть репрезентативными. Очень короткие клипы преувеличивают эффекты старта и склеек; мы берём длительности, усредняющие достаточно планов, чтобы число было стабильным.
• Набор задокументирован. Каждый результат называет категорию контента и число клипов за ним, чтобы читатель знал, на трёх клипах держится число или на тридцати.

Кодеры и настройки: зафиксированы, раскрыты и одинаковы во всём сравнении

Кодер – это не «одна вещь», а конкретная сборка с конкретными настройками, и смена любой из них меняет результат. Поэтому мы фиксируем и публикуем обе. Точная версия каждого кодера записана: кодер H.264 x264, кодер HEVC x265 (на момент написания – 4.2), кодер AV1 SVT-AV1 (в 2026 – 4.x) и любые другие, входящие в конкретное сравнение. Когда эти инструменты выпускают новые версии, числа могут сдвинуться – поэтому версия является частью результата, а не сноской.

Настройки важны не меньше сборки. Самый частый способ испортить сравнение кодеков – рассогласование усилия кодера: сравнить медленный, высокозатратный preset одного кодера с быстрым preset другого, а затем выдать разницу в качестве за заслугу кодека. Мы держим сравнение «как с как»: тот же режим управления битрейтом, сопоставимые по сценарию preset скорости, та же структура группы кадров (GOP), где кодеки это позволяют, и та же обработка разрешения. Полная командная строка каждого кодирования записана в манифест провенанса, так что скрытых флагов нет.

Мы тестируем на лестнице рабочих точек, а не на одном битрейте. Каждый клип кодируется при нескольких настройках качества или битрейта – обычно набор точек постоянного фактора качества (CRF) или фиксированного квантователя (QP), – чтобы построить кривую «битрейт–качество», а не сравнивать две одинокие точки. Стандартные CTC используют четыре такие точки (значения QP 22, 27, 32, 37 в условиях JVET) или шесть (условия AOM добавляют точки ниже и выше); мы берём столько точек, сколько нужно, чтобы провести кривую через тот диапазон качества, который реально отгружает стриминговый сервис, – и указываем, сколько именно. Почему кривая, а не точка, – тема следующих двух разделов: именно это вообще делает честное сравнение кодеков возможным.

«О внутренностях кодеков. Эта статья – про измерение кодеков, а не про то, как они сжимают. О том, как на самом деле работают H.264, HEVC и AV1 и чем различаются реализации кодеров, см. в разделе Video Encoding: сравнение кодеков и реализации кодеров. Мы ссылаемся на сторону причины и остаёмся на стороне измерения.»

Метрики и модели: названы, зафиксированы и честны о слепых зонах

Оценка качества ничего не значит, пока вы не назовёте метрику, модель и условия. «VMAF 95» – это не измерение; «VMAF 95 на дефолтной модели v0.6.1, 1080p, усреднение по среднему» – измерение. Поэтому каждая публикуемая оценка несёт эту полную спецификацию.

Наша основная перцептивная метрика – VMAF (Video Multimethod Assessment Fusion), метрика Netflix, объединяющая несколько признаков качества в оценку 0–100, обученную предсказывать мнение человека. VMAF поставляется с несколькими моделями, и модель – часть измерения: дефолтная модель предсказывает качество на телевизоре 1080p в гостиной, модель 4K – на телевизоре 4K с расстояния в 1,5 высоты экрана, а модель phone – на смартфоне, где то же кодирование набирает выше, потому что искажения труднее заметить на маленьком экране (документация Netflix VMAF; models.md). Мы указываем, какую модель использует каждое число, потому что выдача оценки модели phone за оценку телевизора завышает качество. Глубокий разбор выбора модели – в статье VMAF в деталях; здесь правило простое – мы всегда называем модель и версию.

Мы не сообщаем VMAF в одиночку. Рядом с ним мы вычисляем PSNR (Peak Signal-to-Noise Ratio, мера пиксельной ошибки в децибелах) и SSIM (Structural Similarity, мера структурной верности 0–1), потому что у каждой метрики своя слепая зона, и видеть их вместе – значит ловить ошибки, которые скрывает одно число. Каждая объективная метрика – это прокси, валидированный по субъективным оценкам, и когда метрика и аккуратный просмотр человеком расходятся, побеждает просмотр – на этом и стоит валидация метрик по оценкам людей и субъективное тестирование как истина в последней инстанции. Мы называем, где каждая метрика врёт на тестируемом контенте, потому что любая метрика где-то врёт.

Одно правило измерения легко нарушить, и оно тихо обнуляет бенчмарк: полноэталонной метрике нужны оба кадра одного размера. Когда мы кодируем клип в более низком разрешении для теста ступени лестницы, мы декодируем его и апскейлим обратно к разрешению источника указанным апскейлером, постоянным во всём сравнении. Оценка кодирования 540p против источника 1080p без апскейла измеряет не качество, а рассогласование размеров. На этой же дисциплине стоит выпуклая оболочка, связывающая разрешение и битрейт.

Таблица 1. Контроли «как с как». Левый столбец – что мы держим фиксированным во всём сравнении; правый – какую ошибку вы получаете, если этого не сделать. Бенчмарк корректен, только когда каждая строка совпадает у сравниваемых кодеров.

Нажмите, чтобы увеличить

Пулинг и доверие: одно число – плюс насколько мы в нём уверены

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

Мы также сообщаем, насколько уверены в числе VMAF, потому что оценка, обученная на мнении людей, несёт неопределённость. VMAF может приложить к каждому предсказанию 95% доверительный интервал (CI), вычисленный бутстрэпом – обучением многих моделей на повторно выбранных обучающих данных и измерением разброса их предсказаний (документация Netflix VMAF, conf_interval.md, с версии v1.3.7, 2018). С бутстрэп-моделью 95% интервал – это примерно оценка плюс-минус 1,96 стандартного отклонения этих предсказаний. Практическое следствие – дисциплина, которую мы применяем без исключений: если интервалы двух кодеров перекрываются, мы не объявляем победителя. Разница в 0,4 VMAF внутри интервала ±1,5 VMAF – это шум, и назвать её победой – самый частый способ ввести бенчмарком в заблуждение.

BD-rate: правильный способ сказать «на X% меньше при том же качестве»

Заголовочное число любого сравнения кодеков – экономия битрейта при равном качестве, и стандартный способ её выразить – BD-rate (Bjøntegaard Delta rate): средняя процентная разница битрейта между двумя кодеками при согласованном качестве, по диапазону качества (Bjøntegaard, VCEG-M33, 2001). Знак важен: BD-rate −40% означает, что тестовому кодеку нужно на 40% меньше битрейта, чем эталонному, чтобы достичь того же качества. Это экономия, а не оценка качества, – стоит повторить, потому что эти две вещи постоянно путают.

Идея геометрическая. Постройте кривую «битрейт–качество» каждого кодека – битрейт на логарифмической оси, качество по вертикали, – и BD-rate есть средний горизонтальный зазор между кривыми по диапазону качества, где они перекрываются. «Горизонтальный зазор» – ключ: вы читаете разницу битрейта при фиксированном качестве, а не разницу качества при фиксированном битрейте.

Нажмите, чтобы увеличить

Разобранный пример

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

Таблица 2. Иллюстративное сравнение «битрейт–качество». На каждом согласованном уровне VMAF тестовый кодек берёт около половины битрейта эталона. Числа синтетические, только для демонстрации.

На каждом согласованном уровне качества тестовый кодек берёт половину битрейта, так что отношение битрейтов равно 0,5. BD-rate усредняет это отношение в логарифмическом домене, затем возвращается обратно:

log10(0.5)            = -0.301        (зазор в лог-домене, здесь постоянный)
среднее по перекрытию = -0.301        (одинаково на каждом уровне качества)
BD-rate = 10^(-0.301) - 1
        = 0.5 - 1
        = -0.50  →  -50%

BD-rate −50%: тестовый кодек достигает того же качества при половинном битрейте во всём измеренном диапазоне. Реальные кривые никогда не бывают такими чистыми – экономия меняется с качеством, кривые не параллельны и редко перекрываются на всём диапазоне, – именно поэтому вычисление надо делать аккуратно, а не на глаз.

Как вычислить правильно

Исходный метод 2001 года подгонял через точки одну кубическую кривую. Более поздние работы, включая последующую публикацию самого автора метрики и недавний академический анализ, показали, что простая кубика может «выстреливать» между точками и искажать результат, и что важны две поправки (Bjøntegaard, VCEG-AL22, 2008; Herglotz et al., «The Bjøntegaard Bible», 2023). Мы применяем обе:

• Используйте интерполяцию, сохраняющую форму, а не простую кубику. Кусочно-кубическая интерполяция, не способная выстреливать за свои точки (PCHIP или близкий метод Akima), избегает паразитных колебаний, которые вносит одна кубика. Анализ «Bjøntegaard Bible» нашёл, что простой кубический сплайн «может приводить к выбросам (явление Рунге)... поэтому CSI не следует применять на практике», и рекомендует монотонные альтернативы. Мы указываем, какую интерполяцию использовали.
• Интегрируйте в домене лог-битрейта. Усреднение разницы битрейта в логарифме не даёт результату определяться концом высокого битрейта, где несколько сотен кбит/с забивают всё, что ниже.

Ещё два правила защищают от ошибок, тихо ломающих BD-rate:

• Сравнивайте только по перекрывающемуся диапазону качества. BD-rate определён на интервале качества, которого реально достигают оба кодека; расширение его экстраполяцией даёт большие ошибки. «Bible» сообщает случай, где плохое перекрытие превратило истинные −43% в −49% – ошибка в шесть пунктов из-за одной неперекрывающейся точки. Мы проверяем перекрытие явно и сообщаем его.
• Маленький BD-rate может быть внутри шума. Когда измеренная экономия меньше собственной ошибки метода для этого контента и метрики, мы так и говорим, а не сообщаем решительно звучащее число. Для насыщающихся метрик вроде VMAF и SSIM мы также применяем рекомендуемое логарифмическое преобразование, потому что эти метрики выходят на полку у верха диапазона и иначе искажают подгонку кривой.

Загружаемый инструментарий ниже вычисляет BD-rate именно так – сохраняющая форму интерполяция, интегрирование в лог-домене, явная проверка перекрытия и лог-преобразование VMAF – и точно воспроизводит разобранный выше пример.

Частая ошибка: бенчмарк, который доказывает что угодно

Классический плохой бенчмарк не подделан – он просто нечестен так, что читатель этого не видит. Кто-то сравнивает медленный высокозатратный preset любимого кодера с быстрым preset конкурента, оценивает той метрикой, что льстит его кодеку, сообщает одно среднее, прячущее контент, где он проигрывает, выбирает битрейты, где кривые едва перекрываются, и приводит одно число без версии и без доверительного интервала. Каждый выбор по отдельности защитим; вместе они фабрикуют вывод.

Защита – это дисциплина из этой статьи, и её стоит сформулировать как чек-лист, который читатель может применить к чьему угодно бенчмарку, включая наш: назовите контент, зафиксируйте и раскройте версии и настройки кодеров, держите уровень усилия сопоставимым, назовите метрику и модель, агрегируйте так, чтобы худшие кадры были видны, вычислите BD-rate по реальному перекрытию с сохраняющей форму подгонкой и откажитесь называть победителя внутри доверительного интервала. Бенчмарк, который не может ответить на эти вопросы, – это мнение в одежде числа. Читать любой отчёт о качестве так – навык из статьи как читать отчёт по метрикам, не обманывая себя.

Провенанс: у каждого результата свой чек

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

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт с 2005 года строит ПО для видеостриминга, OTT, конференцсвязи, e-learning, телемедицины и видеонаблюдения, и каждый из этих продуктов живёт или умирает на стоящих за ним решениях по кодированию и доставке. Мы измеряем доставленное качество так же, как просим вам доверять: на реальном контенте, с раскрытыми кодерами и настройками, против именованных метрик и моделей, держа в поле зрения худшие кадры и доверительный интервал. Бенчмарки в этом блоке – не литературный обзор, а наши собственные измерения на тех кадрах, что реально отгружают клиенты, и именно поэтому их стоит цитировать, а метод опубликован полностью. Когда цель по качеству надо защитить перед бюджетом CDN или владельцем продукта, именно эта дисциплина делает число устойчивым.

Ключевые выводы

• Бенчмарк надёжен ровно настолько, насколько надёжен метод за ним, – поэтому метод публикуется первым.
• Мы измеряем на реальном клиентском контенте плюс стандартных клипах, с безупречными источниками и указанными форматами.
• Версии и полные настройки кодеров зафиксированы и раскрыты; рассогласованное усилие – классическое нечестное сравнение.
• Каждая оценка называет метрику, модель и версию; мы никогда не сообщаем среднее VMAF без пулинга и интервала.
• BD-rate вычисляется сохраняющей форму подгонкой, в лог-домене, только по реальному перекрытию.
• Каждый результат несёт манифест провенанса, чтобы скептик мог его воспроизвести.

Что почитать дальше

• Сравнение кодеков на реальном контенте: H.264 vs HEVC vs AV1 – заголовочные результаты, работающие на этом методе.
• BD-rate на наших цифрах – метрика за каждым сравнением кодеков, в деталях.
• Выпуклая оболочка: оптимальные точки битрейт–разрешение – геометрия «битрейт–качество», на которой стоит BD-rate.