I know it certainly was several years ago, and the problem was magnified by every video sharing site using it in their ingestion and transcoding pipelines. It's a single, incredibly powerful and versatile tool, to the point where it's often easier[ß] to fiddle around with command line parameters than to hit the underlying libraries directly.
And by design, in that kind of setup ffmpeg is processing vast quantities of untrusted inputs, coming in at all possible (and some impossible) combinations of video formats, container formats, invalid segment headers, bitstream corruptions and whatever else you can think of. If my memory serves me right, when M. Zalewski first joined Google, he worked on YouTube's video processing ... and to make their engine more robust, started to fuzz ffmpeg. I've heard people describe the result as if shaking a plum tree.
As a result of all these years of hardening, these days ffmpeg should be reasonably robust against malicious inputs. Now, if anyone is generating command lines for it and passing anything from user input to that - well, that's an open invitation to abuse.
ß: subjective, of course. But I've tried to look at using the libraries for something fairly straightforward and every single time it's been much more effective use of my time to just look up what the necessary ffmpeg CLI flags+arguments were.
I believe you can use any character your keyboard and/or chosen input method supports. I happen to like ß. From memory alone I've seen people use the +/- symbol, the upright cross, the double-cross and the cross product symbol, just on HN.
I know it certainly was several years ago, and the problem was magnified by every video sharing site using it in their ingestion and transcoding pipelines. It's a single, incredibly powerful and versatile tool, to the point where it's often easier[ß] to fiddle around with command line parameters than to hit the underlying libraries directly.
And by design, in that kind of setup ffmpeg is processing vast quantities of untrusted inputs, coming in at all possible (and some impossible) combinations of video formats, container formats, invalid segment headers, bitstream corruptions and whatever else you can think of. If my memory serves me right, when M. Zalewski first joined Google, he worked on YouTube's video processing ... and to make their engine more robust, started to fuzz ffmpeg. I've heard people describe the result as if shaking a plum tree.
As a result of all these years of hardening, these days ffmpeg should be reasonably robust against malicious inputs. Now, if anyone is generating command lines for it and passing anything from user input to that - well, that's an open invitation to abuse.
ß: subjective, of course. But I've tried to look at using the libraries for something fairly straightforward and every single time it's been much more effective use of my time to just look up what the necessary ffmpeg CLI flags+arguments were.