On Sun, Aug 7, 2016 at 5:56 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Hans de Goede wrote:
> <sigh> I don't understand why you keep repeating this. I'm sure we can
> come-up with a patch to make the codec-lists a runtime configurable
> thing, this is not rocket science.
If you want to have a try at fixing this, look, e.g., at the member variable
media::MimeUtil::allow_proprietary_codecs_, i.e., the way it is initialized
(to a compile-time hardcoded value) and the way it is used (in several
places).
The right way would really be to remove the boolean variable (which only
allows a binary all-or-nothing approach to patent-encumbered codecs)
entirely and query for each individual codec at runtime. But then, you will
likely be querying FFmpeg directly, whereas for Samsung's GStreamer backend
(which is also affected by this issue, see
https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), one would
have to query GStreamer directly instead. You would also likely be touching
several code places related to codec support.
A less invasive approach would simply try to initialize
media::MimeUtil::allow_proprietary_codecs_ to a runtime-detected value.
Kevin Kofler
You really only need to recompile libmedia.so, which is where the
codec whitelist exists. Both this and the libffmpeg.so library are
provided by the chromium-libs-media package. I'm not sure if it would
work with the system ffmpeg library without a patch, so you may need
to recompile specifically the libmedia.so and libffmpeg.so components
from the Chromium sources into a new chromium-libs-media-freeworld
package.
--
真実はいつも一つ!/ Always, there's only one truth!