Log in

View Full Version : A little information about windows renderers.


DeathWolf
19th January 2007, 21:38
This is a little info about windows renderer, and how they behave, that is with nvidia drivers(i dont have any ATI card so i cant tell).
NVidia settings changed so that TV Level get mapped to full PC level with vmr(very necessary, otherwise you get sad ugly tv levels on the monitor, which uses pc levels)

Part1: Image quality
There are three parameters that i have taken care of in this:

LUT=respects LUT(mapping table used for calibration), depends on the renderer's ability to use the LUT properly
sharp=proper sharpness(that is no intermediate resize or structural luminance change), depends on the renderer's ability to map pixels 1:1
color=proper colorspace conversions(proper colors at the renderer level), depends on the renderer's ability to convert colorspaces/display them

Please note that sharpness and color can be checked(exept for overlay) by using the save image function of mpc.
Results of this mpc screenshotting at: http://arcueid.kawaii-shoujo.net/Pictures/


Results:

overlay mixer: sharp+colors
gdi: sharp+colors
vmr7windowed: sharp+colors
vmr7renderless: LUT+sharp
vmr9windowed: LUT
vmr9renderless: LUT+sharp
haali: LUT+sharp+colors

Note: yuy mixer/vmr9 mixer dont affect quality here
Note 2: all renderers were fed YV12 exept for haali which took in YUY2
Note 3: colorspace didnt change in any major way how things were displayed

The obvious conclusion of that is that only haali could match the 3 needed requirements.


Part2: cpu wise:
Used cpu per core for Blankclip(width=1920,height=1080,color=$777777,length=8000,pixel_type="YV12"):

Results:

Vmr9renderless, 56%, 25%
Vmr7renderless, 30%, 12.5%
Vmr9windowed, 30%, 12.5%
Vmr7windowed, 18.5%, 6%
Haali, 32%, 12.5%
Old renderer, 18%, 6%
Overlay mixer, 19%, 6%


Note: the texturing did not change much on speed(less than a few percent)


These tests were done an AMD 4200+, with 2GB Ram, source video for part 1 was on a ramdisk, gpu is a 6600GT.

Overall i'd say haali is the best renderer, but sadly with my 6600 GT it cant really handle HD it seems (6600GT not being ps-powerful-enough for it i guess, but i'd be happy to hear other opinions/experiences).

Edit1: after some checking, haali does handle hd rather fine but it's giving me some non-smooth pans, at what seems to be fixed intervals. I do not get these with vmr9 renderless/other renderers, which leads me to think that either haali's renderer is dropping frames, or the method to calc which frame to display is different, or there is a problem.

kumi
19th January 2007, 22:07
Just curious, what should I be looking for when judging the effects of LUT? I can't see a difference between vmr7windowed.PNG and haali.PNG. Proper sharpness and proper color, on the other hand, are immediately apparent.

Egh
19th January 2007, 22:09
:goodpost:

But some questions:

* What does exactly item #3 mean?

* Cpu load on Haali renderer heavily relies on GPU, so comparison is not entirely correct here. On my former machine, with FX5500, Haali even for dvd content was much slower (for whole system) compared to VMR9.


* What is that LUT you mentioned?


* Be aware that renderer-level conversion in Nvidia cards depends both on version of the drivers and video card. that VMRCCStatus doesn't do anything here (7600, single CRT monitor, 93.81). Besides, to my knowledge, they also changed the type of that key in registry in later versions.

DeathWolf
19th January 2007, 22:16
Just curious, what should I be looking for when judging the effects of LUT? I can't see a difference between vmr7windowed.PNG and haali.PNG. Proper sharpness and proper color, on the other hand, are immediately apparent.
The LUT's effects will only appear on the display, and not on the screenshots are they applied at the very last stage before video out it seems.


:goodpost:

But some questions:

* What does exactly item #3 mean?

item #3 means that in the way to be converted to RGB32(or whatever it is) for final use, colors dont get tweaked in a weird way, you can clearly see it in screenshots by comparing the original and vmr renders(luminance seems more or less intact, but saturation seems to have changed).

* Cpu load on Haali renderer heavily relies on GPU, so comparison is not entirely correct here. On my former machine, with FX5500, Haali even for dvd content was much slower (for whole system) compared to VMR9.
Yep, the cpu part is much less precise and important.

* What is that LUT you mentioned?
It's the lookup table, which is, afaik, gamma/mapping correction tables that you usually generate with hardware calibration. These allow for proper color correction.

* Be aware that renderer-level conversion in Nvidia cards depends both on version of the drivers and video card. that VMRCCStatus doesn't do anything here (7600, single CRT monitor, 93.81). Besides, to my knowledge, they also changed the type of that key in registry in later versions.

here VMRCCStatus did change things properly in here, guess i was lucky.(i used to have horrid 16-blacks 235-whites, and now they are truely at 0 & 255)

HeadBangeR77
19th January 2007, 22:56
@ DeathWolf

