Re[2]: [XviD-devel] New Motion Estimation (from sysKin) committed to branch

Christoph Lampert xvid-devel@xvid.org
Tue, 24 Sep 2002 17:17:30 +0200 (CEST)


On Tue, 24 Sep 2002, Michael Militzer wrote:
> I quickly tried to implement this idea yesterday into SysKin's ME, but
> because lot of pointers were used (SearchData etc.) I couldn't easily keep
> track which data gets modified at all and obviously the search8 step
> destroyed some information of my earlier search16 :-( Is it that much slower
> to really store all results within SearchData instead of using pointers to
> common variables? Maybe it's a good idea not to throw away any information
> at all (best MV before refinement etc.), lots of computing power has been
> invested to calculate those intermediate results and you never know, if it
> might not be useful in the future again...

SearchData was introduced because many routines need lots of pointers and
value (4 min/max values, many best vectors and best SADs so far) and it's 
a) ugly to always call routines with so many arguments and 
b) slow to push/pop 10 values if only a handful of calculations is done
within the routine. 

Also, SearchData is surely in cache whereas pointers to different
locations of variables might cause conflicts.  So there shouldn't be any
speed penalties from it. 

Maybe we should add a small header to every function that tell which are
the input values and which are the output results (what is modified/side
effects). 

> I don't know if this idea helps to speed up halfpel mode a lot, but because
> most MBs are not INTER4V but mostly INTER, one could save the halfpel8
> refinement for most MBs which might not be too bad... And when quarterpel
> refinment comes into play, the speed gain might be even more noticable.
> 
> 3) I'd like to have a small data structure where the SADs of the neighboured
> blocks (top, bottom, left, right) of the current best match are stored.
> Well, while I think about it, even better would be all 8 neighbours. This
> could allow faster qpel refinement...

Yes, I'll look into that...



gruel