How to read mpg4/h264 videos without embedding a decoder

[kelson42]

It should be possible to rely on the decoding library on the OS on both Windows and Linux?!

[mgautierfr]

Probably not a easy situation. It is mostly a packaging situation.
We never explicitly open a decoding library.
Qt is doing it for us and so the question is how Qt is opening such libraries ?

• On native packages (rpm, dep, ...), it depends on how Qt has been packaged by the distribution
• On appimage. The purpose of appimage is to embed most of the thing. Qt is "configured" to search for codec "inside" the appimage.
• On flathub, we don't compile Qt neither. We are using the KDE runtime (https://invent.kde.org/packaging/flatpak-kde-runtime) and https://github.com/flathub/io.qt.qtwebengine.BaseApp. They probably don't package patented codec for the same reason than us. (And no, we cannot use systems libraries)
• On windows, we use the Qt installed by AppVeyor in its image. So probably the same issue.

[kelson42]

On native packages (rpm, dep, ...), it depends on how Qt has been packaged by the distribution

Therefore not our responsibility. Considering that Debian seems to have the proper codec natively, I guess it could/should be readable everywhere.

• On appimage. The purpose of appimage is to embed most of the thing. Qt is "configured" to search for codec "inside" the appimage.

I see a double constraint which could be impossible to fix. As long as we don't distribute a lot of appimage, that should be OK.

On flathub, we don't compile Qt neither. We are using the KDE runtime (https://invent.kde.org/packaging/flatpak-kde-runtime) and https://github.com/flathub/io.qt.qtwebengine.BaseApp. They probably don't package patented codec for the same reason than us. (And no, we cannot use systems libraries)

Here, we have anyway no control. But we can encourage Linux users to use proper packages if it is proven to be a problem.

• On windows, we use the Qt installed by AppVeyor in its image. So probably the same issue.

This is THE real problem and the priority to clarify IMO

[kelson42]

Should wo

• On windows, we use the Qt installed by AppVeyor in its image. So probably the same issue.

This is THE real problem and the priority to clarify IMO

We should get out of Appveyor anyway and it should be OK with Qt6.5+, see https://wiki.qt.io/QtWebEngine/VideoAcceleration#Qt_WebEngine

[kelson42]

Blocked by #1033

[kelson42]

@adamlamar Do you have the opportunity to test against Qt 6.5? On Windows?

[adamlamar]

I can try the Qt 6.5 upgrade on Linux pretty easily. Last time I was never able to get a local Windows development environment working and had to rely on the Appveyor build. I could try upgrading Appveyor but might be a few weeks before I can get to it.

[kelson42]

@adamlamar We are moving to a Github windows runnner, so please don't waste your time with Appveyor.

[adamlamar]

I finally got Qt6.5 compiled from source on Ubuntu 22.04. kiwix-desktop compiles and seems to work fine, although I must be missing compile-time options or optional libraries because the browser window doesn't load images amongst other style problems.

Distribution-compiled Qt6:

My custom Qt6.5:

I read that Ubuntu 24.04 will include Qt6.4 so it may be a while before Qt6.5 is available in most Linux distributions.

The next step will be to try out on Windows.

[kelson42]

@adamlamar Strage, with Qt6.2.4 it works fine on my Ubuntu 22.04... But not sure exactly where this Bitcoin wiki ZIM file comes from. The key point of this ticket is that we should be able on Windows to read mp4 (for example https://dev.library.kiwix.org/#lang=&q=mp4) without embedding the decoding library (so should rely on Windows decoding capacity).

[kelson42]

Considering that we have achieve to reach all our objectives with webm/vp9 I don't think this is a priority anymore and will close this issue,

[kelson42]

I have to reopen the issue because this issue impacts Zimit.

[kelson42]

Finally reclosing in favour of #1276 which is more specifoc about the need... but both issues are linked anyway.