madVR - high quality video renderer (GPU assisted)

[JPulowski]

Currently using NVIDIA GTX690 with 350.12 WHQL driver. The NNEDI3 artifact issue seems to be fixed for 64-bit madVR. Did not test it yet with 32-bit.

Also I have some questions:

What is the optimal way of getting maximum performance for video playback from multi-gpu/SLI cards?
Are "Use a separate device for presentation" and "Use a separate device for DXVA processing" options related with multi-gpu somehow? If not what are they exactly?

Thanks. :)Okay, I did some testing. Here are my findings for the multi-gpu/SLI users:

madVR is not SLI friendly, disabling SLI seems to improve rendering queue. (Interestingly, rendering time stays pretty much the same.)
SLI needs to be disabled completely from "Configure Multi-GPU, Surround, PhysX" menu from NVIDIA Control Panel. I tried forcing NVIDIA predefined SLI mode to single from NVIDIA Inspector for MPC-HC profile but it did not work.


Now using Single-GPU mode, one of the cards have zero work load and the other one does all the work. And I wonder if it is possible to use the empty one for CUVID processing or madVR processing? I played with "Use a separate device for presentation" and "Use a separate device for DXVA processing" and they don't do anything at all. Any suggestions?

[huhn]

not really possible.
CUVID doesn't really use the GPU it uses the same ASIC as DXVA.
you could run SVP openCL part on the not used GPU.

[Asmodian]

Okay, I did some testing. Here are my findings for the multi-gpu/SLI users:

madVR is not SLI friendly, disabling SLI seems to improve rendering queue. (Interestingly, rendering time stays pretty much the same.)
SLI needs to be disabled completely from "Configure Multi-GPU, Surround, PhysX" menu from NVIDIA Control Panel. I tried forcing NVIDIA predefined SLI mode to single from NVIDIA Inspector for MPC-HC profile but it did not work.


Now using Single-GPU mode, one of the cards have zero work load and the other one does all the work. And I wonder if it is possible to use the empty one for CUVID processing or madVR processing? I played with "Use a separate device for presentation" and "Use a separate device for DXVA processing" and they don't do anything at all. Any suggestions?

I notice a large drop in render times with SLI off, three quarters of the time when the GPU is using the same clock speed (32 ms to 24 ms). I believe this is related to needing to copy memory from one GPU to the other when using SLI, with SLI enabled one GPU is idle but their memory usage is identical. I am using SLI Titans but I imagine this is true for any SLI or Crossfire setup.

The "use separate device" options are not talking about hardware devices but instances of DirectShow software devices.

[cvrkuth]

List of display modes: 1080p23, 1080p24, 1080p50, 1080p59, 1080p60

There was issue in the 32 bit version, v0.86.10. Madshi then do workaround and issue was gone.

I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance " (old path), my screen stays in 24hz.

Because of problem reported above, I uncheck 'Present Several frames in advance " and stay with FSE (old path) for now.
I noticed that rendering time is higher (24 ms vs 5.5) ms but Present time is lower than new path (0.01 vs 0.04). I have no drop frames or other playback issues.

I'm curious .. which is better for me?

[har3inger]

Hi madshi, remember the issue from a year back where the directcompute ordered dithering would result in black screen for my laptop?

Well, I've been poking around again trying to get things to work, but still have no luck. Basically, if I try to get my ATI 8870m to render the video (which is necessary for smooth playback), I get a black screen and a strange ctrl+J OSD that looks like it's drawing/blending on top of itself instead of refreshing each frame. More specifically, it looks like several OSD frames get stacked up so that static text becomes pure white instead of the normal alpha'd grey, and changing text (like the render time stats) stack up and become a big mess of overlapping numbers. The whole thing also flickers a bit. When the title of the file is shown in a box at the top left when you first open it, with ordered diffusion is on that box also flickers rapidly. All of this happens whether smooth motion is on or off. Audio is not affected.

If I force the HD4000 as the render device, everything seems to draw properly but of course has render times >160ms after scaling. I'll post a debug log in case it's helpful. It represents a few seconds of opening a movie with Ordered Diffusion 1 on using the discrete GPU. During this time I see a flickering title box and stacked up flickering OSD over a solid black video frame.

I'm now running Win 8.1 with 14.12 ATI drivers and Samsung OEM intel drivers (10.18.10.3304, 9/9/2013). MPC-HC 64 bit, madvr latest version, LAV filters/splitter.

I realize I'm probably a very isolated case of ordered diffusion not working, but if you have the time, I'd appreciate you taking a crack at figuring out why I'm having this problem. At the very least, since nnedi and OpenCL features first came out, madvr has learned to ignore unsupported settings and no longer get blue screens when I toggle them!

