On x264, once you're using higher bitrates / lower CRF values (~CRF14), does the usage preset (fast, slow, etc) contribute much if anything?

[WarMom]

Title says it all I suppose? Or at least, most of it.
I run a Ryzen 3900X and usually CPU encode because my GPU (GTX1660) is usually quite pushed to the max, and though I know NVENC is on its own dedicated chip, if I'm only just managing to run the game as I desire leaving some OBS overhead, recording on NVENC can introduce some issues on OBS side, and slow down my performance a tad, making the framerate inconsistent which of course exacerbates the problems. If I'm playing a console game, well, I have enough CPU to spare to straight up run x264 slow.

But the question is, does that actually matter? It's largely well established that past 'fast', the gains for slowing down the CPU usage preset are well into diminishing returns past fast, but also differences between encoders normalise around 10,000kbps bitrates and above. What about, however, if you're running at good quality local recording settings on x264 - with enough bits to go around, can you drop the preset to faster ones with next to no, if any, loss at all?

I record at CRF14 (1440/60 unless it's a console game), and if I'm also simultaneously playing, it depends on game but generally CRF14 faster leaves some CPU headroom, but CRF14 fast can max out the CPU and of course then you get encoding overload and the game dropping frames. I did record some footage at CRF14 fast and faster of the same game, look and visually at least I probably wouldn't notice any difference unless I pixel-peeped some fast moving particle effects. The bitrates (variable of course, but per win10 properties) were also nigh-identical, definitely diminishing returns for the CPU usage uptick.

So then I wonder 'is even faster overkill? Does the preset effectively mean nothing if there's enough bits to go around and dropping it further can save me some usage and temperatures with next to no drop in quality?'

What are your experiences with usage presets at higher bitrates / lower CRF values? Thanks in advance!

 

[Deleted member 121471]

In theory, slower presets reduce the resulting filesize at the cost of higher computational requirements. In practice, diminishing returns hit really hard.

Personally, the "faster" preset has been more than sufficient for recordings, since there's no real bitrate limitations and the filesize savings compared to "very fast" are significant enough without adding that much extra stress to the encoding hardware.

 

[WarMom]

Oh, that's interesting, I had always associated slower usage presets with higher quality, albeit that was in a context of CBR at lower, twitch-compatible bitrates.
I'm in no real worry about file sizes, so if I was to jack the usage speed preset up to veryfast or superfast (say for example I start running a game where 'faster' is at risk of maxing out the CPU / causing performance issues), running at CRF14, would I still get identical (or nigh identical) quality at the expense of larger files? I could totally live with that.

 

[Deleted member 121471]

If it helps, when I record at CRF 18, compared to "very fast", "Superfast" is around 33% larger filesize and "faster" is around 20% smaller.

 

[WarMom]

Those are some good metrics, thank you, I'll keep those in mind, Veryfast might be a sweet spot to leave some headroom - and in these cases, they all look (at least in a normal, not-pixel-peeping scenario) very much the same quality?

 

[Deleted member 121471]

"Very fast" is the default for that reason. CRF or CQP should almost guarantee identical quality throughout a recording, it's really only a matter of filesize vs encoding load. One can always reencode the resulting file with slower presets and other encoding options, for long term storage.

Streaming with CBR or recording to diskspace contrained storage are where higher presets really matter.

Other than all this, if you post a logfile with a recording session, there may be additional suggestions that could be made.

Please post a log with your issue! Here's how...

OBS Studio creates a log file each time you run it which contains very useful diagnostic information. Without a log file, it's much harder for any support volunteers to figure out problems and your post may be ignored. To upload a log file, go to the Help menu > Log Files > Upload Last Log...

obsproject.com

 

[WarMom]

Thank you so much for your input, that's really helpful! I'll muck around with faster presets and re-encoding with ffmpeg after the fact. Thanks so much, I understand presets a good bit better now.

 

[FerretBomb]

On a side note, NVENC is a separate part of the GPU die. So long as you aren't using Max Quality, Psychovisual Tuning, or Lookahead (which all use CUDA cores) the in-game impact of using NVENC is zero. It uses absolutely no application-rendering resources at all (at least beyond the timeslices OBS needs for framebuffer access, color conversion, scaling, compositing, etc that would already be incurred by using OBS at all).

And NVENC on Turing/Ampere (as on that 1660) punches in the same weight class as x264 Slow. It's kind of a waste to hammer your CPU like that, when you can have near-identical encoding quality/filesize effectively for free.

 

[WarMom]

On a side note, NVENC is a separate part of the GPU die. So long as you aren't using Max Quality, Psychovisual Tuning, or Lookahead (which all use CUDA cores) the in-game impact of using NVENC is zero. It uses absolutely no application-rendering resources at all (at least beyond the timeslices OBS needs for framebuffer access, color conversion, scaling, compositing, etc that would already be incurred by using OBS at all).

And NVENC on Turing/Ampere (as on that 1660) punches in the same weight class as x264 Slow. It's kind of a waste to hammer your CPU like that, when you can have near-identical encoding quality/filesize effectively for free.

Appreciate the heads-up! I have known that NVENC is a separate chip, but it just didn't line up with my experience - when the GPU was very strained to begin with, NVENC would just pump out videos that stuttered and stammered a lot more, with encoding overload popping up in the UI.

What I didn't know was that NVENC is considered equivalent to actual slow at higher bitrates. I'll definitely consider that in the future, especially as I start toying around with HEVC encoding via StreamFX and now that I've toned down the settings in the particular game that really pushed the GPU.

 

[FerretBomb]

Appreciate the heads-up! I have known that NVENC is a separate chip, but it just didn't line up with my experience - when the GPU was very strained to begin with, NVENC would just pump out videos that stuttered and stammered a lot more, with encoding overload popping up in the UI.

What I didn't know was that NVENC is considered equivalent to actual slow at higher bitrates. I'll definitely consider that in the future, especially as I start toying around with HEVC encoding via StreamFX and now that I've toned down the settings in the particular game that really pushed the GPU.

If you ever get the 'encoder overloaded' message while using NVENC, you have one or more of those three options enabled. NVENC even on the older Pascal core can encode two 4K60 streams simultaneously without issue, and with room to spare. Graphic load will have no effect whatsoever, so long as Max Quality, Psychovisual Tuning, and Lookahead are not in use.

It isn't just at higher bitrates. Per VMAF testing, Turing/Ampere consistently turn out encoding quality either a few points better or worse than x264 Slow... they trade off by a few points depending on the content being encoded.
Essentially there is no longer any point in having a 2PC setup, outside of a very few edge case scenarios (primarily e-sports professionals, whose sponsors will just hand them both machines anyway).

 

[Nass86]

To the original poster. I noticed you said you were using CRF 14.

If you are recording to upload to YouTube, Facebook etc they apparently compress all videos after you upload them, to look no better than the CRF 22 (or CQP 22 on NVENC set to “Max Performance” NOT Max Quality) so we can waste our time stressing a GPU out on 18, 16, 14 etc and never give our audience the benefit. Meanwhile ending up with massive file sizes and waiting longer to upload them.

If that is the case, if I were you I would be trying:

- NVENC
- CQP 22
- Max Performance

Max Performance and Max Quality apparently don’t make a difference to the recording when using CQP, but the difference in file size and GPU resources being freed up is massive.

Try the three options “off” as suggested above. However I suspect you could get away with adding in psycho visual tuning and test that with CQP at 22. Not necessary to have it but you might get an ever so slightly better result. Who knows - maybe you could get Lookahead on too.

 

[FerretBomb]

The problem with that is that it goes through a RE-encode on upload. So the worse quality you send, the worse the re-encode will be.
It's also generally not worth using Max Performance; the load delta is minimal-to-zero between MP and Quality. Max Quality should never be used; it enables 2-pass which isn't meant for live video encoding, uses CUDA cores, and can cause encoding overloads. Use Quality instead. Max Performance will just result in larger files for no good reason.

Strongly advise AGAINST recording CQP 22 if your video will be re-encoded (after editing, or forcibly by YouTube). The better quality you send, the less severe the re-encode artifacting will be. It's not just going to slap up whatever you send it if you use CQP 22, after all. And the lower quality that 22 contains will just make even more of a mess of it at the end.

 

[Nass86]

Hey thanks for explaning.

I'm confused though (easily done) - I read somewhere else that specifically on CQP people are making the mistake of thinking Quality or Max Quality is doing something good when with CQP it has no effect so best to put it on Max Performance.

Comparing two videos (Nvenc) I would say the quality stayed the same, too but it really freed up the GPU a lot.

But you're saying CQP and Quality is on the money?

 

[Deleted member 121471]

CQP Rate Control, Quality preset, Lookahead and Psycho Visual Tuning Disabled, B-frames set to 2. This covers nearly 100% of encoding issues while maintaining as high quality as possible.

Concerning Youtube uploads, it makes sense that higher CQP or CRF values have apparently the same quality as lower values, there's more noise introduced.

Test uploading a lower value CQP or CRF encoded video without denoising or even adding a bit of noise and see how the encoding quality done on youtube improves a bit, specially on gradients (less to no banding).