Originally posted by DrYak
View Post
Announcement
Collapse
No announcement yet.
FFmpeg's VP9 Decoder Is Much Faster Thanks To GSoC 2017
Collapse
X
-
Originally posted by Gusar View PostOpenH264 is used *exclusively* for WebRTC. It's not used for HTML5 video. It can't be even if you wanted to, because it only supports baseline profile, while pretty much all h264 video on web pages is main or high profile.
Firefox uses h264 decoders provided by the platform for HTML5 video, on Linux ffmpeg is used.
A lot of people forget that even free/libre/open source software may be bound by patent licensing – it's totally separate from software licensing.
And to those who thought Europe was free of software patents, think again: http://www.hevcadvance.com/pdfnew/HE...ist_170906.pdf
Originally posted by DrYakH265 being a giant clusterfuck of a patent minefield
H.264 was an outrageous disaster, if anyone remembers.Last edited by andreano; 09 September 2017, 03:15 PM.
Comment
-
Originally posted by andreano View PostUgh. I thought the licensing problem was sort of solved for H264 – OpenH264 is paid by Cisco, but who pays for ffmpeg?
Originally posted by andreano View PostAnd that's just the video decoder, what about AAC?
Comment
-
Originally posted by sdack View PostThe people who developed the Adobe Flash Player must have been thinking the same.- a couple of extra SIMD instructions (which lack "scatter" functionnality, they can't write at arbitrary location, the surface attacks of this new VP9 code is rather low),
- and what is basically an Inner platform (and a proprietary, closed source one)
When was the last time you heard of a remote exploit attacking one of the codecs of ffmpeg ?
Comment
-
Originally posted by DrYak View PostThere's a slight difference between:- a couple of extra SIMD instructions (which lack "scatter" functionnality, they can't write at arbitrary location, the surface attacks of this new VP9 code is rather low),
- and what is basically an Inner platform (and a proprietary, closed source one)
When was the last time you heard of a remote exploit attacking one of the codecs of ffmpeg ?
Comment
-
Originally posted by sdack View PostThat's just another fallacy. The low-level code is always a target. It's common for low-level optimizations to cut as many corners as possible in order to achieve maximum performance. This includes the disregard for any security
AVX instrucrion (before the 512 variant introduced on Xeon Phi accelerator) are *TECHNICALLY UNABLE* to write to arbitrary location.
You cannot smash a stack with AVX isntructions, you cannot overrun a buffer with AVX instruction.
(Just the same way you can't pose a security risk by calling a "cos" function on the FPU).
They can only do the math to fill the buffer.
Thus FFmpeg with these new AVX instruction is just as much secure/insecure as it was before the addition of these instructions.
Doing fuzzing IS actually a good idea to try to find bugs (which is possible on other parts of the code, those who handle the various buffers and decode the containers).
But the probability that fuzzing will find any new invulnerability after the new AVX accelerated code mentioned in the article is *extremely low*.
But yeah, go run Redox OS as your prefered daily driver if it gives you warm feelings. I won't prevent you, every one is free to do what they want.
Comment
-
Originally posted by DrYak View Post...
But yeah, go run Redox OS as your prefered daily driver if it gives you warm feelings. I won't prevent you, every one is free to do what they want.
Comment
-
Originally posted by sdack View Postbecause I've made a joke out of your statement of "I don't expect much critical bugs to be discovered in a video codec"
(or a *math formula* to an *inner platform* as I've mentioned above).
Also because (due to their usage and structure) codecs tend to be really robust and have not a very large attack surface, even more so FFmpeg.
Also because corrupted media and dropped packets is something that happens way more frequently than black hat attackers trying to "exploit" FFmpeg, and thus the robustness of ffmpeg is well tested in its everyday setting, way before you need to start worrying about exploits.
Also because "data-moshing" exists as an art form, and it works because intentionally corrupting media doesn't produce crashes, but corrupted video results, which is a pretty good demonstration that suits like ffmpeg are resilient to corruption (again, not due to magical pixie dust. It's just the way these are designed which happen to make them a lot less likely to crash).
(again, where are the tons of ffmpeg remote exploit littering the web ?)
Your joke is as much valid as if you said "The engineers who built the Challenger shuttle must have been thinking the same.".
You must at least try to have something remotely look coherent if you want your audience to suspend their disbelieve enough to laugh at your joke - otherwise you just look as someone who's giving dishonest / disingenuous critics.
Comment
Comment