Thanks (although I haven't got na Nvidia card) ;) Your thread seems to be very close connected with this one:

http://forum.doom9.org/showthread.php?t=120718

at least from the 2nd page on:
http://forum.doom9.org/showthread.php?t=120718&page=2

If only someone could put the things together, we would get a prefect compendium, though more concentrated on Nvidia users.

DeathWolf
19th January 2007, 23:33
Some more news, the latest beta drivers of nvidia affect things very differently!
Overlay respects LUT in RGB32 with the latest drivers!

Color wide only VMR9 renderless/windowed arent good anymore, everyone else is perfectly fine with these drivers!


And haali's renderer is much smoother with them too(i'm now switching permantly to it)

Egh
20th January 2007, 19:10
Some more news, the latest beta drivers of nvidia affect things very differently!
Overlay respects LUT in RGB32 with the latest drivers!

Color wide only VMR9 renderless/windowed arent good anymore, everyone else is perfectly fine with these drivers!


And haali's renderer is much smoother with them too(i'm now switching permantly to it)

Well that's what I told you :) And it's not really latest, it's all 9x.xx forceware. And did you check if VMRCC[C]Status works in the new drivers as expected?

What version did you install? And what is still not good colorwide for VMR9? Tried feeding it with RGB32 in the new version?

DeathWolf
20th January 2007, 20:10
Note that i was running a 93.xx before and the behaviour was different.
running 93.81 now.
VMRCC[C]Status worked for me, perfectly, it was just in a different location.

As for VMR9, the colors are still off-saturated(at least, if not more), indicating the color space conversion is again borked.

And yes, RGB32 is exactly the same.

Egh
21st January 2007, 17:27
Note that i was running a 93.xx before and the behaviour was different.
running 93.81 now.
VMRCC[C]Status worked for me, perfectly, it was just in a different location.

As for VMR9, the colors are still off-saturated(at least, if not more), indicating the color space conversion is again borked.

And yes, RGB32 is exactly the same.

I still find it strange that VMR9 in RGB32 is bad.

Maybe it's an issue with 6xxx series only?

As for vmrcc(c)status, do you know that this parameter is created by nvidia new control panel? But different to prior versions of the driver, it is not DWORD, it is binary. Also there's a big matter of confusion how many "c"s are in the key name :)

DeathWolf
21st January 2007, 17:31
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet018\Services\nv\Device0\VMRCCCSStatus
that's what i changed for me, dword, set to 0x3.

Maybe it's just 6xxx series indeed, i cant tell.
It did sounds more like a software problem than hardware though... but who knows.

Rash
25th January 2007, 05:31
As for VMR9, the colors are still off-saturated(at least, if not more), indicating the color space conversion is again borked.
Absolutely! I was amazed by how bad the colours are on VMR9!

