madVR - high quality video renderer (GPU assisted)

[Jong]

I still don't think it would be a good idea. E.g. with Aero, the time you present has to be chosen cleverly: If you present too late, then even although it's still before the VSync, the frame will still not be shown, because Aero still needs to do some internal rendering on top of the video playback rendering. Furthermore, and more importantly: For Aero and fullscreen exclusive mode, I plan to make use of the OS internal queues. Which means that I'll present 5-8 frames in advance, by telling the OS when I want the frames to be presented and for how long. Doing so will make sure that even if rendering/presentation is interrupted, playback will still run smoothly, because at least the fullscreen exclusive mode OS queue is managed by hardware interrupts. So if I prerender 8 frames and send them to the OS queue, rendering/presentation would have to be interrupted for 8 * 40ms, before the interruption would result in noticeable stutter. If I do as you suggested, only one frame is in the OS queue at any time. So if the PC gets busy doing whatever for 40ms and doesn't allow me to render/present during that busy period, playback will stutter.All that sounds great!

However, there is a very good chance the Reclock method should work too. I guess it depends on how much of your valuable time it would take to offer the option.

I admit I have not done extensive testing with Aero, but certainly in exclusive mode Reclock should be able to set the point of presentation very dependably. With EVR sync, start of presentation is normally fixed +/-1.5ms. On XP occasional spikes due to delayed presentation of say 7ms are seen, but if av. point of presentation is set ~17ms for 50Hz and 12ms for 60Hz it is very rare, on a well configured PC, this actually causes a drop (mostly not even one per movie). On W7, with its improved scheduling even these spikes are not seen. So I'd say even if Aero needs more margin it is still likely to be fine. Reclock vsync control is really very reliable in a multitude of players including PDVD and TMT when using an overlay surface, as they do for Blu-ray playback. Here you do not even have exclusive mode to help you.

Offering this advanced option would get around the possible current synchronised judder problem madVR may have, but more importantly it would let people like me who use Reclock vsync correction in PDVD/TMT for Blu-ray disc playback use it also for madVR. Alternatively, we have to use a .reg file to change Reclock settings before using each player to manually turn on or off vsync correction. But I understand it does depend on how hard this would be to implement!

[pankov]

... In fullscreen exclusive mode all of these problems should go away. Maybe also with Aero, if I write a specific Aero solution...

madshi,
please, do write an Aero solution, and if possible do it before the exclusive one.
I'm begging you for this because the player that I use (ZoomPlayer) doesn't work good in exclusive (no OSD) ... and I think some other players will be affected in the same way too.

[namaiki]

Lanczos *is* default. For Luma, that is.

Sorry, I mean for upscaling the defaults are very soft.

Thing is after you scale up a certain amount using the default scaler settings, blocks can be seen, but that of course depends on the content as well.

default: http://img34.imageshack.us/img34/2494/defa43t.png
something else: http://img263.imageshack.us/img263/3039/bicubic60.png

[iSunrise]

FWIW. the anti-tearing fix is always on in 0.12, the checkbox in the settings doesn't have any effect in 0.12.
That explains why there´s absolute no difference on my side when enabling/disabling it. Thanks for pointing that out. Since I have perfectly smooth playback either with the fix on or off. I can also enable/disable the 3DLUT (I have it disabled right now, because my CG243W takes care of that) without anything that is affecting smoothness.

oh ok, well I didn't try it on 0.12 as the associated tearing was very annoying in 0.11 anyway.

I'm only telling you what I see, and I can confirm that seeking with Reclock in 0.12 is still a major hit or miss, as it was in 0.11
When I seek with 0.12 I have a very responsive KMP and it´s smooth as well, since I got no dropped frames . The only thing that is still slower with madVR 0.12 is switching from windowed-playback to fullscreen and back if I compare it with Haali or EVR C/A (like it´s called in KMP). With madVR I can actually see that the aspect ration correction takes place when going into fullscreen, which is not the case of either EVR or Haali, because the picture already is there too fast to detect it.

Did you already try what 6233638 suggested? Does that make any difference whatsoever? Because he is also using reclock and has smooth playback with 0.12.

@madshi:
I´m not sure if this is helpful but from experience (having had a CRT until recently before I got the LCD) there is one thing (consider it rather subjective, since 0.12 wasn´t released when I still had my CRT) that I cam across, too. With 0.11 I _never_ could get smooth playback on my CRT on any files, even when playing around a lot with my refresh rates. madVR dropped frames constantly. I have tested 0.11 again with my LCD and it seems that it behaves completely different than my CRT did (I had it connected via BNC, not D-SUB) re: a stable display refresh rate. Because when I´m looking at madVR´s OSD my LCD only ever fluctuates at the very last 2 digits while my CRT had a hard time of keeping it´s refresh rate constant at all, it fluctuated like crazy. 0.11 even sometimes reported my display refresh completely wrong, at least that´s what the OSD showed, so I´m under the assumption that madVR could not calculate some things that it needs to display a smooth image. Just wanted to share that with you, not sure if that helps anything.

[Grmpf]

FWIW. the anti-tearing fix is always on in 0.12, the checkbox in the settings doesn't have any effect in 0.12.

Ok, thats the reason why i get always the same results, with or without the checkbox enabled ;-)

Btw. here a picture with madVR stats from my system - tearing at 23.976hz. Its *always* in the same postion (i marked it red, because i can not screenshot the tearing), no matter if i restart the player, system, use pause, or whatsoever - madVR tears at this position for me and no where else. My system is a Q9550 + ATi 4770, on WinXP SP3, output on a JVC DLA-HD100 (RS2 named in the US) - btw my timings (with powerstrip) are very very tight - i get not a single Repeat/Drop (apart from the starting ones) while bitstreaming AC3/dts in 13+ hours constant playing. With other renderers i can adjust the vsync with reclock to not tear, with madVR its not possible, and after reading your conversation with jong i understand why reclock is not working the way i am used to be.

I cross my fingers that the exclusive mode will fix it, it is a it strange that the tearing is always at the same position or ?

http://img88.imageshack.us/img88/2092/madvrtest01.th.jpg (http://img88.imageshack.us/i/madvrtest01.jpg/)

[TinTime]

I get exactly the same tearing as you at 23/24Hz with 0.12. I'm also on XP SP3 with an Nvidia 8600GT.

This seems to have been present for me since 0.10. Versions 0.9 and earlier were ok. If there was tearing then it was when play was started and a quick pause / play would fix it, similar to when I use VMR-9.

[Razoola]

I don't understand why people think aero is a good thing. In my experiance aero (on win7 x64) is only good in a single display set up, as soon as you have two active displays everything goes wrong with aero enabled.

