chroma upsampling bug

[raymod2]

I play my XviD files on a 42" LCD projection and I have long been annoyed by an artifact that occurs mostly around the edges of highly saturated colors (usually reds). Just recently I stumbled across a description of the so-called "chroma upsampling bug" that described my problem exactly. After doing some experiments on my system I was surprised by what I found out. I created some AVS scripts, loaded them into VirtualDub, and looked at a frame that shows the artifact. The first script I tried was:

AviSource("cutaway.avi")
Info()

This indicated that the colorspace was YV12 and the artifact was present. I'm not sure who is doing the chroma upsampling here (does anyone know?) but it is apparently being done incorrectly. Next I tried the following script:

AviSource("cutaway.avi")
ConvertToRGB()
Info()

This indicated that the colorspace was RGB32 and the artifact was gone. From this I conclude that AviSynth does the chroma upsamping correctly in the ConvertToRGB() filter. Next I tried the following script:

DirectShowSource("cutaway.avi", 23.976)
Info()

This indicated that the colorspace was YUY2 and the artifact was present. Hmmm, it appears that the DirectShow filter graph had already upsampled it (incorrectly) so there was nothing I could do at this point to fix it. So I poked around in the XviD decoder settings and found an option called "Output Colourspace". It was set to "No Force". I tried setting it to "YV12" and then reloaded the previous AVS script. This time it indicated the colorspace was YV12 and now I could prevent the artifact by using ConvertToRGB().

The other interesting thing I noticed is that the artifact went away during video playback when I left the XviD decoder set to output YV12. I am using BSPlayer, by the way, and I did have to go into the preferences and uncheck "Disable YV12 format" or else I got the following error: "Unknown file format (XVID)".

From what I read people were blaming the video card hardware, video card drivers, and the video renderer for incorrect chroma upsampling but it appears (at least in my case) that the XviD decoder was to blame. By the way, I have Koepi's 1.0.3 version of XviD installed. Is this a known issue with XviD in general (or Koepi's build of it)?

[Koepi]

It's a known hardware issue on nvidia cards, it's also known from broken drivers.

Such a long post for just trying to blame xvid for doing thngs correctly.

Cheers
Koepi

[raymod2]

I don't own an nVidia card. I am using an ATI Radeon 9700 Pro. Besides, I thought I demonstrated (in my long post) that the XviD decoder was upsampling from YV12 to YUY2 incorrectly. If I'm wrong, please explain the flaw in my logic.

[celtic_druid]

Yes XviD by default outputs YUY2, however you can change that in the decoder config.

[Soulhunter]

Originally posted by raymod2

From what I read people were blaming the video card hardware, video card drivers, and the video renderer for incorrect chroma upsampling but it appears (at least in my case) that the XviD decoder was to blame. By the way, I have Koepi's 1.0.3 version of XviD installed. Is this a known issue with XviD in general (or Koepi's build of it)?

Well, yes and no!

Maybe have a look @ this thread... (http://forum.doom9.org/showthread.php?s=&postid=598456)

As XviD is YV12, the decoder should output it as YV12!


@ Koepi

In some way raymod2 is right...

The XviD decoder does the chroma upsampling wrong!

IIRC I already mentioned this somewhere in the XviD v.1 threads... :\

Leaves the question if a decoder should do any color conversations @ all?


Bye

[Koepi]

Well, colour conversation will be fun ;)

XviD spits out what it's asked to in first place; might it be YV12 or YUV2. If it's YUV2, it has to do a colour space conversion, admittedly.

XviD doesn't use any interpolation filters in such case, but simple line or pixel-doubling. That is no bug, that is what it's intended to do. If you want different behaviour in that aspect, code a linear or even more complex interpolation for doing the upsampling.

Let me repeat. This isn't a bug. You can output to an apropiate colour space and let your vga or it's driver let do the upsampling. If it's interpolated or just repeated pixels, well...

Koepi

[neuron2]

Yes, but doesn't the choice of which pixels to repeat depend upon the interlaced/progressive status of the frame? Does your conversion allow for that?

Not being evil here, Koepi, just curious. :D

[Koepi]

Yes, it's a difference when dealing with interlaced or progressive material here. Do you think XviD's devs don't know that?

