Top
Best
New

Posted by dabinat 19 hours ago

Dav2d(code.videolan.org)
494 points | 136 commentspage 2
shmerl 10 hours ago|
Nice.

What's the current state of of Dolby trying too attack AV1 ecosystem (Snapchat more specifically)? I hope there is an organized fight back by AOM against these trolls.

sylware 17 hours ago||
I would even remove the C code and lower the usage of the assembler pre-processor to a basic C pre-processor.

Happy, AV2 decoding already here.

:)

kk_mors 1 hour ago||
[dead]
Zopieux 18 hours ago||
[flagged]
tux3 17 hours ago||
Not just C, dav1d and dav2d are actually mostly written in ASM! Then there's a bit of C as the glue or for functions that don't have optimized ASM yet.

Since dav2d is newer it has a higher fraction of C, but not enough for it to be the main language in the codebase :)

dataking 8 hours ago|||
for dav1d there is https://github.com/memorysafety/rav1d although it reuses the dav1d assembly and performance is typically slower by a single-digit percentage.
Almondsetat 17 hours ago||
What are you even implying?
kergonath 13 hours ago|||
It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.
Gigachad 11 hours ago|||
I don’t think it’s unfounded. Media codecs have been one of the top sources for serious vulnerabilities. The code is incredibly complex, and takes complex input from untrusted sources.

Decoders are one of the best places for rust because they are both performance critical and security critical.

JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it. And the apps that did utilise the C based libjxl ended up hit with vulnerabilities in it.

F3nd0 7 hours ago|||
> JPEG-XL couldn’t get off the ground until they recreated the decoder in Rust since none of the browsers wanted to touch it.

This is extremely misleading. Before they even started work on the Rust-based decoder, experimental JPEG XL support was added to Chrome and Firefox using the reference C++ implementation. Chrome later removed this support for very dubious claims of lack of interest and improvement over previous generation of codecs.

Around that time, Safari shipped JPEG XL support in production, still without the Rust implementation. So the assertion no one wanted to touch it is plain false.

It was actually Mozilla who, a long time after stating they were ambivalent on JPEG XL, brought up memory safety as a major consideration, for the very first time. That’s when the work on the Rust implementation started.

Since the format continued to be more and more supported and talked about, it’s hard to say what exactly were the factors which made Google reconsider their stance. The notion that somehow everyone was super worried about memory safety from the very beginning, and once the JXL team fixed that, everyone was happy to embrace it, seems to come up a lot lately, but it’s terribly distorted and simply not true.

kergonath 3 hours ago|||
> I don’t think it’s unfounded.

Not necessarily. What’s annoying is these low-effort posts that bring nothing. In some contexts the discussion is worth having, but we can do better than "it’s bad because it’s not in my pet language" groupthink.

perching_aix 4 hours ago|||
you're falling for and/or playing along with astroturfing, that's what's tedious

can't people coping about rust come up with something fresh? always the same dance:

- fake annoyance about <thing> not being written in rust (bonus points if nonsensical, like here)

- if merely insinuated, fake question about what do they mean exactly

- fake surprise about omg why are people like this, the rust community is so bad, wah wah wah

yawn

oh yeah, let's not forget the other classic:

- the rust community is so dumb for thinking <shit they don't think made up for an easy beatdown>

- yeah ikr haha so stupid

every fucking rust thread is like this, and it's unreadable. by intention of course, obviously.

but it's ai / corporations / the government ruining the internet guys! totally...

notenlish 16 hours ago||||
I think they mean that video decoders and encoders tend to have custom assembly code for speedup.
Almondsetat 15 hours ago||
And? It's common knowledge that the "reference" or "research" version of any codec is always quite high level to get development going and actually produce a working bitstream
IshKebab 16 hours ago||||
That codecs should be written in safer languages given that they usually process untrusted files. There have been a number of serious hacks from file parsing bugs due to them being written in unsafe languages.

There's literally a DSL designed for this purpose (Wuffs) so it would be interesting to hear why they didn't use it.

brigade 16 hours ago|||
There's an order of magnitude difference in speed requirements between file format parsing and image decoding, then another order of magnitude difference to video decoding. Even rav1d reuses dav1d's assembly (most of the actual runtime) to approach its speed.
adobrawy 14 hours ago||||
There was already attempt for dav1d to re-implement in rust by rav1d. It was hard to match performance: https://www.memorysafety.org/blog/rav1d-perf-bounty/
IshKebab 3 hours ago||
> It was hard to match performance

They say it is 5% slower. That's close enough. I know they say it isn't but in reality that speed difference is just going to be used as an excuse by the anti-Rust crowd.

astrange 13 hours ago|||
The people who write DSLs for video codec asm, or who claim that it's fine to use intrinsics or X higher-level language and it will still be fast enough to be usable, are simply wrong and have never been able to demonstrate otherwise.

Having said that I do think you could write a DSL to generate safe performant asm for a video codec. Just not a platform-independent one. It would still have to be asm.