Log:
https://www.dropbox.com/s/78vgkslofsbbwa1/madVR%20-%20log.txt?dl=0

[Jtacdf]

Is Madvr x64 doing something different from it's x86 version in it's functionality for d3d9? I could hook a gpu monitoring software, msi afterburner, onto mpc-hc x64 with EVR. Madvr x64 refuses to work with it while the x86 version works fine.

EVR x64
https://www.dropbox.com/s/8243g0j2mo49gdq/evr%20msi%20ab%20x64.jpg?dl=0

Madvr x86
https://www.dropbox.com/s/7ggh0kog3dhjfwd/madvr%20msi%20ab%20x86.jpg?dl=0

[cremor]

Anyone else not getting NNEDI3 to work at all with Nvidia driver 350.12? My madVR immediately crashes when NNEDI3 is activated since I updated the drivers today.

[kalston]

Nope, using NNEDI3 64 without any issue. GTX 970 and 350.12 drivers / Win 7 x64

[iSunrise]

Does anyone still have a copy of madshi's OpenClSpeedTest.zip laying around? Unfortunately it's not available anymore on http://madshi.net/.

[sneaker_ger]

/edit: removed on request by madshi

[iSunrise]

/edit: removed on request by madshi
Man, that was fast, thanks a lot!

EDIT: Link removed, reason stated above.

[madshi]

/edit: removed on request by madshi
Thanks.

[madshi]

SVP may have a 64bit version to accompany this soon (http://www.svp-team.com/forum/viewtopic.php?pid=48278#p48278).
Nice!

I'm not well aware of the signing procedure, but what does this mean?
http://abload.de/thumb/sm9mu99.png (http://abload.de/image.php?img=sm9mu99.png)
Is that a madVR file? On my PC when looking at the details of a madVR file I'm getting "GlobalSign" instead of "Symantec".

same as tobindac on (un)install.bat. It does not work as intended without the manual "run as admin".
Win 8.1 with the latest updates.

EDIT: it shows that madvr was (un)registered but that doesn't seem to be the case when I look at the Output Renderer Settings on both mpc-hc & potplayer.
Strange. Works here. Will run some further tests... :(

Found what caused it - it's the new "Lose BTB and WTW if it improves performance" option introduced with 0.87.15.
Voting to not have it enabled by default.
It doesn't make much sense that this option causes crashes! Sounds like a very bad NVidia driver bug. Anyway, I'll see if I can detect this problem somehow. If not, I may have to disable that option by default.

Madshi, I'm seeing some dithering on pure blacks when the trade quality option 'use DXVA chroma upscaling' is enabled when doing native DXVA decoding on my HD4000
giving some pixels what would be with the other chroma upscalers, 0,0,0 a value of 0,0,1.

Might I suggest maybe that those use DXVA chroma options are not enabled by default? Because at least on Intel graphics the chroma upscaling is god awful nearest neighbor and the visual difference is night and day.
Hmmm... Intel is a special case. I may have to add some extra code to make this work better for Intel. But I would really prefer having these options enabled by default (especially on Intel) because they bring a nice performance benefit. Obviously nearest neighbor is not acceptable.

Any chance of putting (not recommended) beside the nearest neighbor GPU setting BTW? Just so people stay clear of it if they don't know what they're doing? I do wonder if really that's even useful aside from some sort of testing.
It's mainly for testing. It will most probably be removed for v1.0. But until then it's going to stay. I'll see if "not recommended" fits in there nicely. If so, I might add it.

Symantec has told me they have removed the false positive detection of mvrSettings32.dll
Great - thanks! :)

What is the optimal way of getting maximum performance for video playback from multi-gpu/SLI cards?
Disable SLI. I'm not doing anything special to make things run good or bad on SLI, but it seems the way madVR works is not very SLI friendly, for some reason. According to what I've read here in this thread, most users have a better madVR experience if they disable SLI.

"Use a separate device for presentation" and "Use a separate device for DXVA processing" options related with multi-gpu somehow? If not what are they exactly?
Nothing to do with SLI. These options sometimes help some users get better results.

So my question to you is: will there be some sort of MadAudio or something in the future as a replacement for ReClock?
No.

Where does madVR save freeze reports? I can't find them, trying to make one because it freezed again. Found them on my desktop... Silly me =)
Thanks. Will have to create a test build for you, some time later...

@madshi: Any plans to update madTestPatternSource for x64?
Hmmmm... Good question. That one is written in Delphi, not sure how easy it will be to update it to x64. I'll put it on my to do list. Might take a while, though.

Now that madshi has given us 64-bits in madVR, I wonder how close he's getting to a 1.0 release
Every release hopefully brings us nearer, but I'm still not really near.

Because you're wrong?

...Consequently the motion smoothness depends on proper timestamps. If the timestamps (or audio clock) contain jitter, the playback will contain jitter, too. So even if Reclock might not be needed to avoid frame drops/repeats, anymore, when using madVR's new FRC algorithm, you might still want to use Reclock, because it provides a stable and reliable audio clock with very low jitter...
Ugh madshi was correct in his statement, just like everything he says. That post is just old, and doesn't apply anymore. There is a clock for your cpu, gpu, and audio. Other renderers can access the same clock that reclock can. Madshi has stated often that reclock is not needed for SM. If you don't believe me, try SM with reclock and without, there is no difference in IQ...
I agree, and in addition, I wonder if it ever applied to anything, even on XP. I think madshi was just being overly cautious by making clear that the clock needs to be high quality for SM to work correctly, but there's no evidence that people encountered bad DirectShow clocks. I certainly don't remember anyone on this thread reporting an issue with SM that could be traced back to a bad clock.
FWIW, at the time I did see some logs from users where it was evident that the audio clock had a pretty high jitter in it. Whether this would really be visible with SM on or not is another question. I can't answer that. But for me Reclock reliably produces smoother timestamps. This is also visible in the "clock deviation" measurement. It converges much faster to the "final" value than when using a "normal" audio renderer.

Personally, though, I haven't used Reclock in years. My HTPC has a 1:1 refresh rate / framerate match, so I need neither Reclock nor SM.

HI，I have very high present time in my optimus laptop.
about 8~10ms
I have an M14x R2 Optimus laptop with an HDMI and a miniDP port. I remember having a similar problem to yours when I was using the HDMI port but not when using the miniDP port. It turned out that the HDMI port is wired to the Intel GPU while the miniDP was wired to the Nvidia GPU. I'm not sure why it had a high present time only when connected to the iGPU but I solved my issue by using the miniDP.
Interesting. Yes, when using an output port which is hard wired to the Intel GPU, each rendered frame must be copied from the NVidia GPU to the Intel GPU, which costs a lot of time. If you can't use an NVidia output port, my best workaround suggestion would be to:

1) Try your best to achieve a 1:1 refresh rate / framerate match. E.g. play Blu-Ray movies at 23.976Hz. This should help a lot.
2) If you can't do 1), then you may want to disable the "present several frames in advance" option. But this only applies if 1) is not possible and for Optimus users in this specific situation.

