VVC (H.266) — the codec MPEG built and the industry hasn't deployed

VVC — Versatile Video Coding, MPEG identifier H.266 — is the codec MPEG, ITU-T, and ISO/IEC finalized in July 2020 as the successor to HEVC. On paper, it's the most compression-efficient mainstream codec ever standardized: roughly 30-50% better than HEVC at equivalent visual quality, comfortably ahead of AV1 in most apples-to-apples tests. In practice, six years after the spec finalized, you can't point to any major streaming service serving VVC to consumers at scale. This page is about why.

#What VVC is

VVC is a block-based hybrid video codec, the same fundamental architecture as H.264, HEVC, AV1, and VP9. The compression gains come from packing more sophisticated tools into each step of the encoding pipeline, not from a new fundamental approach.

The headline tools:

• More flexible block partitioning — Multi-Type Tree (MTT) extends HEVC's quad-tree splitting with binary and ternary splits. Encoder can choose partition shapes that fit content boundaries more closely.
• Larger transforms and CTUs — coding tree units up to 128×128. Better for high-resolution content where flat regions span large areas.
• Cross-component linear modeling (CCLM) — chroma blocks predicted from reconstructed luma. Real chroma compression gains, especially on natural content.
• Affine motion compensation — handles rotation, zoom, and scaling. HEVC's translational-only motion model leaves money on the table for any content with camera motion.
• Bi-directional optical flow (BDOF) — refines bi-predicted blocks at the decoder. Quality at the cost of decode complexity.
• Adaptive loop filter (ALF) — Wiener filter applied per-CTU. Reduces ringing artifacts at low bitrates.
• Geometric partitioning — non-rectangular block splits. Helpful on diagonal edges where rectangular blocks force visible artifacts.

VVC also introduces subpictures — independently decodable sub-regions of a frame. This is the spec's nod toward 360° video, viewport-dependent streaming, and tile-based delivery. None of these have driven significant adoption, but they're in the spec.

#The compression numbers

JVET (the joint MPEG/ITU-T group that developed VVC) and independent bodies have published measurements on JVET test sets. Headline:

• VVC vs HEVC: 30-50% bitrate reduction at the same PSNR/MS-SSIM/VMAF.
• VVC vs AV1: 5-15% bitrate reduction, content-dependent. Animation content favors VVC slightly more; sports content roughly equal.
• VVC vs H.264: roughly 60-70% bitrate reduction.

The 5-15% over AV1 is the number to internalize. It's real but not dramatic — and it comes at significant encoding-complexity cost. AV1 reference encoders run an order of magnitude faster than VVC reference encoders at equivalent quality presets.

For most production content, the encoding-complexity gap matters more than the 10% compression lead. This is why AV1 has shipped in production at major streaming services and VVC has not.

#Encoder ecosystem

The ecosystem is small. As of mid-2026:

#VVenC (Fraunhofer HHI)

Fraunhofer Heinrich-Hertz-Institut maintains VVenC, the production-oriented open-source VVC encoder. It's a successor to (and replacement for) the VTM reference encoder, which was unusably slow for production. VVenC presets faster through slower give a workable speed/quality range — medium is roughly comparable to x265 slow in encoding time, with VVC's compression advantage.

VVenC is the only open-source VVC encoder with realistic production speed. Quality is competitive with HEVC encoders at equivalent presets; the issue is the lack of decoders downstream.

#VTM (reference)

The reference test model from JVET. Highest quality, lowest speed — research-grade. Not a production tool. You see VTM numbers in academic papers and standards proposals but never in real pipelines.

#Commercial encoders

Several silicon vendors have announced VVC encoder IP (Intel, NVIDIA referenced VVC support roadmaps). Few products have shipped consumer-facing. NETINT and Quadra have datacenter VVC accelerators in 2025 product lines, primarily targeting broadcast and content distribution use cases that aren't browser-facing.

#Hardware decode

This is the gating factor. As of mid-2026, shipping consumer devices with hardware VVC decode are essentially nonexistent at meaningful scale:

• Phones — no major Android SoC ships VVC decode. No iPhone supports VVC. Mediatek and Samsung have referenced VVC support in roadmap announcements; nothing in volume devices.
• TVs — Samsung announced VVC support in some 2024+ panels. Practical install base remains small.
• PC GPUs — Intel's Battlemage and AMD's RDNA4 have VVC decode references in spec sheets; user reports on actual functioning are mixed in 2026.
• Browsers — Chromium, Firefox, and Safari don't ship VVC decode. Software-only decode would crush battery on mobile and is not enabled.

