https://bugs.kde.org/show_bug.cgi?id=515044
--- Comment #4 from Rodrigo <[email protected]> --- Hi everyone, I would like to provide additional debugging data from Fedora 44 (KDE Plasma 6, Qt 6.10, FFmpeg backend 8.1.2) running on an AMD Ryzen 5 3500U with Radeon Vega 8 Graphics (Raven Ridge). This hardware also lacks silicon-level AV1 decoding support. My report (bug #523042) was marked as a duplicate of this one, and I believe our testing on Fedora can help pin down the root cause of this Qt Multimedia pipeline failure. We performed exhaustive testing trying to force a software decoding fallback (using dav1d/libdav1d, which works flawlessly on the same machine under GStreamer via 'gst-play-1.0'). Here are the results of the workarounds we attempted: 1. Setting Harald's suggested variable: QT_FFMPEG_DECODING_HW_DEVICE_TYPES=, dragon output.mp4 (Result: Playback still fails. The pipeline fails to fall back to CPU decoding and throws "Failed to get pixel format" / "Get current frame error" once hardware paths are stripped). 2. Forcing Qt6 software mode: QT_MULTIMEDIA_FORCE_SOFTWARE=1 dragon output.mp4 (Result: Ignored. The backend still probes VA-API and fails: "[av1] Failed setup for format vaapi: hwaccel initialisation returned error.") 3. Disabling VA-API driver completely: LIBVA_DRIVER_NAME=none dragon output.mp4 (Result: The pipeline falls back to Vulkan, but then crashes immediately due to lack of hardware support: "[av1] Device does not support the VK_KHR_video_decode_queue extension! Failed setup for format vulkan") 4. Trying other Qt AVPlay wrappers: QT_AVPLAY_HWACCEL=none dragon output.mp4 (Result: Ignored. Still attempts VA-API and fails). Conclusion: This confirms Harald's suspicion in Comment 1 and 2. The bug lies deep within the Qt6 Multimedia FFmpeg backend. The pipeline is tightly bound to hardware acceleration formats for AV1 streams. It completely lacks a functional, automatic "software decoding fallback" path. Once all hardware acceleration probes (VA-API, Vulkan) fail, the pipeline terminates abruptly rather than falling back to CPU rendering via libdav1d. Hopefully, this extra testing helps when escalating this issue upstream to the Qt Multimedia/QtProject trackers. -- You are receiving this mail because: You are watching all bug changes.
