x264 vs x265 vs SVT-AV1 vs аппаратные: качество

Кратко

Кодек задаёт потолок сжатия, но насколько вы до этого потолка дотянетесь и как долго будете ждать – решает энкодер: конкретная программа, которую вы запускаете, и пресет, на котором вы её запускаете. Относительно x264 на пресете по умолчанию medium на нашем контенте программный AV1 (SVT-AV1) на медленном пресете достигает того же VMAF при примерно 55% меньшем битрейте, тогда как аппаратный AV1 на современной видеокарте экономит около 40%, но кодирует примерно в сто раз быстрее – тот же кодек, разрыв в 18 пунктов из-за одной только реализации. Поместите все конфигурации на одну плоскость «качество против скорости» – и проступает резкий факт: все настройки x264 и x265 доминируемы и держатся в раскладке лишь потому, что часть устройств не умеет декодировать AV1, а фронт эффективности занимает SVT-AV1, фронт пропускной способности – энкодеры в GPU. Эта статья показывает измеренный компромисс, арифметику времени кодирования и правило выбора энкодера под задачу – и идёт со статьёй как датасет, чтобы вы поставили свои кодирования на ту же плоскость.

Зачем это нужно

Выбор кодека – знаменитое решение; выбор энкодера и пресета – то решение, которое реально определяет ваш счёт за трафик и за вычисления. Эта статья для инженера стриминга, ведущего по кодированию или технического продакт-оунера, который уже выбрал AV1 или HEVC на бумаге и теперь должен решить, какой именно энкодер AV1, на какой скорости, для прямого эфира против VOD-архива. Мы измеряем компромисс «качество против скорости» так, как его и нужно измерять – при равном качестве, на контенте, который наши продукты реально отдают, со временем кодирования рядом с экономией – потому что «мы используем AV1» не говорит ни о чём, пока вы не назвали энкодер и пресет, которыми сделан файл. Цель – число, под которое можно планировать пайплайн, и метод, который можно перепроверить на собственных кадрах.

Кодек – это потолок; энкодер – то, до чего вы дотягиваетесь

Стоит развести три вещи, которые часто смешивают, потому что вся статья держится на этом различии. Кодек (от «кодер-декодер») – это стандарт: H.264, HEVC, AV1 – он определяет, как может выглядеть сжатый битстрим и как декодер обязан его читать. Энкодер – конкретная программа, которая такой битстрим производит: x264 делает H.264, x265 делает HEVC, SVT-AV1 делает AV1, а выделенный кремний в вашем GPU (NVENC у NVIDIA, Quick Sync у Intel, AMF у AMD) делает любой из них аппаратно. Пресет – настройка скорости, на которой вы запускаете энкодер: насколько усердно ему позволено работать над каждым кадром.

Кодек фиксирует потолок. Стандарт AV1 просто допускает более экономные способы описать кадр, чем стандарт H.264, и ни один энкодер не превзойдёт потолок своего кодека. Но два энкодера для одного кодека могут оказаться далеко друг от друга, потому что дотянуться до потолка – значит обыскать огромное пространство кодировочных решений, а сколько этого пространства энкодер обыщет – функция времени. Заголовочные цифры экономии по кодекам из нашего сравнения кодеков – HEVC примерно на 44% меньше H.264, AV1 примерно на 55% – измерены зрелыми программными энкодерами, которым дали реальное усилие. Запустите тот же кодек в аппаратном блоке фиксированной функции, настроенном на скорость, – и часть этой экономии вы вернёте обратно. Эта статья как раз про возврат: про разрыв между тем, что кодек может, и тем, что конкретный энкодер делает на конкретной скорости.

