madVR - high quality video renderer (GPU assisted)

[fairchild]

Thanks for new version madshi. Everything is running good with the latest version (0.54). I am using the new rendering path. After last render step set to flush & wait (sleep). All the others set to no flush. Use windowed mode flush tweaks: selected Using this file which is a 1080p 1.31 minute sample mkv with flac and DTS audio tracks which stresses my system more than any other clip I've ever watched. (Coalgirls-QTS_Kanon_OP_Blu-ray_Box_Eizou_Tokuten_1920x1080_H264-DXVA_FLAC_DTS-HD_MA.mkv) I had zero dropped frames or delayed frames (only 1 presentation glitch which is super minor).

http://www.mediafire.com/?gluvb6wlb2yrgh2

[SamuriHL]

I have to change my stance on my laptop. Watching a few minutes of one of my two videos it breaks up with 0.54. It doesn't seem to matter what I do, it doesn't help. CPU usage is ok, so, it's not dying there. I've tried all variations of flush and nothing fixes it....mostly it just makes it worse. This is an h.264 video. I have to run it for a few minutes before I see the first breakup.

http://www.mediafire.com/?jqv4xtb8l1dr13b

There's a log. I don't know if it'll help. I swear it was playing nicely earlier, but, now I can't reproduce it. I went back to 0.52 temporarily (only one i had kicking around) and I was able to get it to work. Very confused.

EDIT: So I rebooted the laptop and it seems ok now. I give up. Could be some kind of weird network glitch. These are being streamed from my main HTPC over a gigabit network and I've yet to have any problems. Who knows. If I have anymore issues I'll let you know. If something jumps out at you in the log, however, that'd be appreciated.

[Hprd]

Well i seem to have more or less solved my problems (although not really the issue with the que set to 16). I found that if i put the que to 10, with bitperfect playback in reclock, the devation on the "bad" videos only goes up to about -1.5%, then quickly goes down, instead of going all the way up to -5, and staying there, which at the same time of course provided stuttery/unsmooth playback.

And this as well provides playback at lower refresh rates with zero dropped frames/glitches (on a 1080p video with fancy subtitles, and 5.1 flac audio, there probably aren't many harder videos to render i'd imagine). It's not quite ideal for 2-3 minute videos, as it takes about that long to get it very smooth (or well according to the osd), but then again that's not that big of a deal, as it's nowhere near as bad as setting it to 16 on some. And most of the "bad" videos i could care less if they play exactly perfect anyhow, lol.

This was with the windowed mode flush options turned off as well, as they really didn't seem to change anything for me.

Also of note, on 60/48hz there was alot of presentation glitches. I can't really say if they made the playback that unstable (didn't really appear to), but reguardless of the windowed mode tweaks, or the que size, i couldn't seem to do anything about them. On 24/30hz, with the que at at least 10, (like i said above) there was literally zero, so that might have something to do with it.

