inverted luma blocks with B-frames (Duron only?)

[SleepEXE]

I have been having a problem with what appear to be inverted luma blocks when using B-frames. Please see an example frame here (http://orca.st.usm.edu/~jmneal/files/xvid_luma_inv.png) .

But curiously enough, they only occur on my Duron 1000 machine. Using the same XviD settings, source material, and AviSynth script, these blocks do not occur on the four other machines I use for video compression (Celeron 566, Athlon 1600+, P3 533, and Celeron 1300). I first noticed it with Koepi's Nov 25 release and have been subsequently testing the new releases thinking it may be fixed (all of which, I should add, have worked well on my other machines). I tried one of Umaniac's builds as well and noticed the same thing.

I have tried disabling all processor optimizations in the XviD config which made no difference. The artifacts can be seen in both BSPlayer (dshow) and VirtualDub (VFW).

I have no reason to suspect there is anything wrong hardware-wise with the Duron machine...it decodes and plays back AVI's produced with other machines with no problem and is otherwise stable and trouble-free (actually, it's the media box I use for TV-out). And the artifacts disappear when B-frames are disabled.

I read the XviD forum daily so I'm familiar with most of the common issues...i.e. I always load defaults when installing a new build, use conservative & well-tested settings (no chroma motion, qpel, GMC, etc.). Using mod 16 resolutions, even crop values, and so forth. Reaching my wits' end, I decided to remove any saved registry settings before installing any new builds. Still no resolution.

Some basic info on the configuration:
Avisynth 2.07 (YUY2) -> VirtualDub 1.4.13 (using TRBarry's MPEG2DEC2 or dividee's MPEG2DEC)
First pass:
H.263
MSP 5 or 6
B-frames: 2/130/100 or 3/130/100 or 3/150/100
DX50 B-VOP compatibility
Second pass:
H.263 or New Modulated HIQ
<all other settings default>

I've tried to include all the pertinent details here but let me know if I've neglected something. It's easily reproducible so I'll be glad to test any theories.

Best regards,
SleepEXE

[Doom9]

the problems in the screenshot look very similar to problems I've had with an XviD clip I got yesterday. Then I tried out the latest ffdshow and the problems went away (though they were present on both an Athlon XP and a P3 machine). But it might still be worth a shot...

[Koepi]

Try if _not_ using modulated quantizers makes the encoding problem disappear.

And using ffdshow as playback filter instead of xvid is sometimes a very good idea ;)

Best regards
Koepi

[drebel]

...and i though i was the only one!
Duron 800@933(stable as rock)

I faced the same prob a week ago while encoding "the black adder"
Hint: the prob occured in very HIGH MOTION areas ONLY.
Question: are you using TomMoComp or CNR2 in your script?

In my case,it wasnt a decoding prob(same in virtualDubMod).I really cant remember the use of modulated quantizers.At first ,i thought TomMoComp was to blame because of the setting (1,5,1)-my theory was that the search effort wasnt strong enough to do the trick,but i really had no other (bugless) choice,according to TBarry

So,could u plz check your filter chain?Is any other Duron owner experiencing "luma inversions"?
I 'll try to find a copy of those shitty frames for comparison...

regards,
george

[SleepEXE]

Thank you, gentlemen, for the suggestions. I'll try to address each one.

Doom9, thanks, I will try the latest ffdshow when I get home tonight. However, I suspect it won't help...please note that the artifacts are present in both the VFW- and dshow-decoded clips. Additionally, there are no artifacts present when I decode clips [w/B-frames] on the Duron machine that were previously created on one of my other machines.

Koepi, actually I did try using H.263 on both passes and the artifacts were still there.

drebel, misery loves company, eh? ;) However, I'm not seeing the problem in high-motion areas...it seems quite the opposite, actually. Also, I'm not using TomsMoComp or CNR2. The blocks occur even when there's no filtering at all (encoding the MPEG2 stream to XviD directly with VirtualDub and Avisynth/MPEG2DEC2).

Thanks again, guys. I hope this leads somewhere.

Best regards,
SleepEXE

[fraatz]

Hi!
I'm quite shure this is a part of the flickering macroblocks problem reported in the forum several times.
This is independent from qpel and quantization method, but less visible with h263 due to the smoothing effect.
I mailed suxen_drol a clip showing this problem and got an answer yesterday. It's encoder related and he is working on the bugfix.
Just be patient....;)
Cu
Frank

[SleepEXE]

Hi fraatz, thanks for the input! You seem pretty certain we're talking about the same thing, but has anything been said which would tie the problem to certain CPU's? It just seems really odd that it is only occuring with the Duron...even when CPU optimizations are disabled. Strange.

In any event, I'm somewhat relieved that I'm not the only one who has run into this behavior.

Best regards,
SleepEXE

[fraatz]

SleepEXE,
I'm not that certain when I reread Doom9s reply, cause the Problem I'm taöking about is encoder related
I have the problem on my Athlon and AthlonXp and I don't believe its related to a processor type. Maybe some people simple don't see this phenomenon. You have to look *very* closely, especially when using h263...
Anyway, if you want I can send you the clip vial mail..
Frank

[SleepEXE]

I believe the problem Doom9 experienced is different than mine...the effect may be similar but the circumstances don't match. I'm inclined to think you and I are seeing something different as well, because it is very noticable (even to an untrained eye) in my clips even when using H.263 in both passes.

