x265: a good compromise between "slow" and "slower" presets?

[iz-Moff]

Hi.

I wanted to do some encoding using x265 (ver 3.0), but i can't quite decide on the settings. Preset "slow" has pretty good encoding speed, enough that i wouldn't mind sacrificing some to get a bit higher quality encodes, but the next available preset is like 3-4x slower, which is way too slow for me.

I want to tune "slow" preset to be a bit closer to "slower", and i've looked up the parameters they use, but i'm not sure which of them would offer a good tradeoff between speed and quality. I tried reading docs, but they're too technical for me to understand and don't really offer any advice.

So i was wondering if anyone could give me a rough outline of which parameters would have what effect on quality/encoding speed?
Thanks.

Here's the list of parameters that are different between the two presets:

slow slower
bframes 4 8
rc-lookahead 25 40
lookahead-slices 4 1
ref 4 5
limit-refs 3 1
subme 3 4
amp 0 1
max-merge 3 4
recursion-skip 1 0
b-intra 0 1
weightb 0 1
rdLevel 4 6
tu-intra 1 3
tu-inter 1 3
limit-tu 0 4

[Tadanobu]

I'll suggest the following command line :

--preset slow --limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --limit-tu 4 --merange 64 --bframes 8 --no-sao

Here is what I personally use as my main profile. I always make a test encode with these settings and then tweak them. It's a bitter faster than slower (but not that much) :

--preset slow --output-depth 10 --limit-refs 1 --limit-tu 4 --tu-intra-depth 3 --tu-inter-depth 3 --psy-rdoq 1.1 --aq-mode 3 --subme 5 --merange 64 --max-merge 5 --bframes 8 --rc-lookahead 120 --lookahead-slices 1 --ref 6 --deblock -3:-3 --no-sao --psy-rd 2.1

[Blue_MiSfit]

I find SAO to very much be worth it today in all cases. Maybe if you're doing high bitrate encoding you can turn it off, but it really helps in motion. It does soften a bit in single frame comparison sometimes.

[Asmodian]

I also find SAO to be worth it now, even when I encode to really high bitrates. The smoothing is so minor with current versions that there really is no need to turn it off anymore.

If you think x265 smooths too much with SAO on, and SAO does not help much because the bitrate is so high, then you might want to use x264 instead.

[redbtn]

Try Slower with --limit-refs 3 --no-amp --rd 4. It will be a much faster and not affect much to quality.

I find SAO to very much be worth it today in all cases. Maybe if you're doing high bitrate encoding you can turn it off, but it really helps in motion. It does soften a bit in single frame comparison sometimes.
FullHD 16-17mb and UHD 20-22mb is high bitrate? I always use --no-sao, but maybe I should think about it

[iz-Moff]

I'll suggest the following command line :

Is "--limit-refs 1" worth it? I've run some test encodes on a sample, and among the settings that are different between the two presets, "--rd 6", "--limit-refs 1" and "-no-rskip" reduce encoding speed the most. Also, only placebo preset uses --merange above 57, and 57 doesn't sound like a number that would be selected arbitrarily...

Anyway, i guess for now i'll try using pretty much the "slower" preset without "--rd 6", "--limit-refs 1" and "-no-rskip":
--preset slow --profile main10 --bframes 8 --b-intra --weightb --subme 4 --rc-lookahead 40 --tu-intra 3 --tu-inter 3 --limit-tu 4 --amp --ref 5 --lookahead-slices 1 --max-merge 4
These settings result in only about 10-20% slower encoding speed, and, hopefully, will benefit the quality a bit.

Try Slower with --limit-refs 3 --no-amp --rd 4. It will be a much faster and not affect much to quality.

Thanks, yeah, that seems like a good tradeoff. Though "--amp" doesn't seem to reduce the speed a lot, at least not with the samples i tried, so i guess i'll use it.

[redbtn]

If I remember correctly --amp can slow down by 20% at least for me. So, maybe it depends of the source. What you want to encode? If you are interested, I can show all my settings based my tests for 1080p and 4k hrd.
It took a long time, but I'm happy with the result.

