[XviD-devel] Global Motion Compensation

[Michael Militzer]

Hi,

----- Original Message -----
From: "Christoph Lampert" <chl@math.uni-bonn.de>
To: <xvid-devel@xvid.org>
Sent: Monday, October 28, 2002 9:45 AM
Subject: Re: [XviD-devel] Global Motion Compensation


> On Fri, 25 Oct 2002, Christoph Lampert wrote:
> >
> > There is no support for GMC syntax in XviD encoder (or ffmpeg encoder),
> > yet. It would only be possible to use reference encoder as encoder and
> > replace their GMC routine by yours, but that's uncomfortable, of course,
> > because of completely other data structures ,etc...
>
> hi,
>
> I was just adding S(GMC)-VOP support to XviD encoder. At the moment
> stationary only, next will be translational. After that the
> formulas will get ugly...

cool

> There is a new VLC table needed for the GMC coefficients and I don't
> know how we generate them. Can somebody explain to me? For those with a
> standard, it's Table B-33, page 357.

hm, basically it's just a (insanely huge) lookup table including the codes
for all possible coefficients (including VL and FL codes). But we wanted to
change the lookup table generation anyway using the code Skal already
provided (unfortunately c++ code iirc), so it might be a good idea to do it
now...

> S(GMC)-VOPs are almost identical to P-VOPs, but they have two differences:
>
> 1) There is support for GMC. Every INTER or INTER_Q macroblock needs an
>    extra 1 bit flag if motion compensation is done relative to local
>    motion (with vectors in bitstream) or relative to global motion
>    (no extra vectors then, but still DCT data). So if using
>    S(GMC) instead of P but without GMC there is a 1 bit overhead per
>    INTER-block.
>
> 2) In combination with B-frames, there is one advantages: If the
>    co-located block in backwards reference is NOT_CODED in a S(GMC)-VOP,
>    the corresponding B-VOP block _are_ coded, not automatically NOT_CODED
>    as with P-VOP as backwards reference. This might be very slightly less
>    efficient, too, but it surely make encoding B-frames easier.
>
> @Isibaar: I'll have to change some of the code you added for quarterpel,
> because GMC needs VOL type 2, too, so only using m_quarterpel won't
> work anymore.
> Those was in BitstreamWriteVOLHeader (or what it's called...). Do you
> remember any other changes in headers due to quarterpel?

No, just VOLHeader (all places which start with an if(quarterpel)...)

bye,
Michael