MPC-HC GothSync tryouts

[Jong]

STaRGaZeR,

Some thoughts that may or may not help!

First what are your synchronisation settings in each screenshot? Especially "Sync offset"?

I notice in your first screen shot you seem to have the sync position set @5.2ms and you have only an 8.33ms frame time, so you are trying to present (on average) only 3.1ms ahead of vsync. This isn't a lot of time and the glitch seems to be caused just by the small blip in the green line you see just before each event, which is hitting the start of the frame (-8.33ms). With such tight timings @120hz I would try positioning the sync right in the middle - @4ms or @4.12ms if that is possible (not sure). It might help.

But @120Hz I would still be very surprised if occasionally you did not get dropped frames just due to Windows not getting things done in the available 4ms - very fine timing given Windows scheduling accuracy.

Your second screen shot is not using syncnearest, but syncvideo. Did you mean this? As you are using 60Hz, not 59.940Hz, it seems, as ar-jar is saying, you would be better off using syncnearest instead, with Reclock adapting 59.940Hz to 60Hz. Have you tried this? If you did mean to try to use "syncvideo" what do you have the sync offset set to. It seems to be converging on about -14ms which is again too close IMO to the 16.7ms frame time. I would move it to 12ms or so (assuming the player is able to make such a "big" adjustment satisfactorily).

Lastly, just to check, you are not using Reclock at all here are you? for frame rate adaptation? For vsync correction?

[Jong]

I notice in your first screen shot you seem to have the sync position set @5.2ms and you have only an 8.33ms frame time, so you are trying to present (on average) only 3.1ms ahead of vsync.ar-jar, what do you think about having, say, a dotted red line on the OSD at the upper boundary of the frame (-8.33ms in this case, -20ms for 50Hz). Might make it easier for people to notice when jitter is causing glitches?

[Jong]

ar-jar,

I don't know if this is helpful but I have noticed a real difference in the performance of the gothsync branch (9013) vs the trunk specifically @ 60/59.940Hz even with all the gothsync options turned off that may be the cause of some issues, not sure?

As you know I use Reclock. When I start 59.940hz material (a popular 1080i test clip of mine) and the display is already @59.940Hz using the trunk I always see this a second or so in:

http://jong.pwp.blueyonder.co.uk/images/trunk_60hz.jpg

There is a little burst of judder that may be caused by Reclock syncing, but it only happens @59.940Hz and it always goes away to leave clean, synchronised, vsync controlled playback.

With your player it always goes into never ending fits of judder like this:

http://jong.pwp.blueyonder.co.uk/images/gs_60hz_bad_1.jpg

http://jong.pwp.blueyonder.co.uk/images/gs_60hz_bad_2.jpg

The "flatish" part of the green line between bursts of judder moves between -10ms and -5ms, then there is a burst of judder, then it repeats!! It is unwatchable.

To repeat, all your sync settings are off, yet it acts very differently from the trunk.

Just to add an interesting twist, if my display is initially @50Hz and Reclock needs to switch it to 60Hz before playback your player works perfectly, just like the trunk!

http://jong.pwp.blueyonder.co.uk/images/gs_60hz_good.jpg

This is totally repeatable behaviour. In what should be the simpler case - refresh rate already @60Hz your player goes nuts when the trunk does not, but there is something about the fact that Reclock switches refresh rates that stops the problem.

I accept Reclock is causing the funny burst of judder that is causing the problem, but it is interesting that your player does not recover, that the same problem is not in the trunk and that it does not happen even with your player if pstrip has had to change the refresh rate. Maybe this last point may be a clue to curing the vulnerability?

[ar-jar]

ar-jar,

I don't know if this is helpful but I have noticed a real difference in the performance of the gothsync branch (9013) vs the trunk specifically @ 60/59.940Hz even with all the gothsync options turned off that may be the cause of some issues, not sure?



