[Bug]: Linux capture produces no recording on niri/Wayland although the portal session succeeds

[talison-cardoso]

Search existing issues

• I have searched the existing issues

Describe the bug

Screen recording does not start on Linux in current OpenScreen releases.

The same machine and environment were able to record the screen correctly with OpenScreen v1.6 and earlier. After upgrading to a newer version, clicking the record button does not result in an actual recording starting.

The application starts normally and the openscreen-pipewire-helper process is created, but the recording never reaches a usable capture/encoding state.

I investigated the problem extensively and found evidence that the PipeWire ScreenCast path is being initialized and that the helper is actively communicating with PipeWire, but the recording itself still does not start.

Expected behavior

Clicking the record button should start screen recording and produce an MP4 recording.

This worked correctly with OpenScreen v1.6 and earlier on the same system.

To Reproduce

1. Start OpenScreen on Linux.
2. Select screen recording.
3. Start recording.
4. Observe that the recording does not actually start.
5. The openscreen-pipewire-helper process is present, but no usable recording is produced.

Screenshots

No response

OS

Linux

OS Version

CachyOS

Other OS

No response

Browser

None

Browser Version

No response

Other Browser

No response

Device Type

Laptop

Other Device

No response

Additional context

The following observations may help identify where the regression occurs.

PipeWire

PipeWire itself is running:

/usr/bin/pipewire
/usr/bin/pipewire-pulse

OpenScreen also exposes a PipeWire screen node:

node.name = "openscreen-pipewire-helper"
media.role = "Screen"

The helper process is spawned when recording is initiated:

/tmp/.mount_.../resources/electron/native/bin/linux-x64/openscreen-pipewire-helper

Its process tree shows it as a child of OpenScreen.

The helper is actually connected to PipeWire

/proc//maps shows active PipeWire shared memory:

[memfd:pipewire-memfd]

and the system PipeWire library:

/usr/lib/libpipewire-0.3.so.0.1608.0

There are also multiple PipeWire modules mapped into the helper process.

Cursor samples are being produced

The helper continuously writes cursor metadata events such as:

{
"assetId": "...",
"event": "cursor-sample",
"height": 1080,
"schemaVersion": 1,
"timestampMs": 1786326629322,
"visible": true,
"width": 2560,
"x": 1897,
"y": 0
}

This was also confirmed directly with strace:

[pid 19619] write(1, "{"assetId":"...","event":"cursor-sample",...}", 208) = 208

So the helper is not simply failing to start or immediately exiting.

FFmpeg / encoder components

The helper loads the bundled FFmpeg libraries:

libavcodec.so.62
libavformat.so.62
libavutil.so.60
libswscale.so.9

The executable also contains strings indicating support for several Linux H.264 encoder paths:

h264_vaapi
h264_vulkan
libopenh264
OPENSCREEN_LINUX_ENCODER

It also contains:

is not one of auto, vaapi, vulkan, software

and:

no H.264 encoder could be opened

as well as FFmpeg calls such as:

avcodec_find_encoder_by_name
avcodec_alloc_context3
avcodec_open2
avcodec_send_frame
avcodec_receive_packet

This makes the encoder stage a possible point of failure.

Electron process

The Electron utility processes were observed with:

--enable-features=...,WebRTCPipeWireCapturer

but also:

--disable-features=...,Vulkan

I am not assuming this is the cause, since the actual recording helper is a separate native process, but it may be relevant when comparing the working and broken versions.

Helper invocation

The helper was observed being started with a request similar to:

{
"outputPath": "/home/.../.config/openscreen/recordings/recording-....mp4",
"cursorMode": "metadata",
"video": {
"fps": 60
},
"audio": {
"system": {
"enabled": false
},
"microphone": {
"enabled": false,
"gain": 1.4
}
},
"deferStart": true
}
Important regression information

OpenScreen v1.6 and earlier worked correctly for screen recording.

The current version does not.

This appears to be a regression introduced after v1.6, although I cannot currently identify the exact commit or component responsible.

Tests already attempted

A substantial amount of troubleshooting was performed before opening this issue, including:

checking that PipeWire is running;
checking PipeWire nodes;
checking the OpenScreen process tree;
checking that openscreen-pipewire-helper is actually spawned;
inspecting /proc//maps;
inspecting file descriptors;
inspecting the helper's dynamic libraries;
tracing the helper with strace;
checking PipeWire shared-memory mappings;
checking /dev/dri;
inspecting strings in the native helper;
checking for VA-API/Vulkan/H.264 encoder support;
attempting to force the Linux encoder backend with OPENSCREEN_LINUX_ENCODER=software;
attempting to force the VA-API backend;
attempting to force the Vulkan backend.

