madVR - high quality video renderer (GPU assisted)

[namaiki]

information about resizing algorithms can be found here (http://forum.doom9.org/showthread.php?p=1272990#post1272990) and.. through Google.

[fps]

I'm not quite sure if the following is a problem of madVR or ffdshow.
In the ffdshow tryouts thread (http://forum.doom9.org/showthread.php?p=1407612#post1407612) 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 (http://forum.doom9.org/showthread.php?p=1407856#post1407856)).
Could somebody try some VC-1 Blu-ray and check if you have the same issue?

My specs:

(1) ATI Radeon HD 4830.
(2) Win 7/32.
(3) Aero on.
(4) 1680x1050@60Hz.
(5) Single monitor setup.
(6) Intel Core2Quad 9400s
(7) ffdshow rev 3472, MPCHC svn 2018

[pirlouy]

either there's one too much or one missing word.
No. I have tearing, just a border at bottom in 60Hz, but it's higher in 23Hz.

@namaiki: I've tried a lot of combos, without success, even what you said.

But it's not a problem, because I think there will always be people like me who have problems with window mode. Overlay mixer is enough if you don't search always more. To be honest, I don't see differences between Overlay mixer and madVR. :P
On the contrary, I see immediately tearing, so I prefer to have a not tearing renderer.

But like I know madVR is a reference, I'll try every version and tell if there are improvements in my case.

[namaiki]

Maybe try Reclock.. Would be interesting if that changes anything.

[nlnl]

No. I have tearing, just a border at bottom in 60Hz, but it's higher in 23Hz.



And why not to try AERO ON?

[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".

I created a log with the 0.18 debug version --> http://files.1f0.de/madVR-log-20100612-1732.zip
Hope the log contains anything that would help, if you need any more details, just let me know!

Spec:
NVIDIA Geforce 260 GTX (257 driver)
Win7 64
Aero on
1920x1200@60 ( Single Monitor )
Core i7 860
CoreAVC 2.0 in MPC-HC 1.3.2018

[6233638]

And why not to try AERO ON?
I don't understand why people are turning aero off for videos, it doesn't make any sense.

[pirlouy]

Arf, I don't feel like using Reclock again. It's surely a nice application, but madVR is not compatible with MPC-autochange, and I don't want to change resolution manually, even with hotkeys.

@nlnl: Aero loses V-Sync without reason (I can see that easily with browser scrolling or other app'). And it is buggy in dual screen, as explained in another thread.

[nlnl]

but madVR is not compatible with MPC-autochange, and I don't want to change resolution manually, even with hotkeys.

No problem using MPC autochange (very cool feature) +Madvr 0.18 (Vista 32, ATI 5400 + 10.5, AERO ON).

My dream is vector adaptive deinterlacing (ATI) + Madvr (50 or 59.94 hz frame rate) for music BluRays :)!

[yesgrey]

I don't understand why people are turning aero off for videos, it doesn't make any sense.
Perhaps they are not turning it off for playing the videos, but only to avoid the horrible look of the gui with aero on... ;)

[namaiki]

Perhaps they are not turning it off for playing the videos, but only to avoid the horrible look of the gui with aero on... ;)

Personal preference, but I can't stand the light blue taskbar of Aero Basic.

[namaiki]

Aero loses V-Sync without reason (I can see that easily with browser scrolling or other app'). And it is buggy in dual screen, as explained in another thread.

Have you tried on MadVR 0.18?

[Mark_A_W]

I don't understand why people are turning aero off for videos, it doesn't make any sense.


Aero doesn't work for multiple monitors.


At least, multiple monitors when the "other monitor" refresh rate is not a multiple of the video.

You get a stuttery mess.

[pirlouy]

@namaiki: madVR is not responsible of Aero losing V-Sync. Plus the fact I have to use dual screen, I definitively can't use Aero.

[namaiki]

Arf, I don't feel like using Reclock again.

It's surely a nice application, but madVR is not compatible with MPC-autochange, and I don't want to change resolution manually, even with hotkeys.

I think I'm misunderstanding something here.
1) You're not using Reclock. That is clear.
2) You write that: madVR is not compatible with MPC-autochange, and I don't want to change resolution manually, even with hotkeys.
So, 3) You're not even using MadVR?

Could you please try Reclock(default settings) + MadVR? Just check if it changes anything and then uninstall Reclock. :/

I can't even remember why I quoted as above, but have you tried MadVR 0.18?
edit: lol I remember now... dw

[pirlouy]