«Это сторона измерения, а не сторона механики. Эта статья измеряет, как энкодеры работают и во что обходятся по времени; она не объясняет, как x264, x265 или SVT-AV1 устроены внутри и что делает блок NVENC на кристалле. Внутренности реализаций – разбиение на блоки, поиск движения, оптимизация «искажение-битрейт», аппаратный конвейер – в разделе Video Encoding: реализации энкодеров, аппаратное ускорение (NVENC, VPU, ASIC) и бенчмарк энкодеров. Мы ссылаемся на сторону причины и остаёмся на стороне измерения.»

Два числа, а не одно: эффективность и скорость

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

Первая ось – эффективность, выраженная как BD-rate относительно единого общего якоря. BD-rate (Bjøntegaard Delta rate) – это средняя процентная разница в битрейте между двумя кодированиями при равном качестве, по диапазону качества (Bjøntegaard, VCEG-M33, 2001). Якорем мы берём x264 на пресете medium – универсальную базу, которая работает везде, – и каждую другую конфигурацию даём как экономию относительно неё. BD-rate −40% означает, что эта конфигурация достигает того же VMAF, что и x264 medium, при 40% меньшем битрейте; +5% – что нужно на 5% больше. Знак – единственный постоянный источник путаницы, поэтому повторю: минус – это экономия, и BD-rate – экономия, а не оценка качества. Качество здесь – VMAF на модели по умолчанию v0.6.1 (телевизор 1080p в гостиной), усреднённый по кадрам, с разворачиванием каждого кодирования обратно до разрешения источника перед оценкой – та же спецификация, что и во всём методе Блока 7. Полное чтение VMAF – модель, пулинг, доверительный интервал – это VMAF: объяснение.

Вторая ось – скорость, выраженная как пропускная способность кодирования в кадрах в секунду при 1080p на одной заявленной эталонной машине. Кадры в секунду – честная единица, потому что она масштабируется до единственного вопроса, важного в проде: успеет ли энкодер за объёмом контента и во что обойдутся вычисления. 30 fps означает, что клип на 30 кадрах в секунду кодируется в реальном времени; 3 fps – что это в десять раз дольше, чем длится клип; 480 fps – что всё готово почти раньше старта. Скорость сравнима только на одинаковом железе, поэтому каждая цифра fps здесь снята на одной машине, записанной в провенансе датасета.

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

Пресет – это рукоятка «качество-скорость»

Прежде чем сравнивать энкодеры, разберёмся с рукояткой внутри каждого. Любой современный программный энкодер выставляет пресет – именованный набор настроек, который меняет скорость кодирования на эффективность сжатия. У x264 и x265 пресеты идут от быстрого к медленному: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow и placebo, по умолчанию – medium (документация x265, 2026). Пресет не меняет целевое качество, которое вы запросили; он меняет, насколько усердно энкодер старается его достичь. Более медленный пресет вправе перепробовать больше способов закодировать каждый блок и оставить лучший.

Конкретно: проход x265 от fast к slow включает дорогие инструменты – число опорных кадров, на которые энкодер может оглянуться, растёт с 1 до 5, поиск движения расширяется с маленького «ромба» (dia) до «звезды» (star), уточняется субпиксельный поиск, анализ «искажение-битрейт» (RD) идёт от дешёвого приближения к полной оценке, включаются прямоугольные и асимметричные разбиения блоков (документация x265, 2026). Каждый из них находит ещё немного бит для экономии, и каждый стоит времени. У SVT-AV1, продакшен-энкодера AV1, вместо имён числовая рукоятка – пресеты примерно от 0 (самый медленный, самый эффективный) до 13 (самый быстрый), – но идея та же. Как грубая карта скоростей: SVT-AV1 preset 8 примерно на уровне x265 medium, а preset 6 – на уровне x265 slow (рекомендации проекта SVT-AV1; бенчмарки сообщества, 2026).

