MPC-HC GothSync tryouts

[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