Ps: I'm pretty sure that for now (version 3.2) --no-rskip used only preset placebo, so I don't really understand why your Slower use it.

[Blue_MiSfit]

T
FullHD 16-17mb and UHD 20-22mb is high bitrate? I always use --no-sao, but maybe I should think about it

Those are definitely high, especially the 1080p number.

Common HEVC bitrates would be like 3-5 Mbps for 1080p and maybe 10-12 Mbps for UHD.

At least, that's what's commonly seen in the premium OTT streaming case. Approx 8 for FHD and 25 for UHD are the highest used in large scale streaming services.

I think this is enough for very good quality with most content with slow settings, but some challenging content really does need 30+ to look really good, especially grainy content. There's a reason UHD BluRay has the bitrates it does I guess ;)

Anyway, I guess to sum things up, maybe for UHD BluRay level bitrates SAO doesn't make sense, but for anything practical for streaming you definitely want it turned on these days.

IMO.

[Nico8583]

Hi,
And what about --repeat-headers, --aud and --hrd options ? Is there a quality impact when using these options ?
Thank you.

[benwaggoner]

Hi,
And what about --repeat-headers, --aud and --hrd options ? Is there a quality impact when using these options ?
Thank you.
No, those are mainly metadata; shouldn't impact encoding at all. At VERY low bitrates the extra bits might have an impact, but it's << 1 Kbps.

[Nico8583]

No, those are mainly metadata; shouldn't impact encoding at all. At VERY low bitrates the extra bits might have an impact, but it's << 1 Kbps.
Thank you, just to close this point : are these options useless ? Or is it necessary to use it when we encode to x265 and remux to MKV ? Thank you.

[redbtn]

Thank you, just to close this point : are these options useless ? Or is it necessary to use it when we encode to x265 and remux to MKV ? Thank you.--repeat-headers --aud and --hrd are need for HDR encode.

[Nico8583]

Thank you.
I would like to encode my HD and UHD BluRay collection to x265 so I have the same question. Slower is very low, slow has a good speed but I would like to keep the best ratio between speed and quality.
Could you give 2 command line exemples, one for FHD and one for UHD with slow and/or slower preset ?
Thank you !

[redbtn]

Thank you.
I would like to encode my HD and UHD BluRay collection to x265 so I have the same question. Slower is very low, slow has a good speed but I would like to keep the best ratio between speed and quality.
Could you give 2 command line exemples, one for FHD and one for UHD with slow and/or slower preset ?
Thank you !I tried to encode 2160p, but with my settings and CRF 20 it gives me on some BD's 24mb+ bitrate. In my case there is only one way to lower the bitrate, use cutree and turn off psy-rdoq. I don't want to do it. I have 6 core 9400f, so my speed is 1.4fps for 2160p. Just now I did some comparison, native UHD vs resized with spline64 2160p>1080p>2160p and I realized that loss in detail not worth it. So I decided to encode UHD>FHD. My settings are something between slow and slower with some tweaks. I can't give it to you right now, but tomorrow I will.

[Boulder]

Just now I did some comparison, native UHD vs resized with spline64 2160p>1080p>2160p and I realized that loss in detail not worth it. So I decided to encode UHD>FHD.

I downsize my encodes all the time, and I strongly recommend using Zopti to find out the optimal parameters for Bicubic resizing to compensate the loss of sharpness and detail as much as possible.

[Nico8583]

Thank you.
You downsize your encodes to reduce filesize, reduce encoding time or both ?
I already tried to downsize but the result was not so good than UHD encode... Perhaps my filter was not so good.

[Boulder]

I downsize just to save some space, also you can easily see that a lot of material really doesn't have any details to lose if you go from 1080p to 720p, or 2160p to 1080p (of course the relative change is bigger in the latter). Quite a lot is already an upscale from 2K to 4K.
Downsizing with Bicubic with specific tuned parameters can compensate quite a lot, especially the loss of sharpness. My viewing distance to my 65" TV is about 3.5 metres, so downsizing also has a lower impact what comes to details so your situation may be quite different.

[redbtn]