You can look into the xvid sources, there into the colour space conversions. Except for the mmx the code is readable.

They're just fine. (Might need an interpolation filter for final user convenience [so that others will beat down XviD for smearing the image too much. People always do that if you try to make things right for a certain group.]).

Koepi

[Soulhunter]

Originally posted by Koepi

XviD doesn't use any interpolation filters in such case, but simple line or pixel-doubling. That is no bug...

Like we say here, its in the eye of the beholder... ^^

Imho chroma upsampling without interpolation is buggy!


Originally posted by Koepi

...that is what it's intended to do. If you want different behaviour in that aspect, code a linear or even more complex interpolation for doing the upsampling.

Unfortunately I have zero programming skills... :\

But I ask around to find someone that knows how to do it!


Originally posted by Koepi

Let me repeat. This isn't a bug. You can output to an apropiate colour space and let your vga or it's driver let do the upsampling. If it's interpolated or just repeated pixels, well...

But for what are the "non YV12" output colorspaces good then?


Bye

[Koepi]

They're there so you can workaround buggy drivers/hardware to find a proper colour space which gets upsampled correctly :p

[Soulhunter]

Originally posted by Koepi

They're there so you can workaround buggy drivers/hardware to find a proper colour space which gets upsampled correctly :p

The problem is that the renderer can't upsample the chroma anymore if it was already upsampled by the decoder... Means, the only "correct" output colorspace is the colorspace of the source itself. And, as all MPEG4² stuff is YV12, the only³ output colorspace you need is YV12!

³ Assuming that all renderers/gfx support YV12!?

² Apart from some studio profiles maybe...


Bye

[raymod2]

Originally posted by Koepi
They're there so you can workaround buggy drivers/hardware to find a proper colour space which gets upsampled correctly :p

This logic amazes me. Why risk having your renderer or video card upsample wrong when you can have XviD do it and be sure that it's done wrong??

BTW, I've attached a comparison of correct and incorrect upsampling. The one on the left was upsampled by the XviD decoder and the one on the right was upsampled by the AVISynth filter ConvertToRGB(). You be judge.

http://www.myfilestash.com/userfiles/raymod2/chromax2.bmp

[neuron2]

The one on the right looks much more gooder to me. :)

Especially the red stripe on his arm.

Strictly speaking, though, it isn't a bug. It's just a low quality upsampling. It's a bit surprising that a high-quality codec would use nearest neighbor upsampling.

[Koepi]

a) Noone took the time to code interpolated upsampling
b) it's a speed issue. There's this general assumption around that upsampling should be done in hardware... well, anyhow, as long as noone is coding it, we won't see a nicer (and slower) colour space conversion.

:)

Regards
Koepi

[Soulhunter]

Originally posted by Koepi

a) Noone took the time to code interpolated upsampling

I dont know, but...

Wouldnt it be possible to use some code from AviSynth for this?


Originally posted by Koepi

b) it's a speed issue. There's this general assumption around that upsampling should be done in hardware... well, anyhow, as long as noone is coding it, we won't see a nicer (and slower) colour space conversion.


C'mon "it's a speed issue" is imo not a valid argument...

Then you could say the same about XviD's VHQ modes n' other options, no?

You could simply set the decoder to output YV12 to get the old "fast but worse" output!


Bye

[Soulhunter]

Originally posted by Soulhunter

I dont know, but...

Wouldnt it be possible to use some code from AviSynth for this ???

