Video performance issues in web browser source in 31

[SaviorXTanren]

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

31.0.0

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/9nLLWWxZaLTtIVAE

OBS Studio Crash Log URL

No response

Expected Behavior

We've been doing some testing of the browser source/docks CEF updates to version 127 as part of OBS Studio 31 and we've noticed a huge performance hit in the way the web browser source renders multiple videos and iframes on the page that's displayed within the web browser source. Previously on 30.2, our Overlay could easily render 15+ videos all embedded within iframes without skipping a beat.

Current Behavior

However on 31, doing any more than a couple at a time can easily freeze all the videos that are being rendered and keep them hanging on the screen itself. Doing some remote debugging on both versions, I don't see any errors cropping up within the console and nothing looks awry with any of the profiling I was doing, but it's a very obvious performance difference between the versions. We've gotten multiple reports from users who have encountered this only since upgrading to any version of 31, but don't encounter it when downgrading back to 30.

Steps to Reproduce

1. Create a web browser source
2. Link it to a simple HTML file that repeatedly creates iframes with a single
3. Save the web browser source and let it begin running

Anything else we should know?

Comparison videos included below to show the difference. First one is from 30, second one is from 31:

Version.30.mp4

Version.31.mp4

[SaviorXTanren]

This issue is most likely related to the following: #468

[WizardCM]

Please provide a sample webpage to test with. This looks less like a performance issue and more a video decoding or iframe rendering issue, which both may be outside of our control and unrelated to #468.

[SaviorXTanren]

@WizardCM see the attached ZIP file below:

obs_overlay_test.zip

Below is the setup for the web browser source:

This example doesn't have the exact issue with video frames getting completely hung, but you can definitely still see video lag occurring (the audio appears to continue playing fine). It's definitely noticeable in version 31 if you let it run for a few seconds, but I didn't see a single frame drop when running in 30.

However even if this is an video decoding / iframe rendering issue, this specifically wasn't a problem for any of our users on version 30 or earlier; this only started cropping up within version 31. I'm not specifically saying it was something OBS Studio itself did, but the chromium / CEF changes definitely had some impact on this issue.

[ElTioRata]

For some weird reason I started getting this issue on 31.0.1 but not the previous version I think. Nevermind, this performance issue is only present starting from 31. I downgraded to OBS 30 and it's gone.

[WizardCM]

@SaviorXTanren To me it sounds like the bug in this ticket's title/description is very different to the one you reproduced in that ZIP. The former has individual videos freezing within the same browser source (while others continue rendering), the latter is some visual lag for the entire browser source (which is what #468 is about).

I'd rather not conflate the two bugs, as the linked bug #468 already has a cause on the Chromium side tied to how the page frames are sent to us, will hopefully have a fix at some point in the future, and has very specific behaviour (entire browser source lags at specific frame counts, for 250ms).

As I mentioned before, if you're seeing individual videos within one browser source freeze, we need a reproducible file. I still believe your issue is likely tied to video file decoding, potentially even hardware decoding (could even be GPU driver version specific!). I absolutely expect it was introduced by the Chromium update, but ultimately that tells us very little. It could be something we're doing incorrectly, or something that's incorrectly configured on our end, or it's exposing a new bug on Chromium's end. Without a file I can reproduce it with, I can't isolate the cause.

[SaviorXTanren]

@WizardCM That's fair catch, I didn't notice the difference at first. So attempting to generate a fully re-producible file is going to be tricky as if it is video decoding related, it's not going to be something that can be easily put into a single HTML file. Our application hosts a local HTTP listener server on the user's machine for the displaying of visuals (Text, Images, Videos) in a web browser source. The Overlay and all of it's hosted content is routed through this HTTP listener server, including video files. The video files are additional requests against the HTTP listener, which is reads in the video file contents and sends it back in response either with the entire video file data or partial content ranges if the browser supports it. So attempting to extract that out completely into a standalone application would take a bit of work. I'll probably have some time this weekend to try and do that.

Depending on your time & willingness though, I'd be happy to walk you through how to reproduce it through our application if you wanted something to just look at in the interim. It would take 5 or less minutes to setup in total. Otherwise give me a week or so to try and build a standalone executable for this scenario. It would essentially entail the following:

• Download the latest version from our GitHub: https://github.com/SaviorXTanren/mixer-mixitup/releases/download/1.3.0/MixItUp.zip
• Un-zip and run MixItUp.exe inside
• Select the option to create a New Profile, sign in with a streaming account for Twitch/YouTube/Trovo, proceed through to the rest of the wizard
• On the main menu, head to Services -> Overlay, and connect it if it's not already
• Copy out the URL for the overlay ("http://localhost:8111/overlay") and add it to a web browser source in OBS Studio. We recommend setting it to 1920x1080 and ensuring "Shutdown source when not visible" & "Refresh browser when scene becomes active" are checked
• From the main menu, head to Action Groups -> New Action Group
• In the new window, select "Overlay (Images & Videos)" from the drop at the bottom and hit the + button
• In the new Overlay section that appears, select "Video" for the action.
• Browse to a video (the GI Joe one I included in the previous upload works well since it's short)
• Click on the Position tab and select "Random" for the Screen Position drop-down, this helps to better see when the freeze happens
• Look for the Play button on the top banner of the Overlay section and basically just begin mashing the Play button repeatedly until the freeze occurs.

[WizardCM]

Thanks for the thorough reproduction steps. I have confirmed the issue, and have verified it is unrelated to the other linked issue.

I have also verified that it can also be reproduced

1. in a browser dock
2. with browser hardware acceleration disabled

This means it's entirely unrelated to our changes in upgrading to Chromium 127 (that is, it's not shared textures related), and likely a Chromium bug.

It definitely seems to be tied to media in an iframe somehow. Inspecting any media within the page confirms the media is frozen. No attempt at calling .play() resumes it.

I will continue testing when I'm able, including upgrading to newer versions of Chromium to see if it's already fixed on their end.

[WizardCM]

I attempted to test this issue in cefclient, which is CEF's standalone sample application to verify whether bugs are related to our code or not, but the mentioned video file uses a codec that is not enabled in Spotify builds (they disable proprietary codecs by default). If you have other video files we can test with, please post them, otherwise I will have to experiment a bit to find one I can test with.

You can download cefclient from this link, using the option "Sample Application".

[WizardCM]

While further testing occurred for #468, we made a CEF build and OBS build with Chromium 133 (with proprietary codecs), and it looks like whatever issue occurs as part of this ticket no longer occurs in Chromium 133, so the bug was fixed somewhere between 127 (what OBS 31.0.1 ships with) and 133. Unfortunately, this means that unless we can find the exact fix and backport it (among 5,000+ commits), it may be a while before a fix for this issue can be shipped in OBS, as much work has to occur in obs-browser before we can safely ship with >127.

I think next step is to search the Chromium bugtracker to see if someone reported the bug, which could help us narrow the fix commit.

[SaviorXTanren]

Thank you for your detailed investigation @WizardCM . Apologizes for lack of response, just got back from vacation. So based on this comment:

but the mentioned video file uses a codec that is not enabled in Spotify builds

If the video is re-encoded using a different codec, do you think that would at least mitigate the issue?

This video below has the same issue occur and this one I know I had ripped from a YouTube video just using a generic YouTube downloader, so I'm not sure what codec it used:

The.More.You.Know.mp4

However this video was something I directly recorded from OBS Studio 31 and this also has the same issue:

2025-01-21.23-36-57.mp4

Not sure if any of that helps.