XviD: color fluctuating around small moving areas

[unplugged]

After I have seen some motivation and interest around XviD improvement and feature/bug discussions, I have decided do some tests with the latest CVS release dated 22-04-2002 courteusly compiled/packed by Nic.
First of all I have discovered very good improvements on image quality especially in mid-high and high motion frames, second I like much more the *new* curve compression control instead of the older that mostly act by motion and is too localized... (2nd pass tab), infact I didn't like even the payback delay measure...
(Is it true that when I activate the alternate CC the old CC compression tab is ignored?)

I must be honest, the *unique* thing that at this time is bad (not only in relation of DivX5) is a strange color fluctuation around SMALL MOVING object/areas (borders of faces, clothes, actors).
This visible fluctuation (either by Croma or Luma... almost it seems this way) happens as if "compression schemes" change a lot from frame to frame, and thus with these flutuating artifacts, on borders.
This behavior is typical by XviD since time ago...
Talking about DivX5, very small motion frame/areas are encoded very constantly with no noticeable fluctuation/pixellation (at resonable/workable bitrates).



P.S.: please could someone can do a little more clear version of Curve Compression graph? :(
I have already red with some difficulties the long interesting thread regarding CC, but a wider graph with a good terminolgy/specification for X and Y axis and equation elements would be a positive clarification to me/us mortals. :o

P.S.2: I think to understand the CC graph but when I read forum explanations I return to don't understand it :p.

[-h]

Could you post a screenshot of the colour fluctuation you're talking about?

Also, does it always happen, regardless of input colorspace? Try converting a single sequence to YUY2 and RGB, then compress both with the same settings, and see if you notice the problem in both files.

-h

[Teegedeck]

Originally posted by unplugged

(Is it true that when I activate the alternate CC the old CC compression tab is ignored?)

Yes, it is true.



I like much more the *new* curve compression control instead of the older that mostly act by motion and is too localized... (2nd pass tab)
There has _never_ been anything that works 'by motion' in XviD, motion isn't even measured...



This visible fluctuation (either by Croma or Luma... almost it seems this way) happens as if "compression schemes" change a lot from frame to frame [...]
Talking about DivX5, very small motion frame/areas are encoded very constantly with no noticeable fluctuation/pixellation (at resonable/workable bitrates).

[EDIT:] If you are talking about macroblocks, this could really be a motion-compensation thing. Alas, you expressed yourself a bit vague. I had the immediate impression that maybe you only configured XviD in a way that triggered the use of very high and very low quantizers in very rapid change - maybe I had that impression because you mentioned a problem with the alt-cc settings. Well, that's what I first thought, please don't take it cross if you weren't referring to quantizer-jumps.

If you followed the discussion about alt. curve compression on this forum, you'll know that you can easily make XviD treat smaller frames just the way you wish. At least if I got you correctly that with 'compression schemes' you actually mean 'quantizers'. (If you run Debugview during second pass, you can see, how large each frame is and what quantizers is used on it, no need for guessing. And _please_, don't refer to 'motion' when you really mean big frames. The amount of information in a frame can relate to motion, but needn't neccesarily.)

In case you still wonder, just reduce the 'low distance' in the alt.CC-tab to a value around 90% to treat below-average frames VERY benignly (personally, I use 100%). It'll mean that (up to) at a framesize of 10% of the average framesize, the theoretical 'best' quality is used (the curve starts there). Make sure you've set the minimum i/p-frame quantizer to '2'! Of course, the actually used quantizers still depend on the kind of curve type you selected. (If you really want to boost small frames at the cost of big frames, choose 'medium aggression', but there is a building consensus on this forum that 'low aggression' is best - 'low aggression' means that 'compression schemes' won't change very much in the whole encoding...

Thanks for the input on the color fluctuation - a screenshot would be really helpful.

[unplugged]

Originally posted by -h
Also, does it always happen, regardless of input colorspace? Try converting a single sequence to YUY2 and RGB, then compress both with the same settings, and see if you notice the problem in both files.


To be sincere I haven't tried to encode with RGB output, however think nobody ever makes videos in RGB format, just only after YUV-RGB convertion you get little altered colors (and I suppose that these codecs are mostly tuned/developed for YUV format).
For fluctuation I mean macroblocks (visible or not) that draw "almost static areas" with a UNSTABLE croma quantization

When I have written:

This visible fluctuation (either by Croma or Luma... almost it seems this way) happens as if "compression schemes" change a lot from frame to frame
I must say that now I m rather sure that color fluctuation interests only *croma* quantization.

For now look at the image in attachment...
Description: this movie section has a rather slow and continuous movement, panorama approaches slowly but not at the same speed as the actor "shape" come.
Croma fluctuation around head borders:
XviD tends to smear head border with background, generating some *croma* unstable macroblocks.
For unstable I mean those croma values changing (in those critical areas) tonality from frame to frame almost visibly...

take breath :o

...as if the XviD encoder is more incluenced by movie noise (pure detail, with "flashing" noise of course) than the *real* movement of *parts* in image: the actor and the background.
(Hey, don't misunderstand me :D, I know that no codec can distinguish objects or shapes... over the classical macroblock vector scheme :D).
If you only compare single frames, with 2 virtualdub sessions, DivX5 seems only a bit less garbled on this border.
Instead, playing in real time two brief clips, cropped from full 2pass encoded AVIs (same bitrate with standard settings), I have seen difficulties for XviD to draw static or very-slow motion areas, especially when original video content has a little image noise.

In few words, generally XviD has macroblock problems *around* (and often inside) >areas with omomogeous color< (not in patterned/detailed areas); and movie sections when happen small/detectable movements look rather (macroblock) *reencoded* than well vectorized.

Important: I will post a ZIP file with 2 AVI samples cropped from 2 complete test encodings (XviD and DivX501+GMC+Bframe+QPel).
The Mummy: 1h 50min 704x432 (no resize), 1642 kbit/s, approx 1315 Mb final size without titles yet.
(most of frames are more detailed in XviD AVI :) as fast action frames are itential to DVD :eek: ; on the other side in DivX5 B-frames often looks very worse; dialogs, slow panning, actors "shapes" looks *much* uniform, linear, fluid and warm colored... ...to me :D).

[unplugged]

Here are the 2 AVIs.

Sure, there would be other parts in this movie where the artifacts are more tangible...
I know...

For now, my intention has been to upload the same part relative to the previous screenshot.

Sorry Doom9 for the little heavy stuff :o

[-h]

Hrm, I'm not entirely sure, bit I would think that this issue is either a high quantizer simply blurring the chroma component, a flaw in post-processing, or something weirder.

Have you tried:

- comparing constant-quantizer clips of XviD and DivX5
- comparing constant-quantizer clips with post-processing disabled

I've left the zip comparison there, but would people please only download it (~700 KB) if they have a *legitimate* reason for doing so. I can't test it yet, but will in a couple hours.

-h

[unplugged]

First of all I must specify that the image posted is *** 2X *** resized, to not get some people a bit confused about the problem inside screenshot...
Sorry, I have forgotten to write.

Originally posted by -h
Hrm, I'm not entirely sure, bit I would think that this issue is either a high quantizer simply blurring the chroma component

Maybe, but the rest of the image and the flames aren't bad quantized.
It would be useful with XviD having one option to save the 2nd pass "analyze.log"...
I have heard about a debug tool to monitor quantizers, right?

Originally posted by -h

...a flaw in post-processing, or something weirder.

No you see the same thing even with VirtuaDub (it reads AVI by direct XviD decoder, not by DirectShow AX filter...).
However yes the post processing can worsen the approximation even more, as I see with Zoom Player.

Originally posted by -h

Have you tried:

- comparing constant-quantizer clips of XviD and DivX5
- comparing constant-quantizer clips with post-processing disabled


I will try.

P.S.: question about quant:
I know that MPEG4 encoders assign a fixed quantizer for each frame, but taking a single (I)ntra frame for example, the quantizer X is applied to each delta macroblock...
or every macroblock can have a little different quantizer and X only rapresents the average? :eek::confused::o

[-h]

Maybe, but the rest of the image and the flames aren't bad quantized.

True, however it looks more like quantization artifacts (generated by the edges) than anything else I've seen before.

I have heard about a debug tool to monitor quantizers, right?

Dbgview, from www.sysinternals.com , outputs information for the 1st pass, 2nd pass and CBR modes.

or every macroblock can have a little different quantizer and X only rapresents the average? :eek::confused::o

In MPEG4, you can either assign every macroblock in the frame the same quantizer (this is XviD's default behaviour), or you can alter the quantizer on a per-macroblock basis (lumi masking does this).

-h

[unplugged]

Thank you, -h

at the end of my previous post I have talked about Intra frame, it's an error, my intention was talking about Delta frames...

However, you have understood me fine, -h

[-h]

I just had a look at the avi comparison, but I'm not sure what I should be looking for - they both seem fine to me.

-h

[unplugged]

Originally posted by -h
I just had a look at the avi comparison, but I'm not sure what I should be looking for - they both seem fine to me.

-h

I understand you, this is just an example...

look at the pixelizing "fever" in the *head*, try directly in real time with player (only in realtime play you may notice that).
I will search for other part where artifact is clearly evident...

This "pixel fever" (or fluctuation, I have difficulties to find the right word) is almost in all XviD encodes, but in small percentage of frames is clearly evident (but when is evident, make a lot of difference comparing to DivX5 about *image stability*).

As you see in DivX5 the "head" shape is well detected has object with different motion in relation with background, so the border/shape is motion-encoded with care (there isn't pixel fusion/confusion).

However I must say, this could be a poor example for now...

[unplugged]

I have *almost* solved problem!

C:\Windows\System32> regsvr32 /u xvid.ax

:D :D :D

This is filter also generate a strange croma shifiting around left borders of "shapes" (the croma seems to go a bit left leaving alone its "matching luma values"...); disabling the .AX filter solves the fluctuation at 75% and eliminates this croma "ghost" effect.

(no offense to Nic job, I think filter need some precision improvements... infact for now XviD may look worse than it really is, very good)

[chemmajik]

My problems have been on the left side also, I havent tested the right side yet. You may have figured something out I missed unplugged.

[unplugged]

Originally posted by chemmajik
My problems have been on the left side also, I havent tested the right side yet. You may have figured something out I missed unplugged.

The croma dribble appears only on the left vertical side of objects/shapes, but it's only produced by a kind of approximation in the XviD.ax, the DirectShow decoder.
Also, setting postprocess to 0 don't alleviate bluish/pink croma dribble.

You can try by disabling temporarily the filter, go to console prompt:

C:\>cd \windows\system32
C:\windows\system32>regsvr32 /u xvid.ax

("system" if you have Win 9x or ME, not "system32")
later you can reactivate it (without I won't get overlay video acceleration support):

C:\windows\system32>regsvr32 xvid.ax

[MfA]

Could this be related to the overflow bug? (XviD heavily quantizes coefficients, deteriorating hard edges, and at the same time introduces an error in the reference frames which prevents it from fixing it quickly in the next frame.)

[-h]

Could this be related to the overflow bug? (XviD heavily quantizes coefficients, deteriorating hard edges, and at the same time introduces an error in the reference frames which prevents it from fixing it quickly in the next frame.)

That is a good point, any quantizer below 4 (for H.263) can create overflows which simply aren't being catered for. I hope this is fixed soon.

-h