:D
Most often, I use Overlay mixer because I have no tearing at all. For Reclock it is useful when you're very close to V-Sync, but in my case, I play all in 60Hz now, so it's often that I'm in 3:2 pulldown and reclock won't do anything. So I prefer to disable it.

Like madVR is not compatible with MPC-autochange, I... do not use MPC-autochange. :D

But as you all ask, I'll try madVR + MPC-autochange + Aero on + reclock + single mode. It's boring only writing it. :devil:

[pirlouy]

Here is what I've noticed:

- Aero On, every config, no tearing at all

- Aero off, madVR 0.18, 24Hz: tearing (reclock on/off, mono/dual screen, whatever flush options, bilinear scaling or less powerful scaling, 720p video or 480p). I also have a little bit of tearing in 60Hz.

- madVR causes sound glitches. I don't think it's my amp, since I don't have problems with other video renderers. I've tried with several audio renderers (DS, or WASAPI from MPC-HC). These glitches are present any time when Aero on, whereas when Aero is off, glitches are present only when video is not in fullscreen. That was not the case with madVR 0.11. Weird isn't it ?!!

- when Aero is on, I have to add an audio delay of 200ms (with every renderers which don't disable Aero of course).

- MPC-HC autochange feature often confuses Aero which loses V-Sync (and then will cause major stuttering).

-MPC-HC autochange causes crashes with several renderer when using option "start in Full screen" (that's why I said madVR is not compatible, but in fact it's the opposite)

- to avoid tearing when not using Aero, in my case, I have 2 solutions at the moment: Overlay mixer renderer or EVR custom renderer from Beliyaal (with V-Sync + Alternative Sync checked).

But of course, I follow development of madVR and EVR Sync which look promising.

[Warpman]

maybe i missed it, but why can't i use this great renderer with mpc-hc 64bit?
32bit works like a charm! :thanks:

[namaiki]

maybe i missed it, but why can't i use this great renderer with mpc-hc 64bit?

32-bit software, just like ReClock.

[janos666]

maybe i missed it, but why can't i use this great renderer with mpc-hc 64bit?
32bit works like a charm! :thanks:

You can run both 32-bit and 64-bit softwares on x86_64 platforms (like today's consumer CPUs and OSs) but they can not communicate with each other.

[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?p=1407477&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]

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

Also: http://forum.doom9.org/showpost.php?p=1407477&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]

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]

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]

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.

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.

I think you've nailed it.
:)

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.

any chance of a tray icon for madVR? (And madFLAC?)
Already on my to do list for a future version.

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.

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

could be used in transcoding appliances too ?
No, madVR is currently a pure playback solution.

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.

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.

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

I'm not quite sure if the following is a problem of madVR or ffdshow.
In the ffdshow tryouts thread (http://forum.doom9.org/showthread.php?p=1407612#post1407612) 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 (http://forum.doom9.org/showthread.php?p=1407856#post1407856)).
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.

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.

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]

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]

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?

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]

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]

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.

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]

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:
http://www.pix01.com/gallery/FCECA598-D338-4EEF-A549-9FE26CEDBEFE/madVR/7076819801.jpg

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

http://www.pix01.com/gallery/FCECA598-D338-4EEF-A549-9FE26CEDBEFE/madVR/7076819800.jpg

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

[6233638]

Aero rendering path seems worse.

Render time is slightly improved by 1-2ms average, max is unchanged. Not enough to move up to spline/lanczos from bicubic.
Present time increases from 0.2ms to 0.8ms

10 minutes into a film and aero has dropped 5 frames using settings that drop/delay none with it off.

Display: 48.001, Composition: 48.000 if it matters. Shouldn't with reclock.

[namaiki]

Using the special Aero rendering path, MadVR seems to act a bit more like EVR-CP in one test I did. 29.970 fps video on ~61.81Hz screen (Aero composition rate is reported as 60Hz) without Reclock, there is no longer stuttering and the video simply jumps a few times a second, like EVR-CP.

In the situation where the framerate of the video is matched to the refresh rate with Reclock, I lol gotta wait for a family member to come home so I can do a blind test.

[madshi]

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)
If you have wrong detection of refresh rate, then you probably started video playback on the primary monitor, afterwards moving the media player to the secondary monitor. As said a few posts ago, madVR currently doesn't handle this situation well. At the time when the video is loaded, madVR should already be on the right monitor.

That said, with a composition rate of 60Hz of course you must get 3:2 judder with 24Hz content.

Aero rendering path seems worse.

Render time is slightly improved by 1-2ms average, max is unchanged. Not enough to move up to spline/lanczos from bicubic.
Present time increases from 0.2ms to 0.8ms

