MPC-HC GothSync tryouts

[ar-jar]

Here's the first prototype version of MPC with frame lock features added from my (likewise experimental) GothPlayer movie player (see this thread: http://forum.doom9.org/showthread.php?t=146012). The objective is to eliminate all judder caused by the small mismatches between the video frame rate and the display refresh rate that are always present when playing video on a PC.

The prototype should be compatible with the existing vsync features of MPC-HC except Alternative VSync.

If you wish to try it out, please read more and download the exe file from my blog here: http://www.ostrogothia.com/video/?page_id=1050. Post any comments or bugs on this thread for the time being.

[tetsuo55]

Hey ar-jar, glad you finally got things working, even better to see the first build out!.

If i understand correctly it only work with VMR9 right? Do you have any plans to expand to the other renderers(Especially EVR-CP)?

EDIT:
I see your blog is full of the strugle trying to understand MPC-HC, cool stuff!
I hope you can pour all those compiler woes into a step by step guide to compiling from scratch?

[ar-jar]

If i understand correctly it only work with VMR9 right? Do you have any plans to expand to the other renderers(Especially EVR-CP)?


Yes, it's VMR9 only so far. I don't own anything newer than Windows XP as of now (I guess EVR came with Vista). But it shouldn't be too hard to plug it into other renderers. The algorithm is rather "non-intrusive" and thus easy to wire to pretty much anything that displays frames through DirectX. My plan is to get VMR9 to work well first. Then I'll look at the other renderers.
-A

[tetsuo55]

Some basic testing on an old system using SD content, the numbers are changing so it appears to be working, no noticable difference though. (this system uses windows 7, so EVR-CP results should be better)

[tetsuo55]

I don't own anything newer than Windows XP as of now (I guess EVR came with Vista). EVR can be made to work with XP too, You can get windows 7 for free(legally) here http://www.microsoft.com/windows/windows-7/download.aspx

The licence will work until march 2010 iirc

[ar-jar]

Some basic testing on an old system using SD content, the numbers are changing so it appears to be working, no noticable difference though. (this system uses windows 7, so EVR-CP results should be better)

If the Delay values in the brackets (in the on-screen stats) stay between say 0.35 and 0.65 then the frames come into PresentImage with the proper timing in relation to vsync. As long as the # of adjustments (on-screen stats too) doesn't change, you are already in sync and nothing needs to be done so you won't see any difference. It's when the video and the display refresh get too far out of sync (Delay gets too close to 0.0 or 1.0) that the algorithm kicks in.

I've only done some basic testing with some avi files, a DVD and a blu-ray movie but those work fine here on two different computers.

VMR9 is really not a bad renderer if you handle it with care :-)
-A

[rack04]

See to it that your display refresh rate is an exact multiple of the frame rate of the video.

What and how do I set the display refresh rate for 23.976 fps video?

[ar-jar]

What and how do I set the display refresh rate for 23.976 fps video?

It depends on your display. My test setup has a HDTV display that accepts a 47.95 Hz refresh rate which works fine with 23.976 video. Some newer displays and projectors accept straight 23.976 Hz.

I use Powerstrip to set the refresh rate. Or you can use the graphics board's control panel to create a custom resolution. Not all displays can handle this refresh rate though. -A

[clsid]

To get EVR on Windows XP all you need to do is install Microsoft .NET 3.5.

[tetsuo55]

If the Delay values in the brackets (in the on-screen stats) stay between say 0.35 and 0.65 then the frames come into PresentImage with the proper timing in relation to vsync. As long as the # of adjustments (on-screen stats too) doesn't change, you are already in sync and nothing needs to be done so you won't see any difference. It's when the video and the display refresh get too far out of sync (Delay gets too close to 0.0 or 1.0) that the algorithm kicks in.

I've only done some basic testing with some avi files, a DVD and a blu-ray movie but those work fine here on two different computers.

VMR9 is really not a bad renderer if you handle it with care :-)
-AYeah once every so often adjustments increases. (using 25p content on a 85hz screen)

[ar-jar]

Yeah once every so often adjustments increases. (using 25p content on a 85hz screen)

That's never going to work I'm afraid. 25p on a 75 Hz would be fine; screen refresh rate must be an even multiple of video fps to start with. My patch can only do fine-tuning. Sorry.
-A

[Casshern]

Thanks for this great player,

i will try it tonight but could you elaborate a little on how it works? Before you implemented 2 variantions in gothplayer: 1) adjust powerstrip timings or 2) adjust audio clock. I guess its the latter you implemented here. Does this have implications for spdif output at a near exact multiple of the source frame rate? Do the shaders still work?

regards,

casshern

[ar-jar]

To get EVR on Windows XP all you need to do is install Microsoft .NET 3.5.

I think I must have installed .NET 3.5 when I upgraded to VS 2008 because now my filter manager actually reports that I have EVR installed! So it goes! Thanks for that clue clsid!
-A

[ar-jar]

Thanks for this great player,

i will try it tonight but could you elaborate a little on how it works? Before you implemented 2 variantions in gothplayer: 1) adjust powerstrip timings or 2) adjust audio clock. I guess its the latter you implemented here. Does this have implications for spdif output at a near exact multiple of the source frame rate? Do the shaders still work?

regards,

casshern

