madVR - high quality video renderer (GPU assisted)

[TheShadowRunner]

Thanks madshi:

"limited DXVA2 decoding to not work on Windows XP"

This fixed software fallback for decoders on WinXP.

But if you don't mind me asking, are there still plans to support DXVA(1) for XP in the future?
I'd like to decode MPEG2 with DXVA while using madVR instead of VMR9 for DVDs..

[DragonQ]

DXVA2 scaling produces different colours to Jinc or EVR for me, probably been mentioned before.

[madshi]

Originally Posted by ajp2k11

Sorry, debug log posted here instead...

https://dl.dropbox.com/u/152596/madVR%20-%20log.zip

Thanks!

Hmmmm... According to the log the fourth backbuffer fails to work for some weird reason. Probably a driver problem. You could try limiting the number of backbuffers for windowed playback to 3. Maybe that will fix playback in windowed mode. Later in the log you seemed to have switched to fullscreen exclusive mode, and according to the log, display seemed to work ok then. Is that correct?

Originally Posted by aufkrawall

Ooops, that was too easy.
Wow, it got huge for a few seconds (>500MB). 7-Zip will be happy.

@madshi: I didn't test upscaling because I don't have any samples with a corresponding fps rate & resolution.
I'd guess that it's probably the same situation like with downscaling.

Here are the logs for the problem:
http://www.mediafire.com/?xbhfc3oow713119

Ouch, that's really big, will look at it later...

Originally Posted by leeperry

I might be doing something wrong! But if that's not the case, improving on the existing PS script support sounds like a great idea but atm getting the exact same colors as with EVR would prove to be extremely useful if any possible please.

Well, I'm still waiting for a reply from Jan-Willem. I think you probably ran EVR with standard settings, correct? Try activating right click -> "Renderer Settings -> Presentation -> Full Floating Point Processing", when using MPC-HC. Unfortunately on my PC that doesn't work at all, maybe it works on yours. Do you then still get the same colors in EVR?

Of course I can match what EVR does. But EVR also cuts BTB and WTW when running custom pixel shaders. Do you want me to do that, too? I hope you get what I'm aiming at: What EVR currently does is not optimal. I think there needs to be a clear standard for custom shaders and I think it currently doesn't exist. So instead of just matching the bad solution EVR currently uses I'm trying to define a standard with Jan-Willem, and if then any adjustments will be necessary to meet that standard, I will do that.

Originally Posted by TheShadowRunner

But if you don't mind me asking, are there still plans to support DXVA(1) for XP in the future?
I'd like to decode MPEG2 with DXVA while using madVR instead of VMR9 for DVDs..

I can't implement DXVA1 because there are no APIs available for that. VMR9 does some nasty things inside to make DXVA1 work which are not documented, anywhere.

Originally Posted by DragonQ

DXVA2 scaling produces different colours to Jinc or EVR for me, probably been mentioned before.

That shouldn't be the case. Have you set all NVidia GPU driver control panel options for colors and video etc to neutral values or to "let application decide"?

Originally Posted by 6233638