I downsize my encodes all the time, and I strongly recommend using Zopti to find out the optimal parameters for Bicubic resizing to compensate the loss of sharpness and detail as much as possible.
Thank you for advice! Can you share your script for Zopti comparison? I just looked Zopti topic, but it's a little complicated for me.
---------
Nico8583 There are my settings below. No need to set Preset or you can choose Preset Medium cuz it is use defaults.

For HDR
--level-idc 51 --sar 1:1 --colorprim 9 --colormatrix 9 --transfer 16 --range limited --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --hdr --hdr-opt --hrd --chromaloc 2 --repeat-headers --min-luma 0 --max-luma 1023 --no-cutree --no-sao --no-open-gop --no-strong-intra-smoothing --vbv-bufsize 160000 --vbv-maxrate 160000 --min-keyint 5 --keyint 240 --ipratio 1.35 --pbratio 1.25 --deblock -3:-3 --qcomp 0.7 --aq-mode 1 --aq-strength 0.9 --ctu 64 --merange 57 --me star --limit-refs 3 --no-early-skip --weightb --b-intra --rd 4 --rdoq-level 2 --rc-lookahead 72 --psy-rd 2 --psy-rdoq 1.2 --max-merge 4 --lookahead-slices 0 --bframes 8 --ref 4 --subme 4 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 1 --rect --no-amp --limit-modes

For SDR
--level-idc 51 --sar 1:1 --colorprim 1 --colormatrix 1 --transfer 1 --range limited --chromaloc 0 --no-cutree --no-sao --no-open-gop --no-strong-intra-smoothing --vbv-bufsize 90000 --vbv-maxrate 90000 --min-keyint 5 --keyint 240 --ipratio 1.35 --pbratio 1.25 --deblock -3:-3 --qcomp 0.7 --aq-mode 3 --aq-strength 0.8 --ctu 64 --merange 57 --me star --limit-refs 3 --no-early-skip --weightb --b-intra --rd 4 --rdoq-level 2 --rc-lookahead 72 --psy-rd 2 --psy-rdoq 1.2 --max-merge 4 --lookahead-slices 0 --bframes 8 --ref 4 --subme 4 --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 1 --rect --no-amp --limit-modes

And I did some tests yesterday:

--tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 4 (2.10fps = 215.8mb)
--tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 3 (2.11fps = 215.7mb)
--tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 2 (1.93fps = 214.2mb)
--tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 1 (1.91fps = 200.0mb) best speed / compression IMO
--tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 0 (1.73fps = 194.4mb)
--tu-intra-depth 1 --tu-inter-depth 1 --limit-tu 0 (2.28fps = 217.3mb) best speed
--tu-intra-depth 3 --tu-inter-depth 3 --limit-tu 1 (1.83fps = 209.8mb)
--tu-intra-depth 2 --tu-inter-depth 2 --limit-tu 0 (1.57fps = 220.6mb)

[excellentswordfight]

Thank you for advice! Can you share your script for Zopti comparison? I just looked Zopti topic, but it's a little complicated for me.
---------
Nico8583 There are my settings below. No need to set Preset or you can choose Preset Medium cuz it is use defaults.

For HDR


For SDR


And I did some tests yesterday:
Have you done any tests with and without no-strong-intra-smoothing? All test I've done with it shows that disabling it (using no-strong-intra-smoothing) only gave negative effects, worse compression and blocking and gave negligible improvement for sharpness/detail retention.

[redbtn]

Have you done any tests with and without no-strong-intra-smoothing? All test I've done with it shows that disabling it (using no-strong-intra-smoothing) only gave negative effects, worse compression and blocking and gave negligible improvement for sharpness/detail retention.I did test just now and there is no difference in file size, just minor, few KB's. And I don't know how compare it for visual quality. Probably I have to use --strong-intra-smoothing and don't care about it.

[Nico8583]

Thank you redbtn for your command lines :)
And I'm also interested to get a Zopti script.

[Boulder]

Thank you for advice! Can you share your script for Zopti comparison? I just looked Zopti topic, but it's a little complicated for me.


from vapoursynth import core
from zoptilib import Zopti

