VP8 и VP9: открытая альтернатива от Google

TL;DR

VP8 и VP9 – два видеокодека, то есть программы, упаковывающие необработанное видео в компактный файл и обратно его распаковывающие. Google выпустил их без роялти после приобретения разработчика кодеков On2 Technologies за 124,6 млн долларов в феврале 2010 года.1 VP8 появился в мае 2010 года как обязательный видеокодек для WebRTC-браузеров и стал ключевым форматом видео в открытом контейнере WebM; VP9 вышел в июне 2013 года и обеспечивал примерно 50% экономии битрейта по сравнению с VP8 при одинаковом воспринимаемом качестве. Долгое время он использовался YouTube для всех видео выше 720p.23 По данным Bitmovin Video Developer Report за 2026 год, VP9 занимает около 13% в профессиональных стриминговых пайплайнах и остаётся вторым по распространённости кодеком в продакшен-стэках WebRTC после H.264. При этом его преемник AV1, созданный по той же модели royalty-free командой Alliance for Open Media, вытеснил VP9 с YouTube (сейчас более 75% загрузок кодируются в AV1) и на Netflix (30% стримингового трафика, в 2026 году ожидается обгон H.264).45 Поэтому в 2026 году вопрос на практике уже не стоит как «VP8/VP9 против остальных», а звучит иначе: «Где VP8 продолжает приносить пользу внутри WebRTC и есть ли смысл использовать VP9, если можно сразу перейти на AV1».

Зачем читать эту статью

Если вы разрабатываете продукт с видеосвязью в реальном времени – видеоконференции, веб-звонки, видеоподдержку клиентов, live-шоппинг, онлайн-обучение или телемедицину – вы уже используете VP8, хотите вы того или нет, потому что каждый браузер с поддержкой WebRTC обязан его поддерживать. Если вы занимаетесь стримингом, вам нужно решить, стоит ли создавать отдельную VP9-лестницу битрейтов для устройств, которые поддерживают VP9, но не поддерживают AV1 (любой Android-смартфон после 2016 года, Chrome и Firefox, Safari на iOS 14+, любая микросхема Smart TV после 2017 года). А если вы работаете с открытым видеопайплайном, вы почти наверняка используете libvpx – эталонную реализацию обоих кодеков, которую применяет FFmpeg.

В статье объясняется, что такое VP8 и VP9, как сложилась цепочка On2 → Google → AOMedia, и в чём технические различия этих кодеков по сравнению с семейством H.264 / H.265 – без предположения, что читатель уже знаком с принципами работы кодеков. В завершение рассматривается практический вопрос 2026 года: где каждый из кодеков ещё остаётся актуальным, а где его место уже занял AV1. Предварительные знания не требуются – каждый термин объясняется простым языком до первого упоминания. Если вы ещё не читали H.264 / AVC: рабочая лошадка интернета и H.265 / HEVC: +50% к H.264 и патентная катастрофа, их стоит держать под рукой: VP8 создавался как royalty-free аналог H.264, а VP9 – как royalty-free аналог HEVC.

Что такое VP8 и VP9 на самом деле

Кодек – это две программы, объединённые в одну: энкодер, который берёт сырые кадры с камеры или из видеоредактора и упаковывает их в компактный файл, и декодер, который выполняет обратное преобразование и выводит кадры на экран. Само слово «кодек» – портманто от coder и decoder. VP8 и VP9 – такие же кодеки, как H.264 и H.265, и они занимают аналогичное место в видеопайплайне.

Само название VPx старше Google. Семейство VPx разработала небольшая американская компания On2 Technologies (основана в 1992 году под названием The Duck Corporation – это имя до сих пор встречается в codec-тагах некоторых файлов Matroska). В 2001 году On2 выпустила VP3 (позже она передала его Xiph.Org Foundation, где его переименовали в Theora), а затем создала VP4, VP5, VP6 и VP7 – последовательность проприетарных кодеков, которые в основном продавались для использования в Adobe Flash в эпоху раннего онлайн-видео. VP8 стал последним релизом On2 как независимой компании – анонс состоялся 13 сентября 2008 года.2

Главное событие для VP8 произошло через полтора года. 5 августа 2009 года Google объявил о покупке On2, а 19 февраля 2010 года сделка была завершена – за 124,6 млн долларов.1 Ещё через три месяца, 19 мая 2010 года на конференции Google I/O, Google совершил то, чего до этого никто в видеоиндустрии не делал в таком масштабе. Вместо того чтобы монетизировать патенты On2, компания выпустила спецификацию VP8 под неотзывной лицензией без роялти, открыла референсные энкодер и декодер как libvpx под лицензией типа BSD и интегрировала VP8 вместе с аудиокодеком Vorbis в контейнер WebM на основе Matroska.2 Цель была сформулирована чётко: предоставить вебу альтернативу H.264 без роялти – в тот момент MPEG LA всё ещё не определилась, будет ли взимать роялти за стримы интернет-видео.

VP9 появился по той же схеме. Разработка стартовала в конце 2011 года, а первые битстримы VP9 заработали на YouTube в июне 2013 года – в том же месяце, когда была окончательно утверждена спецификация.3 Цель по компрессии формулировалась просто: сократить битрейт VP8 вдвое при неизменном воспринимаемом качестве – то есть вывести VP9 примерно на ту же конкурентную позицию против HEVC, что и VP8 против H.264. VP9 был royalty-free с самого начала – снова благодаря неотзывному патентному гранту Google и снова с libvpx в качестве референсной реализации.

Третий акт той же истории – AV1. Это уже не VPx-кодек, но прямой наследник линейки. В сентябре 2015 года – спустя полгода после запуска патентного пула HEVC Advance, после чего лицензионное будущее HEVC стало выглядеть нереализуемым, – Google, Amazon, Cisco, Intel, Microsoft, Mozilla и Netflix основали Alliance for Open Media (AOMedia). Первым проектом стал royalty-free кодек-наследник, созданный на основе лучших идей Google VP10 (разрабатываемого преемника VP9), Cisco Thor и Mozilla Daala. Результат – AV1, опубликованный в марте 2018 года и спроектированный для замены VP9 так же, как VP9 был создан для замены VP8. Подробно о AV1 – в статье AV1: новый стандарт интернета и где он сейчас в 2026.

Вот почему в этой статье объединены VP8 и VP9, но не AV1. Два кодека семейства VPx имеют одного корпоративного «родителя», общую лицензионную модель, референсную реализацию и контейнер; AV1 унаследовал лицензионную модель и подход к референсной реализации, но его битстрим был полностью переработан AOMedia.

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

Краткая история: от плагина для Flash до дефолта в WebRTC

VP8 и VP9 созданы с одной целью – обеспечить вебу видеокодек, за использование которого не нужно платить роялти. В 2026 году эта идея кажется очевидной, но в 2008–2010 годах было совершенно неясно, не придётся ли платить поштучное роялти за каждое видео в браузере по подписке. Покупка Google компании On2 за 124,6 млн долларов стала прямым ответом на эту неопределённость.

Цепочка решений началась не в Google. Элемент HTML5 <video> стандартизировался в W3C с 2007 по 2010 год без указания обязательного кодека – рабочая группа так и не смогла прийти к соглашению. Apple настаивала на H.264 (уже поддерживался в iOS и Safari). Mozilla и Opera отдавали предпочтение Theora (открытому кодеку на основе On2 VP3), поскольку не хотели включать в бесплатный браузер кодек, обременённый патентами. Microsoft тоже выступал за H.264. Конфликт был реальным, а видеоиндустрия, которая полагалась на Adobe Flash для кроссбраузерного воспроизведения, внимательно следила за ходом событий.

Релиз VP8 от Google в мае 2010 года изменил ход дискуссии. Технически VP8 был близок к профилю H.264 Baseline – примерно такая же эффективность сжатия на простом контенте, чуть хуже на сложном, но при этом надёжный и стабильный – и поставлялся с неотзывным патентным грантом без роялти. Mozilla и Opera внедрили VP8 уже через несколько месяцев. Adobe добавил поддержку VP8 в Flash. Google интегрировал VP8 в Chrome и YouTube. Microsoft и Apple напрямую VP8 не приняли, но сам факт существования бесплатной альтернативы заставил MPEG LA в августе 2010 года публично пообещать, что H.264 никогда не будет взимать роялти за интернет-видео, бесплатное для конечного пользователя. Это сняло прямую угрозу, которая и спровоцировала войну кодеков.2