I have found that aero requires refresh rates of both displays to be good multiples of each other, if not you'll get judder caused by aero thats not seen by the video renderer. For example if you play a 25fps media on a secondary display with 50hz refresh rate you will not get smooth playback unless the primary display also has a refresh rate at a multiple of 25hz. I have this problem with all renderers tried (haali,vmr9, madvr).

[leeperry]

When I seek with 0.12 I have a very responsive KMP and it´s smooth as well, since I got no dropped frames.
with Reclock in 24/48/96Hz on XP SP3? the issue seems to be that Reclock fights for VSYNC control over mVR :o
Did you already try what 6233638 suggested? Does that make any difference whatsoever? Because he is also using reclock and has smooth playback with 0.12
I guess I missed that...what was it?

[6233638]

I guess I missed that...what was it?This is what works for me:
lee, with reclock, disable its V-Sync correction and leave madVR's tearing correction enabled. Windows 7, Aero on - disabling aero usually causes tearing, leave it on.
ffdshow decoding: ffmpeg-mt for h.264, libavcodec for mpeg2 and libavcodec for vc-1. Make sure you use libavcodec for vc-1. While the wmv9 decoder uses less cpu and benchmarks better, it is not possible to get smooth playback in MPC-HC + madVR from my testing.
Reclock outputting WASAPI, upsampling to 32/192 (best sinc, custom resampler) all v-sync correction off.
Haali media splitter. I'm using one from 2009 as the latest don't work with a lot of Bluray m2ts files. (either no audio or video)
MPC-HC for playback. KMP looks a lot nicer but I had problems playing back some discs/files. MPC-HC works perfectly.
This setup gets 100% smooth playback with perfect lip-sync and no dropped/skipped frames. Reclock is still used for upsampling, slowing down PAL and making sure audio is in sync with video.

[leeperry]

oh ok, thanks for the repeat! but you got Aero watching your back, it'd be more or less like running on XP in D3D exclusive mode I think...it forces Reclock and mVR to play nice as I understand it.

[makakam]

To me playback is smooth but still I can see that there are at least 10 frames dropped all the time. What can be done to prevent it? I am using madVr with mpc hc, core avc as a decoder, reclock and windows seven 32-bit, aero on.

[Razoola]

I think given that madshi says he may have found a potential bug in his code that is related to which vsync frame video frames should be presented that people with judder problems should wait until the next release. I myself await it for the fix to allow madVR to work on some nvidia gfx cards with their latest drivers.

[janos666]

Nice improvements, it is much more stable now. It won't crash during fast stop/start/framestep/jump actions anymore. It works perfectly on my desktop PC (HD5850 and Q6600@3,6Ghz).

And it also works with new Forceware drivers. But I can not use it on my laptop so far. I think a mobile 8600GT with a C2D@2.0Ghz won't be enough.
I tried to apply all of the four performance options and set all resize modes to "narest neighbourhood" and overclock the VGA (from 400/800/400) to 600/1500/440 but the result is always a slide show.
It seems like the problem is the CPU. I have constant 50% CPU load during this slide show. There was someone here who could use this renderer with a desktop 8600GT which would imply that I really have a CPU limit. (But he could do it with uncompatible 19x.xx forceware drivers, so he has to be a blessed man or something like that anyway... :DDD)
It is weird because I have nearly the same CPU loads with this renderer on my desktop PC as I have with other renderers (like EVR). FFDShow is multi-threaded, I can produce 100% CPU load with a Blu-Ray sample and EVR. So, I do not understand this constant 50% CPU load thing... My be I still have some bugs with this renderer and Geforce VGAs. (I am using the latest 197.75 now)

[peter0328]

Is .12 supposed to work on GTX 295 Quad SLI with the 196.21 drivers? I'd like to know this before I start trying to get it to work since it would be pointless if if hasn't fixed the driver bug lol.

[Razoola]

Is .12 supposed to work on GTX 295 Quad SLI with the 196.21 drivers? I'd like to know this before I start trying to get it to work since it would be pointless if if hasn't fixed the driver bug lol.

It does not work with my gtx295, you have to go back to 191.07. I ran madshis debug build however and he says the issue will be fixed in the next release. I suggest you await that.

[nevcairiel]

I get frame drops when i switch between window/fullscreen in MPC-HC, so thats kinda tainting the nice "0 frame drops" display, but other then that, its working smoothly without any frame drops at all. Good job :)

[Neeto]

Looking at a new card.
Is a GeForce 210 GPU with 512MB DDR2 at 600MHz enough for madVR with heavy duty options?

Thanks Neeto

[namaiki]

You might need something twice as powerful depending on your scaler settings.

[Neeto]

So something like a 220 GPU with these setting?

Luma Upscaling: Spline36
Luma Downscaling: Spline64
Chroma Resampling: Mitchell-Netravali

[namaiki]

I dunno, but also what resolution source and screen?

My 9600M GT can do the above settings (doubling the resolution of 1280x720 video) in 21ms (say avg frame time is ~42ms).

The 210 is below the 9600M GT and the 220 is just above.

[Neeto]

I'll be running 1920x1080 resolution to Samsung 46" B550 LCD

[madshi]

I don't know why when I use Madvr there's so much cpu usage ?

When I use Madvr with an h.264 file I have a cpu occupation of about 70%
While with haali renderer I have a cpu occupation of 30%

Why Madvr causes so much cpu usage ? He's supposed to do all the work with my graphic card ?

The result is that I must overclock my little pentium dual core (2ghz) to about 2.5ghz to play the video without stutters.

The other point is simply the stability when I start my video. Sometimes media player classic doesn't respond. Sometimes It does.... I've got a gt240 and I'm running seven.
These problems may all be caused by a problem between madVR and the current NVidia driver. The next madVR may fix all that (or not).

However, there is a very good chance the Reclock method should work too. I guess it depends on how much of your valuable time it would take to offer the option.
It might work, too, but only in exclusive mode or in Aero. Furthermore I don't expect it to work *better* than the madVR method (at least after all madVR bugs are fixed). So I don't really see any benefit of offering a Reclock specific rendering mode.

Offering this advanced option would get around the possible current synchronised judder problem madVR may have, but more importantly it would let people like me who use Reclock vsync correction in PDVD/TMT for Blu-ray disc playback use it also for madVR. Alternatively, we have to use a .reg file to change Reclock settings before using each player to manually turn on or off vsync correction.
Does Reclock's vsync correction cause problems with madVR? I don't think it will cause problems, when I implement special support for Aero + exclusive mode.

