Linux/Wayland: recording aborts on a single corrupted PipeWire frame (KDE Plasma 6 / AMD)

[fnune]

Description

On Wayland (KDE Plasma 6 / KWin, AMD GPU), recording stops mid-capture with:

Task wayland-pipewire-capture-thread failed: PipeWire screen capture frame was marked corrupted

It seems to come from the capture loop returning an error whenever a frame has PipeWire's SPA_CHUNK_FLAG_CORRUPTED flag set, which then ends the whole recording:

crates/recording/src/sources/screen_capture/linux.rs (cap-v0.5.2 / main, ~L635):

if chunk_flags.contains(spa::buffer::ChunkFlags::CORRUPTED) {
    bail!("PipeWire screen capture frame was marked corrupted");
}

As far as I can tell KWin sets this flag occasionally on a single frame, so it looks transient rather than a stream-wide problem. In my log, capture ran for around 8s and 312 frames, then stopped on one corrupted frame:

INFO ...:{task="wayland-pipewire-capture-thread"}: cap_recording::sources::screen_capture::linux: Linux Wayland PipeWire capture stopped sent=312 dropped=0 elapsed_ms=7966
INFO recording: cap_desktop_lib::recording: recording wait actor done: Err(PipelineDoneError(Task wayland-pipewire-capture-thread failed: PipeWire screen capture frame was marked corrupted))

I might be missing context, but I wondered whether the frame could be skipped rather than ending the recording. OBS's PipeWire capture does something similar: on the same flag it logs and skips the frame instead of tearing down the stream.

https://github.com/obsproject/obs-studio/blob/3bba730f76bcecb1ac88be5740395291ca197a57/plugins/linux-pipewire/pipewire.c#L842-L845

Reproduction

1. KDE Plasma 6 Wayland session, AMD GPU.
2. Record a display. It stops after a few seconds with the error above. Intermittent (one corrupted frame is enough), so may take a couple of tries.

Additional Context

• Cap version: 0.5.2
• OS: CachyOS (Arch), KDE Plasma 6 / KWin Wayland, AMD Hawk Point iGPU
• pipewire 1.6.7, xdg-desktop-portal-kde 6.7.1
• Install: Arch has no dpkg, so I extracted the official .deb and ran the binary directly. I do not think it is relevant here, noting it in case.

[linear]

CAP-739

[tembo]

Looking at the code in crates/recording/src/sources/screen_capture/linux.rs, the fix here should be straightforward. The frame_from_pipewire_data function at line 635 currently bails on corrupted frames, and that error bubbles up through process_pipewire_frame to set_fatal_error, which terminates the recording.

The codebase already has a pattern for handling skipped frames - the dropped counter at line 486 tracks frames dropped due to pipeline stalls (StalledAndDropped). A corrupted frame could follow the same path: return Ok(None) from frame_from_pipewire_data instead of bailing, optionally log a warning, and increment the dropped counter.

Something like:

if chunk_flags.contains(spa::buffer::ChunkFlags::CORRUPTED) {
    tracing::warn!("PipeWire frame marked corrupted, skipping");
    return Ok(None);
}

This would require changing the return type of frame_from_pipewire_data from anyhow::Result<ffmpeg::frame::Video> to anyhow::Result<Option<ffmpeg::frame::Video>> and updating process_pipewire_frame to handle the None case (just return Ok(None) to skip sending that frame).

The OBS approach you linked is the right model here - transient compositor hiccups shouldn't tear down an otherwise healthy capture session.

Related context: Linux desktop support landed recently in #1923, so the Wayland/PipeWire path is still relatively fresh. This would be a good hardening fix for KDE/KWin users.