EDIT: after a little more testing, it seems that the best way to get more or less perfect playback (sometimes this resulted in fewer or no glitches, sometimes there was, it's random for some reason. As one time playing the video normally had no glitches at all...) is to go to fullscreen, then seek somewhere (preferably the start of the video of course) and the amount of frame repeats/deviation is pretty much identical to setting the que to 2. This is only on 10 though, as doing this with the que set to 16 instantly puts the deviation (and the part of the osd showing the frame repeats/drops simply dissapears) up to -5, and stuttery playback commences...

Also, this didn't work on all videos. Doing this with the 1080p 29.970fps 48khz flac videos didn't make any difference, at 30hz anyways, 60hz it did for some reason (although not to the extent as the AAC and AC3 audio videos). Doing it on a 1200p video with 30fps and 44khz audio did though, as did one (the TES V trailer) which has a 29.970 frame rate and 48khz audio. Quite odd really, lol. :confused: (i thought it was something with the scaling, but then i tried a couple 1200p videos i made, and it didn't behave the same as the 1080p ones...).

EDIT #2: This seems to be something with the audio codec used, and probably how it's decoded. As i encoded the audio from the TES V trailer into flac, then muxed it with the video, and it behaved exactly the same as the other flac videos i have. AC3, and AAC videos seem to be the same (which also depends on the framerate then, 30fps exactly is what seems to blow it up, 29.970 and 23.976 are ok, as in they don't seem to get permanently locked at -5% etc, with the que at 16 of course. Although bizzarely once and a while the 30fps videos were ok with the high que, when i was testing that...) and flac is a bit different then, lol.

[Andy o]

Just one (two) quick question. "Delayed frames" count is the same as repeated frames? If not, what's the relation, or difference?

[dansrfe]

Thanks for new version madshi. Everything is running good with the latest version (0.54). I am using the new rendering path. After last render step set to flush & wait (sleep). All the others set to no flush. Use windowed mode flush tweaks: selected Using this file which is a 1080p 1.31 minute sample mkv with flac and DTS audio tracks which stresses my system more than any other clip I've ever watched. (Coalgirls-QTS_Kanon_OP_Blu-ray_Box_Eizou_Tokuten_1920x1080_H264-DXVA_FLAC_DTS-HD_MA.mkv) I had zero dropped frames or delayed frames (only 1 presentation glitch which is super minor).

http://www.mediafire.com/?gluvb6wlb2yrgh2

Awesome SSA subs.

Now v0.54 works great for me with the same settings that you have listed. No more frame drops/delays!

[pdanpdan]

0.53 worked
0.54 produces the following when used with mpc-hc D3D Fullscreen, interface on first monitor, image on second
- both 1st and 2nd monitor flashes
- crashes without any message about 1-2 seconds

[Rain1]

So far setting that works best for me is

* 8 frames pre-rendered
* Use windowed mode flush tweaks
* 8 backbuffers
* flush - flush & wait (sleep) - don't flush - don't flush (top -> bottom order in madVR settings)

With that settings, playing sneaker_ger's clip (http://forum.doom9.org/showthread.php?p=1491639#post1491639):

* Drop frames: 2 2 2 2 2 (!)
* Glitch presentation : 0 0 0 0 0 (!) (around 50 - 60 on 0.53)

Also, my nVidia control panel setting (since 0.52) FYI:
http://i6.photobucket.com/albums/y244/rain1/nvida1.jpg
http://i6.photobucket.com/albums/y244/rain1/nvida2.jpg

[SamuriHL]

Those are the same settings I'm using that work most of the time on my laptop.

[Mark_A_W]

It's the same with me but only when using the second display (projector). If I play it on the first (LCD monitor) everything is fine. I've tried both madVRcpu and madVRcpu2 and I get mixed results - madVRcpu2 flashes/crashes as v0.54 while v0.53 has the same high CPU usage as v0.52/0.51.
Here are some log files from my tests this evening.
http://www.mediafire.com/?xd3r76fo2n5xdz8

Yup, mine is secondary monitor.

I will change that screen to primary and test again.

[madshi]

On my laptop, I have to have the ...after last render step set to flush & wait (sleep) else it no workie.
Yes , SamuriHL's setting is the best for me .
After last render step set to flush & wait (sleep)
All the others set to no flush .
Everything is running good with the latest version (0.54). I am using the [B]new rendering path. After last render step set to flush & wait (sleep). All the others set to no flush.
So far setting that works best for me is

* 8 frames pre-rendered
* Use windowed mode flush tweaks
* 8 backbuffers
* flush - flush & wait (sleep) - don't flush - don't flush (top -> bottom order in madVR settings)
Now v0.54 works great for me with the same settings that you have listed. No more frame drops/delays!
Ok, it seems you all have a quite similar experience.

Can you guys please also experiment with the number of pre-rendered frames (as Rain1 has done)? That'd be helpful for me to find the best default values. Personally, 8 pre-rendered frames works best for me, too. Any objections to using 8 as the new default?

With 0.54 I either get a series of mad flashes as it constantly tries to get into exclusive mode, or Zoom Player just crashes :(
It's the same with me but only when using the second display (projector). If I play it on the first (LCD monitor) everything is fine.
Same problem here. If i play on first monitor everything is fine.
On secondary monitor i've flashes/crashes.
0.53 worked
0.54 produces the following when used with mpc-hc D3D Fullscreen, interface on first monitor, image on second
- both 1st and 2nd monitor flashes
- crashes without any message about 1-2 seconds
Yup, mine is secondary monitor.
Ok, something seems to go wrong with secondary monitor, it seems. Will need to check that.

v0.54 testing on my HTPC

1) Using Relcock to change the Refresh Rate to match the media fps but I'm seeing a different behaviour from V0.52:
- V0.54 using New Path = Upon a refresh rate change, madVR now displays video frames but the OSD stills says the old refresh rate and while it does not report any dropped frames the playback is choppy
- V0.54 using Old Path = Fine.
Hmmmm... Is this on the primary or secondary monitor? Did you change the refresh rate while madVR was already running or before you started madVR? Does the madVR refresh rate information ever move again after you've changed the refresh rate? Or is it fixed with zero fluctuations from the time of the refresh rate change on?

Q) - Given NOT changing freq to match fps produces a poor playback expereince, I'm not sure that new path is currently a viable option to HTPC duty which has a mix of fps material. Or am I missing somthing?
The new path should work just as fine as the old one for mixed fps.

2) 1080/50p x264 material plays well but I see that on fast pans the OSD itself breaks up / tears / displays duplicate characters etc
Please try using the flush settings as described in the v0.54 release post. Does that make a difference?

* Drop frames: 2 2 2 2 2 (!)
* Glitch presentation : 0 0 0 0 0 (!) (around 50 - 60 on 0.53)
Nice! :) Did you double check if the high CPU consumption is really fixed? Just to be sure...

