gh-obsproject/obs-browser

Watch

Fork 0

New shared textures hang on frame 404 for 250ms, repeating #468

New issue

Closed

opened 2024-12-20 06:04:50 -06:00 by Lordmau5 · 8 comments

Lordmau5 commented

2024-12-20 06:04:50 -06:00

(Migrated from github.com)

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/CO0OuTCbJml5RuSh

OBS Studio Crash Log URL

No response

Expected Behavior

Browser sources are working fine without any lag (as can be seen with animated emotes for example)

Current Behavior

Browser sources are lagging sometimes very frequently, other times not as much, with OBS 31 vs. 30.2.3

Steps to Reproduce

Add browser sources to a scene (e.g. direct link to an animated 7TV emote, testufo page, etc.)
Wait and observe stuttering (good to see on Testufo which will show it in a warning box)

Anything else we should know?

This was not happening on 30.2.3 (but I'd rather stick to the newer version because of both TEB and also better encoder and feature support)

It seems I'm so far one of the few people that can reproduce this (on 3 machines no less) and I wouldn't even know where to begin debugging this.
My hunch would be on either the new shared texture implementation in OBS 31 or perhaps something that changed in CEF internally going from the previous version (5060?) to the one found in 31.

As a side-note, this is happening with both HW Acceleration on and off.
The log in question is from my main OBS instance that I use for streaming - However in the first example below I was able to reproduce it on a fresh portable instance with pretty much nothing besides the browser sources (Didn't record OBS itself, just what was in the canvas)

Examples:
https://github.com/user-attachments/assets/8a70613a-6b8d-41d0-8965-11677d1bf2aa

### 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/CO0OuTCbJml5RuSh ### OBS Studio Crash Log URL _No response_ ### Expected Behavior Browser sources are working fine without any lag (as can be seen with animated emotes for example) ### Current Behavior Browser sources are lagging sometimes very frequently, other times not as much, with OBS 31 vs. 30.2.3 ### Steps to Reproduce 1. Add browser sources to a scene (e.g. direct link to an animated 7TV emote, testufo page, etc.) 2. Wait and observe stuttering (good to see on Testufo which will show it in a warning box) ### Anything else we should know? This was not happening on 30.2.3 (but I'd rather stick to the newer version because of both TEB and also better encoder and feature support) It seems I'm so far one of the few people that can reproduce this (on 3 machines no less) and I wouldn't even know where to begin debugging this. My hunch would be on either the new shared texture implementation in OBS 31 *or* perhaps something that changed in CEF internally going from the previous version (5060?) to the one found in 31. As a side-note, this is happening with both HW Acceleration on and off. The log in question is from my main OBS instance that I use for streaming - However in the first example below I was able to reproduce it on a fresh portable instance with pretty much nothing besides the browser sources (Didn't record OBS itself, just what was in the canvas) Examples: https://github.com/user-attachments/assets/8a70613a-6b8d-41d0-8965-11677d1bf2aa ![image](https://github.com/user-attachments/assets/88da0220-d33c-41d7-897f-01bf05405f28) ![image](https://github.com/user-attachments/assets/9b10015c-1482-4e8b-8c9c-5872ec7db942)

Lordmau5 commented

2024-12-20 14:31:51 -06:00

(Migrated from github.com)

We also talked a bit about it happening when the GPU load is high and / or when e.g. Firefox is open with some tabs.
However, I doubt that is the case seeing as I was able to, as said, reproduce it on 3 different machines with varying GPUs (RTX 3090, RTX 3070 and RTX 4060) and on all of them I used a normal v31 portable build without any plugins and was still able to run into lags...

To add more info onto this: Penwyvern on the Discord managed to build me a version of v31 with CEF 5060 so I could check if the issue might've been in core OBS (or maybe some regression in a plugin etc. etc.) and so far I can't spot any lags happening. We also talked a bit about it happening when the GPU load is high and / or when e.g. Firefox is open with some tabs. However, I doubt that is the case seeing as I was able to, as said, reproduce it on 3 different machines with varying GPUs (RTX 3090, RTX 3070 and RTX 4060) and on all of them I used a normal v31 portable build without any plugins and was still able to run into lags...

Lordmau5 commented

2024-12-30 13:20:55 -06:00

(Migrated from github.com)

Using a HTML test page that increments a number on every animation frame brings some extra results as well.

On a fresh 31 portable install with nothing extra installed I have both a 7TV Animated Emote open (in WEBP format) and the test page.

It seems to freeze the counter at some of the intervals for a bit.
As for the emote, it also sometimes freezes / hitches, but not at the same time as the counter.

This is with 30 FPS because I forgot to change it to 60
https://github.com/user-attachments/assets/e972a727-57dc-43fe-9304-b8988f1f6619

This one with 60
https://github.com/user-attachments/assets/a8aadc86-357d-47ff-a036-6d0829e28672

The emote in question I used:
https://cdn.7tv.app/emote/01GXKYSGBG000A4FN34W5CETQ7/4x.webp

And finally, the HTML test page that was provided by SquidCharger on the OBS Discord (slightly altered for visibility):

<!DOCTYPE html>

<head>
	<style type="text/css">
		body {
			font-size: 64px;
		}

		p {
			background: rgba(0, 0, 0, 0.222);
			color: white;
		}
	</style>
	<script type="text/javascript">
		var count = 0;

		function increment(ts) {
			document.querySelector('.text').innerText = count++;
			requestAnimationFrame(increment)
		}

		requestAnimationFrame(increment);
	</script>
</head>

<body>
	<p class="text"></p>
</body>

Using a HTML test page that increments a number on every animation frame brings some extra results as well. On a fresh 31 portable install with nothing extra installed I have both a 7TV Animated Emote open (in WEBP format) and the test page. It seems to freeze the counter at some of the intervals for a bit. As for the emote, it also sometimes freezes / hitches, but not at the same time as the counter. This is with 30 FPS because I forgot to change it to 60 https://github.com/user-attachments/assets/e972a727-57dc-43fe-9304-b8988f1f6619 This one with 60 https://github.com/user-attachments/assets/a8aadc86-357d-47ff-a036-6d0829e28672 The emote in question I used: https://cdn.7tv.app/emote/01GXKYSGBG000A4FN34W5CETQ7/4x.webp And finally, the HTML test page that was provided by SquidCharger on the OBS Discord (slightly altered for visibility): ```html <!DOCTYPE html> <head> <style type="text/css"> body { font-size: 64px; } p { background: rgba(0, 0, 0, 0.222); color: white; } </style> <script type="text/javascript"> var count = 0; function increment(ts) { document.querySelector('.text').innerText = count++; requestAnimationFrame(increment) } requestAnimationFrame(increment); </script> </head> <body> <p class="text"></p> </body> ```

WizardCM commented

2025-01-19 15:54:15 -06:00

(Migrated from github.com)

Code in question: https://github.com/chromium/chromium/blob/main/media/capture/content/video_capture_oracle.cc#L190

Once we have more insight from Chromium, we can either fix the issue on our side or close this ticket in favour of theirs. Unfortunately, this will likely mean a proper fix may not make it until we upgrade CEF again, which may be a while. Depending on the complexity of the fix, we could theoretically patch our own CEF in the meantime, but that is a decision for another day.

So, extensive testing by a few people has determined this is a bug on Chromium's end and not directly tied to our changes to add support for the new shared textures. We will keep this ticket open for tracking for now, but the next step is to raise a ticket with Chromium so they can either put together a fix upstream, or give us an alternate solution we could implement. Code in question: https://github.com/chromium/chromium/blob/main/media/capture/content/video_capture_oracle.cc#L190 Once we have more insight from Chromium, we can either fix the issue on our side or close this ticket in favour of theirs. Unfortunately, this will likely mean a proper fix may not make it until we upgrade CEF again, which may be a while. Depending on the complexity of the fix, we could theoretically patch our own CEF in the meantime, but that is a decision for another day.

Lordmau5 commented

2025-01-19 16:08:44 -06:00

(Migrated from github.com)

A better URL to test this with is the following, found in #470
https://app.singular.live/output/6W76ei5ZNekKkYhe8nw5o8/Output?aspect=16:9

Alternatively, here's an HTML page with an accompanying timer.webm video (inccrementing timer with milliseconds), seeing as this also affects videos on the webpage. Curiously it doesn't affect videos if they're the only thing on the page.

Additionally, the more the position value at line 91 changes each animation frame, the more often the stutters will occur.

<!DOCTYPE html>
<html lang="en">

<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Video and Background Iframe</title>
	<style>
		body {
			margin: 0;
			padding: 0;
			overflow: hidden;
			font-family: Arial, sans-serif;
			background-color: #2c2c2c;
			color: #fff;
			width: 100%;
			height: 100%;
			display: block;
			position: relative;
		}

		iframe {
			position: absolute;
			top: 0;
			left: 0;
			width: 100%;
			height: 100%;
			border: none;
			z-index: 0;
		}

		.video-container {
			position: absolute;
			top: 20px;
			right: 20px;
			width: 800px;
			height: auto;
			z-index: 1;
		}

		video {
			width: 100%;
			height: auto;
		}

		.scrolling-text {
			position: fixed;
			bottom: 40px;
			white-space: nowrap;
			font-size: 100px;
			font-weight: bold;
			color: #fff;
			text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5);
			z-index: 2;
		}

		.frame-counter {
			position: fixed;
			top: 20px;
			left: 20px;
			font-size: 100px;
			font-weight: bold;
			color: #fff;
			text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5);
			z-index: 2;
		}
	</style>