Other than that there's not much I can suggest...

Confirmed this green artifact with NNEDI 3 chroma upscaling and double/quadrouble Chroma resolution; darker screen (look like scanlines) with double/quadruple Luma resolution even with the newest 15.4 beta driver. These issues only occurred with MadVR 64 bit, my VGA card is R9 290X and in Windows 8.1 environment.
For any of you guys that has problem getting x64 nnedi3 working with AMD gpu, a temporary workaround (I hope) is to rename your media player exe to "ForceSingleGPU.exe".
I've gotten it working without issues that way.

Disregard the above, the issue persist again.
Just tried it, didn't work for me. But I'm fine with having image doubling off until such a time that it's fixed. I just wanted to bring the issue to the dev's attention and see if anyone else had it.
Strange. For my NNEDI3 works just fine in x64. AMD 7770, Windows 8.1 x64. Not sure what's going on there on your PCs. Try to reinstall the driver/OpenCL, maybe?

Now using Single-GPU mode, one of the cards have zero work load and the other one does all the work. And I wonder if it is possible to use the empty one for CUVID processing or madVR processing?
Currently I have other priorities than optimizing for SLI setups. And even if I wanted to that, I'd first have to get an SLI setup in the first place. Probably one for NVidia and one for AMD. Urghs. Not much hope for that anytime soon.

Because of problem reported above, I uncheck 'Present Several frames in advance " and stay with FSE (old path) for now.
I noticed that rendering time is higher (24 ms vs 5.5) ms but Present time is lower than new path (0.01 vs 0.04). I have no drop frames or other playback issues.

I'm curious .. which is better for me?
I don't know, try both and use what works better.

Hi madshi, remember the issue from a year back where the directcompute ordered dithering would result in black screen for my laptop?

