DEV Community

Mason K
Mason K

Posted on

Encode your first VVC clip with vvenc 1.14, then watch every browser refuse to play it

#video #tutorial #ffmpeg #programming

TL;DR

H.266/VVC is the codec behind Brazil's TV 3.0 broadcast standard, and the open-source encoder (VVenC 1.14) is now fast enough to try on a laptop. We'll encode a real clip, mux it into MP4, and then test playback across browsers, FFmpeg, and desktop players to map exactly where VVC does and doesn't work in 2026. Spoiler: your <video> tag says no.

Why bother, if browsers don't play it? Because VVC just got its first massive real-world deployment (Brazilian broadcast TV mandates it, layered with MPEG-5 LCEVC), and "I've actually run the encoder" beats "I read a press release" in every architecture discussion you'll have about codecs this year.

What we're using: VVenC 1.14 (released January 2026), FFmpeg 7.1+ (for a native VVC decoder; FFmpeg 8.0 works too), and optionally GPAC's MP4Box.

1. Get the encoder 🛠️

VVenC is Fraunhofer HHI's open VVC encoder, BSD-3-Clause-Clear licensed. On macOS, Homebrew carries it; everywhere else the cmake build is quick:

# macOS
brew install vvenc

# or build from source (Linux/macOS)
git clone https://github.com/fraunhoferhhi/vvenc.git
cd vvenc
make install-release
# binaries land in bin/release-static/
Enter fullscreen mode Exit fullscreen mode

Check it:

vvencapp --version
Enter fullscreen mode Exit fullscreen mode 
vvencapp: Fraunhofer VVC Encoder ver. 1.14.0
Enter fullscreen mode Exit fullscreen mode

2. Prepare a test clip 🎬

vvencapp eats raw YUV or y4m. Take any 10 to 20 second 1080p clip and unwrap it with FFmpeg:

# clip.mp4 -> raw y4m (this file will be big, that's normal)
ffmpeg -i clip.mp4 -t 15 -pix_fmt yuv420p10le -strict -1 clip_10bit.y4m
Enter fullscreen mode Exit fullscreen mode

💡 Tip: VVC's sweet spot assumes 10-bit. Use yuv420p10le rather than 8-bit so you're testing the codec the way broadcast deploys it.

3. Encode with vvencapp 

vvencapp --preset medium -i clip_10bit.y4m --qp 32 -o clip.266
Enter fullscreen mode Exit fullscreen mode

You'll see per-frame progress and a summary along these lines (numbers are from my run on a laptop, yours will differ):

vvencapp [info]: start encoding...
POC    30 TId: 0 (B-SLICE, QP 35)
...
vvenc [info]: stats summary: frames= 375, bitrate= 2861 kbps
vvenc [info]: Total Time: 214.5 sec [user], 3.5 fps
Enter fullscreen mode Exit fullscreen mode

Two things to notice. First, --preset medium on a modern laptop runs at single-digit fps for 1080p. That's dramatically better than the reference software (Fraunhofer quotes speedups of 20x to 2,400x for VVenC over VTM depending on preset), but it's still far from realtime. Second, try --preset faster and watch fps climb while the bitrate for the same QP rises; that's the whole encoder trade-off surface in two runs.

For a size comparison that's actually yours, encode the same y4m with x265 and SVT-AV1 and put the outputs side by side:

ffmpeg -i clip_10bit.y4m -c:v libx265 -crf 24 -preset slow clip_h265.mp4
ffmpeg -i clip_10bit.y4m -c:v libsvtav1 -crf 32 -preset 6 clip_av1.mp4
ls -lh clip.266 clip_h265.mp4 clip_av1.mp4
Enter fullscreen mode Exit fullscreen mode

I'm deliberately not printing my byte counts here: run it on your own footage, because content complexity dominates codec comparisons and your clip is the only benchmark that matters for you.

4. Mux it into MP4 📦

A raw .266 bitstream won't go far. Recent FFmpeg and GPAC both know how to put VVC in MP4:

# FFmpeg 7.1+
ffmpeg -i clip.266 -c copy clip_vvc.mp4

# or GPAC
MP4Box -add clip.266 -new clip_vvc.mp4
Enter fullscreen mode Exit fullscreen mode

