Question / Help i9-7980XE/GTX 1080Ti/32GB RAM Stream & Recording Stuttering Problem

[JorPorCor]

I am in need of some help. I just recently got a new dedicated rig for streaming. Here are the specs:

Here is my current rigs specs:
Intel Core i9-7980XE 18-Core
MSI GTX 1080Ti
32GB G.Skill RAM
Thermaltake Water Cooling System w/360mm Radiator

Here is my previous rigs specs:
Intel Core i9-7980XE 4-Core
MSI GTX 1080
32GB G.Skill RAM
Asetek Liquid Cooler AIO

My previous rig was not a dedicated streaming rig, so I played games and streamed from that PC. I never really fiddled with my streaming settings on my previous rig because everything worked good for both gaming and streaming. Here are my previous rigs OBS Settings

Output:
Encoder: x264
Rate Control: CBR
Bitrate: 6000
Keyframe Interval: 2
CPU Usage Preset: veryfast
Profile: main

Video:
Base Canvas Resolution: 1920x1080
Output Scaled Resolution: 1600x900
Downscale Filter: Lanczos
Common FPS Value: 30

I never used any custom settings at all. Now with my new rig dedicated to streaming and having the CPU and GPU it has, I planned to increased a few things. My target adjustments are to go from 30FPS to 60FPS, and to go to a slower CPU Preset for better video quality. Here are the settings I used for the first stream on my new rig. It was problems ever since!

Output:
Encoder: x264
Rate Control: CBR
Bitrate: 6000
Keyframe Interval: 2
CPU Usage Preset: slow
Profile: main

Video:
Base Canvas Resolution: 1920x1080
Output Scaled Resolution: 1600x900
Downscale Filter: Lanczos
Common FPS Value: 60

I immediately noticed that the stream was stuttering like crazy! I checked it on my browser and on my phone and it was happening on both. So I immediately stopped the stream and started troubleshooting and cannot for the life of me figure out why? I have tried multiple different presets: veryslow, slower, slow, faster, and fast. They all do the same thing. Though as I go to a faster preset it obviously has a little less stuttering. But how in the world is the video stuttering when the CPU usage sits right around 35% on slow? You mean to tell me that this 18-core processor and GTX 1080Ti can't handle 900p60 on slow preset? Something seems wrong. If anyone can please figure this out it would be great! I know other streamers who have a 6-core or 8-core processor and they stream 720p60 or 900p60 at medium and slow presets without issues. Why is this happening with this much processing power? I have tried everything from limiting threads, cores, disabling hyperthreading, and even overclocking it. I have tested with every core running at 4GHz. This also happens when I record with the same exact settings as my stream settings. I hope someone can give me some good insight into the reasons why this is happening because there is no way this PC can't handle this. Lastly, I use a single capture card to capture my PC and game consoles. I have already figured out that it is not the capture card as I have played a video file and it does the same stuff.

I will supply all the log files I currently have. I wish I had my old log files from my previous PC, but I no longer have them. Would've been nice to compare them just to make sure everything looked okay.

Thanks for looking into this and I hope to get it resolved!
Jordan

 

[DEDRICK]

You can sacrifice some quality by increasing your thread count in the custom x264 settings, I believe 3 is the default: --Threads=24

My reference is from 2013 though, http://dev.beandog.org/x264_preset_reference.html , do some research on x264 thread count.

I know threads splits the image up into horizontal pieces?, assigning 1 piece to a thread to do estimation, I could be off on this. The reason increasing the thread count lowers quality is because it can't accurately estimate motion if you split it up into too many, the threads don't share info with each other.

Someone did a comparison between Threads=1 and Threads=36 here, the degradation is most noticeable at lower bitrates, not sure how resolution plays a part

https://forum.videohelp.com/threads...ding-to-x264-takes-23-hours/page2#post2442659

Start low, or start high, I have never played with it.

All I can say is looking at your log, your encoding time is between 1-2000ms, 60FPS requires lower than 16.6ms

 

[JorPorCor]

Thanks for the response! I will look into the thread count again. I did try to limit the thread count between 20-30, but nothing changed. I’ll try again, but I don’t think that was the issue. The stuttering is pretty bad. Do you know if the thread count being used is directly related to the encoding time?

 

[DEDRICK]

Thanks for the response! I will look into the thread count again. I did try to limit the thread count between 20-30, but nothing changed. I’ll try again, but I don’t think that was the issue. The stuttering is pretty bad. Do you know if the thread count being used is directly related to the encoding time?

Threads is one of the lesser talked about x264 settings, I think it increases encoding latency even when you turn it up, which is the last thing you want to do. It's one area of encoding I don't have much experience in.