</head>

<body>
	<div class="video-container">
		<video autoplay muted loop>
			<source src="timer.webm" type="video/webm">
			Your browser does not support the video tag.
		</video>
	</div>
	<div class="frame-counter">Frame: 0</div>
	<div class="scrolling-text">
		Welcome to the awesome scrolling text! This will keep moving from right to left infinitely... I have to make
		this longer so the issue can be seen more often. The frames should stutter every now and then and the text looks
		like it "teleports" to the left after the stutters are over.
	</div>

	<script>
		const text = document.querySelector('.scrolling-text');
		const counter = document.querySelector('.frame-counter');
		let position = window.innerWidth;
		let frameCount = 0;

		function animate() {
			position -= 10; // Adjust speed by changing this value
			frameCount++;

			// Reset position when text is completely off screen
			if (position < -text.offsetWidth) {
				position = window.innerWidth;
			}

			text.style.transform = `translateX(${position}px)`;
			counter.textContent = `Frame: ${frameCount}`;
			requestAnimationFrame(animate);
		}

		// Handle window resize
		window.addEventListener('resize', () => {
			if (position < -text.offsetWidth) {
				position = window.innerWidth;
			}
		});

		// Start the animation
		animate();
	</script>
</body>

</html>

https://github.com/user-attachments/assets/e0969b75-8fc8-47f3-bc50-b79907ab766b

