Имплементации энкодеров: x264, x265, libvpx, SVT-AV1, rav1e, libaom, vvenc

TL;DR

Стандарт кодека – например H.264 или AV1 – это всего лишь рецепт; энкодер – кухня, в которой блюдо готовят. Один и тот же рецепт в исполнении x264, SVT-AV1 и libaom даёт видео очень разного размера, качества и стоимости CPU. Сегодня в профессиональных пайплайнах доминируют семь свободных программных энкодеров: x264 для H.264, x265 и vvenc для семейств MPEG, libvpx для VP9 и тройка SVT-AV1, rav1e, libaom для AV1. Неправильный выбор стоит либо денег за compute, либо денег за трафик – а правильный ответ зависит от того, что вы отдаёте: VOD, лайв, real-time или премиум HDR.

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

Если вы управляете любым сервисом доставки видео – OTT, e-learning, видеонаблюдение, конференц-связь, телемедицина – выбранный программный энкодер определяет три цифры в вашем счёте: цена транскодинга на час, цена трафика на стрим и удержание пользователей через скорость старта и буферизацию. Маркетинг говорит о кодеках абстрактно («AV1 на 30% эффективнее H.265»), но в продакшне вы доставляете не кодек, а конкретный бинарь энкодера определённой версии с определённым пресетом и тюном. Эта статья – справочник оператора по семи программным энкодерам, которые реально разворачиваются в 2026 году: что каждый хорошо делает и в чём проваливается, как выбрать без перезапуска всех бенчмарков самостоятельно.

Что такое энкодер (и почему одному кодеку нужно много энкодеров)

Видеокодек – это письменная спецификация. Спецификация H.264, формально ITU-T Rec. H.264 и ISO/IEC 14496-10, – это 800+ страниц документа, который описывает, как должен выглядеть битовый поток, чтобы любой декодер в мире смог его проиграть. Спецификация почти ничего не говорит о том, как этот битовый поток создавать – каждый автор энкодера сам выбирает компромиссы скорость-качество.

Именно эта свобода объясняет, почему один кодек может иметь много энкодеров, и почему эти энкодеры дают радикально разные результаты. Программа, которая превращает сырые пиксели в совместимый bitstream, называется имплементацией энкодера. Два энкодера для одного кодека целят в один и тот же контейнер и декодер, но всё между входными пикселями и выходными битами – диапазон motion search, логика принятия решений по mode, rate control, перцептивные эвристики, ассемблерные оптимизации – выбор автора имплементации.

Хорошая аналогия – нотная партитура. Каждый оркестр играет одну и ту же партитуру Бетховена (кодек), но запись, которую вы реально слушаете, зависит от дирижёра, музыкантов и зала (энкодер). Вы не покупаете «запись Бетховена»; вы покупаете конкретную запись конкретного оркестра. С видео то же самое: вы разворачиваете не «H.264», а x264 версии X с пресетом Y.

Состав 2026 года в одном взгляде

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

Из таблицы следуют три наблюдения. Во-первых, все крупные энкодеры – open source; проприетарные существуют (Beamr, Visionular, облачные энкодеры NVIDIA), но в продакшн чаще всего идёт open-source-набор. Во-вторых, один кодек может иметь несколько конкурирующих энкодеров (для одного только AV1 – три). В-третьих, лицензии разделены: BSD-стиль для всех, кроме x264 и x265, у которых GPL плюс коммерческая опция.

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

Семь энкодеров подробно

x264 – универсальный baseline

x264, запущенный Лораном Эмаром в 2003 году и с тех пор поддерживаемый VideoLAN, – энкодер, относительно которого измеряется любой более поздний. Он даёт совместимый bitstream H.264 / AVC и остаётся самым качественным открытым H.264-энкодером. Его ассемблерно-оптимизированные горячие пути работают на x86, ARM NEON, ARM64 и ARM64EC; даже через двадцать три года продолжается низкоуровневая работа – последние коммиты включают оптимизации AArch64 NEON и поддержку ARM64EC для Windows-on-ARM. Проект живёт по адресу code.videolan.org/videolan/x264 и распространяется по двойной лицензии: GPLv2 по умолчанию плюс коммерческая лицензия от x264 LLC для продуктов, не способных соблюдать GPL.

