madVR - high quality video renderer (GPU assisted)

[huhn]

Ah I see a known bug, thank you for pointing that out. Yes I was on a driver some 4 months old before updating yesterday. I even updated again today to 347.90 in the hope it would fix it, but alas it didn't.

the next release may fix this. the current beta driver for window 10 349.65 for 9926 and 349.90 for 100041 doesn't have this issue anymore but other issue...

[JonnyRedHed]

the next release may fix this. the current beta driver for window 10 349.65 for 9926 and 349.90 for 100041 doesn't have this issue anymore but other issue...

I was also getting some odd slow down, almost mini blurred stuttering with r347.88 option2, and had to move up to 347.90 which is ok in option2 but still got the lines in opt1.


Just checked and seen 349.90, didn't see that one. So what's this other issue reported with 349.90.

[huhn]

I was also getting some odd slow down, almost mini blurred stuttering with r347.88 option2, and had to move up to 347.90 which is ok in option2 but still got the lines in opt1.


Just checked and seen 349.90, didn't see that one. So what's this other issue reported with 349.90.

it's a driver for windows 10 so pretty much alpha. the issue are pretty serious... nnedi3 is kind of broken. it not a normal release so nothing to go crazy about yet.

[Warner306]

If anyone is interested, aracnoz at the Kodi forums has released an alpha build of Kodi Entertainment Center featuring madVR. The build is stable, with the exception of some crashes when backing out of videos during playback. This feature is open for testing. I've created a companion set-up guide for those who are not familiar with the DS (DirectShow) Player branch of Kodi.

