Question / Help 1950x | 1080p@Slow|Dual PC | Interesting behavior / help needed

Mera_gg

New Member
Hallo OBS community,

This is my first post here since I have always been able to figure things out myself... until now.

I am running a dedicated second system running an 1950x @ stock speeds. In addition to that
im running a 32gigs 3200mhz cl14 kit of quad channel memory and a gtx 1070. This PC is running an instance
of OBS with basically 1 scene and 1 source which captures the signal from my main pc.

From my main system ( 6800k / 1080ti / 32 gigs of Tridentz 3200mhz ) I send my OBS "preview" to the capture card which has been working great ( i know there are other ways but this is how im doing it since this way I can control the whole production side of things via hotkeys on my main system and not on my second which is further away). The capture card btw is a Magewell HDMI 4k Pro which also works flawlessly.

Now to the situation:
I can stream 1080p60@slow and have been doing so successfully since I got the 1950x.
For some reasons every once in a while the encoder gets overloaded which forces me to switch scenes back and fourth to remove it. The interesting thing in this regard is that the overloading of the Encoder is not reproducible. I can be doing the same thing 20 times, for instance re spawn. Sometimes it happens when I re spawn and sometimes it does not. And even more interesting is. Sometimes it happens when there is basically no movement ( like after a player death ).

OBS Settings:
9PimDQS.png


If I remember correctly the Memory used together with the thread ripper CPU is very important that's why I basically got the fastest available 32 gig kit to do this. In addition to that, My CPU is basically just scratching 30-40 percent load with the Slow preset while streaming. It is also cooled on water and never gets hot. In OBS the only custom commands I am using ontop of the Slow preset is "Threads=20, and bframes=4".

A screenshot of my Magewell Capture Card settings:
BgJYkNa.png


I do believe this thread could be a valuble asset to threadripper users / high core count enthusiast CPU's so lets try and be constructive here :) If we need a video of the exact time it overloads with the scene visible at the same time I gladly will create one and try to reproduce it. Log + Screenshots are attached. Thanks a LOT! in advance for your help.
 

Attachments

  • 2018-02-02 13-06-52.txt
    15.2 KB · Views: 50

KyaJumo

New Member
Hey MERA_gg, have you found the solution?
So far with my research, I've found that threads=27 is the setting for 1080@60fps slow preset for dedicated streaming TR PC. If you've found the solution, can you please share with fellow TR users?

Currently I'm using a single TR PC for gaming + streaming + recording, so my setup is little bit different, but like you, I do get random results regarding in-game fps drops. Sometimes I get super-smooth experience, sometimes I get choppiness. Your workaround of "switching between scenes" sounds interesting though; I think I'll try that tonight.

Also, comparing with Xsplit would be a cool idea too. This way you can be sure if it's the TR vs. OBS.
 

Boildown

Active Member
19:18:10.601: [DShow Device: 'Video Capture Device'] settings updated:
19:18:10.601: video device: USB Capture HDMI 4K+
19:18:10.601: video path: \\?\usb#vid_2935&pid_0009&mi_00#7&3b3dbdea&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global
19:18:10.601: resolution: 1920x1080
19:18:10.601: fps: 60.00 (interval: 166667)
19:18:10.601: format: NV12

Why would anyone get a beast-mode encoding PC like this and handcuff it with a shitty USB capture ... device? Beyond me. Anyways, I blame USB congestion until proven otherwise by using a PCIe capture card and the problem remaining.
 
You are getting encoding overload issues:
23:49:05.470: Video stopped, number of skipped frames due to encoding lag: 29678/2297985 (1.3%)

You need to increase the thread allocation for the x264 encoder to handle the workload, 20 threads is simply not enough for 1080p60fps.
Try threads=27, it should allow for enough headroom and thread count for the workload.
Drop the bframes=4 custom setting until you get the encoding lag under control, then try putting it back in.

You also have some minor bandwidth issues:
23:49:05.469: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 3577 (0.2%)

Below is a link to r1ch's TwitchTest utility, it will assist you in selecting the best streaming server based upon your location:
https://r1ch.net/projects/twitchtest
It is best to do a medium length test duration.
Once it has completed choose the server that as first priority, has the highest Quality and second priority, the lowest RTT (Round Trip Time)
TwitchTest utility will also provide the estimated potential (Will only display up to 10,000 kb/s) bitrate you can stream to for each particular server as well, which may or may not assist you in regards to your upload speed.

If selecting the best server or you are already using the best server to stream via Twitch, then you need to lower your bitrate by 500 and test for 3-5 minutes, with normal game play and check for the above bandwidth related line in your logfile after stopping the test stream.
If it is still present in your logfile, then lower again by 500 and rinse and repeat the test and check.

I hope this helps!
 
@Boildown is correct, your USB capture card is the weakest link in your streaming PC setup and might also be contributing to the encoder overload issues you have, do you have anything else connected to the same USB root hub? If so I would connect them to another hub and have one hub for the capture card by itself to maximize the throughput potential for the capture card you have.
A PCI-e capture card is far superior and is definitely an investment you should look into purchasing in the future..
 

Videophile

Elgato
Just as a note: On my threadripper system, when there is no movement on screen I also get the encoding overloaded warning. When there is lots of action that warning never comes up.

My theory is that the CPU downclocks when there is not motion since its not being heavily used, and so the few IPC heavy workloads in x264 begin slowing down.
 
Just as a note: On my threadripper system, when there is no movement on screen I also get the encoding overloaded warning. When there is lots of action that warning never comes up.
My theory is that the CPU downclocks when there is not motion since its not being heavily used, and so the few IPC heavy workloads in x264 begin slowing down.
I wonder if changing the power profile of Windows to High performance would alleviate this?
If it did, then one could create an automatic power profile plan change on the execution of OBS to resolve the issue, not the best thing though it would work.
 

gtr4life

New Member
I’m having same issue but different I’m getting lag on slow or medium I have a try everything no luck Pure hell
 
Top