Created attachment 185579 [details] Config wizard results SUMMARY Appimage version of Kdenlive does not support Vaapi hardware encoding while Flatpak version does. Trying to render a video using Vaapi encoder results in immediate error (written below.) Running config wizard also says "Hardware encoder unavailable." STEPS TO REPRODUCE 1. Click "check hardware acceleration" in Config Wizard of Appimage version Kdenlive 2. It returns "No hardware encoders found" 3. Try to render a video using Vaapi encoder OBSERVED RESULT Render ends abruptly with following error: " Started render process: /tmp/.mount_kdenlijaClGB/usr/bin/melt -loglevel error -progress2 /tmp/kdenlive-qKesqk-1.mlt [AVHWDeviceContext @ 0x7f9260007600] libva: dlopen of /usr/lib/dri/radeonsi_drv_video.so failed: /usr/lib/dri/radeonsi_drv_video.so: wrong ELF class: ELFCLASS32 [AVHWDeviceContext @ 0x7f9260007600] libva: /usr/lib64/dri/radeonsi_drv_video.so has no function __vaDriverInit_1_0 [AVHWDeviceContext @ 0x7f9260007600] Failed to initialise VAAPI connection: -1 (unknown libva error). [consumer avformat] Failed to initialize VA-API: -5 [av1_vaapi @ 0x7f9260001a00] A hardware frames reference is required to associate the encoding device. Rendering of /media/system/Storage/RenderedVideos/witchfire_introductionav1.mp4 aborted, resulting video will probably be corrupted. " EXPECTED RESULT Hardware acceleration is expected to work as in flatpak version. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Bazzite 42 / KDE Plasma KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.18.0 Qt Version: 6.9.2 ADDITIONAL INFORMATION CPU: Ryzen 5 5600 GPU: AMD RX 7600
Turns out in appimage version, Kdenlive is pointing to an ffmpeg directory that doesn't exist. The directory should be: usr/bin/ffmpeg usr/bin/ffplay usr/bin/ffprobe But it has a garbage value like the following: /tmp/.mount_kdenliDHKFPA/usr/bin/ffmpeg /tmp/.mount_kdenliDHKFPA/usr/bin/ffplay /tmp/.mount_kdenliDHKFPA/usr/bin/ffprobe I simply deleted the garbage value and hardware acceleration is working now. I will share the screenshot as well.
Created attachment 186193 [details] Garbage value for ffmpeg directory causing the issue.
Problem is still present in Appimage Kdenlive: 25.11.70 - rev. f168942
Created attachment 186436 [details] FFmpeg conf for Flatpak
Created attachment 186437 [details] FFmpeg conf for Appimage
Created attachment 186438 [details] FFmpeg conf for Ubuntu 25.10
On the same laptop: - Vaapi is available with Flatpak 25.08.2 - Vaapi is NOT available with Appimage 25.08.2 - Vaapi is NOT available with Appimage 25.08.2 - Vaapi is NOT available with Appimagekdenlive-master-11416-linux-gcc-x86_64.AppImage - Vaapi is NOT available in the version compiled with bb9daeae75eab8fa4157740bc924f0f81c2a4e24 (which uses the system's FFmpeg) I compared the configurations of respective versions of FFmpeg (see file attached). - In the Flatpak configuration, I see `--enable-vaapi`, so it seems logical to have Vaapi available - In the Ubuntu configuration, I see **don't** `--enable-vaapi`, so it seems logical to **not** have Vaapi available - But in the Appimage configuration, I do see `--enable-vaapi`, so it seems that the problem lies somewhere else
(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.
VAAPI support restored with 25.12.0 update. Marking solved.