Do un-used Scenes on my list interfere with Recordings?
- Thread starter Sebatis
- Start date
Certainly if you use the Multiview, it always renders all of the scenes that are shown there.
And if a scene is used as a source in another scene, then of course both scenes have to be rendered.
There's also a lot to be said from a programming perspective, about always processing everything all the time, even if the result is not used. That eliminates problems with task scheduling and random "gotchas" mid-show, where the fluctuating system load ends up greater than the physical capacity, at the expense of always having the maximum possible load all the time. You know immediately, before the show starts, if the entire show will work...or rather...at least that it won't flop for *that particular* reason.
I wouldn't be surprised if OBS did that, but I don't actually know. Never actually had that problem myself, in practice.
And if a scene is used as a source in another scene, then of course both scenes have to be rendered.
There's also a lot to be said from a programming perspective, about always processing everything all the time, even if the result is not used. That eliminates problems with task scheduling and random "gotchas" mid-show, where the fluctuating system load ends up greater than the physical capacity, at the expense of always having the maximum possible load all the time. You know immediately, before the show starts, if the entire show will work...or rather...at least that it won't flop for *that particular* reason.
I wouldn't be surprised if OBS did that, but I don't actually know. Never actually had that problem myself, in practice.
Your response went over my head a bit. I don't think I'm using Multiview, and I'm not adding any Sources as part of another Scene. This is mainly just having a list of Scenes on the bottom left of my OBS even when they aren't in use. One is for my main display, and other Scenes are for individual game captures or applications.
AFAIK I only have 1 Source/Scene selected for Recording at any given time, BUT the log will always load/list all the Sources at the start of each log. It did this same behavior when I had multiple "inert" Scenes too. Just wondering why or if that matters?
koala
Active Member
Unused scenes don't interfere with your recording. If you don't change to them, it's no different to if they don't exist in the first place.
However, everything that's contained in an unused scene is still active and being processed by OBS. OBS has to do this, because you could change to the scene any time, and if you actually change to it, the content has to be available and fresh with zero delay. Display capture sources, game capture sources, their capture operation is being performed even if you never switch to their scene. If you have browser sources with activity in them (Javascript stuff, video player or media sources), this activity is continuously performed and consume memory and CPU power. Media sources are loaded and displayed, and movies played for nothing. However, media and browser sources can be configured to unload and be inactive, if their scene is inactive. But this is an exception.
However, everything that's contained in an unused scene is still active and being processed by OBS. OBS has to do this, because you could change to the scene any time, and if you actually change to it, the content has to be available and fresh with zero delay. Display capture sources, game capture sources, their capture operation is being performed even if you never switch to their scene. If you have browser sources with activity in them (Javascript stuff, video player or media sources), this activity is continuously performed and consume memory and CPU power. Media sources are loaded and displayed, and movies played for nothing. However, media and browser sources can be configured to unload and be inactive, if their scene is inactive. But this is an exception.
Thanks! So if I understand you correctly, Sources and Scenes that are "hiding in the background" will not directly interfere with my Recordings, but will still consume RAM and CPU resources in relation to OBS processing those window captures. Would you describe those CPU resources as insignificant, substantive, or heavy? Is there any loose way to quantify it?
For example, most of my un-used game captures are basically "hooked" to a .exe that the computer is literally not running. This probably means OBS is doing next to nothing to process it. But let's say that while I am currently recording a fullscreen game in the foreground, I also have an un-used main display capture Scene in the background that is not being recorded. Does that un-used main display Scene take up a lot of memory and CPU resources simply for being on my list of Scenes?
@koala pretty much echoed me with different words. :-)
Except for the exception that @koala pointed out, of videos and similar that are specifically set to not do that. But again, that's an exception, not the rule.
Also, its mere presence might enforce some configuration that allows it to work once it does have something, and those configurations might interfere with each other. Maybe the operating system can only serve one of them at a time, and either the rest of them or all of them are nerfed, depending on how the OS handles multiple requests for something that should be exclusive. This is why we don't recommend multiples of some captures. I think the game capture is one of those. This is different from processing live data, but could still be a problem.
If there *is* something to grab, then yes, its entire processing chain still runs as usual, even if the result is thrown away.
---
This is all normal and expected for live media stuff. Whether it's a studio or a concert or whatever, the universal mindset is to have everything running all the time, regardless of whether it's used at the moment or not, and just grab its output or not as desired.
Even something that is only used for a few seconds in a multi-hour production, is turned on and tested well before opening, kept fully on and running throughout the entire thing, and finally shut down well after closing when the crew finally gets around to it. Again, completely normal and expected.
If your machine has trouble keeping up with all that you actually need (or want to keep around "just in case"), then you should look at getting a better machine, or separating its duties to multiple machines.
If your machine keeps up just fine, don't worry about it. 90% load is perfectly okay, so long as it's *constant*. (means it's doing everything that needs to be done, and still has 10% downtime) It's only the fluctuating loads that need to be kept low, "just in case".
Everything is running all the time, regardless of whether you're showing it or not. Add them all up as if you're showing them all at the same time, and that's your constant total, no matter what you're actually doing.
Except for the exception that @koala pointed out, of videos and similar that are specifically set to not do that. But again, that's an exception, not the rule.
If it's not receiving anything, like if it's tied to something that itself is not running, then it just hangs on the last frame that it got. Solid black or transparent if it's never received anything at all yet in this session. No processing the input in that case, that I'm aware of, but whatever filters you might have on it, do still run, and they *are* receiving data. (that last frame, repeated, or generated if there's never been something yet)
Also, its mere presence might enforce some configuration that allows it to work once it does have something, and those configurations might interfere with each other. Maybe the operating system can only serve one of them at a time, and either the rest of them or all of them are nerfed, depending on how the OS handles multiple requests for something that should be exclusive. This is why we don't recommend multiples of some captures. I think the game capture is one of those. This is different from processing live data, but could still be a problem.
If there *is* something to grab, then yes, its entire processing chain still runs as usual, even if the result is thrown away.
---
This is all normal and expected for live media stuff. Whether it's a studio or a concert or whatever, the universal mindset is to have everything running all the time, regardless of whether it's used at the moment or not, and just grab its output or not as desired.
Even something that is only used for a few seconds in a multi-hour production, is turned on and tested well before opening, kept fully on and running throughout the entire thing, and finally shut down well after closing when the crew finally gets around to it. Again, completely normal and expected.
If your machine has trouble keeping up with all that you actually need (or want to keep around "just in case"), then you should look at getting a better machine, or separating its duties to multiple machines.
If your machine keeps up just fine, don't worry about it. 90% load is perfectly okay, so long as it's *constant*. (means it's doing everything that needs to be done, and still has 10% downtime) It's only the fluctuating loads that need to be kept low, "just in case".
To make sure I understand what you two are saying, I recognize that if I have many things open on my PC, those things will all draw resources. But does OBS itself draw significantly more resources because I have those things open & grabbed as un-used background Scenes? I'm unsure how much overhead OBS actually uses for processing all these un-used background Scenes and Sources, basically. To clarify my use case though, I am always only ever Recording one specific window at a time. Just one game, or one browser, or one window. This isn't for a stream-type setting where I am pulling in multiple windows to overlay on top of each other, etc. The other Scenes / Sources simply exist because I needed to add them for previous and future recordings. Does this change any of the answers?
I'm definitely troubleshooting some weird recording behaviors, but also trying to get a better grasp of the technical magic happening behind the scenes too. An example of something I keep running into is Frames missed due to rendering lag. I always get 27 or so of those frames lost just for alt-tabbing back to a fullscreen game, but randomly get 1 or more missed frames added to that counter for unknown reasons. Occasionally, I'm also getting the 21ms or 42ms of audio buffering problem too.
My CPU is the 7950x3d, and my GPU is a 4090, and I have plenty of RAM, but it has definitely not been a consistent experience. When I track these components via Task Manager I have trouble detecting any signs of the hardware struggling, so I'm trying to figure out if I'm using OBS wrong.
koala
Active Member
They are minor. If you have performance issues, they might push an almost fully loaded (but still well running) system over the edge to significant dropouts. In this case, get rid of everything nonessential. But if you don't have any performance issues, keep it if you need it for convenience.
Game capture sources configured with the exe of the game are just searching for a game window that will never appear, which is almost no resource usage. Game capture configured to capture any fullscreen app might grab what you're currently running. Depends on that app. This will take perhaps 1-2% of your GPU resources if they actually grab the fullscreen app.
This is so powerful, a single added capture source is insignificant in case you're running a best practice setup, which includes OBS fps=60, color format nv12, resolution not higher than 2560x1440 (in case of 4k you need to be a little bit more careful), and limiting your game's fps, so the game will not fully load the GPU but leaves room for OBS.
Lost frames just in the moment you alt-tab to or from a game running in true fullscreen mode is irrelevant. Ignore these. They happen during the graphics mode switch.
Hmm, I am definitely pushing that envelope then. The recordings are basically in 4k, 60fps, and often in HDR (meaning sometimes NV12 and sometimes P010). I also often run the games over 60fps but that's something I've been experimenting with. I have a ton of questions which I am trying to decide if I should just move to new threads, but for example:
1) Does playing a game above 60fps while recording that same game at 60fps create extra strain on the hardware from the OBS side, caused by the difference in fps? Is there anything magical about recording at the same FPS as the source game that makes it less of a strain on the OBS side? To clarify, rendering more fps on the game obviously has higher demands on my PC, but I don't understand how OBS actually records things, so I don't know if syncing 60fps gaming to 60fps recording makes OBS's job easier or something.
Thanks. Wanted to make sure that was normal.
There's no difference whether you use a scene or not. If it's *there*, it consumes the same, regardless.
For having a bunch of stuff open on the PC in general, it's not necessarily as bad as you imagine, but it's still good to keep the clutter down. Especially if you have the possibility of sending whatever's on your screen, to the world. (I remember a not-too-happy question on these forums about accidentally broadcasting some very personal information...)
Most apps are event-driven, meaning that they just sit and do nothing - not even scheduled at all for the CPU to touch - until something happens that they're set up to respond to. Click a button, type something, network packet received that matches some criteria, etc. Then it handles that event and gives up control entirely again. They don't tie up CPU by constantly looking for something to do, but they do tie up memory to keep the context of where they are and what's going on.
Running anything bigger (more pixels per frame) or faster (more frames per second) creates more work. Keep those as low as possible while still producing an acceptable result. What's acceptable depends a lot on you, what you're doing, and your audience.
The human visual system can't perceive anything faster than 60fps anyway. The actual limit is kinda fuzzy and depends on the person, but it's definitely lower than 60fps. Those who claim to see faster are really anticipating, not reacting, or keying on something other than the actual framerate.
If you record EXACTLY what is produced, exactly HOW it's produced, then there's no conversion. Just copy straight across. If there's any difference, even to something less, that adds some work, which must be compared to what it takes to work with the original format instead. It might end up saving some to downconvert, and then do a lot with the smaller version, and then publish the smaller result, but then *that* begs the question of, "Why isn't the original that small as well, to eliminate the conversion up front?" Maybe there's a legitimate answer to that, maybe not, in which case you dial those settings back too.
It doesn't help anything (except possibly to fool an algorithm somewhere), to upconvert a final result to something bigger. You're not adding any useful information at all. You can't get back what you lost when you downconverted up front.
koala
Active Member
A difference in fps doesn't put any increased load upon the system. The consequence is more subtle. If OBS does capture, it wakes up at the start of every frame and iterates over all sources. It takes a snapshot of the source at this moment, then composites it on the canvas and sends it to wherever the output should go (recording or stream). Then it sleeps until the next frame is due and does the same for the next frame, and so on.
If a source doesn't change from one frame to the other (its fps is lower than the fps OBS is running with), OBS will capture the same image again. If a source changes multiple times during one OBS frame (its fps is higher than the fps OBS is running with), OBS doesn't see the additional frames. It just captures what is present at the start of its own frame.
Now think about a game running with 144 fps and OBS capturing with 60 fps. Over the course of one second, OBS will see and capture 60 frames and ignore 84 frames. This means, it will ignore either 1 or 2 frames after each captured frame. To be exact, for 36 frames captured it will skip the next frame, and for 24 frames captured it will skip the next 2 frames. This uneven skip is perceived as as slightly non smooth video. Not as stutter or lag, since there are no duplicated frames. Just not completely smooth. This happens, because the monitor of the user playing back that video runs with a strict 60 fps timing, while the frames were originally created (by the game) not in that strict 60 fps timing - some frames were created more early, some frames were created more later. All within the visible time of one frame, but the human eye is able to perceive this as not smooth.
The nasty thing about that is that modern video formats such as mp4 do have a means to record exactly the timestamp when a frame was created, and media players are aware of this timestamp and are able to reproduce the slightly unsteady original capture sequence instead of playing back with a strict 60 fps timing, and OBS is writing this timing into the video file (as far as I know). But monitors do not. Even if the media player is correctly reproducing the original timing, the monitor of the vast majority of the users is running with fixed 60 fps, and this finally creates the unsteadiness. Also some video editors might ignore frame timestamps and instead assume a fixed 60 fps timing, so they destroy the timestamps in edited video and the edited video will appear as unsteady.
Now, if you run your game with 120 fps and OBS captures with 60 fps, OBS will ignore every other frame. This is an even skip, and this is perceived as smooth. In general, the video will appear as smooth if a source has a fps with a multiple of the OBS capture rate. So running your source with 120, 180, 240 fps and capturing with 60 fps will appear as smooth. Running your game with 144 fps or 165 fps or whatever that is not a multiple of 60 will create a slightly non smooth video. This is not because of some system load, it's because of fps ratio.
By the way, what AaronD says about the human eye not being able to perceive more than 60 fps isn't true. It's not able to see the individual frames any more, that's true. However, it still sees a higher fps as more smooth motion. It's more natural, more pleasant, more clear and less motion blur. He either has old eyes, or he never saw a smooth high-fps game. Slow camera panning with high fps is rock solid and crystal clear, while the same panning with 60 fps is never so smooth and appear more blurred. If you once played with high fps for a week, you will never want to go back to 60 fps, feeling it's vastly inferior. You feel it even with the Windows desktop, moving the mouse or moving windows around.
There is also this site: https://testufo.com/ where you're able to visualize difference in perception of 60 fps and higher-than-60-fps video, in case you have a monitor able to run with higher han 60 fps.
Last edited:
Thank you for explaining that *sensibly* for a change! Every other rebuttal I've had, came across as an id10t kid who took the marketing bait and was incapable of thinking any more than to say "ur stoopid". Of course, that doesn't convince anybody other than themselves.
I didn't *think* I was old, but I do notice on occasion, that I remember things that my audience has never heard of...
I'll have to find a true (not false-marketing-hyped) high-fps rig that I can show that site on.
Thanks again!
After letting that simmer for a while, I think I finally got it! Thanks again, @koala, for giving me what I needed to get there.
I don't think I even need to see it to believe it. If I understand correctly now, I can extrapolate from the 15, 30, and 60fps demos that my machine *can* display.
It's not about flash rate at all. That's still capped as I said before, and @koala agreed with. It's about tracking something across the screen, like a bird across the sky. I was surprised with the demo site, how big the steps still were, even at 60fps, for what seemed like relatively slow motion. That appears as jitter or jerkiness when you try to track it like a bird, and THAT'S the problem.
In *that* sense, I might even be able to see 240fps (for real, not duplicated frames down to something slower), given the right test. Wow!
---
But there's still the question of whether it's worth capturing and processing at that rate. If anything in the entire chain is slower, like a lot of viewers' screens, then the answer is no. Capture at the final displayed rate, and process at that rate too. If some of your viewers do have fast displays, and you have things that beg to be followed like that, then maybe it *is* worth it.
I don't think I even need to see it to believe it. If I understand correctly now, I can extrapolate from the 15, 30, and 60fps demos that my machine *can* display.
It's not about flash rate at all. That's still capped as I said before, and @koala agreed with. It's about tracking something across the screen, like a bird across the sky. I was surprised with the demo site, how big the steps still were, even at 60fps, for what seemed like relatively slow motion. That appears as jitter or jerkiness when you try to track it like a bird, and THAT'S the problem.
In *that* sense, I might even be able to see 240fps (for real, not duplicated frames down to something slower), given the right test. Wow!
---
But there's still the question of whether it's worth capturing and processing at that rate. If anything in the entire chain is slower, like a lot of viewers' screens, then the answer is no. Capture at the final displayed rate, and process at that rate too. If some of your viewers do have fast displays, and you have things that beg to be followed like that, then maybe it *is* worth it.
Thanks for a phenomenal write-up @koala. Exactly what I was looking for.
These explanations are definitely tracking with what I'm experiencing. There is a lot of noticeable "stuttering" when I'm playing above 60fps but recording at 60. I couldn't quite tell what was wrong but this confirms why I was perceiving frame jumps in the recordings. Unfortunately as you've mentioned, it's kind of painful to step back down to 60 frames. Feels bad even if I can probably adjust to it easily enough. My instinct is to go to 120 to resolve this issue, but even on the 4090 that just won't happen on many decade-old games at 4k, to say nothing of newer titles these days.
@AaronD I'm guessing you probably just need any higher frame monitor to check that site out. Doesn't feel like a graphic intensive test, though I didn't notice any options in-between 60, 120 & 240hz on it. Depending on use case, our eyes can definitely perceive higher than 60 frames though, by quite a bit. My experiences with it mirror what koala described. When upgrading beyond 60 it's not super noticeable because the resulting effect is that the movements on-screen simply feel natural; the still images stay the same before and after. But when you try to rewind back to 60 frames you immediately notice how much has gone missing. Feels like a stuttering mess to me, almost unbearable. This mostly only matters to me when in a high detail streaming environment, such as gaming. And I was perfectly happy at 60 up until that point. Can't put that genie back in the bottle!
At any rate, thanks for the answers both of you.
So this must be what variable frame rate (VFR) means... Interesting!
These explanations are definitely tracking with what I'm experiencing. There is a lot of noticeable "stuttering" when I'm playing above 60fps but recording at 60. I couldn't quite tell what was wrong but this confirms why I was perceiving frame jumps in the recordings. Unfortunately as you've mentioned, it's kind of painful to step back down to 60 frames. Feels bad even if I can probably adjust to it easily enough. My instinct is to go to 120 to resolve this issue, but even on the 4090 that just won't happen on many decade-old games at 4k, to say nothing of newer titles these days.
Amazing. I'm gonna be spreading that around.
@AaronD I'm guessing you probably just need any higher frame monitor to check that site out. Doesn't feel like a graphic intensive test, though I didn't notice any options in-between 60, 120 & 240hz on it. Depending on use case, our eyes can definitely perceive higher than 60 frames though, by quite a bit. My experiences with it mirror what koala described. When upgrading beyond 60 it's not super noticeable because the resulting effect is that the movements on-screen simply feel natural; the still images stay the same before and after. But when you try to rewind back to 60 frames you immediately notice how much has gone missing. Feels like a stuttering mess to me, almost unbearable. This mostly only matters to me when in a high detail streaming environment, such as gaming. And I was perfectly happy at 60 up until that point. Can't put that genie back in the bottle!
At any rate, thanks for the answers both of you.