Red and Green blocks with latest build

[FalconX]

For the past few weeks I've been uninstalling and re-installing with the latest build of pre-built binaries on http://nic.dnsalias.com/ for xvid, currently I have the ones built on 03/27/02 installed. Yet I still get the red and green small squares.

They seem to appear on any contrasting edges in the encode that don't change after the keyframe. The more P-frames after the I-frame the brighter the red and green squares get, to the point where on some shots they're almost solid red and green and impossible to miss. On some video sources I've encoded you don't run across many scenes where the camera stops long enough for them to be easily seen, but it only takes a few frames for them to be visible at closer inspection.

I read in the FAQ that this was supposed to be fixxed now, but I still get the problem. I just uninstalled XviD again, and noticed something. There was still options saved in the registry for it that didn't get uninstalled, I removed everything relating to xvid from the registry and I'm going to re-isntall xvid and see if this gets rid of the red and green now, if so I'd appreciate it if you made the uninstall give a prompt asking about deleting the old settings from the registry.

If anyone knows anything else I could try to stop getting the red and green blocks (besides something stupid like a 10 frame max I-Frame interval) I'd appreciate it.

Keep up the great work on XviD though, hopefully I'll be able to use it soon.

[avih]

is the fourcc set to DIVX and u use something other than h.263? if that's the case, than it's a known bug with divx decoder haneling mpeg quants. changing the fourcc to xvid or encoding with h.263 should solve the problem.

also, some screenshots with detailed description of the settings would help.

[FalconX]

It occurs using the Xvid FourCC, and using either the mpeg or h.263 quantisizer. I did try playing back the file via the divx decoder, only difference was the red and green blocks were even worse, getting brighter quicker. As for settings, I used 2-pass encoding, and I tried doing a 1-pass quantisizer of 2, and then I tried a quantisizer of 1. Motion search precision has been on 6. I've tried it with or without lumi masking. I've tried it with the full 1-31 quantisizer range for the 2-pass, as well I've limited it to 1-8. I've used both two pass curve compression methods, both using the default methods, but considering it happens with a constant quantisizer I don't think that would effect things much. I've never used the credits options, and cpu optimizations have always been left on "automatically detect optimizations". My cpu is an AMD Thunderbird 1.1ghz.

I did include a zip of an image with the first post, which was under the maximum size of 1mb. don't know if a moderator needs to enable it. If someone wants I can email it to them. I Didn't try all of the above variations on more than one source, but I did try a few of them on another source.

Note: Also, all of this was done using virtualdub opening an avisynth file, I tried both full processing mode, sometimes with the 2d clean filter, and the fast recompress mode.

[FalconX]

Well removing all of the registry setings had no effect and there was still the red(I guess maybe more purple than red) and green squares. The odd thing is, the same video source, using the same settings, and the same build of XviD on a friends pc, it doesn't end up with the red/green blocks. I'm going to give a try at turning off all optimizations now.

[soujir0u]

I get the same problem too using MPEG quantizer, if I change it to H.263 the problem's gone... I'm using XVID FourCC too.

[FalconX]

I get the same problem with both the MPEG quantizer and the H.263 quantisizer though. I tried changing that long ago to fix it.

[-h]

Guh.

Sounds like interpolation.

Yuck.

I'll post a build later on with the old (slower) interpolation code, & see if that fixes it.

-h

[FalconX]

I'll be up for trying anything to fix this. for a image of what it looks like exactly, XviDglitch.zip (http://webpages.charter.net/falconx/XviDglitch.zip).

Well I have to take back something I said. After wiping the registry of anything involving XviD and re-isntalling, using the h.263 quantisizer does remove the issue.

Still though, I would prefer to use the MPEG quantisizer as the softening effect is pretty noticeable.

[Isibaar]

I don't think this is an interpolation problem, could be a quant problem... Any chance you used quantizer=1 and did you once try to disable mmx optimizations in the cpu tab?

[FalconX]

"I don't think this is an interpolation problem, could be a quant problem... Any chance you used quantizer=1"

If you read before you posted you would of read that I tried multiple things, including 2-pass, and using a constant quantisizer of 2 and then 1

" and did you once try to disable mmx optimizations in the cpu tab?"


You also would of read that i didn't try disabling the cpu optimizations till the end and that, that had no effect either.

