madVR - high quality video renderer (GPU assisted)

[ryrynz]

Damn, these are the responses that you get from ignorant folks at GeForce.com forums regarding inclusion of D3D9 - OpenCL interop into NVidia's Windows 10 drivers to support madVR's features - https://forums.geforce.com/default/topic/867318/nvidia-officially-exits-home-theater-arena-for-good-/#4644241 ....

Don't worry about it, the interop isn't needed for NNEDI3 if madshi changes his code so it works again, apparently it's not a hard modification to make.
So just hold on to the old drivers until madshi fixes it.

[Zachs]

Don't worry about it, the interop isn't needed for NNEDI3 if madshi changes his code so it works again, apparently it's not a hard modification to make.
So just hold on to the old drivers until madshi fixes it.

Yeah not hard at all. Took me a whole 15mins to do a quick hack version. ;)

[madshi]

You mean using copyback? Or D3D11 interop with shared textures? Or SM 5.0? Three possible "solutions". Although OpenCL does seem to be faster, the more "modern" the GPU is, so I'd hate to lose it.

[kalston]

You mean using copyback? Or D3D11 interop with shared textures? Or SM 5.0? Three possible "solutions". Although OpenCL does seem to be faster, the more "modern" the GPU is, so I'd hate to lose it.

That's a bummer, speed is actually quite crucial with NNEDI3...

[aufkrawall]

He didn't say he would drop OpenCL. :)
But I still stink it's important to have a reliable fallback in case OpenCL stops working for whatever reason (that just happened).

[ashlar42]

One question regarding debanding: considering the quality achievable with 10 bit output and quality dithering options... is debanding useful on a 10 bit display when rendering at 10 bit with madVR?

[ryrynz]

One question regarding debanding: considering the quality achievable with 10 bit output and quality dithering options... is debanding useful on a 10 bit display when rendering at 10 bit with madVR?

It all depends on your media source. If you have banding in the source and you want it improved then yes.

[ajp_anton]

When using DXVA native to decode a 1280x718 video, two problems occur that don't with EVR:
1. An extra row (or two?) of grey pixels appear at the bottom (only when DXVA scaling is used), forcing a tiny stretch of the video to fit into 1-2 less pixels.
2. If scaled to 100%, the player crashes.

[michkrol]

I see none of the above on my setup:
MPC-HC 1.7.9.145 (x64) + internal LAVFilters, madVR 0.88.21, Geforce 750Ti (drivers v355.60), Windows 10 (x64).

Provide more info: system specs and sample file?

[Dlget]

updated to 355.60.
Now whenever i try to go into full screen MPC-be crashes.

[XMonarchY]

355.69 out - D3D9-OpenCL no interop, right?

[Ver Greeneyes]

