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/
Not just performance, the code was littered with unsafe blocks and the benchmarks (IIRC) were gamed heavily by the Rust devs.
It was a dishonest effort that actually undermined the memory safety pitch.
> 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.
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.
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
It does not contradict it, and also, a gif is not a video.
> a gif is not a video.
They're not that different; the image codec WebP is derived from VP8's intra-frame coding.