None of these approaches resulted in a working recording.

The important result is that the helper remains alive and communicates with PipeWire, including emitting cursor samples, while the actual recording still fails to start.

Environment
OS: Linux
Desktop/session: Niri
Display protocol: Wayland
Distribution: CachyOS
Kernel: 6.18.42-1-cachyos-lts
GPU: Intel Corporation Raptor Lake-P [Iris Xe Graphics]
OpenScreen version: 1.9.1
Working version: v1.6 and earlier
Device: Desktop
Additional context

The main reason I am reporting this as a possible regression rather than an environment/configuration problem is that screen recording worked on this same machine with OpenScreen v1.6 and earlier.

The current helper also appears to successfully establish the PipeWire side of the capture pipeline. The failure therefore seems to occur later in the recording pipeline, potentially around frame delivery, encoder initialization, or the transition from deferred capture to actual recording.

The native helper contains explicit Linux encoder-selection code and support for:

auto
vaapi
vulkan
software

so a comparison between the v1.6 helper and the current helper may be useful.

I can provide additional strace, /proc mappings, process-tree output, or binary inspection results if needed.

---

Disclaimer

This report was prepared with the assistance of ChatGPT after an extensive troubleshooting session involving multiple attempts to diagnose the issue, including PipeWire inspection, process-tree analysis, /proc inspection, strace, dynamic-library inspection, encoder investigation, and tests with different Linux encoder backends.

The observations and command outputs above are based on the actual tests performed on the affected system; the report was organized and written by ChatGPT to make the investigation easier for the OpenScreen maintainers to review.

[aminjavadi02]

kind of the same problem on ubuntu

os version: Ubuntu 24.04.2 LTS
app version: Openscreen-Linux-1.9.1.deb
installed via apt as sudo

happens when I start recording

