x265 Parameter help

[iKron]

1. how no-sao can help?

2. can someone explain CTU 64 vs 32?


3. does no-sao works at CTU 32X32 level?
https://forum.doom9.org/showthread.php?p=1712153#post1712153

4. what is rskip?

5. i found rskip=0 makes the moving scene less pixelated. however most people are saying to use rskip=2. someone even said we use rskip=0 only for placebo preset.

6. closed GOP vs open GOP. can someone please explain?

7. i found peoples are adding b-frame, limit-refs etc. doesn't preset auto determine the best parameter for those?

[jpsdr]

I'll add a question.
According the online documentation the --aq-motion option is tagged as experimental feature.
Is it still the case ?
Does someone has any feedback with it ?

[jpsdr]

Another question.
With multipass "high" average bitrate on 4k video such as :
vbv-maxrate=90000
vbv-bufsize=70000
bitrate=40000
Is it realy interesting/necessary to keep the strong-intra-smoothing enabled by default ?

[excellentswordfight]

1. how no-sao can help?

SAO ( Sample Adaptive Offset loop filter) tends to blur the image/remove details. Its generally preferred to turn it off with no-sao. Although it might be beneficial for low bitrates and/or animation.


2. can someone explain CTU 64 vs 32?

Read the docs (https://x265.readthedocs.io/en/master/cli.html), generally speaking I would say that users are lowering to get better thread usage/speed gain for lower resolutions. The question was raised a couple of years ago with the developers why this wasnt automatically lowered for low res inputs as such a large CTU seems a bit overkill there, but the answer was that they saw benefits of it even for resolutions bellow 2160p. It seems like some are lowering it for other reasons, but I haven't really understood the rational for that.

3. does no-sao works at CTU 32X32 level?
https://forum.doom9.org/showthread.php?p=1712153#post1712153

Yes

4. what is rskip?

Its described in the docs

5. i found rskip=0 makes the moving scene less pixelated. however most people are saying to use rskip=2. someone even said we use rskip=0 only for placebo preset.

Rskip is used for speed gains, not for compression gains, turning it off (rskip=0) has a rather large speed penalty.

6. closed GOP vs open GOP. can someone please explain?

First hit on google https://streaminglearningcenter.com/blogs/open-and-closed-gops-all-you-need-to-know.html

There are scenarios were it needs to be turned off, but in terms of compression open GOP is beneficial. For normal file based playback there is little reason to use closed GOP.


7. i found peoples are adding b-frame, limit-refs etc. doesn't preset auto determine the best parameter for those?
Cause the "best" value might not be universal. Not all content will use that many sequental bframes even if increased, and in some cases it might even hurt quality. Personally I only go above 4 for HFR and anime (tune animation does increase this value as well).


Is it realy interesting/necessary to keep the strong-intra-smoothing enabled by default ?
This use case is a bit different from yours but you can look at this thread to see an example of the effect of sao, deblock & strong-intra-smoothing. I have never seen any benefit of turning it off.

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

[Boulder]

It seems like some are lowering it for other reasons, but I haven't really understood the rational for that.

I've seen CTU 64 cause lower quality in flat, slightly noisy backgrounds. I use CTU 32 even with 1440p encodes.

[jpsdr]

After reading, as i encode 4k denoised video, for now it seems that :
I keep strong-intra-smoothing in all my cases.
Maybe keep sao for animation only cases.

[benwaggoner]

The authoritative reference for everything x265 is here: https://x265.readthedocs.io/en/master/. It is, by a huge margin, the best encoder documentation of this millennium.

As for your specific questions:
SAO:
SAO is definitely helpful at bitrates where QPs hit the mid 20's or higher. With higher QPs, the ringing details that SAO reduces are a much bigger deal than the relatively minor detail preservation. Note that the linked post is comparing zoomed in high detail regions of a still frame. These aren't the sort of differences viewer are really going to notice watching the content playing at normal scaling.

I set SAO on except for higher bitrates and more complex content.

The dynamics are a lot different in adaptive streaming over IP networks versus file-based or LAN use cases. With adaptive streaming, the goal is for only the top bitrate to provide transparency, and then for all the rungs below that to have the maximum reduction in bitrate proportional to a material but not jarring reduction in quality.

aq-motion:
--aq-motion was an interesting idea for a psychovisual optimization, but it never became something that was appropriate to use for any clear scenario. Further work on it was abandoned many years back, and it is probably even less useful now given other improvements to x265's default behavior since then.

CTU:
Yeah, I've seen --ctu 64 offer visual improvements down to 512x288 resolutions when using very low bitrates. When tuning those things, it's interesting to look at the --log-level 2 output and see the frequency of what block types are selected. Some content and bitrates won't get many 64x64 at all, others a good number. I believe those numbers are a percentage of block types, not a percentage of block area, so one 64x64 covers the area of 64 8x8s, so even a low percentage of 64x64 can still account for a lot of the frame.

Ideally, the percentages should be normalized for area covered, not just ratios of block types, which radically overstates the amount of the frame covered by small block types.

[benwaggoner]

Oh, and for --preset setting b-frames and --limit-refs, etcetera. Yes, the do offer pretty well balanced combinations for a given speed/quality for general use across a range of content. Tuning beyond that is generally content and/or scenario specific.

The biggest missing thing is that --selective-sao 2 really should be on by default for veryslow and below. The presets haven't been updated for some years now, since before --selective-sao was added (and some other features).

[Blue_MiSfit]

Note that the linked post is comparing zoomed in high detail regions of a still frame. These aren't the sort of differences viewer are really going to notice watching the content playing at normal scaling.

I set SAO on except for higher bitrates and more complex content.

...

With adaptive streaming, the goal is for only the top bitrate to provide transparency, and then for all the rungs below that to have the maximum reduction in bitrate proportional to a material but not jarring reduction in quality.



QFT. SAO is imperfect in x265, but it's extremely helpful at lower bitrates. It's very easy to be misled if you do still image comparison because yes, it will blur some details. The point is, it's incredibly effective at suppressing low bitrate blocking / ringing artifacts which are very distracting when you're being a human and watching the content.

Net/net when you're at a lower bitrate you're usually better off keeping higher resolution and having SAO turned on than you are turning it off and reducing resolution.

There's exceptions, but this is my default. I disable SAO when I'm confident I can reach transparency (e.g. 20+ Mbps for UHD on most content).

[rwill]

QFT. SAO is imperfect in x265, but it's extremely helpful at lower bitrates. It's very easy to be misled if you do still image comparison because yes, it will blur some details. The point is, it's incredibly effective at suppressing low bitrate blocking / ringing artifacts which are very distracting when you're being a human and watching the content.

Net/net when you're at a lower bitrate you're usually better off keeping higher resolution and having SAO turned on than you are turning it off and reducing resolution.

There's exceptions, but this is my default. I disable SAO when I'm confident I can reach transparency (e.g. 20+ Mbps for UHD on most content).

So they have fixed the issue that happens when encoding material with film grain or similar like this:
https://drive.google.com/file/d/1U_lReuKcaFqwJbfI51lredQT1EqMkyY8/view?usp=sharing ?

Odd, I thought I was monitoring their commits pretty closely.

[iKron]

thank you for all the explanation :)

