Top
Best
New

Posted by captain_bender 7 hours ago

Dav2d(jbkempf.com)
317 points | 103 commentspage 2
yieldcrv 4 hours ago|
D4vd
spiral09 2 hours ago||
[dead]
poly2it 6 hours 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 6 hours 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.
cogman10 6 hours 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 1 hour 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.
cogman10 6 minutes 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.

jbk 6 hours 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.

cesarb 11 minutes 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.

LoganDark 4 hours 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 hours 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.

throawayonthe 4 hours ago|||
but not these cases
bigyabai 24 minutes ago|||
It really should be, though: https://en.wikipedia.org/wiki/FORCEDENTRY
IshKebab 3 hours ago|||
I don't see why not. What makes you think this is unique?
muhbaasu 6 hours 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.
nmz 2 hours ago|||
https://youtu.be/nepKKz-MzFM&t=7195

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.

stukenov 1 hour ago|||
fyi the Rust port already exists: https://github.com/stukenov/rav2d you keep the hand-written asm via FFI, rest is safe Rust. same trick rav1d uses.
throawayonthe 4 hours ago|||
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

Thaxll 1 minute ago|||
It is much slower than 5%, there were other independent tests that put it around 20%.
stukenov 1 hour ago|||
there's a rav2d now too fwiw — https://github.com/stukenov/rav2d same playbook: safe Rust + asm kernels via FFI. just shipped 0.1.0.
Telaneo 6 hours ago|||
Go ask FFmpeg what they're writing their encoders and decoders in.
latexr 6 hours 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 5 hours 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 hours 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.
IshKebab 2 hours 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.

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.

stukenov 1 hour ago||
funny you mention it — rav2d exists now: https://github.com/stukenov/rav2d full C-to-Rust port, asm kernels still via FFI like rav1d does. early (0.1.0) but passes conformance against dav2d.
MattRix 6 hours ago||
Yes? There is 5x more code to optimize the ASM for.
latexr 6 hours 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 hours 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 4 hours 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 4 hours ago|||
As with all naming schemes in the tech world, I am sure no future scenarios, including successor names, were ever considered
jl6 6 hours ago|||
1dav2codecs?

2av2furious?

Hendrikto 5 hours ago||
And then AV3: Tokyo Drift, and after that AV Episode 1.
xp84 4 hours 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 1 hour ago||
AV360. AV365. AV2030. AVXP. AV8. AV10. Perhaps some here will be around for AV95.

Young AV?

BillStrong 5 hours ago|||
Already predicting which versions to avoid, huh.
WhrRTheBaboons 6 hours ago|||
> experience Dav... Now in 3D!
Arubis 6 hours ago|||
Da5id could potentially work as a Snow Crash reference.
latexr 3 hours 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.
aetherspawn 6 hours ago||
Ok whose idea was ‘Wiener filtering’
cogman10 6 hours ago|
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

Eldodi 6 hours 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.

https://accessadvance.com/2026/03/24/access-advance-licensor...

UnlockedSecrets 6 hours ago||
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 6 hours ago|||
How does that prove anything?

They're claiming that there are patents, but that doesn't mean there are.

Eldodi 6 hours ago||
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-...)

zamadatix 6 hours ago|||
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 5 hours 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.

UnlockedSecrets 6 hours ago||||
How does how they bill for their product, matter in terms of if their lawsuit holds merit?
croes 6 hours ago||||
That doesn’t prove their claims are valid.

I can claim the same and offer licenses per device.

silotis 6 hours ago|||
Can you point to any other patent lawsuit over AV1? AFAIK the Dolby case is the first.
Arodex 6 hours 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").

croes 6 hours ago||
No codec can ever avoid patent-pool claims.
kingstnap 5 hours 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.