Placebo vs Very Slow & merange

[HD MOVIE SOURCE]

Hi,

I tend to encode a lot of shorter content on Placebo, but I was just looking at the differences between that and Very Slow, and one thing that I saw (as a major difference) is the merange values.

Placebo uses 92 for merange and Very Slow and everything else uses 57.

It basically says in the docs that anything above 57 really may not be worth the cost.

So, is merange=92 beneficial, and is it worth it? I know there are a few more things that are affected by Placebo, but I'm really just wondering about this. Is 57 always the best no matter the content? Is it this number content-based?

Thanks.

[benwaggoner]

Hi,

I tend to encode a lot of shorter content on Placebo, but I was just looking at the differences between that and Very Slow, and one thing that I saw (as a major difference) is the merange values.

Placebo uses 92 for merange and Very Slow and everything else uses 57.

It basically says in the docs that anything above 57 really may not be worth the cost.

So, is merange=92 beneficial, and is it worth it? I know there are a few more things that are affected by Placebo, but I'm really just wondering about this. Is 57 always the best no matter the content? Is it this number content-based?
Higher numbers aren't harmful to quality, just for speed. In general a higher range will find better matches. 57 is totally fine as a default; placebo is aptly named.

[HD MOVIE SOURCE]

Higher numbers aren't harmful to quality, just for speed. In general a higher range will find better matches. 57 is totally fine as a default; placebo is aptly named.

Thanks Ben.

[HD MOVIE SOURCE]

Higher numbers aren't harmful to quality, just for speed. In general a higher range will find better matches. 57 is totally fine as a default; placebo is aptly named.

Let's say this, if the ctu is 32, is it beneficial to use a merange larger than the ctu? I'm probably misunderstanding what merange is. The real question is, is it ever worthwhile searching beyond the current size of your ctu?

Could you set your ctu to 32 and set merange to 64? If so, does the search only go right to the next ctu? Could it search to the next line of ctu's underneath or only in one direction? I'm asking this because I believe ctu's are built from top to bottom, and left to right.

[benwaggoner]

Let's say this, if the ctu is 32, is it beneficial to use a merange larger than the ctu? I'm probably misunderstanding what merange is. The real question is, is it ever worthwhile searching beyond the current size of your ctu?
There's no real connection between CTU size and motion vector distance. You can mix and match safely.

[HD MOVIE SOURCE]

There's no real connection between CTU size and motion vector distance. You can mix and match safely.

Good to know, thank you Ben.

[microchip8]

There's no real connection between CTU size and motion vector distance. You can mix and match safely.

Actually, maximum merange is calculated as "CTU size - 4(luma) - 2(chroma) (-1 if me=hex is used)"

So the default of 57 comes from the fact that default CTU size in x265 is 64 and default ME is hex. 64 - 4 - 2 - 1 = 57

If using a CTU of 32, the max would be: 32 - 4 - 2 = 26 (or 25 if me=hex is used)

[HD MOVIE SOURCE]

Actually, maximum merange is calculated as "CTU size - 4(luma) - 2(chroma) (-1 if me=hex is used)"

So the default of 57 comes from the fact that default CTU size in x265 is 64 and default ME is hex. 64 - 4 - 2 - 1 = 57

If using a CTU of 32, the max would be: 32 - 4 - 2 = 26 (or 25 if me=hex is used)

So what happens if you use 58 with CTU 64 and 27 with CTU 32? Does it require more processing time because the encoder is moving into another CTU row? Is it always best to be at the exact size of the CTU with merange, obviously, negating the luma and chroma too?

Are there benefits to going outside the CTU range?

[microchip8]

So what happens if you use 58 with CTU 64 and 27 with CTU 32? Does it require more processing time because the encoder is moving into another CTU row? Is it always best to be at the exact size of the CTU with merange, obviously, negating the luma and chroma too?

Are there benefits to going outside the CTU range?

It gets internally clipped by x265

[Boulder]

It's not clipped at all, the encoder does use a value you set there. A different question is if it's meaningful to use a bigger value than the CTU size :devil:

x265.h does have a conflicting comment regarding the default, which is 57 as calculated in the earlier post. It's pointed out that the range should be lowered is CTU is lower.

/* The maximum distance from the motion prediction that the full pel motion
* search is allowed to progress before terminating. This value can have an
* effect on frame parallelism, as referenced frames must be at least this
* many rows of reconstructed pixels ahead of the referencee at all times.
* (When considering reference lag, the motion prediction must be ignored
* because it cannot be known ahead of time). Default is 60, which is the
* default max CU size (64) minus the luma HPEL half-filter length (4). If a
* smaller CU size is used, the search range should be similarly reduced */

[microchip8]

I haven't looked at the code, but I do think it gets clipped. That's why you see no speed difference between 57 or 58 and say 128

[Boulder]

I ended up at that part of code by searcing for "searchRange" in the repository, and I cannot see anything clipping the input. I have myself noticed a difference between 26 and 58 with CTU 32, which is why I initially assumed that any legal value is actually used.

[benwaggoner]

I haven't looked at the code, but I do think it gets clipped. That's why you see no speed difference between 57 or 58 and say 128
Motion vectors can be longer than CTU size! Otherwise the maximum vector length would be 64.

The --merange value means different things in different modes, and doesn't match with the actual search range at full resolutions.

[microchip8]

Motion vectors can be longer than CTU size! Otherwise the maximum vector length would be 64.

The --merange value means different things in different modes, and doesn't match with the actual search range at full resolutions.

I know that! The reason I thought it gets clipped is because years ago, I vaguely remember Dark Shikari mentioning that "something" gets clipped to a max value if the provided one is bigger than it. I don't recall exactly, but I "think" he was talking about merange in x264 and x265 is baed on its codebase.

[rwill]

I know that! The reason I thought it gets clipped is because years ago, I vaguely remember Dark Shikari mentioning that "something" gets clipped to a max value if the provided one is bigger than it. I don't recall exactly, but I "think" he was talking about merange in x264 and x265 is baed on its codebase.

Sometimes "vertical down Y" is clipped to not slow down frame based threading.

[benwaggoner]

I know that! The reason I thought it gets clipped is because years ago, I vaguely remember Dark Shikari mentioning that "something" gets clipped to a max value if the provided one is bigger than it. I don't recall exactly, but I "think" he was talking about merange in x264 and x265 is baed on its codebase.
Every codec I can recall of has a maximum motion vector length constraint that may be what you're thinking of. They're much bigger than 64x64 for everything modern. I think Cinepak was limited to 31x31.