Pixelated Video in VMR 7/9

[Kado]

I only noticed this after reading Japhsoncross post (http://forum.doom9.org/showthread.php?p=1185187#post1185187) about the ATI/nVidia situation but I was using YUV instead of YV12. If I use YUV I get blocks that the shader can fix but with YV12 I get none of that maybe because I have a Geforce 9800GTX?

@pitch.fr
AS for the BT.601/709 range I was using BT.709 on SD material (maybe that's the problem) and luma range was "Standard" (16-235) on ffdshow and "Full" (0-255) on the nVidia control panel to remove the washed out image with EVR Custom Presenter.

[DigitalDeviant]

I wouldn't recommend using it on non-YV12 video (since YUY2 would need a shader that only does horizontal interpolation, and RGB doesn't need any at all), but for YV12 it shouldn't have any downsides.

Well, my problem is I have a HD3650 and I'm getting bad chroma upsampling even using the NV12 colorspace in certain situations using EVR (both custom and regular). Can I use the shader for this?

[pitch.fr]

I was using BT.709 on SD material (maybe that's the problem)
despite what some obscure MPEG2 specs say, SD=601 / HD=709.

at least there's no fuss & fighting on this.

Well, my problem is I have a HD3650 and I'm getting bad chroma upsampling even using the NV12 colorspace in certain situations using EVR (both custom and regular). Can I use the shader for this?
I'm surprised they can get progressive chroma on nvidia.
ATi can only do interlaced.

[DigitalDeviant]

I'm surprised they can get progressive chroma on nvidia.
ATi can only do interlaced.

I don't quite understandyou here. Do you mean that I should really only be getting correct upsampling on interlaced video? Come to think of it, I might only have been noticing it on progressive material.

Since nVidia doesn't have this problem, have they fixed they're lack of VC-1 acceleration? Might be clue to swap cards.

[pitch.fr]

this is with 720p, EVR and an ATI HD card :
http://forum.doom9.org/showpost.php?p=1183500&postcount=10

you can't get progressive chroma upsampling AFAIK...or maybe the media player needs to tells the drivers it's progressive ?

MPC HC and KMPlayer fail at progressive chroma on the ATi...

[Leak]

Well, my problem is I have a HD3650 and I'm getting bad chroma upsampling even using the NV12 colorspace in certain situations using EVR (both custom and regular). Can I use the shader for this?
Ummm... why don't you just try it? It's not as if you can't just toggle it on/off or as if it left permanent damage in your video...

[DigitalDeviant]

@pitch.fr
Interesting. I usually convert most of my video to RGB in ffdshow but had been trying out the NV12 colorspace since I use it for HW deinterlacing and wondered if I couldn't just use it for everything. From my experimenting, it illustrated bad upsampling on all EVR custom settings but on regular EVR it only showed up when the video was upsized beforehand with ffdshow. VMR9 Renderless seemed OK all around but I haven't really put it through the ringer since I won't really be using it.

Now I need an interlaced sample to test. If it is only progressive video affected then I suppose that it doesn't matter since I only use NV12 for interlaced video (unless, the thought occures, that DVXA decoders output NV12).

And I suppose if auto BT.601/709 selection is based on resolution then resizing it with ffdshow before hand will throw that off but I'll figure that one out when I get to it.

@Leak
Tried it and tentatively it looks OK but I never trust my own eyes. So far it looks like you've done a great job.

[Japhsoncross]

US/ASIAN are SMPTE-C, european are EBU....just like DVD.

it's due to the Sony CRT monitors being used in mastering houses.

the ISF makes lists for their users so they know which gamut to switch to.

it's all been discussed in here, and tritical made an Avisynth plugin that I use to get proper gamut conversion in ffdshow :
http://forum.doom9.org/showthread.php?t=139389

there's also a PS script, that Haali told me he would add to his renderer later this month :
http://www.avsforum.com/avs-vb/showthread.php?t=912720

Oh, my... I missed that great post:)
I used to work for some of the SONY professional monitors design, mainly color space conversion designing.
I missed the stage of mastering. Hmm... then it will be easy to recover everything theoretically. I'll try to get a Minlota CA-210 to measure my monitor first to make sure they are still stable now.
Thanks for the information:P

BTW:
10-bit is not enough for linear processing, at least 11bits. Oh, a little bit off topic ;)
nice projector.

[pitch.fr]

BTW: 10-bit is not enough for linear processing, at least 11bits. Oh, a little bit off topic ;)
well I'm in contact with the french ISF CEO and several ppl involved in professional color management, here in France.

they said that DCI projectors work in 10 bit, and that this was more than enough ?!

Sanyo and other consumer brands like to boast about 12 bits, but this would be overkill from what they say ?

but anyhow both tritical's and PS plugins work in 32 float ;)

what I'm interested in, at this point, is knowning how to recognize at a glance whether there's a gamut hiccup.

basically for BT601/709, it's quite easy.

