View Full Version : madVR - high quality video renderer (GPU assisted)
SamuriHL
15th April 2011, 19:10
Ok, as long as you hadn't forgotten about it that's fine. I know you're busy with far more important things.
For those that want to default their settings, the following key should be removed from the registry:
HKEY_CURRENT_USER\Software\madshi\madVR
And delete the settings.bin. I think that'll do it, right? :)
Here's a bat file for it. As always when editing the registry, BE CAREFUL! :)
@echo off
reg delete HKEY_CURRENT_USER\Software\madshi\madVR /f
if exist "settings.old" (del settings.old)
rename settings.bin settings.old
pause
I called it DefaultSettings.bat. To get your old settings back, just rename settings.old back to settings.bin. Enjoy!
oddball
15th April 2011, 19:16
0.55 no worky.
Peekstra
15th April 2011, 19:24
I still can't get Zoomplayer get start in fullscreen mode on my second monitor using, for example, when running zplayer.exe /f:2 movie.avi the screen stays dark and Zoomplayer hangs. When I change the /f:2 to /f:1 it works fine.
Manually dragging Zoomplayer to monitor 2, loading the file and maximizing it works without any problems.
This also happened with all previous madvr versions which I tested.
W7 x64, XFX 6950,11.4, ZP 8.0 RC1
6233638
15th April 2011, 19:30
Checking logs is a very time consuming thing for me. So although I appreciate the time you took to make and upload the logs, I have to pass. I don't think there's much I can see, anyway. Presentation glitches are usually happening outside of madVR's control, so the logs won't tell me much except that there were glitches, unfortunately.No problem, just thought it might have been useful.
I'm seeing that, too, and I think it's a bug in MPC-HC. But what can I say...It seemed more prevalent than usual with 0.54, but it may also have been because I was doing a lot of tests in fairly quick succession. (quitting and restarting each time I made and changes to the flushes)
0.55 is completely freezing on me when I open a file. If it's set to only present one frame at a time, I get a black screen, if that option is disabled it freezes on the first frame of video.
If I start the video with MPC-HC opened first, which makes it open in a window, and then switch to fullscreen, it works. (but I have the same issues as before)
Here's a log if it's any use: http://www.mediafire.com/?pi76zccs6nvc6vc
midiboy
15th April 2011, 19:33
Hi madshi,
starting fullscreen playback on second monitor with Zoom Player crashes it (no video, just audio, have to kill ZP process)
This happens with 0.54 and 0.55. Previous versions worked fine.
See the logfile attached please.
Thanks for your help,
Alex
iSeries
15th April 2011, 19:38
Also just getting a black screen with 0.55. Have to kill player via task manager. 0.54 works fine.
madshi
15th April 2011, 19:49
Ok, will make a fix soon.
thuan
15th April 2011, 19:54
I'm also one of "60fps at 60Hz works fine and 24/30fps at 60Hz does not". By does not I meant presentation glitches is not zero as 60fps/60Hz. Another thing when I set every flush settings for exclusive mode to no flush, switching track using MPC next/previous hangs the program.
pdanpdan
15th April 2011, 19:54
0.54 and 0.55 display black screen on second monitor when started with D3D Fullscreen
0.53 works
Maybe it's because of different refresh rate between the 2 monitors?
0.55 has much lower CPU load than 0.53
if started on the same display everything works
Razoola
15th April 2011, 20:00
An observation.
It seems presently (from my opinion at least) that poor madshi is trying his upmost to get these new exclusive mode issues fixed. When fixes for some get sorted it introduces problems for others. When madshi fixes those issues the first people have problems again. It seems to me this could be more me due to problems in gpu drivers than anything else. Maybe it would be an idea to have everyone reporting issues with the new exclusive mode to use a set ati or nvidia driver revision of madshis choosing. I feel it could greatly help this situation.
Thunderbolt8
15th April 2011, 20:04
no problems at all with any of those new version. maybe its just because Im running a 60Hz display on XP, but I really dont know where all the problems you guys have come from.
Razoola
15th April 2011, 20:09
Also just getting a black screen with 0.55. Have to kill player via task manager. 0.54 works fine.
snap for me, win7 SP1 x64 270.51 mpc-hc 3033
zeroo
15th April 2011, 20:21
I have installed 0.54, but when I switch to fullscreen mode on secondary display, mpc-hc crashes.
Should be fixed in v0.55.
Great! It works now. However, switching to fullscreen is faster than ever on the secondary display.
yesgrey
15th April 2011, 20:21
Oh well. That's *exactly* what I feared. Now that I changed it to green, here come several votes to change it back to red. <sigh> Can't please everybody, I guess.
Any possibility of making it... blue? :D
Maybe it would be an idea to have everyone reporting issues with the new exclusive mode to use a set ati or nvidia driver revision of madshis choosing.
It happened to me. madshi is using nvidia 270.51 and I was still using the previous ones. I updated mine and some of the problems vanished.
OK. Now I've discovered that I have new problems with the custom resolutions creation :( but that's not madshi's fault...
SamuriHL
15th April 2011, 20:28
Any possibility of making it... blue? :D
Troublemaker! :p
It happened to me. madshi is using nvidia 270.51 and I was still using the previous ones. I updated mine and some of the problems vanished.
OK. Now I've discovered that I have new problems with the custom resolutions creation :( but that's not madshi's fault...
I had to nuke that driver off my machine. I could never get it to stay in sync with audio. I rolled back to the latest WHQL driver (268 I think or whatever it is). Haven't have any problems since but, I also haven't tested madVR on that machine in a couple days. I will be doing so tomorrow.
Plutotype
15th April 2011, 20:29
Hi,
Tested 0.55 on 24Hz LCD TV and following numbers were to see:
- black screen when I have "launch in fullscreen function i MPC-HC" enabled or switch too quickly from windowed - ctrl+alt+delete has to be used in this case + kill mpc-exe
- if starting from windowed and then expanding to fullscreen exclusive ( 2 steps ), video starts ok ( up to 10-15 dropped frames and occasionally 1 delayed frame and 1 glitch after both steps )
- playback fine, when resetting the stats, 0 dropped frames, 0 glitches after 30minutes ( fps 23.976 / display 24 ). Additionally, in the OSD field "1 frame drop every..." I get stats like 14 days, 124days, 61 days, 12days, 6 days, 22days...after 30 minutes of playback. Is this fine?
Pluto
dansrfe
15th April 2011, 20:30
Actually it would be pretty cool if you can add a dropdown for us to choose the color we want the OSD to have :D :D
underzone
15th April 2011, 20:45
Oh dear... v0.55 has broken mine too. Black screens on either monitor (or amp), or an MPC-HC hang. latest everything (MPC 3033, ffdshow, etc)
update... installed 0.54 again, everything spot on again. Wierd!
BeNooL
15th April 2011, 21:00
Going full screen on 2nd screen freeze MPC-HC.
Here's a log http://www.megaupload.com/?d=CD5ZHAND
Also the new rendering path on ATI 4550 is worse...the +99% GPU usage is effectively causing massive drops.
neb1236
15th April 2011, 21:00
Hi, just moved to 0.55 from 0.51 and noticed that moving mpc from one screen to another screen is not anymore flawless, the windows/mouse get stuck and video paused for half a second before allowing me to pass from one screen to another. It’s king of awkward.
It’s probably since v0.53, but I can’t find this precise version to test.
I’m using a Radeon HD6950 with 11.3 drivers
Do you need a log?
madshi
15th April 2011, 21:05
For those that want to default their settings, the following key should be removed from the registry:
HKEY_CURRENT_USER\Software\madshi\madVR
And delete the settings.bin. I think that'll do it, right? :)
Yes.
Here's a bat file for it. As always when editing the registry, BE CAREFUL! :)
Nice one! I might add it to the next madVR version... :)
With madvr0.54, counter in fraps become 72fps instead of 96 fps and there are lots of presentation glitch.
With madvr 0.55 (even parameters :default parameters), Counter in fraps become 95 fps instead of 96 fps. Presentation glitch counter increase 1 by one each second.
You can try playing with the flush settings in the "exclusive mode settings" tab. Maybe that helps.
Is there a difference between fullscreen exclusive mode of madvr 0.50 and fullscreen exclusive mode of madvr 0.55?
Yes. v0.50 was a first try and (although it seemed to work well for some people) had many bugs and didn't do things really properly. I hope v0.55 does things properly now.
I'm also one of "60fps at 60Hz works fine and 24/30fps at 60Hz does not". By does not I meant presentation glitches is not zero as 60fps/60Hz.
Can you create a log with 60fps at 60Hz (no glitches), and another log with 30fps at 60Hz (glitches)? Maybe if I compare them I can see something. Or maybe not. Might be worth a try, in any case...
Another thing when I set every flush settings for exclusive mode to no flush, switching track using MPC next/previous hangs the program.
Weird. Can anybody reproduce that?
It seems presently (from my opinion at least) that poor madshi is trying his upmost to get these new exclusive mode issues fixed. When fixes for some get sorted it introduces problems for others. When madshi fixes those issues the first people have problems again. It seems to me this could be more me due to problems in gpu drivers than anything else. Maybe it would be an idea to have everyone reporting issues with the new exclusive mode to use a set ati or nvidia driver revision of madshis choosing. I feel it could greatly help this situation.
Well, I had a similar feeling, but I hope that by offering the flush settings again that I might be able to offer a version that works for everybody (after manual tweaking if necessary).
Some things are real bugs. E.g. the fullscreen freeze in v0.54/0.55. Other things are worth looking into, e.g. why some people have glitches with 24fps at 60Hz while they don't have any glitches with 60fps at 60Hz, which doesn't make any sense to me.
Any possibility of making it... blue? :D
:devil:
- playback fine, when resetting the stats, 0 dropped frames, 0 glitches after 30minutes ( fps 23.976 / display 24 ). Additionally, in the OSD field "1 frame drop every..." I get stats like 14 days, 124days, 61 days, 12days, 6 days, 22days...after 30 minutes of playback. Is this fine?
Sounds good to me.
madshi
15th April 2011, 21:08
the new rendering path on ATI 4550 is worse...the +99% GPU usage is effectively causing massive drops.
Which refresh rate and movie frame rate are we talking about here?
Hi, just moved to 0.55 from 0.51 and noticed that moving mpc from one screen to another screen is not anymore flawless, the windows/mouse get stuck and video paused for half a second before allowing me to pass from one screen to another. It’s king of awkward.
Actually older versions didn't handle this properly. I know it looked "flawless". However, try this with an older version:
(1) start windowed one monitor 1.
(2) go fullscreen. madVR should switch to exclusive mode.
(3) go windowed.
(4) move window to monitor 2.
(5) go fullscreen. madVR fails to switch to exclusive mode.
The newer versions fix this. You can now do the above and go fullscreen on either monitor. The cost of this fix is that everytime you move to a different monitor, madVR has to reset the Direct3D device. Which causes that half second pause you've noticed. Sorry, there's nothing I can do about it.
madshi
15th April 2011, 21:09
madVR v0.56 released
http://madshi.net/madVR.zip
* fixed: going directly to fullscreen mode made madVR freeze
SamuriHL
15th April 2011, 21:10
Nice one! I might add it to the next madVR version... :)
Sweet. :) Glad I was able to contribute finally. LOL! :) It should be fairly safe given that I backup the settings.bin. That way they can revert. I never like when these things go wrong. :D It allows people to test settings, too. BUT, and here's the big warning people (!!!) - if you use this multiple times, say, to backup your current settings, set to default, mess with settings, set to default AGAIN, you will have lost your original settings. So if you want to do testing like that BACKUP the settings.old file! :) You have been warned! :D
neb1236
15th April 2011, 21:25
Actually older versions didn't handle this properly. I know it looked "flawless". However, try this with an older version:
(1) start windowed one monitor 1.
(2) go fullscreen. madVR should switch to exclusive mode.
(3) go windowed.
(4) move window to monitor 2.
(5) go fullscreen. madVR fails to switch to exclusive mode.
The newer versions fix this. You can now do the above and go fullscreen on either monitor. The cost of this fix is that everytime you move to a different monitor, madVR has to reset the Direct3D device. Which causes that half second pause you've noticed. Sorry, there's nothing I can do about it.
Well sorry but I don't need to use exclusive mode (as I don't like screen flash when switching to fullscreen, and that I don’t see improvement using exclusive mode)
Will stick to an old version as it satisfies me. Thanks for all the work you’ve done.
Except if you don't reset the Direct3D device when exclusive mode is disable, but I don’t know if it’s possible.
ikarad
15th April 2011, 21:26
You can try playing with the flush settings in the "exclusive mode settings" tab. Maybe that helps.
I tried many combinations and no change. I always have the problem.
Yes. v0.50 was a first try and (although it seemed to work well for some people) had many bugs and didn't do things really properly. I hope v0.55 does things properly now.
.
With 0.50 I have no problem but since 0.51 I have the problem that I described you.
pdanpdan
15th April 2011, 21:35
0.56 is working - no more freeze, thank you
madshi
15th April 2011, 21:38
Well sorry but I don't need to use exclusive mode (as I don't like screen flash when switching to fullscreen, and that I don’t see improvement using exclusive mode)
Will stick to an old version as it satisfies me. Thanks for all the work you’ve done.
Except if you don't reset the Direct3D device when exclusive mode is disable, but I don’t know if it’s possible.
I think the old version should have a higher CPU consumption, too, if you move the media player to a different monitor.
I tried many combinations and no change. I always have the problem.
With 0.50 I have no problem but since 0.51 I have the problem that I described you.
Do you actually *see* the glitches? I mean is motion non-smooth? v0.50 did not even know if there were glitches, even if there were some.
0.56 is working - no more freeze, thank you
Glad to hear that.
SamuriHL
15th April 2011, 21:44
Finally got around to testing on my nVidia, underpowered X2 machine. Works great! Very minor frame drops when doing stupid things like chapter skipping, pause/play, going in and out of FSE mode, etc. Once you let it settle down I lose maybe 1 frame every 3-5 minutes (mainly cause nVidia has no clue what 23.976 actually means. SIGH). It's freaking gorgeous on that Samsung panel. Man I need to replace my living room TV! :D Anyway, I'm extremely pleased with 0.56. Works on my AMD machines, as well.
neb1236
15th April 2011, 21:45
I think the old version should have a higher CPU consumption, too, if you move the media player to a different monitor.
Probably, but to be honest it's kind of difficult to see a difference on a quad core at 4Ghz, 1080p playback plays around 10% cpu so I never had problem with such things... :)
Virtual_ManPL
15th April 2011, 21:50
Can you give me one (only one) really good reason for creating a 64bit build?
-better performance, cause x86-64 add a bunch of registers which can improve it
-compatibility with 64bit players like MPC-HC and PotPlayer
-why not :devil:
nevcairiel
15th April 2011, 21:56
-better performance, cause x86-64 add a bunch of registers which can improve it
64bit also makes addresses and some data-types bigger, which can actually slow down your software.
IMHO, 64-bit is only really useful if you need to handle alot of data, and the 32-bit address space might run out on you.
madshi
15th April 2011, 21:58
Finally got around to testing on my nVidia, underpowered X2 machine. Works great! Very minor frame drops when doing stupid things like chapter skipping, pause/play, going in and out of FSE mode, etc. Once you let it settle down I lose maybe 1 frame every 3-5 minutes (mainly cause nVidia has no clue what 23.976 actually means. SIGH). It's freaking gorgeous on that Samsung panel. Man I need to replace my living room TV! :D Anyway, I'm extremely pleased with 0.56. Works on my AMD machines, as well.
:)
Probably, but to be honest it's kind of difficult to see a difference on a quad core at 4Ghz, 1080p playback plays around 10% cpu so I never had problem with such things... :)
Ok, next try: Do you ever want to get DXVA2 deinterlacing (I'm not saying it will come to madVR anytime soon, if at all)? If so, what the latest madVR versions do is necessary, too.
-better performance, cause x86-64 add a bunch of registers which can improve it
-compatibility with 64bit players like MPC-HC and PotPlayer
-why not :devil:
Better performance? Nope. Current HTPC software is not any faster in 64bit, often it's slower. Compatability with 64bit players is no advantage because you can use 32bit players without any disadvantage (that I can see). "Why not"? Because it would cost many days of hard work, for no practical benefit.
Plutotype
15th April 2011, 21:58
-better performance, cause x86-64 add a bunch of registers which can improve it
-compatibility with 64bit players like MPC-HC and PotPlayer
-why not :devil:
I dont see a reason to push this for now - especially after this weeks 6 versions of madVR. If you want, you can try to convince at first James at the slysoft forum to rewrite Reclock to 64-bit version:)
SamuriHL
15th April 2011, 21:58
I made the argument for 64 bit before, too, but, there's another issue. What decoder to use? ffdshow is pretty much it for 64 bit. No commercial decoders are going to work in 64 bit.
neb1236
15th April 2011, 22:10
Ok, next try: Do you ever want to get DXVA2 deinterlacing (I'm not saying it will come to madVR anytime soon, if at all)? If so, what the latest madVR versions do is necessary, too.
Sorry, don't try to convince me it's better or not, it's just a matter of personal opinion, please don't think everybody is like me, it's just that I only watch progressive video, and I prefer stinking to software decoder rather than DXVA for several stupid personal reason.
What mater to me is fast playback start (I don’t know how but madVR rocks on this part) flawless switching to fullscreen, flawless moving windows around (flawless UI in short), correct upscaling (dithering and lanczos is a minimum), and for performance matter I bought the needed hardware.
madshi
15th April 2011, 22:14
[...] I prefer stinking [...]
:p ...
Razoola
15th April 2011, 22:14
madshi, I have found something very important on my system but it may help others. Remember I was getting those D3D errors? Well with 056 I am getting them again and more frequently too, also had a couple of player lockups, remember this is at 120hz.
I have found a solution that gives me 100% stability so far... A simple change of the new flush settings to 'dont flush', 'dont flush', 'flush', 'dont flush' did the trick.
With the limited tinkering I have done so far it appears having a flush after copy to backbuffer is very important for stability. I can also see having a flush here greatly limits presentation glitches, in fact so far its the only way I have found to limit them from the initial start few that seem to always happen.
ikarad
15th April 2011, 22:19
Do you actually *see* the glitches? I mean is motion non-smooth? v0.50 did not even know if there were glitches, even if there were some.
.
No really (Like counter increase slowly I can't see really if there is a problem with naked eyes) but if the counter increase, it means that there are glitches.
If one day movies that I see are not smoothing, I prefer to know that madvr is not the culprit because I hate make tests during many hours to know where is the culprit.
madshi
15th April 2011, 22:23
madshi, I have found something very important on my system but it may help others. Remember I was getting those D3D errors? Well with 056 I am getting them again and more frequently too, also had a couple of player lockups, remember this is at 120hz.
I have found a solution that gives me 100% stability so far... A simple change of the new flush settings to 'dont flush', 'dont flush', 'flush', 'dont flush' did the trick.
With the limited tinkering I have done so far it appears having a flush after copy to backbuffer is very important for stability. I can also see having a flush here greatly limits presentation glitches, in fact so far its the only way I have found to limit them from the initial start few that seem to always happen.
Well, there's some sense to that. Let me explain:
Let's say you play a 24fps movie on a 120Hz display. What madVR now does (new exclusive path) is this:
(1) render frame 1
(2) copy frame 1 to backbuffer and present
(3) copy frame 1 to backbuffer and present
(4) copy frame 1 to backbuffer and present
(5) copy frame 1 to backbuffer and present
(6) copy frame 1 to backbuffer and present
(7) render frame 2
(8) copy frame 2 to backbuffer and present
(9) [...]
Basically every frame is rendered once and then copied to backbuffer (and presented) 5 times, since 120Hz / 24fps = 5x. Now the first two flush settings only apply to the rendering, but not to the backbuffer copy and presentation. So I guess with high refresh rates, if your GPU/driver needs flushes, you need to flush after the backbuffer copy or after the presentation. Otherwise you'll have a flush only every fifth VSync event. Two questions for my interest:
- does flushing after present instead of after backbuffer work just as well?
- does the new rendering path now work better for you than the old (and than windowed mode)?
Those of you with glitches when doing 24fps -> 60Hz playback, please also try flushing after either the backbuffer copy or after the present!
Razoola
15th April 2011, 22:23
No really (Like counter increase slowly I can't see really if there is a problem with naked eyes) but if the counter increase, it means that there are glitches.
If one day movies that I see are not smoothing, I prefer to know that madvr is not the culprit because I hate make tests during many hours to know where is the culprit.
Try setting the 'after copy to backbuffer' option to flush and see if that solves your presentation glitches from slowly incrementing during playback.
Andy o
15th April 2011, 22:26
The "delay switch to exclusive mode by 3 seconds" option is not working here. It stopped working several versions ago, but I thought that some setting must have gotten stuck or something. Even when resetting and deleting the madvr registry key it still doesn't work. exclusive switches immediately. Is this setting somewhere else in the registry or somewhere else?
Hypernova
15th April 2011, 22:28
Any possibility of making it... blue? :D
:devil:
I suggest rotating between three colors (joking of course).
With all this stream of troubles from introducing new rendering path, I decided to try it out (I'm totally happy with windowed mode). I just want to come out and say that I never actually have any problem with it (havn't try 0.56 yet). Just to give some positive feedback out :)
madshi
15th April 2011, 22:29
The "delay switch to exclusive mode by 3 seconds" option is not working here.
Works for me. How are you testing this? Try right clicking on the video -> context menu. madVR should go windowed mode. Now press Escape. Does madVR switch back to exclusive immediately?
Andy o
15th April 2011, 22:32
oops, not when I do that. When I go from windowed (small window) to full screen. I used to get the 3 second wait before...
jmone
15th April 2011, 22:33
0.56 Testing on my HTPC:
New Render Path & Black Screen / Display Rate Change
1) Pause/Play fixes it: Reclock does the Refresh Rate change and the screen goes to Black. A Pause brings it back to Windowed Mode and you see a still frame. Pressing Play starts playback and it goes back into Exclusive mode and plays on.
2) If Exlcusive Mode fails (no idea why that would be) a player restart is required then all back to normal
3) I did not have any example of a Mismatch in Refresh Rate between madVR and Reclock this time :)
4) Old path is fine.
It just seems that nothing is being presented when in exclusive mode and the Refresh Rate changes. The Pause/Play cuases a Windowed/Exclusive mode cycle that gets it all going again. The other option of couse is the madshi refresh rate changer option (instead of recock)! I'm also surprised no one else is seeing this - I can believe I'm that "special"!
1080/50p
1) madVR's OSD is still happily tearing etc on fast pans. What I find odd on this one is why would a fast pan in the movie cause tearing in the OSD (unless the whole presentation is also tearing in the renderer - which is kind of hard to tell as similar issues could have been in the original encoding from the Cam, decoding by ffdshow etc The OSD however is added after all is decoded)
Razoola
15th April 2011, 22:35
- does flushing after present instead of after backbuffer work just as well?
- does the new rendering path now work better for you than the old (and than windowed mode)?
Yes to both. In fact flushing after present gives me one presentation glitch less (I get 2 when flushing after copy to backbuffer)
update, dang, I just got a D3D error when flushing on presentation. So the answer is no to the first one.
Andy o
15th April 2011, 22:37
btw, I guess I get why you took out that 3 second wait madshi, when going from window to full screen, but if I change refresh rates when on windowed mode, and then switch to exclusive, it works fine. If I change while on exclusive, it doesn't work. I think the 3 second wait might make MPC-HC's auto refresh switch work for some of us, if not most.
ikarad
15th April 2011, 22:38
Try setting the 'after copy to backbuffer' option to flush and see if that solves your presentation glitches from slowly incrementing during playback.
I tried and no change.
leeperry
15th April 2011, 22:52
Im running a 60Hz display on XP, but I really dont know where all the problems you guys have come from.
Running a 60Hz display means that 24p isn't smooth anyway...you can really only test smoothness w/ a perfect multiple refresh rate and Reclock.
I still need the old path, but apparently ditching "upload frames in render thread" is indeed fine.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.