x265 Sharpness and Detail (Best Settings?)

[benwaggoner]

Could you give me your command line instead? That's easier to parse.

[madey83]

Originally Posted by benwaggoner

Could you give me your command line instead? That's easier to parse.

This is not mine. I found it on internet

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

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


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

Do you any other settings that could improve detail? How about rskip=0? Is this a setting that is good for grain retention? If it's good for grain retention, could it also be good for small details that are not grain?

Thanks.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Do you any other settings that could improve detail? How about rskip=0? Is this a setting that is good for grain retention? If it's good for grain retention, could it also be good for small details that are not grain?

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.

Okay, thank you. Now, what is it about ctu=32 that has a benefit over ctu=64? This isn't something I know anything about. I just assumed it defaults to 64 and that's where it should be.

Does it just give more control over each block? Would this increase bit-rates?

Thanks.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.

As with tskip, it has a mode where it can be useful, but use less resources with --tskip-fast. If use rskip, are 0, 1, and 2 just less and less levels of rskip, or are they completely different rskip modes meant for different content? What really asking, is there an rskip-fast like the tskip-fast, because it's extremely useful.

I wanted to ask a bit more about aq-mode=3 and aq-strength. I believe aq-strength ranges from 0 (off) to 3 (full), But, when you set aq-strength to 3 what is that really doing? Is it trying to place 100% of it's bit-rate in darker areas? Or is there a cap even when set to 3 that only, say, 25% of it's bit-rate looks fo darker content?

----Lets just say it looked for 25% of it's bit-rate to be added in dark areas. If I lower aq-strength from 3 to 1.5, would that mean it it not distributes 12.5% of it's bit-rates into dark areas?

I'm just trying to understand how aq-strength works in relation to aq-mode 3.

Thanks.

[benwaggoner]

All your questions and more are answered at: https://x265.readthedocs.io/en/master/cli.html

It specifies the data type of each parameter.

For --rskip, --rskip 2 is the mode you want to use (deprecating the older, poor at grain default --rskip 1). You control speed/quality tradeoff with --rskip 2 with the --rskip-edge-threshold parameter. Lower values are slower but more accurate. The default is 5, and I like to use 2-3 for high quality encoding.

I'm not aware of any methods to estimate the bitrate impact of different --aq-modes, as they are quite content dependent.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

All your questions and more are answered at: https://x265.readthedocs.io/en/master/cli.html

It specifies the data type of each parameter.

For --rskip, --rskip 2 is the mode you want to use (deprecating the older, poor at grain default --rskip 1). You control speed/quality tradeoff with --rskip 2 with the --rskip-edge-threshold parameter. Lower values are slower but more accurate. The default is 5, and I like to use 2-3 for high quality encoding.

I'm not aware of any methods to estimate the bitrate impact of different --aq-modes, as they are quite content dependent.

I appreciate it thank you.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I've found --rskip 2 --rskip-threshold 2 or 3 works well with typical film grain, without as big a speed hit as --rskip 0.

Raising --psy-rd and --psy-rdoq some can help. Try 3 for each as a starting point.

--ctu 32 for sure

The built-in --nr-inter and --nr-intra aren't particularly advanced denoising filters, but as they operate at the quantization phase, can offer bigger compression efficiency benefits than other methods. Start with something like --nr-intra 100 --nr-inter 400. --nr-intra is a spatial denoising filter and --nr-inter is temporal, which is why we use a good multiple higher as film grain is all temporal.

With all the settings I'm using to pull out as much detail as possible using x265. One setting that Ive forgot about is cu-lossless. Can this help pull out more detail in grain and fine particles?

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

With all the settings I'm using to pull out as much detail as possible using x265. One setting that Ive forgot about is cu-lossless. Can this help pull out more detail in grain and fine particles?

No, --cu-lossless just tries mathematically lossless encoding for a given CU, and picks it if it is lower bitrate/distortion. In essence it's a really specialized and compute-intensive subset of --tskip. It would only be used with very high bitrates or some very specialized patterns, like a fully noise-free digitally rendered black/white checkerboard pattern, color bars, or something artificial like that. Grainy content is pretty much the inverse of when it might be helpful.

I've never found a real-world scenario where --cu-lossless would be useful for a distribution encode. Perhaps for a mezzanine file. --tskip should capture most or all of the value at a much lower performance hit. There's no --cu-lossless-fast equivalent to --tskip-fast.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

No, --cu-lossless just tries mathematically lossless encoding for a given CU, and picks it if it is lower bitrate/distortion. In essence it's a really specialized and compute-intensive subset of --tskip. It would only be used with very high bitrates or some very specialized patterns, like a fully noise-free digitally rendered black/white checkerboard pattern, color bars, or something artificial like that. Grainy content is pretty much the inverse of when it might be helpful.

I've never found a real-world scenario where --cu-lossless would be useful for a distribution encode. Perhaps for a mezzanine file. --tskip should capture most or all of the value at a much lower performance hit. There's no --cu-lossless-fast equivalent to --tskip-fast.

Thanks, will run some more encodes to see what it's giving me. I'll also run some film grain tests, but as you said, it's very compute-intensive, and you need a monster setup to run this. It's okay for 4-minute content to test, but for full movies, it's a real struggle.

I appreciate the feedback.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

No, --cu-lossless just tries mathematically lossless encoding for a given CU, and picks it if it is lower bitrate/distortion. In essence it's a really specialized and compute-intensive subset of --tskip. It would only be used with very high bitrates or some very specialized patterns, like a fully noise-free digitally rendered black/white checkerboard pattern, color bars, or something artificial like that. Grainy content is pretty much the inverse of when it might be helpful.

I've never found a real-world scenario where --cu-lossless would be useful for a distribution encode. Perhaps for a mezzanine file. --tskip should capture most or all of the value at a much lower performance hit. There's no --cu-lossless-fast equivalent to --tskip-fast.

You're right, I tested this on grain content, and I got the exact same results, right down to the average QP. Hmm, interesting, good to know. I was also using tskip, and both encodes with cu-lossless and without have the exact same results. It may as well have been the exact same file. Very interesting.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

You're right, I tested this on grain content, and I got the exact same results, right down to the average QP. Hmm, interesting, good to know. I was also using tskip, and both encodes with cu-lossless and without have the exact same results. It may as well have been the exact same file. Very interesting.

Yep, that's what will happen if x265 doesn't detect any CUs where lossless encoding has better rate/distortion. Which I would expect if the clip is all grainy frames.

You may not be getting any benefit from --tskip either. It can help with noise-free credits in grainy movies, but isn't going to be useful for any CU with significant random noise. It's pretty hard to simply spend more compute to make grainy content look better than --preset slower. What improves grain is using the --nr-i* features, lowering ipratio and pbratio, and other things that are more qualitative tuning, not just more expensive modes.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

Yep, that's what will happen if x265 doesn't detect any CUs where lossless encoding has better rate/distortion. Which I would expect if the clip is all grainy frames.

You may not be getting any benefit from --tskip either. It can help with noise-free credits in grainy movies, but isn't going to be useful for any CU with significant random noise. It's pretty hard to simply spend more compute to make grainy content look better than --preset slower. What improves grain is using the --nr-i* features, lowering ipratio and pbratio, and other things that are more qualitative tuning, not just more expensive modes.

Good to know, and thank you for the advice.