Сильные стороны x264 – скорость, предсказуемость и десять пресетов (ultrafast … placebo), которые закрывают всё от 4K live-ингеста до архивного VOD. На современном 16-ядерном CPU x264 в slow кодирует 1080p со скоростью около 120 fps; в medium – легко 240 fps. Этот запас и держит x264 в продакшне всех энкодерных ферм мира: H.264 до сих пор играет в каждом браузере, на каждом смарт-ТВ, в любой старой приставке, и x264 поставляет его без роялти-рисков по битстриму (роялти декодера – отдельная история).

Берите x264, когда совместимость важнее компрессии. Лайв-стриминг на длинный хвост устройств, видеонаблюдение, любой пайплайн, где принимающее устройство может оказаться десятилетней давности.

x265 – рабочая лошадка HEVC

x265, запущенный в 2013 году компанией MulticoreWare, – доминирующий открытый энкодер H.265 / HEVC. Он достиг 4.1 в ноябре 2024-го и 4.2 – 19 апреля 2026-го. Дорожная карта включала совместную работу с Arm по оптимизации x265 на ядрах AWS Graviton4. Как и x264, он предлагает ту же лестницу из десяти пресетов, ту же двойную лицензию (GPLv2 + коммерческая) и те же ассемблерно-тяжёлые горячие пути.

Подвох – скорость. На сравнимых пресетах x265 работает примерно в 2–3 раза медленнее x264 за ~50% экономии битрейта при одинаковом VMAF. Эта сделка окупается для премиум-VOD-библиотек, 4K- и 8K-архивов, broadcast-контрибуции и HDR-каталогов – везде, где экономия на хранении и трафике перекрывает рост CPU-счёта. Не всегда окупается для лайв-стриминга масштаба: один 4K live-канал на slow может загрузить 32-ядерную машину целиком, тогда как x264 управится восемью ядрами.

libvpx – VP9 и default WebRTC

libvpx – reference-энкодер Google для VP8 и VP9, сегодня совместно поддерживаемый Google и Alliance for Open Media. Он жив – v1.16.0 вышла в 2025–2026 годах с AVX-512, ARM SVE2 и Neon-оптимизациями, плюс per-frame PSNR. Его вес в продакшне сегодня двойной. VP9 нёс большую часть каталога YouTube в эпоху 2016–2024, и энкодер по-прежнему живёт для поддержки старого каталога. VP8 остаётся default real-time-кодеком в WebRTC, а значит каждый браузер и каждый WebRTC SFU по-прежнему зависят от libvpx для VP8-кодирования и декодирования.

В эпоху «H.264 или VP9» libvpx был открытой альтернативой без патентной чащи H.264. В эпоху AV1 его обогнали SVT-AV1 и libaom, но он выживает за счёт огромной установленной базы VP9- и VP8-стримов.

SVT-AV1 – продакшн-энкодер AV1

SVT-AV1 – энкодер, сделавший AV1 продакшн-готовым кодеком, а не исследовательской диковинкой. Он стартовал внутри Intel как Scalable Video Technology for AV1 в 2018 году, в 2020-м получил стратегическое партнёрство с Netflix и в том же 2020 году был принят AOMedia как основа для будущего развития AV1. Версия 4.0 вышла 23 января 2026 года, с расширенным диапазоном CRF до 70, квартальным шагом CRF, ускорением RTC-пресетов на 5–15%, оптимизациями Arm Neon и SVE2 и завершением портирования всех перцептивных фич SVT-AV1-PSY в основную ветку под --tune vq (видео) и --tune iq (AVIF).

Что отличает SVT-AV1 – параллелизм. Он масштабируется горизонтально на десятки CPU-ядер с frame-level и tile-level параллелизмом, поэтому достигает примерно качества libaom на cpu-used 6 примерно за половину wall-clock-времени. Пресеты 4–6 – продакшн-sweet-spot для VOD; 7–11 – для low-latency real-time AV1. По анализу Streaming Learning Center, SVT-AV1 покрывает ~95% практической AV1-работы.

Используйте SVT-AV1 как default AV1-энкодер, если нет особой причины переключиться.

rav1e – AV1 «safety first»

