ColorMatrix v2.3

[Wilbert]

I must admit I don't understand this entirely. Previewing with VDub didn't give me any artefacts typical for 4:2:0 colour compression, because it defaults in options to RGB24. I assume DGIndex does very similar or even exactly the same thing, so no colour bleeding nor stair-stepping.

Yet while decoding MPEG-2 (most of them are YV12 for compression's sake) or MPEG-4 ASP (Divx, XviD) I always get the mentioned artefacts, no matter what player and decoder I use. How could it be a clip is converted to RGB upon display and keeps artefacts typical for chroma sub-sampling (as in JPEGs)? The only thing I can do then is to use ffdshow and force either YUY2 output colour space or the already mentioned HQ YV12=>RGB conversion, again as output colour space. Only then the artefacts disappear (I made dozens of screen-shots once).
It all depends on how the YV12 is upsampled (when converting to RGB) upon display. In many cases the missing chroma is just doubled (ie the same as what pointresize or nearest neighbour resizing does), resulting in stair-stepping. In some cases (AviSynth, VirtualDub, HQ conversion in ffdshow, huffyuv, some others ...), the missing chroma is interpolated instead of being doubled.

[canuckerfan]

other than dgindex, what other method is there for determining a streams colorimetry?

[HeadBangeR77]

It all depends on how the YV12 is upsampled (when converting to RGB) upon display. In many cases the missing chroma is just doubled (ie the same as what pointresize or nearest neighbour resizing does), resulting in stair-stepping. In some cases (AviSynth, VirtualDub, HQ conversion in ffdshow, huffyuv, some others ...), the missing chroma is interpolated instead of being doubled.
:thanks:

Now it's clear. :)

[Wilbert]

other than dgindex, what other method is there for determining a streams colorimetry?
GSpot (as mentioned in the documentation). I'm not aware of any other utilities which show the colorimetry.

[KillerZero]

Decoder doesn't assume anything. MPEG4 decoder just decodes MPEG4 to YV12. Conversion to RGB is done by graphic card, not by decoder. (except you force RGB24 output, if decoder supports it) So it is up to your graphic card and driver to select proper colorimetry. Decoder doesn't have anything to do with it. And at least Ati cards select correct colorimetry according to resolution. (Rec601 for SD, Rec709 for HD) I don't have nvidia card, so I can't test it but I think it will do it corectly too.

You are doing wrong when you are comparing screenshots from MPC, because MPC does conversion by itself when grabbing screenshots and does it wrong. You have to compare just paused video, not captured screens.

BTW X264 has these settings, but I've never tested it and I'm not sure what exactly they will do. I think that it is better to leave it "undef":
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo

[HeadBangeR77]

You are doing wrong when you are comparing screenshots from MPC, because MPC does conversion by itself when grabbing screenshots and does it wrong. You have to compare just paused video, not captured screens.
I can reassure you they look the same - I've done thousands of them in my life and never marked any difference between the paused video screen and a screen grab. Recently I've also compared MPC's, Nero ShowTime's and PowerDVD's still frames, and guess what, they all looked the same, no matter what application/decoder was used. It applies at least to MPEG-2, MPEG-4 ASP and x264 encodes.

BTW X264 has these settings, but I've never tested it and I'm not sure what exactly they will do. I think that it is better to leave it "undef"...
Now this might be really interesting ... Why not to make a short samples with those parameters? ;)

cheers,
HDBR77

[HanSolo00]

I've just found some 'interesting' behaviour with a simple test on 4 different MPEG-2 clips. The problem with DGindex+ColorMatrix hints only seems to occur for me with HD MPEG-2; in all the other cases, the hints passed do as I expect with ColorMatrix. It does a Rec.709->Rec.601 on a Rec.709 Interlaced NTSC clip, but does not on a Rec.709 Progressive Film clip. On a SMPTE 170M Progressive Film clip, it also changes nothing. In those 3 cases, the DGindex shown frames match the output avs played back in MPC, with ColorMatrix(hints=true).

Where it does not match, is when you open a Rec.709 NTSC Interlaced Transport Stream. When you playback the TS in DGindex, and compare the frame colors to MPC playing back the same source frames, the colors match--but when you allow ColorMatrix to use DGindex hints, the colors are changed in the output. IMHO, this is improper--the HD Transport Stream, even though it is NTSC Video Type, should be left alone because HD is supposed to be Rec.709. When I let ColorMatrix change the colors to Rec.601, all the reds turn unnaturally orange, and this is what is happening when DGindex passes the hints as 'Rec.709' and 'NTSC Video Type'. So, the problem appears to be DGindex reporting hints to ColorMatrix that tells it to change the color on the Transport Streams, when it shouldn't.