Well, I've been poking around again trying to get things to work, but still have no luck. Basically, if I try to get my ATI 8870m to render the video (which is necessary for smooth playback), I get a black screen and a strange ctrl+J OSD that looks like it's drawing/blending on top of itself instead of refreshing each frame. More specifically, it looks like several OSD frames get stacked up so that static text becomes pure white instead of the normal alpha'd grey, and changing text (like the render time stats) stack up and become a big mess of overlapping numbers. The whole thing also flickers a bit. When the title of the file is shown in a box at the top left when you first open it, with ordered diffusion is on that box also flickers rapidly. All of this happens whether smooth motion is on or off. Audio is not affected.

If I force the HD4000 as the render device, everything seems to draw properly but of course has render times >160ms after scaling. I'll post a debug log in case it's helpful. It represents a few seconds of opening a movie with Ordered Diffusion 1 on using the discrete GPU. During this time I see a flickering title box and stacked up flickering OSD over a solid black video frame.

I'm now running Win 8.1 with 14.12 ATI drivers and Samsung OEM intel drivers (10.18.10.3304, 9/9/2013). MPC-HC 64 bit, madvr latest version, LAV filters/splitter.

I realize I'm probably a very isolated case of ordered diffusion not working, but if you have the time, I'd appreciate you taking a crack at figuring out why I'm having this problem. At the very least, since nnedi and OpenCL features first came out, madvr has learned to ignore unsupported settings and no longer get blue screens when I toggle them!
The log doesn't really help much, unfortunately. I'd have to be able to reproduce the issue on my PC in order to do something about it.

Is Madvr x64 doing something different from it's x86 version in it's functionality for d3d9? I could hook a gpu monitoring software, msi afterburner, onto mpc-hc x64 with EVR. Madvr x64 refuses to work with it while the x86 version works fine.
The x64 version is pretty much identical to the x86 version.

[madshi]

One polite request to all madVR users:

Please don't (re-)distribute any files from me that aren't available on my server, anymore, without asking me first. I may have had a good reason to remove them from my server. Thanks!

(Obviously this doesn't apply to official madVR/eac3to builds, or anything else that is still available on my server.)

[kasper93]

@madshi: I found that RivaTuner Statistics Server prevents madTPG from running it doesn't even show its window, just leaves ghost process. It happens when "Custom D3D support" is enabled, even if madTPG.exe is on exclude list and/or statistics are disabled completely. I didn't know where to report this issue, but I figured it might be better if you contact RTSS developer with more information if you care about this issue. Or just fix/workaround the issue. :)

[madshi]

Will put it on my to do list.

[ikarad]

Thanks madshi for x64 version.
Between madvr32+mpc-hc32+lav32 and madvr64+mpc-hc64+lav64, there is a big boost in performance.

one question:
What means present in average stat?
http://img15.hostingpics.net/thumbs/mini_493003mpchc642015041921260683.jpg (http://www.hostingpics.net/viewer.php?id=493003mpchc642015041921260683.jpg)

[huhn]

Thanks madshi for x64 version.
Between madvr32+mpc-hc32+lav32 and madvr64+mpc-hc64+lav64, there is a big boost in performance.

one question:
What means present in average stat?
http://img15.hostingpics.net/thumbs/mini_493003mpchc642015041921260683.jpg (http://www.hostingpics.net/viewer.php?id=493003mpchc642015041921260683.jpg)

the time it takes to present the frame.

your stats are terrible. you are most likely getting strong tearing. are you using windows 7 with disabled aero?
if yes activate aero.

[ikarad]

the time it takes to present the frame.
Thanks.
I think it's was rendering in average stat. What are the difference between rendering and present?


your stats are terrible. you are most likely getting strong tearing. are you using windows 7 with disabled aero?
if yes activate aero.
It's not the good stats
My stats are good.
http://img15.hostingpics.net/thumbs/mini_369008mpchc642015041922253421.jpg (http://www.hostingpics.net/viewer.php?id=369008mpchc642015041922253421.jpg)

[huhn]

Thanks.
I think it's was rendering in average stat. What are the difference between rendering and present?

rendering is scaling YCbCr->RGB conversion, SM and other stuff that is done with the picture.

present is just presentation. there is no need to see high values here it's such a simple task for GPU. present times over 3 ms AVG are usually a problem with v-sync for example disabled aero -> disabled v-sync.

[paulescobar]

Anyone else not getting NNEDI3 to work at all with Nvidia driver 350.12? My madVR immediately crashes when NNEDI3 is activated since I updated the drivers today.

I'm having problems with NNEDI3 as well.
I get artefacts (specifically, dotted black or sometimes colored lines which flash on the screen).

This is my first post. I signed up & have waited for a week just to get posting permission. Now I can finally share. Hopefully I don't miss anything important...

