XviD and YV12

[TheCreamCrackerBoy]

Hello to all!

According to Mr. Sh0dan, at Doom's forum http://forum.doom9.org/showthread.php?s=&threadid=79225&highlight=xvid+yv12


* AviSynth has better YUY12 -> YV12 conversion than XviD.
* Many filters are faster in YV12 compared to YUY12.


I would like please to ask some questions:

1) What color system does Xvid uses (YUY12, YV12, RGB24, etc)?
2) Is it a good idea to convert it to YV12 format at Avisynth, according to the sugestion above, writing ConvertToYV12() at Avisynth script?
3) Where can I find some explanation of these color systems (yuy12, yv12, rgb, etc), advantages/disadvantages, and which codecs use which color systems?
4) Is there any relationship between these color systems and low/high bitrate encoding?

Thanks in advance,

The Cream Cracker Boy.

[Manao]

1. XviD uses YV12
2. Yes, but most of the time, you don't need it, since your source is also YV12
3. I don't have a good link to provide right now. Most of the codecs use YV12.
4. Concerning MPEG-4, no, but concerning encoding in general, if you can afford very high bitrate, it's better for you to choose a colorspace that has more bits / pixel

BTW, there's a typo : it's YUY2, not YUY12.

[WaryWolf]

http://www.animemusicvideos.org/guides/avtech/colorspace.html

that page has a good description of the different colourspaces.

[Wilbert]

A quote from that link:
In YUV colorspace you have 3 values: Luminance, or just Luma (which is the brightness level) is abbreviated at Y. U is the Red Difference sample, and V is the Blue Difference sample.
Good, but still not correct description.

I mailed them about it ages ago, but they still haven't changed it.

[zettai]

Those guides are being update but are not yet complete.

The new version of that page is here:

http://www.animemusicvideos.org/guides/avtechbeta/colorspace.html


Edit:
I did some searching on the net after your email Wilbert but either the entire internet has it wrong (or compied it wrong from us :P) or you are :)

I still dont really know which because of conflicting evidence.

[RadicalEd]

The color conversion routines and theory scattered throughout the internet are almost as convoluted and confused as those of aspect ratio. I had to dig through a good four or five conflicting conversion matrices for RGB<->YUV alone before coming up with what is.. I *think*.. the correct one. Along with that came differing reports of what chroma channel U and V each dealt with. I'm pretty sure the correct form is YUV=YCbCr, though most information doesn't make this clear.

[sh0dan]

This is getting a bit off-topic I know, but the following isn't correct:
Cr, when positive, means that the object is red. Cr negative means that the object is green.

Our brain understands these two colors as opposites - If you think about it, no object can ever be red-greenish.

Cb, when positive, indicates blue object. Cb negative means yellow. Again, they are the opposites for our brain and so we have the reasoning behind YUV as a color methodology.
This doesn't make any sense, if you actually look at UV distribution. Have a look at:

ColorYUV(ShowYUV=true)
- This will show you UV, and when you move the frame slider, you only change Y. Cb is left->right. Cr is up->down.

and

Histogram(mode="Color")
- This will show you a UV color distribution of your video.

PS: Red-Greenish = Yellow?

[zettai]

OK so who to believe... syskin (who wrote the paragraph you quoted) or sh0dan... the quest for fact continues!

