2017-06-29 2:30 GMT+02:00 Kevin Kofler <kevin.kofler(a)chello.at>:
Nicolas Chauvet wrote:
> I wonder if it would be relevant for us to rely on the openh264
> repository in our infra ?
> It seems at least that the chromium freeworld flavor rely on a builtin
> version whereas it could use the fedora version, it's a case I wasn't
qt5-qtwebengine-freeworld also uses a bundled openh264. As of 5.9.0, it
cannot even officially be unbundled. They added support for that since, I am
not sure in what release exactly that will ship. It could probably be
… but the main issue I have with building against the openh264 repository is
that this would then introduce a dependency on yet another repository for my
users. I think that in this case, it may make more sense to just keep the
bundled version (also in chromium-media-libs-freeworld, which is in the same
That, or actually ship openh264 in RPM Fusion free. It's not like RPM Fusion
has to care about the patent issues that force that Cisco-hosted repo to
begin with. (RPM Fusion free already ships at least one H.264 decoder (the
builtin decoder in FFmpeg) and at least one H.264 encoder (x264), both of
which support more of the standard than OpenH264, so shipping OpenH264
should not expose RPM Fusion to any additional liabilities.)
would mean importing it into our git and tracking
changes in fedora.
That's an unattractive task for a packager if he's not also
maintaining the package in fedora (and even, that would mean duplicate
Another way would be to automatically enable fedora-cisco-h264 on
rpmfusion-free-release installation ?
Using: dnf config-manager --set-enabled fedora-cisco-openh264 in %post
The question about the need of openh264 in rpmfusion is probably how
the route to either openh264/ffmpeg/x264 is setup in your application:
- If your app route the content that can be decoded by openh264 only
to openh264, then it will expect to always have the library. (and we
will probably need to find a long term solution to avoid bundling).
- If it's smart enough to route content that can be decoded by
openh264 to ffmpeg (if available), then it's a safer path and we will
probably not have to worry about openh264 ourselves.