x265 Sharpness and Detail (Best Settings?)

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Interesting, are you seeing better encodes using CTU=32? I've seen one encode where the QP only dropped by 0.1 on average, so I didn't know whether to use it or not.

In theory can CTU=32 grab more detail than 64? I might just run some tests for even lower than 32 just to see it.

I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.

Thats interesting. Does CTU=32 typically cost more bit-rate to use than CT=64? Is CTU=64, typically better for animation with plain objects, like plain skies, where CTU=64 would be more useful?

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I have seen --ctu 32 provide better quality with very grainy content at 4K and HD resolutions.

I noticed that --hme has some settings that goes with it.

--hme-search between 0,1,2. Is 2 the best? / Highest setting?

--hme-range between 0,1,2. Same question.

Is 2 for both settings maxed out?

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

Thats interesting. Does CTU=32 typically cost more bit-rate to use than CT=64? Is CTU=64, typically better for animation with plain objects, like plain skies, where CTU=64 would be more useful?

Yes, its main value is increased compression efficiency for big flatter/gradient areas. It's not a big improvement; 32x32 is already much bigger than prior codecs supported.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

I noticed that --hme has some settings that goes with it.

--hme-search between 0,1,2. Is 2 the best? / Highest setting?

--hme-range between 0,1,2. Same question.

Is 2 for both settings maxed out?

The are documented here: https://x265.readthedocs.io/en/maste...search-options

--hme-search is 0-5, just replicating the --me options.
--hme-range replicates --merange, and so can be anything from 0 to 32768

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

The are documented here: https://x265.readthedocs.io/en/maste...search-options

--hme-search is 0-5, just replicating the --me options.
--hme-range replicates --merange, and so can be anything from 0 to 32768

I appreciate it thanks. Have you experimented with any specific settings here? Are the defaults more than fine?

Is search best at 5, but say, the hme range to follow whichever settings you use for merange? Which for me is 57.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

I appreciate it thanks. Have you experimented with any specific settings here? Are the defaults more than fine?

Is search best at 5, but say, the hme range to follow whichever settings you use for merange? Which for me is 57.

I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.

Interesting, thanks.

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

I've not found any material quality or performance benefit form using --hme instead of not. x265 doesn't seem to be doing frame or GOP level parallelism for the different sizes, so practical speed benefits are a real challenge. I believe the engineering was more focused on the UHDKit product's ability to simultaneously encode, for example, a 540p, 1080p, and 2160p with each higher resolution reusing the motion search of the prior resolution, and getting parallelism from that.

I can see some combination of coarser --me with a wider net (note that 24 px at the 25% size would be 96 px in the final frame) search range for the lower resolutions, and a more precise me with a smaller search range at the higher makes intuitive sense as a potential quality/speed tradeoff improvement. I've not dived deep to try and find that combination, however.

There was some early talk from MCW some years ago that --hme would help improve quality with very grainy content, as the low pass filtering of the downscales would exclude false positive motion vectors resulting from random grain matches, with the full resolution pass refining on the initial matches. Which makes intuitive sense, but I never saw an actual PoC of this benefit.

I didn't find any benefit in a couple of rounds of initial testing. It's on my backlog of things to noodle with further time permitting.

One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?

[microchip8]

Originally Posted by HD MOVIE SOURCE

One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?

hme has its own search radius, which you can set using --hme-range

[HD MOVIE SOURCE]

Originally Posted by microchip8

hme has its own search radius, which you can set using --hme-range

Okay, thank you. I haven't had much experience with this so I'm still learning how hme affects other settings. Thanks

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

One thing I've noticed, and I think it's when I started using hme, and that's...Even when I set my encoder to placebo, me=2 gets set to 2 and I believe placebo should be set to 5. merange=48 gets set to 48 and placebo is 92.

I re-encoded with me=5 and that got set fine. However, I set merange to the default of 57 and it still gets set to 48. Is hme controlling this?

When you're using --hme, the --hme-search and --hme-range override --me and --me-range. So --preset has no impact on those.

To get a "placebo" --hme, you'd probably use

--hme-search 3,3,3 --hme-range 92,92,92

it's the last digit of each that's most important, as those are for the full resolution final pass. I imagine that