We've reported it on the Chromium bug tracker now
https://issues.chromium.org/issues/391118566

A better URL to test this with is the following, found in #470 https://app.singular.live/output/6W76ei5ZNekKkYhe8nw5o8/Output?aspect=16:9 Alternatively, here's an HTML page with an accompanying `timer.webm` video (inccrementing timer with milliseconds), seeing as this also affects videos on the webpage. Curiously it doesn't affect videos if they're the only thing on the page. **Additionally**, the more the `position` value at **line 91** changes each animation frame, the more often the stutters will occur. ```html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Video and Background Iframe</title> <style> body { margin: 0; padding: 0; overflow: hidden; font-family: Arial, sans-serif; background-color: #2c2c2c; color: #fff; width: 100%; height: 100%; display: block; position: relative; } iframe { position: absolute; top: 0; left: 0; width: 100%; height: 100%; border: none; z-index: 0; } .video-container { position: absolute; top: 20px; right: 20px; width: 800px; height: auto; z-index: 1; } video { width: 100%; height: auto; } .scrolling-text { position: fixed; bottom: 40px; white-space: nowrap; font-size: 100px; font-weight: bold; color: #fff; text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5); z-index: 2; } .frame-counter { position: fixed; top: 20px; left: 20px; font-size: 100px; font-weight: bold; color: #fff; text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.5); z-index: 2; } </style> </head> <body> <div class="video-container"> <video autoplay muted loop> <source src="timer.webm" type="video/webm"> Your browser does not support the video tag. </video> </div> <div class="frame-counter">Frame: 0</div> <div class="scrolling-text"> Welcome to the awesome scrolling text! This will keep moving from right to left infinitely... I have to make this longer so the issue can be seen more often. The frames should stutter every now and then and the text looks like it "teleports" to the left after the stutters are over. </div> <script> const text = document.querySelector('.scrolling-text'); const counter = document.querySelector('.frame-counter'); let position = window.innerWidth; let frameCount = 0; function animate() { position -= 10; // Adjust speed by changing this value frameCount++; // Reset position when text is completely off screen if (position < -text.offsetWidth) { position = window.innerWidth; } text.style.transform = `translateX(${position}px)`; counter.textContent = `Frame: ${frameCount}`; requestAnimationFrame(animate); } // Handle window resize window.addEventListener('resize', () => { if (position < -text.offsetWidth) { position = window.innerWidth; } }); // Start the animation animate(); </script> </body> </html> ``` https://github.com/user-attachments/assets/e0969b75-8fc8-47f3-bc50-b79907ab766b ___ We've reported it on the Chromium bug tracker now https://issues.chromium.org/issues/391118566