My system:
OS: Windows 7 Ultimate 64
MadVR x86: 0.87.21
MPC-HC: 1.7.8 (6fcba1b)
LAV (with CUVID enabled): 0.64.0
Graphics Card: ZOTAC GeForce GTX 770 ZT-70311-10P
NVidia Driver: 350.12
CPU: Intel Core I7-4790K 4.00 GHZ

I've done extensive testing with a variety of videos, decoder & MadVr settings. And no matter what, whenever NNEDI3 is active (through Chroma Upsampling or Doubling)...I will get these dotted lines which constantly flash & are randomly positioned on the screen.

With the previous Nvidia driver, these artefacts actually had sort of neon or blue colors. With the latest Nvidia drivers, they are now black. (FWIW, the previous Nvidia drivers had vertical lines appear when Error Diffusion Option 1 was enabled. The latest Nvidia driver solved that particular problem & I can use the option now)

I don't think this is the result of my system being stressed, because I get no frame drops...and these artefacts appear even when a single NNEDI3 setting with the lowest value is enabled.

Some guy last week said the problem was solved with this Nvidia driver. He speaks for himself, because it's still a problem for me.

[ryrynz]

I'm having problems with NNEDI3 as well.


Try the nvidia driver clean install option.
Also are you overclocking? Try dropping the clocks down even if you aren't to test.

[Schwartz]

Strange. For my NNEDI3 works just fine in x64. AMD 7770, Windows 8.1 x64. Not sure what's going on there on your PCs. Try to reinstall the driver/OpenCL, maybe?


The driver is the Omega 14.12 driver, clean install via Display Driver Uninstaller, circumvented automatic install with gpedit.msc and all that jazz. I'm sure reinstalling won't change anything, but I'm going to try the 15.4 beta soon and will report back then.

NNEDI3 doesn't work for chroma upscaling either, by the way. Selecting it gives me a Chroma > Jinc3 AR in the overlay. The weird thing is that I've never used Jinc so the Anti-Ringing Filter checkbox wasn't even selected.

[paulescobar]

Try the nvidia driver clean install option.
Also are you overclocking? Try dropping the clocks down even if you aren't to test.

I did perform a "clean install" when I updated the Nvidia driver. Also uninstalled completely before installing the latest.

And, no, I don't over-clock (not sure if you mean my CPU or GPU - but either way, I don't).

