| Summary: | Huge frame drops when recording with spectacle | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] KPipeWire | Reporter: | Yujiro Hanma <moyamat555> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | aleixpol, ase1590, dalexmb008, dragoiu.bogdan, jlp, kde, nate, victorr2007 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Yujiro Hanma
2024-06-21 14:20:43 UTC
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` |