rav1e – AV1-энкодер, написанный полностью на Rust, начатый Xiph.Org и Mozilla в 2018 году и сейчас ведомый контрибьюторами xiph и AOMedia. Версия 0.8 вышла в 2025 году после многолетнего перерыва от 0.7 (конец 2023-го). Его приоритеты – безопасность памяти, простая интеграция в Rust-нативные пайплайны и tile-based-архитектура, чисто ложащаяся на embedded multi-core SoC.

На практике rav1e конкурирует с libaom на высоких speed-настройках, но не сравнивается с SVT-AV1 пресет-в-пресет по качеству вдоль всей кривой. Он зарабатывает место в трёх нишах: любой Rust-пайплайн, желающий AV1 без FFI-перехода; защищённые деплои, где memory-safety критична (целый класс CVE в C/C++-видеокоде структурно невозможен в safe Rust); тесно тайлованные embedded-энкодеры, где архитектура подходит.

libaom – reference

libaom – reference-энкодер AV1, тот самый, который определяет совместимый AV1-вывод для спецификации, поддерживается AOMedia в основном инженерами Google. Это самый медленный AV1-энкодер с большим отрывом: на cpu-used 0 worst-case ролики, которые x265 завершает за 3 секунды, могут занимать libaom 445 секунд – замедление в 100–2500 раз. Лестница cpu-used 0–8 меняет качество на скорость, и даже на cpu-used 8 он уступает средним пресетам SVT-AV1 по throughput.

Зато он даёт самые качественные AV1-битстримы на низких cpu-used. YouTube до сих пор использует libaom для AV1-кодирования, где compute-стоимость амортизируется на миллиарды просмотров, и Netflix использует libaom для верхнего тира премиум-VOD, где каждый сэкономленный байт важен. Два валидных кейса, других нет.

vvenc – передний край

vvenc – Fraunhofer Versatile Video Encoder, open-source H.266 / VVC-энкодер из той же лаборатории, что подарила миру reference-работу H.264 и H.265. Версия 1.14 вышла 22 января 2026 года, и трек релизов даёт ускорение в 20–2400 раз относительно VTM reference в зависимости от выбранного из пяти пресетов (faster, fast, medium, slow, slower). Масштабируется на 32 CPU-потока с frame-level-параллелизацией.

Эффективность сжатия VVC на бумаге – самая высокая среди продакшн-кодеков: собственные бенчмарки Fraunhofer показывают -50–55% битрейта против H.264 и ~10–15% против AV1 на 4K. Подвох в 2026-м – железо: VVC hardware decode пока живёт в горстке свежих флагманских телефонов и одном Samsung-Synaptics 8K STB-чипсете. vvenc поэтому – энкодер раннего адоптера: вкладывайтесь сейчас, чтобы быть готовыми, когда декодеры станут массовыми в 2027–2028 годах; игнорируйте, если ваша аудитория ещё вообще не может играть H.266.

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

Развёрнутый пример: один ролик, семь энкодеров

Чтобы компромиссы стали конкретными – вот один и тот же 1080p-ролик 24 fps длиной 60 секунд, закодированный каждым из семи энкодеров на их «продакшн-VOD»-пресете на 16-ядерном CPU. Цифры – представительные диапазоны, синтезированные из Streaming Learning Center и Phoronix Test Suite; читайте их как порядок величины, не как финальный бенчмарк.

Читаем таблицу: 60-секундный ролик стоит ~30 секунд на x264 и ~30–50 минут на libaom, при этом выход у libaom в ~2.7 раза меньше. Этот 60-кратный разрыв в стоимости – именно то, почему «лучший» полностью зависит от того, платите ли вы за CPU один раз и за трафик миллион раз, или за CPU один раз и за трафик один раз.

Формула, которую стоит просчитать перед выбором, всегда одна:

total_cost_per_stream = (encode_CPU_cost / number_of_views) + (bandwidth_cost_per_view × number_of_views)

Если number_of_views исчисляется миллионами (премиум-VOD Netflix, YouTube), доминирует bandwidth-член, и libaom или vvenc оправдывают свою цену. Если number_of_views исчисляется десятками (корпоративное обучение, e-learning, внутреннее видео), доминирует encode-член – и правильный выбор x264.

Скорость и качество – наглядно

Двухосевой взгляд легче удерживать в одной голове. Горизонтальная ось – скорость кодирования на 1080p-эталоне; вертикальная – битрейт при одинаковом VMAF.

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

