Bug 510350

Summary: VAAPI Hardware Encoding Unavailable on Appimage Version of Kdenlive
Product: [Applications] kdenlive Reporter: Gokhan <bluesadam>
Component: Rendering & ExportAssignee: Jean-Baptiste Mardelle <jb>
Status: RESOLVED FIXED    
Severity: normal CC: bluesadam, camille.moulin, kdenlive-bugs
Priority: NOR    
Version First Reported In: 25.08.1   
Target Milestone: ---   
Platform: Bazzite   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Config wizard results
Garbage value for ffmpeg directory causing the issue.
FFmpeg conf for Flatpak
FFmpeg conf for Appimage
FFmpeg conf for Ubuntu 25.10

Description Gokhan 2025-10-07 16:39:51 UTC
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
Comment 1 Gokhan 2025-10-26 15:58:00 UTC
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.
Comment 2 Gokhan 2025-10-26 15:58:29 UTC
Created attachment 186193 [details]
Garbage value for ffmpeg directory causing the issue.
Comment 3 Camille 2025-11-02 08:34:29 UTC
Problem is still present in Appimage Kdenlive: 25.11.70 - rev. f168942
Comment 4 Camille 2025-11-02 21:19:13 UTC
Created attachment 186436 [details]
FFmpeg conf for Flatpak
Comment 5 Camille 2025-11-02 21:19:35 UTC
Created attachment 186437 [details]
FFmpeg conf for Appimage
Comment 6 Camille 2025-11-02 21:19:58 UTC
Created attachment 186438 [details]
FFmpeg conf for Ubuntu 25.10
Comment 7 Camille 2025-11-02 21:23:06 UTC
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
Comment 8 Ron 2025-11-03 10:18:53 UTC
(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.
Comment 9 Gokhan 2025-12-24 13:18:54 UTC
VAAPI support restored with 25.12.0 update. Marking solved.