Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg and a thousand fixes

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

111–120 of 150 posts

Re: FFmpeg and a thousand fixes

#111

Post by rossy »

pjmlp wrote: post #22

The wonders of C: - NULL pointer dereferences, - Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, - Out-of-bounds reads and writes to stack, heap and static-based arrays, - Invalid free() calls, - Double free() calls over the same pointer, - Division errors, - Assertion failures, - Use of uninitialized memory. But hey, any good programmer always writes perfect C code.

And yet, FFmpeg couldn't really have been written in anything else. A 5% difference in performance could be the difference between a 1080p video decoding in real time on a low powered device like a phone or a netbook and the video decoding slightly slower than real time. Improvements to FFmpeg made my old netbook work as a video player. I don't think I would have been able to use an FFmpeg-based player at all if it had the overhead of being written in a more memory safe language.

Re: FFmpeg and a thousand fixes

#112

Post by Goopplesoft »

lucb1e wrote: post #52
lmm wrote: post #26

A thousand , and all the categories they list are things the computer should catch for you. How many more will it take before we switch to better languages?

Be aware that these are open-source projects. I don't see you starting a fork in a better language.

I find this, 'don't complain, fork/fix' mentality ridiculous. Why should he? If his goal is get people off C, communicating/persuading in a developer community comments is probably more effective than him creating a project in some other language that no one would likely ever use.

Re: FFmpeg and a thousand fixes

#113

Post by dgesang »

vinkelhake wrote: post #25
pjmlp wrote: post #22

The wonders of C: - NULL pointer dereferences, - Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, - Out-of-bounds reads and writes to stack, heap and static-based arrays, - Invalid free() calls, - Double free() calls over the same pointer, - Division errors, - Assertion failures, - Use of uninitialized memory. But hey, any good programmer always writes perfect C code.

Really breaking new ground here. What should FFmpeg have been written in? I can think of a few candidates, but I think they share a number of those "wonders".

> What should FFmpeg have been written in?

There'll be a HN topic A FFmpeg reimplementation in JavaScript soon enough ...

Re: FFmpeg and a thousand fixes

#114

Post by thristian »

lhgaghl wrote: post #103
ID_HOME wrote: post #28

Earlier quoted context omitted.

I guess the correct solution is to use Java? Then we can bitch about run away garbage collection. How about Python then? It's really "fast". Or we can program it in snide remarks on forums, then we don't even have to write any working code to feel superior.

If Java is somehow a problem, you can simply make a language without stack smashing but also without GC. Nobody has done this so far because nobody gives a shit about the fact that every program we use is full of remote code vulns and will never be fixed.

You haven't been reading all the Rust release announcement threads, have you?

Re: FFmpeg and a thousand fixes

#115

Post by verroq »

pjmlp wrote: post #22

The wonders of C: - NULL pointer dereferences, - Invalid pointer arithmetic leading to SIGSEGV due to unmapped memory access, - Out-of-bounds reads and writes to stack, heap and static-based arrays, - Invalid free() calls, - Double free() calls over the same pointer, - Division errors, - Assertion failures, - Use of uninitialized memory. But hey, any good programmer always writes perfect C code.

C++11

Re: FFmpeg and a thousand fixes

#116

Post by morsch »

dgesang wrote: post #113
vinkelhake wrote: post #25

Earlier quoted context omitted.

Really breaking new ground here. What should FFmpeg have been written in? I can think of a few candidates, but I think they share a number of those "wonders".

> What should FFmpeg have been written in? There'll be a HN topic A FFmpeg reimplementation in JavaScript soon enough ...

Process videos in browser using FFmpeg compiled to JavaScript (56 days ago) https://news.ycombinator.com/item?id=6739582

Re: FFmpeg and a thousand fixes

#117

Post by bane »

Perseids wrote: post #59
StavrosK wrote: post #55

Earlier quoted context omitted.

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

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

Re: FFmpeg and a thousand fixes

#118

Post by hrjet »

pcwalton wrote: post #109
ajross wrote: post #108

Earlier quoted context omitted.

My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. But the macro point is just empirical: the proof that Rust is an appropriate tool for codec development needs to come in the form of a production-quality codec implementation of some non-trivial standard (VP9, say),…

> My (micro-) point was more that memory bugs are going to be inherent in a codec implementation because of the nature of hte problem, obviously not that all of the bugs are going to come from the assembly. I don't understand this. If you write in a safe language, the compiler rules out the memory safety bugs, regardless of the problem. > But the macro point is just empirical: the proof that Rust is an appropriate to…

> I don't understand this. If you write in a safe language, the compiler rules out the memory safety bugs, regardless of the problem.

For performance sensitive code, you sometimes need to deliberately step out of the strongholds of the compiler.

Re: FFmpeg and a thousand fixes

#119

Post by zw »

Goopplesoft wrote: post #112
lucb1e wrote: post #52

Earlier quoted context omitted.

Be aware that these are open-source projects. I don't see you starting a fork in a better language.

I find this, 'don't complain, fork/fix' mentality ridiculous. Why should he? If his goal is get people off C, communicating/persuading in a developer community comments is probably more effective than him creating a project in some other language that no one would likely ever use.

> communicating/persuading

Snarky, whiny, bitching comments do not a discourse make.

Re: FFmpeg and a thousand fixes

#120

Post by lhgaghl »

thristian wrote: post #114
lhgaghl wrote: post #103

Earlier quoted context omitted.

If Java is somehow a problem, you can simply make a language without stack smashing but also without GC. Nobody has done this so far because nobody gives a shit about the fact that every program we use is full of remote code vulns and will never be fixed.

You haven't been reading all the Rust release announcement threads, have you?

I wasn't even taking Rust into consideration. One could make a language the way I said with no problem in a small amount of time. I'm talking no novel stuff. Arrays bound checked at runtime. No attempt at code correctness even has to be offered, get rid of remote code execution vulns, and suddenly you watch HD videos without fearing for your life. It simply isn't done because nobody cares. It's not sexy enough. It's been 30 years now.
Post reply on HN