```
Too Many Requests
The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.
Details:
Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later
```
'AV2 decoding is roughly five times more complex than AV1 decoding. In practice, that means software running on today’s hardware will struggle to decode AV2 in real time without careful, architecture-specific optimization'
AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
Intel's Arc dGPUs were really compelling for dedicated AV1 encode and decode, especially the small form factor of some cards. You could even fit it as a secondary card in a PC dedicated to recording and encode workflows for OBS.
Hope we get a similar option with future lineups that support AV2, especially given how popular video creation and streaming is now.
Hardly niche. My laptop isn't new and it has hardware AV1 decoding and encoding. My 10 year old iPhone 7 can play 1080p AV1 video in software for over 200 minutes with VLC. The iPhone 7 was released in 2016, a year and a half before AV1. The dav1d decoder is mighty.
> AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
> Make it fast on older desktop, by writing asm for SSSE3+ chips
I guess 5 years ago (around the time when Intel stopped making SSE-only chips) is technically "older", but I wouldn't prioritize avx2 when devices intended for consuming media definitely experience much less pressure to upgrade than workstations…
Almost every Intel CPU released since 2013 has AVX2 support. Some Atom SKUs were longer holdouts, but the fraction of x86 CPUs shipped in the last decade that have AVX2 support is very high.
Seems like the blog succumbed to the HN hug of death (`Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later`), is there a copy available somewhere?
I understood it as compression is 25% better : a quality of 10mbps in av1 can be achieved with 8mbps in Av2.
But, it needs 5 times more compute power for this 25% gain.
When AV1 was first announced, I got the impression the name was chosen partly as a pun/reference/homage to AVI, the classic but outdated format with used to be popular. Then when I saw Dav1d, OK, good way to continue the pun.
But now with AV2 and Dav2d, that completely breaks. Are we eventually going to get AV3/Dav3d and AV4/Dav4d, which will read like Ave/Daved and Ava/Davad? Seems a bit awkward. Was the idea from the start to have the 1 be the version number, and have it specifically be part of the name?
I think it's a reasonable decision. The only people who will interact with dav2d by name are codec nerds, and a simple increment makes the lineage more obvious to that audience.
Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author puts it, AV2 decoding is roughly five times more complex than AV1 decoding?
The algorithms deployed in these kind of codecs take into account not only human vision and mathematical laws of information, but also nitty-gritty details of how computers work, which are optimally exploited by directly having humans write detailed assembly rather than a compiler make a best guess and effort.
The safety can be worth it in certain cases. Like when handling untrusted input. And it's not just Rust: look at WUFFS for example. WUFFS can actually rival handwritten implementations in certain cases.
Encoder and decoder writers frequently need extremely fine grain control over SIMD instructions in order to get good performance.
The way they weave these instructions can be very hard to express with a high level language.
Further, there's a ton of work with arrays and importantly parts of arrays. They can, for example, need to extract every other element up to 1/2 the array. Unfortunately, rust has runtime array bounds checks which make writing that sort of code slower. The compiler can elade those checks, but usually only in simple cases.
The authors would be writing a bunch of unsafe rust to get the performance they want and rust makes that more painful on purpose.
I like rust, but C/ASM really is the right choice here. This is one of the few cases where rust's safety is a major detriment.
The ffmpeg devs have said many times in public that they routinely get speedups of 10x or more over C code. I'm not a reputable source on this myself but I highly recommend looking into their channels, mails, or posts.
That isn’t particularly helpful to someone asking a question in good faith. What others are using doesn’t clarify why they are using it. Plus, FFmpeg is itself a decade older than Rust. The OP is asking about starting a new project today.
They filed a suit, henceforth making a claim of an issue...... They haven't "proved" anything other then they have lawyers on staff that can file some paperwork until the suit is settled in court...
Every single AV2 news here in the last week has seen exactly the same question.
Either go back read the answers there first, or I will assume you are part of a FUD campaign (yes, I know HN guidelines, but again every single AV2 news in the last week has seen the same rhetorical "questions" as top "comments").
"Too Many Requests"
- https://web.archive.org/web/20260531130034/https://jbkempf.c...
- https://archive.md/ln5UE
Too much traffic from HN?
``` Too Many Requests The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly.
Details: Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later ```
i had that too once i used dyndns address my linux apache crashed when some one posted it here
'AV2 decoding is roughly five times more complex than AV1 decoding. In practice, that means software running on today’s hardware will struggle to decode AV2 in real time without careful, architecture-specific optimization'
AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
Intel's Arc dGPUs were really compelling for dedicated AV1 encode and decode, especially the small form factor of some cards. You could even fit it as a secondary card in a PC dedicated to recording and encode workflows for OBS.
Hope we get a similar option with future lineups that support AV2, especially given how popular video creation and streaming is now.
I came to post this as well. Until widespread, inexpensive hardware catches up to a 2018 codec, AV# will remain a niche ideal.
Hardly niche. My laptop isn't new and it has hardware AV1 decoding and encoding. My 10 year old iPhone 7 can play 1080p AV1 video in software for over 200 minutes with VLC. The iPhone 7 was released in 2016, a year and a half before AV1. The dav1d decoder is mighty.
Netflix uses AV1: https://netflixtechblog.com/av1-now-powering-30-of-netflix-s...
YouTube uses AV1. It's tough to be more mainstream than that.
Right click on a YouTube video and select Stats for Nerds. If your system is capable of it, chances are it will be playing back in AV1.
Most of the YouTube videos I watch these days are AV1 encodes. Sometimes it's in VP9 and occasionally it's H.264.
5 replies →
> AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
Yes, this is going to be fun to watch.
> Make it fast on older desktop, by writing asm for SSSE3+ chips
I guess 5 years ago (around the time when Intel stopped making SSE-only chips) is technically "older", but I wouldn't prioritize avx2 when devices intended for consuming media definitely experience much less pressure to upgrade than workstations…
Almost every Intel CPU released since 2013 has AVX2 support. Some Atom SKUs were longer holdouts, but the fraction of x86 CPUs shipped in the last decade that have AVX2 support is very high.
Seems like the blog succumbed to the HN hug of death (`Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later`), is there a copy available somewhere?
it got archived by the wayback machine: https://web.archive.org/web/20260531115337/https://jbkempf.c...
D4vd
I thought this was about Dave2D
Same
I'm not sure what these two lines mean or if we can compare them, any help?
I understood it as compression is 25% better : a quality of 10mbps in av1 can be achieved with 8mbps in Av2. But, it needs 5 times more compute power for this 25% gain.
> I'm not sure what these two lines mean or if we can compare them, any help?
AV2 saves 25% bandwidth at the cost of 5x more decoding complexity.
What does "complexity" mean here? Computation required?
3 replies →
Smaller files but harder to decode
I would love to see comparisons with AV1 on very low bitrates.
Return of the 8MB Shrek encodes?
https://web.archive.org/web/20210416200451/https://cdn.disco...
Shrek 1 at 8.34MB including audio.. insane
3 replies →
6MB should be enough for everyone!
Is codex working on novel decoders 24/7? I hope
One would imagine given the name that it would specialize in codecs
Not to be confused with Da4vid (world-class hacker and owner of the Black sun) or D4vd (rap artist and alleged murderer)
Or Dave2D, popular tech youtuber
Or dave, the command to start Dangerous Dave.
> Not to be confused with Da4vid (world-class hacker and owner of the Black sun)
*Da5id
When AV1 was first announced, I got the impression the name was chosen partly as a pun/reference/homage to AVI, the classic but outdated format with used to be popular. Then when I saw Dav1d, OK, good way to continue the pun.
But now with AV2 and Dav2d, that completely breaks. Are we eventually going to get AV3/Dav3d and AV4/Dav4d, which will read like Ave/Daved and Ava/Davad? Seems a bit awkward. Was the idea from the start to have the 1 be the version number, and have it specifically be part of the name?
As with all naming schemes in the tech world, I am sure no future scenarios, including successor names, were ever considered
I think it's a reasonable decision. The only people who will interact with dav2d by name are codec nerds, and a simple increment makes the lineage more obvious to that audience.
1dav2codecs?
2av2furious?
And then AV3: Tokyo Drift, and after that AV Episode 1.
2 replies →
> experience Dav... Now in 3D!
Da5id could potentially work as a Snow Crash reference.
Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author puts it, AV2 decoding is roughly five times more complex than AV1 decoding?
The algorithms deployed in these kind of codecs take into account not only human vision and mathematical laws of information, but also nitty-gritty details of how computers work, which are optimally exploited by directly having humans write detailed assembly rather than a compiler make a best guess and effort.
Because it's 5 times more complex, you need to get the maximum performance available. Therefore more ASM than ever.
Rust does not bring more performance. Just more safety.
The safety can be worth it in certain cases. Like when handling untrusted input. And it's not just Rust: look at WUFFS for example. WUFFS can actually rival handwritten implementations in certain cases.
1 reply →
Encoder and decoder writers frequently need extremely fine grain control over SIMD instructions in order to get good performance.
The way they weave these instructions can be very hard to express with a high level language.
Further, there's a ton of work with arrays and importantly parts of arrays. They can, for example, need to extract every other element up to 1/2 the array. Unfortunately, rust has runtime array bounds checks which make writing that sort of code slower. The compiler can elade those checks, but usually only in simple cases.
The authors would be writing a bunch of unsafe rust to get the performance they want and rust makes that more painful on purpose.
I like rust, but C/ASM really is the right choice here. This is one of the few cases where rust's safety is a major detriment.
The ffmpeg devs have said many times in public that they routinely get speedups of 10x or more over C code. I'm not a reputable source on this myself but I highly recommend looking into their channels, mails, or posts.
yes it makes sense to use C/ASM here, but if you're curious, there is a rust port of dav1d named rav1d: https://github.com/memorysafety/rav1d
it's not much slower than the original C/ASM implementation (last i checked ~5%?) but that matters here
Go ask FFmpeg what they're writing their encoders and decoders in.
That isn’t particularly helpful to someone asking a question in good faith. What others are using doesn’t clarify why they are using it. Plus, FFmpeg is itself a decade older than Rust. The OP is asking about starting a new project today.
1 reply →
Yes? There is 5x more code to optimize the ASM for.
Ok whose idea was ‘Wiener filtering’
Norbert Wiener in the 1940s. He invented the technique.
It's a semi-common last name.
https://en.wikipedia.org/wiki/Wiener_filter?wprov=sfla1
How is AV2 expected to avoid the patent-pool issues AV1 ran into?
AV1 was designed as royalty-free, but Sisvel’s pool and the recent Dolby/Snap proved the contrary.
https://accessadvance.com/2026/03/24/access-advance-licensor...
They filed a suit, henceforth making a claim of an issue...... They haven't "proved" anything other then they have lawyers on staff that can file some paperwork until the suit is settled in court...
How does that prove anything?
They're claiming that there are patents, but that doesn't mean there are.
Dolby is only the most recent case, Sisvel consorsium actually bills licences per device:
Consumer Display Device: EUR 0.32
Consumer Non-Display Device: EUR 0.11
(source here: https://www.sisvel.com/licensing-programmes/audio-and-video-...)
5 replies →
No codec can ever avoid patent-pool claims.
Every single AV2 news here in the last week has seen exactly the same question.
Either go back read the answers there first, or I will assume you are part of a FUD campaign (yes, I know HN guidelines, but again every single AV2 news in the last week has seen the same rhetorical "questions" as top "comments").
This seems like an interesting case to test AI agents on.
Like we had weird examples like C compilers and Bun. This is a much more interesting example because its highly nontrivial.
AV1 exists, Dav1d exists. Lets see AI take the AV2 spec and Dav1d code and try to make a working high performance AV2 decoder.