http://bugzilla.opensuse.org/show_bug.cgi?id=1041794
http://bugzilla.opensuse.org/show_bug.cgi?id=1041794#c7
--- Comment #7 from Jan Engelhardt
Are you saying that this may be fixable in consumers of the library?
That is a reasonable assumption, yes. I know of at least three consumers (namely, mplayer, mpv, and ffplay) which continue to do their job even with ffmpeg-3.3. I do not know much what the browsers are doing, but from what I do remember is that they use dlopen -- and probably version checks and whatnot to alter their behavior. Yes, some research by browser maintainers/developers would be needed here. Something else that pops out between ffmpeg-3.1 and ffmpeg-3.3: @@ -92,9 +92,9 @@ Codecs: - ..V.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 + D.V.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264_cuvid ) In other words, 3.1 did not support H264 *at all*, and 3.3 supports *passthrough of H264 to CUDA hardware*, so maybe the browser is attempting to use that, and then fails due to the lack of NVIDIA hardware. You could install LiveHTTPHeaders for Firefox/Seamonkey and watch the HTTP URLs pass by to see if indeed it downloads the H264 chunk, compared to *only* downloading the WebM/format 43 with ffmpeg-3.1. -- You are receiving this mail because: You are on the CC list for the bug.