The difference is that FFMpeg is very, very CPU-bound, taking four hours instead of two to encode a movie is a big hassle. On the other hand, not many people use a world-facing FFmpeg instance to submit jobs to. I don't see why security should trump speed here.

You mean, not many people use VLC?

https://www.videolan.org/developers/vlc.html#thirdparty

For realtime playback locally sure. I don't think there are many/any public-facing systems backed by VLC. Presumably VLC prioritizes speed over security.

Oh, that was the point being made. My view is that VLC essentially is a public facing system, in the same sense that my browser is a public facing system. Sure, it is not as easy to do a targeted attack against my VLC as against my mail client (or against the nginx on my server). But it is fed a lot of untrusted data. The same goes for Chrome, which also uses FFmpeg according to the article.

or plex, which i believe is ffmpeg based for real-time transcoding

There's also AT&T Labs' memory-safe dialect of C called Cyclone: http://cyclone.thelanguage.org/

It's been around since 2006, but I haven't really heard of anyone using it. I wonder why.

Cyclone has been dead since years (the last release is dated 5 May 2006)

It never compiled on 64bit architectures, and to get it to compile with 4.0 or 4.1 (newer versions of gcc won't work) you need to fetch it from SVN (last commit is dated May 2009)... and obviously: no distribution still ship such an old version of the build tools... you'd need something like debian lenny, which does not even receive security updates anymore

"that can eliminate nearly every memory management related vulnerability"

This is like saying "my bulletproof vest will stop nearly every round fired at it". Too bad it only takes ONE...

So I suppose you'd rather not wear any bulletproof vest?