Neal Gompa wrote: > My biggest concern among all the choices is the multimedia support. > Fedora cannot ship a full-featured codec stack in any of its spins due > to various legal issues. How do the browsers compare for the Fedora > user who wants to get more codec support himself? Both Chromium and QtWebEngine really need rebuilding to pick up not only an FFmpeg with all the codecs, but also the Chromium "proprietary_codecs" build flag that affects the hardcoded list of supported codecs. (Without the flag, it uses a short hardcoded list of unencumbered codecs, with the flag, it uses a longer hardcoded list that also contains patent-encumbered ones. The decision should really be made at runtime and per codec, but that's not how things work at this time.) There is a Chromium GStreamer backend by Samsung, but it is a quite invasive patch that is not packaged for Fedora at this time, neither in Chromium nor in QtWebEngine. As I wrote in the QupZilla thread: | I had hoped to get GStreamer support working, but that is more work to get | going, I need changes in GStreamer packaging that have not been applied | yet, and a fix for the aforementioned compile-time hardcoding (which also | affects the GStreamer backend, see | https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), and then | also testing with QtWebEngine (the GStreamer code was only ever tested | with vanilla Chromium). So this is something for the future. For now, a | rebuild of QtWebEngine with an uncensored FFmpeg in a third-party | repository is the best that can be done. But Chromium and QtWebEngine are in the same situation there, both rely on a bundled FFmpeg. And at the application level, as Christian Dersch pointed out, QupZilla has a slight advantage because you can override the QtWebEngine library without touching the QupZilla application. Kevin Kofler _______________________________________________ kde mailing list kde@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/kde@xxxxxxxxxxxxxxxxxxxxxxx