Вторая ключевая развилка – стандарт WebRTC. Когда IETF и W3C в 2011–2016 годах кодифицировали видеосвязь напрямую между браузерами, рабочая группа снова не смогла договориться о едином обязательном кодеке. Компромисс, опубликованный в марте 2016 года как RFC 7742, сделал VP8 и H.264 Constrained Baseline обязательными для реализации (mandatory-to-implement, MTI) в каждом WebRTC-совместимом браузере.6 Именно поэтому VP8 в 2026 году имеет 100%-ное покрытие среди браузеров – спустя пятнадцать лет после выхода. Каждый Chrome, Firefox, Safari и Edge на любом десктопе и любом Android-устройстве поставляется с энкодером и декодером VP8 по требованию стандарта WebRTC.

Третья развилка – переход YouTube на VP9 в 2013–2018 годах. YouTube переключил потоки 1080p и 4K на VP9, чтобы избежать роялти за использование H.264 и HEVC на таком масштабе. Это вынудило каждого производителя Android-устройств, каждого вендора Smart TV, каждого производителя сет-топ-боксов и каждого браузера либо внедрить аппаратное декодирование VP9, либо лишиться доступа к контенту YouTube. К 2018 году аппаратное декодирование VP9 стало по сути универсальным на Android-смартфонах, выпущенных после 2016 года, и на Smart TV, появившихся после 2015 года.3

Четвёртая и последняя развилка – AV1. Как только AOMedia в 2018 году выпустила AV1 1.0 и объявила, что её участники будут заменять HEVC и VP9 на AV1 везде, где это возможно, перед любым новым проектом встал простой выбор: «пропустить VP9 и сразу перейти на AV1». YouTube начал использовать кодирование в AV1 в 2018 году и к 2025 году достиг отметки 75% новых загрузок. Netflix внедрил AV1 в 2020 году и к концу 2025-го добился 30% трафика стриминга – полное покрытие каталога AV1-HDR10+ запланировано на начало 2026 года.5 VP9 не исчез, но стал кодеком, используемым в качестве альтернативы H.264 для устройств, не поддерживающих AV1, а не стандартным выбором нового поколения.

Это и есть фон любой проектной дискуссии 2026 года о VP8 или VP9. У этих двух кодеков нет маркетингового бюджета, патентных споров или дорожной карты новых функций. Это инфраструктура: VP8 – кодек для WebRTC, VP9 – открытый кодек, находящийся между H.264 и AV1 по возможностям, и оба поддерживаются в актуальной версии libvpx, потому что от них зависит вся видеоиндустрия – независимо от того, планируют ли их использовать в ближайшие проекты.

Как устроен VP8 простыми словами

VP8 – это гибридный блок-ориентированный кодек той же общей архитектуры, что и H.264. Подробно о фреймворке гибридных кодеков рассказано в статье Архитектура гибридного видеокодека. Основная идея заключается в том, что VP8 разбивает каждый кадр на небольшие прямоугольные блоки, предсказывает значение каждого блока на основе соседних, кодирует лишь небольшой остаток (residual) и записывает биты этого остатка в битовый поток с помощью энтропийного кодера.

VP8 сделал четыре ключевых выбора, которые отличают его от H.264.

Размер блока. VP8 использует фиксированные макроблоки 16×16, как и H.264, с подразделением до 4×4 пикселей для intra-предсказания и 4×4 для компенсации движения. Квадродеревьев не применяется.

Режимы intra-предсказания. У VP8 – 10 режимов intra-предсказания для блоков 16×16 и 10 для блоков 4×4 (вертикальный, горизонтальный, DC и несколько диагональных). У H.264 – 9 для 4×4 и 4 для 16×16. Числовой разрыв небольшой.

Компенсация движения. VP8 поддерживает векторы движения с точностью до четверти пикселя с использованием 6-tap фильтра интерполяции (в H.264 – 6-tap на половине пикселя и билинейный на четверти), допускает до трёх референсных кадров (последний кадр, золотой кадр, альтернативный референсный кадр) и вводит концепцию alt-ref frame – невидимого референсного кадра, который энкодер может синтезировать для улучшения предсказания будущих кадров.

Loop filter и энтропийный кодер. У VP8 есть один in-loop deblocking filter, а в качестве энтропийного кодера используется boolean arithmetic coder (упрощённый арифметический кодер) вместо CABAC из H.264. Арифметический кодер – это осознанный компромисс: он позволяет легче обойти патенты H.264, но при этом немного уступает по эффективности сжатия.

