Preserving MPEG Brightness

[Wilbert]

[MODERATOR]: Continued from this thread.

@Didee and others,

I have made some progress in understanding this issue!

Let me first summarize my findings and then give the evidence:

1) dvd2avi/AviSynth is recreating the clip correctly. No variations in brightness due to AviSynth.
2) The mpeg2 decoder which is used in VirtualDub/VirtualDubMod (I will ask Avery which one this is) is messing up. It's only messing up if there is GREEN in the clip.

In order to test this I made the following script

#mixUVc.avs
BlankClip(pixel_type="YV12", width=720, height=576, color=$00ff00)
# green: Y=145, U=54, V=34
ConvertToYV12
#ColorYUV(analyze=true)

I opened the script in QuEnc and made a m2v file from it. Which I opened in AviSynth (with dvd2avi) using the following script

#mixUVc2.avs
mpeg2source("F:\mixUVc2.d2v")
ColorYUV(analyze=true)

If you open mixUVc2.avs and the m2v file in VDub, you will notice two things:
1) mixUVc2.avs looks exactly like the original script (ie mixUVc.avs)
2) mixUVc.m2v looks a bit darker than the original script (ie mixUVc.avs)

I repeated the test for the red clip (mixUVd.avs) and the blue clip (mixUVe.avs), which didn't show any difference in brightness.

All files can be found here
http://www.geocities.com/wilbertdijkhof/mix.zip

[Si]

2) The mpeg2 decoder which is used in VirtualDub/VirtualDubMod (I will ask Avery which one this is) is messing up.

AFAIK There are no MPEG-2 decoders in any VirtualDub versions written by Avery.

regards
Simon

[Wilbert]

I meant that VDub/VDubMod uses external mpeg decoder converters (maybe mpeg1 dunno):

(...) There used to be support for YV12/I420, but I removed it because it was reusing the MPEG decoder's converters and in recent versions those have strict alignment requirements for SSE2 optimization.

http://virtualdub.everwicked.com/ind...=6985&hl=yv12&

edit: Oh, I get what you mean. Of course VDub can't open mpeg2 files. I will ask the VDubMod folks about this.

[fccHandler]

AFAIK, VirtualDubMod borrows the MPEG-(1/2) code from my VirtualDub-MPEG2 mod, so you should've asked me first.

I downloaded your mix.zip, and the first thing that caught my attention was the fact that QuEnc uses matrix_coefficients = 4 in the "sequence display extension" for mix2.mpg. This value specifies the FCC's coefficients for red, green, and blue (0.3, 0.59, 0.11), rather than ITU's default MPEG-2 coefficients (0.2125, 0.7154, 0.0721), or the more common MPEG-1 coefficients (0.299, 0.587, 0.114).

It's important to note that the "sequence display extension" and "matrix coefficients" fields are optional. But if they are present, my MPEG-2 decoder will use them to convert to RGB. It is the responsibility of the encoder to specify the correct coefficients the decoder should use. And I guarantee that VirtualDub-MPEG2 presents the RGB image correctly, based on those coefficients.

(By corollary, "matrix coefficients" has no meaning if the decoder is not converting to RGB.)

Naturally there will be a discrepancy if Avisynth's "ConvertToYV12" command is not using the same coefficients that QuEnc has specified for the stream, and I think that's what you are seeing.

[Wilbert]

I downloaded your mix.zip, and the first thing that caught my attention was the fact that QuEnc uses matrix_coefficients = 4 in the "sequence display extension" for mix2.mpg.

dammit: I thought I replaced mix.zip by a new one. I will try again tonight.

[trevlac]

Originally posted by fccHandler

I downloaded your mix.zip, and the first thing that caught my attention was the fact that QuEnc uses matrix_coefficients = 4 in the "sequence display extension" for mix2.mpg. This value specifies the FCC's coefficients for red, green, and blue (0.3, 0.59, 0.11), rather than ITU's default MPEG-2 coefficients (0.2125, 0.7154, 0.0721), or the more common MPEG-1 coefficients (0.299, 0.587, 0.114).

It's important to note that the "sequence display extension" and "matrix coefficients" fields are optional. But if they are present, my MPEG-2 decoder will use them to convert to RGB. It is the responsibility of the encoder to specify the correct coefficients the decoder should use. And I guarantee that VirtualDub-MPEG2 presents the RGB image correctly, based on those coefficients.

This is such a cool place! Who would have thought the stream can carry the coefficients! Wow!

[Wilbert]

I updated the mix.zip with the good files.

