Имплементации энкодеров: 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. Неправильный выбор обходится либо в деньги за вычислительные ресурсы, либо в деньги за трафик – а правильный зависит от того, что вы транслируете: 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, называется имплементацией энкодера. Два энкодера для одного кодека работают с одним и тем же контейнером и декодером, но всё, что происходит между входными пикселями и выходными битами – диапазон поиска движения, логика выбора режимов, управление битрейтом, перцептивные эвристики, ассемблерные оптимизации – зависит от выбора разработчика имплементации.

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

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

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

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

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

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

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

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

Сильные стороны x264 – скорость, предсказуемость и десять пресетов (ultrafast … placebo), покрывающих всё – от 4K live-ингеста до архивного VOD. На современном 16-ядерном CPU x264 в режиме slow кодирует 1080p со скоростью около 120 кадров в секунду, а в medium – легко достигает 240 кадров в секунду. Именно этот запас производительности позволяет 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-каталогов – там, где экономия на хранении и трафике перевешивает рост расходов на вычисления. Но не всегда она выгодна для масштабного лайв-стриминга: один 4K-канал в режиме slow может полностью загрузить 32-ядерный сервер, тогда как x264 справится с той же задачей всего на восьми ядрах.

libvpx – VP9 и WebRTC по умолчанию

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

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

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

SVT-AV1 – энкодер, который сделал AV1 готовым к использованию в продакшене, а не просто исследовательской диковинкой. Проект стартовал в Intel в 2018 году как Scalable Video Technology for AV1, в 2020 году получил стратегическое партнёрство с Netflix и был принят 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, но примерно вдвое быстрее по времени выполнения. Пресеты 4–6 – оптимальный выбор для VOD; 7–11 – для задач с низкой задержкой и реального времени. По данным анализа Streaming Learning Center, SVT-AV1 покрывает около 95% практических задач кодирования в формате AV1.

Используйте SVT-AV1 в качестве кодировщика AV1 по умолчанию, если нет особых причин использовать другой.

rav1e – AV1 «сначала безопасность»

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

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

libaom – эталонная реализация

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

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

vvenc – на передовой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Подвох: выбирать по кодеку, разворачивать по энкодеру. Решение «используем 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). Юридический анализ лицензии энкодера важен не меньше, чем патентный анализ битстрима.»

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

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

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

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

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

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