10 minutes into a film and aero has dropped 5 frames using settings that drop/delay none with it off.

Display: 48.001, Composition: 48.000 if it matters. Shouldn't with reclock.
Please try to lower the flush settings. The new special Aero rendering path gets along with lower flush settings. That might help improve things.

[Hypernova]

With the new Aero rendering path, it play smooth for a while and then start stuttering (or maybe judder, I'm not sure about the the difference). I didn't test this with all the flushing combinations yet, but it seems like the more it flush, the longer it could hold out before start stuttering.

I have the same wrong detection of refresh rate as noee said. I made sure MPC-HC is fullscreen on the secondary monitor before open the file.

Info: (changed from all my previous report, just in case you keep track)
(1) ATi 5770
(2) Windows Server 2008 R2
(3) Aero on
(4) 2560x1600/60Hz + 1920x1080/24p
(5) Dual monitor setup. 1st on DisplayPort, 2nd on HDMI

Due to the fact that I got to swap my 3870 with my friend's 5770 for this summer, I couldn't comment on loop vs. sleep after 0.18 since for single monitor setup, there is no need for any flush at all with 5770. I would put my vote on keeping the loop option though.

[madshi]

@Hypernova, do you get smooth playback when deactivating the new Aero rendering path? And which exact display rate / composition rate are you getting? Do the numbers change if you disable the new rendering path?

[6233638]

Please try to lower the flush settings. The new special Aero rendering path gets along with lower flush settings. That might help improve things.Well, the stats got worse when I did that. Flush, Sleep, Flush, Don't is still best by the numbers.

I did not leave it running to see if it still dropped frames though.
Should the numbers be accurate like this?

[namaiki]

Stop looking at MadVR's OSD. With it enabled, even on my 9600M GT, there is a slight performance hit. Keep it off when looking for smoothness of video.

[Hypernova]

@Hypernova, do you get smooth playback when deactivating the new Aero rendering path?

No. It's stuttering like what people who choose not to use Aero. It's actually got better with a right combination of flushing, but it's still stuttering. I posted in a little bit more detail in another thread:

If you play a smaller file in MPC-HC so that the seeking cursor is moving quite fast, you would see that when it stutter, the seeking cursor is also stutter with the video! I certainly think it's Aero, but I like Aero and madVR, so I have to find some other way instead of disable it.

In my case, Sync Renderer cannot solve this. However, exclusive mode get rid of this problem entirely! So I have high hope when madshi eventually implement it in madVR.

Edit: I should have mention that this is all with dual monitor with 60/24. With single setup I don't experience this issue. Also, it looks like using DVI on primary cause less problem than using DisplayPort. It's not entirely smooth, but less stuttering. 2nd is on HDMI.

That's what I meant to say when I read your post, but as I was trying to get the number, I found something different:

1. With new Aero path: It's stuttering as I said in previous post, but the seekbar cursor seems to be perfectly fine, unlike without new aero path. The best flushing combination for this seems to be some flush for all 4, probably with loop.

2. Without new Aero path: the video and seekbar cursor is stuttering so badly. But, here's the strange thing, if I open OSD, then it disappear! I can even disable OSD afterward. The cursor seems to be smooth, and the video as well. It's not perfectly smooth, but I think with a right combination of flushing (I'm on flush/sleep/no/no while testing) this may go away.

And which exact display rate / composition rate are you getting?

59.85797Hz/60.000Hz

Do the numbers change if you disable the new rendering path?

Yes. It's 24.9992Hz/60.000Hz

At least for me, I think you're actually close to nail down the Windowed Mode with Aero on. Keep up the good work!

[Dhruv]

Wow, I am blown away with the recent releases.. this works like a charm under my Optimus laptop setup after setting MPC-HC to use the "High performance card" within the Nvidia settings :D

Win7 x64, Core i5-430M, 1GB GT 325M, 257.15 Beta Drivers (though looks like new ones came out today!), CoreAVC (CUDA Enabled), 3dLut ticked.

Outputting 1080p MKV's to 1920x1080 via HDMI, using MPC's auto-refresh rate changer to change between 60hz, 50hz, 24p. Looks absolutely amazing and plays butter smooth using any of the scaling methods (<40% GPU usage according to GPU-Z).

I bought this laptop a few months ago and have been waiting for the day I can use MadVR.. with 0.18 and later + the new 257x drivers I am finally able to do so! (And yes, this is my first post after registering 5 years ago ;))

[noee]

...At the time when the video is loaded, madVR should already be on the right monitor.

Yes, I have MPC-HC set up to always run on my secondary. With Aero OFF, everything works like a champ and refresh rate detection is correct.