dav2d shipped before AV2 froze — that's the whole strategy

4 min read 1 source clear_take
├── "Writing the decoder in parallel with the spec is the real innovation — it changes who controls the standard"
│  ├── Jean-Baptiste Kempf (jbkempf.com) → read

Kempf published dav2d as a from-scratch BSD-licensed AV2 decoder while the AOMedia spec is still mutating, explicitly stating it tracks the in-progress standard and will need rewrites as tools are accepted or dropped. His position is that implementing alongside standardization — rather than after it — is the right sequencing, and it's the same playbook that made dav1d the de facto AV1 decoder.

│  └── @captain_bender (Hacker News, 362 pts) → view

By submitting dav2d to HN and driving 362 points of engagement, the submitter framed the story around the parallel-development angle rather than treating it as just another codec release. The thread's energy centered on the idea that a working BSD decoder before spec freeze meaningfully shifts who gets to define 'AV2 compliant.'

└── "Open decoders shipping early break the patent-pool capture cycle that plagued H.264 and HEVC"
  └── top10.dev editorial (top10.dev) → read below

The editorial argues the video codec industry has a recurring failure mode where late, slow reference code lets proprietary players define the market and lock in licensing terms before open implementations catch up. dav1d broke that pattern for AV1 by arriving fast and free, and dav2d is positioned to do the same for AV2 — preempting the H.264/HEVC trajectory entirely.

What happened

Jean-Baptiste Kempf, VideoLAN president and the lead behind dav1d, published an early build of dav2d — a from-scratch decoder for AV2, the successor to AV1 currently being drafted inside the Alliance for Open Media. The repo is BSD-licensed, written in C with hand-tuned assembly paths, and follows the same architectural template as dav1d.

The twist worth lingering on: AV2 is not done. AOMedia's bitstream is still mutating — coding tools are being proposed, accepted, dropped, and renumbered as the working groups iterate. Kempf's blog post is explicit that dav2d tracks the in-progress spec and will need to be rewritten in places as the standard settles. He's not waiting for v1.0. He's writing the decoder *alongside* the people writing the spec.

That sequencing — implementation in parallel with standardization rather than after it — is the actual story here, not the existence of another AV2 codec. The HN thread (362 points) lit up around exactly this point: a working BSD decoder before the standard freezes changes who gets to define what "AV2 compliant" means in practice.

Why it matters

The video codec world has a recurring failure mode. A standards body publishes a spec. Patent pools form. Reference code arrives late, written by committee, slow, and often encumbered. By the time a fast clean-room decoder shows up, the proprietary players already have product in the field, the licensing terms are set, and the open implementations spend years playing catch-up. H.264 and HEVC both followed roughly this trajectory.

dav1d broke that pattern for AV1. VideoLAN started writing dav1d before AV1 was finalized, shipped a usable decoder within months of the freeze, and within two years was faster than every other AV1 decoder on every platform that mattered. Chrome embeds it. Firefox embeds it. VLC ships it. Netflix, YouTube, and Meta lean on it in their pipelines. There is no commercial AV1 decoder with meaningful market share, because dav1d got there first and got there faster.

That outcome wasn't an accident of code quality. It was an accident of *timing*. By being the implementation that browser vendors and CDN engineers integrated during AV1's rollout, dav1d became the de facto reference. Spec ambiguities got resolved in dav1d's favor because dav1d was already shipping. The performance bar for any later decoder was "beat dav1d," which is a much harder bar than "be the first one out."

dav2d is the same play, run again, deliberately. Kempf is racing the spec itself — every assembly path he writes now is a path some future proprietary decoder will have to match, on a moving target both teams are watching get drafted in real time. If AOMedia ratifies AV2 in 2027 and dav2d is already production-grade on x86, ARM, and RISC-V, the same lock-in happens. Browser vendors will integrate the thing that exists. CDN encoders will optimize against the decoder their viewers actually run.

The HN commentary picked up on a secondary effect: pre-spec implementations *influence* the spec. When a coding tool is proposed but no decoder team can implement it efficiently, the tool tends to get dropped or modified. Having dav2d in the room — even informally — means VideoLAN's performance constraints get weight in standardization discussions. That's a governance lever, not just an engineering artifact.

What this means for your stack

If you ship video — streaming, video conferencing, surveillance, anything where bitrate is a P&L line — three things follow.

First, plan AV2 integration earlier than you think. The dav1d cycle ran roughly: spec freezes, dav1d ships, browser integration takes 18 months, CDN encoding catches up another 12. If dav2d holds to the same template, the window from "AV2 ratified" to "AV2 is the cheapest delivery codec for your top-10 markets" is shorter than the planning cycle most video teams run. Start scoping encoder/decoder swaps into 2027 roadmaps now, not when the press release hits.

Second, patent diligence shifts. The reason AV1 won on cost wasn't compression — it was that HEVC's patent pool fragmented into three competing licensors and AV1's didn't. If AV2 lands with the same royalty-free posture and dav2d as the reference, the math for moving off HEVC for new pipelines gets cleaner. Talk to legal before your next encoder contract renewal.

Third, if you're building anything adjacent — analytics on decoded frames, ML inference on video streams, hardware encoders — dav2d's repo is the canonical place to track AV2's actual shape. The spec PDF will lag the implementation. Watching the dav2d commit log is how you'll know which coding tools actually made it through and which got cut.

Looking ahead

The pattern Kempf is running — write the open implementation while the standard is still wet — is one of the few reliable mechanisms by which open formats beat proprietary ones. It works because spec authors and decoder authors are the same kind of person, and the open team has the advantage of shipping without waiting for a committee vote. Expect AV2 to look a lot like AV1 looked in 2018: contested, incomplete, and already decided. The decoder being early is how the codec gets won.

Hacker News 531 pts 193 comments

Dav2d

→ read on Hacker News

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.