I will update the instructions on my blog when I get more time. Anyway, right now I only do number 2 kind of (number 1 is actually implemented too but as I haven't implemented any settings yet so I just hard-coded number 2 for the time being as it is more universal). It actually inserts a new reference clock into the graph that takes over from the audio renderer so it doesn't use the audio renderer's clock at all. Then it gently tweaks the new reference clock up and down as needed to stay in sync. Like a "Reclock lite". I had to go and check but yes, I'm using SPDIF from the computer to my HarmanKardon receiver in my home cinema setup. It seems to work fine as far as my ears can discern. The audio renderer syncs up to the rate of the reference clock and so does my receiver as it seems. I have watched quite a few movies with this sync on with GothPlayer and never heard any glitches.

I have not touched the actual image presentation code so shaders and most other stuff should work just as before.
-A

[ashlar42]

Tried it yesterday night, with Reclock but disabling vsync correction. Playback seemed smooth.

I honestly don't completely understand the point of this when Reclock exists and works well. Maybe the point is this being open sourced?

In any case, it worked well but I did not do extensive testing, to be honest. One thing I noticed: if I selected DirectSound default renderer (in my case it's an X-Fi) the channel placing in DTS came out wrong. Not so by using Reclock as audio renderer.

[ar-jar]

Tried it yesterday night, with Reclock but disabling vsync correction. Playback seemed smooth.

I honestly don't completely understand the point of this when Reclock exists and works well. Maybe the point is this being open sourced?

In any case, it worked well but I did not do extensive testing, to be honest. One thing I noticed: if I selected DirectSound default renderer (in my case it's an X-Fi) the channel placing in DTS came out wrong. Not so by using Reclock as audio renderer.

I guess the main point is that I absolutely enjoy the intellectual challenge of this. I'm not a professional programmer so this is my sudoku or on-line chess if you wish. If it works for somebody else too, then so much better. If not, I will do this just for fun anyway. And yes, it's open source which is kind of nice.

The development of this solution has been a winding road. I started with a solution that I still consider as the optimal one from a theoretical point of view, one that controls the refresh rate of the display and leaves the filter graph alone. Just like an old fashioned TV. This solution depends on Powerstrip fully supporting the graphics board which is not the case e.g. for the newest NVidia boards. There may also be displays that don't tolerate the tweak. All my four 720p displays work well with it but I have never tested it with a 1080 display (one of those is on the shopping list...). This solution is in the code but not exposed as I haven't implemented any GUI components yet.

The solution that you've tested was just a quick and very simple fix that worked surprisingly well. That's why I have left it in the code. I like simple solutions if they work. I will soon add some GUI stuff that exposes both solutions.

As to the mixing of channels, I don't have any idea, sorry. I have not looked into what a DTS bitstream looks like so I don't know how the channels are tagged and how they can possibly be mixed. How does the regular 1165 build of MPC work in this respect? (It's identical to my build minus the sync stuff.)
-A

[tetsuo55]

That's never going to work I'm afraid. 25p on a 75 Hz would be fine; screen refresh rate must be an even multiple of video fps to start with. My patch can only do fine-tuning. Sorry.
-ABut even at an non-multiple refresh rate the timing would be be better than without the patch?

[ar-jar]

But even at an non-multiple refresh rate the timing would be be better than without the patch?

I doubt that it will do much good in those cases. At least I don't understand why it should. The sample arrival times will be pretty evenly distributed over the whole vsync cycle with or without my code. I think Beliyaals fixes are much more useful in those cases as they seem to skip or duplicate frames in a controlled fashion. (Although I have to admit that I haven't figured out the EVR code yet as I have never worked with EVR before.) -A

[Casshern]

Just tried it and it works pretty good for me. Only one thing: It uses and old DirectX SDK (35) instead of the new 41. This leads to problems on some machines with the shaders and the upscaler. Please update so it uses the 41 dll, like the regular builds (i even copied the d3dx9_41.dll to the same directory as the mpc exe, but it still showed version 35 on the stats screen)

Apart from that: Great work... the adjustments (even when the frequency is a little off - by 0.001) did not seem to lead to audible problems with the spdif streams. So it seems that my amp can handle slight variations in clock.

Its also fantastic that something like reclock is finally open source - sadly james from slysoft stated that reclock will not be developed further. So this is great timing, even if not all features of reclock are implemented. For me - i only use it with exact multiples of the source frame rate - its already good enough. Others might miss some of reclock features like pal speeddown, the adaption to non multiple screen refreshrates, the pitch correction etc...

[ashlar42]

I guess the main point is that I absolutely enjoy the intellectual challenge of this. I'm not a professional programmer so this is my sudoku or on-line chess if you wish. If it works for somebody else too, then so much better. If not, I will do this just for fun anyway. And yes, it's open source which is kind of nice.This is not nice, it's great and I thank you for it. My secret hope is that part of your work finds its way into XBMC. :D

And I totally respect your desire of facing this as an intellectual challenge. I understand the feeling.

This solution depends on Powerstrip fully supporting the graphics board which is not the case e.g. for the newest NVidia boards.This is *bad*. With newest Nvidia cards Powerstrip now means all cards released in the past two years or so. That's a big slice of the market (one of which I'm part...) and it's a shame, considering Nvidia has done many things pretty well, with CUDA, OpenGL support, etc. There may also be displays that don't tolerate the tweak. All my four 720p displays work well with it but I have never tested it with a 1080 display (one of those is on the shopping list...).Tried it on a 1080p screen, seemed not to care about the resolution.As to the mixing of channels, I don't have any idea, sorry. I have not looked into what a DTS bitstream looks like so I don't know how the channels are tagged and how they can possibly be mixed. How does the regular 1165 build of MPC work in this respect? (It's identical to my build minus the sync stuff.)I'm using regular 1164 and there weren't problems. Unless 1165 regressed somehow, I think it depends on your stuff.

[ar-jar]

Just tried it and it works pretty good for me. Only one thing: It uses and old DirectX SDK (35) instead of the new 41. This leads to problems on some machines with the shaders and the upscaler. Please update so it uses the 41 dll, like the regular builds (i even copied the d3dx9_41.dll to the same directory as the mpc exe, but it still showed version 35 on the stats screen)


Great that it worked for you too! The DS audio renderers seem to accept a speed shift of <= 0.5% or so. And at least your and my receiver too. So it's not good enough for PAL down-shift but it's good enough to fine-tune the graph clock.

I'm trying to figure out where to put the sync code in the EVR presenter but to paraphrase Bowman in 2001, "it's full of threads", and I need to wrap my brain around it some more.

I actually downloaded the old SDK according to the build instructions when I started this tweak. I always use the latest one for my other stuff. i think some files were moved out of the SDK after 35 so I probably need to go include-file hunting when I upgrade. But I'd be happy to delete the old stuff from my HD and use the new version if that's what the MPC folks use already. -A

[travolter]

I use an avisynth script for interpolate frames (framerate doubler).. and In this way I really notice the difference. (playing 30fps movies at 60fps into my 60hz monitor have a "Live" effect in all these videos)

Could be possible implement a framerate doubler into your proyect?

[pirlouy]

I use an avisynth script for interpolate frames (framerate doubler)..
Can you give a link to it please (with plugin versions needed) ?
TIA

[ar-jar]

I use an avisynth script for interpolate frames (framerate doubler).. and In this way I really notice the difference. (playing 30fps movies at 60fps into my 60hz monitor have a "Live" effect in all these videos)

Could be possible implement a framerate doubler into your proyect?

I know what you mean with "live". I have an AVCHD camera that records 1080i material with 50fps. I play it with the Cyberlink h.264 decoder which actually produces 50 *different* frames per second out of those 50 fields which gives a very fluid motion.

As to our question, do you mean a real interpolating framerate doubler like the one you refer to or the ones in some new TVs and projectors and that works for non-interlaced material? (For interlaced material you could use the Cyberlink decoder which gives you pretty much what you want and works with MPC - with some aspect ratio issues though.) The question is where to get the algorithm. Such a function is bound to be non-trivial. Are you aware of any open source code that implements it? Is the avisynth plugin open source? How fast is the plugin? Does it process frames in real-time?

Ideally there could already be a Directshow filter that implements this. But if not, and if I get my hands on a fast enough algorithm, I could give it a try when done with the the renderer stuff. -A

[tetsuo55]

I know what you mean with "live". I have an AVCHD camera that records 1080i material with 50fps. I play it with the Cyberlink h.264 decoder which actually produces 50 *different* frames per second out of those 50 fields which gives a very fluid motion.

As to our question, do you mean a real interpolating framerate doubler like the one you refer to or the ones in some new TVs and projectors and that works for non-interlaced material? (For interlaced material you could use the Cyberlink decoder which gives you pretty much what you want and works with MPC - with some aspect ratio issues though.) The question is where to get the algorithm. Such a function is bound to be non-trivial. Are you aware of any open source code that implements it? Is the avisynth plugin open source? How fast is the plugin? Does it process frames in real-time?

Ideally there could already be a Directshow filter that implements this. But if not, and if I get my hands on a fast enough algorithm, I could give it a try when done with the the renderer stuff. -AIf such an algorythm is ever added, i hope it will have the option to do Any > 60

[Mark_A_W]

Ar-Jar

Will this MPC-HC version work with multi monitors? How about a secondary monitor?

[ar-jar]

Ar-Jar

Will this MPC-HC version work with multi monitors? How about a secondary monitor?

Yes, that is the objective. I believe the clock sync implemented in the first prototype already works on any monitor (with a refresh rate close enough to the video fps). If not, pls let me know. -A

[travolter]

framerate doubling

Can you give a link to it please (with plugin versions needed) ?
TIA

first tutorial here:
http://forums.guru3d.com/showthread.php?t=288017

then other guys at other forum improved the script

http://www.avsforum.com/avs-vb/showthread.php?t=719041&page=98

follow next pages

you will need ffdshow with avisynth script support installed, also MVtools and avisynth...

also need to replace some files after install...
http://www.megaupload.com/?d=NLHQUV3R

Delete the avisynth.dll and mt.dll and put these versions in their place.
Rebbot after you put these new plugins in their folders:
system32 foldr has the avisynth.dll
avisynth plugins folderr has the mt.dll

PLZ if anyone have updates about these framerate doubling pryects. .let me know.. Im would love see some players with this feature enabled.. like the old crystal player

[travolter]

As to our question, do you mean a real interpolating framerate doubler like the one you refer to or the ones in some new TVs and projectors and that works for non-interlaced material?
exactly same technology of these Flat TV planels.. "truemotion" and similar names

The question is where to get the algorithm. Such a function is bound to be non-trivial. Are you aware of any open source code that implements it? Is the avisynth plugin open source?

check my post above for links. Free proyect... so GPL or Opensource I suppose




How fast is the plugin? Does it process frames in real-time?

Im playing all my 1080 videos with the script real time.
Oh man! .,. the movies look amazing. The eye can follow the movement without any jump.. and always with a feeling of "live motion"

Im using a quadcore processor (about 50% of cpu usage).. but other guys are doing it in dual cores without problems


the script that Im using currently is this one: gives me enough quality and not so much CPU usage.. (you can change parameters there to impreve quality but consume more CPU)

SetMTmode(2,3)
last=ffdshow_source()
super=MSuper(pel=1, hpad=8, vpad=8, chroma=true)
backward_vec=MAnalyse(super, blksize=16, chroma=false,\
search=3, searchparam=1, isb = true)
forward_vec=MAnalyse(super, blksize=16, chroma=false,\
search=3, searchparam=1)
MFlowFps(super, backward_vec, forward_vec, num=0, mask=0)
distributor()

[ar-jar]

Im playing all my 1080 videos with the script real time.
Oh man! .,. the movies look amazing. The eye can follow the movement without any jump.. and always with a feeling of "live motion"


Thank you for the pointers. I'm not one of those nostalgic types that cling to 24 fps for that "genuine cinema experience" and I have lamented about that arcane fps standard with its built-in judder many times (see e.g. http://www.ostrogothia.com/video/?p=636, with a link to an interesting article at Projector Central). So this all looks very exciting and I will definitely look at it later on. But first I need to finish the renderer sync. -A

[boyumeow]

Hihi, I have encounter a minor (I think) problem on ur tryout build(1165.9001). I could not play file extension .rm and mpc shutdown by itself, while rename it to .rmvb plays normally. Revert back to r1164 play on both extensions normally. r1165 on svn shows update on translation language, so shouldn't be a problem if I m not wrong. Btw my file extension for .rm was set to RealMedia, .rmvb was DirectShow. My window environment is Vista32, EVR custom (try out VMR9 renderless, same thing happens). Thanks.

Forget to remind U something, enjoy ur holidays, hehe.

[flanger216]

Thank you for the pointers. I'm not one of those nostalgic types that cling to 24 fps for that "genuine cinema experience" and I have lamented about that arcane fps standard with its built-in judder many times (see e.g. http://www.ostrogothia.com/video/?p=636, with a link to an interesting article at Projector Central). So this all looks very exciting and I will definitely look at it later on. But first I need to finish the renderer sync. -A

It's not that we're being nostalgic; we just feel that, if a movie were shot in 24fps, it should be displayed at 24fps, just like if a movie were shot in black & white, it shouldn't be colorized. When you upsample 24fps to 60fps, at least 60% of every image that hits your visual cortex is an interpolated guesstimation (with some algorithms, it's actually 100%!), and with most of the current methods, a sizeable chunk of those new frames are just distorted junk. I mean, home-video enthusiasts have been clamoring for 24fps playback for years, and now that we've got it, it's like all-of-sudden we're clamoring to interpolate everything into a smeary mess all over again. Obviously YMMV is in play here, but to my eyes, Truemotion and the like are a lot like oversharpening, or pushing the contrast, or boosting the reds: it gives a great first impression, but if you really focus on the effect, it comes off as hideously artificial.

But yeah, the 24fps standard needs to go. Us cinematographers have been pushing for Maxivision-48 for years (a 48fps film system), and there's really no excuse for 24fps now that the digital revolution is in full swing.

[and, of course, 'art-house' stuff looks particularly preposterous when fed through these interpolators]

[tetsuo55]

Unless you have a player and a display that can perfectly switch between 24,25,30,50 and 60 hz one needs to find a solution that results in the least jitter and tearing.

I have an equal mix of all 5 formats + for gaming the desktop has to be in 60p mode.

In my case any-to-60 would be the best solution

[pirlouy]

Personnally, I have chosen 50Hz.
Reclock plays film at 25fps, and game at 50Hz is enough.

@ar-jar: like some others, I use EVR and not VMR9. I have some problems with VMR9 (maybe due to 7), so if you are ready to port your code to EVR, it would be great to test.

[Casshern]

I actually downloaded the old SDK according to the build instructions when I started this tweak. I always use the latest one for my other stuff. i think some files were moved out of the SDK after 35 so I probably need to go include-file hunting when I upgrade. But I'd be happy to delete the old stuff from my HD and use the new version if that's what the MPC folks use already. -A



Any news on compiling with the new SDK? I would love to finally ditch reclock (as i exclusively use exact frequency multiples), but with the old SDK i cannot use the shaders (Chroma Upsampling) without severe juddering. This was the same with the regular build until the devs used the new SDK....

[ar-jar]

Any news on compiling with the new SDK? I would love to finally ditch reclock (as i exclusively use exact frequency multiples), but with the old SDK i cannot use the shaders (Chroma Upsampling) without severe juddering. This was the same with the regular build until the devs used the new SDK....

_xxl seems to be working on it. I'll let you know. -A

[Casshern]

_xxl seems to be working on it. I'll let you know. -A

Cool! How about adding some options? For example to turn the sync code on/off. Maybe even so that reclock is prevented from loading when your code is active - this could be done just by having a second audio renderer selection box when your code is enabled. There one could just use the default audio renderer.....

The best thing about your code is that it - in theory - makes the vsync position slider obsolete in reclock, as you have the renderers knowlege about scanlines/vsync positions. This would mean no more vsync adjustments for different filter chains and smooth playback from the get go (without any pause/play hassels or bad vsync positiions stutter when the vsyncs occur in the "critical" area). Can't wait for the day....

[tetsuo55]

kierank fixed the problem, the wiki already contains instructions to get the directx SDK problem out of the way.
Using any platform SDK version has also been cracked, but not yet updated on the wiki

[Kaotech]

Hello, this version work very well, but in your site you say "The Delay parameter should stay close to 0.5." My delay parameter move during playing movie. How can i fix it ?

http://img149.imageshack.us/img149/9602/goth.png

[ar-jar]

Hello, this version work very well, but in your site you say "The Delay parameter should stay close to 0.5." My delay parameter move during playing movie. How can i fix it ?

If it moves between say 0.35 and 0.65 then you're fine. If it's all over the place, then you may not have a display refresh rate that is an even multiple of your video fps. -A

[Mark_A_W]

Cool! How about adding some options? For example to turn the sync code on/off. Maybe even so that reclock is prevented from loading when your code is active - this could be done just by having a second audio renderer selection box when your code is enabled. There one could just use the default audio renderer.....

The best thing about your code is that it - in theory - makes the vsync position slider obsolete in reclock, as you have the renderers knowlege about scanlines/vsync positions. This would mean no more vsync adjustments for different filter chains and smooth playback from the get go (without any pause/play hassels or bad vsync positiions stutter when the vsyncs occur in the "critical" area). Can't wait for the day....


As there is no other KS/Wasapi renderer, why would you want to disable reclock completely?

You can just set it to Slave/Original Speed/Locked and resampling is disabled, but you still get the best audio renderer.



And, umm, to tell you the truth guys, I'm getting smoother playback with madVR and Reclock active. But I'm still playing around.

[KornX]

can the display output (values eg) be dumped in a *.log?

<Offtopic>
@kaotech
mmh think ive seen this movie,
but I can't think of the name...
Sth. with "The ..."?
</Offtopic> ;)

KornX

[ar-jar]

There is a new version of the patch that claims to synchronize your video to your display (and now also vice versa). It can be found here: http://www.ostrogothia.com/video/?page_id=1050. There is a change log and known issues at the bottom of the page for those of you who like the fine print. Please report any issues on this thread and I'll try to respond and fix (if fixable) asap. Hope it works for you as well as it works for me (of some reason software always works better in the development environment than when it hits the reality :-)).

[ar-jar]

can the display output (values eg) be dumped in a *.log?

Currently no. What would you like to analyze? Maybe it can be done some other way. Also please check out the new patch version with much better on-screen statistics. -A

[pirlouy]

I just did a test yesterday evening, with EVR custom, and my TV in 24Hz, and it was the first time I had no jerk in 24Hz.

I'll do more tests in some days but it looks very promising.

[Kaotech]

<Offtopic>
@kaotech
mmh think ive seen this movie,
but I can't think of the name...
Sth. with "The ..."?
</Offtopic> ;)

KornX

Final Destination 2 ;)

[mariner]

Greetings ar-far. Many thanks for the brilliant piece of work.

Some observatins after testing the following 1080i H264 file on single core CPU with HD3650 AGP card runnibng XP3.

1. Doesn't work well running in normal full screen (not D3D). Enabling Alternate VSync seems to help.
2. The OSD reports 29.970/Progressive. Why not interlaced? FYI, uisng Arcsoft Decoder in DXVA/VA de-interlacing mode.
3. Can you also display the actual frame rate as well? In my test environment, refresh rate reported by PStrip was 59.996.

Many thansk and best regards.

http://drop.io/hidden/mbrbkguvrfoufa/asset/c2xpY2llcy1udHNjLTEwODBpLWgtMjY0LXRz

[Casshern]

There is a new version of the patch that claims to synchronize your video to your display (and now also vice versa). It can be found here: http://www.ostrogothia.com/video/?page_id=1050. There is a change log and known issues at the bottom of the page for those of you who like the fine print. Please report any issues on this thread and I'll try to respond and fix (if fixable) asap. Hope it works for you as well as it works for me (of some reason software always works better in the development environment than when it hits the reality :-)).

As i read from the log its also compiled with the new Dx SDK - great - will try it tonight....

[mariner]

Here's another test of 1080i VC1 file in EVR D3D Full Screen mode, again using Arcsoft Video Decocder.

1. Is the green line supposed to be straight? (The glitch is probably due to pressing Alt Print Screen)
2. While the frame rate is now reported correctly as 59.940 interlaced, isn't it supposed to be speeded up to 59.996 to match the actual refresh rate?

Best regards.

[JonasNo]

gothsync patch 1.2.1173.9003 results:
-gothsync uses slightly more cpu then the provided version without gothsync
-gothsync stabalizes the video play better, with some more work/tweeks it will be a good addition to mpc-hc
-issue, the 'control sync offset' can sometimes display a very big number, that continues off the screen, see gothsync_9003_stats_bug.JPG
-issue, the green line keeps on moving when paused
-issue, the 'sync offset' keeps on updating when paused
-issue, moving the player from one screen to another:
1. while still playing: sometimes crash, sometimes continue playing but no sound or video, partial hang
2. pausing before moving it to another screen and then unpause, will make it crash

But mpc-hc have always had some issues with moving from one screen to another, like hanging, miss-coloring the video (wmv), video skipping, etc....

One weird thing that always happens when moving the player from one screen to another is this, look at the graph, see gothsync_9003_moving to another screen.JPG
if i move the player back to the first screen doesn't fix it,
the workaround is the reopen the video

this is how the graph normally looks on my computer:
see gothsync_9003_normal_graph.JPG

ar-jar, nice work indeed, i am eagerly awaiting the patch file so i can study your nice work

[ar-jar]

Greetings ar-far. Many thanks for the brilliant piece of work.

Some observatins after testing the following 1080i H264 file on single core CPU with HD3650 AGP card runnibng XP3.

1. Doesn't work well running in normal full screen (not D3D). Enabling Alternate VSync seems to help.
2. The OSD reports 29.970/Progressive. Why not interlaced? FYI, uisng Arcsoft Decoder in DXVA/VA de-interlacing mode.
3. Can you also display the actual frame rate as well? In my test environment, refresh rate reported by PStrip was 59.996.

Many thansk and best regards.



1. Could you pls describe in what way it doesn't work well.
2. Not sure to be honest. I left that piece of information there from MPC-HC standard build.
3. I can do that. I'll make a note of it for the next build.

Your setup in images two seems to work ok with everything in sync. A refresh rate of 29.97 should be possible to sync up to a 60 Hz display. The video will be speeded up slightly (0.1%) on average. The default value for the cycle time adjustment constant of 0.0012 is designed to be large enough to handle that case (and e.g. 23.975 to 24.0). I appreciate your feedback! -Arto

[ar-jar]