355.69 out - D3D9-OpenCL no interop, right?The release notes (http://uk.download.nvidia.com/Windows/355.69/355.69-win10-win8-win7-winvista-desktop-release-notes.pdf) don't list any changes. They probably just tweaked something to make them work well with the GeForce GTX 950.

[aufkrawall]

Unlikely that it has returned, but the release notes often don't list fixed issues.
It sounds stupid, but it really is that way.

[ajp_anton]

I see none of the above on my setup:
MPC-HC 1.7.9.145 (x64) + internal LAVFilters, madVR 0.88.21, Geforce 750Ti (drivers v355.60), Windows 10 (x64).

Provide more info: system specs and sample file?On a ship with limited internet. Can't upload sample atm, so didn't think of providing more info either, sorry.

Windows 7 x64, MPC-HC (both 32- and 64-bit), LAV.
Intel i5-4200U.

Sample later.

[ryrynz]

The release notes (http://uk.download.nvidia.com/Windows/355.69/355.69-win10-win8-win7-winvista-desktop-release-notes.pdf) don't list any changes. They probably just tweaked something to make them work well with the GeForce GTX 950.

This driver is only for the GTX 950.

[Ver Greeneyes]

Yeah, but that doesn't really mean much. These drivers almost always work just fine on other cards, just need to add your device to nv_disp.inf/nv_dispi.inf. But I doubt they added back D3D9-OpenCl interop, which is the only thing that matters as far as this topic is concerned.

[ryrynz]

Yeah, but that doesn't really mean much. These drivers almost always work just fine on other cards, just need to add your device to nv_disp.inf/nv_dispi.inf. But I doubt they added back D3D9-OpenCl interop, which is the only thing that matters as far as this topic is concerned.

Almost is the key word. But anyway, apparently the interop isn't going to be added back.. so should probably just drop the topic altogether.

[ajp_anton]

When using DXVA native to decode a 1280x718 video, two problems occur that don't with EVR:
1. An extra row (or two?) of grey pixels appear at the bottom (only when DXVA scaling is used), forcing a tiny stretch of the video to fit into 1-2 less pixels.
2. If scaled to 100%, the player crashes.
Windows 7 x64, MPC-HC (both 32- and 64-bit), LAV.
Intel i5-4200U. (GPU: Intel HD 4400)

Sample file:
http://s.ajpanton.se/sample_madVR.mkv

[Zachs]

You mean using copyback? Or D3D11 interop with shared textures? Or SM 5.0? Three possible "solutions". Although OpenCL does seem to be faster, the more "modern" the GPU is, so I'd hate to lose it.

Well FWIW on NVidia at least, anything less than 128 neurons (i.e. 64 and below), the SM5.0 NNEDI3 trumps the OpenCL version using avoid branches optimization. On Intel with P4600 (which is still very modern), the SM5.0 version is ~2x faster than the OpenCL version across the board with the "Alt weight access + scalar small code" optimization option. For example, upscaling 720x576 to 1080p the P4600 renders in 31ms (16/16 neurons) making it perfectly acceptable to watch anything 30fps and below. With the OpenCL version, it needs 58ms. At the end of the day it really comes down to how well the driver/compiler maps the code to its underlying hardware.

Anyway I was talking about the new interop requiring only 15 mins to implement (EDIT: for MPDN - YMMV). To answer your first question, yes you can now use OpenCL NNEDI3 on the latest Nvidia drivers with MPDN, but some users prefer the SM5.0 version anyway as it's simply faster for them.

[x7007]

Well FWIW on NVidia at least, anything less than 128 neurons (i.e. 64 and below), the SM5.0 NNEDI3 trumps the OpenCL version using avoid branches optimization. On Intel with P4600 (which is still very modern), the SM5.0 version is ~2x faster than the OpenCL version across the board with the "Alt weight access + scalar small code" optimization option. For example, upscaling 720x576 to 1080p the P4600 renders in 31ms (16/16 neurons) making it perfectly acceptable to watch anything 30fps and below. With the OpenCL version, it needs 58ms. At the end of the day it really comes down to how well the driver/compiler maps the code to its underlying hardware.

Anyway I was talking about the new interop requiring only 15 mins to implement (EDIT: for MPDN - YMMV). To answer your first question, yes you can now use OpenCL NNEDI3 on the latest Nvidia drivers with MPDN, but some users prefer the SM5.0 version anyway as it's simply faster for them.

Hey, how can I use the OpenCL NNEDI3 ? with CUVID or DXVA2 write-back ?
Can you explain .
Thanks

[Zachs]

Hey, how can I use the OpenCL NNEDI3 ? with CUVID or DXVA2 write-back ?
Can you explain .
Thanks

My reply was specifically for madshi only. I have no idea how to answer your question for madVR as I don't use it. If you mean to ask how you can use OpenCL NNEDI3 with MPDN, kindly post in the MPDN thread instead.

Cheers.

[madshi]

Well FWIW on NVidia at least, anything less than 128 neurons (i.e. 64 and below), the SM5.0 NNEDI3 trumps the OpenCL version using avoid branches optimization. On Intel with P4600 (which is still very modern), the SM5.0 version is ~2x faster than the OpenCL version across the board with the "Alt weight access + scalar small code" optimization option. For example, upscaling 720x576 to 1080p the P4600 renders in 31ms (16/16 neurons) making it perfectly acceptable to watch anything 30fps and below. With the OpenCL version, it needs 58ms. At the end of the day it really comes down to how well the driver/compiler maps the code to its underlying hardware.
From reading the MPDN thread my impression was that older NVidia GPUs were roughly the same with SM5.0 and OpenCL and that newer NVidia GPUs (Maxwell) still performed faster with OpenCL. Has this changed with recent drivers? I'm aware of that Intel likes SM5.0 much more. Thanks...

[Sunset1982]

@xAURUS:

Ok so I tried to figure out the mysterious dropped frames in Win 10.

Tried to replace madvr with EVR, no difference. Tried moving back to 32-bit mpc-hc/lav/madvr. No difference.
Tried using ReClock. No difference. Went back to madvr 88.16. No difference.

The only thing that actually works is to restart the computer, then typically the first movie I watch has no mysterious dropped frames.
After that, it's the same thing.

So I guess this must be something with Win 10. In either case, it's extremely annoying.

did you try the latest insider build 10525 of Win10? maybe this works better?

[aufkrawall]

128 neurons NNEDI3 quadrupling on GTX 980 with 355.60
OpenCL (seems to be working fine with Zachs' new implementation):
GPU load: ~53%
clock: 1421Mhz
power consumption: ~72%
rendering time: ~25.6ms

SM 5.0 Avoid Branches:
GPU load: ~63%
clock: 1421Mhz
power consumption: ~67%
rendering time: ~31.8ms

Prefer Vector:
GPU load: ~80%
clock: 1421Mhz
power consumption: ~80%
rendering time: ~39.5ms

100% power consumption would be ~180 Watts.

[madshi]

So OpenCL does seem to be still faster with Maxwell GPUs, right?

Since OpenCL vs. SM5.0 is like compute power vs shader power (so to say), I suppose that the more the GPU architecture is optimized for compute performance, the higher the probability that OpenCL will be faster than SM5.0. Which also means that newer GPU architectures are likely to favor OpenCL. But then, a lot depends on compilers, too. And Intel seems to be quite different, in any case.

[aufkrawall]

So OpenCL does seem to be still faster with Maxwell GPUs, right?

Yes. However, the advantage naturally shrinks when using less neurons and further effects like AdpativeSharpen or SuperRes. So, in many situations there probably won't be a difference "perceived".

Now questions is, does the way Zachs found for OpenCL look secure for the future?

[Arm3nian]

Can someone explain why d3d9 has to be used? Why not 10, 11 or 12? Does dxva not support those or something? Isn't this microsoft's fault for not updating their stuff instead of nvidia removing backward compatibility or incompatibility in general.

Also, I don't think new gpu's like the 980ti or 950 even have drivers, on any operating system, that support d3d9 interop.

[Xaurus]

@xAURUS:



did you try the latest insider build 10525 of Win10? maybe this works better?
I did not try that yet. But I am surprised, if this is a Win 10 issue there should be much more info on this already. But I can't find much.

What I will do today is to downgrade the Nvidia drivers to the version that can use NNEDI3.

Right now, my HTPC feels useless. Can't watch anything without pulling my hair out because of these mysterious dropped frames.

[kalston]

Also, I don't think new gpu's like the 980ti or 950 even have drivers, on any operating system, that support d3d9 interop.

Well my 980 ti does NNEDI3 256 neurons for 720p to 1440p with ~25ms render times on my Win 7 64 machine so I'm pretty sure that's incorrect.

[Zachs]

So OpenCL does seem to be still faster with Maxwell GPUs, right?

Since OpenCL vs. SM5.0 is like compute power vs shader power (so to say), I suppose that the more the GPU architecture is optimized for compute performance, the higher the probability that OpenCL will be faster than SM5.0. Which also means that newer GPU architectures are likely to favor OpenCL. But then, a lot depends on compilers, too. And Intel seems to be quite different, in any case.

Well it would seem Maxwell is the odd one out - the other simpler explanation could be that they simply haven't optimised the driver as much as they have for the more mature architectures.

[madshi]

Well, it's Maxwell and AMD. So basically those who're strong at computing, no? But I don't really know, I'm just guessing...

[nevcairiel]

Well it would seem Maxwell is the odd one out - the other simpler explanation could be that they simply haven't optimised the driver as much as they have for the more mature architectures.

If by "odd one out" you mean OpenCL is stronger, then thats expected as NVIDIA changed the architecture in Maxwell to cover a lot of ground in computing.

[Zachs]

By "odd one out" I mean it is different to Fermi and Kepler. Fermi was strong in computing too.
But, is shader not computing? Is it not possible for Nvidia to map the shader version to the OpenCL version in its entirety in the future with driver optimizations?
We don't know any of that - all we're doing here is pure speculation, and a bit of a waste of time to be honest since there's no way to find out, or tell the future.

[Asmodian]

Also, I don't think new gpu's like the 980ti or 950 even have drivers, on any operating system, that support d3d9 interop.

Using 853.30 or .49 d3d9 interop worked fine on my 980ti in Windows 10.

[amayra]

i manage to make madvr work in Wine 1.7.50 somehow but is crash later i will post log after they release "CSMT" and "staging" edition

[Akeno]

This has been spanning on for the past couple of pages but can anyone give a short run down on what problems madVR has with windows 10?
So far, it sounds like nnedi3 still doesn't work on nvidia cards due to missing opencl implementation and something about d3d9 interop although I don't know what effects that has on madVR.

[Arm3nian]

Using 853.30 or .49 d3d9 interop worked fine on my 980ti in Windows 10.

Thanks worked for me also. Now that I've tried it, super-xbr looks identical to nnedi3 in chroma upscaling and image chroma and luma doubling watching bluray on a 4k screen. The only difference is that super-xbr doesn't turn my room into an oven.

[noee]

i manage to make madvr work in Wine 1.7.50 somehow but is crash later i will post log after they release "CSMT" and "staging" edition

Start another thread, maybe in the Linux section....I'm trying the same thing....

[Fadeout]

Quick question: does anyone know why MadVR deinterlacing looks much better than Yadif on VLC and other applications?

Windows Media Player gives a similar result to MadVR, it's only Yadif that makes things less smooth. And this is a problem because I'm trying to encode the video to progressive, but the only options for the decoding only produce results that look like Yadif, and so everything is less smooth.

[nussman]

madVR can use GPU Deinterlacing like WMP does. :)

[vivan]

Windows Media Player gives a similar result to MadVR, it's only Yadif that makes things less smooth. And this is a problem because I'm trying to encode the video to progressive, but the only options for the decoding only produce results that look like Yadif, and so everything is less smooth.Yadif is fast CPU deinterlacer, madVR and WMP use DXVA deinterlacing (GPU-based).

If you want proper offline deinterlacing - use QTGMC.

[Fadeout]

I need to convert a video to 1080i to 1080p, but the quality is TERRIBLE.

Is there a way to get a similar input quality that I see in MadVR/WMP and use it in StaxRip or MediaCoder? Can't they use DXVA for decoding as well?

[e-t172]

Yadif that makes things less smooth

Are you sure you're using Yadif in "double framerate" mode? If not, that would explain why you find Yadif less smooth.

[Fadeout]

Are you sure you're using Yadif in "double framerate" mode? If not, that would explain why you find Yadif less smooth.

Yeah, that seems the case.

When enabling Yadif within LAV Video options at 50/60 video mode I get the same smoothness I have normally, whereas in "film" mode I get the standard Yadif I usually see.

The problem is I cannot encode that properly.

[Dogway]

Has nnedi (doubling) some limitations? I can use it with the internal iGPU, but it fails to load with the nvidia card. The CPU is a N3540 and the card is a GT 820M.

[vivan]

It requires feature (D3D9 OpenCL interop) that nvidia recently removed from drivers (at least for Windows 10).
http://forum.doom9.org/showpost.php?p=1731949&postcount=32210

[kuchikirukia]

Is there a way to get MPC-HC's status window to show the video framerate when using madVR? It worked under XP, but ever since I upgraded to Windows 8.1 and then 10 it syncs to my monitor refresh rate. Using System Default renderer shows the correct frame rate.
I do a lot of encoding and having the frame rate is a big help when working with interlaced sources.

http://s17.postimg.org/4dn8lsjsr/Untitled.jpg (http://postimg.org/image/4dn8lsjsr/)

[Dogway]

It requires feature (D3D9 OpenCL interop) that nvidia recently removed from drivers (at least for Windows 10).
http://forum.doom9.org/showpost.php?p=1731949&postcount=32210

Thanks for the help! Yes, nvidia at it again... : /
By chance do you know since what version they removed the feature, I'm going to do some searches in any case.

edit: These are the oldest drivers for Win10: 352.63 Beta and 352.84.
edit2: at least last version 355.60 includes what madshi claimed to be the proper way, "cl_khr_dx9_media_sharing", although I guess he has to work on it for nnedi come back.

[zvans18]

i seem to have a problem where when nnedi3 quadrupling and SR is enabled, the chroma changes to jinc, but when SR is disabled it's back to nnedi3 like it's supposed to be

madvr 88.21 + mpc-hc 1.7.9 x64
win 8.1 with 355.60

[Dogway]

Update, couldn't get the above versions (352.63 Beta and 352.84 -notebook versions here-) to recognize my card (820M) on Windows10, but 353.30 did and there nnedi works, but as noted before only if I choose DXVA on LAV Video, well I can't see why not. Yet the 820M is very underpowered, it struggles to keep up with nnedi16 (only luma), but that's another story.


BTW, is it possible to include duration to profile rules?