[XviD-devel] Mode decision

Christoph Lampert chl at math.uni-bonn.de
Wed Mar 26 12:48:01 CET 2003


On 26 Mar 2003, skal wrote:
> 	Now that I think of it, an complete opposite idea would
> 	be: always perform the 4mv search no matter what. 

That's what I meant earlier: Having the _choice_ to use inter4v 
is never bad. You just have to choose right. Not performing 4MV search 
will of course give speedup, but I believe first we have to understand
when 4MV is beneficial, then we can exclude the other cases already before
search (maybe). 

>       And if
> 	the 4 motion vectors deduced are not that different, then
> 	qualify the block as INTER (and maybe launch a 16x16
> 	refinement, even). 

Problem is, "vectors are different" is not a good criterion either (okay,
"all vectors are equal" is a strong argument again INTER4V, but 1 vector
being 1 pixel different could already save us bits. Especially, since
there should be less vector overhead, if 4MV vectors are close to 1MV. 

> If I'm not mistaking, you may only pay
> 	the overhead of "4*SAD8x8 - SAD16x16", if the dive-toward-
> 	optimal is of sensibly equal length. Don't you think?

Sorry, I didn't get that point. What kind of overhead do you mean? 

After rethinking 4MV I got the idea that maybe one criterion isn't good
for 4MV at all. Maybe there are different possibilities why 4MV can be
good. 

a) 4MVs close to 1MV, thus few overhead bits, but maybe more bits saves
(e.g. zoom: 4MV acts as an "extension" of block search to simulate
nonlinear motion of a larger object) 

b) some of 4MV very different from 1MV, many vector bits, but still the
bits saved could be worth it (e.g. object boundaries, 4MV acts as a finer 
grid for better segmentation).

Maybe we should rather model two decisions step/parameters for those two
cases than trying to model both with one parameter. 

Of course there are also other opposite cases, where even though it's an
a) or b) situation, 4MV is not beneficial. 

gruel 




More information about the XviD-devel mailing list