Re: Using openh264 repository by default in RPM Fusion
On 06/29/2017 01:48 AM, Nicolas Chauvet wrote:
As a consequence , the problem remains for kodi, if libdvdcss cannot
be required from the repos. Kodi needs to be patched to dlopen it.
Or maybe using libdvdcss-devel would be enought for kodi to dlopen but
not link ?
Kodi uses its own upstream for libdvd{read,nav,css}. They are *not* ABI compatible
with the standard libraries so you cannot switch to dlopen() calls. If you wanted to
carry their non-standard sources and package them I could possibly switch to dlopen
then.
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
Nicolas Chauvet wrote: > 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. Chromium (and therefore also QtWebEngine) uses OpenH264 (currently a bundled copy, which is why repoquery does not turn up any dependencies on the shared library for you) for encoding in WebRTC. Chromium does not use x264 at all, it uses FFmpeg for decoding and OpenH264 for encoding. (There is also no support for using only OpenH264, decoding always uses FFmpeg.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
2017-06-29 2:30 GMT+02:00 Kevin Kofler : > 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 >> aware. > > 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 > backported, … > > … 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 > situation). > > 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.) Shipping openh264 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 work). 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. Thx -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
2017-06-27 18:28 GMT+02:00 Sérgio Basto : > > IIRC , we agree in this kind of solution for libdvdcss , and at least > kodi need it . Yes it would be the same problem for libdvdcss as openh264 in fedora. Packages can build with it, but cannot require it. At least dnf repoquery --whatrequires libopenh264.so.1\* doesn't show anything, despite chromium seems to be built with openh264 support. So this means the library is probably dlopen at runtime. As a consequence , the problem remains for kodi, if libdvdcss cannot be required from the repos. Kodi needs to be patched to dlopen it. Or maybe using libdvdcss-devel would be enought for kodi to dlopen but not link ? From my side, I'm okay to import libdvdcss into the free git , but only provide the package into a dedicated repo (same as openh264). As soon as none requires it at runtime, it should be enough. -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
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 > aware. 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 backported, … … 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 situation). 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.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
IIRC , we agree in this kind of solution for libdvdcss , and at least kodi need it . On Tue, 2017-06-27 at 18:03 +0200, Nicolas Chauvet wrote: > Hello, > > 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 > aware. > BTW, if you are interesed in chromium with all codecs, please have a > look at this: > https://bugzilla.rpmfusion.org/show_bug.cgi?id=4363#c31 > > Is there any others users on openh264-devel in RPM Fusion ? > Is there any issue if the build has openh264 enabled, but the fedora > repo isn't ? > > Thx > -- Sérgio M. B. ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Using openh264 repository by default in RPM Fusion
Hello, 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 aware. BTW, if you are interesed in chromium with all codecs, please have a look at this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4363#c31 Is there any others users on openh264-devel in RPM Fusion ? Is there any issue if the build has openh264 enabled, but the fedora repo isn't ? Thx -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
