madVR - high quality video renderer (GPU assisted)

[Xaurus]

madshi,

I can't really find any useful info on pixel shaders or what they do, is that something that will improve the image when also using your scaling algorithms? Or are these two different things?

This from a MPC-HC FAQ:
Q: What are shaders?
A: A Pixel Shader is a graphics function that calculates effects on a per-pixel basis. A shader is basically a tiny program that is executed on your graphics card to process some graphic data. In the case of MPC, every frame of the video you play gets processed.
Doesn't really say much concrete to me. :)

[Razoola]

Not sure what you mean. What is so special about build 6205?

Thats the build number of the custom MPC you built.

[madshi]

I can't really find any useful info on pixel shaders or what they do, is that something that will improve the image when also using your scaling algorithms? Or are these two different things?
Look at MPC-HC in the menu "Play -> Shaders". This whole submenu didn't work with older madVR builds. Now with the latest madVR build and the test MPC-HC build I created, this works with madVR, too. You can use the already existing custom pixel shaders from that menu, or you can write your own. Shaders can do all sorts of things, like noise reduction, sharpening, blurring, whatever you like.

Thats the build number of the custom MPC you built.
Ooh, I see. No, that's just the build I downloaded a couple days/weeks ago. This number does not have any special meaning. I can't say with which version number official MPC-HC builds will support custom shaders with madVR v0.85.0. None of the current official builds does. But maybe tomorrow's build will, I don't know that...

[Xaurus]

Look at MPC-HC in the menu "Play -> Shaders". This whole submenu didn't work with older madVR builds. Now with the latest madVR build and the test MPC-HC build I created, this works with madVR, too. You can use the already existing custom pixel shaders from that menu, or you can write your own. Shaders can do all sorts of things, like noise reduction, sharpening, blurring, whatever you like.

Thanks, I will try it out. Maybe there's a deband shader somewhere, can't find it in the official list though.

[TheLion]

So it happens with software decoding, too? Please make sure you have all DXVA2 related stuff turned off. That means: Decoding, Deinterlacing and Scaling. Does that fix the problem?

Yeah, all DXVA2 stuff is deactivated - including automatic deinterlacing. It happens with any decoder - even with madVR's internal ones.

In CC all video options are disengaged. This is not a setup problem as downgrading to any previous madVR version fixes it.

My guess is that it has to do with the new "color control" interface and MC18. When I open the MC color controls and change something the picture becomes black/white but the controls have an effect (eg. contrast, brightness,..)

[6233638]

Today's date is 21.11.12, and we've reached page 777. I think this is a good time to announce the first madVR version which has no significant limitations compared to VMR/EVR, anymore.This seems like an awesome update! I do wonder if it should have been moved onto version ".90" rather than ".85" to indicate its significance.

(1) External DXVA2 decoders should now work just fine in native mode without needing "copyback". This should improve performance, especially for ATI/AMD users.DXVA2 Native shows errors which do not appear with DXVA2cb or CUVID decoding (image is greyscale in DXVA2cb/CUVID)
http://www.abload.de/thumb/test2.mp4_snapshot_0006qe5.png (http://www.abload.de/img/test2.mp4_snapshot_0006qe5.png)

Sample Video (http://www.datafilehost.com/download-1a4c352e.html)

I also notice that this sample doesn't get deinterlaced by default, no matter your deinterlacing settings. (don't think this is new to 0.85 though)
When you enable deinterlacing, this disappears.

(2) DXVA2 scaling uses the GPU hardware/drivers to do image scaling.On my GPU, the image seems to be slightly cropped with DXVA compared to all other options.

DXVA2:
http://www.abload.de/thumb/dxva8upsl.png (http://www.abload.de/img/dxva8upsl.png)

Jinc 3 AR:
http://www.abload.de/thumb/jinc4apqd.png (http://www.abload.de/img/jinc4apqd.png)

(and wow, DVE's test patterns look horrible these days)

(4) madVR now supports media player color controls (brightness, contrast, saturation and hue). Currently you can't adjust these settings inside of madVR, the media player has to do that, by using the official IVMRMixerControl9 interface.What kind of precision is this done with, compared to madVR's 16-bit levels conversion?

The madVR brightness control only modifies the white level, but keeps the black level identical.While the naming makes more sense, and I agree with your naming change for PC/Video levels for example, this is the opposite of how every display on the planet controls brightness (black level) and contrast (white level) so I would suggest flipping them to the standard naming convention.

The madVR saturation and hue settings work as usual, however I'm performing the modifications in linear light (which is the only correct way to do saturation/hue adjustments), while the other renderers and GPU drivers usually adjust these things in gamma corrected light.Is this actually a "saturation" control, or a "chroma" control? (saturation & lightness) Most "color" or "saturation" controls actually adjust chroma, unless all three Hue/Saturation/Lightness (or HSB) controls are offered.

(6) When using any DXVA2 related functionality with madVR, there's a small blur added to the chroma channel, when using NVidia or Intel hardware. This does not happen with AMD hardware. Currently I've no way to fix this. But it has always been this way and nobody complained until now, so it doesn't seem to be much of a problem.It has always been this way when using DXVA2cb/CUVID, or it has always been this way regardless with Nvidia cards?

(7) The new default scaling settings are Lanczos3 AR for image upscaling, Catmull-Rom AR with Linear Light for downscaling and Bilinear for Chroma. I've selected these algorithms with an eye on performance, as well as quality.This seems like an excellent choice for the defaults, though I wonder how much of a performance hit using something like Bicubic 75 for chroma would be. (a good choice for a default as it's still fairly quick and does not require anti-ringing to look good)
I suppose madVR has moved on quite a lot from one of its main benefits just being chroma upsampling though.

No kidding! And finally madVR is usable on long flights where battery life (DXVA decoding) is important.
Thanks!To be fair, if you've been using LAV Video Decoder, you've been able to use the DXVA2 copy-back feature, which is very similar in terms of performance and power-consumption to native DXVA. (though it seems like some lower-end AMD cards have performance issues)


And for anyone wondering, the new beta drivers from Nvidia do not fix the refresh rate problems on Windows 8. (still switches to 23/59Hz rather than 24/60Hz)

[leeperry]

