Description of problem: QtWebKit appears to always claim to support the H.264 codec, even when there is no actual GStreamer plugin installed for it. See: https://www.youtube.com/html5 for the list of codecs it reports. YouTube then fails to play any video, saying "an error occurred". Version-Release number of selected component (if applicable): qtwebkit-2.3.4-6.fc21.i686 How reproducible: Always Steps to Reproduce: 1. Uninstall gstreamer1-plugins-ugly, gstreamer1-libav and gstreamer1-plugins-bad-freeworld if you had them installed. 2. Start/restart Konqueror (with KWebKitPart). 3. Visit https://www.youtube.com/html5 and see what it reports. 4. Try playing a YouTube video. Actual results: 3. claims H.264 is supported (when it's not, see step 1). 4. fails with "an error occurred". Expected results: 3. should report H.264 as not supported. 4. should play the video in WebM/VP8 format. Additional info: Originally found on F22 by Mustafa Muhammad, see the thread starting at: https://lists.fedoraproject.org/pipermail/kde/2015-July/015270.html KHTML also appears to have this bug (judging from the step 3 output), but YouTube doesn't work in it for other reasons anyway, so I'm not sure it's worth trying to get this fixed there. I can also try to file an upstream bug against QtWebKit, but given how the Qt Project is trying hard to phase out QtWebKit, I'm not sure it'll get much attention there. :-(
Looks like this is a regression in qtwebkit 2.3. Compare this code, from the last version bundled with Qt 4.x (a 2.2.x version, I think): http://code.qt.io/cgit/qt/qt.git/tree/src/3rdparty/webkit/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#n1449 and this code, from the Qt 5 QtWebKit (which is probably what 2.3 also has, I didn't find 2.3 on code.qt.io): http://code.qt.io/cgit/qt/qtwebkit.git/tree/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#n1389 The old code (which was unfortunately for GStreamer 0.10 only, so it may need porting to work right with GStreamer 1) tried hard to find what codecs are actually supported. The new code just returns a hardcoded list.
This is the "fix" in upstream WebKit that caused this regression: https://github.com/WebKit/webkit/commit/bf5f7b96b82afa49f7ac5b1cc8406712f91edfe1 Unfortunately, upstream seems to consider this an "improvement".
See https://bugs.webkit.org/show_bug.cgi?id=86331 for the upstream "bug" that this "improvement" "fixed".
For reference, this is how Firefox does things: https://hg.mozilla.org/mozilla-central/file/888e8026ed60/dom/media/gstreamer/GStreamerFormatHelper.cpp (though that code should not be copied 1:1 – it supports ONLY H.264, they handle WebM separately using their own decoding code and reject anything else).
Could consider a simpler approach, keep the hardcoded codec list minux H.264, and insert a simple runtime check for plugin presence to re-enable it. (this is more fragile, in case there's ever changes in gst H.264 plugins)
Workaround: yum install -y gstreamer1-plugins-ugly gstreamer1-libav gstreamer1-plugins-bad-freeworld i was missing gstreamer1-libav - installing it made rekonq work again.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
There's an upstream bug in WebKit tracking down this issue,, which is probably a better option to link from here than 86331. See https://bugs.webkit.org/show_bug.cgi?id=135972
(In reply to Rex Dieter from comment #5) > Could consider a simpler approach, keep the hardcoded codec list minux > H.264, and insert a simple runtime check for plugin presence to re-enable it. > > (this is more fragile, in case there's ever changes in gst H.264 plugins) There's a patch that does that: https://bugs.webkit.org/show_bug.cgi?id=135972#c13 but it's also not correct, it still reports other codecs such as FLV which are also not available without external plugins. I think we need a complete revert of: http://trac.webkit.org/changeset/117207 but IIRC the enumerating code there was for GStreamer 0.10 and may need porting for GStreamer 1.0.
Yes that patch is useful in the downstream context we are using it where we really only care about the H.264 codec. I posted it just as a code example that might be useful but it was never meant to be upstreamed, at least not in that form. About the revert, I don't think that's a good solution, since it means diverging from upstream in something which has been stated a few times as the right approach, or at least one in the right direction. IMHO, any effort made to fix this properly upstream should go in the line of fixing WK bug 135972 in a proper way, so that it checks the GStreamer registry as it should.
The hardcoded list approach is NOT a good solution for Fedora: * YouTube will prefer H.264 to the Free codecs for some reason, so this means we totally needlessly break YouTube for the people who are NOT willing to install patent-encumbered codecs (not only H.264, but also the AAC audio codec that goes along with it). * Codec auto-installation is not a good solution here because it assumes the codec will be available in the configured repositories to begin with (and also that the user will be willing to install them, see above). Reporting the correct list to begin with should be better. * Codec auto-installation also does not work in QtWebKit, as far as I can tell. It is unfortunate that the HTML 5 API works the way it does. If it required websites to query for a specific MIME type, then we could prompt for auto-installing that MIME type through codec auto-installation. But as it stands now, they want a list and then check whether the codec they want is in the list, which means we have no clue as for what they actually want or support. As the YouTube example shows, it is probably safer to only report what is supported right now. It makes things worse (requires manual codec installation) on sites that require H.264 (and that actually bother checking for it being available – if they just load the H.264 file without asking, the codec auto-installation should actually do the right thing), but it helps a lot for sites that supports multiple formats, where it is crucial that they know what formats are available NOW.
Just to be clear: I never proposed to go for a hardcoded approach *for Fedora*, what I was saying is that there should be a way to have WebKit reporting what codecs are actually available at the moment, regardless of whether it's feasible to use the codecs auto installation feature or not, which I believe would fix the problem in a reasonable way for Fedora too. That said, I know the current situation in WebKit is a hardcoded approach, but that's not what I mean by "fixing this properly upstream". What I meant was having some kind of solution implemented that is neither the original code nor the current hardcoded approach, which I believe is what's being suggested by one Gstreamer developer in the WebKit bug. See: https://bugs.webkit.org/show_bug.cgi?id=135972#c5 https://bugs.webkit.org/show_bug.cgi?id=135972#c6 Anyway, I'm no GStreamer expert so I'll stop rambling. Hope the pointers are useful in some ways for whatever solution gets implemented here.
See also: https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 for the same issue in Chromium-GStreamer. > regardless of whether it's feasible to use the codecs auto installation feature > or not, which I believe would fix the problem in a reasonable way for Fedora > too. It would not be reasonable because it would still require installing the H.264 (and probably AAC) plugin(s) to make YouTube work when they are not actually needed. (It'd just be easier to install the plugins in some cases.)