I forgot to add this, but I am using the WebM/VP9 codec for encoding.

Same exact problem with the same log messages after the Plasma 6.1 update.
Work for a couple of seconds then a lot of the filter queue messages show up:
```
kpipewire_record_logging: Filter queue is full, dropping frame <frame number>
```

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Memory: 125.7 GiB of RAM
Graphics Processor: AMD Radeon RX 6600

What it means is that for some reason, the system cannot encode fast enough to keep the frames from piling up in memory. When frames start piling up without being dropped, you may quickly run out of memory and have your whole system freeze. The reason why this happens could simply be that your computer is too slow or has too many other things competing for system resources.

(In reply to Noah Davis from comment #3)
> What it means is that for some reason, the system cannot encode fast enough
> to keep the frames from piling up in memory. When frames start piling up
> without being dropped, you may quickly run out of memory and have your whole
> system freeze. The reason why this happens could simply be that your
> computer is too slow or has too many other things competing for system
> resources.

I don't think this is the reason. I tested it on a fresh boot and the same thing occurred. Also it used to work perfectly before.

Here's a recording: https://imgur.com/a/f09s7Cg
It seems even initially it starts at over 1.5 core, then ramps up to over 3 cores and I hear the fan increasing speed.

I am on 12c/24t 128GB DDR4 so the overall system is not starved for resources.

Spectacle is likely impacted by changes upstream as I got spectacle-24.05.0-2 from Fedora repos on 2024-06-08, but my update to Plasma 6.1 was almost 2 weeks later on 2024-06-20.

I use Spectacle almost daily to record small clips of devlogs to share with friends, that is why I noticed instantly.

It is possible for there to be a bug. As you said, this probably is an upstream issue since Spectacle does not do the frame dropping itself. The issue is probably in KWin, KPipeWire or in something that either of those rely on.

(In reply to Noah Davis from comment #6)
> It is possible for there to be a bug. As you said, this probably is an
> upstream issue since Spectacle does not do the frame dropping itself. The
> issue is probably in KWin, KPipeWire or in something that either of those
> rely on.

I did some more testing, and it seems only the libvpx and libvpx-vp9 encoders face this issue.
libx264, h264_vaapi and their baseline profiles seem to work fine.

I think we should perhaps move this to kpipewire, this does not seem like a bug of spectacle.

(In reply to Noah Davis from comment #6)
> It is possible for there to be a bug. As you said, this probably is an
> upstream issue since Spectacle does not do the frame dropping itself. The
> issue is probably in KWin, KPipeWire or in something that either of those
> rely on.

Problems with writing to spectacle began on all distributions that updated Pipewire to a version >= 1.1.80

I can confirm the issue still persists with pipewire 1.2.0

I do not know if this is relevant, but kpipewire always seems to drop frames starting around the 3200th frame number. It also drops every 16th or 17th frame. For example look at this

ideapad spectacle[3957]: kpipewire_record_logging: Filter queue is full, dropping frame 6633
ideapad spectacle[3957]: kpipewire_record_logging: Filter queue is full, dropping frame 6650
ideapad spectacle[3957]: kpipewire_record_logging: Filter queue is full, dropping frame 6666
ideapad spectacle[3957]: kpipewire_record_logging: Filter queue is full, dropping frame 6683
ideapad spectacle[3957]: kpipewire_record_logging: Filter queue is full, dropping frame 6700 

Also please note that this only happens on webm/vp9 codec.

Same problem here in openSUSE Tumbleweed with codecs installed by opi. Using libKPipeWire6 6.1.3-1.1 and pipewire 1.2.1-1.1. I also cannot save video using MP4 and get no error logs, but I think that may not be relevant in this case.

Spectacle Version: 24.08.3
KDE Plasma Version: 6.23
KDE Frameworks Version: 6.8.0
Qtversion: 6.8.0
Kernel Version: 6.11.6-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: Ryzen 5 3600X
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX


WebM  still drops frames after a few seconds when recording with a rectangular frame at 966x721
This results in the following repeated error with kpipewire:

`kpipewire_record_logging: Filter queue is full, dropping frame`

Same here.
Operating System: Gentoo Linux 2.17
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.1
Kernel Version: 6.12.3-20R5-sched-ext (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-10310U CPU @ 1.70GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

Same here. And only with VP9. For me spectacle can record up to ~35 seconds of video. And starts dropping frames immediately.

I think that system has enough power to handle it. i7-12700, 64GB RAM.

```
The cached device pixel ratio value was stale on window update.  Please file a QTBUG which explains how to reproduce.
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so 
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
kpipewire_vaapi_logging: VAAPI: profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: profile 14 is not supported by the device "/dev/dri/renderD128"
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so 
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so 
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
[libvpx-vp9 @ 0x7fd9208b7c80] Application has requested 20 threads. Using a thread count greater than 16 is not recommended.
[libvpx-vp9 @ 0x7fd9208b7c80] v1.15.0
kpipewire_dmabuf_logging: eglChooseConfig returned this many configs: 1
kpipewire_record_logging: Filter queue is full, dropping frame 25217
kpipewire_record_logging: Filter queue is full, dropping frame 25450
kpipewire_record_logging: Filter queue is full, dropping frame 25717
kpipewire_record_logging: Filter queue is full, dropping frame 25734
kpipewire_record_logging: Filter queue is full, dropping frame 25934
kpipewire_record_logging: Filter queue is full, dropping frame 26067
kpipewire_record_logging: Filter queue is full, dropping frame 26217
kpipewire_record_logging: Filter queue is full, dropping frame 26234
```
h.264 works fine.

This was working for me until recently.
Can confirm I have the same issue when using the webm/vp9 codec for screen recording.
h264 is working fine.

Spectacle Version: 24.12.2
KDE Plasma Version: 6.3.0
KDE Frameworks Version: 6.10.0
Qtversion: 6.8.2
Kernel Version: 6.13.2-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors:  i5-1135G7
Memory: 24GB of RAM
Graphics Processor: Intel® Iris® Xe Graphics

kpipewire_vaapi_logging: VAAPI: Intel iHD driver for Intel(R) Gen Graphics - 24.4.4 () in use for device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 6 of profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 8 of profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 6 of profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 8 of profile 14 is not supported by the device "/dev/dri/renderD128"
qt.multimedia.ffmpeg: Using Qt multimedia with FFmpeg version n7.1 GPL version 3 or later
qt.multimedia.ffmpeg: Available HW decoding frameworks:
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
qt.multimedia.ffmpeg:      vaapi
qt.multimedia.ffmpeg:      vulkan
qt.multimedia.ffmpeg: Available HW encoding frameworks:
qt.multimedia.ffmpeg:      vaapi
qt.multimedia.ffmpeg:      vulkan
kpipewire_vaapi_logging: VAAPI: entrypoint 6 of profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 8 of profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 6 of profile 14 is not supported by the device "/dev/dri/renderD128"
kpipewire_vaapi_logging: VAAPI: entrypoint 8 of profile 14 is not supported by the device "/dev/dri/renderD128"
[libvpx-vp9 @ 0x7e8d20468bc0] v1.15.0
kpipewire_dmabuf_logging: eglChooseConfig returned this many configs: 1
kpipewire_record_logging: Filter queue is full, dropping frame 36700
kpipewire_record_logging: Filter queue is full, dropping frame 36717

Quite possibly because of Bug 492844.

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

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

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

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

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/194

Git commit 52911b7060fc3341c4ab4b308be1e47f985e8576 by Arjen Hiemstra.
Committed on 21/03/2025 at 09:44.
Pushed by ahiemstra into branch 'master'.

Change Encoder::applyEncodingPreference() to buildEncodingOptions()

As it turns out, FFmpeg does something to the pointers here that causes
the dictionary to never be properly used. This means we were never
applying the encoding options, as avcodec_open() was passed a nullptr
for options.

Fix this by changing the function to return an AVDictionary* instead of
trying to modify a passed-in pointer. This results in a proper dict
being returned, that can then be passed to avcodec_open().

The main result of this is that we now properly apply the encoding
options for VP9 encoding, which means we can now encode VP9 at realtime
speeds instead of it massively lagging behind.

M  +5    -1    src/encoder.cpp
M  +1    -1    src/encoder_p.h
M  +0    -7    src/gifencoder.cpp
M  +0    -1    src/gifencoder_p.h
M  +5    -5    src/h264vaapiencoder.cpp
M  +1    -1    src/h264vaapiencoder_p.h
M  +5    -5    src/libopenh264encoder.cpp
M  +1    -1    src/libopenh264encoder_p.h
M  +6    -4    src/libvpxencoder.cpp
M  +1    -1    src/libvpxencoder_p.h
M  +6    -4    src/libvpxvp9encoder.cpp
M  +1    -1    src/libvpxvp9encoder_p.h
M  +0    -1    src/libwebpencoder_p.h
M  +6    -5    src/libx264encoder.cpp
M  +1    -1    src/libx264encoder_p.h

https://invent.kde.org/plasma/kpipewire/-/commit/52911b7060fc3341c4ab4b308be1e47f985e8576