MPC-HC GothSync tryouts

[asc28]

working great for me (24p on 120hz), i used to hate those small judders and this gets rid of em. keep up the great work!

[de66ka]

Good work,
found your "tuned" version of MPC-HC by chance.
Im using MPC and MPC-HC for a long time. But the newer builds didn't really satisfy me.
Im using an ATI HD 2600 XT which is great in HD (DXVA).
But in the last weeks i fight with juddering. Old Builds didn't work with new ATI-Drivers und vice versa.
So I changed my system from VISTA 64 to WIN 7 X86, but juddering remains.
After using your MPC-HC GothSync, videos play smooth again.
So from me a "big thumb up"!!!!!

[ar-jar]

The source code is now available at https://mpc-hc.svn.sourceforge.net/svnroot/mpc-hc/branches/gothsync. Thanks for all the feedback! -A

[webs0r]

Hi ar-jar

Your latest build with Present at nearest vsync option + reclock works wonderfully.

Can I ask - I was reading your guide and how you say that the target sync offset should be half the refresh time. Can it automatically choose this based on the display's current refresh rate?

Now I just need some automatic way of changing the refresh rate based on the file. Maybe I should set up reclock to do this after all...

M

[ar-jar]

Hi ar-jar

Your latest build with Present at nearest vsync option + reclock works wonderfully.

Can I ask - I was reading your guide and how you say that the target sync offset should be half the refresh time. Can it automatically choose this based on the display's current refresh rate?

Now I just need some automatic way of changing the refresh rate based on the file. Maybe I should set up reclock to do this after all...

M

Great that it worked for you. Yes, I might set that value automatically in the future. For now I have wanted to keep it manual for my experiments.

It would be rather easy change resolution and refresh rate automatically using Powerstrip (for compatible gfx cards). DirectX uses integers to represent refresh rates so it can't be used for instance to set 23.976. The alternative would be to use NV and ATI native functions but those would be specific to each gfx board. So today I prefer to use compatible boards and tweak them with PS.

My patch already controls the display refresh rate w/ PS in small increments when using the "sync display" option. The same function could be used to set any display resolution parameters (again, for compatible boards). The only drawback is that one needs to ascertain in forehand that the display can handle the suggested resolution. So it can't bee too automatic I think or we would all end up with black displays from time to time.

-A

[Casshern]

Hi i just managed to test the newest private build with the present at nearest vsync. It did not quite work for me, but this is probably not due to the sync code but due to having to use evr custom. System: XP 32Bit, 2600 Pro AGP, Cat 9.8. The problem is that i get tearing under evr custom (tried all possible combinations of Vsync/GPU options). That's why i normally use VMR9, but this problem is also present in the normal build. On my system everything is fine under VMR9+Flush GPU+Wait for GPU flush. Does anybody know if WIN7 works better (at least it's supposed to allow h264 dxva in EVR, in XP this only works for VC-1) under EVR ? I am prepared to switch, if necessary.

regards,

Casshern

[de66ka]

I think you have issues in your XP-Installation. With XP, the EVR-Renderer allows h264 in dxva too, if the stream is dxva-compatible encoded.
But remember: EVR is only available for XP if you had installed NET 3.5

You can fight against tearing using the "D3D Fullscreen" option (View/Player/Output).
The price you have to pay for is loosing the possibility to switch between fullscreen and window while looking video, but tearing vanishs.

Switching to Win7 maybe fixes your tearing, maybe!!!!!!

On the other side with your graphic-chip I think older Catalyst builds are the better choice. I would use Catalyst 8.12.

Greetz
Axel

[Casshern]

Well i have XP with NET 3.5. And DXVA(2) with EVR Custom does only work for VC-1. I would be suprised if it worked with H264 as the driver only reports DXVA2 capability for VC-1. Also D3D fullscreen exhibits the same tearing here (with DXVA decoding) only VMR 9 renderless with the GPU options work on my 2600 PRO AGP. It's a known issue - i talked to beliyaal a lot about it way back. But i will probably switch to win 7 soon, and if that doesn't help - a nice shiny corei7 machine would make dxva decoding obsolete anyway and also allows to use limit sharpen scripts with HD material. On the issue of catalyst versions, while i do not remember 8.12 specifically - i did quite extensive testing with just about all cat versions and especially the dxva engine was changed even for older cards in the 9.x drivers. Only with 9.4 or 9.5 some major issues on my system were fixed. And the 9.8 drivers seem to work pretty much the same as those versions. I would recommend them over older drivers for all ATI 2x00 AGP users - but your milage might vary.

I think you have issues in your XP-Installation. With XP, the EVR-Renderer allows h264 in dxva too, if the stream is dxva-compatible encoded.
But remember: EVR is only available for XP if you had installed NET 3.5