dwattttt 12 hours ago||
It sounds like your second statement contradicts your first. But also, WUFFS exists and it looks like the Google Chrome GIF decoder ships in it: https://github.com/google/wuffs
astrange 9 hours ago||
It does not contradict it, and also, a gif is not a video.
dwattttt 7 hours ago||
> a gif is not a video.

They're not that different; the image codec WebP is derived from VP8's intra-frame coding.

sergiotapia 16 hours ago|||
[flagged]
xnx 18 hours ago||
[flagged]
virtualritz 17 hours ago||
And who ever heard of this in the majority of the world? It was news to me, I'm white and European btw.

Did you know the US consititues about 4% of humans? When we look at adults and age range that likely ever hear of D4vd we are talking probably considerably less that 1%.

The rest of humanity has no negative association with these four letters.

pesus 17 hours ago|||
It was my first thought when I saw the name, unfortunately. The US constitutes a large portion of this site's user base. Whether the association sticks around is yet to be seen.
DaiPlusPlus 17 hours ago||||
> And who ever heard of this in the majority of the world? It was news to me, I'm white and European btw.

It's a recurring headline on the rolling news channels on broadcast TV right now - and it's on the front-page of Reddit for me as well.

Almondsetat 17 hours ago|||
So a project should change its name because when it will be production ready 6 years from now the 1% of the 1% of the 1% will think for 1 microsecond about a piece of news from today?
Lerc 17 hours ago|||
Just that remember that there were people that said calling the second LOTR movie The Two Towers was disrespectful.
DaiPlusPlus 16 hours ago||
Hollywood retitles movies based on books all the time[1], for the silliest of reasons ("Sorcerer's Stone" was contemporaneous to LOTR too); so given there's precedent, it follows that those wanting to retain the original title from the books should defend their position.

[1] https://www.empireonline.com/movies/features/book-movie-titl...

DaiPlusPlus 17 hours ago|||
> So a project should change its nam

Potentially... supposing the criminal investigation into this uncovers a hitherto unknown organ harvesting scheme operating within the global music records industry; the subsequent police dragnet implicates significant proportion of the world's music stars and record labels and generates continual major headlines and criminal convictions - with all their lurid details - all for multiple decades from now on.

It's quite ridiculous when I put it that way, but this is basically the same thing as Epstein's network, just with a different crime; and Epstein was already in the news almost 20 years ago from his first conviction.

...so back in 2009, back when everyone was building their own social-network websites and online dating services, and supposing your real-name was also Epstein, so you called it "EpsteinLoveIsland.com" - would you have changed the name back then?

dingdingdang 17 hours ago||||
Gotta admit this was the first thing I thought of as well. Hard to focus on the code implementation with that in mind!
encom 16 hours ago|||
>news channels on broadcast TV

So no one below the age of 60 is aware of this.

zimpenfish 16 hours ago||
It was above-fold on the BBC news website[0][1] several times over the past couple of months.

[0] highest reaching uk language news site in March 2026 - https://pressgazette.co.uk/media-audience-and-business-data/...

[1] >400M visits weekly - https://www.bbc.co.uk/mediacentre/2025/bbc-response-to-globa...

flykespice 15 hours ago|||
> I'm white and European btw.

Why did you feel the need to explicitly specify that you're white as one of the reasons you didn't hear the news?

I'm not american either, but the news is all over social media platforms like reddit and Twitter, it's hard to turn a blind eye on them.

cosmotic 18 hours ago|||
Its a followup to their existing Dav1d decoder (av1, av2)
cogman10 17 hours ago||
Which, should be noted, was a thing before d4vd started his career.

dav1d - started in 2018

d4vd - started composing in 2021

NewsaHackO 17 hours ago|||
It's just unfortunate. Like there was a pharmaceutical company named "Isis" that changed their name due to the association with the terrorist group. That said, while people will notice for the next couple of months, I don't think it warrants changing a name for.
cozzyd 10 hours ago||
More importantly there's a really good band named isis that probably has not benefitted from the Islamic state. (Ok, they disbanded in 2010, but still).
walrus01 17 hours ago||
By this logic nobody should ever name their child Ted or Theodore because Ted Bundy existed.
quickthrowman 1 hour ago||
You ever meet someone named Adolf? Sometimes names actually are no longer used after a particularly terrible person had that name.
arkensaw 13 hours ago||
maybe not great naming. Sounds very similar to the rapper D4vd, who was just arrested for murdering a 14 year old girl
jofzar 13 hours ago|
Actually it's closer to https://youtube.com/@dave2d who is a popular tech YouTuber
bl4ckneon 10 hours ago||
That is what I thought of too. Almost live David is a popular name or something... /s
kylec 16 hours ago||
I wonder if the author is a Dave2D fan?

https://www.youtube.com/@Dave2D

7bees 16 hours ago||
I think it's an increment on this: https://www.videolan.org/projects/dav1d.html
breve 13 hours ago|||
The AV1 decoder is dav1d. The AV2 decoder is dav2d.

