x265 options for reencoding UHD HDR BD (saving space) in 2025

[Stereodude]

I did search before posting this thread, but I did not find consistent suggestions as the threads got newer and presumably x265 was refined. I also didn't find any recent threads (though I'm not sure how much x265 is changing over time).

With the latest builds of x265 in early 2025, what is the general guidance for what options to use for x265?

I've done lot of SDR encoding, but never HDR. I see that DGDecNV will give me a command line with the HDR and colorimetry data to use to duplicate those of the the source like:

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "930,197" --frames 190824 --chromaloc 2

For standard HDR10 is it just a matter of picking the crf that gives me the picture quality/file size I'm after, or are there other essential command line options like --hdr10-opt that should be used or other helpful command line options for x265 that will optimize 2160p HDR encoding, like maybe AQ Mode 4?

FWIW, my intention is to attempt some noise reduction (of grain) with AVIsynth ahead of the encode.

Edit: I'm also aware that HDD drive space is likely cheaper than the electricity to do this, but I'm curious and want to play around and am looking for a good starting point.

[microchip8]

Add --hdr10-opt to cmdline. Other than that, there isn't much else for simple HDR10.

[Stereodude]

Thanks! Does HDR10 material still require a CRF that's about 4 units closer to zero than SDR material to get roughly the same level of visual performance or is that dated advice?

[excellentswordfight]

Originally Posted by Stereodude

Thanks! Does HDR10 material still require a CRF that's about 4 units closer to zero than SDR material to get roughly the same level of visual performance or is that dated advice?

With the --hdr10-opt option, I would say its more like 2.

[Z2697]

hdr10-opt is done like this in the same place as AQ (apply some shift to the AQ adjustment based on the avg luma value of the block)

                            if (lumaAvg < 301)
                                qp_adj += 3;
                            else if (lumaAvg >= 301 && lumaAvg < 367)
                                qp_adj += 2;
                            else if (lumaAvg >= 367 && lumaAvg < 434)
                                qp_adj += 1;
                            else if (lumaAvg >= 501 && lumaAvg < 567)
                                qp_adj -= 1;
                            else if (lumaAvg >= 567 && lumaAvg < 634)
                                qp_adj -= 2;
                            else if (lumaAvg >= 634 && lumaAvg < 701)
                                qp_adj -= 3;
                            else if (lumaAvg >= 701 && lumaAvg < 767)
                                qp_adj -= 4;
                            else if (lumaAvg >= 767 && lumaAvg < 834)
                                qp_adj -= 5;
                            else if (lumaAvg >= 834)
                                qp_adj -= 6;

which doesn't sound that interesting, I mean the low light content just always gets higher qp, but those are actually a major part of the content, not to mention that some studio just loves everything dark.
So yeah I'd say you should lower the CRF by some amount... but then maybe you get too many bits spent in high light level parts.

Personally, I think the low light shift is somewhat unideal, but high lights, they are very compressed in the QP curve, so they should deserve more bits, I guess.

[benwaggoner]

That should work pretty well for clean content. Noisier content can benefit from some --nr-inter and -1 for the chroma qp offsets.

[benwaggoner]

Originally Posted by Z2697

hdr10-opt is done like this in the same place as AQ (apply some shift to the AQ adjustment based on the avg luma value of the block)

                            if (lumaAvg < 301)
                                qp_adj += 3;
                            else if (lumaAvg >= 301 && lumaAvg < 367)
                                qp_adj += 2;
                            else if (lumaAvg >= 367 && lumaAvg < 434)
                                qp_adj += 1;
                            else if (lumaAvg >= 501 && lumaAvg < 567)
                                qp_adj -= 1;
                            else if (lumaAvg >= 567 && lumaAvg < 634)
                                qp_adj -= 2;
                            else if (lumaAvg >= 634 && lumaAvg < 701)
                                qp_adj -= 3;
                            else if (lumaAvg >= 701 && lumaAvg < 767)
                                qp_adj -= 4;
                            else if (lumaAvg >= 767 && lumaAvg < 834)
                                qp_adj -= 5;
                            else if (lumaAvg >= 834)
                                qp_adj -= 6;

which doesn't sound that interesting, I mean the low light content just always gets higher qp, but those are actually a major part of the content, not to mention that some studio just loves everything dark.
So yeah I'd say you should lower the CRF by some amount... but then maybe you get too many bits spent in high light level parts.

Personally, I think the low light shift is somewhat unideal, but high lights, they are very compressed in the QP curve, so they should deserve more bits, I guess.

hdr10-opt is helpful overall, although could benefit from a strength parameter for per-title tuning.

Most HDR-10 content doesn't normally have many pixels in the high light level parts in general. In common content lots of frames won't have any pixels >100 nits, with detail clustered in the bottom half of the code range.

This content has its brightest single pixel at 930 nits and the brightest frame's being overall 197 nits. I'd expect a pixel >300 nits to be present in maybe 10% of the runtime max with those numbers.

Given most consumer HDR TVs will ramp-and-clamp well below 1000 nits nominal (as the picture modes boost peak brightness beyond what the panel can actually display), there's rarely a visible difference between a specular highlight at 800 nits versus 4000 nits. Sure, in Filmmaker Mode on a high-end QLED in a dark room, but that's not a common setup.

[Z2697]

Originally Posted by benwaggoner

hdr10-opt is helpful overall, although could benefit from a strength parameter for per-title tuning.

Most HDR-10 content doesn't normally have many pixels in the high light level parts in general. In common content lots of frames won't have any pixels >100 nits, with detail clustered in the bottom half of the code range.

This content has its brightest single pixel at 930 nits and the brightest frame's being overall 197 nits. I'd expect a pixel >300 nits to be present in maybe 10% of the runtime max with those numbers.

Given most consumer HDR TVs will ramp-and-clamp well below 1000 nits nominal (as the picture modes boost peak brightness beyond what the panel can actually display), there's rarely a visible difference between a specular highlight at 800 nits versus 4000 nits. Sure, in Filmmaker Mode on a high-end QLED in a dark room, but that's not a common setup.

Yeah, the problem with hdr10-opt is that it's too simple.
I think the frame average and peak should also be taken into account, but that's probably gonna reduce the performance.

[Stereodude]

Originally Posted by benwaggoner

That should work pretty well for clean content. Noisier content can benefit from some --nr-inter and -1 for the chroma qp offsets.

What's your definition of noisier content? How much grain/noise are we talking about? I presume it's something well short of Moneyball.

[Stereodude]

Originally Posted by benwaggoner

Given most consumer HDR TVs will ramp-and-clamp well below 1000 nits nominal (as the picture modes boost peak brightness beyond what the panel can actually display), there's rarely a visible difference between a specular highlight at 800 nits versus 4000 nits. Sure, in Filmmaker Mode on a high-end QLED in a dark room, but that's not a common setup.

I'm after 4000 nits (or more) in my next TV. That and 98-100".

[benwaggoner]

Originally Posted by Z2697

Yeah, the problem with hdr10-opt is that it's too simple.
I think the frame average and peak should also be taken into account, but that's probably gonna reduce the performance.

x265 already calculates per frame min/mean/max luma and chroma (you get them in --csv-log-level 2), so it shouldn't impact performance much.

[benwaggoner]

Originally Posted by Stereodude

I'm after 4000 nits (or more) in my next TV. That and 98-100".

As long as you're cool with very little content actually hitting 4000 nits. "Inside Out" is the most notable exception.

[Stereodude]

Originally Posted by benwaggoner

As long as you're cool with very little content actually hitting 4000 nits. "Inside Out" is the most notable exception.

It's fine that there isn't much content that hits 4000 nits. It means there is plenty of spare brightness for backlight strobing and other things to improve motion too.

[Z2697]

Originally Posted by benwaggoner

x265 already calculates per frame min/mean/max luma and chroma (you get them in --csv-log-level 2), so it shouldn't impact performance much.

I just imagined that they might not be available at the AQ step, gonna have a deeper look...

update: oh, I think they are from input, great! (PicYuv::copyFromPicture)

[benwaggoner]

Originally Posted by Stereodude

It's fine that there isn't much content that hits 4000 nits. It means there is plenty of spare brightness for backlight strobing and other things to improve motion too.

Yeah, a brighter peak display is able to get more saturation out of its color gamut in the midrange as well. Which is why you could actually get decent-ish HDR out of those early Rec. 709 400 nit displays; you could have a lot more saturation at 80 nits that nominal Rec. 709 with 100 nit peak could.

[benwaggoner]

Originally Posted by Z2697

I just imagined that they might not be available at the AQ step, gonna have a deeper look...

update: oh, I think they are from input, great! (PicYuv::copyFromPicture)

Yeah, that data is quite useful in determining how to do AQ properly.

[Z2697]

Originally Posted by benwaggoner

Yeah, that data is quite useful in determining how to do AQ properly.

They are only calculated if

param.csvLogLevel >= 2 || param.maxCLL || param.maxFALL

[benwaggoner]

Originally Posted by Z2697

They are only calculated if

param.csvLogLevel >= 2 || param.maxCLL || param.maxFALL

Huh. Interesting they call them those, because maxCLL and maxFALL's units are in nits, but the min/mean/max Y, U, and V are in code values. It'd be really handy if x265 could actually generate accurate static HDR metadata!

(unfortunately, as the Y in YCbCr isn't quite luminance, accurate values can only determined by converting every pixel into RGB and measuring those).

[Z2697]

after some "funny" tests I think dark biased AQ(s?) is sort of enough to compensate for that low light QP offset by hdr10-opt

[benwaggoner]

Originally Posted by Z2697

after some "funny" tests I think dark biased AQ(s?) is sort of enough to compensate for that low light QP offset by hdr10-opt

so --aq-mode 3 --hdr10-opt?