Bug 512429

Created attachment 187030 [details]
Empty file

Created attachment 187031 [details]
Empty file

I have the exact same issue.

Spectacle version (RPM): 6.5.3
NVIDIA driver version (RPM): akmod-nvidia-3:580.105.08-1.fc43.x86_64 (rpmfusion-nonfree-nvidia-driver)
Distribution: Fedora 43 (x86_64)

Findings:
- When using MP4: File size is always 261 bytes, every recording has the same sha1sum (so they have the same contents). See attachment "spectacle_mp4.mp4".
- When using WEBM: File size is always 423 bytes, multiple recordings do *not* have the same file contents. See attachments "spectacle_webm_1.webm" and "spectacle_webm_2.webm".

I see that rob's comment mentions the NVDEC driver. I assume he is using an NVIDIA GPU too?

(I am new to this place for reporting bugs. If you would like to, please let me know if I can improve something.)

Created attachment 187240 [details]
MP4 file

Created attachment 187241 [details]
WEBM file 1

Created attachment 187242 [details]
WEBM file 2

Created attachment 187243 [details]
Spectacle logs

I ran this command to get the logs of spectacle (after killing the `spectacle --dbus` process):
`spectacle --record r 2>&1 | tee spectacle_stdout_stderr_combined.log`

Same problem here, though I am on Fedora 42. Screen recordings result in near empty files, and .webm result in 422B files.

Created attachment 187260 [details]
broken file

Came to report the same issue after pinning it down to ElFarto's vaapi driver. Uninstalling that fixed this. 

This broke for me with recent KDE updates and that codec is meant to be a decoder only not involved in encoding, so I am fairly sure the bug is in spectacle/KDE. Linked bug appears to be a dupe of this one.

*** Bug 512780 has been marked as a duplicate of this bug. ***

Installing gstreamer1-vaapi resolved the issue for me.
`sudo dnf install gstreamer1-vaapi`