gothsync patch 1.2.1173.9003 results:
-gothsync uses slightly more cpu then the provided version without gothsync
-gothsync stabalizes the video play better, with some more work/tweeks it will be a good addition to mpc-hc
-issue, the 'control sync offset' can sometimes display a very big number, that continues off the screen, see gothsync_9003_stats_bug.JPG
-issue, the green line keeps on moving when paused
-issue, the 'sync offset' keeps on updating when paused
-issue, moving the player from one screen to another:
1. while still playing: sometimes crash, sometimes continue playing but no sound or video, partial hang
2. pausing before moving it to another screen and then unpause, will make it crash

ar-jar, nice work indeed, i am eagerly awaiting the patch file so i can study your nice work

Thanks Jonas! Moving the player across screens is a known "challenge". It is fixable I think but requires some deliberation in the cases when sync is on.

I've also noticed that things move in paused state which is funny. i haven't given that issue priority yet.

I'll look into the "big number issue". I assume it goes away when you do CTRL+ALT+R (reset statistics)?

I'm awaiting a moderator approval of your attached images to see what they look like. I hope that the green and the red line stay roughly parallel.

-A

[Casshern]

There is a new version of the patch that claims to synchronize your video to your display (and now also vice versa). It can be found here: http://www.ostrogothia.com/video/?page_id=1050. There is a change log and known issues at the bottom of the page for those of you who like the fine print. Please report any issues on this thread and I'll try to respond and fix (if fixable) asap. Hope it works for you as well as it works for me (of some reason software always works better in the development environment than when it hits the reality :-)).

I tried it now:
1) the shaders are working again, thanx to sdk 41 - great work
2) SP/DIF output desyncs over time, so your findings that the current method to change the clock doesn't work with SP/DIF is sadly true. This is most likely the reason why ago drops/repeats ac3/dts packets. Unfortunately I need this, and do not want to go the decode-analog or decode-reencode way. I hope you find a way around that or do it the reclock way.

3)Syncing the display to video, gave wierd results. It detected the refreshrate correctly as 47.952 from Powerstrip (system said 60hz - framerate of movie was 23.976) but it did way to many corrections (defaults). The old gothplayer did not do that. Something is wrong here - could you maybe explain in more detail what stat from the stats display corresponds to the options, and how this should normaly work. I got 1 adjustment every half a second which can't be right. Also is did exhibit problems with the sony vwl 60 (tried both colum and row). but i have the feeling if you would also provide an option to change the main clock in powerstrip _(instead of row or column), this should work without glitches. I tried in powerstrip and the sony then does not glitch.

thanks again for the great work!

[ar-jar]

2) SP/DIF output desyncs over time, so your findings that the current method to change the clock doesn't work with SP/DIF is sadly true. This is most likely the reason why ago drops/repeats ac3/dts packets. Unfortunately I need this, and do not want to go the decode-analog or decode-reencode way. I hope you find a way around that or do it the reclock way.

3)Syncing the display to video, gave wierd results. It detected the refreshrate correctly as 47.952 from Powerstrip (system said 60hz - framerate of movie was 23.976) but it did way to many corrections (defaults). The old gothplayer did not do that. Something is wrong here - could you maybe explain in more detail what stat from the stats display corresponds to the options, and how this should normaly work. I got 1 adjustment every half a second which can't be right. Also is did exhibit problems with the sony vwl 60 (tried both colum and row). but i have the feeling if you would also provide an option to change the main clock in powerstrip _(instead of row or column), this should work without glitches. I tried in powerstrip and the sony then does not glitch.

thanks again for the great work!

Hi,
About 2): I guess the situation with SPDIF could be analog with the situation with video over HDMI. Displays are supposed to extract their pixel clock from the sync pulses of the video and can often tolerate a certain amount of variability in the timing (that's why sync method 2 often works). I think I will throw this challenge out to somebody else who might be interested in working with the renderer too (or with the audio). Clearly a bit of theory and a bit of experimentation is needed.

About 3): You are right about that you should not get adjustments often. I'm running a 23.976 blu-ray movie now on a display that I've managed to tune to 47.951 (closest match with PS w/ my gfx adapter). Over about 10 minutes so far I've had 2 adjustments. You can see the actual (adjusted) frequency in the third row of the full stats. It should change 0.1% or so up or down from your nominal 47.952.

What does the green line look like? Is it smooth at around 10 ms (one notch up from the middle). What about the red (the sync pulse)?

What do they look like w/o sync? (They should stay pretty must steady.)

Do you start your player on the same display that you run fullscreen on? (You should.)

What's your target sync offset and control limit (defaults are 10 and 2 ms)? Too narrow control limit gives too frequent adjustments.

The main clue here are what the lines look like in the statistics graph. The graph spans a few secs of video and you should see the reason for and the effect of the adjustments there.

I could give you the pixel clock adj. option too. I've never got it to work well on any of my computers but it could be an option for somebody. That's a todo...

[Kaotech]

http://img32.imageshack.us/img32/7750/newbuiuld.png (http://img32.imageshack.us/i/newbuiuld.png/)

Hello,