Nonetheless, everything points to it being encoder-related. If I play back clips with the Duron that were created with another processor, they render fine. If I play back clips created by the Duron on another machine, they have the same artifacts.

Just wanted to confirm that using the latest ffdshow made no difference, as expected...

Best regards,
SleepEXE

[Kurosu]

I should have slept a bit before writing the earlier post


I had a similar problem with divx3 in nandub, that I had narrowed done to the use of quant=2. Rounding errors in the DCT/iDCT using xmm?

@SleepEXE
What happens to those parts when encoded with quant=2 and when encoded with quant=3 (use ffdshow with OSD to display quants) ?

[Defiler]

I am having a very similar problem with the latest (14052003) Koepi version of XviD.
Whenever a quantizer of 2 is involved, I randomly get inverted luma blocks. They are much more obvious when watching the first pass output, simply because there are more frames with q=2. However, they are definitely there in the second pass as well.

In this frame, you can see a pair of them:
http://hellninjacommando.com/misc/xvid/inverted1.jpg

Here is the same frame, with ffdshow visualization enabled, so that you can see the quantizer values:
http://hellninjacommando.com/misc/xvid/inverted2.jpg

Finally, here is the next frame:
http://hellninjacommando.com/misc/xvid/inverted3.jpg

This was a 1-pass fixed quantizer 2 encode, so "inverted3.jpg" is (correctly) a B-frame.

The errors are not there when viewing the Avisynth input, but appear in the output file when viewed with ffdshow, or inside VirtualDubMod, etc. Doesn't seem to matter. I've gotten this with Avisynth 2.0x and 2.5x versions.

Additionally, I don't believe the Avisynth filters are involved, because I've gotten these blocks with at least a dozen different projects, using a wide variety of filter chains.

My XviD settings, used in the above shot:
Motion Search=6
Quantizer=H.263
VHQ=4
Use Chroma Motion
Maximum 4 B-Frames, 150/100/100
Chroma Optimizer
Trellis R-D

I'm 99% certain I've seen this without Chroma Optimizer enabled, and I've definitely seen it with much less aggressive B-Frame settings. I can't recall/verify that I've seen it with lower VHQ settings, or with Trellis R-D disabled. Sorry about the poor test data.

This definitely seems to be a bug, though. I've gotten it with so many different input types, and with a decent variety of settings, both one and two pass.

Thanks.

Edit:
The machine is Windows XP SP1, dual Xeon 2.8GHz. I get the blocks with either auto-detected optimizations, or with all of them disabled.

[Gaia]

I have Duron and i haven't seen anything like this so i don't think it's a bug.

[Defiler]

Note that I don't have a Duron. Heh.

[Gaia]

They are much more obvious when watching the first pass output

Watching first pass output? What do you mean, how do you watch first pass output?

[Defiler]

Originally posted by Gaia
Watching first pass output? What do you mean, how do you watch first pass output? Uncheck "Discard First Pass" in the XviD options.
I usually watch it so that I can know if I need to cancel the second pass to change some options. Saves time.

[Defiler]

I'm repeating that encode right now, with the exact same settings and input, with Trellis R-D disabled. I'll report back in 3 hours.

[Gaia]

Ok i never do it like that. I just do normal first pass, then encode example 10 000 frames of 2nd pass. Stop it and check out quality. If i am happy what i see i restart it. If not i do another 1st pass. For me that works a lot better.

Anyway i had similiar problems with very first b-frame builds when mpeg quantization and b-frames together there buggy but vhq works fine.

[Zarxrax]

I am getting this error as well, but my setup sounds vastly different.
First of all, im encoding on a P4 processor, so the bug is not restricted to durons.
I am NOT encoding with B-frames, so they aren't the culprit either.
I only get these blocks when I have vhq enabled.

[Defiler]

OK. Disabling trellis seems to fix it. I haven't seen any yet.

[Zarxrax]

Yep, thats right. Funny thing is, I was certain I had tried it without trellis and had no change... guess its easy to slip up when you are making like 20 test encodes though :p

Funny thing though... when I enable vhq now, my encode gets BIGGER O_O

[Suikun]

Originally posted by Zarxrax
Funny thing though... when I enable vhq now, my encode gets BIGGER O_O

As far as I know this is actually intended. Some time ago VHQ was changed to favour quality to filesize. Koepi changed it a bit again so that the difference in filesize wouldn't be that big.

[sungey]

hmm i never use Trellis ... maybe that's why i never get this block ... using Athlon here ...

[ssjkakaroto]

so Defiler was it really the trellis quant. that caused the problem? i did a test last night (before i read this topic) with trellis enabled and i got those artifacts too, going to test it later with it disabled to see if they're gone too.

[Gaia]

I just made full movie rip and couldn't see any blocks with trellis and vhq 4...

[Defiler]

Originally posted by ssjkakaroto
so Defiler was it really the trellis quant. that caused the problem? i did a test last night (before i read this topic) with trellis enabled and i got those artifacts too, going to test it later with it disabled to see if they're gone too. Yes. I've done about 10 non-Trellis encodes since then, with no blocks. I'm good at seeing single-frame artifacts while watching the video play, so I would definitely notice them if they were there.

[ssjkakaroto]

yep, disabling trellis worked for me too, thx for the heads up defiler