5. Inspect what you made 🔬

Before playing anything, confirm the file is what you think it is. ffprobe from a recent FFmpeg reads VVC fine:

ffprobe -hide_banner clip_vvc.mp4
Enter fullscreen mode Exit fullscreen mode 
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'clip_vvc.mp4':
  Duration: 00:00:15.00, start: 0.000000, bitrate: 2894 kb/s
  Stream #0:0: Video: vvc (vvc1 / 0x31637676), yuv420p10le(tv),
    1280x720, 30 fps, 30 tbr, 15360 tbn
Enter fullscreen mode Exit fullscreen mode

Two details worth noticing in that output. The sample entry is vvc1, the MP4 signaling browsers would need to recognize before anything else could happen; and the pixel format survived as yuv420p10le, confirming you exercised the 10-bit path broadcast actually uses. If you ever need to debug VVC support claims on a device, this vvc1 string is what its media capabilities API has to acknowledge.

# bonus: count how the encoder spent its frames
ffprobe -v error -select_streams v:0 -show_entries frame=pict_type \
  -of csv clip_vvc.mp4 | sort | uniq -c
Enter fullscreen mode Exit fullscreen mode

That little histogram of I/P/B frames is the GOP structure you configured, verified from the bitstream rather than assumed.

6. The playback tour, from success to failure

FFmpeg's native decoder (works):

ffplay clip_vvc.mp4
Enter fullscreen mode Exit fullscreen mode

FFmpeg has shipped a native VVC decoder in recent releases, and current VLC builds play VVC too. Desktop players are fine.

Browsers (do not work): drop this in a console or a test page:

// vvc-support-check.js
const v = document.createElement("video");
console.log("VVC :", v.canPlayType('video/mp4; codecs="vvc1.1.6.L93.B0"') || "(empty = no)");
console.log("AV1 :", v.canPlayType('video/mp4; codecs="av01.0.08M.08"') || "(empty = no)");
console.log("HEVC:", v.canPlayType('video/mp4; codecs="hvc1.1.6.L93.B0"') || "(empty = no)");
Enter fullscreen mode Exit fullscreen mode 
VVC : (empty = no)
AV1 : probably
HEVC: maybe   # hardware-dependent
Enter fullscreen mode Exit fullscreen mode

As of mid-2026 no major browser ships VVC decode. Chrome, Firefox, and Edge decode AV1 natively, and AV1 hardware decode has landed across Apple, Qualcomm, and MediaTek chips. That asymmetry is the entire story of why your web ladder is H.264 + AV1 (+ HEVC for some Apple paths) and not VVC.

7. So where does VVC actually run? 📡

Environment VVC in 2026 Why
Browsers No support in any major browser Patent-pool ambiguity, AV1 already shipped royalty-free
Broadcast TV (Brazil TV 3.0 / DTV+) Mandated, on air since Aug 2025 Standard requires VVC + LCEVC decode in new sets
Smart TV SoCs Arriving in new chipsets Pulled along by broadcast mandates
FFmpeg / VLC Decode works Native decoder in recent releases
Your encode box Works today via VVenC / libvvenc BSD-licensed encoder, practical speeds

The interesting technical wrinkle in Brazil's stack is MPEG-5 LCEVC: not a standalone codec but an enhancement layer over a base codec. V-Nova's TV 3.0 trial figures claim 4K HDR at 8.08 Mbps with VVC+LCEVC versus 12.54 Mbps for VVC alone (vendor numbers, take accordingly). The layered idea is worth knowing even if you never touch VVC, because it can ride on codecs browsers already play.

What's next

  • Point the same workflow at LCEVC and see the enhancement-layer model up close (V-Nova publishes SDKs and the TV 3.0 write-up at v-nova.com).
  • Watch chipset spec sheets, not browser release notes, if you ship connected-TV apps. TV SoCs are where VVC decode will reach your users first.
  • Keep your ladder boring: H.264 floor, AV1 where advertised. The experiment you just ran is exactly why.

Sources: VVenC releases, V-Nova TV 3.0, Streaming Media, State of Streaming Codecs 2026.

Top comments (0)