One day in the mysterious future the AV3 decoder will be dav3d.

d3Xt3r 15 hours ago|||
Or a fan of Dangerous Dave 2

https://en.wikipedia.org/wiki/Dangerous_Dave_in_the_Haunted_...

foo-bar-baz529 16 hours ago||
They’re more of a D4vd fan
DonHopkins 10 hours ago||
D4ve's not here!
dcsommer 17 hours ago|
We must not continue to develop media codecs in memory unsafe languages. Small, auditable sections can opt-out perhaps, but choosing default-unsafe for this type of software is close to professional negligence.
fguerraz 17 hours ago||
Cryptography and video codecs are notable exceptions, they put a lot of effort to making the code provably memory safe: no recursion, limited use of stack variables, no dynamic allocations, etc. As a result, memory safe languages bring nothing but trouble by making it non deterministic, that’s especially true for crypto where compiler “optimisations” guarantee you side channels attacks.
WhatIsDukkha 15 hours ago|||
Thank you for mentioning this.

I wonder IFF Rust had an effects system that a Jasmin MIR transform (ie like SPIRV is for shaders) would be useful?

https://github.com/jasmin-lang/jasmin

astrange 13 hours ago||||
Video codecs just don't need to do dynamic allocations because it's not relevant to the problem. There's still certainly plenty of opportunities for memory bugs because there's a lot of pointer math.
simonask 13 hours ago|||
What in the world do you mean by “non-deterministic”?

C compilers, Rust compilers, and assemblers are all deterministic.

fguerraz 6 hours ago|||
In cryptography, you want operations to run in constant time, even if it’s wasteful, otherwise an attacker could guess information about the key or plaintext by measuring execution times.

Modern compilers are extremely clever and will produce machine code that takes full advantage of modern CPU branch predictors, and reorder instructions to better take advantage of pipelining. This in itself will make the same code run at different speeds depending on the input data.

Then there is the whole issue of compiler version roulette. As a developer you have no idea which version of compilers your users and distros will use, and what new and wonderful optimisation they will bring.

simonask 3 minutes ago||
I know that, but none of that makes the compiler output non-deterministic.

Determinism does not mean “easy to predict”, it just means “predictable”.

adgjlsfhk1 9 hours ago|||
> C compilers, Rust compilers, and assemblers are all deterministic.

Within a version, yes, but not cross version. Different versions of GCC/Clang etc can give you completely different code.

fishgoesblub 17 hours ago|||
Of the 3 software AV1 encoders, the only one that is fully dead is the Rust encoder (rav1e). If people truly wanted memory safe encoders/decoders, they would fund and develop them.
Sesse__ 1 hour ago|||
I can totally understand why people would want a memory-safe decoder, but a memory-safe encoder is niche. Finding a memory-safety bug in a decoder is a matter of finding a single unchecked integer field somewhere; finding a memory-safety bug in an encoder requires first finding some sort of logic bug in the encoder and then crafting an adversarial input that survives a number of highly lossy transformations.

Compare the number of CVEs against x264 (included decoders don't count!) and FFmpeg's H.264 decoder.

dataking 2 hours ago||||
https://github.com/memorysafety/rav1d got funded and developed. it is unfortunately a bit slower (typically by a single-digit percentage) than dav1d.
simonask 13 hours ago||||
Encoding is a way, way less risky thing to be doing compared to decoding.
vlovich123 16 hours ago||||
Fully dead in what sense? Seems like it still has active development to me.
fishgoesblub 16 hours ago||
It hasn't had any proper quality/speed improvements in years. Only thing that has changed is updating deps and some bug fixes.
snvzz 2 hours ago||||
There are many paths to memory safety, even if the one Rust project seems to be going nowhere.

There's other memory-safe languages, and there's formal verification.

e.g. seL4 favors pancake.

esseph 17 hours ago|||
> If people truly wanted memory safe encoders/decoders

Really? How many codecs have your neighbors contributed money for the development of, just curious.

computerbuster 15 hours ago|||
I think these conversations are directed by the parties funding the efforts. Example: "we (large company) want a fast AV2 decoder" -> they pay a specialized team to do it -> this team works in C for the most part, so it is done in C. If there were financial incentives to do it in Rust, they'd pay more for a Rust decoder.
Telaneo 16 hours ago|||
Given Netflix's involvement with SV1-AV1, (not even that) indirectly, at least 1.
kllrnohj 15 hours ago|||
For the codec itself, the majority of it is performance sensitive and often has a significant amount of assembly even, so a memory safe language doesn't change much.

However for the container/extractor... those should absolutely be in a memory safe language, and those are were a lot of the exploits/crashes are, too, as metadata is more fuzzy.

As a practical example of this see something like CrabbyAVIF. All the parser code is rust, but it delegates to dav1d for the actual codec portion

maxloh 15 hours ago||
Decoders written in Rust will be a lot slower than the equivalents in assembly.