ColorMatrix v2.3

[KillerZero]

Nothing in MPEG2, but in HD specs is Rec709 as only possible. Being it MPEG2, MPEG4, VC-1 or anything else, progressive or interlaced it must always use rec709.
That is what I'm talking about, it changes to Rec601, and this is the thing that causes wrong colors, because it is played as Rec709, like every HD video.

[Guest]

Originally Posted by KillerZero

Nothing in MPEG2, but in HD specs is Rec709 as only possible. Being it MPEG2, MPEG4, VC-1 or anything else, progressive or interlaced it must always use rec709.

There are still two systems in use for HDTV: 709 and SMPTE 240M. I agree that the latter is less common.

That is what I'm talking about, it changes to Rec601, and this is the thing that causes wrong colors, because it is played as Rec709, like every HD video.

Well, it changed it because you asked it to. That is what ColorMatrix does, it converts color spaces.

[KillerZero]

Sorry, don't know exactly what spec says it, but every HD device assumes Rec709.

Yes, that is why I'm telling hansolo that he shouldn't use it.

[Wilbert]

You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix.

I have some hd mpeg-2 examples which uses Rec.601, so your conclusion is false (it's not very common though).

[Alain2]

Sorry to interrupt, but I thought that the colorspace used for the avs output should match the codec expectancy, and not related to some "resolution" specs ? I thought for instance that xvid decoders were expecting rec601 by default whatever the resolution (cf background information in colormatrix doc), same for x(h)264 decoders (no specific resolution, I am not encoding to any particular standard resolution), and CCE was expecting rec709 by default, am I completely wrong ?

[KillerZero]

Yes, you are completly wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card. And it selects color matrix depending on resolution. (You can test that it depends on resolution by using resize&aspect in ffdshow. When you resample it to 1280x720 it starts using Rec720 matrix. I've just tried it. I'm not sure what exact resolution is minimal, but for 1280x720 it works)

Originally Posted by Wilbert

I have some hd mpeg-2 examples which uses Rec.601, so your conclusion is false (it's not very common though).

It is not false, you can have examples which are in Rec601, but they still will be probably played as rec709. On PC they will definitely be played as Rec709. BTW I wonder where did you get that examples?

[Wilbert]

Yes, you are completly wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card. And it selects color matrix depending on resolution.

You are bringing up some interesting points. I will come back to this and will change the docs accordingly ...

I'm a bit confused. Let's talk about mpeg-2 and playback for example. Are you claiming that this colorimetry info in a mpeg-2 is never used upon display? Or does it depend on the player?

I thought that not all graphic cards support YV12, who is doing the YV12->RGB conversion in that case?

[KillerZero]

If we are talking about playing MPEG2 with ffdshow then it is not used. I know it, because TV broadcast in Rec709 and it plays like Rec601 unless I use resize to 1280x960 in ffdshow. (I have Radeon 9600XT)

If YV12 is not supported by card (do you know any card which doesn't? I don't) ffdshow switches to supported colorspace closest to YV12.

[HeadBangeR77]

Originally Posted by KillerZero

Yes, you are completly wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card.

That is indeed interesting - I used to think what Alain2 did. Radeon 9800XT on board here + X700 mobile, so we've got at least the same family of graphic cards to test with.

And it selects color matrix depending on resolution. (You can test that it depends on resolution by using resize&aspect in ffdshow. When you resample it to 1280x720 it starts using Rec720 matrix. I've just tried it. I'm not sure what exact resolution is minimal, but for 1280x720 it works)

I've been trying to reproduce this using MPC + ffdshow resizing (rev. 1006, ICL9), yet it doesn't seem to affect my encodes (XviD): VRM7 windowed, YV12 /YUY2 in ffdshow as output colour-spaces (yet it shouldn't matter, since the graphic card converts it to RGB). I've resized to 1280x0 (auto) and 1400x0 (auto).
Different drivers? Or perhaps it affects certain codecs (although it shouldn't) only? Could you bring the matter to the ffdshow thread - think the guys there might be interested and will have more knowledge and experience than I do to reproduce and track the problem.

cheers,
HDBR77

PS. I've just linked the last few posts in the ffdshow try-outs thread.

[KillerZero]

Try to use system default as output. I haven't tested VMR modes. And you have to compare paused video, not screnhots of course, because conversion is done by MPC for screenshots. Also, I have unchecked "let the application control video adjustments" in Catalyst control center video settings. And it is not problem, it should behave like this, as Rec601 is default for SD video and Rec709 for HD. I don't know if decoder can send colorimetry info to driver. If not, ffdshow would have to convert it.

[HeadBangeR77]

Originally Posted by KillerZero

Try to use system default as output. I haven't tested VMR modes.

Well, if so, what OS are you running on? AFAIR VMR7 is system's default with WinXP.

And you have to compare paused video, not screnhots of course, because conversion is done by MPC for screenshots.

I remember - you don't have to remind me - that's what I did.

Also, I have unchecked "let the application control video adjustments" in Catalyst control center video settings. And it is not problem, it should behave like this, as Rec601 is default for SD video and Rec709 for HD.

Well, it could be a potential problem, since whole bunch of people is using ffdshow's filters for real-time playback, and this includes the resizing for a better presentation /visualization, especially for all possible kinds of SD sources.
For instance: if I made the previously discussed encode with ColorMatrix Rec.709=>Rec.601 conversion, and I would upsize it by playback on my notebook to 1280xauto, then it would be happily converted to Rec.709, and I would get hell of over-saturation, most probably.

Btw. What ffdshow revision are you using?

[KillerZero]

I tried it and same thing in VMR7 windowed. And I tested it some more and it depends only on lines, so it has to be at least ????x720. This is rather bad, as reencodes with cropped blask bars will play wrong unless you add them back with ffdshow. I thought one of them seems wrong...
I'm using version from 2nd september 2006, I can't find revision number. (I use this older version because newer buids can't use HW deinterlacing, only weave and bob is allowed. At least few months ago it couldn't.)

[HeadBangeR77]

Originally Posted by KillerZero

I tried it and same thing in VMR7 windowed. And I tested it some more and it depends only on lines, so it has to be at least ????x720 ...

That's what I was starting to suspect, since I was resizing a 16:9 widescreen (2.35/2.40:1) samples, so I never got to the lowest HD level in terms of vertical resolution.

I'm using version from 2nd september 2006, I can't find revision number. (I use this older version because newer buids can't use HW deinterlacing, only weave and bob is allowed. At least few months ago it couldn't.)

A new beta is just out at sourceforge.net. I've just uninstalled my "ancient" rev. 1006 from the 7th of March, so I'm gonna try to reproduce your issue using the official beta2.

[KillerZero]

I think it has nothing to do with ffdshow, I think that it depends only on graphic driver.

[Sharro]

Originally Posted by Wilbert

I have some hd mpeg-2 examples which uses Rec.601, so your conclusion is false (it's not very common though).

Not common, still my Star Wars Ep. I to III had all Rec.601 flag, which I believe it's a very "common" movie.

All the best,

Sharro

[Alain2]

@KillerZero
I don't understand.. Why bother putting colorimetry flags in the stream if nobody cares in the encoding or decoding process loop ? If it's resolution based only, do you know of a look-up table published somewhere to confirm this ? I find it hard to believe that it's standardized around the world

[KillerZero]

Sharro: where did you recorded it from?
Alain2: Decoder and decoder just takes raw data. Being it Rec601 or Rec709 encoding and decoding process is still the same. There is nothing to be changed and no reason to care which colorimetry it is. Colorimetry information is relevant only if you convert to RGB or back or if you do some color corrections. I don't know if it is possible to tell graphic card which colorimetry should be used?
What table? I don't know, it's just based on tests I've done. My card uses Rec601 for SD and Rec709 for HD.
It's possible that some HW players convert it, but I doubt it's widely used.
709 is standard for HDTV. It also requires slightly different RGB values, which probably all HDTV's use.

[Alain2]

Yes but the raw data are formatted to be decoded either rec601 or rec709 (or whatever) : your card renders differently at different resolution the same yv12 stream to the same rgb monitor, thus the raw data are supposed to be encoded taking into account the colorimetry convertion that will be applied when you watch it. So there is a reason to care about colorimetry I think, I am just not sure how now...

Also you refer only some specific standard SD / HD resolutions, but what about all the other non-standard resolutions ? I don't particularly pay attention to the resolution when I encode something, I choose whatever is the best compromise for resize aspect error/resolution/available bitrate as I don't plan to use hardware players..

[foxyshadis]

If you rely on your graphics card for colorometry, you might as well wish on a falling star. They can't even get luma levels right consistently, there's no way they'll ever make an effort to work with colorometry correctly. That's why I'm hoping ffdshow's hq rgb output will be able to take that into account someday. If you want the speed of YUV output you're just going to have to live with flaky rendering and making up-front corrections.

[KillerZero]

Alain2: I meant that there is no difference in encoding/decoding process. All can encoder do is to write given colorimetry info and decoder read it and give it to YV12/RGB convertor. That convertor is usually graphic card. Still noone answered my question if it is possible to tell card what colorimetry should be used.
It is dependent on number of lines, as long as it is 720 lines high or more, it uses Rec709.

Originally Posted by foxyshadis

They can't even get luma levels right consistently, there's no way they'll ever make an effort to work with colorometry correctly.

What do you mean by inconsistent luma? I really have no idea what should I imagine. And I think that current colorimetry behavior is quite correct.

Originally Posted by foxyshadis

If you want the speed of YUV output you're just going to have to live with flaky rendering and making up-front corrections.

Also, I don't understand what do you mean with that.
I don't know why should I use ffdshow's RGB conversion, if there is no difference from HW and it is much slower. +RGB output works correctly only to 960xsomething resolution. And as you say, ffdshow always use Rec601, so only way to play Rec709 is not using ffdshows RGB conversion.