FFmpeg and a Thousand Fixes (2014) | Hacker News Reader

FFmpeg and a Thousand Fixes (2014)

security.googleblog.com

26 pointswglb14 comments

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

Probably.

ffmpeg is still the king of multimedia although several people are starting to write parsers in rust.

> 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).

Cool--this must be the real Brent Ozar, master of SQL?

Yes, that was my motive. I have a different view of this celebrite thing having spent time in the eDiscovery world.

Hahaha, yes, this is indeed me! I love the eDiscovery business. Such a fun problem to solve.

We met at the special bar meetup Scott sponsored during fest!

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 remember a decade or so ago VLC would crash semi regularly [...]

> I can’t remember the last time I experienced a crash.

So which one is it? :) j/k

VLC really became super stable from an enduser-only subjective perception.

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.

edit: I found the video: https://youtu.be/ydqNot4csmE?t=637

> we recommend that people refrain from using either of the two projects to process untrusted media files

This seems like a reckless recommendation, as people would then likely use software even more poorly tested to play internet videos.

It's kind of a useless recommendation, because it doesn't list any example that is fuzz-clean.

There have been 2000 fixes related to fuzzer issues so far, averaging 400 fixes in recent years. Almost all of them are taken care of by Michael.

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.

Reply on news.ycombinator.com