Compare to AV1: every Android flagship since Snapdragon 8 Gen 1 (2022), every iPhone 15 Pro+ (2023), most 2022+ smart TVs, every major recent GPU. AV1 has a 4-year head start in the device market that VVC has not closed.

For practical streaming-to-consumers purposes, VVC has no audience in 2026. Software decode is theoretically possible but unfit for production at scale.

#The patent pool problem

VVC inherits HEVC's structural problem: multiple patent pools, fragmented licensing, no royalty-free alternative within the standard.

The known pools as of 2026:

• Access Advance VVC pool — formerly HEVC Advance, the largest aggregator. Per-stream royalties.
• MPEG LA VVC license — MPEG LA's VVC program. Different rate structure, partial overlap with Access Advance members.
• Sisvel VVC pool — Sisvel's VVC pool, with members not represented in the other two.
• Unaffiliated patent holders — claims outside the pools.

The result is the same problem HEVC has — for streaming use, the licensing math is messy enough that legal teams default to "use AV1." This is exactly the pattern AOMedia formed to escape on the HEVC side, and the industry has, broadly, voted with its feet again.

The pools have made gestures toward simplification — single-pool reciprocal licensing, royalty caps for small users — but the structural problem persists. Until there's a single VVC license, browsers will not ship VVC decode, and consumer adoption stays at zero.

#When VVC actually wins

VVC isn't dead. It's not a consumer streaming codec in 2026, but it has live use cases:

• Broadcast — over-the-air DVB-I broadcasts in some regions are using VVC as the next-gen broadcast codec. The set-top box ecosystem is closed enough that licensing is tractable.
• Archive and master encoding — when storage is the constraint and decode happens once internally, VVC's compression advantage matters and the patent issue is irrelevant.
• Premium contribution — broadcast contribution feeds (camera-to-truck, truck-to-station) where the encoding complexity is amortized over a small number of decoders that the broadcaster controls.
• Niche premium streaming — Brazil, Korea, and a few European markets have public-broadcast trials of VVC streaming. Not at scale globally.

The summary: VVC is a real codec for closed ecosystems and storage-constrained workflows. It is not a real codec for consumer streaming.

#VVC vs AV1 — the practical answer

If you're sizing a 2026 codec ladder, this is the question that matters. The honest comparison:

For consumer streaming, AV1 is the answer to "what's the next codec after HEVC?" VVC is the answer to "what codec wins on a benchmark in a paper?" Those are different questions.

#When (if ever) VVC will become a streaming codec

The conditions for VVC to become a consumer streaming codec are clear:

1. Single-pool licensing with rates competitive with HEVC's ~2020 stabilization. Without this, browsers won't ship decode.
2. Hardware decode in flagship Android + iPhone + flagship TVs — practical floor of ~50% mobile install base before serving VVC at scale makes sense.
3. Browser support — Chromium, Firefox, Safari shipping decode, even if behind feature flags initially.

None of these are short-term. Realistically, VVC becomes a consumer streaming option no earlier than 2028, and probably not until 2030. By then, the post-VVC codec (already in research at MPEG and AOMedia) will be in early standardization, and the "next codec" question will reset.

#What MpegFlow does with VVC

VVC / H.266 is not a currently shipped encoder in MpegFlow's FfmpegExecutor worker image. The default worker build covers x264, x265, SVT-AV1, libvpx-vp9, FDK-AAC, libopus, and libvmaf; it does not include VVenC. VVC is on the backlog for evaluation when consumer-streaming demand justifies the worker-image expansion, and is not a 2026 production answer in MpegFlow today.

If you're sizing a 2026 ladder for consumer streaming, our standing recommendation is the three-codec AV1 → HEVC → H.264 design — all three of those encoders are in the worker image today and exposed through standard FfmpegExecutor parameters.

If your use case is broadcast, archive, or one of the closed-ecosystem deployments where VVC's compression advantage actually translates to value — that's a different conversation, and one we have when it's the real shape of the workflow. Adding VVenC to the worker image is a deployment-level change rather than a per-workflow toggle today.