the only determining factor was choosing mpeg or h.263 quantisizer. I'm guessing the last time I tried h.263 quantisizer was possibly when this problem happened with it as well, as I hadn't tried that one with the latest build till just earlier today. Only having one of the 2 quantisizers available for use though isn't too great.

[-h]

If you read before you posted you would of read that I tried multiple things, including 2-pass, and using a constant quantisizer of 2 and then 1

Ouch man, Isibaar started the XviD project, he's trying to help.

the only determining factor was choosing mpeg or h.263 quantisizer. I'm guessing the last time I tried h.263 quantisizer was possibly when this problem happened with it as well, as I hadn't tried that one with the latest build till just earlier today. Only having one of the 2 quantisizers available for use though isn't too great.

Ah just looked at the screenshot. Definitely quantization, I just thought interpolation because the bad code used to create pink/green squares (though they were much bigger). Seems to be a kooky overflow problem too.

Could you post a 2- or 3- frame huffyuv AVI of that section by any chance?

-h

[FalconX]

Yeah sorry Isibaar I was too harsh, and you're guess that it was a quantisization problem was correct.

Sample HuffYUV avi (http://webpages.charter.net/falconx/NTHT06huffyuv.avi)

[-h]

Just wondering while it downloads (I hate my 28.8 modem), is this clip from the resized source, as it would be immediately before being sent to XviD, or a huffyuv conversion, as in a "Save as" of the flawed XviD avi?

I remember you said that the problem only occurred on your computer, not when you tried it on a friend's with the same clip and XviD build. Testing might be a challenge.

-h

[FalconX]

This is the source as it was before encoding into XviD. I could get the source from cvs and check it out in visual, but I'm not that knowledgeable a programmer when dealing with video. I think it is something specific happening with the mpeg quantisizer on my pc though as its not just this clip. I need to get some sleep tonight but I'll see how confusing the xvid source is to me tommorow.

[-h]

Hm just tried it, and there were no problems at my end.

MPEG quantization only has C and MMX versions (quant_mpeg4.c and quantize4_mmx.asm), and both were fine on my end. I'm honestly not sure what could be going wrong here, but this is the 3rd instance of this problem I've heard of now.

-h

[Isibaar]

Originally posted by FalconX
[B]"I don't think this is an interpolation problem, could be a quant problem... Any chance you used quantizer=1"

If you read before you posted you would of read that I tried multiple things, including 2-pass, and using a constant quantisizer of 2 and then 1


sure I should have read your posts more carefully, but I was in a hurry and just wanted to point out quickly that this is no interpolation problem so -h is not going to waste his time.

Other people reported similar problems like yours while using quant=1, that's why I asked - no need to become annoyed...

Originally posted by FalconX
Yeah sorry Isibaar I was too harsh, and you're guess that it was a quantisization problem was correct.


ok, then.

btw: I also downloaded your huffyuv example and it encodes fine for me, too. So I have some questions: Did you once tried to encode exactly the clip you provided, and if so, did you still experience the red/green problem? Could you also provide a small clip that shows the error?

Also, have you tried a 1 pass quantizer with a higher quant value (say 8)? Would be interesting to know if the bug is then still visible.

quant 1 and 2 are known to cause overflows, therefore, as I wrote the quant code, I added a special treatment for these quant values to prevent overflows. So it's very interesting to know if the artifacts are still visible with higher quant values - if so, it's becoming really strange...

[FalconX]

I just tested encoding the huffyuv in quantisizer of 1, 2, 3, and 4 using the mpeg quantisizer and I didn't get the red and green blocks either, I just went back and checked the full length video where It does occur and the red and green blocks don't start showing up until 52 frames after the keyframe and at that point they're not too visible. If any of the sub blocks have some motion in them then the red and green blocks dissappear until another 50 frames or so of no motion. This particular scene and a lot of others there's only small motion like mouth movement and occasionally one character moving, so the span between keyframes is 283 frames here, at the end of which some edges have the really heavy red and green.

I made a 100 frame huffyuv sample, its 14.9 mb though. I tested encoding it into a mpeg quant of 4, and it showed the red and green blocks.

My webspace unfornately can't hold 14.9mb, I'm going to send a private message via the board to you two with an ftp account to get it, won't be the fastest though.

I did put up a encoded xvid sample on there using quant of 4 that does show the problem.

NTHT06huffyuv100frames to xvid quant4.avi (http://webpages.charter.net/falconx/NTHT06huffyuv100frames to xvid quant4.avi)

Also as a note, it happens at a quantisizer of 1 and 2 as well.