running pixels

[ammer]

One thing about the coding, there seems to be a lot of pixel pushing in XviD. It seems like the coding is keeping many of the older bits and running it around, probably not so much as divx5.01 but its there. A lot of small details seem to move with the big objects. If it's possible or maybe feasible for bit rate wise encoding to move only noncontrasting background bits like the light on dark detailed background (in wide plain areas) or vice versa. Or that with unvisibly apparent(unnoticable) parts of the moving video...Maybe something that could be looked at. Also, its something that seems to happpen further from the moving edges then divx3.11 a lot of the time. Well, thats just something that seems to show up in the encoding.

[Teegedeck]

Originally posted by ammer
there seems to be a lot of pixel pushing in XviD.

pixel-pushing? :)

It seems like the coding is keeping many of the older bits and running it around

If a block doesn't change between two frames, the data from the foregoing frame is used, one of the essential bitrate-savers, what's wrong with that?

A lot of small details seem to move with the big objects.

I can only imagine that you use MPEG-quantizer and refer to the noise added by it. That noise is meant to trick the human eye into believing to see additional detail where there is none. If you do use MPEG-quantizer and feel troubled by this, switch over to H.263-quantizer.

If it's possible or maybe feasible for bit rate wise encoding to move only noncontrasting background bits like the light on dark detailed background (in wide plain areas) or vice versa. Or that with unvisibly apparent(unnoticable) parts of the moving video...

I don't quite comprehend your suggestion, sorry - perhap -h does. Your terminology really lacks some clarity, that makes it difficult. For example when you say 'bits' I immediately think of data-bits, but I guess you just mean 'parts of the picture', right? And you would also help us much if you gave details about your basic encoding parameters like MPEG- or H.263-quant, lumi-masking or not, one-pass or two-pass, which compression-settings,if you use two-pass, what bitrates...

Greetings

[-h]

Yeah I've noticed this - it's just how PMVFAST (which I assume you're using?) works. Even though the background "should" stay where it is, PMVFAST decides that it'll take fewer bits to store the motion if it gives said background the same vectors as the big moving object next to it.. and it's right. This could be prevented by increasing the bias towards "non-moving blocks" in motion estimation, however this would results in larger frames, and thus more blocks.

gruel is currently re-writing motion estimation, and this may either alleviate the problem or we could add a switch to favour zero-motion over movement-for-very-little-gain.

-h

[ammer]

MPEG,lumi-masking, two pass, 3hrs into 1400mb. I'm just saying the dots and stuff on the background are moving with the other things. Like in the twirling stars in paramount.

[Ivion]

I'm having the exact same problem. I encoded a 23 min episode of anime (Neon Genesis Evangelion) with:
Motion Search Precision 6 - Quantization Type H.263.
Using Hinted ME and Alt CC with these settings: High/200/75/50. (Curve Agression/High Distance/Low Distance/Strenght) and automatic bias bonus.
If people wish I could post a clip? Does someone has space or is interested in receiving this clip, then please contact me @: chesskid@GameBox.net, we'll then discus HOW we are going to transfer it :).
I hope someone finds a solution (and if not, the reason WHY it is happening :)).

[-h]

I hope someone finds a solution (and if not, the reason WHY it is happening :)).

It's happening because that's how PMVFAST (and probably to some degree EPZS) work in their current incarnations. It could probably be fixed to some degree by increasing the zero-MV bias and/or compensating against original (instead of reconstructed) frames. You'd see higher quantizers, but perceived quality is of course the most important metric.

I'd like to try it, but I only have so much time. Maybe on Sunday..

-h

[Ivion]

Thanks for the explination (sorry for my bad english :)), now I at least know WHY, and that is 'nice', because if you do not WHY it is happening, you'll feel disturbed and angry. :D
But also thanks for looking into that problem -h. Hope you can (or someone else on the XviD developing team) solve it. :)
Keep up the good work guy's, I just luv XviD. :p :D