You can fight against tearing using the "D3D Fullscreen" option (View/Player/Output).
The price you have to pay for is loosing the possibility to switch between fullscreen and window while looking video, but tearing vanishs.

Switching to Win7 maybe fixes your tearing, maybe!!!!!!

On the other side with your graphic-chip I think older Catalyst builds are the better choice. I would use Catalyst 8.12.

Greetz
Axel

[ar-jar]

Hi i just managed to test the newest private build with the present at nearest vsync. It did not quite work for me, but this is probably not due to the sync code but due to having to use evr custom. System: XP 32Bit, 2600 Pro AGP, Cat 9.8. The problem is that i get tearing under evr custom (tried all possible combinations of Vsync/GPU options). That's why i normally use VMR9, but this problem is also present in the normal build. On my system everything is fine under VMR9+Flush GPU+Wait for GPU flush. Does anybody know if WIN7 works better (at least it's supposed to allow h264 dxva in EVR, in XP this only works for VC-1) under EVR ? I am prepared to switch, if necessary.


Do you get tearing with VMR9 in my build? (It would surprise me if you didn't but I ask just in case.) -A

[mariner]

1265 vs 9012

Greetings ar-jar.

Played a 59.94 clip with refresh rate of 60 to test 9012' latest Vsync mode, while 1265 had all Vsync options turned off.

1265's frame rate stayed constant at 60, but not 9012.

Best regards.

[STaRGaZeR]

9012?

[ar-jar]

9012?

See http://www.ostrogothia.com/?page_id=1213, "private builds". -A

[STaRGaZeR]

Thanks, missed it ;)

[mariner]

9005 vs 9012

Tested once again using 59.94 clip with refresh rate set at 60, DXVA enabled.

With Vsync mode set to synchronize video, 9005 reports a steady frame rate of 60, while 9012 does not.

Is this how the new frame rate detection routine is supposed to work?

Many thanks and best regards.

[Jong]

Hey ar-jar. Thought I'd try an experiment and use your player with Reclock speeding up 24p material to play @50Hz. XP SP3, VMR9(renderless) in D3D mode, using sync method 1. Reclock vsync correction OFF of course.

I aboslutely swear to you the first time I did it it played perfectly. It was hitting the -10ms target offset beautifully and audio was fine. Then I tried agin in non-D3D mode and got a horrible sawtooth pattern for the green line in the graph. Switched back to D3D mode and I STILL get the sawtooth. I cannot work out for the life of me why it worked so perfectly the first time. Is there anything you store in the registry or elsewhere that you reuse the second time around that may be causing this. Any other ideas why it would work once and not again?!

I wish I had caught a screenshot the first time, it was awesome. But now I am very confused!

Edit: I suppose it is possible the very first time I ran it your sync code did not kick in, that happened only after a restart, and it was just "luck" that the offset was almost exactly -10ms (av. -10.1ms I think) when I ran it. :confused:

[ar-jar]

Hey ar-jar. Thought I'd try an experiment and use your player with Reclock speeding up 24p material to play @50Hz. XP SP3, VMR9(renderless) in D3D mode, using sync method 1. Reclock vsync correction OFF of course.

I aboslutely swear to you the first time I did it it played perfectly. It was hitting the -10ms target offset beautifully and audio was fine. Then I tried agin in non-D3D mode and got a horrible sawtooth pattern for the green line in the graph. Switched back to D3D mode and I STILL get the sawtooth. I cannot work out for the life of me why it worked so perfectly the first time. Is there anything you store in the registry or elsewhere that you reuse the second time around that may be causing this. Any other ideas why it would work once and not again?!

I wish I had caught a screenshot the first time, it was awesome. But now I am very confused!

Edit: I suppose it is possible the very first time I ran it your sync code did not kick in, that happened only after a restart, and it was just "luck" that the offset was almost exactly -10ms (av. -10.1ms I think) when I ran it. :confused:

