4 ms·
> especially for something like a video codec Why especially video decoders? > I wonder if they really care or if this is one of those "we don't want to use R
by Benjamin_Dobell 1y ago
> especially for something like a video codec
Why especially video decoders?
> I wonder if they really care or if this is one of those "we don't want to use Rust because of silly reasons and here's are reasonable-sounding but actually irrelevant technical justification"...
I would have thought video decoders are specifically one of the few cases where performance really is important enough to trump language guaranteed security. They're widely deployed, and need to work in a variety of environments; everything from low power mobile devices to high-throughput cloud infrastructure. They also need to be low latency for live broadcast/streaming.
That's not to say security isn't a concern. It absolutely is, especially given the wide variety of deployment targets. However, video decoders aren't something that necessarily need to continually evolve over time. If you prioritize secure coding practices and pair that with some formal/static analysis, then you ought to be able to squeeze out more performance than Rust. For example, Rust may be inserting bounds checks on repeated access — where as a C program could potentially validate this sort of information just the once up front and pass the "pre-validated" data structure around (maybe even across threads) "knowing" that it's valid data. Yes, there's a security risk involved, but it may be worth it.
- steveklabnik 1y agoNot your parent, but video codecs are basically handling untrusted input from a user, and are therefore the sorts of programs that have a good justification for increased safety. You're also right that performance is paramount. That's why it's non-trivial.
- IshKebab 1y ago> Why especially video decoders? Codecs are a very common source of security vulnerabilities.