View Full Version : madVR - high quality video renderer (GPU assisted)
huhn
12th April 2015, 23:55
Seems to work fine. Test build for all folks before it gets to nightly https://www.dropbox.com/s/lrmrdd2e3sgoc46/MPC-HC.1.7.8.156.x64_madVR.7z?dl=1
i haven't test it yet but you are really awesome to say the least.
Devrim
12th April 2015, 23:58
Seems to work fine. Test build for all folks before it gets to nightly https://www.dropbox.com/s/lrmrdd2e3sgoc46/MPC-HC.1.7.8.156.x64_madVR.7z?dl=1
This fixes the crash for me. Thanks!
sexus
13th April 2015, 00:36
64 bit huh. Well that came out of nowhere.. Madshi just stringing us along..
You got me mixed up with someone else there bud.
oh , lols my bad i guess i did xD
Ver Greeneyes
13th April 2015, 01:19
Works great with the MPC-HC test build, thanks!
noee
13th April 2015, 02:10
Okay, gurus, riddle me this. So I cranked up our favorite test videos for the newest 64-bit chain (LAV->MPC-HC->madVR). First up in the rotation is the opening scene in Revenge of the Sith, camera pans vertically from the starfield to the star destroyer, then the the pan transitions horizontally following the destroyer....blah, blah, blah. On the 32-bit chain, the pan down has a little bit of jumping, very small but noticeable, until the pan goes right and it's totally smooth (I use smooth motion ON). 64-bit, the vertical pan is dead smooth, just like the horizontal pan. Playback is 23.976fps on 60Hz tv and 1080->1080.
I don't see anything in the recent changelog to indicate changes to smoothmotion, etc. Went back to 32-bit just to check our eyes and the vertical jumping is back....
This just Win7Ult on a very old AMD platform (Athlon/HD6570 and the only Windows platform I have left) with old AMD drivers (13.12).
Anyone else notice this?
btw, great update madshi, thx.
andybkma
13th April 2015, 02:32
x64 build, wow, wonder if it does anything for kodi playback , since kodi is still 32bit as of yet, hmmm....as well thanks for the playback short freeze fix, looks like ryrynz needs to update his playback package for potplayer now since we officially have everything to finally advance to x64 playback . lav filters x64 , check , av splitter x64 , check , ffdshow x64 , check , potplayer x64 , check , xysubfilter x64, check ,
Maybe you have everything you need but I would still need a Zoom Player 64 build, a Reclock 64 build and an Avisynth 64 build. But yes, getting closer but I doubt I will ever see all this...
madshi, thanks for fixing the playbook freeze bug in 87.20, so far so good :-)
Teapsalm
13th April 2015, 02:41
Keep getting a black screen and I'm not sure why. Using the test build.
edit: Realized I needed to edit internal filters. Works perfectly with the test build.
Jtacdf
13th April 2015, 03:09
Hi Madshi,
madvr x64 with mpc hc causes nnedi3 to produce the artifact as below if the pc system is in crossfire mode.
Works fine if I manually disable it in CCC Crossfire settings. But not with a specific 3d application settings setting to disabled crossfire.
32bit works without issue as well.
https://www.dropbox.com/s/vdhalt2rnomf6kl/%5BCommie%5D%20Fate%E2%81%84stay%20Night%20Unlimited%20Blade%20Works%20-%2014%20%5B17F39C48%5D.mkv_snapshot_00.08_%5B2015.04.13_09.54.52%5D.jpg?dl=0
James Freeman
13th April 2015, 04:33
x64 madvr:
It seems that there is a problem with Device detection in the Devices tab.
The device is there but it is greyed out.
Also, the 3dLut can't be disabled via ctrl+Shift+3 or the menu itself when the device is greyed out.
Everybody that are involved, thank you so much for MPC-HC, LAV-filter and MadVR.
omarank
13th April 2015, 06:29
Thanks madshi for the 64 bit build. It works perfectly with the test build of MPC-HC 64 provided by kasper93.
If we had a 64 bit version of ReClock too, we would completely get rid of 32 bit players.
ryrynz
13th April 2015, 07:53
Thanks madshi for the 64 bit build. It works perfectly with the test build of MPC-HC 64 provided by kasper93.
If we had a 64 bit version of ReClock too, we would completely get rid of 32 bit players.
What sort of issues do you experience when not using ReClock? Why not just stop using it?
Siso
13th April 2015, 08:16
What sort of issues do you experience when not using ReClock? Why not just stop using it?
IMHO reclock is essential with the people with "24" multiple refresh rates (24hz,48hz,72hz etc.) So a x64 build of reclock will be very well welcomed. :)
madshi
13th April 2015, 08:35
Seems to work fine. Test build for all folks before it gets to nightly https://www.dropbox.com/s/lrmrdd2e3sgoc46/MPC-HC.1.7.8.156.x64_madVR.7z?dl=1
Awesome - thanks for the ultra-quick fix! :)
FWIW, I might still try to work around the problem within madVR, too, but the solution you just implemented is the cleanest possible approach, so it's good to have in any case.
Okay, gurus, riddle me this. So I cranked up our favorite test videos for the newest 64-bit chain (LAV->MPC-HC->madVR). First up in the rotation is the opening scene in Revenge of the Sith, camera pans vertically from the starfield to the star destroyer, then the the pan transitions horizontally following the destroyer....blah, blah, blah. On the 32-bit chain, the pan down has a little bit of jumping, very small but noticeable, until the pan goes right and it's totally smooth (I use smooth motion ON). 64-bit, the vertical pan is dead smooth, just like the horizontal pan. Playback is 23.976fps on 60Hz tv and 1080->1080.
I don't see anything in the recent changelog to indicate changes to smoothmotion, etc. Went back to 32-bit just to check our eyes and the vertical jumping is back....
This just Win7Ult on a very old AMD platform (Athlon/HD6570 and the only Windows platform I have left) with old AMD drivers (13.12).
Anyone else notice this?
Interesting. Not sure why that would happen. Maybe the refresh rate estimation works somewhat more exact or faster in x64, but I'm not really sure why. For me things look smooth here on my PC in both 32bit and 64bit. Haven't tested that specific test video, though.
madvr x64 with mpc hc causes nnedi3 to produce the artifact as below if the pc system is in crossfire mode.
Works fine if I manually disable it in CCC Crossfire settings. But not with a specific 3d application settings setting to disabled crossfire.
32bit works without issue as well.
I don't think there's much I can do about that. There's nothing specific about crossfire that I do in madVR. Crossfire is expected to work automatically, or at least not to harm. That seems to fail in this case. I don't see how it could be madVR's fault. I fear this is probably an AMD driver bug. I'd recommend that you report it to AMD.
x64 madvr:
It seems that there is a problem with Device detection in the Devices tab.
The device is there but it is greyed out.
Yes, I can reproduce that here.
huhn
13th April 2015, 08:36
IMHO reclock is essential with the people with "24" multiple refresh rates (24hz,48hz,72hz etc.) So a x64 build of reclock will be very well welcomed. :)
you could use smooth motion?
cvrkuth
13th April 2015, 08:40
When I close file in player (PotPlayer 1.6.53104 64-bit) I get error with x64 build
http://krstic.eu/clip.jpg
EventID 1000
Faulting application name: PotPlayerMini64.exe, version: 0.0.0.0, time stamp: 0x54bdb246
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000085000e023f
Faulting process id: 0x624
Faulting application start time: 0x01d075ba2b3ad3df
Faulting application path: D:\DATA\y040644\totalcmd\PLUGINS\Daum\PotPlayer64\PotPlayerMini64.exe
Faulting module path: unknown
Report Id: 7d2530d4-e1ad-11e4-82b1-002215207e47
Faulting package full name:
Faulting package-relative application ID:
Siso
13th April 2015, 09:04
you could use smooth motion?
The difference between smooth motion on 60hz and without it on 72hz is huge, on 72hz the motion of the video looks very fluid and natural, unlike the smooth motion on 60hz which looks artificial + plus the extra load on the gpu :)
huhn
13th April 2015, 09:10
The difference between smooth motion on 60hz and without it on 72hz is huge, on 72hz the motion of the video looks very fluid and natural, unlike the smooth motion on 60hz which looks artificial + plus the extra load on the gpu :)
you sure? i would call this a bug.
Siso
13th April 2015, 09:29
you sure? i would call this a bug.
The difference is quite obvious for me, and I don't like the extra load on the gpu, plus reclock makes the playback very smooth.
iSunrise
13th April 2015, 09:32
you sure? i would call this a bug.
Smooth motion, like it is currently implemented, can't magically be the same as one having a multiple refresh of a movie's native framerate.
It comes close though, but depending on the type of source fps your content has and your target refresh, it still has some more or less visible negatives (which we also debated over in this thread).
It's exactly like madshi implemented it.
cvrkuth
13th April 2015, 10:17
With x64 build I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz.
huhn
13th April 2015, 10:32
With x64 build I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz.
what display modes do you use and what operation system?
23 hz should be the right refreshrate for nearly 90% off all BD content. but if you haven't added this it should use this.
Qaq
13th April 2015, 10:53
What sort of issues do you experience when not using ReClock? Why not just stop using it?I live in PAL country and I need to slow TV caps down from 25 to native 24. And beside that I have dozen other reasons.
Jtacdf
13th April 2015, 11:26
I don't think there's much I can do about that. There's nothing specific about crossfire that I do in madVR. Crossfire is expected to work automatically, or at least not to harm. That seems to fail in this case. I don't see how it could be madVR's fault. I fear this is probably an AMD driver bug. I'd recommend that you report it to AMD.
Thanks for the info madshi. I've reported the bug to AMD, but I'm not too optimistic about them resolving it. After all, they still have yet to fix the D3D9 <-> OpenCL interop issue.
tobindac
13th April 2015, 11:41
massive 'green' artifact here on 64bit
http://i.imgur.com/rXFv9ym.png
though I don't see much use for the version yet since I always use SVP on top which is still 32bit.
GPU is an R9 290 latest stable drivers.
I figured this artifact appears with chroma upscaling set to NNEDI3.
Jtacdf
13th April 2015, 11:43
Nobody else gets that 'green image' artifact (http://forum.doom9.org/showpost.php?p=1717303&postcount=28836)? Weird, I don't have any novel setup. Just an R9 290 on W8.1.
tobindac, are you using a crossfire setup as well with 14.12 driver? That green artifact comes from nnedi3 being enabled in a crossfire setup.
Everything works without issue if you turn off Xfire manually in CCC. Unfortunately, creating a specific 3d application setting to turn off Crossfire still causes it to appear.
tobindac
13th April 2015, 11:44
tobindac, are you using a crossfire setup as well with 14.12 driver? That green artifact comes from nnedi3 being enabled in a crossfire setup.
Everything works without issue if you turn off Xfire manually in CCC. Unfortunately, creating a specific 3d application setting to turn off Crossfire still causes it to appear.
I deleted that message. I figured the artifact appears with NNEDI3 on chroma upscaling.
I don't have a Crossfire setup.
I never had one on this PC.
Jtacdf
13th April 2015, 11:50
I deleted that message. I figured the artifact appears with NNEDI3 on chroma upscaling.
I don't have a Crossfire setup.
I never had one on this PC.
That's pretty strange. Everything works fine for me running with 1 GPU. I'm using a 290x with 15.3 beta driver.
Are you using a AMD APU? From my limited understanding (since I'm using intel), AMD APU+GPU do have some form of crossfire as well.
StinDaWg
13th April 2015, 12:25
you sure? i would call this a bug.
It's not a bug, if your tv has proper 72/96hz playback it looks better than frame blending.
I could never stand madVR's implementation of smooth motion. I'd rather watch with judder than the loss of sharpness you get with frame blending.
Soukyuu
13th April 2015, 12:43
Great, now I can finally ditch that 32-bit player chain... once the wrinkles are ironed out.
Getting a white/cyan checkerboard pattern now and then instead of the video in windowed fullscreen (no overlay) and the mpc-hc x64 test build.
Also a crash on exiting said fullscreen mode (sent a report).
edit: There is sometimes a "fade to grey" on first subtitle line using latest xySubFilter beta x64. The screen just fades to a dark grey color while sound continues.
Disabling overlay or going fullscreen exclusive crashes on first subtitle line seemingly randomly.
madshi
13th April 2015, 14:12
madVR v0.87.21 released
http://madshi.net/madVR.zip
* fixed: (un)install.bat now works without having to manually "run as admin"
* fixed: active display wasn't properly set in the settings (x64)
* added workaround for window subclassing crash (x64)
Although the x64 crash seems to be gone now, I'd still like to encourage media player developers to implement "IMadVRSubclassReplacement", as MPC-HC has already done (thanks kasper93).
aufkrawall
13th April 2015, 14:39
I wonder when there will be the next surprise release, with Jinc downscaling, framerate conversion and 10 bit output. :devil:
:thanks:
SecurityBunny
13th April 2015, 15:14
Nvidia Geforce 350.12 driver seems to crash when going into windowed fullscreen mode. Using MPC-HC 1.7.8.156 (x64) & MadVR v0.87.21 (x64). Driver crash also occurs with version 350.05. Fullscreen playback seems to be fine with exclusive mode enabled.
Driver 347.88 is fine with both exclusive fullscreen and windowed fullscreen.
nijiko
13th April 2015, 15:19
64 now! Awesome!!!
cvrkuth
13th April 2015, 15:40
what display modes do you use and what operation system?
23 hz should be the right refreshrate for nearly 90% off all BD content. but if you haven't added this it should use this.
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.
khanmein
13th April 2015, 15:53
Nvidia Geforce 350.12 driver seems to crash when going into windowed fullscreen mode. Using MPC-HC 1.7.8.156 (x64) & MadVR v0.87.21 (x64). Driver crash also occurs with version 350.05. Fullscreen playback seems to be fine with exclusive mode enabled.
Driver 347.88 is fine with both exclusive fullscreen and windowed fullscreen.
x64 for mpc & lav filter stable with madvr?
huhn
13th April 2015, 16:02
the nvidia 349 branch added a serious issue with nnedi3. i'm going to test this later but i think is very unlikely that this issue is fix in this version. so it's maybe not a good idea to use this version with madVR.
SecurityBunny
13th April 2015, 16:07
x64 for mpc & lav filter stable with madvr?
As far as my testing has gone, x64 MPC-HC (1.7.8.156) with native lav filters works perfectly fine with x64 MadVR (0.87.21). Just the later nvidia display drivers (350.05 & 350.12) crash when going into windowed fullscreen. Also causing the video player to crash or report madvr direct x initialization failure. This behavior only occurs with windowed fullscreen, exclusive fullscreen seems to function just fine.
Downgrading nvidia driver to 347.88, both windowed and exclusive fullscreen function as intended with x64 versions.
ThurstonX
13th April 2015, 16:36
Thanks for the x64 build and fix :-)
I just tested a few files using the stable release of MPC-HC 1.7.8 x64, LAV as external filters, and the "MPC-HC has stopped working" error I was receiving with 0.87.20 when closing MPC-HC seems to be fixed with 0.87.21.
tobindac
13th April 2015, 17:12
That's pretty strange. Everything works fine for me running with 1 GPU. I'm using a 290x with 15.3 beta driver.
Are you using a AMD APU? From my limited understanding (since I'm using intel), AMD APU+GPU do have some form of crossfire as well.
R9 290 on latest stable drivers.
i7 cpu with disabled igpu.
obieobieobie
13th April 2015, 17:14
Symantec antivirus doesn't like mvrsettings32.dll in this new version (0.87.20+)
False positive?
http://i.imgur.com/vuB0Qkr.png
tobindac
13th April 2015, 17:17
It still requires run as admin here. Win8.1.
madshi
13th April 2015, 17:24
R9 290 on latest stable drivers.
No problems here with NNEDI3 chroma upsampling on my HD7770 on Windows 8.1. Probably a driver issue?
Symantec antivirus doesn't like mvrsettings32.dll in this new version (0.87.20+)
False positive?
Yes, of course. Please contact their customer support and complain. Loudly. Reporting a properly signed dll as a false positive is a sign of a very bad behaving anti-virus software. Seriously, you may want to consider changing to a better product.
It still requires run as admin here. Win8.1.
Works for me. Is it working/failing for you other guys?
obieobieobie
13th April 2015, 17:44
Madshi, is the DLL packed?
I will report the false positive
aufkrawall
13th April 2015, 17:46
Funny that Symantec doesn't trust its own signatures. :scared:
madshi
13th April 2015, 17:55
The DLL is not packed. It's a simple and straight Delphi XE7 compiled DLL, nothing fancy. And even signed.
@aufkrawall, what do you mean? The signature is from GlobalSign.
tobindac
13th April 2015, 18:10
SVP may have a 64bit version to accompany this soon (http://www.svp-team.com/forum/viewtopic.php?pid=48278#p48278).
Thunderbolt8
13th April 2015, 18:43
Is it working/failing for you other guys?works for me on windows 8.1 (then again I am not sure whether I need to apply admin mode at all any more, because I once changed some stuff in my local security policy)
mandarinka
13th April 2015, 18:45
Thanks!
This should save us some CPU cycles when decoding high resolution videos thanks to 64bit LAV decoders, too :)
Edit: Seems to work without issues here.
Vyral
13th April 2015, 19:09
Thanks madshi for the 64bit build.
After some testing, all I can say is wow... just... wow.
Not only everything seems faster (loading and seeking but maybe it's just a placebo) but my refresh rate and rendering time are perfectly constant during playback.
aufkrawall
13th April 2015, 19:32
@aufkrawall, what do you mean? The signature is from GlobalSign.
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)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.