This explanation may not be entirely clear (it's very easy to show when actually adjusting a display, for example) but it's an image from CalMAN 5:


From the centre white point to each primary/secondary (outer points of the triangle) you have 25/50/75/100% saturation marked, because saturation is measured as a line from the white point in the centre to the primary/secondary points at the corners of a CIE chart.

The further you get from the white point in the centre to the edges of the triangle, the higher saturation is. (this is why "wide gamut" displays show high levels of saturation) Deviation from that line to either side, is hue error.

On this particular chart (that I just got from a Google search because I'm not at my machine with CalMAN right now) red, green and blue are all somewhat oversaturated, because each measured point (circle) is further from the white point than the target. (white boxes)

Magenta is showing hue errors because the points are twisted towards red, rather than being where they should be on that line.

Luminance (Lightness/Brightness) is the Y axis, which is not visible on that CIE xy chart - it's the third dimension to colour, and is essentially height.

Viewed from the side, a CIE chart would look something like this 3D gamut plot, where Y (luminance) is the height:


A pure saturation adjustment would only move colour along the xy axis in a CIE chart, and Y would remain constant. (or relatively constant, at least)

A chroma control changes both the xy position, and Y, by changing luminance along with saturation.

Ok, that's all fine, but now you're talking about CIE and "luminance" instead of HSL and "lightness". You're not very clear which definition of these words you mean exactly. According to what I've read "Lightness" is usually used by HSL or by LAB, while Luminance is used by CIE XYZ. So which are you talking about? You're not only not clear about this, you're also not consistent with the terms you're using. "Lightness" as defined by HSL is very different to "Luminance" used by CIE XYZ.

Originally Posted by 6233638

Using my previous example:

• The first square is Red at 100% saturation and luminance.
• The second square is Red at 50% saturation and 100% luminance.
• The third square is Red at 100% saturation, but 50% luminance. (note how dark it is)

Sorry, but that's not correct. The 3rd square is Red at 100% saturation, but 50% luma. Luma is not identical to luminance.

Originally Posted by 6233638

That's what makes it a Chroma control - it's reducing both the saturation and luminance of the colour, rather than just the saturation.

But madVR *does* keep the luminance constant and just changes the saturation. So madVR's saturation control is a true saturation control and not a chroma/color control. madVR's saturation control does not keep luma (= gamma corrected Y channel) constant, though, and also lightness (by HSL definition) is not kept constant. Just luminance (= linear light Y channel) is kept constant. Do you see how important it is to use the proper terms and to define which terms you mean exactly with which definition?

Originally Posted by 6233638

From a calibration standpoint, I have to disagree with this. A display's brightness & contrast controls should be used to adjust to the connected device's output levels. (e.g. 0-255 with my PC) These should never be changed after that.

We're not actually disagreeing. We both think that the display's levels should be setup once and only once by using the display's brightness & contrast controls. So, this means that the color controls should not be used to "calibrate" the display. I think we both agree on that.

Originally Posted by 6233638

If you have content which does not conform to these levels correctly (e.g. a video encoded as 30-218) then you should use the player's controls to correct for it, because they will only affect that video, and not how the desktop or other applications are displayed. (and the player's controls are much faster than going into a TV's menus to adjust brightness/contrast for a 30-minute video, and then changing them afterwards)

When changing controls in the media player, it's trivial to use, for example, Q/W to adjust brightness up/down, and hit E to reset them to the default levels. (because most videos should not need adjustment)

Or better yet, having some sort of option to create a custom preset (or multiple presets) in madVR where I can just assign Q to toggle between PC/TV/Custom source levels, which only affect the current video and are not saved. (CTRL+ALT+SHIFT+I by default)

Ok, so you want to use the color controls just to work around incorrectly encoded source files. Correct? I can understand that, but do you really think that "brightness" and "contrast" are the correct names for such a color control? I think the terms "black level" and "white level" would be more appropriate. As a result I do think using the media player's color controls to adjust brightness (= gamma) and contrast (= S-curve, but see below) without changing either black or white levels might make a lot of sense.

I could still add separate black and white level controls which would only be accessible from within madVR and not by the media player, and these controls would auto-reset when madVR loads a new video.

Originally Posted by 6233638

To me, is seems like this sort of adjustment doesn't belong in madVR - at least not replacing the standard brightness or contrast control - because it's making the image less accurate. S-curve gammas are exactly the sort of thing calibration tries to eliminate.

You misunderstood me. I didn't say that the contrast control would try to achieve an S-curve gamma. Not at all. The sigmoidal contrast method works like this:

(1) You convert the image to linear light.
(2) You apply a slight S-curve to adjust image contrast.
(3) You convert back from linear light to gamma corrected light.

You see, this is very different from trying to achieve an S-curve gamma.

[aufkrawall]

Originally Posted by madshi

Ouch, that's really big, will look at it later...

Mabe I accidently played some other videos afterwards.
Will retry and see if it's smaller.

Edit: Ah, no. New file even has 700 MB. ^^

[madshi]

Yeah, the log file grows fast, and with a vengeance.

[ajp2k11]

Originally Posted by madshi

Hmmmm... According to the log the fourth backbuffer fails to work for some weird reason. Probably a driver problem. You could try limiting the number of backbuffers for windowed playback to 3. Maybe that will fix playback in windowed mode. Later in the log you seemed to have switched to fullscreen exclusive mode, and according to the log, display seemed to work ok then. Is that correct?

The windowed backbuffer setting is already at it's default 3? I switched to fullscreen because I wanted that logged too, didn't work either. It seems some files are harder to get to play than others, the one I'm testing with now seems impossible... others work after a while if I leave it alone or switch between windowed and fullscreen a couple of times, at least I think so...

EDIT: Some files play ok but some files just refuse to play...? They play fine using EVR/CP + LAV...

[rahzel]

Originally Posted by madshi

Have you disabled all funny algorithms in the Intel GPU driver control panel? Using DXVA2 always comes with the danger of introducing stupid GPU algorithms.

Ya I did. Guess the driver is doing something else. Will try my AMD rigs now.

Question, does using DXVA2 native actually put more load on the GPU?

[leeperry]

Originally Posted by madshi

Well, I'm still waiting for a reply from Jan-Willem. I think you probably ran EVR with standard settings, correct? Try activating right click -> "Renderer Settings -> Presentation -> Full Floating Point Processing", when using MPC-HC. Unfortunately on my PC that doesn't work at all, maybe it works on yours. Do you then still get the same colors in EVR?

Of course I can match what EVR does. But EVR also cuts BTB and WTW when running custom pixel shaders. Do you want me to do that, too? I hope you get what I'm aiming at: What EVR currently does is not optimal. I think there needs to be a clear standard for custom shaders and I think it currently doesn't exist. So instead of just matching the bad solution EVR currently uses I'm trying to define a standard with Jan-Willem, and if then any adjustments will be necessary to meet that standard, I will do that.

The floating point stuff works for me in EVR, but it's visually identical to the regular mode.

So how come the PS gamut mapping script measures perfectly if everything is crushed like hell? This is confusing =/

IIRC yesgrey once told me that gamut mapping is not dependent on the incoming/outgoing levels.....BUT now that I think of it, when I was comparing this AVS script against tritical's ddcc, these were visually identical! So maybe it's just the new builds of MPC HC that are broken. I was using an old build from Casimir666 that didn't have all those fun(k)y options for EVR CP.

I personally measured the PS gamut mapping script using manual HCFR test patterns and it was all fine, I will try tomorrow with older MPC HC builds and report back. Yay, playing movies on a PC is such a struggle! I can see why some ppl buy a standalone player, a pj with an ISF CMS and call it a day

PS: avishader with the AVS script was also giving me the same colors as ddcc, but source code isn't available apparently.

[TheShadowRunner]

Originally Posted by madshi

I can't implement DXVA1 because there are no APIs available for that. VMR9 does some nasty things inside to make DXVA1 work which are not documented, anywhere.

Arg, but hmm this doesn't help?
DXVA_1.01 API
Or those 2 topics: 1/2 ?

[DragonQ]

Originally Posted by madshi

That shouldn't be the case. Have you set all NVidia GPU driver control panel options for colors and video etc to neutral values or to "let application decide"?

It's set to nVidia Settings, everything in the Colour and Gamma tabs is default but Dynamic Contrast Enhancement and Colour Enhancement are off, with Dynamic Range set to 0-255.

[secvensor]

At switchings between algorithms Jink in v0.85.1 becomes inaccessible:

[6233638]

Originally Posted by madshi

Ok, that's all fine, but now you're talking about CIE and "luminance" instead of HSL and "lightness". You're not very clear which definition of these words you mean exactly. According to what I've read "Lightness" is usually used by HSL or by LAB, while Luminance is used by CIE XYZ. So which are you talking about? You're not only not clear about this, you're also not consistent with the terms you're using. "Lightness" as defined by HSL is very different to "Luminance" used by CIE XYZ.

…

But madVR *does* keep the luminance constant and just changes the saturation. So madVR's saturation control is a true saturation control and not a chroma/color control. madVR's saturation control does not keep luma (= gamma corrected Y channel) constant, though, and also lightness (by HSL definition) is not kept constant. Just luminance (= linear light Y channel) is kept constant. Do you see how important it is to use the proper terms and to define which terms you mean exactly with which definition?

Sorry, most displays and colour management systems swap the terms around and use them interchangeably, so I have a habit of doing that as well.

I've actually just got in and had a chance to actually measure what your control is doing on my displays, and it is exactly what you have said. I misunderstood what it was doing, and it works exactly as intended - it reduces saturation while keeping luminance constant - a true saturation control.

Sorry for this big waste of your time.

Originally Posted by madshi

Ok, so you want to use the color controls just to work around incorrectly encoded source files. Correct? I can understand that, but do you really think that "brightness" and "contrast" are the correct names for such a color control? I think the terms "black level" and "white level" would be more appropriate.

I agree that the terms "black level" and "white level" would be more appropriate, and on most displays, these controls are labelled "brightness" and "contrast".

Originally Posted by madshi

As a result I do think using the media player's color controls to adjust brightness (= gamma) and contrast (= S-curve, but see below) without changing either black or white levels might make a lot of sense.

I could still add separate black and white level controls which would only be accessible from within madVR and not by the media player, and these controls would auto-reset when madVR loads a new video.

I think this would be an excellent solution. It may cause some confusion for people used to traditional "brightness" and "contrast" controls, but as long as you have some kind of black & white level controls inside madVR as well, I think it will work well.

Originally Posted by madshi

You see, this is very different from trying to achieve an S-curve gamma.

Again, I'll trust your judgement on this. My area of expertise is generally in actually calibrating and evaluating displays, and less-so in terms of image processing.

I'm still not fond of "image enhancement" processing, rather than trying to achieve the most accurate calibration, but it doesn't sound like a bad control to have for people that want it.

[rahzel]

Originally Posted by DragonQ

It's set to nVidia Settings, everything in the Colour and Gamma tabs is default but Dynamic Contrast Enhancement and Colour Enhancement are off, with Dynamic Range set to 0-255.

Using madVR DXVA2 on my Radeon 5570 also shows different colors compared to software decoding, DXVA2-CB and using EVR CP DXVA. Only madVR DXVA2 native makes colors look different (judging by the screenshots taken by MPC HC anyway). All of my 'enhancements' in the drivers are either disabled or set to application preference. Using LAV 0.53.2 with the default LAV video decoder settings.

[cyberbeing]

Originally Posted by madshi

Defaults...Catmull-Rom AR with Linear Light for downscaling

This isn't exactly a safe default from a performance perspective on weaker GPUs with 60fps content or when deinterlacing. On my GT440 using either AR or Linear for Image downscaling on such content is a no-go, which is why I switched to using normal Spline36 Image downscaling awhile back.

With my GT440 DDR5 & 1920x1080p60 (16.68ms/frame) @50%:

Catmull-Rom Image + Bilinear Chroma: 7.8ms render avg
Spline36 Image + Catmull-Rom Chroma: 10.6ms render avg
Catmull-Rom (AR) Image + Bilinear Chroma: 12.6ms render avg
Catmull-Rom (Linear) Image + Bilinear Chroma: 12.6ms render avg
Catmull-Rom (AR + Linear) Image + Bilinear Chroma: 100% GPU Load & Constant Dropped Frames


With my GT440 DDR5 & 1920x1080i30->60p (16.68ms/frame) @50%:

Catmull-Rom Image + Bilinear Chroma: 7.8ms render avg + 2.3ms deinterlace
Spline36 Image + Catmull-Rom Chroma: 10.6ms render avg + 2.3ms deinterlace
Catmull-Rom (AR) Image + Bilinear Chroma: 90-100% GPU Load & Occasional Heavy Dropped Frames
Catmull-Rom (Linear) Image + Bilinear Chroma: 90-100% GPU Load & Occasional Heavy Dropped Frames
Catmull-Rom (AR + Linear) Image + Bilinear Chroma: 100% GPU Load & Constant Dropped Frames

I'm not insisting that you should change the defaults again, but it definitely something for users to keep in mind if they are having performance issues when downscaling 1920x1080 60fps with the new defaults. More powerful GPUs like the GTX 660 which a few have been recommending here recently, I'm sure has plenty of performance to be unaffected.

[crotecun]

Originally Posted by rahzel

Using madVR DXVA2 on my Radeon 5570 also shows different colors compared to software decoding, DXVA2-CB and using EVR CP DXVA. Only madVR DXVA2 native makes colors look different (judging by the screenshots taken by MPC HC anyway). All of my 'enhancements' in the drivers are either disabled or set to application preference. Using LAV 0.53.2 with the default LAV video decoder settings.

With AMD Catalyst you also have to disable everything in the video quality settings, not just video color.

Another way to make sure the drivers don't do anything funny with the video output is to rollback to the WHQL drivers from microsoft update. If you uninstall your Catalyst drivers, windows update will rollback to the latest approved drivers for Radeon HD 5xxx cards (version 8.850 from April 2011).

As far as I can tell this does not tweak the video output since you don't have the Catalyst control panel.

[mindbomb]

oh, wow.
this is amazing.

[rahzel]

Originally Posted by crotecun

With AMD Catalyst you also have to disable everything in the video quality settings, not just video color.

Another way to make sure the drivers don't do anything funny with the video output is to rollback to the WHQL drivers from microsoft update. If you uninstall your Catalyst drivers, windows update will rollback to the latest approved drivers for Radeon HD 5xxx cards (version 8.850 from April 2011).

As far as I can tell this does not tweak the video output since you don't have the Catalyst control panel.

Ya, everything in the video quality settings is disabled, too. And again, EVR CP + DXVA doesn't change the colors. As shown in my screenshots a page back, my HD4000 seems to change the gamma a bit, too.

The good news is that it does indeed work. CPU usage dropped from ~30% or ~8% on my somewhat dated HTPC (AMD Athlon II 250 + Radeon 5570).

[ajp_anton]

Green line at the top of the screen when using DXVA scaling and any kind of decoding, including madVR's own.

http://ajpanton.se/sample.mkv

Win7 x64, MPC-HC 6240, Intel HD3000.

[6233638]

Originally Posted by cyberbeing

This isn't exactly a safe default from a performance perspective on weaker GPUs with 60fps content or when deinterlacing. On my GT440 using either AR or Linear for Image downscaling on such content is a no-go, which is why I switched to using normal Spline36 Image downscaling awhile back.

I thought this was quite interesting, and decided to have a look at performance in general, rather than just downscaling, under a number of different conditions.

First, I wouldn't recommend anyone use CUVID decoding any more. It forces the GPU into its high power state (P0) regardless of load, and has measurably higher GPU, MCU, and VPU load compared to the DXVA2 options in LAV Video.


To my surprise, whether my card was locked to slower clockspeeds or not (Nvidia Inspector can force the GPU into the P0/8/12 states, and alter their clockspeeds) DXVA2 copy-back had lower VPU load than DXVA2 native in all my tests. In some cases, this was as much as 20%, though it was typically in the 5–10% range.

MCU load was the same with both DXVA options, though there was a 2% increase in GPU load when using DXVA2 copy-back rather than native. Negligible for me, but perhaps not with a slower card.

DXVA2 native appeared to have zero impact on the GPU load, measuring the same as software decoding on the CPU though.


In most cases, even though VPU load could be as much as 20% higher with DXVA2 native, it was typically not the limiting factor for video playback. Any of the samples I tried which failed to play back smoothly due to the higher VPU load of DXVA2 native also failed with DXVA2 copy-back, but with less dropped frames. On another GPU that extra 20% might be the difference between smooth playback and constantly dropping frames though. I don't know whether Nvidia use the same VPU across their entire product range, or if it also scales in performance along with the GPU itself. It definitely seems like it might be worth trying both DXVA2 native (lower GPU load) and DXVA2 copy-back (lower VPU load) on clips that are giving you trouble, to see if switching from one to the other helps.


I was also able to find some samples that, at least when locked to a lower power state (to simulate being on a slower GPU) VPU load, whether using DXVA2 copy-back or native, was the cause of dropped frames, and that switching to CPU decoding allowed for smooth playback, even with some of the more intensive scaling algorithms.


With the most demanding video I could find, a 1080p60 clip of Avatar, even my GTX570 was barely able to decode it, as the peak VPU load was 89% for DXVA2 copy-back, and 94% for both DXVA2 native & CUVID. So it's certainly possible that with high framerate clips, a card with a slower VPU on it might need to use CPU decoding instead of DXVA.



Unfortunately it seems that when downsampling, the biggest performance hit is linear light scaling. When my card was set to the lowest power state, I found that I was able to use Lanczos 3 for downscaling, but couldn't use Catmull-Rom linear, even without the anti-ringing filter. So perhaps an option with linear light scaling enabled doesn't make for the best default, even though Catmull-Rom is typically one of the less demanding scaling algorithms.

The problem is that when downsampling images, ideally you should be using linear light scaling if at all possible.
Even though Catmull-Rom is actually one of the least demanding scaling algorithms in madVR right now, it happens to be the best looking when downsampling in linear light, as long as you have the anti-ringing filter enabled. If your GPU can't handle that combination though, I wouldn't recommend using linear light scaling at all.

I don't know what I would recommend other than that. Lanczos seems to be a common choice, and it's definitely less work on the GPU than linear light scaling.
For the same GPU load as Lanczos, you may be able to use a less intensive scaler in conjunction with the anti-ringing filter though.
I'm not really sure which would look best, as downsampling is not really a priority for me, and all of the comparisons I've done recently have been with both the linear light scaling and anti-ringing options enabled.



So I'm not sure what conclusion to draw from all this. If your problem is specifically with 60fps content, the first thing I would try is switching to software decoding on the CPU to see if that helps (assuming your CPU is up to the task) but it does seem most likely to be a GPU load issue, unfortunately.

Originally Posted by ajp_anton

Green line at the top of the screen when using DXVA scaling and any kind of decoding, including madVR's own.

http://ajpanton.se/sample.mkv

Win7 x64, MPC-HC 6240, Intel HD3000.

Can't reproduce that here on my GTX 570, so it doesn't appear to affect Nvidia.

[Aleksoid1978]

madshi hi.
Question - how can I find out which mode is currently using in madVR - DXVA or not. MPC-BE for internal DXVA compatible renderer use Hook to detect DXVA mode. Maybe you add api call for this ?

If not - do not worry, have also made ​​also use a hook