Yeah, it is... (http://forum.doom9.org/showthread.php?s=&postid=615160#post615160) :D


Bye

[bleo]

I think the problem may be 'encoded' into your source!

There's a long explanation of the chroma upsampling bug here: http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html. Some of what I'm about to say is for further explanation to readers.

The way I see it, there are two types of YV12. One with 'progressive chroma' where the chroma samples are averaged over two adjacent lines, and another with 'interlaced chroma' where the chroma samples are averaged from every second line.

DVDs can have either type, and I have found no reliable way of telling besides manually examining the picture. Whether the DVD is film or TV, frames or fields, progressive or interlaced, telecined, force filmed or whatever has no bearing on whether the chroma is progressive or interlaced.

Now, when you playback the YV12 you have to upsample the missing chroma samples but you don't know whether it has progressive or interlaced chroma! If you use the opposite upsampling method to how the YV12 was downsampled in the first place, then it will look wrong, hence the 'chroma upsampling bug' as described.

However, YV12 decoders simply stick to one of the upsampling methods and hope that they get it right half the time! There is nothing 'wrong' with how xvid upsamples! From my quick look, I think xvid and the avisynth colorspace conversion filters use progressive chroma upsampling, and VirtualDub uses interlaced chroma upsampling but this might depend on your filters and video card.

So what do you do if your YV12 decoder is using the wrong upsampling method for your source? In Avisynth you can use ConvertToYUY2(interlaced=true). If you're converting a DVD to xvid or any other format that stores in YV12, then the problem is a bit more complicated and I can try to explain if anyone asks...

[Soulhunter]

Originally posted by bleo

I think the problem may be 'encoded' into your source...

Well, not in the source of raymod2...

The sample shows just the "usually" bad chroma upsampling:

Interlaced upsampling bug:
http://img74.exs.cx/img74/6127/iubug5lm.png (http://www.imageshack.us)

The "usually" bad chroma upsampling:
http://img73.exs.cx/img73/6381/chromax22dt.png (http://www.imageshack.us)


The first bug should be removed before encoding...

But the second one can only be removed while playback!


Bye

[ChronoCross]

The issue of speed in the upsampling is quaite a aparent to what most ocmputers can handle and a slower version would screw 60% of xvid users. I can ahandle all the current advanced feature like VHQ GMC Trellis but as soon as I start adding post processing such as deblocking and whatnot my Pc acts like it's gonna die. If it had to do a HQ colorspace conversion during playback I wouldn't be able to watch anything I encode with xvid. using any one of avisynths colorspace conversions islike wishing death on my viewability.

[Soulhunter]

Originally posted by ChronoCross

The issue of speed in the upsampling is quaite a aparent to what most ocmputers can handle and a slower version would screw 60% of xvid users. I can ahandle all the current advanced feature like VHQ GMC Trellis but as soon as I start adding post processing such as deblocking and whatnot my Pc acts like it's gonna die. If it had to do a HQ colorspace conversion during playback I wouldn't be able to watch anything I encode with xvid. using any one of avisynths colorspace conversions islike wishing death on my viewability.

Well, you dont have to use this option!

Thats why its a option... ;)


Bye

[raymod2]

Originally posted by ChronoCross
The issue of speed in the upsampling is quaite a aparent to what most ocmputers can handle and a slower version would screw 60% of xvid users. I can ahandle all the current advanced feature like VHQ GMC Trellis but as soon as I start adding post processing such as deblocking and whatnot my Pc acts like it's gonna die. If it had to do a HQ colorspace conversion during playback I wouldn't be able to watch anything I encode with xvid. using any one of avisynths colorspace conversions islike wishing death on my viewability.

Now that's just good science! HIS computer slows down when he enables deblocking. Therefore, 60% of XviD users will suffer performance problems if the chroma upsampling algorithm is changed. QED.

Even if this ridiculous logic were true, nobody is asking the XviD team to remove YV12 decoder output. All we are asking is that if you are going to offer YUY2 or some other upsampled colorspace then don't cripple it by using nearest neighbor sampling.

[Soulhunter]

@ raymod2

Btw, have you already tried the new ffdshow builds with optional HQ upsampling?


Bye

[raymod2]

Originally posted by Soulhunter
@ raymod2

Btw, have you already tried the new ffdshow builds with optional HQ upsampling ???


No, I currently have XviD set to output in YV12 and I am letting my renderer or video card do the upsampling. It looks much better now. Is there any reason to think that ffdshow would do a better job? I'm not sure I want to jump on the ffdshow bandwagon and deal with the incompatibility problems.

[Soulhunter]

Originally posted by raymod2

No, I currently have XviD set to output in YV12 and I am letting my renderer or video card do the upsampling...

Would like to know which of them does the upsampling!

Do you use VMR9 windowed or OverlayMixer?


Originally posted by raymod2

Is there any reason to think that ffdshow would do a better job?