I downloaded your mix.zip, and the first thing that caught my attention was the fact that QuEnc uses matrix_coefficients = 4 in the "sequence display extension" for mix2.mpg. This value specifies the FCC's coefficients for red, green, and blue (0.3, 0.59, 0.11), rather than ITU's default MPEG-2 coefficients (0.2125, 0.7154, 0.0721), or the more common MPEG-1 coefficients (0.299, 0.587, 0.114).

1) I'm using QuEnc 0.52, but I guess the user can't change this setting (matrix_coefficients = 4)?

2) These are for the luma, YCbCr [0,255] -> RGB [0,255] right? Why are the coefficients "0.3, 0.59, 0.11" used?

But, should the coefficients be used for a YCbCr [16,235] -> RGB [0,255] conversion (ie 0.257, 0.504, 0.098)?

3) I will try it with TMPGEnc and post my findings.

[fccHandler]

Originally posted by Wilbert
1) I'm using QuEnc 0.52, but I guess the user can't change this setting (matrix_coefficients = 4)?

I'm embarrassed to admit I've never used QuEnc, but so far I haven't seen an MPEG-2 encoder which allows you to specify the "matrix coefficients" field explicitly. TMPGEnc has a "video format" setting, but I'm not exactly sure what it does...

2) These are for the luma, YCbCr [0,255] -> RGB [0,255] right? Why are the coefficients "0.3, 0.59, 0.11" used?

If present, the "matrix coefficients" field specifies a set of coefficients given in Table 6-9 of ISO/IEC 13818-2, section 6.3.6. These are defined as the coefficients which were used by the encoder to convert the original RGB signal to the native YCbCr of MPEG-2. The tables describe nine coefficients, but in reality only three are needed; the coefficients which describe the relation of luminance to RGB (the other six coefficients can be derived from that). Assuming the coefficients are 0.299, 0.587, 0.114, the math for luminance (Y) is defined as:

Y = (0.299 * (219 / 255) * R) + (0.587 * (219 / 255) * G) + (0.114 * (219 / 255) * B) + 16;

Note that a scaling does take place, because an RGB value of 0,0,0 is converted to a luminance value of 16. Honestly I've never given much thought to that, because I was only concerned with the decoding part, not the encoding.

To recover the original RGB data, I use the same three coefficients, plus some inverted math inspired by the MSSG reference. I can only describe it in code:

crv = (255 / 224) * (1 - 0.299) * 2;
cbu = (255 / 224) * (1 - 0.114) * 2;
cgu = (255 / 224) * (0.114 / 0.587) * (1 - 0.114) * -2;
cgv = (255 / 224) * (0.299 / 0.587) * (1 - 0.299) * -2;

y2 = (Y * (255 / 219)) - 16;

R = y2 + crv * (Cr - 128);
G = y2 + cgu * (Cb - 128) + cgv * (Cr - 128);
B = y2 + cbu * (Cb - 128);

[Wilbert]

I downloaded your mix.zip, and the first thing that caught my attention was the fact that QuEnc uses matrix_coefficients = 4 in the "sequence display extension" for mix2.mpg. This value specifies the FCC's coefficients for red, green, and blue (0.3, 0.59, 0.11), rather than ITU's default MPEG-2 coefficients (0.2125, 0.7154, 0.0721), or the more common MPEG-1 coefficients (0.299, 0.587, 0.114).

It's important to note that the "sequence display extension" and "matrix coefficients" fields are optional. But if they are present, my MPEG-2 decoder will use them to convert to RGB. It is the responsibility of the encoder to specify the correct coefficients the decoder should use. And I guarantee that VirtualDub-MPEG2 presents the RGB image correctly, based on those coefficients.

(By corollary, "matrix coefficients" has no meaning if the decoder is not converting to RGB.)

Naturally there will be a discrepancy if Avisynth's "ConvertToYV12" command is not using the same coefficients that QuEnc has specified for the stream, and I think that's what you are seeing.

What a mess

I think that AviSynth is using the same coefficients. Ie, (0.299, 0.587, 0.114) for luma.

-----
Let's calculate it, to see where it goes wrong.

Take a look at mixUVc.m2v (in mix.zip). Presumable it has the same matrix coefficients. How can I check that myself?

mixUVc.m2v is created (with QuEnc) with an avs script: R=B=0, G=256. Converted to YV12 in AviSynth, resulting in Y=145, U=54, V=34 (can be checked with coloryuv(analyze=true)). The (0.299, 0.587, 0.114) coefficients result in the same YUV values (ie Y=145, U=54, V=34). Ie

