Bug 475894

Created attachment 162887 [details]
print of the system activity showing spectacle eating all ram

I have the same bug, but on Fedora Kinoite, the print was just from 5 seconds of starting spectacle, and it keep growing rapidly 

Operating System: Fedora Linux 39
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.10
Kernel Version: 6.5.6-300.fc39.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700U with Radeon Graphics
Memory: 6,6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 82MF
System Version: IdeaPad 3 15ALC6

Created attachment 162888 [details]
journalctl logs of spectacle

spectacle looks 3.7GB in the video but the display was not responding properly so i suspect it must've been much higher.

https://imgur.com/elt3YU0

Operating System: KDE neon 5.27
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.2.0-36-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx
Memory: 5.7 GiB of RAM
Graphics Processor: AMD Radeon Vega 3 Graphics
Manufacturer: LENOVO
Product Name: 81UT
System Version: Lenovo IdeaPad S145-15API

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

Just letting people know, I'm currently unable to reproduce this bug. My assumption right now is that it's similar to the problem I get when using the wrong encoder settings with a stream, which is that the RAM usage grows rapidly until OOMing if it can't process the incoming frames quickly enough.

I think that this issue should be more commonly encountered on systems with weak CPUs, but that doesn't explain why Viniciusdaros's PC had the problem. I have an AMD Ryzen 7 4800H with Radeon Graphics and 30.8 GiB of RAM. Viniciusdaros has much lower RAM than me, but their CPU is not vastly different in performance (https://www.notebookcheck.net/R7-5700U-vs-R7-4800H_12978_11677.247596.0.html). Based on my observations under normal circumstances, Spectacle's RAM usage should be 200-300 while GPU encoding and 2x that while CPU encoding (depends on the encoder). Under normal circumstances, 6.6 GiB of RAM should be enough to record with Spectacle without OOMing unless the system is already close to running out of RAM.

(In reply to Noah Davis from comment #5)
> Just letting people know, I'm currently unable to reproduce this bug. My
> assumption right now is that it's similar to the problem I get when using
> the wrong encoder settings with a stream, which is that the RAM usage grows
> rapidly until OOMing if it can't process the incoming frames quickly enough.
> 
> I think that this issue should be more commonly encountered on systems with
> weak CPUs, but that doesn't explain why Viniciusdaros's PC had the problem.
> I have an AMD Ryzen 7 4800H with Radeon Graphics and 30.8 GiB of RAM.
> Viniciusdaros has much lower RAM than me, but their CPU is not vastly
> different in performance
> (https://www.notebookcheck.net/R7-5700U-vs-R7-4800H_12978_11677.247596.0.
> html). Based on my observations under normal circumstances, Spectacle's RAM
> usage should be 200-300 while GPU encoding and 2x that while CPU encoding
> (depends on the encoder). Under normal circumstances, 6.6 GiB of RAM should
> be enough to record with Spectacle without OOMing unless the system is
> already close to running out of RAM.

I got the same issue on same hardware on openSUSE Tumbleweed KDE and Fedora 39 KDE, but i recently formatted it again, Fedora 39 with GNOME and default GNOME's recording tool does not suffer of any memory leak. it just keeps recording and recording my screen.

The system is a ThinkPad T14 Gen 2a with 16 × AMD Ryzen 7 PRO 5850U with Radeon Graphics and 48GB of RAM

I am unable to format at the moment, but let me know if virtual machines are good to try to reproduce the issue, and if there is any specific version or parameter to pass so we can get more detaile info.

(In reply to Noah Davis from comment #5)
> Just letting people know, I'm currently unable to reproduce this bug. My
> assumption right now is that it's similar to the problem I get when using
> the wrong encoder settings with a stream, which is that the RAM usage grows
> rapidly until OOMing if it can't process the incoming frames quickly enough.
> 
> I think that this issue should be more commonly encountered on systems with
> weak CPUs, but that doesn't explain why Viniciusdaros's PC had the problem.
> I have an AMD Ryzen 7 4800H with Radeon Graphics and 30.8 GiB of RAM.
> Viniciusdaros has much lower RAM than me, but their CPU is not vastly
> different in performance
> (https://www.notebookcheck.net/R7-5700U-vs-R7-4800H_12978_11677.247596.0.
> html). Based on my observations under normal circumstances, Spectacle's RAM
> usage should be 200-300 while GPU encoding and 2x that while CPU encoding
> (depends on the encoder). Under normal circumstances, 6.6 GiB of RAM should
> be enough to record with Spectacle without OOMing unless the system is
> already close to running out of RAM.

btw, i can't reproduce it since i rebased kinoite to plasma 6

similar issue here, unable to reproduce. 
just installed kde neon testing and **no recording tab** on spectacle.

how do i rebase it to plasma 6? just wait and install a new vm?

Created attachment 163962 [details]
missing recording tab

(In reply to sombriks from comment #8)
> similar issue here, unable to reproduce. 
> just installed kde neon testing and **no recording tab** on spectacle.

Spectacle only does recording on Wayland. If you are on X11, this behavior is expected.

> how do i rebase it to plasma 6? just wait and install a new vm?

Not sure about KDE Neon. If in doubt, you could try Unstable Edition.

Git commit 66774b90e2f346d681f3d27a271ce5ad82b82bf7 by Arjen Hiemstra.
Committed on 18/12/2023 at 12:00.
Pushed by ahiemstra into branch 'master'.

encoding: Track the number of frames in flight

If the encoder cannot keep up, we can run into cases where either the
filter or encode queues are filling up with frames, causing memory usage
to increase unconstrained. Unfortunately, FFMpeg does not have any way
to set limits on its internal queues. So instead, we manually track
frames enqueued and dequeued so that we can drop frames should the
queues fill up too fast.
Related: bug 469005

M  +29   -11   src/encoder.cpp
M  +9    -2    src/encoder_p.h
M  +20   -6    src/pipewireproduce.cpp
M  +3    -0    src/pipewireproduce_p.h

https://invent.kde.org/plasma/kpipewire/-/commit/66774b90e2f346d681f3d27a271ce5ad82b82bf7

hey i just came here to say thank you! 
spectacle is recording nicely on fedora 40!