Из графика становятся ясны три вещи. Во-первых, каждое поколение кодеков двигает фронтир вниз-и-вправо – лучшее сжатие на той же скорости, или то же сжатие быстрее. Во-вторых, три AV1-энкодера разнесены широко: SVT-AV1 примерно на порядок быстрее libaom на сравнимых настройках. В-третьих, vvenc сегодня медленный, но запас по оптимизации у него больше, чем у любого другого энкодера на графике, потому что VVC-тулинг ещё на версии 1.x и будет тяжело оптимизирован в 2026–2027 годах.

Как выбрать правильный энкодер – дерево решений

Вопрос выбора редко звучит «какой кодек» – он звучит «какой энкодер какого кодека для какого workload-а». Три класса нагрузки покрывают почти все решения.

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

Для real-time / sub-second-latency нагрузок (WebRTC-конференции, live-видеонаблюдение, облачный гейминг) x264 на superfast–veryfast – безопасный default; VP8 через libvpx – WebRTC-interop-фолбэк; SVT-AV1 пресет 11 – новый претендент теперь, когда real-time AV1-железо существует.

Для лайв-стриминга масштаба (спорт, новости, e-learning live) x264 на fast–medium всё ещё default; x265 – только если ваш ингест и distribution-цепочка играют HEVC от начала до конца.

Для VOD масштаба (OTT, обучающие каталоги, подкасты) порядок такой: лестница на x264 для совместимости, добавить HEVC-тир на x265 для HDR или 4K, добавить AV1-тир на SVT-AV1 для верха кривой битрейта, и рассмотреть VVC через vvenc только если ваша аудитория демонстрируемо владеет флагманскими телефонами 2024+ или свежими OLED-ТВ.

Распространённые ошибки при выборе энкодера

«Подвох: выбирать по кодеку, разворачивать по энкодеру. Решение «используем AV1», принятое CTO с заголовком Streaming Media в руках, превращается в «используем libaom» в руках инженера – и команда обнаруживает, что счёт за энкодерную ферму вырос в 30 раз за ночь. Всегда фиксируйте кодек и энкодер и пресет в design-доке.»

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

«Подвох: игнорировать лицензию в CI/CD. x264 и x265 по умолчанию идут под GPLv2. Если ваш энкодер работает внутри закрытого продукта, который вы продаёте, нужно либо купить коммерческую лицензию у x264 LLC / MulticoreWare, либо использовать BSD-лицензированные энкодеры (libvpx, SVT-AV1, rav1e, libaom, vvenc). Legal-ревью лицензии энкодера так же важно, как патентное ревью битстрима.»

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

Фора Софт строит видеопайплайны с 2005 года для conferencing, video streaming, OTT и IPTV, video surveillance, e-learning, telemedicine и AR/VR. Через эти вертикали мы разворачивали в продакшне каждый энкодер из этой статьи: x264 – для универсального baseline-тира в conferencing и surveillance, x265 – для премиум-OTT 4K HDR, libvpx – для WebRTC VP8-фолбэка, SVT-AV1 – для новых AV1-тиров в OTT, vvenc – в PoC-работе для клиентов, планирующих H.266-роллаут в 2027 году. Повторяющийся урок из этих проектов: выбор энкодера редко бывает узким местом; bitrate-лестница, режим rate-control (CRF vs capped-CRF vs CBR) и per-title-тюнинг сдвигают качество гораздо сильнее, чем замена одного энкодера на другой при том же пресете.

Ключевые тезисы

• Кодек – спецификация; энкодер – программа. Один кодек, разные энкодеры, очень разный выход.
• Семь open-source-энкодеров везут большую часть мирового видео в 2026: x264, x265, libvpx, SVT-AV1, rav1e, libaom, vvenc.
• SVT-AV1 – default AV1-энкодер; libaom – только премиум-VOD с миллионами просмотров на актив.
• vvenc готов; H.266 hardware decode – нет. Планируйте роллаут на 2027–2028.
• Лицензия важна: x264 и x265 – GPL по умолчанию плюс коммерческая опция; всё остальное – BSD-стиль.
• Перезамеряйте на каждом мажорном релизе. Качество энкодера – движущаяся мишень.

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

• Краткая история видеокодеков: от H.120 до AV2
• Сравнительная таблица кодеков
• FFmpeg: шпаргалка для разработчика