Yeah, I have focused a lot on getting the sync algorithms to work and scaled off a lot of trunk code. I need to go back to get a totally stable base version of the renderer. (Perhaps I need to add some of that trunk code but I'd like to keep things lean.) Since EVR isn't officially supported on XP it's hard to find documentation / examples that are 100% applicable and therefore there is always a bit of uncertainty. But it'll get there...
Thanks for all your efforts! -A

[STaRGaZeR]

Thanks for your answers! Let's see if I can help you.

Hi, thanks for your testing efforts! I don't have much time to look into these in a week or two unfortunately. A couple of comments and questions though:

In issue 1 you say "each time the device is restarted". What do you mean by that?

Each time I do something with some options, opening a video or something like that, it requires a very short black screen and an audio pause. This happened very clearly with the old beliyaal code when you turned Alternative VSync, Accurate VSync, 10 bit video, etc. on/off in realtime. I don't really know if the device is restarted, but it looks that way. After a change in those options or opening a new video, I get a short black screen (possible restart of the device with the new options activated) and 30 seconds of periodical glitches like you see in the SS. Turn on/off Frame time correction, or VSync, no short pauses will occur and no new glitches will appear.

Issue 2: i will look into the lock-ups. Do they happen with all sync options turned off too or just with certain sync options?

It seems they happen with every combination of options including all off, but I can't really tell because they're so random I can't find a pattern. I can have 10 freezes in 1 minute requiring a new seek or none in 30.

Issue 3: The Sync video option can only bridge small frequency differences and is not recommended for a change that requires a "bias" (like from 23.976 to 24 or a multiple). The slope in the green line indicates that the frequency adjustment is not big enough. It actually looks like your frequency diff is 0.2%. The default frequency adjustment is only 0.12% (in the Options), i.e. too small. You could try Frequency adjustment = 0.0022 or something just as a test. But it's really not intended to be used that way.

It really isn't 0,2%, but more like 0,05%-0,1%. You can see it in the first screenshot, I don't know why it showed 0,2% in that one. When using the trunk build or madVR's frame rate detection, both show 119,98-120,001Hz or so. Your suggestions result in the same thing. I've noticed that "Actual frame cycle" shows crazy values when the crazy high glitches occur, like +206,xxx.

Issue 4: No, no glitches should be heard. All my audio renderer have handled the small speed adjustments gracefully. Are you using SPDIF? Could you try with a different audio renderer and see what happens?

No, no SPDIF, only analog output. Reclock and DirectSound are the same. It's like cracking.

STaRGaZeR,

Some thoughts that may or may not help!

First what are your synchronisation settings in each screenshot? Especially "Sync offset"?

Freq adjustment 0,0012, Sync offset to 4ms and Control limits to 1ms in all of them, but it really doesn't matter much. More or less the same results with 2, 6 and 8ms of Sync offset for example.

I notice in your first screen shot you seem to have the sync position set @5.2ms and you have only an 8.33ms frame time, so you are trying to present (on average) only 3.1ms ahead of vsync. This isn't a lot of time and the glitch seems to be caused just by the small blip in the green line you see just before each event, which is hitting the start of the frame (-8.33ms). With such tight timings @120hz I would try positioning the sync right in the middle - @4ms or @4.12ms if that is possible (not sure). It might help.

No, I'm sure it's not caused by that. It only happens in the first 30 seconds, and then they're gone. Also, they're option independent and caused by beliyaal changes, not ar-jar's.

But @120Hz I would still be very surprised if occasionally you did not get dropped frames just due to Windows not getting things done in the available 4ms - very fine timing given Windows scheduling accuracy.

I get no dropped frames with Present at nearest VSync and Reclock set to speedup things to the nearest integer (24, 30 and 60 result in a perfect flat line during an entire movie with no glitches or dropped frames). If not using Reclock, I only get the normal glitches of the 23,976-->24, 29,97-->30, etc. mismatch, every now and then in regular intervals when a frame is repeated to sync audio and video. But again this is perfectly normal and there are no "extra" glitches caused by MPC or Windows.

Your second screen shot is not using syncnearest, but syncvideo. Did you mean this? As you are using 60Hz, not 59.940Hz, it seems, as ar-jar is saying, you would be better off using syncnearest instead, with Reclock adapting 59.940Hz to 60Hz. Have you tried this? If you did mean to try to use "syncvideo" what do you have the sync offset set to. It seems to be converging on about -14ms which is again too close IMO to the 16.7ms frame time. I would move it to 12ms or so (assuming the player is able to make such a "big" adjustment satisfactorily).

The second shot is to show the glitches not caused by ar-jar's code at 60Hz instead of 120Hz, the 60Hz and SyncVideo are just there because I was testing different options :P. As I say above Sync offset doesn't really change this chaotic behaviour. SyncNearest and Reclock is indeed the preferred option, but Reclock doesn't detect 120Hz and takes ages to load even if it works ok later. A bug report in the Reclock forums is in order.

Lastly, just to check, you are not using Reclock at all here are you? for frame rate adaptation? For vsync correction?

Nope, not for testing. No other corrections are happening. For daily usage, yes, SyncNearest and Reclock speeding things up to the nearest integer.

On a side note, I think the Present at nearest VSync should be the default option. It works just as the old beliyaal code, and is the normal way of syncing mismatched frame and refresh rates.

BTW, Arto, can you compile a x64 build of your changes for testing?

Sorry for the long post! :p

[Casshern]

Hi Ar-Jay,

i tried the newest private build and my results under win 7, EVR CP and DXVA are still the same. It seems your algo is even more time sensitive in regard to the time left during the vblank interval. With beliyaals code with the same stream i can have two shaders enabled (YV12US, Complex Sharpen 2) and use bicubic resizing. With your latest build i have to disable one of the shaders and can only use bilinear resizing. Apart from that both (yours and beliyaals) vsync handlers work nearly identical - with an edge obviously to beliyaals code. That poses one question what is the difference to beliyaals code, he also implemented the method described here: http://software.intel.com/en-us/articles/video-frame-display-synchronization/.
Could you elaborate a little?

[Jong]

Freq adjustment 0,0012, Sync offset to 4ms and Control limits to 1ms in all of them, but it really doesn't matter much. More or less the same results with 2, 6 and 8ms of Sync offset for example.Yeah, I guess that's true because 4ms and 1ms is probably about as good as you can set it for 120Hz at the moment. So in that screenshot (where the offset is>5ms) the renderer has yet to finish correcting the vsync.

No, I'm sure it's not caused by that. It only happens in the first 30 seconds, and then they're gone. Also, they're option independent and caused by beliyaal changes, not ar-jar's.I'm sure it is that. That green spike clearly reaches to the beginning of the frame where a judder has to occur.

You are catching gothsync when it is still adapting the vsync (moving it towards 4ms). I see these odd spikes very often with Reclock when it has moved out of serious judder but yet to get to a truly safe zone. But @60Hz that danger zone (say within 3ms of the start/end of frame) is still far enough away from the defined target that Reclock is correcting things quickly and it does not last long (speed of correction is proportional to difference betwen actual offset and desired offset). Here, you are, in absolute terms, very close to the desired offset yet you are still in the danger zone. It is tough! I can make what you are seeing there happen easily @60Hz, just by setting my offset too close (say 3ms) to the beginning of the frame.

Capture a few screen shots a little later, when no judder is occuring, and I would guess the offset is closer to 4ms and the variability upwards is no longer reaching -8.33ms.

I think some thoughts for ar-jar are:

- if gothsync is to work @ these high refresh rate we need more granularity for setting offset and control limits than whole integers (0.1ms?)

- the speed of convergence needs to be proportional to the frame size, not the absolute offset, so the offset will quickly move through -6ms and down to close to -4ms and not very slowly drift through the 5s, where it is still too close to danger to avoid the odd glitch.

I get no dropped frames with Present at nearest VSync and Reclock set to speedup things to the nearest integer (24, 30 and 60 result in a perfect flat line during an entire movie with no glitches or dropped frames). If not using Reclock, I only get the normal glitches of the 23,976-->24, 29,97-->30, etc. mismatch, every now and then in regular intervals when a frame is repeated to sync audio and video. But again this is perfectly normal and there are no "extra" glitches caused by MPC or Windows.Well its hard to argue with that. if you have your PC nailed down tight enough you may well be right. I'd still take a modest(!) bet that if you watched 2 or 3 whole movies with Reclock that there will be the odd glitch >4ms, and if there is a glitch will happen.


The second shot is to show the glitches not caused by ar-jar's code at 60Hz instead of 120Hz, the 60Hz and SyncVideo are just there because I was testing different options :P. As I say above Sync offset doesn't really change this chaotic behaviour. You may be right but you'd need to show an example with sync offset set to 8ms to prove that to me! Where the sync is in that screen shot you will get glitches. You are much too close to the beginning of the frame. You can clearly see the green spike, even though it is not that big, going past 16.666ms. A glitch is unavoidable.

SyncNearest and Reclock is indeed the preferred option, but Reclock doesn't detect 120Hz and takes ages to load even if it works ok later. A bug report in the Reclock forums is in order. OK, so you are consciously trying to use gothsync to do something for which it was not designed because Reclock has problems at higher refresh rates, which is fair enough. Why not give it a go. It might even work for 0.1% speedup. But it was not designed for this.

[STaRGaZeR]

I'm sure it is that. That green spike clearly reaches to the beginning of the frame where a judder has to occur.

You are catching gothsync when it is still adapting the vsync (moving it towards 4ms). I see these odd spikes very often with Reclock when it has moved out of serious judder but yet to get to a truly safe zone. But @60Hz that danger zone (say within 3ms of the start/end of frame) is still far enough away from the defined target that Reclock is correcting things quickly and it does not last long (speed of correction is proportional to difference betwen actual offset and desired offset). Here, you are, in absolute terms, very close to the desired offset yet you are still in the danger zone. It is tough! I can make what you are seeing there happen easily @60Hz, just by setting my offset too close (say 3ms) to the beginning of the frame.

Capture a few screen shots a little later, when no judder is occuring, and I would guess the offset is closer to 4ms and the variability upwards is no longer reaching -8.33ms.

I think some thoughts for ar-jar are:

- if gothsync is to work @ these high refresh rate we need more granularity for setting offset and control limits than whole integers (0.1ms?)

- the speed of convergence needs to be proportional to the frame size, not the absolute offset, so the offset will quickly move through -6ms and down to close to -4ms and not very slowly drift through the 5s, where it is still too close to danger to avoid the odd glitch.

Then why only happens 15 times or so each time a new video is opened and then nothing? Doesn't make any sense to me. I forgot to say, they can be a lot smaller sometimes, like this:

http://thumbnails22.imagebam.com/4950/b18b4549493192.gif (http://www.imagebam.com/image/b18b4549493192)

What does the green line suggest to you in this case? I must emphasize this is not caused by anything in ar-jar's code, it's caused by the changes done by beliyaal as it happens since his very first tryout build. Another thing to consider is, even if I set it to 4ms and 1ms, the green line will stay flat at 5,2 except when these glitches occur. It can move a bit up or down, like little spikes.

http://thumbnails15.imagebam.com/4950/dc7b3449494628.gif (http://www.imagebam.com/image/dc7b3449494628)

You see what happens after 30 seconds have passed. I get that until I close the player.

Well its hard to argue with that. if you have your PC nailed down tight enough you may well be right. I'd still take a modest(!) bet that if you watched 2 or 3 whole movies with Reclock that there will be the odd glitch >4ms, and if there is a glitch will happen.

Of course they can happen, timing is not always perfect. But the point is: these splikes are an anomaly that only happen in the first 30 seconds of the movie, they happen a concrete number of times and the only difference between screenshots will be the lenght of the spikes. Sync offset doesn't matter now, and it didn't matter when beliyaal was around.

You may be right but you'd need to show an example with sync offset set to 8ms to prove that to me! Where the sync is in that screen shot you will get glitches. You are much too close to the beginning of the frame. You can clearly see the green spike, even though it is not that big, going past 16.666ms. A glitch is unavoidable.

No problem.

2ms-4ms:

http://thumbnails16.imagebam.com/4950/04baa849496659.gif (http://www.imagebam.com/image/04baa849496659) http://thumbnails14.imagebam.com/4950/865b1749497022.gif (http://www.imagebam.com/image/865b1749497022)

The SS have a freq adjustment of 0,0022 and Control limits set to 1ms. I just can't take shots with 6 or 8ms because this thing just hangs 1 second after the beginning. The 2ms shot hanged seconds ofter I took the shot, and the 4ms one not much after. I'll try later.

OK, so you are consciously trying to use gothsync to do something for which it was not designed because Reclock has problems at higher refresh rates, which is fair enough. Why not give it a go. It might even work for 0.1% speedup. But it was not designed for this.

I was just testing it. The only problem Reclock has is that it doesn't detect the refresh rate, it displays 0.000. Because of this it takes at least 10 seconds to load (I guess it's trying to determine it), but then it works as it should. With 60Hz it loads instantly and displays 59.98Hz. The funny thing is, this evening it has started to show 120.01Hz and loading instantly too. Weird, but who cares :p

