madVR - high quality video renderer (GPU assisted)

[leeperry]

I don't usually check my calibration through media players because Color.HCFR needs a lot of patterns, and it's a major PITA as nothing's automatizable..I can't be hassled to press "next" on the CRT in HCFR and then "next" on the projector +40 times in a row.

I calibrate my CRT w/ an automatic VGA LUT using ArgyllCMS(that I double-check w/ Color.HCFR using its built-in test patterns) and my HC3100 pj(10bit gamma/RGB processing) using Color.HCFR and its built-in test patterns. On top of that, I do need gamut mapping from the PC, and I check their accuracy against this PS script using screenshots of a REC.709 test pattern.

madshi said this script wasn't mathematically accurate?! I guess a simple 3DLUT in HLSL code would be piece of cake to implement? And waiting for 96MB files to load for a simple gamut mapping is pretty overkill....anyway, I'll stop whining about it, I guess it'll come soon or later and that's the only thing missing in mVR for me

About the VGA LUT flush, I'm not sure it's happening on the nvidia but OK I'll double-check! on the ATi it was dead obvious as it would happen on the windows desktop before the game opens.

I guess it might come in handy to import the VGA LUT info(3x256 values in the ArgyllCMS file) within the madVR 3DLUT but ArgyllCMS has a tool to check the VGA LUT accuracy, and supposedly VGA and the VGA LUT working in 10 bit...you often end up with 9bit results, so in analog keeping the VGA LUT might be desirable.

PS: the only major flaw in my calibrations is that the gamut mappings don't take the actual saturations in account() but quite frankly, Colorfacts doesn't even care about those...and I haven't seen any CMS that'd allow inputting them. You need a proper CMS in your display to overcome this problem AFAIK.

And checking on those saturations in a media player requires 60 Color.HCFR manual test patterns hah

[Octo-puss]

Originally Posted by noee

My advice is, if your GPU can handle madVR (and it appears anything newer can), don't look back.

But in the first post I can read "hardware accelerated video decoding (DXVA) is currently not supported"...

[namaiki]

DXVA doesn't have anything to offer over software decoding in the 'quality' debate.

[Mark_A_W]

DXVA is a total load of crap.

It means you are handing your video quality over to a bunch of developers who's mission in life is to get 2 more fps on the latest game for 15yr olds.

[janos666]

Originally Posted by leeperry

Color.HCFR needs a lot of patterns, and it's a major PITA as nothing's automatizable.

I calibrate my CRT w/ an automatic VGA LUT using ArgyllCMS and my HC3100 pj(10bit gamma/RGB processing) using Color.HCFR and its built-in test patterns.

You can make custom test pattern set with DispcalGUI very easily. I already prepared one for yCMS when it will accept 3D measurement formats for the gray scale tracking.
You can collect the data from the full 0-255 gray ramp + primary and secundary colors automatically with the display profiling function in DispcalGUI (and a custom pattern set).

On top of that, I do need gamut mapping from the PC, and I check their accuracy against this PS script using screenshots of a REC.709 test pattern.

madshi said this script wasn't mathematically accurate?! I guess a simple 3DLUT in HLSL code would be piece of cake to implement? And waiting for 96MB files to load for a simple gamut mapping is pretty overkill....

Yes, it was inaccurate. It handled the out-of-gamut colors very badly. Even cr3dlut was not perfect (I didn't check my old display with a bug-free yCMS version.)

Real-time HQ processing? That would be an overkill, not a little extra loading time.

The load time is nearly unnoticeable for me. (I have a RAID-0 array with fast hard disks. But you should try an SSD as a system disk! I loved that.)

About the VGA LUT flush, I'm not sure it's happening on the nvidia but OK I'll double-check! on the ATi it was dead obvious as it would happen on the windows desktop before the game opens.

Sometimes it happens, sometimes it doesn't. Fortunately, it doesn't happen too often.

I guess it might come in handy to import the VGA LUT info(3x256 values in the ArgyllCMS file) within the madVR 3DLUT but ArgyllCMS has a tool to check the VGA LUT accuracy, and supposedly VGA and the VGA LUT working in 10 bit...you often end up with 9bit results, so in analog keeping the VGA LUT might be desirable.

ArgyllCMS guessed my effective VGA LUT depth is 11 bit. The display works with 12 bit controller which theoretically receives 12 bit through HDMI (I can't check it objectively now), but the panel works with dithered 10 bit only.

This 12 bit (integer?) processing with performance optimized algorithms (for small integrated chips) is absolutely useless for gamut correction. I tired to set up a perfect Rec709 coverage with the six-axial Saturation and Huye controls. It produced perfect primary coordinates and a heavily distorted color chart.
Fortunately, there are two internal 12 bit 3DLUTs for gamut emulation as well. These are factory calibrated LUTs, I don't have control over them, so they are good but not perfect. But this is the right path (3DLUT intead of realtime processing).

the only major flaw in my calibrations is that the gamut mappings don't take the actual saturations in account

And checking on those saturations in a media player requires 60 Color.HCFR manual test patterns hah

I think my earlier suggestion will come in handy here.

[leeperry]

ok nice, but ArgyllCMS cannot give those saturations charts I think? and my current workflow works like a charm: 1) the display is calibrated to the best it can be(using its 10bit internal processing) 2) I process gamut mapping from the PC...and no CMS seems to be able to import those saturations figures anyway, so there's no point in checking them within a media player.