В целом VP8 примерно эквивалентен H.264 Baseline Profile на большинстве контента: сопоставимая степень сжатия на простых источниках, немного хуже – на сложных (сложное движение, мелкие детали, низкий битрейт) и заметно уступает H.264 High Profile (в котором используются 8×8 преобразования, CABAC и B-кадры, отсутствующие в VP8). В контексте стриминга этот разрыв существует, но невеликий; в WebRTC, где кодирование всегда происходит на низком битрейте и с короткими GOP, он не имеет значения, и VP8 регулярно показывает такой же MOS, как и H.264 Baseline.

Главное, чего не хватает VP8, – это B-кадры (двунаправленные предсказанные кадры, ссылающиеся и на предыдущие, и на последующие). Механизм alt-ref frame частично компенсирует это, предоставляя энкодеру невидимый референс для предсказания, но отсутствие настоящих B-кадров – главная причина, по которой VP8 уступает H.264 High Profile.

Как устроен VP9: пять преимуществ перед VP8

VP9 сохраняет гибридную блок-ориентированную архитектуру, но кардинально перерабатывает каждую её стадию. Пять ключевых улучшений, благодаря которым VP9 обеспечивает прирост эффективности кодирования примерно на 50% по сравнению с VP8.

1. Superblocks вместо макроблоков

VP9 отказывается от фиксированных блоков 16×16 и заменяет их superblock размером 64×64 пикселя, который рекурсивно делится на более мелкие prediction blocks – вплоть до 4×4 – с помощью квадродерева. В отличие от HEVC, где квадродерево Coding Tree Unit (CTU) ограничено только квадратными разбиениями, VP9 допускает прямоугольные разбиения на каждом уровне (например, блок 64×64 может разделиться на две части 64×32 или 32×64). Такая гибкость особенно полезна при обработке контента с выраженным горизонтальным или вертикальным движением – например, панорам или текста на экране.37

Ментальная картина такая же, как в HEVC – шахматная доска из квадратов, которые можно делить на части, – плюс дополнительная свобода: любой квадрат можно разделить не только на четыре четверти, но и на две половинки. На плоских участках (небо, стены, градиенты) VP9 использует один блок 64×64 и экономит битрейт; на текстурированных и движущихся областях – разбивает структуру так глубоко, как требуется.

2. Десять intra-режимов с более умными базовыми режимами

Парадоксально, но у VP9 всего 10 режимов intra-предсказания – меньше, чем 35 у HEVC. Хитрость в том, что эти режимы спроектированы так, чтобы эффективно покрывать наиболее распространённые направления границ – вертикаль, горизонталь, несколько близких к диагональным, а также DC и TM (TrueMotion) averaging modes. В сочетании с прямоугольными разбиениями, описанными выше, они позволяют точно описывать реальные границы контента, используя меньшее количество бит на режим. Этот разрыв в числе режимов – одна из технических причин, по которой VP9 немного уступает HEVC в прямых сравнениях по Bjøntegaard Delta Bitrate; большинство измерений показывают этот разрыв в диапазоне 5–15% в зависимости от контента и битрейта.8

3. Лучшее движение: 1/8 пикселя, три референса, расширенный поиск

VP9 улучшает компенсацию движения по сравнению с VP8 в трёх аспектах. Векторы движения теперь имеют точность 1/8 пикселя (вместо 1/4 у VP8 и H.264), а фильтр интерполяции – 8-таповый для яркости (вместо 6-тапового в VP8). Энкодер может использовать до трёх референсных кадров одновременно на блок (как и в VP8, но с более умными эвристиками выбора), включая alt-ref frame, унаследованный от VP8 и применяемый в VP9 значительно активнее. Подробности – в Inter-frame coding и motion estimation.

4. Большие трансформеры и новый асимметричный трансформ

VP8 использовал только трансформацию 4×4. VP9 добавляет целочисленные трансформы 8×8, 16×16 и 32×32, а также Asymmetric Discrete Sine Transform (ADST) для блоков, в которых остаток, как предполагается, имеет асимметричное распределение энергии – например, на краях движущихся объектов. Трансформация DCT 32×32 на больших однородных участках даёт значительный выигрыш в сжатии UHD-контента по той же причине, по которой эффективны CTU: большие трансформы значительно лучше сжимают плавные градиенты. Подробно о семействе методов transform coding рассказано в статье Transform coding: DCT, ADST, integer transforms.

5. Параллелизм через тайлы

