[XviD-devel] Global Motion Compensation

Michael Niedermayer xvid-devel@xvid.org
Thu, 24 Oct 2002 13:14:15 +0200


Hi

On Thursday 24 October 2002 12:54, Christoph Lampert wrote:
[...]
> > > two questions for the experts, since I started to look at GMC again but
> > > have no reference material (there's no DivX5pro for Linux and micro$oft
> > > reference software doesn't compile).
> >
> > momusys does compile on linux
>
> Where is the GMC code in that? I just found routines to load warping
> information from files.
vm_common/src/globalMC.c

[...]
> > > 3) How much work would it be to add GMC decoding to XviD decoder API-3?
> > >    I guess it's the only feature missing to be a full Advanced Simple
> > >    profile decoder and for testing I would love to be able to use
> > >    xvid_stat.
> >
> > hmm advanced simple allso requires the error resilience stuff IIRC (i
> > might be wrong though)
> >
> > btw, iam not sure if GMC encoding with >1 warp point is such a great
> > idea, the speed loss is huge for decoding and that would make the files
> > unplayable on older CPUs
>
> Yeah, maybe. But on the other hand, CPUs get faster every day and I don't
> believe in simply ignoring a feature because it's too slow... If you
> encode for yourself and know that your machine is fast enough for
> decoding, why not use everything possible? Smolic implemented a real-time
> GMC _encoder_. 
encoding is not more difficult than decoding IMHO, as the motion estimation is 
allready done, we just need to analyse it to find good warp points ...

> Maybe more tweaks are possible for fast decoding, too.
> (pre calculated tables or something...)
hmm, i doubt it a bit

>
> The only argument would be that you don't gain anything from GMC, which
> may be true for most videos, but sometimes it seems to help during
> zoom/pan, so I'll at least have a look.
hmm, its allways a question of complexity vs. compression gain, never just 
compression alone, or why dont we all do full ME search? 

[...]

Michael