Repository navigation
fix(linux): start a KDE window recording on its first frame - #1351
Conversation
A window stream waited up to 8 frames for a SPA_META_VideoCrop rectangle before opening the encoder. mutter negotiates that block and fills it a few frames late, so the wait made sense there. KWin never negotiates it: it sizes a window stream to the window, sends one frame when the stream starts, then sends more only when the window repaints. A still window therefore had its only frame thrown away, and the start timed out after 10 s ("the screen share delivered no frame"). Typing in the window during the countdown made it record, which is how a KDE Plasma 6 user on Debian 13 narrowed it down.
The wait now only applies when the negotiated buffers actually carry the VideoCrop block, read from the first buffer-info report, which the shim sends before that buffer's frame.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
The previous fix (#1351) skipped the crop wait only when the buffers did not carry SPA_META_VideoCrop. KWin's buffers do carry the block; KWin just never fills it. So a still window on KDE still had its one frame thrown away while the helper counted to 8, and the start still timed out after 10 s (confirmed on the reporter's machine with the 2.1.2 CI build). The helper now keeps the latest crop-less window frame instead of discarding it. A frame that brings a crop (mutter, a few frames late) supersedes it; otherwise, after 500 ms, the held frame starts the recording at the stream's size, replayed through the same FrameReady path. The negotiated-meta check is gone.
The previous fix (#1351) skipped the crop wait only when the buffers did not carry SPA_META_VideoCrop. KWin's buffers do carry the block; KWin just never fills it. So a still window on KDE still had its one frame thrown away while the helper counted to 8, and the start still timed out after 10 s (confirmed on the reporter's machine with the 2.1.2 CI build). The helper now keeps the latest crop-less window frame instead of discarding it. A frame that brings a crop (mutter, a few frames late) supersedes it; otherwise, after 500 ms, the held frame starts the recording at the stream's size, replayed through the same FrameReady path. The negotiated-meta check is gone.
Summary
On KDE Plasma (Wayland), recording a window failed after the countdown with "the screen share delivered no frame within 10 s" whenever the window was still. Screens were fine.
Cause. The helper threw away up to 8 crop-less frames of a window stream while it waited for a
SPA_META_VideoCroprectangle. mutter negotiates that block and fills it a few frames late, so waiting made sense there. KWin never negotiates it. It sizes the stream to the window, sends one frame when the stream starts, then sends more only when the window repaints. A still window's only frame was discarded, and the start timed out.Fix. Only wait for a crop when the negotiated buffers actually carry the
VideoCropblock. That is read from the firstbuffer-inforeport, which the shim sends before the same buffer's frame. GNOME keeps its current behaviour.Related issue
Reported on Discord (#ask-community) by a Debian 13 / KDE Plasma 6 / AMD Renoir user on v2.1.1.
Type of change
Release impact
Desktop impact
Testing
window-crop-missing … 8 frames, thencapture started, which confirms the diagnosis.WindowScreenCastSourcesends one frame onresume(), then one perWindow::damaged.ScreenCastStreamoffers noVideoCropmeta.cargo test --bin openscreen-pipewire-helperin WSL (rustc 1.98.1): 101 passed, including the newonly_a_negotiated_video_crop_block_is_worth_waiting_for. rustc 1.94.1 hits an ICE on an existingcapture.rstest, onmainas well.🤖 Generated with Claude Code
Summary by CodeRabbit