VP9 проектировался с учётом многоядерного декодирования с самого начала. Кадр разбивается на вертикальные тайлы (а в новых версиях libvpx – опционально и на горизонтальные строки тайлов), которые декодируются независимо друг от друга. В сочетании с row-based multi-threading в libvpx (-row-mt 1 в FFmpeg) это позволяет одному VP9-декодеру загружать восемь и более CPU-ядер при обработке видео 4K60 – чего не может добиться серийный декодер VP8, работающий макроблок за макроблоком.9

Цена всех пяти выигрышей – сложность энкодера. На пресете -speed 1 (качество-оптимизированный) libvpx-VP9 работает примерно в 3–8 раз медленнее, чем libvpx-VP8 при сопоставимом качестве, и в 5–15 раз медленнее, чем libx264 при аналогичных пресетах.9 Сложность декодера остаётся скромной – примерно в 2 раза выше, чем у VP8, что вполне укладывается в вычислительные возможности любого устройства 2026 года.

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

Точное число в компрессии – и где оно не справляется

Независимые академические измерения снова и снова показывают, что VP9 опережает VP8 примерно на 40–45% (чуть ниже цели Google в «50%» в среднем), отстаёт от HEVC примерно на 5–15% при одинаковом объективном качестве на HD и UHD и уступает AV1 примерно на 25–30%.8 На низком битрейте и разрешении разрыв с HEVC сокращается или даже меняет знак – VP9 иногда обгоняет HEVC при стриминге ниже 720p и ниже 1 Мбит/с, поскольку прямоугольные intra-разбиения VP9 лучше соответствуют краям мелких блоков, в отличие от исключительно квадратных intra-разбиений HEVC. На высоком битрейте и разрешении VP9 отстаёт от HEVC уже ближе к 15%.

Честный итог давно сформулирован в бриф-материалах Iain Richardson на Vcodex: VP9 – это кодек класса HEVC с открытой лицензией, но с более медленными энкодерами.

Профили и уровни VP9 – что именно использовать

Матрица профилей и уровней VP9 заметно скромнее, чем у HEVC, поскольку VP9 поддерживает более узкий набор сценариев. Определено четыре профиля – Profile 0 до Profile 3, каждый из которых добавляет новые возможности по сравнению с предыдущим.3

Таблица 1. Четыре профиля VP9. Профиль 0 – де-факто стандарт для стриминга; профиль 2 – HDR-профиль, единственный другой с заметным аппаратным покрытием.

Уровни VP9 (Level 1–Level 6.2) ограничивают разрешение, частоту кадров и битрейт примерно по тому же принципу, что и уровни HEVC, адаптированные под битстрим VP9. Level 5.1 (4K60, максимум 60 Мбит/с) – стандартный выбор для 4K-стриминга. Level 6.1 поддерживает 8K60. Большинство потребительских устройств с поддержкой VP9 работают на уровне 5.1; некоторые телевизоры 2024–2026 годов и новые Android-флагманы способны обрабатывать Level 6.1.

Контейнер WebM – естественная обёртка для VP9. WebM представляет собой профиль Matroska (MKV), ограниченный видео VP8/VP9 и аудио Vorbis или Opus. Браузеры по умолчанию используют VP9 внутри WebM; Smart TV и Android поддерживают VP9 как в формате WebM, так и в MP4. Подробнее см. Контейнеры: MP4, fMP4, MKV, WebM, MOV, MPEG-TS.

VP8 в WebRTC, и почему он по-прежнему важен в 2026

Если вы транслируете какое-либо видео в реальном времени – видеосвязь, конференции, поддержку клиентов, live-шоппинг, телемедицину, e-learning или онлайн-обучение – вы используете VP8, потому что RFC 7742 обязывает каждый WebRTC-браузер реализовать его как кодек, обязательный к поддержке (mandatory-to-implement, MTI).6 H.264 Constrained Baseline – второй MTI-кодек, а VP9 и AV1 всё чаще становятся опциональными кодеками в SDP-переговорах. Однако VP8 – это кодек, который браузеры всегда смогут использовать, если SDP offer/answer не найдёт ничего лучшего. Подробности о работе SDP и ICE мы разбираем в статье WebRTC глубоко: SDP, ICE, STUN/TURN, SFU vs MCU.