In a nutshell: DGindex internally is leaving a HD Transport Stream alone, as Rec.709, as you can see when you play it in DGindex (which is correct.) But as soon as you pass hints 'NTSC' video type to ColorMatrix, it goes and does a Rec.709->Rec.601 because it isn't differentiating between SDTV NTSC video and HDTV NTSC video. This must be wrong, because if you open a SDTV NTSC clip into DGindex and play it, it internally changes the color to Rec.601.

I can't post more details or samples just yet as I must get some sleep--full work day tomorrow.

[KillerZero]

I can reassure you they look the same - I've done thousands of them in my life and never marked any difference between the paused video screen and a screen grab.

Yes, they look same for SD video, but for high resolution they are wrong. Try it. Make one clip resampled to 640x360 and one resampled to 1280x720. Do one screenshot in vdubmod from avisynth script with ConvertToRGB24() and one with ConvertToRGB24("Rec709"). Then compare them. You will see that SD clip will look as first screenshot and HD clip as second screenshot, but when you capture screens from MPC, they will look both as first one.
You must not have set ffdshow to output RGB of course, you must have set it to output directly YV12. And I have set output to system default in MPC, but I don't think that VMR will change anything about that.

[HeadBangeR77]

Yes, they look same for SD video, but for high resolution they are wrong. Try it. Make one clip resampled to 640x360 and one resampled to 1280x720. Do one screenshot in vdubmod from avisynth script with ConvertToRGB24() and one with ConvertToRGB24("Rec709").
Now, it's much clearer and more precise. Btw. VDub (if VDubMod, I have no idea) converts to RGB24 by default (check video => colour depth). So only in case of Rec.709 the additional conversion is needed, imo. I've never encoded anything with horizontal resolution higher than 1024, so I haven't marked what you've found out.

Then compare them. You will see that SD clip will look as first screenshot and HD clip as second screenshot, but when you capture screens from MPC, they will look both as first one.
You must not have set ffdshow to output RGB of course, you must have set it to output directly YV12. And I have set output to system default in MPC, but I don't think that VMR will change anything about that.
VMR can only add the TV-scale bug, if one is unlucky. I get it, gonna try with some QT trailers I've got. Could it be in any way related to the problem that HanSolo00 is having atm?

cheers,
HDBR77

[KillerZero]

Now, it's much clearer and more precise. Btw. VDub (if VDubMod, I have no idea) converts to RGB24 by default (check video => colour depth). So only in case of Rec.709 the additional conversion is needed, imo. I've never encoded anything with horizontal resolution higher than 1024, so I haven't marked what you've found out.

When you use fast recompress, vdub(mod) passes YV12 directly to encoder. I hope that noone is so stupid to use full processing when encoding to xvid! I hope you didn't misunderstand me, that conversion to RGB in avisynth is good only if you make screenshots, you should leave it in YV12 for reencoding!


Could it be in any way related to the problem that HanSolo00 is having atm?

I think that only problem HanSolo have is confusion caused by DGindex's TV/PC scale settings and this filter... For HD only Rec709 is used and everything expect Rec709 when playing HD video, so Colormatrix shouldn't be used. If you use it, colormatrix changes it to 601, but when playing it is handled as 709. So it is like if you would use colormatrix twice, and it of course causes orange faces.

[HeadBangeR77]

When you use fast recompress, vdub(mod) passes YV12 directly to encoder. I hope that noone is so stupid to use full processing when encoding to xvid!
I've always been using fast recompress, was it Nandub ages ago, was it VDubMod or is it the latest VDub. Yet the application defaults to full processing mode when you open it, so I use it for previewing & taking screenshots (if necessary, e.g when asked by Wilbert, normally AVSP would suffice).

[Guest]

I think that only problem HanSolo have is confusion caused by DGindex's TV/PC scale settings and this filter... I suspect that is the case as well.

[HanSolo00]

I suspect that is the case as well.The problem I'm seeing is not Luma related, it's the fact that DGindex passes hints to ColorMatrix telling it to Rec.709->Rec.601 on HD MPEG-2 NTSC Transport Stream. Of course it is easy to simply exclude ColorMatrix from HD encoding altogether, but that sort of defeats the whole purpose as I understand it of passing color hints and determining any color adjustment for the user automatically.

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)

For HD only Rec709 is used and everything expect Rec709 when playing HD video, so Colormatrix shouldn't be used. If you use it, colormatrix changes it to 601, but when playing it is handled as 709. So it is like if you would use colormatrix twice, and it of course causes orange faces.
This is proving out what I just posted above. ColorMatrix should not change HD source color from Rec.709. So then, why can't DGindex pass hints telling it to not change anything? It would make things a lot more simple and less confusing for the end user. And after all, I thought the whole point of passing hints in the first place was to allow DGindex+ColorMatrix to always get the color right irregardless of what the scripter needs to know.

