VP8 And VP9: Google's Open Alternative

Published 2026-05-16 · 17 min read · By Nikolay Sapunov, CEO at Fora Soft

Why This Matters

If you build a real-time video product — video calling, conferencing, customer-support video, live shopping, online tutoring, telemedicine — you ship VP8 today whether you planned to or not, because every WebRTC browser is required to implement it. If you build a streaming product, you decide whether to encode a VP9 ladder for the long-tail of devices that decode VP9 but not AV1 (every Android phone since 2016, every Chrome and Firefox install, Safari on iOS 14 and later, every smart-TV chipset since 2017). And if you are anywhere in the open-source video pipeline, you almost certainly link against libvpx, the reference implementation Google maintains for both codecs and that FFmpeg uses by default.

This article explains what VP8 and VP9 actually are, walks through the On2 → Google → AOMedia lineage that produced them, lays out the technical differences from the H.264 / H.265 family without assuming any prior codec knowledge, and ends with the 2026 deployment question every video product team faces: where each codec still earns its keep, and where AV1 has already taken over. You do not need prior knowledge of codecs to follow it — every term is defined in plain language before it appears. If you have not yet read H.264 / AVC: The Workhorse Of The Internet and H.265 / HEVC: +50% Over H.264 And The Patent Nightmare, those are the prerequisites: VP8 was designed as a royalty-free counterpart to H.264, and VP9 as a royalty-free counterpart to HEVC.

What VP8 And VP9 Actually Are

A codec is two pieces of software glued together: an encoder that takes raw pictures coming out of a camera or a video editor and packs them into a small file, and a decoder that reverses the process to put the pictures back on screen. The name is a portmanteau — coder + decoder. VP8 and VP9 are codecs in this sense, just like H.264 and H.265, and they slot into the same place in a video pipeline.

The naming is older than Google's involvement. The VPx family was developed by a small US company called On2 Technologies (originally founded in 1992 as The Duck Corporation, a name that still appears in some Matroska container codec tags). On2 shipped VP3 in 2001 (later donated to the Xiph.Org Foundation and renamed Theora), then VP4, VP5, VP6, and VP7 as a steady stream of proprietary codecs sold mostly to Adobe Flash for early online video. VP8 was On2's last release as an independent company, announced on 13 September 2008.¹

The headline event for VP8 came eighteen months later. On 5 August 2009 Google announced it was acquiring On2, and on 19 February 2010 the deal closed for $124.6 million.³ Three months later, on 19 May 2010 at Google I/O, Google did something nobody in video had done at this scale before. Instead of monetising On2's patents, Google released the VP8 specification under an irrevocable royalty-free patent licence, open-sourced the reference encoder and decoder as libvpx under a BSD-style licence, and bundled VP8 with the Vorbis audio codec inside a Matroska-derived container called WebM.¹ The intent was explicit: provide the web with a royalty-free alternative to H.264, which was at that point still trying to figure out whether its MPEG LA patent pool would charge per-stream royalties on internet video.

VP9 followed on the same model. Development began in late 2011, and the first VP9-encoded bitstreams were live on YouTube in June 2013 — the same month the spec was frozen.² The compression target was straightforward: halve the bitrate of VP8 at the same perceptual quality, putting VP9 in roughly the same competitive position against HEVC that VP8 occupied against H.264. VP9 was royalty-free from day one, again under an irrevocable Google patent grant, and again with libvpx as the reference implementation.

The third act of the same story is AV1, which is not a VPx codec but is the direct descendant of the lineage. In September 2015 — six months after the HEVC Advance patent pool launched and made HEVC's licensing future look unworkable — Google, Amazon, Cisco, Intel, Microsoft, Mozilla, and Netflix founded the Alliance for Open Media (AOMedia). The first project was a royalty-free successor codec, built by merging the best ideas from Google's VP10 (the in-progress VPx successor), Cisco's Thor, and Mozilla's Daala. The result was AV1, published in March 2018, and explicitly designed to retire VP9 in the same way VP9 had been designed to retire VP8. We unpack AV1 in detail in AV1: The New Internet Standard And Where It Stands In 2026.

That is why this article covers VP8 and VP9 together but does not include AV1. The two VPx codecs share a corporate parent, a licence model, a reference implementation, and a container; AV1 inherits the licence model and the reference-implementation pattern, but its bitstream was rebuilt from scratch under AOMedia.