why this isn't v1.0 yet: While madVR now has no major limitations compared to VMR/EVR, anymore, I still don't consider it feature-complete. There's still a list of things I want to add. Afterwards there'll be a period of tweaking and polishing. Then some kind of manual. And then maybe it's time for v1.0. But that's still some time away...
So it's a like a "try before you buy" end-user agreement that might very well last half a decade or more :D

I'm currently focused on delivering all important stuff with the minimum of needed features. Adding access to N-1 frames would not be compatible to the MPC-HC shader editor, so I'd have to write my own shader editor and that would cost a lot of time. In the same way some other features are rather limited right now, too. E.g. screenshots, refresh rate changer etc could all be better than they are now. But they work, and there are still some things missing, so the missing things are more important now. In the same way I first wanted to make shaders work the same way they work in VMR/EVR because doing that didn't cost too much time. Adding new features to all this stuff might happen some time in the future, but now's not the time for that. Or let me say it in different words: If I had implemented a much more extensive shader solution with access to N-1 frames etc, you would have had to wait a month or 2 more for v0.85.0 to appear, furthermore you'd not have DXVA2 decoding and scaling support at all.
OK, thanks for the detailed reply! When I whine about the ability to input custom display gamut instead those 3 miserable existing presets or to finetune the amount of dithering(as all displays aren't born equal) it seems that I don't deserve a reply so I'm most glad to have one on another feature request that matters a lot to me(and others too, especially on HCFR) :)

Well, ages ago you told me that giving access to the PS scripts via the mediaplayer wouldn't be technically possible, so I'm also glad to see that you worked it out! Because quite frankly, it takes a million clicks to get into mVR's config panel and this is not convenient at all :o

I was hoping that you could simply add some variables that would allow access to N-1 frames w/o reinventing the wheel? Like a backward compatible improved script language or so?

I might be mistaking but I should able to set automatic profiles in PotP combined with specific PS scripts, so my very evil plan of automatic PS based gamut mapping based on frame rate & resolution(SD/HD 25=EBU,SD/HD 23.976=SMPTE-C, SD 29.97=SMPTE-C, HD 29.97=HDTV) might finally be possible....I'm shocked :scared:

Especially when JohnAd's PS script has been checked by a large number of ppl on AVS and that I don't have to check it again....this thing blew me away the time day I tried it on my ex-HC3100!

I'll wait for PotP to support PS script capabilities with mVR, then the struggle will inevitably continue :)

I dunno how high/whether that's still on your TODO list but custom levels/gamut/matrix filename tags would still be full of win in order to permanently fix broken encodes once and for all, but at least we can process 16bit(or 32fp?) levels conversions via a PS script now and roll the gamut/matrix manually...too bad none of this can be automated :(

:thanks: again for making this all possible!

[Gelatinous]

how can I tell in potplayer/MPC if dxva is working with MadVR and LAV? I've seen screenshots of MPC with "Playing [DXVA]" in the status bar, but when I enable dxva2 native in LAV Video config there's no such message in my status bar.

[JarrettH]

Can't wait for your slew of scaling tests, 6233638.

Thanks for this major version, madshi :goodpost:

I just want to double check...are the CPU/GPU default queues 12/8?

As an aside, is the picture quality in Overlay equal to FSE? It's significantly faster. Are there some pros/cons between both? I know you can't take screenshots in Overlay.

DXVA2 scaling is way, way faster for rendering times. Dexter episode (720p, HDTV)...

to 1920x1080p (Core 2 Duo E6600, GeForce 550 Ti 306.97 driver)

Jinc 3 AR
Bicubic 75 AR

16ms

DXVA2
Bicubic 75 AR

4ms

Ran (720p)

Jinc 3 AR
Bicubic 75 AR

16ms

DXVA2
Bicubic 75 AR

5ms

A quick subjective test tells me that DXVA2 is slightly softer versus Jinc3 (expected) and the image doesn't have as much 'pop' to it.

[leeperry]

Thanks, I will try it out. Maybe there's a deband shader somewhere, can't find it in the official list though.
The best place for PS scripts might very well be this 69 pages long thread (http://www.homecinema-fr.com/forum/multimedia-materiels-pchc/mpc-filtre-s-pixels-shaders-t29814317.html), good luck avec le broken français via google translations http://forum-images.hardware.fr/images/perso/apo_isis.gif

[TheShadowRunner]

Hi madshi,
On XP, when I try to use Cyberlink MPEG2 Dec in DXVA mode + madVR 0.85 for DVD playback, i get an error:
"Access violation at address 1C45259A in module 'CLVSD.AX". Read of addresss 00000000." and playback never starts.
With previous madVR builds, the Cyberlink decoder fell back to software mode at least.

I guess this is expected as madVR became compatible with DXVA2 decoders but is still not DXVA (old DXVA for XP) compatible, right?
Or is it supposed to work?

[HoP]

Thanks, I will try it out. Maybe there's a deband shader somewhere, can't find it in the official list though.

The best place for PS scripts might very well be this 69 pages long thread (http://www.homecinema-fr.com/forum/multimedia-materiels-pchc/mpc-filtre-s-pixels-shaders-t29814317.html), good luck avec le broken français via google translations http://forum-images.hardware.fr/images/perso/apo_isis.gif

you forgot this topic ;)
http://forum.doom9.org/showthread.php?t=157634

sorry for off-topic :)

[madshi]

My guess is that it has to do with the new "color control" interface and MC18. When I open the MC color controls and change something the picture becomes black/white but the controls have an effect (eg. contrast, brightness,..)
Oh, that's a very good explanation, actually. It's quite possible that MC18 does weird things with the color control interface. I actually had to change my initial implementation to make it work ok with MPC-HC because MPC-HC has a very crappy implementation of this interface. Maybe MC18 has a similarly crappy implementation, just in a different way? If you upload a debug log, I can have a look at what MC18 is telling madVR to do. Does MC18 have a "reset" function for the color controls? Try moving all sliders around, maybe that helps...

DXVA2 Native shows errors which do not appear with DXVA2cb or CUVID decoding (image is greyscale in DXVA2cb/CUVID)

I also notice that this sample doesn't get deinterlaced by default, no matter your deinterlacing settings. (don't think this is new to 0.85 though)
When you enable deinterlacing, this disappears.
Interesting. Which GPU and OS are you using? I can reproduce this with my NVidia 9400 on win7 x64.