please, do write an Aero solution, and if possible do it before the exclusive one.
You want Aero first. Others want exclusive mode first.

Sorry, I mean for upscaling the defaults are very soft.
Default for (luma) upscaling is Lanczos! Which is the sharpest scaler madVR currently offers.

I´m not sure if this is helpful but from experience (having had a CRT until recently before I got the LCD) there is one thing (consider it rather subjective, since 0.12 wasn´t released when I still had my CRT) that I cam across, too. With 0.11 I _never_ could get smooth playback on my CRT on any files, even when playing around a lot with my refresh rates. madVR dropped frames constantly. I have tested 0.11 again with my LCD and it seems that it behaves completely different than my CRT did (I had it connected via BNC, not D-SUB) re: a stable display refresh rate. Because when I´m looking at madVR´s OSD my LCD only ever fluctuates at the very last 2 digits while my CRT had a hard time of keeping it´s refresh rate constant at all, it fluctuated like crazy. 0.11 even sometimes reported my display refresh completely wrong, at least that´s what the OSD showed, so I´m under the assumption that madVR could not calculate some things that it needs to display a smooth image. Just wanted to share that with you, not sure if that helps anything.
A madVR 0.11 problem report does not help me.

I cross my fingers that the exclusive mode will fix it
I've never seen tearing in exclusive mode yet. So yes, exclusive mode should definitely fix it.

I don't understand why people think aero is a good thing. In my experiance aero (on win7 x64) is only good in a single display set up, as soon as you have two active displays everything goes wrong with aero enabled.

I have found that aero requires refresh rates of both displays to be good multiples of each other, if not you'll get judder caused by aero thats not seen by the video renderer. For example if you play a 25fps media on a secondary display with 50hz refresh rate you will not get smooth playback unless the primary display also has a refresh rate at a multiple of 25hz. I have this problem with all renderers tried (haali,vmr9, madvr).
May be a problem with Aero. Nobody will stop you from disabling it. However, people with a dedicated HTPC (single display set up) should not have this problem. For them Aero may be a good solution.

To me playback is smooth but still I can see that there are at least 10 frames dropped all the time.
Does the number increase during playback? It's relatively normal that at the beginning of playback there are some dropped frames because the queues are all empty. As long as there are no further dropped frames after 10 seconds of playback time, I wouldn't worry about it.

And it also works with new Forceware drivers. But I can not use it on my laptop so far. I think a mobile 8600GT with a C2D@2.0Ghz won't be enough.
I don't know if the 8600GT will be fast enough or not. But the problem may also be driver related. Maybe the problem will go away with the next madVR version.

My 9600M GT can do the above settings (doubling the resolution of 1280x720 video) in 21ms (say avg frame time is ~42ms).

The 210 is below the 9600M GT and the 220 is just above.
The 220 may be fast enough for current madVR processing. But there's one thing to keep in mind: madVR only has basic processing capabilities right now. There's a very high probability that future madVR versions will add new processing options which will require much more processing power. Because of that my recommendation for a new GPU is this:

Get the fastest GPU you can afford and which fits your thermal/space/noise requirements. The faster, the better. That is, if you want to prepare for potential future madVR algorithms.

[pankov]

You want Aero first. Others want exclusive mode first.
I'm not trying to argue with you - I value your work very much, I simply can't see the need / benefit of exclusive mode and it's limitations if we have a fully working "non-exclusive" mode. And also having in mind that Aero is the default mode for the new and I believe future Windows versions I think it'll have much wider acceptance than Exclusive mode ... also it doesn't require any changes in the software player (OSD / notifications).
That's just my $0.02.

[cyberbeing]

A GT 220 may have trouble scaling higher resolution 30fps content and definitely 60fps content quick enough with those settings. If you never watch anything except 24fps content, this may be a non-issue.

Another thing to keep in mind is that using a higher tiered scaler like Spline or Lanczos for Chroma Resampling would most likely absolutely kill that GPU when scaling content. Every other Chroma Resampler except Spline and Lanczos should be fine, so this may be a non-issue as well.

Something like a GeForce GT 240 (385 GFLOPS, 54.4GB/s GDDR5) or even better a 9800 GT (504 GFLOPS, 57.6GB/s GDDR3) would give you a lot more headroom.

Sorry, I mean for upscaling the defaults are very soft.Default for (luma) upscaling is Lanczos! Which is the sharpest scaler madVR currently offers.

This is incorrect, at least in any released version of madVR. The defaults only use Lanczos4 for luma downscaling. The very soft SoftCubic50 is used for luma upscaling.

The defaults are:
luma upsampler=SoftCubic50
luma downsampler=Lanczos4
chroma resampler=SoftCubic100

[Jong]

Does Reclock's vsync correction cause problems with madVR? I don't think it will cause problems, when I implement special support for Aero + exclusive mode.Well I'd hate to be definitive about something that we haven't seen yet. :)

But for sure it will cause problems if Reclock is unable to move the point "present()" returns by altering the reference clock. If madVR pins the start of presentation to a specific spot in the frame cycle, hence, with Aero or exclusive mode, average end of presentation is also fixed, there will be a serious problem if the Reclock target range does not coincide with the position madVR defines. Then, Reclock will try to bring end of presentation back into line by running the clock a little too fast or slow, but because madVR keeps "end of presentation" pinned Reclock will never stop and "rolling sync occurs" where there is a burst of judder every 20-60 secs, approx (frame rate and refresh rates not quite exact multiples of each other).