I use powerstrip like you see on the screen, the real refresh rate of powerstrip is : 23,976 the 23,975 is the number i set in advanced timing option to have a real 23,976, you can see it if you clic on the camera (it's the real refresh rate)

Why "The Display refresh rate from application" is not 23,976 ? However powerstrip say 23,976.

Four or five time during playing movie, i have the screen who bug, picture cut, like a tearing but, isn't it.

What the way to have the best performance with 23,976 video refresh rate, it's a display rate @ 24 or 23,976 ?

[pbmtp]

Hi,

For the SPDIF issue would it be possible to reencode the sound in AC3 as it is done by reclock (decode AC3 using which ever decoder you prefer, reclock does its magic on the multiple PCM, reclock reencode all corrected PCM in AC3, AC3 then passtrough SPDIF).

pb

[mariner]

1. Could you pls describe in what way it doesn't work well.
2. Not sure to be honest. I left that piece of information there from MPC-HC standard build.
3. I can do that. I'll make a note of it for the next build.

Your setup in images two seems to work ok with everything in sync. A refresh rate of 29.97 should be possible to sync up to a 60 Hz display. The video will be speeded up slightly (0.1%) on average. The default value for the cycle time adjustment constant of 0.0012 is designed to be large enough to handle that case (and e.g. 23.975 to 24.0). I appreciate your feedback! -Arto

Greetings ar-jar. Thanks for the reply.

1. Playback in normal full screen stutters if Alt VSync is turned off. You can see the glitches in the first image. The same thing happens in the regular MPC build. I remember beliyaal mentioning in one of his earlier posts having Vsync problem with some ATI cards, and Alt VSync was designed to fix it. Have you come across this problem and does GothSync work with Alt VSync enabled? Appreciate if you could look into this.

2. The OSD reports frame rates of 1080@60i video differently : 29.970/P in VMR9 and 59.940/i in EVR. Perhaps a little consistency would be helpful.

3. Some clarification here. If I understand how GothSync sync method 1 works, the ref clock is manipulated to match the video clock (ala reclock) to achieve smooth playback without dropping/repeating frames. So the nominal video frame rate as reported by windows is correct: GothSync reports 29.970/59.940 and Beliyaal reports 59.996. What I would also like to see is the actual frame rate achieved measured by the unmodified clock, ie the refresh rate reported by PStrip.

Many thanks and best regards.

[JonasNo]

I'll look into the "big number issue". I assume it goes away when you do CTRL+ALT+R (reset statistics)?


No pressing CTRL+ALT+R doesn't fix the big number issue. I have tried several times.
When i drag-drop open another video file sometimes fixes it.

[ar-jar]

[/URL]
I use powerstrip like you see on the screen, the real refresh rate of powerstrip is : 23,976 the 23,975 is the number i set in advanced timing option to have a real 23,976, you can see it if you clic on the camera (it's the real refresh rate)

Why "The Display refresh rate from application" is not 23,976 ? However powerstrip say 23,976.

Four or five time during playing movie, i have the screen who bug, picture cut, like a tearing but, isn't it.

What the way to have the best performance with 23,976 video refresh rate, it's a display rate @ 24 or 23,976 ?

The "application" gets its refresh rate from Windows which doesn't know that you've tweaked it through PowerStrip. PS bypasses Windows.

Not sure what you mean by "screen who bug". What does it look like when you change the front porch manually through Powerstrip? Do you get glitches? Do you get the artifacts when the "Adj delta" parameter is <> 0, i.e. when an adjustment is going on? Do you get these glitches also when you turn off the the sync entirely or only when sync is on?

If you watch 23.976 material then you should set the display refresh as close to that as possible (or, as I do, use 47.95 or so). -A

[ar-jar]

Hi,

For the SPDIF issue would it be possible to reencode the sound in AC3 as it is done by reclock (decode AC3 using which ever decoder you prefer, reclock does its magic on the multiple PCM, reclock reencode all corrected PCM in AC3, AC3 then passtrough SPDIF).

pb

Would you not get about the same thing if you decode with a regular audio decoder and reencode with Dolby Live which outputs SPDIF? The audio renderer syncs to the external reference clock rate and you still get digital output, now in sync. Sounded fine to me but then I decided to skip that re-encoding step and use the analog output from the computer into the receiver which actually gives me many more options than if I decode with my receiver.

Anyway, I will not prioritize the sound issue right now if I don't run into issues with the analog output too. -A

[ar-jar]

Here's another test of 1080i VC1 file in EVR D3D Full Screen mode, again using Arcsoft Video Decocder.

1. Is the green line supposed to be straight? (The glitch is probably due to pressing Alt Print Screen)
2. While the frame rate is now reported correctly as 59.940 interlaced, isn't it supposed to be speeded up to 59.996 to match the actual refresh rate?

Best regards.

Yes, you get glitches when doing things like print screen, pulling up the context menu etc, especially on single core machines.

And yes, the green line is supposed to stay reasonably straight and around the first gridline of the graph, representing 10 ms from the sync pulse (which is the red line that defines 0 in the graph).

The video frame rate on row one of the stats display is the one reported by the video stream itself (I believe, I have actually tried not to touch too much code and this piece fo code is from MPC original). The effective (adjusted) video frame rate will on average be equal to the display refresh rate if the sync works as it should. In your case it should be speeded up to 60 Hz as that seems to be your display refresh. A speed-up of 0.1%. With a cycle time adjustment parameter of 0.0012 (0.12%) that should be possible.

The parameter Actual frame time gives you the the adjusted value of the frame time (and thus 1 / frame time = frame rate) but in your case something fishy has just happened as that frame time corresponds to something like 57 fps instead of 60 fps.

Anyway, as long as the green and the red line stay straight, then you are most likely in sync. -A

[pbmtp]

Hi ar-jar,

Indeed but you need a soundcard compatible with dolby live (which I do not own)

I will see if it is possible to use reclock in "slave reference clock to audio" mode and use its ac3 encoder maybe it will work and will also allow bypassing kmixer.

pb

[ar-jar]

gothsync patch 1.2.1173.9003 results:

-issue, the 'control sync offset' can sometimes display a very big number, that continues off the screen, see gothsync_9003_stats_bug.JPG

this is how the graph normally looks on my computer:
see gothsync_9003_normal_graph.JPG


Now your pics came through too. The big number is because sync is not on and I have forgot to turn off those numbers in the stats display. Probably uninitiated variables that are not used. I have some tidying up left to do in the code.

The "normal" graph looks ugly. The lines should be almost traight and 10 ms apart (on gridline) with the default parameters. Did you move the player between screens before you got that saw toothg. could you please publish a screenshot that shows the other parameters too? -A

[ar-jar]

Greetings ar-jar. Thanks for the reply.

1. Playback in normal full screen stutters if Alt VSync is turned off. You can see the glitches in the first image. The same thing happens in the regular MPC build. I remember beliyaal mentioning in one of his earlier posts having Vsync problem with some ATI cards, and Alt VSync was designed to fix it. Have you come across this problem and does GothSync work with Alt VSync enabled? Appreciate if you could look into this.

2. The OSD reports frame rates of 1080@60i video differently : 29.970/P in VMR9 and 59.940/i in EVR. Perhaps a little consistency would be helpful.

3. Some clarification here. If I understand how GothSync sync method 1 works, the ref clock is manipulated to match the video clock (ala reclock) to achieve smooth playback without dropping/repeating frames. So the nominal video frame rate as reported by windows is correct: GothSync reports 29.970/59.940 and Beliyaal reports 59.996. What I would also like to see is the actual frame rate achieved measured by the unmodified clock, ie the refresh rate reported by PStrip.

Many thanks and best regards.

Hi,

1. Theoretically alternative vsync should work but I'm not sure as to why it is better than to let DirectX do the synchronization of the video buffer flipping and the vertical blank. I have never run into the issues you decribe but then again, I have not tested that many gfx boards. I'm running my code on one NVidia system and one ATI system and both work almost identical wrt to my application. In your gfx control panel, have you checked "let application decide" (or similar) for vsync (you should)? A card that isn't able to sync the video buffer flipping to vsync is imho rather unsuitable for video. The question is whether your board actually exhibits this capability through DirectX. I don't think there is a check in the code for that in the original MPC code. I'll look into that.

2. This code is unaltered from MPC and I haven't really looked into it. I have actually tried not to touch too much code not to break anything before I know how to fix it. But I see your point and yes, it should be fixed.

3. If you leave Powerstrip on when starting the player, you will see the refresh rate as reported by PS. If you do display sync, the refresh rate reported by PS at any given time is the *adjusted* refresh rate (= nominal refresh rate most of the time but <> from it when an adjustment is going on).

-A

[ar-jar]

Hi ar-jar,

Indeed but you need a soundcard compatible with dolby live (which I do not own)

I will see if it is possible to use reclock in "slave reference clock to audio" mode and use its ac3 encoder maybe it will work and will also allow bypassing kmixer.

pb

Hi, I'm eagerly awaiting your results from the reclock test. One of these days I will install it again. I had some very mixed experiences from it several years back and have avoided it ever since. (That, and my need for a smooth playback was also one reason why I picked up programming again after 20 years.) -A

[ar-jar]

Please test your set-up with both syncs turned *off* first. I you are unable to get smooth and almost parallel red and green lines in the stats graph (CTRL+J) with some combination of the "old" sync options on (or none), then GothSync probably won't help. The sync doesn't kick in at every sample to try to fix the timing, it only fixes the timing on average. The player should be able to stay in sync at least several seconds without sync for GothSync to have time to do its tricks. If either your vsync curve (red) or the paint start curve (green) exhibit a clearly visible sawtooth pattern or frequent and random peaks or throughs of more than 10 ms, then you have a poor match to start with. (You could still try to see what happens with one of the GothSync options but the odds for it to work are poor.) Thanks! -A

EDIT: I now recall that I've seen some video streams that alternate between two different sample times (with the correct average sample time). These should show up as a jagged green curve (and potentially as a jagged but synchronized red curve). Anyway, if you have two almost straight lines to start with, then you are probably in good shape and you can blame GothSync if you don't stay in sync. Jagged lines *might* work if they are totally regular.

[mariner]

Tearing issue in GothSync

Greetings ar-jar. Would appreciate if you could look into tearing issue with this 1920x1080@60P H264/AAC .mp4 clip. Doesn't show up in the screen capture, but is present even in D3D FullScreen mode when running tearing test.

On further testing, it appears tearing could have been caused by Alt VSync. There is no trace of tearing in D3DFullScreen when Alt Vsync is turned off.

Many thanks and best regards.

http://www.sanyo-dsc.com/products/lineup/dmx_hd2000/img/sample/movie_sample_hd2000_01.zip

[ar-jar]

Tearing issue in GothSync

Greetings ar-jar. Would appreciate if you could look into tearing issue with this 1920x1080@60P H264/AAC .mp4 clip. Doesn't show up in the screen capture, but is present even in D3D FullScreen mode when running tearing test.

On further testing, it appears tearing could have been caused by Alt VSync. There is no trace of tearing in D3DFullScreen when Alt Vsync is turned off.

Hi Mariner, I don't seem to be able to play your clip at all with MPC. It doesn't show any video, only sound. I've tried with three different builds of revision 1173, including two that I built myself and the one from xvidvideo.ru. I've tried several renderers and configs. I haven't tried with external filters.

I can play the clip with Windows Media Player, Zoom Player and GothPlayer. ZP and GP both use the Cyberlink H.264/AVC DXVA decoder that I have installed (an excellent decoder). Media Player looks good in both windowed and full-screen (don't know which renderer). ZP stutters severly in VMR9 renderless full-screen (which I bet is non-exclusive). GP stutters exactly like ZP (probably an identical filter graph) in VMR9 full-screen non-exclusive but plays fine in full-screen exclusive mode.

Which MPC build, filters and renderer do you use to play the clip?

-A

[mariner]

MPC's internal decoder has been broken since build 1043. Unfortunately Casimir was in no hurry to fix it. You will need either PDVD8 or Arcsoft decoder for DXVA playback. Over here, the Acrsoft did not like VMR9 renderless, would appreciate if you could test it out if you have access to it.

http://forum.doom9.org/showpost.php?p=1289246&postcount=7962
Sorry it's more complicated than a transparency problem, this bug will not be fixed for the moment.


For some unknown reasons, MPC's internal MP4 splitter reports 59.937 fps while all others splitter (Haali, Arcsoft, Cyberlink) reports 59.94.

Another bug I noticed: frame rate of some 1080/60i clip as reported as 23.976 in VMR9 renderless.

Best regards.

[tetsuo55]

MPC's internal decoder has been broken since build 1043. Unfortunately Casimir was in no hurry to fix it.This bug has the highest priority.
But Casimir has limited time, having a life and all, and the fix is very time consuming(fix one thing break another).

[ar-jar]

MPC's internal decoder has been broken since build 1043. Unfortunately Casimir was in no hurry to fix it. You will need either PDVD8 or Arcsoft decoder for DXVA playback. Over here, the Acrsoft did not like VMR9 renderless, would appreciate if you could test it out if you have access to it.

http://forum.doom9.org/showpost.php?p=1289246&postcount=7962

For some unknown reasons, MPC's internal MP4 splitter reports 59.937 fps while all others splitter (Haali, Arcsoft, Cyberlink) reports 59.94.

Another bug I noticed: frame rate of some 1080/60i clip as reported as 23.976 in VMR9 renderless.

Best regards.

I only have access to the Cyberlink/PDVD8 decoder (which has performed flawlessly with VMR9 until I tried to play your mp4 file). Your file plays fine with EVR D3D full-screen on my player with the Cyberlink decoder. My patch is able to sync it to 10 ms sync offset as it should. When I then try to play it with VMR9 it fails or stutters. After that not even EVR will work again until I reboot. The VMR9 attempt seems to leave an un-reset failed state somewhere. I need to test this a bit more.

Anyway, I have so far only looked at the MPC code that I've needed for my sync mechanisms, not much else. So I'm not yet in a position to fix bugs in the regular builds of MPC. Please report any failures in the regular builds as potential bugs at SourceForge if you haven't already. And please report any failures that only appear in my patch build here and I will look at them asap.

About the numbers: My guess would be that the 59.937 / 59.94 is just a question of rounding (but I'm not sure).

23.976 fps is reported by MPC when it can not extract a frame rate from the video stream. Some decoders such as at least older versions of the Cyberlink MPEG2 decoder always report 0 fps which will thus be reported as 23.976 by MPC. Maybe 0 would be less confusing(?) -A

[mariner]

Greetings ar-jar. Not sure why you're having problem with PDVD8 decoder. The combinaaion of Haali/PDVD8/VMR9Renderless works well here in DXVA mode usig latest MPC_GothSync. Here is a summary of testing :

1. FUllScreen VMR9Renderless with Alt VSync ON: stutter free but with tearing.
2. D3DFUllScreen VMR9Renderless with Alt VSync ON: stutter free but with tearing.
3. FUllScreen VMR9Renderless with Alt VSync OFF: stutter but no tearing.
4. D3DFullScreen VMR9Renderless with Alt VSync OFF: stutter and tearing free.

It seems to me you have found a way to cure both stutter and tearing problems, at least for D3DFullScreen playback. Hopefully with more investigations, the same can be achieved for FullScreen VMR9Renderless and EVR_CP playback.

Many thanks and best regards.

[ar-jar]

In any case, it worked well but I did not do extensive testing, to be honest. One thing I noticed: if I selected DirectSound default renderer (in my case it's an X-Fi) the channel placing in DTS came out wrong. Not so by using Reclock as audio renderer.

One more reply to this now when the new tryout version(s) are out: Please try both MPC versions that I've uploaded to http://www.ostrogothia.com/video/?page_id=1050. Both are built on the same base version of MPC (1173), one with the GothSync additions and one without. Do you get the same mix-up of channels with both player versions? (This is verify that it is my additions that are causing your problems.) See also this blog post regarding the use of SPDIF: http://www.ostrogothia.com/?p=1152. -A

[tetsuo55]

There is a bug with the channels due to the FFmpeg update

[ar-jar]

Greetings ar-jar. Not sure why you're having problem with PDVD8 decoder. The combinaaion of Haali/PDVD8/VMR9Renderless works well here in DXVA mode usig latest MPC_GothSync. Here is a summary of testing :

1. FUllScreen VMR9Renderless with Alt VSync ON: stutter free but with tearing.
2. D3DFUllScreen VMR9Renderless with Alt VSync ON: stutter free but with tearing.
3. FUllScreen VMR9Renderless with Alt VSync OFF: stutter but no tearing.
4. D3DFullScreen VMR9Renderless with Alt VSync OFF: stutter and tearing free.

It seems to me you have found a way to cure both stutter and tearing problems, at least for D3DFullScreen playback. Hopefully with more investigations, the same can be achieved for FullScreen VMR9Renderless and EVR_CP playback.

Many thanks and best regards.

Hi and thanks for the report. Unfortunately I don't get the same behavior. Maybe it depends on the video card and/or operating system (I'm running a low-end ATI card on XP). Anyway, as I said, EVR works fine here with that codec, both with and without D3D full-screen. Maybe that is because the codec does not use DXVA with EVR (XP does not support DXVA2; DXVA1 does not work with EVR). It does use DXVA1 with VMR9 for a mixed result at best.

Notably enough all works fine with that codec and AVCHD files (.mts) from my Sony HandyCam, both in D3D full-screen and regular (windowed) full-screen (the aspect ratio is wrong though as the Sony produces anamorphic frames, which MPC fails to recognize).

What's your OS and video card? Cheers! -A

EDIT: On my machine the combination of Cyberlink and EVR seems to be about the *only* combination that gives a correct output with that file. All other combination (ffdshow and other renderers) seem to have some kind of a problem with the sample timing. Video lags severely and the skips frequently to catch up.

[Kaotech]

Ar-jar, how many ajustement did you have at the end of a movie, i watched a movie yesterday, at the end i see 160 ajustement, with my problem of picture who tear like tearing.

I can't load ffdshow raw video filter, and you ?

I use the same config :

http://img32.imageshack.us/img32/7750/newbuiuld.png

[webs0r]

Hi,

I seem to get better sync on the plain build.

Can I ask, what does it mean when my green line slowly drifts towards the red line, then as it nearly touches the red line, it jumps back up a little and then continues to slowly drift down.

Thanks

[tetsuo55]

Hi,

I seem to get better sync on the plain build.

Can I ask, what does it mean when my green line slowly drifts towards the red line, then as it nearly touches the red line, it jumps back up a little and then continues to slowly drift down.

Thanksdoes your video refresh rate match the display refresh rate?

[ar-jar]

Hi,

I seem to get better sync on the plain build.

Can I ask, what does it mean when my green line slowly drifts towards the red line, then as it nearly touches the red line, it jumps back up a little and then continues to slowly drift down.

Thanks

It means either that you don't have any sync option on or that the adjustment parameter is too small or that the discrepancy in display and video frequencies is too large. Try video sync first (it's the easies one to get to work but doesn't work for live sources such as TV) and see to it that your display and video rates are less than 0.12% apart (for the default adjustment parameter of 0.0012). When in sync, the lines should stay roughly parallel. The good thing is that if you have a slow drift, then you're close and there is hope. If you have jagged lines, the the odds are worse. -A

[mariner]

Greetings ar-jar.

All testings so far are done on an old single core pentium4 CPU with HD3650 AGP graphics card running XP3. Software decoding is not possible due to hardware limitation.

The clip plays smoothly in normal FullScreen using VMR7 and VMR9 windowed. D3D FullScreen is required to eliminate stutter with VMR9 Renderless.

The Sanyo clip is recorded in 1080/60P, currently the only camcorder capable of that. All other models record in either 1080/60i or 30p.

Two questions:
1. Does MPC_GothSync work well in Vista?
2. Can it be set up to do 24fps to 25fps speedup, as in reclock?

Many thanks and best regards.

Edit: I notice your are using the HD3450 card. Perhaps if you turn off DXVA in the cyberlink decoder, you could get it to run in VMR9 Renderless.

[webs0r]

does your video refresh rate match the display refresh rate?

Thanks for the help Tetsuo & ar-jar.

I can get perfect sync when my source=25fps and refresh=50Hz.

I get this drifting occurring when my source=30fps (29.97, with reclock moving it to 30fps) and refresh=60 Hz.

I've tried fiddling with different options but cannot seem to get a flat line with 30 fps content. Wonder if I'm missing something basic...

[ar-jar]

Thanks for the help Tetsuo & ar-jar.

I can get perfect sync when my source=25fps and refresh=50Hz.

I get this drifting occurring when my source=30fps (29.97, with reclock moving it to 30fps) and refresh=60 Hz.

I've tried fiddling with different options but cannot seem to get a flat line with 30 fps content. Wonder if I'm missing something basic...

Hi, I have not done any testing together with reclock. Which sync mechanism do you use (video or display)? With display sync your set-up should work. With video sync I doubt it. I believe my mpc and reclock will end up fighting about who gets to be the reference clock. If you connect to the filter graph in graphedit or graphstudio while mpc is playing, which filter has a yellow clock on it? (Only relevant if you use "sync video to display".) -A

[ar-jar]

Thanks for the help Tetsuo & ar-jar.

I can get perfect sync when my source=25fps and refresh=50Hz.

I get this drifting occurring when my source=30fps (29.97, with reclock moving it to 30fps) and refresh=60 Hz.

I've tried fiddling with different options but cannot seem to get a flat line with 30 fps content. Wonder if I'm missing something basic...

You could try this also if you are using the "sync video to display" option. Turn off reclock entirely (check so that it is not in the filter graph). As the difference in frequency is only 0.1%, the sync mechanism should be able to speed your media up to match 30 / 60 Hz with the frequency adjustment parameter set to 0.0012 (= 0.12%). You could set it to 0.0015 (0.15%) to on the safe side. See what happens! -A

[ar-jar]

Ar-jar, how many ajustement did you have at the end of a movie, i watched a movie yesterday, at the end i see 160 ajustement, with my problem of picture who tear like tearing.

I can't load ffdshow raw video filter, and you ?


160 adjustments is fairly normal. If everything has worked out, it means that you have avoided 160 glitches in the video :-)

I have no experience of the ffdshow raw filter. Please check if you have the same undesired behaviour in the unpatched version of MPC.

If you get tearing in full-screen mode, please try to turn on D3D Fullscreen in the MPC options. (You can quit the player with ALT+X when in D3D Fullscreen mode or turn on the "D3D Fullscreen GUI Support" from the context menu -> Renderer Settings -> Presentation -> for the regular context menu to work.) -A

[Keiyakusha]

ar-jar
Since downloading speed from your site is somewhat slow (around 10kbps for me...), is it possible to put executables in some archive? In 7z for example mplayercgs filesize will be 3 times lower. Thanks.

[ar-jar]

ar-jar
Since downloading speed from your site is somewhat slow (around 10kbps for me...), is it possible to put executables in some archive? In 7z for example mplayercgs filesize will be 3 times lower. Thanks.

I have now 7-zipped and uploaded the player(s) to my account at my ISP instead. Please go back to the download page again, klick on the link(s) and tell me how it works! -A

[Keiyakusha]

I have now 7-zipped and uploaded the player(s) to my account at my ISP instead. Please go back to the download page again, klick on the link(s) and tell me how it works! -A

Thanks! It really helps. Now it takes one second to download it. :eek:

[boyumeow]

Hi ar-jar, just wonder could U include ur patch in the 7z. Thanks.

[ar-jar]

Hi ar-jar, just wonder could U include ur patch in the 7z. Thanks.

Ok, I will do that with my next build. I have now figured out what my problem with building patches was (I think). It's going to take a while though because I want to do quite a bit of restructuring before the next patch and things will be broken in the mean time. -A

[Kaotech]

Deleted Post

[Abnormal1]

I was wondering if it would be possible for mpc-hc to auto change the refresh rate based on the fps. mpc-hc already has the ability to change the display settings so may not be to much work.

I'm not sure how it would work with the people who use powerstrip and method 2 but method 1 should be possible to have auto change the refresh rate.
This would really help me out as i currently have xbmc call mpc-hc on my htpc and so manually changing the refresh rate is a real pain.

Oh and sorry if this has been asked before or is actually possible with current versions, I did read this thread but may have missed it.

[Kaotech]

Another test with last build, in this test i use reclock to convert movie frame @ 24i/s with refresh rate @ 72Hz

Did you got idea, why my stats are like this

http://img232.imageshack.us/img232/4571/24x3.png

movie frame @ 23,976i/s (without Reclock) with refresh rate @ 71,928Hz

http://h.imagehost.org/0448/23_976X3.png


I don't see the reset stats on the new build.

http://h.imagehost.org/0259/reset_stat_dont_display.png

[ar-jar]

I was wondering if it would be possible for mpc-hc to auto change the refresh rate based on the fps. mpc-hc already has the ability to change the display settings so may not be to much work.

I plan to add this as an option for full-screen mode. I dont' think people want their screens to flicker from a refresh rate change if they are just watching something in a window. DirectX supports change of refresh rate for full-screen (have never tried it though). PowerStrip gives even more options if you have a display like mine that syncs to pretty much everything but only reports the standard rates (it's a Philips and has a really robust sync, ideal for experimenting with video players). I plan to add refresh change through PowerStrip too for the more adventurous folks. But I want to make the other stuff more robust before I add more functions. -A

[ar-jar]

Another test with last build, in this test i use reclock to convert movie frame @ 24i/s with refresh rate @ 72Hz

Did you got idea, why my stats are like this

movie frame @ 23,976i/s (without Reclock) with refresh rate @ 71,928Hz

I don't see the reset stats on the new build.

To start with, I have not tested my sync with reclock and I can't predict what happens. It looks like you've got good sync though in your first two screen shots. In the first I believe you actually see the result of an on-going adjustment as the green curve turns back up toward the target value (10 ms?).

You can forget about the yellow line. It's not all that interesting really. I used it for verification purposes and have removed it from later builds (to be published in due time).

Hmm, looks like i lost one menu button when I "manually patched" a new base revision with my stuff some time ago :-) Or maybe I did it on purpose as menus can disturb the sync (can't remember actually). Anyway, I recommend using CTRL+ALT+R for resetting the stats. It still works. -A

[Abnormal1]

I plan to add this as an option for full-screen mode. I dont' think people want their screens to flicker from a refresh rate change if they are just watching something in a window. DirectX supports change of refresh rate for full-screen (have never tried it though). PowerStrip gives even more options if you have a display like mine that syncs to pretty much everything but only reports the standard rates (it's a Philips and has a really robust sync, ideal for experimenting with video players). I plan to add refresh change through PowerStrip too for the more adventurous folks. But I want to make the other stuff more robust before I add more functions. -A

This is actually how I would expect it to work since its how mpc-hc currently deals with changing the display settings.
As in mpc-hc currently changes the resolution and refresh rate when in fullscreen and when you return to window mode it changes the display settings back to the system settings.

Thanks for this.

[ar-jar]

Please try the newest version of the MPC-HC with the GothSync additions. A new (hopefully the last :-)) sync option has been added. My intention is to make it the default sync option if it turns out to be stable. Read more about it at http://www.ostrogothia.com/?p=1337. You can download it here: http://www.ostrogothia.com/?page_id=1213. Thanks! -A