On my GPU, the image seems to be slightly cropped with DXVA compared to all other options.
Yes, I have that, too, although I feed DXVA the same values I use for my own resizing...

What kind of precision is this done with, compared to madVR's 16-bit levels conversion?
It's done without temp buffer storage, so it's actually 32bit+ floating point per component. If you change black or white level by one step in MPC-HC, madVR moves the level by a value of 0.5. So e.g. having brightness at +5 and contrast at +0, with video levels you should get output levels of 16 - 237.5.

While the naming makes more sense, and I agree with your naming change for PC/Video levels for example, this is the opposite of how every display on the planet controls brightness (black level) and contrast (white level) so I would suggest flipping them to the standard naming convention.
As far as I know, display brightness and contrast controls both change black level as well as white level at the same time, or am I wrong?

Is this actually a "saturation" control, or a "chroma" control? (saturation & lightness) Most "color" or "saturation" controls actually adjust chroma, unless all three Hue/Saturation/Lightness (or HSB) controls are offered.
I'm not sure I understand the concept of lightness. I'm not a calibration expert. What madVR does is convert R'G'B' to linear light RGB, then to linear light YCbCr, then the Cb and Cr channels are multiplied with the saturation factor. Does that answer your question? Basically both saturation and hue controls affect only Cb and Cr, and that in linear light. So linear light Y is unchanged by both controls.

It has always been this way when using DXVA2cb/CUVID, or it has always been this way regardless with Nvidia cards?
It has always been this way when madVR comes in *direct* contact with any DXVA2 output. DXVA2cb/CUVID don't count as direct contact because LAV does all that behind madVR's back and converts it to a format that looks like software decoder output.

The simple problem is that DXVA2 writes NV12 to a IDirect3DSurface9, and pixel shaders cannot access this. So I have to convert the NV12 surface to a format pixel shaders can work with. And doing that unfortunately makes NVidia and Intel drivers apply chroma upsampling. Which madVR then undoes later.

I suppose madVR has moved on quite a lot from one of its main benefits just being chroma upsampling though.
madVR's main benefit was never supposed to be just chroma upsampling. The main benefit was always meant to be high-bitdepth accurate processing from start to finish, without any bad GPU algorithms coming in between.

though it seems like some lower-end AMD cards have performance issues
It's not just lower-end AMD cards. It's generally *any* AMD card older than 7xxx which has problems with copyback. Only generation 7xxx relaxed the problem a bit.

So it's a like a "try before you buy" end-user agreement that might very well last half a decade or more :D
madVR will probably always stay free. There might just be a "pro" version with some fancy extra features at some time in the future.

When I whine about the ability to input custom display gamut
We've had this discussion before. I don't feel like repeating myself.

or to finetune the amount of dithering(as all displays aren't born equal)
Forgot about that. From what I remember, some months (years?) ago you were all hip about adding additional noise/dithering to what madVR already added. Now it seems you're going the opposite way, asking for less dithering. Anyway, madVR applies exactly the mathematically correct way of dithering to get rid of quantization artifacts. Any less dithering and quantization artifacts are likely to return. So no, I do not plan to offer an option to reduce the dithering noise. I don't think it's a good idea for image quality. What I might do is add support for 10bit output some day in the future. Doing that will automatically lower the mathematically necessary amount of dithering by a factor of 4. But this will probably not happen anytime soon. And then the question will be which GPUs/drivers support that, anyway.

I was hoping that you could simply add some variables that would allow access to N-1 frames w/o reinventing the wheel? Like a backward compatible improved script language or so?
It doesn't stop there, though. Having access to N-1 frames will also result in people asking for the ability to add new frames into the madVR render queues to do frame interpolation etc. Doing that would open up a whole new can of worms. It's all possible, but very complex and time consuming.

how can I tell in potplayer/MPC if dxva is working with MadVR and LAV? I've seen screenshots of MPC with "Playing [DXVA]" in the status bar, but when I enable dxva2 native in LAV Video config there's no such message in my status bar.
If DXVA2 native isn't working, LAV Video falls back to software encoding, I think, so you could simply check the CPU usage. If DXVA2 decoding is used, CPU usage should be lower than when using software decoding. This this with a high-bitrate VC-1 or h264 Blu-Ray, just to be safe.

I just want to double check...are the CPU/GPU default queues 12/8?
I think 16/8? Not sure, from the top of my head, though.

As an aside, is the picture quality in Overlay equal to FSE? It's significantly faster. Are there some pros/cons between both? I know you can't take screenshots in Overlay.
Yes, you can take screenshots with Overlay, by using the media player functionality for that. You can't take screenshots with Overlay by using the Print key, though.

Overlay is faster in what way? Overlay is more comfortable because it's not exclusive (doh). Exclusive is less comfortable, but it comes with the highest protection against frame drops. Overlay might very well work perfectly for you, though. It depends on how susceptible your PC is for frame drops.

DXVA2 scaling is way, way faster for rendering times. Dexter episode (720p, HDTV)...
Well, comparing to Jinc might not be fair. Try comparing against simple Bicubic or Lanczos with or without AR. Jinc is extra demanding compared to everything else.

[aufkrawall]

Very cool new features. :)

But something's wrong for me: I got thick a artifact line at the bottom of a rendered image with some samples (H.264 downscaled).
Edit: With DXVA2 native. Gonna post screens, 1 sec...

[madshi]

Hi madshi,
On XP, when I try to use Cyberlink MPEG2 Dec in DXVA mode + madVR 0.85 for DVD playback, i get an error:
"Access violation at address 1C45259A in module 'CLVSD.AX". Read of addresss 00000000." and playback never starts.
With previous madVR builds, the Cyberlink decoder fell back to software mode at least.

I guess this is expected as madVR became compatible with DXVA2 decoders but is still not DXVA (old DXVA for XP) compatible, right?
Or is it supposed to work?
Hmmmm... Is that decoder really DXVA or is it DXVA2? I don't have a "Cyberlink MPEG2 Dec" installed on my XP PC, but I do have a filter named "Cyberlink Video/SP decoder (PDVD7)" installed and that does seem to crash. Is that the one you're talking about?

