Pink Banding in movie - Xvid

[lar1r]

After a 2 pass encoding, my movies generate pink where ever there is motion on the right side of the screen.

Is this a regular problem, or am I setting up my 2pass -2nd pass settings incorrectly?
(Note: I simply include the .stats file I created in 1st pass in both boxes in the 2nd pass dialog.)



Thx

[Teegedeck]

Originally posted by lar1r
After a 2 pass encoding, my movies generate pink where ever there is motion on the right side of the screen.

Is this a regular problem, or am I setting up my 2pass -2nd pass settings incorrectly?
(Note: I simply include the .stats file I created in 1st pass in both boxes in the 2nd pass dialog.)
Thx

I'm afraid, you definitely made a mistake. Before the 2nd pass you have to open the 1st-pass' stats in GKnot and calculate it for the size you want for your final encoding. Please refer to Doom9's GKnot-guide on how to do that. Just ignore that in the description only DivX 3.11 is mentioned - just do it the same way EXCEPT that you uncheck the boxes for 'luma correction' and 'motion correction'

After this, include the resulting stats in the 2nd pass line in the dialogue.

[gldblade]

Shouldn't it be valid anyway if you use the stat file in both fields? If I'm correct, it would be equivalent to saying encode to the maximum filesize possible. Obviously not everyone would want this, but it should still be valid.

I think...

[lar1r]

yeah, i though videogk meant i had to use gordianknot but I didn't know how to go about it.

Thx everyone.

[Teegedeck]

Originally posted by gldblade
Shouldn't it be valid anyway if you use the stat file in both fields? If I'm correct, it would be equivalent to saying encode to the maximum filesize possible.

Wouldn't make much sense, would it? :)

Anyone who really wants the best quality, can encode with constant quantizer=2 (this is what the codec does in the 1st pass, AFAIK). Or simply deactivate the 'discard first pass bitstream'-option, while doing the first pass. Can be senseful if the source compresses so well that maybe you want to skip the second pass and keep the result of the first pass.

Obviously not everyone would want this, but it should still be valid.


I think...

One should think so. Perhaps we should ask Isibaar about this phenomenon? Then again, it hardly is a bug, it's only interesting. Could be an effect of the formula that steers the codec in second pass? I suspect that having identical factors in the equation could produce nonsense, mathematically.

[Teegedeck]

I get the feeling, I'll have to write a short XviD-how-to...

[-h]

Using the same .stats file for both passes will generate an output of quant=2 for every frame. The current system works by comparing the original .stats bitrate field to the 2nd pass one, and deciding on a new quantiser to effect the change. If they're equal, no change from q=2 will occur.

As for the pink blocks - I assume lar1r is using an old build of the codec? If the pink blocks still appear (this was the get_range() bug) with the latest build, a sample from the vob where it occurs would be greatly appreciated I'm sure.

-h

[Teegedeck]

@-h: I've got a draft for a short XviD-how-to, but can't even have a look at the codec's config dialogues for the next days. Would you care to have a look? You can PM me.

[lar1r]

The pink blocks do NOT appear if I use the gk method as illustrated above. Everything works fine.

They DO appear if I use the same stats file name in both boxes on the 2nd pass page. (only when there is motion from the very right side that moves to the left)

And yes, I am using the latest compiled version.

[-h]

Does this happen on all movies you've tried, or just a specific few? I'm wondering if I'll have anything that can repeat this behaviour.

-h

[lar1r]

yes it does happen to me if I mistakingly put the same stats file in both boxes under 2 pass. (The pink always comes from the right edge of the graphic when there is motion from this edge moving in towards the center of the picture)