madVR - high quality video renderer (GPU assisted)

[madshi]

http://madshi.net/madVR.zip

madVR v0.11

* fixed: luma resampling settings weren't saved/loaded correctly
* fixed: on some PCs video startup took several seconds
* updated cr3dlut to v2.2

features:

- high quality chroma upsampling
- high quality scaling (bicubic, mitchell, lanczos, spline etc)
- high quality YCbCr -> RGB conversion
- gamut & gamma correction for display calibration
- full 16bit processing queue
- final 16bit processing result is dithered down to RGB output bitdepth
- bypasses graphics card's video (damage) algorithms
- all work is done via GPU shaders
- no shortcuts, highest quality has priority over anything else

requirements:

- graphics card with full Direct3D9 hardware support
- at least 128MB of dedicated graphics card memory
- Windows XP or newer

disadvantages:

- hardware accelerated video decoding (DXVA) is currently not supported
- slightly slower startup when using 3dlut technology (96MB file must be read)

[madshi]

chroma upsampling comparison:



A picture says more than 1000 words. I don't think I have to comment this, do I?



These pictures are 400% enlarged. If you want to see the original 100% images, I've uploaded them here:

ATI - VMR9 - red fonts.png
ffdshow 2867 - red fonts.png
MPC HC YV12 Shader - red fonts.png
Haali Renderer - red fonts.png
madVR 0.5 - red fonts.png

extreme downscaling comparison:



I'm aware that you usually don't downscale that much. But I still thought that the differences were interesting, so I'm posting them here.

The ffdshow gray background is *not* caused by incorrect settings (like output levels), I've double checked that. The gray background must originate from calculation errors in the scaling algorithm (lanczos, default settings). The ATI VMR9 and Haali Renderer downscaling results might not look that bad on a quick check, but you need to see it in motion! It sparkles like crazy, totally unwatchable. ffdshow's and madVR's downscaling don't sparkle, they're both stable and smooth.

visible benefits of more than 8bit processing:

I've some screenshots to demonstrate that higher than 8bit processing does help in specific situations, but the screenshots are too big to include them in this post, so I'll just post links instead. Please open the 3 links in different tabs of your browser and then switch between them. Please make sure that your browser does not rescale the images, so that there are no additional artifacts added by the browser scaling.

The following screenshots were made with images produced by the "madTestPatternSource" YCbCr test pattern generator. More details about that in this thread:

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

Now the comparison images:

ATI - VMR9 - colors.png
ffdshow 2867 - colors.png
Haali Renderer - colors.png
madVR 0.1 - colors.png

This test pattern consists of colored rectangles which form a smooth full screen color gradiant. Properly displayed you should be able to see the rectangle borders, but you shouldn't see any visible patterns in the color gradiants.

Now if you look at the ATI VMR9 and Haali Renderer result, you do see some kind of pattern. It doesn't look that bad on the screenshot, but in motion it's really ugly, because the pattern changes with every frame. The ffdshow result is even worse. The madVR result is exactly how the test pattern is supposed to look. It also stays stable in motion. The patterns in the color gradiants are caused either by too low processing bitdepth or by rounding or truncating the final processing result down to 8bit. The madVR output is only that smooth because it uses proper dithering.

If you like these kind of comparisons, I'd suggest to try "madTestPatternSource" yourself. It's contained in the madVR archive. Use it to compare image quality yourself with the renderer you're usually using.

ATI - VMR9 - smallramp.png
ffdshow 2867 - smallramp.png
Haali Renderer - smallramp.png
madVR 0.4 - smallramp.png

On a first check these 3 images might not look all that different. But if you look closer you should see two things: (1) The gradiants in the ATI VMR, Haali Renderer and madVR screenshots are smooth from left to right, while there are some unexpected bright bars standing out in the ffdshow gradiant. (2) In the ATI VMR, Haali Renderer and ffdshow screenshots the whole gradiant is covered by very small and faint vertical bars. In contrast the madVR screenshot doesn't show any such bars.

This test pattern works very well to test whether the processing queue beginning with upscaling and ending with final output somewhere somewhen ends up in rounded or truncated 8bit. If it does, you will see those faint vertical bars. The only way to produce a really smooth output with this test pattern is to do scaling and all the processing steps afterwards with more than 8bit. Also the final result must not be rounded or truncated down to 8bit. Instead only proper dithering preserves the smoothness.

[madshi]

How to use:

(1) First of all you need to use a media player which supports using madVR as a renderer. Your choices are currently MPC HC, Zoom Player and KMPlayer.

(2) madVR only accepts "YV12" and nothing else. So make sure that the decoder you're using actually outputs YV12, or else madVR will not work. I've intentionally limited madVR in this way because outputting YV12 is simply the best quality option.

(3) You can press Ctrl-J to turn the OSD on/off.