(edit: I'm looking into it, thanks for the info)

[RadicalEd]

Green is calculated against Cr and Cb, so less of either equates to more green. Red and blue are calculated directly from Cr and Cb respectively. It's not a game of opposites, but rather relative differences between Cr and Cb that define the specific color. Here's the conversion formula for YUV->RGB so you can get an idea of what I mean. Don't ask for the source or tell me it's wrong. I think it differs from the one in avisynth. I also think it's right :p But I could be wrong. Who knows? Muahahaha

R = 128+(Y + 1.402 *V)
G = 128+(Y - 0.344136*U - 0.714136*V)
B = 128+(Y + 1.772 *U )

Updated to 6 singificant digit precision.

[virus]

According to the ITU Recommendation BT.601, the YCbCr components are defined as follows:

Y = 0.299*R + 0.587*G + 0.114*B
Cb = 0.564*(B - Y)
Cr = 0.713*(R - Y)

Now comes the funny part: the 2 latter equations can be rewritten with different roundings of the coefficients, and every standard apparently round them in a slightly different way. Anyway, here are the results with 4 significant digits:

Cb = - 0.169*R - 0.331*G + 0.5*B
Cr = 0.5*R - 0.419*G - 0.081*B

So if R = G = B (a shade of gray) both Cb and Cr will be zero. Increasingly positive values of Cb/Cr thus mean increasingly amount of blue/red in the actual color.
Also, usually Cb = U and Cr = V, but I'm not sure everyone agrees on this (IIRC the MPEG-2 standard has them reversed, and maybe even MPEG-4). Note that some standards use an offset of 2^(b-1), where b is the sample precision of the input, for the Cb/Cr components obtained by the equations above. That's 128 for 8 bit/component depth.

hope this helps :)
virus

[EDIT] swapped a couple of terms for clarity

[Wilbert]

Also, usually Cb = U and Cr = V, but I'm not sure everyone agrees on this IIRC the MPEG-2 standard has them reversed, and maybe even MPEG-4
I doubt that. Both of them are stored as I420. If you pick the U channel in AviSynth, you will see it's Cb.

Maybe I'm missing something, because I'm not a programmer.

[TheCreamCrackerBoy]

Thanks for all of you that have answered my thread. ;-)

Thanks for the url above... If you want to, I've found another good one:

http://www.fourcc.org/index.php?http%3A//www.fourcc.org/intro.php

Best regards,

The Cream Cracker Boy

[virus]

Originally posted by Wilbert
I doubt that. Both of them are stored as I420. If you pick the U channel in AviSynth, you will see it's Cb.I'm not sure about MPEG, really. I did a check... I've got a couple of books and they say two opposite things :(

What I know for sure is that the JPEG family of standards uses U = Cb. Anyway YUV is a broad word that can be applied to a lot of colourspaces. Only YCbCr is standardized AFAIK. Using only these terms would be much clearer.

cheers :)
virus

[cipher]

@virus, there are 5 equations in ITU-R BT.601 Recommendation, which are for colorspace convertions from
1. analogous RGB to analogous Y, (B-Y), (R-Y)
2. analogous (B-Y) and (R-Y) to analogous Cb and Cr
3. analogous YCbCr digtally sampled/quantized to digital YCbCr
4. analogous RGB digtally sampled/quantized to digital RGB
5. digital RGB to digital YCbCr

what this equation,

Cb = - 0.169*R - 0.331*G + 0.5*B
Cr = 0.5*R - 0.419*G - 0.081*B

defines is the 2nd conversion described above (Recommendation ITU-R BT.601-2). :)

A more general equation system for Convertion from RGB to YCbCr is

Y = kr*R + (1 − kb − kr )*G + kb*B
Cb = 0.5(1 − kb) / (B − Y )
Cr = 0.5(1 − kr) / (R − Y )

where kr and kb are weight factors for R and B, respectively (that for G is eliminated, for kr + kg + kb =1) :)

Similarily, we get one for RGB to YCbCr:

R = Y + (1 - kr)*Cr/0.5
G = Y - [kb*(1 - kb)*Cb]/ [0.5*(1 - kb - kr)] - [kr*(1 - kr)*Cr]/ [0.5*(1 - kb - kr)]
B = Y + (1 - kb)*Cb/0.5

what differ among the 5 color space conversions are differently defined weight factors, ie. kr and kb by Rec. ITU-R BT.601. To make things even more complicated, there are different definitions in ITU-R BT.709 too... :p

The conversion done by XviD must've referenced ITU-R recommendation BT.601 - 5 (digital RGB to digital YUV) which, after kb and kr are plugged in, looks like this:

Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
Cr = V = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128

If we actually look it up in XviD's source, we're gonna find this:
(xvidcore\src\image\colorspace.c)


/********** colorspace input (xxx_to_yv12) functions **********/

