More q's of "does xvid really calc motion after all"

[OUTPinged_]

MooPolice never sleeps! \o

Hello everyone. There were some questions risen again and maybe somebody here can help me.

It was initiated by some irc chatting, i will basically provide citates here:


<FalconX> xvid still calculates motion information it just only operates on a block by block basis, not the whole frame
<FalconX> so it stores movement info for all the blocks instead of just for the whole frame in those pans, but that's not a huge difference in size
<FalconX> its just a hyptohesis, educated guess.
<OUTPinged_> i want to citate that part where you described how xvid does motion calc and about pans that compress well
<FalconX> yeah, just as long as it is known i'm not stating it as fact but how i would hope it works :)


And thats it. May somebody confirm if that kind of calculation is indeed taking place and if it affects bitrate curve profiling?

I remember Foxer mentioned a while ago vxid doesnt calc motion from keyblock changes as divx3/(4/5?) did. So does xvid use other, "non-nandub" ways to get the work done?

[Koepi]

Ever thought about terms like

Motion vector
Motion estimation

...

All part of XviD.

But well, that's what I do expect from you.

[-h]

<FalconX> xvid still calculates motion information it just only operates on a block by block basis, not the whole frame

True - we internally perform motion estimation on 16x16 and 8x8 blocks, not entire images (as in global motion compensation).

And thats it. May somebody confirm if that kind of calculation is indeed taking place and if it affects bitrate curve profiling?

I think there's a misunderstanding - motion estimation is inside core, and to do with actual image compression. Motion calculations involving bitrate curve profiling are specific to two-pass encoding, which exists entirely independent of core's motion estimation stage.

The 2-pass system doesn't take into account motion directly, it just scales big frames down to smaller ones. Conveniently, big frames are almost always high-motion frames, so the end result is similar.

-h

[OUTPinged_]

The 2-pass system doesn't take into account motion directly, it just scales big frames down to smaller ones.


That answered that, thanks -h.

Still, one more question:


Conveniently, big frames are almost always high-motion frames, so the end result is similar.


Ok, i will collect some more data and will make a discussion on that topic. -h, i still believe the hi-mo percentage of large frame values for "typical" encode may be low enough for motion calc in br.curve profiling to become usefull.

[-h]

Ok, i will collect some more data and will make a discussion on that topic. -h, i still believe the hi-mo percentage of large frame values for "typical" encode may be low enough for motion calc in br.curve profiling to become usefull.

Hm not really, decimation of high-motion scenes should be achieved through motion masking, not higher quantizers, same as dark scenes should be handled by lumi masking.

It'll come eventually..

-h

[OUTPinged_]

yes, that should be a more wise approach.

btw -h, i heard rumors the lumi masking will be toned down soon, is that true?