madVR - high quality video renderer (GPU assisted)

[rahzel]

Thanks for your answers, madshi.

Haven't tried my AMD rig yet, but on my HD4000 Intel, I'm noticing a small difference in gamma using DXVA2 native (LAV 0.53.1) vs the other decoders.

First screen is DXVA2 native, then the others it doesn't really matter as they're identical, but they're either Quicksync, DXVA2-CB or LAV software decoding.
http://imgbox.com/g/ABn4hB4zBf

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

[robpdotcom]

Not sure if this is a bug or a limitation, but the IVTC filter does not work with DXVA2 decoding. In fact, I cannot even toggle to "film mode" using the keyboard shortcut.

[crotecun]

Originally Posted by madshi

madVR v0.85.1 released

http://madshi.net/madVR.zip

* fixed: corruption on bottom image border with native h264 DXVA2 decoding
* fixed: DXVA2 scaling didn't work correctly
* fixed: color controls resulted in washed out image with J.River MC
* small DXVA2 decoding stability improvement
* limited DXVA2 decoding to not work on Windows XP
* limited DXVA2 decoding to not work when using the old FSE mode
* custom shaders are now compiled with wanted profile instead of always ps_3_0
* added "[DXVA2]" to debug log when DXVA2 decoding is used

Please retest DXVA2 scaling, it should be a lot different now compared to before. No more "scaling failed" and no more point resampling with AMD and Intel. Also probably better scaling quality with NVidia now.

Hooray, scaling in DXVA2 now works as expected

And yes, the video settings in the GPU control panel do affect the output.

On my video card I can easily see the difference by turning on demo mode to split screen in AMD Catalyst settings --





I wonder how much different it would like on an Intel or Nvidia card

[ajp_anton]

"New" default scalings + LAV/QS: ~17.5W
All bilinear scaling + QS: ~15.0W
DXVA scaling + QS: ~14.0W
DXVA scaling and decoding: ~13.0W
EVR-CP with any scaling: ~12.5W (<-chroma looks horrible)
EVR: ~12.0W

i7-2600k, HD3000, looking at the whole CPU package power. Upscaling from 720p to 1440p.
DXVA scaling looks a little sharper than lanczos3, but haven't made any more detailed comparisons.

[ajp2k11]

Originally Posted by ajp2k11

I installed Win8 on my laptop a few days ago and since then I'm having trouble with MadVR in MPC-HC. Never hade any problems on Win7.

Playback starts but the screen is black and I hear audio. Sometimes the picture appears after I while or if I maximize/minimize the player a few times, maybe it's just a coincident. Some files are harder to get to play than others. MPC-HC with just EVR/CP and LAV filters on their own work fine...

My laptop has a Radeon HD6650M with Catalyst 12.10...

Suggestions?

Madshi,

debug log as requested.

Thanks!

[aufkrawall]

The bars are gone, nice & thanks.

But now I have another problem:
madVR fails to correctly enter FSE if there's a display mode change at the same time when DXVA2 downscaling is selected.
It's reproducible to me. Doesn't happen with other downscale methods.

[6233638]

Originally Posted by madshi

MPC-HC does not have a color control dialog, but you can assign keys to increase/decrease brightness, contrast and saturation (but not hue), and to reset the color controls to standard values.

Got it. I only tried adjusting the Nvidia settings because that was all I could find which changed the image.

Using the MPC-HC controls, they are not working correctly. Or at least, not how everyone else does it - I do think your usage is more accurate, but it will confuse anyone familiar with how the brightness/contrast controls work on anything else.

+contrast should be −brightness
−contrast should be +brightness

+brightness should be +contrast
−brightness should be −contrast

+saturation should be called +colour or +chroma
−saturation should be called −colour or −chroma

But I guess the "saturation" label isn't something you can change, and that would be up to the MPC-HC devs. (I don't think you should change how "saturation" is working in madVR)

I've also noticed that when using the "DXVA2" scaling option, the controls can be quite unresponsive and cause a large number of dropped frames. (fine with any other scaling option)


Am I correct in thinking that the brightness/contrast controls only affect either the white/black points, and are not stretching the range?

i.e. −contrast under your naming scheme is only raising black from say 16 to 20, and leaves white at 235 rather than also reducing it by a similar amount at the same time. (say to 230)


I actually think that it would be useful to have a control that adjusted both black level and white level by the same amount to fix videos which have been encoded with the wrong levels settings (sometimes a video is recorded at 16-235 but gets encoded at 30–218 for some reason) but that's not what people would expect the brightness/contrast controls to do.

