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

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

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:

* 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:

[SamuriHL]

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

[Mark_A_W]

Originally Posted by pankov

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]

Originally Posted by SamuriHL

On my laptop, I have to have the ...after last render step set to flush & wait (sleep) else it no workie.

Originally Posted by someone`

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 .

Originally Posted by fairchild

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.

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

Originally Posted by dansrfe

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?

Originally Posted by Mark_A_W

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

Originally Posted by pankov

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.

Originally Posted by tmbt

Same problem here. If i play on first monitor everything is fine.
On secondary monitor i've flashes/crashes.

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

Originally Posted by Mark_A_W

Yup, mine is secondary monitor.

Ok, something seems to go wrong with secondary monitor, it seems. Will need to check that.

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?

Originally Posted by jmone

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.

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?

Originally Posted by Rain1

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

Originally Posted by Rain1

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.

Originally Posted by yesgrey

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.

Originally Posted by ajp_anton

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.

Originally Posted by ajp_anton

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.

Originally Posted by ajp_anton

Present queue: same as backbuffer?

No, these are frames already sent to Direct3D/GPU. These frames are practically out of madVR's hands.

Originally Posted by ajp_anton

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.

Originally Posted by Hprd

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.

Originally Posted by Andy o

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]

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

Same here...

[jmone]

Originally Posted by madshi

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!

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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.