Best Bitrate for H.265 DCI 4K HDR?

Hello everyone. I would like to know what the best bitrate for DCI 4K HDR 10-bit at 23.98p would be for an upload to YouTube. The YouTube recommendations seem rather low and are for H.264, which doesn't seem to like HDR or 10-bit and is less efficient.

Some footage is 150Mb/s H.264 4:2:2 10-bit, some is 200Mb/s HEVC 4:2:2 10-bit. Should I render at the lowest common denominator (75MB/s H.265) or should I render closer to the higher bitrate footage (200MB/s H.265)? Maybe somewhere in between?

Sometimes I wish Resolve had a CQP or CRF option like OBS so I could just put in a quality number and let it do the magic, but the presets are broken for H.265, all being very low bitrate at 15MB/s...

If you want such settings use Handbrake.

200Mbit should be ok, assuming YT will transcode to something waaaay lower.

Sometimes I wish Resolve had a CQP or CRF option like OBS so I could just put in a quality number and let it do the magic, but the presets are broken for H.265, all being very low bitrate at 15MB/s...

Correct, VBR is garbage in Resolve. Export to DNxHR HQX and use Handbrake to compress to h.265 10bit.

Youtube will accept DNxHR directly, but I have never had an internet connection big enough for 5gbyte per minute uploads.

Hello everyone. I would like to know what the best bitrate for DCI 4K HDR 10-bit at 23.98p would be for an upload to YouTube. The YouTube recommendations seem rather low and are for H.264, which doesn't seem to like HDR or 10-bit and is less efficient.

Some footage is 150Mb/s H.264 4:2:2 10-bit, some is 200Mb/s HEVC 4:2:2 10-bit. Should I render at the lowest common denominator (75MB/s H.265) or should I render closer to the higher bitrate footage (200MB/s H.265)? Maybe somewhere in between?

Sometimes I wish Resolve had a CQP or CRF option like OBS so I could just put in a quality number and let it do the magic, but the presets are broken for H.265, all being very low bitrate at 15MB/s...

If you use at least 150Mbs and switch off optimise for speed and use main 10, you'll be good to go. Chances are you'll easily get away with a much lower bitrate depending on average scene/shot complexity etc.

At those bit rates/settings you wont see any visual difference between it and anything that's using X265 (handbrake etc.).

You may get lower bitrates using X265 for the same visual picture quality but your encode times will be stupid long.

I'm on M1 Max and the exports are at least as fast as the timeline, even up to 8K 29.97, so 23.976 will be at least as fast as your timeline.

Easiest thing to do is some 30 second test exports, upload them to YouTube and then guague from that.

These videos may help.

Thanks for all the replies guys! I will try Handbrake and see if I get any massive file savings there. If not, I will for sure try 150MB/s for my HDR projects. I notice that on YouTube, the difference in bitrate is not noticeable at all unless it is really low (like 15 MB/s that the horrible auto encoder uses). I will do some tests then to see what works best. Thanks!

Thanks for all the replies guys! I will try Handbrake and see if I get any massive file savings there. If not, I will for sure try 150MB/s for my HDR projects. I notice that on YouTube, the difference in bitrate is not noticeable at all unless it is really low (like 15 MB/s that the horrible auto encoder uses). I will do some tests then to see what works best. Thanks!

Once you are at high resolutions and frame rates the encoding bit rate of your upload file will definitely have an effect on YouTube's final encode quality. Using lower bit rates in general will definitely have an impact on final stream quality, breaking up of fine detail and blocking being the most visually obvious result of low bit rate uploads.

The exception here may be X265 but to acquire a comparatively visually similar final stream quality compared to a higher bit rate encode on a "lesser" encoder. The X265 variant will have to have more exhaustive analysis, for which the much longer encode time may negate any savings.

For anyone on M1 Max or M1 Pro, I would definitely recommend doing short tests at various bitrates using the hardware encoder for H.265 with the "Optimize for speed" option switched off. This will allow for a better guague of final overall visual quality. Average/maximum bit rates will be entirely dependent upon content complexity, resolution and frame rate. This will be the same workflow test for any encoder or delivery codec.

Reading around the forum there seems to be a general discouragement for using Resolve's own H.264/5 encoders. I'm assuming this is for Windows based workflows with software/CPU encoding, something that I'm not overly familiar with. However, the new M1 Max and M1 Pro hardware encoders are great and very fast. In scenarios where you are capable of real-time within timeline performance, a 4K UHD 60FPS project is capable of between 90 to 120 frames per second encode speed depending on the "Optimize for speed" setting.

Thanks for all the replies guys! I will try Handbrake and see if I get any massive file savings there. If not, I will for sure try 150MB/s for my HDR projects. I notice that on YouTube, the difference in bitrate is not noticeable at all unless it is really low (like 15 MB/s that the horrible auto encoder uses). I will do some tests then to see what works best. Thanks!

Once you are at high resolutions and frame rates the encoding bit rate of your upload file will definitely have an effect on YouTube's final encode quality. Using lower bit rates in general will definitely have an impact on final stream quality, breaking up of fine detail and blocking being the most visually obvious result of low bit rate uploads.

The exception here may be X265 but to acquire a comparatively visually similar final stream quality compared to a higher bit rate encode on a "lesser" encoder. The X265 variant will have to have more exhaustive analysis, for which the much longer encode time may negate any savings.

