gh-obsproject/obs-browser

Watch

Fork 0

Frame swap artifacts occurring when HW acceleration enabled and CPU under load #488

New issue

Open

opened 2025-06-13 07:56:37 -05:00 by Dan-Shields · 0 comments

Dan-Shields commented

2025-06-13 07:56:37 -05:00

(Migrated from github.com)

Operating System Info

Windows 11

Other OS

Windows 11 & Windows 10

OBS Studio Version

31.1.0-beta2

OBS Studio Version (Other)

31.1.0-beta2 & 31.0.3

OBS Studio Log URL

https://obsproject.com/logs/HsUwuFk33D2Y1Yxw

OBS Studio Crash Log URL

No response

Expected Behavior

The browser source should be rendered artifact-free.

Current Behavior

Below are screencaps showing the 1-frame long artifacts affecting a browser source set to play a 4k60 video above a #00ff00 color source. There are patterns across the different screencaps, but the artifacts are not always the same. These images were captured by screen capturing the OBS preview, but can also be seen on recordings made by the OBS doing the rendering, as well as in decklink output.

Browser hardware acceleration must be enabled for the issue to arise.

The frequency of frames which are effected is proportional to the load that the CPU is under. The CPU core assigned to run OBS compositing is particularly sensitive.

The issue appears either infrequently or not-at-all if the GPU is running 100% (i.e. GPU bottlenecked). In this instance the video will slow/drop frames, but no artificing is minimized. This part was tested changing videos to ones that were hardware decoded vs software, higher and lower bitrates, and different resolutions to affect GPU usage.

The above was found by correlating HW usage in task manager while trying various combos of things we found to make the problem worse.

Things that exacerbate the issue:

setting the OBS process priority to idle and unfocusing the window
throttling the CPU
applying load across the CPU (tested running a multi-core CPU CineBench 2024 benchmark)
starting a recording using the software encoder (x264)
starting obs virtual camera output
starting decklink output

Things that don't seem to affect the issue:

pixel format (happens on BGRA, NV12, I420, I444 at least)
drop frame (happens on 60 & 59.94 fps)
starting a recording using a GPU encoder (NVENC)
the specific contents of the browser source, as long as its updating each frame (we have found the same issue with CSS animation-based pages, for example)

The issue was first noticed to happen occasionally on beefy renderer machines with identical hardware to each other, then reproduced on several separate machines, one of which is where the attached logs come from. On those we see several affected frames per second.

We have some renderer machines on slightly different hardware, but running the same software which don't show the issue at all.

Steps to Reproduce

Set OBS to 4k59.94, process priority idle, BGRA video format, Browser Hardware Acceleration enabled.
Create a 4k browser source, and point it to the debug page w/ video you can find here.
Optionally add a green color source underneath to make the issue more clear.
Depending on system specs, the issue may already occasionally appear already.
Try to force the issue by adding one or more of the things from the above list of steps that can make the issue worse. The one thing that always makes it show up for me is the CPU benchmark using Cinebench.

Anything else we should know?

Obviously running CPU benchmarks in the background is not what we're doing in production, so I think its appearing in that scenario when the CPU scheduler puts too much work on one core, leading to more sporadic issues.

At least on the renderers we see the issue, it seems like the compositing, decklink output and browser source all work from one core, even on a 32 thread machine. My speculation is that some point the CPU takes too long to copy the browser texture from the GPU into RAM, and a partial frame is seen.

I'm very keen to explore the issue more with someone who understands the render pipeline better than I do, in the hope we can find a fix.

### Operating System Info Windows 11 ### Other OS Windows 11 & Windows 10 ### OBS Studio Version 31.1.0-beta2 ### OBS Studio Version (Other) 31.1.0-beta2 & 31.0.3 ### OBS Studio Log URL https://obsproject.com/logs/HsUwuFk33D2Y1Yxw ### OBS Studio Crash Log URL _No response_ ### Expected Behavior The browser source should be rendered artifact-free. ### Current Behavior Below are screencaps showing the 1-frame long artifacts affecting a browser source set to play a 4k60 video above a #00ff00 color source. There are patterns across the different screencaps, but the artifacts are not always the same. These images were captured by screen capturing the OBS preview, but can also be seen on recordings made by the OBS doing the rendering, as well as in decklink output. Browser hardware acceleration must be enabled for the issue to arise. The frequency of frames which are effected is proportional to the load that the CPU is under. The CPU core assigned to run OBS compositing is particularly sensitive. The issue appears either infrequently or not-at-all if the GPU is running 100% (i.e. GPU bottlenecked). In this instance the video will slow/drop frames, but no artificing is minimized. This part was tested changing videos to ones that were hardware decoded vs software, higher and lower bitrates, and different resolutions to affect GPU usage. The above was found by correlating HW usage in task manager while trying various combos of things we found to make the problem worse. Things that exacerbate the issue: - setting the OBS process priority to idle and unfocusing the window - throttling the CPU - applying load across the CPU (tested running a multi-core CPU [CineBench 2024](https://www.maxon.net/en/downloads/cinebench-2024-downloads) benchmark) - starting a recording using the software encoder (x264) - starting obs virtual camera output - starting decklink output Things that don't seem to affect the issue: - pixel format (happens on BGRA, NV12, I420, I444 at least) - drop frame (happens on 60 & 59.94 fps) - starting a recording using a GPU encoder (NVENC) - the specific contents of the browser source, as long as its updating each frame (we have found the same issue with CSS animation-based pages, for example) The issue was first noticed to happen occasionally on beefy renderer machines with identical hardware to each other, then reproduced on several separate machines, one of which is where the attached logs come from. On those we see several affected frames per second. We have some renderer machines on slightly different hardware, but running the same software which don't show the issue at all. ![Image](https://github.com/user-attachments/assets/b7719785-4fe5-4fcc-91c0-4d506c4b4ca4) ![Image](https://github.com/user-attachments/assets/a449ab93-226d-4273-9958-2b3dd6c39bbf) ![Image](https://github.com/user-attachments/assets/589eb10d-6b96-4795-af72-276cfd0a634b) ![Image](https://github.com/user-attachments/assets/a643f060-03dd-4ade-9d66-ea590329a01b) ![Image](https://github.com/user-attachments/assets/70132323-df60-45d2-af99-786a7bff0e1c) ### Steps to Reproduce 1. Set OBS to 4k59.94, process priority idle, BGRA video format, Browser Hardware Acceleration enabled. 2. Create a 4k browser source, and point it to the debug page w/ video you can [find here](https://drive.google.com/file/d/1Dg6kyKi5lltJgx6sQDq3b0SYDG30BB6J/view?usp=sharing). 3. Optionally add a green color source underneath to make the issue more clear. 4. Depending on system specs, the issue may already occasionally appear already. 5. Try to force the issue by adding one or more of the things from the above list of steps that can make the issue worse. The one thing that always makes it show up for me is the CPU benchmark using Cinebench. ### Anything else we should know? Obviously running CPU benchmarks in the background is not what we're doing in production, so I think its appearing in that scenario when the CPU scheduler puts too much work on one core, leading to more sporadic issues. At least on the renderers we see the issue, it seems like the compositing, decklink output and browser source all work from one core, even on a 32 thread machine. My speculation is that some point the CPU takes too long to copy the browser texture from the GPU into RAM, and a partial frame is seen. I'm very keen to explore the issue more with someone who understands the render pipeline better than I do, in the hope we can find a fix.

👍 1

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-obsproject/obs-browser#488

No description provided.

Rows
Columns