madVR - high quality video renderer (GPU assisted)

[iSunrise]

Originally Posted by sneaker_ger

/edit: removed on request by madshi

Man, that was fast, thanks a lot!

EDIT: Link removed, reason stated above.

[madshi]

Originally Posted by sneaker_ger

/edit: removed on request by madshi

Thanks.

[madshi]

Originally Posted by tobindac

SVP may have a 64bit version to accompany this soon.

Nice!

Originally Posted by aufkrawall

I'm not well aware of the signing procedure, but what does this mean?

Is that a madVR file? On my PC when looking at the details of a madVR file I'm getting "GlobalSign" instead of "Symantec".

Originally Posted by ikakun

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

Originally Posted by Soukyuu

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.

Originally Posted by ryrynz

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.

Originally Posted by ryrynz

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.

Originally Posted by obieobieobie

Symantec has told me they have removed the false positive detection of mvrSettings32.dll

Great - thanks!

Originally Posted by JPulowski

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.

Originally Posted by JPulowski

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

Originally Posted by Xaurus

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

No.

Originally Posted by flashmozzg

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

Originally Posted by kasper93

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

Originally Posted by jkauff

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.

Originally Posted by Qaq

Because you're wrong?

Originally Posted by Arm3nian

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

Originally Posted by e-t172

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.

Originally Posted by heiseikiseki

HI，I have very high present time in my optimus laptop.
about 8~10ms

Originally Posted by 6ari8

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

Originally Posted by Anatasia

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.

Originally Posted by Jtacdf

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.

Originally Posted by Schwartz

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?

Originally Posted by JPulowski

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.

Originally Posted by cvrkuth

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.

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

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.

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

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?

[huhn]

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

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]

Originally Posted by huhn

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?

Originally Posted by huhn

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.

[huhn]

Originally Posted by ikarad

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]

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

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]

Originally Posted by paulescobar

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]

Originally Posted by madshi

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]

Originally Posted by ryrynz

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]

Originally Posted by paulescobar

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

This is a known issue 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/16...r-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]

Originally Posted by cyberbeing

This is a known issue 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

[paulescobar]

Originally Posted by cyberbeing

This is a known issue 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]

Originally Posted by Jtacdf

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

I don't see how that's possible.

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.

Originally Posted by paulescobar

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]

Originally Posted by cyberbeing

I don't see how that's possible.

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.