Have a look at some actual video screenshots and the difference is obvious. One is using System Default renderer (same as VMR7 - using MPC's nomenclature) and the other one is using VMR9 windowed. Believe me when I say this difference is noticeable even when you are not comparing side by side screenshots like this. When I had set VMR9 I knew something was different.

http://rash.apanela.com/images/Lost_1_SysDef.png
http://rash.apanela.com/images/Lost_1_VMR.png
http://rash.apanela.com/images/film_SysDef.png
http://rash.apanela.com/images/film_VMR.png

The brightness/contrast levels were adjusted for both renderers using the THX Optimizer. I know THX is not the best way to calibrate anything, but it was an easy and fast way to do a small calibration. It is not responsible for this difference.

I will give Haali's Renderer another try now that you've mentioned, DeathWolf. I gave up on Haali when I realised it was conflicting with my drivers. I'm using NVIDIA's latest stable drivers 93.71.

Thank you for your testing.

Rash
25th January 2007, 06:08
Wow! Testing has never been so fast. I tested Haali against SysDef, my preferred choice. Not only the image quality with SysDef was much superior (sorry, I can't prove that) but also CPU utilization was lower. Haali did not score good with my heaviest video, a 720p 60fps WMV encoded at 12 Mbps. :(

http://rash.apanela.com/images/haali_sysdef_01.png
http://rash.apanela.com/images/haali_sysdef_02.png

So I'm back to default. In the end of the day this is good. I love defaults. One thing I hate about videos on Windows XP is all these many choices. I wish XP had only one good video renderer and that's it, all program coders would support it, driver coders would do their best and we wouldn't have to endure these differences. I'm not against custom renderers like Haali, having the option to add a new renderer is great. But the system itself should have only one. Ahhh, why is Vista taking so long... it should solve this issue.

DeathWolf
25th January 2007, 11:59
the sys renderer is pretty good exept it doesnt respect LUT at all. Otherwise i guess it's a pretty good choice.

And yeah, the lack of one very good accelerated renderer is mostly frustrating. But afaik it's partly microsoft's fault and partly nvidia/ati's.

Rash
26th January 2007, 04:13
DeathWolf, I'll be honest with you, I didn't understand what you meant by LUT, but I can't help noticing the superior image quality with SysDef. It is by a very small margin, but enough for my eyes.

Like I said, I'm completely opened to new renderes like Haali and even VMR9. That's why I test them all. But SysDef will remain, for now, as my preferred choice.

Obviously, SysDef can only be used after some calibration. But I've messed so much with it, that I think I came to a solution.

I know this is not Microsoft's fault alone. But they could impose one format for both ATi and NVIDIA, like they did with DirectX and its features. That's the only way we can garantee that a game will run on either brand. I wish MS did a little bigger effort with video too.

KoD
26th January 2007, 11:59
VMR9's default TV scale range instead of PC scale (as if someone that has a PC only uses that PC to play video, not do other stuff) is Microsoft's "bigger effort". They are the ones responsible for imposing this stuff, as they made "recommendations" to Nvidia and ATi. You can find such discussion from Microsoft employees on avsforum.

As for LUT. Well, you see, what a video decoding chain ultimately spews out are simply numbers. For one sample of the image (you can consider it as one point or pixel, but that's not quite correct), in the end the decoding chain outputs three numbers, one representing red, one green and one blue. These are just that, numbers like (123,23,78). Well, you know, you can map these numbers to other numbers (123,23,78) -> (124, 30, 79). This mapping is done by means of a LUT (lookup table). In the case above, the lookup for 123 returns 124, 23 -> 30, 78 -> 79. The values in this table are what color calibration software modifies. This remapping (transform) is performed by the video card. Such remapping is usually necessary because of the various color transforms performed on the video material on its way from capture (sampling / digitization -> that's how those numbers are originated) to being displayed (transformed from discrete samples to analog signal again).

Rash
26th January 2007, 19:55
Thank you for your explanation, KoD.

Egh
28th January 2007, 19:53
DeathWolf, I'll be honest with you, I didn't understand what you meant by LUT, but I can't help noticing the superior image quality with SysDef. It is by a very small margin, but enough for my eyes.
... ... ... ...


Would be nice if all that was proven by images :)
As for SysDef renderer, there's NO such thing in the existance.
System Default falls back to some other renderer, the exact type of which would depend on installed DX version and version of Windows. It is mentioned it falls back to VMR7 windowed on XP, but never checked that.

As I already told earlier, I don't see any serious difference in quality between VMR9 and Haali renderer, provided i feed both with RGB32 (from ffdshow).

Btw, as a sidenote. DX10 is upcoming ^^ Maybe we'll have VMR10, who knows :P

DeathWolf
28th January 2007, 19:58
for images without LUT considerations you can check the url on my first post.

That is, to show LUT being applied or not I'd have to photograph the screen:)

foxyshadis
29th January 2007, 12:01
Would be nice if all that was proven by images :)
A LUT is just a generalization of Levels and Curves (or even Brightness/Contrast/Saturation), which are all specific forms of luts. That should make it obvious how it can change the picture. (Not just a placebo!)

In this case I guess it takes into account the monitor's ICM profile (or something?) to bring the image into a "calibrated" state.

Egh
29th January 2007, 23:11
A LUT is just a generalization of Levels and Curves (or even Brightness/Contrast/Saturation), which are all specific forms of luts. That should make it obvious how it can change the picture. (Not just a placebo!)

In this case I guess it takes into account the monitor's ICM profile (or something?) to bring the image into a "calibrated" state.

I think it's more like Nvidia gamma settings (overlay is separate from desktop/vmr).

faam
13th May 2007, 15:58
Note: the texturing did not change much on speed(less than a few percent)


.

Sorry man you are wrong, on my 2.8 P4 512ram Geforce MX4000
the texturing in 2d icrease it to about 10%
============3d ============== 15%

regards

tetsuo55
13th May 2007, 16:24
I wonder if an updated version of this test could be done, i would especially be interested in running the test again with the latest haali renderer and both on winxp and vista.

reepa
14th May 2007, 15:42
I think it's more like Nvidia gamma settings (overlay is separate from desktop/vmr).

Overlay had separate color controls on an ATi Radeon 8500 too. As for the LUT: isn't it harmful to image quality when using a digital connection (8bit -> LUT -> 8bit; analog has a 10bit DAC)? Also, I tried GDI rendering with VLC and it definetely was affected by LUT.

edit:
Would be nice if all that was proven by images :)
Here's a renderer which not affected by LUT:
http://img291.imageshack.us/img291/3043/noeffectfz2.jpg (http://imageshack.us)

Here's a renderer which is:
http://img150.imageshack.us/img150/4849/effectaw3.jpg (http://imageshack.us)

DeathWolf
14th May 2007, 16:25
LUT can create banding indeed since it's nothing but remapping, when purely digital.
I'm not sure if it does it with analog.

But it's still better(imho) to have good colors and some banding(fixable with deband/noise) than bad colors.
(and with most lcds you get banding in the dark tones anyway)