Repository navigation
obs-browser picture is blank on Wayland/AMDÂ #4354
Description
Describe the bug
obs-browser doesn’t display the browser since cef 156. It worked on cef 154.
Seems like #4238 introduced this, reverting it fixes the issue at least on Wayland/AMD.
To Reproduce
Steps to reproduce the behavior:
- Start obs with cef 156.0.8. It doesn’t seem to matter which version it was built with.
- Add a browser source with some url that plays audio, eg. https://www.nyan.cat/
- Sound works, but nothing is displayed
Expected behavior
The browser/website is visible
Screenshots
Versions (please complete the following information):
- OS: Arch Linux
- CEF Version: 156.0.8
- OBS Studio: 33.0.1
- Niri (Wayland) with AMD iGPU + RX 6700 XT
Additional context
A workaround is to disable "Enable Browser Source Hardware Acceleration" under File > Settings > Advanced.
This was also found in jellfium-desktop: andrewrabert/jellium-desktop@ec4cba2
Activity
magreenblatt commentedon Nov 10, 2026
@krissedout any thoughts on this?
krissedout commentedon Nov 10, 2026
@magreenblatt Yes, it’s from #4238, and I found the cause. Since 156 the capture buffers are no longer forced to be linear, so on AMD the driver picks a DCC modifier, and those buffers carry extra metadata planes (2 or 3 for a single-plane BGRA format). The allocation works, but VideoFrame::WrapMappableSharedImage() in media/base/video_frame.cc rejects any handle whose plane count doesn’t match the format, so the capturer never gets its first frame, logs “Unable to allocate frame for first frame capture: OOM?” and stops. CefVideoConsumerOSR::OnStopped() is empty, so nothing recovers and the view stays blank. It reproduces on every AMD setup I’ve tried, it doesn’t depend on the compositor, and NVIDIA buffers are always single-plane, so they’re not affected.
I’m preparing a Chromium CL that accepts handles with extra planes when they carry a modifier, which keeps the compression, and I’ll link it here once it’s up. It would be good to carry it as a CEF patch on 156 and master until it rolls in. I’d also like CEF to stop going silently blank when the capturer stops.
Until then, setting AMD_DEBUG=nodcc in the app’s environment works around it without losing hardware acceleration, as long as Chromium’s GPU process inherits it.
krissedout commentedon Nov 11, 2026
The Chromium CL is up: https://crrev.com/c/8789062. It applies cleanly to 156, so I can open a CEF PR that carries it as a patch on 156 and master, if that works for you, or you'd rather wait for it to get merged first.