Also, my nVidia control panel setting (since 0.52) FYI: [...]
Do you get any different results with madVR if you switch the NVidia control panel back to default (Maximum Pre-Rendered Frames -> 3)? Thanks.

I was going to post my log with v0.53 because I had several problems with one file, but you beat me. v0.54 is running great, without any problems, so it probably were the high cpu usage problems.

When we start thinking that madVR cannot improve anymore, you come and surprise us. :)
:)

Is the "slow" (.5 s) windowed<->exclusive switch because of madVR or Windows (/drivers)?
I noticed that all buffers seem to be emptied after the switch. Can't you render the frames already created, and just start filling the buffers with frames of the new size, and do the actual switch when all "old" frames are rendered?
I've not fully investigated this yet. The switch from exclusive -> windowed mode is expected to be slower with the new rendering path. Probably no way around it. That said, maybe there's a way to at least improve things a bit. But let's first make playback with the new rendering path work as well for everybody as possible. That's more important than a quick windowed <-> exclusive switch for now.

Not sure I understand the function of each queue shown in the OSD... how much of the following is correct?
Decoder queue: Decoded YV12 frames, stored in system RAM
Upload queue: Frames sent to the graphics RAM
Render queue: Processed frames in RGB
Backbuffer queue: "Direct3D queue for frames soon to be presented"
Correct.

Present queue: same as backbuffer?
No, these are frames already sent to Direct3D/GPU. These frames are practically out of madVR's hands.

Also, the backbuffer/present queues never seem to want to go above ~11-13. But when set to 16, the seekbar delay seems to be a lot faster than when it's at ~2 or 3.
The backbuffer/present queues are somewhat limited by the size of the render queue which is max 8 with the current madVR version. I'd have to increase the render queue size to allow the backbuffer/present queue to fill completely. The situation is different, though, if you have a very high refresh rate, then the backbuffer/present queues should fill just fine. If the seekbar delay is smaller with 16 frames then that probably means that your GPU/driver doesn't handle 16 properly. I would better not use it then. You might get audio/video desync otherwise.

This is only on 10 though, as doing this with the que set to 16 instantly puts the deviation (and the part of the osd showing the frame repeats/drops simply dissapears) up to -5, and stuttery playback commences...
I think 16 frames is running into some kind of driver (or maybe memory) limitation in your case. Since 16 doesn't work well you, simply don't use it.

Just one (two) quick question. "Delayed frames" count is the same as repeated frames? If not, what's the relation, or difference?
I do/can not count repeated frames at the moment. That's to come in some future version. "Delayed frames" are frames that were not dropped, but shown a bit later than originally planned. Delayed frames are not as bad as dropped frames, but they're bad enough.

[Hprd]

I think 16 frames is running into some kind of driver (or maybe memory) limitation in your case. Since 16 doesn't work well you, simply don't use it.

Yeah probably something like that, fortunately though 10 seems perfect with this version :)

[zeroo]

I have installed 0.54, but when I switch to fullscreen mode on secondary display, mpc-hc crashes. I tried with all flush options on and off, but no luck. Once I even got a BSOD, too.

Here is the log:
http://www.mediafire.com/?f59lf2qqmyv725l

With 0.53 no crashes at all.

[cyberbeing]

Preliminary Flush settings which are working best for keeping queues full:

