```
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
```
BetterThanSober 3 days ago [-]
I don't know if I'm underestimating HN's reach but I doubt we did that, probably traffic from a much bigger aggregator/forum
jezzamon 3 days ago [-]
You are underestimating HN's reach, this happens all the time. As someone who has been on the front page of HN it's a pretty big rush in traffic!
pstuart 3 days ago [-]
I'd wager that the load is amplified by other sites that treat HN as a goldmine of tasty links.
NorwegianDude 3 days ago [-]
Hacker news doesn't generate much traffic, despite what people are saying.
The host here has a limit of 160000 files served each day. That is extremely low. If the site has an icon, css, a js file and a few images it's 10 files each visit. That's will limit it to 16k visits/day. If there are more files loaded it might just handle a few thousand visits, and they have received more than that from HN now.
Anduia 3 days ago [-]
Well, if every asset request hits the origin (no CDN, no caching...) that would be a misconfiguration of the website. It should never happen for a blog.
SonOfLilit 3 days ago [-]
A decade ago I was on the front page and saw ~16k uniques/hour I think?
BetterThanSober 3 days ago [-]
Yeah misconfig would also be my guess, too much cache miss
ethin 3 days ago [-]
Wait really? I'm not really sure what to think and I posted before I saw this... I wonder why the limit is so low?
reactordev 3 days ago [-]
The HN hug of death is real. If you aren’t prepared, it can set fire to your server room.
claytongulick 3 days ago [-]
Oldtimers 'round these parts call it "slashdotted"
reactordev 2 days ago [-]
I'll forever miss Web 1.0
simondotau 2 days ago [-]
Slashdot was Web 2.0 in every respect except for the mid-2000s design aesthetic.
kaka314 3 days ago [-]
Yeah, it's hard to tell thb, just a guess. But potentially the site also misconfigured their server, causing too much cache misses and hitting the server direclty.
hideout_berlin 3 days ago [-]
i had that too once i used dyndns address my linux apache crashed when some one posted it here
minraws 2 days ago [-]
most likely the millions of llm bots that scrape hn and stuff hugged it when it got to frontpage.
jordand 3 days ago [-]
'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.
nwallin 2 days ago [-]
> AV1 software decoding is already very intensive
I think you might be misunderestimating how incredible the dav1d AV1 decoder is. Not only does it require less total time than the reference decoder to decode the same video, but it can spread that out over far more threads. I was unable to watch 4k 60fps av1 video on my media center PC (it's from 2019, so predates hardware av1 decoding, and, well, the CPU was a little long in the tooth) until I switched to dav1d. With dav1d I am now able to watch 4k 60fps av1 using software decoding, and my machine uses 10% CPU while doing so. Really amazing piece of software.
With any luck, the dav2d 5x claim will hold true, and 10% CPU usage will scale to 50% CPU usage, meaning I'm still able to watch 4k 60fps video on my media center without a hardware upgrade. (that machine doesn't have hyperthreading, so 50% cpu is actually 50%, not 100% in a fancy suit)
rbultje 2 days ago [-]
dav2d author here - the 5x number is just where we currently are, it's not the theoretical limit. We're hopeful that a significant amount of the increase we observe in dav2d relative to dav1d is in math code, which should be easier to optimize using hand-written assembly or other algorithmic optimizations. If that holds true, the practical slowdown once everything has been optimized may be substantially less, possibly 2x.
kmfrk 3 days ago [-]
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 are now.
thrownthatway 3 days ago [-]
Is there a compelling reason encoding needs to be done locally?
The point of encoding is to reduce downstream bandwidth for the viewer, and upstream bandwidth for the distribution network.
The content creator only needs to upload it once.
esposm03 3 days ago [-]
Yes.
An uncompressed 1080p, 60fps video with 24-bit color depth would need around 3Gbps to be streamed. And even if you don't need to stream it, that would still consume a sizeable portion of the write throughput of the fastest SSDs currently available; if you go up to 4K, you'd actually exceed that by a lot (not to mention, 1tb of storage would last for about 10 minutes of video).
Forgeties79 3 days ago [-]
Who is regularly watching uncompressed videos outside of production environments? That’s got to be a very small population.
gblargg 3 days ago [-]
The context was remotely encoding the video, which would require sending the uncompressed stream.
zamadatix 2 days ago [-]
I think the context was intended to be "encoded in some fashion on the upload, just it not as AV2 until after the remote end does all of the transcoded variations". I.e. upload as 2x target bitrate AV1 once and distribute as 1x target bitrate AV2 1,000 times and you'll get the same quality without having to encode AV2 locally.
I've actually done a version this for some multi-system live AV at an event before. Between the main software mixer workstations at various fields in the event it was a dumb but simple encoding they could do in hardware at a high bitrate and then in the machine compositing for the livestream out it did AV1 software encoding to upload to the streaming site to minimize bandwidth requirement from the venue and maximize quality on the streaming site. We've since upgraded to hardware with AV1 encode though.
The practical downside is AV2 is only providing a 30% advantage over AV1. For the streaming providers their bandwidth costs are pretty cheap compared to revamping the transcoding infrastructure, so it'd probably only make financial sense once the remove end can do the most complex and quality encoding used and the rest are all simpler.
Ecco 3 days ago [-]
Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?
gblargg 3 days ago [-]
If you compressed it with H.264, it wouldn't make much sense to send it remotely to be encoded with a better codec.
Dylan16807 2 days ago [-]
Why not? If h.264 is the best you can do with minimal resources, you can give it 5x the final bitrate and send it to a specialized/beefy encoding system to become something better.
overfeed 3 days ago [-]
> Using raw uncompressed bitrate is a bit disingenuous
It is not disingenuous given the context. Gp was responding to ggp's hypothetical:
>> Is there a compelling reason encoding needs to be done locally?
phkahler 3 days ago [-]
If you don't encode locally as the video is created, you either need to store RAW frames which takes enormous amount of storage, or you use a different format and suffer quality loss by transcending.
tverbeure 3 days ago [-]
> you use a different format and suffer quality loss by transcending.
Compressing to AV1/h264/265 etc is really only done for the final version, but that doesn't mean that videos are stored in RAW format during editing, where it is very common to store frames locally in Apple ProRes, Avid DNxHD, or some other compressed format that's targeted towards professional editing.
Contrary to AV1 or whatever similar format which offer compression ratios of 1000x and more, these formats have a compression ratio of around 10x. They are very simple, and the quality loss is low enough that it doesn't matter. They also tend to store images with 30 bits per pixel instead of the 24 bpp that's normally used for streaming.
Forgeties79 3 days ago [-]
You’re not wrong but I do think it’s worth clarifying that any professional production with a budget, even a modest one, is generally being shot with a raw codec -> edited/colored with proxies -> rendered with the original raw codec where they compress for the final cut.
ProRes and the like are used for proxies or quick and dirty productions that are mostly shooting their look in camera because of a fast turnaround time. This is usually event work on a budget or something for social media.
halJordan 3 days ago [-]
Well yes? The platforms only accept certain resolution/bitrates and also most of America isnt running 1gig up. They're running 5-30 mbps up. So yeah they need to encode it.
thrownthatway 3 days ago [-]
> They're running 5-30 mbps up
Do you not have 98% high speed 5G coverage?
ihattendorf 3 days ago [-]
Data caps make that hard. While everyone likes to claim unlimited data, I'm not aware of any providers that don't have a heavy data user clause where they'll deprioritize your data if you're a top ~5% data user (usually somewhere over ~1TB/month).
You also will need _some_ sort of encoding locally before uploading, even if it's minimal, which could lead to issues when encoded again (although there are codecs available to minimize this).
Forgeties79 3 days ago [-]
Just over half the world’s smartphone users do (meaning almost half don’t), and certain countries/areas have way more coverage than others. And a massive number of people have limited data per month, which means it’s also a cost concern.
Leaner delivery is not just ethical, but it also makes better business sense.
IshKebab 3 days ago [-]
Video calls & streaming.
sysguest 3 days ago [-]
this
for other cases, I can just wait more for my cpu/gpu/cloud to do the job
3 days ago [-]
mrbluecoat 3 days ago [-]
I came to post this as well. Until widespread, inexpensive hardware catches up to a 2018 codec, AV# will remain a niche ideal.
breve 3 days ago [-]
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.
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.
weiliddat 3 days ago [-]
Supported is different from doing it well though. You do notice the performance hit even on TVs that playback YouTube videos on AV1.
Even on 1080p videos running on AV1 on 1x, the TV system bogs down and any kind of interaction has a variable 1-3s lag. On some TVs if you do 1.25x the TV automatically "downgrades" the resolution to 480p to avoid dropping frames.
I wish there was an option to still use VP9 / H.264 on those systems (even limited to 1080p).
Dylan16807 3 days ago [-]
More reason to never use the builtin stuff in a tv. Cheap sticks can handle decoding fine.
Gigachad 3 days ago [-]
My TV lags out even when doing nothing. So I use it as a dumb panel and let another device handle the streaming and decoding. Also has the benefit of blocking LG from loading adverts all over the UI.
TingPing 3 days ago [-]
Youtube artificially limits the resolution, on mine if you cast the exact same video it doesn’t impose that limit and works fine.
jordand 3 days ago [-]
Yeah I could imagine the AV1 codec sticking around for a very long while, even as a fallback for AV2. There's still hundreds of millions of people out there using old/cheap devices (especially in developing countries) where that battery drain from software decoding is a big problem, so AV2 would be nonviable.
ZeroGravitas 3 days ago [-]
Some of the early use of VP9 and AV1 was Netflix serving video to people in developing countries. Their metered bandwidth was more of a bottleneck than the CPU playback.
sylware 3 days ago [-]
Same. Mostly AV1, sometimes VP9, and rarely h264.
What's missing mostly: live streams which are h264.
Currently, and I say currently, dav1d is so fast, no worries on that side.
jbk 3 days ago [-]
> 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.
genxy 3 days ago [-]
A codec spec isn't done until there is at least one decoder developed in the field. So reference + 1. The field implementations often become the de facto spec.
Reading the MPEG1 specs back in the 90s as a child opened my eyes to how to define complex systems. For a media coding standard, they spent most of their time saying how to interpret encoded bytes, which I realized is genius. Be descriptive about decoding and you don't have to be prescriptive about encoding. Encoding is where you can apply all the creativity, but you need to provide a way to have a shared understanding of the encoded bytes.
ksec 12 hours ago [-]
>The reported gains vary depending on the test conditions, but improvements around 25% compared to AV1 are commonly seen
>AV2 decoding is roughly five times more complex than AV1 decoding.
For the past 8 to 10 years VideoLan are the only guys on the AOM camp who doesn't care about optics and willing to spell out the truth.
>because we did not believe hardware decoding would become available quickly enough, or on enough devices.
The we was basically VideoLAN only. All other members ( at least on the AOM ) thought hardware decoder would be ready by 2019. And we all know how that works out.
pantalaimon 3 days ago [-]
I'm not quite convinced a 25% reduction in size is worth effectively obsoleting all devices that have hardware decoders for AV1 but will struggle to decode AV2
amiga386 3 days ago [-]
Modern video services perform multiple encodings with different codecs, bitrates and screen dimensions, and serve up the most appropriate format that the client device can decode. Youtube has hundreds of format variants:
Devices with AV1 hardware decoding - rare as they are - won't be obsoleted for a long time.
Gigachad 3 days ago [-]
Even devices that don't aren't becoming obsolete. My M1 macbook does not have a hardware decoder and youtube seems to choose AV1 whenever it's available. The software decoder does not noticeably warm the laptop.
breve 3 days ago [-]
When you host videos with near 17 billion views you're going to want to stream those videos in as few bits as possible:
Nothing will become obsolete. AV1 will stick around for a long time. And YouTube still does H.264 encodes to support old devices.
toast0 3 days ago [-]
A new codec doesn't obsolete old devices. At least, not right away.
Studios still release new dvds with mpeg2 video. Online videos tend to be available in many codecs. Video conferencing tends to negotiate to best available or has settled on ancient codecs and won't change quickly.
FrostKiwi 2 days ago [-]
Same comment, same wording was had when going from H.264/AVC to H.265/HEVC and again to AV1. Across the board it's 30% better Size vs Quality and with an X amount increase in compute required to encode and decode.
Each time these standards were put into ink, they were years from being practical.
ChrisArchitect 3 days ago [-]
Related:
The AV2 Video Standard Has Released (Final v1.0 Specification)
Yeah I suppose it’s named after dav1d but still seems like a pretty unfortunate name collision.
3 days ago [-]
xk9 3 days ago [-]
Exactly
fitzroymckay 3 days ago [-]
same
adithyassekhar 3 days ago [-]
Same
plopilop 3 days ago [-]
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?
Ouch, looks like the HN hug of death struck again. Gives me error 429.
Slurpee99 3 days ago [-]
... improvements around 25% compared to AV1
AV2 decoding is roughly five times more complex than AV1 decoding
I'm not sure what these two lines mean or if we can compare them, any help?
whynotmaybe 3 days ago [-]
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.
3 days ago [-]
jbk 3 days ago [-]
> 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.
0x1ceb00da 3 days ago [-]
What does "complexity" mean here? Computation required?
BillStrong 3 days ago [-]
Yes, much higher computation required to encode it, and decode it, both.
Caspy7 3 days ago [-]
He only mentioned decode complexity. Would be interesting to know the average encode complexity compared to AV1.
kiicia 3 days ago [-]
Encoding speed even on Mac Studio is atrocious, it’s in range of single frames per second as opposed to realtime+ for even h265
F3nd0 3 days ago [-]
The specification for AV2 has only been finalised very recently, so performant encoders have not yet been developed. Meaningful comparison to older codecs like H265 and AV1 will only be possible once that has changed. (It'll be slower, but almost certainly not one-frame-per-second slow.)
Dylan16807 2 days ago [-]
Getting the full bitrate gains will be slower.
For any specific bitrate and quality target, there's a good chance it'll be faster.
WD-42 3 days ago [-]
dav1d is the av1 decoder and it’s an insane feat of engineering. Written in assembly, it even eschews the normal c calling convention to get even better performance.
IshKebab 3 days ago [-]
The normal C calling convention is really only for cross-binary calls (e.g. between shared libraries). If you're not doing that you can ignore it; it's not a weird thing to do. It would be odd to strictly follow it in assembly and I assume compilers don't either.
adgjlsfhk1 3 days ago [-]
Unfortunately, in absence of inlining, compilers mostly respect calling convention even when they don't have to.
simjnd 3 days ago [-]
Yes
croes 3 days ago [-]
Smaller files but harder to decode
mudkipdev 3 days ago [-]
> 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.
HN hug of death
GaggiX 3 days ago [-]
I would love to see comparisons with AV1 on very low bitrates.
There's a 64MB game boy advance cartridge with shrek on it [1]. Looks pretty horrible [2]. But the GBA only has 16KB fast / 256KB slow RAM, and a 16MHz CPU.
Video resolution: 128x72, hahah. Late 90s RealPlayer postage stamp video is back! To its credit, that whole movie is probably smaller than RealPlayer itself was.
asimovDev 3 days ago [-]
I once watched an entire movie (around 90 mins) on a Nokia 6303. This reminds me of that
GaggiX 3 days ago [-]
I love this, hope to see a AV2 version at 8MB
lostmsu 3 days ago [-]
6MB should be enough for everyone!
Dylan16807 2 days ago [-]
Almost half of the file is audio, so you're not saving as much.
lostmsu 2 days ago [-]
Hopefully audio codecs will progress as well.
I noticed that too. When I tried extreme screen recording compression with AV1 audio became a noticeable part of the bottleneck.
GaggiX 2 days ago [-]
Is opus being used for the audio or it's not the solution for extreme lossy compression?
lostmsu 1 days ago [-]
OPUS is the default now, but there's more room. Especially with neural codecs.
latexr 3 days ago [-]
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?
BetterThanSober 3 days ago [-]
I'm pretty sure it is a homage. As for dav1d it's not a reference decoder (although partially funded by AOM iirc) so they might not know that the next iteration will simply be AV2, we have h264, h265, h266 naming though
Tangent but I cannot wait for h269 (or h267 for the younger gen)
p1mrx 3 days ago [-]
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.
xp84 3 days ago [-]
As with all naming schemes in the tech world, I am sure no future scenarios, including successor names, were ever considered
jl6 3 days ago [-]
1dav2codecs?
2av2furious?
Hendrikto 3 days ago [-]
And then AV3: Tokyo Drift, and after that AV Episode 1.
account42 2 days ago [-]
There is going to be a never ending stream of them isn't there.
xp84 3 days ago [-]
Or go the Apple Watch naming scheme route.
Just “AV”
Next, AV Series 1 and 2 (released simultaneously)
Later, AV Edition but it costs $10,000
brnt 3 days ago [-]
AV360. AV365. AV2030. AVXP. AV8. AV10. Perhaps some here will be around for AV95.
Young AV?
BillStrong 3 days ago [-]
Already predicting which versions to avoid, huh.
Arubis 3 days ago [-]
Da5id could potentially work as a Snow Crash reference.
WhrRTheBaboons 3 days ago [-]
> experience Dav... Now in 3D!
latexr 3 days ago [-]
I’m fascinated by the flurry of downvotes to a simple commentary and question, especially when the replies are normal. If you’re one of the downvotes, please do share what you found offensive about my comment, I am genuinely interested in what you perceived as problematic.
remix2000 3 days ago [-]
> 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…
otherjason 3 days ago [-]
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.
philipallstar 3 days ago [-]
> Let dav2d be.
This is an odd signoff. Are people having a go at dav2d?
TheMrZZ 3 days ago [-]
I'm French, and so is JB. To me it feels more like a play on "Let there be light", as in French we'd say "Let the light be". I might be wrong but I did not feel this insinuated people were having a go at AV2/dav2d.
account42 2 days ago [-]
Is there actually a reasonably performing encoder that can compete with the x26* family in real world conditions this time?
ZeroGravitas 2 days ago [-]
Last time Intel's SVT-AV1 managed to beat both x265 and x265 at various quality/speed tradeoffs.
I assume there will be an SVT-AV2 too which will semi-automatically gain from the SVT foundation for working with lots of cores but will still need specific work to support and then tune AV2 encoding.
avaer 3 days ago [-]
If decode is becoming so complicated and expensive the hardware can't handle it, why not just go full neural, send latents, and run decode on tensor cores?
The answer is probably the same as for why not AV2 everything; a lot of hardware couldn't support it today. But in 10 years?
It seems we're running up against fundamental limits of human-engineered video codecs at this point. There might be a lesson in there.
Dylan16807 3 days ago [-]
What makes you think that would use less resources?
And it's not really hardware hitting limits, it's specifically software decoding on somewhat weaker machines.
avaer 3 days ago [-]
It could help in the same way that running things in a shader uses less resources than running it on CPU. You're flattening the pipeline, and you can optimize better with simpler primitives and less branches.
Cthulhu_ 2 days ago [-]
I wouldn't want it myself, but, video games already do something like this - AI upscaling. Render the game at lower resolution / quality settings, then use AI to upscale and fill in the blanks.
This could work / works for video too, give it lower resolution / quality images and AI upscale. Its predecessor would calculate intermediate frames for example.
itishappy 3 days ago [-]
This is a software decoder designed to run on general purpose hardware.
Adding custom hardware like tensor cores to the stack would serves a different use case.
avaer 3 days ago [-]
Right, I'm sure it's way faster in specialized hardware.
What I'm saying is the performance problem is a "code smell". The algorithms are getting so complicated that perhaps we are approaching fundamental limits of heuristiccs; we might get better + faster results ditching "smart" algorithms and just learning the codec in a much higher dimensional space.
Again specialized hardware, but a different approach to it.
arikrahman 3 days ago [-]
What's next, Dav4d?
ant6n 3 days ago [-]
Dav3d?
H8crilA 3 days ago [-]
Dav3.1416d
Cthulhu_ 2 days ago [-]
Dav67d
poly2it 3 days ago [-]
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?
Arodex 3 days ago [-]
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.
alkonaut 3 days ago [-]
Surely 100% of these low level features are availale in rust too? I understand it is a massive undertaking and builds off the previous codec(s) but writing these things by hand such as inline assembly seems to be as easy if not easier in Rust?
And as soon as you walk into concurrency territory for a complex codec like this then it seems almost impossible for humans to do correctly while retaining safety.
rafaelmn 3 days ago [-]
Why ? If it's shared reads and scoped writes (read-only look up, output to a thread owned buffer span) concurrency seems pretty straightforward.
Rust can only prove a limited subset of correct programs to be safe, when you're doing bare metal stuff you've often not in that subsystem and drop down to unsafe. I'm guessing there's always stuff that's not perf critical and can live in Rust sandbox - so not saying no wins - but it doesn't sound like Rust is a no-brainer.
alkonaut 2 days ago [-]
I mean all else being equal, I'd just take the ergonomics (dependency management, build-system/multi-targeting, modern language features, no h-files, ...) and run. I can always just write at the level I want (safe rust, unsafe rust, C, inline asm...).
I still think no one should in 2026 be writing a nontrivial codec or anything parsing untrusted data, in C. There's just no excuse.
The gains are re-use of skill and code. And I hope that's the reason this is continuing with C, this is basically a v2 of an existing project, not a greenfield codec, even if it's much larger.
jbk 3 days ago [-]
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.
alkonaut 3 days ago [-]
It brings tooling that is a LOT easier. Just things like dependency management, test running and so on is so much better in Rust than in C, even if you happen to write the exact same code because you basically write unsafe code and hand rolled assembly for many things. I think this is people using the tool they know rather than the best tool (And if you know a tool well, it might become the best tool for the job because of that). It could be because a huge chunk of existing code can be re-used. But all else being equal (existing code, existing developers don't exist) I refuse to believe a codec should ever be written in C ever again.
LoganDark 3 days ago [-]
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.
xp84 3 days ago [-]
Are video codecs in the present day able to be sandboxed? In my fantasies at least I’d like the worst a malicious video file can do is cause garbage output or cause the codec to crash.
Forgive the ignorance, I have worked entirely in the abstracted layers of the stack, and mostly web.
adgjlsfhk1 3 days ago [-]
not really. they're mostly pure assembly and sandboxing assembly isn't really a things
nullpoint420 3 days ago [-]
yes it is. all modern operating systems sandbox assembly. that's how it works.
LoganDark 2 days ago [-]
Windows may use virtualization-based security by default, but I'm not aware of macOS or Linux doing the same -- Apple builds security directly into the silicon such that no virtualization is required, and Linux just rawdogs everything.
Whether that counts is up to you. I suppose it's still "sandboxed" in that it runs in a less privileged context than the kernel.
I don't see why not. What makes you think this is unique?
adgjlsfhk1 3 days ago [-]
WUFFS like approaches work better for algorithms like lz77 that are substantially bandwidth constrained. for something like a video codec, the computational intensity is much higher so you need better codegen to reach max speed
cesarb 3 days ago [-]
> Rust does not bring more performance. Just more safety.
Though more safety can in some cases bring a bit more performance. For instance, with Rust you can often avoid "defensive copies" of objects.
itishappy 3 days ago [-]
When writing a high performance video codec avoiding defensive copies of objects is something you want always, not just often.
C makes it easy to be fast but hard to be safe. Rust makes it easy to be safe but hard to be fast.
Also note that video codecs tend to wrap C or Rust around handcrafted ASM. Performance is king.
cogman10 3 days ago [-]
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.
dcsommer 3 days ago [-]
Performance should not be priority #1. Security should be. Why do we slow down all CPUs to prevent SPECTRE attacks yet continue to write in C? As rav1d shows, the perf loss is far less to migrate from C to Rust than it is to apply SPECTRE mitigations, and adding a sandbox around a memory-unsafe codec is going to be way more expensive again than using Rust code to start.
Const-me 3 days ago [-]
> Performance should not be priority #1. Security should be.
For a web browser, or a server in a bank, sure. For anything else, questionable.
> adding a sandbox around a memory-unsafe codec is going to be way more expensive
In modern world, overhead of strong sandboxes is surprisingly small. A nuclear but most reliable option is hardware assisted VM. On modern computers with SLAT and virtualized IO the overhead for most use cases is negligible. If you want something lighter weight, can use a multi-user nature of all modern OS kernels and isolate into a separate process with restricted permissions. Sandboxing overhead is approximately zero.
cogman10 3 days ago [-]
> As rav1d shows
rav1d is not a full rewrite of dav1d to rust. So it really doesn't show that. It's currently C + rust + asm.
I don't think we can say anything about what this does or does not prove about the performance of safe code.
> Performance should not be priority #1. Security should be.
Entirely depends on the application. The reason rust has `unsafe` is because there's some situations where performance needs to preempt potential security problems.
dcsommer 3 days ago [-]
Codecs are difficult and expensive to develop. Therefore they get reused in many contexts, including security critical ones. Sandboxing is shown over and over to not be a great security solution, so what this means in practice is that security-critical software that needs software decoding get pwned because software engineers don't care to prioritize it in the first place.
Why shouldn't safety be the default? If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them.
Software decoding has a safety culture problem, and we need to talk about it.
cogman10 3 days ago [-]
> Why shouldn't safety be the default?
Because safe code isn't fast enough to decode live video.
> If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them.
Yeah, but then you are undermining safety in a critical way that does lead to security vulnerabilities (buffer overflow). And you are also now maintaining and requiring other devs for a project to use a custom version of rustc. That's certainly part of the reason that's simply not happened.
But another major part of it is that encoders end up with a lot of custom ASM regardless. That custom ASM is going to be where vulnerabilities end up. You don't really escape that by using rust.
If you are already abandoning where you critically need safety the most for performance, then why pick a language that additionally penalizes you for using unsafe constructs?
> Software decoding has a safety culture problem, and we need to talk about it.
Compilers and languages have an optimization problem that we need to talk about. SIMD optimizations remain a very hard thing for compilers to get right. We should talk about what it'd take to make compilers better and the reasons for why codec devs need to drop down to asm instead of using a high level compiler.
There might not be a solution to this problem, there are reasons for it.
Dylan16807 3 days ago [-]
> Because safe code isn't fast enough to decode live video.
I strongly doubt that.
And if any implementation of AV2 can be "fast enough", then there should be no question at all that we can write "fast enough" safe decoders for every other codec. Absolutely no way safe code is inherently that much slower.
cogman10 2 days ago [-]
Show me the AV1, H.265, or even H.264 decoder that doesn't ultimately rely heavily on hand written assembly to achieve "fast enough".
You can doubt all you like. Ultimately, there's a reason why dav1d includes hand coded SIMD for common platforms.
It's simply impossible to get a compiler to emit something like this [1].
Is it simply impossible to get compiled code within a factor of five? That claim needs strong evidence.
More importantly, if you can show that your assembly code isn't altering pointers it shouldn't alter, and isn't going out of bounds on its reads, you're most of the way to having assembly in your verified safe code. And rough bounds checking with padding can as cheap as a bitmask.
cogman10 2 days ago [-]
> Is it simply impossible to get compiled code within a factor of five? That claim needs strong evidence.
1. I didn't make that claim.
2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's non-existence. If you disagree, you need to provide evidence to the contrary.
Dylan16807 2 days ago [-]
> 1. I didn't make that claim.
Then you didn't read my previous comment correctly. AV2 must be "fast enough" if the designers aren't crazy. And AV2 is 5x slower than AV1. Therefore if compiled code is within a factor of five of hand-written assembly, it's "fast enough" for AV1, and h.264, and probably h.265 too.
You were disagreeing with my claim that other codecs could be "fast enough" with a safe compiler, right? If you weren't disagreeing, I don't know why you challenged me to show you some particular kind of code.
> 2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's non-existence. If you disagree, you need to provide evidence to the contrary.
You're saying it's "simply impossible" for a compiler to optimize instructions to a certain level. But anything one person can code, another person can teach a compiler to do in similar situations. I don't need to show you an example, I just need to point you at the Church-Turing thesis and related documents.
imtringued 3 days ago [-]
What's supposed to be the big source of unsafety in codecs though? Feels like the problem here is that C developers are ruining the reputation of C with their garbage code.
Bounds checking as a source of slowdown is overrated in a niche where you're working on fixed size blocks. It feels like the C developers are getting the parts outside the ASM kernels wrong.
cogman10 2 days ago [-]
> What's supposed to be the big source of unsafety in codecs though?
Hand written assembly. It's quite easy to accidentally start reading or manipulating a block of memory you didn't intend to when doing complex SIMD transformations.
> Bounds checking as a source of slowdown is overrated in a niche where you're working on fixed size blocks.
I think you don't really understand how codecs work. It is not uncommon for a transformation like `a = b[c[i] * 3 + offset];`. There's no way for a compiler to omit the bounds check because it can't prove the contents of `c` aren't going to exceed the bounds of `b`.
This isn't a "crappy C developer" problem. This is a "There isn't a language that does a great job at capturing high level SIMD expressions" problem.
muhbaasu 3 days ago [-]
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.
If you can stand Lex Friedman for a bit, the VLC authors talk about why you use ASM for a video decoder instead of pure C or rust.
IshKebab 3 days ago [-]
I don't know why you've been down-voted. It definitely isn't an optimal decision. A video codec isn't all assembly. There's plenty of plain unsafe C code. E.g. this is the first random file I clicked. It has a ton of raw C pointer stuff just begging to be exploited.
> This is enough of a difference to be a problem for potential adopters, and, frankly, it just bothers us.
But in my opinion nobody actually cares about 5% in absolute terms. It's likely just Rust naysayers using that as an excuse.
I think the likely reason for dav2d using C is that they can reuse lots of code and infrastructure from dav1d. But I agree it would be much better if they worked on Rav2d instead (these names!). You can hardly complain about a 5% overhead if you're opting in to 5x more decoding complexity.
skelpmargyar 3 days ago [-]
Of course any random C file is going to have pointers. Where can anything in the linked code be exploited? It seems like they're testing for bad input data with asserts to catch bugs in some functions, and properly validating bad inputs in others. Just because they're writing C doesn't mean it's vulnerable.
How can you claim nobody cares about 5%? A 5% performance increase is significant. And video decoding is not always for playback, where 5% may not matter as much.
IshKebab 2 days ago [-]
> Where can anything in the linked code be exploited?
I am not sure if it is that much safer than the C version when raw assembly is still required.
Thaxll 3 days ago [-]
It is much slower than 5%, there were other independent tests that put it around 20%.
stukenov 3 days ago [-]
[dead]
Telaneo 3 days ago [-]
Go ask FFmpeg what they're writing their encoders and decoders in.
latexr 3 days ago [-]
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.
Telaneo 3 days ago [-]
> What others are using doesn’t clarify why they are using it.
It does if you ask them, or at least research the topic at hand.
latexr 3 days ago [-]
Isn’t that just the same as answering “Google it”, then? We’re on a discussion forum, where matter experts visit, talking about a specific topic. If one can’t ask their questions in this highly relevant situation, where can they? The point of HN is supposed to be gratifying curiosity.
Gigachad 3 days ago [-]
Just don't try reporting a security issue to them.
If so, FFmpeg's stance is very understandable in my opinion.
Gigachad 3 days ago [-]
Somewhat, but somewhat not. Yes it's a very obscure format, and yes it's partially a marketing stunt from Google for their AI tools. But it's also a real bug which is exploitable on ffmpeg. And we have seen in the past that state sponsored hacking groups specifically target media decoders with obscure formats that aren't often tested or known about.
Media decoders are one of the highest risk programs since they deal with untrusted user input and are incredibly complex. So just because a large project like ffmpeg uses C, doesn't mean there isn't very good reason to consider a language like Rust for saftey reasons.
Telaneo 3 days ago [-]
If Google want secure encoders and decoders, then they can donate money or patches. Since they don't, the clearly don't actually care all that much, or are just mooching of volunteers' goodwill.
The disadvantage in speed when using Rust is pretty obvious.[1] When it comes to video encoding and decoding, I and FFmpeg care a lot more about speed than memory safety. So those reasons have been considered and largely discounted.
[1] https://xcancel.com/FFmpeg/status/1924137645988356437 (to be fair, this is only transpiled from C, so it could probably be optimised further, but that apparently needed a 20k USD bounty to then not even happen (as far as I can tell))
standard in DSP. Super cool and can be used on stock trades and other predictive markets.
kingstnap 3 days ago [-]
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.
rbultje 2 days ago [-]
> Lets see AI take the AV2 spec and Dav1d code and try to make a working high performance AV2 decoder.
That sounds like one of these high-risk, high-reward things that are great for people / projects / companies who have nothing to lose, but is not a great baseline strategy for an established market player. AV2 is here with support from aomedia and its members. AV2 will be used, and we need a production-grade decoder regardless of where AI is at, so it makes much more conservative business sense to use established approaches (language: c/asm, devteam: ffmpeg/dav1d) as a starting point. While that's happening, we can dabble in AI and other risky stuff and see if it helps. If so, great, and if not, nothing lost.
kingstnap 1 days ago [-]
What's the high risk? That you end up with useless code?
I didn't mean that the Dav1d people should yolo vibe code Dav2d. My point was this this is a very interesting possible experiment since there is no existing Dav2d contamination in the training data.
Eldodi 3 days ago [-]
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.
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...
AndrewDucker 3 days ago [-]
How does that prove anything?
They're claiming that there are patents, but that doesn't mean there are.
Eldodi 3 days ago [-]
Dolby is only the most recent case, Sisvel consorsium actually bills licences per device:
Sisvel allows you to pay them if you believe their claims, they haven't actually taken anyone not paying to court yet to prove that. The only court cases for VP9/AV1 from Sisvel so far have been their patents being found invalid/irrelevant.
Dolby is somewhat more interesting in that rather than scare tactics, media hype, and attempting to form a pool about it they are actually taking a patent assertion claim to court.
justinclift 3 days ago [-]
That crowd are just deeply concerned one of their lucrative revenue streams is disappearing.
So they seem to be attempting to pull a fast one and use unproven claims to try and convert their competitor into a replacement revenue source.
It'll probably be a case of whoever has the best lawyers + contacts + persistence wins.
But it'll be interesting if discovery shows evidence they know they don't have a case and are trying it anyway. "Piercing the corporate veil" can theoretically be a consequence of that AFAIK.
croes 3 days ago [-]
That doesn’t prove their claims are valid.
I can claim the same and offer licenses per device.
UnlockedSecrets 3 days ago [-]
How does how they bill for their product, matter in terms of if their lawsuit holds merit?
silotis 3 days ago [-]
Can you point to any other patent lawsuit over AV1? AFAIK the Dolby case is the first.
croes 3 days ago [-]
No codec can ever avoid patent-pool claims.
adgjlsfhk1 3 days ago [-]
Sorry, I have a patent on questioning whether open source codecs are parent encumbered. Venmo me $1000 or you will be speaking to my lawyers
Arodex 3 days ago [-]
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").
- https://web.archive.org/web/20260531130034/https://jbkempf.c...
- https://archive.md/ln5UE
``` 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 ```
The host here has a limit of 160000 files served each day. That is extremely low. If the site has an icon, css, a js file and a few images it's 10 files each visit. That's will limit it to 16k visits/day. If there are more files loaded it might just handle a few thousand visits, and they have received more than that from HN now.
AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
I think you might be misunderestimating how incredible the dav1d AV1 decoder is. Not only does it require less total time than the reference decoder to decode the same video, but it can spread that out over far more threads. I was unable to watch 4k 60fps av1 video on my media center PC (it's from 2019, so predates hardware av1 decoding, and, well, the CPU was a little long in the tooth) until I switched to dav1d. With dav1d I am now able to watch 4k 60fps av1 using software decoding, and my machine uses 10% CPU while doing so. Really amazing piece of software.
With any luck, the dav2d 5x claim will hold true, and 10% CPU usage will scale to 50% CPU usage, meaning I'm still able to watch 4k 60fps video on my media center without a hardware upgrade. (that machine doesn't have hyperthreading, so 50% cpu is actually 50%, not 100% in a fancy suit)
Hope we get a similar option with future lineups that support AV2, especially given how popular video creation and streaming are now.
The point of encoding is to reduce downstream bandwidth for the viewer, and upstream bandwidth for the distribution network.
The content creator only needs to upload it once.
An uncompressed 1080p, 60fps video with 24-bit color depth would need around 3Gbps to be streamed. And even if you don't need to stream it, that would still consume a sizeable portion of the write throughput of the fastest SSDs currently available; if you go up to 4K, you'd actually exceed that by a lot (not to mention, 1tb of storage would last for about 10 minutes of video).
I've actually done a version this for some multi-system live AV at an event before. Between the main software mixer workstations at various fields in the event it was a dumb but simple encoding they could do in hardware at a high bitrate and then in the machine compositing for the livestream out it did AV1 software encoding to upload to the streaming site to minimize bandwidth requirement from the venue and maximize quality on the streaming site. We've since upgraded to hardware with AV1 encode though.
The practical downside is AV2 is only providing a 30% advantage over AV1. For the streaming providers their bandwidth costs are pretty cheap compared to revamping the transcoding infrastructure, so it'd probably only make financial sense once the remove end can do the most complex and quality encoding used and the rest are all simpler.
It is not disingenuous given the context. Gp was responding to ggp's hypothetical:
>> Is there a compelling reason encoding needs to be done locally?
Compressing to AV1/h264/265 etc is really only done for the final version, but that doesn't mean that videos are stored in RAW format during editing, where it is very common to store frames locally in Apple ProRes, Avid DNxHD, or some other compressed format that's targeted towards professional editing.
Contrary to AV1 or whatever similar format which offer compression ratios of 1000x and more, these formats have a compression ratio of around 10x. They are very simple, and the quality loss is low enough that it doesn't matter. They also tend to store images with 30 bits per pixel instead of the 24 bpp that's normally used for streaming.
ProRes and the like are used for proxies or quick and dirty productions that are mostly shooting their look in camera because of a fast turnaround time. This is usually event work on a budget or something for social media.
Do you not have 98% high speed 5G coverage?
You also will need _some_ sort of encoding locally before uploading, even if it's minimal, which could lead to issues when encoded again (although there are codecs available to minimize this).
Leaner delivery is not just ethical, but it also makes better business sense.
for other cases, I can just wait more for my cpu/gpu/cloud to do the job
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.
Even on 1080p videos running on AV1 on 1x, the TV system bogs down and any kind of interaction has a variable 1-3s lag. On some TVs if you do 1.25x the TV automatically "downgrades" the resolution to 480p to avoid dropping frames.
I wish there was an option to still use VP9 / H.264 on those systems (even limited to 1080p).
What's missing mostly: live streams which are h264.
Currently, and I say currently, dav1d is so fast, no worries on that side.
Yes, this is going to be fun to watch.
Reading the MPEG1 specs back in the 90s as a child opened my eyes to how to define complex systems. For a media coding standard, they spent most of their time saying how to interpret encoded bytes, which I realized is genius. Be descriptive about decoding and you don't have to be prescriptive about encoding. Encoding is where you can apply all the creativity, but you need to provide a way to have a shared understanding of the encoded bytes.
>AV2 decoding is roughly five times more complex than AV1 decoding.
For the past 8 to 10 years VideoLan are the only guys on the AOM camp who doesn't care about optics and willing to spell out the truth.
>because we did not believe hardware decoding would become available quickly enough, or on enough devices.
The we was basically VideoLAN only. All other members ( at least on the AOM ) thought hardware decoder would be ready by 2019. And we all know how that works out.
https://gist.github.com/MartinEesmaa/2f4b261cb90a47e9c41ba11...
Devices with AV1 hardware decoding - rare as they are - won't be obsoleted for a long time.
https://www.youtube.com/watch?v=XqZsoesa55w
That extra 25% becomes worth it.
Nothing will become obsolete. AV1 will stick around for a long time. And YouTube still does H.264 encodes to support old devices.
Studios still release new dvds with mpeg2 video. Online videos tend to be available in many codecs. Video conferencing tends to negotiate to best available or has settled on ancient codecs and won't change quickly.
Each time these standards were put into ink, they were years from being practical.
The AV2 Video Standard Has Released (Final v1.0 Specification)
https://news.ycombinator.com/item?id=48340910
AV2 saves 25% bandwidth at the cost of 5x more decoding complexity.
For any specific bitrate and quality target, there's a good chance it'll be faster.
HN hug of death
Shrek 1 at 8.34MB including audio.. insane
[1] https://archive.org/details/Shrek-Video-GBA [2] https://www.youtube.com/watch?v=CyOfPZQl4MI
I noticed that too. When I tried extreme screen recording compression with AV1 audio became a noticeable part of the bottleneck.
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?
Tangent but I cannot wait for h269 (or h267 for the younger gen)
2av2furious?
Just “AV”
Next, AV Series 1 and 2 (released simultaneously)
Later, AV Edition but it costs $10,000
Young AV?
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…
This is an odd signoff. Are people having a go at dav2d?
I assume there will be an SVT-AV2 too which will semi-automatically gain from the SVT foundation for working with lots of cores but will still need specific work to support and then tune AV2 encoding.
The answer is probably the same as for why not AV2 everything; a lot of hardware couldn't support it today. But in 10 years?
It seems we're running up against fundamental limits of human-engineered video codecs at this point. There might be a lesson in there.
And it's not really hardware hitting limits, it's specifically software decoding on somewhat weaker machines.
This could work / works for video too, give it lower resolution / quality images and AI upscale. Its predecessor would calculate intermediate frames for example.
Adding custom hardware like tensor cores to the stack would serves a different use case.
What I'm saying is the performance problem is a "code smell". The algorithms are getting so complicated that perhaps we are approaching fundamental limits of heuristiccs; we might get better + faster results ditching "smart" algorithms and just learning the codec in a much higher dimensional space.
Again specialized hardware, but a different approach to it.
And as soon as you walk into concurrency territory for a complex codec like this then it seems almost impossible for humans to do correctly while retaining safety.
Rust can only prove a limited subset of correct programs to be safe, when you're doing bare metal stuff you've often not in that subsystem and drop down to unsafe. I'm guessing there's always stuff that's not perf critical and can live in Rust sandbox - so not saying no wins - but it doesn't sound like Rust is a no-brainer.
I still think no one should in 2026 be writing a nontrivial codec or anything parsing untrusted data, in C. There's just no excuse.
The gains are re-use of skill and code. And I hope that's the reason this is continuing with C, this is basically a v2 of an existing project, not a greenfield codec, even if it's much larger.
Rust does not bring more performance. Just more safety.
Forgive the ignorance, I have worked entirely in the abstracted layers of the stack, and mostly web.
Whether that counts is up to you. I suppose it's still "sandboxed" in that it runs in a less privileged context than the kernel.
Though more safety can in some cases bring a bit more performance. For instance, with Rust you can often avoid "defensive copies" of objects.
C makes it easy to be fast but hard to be safe. Rust makes it easy to be safe but hard to be fast.
Also note that video codecs tend to wrap C or Rust around handcrafted ASM. Performance is king.
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.
For a web browser, or a server in a bank, sure. For anything else, questionable.
> adding a sandbox around a memory-unsafe codec is going to be way more expensive
In modern world, overhead of strong sandboxes is surprisingly small. A nuclear but most reliable option is hardware assisted VM. On modern computers with SLAT and virtualized IO the overhead for most use cases is negligible. If you want something lighter weight, can use a multi-user nature of all modern OS kernels and isolate into a separate process with restricted permissions. Sandboxing overhead is approximately zero.
rav1d is not a full rewrite of dav1d to rust. So it really doesn't show that. It's currently C + rust + asm.
I don't think we can say anything about what this does or does not prove about the performance of safe code.
> Performance should not be priority #1. Security should be.
Entirely depends on the application. The reason rust has `unsafe` is because there's some situations where performance needs to preempt potential security problems.
Why shouldn't safety be the default? If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them.
Software decoding has a safety culture problem, and we need to talk about it.
Because safe code isn't fast enough to decode live video.
> If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them.
Yeah, but then you are undermining safety in a critical way that does lead to security vulnerabilities (buffer overflow). And you are also now maintaining and requiring other devs for a project to use a custom version of rustc. That's certainly part of the reason that's simply not happened.
But another major part of it is that encoders end up with a lot of custom ASM regardless. That custom ASM is going to be where vulnerabilities end up. You don't really escape that by using rust.
If you are already abandoning where you critically need safety the most for performance, then why pick a language that additionally penalizes you for using unsafe constructs?
> Software decoding has a safety culture problem, and we need to talk about it.
Compilers and languages have an optimization problem that we need to talk about. SIMD optimizations remain a very hard thing for compilers to get right. We should talk about what it'd take to make compilers better and the reasons for why codec devs need to drop down to asm instead of using a high level compiler.
There might not be a solution to this problem, there are reasons for it.
I strongly doubt that.
And if any implementation of AV2 can be "fast enough", then there should be no question at all that we can write "fast enough" safe decoders for every other codec. Absolutely no way safe code is inherently that much slower.
You can doubt all you like. Ultimately, there's a reason why dav1d includes hand coded SIMD for common platforms.
It's simply impossible to get a compiler to emit something like this [1].
[1] https://github.com/videolan/dav1d/blob/master/src/x86/ipred_...
More importantly, if you can show that your assembly code isn't altering pointers it shouldn't alter, and isn't going out of bounds on its reads, you're most of the way to having assembly in your verified safe code. And rough bounds checking with padding can as cheap as a bitmask.
1. I didn't make that claim.
2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's non-existence. If you disagree, you need to provide evidence to the contrary.
Then you didn't read my previous comment correctly. AV2 must be "fast enough" if the designers aren't crazy. And AV2 is 5x slower than AV1. Therefore if compiled code is within a factor of five of hand-written assembly, it's "fast enough" for AV1, and h.264, and probably h.265 too.
You were disagreeing with my claim that other codecs could be "fast enough" with a safe compiler, right? If you weren't disagreeing, I don't know why you challenged me to show you some particular kind of code.
> 2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's non-existence. If you disagree, you need to provide evidence to the contrary.
You're saying it's "simply impossible" for a compiler to optimize instructions to a certain level. But anything one person can code, another person can teach a compiler to do in similar situations. I don't need to show you an example, I just need to point you at the Church-Turing thesis and related documents.
Bounds checking as a source of slowdown is overrated in a niche where you're working on fixed size blocks. It feels like the C developers are getting the parts outside the ASM kernels wrong.
Hand written assembly. It's quite easy to accidentally start reading or manipulating a block of memory you didn't intend to when doing complex SIMD transformations.
> Bounds checking as a source of slowdown is overrated in a niche where you're working on fixed size blocks.
I think you don't really understand how codecs work. It is not uncommon for a transformation like `a = b[c[i] * 3 + offset];`. There's no way for a compiler to omit the bounds check because it can't prove the contents of `c` aren't going to exceed the bounds of `b`.
This isn't a "crappy C developer" problem. This is a "There isn't a language that does a great job at capturing high level SIMD expressions" problem.
If you can stand Lex Friedman for a bit, the VLC authors talk about why you use ASM for a video decoder instead of pure C or rust.
https://code.videolan.org/videolan/dav2d/-/blob/main/src/dat...
There is a project to write an AV1 decoder in Rust: Rav1d (really stretching the name here).
https://github.com/memorysafety/rav1d
They got within 5% of the performance of dav1d and held a contest to close the gap but I think I read somewhere that this wasn't achieved.
https://www.memorysafety.org/blog/rav1d-perf-bounty/
They claimed
> This is enough of a difference to be a problem for potential adopters, and, frankly, it just bothers us.
But in my opinion nobody actually cares about 5% in absolute terms. It's likely just Rust naysayers using that as an excuse.
I think the likely reason for dav2d using C is that they can reuse lots of code and infrastructure from dav1d. But I agree it would be much better if they worked on Rav2d instead (these names!). You can hardly complain about a 5% overhead if you're opting in to 5x more decoding complexity.
How can you claim nobody cares about 5%? A 5% performance increase is significant. And video decoding is not always for playback, where 5% may not matter as much.
Difficult to tell - that's the point!
it's not much slower than the original C/ASM implementation (last i checked ~5%?) but that matters here
I am not sure if it is that much safer than the C version when raw assembly is still required.
It does if you ask them, or at least research the topic at hand.
If so, FFmpeg's stance is very understandable in my opinion.
Media decoders are one of the highest risk programs since they deal with untrusted user input and are incredibly complex. So just because a large project like ffmpeg uses C, doesn't mean there isn't very good reason to consider a language like Rust for saftey reasons.
The disadvantage in speed when using Rust is pretty obvious.[1] When it comes to video encoding and decoding, I and FFmpeg care a lot more about speed than memory safety. So those reasons have been considered and largely discounted.
[1] https://xcancel.com/FFmpeg/status/1924137645988356437 (to be fair, this is only transpiled from C, so it could probably be optimised further, but that apparently needed a 20k USD bounty to then not even happen (as far as I can tell))
[2] https://www.memorysafety.org/blog/rav1d-perf-bounty/
https://www.youtube.com/watch?v=dEGCdVADLWY
*Da5id
It's a semi-common last name.
https://en.wikipedia.org/wiki/Wiener_filter?wprov=sfla1
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.
That sounds like one of these high-risk, high-reward things that are great for people / projects / companies who have nothing to lose, but is not a great baseline strategy for an established market player. AV2 is here with support from aomedia and its members. AV2 will be used, and we need a production-grade decoder regardless of where AI is at, so it makes much more conservative business sense to use established approaches (language: c/asm, devteam: ffmpeg/dav1d) as a starting point. While that's happening, we can dabble in AI and other risky stuff and see if it helps. If so, great, and if not, nothing lost.
I didn't mean that the Dav1d people should yolo vibe code Dav2d. My point was this this is a very interesting possible experiment since there is no existing Dav2d contamination in the training data.
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're claiming that there are patents, but that doesn't mean there are.
Consumer Display Device: EUR 0.32
Consumer Non-Display Device: EUR 0.11
(source here: https://www.sisvel.com/licensing-programmes/audio-and-video-...)
Dolby is somewhat more interesting in that rather than scare tactics, media hype, and attempting to form a pool about it they are actually taking a patent assertion claim to court.
So they seem to be attempting to pull a fast one and use unproven claims to try and convert their competitor into a replacement revenue source.
It'll probably be a case of whoever has the best lawyers + contacts + persistence wins.
But it'll be interesting if discovery shows evidence they know they don't have a case and are trying it anyway. "Piercing the corporate veil" can theoretically be a consequence of that AFAIK.
I can claim the same and offer licenses per device.
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").