[x264-devel] Re: x264_me_search_ref

[Johannes Ballé]

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.

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.

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?

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

> > lines 222ff) Why is it necessary to adjust the limits like that?
> > Shouldn't h->mb.mv_min_fpel etc. already contain the correct limits?
>
> mv_min_fpel contains the limits of where to start the search, not where to
> end it. For the same reason as your first question.

Hmm, I think it would be better to use them to limit the search.

-- 
Johannes Ballé
RWTH Aachen University
johannes.balle at rwth-aachen.de

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