[Casshern]

Please try the newest version of the MPC-HC with the GothSync additions. A new (hopefully the last :-)) sync option has been added. My intention is to make it the default sync option if it turns out to be stable. Read more about it at http://www.ostrogothia.com/?p=1337. You can download it here: http://www.ostrogothia.com/?page_id=1213. Thanks! -A

Did you include the option to change the pixel clock instead of no. of lines when syncing through powerstrip? This could eliminate the artifacts on some displays...

I would love to test that....

[NanoBot]

Hi ar-jar,

The option "Present at nearest vsync" is greyed out here, both in options / synchronisation and in view / renderer settings / vsync. Am I doing something wrong, or is it not intended to work in my environment ? I am using XP Pro SP3, VMR9 and the graphics adapter is a 9600GT.

[ar-jar]

Did you include the option to change the pixel clock instead of no. of lines when syncing through powerstrip? This could eliminate the artifacts on some displays...

I would love to test that....

I didn't include it (yet), I could do that. I have tried it hard-coded though and it did *not* work well on my machine. Maybe yours is different. I'll add it to my todo. -A

[ar-jar]

Hi ar-jar,

The option "Present at nearest vsync" is greyed out here, both in options / synchronisation and in view / renderer settings / vsync. Am I doing something wrong, or is it not intended to work in my environment ? I am using XP Pro SP3, VMR9 and the graphics adapter is a 9600GT.

Hi, you need to select EVR custom presenter as your renderer for this option to work. If you don't find that renderer in the Output options, you
need to install .NET 3.5 which includes EVR. Let me know how it goes. -A

[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

[Jong]

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. -AMaybe tell me what you see or you post a screenshot and I might be able to help. If there is one thing I have spent a lot of time with it is fixing judder with Reclock!

As I mentioned you must use D3D mode with Reclock vsync correction. Then the graph should look like this and stay this way forever:

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

With D3D mode OFF this is the "rolling sync" you normally see due to Reclock continually running at a slightly too fast/slow refresh rate (watch the green line!):

http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_2.jpg
http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_3.jpg
http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_4.jpg
http://jong.pwp.blueyonder.co.uk/images/gs_rollingsync_5.jpg

Obviously you cannot see this graphically with the beliyaal build but you can see it by watching the "present wait" figure, with vsync set "off" (not actuall off!), or "VBlank Wait", with vsync set "ON".

If you turn off DXVA and turn on the Reclock vsync markers you can also see if there is a problem. In the above example the vsync marker will be "pinned" at the top of the screen and will never approach the target zone (Marked by the other two white lines).

[FoLLgoTT]

@ar-jar
Great work! :)

But I have a strange problem. The sync graph is not painted on my HTPC with your tryout and private build. On my other PC with nearly the same configuration everything is correct. I attached a screenshot of the display stats. Do you have any idea?

http://img142.imageshack.us/img142/2360/unbenanntfc.th.jpg (http://img142.imageshack.us/i/unbenanntfc.jpg/)

Configuration:

Windows Vista, ATI 3850, EVR Custom Presenter, Sync video to display

And by the way, should the tearing test work?

[Jong]

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.

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.If you cannot put up with D3D mode I agree. If you can then Reclock vsync is better, or ar-jar's option 1 if you refresh rates are near identical.

On the other hand, ar-jar, it is the buffering in D3D mode that seems to allow Reclock's vsync to work. PowerDVD seems to use [triple?] buffering that allows Reclock vsync to work in VMR9 WITHOUT D3D. If you could implement a renderer like this for MPC-HC it would make Reclock usable by many more people.

[tetsuo55]

@ar-jar
Great work! :)

But I have a strange problem. The sync graph is not painted on my HTPC with your tryout and private build. On my other PC with nearly the same configuration everything is correct. I attached a screenshot of the display stats. Do you have any idea?

http://img142.imageshack.us/img142/2360/unbenanntfc.th.jpg (http://img142.imageshack.us/i/unbenanntfc.jpg/)

Configuration:

Windows Vista, ATI 3850, EVR Custom Presenter, Sync video to display

And by the way, should the tearing test work?did you install the latest directx redist? (link in my signature)

[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

Pls try the new one. I'm off for a few days though so make a note of your bugs and report them to me later when I'm on-line (or on my blog). Thanks! -A

[FoLLgoTT]

did you install the latest directx redist? (link in my signature)

Thanks! After an upgrade to the newest DirectX I can see the sync graph. :)

[tetsuo55]

Pls try the new one. I'm off for a few days though so make a note of your bugs and report them to me later when I'm on-line (or on my blog). Thanks! -ANo difference for the private build i downloaded just now.

[ar-jar]

No difference for the private build i downloaded just now.

Does the last regular build work better? -A

[tetsuo55]

Regular MPC and last stable mpc-hc gothsync are behaving as good as we've got it so far

[ADude]

I assume that when beliyaal replaced the microsoft vsync handler with his own this sort of broke VMR9 for me and introduced the tearing

and

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.

So, evidently in this thread, everyone knows that Beliyaal's code tears.

But if you say so in the MPC-HC thread, then it is heresy and you are kicked out ??

If the concept is to have intelligent technical discussion in this thread, and leave the MPC-HC thread to children who think that a two year old video card is "old and outdated", then someone should have at least said so in a PM, and a lot of trouble would have been avoided...

[Casshern]

Please do not disinform through quoting out of context. I said that beliyaal's "GPU Flush" options fixed the tearing for me with VMR9. Before beliyaal's code VMR9 and DXVA was completely useless on my video card due to severe frame stuttering (wrong buffers being displayed). With "GPU Flush" and VMR9 on everythings works nicely here with beliyaals code - my remark was directed at very early beliyaal builds where he didn't include the gpu flush stuff. I only brought it up here because ar-jay removed some of this code in his experimental builds, so the tearing is back in those builds as the "gpu flush" options have no effect anymore.

Please do never quote me again, as i do not want to waste time answering your troll attempts.


and



So, evidently in this thread, everyone knows that Beliyaal's code tears.

But if you say so in the MPC-HC thread, then it is heresy and you are kicked out ??

If the concept is to have intelligent technical discussion in this thread, and leave the MPC-HC thread to children who think that a two year old video card is "old and outdated", then someone should have at least said so in a PM, and a lot of trouble would have been avoided...

[ADude]

Please do not disinform through quoting out of context. I said that beliyaal's "GPU Flush" options fixed the tearing for me with VMR9. ...

Please do never quote me again, as i do not want to waste time answering your troll attempts.

Oops, sorry for taking you out of context.

Such as the context of other posts where you state that GPU Flush options have caused judder problems, and where Tetsuo55 states they have caused macroblocking problems.

I only brought it up here because ar-jay removed some of this code in his experimental builds, so the tearing is back in those builds as the "gpu flush" options have no effect anymore.

Amazingly parallel to my own statement of " Belliyaal removed some of the code in his experimental builds (that were merged with main version), so the tearing is back in the main version, because he removed the code that parallels ar-jar's ' present at next vsync' ".

So, you want me to respect your statement, but when I say the same thing, it is "trolling".

And I mistakenly thought that perhaps there was some place we could talk just about technical issues, but never mind...

[foxyshadis]

Struck for rule 16. The issue of Baliyaal's vsync code is closed. Any further derailings will be a suspension.

[ar-jar]

If you cannot put up with D3D mode I agree. If you can then Reclock vsync is better, or ar-jar's option 1 if you refresh rates are near identical.

On the other hand, ar-jar, it is the buffering in D3D mode that seems to allow Reclock's vsync to work. PowerDVD seems to use [triple?] buffering that allows Reclock vsync to work in VMR9 WITHOUT D3D. If you could implement a renderer like this for MPC-HC it would make Reclock usable by many more people.

I use triple buffering in my old player in both windowed and exclusive mode. So it's definitely doable but it doesn't work immediately in MPC (did a very quick test). MPC currently uses one backbuffer in windowed mode. If I change that to three (simultaneously doing some other necessary chances that with a single buffer work fine), I won't get any video output. THe reason for this should be relatively easy to find since I have a "correct answer" to look at. The main difference between my old renderer and the MPC renderer is that I render a texture on a "virtual moviescreen" (a 3d object) whereas MPC uses a "strechrect" which I believe is a blt. I'll add this to my todo-list. -A

[mariner]

Greetings ar-jar. Thanks for the kind reply.

1. If you look at the attached capture, it shows that your new vsync option does not produce as clean a result as Casimir's latest build.

2. You may have overlooked my other post 9005 vs 9012. If vsync is set to synchronized video, 9005 will quickly settle on the target refresh rate, but not 9012. So which one is reporting the frame rate correctly?

3. Tearing is still an issue and seems to occur most frequently when playing 24fps content with 24Hz refresh rate. In my case, it appeared near the bottom of the screen, and the position is the same for both your build and Casimir's. Enabling D3DFullScreen is the only way to eliminate it.

Best regards.

[Jong]

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.Seems your system is a bit better than mine!:)

Just did my own similar test and I get 1ms of drift about every 20mins. It happens this drift is always in the same direction on my system (at least today) but I'm sure it could go either way, maybe even on my system another time. Normal variability in presentation is about +/- 1-2ms. So if I use option3 instead of Reclock vsync correction or your option 1 and set the starting offset @10ms (in the middle). It should be about 2 1/2 hours before I get one single dropped frame. Not bad. Trouble is, on my system at least, I very occasionally (once or twice a movie) get presentation shifting out up to 7.5ms. So if it is kept nice and tight on 10ms (as with option 1) I get no glitches. With option 3 I would get maybe a couple. Still at least they would be single frames, not long periods of judder and at least the starting offset is fixed, not random, as without any vsync correction. A huge improvement!

I guess what it shows though is that the drift can vary from system to system and I am sure the peaks will vary depending on on "tied down" the system is. So with anything but option1/option2/Reclock vsync correction some skips are likely. Option 3 is a very good second best, but how good will depends on the speed of drift and the general stability of presentation.

I would recommend this player even to to anyone planning on using Reclock vsync correction.The min/max/av. offset display let's you position the Reclock vsync marker with precision, instead of with educated guesswork!

[Jong]

I use triple buffering in my old player in both windowed and exclusive mode. So it's definitely doable but it doesn't work immediately in MPC (did a very quick test). MPC currently uses one backbuffer in windowed mode. If I change that to three (simultaneously doing some other necessary chances that with a single buffer work fine), I won't get any video output. THe reason for this should be relatively easy to find since I have a "correct answer" to look at. The main difference between my old renderer and the MPC renderer is that I render a texture on a "virtual moviescreen" (a 3d object) whereas MPC uses a "strechrect" which I believe is a blt. I'll add this to my todo-list. -AThis sounds exciting! Great.

[tetsuo55]

Greetings ar-jar. Thanks for the kind reply.

1. If you look at the attached capture, it shows that your new vsync option does not produce as clean a result as Casimir's latest build.

2. You may have overlooked my other post 9005 vs 9012. If vsync is set to synchronized video, 9005 will quickly settle on the target refresh rate, but not 9012. So which one is reporting the frame rate correctly?

3. Tearing is still an issue and seems to occur most frequently when playing 24fps content with 24Hz refresh rate. In my case, it appeared near the bottom of the screen, and the position is the same for both your build and Casimir's. Enabling D3DFullScreen is the only way to eliminate it.

Best regards.Your picture has not been approved yet, can you upload it to imageshack.us or something?

You cannot compare the graph to casimir because the gothsync graph is more revealing.

[Jong]

ar-jar, one, hopefully small, request for your to-do list!

Can you either change to using percentages for the target offset - so 50% would mean 10ms @50Hz and 8ms @60Hz - or allow several figures to be set for different common refresh rates. Quite a lot are using different refresh rates for different media. The first sounds a lot easier and I cannot see the downside, but you may know different!

[Jong]

ar-jar,

could your renderer (VMR9 specifically) have problems with DVD playback (i.e when using DVD Navigator)? I know MAD-VR had/still has issues to do I think with menu transitions etc.

I am getting frequent "lock-ups" trying to play full discs with your player that I do not get with the current trunk build.

[Jong]

ar-jar,

could your renderer (VMR9 specifically) have problems with DVD playback (i.e when using DVD Navigator)? I know MAD-VR had/still has issues to do I think with menu transitions etc.

I am getting frequent "lock-ups" trying to play full discs with your player that I do not get with the current trunk build.It may be just D3D mode. Trying to play a disc in this mode is guaranteed to lock-up either at first play, or the main menu, or before the movie starts. yet to get a movie (in DVD structure) playing. A quick test in non-D3D mode worked despite a fair bit of menu navigation and chapter jumping in the movie.

The trunk is rock solid.

[Jong]

Hi again ar-jar!

Small point but I think your stats get confused if there is a refresh rate change, especially if it is done by Pstrip (using a Reclock script). Looks like your refresh rate calculation is a one time deal? If it is not too resource intensive it might be sensible to check the refresh rate every few seconds or so and reset the OSD if it has changed.

[THX-UltraII]

I ve been using Reclock for ages now and all it gave me all these years was loooooots of discusions with James and many headaches. Because I live in PAL-land I need something like ReClock. Is this the player I m looking for? If not, what is the purpose of this player compared to MPC-HC 'regular'?

[Jong]

No, this does not speed up 24p for display @50Hz or slow down PAL to 24Hz. Reclock works very well with it though. :)

It offers the benefits of vsync correction (part of Reclock) but without all the confusing options and renderer restrictions - turn it on and go.

It seems really solid, except it really does seem to have a problem with DVD playback in D3D mode (quite a big "but"!), but I am waiting for ar-jar to come back on that one. That said, if you don't need to use Reclock, you don't need Reclock vsync correction and if you don't need that you don't need D3D mode, so for many this will be just fine. Sadly, it sounds like you do still need Reclock.

[Jong]

ar-jar,

Something else from my testing. It seems pretty clear to me, on several system, that whilst "normal", "background" variability in presentation is roughly symmetric, the bigger spikes in variability that can lead to glitches are all one way - towards -0ms. I have never seen a big spike towards -20ms.

So my testing with your excellent OSD has confirmed what I had assumed/guessed but never been able to truly verify before, that you do not really want to set the target offset "in the middle" but as close to -20ms (for 50Hz) as you can without risking "normal" variability taking you over. I would guess this might vary from system to system, but is easy to see using your "check the sync" test. On the systems I have tried a figure of say 15ms @50Hz seems good. For 60Hz maybe 12ms would be good. (Or 75% for both if you change the way of defining the offset).

Thoughts?

[ar-jar]

ar-jar,

Something else from my testing. It seems pretty clear to me, on several system, that whilst "normal", "background" variability in presentation is roughly symetric, the bigger spikes in variability that can lead to glitches are all one way - towards -0ms. I have never seen a big spike towards -20ms.

So my testing with your excellent OSD has confirmed what I had assumed/guessed but never been able to truly verify before, that you do not really want to set the target offset "in the middle" but as close to -20ms (for 50Hz) as you can without risking "normal" variability taking you over. I would guess this might vary from system to system, but is easy to see using your "check the sync" test. On the systems I have tried a figure of say 15ms seems good.

Thoughts?

Thanks for your analysis Jong. I suspected it could be like this but as I've not had any issues myself with the middle ground value, I've stuck with it. I shall run a few tests on my own when I get the time. Talking of which, I will try to answer you all during the weekend but I'm rather busy at work currently. The DVD in exclusive mode should not be a big issue, I might be able to look into this also during the weekend. Other than that, progress will unfortunately be slow the next month or so... -A

[Jong]

This brings up an interesting question for "option3". What offset figure should be targetted?

It seems to me (do you agree?) that "drift" could be in either direction. Can't think why it should not be.

If drift is towards -0ms you would want to set offset as suggested above for Reclock and your option 1. As time goes on the drift will increase the chance of a random spike causing a glitch, but at least it will be clean.

If drift is towards -20ms we have a trickier decision. If we set at -15ms we will get much more frequent glitches due to drift. If we set @-5ms we will be much more vulnerable to random spikes causing a glitch early on. Probably best to stick to "in the middle" for this mode unless testing shows drift is always towards -0ms.

[THX-UltraII]

No, this does not speed up 24p for display @50Hz or slow down PAL to 24Hz. Reclock works very well with it though. :)

It offers the benefits of vsync correction (part of Reclock) but without all the confusing options and renderer restrictions - turn it on and go.

It seems really solid, except it really does seem to have a problem with DVD playback in D3D mode (quite a big "but"!), but I am waiting for ar-jar to come back on that one. That said, if you don't need to use Reclock, you don't need Reclock vsync correction and if you don't need that you don't need D3D mode, so for many this will be just fine. Sadly, it sounds like you do still need Reclock.


and how do I find out if I need this version? In other words, how do I find out if I have V-Sync problems?

btw. Is it still not possible with Reclock to PAL-speeddown when you SPDIF passthrough?

[Jong]

What renderer and renderer settings are you using? what OS? But generally (other than maybe EVR with Aero ON) if you have matched frame rates and refresh rates (e.g. using Reclock) you need it. But if you don't notice the problems no need to make life difficult for yourself!

Basically:

- if you notice repeating judder (not one skipped frame but judder that goes on and on for many seconds or even minutes) sometimes when you start playback, or after pausing/seeking
- if you notice repeating judder that starts after a period of playback varying randomly from minutes to an hour or more
- if you suffer from odd random frame drops that Reclock does not fix

Try the Gothsync version of MPC-HC (it is just an exe, it does not install anything else or mess with the registry), with all ar-jars synchronisation options "off". Bring up the OSD with <cntrl-j> and play a movie. Try seeking and pausing/un-pausing. Does the "sync offset" (the gap between the green and red lines) vary from one seek to the next? Does the green line sometimes come very close to the red line and then cause big spikes on both (judder). Does the sync offset drift over time (green line drifts towards the red line)?

You can speeddown and use s/pdif provided you are prepared to decode the audio on your PC and then use Reclock (or your soundcard/motherboard) to re-encode to AC3 (or, with some soundcards/MBs, DTS). In my experience this works fine. The re-encoding is done @640kb/s - higher than DVD, which is a max of 448kb/s. Compared to the damage done by the timeshifting dll itself I'd say the effects are negligible.

Edit: Sorry, of course when doing PAL speeddown the timestretch dll is not used, so it does not affect quality. Still, my main point stands: The damage (lossy re-encoding technically always degrades the sound) done by re-encoding the a DVD track (originally 448kb/s or 384kb/s) @640kb/s, after resampling, has an inaudible effect on sound quality.

[tetsuo55]

Try seeking and pausing/un-pausing. Does the "sync offset" (the gap between the green and red lines) vary from one seek to the next? Does the green line sometimes come very close to the red line and then cause big spikes on both (judder). Isnt this behaviour inherent of the "seek" function, the splitter has to recover causing a few spikes.
Also the action of opening the menu (in full screen mode) will cause spikes.

I think this is expected and logical behaviour, but it would be cool to add some form of robustness to remove these spikes.

[ar-jar]

Isnt this behaviour inherent of the "seek" function, the splitter has to recover causing a few spikes.
Also the action of opening the menu (in full screen mode) will cause spikes.

I think this is expected and logical behaviour, but it would be cool to add some form of robustness to remove these spikes.

Without any vsync-related correction, either in the renderer or in Reclock, the green line (indicating the time when the actual rendering code is called) will settle pretty randomly between vsyncs (having settled after streaming is started after a pause - not referring to those few initial spikes). With some luck it ends up several ms before vsync but on occasion it may end up very close to vsync which doesn't leave enough time for the rendering code and you end up with judder. With drift, the lines will sooner or later meet too, causing a spike or judder. The closer the rates are to each other, the longer the judder period. A

[Jong]

Isnt this behaviour inherent of the "seek" function, the splitter has to recover causing a few spikes.
Also the action of opening the menu (in full screen mode) will cause spikes.

I think this is expected and logical behaviour, but it would be cool to add some form of robustness to remove these spikes.A few spikes, yes. No I was talking of after those spikes have gone. If there is no vsync correction the final sync offset is essentially random after a seek/pause. Sometimes it may be only 0-2ms one side or other from vsync in which case you get synchronised frame rate/refresh rate judder from then until drift takes it out of the danger zone. Especially with Reclock stabilising things, but more generally if refresh rate and frame rate are well matched, this may not be for up to an hour or so!

edit: oops.. sorry. didn't realise you had already replied to this ar-jar!

[Jong]

With drift, the lines will sooner or later meet too, causing a spike or judder. The closer the rates are to each other, the longer the judder period. A Maybe a small point but I would change this to read "With drift, the lines will sooner or later meet too, causing a period of spikes and judder. The closer the rates are to each other, the longer the judder period, from seconds to many minutes, even an hour or more", just so its clear we are not nitpicking over the odd very rare single dropped frame!

[THX-UltraII]

You can speeddown and use s/pdif provided you are prepared to decode the audio on your PC and then use Reclock (or your soundcard/motherboard) to re-encode to AC3 (or, with some soundcards/MBs, DTS). In my experience this works fine. The re-encoding is done @640kb/s - higher than DVD, which is a max of 448kb/s. Compared to the damage done by the timeshifting dll itself I'd say the effects are negligible.


So if I per se want my receiver do the decoding and live in PAL-land (use both 24 and 25fps material) Reclock is useless?

[webs0r]

Hi all, good to see progress on this great initiative.
I noticed the latest version of mpc-hc does not resize the output when it does not need to. This is great for me as I use ffdshow spline resizing instead, but then MPC resizes again unnecessarily, causing me to have to select Bilinear in MPC to avoid occasional tearing on my htpc setup.

Can I request an updated Gothsync build?

Cheers :)

[Jong]

So if I per se want my receiver do the decoding and live in PAL-land (use both 24 and 25fps material) Reclock is useless?If you want your receiver to decode and you want 25p DVDs played back @24p, Reclock cannot help and there is no other tool to help either, nor is there ever likely to be.

If you are happy that your PC does the decoding Reclock can help. Audio can then be passed over analogue, as PCM over HDMI or, with lossy compression, as s/pdif to your receiver.

If you are happy to playback at 24p or 25p depending on the disc and your TV properly supports 24p and 50Hz then either Reclock or "MPC-HC-gothsync" can help.

But we are OT. I suggest a thread in the Reclock forum if you want to discuss further.

[ar-jar]

It may be just D3D mode. Trying to play a disc in this mode is guaranteed to lock-up either at first play, or the main menu, or before the movie starts. yet to get a movie (in DVD structure) playing. A quick test in non-D3D mode worked despite a fair bit of menu navigation and chapter jumping in the movie.

The trunk is rock solid.

I'm unable to reproduce your problems on my XP system, sorry. I'm running my latest "private build". That build and the trunk behave the same here playing DVDs with VMR9 exclusive mode. Both work so-so (the menus are rather unresponsive in both cases). Can't remember what OS you're running but perhaps it's W7. I have just got my new hardware from the post office and will put together a new HTPC over the weekend. It will run W7 (whenever it becomes available, I just missed the window for the beta as my h/w was delayed). This will give me one more machine to test on. I'm not really keen on "upgrading" though; XP has over the years become rock-solid. But I guess one needs to go with the flow... -A

[Jong]

I'm unable to reproduce your problems on my XP system, sorry. I'm running my latest "private build". That build and the trunk behave the same here playing DVDs with VMR9 exclusive mode. Both work so-so (the menus are rather unresponsive in both cases). Can't remember what OS you're running but perhaps it's W7. I have just got my new hardware from the post office and will put together a new HTPC over the weekend. It will run W7 (whenever it becomes available, I just missed the window for the beta as my h/w was delayed). This will give me one more machine to test on. I'm not really keen on "upgrading" though; XP has over the years become rock-solid. But I guess one needs to go with the flow... -ANo. I'm using XP SP3 :confused: Any more testing I can do? In all other ways your player is great, but in VMR9 D3D mode (with VMR mixer and YUV mixing, if that makes a difference) as soon as I try to play a DVD it crashes, either on the first play, or the menu or, at least, before the movie starts.

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

