[XviD-devel] 3 warp point GME

[Radek Czyz]

Lo,

> I guess we had this discussion

Yes, I'm not complaining about current state of course :)

> 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. 
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?

> 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.

As for early SKIP decision during ME, I even tried to make it pure R-D
- number of bits is known (0, coded/not_coded bit is not counted
anywhere), distortion is known (sum of squared dct components)... and
even at high lambda (2.0? 3.0?), it just skipped everything.....

I'm out of ideas.

Radek