In principle it is possible to set madVR/Reclock so they both agree on the desired position of "end presentation". Then Reclock will turn off its vsync correction and all will be good. But that depends on madVR being able to control the av. end of presentation tightly enough that it always stays inside of the Reclock target. The MediaPortal guys felt that would be very difficult to achieve with their EVR CP renderer. Even if it were possible, if the madVR position is fixed and not compatible with that required for Reclock in other players (eg. TMT or PDVD) the user would still need to write to the registry to move the target before and after using madVR. :(

[madshi]

I'm not trying to argue with you - I value your work very much, I simply can't see the need / benefit of exclusive mode and it's limitations if we have a fully working "non-exclusive" mode. And also having in mind that Aero is the default mode for the new and I believe future Windows versions I think it'll have much wider acceptance than Exclusive mode ... also it doesn't require any changes in the software player (OSD / notifications).
Exclusive mode is the ultimate playback solution. It will always be better than Aero. Here's a list of key advantages of exclusive mode over Aero:

(1) the renderer has full control over everything
(2) DeepColor can be used
(3) probably necessary for 3D playback
(4) no additional GPU load caused by Aero
(5) works in all OSs, while Aero doesn't work in XP
(6) no problem with multi display setup (see Razoola's post)

This is incorrect, at least in any released version of madVR. The defaults only use Lanczos4 for luma downscaling. The very soft SoftCubic50 is used for luma upscaling.
That's a bug, then. SoftCubic50 was not intended to be used as Luma upscaling default...

But for sure it will cause problems if Reclock is unable to move the point "present()" returns by altering the reference clock.
I don't see how Reclock could technically move the Present() return, at least when measured in system time. The Present() call returns after the next VSync. Are you saying that Reclock changes the (system) time when the VSync occurs? The only way to do that would be by changing the graphics mode timings (e.g. GPU pixel clock), as far as I can see, and I'm quite sure that Reclock is not doing that. Reclock is definitely able to do violence to the reference clock time. But such a change will only affect audio, not video, as far as I can see. I don't see what madVR would have to do with that.

If madVR pins the start of presentation to a specific spot in the frame cycle, hence, with Aero or exclusive mode, average end of presentation is also fixed there will be a serious problem if the Reclock target range does not coincide with the position madVR defines. Then, Reclock will try to bring end of presentation back into line by running the clock a little too fast or slow, but because madVR keeps "end of presentation" pinned
Again: madVR has no control whatsoever over the "end of presention". This is controlled by Direct3D, respectively in exclusive mode by the VSync hardware interrupt. Please note that even in exclusive mode Present() will block, when all backbuffers are filled. If the queues are full (which should be the case), that means that virtually every Present() call will block, in exclusive mode. And the block is released by the VSync hardware interrupt. Present() will not block only if there are unused backbuffers. Which is not the normal situation, if all queues are full.

Reclock will never stop and "rolling sync occurs" where there is a burst of judder every 20-60 secs (approx).
I don't really understand how madVR would cause Reclock any trouble, technically.

@Jong, I think the key problem is that I still don't understand how Reclock and madVR affect each other. Sure, if Reclock modifies the reference clock, madVR may schedule different frames for different VSync events. That I understand. But I just don't see how Reclock would have any effect on the hardware VSync interrupt. And as a result I don't see how madVR could cause any trouble because in the end madVR relies on Direct3D and in exclusive mode Direct3D relies on the VSync hardware interrupt. If you can explain to me why madVR could make problems to Reclock, and how Reclock can change the end of presentation (in *system time*), then maybe we can make a step forward... :)

[Razoola]

May be a problem with Aero. Nobody will stop you from disabling it. However, people with a dedicated HTPC (single display set up) should not have this problem. For them Aero may be a good solution.


Yes its certinally an Aero issue and not something caused by the renderer. I currently always disable Aero as it most instances it solves my judder issues. I use the MPC-HC disable desktop composition but this option is not available when using madVR. Is it possible you can add an option into madVR to disable Aero while madVR is doing its thing?

[ajp_anton]

http://web.tiscali.it/djsolidsnake86/video.mp4

if anyone want try madvr with this video, there is a very strange problem

I get a green line at the top with MPC-HC's decoder.
With CoreAVC, MPC-HC simply crashes.
With ffdshow it works fine.

[leeperry]

I don't really see any benefit of offering a Reclock specific rendering mode.
mVR works like a charm w/ Relock if you disable the tearing fix in 0.11...but then you do get occasional tearing :o

It is my understanding that Overlay works so well with Reclock because it's more of a "passive" VR than anything else..and to many ppl Reclock is mandatory to get audio adaptation and perfectly smooth video. I realize Reclock is just a "dirty hack"(hence Slysoft not selling it, being impossible to technically support) but mVR looks so close to offer proper compatibility...FWIW, Beliyaal's EVR CP seems to work really really well.

One thing that's really weird to me is that you tell me that mVR knows exactly the VSYNC position at any given time, yet when I seek sometimes it works fine for 15 mins then it starts dropping frames...it is my understanding that Reclock pushes its tight timings assuming that the VR caught the fliptime perfectly, but that mVR simply did not.

I believe running Aero would fix all my problems altogether(as Aero seems to enforce VSYNC control on a permanent basis...very noticeable with HR's jitter OSD), too bad I like my XP box so much :devil:

[flanger216]

So something like a 220 GPU with these setting?

Luma Upscaling: Spline36
Luma Downscaling: Spline64
Chroma Resampling: Mitchell-Netravali

My GT220 can handle those settings resizing to 1920x1080 @ 24fps. However, 30fps is threshold, and 60fps is nowhere close to usable. Not too many 60p sources around, but of course I come across 30i all the time, and I'm SOL for using a framerate-doubling deinterlacer.

So... probably want something a little faster.

[Jong]

I don't see how Reclock could technically move the Present() return, at least when measured in system time. The Present() call returns after the next VSync. Are you saying that Reclock changes the (system) time when the VSync occurs? The only way to do that would be by changing the graphics mode timings (e.g. GPU pixel clock), as far as I can see, and I'm quite sure that Reclock is not doing that. Reclock is definitely able to do violence to the reference clock time. But such a change will only affect audio, not video, as far as I can see. I don't see what madVR would have to do with that.


Again: madVR has no control whatsoever over the "end of presention". This is controlled by Direct3D, respectively in exclusive mode by the VSync hardware interrupt. Please note that even in exclusive mode Present() will block, when all backbuffers are filled. If the queues are full (which should be the case), that means that virtually every Present() call will block, in exclusive mode. And the block is released by the VSync hardware interrupt. Present() will not block only if there are unused backbuffers. Which is not the normal situation, if all queues are full.


I don't really understand how madVR would cause Reclock any trouble, technically.

@Jong, I think the key problem is that I still don't understand how Reclock and madVR affect each other. Sure, if Reclock modifies the reference clock, madVR may schedule different frames for different VSync events. That I understand. But I just don't see how Reclock would have any effect on the hardware VSync interrupt. And as a result I don't see how madVR could cause any trouble because in the end madVR relies on Direct3D and in exclusive mode Direct3D relies on the VSync hardware interrupt. If you can explain to me why madVR could make problems to Reclock, and how Reclock can change the end of presentation (in *system time*), then maybe we can make a step forward... :)The way it works in practice is this:

I have yet to see a VMR9 or EVR renderers using exclusive mode or Aero, or a renderer using an overlay surface that in practice causes "blocking". For any given renderer/settings average "End present" follows a fixed duration, depending on workload, after the present() call.

By default all such renderers appear to do as I suggested a few days ago. The first frame appears ASAP after it is 'ready' and frames follow an appropriate period later, with no regard to vsync.

As a consequence of both the above "end present" also bears no regard to vsync and, without help, all such renderers are vulnerable to synchronised judder if using a front and back buffer.

By varying the reference clock ever so slightly (say 0.1%, actually the adjustment is greater the further from the target the current measured position is) Reclock is able to move the point frames are ready/due, hence "Present()", hence the point this returns. Once the measured position is inside the Reclock target correction is turned off and the frame rate returns to normal.

If average "end of presentation", i.e. the point "Present()" returns, is pinned to a particular scanline then Reclock is unable to move it, keeps running its clock slightly too fast or slow for the refresh rate , so periodically (say 20-60 secs, depending on the adjustment) a frame has to be dropped or repeated. Often things are even worse than this sounds - because the frame rate is so near to the "compatible rate" it takes a while for the frame to move through the "danger zone" and you get a few seconds of "synchronised judder" on each cycle.

Examples of when average "end of presentation" are pinned are:

1. VMR/EVR in windowed mode, when it is pinned to just after vsync.
2. Custom renderers in Aero or exclusive mode that themselves dictate the scanline for the "Present()" call, i.e renderers with their own "anti-judder" code. As average "end present" follows a fixed duration after this, it is also effectively pinned to a specific scanline.

I am expecting madVR will behave as in case 2 above. I.e. it will seek to present each frame at a particular point in the cycle, to avoid judder and ensure presentation is complete before the next vsync. Consequently Reclock will not be able to move this position by speeding up the reference clock - if the clock is running a little too fast madVR will simply add a slightly bigger offset to each frame in order to present at its "ideal position" until the needed offset grows to bigger than a single frame at which time it will, presumably, drop that frame and move on to the next, i.e. judder.

I should say that we are assuming that what Reclock is able to infer is actually the time the "Present()" call returns. Unfortunately we do not know this for a fact. However, what is clear is that in Windowed mode the "vsync target" Reclock measures is pinned in hardware to just after vsync. It is clear that it is hard-pinned because there is almost no spread - just a single line marking its position, just below the top of the screen. However, in exclusive mode or when using Aero or overlay this measured position is random after each seek, unless Reclock vsync correction is enabled or the renderer itself is positioning "Present()", and has a spead that indicates it is software scheduled.

[mark0077]

Hi madshi,

I didn't notice any stutters lastnight watching another blu-ray, this time with reclock vsync disabled. Seems it was having reclock vsync enabled, along with madVR caused the problem with the odd stutter here and there.
The green lines on some blu-ray movies, seem to be caused by the internal mpc-hc mpeg4 decoder. I'll try to post this in the mpc thread.

One more question for you guys, should madVR, or evr-cp or any renderer for that matter, when thinking about audio / video sync, consider the 1 frame delay incurred when having aero enabled. Is this something an audio renderer might have to do, or is it something thats handled automatically by Windows? I just imagine (length of 1 video frame)ms delay would need to be added to audio, when Aero is enabled to get audio and video perfectly in sync.

Mark

[cyberbeing]

That's a bug, then. SoftCubic50 was not intended to be used as Luma upscaling default...

That was a bug all this time? I thought you said way back (madVR 0.4) that you were using SoftCubic since it had almost no ringing, haloing, and aliasing. You didn't think the softness was an issue because you could always sharpen via post-processing or on your TV. Something along those lines.

For reference:
madVR 0.3 Defaults: Catmull-Rom for Everything
madVR 0.4 Defaults: SoftCubic50 for Everything
madVR 0.6 through 0.9 Defaults: Luma Up/Down SoftCubic50 | Chroma Up/Down SoftCubic100
madVR 0.10 through 0.12 Defaults: Luma Up SoftCubic50| Luma Down Lanczos4 | Chroma Up/Down Softcubic100.

[chuuey]

tried this on my 9400m, still doesn't work, coreavc cuda on/off, latest mpc, the player and filters load, but after that it hangs, i can alt-tab out and the video will eventually start, but will stutter pretty bad, one time i managed to enter full screen and get a few minutes without issues but i tried with another movie and failed, used windows xp, back to 0.09 again ;) latest nvidia drivers

[madshi]

Is it possible you can add an option into madVR to disable Aero while madVR is doing its thing?
It is possible. But will I do that? I don't know. Let me first create an Aero specific rendering path. And then let's check how well it works and if it still makes sense at all to disable Aero.

I didn't notice any stutters lastnight watching another blu-ray, this time with reclock vsync disabled. Seems it was having reclock vsync enabled, along with madVR caused the problem with the odd stutter here and there.
Ah, that's interesting.

One more question for you guys, should madVR, or evr-cp or any renderer for that matter, when thinking about audio / video sync, consider the 1 frame delay incurred when having aero enabled. Is this something an audio renderer might have to do, or is it something thats handled automatically by Windows? I just imagine (length of 1 video frame)ms delay would need to be added to audio, when Aero is enabled to get audio and video perfectly in sync.
I'm not sure about this. Does Microsoft say somewhere that there is exactly one frame delay? I thought that there would be a delay only if the renderer presents too late. Not sure, though...

I have yet to see a VMR9 or EVR renderers using exclusive mode or Aero, or a renderer using an overlay surface that in practice causes "blocking". For any given renderer/settings average "End present" follows a fixed duration, depending on workload, after the present() call.
Strange. In that case those renderers are not well written, IMHO. Because the optimal way to use exclusive mode is to render as fast as you can and let the VSync hardware interrupt take control. At least that's how games do it.

By default all such renderers appear to do as I suggested a few days ago. The first frame appears ASAP after it is 'ready' and frames follow an appropriate period later, with no regard to vsync.

As a consequence of both the above "end present" also bears no regard to vsync and, without help, all such renderers are vulnerable to synchronised judder if using a front and back buffer.

By varying the reference clock ever so slightly (say 0.1%, actually the adjustment is greater the further from the target the current measured position is) Reclock is able to move the point frames are ready/due, hence "Present()", hence the point this returns. Once the measured position is inside the Reclock target correction is turned off and the frame rate returns to normal.

If average "end of presentation", i.e. the point "Present()" returns, is pinned to a particular scanline then Reclock is unable to move it, keeps running its clock slightly too fast or slow for the refresh rate , so periodically (say 20-60 secs, depending on the adjustment) a frame has to be dropped or repeated. Often things are even worse than this sounds - because the frame rate is so near to the "compatible rate" it takes a while for the frame to move through the "danger zone" and you get a few seconds of "synchronised judder" on each cycle.

Examples of when average "end of presentation" are pinned are:

1. VMR/EVR in windowed mode, when it is pinned to just after vsync.
2. Custom renderers in Aero or exclusive mode that themselves dictate the scanline for the "Present()" call, i.e renderers with their own "anti-judder" code. As average "end present" follows a fixed duration after this, it is also effectively pinned to a specific scanline.

I am expecting madVR will behave as in case 2 above. I.e. it will seek to present each frame at a particular point in the cycle, to avoid judder and ensure presentation is complete before the next vsync. Consequently Reclock will not be able to move this position by speeding up the reference clock - if the clock is running a little too fast madVR will simply add a slightly bigger offset to each frame in order to present at its "ideal position" until the needed offset grows to bigger than a single frame at which time it will, presumably, drop that frame and move on to the next, i.e. judder.

I should say that we are assuming that what Reclock is able to infer is actually the time the "Present()" call returns. Unfortunately we do not know this for a fact. However, what is clear is that in Windowed mode the "vsync target" Reclock measures is pinned in hardware to just after vsync. It is clear that it is hard-pinned because there is almost no spread - just a single line marking its position, just below the top of the screen. However, in exclusive mode or when using Aero or overlay this measured position is random after each seek, unless Reclock vsync correction is enabled or the renderer itself is positioning "Present()", and has a spead that indicates it is software scheduled.
I think I understand it now. Basically Reclock's logic is a fix for all renderers who don't properly do things on their own. That's a nice trick! But to be honest, I believe a good renderer should solve this problem on its own, without relying on external hacks. I believe my planned (not yet implemented) solution for exclusive mode and Aero is overall a much better solution. Why? Because what Reclock and madVR are currently doing, is a difficult thing and in my experience is not 100% reliable all of the time, especially when the PC is busy doing some other stuff during rendering. Basically for Reclock's and madVR's current solution to work perfectly, Reclock/madVR need to have CPU time every VSync at the right time. If it happens that due to a busy PC, Reclock/madVR don't get any CPU time between 2 VSyncs, things can go wrong. The final madVR solution I have in mind for exclusive mode and Aero should be much more reliable.

So will I add a Reclock mode? I'd say: Let's wait and see how well madVR's exclusive mode / Aero solutions will work. And then we can decide whether adding a madVR Reclock rendering mode is worth it.

if the madVR position is fixed and not compatible with that required for Reclock in other players (eg. TMT or PDVD) the user would still need to write to the registry to move the target before and after using madVR.
I think the proper solution for that would be to add an option to Reclock which allows turning VSync correction on/off for specific renderers. Or Reclock could also hard code VSync correction to be off, when it detects that the renderer is madVR. That should be very easy to implement.

[madshi]

That was a bug all this time? I thought you said way back (madVR 0.4) that you were using SoftCubic since it had almost no ringing, haloing, and aliasing. You didn't think the softness was an issue because you could always sharpen via post-processing or on your TV. Something along those lines.
Well, I don't really remember, to be honest. In my mind I thought that Lanczos was set as default for upscaling, too, though.

tried this on my 9400m, still doesn't work, coreavc cuda on/off, latest mpc, the player and filters load, but after that it hangs, i can alt-tab out and the video will eventually start, but will stutter pretty bad, one time i managed to enter full screen and get a few minutes without issues but i tried with another movie and failed, used windows xp, back to 0.09 again ;) latest nvidia drivers
Please try again with the next madVR version. It will contain a fix for misbehaving newer NVidia drivers. How often did I say that on the last 2 pages? I bet at least 5 times! ;)

[cyberlolo]

Well, I don't really remember, to be honest. In my mind I thought that Lanczos was set as default for upscaling, too, though.

So to sum things up, your recommended default setting for Luma upscaling is Lanczos4, isn't it?

[Jong]

I think the proper solution for that would be to add an option to Reclock which allows turning VSync correction on/off for specific renderers. Or Reclock could also hard code VSync correction to be off, when it detects that the renderer is madVR. That should be very easy to implement.I agree with that. It already has control by renderer except it has no specific option for madVR. If James has a few spare minutes it may be possible.

I also agree the right place to do all this is in the renderer. :)

My observation (no more!) is that several other people have tried to fix synchronised judder in the renderer and all have ended up moving on to other things before they really fixed it and we end up falling back on Reclock. We are lucky in mpc-hc they included an option to turn off all vsync correction. In MediaPortal at the moment there is no such option and no fix! Any solution needs to at least allow Reclock to work in "non-vsync mode". A solution that completely stops Reclock from working to speedup/slowdown media, as some have ended up with, is IMO no solution.

Lastly I'd just say that, despite the issues you correctly point out, the Reclock method is surprisingly robust, at least on a modern PC. Because the back buffer is still flipped in hardware at vsync, the timing of average point presentation does not need to be that precise. It just needs to be after the preceding vsync (say 3ms) and a little before the next, (say 6ms, ignoring any additional Aero requirements). @50Hz this means presentation can occur anywhere in about a 14ms of the total 20ms frame time. @60Hz we still have maybe 10ms. It is not until we start trying to do 96Hz or, worse, 120Hz, as some are attempting, that it gets very tough.

[madshi]

So to sum things up, your recommended default setting for Luma upscaling is Lanczos4, isn't it?
I have always said and let me say it again:

All resampling algorithms have strengths and weaknesses. Some more than others. Everybody has to pick his own poison. That's also the reason why I don't consider default values to be so important. Just play with the settings and chose whatever you like best.

My observation (no more!) is that several other people have tried to fix synchronised judder in the renderer and all have ended up moving on to other things before they really fixed it and we end up falling back on Reclock.
That's really bad. But well, I'm quite sure this won't happen with madVR.

Lastly I'd just say that, despite the issues you correctly point out, the Reclock method is surprisingly robust, at least on a modern PC. Because the back buffer is still flipped in hardware at vsync, the timing of average point presentation does not need to be that precise. It just needs to be after the preceding vsync (say 3ms) and a little before the next, (say 6ms, ignoring any additional Aero requirements). @50Hz this means presentation can occur anywhere in about a 14ms of the total 20ms frame time. @60Hz we still have maybe 10ms. It is not until we start trying to do 96Hz or, worse, 120Hz, as some are attempting, that it gets very tough.
Yeah, but if done right, for exclusive mode there's no need to depend on millisecond timing. Vista allows 30 backbuffers. So it would be possible to prerender more than 1 full second worth of video playback, which would then all be automatically and perfectly switched by the GPU hardware VSync interrupt, without needing *any* further help by the playback software / renderer. That's *SO* much better than what Reclock does IMHO.

I don't plan to do a 30 frame queue, though... :)

[leeperry]

the optimal way to use exclusive mode is to render as fast as you can and let the VSync hardware interrupt take control. At least that's how games do it.
yes, I think that's the golden ticket to get everything smooth! the sad thing is that I don't even use Reclock's VSYNC Correction...I think Reclock is broken by design, and it takes a lot of luck to get it working.

HR has a jitter figure, I think it's the jitter between the timestamps and the actual presented time...and depending on seeking, it would either slowly increase or decrease...the idea was to make it decrease from as high as possible(say 7ms), then it'd slowly fall back to 0.25ms(it would take 45mn on an HD3850 and +1H on a 8800GS) and then slowly increase(>7ms will drop frames). This "trick" does work, but it's too plain annoying to watch for jitter when all you want is watch a darn movie already :devil:

ah well, Reclock on XP has disgusted me of watching movies tbh..mVR 0.11 w/o the tearing fix worked damn fine, until I realized that I was getting some weird video "glitches"(can that even be called "tearing"?)...to me watching movies on XP is indeed rocket science, it's about time I either move to W7/Aero or use D3D exclusive mode on XP...to "let the VSync hardware interrupt take control" as you said. "Help us obiwan-madshi, you're our only hope" :D

Reclock pushes for timestamps that are IMPOSSIBLE to obey...that's my understanding anyway.

[Jong]

Yeah, but if done right, for exclusive mode there's no need to depend on millisecond timing. Vista allows 30 backbuffers. So it would be possible to prerender more than 1 full second worth of video playback, which would then all be automatically and perfectly switched by the GPU hardware VSync interrupt, without needing *any* further help by the playback software / renderer. That's *SO* much better than what Reclock does IMHO.Yeah that sounds amazing. What is surprising though is that no one else has made any attempt at this. Even the big commercial player - PDVD, TMT and of course WMP all use very conventional renderers. It would be awesome if you could show the way! Then go off and help the big guys make a Blu-ray disc player that does the same!

...by the way, not sure about the whole "that's how games do it" thing. Games typically either throw as many frames up as they can and tear or they actually suffer from another nasty form of judder, where they have to drop the frame rate to half the refresh rate if the frame rate dips below it. That is why most real games put up with tearing.

[Jong]

I think Reclock is broken by design, and it takes a lot of luck to get it working.I don't agree. It is just you have always refused to use exclusive mode and you wouldn't move from XP:D Now it sounds like you are considering both :)