orig = core.ffms2.Source(source=r'ridgemont.avi') # lossless intermediate file containing 80-100 single frames throughout the whole movie (see below how I do it)

zopti = Zopti(r'results.txt', metrics=['mdsi', 'time'], matrix='709')

b = -110/100.0 # optimize b = _n_/100.0 | -175..-50 | b
c = -10/100.0 # optimize c = _n_/100.0 | -30..70 | c

alternate = core.resize.Bicubic(orig, width=1280, height=688, filter_param_a=b, filter_param_b=c) # this one downsizes the lossless clip to my final size
alternate = core.resize.Bicubic(alternate, width=3840, height=2064, filter_param_a=0, filter_param_b=0.5) # this one upsizes the downsized clip to the full 4K resolution as I have a 4K TV
orig = core.resize.Bicubic(orig, width=3840, height=2064, filter_param_a=0, filter_param_b=0.5) # the lossless clip (having the original resolution minus black borders) is upsized to 4K
zopti.run(orig, alternate) # we compare the upsized original to the downsized-upsized one to get as close as possible

To get the lossless clip, I simply load the source, add the denoising part etc. and then add these ones:

clp = core.std.SelectEvery(clp, 700, 1)
clp = core.std.Trim(clp, 2, 101)

So in this case it would pick one frame in every 700 frames, then trim the result to 100 frames. I do this to make sure the comparison uses various kind of frames throughout the movie. I usually adjust the first line so that the clip length is first something like 105-110 frames, then uncomment the Trim line.
Then I use ffmpeg to encode the lossless clip (you can use FFV1 as the codec for example), like vspipe.exe --y4m "yourscript.vpy" - | c:\utils\ffmpeg\bin\ffmpeg.exe -i - -c:v ffv1 "c:\zopti\yourlosslessclip.avi"

The idea of the Zopti script is to simulate encoding the video in a lower resolution and then your TV or media player will upsize it to 4K when you watch it. We are trying to find optimal parameters in Bicubic to make sure the distortion in the final result is as small as possible. The other metric to try is gmsd, it's faster than mdsi. Usually ends up in a slightly less sharp final result.

This is the Zopti command line I use:
zopti test.vpy -alg mutation -iters dyn -dyniters 15 -dynphases 2 -pop 1 -runs 1 -mutcount 1 -mutamount 0.1 0.01 -initial script

Then from the log file, get the best result for b and c (filter_param_a and filter_param_b in Vapoursynth Bicubic). Place them in your script that you use to encode.
zopti -mode evaluate -log "nameofthezoptilogfilehere.log"

It may look a bit complicated but once you do it a few times, you get the hang of it. I'm quite happy with the results, much better than what I could have done manually.

[redbtn]

Boulder Thank you very much for explaining! Just a few questions.

1) If I'm encoding HDR, should I use:

zopti = Zopti(r'results.txt', metrics=['mdsi', 'time'], matrix='bt2020nc')

or matrix='709' but first tonemap HDR to SDR video using like tonemap.Hable ?

2) If i don't use denoising (because i don't know how), can i skip encode the lossless clip and just add to the beginning of the script?

clp = core.std.SelectEvery(clp, 700, 1)
clp = core.std.Trim(clp, 2, 101)

After a few time, it's my script. Is it right? I don't have good VapourSynth skills, i hope it's right.

import vapoursynth as vs
from zoptilib import Zopti
core = vs.get_core()
core.max_cache_size = 8192

# Open video
clip = core.lsmas.LWLibavSource(source="video.mkv", format="YUV420P10", cache=1)

# SelectEvery and Trim
clip = core.std.SelectEvery(clip, 1500, 1)
clip = core.std.Trim(clip, 6, 105)

# Crop the video
clip = core.std.CropRel(clip=clip, left=0, right=0, top=280, bottom=280)