However...my motherboard is an "MSI Z97 XPower AC". I read somewhere once (not even sure if it's true) that it has some mild over-clock enabled in factory defaults (and defaults are pretty much what I use, sans boot order stuff).

Not sure why this would affect MadVR, but do you think it would have a big enough impact to warrant further research?

[cyberbeing]

I will get these dotted lines which constantly flash & are randomly positioned on the screen.

This is a known issue (http://bugs.madshi.net/view.php?id=250#c944) on Kepler GPUs with the latest drivers if you don't run NNEDI3 in madVR x64 first after the driver upgrade. You can workaround the issue by deleting the HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL registry key and then running NNEDI3 in madVR x64 to regenerate the OpenCL kernel. NVIDIA is aware of the issue, and looking into it.

Though since you also have a GTX770 like I do, applying either of the following registry keys should work so you don't need to mess with any of that.
http://www.mediafire.com?innbjl44crc6pbe

[dansrfe]

I have monitors which darken (lower gamma) when the refresh rate is overclocked beyond 60Hz as written here: http://www.gamersnexus.net/guides/1674-overclock-monitor-higher-refresh-rate

@madshi I'm curious, does it make sense to allow for madVR to use different 3DLUT profiles that have been generated from calibrations at different refresh rates in conjunction with the refresh rate changer?

If so, I'll be able to match refresh rate and frame rate on all files.

[Jtacdf]

This is a known issue (http://bugs.madshi.net/view.php?id=250#c944) on Kepler GPUs with the latest drivers if you don't run NNEDI3 in madVR x64 first after the driver upgrade. You can workaround the issue by deleting the HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL registry key and then running NNEDI3 in madVR x64 to regenerate the OpenCL kernel. NVIDIA is aware of the issue, and looking into it.

Though since you also have a GTX770 like I do, applying either of the following registry keys should work so you don't need to mess with any of that.
http://www.mediafire.com?innbjl44crc6pbe

Nice! This workaround also works with AMD Gpu. Works even with crossfire system.

Pic of proof in the link below.
https://www.dropbox.com/s/p5tbwmx0e3mdzb7/nnedi%20x64%20madvr.jpg?dl=0 (https://www.dropbox.com/s/p5tbwmx0e3mdzb7/nnedi%20x64%20madvr.jpg?dl=0)

[paulescobar]

This is a known issue (http://bugs.madshi.net/view.php?id=250#c944) on Kepler GPUs with the latest drivers if you don't run NNEDI3 in madVR x64 first after the driver upgrade. You can workaround the issue by deleting the HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL registry key and then running NNEDI3 in madVR x64 to regenerate the OpenCL kernel. NVIDIA is aware of the issue, and looking into it.

Though since you also have a GTX770 like I do, applying either of the following registry keys should work so you don't need to mess with any of that.
http://www.mediafire.com?innbjl44crc6pbe

Wow! Can't wait to try this...when my mom is done watching her Indian soaps which are being upscaled by MadVR lol!

Can I ask you a silly question? I'm kind of new to Windows 64. What is the correct method of installing this new 86/64 MadVR package?

Should I place it in the x86 program files folder and then run "Install.bat"?
Or should I place it in the normal x64 program files folder & then run "Install.bat"?

[cyberbeing]

Nice! This workaround also works with AMD Gpu. Works even with crossfire system.

Pic of proof in the link below.
https://www.dropbox.com/s/p5tbwmx0e3mdzb7/nnedi%20x64%20madvr.jpg?dl=0 (https://www.dropbox.com/s/p5tbwmx0e3mdzb7/nnedi%20x64%20madvr.jpg?dl=0)

I don't see how that's possible. :rolleyes:

The NVIDIA PTX kernel in those registry keys I linked can only be used by Kepler sm_30 GPUs (i.e. GK104). Even more so, it will be regenerated/ignored if not using a GTX 770 with 350.12 driver because of the key name and values. If you imported my 'GeForce GTX 770' key on a AMD setup, it should just be yet another entry in the registry and ignored. madVR has always supported storing a cached OpenCL kernels for each GPU you've ever used with madVR, but this shouldn't have any overlapping side-effects.

Either adding an NVIDIA OpenCL key on an AMD setup somehow breaks NNEDI3 and madVR fails to report it correctly, or madVR has a serious bug regarding those OpenCL registry keys. Check HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL and see if there is a key with your GPU model which contains a Binary kernel.


Should I place it in the x86 program files folder and then run "Install.bat"?
Or should I place it in the normal x64 program files folder & then run "Install.bat"?

It doesn't matter. You don't even need to place madVR in program files if you didn't want to. Creating a folder anywhere on your system should work, though optimally you'd want a folder where madVR has write access. With default security settings, creating a folder for madVR in your Documents directory may be a better location. Just make sure you see a 'regsvr32 succeeded' message for both madVR.ax and madVR64.ax when you run the install.bat

If using one of GTX 770 OpenCL registry keys I posted, it doesn't mater if you are using madVR x86 or x64. The same key can be used with both. As for which key to use, just pick whichever one seems faster if there is a difference at all. That said, if you wanted to switch to madVR x64, it can only be used with a 64bit directshow filters and media player. You'd need to grab a player like MPC-HC x64 or MPC-BE x64 at bare minimum in order to use it.

[Jtacdf]

I don't see how that's possible. :rolleyes:

The NVIDIA PTX kernel in those registry keys I linked can only be used by Kepler sm_30 GPUs (i.e. GK104). Even more so, it will be regenerated/ignored if not using a GTX 770 with 350.12 driver because of the key name and values. If you imported my 'GeForce GTX 770' key on a AMD setup, it should just be yet another entry in the registry and ignored. madVR has always supported storing a cached OpenCL kernels for each GPU you've ever used with madVR, but this shouldn't have any overlapping side-effects.

Either adding an NVIDIA OpenCL key on an AMD setup somehow breaks NNEDI3 and madVR fails to report it correctly, or madVR has a serious bug regarding those OpenCL registry keys. Check HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL and see if there is a key with your GPU model which contains a Binary kernel.

I should have mentioned that I only deleted the GPU folder in HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL. It refreshed itself thereafter once I started up madVR. I did not use your nvidia specific kernal at all.

[cyberbeing]

I should have mentioned that I only deleted the GPU folder in HKEY_CURRENT_USER\Software\madshi\madVR\OpenCL. It refreshed itself thereafter once I started up madVR. I did not use your nvidia specific kernal at all.

Ah, that makes perfect sense then. :)

I guess that means madVR may need to be a bit more aggressive with its check deciding when to regenerate the cached OpenCL kernels on AMD systems. Normally madVR does this automatically on driver upgrade, but maybe there is another factor on AMD (crossfire only?) systems.

[Schwartz]

To expand upon that thing I noticed, where render ms appear unusually high or inconsistent with x64 madVR.. that didn't have anything to do with NNEDI3 working or not, but rather something else:

Watching an MPEG-4 video that MPC-HC decodes through software avcodec (using only Spline36/Spline36 for upscaling, Error Diffusion 1, Smooth Motion, all quality tradeoffs disabled), I noticed that CPU usage will rise slowly from 7% to 15% and render ms will likewise go from ~9ms up to ~15ms, which is much more than I've ever seen on a profile that didn't use Image Doubling. I can play 1080p content with Spline36 and not even reach ~9ms, but this 640x480 SD content is bugging out on me. It appears to be less pronounced when watched at 100% zoom, but maximizing the window will produce these effects. The ms increase is not sudden either, but will slowly climb up higher and higher. When the window is maxed and the upscaler kicks in, the values may stay low for as long as 10-20 seconds, suggesting that these extra CPU cycles and render ms aren't actually required to play the movie but come from somewhere else.

This could just as well be a x64 LAV issue I assume, I just don't know.

[Hprd]

Though since you also have a GTX770 like I do, applying either of the following registry keys should work so you don't need to mess with any of that.
http://www.mediafire.com?innbjl44crc6pbe

Have a 770 here as well, this fix worked. :thanks:

[michkrol]

A little late to the party, but thanks madshi for the x64 build ;)
Everything works as expected on my PC.

To expand upon that thing I noticed, where render ms appear unusually high or inconsistent with x64 madVR.. that didn't have anything to do with NNEDI3 working or not, but rather something else
(...)
Do you get dropped frames or just higher render times and CPU usage?
Isn't it just the power-saving features of your CPU and/or GPU kicking in? Check your CPU and GPU clocks with HWiNFO (free download) or similar software during playback to make sure.
I know I sometimes get higher render times with "lower" setting because my GPU downclocks to save energy, which is not really a bad thing unless you get dropped frames.

[Magik Mark]

Is there a way to stream my set top box to my htpc & apply madvr?

[huhn]

Is there a way to stream my set top box to my htpc & apply madvr?

it would be possible to use a capture card to do this but a simple TV card is the better choice.

[paulescobar]

cyberbeing,

Thank you so much! :thanks:

I did the reg delete & execution of 64-bit MadVR & NNEDI3, as you advised.

Then I went through a bunch of videos with various NNEDI3 settings, and none displayed those artefacs I previously described.

Now I can perform stress tests to see just how much picture can improve with NNEDI3 enabled. :)

[billqs]

HI! I'm getting video freezes when using MPC-HC 1.7.8 and MadVR latest build to scale to UHD. Video will play to a random point then freeze, but the audio continues to play. I try to engage task manager but all I have after a control+alt+delete is a blank screen. I try to use the control+alt+delete to shutdown the system but I get the same blank screen & no shutdown. I have to do a hard restart with the power switch.

My gear:
Windows 7 64 bit
16GB RAM
i7 3820 CPU
X79A-GD45-PLUS Motherboard
R9 280x AMD Video card

I've managed to rule out MPC-HC directly causing the error as I have switched renderers to EVR CP and played several long video files. I also do not get freezes when using WMP to playback files. My Madvr settings are set to NNEDI3 32 neurons for image doubling, nothing checked for quadrupling, Lancoz for image upscaling (down from Jinc 3 taps to see if that would prevent the freeze- it didn't) bicubic for chroma. I have deblocking set to mild and I have engaged in luma the anti-ringing filter.