Практические причины, по которым VP8 выигрывает в WebRTC, – в основном не в сжатии. Энкодер VP8 достаточно быстр, чтобы работать в реальном времени на любом устройстве, выпущенном после 2012 года. Его битрейт легко адаптируется к изменяющимся условиям сети, поскольку у энкодера отсутствуют B-кадры, требующие переупорядочивания, и сложная пирамидальная структура GOP, которую нужно восстанавливать после потери пакета. Режимы temporal scalability (позже использованные в VP9 и AV1) позволяют SFU (Selective Forwarding Unit) выборочно отбрасывать кадры для участников при ухудшении сети – именно этот выигрыш в видеоконференциях и стал главной причиной выбора VP8. И лицензия действительно бесплатна.

Компромисс заключается в том, что сжатие VP8 не превосходит H.264 Baseline. На современном конференц-оборудовании, способном использовать H.264 High Profile или VP9, отказ от VP8 даёт ощутимую экономию пропускной способности при неизменном MOS. Поэтому большинство продакшен-стэков WebRTC используют VP8 как базовый кодек, переходят на H.264 / VP9 / AV1, если пира поддерживает, и возвращаются к VP8 только в случае, если переговоры по SDP не находят ничего лучше – что до сих пор регулярно происходит в кросс-браузерных, кросс-платформенных и кросс-версионных звонках.

Поддержка браузерами и аппаратное декодирование в 2026

Картину поддержки VP8 и VP9 в 2026 году можно охарактеризовать как универсальную в браузерах и доминирующую на стороне Android в части аппаратного декодирования.

Браузеры. Программное декодирование VP8 будет внедрено во все версии Chrome, Firefox, Safari и Edge к 2026 году по требованию WebRTC MTI. Программное декодирование VP9 также доступно во всех крупных браузерах: Safari добавил поддержку VP9 в iOS 14 и macOS Big Sur (2020), Edge поддерживает VP9 на всех платформах, где это реализовано в Chromium, а Chrome и Firefox предоставляют VP9 с 2013 года.3

Аппаратный декодинг. Аппаратный декодинг VP9 поддерживается на большинстве SoC для Android, выпущенных после 2016 года: Qualcomm Snapdragon 820 и новее, MediaTek Helio P-серии и старше, Samsung Exynos 8895 и новее, а также все процессоры Google Tensor. На Smart TV-чипсетах, появившихся после 2015 года, аппаратное декодирование VP9 также широко распространено – оно реализовано в большинстве моделей Samsung, LG, Sony, Vizio, TCL и Hisense.

На iOS браузер Safari воспроизводит VP9 программно на всех устройствах, начиная с iPhone 6s. Аппаратное декодирование появилось начиная с чипа A15 Bionic – то есть на iPhone 13 Pro и новее, а также на Mac с процессорами M3 и выше.10

На Windows любой современный GPU от Intel, AMD или Nvidia поддерживает аппаратный декодинг VP9. Единственный заметный пробел – Chrome на Linux, где VP9 воспроизводится программно повсеместно, а аппаратное декодирование работает фрагментарно из-за непоследовательной поддержки VA-API.

Аппаратное декодирование VP8 встречается реже, потому что основной сценарий – это real-time WebRTC, где узкое место – энкодер, а битрейт обычно достаточно низок, чтобы CPU-декодирование справлялось. Большинство современных Android SoC включают аппаратное декодирование VP8 как дополнение к VP9, но аппаратный энкодер VP8 – редкость: большинство устройств кодируют VP8 на CPU с помощью libvpx.

Типичные подводные камни (читать до энкодинга)

Короткий список ошибок, с которыми столкнулись видеокоманды при выборе между VP8 и VP9.

«Подводный камень: отгрузка VP9 в MIME-типе video/mp4 без проверки плеера. VP9 внутри MP4 (video/mp4; codecs="vp09.00.10.08") поддерживается в Chrome, Edge, Firefox и Android, но Safari и iOS исторически предпочитают VP9 в формате WebM. Перед тем как использовать один контейнер для двух платформ, обязательно протестируйте MP4-реализацию в Safari.»

«Подводный камень: энкодинг VP9 на дефолтах libvpx и принятие результата. Дефолтный режим libvpx-VP9 с параметром -speed 0 работает крайне медленно и даёт лишь незначительное улучшение качества по сравнению с -speed 1 или -speed 2. Большинство производственных конфигураций используют -speed 1 для двухпроходного кодирования видео по запросу (VOD) и -speed 4 для прямых трансляций, а также включают -row-mt 1 и -tile-columns примерно log2(width / 256). Без этих флагов libvpx-VP9 может быть в 20 раз медленнее, чем необходимо.»