[leeperry]

I don't agree. It is just you have always refused to use exclusive mode and you wouldn't move from XP:D Now it sounds like you are considering both :)
well, exclusive mode in what? in MPC-HC? half of the time, this player doesn't close properly and remains as an active process that I have to kill manually...it's a known issue, yada yada.

and EVR is too sharp to my eyes anyway...I'll take LSF over their hardware accelerated sharpener anytime of the day.

W7? let's just say that I'm perfectly happy w/ my XP box for everyday use and audio(w/uLilith+ASIO4ALL) and it's not the hollywood movies crappiness and Reclock's nonsense that will force me to move to an OS w/ +50 background processes living their life as if I did not exist.

I think I sumed up the problem pretty accurately at the end of my previous post...Reclock is expecting the impossible, and all the VR's are forced to drop frames to catch up :devil:

[pirlouy]

No need for a particular option to disable Aero.
You can disable Aero by application: http://forum.doom9.org/showthread.php?p=1375022#post1375022

[Mark_A_W]

I'm worried by all this talk of Aero and Exclusive mode.


- Aero does not work with Multi-monitors. I've confirmed this myself. Beautiful playback with one monitor, turn on the second monitor and it all goes haywire (it may work if the other monitor has a refresh rate that is a multiple..haven't checked that....but doesn't mean there is an underlying bug? And anyway, I watch video with more than one source rate).

