Bug 478029 - Window Recording freezes when resizing the window
Summary: Window Recording freezes when resizing the window
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 480336 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-12-04 05:23 UTC by foodblob
Modified: 2024-01-28 00:49 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0
Sentry Crash Report:


Attachments
Demo of the bug (675.37 KB, video/x-matroska)
2023-12-04 05:23 UTC, foodblob
Details

Note You need to log in before you can comment on or make changes to this bug.
Description foodblob 2023-12-04 05:23:09 UTC
Created attachment 163842 [details]
Demo of the bug

Window Capture (Pipewire) will freeze when the target window is resized.  Tested on Firefox, Chrome, and OBS all with the same issue


STEPS TO REPRODUCE
1.  Open any screen recording software
2.  Record a window
3.  Resize Window

OBSERVED RESULT
Recording Freezes

EXPECTED RESULT
Recording Continues, Resize if possible

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: 
NixOS 23.05/5.27.9
Fedora Kinoite/5.27.x
NixOS 24.11/Plasma 6 Beta

KDE Plasma Version: 
5.27.X, Plasma 6 Beta

KDE Frameworks Version: 
5.112.0 (haven't checked the other system)

Qt Version: 
5.15.11 (haven't checked the other system)

ADDITIONAL INFORMATION
Tested with Latest Plasma 5 and Beta Plasma 6
GPU Vendor doesn't matter (Tested with an Nvidia RTX2060, intel 8&9th gen iGPU, AMD RX6700XT)
Flatpak doesn't affect the result
no issue on xorg
Comment 1 thecookie94 2024-01-20 14:39:42 UTC
Let me add a comment to that.

Yup, I am affected by this as well. Broken in OBS, as it is in Chromium and Firefox.

Format renegotiation works just fine, but after that it freezes (window resize isn't even reflected in the capturing application) and I end up with the following ?maybe? related log messages in my journal:

Jan 20 15:17:49 HOSTNAME wireplumber[6607]: <WpSiStandardLink:0x5f56c654e850> si-standard-link: in/out items are not valid anymore
Jan 20 15:17:49 HOSTNAME wireplumber[6607]: <WpSiStandardLink:0x5f56c63204c0> si-standard-link: in/out items are not valid anymore
Jan 20 15:17:55 HOSTNAME pipewire[6604]: mod.client-node: 0x633d9841cb30: unknown peer 0x633d982e89c0 fd:157

and a bit after that kpipewire comes in as well with

Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 target not found
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 unknown resource 2 op:4
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 unknown resource 2 op:4
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 unknown resource 2 op:4
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 unknown resource 2 op:4
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 unknown resource 2 op:4
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 unknown resource 2 op:7
Jan 20 15:18:22 HOSTNAME plasmashell[1625]: kpipewire_logging: PipeWire remote error:  -2 target not found

after which the cycle in log messages continues with the message from wireplumber failing to activate the link, pipewire mod client node unknown peer, and then kpipewire logging the same again.

System:
Ryzen 7 3700x, 32GB mem, 5700xt (running mesa driverstack), u2d archlinux (at the time of writing), plasma 5.27.10 on wayland, kde frameworks 5.144.0 and qt ver 5.15.12
Comment 2 Zamundaaa 2024-01-22 22:26:52 UTC
Shouldn't happen anymore with https://invent.kde.org/plasma/kwin/-/commit/2e6619f3d05c5b4564c3bcf00a510cc911968aae
Comment 3 Zamundaaa 2024-01-25 20:29:43 UTC
*** Bug 480336 has been marked as a duplicate of this bug. ***
Comment 4 thecookie94 2024-01-28 00:49:13 UTC
Running plasma 6 rc1 (with the commit to fix it applied as a patch), and yes it indeed does resume the stream after window resize now.
There is some "kwin_screencast: Waiting for new buffers to be created" spam in the log (multiple time per second) in the journal now, though