Question / Help Freezing on monster PC

[HPV]

Hi folks, hope you're well! I'm doing a daily stream for a client which involves broadcasting a Zoom call with a few graphics behind it. The call occasionally lags inside OBS but that same lag isn't present on the actual call when I look at my second monitor. Any ideas what this could be? GPU usage is getting past 50% at times on a 2080 TI, CPU usage about 2%. Internet is 350 down 37 up.

Here is my log file: https://obsproject.com/logs/vRT9ZJNYDuoa0GSV

If anyone has any clues or ideas of what I could change I'd really appreciate a bit of guidance

Thanks so much!

 

[FerretBomb]

You may need to be more specific what you mean by 'the call occasionally lags inside OBS'.

Only immediate issue I'm seeing is:

09:13:45.013: Output 'adv_stream': Number of lagged frames due to rendering lag/stalls: 964 (0.8%)

which normally means that the GPU is being over-loaded. That really shouldn't be an issue on a single Zoom call Window Capture, and suggests that something else running on the system may be interfering.

In any case, one workaround to try and prevent that from happening is to run OBS as Administrator. Give that a shot; it lets OBS claim GPU priority over all other programs so it can take care of its housekeeping tasks first (if it can't, you get that rendering lag). Just right-click the shortcut, Run as Administrator.

 

[HPV]

You may need to be more specific what you mean by 'the call occasionally lags inside OBS'.

Only immediate issue I'm seeing is:

which normally means that the GPU is being over-loaded. That really shouldn't be an issue on a single Zoom call Window Capture, and suggests that something else running on the system may be interfering.

In any case, one workaround to try and prevent that from happening is to run OBS as Administrator. Give that a shot; it lets OBS claim GPU priority over all other programs so it can take care of its housekeeping tasks first (if it can't, you get that rendering lag). Just right-click the shortcut, Run as Administrator.

Hey Ferret, thanks again for your help in my previous thread :)

That's really strange, it's a top end GPU! Yes must be another program, I'll close everything for the next stream..

By occasionally lagging, I mean the OBS preview window freezes for 1s or so occasionally (audio seems unaffected in these episodes, thankfully)

I'll run OBS as admin from now on, good call. Anything else I can do to identify what the offending program could be if the problem persists? OBS was using about 40-50% of the GPU (which I felt was rather high for the simple task being performed) I am scaling down to 720p from a 1440p 165hz monitor though - could that have a big impact?

I stopped recording via OBS because I know that uses GPU, I would really like to continue recording - could I record with CPU at the same time as streaming? It's only using about 2% of the CPU when stream is active

 

[HPV]

You may need to be more specific what you mean by 'the call occasionally lags inside OBS'.

Only immediate issue I'm seeing is:

which normally means that the GPU is being over-loaded. That really shouldn't be an issue on a single Zoom call Window Capture, and suggests that something else running on the system may be interfering.

In any case, one workaround to try and prevent that from happening is to run OBS as Administrator. Give that a shot; it lets OBS claim GPU priority over all other programs so it can take care of its housekeeping tasks first (if it can't, you get that rendering lag). Just right-click the shortcut, Run as Administrator.

Ok I think I found the problem - entirely my fault! Hopefully this can help someone reading this with the same problem..

I had my canvas and output at 1920x1080, my main monitor is 1440p - streaming tab rescale output set to 1280x720 for Facebook. So I think the GPU may have been doing more scaling work than necessary because the 30-40% usage when streaming and recording has reduced to 12%.

My secondary monitor is 1080, not sure if this needs to be accounted for anywhere in settings? The Zoom call window I use as a source is on this screen.

Next stream is tomorrow morning so will see if there are any lagged frames.. Thanks again for the help Ferret.

 

[FerretBomb]

Actually, I hadn't looked at it until you mentioned multiple monitors, but this is a problem:

21:41:18.783: output 0: pos={0, 0}, size={2560, 1440}, attached=true, refresh=144, name=ROG PG279Q
21:41:18.783: output 1: pos={2560, 0}, size={2560, 1080}, attached=true, refresh=60, name=LG ULTRAWIDE

There's a long-standing bug in Windows that causes problems when running two monitors with different refresh rates, with hardware-accelerated programs. It will lead to stuttering and stalling in OBS thanks to how the OS desktop compositor works. There's a fix coming in Win10 2004, but that isn't out until later this year, or next year. You can get it early if you are on the Slow Ring of the Windows Insider program.
The only full-fix at present for full-release Windows is to run all connected monitors at the same refresh rate.

The canvas and rescale would be much less likely to be an issue.
Generally you want to avoid using the Output rescale option if possible; it performs the rescale at the encoder step, which is CPU-side. If you're recording locally at a higher resolution and streaming at lower, this has to be used.
What resolution is the Zoom call coming in at, and what resolution are the graphics you're planning to use? That mostly determines your canvas resolution, setting it to your monitor resolution is just a basic rule of thumb.
For example, if I had a 1280x720 background graphic and the video I wanted to include on top of it was only 480p, there would be no reason to run the canvas at 1080p... especially if I wanted a 720p output. That would only result in quite a lot of video degradation due to scaling the assets up to 1080p, then using the output rescale to produce 720p. In this example, it'd be better to set the Canvas to 720p, run the background image at native, scale the video to fit my overlay, and run my output with no downscale at all to preserve maximum quality.
Your situation will vary, of course.

I'd also advise swapping to NVENC as your encoder; currently you're using software/CPU x264 Medium preset, and NVENC on the 2080 in your machine will provide compression quality roughly equal to x264 Slow. NVENC is a part of the GPU die that just sits there doing nothing normally, unless you're encoding video; there's no reason NOT to use it, and it will take a lot of that CPU load off the system with no down side (older versions of NVENC weren't great, but Turing on the 2080 is excellent, and has eliminated the need for a 2PC setup 99.999% of the time).

 

[HPV]

Actually, I hadn't looked at it until you mentioned multiple monitors, but this is a problem:

There's a long-standing bug in Windows that causes problems when running two monitors with different refresh rates, with hardware-accelerated programs. It will lead to stuttering and stalling in OBS thanks to how the OS desktop compositor works. There's a fix coming in Win10 2004, but that isn't out until later this year, or next year. You can get it early if you are on the Slow Ring of the Windows Insider program.
The only full-fix at present for full-release Windows is to run all connected monitors at the same refresh rate.

The canvas and rescale would be much less likely to be an issue.
Generally you want to avoid using the Output rescale option if possible; it performs the rescale at the encoder step, which is CPU-side. If you're recording locally at a higher resolution and streaming at lower, this has to be used.
What resolution is the Zoom call coming in at, and what resolution are the graphics you're planning to use? That mostly determines your canvas resolution, setting it to your monitor resolution is just a basic rule of thumb.
For example, if I had a 1280x720 background graphic and the video I wanted to include on top of it was only 480p, there would be no reason to run the canvas at 1080p... especially if I wanted a 720p output. That would only result in quite a lot of video degradation due to scaling the assets up to 1080p, then using the output rescale to produce 720p. In this example, it'd be better to set the Canvas to 720p, run the background image at native, scale the video to fit my overlay, and run my output with no downscale at all to preserve maximum quality.
Your situation will vary, of course.

I'd also advise swapping to NVENC as your encoder; currently you're using software/CPU x264 Medium preset, and NVENC on the 2080 in your machine will provide compression quality roughly equal to x264 Slow. NVENC is a part of the GPU die that just sits there doing nothing normally, unless you're encoding video; there's no reason NOT to use it, and it will take a lot of that CPU load off the system with no down side (older versions of NVENC weren't great, but Turing on the 2080 is excellent, and has eliminated the need for a 2PC setup 99.999% of the time).

Aha, that seems to have done it! Unplugged the 60hz monitor before stream this morning and it ran flawlessly with very low GPU usage, 6-8% from the previous 30-40%.

Should I be worried about using my CPU? The computer is doing nothing else when these streams take place and I have a monster 16 core CPU 2-3% in use while streaming - I assumed it made sense to split the load between both components, but you think I would be better streaming and recording with the GPU? If you think using the CPU is fine for encoding, should I bump it up a bit from X264 slow or even higher as it appears to not be taxing the component at all?

On canvas size, the zoom call comes in at something like 360p which is upscaled when you resize the window. Placeholder video I create and run at the start is 1080p (can be changed) background images vary in size but within 1920x1080. It would be nice if the recording is 1080p, so should I set the canvas to that instead of the native monitor 1440p?

Thanks again for the refresh rate tip!!

 

[carlmmii]

With your hardware, honestly it really doesn't matter. For your situation where you're encoding at 25fps, you could quite easily get away with the slow preset, but I would definitely do a quality comparison between x264 slow, x264 medium, and nvenc for your stream settings. Reason being, the slow and medium encoders prioritize different features to spend more bits on, which has the possibility of the slow preset actually looking worse in some cases.

For recording, there is really no reason not to use nvenc. It's essentially free processing horsepower, and without the strict bitrate limitation, you can set it to a quality-based encoding target and call it good. Just make sure to turn off cuda options so you don't run into potential encoder overload from using non-nvenc processing for encoding (psychovisual tuning, look ahead, and max quality all use cuda).

For the canvas size, use whatever makes the most sense for your workflow. Image scaling is a fairly low-cost function for GPUs in general, and yours has plenty of headroom. For your situation, it seems like it would make the most sense to just set your canvas resolution to 1080p since that's the maximum output resolution you will be dealing with.

 

[FerretBomb]

Aha, that seems to have done it! Unplugged the 60hz monitor before stream this morning and it ran flawlessly with very low GPU usage, 6-8% from the previous 30-40%.

Yep, that mixed refresh rate fix can't come soon enough. To leave both plugged in, just set both to run at 60hz.

Should I be worried about using my CPU? The computer is doing nothing else when these streams take place and I have a monster 16 core CPU 2-3% in use while streaming - I assumed it made sense to split the load between both components, but you think I would be better streaming and recording with the GPU? If you think using the CPU is fine for encoding, should I bump it up a bit from X264 slow or even higher as it appears to not be taxing the component at all?

Worried? No, not at all. But NVENC on the 2080 will give better quality compression than x264 Medium, remove the load from the CPU (which can be used for other things, or just act as extra margin), and is a resource that's just sitting idle at present. You of course can leave it on the CPU side, but frankly, there's no need to with your setup, and going to NVENC will improve the image quality at the same bitrate on the stream.
The CPU DOES still handle video decompression, running any browser sources, and other overhead. It could open your options up to adding more features to your stream.

On canvas size, the zoom call comes in at something like 360p which is upscaled when you resize the window. Placeholder video I create and run at the start is 1080p (can be changed) background images vary in size but within 1920x1080. It would be nice if the recording is 1080p, so should I set the canvas to that instead of the native monitor 1440p?

Thanks again for the refresh rate tip!!

I'd just leave the canvas at 1080p then. Really... you aren't gaining much given the upscale from a source as small as 360p, and need a good bit more bitrate. Going to a 1440p would give you a full-integer downscale, but with the upscaling... it's not even really a concern, it's not going to look great no matter what you do, first upscaling and then re-downscaling. If your videos are 1080p native, may as well maintain full quality on the recordings.

I kind of lean on quality, and focus on delivering the cleanest stream quality I can. If it were me, I would try to get the Zoom call as close to native-resolution as possible, and go from there. Scaling up to 1080p isn't going to make it look good... if anything, it will likely make it look worse due to the upscale-to-1080-then-downscale-to-720. I'd probably re-render my videos at the native streaming resolution (so 720p), run the canvas at 720, the videos at the now-native 720, and upscale the Zoom call to fit. That would keep things as close to full quality as possible for the stream.
If your focus is more on the recordings... well, then going to 1080 makes sense with the 1080p video overlays and having them look good.