Hell you might even benefit from lowering it because I just read x264 apparently opens 1.5 threads per logical core, so for you that is 54, but it can only properly utilize a thread per 40 lines of vertical resolution no lower, so in your case you would want to limit your thread usage to 27 for 1080p. I would try dropping it to 18 or even 8 to see what happens honestly.

Here is someone with a Thread ripper which is 32 threads

https://obsproject.com/forum/threads/can-you-please-explain-x264-option-threads.76917/

Use MPC-HC or download MediaInfo to check the properties of your recordings, it will tell you the thread count it is using, it will look something like this, also check that it changes when you enter Threads=x in the Custom Settings box

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

 

[JorPorCor]

Sweet! That’s some good info, I’ll take a look at that stuff. I have tried limiting the threads but I didn’t do too much with it. I’ll see what I can do.

 

[DEDRICK]

Shroud has a similar setup to yours, he is doing 1080p60 x264 Medium on a i9-7900x so you should definitely be able to do it considering you have 16 more threads. You may be able to download one his VODs and use MediaInfo on it to see his settings.

The jump from Medium to Veryslow is huge though, the settings that change drastically increase CPU usage and encoding time

 

[JorPorCor]

Yea I have looked at the specific changes in the different presets and going from veryfast>medium is huge and going from medium>slow is another huge difference as far as the preset settings go. But I tested the slow, medium, and fast presets last night and it stutters on all of them. It’s so bizarre. The fast preset isn’t too bad but it stutters probably every 15-30 seconds.

 

[BornDownUnder]

Your webcam could also be set to 30fps instead of 60, this will help shave off a bit of the load for encoding.

 

[JorPorCor]

Thanks for the response! I will check into that. I haven’t tried testing without the webcam, which I might do just to get an idea if it’s causing any issues. I might try and wipe my entire computer and do a fresh install of Windows 10. Seems odd that even at the fast preset the streams/recordings are still stuttering. Doesn’t make much sense. I am not capturing the game on the PC either it’s being capture through a Magewell capture card from my gaming PC and I have never had any problems before with it. The stuttering happens on the entire stream as well. I tried playing a video file and it did the same thing. Seems bizarre to me, but I will definitely try more troubleshooting and try both of your guys recommendations! Thanks for the input.

 

[BornDownUnder]

I forgot to ask, what speed is your RAM running at? Ryzen and Threadripper love high clock speeds on RAM, the faster the RAM the better, more important to a large degree than tighter timings. It may be a case of your RAM speed is not fast enough for the CPU preset workload.

 

[JorPorCor]

It is currently running at 3200MHz. I have 32GB (8x4) G.Skill Trident Z RAM installed. This rig is not even a week old. All brand new parts. I currently have the i9-7980XE running at 4GHz per core, I upped it from 3.5GHz. I then made some adjustments to OBS. I also updated all the drivers. There were a ton of system drivers that needed to be updated. I tested the settings at 1080p60, CBR, 6000 Bitrate, Slow Preset, and Custom Settings: “threads=27” and it is as stable as can be. I wasn’t able to get it to overload or stutter. I did some rigourous testing to. I focused mainly on fast movement, probably unrealistically fast because I’d never move around that crazy in the game, but it makes the encoder go crazy and it still didn’t stutter or overload. Now if I immediately change the preset to slower or veryslow it overloads and stutters a bunch, even with the CPU usage at around 50-60%. And it’ll say it’s overloaded even on a near still frame at around 20-30% CPU Usage. Stills seems like somethings weird that this rig can’t handle that, unless I’m misunderstanding something? Is there even a rig out there capable of this? I know there are some Xeon CPUs with up to 28 cores but I have a hard time thinking that that’s what I’d need to achieve that. Either way I’ll see how she does next time I stream and the slow preset is initially what I wanted to achieve because really the quality difference is quite minimal after that.

 

[DEDRICK]

So you got Slow working, next I would take a look at Slower and Very Slow on the Preset Table here.

http://dev.beandog.org/x264_preset_reference.html

It shows you what changes, I skipped the ones that change only between Slower and Very Slow. Put OBS on Slow and use customs to increase each one to figure out which is causing the overload. If I had to venture a guess, 99% sure it is Ref, I'm 50% on Trellis and subme, both of them will increase your encoding time but how much? You're entering major diminishing returns category at this point with a drastic increase in require power.



ref
Slow 5*
Slower 8*
Very Slow 16*

• 
  More reference frames require more processing power because every frame is searched by the motion search (except when an early skip decision is made). The slowdown is especially apparent with slower motion estimation methods.

