madVR - high quality video renderer (GPU assisted)

[madshi]

So what is the implication of this new DXVA mode? Does this mean we can get hardware decoding plus high-quality MadVR scaling? Would the scaling still be done in software?
Yes, basically you can get hardware decoding + high-quality madVR scaling. But you were able to get that before already by using LAV Video Decoder with copy-back. So the major improvement is that the whole "copy-back" trick isn't needed, anymore, which didn't work so well for older AMD cards. Scaling was never done in software by madVR. It was always done via hardware pixel shaders.

[DragonQ]

Yes, basically you can get hardware decoding + high-quality madVR scaling. But you were able to get that before already by using LAV Video Decoder with copy-back. So the major improvement is that the whole "copy-back" trick isn't needed, anymore, which didn't work so well for older AMD cards. Scaling was never done in software by madVR. It was always done via hardware pixel shaders.
OK, thanks for the explanation.

[nevcairiel]

MediaPortal is actually incapable to actually show the properties dialog of the currently running filter. Below the drop-down box is another text field which lists the active decoder, it should say "dxva2n" for DXVA2 Native decoding, and "avcodec" for software - if you watch the wrong property page, it will just say "<inactive>". :p

Edit:
You sneakely edited something out, i saw it clearly!

[DragonQ]

Ha yeah, I was talking about MPC-HC but it turned out to just be one type of file (576i) that wasn't using DXVA2, other files (e.g. 1080p) show it's being used. :)

MediaPortal doesn't support MadVR anyway, sucks really cos EVR is terrible for banding on TV material.

Never really looked at the upscaling algorithms much...looks like my GTS250 can handle Jinc3/Jinc3/Lanczos3 but can't handle the same with anti-ringing.

[aufkrawall]

Uhm, what to do after enabling debug mode and reproducing the problem?
I suppose there must be debug logs somewhere...

[nevcairiel]

look on your desktop.

[Alabanda]

Just wanted to say congratulations on reaching this milestone, madshi. Having recently changed my setup from a measly AMD E350 APU + 17" 4:3 ancient LCD to Nvidia GTX660 + 24" 16:10 IPS LCD (Dell U2412M), I throughly enjoy your (and also Nev's) efforts. Jinc is wonderful, and (a late discovery by my part) the display modes setting is a lifesaver. (I can finally satisfy ReClock.)

[ajp2k11]

Madshi,

debug log as requested.

Thanks!

Sorry, debug log posted here instead...

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

Thanks!

[aufkrawall]

look on your desktop.
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

[leeperry]

That's what I thought, too, but after talking to Jan-Willem about it, I'm not so sure, anymore. He's saying that scripts do work in 0-255 when using 8bit textures, but in that case BTB and WTW are clipped. He says when using higher quality textures, the shaders run in 16-235 instead, but in XYZ color space. I'm not sure yet if I understood him correctly, though. Still waiting for confirmation. I think there should be an official spec for which colorspace and levels custom shaders run in. Maybe we'll have to create that spec, if it doesn't exist yet.

I've been killing time until PotP would support PS script with mVR, comparing screenshots between EVR/mVR/HR with the 6240 MPC build using the test pattern attached to this post(mediafire refuses to accept it and they've killed all my previous uploads of it, lemme know where else I could upload it if need be).

I could never get the same colors in mVR when using YV12 so I decided to output RGB32HQ from ffdshow, I've also disabled all color conversions in mVR.

That's without processing:

-EVR http://thumbnails103.imagebam.com/22180/9cf827221791316.jpg (http://www.imagebam.com/image/9cf827221791316) -HR http://thumbnails102.imagebam.com/22180/39a292221791319.jpg (http://www.imagebam.com/image/39a292221791319) -mVR http://thumbnails103.imagebam.com/22180/ef090a221791303.jpg (http://www.imagebam.com/image/ef090a221791303)

They're all identical :)

And that's with the stock "nightvision script" set on post-scaling, and this is:

-EVR http://thumbnails104.imagebam.com/22180/337c0a221791307.jpg (http://www.imagebam.com/image/337c0a221791307)
-mVR with my display set to 0-255 http://thumbnails106.imagebam.com/22180/705403221791312.jpg (http://www.imagebam.com/image/705403221791312)
-mVR with my display set to 16-235 http://thumbnails101.imagebam.com/22180/341b17221791315.jpg (http://www.imagebam.com/image/341b17221791315)

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.

