Lisandro Damián Nicanor Pérez Meyer wrote: > Actually when it comes to the web engine it's not true. When I suggested > to use an external ffmpeg and libv8 (javascript engine) the answer was > 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. We also want our web browsers to support a JavaScript engine that has a non- 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 place.) Kevin Kofler