[XviD-devel] 3 warp point GME

[Christoph Lampert]

On Mon, 30 Jun 2003, Radek Czyz wrote:
> > So in principle it should be:
> > 1) one rough step of MEAnalysis (but not 32x32 block, 16x16 is the max)
> 
> It is 16x16 (more or less). We'll have to check how bad it is.
> Also, we can try to extend this search by halfpel refinement during
> pframe coding (not before, we don't have halfpel pictures before),
> because the vectors are stored. 

Halfpel during Analysis is absolutely necessary to get reliable start
vectors... 

> This step can't be done in second pass - at least not this way... I
> wonder if it would be possible/ok/useful to store GMC in a file of
> some sort.
> 
> > 2) global ME based on block vectors
> > 3) global ME refinement, based on block vectors or last frame's GME
> > 4) decision whether to _use_ global motion at all
> 
> Do you think point 4 could be done between 2 and 3?

Yes, I know this sounds tempting, but I believe "no". From what I noticed,
step 2) is often unnecessary, because previous frame's GME is already
better than the approximation from unreliable block vectors. But some
time to time when global motion changes, they are needed as a new start
point, because it would be too slow to "walk" the way from previous frames
GME to new best. 
Changing warp parameter in only 1 iteration step effects all GMC
blocks at the same time. SAD may be very bad before the "optimal" warp
parameters are found. On the other hand, parameters are not equally
important. translation (parameter set 0) has more influence then the other
two. I don't think you can decide whether to use GMC before the actual
parameters are there. 

I might be worth to find some criterion to sometimes skip 3), but the real
decision 4) has to be done after 3). I'll have to do more tests, so see if 
something like "no translation, but some small shear value" is really
worth the bits. 
 
> > 5) block based ME with knowledge of global motion
> 
> I tried BITS for 2-point GMC, using the current order - it was very
> bad, possibly because of large number of vectors, all depending on
> prediction (large number because of inter4v being used often).
> 
> 
> >> Indeed, it _might_ finally make SKIP mode useful. Currently, it's very
> >> hardly used, even at low bitrates.
> 
> > What? Really? But SKIP is the part that's supposed to save the bits.
> > And I guess in most cases, the background motion _is_ (0,0).
> 
> I fully admit - I was unable to make SKIP mode useful, even thought I
> tried very very hard.
> 
> That's correct, motion might be zero. However, it doesn't mean that
> blocks are not coded. At quants 2-4, almost all blocks are coded in
> pframes. Even one coefficient in one block (of 6) will prevent SKIP.

Hm, we might have to come with a clever idea of coefficient reduction, 
like trellis does. But if the 1 coefficient is DC, it might be better to
code the block, because the difference coded/not_coded isn't that big,
and throwing away DC might cause blinking blocks again. 
In fact, I wasn't thinking about quant 2-4 when I meant that many blocks
should be SKIPed. 

gruel