Advice for capturing in 60FPS Huffyuv or a modern equivalent?

[Cyber Akuma]

I don't stream, I just occasionally capture footage either just to store some moments I want to keep or just to upload a small clip to YouTube.

Because of this I don't need to encode on the fly, so usually I like to capture using codecs that don't actually encode the video much and just impact the cpu/gpu as little as possible to dump as much lossless un-encoded video as reasonably possible to software encode later.

I used to use Fraps for this as that's how it's own custom codec used to work, but it's pretty obsolete and useless nowadays. I am still new to using OBS in place of Fraps, and configuring it's capture settings to do this is one of the things I am trying to figure out.

I noticed that it only seemed to let me encode either by x264 software or NVENC, unless I enable more advanced settings and make it go through ffmpeg, at which point I get a ton of options. I also used to use Huffyuv as my capture codec before, but that's pretty old and outdated nowadays too... also from my understanding, Huffyuv only works with AVI containers (Though OBS seems to let me use it for MP4 containers, but not MKV, not sure if it will work outside of AVI though). I was wondering if there is any modern (hopefully somewhat smaller filesize too) version of Huffyuv to use with OBS? And if not, what would someone recommend I do to capture a temporary video intended to impact the CPU/GPU as little as possible and be as lossless as possible for the purposes of CPU-encoding it into something sane later?

 

[koala]

Choose simple output mode, and for recording quality choose lossless. This will encode your video with the utvideo codec, which can be seen as kind of successor of huffyuv.

However, if you use today's resolutions (1080p, 1440p, 2160p), the throughput of your hard disk may be a bottleneck and may cause stutter and lost frames. So record such material to SSD and not to a spinning disk.

Generally, the disadvantage of such huge file sizes isn't usually worth the small (not perceivable) quality loss of a nvenc-encoded video with "indistinguishable quality" of simple recording mode. Use Nvenc, if you have it. It's a great hardware encoder and makes recording invisible in terms of resource demand.

 

[Cyber Akuma]

However, if you use today's resolutions (1080p, 1440p, 2160p), the throughput of your hard disk may be a bottleneck and may cause stutter and lost frames. So record such material to SSD and not to a spinning disk.

Yeah, that's another thing that just occurred to me. According to my calculations, it would take around 350-420GB to record the video I want. (around 50-60 minutes at 1080p 60fps), I am not sure if my HDD can keep up with that.... or if OBS itself could even crash with a file that big. I know you can keep track of dropped frames while recording, but since the game will be full-screen I would have to do test recordings and see if there are any dropped frames after the fact, and I am not sure how to do that.

Generally, the disadvantage of such huge file sizes isn't usually worth the small (not perceivable) quality loss of a nvenc-encoded video with "indistinguishable quality" of simple recording mode. Use Nvenc, if you have it. It's a great hardware encoder and makes recording invisible in terms of resource demand.

I tried a test-recording with NVENC in non-lossless mode and it seemed to artifact quite a bit. The issue is this game demo I want to record footage of has a lot of fast movements and visuals, it's part of the reason I wanted to record it, to see if I can even capture and then encode it in any decent quality. Isn't multi-pass software encoding going to be higher quality than on-the-fly GPU encoding?

 

[koala]

Multi-pass encoding isn't able to magically compress a lossless image into the tiniest file. It's not intended for quality, it's mainly intended for CBR videos suited for streaming to better conform to the desired bitrate. By knowing in advance what complexity the next frames have, the encoder can adjust compression to exactly match the desired bitrate. It can plan ahead. With 1-pass encoding, the complexity of the next frames is estimated, and if it is estimated wrongly, the encoder may need to compress more than expected (if complexity increased unexpectedly) or less than expected (if complexity lowered unexpectedly), so the available bandwidth is not used optimally.

But if you want best quality for a recording, you don't use a bitrate-orientated rate control such as CBR at all. Instead, you use a quality-based rate control such as CQP, ICQ or CRF. These are chosen automatically by OBS for recording, if you use simple output mode.

These remove the same amount of detail regardless the motion, so the bitrate with high-motion scenes increases and the bitrate with low-motion scenes lowers - down to 0 bps if you have still images, with no perceivable quality impact, because there only the same image to show. These rate controls don't need multiple passes, because they don't have bitrate constraints.

 

[Cyber Akuma]

I see, thanks for that help. So then after I capture the lossless video it would be better to just do a single-pass constant bitrate encode in something like Handbrake like this?

 

[koala]

You're better if you're not convert into any constant bitrate encoding but instead in constant quality mode (CQP/ICQ/CRF), just as I wrote above.