madVR - high quality video renderer (GPU assisted)

[cyberbeing]

I did some testing in Windows 7 Ultimate x64 with the GTX 470.

Unsurprisingly, using Aero did result in vastly different behavior.

The only setting which is found reasonably smooth were:

After Render Steps: Don't Flush (Any other setting caused massive stuttering)
After Last Step: Don't Flush (Any other setting caused massive stuttering)
After Backbuffer: Flush (All Flush & Wait settings caused massive stuttering. Don't Flush caused minor stuttering)
After Present: Don't Flush (Any other setting caused massive stuttering)

All in all, even with the above settings, using Aero with madVR wasn't all that smooth, but the above was at least somewhat tolerable.

Interestingly, if I set After Present to Flush & Wait, my avg and max present times skyrocketed higher than my VSync interval. Could it be that madVR doesn't show the present times correctly when using Aero, without a Flush & Wait setting set for After Present? Considering madVR required Flush & Wait in order to get correct stats for After Render Steps & After Last Step, I wouldn't be surprised if that is the case here as well. Aero breaks madVR's normal present time stat recording, but Flush & Wait restores it. This makes me believe that actual Aero present times really aren't <1ms, but rather quite high and currently harm madVR present performance considerably.

This seems to potentially be confirmed when I disable Aero.

I did some testing with Aero disabled, and surprise, surprise, madVR seemed to behave similarly to Windows XP (with a few additional quirks). When I tested all flush setting again, I eventually ended up with the exact same settings I was using on WinXP.

After Render Steps: Don't Flush
After Last Step: Flush
After Backbuffer: Flush & Wait (Loop)
After Present: Flush & Wait (Loop)

The above settings I can now confirm give me near perfect smoothness on both Windows XP & Windows 7 (Aero Disabled). Speaking of only Windows 7, using the above settings with Aero Disabled, is literally twice as smooth as when Aero is Enabled using the settings at top.

Windows 7 Ultimate x64 & Windows XP Pro x86
AMD X2 4800+ (939) @ 2.64Ghz (220Mhz X 12)
2GB DDR400 @ DDR440 (2-3-3-6-1T)
NVIDIA GTX 470 (Forceware 257.15 Beta)
CRT Monitor (Single Display)
1920x1080 @120Hz | 1600x1200 @96Hz
MPC-HC x86 | CoreAVC 2.0 (tested both w/ CUDA & w/o CUDA) | Haali Media Splitter | FFDShow Audio | madFLAC | VSFilter


Sometime around the beginning of next week, I'll be building my mother a Core i5-750, 4GB DDR3, ATI Radeon 5750, Win7 Pro x64 computer. I'll do some madVR testing with that PC when it is built, to see if anything is different.

End of this week I'll be returning this GTX 470, and be back to using my 7800GTX 512. I'll then need to do some testing with my 7800GTX 512. So far I've been able to to none since all these madVR changes happened. Overall I've been very pleased with the GTX 470, but my own computer upgrade likely still a bit in the future. Depending how things go, I may end up building my next computer around Intel's Sandy Bridge LGA 2011 platform & NVIDIA's Fermi 2 (or whatever NVIDIA has out) in 2H 2011, if that is when LGA 2011 ends up being released.

[namaiki]

cyberbeing: which forceware drivers are you using on Windows 7?

Also: http://forum.doom9.org/showpost.php?...postcount=3190 Please try it and keep stats/OSD off and Aero on for that config. I would very much like to know what you see with it.

[cyberbeing]

Originally Posted by namaiki

cyberbeing: which forceware drivers are you using on Windows 7?

Also: http://forum.doom9.org/showpost.php?...postcount=3190 Please try it and keep stats/OSD off and Aero on for that config. I would very much like to know what you see with it.

Using Forceware 257.15 Beta.

I just tested your settings in that post, and they were giving me constant significant stuttering. Not good at all for my setup.

And just for clarification, when I say something is stuttering in with Aero enabled, it is extremely stuttering. The stuttering I get with Aero disabled and WinXP is only minor (depending on the setting, you may have to really focus to see it) compared to Aero stuttering (always blatantly obvious). Aero seems much more picky in regard to what works acceptably with madVR.

[namaiki]

What about my settings from before + After Backbuffer: Flush?
I tried your Aero on settings as above, but video looked 'slow'. (tested 1280x720 ~24fps on 60Hz) My knowledge/vocabulary doesn't go far enough to describe exactly how it looked, but it wasn't stuttering (frames back and forth).

[cyberbeing]

Considering we are dealing with low framerate 24fps content, 'slow' (which makes me think evenly spaced frames) may actually be the correct feeling when displaying it at a higher refresh rate without interpolation. You aren't getting any dropped or delayed frames, correct? It's still hard to say without seeing what you're experiencing. You're also using a non-multiple refresh rate, 60Hz, which I haven't tested much at all myself.

I tried your settings + After Backbuffer Flush, and as soon as I got to a panning scene there was noticeable stuttering.

I should also mention that for the time being, I don't have Reclock installed on Win7, so I'll try throwing that into the mix. I'm not all that confident it will make things much different, but we'll see.

Edit
Nope, Reclock didn't make any difference with your settings. Still stuttering.

Reclock helped very slightly with my Aero settings (After Backbuffer Flush only), but still nowhere near the smoothness of my Aero Disabled settings.

[namaiki]

About half the effect of Youtube on old flash player at full screen slow.

I get stuttering for 30fps(reclock on and off) on 60Hz with:

After Render Steps: Don't Flush (Any other setting caused massive stuttering)
After Last Step: Don't Flush (Any other setting caused massive stuttering)
After Backbuffer: Flush (All Flush & Wait settings caused massive stuttering. Don't Flush caused minor stuttering)
After Present: Don't Flush (Any other setting caused massive stuttering)

[cyberbeing]

I'm really beginning to think that there is just something about the major architectural changes that happened with Fermi which makes it behave significantly different than other GPUs with madVR. It being able to use both CUDA decoding and madVR without any slowdown, appears to show the results of some such changes. Weren't people with other NVIDIA GPUs unable to use CUDA decoding and madVR effectively (I seem to remember reading such in this thread)?

I'll know soon enough if Fermi is unique once I'm back to my 7800GTX 512 and also have an ATI 5750 on hand.

[namaiki]

I can't because I don't have enough VRAM. (256MB) without CUDA usage is ~220MB, with CUDA it goes too high. If I resize the video window smaller, VRAM used is less and it will be smooth.
It worked fine at 1280x720 last I checked, but not at 1920x1080 which is what I usually use.


edit: Actually, I can use CUDA @ 1920x1080 if I disable Aero (uses about 40+MB of video ram), but I've become unnecessarily attached to transparency. :/
edit2: My current official drivers don't support CUDA acceleration with CoreAVC 2.0, though.

[Razoola]

Originally Posted by cyberbeing

The above settings I can now confirm give me near perfect smoothness on both Windows XP & Windows 7 (Aero Disabled). Speaking of only Windows 7, using the above settings with Aero Disabled, is literally twice as smooth as when Aero is Enabled using the settings at top.

This is what I have been saying all along... Aero is bad. It seems to me that the only thing Aero can be helpfull in is solving tearing issues for some users. It does nothing to help smooth playback with my GTX295, it does the opposite (like you say) and the stuttering it causes is not even seen by the renderer.

[ajp_anton]

Originally Posted by cyberbeing

I'm really beginning to think that there is just something about the major architectural changes that happened with Fermi which makes it behave significantly different than other GPUs with madVR. It being able to use both CUDA decoding and madVR without any slowdown, appears to show the results of some such changes. Weren't people with other NVIDIA GPUs unable to use CUDA decoding and madVR effectively (I seem to remember reading such in this thread)?

I'll know soon enough if Fermi is unique once I'm back to my 7800GTX 512 and also have an ATI 5750 on hand.

Worked fine with my integrated 9300, with "faster" resizing algorithms.

[madshi]

Originally Posted by cyberbeing

Don't ask me why, but it was using the exact same amount of CPU as Flush & Wait (Loop). I re-checked multiple times. Bug?

Don't know, have to look into that.

Originally Posted by cyberbeing

It still seems to be adding delay in the OSD stats, and much more time then 0.05ms is being wasted somewhere.

Weird. Will have to investigate that, too.

Originally Posted by Mark_A_W

I think you've nailed it.

Originally Posted by namaiki

Madshi: Could you please consider making a checkbox to enable or disable delayed frames? I'm getting a little bit of stutter for 60fps video where I wasn't before, I'm not sure what's causing it though. (it is and was dropping/delaying tons of frames, but there wasn't stutter before - may or may not be related to delayed frames, but GPU usage seems to be ever so slightly lower, but with stutter compared to before)

0.17 did show some delayed frames, too, just not "officially". I don't plan to go back to the 0.17 logic, it was faulty.

Originally Posted by Mark_A_W

any chance of a tray icon for madVR? (And madFLAC?)

Already on my to do list for a future version.

Originally Posted by mark0077

Just still has the tiny niggle when switching from windowed to fullscreen. It seems to be a visually two step process ie maximize horizontally. Then 0.2seconds pause (1 frame maybe?). Then maximize vertically.

Might be a little bit better in v0.19, but to be honest, I don't consider this a real problem at this point in time. There are so many more important things to look into first.

Originally Posted by leeperry

I've watched a few 90 mins movies(all flush settings disabled)...no dropped frames after 45/60 mins whatsoever anymore

Great!

Originally Posted by PatchWorKs

could be used in transcoding appliances too ?

No, madVR is currently a pure playback solution.

Originally Posted by leeperry

so I've run more tests w/ Space Chimps...whatever I set for the flush options doesn't seem to matter(everything set to "don't"/default/namaiki's settings), but from time to time when I seek back and forth quickly I can get a dropped frame..or can I say late/delayed? It doesn't increment in mVR's OSD.

A dropped frame after a seek is perfectly alright. Nothing to worry about at all.

Originally Posted by leeperry

The difference I see is that in <0.18, if your seeking point was missed..it was completely missed, the video was jerky until you manually re-sought. Now, very rarely, a seek can make a delayed frame occur...it quickly gets back in time and doesn't require a reseek.

Which means that the synchronized judder problem seems to be fully fixed.

Originally Posted by leeperry

also, I need more time to make sure that the jerky playback after 45/60 mins problem is gone...but so far I haven't seen it happening

Ok, let's wait a bit, let me know if you see it happen again...

Originally Posted by fps

I'm not quite sure if the following is a problem of madVR or ffdshow.
In the ffdshow tryouts thread I posted this issue:
ffdshow's libavcodec and wmv9 VC-1 decoder give me stuttering playback on every 1080p Blu-ray. The only decoder that works is the internal VC-1(ffmpeg) decoder of MPCHC.
The strange thing is with some other renderers like EVR (non CP), EVR-Sync and overlay both decoders in ffdshow work well (clsid said it's probably a renderer error).

Which splitter are you using? Does it only occur when using the MPC HC internal m2ts splitter? What happens if you use Haali's splitter? Or when you remux to MKV? My best guess right now is that it's a splitter problem, which some decoders and some renderers can work around.

Originally Posted by nevcairiel

I'm having some weird error that started just recently, not sure what changed exactly, but it was present in .17 and .18 at least, sometimes randomly before as well.

Playback just doesn't start at all anymore. MPC-HC starts up, sizes itself to the video size, and then just sits there, and after a few seconds ends up being greyed out by windows as "not responding".

Don't know what's happening there. The log look alright to me. Apart from that playback simply doesn't start. I don't know why the decoder is not sending any video frames to madVR. I'd suggest to try a different splitter or a different decoder.

Originally Posted by cyberbeing

All in all, even with the above settings, using Aero with madVR wasn't all that smooth, but the above was at least somewhat tolerable.

Interestingly, if I set After Present to Flush & Wait, my avg and max present times skyrocketed higher than my VSync interval. Could it be that madVR doesn't show the present times correctly when using Aero, without a Flush & Wait setting set for After Present? Considering madVR required Flush & Wait in order to get correct stats for After Render Steps & After Last Step, I wouldn't be surprised if that is the case here as well. Aero breaks madVR's normal present time stat recording, but Flush & Wait restores it. This makes me believe that actual Aero present times really aren't <1ms, but rather quite high and currently harm madVR present performance considerably.

Quite possible.

[madshi]

madVR 0.19 released

http://madshi.net/madVR.zip

* small timing tweak for windowed playback with high display refresh rates
* got rid of "don't render right before presentation" option
* increased backbuffer queue size to 8 (in Vista and newer OSs only)
* dropped/delayed frames stats are reset now when a new video is played
* added Aero "composition rate" information to OSD
* added "aero delayed/dropped frames" information to OSD
* added special Aero rendering path, must be activated by new option

To be honest, I'm disappointed with the special Aero rendering path. I was hoping to get a much higher performance (allowing higher scaling settings to be used) with noticeably higher reliability (less dropped/delayed frames). I was hoping that "Present" calls would never block, anymore, except if the Aero queues are full. But not so. Here's my impression of madVR's new "special Aero rendering path":

(1) slightly higher reliability, if GPU + Aero can handle the load
(2) maybe ever so slightly higher performance, but not much
(3) "Present" calls often unexpectedly block, which I don't understand
(4) there's no proper way to empty the queues, which results in artifacts when using trick play

Because of (4) the new rendering path is only an option right now, which is not even enabled by default. Please play with it and report your results. Thanks.

The new "use special Aero rendering path" option only shows effect after you've restarted your media player !!

[Razoola]

I have tried the new aero renderer path but I just cannot get smooth playback at all. I guessed this would be the case because I can't get smooth playback with aero enabled.

[nevcairiel]

Originally Posted by madshi

Don't know what's happening there. The log look alright to me. Apart from that playback simply doesn't start. I don't know why the decoder is not sending any video frames to madVR. I'd suggest to try a different splitter or a different decoder.
.

I did. Happens on any video file, so different encoders and splitters are involved anyway.
But tested all combinations on one 720p MKV just to be sure. MPC-HC internal splitter/decoder, internal splitter + CoreAVC, Haali with internal decoder, haali with CoreAVC .. i doubt its the decoder or splitter.

I'll try some other nvidia drivers, maybe that will somehow magically solve it.

[madshi]

Originally Posted by Razoola

I have tried the new aero renderer path but I just cannot get smooth playback at all. I guessed this would be the case because I can't get smooth playback with aero enabled.

Do you have a multi monitor setup? What display refresh rate do your monitors have? And which composition rate does the OSD show?

Originally Posted by nevcairiel

I did. Happens on any video file, so different encoders and splitters are involved anyway.
But tested all combinations on one 720p MKV just to be sure. MPC-HC internal splitter/decoder, internal splitter + CoreAVC, Haali with internal decoder, haali with CoreAVC .. i doubt its the decoder or splitter.

I'll try some other nvidia drivers, maybe that will somehow magically solve it.

That doesn't look like a fault of the drivers to me. According to the log madVR hasn't even tried starting to render yet, because the decoder hasn't bothered to send any video frames to madVR. The GPU drivers only start affecting things when madVR tries to start rendering.

That said, I've only seen one log. Maybe with a different splitter/decoder combination madVR does get video frames and does try to start rendering. In that case it might be a problem with the drivers, after all. I'd also suggest to update to the latest MPC HC and ffdshow versions.

[Razoola]

Originally Posted by madshi

Do you have a multi monitor setup? What display refresh rate do your monitors have? And which composition rate does the OSD show?

Yes I do... Primary has a refresh rate of 120.3hz, secondary has a refresh rate of 50hz using a test case video at 25fps. Aero rendering path is enabled.

Opening video on primary display I get....
disply rate = 120.3
areo rate 120.0

Opening on secondary display I get...
disply rate = 120.3
areo rate 120.0

Opening on primary and going full screen to secondary I get.
disply rate = 120.3
areo rate 60.0

You can see clearly that aero does not tune itself to the refresh rate of the secondary display. I have long suspected this is a limitation with Aero and the reason why both displays must be at a multiple of the video source rate to get some kind of smooth playback with aero enabled.

Just a quick update to say when I disable the aero rendering path but leave desktop compasition enabled the display rate is correctly reported at 50hz for the secondary display. As soon as the new rendering path is enabled it reports 120.3 again.

[nevcairiel]

I reinstalled MPC-HC and completly reset all its settings, and now it works again. No idea what went bananas there .. didnt even think the player could screw up like that, oh well!

[madshi]

Originally Posted by Razoola

Yes I do... Primary has a refresh rate of 120.3hz, secondary has a refresh rate of 50hz using a test case video at 25fps. Aero rendering path is enabled.

Opening video on primary display I get....
disply rate = 120.3
areo rate 120.0

Opening on secondary display I get...
disply rate = 120.3
areo rate 120.0

Opening on primary and going full screen to secondary I get.
disply rate = 120.3
areo rate 60.0

You can see clearly that aero does not tune itself to the refresh rate of the secondary display. I have long suspected this is a limitation with Aero and the reason why both displays must be at a multiple of the video source rate to get some kind of smooth playback with aero enabled.

Hmmmm... Opening the video on the first monitor and then moving it to the second is not a good idea. I don't think madVR properly handles that situation yet. Try opening the media player, but not loading the video file yet. Then move the media player to the secondary monitor and open the video there. Does that change things? If the display refresh rate OSD information in madVR shows a wrong number, then something is wrong.

Originally Posted by nevcairiel

I reinstalled MPC-HC and completly reset all its settings, and now it works again. No idea what went bananas there .. didnt even think the player could screw up like that, oh well!

Glad to hear you got it fixed.

[Razoola]

Originally Posted by madshi

Hmmmm... Opening the video on the first monitor and then moving it to the second is not a good idea. I don't think madVR properly handles that situation yet. Try opening the media player, but not loading the video file yet. Then move the media player to the secondary monitor and open the video there. Does that change things? If the display refresh rate OSD information in madVR shows a wrong number, then something is wrong.

If I do what you suggest the display rate is correct but the aero rate is reported at 60hz.

I have taken it one step further and done the above test again after first changing the primary refresh rate from 120hz to 100hz. Again the display rate is correct but the aero rate is reported at 100hz.

Im sure this is a aero limitation and not MadVR. The same problems happens with all other renderers in a multi monitor setup. Your OSD seems to confirm what I could see via judder before.

[noee]

Well, I'm resigned to the fact that Razoola is right about aero in general it seems. I have similiar results.

With both monitors @ 60Hz (playback on secondary), I get smooth playback, at least no juddering. Stats:


With primary at 60Hz and secondary at 24Hz (playback on secondary), I get a the typical nasty juddering Check out the stats and the queues and note the wrong detection of refresh rate (reclock reports it properly at 24Hz):



Playback is just an SD source in MKV.

HD2600XT, CCC10.3, Win7 x64, Aero ON, dual-mon (primary 60Hz, sec 24Hz, both 1920x1080)
HMS/FFDshow/Reclock/madVR/MPC-HC
3Dlut OFF|Spline64|Spline64|Spline36
AERO path option ON
flush|flush and wait(sleep)|don't|don't|don't