Proprietary codec availability needs to be detected at runtime

[kkofler]

Currently, the build instructions recommend setting use_proprietary_codecs=1, which always reports those codecs as available. But on Fedora, those codecs are not available out of the box, but only if the plugins are installed from third-party repositories. So there needs to be a runtime check for at least media::MimeUtil::allow_proprietary_codecs_. But ideally, availability needs to be checked for each individual codec.

[kkofler]

(For an example of what can happen if the codecs are incorrectly reported, see: https://bugzilla.redhat.com/show_bug.cgi?id=1248801 – current QtWebKit does not work on YouTube on a stock Fedora installation, because it hardcodes the codec list.)

[CapOM]

You are right, currently if upstream Chromium is built with use_proprietary_codecs=1 and ffmpeg_branding=Chromium then it fails to play Youtube video that wants to use proprietary codec in priority. Indeed Chromium statically reports it can play then fails to decode but does not fallback to non-proprietary codecs. So it should be dynamic in the first place as you suggested.

Chromium should be able to ask at the runtime the media backend if it is supports the requested proprietary codec.

[mariospr]

As @kkofler said in the RH bug linked above, this issue is also present in WebKit since SVN r117207 since WebKit does not use a static list of mimetypes, and does not consider querying the GStreamer registry for that. This issue currently affects Fedora, and is being currently tracked as WK bug 135972.

This, while it makes sense in environments where the GStreamer codecs installation infrastructure is available to be used (which is enabled in WebKit since SVN r147279), might not be an option in other environments such as chromium, which is heavily based in bundled-in libraries.

So, while I doubt upstream chromium will ever accept a change like this one, I'm sharing here a link to the solution we have implemented downstream in Endless, which might be helpful here too: https://bugs.webkit.org/show_bug.cgi?id=135972#c13

[kkofler]

FYI, the WebKit equivalent of this issue has been addressed (http://trac.webkit.org/changeset/201163), but be warned that licensing probably prevents copying&pasting their code (the media/base/mime_util.cc file is BSD-licensed, the WebKit code is LGPL, which is more restrictive).