[x264-devel] Re: x264_me_search_ref

[Loren Merritt]

On Mon, 7 Aug 2006, Johannes Ball wrote:

> Am Montag, 7. August 2006 18:27 schrieb Loren Merritt:
>> On Mon, 7 Aug 2006, Johannes Ball wrote:
>>> line 179) Why are p_cost_mv{x,y} adjusted for a clipped mvp? As far as I
>>> know, clipping of the predictor is not done in the decoder, so unless
>>> there is some special magic involved, shouldn't this yield the wrong cost
>>> measure? The comment doesn't really make sense to me, because it's not
>>> mvp that's clamped here, only the cost measure is moved.
>>
>> If I didn't do that, then the iterative searches could walk all the way
>> off the frame and into uninitialized memory. That could also be prevented
>> by checking against mv_min_spel etc at each iteration, but this way is
>> faster.
>
> Sorry, I don't see that. The purpose of p_cost_mv* is to emphasize mvs near
> the predictor, because these mvs need less bits to encode (because we encode
> not the mv itself, but the difference to the predictor). This should be
> independent of how you do the search.

Pixels outside the frame are defined to be equal to the nearest pixel in 
the frame. x264 initializes a padding region of 32 pixels in each 
direction. If the search ends up in that border, then the SAD residual 
won't change any more, so the only factor that can cause the search to 
continue moving beyond the edge of the frame is if mvp points out there 
and thus creates a cost gradient in that direction.

> By moving p_cost_mv*, you keep the region of emphasized mvs inside the frame,
> true. But as far as I can see, that's not a hard limitation. The search could
> still wander off into uninitialized memory, given the right video input. I
> think it will run okay most of the time, but my main point is that you're
> giving up the right distance measure. x264_me_search_ref will pass back an
> incorrect m->cost for the m->mv it returns, and all this will lead to
> suboptimal decisions.

mv_min_spel is in the padding region. So if the mv does end up near the 
clipped mvp, then we can set the mv equal to the non-clipped mvp and it 
will be just as good an mv, and the clipped cost will be correct. The only 
inaccuracy is if the final mv is far enough from mvp to be inside the 
frame (so we can't just change it), but close enough that the mv_cost 
gradient is non-negligible.

> It appears to me that your algorithm is fast, but not reliable in all
> circumstances. Checking against mv_min_... is probably the better way(tm),
> even if it takes a speed penalty. Have you checked how much it would slow
> down vs. how prediction improves?

Yes I tried it, and the difference in quality is too small to measure.

>>> lines 209 and 515) I don't understand either why the mv cost is
>>> subtracted in line 209 nor why it is added in line 515. Could this be
>>> related? In line 209, it obviously wasn't clear to the author himself. In
>>> line 515, m->cost should already include mv_cost (because of the way
>>> COST_MV_* works), so I don't see a reason why it is added there again.
>>>
>>> Thinking twice about it, this could be meant as way to account for SKIP
>>> mode, but why is it only done for h->mb.i_subpel_refine < 3?
>>
>> It's to compensate for the fact that mvp was rounded to fullpel, whereas
>> the most likely result is to use it exactly. With subpel_refine >= 3 we
>> don't round the predictors, so no compensation is needed.
>> mv_cost is added in 515 if and only if it was subtracted in 209.
>> Compensation for rounding is no longer needed here, because the next thing
>> the score is used for is subpel search.
>
> Why treat mvp specially? The extra predictors are also rounded, and the other
> motion vectors you're comparing them to are full-pel, as well.

Because the difference in cost between mv-mvp=(N,N) and mv-mvp=(N+.5,N+.5) 
is up to 8 bits if N=0, but is small for other N.
...But that's just my rationalization for it. The real reason it's done 
this way is: Some time ago there was a bug whereby mv_cost was not added 
to the mvp score. I found that fixing that bug reduced quality. So I left 
it.

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html