Bug 512429 - Screen recording not working
Summary: Screen recording not working
Status: REPORTED
Alias: None
Product: Spectacle
Classification: Applications
Component: General (other bugs)
Version First Reported In: 6.5.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Noah Davis
URL:
Keywords:
: 512780 (view as bug list)
Depends on:
Blocks:
 
Reported: 2025-11-21 10:47 UTC by rob
Modified: 2025-12-14 13:25 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Empty file (422 bytes, video/webm)
2025-11-21 11:21 UTC, rob
Details
Empty file (261 bytes, video/mp4)
2025-11-21 11:21 UTC, rob
Details
MP4 file (261 bytes, application/octet-stream)
2025-11-29 10:03 UTC, Sander
Details
WEBM file 1 (423 bytes, application/octet-stream)
2025-11-29 10:04 UTC, Sander
Details
WEBM file 2 (423 bytes, application/octet-stream)
2025-11-29 10:04 UTC, Sander
Details
Spectacle logs (3.12 KB, text/x-log)
2025-11-29 10:07 UTC, Sander
Details
broken file (422 bytes, video/webm)
2025-11-30 05:30 UTC, pkw.nife
Details
attachment-1106389-0.html (1.58 KB, text/html)
2025-12-02 23:27 UTC, Arimil
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rob 2025-11-21 10:47:55 UTC
Not working screen recording in both formats mp4 and webm. Spectacle.
A file is created that cannot be played - it is empty.


 spectacle
kpipewire_vaapi_logging: VAAPI: VA-API NVDEC driver [direct backend] in use for device "/dev/dri/renderD128"
[libvpx-vp9 @ 0x7f51e4062300] v1.15.2
kf.kio.workers.file: copy() QUrl("file:///tmp/Spectacle.gODaYl/Запись экрана_20251121_133844.webm") to QUrl("file:///home/robert/Видео/Записи экрана/Запись экрана_20251121_133844.webm") mode= -1




pipewire_vaapi_logging: VAAPI: VA-API NVDEC driver [direct backend] in use for device "/dev/dri/renderD128"
[in @ 0x7f0ffc052ec0] Setting BufferSourceContext.pix_fmt to a HW format requires hw_frames_ctx to be non-NULL!
kpipewire_record_logging: Failed to create the buffer filter
[libx264 @ 0x7f0ffc063080] -qscale is ignored, -crf is recommended.
[libx264 @ 0x7f0ffc063080] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512
[libx264 @ 0x7f0ffc063080] profile Main, level 5.2, 4:2:0, 8-bit
kf.kio.workers.file: copy() QUrl("file:///tmp/Spectacle.LrLyQu/Запись экрана_20251121_133104.mp4") to QUrl("file:///home/robert/Видео/Записи экрана/Запись экрана_20251121_133104.mp4") mode=
Comment 1 rob 2025-11-21 11:21:28 UTC
Created attachment 187030 [details]
Empty file
Comment 2 rob 2025-11-21 11:21:54 UTC
Created attachment 187031 [details]
Empty file
Comment 3 Sander 2025-11-29 10:02:31 UTC
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.)
Comment 4 Sander 2025-11-29 10:03:52 UTC
Created attachment 187240 [details]
MP4 file
Comment 5 Sander 2025-11-29 10:04:29 UTC
Created attachment 187241 [details]
WEBM file 1
Comment 6 Sander 2025-11-29 10:04:48 UTC
Created attachment 187242 [details]
WEBM file 2
Comment 7 Sander 2025-11-29 10:07:09 UTC
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`
Comment 8 pkw.nife 2025-11-30 05:26:25 UTC
Same problem here, though I am on Fedora 42. Screen recordings result in near empty files, and .webm result in 422B files.
Comment 9 pkw.nife 2025-11-30 05:30:57 UTC
Created attachment 187260 [details]
broken file
Comment 10 pallaswept 2025-12-01 00:41:03 UTC
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.
Comment 11 Arimil 2025-12-01 02:23:02 UTC
*** Bug 512780 has been marked as a duplicate of this bug. ***
Comment 12 Sander 2025-12-02 11:12:43 UTC
Installing gstreamer1-vaapi resolved the issue for me.
`sudo dnf install gstreamer1-vaapi`
Comment 13 Sander 2025-12-02 18:46:24 UTC
(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.
Comment 14 pallaswept 2025-12-02 19:08:18 UTC
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 ...
Comment 15 Arimil 2025-12-02 21:08:55 UTC
Installing gstreamer-vaapi on arch didn't resolve the issue.
Comment 16 pallaswept 2025-12-02 21:10:33 UTC
(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.
Comment 17 pallaswept 2025-12-02 21:12:27 UTC
(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.
Comment 18 Arimil 2025-12-02 21:13:36 UTC
(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.
Comment 19 pallaswept 2025-12-02 21:16:01 UTC
(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)
Comment 20 pallaswept 2025-12-02 21:19:18 UTC
(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.
Comment 21 Arimil 2025-12-02 21:28:07 UTC
(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.
Comment 22 pallaswept 2025-12-02 21:29:28 UTC
On arch it is called libva-nvidia-driver
Comment 23 Arimil 2025-12-02 21:31:07 UTC
Yep I do have extra/libva-nvidia-driver installed.
Comment 24 DrQwertySilence 2025-12-02 21:51:21 UTC
(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.
Comment 25 pallaswept 2025-12-02 21:57:59 UTC
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.
Comment 26 Arimil 2025-12-02 23:27:28 UTC
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.
>
>
Comment 27 diggsey 2025-12-13 23:14:19 UTC
Same issue here (Nvidia GPU)
Comment 28 Aleksandr Shamaraev 2025-12-14 13:15:28 UTC
I have the same problem in ALT Linux. I removed the nvidia-vaapi-driver.
Comment 29 Aleksandr Shamaraev 2025-12-14 13:25:45 UTC
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