Question / Help Am I Expecting Too Much From OBS/NVenc?

[Taffer]

I was hoping 1080p@60 would be a reasonable expectation with an i5 2500/Gtx 1070, particularly with NVenc, now I'm starting to wonder if that's just wishful thinking.
30% cpu usage and "encoding overloaded" seems to be the norm for me at "indistinguishable quality" using NVenc.

 

[officiallxander]

depends on how many NVENC sessions you are using. for your gpu, 2 is the max.

 

[Taffer]

depends on how many NVENC sessions you are using. for your gpu, 2 is the max.

1, just trying to record 1 game at 1080p/60.

 

[officiallxander]

right, but do you have other elements in your recording that require encoding? active overlays, media, etc? then again, isnt streaming and recording simultaneously count as 2 sessions?

 

[Taffer]

I'm recording audio and video from a videogame, not streaming.

 

[officiallxander]

are you using game capture from external device or directly from game on pc? 1080p/60fps is maybe 2.5Gbps data rate roughly and your GPU is maybe 1.5GHz? probably too much load.

 

[Taffer]

Runnning game and capturing on the same pc. That's not how gpu bandwidth works. I appreciate the effort, but if you don't have a knowledgeable solution this discussion is only adding to my frustration. Gpu core clock has nothing to do with available bandwidth, and there is more to encoding than bandwidth usage.

 

[R1CH]

Make sure you're limiting your game FPS in some way so that there's enough free GPU for OBS itself. NVENC should have no problem with 1080p60.

 

[Taffer]

Make sure you're limiting your game FPS in some way so that there's enough free GPU for OBS itself. NVENC should have no problem with 1080p60.

That's what I needed to hear. I've been delving into the advanced output settings and the general advanced section. I had the color format set to rgb full 709, because that's what is most familiar to me. I didn't realize there would be such a massive impact switching from NV12. I switched back to NV12 and enabled VBR in the advanced output settings, and now I'm down to 10% cpu without errors. Though now that I think about it VBR would potentially have a negative impact on performance while decreasing file size, as the renderer would need to calculate the variation per frame.

 

[DEDRICK]

Yeah don't record in RGB, the most you can do is i444 I believe, but even that is rough. Safest bet is to leave it on NV12, considering you have to in order to stream. You will experience some color shift, it's unavoidable.

You should try to use CQP/IQP/CRF(All the same thing) for recording, default is 23.

Lower values = higher quality/less compression but file size increases drastically. When you select "Indistinguishable" I believe it drops it to CQP 16? It's something ridiculous, I typically never go below 20.

 

[Taffer]

Yeah don't record in RGB, the most you can do is i444 I believe, but even that is rough. Safest bet is to leave it on NV12, considering you have to in order to stream. You will experience some color shift, it's unavoidable.

You should try to use CQP/IQP/CRF(All the same thing) for recording, default is 23.

Lower values = higher quality/less compression but file size increases drastically. When you select "Indistinguishable" I believe it drops it to CQP 16? It's something ridiculous, I typically never go below 20.

I don't intend to stream, I'm recording for a game review/retrospective channel on YT/Bitchute.
What makes CQP special? I understand the difference between CBR and VBR, but this is the first time I've run across CQP. File size isn't a huge problem, performance is more important to actually run the games and record simultaneously. If it turns out that lossless with 0 b frames provides the best performance, so be it. I can always convert to a more efficient format later on, but I can't get back lost performance.

 

[DEDRICK]

CQP or CRF stands for Constant Quantization Parameter or Constant Rate Factor. Unlike CBR and VBR, there is no bitrate "limit".

In intra-frame encoding a single frame is split into hundreds of macroblocks (16x16 pixels typically), each macroblock is analyzed and encoded. So in CQP, it's a static value that tells the encoder "you are allow to remove x amount of info from a macroblock", per macro block, per frame, in order to maintain a constant level of quality.

This is why lower values yield larger file sizes, or higher quality, it removes less info per block so it requires more bitrate.

So for static scenes you will use very little bitrate to encode, for high motion scenes you will use an astronomical amount of bitrate in order to maintain the quality.

I have seen ranges from 8Mbps - 200Mbps+ for some scenes.

 

[DeMoN]

All the same thing

CQP and CRF are not the same. They work different.
CQP has a constant quantizer, while CRF uses dynamic quantizerfactors (targets the same quality per frame for an eye)
NVEnc has just CQP though.
__
Encode into NV12 with 709 matrix and limited range.

Also OBS has a bug with NVEnc and higher settings than NV12.
The bug is: for some reason it stays 4:2:0 color but upscaled via nearest neighbor to 4:4:4 or whatever you've chosen.
So what you get is is an video with every 2nd pixel being colorless.
__
Why the hell is in OBS the default matrix setting = 601?

 

[officiallxander]

Runnning game and capturing on the same pc. That's not how gpu bandwidth works. I appreciate the effort, but if you don't have a knowledgeable solution this discussion is only adding to my frustration. Gpu core clock has nothing to do with available bandwidth, and there is more to encoding than bandwidth usage.

I think my point was if youre trying to send 2.5gigbits at a full pixel scale per second to the GPU to process when its limited to 1.5 billion transactions a second, then you may be biting more than you can chew. no need to be condescending as we are all trying to help one another.

 

[Osiris]

Also OBS has a bug with NVEnc and higher settings than NV12.
The bug is: for some reason it stays 4:2:0 color but upscaled via nearest neighbor to 4:4:4 or whatever you've chosen.
So what you get is is an video with every 2nd pixel being colorless.

Not sure why you think that, i don't see every 2nd pixel being colorless when recording in 4:4:4.

 

[DeMoN]

Was it maybe fixed in some version? I can check again then. But last time it was the case with nvenc. with x264 it worked always.

 

[Rodney]

Quick test using a test pattern designed to identify if a signal is subsampled confirms that 4:4:4 works correctly: http://www.framecompare.com/screenshotcomparison/W6KPNNNX

 

[DeMoN]

But was it with nvenc?

 

[Rodney]

Yes

 

[DeMoN]

ok. then it apparently got fixed. I try myself later ;)