[madshi]

But something's wrong for me: I got thick a artifact line at the bottom of a rendered image with some samples (H.264 downscaled).
Using which decoder and madVR settings? I can't read your mind. Is it DXVA2 decoding which is causing the issue? Or DXVA2 scaling? Or something else?

[madshi]

Ok, my MPC-HC changes were applied with revision 6239. So any MPC-HC equal to or higher than that should support custom pixel shaders with madVR v0.85.0.

[TheShadowRunner]

That Cyberlink MPEG2 decoder, when used on XP, is using the DXVA interface. It works with VMR7/9 just fine with DXVA active.
Yes, it's the one you're talking about, except I use the latest version (PDVD12).

[aufkrawall]

Using which decoder and madVR settings? I can't read your mind. Is it DXVA2 decoding which is causing the issue? Or DXVA2 scaling? Or something else?
Thus the edit.
Some more details:
Happens only with DXVA2 native.
Chroma upscale: Jinc3 AR
Luma downscale: C-R AR LL

Screens:
http://www.abload.de/thumb/avatar.mkv_snapshot_0qbuhr.png (http://www.abload.de/image.php?img=avatar.mkv_snapshot_0qbuhr.png) http://www.abload.de/thumb/cryengine3_tech.mkv_sfxubo.png (http://www.abload.de/image.php?img=cryengine3_tech.mkv_sfxubo.png)

Avatar has distortion and the CE3 trailer a grey line. Both are H.264.
Oddly it doesn't happen with VC-1 or VC-1i.

[madshi]

@TheShadowRunner, I'll have a look at the later.

@aufkrawall, does it happen with all decoders? I suppose you've tested with LAV? How about e.g. CoreAVC?

[aufkrawall]

@aufkrawall, does it happen with all decoders? I suppose you've tested with LAV? How about e.g. CoreAVC?
Seems to be decoder independent: Happens also with CoreAVC or MPC HC internal.

[nevcairiel]

how can I tell in potplayer/MPC if dxva is working with MadVR and LAV? I've seen screenshots of MPC with "Playing [DXVA]" in the status bar, but when I enable dxva2 native in LAV Video config there's no such message in my status bar.

In MPC-HC, the [DXVA] thing in the statusbar only works with the built-in renderers, specifically only with EVR-CP and/or VMR-9 renderless. It uses a rather hacky way to detect it.

Maybe madshi can show it on the OSD instead?

Also a short note for LAV DXVA2 native + madVR: There are 2 small bugs in LAV that may affect madVR DXVA, but they are fixed in the latest git builds, you can run this one for a better experience:
http://files.1f0.de/lavf/LAVFilters-0.53.2-8-g7fd402c.zip

The issues would mostly manifest as madVR queues not filling in DXVA2-Native mode, or madVR staying in memory, possibly causing MPC-HC not to close properly.
Both these issues didnt affect EVR, because it works quite differently in some areas (especially queuing)

I'll finish some changes on the weekend and release a new final version of LAV soon, once i'm back from my business trip anyway.

Now all we need is the new xy-vsfilter with the madVR subtitle interface, and it can properly run in DXVA for nearly all cases. :)

[madshi]

@aufkrawall, thanks.

@nevcairiel, yeah, I should probably display that DXVA2 decoding is used in the debug OSD somewhere...

[aufkrawall]

@nevcairiel, yeah, I should probably display that DXVA2 decoding is used in the debug OSD somewhere...
Maybe you could also display there if resolution/refreshrate is chosen by filename instead of file header/container/stream info? :)

[leeperry]

We've had this discussion before. I don't feel like repeating myself.
Well, we've had a lot of discussions about this...IIRC first you said that you would never provide PS based gamut mapping because this is what 3DLUT's are for, then you silently added it, and then you kept saying that 3DLUT's are here for this very purpose.....but I don't see how hard this would be for you to allow custom coordinates....seriously :confused:

I was under the impression that the goal of mVR was to provide top notch features without all the headaches associated. Many ppl have shown/proven you that yCMS in yRGB is still very much a WIP and doesn't do what it's supposed to(bugfixes are in the works, or so I heard)...I fail to understand what the big deal would be to allow custom coordinates instead of those 3 miserable existing presets =/

