https://bugs.kde.org/show_bug.cgi?id=510350
Ron <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |z.net --- Comment #8 from Ron <[email protected]> --- (In reply to Camille from comment #7) > - But in the Appimage configuration, I do see `--enable-vaapi`, so it seems > that the problem lies somewhere else It is 'successfully' enabling it, but it's one of those low-level libraries, like libc, where we build and link with the version provided by the AppImage build environment (partly controlled by the Craft recipe, and partly by the (virtual) machine and OS it is run in), but at runtime we use the one on the system that is running the AppImage, we don't (and probably can't) ship it in the AppImage. So those two version need to be compatible, otherwise we end up with problems like this one, and the one we occasionally have where the new AppImage won't work for users on OS releases with some ancient libc (like this: https://discuss.kde.org/t/kdenlive-23-08-3-x86-64-appimage-not-working-either/7513/6). In the case of libva, for me that looks like this: https://discuss.kde.org/t/appimage-version-does-not-support-vaapi-hardware-acceleration/40377/4 The salient bit being (for Debian Trixie): > So the appimage is expecting to find VA-API version 1.0 (which is what was > used to build it), > while the drivers on my machine are providing version 1.22 (from libva > 2.22.0). The bit I'm not sure about is how we get the 'official' Craft builds to use something that more users are likely to have. libva is probably moving faster than libc, so there may be a bigger spread in what 'current' OS releases are using. -- You are receiving this mail because: You are watching all bug changes.
