chromium is under review on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=chromium On 07/19/2016 02:38 PM, Nicolas Chauvet wrote: -- --- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x6CE6D08A Check on https://keys.fedoraproject.org/

On Tue, Jul 19, 2016 at 2:38 PM, Nicolas Chauvet <kwizart(a)gmail.com&gt; wrote: Well, we don't also accept software that can go to Fedora proper. And if I'm not mistaken Chromium can go directly to Fedora. There even a review request open: https://bugzilla.redhat.com/show_bug.cgi?id=1270322 Bye, Andrea

Nicolas Chauvet wrote: It might not be enough to replace the chromium-ffmpeg, you may need a complete chromium-freeworld rebuild with the enable_proprietary_codecs flag on. There is code in Chromium itself which hardcodes the list of available codecs (which is provided, e.g., to websites querying for supported codecs) depending on that compile-time flag. The GStreamer backend in Samsung's fork currently has the same issue, which pretty much defeats the point of using GStreamer. See also https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 If things like Pepper plugins and Widevine DRM support are not compiled in (as was mentioned elsewhere in this thread), that would be another possible reason for rebuilding the entire package. (For what it's worth, QtWebEngine actually enables support for both of them, there just aren't any blobs shipped – if you want Pepper Flash or the Widevine DRM blob (which is also shipped as a Pepper plugin), you need to get them from Chrome or elsewhere, downloading Chrome being probably the only legal way to get them.) That said, if you're going to install the proprietary Chrome anyway to get those proprietary blobs, why would you even bother with the Chromium package? (It makes more sense for QtWebEngine, which integrates the Chromium/Blink engine into native Qt applications.) It doesn't. Spot's package is a package of upstream Chromium without Samsung's changes. Kevin Kofler

Jeremy Nouhaud wrote: And that comment is incorrect (or at least poorly formulated and incomplete): 1. There is no "ffmpegsumo.so" in his package (nor in any other current Chromium package). That file name was dropped in Chromium 45. Now, FFmpeg is either static, or shared as libffmpeg.so (in a private library directory). spot's package uses the latter (shared libffmpeg.so). 2. I don't see how you would replace the library, given that it is in a private library directory, thus referenced using RPATH. The ld.so.conf.d trick (as in freetype-freeworld) does not work on RPATH'd libraries. Using Conflicts: could work if the library were in a subpackage, but it is currently not. 3. While replacing the library will work if you have a solution to "2.", it will not necessarily do what you want. Websites will not be able to detect that your browser supports patent-encumbered codecs (such as H.264). You have to recompile the entire Chromium with the proprietary_codecs compile-time flag to make that work. Otherwise, the codec can be decoded if it gets sent, but querying for codec availability uses a hardcoded list determined only by that compile-time flag (i.e., one of 2 hardcoded lists, selected by the proprietary_codecs flag). Kevin Kofler

2016-08-07 1:18 GMT+02:00 Kevin Kofler <kevin.kofler(a)chello.at&gt;: libffmpeg.so is not provided anymore in the approved fedora build. So I think there is nothing much to replace, but instead to provide the shared library as a complement. I might have something to share to acheive that, so please ask on #rpmfusion IRC about this, as I don't plan to do much packaging work until the infra is finished. Thx Nicolas (kwizart)

Hi, On 07-08-16 14:03, Kevin Kofler 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. Regards, Hans

On Sun, Aug 7, 2016 at 5:56 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote: 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!

Neal Gompa wrote: Replacing libmedia.so is unfortunately not enough. The USE_PROPRIETARY_CODECS compile-time flag is checked all over the place, even in the application layer. See e.g.: https://chromium.googlesource.com/chromium/src.git/+/master/chrome/common... (QtWebEngine's equivalent has the same at: http://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_client_qt... by the way.) You'll probably find more if you search all .cc files for the string. So either you patch all these usages in the Fedora Chromium package to look up the flag from libmedia at runtime, or there is no way around recompiling the whole Chromium. Kevin Kofler

Hello, According to Tom 'spot' Callaway it's possible to build a chromium- libs-media-freeworld package to make available proprietary codecs to chromium. It will be great if that can be add to RPMFusion ! https://www.reddit.com/r/Fedora/comments/5buozn/how_to_enable_mse_h264_ in_chromium/ https://www.reddit.com/r/Fedora/comments/5buozn/how_to_enable_mse_h264_ in_chromium/d9x3lap/ Thanks !

Well I'm not skilled enough but I'm surprised that nobody in RPMFusion is interested since it looks to be relatively simple. Feel free to maintain the work in RPM Fusion.Thx-- -Nicolas (kwizart)

See the review request: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4363 Note that I'm leaning towards just making a chromium-freeworld instead of this package. Please see the request and leave your feedback there. On Mon, Nov 28, 2016 at 6:24 PM, Jeremy Newton <alexjnewt(a)gmail.com&gt; wrote: