madVR - high quality video renderer (GPU assisted)

[Jong]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by Razoola

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.

Originally Posted by mark0077

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.

Originally Posted by mark0077

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

Originally Posted by Jong

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.

Originally Posted by Jong

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.

Originally Posted by Jong

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]

Originally Posted by cyberbeing

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.

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

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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]

Originally Posted by cyberlolo

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.

Originally Posted by Jong

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.

Originally Posted by Jong

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]

Originally Posted by madshi

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

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"

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

[Jong]

Originally Posted by madshi

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]

Originally Posted by leeperry

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 Now it sounds like you are considering both

[leeperry]

Originally Posted by Jong

I don't agree. It is just you have always refused to use exclusive mode and you wouldn't move from XP 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

[pirlouy]

No need for a particular option to disable Aero.
You can disable Aero by application: http://forum.doom9.org/showthread.ph...22#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]

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

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]

Originally Posted by leeperry

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

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:

Originally Posted by madshi

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

Originally Posted by madshi

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:

Originally Posted by leeperry

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

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]

Originally Posted by Jong

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.

Originally Posted by Jong

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

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

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.

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

Not sure, probably somehow.

Originally Posted by djsolidsnake86

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.