Bug Report Low FPS in OBS? Frames missed due to rendering lag? GPU problems? Look here.

Came across a guy with a monster PC (3090, the lot) who said he needed a dual PC setup to "avoid the bullshit". Reminded me of this issue as that's probably what he was struggling with lol.

Remember when I used stream on a £500 laptop from 2015 and was pretty carefree. You just couldn't do that now given you have to leave a chunk of GPU usage available "just incase" OBS needs it. It's just not dynamic like how it used to be.
 
Wait this is fixed now? Haven't streamed in years but would love to know. You wouldn't necessarily need a dual PC then... right?
Gozen said:
For anyone who hasn't seen it, EposVox made a couple of months ago in regards to issues described in this thread: Windows 10 is Holding Back Content Creators & Streamers! There are more details posted in the description for that video as well.

As a person who used to stream and game from the same PC, I've noticed the rendering lag issues in OBS Studio for a long time.

My gaming (and also former streaming) PC includes:
i7-4790K
16 GB RAM
GTX 1080 Ti 11 GB
Logitech C922 set to 1280x720 at 30 or 60 FPS in OBS Studio
Windows 10 Professional 64-bit
2560x1440 165 Hz G-Sync Monitor
Elgato HD60 Pro

For most games, I was able to play at 2560x1440 resolution at ultra (max) settings, dedicated full screen, with V-sync disabled, no FPS cap/lock set, at 165 Hz refresh rate and able to stream at 1280x720 at 60 FPS usually without much, if any rendering lag/stalls. However, it really did depend on the game. If I ever tried to stream at 1920x1080 at 60 FPS, then rendering lag/stalls would become much more prevalent. There were also those instances where I would see the rendering lag/stalls occurring in real time in OBS studio without me even streaming anything.

I didn't really want to lower my refresh rate to 60 Hz, nor enable V-sync, and/or set a FPS cap/lock at 60 FPS to free up GPU resources. However, even when I did do any, or all 3 of these, there were still instances where rendering lag/stalls would occur.

After seeing EposVox's review of the AVerMedia GC573 Live Gamer 4K last summer, I decided to build a dedicated stream PC.

The stream PC includes:
Ryzen 7 1800X
16 GB RAM
GTX 1060 6 GB
Logitech C922 set to 1920x1080 at 30 FPS in OBS Studio
Windows 10 Professional 64-bit
2560x1440 165 Hz G-Sync Monitor
AVerMedia GC573 4K

After doing this, I was able to to stream at 1920x1080 at 60 FPS with no rendering lag/stalls in OBS studio. The biggest caveat to this is that I can't run 165 Hz on my streaming PC. I also don't operate at 144 Hz, but instead at 120 Hz due to screen tearing that occurs on stream when not running at 120 Hz. I also don't run G-Sync on my gaming PC either due to tearing.

In the end though, I would love to see it where rendering lag/stalls are a thing of the past in Windows 10 with OBS Studio. I do prefer streaming from a single PC, even if it does mean a loss of FPS in games. However, the streaming PC has been working out great and I am happy that I don't have to worry about rendering lag/stalls anymore.
Click to expand...
 
Has anyone tried changing the monitor display picture mode from dynamic contrast to cinema/custom/standard? the monitor, not the OS settings. I did this, it stopped my rendering lag completely. you should try it.
 
