x265 HEVC Encoder

[Boulder]

I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled

Thanks, I need to test that change. I also noticed a severe slowdown when testing HME at its default values and with merange 32. This is with basically settings from preset 'slower' with only a few minor changes.

[microchip8]

Thanks, I need to test that change. I also noticed a severe slowdown when testing HME at its default values and with merange 32. This is with basically settings from preset 'slower' with only a few minor changes.

I don't use presets but my own settings which I'm satisfied with. Here are my libx265 ffmpeg settings


X265PARAMS="ref=4:me=umh:hme=1:hme-search=umh,umh,umh:bframes=6:rd=4:subme=4:merange=26:strong-intra-smoothing=0:ctu=32:sao=0:cu-lossless=0:cutree=1:fades=1:tu-inter-depth=3:tu-intra-depth=3:rskip=1:max-merge=1:rc-lookahead=60:aq-mode=1:aq-strength=1.0:rdoq-level=1:psy-rdoq=1.5:psy-rd=2.3:limit-modes=1:limit-refs=3:limit-tu=1:rd-refine=0:deblock=-3,-3:weightb=1:weightp=1:rect=1:amp=0:wpp=1:pmode=0:pme=0:b-intra=1:b-adapt=2:b-pyramid=1:tskip-fast=0:fast-intra=0:early-skip=0:min-keyint=24:keyint=240"

[Boulder]

Biggest differences seem to be ref=5, me star, rd=6, rd-refine, strong-intra-smoothing, max-merge=4 and amp in my settings. I don't think those should affect the search for motion though. I really need to test to get some rough values.

[aegisofrime]

I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled

I was using the default ME range of 57. I guess it needs to be dropped once HME is enabled.

I can't wait to get a 3900X or a 16 core Threadripper!

[microchip8]

Biggest differences seem to be ref=5, me star, rd=6, rd-refine, strong-intra-smoothing, max-merge=4 and amp in my settings. I don't think those should affect the search for motion though. I really need to test to get some rough values.

you're maxing out a few things. rd=6 (combined with rd-refine) is IMHO overkill if you want to compromize between speed and quality

Motion Estimation is where the encoder spends most of its time and takes the biggest penalty the higher you get. rd=6 is very expensive. I'm fine with rd=4 (which is really rd=3 as 4 maps to it)

This is the best I can do on my i7 7700K when turning on HME. I don't want to wait days for an encode to finish and I won't see the difference when watching from afar on the TV

With my settings above and HME turned on, I can shave ~100 MiB of an encode. Encoded Blade Runner once with and once without HME. The result was 100 MiB in size reduction with better subjective quality when HME is on

[Boulder]

Here are my results with my Black Sails testclip, 2748 frames @ CRF 18:

rd 6, no hme - 4333,39 kbps - 2.91 fps
rd 6, hme umh - 4323,63 kbps - 2.16 fps
rd 4, no hme - 4149,59 kbps - 3.95 fps
rd 4, hme umh - 4154,60 kbps - 2.66 fps

So the difference with rd=4 is even bigger than with rd=6 + rd-refine. I'm using a Ryzen 1800X @ 3.8 GHz.

[microchip8]

Here are my results with my Black Sails testclip, 2748 frames @ CRF 18:

rd 6, no hme - 4333,39 kbps - 2.91 fps
rd 6, hme umh - 4323,63 kbps - 2.16 fps
rd 4, no hme - 4149,59 kbps - 3.95 fps
rd 4, hme umh - 4154,60 kbps - 2.66 fps

So the difference with rd=4 is even bigger than with rd=6 + rd-refine. I'm using a Ryzen 1800X @ 3.8 GHz.

I have the opposite experience. rd=6 is too costly here. But, the tests I did were a long time ago so I'll retest again soon

[Boulder]

Of course, it could be AVX2 which is making the difference here. On a first generation Zen CPU, it's more useful to disable it (as I've done). I'd expect an Intel CPU to benefit from AVX2.

[microchip8]

I've reported the segfault when using star for hme-search Level 0 to the x265 devs. One of them came with a patch which I tested and seems to work. Patch is not committed yet but you can find it at https://mailman.videolan.org/pipermail/x265-devel/2019-July/012601.html

[DJATOM]