[Guest]

The problem I'm seeing is not Luma related, it's the fact that DGindex passes hints to ColorMatrix telling it to Rec.709->Rec.601 on HD MPEG-2 NTSC Transport Stream. DGIndex does not pass hints to anyone or anything. I will guess that you are meaning to say "DGDecode passes hints." Precision is important.

Second, DGDecode does not "tell" ColorMatrix to do anything. It simply reports the colorimetry detected in the stream. That may sound like a fine point to you, but it determines where a fix for your claimed bug should be located.

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.) DGDecode does not treat SD and HD differently, as there is nothing in the MPEG2 specification that requires it to do so. Any observed difference will be due to different stream specification of the colorimetry.

Furthermore, there is no hint specifying "NTSC video" as you alluded to in an earlier post. It simply does not exist. You wrote:

"this is what is happening when DGindex passes the hints as 'Rec.709' and 'NTSC Video Type'"

There is a hint that reports the progressive_frame flag, but I don't know if ColorMatrix uses it.

This is proving out what I just posted above. ColorMatrix should not change HD source color from Rec.709. So then, why can't DGindex pass hints telling it to not change anything? DGDecode reports the detected stream colorimetry via hints. That is all. If there is a problem, you need to focus on the downstream filter. If you can demonstrate that DGDecode is not correctly reporting the colorimetry, then you will have my attention.

[KillerZero]

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)

You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix. Hints tell colormatrix only what colorspace is source, not to what colorspace it should convert. Colormatrix changes colors to 601, so it is obvoius that it will seem wrong when it will be played with rec709 matrix. Good solution would be to change Colormatrix to default to rec709 when resolution is HD. But best would be to not use Colormatrix for HD at all, as you won't find HD in any other colorspace than Rec709, so it is never needed to convert it in any way.

[HanSolo00]

You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix.No, I understand that just fine.
Good solution would be to change Colormatrix to default to rec709 when resolution is HD.This is the solution that makes the most sense to me since a lot of encoders simply trust that ColorMatrix(hints=true) will produce the right result with all MPEG-2 sources.

[Guest]

Good solution would be to change Colormatrix to default to rec709 when resolution is HD. That is not a good solution, because it doesn't follow the MPEG2 spec. HD means nothing; you can have interlaced HD: 1080i.

If ColorMatrix is keying off the progressive hint, I'd like to know why. Wilbert should explain whether it uses it and why.

I do know that it is not uncommon for streams to set the progressive_frame flag incorrectly.

[Guest]

I just looked at the source code of ColorMatrix and it does not use the progressive hint. If you can point me to your stream that has a "problem" I will look at it and tell you exactly why the 709->601 conversion is being triggered (if in fact it is being triggered).

So, the ball is in your court to provide a sample stream.

[KillerZero]

That is not a good solution, because it doesn't follow the MPEG2 spec. HD means nothing; you can have interlaced HD: 1080i.

What are you talking about? Yes you can have intelaced HD, but what it have to do with fact that HD always use Rec709 colors and when you play anything with HD resolution (even in PC) it will be played back with Rec709 matrix? Colorimetry and interlacing are two completly separate things.

[Guest]

There is nothing in the MPEG2 spec that says an HD stream must use 709. That is my point. The reference to interlacing was due to Han's claims.

The conversion is being triggered simply because the stream reports 709 and ColorMatrix by default does 709->601 conversion.

If in practice HD streams always use 709, then I suppose it might make sense to change the default mode of ColorMatrix. I don't care about that. I see a potential for just a different form of user confusion, though.

I got involved only because people started saying DGMPGDec is doing something wrong and needs a fix.

Carry on, I'm outta here.

[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]

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)

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]

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]

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]

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]

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.

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.

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.

[Leak]

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.
I guess she meant that whole "TV levels" vs. "PC levels" brouhaha...

[KillerZero]

What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
AFAIK, PC levels are used only in JPEGs.

[Leak]

What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
IIRC Overlay Mixer uses one and VMR7/9 uses the other, thus making both look different...

np: The Remote Viewer - Take Your Lights With You (Let Your Heart Draw A Line)

[KillerZero]

VMR7 also uses correct values, only VMR9 uses wrong colors.
edit: and VMR7 renderless is also wrong, so only overlay and VMR7 windowed is correct. But why?
Edit2: really strange, it seems that VMR9 selcts color mode randomly...
Edit3: I got it, VMR7 renderless and both VMR9 modes render colors correctly only with resolution < 720 lines. For 720p or higher, they really expect PC scale. Maybe bug in drivers? I'll try upgrade to newest catalyst.

