x265 HEVC Encoder

[asarian]

Originally Posted by Boulder

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]

Originally Posted by asarian

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]

Originally Posted by fauxreaper

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]

Originally Posted by Boulder

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]

Originally Posted by Asmodian

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

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.

[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]

Originally Posted by 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.

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]

Originally Posted by Asmodian

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]

Originally Posted by 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".

--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]

Originally Posted by benwaggoner

--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]

Originally Posted by Boulder

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/1SnS...ew?usp=sharing --no-sao
https://drive.google.com/file/d/1pp2...ew?usp=sharing --selective-sao 1
https://drive.google.com/file/d/13wD...ew?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]

Originally Posted by 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/1SnS...ew?usp=sharing --no-sao
https://drive.google.com/file/d/1pp2...ew?usp=sharing --selective-sao 1
https://drive.google.com/file/d/13wD...ew?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

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/1zYP...ew?usp=sharing

[benwaggoner]

Originally Posted by 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/1zYP...ew?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.