Edit all (now I actually *read* your post): Reclock with any sync method except Present at nearest vsync will produce unpredictable results as two algorithms are both trying to control the speed. Use Present at nearest vsync (you need to use EVR for that for the moment - I / Thomasen will implement it in VMR9 later). It works great for me. (This is actually the first time I tried it with a speed shift so I'm actually a bit excited. Now I can watch my Blu-ray movies with my old pj that will only sync to 50Hz.) -A

[Jong]

Yeah, it looked great to me the first time, but now I cannot get it working. This is what it looks like:

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

Interestingly though later I turned off your sync correction and turned on Reclock's vsync correction and, thanks to your great graphs, it is clear they both do result in a very similar outcome. I think Reclock is slower in moving to its target and it has a target "band" for av.offset, not a single figure. So when I set the Vsync target in Reclock's registry to 3f(hex) it will settle with an av. of either -8.3ms or -11.4ms (roughly), if it starts outside of these figures or between if it starts in between. The min and max once it has settled is pretty consistently about +1ms below the average and -2ms above, so the worst case min = -8Ms+1ms = -7ms and the worst case max = -11.4ms-2ms= -13.4ms.

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

Works pretty well, but I can see yours will be more resilient because the av. in more tightly pinned. The variation between min and max though seems the same for Reclock and your sync correction (at least as I remember it!)

[pirlouy]

Sorry to bother, but in a special thread (http://forum.doom9.org/showthread.php?t=149101) I asked how to use powerstrip to change refresh rate according to video. Maybe someone here can help me...

Anyhow, it would be cool ar-jar, if you found a way to force mpc to change screen refresh rate according to video framerate... For example, there would be some settings for 24 fps video, 25 fps, 30 fps, 50 fps. These settings would allow to choose refresh rate for those cases.

[ar-jar]

Yeah, it looked great to me the first time, but now I cannot get it working. This is what it looks like:


The first graph is very typical of playing 23.976 fps @ 25/50Hz, i.e. you don't have any speed correction. Does Reclock turn green?

See my previous (edited) post! Do not use "Sync video"! :-)

Cheers! -A

[ar-jar]

Sorry to bother, but in a special thread (http://forum.doom9.org/showthread.php?t=149101) I asked how to use powerstrip to change refresh rate according to video. Maybe someone here can help me...

Anyhow, it would be cool ar-jar, if you found a way to force mpc to change screen refresh rate according to video framerate... For example, there would be some settings for 24 fps video, 25 fps, 30 fps, 50 fps. These settings would allow to choose refresh rate for those cases.

See an earlier post on this thread! It is possible of course and easy to implement but it has its drawbacks and limitations. I need to think about how to make it "foolproof" so as to avoid angry posts about black screens :-) -A

[Jong]

The first graph is very typical of playing 23.976 fps @ 25/50Hz, i.e. you don't have any speed correction. Does Reclock turn green?

See my previous (edited) post! Do not use "Sync video"! :-)

Cheers! -AYeah. Reclock goes and stays green. Totally baffled how it appeared to work the first time. I wasn't convinced it would, but then I was (briefly) very excited! I am sure all I changed for the second run was the D3D tick-box :confused:. Then it never worked again!

Looking forward to "Present at nearest vsync " on VMR9. EVR works here, but of course no DXVA for AVC on XP. But even without it your far superior OSD has helped me see properly what Reclock vsync correction is doing and most importantly at least we have a proper glitch count so we do not need to sit in front of the screen for hours looking for judder!

Thanks!

[Mark_A_W]

See an earlier post on this thread! It is possible of course and easy to implement but it has its drawbacks and limitations. I need to think about how to make it "foolproof" so as to avoid angry posts about black screens :-) -A


You have a config screen where you setup your three powerstrip timings (or display changer I think it's called). Similar to the way you enter your timings into Reclocks VBS script...but user friendly ;)

Don't guess, like XBMC does (you have to activate this fearture, it's not the out of the box behaviour), that's a disaster.

[Jong]

ar-jar, can you think of any pros or cons of using your player with all sync correction off, but using Reclock to synchronise clocks, sync to refresh rate and adjust vsync over using the Beliyaal version, in VMR9 D3D mode.

Having compared the two the offset spread seems smaller in yours (3ms vs 4ms) but I am not sure the two OSDs are measuring the same thing! Also, yours reassuringly shows "0 glitches", the Beliyaal OSD requires that I watch the jitter chart and I am never quite sure when slightly larger than normal "spikes" equate to a frame drop!

[ar-jar]

ar-jar, can you think of any pros or cons of using your player with all sync correction off, but using Reclock to synchronise clocks, sync to refresh rate and adjust vsync over using the Beliyaal version, in VMR9 D3D mode.

Having compared the two the offset spread seems smaller in yours (3ms vs 4ms) but I am not sure the two OSDs are measuring the same thing! Also, yours reassuringly shows "0 glitches", the Beliyaal OSD requires that I watch the jitter chart and I am never quite sure when slightly larger than normal "spikes" equate to a frame drop!

I you don't want to use the sync options in my code, then it's basically (not counting any bugs + or -) just like any standard EVR or VMR9 renderer. In Beliyaal code you have more bells and whistles (like the GPU flushes that seem to reduce tearing on some gfx boards9). I have probably been lucky in my choice of boards as I have never experienced the problems that that code is said to solve. I never have any tearing and timing problems really when running my renderer (or my old player, the GothPlayer, for that matter).

I currently think that the optimal combination for many people would be Reclock and Present at nearest vsync in my renderer. It will work with SPDIF. It will reduce/eliminate tearing and it makes it possible to play Blu-ray on my old pj (50Hz). But, there may still be a few bugs hidden in there... -A

PS. Have you tried to reset your Reclock timing database? In rare cases, with the wrong settings, Windows forces 60Hz exclusive mode. If that "gets stuck" in Reclock, it could cause something like the problem you see. As I said, Reclock works really well for me with Present at nearest.

[Mangix]

anyone have any idea why resizing the MPC window results in tearing ever with a straight graph? For example if I play a video and press alt + enter to go to fullscreen, it starts tearing even though the graph is perfectly fine. pressing alt + enter again to come out of fullscreen fixes it. This happens with all files(even 30fps files while running at 60hz). I know reclock isn't the problem since going back and forth between DirectSound and reclock has no effect. And also this only happens on XP. Windows Vista/7 is fine.

[lych_necross]

I you don't want to use the sync options in my code, then it's basically (not counting any bugs + or -) just like any standard EVR or VMR9 renderer. In Beliyaal code you have more bells and whistles (like the GPU flushes that seem to reduce tearing on some gfx boards9). I have probably been lucky in my choice of boards as I have never experienced the problems that that code is said to solve. I never have any tearing and timing problems really when running my renderer (or my old player, the GothPlayer, for that matter).

I currently think that the optimal combination for many people would be Reclock and Present at nearest vsync in my renderer. It will work with SPDIF. It will reduce/eliminate tearing and it makes it possible to play Blu-ray on my old pj (50Hz). But, there may still be a few bugs hidden in there... -A

PS. Have you tried to reset your Reclock timing database? In rare cases, with the wrong settings, Windows forces 60Hz exclusive mode. If that "gets stuck" in Reclock, it could cause something like the problem you see. As I said, Reclock works really well for me with Present at nearest.
Just for clarification, thats reclock with its internal vsync disabled right? Also to use "Present at Nearest", do I need to enable vsync and accurate vsync under the renderer settings?

[ar-jar]

anyone have any idea why resizing the MPC window results in tearing ever with a straight graph? For example if I play a video and press alt + enter to go to fullscreen, it starts tearing even though the graph is perfectly fine. pressing alt + enter again to come out of fullscreen fixes it. This happens with all files(even 30fps files while running at 60hz). I know reclock isn't the problem since going back and forth between DirectSound and reclock has no effect. And also this only happens on XP. Windows Vista/7 is fine.

Do you also get tearing using D3D ("exclusive mode") fullscreen w/ XP? I got tearing in non-exclusive mode way back with NVidia but I believe the new drivers have fixed that. Do you have the latest gfx drivers in XP? Are the green and the red lines about half a refresh period apart (in your case some 8 ms)? A screenshot of the OSD when you get tearing would be great too. -A

PS. And btw, are you using the gothsync build (I assume you are but just in case)?

[ar-jar]

Just for clarification, thats reclock with its internal vsync disabled right? Also to use "Present at Nearest", do I need to enable vsync and accurate vsync under the renderer settings?

Yes to the first question as Gothsync manages vsync. And no to the other questions. Those settings are totally disabled in this build so it doesn't matter if they are checked or not. -A

[Mangix]

Do you also get tearing using D3D ("exclusive mode") fullscreen w/ XP? I got tearing in non-exclusive mode way back with NVidia but I believe the new drivers have fixed that. Do you have the latest gfx drivers in XP? Are the green and the red lines about half a refresh period apart (in your case some 8 ms)? A screenshot of the OSD when you get tearing would be great too. -A

PS. And btw, are you using the gothsync build (I assume you are but just in case)?

when i use exclusive mode, i get no tearing. but the reason is because there is no resizing of the window involved. it starts up fullscreen and stays that way. that's currently the way that i have to watch my videos to prevent tearing.

I have an nvidia Geforce 8500 GT and i'm using nvidia 190.57 drivers.

here's the graph that i get with a 30fps video.
http://img34.imageshack.us/img34/6380/clipboard01xi.jpg
The little spike on the left is what happens when i press alt + enter. and although the picture doesn't show it, the passing red line tears.

And yes, i use the gothsync build since the graph and fps stay consistent throughout. Bad thing is that it happens with both regular and your build. I noticed however that if I enable "wait for flushes" under GPU Control with the regular build, the tearing disappears but as a result I actually get dropped frames and playback is very choppy.

[ar-jar]

1265 vs 9012

Greetings ar-jar.

Played a 59.94 clip with refresh rate of 60 to test 9012' latest Vsync mode, while 1265 had all Vsync options turned off.

