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

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 ?

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.)