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 :)
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.
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.
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
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.
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.
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.
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 :)
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.
What are you even implying?
It’s not Rust, therefore it’s bad. Or something. This is getting rather tedious.
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.
2 replies →
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...
I think they mean that video decoders and encoders tend to have custom assembly code for speedup.
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
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.
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.
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/
2 replies →
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.
3 replies →
[flagged]