1265's frame rate stayed constant at 60, but not 9012.

Best regards.

I guess what you mean is that the "Actual frame cycle" varies a bit and the red line isn't entirely straight. These entities are related. This may be due to inaccuracies in the standard reference clock (the audio renderer) since when I use either my own reference clock (in the sync video option) or Reclock, then the red line stays flat. Or perhaps it is in the combination of measurement method and the measured entity. To find out which is still on my todo-list. Anyway, this is as expected right now. You would get the same variation if you used the sync display option. -A

[Jong]

I you don't want to use the sync options in my code, then it's basically (not counting any bugs + or -) just like any standard EVR or VMR9 renderer. In Beliyaal code you have more bells and whistles (like the GPU flushes that seem to reduce tearing on some gfx boards9). I have probably been lucky in my choice of boards as I have never experienced the problems that that code is said to solve. I never have any tearing and timing problems really when running my renderer (or my old player, the GothPlayer, for that matter).

I currently think that the optimal combination for many people would be Reclock and Present at nearest vsync in my renderer. It will work with SPDIF. It will reduce/eliminate tearing and it makes it possible to play Blu-ray on my old pj (50Hz). But, there may still be a few bugs hidden in there... -A
I'm not running down your efforts at all, I would love to use one of the first two methods (but currently need to play 24p@50Hz). And even without those the OSD statistics enhancements alone are great. But, after what you say here, if we are going to use Reclock at all, I don't see why using "Present at nearest vsync " is better than using Reclock's vsync correction.

Reclock will constantly make minor adjustments to the frame rate to keep presenting frames at the same average position. In use it looks almost identical in your stats to your option 1, except, unfortunately, it only tries to get the offset in a range about 3ms in size. However, with a variance in offset of about +1ms and -2ms (on my system at a least, I realise this may vary) this still give plenty of margin even @60Hz. There should never be a dropped frame unless things get so delayed in Windows for some reason due to errent processes, in which case I think "Present at nearest vsync" would have a problem too, right?

"Present at nearest vsync" on the other hand will (if I understand it right) slowly drift in offset, but then drop just one frame, rather than judder, possibly for minutes with Reclcok stablising the refresh rate. With Reclock controlling the refresh rate this drift will be very small I understand, but it will still happen, in time, right?

But maybe I'm missing something?

What would be intereresting, only if it were very easy for you, would be to replace Beliyaal's OSD with your OSD, in the standard version of MPC-HC for a test build. Then we could run whole movies with

- Beliyaal+Reclock+Reclock vsync
- Beliyaal+Reclock+"Present at nearest vsync", both using the standard build with modded OSD

- ar-jar option1, using your build

all with your stats and see which wins out!!

[ar-jar]

I'm not running down your efforts at all, I would love to use one of the first two methods (but currently need to play 24p@50Hz). And even without those the OSD statistics enhancements alone are great. But, after what you say here, if we are going to use Reclock at all, I don't see why using "Present at nearest vsync " is better than using Reclock's vsync correction.

Reclock will constantly make minor adjustments to the frame rate to keep presenting frames at the same average position. In use it looks almost identical in your stats to your option 1, except, unfortunately, it only tries to get the offset in a range about 3ms in size. However, with a variance in offset of about +1ms and -2ms (on my system at a least, I realise this may vary) this still give plenty of margin even @60Hz. There should never be a dropped frame unless things get so delayed in Windows for some reason due to errent processes, in which case I think "Present at nearest vsync" would have a problem too, right?

"Present at nearest vsync" on the other hand will (if I understand it right) slowly drift in offset, but then drop just one frame, rather than judder, possibly for minutes with Reclcok stablising the refresh rate. With Reclock controlling the refresh rate this drift will be very small I understand, but it will still happen, in time, right?

But maybe I'm missing something?

What would be intereresting, only if it were very easy for you, would be to replace Beliyaal's OSD with your OSD, in the standard version of MPC-HC for a test build. Then we could run whole movies with

- Beliyaal+Reclock+Reclock vsync
- Beliyaal+Reclock+"Present at nearest vsync", both using the standard build with modded OSD

- ar-jar option1, using your build

all with your stats and see which wins out!!

I didn't think you were running down my efforts, no problems :-) There's a bit of history at play in which I never got Reclock to sync properly way back. That was really why i started to experiment with my own methods. The sync display is still the optimal method I think but unfortunately not possible with all set-ups. With Present at Nearest I may have completed a full circle and I should really perhaps now give REclock an other chance instead of patching it with my code. It still doesn't work reliably for me with the vsync option turned on. But I might have missed something in my turn.

Anyway, as I'm still on a learning curve here I will keep debugging and understanding on my branch for a bit more. Then we can run that "contest". I'm sure that life will become busyer when I add something to the trunk and I'm not quite ready yet. -A