I have gotten this error with both 32 bit and 64 bit madvr and also other builds of madvr going back several iterations.

My *guess* is that I'm overpowering the GPU on the R9 280x by getting everything up to 3820x2160. I didn't know if any of you have had similar issues.

[XinHong]

I don't know if this issue is related to madVR or MPC-HC but the "Save Image" function of MPC-HC is broken since 0.87.16, even with the new x64 releases.

I got the following error message: "GetDIB failed, hr=80004005".

Win 7 x64
Intel HD3000 (9.17.10.4101) / [nVidia GT525M (340.52) <- not used]
LAV x64 0.64.0.52-git
MPC-HC x64 1.7.8.162

[iSunrise]

...My *guess* is that I'm overpowering the GPU on the R9 280x by getting everything up to 3820x2160. I didn't know if any of you have had similar issues.
Even if you would overpower the GPU, the issues you describe are not exactly normal.

Just disable NNEDI3 altogether, put everything on low settings and run GPU-Z in parallel and slowly go up with the settings so you can find out the optimal settings that are still OK without overloading your system.

If that still causes some weird issues report back.

[kasper93]

@XinHong: Works fine for me. You might want to report this in madVR thread. Probably debug log would help to diagnose the problem. In madVR folder run "activate debug mode.bat" and log will be generated on desktop.