(4) If movies stutter for you then maybe your graphics card is not fast enough. In that case you can open the madVR settings dialog (you'll find it somewhere in your media player, at the same place where you also find the settings dialogs of all other filters). There you can turn down image quality somewhat to gain some speed. You can also simply just play with the options to see what effect they have. If you want to do that, I'd suggest trying the "madTestPatternSource", which allows you to easily see differences with the various madVR options enabled/disabled.

(5) Currently madVR only supports windowed mode, which is not ideal for smooth motion playback. Fullscreen exclusive mode will be added in a future version which should allow nearly perfect smooth motion playback.

If you want to know more about which scaling filters have which effect, you can check out this post:

http://forum.doom9.org/showthread.ph...90#post1272990

For starters, I recommend to use "SoftCubic100" for chroma resampling. IMHO it produces best quality. And it's even quite fast, too. For luma resampling you will have to experiment which filter you like most. Some are sharper than others, but have more ringing artifacts. So it's a matter of taste...

If you run into any trouble, please let me know. If you don't run into any trouble but love what you see, then please let me know, too...

[madshi]

technical discussion:

I've seen many comments about HDMI 1.3 DeepColor being useless, about 8bit being enough (since even Blu-Ray is only 8bit to start with), about dithering not being worth the effort etc. Is all of that true?

It depends. If a source device (e.g. a Blu-Ray player) decodes the YCbCr source data and then passes it to the TV/projector without any further processing, HDMI 1.3 DeepColor is mostly useless. Not totally, though, because the Blu-Ray data is YCbCr 4:2:0 which HDMI cannot transport (not even HDMI 1.3). We can transport YCbCr 4:2:2 or 4:4:4 via HDMI, so the source device has to upsample the chroma information before it can send the data via HDMI. It can either upsample it in only one direction (then we get 4:2:2) or into both directions (then we get 4:4:4). Now a really good chroma upsampling algorithm outputs a higher bitdepth than what you feed it. So the 8bit source suddenly becomes more than 8bit. Do you still think passing YCbCr in 8bit is good enough? Fortunately even HDMI 1.0 supports sending YCbCr in up to 12bit, as long as you use 4:2:2 and not 4:4:4. So no problem.

But here comes the big problem: Most good video processsing algorithms produce a higher bitdepth than you feed them. So if you actually change the luma (brightness) information or if you even convert the YCbCr data to RGB, the original 8bit YCbCr 4:2:0 mutates into a higher bitdepth data stream. Of course we can still transport that via HDMI 1.0-1.2, but we will have to dumb it down to the max HDMI 1.0-1.2 supports.

For us HTPC users it's even worse: The graphics cards do not offer any way for us developers to output untouched YCbCr data. Instead we have to use RGB. Ok, e.g. in ATI's control panel with some graphics cards and driver versions you can activate YCbCr output, *but* it's rather obvious that internally the data is converted to RGB first and then later back to YCbCr, which is a usually not a good idea if you care about max image quality. So the only true choice for us HTPC users is to go RGB. But converting YCbCr to RGB increases bitdepth. Not only from 8bit to maybe 9bit or 10bit. Actually YCbCr -> RGB conversion gives us floating point data! And not even HDMI 1.3 can transport that. So we have to convert the data down to some integer bitdepth, e.g. 16bit or 10bit or 8bit. The problem is that doing that means that our precious video data is violated in some way. It loses precision. And that is where dithering comes for rescue. Dithering allows to "simulate" a higher bitdepth than we really have. Using dithering means that we can go down to even 8bit without losing too much precision. However, dithering is not magic, it works by adding noise to the source. So the preserved precision comes at the cost of increased noise. Fortunately thanks to film grain we're not too sensitive to fine image noise. Furthermore the amount of noise added by dithering is so low that the noise itself is not really visible. But the added precision *is* visible, at least in specific test patterns (see image comparisons above).

So does dithering help in real life situations? Does it help with normal movie watching?

Well, that is a good question. I can say for sure that in most movies in most scenes dithering will not make any visible difference. However, I believe that in some scenes in some movies there will be a noticeable difference. Test patterns may exaggerate, but they rarely lie. Furthermore, preserving the maximum possible precision of the original source data is for sure a good thing, so there's not really any good reason to not use dithering.

So what purpose/benefit does HDMI DeepColor have? It will allow us to lower (or even totally eliminate) the amount of dithering noise added without losing any precision. So it's a good thing. But the benefit of DeepColor over using 8bit RGB output with proper dithering will be rather small.

[TheFluff]

Looks like it uses PC levels without any option to expand TV->PC. Other than that, seems to work fine in my extremely brief test. Works fine as a custom renderer in zoomplayer. Quite slow in changing window size and going between fullscreen/windowed mode, but I guess that's to be expected.

(nice job, by the way)

[madshi]

Originally Posted by TheFluff

Looks like it uses PC levels without any option to expand TV->PC. Other than that, seems to work fine in my extremely brief test. Works fine as a custom renderer in zoomplayer.

You're too quick!! I'm still working on the description and documentation (see "reserved" posts).

YCbCr -> RGB conversion is done through a 96MB 3dlut file. The 3dlut file shipping with madVR is using PC levels. You can however create your own file with any custom setting you want. Please check out this thread to learn more about this topic:

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

[leeperry]

these test patterns look somewhat familiar

awesome project btw! do you plan on adding jitter correction(a la HR) and means to synchronise to the VSYNC fliptime ?

this is the real enemy : http://software.intel.com/en-us/arti...ynchronization

96MB seems quite a lot, why not only 5-6 frames?

hopefully when it'll be mature, James won't mind adding support for it in Reclock

EDIT: oh cool it reads LUT's from yesgrey's software

[Rectal Prolapse]

madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration.

[madshi]

Originally Posted by leeperry

do you plan on adding jitter correction(a la HR) and means to synchronise to the VSYNC fliptime ?

I'm not sure yet which exact method I'll use to get motion display smooth, but I do plan to make sure that at least with a 1:1 match between source frame and display refresh rate motion display will be smooth. Such a feature is not implemented yet, though. After all, this is just a very first beta release to get some feedback from users with different graphics cards.

Originally Posted by leeperry

96MB seems quite a lot, why not only 5-6 frames?

Those 96MB are spent on the 3dlut file (for YCbCr -> RGB conversion, gamut & gamma correction), not on frame storage!

Originally Posted by Rectal Prolapse

madshi, have you tested this with neuron2's VC1/AVC CUDA decoder, or coreavc's CUDA? That can get you back some h/w acceleration.

I have an ATI card, so I can't test that. However, yesgrey has already tested CUDA + madVR and generally it works, although it seems that with a low range graphics card using both CUDA + madVR at the same time may be too much of a burden for the GPU.

[Atak_Snajpera]

@madshi
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)