I have removed the GPU flush code. That's why there's no difference. I wanted to start from something that I understood. I will probably put stuff back as I understand why it's there and if it is still needed with the rest of my code. I realize that GPU flushes removes tearing with some gfx boards. To me it's a bit black magic and probably a fix for a bad driver. When using PresentationInterval = D3DPRESENT_INTERVAL_ONE for the DirectX device "The driver will wait for the vertical retrace period (the runtime will "beam follow" to prevent tearing)." says the docs. It seems that I've been lucky with my gfx boards that indeed behave according to the MS docs; there's no tearing (unless I force the presentation time very close to vsync). Other people around here don't seem as lucky. -A

[ar-jar]

No. I'm using XP SP3 :confused: Any more testing I can do? In all other ways your player is great, but in VMR9 D3D mode (with VMR mixer and YUV mixing, if that makes a difference) as soon as I try to play a DVD it crashes, either on the first play, or the menu or, at least, before the movie starts.

I've tried it with a few more DVDs. I do get freezes. On Sade's Lovers Life concert DVD i can't for instance navigate to a certain song. But, the behavior is exactly the same with the trunk build and my branch build. It also consistently fails with both windowed mode and exclusive mode fs.

When I use the NVidia Purevideo MPEG2 decoder instead of the internal one, everything works fine. There is a video format change from 4:3 to 16:9 between the menus and the actual video in the Sade case (that could be a clue). Another DVD that I've used for testing for some time works fine every time. Have you tried several DVDs? Any format changes? -A

[Jong]

Thanks. I'll do some more testing and come back. I never, ever get crashes playing DVDs with the trunk. I am using Cyberlink's MPEG-2 decoder with DXVA on. Should have mentioned that, sorry.

[Jong]

Still hangs with the built in decoder :confused: It does seem to affect some discs wore than others, although it is a bit random/inconsistent so not totally sure. There is no visble aspect ratio change on the discs I am trying, but the way DVD menus work there could be things happening invisibly.

Did you test with VMR Mixer on, YUV mixing on? I must admit I haven't tested with it off yet. (everytime it hangs I have had no put the PC to sleep and bring it out to get rid of the black screen , but now I have a hotkey to kill your process so that should speed up testing! :))

I am using 1269 trunk. Also using your buikd 1259.9012. No problem with 1269 (and not with any build for a long long time).

[Leak]

Did you test with VMR Mixer on, YUV mixing on? I must admit I haven't tested with it off yet. (everytime it hangs I have had no put the PC to sleep and bring it out to get rid of the black screen , but now I have a hotkey to kill your process so that should speed up testing! :))
Have you considered hitting Ctrl-Alt-Del?

(Unless you're using one of those Microsoftian Toy-OS-versions where said combination brings up the task manager instead of the Windows Security dialog/screen...)

np: Reinhard Voigt - Am Limit (Various - Kompakt Total 10 (Disc 2))

[tetsuo55]

Can you reproduce with internal decoder?

We think non matching navigator/decoder will always be problematic in one way or another.

[Jong]

On second thoughts it may be the Cyberlink decoder that is tripping up your renderer. I did get one hang when I switched to the internal decoder, but I have not been able to reproduce it. But the problems with Cyberlink are serious. It will crash sometimes a few seconds after successfully starting to play the first play video. Video playback just locks up with a forzen frame on screen.

It may be DXVA related. I'll test the decoder with DXVA off in a little while.

[Jong]

Have you considered hitting Ctrl-Alt-Del?Doesn't work in D3D mode. Task manager opens but it is hidden behind the fullscree D3D window. However a hotkey which runs a "taskkill" batch file works great.

[Jong]

Can you reproduce with internal decoder?

We think non matching navigator/decoder will always be problematic in one way or another.That doesn't really make sense, or all DVD playback would be problematic on XP! There is no MS decoder. Directshow playback always involves the MS Navigator and a 3rd party decoder. All the decoders must be validated with the MS Navigator as it is standard practice for WMP to play DVDs once a 3rd party player/decoder is installed.

There is certainly no problem at all with using the Cyberlink decoder (7 or 8) with the trunk build.

[tetsuo55]

That doesn't really make sense, or all DVD playback would be problematic on XP! There is no MS decoder. Directshow playback always involves the MS Navigator and a 3rd party decoder. All the decoders must be validated with the MS Navigator as it is standard practice for WMP to play DVDs once a 3rd party player/decoder is installed.

There is certainly no problem at all with using the Cyberlink decoder (7 or 8) with the trunk build.Every decoder has its own navigator if you use the original program it was intended for.

Also the navigator was only meant to be used in WMP.
We're 99% sure its a combined problem of MPC+MS navigator+random renderer

[Jong]

In brief testing the problem goes away when I turn off DXVA in the Cyberlink decoder. It does now seem the crashes are not menu related. It will crash just playing a video if you leave it long enough (normally just a few seconds). It does not affect .mpg playback, so it does seem related to using DVD Navigator as a splitter. But it definitely does not affect the trunk. Since using an external decoder is the only way to get decent hardware assisted de-interlacing of DVDs in MPC-HC I think its pretty vital to get this fixed. IMHO :)

[ar-jar]

In brief testing the problem goes away when I turn off DXVA in the Cyberlink decoder. It does now seem the crashes are not menu related. It will crash just playing a video if you leave it long enough (normally just a few seconds). It does not affect .mpg playback, so it does seem related to using DVD Navigator as a splitter. But it definitely does not affect the trunk. Since using an external decoder is the only way to get decent hardware assisted de-interlacing of DVDs in MPC-HC I think its pretty vital to get this fixed. IMHO :)

Thanks, I'm looking into it. The thing is that it works pretty well on my dev machine with CyberLink SP/Video Decoder (PDVD8) w/ DXVA so debugging is a bit slow. -A

[Jong]

I've been using the PDVD7 decoder, but I have the PDVD8 one too. I'll try that and see if there is a difference.

[THX-UltraII]

I just downloaded the GoithSync version of MPC-HC and read this post http://www.ostrogothia.com/?page_id=1216

However, it seems too technical for me so I would like to ask if you guys can help me on my way:

I ll explain how my system looks like in the first place:
As movie browser I use XBMC with MPC-HC as external player. The problem is that when I start a movie from within XB<C I NEED direct3D fullscreen or else the focus from XBMC gets lost. So I enabled this in the settings of MPC-HC. I use XP with SP3 and netfram 3.5 installed and I use EVR Custom. I do not use Reclock. I have a JVC RS2 projector. My videocard is the ATI HD4350 with the lastest driver installed. My ATI settings are 1920x1080@24Hz because I mostly watch 24fps material (.mkv files). As output for my sound I use SPDIF passthrough. I don t want to have a discussion about this but I want my receiver do the DTS/Dolby Digital decoding, so decoding done bt my HTPC is a no-go for me :)

I hope I have provided enough information but can you guys help my pick the best settings for the GothSync player?

Thanks

[Jong]

No PDVD8 decoder is just the same here. Looks like it is a fine timing thing. It happens much more easily here when D3D GUI is off, which it has to be for me. When D3D GUI is on it turns off the additional buffering which lets Reclock control the vsync. It still crashes with D3D GUI ON, but it seems to happen less frequently.

[ar-jar]

I just downloaded the GoithSync version of MPC-HC and read this post http://www.ostrogothia.com/?page_id=1216

However, it seems too technical for me so I would like to ask if you guys can help me on my way:

I ll explain how my system looks like in the first place:
As movie browser I use XBMC with MPC-HC as external player. The problem is that when I start a movie from within XB<C I NEED direct3D fullscreen or else the focus from XBMC gets lost. So I enabled this in the settings of MPC-HC. I use XP with SP3 and netfram 3.5 installed and I use EVR Custom. I do not use Reclock. I have a JVC RS2 projector. My videocard is the ATI HD4350 with the lastest driver installed. My ATI settings are 1920x1080@24Hz because I mostly watch 24fps material (.mkv files). As output for my sound I use SPDIF passthrough. I don t want to have a discussion about this but I want my receiver do the DTS/Dolby Digital decoding, so decoding done bt my HTPC is a no-go for me :)

I hope I have provided enough information but can you guys help my pick the best settings for the GothSync player?

Thanks

If you don't like tweaking too much, you should go for the Present at nearest vsync option in the Synchronization tab under Options. Leave the rest at their default values. Hit CTRL-J to see if you get fairly straight red and green lines in the graph. If not, pls post a screenshot and I'll see if I can help. -A

[tetsuo55]

DXVA mpeg2 isnt really required, even 1080p is relatively easy to decode.

We have talked to a dev who wants to get MPEG2 bitstream DXVA into MPC-HC.
We also know there are bugs with the internal MPEG2 decoder (but not sure what they are exactly)

Once both of these are fixed, and deinterlacing works, there will no longer be a reason not to use the internal decoder.

[THX-UltraII]

If you don't like tweaking too much, you should go for the Present at nearest vsync option in the Synchronization tab under Options. Leave the rest at their default values. Hit CTRL-J to see if you get fairly straight red and green lines in the graph. If not, pls post a screenshot and I'll see if I can help. -A

Ok, thank you!
So I checked the third option in the synchro options and enabled d3d. I do get sync problems. Can you make something of this?:

http://img25.imageshack.us/img25/5313/naamloosmd.png (http://img25.imageshack.us/i/naamloosmd.png/)

[THX-UltraII]

btw. In the ATI settings the sync is on: ALWAYS OFF, UNLESS APPLICATION REQUIRES.

[Jong]

That sounds good. It is the hardware deinterlacing and (very very delicate) use of driver image enhancement that I want more than the acceleration of MPEG2, which as you say it quite easy.

I am sure you are right, it is possible for a combination of mixed navigator and decoder and renderer to cause problems. This proves it. But, as is also clear from the trunk, it does not have to be the case. Hopefully ar-jar can find the problem.

[Jong]

Ok, thank you!
So I checked the third option in the synchro options and enabled d3d. I do get sync problems. Can you make something of this?:

http://img25.imageshack.us/img25/5313/naamloosmd.png (http://img25.imageshack.us/i/naamloosmd.png/)Have you still got Reclock vsync correction turn on?

[THX-UltraII]

heres a screenshot with VSync set to ALWAYS ON in the ATI settings:

http://img25.imageshack.us/img25/497/naamloosxpz.png (http://img25.imageshack.us/i/naamloosxpz.png/)

[tetsuo55]

@THX-UltraII > to my eyes your screenshot looks good, however the number of artifacts that occur when the vsync trips over itself is much higher than it should be.

You didnt seek right before that screenshot did you??

Did you make your screenshot like this, if not please upload another one:

open video, press CTRL+J, wait minimum of 5 seconds (so all lines are flat), press CTRL+R.
Now wait for for the spikes and then hit PRINTSCREEN.
The spikes should only occur when Sample paint time correction goes from 0 to 41 or viceversa

[THX-UltraII]

@Jong: I don t use ReClock anymore.

[THX-UltraII]

@THX-UltraII > to my eyes your screenshot looks good, however the number of artifacts that occur when the vsync trips over itself is much higher than it should be.

You didnt seek right before that screenshot did you??

Did you make your screenshot like this, if not please upload another one:

open video, press CTRL+J, wait minimum of 5 seconds (so all lines are flat), press CTRL+R.

Now wait for for the spikes and then hit PRINTSCREEN.

The spikes should only occur when Sample paint time correction goes from 0 to 41 or viceversa

I did exactly like you say and didnt seek at all.
Could it have something to do with the fact that I set my ATI to 1920x1080@24HZ and the movie is 23,976? (With ATI it is not possible to pick 1920x1080@23,976HZ).

Guys, keep in mind also that I use SPDIF and that my receiver does the decoding. Maybe this is important information, I don t know

[THX-UltraII]

I trying to help thinking:

Maybe it has something to do with the ATI setting 1920x1080@24HZ and should I try and pick 1920@1080@72HZ?

[tetsuo55]

Yes the tiny difference in rate should cause 1 artifact at each rollover (from 41 to 0 or 0 to 41)

Maybe Ar-Jar can see why you are getting so many artifacts at each rollover

What happens when you disable fillscreen D3D, if you open the file manually from mpc and go to fullscreen with the doubleclick or ALT+ENTER

[THX-UltraII]

What happens when you disable fillscreen D3D, if you open the file manually from mpc and go to fullscreen with the doubleclick or ALT+ENTER

This is what happens:


http://img17.imageshack.us/img17/2617/naamloosnw.png (http://img17.imageshack.us/i/naamloosnw.png/)

[tetsuo55]

What happens if you try the stable build instead of the private build

[THX-UltraII]

What happens if you try the stable build instead of the private build

I use the stable build and not the private

[tetsuo55]

ok try the private build lol

[ar-jar]

Ok, thank you!
So I checked the third option in the synchro options and enabled d3d. I do get sync problems. Can you make something of this?:


Does your projector sync to 48Hz? If it does, please try that refresh rate too! -A

[THX-UltraII]

ok try the private build lol

same happens

[THX-UltraII]

Does your projector sync to 48Hz? If it does, please try that refresh rate too! -A