NVCPL Maximum Pre-Rendered Frames = 0 (I don't know why, but setting this to 0 seems to be a minor improvement over the default 3 for keeping Present/Backbuffer queues full)
Present Queue = 2 (setting >2 results in stuttering with and without frame drops and empty queues)
After Intermediate Render Steps = Flush & Wait (I'll need to test if Sleep vs Loop makes a difference, I'm somewhat suspecting it may but only at startup)
Everything Else = Flush or No Flush (I'll need to do some smoothness tests so see which is best)

Note: Setting 'After Last Render Step' to Flush & Wait is better than flushing disabled, but worse than After Intermediate Render Steps set to Flush & Wait.
Setting both to Flush & Wait makes things worse than flushing disabled. Unfortunately, this doesn't seem to coincide with what a couple others have found.

madshi, I'd still like to test a build where I can set the Present Queue to 1. Setting it to 3 is still unusable, and setting to 2 is an improvement but not great. Even though refresh rate calculation was fixed, nothing has improved in that regard. Using the flush settings above did help (I can use Mitchell-Netravali (Chroma) + Spline36 (Luma) resizing once again), but it's still not as stable as I'd like. Does the present queue and the backbuffer need to be set the the same number?

On another note, since we seem to need flush settings for Fullscreen Exclusive now, I'd like them to be independent of the Windowed Mode settings. I need to use literally the exact opposite flush settings for windowed mode, so having them both shared doesn't really work.

Here are a couple mpc-hc crash on close logs with madVRcpu2:
http://www.mediafire.com/?f45g2gzgsbbknta

Did you want me to get the hang-on-close logs with madVRcpu2 or madVR 0.54 official. I assume madVRcpu2 since it still has more logging?

It may also be nice if you printed Debug and possibly Version # at the top of the CTRL+J Stats when applicable (i.e. madVR 0.54 Debug OR madVR 0.54).

[cvrkuth]

I have installed 0.54, but when I switch to fullscreen mode on secondary display, mpc-hc crashes. I tried with all flush options on and off, but no luck. Once I even got a BSOD, too.

Here is the log:
http://www.mediafire.com/?f59lf2qqmyv725l

With 0.53 no crashes at all.
Same here...

[jmone]

Originally Posted by jmone
v0.54 testing on my HTPC

1) Using Relcock to change the Refresh Rate to match the media fps but I'm seeing a different behaviour from V0.52:
- V0.54 using New Path = Upon a refresh rate change, madVR now displays video frames but the OSD stills says the old refresh rate and while it does not report any dropped frames the playback is choppy
- V0.54 using Old Path = Fine.

Hmmmm... Is this on the primary or secondary monitor? Did you change the refresh rate while madVR was already running or before you started madVR? Does the madVR refresh rate information ever move again after you've changed the refresh rate? Or is it fixed with zero fluctuations from the time of the refresh rate change on?

To answer your Q's
- Only one Monitor (HDTV)
- Reclock does kicks of the display rate change so the graph is already built at this stage. Reclock "sees" the mismatch then changes the refresh rate
- madVR refresh rate keeps moving slightly all the time (eg it is not Frozen on one value).

Doing more testing I notice that the result is not always the same.
1) Black Screen at Refresh Rate change but Pause/Play fixes it: This is the most common with V45. 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) Exlcusive Mode fails hence the refreash rate change has no impact
3) Mismatch in Refresh Rate between madVR and Reclock - Less common and seems to occur more after frequent start /stops See pic but CCC agrees with madVR so Relcock is the odd one out...very odd!

http://img33.imageshack.us/img33/7996/madof.jpg


Originally Posted by jmone
2) 1080/50p x264 material plays well but I see that on fast pans the OSD itself breaks up / tears / displays duplicate characters etc

Please try using the flush settings as described in the v0.54 release post. Does that make a difference?

It did not make any difference regardless of the flush settings.

[watchman]

I did few more test with 0.54 and here is what I found:

24fps at 60hz, 30fps at 60hz - still lot of presentation glitches even with new flushing tweaks (I tried almost every combination of flushing and also experimented with backbuffers and pre-rendered frames number but there was no difference at all)

24fps at 24hz, 60fps at 60hz - 0 presentation glitches with or without flushing tweaks

So it seems like I just neet perfectly match display refresh rate with source fps to get 0 glitches. Well it's not a big deal since I'm doing it all the time so I can still use last version in everyday life.

@to answer your question about pre-rendered frames: 8 are working best for me as well

[ryrynz]

Can you please retry with v0.53? Which is your display refresh rate and which (non-doubled) framerate does your h264 content have?


Tested 0.54 and that's fixed it, I'm on to the new exclusive mode! :)

When edge-detect anti-aliasing is enabled and framerate doubling with process frames marked as progressive are ticked I get a lot of glitches and dropped frames.
The other FSAA settings don't cause dropped frames for me with the framerate doubling, perhaps a wise idea to set FSAA to use application settings.

BTW I prefer the red OSD, that green is a pain to see sometimes.

[kennae]

Hi there. I installed latest MadVR and now MPC-HC crashes when going to fullscreen. Tried all the latest builds of mpc-hc + ffdshow and the ones that were working before, no dice.

So the same problem with two other people.

[Gleb Egorych]

With 0.52 no dropped frames but presentation glitches appear while decoder, render, backbuffer queues are stable. I guess you fixed stats. Playback experience is the same as with 0.51 - with 14 or 16 frames pre-render playback is smooth, jerking with lesser number of frames.

0.53 is worse for me, even with 14 and 16 pre-rendered I have some glitches.
Try the v0.54 flush settings, they might help.
0.54 is better than 0.51 & 0.52 and a way better than 0.53. It requires only 10+ pre-rendered frames to get smooth playback instead of 14+ with 0.51 and 0.52. Unfortunately windowed mode tweaks do not allow to lower the number though with tweaks and 8 pre-rendered frames presentation glitches appear significantly rarely than without tweaks and with the same 8 frames.

[fairchild]

Ok, it seems you all have a quite similar experience.

Can you guys please also experiment with the number of pre-rendered frames (as Rain1 has done)? That'd be helpful for me to find the best default values. Personally, 8 pre-rendered frames works best for me, too. Any objections to using 8 as the new default?

I changed mine to 8 pre-rendered frames and noticed no ill effects. I'll continue to monitor and let you know if anything changes.

[yesgrey]