:thanks:

[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]

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?

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...

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.

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.

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"?

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:
http://www.abload.de/img/201206224vo7p.jpg

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:
http://www.abload.de/img/prophotovsargbttken.jpg

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.

Using my previous example:
http://www.abload.de/img/slcpvsj5.png

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.

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?

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.

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.

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]

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]

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]

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]

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 :p

PS: avishader (http://forum.doom9.org/showthread.php?t=86793&page=2) with the AVS script was also giving me the same colors as ddcc, but source code isn't available apparently.

[TheShadowRunner]

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 (http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/DXVA_1.01.doc)
Or those 2 topics: 1 (http://social.msdn.microsoft.com/Forums/en-US/mediafoundationdevelopment/thread/ca7b767f-4773-4072-be25-6d74a3adaf9d/)/2 (http://social.msdn.microsoft.com/forums/en-US/mediafoundationdevelopment/thread/0fdc2b5d-2a02-4f3e-9118-a7c6bfe09287/) ?

[DragonQ]

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:
http://i47.fastpic.ru/big/2012/1123/ad/10f65c696b0ade17b5493e4c632fddad.png

[6233638]

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. :o

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".

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.

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]

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]

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]

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]

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]

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.


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 :)

[crotecun]

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).

Is that so... well then, try the rollback method for your card! It's what I did just now since I couldn't quite tell whether disabling everything for video color and quality in AMD Catalyst control center really does disable everything.

To be sure that it doesn't keep any Catalyst control center settings, you have to uninstall the video card driver too.

http://i.imgur.com/rYgjBl.png

That way it wipes the registry entries for your video card in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video. When the operating system automatically reinstalls the video drivers when your restart your PC, it would give you a clean slate without any Catalyst settings.

Before, with Catalyst control panel installed - left side is the unaltered video, right side is with all the Catalyst video color and quality settings on:

http://i.imgur.com/UemMvl.jpg (http://imgur.com/UemMv)

After, with Catalyst control panel uninstalled, video card drivers uninstalled from device manager and registry settings wiped:

http://i.imgur.com/TYWGYl.jpg (http://imgur.com/TYWGY)

[mindbomb]

with amd drivers, even with the color settings set to use player's preference, the advanced video color still defaults to having a bunch of crap on.
and, with amd, I have crashes on seeking, using lav splitter, dxva2 with bilinear chroma, in fullscreen mode.

[huhn]

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.

dxva2 scaling works fine with hd 4000
tested with quicksync, dxva2 native, dxva2 cp and lav software decoder

[Gary.M]

But let's get back to the roots: Do we really want to replicate what old CRTs did? Does it not make more sense to design the controls today in such a way that they serve their purpose better?

No we don't, but the situation is the same... we need to adjust the range somehow without distorting the greyscale. Maybe look at it, based on my graph, as brightness - adjust slope of line with current white point fixed as the pivot. Contrast - adjust slope of the line with current black point fixed as the pivot. That we we get a full range of adjustment, independence between black and white points and controls, and the greyscale isn't mucked up.

Sorry I'm an analogue guy.

[cyberbeing]

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.

I never have used GPU decoding and always have my GPU overclocked in a full-power state.

The only conclusion is that the GT 440 DDR5 (16-19ms rendering times) and lesser GPUs in full-power state, not having enough muscle for 1920x1080p60 Catmull-Rom linear light + AR downscaling. As for 1920x1080i30->60p downscaling, I'd assume it would need at least a GT 650 or GT 650 TI in full-power state, considering rendering times were 21-31ms + 3ms on the GT 440. It came to a point that I'd rather have reliable playback on all types of content, rather than needing to deal with switching of settings around all the time, else be greeted by unexpected dropped frames.

As madshi stated a few times in the past, downscaling is more GPU intensive than the same algorithm used for upscaling.

[ryrynz]

I noticed enabling DXVA upscaling on my Intel HD4000 changes the color output, some colors are darkened some are lightened, everything under the media tab is set to application settings or is unticked. There's a slight pixel shift as well *shrug*

DVXA upscaling vs Jinc 3 AR.

http://screenshotcomparison.com/comparison/159646

[TheLion]

I noticed enabling DXVA upscaling on my Intel HD4000 changes the color output, some colors are darkened some are lightened, everything under the media tab is set to application settings or is unticked. There's a slight pixel shift as well *shrug*

