VP9 — Google's pre-AV1 codec, and why most teams skip it now

VP9 is the codec Google shipped in 2013 as the open-source, royalty-free alternative to HEVC. From 2014 to ~2020, it was the codec YouTube delivered to most of its audience and the codec a meaningful slice of the streaming industry took seriously. Then AV1 finalized in 2018, the AOMedia coalition formed around AV1 as the real royalty-free successor, and VP9 quietly settled into "still serving traffic, no one's choosing it for new pipelines." That's where it remains in 2026.

This page is the engineering reference: what VP9 is, why it had a moment, and the narrow set of cases where you'd still pick it.

#What VP9 is

VP9 is a block-based hybrid video codec, lineage running through Google's On2 acquisition and the VP8 → VP9 evolution. The headline tools relative to VP8/H.264:

• Larger superblocks — up to 64×64, with recursive partitioning down to 4×4. Similar in spirit to HEVC's CTU/CU structure, predates HEVC's standardization.
• Better intra prediction — 10 prediction modes for blocks down to 4×4. Roughly comparable to HEVC's intra modes.
• Improved inter prediction — eighth-pel motion vectors (HEVC has quarter-pel), better motion vector prediction.
• More reference frames — up to 8 active references; HEVC caps at 16 but most codecs use 4-6 in practice.
• Larger transforms — up to 32×32 ADST and DCT variants.
• Loop filter improvements — adaptive filter strength per block, more aggressive than H.264.
• Profile 2/3 for higher bit depth — 10-bit and 12-bit profiles. HDR signaling is supported but ecosystem-thin.

Compression efficiency benchmarks:

• VP9 vs H.264: 40-50% bitrate reduction at equivalent visual quality. Roughly equivalent to HEVC.
• VP9 vs HEVC: roughly tied in most tests, content-dependent. HEVC sometimes wins by 1-3% on natural content; VP9 sometimes wins by similar margin on screen content.
• VP9 vs AV1: VP9 is 20-30% worse than AV1 at equivalent visual quality.

The takeaway: VP9 is in HEVC's quality tier, not AV1's. AV1 obsoletes VP9's compression position; VP9's main remaining advantage is encoder/decoder maturity and royalty-free status.

#libvpx-vp9 in production

libvpx is Google's reference encoder for VP8 and VP9. The VP9 production presets (called --cpu-used or --good):

• --cpu-used 0 to 2 — research-grade, glacially slow.
• --cpu-used 3 to 4 — premium VOD, slow but acceptable.
• --cpu-used 5 — VOD baseline, comparable to x265 medium in encoding speed.
• --cpu-used 6 to 7 — live encoding territory, quality drops noticeably.
• --cpu-used 8 to 9 — real-time, low quality.

libvpx-vp9 is functional but its encoding speed plateaued around 2018. SVT-VP9 (Intel/Netflix) emerged as a faster alternative — same parallelism story as SVT-AV1 — but adoption was limited because by the time SVT-VP9 was production-ready, the industry was already moving to AV1.

In 2026, if you're encoding VP9, you're using libvpx-vp9 with --cpu-used 4-5 for VOD and --cpu-used 6-7 for live. There's not really a second viable open-source VP9 encoder.

#Hardware encode/decode

VP9 hardware decode shipped in roughly the same generation as HEVC, primarily because YouTube needed it for mobile playback:

• Mobile — every Android flagship since 2016 supports VP9 decode in hardware. iPhone added VP9 decode in iOS 14 (2020). Practical install base: ~95% of new traffic, slightly lower for total install base.
• Desktop — Intel Quick Sync added VP9 decode in 7th-gen (Kaby Lake, 2017). NVIDIA shipped VP9 decode in Pascal (2016). AMD followed in Polaris (2016).
• TVs — most smart TVs from 2018+ support VP9 decode for YouTube playback. Some 2017+ models if they targeted YouTube certification.
• Browsers — every Chromium-based browser has supported VP9 decode since launch. Firefox added it in 2014. Safari added VP9 decode in 2020 with macOS Big Sur and iOS 14.

Hardware VP9 encode is much rarer. NVIDIA shipped VP9 encode in Turing (2018) but quality was poor; Ampere (2020) improved it. Intel Quick Sync VP9 encode arrived in 11th-gen (Tiger Lake, 2020). For VOD, software libvpx is what's used; hardware VP9 encode is a niche live use case.

#When VP9 had its moment

The 2015-2020 window is where VP9 made sense as a codec choice:

• Royalty-free — pre-AV1, VP9 was the only royalty-free codec in HEVC's quality tier. Streaming services that wanted to avoid HEVC licensing went to VP9.
• YouTube-driven hardware — hardware decode shipped fast because YouTube needed it. By 2018, most browsers and devices could decode VP9.
• WebM container ecosystem — VP9-in-WebM with Opus audio was the standard combo for browsers. YouTube delivered it; Vimeo delivered it; Netflix experimented with it.

For ~5 years, VP9 was the codec that solved the "we need HEVC quality without the licensing pain" problem. AV1 is what it solves now.

#When VP9 still wins (rarely)

In 2026, the cases where you'd choose VP9 over HEVC or AV1:

• WebRTC media — VP9 is supported across more WebRTC implementations than AV1 is. If your live use case is real-time browser-to-browser and quality matters more than universal compatibility, VP9 is sometimes the answer.
• WebM-only pipelines — if you're constrained to WebM container and royalty-free codecs (rare), VP9 is the most compatible option. This is essentially "I'm building Chromium-only video infrastructure."
• Content that VP9 happens to compress well — screen content, animation, certain UGC patterns. VP9's transform and prediction tooling occasionally beats HEVC by enough margin to matter on specific content. Rare in practice; benchmark before committing.

For consumer streaming in 2026, VP9 is rarely the right answer. AV1 obsoletes the compression case; HEVC has hardware ubiquity advantage; H.264 is the fallback. VP9 is in the awkward middle.

#VP9 vs the field in 2026

#A note on VP9's place in the codec arc

The arc is worth understanding because it explains why VP9 sits where it does. Google bought On2 in 2010 specifically to acquire VP8 and the VP-codec lineage. VP8 was Google's first attempt at a royalty-free codec — quality was disappointing relative to H.264 and adoption stayed thin. VP9 was the second attempt and was much better — quality genuinely competitive with HEVC, royalty-free, hardware decode mandatory for YouTube playback. The combination of YouTube's distribution and Chromium's reach drove broad VP9 adoption between 2014 and 2020.

But by 2018, AV1 had finalized — designed by AOMedia (Google + Netflix + Amazon + Mozilla + Cisco + Intel + Microsoft + Meta + others) as the industry consensus royalty-free codec. AV1 is roughly 20-30% better compression than VP9 with similar licensing freedom. The moment AOMedia formed and AV1 became real, VP9's strategic position evaporated — Google's own roadmap shifted to AV1, and so did the industry's.

This is why, despite VP9 being a perfectly competent codec, it's in maintenance mode: the codec it was meant to be the answer to (HEVC) got its own answer (AV1) before VP9 could complete the displacement story. VP9 is what AV1 obsoletes most cleanly. You can think of VP9 as the bridge generation between "royalty-free codecs were a hope" and "royalty-free codecs are an industry standard," and bridge generations don't tend to be the destination.

#Compression-efficiency caveat

The "VP9 vs HEVC roughly tied" line above hides real content variance. For natural video content (live action, talking heads, mixed-content streaming) HEVC tends to win by a few percent on most well-tuned ladders. For screen content (terminals, code, IDE recordings, slide presentations) VP9 often wins because libvpx's intra prediction tooling handles flat regions and sharp text edges better than x265's defaults. For animation, the codecs trade wins depending on the specific content; both produce excellent output. The practical result: if you've already got a libvpx-vp9 pipeline tuned to your specific content mix, the migration cost to HEVC may not pay off in compression alone — it pays off in ecosystem support. Choose codec primarily on audience reach and licensing, not on the last 1-3% of compression efficiency.

#What MpegFlow does with VP9

MpegFlow's FfmpegExecutor worker image includes libvpx-vp9, so VP9 encoding is configurable as a per-rendition encoder choice in workflow YAML. The DAG runtime expresses each VP9 rendition as a parallel stage on the same DAG that hosts AV1, HEVC, and H.264 stages — same job_stages persistence, same per-stage retry, same sibling cancellation, same rendition-level partial-success reporting.

VP9 isn't in default ladder templates because the cases where VP9 is the right choice are narrow enough that customers who want it know they want it. Two patterns we see: a WebRTC-heavy real-time deployment, and an internal-tooling pipeline that needed royalty-free pre-AV1.

For new pipelines, our default recommendation skips VP9 entirely — AV1 takes the royalty-free top tier, HEVC takes the middle, H.264 takes the floor. VP9 doesn't fit cleanly in that ladder. If you have a specific reason for VP9, we support it; if you don't, you probably don't need it.

The one place where the conversation gets interesting is migration: customers with existing VP9 archives often want to know whether to re-encode to AV1. The answer is "depends on the access pattern" — content that's hot enough to justify re-encode (cost of compute) gets re-encoded; content in cold storage stays on VP9 because the decode side still works fine. That's a customer-specific economics question we work through during onboarding.