View Full Version : madVR - high quality video renderer (GPU assisted)
madshi
12th April 2015, 18:08
here
http://anonfiles.co.uk/image.php?di=Q5R6
Your zoom setup requires madVR to downscale in X direction and upscale in Y direction. Because of that Jinc cannot be used because madVR currently doesn't support downscaling with Jinc.
Here's a screenshot showing the res in windows: http://i.imgur.com/tbfSZw2.jpg
The only black borders are from the movies itself. On the desktop the whole screen is filled. For display modes I don't use any. As for resetting madvr not sure how to unless right clicking screen -> renderer settings -> reset -> reset to default renderer settings counts.
Whatever the problem is, it doesn't look like madVR's fault. madVR is asked to render to a specific target rect and does that just fine.
Maybe your OS is setup with large fonts / DPI settings? So that it's not really 1080p but 720p to the eyes of all applications?
sexus
12th April 2015, 18:38
Your zoom setup requires madVR to downscale in X direction and upscale in Y direction. Because of that Jinc cannot be used because madVR currently doesn't support downscaling with Jinc.
im confused here, im using jinc3 AR for upscaling not downscaling , madshi , and i use mitchell netravali with AR and scale in linear light as downscaler, so your statement doesnt make much sense tbh, also ive noticed the x and y value changes dependent on what aspect ratio/zoom i use 4:3 stretch or custom zoom settings, meaning if i use 4:3 stretch mode i have lanczos 3 AR as x direction and of course as you already know with custom zoom settings, where i zoom the image both horizontally and vertically to get rid of black borders that arent removed by using 16:9 aspect mode, then i get the y direction shown as using lanczos 3 AR
madshi
12th April 2015, 18:51
im confused here, im using jinc3 AR for upscaling not downscaling , madshi , and i use mitchell netravali with AR and scale in linear light as downscaler, so your statement doesnt make much sense tbh, also ive noticed the x and y value changes dependent on what aspect ratio/zoom i use 4:3 stretch or custom zoom settings, meaning if i use 4:3 stretch mode i have lanczos 3 AR as x direction and of course as you already know with custom zoom settings i get the y direction shown as using lanczos 3 AR
Of course my reply makes perfect sense. Your screenshot says:
movie resolution: 1920x1080
target rect: 4, -167, 1916, 1249
The target rect is defined by the media player. So madVR is asked to zoom 1920x1080 to 1912x1416. Which means X has to be downscaled and Y has to be upscaled. In this situation Jinc cannot be used. The OSD also clearly shows what madVR does:
image x < Mitchell-Netravali AR
image y > Lanczos3 AR
So X is downscaled ("<"), while Y is upscaled (">").
sexus
12th April 2015, 18:53
heres a screenshot from what im getting while using the 4:3 stretch mode
http://anonfiles.co.uk/image.php?di=IEX1
ive been thinking , how bout having NNEDI do the downscaling as well, or matter of fact do all , since currently the best downscaling method is mitchell netravali + AR + scale in linear light from what ive heard , madshi
Yvese
12th April 2015, 18:57
Maybe your OS is setup with large fonts / DPI settings? So that it's not really 1080p but 720p to the eyes of all applications?Omg that was it!
I checked the "Let me choose one scaling level for all my displays" under the windows display options and set everything to 100% and it worked.
Thanks! Thanks to huhn as well!
Also I have a question - is it safe to set my TV to 24hz? My TV's manual doesn't list what it supports ( it's a Sharp LC-39LE551U ) but when I set it to 24hz it actually runs just fine.
madshi
12th April 2015, 19:20
heres a screenshot from what im getting while using the 4:3 stretch mode
http://anonfiles.co.uk/image.php?di=IEX1
Looks alright to me.
how bout having NNEDI do the downscaling as well
NNEDI3 cannot do downscaling. It can only exactly double the resolution.
Also I have a question - is it safe to set my TV to 24hz? My TV's manual doesn't list what it supports ( it's a Sharp LC-39LE551U ) but when I set it to 24hz it actually runs just fine.
No, it's not safe, you could create a black hole and collapse the universe. Seriously, how are we supposed to know? Probably it's safe, but only Sharp technical support can say for sure.
huhn
12th April 2015, 19:24
Also I have a question - is it safe to set my TV to 24hz? My TV's manual doesn't list what it supports ( it's a Sharp LC-39LE551U ) but when I set it to 24hz it actually runs just fine.
if windows reports in it should be fine because your TV is kind of saying it can do this to windows.
just use madVR display modes and add everything windows gives you as an option ok ignore the interlaced mode if listed. usually you don't want to use 24 hz but 23 hz (that 24000/1001 the refresh rate nearly all BDs have).
madshi
12th April 2015, 19:57
madVR v0.87.20 released
http://madshi.net/madVR.zip
* added x64 build
* fixed: short playback freeze, then catch up, at runtime start
Hmmm... Maybe I should stop saying "no further release planned in the next 2-3 weeks". I mean I meant it. And I mean it again this time. But you know...
Edit: You need to right click "install.bat" and run as admin with this build.
Sm3n
12th April 2015, 20:15
thx for x64 build.
flashmozzg
12th April 2015, 20:16
* added x64 build
:eek: unexpected.
sexus
12th April 2015, 20:36
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 , yep ..excellent but id love to have kodi devs finally work out a x64 build , now that would be epic
so you say jinc3 is the best we will get for downscaling? , then i cant wait for it to be supported , to bad NNedi dont work for downscaling
vomanci
12th April 2015, 20:38
Ok, so x64 build .... work as it should. No problems on MPC-HC x64.
One question not related to this build thou: why, when using windowed overlay mode, backbuffer queue appears instead of present queue and is always 2-3/3, can't change the value.
Devrim
12th April 2015, 20:44
Thanks for the x64 build!
Ge'in
12th April 2015, 20:49
Good news :D
aufkrawall
12th April 2015, 21:01
Thanks for x64 build. :)
It works fine here, apart from crashing MPC HC when closing:
Problemsignatur:
Problemereignisname: BEX64
Anwendungsname: mpc-hc64.exe
Anwendungsversion: 1.7.8.0
Anwendungszeitstempel: 54c4efa5
Fehlermodulname: StackHash_1e37
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 00000000
Ausnahmeoffset: PCH_73
Ausnahmecode: c0000005
Ausnahmedaten: 0000000000000008
Betriebsystemversion: 6.3.9600.2.0.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 1e37
Zusatzinformation 2: 1e373e69fff075aed81f57003e66ce10
Zusatzinformation 3: 9f0e
Zusatzinformation 4: 9f0e095f32a88249d7a2b7eca4e322ea
tobindac
12th April 2015, 21:01
mpc-hc 64 doesn't see the renderer here. latest mpc-hc nightly build. using 'install.bat'.
edit: wait, not even the 32bit version works now. "unavailable" in output settings.
huhn
12th April 2015, 21:02
Ok, so x64 build .... work as it should. No problems on MPC-HC x64.
really?
both newest nightly of mpc-hc and mpc-be doesn't work yet with the 64 bit version. with the error the selected renderer is not installed. atleast for me
i guess a new nightly of both mpc-hc and-mpc be is needed.
tobindac
12th April 2015, 21:05
really?
both newest nightly of mpc-hc and mpc-be doesn't work yet with the 64 bit version. with the error the selected renderer is not installed. atleast for me
i guess a new nightly of both mpc-hc and-mpc be is needed.
'unavailable' here even with a 1.7.8 install.
Ge'in
12th April 2015, 21:08
Thanks for x64 build. :)
It works fine here, apart from crashing MPC HC when closing:
Problemsignatur:
Problemereignisname: BEX64
Anwendungsname: mpc-hc64.exe
Anwendungsversion: 1.7.8.0
Anwendungszeitstempel: 54c4efa5
Fehlermodulname: StackHash_1e37
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 00000000
Ausnahmeoffset: PCH_73
Ausnahmecode: c0000005
Ausnahmedaten: 0000000000000008
Betriebsystemversion: 6.3.9600.2.0.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 1e37
Zusatzinformation 2: 1e373e69fff075aed81f57003e66ce10
Zusatzinformation 3: 9f0e
Zusatzinformation 4: 9f0e095f32a88249d7a2b7eca4e322ea
I have exactly the same problems on exit.
Nom d’événement de problème: BEX64
Nom de l’application: mpc-hc64.exe
Version de l’application: 1.7.8.0
Horodatage de l’application: 54c4efa5
Nom du module par défaut: StackHash_2264
Version du module par défaut: 0.0.0.0
Horodateur du module par défaut: 00000000
Décalage de l’exception: 0000000003ed023f
Code de l’exception: c0000005
Données d’exception: 0000000000000008
Version du système: 6.1.7601.2.1.0.256.48
Identificateur de paramètres régionaux: 1036
Information supplémentaire n°*1: 2264
Information supplémentaire n°*2: 2264db07e74365624c50317d7b856ae9
Information supplémentaire n°*3: 875f
Information supplémentaire n°*4: 875fa2ef9d2bdca96466e8af55d1ae6e
sneaker_ger
12th April 2015, 21:09
both newest nightly of mpc-hc and mpc-be doesn't work yet with the 64 bit version. with the error the selected renderer is not installed.
Did you run Install.bat with admin rights?
It seems to use regsvr32.exe directly - not InstallFilter.exe like previous versions.
Playback works fine for me but both MPC-HC and MPC-BE crash after I close them. They don't create any crash dumps, though.
http://217.160.126.132/mpc-hc64%20crash.7z
Problemsignatur:
Problemereignisname: BEX64
Anwendungsname: mpc-hc64.exe
Anwendungsversion: 1.7.8.152
Anwendungszeitstempel: 5526f937
Fehlermodulname: StackHash_2264
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 00000000
Ausnahmeoffset: 0000000002b2023f
Ausnahmecode: c0000005
Ausnahmedaten: 0000000000000008
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 2264
Zusatzinformation 2: 2264db07e74365624c50317d7b856ae9
Zusatzinformation 3: 875f
Zusatzinformation 4: 875fa2ef9d2bdca96466e8af55d1ae6e
sexus
12th April 2015, 21:10
i see, guess i was too quick with my excitement , seems x64 is in need of some troubleshooting , ey? ill gladly wait
hey ryrynz make sure to upload that x64 potplayer package once this baby got its quirks taken care of , thanks man , ill be waiting over at imouto
tobindac
12th April 2015, 21:11
Did you run Install.bat with admin rights?
That seems to be the issue. It's gonna confuse a lot of people. Right clicking -> install as admin is not a default move.
huhn
12th April 2015, 21:16
Did you run Install.bat with admin rights?
It seems to use regsvr32.exe directly - not InstallFilter.exe like previous versions.
didn't saw a reason for that but now it works fine, thank.
but i'm not shocked if the player need to add some code to make this 64 bit version work better.
madshi
12th April 2015, 21:19
I removed InstallFilter.exe, but added some code to madVR(64).ax to make install.bat work like before. But it seems this doesn't work properly, so you have to use "right click -> run as admin" for now on the install.bat.
On my PC I get no crash with MPC-HC 64bit 1.7.8. I can't do anything about that if I can't reproduce it. Those of you who have a crash, can you try with other 64bit media players to double check whether the issue is likely in madVR or on MPC-HC?
sneaker_ger
12th April 2015, 21:20
GraphStudioNext does not crash after exit so maybe it's really only mpc-hc/be.
kasper93
12th April 2015, 21:22
I see it is already reported here. MPC-HC crashes on closing the graph. CTRL+C is enough to trigger the crash. Probably some momory corruption is going on. I tried to debug that, but all I get is access violation exception and invalid stack trace.
tobindac
12th April 2015, 21:24
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.
sexus
12th April 2015, 21:24
well i would , but i have to wait for ryrynz to update his potplayer lav filters pack to accomandante both the x86 and x64 versions of all the filters including yours madshi and of course potplayer itself
,of course making each component optional to install , since i really just need the x86 filters for kodi , since im working on getting some kodi devs attention to have them work on x64 builds of kodi , ill be gladly be testing the x64 version of madvr then
sneaker_ger
12th April 2015, 21:30
Ok, let's collect data on the people getting the crash after close/exit:
Windows 7 (EMET 5.1, not active on MPC-HC/BE)
Core i7-860
AMD Radeon HD 5850, Catalyst 15.3 Beta
baii
12th April 2015, 21:30
What are the presumed benefit for using the 64bit build?
Sent from my 306SH
sneaker_ger
12th April 2015, 21:31
For madVR itself probably none. But now you can use it with other 64 bit filters. 64 bit versions of LAV Video are a lot faster regarding HEVC and VP9 decoding than their 32 bit counterparts, for example.
tobindac
12th April 2015, 21:34
Even if the software design does not directly target it a minor advantage is always there for 64bit due to compiler tricks under the hood.
madshi
12th April 2015, 21:43
I can reproduce the crash by pressing Ctrl+C in MPC-HC. Will try to find out what's going on. Might be hard, though...
huhn
12th April 2015, 21:44
mpc-be x64 1.4.4 286 doesn't crash at all
mpc-hc x64 1.7.8 152 doesn't crash but did it in the first couple of tries.
daum potplayer x64 1.6.53104 crashes when playback is stopped.
and i have a general issue with render times on the new version:
http://abload.de/img/generalissueb6uef.png
edit: can't reproduce this issue with the rendertimes anymore
the composition rate for windows 10 is removed is this intentional?
sexus
12th April 2015, 21:57
thanks huhn for testing on potplayer, this seems to be a bigger issue to squash, so much for 3 weeks breaktime ey madshi? xD
clsid
12th April 2015, 22:05
EMET 5.2 detects DEP mitigation when MCP-HC64 crashes on close.
madshi
12th April 2015, 22:22
I see it is already reported here. MPC-HC crashes on closing the graph. CTRL+C is enough to trigger the crash. Probably some momory corruption is going on. I tried to debug that, but all I get is access violation exception and invalid stack trace.
I've identified the window subclassing to be at fault. However, I don't see much I can do there. The same code works in 32bit. In 64bit, after I restore the stored window proc, the crash occurs. If I don't restore it, a different crash occurs. So what can I do? Here's what the log says:
00000064 Render install new WindowProc (ParentWindow: 000000000048121E, OldWindowProc: 00007FF7B3E7ACC0, NewwindowProc: 0000000DECD50000) -> +
00001976 Render restore WindowProc, ParentWindow: 000000000048121E, current: 00000000FFFF0DC7, old: 00007FF7B3E7ACC0, ours: 0000000DECD50000
So basically when madVR starts rendering, I'm storing the old window proc of madVR's parent window, then I'm subclassing the parent window, and when madVR is finalized, I undo the subclassing. Unfortunately this crashes MPC-HC 64bit, but not in 32bit. Interestingly, at the moment when I want to undo the subclassing, the active window proc neither matches the original one, nor the one I set. So something weird is going on there, anway. But that's the case in 32bit, too, and there it still works without a crash.
There's a madVR interface "IMadVRSubclassReplacement" which you can use to replace madVR's window subclassing with a cleaner method. Using that should take care of the crash. Would that be possible to add to MPC-HC? It's the better solution for 32bit, too.
huhn
12th April 2015, 22:23
thanks huhn for testing on potplayer, this seems to be a bigger issue to squash, so much for 3 weeks breaktime ey madshi? xD
not sure why you can't download potplayer 64 -> right click -> video renderer -> madVR and start a file.
sexus
12th April 2015, 22:25
sure i could , but i want the full package from ryrynz , aka all the filters including lav filters x64 , xysubfilter x64 version , since i use these for regular playback , testing madvr without them wouldnt make much sense to me you see,
as of currently due to kodi being x86, and me working on getting the kodi devs to adopt , im gona be running both x86 and x64 filters , of course im waiting till ryrynz integrates this nicely into his epic setup installer , im in no need to install x86 potplayer thou , so make it optional to install, since potplayer x64 is all i need to test this madvr build , thats as soon as this crash issue gets fixed , thanks ryrynz bro
huhn
12th April 2015, 22:30
when you install the new version of madVR and potplayer all other filter doesn't disappear and can still be used. and you can install these by your self. if, for what ever reason, only the 32 bit version are installed.
sexus
12th April 2015, 22:36
honestly im not really sure if theyre only 32bit version installed , ryrynz would have to chime in on that one , since i only see lav filters in my x86 lav filters folder but no 32bit naming to them unlike madvr..hmmm....
heres the link to ryrynz lav filters pack
https://imouto.my/configuring-potplayer-for-gpu-accelerated-video-playback-with-dxva-or-cuda-and-also-high-performance-software-decoding/
nussman
12th April 2015, 22:38
Thanks for 64Bit Version madshi.
@sexus: Could you please stop spamming here?
sexus
12th April 2015, 22:39
i dont understand
Thunderbolt8
12th April 2015, 22:40
is there some indication I can use when madVR is running to check whether its in 32-bit or 64-bit mode when having both installed?
sexus
12th April 2015, 22:41
yes , go into taskmanager and check it that way, not sure any other way would do
sneaker_ger
12th April 2015, 22:44
If you use a 64 bit player it can only run in 64 bit and if you use a 32 bit player it can only run in 32 bit. madHcCtrl.exe is 32 bit only, I think.
nussman
12th April 2015, 22:46
is there some indication I can use when madVR is running to check whether its in 32-bit or 64-bit mode when having both installed?
64Bit Player => 64bit madVR
32bit Player => 32bit madVR
Thunderbolt8
12th April 2015, 23:06
slightly offtopic: does anyone know where the topic of that little htpc-updater tool has gone? or better, if that tool automatically downloads the 64-bit versions of LAVfilter and MPC-HC as well?
ryrynz
12th April 2015, 23:19
64 bit huh. Well that came out of nowhere.. Madshi just stringing us along..
heres the link to ryrynz lav filters pack
You got me mixed up with someone else there bud.
kasper93
12th April 2015, 23:53
I've identified the window subclassing to be at fault. However, I don't see much I can do there. The same code works in 32bit. In 64bit, after I restore the stored window proc, the crash occurs. If I don't restore it, a different crash occurs. So what can I do? Here's what the log says:
00000064 Render install new WindowProc (ParentWindow: 000000000048121E, OldWindowProc: 00007FF7B3E7ACC0, NewwindowProc: 0000000DECD50000) -> +
00001976 Render restore WindowProc, ParentWindow: 000000000048121E, current: 00000000FFFF0DC7, old: 00007FF7B3E7ACC0, ours: 0000000DECD50000
So basically when madVR starts rendering, I'm storing the old window proc of madVR's parent window, then I'm subclassing the parent window, and when madVR is finalized, I undo the subclassing. Unfortunately this crashes MPC-HC 64bit, but not in 32bit. Interestingly, at the moment when I want to undo the subclassing, the active window proc neither matches the original one, nor the one I set. So something weird is going on there, anway. But that's the case in 32bit, too, and there it still works without a crash.
There's a madVR interface "IMadVRSubclassReplacement" which you can use to replace madVR's window subclassing with a cleaner method. Using that should take care of the crash. Would that be possible to add to MPC-HC? It's the better solution for 32bit, too.
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
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.