| Summary: | Very high memory used while screen recording (possibly cursor related) | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] KPipeWire | Reporter: | dmatteo002 |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | grave | CC: | agurenko, aleixpol, alex.pyattaev, bugseforuns, dalestorage1, dashonwwIII, dmatteo002, kde, luis.buechi, med.medin.2014, miranda, nate, noahadvs, putr4.s, whyhow+tech |
| Priority: | VHI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kpipewire/-/commit/66774b90e2f346d681f3d27a271ce5ad82b82bf7 | Version Fixed In: | 6.0 |
| Sentry Crash Report: | |||
|
Description
dmatteo002
2023-04-26 13:52:06 UTC
Can reproduce. The memory use immediately goes absolutely bananas. > 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.
Perhaps this is a KPipeWire issue? I don't see any obvious issues in Spectacle's code. 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. I was able to reproduce this issue yesterday with the tip of the Plasma/5.27 branch in KPipeWire. 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. *** Bug 469993 has been marked as a duplicate of this bug. *** *** Bug 469998 has been marked as a duplicate of this bug. *** *** Bug 471528 has been marked as a duplicate of this bug. *** 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! 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). I can still reproduce memory leak even on mp4 format, it get to 6gb+ (over 8gb) in seconds (even faster than before maybe). 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. Can anyone reproduce this with the latest beta version? I am currently unable to. 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. I can still reproduce it with today's git master. While recording, memory goes above 5Gb and CPU usage goes above 400%. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/102 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 |