I've got all my HTPC files on a PC8500 ramdisk, and PotPlayer is noticeably slower to open when I enable a 96MB LUT file in mVR and I need 6 LUT's for my 2 displays...it's annoying to run batches to decompress them when I could just rename .ini files

The VGA LUT cannot provide gamut mapping as it's a 1D LUT, but using it for ArgyllCMS calibration can be handy as it can be processed in more than 8bit...but well, if you take dithering in account maybe it's not superior..so merging the VGA LUT into the 96MB 3DLUT might be desirable indeed.

the PS script looked great to my eyes and has been double-checked by many ppl(even on my HC3100 that has a lot of OOG green): http://www.avsforum.com/avs-vb/showp...4&postcount=90

You've reminded me that there are tools to force the VGA LUT within D3D games, I'll use them if need be.

[Octo-puss]

Originally Posted by Mark_A_W

DXVA is a total load of crap.

It means you are handing your video quality over to a bunch of developers who's mission in life is to get 2 more fps on the latest game for 15yr olds.

What's wrong with utilizing VGA instead of CPU? I like it...

[namaiki]

There's nothing wrong with it, but it is something you can 'sacrifice' (if you will call it that) for superior video quality.

[madshi]

First of all: Thanks to everyone who gave feedback about the ATI Pixel Format issue.

Originally Posted by janos666