Y = (0.299 * (219 / 255) * 0) + (0.587 * (219 / 255) * 256) + (0.114 * (219 / 255) * 0) + 16 = 145 (same for U and V)

Now, the decoder side:

1) If I open the mixUVc.m2v is AviSynth and take a look at the YUV values, they are precisely Y=145, U=54, V=34. As it should. Converting to RGB (in avs itself), gives R=B=0, G=256, as it should.

2) What about VirtualDubMod?

y2 = (145 * (255 / 219)) - 16 = 152.8356

I will assume this is a typo, because it should be

y2 = (145 - 16)*(255 / 219) = 150.2054795

crv = 1.5960
cbu = 2.0172
cgu = -.3918
cgv = -.8130

R = y2 + crv * (V - 128) = .1789616 -> 0
G = y2 + cgu * (U - 128) + cgv * (V - 128) = 255.6148478 -> 256
B = y2 + cbu * (U - 128) = .9303010 -> 1

But this is not what I see if I open mixUVc.m2v in VDubMod. If I take a snapshot in VDudMod, open it in Color photo paint it gives

R0 G216 B0

Could you please check the YUV->RGB conversion in VDubMod?

edit: I did the same avs script with TMPGEnc:

BlankClip(pixel_type="YV12", width=720, height=576, color=$00ff00)

result:

http://www.geocities.com/wilbertdijkhof/mixUVc_tmpg.mpg

YUV values are Y=145, U=54, V=34. What are the matrix coefficients of this one? Cause, if I open it in VDubMod it does look like the original.

[fccHandler]

I got your new .zip, and I'll address everything you've said approx. 9 hours from now. Right now I have to get to my real job (drat)...

[fccHandler]

Originally posted by Wilbert
What a mess

It gets worse.

I think that AviSynth is using the same coefficients. Ie, (0.299, 0.587, 0.114) for luma.

You're probably right. Those coefficients are a de facto standard dating back to the 1950's. They are correct for MPEG-1 video, but not necessarily correct for MPEG-2.

Take a look at mixUVc.m2v (in mix.zip). Presumable it has the same matrix coefficients.

For whatever reason, mixUVc.m2v doesn't contain a "sequence display extension" (like mix2.mpg had). In the absence of this extension, the specs say we are supposed to use the default MPEG-2 coefficients (0.2125, 0.7154, 0.0721).

How can I check that myself?

I check it using some old programs I wrote to analyze MPEG files. They are very primitive, and I wouldn't want to release them in public. If you're really desperate, PM me.

mixUVc.m2v is created (with QuEnc) with an avs script: R=B=0, G=256. Converted to YV12 in AviSynth, resulting in Y=145, U=54, V=34 (can be checked with coloryuv(analyze=true)). The (0.299, 0.587, 0.114) coefficients result in the same YUV values (ie Y=145, U=54, V=34). Ie

Y = (0.299 * (219 / 255) * 0) + (0.587 * (219 / 255) * 256) + (0.114 * (219 / 255) * 0) + 16 = 145 (same for U and V)

Now, the decoder side:

1) If I open the mixUVc.m2v is AviSynth and take a look at the YUV values, they are precisely Y=145, U=54, V=34. As it should. Converting to RGB (in avs itself), gives R=B=0, G=256, as it should.

Not exactly. This procedure ignores the MPEG-2 "matrix coefficients" field (or lack thereof), because DVD2AVI is feeding YV12 to Avisynth, and Avisynth is converting to RGB blindly using the (0.299, 0.587, 0.114) coefficients, which are incorrect for this particular stream.

2) What about VirtualDubMod?

y2 = (145 * (255 / 219)) - 16 = 152.8356

I will assume this is a typo, because it should be

y2 = (145 - 16)*(255 / 219) = 150.2054795

Oops, you're right. (Y - 16) should be the first operation.

crv = 1.5960
cbu = 2.0172
cgu = -.3918
cgv = -.8130

R = y2 + crv * (V - 128) = .1789616 -> 0
G = y2 + cgu * (U - 128) + cgv * (V - 128) = 255.6148478 -> 256
B = y2 + cbu * (U - 128) = .9303010 -> 1

But this is not what I see if I open mixUVc.m2v in VDubMod. If I take a snapshot in VDudMod, open it in Color photo paint it gives

R0 G216 B0