(In reply to Sander from comment #12)
> Installing gstreamer1-vaapi resolved the issue for me.
> `sudo dnf install gstreamer1-vaapi`

This fixed it for me on my laptop (AMD CPU with integrated graphics + NVIDIA GPU).
It did not fix it for me on my PC (only using NVIDIA GPU).
My bad.

One of these should do it (idk what the package is called on your distro, if fedora, I think the first one)

sudo dnf remove libva-nvidia-driver
sudo dnf remove nvidia-vaapi-driver

This will remove hardware video decoding system-wide though, so ...

Installing gstreamer-vaapi on arch didn't resolve the issue.

(In reply to Arimil from comment #15)
> Installing gstreamer-vaapi on arch didn't resolve the issue.

That is not the right package name, see above.

(In reply to Arimil from comment #15)
> Installing gstreamer-vaapi on arch didn't resolve the issue.

Sorry: Also, as well as referring to the correct package, you need to remove it, not install it. That is why it removes the video decoding from everything.

(In reply to pallaswept from comment #17)
> (In reply to Arimil from comment #15)
> > Installing gstreamer-vaapi on arch didn't resolve the issue.
> 
> Sorry: Also, as well as referring to the correct package, you need to remove
> it, not install it. That is why it removes the video decoding from
> everything.

It wasn't even installed for me to begin with, so odd that this fixes it on Fedora.

(In reply to Arimil from comment #18)
> It wasn't even installed for me to begin with, so odd that this fixes it on Fedora.

Then your bug is not this one, because this one requires that driver:

kpipewire_vaapi_logging: VAAPI: VA-API NVDEC driver [direct backend] in use for device "/dev/dri/renderD128"

(see top of this thread)

(In reply to pallaswept from comment #19)
> (In reply to Arimil from comment #18)
> > It wasn't even installed for me to begin with

I just saw this in your other bug marked as a dupe:

Nov 29 21:52:31 camelot spectacle[134701]: VAAPI: VA-API NVDEC driver [direct backend] in use for device "/dev/dri/renderD128"

So you do have it installed on that machine, and that bug report is a dupe of this one, and removing it will resolve the problem we see here, by using CPU encoding with ffmpeg rather than the vaapi encoder.

To hazard a guess why it had an effect o nthat other system, perhaps installing the other vaapi driver caused it to use that one and not this one. But spectacle shouldn't use this one anyway because it is not an encoder.

(In reply to pallaswept from comment #20)
> (In reply to pallaswept from comment #19)
> > (In reply to Arimil from comment #18)
> > > It wasn't even installed for me to begin with
> 
> I just saw this in your other bug marked as a dupe:
> 
> Nov 29 21:52:31 camelot spectacle[134701]: VAAPI: VA-API NVDEC driver
> [direct backend] in use for device "/dev/dri/renderD128"
> 
> So you do have it installed on that machine, and that bug report is a dupe
> of this one, and removing it will resolve the problem we see here, by using
> CPU encoding with ffmpeg rather than the vaapi encoder.
> 
> To hazard a guess why it had an effect o nthat other system, perhaps
> installing the other vaapi driver caused it to use that one and not this
> one. But spectacle shouldn't use this one anyway because it is not an
> encoder.

Both of these are true, gstreamer-vaapi package is not installed, in fact it is not even shipped in the main Arch repos, it's in extra. And yes that error is the one that shows up in journal. I do not have a single package installed with vaapi in it's package name.

On arch it is called libva-nvidia-driver

Yep I do have extra/libva-nvidia-driver installed.

(In reply to pallaswept from comment #22)
> On arch it is called libva-nvidia-driver

Uninstalling this package fixes it for now on Arch when your unique GPU is NVIDIA.

Tested the gstreamer vaapi plugins here, had no effect. 

With nvidia-vaapi-driver installed, this workaround is also effective though: 

LIBVA_DRIVER_NAME="" spectacle

Seems almost certain that spectacle is using this decoder as an encoder by mistake.

Created attachment 187316 [details]
attachment-1106389-0.html

Removing/disabling vaapi for me actually makes spectacle stop showing the
recording feature at all, I tried setting LIBVA_DRIVER_NAME=radeonsi to see
if it would use my iGPU, but that is not the case.

On Tue, Dec 2, 2025 at 4:58 PM pallaswept <bugzilla_noreply@kde.org> wrote:

> *Comment # 25 <https://bugs.kde.org/show_bug.cgi?id=512429#c25> on bug
> 512429 <https://bugs.kde.org/show_bug.cgi?id=512429> from pallaswept
> <pallaswept@proton.me> *
>
> Tested the gstreamer vaapi plugins here, had no effect.
>
> With nvidia-vaapi-driver installed, this workaround is also effective though:
>
> LIBVA_DRIVER_NAME="" spectacle
>
> Seems almost certain that spectacle is using this decoder as an encoder by
> mistake.
>
> ------------------------------
> You are receiving this mail because:
>
>    - You are on the CC list for the bug.
>
>

Same issue here (Nvidia GPU)

I have the same problem in ALT Linux. I removed the nvidia-vaapi-driver.

with nvidia-vaapi-driver

>mp4
~ ❯ spectacle 
QThreadStorage: entry 2 destroyed before end of thread 0x55c4b60d51e0
QThreadStorage: entry 1 destroyed before end of thread 0x55c4b60d51e0

> webm
~ ❯ spectacle
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
kpipewire_vaapi_logging: VAAPI: VA-API NVDEC driver [direct backend] in use for device "/dev/dri/renderD128"
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
[libvpx-vp9 @ 0x7f7c14667f00] v1.15.2
qt.multimedia.ffmpeg: Using Qt multimedia with FFmpeg version 7.1.1-alt4 GPL version 3 or later
[matroska,webm @ 0x7f7c6c002000] Duplicate element
[matroska,webm @ 0x7f7c6c002000] 0x00 at pos 100 (0x64) invalid as first byte of an EBML number
[matroska,webm @ 0x7f7c6c002000] Duplicate element
[matroska,webm @ 0x7f7c6c002000] 0x00 at pos 167 (0xa7) invalid as first byte of an EBML number
[matroska,webm @ 0x7f7c6c002000] Element at 0x5d ending at 0x1aec0100000066 exceeds containing master element ending at 0x1409
qt.multimedia.ffmpeg.mediadataholder: Could not open media. FFmpeg error description: End of file

I think the problem is related to the nvidia-vaapi-driver.

Since Spectacle 6.4.6 doesn't work with the nvidia-vaapi-driver installed, nor does Spectacle 6.5.3.

https://github.com/elFarto/nvidia-vaapi-driver/issues/415

Confirming that using `LIBVA_DRIVER_NAME=none spectacle` to launch Spectacle fixes screen recording for me (at least for one use). I consider this a HIGH priority issue since a key feature of Spectacle is broken with no obvious error message.

Note that I do NOT have nvidia-vaapi-driver installed. I'm using the proprietary nvidia driver only:

$ modinfo nvidia | grep ^version
version:        590.48.01

(In reply to Mike Leach from comment #31)
> Confirming that using `LIBVA_DRIVER_NAME=none spectacle` to launch Spectacle
> fixes screen recording for me (at least for one use). I consider this a HIGH
> priority issue since a key feature of Spectacle is broken with no obvious
> error message.
> 
> Note that I do NOT have nvidia-vaapi-driver installed. I'm using the
> proprietary nvidia driver only:
> 
> $ modinfo nvidia | grep ^version
> version:        590.48.01
Read above you do have it likely from extra/libva-nvidia-driver.

(In reply to Arimil from comment #32)
> Read above you do have it likely from extra/libva-nvidia-driver.

I do not have extra/libva-nvidia-driver installed either.

If you really don't have that driver installed, then you don't have the same bug that everyone here has. Logs would be very useful. If you run spectacle (without setting the variable which had a positive effect), what does that say? What does the command vainfo give you?

(In reply to pallaswept from comment #34)
> If you really don't have that driver installed, then you don't have the same
> bug that everyone here has. Logs would be very useful. If you run spectacle
> (without setting the variable which had a positive effect), what does that
> say? What does the command vainfo give you?

Interesting, looks like spectacle is using VAAPI via Mesa for my AMD CPU by default. I thought the nvidia driver included VAAPI support but the Arch wiki says otherwise. Here's the logs from a normal (failing) run that produces a broken 422 byte file:

$ spectacle
kpipewire_vaapi_logging: VAAPI: Mesa Gallium driver 25.3.2-arch1.1 for AMD Ryzen 7 9800X3D 8-Core Processor (radeonsi, raphael_mendocino, LLVM 21.1.6, DRM 3.64, 6.18.2-arch2-1) in use for device "/dev/dri/renderD129"
[libvpx-vp9 @ 0x7fdfd8062780] v1.15.2
kf.kio.workers.file: copy() QUrl("file:///tmp/Spectacle.WWMogj/Screencast_20260103_191555.webm") to QUrl("file:///home/USERNAME/Screencasts/Screencast_20260103_191555.webm") mode= -1
qt.multimedia.ffmpeg: Using Qt multimedia with FFmpeg version n8.0.1 GPL version 3 or later
[matroska,webm @ 0x7fe020001ec0] Duplicate element
[matroska,webm @ 0x7fe020001ec0] 0x00 at pos 100 (0x64) invalid as first byte of an EBML number
[matroska,webm @ 0x7fe020001ec0] Duplicate element
[matroska,webm @ 0x7fe020001ec0] 0x00 at pos 167 (0xa7) invalid as first byte of an EBML number
[matroska,webm @ 0x7fe020001ec0] Element at 0x5d ending at 0x1aec0100000066 exceeds containing master element ending at 0x1409
qt.multimedia.ffmpeg.mediadataholder: Could not open media. FFmpeg error description: End of file

Here's the logs from the working command which produces a 217kb file that plays normally:

$ LIBVA_DRIVER_NAME=none spectacle
kpipewire_vaapi_logging: VAAPI: Failed to initialize display
kpipewire_vaapi_logging: VAAPI: Failed to initialize display
kpipewire_vaapi_logging: DRM device not found
[libvpx-vp9 @ 0x7f37cc062a40] v1.15.2
kpipewire_dmabuf_logging: eglChooseConfig returned this many configs: 1
kf.kio.workers.file: copy() QUrl("file:///tmp/Spectacle.HeOtCU/Screencast_20260103_191650.webm") to QUrl("file:///home/USERNAME/Screencasts/Screencast_20260103_191650.webm") mode= -1
qt.multimedia.ffmpeg: Using Qt multimedia with FFmpeg version n8.0.1 GPL version 3 or later
Input #0, matroska,webm, from '/home/USERNAME/Screencasts/Screencast_20260103_191650.webm':
  Metadata:
    ENCODER         : Lavf62.3.100
  Duration: 00:00:03.22, start: 0.022000, bitrate: 552 kb/s
  Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 966x790, SAR 1:1 DAR 483:395, 60 fps, 60 tbr, 1k tbn, start 0.022000
    Metadata:
      DURATION        : 00:00:03.223000000


Happy to make a new issue if that makes sense. Looks like I'm getting ffmpeg errors.

vainfo output:

vainfo
Trying display: wayland
vaInitialize failed with error code -1 (unknown libva error),exit

Yeh it looks like you have a different root cause, but I'm not sure if this is "that's a different problem, file a different bug" or "that's a different root cause, but spectacle should fall back to a working (software) encoder anyway, so it's the same fix, don't file a different bug". I'll leave it to some spectacle expert to decide.

It might just be neither. The results from vainfo suggest that maybe you don't have a bug, but just a configuration problem. Either way, I'll wait for a spectacle expert to decide :)

Thanks for sharing the logs, I think they're interesting. Will be even more interesting once a dev sheds some light on this for us :)

Same issue here for NVIDIA,

it's fixed when the UEFI display mode is set to Dynamic (OS is working on integrated GPU):

Operating System: Fedora Linux 43

KDE Plasma Version: 6.5.5

KDE Frameworks Version: 6.22.0

Qt Version: 6.10.1

Kernel Version: 6.18.5-200.fc43.x86_64 (64-bit)

Graphics Platform: Wayland

Hardware - Asus ROG Strix G18 G834JZR

CPU: 32 × Intel® Core™ i9-14900HX

GPU 1: Intel® Graphics (integrated)

GPU 2: NVIDIA GeForce RTX 4080 Laptop GPU

I have this problem too on OpenSUSE Tumbleweed, with nvidia-vaapi-driver. However for me `LIBVA_DRIVER_NAME="" spectacle` just makes Spectacle crash as soon as it tries to record video:
libva info: VA-API version 1.23.0
libva info: User environment variable requested driver ''
libva info: Trying to open /usr/lib64/dri/_drv_video.so
libva info: va_openDriver() returns -1
kpipewire_vaapi_logging: VAAPI: Failed to initialize display
kpipewire_vaapi_logging: DRM device not found