2 bugs with decoder in latest XviD-1.0.2-29082004.exe (koepi)

[fisix]

after installing the latest xvid pack as compiled by koepi, i found two bugs with the included decoder. one is concerning the configure decoder applet (and not so important), and the other is concerning a video artifact (important!)

1) video artifact. something is wrong with how red is sent to the overlay/video renderer. i used an xvid encoded copy of Stanley.Kubrick.A.Life.In.Pictures.2001.XVID.avi to test. About 0:2:44 into the video there is a title page of red lettering (Stanly Kubrick, a life in pictures) on a black background. i tested with the latest standard zoomplayer and switched back and forth between divx 5.1 and this latest xvid decoder.

with the divx decoder, the red lettering looks like normal sharp lettering in a movie title page at high bitrate. the xvid decoder, however, produces very blocky and bleeding red lettering. i checked this against white lettering in the same encode and the blockyness and bleeding aren't there. this looks a bit like the old dvdplayer mpeg2 decoder error, but more pronounced. i seem to remember the gurus in the doom9 avisynth developer forum discussing a similar error encountered when incorrectly converting from yuv4 to yv12, or maybe the other way around. can't remember, and i can't find the old thread (used to be sticky). rather than rely on my useless memory, hopefully i've given enough info so that you can check on your own. i've seen the same issue with red lettering on black background in other encodes, so you shouldn't need video from me to see the problem.

i tried to make a set of frame grabs that showed the difference, but i can't get the frame grabber to get the xvid frames. i'll work on that and post back if i can get them up.

the rest of the decoding seems good, and black and white looks especially good when compared to the divx decoder.

let me know if you need more info, i think this one is important to fix.


2) the configure decoder applet has options to check, including the option to use the xvid decoder to decode divx files, but the 'apply' button is always greyed out. as far as i can tell, the only way to get any of the options to change is to reregister the decoder (zoomplayer has a way to do this) or possibly reboot. even then, the only option i know for sure that i can get to change this way is the option to decode divx files.

so, the configure decoder is buggy and needs fixing.


my setup: zoomplayer 4.03, using vmr9, clean install of divx 5.1 and the xvid version referenced above. nvidia card in an intel p3 1GHz running windows 2000. all windows updates installed, including the latest directx.

please post back, even if it is just a 'i read it, don't know when we can get to it' post.

thanks

-fisix

i am posting this here and at xvid.org because 1)there is more traffic here, 2)i reference a doom9 forum, maybe some regulars will be available to help, and 3)xvid.org should have a record of it.

[Koepi]

Your observation of the "decoding error" got explained some hundred times. It has to do with the colour space used to decode to. If it's YV12, a chroma pixel has a "real" dimension of 2x2 pixels which looks blocky if it doesn't get interpolated.

You can override the used colour space in the xvid decoder option - it'll result in interpolation of those "2x2 chroma pixels". Try RGB24 or YUV2, you'll be surprised.

Regards
Koepi

[sysKin]

Originally posted by fisix
i tried to make a set of frame grabs that showed the difference, but i can't get the frame grabber to get the xvid frames.
It is perhaps worth noting that if you can't grab the frame, you are NOT using vmr9. You're using overlay.
This is probably the cause of the bleeding - overlays might, or might not, be interpolated differently than 2d/3d textures.
2) the configure decoder applet has options to check, including the option to use the xvid decoder to decode divx files, but the 'apply' button is always greyed out. as far as i can tell, the only way to get any of the options to change is to reregister the decoder (zoomplayer has a way to do this) or possibly reboot. even then, the only option i know for sure that i can get to change this way is the option to decode divx files.Changes happen immidietly. No need to "apply" them.
I agree that thr button should be removed.

Radek

[fisix]

Originally posted by sysKin
It is perhaps worth noting that if you can't grab the frame, you are NOT using vmr9. You're using overlay.
This is probably the cause of the bleeding - overlays might, or might not, be interpolated differently than 2d/3d textures.
Changes happen immidietly. No need to "apply" them.
I agree that thr button should be removed.

Radek

is there some reason why i could grab a divx frame and not an xvid frame? one worked, the other didn't. zoomplayer says that i am using vmr9...

the changes don't seem to happen immediately. at least with the divx decoder, i can clearly see the difference when i switch from no film effect to film effect. when i try the same with the xvid decoder, i can't see any difference. same goes for the other postprocessing check boxes. if it's there and subtle, then i may be missing it, but:

