Quick, dirty hack requested ;-)

[PowerMacG4]

XviD-14052003-1 - Koepi

Settings - Motion Seach 6 (implies 4mv), VHQ1, Chroma ME, Trellis, Qpel

From watching ffdshows motion vector output, it looks like XviD uses a very good motion estimation algorithm. My only problem, is that when there is 0 motion, or at least 0 visible motion, the motion vectors seem to 'jump' around very slightly. I know the TMPGEnc has an option to disable motion search for still parts of the picture, but has a side effect where low motion parts of the picture become spoiled.

I would like to modify the source myself to round certain small MV values from whatever amount to 0, just to see how it would look, but I do not have the expertise for playing the XviD source. Could some one hack this into a special build for testing? sysKin?

Also, I have noticed when there is, for example a green square moving along the top of the screen (black background), even though there is no motion in the black area, there is a huge column of motion vectors where there is obviously no motion. What purpose does this serve? (I already had the long MV's due to fades explained to me)

[Koepi]

Noise does move.

It keeps the picture "detailed".

[sysKin]

Originally posted by PowerMacG4
[B]
Settings - Motion Seach 6 (implies 4mv), VHQ1, Chroma ME, Trellis, Qpel

From watching ffdshows motion vector output, it looks like XviD uses a very good motion estimation algorithm. My only problem, is that when there is 0 motion, or at least 0 visible motion, the motion vectors seem to 'jump' around very slightly. I know the TMPGEnc has an option to disable motion search for still parts of the picture, but has a side effect where low motion parts of the picture become spoiled.
I'm aware of this. In theory, it would be best to make the still macroblocks SKIPped - they would be completely static and would only take one bit to code. The code is there, but (especially for high bitrates) seems never - or almost never - to actually skip.
Whenever I tried to "fix" it, the result was horrible: even 2dB quality loss and completely no gain (maybe 1% filesize at best).
It's very difficult for me to say that motion estimation is better just because vectors don't "jump" when psnr drops so very much...

I would like to modify the source myself to round certain small MV values from whatever amount to 0, just to see how it would look, but I do not have the expertise for playing the XviD source. Could some one hack this into a special build for testing? sysKin?
That would be even worse: much less PSNR, much bigger filesize. You can't just take a vector and force it to zero.
Also, I have noticed when there is, for example a green square moving along the top of the screen (black background), even though there is no motion in the black area, there is a huge column of motion vectors where there is obviously no motion. What purpose does this serve?Well, a side-effect of what I said above. If those macroblocks are not SKIPped, encoder codes vectors to be equal to prediction, because that takes almost no bits (4 bits total if there is no coded dct blocks). Changing such vector to 0 wouldn't change the picture (you said it was black) but would probably take at least 20 bits (because it still wouldn't be skipped).
All in all, I can perfectly imagine when SKIPped blocks are useful. Even 4 bits is more than 1 bit.
And when it comes to xvid's motion estimation, this is the only area I can clearly say: I have no idea how to make it work.

Radek

[PowerMacG4]

Thanks for your answer.

I am not perfect with my understanding of how MPEG compression works, but you grasped the idea of what I was saying. Even though the PSNR is lower because the image is fundamentally different than the source, does it look better to the eye because the picture does not jump around? Is there a better way to do this instead of on the encoding side?

I talked about an Avisynth plugin that did something similar to this earlier. The idea is sort of like Dup plugin, but to make only certain parts of the picture still, not the entire picture. I would imagine this would be primarily beneficial to anime filtering, but maybe I am crazy.

[mf]

I have thought about almost the same. A "true MV" mode instead of "best compression MV". XviD catches the motion that will generate the best compression, but rarely catches the real motion as it was recorded. This sometimes creates some rather funky effects, like that what you describe.