Bug 469005 - Very high memory used while screen recording (possibly cursor related)
Summary: Very high memory used while screen recording (possibly cursor related)
Status: RESOLVED FIXED
Alias: None
Product: KPipeWire
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: VHI grave
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 469993 469998 471528 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-04-26 13:52 UTC by dmatteo002
Modified: 2023-12-23 04:56 UTC (History)
15 users (show)

See Also:
Latest Commit: https://invent.kde.org/plasma/kpipewire/-/commit/66774b90e2f346d681f3d27a271ce5ad82b82bf7
Version Fixed In: 6.0
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description dmatteo002 2023-04-26 13:52:06 UTC 
SUMMARY
While recording the screen with the new version of spectacle (23.04) a very high usage of RAM of about all the available RAM on the system (which is 5-7gb on my system). It seem to be a problem connected to the cursor because while moving it fastly around the screen the ram usage goes up quickly. 
While in this state the application while still responding doesn't seem able to stop the recording by pressing the button (sometimes it does but after some time is passed between button pressed and actual stop). 
Even after stopping the recording the memory seem to remain allocated. Only deallocated after closing the application.


STEPS TO REPRODUCE
1. Open spectacle
2. Go on the recording tab 
3. Click record "selected screen" (or also "workspace")
4. move your cursor around like crazy for about some seconds to make the ram usage go up faster

OBSERVED RESULT
Ram usage pass from about more or less 1 gb to about 5 gb (physical memory) and some swap. It only stop when the memory is completly full. 

EXPECTED RESULT
No memory increase or not such a big increase.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch linux (kernel 6.2.12)
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9 (+ qt6 istalled)

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2023-04-26 18:35:32 UTC 
Can reproduce. The memory use immediately goes absolutely bananas.
Comment 2 Noah Davis 2023-04-26 18:45:26 UTC 
> move your cursor around like crazy for about some seconds to make the ram usage go up faster

Seems like this only happens when the "Include mouse pointer" option is enabled, although my memory usage didn't shoot up anywhere near as much as yours did. Mine only went up about 40MB while recording a 30 second video.
Comment 3 Noah Davis 2023-04-26 18:51:36 UTC 
Perhaps this is a KPipeWire issue? I don't see any obvious issues in Spectacle's code.
Comment 4 Aleix Pol 2023-04-27 14:03:09 UTC 
This is known, it should be working better with latest versions of KPipeWire 5.27 branch, make sure it's tested with them.

It's a hard problem to tackle too, if you think there's an option we can disable  and improve the situation, it's something that we should probably consider.
Comment 5 Nate Graham 2023-04-27 14:04:45 UTC 
I was able to reproduce this issue yesterday with the tip of the Plasma/5.27 branch in KPipeWire.
Comment 6 dmatteo002 2023-05-16 12:25:10 UTC 
Can reproduce also without the "include mouse pointer" option (but seem a tiny bit slower at leaking all the memory). Also it is only present when recording screen or workspace and not when recording window.
Comment 7 Nate Graham 2023-05-19 20:18:07 UTC 
*** Bug 469993 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2023-05-19 20:19:44 UTC 
*** Bug 469998 has been marked as a duplicate of this bug. ***
Comment 9 Patrick Silva 2023-06-28 12:29:54 UTC 
*** Bug 471528 has been marked as a duplicate of this bug. ***
Comment 10 HeadHunter 2023-09-28 06:46:47 UTC 
This likely has little/nothing to do with mouse pointer. When codec chosen is mp4, there is no memory leak. When codec chosen is webm, the memory leak is present. When codec chosen is web AND mouse capture is enabled, the leak is accelerated by about a factor of 3. The key is that if codec used is mp4 then no leak occurs. My suspicion is that spectacle is either 
1)  not using webm encoder correctly or 
2) webm encoder is leaking memory, which results in spectacle getting the blame (as it seems to be running as a thread under spectacle).

As a workaround recommend using mp4 codec until a fix is found. 

PS: Thanks for bringing this feature to Spectacle, rolling the scripts for ffmpeg was no fun!
Comment 11 HeadHunter 2023-09-28 06:50:19 UTC 
By the way, tests were made with following versions:
spectacle 23.08.1
kpipewire 5.27.8-1
gstreamer 1.22.6-1
libvpx 1.13.0-1

all running on Arch linux (though it probably does not matter).
Comment 12 dmatteo002 2023-09-29 09:27:24 UTC 
I can still reproduce memory leak even on mp4 format, it get to 6gb+ (over 8gb) in seconds (even faster than before maybe).
Comment 13 Dashon 2023-10-16 02:29:58 UTC 
I've tested all choices in this thread, webm, mkv, mouse pointer, no mouse pointer. On a system with 64 GB of ram. Screen recording with spectacle got up to about 27GB in about 20 seconds.
Comment 14 Noah Davis 2023-12-14 14:43:38 UTC 
Can anyone reproduce this with the latest beta version? I am currently unable to.
Comment 15 Noah Davis 2023-12-14 14:46:13 UTC 
For me, Spectacle's RAM usage never goes higher than 2.1 GiB while recording the cursor in a 7680x2160 video with a roughly 1 minute duration.
Comment 16 Nate Graham 2023-12-14 17:02:28 UTC 
I can still reproduce it with today's git master. While recording, memory goes above 5Gb and CPU usage goes above 400%.
Comment 17 Bug Janitor Service 2023-12-15 11:46:35 UTC 
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/102
Comment 18 Arjen Hiemstra 2023-12-19 14:56:16 UTC 
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 475894

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