Edit: THere will (should) be no drift and thus no glitches when you use Reclock and Present at nearest. Present at nearest would just position the present code right in relation to the vsync. Probably what the vsync option in Reclock should do too.

[Jong]

Edit: THere will (should) be no drift and thus no glitches when you use Reclock and Present at nearest. Present at nearest would just position the present code right in relation to the vsync. Probably what the vsync option in Reclock should do too.But option 1 seems to work the same as Reclock vsync correction. if I am understanding option 3 right it will position it right at the start but not make continual adjustments to frame rate, so there will be slow drift. Am I wrong?

Even so, if you always position it right (rather than randomly, with no options turned on) it shoudl take a long time to drift into harms way, but maybe once (or even twice) in a movie.

[ar-jar]

But option 1 seems to work the same as Reclock vsync correction. if I am understanding option 3 right it will position it right at the start but not make continual adjustments to frame rate, so there will be slow drift. Am I wrong?

Even so, if you always position it right (rather than randomly, with no options turned on) it shoudl take a long time to drift into harms way, but maybe once (or even twice) in a movie.

Sync video is a "Reclock lite" as somebody called it. With analog audio out it works about as well as Reclock with matching rates.

Option 3 will drift if Reclock is not used but make this drift as unnoticeable as possible. And if your rates match well, there won't be many glitches in a movie.

If Reclock is used (w/o it's own sync option), there will of course be no drift and it will just replace Reclock's vsync option (that, again, does not work consistently well for me, thus my experiments in this area). I may not have tried hard enough though. -A

BTW: Does anybody know what type of sync satellite boxes employ? Ideally they should control the speed of the display in the old-fashioned TV-way. If they do, it would be nice to see what parameters in their DVI/HDMI output they tweak to achieve that sync. If they don't, then Present at nearest would be equivalent to their method. But I don't really know and have not been able to find out even by talking to box developers as they buy their circuits and probably never ask that question.

[Jong]

I think it was me who coined "Reclock lite" :)

With Reclock, but no Reclock vsync there is a slow drift in vsync offset. It's slow but there.

[ar-jar]

I think it was me who coined "Reclock lite" :)

With Reclock, but no Reclock vsync there is a slow drift in vsync offset. It's slow but there.

This is a very interesting observation. I will look into it and report back. May take some time though... -A

[Casshern]

