| 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. |
How can you claim nobody cares about 5%? A 5% performance increase is significant. And video decoding is not always for playback, where 5% may not matter as much.