o o , sorry m8, but I really don t know what you mean here.....:(

[tetsuo55]

o o , sorry m8, but I really don t know what you mean here.....:(1920x1080@48HZ
set that in the ati control panel

[THX-UltraII]

Again, don t know if the info is valuable, but here is a screenshot what happens with the option sync video to display (first option) is enabled and d3d fullscreen enabled. I played a movie for 5 min and don t see any ups or downs.



http://img2.imageshack.us/img2/1285/naamloosks.png (http://img2.imageshack.us/i/naamloosks.png/)

[THX-UltraII]

1920x1080@48HZ
set that in the ati control panel

Is is not selectable in the ATI panel:

http://img38.imageshack.us/img38/3894/naamloosdu.png (http://img38.imageshack.us/i/naamloosdu.png/)

[ar-jar]

No PDVD8 decoder is just the same here. Looks like it is a fine timing thing. It happens much more easily here when D3D GUI is off, which it has to be for me. When D3D GUI is on it turns off the additional buffering which lets Reclock control the vsync. It still crashes with D3D GUI ON, but it seems to happen less frequently.

I think I have a clue about at least where to look. When you play your DVD, does it say "Frame cycle from video header: 0.000 ms"? (Second row in the OSD) -A

[tetsuo55]

I think I have a clue about at least where to look. When you play your DVD, does it say "Frame cycle from video header: 0.000 ms"? (Second row in the OSD) -Ai confirm all values in that line being 0 on my system

[ar-jar]

i confirm all values in that line being 0 on my system

What seems to happen is that the renderer is desperately trying to find the frame rate from the input pin as long as it is 0 but fails and eventually runs into a dead-lock of some kind. Some decoders don't report a correct refresh rate. The bug chase continues... -A

[THX-UltraII]

frame rate cycle from video header: 41.708ms | frame rate from video header 23.976fps (as you can see in my screenshots).

And what about my other screenshot with the option 1 enabled? Can t I use this one or do I need to let the decoding beeing done by my PC as a condition?

[Jong]

I think I have a clue about at least where to look. When you play your DVD, does it say "Frame cycle from video header: 0.000 ms"? (Second row in the OSD) -AYes :). Sounds like you are on to something!

[Jong]

Could it have something to do with the fact that I set my ATI to 1920x1080@24HZ and the movie is 23,976? (With ATI it is not possible to pick 1920x1080@23,976HZ).Is there not a 23Hz option? If so, this is what you want. Windows refresh rates are always rounded down when displayed in control panel or ccc.

@23.976Hz you should be able to use option 1.

[THX-UltraII]

Is there not a 23Hz option? If so, this is what you want. Windows refresh rates are always rounded down when displayed in control panel or ccc.

@23.976Hz you should be able to use option 1.

what you mean? There s no 23Hz option. Only, 24,25,30,50 etc.

I checked the first option and the green and red bars looks like the screenshot I posted 12:53.

However, you can also see there: ''Audio renderer is not matching rate''. What does this mean? Maybe this is why Ar-Jar told me to use option 'present at nearest vsync'

[Jong]

what you mean? There s no 23Hz option. Only, 24,25,30,50 etc.

I checked the first option and the green and red bars looks like the screenshot I posted 12:53.

However, you can also see there: ''Audio renderer is not matching rate''. What does this mean? Maybe this is why Ar-Jar told me to use option 'present at nearest vsync'Often there is a 23Hz option (which is really 23.976Hz) as well as a 24Hz one. Shame if you do not have it. Hopefully ar-jar can work on your problem.

[THX-UltraII]

thxz for all input guys (specially Jong and Ar-Jar). I ve done some more testing today and more questions rise up:

First of all, one and for all I want to know what to do with the vsync option in the ATI control panel: should I set this to always ON or always OFF? I still dont know that.

This afternoon I began with some tests. I reinstalled Reclock and found out some interesting things. I did a 2minutes test with a .mkv dts file set up reclock to passthrough so my receiver can do the decoding:
First thing you should know is that in this 2minutes test the red and green bars never went u or down, so I think thats a good thing correct?
You can also see () that the notification ''Audio renderer is not matching rate'' is gone now. This is strange to me because I configured ReClock to only pssthrough spdif and that is all he does. Anyway, I also see 5x sync adjustments. I this ok? Also would like to know if there are more non-normal things that happen.

thanks.

http://img22.imageshack.us/img22/3183/naamlooscb.png (http://img22.imageshack.us/i/naamlooscb.png/)

[THX-UltraII]

one morre thing (for today :)): In the 'manual' I see this:

1.Open the View -> Options -> Playback -> Synchronization tab. Select Sync video to display. Frequency adjustment should be set to about 0.0012 (~0.12% of the nominal frequency), Target sync offset to 10 ms for a 50 Hz display refresh rate and 8 ms for a 60 Hz display, and Control limits to 2.0 ms. The sync options checkboxes are greyed out if you haven’t selected VMR9 or EVR as your renderer or if you haven’t closed the Options dialog in between or if there is an active playback (select File -> Close in that case).

does this mean that for Target Sync offset you can use 8ms for 60HZ, 10ms for 50HZ, 12ms for 40HZ, 14ms for 30HZ and approx. 15ms for my resolution 1920@1080@24HZ that my card sends out (and my JVC projector accepts)

[Jong]

ATI CCC should be set with Vsync "OFF unless app specifies".

Trying to help in ar-jars absence (sorry ar-jar and THX if I get anything wrong!!), but you should not be using "option 1" if using Reclock. In your latest screenshot it does look like the green line is slowly rising, which will lead to judder (and probably quite bad judder) when it gets to (about) 42ms. With such a large frame time this may well take more than 2 mins so your test was probably not sufficient.

In fact, if you are using Reclock with EVR in D3D mode you should be able to use Reclock vsync correction. Try it. Set the Reclock slider in the middle (for now) and look at your chart. Make sure vsync correction in EVR is enabled in Reclock. Make sure "D3D Full screen GUI" is turned OFF in MPC-HC. Turn off all of ar-jar's synchronisation options.

Failing that you will be back to using option 3, which may work with Reclock, but Reclock vsync really should work with your setup.

[noee]

I don't mean to be a contrarian here, but here's my set up using MPC-Goth:

Source material 23.976
ATI CCC Vsynch ON unless app specifies
HD2600XT 1080@24Hz
FFdshow decoders audio/video
Reclock vsynch turned off (all)
MPC EVR-CP, D3D NOT checked
Synch OPtion 1 (Synch video to display)

I get perfectly parallel red/green lines and zero glitches for a long, long time. Occasionally, the green line heads down towards the red line, but the the "magic" occcurs and they go back parallel and no judder, no glitches.

YMMV, but it works wonderfully here.

[ADude]

There is certainly no problem at all with using the Cyberlink decoder (7 or 8) with the trunk build.

Actually that is not true.

There are long-standing unfixed bugs in the bug tracker, relating to DVD menu highlight display that only occur with MPC-HC main build, Cyberlink decoder with DXVA turned on, and MS DVD Navigator.

[ADude]

I wanted to start from something that I understood.

I think that is a very important principle, one that needs to be followed more closely by everyone.

I have read various comments regarding all aspects of video/audio timing in HT-PCs by various developers, such as the developer of Reclock, by "he who cannot be named", by the main MPC-HC developers, by the Zoom Player developer, and the one thread that runs through it all is nobody entirely understands it.

Of course, there are people who understand it, they are professionals who work for AMD, Nvidia, Intel, MS, Dish Network, DirecTV, BSkyB, Comcast, ESPN, BBC, Toshiba, Sony, Samsung, Lucasarts and so forth.

With the approach of trying to patch various specific problem combinations, the inevitable result is that other combinations become broken.

I think that effort is wasted using that approach, and instead time and effort instead should be applied to learning more about how it actually works in professional and consumer applications.

I remember someone in one of these threads saying " I wonder how DBS Satellite boxes accomplish sync. " I think that is the sort of thing that people should be spending their time researching.

[Jong]

Actually that is not true.

There are long-standing unfixed bugs in the bug tracker, relating to DVD menu highlight display that only occur with MPC-HC main build, Cyberlink decoder with DXVA turned on, and MS DVD Navigator.Yeah, maybe I should have been clearer, sorry. Works perfectly with VMR9 on XP.

[Jong]

I don't mean to be a contrarian here, but here's my set up using MPC-Goth:

Source material 23.976
ATI CCC Vsynch ON unless app specifies
HD2600XT 1080@24Hz
FFdshow decoders audio/video
Reclock vsynch turned off (all)
MPC EVR-CP, D3D NOT checked
Synch OPtion 1 (Synch video to display)

I get perfectly parallel red/green lines and zero glitches for a long, long time. Occasionally, the green line heads down towards the red line, but the the "magic" occcurs and they go back parallel and no judder, no glitches.

YMMV, but it works wonderfully here.Well this is where we need ar-jar's input. I still use Reclock to do it all, so I am just repeating ar-jar when he says he thinks option 1 and Reclock will clash. Maybe I should do some tests on this!

[Jong]

I think that is a very important principle, one that needs to be followed more closely by everyone.

I have read various comments regarding all aspects of video/audio timing in HT-PCs by various developers, such as the developer of Reclock, by "he who cannot be named", by the main MPC-HC developers, by the Zoom Player developer, and the one thread that runs through it all is nobody entirely understands it.

Of course, there are people who understand it, they are professionals who work for AMD, Nvidia, Intel, MS, Dish Network, DirecTV, BSkyB, Comcast, ESPN, BBC, Toshiba, Sony, Samsung, Lucasarts and so forth.

With the approach of trying to patch various specific problem combinations, the inevitable result is that other combinations become broken.

I think that effort is wasted using that approach, and instead time and effort instead should be applied to learning more about how it actually works in professional and consumer applications.

I remember someone in one of these threads saying " I wonder how DBS Satellite boxes accomplish sync. " I think that is the sort of thing that people should be spending their time researching.Great, maybe that is a positive contribution you could make to the group.

The fact is that if the professionals knew how to make it all work dependably on a PC we would not be having this discussion at all. Win-tel PCs at a very fundamental level were not engineered for high quality smooth video playback. Their architecture was set way before it was even a dreamt of requirement. Trying to retro-fit it is not easy.

It amazes me that still major commercial aps like Cyberlink, running on the latest Windows with the latest greatest graphics card still, more often than not, suffers from synchronised judder, without band-aid fixes, like Reclock.

In so much as Reclock and gothsync can fix it (and in the vast majority of well maintained systems, where people are prepared to accept recommendations for hardware and software changes where needed, they can) they are doing something all the great minds in AMD, Nvidia, Microsoft etc. have yet to acheive. I guess it is true that the majority of HTPC users (mainly using VMC) are still not videophile enough to complain about a bit of judder. They are used to PC video playback being C**p!

[tetsuo55]

None of those companies named, except Lucasarts, are doing anything serious towards video/audio quality and sync.

Everyone uses a different hack (at least Lucasarts is asking everyone to use the same hack)

We can forget about solving the age old problem(on windows at least).
This time however, Ar-Jar is taking the start from scratch, minimal approach to the renderer.

Basically:
What is the minimum amount of actions required to get the image on the screen, and what needs to be added to those actions to get the image tearing, jitter and artifact free and keep judder under control. (all of this within the windows limitations)

This approach is also why i keep saying that there is a good chance that EVR-CP can replace all the older renderers in all situations except where DXVA2 support is needed and unavailable.

[ar-jar]

Yes :). Sounds like you are on to something!

Could you pls try the latest private build: http://www.ostrogothia.com/?page_id=1213. Again, I have basically only removed code so there might be side effects having to do with wrong image size or aspect ratio (I haven't seen any such effects while testing but that doesn't mean there aren't any). The OSD doesn't show exactly what it says anymore. I'll fix that later. Since I had a hard time reproducing the bug, I'm not absolutely sure I actually removed it. But at least i removed the statement where it apparently got stuck. Cheers! -A

[ar-jar]

The fact is that if the professionals knew how to make it all work dependably on a PC we would not be having this discussion at all. Win-tel PCs at a very fundamental level were not engineered for high quality smooth video playback. Their architecture was set way before it was even a dreamt of requirement. Trying to retro-fit it is not easy.


It's no rocket science to add sync to DirectShow / DirectX / OpenGL / the drivers. The reasons for why this doesn't happen are IMO: (1) most people don't even know they have a problem, and (2) gaming, not video, is where the money is. We are geeks interested in an esoteric problem with no potential for any money :-) -A

[tetsuo55]

Could you pls try the latest private build: http://www.ostrogothia.com/?page_id=1213. Again, I have basically only removed code so there might be side effects having to do with wrong image size or aspect ratio (I haven't seen any such effects while testing but that doesn't mean there aren't any). The OSD doesn't show exactly what it says anymore. I'll fix that later. Since I had a hard time reproducing the bug, I'm not absolutely sure I actually removed it. But at least i removed the statement where it apparently got stuck. Cheers! -Ahere is my result:
http://img38.imageshack.us/img38/5043/dvdtst.th.png (http://img38.imageshack.us/i/dvdtst.png/)

[Jong]

It's still a fudge though, caused:

a) because the PC has no single clock to go by and by design it drops frames rather than compromise audio if it gets out of sync

b) it is not a real time OS. Short of stripping down your installation to an almost non-functional/security exposed core, there is still no way to start video and be 100% sure some other piece of WIndows jumk (or accumulated PC clutter) is not going to stop smooth playback.

I think it is remarkable how smooth we are now managing to make things given this background, helped significantly by throwing ridiculously large amounts of processing power at the problem compared to what should be needed.

[ar-jar]

Again, don t know if the info is valuable, but here is a screenshot what happens with the option sync video to display (first option) is enabled and d3d fullscreen enabled. I played a movie for 5 min and don t see any ups or downs.


The video speed gets adjusted by this sync option and is in effect sped up from 23.976 to 24 Hz (if I can read the tiny numbers right). This works fine for analog audio output but if you use SPDIF then you'll most likely notice that audio and video get out of sync eventually. -A

[Jong]

Could you pls try the latest private build: http://www.ostrogothia.com/?page_id=1213. Again, I have basically only removed code so there might be side effects having to do with wrong image size or aspect ratio (I haven't seen any such effects while testing but that doesn't mean there aren't any). The OSD doesn't show exactly what it says anymore. I'll fix that later. Since I had a hard time reproducing the bug, I'm not absolutely sure I actually removed it. But at least i removed the statement where it apparently got stuck. Cheers! -A A very very brief test before bed seemed to work well:). Not tested for regressions and only tried once. However, this DVD would have crashed within seconds previously.

[ar-jar]

here is my result:


This is what I think happened: You managed to find a file / decoder combination just like Jong's, which doesn't report its frame-rate in the videoinfo header. Thus the 0 on the second row. With such a large (apparent) rate difference, the "snap" function won't kick in and you get judder when passing vsync.

I just fixed (hopefully) exactly this issue in VMR9. I will do the same with EVR if the fix seems to work well. -A