[x264-devel] Re: x264_me_search_ref

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

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

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

> I did some minor cleanup of the code (see attached file). It's not tested and
> only meant to clarify what I'm trying to say. If you would, please
> double-check and give comments.

--Loren Merritt

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