Bugzilla – Bug 1041794
ffmpeg 3.3 enablement of h264_cuvid causes browsers not to select webm
Last modified: 2022-10-04 15:27:24 UTC
An update around mid May caused some Youtube videos to fail. When this happens, loading the video stops, leaving only the dot going around a circle showing. This happens with Firefox, Seamonkey and Chromium browsers. The videos that fail play OK in Windows. To verify the problem, I tried the videos with a VirtualBox VM or a fresh 42.2 install. The problem videos played. I then cloned the VM and ensured the videos played. I then updated the clone to the latest updates and now the videos fail. The original non-updated VM still continued to play the videos. It appears the problem is related to the type of codec used. For example, videos with the vp9 codec play, but those with avc1.4d400d now fail. Here are 2 links, this one plays OK: https://www.youtube.com/watch?v=Rzqq581Q3Us But this one doesn't: https://www.youtube.com/watch?v=t8tdmaEhMHE Again, this problem occurred recently. Videos that played a few weeks ago now fail.
Seen the same. This appears to be a regression from ffpeg + libs update openSUSE-2017-524 https://lists.opensuse.org/opensuse-updates/2017-04/msg00106.html https://build.opensuse.org/project/show/openSUSE:Maintenance:6675 https://build.opensuse.org/package/rdiff/openSUSE:Leap:42.2:Update/ffmpeg?linkrev=base&rev=3 osc rdiff openSUSE:Leap:42.2:Update/ffmpeg.{6568,6675} Workaround: zypper in --oldpackage ` \ zypper info -t patch --conflicts openSUSE-2017-524 | \ grep " < " | while read NAME C VERSION; do \ rpm --quiet -q --queryformat "%{name}\n" $NAME && echo "${NAME}<${VERSION}"; \ done` I have not checked if this is in the package itself or possibly a binary compatibility problem (e.g. consumers needing to be rebuild)
>But this one doesn't: https://www.youtube.com/watch?v=t8tdmaEhMHE The reason is simple: that picture data is only available in MPEG, and that is understandably not enabled in openSUSE. $ youtube-dl -F https://www.youtube.com/watch?v=t8tdmaEhMHE [youtube] t8tdmaEhMHE: Downloading webpage [youtube] t8tdmaEhMHE: Downloading video info webpage [youtube] t8tdmaEhMHE: Extracting video information [youtube] t8tdmaEhMHE: Downloading MPD manifest [info] Available formats for t8tdmaEhMHE: format code extension resolution note 139 m4a audio only DASH audio 48k , m4a_dash container, mp4a.40.5@ 48k (22050Hz), 840.29KiB 171 webm audio only DASH audio 63k , 1fps, vorbis@128k, 1.01MiB 140 m4a audio only DASH audio 97k , m4a_dash container, mp4a.40.2@128k (44100Hz), 1.64MiB 160 mp4 192x144 DASH video 110k , avc1.4d400c, 12fps, video only, 1.85MiB 133 mp4 320x240 DASH video 247k , avc1.4d400d, 24fps, video only, 4.14MiB 17 3gp 176x144 small , mp4v.20.3, mp4a.40.2@ 24k 36 3gp 320x240 small , mp4v.20.3, mp4a.40.2 18 mp4 320x240 medium , avc1.42001E, mp4a.40.2@ 96k 43 webm 640x360 medium , vp8.0, vorbis@128k (best)
Ah dang, there is format 43, and it plays (youtube-dl + ffplay). Not sure why firefox won't select #43… maybe the youtube HTML site only goes to look for DASH-based formats these days?
It's not just Firefox. It's also Chromium and Seamonkey. Now, as I have said, this is a recent problem caused by an update. It is not fixed, until that update is fixed or backed out.
(In reply to Jan Engelhardt from comment #2) > >But this one doesn't: https://www.youtube.com/watch?v=t8tdmaEhMHE > > The reason is simple: that picture data is only available in MPEG, and that > is understandably not enabled in openSUSE. > [...] > 43 webm 640x360 medium , vp8.0, vorbis@128k (best) (In reply to Jan Engelhardt from comment #3) > Not sure why firefox won't select #43 Are you saying that this may be fixable in consumers of the library?
(In reply to James Knott from comment #4) > Now, as I have said, this is a recent problem caused by an update. It is > not fixed, until that update is fixed or backed out. This does not usually need clarification, but our bugzilla tracks software issues, not helpdesk tickets. The volunteer community developer has acknowledged that the problem does in deed exists, but decided that he will not fix it as such: (WONTFIX, not INVALID or FIXED.) So we have to take it at face value for now. Maintenance can look if there is an alternative route that may be taken, or maybe the Mozilla / Chromium maintainers have an idea?
>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 could install LiveHTTPHeaders for Firefox/Seamonkey" That means nothing to me. Also, this occurs on my desktop computer and ThinkPad, in addition to the VirtualBox VM. I dont't think there's NVidia hardware anywhere. What update happened recently that might have caused this? If I knew, I'd be able to back it out. As I mentioned, it happened about 2 - 3 weeks ago.
For reference, the mailing list thread: https://lists.opensuse.org/opensuse/2017-05/msg00633.html
(In reply to James Knott from comment #8) > Also, this occurs on my desktop computer and ThinkPad, in addition to the > VirtualBox VM. I dont't think there's NVidia hardware anywhere. Comment #7 noted the possibility if an incorrect inication of H264 support, while this would only actually work on NVidia. > What update happened recently that might have caused this? If I knew, I'd > be able to back it out. As I mentioned, it happened about 2 - 3 weeks ago. See comment #2 where this is explained in great detail.
If this is indeed caused by cuda, which is enabled in the ffmpeg build along with another nvidia specific option cuvid both default to autodetect but the build log shows cuda hardware support is included in libavutil. I've built ffmpeg-3.3.1 in home:plater using --disable-cuda and --disable-cuvid. Installed all of it and it does allow firefox to play: https://www.youtube.com/watch?v=t8tdmaEhMHE Of course with this version of ffmpeg installed the downloaded: "One Toke Over The Line - Lawrence Welk - WTF! (1971) - YouTube [360p].mp4" doesn't play due to missing h264 capabilities. I'll submit this to Factory and 42.1 update.
(In reply to Dave Plater from comment #11) > If this is indeed caused by cuda, which is enabled in the ffmpeg build along > with another nvidia specific option cuvid both default to autodetect but the > build log shows cuda hardware support is included in libavutil. Okay, I adjusted the summary to reflect that. > I've built ffmpeg-3.3.1 in home:plater using --disable-cuda and > --disable-cuvid. Installed all of it and it does allow firefox to play: Hmm, what do you think about dual packages to allow users of cuda to optionally use this feasture? > I'll submit this to Factory and 42.1 update. Okay, assigning the bug to you if it is okay. Maintenance for 42._2_ please. :-)
Well but this smells more and more like a browser problem in that they fail to check the practical usability of cuvid decoder (and then falling back to another format).
(In reply to Andreas Stieger from comment #12) > (In reply to Dave Plater from comment #11) > > If this is indeed caused by cuda, which is enabled in the ffmpeg build along > > with another nvidia specific option cuvid both default to autodetect but the > > build log shows cuda hardware support is included in libavutil. > > Okay, I adjusted the summary to reflect that. > > > I've built ffmpeg-3.3.1 in home:plater using --disable-cuda and > > --disable-cuvid. Installed all of it and it does allow firefox to play: > > Hmm, what do you think about dual packages to allow users of cuda to > optionally use this feasture? I think that cuda support can remain in BUILD_ORIG where it won't be likely to cause future problems. It's video card and driver specific. > > > I'll submit this to Factory and 42.1 update. > > Okay, assigning the bug to you if it is okay. Maintenance for 42._2_ please. > :-) Sent sr#500153 to Factory will prepare 42.2 update
(In reply to Jan Engelhardt from comment #13) > Well but this smells more and more like a browser problem in that they fail > to check the practical usability of cuvid decoder (and then falling back to > another format). Your additional codec purge didn't fix the bug. Disabling cuda in the build does. It seems the assumption that the browser attempts to use the cuda codec is correct.
Created mr#500157
This is an autogenerated message for OBS integration: This bug (1041794) was mentioned in https://build.opensuse.org/request/show/500153 Factory / ffmpeg https://build.opensuse.org/request/show/500157 42.2 / ffmpeg
"It seems the assumption that the browser attempts to use the cuda codec is correct." Well, then it's 3 browsers, Firefox, Seamonkey and Chromium.
Processed for maintenance, issue seems solved with this build. Test update packages will appear first in: http://download.opensuse.org/repositories/openSUSE:/Maintenance:/6821/openSUSE_Leap_42.2_Update/ http://download.opensuse.org/update/leap/42.2-test/ Thanks all, closing.
openSUSE-RU-2017:1470-1: An update that has one recommended fix can now be installed. Category: recommended (moderate) Bug References: 1041794 CVE References: Sources used: openSUSE Leap 42.2 (src): ffmpeg-3.3-6.9.1
Created https://trac.ffmpeg.org/ticket/6442#ticket : libavcodec shouldn't advertise hardware specific codecs on systems without such hardware Have also referenced Bug #1039163 which was fixed when the non cuvid libavcodec was installed.
(In reply to Jan Engelhardt from comment #13) > Well but this smells more and more like a browser problem in that they fail > to check the practical usability of cuvid decoder (and then falling back to > another format). It is indeed a browser problem, the cuvid decoder fails if it detects non nv hardware and the browser fails to fall back.
Disabling cuvid also fixed Bug #1039163
openSUSE-SU-2017:2501-1: An update that solves 13 vulnerabilities and has two fixes is now available. Category: security (moderate) Bug References: 1041794,1046211,1049095,1056760,1056761,1056762,1056763,1056765,1056766,1057536,1057537,1057539,1058018,1058019,1058020 CVE References: CVE-2017-11399,CVE-2017-14054,CVE-2017-14055,CVE-2017-14056,CVE-2017-14057,CVE-2017-14058,CVE-2017-14059,CVE-2017-14169,CVE-2017-14170,CVE-2017-14171,CVE-2017-14222,CVE-2017-14223,CVE-2017-14225 Sources used: openSUSE Leap 42.2 (src): ffmpeg-3.3.4-6.16.1, ffmpeg2-2.8.13-25.10.1, lame-3.99.5-2.1, twolame-0.3.13-2.1
This is an autogenerated message for OBS integration: This bug (1041794) was mentioned in https://build.opensuse.org/request/show/623663 15.0+42.3+Backports:SLE-12-SP2 / chromium+codec2+ffmpeg-2+ffmpeg-3+ffmpeg-4+libsodium+libvpx-1_6+zeromq
This is an autogenerated message for OBS integration: This bug (1041794) was mentioned in https://build.opensuse.org/request/show/802662 Factory / ffmpeg-4
*** Bug 1203855 has been marked as a duplicate of this bug. ***