И вот где измерительная честность меняет решение. Сравнивая пресеты при равном битрейте, медленные пресеты выглядят бессмысленно: один аккуратный анализ нашёл, что x265 slow даёт лишь около 0,87% более высокий VMAF, чем medium, при более чем удвоенном времени кодирования, а ultrafast всё ещё достигает 98% от оценки veryslow (Ozer, OTTVerse, 2021). В такой рамке кто станет платить вдвое за неполный пункт VMAF? Но равный битрейт – неверная рамка для стриминга. Измерьте те же два пресета при равном качестве (вопрос BD-rate) – и slow срезает битрейт верхней ступени примерно на 23%, а всю лестницу – примерно на 26% (Ozer, OTTVerse, 2021). Усилие купило вам не более высокую оценку при том же размере, а ту же оценку при меньшем размере – а это ровно тот трафик, за который вы платите. Ценность пресета невидима при равном битрейте и очевидна при равном качестве – центральный урок измерения при сопоставленном качестве, проходящий через весь этот раздел.

Заголовок: плоскость «качество-скорость»

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

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

Измеренные числа за графиком, от самого быстрого к самому медленному:

Таблица 1. Иллюстративные домашние результаты, якорь – x264 medium (модель VMAF по умолчанию, BD-rate в лог-домене по перекрывающемуся диапазону, одна эталонная машина). Фронт – набор конфигураций, которые ничто не превосходит сразу по скорости и эффективности. Скачиваемый датасет и инструмент воспроизводят каждую цифру этой таблицы.

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

Чтение фронта: x264 и x265 доминируемы

Резкий результат стоит того, чтобы на нём задержаться: каждая конфигурация x264 и каждая конфигурация x265 лежит под фронтом. Любая из них доминируема – всегда найдётся другая конфигурация, которая и быстрее, и эффективнее. x265 slow (−44% при 9 fps) обходит SVT-AV1 preset 6 (−55% при 11 fps), который и эффективнее, и быстрее. x265 medium (−38% при 22 fps) обходит SVT-AV1 preset 8 (−51% при 30 fps). x264 medium, якорь, проигрывает по скорости любому аппаратному энкодеру и по эффективности всему остальному.

Это не значит, что x264 и x265 устарели, и причина – та самая ось, которой нет на графике: поддержка декодирования. Фронт эффективности и скорости игнорирует, сумеет ли устройство зрителя вообще воспроизвести файл. H.264 декодируется практически на всём, что когда-либо собрано; HEVC – на большинстве современного железа; AV1 – на большой и быстро растущей, но не всеобщей базе. Поэтому x264 остаётся в лестнице как пол совместимости – ступень, которую вы отдаёте старому смарт-ТВ и корпоративному ноутбуку, – а HEVC закрывает середину там, где декодирования AV1 ещё нет. Своё место они зарабатывают охватом, а не качеством-на-бит-на-секунду. Картину поддержки устройств и распространения смотрите в состоянии AV1 в 2026 раздела Video Encoding; эта статья даёт измеренную цену их выбора.

Прочитайте фронт справа налево – и это понятное меню. На крайнем правом, где нужна сырая пропускная способность превыше всего, NVENC H.264 – самое быстрое на доске, но по эффективности едва обходит якорь. Шаг влево – к аппаратным AV1 и HEVC ради крупного выигрыша в эффективности почти на той же скорости. Ещё шаг влево – в лестницу пресетов SVT-AV1, где скорость меняется на эффективность по пресету за раз, пока вы не дойдёте до preset 2 – самой эффективной измеренной конфигурации и самой медленной. Ничто на этом фронте не «неправильно»; правильная точка целиком зависит от того, сколько времени вы можете потратить на кадр.

Программные против аппаратных: реальный компромисс

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