[KillerZero]

It should be possible to set color matrix:

http://msdn2.microsoft.com/en-us/library/ms796493.aspx

[Alain2]

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.
I am not sure of that.. I always use avisynth for encoding, and I really doubt that avisynth is keeping a colorimetry flag throughout the filters process, therefore to me the colorimetry flag is reset by the encoder used. That's why I said earlier that xvid/x264 were rec601 and CCE rec709, and that the source had to be dealt with accordingly... maybe avisynth devs can confirm / disapprove what I just said ?

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.
What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
AFAIK, PC levels are used only in JPEGs.
Like Foxyshadis, I personnally disabled yv12 output in ffdshow and only enabled rgb32, with the yv12>rgb hq conversion option enabled. This is to get the full PC scale as I do want 0-255 on my lcd screen. Usual DVD software players / AvsP preview / vdub scale 16-235 over 0-255 (histogram("levels") indicate values in 16-235, whereas it is clearly displayed in 0-255 as black is true black), so I think it is what most people want on their computer... Only ffdshow yv12 output keep the output level to 16-235

[KillerZero]

For me, YV12 also results in 16 as black. There is no visible difference between RGB32 with HQ RGB conversion and YV12. What is your graphic card?
You definitely not using avisynth for encoding, only for decoding. And it is nothing contradicting to what I said - only what encoder can do is write colorimetry info to stream and all what decoder can do is to give colorimetry info to next filter if it's present in stream, but in encoding/decoding process itself is no slightest difference. It's only relevant for YV12<-->RGB conversion, so if we want it to be played properly ffdshow must be able to pass colorimetry info to graphic card. If not, default value is used, which is Rec601 for all resolutions below 720p.
I'm not sure if you understand - if you have raw YV12 data there is no way how to tell which colorimetry is it. If you have no colorimetry info in stream, all you can do is just guess what looks more correct to you.
Another question is if xvid writes colorimetry info to stream. Probably not, but at least MPEG2 playback could be correct.
X264 has option to set colorimetry info. use X264.exe --longhelp

[foxyshadis]

As I've said many times, it pretty much randomly changes based on your drivers. For a few driver versions it'll be "TV" levels, then it'll slide back to "PC" levels, fullrange conversion, sometimes only for some streams and not others. At least nvidia opened up a registry option that can be used to change the output levels, after being pestered, because some people actually use and prefer PC-levels, although I understand this stopped working or became unreliable last year. (I gave it up some time back.)

I'm surprised that anything changes for you when the size of the output reaches 720p. In my case, it's the same, with pretty recent cat, but an x1400 mobility. On the other hand I usually can't tell the difference between 601 and 709, so maybe it's just slipping by me.

I've been putting up with it for two years, once I figured out what caused it, filing occasional support requests, and the flip-flopping in the drivers and the steady stream of posts by other people with the same problem have just grated on me. So I'm a little more annoyed at them than I should be. That's the reason I suspect that instead of honoring any colorometry flag, they will just use one and ignore the stream. As in your case, they pick one flag for SD and one flag for HD - that's simply wrong, hardly any better than forcing one all the time.

[G_M_C]

Regarding the YUv PC/TV-scale; I've got a H264 clip wich comes out PC scale after opening throught AVCSource().

Currently I'm using a AVS-script like this:

AVCSource("bond.dga", deblocking=false).ConvertToYUY2()
Trim(xxxxx,xxxxx)
AssumeFPS(25,1,false)
Spline16Resize(720,426)
FFT3DGPU(...{bunch of options}...)
AddBorders(0,74,0,76)


Would you guys do the ...
1) ColorYUV("PC->TV") just before the ConvertToYUY2()
2) ColorYUV("PC->TV") just before the FFT3DGPU ?
3) Doesnt matter sh*t, there wont be a difference ;)

What would you guys do ?

PS: (G_M_C is trying hard to circumvent the "what's best" question ;) )

[KillerZero]

1)How do you know it is PCscale? use script with just AVCSource and ColorYUV(analyze=true) and check loose min luma.
2) why are you converting it to YUY2? why don't you leave it in YV12?
3) Why fft3D? Denoising?
4) where can I get AVCsource plugin? Is it faster than DirectShowSource?
5) I don't know AVCSource and I cant google any relevant page, but if deblocking=false disables deblocking even if clip uses in-loop deblocking, this can lead to catastrophic results.

I think there won't be any significant difference, but maybe would be better put it after FFT3D, so it will work with more colors.