A few more notes:
-For me v0.54 works perfectly without messing with the flush options
-People with nvidia cards should consider update to 270.51 drivers. In my first tests I was using the previous ones and had several problems. With the newer versions (v0.53 and v0.54) the image froze whenever madVR switched to the new rendering path. When I tried 16 pre-rendering frames mpc-hc crashed. After installing 270.51 drivers everything was fixed. Now I can even use 16 pre-rendering frames. I thought it was a memory limitation of my card (512 MB), but it wasn't. With the 16 pr frames the memory used is ~370MB.

[chogster]

Everything sweet on this side of the house with 0.54! HAM is running great on my HD5450 with no dropped frames. PQ is tiptop!!

[kennae]

I have been using the latest nvidia drives since they came like a month ago (270.51). And I have always used pre rendered frames as 0, even before trying MadVR for the first time. It's not that. MadVR has always worked greatly for me, always full queues with every settings I've tried.
Never got any dropped frames. So this is not my hardware I bet.

What was the page to get older MadVR versions? The 0.53 and every version before that worked great for me.

Reverted back to 0.53 and everything is smooth as used to be.

[6233638]

My original hope for the new exclusive mode rendering path was that no manual tweaks would be necessary. But after the last couple of days and various feedback from you guys my impression is that the flush settings do still make a difference, sadly. So I've now added an option which allows you to activate the flush settings for the new exclusive mode rendering path, too. If you don't activate this option, no flushs are done at all. If you find that activating some flushs works better for you, please let me know which exact settings work best for you. My recommendation on what to try is this:

(1) Try default setting without any flushs first. If you don't get good results:
(2) Activate the "use windowed flush tweaks" option. Then try setting "after last render step" and "after D3D presentation" to "flush", set the others to "don't flush". If that still doesn't help:
(3) Try setting "after intermediate render steps" to "flush", too, in addition to (2). If that still doesn't help:
(4) Try setting some "flush"s to "flush & wait", maybe first "after last render step" or "after D3D presentation".Thanks for the update. I'm still having a ton of presentation glitches. The only way to stop them seems to be setting "after copy to backbuffer" to sleep or loop, but that then causes the other buffers to drop as they were doing previously.

I have a large collection of logs for you, and I hope the naming makes sense.

http://www.mediafire.com/?t2oh5rhtd74tk18


I am also getting visible stuttering that does not show up in the stats, and the screen flickers (once) when entering fullscreen.

I am also seeing a large number of times when I quit MPC-HC (using your 3005 version) and the process does not exit and has to be closed via task manager.

[fairchild]

Can someone tell me what's the benefit of running the highly touted HAM decoder? Is it primarily for weaker systems (HTPC or laptops with weak cpu?) or is there another benefit to it as far as picture quality goes?

Also, I've gotten the HAM decoder to work with MadVR but some videos display a green line at the bottom of the video that stretches horizontally accross the screen. I've seen it on 720p and 1080p videos irregardless of the aspect ratio (16x9, 2.35, 2.4) of the clip or irregardless of the renderer (EVRCP, madVR) or the video player (mpc-hc, potplayer) which I never see using software decoders or other DXVA decoders.

[SamuriHL]

Ok, it seems you all have a quite similar experience.

Can you guys please also experiment with the number of pre-rendered frames (as Rain1 has done)? That'd be helpful for me to find the best default values. Personally, 8 pre-rendered frames works best for me, too. Any objections to using 8 as the new default?


The settings rain1 posted are EXACTLY what I've been using on my laptop and give me the best results. I have no objections at all and would appreciate that as the default. Have you given any more consideration into a "reset to default" setting?

[Mark_A_W]

Yup, mine is secondary monitor.

I will change that screen to primary and test again.

I tested again, with the video screen set to primary.

No stability issues, no jumping to 60hz, it just works....

....well, except for the presentation glitches which are relentless.


Queues and time stats appear ok - I tried to get a screenshot...now I know why you guys have been asking for that feature to be added....

And having viewed the green OSD...I vote red. Sorry, but the green is washed out by the image half the time. Red is an unusual colour, green is present in almost all images.

Log;

http://dl.dropbox.com/u/1372034/madVR%20-%20log%20presentation%20glitches%200.54.txt

[SamuriHL]

Everything sweet on this side of the house with 0.54! HAM is running great on my HD5450 with no dropped frames. PQ is tiptop!!

Awesome! No more HAM issues? That's really great!

[Mark_A_W]

Have you given any more consideration into a "reset to default" setting?


+1

Sometimes I screw things up and have to rely on screenshots that I took to restore madVR settings to default.

[SamuriHL]

Can someone tell me what's the benefit of running the highly touted HAM decoder? Is it primarily for weaker systems (HTPC or laptops with weak cpu?) or is there another benefit to it as far as picture quality goes?

Also, I've gotten the HAM decoder to work with MadVR but some videos display a green line at the bottom of the video that stretches horizontally accross the screen. I've seen it on 720p and 1080p videos irregardless of the aspect ratio (16x9, 2.35, 2.4) of the clip or irregardless of the renderer (EVRCP, madVR) or the video player (mpc-hc, potplayer) which I never see using software decoders or other DXVA decoders.

