Global Motion Compensation - theory and praxis

[HarryM]

Hi,

I have two question:

1. How much can be GMC theoretically effective (in ideal case, of course)? How much can lowering bitrate ideally?

2. GMC vs B-frames. I think, that using B-frames decrease effectivity of GMC generally. Both features, in any cases, makes (nearly) identical thing - identify regular (steady) movement for bitrate lowering.
I am right?

[sysKin]

It's a bit difficult to answer, because GMC is much more then has been discussed so far.
GMC makes a modified copy of reference picture. In P-frames which use GMC, for every macroblock, motion estimation can access this modified copy (without any additional vector) or normal reference moved by a given vector (just like without GMC).
The overhead is one bit for every macroblock.

Now, the point is that there are many ways create this new reference. What we see in DivX5 is a one-vector GMC - new reference is just the old reference moved by a vector. A halfpel-precision vector. This is exactly the same thing which can be done ithout GMC. It's not effective. In theory we can save some bits if GMC-motion is equal to 'real' motion, but one-bit-per-macroblock overhead compensates this saving...

Gruel is currently working on two-vector GMC. In such a case, GMC-reference is really created from the scrach, by zooming and/or rotating the reference frame. This is much more effective, because it creates a reference which couldn't be achived in other ways.
I don't know how effective it's going to be, yet. We'll see.

GMC is not like bframes, it just helps P-frame coding without affecting any b-frames (well ok, it affects tham a bit, different story. :P)

Radek

[trbarry]

Gruel is currently working on two-vector GMC. In such a case, GMC-reference is really created from the scrach, by zooming and/or rotating the reference frame.

Does MPEG4 GMC have any provision for a global change in brightness/intensity in this new mutated frame? It seems it would be easy to detect and might be useful.

- Tom

[MfA]

The originator of the GMC proposal didnt intend (http://www.google.nl/search?q=cache:86dTAThlRnYC:lists.m4if.org/pipermail/technotes/2002-March.txt+%22global+motion+compensation%22+sprite_brightness_change+site:lists.m4if.org&hl=en&ie=UTF-8) for brightness change to be used that way (scroll down to Yoshinori Suzuki's message). That is not a huge issue since the standard allows what it allows, intentions be damned.

The problem with brightness change is that there is no way to encode a 0 brightness change without using a new VOL header, the smallest brightness change which can be encoded without it multiplies luminance with 1.01. A new VOL header wouldnt be a big issue as long as we dont use an I-frame at the start of each VOL like we are doing at the moment. Unfortunately that is not standard compliant, and support for it might be removed (actually it is standard compliant but useless, a standard compliant decoder is supposed to not output any VOPs till the next I-frame).