That is the correct result if you use the default MPEG-2 coefficients (which you must, since the mixUVc.m2v stream doesn't specify its own):

crv = (255 / 224) * (1 - 0.2125) * 2 = 1.7929687
cbu = (255 / 224) * (1 - 0.0721) * 2 = 2.1126294
cgu = (255 / 224) * (0.0721 / 0.7154) * (1 - 0.0721) * -2 = -0.2129164
cgv = (255 / 224) * (0.2125 / 0.7154) * (1 - 0.2125) * -2 = -0.5325772

y2 = (145 - 16) * (255 / 219) = 150.20548

R = y2 + crv * (34 - 128) = 0
G = y2 + cgu * (54 - 128) + cgv * (34 - 128) = 216
B = y2 + cbu * (54 - 128) = 0

mixUVc_tmpg.mpg

In that one, matrix coefficients = 4 (the FCC standard). But this is so close to (0.299, 0.587, 0.114) that you probably won't see a difference with your eyes.

[Wilbert]

Let me guess: The following mpeg2 stream comes (=demuxed) from a dvd (from hell). I bet it uses the mpeg2 coefficients

http://www.geocities.com/wilbertdijkhof/fh.m2v

So, summarized the problem is as follows (if the above is indeed true):

1) VirtualDubMod (and probably the majority of the software dvd players) does it right, because it uses the mpeg2 coefficients for playback.

2) dvd2avi, AviSynth, DivX/XviD/TMPGEnc (CCE?) does it "wrong", because:

a) dvd2avi/AviSynth doesn't correct for this, doesn't pass the mpeg2 coefficients through.

b) DivX/XviD resp. TMPGEnc (CCE?) uses the mpeg1 coefficients resp. FCC coefficients. So, the mpeg2/mpeg4 decoders uses the wrong coefficients.

TMPGEnc has a "video format" setting, but I'm not exactly sure what it does...

You mean under the video tab (where you can choose pal/ntsc)?

How do you suggest the dvd2avi/AviSynth should solve this?

Make an AviSynth plugin to correct for this, or (I think a better solution is to) bug the DivX/XviD/"programs which let you change the mpeg2 header info" folks to add a setting for choosing the right coefficients?

[sh0dan]

Interesting. I've googled around a bit and haven't so far found anything to use as reference for this. Do you have any links?

There are a bunch of possible solutions - even though I don't much like either of them. Either way - does DVD2AVI write the value into the D2V-file?

My initial idea is a separate filter for conversion filter reading a default "in" color-coefficients from a variable that mpeg2dec3 could set on initialization, and default output to 601 coefficients.

Could you list all known coefficients?

[fccHandler]

Originally posted by Wilbert
Let me guess: The following mpeg2 stream comes (=demuxed) from a dvd (from hell). I bet it uses the mpeg2 coefficients

http://www.geocities.com/wilbertdijkhof/fh.m2v

It lacks a "sequence display extension," so the default MPEG-2 coefficients are used (just like mixUVc.m2v).

1) VirtualDubMod (and probably the majority of the software dvd players) does it right, because it uses the mpeg2 coefficients for playback.

I doubt the majority does it right, if they are based on DirectShow filter graphs. I suspect the decoder filter presents its output data as YUV, passing it downstream to a video display or overlay filter, which (like Avisynth) blindly converts to RGB with no knowledge of the stream's preferred coefficients.

How do you suggest the dvd2avi/AviSynth should solve this?

Let DVD2AVI pass the stream's coefficients to Avisynth, and/or, let ConvertToRGB() accept coefficient parameters, e.g., "ConvertToRGB(0.299, 0.587, 0.114)".

[fccHandler]

Originally posted by sh0dan
Interesting. I've googled around a bit and haven't so far found anything to use as reference for this. Do you have any links?

Could you list all known coefficients?

My reference is ISO/IEC 13818-2 (the MPEG-2 video spec). Both wotsit and neuron2 have copies of it, but for some reason the formatting looks ugly on my PC. I think two better copies can be found here:

http://www.ece.cmu.edu/~ece796/docum...2_Video_IS.doc
http://le-hacker.org/hacks/mpeg-drafts/is138182.pdf

Section 6.3.6 describes "sequence display extension," and Table 6-9 of that section lists the matrix coefficients.

[Wilbert]

My initial idea is a separate filter for conversion filter reading a default "in" color-coefficients from a variable that mpeg2dec3 could set on initialization, and default output to 601 coefficients.

I think this is the best solution. I suggest to start with a filter which does:

default: mpeg2 coefficients -> default: mpeg1 coefficients.

If Graft gets back we can ask him to modify his DVD2AVI (called DGIndex) and mpeg2dec3 (called DGDecode). Might take a while though, before he gets back