[XviD-devel] VHQ

Radek Czyz radoslaw at syskin.cjb.net
Wed Feb 12 23:17:24 CET 2003


Hi,

> I didn't get that. Qpel refine is done how exactly? SAD _and_ BITS ?
 
OK, I'll explain this in more details. This is actually still a result
of some experiments and in the end might not be true.

Imagine that after sad-based ME we're doing our first check in BITS
domain. We discover that cbp == 0, which means that all blocks will
not be coded (and at this moment I mean 4 luma blocks). When this
happens, we can still do square/refinement steps and minimize bits
needed for motion vectors.
What I discovered: when we do that PSNR drops. This is because when
we're minimizing MV bits, we move away from 'best match' in the
understanding of SAD. We can save some bits, but SAD of the match - 
which means SAD of the MB in new picture [no dct to correct] - will
get worse. 

This is not big deal for quantizer 2, and this doesn't happen often at
quantizer 2 anyway. But for q6 that makes a _big_ difference.

Now, back to refinement.
If we are supposed to stop after we discover that cbp of sad-found
vector is 0, we should check sad-refined vector for that. Also, if
we're supposed to stop, we have to make sure that this vector is
actually refined.
The best way to do all this is to sad-refine the vector, then check.
A speedup can be obtained if we estimate, using SAD, if the match
actually has any chances of being cbp==0. 

The outcome is - if refine16_bits is active:
 - do sad-based fullpexel search
 - if SAD is low enough, refine it
 - check if cbp == 0. if yes, stop (see? it's refined after all)
 - if it's not, just do all the search and refinement using _BITS
   functions

And that's the explanation. This is all subject of further tests and
corrections, and I'm open on ideas as well.

Radek

PS you're right gruel, I changed the names to _BITS



More information about the XviD-devel mailing list