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

TL;DR

VP8 и VP9 – это два видеокодека, то есть программы, которые упаковывают сырое изображение в маленький файл и распаковывают обратно. Google выпустил их без роялти после того, как в феврале 2010 года купил разработчика кодеков On2 Technologies за 124,6 млн долларов.1 VP8 вышел в мае 2010 года как обязательный видеокодек для WebRTC-браузеров и как ключевой формат картинки внутри открытого контейнера WebM; VP9 появился в июне 2013-го с примерно 50%-ным выигрышем по битрейту относительно VP8 при том же воспринимаемом качестве и долгие годы был кодеком, в котором YouTube отдавал всё видео выше 720p.23 В 2026 году VP9 занимает около 13% в профессиональных стриминговых пайплайнах по данным Bitmovin Video Developer Report и остаётся вторым по распространённости кодеком внутри продакшен-стэков 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».

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

Если вы делаете продукт с видеосвязью в реальном времени – видеоконференцию, веб-звонки, customer-support video, 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-tag некоторых файлов Matroska). On2 выпустила VP3 в 2001 году (его потом подарили 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, Google выпустил спецификацию VP8 под неотзывной royalty-free патентной лицензией, открыл референсный энкодер и декодер как libvpx под BSD-style лицензией и положил VP8 вместе с аудиокодеком Vorbis в Matroska-based контейнер WebM.2 Цель была заявлена явно: дать вебу royalty-free альтернативу 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 в 124,6 млн долларов на On2 была прямым ответом на эту неопределённость.

Цепочка решений началась не в 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 profile – примерно та же эффективность сжатия на простом контенте, чуть хуже на сложном, но рабочий и шипящий – и шёл вместе с неотзывным royalty-free патентным грантом. Mozilla и Opera поставили VP8 за несколько месяцев. Adobe добавил VP8 во Flash. Google добавил VP8 в Chrome и YouTube. Microsoft и Apple напрямую VP8 не приняли, но сам факт существования royalty-free альтернативы заставил MPEG LA в августе 2010 года публично пообещать, что H.264 никогда не будет брать роялти за интернет-видео, бесплатное для конечного пользователя. Это сняло прямую угрозу, которая и спровоцировала кодек-войну.2

Вторая ключевая развилка – стандарт WebRTC. Когда IETF и W3C кодифицировали браузер-к-браузеру видеосвязь в 2011–2016 годах, рабочая группа опять не смогла договориться об одном обязательном кодеке. Компромисс, опубликованный как RFC 7742 в марте 2016 года, сделал и 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 именно для того, чтобы выйти из-под per-stream-роялти на 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 году и пересёк рубеж 75% новых загрузок в 2025-м. Netflix добавил AV1 в 2020 году и к концу 2025-го дошёл до 30% трафика стриминга – полное покрытие AV1-HDR10+ каталога планируется на начало 2026 года.5 VP9 никуда не исчез, но стал кодеком, который ставят как альтернативу H.264 для устройств, слишком старых для AV1, а не дефолтным выбором нового поколения.

Это и есть фон любой проектной дискуссии 2026 года про VP8 или VP9. У этих двух кодеков нет маркетингового бюджета, патентной драмы или roadmap новых фич. Это инфраструктура: 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 на половине пикселя и билинейный на четверти), допускает до трёх референсных кадров (last frame, golden frame, alt-ref frame) и вводит концепцию 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-кадры (двунаправленные predicted frames, ссылающиеся и на прошлые, и на будущие кадры). Механизм 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 разрешает прямоугольные разбиения на каждом уровне (superblock 64×64 может, например, разделиться на две половины 64×32 или 32×64), что реально полезно на контенте с сильным горизонтальным или вертикальным движением – панорамах и экранном тексте.37

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

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

Парадоксально, но у VP9 всего 10 режимов intra-предсказания – меньше, чем 35 у HEVC. Хитрость в том, что моды VP9 спроектированы покрывать наиболее частые направления краёв эффективно – вертикаль, горизонталь, несколько ближних к диагональным, плюс 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-tap для luma, а не 6-tap у VP8. Энкодер может использовать до трёх одновременных референсных кадров на блок (как и VP8, но с более умными эвристиками выбора), включая alt-ref frame, унаследованный от VP8 и используемый в VP9 гораздо агрессивнее. Подробности – в Inter-frame coding и motion estimation.

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

VP8 использовал только трансформ 4×4. VP9 добавляет integer-трансформы 8×8, 16×16 и 32×32, плюс Asymmetric Discrete Sine Transform (ADST) для блоков, где остаток предположительно имеет асимметричное распределение энергии (край движущегося объекта, например). Трансформ 32×32 DCT на больших плоских областях даёт существенный выигрыш на 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

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

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

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

Независимые академические измерения раз за разом ставят VP9 примерно на 40–45% впереди VP8 (чуть ниже цели Google в «50%» в среднем), примерно на 5–15% позади HEVC при равном объективном качестве на HD и UHD и примерно на 25–30% позади AV1.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. Profile 0 – практический дефолт для стриминга; Profile 2 – HDR-профиль, единственный другой с сколько-нибудь значимым аппаратным покрытием.

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

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

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

Если вы отгружаете какое-либо real-time видео – видеосвязь, конференции, customer-support video, 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) выборочно дропать кадры на участника, когда сеть проседает – это и есть тот conferencing-выигрыш, ради которого VP8 в своё время взяли. И лицензия – реально бесплатна.

Компромисс в том, что компрессия VP8 не лучше H.264 Baseline. На современном конференц-железе, которое может позволить себе H.264 High Profile или VP9, отказ от VP8 даёт измеримую экономию пропускной способности при той же MOS. Большинство продакшен-стэков WebRTC поэтому держат VP8 как floor-кодек, переходят вверх к 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 универсален на Android SoC после 2016 года (Qualcomm Snapdragon 820+, MediaTek Helio P-series и старше, Samsung Exynos 8895 и старше, все Google Tensor) и на Smart TV-чипсетах после 2015 года (большинство моделей 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 для 2-pass VOD и -speed 4 для live, плюс -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-бит 4:2:0 – это битовая глубина и chroma layout, нужные для HDR. Но HDR transfer function (PQ или HLG), primaries (BT.2020) и mastering display metadata всё равно надо просигналить в битстриме и контейнере. См. Полный гид по 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 собирает per-frame statistics, потом медленный второй проход на -speed 1 использует эту статистику, чтобы умно распределить биты. -row-mt 1 включает row-based multi-threading внутри каждого тайла. -tile-columns 2 позволяет декодеру параллелиться по 4 тайлам на 1080p. Режимы rate control мы разбираем в 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 – это constant-quality режим (аналог -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

Фиксированный двухсекундный keyframe-интервал (-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 как floor-кодеком, каждая телемедицинская платформа, которую мы строили, откатывается на VP8, когда браузер пациента слишком старый, чтобы договориться о H.264, каждый конференц-продукт надстраивает temporal scalability 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 – обязательный mandatory-to-implement видеокодек 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 как next-generation дефолт на YouTube (75% AV1) и в Netflix (30% трафика), но VP9 остаётся безопасным royalty-free выбором для хвоста устройств без аппаратного AV1.

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

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