error logs:
RECORDINGS_DIR: /home/amin/.config/openscreen/recordings
User Data Path: /home/amin/.config/openscreen
Global shortcut registered: CommandOrControl+Shift+O
[capture-linux] portal-failed: cannot reach org.freedesktop.portal.ScreenCast: A portal frontend implementing org.freedesktop.portal.ScreenCast was not found
Could not prepare the native Linux capture: Error: cannot reach org.freedesktop.portal.ScreenCast: A portal frontend implementing org.freedesktop.portal.ScreenCast was not found
at Ex.handleEvent (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27627:112)
at file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27551:12
at Q$.push (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27149:12)
at Ex.handleStdout (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27543:16)
at Socket. (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27416:85)
at Socket.emit (node:events:508:28)
at addChunk (node:internal/streams/readable:563:12)
at readableAddChunkPushByteMode (node:internal/streams/readable:514:3)
at Readable.push (node:internal/streams/readable:394:5)
at Pipe.onStreamRead (node:internal/stream_base_commons:189:23)
[native-linux] starting capture {
outputPath: '/home/amin/.config/openscreen/recordings/recording-1786348667103.mp4',
prepared: false,
cursor: { mode: 'editable-overlay' },
audio: {
system: { enabled: false },
microphone: { enabled: false, gain: 1.4 }
},
video: { fps: 60 }
}
[capture-linux] portal-failed: cannot reach org.freedesktop.portal.ScreenCast: A portal frontend implementing org.freedesktop.portal.ScreenCast was not found
Failed to start native Linux recording: Error: cannot reach org.freedesktop.portal.ScreenCast: A portal frontend implementing org.freedesktop.portal.ScreenCast was not found
at Ex.handleEvent (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27627:112)
at file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27551:12
at Q$.push (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27149:12)
at Ex.handleStdout (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27543:16)
at Socket. (file:///opt/Openscreen/resources/app.asar/dist-electron/main-C7tnHRt4.js:27416:85)
at Socket.emit (node:events:508:28)
at addChunk (node:internal/streams/readable:563:12)
at readableAddChunkPushByteMode (node:internal/streams/readable:514:3)
at Readable.push (node:internal/streams/readable:394:5)
at Pipe.onStreamRead (node:internal/stream_base_commons:189:23)

[RezaRamezanpour]

I've got same error

[EtienneLescot]

Splitting this, because it had collected two different failures under one title.

The one reported in the comments by @aminjavadi02 and @RezaRamezanpour — A portal frontend implementing org.freedesktop.portal.ScreenCast was not found — is a missing xdg-desktop-portal backend, undeclared by our packages. That is now #328, with a workaround you can apply today and a fix landing in 1.9.3. It is not the same bug as this one and it would have buried it.

@talison-cardoso — this issue stays yours, retitled to match what you actually measured. Two things about it:

Your report is already past everything 1.9.x fixed on niri. v1.9.1 contains the DMA-BUF format negotiation for wlroots compositors (#287) and the recovery of a plane size the producer leaves at zero. You are on 1.9.1 and still failing, so this is a distinct cause and the "regression since v1.6" framing is likely right. Thank you for the detail — the strace and /proc work is what makes that conclusion possible at all.

The one measurement that would split the remaining hypotheses in two. The cursor samples you captured prove the portal session is live, but not that a single video frame arrived: cursor metadata and the PipeWire video stream are separate paths, and the helper emits samples from the former regardless of the latter.

So the question is whether the helper ever emits stream-started on stdout. Running the AppImage from a terminal and keeping the whole output:

./Openscreen-Linux-1.9.2.AppImage 2>&1 | tee /tmp/openscreen.log

then starting a recording and stopping it, and attaching /tmp/openscreen.log.

• ready then stream-started, then nothing → frames arrive and the encoder is where it dies; stderr should carry no H.264 encoder could be opened at WxH. Attempts: ..., and the attempt list names every backend that was tried and why each refused.
• ready and cursor-sample but no stream-started → no frame ever reached us, and the encoder is innocent. That would point back at DMA-BUF negotiation on your Intel Iris Xe, in a case [Bug]: Screen recording fails on Niri/Wayland with PipeWire (no more input formats) #287's fix does not cover.

We have no niri machine and no Iris Xe here, so that one line decides which half of the pipeline to open.

[talison-cardoso]

./Openscreen-Linux-1.9.4-rc.2.AppImage 2>&1 | tee /tmp/openscreen.log

Fontconfig warning: We will not regenerate the cache because some cache files were generated by a newer version (0x2012001) of Fontconfig. Please regenerate the cache with the latest version of Fontconfig to avoid any unexpected behavior. (current version: 0x2011001)
RECORDINGS_DIR: /home/talodev/.config/openscreen/recordings
User Data Path: /home/talodev/.config/openscreen
Global shortcut registered: CommandOrControl+Shift+O
[11880:0810/202744.305255:ERROR:ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:251] '--ozone-platform=wayland' is not compatible with Vulkan. Consider switching to '--ozone-platform=x11' or disabling Vulkan
[11835:0810/202744.350154:ERROR:components/dbus/xdg/request.cc:169] Request ended (non-user cancelled).
[11835:0810/202744.350168:ERROR:ui/base/accelerators/global_accelerator_listener/global_accelerator_listener_linux.cc:389] Failed to call BindShortcuts (error code 5).
[capture-linux] source selected {"sourceKind":"monitor"}
[native-linux] starting capture {
  outputPath: '/home/talodev/.config/openscreen/recordings/recording-1786404467624.mp4',
  prepared: true,
  cursor: { mode: 'editable-overlay' },
  audio: {
    system: { enabled: false },
    microphone: { enabled: false, gain: 1.4 }
  },
  video: { fps: 60 }
}
[capture-linux] portal stream started {"width":2560,"height":1080,"sourceKind":"monitor"}
[capture-linux] source selected {"sourceKind":"monitor"}
[native-linux] starting capture {
  outputPath: '/home/talodev/.config/openscreen/recordings/recording-1786404480236.mp4',
  prepared: true,
  cursor: { mode: 'system' },
  audio: {
    system: { enabled: false },
    microphone: { enabled: false, gain: 1.4 }
  },
  video: { fps: 60 }
}
[capture-linux] portal stream started {"width":2560,"height":1080,"sourceKind":"monitor"}
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] source selected {"sourceKind":"monitor"}
[native-linux] starting capture {
  outputPath: '/home/talodev/.config/openscreen/recordings/recording-1786404492418.mp4',
  prepared: true,
  cursor: { mode: 'system' },
  audio: {
    system: { enabled: false },
    microphone: { enabled: false, gain: 1.4 }
  },
  video: { fps: 60 }
}
[capture-linux] portal stream started {"width":2560,"height":1080,"sourceKind":"monitor"}
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.
[capture-linux] no-cursor-metadata: The negotiated buffers carry no SPA_META_Cursor, so no cursor samples will be produced. Metadata present: [Busy:8,Header:32]. A cursor block is dropped when the compositor's fixed SPA_PARAM_META_size falls outside the range this helper accepts.