Hello all. Great topic, given that we're so many to have this problem (me included).
I have a pseudo-solution (temporary maybe) for micro-stuttering (in relation with frames dropping, or without, I don't know) ; so pease go to the "Now comes the best part" chapter if you want a quick look.

I'm streaming with a second PC, through HDMI-to-USB cable : I use an Optiplex 760 Desktop format, with a Q9550 and a Quadro K600.
In OBS when IDLE (just previewing), my K600 is juste using 50% of its power with a 1080p canvas and 1080p output, and the CPU is using ~30%. OBS stills indicates about 2 to 4% of misseg rendering frames (GPU-side).

I want to add my contribution to this topic by gathering all the informations I have (not conclusions for now).
Here's the crux of the biscuit :

1 - When adding a source (any one), OBS demand ~2% to 4% of GPU. It adds those 2% for each new sources. Meaning that if you add 10 sources, you increase the GPU usage by 20%.
2 - Importing a scene in a scene (nesting scenes) add immediatly 4% of GPU, even if the imported scene is empty.
3 - Points 1 and 2 indicates a problem with OBS and how compositing is made.
4 - I made dozens of tests since the past two years (changing encoding methods hundreds of time, trying fancy HDMI-splitters usage and fake 3rd screen to display a preview and capture it, NDI usage, etc), but the more interesting is the last one : when simply slecting an other SCENE COLLECTION with simples scenes (in wich just a display source is added, without overlay), NO MORE FRAME DROPS. And by re-selecting the previous "bloated" collection, I have a peaceful frame stability for about 2 minutes, before it suddently drops from 60 stable FPS to 58, with 4% of dropped frames.
5 - We can't constantly switch collections, so that's not a solution. Not mentioning that we can't switch collection during a stream anyway. But this is definitely going in the direction of OBS compositing as the culprit, if not the way it loads collections (JSON file since a few updates).
6 - It may be mixed with NVidia drivers and/or Windows way to manage things, of course. But the fact that we have a stability by just changing a collection and switching back, is interesting.

Now comes the best part :

6 - I discovered, months ago, that setting OBS to just some specific CPU cores that are not used by any other consumming process, could help greatly. For instance, on my main PC with an Intel 920 4x2 cores (hypertreaded), I would isolate OBS on cores 3,4,5,6,7,8, and isolate Spotify and Discord on cores 1 and 2 (or any other combination, as long as they are separated). I've re-tested things on my 2nd "Streaming" PC, wich has only 4 cores, and NO MORE STUTTERING ! I still have the 4% frames drop as usual, but the suddent STUTTERING I experienced recently, wich was annoying me because it make the stream experience really uncomfortable for viewers, simply was... solved. Yeah, solved. Solid.

So, the magical "pseudo-solution" to temporarily solve MICRO-STUTTERING (but not dropped frames) is to isolate OBS on some physical cores. I'm not talking of the massive stuttering that has been years ago solved with the "run in admin mode". I'm talking about micro-stuttering, and as a matter of fact, OBS on my second "streaming" PC is NOT running in admin mode. Why ? Because I'm using network drives with it, and unfortunately, auto-mounted network drive (when starting windows) can't be recognized by OBS if it runs in admin mode (I won't elaborate about it, it's an other problem/topic).

I said "physical cores" and not "logical cores". Here's why, with also some general knowledge about core isolation :

A) Cores are numbered starting from #0. If you have 4 cores, they are numbered #0, #1, #2, #3.
B) If hyperthreaded, cores #0 and #1 are supposed to be from the same PHYSICAL core. However, some CPU doesn't work like that, and instead use #0 and #2 as physical core [1], and #1 and #3 as physcal core [2], etc. You have to read the documentation of your CPU to know that !
C) Windows OS is mainly using core #0. Meaning that if you have only 2x2 cores (4 in total), you may avoid core #0 for OBS. Buuuuut.... in fact, as #1 is also on the same physical core [1], just avoiding logical core #0 won't help : you still use physical core [1] (the hyperthreading is managing how incoming requests are spreaded on logical cores), and that may impact OBS. For instance, if logical core #0 has a spike usage like 99%, OBS will be impacted as if his request on physical core [1] won't be routed to logical core #1 without... a certain lag. I'm not a specialist, but I've tested and validated this problem, so... trust me.
D) Indeed, by really avoid totally a PHYSICAL cores (ex : logical #0 and #1 for instance, or #2 and #3 <- but it may vary on some CPU, don't forget !!), OBS doesn't micro-stutter anymore, even if it is ridiculously confined in just two logical cores ! You may be surprised, but OBS can works correclty on just two logical cores, yeah.

So, definitely, cores isolation is a great tool to improve OBS streaming process. As a streamer sharing regularly with others new streamers, i would certainly emphasize on this, absolutely, as a necessary step during tests to solve some problems.

___________________________________________

Now a personal commentary :

- The problem is probably a sum of multiple causes : OBS + Windows + drivers. And the mess is so complex that it is utterly hard to find the culprit, given that there is many ones.
- OBS seems to have a problem with how things are loaded (scenes collection) and how things are mixed up during compositing (GPU increasing iteratively in a stupid mechanical way).
- Windows seems to have an impact on OBS, given that avoiding CPU physical core [1] can greatly improve some symptoms.
- Finally, drivers... well I have nothing for now to say about them.
 
Last edited:
I forgot to mention for you guys, that despite EpoxVox saying that dual-GPU is useless, it is not totally true :

- Dual-GPU is uselss if you launch OBS normally : indeed, it will launch it with the GPU associated with the "main screen". So, if you have two screens, and the main one (on wich you play) is the default one, OBS with launch on it, and so, it will select your main GPU (used to play and display things on this default screen) to process COMPOSITING. Yeah, compositing, not rendering. Compositing is just... receiving and assembling things. You can verify that with a program like HWmonitor, by watching a sudden ~25% usage of your main GPU when launching OBS.
- This means that even with a dual-GPU config and the 2nd GPU selected in OBS for rendering, when not playing you will observe ~25% of your main GPU in use. This explains the "no improvement" phenomenon : indeed, you have no improvement, because rendering is made by the NVENC chipset (no GPU load), and compositing... well it's still there ^^.
- EpoxVox said that it can even lead to "degradation" of performances : yeah, given that on the top of still having compositing made by the main GPU, all the image data is transiting from GPU#1 to GPU#2 by PCI-lanes and RAM. Wich takes... time, if not CPU overloads (if it hasn't enough PCI-lanes available).

First part of a "solution for dual-GPU" :
- However there's a technic to temporarily define your second screen as the "default" one, launch OBS, and revert the screen assignation. This means that if you plug your 2nd screen in a 2nd GPU, this GPU will be used... for compositing !
- You may answer : "yeah but there's still the information transmission in PCI-lanes/RAM problem !".Well, if you CPU can handle it, and if your RAM can too, it can be a part of the solution, because it will completely relieve your main GPU.

The second part, is :
- Use HDMI-to-USB plugged in a 2nd slot of your first GPU, and plug it back into... the same gaming PC ! Yeah, it may sound stupid, but in fact : with this method, you completely AVOID data-transmission through PCI-lanes/RAM !! And as a certainty, that's how I made a fluid DUAL-GPU working on my gaming PC for one complete year !

The only reason why I switched to a second streaming PC method was that I still haven't enough FPS in Apex Legends (wich is an awful consumming game, causing problem to every streamers even with the highest configs). To be coompletely sincere, the CPU I had (Intel 920) wasn't capable to run Apex and OBS with or without this trick : so by changin it to a Xeon X5650, and using a second PC to stream, I completly solved my "problem". But I could re-use a single-PC setup, and the only degradation I would observe is that my CPU will be used for "encoding" (TCPI/IP transmission of the stream), period ! Wich of course would impact my Apex Legend experience, that's why I prefer to keep OBS away from my gaming PC ^^.

But I can assure you that Dual-GPU, with HDMI-to-USB cables, is really working. EpoxVox was just deducing things under a normal (software) capture method, and by launching OBS without the trick. If your CPU can handle things, you will certainly have a main-GPU relief. People saying "no because your main GPU has a chipset to encode on it so it makes no difference and it's even worse to use a second GPU with the same chipset as the renderer" usually completely miss the part about COMPOSITING assigned to the default screen/GPU. ^^
 
Last edited:
The more you micromanage your settings and your hardware, the more fragile the whole system becomes, so in the end everyting can break down even with the next Windows update.

So don't micromanage your system. Let it do its work with how it comes out of the box, use best practice, and if it isn't working out of the box and best practice applied, consider upgrading the right thing - the thing that is the cause of the bottleneck.

Best practice is "use default settings wherever possible", "don't use obsolete hardware" and "use the most recent and patched version of every software".

Almost everything in this thread is reading coffee grounds and "it works for me, so it will work for everyone".
 
Trying out OBS as a replay buffer system (instead of ShadowPlay) with my new install. I can't believe it but... IT'S STILL FUCKING THERE!!!!

Flawless recording and replays when GPU is not fully maxed by the game, and terrible when it is. Are people STILL streaming with this massive hurdle...? I thought it was fixed?

My god no wonder no one uses OBS instead of ShadowPlay for saving replays.
 
You must log in or register to reply here.
Back
Top