[XviD-devel] SAD of last visited neighbour positions

[Christoph Lampert]

On Mon, 21 Oct 2002, Michael Militzer wrote:
> Btw: Christoph, what's the main problem your currently facing? From my
> understanding it should be sufficient to modify the DiamondSearch functions
> to store the SADs of already visited positions, right? Or is the
> modification much more complex? (please excuse my ignorance in this area...)

It's not really "problems", it rather "annoyances". 
DiamondSearch is a beautifully simple routine using beautifully simple
macros/subroutines. They check a position and set optimal vector/sad
corresponding, but they don't care which "direction" they check. 
Using binary flags it's ensured that the previous position (before this
timestep) isn't rechecked. 

If you want to know and save which position had what SAD, you either have
to recheck that one (at least 25% slowdown) or keep track of all
directions, because you have to use 3 SAD-checks for obtaining new
position checks and a temporary variable for the unchecked because already
known value. So far so bad, that's for a simple DiamondSeach().

Now the problem is SysKin implemented clever modifications of
DiamondSearch, including diagonal checks. Those depend on what the last
direction was. So you have to keep track of those positions, too. But not
all neighbours of them are known and in the next step, these positions
will not be rechecked, so we have to keep backup copies of the diagonals,
too. With current structure it's simply plain ugly... and adding the stuff
to current DiamondSearch() would also slow the whole search down. 

I guess I should rather create another plain DiamondSearch() routine, that
doesn't use bit-flags to label which directed have to be checked and which
don't. It would be slower than current, but in combination with faster
Qpel it might come out superior. 

Christoph