EDIT: I thought we are in different thread. Or the post were moved... ;p

[XinHong]

I don't know if this issue is related to madVR or MPC-HC but the "Save Image" function of MPC-HC is broken since 0.87.16, even with the new x64 releases.

I got the following error message: "GetDIB failed, hr=80004005".

Win 7 x64
Intel HD3000 (9.17.10.4101) / [nVidia GT525M (340.52) <- not used]
LAV x64 0.64.0.52-git
MPC-HC x64 1.7.8.162

@XinHong: Works fine for me. You might want to report this in madVR thread. Probably debug log would help to diagnose the problem. In madVR folder run "activate debug mode.bat" and log will be generated on desktop.

- madVR log : http://dl.free.fr/jWghrvZVR I don't know if the error is inside the madVR log because it's only a warning from MPC-HC. I tried several times with EVR Custom and it's working fine.
I can easily reproduce it but sometimes it's working.

Edit : I tried several files but the error is still there.

http://s17.postimg.org/bjyncnnfv/MPC_HC.jpg (http://postimg.org/image/bjyncnnfv/)

[MistahBonzai]

Try running the 4GB Patch on mpc-hc.exe, if you haven't already although your problem appears to be nVidia related. I have no problems with <alt>+i in either 32 or 64 bit but I'm running a AMD H 7850.

[RenderGuy2]

Is there a limit to the amount of vram madVR x32 (+mpc-hc shaders) can use?

I've been feeding a full over/under 3d aviysnth script (1920x2160) into the player, image doubling (luma) with MadVR, sharpening with the FineSharp shader and then weaving the top and bottom into line alternate 3d with another shader (to be used with UHD passive 3d tv @ 3840x2160). All this uses about 3.2-3.4 GB of vram and another GB or so of system ram.

Am I getting close to the limit?

[oudo86]

Hello,

I am using madVR with PotPlayer on Windows 8.1 on my Laptop

It all works very well, but one weird thing I've notice is that my laptops fan speeds up significantly when I pause a video. Then when I press play the fan will eventually slow down again.

Anyone have any idea what's causing this?

[Fullmetal Encoder]

Forgive me if this has already been asked, but can any current cards do a quadruple upscale of 1920x1080 using nnedi3 with at least 64 neurons to UHD? Also, will madVR have the capacity to do much higher multiples with nnedi3 for 720x480 content? I imagine it would have to at some point to make it worthwhile watching older, lower resolution content on such higher resolution panels. I am eying a specific 4k monitor that would be able to natively support the relevant standard frame rates without having to resort to SM if that would free-up any GPU resources to make such scaling more feasible.

[huhn]

Forgive me if this has already been asked, but can any current cards do a quadruple upscale of 1920x1080 using nnedi3 with at least 64 neurons to UHD? Also, will madVR have the capacity to do much higher multiples with nnedi3 for 720x480 content? I imagine it would have to at some point to make it worthwhile watching older, lower resolution content on such higher resolution panels. I am eying a specific 4k monitor that would be able to natively support the relevant standard frame rates without having to resort to SM if that would free-up any GPU resources to make such scaling more feasible.

no quadruple doesn't even trigger in this case.
and SM doesn't matter it's nothing compared to use stuff like 64 neurons on a 1080p source.

[Fullmetal Encoder]

no quadruple doesn't even trigger in this case.
and SM doesn't matter it's nothing compared to use stuff like 64 neurons on a 1080p source.

I suspected that SM wouldn't have enough of an impact to meaningfully affect nnedi3 scaling capability. As to the other point I guess I don't know how nnedi3 upscaling works then. Isn't 3840x2160 exactly 4 times the resolution of 1920x1080?

[Asmodian]

Isn't 3840x2160 exactly 4 times the resolution of 1920x1080?

No, it is exactly 2 times the resolution (https://forum.doom9.org/showthread.php?p=1710665#post1710665). ;)

I would wait if you need a GPU that can do NNEDI3 64 neuron doubling on 1080p, I think a Titan X would be able to do it but even that would be close. Why do you need NNEDI3 64 instead of 32 neurons?

[ryrynz]

No, it is exactly 2 times the resolution (https://forum.doom9.org/showthread.php?p=1710665#post1710665). ;)

I would wait if you need a GPU that can do NNEDI3 64 neuron doubling on 1080p, I think a Titan X would be able to do it but even that would be close. Why do you need NNEDI3 64 instead of 32 neurons?

The ol' resolution debate..

64 is the best choice performance/quality wise. Going beyond 64 doesn't yield you much but uses a fair bit more processing power. 32 neurons is just okay IMO, so fair call wanting 64, it's what I'd gun for.