For anyone on M1 Max or M1 Pro, I would definitely recommend doing short tests at various bitrates using the hardware encoder for H.265 with the "Optimize for speed" option switched off. This will allow for a better guague of final overall visual quality. Average/maximum bit rates will be entirely dependent upon content complexity, resolution and frame rate. This will be the same workflow test for any encoder or delivery codec.

Reading around the forum there seems to be a general discouragement for using Resolve's own H.264/5 encoders. I'm assuming this is for Windows based workflows with software/CPU encoding, something that I'm not overly familiar with. However, the new M1 Max and M1 Pro hardware encoders are great and very fast. In scenarios where you are capable of real-time within timeline performance, a 4K UHD 60FPS project is capable of between 90 to 120 frames per second encode speed depending on the "Optimize for speed" setting.

Honestly it seems that they should update the encoders that are inside Resolve then because exporting to a large codec I will never use just to get reasonable file sizes and quality in Handbrake seems a bit nonsensical to me since I will never use DNxHR because everything I do is non-professional.

Not all hardware encoders are created equal. For those on the new M1 Macs, I'd do it from Resolve. Their hardware encoders are really good.
But if you can already spot a difference between an encode by Resolve and by Handbrake at comparable bitrates, I'd suggest Handbrake. Even if you need more time, the recompressed YT will look better.

Honestly it seems that they should update the encoders that are inside Resolve then because exporting to a large codec I will never use just to get reasonable file sizes and quality in Handbrake seems a bit nonsensical to me since I will never use DNxHR because everything I do is non-professional.

100% agree. But it seems everything Black Magic has done since V17 release has been about new showy features, not improving stability or base functionality.

Hell, they can't even be bothered to publish a supported codec list for V17. the newest if V16.

Honestly it seems that they should update the encoders that are inside Resolve then because exporting to a large codec I will never use just to get reasonable file sizes and quality in Handbrake seems a bit nonsensical to me since I will never use DNxHR because everything I do is non-professional.

BM uses OS/GPU provided codecs for h264/5, so they can't really do any updates. It's what it's.
Other option is to license some h264/5 engine (eg. Mainconcept one which is use by eg. Adobe), but then someone has to pay costs if it. No free version?
There are reasons why those export options are rather weak.

You can be total amateur, but you can still use ProRes or DNxHR. Not sure what 1 has to do with other.

MainConcept can be bought as an export plug-in. Makes sense for professional use and it's a clear indication that BM decided to use what the systems offer and leave the rest to third-parties.

Yes, forgotten about it. If you want more control in h265 export buy Mainconcept plugin (works only with Resolve Studio).

This mainconcept plugin looks interesting, seeing it is 99 dollars for a lifetime subscription. But, does it bring anything apart from being easier? Handbrake is free, and rendering is done when I am away from my pc.

Works directly from Resolve timeline- this is main beauty.
Gives you up to 8K h265 8/10bit and many broadcast formats: XDCAM, P2 etc. (for some people this is also important).
Check trial before you buy.

Honestly it seems that they should update the encoders that are inside Resolve then because exporting to a large codec I will never use just to get reasonable file sizes and quality in Handbrake seems a bit nonsensical to me since I will never use DNxHR because everything I do is non-professional.

BM uses OS/GPU provided codecs for h264/5, so they can't really do any updates. It's what it's.
Other option is to license some h264/5 engine (eg. Mainconcept one which is use by eg. Adobe), but then someone has to pay costs if it. No free version?
There are reasons why those export options are rather weak.

You can be total amateur, but you can still use ProRes or DNxHR. Not sure what 1 has to do with other.

I understand. The only thing though is that not many of my videos are worth the hassle of transcoding from a larger codec because the source files are already 8-bit H.265 from the GoPro, 8-bit XAVC-S from Sony A7RIV, and 10-bit 4:2:2 H.264 from the Panasonic S5.

It seems from tests that I would be getting a 3x file savings from using Handbrake instead (at the same perceptual quality), but at the cost of having a 100GB file sitting on the computer while it's transcoding (DNxHR HQ, DNxHR HQX would be so much larger when I am doing HDR), and encoding time being 5x longer since it is CPU based.

Is the new Native H.265 encoder any good? I saw that pop up in the last update and it apparently uses CPU like Handbrake.

Native h265 is not CPU based. It's GPU one.

It all depends what you want to do. If you want small final files then there will be always a need for good h264/5 encoder and there is no escape form it. For work in progress big(er) files are not that big deal as storage is relatively cheap now.
Mainconcept plugin should give you fairly good h265 straight from timeline.
You also have Vukoder Voukoder plugin which is based on x264/5, so same as Handbrake. It should serve your needs well.

Excuse me, I think it's Voukoder. And it's free. Windows only.

You don't need these super large intermediates. NVENC H256 10bit with 0 or single digit CQ values makes a good intermediate for further encoding and is very fast.

Also modern NVENC is roughly equivalent to x264 / x265 preset medium in terms of efficiency. So no, you don't get 3x file size saving. Not at all.

And with 17.4.4 encoding of H.265 in 4:2:2 and 10 bit flies on M1.

And with 17.4.4 encoding of H.265 in 4:2:2 and 10 bit flies on M1.

Hopefully they optimize it for PC too. My Mac is way less powerful than my GTX 1080 on my desktop. It does NR at around 0.5fps while my desktop does it at 4.

BM can't do much about that. It's hardware based.