I do wish there was an option to add some custom levels presets or something inside madVR rather than manually adjusting brightness/contrast for each video though. Being able to switch between "PC Levels", "TV Levels", and "Custom 1", "Custom 2" etc. would be very useful. (or at least PC, TV, and 30-218)

Originally Posted by madshi

I still don't understand the difference between "chroma" and "saturation" control. Whose definition are you refering to? You're talking about a "full HSL color system" as if that would be the best solution, while in reality HSL is total crap. So if your definition of chroma vs saturation control is based on HSL then please throw your definition out of the window and forget about it as fast as possible. If your definition of "saturation" vs. "chroma" is based on something other than HSL, then please let me know where I can read about the difference between "saturation" and "chroma" control.

Most colour management systems now use RGBCMY HSL controls to adjust things. It's a far easier way to calibrate the display because you can use dE'94 to split the colour error into its hue/saturation/lightness components and allows you to adjust each aspect individually. HSL controls allow you to dial in a display much quicker than any other method.

RGBCMY HSL controls (or xyY) are exactly what yCMS needs to adjust the LUT if the calculated points are not correct. (although personally I would rather just directly enter RGB output values, similar to when you write a custom LUT for some hardware LUT boxes)

A chroma control adjusts both saturation and lightness of a colour at the same time, and is considerably less useful in calibration. A chroma control is probably what most people would expect from something like this however, so your "linear saturation" implementation is fine there. (but it's technically a "chroma" control rather than a "saturation" one)

Originally Posted by madshi

I already answered that before:

"It has always been this way when madVR comes in *direct* contact with any DXVA2 output. DXVA2cb/CUVID don't count as direct contact"

Sorry, I just wasn't 100% sure on whether this was a madVR specific issue, or one with DXVA. I thought that it was a DXVA issue and that LAV Filters using copy-back would be similarly affected.

Originally Posted by madshi

You do have a point. Putting black & white level adjustments controls in the madVR device setup might make more sense because you can set them there per monitor. True brightness & contrast controls which don't change black nor white levels might be better choices for the media player color controls. I guess brightness could simply be changed by changing the gamma curve. For contrast I also have an algorithm which doesn't modify black & white level.

What do the others say?

I couldn't disagree more. I don't see how the Photoshop style of brightness/contrast adjustment is useful for video. Brightness/contrast controls for video exist solely to set the black/white point in the video to correct for level errors.

If you want to adjust midtone contrast of the image, that's what gamma controls are for. (and madVR already has keyboard shortcuts for ±gamma control)

Originally Posted by madshi

Please retest DXVA2 scaling, it should be a lot different now compared to before. No more "scaling failed" and no more point resampling with AMD and Intel. Also probably better scaling quality with NVidia now.

The image is still getting cropped slightly with DXVA2 scaling as well. (but less than it was before)

[DragonQ]

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?

[madshi]

Originally Posted by robpdotcom

Not sure if this is a bug or a limitation, but the IVTC filter does not work with DXVA2 decoding. In fact, I cannot even toggle to "film mode" using the keyboard shortcut.

That is as intended because the madVR IVTC algorithm currently runs on the CPU, so it doesn't work with native DXVA2 decoding.

Originally Posted by ajp2k11

debug log as requested.

Please upload it somewhere else. Attachments on this forum can sometimes take a long time to get approved.

Originally Posted by aufkrawall

But now I have another problem:
madVR fails to correctly enter FSE if there's a display mode change at the same time when DXVA2 downscaling is selected.
It's reproducible to me. Doesn't happen with other downscale methods.

It does not occur when using DXVA2 upscaling? That's weird, if it only occurs during downscaling but not during upscaling!. Can I have a debug log, please?

Originally Posted by 6233638

Using the MPC-HC controls, they are not working correctly. Or at least, not how everyone else does it - I do think your usage is more accurate, but it will confuse anyone familiar with how the brightness/contrast controls work on anything else.

+contrast should be −brightness
−contrast should be +brightness

+brightness should be +contrast
−brightness should be −contrast

Ok.

Originally Posted by 6233638

+saturation should be called +colour or +chroma
−saturation should be called −colour or −chroma

You're still continuing to talk about "saturation" vs. "chroma" without really saying which definition you're basing this on. Where is it defined exactly what a "saturation" control does and what a "chroma" control does? I hate to ask the same question multiple times, but you still haven't answered that. You're continuing to explain your understanding of what a saturation control does vs. chroma control, but you haven't said yet which definition/theory/concept this is based on.

Originally Posted by 6233638

Am I correct in thinking that the brightness/contrast controls only affect either the white/black points, and are not stretching the range?

i.e. −contrast under your naming scheme is only raising black from say 16 to 20, and leaves white at 235 rather than also reducing it by a similar amount at the same time. (say to 230)

I actually think that it would be useful to have a control that adjusted both black level and white level by the same amount to fix videos which have been encoded with the wrong levels settings (sometimes a video is recorded at 16-235 but gets encoded at 30–218 for some reason) but that's not what people would expect the brightness/contrast controls to do.

I do wish there was an option to add some custom levels presets or something inside madVR rather than manually adjusting brightness/contrast for each video though. Being able to switch between "PC Levels", "TV Levels", and "Custom 1", "Custom 2" etc. would be very useful. (or at least PC, TV, and 30-218)

The whole brightness and contrast control stuff is a big mess. Your opinion seems to be that I should design the controls in the same way displays do that. But is it really a good idea to do that? E.g. if you use the madVR controls to change the levels from 16-235 to 32-180 then you're also severely reducing the number of "steps" madVR can output. It would be better for image quality to use the display's controls instead.

Originally Posted by 6233638

Most colour management systems now use RGBCMY HSL controls to adjust things. It's a far easier way to calibrate the display because you can use dE'94 to split the colour error into its hue/saturation/lightness components and allows you to adjust each aspect individually. HSL controls allow you to dial in a display much quicker than any other method.

RGBCMY HSL controls (or xyY) are exactly what yCMS needs to adjust the LUT if the calculated points are not correct. (although personally I would rather just directly enter RGB output values, similar to when you write a custom LUT for some hardware LUT boxes)

A chroma control adjusts both saturation and lightness of a colour at the same time, and is considerably less useful in calibration. A chroma control is probably what most people would expect from something like this however, so your "linear saturation" implementation is fine there. (but it's technically a "chroma" control rather than a "saturation" one)

You still haven't explained where all these terms are defined that you're using. Are you basing all of this on the HSL colorspace definition? If so, you should really do some research because even if HSL might work reasonably ok for calibration, it's a very flawed system. "Lightness" as defined by HSL doesn't even take into account that green looks brighter to the human eye than blue does. So it's really a totally crappy system. If you try to judge madVR's saturation controls by HSL standards then yes, both "lightness" and "color" are changed. But the HSL term of "lightness" is totally bad. If you judge the madVR controls based on a better concept than HSL then madVR actually only changes saturation and nothing more. madVR splits the colors into luminance and chrominance (not luma and chroma) and luminance is left untouched by the saturation control. So if you think about it, "luminance" is somewhat comparable to HSL's "lightness". madVR's saturation control does not change "luminance", but it does change "lightness". But since the concept of luminance/chrominance is technically far superior to lightness/color, the proper name really is "saturation control" and not "chroma/color control", as far as I understand. If you disagree, I'm open for discussion, but I'd like some links that explain your definitions.

Originally Posted by 6233638

I couldn't disagree more. I don't see how the Photoshop style of brightness/contrast adjustment is useful for video. Brightness/contrast controls for video exist solely to set the black/white point in the video to correct for level errors.

But shouldn't level errors be corrected by using brightness/contrast controls in the display? Even if you think they should be corrected by madVR's controls, then don't they still belong into the madVR device setup, so they can be defined per monitor? If so, this can't be done via color controls, because the color controls are out of madVR's hands, so they can't be applied per monitor.

But then, media players do reapply the same color controls for every video, so the color controls are neither truely per monitor, nor are they per source file. This really is a mess...

Originally Posted by 6233638

If you want to adjust midtone contrast of the image, that's what gamma controls are for. (and madVR already has keyboard shortcuts for ±gamma control)

Changing the gamma curve can change the "brightness" of the image, but a contrast change is something different. For changing contrast you would apply an S-curve, which is different to what gamma adjustments do. Look here for more information about this:

http://tutes.tonebytone.com/ImageMagick/Enhance/SigmoidalContrast/index.php

[madshi]

Originally Posted by DragonQ

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]

Originally Posted by madshi

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

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]

Originally Posted by 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]

Originally Posted by nevcairiel

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]

Originally Posted by madshi

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 -HR -mVR

They're all identical

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

-EVR
-mVR with my display set to 0-255
-mVR with my display set to 16-235

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.