I don't think this would hurt yesgrey's feelings and again all roads lead to Rome so ppl could first use your PS script based gamut mapping and should they want to go the 3DLUT way later on, then more power to them! I can't think of any display that would hit perfectly out of the box SMPTE-C(not even oldish CRT's), EBU(an EBU display, seriously?) or REC.709(there's always at least a 6/8 ΔE drift IME) so your 3 presets are like dropping your end-users on the highway in the middle of their trip: I'll roll gamuts for ya, but fix your display first or forget about the whole thing! Do you find this convenient? Did you find it usable at all in your own real world experience?

The truth is that it'll take a display with an xyY CMS in order to make it usable so it's completely pointless on regular/non-highend consumer displays. I was under the impression that your goal was to dumb down video excellence, not keep it as an holy graal to an educated elite. Allowing custom coordinates would allow anyone to buy a $50 ColorMunki Create(i1d2 clone) and get perfect gamut mapping in a few clicks: oh yeah baby!

Anyway, you're the one in charge and for some completely inexplicable reason to me you've decided to stubbornly overlook this most important feature...bummer :(

Forgot about that. From what I remember, some months (years?) ago you were all hip about adding additional noise/dithering to what madVR already added. Now it seems you're going the opposite way, asking for less dithering. Anyway, madVR applies exactly the mathematically correct way of dithering to get rid of quantization artifacts. Any less dithering and quantization artifacts are likely to return. So no, I do not plan to offer an option to reduce the dithering noise.
Well, times change you know....especially when connected to a CRT in 10bit with a 10bit CLUT. Also, noise and fake film grain get odd after a while. And on crisp anime mVR's dither can look quite noisy with CRT/LCD IME, it flattens the 3D pop effect as well...all I'm seeing atm is a layer of random noise added onto my movies. Also, some LCD's have a built-in video engine that's meant to clean up noise, and will/would also add its own dither on top afterwards....anyway, I've made my point and you've also strongly disagreed, c'est la vie I guess. I've got dither disabled in mVR atm as it tends to make the picture too noisy to my taste....DLP doesn't care much about noise IIRC/FWIWT so we'll see :)

It doesn't stop there, though. Having access to N-1 frames will also result in people asking for the ability to add new frames into the madVR render queues to do frame interpolation etc. Doing that would open up a whole new can of worms. It's all possible, but very complex and time consuming.
Alright, I didn't realize that it would become such a headache :D

BTW, I've tried to set automatic profiles in PotP but they don't remember the last selected PS script and they provide very limited rules, so that's a no-go.....I'll have to calibrate the W1070's ISF xyY CMS to REC.709 and use your holy REC.709 preset :)

Last but not least, I don't mean to whine any further but so far you only told me that you'd "think about" my custom levels/gamut/matrix filenames tags feature request, do you think this might ever occur in a foreseeable future by any chance please? I'm sure I'm not the only with broken encodes who would love to gain the ability of fixing them forever with a simple filename tag: that'd be too good to be true! :cool:

:thanks:

[Gary.M]

Brightness should shift black level, contrast should affect gain or slope which will have less effect on black as it's nearer the origin than white.

Sent using Tapatalk

[Mangix]

notes on the DXVA2 decoding in madVR using a GTS 450.

It works great. The only issue with it is that rendering times really spike up compared to plain software decoding(8-10ms higher rendering times here). This is due to the fact that the GPU downclocks to 405MHz. A 720p video that I played added around 10% of extra GPU load. CUVID is still the fastest option(even faster than software) as there is no downclocking of the GPU.

After setting Prefer Maximum Performance in the Power Management section of the control panel I tested DXVA2 native to have around .30ms higher rendering times than CUVID(the test was repeated twice). Not too bad.

I'm expecting a greater benefit with AMD hardware as copyback is tremendously slow on a laptop I tested(struggles with 720p).

[nevcairiel]

If every video frame is shown for over 40ms (say 24p is shown for 41.6ms), why do you care if it takes 5 or 15ms to render the frame?
The GPU will automatically go into a higher performance state if its required to do so. Forcing maximum performance should not make any difference, it just adds power consumption, temperature and possibly even noise.

[6233638]

Interesting. Which GPU and OS are you using? I can reproduce this with my NVidia 9400 on win7 x64.Windows 8 and a GTX 570. (I try to keep my signature current)Yes, I have that, too, although I feed DXVA the same values I use for my own resizing...Strange, I wonder if it's possible to fix this. With Nvidia at least, the scaling doesn't appear to be very high quality. I hear that Intel's solution on the HD4000 is quite a good adaptive algorithm based on Lanczos 4 to try and minimize ringing, but I don't have any way of testing this either.It's done without temp buffer storage, so it's actually 32bit+ floating point per component. If you change black or white level by one step in MPC-HC, madVR moves the level by a value of 0.5. So e.g. having brightness at +5 and contrast at +0, with video levels you should get output levels of 16 - 237.5.Sounds good.As far as I know, display brightness and contrast controls both change black level as well as white level at the same time, or am I wrong?I don't know of any displays that do that now. It was really only CRTs where that was the case (raising brightness would also raise contrast a bit, and vice-versa) and that wasn't really intentional, just a side-effect of their analogue nature.

Brightness should only adjust the black level, and contrast should only affect the white level on most - if not all - displays.

The naming convention really is backwards though, but that's how it appears to be standardised across all displays I have ever used.I'm not sure I understand the concept of lightness. I'm not a calibration expert. What madVR does is convert R'G'B' to linear light RGB, then to linear light YCbCr, then the Cb and Cr channels are multiplied with the saturation factor. Does that answer your question? Basically both saturation and hue controls affect only Cb and Cr, and that in linear light. So linear light Y is unchanged by both controls.That sounds like it would be a "chroma" control then, rather than "saturation" but I'm not certain. Outside of a colour management system, it probably doesn't matter either way - as I said, any "colour" or "saturation" you find on a display is actually a "chroma" control unless it's part of a CMS with HSL controls.

Someone may have to correct me on this, but I think I have it right. (not sure if my numbers are correct for the Chroma patch)

http://www.abload.de/img/slcpvsj5.png
100% Red. 255/000/000 -50% Saturation. 255/127/127 -50% Lightness. 128/000/000 -50% Chroma. 191/064/064 (saturation & lightness)Photoshop's rounding is sometimes weird.It has always been this way when madVR comes in *direct* contact with any DXVA2 output. DXVA2cb/CUVID don't count as direct contact because LAV does all that behind madVR's back and converts it to a format that looks like software decoder output.So for optimal image quality, we should still be using DXVA2 copy-back, at least until you figure out a way around this on Nvidia/Intel hardware?madVR's main benefit was never supposed to be just chroma upsampling. The main benefit was always meant to be high-bitdepth accurate processing from start to finish, without any bad GPU algorithms coming in between.Sorry, I didn't meant to reduce it to just that. It's just that in early versions, that appeared to be the one of the main areas it was focused on. (i.e. this (http://forum.doom9.org/showpost.php?p=1271416&postcount=2))It's not just lower-end AMD cards. It's generally *any* AMD card older than 7xxx which has problems with copyback. Only generation 7xxx relaxed the problem a bit.Ah, I had misunderstood the problem then. It sounds like DXVA2 Native support will be best for AMD, and DXVA2 Copy-Back for Nvidia/Intel then.What I might do is add support for 10bit output some day in the future. Doing that will automatically lower the mathematically necessary amount of dithering by a factor of 4. But this will probably not happen anytime soon. And then the question will be which GPUs/drivers support that, anyway.If there is any way to get 10-bit output over HDMI from the current cards (I'm not sure that there is though?) I would really appreciate it if this was added sooner rather than later, but I understand that it's a very low-priority feature for you.

PCs really are awkward with how they handle high bit-depth output though, as it's mostly limited to professional displays/GPUs, and typically over DisplayPort, none of which is applicable to a home theatre setup.I think 16/8? Not sure, from the top of my head, though.Default appears to be 12/8.Yes, you can take screenshots with Overlay, by using the media player functionality for that. You can't take screenshots with Overlay by using the Print key, though.While not related to overlay, I did notice that if you take a screenshot of DXVA using the media player's built-in function, it saves the scaled result, rather than the pre-scaled result.how can I tell in potplayer/MPC if dxva is working with MadVR and LAV? I've seen screenshots of MPC with "Playing [DXVA]" in the status bar, but when I enable dxva2 native in LAV Video config there's no such message in my status bar.If you bring up the LAV Video properties when playing, it should say "Active Decoder: dxva2n" if it is using DXVA decoding. It will say "avcodec" if it is not.

Now all we need is the new xy-vsfilter with the madVR subtitle interface, and it can properly run in DXVA for nearly all cases. :)I think it's out now: http://code.google.com/p/xy-vsfilter/wiki/Downloads?tm=2

EDIT:Also a short note for LAV DXVA2 native + madVR: There are 2 small bugs in LAV that may affect madVR DXVA, but they are fixed in the latest git builds, you can run this one for a better experience:
http://files.1f0.de/lavf/LAVFilters-0.53.2-8-g7fd402c.zipI recommend this build for anyone using DXVA Native with DVD Playback - it fixed some menus that weren't working for me with the 0.53.2 build of LAV Filters. (was just about to report them)

[Mangix]

If every video frame is shown for over 40ms (say 24p is shown for 41.6ms), why do you care if it takes 5 or 15ms to render the frame?
The GPU will automatically go into a higher performance state if its required to do so. Forcing maximum performance should not make any difference, it just adds power consumption, temperature and possibly even noise.

One thing preventing me from fully moving to Jinc 3 is the rendering times. Although it's manageable for progressive content, interlaced is another ballpark. In particular, since 30i content gets deinterlaced to 60p, that really increases the workload. and rendering times above 16ms become a problem(72 and 75Hz are bigger problems).

I need to do more testing with different content to see if I get performance gains/issues. Oddly enough, the High Performance setting only really takes effect when running madVR. The GPU still downclocks as usual when doing other stuff like browsing or watching youtube videos.

[Prinz]

I think it's out now: http://code.google.com/p/xy-vsfilter/wiki/Downloads?tm=2

No, that new build doesn't use the new interface. The Developers said already that the november release will be a normal (old) release, only after this release the main work for the new interface begins.

[6233638]

No, that new build doesn't use the new interface. The Developers said already that the november release will be a normal (old) release, only after this release the main work for the new interface begins.Sorry, my mistake. Thanks for the correction.

[ajp_anton]

To be fair, if you've been using LAV Video Decoder, you've been able to use the DXVA2 copy-back feature, which is very similar in terms of performance and power-consumption to native DXVA. (though it seems like some lower-end AMD cards have performance issues)I changed it to "DXVA native" (before your post =)).
I know it's not much, but my laptop uses about 1W less with native than copy-back. On 5h flights, or even 10h which happens surprisingly often, every watt counts.

[madshi]

Now all we need is the new xy-vsfilter with the madVR subtitle interface
Yes, that would be nice!

IIRC first you said that you would never provide PS based gamut mapping because this is what 3DLUT's are for, then you silently added it
You do want to annoy me, don't you? I rarely say a definite "never". And what I said was that if you want to calibrate your display, you should use 3dluts. The gamut conversions madVR currently does via pixel shaders are not for calibrating the display, but for converting different source gamuts to a standard output gamut. That's a different thing to calibration. Calibration involves so much more than just mapping a gamut. I tried to explain that to you many times before, but it seems you just don't listen.

Last but not least, I don't mean to whine any further but so far you only told me that you'd "think about" my custom levels/gamut/matrix filenames tags feature request, do you think this might ever occur in a foreseeable future by any chance please?
I generally don't like to comment on questions about when I'll implement what in the future. Especially not after you've just done your best to annoy me.

Brightness should shift black level, contrast should affect gain or slope which will have less effect on black as it's nearer the origin than white.
Who defines how the control "should" work, though? From the calibration DVDs/videos I've seen, the recommended approach is to use brightness and contrast controls to get black and white level setup correctly. That appears to be the only purpose of those controls. So isn't it much more helpful if black and white levels are isolated to different controls? That would contradict your definition to have contrast affect gain/slope, though.

notes on the DXVA2 decoding in madVR using a GTS 450.

It works great. The only issue with it is that rendering times really spike up compared to plain software decoding(8-10ms higher rendering times here). This is due to the fact that the GPU downclocks to 405MHz. A 720p video that I played added around 10% of extra GPU load. CUVID is still the fastest option(even faster than software) as there is no downclocking of the GPU.

After setting Prefer Maximum Performance in the Power Management section of the control panel I tested DXVA2 native to have around .30ms higher rendering times than CUVID(the test was repeated twice). Not too bad.

I'm expecting a greater benefit with AMD hardware as copyback is tremendously slow on a laptop I tested(struggles with 720p).
It's interesting that using DXVA2 decoding lowers GPU clocks compared to software decoding. Isn't that weird?

Brightness should only adjust the black level, and contrast should only affect the white level on most - if not all - displays.

The naming convention really is backwards though, but that's how it appears to be standardised across all displays I have ever used.
Interesting. So I should just rename them and be done? Could you please check if the contrast and brightness adjustments "directions" are as expected? I wasn't sure which way they should be.

That sounds like it would be a "chroma" control then, rather than "saturation" but I'm not certain. Outside of a colour management system, it probably doesn't matter either way - as I said, any "colour" or "saturation" you find on a display is actually a "chroma" control unless it's part of a CMS with HSL controls.

Someone may have to correct me on this, but I think I have it right. (not sure if my numbers are correct for the Chroma patch)

http://www.abload.de/img/slcpvsj5.png
100% Red. 255/000/000 -50% Saturation. 255/127/127 -50% Lightness. 128/000/000 -50% Chroma. 191/064/064 (saturation & lightness)Photoshop's rounding is sometimes weird.
These are R'G'B' (gamma corrected) values, correct? If so, the saturation control you're mentioning seems to work in gamma corrected light? Which would be bad. I've done a lot of google searching when implementing my saturation and hue controls and the general consensus was that Photoshops saturation and hue controls are very very bad. My implementation is based on what my research seemed to indicate as the "proper" way to do things. When reducing saturation to 50% with madVR, the result is 203/092/092. When using the "procamp" shader script with EVR to reduce saturation to 50%, I get 166/038/038.

E.g. look here:

http://www.colormancer.com/whitepapers/saturation1/saturation.html

madVR results look a lot like Colormancer's results. The photo in the middle is from Photoshop... :D I don't know how old that article is, though. Maybe newer Photoshop versions are better...

So for optimal image quality, we should still be using DXVA2 copy-back, at least until you figure out a way around this on Nvidia/Intel hardware?
If copy-back works well for you then yes. Although, if you activate DXVA2 deinterlacing in madVR, the problem will affect you, anyway.

[huhn]

dxva2 resizing with intel hd 4000:

720:480 (ar 16/9) to 960

with dxva2 is at ~10.61 ms and it is most likely nearest neighbor
resize time 0.10 ms


chroma is mitchell-netravali without ar

looks like shit http://s3.imgimg.de/uploads/dxvainteleaee208bpng.png

the rendertime is about 14.50 ms with lanczos 3 tap without ar

madvr nearest neighbor ist below 4ms

if u know a way to change the dxva2 resizer to bilinear or something like that i can test it with that

with my amd 6770 12.10

dxva2 is nearest neighbor and scailing is at 0.18 ms and rendering over 4 ms

with lanczos 3 it is below 4 ms and with madvr nearest neighbor is at 1.70 ms

all done with mitchell-netravali without ar for chroma.

is there something else i can test?

edit: upscaled to 960 not 1080

[madshi]

@huhn, you're getting nearest neighbor results with Intel? That's really unexpected. DXVA2 scaling with Intel was supposed to activate some kind of Intel Lanczos AR algorithm! I'm not sure why it's not working for you. Will have to talk to my Intel contact about this...

[huhn]

i will remove my 6770 and try it again and update my intel driver.
this is most likely a wast of time but who knows maybe 2 grafikkarts at once is the problem here.


will be back in 20 mins

[huhn]

nothing changed as expected.

[madshi]

Too bad. In the meanwhile I also tested with my Intel laptop and I have the same problem here. Maybe I'm doing something wrong...

[leeperry]

The gamut conversions madVR currently does via pixel shaders are not for calibrating the display, but for converting different source gamuts to a standard output gamut. That's a different thing to calibration. Calibration involves so much more than just mapping a gamut.
Well, it currently says "this display is already calibrated" and then "the display is calibrated to the following primaries / gamut" so it's really meant to map the movie gamut to the display...and both the SMPTE-C and EBU presets are useless IRL. Only Rec.709 is usable and it requires a display with a xyY CMS.

I am well aware that a calibration per se involves more that just mapping a gamut but most serious displays will allow you to reach D65 from within their OSD in 12bit. It's only the CMS options that are missing in the consumer grade gear. At this point, 3DLUT's in yRGB don't seem to be able to roll gamuts reliably and merging them with ArgyllCMS 3x1DLUT *calibration* data doesn't seem to work too well either(and it doesn't make any sense to calibrate via an 8bit signal when you can do it in true 12bit in your display :o). So at this very moment, you're SOL if you don't have a xyY CMS capable display....that's my point and it seems that we will never agree on that matter, when a custom coordinates option would straighten everything out for many ppl(all those ppl from AVS who use the PS script on a daily basis for instance, mVR providing the added value of rolling them automatically :)).

I generally don't like to comment on questions about when I'll implement what in the future. Especially not after you've just done your best to annoy me.
I sincerely apologize for that :( It's just that you always seem to get jiggy with it whenever I raise this extremely disappointing situation, for whatever reason I'm completely clueless about....but alright, let's forget about the whole custom coordinates thing! I'll get that BenQ pj to reach Rec.709 and I'll come back with real world measurements of your gamut mapping code(that no one bothered providing yet AFAIK) :)

Back to my dither noise issue, I guess the real problem is that I'm feeding a CRT in 10bit going through a 10bit 3x1DCLUT + 2 D/A conversions via a 1.5m VGA cable.....so indeed any further noise is quite hard to bear, and I'll give you that your dither code does look fantastic via a TMDS24 connection on a display that doesn't do any "smart" NR. I need to give up on CRT anyway, the only thing they do well is black, all the rest is grossly outdated.

[6233638]

From the calibration DVDs/videos I've seen, the recommended approach is to use brightness and contrast controls to get black and white level setup correctly. That appears to be the only purpose of those controls. So isn't it much more helpful if black and white levels are isolated to different controls? That would contradict your definition to have contrast affect gain/slope, though.Yes, that's how they should work. Black/White clipping controls, essentially.

Brightness affects black level only.
Contrast affects white level only.

It's interesting that using DXVA2 decoding lowers GPU clocks compared to software decoding. Isn't that weird?That is weird, and has not been my experience:

CUVID forces the card to run using the highest clocks (P0 State) regardless of GPU load.

DXVA2 (native/copy-back decoding, or scaling) forces the card to run using medium clocks (P8 State) and it will switch to P0 if required. (e.g. using Jinc 8)

Software decoding allows the card to run in the lowest power state (P12) if GPU load is low enough, or P8/P0 as required. Most scaling algorithms push my card into P8, so I think I'm better off using DXVA2 copy-back. (assuming chroma is rendered properly, unlike DXVA2 native?)


I haven't measured power consumption to see how CPU decoding compares to GPU decoding, and would be curious to see how that also compared with QuickSync.

I also haven't used a Z67/77 system, so I don't know how it's handled on them. Is it possible to use QuickSync for video decoding (presumably lower power consumption than software decoding) and have your dedicated GPU handle image scaling, or does using QuickSync require the onboard GPU? (HD4000)

It seems like QuickSync decoding with a dedicated GPU handling scaling should still be allowed to enter P12, and could reduce power consumption over software decoding.

Interesting. So I should just rename them and be done? Could you please check if the contrast and brightness adjustments "directions" are as expected? I wasn't sure which way they should be.I'm not sure where these controls are supposed to be? If I'm supposed to be using the Nvidia control panel, they appear to be working correctly for DXVA2 Native.

These are R'G'B' (gamma corrected) values, correct? If so, the saturation control you're mentioning seems to work in gamma corrected light? Which would be bad. I've done a lot of google searching when implementing my saturation and hue controls and the general consensus was that Photoshops saturation and hue controls are very very bad. My implementation is based on what my research seemed to indicate as the "proper" way to do things. When reducing saturation to 50% with madVR, the result is 203/092/092. When using the "procamp" shader script with EVR to reduce saturation to 50%, I get 166/038/038.Yes, I was using Photoshop, so it is probably still calculated in gamma corrected light. If your shader script is adjusting RGB values in such a way, it's a Chroma control, rather than a pure "saturation" control. (but operating in linear light instead of gamma corrected) Most "saturation" or "colour" controls are labelled incorrectly though. Without a full HSL colour system, a "chroma" control would be the right thing to use. (so your implementation is fine) Sorry for any confusion.

If copy-back works well for you then yes. Although, if you activate DXVA2 deinterlacing in madVR, the problem will affect you, anyway.That's interesting, because I don't think any of my chroma tests have been with interlaced material at all.

So I should avoid DXVA2 Native, and stick with DXVA2 Copy-Back, or does copy-back still have this problem, but LAV performs better downsampling from 4:2:2 to 4:2:0? I would prefer not to have this conversion at all.

What about CUVID?

Using DXVA2/CUVID/Software really isn't a concern for my system - I would rather have optimal image quality rather than a reduction in power consumption.

Is this something you are going to be able to get around, or is it up to Nvidia to fix? (and is it a hardware issue that would require new cards?)

[Prinz]

DXVA2 native with LAV Video doesn't work on some files for me. I used the LAVFilters-0.53.2-8-g7fd402c release, but mpc-hc hangs with a black screen and I have kill it via the taskmanager.

With EVR the same files work.

Debug log madvr (https://www.dropbox.com/s/e4t4wzcgryc2veq/madVR%20-%20dxva.zip)

[Mangix]

Can't replicate the downclocking results for some reason. Maybe requires a restart...

But I am having issues switching between windowed and exclusive mode again. This time the EDID is overridden properly and Windows recognizes my custom resolutions as being supported. Despite that, I'm getting issues when switching, both with regular windowed mode and overlay. It's so weird since I have no issues with 25i content but have issues with 24p, 30p, 30i, and 24i content(have not tested 25p, need to find some).

My guess as to why this is happening is because the default and as of now unchanged default refresh rate is 60Hz but actually a little lower and as a result showing up as both 59Hz and 60Hz. There's a similar problem for 71Hz and 72Hz(real refresh rate is set to 71.928). I might need to start using integer values.

It's so strange as D3D games have no problem using these refresh rates which was not the case without an EDID mod.

edit: I was right. When I removed 72Hz and made it an integer value instead of 71.928, the issue went away as well as 71Hz. I can't seem to make 59Hz go away however. I'd probably need more hardcore EDID editing to fix that...

Although what's interesting is that if I open up a 30p/i video from a resolution that's NOT 60Hz, madVR will switch the refresh rate to 59Hz instead(I see this on the OSD as 59.999 vs 59.950). When my refresh rate is at 60Hz, this will not happen but once I go into exclusive mode, the refresh rate changes to 59Hz.

Quite interesting...

edit2: If I launch a 30i/p video while at 60Hz, madVR will keep it at that resolution until exclusive mode where it goes to 59Hz. After closing mpc-hc, it does not go back to 60Hz but stays at 59Hz. I smell a bug.

edit3: oh this is just hilarious. the 60/59Hz issue does not happen with the old rendering path(present frames in advance unchecked). This is starting to mirror my prior experience with madVR switching to an HDTV resolution(16-235) versus the PC resolution(0-255) that it started out as.

Overlay also does not work if present frames in advance is unchecked.

[sneaker_ger]

It's interesting that using DXVA2 decoding lowers GPU clocks compared to software decoding. Isn't that weird?

My thoughts exactly. Happens here with HD5850 on Win7 x64. (Cat 12.11)

That said: DXVA2 decoding seems to work fine at first glance.

Problems:
- DXVA2 scaling seems to use something like nearest neighbor.
- some frames are shown out of order when seeking. (DXVA2 decoding + scaling)
- when seeking "scaling failed" warning may appear, but playback seems to immediately continue fine

[wanezhiling]

@madshi, 0.85 cant work with ffdshow dxva video decoder(build 4493), it gave me a blackscreen.

[Nevilne]

DXVA is point resize on hd6850, heh.

On an unrelated note, i've been comparing jinc to nnedi and it's pretty even fight.

[Gary.M]

Who defines how the control "should" work, though? From the calibration DVDs/videos I've seen, the recommended approach is to use brightness and contrast controls to get black and white level setup correctly. That appears to be the only purpose of those controls. So isn't it much more helpful if black and white levels are isolated to different controls? That would contradict your definition to have contrast affect gain/slope, though.


It is derived from where all this came from... CRT setup... black level was where the gun cut off, contrast was gain. In effect I guess here that black was the origin, and everything extended up from there.

If you set black level, how can you then set white level without "stretching or shrinking" things above that? If you don't "stretch or shrink" you will move black again. This "stretch or shrink" is equivalent to gain adjustment in analogue video amplifiers.

I think you could view contrast as a dynamic range adjustment too. Match the range of the source to that of the display while leaving black alone. "White" just happens to be a suitable place to align this.

[Mangix]

DXVA2 resize looks like some form of bilinear on my GTS 450. Looks blurry.

Also the save image function doesn't work as intended when using DXVA2. When using Jinc, the image is saved in its native resolution but when using DXVA2, it's upscaled.

[crotecun]

DXVA2 scaling doesn't work for me... I set my image upscaling and downscaling to DXVA2, the on-screen display says

madVR reports:
- scaling failed

The image produced is very jagged and there are short transparent lines around the edges.

Default settings - http://imgur.com/lIbhC
DXVA2 on image upscale and downscale - http://imgur.com/F8NdB

I'm on Windows 7 64-bit and a Radeon HD 5670 video card.

[crotecun]

Also the save image function doesn't work as intended when using DXVA2. When using Jinc, the image is saved in its native resolution but when using DXVA2, it's upscaled.

I can confirm this. Using default settings the image is in the native resolution, when I saved the image using DXVA2 it was upscaled too.