Sweet, thanks.

[Natty]

using --dither and happy that it dithers properly. amazing results. but I want to know which dithering method it uses? and what does it use when this flag isn't enabled?

thanks.

[Barough]

x265 v3.1+10-459d3822c608 (http://www.mediafire.com/file/nnxk5mj74ww3741/x265-3.1%252B10-459d3822c608_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

There was a comment in the sources in previous versions. From a former issue report: (https://bitbucket.org/multicoreware/x265/issues/255/dither-option-in-the-command-line-produces)
The dithering algorithm is based on Sierra-2-4A error diffusion.

Without dither, it will probably just strip off less significant bits (but not sure).

[Natty]

There was a comment in the sources in previous versions. From a former issue report: (https://bitbucket.org/multicoreware/x265/issues/255/dither-option-in-the-command-line-produces)


Without dither, it will probably just strip off less significant bits (but not sure).

nice its same as x264 then. i read about this. its similar to floyd. clears my confusion why grain particles were looking finer than ordered, but not as fine as floyd. :thanks:

[Barough]

x265 v3.1.2+1-76650bab70f9 (https://www.mediafire.com/file/asn09rfxt1zaumj/x265-3.1.2+1-76650bab70f9_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)
https://bitbucket.org/multicoreware/x265/commits/

[LigH]

Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

https://www.ligh.de/pics/x265branches.png

[filler56789]

Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

https://www.ligh.de/pics/x265branches.png

Yeah, it's becoming a mess :-/

[LigH]

So, at the moment, users have to decide between either branch until a merge may happen...

[nevcairiel]

So, at the moment, users have to decide between either branch until a merge may happen...

From your screenshot of the history, I don't see any commit that is only on the 3.1 branch thats not also on the default branch. After the earlier fixes there was a merge back to default (through stable), and the later fixes are simply on both branches.
Of course you still have to decide which branch you want, thats why branches exist. If all were identical, what would be their point? The full development "default" branch, or the possibly more stable 3.1 release branch?

[Boulder]

I tested HME some more, and got quite interesting results.

Source 1080p filtered with my standard methods and downsized to 720p, merange 26 and my standard settings in x265. 1000 frames.

umh,umh,umh 2.05 fps / 5313,76 kbps
umh,umh,star 2.24 fps / 5314,31 kbps
umh,star,star 2.00 fps / 5327,91 kbps
star,star,star 2.01 fps / 5316,15 kbps
hex,umh,umh 2.03 fps / 5299,69 kbps

no HME, umh 2.64 fps / 5323,86 kbps
no HME, star 2.79 fps / 5325,69 kbps

I'll make the same tests with some different clip to see if the difference simply occurs because of the source.

[MeteorRain]

So, at the moment, users have to decide between either branch until a merge may happen...

It's dev & stable branches strategy, except that instead of constantly merge stable to dev, they cherry pick (or duplicate) bug fixes onto dev branch.

It's literally the same thing as before, just in a different way.

[LigH]

Okay, I may have missed that some patches were applied to both branches.

The only problem here for casual builders using automated build suites: How shall the suite know which branch the user prefers? It cannot rely on "tip" pointing to either. May the author of such a suite have to add a choice in its configuration?

[nevcairiel]

The concept of "tip" in mercurial is flawed anyway, would never rely on it. Someone pushed an experimental half-broken branch, and suddenly thats the tip? Clearly not what everyone wants to build off of. The "most recent change" seems like a particular worthless point of reference to use.
You should always be aware of what branch you build from.

[mandarinka]

I tested HME some more, and got quite interesting results.

Source 1080p filtered with my standard methods and downsized to 720p, merange 26 and my standard settings in x265. 1000 frames.

umh,umh,umh 2.05 fps / 5313,76 kbps
umh,umh,star 2.24 fps / 5314,31 kbps
umh,star,star 2.00 fps / 5327,91 kbps
star,star,star 2.01 fps / 5316,15 kbps
hex,umh,umh 2.03 fps / 5299,69 kbps

no HME, umh 2.64 fps / 5323,86 kbps
no HME, star 2.79 fps / 5325,69 kbps

I'll make the same tests with some different clip to see if the difference simply occurs because of the source.

I tested HME (with umh/umh/umh, merange 92, against umh with same merange) on some cel anime bluray footage with motion (both full camera motion and objects in scene only motion).

I got notably decreased SSIM score with HME, so be careful, at these low resolutions it looks like it is possible that HME doesn't help but harms.
Why? The first ME pass with merange 92 is done on 4X downscale. So if you have 1080p resolution, you are down on 240p. It is likely that small objects won't get tracked properly at this stage. After that, the second (480p) and last (1080p) ME stage only only lower merange (search distance), I assume? So if the large downscaling fools the first pass, the second and third stage might not be able to correct it.

My footage was 1440x1080 and you would have even worse situation at 720p. Basically this factor may cause HME to be counter productive unless you use it on 4K for which ts was intended (IIRC).

"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16
--pass 2 --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me star --subme 7 --merange 92 --amp --rect --ref 6
--weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.7
--no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless
--lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 5108.02s (0.17 fps), 10064.24 kb/s, Avg QP:19.49, SSIM Mean Y: 0.9820175 (17.451 dB)


"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16
--pass 2 --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me umh --subme 7 --merange 92 --amp --rect --ref 6
--weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.7
--no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless
--lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 11135.11s (0.08 fps), 10064.75 kb/s, Avg QP:19.49, SSIM Mean Y: 0.9820200 (17.452 dB)

"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16
--pass 2 --hme --hme-search umh,umh,umh --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me umh --subme 7
--merange 92 --amp --rect --ref 6 --weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5
--qcomp 0.7 --no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree
--cu-lossless --lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 7319.99s (0.12 fps), 10051.98 kb/s, Avg QP:19.52, SSIM Mean Y: 0.9819607 (17.438 dB)

p.s. Ignore the fps values, they are not indicative of the speed due to background cpu usage, system sleeping for a time and so on.

BTW, it would be interesting to determine what is the speed hit of a particular HME setting and then determine how much do you need to increase merange for the normal search mode to get at the same FPS - and then comapre the quality/SSIM. Because obvioously the added computation time could be used to improve quality by just increasing merange too, so that is your reference point for comparisons.

Edit: one other thing. Doing two-pass testing smaples, I found that just switching ME method between star and umh changes content of each frame and block quite a bit due to various indeterministic things going on. Individual frames would look worse and better based on how the rate control stars aligned.
So don't compare the results just by bitrate they give you!
It is quite possible the two files are not the exactly same quality, which would skew your judgement completely.

[Boulder]

Isn't it the other way around so that the first pass is made at full resolution and then the result is used as a predictor for the next pass which is done after downscaling. I agree that small details could well be lost when downscaling. The code seems to set the limit to use HME at 540 pixels of vertical resolution.

What I was wondering with those results of mine was that umh,umh,star was noticably faster than any other combination.

[benwaggoner]

Is there a build which includes the --aq-mode 4 patch? I've tried the latest ones here, and I keep getting:
C:\Users\benwagg\Desktop\x265>C:\Users\benwagg\Desktop\x265\x265.exe --input D:\Rights_Cleared_Sources\TearsofSteel_1920x800p24.y4m --preset slower --crf 28 --aq-mode 4 -F 1 --min-keyint 72 --keyint 120 --no-open-gop D:\TearsOfSteel\ToS_aqm4_crf28.hevc
y4m [info]: 1920x800 fps 24/1 i420p8 frames 0 - 17619 of 17620
raw [info]: output file: D:\TearsOfSteel\ToS_aqm4_crf28.hevc
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [error]: Aq-Mode is out of range
x265 [error]: failed to open encoder

[mandarinka]

I think https://forum.doom9.org/showpost.php?p=1879566&postcount=6935 worked for me.

[pradeeprama]

The new aq-mode and HME is only present in the default branch (3.1)

3.1.1 and 3.1.2 from the Release_3.1 branch only include some bug fixes that are also on the default branch.

x265-3.1+11-de920e0-win64-static-multilib (https://drive.google.com/open?id=1_gqvRPHTWI4C7DQ-LEsU0RHaDJy1-wOL)

x265 [info]: HEVC encoder version 3.1+11-de920e0a3183
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.55.100)
x265 [info]: (libavformat 58.30.100)
x265 [info]: (libavutil 56.33.100)
x265 [info]: (lsmash 2.16.1)

These features will be part of the next release, which will have its own branch. Only bug fixes for v3.1 will go into the Release_3.1 branch

[benwaggoner]

The new aq-mode and HME is only present in the default branch (3.1)

3.1.1 and 3.1.2 from the Release_3.1 branch only include some bug fixes that are also on the default branch.

x265-3.1+11-de920e0-win64-static-multilib (https://drive.google.com/open?id=1_gqvRPHTWI4C7DQ-LEsU0RHaDJy1-wOL)

It worked! I'm going to knock out some aq-mode 2 versus 4 tests with Tears of Steel.

[jlpsvk]

@benwaggoner
any thought about aq-mode 2 vs aq-mode 4?

[benwaggoner]

@benwaggoner
any thought about aq-mode 2 vs aq-mode 4?
CPUs have been too busy doing other things! But I'll kick them off now.

[brumsky]

CPUs have been too busy doing other things! But I'll kick them off now.

I'm looking forward to your results as well. I tested hevc-qa and it was bad... I had weird banding and everything was smoothed out really bad.

[markiemarcus]

I'm looking forward to your results as well. I tested hevc-qa and it was bad... I had weird banding and everything was smoothed out really bad.

I've had positive results with HEVC-AQ on animation; in part due to it taking AQ strength out of the equation.

Live action not so much.

[benwaggoner]

I've had positive results with HEVC-AQ on animation; in part due to it taking AQ strength out of the equation.

Live action not so much.
I'm running a 2-pass veryslow Tears of Steel encodes at 1 Mbps ABR comparing aq-mode 2, 3, 4 and aq-hevc. I should have some clips to evaluate tomorrow.

[markiemarcus]

I'm running a 2-pass veryslow Tears of Steel encodes at 1 Mbps ABR comparing aq-mode 2, 3, 4 and aq-hevc. I should have some clips to evaluate tomorrow.

It has actually surprised me how much variation there is between them. I've only really tested extensively on animation, often at 720p where the problems are more noticeable. The trouble really starts when you disable SAO, but you often have to in order to preserve high frequency detail. The artifacts resemble a mixture of ringing and mosquito noise around dark lines.

Under these circumstances Aq mode 1 is by far the most prone to distortion and though it's subjectively more detailed, I don't like it, unless the source has a lot of grain where it can be quite useful. Aq mode 2 is much less prone to distortion, but grain can look soft and it's noticeably poor in low luma. Aq mode 3 generally works well, but it's often a sub optimal usage of bits, especially if only fleeting scenes are low luma. That's usually where Hevc-aq does rather well (though Cbq and Crq need a -1 nudge down). I find it to be the most predictable and least troublesome in motion.

Aq mode 4 I don't really know what to make of. With grainy animation it seems a little more detailed than Aq mode 2. Just to clarify again that the above is all for animation; I haven't looked at the metrics and I don't have much experience with live action.

Looking forward to your results! I'm a long time lurker.

[Boulder]

I'm running a 2-pass veryslow Tears of Steel encodes at 1 Mbps ABR comparing aq-mode 2, 3, 4 and aq-hevc. I should have some clips to evaluate tomorrow.

1 Mbps is quite low already, it would be nice to see some results with average bitrate around 7-8 Mbps or so.

[benwaggoner]

1 Mbps is quite low already, it would be nice to see some results with average bitrate around 7-8 Mbps or so.
I'd expect there's be a lot of convergence at high bitrates. I'm most interested in how the different modes do when they don't have enough bits to do it right.

I'm also replicating the procedure from my encoding challenge, for apples-to-apples

https://forum.doom9.org/showthread.php?t=175776

[tebugg]

hello everyone. i am seeking a little bit of help with cpu usage. i have an amd ryzen 3900x overclocked to 4200mhz. it is on an msi x570 godlike mobo. so the vrm's are the best. i currently can only get between 70-80% cpu usage on the first pass. on the second pass it drops down to 60% usage. this is encoding a 4K video file that was originally encoded with x265 from my cell phone. is there a way for me to squeeze out more usage from x265's settings?

edit: on crf the encoder maxes out all the cores. also on x264 with 2pass and crf both max out the cores.

[Forteen88]

i currently can only get between 70-80% cpu usage on the first pass. on the second pass it drops down to 60% usage..If you can, then you should do 2 encodes at the same time.

[LazyNcoder]

Hello guys,
Any specific commands to encode HDR10+?
--transfer smpte2094 instead of --transfer smpte2084? is it enough? Does it work at all? because I couldn't find smpte2094 on x265 documentations ...

Edit:
Nope.
x265 [error]: invalid argument: transfer = smpte2094
Is there something wrong with my build?

[kabelbrand]

Any specific commands to encode HDR10+?
There is a command line switch to insert HDR10+ metadata but you'll need a separate tool e.g. from Samsung to process your source file for metadata creation.
https://x265.readthedocs.io/en/default/cli.html#cmdoption-dhdr10-info

[LazyNcoder]

There is a command line switch to insert HDR10+ metadata but you'll need a separate tool e.g. from Samsung to process your source file for metadata creation.
https://x265.readthedocs.io/en/default/cli.html#cmdoption-dhdr10-info

Thank you.

1- What if the source we already have is HDR10+? Can we somehow extract or bypass the metadata into x265?

2- What tool from Samsung exactly? or any alternative

[kabelbrand]

I guess you'd have to be a HDR10+ adopter to get access to the Samsung tools (JsonFromVideo, Hdr10PlusGenerator) or instead use a software like Colorfront Transkoder.

[filler56789]

Maybe off-topic but probably a necessary notice...

«After much consideration, we’ve decided to remove Mercurial support from Bitbucket Cloud and its API. Mercurial features and repositories will be officially removed from Bitbucket and its API on June 1, 2020.»

https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

[quietvoid]

Thank you.

1- What if the source we already have is HDR10+? Can we somehow extract or bypass the metadata into x265?

2- What tool from Samsung exactly? or any alternative

This might be useful for you: https://github.com/quietvoid/hdr10plus_parser

[LigH]

@filler56789: Good to get this notice way ahead ... enough time for the x265 team to possibly move the repository to either a different hoster or a different versioning system... (I would assume rather the first, since they love funny version tags which annoy some compiler suites not expecting their syntax).

[kabelbrand]

This might be useful for you: https://github.com/quietvoid/hdr10plus_parser

Thanks, good work! Even though the Samsung Hdr10PlusInjector tool does not like this JSON format I guess as long as x265 is happy that's good enough.

For reference I attached the raw JSON output from my test. There are some additional indexes and ids in the Samsung output but these might be optional.

[quietvoid]

Thanks, good work! Even though the Samsung Hdr10PlusInjector tool does not like this JSON format I guess as long as x265 is happy that's good enough.

For reference I attached the raw JSON output from my test. There are some additional indexes and ids in the Samsung output but these might be optional.

Yes, if I remember correctly x265 just adds the metadata for each frame encoded, scene related info is ignored.
At the time of development (possibly now too), HDR10+ titles also have metadata inserted at every frame, and not like 1 SEI message per scene.

After all, some of this is trial and error using x265 as "correct" implementation.
There is still some desync between source JSON and extracted where there is a metadata change (scene change?), but it's usually just 1-2 frames that are different.

[benwaggoner]

Yes, if I remember correctly x265 just adds the metadata for each frame encoded, scene related info is ignored.
At the time of development (possibly now too), HDR10+ titles also have metadata inserted at every frame, and not like 1 SEI message per scene.

After all, some of this is trial and error using x265 as "correct" implementation.
There is still some desync between source JSON and extracted where there is a metadata change (scene change?), but it's usually just 1-2 frames that are different.
You want to use --dhdr10-opt. That'll insert the SEI only on IDR frames and frames where the metadata changes.

Note that dynamic metadata isn't necessarily static across a shot; if there are dramatic changes in a shot, than there likely will be mid-shot metadata.

[quietvoid]

You want to use --dhdr10-opt. That'll insert the SEI only on IDR frames and frames where the metadata changes.

Note that dynamic metadata isn't necessarily static across a shot; if there are dramatic changes in a shot, than there likely will be mid-shot metadata.

I'm aware of x265's --dhdr10-opt, but I prefer to keep it the same as the source (which seems to always be for every frame).
Not sure if it would affect compatibility as well.