GMC reencoder

[eibwen]

the ability to somehow just reencode S-vop frames (i believe they are called, frames with GMC data) would rock.

it wouldn't be too easy to make tho i don't think, because the program would need to be able to read the source file directly instead of a decoded RGB or YUV input. But something that would do this would rock because few, if any, dvd players which support xvid/divx don't support at least xvid's GMC, so a tool to just reencode those frames instead of every frame would:
A. improve speed of reencoding
B. cause less reduction of quality due to reencoding

well theres my idea while i'm running a couple of encoding processes in 1pass for the fastest speed of reencode of videos i encoded not planning on watching on a dvd player.

i assume it would work, but i know nothing of the actual structure of the stream, or if you'd be able to insert the frame, and calculate any dependencies of the next/previous frames

perhaps this will inspire someone into putting some work into this, or discussion on it

[sysKin]

No this will not work. A reencoded frame - even with only GMC-ed macroblocks reencoded - will look different. By itself it's not a problem, but in compression, this frame becomes a reference frame for other frames which inherit all differences. Then, next frame inherits from those.

The result is a horrible artifact crawling all the way to next intra frame.

[eibwen]

yes, the preceeding frames require the gmc frames, but i would think there would be some way to make the new frames compatable with that...

the way i'm invisioning how gmc works is like it encodes an image larger than the viewable area, then for each frame contained on that it tells a x/y value that it crops out of that larger area. would that be an apt way to think of it, or does it work totally different to that? if it were that, the recoder could like crop out that extra data, putting the data for each frame and only that frame taht would be basically bitwise the same as the gmc decoded data for that area, therefore could be used flawlessly for the next frames?

again, i generally don't know what i'm talking about, so sorry if i'm pushing this and it has no chance of working

[foxyshadis]

GMC is just a second vector added to every block's motion vector. (In 1-point "DivX" GMC, it's a constant offset vector, 3-point in xvid isn't necessarily.) I don't see a major reason why the vectors can't be merged by a bitstream tool to transform it into a standard P-vop, if everything was properly updated, but I don't know the mpeg-4 internals intimately either. Since vectors are composed of integer half-pel offset pairs, it seems as if it wouldn't be subject to any roundoff errors, but maybe quantization is involved in a weird way.

[Manao]

GMC 1 point indeed amounts to a constant vector ( which makes it "almost" useless ), but GMC 3 points creates a per pixel motion vector field.

[sysKin]

the way i'm invisioning how gmc works is like it encodes an image larger than the viewable area, then for each frame contained on that it tells a x/y value that it crops out of that larger area. would that be an apt way to think of it, or does it work totally different to that?
I'm not 100% clear at what you're saying, but I'm almost sure you're wrong.
GMC is just a second vector added to every block's motion vector.
And this is definitely wrong :)

GMC works by zooming/rotating (2-warpoints) or a 3D perspective transformation (3 warpoints) of the reference frame. Then, the blocks which use GMC don't have any vector, but use this transformed picture directly. Other blocks are unaffected and reference from original.

There's no way to simulate these effects with any motion vectors.

[foxyshadis]

Oh, I thought it performed the rotate/skew on the field of vectors, not on the full pixel frame. Now I see why it's impossible!