- There are no players with a decent, reliable, attractive, exclusive mode interface. MPC-HC buggy, and ZP doesn't have an interface at all for exclusive mode (time to start pleading to Blight to write one..). Theatertek worked well in exclusive mode, but it's dead.

[Razoola]

I'm worried by all this talk of Aero and Exclusive mode.


- Aero does not work with Multi-monitors. I've confirmed this myself. Beautiful playback with one monitor, turn on the second monitor and it all goes haywire (it may work if the other monitor has a refresh rate that is a multiple..haven't checked that....but doesn't mean there is an underlying bug? And anyway, I watch video with more than one source rate).

- There are no players with a decent, reliable, attractive, exclusive mode interface. MPC-HC buggy, and ZP doesn't have an interface at all for exclusive mode (time to start pleading to Blight to write one..). Theatertek worked well in exclusive mode, but it's dead.

I'm with you all the way on Aero, I can confirm the multi monitor issue with it, its easy to check if you want to test it yourself. That said though from the way madshi has answered my queries I think he will give option to disable aero etc once once he gets to the point he realises the issues it causes in some setups (multi monitor).

I feel the way madshi is going about it is actually a very good way for the dev cycle of madVR, he seems very level headed and want to achive perfectly smooth playcack without the need of reclock, my fingers are crossed he gets there.