Figure 1. The VP8 → VP9 → AV1 timeline. The cadence is roughly five years per generation, with a corporate change of vehicle (On2 → Google → AOMedia) at each step.

A Short History: From Flash Plug-in To WebRTC Default

The reason VP8 and VP9 exist is to give the web a video codec that nobody has to pay royalties to use. That sentence sounds obvious in 2026, but in 2008–2010 it was a genuinely open question whether browser-delivered video was going to be subject to per-stream royalties, and Google's $124.6M bet on On2 was a direct answer to that uncertainty.

The chain of decisions started outside Google. The HTML5 <video> element was being standardised at the W3C between 2007 and 2010 without a mandatory codec, because the working group could not agree on one. Apple wanted H.264 (which it already supported across iOS and Safari). Mozilla and Opera wanted Theora (the open codec descended from On2 VP3) because they were unwilling to ship a patent-encumbered codec inside a free browser. Microsoft wanted H.264. The fight was real, and a video industry that depended on Adobe Flash for cross-browser playback was watching closely.

Google's release of VP8 in May 2010 reframed the conversation. VP8 was technically close to H.264 baseline profile — roughly the same compression efficiency on simple content, somewhat worse on hard content, but real and shipping — and it came with an irrevocable royalty-free patent grant. Mozilla and Opera shipped VP8 within months. Adobe added VP8 to Flash. Google added VP8 to Chrome and to YouTube. Microsoft and Apple did not adopt VP8 directly, but the existence of a royalty-free option pushed MPEG LA in August 2010 to commit publicly that H.264 would never charge for free-to-end-user internet video, which removed the immediate threat that had triggered the codec war in the first place.¹

The second turning point was the WebRTC standard. When the IETF and W3C codified browser-to-browser real-time video between 2011 and 2016, the working group again could not agree on a single mandatory codec. The eventual compromise, published as RFC 7742 in March 2016, made both VP8 and H.264 Constrained Baseline mandatory-to-implement in every WebRTC browser.⁴ That decision is why VP8 still has 100% browser support in 2026, fifteen years after release. Every Chrome, Firefox, Safari, and Edge install on every desktop and every Android phone ships a VP8 encoder and decoder by mandate of the WebRTC spec.

The third turning point was YouTube's adoption of VP9 between 2013 and 2018. YouTube switched its 1080p and 4K streaming tiers to VP9 specifically to escape the per-stream royalty exposure on H.264 and HEVC at scale, and the move forced every Android device manufacturer, every smart TV vendor, every set-top box, and every browser to support VP9 hardware decode or lose access to YouTube's catalogue. By 2018, VP9 hardware decode was effectively universal on Android phones manufactured after 2016 and on smart TVs manufactured after 2015.²

The fourth and final turning point was AV1. Once AOMedia shipped AV1 1.0 in 2018 and announced its members would replace HEVC and VP9 with AV1 wherever they could, the practical question for every greenfield deployment became "skip VP9 and go straight to AV1". YouTube began AV1 encoding in 2018 and crossed 75% of new uploads in 2025. Netflix added AV1 in 2020 and reached 30% of streaming traffic by late 2025 with full AV1-HDR10+ catalogue coverage planned for early 2026.⁶ VP9 did not disappear, but it became the codec you ship as the H.264 alternative for the device tail too old to decode AV1, rather than the next-generation default.

That is the story behind every 2026 video product decision involving VP8 or VP9. The two codecs do not have a marketing budget, a patent-pool drama, or a new feature roadmap. They are infrastructure: VP8 is the WebRTC video codec, VP9 is the open-source middle codec between H.264 and AV1, and both are kept current by libvpx because the whole video industry depends on them whether or not anybody plans to deploy them next.

How VP8 Works, In Plain Language

VP8 is a hybrid block-based codec in the same broad architecture as H.264. We unpack the hybrid framework in Hybrid Video Codec Architecture; here the key idea is that VP8 cuts each frame into small rectangular blocks, predicts each block from its neighbours, encodes only the small leftover (the residual), and uses an entropy coder to write the residual bits efficiently into the bitstream.

VP8 made four concrete choices that distinguish it from H.264.