[Jong]

You are right. Those spikes don't look right. They look much more obviously wrong than the first screenshot in the last post, but that may have been because they had less far to go to the frame boundary there so they looked less distinct from the background variability.

But 120Hz is not helping us here, because timing is so tight anyway. If you could post a 60Hz screenshot where the av. offset is around 8ms that would be interesting- is there still a full glitch in the red line or a little spike in the green line?

And I'm still not sure what you are saying about what settings you are using. I think you are saying:

- if you use Reclock + syncnearest all is OK with MPC-HC - none of these problems - the only issue is Reclock taking time to sync to 120hz

- these problems only happen when Reclock is disabled (completely, no frame rate adaptation or vsync correction)

Is this right? Was this also true when testing with the trunk version?

[Leak]

One of my "problems" is that I have a very powerful computer for compilation purposes and it conceals many timing issues.
I'm pretty sure you could use RMClock (http://cpu.rightmark.org/products/rmclock.shtml) to underclock or throttle your CPU when needed... ;)

[STaRGaZeR]

You are right. Those spikes don't look right. They look much more obviously wrong than the first screenshot in the last post, but that may have been because they had less far to go to the frame boundary there so they looked less distinct from the background variability.

But 120Hz is not helping us here, because timing is so tight anyway. If you could post a 60Hz screenshot where the av. offset is around 8ms that would be interesting- is there still a full glitch in the red line or a little spike in the green line?

And I'm still not sure what you are saying about what settings you are using. I think you are saying:

- if you use Reclock + syncnearest all is OK with MPC-HC - none of these problems - the only issue is Reclock taking time to sync to 120hz

- these problems only happen when Reclock is disabled (completely, no frame rate adaptation or vsync correction)

Is this right? Was this also true when testing with the trunk version?

Yes, it is, but only sometimes. You can see it in one of my first screenshots with Sync offset to 4ms and SyncVideo:

http://thumbnails19.imagebam.com/4943/cdbced49422976.gif (http://www.imagebam.com/image/cdbced49422976)

With 60Hz it's very difficult to take a shot because they happen a lot less and not in the first 30 seconds of the video. I just got one with 8ms. I needed 5 minutes to get it:

http://thumbnails14.imagebam.com/4958/380db049579323.gif (http://www.imagebam.com/image/380db049579323)

Unlike with 120Hz, where I get them in a regular pattern and only in the first 30 seconds of playing, 60Hz is radically different. You can consider them as random here.

Again, the settings needed to obtain the glitches are:

- No Reclock. But with Reclock, it's the same.
- SyncNearest, SyncVideo, etc. doesn't matter.
- Various sync offset settings.
- 120Hz.

With all the above and 60Hz instead of 120Hz, the same glitches are very random so they're not easily reproducible. But they're there.

Yes, this happens since the first beliyaal test build. His code was integrated into MPC in rev1048.

[Jong]

Again, the settings needed to obtain the glitches are:

- No Reclock. But with Reclock, it's the same.So you still get glitches when using Reclcok and sync nearest?

I ask because you said:I get no dropped frames with Present at nearest VSync and Reclock set to speedup things to the nearest integer (24, 30 and 60 result in a perfect flat line during an entire movie with no glitches or dropped frames).

[Jong]

With 60Hz it's very difficult to take a shot because they happen a lot less and not in the first 30 seconds of the video. I just got one with 8ms. I needed 5 minutes to get it:

http://thumbnails14.imagebam.com/4958/380db049579323.gif (http://www.imagebam.com/image/380db049579323).The regular spikes seem to be a consequence of 120Hz. Maybe pushing some part of the processing chain (CPU/GPU/IO) a bit too hard? I don't know and I don't know why they go away after a while. It's worth looking into, but it seems to be 120Hz (or at least very fast refresh) specific.

The screenshot above is just what I was looking for. It confirms it is not some frame/refresh rate timing issue that would force a dropped frame whatever frame interval, it is the type of random delay in frame presentation due to Windows scheduling etc. I was talking about earlier. As long as it does not hit the green line (causing a "half frame" spike in the red line) it will not cause judder.

What would help is if you set up for 60hz again, use <ctrl><alt>r to reset all the max/mins and counters when all is flat and THEN catch your screenshot with a spike. Then the "# of glitches" stat should reassure you there is no judder, even though there is a little movement on the red and green lines, and the "max/min" offset will tell us exactly how big that spike is!

Although that spike should not cause judder the effect on the red line is big enough to possibly cause a quick one frame flash of tearing. You probably wouldn't even notice it, but you should be able to make the red line smoother, hopefully so it stays within the blanking period (no visible tearing even for a single frame) if you increase the sync offset from -8ms to -12ms or -13ms. The gap between this and -16.666ms should still be enough to protect against background variability "upwards" but the extra margin downwards will reduce the effect any slightly delayed frames (small green spikes) have on the red line. You may need to adjust the offset a little if you find the player is not controlling things with sufficient accuracy. E.g If you set -13ms and you sometimes end up with -14ms offset you probably should set -12ms (-14ms is too close to -16.66ms). If you set -12ms and get -13ms, but some of the natural variability upwards occasionally causes a judder (big red spike), then try -11ms. But I'd be surprised if you get any judder due to upward variability if the offset is <13ms.

This post here (http://forum.slysoft.com/showpost.php?p=219299&postcount=3848) on the Reclock forum discusses just this.

[THX-UltraII]

Do you guys know if there s a simple tool/program out there that can make i 23,976Hz freq? the ATI only does 24Hz and I want 1920x1080@23,976. I know Powerstrip does this but PS is not free and gave my nothing but problems in the past.

[STaRGaZeR]

So you still get glitches when using Reclcok and sync nearest?

I ask because you said:

When I said that I meant no glitches and flat lines after the damn first 30 seconds we're discussing here. Sorry for the misunderstanding. With or without Reclock, they're there.

OK. That's my point.

The regular spikes seem to be a consequence of 120Hz. Maybe pushing some part of the processing chain (CPU/GPU/IO) a bit too hard? I don't know and I don't know why they go away after a while. It's worth looking into, but it seems to be 120Hz (or at least very fast refresh) specific.

The screenshot above is just what I was looking for. It confirms it is not some frame/refresh rate timing issue that would force a dropped frame whatever frame interval, it is the type of random delay in frame presentation due to Windows scheduling etc. I was talking about earlier. As long as it does not hit the green line (causing a "half frame" spike in the red line it will not cause judder.

What would help is if you set up for 60hz again, use <ctrl><alt>r to reset all the max/mins and counters when all is flat and THEN catch your screenshot with a spike. Then the "# of glitches" stat should reassure you there is no judder, even though there is a little movement on the red and green lines and the "max/min" offset will tell us exactly how big that spike is!

Although that spike should not cause judder the effect on the red line is big enough to possibly cause a quick one frame flash of tearing. You probably wouldn't even notice it, but you should be able to make the red line smoother, hopefully so it stays within the blanking period (no visible tearing even for a single frame) if you increase the sync offset from -8ms to -12ms or -13ms. The gap between this and -16.666ms should still be enough to protect against background variability "upwards" but the extra margin downwards will reduce the effect any slightly delayed frames (small green spikes) have on the red line. This post here (http://forum.slysoft.com/showpost.php?p=219299&postcount=3848) on the Reclock forum discusses just this.

You may be right but the main questions here are: why 15 exact glitches and not more? Why only at the beginning? Why ar-jar's code doesn't change anything?

And why do you say you think the regular ones are consequence of 120Hz when this shot (http://www.imagebam.com/image/380db049579323) and this one (http://www.imagebam.com/image/b18b4549493192) look the same, but one is 60 and the other is 120Hz?

I never get tearing, only judder. With samples that have tons of pans is easy to spot them. We're not talking about a little glitch here, it's a huge jump in the video. Each one increases the glitch counter by 2, the shape of the glitch doesn't matter.

I forgot to say: VMR9 or normal EVR do not have any glitches whatsoever. Are you using Vista/7? Or using EVR in XP?

I still think this has nothing to do with Windows f*cking things up, but let's see what ar-jar thinks.

[Jong]

When I said that I meant no glitches and flat lines after the damn first 30 seconds we're discussing here. Sorry for the misunderstanding. With or without Reclock, they're there. No worries. Thanks for clarifying.

You may be right but the main questions here are: why 15 exact glitches and not more? Why only at the beginning? Why ar-jar's code doesn't change anything?I agree it is worth investigating why this happens. Maybe ar-jar can help.

And why do you say you think the regular ones are consequence of 120Hz when this shot (http://www.imagebam.com/image/380db049579323) and this one (http://www.imagebam.com/image/b18b4549493192) look the same, but one is 60 and the other is 120Hz?Because one is regular and at the beginning and one is random and any time (your description). Random spikes (as opposed to glitches) do happen unless you stop almost every Windows background process and maybe even then! Its just life (in Windows!).

I never get tearing, only judder. With samples that have tons of pans is easy to spot them. We're not talking about a little glitch here, it's a huge jump in the video. Each one increases the glitch counter by 2, the shape of the glitch doesn't matter.I said you'd be unlikely to spot the tearing, because it is only a single frame and still VERY close to the top of the screen. But I would be prepared to bet you a high quality beer, (funded through PayPAL!) that you do not get an increase in the # of glitches in this screenshot:

http://thumbnails14.imagebam.com/4958/380db049579323.gif (http://www.imagebam.com/image/380db049579323)

You'll see in the post I pointed to, with my -10ms spike, there is a small corresponding blip in the red line, but no increase in the glitch count.

You will get a "glitch" if you have the offset too close to the frame boundary (top or bottom) as here:

http://thumbnails19.imagebam.com/4943/cdbced49422976.gif (http://www.imagebam.com/image/cdbced49422976)

or if the green spike is bigger than your offset eg. 14ms spike with -12ms as your av. sync offset. But your 60Hz green spike (at least that one) is quite small so a -12ms av. offset should protect against it and lead to smooth playback. :) As I said, doing the 60Hz test again, resetting the counter when playback has stabilized and is smooth and then grabbing a screenshot just after it spikes should prove if there is actual judder or not.

[Kaotech]

In "View -> Options -> Playback -> Synchronization tab" with a display @ 23,976.

I should be set Target sync offset to 41.7083 (1/23,976X1000)?

[STaRGaZeR]

Jong, you're right, it seems that the little, non regular spikes in 60Hz result in no glitches. But I'm sure I've seen new glitches with the regular 120Hz spikes even if they're smaller than 8,333ms, even though I can't confirm it because every time I test now to get a screenshot I get huge spikes. Crazy stuff.

[Jong]

The spikes do not have to be 8.33ms @120Hz. Even if you put the offset dead in the middle @4ms the spikes can only be ~4ms max. Gothsync seems to settle +/-1ms so that may only mean 3ms, which is pretty small!

[Jong]

In "View -> Options -> Playback -> Synchronization tab" with a display @ 23,976.

I should be set Target sync offset to 41.7083 (1/23,976X1000)?No. You should set to something like 21ms (half the frame time). But @24Hz you have a lot of room to play with (unlike STaRGaZeR's 120Hz! :)), so you could reduce it to say 15ms probably quite safely.

[ar-jar]

Hi Ar-Jay,

i tried the newest private build and my results under win 7, EVR CP and DXVA are still the same. It seems your algo is even more time sensitive in regard to the time left during the vblank interval. With beliyaals code with the same stream i can have two shaders enabled (YV12US, Complex Sharpen 2) and use bicubic resizing. With your latest build i have to disable one of the shaders and can only use bilinear resizing. Apart from that both (yours and beliyaals) vsync handlers work nearly identical - with an edge obviously to beliyaals code. That poses one question what is the difference to beliyaals code, he also implemented the method described here: http://software.intel.com/en-us/articles/video-frame-display-synchronization/.
Could you elaborate a little?

There is a new "private" build 9016 on my site. It still needs some more testing before i promote it to a "tryout". It shows some pretty predictable behavior: with your set of shaders and bicubic resizing, I get tearing (but no other sync issues) all the way up to sync offset 18ms (20 ms is the maximum for my 50Hz display). The tearing position moves with sync offset. One explanation consistent with this behavior is that the shader code takes quite some time on my (very cheap) gfx board and so it needs a lot of space to execute (almost the full display refresh cycle). Other than that, shaders work fine on my set-up.

i read the article you refer to when I started working on this problem way back (I've commented it on Intel's site). I think the present at nearest is close to the algorithm described there. My other two algorithm are only hinted in the article. -A

Edit: BTW, I get similar tearing with the regular build too when using that set of shaders. Not even exclusive mode, that usual last resort, works w/o tearing. Perhaps my weak graphics board that can't keep up. Conclusion: I can not currently test the difference between the regular build and my build. I have a new HTPC in pieces waiting for assembly...

[Jong]

Hi ar-jar, welcome back! A build post-1287, which introduced Blu-ray seemless branching would be great to try out, when you have the time.

Thanks.

[ar-jar]

Hi ar-jar, welcome back! A build post-1287, which introduced Blu-ray seemless branching would be great to try out, when you have the time.

Thanks.

Will do. A merge is next on my agenda (if you guys can avoid to find any serious bugs for a while :-)). Cheers! -A

[STaRGaZeR]

I have good news :)

I don't really know the cause, but today watching regular videos I noticed no jumps when starting them, so I enabled the stats. The regular spikes at 120Hz are gone! The only thing I've done that could cause this is install the lastest ATI beta driver, intended for the HD5800 series as there are no official driver releases for them yet. You can get them here: http://support.amd.com/us/kbarticles/Pages/ATIRadeonHD5800seriesrecommendedgraphicsdriver.aspx

120Hz goodness:

http://thumbnails19.imagebam.com/5072/75242650713718.gif (http://www.imagebam.com/image/75242650713718)

The SS was taken with a trunk build because ar-jar's keeps freezing. I'm so freaking happy. I hope this is definitive and not coincidence :p

[THX-UltraII]

@Stargazer: why are you using a 120Hz refresh rate? Do you play your content with a projector or tv?

[ar-jar]

The SS was taken with a trunk build because ar-jar's keeps freezing.

Hi, do you also get freezes with the new 9016 build (my download site)? -A

[STaRGaZeR]

@Stargazer: why are you using a 120Hz refresh rate? Do you play your content with a projector or tv?

Because it allows judder free playback for 24, 30 and 60FPS material, and it's just wonderful for gaming. The monitor is a Samsung SyncMaster 2233RZ, 22".

ar-jar, more great news: no freezes so far with 9016 :)

Another couple of things I've noticed:

1) Framestep doesn't work as it should. Each time the key is pressed the video advances several frames instead of only one. This bug is not present in the trunk build. Framestep back doesn't work OK either, but this one is in the trunk.

2) The internal subtitle filter generates lots of ugly glitches when a subtitle is on screen, with and without buffering (although with no buffering there are a lot more). Higher video resolution and longer or bigger lines results in more glitches. I get no glitches with 720p material but lots with 1080p material. Another thing to notice is that it doesn't happen when the player is windowed, only in fullscreen. I think this can be confirmed by anyone as it's an old bug in the trunk, but I can take shots if needed.

[ar-jar]

ar-jar, more great news: no freezes so far with 9016 :)

Another couple of things I've noticed:

1) Framestep doesn't work as it should. Each time the key is pressed the video advances several frames instead of only one. This bug is not present in the trunk build. Framestep back doesn't work OK either, but this one is in the trunk.



Good to hear it works better. Hope it continues that way.

Does the Frames drawn number in the stats OSD thus increase with more than one when you hit the right arrow key? I don't seem to be able to reproduce this bug in my configuration.

i know about the framestep back. Haven't looked into it yet.

-A

[STaRGaZeR]

No, the counter increases only 1 frame. But it's obvious looking at the video that it has advanced at least 2-3 frames, I can see it like a very short fast forward.

[ar-jar]

No, the counter increases only 1 frame. But it's obvious looking at the video that it has advanced at least 2-3 frames, I can see it like a very short fast forward.

Ok, I'll look into it. I might inadvertently skip frames that the renderer perceives as late even though they are intended for frame stepping. -A

[webs0r]

Sweet. 9016 is working nicely on my setup as well.

I also have the framestep issue where it advances multiple frames but only counts 1.

2 things i've noticed, I'll try my best to describe without screenshots but can do them if needed:
- # of sync glitches, sometimes these increase based on the graph in the past (left side of the graph) even though the current playback is fine (right side of the graph). Usually at the start of playback. I find that a little confusing, shouldn't it only count based on what is happening right in the present?
- On 60 fps playback, it works better now, but there are constant dips in the red line that causes glitches/dropped frames. But its very interesting - if I press alt-enter to un-fullscreen mpc it plays back perfectly - perfectly flat red line below! (Note: while not fullscreen the window is maximised, shaders disabled - even my resize is done on cpu via ffdshow)

[webs0r]

Oh can I ask a question: how do we interpret the hysteresis statistic?

Thanks!

[Astrophizz]

Hysteresis is a latent memory effect, though I don't know what it pertains to here..

[ar-jar]

Oh can I ask a question: how do we interpret the hysteresis statistic?

Thanks!