[edison]

is that possible output full screen video to the second monitor in exclusive mode while keep the windowed video player in 1st monitor like the video mirror mode in old NVIDIA XP driver ?

[djsolidsnake86]

mkv files that have x264 codec crash with madvr, ok with other render

[Jong]

well, exclusive mode in what? in MPC-HC? half of the time, this player doesn't close properly and remains as an active process that I have to kill manually...it's a known issue, yada yada.

and EVR is too sharp to my eyes anyway...I'll take LSF over their hardware accelerated sharpener anytime of the day.

W7? let's just say that I'm perfectly happy w/ my XP box for everyday use and audio(w/uLilith+ASIO4ALL) and it's not the hollywood movies crappiness and Reclock's nonsense that will force me to move to an OS w/ +50 background processes living their life as if I did not exist.

I think I sumed up the problem pretty accurately at the end of my previous post...Reclock is expecting the impossible, and all the VR's are forced to drop frames to catch up :devil:I'm surprised you still have problems with mpc-hc not closing. I had that problem for a little while about 2 years ago, but not for a long, long time, even before I moved to W7 last December. Maybe it is a renderer compatibility issue? It never happens to me using EVR Sync or EVR CP.

I fully understand your feelings about moving from XP. As you know I was really uncertain about moving for a long time. But I would not worry about the background processes in W7. Its improved scheduling more than compensates IMO. Plus, if you ever want to play streamed video you will most likely need Aero to fix tearing.

