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.