Yea, basically it helps lower the CPU requirements. I don't actually need it on my HTPC as it's a c2q 8200, but, with it MPC-HC rocks around 10-14% on average. With software decoding that jumps up to 30-40%. You have a powerful enough machine, go with software decoding if you're getting glitches with HAM. For my laptop, it's 100% necessary else I'd not be able to use madVR at all.

[nlnl]

madshi, thank you for 0.54!

W7, 5750, MPC HC, CoreAVC, Aero on, spline4 chroma up, no scaling 1080p, default setting without any flushs

2 pre-render frames (present buffers) - OK
4 - OK
8 - dropping frames

madshi,
Could you define "presentation glitch"? Is it visible?

Editing:

Retested after reloading and 2, 4, 8, 16 pre-render frames are OK :). Very stable queues and no dropping frames

[Virtual_ManPL]

Any plans for 64bit build ? :cool:

[leeperry]

now that the OSD has become readable, I can definitely say that the new path(whatever w/ or w/o windowed tweaks) is a "presentation glitches" feast for me on XPSP3(I always reset the counter after going FSE): http://www.mypixelz.fr/thumb.php?id=58E1_4DA85B84 (http://www.mypixelz.fr/image.php?id=58E1_4DA85B84) ...OTOH, the old path w 0.54 is fine: http://www.mypixelz.fr/thumb.php?id=1FEB_4DA85B84 (http://www.mypixelz.fr/image.php?id=1FEB_4DA85B84)

please don't remove the old path just yet :o

[nevcairiel]

the new path(whatever w/ or w/o windowed tweaks) is a "presentation glitches" feast for me on XPSP3(I always reset the counter after going FSE)

[...]

OTOH, the old path w 0.54 is fine:

The old path does not show presentation glitches, that does not mean it doesnt have any. See quote from madshi here:


v0.52 now properly shows and handles presentation glitches. Please note that v0.49 and earlier versions were not able to detect presentation glitches even if they occurred (!!). That means if you see the presentation glitch statistic increase with v0.52 which you didn't see with v0.49 that's not yet a reason to worry. Trust your eyes above all else.

leeperry, didn't you think it was kinda odd that it didn't even have a display showing 0 for it... :P

[ikarad]

I have a problem with madvr 0.54 (maybe also with madvr 0.51 and other)

With 0.54 madvr
When I'm in exclusive fullscreen mode, I have 96 fps and at some moment the counter in fraps become 72 fps and the counter "presentation glitches" increase.
Screenshot
before
http://img4.hostingpics.net/thumbs/mini_7576421542012sansproblem.jpg (http://www.hostingpics.net/viewer.php?id=7576421542012sansproblem.jpg)

after
http://img4.hostingpics.net/thumbs/mini_7101861542012problem.jpg (http://www.hostingpics.net/viewer.php?id=7101861542012problem.jpg)

With madvr0.51, same problem but presentation glitches counter doesn't increase (stay at 0).

With madvr 0.50, FPS at fraps stay at 96fps in fullscreen mode.

Is-it normal or not?

I have parameters at default in madvr and I use windows xp sp3 with geforce gtx280 and 270.51 driver. I tried with differents versions of mpc-hc (the last and older) and same problem. I use ffdshow and reclock.

[oddball]

Something broke with 0.54 my screen keeps flashing on and off (Nvidia). Tried on my laptop with Intel HD and it does the same. MPC-HC 3033 (Did it with 3011 too). Also MadVR is leaning heavily on my CPU. Typical CPU when decoding 1080p without MadVR is 30-50% on a E7600 decoding with CoreAVC software only (I have a few things in the chain like ffdshow filters amd ReClock). But with MadVR it's using nearly 100% CPU. I'm having big problems with the Intel HD and MadVR on some high bitrate 1080p content. I've remuxed a well known blue folk BluRay into a MKV file and it causes huge stress on both my E700 system and an i5 540M laptop with the Intel HD graphics.

[leeperry]

The old path does not show presentation glitches, that does not mean it doesnt have any.
good point! but 0.49 was dead smooth for me, and I can't really get 0.53/0.54 to be as smooth when using the new path. The picture is slightly hiccuping from time to time...which is easily understandable as the "presentation glitches" counter keeps increasing rather steadily :o

[namaiki]

I found 0.54 about half as CPU intensive as 0.53 when using the new exclusive mode. (~24fps on 72Hz screen; madVR default settings)

However, I also got the same crash that others experienced when using madVR on secondary monitor. 0.53 was perfect in that regard.

[sneaker_ger]

I'm still getting these presentation glitches, even when playing around with the flush settings. (Can't test them all of course)

Is it correct that all people with these problems are playing their videos on a display with higher frequency, i.e. 24p at 60Hz?

[Qaq]