[leeperry]

Originally Posted by Atak_Snajpera

@madshi
Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)

the biggest problem w/ EVR is the ugly EE it adds, yet it doesn't show on screenshots
they must be doing it after the RGB32 mixer, behind the scene. Use LSF in ffdshow, play a video in EVR then in HR on a large screen...they don't look quite similar, the picture in EVR is more 3D-like and its EE algorithm interferes w/ LSF, making the picture way oversharpened(VMR9 has the same problem, but less EE)

a D3D renderer that'd keep the PQ untouched(like HR), use yesgrey's LUT and sync to the VSYNC fliptime is one hell of a terrific idea

but on Vista, Aero forces the VSYNC constantly...which makes HR jerky to hell...hopefully madshi will find a workaround for this, making it XP compatible too

[madshi]

Originally Posted by Atak_Snajpera

Could you also post screenshot from MPC-HC with enabled shader YV12 Chroma Upscaling (EVR Custom)

That's a gone one. I've updated the screenshots. You may need to press F5 to reload the images.

In the "Jacques Pibarot" test the MPC-HC YV12 Shader is *almost* as good as madVR. But in the other chroma upsampling test madVR is still in a class of its own.

[Atak_Snajpera]

@leeperry
What does 'EE' stand for?

[madshi]

Edge Enhancement, which often produces ringing (typically white ghost lines next to high contrast edges).

[leeperry]

Originally Posted by Atak_Snajpera

@leeperry
What does 'EE' stand for?

Edge Enhancement : www.videophile.info/Guide_EE/Page_01.htm

[Mark_A_W]

Thanks Madshi

I would be awesome if you integrated it with Reclock (sync to V-sync or something). Smoothness is the most important to me (and no tearing!).

[Snowknight26]

Alternate link to the custom MPC-HC build:
http://stfcc.org/misc/mplayerc.rar

And while I'm at it:


Oops.

[DeepBeepMeep]

Many thanks Madshi for this new creation!

However, I am not sure I have understood its added value compared to VMR9/EVR for a typical usage, I mean is there any real benefit to use this renderer if no resize is needed for the playback of a 1080p movie on an 1080p screen using HDMI 1.0?

On a side note I have noticed that when a player that uses the renderer (in my case zoomplayer) is in the background the CPU usage rises to 50% even in pause mode.

[yesgrey3]

Here is the link for the new reclock release that already supports madVR, I've requested it to James (reclock's current developer) and he was so nice to add it imediatelly.
http://forum.slysoft.com/showthread.php?t=19931

[honai]

I just knew madshi was cooking up something, but I suspected he might be the force behind the mysterious SlyPlayer.

This is really amazing work, madshi, thank you very much! It proves once again that when it comes to obsessing about quality nothing beats German engineering. And I'm in total agreement, when we can get the best quality why compromise?

One question: Does madVR actually support 10-bit data paths in GPU drivers?