if ppl faces look greenish, you're converting 601 to 709
if reds look faded and colors washed out, you're converting 709 to 601

http://pix.nofrag.com/1/8/b/89ac689b298066012fefad1f061b6t.jpg (http://pix.nofrag.com/1/8/b/89ac689b298066012fefad1f061b6.html)

but a friend of mine recorded some HD episodes of Seinfeld on satellite, they've been reframed to 16/9 and obviously converted from SMPTE-C to HDTV.

if I play them in SMPTE-C, ppl faces look greenish to death.

so this is one : HDTV in SMPTE-C = greenish faces

also the Doomsday BD looks terrible in SMPTE-C, and a lot better in EBU.
considering it's a UK movie, that would make sense I guess...

[Japhsoncross]

the picture you posted is a typical case.
actually, there are a lot of things to consider.

SMPTE is a good pattern for me to show if the primaries are the same for two different sources.
but for a real life footage, serveral mistakes can be made in several stages.
SMPTE-C and Rec.709 primaries are very close to each other, if your monitor's primaries are not accurate enough, and you will miss the point.
if you can see big change, the problem might comes from other parts. but different people has different color sensitivity, we do better trust color meters. CA-210 is my good friend, though i can only use it in my office and lab:(
The most accurate way is trying to recover the exact XYZ, and remap them to the R'G'B' values according to your monitor primaries.

BTW: New Sony professional monitors can set primaries for different type of sources. Probably we won't have to do such brain killing things, finding everything possible wrong, in future:)

[Leak]

Okay, I'll drop the idea of discerning between BT.601 and BT.709...

If you give the following script a try in MPC...

ColorBars().Trim(0,-150).ConvertToYV12(matrix="PC.601").ConvertToRGB32(matrix="PC.601").Subtitle("601/601") + \
ColorBars().Trim(0,-150).ConvertToYV12(matrix="PC.709").ConvertToRGB32(matrix="PC.601").Subtitle("709/601") + \
ColorBars().Trim(0,-150).ConvertToYV12(matrix="PC.601").ConvertToRGB32(matrix="PC.709").Subtitle("601/709") + \
ColorBars().Trim(0,-150).ConvertToYV12(matrix="PC.709").ConvertToRGB32(matrix="PC.709").Subtitle("709/709")

...you'll notice that the colors of the bars for all conversion combinations stay exactly the same with my shader turned on or off since I'm using BT.601 conversion in both directions instead of only converting to YV12 and I'm doing no clipping either...

(I.e. the colors for each of the four 5-second segments will of course be different, but my shader doesn't alter them either...)

np: ESG - Insane (Tambourine Mix) (Soul Jazz Records Singles 2006-2007 (Disc 2))

[pitch.fr]

Samsung offers automatic 601/709 detection on their 800B projector.

god knows how they managed to do that :eek:

[Japhsoncross]

for one block with the same color, it will be fine, as you convert and revert back with matrix A and matrix A-1, and the shader does nothing. but for the edges, where the chroma channels are going to be traded between different pixels, then you will find the difference, as the shader always assumes the RGB pixels are BT601 and extract chroma channels in that manner. after getting a blurred result, the difference is shown.
you may try this avs script and check the center pixel to see the difference between shader only does by 601 and the one only does by 709.
blankclip(width=640, height=720, color=$7F0000).addborders(0, 0, 640, 0).converttoyv12(matrix="rec709")

[Japhsoncross]

Samsung offers automatic 601/709 detection on their 800B projector.

god knows how they managed to do that :eek:

would you please provide more detailed information?
if it detects 601/709 in HDMI source, I don't think there's anything difficult, as the colorimetry information is included.
is it able to detect in the YPbPr source if I use 601 conversion for an HD source, and transfer it by YPbPr to the projector?

[pitch.fr]

good point, it only works through HDMI.......they just confirmed it.

http://www.ultimateavmag.com/videoprojectors/908sama800/

The user can also choose one of three color standards: SMPTE-C, HD, or EBU.
I used SMPTE-C for most of my tests and viewing because, according to Kane, most post-production and mastering facilities still use monitors calibrated to this color gamut.

[totozero]

I wouldn't recommend using it on non-YV12 video (since YUY2 would need a shader that only does horizontal interpolation, and RGB doesn't need any at all), but for YV12 it shouldn't have any downsides.

As for the BT.601/.709 difference: even if you're using the wrong colorspace it should only have minimal impact since I'm only averaging values after conversion followed by converting back to RGB using the same (wrong) conversion afterwards.

But I'll add a height check to use BT.709 for HD material when I get home... (and then I'll locate whoever was responsible for that whole 601/709 brouhaha in the first place and will taunt him fiercely... :mad:)

Hello Leak,
been following this thread from the beginning and now I've added your shader in my setup i.e. MPC-HC/CUSTOM EVR/FFDSHOW input yv12/decoding -> output yv12 (B4 I used to output rgb32hq due 2 this chroma stuff)

Been making some comparisons and in the end yuy2+yer shader performed slightly better than rgb32hq.

What's bugging me is that you told us this shader was inaccurate while outputting yuy2.

If so, would you be kind enough to mod. your shader to fit correct yuy2 output ?

TIA.

[Leak]

If so, would you be kind enough to mod. your shader to fit correct yuy2 output ?
Well, it's so straightforward that a child could do it (Fetch me a child! None here? D'oh - do I have to do everything myself? :() but I'm at work, so this is untested:

/*
YUY2 chroma upsampling fixer
by Kurt Bernhard 'Leak' Pruenner

Use with YUY2 output if the half-resolution chroma
gets upsampled in hardware by doubling the values
instead of interpolating between them.

(i.e. if you're getting blocky red edges on dark
backgrounds...)
*/

sampler s0 : register(s0);
float4 p0 : register(c0);
float4 p1 : register(c1);

#define width (p0[0])
#define height (p0[1])

float4 getPixel(float2 tex, float dx)
{
tex.x+=dx;

return tex2D(s0, tex);
}

float4 rgb2yuv(float4 rgb)
{
float4x4 coeffs=
{
0.299, 0.587, 0.114, 0.000,
-0.147,-0.289, 0.436, 0.000,
0.615,-0.515,-0.100, 0.000,
0.000, 0.000, 0.000, 0.000
};

return mul(coeffs,rgb);
}

float4 yuv2rgb(float4 yuv)
{
float4x4 coeffs=
{
1.000, 0.000, 1.140, 0.000,
1.000,-0.395,-0.581, 0.000,
1.000, 2.032, 0.000, 0.000,
0.000, 0.000, 0.000, 0.000
};

return mul(coeffs,yuv);
}

float4 main(float2 tex : TEXCOORD0) : COLOR
{
float dx=1/width;

float4 yuv0=rgb2yuv(getPixel(tex,-dx));
float4 yuv1=rgb2yuv(getPixel(tex, 0));
float4 yuv2=rgb2yuv(getPixel(tex, dx));

float4 yuv=(yuv0*1+yuv1*2+yuv2*1)/4;

yuv.r=yuv1.r;

return yuv2rgb(yuv);
}

[totozero]

Many thanks leak.
Guess I'm not even skilled as a child.
I'll give it a try it and tell you if it makes a difference.

C'ya.

[STaRGaZeR]

That last update doesn't work right for me, only a part of the bloking is gone. The previous one was spot on.

[tetsuo55]

Do i understand this correctly?

There are basically 5 problems we are facing:
1.Blocking due to incorrect rgb<>others conversion.
2.Difficulty in accurately detecting BT type
3.Drivers converting between BT's regardless of the fact if its needed or not
4.Incorrect BT conversion due to incorrect primaries
5.Lack of chroma upsampling for progessive sources(Does this help image quality?)

[Leak]

That last update doesn't work right for me, only a part of the bloking is gone. The previous one was spot on.
That "last update" is a shader for YUY2, not YV12 - it'll only interpolate horizontally, as in YUY2 the chroma has the same height but only half the width of the luma.

Don't tell me I changed the comments at the beginning of the shader for nothing... :(

np: Matias Aguayo - Uno (Soul Jazz Records Singles 2006-2007 (Disc 1))

[STaRGaZeR]

That "last update" is a shader for YUY2, not YV12 - it'll only interpolate horizontally, as in YUY2 the chroma has the same height but only half the width of the luma.

Sorry, don't bite me :p I though it was an incremental update, with support for both YUY2 and YV12. But now thinking about it it's possible to see if the source is in one format or another and apply the shader accordingly?

[Leak]

Sorry, don't bite me :p I though it was an incremental update, with support for both YUY2 and YV12. But now thinking about it it's possible to see if the source is in one format or another and apply the shader accordingly?
Bite you? Nah, I already had breakfast today... :p

And no, it's not really possible to detect anything here since all the shader gets to see is the final RGB image, and at that point there's no information about the original colorspace left...

You could, however, just use the YV12 shader for both since it can't look worse than what it would look like if the video had been in YV12 in the first place...

[STaRGaZeR]

Yeah, I'll use the YV12 for everything.

How about my question here (http://forum.doom9.org/showpost.php?p=1186058&postcount=4303)? Let's use this thread only.

[arfster]

:) it detects the image height>= 720, then BT709, otherwise BT601.

Better to use horizontal res as Haali renderer does imo (say 1000), else you get bt601 used on bt709 widescreen 720p content encoded without bars - eg 1280 * 550ish

[JohnLai]

Why the YUY2 Chroma sampling fixer is not added into the mpc-hc as well?

[Leak]

Why the YUY2 Chroma sampling fixer is not added into the mpc-hc as well?
Probably because nobody has poked Casimir666 to do it...

Why don't you send him a PM with a link to my post? :)