🚀 1

WizardCM commented

2025-02-28 21:29:40 -06:00

(Migrated from github.com)

Latest on this issue: the fix has been merged upstream in Chromium, and we have backported it on all platforms. It'll be included as part of https://github.com/obsproject/obs-studio/pull/11910

WizardCM commented

2025-03-08 17:45:52 -06:00

(Migrated from github.com)

Noting this for posterity: Chromium has reverted the fix because it apparently results in more frames than the WebRTC team likes. It apparently results in 32fps when targeting 30fps. The hope is to find an alternate fix before our next big CEF/Chromium update, as we don't want to maintain a custom patch forever.

Noting this for posterity: Chromium has [reverted the fix](https://chromium-review.googlesource.com/c/chromium/src/+/6330304) because it apparently results in more frames than the WebRTC team likes. It apparently results in 32fps when targeting 30fps. The hope is to find an alternate fix before our next big CEF/Chromium update, as we don't want to maintain a custom patch forever.

reitowo commented

2025-04-21 18:26:43 -05:00

(Migrated from github.com)

Update: A new patch has been merged in Chromium 137 and will branch at 4/28, then it will be later merged in CEF, but it could take a while before OBS use the new patch, as the OBS team needs time to sort out the new chrome runtime before update CEF to latest.

Anyway, the whole process of transition to new patch should makes no difference to users.

Don't forget to remove the previous manually maintained patch when bumping to the latest CEF.😉

Update: A [new patch](https://chromium-review.googlesource.com/c/chromium/src/+/6438681) has been merged in Chromium 137 and will branch at 4/28, then it will be later merged in CEF, but it could take a while before OBS use the new patch, as the OBS team needs time to sort out the new chrome runtime before update CEF to latest. Anyway, the whole process of transition to new patch should makes no difference to users. Don't forget to remove the previous manually maintained patch when bumping to the latest CEF.😉

❤️ 2

hoshinolina commented

2025-11-18 02:31:25 -06:00

(Migrated from github.com)

Looks like this just made it into CEF 142.0.14+gceaf578+chromium-142.0.7444.163 (my understanding is it's this commit).

@WizardCM can you confirm that this is all good with upstream CEF now? Also would be nice to be tagged in anything requiring custom patches (or backports ahead of upstream) going forward, so I can throw them into the Fedora CEF package ^^

Looks like this just made it into CEF 142.0.14+gceaf578+chromium-142.0.7444.163 (my understanding is it's [this](https://github.com/chromiumembedded/cef/commit/913e29ea350d7bded1c998ad484ed39fbdfbbde6) commit). @WizardCM can you confirm that this is all good with upstream CEF now? Also would be nice to be tagged in anything requiring custom patches (or backports ahead of upstream) going forward, so I can throw them into the Fedora CEF package \^\^

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#468

No description provided.

Rows
Columns