4 ms·
Is this a reference to this: https://news.ycombinator.com/item?id=45785291 https://news.ycombinator.com/item?id=45785291 ? If so, FFmpeg's stance is very under
by Telaneo 5mo ago
Is this a reference to this: https://news.ycombinator.com/item?id=45785291 https://news.ycombinator.com/item?id=45785291 ?
If so, FFmpeg's stance is very understandable in my opinion.
- Gigachad 5mo agoSomewhat, but somewhat not. Yes it's a very obscure format, and yes it's partially a marketing stunt from Google for their AI tools. But it's also a real bug which is exploitable on ffmpeg. And we have seen in the past that state sponsored hacking groups specifically target media decoders with obscure formats that aren't often tested or known about. Media decoders are one of the highest risk programs since they deal with untrusted user input and are incredibly complex. So just because a large project like ffmpeg uses C, doesn't mean there isn't very good reason to consider a language like Rust for saftey reasons.
- Telaneo 5mo agoIf Google want secure encoders and decoders, then they can donate money or patches. Since they don't, the clearly don't actually care all that much, or are just mooching of volunteers' goodwill. The disadvantage in speed when using Rust is pretty obvious.[1] When it comes to video encoding and decoding, I and FFmpeg care a lot more about speed than memory safety. So those reasons have been considered and largely discounted. [1] https://xcancel.com/FFmpeg/status/1924137645988356437 https://xcancel.com/FFmpeg/status/1924137645988356437 (to be fair, this is only transpiled from C, so it could probably be optimised further, but that apparently needed a 20k USD bounty to then not even happen (as far as I can tell)) [2] https://www.memorysafety.org/blog/rav1d-perf-bounty/ https://www.memorysafety.org/blog/rav1d-perf-bounty/