madshi, I'm happy to say that v0.54 fixed all the issues for me (ATI 5450). Finally! Thanks!
In FSE mode CPU usage is about 15% even with FullHD 1080p/24 video (here I have to thank Cyberlink HAM also). No dropped/delayed frames and playback is smooth without notes. In windowed mode CPU usage is still high, but WM is doesn't matter for me, I even didn't try any tricks yet. Thanks again for your hard work and have a good weekend!

To All. HAM is really matters for madVR! 15% vs 60% for HAM vs SW modes. HAM wins! BTW, tried DXVA mode also, got green screen :eek:.

[oddball]

OK another problem. If I have a video that is just under 1920x1080 (Like 1919x1079) MadVR tries to scale it causing huge strain on my lowly video card (G210 in main PC and INtel HD in laptop). This makes some HD movies unplayable. The only workaround I have found is to set ffdshow to resize always to 1920x1080. Any other way around this other than getting a beefier graphics card for my main PC? Would I be able to have everything set high, 1079 upscaling and CUDA acceleration on a GTX 560 (Thinking of getting the Palit 2GB version) for instance?

I've gone back to 0.52 (missed 0.53 download) for now because of the secondary screen issue.

[nevcairiel]

A GTX560 should have plenty power to do any kind of upscaling you need.

[namaiki]

If I get a video that is *just* under 1080p, I just play it at it's regular resolution and have black bars.

[madshi]

I have installed 0.54, but when I switch to fullscreen mode on secondary display, mpc-hc crashes.
Should be fixed in v0.55.

NVCPL Maximum Pre-Rendered Frames = 0 (I don't know why, but setting this to 0 seems to be a minor improvement over the default 3 for keeping Present/Backbuffer queues full)
Weird!

Present Queue = 2 (setting >2 results in stuttering with and without frame drops and empty queues)
After Intermediate Render Steps = Flush & Wait (I'll need to test if Sleep vs Loop makes a difference, I'm somewhat suspecting it may but only at startup)
Everything Else = Flush or No Flush (I'll need to do some smoothness tests so see which is best)
Somehow your PC is always different to everybody else's... :p

madshi, I'd still like to test a build where I can set the Present Queue to 1. Setting it to 3 is still unusable, and setting to 2 is an improvement but not great. Even though refresh rate calculation was fixed, nothing has improved in that regard. Using the flush settings above did help (I can use Mitchell-Netravali (Chroma) + Spline36 (Luma) resizing once again), but it's still not as stable as I'd like.
Ok, v0.55 allows you to choose a present queue of 1.

A general question: Does windowed mode still work better for you than the new exclusive mode?

Does the present queue and the backbuffer need to be set the the same number?
Yes.

Here are a couple mpc-hc crash on close logs with madVRcpu2
Thanks. But unfortunately madVR logs rarely help for crash problems.

Did you want me to get the hang-on-close logs with madVRcpu2 or madVR 0.54 official. I assume madVRcpu2 since it still has more logging?
The logging is still in there. You can use v0.54 or v0.55.

- Only one Monitor (HDTV)
- Reclock does kicks of the display rate change so the graph is already built at this stage. Reclock "sees" the mismatch then changes the refresh rate
- madVR refresh rate keeps moving slightly all the time (eg it is not Frozen on one value).

Doing more testing I notice that the result is not always the same.
1) Black Screen at Refresh Rate change but Pause/Play fixes it: This is the most common with V45. 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) Exlcusive Mode fails hence the refreash rate change has no impact
3) Mismatch in Refresh Rate between madVR and Reclock - Less common and seems to occur more after frequent start /stops See pic but CCC agrees with madVR so Relcock is the odd one out...very odd!
Yeah, odd. Maybe v0.55 fixes this?

