Comment by ellis0n | Hacker News Reader

Comment by ellis0n | Hacker News Reader

Parent Full thread

The "triumph of high quality open source software" is wrong because ffmpeg is old C/ASM hacky code (not even C++, optimized by speed for hardware). I got my first experience of optimizing ffmpeg video decoder for AMD Alchemy processor in 2006.

Let's take a look at the history of ffmpeg created by hackers for hackers.

Do you remember how many times you saw strange squares on the screen when rewinding a YouTube video or DVD MPEG2, or random freezes when streaming Twitch when you think it is a video stream error. But no. Most of these are programming errors of the ffmpeg hacker backend, which has many pointer errors. It is difficult to recovery state from a failure of any level due handling C and pointer errors. The global use of ffmpeg is caused by the lack of FOSS alternatives, but not by the quality of the software. It was cheaper for corporations to fix bugs and hire a developer like me than to develop their own video codec or system from scratch. All alternatives were closed source and required of tones of money per tech licenses like MPEG2. Of course, over the years, the ffmpeg ecosystem has improved and many bugs have been fixed, but this has not changed the general situation with existing and potential bugs and vulnerabilities by design. Therefore, in different video applications, you can observe random bugs and signal drops every day. Nice try John ID_AA_Carmack

This is conflating two very different issues. While ffmpeg certainly has its share of vulnerabilities in part caused by it being an old and crusty C project, that has little to do with video glitches. Video glitches are usually caused by corner cases in decoding, e.g. issues with reference frames during seeking. Those are logic errors, which any project handling video formats would be prone to because video codecs are ridiculously complicated these days.

Your blocky errors in video playback aren't caused by a pointer going wild due to bad pointer math in ffmpeg. They're caused by bad or corrupted input or an improper seek to a non IDR point in the file. ffmpeg is rock solid for playback of standard corruption-free h.264 streams. This idea that any time you see corrupted video it's a (potentially exploitable) bug in ffmpeg is just not true. Nobody is getting "signal drops" due to ffmpeg problems.

Now if you start fuzzing ffmpeg and giving it wildly noncompliant and broken input, yes, you're going to run into memory errors at some point - which is why there are companies doing just that these days, to find and fix those security flaws. Most of those bugs aren't even in popular codecs (since those are extremely well tested), but rather in the very long tail of obscure formats that ffmpeg supports (try counting how many obscure video game formats it supports some time!), and therefore in codepaths that nobody watching YouTube or Twitch is ever going to hit.

This is a code audit issue. Video codecs and drivers are a niche and are extremely protected by patents. The number of ffmpeg researchers and developers is very small compared to the number of lines of code, closed standards and soft/hard bugs in each series of specific video hw/sw encoders and decoders. And an AI that can analyze and validate code as complex as ffmpeg has yet to be invented.

It's a programming language issue. Any time you're writing complex format parsing code in an unsafe language like C, you're going to run into these problems. Unfortunately, Rust didn't exist when ffmpeg was created.

Patents have absolutely nothing to do with this; they don't affect the security of the resulting code.

Nobody can write code for all the formats ffmpeg supports and do it safely, in C. Nobody. You think audits work? Tell that to Infineon, who shipped a broken RSA key generator implementation. In a cryptography product. Which was audited privately. And that's a critical part of the code that should've had many eyes on it.

Perfect memory safety for C parsers for hundreds of formats? Yeah, not going to happen. It has nothing to do with the code quality of ffmpeg. It's just not humanly possible to get this right in every instance.

> It's just not humanly possible to get this right in every instance.

That's what theorem provers and model driven development are for.

I wish these tools could be used more. There should also be automated completeness checkers for requirements and specs - a lot of errors, incompatibilities and security issues are the result of ambiguous, contradictory, or incomplete specs and requirements.

> That's what theorem provers and model driven development are for.

That's building a safe programming language on top of an unsafe one. At that point you might as well just use a safe programming language.

That won't fix logic errors, but the vast majority of security issues are safety problems, especially in this kind of codebase.

There is no algorithm in the world for how to check whether a video codec is working correctly or not

The model checking would not check the output but the trace of operations.

It might prove that all bytes of the output were written to at least once, that dereferenced pointers point toward either the input or some other valid structure, and other properties like this.

I agree with RSA key generator implementation idea and I like Rust is better C idea

ffmpeg/libav is being fuzzed with reasonable success. See for example https://github.com/google/oss-fuzz/tree/master/projects/ffmp... and https://security.googleblog.com/2014/01/ffmpeg-and-thousand-....

They found issues in code I wrote...

(I work for Google but do not speak for it)

What's high quality open source software? ffmpeg works well, I don't think an alternative would be much better. There will never be a software without bugs. The alternative would be spending tons of money for another piece of software with more bugs.

Good quality software means good architecture design, less code, fewer bugs, more language features and advanced programming to prevent bugs. FFmpeg works well because the hackers did a good job but spent millions of man-hours shooting themselves in the foot.

I think good quality software is a relative term, and I'd rather have useful softwares. What happens in big company is when software age, fresh employees will say it is not a good software, then they will start from fresh code base, maybe discard some features, write some new bugs, the software would generally at the same level as the old ones. The same can happen in opensource community as well, someone could start a new ffmpeg.

Reply on news.ycombinator.com