Guessing this is related to the recent documentation by Signal about how Cellebrite is using a 2012 version of FFmpeg, long before these code fixes went in: https://news.ycombinator.com/item?id=26891811
> several people are starting to write parsers in rust
ffmpeg is what it is because it's way more than "parsers". It's all the parsers, and the filters, and everything you need to feed it any audio/video file you have, and get any audio/video file you want in return. That's why out of all the tools out there that's the one everyone and everything uses, from VLC to Chrome to your phone to your TV to your car to whatever.
This is like saying "sqlite is still the king of embedded sql but several people are starting to write databases in rust".
PS: another reason for ffmpeg massive success is simply that Michael is an insanely productive and dedicated developer, as seen in this story and also in the "libav splits because they don't like him but then the project fails because they don't have him" (yes, this is a vast oversimplification).
I remember a decade or so ago VLC would crash semi regularly while playing various media with weird ffmpeg related segfaults. I’ve noticed vlc has gotten way more stable over the last few years - I can’t remember the last time I experienced a crash.
It’s weird to think I have Google to thank for that; though I suppose it makes sense given they embed ffmpeg in chrome and other services.
I will note that this ffmpeg work by google is still ongoing. I do remember an ffmpeg (then libav) developer mentioning that this will never end since this is C and since ffmpeg is doing parsing of data.
I wonder if in future someone could write a competitor to these C based media libraries in Java. Today it wouldn't really be ideal, but the combination of Graal native image, such can build standalone native libraries with C ABI interfaces, the new vector API and eventually value types, means Java should become competitive for the sorts of high performance media tasks that C currently dominates. And being a standalone shared library means it would be feasible to make a drop in compatible replacement for ffmpeg.
Of course we're still some way from this being possible but over 1000 fixes and still going means ffmpeg and the like can never really be trusted. Add the blog post says, it's not safe to use with media of unknown source but the whole point of media is to come from other people. How often do you play video from sources you don't trust? It happens all the time. The only reason it's not chaos today is we proxy everything through giant re-encoding farms like YouTube, and browser sandboxing.
If you haven't heard of it yet, you might find the rust language interesting. It is the most likely candidate for replacing C in applications like this today. It is kind of like C with built-in static analysis to enforce memory safety, plus a modern type system and tooling. It also has robust C ABI support.