Can you implement a little option (which is disabled by default, and I don't need a check-box on the GUI, an ini variable would be good enough) which clears the VGA LUT but reloads it after you close the video player?

I can do that in a future version. But not before the settings dialog is redesigned (which is not too far away).

Originally Posted by Virtual_ManPL

Using madVR 0.23 + MPC-HC 1.3.2179.0 causing frame freezing in fullscreen mode, it unfroze when I move mouse on seeking menu. Works fine in windows mode or using older madVR 0.9.

It's only me or some1 have this problem too ?

I've not seen this reported by anyone else. Can you do a log for me?

Originally Posted by Octo-puss

I have one stupid question. Can madVR potentially replace Haali renderer? I do not technically understand these things, but given how poorly updated Haali is, I am curious.

Originally Posted by Octo-puss

But in the first post I can read "hardware accelerated video decoding (DXVA) is currently not supported"...

I'm confused. Haali does not support DXVA decoding, either. So if you're looking for a replacement for Haali's renderer, the lack of DXVA support in madVR should not bother you...

About your original question: Just give madVR a try and see if it works as well as the Haali Renderer in your setup. If not, come here and complain. If madVR works even better for you, come here and post thanks.

[janos666]

Originally Posted by madshi

First of all: Thanks to everyone who gave feedback about the ATI Pixel Format issue.

I forgot to mention: The HDMI pixel format settings work for me with a HD5850 (native HDMI 1.3 port) and 10.7a drivers. (I found it better than the DisplayPort 1.1a connection was.)


It is only an idea but there is an "Enable ITC processing" option in CCC (it is enabled by default, at least for me).
It is related to full screen movie playback. So, I think it has nothing to do with madVR (and I think it won't really work even with EVR) but maybe it worths to try. (Theoretically, it will try to apply some smart connection methods between the devices. So, may be it wants to automatically set the dynamic range as well. And it may think that RGB Limited is better for you device.)

[madshi]

madVR v0.24 released

http://madshi.net/madVR.zip

* added *automatic* fullscreen exclusive mode
* added optional seek bar (only for fullscreen exclusive mode)
* added OSD interface for media players
* added new options for automatic fullscreen exlusive mode and seek bar
* added rendering mode information to OSD
* added some code to avoid playback freezes
* changed Aero timing mode slightly
* changing backbuffer count now shows immediate effect
* added keyboard shortcut Ctrl+Alt+Shift+Y for switching PC <-> video levels

Some things to note:

(1) In order to use the new automatic fullscreen exclusive mode, make sure the "D3D Fullscreen" option in MPC HC's "output" tab is turned *OFF*.

(2) The automatic fullscreen exclusive mode works like this: When you run your media player in a window, madVR will render in windowed mode. As soon as you go into fullscreen mode, and if no media player GUI is visible for more than 1 second, madVR will automatically switch into fullscreen exclusive mode. If you open a context menu or an option dialog or any other media player GUI, madVR will at once switch back to windowed mode. This automatic switching allows you to use the full benefits of fullscreen exclusive mode, while still giving you the full GUI of your media player.

(3) The automatic fullscreen exclusive <-> windowed mode switching takes a bit of time, so it is to be expected that there will be a few dropped frames. The switching works pretty fast on my XPSP3 Radeon 3850 dev machine, but noticeably slower on my Windows 7 x64 NVidia 9400 HTPC. I'm not sure where the difference comes from. So please give it a try and report back how quickly the switching works on your setup.

(4) Because the automatic switching results in a few dropped frames, madVR now also draws a custom seek bar (only in exclusive mode). This way you can seek without madVR having to go back to windowed mode. In order to activate the madVR seek bar, move your mouse cursor to the bottom of the screen.

(5) If you activate the automatic fullscreen exclusive mode, madVR will not use the extended Direct3D9 interfaces in Vista and Windows 7 for now, because they make some trouble. This is a minor disadvantage, but no biggie IMHO.

(6) madVR is not yet using the full potential of the fullscreen exclusive mode. So there are further reliability improvements to be expected in a future version. However, there are already many benefits right now:

- improved performance
- improved reliability (less delayed/dropped frames)
- no tearing
- no problems with stupid Aero
- no problems with multi monitor setups

Please consider the automatic fullscreen exclusive mode feature "experimental". It's a first version and expected to have some bugs in it. But still, I'm already using it myself and I'm pretty happy with the improvements with my NVidia 9400 HTPC.

[Octo-puss]

I am an idiot. I confused the renderer with the codecs and/or player being used. Of course Haali doesn't support DXVA either
Btw. I just installed madVR and have a little problem - I cannot select it in MPC-HC as preferred, it's greyed out. What am I doing wrong?

[leeperry]

for the new version! I run 1280*768 96Hz on XPSP3 but the automatic D3D mode reverts to 60Hz...if I want the nvidia drivers to override the default D3D refresh rates I'm forced to run their NT service I think, any chance of keeping the "windowed" refresh rate? I'll try to override it anyway and report back, but this might be a problem when you use several different refresh rates at the same resolution(48/50/59.94Hz in your display native res. for instance)

Originally Posted by Octo-puss

I just installed madVR and have a little problem - I cannot select it in MPC-HC as preferred, it's greyed out. What am I doing wrong?

using MPC x64? can you see madVR in the MPC HC external filters:

[Octo-puss]

Yes x64. Apparently I need to use 32bit version, because there I can normally select it (just tried).

[leeperry]

Originally Posted by Octo-puss

Apparently I need to use 32bit version

You do.

BTW, in FS exclusive mode I cannot get mVR's seekbar to show up...all I get is a black screen, it seems to be conflicting w/ PotPlayer's own transport bar. Hopefully its coder will watch over the problem.

[Alabanda]

I've been using madVR on my laptop (which has ATI 5650 on it) for about a month now, and never experienced a serious problem. Thanks a lot for the hard work madshi! (:
And congratulations for the long-hyped fullscreen exclusive mode, I'll try it later today~

[madshi]

Originally Posted by leeperry

I run 1280*768 96Hz on XPSP3 but the automatic D3D mode reverts to 60Hz...

Then I guess that Direct3D doesn't tell madVR which refresh rate is used in windowed mode on your PC. madVR asks Direct3D and then tells Direct3D to use the same refresh rate in fullscreen exclusive mode. Unfortunately, in my experience, in XP Direct3D often reports a refresh rate of 0. Which means madVR is also setting a refresh rate of 0 in your case, which will result in the default refresh rate being activated, which is probably 60Hz.

I don't have a solution for that right now. When I redesign the settings dialog, I'll give you more control over refresh rates etc. That should fix the problem. Until then there's not much I can do, I think.

Originally Posted by leeperry

in FS exclusive mode I cannot get mVR's seekbar to show up...all I get is a black screen, it seems to be conflicting w/ PotPlayer's own transport bar. Hopefully its coder will watch over the problem.

What do you mean with "a black screen"? Does video not play at all in exclusive mode for you?

I've tested MPC HC and ZoomPlayer and the madVR v0.24 seek bar works in both. Haven't tested PotPlayer.

[sneaker_ger]

Does anyone know a way to not let the GPU/memory frequency increase while using madVR? I'm on a Radeon HD 5850 (switching between Full Range and TV Range works fine on the DVI connector btw.), drivers Cat 10.7a and am mostly watching 720p24 content. When using madVR the cycles increase to 725/1000 from the 157/300 when idling. I could set it to 400/500 (rendering time still < 10ms) using the overdrive settings in the driver, but it will stay that high even when just surfing the web. Any solutions?

[Octo-puss]

Just quickly tried to play one 1080p encode and I must say yay! for madVR. The image is a little bit sharper than when using Haali! Not by much, but even my blind eyes could notice when comparing one frame.

Any plans to support subtitles btw? Like, those muxed into the movie.

[Thunderbolt8]

thanks for the fullscreen mode!

one little request for later: could you please add the current runtime & overall length of the movie to the fullscreen seeking bar?