New shared textures hang on frame 404 for 250ms, repeating #468
Comments
|
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. |
|
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. This is with 30 FPS because I forgot to change it to 60 This one with 60 The emote in question I used: 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> |
|
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. |
WizardCM
changed the title
|
A better URL to test this with is the following, found in #470 Alternatively, here's an HTML page with an accompanying Additionally, the more the <!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>timer.webm |
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
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
The text was updated successfully, but these errors were encountered: