Log in

View Full Version : RGB32 and YV12 produce very different output - which is "real"?


Pages : 1 [2]

leeperry
8th December 2008, 20:41
Do these settings only relate to the video processed by ffdshow codecs, i.e. using MPC-HC DXVA wont see these changes?
DXVA in MPC HC is not compatible w/ ffdshow in the first place.
Well I checked this sample and on my system everything looks very comparable, maybe you have mess on your system? Here you have my comparison:

Right I forgot you are the one who see things not visible on screenshots. BTW screenshots made by print screen are take from backbuffer which is sent to display, if something isn't there is not on display also.
oh right, Leak created a PS script to progressively upsample YV12/YUY2 chroma in MPC HC...maybe his system is messed up too ? :D

you got a non-HD ATI card, apparently these cards also don't suffer from the "ghost lines" in HR....these ancient cards are very valuable apparently, I would strongly advise you to keep it until the end of days.

rack04
8th December 2008, 20:50
DXVA in MPC HC is not compatible w/ ffdshow in the first place.

Care to explain? I'm using MPC-HC with internal h264 (DXVA) and ffdshow tryouts without any problems.

shaolin95
8th December 2008, 20:52
Excuse my silly question but when you select ConverToRGB32() in avisynth....what do you select then in ffdshow to prevent multiple conversions?

Leak
8th December 2008, 20:57
Care to explain? I'm using MPC-HC with internal h264 (DXVA) and ffdshow tryouts without any problems.
You can't use ffdshow to process the output of MPC HC's DXVA decoders. If anything, they'll skip using DXVA and fall back to software decoding that way - DXVA will only work if you connect the decoder directly to a renderer in the DirectShow graph.

np: Swod - Frost (Sekunden)

leeperry
8th December 2008, 20:57
Care to explain? I'm using MPC-HC with internal h264 (DXVA) and ffdshow tryouts without any problems.

http://tibrium.neuf.fr/DXVASupport.html

DXVA is quite picky [...]
The MPC-HC Video decoder must be connected directly to the renderer. That means no intermediate filters such as [...] ffdshow can be inserted between the decoder and the video renderer.
Excuse my silly question but when you select ConverToRGB32() in avisynth....what do you select then in ffdshow to prevent multiple conversions?
if you output RGB32 from Avisynth, check "RGB32" & "full range" in ffdshow and it will remain untouched ;)

rack04
8th December 2008, 21:04
http://tibrium.neuf.fr/DXVASupport.html

http://i11.photobucket.com/albums/a199/rack04/DXVA.jpg

With ffdshow tryouts-mt svn 2443 installed.

leeperry
8th December 2008, 21:11
...and you can add ffdshow post-processing on top of it ?

I wish that was possible to have the GPU decode h264, and add Avisynth scripts in ffdshow....but only CUDA could allow that...maybe in a future CoreAVC version :o

shaolin95
8th December 2008, 21:14
http://tibrium.neuf.fr/DXVASupport.html



if you output RGB32 from Avisynth, check "RGB32" & "full range" in ffdshow and it will remain untouched ;)
Pardon my ignorance but does that mean I can uncheck EVERY other option in ffdshow or just select RGB32 output as well (highquality?) and full range?

leeperry
8th December 2008, 21:18
uncheck all the output colorspaces except RGB32, and check "full range"...so ffdshow won't temper w/ the avisynth stream ;)

"hq yv12 conversion" don't matter, as there won't be any conversion

Blue_MiSfit
8th December 2008, 21:33
The only problem with ffdshow RGB conversion is that it's very slow. It shouldn't be a problem, but I've had issues with it when handing 1080p material. I prefer Haali renderer for this reason (hardware based), plus you can change the luma range and color matrix on the fly and compare the differences. You can't do that with ffdshow.

rack04
8th December 2008, 21:39
You can't use ffdshow to process the output of MPC HC's DXVA decoders. If anything, they'll skip using DXVA and fall back to software decoding that way - DXVA will only work if you connect the decoder directly to a renderer in the DirectShow graph.

np: Swod - Frost (Sekunden)

So changing the output colorspace, YCbCr specification, and contrast in ffdshow has no effect on the video output from the MPC-HC DXVA decoder?

leeperry
8th December 2008, 21:41
The only problem with ffdshow RGB conversion is that it's very slow. It shouldn't be a problem, but I've had issues with it when handing 1080p material. I prefer Haali renderer for this reason (hardware based), plus you can change the luma range and color matrix on the fly and compare the differences. You can't do that with ffdshow.
good point, but HR's 601/709 coeffs are not green enough :
http://forum.doom9.org/showthread.php?p=1133980&highlight=YUY2#post1133980

doesn't matter if your display is not calibrated, though ;)

Blue_MiSfit
8th December 2008, 21:49
@leeperry:

Interesting! I had no idea.

Still, I consider that to be a minor issue - which will hopefully get fixed eventually :)

~MiSfit

leeperry
8th December 2008, 21:54
Interesting! I had no idea.

Still, I consider that to be a minor issue - which will hopefully get fixed eventually :)
well I've spoken to Haali quite a lot lately, he used to have a lot of free time when he was working on HR....but this is now history.

don't count on a fix anytime soon(same goes for the ghost lines on ati/nvdia cards when using the built-in bicubic scaler..)

oh sure if your display is not carefully D65/2.2 calibrated, it's a very minor issue...HR remains the smoothest PC video renderer hands down to me(and many friends from HCFR) :)

Blue_MiSfit
8th December 2008, 22:06
Indeed. I am somewhat D65/2.2 calibrated, but my Huey Pro doesn't do a very good job :(

I never noticed any green shift, so I'm just going to pretend I never heard this :)

Too bad about Haali - actually good for him (assuming he's working a lot). Hopefully sometime he'll have time for us again :D

~MiSfit

wozio
8th December 2008, 22:26
oh right, Leak created a PS script to progressively upsample YV12/YUY2 chroma in MPC HC...

How did he do this? MPC gets RGB data from renderer, how it is possible to get yuv->rgb convert process in here? But maybe I need to ask him directly...

[QUOTE]you got a non-HD ATI card, apparently these cards also don't suffer from the "ghost lines" in HR....these ancient cards are very valuable apparently, I would strongly advise you to keep it until the end of days./QUOTE]
I don't use HR (do you read what you're answering to?), for me it doesn't have any advantages over VMR9 renderless in fullscreen exclusive mode.

leeperry
8th December 2008, 22:45
Indeed. I am somewhat D65/2.2 calibrated, but my Huey Pro doesn't do a very good job :(

did you try w/ ARGYLLCMS ?

that's the kind of calibration ARGYLLCMS offers on my old ass 19" iiyama CRT w/ an i1d2 :

http://pix.nofrag.com/5/6/f/7244b3a94c3a062791a8f8eec4ce8tt.jpg (http://pix.nofrag.com/5/6/f/7244b3a94c3a062791a8f8eec4ce8.html)

add gamut conversion on top of it w/ proper REC601/709 conversion, and I'd say that the colors look pretty damn good :eek: :D

there's a tool in the ARGYLLCMS package to check the LUT accurary, and I've noticed that they were processed in 9 bits in VGA on ATI, and 10 bits on nvidia...funny world heh :D

Leak
8th December 2008, 23:20
How did he do this? MPC gets RGB data from renderer, how it is possible to get yuv->rgb convert process in here? But maybe I need to ask him directly...
There's a thread somewhere around here where I cooked up that shader, but it boils down to this:

MPC's renderer gets an RGB image with point upsampled chroma (i.e. the chroma pixels were just duplicated in every direction) - that means no data has been lost, save for a bit of rounding during YUV -> RGB conversion.

I simply take all pixels, convert them back to YUV, keep the Y values but interpolate linearly between the U and V values of neighbouring pixels then convert back to RGB. Sure, that doesn't create extra chroma detail, but it smooths out the blocking just like ffdshow's high quality conversion does.

np: It's A Musical - Pain Song (The Music Makes Me Sick)

Leak
8th December 2008, 23:24
So changing the output colorspace, YCbCr specification, and contrast in ffdshow has no effect on the video output from the MPC-HC DXVA decoder?
Check the "Filters" contextmenu and/or your system tray - if there's no ffdshow video decoder entry/icon it's not used. And if it were used, it still couldn't magically get the decoded video off the graphics card. That's just not supported with DXVA - okay, you could probably write a custom renderer to do it, but I'd be surprised if there were any program that supported using more than one video renderer, and as soon as you start moving 1920x1080 frames back and forth over the graphics card's bus you might as well decode them in software...

np: It's A Musical - The Music Makes Me Sick (The Music Makes Me Sick)

leeperry
8th December 2008, 23:27
I simply take all pixels, convert them back to YUV, keep the Y values but interpolate linearly between the U and V values of neighbouring pixels then convert back to RGB. Sure, that doesn't create extra chroma detail, but it smooths out the blocking just like ffdshow's high quality conversion does.
and the man is humble, but it's thanks to him that we got avisynth support in ffdshow http://forum-images.hardware.fr/images/perso/roi.gif

besides I'm also a big fan of autechre & warp records :D

EDIT: if you could add support for neuron2's CUDA decoder in ffdshow, that would be the shiznit :p

Leak
9th December 2008, 00:50
EDIT: if you could add support for neuron2's CUDA decoder in ffdshow, that would be the shiznit :p
You'd need to get nVidia to support ATI cards first, and even then that's not something I'd be interested in, sorry...

np: It's A Musical - What All People Know (The Music Makes Me Sick)

leeperry
9th December 2008, 01:35
You'd need to get nVidia to support ATI cards first, and even then that's not something I'd be interested in, sorry...
ok no biggy, I guess CoreAVC will support CUDA soon or later...so I can use LSF + Avishader() on full bitrate BD :D

at this point Avishader() copies the frames back and forth between the CPU<>GPU so it sucks a helluvalot of CPU time..luckily my Q6600 is up to the task on 720p downscales, so I can get gamut conversion in HR :cool:

wozio
9th December 2008, 08:01
MPC's renderer gets an RGB image with point upsampled chroma

What drivers/graphic cards use point sampling for chroma? I though it ended few years ago. I ask to know what to avoid.

Leak
9th December 2008, 11:14
What drivers/graphic cards use point sampling for chroma? I though it ended few years ago. I ask to know what to avoid.
I do know for a fact that my ATI 4850 does it... maybe it does proper upsampling in NV12, but I haven't tried it.

wozio
9th December 2008, 12:41
So you fed renderer with yuy2? Well if my ATI 1650 pro does properly upsample nv12 then your 4850 does too. NV12 is best supported color space in drivers, good quality deinterlacing is also supported only on nv12. Is nv12 colorspace used in encoded streams? If yes then what is the reason of converting to yuy2?

Leak
9th December 2008, 12:58
So you fed renderer with yuy2? Well if my ATI 1650 pro does properly upsample nv12 then your 4850 does too. NV12 is best supported color space in drivers, good quality deinterlacing is also supported only on nv12.
That's the point - I don't use NV12 because I don't like my graphics driver/graphics hardware messing with the image, be it "Dynamic Contrast", "Noise Reduction" or just deinterlacing.

Is nv12 colorspace used in encoded streams? If yes then what is the reason of converting to yuy2?
NV12 (NV as in nVidia) is just YV12 labelled differently (and maybe the U and V planes swapped, but that doesn't affect image quality in any way) and is nowadays used to signal the graphics card to process the video with whatever optimizing functions the hardware has.

I don't like that, so I use YV12 (which is what most video codecs process internally) instead.

And where did you get the idea I was using YUY2?

wozio
9th December 2008, 18:24
That's the point - I don't use NV12 because I don't like my graphics driver/graphics hardware messing with the image, be it "Dynamic Contrast", "Noise Reduction" or just deinterlacing.

Well all of this enhancements can be disabled and must be if one cares about image quality (except deinterlacing of course, I watch a lot of interlaced content and hardware deinterlacing is only option for me). Deinterlacing doesn't switch on progressive frames. I'm unable to spot difference between source image and rendered one on my system, that means processing is only by converting yuv->rgb.

NV12 (NV as in nVidia) is just YV12 labelled differently (and maybe the U and V planes swapped, but that doesn't affect image quality in any way) and is nowadays used to signal the graphics card to process the video with whatever optimizing functions the hardware has.

As I wrote it can be disabled.

And where did you get the idea I was using YUY2?

I don't know ;-)

Wilbert
9th December 2008, 22:32
NV12 (NV as in nVidia) is just YV12 labelled differently (and maybe the U and V planes swapped, but that doesn't affect image quality in any way) and is nowadays used to signal the graphics card to process the video with whatever optimizing functions the hardware has.
It isn't the same accordingly to fourcc.org. First the luma plane, then the chroma interleaved: http://www.fourcc.org/yuv.php#NV12 (if i understand it correctly).

tetsuo55
10th December 2008, 00:11
add gamut conversion on top of it w/ proper REC601/709 conversion, and I'd say that the colors look pretty damn good :eek: :D

what is this "gamut conversion". Why does it help?

And how do we do it?

Leak
10th December 2008, 10:57
It isn't the same accordingly to fourcc.org. First the luma plane, then the chroma interleaved: http://www.fourcc.org/yuv.php#NV12 (if i understand it correctly).
Oh, okay. Makes (some) sense to do it that way, since you only have to walk 2 planes instead of 3 when converting the image to RGB...

leeperry
10th December 2008, 11:36
what is this "gamut conversion". Why does it help?

And how do we do it?
http://www.avsforum.com/avs-vb/showthread.php?t=912720

you get proper colors from the BD/DVD original mastering basically.

most displays nowadays have wide gamuts, but movies are still mastered in SMPTE-C/EBU...so it ends up in grossly oversaturated colors :eek:

once you start watching movies in their native gamuts, there's no looking back....just like watching movies w/ Reclock & a perfectly matching refresh rate

the big triangle is the original JVC RS1 gamut, the small one SMPTE-C(thanks to the PS script) :

http://i64.photobucket.com/albums/h173/prairie_2006/shader1.png

tetsuo55
10th December 2008, 12:23
Here is the diagram for my color settings.
i don't have the chart for gamma but it was calibrated for 2.2, as this picture is too dark for my viewing environment i have hightend it a bit, but i have no clue what the value is now.

the chart is REC709

littleD
10th December 2008, 12:39
I finally found that (http://forum.doom9.org/showthread.php?t=140003&highlight=gamma+test) thread.
There you have clips for testing with levels and gamma. Download them and play level test in full screen and gamma test in actual size but remember: they are full range.

leeperry
10th December 2008, 13:13
Here is the diagram for my color settings.
i don't have the chart for gamma but it was calibrated for 2.2, as this picture is too dark for my viewing environment i have hightend it a bit, but i have no clue what the value is now.

the chart is REC709
well a properly calibrated display depends on several things :

-proper D65 calibration(through gray levels)
-proper gamma correction(between 2.2 & 2.5 depending on the room & native gamma....professional gear is 2.5, consumer is 2.2)
-proper gamut conversion(SMPTE-C for US/ASIAN DVD/BD, EBU for EUR BD/DVD, HDTV for HDV)

then I shall add proper primaries/secondaries saturations, but Colorfacts doesn't measure them...only Color.HCFR does, but then it's too annoying to fix them(24 manual DVD test patterns, enough to turn anyone nuts :D )

Steveo08
10th December 2008, 18:44
@leeperry


how can i enable/disable "gamut conversion" in haali?

is that in the haali renderer, YUV Colorspace, BT.601/BT.709?

shaolin95
10th December 2008, 18:58
I dont mean to intrude but...what does the buil in MPC-HC decoder outputs RGB or something else?
When I run them in Vista 64 I get a lot more intensity in the colors displayed by the MPC-HC decoder and EVR Custom combination than with the ffdshow (avisynth covertion to RGB32 and 701) with EVR Custom.
One thing to notice is that the ffdshow+EVR is using mpc-hc 32bit and the mpc-hc decoder+EVR is using mpc-hc 64bit.

PS BTW, all my files are 1080p

leeperry
10th December 2008, 20:34
how can i enable/disable "gamut conversion" in haali?

is that in the haali renderer, YUV Colorspace, BT.601/BT.709?
well there is a way, through Avishader() but it's very CPU consuming, and pretty complicated to set up.

if you don't have an overclocked quad, you're be better off waiting for Haali to add it in HR through PS scripts(it's almost working at this point, still needs some work though....but i doesn't use any CPU at all!)

another option is MPC HC w/ this :
http://www.avsforum.com/avs-vb/showthread.php?t=912720

I dont mean to intrude but...what does the buil in MPC-HC decoder outputs RGB or something else?
use test patterns to see whether it outputs 16-235 or 0-255(you can also change it in the nvidia drivers I think) :
http://www.burosch.de/shop/shop_content.php?coID=51

Steveo08
10th December 2008, 21:15
[QUOTE=leeperry;1222770]well there is a way, through Avishader() but it's very CPU consuming, and pretty complicated to set up.

if you don't have an overclocked quad, you're be better off waiting for Haali to add it in HR through PS scripts(it's almost working at this point, still needs some work though....but i doesn't use any CPU at all!)

another option is MPC HC w/ this :
http://www.avsforum.com/avs-vb/showthread.php?t=912720


thank you, so i will wait for a new version from haali.

tetsuo55
15th December 2008, 20:18
Reclock doesn't seem to work for me

Display 50hz
Video 25hz

Reclock set to "auto" and doing its magic.

All pans have tearing at about 1/3rd distance from the top of the screen when panning/moving.

(using VMR9, fullscreen-tearing-fix disabled)

leeperry
15th December 2008, 21:06
well use Reclock/MPC HC tearing tests, maybe your display converts to 60Hz internally :D

some motherboards(Asus?) are know to create tearing as well...do you also get tearing with HR at 50.000Hz ?

tetsuo55
15th December 2008, 22:01
well use Reclock/MPC HC tearing tests, maybe your display converts to 60Hz internally :D

some motherboards(Asus?) are know to create tearing as well...do you also get tearing with HR at 50.000Hz ?

i will try that

PS my display was set to 60hz before and the tearing was much worse, it claims to natively support 24/25/30/50/60

Steveo08
16th December 2008, 23:42
i will try that

PS my display was set to 60hz before and the tearing was much worse, it claims to natively support 24/25/30/50/60



what is better for mkv movies with 23,98 fps, 50Hz or 60Hz?

my display is working with 50,59 and 60Hz. and i use 60Hz, because i mean i had a little tearing with 50Hz or was it just an imagination?



Edit:


i am know testing my display with 50Hz and enables in haali for output to force 25fps, is that the best option for me? because 50HZ is the multiple of 25fps. and how much does help the function "vertical sync" in the nvidia driver settings?