DVXA upscaling vs Jinc 3 AR.

http://screenshotcomparison.com/comparison/159646

In this comparison the DVXA looks ALOT better than madVR Jinc3 to my eyes. I am especially talking about the color/contrast differences. Is the same color matrix used?

[madshi]

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...
Ah sorry, I misread the log file. Just checked it again. The problem is not actually the number of backbuffers. The real problem is that the GPU driver is flat out refusing to provide madVR with proper VSync scanline information. I'm not sure why. Does your laptop have switchable Intel + AMD graphics? If so, does the problem go away if you turn the AMD GPU off? Or can you alternatively turn the Intel GPU off? I'm not sure what to suggest. madVR requires access to proper VSync scanline information in order to be able to draw the video frames at the right time. I would guess there's a problem with your drivers somehow...

The floating point stuff works for me in EVR, but it's visually identical to the regular mode.
Oh, interesting. That somehow differs from how I understood Jan-Willem.

So how come the PS gamut mapping script measures perfectly if everything is crushed like hell? This is confusing =/
I never said anything was crushed like hell. I just said that with standard settings, using custom shaders with EVR cuts BTB and WTW. That's not a *big* problem, it's probably not visible at all on a properly calibrated display, but I still consider it wrong. Anyway, please just have a bit of patience. As I hinted several times already, I'm still in discussion with Jan-Willem about this.

Arg, but hmm this doesn't help?
DXVA_1.01 API (http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/DXVA_1.01.doc)
Or those 2 topics: 1 (http://social.msdn.microsoft.com/Forums/en-US/mediafoundationdevelopment/thread/ca7b767f-4773-4072-be25-6d74a3adaf9d/)/2 (http://social.msdn.microsoft.com/forums/en-US/mediafoundationdevelopment/thread/0fdc2b5d-2a02-4f3e-9118-a7c6bfe09287/) ?
All of that talks about how to write a DXVA1 decoder, not a renderer. Writing a DXVA1 decoder is not the problem. You just connect to VMR and provide all the bitstream to VMR. But if a DXVA1 decoder connects to madVR and delivers the DXVA1 bitstream packages to madVR, I don't know what to do with it. It's not documented anywhere how VMR passes the DXVA1 bitstream packets to the GPU for decoding, so I don't know how to do that.

Anyway, DXVA decoding on XP is problematic, anyway. It's always been very unstable (blue screens etc) on my XP PC. And there's a fundamental problem when resizing the window, too. Resizing the window results in madVR trying to reset the D3D9 device, but in XP that is only possible if all GPU resources are destroyed first. That makes things very very complicated when using external DXVA decoders, because they hold some GPU resources, as well. In Vista (and win7 and win8) resetting the D3D9 device is possible without having to destroy all GPU resources first. So that's a much more friendly environment for DXVA decoding. As a result I have no intentions to support DXVA1/2 decoding on XP at all. Even if suddenly documentation for writing a DXVA1 renderer showed up, I'd probably not support it for XP because of the D3D9 device reset problem. FWIW, I fully support DXVA2 deinterlacing and scaling on XP and it works very stable for me. But right now chances for getting DXVA1/2 decoding support for XP are extremely low for madVR users.

At switchings between algorithms Jink in v0.85.1 becomes inaccessible
I've tried, but I can't seem to reproduce this. Can you please provide me with a step-by-step instruction to reproduce this problem? Thanks!

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.
Cool, it's good to be on the same page again, and we can put this to rest now.

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.
Great! Seems we've found a solution now which should satisfy most people.

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.
I'm not really a fan of that, either, but I've been told by several users that their displays lack important controls and so sometimes it can be useful to have such controls in madVR instead. Of course the recommended setting for all these options will be "neutral".

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.
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.
Originally I was planning to use DXVA2 scaling as the new default option, because that should (hopefully) run smooth on even rather slow GPUs. But then with the original v0.85.0 DXVA2 scaling wasn't working well at all, so I decided to use different defaults. But now with v0.85.1 DXVA2 scaling seems to work fairly well and it seems that the scaling algorithms offered by Intel especially, but maybe also by ATI and NVidia might be acceptable as a default option for budget GPUs. What do you think? I would really like the first impression of new users to be positive. It can't be positive if the first impression is that madVR produces a slide-show. So maybe using DXVA2 scaling as default option might be a good idea?

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 :)
No problem, I can add an interface for that.

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.
Which "target rectangle" does the madVR debug OSD (Ctrl+J) show when the green line shows up? Does the green line appear no matter which zoom factor you're using? Does it occur with every video, or just with some? Tnx.

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.
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.
I noticed enabling DXVA upscaling on my Intel HD4000 changes the color output, some colors are darkened some are lightened, everything under the media tab is set to application settings or is unticked. There's a slight pixel shift as well *shrug*

