Video performance issues in web browser source in 31 #470
Labels
No labels
area/accessibility
area/dependency
Confirmed
Crash Report
Delayed
Design Issue
Duplicate
Feedback required
Good first issue
kind/bug
kind/cleanup
kind/enhancement
platform/linux
platform/macos
platform/windows
priority/high
Question
Request for Comments
Seeking Other Contributors
Seeking Testers
Won't Fix / By Design
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-obsproject/obs-browser#470
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Anything else we should know?
Comparison videos included below to show the difference. First one is from 30, second one is from 31:
https://github.com/user-attachments/assets/926ab780-3b30-46bb-823c-68b4223b08bb
https://github.com/user-attachments/assets/84acc22d-2b6a-48d9-abb3-2096019c8f9e
This issue is most likely related to the following: https://github.com/obsproject/obs-browser/issues/468
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.
@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.
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.@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.
@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:
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
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.
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".
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.
Thank you for your detailed investigation @WizardCM . Apologizes for lack of response, just got back from vacation. So based on this comment:
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:
https://github.com/user-attachments/assets/e35b6ef4-bb55-4bd9-bac3-2f115f2b1503
However this video was something I directly recorded from OBS Studio 31 and this also has the same issue:
https://github.com/user-attachments/assets/cfc82c81-41f9-41cc-ac19-df99e65e575f
Not sure if any of that helps.
@SaviorXTanren Please test with the test build here to see if the issue persists:
https://github.com/obsproject/obs-studio/actions/runs/13639524423
We don't expect the issue to be fixed but would like to double check.
I just wanted to chime in and mention that I'm unfortunately still seeing this behavior in 32.0.4.
I tried updating from 30.2.3 today to test it out. The freezing with MixItUp video redeems (via Browser Source) is still happening, so I rolled back to v30 and the issue went away again.
The MixItUp team has linked any support request related to the issue tracked here. Saying that they can't do anything as it isn't on their end.
If someone has time to peek at this, it would be super appreciated!
@RytoEX Apologies for the no response, SaviorXTanren who created this issue stepped down from the project so no one else was available to follow up.
I've been doing some testing on my end, and I can confirm that this issue only happens with videos that have audio. When volume is set to 0, all videos play without issues. Not sure if this helps narrow it down to a specific file or audio section that can be patched or tested. Thank you again
From a quick review of this thread, the prevailing theory is that this is a Chromium bug that affects Chromium 127 but is fixed somewhere between Chromium 128 and 133. Unfortunately, we cannot simply update CEF because of major changes in CEF 128.