«Подводный камень: забыли alt-ref frames. Самый главный рычаг улучшения качества в libvpx-vp9 – это auto-alt-ref 1 в сочетании с lag-in-frames 25, что включает механизм alt-ref. Энкодеры с отключённым alt-ref (или с lag-in-frames < 12) теряют на выходе 3–10% эффективности сжатия.9»

«Подводный камень: считать, что VP9 Profile 2 – это «VP9 готов к HDR». VP9 Profile 2 поддерживает 10- и 12-битную глубину цвета и формат chroma 4:2:0 – то есть те параметры, которые необходимы для HDR. Однако transfer function (PQ или HLG), цветовые первичные (BT.2020) и метаданные о мастеринг-дисплее всё равно нужно явно указать в битстриме и контейнере. См. Полный гид по HDR: HDR10, HDR10+, Dolby Vision, HLG.»

«Подводный камень: использовать VP9 вместо AV1 из-за дороговизны энкодера, не проверив поддержку AV1 на устройствах. В 2026 году 80% потребительских устройств будут декодировать AV1 аппаратно (Intel, AMD, Nvidia, Apple A17 Pro и выше, каждый Pixel начиная с 6, каждый Galaxy S22 и выше). Поддержка VP9 остаётся шире, но разрыв сокращается. Если в 2026 году вы выбираете VP9 вместо AV1 – это должно быть связано с текущей стоимостью энкодинга и планом на пересмотр, а не с отсутствием поддержки AV1.»

VP9 в FFmpeg: команды, которые вы реально будете использовать

Три команды охватывают примерно 90% задач по работе с VP9 для большинства видеокоманд. Энкодер – libvpx-vp9, открытая референсная реализация, поддерживаемая Google. Все три команды предполагают использование FFmpeg 6+ с включённой поддержкой libvpx при компиляции.

# 1) 2-pass VOD, 1080p60, целевой битрейт 3 Мбит/с, quality preset
ffmpeg -i in.mov -c:v libvpx-vp9 -b:v 3M -minrate 1.5M -maxrate 4.35M \
  -pass 1 -row-mt 1 -tile-columns 2 -threads 8 -speed 4 \
  -auto-alt-ref 1 -lag-in-frames 25 -an -f null /dev/null && \
ffmpeg -i in.mov -c:v libvpx-vp9 -b:v 3M -minrate 1.5M -maxrate 4.35M \
  -pass 2 -row-mt 1 -tile-columns 2 -threads 8 -speed 1 \
  -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 128k out.webm

Двухпроходная структура – стандартный подход в libvpx: на первом быстром проходе с параметром -speed 4 собирается статистика по кадрам, а на втором, более медленном проходе с -speed 1 она используется для умного распределения битов. Параметр -row-mt 1 включает многопоточность на уровне строк внутри каждого тайла. -tile-columns 2 позволяет декодеру обрабатывать до четырёх тайлов параллельно при разрешении 1080p. Подробно о режимах управления битрейтом – CBR, VBR, CRF, ABR и capped CRF – читаем в статье Rate control: CBR, VBR, CRF, ABR, capped CRF.

# 2) 4K HDR Profile 2 (10-бит BT.2020 PQ), однопроходный CRF
ffmpeg -i in_master.mxf -c:v libvpx-vp9 -profile:v 2 -pix_fmt yuv420p10le \
  -crf 28 -b:v 0 -row-mt 1 -tile-columns 3 -threads 16 -speed 2 \
  -auto-alt-ref 1 -lag-in-frames 25 \
  -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc \
  -c:a copy out_4khdr.webm

Пара -crf 28 -b:v 0 – это режим постоянной качества (аналог -crf в x265): кодек VP9 сам выбирает нужный битрейт, чтобы достичь заданного уровня воспринимаемого качества. Параметр -pix_fmt yuv420p10le обязателен для использования Profile 2. Сигнальные параметры цвета (-color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc) отвечают за то, чтобы файл корректно отображался как HDR на совместимом плеере; без них он будет восприниматься как 10-битный SDR-файл.

# 3) Live RTMP / WebRTC-ингест, 720p30, однопроходный CBR
ffmpeg -re -i input -c:v libvpx-vp9 -b:v 2M -minrate 2M -maxrate 2M \
  -row-mt 1 -tile-columns 1 -threads 4 -speed 6 \
  -error-resilient 1 -frame-parallel 1 -lag-in-frames 0 \
  -g 60 -keyint_min 60 -auto-alt-ref 0 \
  -c:a libopus -b:a 96k -f webm tcp://ingest.example.com:9000

