[XviD-devel] GME and Block ME

[Christoph Lampert]

On Tue, 22 Apr 2003, Michael Militzer wrote:
> BTW: gruel, why do you need a precise ME, then GME, followed again by precise 
> ME? Why is precise ME + GME no sufficient? Wouldn't it be possible to somwhow 
> merge the steps or at least to somehow speed-up the final block search?

Everything is possible, and just speeding up the second step is surely not
a big problem, except for that the refinement takes at least 50% of ME 
time, and I can't get rid of this. :-(
But I can't get rid of the whole step, because BlockME must know the 
global motion vector, because that's the SKIP vector, and we shouldn't 
optmize for as many (0,0)s as possible, if (0,0) isn't the SKIP value. 

> Would it be sufficient to first do a precise ME (but without
> refinement), then GME, then do an additional search using the GME
> result as predictor and finally perform the refinement step?
 
Of course I tried that: A first step without refinement is too coarse to
yield good start values for GME. Not that this predicition is good anyway,
but without halfpel we can forget the whole thing, with halfpel it's at
least a little bit useful.  At the moment I check two possible start
values: previous frame's parameters and prediction from block search.
Gradient decent starts at the better of those (which is previous frame in
95% of cases). It is crucial to not have many step in gradient search,
because that's the slowest (and least optmized) part. 

But I'll simply commit the code (maybe I'll wait till dev-api-4 is in
HEAD?) and then we can check and discuss all ideas.

gruel