• 
  You may want to set to the back to Medium's level of 3 or even 4, while it does make it more accurate it drastically increases your encoding time.

subme
Slow 8*
Slower 9*
Very Slow 10*

• 
  6-7: 6 is the default. Activates rate-distortion optimization for partition decision. This can considerably improve efficiency, though it has a notable speed cost. 6 activates it in I/P frames, and subme7 activates it in B frames.
  
  8-9: Activates rate-distortion refinement, which uses RDO to refine both motion vectors and intra prediction modes. Slower than subme 6, but again, more efficient.
  
  An extremely important encoding parameter which determines what algorithms are used for both subpixel motion searching and partition decision.

• 
  9 and 10 might be over kill, change this one last though

trellis
Slow 1
Slower 2*
Very Slow 2*

• 
  0: disabled
  
  1: enabled only on the final encode of a MB
  
  2: enabled on all mode decisions
  
  The main decision made in quantization is which coefficients to round up and which to round down. Trellis chooses the optimal rounding choices for the maximum rate-distortion score, to maximize PSNR relative to bitrate. This generally increases quality relative to bitrate by about 5% for a somewhat small speed cost. It should generally be enabled. Note that trellis requires CABAC.

• 
  Probably should set it back to 1, this is a real killer but change Ref first

 

[thewookieway]

I think we all assumed in this rig that you have an SSD, and not just an HDD.
But do you have a SATA ssd (like samsung 850 EVO or similar) or an NVMe SSD ( like samsung 960 pro) ?

 

[JorPorCor]

I am currently using a Samsung 850 Pro SATA SSD.

I have checked that site that you linked DEDRICK, but didn’t know too much about each setting so your explanations help a lot, especially for testing. Now this might be a dumb question, does x264 use the graphics card at all? I know OBS does, but is OBS using the graphics card separately from the x264 encoder. Just curious if maybe the graphics card could be the bottleneck. I’ll do some more research as well.

 

[DEDRICK]

OBS uses the graphics card for downscaling and generating the frames for the encoder but you are on a stream PC so you wouldn't be having lagged frame issues(100% GPU usage).

x264 will not use the card, the bottleneck in this case is x264 itself, and the exponentially increased processing requirements for little quality gain. You can try to squeak out a bit more by overclocking, setting it to Slower and dropping the reference frames down to 3 or 4 to see how it goes, you might be reaching the limits of x264's efficiency.

When you dropped the thread count down it decreased your encoding time allowing you to go 1080p60 Slow. It was originally at 54 (36*1.5), which made it shit the bed trying to sync all the threads. 27 threads was based on the recommended minimum 40 pixels per thread but you may even benefit from lowering it further. 18 threads would mean all your real cores would get the work, less threads to sync up, but you may overload. No harm in trying.

 

[JorPorCor]

I might try and test 18 threads and see what it does. I have seen a ton of places list that x264 opens 1.5 x logical cores, which would be an insane amount of threads for x264. I have also seen a lot of forum posts state that the vertical resolution/40 should be how many threads need to be used. Lastly, do you think there is any benefit to putting all the work on the 18 cores over opening the recommended amount of threads ie: 27 threads?

 

[DEDRICK]

Lower thread counts yield higher quality / more accurate motion estimation. So at 27 it has 40 pixels it can compare against for changes in motion , at 18 thread it has 60 pixels. The threads don't talk to each other, don't share info, if you split the image up too many times there isn't enough data for estimation to work.

Bunch of interesting info on it in this old doom9 thread

http://forum.doom9.org/archive/index.php/t-168875.html

I was playing around with Threads last night, for me default is 12 with my 4790K, I turned it up to 36 and my CPU usage sky rocketed, which tells me that it split the image up 36 times and my real threads had to crunch them all to do 1 frame, which it couldn't do fast enough and I overloaded lol.

It's a weird balancing act, too low and you don't have enough threads to finish in time, too high and you have too many to piece together in time

 

[JorPorCor]

Yea it’s crazy, I didn’t think I would have to learn all of this when I got this rig! I just expected it to be more then enough power, but hey I’m down to learn and I appreciate all the help. I am going to monkey around with the settings more when I get the chance.

 

[DEDRICK]

I wanted to see what the lowest thread count I could get away with was at 720p60 Very Fast, in PUBG I can do Threads=2, my FPS doesn't even get touched, don't skip a single frame. 900p60 I need Threads=6 to not skip frames. It's an interesting way to tune the performance impact of single PC streaming

 

[BornDownUnder]

Some great info in this thread from replies!
Glad you managed to get your streaming system to run at slow preset as per your desire, I think you would probably need around 21-24 threads at Slow preset for 1080p60fps.