Yes, if your gfx is not able to upsample internally @ hardware level... Most Radeon cards (thats why I would like to know which mode you use) are able to upsample the chroma internally when feeding OverlayMixer with YV12 data. But most Nvidia cards (at least all I used) dont have this ability, so you have to use VMR9 windowed instead of OverlayMixer to get correct chroma upsampling. But VMR9 itself could cause some problems (tearing and a raised gamma level is the most reported problem) So, if you have a gfx without proper internal chroma upsampling, you can use ffdshow's HQ Y12 -> RGB upsampling to get correct upsampling even with OverlayMixer as renderer!


Bye

[raymod2]

In my BSPlayer Preferences->Video->Video_Rendering I have "Use overlay Mode 1" selected. When I open an XviD file in GraphEdit it says I am using "Video Renderer" and when I right-click on it and select "Filter Properties" it says "VMR-7 is in non-mixing mode". When I list the DirectShow filters there are two of them called "Video Renderer" and they both point to C:\WINDOWS\System32\quartz.dll.

[Soulhunter]

Originally posted by raymod2

In my BSPlayer Preferences->Video->Video_Rendering I have "Use overlay Mode 1" selected. When I open an XviD file in GraphEdit it says I am using "Video Renderer" and when I right-click on it and select "Filter Properties" it says "VMR-7 is in non-mixing mode". When I list the DirectShow filters there are two of them called "Video Renderer" and they both point to C:\WINDOWS\System32\quartz.dll.

Hrm, any chance that you install MPC to do a test with all render modes?

http://img83.exs.cx/img83/6449/mpc1nz.png (http://www.imageshack.us)


Bye

[dark.soft]

Hi, I had the same problem of raymod2: I've made an avisynth script:
LoadPlugin("C:\DIVXMA~1\Encoders\GORDIA~1.0\DGMPGDec\DGDecode.dll")
mpeg2source("F:\avp\a.d2v")
crop(0,70,720,436)
LanczosResize(640,272)

and if I watch the avs with mpc, I get the artifacts. If I watch the resulting xvid file, I also get them, but if I set in xvid decoder options, yv12 as the output colour space, I don't get the artifacts. If I add Converttorgb() after mpeg2source, I don't get the artifacts watching the avs, but I get them in the xvid file if I don't set yv12 as the output colourspace. So, the xvid stream resulting from the avs with the rgb conversion line has the artifacts on it or not?

[raymod2]

dark.soft:

The artifact is not present in the XviD stream at all. The XviD stream is stored as YV12 (12bpp). It gets displayed as RGB (24bpp). When you let the XviD DECODER do the upsampling (which is unfortunately the default which most people probably use) it uses a braindead nearest neighbor algorithm which causes the artifact.

[Japhsoncross]

well i have a geforce2ti, and it can't make correctly upsampling when the output is yv12 by xvid decoder or ffdshow when the renderer is overlay mixer, but when i set the output color space to yuy2 in ffdshow, and the upsampling seems quite good even if the renderer is overlay mix. i see the decoding info in ffdshow, when ffdshow outputs yv12 to geforce2ti overlay mixer, we get the wrong hardware upsampling. when ffdshow outputs yuy2 to geforce2ti overlay mixer, we get the correct hardware upsampling. i also have radeon9200 and radeon9550, when the output is yv12 to overlay mixer, the result is correct. i remember geforceFX9500XT can make correct hardware upsampling when the decoder outputs yv12 to its overlay mixer
btw: i set the option "hq yv12 -> rgb" in ffdshow, but is doesn't seem it has better quality than that when i just set the output to yuy2.
when i set the renderer to overlay mode 1 in bsplayer the ffdshow outputs yuy2, and when i set overlay mixer in bsplayer, the ffdshow outputs yv12.

sorry for my bad english :)

[planet1]

Since the default colourspace output of the xvid decoder is YUY2 (and according to the course of this discussion that will remain so for a while :confused: ), i wonder how all the other mpeg4 asp filters manage ?

well divx & ffdshow output YV12

what about 3ivx, nero, moonlight, intervideo etc.?

I could be wrong, but wasnt there a deinterlace option in the decoder prior to the 1.1 Betas ?

@Koepi - please add a uninstall entry for the start menu in your next release (Nic's builds have one ;) )