FFmpeg and a thousand fixes

Re:FFmpeg and a thousand fixes by StavrosK on Friday January 10, 2014 @04:19PM (#7039483)

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.

[ Parent | on HN ]

Re:FFmpeg and a thousand fixes by Perseids on Friday January 10, 2014 @04:25PM (#7039539)

You mean, not many people use VLC?

https://www.videolan.org/developers/vlc.html#thirdparty

[ Parent | on HN ]

Re:FFmpeg and a thousand fixes by Crito on Friday January 10, 2014 @04:34PM (#7039618)

For realtime playback locally sure. I don't think there are many/any public-facing systems backed by VLC. Presumably VLC prioritizes speed over security.

[ Parent | on HN ]

Re:FFmpeg and a thousand fixes by Perseids on Friday January 10, 2014 @04:52PM (#7039755)

Oh, that was the point being made. My view is that VLC essentially is a public facing system, in the same sense that my browser is a public facing system. Sure, it is not as easy to do a targeted attack against my VLC as against my mail client (or against the nginx on my server). But it is fed a lot of untrusted data. The same goes for Chrome, which also uses FFmpeg according to the article.

[ Parent | on HN ]

Re:FFmpeg and a thousand fixes by bane on Friday January 10, 2014 @10:01PM (#7041304)

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

[ Parent | on HN ]