Distros and QtWebEngine
kevin.kofler at chello.at
Tue Apr 21 17:13:03 BST 2015
Lisandro Damián Nicanor Pérez Meyer wrote:
> Actually when it comes to the web engine it's not true. When I suggested
> directly no, simply because they are too entangled to be possible. And
> ffmpeg tends to be quite a source of CVEs...
Not to mention that we want our web browsers to not use FFmpeg at all (at
least not directly), but GStreamer 1. Sadly, due to how deeply FFmpeg is
entangled into Chromium, this does not look realistic for QtWebEngine. Using
GStreamer would mean that we could ship it only with unencumbered codecs
while still allowing our users to easily add patent-encumbered codecs, the
same codecs would work for all applications, and there would also be an
automated plugin installation mechanism. Chromium's hardcoded use of a
forked FFmpeg breaks all that.
JIT fallback, because the JIT does not work on our secondary architectures.
(For Debian, those are even PRIMARY architectures!) This is even less
realistic in Chromium, because V8 is hardcoded everywhere, and there is no
interest whatsoever in V8 upstream in supporting an interpreter fallback.
This issue means anything that requires QtWebEngine in KDE will NOT be
available on all those platforms, even if we were to package QtWebEngine.
(It would also increase our maintenance workload if we were to package
QtWebEngine, by requiring ExcludeArch or ExclusiveArch lists all over the
More information about the kde-core-devel