if source is 8 bit x264 is it wise to encode in 10bit x265? will we get any benefit?

is there command line for x265 encode which will copy the source video bit depth?

[Boulder]

if source is 8 bit x264 is it wise to encode in 10bit x265? will we get any benefit?

Re-encoding that only introduces more artifacts etc. I'd say that in 99,9% of the cases, it's not a good idea and will not have any benefits.

[jpsdr]

I disable SAO when I'm confident I can reach transparency (e.g. 20+ Mbps for UHD on most content).

According all these posts, it seems i can (and i will) disable it with these settings :
vbv-maxrate=90000
vbv-bufsize=70000
bitrate=40000

Your posts confirm what i begun to think : It's usefull for low bitrate, but not for high bitrate, and even more, it can be harmfull.

[benwaggoner]

Re-encoding that only introduces more artifacts etc. I'd say that in 99,9% of the cases, it's not a good idea and will not have any benefits.
Yeah, reencoding of a x264 encode only makes sense if you're willing to sacrifice some quality and a fair bit of time to reduce file size significantly.

Fundamentally, all lossy compression is about sacrificing some quality and time to get smaller files. No point unless the source is too big to be used directly. Reencoding from DVD made more sense as MPEG-2 didn't have any in-loop deblocking, so it was pretty easy to improve the quality of the source before reencoding by applying deblocking filters, thus getting a smaller and better looking file.

But in the H.264/HEVC/VVC/etc era, quality improvements are much smaller and harder to get. With storage so cheap, it's generally best to just remux the original compressed bitstream if the source was already compressed for distribution.

[iKron]

@benwaggoner thank you for all the input sir!

does no-fast-pskip option works on x265 VBR 2 pass mode? after encode done i could not see this info inside media info.

[PatchWorKs]

if source is 8 bit x264 is it wise to encode in 10bit x265? will we get any benefit?

Yes:

encoding pictures using 10-bit processing always saves bandwidth compared to 8-bit processing, whatever the source pixel bit depth

When encoding with the 10-bit tool, the compression process is performed with at least 10-bit accuracy compared to only 8-bit otherwise. So there is less truncation errors, especially in the motion compensation stage, increasing the efficiency of compression tools. As a consequence, there is less need to quantize to achieve a given bit-rate.
The net result is a better quality for the same bit-rate or conversely less bit-rate for the same quality: between 5% and 20% on typical sources.

Source: Why does 10-bit save bandwidth (even when content is 8-bit)?
(https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

[nevcairiel]

Note that this effect is greatly diminished in h265 due to increases in internal precision, the huge advantage was only present in h264. But its generally not _worse_ to encode in 10-bit assuming your target playback device can handle it.

[jpsdr]

About 10 bits precision/processing with 8 bits contents, the only experience i have is with x264, and the only thing i can said is that if you have noise/grain, the bitrate explode, and you absolutely don't have the same quality (even less better) for the same bitrate.
But... If you're clean and without noise/grain, you have indeed a better quality for the same bitrate.

[Forteen88]

if source is 8 bit x264 is it wise to encode in 10bit x265? will we get any benefit?

is there command line for x265 encode which will copy the source video bit depth?
Reencoding it to 10-bits will get you less banding and saves some bitrate compared to if you reencoded it to 8-bit.
https://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

[iKron]

thank you guys, for giving all the advice. i really appreciate. video encoding testing is really time consuming. without your advice/suggestion it would take me a tons of time to figure it out.