Фиксированный интервал ключевых кадров в две секунды (-g 60 при 30 fps), опция -error-resilient 1 и параметр lag-in-frames 0 – именно они обеспечивают низкий уровень задержки и устойчивость потока к потерям пакетов. -speed 6 – это пресет для кодирования в реальном времени. Подробнее см. Стриминг-протоколы: 8 главных в 2026.

VP8 / VP9 против остальных: сравнение кодеков в 2026

Честное сравнение включает пять кодеков, о которых ваш продукт упомянет на бюджетном совещании.

Таблица 2. Карта кодеков в 2026 году. VP8 – стандартный кодек WebRTC; VP9 – royalty-free кодек, занимающий промежуточное положение между H.264 и AV1; AV1 – новый royalty-free лидер. Актуальная версия таблицы – в Сравнительной таблице кодеков.

Чтение этой таблицы, которую мы предлагаем использовать на продуктовых ревью: VP8 неизбежен внутри WebRTC; VP9 – безопасная royalty-free альтернатива для устройств, не поддерживающих аппаратное декодирование AV1; AV1 – дефолт для всего остального. VP9 постепенно уйдёт с рынка в течение пяти лет по мере того, как аппаратное декодирование AV1 охватит последние 20% устройств, однако зависимость WebRTC от VP8 сохранит актуальность обоих кодеков libvpx ещё на долгие годы – вплоть до 2030-х.

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

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

Мы занимаемся видеопродуктами с 2005 года и реализовали более 239 проектов в сфере видеоконференций, видеостриминга, OTT и Internet TV, видеонаблюдения, e-learning, телемедицины и AR/VR. VP8 лежит в техническом ядре каждого real-time пайплайна, который мы сдавали: каждая интеграция WebRTC SFU поставляется с VP8 как базовым кодеком, каждая телемедицинская платформа, которую мы разрабатывали, переключается на VP8, если браузер пациента слишком устарел для поддержки H.264, а каждый конференц-продукт использует временную масштабируемость VP8 поверх SFU, чтобы справедливо распределять пропускную способность в условиях слабой сети. VP9 входит в кодек-лестницу каждого стримингового продукта, где клиенту нужна royalty-free передача 4K на устройствах уровня YouTube без необходимости сразу внедрять дорогостоящий AV1-энкодинг. Диалог «VP9 или сразу AV1» мы ведём со стриминговыми клиентами несколько раз в квартал, и ответ «только AV1» звучит редко: большинство команд используют все три кодека (H.264 + VP9 + AV1) на ближайшие два-три года. Если ваша команда работает над этим решением – мы будем рады обсудить его с вами.

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

• VP8 (2008/2010) и VP9 (2013) – royalty-free кодеки Google, созданные на основе приобретения On2 и распространяемые под неотзывным патентным грантом.
• VP8 является обязательным для реализации видеокодеком WebRTC согласно RFC 7742, поэтому он по-прежнему присутствует в каждом браузере 2026 года.
• VP9 обеспечивает примерно на 40–45% меньший битрейт по сравнению с VP8 и уступает HEVC на 5–15% при одинаковом объективном качестве.
• Аппаратное декодирование VP9 стало повсеместным на Android после 2016 года, на Smart TV после 2015 года и на iOS 14+ (аппаратно – с iPhone 13 Pro и выше).
• Профильная модель VP9 проста: Profile 0 – для SDR, Profile 2 – для HDR; по умолчанию используйте Profile 0 в контейнерах WebM.
• AV1 вытеснил VP9 в качестве следующего поколения по умолчанию на YouTube (75% трафика) и в Netflix (30% трафика), однако VP9 остаётся надёжным royalty-free решением для устройств, не поддерживающих аппаратное декодирование AV1.

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

• AV1: новый стандарт интернета и где он сейчас в 2026 – преемник AOMedia, который напрямую породил VP9.
• H.264 / AVC: рабочая лошадка интернета – кодек, которому VP8 проектировался как royalty-free аналог.
• Сравнительная таблица кодеков – живая, постоянно обновляемая таблица сравнения всех кодеков, используемых в продакшене, по ключевым параметрам, важным для вашей продуктовой команды.