/* rgb -> yuv def's
....
....
#define Y_R_IN 0.257
#define Y_G_IN 0.504
#define Y_B_IN 0.098
#define Y_ADD_IN 16

#define U_R_IN 0.148
#define U_G_IN 0.291
#define U_B_IN 0.439
#define U_ADD_IN 128

#define V_R_IN 0.439
#define V_G_IN 0.368
#define V_B_IN 0.071
#define V_ADD_IN 128
....


Does it look familiar? ;)

There are different versions of approximation of the equations, and
what Microsoft has documented (http://msdn.microsoft.com/library/en-us/dnwmt/html/yuvformats.asp) is

Y = round( 0.256788 * R + 0.504129 * G + 0.097906 * B) + 16
U = round(-0.148223 * R - 0.290993 * G + 0.439216 * B) + 128
V = round( 0.439216 * R - 0.367788 * G - 0.071427 * B) + 128

And prolly Avisynth has its own version too.

well, back to our topic at last, that ms page has also given the example of upsampling 4:2:0 YUV (YV12) to 4:2:2 YUV (YUY2), and XviD, again, must have done the same thing. :)

[virus]

@chiper

thanks for the infos! :)
I see that all the video compression world uses the YCbCr colourspace with a reduced number of luma levels... now I finally understand where it comes from (I don't d/l standards if they're not for free :D)

The system I wrote about, with kr=0.299 and kb=0.114 (yes, I know that general formula too ;)) is used for image compression (JPEG/JPEG 2000 for sure, and probably even some more standards), so despite the name, it still applies to the digital world :)

What induced me in error is the fact that I found the equations with kr=0.299 and kb=0.114 also in Richardson's book about MPEG-4 and H.264 (!!!). That lead me to think they were universal (i.e. image and video). I should have remembered the "reduced number of luma levels"-stuff, and crosschecked the XviD sources, my bad.

cheers :)
virus

[RadicalEd]

But wait, that doesn't make sense that the digital conversion would use the reduced luma range whereas the analog conversion wouldn't... it should be the other way around. Likewise, I don't understand why the analog conversion as defined by CCIR-601 would be used for digital image processing. At any rate, at some point I must have come across a more precise version of that conversion (#2), because this is what's in my personal converter from a few months ago:
Cr = - 0.168736*R - 0.331264*G + 0.5 *B
Cb = 0.5 *R - 0.418688*G - 0.081312*B
Which of course rounds to the already given:
Cr = - 0.169*R - 0.331*G + 0.500*B
Cb = 0.500*R - 0.419*G - 0.081*B

Updated to 6 significant digit precision.

[virus]

@RadicalEd

I guess "digital" and "analog" are just names. Probably the standards for video coding are geared towards compatibility with the existing television standards (and colour gammas generated by actual CRTs). That doesn't apply to image compression, so maybe they can use a different YUV colourspace. Just my guess, eh, I'm not sure! ;)

I've just checked the JPEG 2000 standard (well, actually the final draft... ;)) and it gives the equations we (me and you) already gave with up to 6 significant digits for the Cb/Cr coeffs. (in JPEG 2000 they're called I1 and I2 anyway - I0 is the luma)

BTW I also think that the YCbCr conversion used by JPEG can be made lossless if you keep enough precision in the intermediate and final results. I plan to write a little prog to verify that if I can find time. I'm curious :D

virus

[RadicalEd]

http://www.jpeg.org/public/fcd15444-1.pdf

Thanks for the heads up. Two of the least significant digits in my equations were off. I've edited them to reflect the correct (according to JP2000 anyway) values.

[virus]

Be careful with that draft! Equation G.9 for the luma component has a typo in the last coefficient: they say 0.144 but it's 0.114, 'cause the sum of coeffs must be 1. I've verified other sources as well. (but maybe they've corrected the pdf now, I d/l the specs 1.5 years ago...)

[P0l1m0rph1c]

I actually found this link helpful:

http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC30

(one more link to the confusion ^^)

[RadicalEd]

Originally posted by P0l1m0rph1c
I actually found this link helpful:

http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC30

(one more link to the confusion ^^)

Holy six digit precision. Thanks :D
-0.168736 contradicts JP2000's rounding though, which sets that element at -0.16875. But since I had -0.16874 originally, I trust this one ;p