the one option that i'd like to be able to toggle easily is the check box to enable decoding of divx files. having it on or off seem to work excatly once after installation, but after that it doesn't seem to change anything, and the divx decoder ends up decoding everything. as i mentioned above, the only way i've been able to reliably turn off and on the xvid decoder is to change its relative priority with the zoomplayer filter manager and then reregister all the codecs.

sorry about the repost of the red bleed yv12 error. i looked back a couple pages and didn't see mention of it. as yet another test of the configuration applet, i'll try changing the colorspace.

[sysKin]

Originally posted by fisix
is there some reason why i could grab a divx frame and not an xvid frame? one worked, the other didn't. zoomplayer says that i am using vmr9...
Well, I don't know the details of VMR9 - but the bottom line is, they are rendered differently, and this is the reason for ugliness (and in fact any differences) you're seeing.
XviD works well with VMR9 here - in fact it even uses it for aspect ratio correction (in xvid 1.1).
I'd like to know why it doesn't seem to work in your system...

the one option that i'd like to be able to toggle easily is the check box to enable decoding of divx files. having it on or off seem to work excatly once after installation, but after that it doesn't seem to change anything, and the divx decoder ends up decoding everything. as i mentioned above, the only way i've been able to reliably turn off and on the xvid decoder is to change its relative priority with the zoomplayer filter manager and then reregister all the codecs.
I think you misunderstood what this option does. It makes XviD support DIVX fourcc. It does not force XviD decode this fourcc, this is not possible.
If you've got more than one decoder that support given fourcc, it is indeed not obvious which is chosen. The one with higher priority is chosen. If they have the same priority, the one which was registered last is chosen. In either case, it's an issue with directshow, not any particular filter.

XviD always registeres itself as supporting DIVX fourcc. If asked by directshow to decode, it checks for configuration and - depending on it - accepts or rejects. But the point is, it can only accept if some other decoder (divx, ffdshow, 3vix, ND) didn't accept first.

[fisix]

Originally posted by sysKin
Well, I don't know the details of VMR9 - but the bottom line is, they are rendered differently, and this is the reason for ugliness (and in fact any differences) you're seeing.
XviD works well with VMR9 here - in fact it even uses it for aspect ratio correction (in xvid 1.1).
I'd like to know why it doesn't seem to work in your system...this was completely a misunderstanding on my part. i fixed it and now i can get frame grabs just fine. sorry.
But the point is, it can only accept if some other decoder (divx, ffdshow, 3vix, ND) didn't accept first.
i assumed that xvid files would be decoded by the xvid decoder even if divx was set to decode generic mpeg4.. arg. sorry. fixed now.

however, i now have frame grabs of the video problem i mentioned. the two grabs i have are of a divx decode and an xvid decode. the xvid decode is the best looking one out of the different selectable colorspaces, which was yuy2, and which also seems to be what is output when 'don't force' is selected. the two things you can clearly see: 1)the xvid decode makes black look black while divx looks a little greyish, and 2) the blockyness is clearly visible in the red lettering in the xvid decode.

it looks like the xvid decoder is ignoring some of the coeffecients in the colorspace transform. most of the red lettering looks like it is decoded to a lower resolution than in the divx decode, and then maybe some sort of (subpar) interpolation is applied (as koepi described). the blockyness looks even worse when forced to yv12. anyway, whatever it is, you can clearly see the differences if you download the images and view the letter 'S' zoomed in.

divx decode:
http://physics.usc.edu/~kevinwhi/divx.bmp

xvid decode:
http://physics.usc.edu/~kevinwhi/xvid.bmp

is this a bug, or is it the result of a choice made out of a need for speed in the decode?

edit-> i also tried rgb24 as a color space but zoomplayer started using the nero video decoder, so i don't have data on that. what colorspace does the divx decoder output to?

[sysKin]

Yeah that looks pretty ugly. I wonder if divx is doing some interpolation/smoothing on chroma planes? I'll try to figure it out.

[fisix]

thanks, syskin. let me know if there is anything you'd like from me.

[chilledoutuk]

you are sure that posprocessing is switched off in the divx playback filter? as this could be smothing out the blocks.

also have you tried using ffdshow to decode the divx to see if that has the same blocking problem?

[fisix]

Originally posted by chilledoutuk
you are sure that posprocessing is switched off in the divx playback filter? as this could be smothing out the blocks.

also have you tried using ffdshow to decode the divx to see if that has the same blocking problem?

just to make sure, i'll make up some new grabs that compare both with post processing on, and both without. the two above both had partial post processing on.

by the way, i'm not decoding a divx encoded file, i'm decoding an xvid encoded file.