It did not make any difference regardless of the flush settings.
Too bad... :(

24fps at 60hz, 30fps at 60hz - still lot of presentation glitches even with new flushing tweaks (I tried almost every combination of flushing and also experimented with backbuffers and pre-rendered frames number but there was no difference at all)

24fps at 24hz, 60fps at 60hz - 0 presentation glitches with or without flushing tweaks
60fps at 60Hz works fine and 24fps at 60Hz does not!? That's extremely weird!! I've no explanation for that...

perhaps a wise idea to set FSAA to use application settings.
Yes, definitely!

BTW I prefer the red OSD, that green is a pain to see sometimes.
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. Maybe someone should set up an official vote somewhere. Not me, though.

Thanks for the update. I'm still having a ton of presentation glitches. The only way to stop them seems to be setting "after copy to backbuffer" to sleep or loop, but that then causes the other buffers to drop as they were doing previously.

I have a large collection of logs for you, and I hope the naming makes sense.
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.

I am also seeing a large number of times when I quit MPC-HC (using your 3005 version) and the process does not exit and has to be closed via task manager.
I'm seeing that, too, and I think it's a bug in MPC-HC. But what can I say...

Have you given any more consideration into a "reset to default" setting?
It's on my to do list. Like a million of other things.

Could you define "presentation glitch"? Is it visible?
It should be visible but if your refresh is higher than the movie framerate it might not be too bad. A presentation glitch is a glitch that occurs outside of madVR's control.

Any plans for 64bit build ? :cool:
Can you give me one (only one) really good reason for creating a 64bit build?

please don't remove the old path just yet :o
Don't plan to. I wish I could, but it seems the old path works better for several people. Probably mostly those with high refresh rates, I'd guess...

When I'm in exclusive fullscreen mode, I have 96 fps and at some moment the counter in fraps become 72 fps and the counter "presentation glitches" increase.
Try v0.55.

Something broke with 0.54 my screen keeps flashing on and off (Nvidia). Tried on my laptop with Intel HD and it does the same. MPC-HC 3033 (Did it with 3011 too). Also MadVR is leaning heavily on my CPU. Typical CPU when decoding 1080p without MadVR is 30-50% on a E7600 decoding with CoreAVC software only (I have a few things in the chain like ffdshow filters amd ReClock). But with MadVR it's using nearly 100% CPU.
Try v0.55. Not sure where high CPU consumption should come from, though. Is that a new problem? Or did you have that with older madVR versions, too?

Is it correct that all people with these problems are playing their videos on a display with higher frequency, i.e. 24p at 60Hz?
Maybe not all, but most, it seems to me.

I'm happy to say that v0.54 fixed all the issues for me (ATI 5450). Finally! Thanks!
In FSE mode CPU usage is about 15% even with FullHD 1080p/24 video (here I have to thank Cyberlink HAM also). No dropped/delayed frames and playback is smooth without notes.
Yey! :)

If I have a video that is just under 1920x1080 (Like 1919x1079) MadVR tries to scale it
madVR does what the media player tells it to. You can configure the media player to do no scaling. E.g. with MPC-HC right click on the video, then choose "Video Frame -> Normal Size".

[madshi]

madVR v0.55 released

http://madshi.net/madVR.zip

* a couple of bugfixes and improvements for dual monitor setups
* added new render option tab named "exclusive mode settings"
* moved some exclusive mode options from "general settings" tab to new tab
* added separate flush options for exclusive mode (old and new path)
It seems that I have to keep both the old and new exclusive mode rendering paths, at least for the time being. Because of that I've renamed the option in the settings dialog. The option to switch between old <-> new is now named after what it really does. The name of the option is now "present only one frame at a time". That's a description of the old exclusive rendering mode. It's disabled by default.

[SamuriHL]

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. Maybe someone should set up an official vote somewhere. Not me, though.


SIGH. :( I know I like the green as do a few others. Sorry for those that liked the red. It really was hard to read for some of us and the green is a LOT better.

I'm seeing that, too, and I think it's a bug in MPC-HC. But what can I say...


I saw this on my laptop yesterday. It's very possibly what caused it to not work right and why a reboot "fixed it". I happened to notice after the fact that I had a bunch of MPC-HC instances still running. BLECK!


It's on my to do list. Like a million of other things.


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? :)

[ikarad]

madVR v0.55 released

http://madshi.net/madVR.zip

* a couple of bugfixes and improvements for dual monitor setups
* added new render option tab named "exclusive mode settings"
* moved some exclusive mode options from "general settings" tab to new tab
* added separate flush options for exclusive mode (old and new path)
It seems that I have to keep both the old and new exclusive mode rendering paths, at least for the time being. Because of that I've renamed the option in the settings dialog. The option to switch between old <-> new is now named after what it really does. The name of the option is now "present only one frame at a time". That's a description of the old exclusive rendering mode. It's disabled by default.

There is still a problem but less important.

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.

screenshot here
http://img4.hostingpics.net/thumbs/mini_8867341542012problem2.jpg (http://www.hostingpics.net/viewer.php?id=8867341542012problem2.jpg)
http://img4.hostingpics.net/thumbs/mini_1338221542012problem2.jpg (http://www.hostingpics.net/viewer.php?id=1338221542012problem2.jpg)


Is there a difference between fullscreen exclusive mode of madvr 0.50 and fullscreen exclusive mode of madvr 0.55?

[nevcairiel]

Why do you try to fraps your video player, anyway? That seems terribly backwards

[oddball]

"madVR does what the media player tells it to. You can configure the media player to do no scaling. E.g. with MPC-HC right click on the video, then choose "Video Frame -> Normal Size"."

Heh! That just makes lower res videos shrink into the diaplsy with black bars all sides. I think the ffdshow trick works better and I have setup profiles to make that happen.

[ikarad]

Why do you try to fraps your video player, anyway? That seems terribly backwards

And why not?

If you want to know, it's just to see if there is no problem with new version of madvr and also I have forgotten to turn off fraps after playing game. Moreover, I wouldn't see this problem if I didn't use fraps because presentation glitch counter is to little and light green is not very visible.

Maybe the problem seems lie to a problem with refresh rate or simliar thing. Fraps shows that there is a problem.