HOW TO - Configure Kodi DSPlayer with LAV Filters & madVR (http://forum.kodi.tv/showthread.php?tid=222576)

Here is a screenshot comparison of DSPlayer with madVR and MPC-BE with LAV Filters & madVR (http://forum.kodi.tv/showthread.php?tid=154534&pid=1965180#pid1965180).

[huhn]

the comparison screens shoots are JPG so this isn't a comparison.

and for comparison you should disable dither after that the picture should be bit identical. it's a JPG not sure if you did that.

lavfilter is not needed for madVR any directshow decoder should work and if that decoder is not broken it should result in 100 % the same quality.

[Warner306]

the comparison screens shoots are JPG so this isn't a comparison.

and for comparison you should disable dither after that the picture should be bit identical. it's a JPG not sure if you did that.

lavfilter is not needed for madVR any directshow decoder should work and if that decoder is not broken it should result in 100 % the same quality.

Yes, there are obvious limitations with showing screenshots on the Internet. I am certain Kodi applies additional compression to the images in its forum. The purpose of the comparison is to show that the integration of madVR and Kodi is done without any compromises in image quality. It you flip between players with the same image on the screen, they are identical.

Although, it is a guide, so I could include some information in the post about the limitation of screenshot comparisons or the purpose of the post.

The set-up guide is a reflection of what I've learned. It is hard to find up-to-date set-up guides dealing with madVR and various media players, so I have written two. More contribution on the specific content would be welcome, as I'm sure the technical accuracy could be improved. I represent the average user more than the expert.

[baii]

Nvm, confused between queue and frame setting in full screen.

Sent from my 306SH

[jkauff]

The set-up guide is a reflection of what I've learned. It is hard to find up-to-date set-up guides dealing with madVR and various media players, so I have written two. More contribution on the specific content would be welcome, as I'm sure the technical accuracy could be improved. I represent the average user more than the expert.
You'll find some useful information in this thread:

http://forum.doom9.org/showthread.php?t=171787

[Warner306]

You'll find some useful information in this thread:

http://forum.doom9.org/showthread.php?t=171787

Yes, I already incorporated everything I learned from post. But thanks.

[FireFreak111]

At what point in time do you reckon Windows XP support should end? Most people using madVR are likely running modern GPU's (Intel 4000+, Nvidia 400 series+, AMD 5000 series+) and a CPU made in the last 5 years. With that sort of hardware, most wouldn't be using Windows XP. Also, ditching it would allow a complete D3D11 chain.

Additionally, if you add 64 bit support, XP won't be a system that supports 64 bit (noone uses its 64 bit version).

[Soukyuu]

At what point in time do you reckon Windows XP support should end? Most people using madVR are likely running modern GPU's (Intel 4000+, Nvidia 400 series+, AMD 5000 series+) and a CPU made in the last 5 years. With that sort of hardware, most wouldn't be using Windows XP. Also, ditching it would allow a complete D3D11 chain.You're tying dropping winXP support to introducing a D3D11-only support. What about those like me who don't use XP but don't have a DX11 capable card either? The 260GTX is still more than enough for most madVR options (minus the NNEDI stuff).

[huhn]

it's fine as it is. no need to remove anything.

a directx 10/11/12 or something with 10 bit support is coming sooner or later.

[madshi]

In madvr 0.86.11, in windowed mode, fraps indicates 24fps and in fullscreen mode, madvr indicates 120fps. In mad 0.87.14 fraps indcates 120fPs and in fullscreen mode, madvr indicates 120fps.
Why in windowed mode, there is a change? How back to 25fps in windowed mode?
That's the new windowed mode. It was introduced in v0.87.10. It should produce more stable and reliable smooth playback. You can disable it to get the same as v0.86.11, by unchecking the option "present several frames in advance" in the madVR "windowed mode settings". I don't recommend doing that, though, because the new mode should really be superior.

With 6bits on my 6bits display, image is very ulgy.
With 8bits in my 6bits display, image is good.

With dithering option (error diffusion) and 6bits in option, it's like 8bits without error diffusion.
Dithering menu is not redundancy with native display bitdepth in device menu?
Strange. In theory setting your display to a lower bitdepth in the madVR "device" setup should result in stronger dithering, which should increase the noise floor slightly, but should decrease banding artifacts. So you're saying setting your display to 6bit in the madVR device setup increases banding artifacts compared to setting it to 8bit? That sounds really weird.

Older madVR builds used random dithering. You can try whether using that improves things. But in theory the ordered dithering algorithm used in newer madVR builds should be superior.

http://bugs.madshi.net/view.php?id=215&PHPSESSID=8dde4e94680d9e0e5bfc98594d441189
madshi told to write here. Could anybody help?
Driver version: 347.52. madvr version: 0.87.14. Video doesn't play if system color depth is 32 bit.
You can try again with v0.87.15. Maybe it's solved there? If not, please have a look at your debug OSD when video playback starts to judder. Are all the queues decently filled? Or are some of them near empty? Which?

At what point in time do you reckon Windows XP support should end?
When it costs me serious time to maintain it. Atm that's not the case.

-------

Extra special thanks to @huhn (and everyone else who helps out) for constantly and reliably providing a lot of support in this thread. That's very helpful to madVR users, and it saves me precious time!

:thanks:

[madshi]

madVR v0.87.15 released

http://madshi.net/madVR.zip

* changed DXVA scaling logic to produce proper quality with AMD drivers
* improved DXVA color space conversion performance
* new trade option "use DXVA chroma upscaling when doing native DXVA decoding"
* new trade option "use DXVA chroma upscaling when doing DXVA deinterlacing"
* new trade option "lose BTB and WTW if it improves performance"
* added scaling algorithm information to OSD
* added 3dlut split screen mode (can only be activated via key shortcut)
* added a few stability fixes/workarounds
* fixed: #033: display mode changer sometimes didn't switch to 75hz
* fixed: #176: no image on portrait (rotated) displays
* fixed: #199: decimation didn't work with 4:4 cadence (PAL 50p)
* fixed: #201: decimation didn't work with 4:2:2:2 cadence
* fixed: #203: cadence info sometimes went "unknown" in debug OSD
* fixed: #205: XySubFilter subtitles sometimes weren't visible
* fixed: #213: bad edit detection didn't work with 6:4 cadence (ATSC 60p)
* fixed: #222: crash when using a large number of shaders
* fixed: #227: Zoom Player OSD "pause" message sometimes wasn't shown
* fixed: #230: madVR refresh rate changer caused DVD playback to break
* fixed: #233: shared NVidia/AMD/Intel GPUs (e.g. Optimus) showed black screen
* fixed: #254: madVR 0.87.14 sometimes crashed when using XySubFilter
* fixed: #255: original system timer resolution wasn't restored on unload
* fixed: #257: OSD information sometimes shows "1.#J days"
* fixed: crash when decreasing GPU queue size
* removed software decoders
* removed trade option "don't use "copyback" for DXVA deinterlacing"
* removed trade option "don't use "copyback" for DXVA decoding"
* removed option "use OpenCL to process DXVA NV12 surfaces"
* removed option "use alternative interop hack (not recommended, AMD only)"
* removed option "use managed upload textures (XP only)"
* added support for ZoomPlayer's mouse scroll zoom functionality
* "Exclusive/Windowed" OSD messages don't overwrite other messages, anymore
Don't get a shock, please. I've finally (?) removed the software decoders from madVR. Some people will be happy, maybe some won't. But in the end, I haven't updated them in years, and LAV Video Decoder should really be superior in every way. So there wasn't really any point keeping them in madVR. I added them at a time when LAV Video Decoder didn't exist yet.

Mostly v0.87.15 is about fixing bugs, and improving DXVA related stuff. Some of these changes go a bit deeper than previous v0.87.x minor releases, so a few new bugs could eventually show up. If so, please let me know.

[Sm3n]

Thx so much for the update Mr ;)

[ryrynz]

No shocks.. a nice eyebrow raise though. Very nice to see this release come through, I figured the decoders would have to get the chop sooner or later due to them being quite out of date now.
Hope to see some bigger changes this year, things have been a bit slow over this way so far.

Glad to see the scaler info in the OSD as well, been wanting to see there that at times..

[sneaker_ger]

* changed DXVA scaling logic to produce proper quality with AMD drivers
* new trade option "use DXVA chroma upscaling when doing native DXVA decoding"
* new trade option "use DXVA chroma upscaling when doing DXVA deinterlacing"
I see these are enabled by default. Are they really that good on all AMD cards/drivers?

[tobindac]

"use DXVA chroma upscaling when[..]"

Can you explain this setting? I use the internal LAV on mpc-hc to do DXVA native decoding but the new OSD reports the nnedi3 setting I had for upscaling. Does it really trade quality by the way, or is it just an alternative processing route?

[kasper93]

DXVA chroma upscaling use built-in scaling in your GPU. It is faster, but most likely offers lower quality than madVR's algorithms (at least some of them). But don't be sacred chroma scaling is not that critical and if fact it is common to use less demanding algorithm to save some computing power. DXVA scalling should be sufficient for Chroma.

I believe the reasoning behind this change is to give better performance for DXVA users out of the box. If they use DXVA it is most likely that they want performance.

[aufkrawall]

Isn't chroma upscaling on Intel done via Lanczos?
Maybe it's about time to test various DXVA scaling algorithms again (Broadwell, Tonga, Maxwell GTX 960).

However, I think a GTX 960 doesn't really consume noticeably more when Jinc3 AR is used instead of DXVA for chroma, since chroma scaling usually doesn't have a significant performance impact anyway.

[tobindac]

DXVA chroma upscaling use built-in scaling in your GPU. It is faster, but most likely offers lower quality than madVR's algorithms (at least some of them).

I suspected the new setting does something other than just changing the algorithm the way we change it manually in settings. It refers to "decoding". But decoding is now removed from madvr, and when I use native DXVA decoding in LAV, the new madvr OSD still reports the nnedi3 algorithm I had set.

[kalston]

Nice update.

Anyone else ditched the fullscreen exclusive mode completely in favour of the windowed overlay mode btw? Performance for me is about the same (say 1-2ms increased rendering times at the most) but it has the advantage of not enabling g-sync* and having perfectly smooth transitions between windowed and fullscreen (not the slightest dropped or delayed frames or glitches). No tearing issues either despite running with Aero disabled (and thus v-sync along with it). Also, it only outputs 24fps instead of 144hz but I don't see that as being a problem, it's equally smooth. Oh and I can keep the JRiver overlay UI in fullscreen with the audio path info etc. being clearly visible. Really nice.

*disabling g-sync on a per-application basis doesn't work very well with current nvidia drivers, it works with MPC for example but not with JRiver MC20. Having to disable the global g-sync feature every time I want to watch a film is a hassle.

[clsid]

madshi, can you give more details regarding the Optimus fix? That might help the MPC-HC devs to fix similar issues with EVR-CP.

Isn't chroma upscaling on Intel done via Lanczos?Someone said it is comparable in quality, so it probably uses an algorithm similar to Lanczos. The benefit of DXVA scaling is that it doesn't use Shaders, but fixed function stuff on the GPU.
I suspected the new setting does something other than just changing the algorithm the way we change it manually in settings. It refers to "decoding". But decoding is now removed from madvr, and when I use native DXVA decoding in LAV, the new madvr OSD still reports the nnedi3 algorithm I had set. No, it isn't directly related to decoding. It just means that if you are using DXVA decoding, you can use DXVA for other stuff as well without extra overhead. The new options apply to chroma scaling only, not luma scaling.

[vivan]

I have a 6-bit IPS display with really terrible built-in dithering (even perfect gradients have very noticeable banding) and it confirms this In theory setting your display to a lower bitdepth in the madVR "device" setup should result in stronger dithering, which should increase the noise floor slightly, but should decrease banding artifacts.
Dithering to 8 and even 7 bit depth is not enough, it looks good only at 6.

However there's no one oddity that I can't explain: when dithering to a lower bitdepth some parts of the image are shifted by ~1 pixel. For example bottom half of the image is moving here:
8 bit http://i.imgur.com/Rd3SIlm.png
6 bit http://i.imgur.com/4rHnHMe.png
At first I thought it's a madVR bug, but then I compared screenshoots on other displays and they don't show this difference. Same happens with my own dithering. I wonder what my display is even doing...


The main problem of DXVA-things is that they're limited to 8 bit precision. It leads to banding and extra noise (from dithering before it).
Lanc3+AR: http://firepic.org/images/2015-03/30/mhg6xqrhqr6f.png
DXVA: http://firepic.org/images/2015-03/30/kzuelukvcncj.png
(2x upscaling)

I wonder if it would be noticeable on chroma...

[madshi]

Can you explain this setting? I use the internal LAV on mpc-hc to do DXVA native decoding but the new OSD reports the nnedi3 setting I had for upscaling.
Are you using NNEDI3 for chroma or image/luma upscaling? And are you really doing native DXVA decoding or maybe copyback DXVA?

I believe the reasoning behind this change is to give better performance for DXVA users out of the box. If they use DXVA it is most likely that they want performance.
Exactly.

madshi, can you give more details regarding the Optimus fix? That might help the MPC-HC devs to fix similar issues with EVR-CP.
I'm not fully sure the fix is working yet. I don't have an Optimus laptop to test this. I suspect that the VSync scanline APIs (GetRasterStatus etc) don't work properly on Optimus laptops. So the fix is make sure rendering still works (more or less) even those APIs don't work.

The main problem of DXVA-things is that they're limited to 8 bit precision. It leads to banding and extra noise (from dithering before it).
Lanc3+AR: http://firepic.org/images/2015-03/30/mhg6xqrhqr6f.png
DXVA: http://firepic.org/images/2015-03/30/kzuelukvcncj.png
(2x upscaling)
True. That shouldn't harm when using DXVA decoding/deinterlacing, though, because those are usually 8bit, anyway. So the new DXVA trade for quality options shouldn't suffer much from the 8bit limitation.

[Vyral]

Thanks for the new version madshi !

* added scaling algorithm information to OSD
Nice ! I don't need to open madVR settings to make sure the right scaling algorithms are used anymore.

* removed option "use alternative interop hack (not recommended, AMD only)"
The original interop hack for AMD GPU is still here, right ?

[vivan]

For some reason new version detects some 1080p videos (.m2ts from BD, .mts from camera) as BT.601.
http://i.imgur.com/8mL1KOe.png

0.87.14 detects them as BT.709.

[madshi]

The original interop hack for AMD GPU is still here, right ?
Not sure what you mean. The v0.87.15 OpenCL behaviour should be identical to the v0.87.14 default setup.

For some reason new version detects some 1080p videos (.m2ts from BD, .mts from camera) as BT.601.

0.87.14 detects them as BT.709.
Weird! Can you provide a small sample? Probably 10MB should do, just enough so that I can see the incorrect detection.

[vivan]

Sample http://s000.tinyupload.com/index.php?file_id=19984692264598428867
10 MB sample http://s000.tinyupload.com/index.php?file_id=23326137763555941348

[FireFreak111]

Is there a reason I get 0.87.14 when I open the link on any browser? I have tried 11 times, keep getting 0.87.14. Is there anything I can do to not get the seemingly cached version?

[kalston]

Tried simply ctrl + f5 to refresh the cache? Alternatively go here http://www.videohelp.com/software/madVR/old-versions#download

[Vyral]

Is there a reason I get 0.87.14 when I open the link on any browser? I have tried 11 times, keep getting 0.87.14. Is there anything I can do to not get the seemingly cached version?

Try that link : http://www.videohelp.com/software/madVR/old-versions#download

[derpycat]

I've been using madvr for a couple of years, and in that time I've always had LAV Video filter set to DXVA2 copy-back on my AMD card, with the understanding that native doesn't support hardware acceleration, or something like that. I've just always read that AMD users should pick copy-back.

I'm now seeing some people recommend native over copy-back. I gave it a try and I see no difference in GPU load, though native seems to be using about 70mb more Vram on one video (not a big deal). Rendering stats seem almost identical as well. I'm making sure that the LAV Video filter is reporting the correct active decoder each time I change.

Can someone please tell me if native is now the preferred option, and also why I might not be seeing any difference in performance?

[madshi]

Sample
Thanks, will be fixed in the next build.

Can someone please tell me if native is now the preferred option
No, it's not. All the options have their advantages and disadvantages. If one option was clearly preferred, there would be no need to offer an option at all.

[derpycat]

Thanks, will be fixed in the next build.


No, it's not. All the options have their advantages and disadvantages. If one option was clearly preferred, there would be no need to offer an option at all.

Ok. I assumed some of the options were there for compatibility, as is often the case with these things. I was also asking because I couldn't find what those advantages and disadvantages might be. All I found were technical definitions of the two. Could you give me an example of a practical difference?

[madshi]

Simply try them and use what works best for you. I would recommend to use either DXVA copyback, or software decoding, but that's just my personal opinion. Some madVR features don't work with native DXVA, mainly forced film mode.

[huhn]

Ok. I assumed some of the options were there for compatibility, as is often the case with these things. I was also asking because I couldn't find what those advantages and disadvantages might be. All I found were technical definitions of the two. Could you give me an example of a practical difference?

DXVA native doesn't work with other filter like vsfilter. you can't use force film mode or the decimation feature of madVR.

[derpycat]

Alright, thanks. I'll go back to copy-back.

Edit: Turns out I have a file (the only one) that shows a difference between copy-back and software decoding. It's a 120fps clip, and apparently AMD's cards, or at least the drivers, aren't capable of playing back 120fps. I guess I'll stick with software decoding then.

[FireFreak111]

Last thing, assuming the 'Use separate device' options are DXGI options (I'm likely wrong), is there any chance of using the new DXGI flip model (https://msdn.microsoft.com/en-us/library/windows/desktop/hh706346%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396) on Windows 8+ (only the OS needed, no new hardware) for performance, or is that at the player level (MPC-HC)?

Quote from page:
'Performance improvements of DXGI flip model are significant when the app is in windowed mode.'

It would be awesome to see even less CPU copying :).

Also thanks for that link, got a new madVR version before my internet goes for a month.

[mark0077]

Thanks madshi, new version works great. Quick question for anyone. If it has been already answered please delete this, I couldn't find the answer in the guide or from searching.

Does madVR still use the logic that if height > 1024, to use 709 matrix, or should I be using profiles to achieve this? Currently watching blu-rays like Avatar, the matrix is seen to be set to "BT.601 [best guess]" and primaries "SMPTE C [best guess]". I can only assume it should be BT.709 but I'm not sure whether I need to add this to a profile myself?

[e-t172]

mark0077: see above. It's a known issue (http://forum.doom9.org/showpost.php?p=1715367&postcount=28535), it will be fixed in the next build (http://forum.doom9.org/showpost.php?p=1715385&postcount=28542). I guess people should wait until the fix, otherwise they're going to get wrong colors.

[mark0077]

Ahhhh thank you.

[tobindac]

Are you using NNEDI3 for chroma or image/luma upscaling? And are you really doing native DXVA decoding or maybe copyback DXVA?

For chroma, luma upscaling has no nnedi3 option and doubling is turned off. By the way, there is an OSD printing quirk if doubling is turned on, it reports the image upscaling algo as 'chroma'.

The LAV decoding setting was native. By the way, I hear that it may be safer to use copy-back but that's supposed to have higher overheads. Is it safe for quality of image to use native if the playback is stable or can it create subtle quality differences?

Something I noticed is that if the image upscaling algo is set to DXVA2 the chroma upscaling algo is reported to be DXVA too in OSD not matter the chroma algo setting. Is that normal? Not that I would use DXVA image upscaling personally though.

[huhn]

The LAV decoding setting was native. By the way, I hear that it may be safer to use copy-back but that's supposed to have higher overheads. Is it safe for quality of image to use native if the playback is stable or can it create subtle quality differences?

all decoder have the same quality. software is the safest it has the best error handle.

some feature are not usable with DXVA native: http://forum.doom9.org/showpost.php?p=1715388&postcount=28545 . the DXVA copy back over head is so small it doesn't really matter with a modern GPU. the new lavfilter version got a copy back direct version which is even faster.

[huhn]

Something I noticed is that if the image upscaling algo is set to DXVA2 the chroma upscaling algo is reported to be DXVA too in OSD not matter the chroma algo setting. Is that normal? Not that I would use DXVA image upscaling personally though.

there is a new trade quality for performence option that does this. it on by default.
and if i think about that now DXVA native with the new trade quality for performance option can easily have lower quality than copyback or software decoding.

[madshi]

Last thing, assuming the 'Use separate device' options are DXGI options
No, they're not.

"use DXVA chroma upscaling when[..]"

Can you explain this setting? I use the internal LAV on mpc-hc to do DXVA native decoding but the new OSD reports the nnedi3 setting I had for upscaling. Does it really trade quality by the way, or is it just an alternative processing route?
I can't reproduce that here.

there is an OSD printing quirk if doubling is turned on, it reports the image upscaling algo as 'chroma'.
I can't reproduce that here, either.

If you're sure that these are real issues, I'll need a way to reproduce them. Right now, I've tried to use the same settings as you, but it works fine here. So if you can 100% reproduce these issues, please provide me with a full detailed description of the situation: LAV decoder settings (software, copyback, native, whatever). madVR chroma, image and doubling settings, trade quality options, video resolution and target rect (from Ctrl+J debug menu), and what the debug menu says exactly about which algos are active.

Something I noticed is that if the image upscaling algo is set to DXVA2 the chroma upscaling algo is reported to be DXVA too in OSD not matter the chroma algo setting. Is that normal?
Yes. If DXVA image upscaling is active, chroma is also upscaled by DXVA. That is always true, independent of the trade quality options.

[Ge'in]

I have also a strange OSD behavior with luma doubling and a profile for chroma.
You can see that on my screenshot:
http://reho.st/self/b795f0f5819e819f0270702083053cf16273e27a.png

Edit: It's ok, when u use only luma doubling, the chroma part is also upscaled with the image algorithm.
So everything is ok.

[vivan]

This is how it's supposed to be.
Chroma was upsampled from 320x176 to 640x352 according to your "chroma upscaling" settings (nnedi32 for chroma, right?)
Then luma was doubled to 1280x704 (chroma is still 640x352), according to your "image doubling" rule (since you have only luma doubling using nned64 enabled, right?).
And then everything was upscaled (luma from 1280x704, chroma from 640x352) to your target resolution according to your "image upscaling" rule (jinc3 AR, right?).

[Ge'in]

Thx for your clarification. It's now obvious :thanks:

[MS-DOS]

* removed option "use alternative interop hack (not recommended, AMD only)"
Great... That option was the only way for me to use NNEDI normally (1 (https://www.doom9.org/showthread.php?p=1677698#post1677698), 2 (https://www.doom9.org/showthread.php?p=1677728#post1677728)). Otherwise framerate detection (display xx.xxxxx Hz) now constantly resets to 0s and they both with GPU load start to jump like crazy, and I get stuttering with some presentation glitches reported. Nothing I've tried since then fixed it.

Why did you remove it ?