Question / Help Will overclocking CPU help?

[LGx]

I'm not streaming but recording gameplay. I've found a setting that I really like for output.

Quality balance - 10
No CBR
Max bitrate - 16,000
Default buffer size (custom unchecked)

1920/1080 60 FPS

Image of Advanced tab

While idle in my game, OBS uses 35% CPU when recording with these settings. This jumps to 70% usage when the game is at max load, and the game uses 25%. So I get stutters on playback.

I'll fallback on the settings if I have to. I'm just curious if I overclock my CPU, would it make a difference, enough to allow me to use these settings.

I have a pretty new 4690k and aftermarket cooler. I just never bothered to overclock it as I didn't need to. My GPU is an AMD 7850 2 GB.

Thanks in advance

 

[alpinlol]

please make sure to post a log

 

[LGx]

It's just a question, not an issue with OBS. Feel free to ignore my specific situation. I just want to know if overclocking a worthy CPU noticeably lowers usage during recording.

 

[alpinlol]

with that cpu its probably withing the 2-3% range so, not really.

wanted the log, maybe theres something to tweak

 

[LGx]

Thanks. I just turned the x264 CPU preset to "superfast" and it put me in a good place usage wise. I don't notice much of any quality loss, we'll see when after an upload to youtube with it.

 

[Sapiens]

Preset should have a negligible quality impact if you're following the steps at https://obsproject.com/forum/resources/how-to-make-high-quality-local-recordings.16/

 

[LGx]

Thanks for that. I didn't understand that guide as well my first time around though I did follow it before hand with huge CPU usage.

Well, with my original settings shown on the OP along with the superfast preset, I had much more consistent and lower usage with crf-14.

Now, following that guide with a quick stress test (in game) using crf-14 and superfast preset, it did much better than any settings I tried before my last post, but the CPU usage was higher and bouncing around a lot, it didn't hit 90% but the short playback showed a large stutter.

If I understand that guide correctly though, it's fail proof at getting the best quality my CPU can deliver. I guess that means I should stick with it and raise the crf one at a time until I get smooth playback.

I guess my problem was just not wanting to touch the x264 CPU preset as a lot of places I read about it said it's best to leave it at default, I also thought it would have a huge impact on quality at first.

Thanks everyone!

 

[Sapiens]

The point of configuring things that way is to let the encoder use whatever bitrate it needs to achieve your quality target (the opposite of streaming, where the bitrate is controlled and the quality fluctuates). When you follow the recording guide, the x264 preset affects output file size, not the quality. Using less compression by switching from veryfast to superfast or ultrafast will give you the same quality in a bigger file.

You could also use Quick Sync to put the encoding work on your iGPU instead.

 

[FerretBomb]

Yep, local recording normally uses Ultrafast and throws a bucket of bitrate at it, as hard drive space is cheap. And after you have the video done, you can always run it through a MUCH more efficient (and far slower) multi-pass re-encoder to get the filesize down to a much more reasonable level for long-term storage, sacrificing minimum quality loss.

 

[LGx]

@Sapiens Thanks for the explaining that further, I may try out the ultrafast preset to see the file sizes since the cpu usage is still a little high on superfast. I'm really interested in using my GPU for the encoding, I have an AMD 7850 though so I don't think it will be as simple as using Quick Sync (assuming it's simple). I'm currently reading this thread to try and figure out how to set it up and hopefully understand how it works as well. I'm curious if AMD VCE will share the encoding work with the CPU or if not, would it still be a better option than just using the CPU alone.

@FerretBomb Thanks. I was just uploading gameplay recordings directly to YT but I'm starting to want to mess with editing them some to add a little presentation. I actually did one recording in Sony Vegas to cut out a large 10 second freeze of video at the beginning. I still wonder why it was only at the beginning and why it only affected video and not audio. I'm guessing maybe my hard drive might have been in some power saving mode, or maybe something else was using my CPU.

Anyway, those re-encoding times scared me the hell away from doing that again, especially with the lagarith codec. If I have to though, I have to. Hopefully my file sizes won't be so big that I have to do multi-passes, you make a good point about long term storage though. If I do decide on using multi-pass re-encoding, do you know if Sony Vegas supports it and I might be asking the wrong question but if so, what codec would you recommend?

 

[LGx]

Also, the stickied thread about CPU usage has either wrong or misleading information. This is what put me off from changing the x264 presets at first.

For example, if you would like to try to reduce CPU usage without modifying your resolution or FPS, you can reduce your CPU usage by changing your x264 preset to superfast or ultrafast, and x264 will spend less time trying to make the image look good, and will spare you some CPU cycles. The image may look a bit blockier or pixelated, but you will be able to retain your resolution/fps.

Be very careful with this setting, because even one step faster or slower can have a huge impact on CPU usage.

 

[alpinlol]

Also, the stickied thread about CPU usage has either wrong or misleading information. This is what put me off from changing the x264 presets at first.

in which way? the information pretty much explains it if the presets gets faster you lose quality and will spare some cpu cycles (less cpu usage)

besides the explaining in the quote i must agree that the careful warning is misleading

 

[FerretBomb]

Yes, it doesn't mention that you can overcome the blocking by using more bitrate, because that thread is aimed at information about livestreaming, where you have a limited amount of realistic usable bitrate. OBS was designed first and foremost as a livestreaming tool... local recording is just extra functionality it happens to also perform.

When streaming, you want to be as efficient as possible as that bitrate is your main bottleneck; you need to do everything possible to preserve and use it as optimally as you can. Local recording only? You have tons.

Yes, re-compressing video is SLOW when you want to use good compression. Streaming uses good-enough... it's ridiculously low quality compared to most other forms of media, but it's the best that can be done in real-time, as video compression is an extremely computationally heavy task. When you give it a few hours to render (and recording-only, you have time to do so after you're done editing and whatnot) you can preserve much better quality thanks to not needing to deliver the video stream in real-time. Generally it becomes a 'kick it off before bed' type affair, and let the system crunch on it.