--hme-search 2,2,3 --hme-range 57,57,92

Would give you essentially equal results.

I don't think that --hme would offer much benefit at all in placebo. To get a better speed-quality benefit, something like the below would be more likely to be net beneficial. HME techniques are generally about improving quality @ speed, not maximum quality when not speed bound.

--hme-search 2,2,3 --hme-range 25,25,26

Where the motion search range can be constrained for the higher resolution passes as the coarser stages were able to identify good matches to refine in the later stages. a 25 range at quarter resolution maps to 100 at the final resolution.

(25 constrains motion search to 32x32 in hex, as does 26 to 32x32 in star. That allows another 32x32 row to be parallelized in WPP versus higher values).

[HD MOVIE SOURCE]

Originally Posted by benwaggoner

When you're using --hme, the --hme-search and --hme-range override --me and --me-range. So --preset has no impact on those.

To get a "placebo" --hme, you'd probably use

--hme-search 3,3,3 --hme-range 92,92,92

it's the last digit of each that's most important, as those are for the full resolution final pass. I imagine that

--hme-search 2,2,3 --hme-range 57,57,92

Would give you essentially equal results.

I don't think that --hme would offer much benefit at all in placebo. To get a better speed-quality benefit, something like the below would be more likely to be net beneficial. HME techniques are generally about improving quality @ speed, not maximum quality when not speed bound.

--hme-search 2,2,3 --hme-range 25,25,26

Where the motion search range can be constrained for the higher resolution passes as the coarser stages were able to identify good matches to refine in the later stages. a 25 range at quarter resolution maps to 100 at the final resolution.

(25 constrains motion search to 32x32 in hex, as does 26 to 32x32 in star. That allows another 32x32 row to be parallelized in WPP versus higher values).

I really appreciate the explanation on this, because I've been testing some search and range settings for hme and my encodes have been crashing. Now, you've provided the command lines to be more understandable I'll give them a try.

I've recently been testing placebo vs straight hme, and hme gave me 0.1 QP average QP more than not using it vs placebo that then uses me=5 and 92 for the merange.
Interestingly enough the hme encode was faster than placebo when just stating hme, and not stating the range or search values. So, I think you might be right that under placebo it may not be needed. However, now knowing what I can change, I might be able to eek more out of it, LOL.

Placebo with no hme = Job completed (Elapsed Time: 8h 16m)
Placebo with basic hme turned on = Job completed (Elapsed Time: 7h 09m)

Placebo with no hme average QP= Avg QP:8.74
Placebo with basic hme turned on = Avg QP:8.73

So, unless you can tune hme significantly with the settings you said
--hme-search 3,3,3 --hme-range 92,92,92, maybe there's some more quality to be gained? But, I assume you'd lose speed with these settings vs the default which is 16,32,48 for the range, but I'm not sure what for the search.

My media info says hme / Level / merange / L0,L1,L2=16,32,48, which is me just stating hme in the command line. I did a search for hme-search and that isn't there. I assume that you have to manually state that?

The big this is, is there a visual difference when using hme vs not using it when using placebo? Also, I wonder when the speed crosses over? Meaning, I wonder which preset hme becomes slower? Because the merange is always 57 on every other preset. If hme-range is the equivalent and by default only goes to 48, is hme always better to use?

hme-range <integer>,<integer>,<integer> is the last number the most important number? Does the first and second number matter if they are lower-resolution searches?

Thanks.

[microchip8]

If you're encoding Full HD or lower, I wouldn't bother with HME.

[benwaggoner]

Originally Posted by HD MOVIE SOURCE

My media info says hme / Level / merange / L0,L1,L2=16,32,48, which is me just stating hme in the command line. I did a search for hme-search and that isn't there. I assume that you have to manually state that?

It's the same values as --me and --me-range, so

--hme-search:
0: dia
1: hex (default)
2: umh
3: star
4: sea
5: full

Thus the default search modes for HME are Dia for 1/4 res, Hex for 1/2 res, and UMH for full res. --preset placebo uses 3: Star. So for placebo-equivalent you'd want at least the third --hme-search value to be 3.

