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