Собственные измерения NVIDIA ставят на это цифры. На поколении Ada Lovelace аппаратный энкодер AV1 даёт около 40% экономии битрейта относительно H.264-энкодера того же чипа при 1080p60, на пропускной способности около 500 fps – примерно в девять раз быстрее, чем сравниваемый программный x264 (NVIDIA, 2023). Это по-настоящему сильный результат, и он совпадает с нашими −40% для NVENC AV1. Но заметьте, против чего он измерен: против аппаратного H.264 и быстрой программной базы. Против SVT-AV1, которому дали реальное время, тот же NVENC AV1 отстаёт примерно на 15 пунктов – −40% против −55% на preset 6, – потому что программный энкодер перебирает решения, недоступные блоку фиксированной функции. Оба факта верны одновременно: аппаратный AV1 разносит программный H.264, и программный AV1 обходит аппаратный AV1.

В поле аппаратного AV1 три игрока, и они близки. Наши измерения ставят NVENC AV1 у NVIDIA незначительно впереди по эффективности, Quick Sync AV1 у Intel (на GPU класса Arc) чуть позади, а AMF AV1 у AMD ещё на шаг назад – разброс в несколько пунктов BD-rate, что согласуется с независимыми тестами, обычно ставящими блоки AV1 у Intel и NVIDIA впереди, а у AMD – позади (тесты сообщества, 2023–2025). Различия между вендорами малы по сравнению с разрывом между любым из них и медленным программным пресетом. Если ваше ограничение – пропускная способность (прямые каналы, транскодинг в реальном времени, фермы кодирования, мерящиеся потоками-на-ватт), этот разрыв – цена входа, и 40% экономии при 480 fps – отличная сделка. Аппаратный AV1 – естественный выбор и для прямых трансляций и пользовательского контента, где нет времени на медленный пресет и нет чистого эталона для измерения.

Число, которое стоит унести: разрыв реализаций – тот же кодек AV1 на нашем контенте простирается от −40% (NVENC, настроенный на скорость) до −58% (SVT-AV1 preset 2, настроенный на эффективность), то есть 18 пунктов BD-rate, решённых целиком тем, какой энкодер и пресет сделали файл, а не кодеком. Кто говорит «мы кодируем в AV1», не сказал о битрейте почти ничего, пока не сказал чем.

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

Цена времени кодирования, в цифрах

Эффективность оплачивается вычислениями, и счёт достаточно велик, чтобы менять решения, поэтому арифметику стоит проговорить вслух. Возьмём один десятиминутный клип при 1080p30 – 600 секунд × 30 кадров в секунду = 18 000 кадров – и прочитаем настенное время кодирования прямо из скоростей Таблицы 1, разделив число кадров на пропускную способность:

NVENC AV1    (480 fps):  18 000 / 480  =     37,5 с   (~0,6 мин)
x264 medium   (95 fps):  18 000 /  95  =    189 с     (~3,2 мин)
SVT-AV1 p6    (11 fps):  18 000 /  11  =  1 636 с     (~27 мин)
SVT-AV1 p4   (4,5 fps):  18 000 / 4,5  =  4 000 с     (~67 мин)
x265 veryslow  (3 fps):  18 000 /   3  =  6 000 с     (~100 мин)

Аппаратный AV1 заканчивает десятиминутный клип менее чем за минуту; SVT-AV1 на preset 4 берёт за тот же клип больше часа, чтобы положить в банк лишние 17 пунктов BD-rate (−57% против −40% у NVENC). Это отношение примерно 107× по вычислениям ради примерно на четверть большей экономии. Стоит ли эта сделка – не вопрос качества; это вопрос экономики, и он переворачивается с масштабом и просмотрами.

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

Решающий факт в том, что кодирование оплачивается один раз, а экономия трафика собирается вечно. Тайтл, который стримили миллион раз, платит счёт за медленный пресет однажды и кладёт 17-пунктовую экономию в банк на каждом просмотре – лёгкая победа SVT-AV1 на медленном пресете. Клип, который посмотрят пару сотен раз, никогда не отобьёт вычисления, и правильный путь – быстрый аппаратный. Для большого каталога счёт за медленный пресет становится реальными деньгами: тысяча часов контента на 4,5 fps пресета 4 – это порядка девяти месяцев однопоточного кодирования (на практике распараллеленного по ферме), против пары дней на аппаратном AV1. Точка окупаемости держится на просмотрах на актив и на отношении вашей стоимости вычислений к стоимости трафика – та же логика, что задаёт цель и бюджет по качеству и движет решением per-title и per-shot тратить больше вычислений там, где это окупается.