# color adjustment using ToneMap
clip = core.resize.Bilinear(clip=clip, format=vs.RGBS, range_in_s="limited", matrix_in_s="2020ncl", primaries_in_s="2020", primaries_s="2020", transfer_in_s="st2084", transfer_s="linear",dither_type="none", nominal_luminance=125)
clip = core.tonemap.Hable(clip=clip, exposure=2.000)
clip = core.resize.Bilinear(clip=clip, format=vs.YUV420P8, matrix_s="709", primaries_s="709",range_s="limited", transfer_s="709", transfer_in_s="linear", range_in_s="limited", dither_type="ordered")

# Zopti Starts
zopti = Zopti(r'results.txt', metrics=['mdsi', 'time'], matrix='709')

b = -110/100.0 # optimize b = _n_/100.0 | -175..-50 | b
c = -10/100.0 # optimize c = _n_/100.0 | -30..70 | c

# This one downsizes the lossless clip to FHD
alternate = core.resize.Bicubic(clip, width=1920, height=800, filter_param_a=b, filter_param_b=c)

# This one upsizes the downsized clip to the UHD
alternate = core.resize.Bicubic(alternate, width=3840, height=1600, filter_param_a=0, filter_param_b=0.5)

# My 4k cropped video (I removed upscaling because my original video already 4k)
orig = clip

# We compare the original to the downsized-upsized one to get as close as possible
zopti.run(orig, alternate)

[Boulder]

If you are going the HDR way, you can use bt2020nc as the matrix and skip the tone mapping part. You can also add those two lines selecting the frames there, but it will probably be slower than using a lossless clip with the frames already picked.

[redbtn]

I got an error in VS Editor using matrix='bt2020nc'
Failed to evaluate the script:
Python exception: Resize error: bad value: matrix_in_s

Anyway, thank you very much!

[Boulder]

http://www.vapoursynth.com/doc/functions/resize.html

It's probably 2020ncl.

[redbtn]

http://www.vapoursynth.com/doc/functions/resize.html

It's probably 2020ncl.Yes, you are right! After finish the current job I'll try with 2020ncl without tone mapping and compare results. Thx!!
I hope in the end I'll get better result vs spline64

[benwaggoner]

Yes, you are right! After finish the current job I'll try with 2020ncl without tone mapping and compare results. Thx!!
I hope in the end I'll get better result vs spline64
Unless you're scaling in the linear light domain, you probably aren't going to get great results. I don't know of any way with most open source pipelines to get linear light transforms. I generally wind up doing it with the Adobe Creative Cloud products.

[redbtn]

It seems weird, sometimes it writes (no samples)

UPD: Oh, it seems like i found the reason. I use script below and it shows 100 frames, but the duration is still 1 hour 44mins (FPS: 16/1001 = 0.01598), like whole movie. I try to do losless video, and i get *.avi with 1 hour 44mins duration. It's very weird. I don't know what I'm doing wrong.

UPD 2: Problem is SelectEvery function. Without it fps is ok (FPS: 24000/1001 = 23.976). I don't know why it's happening.
UPD 3: Solution is very simple, Just set AssumeFPS after SelectEvery. Now it's ok. No, it's not. Fps is fine but it still writes "no samples". Maybe this is not errors. The script works and gives the result.
import vapoursynth as vs
core = vs.get_core()

clip = core.lsmas.LWLibavSource(source="video.mkv", format="YUV420P10", cache=1)
clip = core.std.AssumeFPS(clip, fpsnum=24000, fpsden=1001)
clip = core.std.CropRel(clip=clip, left=0, right=0, top=280, bottom=280)

# SelectEvery and Trim
clip = core.std.SelectEvery(clip, 1500, 1)
clip = core.std.Trim(clip, 6, 105)

clip.set_output()

[Boulder]

Unless you're scaling in the linear light domain, you probably aren't going to get great results. I don't know of any way with most open source pipelines to get linear light transforms. I generally wind up doing it with the Adobe Creative Cloud products.

I use resamplehq myself, that one should work fine.

[Boulder]

It seems weird, sometimes it writes (no samples)


Don't worry about any of those things, it's working fine :)

And when you get the results, don't forget to divide them by 100 to get the value to feed in the resizer. As benwaggoner mentioned, you probably need something like resamplehq with HDR sources (in Zopti and final encode).

[redbtn]