It alludes to the memory effect in e.g. transformers. In this case it's the memory of picking what side of a vsync the samples should be presented. As explained in many places, e.g. on my blog (see below), when samples are presented very close in time to vsync, common players such as regular MP can't make up it's mind as to on what side to present the sample. This results in judder. To avoid that, as soon as I pass vsync, I add a few ms to some timings so as not avoid "slipping back". When at a safe distance from vsync, the hysteresis is reset. Basically it's a number that's only interesting for me :-) -A

PS. See http://en.wikipedia.org/wiki/Hysteresis

[ar-jar]

Sweet. 9016 is working nicely on my setup as well.

I also have the framestep issue where it advances multiple frames but only counts 1.

2 things i've noticed, I'll try my best to describe without screenshots but can do them if needed:
- # of sync glitches, sometimes these increase based on the graph in the past (left side of the graph) even though the current playback is fine (right side of the graph). Usually at the start of playback. I find that a little confusing, shouldn't it only count based on what is happening right in the present?
- On 60 fps playback, it works better now, but there are constant dips in the red line that causes glitches/dropped frames. But its very interesting - if I press alt-enter to un-fullscreen mpc it plays back perfectly - perfectly flat red line below! (Note: while not fullscreen the window is maximised, shaders disabled - even my resize is done on cpu via ffdshow)

You can reset the stats with <ctrl><alt><R>. It should thereafter only count the glitches entering "from the right".

What sync alternative are you using when getting those dips in fullscreen? What's your target sync offset? What happens if you increase it up towards say 13 ms?

-A

[pirlouy]

Just to confirm that with 1273.9016 version, I don't have seek problems at all.

And just for information, I use "Sync at nearest" without Reclock for 60Hz screens and it works well. In my case, I think it can be included in MPC-HC builds without problem.

[webs0r]

Hi ar-jar

I'm using present at nearest option. Target offset is 14 ms. Same behaviour with 13 ms - here are the screenshots:

Not fullscreen:
http://sharonj81.customer.netspace.net.au/9016-60fps-notfullscreen.jpg

Fullscreen:
http://sharonj81.customer.netspace.net.au/9016-60fps-fullscreen.jpg

[tetsuo55]

Hey webs0r,

Try using the Double CTRL+J, and see if the line evens out.
On my laptop i cannot use the full stats.

Also your videocard is lieing about the refresh rate, and isnt really 60 but actually 59,x

[THX-UltraII]

just tried your latest version and have some questions about it:

1. When selecting the Sync Video To Display option, is it correct that PAL-speeddown in Reclock for 25fps material does not work then and that this only works with the Present at nearest Vsync function?

2. Is it better to use sync video to display if you have exact matching refesh rates?

3. You say in your guide that it is best to let the pc do the decoding when selecting sync video to display. Does this still apply and is bitstreaming dd/dts really not recommended?

4. IF I do want to use bitstreaming (SPDIF over HDMI) DD/DTS, is option nearest vsync the one to use then? (even though I have exact matching refresh rates)

thxz

[ar-jar]

No, the counter increases only 1 frame. But it's obvious looking at the video that it has advanced at least 2-3 frames, I can see it like a very short fast forward.

Pls try the latest "private build" from my site (9017). I hope it only steps one frame. I'm not quite happy with the difference in behavior between a file and DVD when single-stepping and seeking at the same time. But I think the trunk build behaves similarly. -A

[ar-jar]

Hi ar-jar

I'm using present at nearest option. Target offset is 14 ms. Same behaviour with 13 ms - here are the screenshots:


Look nasty :-( Pls try the latest "private build" from my site. I (re-)enabled adjustment of the target sync offset using <ctrl><alt><up arrolw> or ...<down arrow>. You can use these keys to easily test different offsets and see if there's a difference.

Some standard questions: What's your CPU load? And do you use shaders? Looks like you aren't getting up to the correct frame rate. What does it look like when you turn off all sync options? What does it look like in the trunk build? -A

[ar-jar]

just tried your latest version and have some questions about it:

1. When selecting the Sync Video To Display option, is it correct that PAL-speeddown in Reclock for 25fps material does not work then and that this only works with the Present at nearest Vsync function?

2. Is it better to use sync video to display if you have exact matching refesh rates?

3. You say in your guide that it is best to let the pc do the decoding when selecting sync video to display. Does this still apply and is bitstreaming dd/dts really not recommended?

4. IF I do want to use bitstreaming (SPDIF over HDMI) DD/DTS, is option nearest vsync the one to use then? (even though I have exact matching refresh rates)

thxz

1. I wouldn't recommend any other sync options than Present at nearest with Reclock. Reclock seems to get confused both by a variable refresh rate (control display) and a variable clock rate (control video).

2. If you don't use SPDIF, I would recommend sync video yes. Personally I like sync display even better but it requires both a compatible display and a compatible graphics board.

3. Yeah, sync video won't work with SPDIF out. It relies on the fact that the audio renderer matches its rate to the video when the video speed is variable. This rate matching only works if one allows the audio renderer do the decoding.

4. Yes. Or you could combine Present at nearest with Reclock. This combination works very well for me. Other people report a handful of glitches during a movie. You probably won't notice. Then again, Reclock resamples which might not be acceptable if you are an audio buff.

Cheers! -A

[STaRGaZeR]

Pls try the latest "private build" from my site (9017). I hope it only steps one frame. I'm not quite happy with the difference in behavior between a file and DVD when single-stepping and seeking at the same time. But I think the trunk build behaves similarly. -A

Fixed! :)

[webs0r]

Hey webs0r,

Try using the Double CTRL+J, and see if the line evens out.
On my laptop i cannot use the full stats.

Also your videocard is lieing about the refresh rate, and isnt really 60 but actually 59,x

Hey this actually worked - double ctrl+j (less OSD stats) causes the red line to flatten out & results in smooth playback. Why is this?

Sorry actually it didn't.. maybe I jumped the gun.. there were less issues though...

