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

51–60 of 150 posts

Re: FFmpeg and a thousand fixes

#51

Post by pjmlp »

colanderman wrote: post #46
lmm wrote: post #27

Earlier quoted context omitted.

The only options I could think of that're mature enough are OCaml and Haskell. I'm aware of video transcoders in both, though nothing with anything like the format support of ffmpeg.

OCaml I know doesn't support SIMD acceleration. Not sure about Haskell. You need SIMD support to get anything decently fast in the field of video/audio manipulation.

That is a compiler issue, not language.

ISO/ANSI C also don't support SIMD, you have to go down to Assembly when writing portable code across C compilers.

Re: FFmpeg and a thousand fixes

#52

Post by lucb1e »

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.

Re: FFmpeg and a thousand fixes

#53

Post by x0x0 »

pjmlp wrote: post #51
colanderman wrote: post #46

Earlier quoted context omitted.

OCaml I know doesn't support SIMD acceleration. Not sure about Haskell. You need SIMD support to get anything decently fast in the field of video/audio manipulation.

That is a compiler issue, not language. ISO/ANSI C also don't support SIMD, you have to go down to Assembly when writing portable code across C compilers.

if we're willing to posit the existence of unwritten software that makes simd work from ocaml or haskell, we could also just assume the existence of C that checks memory accesses for zero cost

also, I think you may be able to do reasonably well with icc and not much assembly

Re: FFmpeg and a thousand fixes

#54

Post by rip747 »

chadillac wrote: post #47
samworm wrote: post #2

It is interesting that YouTube isn't mentioned in this blogpost, despite there being good evidence that ffmpeg has been used there[1]. The fuzz testing they mention is based around constructing malformed (or at least "exotic") input files and then monitoring for failures... ie simulating exactly the kind of attack someone might use against YouTube's transcoding infrastructure. [1] http://multimedia.cx/eggs/googles-yo…

I'm not proud of this legacy code, but... it exists because it was a real world issue that would cripple a conversion server in production envs when fed certain files with timing/syncing errors as part of an automated upload and conversion process. When it would crash it would consume 100% of the cores and eat up enough RAM to force swap. This cron has been keeping ffmpeg in check for over 4 years (not 6, whoopsie) i…

"I'm not proud of this legacy code,"

"This cron has been keeping ffmpeg in check for over 6+ years in a production environment at this point... it processes thousands of videos a day using a custom queuing and reviewing system."

why do we programmers always feel we need to apologize for something that we did quickly, but has been running without incident for a number of years.

take a bow my friend. that was an awesome patch you came up with all those years ago.

Re: FFmpeg and a thousand fixes

#55

Post by StavrosK »

Perseids wrote: post #48
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".

On the 30C3 there was a talk about a C Compiler (actually an llvm optimization plugin) that can eliminate nearly every memory management related vulnerability by adding memory checks. The penalty is only a 100% increase in runtime. > If you're a C programmer and somebody says like: I've that optimization that makes your program 3% faster you go: wow! Then you come and say: well, now I make it half as fast you go: w00…

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.

Re: FFmpeg and a thousand fixes

#56

Post by ux »

astrange wrote: post #50
nathancahill wrote: post #17

Earlier quoted context omitted.

Incompatible? Do you mean with libav?

Backwards incompatible with previous versions of itself.

Most of the old options have been mapped to the new interface (see opt_old2new() for instance). So most of the old commands are still compatible. Libav also has dropped ffmpeg forked copy since a long while, so FFmpeg is actually more retro compatible.

Re: FFmpeg and a thousand fixes

#57

Post by vinkelhake »

pjmlp wrote: post #44
vinkelhake wrote: post #39

Earlier quoted context omitted.

There are other things to consider as well. Compiler support across various platforms: are there compilers available and do they generate good code? Mindshare: how big is the intersection of people who know the language and have the domain knowledge to contribute to the project?

When C was UNIX only, the generated code quality also had a lot to be desired.

Sorry, I don't get what you're arguing here. Are you saying the C-compilers generated poor code when the FFmpeg project was started back in 2000? Are you arguing that if the FFmpeg project had used Modula-2, this would have sparked more work on Modula-2 compilers?

Or are you perhaps just wishing that history had taken a different turn?

Re: FFmpeg and a thousand fixes

#58

Post by Crito »

pjmlp wrote: post #44
vinkelhake wrote: post #39

Earlier quoted context omitted.

There are other things to consider as well. Compiler support across various platforms: are there compilers available and do they generate good code? Mindshare: how big is the intersection of people who know the language and have the domain knowledge to contribute to the project?

When C was UNIX only, the generated code quality also had a lot to be desired.

The initial release of FFmpeg was in 2000, well after that stage in C's life.

Re: FFmpeg and a thousand fixes

#59

Post by Perseids »

StavrosK wrote: post #55
Perseids wrote: post #48

Earlier quoted context omitted.

On the 30C3 there was a talk about a C Compiler (actually an llvm optimization plugin) that can eliminate nearly every memory management related vulnerability by adding memory checks. The penalty is only a 100% increase in runtime. > If you're a C programmer and somebody says like: I've that optimization that makes your program 3% faster you go: wow! Then you come and say: well, now I make it half as fast you go: w00…

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

Re: FFmpeg and a thousand fixes

#60

Post by mkramlich »

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.

this is why Java exploded in the enterprise backend niche
Post reply on HN