Do you get tearing with VMR9 in my build? (It would surprise me if you didn't but I ask just in case.) -A

Will try vmr9 again with your build. But i am under the impression that your new code is only active in EVR. With VMR9 and the regular builds i ONLY get tearing free video with VMR9 + FLUSH GPU + WAIT FOR GPU FLUSH. All other modes including the d3d exclusive modes do not seem to work on my AGP 2600 PRO + WIN XP (x86). I assume that when beliyaal replaced the microsoft vsync handler with his own this sort of broke VMR9 for me and introduced the tearing - luckily he also implemented the GPU FLUSH stuff which made it work again. I had a whole lot of exchanges with him back then regarding the ATI DXVA engine - and our conclusion was that the old lockback buffer method would not work with the ATI engine. Also the lockback buffer approach was also not best-practice when programming directx - So he replaced it with the proper (better) method. But it's like a year back and i do not remember all the details....

[Jong]

This is a very interesting observation. I will look into it and report back. May take some time though... -AProbably I should say it can be there. Obviously, it depends on the starting offset (which is random on each seek if vsync correction is off). It is the reason why you will see many posts, especially by "leeperry" about judder appearing 45' to an hour into a movie, even if he seeks 'till the offset is ideal (no vsync correction). I guess it depends on clock accuracy as well. With my current setup, if I seek until I get judder at the start it will still be juddering 45 mins later, but starting to do so less, so it is drifting if slowly. If you set the offset right in the middle some may get a judder or two in a movie, some maybe not.

[ar-jar]

Probably I should say it can be there. Obviously, it depends on the starting offset (which is random on each seek if vsync correction is off). It is the reason why you will see many posts, especially by "leeperry" about judder appearing 45' to an hour into a movie, even if he seeks 'till the offset is ideal (no vsync correction). I guess it depends on clock accuracy as well. With my current setup, if I seek until I get judder at the start it will still be juddering 45 mins later, but starting to do so less, so it is drifting if slowly. If you set the offset right in the middle some may get a judder or two in a movie, some maybe not.

So are you basically saying that Reclock is / may be drifting (regardless of renderer) unless one uses Reclock's own vsync detection?

[Jong]

So are you basically saying that Reclock is / may be drifting (regardless of renderer) unless one uses Reclock's own vsync detection?Yes, very slowly. I guess, without vsync correction providing a positive feedback loop, clock differences/errors can lead to slow drift that can "drift into judder" depending on the length of playback and the size of the offset at the start.

[ar-jar]

Yes, very slowly. I guess, without vsync correction providing a positive feedback loop, clock differences/errors can lead to slow drift that can "drift into judder" depending on the length of playback and the size of the offset at the start.

That's news to me. Thanks. So basically it is a static calibration in those cases. Now, the Reclock doc actually recommends to turn off vsync detection in Reclock when using VMR9 as VMR9 does something with vsync and timing of its own. This would then limit the usefulness of Reclock quite a bit? Or does it actually play well with VMR9 w/ vsync detection/correction on despite that caveat?

I will run a full movie w/ Reclock and count glitches... -A

[Jong]

That's news to me. Thanks. So basically it is a static calibration in those cases. Now, the Reclock doc actually recommends to turn off vsync detection in Reclock when using VMR9 as VMR9 does something with vsync and timing of its own. This would then limit the usefulness of Reclock quite a bit? Or does it actually play well with VMR9 w/ vsync detection/correction on despite that caveat?

I will run a full movie w/ Reclock and count glitches... -AAs an example (actual figures may vary), without vsync correction Reclock calculates the refresh rate @say 50.000Hz, but in fact it is 50.0003Hz. Small difference, but leads to one frame approx every hour (if I haven't got my maths wrong!). It is continually measuring the refresh rate I believe but there is still a measurement error. Of course because the drift is so slow when it does happen the judder is horrible and goes on for ages (many minutes).

On the other point, yeah, I think Ogo, was working a lot in the dark when he originally wrote Reclock. There is little documentation on all this as I am sure you found developing your player!

Even he said "VMR9: this renderer seems to have an internal way to do the same thing and will somehow work against the VSYNC ". He didn't seem sure if/how they would work/fight and still allowed it as an option! and he disabled it for DXVA, when in fact we now know it works perfectly in DXVA mode, although of course you cannot actually display the vsync markers on screen.

As I see it there is nothing inherent in VMR9 that forces vsync. it is down to how the renderer is configured. Probably the player he was using all those years back did force it (most do). Beliyaal's code allows you to turn off vsync in VMR9, but that just seems to mean you flip buffers as soon as a frame is complete, so it tears. But what does work is D3D mode (as we discussed on your blog). Extra buffering in D3D mode seems to allow Reclock to control when each frame is presented (which is how it controls "vsync"), although the renderer is in fact always switching the backbuffer at just the right time before/during vsync to avoid tearing.

In non-D3D mode in most players (not with Beliyaal vsync off) the way VMR9 "somehow works against the vsync" is that vsync is "pinned" by the player, Reclock alters the frame rate ever so slightly to try to roll the vsync point into its target zone, but the player keeps it pinned in the same location, so Reclock runs with a permanently slightly fast/slow frame rate that leads to periodic judder every few seconds to a minute or so.

I think all this applies to EVR too, which was never supported by Ogo (added by Slysoft).

[Jong]

Interestingly, I need to do a longer test, but your VMR9 renderer in non-D3D seemed to work better with Reclock. I don't know if you can think why. The offset seemed to roll up and down within about 1-2ms but, if you have the target set properly never into the danger zone. But it was a quick test and I may be wrong. I need to test again, with DXVA off so I can see the Reclock vsync markers.No I think this was nonsense! Behaviour is the same as the "normal" version. Above post edited!

[Bitmonster]

BTW: Does anybody know what type of sync satellite boxes employ? Ideally they should control the speed of the display in the old-fashioned TV-way. If they do, it would be nice to see what parameters in their DVI/HDMI output they tweak to achieve that sync. If they don't, then Present at nearest would be equivalent to their method. But I don't really know and have not been able to find out even by talking to box developers as they buy their circuits and probably never ask that question.
I don't know if they actually do it today, but a few years ago digital boxes used a VCXO (voltage-controlled crystal oscillator) to match the internal clock to the one of the broadcast station. So they have perfect sync.

If today's PC video cards would use such VCXO, that could be controlled through a GPU register (and the same for the sound card), we would have PCs with perfect sync, even for external sources. But since enough people claim "my PC is judder free" even without ReClock or similiar tricks, manufacturers will never spend the 50 cents for a VCXO or similar device.

[Casshern]

Hi,

the way i understand ar-jays method it might have the potential to circumvent the judder due to the slow drift. In essence instead of going into a long period of judder it should just drop or repeat one frame and then be fine again for the next lets say 45 minutes.... this would be reasonable, and perfectly fine for movie playback. At the moment though there still seems to be some issues here....

We discussed this way back with james from slysoft and beliyaal and the consensus was that perfection can only be achieved if the vsync handler could actually talk to reclock (which in turn uses the reference clock to adjust the speed of video). But ar-jays code could do without that, trading absolute perfection for one occasional dropped or repeated frame. I think it would be a worthwhile compromise.



As an example (actual figures may vary), without vsync correction Reclock calculates the refresh rate @say 50.000Hz, but in fact it is 50.0003Hz. Small difference, but leads to one frame approx every hour (if I haven't got my maths wrong!). It is continually measuring the refresh rate I believe but there is still a measurement error. Of course because the drift is so slow when it does happen the judder is horrible and goes on for ages (many minutes).

On the other point, yeah, I think Ogo, was working a lot in the dark when he originally wrote Reclock. There is little documentation on all this as I am sure you found developing your player!

Even he said "VMR9: this renderer seems to have an internal way to do the same thing and will somehow work against the VSYNC ". He didn't seem sure if/how they would work/fight and still allowed it as an option! and he disabled it for DXVA, when in fact we now know it works perfectly in DXVA mode, although of course you cannot actually display the vsync markers on screen.

As I see it there is nothing inherent in VMR9 that forces vsync. it is down to how the renderer is configured. Probably the player he was using all those years back did force it (most do). Beliyaal's code allows you to turn off vsync in VMR9, but that just seems to mean you flip buffers as soon as a frame is complete, so it tears. But what does work is D3D mode (as we discussed on your blog). Extra buffering in D3D mode seems to allow Reclock to control when each frame is presented (which is how it controls "vsync"), although the renderer is in fact always switching the backbuffer at just the right time before/during vsync to avoid tearing.

In non-D3D mode in most players (not with Beliyaal vsync off) the way VMR9 "somehow works against the vsync" is that vsync is "pinned" by the player, Reclock alters the frame rate ever so slightly to try to roll the vsync point into its target zone, but the player keeps it pinned in the same location, so Reclock runs with a permanently slightly fast/slow frame rate that leads to periodic judder every few seconds to a minute or so.

I think all this applies to EVR too, which was never supported by Ogo (added by Slysoft).

[ar-jar]

Hi,

the way i understand ar-jays method it might have the potential to circumvent the judder due to the slow drift. In essence instead of going into a long period of judder it should just drop or repeat one frame and then be fine again for the next lets say 45 minutes.... this would be reasonable, and perfectly fine for movie playback. At the moment though there still seems to be some issues here....

Hi, I just ran a full movie with Reclock w/o vsync correction and Present at nearest and got 2 ms of drift during 6800 seconds of movie. So there *is* drift, but not much. In this particular case I had zero sync glitches as the drift entirely fit into one refresh period. In the worst case I would have got one glitch. With vsync correction I get sync offsets all over the place. With VMR9 in the regular build MPC (and my build) I get severe judder with Reclock w/ vsync correction turned on no matter how I set the vsync ruler. I'll look more into this. -A

[Casshern]

Just tested this. With your latest private build i get tearing in vmr9 no matter what. The GPU Flush settings do not make any difference here - in contrast to the regular build. It looks like undr VMR9 it still use its own vsync handler, only that it is empty and does not contain any code.


Do you get tearing with VMR9 in my build? (It would surprise me if you didn't but I ask just in case.) -A

[ar-jar]

Just tested this. With your latest private build i get tearing in vmr9 no matter what. The GPU Flush settings do not make any difference here - in contrast to the regular build. It looks like undr VMR9 it still use its own vsync handler, only that it is empty and does not contain any code.

Ok, as I said, that was expected. As I've written elsewhere, I did a rather radical restart with the renderers, removing most of the old sync code as none of that code has ever been needed on any of my systems for fixing either sync or tearing when using my own code (in my own player). I understand now that there are systems out there that require some of that old code and I will probably put some of it back later. I do hope though that the problems that for instance the GPU flush code fix are rare and exceptional. And I need to *understand* the code and why it make a difference before I put it back. -A

[tetsuo55]

@ar-Jar
The lastest private build(downloaded 5 minutes ago) breaks syncnearest on my laptop. This is the worst its ever looked.

Both the green and red look like hearbeat monitors, and i get glitches every second.

I noticed you enabled vsync again, no difference however with it on or off

[ar-jar]

@ar-Jar
The lastest private build(downloaded 5 minutes ago) breaks syncnearest on my laptop. This is the worst its ever looked.

Both the green and red look like hearbeat monitors, and i get glitches every second.

I noticed you enabled vsync again, no difference however with it on or off

Thanks, that's bad ,sorry. My intention was to make the code a bit more robust. I realized that there are scenarios in which the renderer will hang. I'll look into it. I have not enabled anything from the "old" code except the tearing test though. -A