Native Go Live is extremely slow / ~1 FPS on SteamOS Gaming Mode

[zerno110]

Native Go Live is extremely slow / ~1 FPS on SteamOS Gaming Mode

Environment

• OS: SteamOS 3.8.16 (stable)
• Build: 20260716.1
• Kernel: 6.16.12-valve24.5-1-neptune-616-gb2f7cfe85e45
• Hardware: Steam Machine, AMD GPU
• Mode: Gaming Mode
• Steamcord: 1.37
• Vesktop: 1.6.7
• Vesktop installation: Flatpak
• Resolution: 2560×1440

Problem

Native Go Live / screen sharing in Gaming Mode does not work correctly.

The stream starts, but the video is essentially unusable: the viewer receives approximately 1 frame every 5 seconds.

Steamcord appears to successfully find and route the Gamescope stream. For example:

[golive] piste stream 651 → steamcord_share (ok)

The Gamescope PipeWire node is also successfully detected by the Steamcord portal shim:

[portal] INFO portalshim: Start → node 83 size=(2560, 1440)
[portal] INFO portalshim: OpenPipeWireRemote → fd pipewire

However, immediately after starting the native screen share, Vesktop/Chromium reports:

[ERROR] third_party/webrtc/modules/desktop_capture/linux/wayland/egl_dmabuf.cc:446
Failed to initialize EGL display: EGL_NOT_INITIALIZED

[ERROR] third_party/webrtc/modules/desktop_capture/linux/wayland/egl_dmabuf.cc:832
Failed to create default device for wayland platform

The errors occur when the native Gamescope screen-sharing session is started.

Diagnostics

Gamescope exposes the screen as a PipeWire video source:

media.class = "Video/Source"
media.name = "gamescope"
resolution = 2560x1440
format = BGRx
modifier = 0
max framerate = 60 FPS

The Vesktop video input also supports:

BGRx
2560x1440
modifier = 0
max framerate = 60 FPS

The Vesktop Flatpak has access to:

sockets=wayland;pulseaudio;fallback-x11;
devices=all;
xdg-run/pipewire-0

Steamcord launches Vesktop with:

--ozone-platform=x11
--disable-accelerated-video-decode
--disable-features=AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL

Relevant journal output

Sep 24 09:45:10 steamdeck PluginLoader[2071]: Starting Steamcord backend
Sep 24 09:46:54 steamdeck PluginLoader[2071]: [golive] piste stream 310 → steamcord_share (ok)
Sep 24 10:00:16 steamdeck PluginLoader[2071]: [golive] piste stream 651 → steamcord_share (ok)
Sep 24 10:00:24 steamdeck PluginLoader[2071]: [golive] piste stream 651 → steamcord_share (ok)

The Steamcord backend itself appears to be able to find the Gamescope stream successfully.

Question

Could this be a compatibility issue between SteamOS 3.8.16 / Gamescope / PipeWire / Chromium WebRTC EGL-DMABUF capture?

Is there a recommended workaround or Chromium/Vesktop configuration for this specific SteamOS Gaming Mode setup?

I can provide additional pw-dump, pw-cli, PipeWire and Steamcord logs if needed.

[Necrosiak]

Thanks a lot for the detailed report, it already rules out a lot: Steamcord finds the gamescope node and routes the audio fine, so the problem sits between gamescope and Vesktop's capture.

The EGL errors mean Chromium couldn't set up its GPU path, so it falls back to copying frames through system memory. That alone should make it slower, not drop to one frame every ~5 seconds, so I'd like to narrow it down. Could you check a few things?

1. Quality setting: in Steamcord's Go Live settings, set the quality to 720p / 30 FPS and try again. Does the frame rate change at all?
2. Game vs. Steam UI: is it the same when you share the Steam interface with no game running?
3. Negotiated format: while a Go Live is running (and stuttering), run this from Desktop Mode or over SSH and attach the file:

   pw-dump > ~/pwdump.json
   

   It shows which format gamescope and Vesktop agreed on (GPU buffers or shared memory), and at what size.
4. gamescope version: the output of gamescope --version.
5. Full Vesktop output: you already captured the egl_dmabuf.cc errors. If you still have that output, the lines around the start of the share (anything mentioning pipewire, desktop_capture or webrtc) would help a lot.

On my side (BC-250 on Bazzite, same Vesktop 1.6.7 Flatpak) the Go Live runs smoothly, so the difference is likely in SteamOS 3.8's gamescope or in how Chromium picks its EGL platform there. Your answers should tell which.

[Necrosiak]

Closing this since there hasn't been an update for a while. Go Live has changed a lot since (direct capture in v1.39.0, plus several capture and audio fixes up to v1.40.1), so if it's still slow on the latest version, feel free to reopen with the Steamcord log from ~/homebrew/logs/Steamcord/ and I'll take another look.