Block size. VP8 uses fixed 16×16 macroblocks like H.264 did, with sub-partitions down to 4×4 pixels for intra-prediction and 4×4 for motion compensation. There is no quadtree split.

Intra-prediction modes. VP8 offers 10 intra-prediction modes for 16×16 blocks and 10 for 4×4 blocks (vertical, horizontal, DC, and several diagonal directions). H.264 has 9 for 4×4 blocks and 4 for 16×16. The numerical gap is small.

Motion compensation. VP8 supports quarter-pixel motion vectors with a 6-tap interpolation filter (compared to H.264's 6-tap filter at half-pixel plus bilinear at quarter-pixel), allows up to three reference frames (last frame, golden frame, alt-ref frame), and introduces the alt-ref frame concept — an invisible reference frame the encoder can synthesise to improve prediction of future frames.

Loop filter and entropy coder. VP8 has one in-loop deblocking filter and uses a boolean arithmetic coder (a simplified arithmetic coder) instead of H.264's CABAC. The arithmetic coder is a deliberate compromise — easier to license around the H.264 patents, slightly less efficient in pure compression terms.

The net result is that VP8 is approximately equivalent to H.264 Baseline Profile on most content: comparable compression on simple sources, somewhat worse on hard sources (complex motion, high detail, low bitrate), and noticeably worse than H.264 High Profile (which adds 8×8 transforms, CABAC, and B-frames that VP8 lacks). In a streaming context this gap is real but small; in a WebRTC context, where everyone codes at low bitrates and short GOPs, it does not matter and VP8 routinely matches H.264 Baseline at the same Mean Opinion Score (MOS).

The one thing VP8 does not have is B-frames (bidirectional predicted frames that reference both past and future frames). The alt-ref frame mechanism partially compensates by giving the encoder an invisible reference to predict from, but the absence of true B-frames is the main reason VP8 falls short of H.264 High Profile.

How VP9 Works: The Five Wins Over VP8

VP9 keeps the hybrid block-based framework and rebuilds every stage of it. There are five places where VP9 earns its roughly 50% bitrate saving over VP8.

1. Superblocks instead of macroblocks

VP9 throws out the fixed 16×16 macroblock and replaces it with a superblock of 64×64 pixels, recursively split into smaller prediction blocks down to 4×4 through a quadtree. Compared to HEVC, where the Coding Tree Unit (CTU) quadtree is restricted to square partitions, VP9 allows rectangular partitions at every level (a 64×64 superblock can split into two 64×32 or 32×64 halves, for instance), which is genuinely useful on content with strong horizontal or vertical motion such as panning shots and on-screen text.²⁸

The mental picture is the same chessboard-of-subdividable-squares from HEVC, with the extra freedom that any square can also be cut into two rectangles instead of four quadrants. On flat regions (sky, walls, gradients) VP9 uses one 64×64 block and saves bitrate; on textured or moving regions it subdivides as needed.

2. Ten intra-prediction modes, with smarter primary modes

Counter-intuitively, VP9 has only 10 intra-prediction modes, fewer than HEVC's 35. The trick is that VP9's modes are designed to cover the most common edge directions efficiently — vertical, horizontal, several near-diagonal, plus DC and TM (TrueMotion) average modes — and combine with the rectangular partitioning above to match real-content edges with fewer mode bits. The mode-count gap is one of the technical reasons VP9 falls slightly short of HEVC in head-to-head Bjøntegaard Delta Bitrate tests, by a margin most measurements put in the 5–15% range depending on content and bitrate.⁷

3. Better motion: eighth-pixel vectors, three references, larger search

VP9 sharpens VP8's motion compensation in three places. Motion vectors are precise to 1/8 of a pixel (against VP8's 1/4-pixel and H.264's 1/4-pixel), and the interpolation filter is 8-tap for luma rather than VP8's 6-tap. The encoder may use up to three simultaneous reference frames per block (the same count as VP8 but with smarter selection heuristics), including the alt-ref frame inherited from VP8 and used much more aggressively in VP9. See Inter-Frame Coding And Motion Estimation for the broader story.

4. Bigger transforms, a new asymmetric transform

VP8 used only a 4×4 transform. VP9 adds 8×8, 16×16, and 32×32 integer transforms, plus an Asymmetric Discrete Sine Transform (ADST) for blocks where the residual is expected to have asymmetric energy distribution (the edge of a moving object, for instance). The 32×32 DCT on large flat areas is a substantial win on UHD content for the same reason CTUs are: bigger transforms compress smooth gradients dramatically better. We cover the transform-coding family in Transform Coding: DCT, ADST, Integer Transforms.

5. Tile-based parallelism

VP9 was designed for multi-core decoding from day one. The picture is divided into vertical tiles (and optionally horizontal tile rows in newer libvpx versions) that can be decoded independently. Combined with row-based multi-threading in libvpx (-row-mt 1 in FFmpeg), this lets a single VP9 decoder saturate eight or more CPU cores at 4K60 — something VP8's serial, macroblock-by-macroblock decoder cannot do.⁹

The cost of all five wins is encoder complexity. libvpx-vp9 at its quality-balanced -speed 1 preset is roughly 3–8× slower than libvpx-vp8 at comparable quality settings, and 5–15× slower than libx264 at comparable presets.⁹ Decoder complexity is more modest — roughly 2× the work of a VP8 decoder, comfortably within the budget of any 2026 device.

Figure 2. The VP9 encoder pipeline. The five stages are the same as VP8 — predict, transform, quantize, code, filter — but each stage was redesigned for roughly twice the compression, at the cost of 3–8× the encoder CPU.

The exact compression number — and where it falls short

Independent academic measurements have repeatedly placed VP9 about 40–45% ahead of VP8 (slightly under Google's "50%" target on average), about 5–15% behind HEVC at matched objective quality on HD and UHD content, and about 25–30% behind AV1.⁷ On low-bitrate, low-resolution content the gap to HEVC narrows or reverses — VP9 sometimes beats HEVC at sub-720p sub-1 Mbps streaming because its rectangular intra partitions match small-block edges better than HEVC's square-only intra partitions. On high-bitrate, high-resolution content, VP9 trails HEVC by closer to 15%.

The honest summary is the one Iain Richardson's Vcodex briefs have used for years: VP9 is HEVC-class compression with a permissive licence and slower encoders.

VP9 Profiles And Levels — What You Actually Ship

VP9 has a much smaller profile and level matrix than HEVC because it covers a narrower set of use cases. Four profiles are defined, named Profile 0 through Profile 3, each adding a feature on top of the previous one.²

Table 1. The four VP9 profiles. Profile 0 is the practical default for streaming; Profile 2 is the HDR profile and the only other one with meaningful hardware decode coverage.

VP9 levels (Level 1 through Level 6.2) cap resolution, frame rate, and bitrate in roughly the same shape as HEVC levels, scaled to VP9's bitstream syntax. Level 5.1 (4K60, 60 Mbps cap) is the practical default for 4K streaming. Level 6.1 caps 8K60. Most consumer hardware that advertises VP9 support is Level 5.1 capable; some 2024–2026 TVs and the latest Android flagships support Level 6.1.

The WebM container is the natural delivery wrapper for VP9. WebM is a profile of Matroska (MKV) restricted to VP8/VP9 video and Vorbis or Opus audio. Browsers serve VP9 inside WebM by default; smart TVs and Android devices accept VP9 inside MP4 as well. See Containers: MP4, FMP4, MKV, WebM, MOV, MPEG-TS for the container side of the story.

VP8 In WebRTC, And Why It Still Matters In 2026

If you ship any kind of real-time video — video calling, conferencing, customer-support video, live shopping, telemedicine, e-learning, online tutoring — you ship VP8 today because RFC 7742 requires every WebRTC browser to implement it as a mandatory-to-implement (MTI) video codec.⁴ H.264 Constrained Baseline is the other MTI codec, and VP9 and AV1 are increasingly common as negotiated optional codecs, but VP8 is the codec the browsers will always have in common when the SDP offer/answer exchange fails to find anything better. We cover the SDP and ICE machinery in WebRTC In Depth: SDP, ICE, STUN/TURN, SFU Vs MCU.

The practical reasons VP8 wins inside WebRTC are mostly non-compression reasons. VP8's encoder is fast enough to run in real time on any device built after 2012. Its bitrate adapts cleanly to changing network conditions because the encoder has no B-frames to reorder and no complex pyramid GOP structure to recover from after a packet loss. Its temporal scalability modes (also reused by VP9 and AV1) let an SFU (Selective Forwarding Unit) drop frames selectively per participant when the network shifts — the conferencing-side win that made VP8 attractive in the first place. And the licence cost is genuinely zero.

The trade-off is that VP8's compression is only as good as H.264 Baseline. On modern conferencing hardware that can afford H.264 High Profile or VP9, switching off VP8 saves measurable bandwidth at the same MOS. Most production WebRTC stacks therefore offer VP8 as the floor codec, negotiate up to H.264 / VP9 / AV1 when the peer supports it, and fall back to VP8 only when SDP negotiation produces no other match — which still happens routinely on cross-browser, cross-platform, cross-version calls.

Browser And Hardware Decode Support In 2026

The 2026 support picture for VP8 and VP9 is essentially universal on the browser side and Android-dominant on the hardware-decode side.

Browsers. VP8 software decode ships in every Chrome, Firefox, Safari, and Edge in 2026 because of the WebRTC MTI requirement. VP9 software decode also ships in every major browser; Safari added VP9 in iOS 14 / macOS Big Sur (2020), Edge supports VP9 on every platform Chromium does, Chrome and Firefox have shipped VP9 since 2013.²

Hardware decode. VP9 hardware decode is universal on Android SoCs manufactured after 2016 (Qualcomm Snapdragon 820+, MediaTek Helio P-series and later, Samsung Exynos 8895 and later, all Google Tensor) and on smart-TV chipsets manufactured after 2015 (most Samsung, LG, Sony, Vizio, TCL, and Hisense models). On iOS, Safari plays VP9 in software on every device since iPhone 6s, with hardware decode added on the A15 Bionic and later (iPhone 13 Pro and later, M3-class Macs).¹⁰ On Windows, every modern Intel, AMD, and Nvidia GPU includes VP9 hardware decode. The only sizeable gap is Chrome on Linux, where VP9 software decode is universal but hardware decode is patchy because of inconsistent VA-API support.

VP8 hardware decode is rarer because the use case is real-time WebRTC, where the encode side is the bottleneck and the bitrate is usually low enough that CPU decode is fine. Most modern Android SoCs include VP8 hardware decode as a bonus alongside VP9, but VP8 hardware encode is unusual — most devices do VP8 encode on the CPU through libvpx.

Common Pitfalls (Read Before Encoding)

A short list of mistakes we have repeatedly seen video teams make when they adopt VP8 or VP9.

Pitfall: shipping VP9 in a video/mp4 MIME type without checking the player. VP9 inside MP4 (video/mp4; codecs="vp09.00.10.08") is supported on Chrome, Edge, Firefox, and Android, but Safari and iOS historically prefer VP9 inside WebM. Test the MP4 path explicitly on Safari before committing to one container for both ladders.

Pitfall: encoding VP9 at libvpx defaults and accepting the result. libvpx-vp9's default -speed 0 is excruciatingly slow and produces only marginally better quality than -speed 1 or -speed 2. Most production ladders use -speed 1 for 2-pass VOD and -speed 4 for live, with -row-mt 1 and -tile-columns set to roughly log2(width / 256). Without those flags, libvpx-vp9 can be 20× slower than necessary.

Pitfall: forgetting alt-ref frames. The single biggest quality knob on libvpx-vp9 is auto-alt-ref 1 plus lag-in-frames 25, which enables the VP9 alt-ref mechanism. Encoders that disable alt-ref (or run with lag-in-frames < 12) leave 3–10% of compression on the table.⁹

Pitfall: assuming VP9 Profile 2 is "VP9 HDR ready". VP9 Profile 2 covers 10/12-bit 4:2:0, which is the bit depth and chroma layout needed for HDR — but the HDR transfer function (PQ or HLG), primaries (BT.2020), and mastering display metadata still have to be signalled in the bitstream and container. See The Complete Guide To HDR: HDR10, HDR10+, Dolby Vision, HLG.

Pitfall: deploying VP9 to escape AV1's encoder cost without checking AV1's hardware decode footprint. As of 2026, 80% of consumer devices decode AV1 in hardware (Intel, AMD, Nvidia, Apple A17 Pro and later, every Pixel since the 6, every Galaxy S22 and later). VP9 hardware decode is broader but the gap is narrowing. If you are picking VP9 over AV1 in 2026 it should be because the encode cost matters today and you plan to revisit, not because AV1 lacks decoders.

VP9 In FFmpeg: The Commands You Will Actually Use

Three commands cover roughly 90% of the VP9 encoding work most video teams do. The encoder is libvpx-vp9, the open-source reference implementation Google maintains. All three commands assume FFmpeg 6 or later with libvpx enabled at compile time.

# 1) 2-pass VOD encode, 1080p60, target 3 Mbps, 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

The two-pass structure is the standard libvpx recipe: a fast first pass at -speed 4 gathers per-frame statistics, then a slower second pass at -speed 1 uses those statistics to allocate bits intelligently. -row-mt 1 enables row-based multi-threading inside each tile. -tile-columns 2 lets the decoder parallelise across 4 tiles at 1080p. We cover rate control modes in Rate Control: CBR, VBR, CRF, ABR, Capped CRF.

# 2) 4K HDR Profile 2 encode (10-bit BT.2020 PQ), single pass 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

The -crf 28 -b:v 0 pair is constant-quality mode (analogous to x265's -crf): VP9 picks whatever bitrate the picture needs to hit the target perceptual quality. -pix_fmt yuv420p10le is mandatory for Profile 2. The colour signalling (-color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc) is what makes the file display as HDR on a compatible player; without it, the file is a 10-bit SDR file.

# 3) Live RTMP / WebRTC ingest, 720p30, single pass 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

The fixed two-second keyframe interval (-g 60 at 30 fps), -error-resilient 1, and lag-in-frames 0 are what make the stream low-latency and recoverable after packet loss. -speed 6 is the realtime preset. See Streaming Protocols: The 8 That Matter In 2026 for the protocol side.

VP8 / VP9 Vs The Field: Codec Comparison In 2026

The honest comparison includes the five codecs your product manager will mention in a budget meeting.

Table 2. Codec landscape in 2026. VP8 is the WebRTC default; VP9 is the royalty-free middle codec between H.264 and AV1; AV1 is the new royalty-free top of the line. We maintain a live version of this table at Codec Comparison Matrix.

The reading of this table we offer in product reviews: VP8 is unavoidable inside WebRTC; VP9 is the safe royalty-free alternative for the device tail that lacks AV1 hardware decode; AV1 is the default for everything else. VP9 will fade out gradually over the next five years as AV1 hardware decode reaches the last 20% of the device market, but the WebRTC dependence on VP8 will keep both libvpx codecs current well into the 2030s.

Figure 3. The codec landscape in 2026 at a glance. VP8 and VP9 sit on the royalty-free side with universal browser coverage; their compression efficiency is the middle of the pack.

Where Fora Soft Fits In

We have been building video products since 2005 and shipped 239+ projects across video conferencing, video streaming, OTT and Internet TV, video surveillance, e-learning, telemedicine, and AR/VR. VP8 is in the technical core of every real-time pipeline we have delivered — every WebRTC SFU integration ships VP8 by default as the floor codec, every telemedicine platform we have built falls back to VP8 when the patient's browser is too old to negotiate H.264, every conferencing product layers VP8's temporal scalability over an SFU to keep bandwidth honest on weak networks. VP9 sits in the codec ladder of every streaming product we have built where the client wanted a royalty-free 4K rendition for the YouTube-class device tail without committing to the AV1 encoder cost on day one. The "VP9 or skip to AV1" conversation is one we have several times a quarter with streaming clients, and the answer is rarely "AV1 only" — most teams ladder all three (H.264 + VP9 + AV1) for the next two to three years. If your team is working through that decision, that is a conversation we are happy to have with you.

What To Read Next

• AV1: The New Internet Standard And Where It Stands In 2026 — the AOMedia successor that VP9 directly produced.
• H.264 / AVC: The Workhorse Of The Internet — the codec VP8 was designed as a royalty-free counterpart to.
• Codec Comparison Matrix — the live, continuously updated comparison of every production codec on every dimension your product team needs.

Talk To Us / See Our Work / Download

• Talk to a video engineer — book a 30-minute scoping call.
• See our case studies — 239+ shipped video projects across OTT, streaming, video conferencing, surveillance, e-learning, telemedicine, and AR/VR.
• Download the VP8 / VP9 cheat sheet — one-page A4 reference with the profile/level matrix, the libvpx FFmpeg recipes, and the 2026 browser/hardware support snapshot.

References