'Lightweight' encoder for high bitrate video, 60 FPS, YUV444?

[antoniu200]

Hi,

I am getting me a Pioneer Blu-ray optical drive, since my (cheap) DVD drive just died a month ago after almost 10 years of use. Very excited for it, since blank BD-R discs are dirt cheap.

Now, I would like to use this optical drive to dump all of my large recordings, including game recordings, on Blu-ray, so I don't rely on YouTube for archival (Google Takeout).
When recording various gameplay on my computer, I was using, up until now, H264 NVENC, to spare my CPU the hassle, otherwise games would start lagging. Problem with this is the GPU is also not great at keeping the bitrate low enough, so I would have moments when the bitrate would go through the roof at 120Mb/s. I tried limiting it to 20M, but it seems to ignore the maxrate flag, even when bufsize is applied. I am using constqp as rate control, qp=20.
I would rather not use CBR, since I sometimes play games where there's not that much changing on the screen, so a lower bitrate does fine and will help decrease the file size.

I have upgraded my CPU since from a Xeon X5650 to a Ryzen 5 5500, so it should cope better, but still wouldn't risk it with H264, especially since H264 does well at low bitrates, rather than high ones

Is there any CPU encoder that has relatively low complexity (compared to H264), supports YUV444 (FFMPEG's MPEG2 seems not to) or RGB, does good at high bitrates and can deal with max bitrate of 20 Mbits/s?
Or is there any way I could optimize H264 for my needs?

1360x768 resolution
60 FPS

[Selur]

Anything with lower complexity will have offer worse compression ratios. (like most lossless or near lossless formats)
Since you got NVEncC, you could use NVEncC with H.265 which should offer better compression at the such resolutions than H.264. (depending on you card H.265 does support 4:4:4 encoding)

[antoniu200]

Anything with lower complexity will have offer worse compression ratios. (like most lossless or near lossless formats)

Yeah, I know. I don't need low file size or bitrate or anything. If retail 1080p Blu-ray discs come with MPEG2 streams at 20-30 Mb/s and they look the way they look, I would assume a 1360x768 source should do fine with a worse, but more lightweight algorithm than H.264.

Since you got NVEncC, you could use NVEncC with H.265 which should offer better compression at the such resolutions than H.264. (depending on you card H.265 does support 4:4:4 encoding)

Yeah, problem is my card is a GTX 980, so no support for 4:4:4 H.265 here, except on the CPU, which would be too intensive.

 
What features of H.264 should I disable to reduce its complexity? Or, better said, what are the most complex features of H.264 a high bitrate video would not exactly need (excluding QP)?

[Selur]

If retail 1080p Blu-ray discs come with MPEG2 streams at 20-30 Mb/s and they look the way they look, I would assume a 1360x768 source should do fine with a worse, but more lightweight algorithm than H.264.

retail mpeg-2 uses 4:2:0 so 12bit of raw information.
4:4:4 is 16bit data. So just sticking with 16bit increases the data that needs to be saved by 1/3.
Additionally, more than doubling the amount of pixels and increasing the frame rate also requires more data.
-> so be aware that lowering the options of the encoder might work against your resulting file size.

Or, better said, what are the most complex features of H.264 a high bitrate video would not exactly need (excluding QP)?

The complexity of the format doesn't really change.
What is your goal in lowering complexity?
Getting faster encoding or faster decoding, or something else?

Ryzen 5 5500 + Geforce 980, so hardware encoding isn't that interesting. (Hardware encoding without b-frames is often worse than using x264 with ultrafast preset.)
-> Have you tried x264 and x265 in their ultrafast presets and adjusting quality through a lower/higher crf value?

Cu Selur

Ps.: ProRes and other lossless formats that support 4:4:4 will be nowhere near mpeg-2 or H.264 compression ratios.

FFMPEG's MPEG2 seems not to

Naturally, since even high profile in MPEG-2 only supports 4:2:2.

[antoniu200]

retail mpeg-2 uses 4:2:0 so 12bit of raw information.
4:4:4 is 16bit data. So just sticking with 16bit increases the data that needs to be saved by 1/3.
Additionally, more than doubling the amount of pixels and increasing the frame rate also requires more data.
-> so be aware that lowering the options of the encoder might work against your resulting file size.

I just did a calculation. 1360x768x60x16 is actually above 1920x1080x23.97x12. And here I was thinking I was far below what Blu-ray has.

Well that changes things.
In that case, I'm ok with losing some quality as long as I can encode fast enough and keep the bitrate under or equal to 20M.

The complexity of the format doesn't really change.
What is your goal in lowering complexity?
Getting faster encoding or faster decoding, or something else?

Faster encoding, so I get less lag in games while doing so.

Ryzen 5 5500 + Geforce 980, so hardware encoding isn't that interesting. (Hardware encoding without b-frames is often worse than using x264 with ultrafast preset.)
-> Have you tried x264 and x265 in their ultrafast presets and adjusting quality through a lower/higher crf value?

Not until now, here are my codec options (using OBS to setup FFmpeg):

preset=ultrafast profile=high444 crf=17 tune=zerolatency maxrate=20000000 bufsize=40000000 pix_fmt=yuv444p hwaccel=auto opencl=true force-cfr=1

Unfortunately, with these options, the bitrate reached 44M at some point. Or is maxrate ignored when using CRF?

The CPU usage remained relatively low, 10% max. Also, with these options I think it's relevant to say B-Frames are also turned off.

EDIT: Forgot to mention, keyint is 600.

[Selur]

Not totally sure about how ffmpeg handles it, but normal x264 only respects buffersize&co if profile&level are set. You only specified the profile.
You probably might want to read up on vbv restrictions and read up on ffmpegs 'x264-params' instead of using maxrate and bufsize. The vbv readup is needed, so that you understand what that max bit rate really is meant to do, since it does not set an absolute maximum bit rate.
'opencl=true' <- is probably a bad idea if it enables the opencl support in x264, since the opencl support in x264 isn't really useful and sometimes even harmful.

[antoniu200]

Not totally sure about how ffmpeg handles it, but normal x264 only respects buffersize&co if profile&level are set. You only specified the profile.

Fixed

You probably might want to read up on vbv restrictions and read up on ffmpegs  'x264-params' instead of using maxrate and bufsize. The vbv readup is needed, so that you understand what that max bit rate really is meant to do, since it does not set an absolute maximum bit rate.

Read some on that VBV functionality, I believe I applied it properly below.

'opencl=true' <- is probably a bad idea if it enables the opencl support in x264, since the opencl support in x264 isn't really useful and sometimes even harmful.

Removed it, but not sure why it would be harmful?

---

Okay, this was the command I got to, but there was significant blockiness when movement appeared, almost like I was watching 6Mb/s 1080i50 streams on TV:

preset=ultrafast profile=high444 level=4 crf=17 tune=zerolatency maxrate=20M bufsize=20M x264-params=pix_fmt=yuv444p:hwaccel=dxva:force-cfr=1

Maybe if I dropped the preset to veryhigh, or somehow forced an Open GOP and interlacing, but I'm not sure it's worth it, since most of these will increase CPU usage and at this resolution games are CPU-bound, so it's already high enough.

I compared the above command to this H264 NVENC one and the results were far from comparable:

profile=high444p level=4 rc=vbr maxrate=20M bufsize=20M

Plus the GPU usage was very low for the quality of the output: 8%.
Maybe because I used VBR instead of CRF?

At this point I am not sure it's worth scratching our heads further, since I now have a good quality output file, while keeping the size low. Unless there is some way of setting the ildct and ilme flags for interlaced encoding, plus limiting the output fields to 60 from within the encoder, since OBS only outputs progressive by default, which is not possible, from my lookups.

Thanks for your time, you've been a big help, as always.