The big this is, is there a visual difference when using hme vs not using it when using placebo? Also, I wonder when the speed crosses over? Meaning, I wonder which preset hme becomes slower? Because the merange is always 57 on every other preset. If hme-range is the equivalent and by default only goes to 48, is hme always better to use?

You can always use --me 48. But the key goal of a HME algorithm is that you can do an initial coarse search at a lower resolution, and then refine with more accuracy but smaller search range as the resolutions go up. So, in theory, a --me 92 gets handled by having the first motion search range be 92/4=23. There are intricacies between search modes and such, but that's the basic idea.

hme-range <integer>,<integer>,<integer> is the last number the most important number? Does the first and second number matter if they are lower-resolution searches?

I'm not sure which number is the most "important" - it gets down to finding the right combination of quality, speed.

Sure --hme-search 3,3,3 --hme-range 24, 48, 92 should match placebo quality, but I don't know that it would look better than placebo, or that it would save any encoding time.

[N'Cha]

[QUOTE=benwaggoner;1975353]

Originally Posted by HD MOVIE SOURCE

Hi,

I'm looking to find settings that increase detail and sharpness. In turn, I'm also looking for settings that apply blurring or softness and can be turned off.

Here are the settings that I know of so far that do this.

1. subme=7 (A sharpener, detail increase)
2. no-deblock / deblock (Blurring/detail loss the more deblock is used)
3. no-sao / sao (High Blur)
4. no-strong-intra-smoothing / strong-intra-smoothing (Smoother/Blur)
5. psy-rd=-- & psy-rdoq=-- rdoq-level=-- (Detail increase as the cost of accuracy - Can look over-digital)

I am unaware of any evidence that --strong-intra-smoothing reduces visible detail in any scenario.
Nor does --deblock if used appropriately. Both will reduce detail at moderate-low bitrates, as they reduce compression efficiency and drive QPs higher, which itself is a low-pass filter. The HEVC built-in deblocking filter is better turned than H.264's.

--subme only goes up to 5 in --preset placebo. I've not seen visible quality improvements from using higher values.

If you have sharp synthetic details (text, line art, noise-free anime), --tskip can increase detail.

In theory --hme can help with very noisy content.
--amp and --rect can improve detail by allowing TUs to better match the shape of content, for example encoding a mild horizontal curve as 32x8 instead of forcing it to be square.

But in general, a lot of these things are controlled by the preset. It's best to pick the slowest preset that is fast enough, and start tweaking from there.


That "blurrs" differences in QP to reduce quality fluctuations. It has no direct impact on sharpness.


I'd start doing a test encode at --preset slower --crf 18 --no-sao and see if the detail retention and file size are okay for you. If not, tweak from there. Jumping in with parameters without having some reference encodes to compare with the source and each other makes for a lot more work.

Is it still your opinion that subme 7 is not sharper/more detailed than subme 5 ? (especially for anime)

[benwaggoner]

Originally Posted by N'Cha

Is it still your opinion that subme 7 is not sharper/more detailed than subme 5 ? (especially for anime)

I haven't tested this is many years, but I'm not aware of any changes that could make a difference. MCW's testing showed that --subme 7 wasn't even worth using in --preset placebo.

If anyone has more recent or specific results, I'd love to hear about them!

[brad86]

Recently found a good balance of settings and quality I would like for my encodes, except for one issues that I can not seem to fix.
I'm getting a great image overall with these settings, other than blurring near the top of the canvas. It's like it doesn't know how to handle the edge very well.
I would love to find a setting that can stop this. A lower CRF value (even 0 for testing) does not stop it. aq-strength, is really the only tweak I make between different films (1.0-1.3), but again, even a high value here does not help.

You can see the issue I'm having below.



My settings current settings are;
10-bit. CRF 17. Slow preset.
selective-sao=2:no-strong-intra-smoothing:rskip=2:rskip-edge-threshold=3:aq-mode=3:aq-strength=1.2:deblock=-3:-3

[Boulder]

Borders cropped off before encoding? Mod-8/16 vertical resolution?

[brad86]

Originally Posted by Boulder

Borders cropped off before encoding? Mod-8/16 vertical resolution?

No cropping. I despise doing such a thing. It is as it is on my disc.