x265 HEVC Encoder

[nevcairiel]

ICtCp is definitely used by streaming services for Dolby Vision. Its just metadata though, and you can decode it with any ordinary 10/12-bit capable HEVC decoder (depending on the stream), interpretation of the color data is then typically up to the implementation (ie. by using shaders), or using pass-through to the display.

[Barough]

x265 v3.5+21-7155a58f7 (https://www.mediafire.com/file/hvggc6r6pehjwpx/x265-3.5%252B21-7155a58f7_Win_GCC112.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.3.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[charliebaby]

x265 v3.5+21-7155a58f7 (https://www.mediafire.com/file/hvggc6r6pehjwpx/x265-3.5%252B21-7155a58f7_Win_GCC112.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.3.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master


Thank you for GCC 11.2

[LigH]

New upload: x265 3.5+20-17839cc0d (https://www.mediafire.com/file/cy3ma8e9nr4vm88/x265_3.5+20-17839cc0d.7z/file)

[Windows][GCC 11.2.0][32/32XP/64 bit] 8bit+10bit+12bit

Bugs not yet fixed:

NASM 2.15.05 multi-line macro warnings (reported August 2020)

[tormento]

Is there any option to optimize greyscale (i.e. BW movies) encoding. mostly about speed?

[benwaggoner]

Is there any option to optimize greyscale (i.e. BW movies) encoding. mostly about speed?
That was something that MCW had been looking at some years ago, but it doesn't look like it made it in.

The good news is that, with 4:2:0 chroma subsampling, only 1/3rd of the samples in a frame are color. And there is coarser quantization as well, so chroma compute is probably less than 33% on net. Setting --cbqpoffs and --crqpoffs to 12 would provide chroma with much coarser quantization, which speeds up some things (but would make actual chroma look pretty terrible).

You'd thus want to filter your source to luma-only before encoding to avoid that kind of problem. And IIRC there are some early exits that turn on when a chroma plane is packed with zeros. Give it a shot.

[asarian]

New upload: x265 3.5+20-17839cc0d (https://www.mediafire.com/file/cy3ma8e9nr4vm88/x265_3.5+20-17839cc0d.7z/file)

[Windows][GCC 11.2.0][32/32XP/64 bit] 8bit+10bit+12bit

Bugs not yet fixed:

NASM 2.15.05 multi-line macro warnings (reported August 2020)



FYI, I am currently using this version. Even though I have --frames 211420 on the command line, your version says 'unknown frame count'.

[LigH]

Don't blame me, I only run the compilation. The reason may be related to processing a raw video input stream via pipe instead of physical source file. Using x265 linked in a current ffmpeg may give you a better environment.

[asarian]

Don't blame me, I only run the compilation. The reason may be related to processing a raw video input stream via pipe instead of physical source file. Using x265 linked in a current ffmpeg may give you a better environment.

Isn't the '--frames 211420' supposed to tell x265 how many frames there are?

[Boulder]

Isn't the '--frames 211420' supposed to tell x265 how many frames there are?

The message you are seeing is from the input handling. I don't think I've ever seen a number of frames there when using piping.

The number of frames set in the parameters is only used for calculating the ETA.

[asarian]

The message you are seeing is from the input handling. I don't think I've ever seen a number of frames there when using piping.

The number of frames set in the parameters is only used for calculating the ETA.


Exactly. My entire command line goes like this:

VSPipe -c y4m "f:\jobs\test.vpy" - | x265 --y4m --input - --lossless --preset ultrafast --input-depth 10 --output-depth 10 --crf 10 --colorprim 9 --transfer 16 --colormatrix 9 --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" --max-cll "0,0" --frames 211420 --chromaloc 2 --aq-mode 3 --output "f:\video\test.hevc"

I've always done it like this. I do get the ETA at the end, though

x265 [info]: tools: strong-intra-smoothing lslices=8 deblock
[73.4%] 155199/211420 frames, 1.97 fps, 1008625.25 kb/s, eta 7:54:32

But the top line says

y4m [info]: 3840x2072 fps 24000/1001 i420p16 unknown frame count

[Boulder]

But the top line says

y4m [info]: 3840x2072 fps 24000/1001 i420p16 unknown frame count

This is because it cannot get the amount of frames from the piped stream.

[Boulder]

Without limit-tu, higher values of tu-intra and tu-inter only increase compression, not visual quality. limit-tu 1 + tu-inter 4 + tu-intra 4 should give better quality than using limit-tu 0.

I ran into this remark while once again searching for information regarding TU depth and related things.

Is it actually so that increasing the TU depth only affects compression and that in fact, at least in CRF mode, it can potentially lead to lower detail retention? I've always thought that it is one component which retains detail since it possibly splits into smaller pieces when needed. Or is CTU itself already the major thing in detail retention?

[Asmodian]

Is it actually so that increasing the TU depth only affects compression and that in fact, at least in CRF mode, it can potentially lead to lower detail retention?

It isn't that limit-tu 0 lowers detail retention, but that tu-inter 4 and tu-intra 4 increases detail retention while limit-tu 1 keeps the speed up.

limit-tu 0 with tu-inter 4 and tu-intra 4 would be great, but also slow.

[Boulder]

It isn't that limit-tu 0 lowers detail retention, but that tu-inter 4 and tu-intra 4 increases detail retention while limit-tu 1 keeps the speed up.

limit-tu 0 with tu-inter 4 and tu-intra 4 would be great, but also slow.
There the paradox lies. A higher depth is supposed to increase detail retention, but only if it is limited :confused:

Blade Runner 2049
--tu-inter-depth 4 --tu-intra-depth 4
CTU 64
limit-tu 4 - 4847,24 kbps - 19.57
limit-tu 3 - 4634,72 kbps - 19.54
limit-tu 2 - 4766,69 kbps - 19.61
limit-tu 1 - 4328,30 kbps - 19.82
limit-tu 0 - 3970,48 kbps - 20.15

CTU 32
limit-tu 4 - 5329,45 kbps - 19.29
limit-tu 3 - 5325,54 kbps - 19.28
limit-tu 2 - 5289,30 kbps - 19.31
limit-tu 1 - 5092,24 kbps - 19.40
limit-tu 0 - 5128,37 kbps - 19.47

And if I reduce the depths step by step, depth 1 will produce the highest filesize and also the lowest average QP. The difference is not much, but it's there. Depth 1 is also much faster, about 10% difference in my tests.

Based on a snippet of ~2000 frames, the average QP is much higher the less TU recursion is limited. I've also found out earlier that the combination of CTU 64, rskip 2 and limit-tu 0 is very much b0rked.

[Asmodian]

Shouldn't you compare at the same size? Lower CRF if a setting decreases the size, or better, compare settings with 2-pass so the bitrates are the same.

Are you assuming a setting retains more detail based on how it affects size at the same CRF? It is always possible to make a file bigger and retain more detail. :confused:

[Boulder]

I'd expect this setting to be one which doesn't require varying CRF since it's more like affecting the number of iterations. My question more or less rises from the fact that in x265 development, the focus in some parameters seems to be compressing more and more instead of detail retention. TU depth is one of those I cannot just understand well enough.

[Asmodian]

I'd expect this setting to be one which doesn't require varying CRF since it's more like affecting the number of iterations.

This doesn't make sense to me. Why would affecting the number of iterations not require changing the CRF?

It changes the number of configurations tried, but only one is picked in the end. What "best" means when selecting the best option might not be the one with the highest detail retention, but it could also be that the other options simply don't compress as well.

Unless you compare visually at the same size, I don't see how you can come to any conclusion.

[Boulder]

Can anyone explain why --no-sao and --selective-sao 0 are two different things? What is the encoder doing when --selective-sao 0 is applied but SAO is still enabled? I was doing some testing with --selective-sao 1 and made a comparison encode with --selective-sao 0. I then noticed that it produced a larger file than when --no-sao is used..

--selective-sao 1 - 6635.40 kbps, avg QP 21.72
--selective-sao 0 - 6816.47 kbps, avg QP 21.62
--no-sao - 6641.23 kbps, avg QP 21.72

EDIT: hmm, apparently --selective-sao + --sao is the same as "old --sao".

[benwaggoner]

This doesn't make sense to me. Why would affecting the number of iterations not require changing the CRF?
Why would it? higher --tu-i* depths allow for increasingly smaller TUs relative to --ctu. --tu-intra/inter-depth 4 with --ctu 64 and --tu-inter/intra-depth 3 with --ctu, both allowing a minimum TU size of 4x4.

It changes the number of configurations tried, but only one is picked in the end. What "best" means when selecting the best option might not be the one with the highest detail retention, but it could also be that the other options simply don't compress as well.
Yeah, intra-frame RC can get quite complex. And the smaller the TU, the higher QP can be at similar subjective quality, as there's fewer pixels for ringing or blocking to become visible.

Unless you compare visually at the same size, I don't see how you can come to any conclusion.
I fully agree that comparisons need to be done at the same ABR to really understand the pros/cons. Using CRF adds ABR as a confounding factor.

In my experience, the higher tu depths can be really helpful with low-noise content with sharp edges, like animation, graphics, and text.

They don't do much with grainy/noisy content because so much of the energy of potential TUs is in randomly distributed pixels. This is particularly of grain that has a lot of per-pixel variance. More natural grain that isn't per-pixel randomization is better.

[benwaggoner]

Can anyone explain why --no-sao and --selective-sao 0 are two different things? What is the encoder doing when --selective-sao 0 is applied but SAO is still enabled? I was doing some testing with --selective-sao 1 and made a comparison encode with --selective-sao 0. I then noticed that it produced a larger file than when --no-sao is used..

--selective-sao 1 - 6635.40 kbps, avg QP 21.72
--selective-sao 0 - 6816.47 kbps, avg QP 21.62
--no-sao - 6641.23 kbps, avg QP 21.72

EDIT: hmm, apparently --selective-sao + --sao is the same as "old --sao".
--sao is also the "old sao" ;).

--selective-sao just turns off SAO for specified classes of frames. The only one that really matters is --selective-sao, which only applies SAO to I and P frames. SAO wasn't designed for bidirectional prediction and provides almost no benefit to B and b frames. So --selective-sao 2 is an essentially free minor speed boost. This is pretty orthogonal to the detail preservation/ringing suppression features of SAO, and has little or no visual impact on how SAO operates in x265.

I'd love to have an --sao-parameters that could actually tune the SAO parameters; x265 just uses fixed SAO parameters, so we really only can control in being on/off. An --adaptive-sao would be even better. I don't know of any actual research done in this area, though.

[Boulder]

--sao is also the "old sao" ;).

--selective-sao just turns off SAO for specified classes of frames.
In that case, --selective-sao 0 --sao should disable SAO since --selective-sao 0 is "Disable SAO for all slices" as per the documentation. Looks like a combination which really has not been tested while evaluating the patch..

I've now settled for using --selective-sao 1. SAO has a too strong effect on P-frames to my liking, it clearly removes detail. I-frames are affected only very slightly, which I believe is the real intent of the functionality. Even though they are not to be blindly trusted, distortion related metrics like MDSI and GMSD show improvement in the whole GOP with value 1 compared to other values, or --no-sao. So I think using it only in the first frame of the GOP is most beneficial.

[benwaggoner]

In that case, --selective-sao 0 --sao should disable SAO since --selective-sao 0 is "Disable SAO for all slices" as per the documentation. Looks like a combination which really has not been tested while evaluating the patch..
I concur. If x265 ever gets refactored, both parameters should be replaced with a single --sao-level,

I've now settled for using --selective-sao 1. SAO has a too strong effect on P-frames to my liking, it clearly removes detail. I-frames are affected only very slightly, which I believe is the real intent of the functionality. Even though they are not to be blindly trusted, distortion related metrics like MDSI and GMSD show improvement in the whole GOP with value 1 compared to other values, or --no-sao. So I think using it only in the first frame of the GOP is most beneficial.
That's an interesting result, and not one I've replicated. What sort of content, bitrates, and settings did you test with?

[Boulder]

The source is Fellowship of the Ring EE, frames 140330-141401 in this case. Some static scenes with closeups and panning motion.

https://drive.google.com/file/d/1SnSLipsVQRUNh25xFjRTjcsFjGDNcu45/view?usp=sharing --no-sao
https://drive.google.com/file/d/1pp2MlMauWswcqY6ttbrudSsHMjOGUWFv/view?usp=sharing --selective-sao 1
https://drive.google.com/file/d/13wDN1VVUbgcWiHrmFlGqodqCj3WTl4y5/view?usp=sharing --selective-sao 2

This is the MediaInfo output. --preset slower as the base, then some additional touches. CRF 18, very slight denoising in the script, I'm also doing the green tint fix with a GIMP curve.

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 44 s 711 ms
Bit rate : 6 508 kb/s
Width : 1 920 pixels
Height : 800 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
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.177
Stream size : 34.7 MiB (98%)
Writing library : x265 3.5+21-30cbfda6a:[Windows][GCC 11.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=24 / wpp / no-pmode / no-pme /
no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance /
no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=5 / keyint=480 / gop-lookahead=0 / bframes=10 / b-adapt=2 /
b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=0 / scenecut=40 / no-hist-scenecut / radl=0 / no-splice / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp /
max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=4 / rdoq-level=1 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra /
strong-intra-smoothing / max-merge=2 / limit-refs=1 / limit-modes / me=3 / subme=4 / merange=26 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / no-analyze-src-pics /
deblock=-1:-1 / sao / no-sao-non-deblock / rd=6 / selective-sao=1 / no-early-skip / rskip / rskip-edge-threshold=0.020000 / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra /
splitrd-skip / rdpenalty=0 / psy-rd=1.80 / psy-rdoq=5.00 / no-rd-refine / no-lossless / cbqpoffs=-3 / crqpoffs=-3 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 /
ipratio=1.35 / pbratio=1.25 / aq-mode=1 / aq-strength=1.00 / 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=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=64 / max-luma=940 / 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 / no-hdr10 /
no-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=0 / conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[Kill3rWolf]

The source is Fellowship of the Ring EE, frames 140330-141401 in this case. Some static scenes with closeups and panning motion.

https://drive.google.com/file/d/1SnSLipsVQRUNh25xFjRTjcsFjGDNcu45/view?usp=sharing --no-sao
https://drive.google.com/file/d/1pp2MlMauWswcqY6ttbrudSsHMjOGUWFv/view?usp=sharing --selective-sao 1
https://drive.google.com/file/d/13wDN1VVUbgcWiHrmFlGqodqCj3WTl4y5/view?usp=sharing --selective-sao 2



In my opinion, "no-sao" looks better, clean & provided more details (I'm not so sure..LOL)

I created a comparison screenshot from your video, hopefully, you won't mind:
https://slow.pics/c/JyWTHIUA

Please, everyone, look at comparison 6: Frame number 908. Which one is slightly better here & why?

@Boulder, Could you provide another test with --limit-sao? Same start & end runtime video.

But I found this one: https://amefs.net/en/archives/1470.html (http://amefs.net/en/archives/1470.html)

According to him:

1.limit-sao can limit the artifact caused by SAO in both P and B frames.

2.SAO can improve visual effects. (reduce noise and ringing around edges)

3. I think texture enhance will solve some of the problems, caused by SAO

[Boulder]

The differences in motion are very subtle. However, in frame-by-frame comparison, to me the areas with edges look very slightly better with --selective-sao 1.

Here's --selective-sao 1 --limit-sao: https://drive.google.com/file/d/1zYPp4nZTuRtHbbZ_A-Q1l2NciOeILRDI/view?usp=sharing

[benwaggoner]

The differences in motion are very subtle. However, in frame-by-frame comparison, to me the areas with edges look very slightly better with --selective-sao 1.

Here's --selective-sao 1 --limit-sao: https://drive.google.com/file/d/1zYPp4nZTuRtHbbZ_A-Q1l2NciOeILRDI/view?usp=sharing
Subtle changes only visible in frame-by-frame aren't really psychovisually relevant with moving image content. And x265 certainly has optimizations that presume full-speed playback.

[benwaggoner]

Also, I believe --limit-sao is supposed to be just a performance improvement via early exit, and shouldn't change the look of SAO. But stuff can have unanticipated impacts! Have you seen a material difference with it on versus off?

[_kermit]

what are the current recommended tuning options for 1080p and 4K (HDR) , assuming slow or slower is used?

considering that only motion and not still pictures are of interest?
what are you using?

[tormento]

Guys, as far as I can read on hevc papers and academic studies, sao is now completely safe to be used but in a very few cases.

[rwill]

Guys, as far as I can read on hevc papers and academic studies, sao is now completely safe to be used but in a very few cases.

SAO in HEVC was set in stone in 2013. What do you mean with 'now' ?

[Boulder]

I'd say the problem is in the implementation, not in the feature itself.

[rwill]

I'd say the problem is in the implementation, not in the feature itself.

True, my x265 SAO example (https://forum.doom9.org/showthread.php?p=1949376#post1949376) still stands it seems.

[_kermit]

I've just encoded the same movie again using this (skipped a few params):
x265.exe - --y4m --output-depth 10 --preset slower --crf 22 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --vbv-bufsize 160000 --vbv-maxrate 160000 --rdoq-level 2 --cu-lossless --max-merge 3 --rc-lookahead 25 --lookahead-slices 4 --ref 4 --range limited --hdr --hdr-opt --repeat-headers --aud --deblock -1:-1 --no-strong-intra-smoothing --aq-mode 1 --rskip 2 --rskip-edge-threshold 3 --psy-rd 4 --psy-rdoq 15

with the same result.
Massive tearing, at least I think that's what it's called: https://ibb.co/fSYXTQ0

it's a specific scene of Mission Impossible - Rogue Nation starting at 1.09.56 (original: https://ibb.co/9GhV3wx)

any ideas how to prevent that?
are my params the reason (hence the question above)?

[microchip8]

I've just encoded the same movie again using this (skipped a few params):
x265.exe - --y4m --output-depth 10 --preset slower --crf 22 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --vbv-bufsize 160000 --vbv-maxrate 160000 --rdoq-level 2 --cu-lossless --max-merge 3 --rc-lookahead 25 --lookahead-slices 4 --ref 4 --range limited --hdr --hdr-opt --repeat-headers --aud --deblock -1:-1 --no-strong-intra-smoothing --aq-mode 1 --rskip 2 --rskip-edge-threshold 3 --psy-rd 4 --psy-rdoq 15

with the same result.
Massive tearing, at least I think that's what it's called: https://ibb.co/fSYXTQ0

it's a specific scene of Mission Impossible - Rogue Nation starting at 1.09.56 (original: https://ibb.co/9GhV3wx)

any ideas how to prevent that?
are my params the reason (hence the question above)?

IIRC, rskip 2 doesn't work (well) with a CTU of 64 which is the default if not set

[rwill]

Massive tearing, at least I think that's what it's called: https://ibb.co/fSYXTQ0

it's a specific scene of Mission Impossible - Rogue Nation starting at 1.09.56 (original: https://ibb.co/9GhV3wx)

any ideas how to prevent that?
are my params the reason (hence the question above)?

Looks like encoder/decoder mismatch to me. Try to write out x265 recon to check if this is what x265 had in mind for these pictures or try another decoder ( maybe the reference software ) to see if the problem persists.

[Boulder]

IIRC, rskip 2 doesn't work (well) with a CTU of 64 which is the default if not set

At least if --limit-tu 0 is used.

I'm still trying to decide whether I should use CTU 64 with 1080p or 1440p encodes, but I'm a bit unsure. Based on some testing, CTU 32 does not seem to create as strong "floating noise in the flat background" effect as CTU 64 with standard quality sources, so I'm leaning towards CTU 32.

[Kill3rWolf]

but in a very few cases.

@tormento, Which few cases?

I've just encoded the same movie again using this (skipped a few params):
x265.exe - --y4m --output-depth 10 --preset slower --crf 22 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --vbv-bufsize 160000 --vbv-maxrate 160000 --rdoq-level 2 --cu-lossless --max-merge 3 --rc-lookahead 25 --lookahead-slices 4 --ref 4 --range limited --hdr --hdr-opt --repeat-headers --aud --deblock -1:-1 --no-strong-intra-smoothing --aq-mode 1 --rskip 2 --rskip-edge-threshold 3 --psy-rd 4 --psy-rdoq 15


What (rskip-edge-threshold 3) actaully do? When should increase psy-rd 4 & psy-rdoq? Reason for deblock -1:-1?

Explaining here &/or providing links will be beneficial for me.

[microchip8]

@tormento, Which few cases?



What (rskip-edge-threshold 3) actaully do? When should increase psy-rd 4 & psy-rdoq? Reason for deblock -1:-1?

Explaining here &/or providing links will be beneficial for me.

rskip threshold sets the threshold for rskip 2. The lower, the better/more precise rskip 2 will work.

High values of psy-rd and psy-rdoq help eliminate banding issues far better than using aq-mode 3

deblock -1,-1 lowers the strength of the in-loop deblocker and thus provides a sharper image.

[Kill3rWolf]

High values of psy-rd and psy-rdoq help eliminate banding issues far better than using aq-mode 3.

Currently, I'm using only aq-mode 3 without touching the psy-rd and psy-rdoq (default or auto-detect). Is there any chance higher psy-rd and psy-rdoq values will provide bad quality or any kind of accident?


deblock -1,-1 lowers the strength of the in-loop deblocker and thus provides a sharper image.

What about deblock=1:-3:-3? I don't know why some people (encoders) biased/tendency to use deblock=1:-3:-3. Which one is the safest option to use almost all contents? Less or almost zero Artifacts with sharper image & well detail?

[apophis906]

I've just encoded the same movie again using this (skipped a few params):
x265.exe - --y4m --output-depth 10 --preset slower --crf 22 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --vbv-bufsize 160000 --vbv-maxrate 160000 --rdoq-level 2 --cu-lossless --max-merge 3 --rc-lookahead 25 --lookahead-slices 4 --ref 4 --range limited --hdr --hdr-opt --repeat-headers --aud --deblock -1:-1 --no-strong-intra-smoothing --aq-mode 1 --rskip 2 --rskip-edge-threshold 3 --psy-rd 4 --psy-rdoq 15

with the same result.
Massive tearing, at least I think that's what it's called: https://ibb.co/fSYXTQ0

it's a specific scene of Mission Impossible - Rogue Nation starting at 1.09.56 (original: https://ibb.co/9GhV3wx)

any ideas how to prevent that?
are my params the reason (hence the question above)?

As far as I can tell that is a decoder issue. I have had that happen on a few myself. With both Mortal Kombat animated UHD and then Halloween 2018 UHD. It would mess up like that on my htpc but not the pc I encoded it with, or when I used software decoding. My htpc has an EVGA GTX 1060 SC 6GB, and I have two htpc's for different rooms and they both react the same way.
After the third one I tested and changed from slow to slower due to it not happening with that change. Even with that it still happened with Shang Chi. So then I started to test a bunch of changes and decided to try changing the IP ratio to 1.3 and PB ratio to 1.2. That got all of those to do fine, but then caused Black Widow to mess up when it had not before. In the end I put the IP and PB back to stock and turned on selective SAO 1 and that got all of them to not do it. So far I have not have any UHD show that problem, but only been using that setting a few weeks so far.
I did have an HD show do it last night though. It was the remastered Gundam Seed episode 47. It cuts to a computer screen and you see a radar image, then a solid yellow frame for one frame and then a weapons chart for 7 frames. Then you get another solid yellow frame for one frame and a selection menu. On playback with my settings it was all yellow with just the letters all messed up trying to show. My solution was to add the two frames right after the yellow single frame to the QP file and set them to an I frame. That cleared it up and had it play fine.
My advice is you just have to test settings to see what works for you and your playback device. If this is the only movie that has given you any trouble then the simplest option is to find the frame that is at the start of the error and add that to a QP file and set it to an I frame. That should clear it up for you. Just know if you use Staxrip like I do and you chunk encode, that any QP setting after the first chunk doesn't go through and will only take effect for the first chunk. Now if this happens to a few movie then you will need to play around with settings and see what avoids this with your playback device.

[microchip8]

Currently, I'm using only aq-mode 3 without touching the psy-rd and psy-rdoq (default or auto-detect). Is there any chance higher psy-rd and psy-rdoq values will provide bad quality or any kind of accident?

it's safe to use high values of psy-rd/psy-rdoq. I use them all the time and have yet to see something wrong. Make sure you use aq-mode 1 when using high values.

What about deblock=1:-3:-3? I don't know why some people (encoders) biased/tendency to use deblock=1:-3:-3. Which one is the safest option to use almost all contents? Less or almost zero Artifacts with sharper image & well detail?

-3:-3 is a good balance between deblocking and preserving detail/sharpness. The default in x265 softens the image too much. I also use -3:-3 for all my encodes

[_kermit]

IIRC, rskip 2 doesn't work (well) with a CTU of 64 which is the default if not set

I removed it, seems to work, thanks!
But it also cut FPS in half.
How can I improve that again?

[Boulder]

Use --ctu 32. Rskip 2 is useful for retaining details, CTU 64 much less (if at all) so.

[_kermit]

it's safe to use high values of psy-rd/psy-rdoq. I use them all the time and have yet to see something wrong. Make sure you use aq-mode 1 when using high values.



-3:-3 is a good balance between deblocking and preserving detail/sharpness. The default in x265 softens the image too much. I also use -3:-3 for all my encodes

what are high values for psy-..?

[microchip8]

what are high values for psy-..?

3 and above for psy-rd, 5 and above for psy-rdoq. I personally use 4 for psy-rd and 15 for psy-rdoq. This due to encountering a lot of banding while encoding Blade Runner 2049 blu-ray. aq-mode 3 couldn't cut it so I went over to psy-* which worked perfectly. Ever since then I've been encoding different content with these psy values and never had banding again (unless it's present in the source itself)

[microchip8]

I removed it, seems to work, thanks!
But it also cut FPS in half.
How can I improve that again?

use rskip 1 and ctu 32

[_kermit]

use rskip 1 and ctu 32

thanks for both tips!

[Kill3rWolf]

3 and above for psy-rd, 5 and above for psy-rdoq. I personally use 4 for psy-rd and 15 for psy-rdoq. This due to encountering a lot of banding while encoding Blade Runner 2049 blu-ray. aq-mode 3 couldn't cut it so I went over to psy-* which worked perfectly. Ever since then I've been encoding different content with these psy values and never had banding again (unless it's present in the source itself)

Do these tricks apply to both CRF & Target Bitrate encoding?

[microchip8]

Do these tricks apply to both CRF & Target Bitrate encoding?

Yes they do