Какой энкодер под какую задачу

Плоскость свёртывается в короткое правило, как только вы знаете о задаче две вещи: сколько у вас времени на кадр и какие устройства обязаны воспроизвести результат.

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

Для прямого эфира и реального времени – вещание, конференцсвязь, облачный гейминг, всё, где кодирование должно поспевать за источником, – ответ аппаратный, и аппаратный AV1 (NVENC, Quick Sync) там, где устройства его декодируют. 40% экономии при сотнях кадров в секунду – ровно та сделка, что нужна эфиру, и низкая задержка тут не опциональна. Для VOD большого объёма – каталога, который стримят куда чаще, чем кодируют, – программный AV1 на медленном пресете (SVT-AV1 preset 4–6) и есть ставка на эффективность; одноразовые вычисления амортизируются на миллионах просмотров. Для архивных или мезонинных мастеров, где битрейт важнее времени, самый медленный практичный пресет SVT-AV1 отрабатывает свои часы. А под всем этим x264 остаётся в лестнице как пол совместимости, с HEVC, закрывающим зазор на устройствах, которые декодируют его, но не AV1. Большинство продакшен-сервисов гоняют несколько из них разом и отдают каждому устройству лучший поток, который оно может проиграть – картину со стороны кодека смотрите в реализациях энкодеров раздела Video Encoding.

Таблица 2. Правило решения таблицей. Энкодер выбирается ограничением задачи, а не единым «лучшим» – каждая строка и есть правильный ответ для своей строки.

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

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

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

Третья тонка и специфична для измерения: настройка энкодера на ту самую метрику, которую вы потом сообщаете. У x265 есть --tune psnr и --tune ssim, которые отключают перцептивные оптимизации энкодера именно для того, чтобы цифра PSNR или SSIM вышла выше – и документация прямо говорит, что по умолчанию x265 «настраивается на наивысшее воспринимаемое визуальное качество», а переключаться на тюн под метрику стоит, только если вы намерены бенчмаркать против неё (документация x265, 2026). Бенчмаркните энкодер, пока он настроен льстить вашей оценочной метрике, – и вы измерите настройку, а не качество, которое увидел бы зритель. Мы оцениваем по VMAF с энкодерами в их перцептивной настройке по умолчанию и называем эту ловушку, потому что она повсюду. Любая объективная метрика – прокси, валидированный против человеческого мнения; оптимизировать энкодер под прокси, а не под зрителя – старейший способ выиграть бенчмарк и потерять аудиторию. Когда метрика и аккуратный просмотр расходятся, побеждает просмотр.

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

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

Главное

• Кодек задаёт потолок; энкодер и пресет решают, до чего вы дотянетесь.
• Оценивайте энкодеры по двум осям: экономия битрейта при равном качестве и скорость.
• Тот же кодек AV1 охватывает 18 пунктов BD-rate: SVT-AV1 preset 2 (−58%) до NVENC AV1 (−40%).
• Все настройки x264 и x265 – вне фронта «качество-скорость»; держатся на поддержке декодирования.
• Аппаратный AV1 экономит ~40% при скорости ~в 100 раз выше медленного программного пресета.
• Кодирование оплачивается один раз; экономия трафика собирается на каждом просмотре.

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

• Сравнение кодеков на реальном контенте: H.264 vs HEVC vs AV1 – экономия на уровне кодеков, которую эти энкодеры реализуют.
• Наша методология бенчмарков – как сделаны эти числа, чтобы вы могли им доверять.
• Контент важен: как результаты по качеству меняются по типу контента – почему одно заголовочное число всегда неполно.