Regarding Reclock though, it is not the cause of the problems. As Madshi said:.....madVR knows exactly at which VSync each frame should be presented. The next problem is when to do the actual "Direct3D::Present()" call. This is problematic, because the "Present()" call blocks (doesn't return), until the target VSync event is through. And during the blocked time, the GPU doesn't render, anymore. So if madVR presents too early, rendering stops, which can cause stuttering (because the queues empty and no new frames can be rendered). But if madVR calls the "Present()" API too late, with a bit of bad luck, it might be too late and Direct3D might sloü the targetted VSync and wait for the next VSync instead, which would also cause stuttering.It's not specific to video renderers. Any software, which uses Direct3D in windowed mode, blocks in the "Present()" call. That also applies to games. There's no way around that, that's just the way Microsoft implemented Direct3D.

Things change in fullscreen exclusive mode. There "Present()" does not block, as long as there's still a non-used backbuffer available....

Aero also changes things. Aero works somewhat comparable to fullscreen exclusive mode. However, there are specific Aero APIs available to control which frame is presented when and for how many frames.ALL renderers are very tightly constrained in windowed mode.

Only an overlay surface, or exclusive mode or Aero frees up those constraints.

Furthermore, when those constraints are released, Reclock actually helps current renderers to be less time sensitive by positioning average start of presentation as early as possible in the vsync cycle to give it maximum time to complete.

Ignoring for a minute Madshi's plans to pre-render multiple frames in advance (which I agree would be awesome), even a renderer that did the job properly itself (at the moment there are none!) would only be in a slightly better position. It would not have to worry about being too close to the preceding vsync, so it may have an extra 3-4ms to play with over Reclock, but it is still susceptible to scheduling delays. In practice, on a modern PC, Reclock has enough margin to work almost all the time (i.e significantly fewer than one drop per movie). If some errant process causes a big enough hiatus to stop a Reclock "controlled" renderer presenting in time I am not sure an extra 3-4ms would make any difference!

In fact my main interest in having the renderer properly manage vsync was not to avoid possible scheduling problems but to avoid Reclock's "brief judder after a seek" issue. Reclock can take up to ~30 secs to get vsync into its target zone. Sometimes playback starts in, or very near, judder and Reclock cannot avoid that. A renderer that correctly controls vsync can hold onto the frame and present it at a safe spot, so judder can be avoided completely, even at the start or after a seek or pause. :)

Lastly:HR has a jitter figure, I think it's the jitter between the timestamps and the actual presented time...and depending on seeking, it would either slowly increase or decrease...the idea was to make it decrease from as high as possible(say 7ms), then it'd slowly fall back to 0.25ms(it would take 45mn on an HD3850 and +1H on a 8800GS) and then slowly increase(>7ms will drop frames). This "trick" does work, but it's too plain annoying to watch for jitter when all you want is watch a darn movie already :devil:I don't think HR is special in any way here. As Madshi said, all renderers in windowed mode are subject to pretty tough timing. The problem you describe with HR is exactly the same as every other renderer that is susceptible to synchronised judder. My guess is:

- like all other renderers not using Reclock vsync correction and without their own ability to change playback speed (i.e. EVR Sync in "sync video to display" mode), the time the first frame is available for presentation is random, relative to vsync, after each seek. It then drifts slowly if there is any mismatch between the GPU and the reference clock

- the "jitter" figure is, I think, how far away from the middle of the frame that "start of presentation" is, or maybe how far away from the "ideal". It is the same measurement as the EVR Sync "av. sync offset" except it is expressed as an absolute value relative to the middle of the frame instead of the distance from the end of the frame. So, for a 20ms frame, the EVR Sync offset, with Reclock vsync correction OFF, can be any value from 0ms to -20ms. Judder occurs if the average is between, say -18 to -20ms or 0ms to -3ms. If I am right, a "jitter" figure of >7ms corresponds to an EVR offset figure either 0 to -3ms or -17ms to -20ms; If you were talking about 60Hz, with a 16.7ms frame time 7ms would correspond to times within 1.33ms either side of vsync. All of these are very much in synchronised judder territory.

- So, although I understand you do not like the look of EVR, you see you could do exactly what you used to do with HR with EVR sync and no Reclock vsync correction

- Start playback
- look at the "Sync offset"
- keep pausing until the figure is -10ms@50Hz, or, if you know the direction of drift, pause until you get -17ms or -3ms (at 60hz the figures would be -8.33ms, - 14ms or -3ms)
- then you will have judder free playback until the offset drifts either to near the top or the bottom.

It really does not look to me like there is anything different about HR in this respect. It is behaving just the way all other "normal" renderers behave.

[madshi]

What is surprising though is that no one else has made any attempt at this. Even the big commercial player - PDVD, TMT and of course WMP all use very conventional renderers.
Yeah, that surprises me, too.

...by the way, not sure about the whole "that's how games do it" thing. Games typically either throw as many frames up as they can and tear or they actually suffer from another nasty form of judder, where they have to drop the frame rate to half the refresh rate if the frame rate dips below it. That is why most real games put up with tearing.
Hmmmm... I've stopped playing Direct3D games a few years ago (due to lack of time), but I don't remember having ever seen games tear. Maybe newer games are different? Maybe they need ultra fast reaction times with 0 lag. In that situation maybe it's preferable to tear over having a small lag caused by proper VSyncing? Don't know... For video rendering lag is not a problem because video playback is not interactive. In a game if the player changes direction, the game has to react immediately, so you can't prerender too many frames. With video playback it would be possible to prerender hundreds of frames.

I'm worried by all this talk of Aero and Exclusive mode.

- Aero does not work with Multi-monitors. I've confirmed this myself. Beautiful playback with one monitor, turn on the second monitor and it all goes haywire (it may work if the other monitor has a refresh rate that is a multiple..haven't checked that....but doesn't mean there is an underlying bug? And anyway, I watch video with more than one source rate).

- There are no players with a decent, reliable, attractive, exclusive mode interface. MPC-HC buggy, and ZP doesn't have an interface at all for exclusive mode (time to start pleading to Blight to write one..). Theatertek worked well in exclusive mode, but it's dead.
So you dislike both Aero and exclusive mode? Don't worry, I'm not planning to drop non-Aero windowed mode. I want to have all modes work as good as possible. But still, I think the ultimate solution will be exclusive mode. Yeah, the user interface in exclusive mode might be a problem. But hey, for me video playback quality is 10x more important than a nice user interace. What user interface do you need during video playback, anyway? Personally, I need to be able to pause and resume the movie. That's about it.

is that possible output full screen video to the second monitor in exclusive mode while keep the windowed video player in 1st monitor like the video mirror mode in old NVIDIA XP driver ?
Not sure, probably somehow.

mkv files that have x264 codec crash with madvr, ok with other render
I would guess that this is a problem between madVR and the decoder you're using. Please try at least 2 different decoders, if possible 3. If you have the same (or similar) problems with all decoders, please upload a sample for me to reproduce the problem.