DVXA upscaling vs Jinc 3 AR.

http://screenshotcomparison.com/comparison/159646
Can you guys please test the following:

(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

The reference is (1) for colors, brightness, contrast and gamma. This is how the image must look. Please check which of (2), (3) and (4) are different from the reference and which are identical. Also please check if maybe (4) is even more different than (2) and (3) are.

(I don't need screenshots.)

Please also list your GPU, your drivers, and your OS.

Thank you!!!

In this comparison the DVXA looks ALOT better than madVR Jinc3 to my eyes. I am especially talking about the color/contrast differences. Is the same color matrix used?
The scaling algorithm itself (e.g. Jinc vs. Bilinear) does not have any effect on color/contrast. I'm just saying that to clarify that the DXVA2 scaling algorithm itself isn't better than Jinc. It just happens that the colors look different when using DXVA2 for some reason. This could be a bug in madVR, or a misbehaviour of the GPU drivers. In any case, the DXVA2 colors are very very likely to be incorrect. It's just a happy accident that they might look pleasing in this specific case.

[cyberbeing]

On my GT 440, DXVA2 scaling seems to be Bilinear, yet with blurry misaligned (centered pos instead of left pos?) chroma, so I don't really think that's a great default either.

[madshi]

Even with v0.85.1, it's Bilinear for you? That's disappointing...

[romulous]

I'll put this on my list of things to look it. For now I'm more concerned about fixing all the new bugs with DXVA2 decoding and scaling first.

Thanks madshi, much appreciated!

[leeperry]

Oh, interesting. That somehow differs from how I understood Jan-Willem.

I never said anything was crushed like hell. I just said that with standard settings, using custom shaders with EVR cuts BTB and WTW. That's not a *big* problem, it's probably not visible at all on a properly calibrated display, but I still consider it wrong.
I just compared:
-EVR CP in PotP
-VMR9 in an old build from Casimir666 released in 2007 (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC%20v1.0.11.0%20_%2032%20bits/)
-EVR CP in the recent 6240 MPC build, whatever in regular or float mode

= they all give identical colors with the nightvision script on my rec709 video test pattern!

so if BTB/WTW are trimmed, it all remains a big mystery to me as to why the AVS PS script outputs the exact same colors as ddcc():

untouched: http://thumbnails8.imagebam.com/956/b5e6859555408.gif (http://www.imagebam.com/image/b5e6859555408)

AVS PS script: http://thumbnails8.imagebam.com/956/3498ff9555409.gif (http://www.imagebam.com/image/3498ff9555409) ddcc: http://thumbnails8.imagebam.com/956/9a4b919555410.gif (http://www.imagebam.com/image/9a4b919555410)

there are some slight R/G/B differences in the <16 and >235 regions but these might account for different gamma curves or slightly different coeffs...nothing appears to be "cut" :o

[cyberbeing]

Even with v0.85.1, it's Bilinear for you? That's disappointing...

Definitely is Bilinear, but slightly worse quality than the madVR implementation. The only improvement I see from v0.85.1, is that DXVA2 scaling no longer crops off a portion of the frame.

[madshi]

I just compared:
-EVR CP in PotP
-VMR9 in an old build from Casimir666 released in 2007 (http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC%20v1.0.11.0%20_%2032%20bits/)
-EVR CP in the recent 6240 MPC build, whatever in regular or float mode

= they all give identical colors with the nightvision script on my rec709 video test pattern!

so if BTB/WTW are trimmed, it all remains a big mystery to me as to why the AVS PS script outputs the exact same colors as ddcc()
Maybe you don't understand what BTB/WTW are or what purpose they have? If BTB/WTW are cut, that has no effect whatsoever on the "valid"/visible colors.

Anyway, could you please give this finally a rest? I've told you many times, this topic is still under discussion between the devs. I will not do anything about this until the discussion has finished. Posting any more about this really doesn't make any sense right now.

Definitely is Bilinear, but slightly worse quality than the madVR implementation.
Too bad.

So, suggestions for madVR default scaling settings, anyone? I'd like to aim low. Maybe I should be brutal and set everything to bilinear to achieve smooth results on any GPU for first time users? But that would be too extreme, I guess...

[kasper93]

@crotecun:
Using old Microsoft drivers is just wrong :< And you don't need to uninstall CCC in order to disable video enhance features. Just disable everything and turn off demo mode, and that's all.

[leeperry]

If BTB/WTW are cut, that has no effect whatsoever on the "valid"/visible colors.
Well, I was feeding full range 0-255 RGB32 to this PS script so if <16 and >235 were harmed, this would show...and it does not, that's my point. It's virtually identical to the 0-255 RGB32 test pattern that was fed to ddcc().

[Prinz]

So, suggestions for madVR default scaling settings, anyone? I'd like to aim low. Maybe I should be brutal and set everything to bilinear to achieve smooth results on any GPU for first time users? But that would be too extreme, I guess...

Don't know what it's a good default setting. I can only say I have to set everything to bilinear or my GPU (ATI 2600 XT) will drop frames with some videofiles.

[CiNcH]

* added support for media player color controls (IVMRMixerControl9)
* added support for "IQualProp" interface for media player statistics display
Is there a complete list of MS interfaces that you support somewhere?

[ryrynz]

In this comparison the DVXA looks ALOT better than madVR Jinc3 to my eyes. I am especially talking about the color/contrast differences. Is the same color matrix used?

Yup, I'll agree some areas look more saturated and "better" but overall I don't like it mostly because of how overly sharp it is, I'll continue to use Lanczos 3 AR over DXVA.

Don't know what it's a good default setting. I can only say I have to set everything to bilinear or my GPU (ATI 2600 XT) will drop frames with some videofiles.

Once again falling into final stage fine-tuning but having MadVR perform a benchmark and auto selecting a preset would be quite cool.

[madshi]

Well, I was feeding full range 0-255 RGB32 to this PS script so if <16 and >235 were harmed, this would show...and it does not, that's my point.
You fed full range 0-255 RGB32 to the *renderer*, not to the PS script. IIRC, MPC-HC's EVR and VMR treat all RGB input as fullrange by default, so your test didn't really say anything about BTB/WTW at all. It would have been a useful test only if the <16 and >235 areas of your test pattern were treated as BTB/WTW by the renderer, but they were not, I believe. Try feeding 16-235 RGB to MPC-HC's EVR/VMR and you'll see that black turns gray, proving that with RGB input, MPC-HC's EVR/VMR renderers expect BTB and WTW <0 >255, so basically with RGB input there never is any BTB/WTW.

If you want to really test whether BTB and WTW are cut with EVR with default settings, just apply the following 2 scripts after each other, with no other scripts: (1) "16-235 -> 0-255", (2) "0-255 -> 16-235". Then feed RGB with a gray scale. If BTB and WTW are cut, the darkest gray you should get is 16,16,16. If BTB and WTW are not cut, you should get 0,0,0. And this is exactly what happens with EVR on my PC. EVR produces 16,16,16. madVR maintains the full range down to 0,0,0.

Anyway, as I said about a dozen times now, and as I have already said right in the very v0.85.0 release notes, the levels custom shaders run in are still under discussion. So it really doesn't make much sense to discuss it here in the forum now.

Don't know what it's a good default setting. I can only say I have to set everything to bilinear or my GPU (ATI 2600 XT) will drop frames with some videofiles.
So you get drops with bilinear but not with more demanding scalers? That's weird...

Is there a complete list of MS interfaces that you support somewhere?
Hmmmm... Good question. Probably if you search through the changelog. But let me check the source code. Here you go:

- ISpecifyPropertyPages
- IVideoWindow
- IBasicVideo
- IBasicVideo2
- IKsPropertySet
- IVMRMixerControl9
- IQualProp
- IMFGetService -> IDirect3DDeviceManager9, IDirectXVideoMemoryConfiguration

There might be some more supported by the Microsoft base classes madVR is building on, but I don't think so. If media player devs need more MS interfaces than those listed above, I'm willing to put that on my to do list.