Don't worry about any of those things, it's working fine :)

And when you get the results, don't forget to divide them by 100 to get the value to feed in the resizer. As benwaggoner mentioned, you probably need something like resamplehq with HDR sources (in Zopti and final encode).Thank you! I found the optimal values.
And I have a question, if I wanna spend like 18mb/s of bitrate to all my encodes (If they can use less bitrate for a quality that suits me, I don't care. And if they need more, I don't want to spend more), what the best way, adjust CRF to target bitrate or use ABR?
I'm asking because I did test and noticed that CRF encode in slow scenes much worse than ABR. I didn't compare high motions scenes yet, but I'm a little confused.

[Natty]

--limit-refs 1 --tu-intra-depth 3 --tu-inter-depth 3 --limit-tu 4


how these switches work? :thanks:

[Boulder]

Thank you! I found the optimal values.
And I have a question, if I wanna spend like 18mb/s of bitrate to all my encodes (If they can use less bitrate for a quality that suits me, I don't care. And if they need more, I don't want to spend more), what the best way, adjust CRF to target bitrate or use ABR?
I'm asking because I did test and noticed that CRF encode in slow scenes much worse than ABR. I didn't compare high motions scenes yet, but I'm a little confused.

I always use CRF. I've figured out a level which will generally produce transparent results when watching from about 2 metres, then reduced the figure a bit more to gain some headroom. This is simply because the material varies so much. Some requires very few bits, but some black and white movies with a lot of grain will eat bits for breakfast. CRF 18 is the one I use for my 720p encodes, 1080p could probably handle CRF 19 but 18 is on the safe side.

If I'm not entirely mistaken, a 2-pass encode at 18 Mbps and CRF resulting in the same average bitrate should produce equal quality. The rate control mechanism is most likely the same, at least that's how it is with x264.

[redbtn]

If I'm not entirely mistaken, a 2-pass encode at 18 Mbps and CRF resulting in the same average bitrate should produce equal quality. The rate control mechanism is most likely the same, at least that's how it is with x264.
2-pass is taking x2 time for encode. I'm comparing CRF vs 1-pass ABR at the same bitrate. I wonder in what areas or scenes CRF should be better to find the differences.
Do you use --cutree?

[redbtn]

how these switches work? :thanks:This is a very General question. It is unclear what answer you want to hear.

[Boulder]

2-pass is taking x2 time for encode. I'm comparing CRF vs 1-pass ABR at the same bitrate. I wonder in what areas or scenes CRF should be better to find the differences.
Do you use --cutree?

Yes, cutree is enabled by default. ABR is not suitable for your regular encodes, I'd say it's more for streaming or just some quick tests. Better find the CRF level you are happy with..

[Nico8583]

I think I'll go with these settings :
HD :
Preset : Slow
CRF : 14 to 16
Sao : 0
Deblock : -1;-1
Colorprim : bt709
Transfer : bt709
Colormatrix : bt709

UHD :
Preset : Slow
CRF : 14 to 16
Sao : 0
Deblock : -1;-1
Colorprim : bt2020
Transfer : smtpe2084
Colormatrix : bt2020nc
HDR : 1
HDR-Opt : 1
Chromaloc : 2 (variable)
Repeat-Headers : 1
AUD : 1
HDR : 1
Range : Limited
Master Display : G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20) (variable)
Max CLL : 717,578 (variable)

UHD HDR10+ :
Same than UHD +
DHDR10-Info : 1
DHDR10-Opt : <JSON>
My first tests seems to be OK, few parameters but sufficient, no ?

[redbtn]

I'm not sure about Dolby Vision, but overall it looks ok. Just add min-luma 0 and max-luma 1023 to HDR settings.

[Nico8583]

I don't know these parameters, hdr-opt and/or colormatrix and/or range don't already define these values ?
And I'm doubting about SAO, with a high bitrate I allways disable it but since last x265 versions perhaps it's not a good idea ?

[Boulder]

SAO had not been touched at all in a long time in code so I would keep it disabled if that's what you did earlier.

[Nico8583]

Ok thank you so I'll keep no sao.
And sorry it was not Dolby Vision but HDR10+ in my previous post, MKV doesn't support Dolby Vision now.

[redbtn]

Ok thank you so I'll keep no sao.
And sorry it was not Dolby Vision but HDR10+ in my previous post, MKV doesn't support Dolby Vision now.HDR10+ requires json file if I remember correctly. I didn't any hdr10+ encodes yet.

[redbtn]

I have some wiered green artifacts that appear in various places. I tried different settings (also --aud helps a lot) and even clean Preset Slow, but they are still there. I don't understand where is the problem.
--cbqpoffs -3 --crqpoffs -3 didn't help

Left - source | Right - encode (both tonemapped with MadVR)

https://t35.pixhost.to/thumbs/467/124914204_fs-2019-10-20-21-13-24-edit.png (https://pixhost.to/show/467/124914204_fs-2019-10-20-21-13-24-edit.png) https://t35.pixhost.to/thumbs/467/124914203_fs-2019-10-20-21-20-06.png (https://pixhost.to/show/467/124914203_fs-2019-10-20-21-20-06.png)

My settings
--level-idc 51 --colorprim 9 --colormatrix 9 --transfer 16 --range limited --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "3241,902" --hdr --hdr-opt --hrd --aud --chromaloc 2 --repeat-headers --no-sao --no-open-gop --vbv-bufsize 160000 --vbv-maxrate 160000

Mediainfo from encode
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 44 s
Bit rate : 14.2 Mb/s
Width : 3 840 pixels
Height : 1 600 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.097
Stream size : 177 MiB (100%)
Writing library : x265 3.2+7-37648fca915b:[Windows][GCC 9.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=2 / numa-pools=6 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x1600 / interlace=0 / total-frames=2500 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=5 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=72 / lookahead-slices=0 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=1 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=4 / limit-refs=1 / limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.20 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.35 / pbratio=1.25 / aq-mode=2 / aq-strength=0.80 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) / cll=3241,902 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 3241 cd/m2
Maximum Frame-Average Light Level : 902 cd/m2

[Nico8583]

What is your frameserver ? Have you tried to encode lossless ? Or have you tried to encode to x264 ? Just to compare the output.

[redbtn]

What is your frameserver ? Have you tried to encode lossless ? Or have you tried to encode to x264 ? Just to compare the output.Vapoursynth. I did some more tests and it seems like there is not enough bitrate for I-frames. Because I compared encoded I-frame vs original P-frame and with bitrate 160000kb/s color is right, but with bitrate 70000kb/s it's wrong. I'm a little confused

[Boulder]

Vapoursynth. I did some more tests and it seems like there is not enough bitrate for I-frames. Because I compared encoded I-frame vs original P-frame and with bitrate 160000kb/s color is right, but with bitrate 70000kb/s it's wrong. I'm a little confused

Do you mean the VBV buffer? 70000 kbps could well be too low. But that value does not mean the same as the bitrate of the encode.
The specs say max rate at 160000 kbps anyway..
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels

[redbtn]

Do you mean the VBV buffer? 70000 kbps could well be too low. But that value does not mean the same as the bitrate of the encode.
The specs say max rate at 160000 kbps anyway..
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levelsNo, I mean Average Bitrate. If I drop CRF to like 10, I-Frames avg bitrate hit 160000 and then it looks good. But if CRF is higher and I-frames avg bitrate only 70000, it still has color artifacts.
VBV buffer = 160000 always. 4K encode

[Boulder]

Have you tried raising the aq-strength substantially, like to 1.5 - 2.0? Or mode 1 at the default?

All in all, I think those issues should also be posted in the x265 issue tracker along with samples.

[redbtn]

Have you tried raising the aq-strength substantially, like to 1.5 - 2.0? Or mode 1 at the default?

All in all, I think those issues should also be posted in the x265 issue tracker along with samples.Thx. I'll try it in next couple of hours. I'll report later.
I don't know actually, maybe it's normal, cuz this areas is small and it visible only by comparing frames. But I'd like to that 4k encode at 22-24mb bitrate doesn't have colors issues.