[webs0r]

Hi ar-jar

Ok I've done some proper testing now, sorry about before.

For your questions:
- CPU Load: 40%
- Shaders: All disabled
- Offset testing - on this 60Hz scenario 13 ms gives me the least glitches, going less or more seems to increase the amount. Thanks for the shortcut keys, this made it easy to find.
Please remember that in a window there are NO glitches, this issue seems to be confined to only when mpc is full screen (not D3D fullscreen, just normal fullscreen)

Here are a bunch of screenshots, let me know if this is annoying people & I'll see if I can post them as thumbnails like some others do.

Original scenario screenshot (build 9016, fullscreen, 60 fps, 60 Hz, reclock):
http://sharonj81.customer.netspace.net.au/9016-60fps-fullscreen.jpg

Original scenario but build 9017 and 2xCTRL-J (less glitches!):
http://sharonj81.customer.netspace.net.au/60fps-lessstats.jpg

9017, vsync unticked:
http://sharonj81.customer.netspace.net.au/60fps-novsync.jpg

Trunk build 1290, no vsync:
http://sharonj81.customer.netspace.net.au/60fps-trunknovsync.jpg

Trunk build 1290, Vsync ticked:
http://sharonj81.customer.netspace.net.au/60fps-trunkvsynconlyticked.jpg

Trunk build 1290, Vsync+alternative ticked:
http://sharonj81.customer.netspace.net.au/60fps-trunkaltvsync.jpg

Basically gothsync works well for me at 25/30/50 fps but 60 fps seems to have issues. I don't really have any 60 fps content - and it is quite rare and most of it is "fake" (interlaced shenanigans) so let me know if this is a waste of time. But I figure if you get 60 fps working perfectly (tight timings and margins) it should thereotically work perfectly for slower timings.

[ar-jar]

Hi ar-jar
Basically gothsync works well for me at 25/30/50 fps but 60 fps seems to have issues. I don't really have any 60 fps content - and it is quite rare and most of it is "fake" (interlaced shenanigans) so let me know if this is a waste of time. But I figure if you get 60 fps working perfectly (tight timings and margins) it should thereotically work perfectly for slower timings.

Thanks for your testing. Screenshots are helpful and fine with me. Not sure really what to make of this yet. Could you do one more check please: try frame-stepping your file and see how the Sample time stamp increases (first row in the full stats OSD). Particularly interesting would be to see whether it increases in equal steps (16 - 17 ms in your case).

Also, what happens if you use the Sync video option?

And what happens with or without sync correction using VMR9?

-A

[THX-UltraII]

1. I wouldn't recommend any other sync options than Present at nearest with Reclock. Reclock seems to get confused both by a variable refresh rate (control display) and a variable clock rate (control video).
I tried sync video and it seems to work pretty well with Reclock so far. I assume this because the red line is flat and the green line is almost flat and 3-4 cm above the red line. Is this ok?

2. If you don't use SPDIF, I would recommend sync video yes. Personally I like sync display even better but it requires both a compatible display and a compatible graphics board.
I m not using SPDIF anymore and let the decoding beeing done by ffdshow.

By the way, I just read a post on the reclock forum about bit exact audio: user yesgrey3 suggested me to check the options 'slave reference clock to audio' and set the 'media adaption speed' to Original Speed. I indeed now get bit exact audio output by Reclock. Do you know if this is all ok to use with your player and do you have tips/suggestions on this one?

[ar-jar]

I tried sync video and it seems to work pretty well with Reclock so far. I assume this because the red line is flat and the green line is almost flat and 3-4 cm above the red line. Is this ok?


I m not using SPDIF anymore and let the decoding beeing done by ffdshow.

By the way, I just read a post on the reclock forum about bit exact audio: user yesgrey3 suggested me to check the options 'slave reference clock to audio' and set the 'media adaption speed' to Original Speed. I indeed now get bit exact audio output by Reclock. Do you know if this is all ok to use with your player and do you have tips/suggestions on this one?

Well, using both Reclock and sync video is like riding a tamdem bicycle with steering both front and rear. As long as the two riders agree, all goes well... As I said, this works more by luck than by design :-)

Afaik, slaving to audio gives you the constant speed shift from e.g. 23.978 to 25 but doesn't attempt to adjust any clocks. This option should work with sync display (with compatible board etc) and present at nearest but not with sync video as this option insists on it's own reference clock.

[webs0r]

Thanks for your testing. Screenshots are helpful and fine with me. Not sure really what to make of this yet. Could you do one more check please: try frame-stepping your file and see how the Sample time stamp increases (first row in the full stats OSD). Particularly interesting would be to see whether it increases in equal steps (16 - 17 ms in your case).

Also, what happens if you use the Sync video option?

And what happens with or without sync correction using VMR9?

-A

Ok framestepping results in the sample time pattern: 01, 18, 34, 51, 68 etc so about 16-17 ms.

Sync video results in the exact same behaviour (runs fine in window, glitches when full screen).

VMR9 is the same or worse - both with and without vsync correction.

Cheers

[ar-jar]

Ok framestepping results in the sample time pattern: 01, 18, 34, 51, 68 etc so about 16-17 ms.

Sync video results in the exact same behaviour (runs fine in window, glitches when full screen).

VMR9 is the same or worse - both with and without vsync correction.

Cheers

I remember having a problem like this way back when working with my previous player (GothPlayer). That's when I decided to only support exclusive mode fullscreen in that player :-) When I started working on MPC-HC I found that windowed fullscreen worked almost as well as exclusive mode. I figured drivers had improved. Anyway, here's yet another test for you if you wish. Drag the player window (in windowed mode) all the way to the bottom of the screen so that there is video displayed on the last line of the display. Do you get glitches? I'm currently downloading a 60 fps file. We'll see if I can reproduce your problem. -A