x265 Sharpness and Detail (Best Settings?)

[jpsdr]

I took a quick look at the part code of hevc-aq, and it realy doesn't look like aq-mode 4...
Real question : Is the purpose of hevc-aq of being more suitable to HDR-PQ than the others standard aq-mode ? (If i ask this it's because of the hevc part in the name... )

[benwaggoner]

I don't recall anything HDR-specific about --hevc-aq.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I suspect the gap will be larger with a more representative number of frames. You need to encode a decent multiple of --keyint to get accurate performance numbers. 10 frames is less than default --rc-lookahead, and fps is typically way higher for the --rc-lookahead duration.

--rc-lookahead is really a secret weapon for improving quality and reducing quality fluctuations with single-pass encoding.

Sorry for the late response to this one, but what if I'm using constant rate factor with a keyint of 24 and an rc-lookahead of 24. Is there any quality gains to be had past this? I used to try 48 for rc-lookahead to be 1 second in front just to cover my back, but I was told that going over the keyint is never worth it / a waste of time.

Responding to some thoughts about aq-modes. I have personally found that aq-mode 3 seems to be best for all the content that Ive encoded, and seems to cover your back with any scenes that have black level detail. One thing that I noticed is that using aq-mode 3, and with a relatively high strength like 1.7 seems to remove microbanding, and any odd banding or bit-depth errors.

[Blue_MiSfit]

Any reason you're punching yourself in the face with such a short keyint? I'd suggest at least 2 seconds (and ideally 4-10) to let x265 stretch its legs

I don't think there's any benefit to rc-lookahead > keyint but I'll let Ben chime in on that

[HD MOVIE SOURCE]

Originally Posted by Blue_MiSfit

Any reason you're punching yourself in the face with such a short keyint? I'd suggest at least 2 seconds (and ideally 4-10) to let x265 stretch its legs

I don't think there's any benefit to rc-lookahead > keyint but I'll let Ben chime in on that

Thats the keyint required for uhd-bd=1.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Thats the keyint required for uhd-bd=1.

OG Blu-ray would allow a 2-sec GOP if the --vbv-maxrate was 15000 Kbps or below. Does UHD-BD have any equivalent option?

Back when I was trying to fit BD content on a DVD-R, I'd often use the 15 Mbps cap so I could get the longer GOPs. Going to level 4.0 instead of 4.1 also eliminates the requirement for four slices, although takes the vbv-maxrate down to 25 Mbps from 40 Mbps.

With a 2 sec GOP and single slice, most 1080p24 content could still look excellent at a 15 Mbps peak, and the improved efficiency would make average quality better than with higher peaks but with slices and 1 sec GOP.

Only mattered when trying to stick a good amount of content on a small disc, though.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

OG Blu-ray would allow a 2-sec GOP if the --vbv-maxrate was 15000 Kbps or below. Does UHD-BD have any equivalent option?

Back when I was trying to fit BD content on a DVD-R, I'd often use the 15 Mbps cap so I could get the longer GOPs. Going to level 4.0 instead of 4.1 also eliminates the requirement for four slices, although takes the vbv-maxrate down to 25 Mbps from 40 Mbps.

With a 2 sec GOP and single slice, most 1080p24 content could still look excellent at a 15 Mbps peak, and the improved efficiency would make average quality better than with higher peaks but with slices and 1 sec GOP.

Only mattered when trying to stick a good amount of content on a small disc, though.

Good question, honestly not sure. I've always thought UHD-bd was always a 1 second GOP. I may have tried 2 seconds before and I think the encode failed, but I could be wrong.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Good question, honestly not sure. I've always thought UHD-bd was always a 1 second GOP. I may have tried 2 seconds before and I think the encode failed, but I could be wrong.

I don't know if UHD-BD's spec allows for 2-sec GOP in any case. UHD BD was intentionally as small as possible delta from the original Blu-ray spec. it's basically support for higher density discs plus HEVC 4K. But all the BD-J and overlays are still only 1080p.

I don't think that the special <25 Mbps (can use a single slice instead of 4) or <15 Mbps (can use 2 sec GOP) modes were used much (if ever) with commercial discs, nor was consumer authoring a concern with the UHD upgrade, so it'd be unsurprising if there's no equivalent.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Sorry for the late response to this one, but what if I'm using constant rate factor with a keyint of 24 and an rc-lookahead of 24. Is there any quality gains to be had past this? I used to try 48 for rc-lookahead to be 1 second in front just to cover my back, but I was told that going over the keyint is never worth it / a waste of time.

--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames.

Responding to some thoughts about aq-modes. I have personally found that aq-mode 3 seems to be best for all the content that Ive encoded, and seems to cover your back with any scenes that have black level detail. One thing that I noticed is that using aq-mode 3, and with a relatively high strength like 1.7 seems to remove microbanding, and any odd banding or bit-depth errors.

--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

[Boulder]

Originally Posted by benwaggoner

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

For example jpsdr's recent x265 mods have this kind of a feature. There is the parameter --aq-bias-strength which is a multiplier on top of aq-strength. I believe it should make --sbrc work more efficiently. (aq-mode 5 mentioned here is aq-mode 4 + low luma bias)

--aq-bias-strength <float>
      Adjust the strength of dark scene bias in AQ modes 3 and 5. Setting this
      to 0 will disable the dark scene bias, meaning modes will be equivalent to
      their unbiased counterparts (2 and 4).
      Default 1.0.

Originally Posted by benwaggoner

--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

Hi,

What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)?

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

--rc-lookahead is capped at --keyint in any case, so it doesn't really matter.

I've certainly seen valuable quality improvements (specifically big reductions in quality variations that yield visibly poor quality) when increasing keyint and rc-lookahead from 2 to 5 seconds, and that was mostly due to the higher --rc-lookahead (comparing --keyint 120 --rc-lookahead 48 versus 128). That said, --rc-lookahead is most impactful with single-pass --crf encodes. It offers benefit with 1-pass CBR, but a full two-pass encode is basically rc-lookahead=total frames.


--aq-mode 3 is identical to --aq-mode 2 except that it lowers QP as luma values get nearer to black. This gets around Rec. 709's perceptual non-uniformity, where the difference between luma of 16 and 17 is much more visible than between, say 216 and 217. So the same compression artifacts can be much more visible near black than near white.

--aq-mode 3 can really help shadow detail and reduce banding near black. However, those lower QPs use more bits. For CBR and VBV-limited encodes, this increases QP of brighter frames, which can introduce new quality issues. Or in CRF mode, increase ABR quite a bit. It's a great tool when there's enough bandwidth, but needs to be used delicately at lower bitrates. It's not a safe feature to just leave always on when targeting best possible quality at low bitrates. It helps sometimes, and hurts others. Lower --aq-strength values are optimal with aq-mode 3 than 2 as well, as high values can really starve brighter macroblocks of bits.

It's also not appropriate for HDR-10, which is much more perceptually uniform, and where the visible difference between luma values is pretty much identical at any brightness.

10-bit encoding can make --aq-mode less needed as well, as the difference between 8-bit 16 and 17 now is the difference between 64 and 68, and those four extra steps make for more efficient encoding, reduce the need for dithering, and generally makes for much less visible banding and blocking.

I'm confident that --aq-mode 3 could be improved to be more content-adaptive. It'd prefer x264 to have aq-mode algorithm selection decouple from luma bias. So we could do stuff like

--aq-mode 4 --low-luma-bias 0.7

And make --aq-mode 3 essentially an alias to

--aq-mode 2 --low-luma-bias 1.0

Very valuable info, thank you. I'd be interested in trying the 5x keyint for lookahead. Does higher lookahead require much more processing time? If so, it really depends on what can be gained from 5x lookahead.

I have thought about having bit-rate starved on brighter scenes, but I haven't found it to be an issue when bit-rates are high enough. I guess it could be an issue for bit-rate-restricted content. I typically find that black-level detail can still be an issue even on 4K discs. So even using it as a tool to distribute more bits into black-level detail is useful. Do you think this is why it potentially could improve gradients from black to full color? Because there are more bits being distributed in the low end of the spectrum and now the gradients look smoother?

[benwaggoner]

Originally Posted by Boulder

For example jpsdr's recent x265 mods have this kind of a feature. There is the parameter --aq-bias-strength which is a multiplier on top of aq-strength. I believe it should make --sbrc work more efficiently. (aq-mode 5 mentioned here is aq-mode 4 + low luma bias)

--aq-bias-strength <float>
      Adjust the strength of dark scene bias in AQ modes 3 and 5. Setting this
      to 0 will disable the dark scene bias, meaning modes will be equivalent to
      their unbiased counterparts (2 and 4).
      Default 1.0.

Well, that's just lovely! Have these changes been contributed back to MCW for x265? I've exactly this feature with MCW developers before, and they showed some interest.

I don't really use other private forks much to keep my settings compatible with other x265 implementations. I'm going to try this one out; I have some content types where those tweaks could really make a difference.

[Boulder]

Originally Posted by benwaggoner

Well, that's just lovely! Have these changes been contributed back to MCW for x265? I've exactly this feature with MCW developers before, and they showed some interest.

I don't really use other private forks much to keep my settings compatible with other x265 implementations. I'm going to try this one out; I have some content types where those tweaks could really make a difference.

Unfortunately not, at least I've not seen it discussed in the x265-devel list. In my opinion, it is too difficult to contribute since it's not just about submitting a pull request but requires more effort.

[benwaggoner]

Originally Posted by madey83

What could be your settings recommendation for Dolby vision encoder to have quite small file for 43 minutes episode ( 1-1.5GB)?

Profile 5 or 8.1?

Those file sizes give around 3-4.5 Mbps; pretty darn low for 4K. I'd look at scaling down to 1080p or maybe 1440p. I think only clean animation would encode well at those bitrates. Something with even light noise might require --crf 30 at full resolution. 2-pass encoding could be preferable as final file sizes would vary a lot depending on source specifics.

The job is more about artifact suppression than fine detail retention at those bitrates. So definitely you'll want --sao, default in-loop deb locking, some --nr-intra, maybe some <100 --nr-inter. And I'd start with --preset slower at a minimum.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Very valuable info, thank you. I'd be interested in trying the 5x keyint for lookahead. Does higher lookahead require much more processing time? If so, it really depends on what can be gained from 5x lookahead.

--rc-lookahead can't be higher than --keyint. For single pass encodes when I have enough RAM and time, I try to use keyint=rc-lookahead.

There is some slowdown with higher values, but I find it's relatively cheap as quality/speed tradeoff features go. The bigger limitation is the RAM requirements, which can increase almost linearly with --rc-lookahead. I've had a 60 GB single x265 process doing 8K 10-bit encoding with --rc-lookahead 96.

I have thought about having bit-rate starved on brighter scenes, but I haven't found it to be an issue when bit-rates are high enough. I guess it could be an issue for bit-rate-restricted content. I typically find that black-level detail can still be an issue even on 4K discs. So even using it as a tool to distribute more bits into black-level detail is useful. Do you think this is why it potentially could improve gradients from black to full color? Because there are more bits being distributed in the low end of the spectrum and now the gradients look smoother?

Yeah, --aq-mode 3 lowers QP near black, and so a gradient that has one end that dark will benefit from it.

Using 10-bit instead of 8-bit can also really help gradients in general. And use the --dither parameter if you're encoding at a lower color depth than the source, which can help reduce 8-bit SDR banding as well.

Lots of these things are bitrate related. If you have enough bits, they may not be much of an issue. But if trying to really maximize bang for the bit, careful tuning can really help. Optimal --aq-mode and --aq-strength can vary quite a bit in different shots and scenes.

A whole lot of deep amazing things can be done using x265 as .dll instead of an .exe, where some parameters can be varied by GOP, frame, and even CU.

It'd be lovely to have some sort of standard XML syntax for .dll specific tweaks with an .exe that would parse those and pass them on to the .dll in a predictable and portable way.

Originally Posted by benwaggoner

Profile 5 or 8.1?

Those file sizes give around 3-4.5 Mbps; pretty darn low for 4K. I'd look at scaling down to 1080p or maybe 1440p. I think only clean animation would encode well at those bitrates. Something with even light noise might require --crf 30 at full resolution. 2-pass encoding could be preferable as final file sizes would vary a lot depending on source specifics.

The job is more about artifact suppression than fine detail retention at those bitrates. So definitely you'll want --sao, default in-loop deb locking, some --nr-intra, maybe some <100 --nr-inter. And I'd start with --preset slower at a minimum.

Hi,
Sorry but I did not mention that I will downscale to 1080p profile 5 as original source and for noise source I'd probably use some denise filter.

My preference for encode is crf

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

--rc-lookahead can't be higher than --keyint. For single pass encodes when I have enough RAM and time, I try to use keyint=rc-lookahead.

There is some slowdown with higher values, but I find it's relatively cheap as quality/speed tradeoff features go. The bigger limitation is the RAM requirements, which can increase almost linearly with --rc-lookahead. I've had a 60 GB single x265 process doing 8K 10-bit encoding with --rc-lookahead 96.


Yeah, --aq-mode 3 lowers QP near black, and so a gradient that has one end that dark will benefit from it.

Using 10-bit instead of 8-bit can also really help gradients in general. And use the --dither parameter if you're encoding at a lower color depth than the source, which can help reduce 8-bit SDR banding as well.

Lots of these things are bitrate related. If you have enough bits, they may not be much of an issue. But if trying to really maximize bang for the bit, careful tuning can really help. Optimal --aq-mode and --aq-strength can vary quite a bit in different shots and scenes.

A whole lot of deep amazing things can be done using x265 as .dll instead of an .exe, where some parameters can be varied by GOP, frame, and even CU.

It'd be lovely to have some sort of standard XML syntax for .dll specific tweaks with an .exe that would parse those and pass them on to the .dll in a predictable and portable way.

Great info, thank you.

[benwaggoner]

Originally Posted by madey83

Hi,
Sorry but I did not mention that I will downscale to 1080p profile 5 as original source and for noise source I'd probably use some denise filter.

My preference for encode is crf

Profile 5 can be somewhat challenging for an encoder, as it shifts the PQ EOTF to maximize the dynamic range of the current shot. So, if encoding something that's only 100 nits, it'll expand the Y' range higher so there are more code values.

This looks a lot like fades to the encoder, so having p- and b-frame weighted prediction on is important. The --fades feature could help as well, although I've never actually gotten it to result in different output than not using it.

The expanded range can also through off tools that presume encoding to actually perceptually linear code values. The impact of --nr-* could vary in strength on the same content if they got mapped to different code values. The broader range of code values the image gets mapped to, the stronger the AC coefficients will be, and so the less impact a given --nr-* strength would have.

Long way of saying that it might be better to apply denoising in uncompressed PQ ICtCp before or after scaling, and send denoised frames to the encoder instead of using the built-in tools.

I've not actually tested this empirically, but it seems kind of inevitable barring some DoVi Profile 5 specific optimization in x265 that would compensate for the range expansion.

Originally Posted by benwaggoner

Profile 5 can be somewhat challenging for an encoder, as it shifts the PQ EOTF to maximize the dynamic range of the current shot. So, if encoding something that's only 100 nits, it'll expand the Y' range higher so there are more code values.

This looks a lot like fades to the encoder, so having p- and b-frame weighted prediction on is important. The --fades feature could help as well, although I've never actually gotten it to result in different output than not using it.

The expanded range can also through off tools that presume encoding to actually perceptually linear code values. The impact of --nr-* could vary in strength on the same content if they got mapped to different code values. The broader range of code values the image gets mapped to, the stronger the AC coefficients will be, and so the less impact a given --nr-* strength would have.

Long way of saying that it might be better to apply denoising in uncompressed PQ ICtCp before or after scaling, and send denoised frames to the encoder instead of using the built-in tools.

I've not actually tested this empirically, but it seems kind of inevitable barring some DoVi Profile 5 specific optimization in x265 that would compensate for the range expansion.

Hi,

Thank you for this but this is to deep explanation for me.
I have found below and I would like to ask if belove settings are good or there is something to change to get better results:


Cry Macho 2021 1080p UHD BluRay DD+5.1 DoVi x265-DON

Writing library : x265 3.5+39-931178347:[Windows][MSVC 1933][64 bit] 10bit
Encoding settings : cpuid=1049583 / frame-threads=4 / numa-pools=24 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x804 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / repeat-headers / annexb / aud / no-eob / no-eos / hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=16 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=4 / scenecut=40 / no-hist-scenecut / 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=4 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=4 / limit-refs=1 / limit-modes / me=3 / subme=5 / 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=2.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=13.7 / qcomp=0.80 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.20 / pbratio=1.10 / aq-mode=1 / aq-strength=0.85 / no-cutree / zone-count=8 / zones: / start-frame=112 / end-frame=430 / bitrate-factor=4.000000 / zones: / start-frame=14684 / end-frame=15005 / bitrate-factor=7.000000 / zones: / start-frame=16507 / end-frame=17008 / bitrate-factor=1.500000 / zones: / start-frame=17009 / end-frame=17145 / bitrate-factor=2.000000 / zones: / start-frame=17601 / end-frame=23536 / bitrate-factor=2.500000 / zones: / start-frame=31365 / end-frame=37290 / bitrate-factor=3.000000 / zones: / start-frame=44733 / end-frame=50608 / bitrate-factor=3.000000 / zones: / start-frame=140360 / end-frame=140415 / bitrate-factor=3.000000 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / 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=1134,104 / 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 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / hdr10 / hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / 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 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass



Of course without providing zones to encoder.