About chromium packaging
Neal Gompa
ngompa13 at gmail.com
Tue Aug 9 23:35:04 CEST 2016
On Sun, Aug 7, 2016 at 5:56 PM, Kevin Kofler <kevin.kofler at 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!
More information about the rpmfusion-developers
mailing list