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

[tetsuo55]

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. -Asounds plausible.
Let me know as soon as you have ported that fix, i will test it asap.

[Jong]

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.I thought I'd elaborate a little on this comment, for discussion!

Reclock alters the frame rate to match it to the refresh rate; In vsync mode it even alters it continually to keep frame presentation in the "right" place relative to vsync. To be able to do this it has to resample up to 8 channels of potentially high definition, up to 96khz/24-bit, audio in real time; To keep HD audio HD it has to do this to an exceptionally high quality. This simply would not have been possible a few year ago. It was not really possible when Reclock was written, hence Ogo's recommendations that lower quality resampling be used. This may have been OK (ish!) for SD audio, but would certainly have been unacceptable in today's HD world. Only recent advances in processing power and GPUs has allowed better resampling to be incorporated into Reclock in the last year, and for most of us, with state-of-the-art HTPCs, to use it.

Gothsyncs methods are (and you know I do not mean this in a derogatory way at all!) "simpler" and "lighter" but it does mean for a perfect result you need a better match of frame-rate and refresh rate. Even then only options 1 and 2 offer the "perfect" video playback we are all seeking. However, even they (and Reclock) rely on the fact that a modern PC is able to render and paint a frame in a tiny fraction of the time available between vsyncs. There is plenty of space available to avoid frames being presented @vsync and plenty of spare CPU (mostly!) for Windows to do whatever it wants/needs/must do even when playing time critical video :rolleyes: and still deliver the frame on time. It would be possible to build a stand-alone player using technology from many years ago that takes most of the time between refreshes to render the frame, but a PC using that technology would be completely unreliable in delivering frames on time. The methods we are using to retro-fit vsync correction would also be unreliable on such hardware.

Along with the sad fact that 90% of the market just do not know or care about smooth video playback(!), the other reason why the "main players" have not yet fixed the problem (I guess) is any of the techniques available would not work on the full spectrum of PCs that they would be expected to run on. In another few years that may change, but it will, again, be using the brute force of incredible processing power to overcome a fundamental design flaw.

[THX-UltraII]

did some more and more testing last night:

No matter what combination I tried (with VSync settings d3d etc etc) there was always troubles.

Eventually I applied a 'back-to-basics' method:

I installed the latest regular MPC-HC version and put EVERYTHING off (vsync options, etc) and now everything works as smooth as hell

[Jong]

If you don't have a problem don't look for one and don't try to fix it! It will only drive you mad. Glad you have found something you are happy with. It would help others if you listed your full settings - OS, renderer, renderer options, renderer settings, display refresh rate.

[ar-jar]

sounds plausible.
Let me know as soon as you have ported that fix, i will test it asap.

There's a new private build. I've now also addressed the case when the video frame-rate is higher than the display refresh rate. I realized it wouldn't have worked with the Present at Nearest as it was implemented before. It also exclusively gets the frame rate from the sample timestamps now, both in VMR and EVR. It seems to be the only reliable method to actually get the number. And the previous method also had some serious issues as Jong found out. It was the same code as in the regular build so I wouldn't be surprised if the same issue pops up there too sooner or later. I don't have time to fix any major bugs again for a week or so, so be patient :-) Cheers! -A

[Jong]

ar-jar. Thanks for the new build. I will test tomorrow.

Something occured to me about "option 3". Does audio/video sync change as your offset correction grows or do you fix this somehow? If it grows it might still be OK for 60Hz/50Hz but it could be quite noticeable @24Hz (42ms cycle time). Of course option 3 is only the fallback anyway.

[Jong]

So although it's still 9012 it's new, right? Changed from last night's new build?

[ar-jar]

ar-jar. Thanks for the new build. I will test tomorrow.

Something occured to me about "option 3". Does audio/video sync change as your offset correction grows or do you fix this somehow? If it grows it might still be OK for 60Hz/50Hz but it could be quite noticeable @24Hz (42ms cycle time). Of course option 3 is only the fallback anyway.

Audio and video will get slightly out of sync yes (one frame cycle at the most). But this is a tricky issue in general if you don't insist on GPU flushes and what have you. The gfx board for instance has according to DirectX docs the option to store up to 2 frames in an inaccessible buffer if it so chooses which will give you some 80 ms diff to start with. It is definitely possible to improve the performance but it's not my priority right now. A stable renderer is :-) -A

[Jong]

Yes of course I understand!

But most can calibrate for a fixed offset. 42ms of variable sync @24Hz will be very noticeable and may influence whether it can/should be the default setting for 24p?

Do you think your build with all your sync settings OFF has a different AV sync to the trunk build with default GPU flush settings? I haven't spent long with it but I think there is about 40ms of difference, which I need to adjust for.

[ar-jar]

Yes of course I understand!

But most can calibrate for a fixed offset. 42ms of variable sync @24Hz will be very noticeable and may influence whether it can/should be the default setting for 24p?

Do you think your build with all your sync settings OFF has a different AV sync to the trunk build with default GPU flush settings? I haven't spent long with it but I think there is about 40ms of difference, which I need to adjust for.

Depending on the gfx board, all players using DirectX may end up with 2 frames worth of audio lead, if not compensated for. This probably varies between boards. GPU flush flushes the GPU pipeline clean and so should cause immediate presentation. (It also thus disables any threading advantages of having a pipeline in the GPU.) Not sure if there is a way to actually know exactly when a new frame is flipped into the front buffer by gfx driver. Maybe one can query the GPU but I haven't checked. -A

[Jong]

In my experience the most important thing is for it to be consistent. Probably up to 20ms of variability @50Hz will not be noticed, especially if av sync is set so audio is slightly behind video at all times, but 42ms of variability I think would be distracting (for me anyway!).

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

Greetings ar-jar. Did you get a chance to look into these issues?

Best regards.

[Casshern]

Hi,

i just switched to win7 and already posted some interesting findings in the main MPC HC thread. I came around testing the MPC GOTHSync tryouts under win 7 and want to present some of my observations. Let me first briefly sum up my findings of the regular build (x86), win7 (x64), my trusty old ATI 2600 PRO AGP, reclock (no vsync control), and powerstrip (e.g. 47.952 display refresh), movie frame rate 23.976, EVR CP:

Through trial and error i came up with two working (no tearing, judder free, dxva + YV12 upsampling + complex sharpen 2, bicubic resizing) settings:
1) All Vsync options off, all gpu options off, desktop composition enabled (= uncheck the option to disable the desktop composition).
tearing free + judder free: but after starting play might be stuck with permanent judder which one has to eliminate by hitting pause/play a couple of times. Once judder free it will stay that way - i tested it with about 3 full movies.

2) Even better: Vsync on, all other options off, desktop composition disabled.
tearing free + judder free: after start i get tearing judder for maybe 1-2 seconds after which beliyaals code settles and gives perfect playback. But this is extremely sensitive to the time it takes the gfx card to finish all DXVA+Shader+ resizing operations. If the card takes to long, you get tearing. If went back to bilinear scaling or desabled one of the shaders i used (e.g. complex sharpen) it worked fine. Luckily i found out that I had to compile all shaders with shader model 3.0 which gave enough of a speed up to have everything working without disabling any shader or going back to bilinear resizing.

Additional observations: resizing is currently ALWAYS applied, even if source resolution equals display resolution. Also it seems like the shaders are also applied at screen refresh and NOT on the decoded frames. Here is a lot of room to improve especially for older/slower/onboard gfx cards. It would be best to decouple the shaders+resizing from screen refresh.

Speculation: this decoupling sort of happens if you use aero (enable desktop compositon) or use the flush gpu, wait for gpu settings: Here the code waits for all GFX operations to finish. If this takes longer then one screen refresh, beliyaals code recovers here (i don't know whether by design or accidental) as the previous skipped display frame is only a repeat of the previous.

Gothsync tryouts:
Under XP: i did not get it to work without tearing, no matter what GPU settings and i highly suspect it was indeed because of the speculation above, only that the goth code does not recover that well
Under Win7: Everything turned off, except for the present at nearest sync option, and desktop compositon disabled it behaved much like method two above. Judderfree + tearing free, if and only if i disable one of the shaders and/or go back to simpler resizing. It seems like the goth code is even move timing sensitiv or maybe just takes up more vsync time of its own. But if i disable a shader it works pretty solidly - but at the moment i would obviously prefer the beliyaal code as it permits to use all of my shaders and bicubic resizing.

All this explains some of the probs people with slow gfx cards and/or Vista versions without aero have. Without aero you cannot use option1 and with a very slow gfx dxva engine even option two without any shaders and simple resizing might be plaged with tearing.

i hope this sheds some light on some issues and helps to improve....

[ar-jar]

Greetings ar-jar. Did you get a chance to look into these issues?

Best regards.

Hi, I think I gave you a partial answer earlier. I could never access the screenshot as it was pending approval for a long time.

Not sure what you mean by "target refresh rate". The refresh rate should stay approx. constant with that sync option. The refresh rate is estimated when streaming starts and then from the estimated vsync times. The vsync detection may be less exact now than in previous builds but should be sufficiently exact for its purposes.

About tearing: the only pretty universal antidote seems to be exclusive fullscreen ("D3D"). Many boards including the ones I have at home are pretty tearing-proof as long as you give them enough time to do the rendering (keep the green line far enough above the red line in the graph). But other boards seem to require all kinds of tricks. I would be great if we could, once we have a couple of stable builds, collect some data on what configs work well and what configs to avoid when building a new HTPC. -A

[Jong]

New private build does seem to have fixed the hanging problem. However, when it exits it does not seem to cause a full screen refresh :confused: (using VMR9 D3D)

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

[tetsuo55]

New private build does seem to have fixed the hanging problem. However, when it exits it does not seem to cause a full screen refresh :confused:it's probably better and faster if you use an externalhosting like imageshack.us

[tetsuo55]

There's a new private build. I've now also addressed the case when the video frame-rate is higher than the display refresh rate. I realized it wouldn't have worked with the Present at Nearest as it was implemented before. It also exclusively gets the frame rate from the sample timestamps now, both in VMR and EVR. It seems to be the only reliable method to actually get the number. And the previous method also had some serious issues as Jong found out. It was the same code as in the regular build so I wouldn't be surprised if the same issue pops up there too sooner or later. I don't have time to fix any major bugs again for a week or so, so be patient :-) Cheers! -AHere is the result for dvd playback on my htpchttp://img245.imageshack.us/img245/7019/dvd2.th.png (http://img245.imageshack.us/i/dvd2.png/)

[ar-jar]

Here is the result for dvd playback on my htpchttp://img245.imageshack.us/img245/7019/dvd2.th.png (http://img245.imageshack.us/i/dvd2.png/)

Looking good huh? -A

[tetsuo55]

Looking good huh? -AYeah, however on the "sample paint time correction" roll over from 16 to 0 it still looks like this: http://forum.doom9.org/showthread.php?p=1324878#post1324878

[THX-UltraII]

if you guys had to pick an OS from a full reinstallation of a HTPC. Which is the best to pick (with keeping in mind the best for MPC-HC and no-tearing).

XP
Vista
or
Windows7 (which version is the current one?)

[pirlouy]

In the latest build (Tentative patch 9012), seek function is quite broken: when you seek, image freezes (not always, but often).

Not present in an older build. Someone to confirm ?

[ar-jar]

In the latest build (Tentative patch 9012), seek function is quite broken: when you seek, image freezes (not always, but often).

Not present in an older build. Someone to confirm ?

I'm working on it :-) -A

[ar-jar]

In the latest build (Tentative patch 9012), seek function is quite broken: when you seek, image freezes (not always, but often).

Not present in an older build. Someone to confirm ?

The new version should be a little better but it's not perfect. To be continued... -A

[buzzqw]

Hi

i dumb question: my plasma support 23.976, 24p, 25p,50p,60i,60p mode and my nvidia (9400m) too

i tryed your mpc build, but don't seems that framerate of display changes (even if i checked the options) (tested with varius sources)

for sure i am doing something stupid.. any help ?

BHH

[webs0r]

I'll post what I found useful in getting perfect sync:

Setup
Intel E7300 @ 3.4 Ghz
ATI 4550
Windows Home Server (comparable to XP)

I found EVR+Gothsync patch version gives me the most consistent perfect sync.

Typical filterchain:
Source (haali splitter mostly)
Decoder (usually ffdshow or coreavc)
ffdshow (Spline resize + colour conversion)
Reclock
EVR/gothsync renderer

My TV supports basically 50/60 Hz only afaik, at least I don't know other timings for it (48?).

So I use reclock to automatically switch refresh rate to 50 or 60 Hz and adjust media speed to 25 or 30 fps exact, depending on the source.

Then I have gothsync set to present at nearest vsync.

With target sync offset set to 9ms:
- I found it would tear when I set MPC resize to Bicubic. Tearing would be fixed if I set it to bilinear, in which case playback was perfect.
- This is even though MPC doesn't need to resize when ffdshow is resizing to 1080 already and I am watching at 1080. So I'm keen to get latest MPC code merged.

With target sync offset set to 14ms:
- It does not tear when I set MPC resize to Bicubic & there is perfect playback.

Although I don't understand the detail it seems that moving this offset up has given the system more time to ..? All I know is it avoids tearing when the graphics system has (slightly) more load. Knowing this & the resize issue might help some out there.

Other notes:
- Monitoring the MPC load on the GPU shows that there is only a small difference in bilinear vs bicubic, both well below 100% (20-30%)
- Can frames be prepared & buffered ahead of time so that variation in cpu/gpu load become irrelevant?
- It is interesting to test with 50/60 fps content as the window is much smaller. I get perfect sync on this too, but on my gaming/encoding rig which is much more powerful (q9550/8800gt etc).
- Argh I overwrote my copy with seek working! :( Ar-jar can the version numbers be incremented, and maybe older versions kept? :)

Cheers & good luck!

[ar-jar]

Hi

i dumb question: my plasma support 23.976, 24p, 25p,50p,60i,60p mode and my nvidia (9400m) too

i tryed your mpc build, but don't seems that framerate of display changes (even if i checked the options) (tested with varius sources)

for sure i am doing something stupid.. any help ?

BHH

Which sync option are you testing? The refresh rate of the display (if that's what you mean) only changes with the Sync Display option and it probably won't work with your new-ish nvidia board. You have to check if it is supported by PowerStrip. More documentation on my site. -A

[ar-jar]

With target sync offset set to 9ms:
- I found it would tear when I set MPC resize to Bicubic. Tearing would be fixed if I set it to bilinear, in which case playback was perfect.
- This is even though MPC doesn't need to resize when ffdshow is resizing to 1080 already and I am watching at 1080. So I'm keen to get latest MPC code merged.

With target sync offset set to 14ms:
- It does not tear when I set MPC resize to Bicubic & there is perfect playback.

Although I don't understand the detail it seems that moving this offset up has given the system more time to ..? All I know is it avoids tearing when the graphics system has (slightly) more load. Knowing this & the resize issue might help some out there.

Other notes:
- Monitoring the MPC load on the GPU shows that there is only a small difference in bilinear vs bicubic, both well below 100% (20-30%)
- Can frames be prepared & buffered ahead of time so that variation in cpu/gpu load become irrelevant?
- It is interesting to test with 50/60 fps content as the window is much smaller. I get perfect sync on this too, but on my gaming/encoding rig which is much more powerful (q9550/8800gt etc).
- Argh I overwrote my copy with seek working! :( Ar-jar can the version numbers be incremented, and maybe older versions kept? :)

Cheers & good luck!

Some answers:

- A larger sync offset indeed gives the GPU more time for processing. I haven't been eager to pull it back too far as one may perhaps "slip" to the previous vsync period if you are too close to the previous vsync. But people say it doesn't easily happen so it's probably safe to pull it back to say 3/4 of a vsync cycle (15 ms @ 50 Hz).
- Merge will come in due time :-)
- Frames are already buffered (> 4 when running EVR) but the GPU can only take one frame at the time anyway.
- 50/60 fps shouldn't make much difference to 25/30 as I already only use one vsync period at the most for processing (easier algorithms).
- I will have numbering on the more "official" builds but I've been churning out "private builds" for a few people to test. Now these have become more or less "official"... The thing is that to insert a new patch label I need to recompile for maybe 5 minutes which is a lot sometimes.
Cheers! -A

[tetsuo55]

The new version should be a little better but it's not perfect. To be continued... -ADoes this mean you uploaded a new private build last minute?

[buzzqw]

Which sync option are you testing? The refresh rate of the display (if that's what you mean) only changes with the Sync Display option and it probably won't work with your new-ish nvidia board. You have to check if it is supported by PowerStrip. More documentation on my site. -A

thanks for the answer

i have checked "synch display to video"

could you please link me the power strip on your site ?
i have tryed the search .. but don't seems to works well (too much results)

or i must search on power strip application site ?

thanks again

BHH

[ar-jar]

Does this mean you uploaded a new private build last minute?

I'll try to number the private builds too in the future. Try this one for a fresh start of that numbering :-) -A

[ar-jar]

thanks for the answer

i have checked "synch display to video"

could you please link me the power strip on your site ?
i have tryed the search .. but don't seems to works well (too much results)

or i must search on power strip application site ?

thanks again

BHH

See this page http://www.ostrogothia.com/?page_id=1216 under "Alternative 2". -A

[pirlouy]

Does this mean you uploaded a new private build last minute?
Yes, and this build improved seek function.
And with the new one (9013), it looks like there isn't seek problem anymore.

Thanks ar-jar for your work and your spontaneity !

[Jong]

ar-jar, can you explain to everyone the difference between "glitches" and "frames dropped" in the OSD of your latest private builds?

Is it the difference between frames which are "consciously" never displayed because they are ready too late vs those that are skipped/repeated due to successive frames being presented too close to vsync?

[webs0r]

Awesome, seek problem mostly fixed:

Ar-jar I noticed that on my 60 fps test scenario on HTPC (60 Hz/60 fps source):
- if I have too much processing that can't pump out the frames fast enough (CPU saturated), the video just "freezes" similar to the seek problem before (i.e. sound continues, picture is still). Not sure what the best option is in the scenario as the video would technically be unwatchable anyway, but should it just skip frames, perhaps just display the last frame actually ready at the vsync?
- if I reduce the processing (basically take off spline resize), it works flawlessly <edit: actually it doesn't i just noticed it is dropping every 2nd frame need to test more and get a screenshot>

[tetsuo55]

Awesome, seek problem mostly fixed:

Ar-jar I noticed that on my 60 fps test scenario on HTPC (60 Hz/60 fps source):
- if I have too much processing that can't pump out the frames fast enough (CPU saturated), the video just "freezes" similar to the seek problem before (i.e. sound continues, picture is still). Not sure what the best option is in the scenario as the video would technically be unwatchable anyway, but should it just skip frames, perhaps just display the last frame actually ready at the vsync?
- if I reduce the processing (basically take off spline resize), it works flawlesslyimho it should start dropping frames, and only display frames it has on time for paint

[ar-jar]

Awesome, seek problem mostly fixed:

Ar-jar I noticed that on my 60 fps test scenario on HTPC (60 Hz/60 fps source):
- if I have too much processing that can't pump out the frames fast enough (CPU saturated), the video just "freezes" similar to the seek problem before (i.e. sound continues, picture is still). Not sure what the best option is in the scenario as the video would technically be unwatchable anyway, but should it just skip frames, perhaps just display the last frame actually ready at the vsync?
- if I reduce the processing (basically take off spline resize), it works flawlessly <edit: actually it doesn't i just noticed it is dropping every 2nd frame need to test more and get a screenshot>

Hi, in my notes on my download page I wrote a couple of words about this scenario. It does at least not work too well with Present at nearest option in the 50/50 or 60/60 scenario. Dropping every other frame might be correct if they arrive too late. When it goes black it *might* be because every frame arrives late and the system is choked up basically. But I haven't tested these scenarios too well yet. -A

[webs0r]

Hi ar-jar

Actually upon doing some more testing, I have a feeling it is just an OSD issue..... because it *seems* quite smooth. I know, its subjective but I think it is showing me 60 fps but telling me its only doing 30. Actually I can't really definitively tell, if its dropping every second frame exactly its hard.

http://sharonj81.customer.netspace.net.au/example.jpg
- Please refer to the number of frames dropped - those 160 were from the last few seconds after reset stats, increase at about 30 per second I think
- But the playback is butter smooth
- The sync is fine
- I have cpu/gpu to spare in this test case

[Jong]

The player seems to exit properly with this latest private build. No remnants of the last frame left on the screen, as in my earlier screenshot. Thanks.

[ar-jar]

Actually upon doing some more testing, I have a feeling it is just an OSD issue..... because it *seems* quite smooth. I know, its subjective but I think it is showing me 60 fps but telling me its only doing 30. Actually I can't really definitively tell, if its dropping every second frame exactly its hard.

- Please refer to the number of frames dropped - those 160 were from the last few seconds after reset stats, increase at about 30 per second I think
- But the playback is butter smooth
- The sync is fine
- I have cpu/gpu to spare in this test case

It *is* probably dropping every other frame but since the contents is interlaced you probably don't get more than 30 unique frames anyway so you won't notice losing every other frame. As I said, I haven't managed to put the last bits of the algorithm in place so it doesn't handle the 50/50 or 60/60 case very well. It's a bit of a challenge actually. But I'll get there... -A

[webs0r]

OK. Ready to test whenever :)

Question: When reclock changes playback from 23.9 to 25 fps, how come the OSD still reports 23.9 as the frame rate?

[Jong]

Question: When reclock changes playback from 23.9 to 25 fps, how come the OSD still reports 23.9 as the frame rate?Yes, I'm intrigued by this too.

What is also interesting is the "Actual Frame Rate" reported in Gothsync DOES change when Reclock is making the, much smaller, adjustments to frame rate needed for vsync correction. I had thought that Reclock would simply take the two factors and use them to make one adjustment to the master clock, but it seems frame rate/refresh rate matching and vsync correction are made in different places.

[starla_]

Yes, I'm intrigued by this too.

What is also interesting is the "Actual Frame Rate" reported in Gothsync DOES change when Reclock is making the, much smaller, adjustments to frame rate needed for vsync correction. I had thought that Reclock would simply take the two factors and use them to make one adjustment to the master clock, but it seems frame rate/refresh rate matching and vsync correction are made in different places.

Actual frame rate is calculated based in the rendering stats and the frame rate is most likely read from the media file / samples itself.

[Jong]

Actual frame rate is calculated based in the rendering stats and the frame rate is most likely read from the media file / samples itself.That doesn't match what we are seeing.

[ar-jar]

OK. Ready to test whenever :)

Question: When reclock changes playback from 23.9 to 25 fps, how come the OSD still reports 23.9 as the frame rate?

Please take the 9014 version for a spin. Haven't had much time for testing unfortunately but the older versions are there as a fall-back. Search might still be a bit of an issue.

The frame rate has to do with the fact that Reclock doesn't change the time stamps on the frames (of natural reasons since it's just an audio renderer) and the Frame cycle number is based on those time stamps. Reclock also adjusts the reference clock which I use to measure the Actual frame cycle. So both numbers are off. I could use another clock to measure the actual frame rate of course but haven't got around to it.

Cheers! -A

[webs0r]

9014 is working well for me for up to 30 fps content I haven't yet had a seek issue.
I had one instance where it displayed weird behaviour (dropping frames) before fixing itself, but I'm unable to replicate it now.

Here is a shot of playback of 60 fps content now:
http://sharonj81.customer.netspace.net.au/example2.jpg

- Now it is not dropping every second frame, it is dropping less (good)
- But "randomly" so you do notice constant stutter (bad)
- This does experience the seek issue (but not all the time) where the video will freeze
- When testing on the overloaded cpu scenario the video will freeze as well

[ar-jar]

9014 is working well for me for up to 30 fps content I haven't yet had a seek issue.
I had one instance where it displayed weird behaviour (dropping frames) before fixing itself, but I'm unable to replicate it now.

- Now it is not dropping every second frame, it is dropping less (good)
- But "randomly" so you do notice constant stutter (bad)
- This does experience the seek issue (but not all the time) where the video will freeze
- When testing on the overloaded cpu scenario the video will freeze as well

Thanks for testing! What's our CPU-load when running 60 fps w/o DXVA. I have only been able to test 50 fps @ 50 Hz from a Cyberlink Video/SP decoder that delivers 50 fps in DXVA mode. Do you have any links to true 60 Hz material that I can decode with the internal decoders. Would be useful for further testing. (One of my "problems" is that I have a very powerful computer for compilation purposes and it conceals many timing issues.) -A

[Jong]

The frame rate has to do with the fact that Reclock doesn't change the time stamps on the frames (of natural reasons since it's just an audio renderer) and the Frame cycle number is based on those time stamps.Makes sense, but how come the frame cycle and actual frame rate DO change when Reclock is correction vsync (see those two posts off the Reclock forum I PM'd you)?

[mariner]

Greetings ar-jar.

9014 is quite a disaster, massive number of dropped frames.

Tested with MS decoder, currently the only one that offers FGT.

[STaRGaZeR]

Hi Arto, I've been testing your branch for weeks but didn't have time to properly report these issues. Well, let's get it started because your chenges have lots of potential. I'm using a Samsung 2233RZ, which has a refresh rate of 120Hz. Real 120Hz. Private build 9013 from your site, fresh installations of Vista and Seven x64.

- Issue 1:

I get this glitches every time the device is restarted, by opening a new file, changing the refresh rate when playing videos, etc. They were introduced when beliyaal changed EVR, so they're not caused by your changes, but if you can look into it, it'd be fantastic. I can always reproduce this behaviour. They happen every 2 seconds or so, for 30 seconds or so, then they disappear and playback is perfect.

http://thumbnails3.imagebam.com/4943/4e053d49421905.gif (http://www.imagebam.com/image/4e053d49421905)

When using 60Hz instead of 120Hz, I can't determine the frequency because it changes each time the device is restarted: 6, 20 seconds, whatever. Frame rate or options don't matter.

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

You can't see the next one because it comes 20 seconds after this one.

- Issue 2:

With your builds I get random lockups, the video just freezes while the audio continues for 5 seconds, then it stops too. I can track this one. I think it's the same issue other people are reporting. Happens with any of your sync options.

- Issue 3:

When "Sync video to display" is enabled, weird behaviour when using 120Hz and close frame rates like 23,976 or 29,97, glitches all over the place. Both should be flat lines. Red and green lines are parallel for some time, then an adjustment happens and the green line goes down until it passes the red line, after that, see the screenshot.

http://thumbnails15.imagebam.com/4943/c22a6e49423863.gif (http://www.imagebam.com/image/c22a6e49423863)

- Issue 4:

When "Sync video to display" is enabled, noise and audio glitches can be heard sometimes. Is this normal?


That's all for now, thanks for your hard work :)

[ar-jar]

- Issue 1:

I get this glitches every time the device is restarted, by opening a new file, changing the refresh rate when playing videos, etc. They were introduced when beliyaal changed EVR, so they're not caused by your changes, but if you can look into it, it'd be fantastic. I can always reproduce this behaviour. They happen every 2 seconds or so, for 30 seconds or so, then they disappear and playback is perfect.

When using 60Hz instead of 120Hz, I can't determine the frequency because it changes each time the device is restarted: 6, 20 seconds, whatever. Frame rate or options don't matter.

You can't see the next one because it comes 20 seconds after this one.

- Issue 2:

With your builds I get random lockups, the video just freezes while the audio continues for 5 seconds, then it stops too. I can track this one. I think it's the same issue other people are reporting. Happens with any of your sync options.

- Issue 3:

When "Sync video to display" is enabled, weird behaviour when using 120Hz and close frame rates like 23,976 or 29,97, glitches all over the place. Both should be flat lines. Red and green lines are parallel for some time, then an adjustment happens and the green line goes down until it passes the red line, after that, see the screenshot.

- Issue 4:

When "Sync video to display" is enabled, noise and audio glitches can be heard sometimes. Is this normal?

That's all for now, thanks for your hard work :)

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

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

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

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

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

Thanks! -A

[Jong]

STaRGaZeR,

Some thoughts that may or may not help!

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

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

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

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

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

[Jong]

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

[Jong]

ar-jar,

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

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

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

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

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

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

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

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

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

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

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

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

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

[ar-jar]

ar-jar,

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



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

[STaRGaZeR]

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

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

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

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

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

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

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

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

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

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

STaRGaZeR,

Some thoughts that may or may not help!

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

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

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

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

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

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

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

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

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

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

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

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

Sorry for the long post! :p

[Casshern]

Hi Ar-Jay,

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

[Jong]

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

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

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

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

I think some thoughts for ar-jar are:

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

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

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


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

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

[STaRGaZeR]

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

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

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

I think some thoughts for ar-jar are:

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

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

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

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

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

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

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

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

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

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

No problem.

2ms-4ms:

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

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

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

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

[Jong]

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

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

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

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

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

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

[Leak]

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

[STaRGaZeR]

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

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

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

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

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

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

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

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

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

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

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

Again, the settings needed to obtain the glitches are:

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

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

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

[Jong]

Again, the settings needed to obtain the glitches are:

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

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

[Jong]

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

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

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

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

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

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

[THX-UltraII]

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

[STaRGaZeR]

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

I ask because you said:

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

OK. That's my point.

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

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

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

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

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

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

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

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

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

[Jong]

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

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

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

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

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

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

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

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

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

[Kaotech]

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

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

[STaRGaZeR]

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

[Jong]

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

[Jong]

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

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

[ar-jar]

Hi Ar-Jay,

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

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

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

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

[Jong]

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

Thanks.

[ar-jar]

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

Thanks.

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

[STaRGaZeR]

I have good news :)

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

120Hz goodness:

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

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

[THX-UltraII]

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

[ar-jar]

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

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

[STaRGaZeR]

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

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

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

Another couple of things I've noticed:

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

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

[ar-jar]

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

Another couple of things I've noticed:

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



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

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

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

-A

[STaRGaZeR]

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

[ar-jar]

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

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

[webs0r]

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

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

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

[webs0r]

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

Thanks!

[Astrophizz]

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

[ar-jar]

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

Thanks!

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

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

[ar-jar]

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

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

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

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

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

-A

[pirlouy]

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

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

[webs0r]

Hi ar-jar

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

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

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

[tetsuo55]

Hey webs0r,

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

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

[THX-UltraII]

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

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

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

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

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

thxz

[ar-jar]

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

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

[ar-jar]

Hi ar-jar

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


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

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

[ar-jar]

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

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

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

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

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

thxz

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

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

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

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

Cheers! -A

[STaRGaZeR]

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

Fixed! :)

[webs0r]

Hey webs0r,

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

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

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

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

[webs0r]

Hi ar-jar

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

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

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

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

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

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

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

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

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

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

[ar-jar]

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

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

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

And what happens with or without sync correction using VMR9?

-A

[THX-UltraII]

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

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

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

[ar-jar]

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


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

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

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

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

[webs0r]

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

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

And what happens with or without sync correction using VMR9?

-A

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

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

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

Cheers

[ar-jar]

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

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

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

Cheers

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

[THX-UltraII]

thxz,

How do I set the Target Sync offset and Control limits section?

edit: I ve also noticed that using the Present at nearest Vsync option gives two horizontal lines (green and red) immediately after starting media and checking by pushing ctrl+j. However, with the Sync video to display option the green line start high and it takes some time (1-2 min) before the green line becomes constant horizontal. Is this correct or does this means something is wrong in my setup?

[Jong]

What is the idea behind the "control limits". In the new verson of reclcok we have it down to a 0.5ms window of acceptable offset and that works fine. There seems no reason to let the user decide, let alone have an enormous 2ms window (especially if running at a fast refreahs rate like 120Hz).

[ar-jar]

thxz,

How do I set the Target Sync offset and Control limits section?

edit: I ve also noticed that using the Present at nearest Vsync option gives two horizontal lines (green and red) immediately after starting media and checking by pushing ctrl+j. However, with the Sync video to display option the green line start high and it takes some time (1-2 min) before the green line becomes constant horizontal. Is this correct or does this means something is wrong in my setup?

You adjust the target sync offset and control limits in the Synchronization tab in Options. Target sync offset should be something like 3/4 of a display refresh cycle i.e. 15 ms for 50 Hz or 12 ms for 60 Hz. Control limit can be left at its default value of 1.5 ms (if i remember correctly).

The difference between the sync options is that Present at nearest gives a straight green line per definition as it controls that parameter directly. Sync video adjusts the video stream speed to indirectly achieve a straight green line which may take a while. Several minutes is a bit long though and may mean that you either have a too small adjustment parameter (default is 0.0012 or 0.12%) or that your rates aren't exactly matching so that the sync mechanism is "struggling" to adjust. But as long as you don't get glitches or dropped frames you are fine. -A

[ar-jar]

What is the idea behind the "control limits". In the new verson of reclcok we have it down to a 0.5ms window of acceptable offset and that works fine. There seems no reason to let the user decide, let alone have an enormous 2ms window (especially if running at a fast refreahs rate like 120Hz).

The idea is that you don't want to spend too many CPU-cycles on adjustments either. This is particularly valid for the sync display option that accesses the gfx board registers in the middle of a fiddle. 120 Hz requires much tighter limits of course and thus more CPU. Also, I'm sure the algorithm itself can be improved. It should really be a regular PID control loop. But I have forgotten most of my control theory and the simple algorithm (kind of thresholded P-only) has worked well enough so far. -A

[THX-UltraII]

Target sync offset should be something like 3/4 of a display refresh cycle i.e. 15 ms for 50 Hz or 12 ms for 60 Hz.?:confused:
3/4 of 50 is approx. 38ms and 3/4 of 60 is 45 or am I missing the big picture now ??
Control limit can be left at its default value of 1.5 ms (if i remember correctly).
your standard value is set on 2ms

Several minutes is a bit long though and may mean that you either have a too small adjustment parameter (default is 0.0012 or 0.12%) or that your rates aren't exactly matching so that the sync mechanism is "struggling" to adjust. But as long as you don't get glitches or dropped frames you are fine.
my rates are EXACTLY perfect matching so thats not the problem. Its on 0,0012 now. Should I raise the value to 0.12?

[Jong]

The idea is that you don't want to spend too many CPU-cycles on adjustments either. This is particularly valid for the sync display option that accesses the gfx board registers in the middle of a fiddle. 120 Hz requires much tighter limits of course and thus more CPU. Also, I'm sure the algorithm itself can be improved. It should really be a regular PID control loop. But I have forgotten most of my control theory and the simple algorithm (kind of thresholded P-only) has worked well enough so far. -AIgnoring the "sync display" mode, which I understand is different. With "sync video" the CPU required with a modern CPU is minimal. As you know Reclock without vsync does not correct for drift, and it also stops correcting as soon as it is inside the safety zone (does not force it to the center, let alone the opposite edge.), so in the end it is correcting almost continuously and it is really no overhead at all. And there is no downside. I was worried it might "oscillate" in and out of both sides, but the correction is so gradual it easily stops inside even a 0.5ms window. The benefit of having a tight window easily outweighs the cost IMO.

Just take STaRGaZeR's example@120Hz. Being +1.3ms higher than the goal (which is what he seemed to be getting) turns a possible 4.33ms margin into 3ms, which is quite a significant reduction and makes 120Hz very hard to manage.

If you really like having the bigger margin @50Hz could you make it proportional, so @50Hz it is +/1ms but @120Hz it would be +/-0.42ms. Presumably only those with pretty beefy systems would be trying to run @120Hz smoothly (and if not, that's their problem!) so should easily be able to handle the addition CPU required.

[ar-jar]

?:confused:
3/4 of 50 is approx. 38ms and 3/4 of 60 is 45 or am I missing the big picture now ??

your standard value is set on 2ms

my rates are EXACTLY perfect matching so thats not the problem. Its on 0,0012 now. Should I raise the value to 0.12?

1/50 Hz = 20 ms; 3/4 of 20 ms is 15 ms :-)

0.0012 should be fine but you can experiment a bit if you want to.Some multiple of FPS X (1 + adjustment) should be higher than the display refresh rate wheras FPS X (1 - adjustment) should be lower than the display refresh rate. So if your rates match very closely then adjustment can be very small.

-A

[ar-jar]

Ignoring the "sync display" mode, which I understand is different. With "sync video" the CPU required with a modern CPU is minimal. As you know Reclock without vsync does not correct for drift, and it also stops correcting as soon as it is inside the safety zone (does not force it to the center, let alone the opposite edge.), so in the end it is correcting almost continuously and it is really no overhead at all. And there is no downside. I was worried it might "oscillate" in and out of both sides, but the correction is so gradual it easily stops inside even a 0.5ms window. The benefit of having a tight window easily outweighs the cost IMO.

Just take STaRGaZeR's example@120Hz. Being +1.3ms higher than the goal (which is what he seemed to be getting) turns a possible 4.33ms margin into 3ms, which is quite a significant reduction and makes 120Hz very hard to manage.

If you really like having the bigger margin @50Hz could you make it proportional, so @50Hz it is +/1ms but @120Hz it would be +/-0.42ms. Presumably only those with pretty beefy systems would be trying to run @120Hz smoothly (and if not, that's their problem!) so should easily be able to handle the addition CPU required.

You can probably narrow down the control limtits. I'm testing 0.5 ms right now and that works fine. The smaller the band, the better match between frame rate display refresh rate is required though as you need to decrease the adjustment factor too not to get oscillation.

There is an inherent problem though: the real-time characteristics of Windows are not 100% as you know. And timer resolution is typically 1 ms. So getting sub-ms precision is not easy.

-A

[Jong]

Yes, Reclock slows down its correction as it gets closer to the target to avoid oscillation. I know what you mean about timers. I am not sure about your algorithm, but Reclock is targeting an AVERAGE offset and manages to hold that nicely in the zone. The spread though is still +/- 1-2ms so individual frames will fall outside. But that's OK, it will not peak more than say 2ms higher e.g. -16ms +/- 0.5ms -2ms = -18.5ms worst = safe @50Hz. However, if the acceptable range for the offset = +/- 2ms then you have -16ms +/- 2ms -2ms = -20ms worst = NOT SAFE. So better to keep a tight control of the average even though you cannot control each frame to that accuracy.

[THX-UltraII]

1/50 Hz = 20 ms; 3/4 of 20 ms is 15 ms

So what value do I use for the best result if I my display is running @1920x1080@23,976Hz?

[Jong]

You have sooo much time @23.976 it is not so important. You could use 21ms (half way), 30ms (3/4s of the way, recommended for 50Hz/60Hz) or 36ms (still plenty of margin from 42ms). All should work equally well. I'd go somewhere between 30 and 36ms.

[THX-UltraII]

You have sooo much time @23.976 it is not so important. You could use 21ms (half way), 30ms (3/4s of the way, recommended for 50Hz/60Hz) or 36ms (still plenty of margin from 42ms). All should work equally well. I'd go somewhere between 30 and 36ms.

So 33 is ok? Is this also ok for my PAL material? (if I play PAL material is switch to my second profile 1920x1080@25,000Hz)

btw. Have you read about a new audio renderer that is comming soon for MPC-HC; will this make Reclock redundant?

[webs0r]

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

Hi Ar-jar

When I drag the window to the bottom it runs fine actually.
Also updated my nv drivers to version 191... but didn't make a difference :)

What i don't get is (in fullscreen) why there are a lot less glitches when I have only the summary stats displayed... why would that be? i.e. one every 5-10 seconds vs. craziness with the full stats.

So no stats - lots of glitches
2x ctrl-J - nearly perfect but occasional glitches
3x ctrl-J - medium glitches (not as bad as no stats)

Isn't that strange?

I'm going to test a 50 fps/50 Hz scenario (aus tv cap) on the other computer and see how it goes.

[Jong]

So 33 is ok? Is this also ok for my PAL material? (if I play PAL material is switch to my second profile 1920x1080@25,000Hz)

btw. Have you read about a new audio renderer that is comming soon for MPC-HC; will this make Reclock redundant?33ms should be good for 25Hz, but not of course for 50Hz. At the moment you have to specify one figure for all refresh rates so unless you want to change it all the time I would set to 15ms if the max rate you use is 50hz and 12ms if the max rate is 60Hz. Really your call on how much messing around you want to do.

Yes, I have briefly seen talk about the new renderer. Don't think it does any frame rate changing though - e.g. PAL @24p - does it? But if you always use closely matched rates then maybe that plus the Gothsync merged renderer will do you.

[THX-UltraII]

33ms should be good for 25Hz, but not of course for 50Hz. At the moment you have to specify one figure for all refresh rates so unless you want to change it all the time I would set to 15ms if the max rate you use is 50hz and 12ms if the max rate is 60Hz. Really your call on how much messing around you want to do.
So if I have two proflies (23,976Hz and 50,000Hz) I can set it on 15ms and everything should work fine?

Yes, I have briefly seen talk about the new renderer. Don't think it does any frame rate changing though - e.g. PAL @24p - does it? But if you always use closely matched rates then maybe that plus the Gothsync merged renderer will do you
From what I understand it will not do PAL-speeddown so this will be a Reclock exclusive feature for now. However, Since yesterday I use the 'bit perfect' feature of Reclock ('slave reference to master' and 'original speed' settings) so with this you HAVE to switch between 2 profiles when you live in PAL-land and play both 23,976 and 25,000 material because 'bit perfect' does not let you do PAL-speeddown in Reclock.

[THX-UltraII]

Ar-Jar:
I ve just noticed that I get tearing on the top of the screen when I start playing content. This tearing moves away vertically and vanishes within a few seconds. I played with some settings and found out that I can remove it by putting MPC-HC in d3d fullscreen. However, this mode gives me too much troubles and I don t want to use this. So I did some more testing and found out that it might has something to do with the EVR buffer settings. This is standard on 5 and changing this make the tearing in the beginning of content behaves different. What are the recommended settings for EVR buffer and is it correct that this has affect on tearing?

Is it also still the best to only do one of your 3 sync settings and leave all the rest (Vsync, Accurate Vsync, Alternate Vsync) off?

[Jong]

So if I have two proflies (23,976Hz and 50,000Hz) I can set it on 15ms and everything should work fine?Should be fine, yes.

You are just not getting as much benefit of judder protection @24p as you could if you manually set 30-36ms. But if your PC is running half decently 15ms of protection should be fine.

[Jong]

Ar-Jar:
I ve just noticed that I get tearing on the top of the screen when I start playing content. This tearing moves away vertically and vanishes within a few seconds. I played with some settings and found out that I can remove it by putting MPC-HC in d3d fullscreen. However, this mode gives me too much troubles and I don t want to use this. So I did some more testing and found out that it might has something to do with the EVR buffer settings. This is standard on 5 and changing this make the tearing in the beginning of content behaves different. What are the recommended settings for EVR buffer and is it correct that this has affect on tearing?

Is it also still the best to only do one of your 3 sync settings and leave all the rest (Vsync, Accurate Vsync, Alternate Vsync) off?Post a screen shot of the <ctrl>-J stats when this is happening. Preferably capture the stats just after you have seen some tearing so it will still be captured in the jitter chart.

[webs0r]

My test result on the other computer with 50 fps content on 50 Hz refresh rate works perfectly without glitches.

Moving the sync offset is pretty cool (purely for interest), if I stay between 2 and 18 ms on 50 Hz, it is glitch free.

I set it to 13 ms though as I have reclock switching refresh rate between 50 & 60 depending on the content.

So far I'm very impressed with the progress - great work Ar-jar!!

[THX-UltraII]

Post a screen shot of the <ctrl>-J stats when this is happening. Preferably capture the stats just after you have seen some tearing so it will still be captured in the jitter chart.

I m @work now but I ll post a screen tonight.

[starla_]

There is an inherent problem though: the real-time characteristics of Windows are not 100% as you know. And timer resolution is typically 1 ms. So getting sub-ms precision is not easy.

One ugly way (most likely the only one) is to use timer that fires of few ms before the real intented event and then busy poll the few next ms until the correct time is reached (not CPU friendly :)).

[Perls]

Hi there ar-jar,

I am a user of the regular mpc-hc together with re-clock (for 24p on 50 Hz 1080p display). This works very well for me, but I wanted to give your branch a little testing too.

I have tried the following on 9018 together with ffdshow and re-clock. Vsync, accurate vsync and present at nearest vsync was enabled in the settings.

Wall-E blu-ray: Started this a few times and it worked very well most of them. A few small spikes in the osd but no lost frames or sync glitches registered. At one occasion it did however start "out of sync" with constant glitches and dropped frames which it didn't recover from.

Casino royale blu-ray: works pretty well but actually registers some sync glitches but no lost frames, I don't think I would have noticed without the OSD

Golden compass blu-ray: repeatably works for about a minute but then the sync is all over the place with lots of glitches and lost frames, it recovers briefly only too soon loose it again and it doesn't seem to recover from the constant stuttering after that. This film is in VC1 and actually requires less cpu than the other two. With the regular MPC-HC it does however require that frame time correction is enabled to play smoothly (which it also was during this test) if that may have something to do with this behaviour? It does however seem to lose sync at the same place each time, where it co-incidentally is a rise in cpu-load, still pretty low load compared to the first two films however.

Yes, I know these kinds of "no hard data trouble reports" are next to impossible to work with, but I wanted to share it anyways:) And btw, thank you for sharing your work!

[Jong]

One ugly way (most likely the only one) is to use timer that fires of few ms before the real intented event and then busy poll the few next ms until the correct time is reached (not CPU friendly :)).You do not need to time it exactly +/- 2ms from frame to frame is fine. You just need to be sure the average around which it is oscillating is tightly controlled. If the average can be +/- 2ms either way and THEN it oscillates +/- 2ms around that you have a problem, as I think was demonstrated @120Hz.

[ar-jar]

Ar-Jar:
I ve just noticed that I get tearing on the top of the screen when I start playing content. This tearing moves away vertically and vanishes within a few seconds. I played with some settings and found out that I can remove it by putting MPC-HC in d3d fullscreen. However, this mode gives me too much troubles and I don t want to use this. So I did some more testing and found out that it might has something to do with the EVR buffer settings. This is standard on 5 and changing this make the tearing in the beginning of content behaves different. What are the recommended settings for EVR buffer and is it correct that this has affect on tearing?

Is it also still the best to only do one of your 3 sync settings and leave all the rest (Vsync, Accurate Vsync, Alternate Vsync) off?

What sync option do you use when you get the initial tearing? If you use sync display or sync video you may get it while it gets into the right position which may take a few secs. What does the green line look like during the tearing? With Present at nearest you should be in the sweet spot timing-wise from the start (you may get the occasional glitch though). If you set sync offset to say 3/4 of a refresh cycle, there shouldn't be any tearing. Or so the theory goes - this of course depends both on the driver and the gfx board itself. Specs are loosely interpreted in this industry... -A

Edit: Those sync options are "disconnected" for the moment so either way works.

[BatKnight]

ar-jar

I've tested your latest 9018 build. I am getting the lines up and down. Screenshot:
http://i.imagehost.org/0437/gothsync9018_1.jpg
Is this right?

This is what I get with the normal MPC-HC build 1290: screenshot:
http://i.imagehost.org/0120/mpchc1290_1.jpg

Should the red lines be like this on your build?

I don't use Reclock and I don't use SPDIF.
Thanks

Bat

[pirlouy]

"Attachments Pending Approval"

-> Please, use images hosting website instead of this functionality. Else you can't be sure people won't forget to read your post again...

[BatKnight]

"Attachments Pending Approval"

-> Please, use images hosting website instead of this functionality. Else you can't be sure people won't forget to read your post again...
Thanks, just did it..

Bat

[tetsuo55]

@BAtknight > that looks perfectly normal for you 60hz display.

[BatKnight]

@BAtknight > that looks perfectly normal for you 60hz display.
OK, I understand. What about the sync glitches that keep rising all the way the movie plays. On a utopic view shouldn't the glitches be 0 or near it?

Another thing, my screen alows 60Hz and 50Hz and most of the videos I play are NTSC, should I keep 60Hz or should I go to 50Hz, in terms of smooth playing.

Bat

[tetsuo55]

OK, I understand. What about the sync glitches that keep rising all the way the movie plays. On a utopic view shouldn't the glitches be 0 or near it?

Another thing, my screen alows 60Hz and 50Hz and most of the videos I play are NTSC, should I keep 60Hz or should I go to 50Hz, in terms of smooth playing.

Batglitches will only be near 0 if the video refreshrate and display refreshrate are exact matches.

[pirlouy]

@BatKnight: some people will tell you to use 50Hz and reclock (to play at 25fps) in order to have perfect sync.

In my case, I have the same graph as you for 24fps video for my 60Hz screen. And I don't see anything wrong when I watch a video.

I've already tried 24fps movie in 24, 50 or 60 Hz on my HD TV with MPC-HC Gothsync and reclock (to play at 25fps) and my conclusion is:
- when my TV is in 24fps: I have jerky video and audio can be staggered; unusable
- in 50Hz: I don't have noticed something better than 60Hz; I mean I don't find video smoother...
- in 60Hz: I can watch 24 fps video without seeing jerks problems, and I play 30fps video without problem as well.

60Hz is a good compromise, I think. 120Hz is surely the better choice, but I think it should use more energy (and you have to have a compatible TV).

[BatKnight]

60Hz is a good compromise, I think. 120Hz is surely the better choice, but I think it should use more energy (and you have to have a compatible TV).

I also don't have problems with smooth playing. I just saw those glitches on the stats and the red line going up and down and didn't if it was supposed to. The green line is much more steadier on Gothsync's version than on the normal MPC-HC. Is this the result of a better sync or the builds just present it differently?

On this case, 60Hz, which value of sync offset should be the better?

Bat

[STaRGaZeR]

- when my TV is in 24fps: I have jerky video and audio can be staggered; unusable

Jerky?

I also don't have problems with smooth playing. I just saw those glitches on the stats and the red line going up and down and didn't if it was supposed to. The green line is much more steadier on Gothsync's version than on the normal MPC-HC. Is this the result of a better sync or the builds just present it differently?

The graphs are the same. Only at different scales.

[Jong]

OK, I understand. What about the sync glitches that keep rising all the way the movie plays. On a utopic view shouldn't the glitches be 0 or near it?

Another thing, my screen alows 60Hz and 50Hz and most of the videos I play are NTSC, should I keep 60Hz or should I go to 50Hz, in terms of smooth playing.

BatPersonally I go the 50Hz route, but you need Reclock for that. Then you can have perfectly smooth playback, but you do get "PAL speedup" of course of the movie and soundtrack. I'm used to it after years of PAL DVDs though. If you do do this do not use Reclock to "pitch correct" the soundtrack as it destroys the phase coherence. Although all the channels are independently of quite good quality you lose 3D positioning, which is a big deal for 5.1/7.1 movies!

[BatKnight]

The graphs are the same. Only at different scales.
OK then. Sorry if the following question sounds stupid, but what are the advantages of Gothsync's version over the one already implemented on MPC-HC, when it comes to 60Hz TVs, if on both I get the same results?

Bat

[Jong]

For me 50hz is much smoother than 60Hz. It certainly should be.

but I think most in the US are used to pulldown judder in the same way most in Europe are used to PAL speedup. We don't notice each others afflictions!

[Jong]

OK then. Sorry if the following question sounds stupid, but what are the advantages of Gothsync's version over the one already implemented on MPC-HC, when it comes to 60Hz TVs, if on both I get the same results?

BatNot much. Its benefits are mostly when you DO have matching rates.

[Keiyakusha]

Hi.
Lets say I have 85Hz display and NTSC video with 30000/1001 framerate. I'm running it through avisynth script which contains only one filter ConvertFPS(85,3). Can someone recommend me how should I setup sync options for playing this?

[Jong]

I would try using sync video to display with an offset of 8ms and +/-1ms control limits. Then look at the jitter chart. If you get spikes on the red line when the green line is going up, not down then you may need to reduce the offset to 7ms. You will need to make sure your PC has minimal background processes running to ensure delays in presentation (spikes down in the green line) are never greater than 5-6ms (for 7 or 8ms offset) as @85Hz anything greater will cause a judder.

[Keiyakusha]

Jong
I really can get nice results with this settings, thanks! Now I have better place to start tweaking things. Here (http://img0906d.image.vc/out.php/i137387_1.jpg) is what it looks like now. Before there was insane spikes ^_^
And if it is interesting to someone... I see something like this (http://img0906d.image.vc/out.php/i137388_2.jpg) using non-gothsync build 1285. Vsync and Acurate vsync on, alternative vsync off, aero on, GPU flushes on.

[pirlouy]

Jerky?
Yes. I think it's what you call "glitches".
But when you have 1 glitch with a 24 Hz screen, it's really visible ans it's annoying.

With 60Hz, you don't notice glitch since there are always glitches, and they are very brief, so your eyes don't see these jerks and all looks smooth in fact. Of course, it would be better with 72,96 or 120Hz screen, but TV use 60Hz at maximum I think.

[pirlouy]

For me 50hz is much smoother than 60Hz. It certainly should be.

In my case, I've tried to search for differences (using reclock), and I've seen nothing particular (except the graph which is much more beautiful ! :D)
But I guess you should use advanced settings I don't understand.

[webs0r]

OK, I understand. What about the sync glitches that keep rising all the way the movie plays. On a utopic view shouldn't the glitches be 0 or near it?

Another thing, my screen alows 60Hz and 50Hz and most of the videos I play are NTSC, should I keep 60Hz or should I go to 50Hz, in terms of smooth playing.

Bat

I use reclock to solve this issue.

Reclock can take 23.9/24 fps source and move it to 25 fps and switch my display to 50 Hz so it matches. It will take 29.9 fps source and move it to 30 fps and switch my display to 60 Hz to match.

This way you get judder free playback on a screen that doesn't support anything other than 50/60 Hz.

[Casshern]

Hi there,

tested the newest private build (Win 7x64 / ATI 2600 PRO AGP / approx 47.952 with powerstrip / Reclock). It works somewhat better than before:
1) recovers from seeking better
2) adjusting vsync offset (+3)allowed for tearing free playback with my two pet shaders (YV12 chroma upsampling / slightly modified complex sharpen)
But some issues still remain
1) vsync offset has to be different for different material (offset -3 for a low res xvid compared to offset +3 for a blu ray h264 stream)
2) beliyaals code is still much faster and robust for me: it allows for bicubic resizing, and does not tear if for example the stats display is on, or even the sync offset osd - which kind of makes is tricky to find the correct offset as one has to wait for the sync offset osd to vanish
3) black screen bug - this i finally found out is not tied to dxva playback, it also occurs with software decoding and also with the regular versions with beliyaals code (although not as severe): here when ever a black screen is to be rendered (especialy during fade outs) the tearing bar shows severe judder - naturally this is not visible during movie watching (as it is a black screen) but with the gothsync code it also gives sometimes sound dropouts. I think its a long standing bug where if the render code is done to early (much to fast) it leads to problems. It could also be that windows (evr and also vmr9) render/paint black frames much faster as anticipated by the sync code. With beliyaals code this was rare and cosmetic (as i do not watch the tearing bar) but the occasional sound drop outs with the gothcode are worrying - but will investigate further.

But still great progress....


p.s.: All vsync options were off except for present at nearest vsync. Desktop composition was disabled.

[STaRGaZeR]

Yes. I think it's what you call "glitches".
But when you have 1 glitch with a 24 Hz screen, it's really visible ans it's annoying.

With 60Hz, you don't notice glitch since there are always glitches, and they are very brief, so your eyes don't see these jerks and all looks smooth in fact. Of course, it would be better with 72,96 or 120Hz screen, but TV use 60Hz at maximum I think.

Of course, but why did you get that glitch? If you're watching 23,976FPS material in a 23,976Hz TV you shouldn't get any glitches, and if you got one that's something that should be investigated.

I agree you don't see rare glitches when they are in between a lot more. But calling the normal ones "smooth"... I don't know what are you watching in your TV, but 24FPS material in a 50Hz or 60Hz TV looks horrid to me, and the usual glitches of these configurations just can't look smooth. However you're probably like most people in the USA, they've been seeing that effect since forever and they just don't notice it anymore, it's normal for them.

You will see lots of real 120Hz TVs soon, it's a requirement for the type of 3D TV the big companies want to use in the near future. In fact the very few 120Hz monitors currently in the market (only 2!) are here because of NVIDIA's 3D too.

[webs0r]

If you don't notice the glitches then it's fine really, you don't need to change your setup.
The problem is once you start noticing them, you really want them gone!

If you like some types of videos like docos that include slow panning side to side or zooming in and out that's when you'll notice them more. Especially if you're watching something in nice 720/1080 quality, then it starts panning and erk erk erk erk erk ..... sorry trying to verbalise the glitches... its quite annoying.

I also find the size of the screen - the bigger it is (or the closer you sit), the easier they are to notice. Maybe because of the bigger field of view it takes up in your vision, the brain's visual system interprets low fps as smooth but the glitches interfere with that interpretation and doesn't like it.

That's why this software & reclock are soooo good.

[webs0r]

Hi there,

tested the newest private build (Win 7x64 / ATI 2600 PRO AGP / approx 47.952 with powerstrip / Reclock). It works somewhat better than before:
1) recovers from seeking better
2) adjusting vsync offset (+3)allowed for tearing free playback with my two pet shaders (YV12 chroma upsampling / slightly modified complex sharpen)
But some issues still remain
1) vsync offset has to be different for different material (offset -3 for a low res xvid compared to offset +3 for a blu ray h264 stream)
2) beliyaals code is still much faster and robust for me: it allows for bicubic resizing, and does not tear if for example the stats display is on, or even the sync offset osd - which kind of makes is tricky to find the correct offset as one has to wait for the sync offset osd to vanish
3) black screen bug - this i finally found out is not tied to dxva playback, it also occurs with software decoding and also with the regular versions with beliyaals code (although not as severe): here when ever a black screen is to be rendered (especialy during fade outs) the tearing bar shows severe judder - naturally this is not visible during movie watching (as it is a black screen) but with the gothsync code it also gives sometimes sound dropouts. I think its a long standing bug where if the render code is done to early (much to fast) it leads to problems. It could also be that windows (evr and also vmr9) render/paint black frames much faster as anticipated by the sync code. With beliyaals code this was rare and cosmetic (as i do not watch the tearing bar) but the occasional sound drop outs with the gothcode are worrying - but will investigate further.

But still great progress....


p.s.: All vsync options were off except for present at nearest vsync. Desktop composition was disabled.

Interesting, I think I understand the buffering more from these observations.

So it is buffering the frames before it hits the shaders, rather than the final processed output (incl OSD stats)?
If that was buffered then changing shader options you'd think shouldn't affect the vsync offset interaction as the final frame would always be ready to go?

I wonder if changing this approach would help?
Might introduce some tiny lag for the OSD (after pressing ctrl+j)... maybe some other side effects as well...

[pirlouy]

I've just taken a printscreen of a 24p videos on my 24Hz display. There is no glitches (129 is when I've launched video). All looks great but in fact, sometimes I have jerks (in fact you call that "judder" I think), but there is no way to see it in numbers. And more, sometimes I have audio lags, and numbers don't show anything.

http://img136.imageshack.us/img136/4358/gothsync1.jpg

In order not to have audio lag, I need to use 50Hz at minimum. And in order to have no judder (or I should say "in order not to perceive judder"), I need to have 60Hz at minimum. Yes, I have judder with 50Hz and reclock (even if numbers and graph look perfect).

[Jong]

A few thoughts.

- What are you watching? It is VERY common, for example, that TV show captures have judder encoded at capture time. That is one cause of judder with no glitch in Gothsync. It almost always happens when there is overlayed graphics eg. advertising other shows (the graphics is normally "video" ie. interlaced and it throws the deinterlacer of the capture card), but it happens at other times too just due to broadcast glitches. You can tell by skipping back and going over the same point. Encoded glitches will reliably repeat in the same location.

- Why are you running with such a small offset? @24p you could easily set up to 36ms, which would give you far more protection from possible local glitches. If you want compatibility with 60Hz you could set @12ms which would help enormously.

- When testing, hit <ctrl><alt>r after the first few seconds, when the graph as settled. This will reset all the stats so you can see if there have been any real, local glitches and how big the biggest spikes in the green line were.

A few questions, what do you mean by audio lag? Are saying the audio video sync varies over time? And that sometimes the audio is very late? How bad? Is audio ever early?

[ar-jar]

Interesting, I think I understand the buffering more from these observations.

So it is buffering the frames before it hits the shaders, rather than the final processed output (incl OSD stats)?
If that was buffered then changing shader options you'd think shouldn't affect the vsync offset interaction as the final frame would always be ready to go?

I wonder if changing this approach would help?
Might introduce some tiny lag for the OSD (after pressing ctrl+j)... maybe some other side effects as well...

In windowed mode (and non-exclusive mode full-screen), the renderer uses one single back buffer (both in my build and the regular build). (The back buffer is the memory into which the image is renderered - after shaders and all.) In my own experimental player , GothPlayer, I used triple-buffering which seemed to eliminate some problems. I have briefly tried to change the directx flip/copy method in the MPC directx renderer and add buffers to windowed mode but it didn't immediately work. I need to look more into that. (It worked in my player so it shouldn't be impossible.) I think it was Jong who said that Reclock also works better with double of triple buffering. Exclusive mode (D3D) fullscreen is using triple buffering so it should work better for most people.

Any buffering before the rendering may be useful to even out decoder load. On any reasonable hardware the number of buffers (that you can select in the options) doesn't seem to make much difference though as decoding is rather effortless. -A

[pirlouy]

- I can assure it's not in the video, since judder is not always at the same place.
- I've tried several settings (even if I don't understand anything, but I haven't seen differences.

In fact, I'm not sure:

http://img12.imageshack.us/img12/3001/gothsync2.jpg

With this graph, knowing I'm in 24 Hz, I should have several glitches, like if video was jerky, shouldn't I ? Because in fact the graph panics, but I don't see any judder during this time. Could it be possible that the graph is not right ? :/

[ar-jar]

- I can assure it's not in the video, since judder is not always at the same place.
- I've tried several settings (even if I don't understand anything, but I haven't seen differences.

In fact, I'm not sure:

http://img12.imageshack.us/img12/3001/gothsync2.jpg

With this graph, knowing I'm in 24 Hz, I should have several glitches, like if video was jerky, shouldn't I ? Because in fact the graph panics, but I don't see any judder during this time. Could it be possible that the graph is not right ? :/

Hi, this looks like you don't have matching rates. The video is running slower than the display. My guess is that your display is at 24 Hz and the video is 23.976 fps. This is not a situation handled by the Sync Video sync option that you have selected. Cheers! -A

Edit: may be I answered the wrong question :-) Yes you should see judder and you will if the ugliness in the graphs conicide with a pan scene in the movie. The graph is most likely correct wrt timings.

[Jong]

Yeah, the green line should not be slopping like that. Can we have a full screenshot?

[pirlouy]

Hi, this looks like you don't have matching rates. The video is running slower than the display. My guess is that your display is at 24 Hz and the video is 23.976 fps. This is not a situation handled by the Sync Video sync option that you have selected. Cheers! -A
Ok. Then I really have not understood what Goth Sync offers. I'll try to read your doc again. I thought that was the aim of Goth Sync: sync video and refresh rate when they are really close (like 23.976 and 24).
Maybe a guru should write a topic "how to (and why) achieve smoothness video playback" for people like me...

Edit: may be I answered the wrong question :-) Yes you should see judder and you will if the ugliness in the graphs conicide with a pan scene in the movie. The graph is most likely correct wrt timings.
Then I confirm I don't see judder. But for information, I've tried with these settings:
http://img196.imageshack.us/img196/4112/gothsync3.png
If I set "Target sync offset" to 12ms, the graph is prettier but I don't see differences when watching video. I've tried with different values, but result is not each time the same (judder-free or not).

But as I say, I think it's just 24 Hz which is unusable and there's nothing we can do.


@Jong: http://img159.imageshack.us/img159/3397/gothsync4.jpg

[STaRGaZeR]

Don't use Sync video to display otherwise you'll get what you're seeing. Use Present at nearest VSync, you'll get a flat line and no judder except for one glitch each 10-15 seconds because of the 23,976-->24 mismatch. If you want a perfect line with no glitches whatsoever use Reclock, configured to Nearest integer speed. It will accelerate your video a little to 24FPS and you'll achieve perfect sync with no glitches.

@ar-jar, now we get those glitches (I get the same, you can see it in my previous screenshots) when trying to do 23,976-->24. It's possible to modify your algorithm so it can be properly done or it's just impossible by design? Also there's a new audio renderer coming to MPC-HC with WASAPI support, maybe it can be useful for all the sync stuff.

[noee]

If you want a perfect line with no glitches whatsoever use Reclock, configured to Nearest integer speed. It will accelerate your video a little to 24FPS and you'll achieve perfect sync with no glitches.

THis is exactly what I use with the MPC-Goth trial and the latest (9018) is giving me outstanding results. Pirlouy, if you are playing back 23.976fps on a 24Hz display, this is the best option.

[STaRGaZeR]

I also use that config but with 120Hz, perfect results too.

[Jong]

Don't use Sync video to display otherwise you'll get what you're seeing. Use Present at nearest VSync, you'll get a flat line and no judder except for one glitch each 10-15 seconds because of the 23,976-->24 mismatch. If you want a perfect line with no glitches whatsoever use Reclock, configured to Nearest integer speed.Reclock configured to "AUTO" is fine too, and no need to mess around when you change configs/refresh rates..

And you shouldn't get a glitch every 1-15 secs surely. Mayeb ar-jar can confirm, but I'd have though it was only approximately every 1000 secs, minus a "safe margin" of maybe 10% or so?

[starla_]

And you shouldn't get a glitch every 1-15 secs surely. Mayeb ar-jar can confir, but I'd have though it was only approximately every 1000 secs, minus a "safe margin" of maybe 10% or so?

Actually it is more closely to the 40 seconds. 23,976 / 24 approx every 1000th frame and 24 fps per seconds 1000 / 24 is approx 41 seconds.

[Jong]

Of course, don't know what I was thinking :stupid:

[pirlouy]

This is a printscreen with these settings:
- reclock active
- refresh rate: 50 Hz
- Present at nearest vsync; 10 ms (9018 build)

http://img203.imageshack.us/img203/4295/gothsync5.jpg


And I have judder.

It's just for information, I would totally understand if you have nothing to answer or if you were bored.

[Jong]

Are you saying you see judder when the OSD is smooth? And you are sure it is not encoded into the video?

If so, what is your display? Does it truly support 50Hz? Your display could be adapting the signal to an internal 60Hz rate.

[ar-jar]

This is a printscreen with these settings:
- reclock active
- refresh rate: 50 Hz
- Present at nearest vsync; 10 ms (9018 build)

And I have judder.

It's just for information, I would totally understand if you have nothing to answer or if you were bored.

I understand that you have reset the statistics right before the screeshot. When you see the judder, do you see either "sync glitches" or "frames dropped" increase? Those two numbers should really catch all types of judder due to rate mismatch (or so the theory goes at least).

A "sync glitch" means that two frames are presented with a distance (in time) that deviates significantly from the average distance between frames. In your case most frames are presented with 40 ms distance (2 display cycles) but because there is a mismatch in rates (41.7 ms vs 40 ms), every now and then frames are presented with a 60 ms distance which is interpreted as a "sync glitch". You may or may not see this depending on the contents of the video.

Frames are dropped only when the fps of the video in is larger than the display refresh rate (e.g. 60 fps @ 50 Hz or more commonly perhaps 50 fps @ 49.9... something, i.e. a simple inaccuracy).

-A

[ar-jar]

Actually it is more closely to the 40 seconds. 23,976 / 24 approx every 1000th frame and 24 fps per seconds 1000 / 24 is approx 41 seconds.

If you are running 23,976 @ 48 Hz, which is perhaps more commonly attainable than 24 Hz, you would get a "half-glitch" every ~20 seconds as the frame presentation time is only shifted one display cycle ~0.5 frame cycles at each time. -A

[STaRGaZeR]

Reclock configured to "AUTO" is fine too, and no need to mess around when you change configs/refresh rates..

And you shouldn't get a glitch every 1-15 secs surely. Mayeb ar-jar can confirm, but I'd have though it was only approximately every 1000 secs, minus a "safe margin" of maybe 10% or so?

AUTO plays 25fps content as 25,714fps, so it's a no go. Also, I don't change refresh rates or anything, and nearest integer works just fine with every frame rate I use.

I've measured it. Each 23,976-->24 glitch happens every ~8,5s at 120Hz.

[ar-jar]

I've measured it. Each 23,976-->24 glitch happens every ~8,5s at 120Hz.

And that's a "1/5:th glitch" instead of a "full glitch" which you get at 24 Hz display refresh. The present timing is shifted 8.3 ms each time instead of 41.7 ms (but it is shifted 5 times as often). I'm not really sure which is better. What do you guys think? -A

[Casshern]

Well, i think you mean the same thing. Let me explain a little more:
1) The vsync code is executed during the vblanking interval at display refresh frequency
2) From my observations it draws the osd, the stats screen, flips the next buffer, calculates the next vsync flip time and invokes the shaders (
3) I think some of the stuff should not be done in the vblank at all, some stuff should probably be done in a different order.

a) the shaders do not have to be done at screen refresh rate. Obviously they should be done on the frames coming from the decoder. So when your display refresh rate is twice the movie frame rate, at the moment, the shaders are applied twice for every movie frame. Unnecessary because the second frame displayed is identical.
b) the osd should be applied after all vsync code is finished (buffers are flipped), maybe even outside the vsync code (as a tear in the stats is not important, but of course the tearing bar must be done in the vsync code) and should be optimized to be faster. Its eating 10-20 scanlines at 1920x1080 with a 118Mhz pixel clock.
c) There is a bug in the vsync code that when the rendered image is completely black and the code is actually finished to fast, theres a problem as the tearing bar begins to judder. This is normally not important as after all one is not watching the tearing bar - but with the gothcode i had some audio dropouts. This might also have to do with the order in which the code does its stuff.
d) In principal it shouldn't matter if the dxva engine, the shaders etc use up less than 1/23.976023976s (movie frame duration) even on a 47.952 refresh rate display. At the moment this is not the case with the stats- for obvious reason (as the stats are outputted every refresh cycle). This i can understand but without any of that stuff the code should be robust enough to handle these cases. In that respect the beliyaal code still has the edge.

e) the resizer is also applied every refresh cycle - unnecessarily. But fortunatly due to my findings in the other thread at least it now only resizes if screen resolution is different from movie res. For some experiencing tearing on slower cards they could try a faster algo (bilinear - ugly but maybe the tearing is gone)

In summary - the gothcode is getting better, for me the beliyaal code still has some tiny edge. But if ar-jay continues at his pace, i have no doubt the gothcode will soon be better in all respects.

regards,

Casshern

Interesting, I think I understand the buffering more from these observations.

So it is buffering the frames before it hits the shaders, rather than the final processed output (incl OSD stats)?
If that was buffered then changing shader options you'd think shouldn't affect the vsync offset interaction as the final frame would always be ready to go?

I wonder if changing this approach would help?
Might introduce some tiny lag for the OSD (after pressing ctrl+j)... maybe some other side effects as well...

[Jong]

AUTO plays 25fps content as 25,714fps, so it's a no go. Also, I don't change refresh rates or anything, and nearest integer works just fine with every frame rate I use.If it works for you fine. But there is somethig wrong if AUTO is playing @25.714 with 50Hz refresh. Screenshot?

[Jong]

I've measured it. Each 23,976-->24 glitch happens every ~8,5s at 120Hz.Yeah, I had a brainstorm there. ar-jar has explained.

[pirlouy]

Are you saying you see judder when the OSD is smooth? And you are sure it is not encoded into the video?
I understand that you have reset the statistics right before the screeshot. When you see the judder, do you see either "sync glitches" or "frames dropped" increase? Those two numbers should really catch all types of judder due to rate mismatch (or so the theory goes at least).
Yes; even if OSD shows great things, video is not smooth. When I watch graph, I can easily see this graph is not smooth.
Whereas the green line looks smooth on 60Hz !

I have reset stats just after the beginning. After that, OSD does not show glitches or dropped frames.


If so, what is your display? Does it truly support 50Hz? Your display could be adapting the signal to an internal 60Hz rate.
It's a Samsung 40B530. It can display 24, 50, 60 Hz. I use a dvi/hdmi adapter for graphic card. I use Windows 7 RC1.

But, is it normal not to find graph smooth ?

[webs0r]

Are you saying you see judder when the OSD is smooth? And you are sure it is not encoded into the video?

If so, what is your display? Does it truly support 50Hz? Your display could be adapting the signal to an internal 60Hz rate.

One way to help see judder that is encoded into the video it to use the freshly fixed framestep on a slow panning scene.

For example you'll see a signpost or island or whatever reference point move a similar distance each frame, and then in one framestep it will jump a larger (or shorter) distance. That is judder in the video itself. And then you cry... :(

[STaRGaZeR]

And that's a "1/5:th glitch" instead of a "full glitch" which you get at 24 Hz display refresh. The present timing is shifted 8.3 ms each time instead of 41.7 ms (but it is shifted 5 times as often). I'm not really sure which is better. What do you guys think? -A

If the glitches are less noticeable, that's better even if there are more of them.

If it works for you fine. But there is somethig wrong if AUTO is playing @25.714 with 50Hz refresh. Screenshot?

With 120Hz, dunno about 50Hz :)

http://thumbnails3.imagebam.com/5163/9b863551621288.gif (http://www.imagebam.com/image/9b863551621288)

[webs0r]

Looks like a reclock bug? Maybe someone should get James to have a look at it?

25 fps @ 50 Hz auto works fine (stays at 25).

25 fps @ 120 Hz hmm what should happen.. slow down 4% to 24 fps?

[STaRGaZeR]

Looks like a reclock bug? Maybe someone should get James to have a look at it?

25 fps @ 50 Hz auto works fine (stays at 25).

25 fps @ 120 Hz hmm what should happen.. slow down 4% to 24 fps?

Since it can't be synced to anything, it should play at original speed, 25 fps. 24 fps only if PAL SpeedDown is selected.

[Jong]

I have heard of this type of problem before. Try resetting the Reclock timing database (it should be reset whenever drivers are updated). It will probably sort it. If not, post on the Slysoft forum (http://forum.slysoft.com/forumdisplay.php?f=85). It is the kind of thing James will normally look at reasonably quickly and it may be causing other less obvious oddities!

[Jong]

Yes; even if OSD shows great things, video is not smooth. When I watch graph, I can easily see this graph is not smooth.
Whereas the green line looks smooth on 60Hz !
60Hz or 50Hz? If one works smoothly and not the other TVs often only have one true internal refresh rate and converting internally often introducing judder.

[pirlouy]

When the TV is in 50 Hz, graph is not smooth.
When the TV is in 60 Hz, graph is smooth.
When the TV is in 24 Hz, graph looks smooth.

By "smooth graph", I mean the green line moves smoothly from right to left. I don't talk about form of this line, but smooth move...

Thank you Jong for this information. I didn't know this behavior. So, in my case, this 50Hz mode is unusable. I'm a bit disappointed, but I prefer to know instead of believing all works whereas it's not the case.

And 24Hz seems to have problem too (audio lag); not really joyful news, but at least, I won't bother to have sync in these refresh rates. But I'll try to do some tests in 24Hz nevertheless. :)

[Jong]

Out of interest, what is the full model number of the TV? This should clear up the issue.

[pirlouy]

It's a Samsung LE40B530 (I think it is also called LN40B530). It's not a "down-market" product. I think a lot of TV should be affected then.

[Jong]

The LE and LN bit is key. Where did it come from? I admit to not being an expert on that TV, but the US version should be "LN" and have a native 60Hz rate, the LE should be the European Variant and have 50Hz native rate. It looks like you have a US model?! :confused:

[ar-jar]

Well, i think you mean the same thing. Let me explain a little more:
1) The vsync code is executed during the vblanking interval at display refresh frequency
2) From my observations it draws the osd, the stats screen, flips the next buffer, calculates the next vsync flip time and invokes the shaders (
3) I think some of the stuff should not be done in the vblank at all, some stuff should probably be done in a different order.


Hello Casshern and thanks for the input. A few comments:

Not sure what you mean by the "vsync code". What happens is that at vsync offset milliseconds before the vsync, the "Paint" method is called with a new frame. After that the Paint method executes the shaders, add subtitles, draw the OSD (and perhaps a couple of other things that I now forget sitting on a train). Having done that, it calls IDirect3DDevice9::Present to tell the gfx board that there is a new frame rendered. The gfx driver then replaces the contents of the front buffer with the contents of the next back buffer in line during the next vblank. All this should happen in good time before the vsync to avoid tearing caused by too late buffer flips. The time available to execute the above is vsync offset.

Having added the shortcut <ctrl><alt><up- or down-arrow> to modify vsync offset it is now easy to see how tearing is affected by early and late calls of Paint. At least in my set-up the position of the tearing is pretty much proportional to vsync offset and it vanishes entirely at 15 ms vsync offset @ 50 Hz. This obviously varies with boards and drivers.


a) the shaders do not have to be done at screen refresh rate. Obviously they should be done on the frames coming from the decoder. So when your display refresh rate is twice the movie frame rate, at the moment, the shaders are applied twice for every movie frame. Unnecessary because the second frame displayed is identical.


This is unnecessary but then again, some decoders like both the CyberLink and the NVidia MPEG2 decoders deiiver 50/60 fps in DXVA mode. I think the code should be able to handle that at all times.


b) the osd should be applied after all vsync code is finished (buffers are flipped), maybe even outside the vsync code (as a tear in the stats is not important, but of course the tearing bar must be done in the vsync code) and should be optimized to be faster. Its eating 10-20 scanlines at 1920x1080 with a 118Mhz pixel clock.


See above, the OSD must be rendered onto the surface that is to be renderered. But there should be plenty of time to do that with a large enough vsync offset.


c) There is a bug in the vsync code that when the rendered image is completely black and the code is actually finished to fast, theres a problem as the tearing bar begins to judder. This is normally not important as after all one is not watching the tearing bar - but with the gothcode i had some audio dropouts. This might also have to do with the order in which the code does its stuff.


Since the rendering is a simple blt of a texture or a surface, that part of the algorithm should be totally "color blind". I have one blu-ray file that has similar issues. I believe I'm getting bad samples into the renderer from the decoder but I haven't single-stepped through them to analyze them more. Erroneous time stamps could upset the timing of the video renderer and perhaps upset the audio when it is matching rate (when using the Sync Video option). I haven't yet seen or heard this myself. Do you have a file that causes this to happen that I could test?


d) In principal it shouldn't matter if the dxva engine, the shaders etc use up less than 1/23.976023976s (movie frame duration) even on a 47.952 refresh rate display. At the moment this is not the case with the stats- for obvious reason (as the stats are outputted every refresh cycle). This i can understand but without any of that stuff the code should be robust enough to handle these cases. In that respect the beliyaal code still has the edge.


As I hinted above, I don't think it is a robust solution if it can't handle 50/60 fps. To the extent it can't, I think I should address core problems and not try to get something to work for 24/25 that doesn't work for the higher fps:es. In terms of prioritizing my time that is.


e) the resizer is also applied every refresh cycle - unnecessarily. But fortunatly due to my findings in the other thread at least it now only resizes if screen resolution is different from movie res. For some experiencing tearing on slower cards they could try a faster algo (bilinear - ugly but maybe the tearing is gone)


Again, I aim for full 50/60 fps functionality and are not eager to implement special solutions for 24 Hz. I may re-evaluate this later but that's how I feel now.


In summary - the gothcode is getting better, for me the beliyaal code still has some tiny edge. But if ar-jay continues at his pace, i have no doubt the gothcode will soon be better in all respects.


Thanks. My pace will vary but I'll do my best to arrive at a decent and stable renderer. -A

[ar-jar]

60Hz or 50Hz? If one works smoothly and not the other TVs often only have one true internal refresh rate and converting internally often introducing judder.

This seems to be true of my Toshiba TV too. It accepts a 47.952Hz input signal but produces nasty judder when inputing 23.796 fps. I have indications that it internally still uses 50 Hz. This has prevented me from watching any 23.796 material with this TV (this was before I realized Reclock actually works quite well with my renderer).

I do have a small Philips 720p TV that I use for testing and that actualy syncs to pretty much anything you throw at it including 47.952, 48, 50, 60 and does it in a "native" way. It's a TV designed by real TV engineers! -A

[pirlouy]

The LE and LN bit is key. Where did it come from? I admit to not being an expert on that TV, but the US version should be "LN" and have a native 60Hz rate, the LE should be the European Variant and have 50Hz native rate. It looks like you have a US model?! :confused:

I think LN and LE have just some minor differences like 110V for LN and 220V for LE and things like that.

But both models are using 1080p at 60 Hz as native resolution for PC.

[Jong]

Not according to the spec sheets I have seen on European and US web sites; They show different refresh rates. And indeed it would be mad to sell a TV in PAL countries that cannot display 50Hz smoothly!

Edit: Or are you saying you are using a PC-input, not a normal HDMI input. That might make sense!

[pirlouy]

No, I use hdmi port.
But more important, good news !

I've understood what was going on. Thank you for having pushed me. I've done tests and I've found where these judders come from ! It was due to... Aero (I'm using W7 RC1) ! :scared:

Indeed, after having tried Overlay mixer (which disables Aero), 50Hz and reclock, there were no judder. So I've tried EVR custom + 50 Hz + reclock + "Disable desktop composition" and... Yes ! No judder anymore;

Beliyaal and some other people had surely seen before, that's why he has implemented this option. Unfortunately, I didn't know what this option really brought so I did not use it.


I've tested 24Hz + reclock + EVR custom + "disable desktop composition" and I don't have audio lags anymore !


So Aero caused judders and audio lags. :/
It's a shame because I like Aero, and each time I'll launch MPC, it will lose some time to disable Aero... But if it's better...

[Jong]

Great news.

Yes, IMO Aero is a bad idea for really high quality video playback, just another software layer adding latency and inhibiting stand-alone type performance for quality players. Useful for thimgs that don't care for vsync though, like WPF and Flash.

But what you are seeing sounds like a bug/severe oversight - that Aero is re-timing to 60Hz even for a 50Hz display :mad:.

[Casshern]

I think that the problem is not related to 23.976hz (or 47.952) playback at all. In fact the problem (vsync code taking to long) is getting much worse on 50hz or 60hz displays, which is what the majority of people use. Think about it like this: The vsync code takes time x to do its magic, but the window in that it is possible to do that without tearing is getting smaller and smaller with increasing display refresh rate. In a perfect world this should only scale with input refreshrate (actual movie frame rate) and not the display refreshrate. After all the shaders should handle every decoded frame just once and not do identical work on an identical frame again just because the display is using a higher display refreshrate.

I reckon that the problems people have with tearing especially when using not the most up to date gfx boards (which are fast enough). You are right that changing vsync offset can reduce the problem, but unfortunatly (and i do not really know why) it is not a one size fits all - for different material (translating to different decoder&filter combinations) i had to adjust vsync offset to get a satisfactory result. This is clearly undesirable. Also when using hardware deinterlacing, shaders, resizing, dxva decoding even adjusting vsync offset doesnt help anymore, than one can only choose if it tears at the top or bottom.

As somebody already suggested triple buffering might be a way to ease the problem - just make the flip independent of the stats paint and the shaders. The tearing bar naturally has to be painted by the vsync code. But to me it seems like all the other stuff (Subtitles etc.) should be performed on the decoded frames before being passed to the renderer and no by the vsync code.

I can imagine that might be difficult to implement due to the current architecture and the way evr works- so just take this as a sort of philosophical discussion. If something good comes out of it perfect, if not i helps to understand the renderer better - at least for me.

Black frame problem: Take the BD of "Any given sunday" (there were others which i do not remember off hand) and use the mpc hc dxva decoder - during the title sequence there are a couple of fade to blacks which exhibit the problem. First i thought it was only related to the dxva decoder but recently i had the same issue with an episode of the "big bang theory" which was encoded as an xvid and decoded by the internal software decoder. It might be an optimization by the encoders used which just encode a series of black frames as one black frame with a longer duration. But i was very surprised to see it with an xvid....
I wouldn*t prioritize this thing, as it doesnt impair normal viewing - only once it lead to an audio dropout.

Basically the only worrysome thing is that vsync offset has to be adjusted for different decoder filter combinations. This is as much hassle as adjusting reclocks vsync correction, which gothsync is supposed to make obsolete. So every optimization that speeds up the vsync code would make the window larger and more robust to tearing, leading to less or no need to adjust vsync offset. I wonder why beliyaals code handles this more robustly, is essentially doing the same stuff.... your code can't really be substantially slower as there shoudn't be any heavy computations.... maybe its the sequence.... any ideas....





Hello Casshern and thanks for the input. A few comments:

Not sure what you mean by the "vsync code". What happens is that at vsync offset milliseconds before the vsync, the "Paint" method is called with a new frame. After that the Paint method executes the shaders, add subtitles, draw the OSD (and perhaps a couple of other things that I now forget sitting on a train). Having done that, it calls IDirect3DDevice9::Present to tell the gfx board that there is a new frame rendered. The gfx driver then replaces the contents of the front buffer with the contents of the next back buffer in line during the next vblank. All this should happen in good time before the vsync to avoid tearing caused by too late buffer flips. The time available to execute the above is vsync offset.

Having added the shortcut <ctrl><alt><up- or down-arrow> to modify vsync offset it is now easy to see how tearing is affected by early and late calls of Paint. At least in my set-up the position of the tearing is pretty much proportional to vsync offset and it vanishes entirely at 15 ms vsync offset @ 50 Hz. This obviously varies with boards and drivers.



This is unnecessary but then again, some decoders like both the CyberLink and the NVidia MPEG2 decoders deiiver 50/60 fps in DXVA mode. I think the code should be able to handle that at all times.



See above, the OSD must be rendered onto the surface that is to be renderered. But there should be plenty of time to do that with a large enough vsync offset.



Since the rendering is a simple blt of a texture or a surface, that part of the algorithm should be totally "color blind". I have one blu-ray file that has similar issues. I believe I'm getting bad samples into the renderer from the decoder but I haven't single-stepped through them to analyze them more. Erroneous time stamps could upset the timing of the video renderer and perhaps upset the audio when it is matching rate (when using the Sync Video option). I haven't yet seen or heard this myself. Do you have a file that causes this to happen that I could test?



As I hinted above, I don't think it is a robust solution if it can't handle 50/60 fps. To the extent it can't, I think I should address core problems and not try to get something to work for 24/25 that doesn't work for the higher fps:es. In terms of prioritizing my time that is.



Again, I aim for full 50/60 fps functionality and are not eager to implement special solutions for 24 Hz. I may re-evaluate this later but that's how I feel now.



Thanks. My pace will vary but I'll do my best to arrive at a decent and stable renderer. -A

[nijiko]

>ar-jar

Hi.
I found a small problem with your GothSync builds while playing videos.
I used 9018 release from your website.
When I push PLAY button or STOP button, the video will lag for a second.
The performance of the problem is the sound(audio) was instant repeated.
The Tomason's Svplayer used your Goth codes.
But no problems.
He said he used threads for it.
Can you check it?
Thanks for your work.

[Jong]

Basically the only worrysome thing is that vsync offset has to be adjusted for different decoder filter combinations. This is as much hassle as adjusting reclocks vsync correction, which gothsync is supposed to make obsolete. ...I can assure you that in D3D mode (so triple buffered) there is no need to adjust vsync for different combinations, certainly in Reclock. NB: You must not use "D3D fullscreen GUI support" though, that disables the exra buffering.

I know some just do not like D3D; I'm not sure why. People put up with it for games and eliminating judder is even more important for video IMO. Yes, there are some limitations - no right click menu for example, but when watching a movie I never miss that. Disabling D3D is something I do for testing now and again.

Maybe if ar-jar gets a triple buffered non-D3D renderer going that will offer the best of both worlds (PDVD can do it), but for now a huge number of problems go away if you could live with the small restrictions imposed by D3D.

[ar-jar]

Maybe if ar-jar gets a triple buffered non-D3D renderer going that will offer the best of both worlds (PDVD can do it), but for now a huge number of problems go away if you could live with the small restrictions imposed by D3D.

I just did a test with triple buffering in non-exlusive mode. The tearing is the same unfortunately. And one would have to modify the resizing code for windowed mode when using triple buffering (it requires another flip method which doesn't support resizing in the same way. I did the tests with faulty resizing in windowed mode.)

I agree that the only way that reliably seems to eliminate tearing is exclusive mode fs w/o menu support. Or large sync offsets in my case (> 15 ms @ 50 Hz). It would of course be fairly easy to implement a variable default sync offset of say 3/4 of a display cycle. i have to check if it produces the desired results... -A

[Jong]

Might need to get a bit more complex than 3/4s of a cycle.

I think that will work for 50Hz and 60hz (does here), but @120Hz I don't think it would (and 96Hz is tight). You might need to ensure a minimum of say 4ms upper-end margin (unless that would make the offset <4ms from the bottom of course!).

What is also needed IMO is some more granularity, so don't target whole numbers of ms.

[Casshern]

Did not know that about the "d3d fullscreen gui support". But i do remember that without that option it was a real pain to use mpc hc in fullscreen mode. But will try later anyway! Thanks for the tip....

I can assure you that in D3D mode (so triple buffered) there is no need to adjust vsync for different combinations, certainly in Reclock. NB: You must not use "D3D fullscreen GUI support" though, that disables the exra buffering.

I know some just do not like D3D; I'm not sure why. People put up with it for games and eliminating judder is even more important for video IMO. Yes, there are some limitations - no right click menu for example, but when watching a movie I never miss that. Disabling D3D is something I do for testing now and again.

Maybe if ar-jar gets a triple buffered non-D3D renderer going that will offer the best of both worlds (PDVD can do it), but for now a huge number of problems go away if you could live with the small restrictions imposed by D3D.

[ar-jar]

I ran some tests on how much sync offset that is required to get tearing-free rendering with the different resizers available in MPC-HC. The more complex the resizer, the more sync offset is required to avoid tearing. There seems to be a significant difference between the simple resizers and the more complex ones. See the latest post on my blog (http://www.ostrogothia.com/video/) for the results.

[Keiyakusha]

I ran some tests on how much sync offset that is required to get tearing-free rendering with the different resizers available in MPC-HC. The more complex the resizer, the more sync offset is required to avoid tearing. There seems to be a significant difference between the simple resizers and the more complex ones. See the latest post on my blog (http://www.ostrogothia.com/video/) for the results.
These PS resizers works only using shaders? If so, software equivalent probably will be better... Maybe it worth to add them?

Edit: Personally I prefer to use lanczos or spline in ffdshow instead of resizing in MPC... By the way, as i remember from MPC-HC thread, Bicubic resizer was somewhat broken. Don't know if it fixed already, probably no.

[ar-jar]

These PS resizers works only using shaders?.

Yes, the resizers labeled "PS 2.0" use shader code. But then again, there is no significant difference between the non-shader and the shader version of the bilinear resizer.

[webs0r]

Checked your blog update, wow that bicubic PS 2.0 resizer is a time hog... It does depend on the graphics card though. I get vastly different results on an ATI 4550 vs. an Nv 8800GT.

This was why I was so keen to get the MPC trunk merged that had the "don't resize if source res = output res" enhancement. Has it been now? I think it has. At least this applies when you are watching at 100% res.

I also use spline resizing in ffdshow, and suggest this resize (or a diff CPU resize) for people that have the CPU% to spare. It takes the variability out of your sync offset as Casshern was describing (and to me, gives a sharper upsampling of the image vs bicubic without too many artifacts). Resizing a 720->1080 on the gpu is going to take longer than 288->1080. (Unless you can triple buffer the resize & other shader work, which you would expect would allow you to keep a constant offset, regardless of different source content by having the final frame always ready to just flip to). In fact a strategy now could be to move everything as much as possible to the CPU. Incidentally, I have ffdshow doing the RGB32 conversion as well.

You would think a good implementation of a complex resizer on GPU would also be faster than CPU... but I don't know... Someone would have to write it, or perhaps re-use work from some of those GPU avisynth plugins. But I really think a buffering system for the final frame needs to be in place to negate the time variation of selecting different shader combinations.

Also can the OSD drawing be made any faster?
This explains the difference in behaviour I got with 1x ctrl-J vs 2x ctrl-j with 60 fps content.
It needs to be as minimal impact as possible so that it doesn't skew the results of what you are seeing. If it is causing glitches because it takes too long to draw when you watch video without the OSD everything is fine, then the OSD isn't representing what is happening well :)
Maybe an idea is to review every bit of info on that screen and just isolate the most key ones and use that as the 1x ctrl-J option.
Could have a more verbose option later in the ctrl-J selection.
Unfortunately I'm guessing making the graph (which is so useful) takes time as well...

Or you could put the stats elsewhere (e.g. a window) running on a diff thread?

[ar-jar]

This was why I was so keen to get the MPC trunk merged that had the "don't resize if source res = output res" enhancement. Has it been now? I think it has. At least this applies when you are watching at 100% res.


When the resolutions are identical, then a nearest neighbor resizer is always used. This is the simplest resizing "filter" (see http://msdn.microsoft.com/en-us/library/ee416649(VS.85).aspx) and as fast as it gets I guess while still working with textures (and since gaming drives the gfx board architectures, I would guess that texturing is a very efficient operation). Identical code is run if you manually choose this filter type in the Options.


You would think a good implementation of a complex resizer on GPU would also be faster than CPU... but I don't know... Someone would have to write it, or perhaps re-use work from some of those GPU avisynth plugins. But I really think a buffering system for the final frame needs to be in place to negate the time variation of selecting different shader combinations.


I briefly tried triple buffering but it didn't make much difference. See an earlier post on this thread. What makes a huge difference is exclusive mode full-screen ("D3D") w/o GUI support.

As you can see from the MSDN page there are nowadays more complex "ready-made" resizing filters available that hopefully have been optimized as they are part of DirectX. They may not work on older boards but might be nice for those of us with somewhat newer boards. I'll see if I can throw some of those in later.


Also can the OSD drawing be made any faster?


I ran some more tests. The full OSD requires an additional 2 ms or so of sync offset (drawing time) on my low-end ATI board. Not an eternity but could make or break a tight schedule. The tearing test bars are drawn with CPU code. Conceivably you could also draw the OSD with the CPU but that's not my priority right now. There would also be some ugliness as the samples haven't been resized while accessible for the CPU.

[Casshern]

Yeah, the more complex shaders take more time. This also explains one reason for having to adjust sync offset for different material/decoder/filiter chains - if the movie has to be resized (in my case, when its not 1920x1080) a shader other than bilinear is used. The time it takes for that scaler is probably roughly proportional to the source resolution-> ergo you have to adjust vsync offsets for different files.

If there is anyway to decouple resizing from screen refresh (which adds additional computational burden if screen refresh > movie frame rate), it would probably eliminate the tearing (or fiddling with vsync) on most systems.

Also a triple buffer might help here to (still have to try d3d mode without gui support - just cant bring myself to endure that again). I wonder if a algo with good recovery from overlong vsync might be another solution if it has a way to know about repeated frames. Imagine this:
1) resizer+all other vsync code takes to long when screen refresh > movie frame rate
2) now the code checks at which scanline the display is, if its to late (scanline outside vsync area), we do NOT flip the buffers on the condition that the frame is a repeat of last movie frame
3)we abort the current operation and begin immediately on the the next frame vsync code (even though we are not in the vsync area).
4) This makes the complete scanline time = total scanlines - abort scanline + vsync area available to the vsync code for the next real movie frame. Which should be plenty enough -> so that it should sync again to tearing free playback.
5) now just flip when reaching the normal flip position

Of course best would be not to work on the duplicate frames at all....
I ran some tests on how much sync offset that is required to get tearing-free rendering with the different resizers available in MPC-HC. The more complex the resizer, the more sync offset is required to avoid tearing. There seems to be a significant difference between the simple resizers and the more complex ones. See the latest post on my blog (http://www.ostrogothia.com/video/) for the results.

[Casshern]

One other thing to improve the renderer.

One of the main problems of evr is that one has to use the YV12 chroma upsampling shader for proper chroma interpolation. I can't really imagine that microsoft still hasn't adressed this problem somehow in EVR. Especially since they did a complete makeover for their new media foundation in Win7. Maybe there is a new (or even old) switch to get proper chroma upsampling, without having to use the shader.

regards,

Casshern

When the resolutions are identical, then a nearest neighbor resizer is always used. This is the simplest resizing "filter" (see http://msdn.microsoft.com/en-us/library/ee416649(VS.85).aspx) and as fast as it gets I guess while still working with textures (and since gaming drives the gfx board architectures, I would guess that texturing is a very efficient operation). Identical code is run if you manually choose this filter type in the Options.



I briefly tried triple buffering but it didn't make much difference. See an earlier post on this thread. What makes a huge difference is exclusive mode full-screen ("D3D") w/o GUI support.

As you can see from the MSDN page there are nowadays more complex "ready-made" resizing filters available that hopefully have been optimized as they are part of DirectX. They may not work on older boards but might be nice for those of us with somewhat newer boards. I'll see if I can throw some of those in later.



I ran some more tests. The full OSD requires an additional 2 ms or so of sync offset (drawing time) on my low-end ATI board. Not an eternity but could make or break a tight schedule. The tearing test bars are drawn with CPU code. Conceivably you could also draw the OSD with the CPU but that's not my priority right now. There would also be some ugliness as the samples haven't been resized while accessible for the CPU.

[starla_]

One other thing to improve the renderer.

One of the main problems of evr is that one has to use the YV12 chroma upsampling shader for proper chroma interpolation.

http://msdn.microsoft.com/en-us/library/ms698989(VS.85).aspx Might be helpful.

[Leak]

http://msdn.microsoft.com/en-us/library/ms698989(VS.85).aspx Might be helpful.
Helpful in determining how the chroma is oriented vs. the luma - yes. (If the values are to be trusted, see interlaced vs. progressive in MPEG2 streams...)

Helpful in getting the renderer to not do point upscaling of the chroma - not so much, I'm afraid...

[madshi]

I briefly tried triple buffering but it didn't make much difference. See an earlier post on this thread. What makes a huge difference is exclusive mode full-screen ("D3D") w/o GUI support.
From my experience it seems that triple buffering is next to useless in windowed mode (regardless of whether it's "full screen" or not) because the "Present" call actually blocks until the next VSync occurs. Which means that as soon as you call "Present", you can't do any more rendering. Which means that the additional two background render buffers have no chance to even fill up.

In fullscreen *exclusive* mode I think "Present" does not block (haven't tried yet, though). Which should give you a HUGE performance advantage. Of course the whole presentation logic (which frame is shown when) must be able to cope with the non-blocking "Present" call for this all to make sense. Fullscreen exclusive mode with triple buffering should be the best option for performance.

[ar-jar]

From my experience it seems that triple buffering is next to useless in windowed mode (regardless of whether it's "full screen" or not) because the "Present" call actually blocks until the next VSync occurs. Which means that as soon as you call "Present", you can't do any more rendering. Which means that the additional two background render buffers have no chance to even fill up.

In fullscreen *exclusive* mode I think "Present" does not block (haven't tried yet, though). Which should give you a HUGE performance advantage. Of course the whole presentation logic (which frame is shown when) must be able to cope with the non-blocking "Present" call for this all to make sense. Fullscreen exclusive mode with triple buffering should be the best option for performance.

Thanks! This rhymes with my experience also. I remember back when I started working with this that I was a bit surprised that Present didn't always block. Most of the time it looks like it blocks but that's when you are up to speed and feed the swap-chain with a new frame every screen refresh cycle which I do most of the time (I know this is not always optimal but I wanted to be able to handle 50/60 fps anyway since some decoders actually deliver this number of unique frames, e.g. the CyberLink AVCHD decoder). Conclusion: use either exclusive mode full-screen or a large sync offset value. -A

[THX-UltraII]

I had to do a fresh installation of my HTPC last night. So of course time for new bugs after this :D

The problem:
When I use ffdshow as video decoder I get the result you see in picture 1 (I m not @home so I made a home-made picture with paint :)). The thing I notice is that when I press CTRL+J I see that the Actual Frame Rate information shows strange behaviour: Is goes up to approx. 24,002 and back to approx. 23,961 and this goes in cycles. (off course this is why the green line is not constantly horizontal).

When I don t use ffdshow (internal MPC-HC filters) I get a perfect constant info @Actual Frame Rate of 23,976 and picture 2 @CRTL+J.

''Why not use the internal filter than'' I hear you think. Cause I need ffdshow for RGB HQ output.

What could this be?

My settings: latest .9018 GothSync MPC-HC, EVR Custom output, ATI HD4350 with 9.10 beta driver, Sync Video to Display option, all other Vsync option in MPC-HC OFF.

Picture 1:
http://img395.imageshack.us/img395/4433/ffdshow.th.jpg (http://img395.imageshack.us/i/ffdshow.jpg/)

Picture 2:
http://img63.imageshack.us/img63/1964/withoutffdshow.th.jpg (http://img63.imageshack.us/i/withoutffdshow.jpg/)

[madshi]

I remember back when I started working with this that I was a bit surprised that Present didn't always block.
That was with fullscreen exclusive mode, I guess?

[ar-jar]

That was with fullscreen exclusive mode, I guess?

Yes, I believe it was as I focused entirely on getting this to work in exclusive mode. When I started a few years ago, there were severe tearing issues with non-exclusive mode (there still are but they are more controllable now it seems).

I'm among those who use the HTPC with a remote control in a real home cinema setting and I couldn't care less about menus and windowed mode :-)

-A

[Jong]

I'm among those who use the HTPC with a remote control in a real home cinema setting and I couldn't care less about menus and windowed mode :-)Me too!

[THX-UltraII]

any thought on the issue I have Ar-Jar or Jong?

[Jong]

My main thought is that if you are not upscaling in ffdshow you do not need to use ffdshow to convert to RGB. I understand in another thread leeperry is suggesting you use it as a reference to compare with other options, but that should just be for testing. There should be no reason why you cannot use MPC-HC with EVR/VMR9 Gothsync and get the correct colours. If they are wrong, somehow MPC or your filters are misconfigured or there is something wrong with the file you were using for testing (hence the suggestion you use AVS-HD test patterns).

On what you are observing, first are you actually using ffdshow to DECODE or are you using it just as a post-processor? ar-jar may need to comment on why the frame-rate is constantly varying, but the main thing is provided your number of glitches/dropped frames is not going up this makes no difference at all to your viewing pleasure. What you are seeing is a slight variation in when the frames are presented, but the frames are displayed on a precise "beat" controlled by the GPU and slight variations like this that do not cause glitches make no difference at all to your viewing pleasure!

[Jong]

My main thought is that if you are not upscaling in ffdshow you do not need to use ffdshow to convert to RGB. Actually there is one exception to this that leeperry has mentioned. That is 2.35:1 or 2.4:1 video encoded @720p without the black bars. Then the vertical resolution that most renderers use to decide the colorspace is <720p and they make the wrong choice. However, since your video is 1080p this would not apply even if encoded withoutthe black bars (all professional BR discs are encoded WITH the black bars, so at the full 1920x1080 resolution). Personally I live with the errors in these rare situations (normally trailers).

[THX-UltraII]

thxz for all info (again!) Jong. The link to the testfile Leeperry wrote, how does this work? Do I just need to see all equal sqaures and is it then ok? If so, I m going to do some tests tonight and report back to you asap

[Jong]

I don't know I haven't looked at it. Ask leeperry or follow the suggested diagnostic method I proposed using AVS-HD.

[THX-UltraII]

I don't know I haven't looked at it. Ask leeperry or follow the suggested diagnostic method I proposed using AVS-HD.

ok, so just grab the mp4 version from http://www.avsforum.com/avs-vb/showthread.php?t=948496.

Is there a manual with it so I know how it works?

[Jong]

Didn't you grab the .pdf file, that is right next to the download link in the first post?

[ar-jar]

The problem:
When I use ffdshow as video decoder I get the result you see in picture 1 (I m not @home so I made a home-made picture with paint :)). The thing I notice is that when I press CTRL+J I see that the Actual Frame Rate information shows strange behaviour: Is goes up to approx. 24,002 and back to approx. 23,961 and this goes in cycles. (off course this is why the green line is not constantly horizontal).

When I don t use ffdshow (internal MPC-HC filters) I get a perfect constant info @Actual Frame Rate of 23,976 and picture 2 @CRTL+J.

''Why not use the internal filter than'' I hear you think. Cause I need ffdshow for RGB HQ output.

What could this be?



The strange thing is why you get straight lines in the second case (the first one is kind of normal although you could experiment with the control limit a bit too to narrow down the oscillations). You say the image is done with paint? So are the lines exactly straight in the second case? If they are, I don't have any explanation currently. I've never seen lines w/o the tiniest wiggle. Have to think about what it is that could have happened. Are you sure you are doing sync video in both cases?

And btw, are you also trying to illustrate that the scaling is wrong so that the actual video only covers the upper left corner of the screen?

-A

[tdoll]

I am sorry for my simple question but I am using mpc-hc for a while now and I have not jet been able to use gothsync tryouts. I always take the latest version of mpc-hc and I thought gothsync is embedded in the player. Am I wrong here. Is there any thread where I could read about how to use the gothsync tryouts with mpc-hc. I just neet some hints to get started. I am very interested in this project. I used to use reclock but I like the idea to have everything integrated in the player.

Thanks for your help!

Thomas

[Jong]

Just follow the link in the first post of this thread for the special Gothsync versions of MPC-HC. It is not in the standard builds yet.

[Casshern]

Hi ar-jay,

just read on your site that you will move your code to your own renderer! Good call! This will make everybody happy. People can still use beliyaals code or yours, whatever works best for them. Awesome!

[pirlouy]

Is this "new" renderer going to be based on EVR ?

[ar-jar]

Is this "new" renderer going to be based on EVR ?

Yes, that would be my first bet as EVR gives better access to controlling the timing etc. -A

[honai]

I hope you are aware that with EVR you get all sorts of transparent driver tweaks that nVidia, ATI and Intel apply behind the scenes, e.g. VSYNC fiddling, color correction (applying both Windows color-management and certain enhancements, e.g. for skin tones), implicit color-space conversions, color clipping, etc.

With EVR there's no way around that. That's why madshi decided to base his renderer *not* on EVR.

[tetsuo55]

The renderer isnt new from scratch like madvr, but rather the newest evolution of custom-EVR.

[honai]

Still, the relevant parts of this project - reducing tear/judder and faithful rescaling - are out of the control of the dev/user as long as you use EVR. Even with a custom EVR renderer you get transparent driver tweaks, hence the bunch of options that Beliyaal had to include in his version. And still, behavior of his custom EVR varies vastly from platform to platform, GPU to GPU - simply because, no matter how nicely you talk to the EVR API, the driver determines the actual behavior, i.e. the part of the EVR renderer code that is invisible to you.

[tetsuo55]

Still, the relevant parts of this project - reducing tear/judder and faithful rescaling - are out of the control of the dev/user as long as you use EVR. Even with a custom EVR renderer you get transparent driver tweaks, hence the bunch of options that Beliyaal had to include in his version. And still, behavior of his custom EVR varies vastly from platform to platform, GPU to GPU - simply because, no matter how nicely you talk to the EVR API, the driver determines the actual behavior, i.e. the part of the EVR renderer code that is invisible to you.as far as i know ar-jar worked around almost all of those (but he will have to reply himself for further details)

[pirlouy]

Maybe honai is right, but I think it's very hard to write your own renderer all by yourself. Since Madshi has some plans, I guess it's not a bad idea to improve a renderer which is now a reference (EVR) with its pros and cons.

Anyway, one thing which works well for sync in my case in Beliyaal build, it's the ability to stop Aero (even if stopping Aero causes tearing)... I hope Ar-jar's renderer will keep this option.

[PaJaSoft]

Anyway, one thing which works well for sync in my case in Beliyaal build, it's the ability to stop Aero (even if stopping Aero causes tearing)... I hope Ar-jar's renderer will keep this option.

I thought the same thing, but practical test - ar-jar graph during play - says something else... I didn't disable Aero in whole Windows 7, only disable Desktop composition for this binary .exe, but the result is much more jitter/judder and synchonization adjustment every second or less - red line spike... (HDMI out is 50Hz, source off-line played signal is recording from SAT 1080i 25fps DVB) - I'm using sync to nearest as the best method - without PowerStrip.

Leave Aero ON is much better for me (NVidia 250GTX, 191.07WHQL, Windows 7 Prof. 64-bit Prof) in this program... - althought in DVBViewer is the situation on EVR surface exactly inverse... strange:-( (using latest build of GothSync)

[Jong]

Yes, that would be my first bet as EVR gives better access to controlling the timing etc. -APlease try to keep a VMR9 renderer too, for XP users. I have totally got used to using Gothsync now. I would hate to have to "regress" :)

[pirlouy]

I thought the same thing, but practical test - ar-jar graph during play - says something else...
In my case, Ar-jar graph suffers from judder when Aero is enabled. graph is correct thought, but it has judders.
In fact, I think it's due to dual screen. One screen in 60Hz, other in 50Hz.
But when Aero is enabled, and when I use 24Hz, UI is very slow (which is not the case when Aero disabled).

Aero is pretty, fights again tearing, but unfortunately it does not manage to do it the right way. It does not worth GothSync + D3D. Madshi renderer is not really usable for now.

[tetsuo55]

Please try to keep a VMR9 renderer too, for XP users. I have totally got used to using Gothsync now. I would hate to have to "regress" :)You only need VMR9 for DXVA, otherwise ar-jar's EVR is better even for XP.

Eventually changes will be backported to VMR9

[mark0077]

Looking forward to seeing it integrated into mpc-hc. When I play 24hz content on my 60hz display, I am used the usual spiky graph, but I notice a difference between beliyaals graph and gothsync's graph.

With the normal mpc-hc graph, the audio sync line spikes up and down, I assume to show the audio is out of sync with the video?
With gothsync, my audio sync line stays almost perfectly straight, but the video line in the graph spikes as usual.

Are they representing different things?

[tetsuo55]

Looking forward to seeing it integrated into mpc-hc. When I play 24hz content on my 60hz display, I am used the usual spiky graph, but I notice a difference between beliyaals graph and gothsync's graph.

With the normal mpc-hc graph, the audio sync line spikes up and down, I assume to show the audio is out of sync with the video?
With gothsync, my audio sync line stays almost perfectly straight, but the video line in the graph spikes as usual.

Are they representing different things?the lines cannot be compared

[mark0077]

OK cheers.

[THX-UltraII]

Here a stupid question:

What happens when Gothsync gets integrated in MPC-HC as renderer? With the current version posted by Ar-Jar you already have the 'syncronisation' option in the options menu of MPC-HC. What will become different then?

[tetsuo55]

Here a stupid question:

What happens when Gothsync gets integrated in MPC-HC as renderer? With the current version posted by Ar-Jar you already have the 'syncronisation' option in the options menu of MPC-HC. What will become different then?the difference is, that Ar-Jar can work freely on the renderer, without having to worry about syncing with trunk.

[webs0r]

Hey ar-jar how is it going? It has been quiet for a bit. Anything new to test? :)

[pirlouy]

As he said on his blog (http://www.ostrogothia.com/video/), he is occupied to rewrite his current renderer in order to be "MPC independent" in fact.

[ar-jar]

As he said on his blog (http://www.ostrogothia.com/video/), he is occupied to rewrite his current renderer in order to be "MPC independent" in fact.

Well, I don't think I wrote "MPC-independent". I didn't mean it in any case. I have been rather ambivalent as to whether I should again integrate my features with the Beliyaal track and I talked with him about that. Eventually I will probably do that but he is doing some work on the renderer for the moment so it's a bit of a moving target. I will therefore, time permitting, work on a parallel track for yet some time. Unfortunately I've been extremely busy at work lately so progress has been slow. That *must* change eventually :-) -A

[pirlouy]

Ok, but I think you should try to make the renderer independent of MPC-HC. You can support some MPC API like subtitle renderer, but I think it could be better if it was not dependent on MPC.

[ar-jar]

Ok, but I think you should try to make the renderer independent of MPC-HC. You can support some MPC API like subtitle renderer, but I think it could be better if it was not dependent on MPC.

My first renderer (non-MPC) was in fact almost independent of the player. At that time there was one challenge that I couldn't find a good solution for: to switch between exclusive mode full-screen and windowed mode only using the standard renderer interfaces. Also at that time all players used the IVideoWindow interface which was a real pain to implement. So I ended up specifying a proprietary interface that only my own player used. I think that many of these things have changed with EVR so I might give it another try. Thanks for the encouragement! -A

[SundaY82]

My first renderer (non-MPC) was in fact almost independent of the player. At that time there was one challenge that I couldn't find a good solution for: to switch between exclusive mode full-screen and windowed mode only using the standard renderer interfaces. Also at that time all players used the IVideoWindow interface which was a real pain to implement. So I ended up specifying a proprietary interface that only my own player used. I think that many of these things have changed with EVR so I might give it another try. Thanks for the encouragement! -A
I would also love a version free from mpc so I can use gothsync with zoom player :)

[aymeric106]

I spent years trying to find the perfect player ... and now, i've got it, thanks to your work
It was almost perfect until i saw your post about resizing and shaders http://www.ostrogothia.com/?p=1444, and now it is perfect.

bye bye reclock, powerstrip, mad renderer, haali ... I can stop buying nvidia card, then ati, then nividia ...
The only thing i'm missing is the script that was launched by reclock to set the proper frequency on my second monitor (24,50 or 60 Hz depending on the video source rate), but i'm not sure it's the media player role to change display frequency.

Anyway, thanks, and keep it up !!

aymeric

[THX-UltraII]

any news on MPC-HC intergration?

[pirlouy]

I think you missed another point ! :P http://www.ostrogothia.com/?p=1460

But maybe we can ask the development state of this kinda new renderer... Does it progress or are there more and more difficulties ? :-)

[THX-UltraII]

I think you missed another point ! :P http://www.ostrogothia.com/?p=1460

But maybe we can ask the development state of this kinda new renderer... Does it progress or are there more and more difficulties ? :-)

I did see this. But was just wondering what the status is.

[ar-jar]

any news on MPC-HC intergration?

Sorry, progress is really slow now due to too much work (for a living). That *will* change, I just don't know exactly when. I'm happy to receive any feedback on the existing version in the mean time. -A

[SundaY82]

Anyone have a dl link to latest version of gothsync?
Reinstalled my computer with windows 7 but now when I was to redownload gothsync the links are dead.

Progress update by the way?

[THX-UltraII]

Let s hope it s not dead!

[ar-jar]

Let s hope it s not dead!

Thanks for letting me know. My ISP has been messing with my ftp site. I can't access it myself anymore. The support folks are probably home for Christmas so give it a few days. Hopefully I will get a couple of days off myself during the holidays to try to remember what my project was all about :-) -A

[ar-jar]

The download links should work again! -A

[SundaY82]

Thanks for letting me know. My ISP has been messing with my ftp site. I can't access it myself anymore. The support folks are probably home for Christmas so give it a few days. Hopefully I will get a couple of days off myself during the holidays to try to remember what my project was all about :-) -A
Sounds great, would really hate if this work you have done goes dead.

Did you plan on making some sort of version free from mpc that could be used in other players like zoom player?

[leeperry]

I spent years trying to find the perfect player ... and now, i've got it, thanks to your work [..]
bye bye reclock, powerstrip, mad renderer, haali
hey man! care to share more details please?

can it do bit-perfect KS/WASAPI audio, gamut conversion(through PS script in MPC possibly?), 25/23.976fps@24/48Hz, as smoothly as madVR+Reclock and w/o any dropped frame WHATSOEVER? I haven't tried ar-jar's code in a while, and I'm well aware that he's got a lot of tricks up his sleeve...so more details would be most welcome ;)

last time I tried his VMR9 based player, it was more aimed at ATi users..

[SundaY82]

The download links should work again! -A
Still cant get the download links to work on your download page, http://www.ostrogothia.com/?page_id=1213

[ar-jar]

Still cant get the download links to work on your download page, http://www.ostrogothia.com/?page_id=1213

I think my ISP is using the Christmas holiday for sysadmin. I have added another link to the 9018 patch version. It's probably slower but it should work if the rest of the site works since it's on the same server.

[ar-jar]

I have merged the GothSync code with the regular MPC-HC build. It can be downloaded as usual from my blog. It's also committed to the SVN trunk.

The Sync Renderer is now the last option in the ever longer list of renderers. When it's selected, further sync options can be set through the Options -> Playback -> Synchronization dialog. More documentation can be found on the blog (may be slightly out of date).

Hopefully I didn't break too many things along the way :-)

[Keiyakusha]

Just a few things:
Where the "fullscreen monitor" menu located now?
There is a lot of renderers now. Maybe it will be better to make dropdown menu for them just like for audio renderers?
Since original project was named GothSync, IMHO its fine to live that name for the renderer, unless you don't like it anymore...

[scharfis_brain]

just a question, even if it is not possible, though.

Would it be possible within the renderer to insert blended frames during playback in realtime to maintain motion fluidity with unsyncable framerates?

example: 24fps on 60Hz display
standard pattern: A A A b b C C C d d (the usual 3:2 pattern arises)
frameblending: A A Ab b b C C Cd d d (every frame is being shown exactly 2.5 times on the screen due to the blending)

I found the blending being barely noticable. It produces very smooth motion.
I am using it all time now with AVISynth in ffdshow during playback.
But it is clumsy to set up and I need to touch the settings everytime I switch the screens.

This also works for arbitrary framerate conversions as long as the framerate of the video is less than half of the screens refresh rate.

[ar-jar]

Just a few things:
Where the "fullscreen monitor" menu located now?
There is a lot of renderers now. Maybe it will be better to make dropdown menu for them just like for audio renderers?
Since original project was named GothSync, IMHO its fine to live that name for the renderer, unless you don't like it anymore...

Not quite sure what you mean by "fullscreen monitor menu" but there are some options in the pop-up menu under Renderer Settings -> Presentation. I'll think about the "Goth" part. Thanks :-)

[ar-jar]

just a question, even if it is not possible, though.

Would it be possible within the renderer to insert blended frames during playback in realtime to maintain motion fluidity with unsyncable framerates?


This is a very interesting feature and afaik there is OSS code available (?). My first prio is to stabilize the renderer. Then I'll start looking at the feature requests. Have you added it to http://sourceforge.net/apps/trac/mpc-hc/report/9?

[scharfis_brain]

uh_oh, do I really need to create a user account on sourceforge to enter a feature request?

[fastplayer]

^Yes.

[carnage_pl]

When language is preset to another than english when you try to go into settings error appears: Encountered improper argument

[ar-jar]

When language is preset to another than english when you try to go into settings error appears: Encountered improper argument

Sorry, I have never compiled anything but an English version. Do you use a decimal point (English style) or a decimal comma (as in Scandinavia) in your culture?

[XhmikosR]

@ar-jar: you need to update all the resources like you did for mplayerc.rc otherwise what carnage_pl said happens with other than English languages.

[carnage_pl]

Decimal comma. I had to check that because I never thought about it :D

[Leak]

Where the "fullscreen monitor" menu located now?

If you mean the drop-down to select the fullscreen monitor - that's on the playback page now together with the setting for fullscreen resolution...

np: Bibio - Dwrcan (Eskmo Remix) (The Apple And The Tooth)

[ar-jar]

@ar-jar: you need to update all the resources like you did for mplayerc.rc otherwise what carnage_pl said happens with other than English languages.

Yeah, thanks, I realize that now... Is there a tool for merging my changes? I guess I would need to add the changes in English and then let somebody native take over?

[ar-jar]

@ar-jar: you need to update all the resources like you did for mplayerc.rc otherwise what carnage_pl said happens with other than English languages.

Ok, I'm at it, sorry for this omission. It'll take some time though I'm afraid. Thanks for clearing out how the linguistic part of mpc-hc works. -A

[ar-jar]

Decimal comma. I had to check that because I never thought about it :D

What's your language btw? I'll see to it that I fix that resource file first. -A

[carnage_pl]

What's your language btw? I'll see to it that I fix that resource file first. -A
Polish

[ar-jar]

Polish

I committed a new Polish resource file (+ Swedish and German). I did the Swedish translation but leave the Polish to you. -A

[STaRGaZeR]

Hey Arto, welcome back :)
Have you considered adding the status of the EVR buffers to the stats just ike EVR Custom? They are very useful.

[ar-jar]

Hey Arto, welcome back :)
Have you considered adding the status of the EVR buffers to the stats just ike EVR Custom? They are very useful.

I could do that. What do learn from those stats? -A

[STaRGaZeR]

In perfomance limited scenarios you can see how many frames need to be buffered to maintain realtime playback, you can see if you're limited by the decoder speed if the buffers are not always full, for example, when using Avisynth scripts in ffdshow with filters that are single threaded, and you can also see if and how particular settings help in those cases. I consider it a pretty useful feature.

[mark0077]

Remove. Wrong thread

[ADude]

I think what you are saying is that MPC-HC builds from 1465 will have "Sync Renderer" included ?

If so, no one has mentioned that in the regular MPC-HC thread.

I did not do so, since I think ar-jar should be allowed to do so himself, and say what he wants to say about it.

[ar-jar]

Hey Arto, welcome back :)
Have you considered adding the status of the EVR buffers to the stats just ike EVR Custom? They are very useful.

I added the stats. There is a new version under the "Private builds" heading on my download page (http://www.ostrogothia.com/?page_id=1213). Hope they were the right stats. -A

[Remicade]

Noob question: right click, renderer settings, display stats: what is the ideal case the red line and the green line appear ? Paralel, zigzag ?

[ar-jar]

Noob question: right click, renderer settings, display stats: what is the ideal case the red line and the green line appear ? Paralel, zigzag ?

Parallel. Check out the documentation here (http://www.ostrogothia.com/?page_id=1218). There is some getting-started documentation here (http://www.ostrogothia.com/?page_id=1216). -A

[Jong]

ar-jar, any chance of you being able to support DVD Menus with the Cyberlink MPEG-2 decoder, or is this out of your control? I loved using this decoder on XP, but currently must use the MPC decoder on W7 for full menu support with EVR and your renderer.

[STaRGaZeR]

I added the stats. There is a new version under the "Private builds" heading on my download page (http://www.ostrogothia.com/?page_id=1213). Hope they were the right stats. -A

Yup, they are. Thanks!

[hdboy]

Just a few things:
Where the "fullscreen monitor" menu located now?


options > playback

questions:

1) if gothsync is vmr9 based, why does the guide says EVR needs to be installed?

2) my TV accepts 24hz or 60hz. Is it possible to set MPC to automatically switch the refresh rate to 24hz for 23.976fps material, and 60hz for everything else?

[ar-jar]

options > playback

questions:

1) if gothsync is vmr9 based, why does the guide says EVR needs to be installed?

2) my TV accepts 24hz or 60hz. Is it possible to set MPC to automatically switch the refresh rate to 24hz for 23.976fps material, and 60hz for everything else?

1) It's EVR-based. It used to be VMR-based in the old player.

2) It would but it would require a bit of programming. Pls add it to the feature requests. Thanks.

-A

[ar-jar]

ar-jar, any chance of you being able to support DVD Menus with the Cyberlink MPEG-2 decoder, or is this out of your control? I loved using this decoder on XP, but currently must use the MPC decoder on W7 for full menu support with EVR and your renderer.

Need to check it out. I just very recently got myself a W7 HTPC and haven't had any time to check what works and what doesn't. I don't know of any way to get EVR and DVD menus to work on XP. I too use the Cyberlink from time to time. -A

[ADude]

The Cyberlink MPEG2 with hardware acceleration + MPC-HC + DVD menus problem was reported to the bug tracker months ago, and is reported in threads every few weeks.
The workaround I use is to use the AutoPlay detection to start an older version of MPC-HC only for DVDs (the bug actually was introduced at some point in the last year or two).

[Jong]

Need to check it out. I just very recently got myself a W7 HTPC and haven't had any time to check what works and what doesn't. I don't know of any way to get EVR and DVD menus to work on XP. I too use the Cyberlink from time to time. -AYeah, they work with Cyberlink & VMR9, but not EVR on XP, Vista or W7. It would be great if Cyberlink could be supported on W7. The current MPC decoder is not as smart at deinterlacing, does not support DXVA and has some decoding glitches.

[Jong]

The Cyberlink MPEG2 with hardware acceleration + MPC-HC + DVD menus problem was reported to the bug tracker months ago, and is reported in threads every few weeks.
The workaround I use is to use the AutoPlay detection to start an older version of MPC-HC only for DVDs (the bug actually was introduced at some point in the last year or two).I'm not that happy with this as DVDs are still a big reason to use MPC-HC and I want some of the smoothness and resizing improvements that have been made recently. But please could you tell me which is the latest version that works?

[Ger]

The results seem to change a lot if the (CTRL-I) remaining time OSD is turned on. The only difference between these two screenshots apart from a slightly different position in the same video file is the OSD state.

Using build 1473. The file is a run of the mill xvid/avi on Win7-x64 with Nvidia 8800GT.

http://img690.imageshack.us/img690/2838/screenshot2010010323000.th.png (http://img690.imageshack.us/i/screenshot2010010323000.png/)

http://img24.imageshack.us/img24/2952/screenshot2010010323020.th.png (http://img24.imageshack.us/i/screenshot2010010323020.png/)

CPU usage is only slightly higher with CTRL-I OSD on, barely noticeable.

[ar-jar]

The results seem to change a lot if the (CTRL-I) remaining time OSD is turned on. The only difference between these two screenshots apart from a slightly different position in the same video file is the OSD state.

CPU usage is only slightly higher with CTRL-I OSD on, barely noticeable.

Thanks, that's an interesting observation. I don't seem to be able to reproduce it right now either on my 32 bit XP or on my 64 bit w7. Something funny happened with the w7 version though (but not exactly this). Could you pls try the 64 bit build that i just recently uploaded to my site? -A

[ADude]

I'm not that happy with this as DVDs are still a big reason to use MPC-HC and I want some of the smoothness and resizing improvements that have been made recently. But please could you tell me which is the latest version that works?

1.0.11.0

which is at:

http://sourceforge.net/projects/mpc-hc/files/MPC%20HomeCinema%20-%20Win32/MPC-HC%20v1.0.11.0%20_%2032%20bits/mplayerc_homecinema_x86_v1.0.11.0.zip/download

If you want to use the current version with DVD, then you need to turn off hardware acceleration on MPEG2 when you want to play DVDs.

[Ger]

Could you pls try the 64 bit build that i just recently uploaded to my site? -A

The 32 and 64 bit builds behave the same as far as I can tell.

These screenshots have different framerate/decoder/container/res (film/H.264/mkv/720p) compared to the last ones, and are taken with 64-bit build 1480. Other specs are the same as last time: 8800GT/Win7-x64.

http://img228.imageshack.us/img228/7921/screenshot2010010401110.th.png (http://img228.imageshack.us/i/screenshot2010010401110.png/)

http://img46.imageshack.us/img46/7826/screenshot2010010401120.th.png (http://img46.imageshack.us/i/screenshot2010010401120.png/)

The way I understand your guides the first one is normal here as well, with a more difficult/"unsyncable" framerate for my monitor casuing the increased zig-zag. When I enable OSD (second image) the spikes are there again.

Press CTRL-I again to disable OSD, and the lines are back to normal (like the first screenshot in this post) immediately.

I should say that my CPU is not the best, a 3+ year old Core 2 Duo E6300, but the CPU usage monitor on my Logitech G15 stays in the 15-25% range with or without OSD. Perhaps a few percent higher average with OSD enabled.

For the record, this is not a big issue for me. The only smoothness issues I notice (without stats/graphs) are with various deinterlacers and interlaced DVB/PAL sources (not related to your Sync Renderer of course). I rarely, if ever, notice any picture problems with progressive material (perhaps I'm used to judder). I just thought I'd mention the OSD thing in case it helps.

[mark0077]

Hi ar-jar I am having fun trying out your newly merged code. I have 3 questions for you if you have time to answer.

1) I am curious, if for example I am using a display, and with some content being a perfect divisor of my displays refresh, and some content not being a perfect divisor, must I manually switch synchronization settings.

I guess I am asking, will an option appear in the future to automatically switch from one mode to another, when perfect sync isn't possible. For example could I select to "Sync video to display" by default, and perhaps "Present at nearest vsync" otherwise. I am just not sure if I select the first sync option , what would happen if perfect sync isn't possible. Does it iternally switch to another mode?

2) My second question is, is the functionality that is given by power stript to allow "Sync display to video" feasible to code into a future version of your renderer.

3) It has probably being asked before, but will reclock like options like 25fps to 24fps speeddown (pal speeddown) be feasible in a future version :D

In essence I suppose I am asking how you envision the render progressing in terms of ease of setup / automation to make it work v well for most by default.

[ar-jar]

Hi ar-jar I am having fun trying out your newly merged code. I have 3 questions for you if you have time to answer.

1) I am curious, if for example I am using a display, and with some content being a perfect divisor of my displays refresh, and some content not being a perfect divisor, must I manually switch synchronization settings.

I guess I am asking, will an option appear in the future to automatically switch from one mode to another, when perfect sync isn't possible. For example could I select to "Sync video to display" by default, and perhaps "Present at nearest vsync" otherwise. I am just not sure if I select the first sync option , what would happen if perfect sync isn't possible. Does it iternally switch to another mode?

2) My second question is, is the functionality that is given by power stript to allow "Sync display to video" feasible to code into a future version of your renderer.

3) It has probably being asked before, but will reclock like options like 25fps to 24fps speeddown (pal speeddown) be feasible in a future version :D

In essence I suppose I am asking how you envision the render progressing in terms of ease of setup / automation to make it work v well for most by default.

It would be rather easy to implement some automation wrt selecting the right sync option and modifying the base refresh rate of the display automatically when feasible. I will probably add some functions in this territory later.

Questions 2 and 3 are tricker. Powerstrip-like functionality would require that NVidia/ATI add similar functionality to their APIs (NVidia actually accepted my change request to that effect a long time ago but I haven't had a chance to follow it up). So good contacts at e.g. NVidia would be useful to make this happen. Any leads?

Audio speed shifts require careful resampling in the general case afaik. Would I get some help with the audio, then I could handle the video part but I'm not an expert in audio. Maybe there are some OSS audio resamplers out there or somebody willing to help. -A

[mark0077]

Cheers for the replies. Well I think reclock uses an open source audio resampler, http://www.mega-nerd.com/SRC/index.html to achieve this type of audio speed down :D All seems to be open source yay :D I suppose I will add it as a long term feature request, keep up the good work anyways and I look forward to the more automated methods of selecting correct options.

Cheers.

[iSeries]

Sorry, wrong thread - moved.

[hdboy]

ar-jar: as I mentioned earlier, I think it'd be great if you could automatically select the refresh rate the display supports that is closest to the input rate. In options > playback, in addition to "Change fullscreen resolution", possibly an option like "auto select refresh rate". So if my display accepts 24p and 60p, and the material is 23.98 or 23.976, then MPC switches the refresh rate to 24p (if it's not already). If video is 29.98fps or 59.97fps or 25fps, then switch to 60p. That in conjunction with the Synchronization option I think would work very well.

Btw, why didn't you stay with the GothSync renderer name? It's rather catchy :) and more distinctive than Sync Renderer.

[avivahl]

Looking at the latest MPC-HC available from xvidvideo.ru (rev1486), I think you should switch the sync page choices from checkboxes to radio buttons. And yes, I saw that checking one choice actually unchecks the others, but this is exactly what radio buttons are for.

[avivahl]

oh, almost forgot... could you move the sync options page to be a property page of the renderer? It will make the sync renderer "less integrated" and more generic, i guess.

[ar-jar]

Looking at the latest MPC-HC available from xvidvideo.ru (rev1486), I think you should switch the sync page choices from checkboxes to radio buttons. And yes, I saw that checking one choice actually unchecks the others, but this is exactly what radio buttons are for.

Yeah, this code has survived it's original requirements. There were in the beginning some combinations that would work too. Now radio buttons are more appropriate as only one option is allowed at the time. For the time being I will focus on making the renderer as stable as possible though. Then I will beautify the GUI part. -A

[avivahl]

It's wonderful to receive such a quick response. Thank you. :-)

[Jong]

If you want to use the current version with DVD, then you need to turn off hardware acceleration on MPEG2 when you want to play DVDs.This is very useful thanks. I had not tried/realised that it was DXVA causing the problem. Maybe that will help ar-jar narrow down what needs changing to get it working.

Even in non-DXVA mode the Cyberlink decoder does not drop frames at certain fixed points in some of my DVDs like the MPC MPEG2 Decoder does :)

It has also brought to my attention how much standard resizing has improved on my new 5750 when compared with my 3850. Resizing DVDs to 1080p was as muddy as hell on my 3850. I had to use either ffdshow or just a touch of edge enhancement ("1"). Edge enhancement does not work without DXVA but even so the image with my 5750 in non-DXVA mode is almost indistinguishable from my old, much tweaked, ffdshow settings :).

I haven't tried deinterlacing yet but right now I am back using Cyberlink but in non-DXVA mode. :)

[ADude]

Using Sync Renderer with the 'Present at nearest vsync' synchronization option with build 1.3.1486:

Ok sorry, I'm definitely not nuts. If I change the renderer to EVR CP, then untick all the vsync options under Renderer settings, and then change the renderer back to Sync Renderer and then look at the vsync options again, 'Vsync' is ticked but all 3 are greyed out ('Vsync', 'Accurate Vsync' and 'Alternative Vsync'). I then proceed to play a movie - terrible tearing and stuttering.

I then change the renderer back to EVR CP, tick 'Accurate Vsync' and 'Alternative Vsync' (along with 'Vsync') and then change the renderer back to Sync Renderer and look at the vsync options again, all 3 remain ticked but greyed out. I play a movie - play back is perfect ( I tested this over and over and the results are the same every time). So even though the vsync options are greyed out they still have an effect on playback.

Could someone please explain if this is to be expected or not - I had assumed that the vsync options were greyed out because they are not meant to be user selectable with Sync Renderer (i.e Sync Renderer had it's own vsync method and the options were greyed out simply because the render does not use them).

I have found something similar.

I found that if I used EVR CP with 1453 (shortly prior to Sync Renderer) and then used 1465 with Sync Renderer and then went back to 1453 with EVR CP, there were different results the second time with 1453 than the first time.

Similar things occurred with different versions and different orders.

When I rebooted the PC in between each version change, then I could tell each version's performance (as would be predicted by the code changes).

So there is either a memory leak, or else some other way in which different versions affect each other, such as options not being cleared properly.

[mark0077]

When you guys switch back to the standard mpc-hc (without syncrenderer included), you will have to manually select a renderer. mpc-hc will open with no renderer selected in this situation so you need to go in and select your desired renderer again when going to older versions.

[ar-jar]

When you guys switch back to the standard mpc-hc (without syncrenderer included), you will have to manually select a renderer. mpc-hc will open with no renderer selected in this situation so you need to go in and select your desired renderer again when going to older versions.

Good point. Thanks! -A

[ADude]

When you guys switch back to the standard mpc-hc (without syncrenderer included), you will have to manually select a renderer. mpc-hc will open with no renderer selected in this situation so you need to go in and select your desired renderer again when going to older versions.

It uses the default renderer, and nothing is checked in the list of renderers.

If you then go to 1465, Sync Renderer is checked again.

This is a different issue from the one mentioned above (although it could be related).

[mark0077]

Well I'm back again with some questions, and maybe some ideas to improve some of the three different sync options.

I am not trying to annoy, just picking out things I think could be improved as work continues, and some questions that I can't answer from reading your blog. I know the GUI will be improved at a later date, hopefully along with automation of best selection of options, but heres a few comments anyways.

I am using a GTX 295, Windows 7 64bit, with Samsung Series 9 display, and analog Xonar HDAV Deluxe. These Series 9 displays have a 60hz PC mode that doesn't do any funny modification of the image and although I have tried going back to 24hz from time to time, I can't stand the horrible effects that can be seen (another days story). So I decide to stick with 60hz and have used Reclock to get my 23.976 material to 24hz, and mpc-hc to sync this 24hz to my display as best as possible.

-- Sync video to display --
1) Out Of Sync Question.
So with 23.976 material being played on 60hz screen, this would speed the video up to 24fps right like ffdshow would do?
If so excellent!!, but I understand it is noted on your web page that this is with the disadvantage being that audio will get out of sync? If so, without you wasting your time explaining why this happens, could you also do whatever ffdshow does as it doesn't get out of sync in this scenario.
I guess ffdshow uses the open source audio resampler I linked you to, to resample the audio as an alternative to going out of sync over time. This of course would mean tiny pitch changes.
If this can be implemented in a future version, the only disadvantage people might have to be aware of here would be that almost inaudible pitch changes could occur, and that would be only noticible when going into the larger percent speed changes.

2) Frequency adjustment option
Is it in % as I see no percentage sign in the GUI currently? I see 0.00012 represents 0.12% in your documentation. Is this just another way to set a limit of how much things are changed by, just like the "Control limits" option sets a limit of how ms control can be changed?

3) What happens if my display / refresh are off by more than the frequency adjustment, and control limits. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync?

Problem Noticed: Testing a 25fps music DVD that I want to play at 25fps, gives massive audio pops and glitches, and seems to play at a slow deep sounding rate in sync renderer using this option. It must be suffering badly from audio being out of sync and why I hear the audible blip as sound catches up? I didn't think 0.12% would allow this speed change at all, I thought it would revert to another mode.

-- Sync display to video --

I havn't been able to change front porch number in reclock so I guess this isn't support on Samsung Series 9 or my GTX 295. I don't see any newish Nvidia cards listed in supported list.... Maybe some custom resolution might allow changing of this but will need to look into it to see it in action.

1) Only comment is, that ffdshow refers to horizontal front porch in pixels, so I got a bit confused with SyncRender refering to it as columns.
As an improvement, can adjustment of lines / pixels default to 1 for the most fine grained control, and increase number to 2, 3 automatically if previous attempt at finer grain control didn't work? This if it works, could remove the frequency adjustment options from the renderer options?

2) What happens if sync renderer detects that porch control isn't possible on my display / graphics card. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync, or just continue trying adjustments.

-- Present at nearest vsync --
I imagine this will always work for any combination of display / video so no comments here.

Problem Noticed: Playing my Queen 25fps interlaced Video again, as I enabled de-interlacing in ffdshow a few minutes into this clip, making the frame rate change to 50fps, the renderer starts to show frame rate switching from ~41fps to 50fps (In "Actual Frame Cycle" output), as if its going up and down, so the graph goes a bit mad when it starts go back down from 50.000. I can't hear or see this speed change and my machine has no problem with speed in this situation (cpu usage below 3% on 4ghz core i7). I will test some DVD menu's also as a benchmark of the renderer, to see how it can handle speed changes as time goes on. They have caused problems for some renderers in the past.

Other Questions
1) Do all three syncing work better with reclock loaded, ie does it somehow give more accurate details to your renderer in certain scenarios, other than just giving extra control for "Sync display to video".
2) Target Sync Offset: Forgive me on this one. I just imagine the target sync offset for anyone would be 0ms, why is it recommended to have a target of 8 – 14 ms for a 60 Hz display?

Again, I can test any builds you might have that might benefit from testing using the configuration I use. Just let me know.

[ar-jar]

Thanks for your input!


So with 23.976 material being played on 60hz screen, this would speed the video up to 24fps right like ffdshow would do?


Speeding up 23... to 24 is technically possible as long as you let the computer decode audio. Experiments show that the audio renderer "matches rate" at least up to about 0.5% speed difference. Unfortunately too little for 23... -> 25. What's the advantage of shifting from 23... to 24?


Is it in % as I see no percentage sign in the GUI currently? I see 0.00012 represents 0.12% in your documentation. Is this just another way to set a limit of how much things are changed by, just like the "Control limits" option sets a limit of how ms control can be changed?


0.0012 is means 0.12%. To use the actual number instead of a percentage saves one division op :-) This is how much speed is shifted to either slow down or speed up the video when needed. It's a rather crude control algorithm but it seems to suffice.


What happens if my display / refresh are off by more than the frequency adjustment, and control limits. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync?


Today it just bangs its head against the wall, i.e. it tries to adjust but fails and then it tries again. There is today no fallback. It could be more intelligent admittedly.


Problem Noticed: Testing a 25fps music DVD that I want to play at 25fps, gives massive audio pops and glitches, and seems to play at a slow deep sounding rate in sync renderer using this option. It must be suffering badly from audio being out of sync and why I hear the audible blip as sound catches up? I didn't think 0.12% would allow this speed change at all, I thought it would revert to another mode.


Is there a typo above? 25 fps @ 25 fps should work just fine. It would do very few adjustments. Are you using analog audio out? SPDIF will give funny results.


I havn't been able to change front porch number in reclock so I guess this isn't support on Samsung Series 9 or my GTX 295. I don't see any newish Nvidia cards listed in supported list.... Maybe some custom resolution might allow changing of this but will need to look into it to see it in action.


I unfortunately doubt that the 9-series will be supported. ATI seems to be more leaky wrt docs (Rik at Entech once wrote that they depend on leaked docs from NVidia and AMD).


1) Only comment is, that ffdshow refers to horizontal front porch in pixels, so I got a bit confused with SyncRender refering to it as columns.


The columns are one pixel wide :-) When programming we think in rows and columns, that's why.


As an improvement, can adjustment of lines / pixels default to 1 for the most fine grained control, and increase number to 2, 3 automatically if previous attempt at finer grain control didn't work? This if it works, could remove the frequency adjustment options.


Yeah, one could do all kinds of magic with Powerstrip. Too bad it seems to be going out of fashion. It's such an amazing piece of s/w.


2) What happens if sync renderer detects that porch control isn't possible on my display / graphics card. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync, or just continue trying adjustments.


No, it's stupid as of now.


Problem Noticed: Playing my Queen 25fps interlaced Video again, as I enabled de-interlacing in ffdshow a few minutes into this clip, making the frame rate change to 50fps, the renderer starts to show frame rate switching from ~41fps to 50fps (In "Actual Frame Cycle" output), as if its going up and down, so the graph goes a bit mad when it starts go back down from 50.000. I can't hear or see this speed change and my machine has no problem with speed in this situation (cpu usage below 3% on 4ghz core i7). I will test some DVD menu's also as a benchmark of the renderer, to see how it can handle speed changes as time goes on. They have caused problems for some renderers in the past.


I need to look into the code to see what happens at a rate shift. I might only get the rate at start of streaming which should explain your problem.


1) Do all three syncing work better with reclock loaded, ie does it somehow give more accurate details to your renderer in certain scenarios, other than just giving extra control for "Sync display to video".


You mean Powerstrip I presume? It gives a better estimate of the pixel clock but it's not a big deal.


2) Target Sync Offset: Forgive me on this one. I just imagine the target sync offset for anyone would be 0ms, why is it recommended to have a target of 8 – 14 ms for a 60 Hz display?


See this post (http://www.ostrogothia.com/?p=866). Sync offset is the same as "present margin" in the post.


Again, I can test any builds you might have that might benefit from testing using the configuration I use. Just let me know.

I will hold you to that promise :-)

-Arto

[mark0077]

Thanks for your replies. The advantage of speeding 23.976 upto 24 is that 24 fits into 60 exactly 2.5 times giving less jerkyness than 23.976 hz. ReClock does this when its rate is set to "Auto", and like yours, does it with configurable limits. I assumed option 1 was going to sync the 23.976 to my display better by making my video run at 24hz but I know gather it only changes the rate to get the playback rate to an almost exact multiple of the display, not to make a bad situation like mine a little better. Possible improvement! :D

I guess this ability of reclock's would be a mix of option 1, and then option 3 in your sync settings. Maybe if you can perfect your individual renderer modes, maybe get around to including the open source audio resampler, then advanced combinations like this can be suggested or maybe an algorithm can be thought of to make it naturally be used when a scenario could benefit from it (anyone using 60hz display's with 23.976 content).

Regarding the Queen DVD at 25fps, it wasn't a typo. These music DVD's are the only 25fps content that I don't ever want to slow down from 25 to 24hz as the audio was obviously remastered to sound at the correct pitch at 25fps. Obviously at the moment this drives the old option 1 crazy. :D

In any case a toolkit / improvement of two things should make this renderer perfect for myself at least would be

1) Ability to resample audio from one rate to another, along with options and an algorithm to control it.
This would allow
a) 25 -> 24fps speed down which I think alot of users can't go without (although reclock can be used for the time being).
b) Rate changes of say 23.976 to 24 fps without loss of audio sync, even well beyond 0.5% which I assume is the limit when audio isn't resampled to match video rate changes.

2) Options based around these abilities to enable / disable features like PAL SpeedDown.

3) Options to favour certain algorithms in certain situations perhaps, and more importantly the smart algorithm to choose the best of the three synchronization options so every scenario is catered for automatically.

Any input I can give or testing of particular things, as I say, let me know. More than happy to help.

[ar-jar]

Regarding the Queen DVD at 25fps, it wasn't a typo. These music DVD's are the only 25fps content that I don't ever want to slow down from 25 to 24hz as the audio was obviously remastered to sound at the correct pitch at 25fps. Obviously at the moment this drives the old option 1 crazy. :D


Ok, now I see past my prejudices. Your display is running @ 25 fps huh? I haven't tested exactly that scenario to be honest. What happens if you run your the display @ 50 Hz? That's a scenario I test over and over again.
-A

[mark0077]

No, my display is at 60hz, I mean playing 25fps video content at 25fps speed (ie its original speed, no pal speed down as its not required for most music content). So this was 25fps at 60hz. I'm trying to come up with the basics of a smart algorithm, Ill stick it in here and see if you agree with any of my thinkings on it.

[ar-jar]

No, my display is at 60hz, I mean playing 25fps video content at 25fps speed (ie its original speed, no pal speed down as its not required for most music content). So this was 25fps at 60hz. I'm trying to come up with the basics of a smart algorithm, Ill stick it in here and see if you agree with any of my thinkings on it.

Ok. That's unexpected then. I don't have any sound problems with that combination except that the sync adjustment stays at "-1" all the time trying but failing. Are you using analog audio out? And no Reclock? -A

[mark0077]

I had reclock enabled, apologies!!

So here is what I imagine being a high levelish algorithm and options list. This is what I personally would start working with, hope some of it might be of use to yourself when you get around to thinking about it. To test the logic of a possible algorithm I think you could have a simple gui, that would also let the user input a display resolution - refresh rate, and video rate, and click "calculate" to see what the renderer would decide to do. This could be refined before / while it was actually put into actual action in the final renderer. At least the "calculate" option would allow myself and others to go and say, hey in this scenario, with refresh rate x, and video rate y, with option z enabled and option w disabled, the renderer would have decided to do "abc", but the algorithm should be refined so that it does def in this case because "def" would give a better result.

A textual output of the renderers decisions would be great to see what its "thinking" when the algorithm is put in place.

Anyways..

----

--- Options Screen ---

List of resolutions / refresh rates available, with ability to choose which ones can be switched to or not, and possibly which ones to allow frequency adjustment with, with a lines and columns setting for each.


Enabled /Disabled | Resolution | Display Frequency Adjustments
[enabled] 1920 x 1080 @ 60hz | 0 lines | 2 columns
[enabled] 1920 x 1080 @ 24hz | 0 lines | 0 columns
[disabled] 1920 x 1080 @ 1hz | 0 lines | 0 columns
[add] [edit] [remove] [enable][disable][etc]

[enabled] Resolution Switching
[enabled] Display Frequency Adjustments

[enabled] Pal Speed Down

[enabled] Playback Rate Change Allowed
[0.12%] Max Frequency Adjustment
[enabled] Audio Frequency Adjustment Allowed (Would need secret rabbit resampler to be integrated) (Note that when disabled can cause audio going out of sync, but causes pitch change)

[very high] Audio Resampling Quality

[10ms] Target Sync Offset
[2ms] Control Limits +-

----------------------------------------

When Renderer detects rate change
do

# Record the current video rate.

# Generate some basic variables based around high level speed changes requested in options, like pal speed down.
1) If frame rate is 25fps, and if PAL SpeedDown is enabled
Mark video rate as being possibly 23.976 or 24.

# Generate list of possible frequencies, from resolutions and lines / columns figures given in options.
2) If "Resolution Switching" or "Display Frequency Adjustments"
Calculate "Display Frequencies Possible", from various combinations of resolutions, and from what X lines and Y columns changes will mean in terms of display frequency changes.

# Basically figure out what our strategy will be in terms of a one off display resolution / frequency change
3) For each of the possible display frequencies calculated, calculate which "Display Frequency Possible" (from step 2) + "Playback rates possible" (calculated from "Playback Rate Change Allowed" and "Max Frequency Adjustment" options) would give best results, or basically give "Sync video to display" the least to do ;) (how do we define best, making display refresh changes as less of an impact over video rate changes, and then prioritizing whatever combination gives the least skips / glitches).
Make that resolution change (if any).
Wait until resolution change is done?
Make display frequency change using powerstrip (if any).
Wait until frequency change is done?
Make that video rate change to the video and audio (if any).
If "Audio Frequency Adjustment Allowed" then resample audio.

# Now loop using "Sync video to display" knowing the strategy we are using to get in sync from work done above. We perform audio resampling in loop if needed.
4) Perform "Sync video to display" given current playback rate, and display frequency until another rate change occurs where we start again, and possibly pick a new strategy.

----------------------------------------

Oh and one more possible improvement. The graph still seems to refresh / calculate frame rate etc, when video is paused. Maybe this can be disabled when in pause mode.

[BatKnight]

I've been following mark00777 and ar-jar discussion and I would like to add that playing 23.976fps content on a 60Hz has always been a nightmare for me, no matter what render I use.
Ar-jar's render seem to help, and this is what I get: 23.976fps played at 60Hz (http://image-shed.com/show.php/1658_23.976fpsplayedat60hz-1.jpg.html). Notice the change in pattern in the red graph. This happens once in a while and it translates to a glitch or jerkiness in the motion of the Tearing Test Bar. in the quest of getting that CTRL-T test bar to travel across the screen fluidly and smoothly I would like to ask what am I missing? Is there really a way of doing it?

Messing around with the Target Sync Offset should help? If so, how? What differences should I look for when changing the values?

My LCD allows 24Hz and when at it the video is very smooth and the Tearing bar test travels quite smoothly too. But it glitches every once in a while. 2 Examples here: 23.976fps played at 24Hz - example 1 (http://image-shed.com/show.php/1659_23.976fpsplayedat24hz-1.jpg.html) and 23.976fps at 60Hz - example 2 (http://image-shed.com/show.php/1660_23.976fpsplayedat24hz-2.jpg.html)
Can this be minimized or eliminated?

INFO: Specs below, and during video play CPU never got higher than 40% and no other softwares loaded interfere because I've tested without them and get same results.

Bat

[mark0077]

BatKnight, from reading on the reclock forums, the reason 24fps is so desirable over 23.976 in this scenario, is that the final product will be a known number of glitches per second. With 23.976, as there is no number that divides into both it, and 60 evenly, there will be occasions where you have a certain number of glitches per second, and then suddenly you will have an unexpected one in the middle of all of that.

Have you ever tried reclock (without its sync option turned on), and its speed setting set to "Auto (best)". This type of auto mode is what I am hoping ar-jar can build into his code, maybe in step 3 of my attempt at an algorithm above, where its selecting the best combination of display refresh rate and video refresh rate.

In my case, for 60hz, with 23.976 fps video, that turns out to be 60hz display (no change), with 24fps video. 23.976 will give more glitches over time than 24 will. You can minimize this with sync offset, but as I say it will never be as "good" as 24fps on 60hz.

[BatKnight]

Have you ever tried reclock (without its sync option turned on), and its speed setting set to "Auto (best)". This type of auto mode is what I am hoping ar-jar can build into his code, maybe in step 3 of my attempt at an algorithm above, where its selecting the best combination of display refresh rate and video refresh rate.
I haven't used Reclock for a long time, not since version 1.6. Looks like it is very different now.
I've tried it using 60Hz and with 11ms of Target Sync Offset I get no changes in the pattern of the red lines in the stats but It's noticeable (specially in moving pans from down to up [vertically]) that it is not fluid and smooth, it doesn't stutter although it's not fluid.

But when I changed to 24Hz I was in awe! Perfect, smooth, fluid playback of a 23.976fps video. No glitches, no hiccups, nothing!

I left all Reclock settings at default. In your opinion should I had changed anything to help 60Hz playback?
I won't give up from 60Hz because it's somewhat annoying to have to change from 60Hz to 24Hz all the time because of two things. First I use the same computer for games and browsing and the mouse moves slow at 24Hz and I also notice some kind of flicker like in the old CRTs.

Any more suggestions?

Bat

[mark0077]

Well of course if some sort of gui like I suggest was put in place, a renderer could decide to switch to your 24hz display mode to get the best results, and then maybe speed up your 23.976 content slightly, or of course if your display was setup in the gui to allow slight rate adjustments, it could be possible to configure that, and leave speed at original 23.976. It will be great when an algorithm is put in place that people can agree gives best intelligence for a whole range of scenarios, and allows enough flexibility for peoples preferences during the calculations.

I think reclock can even do automatic resolution changing depending on input as is, I am sure you can find out how on the forums. I imagine this would be your best option, followed by 23.976 speed change to 24fps with reclock, followed by 23.976 with some playing with target sync offset to minimize extra judder.

I just hope I'm not going overboard with all of these thoughts on what I think the renderer could become, I suppose I am imagining what I would get if I had the perfect player / renderer for me :D

[ADude]

Restructured and encapsulated everything in the SyncRenderer files.
Is that any actual change in the video processing code, or is it just changes in the structure of the source code without any change in the video processing ?

[ar-jar]

Is that any actual change in the video processing code, or is it just changes in the structure of the source code without any change in the video processing ?

No change in functionality (hopefully) but a better basis for future changes with less risk for unintended side-effects. -A

[Jong]

I haven't used Reclock for a long time, not since version 1.6. Looks like it is very different now.
I've tried it using 60Hz and with 11ms of Target Sync Offset I get no changes in the pattern of the red lines in the stats but It's noticeable (specially in moving pans from down to up [vertically]) that it is not fluid and smooth, it doesn't stutter although it's not fluid.

But when I changed to 24Hz I was in awe! Perfect, smooth, fluid playback of a 23.976fps video. No glitches, no hiccups, nothing!

I left all Reclock settings at default. In your opinion should I had changed anything to help 60Hz playback?23.976fps @60Hz will never be as fluid as @24Hz. You will always have 3:2 Pulldown judder. What Reclock can do is eliminate the additional periodic "jerk" that you get playing 23.976 @60hz.

[Jong]

I think reclock can even do automatic resolution changing depending on input as is, I am sure you can find out how on the forums. I imagine this would be your best option, followed by 23.976 speed change to 24fps with reclock, followed by 23.976 with some playing with target sync offset to minimize extra judder.I used this with XP and Pstrip, but I have not managed to get it working reliably with W7 and my 5xxx series ATI card. PStrip advanced timing is not supported on the latest GPUs and Entech seem to be withdrawing support (claim the product does not sell much any more). Other ways of changing refresh rates in the middle of playback tend to cause problems for many players.

[Pr3d]

Its nice to see GothSync merged into MPCHC.
I'm already using it because it uses less CPU than EVR with DXVA enabled.
Keep up the good work ar-jar, hope to see it merged in the existing renderer asap.

[hdboy]

I have it working pretty well for 23.976fps material on my 24hz/60hz TV. Now the stumbling block is 25fps video (usually UK shows). I get stutters. ctrl+j shows a red sawtooth line with big spikes at regular intervals. Any tip on how to deal with this? thanks.

[Jong]

The only real answer is to change the display to 50Hz. If it is 25p material it might be worth trying slowing down to 24fps, but then it comes down to which is the lesser evil.

[mark0077]

Chances are the 25fps material was recorded at, and should be played at 24fps anyways. 99% of my 25fps PAL content, I choose to play at 24fps, to get the correct audio pitch and frame rate. The only 25fps that should be left at 25fps is mostly music DVD's that have had their pitch corrected to sound correct at 25fps.

[BatKnight]

Chances are the 25fps material was recorded at, and should be played at 24fps anyways. 99% of my 25fps PAL content, I choose to play at 24fps, to get the correct audio pitch and frame rate. The only 25fps that should be left at 25fps is mostly music DVD's that have had their pitch corrected to sound correct at 25fps.
When watching PAL content that was original filmed at 24fps, like US movies, and to get the correct pitch, which PAL Speedown should I tick at Reclock? Media Adaptation, Sound Adaptation or both?

Bat

[mark0077]

Yeah I think the GUI surround this isn't very intuitive. You only select PAL Speed down in media adaptation. If also selected in sound adaption, you get a double whammy and the audio sounds extremely deep.

In reclocks config properties screen, I always set Resampling quality to be "Excellent".

Make sure timestretching "When slowing down media" is disabled in the config properties screen also. Otherwise, you won't get the PAL Speed Down pitch change, as timestretching tries to keep the pitch the same, which is not whats intended during pal speed down. You actually want the pitch change, as you usually get closer to the original content that way.

[iSeries]

After reading this thread I had thought that the Target Sync Offset should be set to around 3/4 of a display refresh cycle - so for a 24hz screen this should be set to around 31? For some reason setting this to 31 gives me tearing. So instead would it be a good idea to change this to the highest value that does not give me tearing? 28 seems to be the highest I can go for tear-free playback.

Or should I just keep it at the default 12?

[Remicade]

In yours opinion what is the best way to play 23,796 content on a 60 Hz LCD 1360x768 ?

[BatKnight]

In yours opinion what is the best way to play 23,796 content on a 60 Hz LCD 1360x768 ?

In my experience I got to know that if your display can't do 24Hz then use Reclock to speedup to 24fps. This way won't give you smooth playback as when on 24Hz, just the classic 3:2 pulldown judder without further stuttering.

If your LCD does 24Hz, then use it. It's quite a difference in smoothness.

Bat

[Leak]

PStrip advanced timing is not supported on the latest GPUs and Entech seem to be withdrawing support (claim the product does not sell much any more).
Reading their forums it sounds more like they don't have the hardware documentation they'd need to support ATI's Evergreen (5xxx) line - yet.

Seeing as ATI released the full shader hardware documentation for it just before christmas, and one of their coders (John Bridgeman) said on the Phoronix forums that they were working on scrubbing the docs and code for modesetting (which is what PowerStrip does) so they can also released that in the near future...

Of course, with those docs it should also be possible to write a stand-alone driver for ATI cards to tweak the timings, taking PowerStrip out of the picture completely as far as twiddling the front and back porch values through the GothSync renderer is concerned...

(NB: that doesn't mean someone is going to do it, of course - it just means it should be possible...)

[madshi]

Of course, with those docs it should also be possible to write a stand-alone driver for ATI cards to tweak the timings, taking PowerStrip out of the picture completely as far as twiddling the front and back porch values through the GothSync renderer is concerned...

(NB: that doesn't mean someone is going to do it, of course - it just means it should be possible...)
Having an open source HTPC optimized Windows driver is one of my wet dreams.

(NB: I definitely have no plans to work on such a thing)

[Leak]

Having an open source HTPC optimized Windows driver is one of my wet dreams.

(NB: I definitely have no plans to work on such a thing)
I guess I should clarify - by "driver" I meant some small piece of kernel-level code that twiddles the card's timing values, not a full blown graphics driver; AFAIK that's what PowerStrip does.

[Jong]

Reading their forums it sounds more like they don't have the hardware documentation they'd need to support ATI's Evergreen (5xxx) line - yet.

Seeing as ATI released the full shader hardware documentation for it just before christmas, and one of their coders (John Bridgeman) said on the Phoronix forums that they were working on scrubbing the docs and code for modesetting (which is what PowerStrip does) so they can also released that in the near future...Let's hope! For sure they currently lack documentation, but they have also said in the last few months that the market and revenue stream for pstrip is drying up so they are not putting much time into it.

It's true that the infinite flexibility of pstrip is less and less useful now with LCDs, fixed refresh rates and synced HDMI audio. But a simplified tool targetted at HTPCs would I think be very popular.

[madshi]

I guess I should clarify - by "driver" I meant some small piece of kernel-level code that twiddles the card's timing values, not a full blown graphics driver; AFAIK that's what PowerStrip does.
Well, I meant a full blown graphics driver. Let me dream... :)

[ar-jar]

Having an open source HTPC optimized Windows driver is one of my wet dreams.

(NB: I definitely have no plans to work on such a thing)

I'd like to subscribe to that wet dream! I once tried to get some open source driver folks interested but I don't think I got any answer actually. One could forget about all the 3D-stuff and just focus on shuffling pixels and doing some 2D-filtering. And adjusting the timings of course in a delicate manner. A question that I still haven't found any answer to is how the digital set-top boxes do this. With dirt-cheap hardware and Linux. Do they have sync or aren't we just noticing the occasional judder because we are not looking for it? -A

[ADude]

I have it working pretty well for 23.976fps material on my 24hz/60hz TV. Now the stumbling block is 25fps video (usually UK shows). I get stutters. ctrl+j shows a red sawtooth line with big spikes at regular intervals. Any tip on how to deal with this? thanks.

The two answers you received were wrong.

(Sorry, nothing personal.)

I have a 60hz TV, and since it is not purchased from Europe, then it does not have a 50hz refresh setting, and probably neither does yours.

And, the UK shows we are watching are not based on films, so slowing them down to 24fps is also wrong. When we say "UK shows" that means "UK TV shows" that were captured from 25fps or 50fps broadcasts.

In my experience, what you need to do is to:

- Choose "Sync Renderer" and EVR Buffers = 10
- Check the "Present at Nearest sync" setting
- Set Target Sync Offset to 10

[Jong]

What is your definition of "wrong"?

The only way to smoothly play 25p content is @50Hz. Even slowing to 24fps still leads to 3:2 pulldown judder. Your answer leads to, even worse, one repeated frame for every five. You are trading smoothness for accurate pitch. Which, as I said, comes down to the lesser of two evils.

I fully respect your preference for judder over inaccurate pitch, but neither is right or wrong and it is a fact (like it or not) that all PAL DVDs of US films preferred 4% inaccurate pitch over judder.

[madshi]

I'd like to subscribe to that wet dream! I once tried to get some open source driver folks interested but I don't think I got any answer actually. One could forget about all the 3D-stuff and just focus on shuffling pixels and doing some 2D-filtering. And adjusting the timings of course in a delicate manner.
Well, my renderer makes a lot of use of pixel shaders, so I'd need access to 3D hardware, too... :(

A question that I still haven't found any answer to is how the digital set-top boxes do this. With dirt-cheap hardware and Linux. Do they have sync or aren't we just noticing the occasional judder because we are not looking for it?
I don't know about dirt cheap hardware. But I have feedback from higher quality companies. One answer from a set-top box designer (ReelBox), one answer from a receiver designer (Arcam), one answer from a Blu-Ray player designer (Ayre):

ReelBox: http://reelbox-forum.com/showthread.php?t=6839
Arcam: http://www.avsforum.com/avs-vb/showthread.php?p=11079529#post11079529
Ayre: http://www.avsforum.com/avs-vb/showthread.php?p=17402589#post17402589

Very interesting posts, I think.

[ar-jar]

Well, my renderer makes a lot of use of pixel shaders, so I'd need access to 3D hardware, too... :(


Yes, we would need to rewrite code but using a full-blown 3D engine to create a texture on two triangles (or something along those lines) is really overkill. I could do with a fast blt function, support for fast convolutions, some LUT functions and some simple arithmetics on color vectors.

I didn't quite understand how the posts that you referred to relate to judder (e.g. pan judder). They seemed to be more about jitter which sounds like something else. What I would like to know is whether simple satellite boxes actually synchronize their video output circuitry to the incoming video and how they in that case tweak the HDMI output to the display to reflect this sync. My take after reading about the standard is that there is actually a "digital sync pulse" in the DVI signal from which the display can extract a clock. I would be great to understand exactly how and how much and when this sync pulse can be tweaked. Or maybe I have misunderstood the standard? -A

[buzzqw]

@ar-jar

i am experimenting with your render, and it's very good so far !
but i have a problem, powerstrip don't support my card (gt240) so i am using reclock with displaychanger (http://www.12noon.com/displaychanger.htm)

will be possibile to implement displaychanger support in mpc-hc GothSync ?

thanks

BHH

[madshi]

using a full-blown 3D engine to create a texture on two triangles (or something along those lines) is really overkill.
The point is that I'm not happy with any of the GPU's built in video processing algorithms. So I'm doing everything myself, and for that I can use all the computational power I can get. The more, the better.

I didn't quite understand how the posts that you referred to relate to judder (e.g. pan judder). They seemed to be more about jitter which sounds like something else. What I would like to know is whether simple satellite boxes actually synchronize their video output circuitry to the incoming video and how they in that case tweak the HDMI output to the display to reflect this sync.
The posts I linked to are talking about adjusting audio / video clocks by using a VCXO. Which you can think of as a clock generator which can be adjusted very accurately. So if video is too fast, they simply lower the clock ever so slightly in real time.

Really cheap devices don't seem to do this. Instead they probably drop video/audio frames every once in a while...

My take after reading about the standard is that there is actually a "digital sync pulse" in the DVI signal from which the display can extract a clock. I would be great to understand exactly how and how much and when this sync pulse can be tweaked. Or maybe I have misunderstood the standard?
My understanding is that this "sync pulse" is simply the speed in which frames are sent by the source device. So it's controlled by the source device's clock generator. I don't think we can really tweak the HTPC audio/video clocks in a useful way. You can use PowerStrip to change the (pixel) clock, but the minimum pixel clock changes you can do are so big that changing them during playback would probably too much of a change and might confuse the display. What we'd really need is a way to change the pixel clock in *MUCH* smaller steps. I don't think the GPU hardware can do this. The GPU's clock generator is probably not flexible enough for such small pixel clock changes...

[ar-jar]

The point is that I'm not happy with any of the GPU's built in video processing algorithms. So I'm doing everything myself, and for that I can use all the computational power I can get. The more, the better.

I understand. But today I guess you are using that raw processing power through DirectX interfaces, the methods of which aren't necessarily optimal for 2D video processing. Or are you using Cuda or OpenCL or something like that for your algorithms?


My understanding is that this "sync pulse" is simply the speed in which frames are sent by the source device. So it's controlled by the source device's clock generator. I don't think we can really tweak the HTPC audio/video clocks in a useful way. You can use PowerStrip to change the (pixel) clock, but the minimum pixel clock changes you can do are so big that changing them during playback would probably too much of a change and might confuse the display. What we'd really need is a way to change the pixel clock in *MUCH* smaller steps. I don't think the GPU hardware can do this. The GPU's clock generator is probably not flexible enough for such small pixel clock changes...

The DVI specs define requirements on the clock and how the receiver must lock to the clock. But is also defines a horizontal and vertical sync. The question is to what extent and how these sync signals are used by the display unit. My Powerstrip-based "genlock" in fact shifts these sync signals one line or one column (or so) when needed and it seems that at least 720 displays immediately adapt to the new sync interval. I do not change the pixel clock. I also read somewhere that LCDs display one line at the time and I would guess that the timing for this is determined by the h-sync pulse, not the pixel clock. But I would be interested to read any articles or specs thay you may have and that explain how for instance an LCD displays the incoming digital signal, i.e what in the signal triggers what actions in the display unit. -A

[madshi]

I understand. But today I guess you are using that raw processing power through DirectX interfaces, the methods of which aren't necessarily optimal for 2D video processing. Or are you using Cuda or OpenCL or something like that for your algorithms?
The whole 3D pipeline is rather complicated and not optimized for video processing, of course. However, you set that up once and then forget it. I'm doing the real work by using Pixel Shaders and they work great for 2D video processing IMHO.

The DVI specs define requirements on the clock and how the receiver must lock to the clock. But is also defines a horizontal and vertical sync. The question is to what extent and how these sync signals are used by the display unit. My Powerstrip-based "genlock" in fact shifts these sync signals one line or one column (or so) when needed and it seems that at least 720 displays immediately adapt to the new sync interval. I do not change the pixel clock. I also read somewhere that LCDs display one line at the time and I would guess that the timing for this is determined by the h-sync pulse, not the pixel clock. But I would be interested to read any articles or specs thay you may have and that explain how for instance an LCD displays the incoming digital signal, i.e what in the signal triggers what actions in the display unit. -A
I know that you are modifying the sync signals, but that's not what high-end Blu-Ray players and satellite boxes do. They're changing the clock, not the sync signals. I can't say that your method is better or worse, I don't know that, but I do know that when I played with the sync settings on my old plasma, it sometimes "resynced" (image went black, then came back after a second or so). I think doing extremely small adjustments to the pixel clock would be a safer way to solve the problem, but the PC hardware doesn't allow us to do that.

[somy]

Hi ar-jar, thanks for your great work, now I can see it's integrated to MPC-HC with auto display refresh rate changing feature, amazing.
I have a question, what is the advised value of target sync offset and control for 24P playback on 23.976HZ display? The default value is 12ms, and I assume it only works for 25P playback on 50HZ device right?
Thanks!

[DigitalLF]

i have a question for Ar-Jar i think... (Leak later told me this is a question for Aleksoid)

are you the maker of the "autochange fullscreen monitor mode"? if so would it be possible to add a option for a delay before opening the file? it would help me to use this feature with MadVR.

its my just my very own personal way of thinking how it could be used with MadVR i don't know if its the solution ...


but I'm just guessing now but to find out the framerate you use mediainfo?

[somy]

i have a question for Ar-Jar i think...

are you the maker of the "autochange fullscreen monitor mode"? if so would it be possible to add a option for a delay before opening the file? it would help me to use this feature with MadVR.

its my just my very own personal way of thinking how it could be used with MadVR i don't know if its the solution ...


but I'm just guessing now but to find out the framerate you use mediainfo?

This could be nice. MadVR need some seconds to warm up, otherwise it will use the wrong refresh rate. I now use CCC to change refresh rate before I start to play movie ::devil::devil::devil:

[DigitalLF]

somy i for now use a hotkeys on my keyboard to run a .bat file to change the refreshrate. but that delay would be perfect =)

[Leak]

i have a question for Ar-Jar i think...

are you the maker of the "autochange fullscreen monitor mode"?
If you read the change log (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=1517) you'll find it actually was added by Aleksoid, so you might have more success asking in the "regular" MPC HC thread...

[THX-UltraII]

Hi Ar-Jar,

I just bought a new ATI 5670 card and have some tearing issues when selecting sync output as renderer. The problem is at the bottom of the screen. So no problems with 2:35:1 movies but you can see tearing at very bottom of the screen with 1:85 (full 16:9) content. It can also be seen when doing a tearing test (ctrl+t) because the two red bars are broken at the bottom of the screen. I also have this problem with EVR custom but found out that I can solve it by CHECKING 'alternative v-sync' (that s NOT the 'accurate v-sync option which is ENABLED by default in EVR custom).

I hope you can do something with this information because I m not using your output now because of this rendering issue. If you need more info let me know!

[somy]

Hi Ar-Jar,

I just bought a new ATI 5670 card and have some tearing issues when selecting sync output as renderer. The problem is at the bottom of the screen. So no problems with 2:35:1 movies but you can see tearing at very bottom of the screen with 1:85 (full 16:9) content. It can also be seen when doing a tearing test (ctrl+t) because the two red bars are broken at the bottom of the screen. I also have this problem with EVR custom but found out that I can solve it by CHECKING 'alternative v-sync' (that s NOT the 'accurate v-sync option which is ENABLED by default in EVR custom).

I hope you can do something with this information because I m not using your output now because of this rendering issue. If you need more info let me know!

The same result I had yesterday when I tried Sync renderer, I thought it was my projector problem:mad::mad::mad:

[DigitalLF]

Leak thank you i did not know where to find the changelog. =)

[THX-UltraII]

The same result I had yesterday when I tried Sync renderer, I thought it was my projector problem:mad::mad::mad:

Try EVR Custom with 'alternative v-sync' enabled and see if that solves your problem.

maybe Ar-Jar know more about this....

[pirlouy]

If you read the change log (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=1517) you'll find it actually was added by Aleksoid, so you might have more success asking in the "regular" MPC HC thread...
In fact, Aleksoid just added patches from X-Dron (who is posting in MPC-HC regular thread indeed).

[aymeric106]

Now that you have merged with the offical build, is there some way to enable your sync method with VMR9 ? (just like your old custom build)

For some reason, Fullscreen D3D with EVR never worked on my secondary display ...

Thanks

aymeric106

[ar-jar]

Hi ar-jar, thanks for your great work, now I can see it's integrated to MPC-HC with auto display refresh rate changing feature, amazing.
I have a question, what is the advised value of target sync offset and control for 24P playback on 23.976HZ display? The default value is 12ms, and I assume it only works for 25P playback on 50HZ device right?
Thanks!

If you're output is really 24p you can use anything up to the cycle time minus a few ms which should be like 35 ms or so. That would give you ample time for using complex shaders and still get tearing-free playback. -A

[ar-jar]

Hi Ar-Jar,

I just bought a new ATI 5670 card and have some tearing issues when selecting sync output as renderer. The problem is at the bottom of the screen. So no problems with 2:35:1 movies but you can see tearing at very bottom of the screen with 1:85 (full 16:9) content. It can also be seen when doing a tearing test (ctrl+t) because the two red bars are broken at the bottom of the screen. I also have this problem with EVR custom but found out that I can solve it by CHECKING 'alternative v-sync' (that s NOT the 'accurate v-sync option which is ENABLED by default in EVR custom).

I hope you can do something with this information because I m not using your output now because of this rendering issue. If you need more info let me know!

I assume you refer to fullscreen playback(?) Try this:
- Use bilinear resizer (it's light-weight)
- Set target sync output to your display cycle time minus say 3 ms (e.g. 17 ms for a 50 Hz display refresh rate)
- Use "present at nearest vsync"

Try both regular fullscreen and D3D fullscreen. If both work, then you can try more complex resizers and shaders with the regular fullscreen. Depending on the processing power of your GPU, you may or may not get tearing when adding more processing to the rendering cycle.

Generally D3D fullscreen should be tearing-free with almost any parameters. The drawback is that if you use the fullscreen gui-support you lose all benefits of D3D fullscreen wrt tearing so I have disabled fullscreen gui support for the time being.

Hope this helps!

Arto

[ar-jar]

Now that you have merged with the offical build, is there some way to enable your sync method with VMR9 ? (just like your old custom build)

For some reason, Fullscreen D3D with EVR never worked on my secondary display ...

Thanks

aymeric106

I'm sorry but I don't have any plans for this as of now. I will focus on the EVR for some time. Hopefully your problems will be solved along the way too. What's your gfx board? -A

[THX-UltraII]

I assume you refer to fullscreen playback(?) Try this:
- Use bilinear resizer (it's light-weight)
- Set target sync output to your display cycle time minus say 3 ms (e.g. 17 ms for a 50 Hz display refresh rate)
- Use "present at nearest vsync"

Try both regular fullscreen and D3D fullscreen. If both work, then you can try more complex resizers and shaders with the regular fullscreen. Depending on the processing power of your GPU, you may or may not get tearing when adding more processing to the rendering cycle.

Generally D3D fullscreen should be tearing-free with almost any parameters. The drawback is that if you use the fullscreen gui-support you lose all benefits of D3D fullscreen wrt tearing so I have disabled fullscreen gui support for the time being.

Hope this helps!

Arto

thxz for your reply Ar-Jar.
I will try some suggestions tonight and report back to you.
I still don t understand the calculation to set the 'Taget Sync offset'. Can you help me with this? => I have a JVC RS20 projector that supports 24p playback and have set my ATI5670 to 1920x1080@23,976Hz.

ps. When you want to give me the correct value for this setting you have to keep in mind that I live in PAL-land and that I also play 25fps material. My JVC projector DOES NOT support 25Hz so I use the 'autochange' options in fullscreen options of MPC-HC as follow:
* 23.50 - 24.00Hz => 1920x1080 32bpp 23Hz (that is 23,976 for ATI)
* 24.50 - 25.00Hz => 1920x1080 32bpp 50Hz
* 29.50 - 30.00Hz => 1920x1080 32bpp 60Hz

And now that you know what hardware and settings I use, can you also give me the best values to use for the frequency of 'sync video to display' which standard is 0.0012 and the setting 'Control Limits' which standard is set to 2ms.

thanks again Ar-Jar

[ar-jar]

ps. When you want to give me the correct value for this setting you have to keep in mind that I live in PAL-land and that I also play 25fps material. My JVC projector DOES NOT support 25Hz so I use the 'autochange' options in fullscreen options of MPC-HC as follow:
* 23.50 - 24.00Hz => 1920x1080 32bpp 23Hz (that is 23,976 for ATI)
* 24.50 - 25.00Hz => 1920x1080 32bpp 50Hz
* 29.50 - 30.00Hz => 1920x1080 32bpp 60Hz

And now that you know what hardware and settings I use, can you also give me the best values to use for the frequency of 'sync video to display' which standard is 0.0012 and the setting 'Control Limits' which standard is set to 2ms.

thanks again Ar-Jar

If you aren't using any advanced shaders or complex resizers (or if you have a potent gfx board) you could choose about 12 ms for the target sync offset for all resolutions and refresh rates).

To really optimize things I would recommend sync offset = display refresh cycle - 3 ms. For 25 Hz (40 ms) this would mean 37 ms. For 50 Hz (20 ms) 17 ms and so on.

The default values should be ok for the other parameters.

This reminds me that I should calculate the default value based on current refresh rate. I'll add that to my to-do list.

Tell me if it works!

-Arto

PS. See my blog for more details about this.

[mark0077]

Hi arjar. Can settings like this be set to an auto setting. Ie use the formula you give above.

Just or kore question. Does evr sync detect media speed changes during playback yet. It seemed to be an issue for me with early versions so I must use evr-cp.

Thank you.

[pirlouy]

If it can help people...
50 Hz: 1/50 = 0,020 s = 20 ms ; -3ms = 17 ms
25 Hz: 1/25 = 0.040 s = 40 ms ; -3ms = 37 ms
23,976 Hz: 1 / 23.976 ~ 41 ms ; -3ms = 38 ms
60 Hz: 1/60 ~ 16 ms ; -3ms = 13 ms

[Peuj]

Hi arjar. Can settings like this be set to an auto setting. Ie use the formula you give above.

Thank you.

Or at least as an option like "Auto sync offset". So users can have the choice.

[mark0077]

Yeah sounds good. Anything that can be automated within reason should be as much as possible.

[THX-UltraII]

If it can help people...
50 Hz: 1/50 = 0,020 s = 20 ms ; -3ms = 17 ms
25 Hz: 1/25 = 0.040 s = 40 ms ; -3ms = 37 ms
23,976 Hz: 1 / 23.976 ~ 41 ms ; -3ms = 38 ms
60 Hz: 1/60 ~ 16 ms ; -3ms = 13 ms

but that's the 'problem' I have. My projector can handle 23,976Hz but I also play 25fps (PAL) material. My projector cannot display at 25Hz so I play the 25fps material @50Hz.

So this means that everytime I switch between NTSC and PAL material I have to manually change the sync offset value from 38 to 17ms and so on.....

[pirlouy]

That's why mark0077 asks for something automatic. :D

[Jong]

Personally I would go with -4ms, not -3ms. I have not seen sync glitches @-3ms but it is close enough that I do sometimes see the red line wavering in sync with the green line. @-4ms the red line is flat. A sign we are cutting things a bit fine @-3ms I think (at least here).

Automatic is definitely good, but things are not as bad as they seem. The most important thing is to have a reasonable margin from vsync. For most peoples systems I would imagine that the -12ms or -13ms you would get setting for 60Hz would be perfectly fine. If you use this same setting for 50Hz, 24Hz etc. you are not taking advantage of the extra margin available to you at those refresh rates, but if -12ms works then it works(!) and the extra margin is really not needed or particularly useful.

When automatic really is needed is if people what to use 96Hz or 120Hz. Then -12ms (or, even worse, -13ms) really would not work.

[pirlouy]

@ar-jar:
When I use EVR Sync, I have some little tearing at bottom (5% of screen) (Aero disabled, and when I don't use D3D fullscreen).
This strip is always present, I mean it's not due to CPU, GPU, RAM limitations; for example, if I use another way to resize (bicubic instead of bilinear), there's the same strip.

This tearing is present with madVR too (a lot more for that matter), but I've noticed that with Beliyaal EVR custom, if I choose V-Sync + Alternative Sync (only these two), there's is no tearing anymore.

Do you know what these options do, or you haven't studied it ?

[ar-jar]

@ar-jar:
When I use EVR Sync, I have some little tearing at bottom (5% of screen) (Aero disabled, and when I don't use D3D fullscreen).
This strip is always present, I mean it's not due to CPU, GPU, RAM limitations; for example, if I use another way to resize (bicubic instead of bilinear), there's the same strip.

This tearing is present with madVR too (a lot more for that matter), but I've noticed that with Beliyaal EVR custom, if I choose V-Sync + Alternative Sync (only these two), there's is no tearing anymore.

Do you know what these options do, or you haven't studied it ?

What happens when you gradually change target sync offset (use CTRL+ALT+up or down arrow)? Test both increasing it and decreasing it. In my experience the tearing should disappear when you have a large enough target sync offset. I don't think the tearing issue can be explained with anything in the DirectX library. It's probably depends on the driver and / or the hardware. My desktop ATI card causes tearing while my laptop ATI card is impossible to force to tear. Go figure.

I'll try to understand the complex algorithms of EVR custom eventually but not quite yet. -Arto

[pirlouy]

No, changing "target sync offset" does not prevent this little strip of tearing (less than 5% of screen in fact).

I didn't remember, but after some tries, I've noticed Tearing is present in VMR9, EVR, madVR but not in VMR7 or Overlay Mixer. This Overlay Mixer may look old, but in fact, it works well regarding tearing or audio lag.

[canuckerfan]

forgive me if I've missed something but I get this error when I try to watch a video:

http://i50.tinypic.com/dgjko2.png

any thoughts?

[pirlouy]

I think it could help if you give information on MPC-HC Build, GPU, OS for example.

[mark0077]

Hi, just wondering how high up the todo list, is getting audio and video in sync.

As said before I always get 20-40ms out of sync with evr-cp and synch renderer. With vsync disabled, and reclock vsync enabled instead, this drops immediately to 0-2ms, and I get noticible back into sync.

[ar-jar]

forgive me if I've missed something but I get this error when I try to watch a video:

http://i50.tinypic.com/dgjko2.png

any thoughts?

This means that you probably have a rather basic gfx board that doesn't have any information about what scan line of the video frame it is currently showing. It should really only be an issue if you use the "synchronize display to video" option. I'll look into the code to see if I issue this warning for other modes as well. That would be a bug. -A

[canuckerfan]

I think it could help if you give information on MPC-HC Build, GPU, OS for example.
build 1.3.1588.0
radeon 9250 pro
windows xp sp3

[FDisk80]

Sorry, double post. ignore this :)

[FDisk80]

What happens when you gradually change target sync offset (use CTRL+ALT+up or down arrow)? Test both increasing it and decreasing it. In my experience the tearing should disappear when you have a large enough target sync offset. I don't think the tearing issue can be explained with anything in the DirectX library. It's probably depends on the driver and / or the hardware. My desktop ATI card causes tearing while my laptop ATI card is impossible to force to tear. Go figure.

I'll try to understand the complex algorithms of EVR custom eventually but not quite yet. -Arto


This is a bug.
I have the same problem when in sync with 24Hz while playing 1080p content.
The solution is very strange. Turn ON Aero and the tearing at the bottom goes away.

But this starts another strange problem
With Aero ON the video starts with insane frame skip. (When starting playback directly in fullscreen)
And the solution for this bug is to open any menu.
Click "O" for example for options then close the options window and the frame skipping stops.
Very strange.

Some Details of the system:
i5 750, HD5770 (DXVA), Win 7 64bit, MPC-HC 64bit v1.3.1594.0

[pirlouy]

@canuckerfan: I don't know if you missed ar-jar post (just before your last post), but the answer is here: you have an old GPU card (6 year old) and it was not an advanced GPU at that time so it may be linked. What options are you using in EVR Sync settings ?

[canuckerfan]

^I was following the guide here: http://www.ostrogothia.com/?page_id=1216

beginning with alternative 1: "using sync video to display"

[pirlouy]

What about if you use option "Present at nearest" ? Have you this error ?

[canuckerfan]

What about if you use option "Present at nearest" ? Have you this error ?
I still get the error. it's weird because in both cases (with or w/o the option ticked) the file plays in the background fullscreen while mpc stays in the foreground. but I can't seem to control anything and I have to close mpc-hc just to get out of the fullscreen mode. is my video card just too old for this?

[ar-jar]

I still get the error. it's weird because in both cases (with or w/o the option ticked) the file plays in the background fullscreen while mpc stays in the foreground. but I can't seem to control anything and I have to close mpc-hc just to get out of the fullscreen mode. is my video card just too old for this?

Sorry, I checked the code and realized that the checking of the graphics board capabilities is a little too conservative, i.e. it will rule out your card whatever sync option you use. I'll fix that in a future build. -A

[ADude]

pirlouy -

The sync option for EVR CP are not sufficiently documented, either in the code or elsewhere. The developer of that specific part of the code, left the project right after finishing the options, and right before some questions were asked to clarify - in a technical way - what the options do. So, all you can do is experiment.

[ADude]

ar-jar -

I recently was playing a video - which turned out to have some encoding problems. But, in an effort to see if the visual problems were due to EVR Sync, I tried going back to EVR CP (and, as implied, there was no difference).

Later, I was playing other videos, and encountered the sort of tearing that is usually fixed by "Present At Nearest" with my setup. I remembered that I had changed to EVR CP, and so, I went into options, selected "EVR Sync" again, and exited.

When I played the video again, the EVR CP options were grayed out and in Options, "EVR Sync" was indeed selected. BUT, the tearing was still there AND Filters said "EVR CP" was in use.

I then rebooted my PC (vista 32bit, no Aero, as stated in my sig), and played the video again immediately after reboot, and this time, there was no tearing and Filters said "EVR Sync".

This seems to be the same bug that I reported a few weeks ago, where changing from EVR CP to EVR Sync does not take effect without rebooting.

[pirlouy]

pirlouy -
The developer of that specific part of the code, left the project right after finishing the options,
Maybe there is not a lot of documentation, but Beliyaal's algorithms are (I think) very interesting to study.
It's one of the first here to have modified EVR in order to avoid judder. And a lot of people use its renderer and it works well.

Options are documented, and Beliyaal has not left; he's less active, but he has committed some changes not so long ago.

[ADude]

Options are documented, and Beliyaal has not left; he's less active, but he has committed some changes not so long ago.

There is very sketchy documentation. The technical questions about the options have never been answered and no other developer has been able to answer them.

[edigee]

I post here , because your sync renderer options was implemented in the main MPC-HC project ,but I guess I can find out more here.
Here's my set up:
HD3650 ,Cat 10.1 ,Vista 32 bit, HD Audio (ALC662 Audio Codec) built in device, MPC_HC build 1623 with: EVR sync ,Sync video to display, audio renderer-system default, display at 60Hz, no reclock, aero enable.
Here's my broblem:
When I play H264 files(mkv or mp4) with 23.976 with DXVA (don't know if it matters) the video is pretty much OK in terms of smooth movement but the audio gives some strange hisses or more like small scratches from time to time as if it was an old vinyl disk.
No matter I switch between AC3 filter or ffdshow audio ,the issue is still on. When I check the sound device tab there are some erors (i guess sync ones) displayed there. When I choose a different audio renderer the problem is still on or the audio goes out of sync.
With EVR Custom those problems dissapear ,but I have small isues in terms of smooth movement of the video.

[pirlouy]

S/PDIF or analog ?
Which option do you use for synchronization (EVR Sync options) ?

[edigee]

S/PDIF or analog ?
Which option do you use for synchronization (EVR Sync options) ?

I'm on analog( stereo output to a stereo amplifier).
EVR Sync -sync video to display-freq. adjust.:0.0012

[swp]

No, changing "target sync offset" does not prevent this little strip of tearing (less than 5% of screen in fact).

I didn't remember, but after some tries, I've noticed Tearing is present in VMR9, EVR, madVR but not in VMR7 or Overlay Mixer. This Overlay Mixer may look old, but in fact, it works well regarding tearing or audio lag.
I can also confirm this. I have constant tearing at the bottom as well with an ati 5850.
- Aero removes tearing but screws up frame rate.
- d3d also removes it but then I get frequent freezes especially if using autochange of fullscreen freq.

[ikarad]

http://forum.doom9.org/showpost.php?p=1376500&postcount=12003

[ADude]

ar-jar -

I recently was playing a video - which turned out to have some encoding problems. But, in an effort to see if the visual problems were due to EVR Sync, I tried going back to EVR CP (and, as implied, there was no difference).

Later, I was playing other videos, and encountered the sort of tearing that is usually fixed by "Present At Nearest" with my setup. I remembered that I had changed to EVR CP, and so, I went into options, selected "EVR Sync" again, and exited.

When I played the video again, the EVR CP options were grayed out and in Options, "EVR Sync" was indeed selected. BUT, the tearing was still there AND Filters said "EVR CP" was in use.

I then rebooted my PC (vista 32bit, no Aero, as stated in my sig), and played the video again immediately after reboot, and this time, there was no tearing and Filters said "EVR Sync".

This seems to be the same bug that I reported a few weeks ago, where changing from EVR CP to EVR Sync does not take effect without rebooting.

[ar-jar]

ar-jar -

I recently was playing a video - which turned out to have some encoding problems. But, in an effort to see if the visual problems were due to EVR Sync, I tried going back to EVR CP (and, as implied, there was no difference).

Later, I was playing other videos, and encountered the sort of tearing that is usually fixed by "Present At Nearest" with my setup. I remembered that I had changed to EVR CP, and so, I went into options, selected "EVR Sync" again, and exited.

When I played the video again, the EVR CP options were grayed out and in Options, "EVR Sync" was indeed selected. BUT, the tearing was still there AND Filters said "EVR CP" was in use.

I then rebooted my PC (vista 32bit, no Aero, as stated in my sig), and played the video again immediately after reboot, and this time, there was no tearing and Filters said "EVR Sync".

This seems to be the same bug that I reported a few weeks ago, where changing from EVR CP to EVR Sync does not take effect without rebooting.

I have added a bookmark to this report in my private "mpc-hc bugs" folder. I'm in the middle of some major restructuring right now so it will be some time before i can look at it. -A

[THX-UltraII]

I can also confirm this. I have constant tearing at the bottom as well with an ati 5850.
- Aero removes tearing but screws up frame rate.
- d3d also removes it but then I get frequent freezes especially if using autochange of fullscreen freq.

+1 for this problem. Still having tearing at the bottom of the screen with Ar-Jar renderer as output. Using EVR Custom for the time-beeing now :(

[ADude]

Ar-jar:

Since you are currently working on full-screen and monitor issues, perhaps you know the answer to this MPC-HC question:

Back when I was using Build 1043 (the last MPC-HC build prior to he-who-I-am-not-allowed-to-mention), I used to use RealVNC to connect to my HT-PC (which otherwise only has my HD TV as its display) from my laptop. That was convenient when someone was using another source to watch that HD TV, and so I could use RealVNC to do various maintenance on the HT-PC at the same time.

Sometimes I would just use RealVNC from the laptop to start a file playing in MPC-HC on the HD TV. This worked fine, although the RealVNC display on the laptop only showed occasional frames and in a lower color depth, but that was irrelevant, since we were watching the video on the HD TV.

Nowadays, using recent MPC-HC versions with EVR Sync, I find that if RealVNC is running at the same time on the laptop from the HT-PC, I get terrible jerky playback on the HT-PC until such time as I stop the RealVNC viewer altogether. Doing that causes the HD TV to go blank for a fraction of a second, and then playback resumes and is entirely smooth from then on.

So, out of curiosity, do you have any idea what changed in MPC-HC (that caused this) ?

[THX-UltraII]

Ar-Jar, any progress in solving the 'bottom-tearing' issue with EVR SYNC?

[ar-jar]

Ar-jar:

Since you are currently working on full-screen and monitor issues, perhaps you know the answer to this MPC-HC question:

Back when I was using Build 1043 (the last MPC-HC build prior to he-who-I-am-not-allowed-to-mention), I used to use RealVNC to connect to my HT-PC (which otherwise only has my HD TV as its display) from my laptop. That was convenient when someone was using another source to watch that HD TV, and so I could use RealVNC to do various maintenance on the HT-PC at the same time.

Sometimes I would just use RealVNC from the laptop to start a file playing in MPC-HC on the HD TV. This worked fine, although the RealVNC display on the laptop only showed occasional frames and in a lower color depth, but that was irrelevant, since we were watching the video on the HD TV.

Nowadays, using recent MPC-HC versions with EVR Sync, I find that if RealVNC is running at the same time on the laptop from the HT-PC, I get terrible jerky playback on the HT-PC until such time as I stop the RealVNC viewer altogether. Doing that causes the HD TV to go blank for a fraction of a second, and then playback resumes and is entirely smooth from then on.

So, out of curiosity, do you have any idea what changed in MPC-HC (that caused this) ?

The short answer is no, sorry. Does this also happen with the other DirectX-based renderers? Have you experimented with Disabling Desktop Composition (just guessing a bit here)? -A

[ar-jar]

Ar-Jar, any progress in solving the 'bottom-tearing' issue with EVR SYNC?

No, sorry. I'm not really able to repeat it. I am instead focusing on making exclusive mode (D3D mode) full-screen more convenient to use. It is my gut feeling (backed up with some facts) that it will always be the most robust mode tearing-wise and timing-wise as it doesn't share the graphics device with any other processes (except perhaps DXVA). -A

[tetsuo55]

You guys should consider EVR-Sync a work in progress, thus highly unstable in some cases.

You should consider it a complete rewrite, and things are likely to break in that process

[THX-UltraII]

So you recommend to stick with ECR Custom for now?

[tetsuo55]

I suggest try EVR-Sync and if it works for you then keep using it.

If however you have problems right now, i suggest comming back later.
Do report the issue you found here, that way we can contact you and check if the final code still has the bug

Work is still being done on the core basics, and that means that bugs could be fixed, reintroduced or added by accident continually

[Jong]

Ar-Jar, any progress in solving the 'bottom-tearing' issue with EVR SYNC?I assume you have tried moving the sync target?

What synchronisation settings are you using? What refresh rate? can you post a screenshot with the OSD displayed when you have the tearing (so we can see what is ahppening to the red and green lines)?

In my experience this can happen if you have the sync target too close to either the start or end of the frame, eg. @50Hz too close to 0ms or -20ms

Or, as ar-jar says, try D3D mode. Even with its current restrictions that is what I use all the time other than when testing.

[THX-UltraII]

I assume you have tried moving the sync target?
What is moving the sync target? Do you mean 'Renderer Settings>VSync>Decrease/Increase vsync offset', or do you mean changing 'MPC-HC Options-EVR Sync Settings-Target sync offset ...ms value'?

What synchronisation settings are you using? What refresh rate? can you post a screenshot with the OSD displayed when you have the tearing (so we can see what is ahppening to the red and green lines)?
I use sync video to display because I use exact matching ATI profiles.

I use 1920x1080@23,976(23ati profile) for NTSC (HD) movies,1920x1080@50Hz(50ati profile) for PAL (HD) and 1920x1080@59,970(59ati profile) for TV based material.

Can post a screenshot tonight.

try D3D mode. Even with its current restrictions that is what I use all the time other than when testing
can t use MPC-HC menu and used to have major lip-sync issues in the past with this option.

[Jong]

What is moving the sync target? Do you mean 'Renderer Settings>VSync>Decrease/Increase vsync offset', or do you mean changing 'MPC-HC Options-EVR Sync Settings-Target sync offset ...ms value'?The latter.

Can post a screenshot tonight.
That will help, I hope.

can t use MPC-HC menu and used to have major lip-sync issues in the past with this option.Yep. Not being able to use right click menu is a downside. Or rather you can enable it under renderer settings, but that basically throws away all the benefits so there is no point (option should be removed IMO). That is why, as I understand it, ar-jar is working on better support for D3D mode that will allow us to switch in and out of it when we need to. But I find in "normal mode", i.e. when not debugging issues or otherwise testing, I never need the right-click menu anyway. All the changes I need to do during playback are mapped to keys on my remote.

D3D mode should not cause lip sync issues might be worth trying it again. If the tearing is fixed this may go away too.

[THX-UltraII]

The latter.

That will help, I hope.

Yep. Not being able to use right click menu is a downside. Or rather you can enable it under renderer settings, but that basically throws away all the benefits so there is no point (option should be removed IMO). That is why, as I understand it, ar-jar is working on better support for D3D mode that will allow us to switch in and out of it when we need to. But I find in "normal mode", i.e. when not debugging issues or otherwise testing, I never need the right-click menu anyway. All the changes I need to do during playback are mapped to keys on my remote.

D3D mode should not cause lip sync issues might be worth trying it again. If the tearing is fixed this may go away too.

thxz for the replies again.
I ll post a screen tonight

What about the value in ms? I have a 23,976Hz profiles, a 50Hz profile and a 59,970Hz profile. I can remember that Ar-Jar told that you need to pick specific values when using 23,976Hz and 50-60Hz. So this would mean I constantly have to change this value when I wsitch between PAL and NTSC material. Or is there some kind of average ms that I can use that s ok for all my profiles? (hope you understand what I mean:))

[Jong]

thxz for the replies again. I ll post a screen tonight What about the value in ms? I have a 23,976Hz profiles, a 50Hz profile and a 59,970Hz profile. I can remember that Ar-Jar told that you need to pick specific values when using 23,976Hz and 50-60Hz. So this would mean I constantly have to change this value when I wsitch between PAL and NTSC material. Or is there some kind of average ms that I can use that s ok for all my profiles? (hope you understand what I mean:)) Tell us what it is currently set at, what refresh rates you get tearing at and let's have a look at that screenshot, before we start changing things.

[Leak]

Yep. Not being able to use right click menu is a downside. Or rather you can enable it under renderer settings, but that basically throws away all the benefits so there is no point (option should be removed IMO).
Works fine for me - I get no tearing/stuttering with Aero disabled and this option enabled.

Granted, I get tearing when the context menu is up, but as soon as I close it the video is smooth again.

So exactly what is your problem with the D3D GUI option, if I may ask?

np: The Seasons - Trois (Undone)

[Jong]

By necessity it disables the extra buffering that gives D3D mode its main advantage.

Generally D3D fullscreen should be tearing-free with almost any parameters. The drawback is that if you use the fullscreen gui-support you lose all benefits of D3D fullscreen wrt tearing so I have disabled fullscreen gui support for the time being.

Are you saying you get tearing without D3D mode, but you do not with it, even with the GUi option on? Because I do not get tearing with EVR sync with or without D3D mode. I use it solely so I can use Reclock to control vsync, which only works with overlay or VMR9/EVR in D3D mode. If you get tearing without D3D mode, but you don't with it, even with GUI on, it may just be a subtle change in timing that is fixing it rather than the extra buffering.

[ar-jar]

By necessity it disables the extra buffering that gives D3D mode its main advantage.



Are you saying you get tearing without D3D mode, but you do not with it, even with the GUi option on? Because I do not get tearing with EVR sync with or without D3D mode. I use it solely so I can use Reclock to control vsync, which only works with overlay or VMR9/EVR in D3D mode. If you get tearing without D3D mode, but you don't with it, even with GUI on, it may just be a subtle change in timing that is fixing it rather than the extra buffering.

With the right timing parameters and no heavy shaders or resizers, i don't get tearing in any mode with my cheap ATI gfx board. D3D with GUI support on the other had is no better than windowed mode full-screen. I have never had tearing with plain vanilla D3D / exclusive mode full-screen. And engineering-wise i prefer it because it doesn't get messed up by the window manager or anything else like that. -A

[Peuj]

Hi ar-jar,

When I active the option in MPC: "Subtitles -> Allow animation when buffering" it creates some "lags" when playing files with external subtitles (including mvk).
It's worst with EVR-CP.

It is known or a normal issue ?

Thanks

[STaRGaZeR]

Hi ar-jar,

When I active the option in MPC: "Subtitles -> Allow animation when buffering" it creates some "lags" when playing files with external subtitles (including mvk).
It's worst with EVR-CP.

It is known or a normal issue ?

Thanks

Here too, the higher the subtitle resolution the worse the lags and stuttering get. I think there's a ticket for this, but I'm not sure.

[Peuj]

ok thanks for the info.

[Jong]

With the right timing parameters and no heavy shaders or resizers, i don't get tearing in any mode with my cheap ATI gfx board. D3D with GUI support on the other had is no better than windowed mode full-screen.Ditto, I suspect THX-Ultra's problem is fixable either by changing sync timing or, if he is using some funky shaders, backing off on those.

@THX,

If you need more help can you:

- tell us the EVR sync renderer settings you have set
- at which refresh rates you get tearing?
- what shaders you are using and overall what filters you are using? if using ffdshow what post-processing are you doing?
- post that screenshot showing the EVR Sync renderer OSD when tearing is occuring, or if the OSD gets rid of tearing (as it might) at least a screenshot at the same refresh rate and with all other settings the same (filters/shaders/sync offset etc.)

[pirlouy]

I also have bottom tearing with EVR-sync, and it's not a problem with sync timing, sure.

We are several concerned by this bottom tearing. I really think any EVR Sync option can't change that (except enabling Aero).

But it's not a big problem, since we can use other renderer meanwhile ar-jar implements Direct 3D in Fullscreen.

[Jong]

I'd ask the same questions I asked of THX, and, of course, full system specs, even if it just helps understand why/when this problem is occuring.

[ADude]

The short answer is no, sorry. Does this also happen with the other DirectX-based renderers? Have you experimented with Disabling Desktop Composition (just guessing a bit here)? -A

There is no Desktop Composition in Vista Home Basic.

And I tried with EVR Custom Presenter and the problem does not exist with that renderer.

So, it is a bug introduced by EVR Sync.

(Again, just for reference, it is stuttering introduced when using VNC to display the HT PC's desktop on another PC, and the stuttering goes away if the VNC viewer is disconnected.)

PS EVR Sync continues to be perfect in displaying 25fps on a 60hz display, while EVR Custom Presenter still has tearing and other issues when trying to do that, so I still prefer EVR Sync due to "Present at Nearest...".

[tetsuo55]

There is no Desktop Composition in Vista Home Basic.

And I tried with EVR Custom Presenter and the problem does not exist with that renderer.

So, it is a bug introduced by EVR Sync.

(Again, just for reference, it is stuttering introduced when using VNC to display the HT PC's desktop on another PC, and the stuttering goes away if the VNC viewer is disconnected.)

PS EVR Sync continues to be perfect in displaying 25fps on a 60hz display, while EVR Custom Presenter still has tearing and other issues when trying to do that, so I still prefer EVR Sync due to "Present at Nearest...".A lot of testing has been done, and the "lack" of AERO is highly likely to be the cause of the tearing without EVR-Sync.
EVR-Sync is being re-designed to to be independent from AERO in fullscreen mode.

[THX-UltraII]

@Jong: haven t found the time yet to post screenshots. I ll post them beginning of this week.

However, I know that the 'bottom-tearing issue' isn t a config problem on my specific setup but a bug that needs (and will) to be fixed be the MPC dev. team.

There is also another reason why I HAVE to use EVR CP:
When using EVR CP there becomes an option available in the renderer settings called 'Enable Frame Time Correction'. I need this option for my 1080p VC1 material to make it run smooth when not using DXVA. This option is not available when running EVR sync.

[Jong]

@Jong: haven t found the time yet to post screenshots. I ll post them beginning of this week.

However, I know that the 'bottom-tearing issue' isn t a config problem on my specific setup but a bug that needs (and will) to be fixed be the MPC dev. team.Don't forget to say in which refresh rates you get tearing and what the frame rate of the media you are using is at the time. And what shaders you are using and the filter chain.

[littleD]

There is no Desktop Composition in Vista Home Basic.

@ADude
Are you aware that Vista Home Basic does have aero theme and microsoft screwed its users?? What is more, i wrote for you, how to enable that many weeks ago, because of your complains about Beliyal work...
Heres my original post http://forum.doom9.org/showthread.php?p=1323109#post1323109

[Grasso]

Hi,

why is synchronization so hard to archieve when one only needs to a) write a video frame to the buffer for every such vsync (given that refresh approximates a multiple of frame rate) and b) re-sample audio? Why is this not possible with Windows 98?

Another problem is speed respectively efficiency. I ran MPC plus Reclock (also for PAL-to-film slowdown), but using a Pentium III 650 and a Nvidia TNT2, DVD playback jerks. We were once told that a Pentium II 233 and a good grafics card were sufficient.

Greetings,
Grasso

[STaRGaZeR]

Arto, do you have any recommendations for this kind of graph? This stuff happens randomly, the renderer starts dropping frames like crazy. Then after a while, it resumes normally. I've already tried everything.

http://thumbnails24.imagebam.com/7217/0588d972163551.gif (http://www.imagebam.com/image/0588d972163551)

[ADude]

A lot of testing has been done, and the "lack" of AERO is highly likely to be the cause of the tearing without EVR-Sync.
EVR-Sync is being re-designed to to be independent from AERO in fullscreen mode.

The problem being reported here:

- has nothing to do with tearing

- is unlikely to have anything to do with Aero

You need to read the whole thread before replying.

(The problem being reported is that EVR Sync stutters when the Desktop is connected by VNC to another PC, while EVR CP has never stuttered in that situation. The tearing was cited to answer the automatic reply "Then why not just use EVR CP". I.E. That EVR Sync fixes the tearing problem without Aero and without using any Vsync method other than "Present at Nearest".)

[ADude]

There is also another reason why I HAVE to use EVR CP:
When using EVR CP there becomes an option available in the renderer settings called 'Enable Frame Time Correction'. I need this option for my 1080p VC1 material to make it run smooth when not using DXVA. This option is not available when running EVR sync.

And what exactly does 'Enable Frame Time Correction' do ?

For example, it could be the same technical change as some EVR Sync option.

This is why it is so important to document what these options actually do.

[THX-UltraII]

I also have bottom tearing with EVR-sync, and it's not a problem with sync timing, sure.

We are several concerned by this bottom tearing. I really think any EVR Sync option can't change that (except enabling Aero).

But it's not a big problem, since we can use other renderer meanwhile ar-jar implements Direct 3D in Fullscreen.

noob question:
How do I enable/disable Aero in W7 Ultimate x64? :stupid::stupid:

[Jong]

are you not going to bother answering the earlier questions or post your screenshot?

[THX-UltraII]

I promised you to do this last week, but didn t find the time for it. I ll really do it this weekend.

[tetsuo55]

The problem being reported here:

- has nothing to do with tearing

- is unlikely to have anything to do with Aero

You need to read the whole thread before replying.

(The problem being reported is that EVR Sync stutters when the Desktop is connected by VNC to another PC, while EVR CP has never stuttered in that situation. The tearing was cited to answer the automatic reply "Then why not just use EVR CP". I.E. That EVR Sync fixes the tearing problem without Aero and without using any Vsync method other than "Present at Nearest".)Sorry used the wrong wording, AERO takes away any stuttering and tearing by controlling the timing of frames being rendered, that said, i do agree that this is highly unlikely to be related to the vnc problem you mention.And what exactly does 'Enable Frame Time Correction' do ?

For example, it could be the same technical change as some EVR Sync option.

This is why it is so important to document what these options actually do."Frame time correction" is a hack for a problem in VC1 decoders. [Basically VC1 uses a different way to represent the timing of a frame than all other formats)

[kramcd]

Hi Guys,

I have posted this question before, but didn't get a reply...

1). With regards to Fast Forwarding a video file; I have noticed that sometimes I can get MPC-HC to Ffwd at up to 128x normal speed, but most of the time it's only 4x. I'm not sure what setting has changed to enable or disable this...I do like the 128x speed though!

2). Is it possible to have MPC-HC Rewind properly, rather than the current 'slow down speed' that happens?

3). I guess if I had a 'wish list' it would include the above things, and perhaps individual settings for each movie, i.e. the ability to set subtitles on or off, make volume adjustments, adjust audio sync etc for each movie. In the same way the option to resume a movie happens, it could hold these individual settings.

ATI HD 5670, 10.2 Drivers, Q6600, P5B-E, Win 7 64 Bit, 4GB Ram,

Cheers.

[namaiki]

2). Is it possible to have MPC-HC Rewind properly, rather than the current 'slow down speed' that happens?


I would doubt it as a lot of files can't really be read backwards.

[kramcd]

I would doubt it as a lot of files can't really be read backwards.
It's curious as (for example) XBMC can do this with the same files.

[namaiki]

http://forum.xbmc.org/showpost.php?p=373761&postcount=7

I didn't say that it's impossible.

If you want, you can still use ctrl + left arrow to skip back 5 seconds or something like that.


1). With regards to Fast Forwarding a video file; I have noticed that sometimes I can get MPC-HC to Ffwd at up to 128x normal speed, but most of the time it's only 4x. I'm not sure what setting has changed to enable or disable this...I do like the 128x speed though!

Also, what do you mean by this?
Do you mean that a 128x speed is not accessible, or that the picture just freezes while it appears to be fast-forwarding, or other?

[kramcd]

http://forum.xbmc.org/showpost.php?p=373761&postcount=7

I didn't say that it's impossible.

If you want, you can still use ctrl + left arrow to skip back 5 seconds or something like that.




Also, what do you mean by this?
Do you mean that a 128x speed is not accessible, or that the picture just freezes while it appears to be fast-forwarding, or other?
OSD reports that it is only advancing at 4x (will not go any faster) and visually that appears to be the case, yet sometimes, for some reason, I've been able to speed fwd at up to 128x and you can certainly see how fast it is going!

[Leak]

OSD reports that it is only advancing at 4x (will not go any faster) and visually that appears to be the case, yet sometimes, for some reason, I've been able to speed fwd at up to 128x and you can certainly see how fast it is going!
I've found that the soundtrack's sample rate(!) can sometimes be a limiting factor - try resampling the audio to something lower (like 22kHz) and see if you can speed it up more then...

[nightrhyme]

Was looking to try this MPC HC edition but none of the provided links work.

Perhaps site is down.

Any alternative links to download ?

[edigee]

http://www.ostrogothia.com/video
You can get it from here. But most of ar-jar developments were already included in the main MPC-HC. It's all about the new EVR-Sync renderer (based on EVR-CP) and all the settings regarding a better sincronization of the video with the display and vice versa.
Anyway , all ar-jar work is highly apreciated in MPC-HC development.

[nightrhyme]

http://www.ostrogothia.com/video
You can get it from here. But most of ar-jar developments were already included in the main MPC-HC. It's all about the new EVR-Sync renderer (based on EVR-CP) and all the settings regarding a better sincronization of the video with the display and vice versa.
Anyway , all ar-jar work is highly apreciated in MPC-HC development.

Ahh ok however site is still inacessible: http://downforeveryoneorjustme.com/www.ostrogothia.com/video

[ar-jar]

Ahh ok however site is still inacessible: http://downforeveryoneorjustme.com/www.ostrogothia.com/video

I seem to have an issue with my ISP. They've probably changed my IP address. I'll look into it. Thanks for pointing out. -A

EDIT: Fixed. But as pointed out, most of the stuff is already in the trunk build. I've been working on some improvements but progress has been slow.

[ar-jar]

There is a new test version of MPC-HC with EVR Sync available on my blog (including source code). It attempts to enable toggling between windowed mode and exclusive mode full-screen (D3D mode) without having to restart the player. The idea is to make tear-free exclusive mode more accessible. Take it for a spin if you are adventurous. It's likely to have several bugs. I'm not sure if I'm moving in the right direction here so I haven't committed anything to svn yet.

I could also use some help hunting down some outstanding COM references that I haven't been able to find. Please let me know if you have plenty of time on your hands and some skills in DirectX and COM.

Arto

[Peuj]

Hi Arto,

Is there a way to activate a debug mode with this test version to give you useful information in case of crash or issues?

Edit: I mean using DebugView.

Thanks

[ar-jar]

Hi Arto,

Is there a way to activate a debug mode with this test version to give you useful information in case of crash or issues?

Edit: I mean using DebugView.

Thanks

No, this is a release build so it doesn't have debug info in it. Please let me know if you get a crash etc and I can provide a debug version. -A

[Peuj]

Ok thanks. Under testing.

For the moment no crash or issues.
Don't see any difference during playback.

Official EVR Sync:
http://img714.imageshack.us/img714/9946/oldj.jpg (http://img714.imageshack.us/i/oldj.jpg/)

New EVR Sync
http://img218.imageshack.us/img218/4345/newve.jpg (http://img218.imageshack.us/i/newve.jpg/)

[ar-jar]

Ok thanks. Under testing.

For the moment no crash or issues.
Don't see any difference during playback.


Good to hear and thanks for testing. I see you're not using D3D full-screen though. Could you test too if you can toggle between D3D full-screen and windowed mode. Also across two displays if you have such a set-up. -A

[Peuj]

I've set the D3D option and put MPC on my second display (like done with the previous tests).
When I open a file everything is normal then I switch to fullscreen, Aero is deactivated (I'm on Vista) and MPC is on D3D mode (No context menu,...)
Everything looks ok, excepted it looks like the green line is less "stable" or less "linear" than in the previous tests (maybe because of Aero off?).

http://img18.imageshack.us/img18/8801/d3dg.jpg (http://img18.imageshack.us/i/d3dg.jpg/)

I can switch back to windowed mode without issue.

Note that MPC crashes if I activate the "Launch file in fullscreen" option with D3D activated.

[nlnl]

ar-jar
Thanks for the renderer!
And could you port FTC (Frame time correction) option from EVR CP to your renderer for VC1 playback.
I (Vista, Nvidia 9400) have some issues with Cyberlink decoder: very slow frame rate (1/2 of original).

[Matching_Mole]

As nlnl I'm facing to the same issue with VC1 codec. But the Frame time correction option is just a workaround, the real issue is into the m2ts splitter and it will be great if this can be fixed one day!

[maxxximilian]

I also have bottom tearing with EVR-sync, and it's not a problem with sync timing, sure.

We are several concerned by this bottom tearing. I really think any EVR Sync option can't change that (except enabling Aero).

But it's not a big problem, since we can use other renderer meanwhile ar-jar implements Direct 3D in Fullscreen.

I have also the same tearing on bottom and I I can't use Fullscreen D3D either because then I will get stuttering.
I think this is somehow related to newer ATI graphics cards, I have currently Radeon 5850 but same tearing was with previous Radeon 4890 card, too. Rest of the computer: i7-920, 6GB RAM, Creative XFi Titanium sound card, Win 7 x64, 20" LCD and 42" Plasma TV (via HDMI, Extended desktop). Tearing is on both screens and even if I disable one screen.
ar-jar test build is acting the same way.

[pirlouy]

I have a nVidia 8800GT, so I don't think it's driver related.

[maxxximilian]

I have a nVidia 8800GT, so I don't think it's driver related.
Oh, what renderer/settings do you use then to avoid tearing?

[pirlouy]

- Overlay Mixer
- ffdshow does the decoding, post-processing, subtitles
- MPC-HC changes refresh rate according to video
- Reclock deals with Sync.

[maxxximilian]

- Overlay Mixer
- ffdshow does the decoding, post-processing, subtitles
- MPC-HC changes refresh rate according to video
- Reclock deals with Sync.
I prefer MPC internal subtitling because then subtitles are all the time in same place and size, unfortunately they don't work under Overlay Mixer. It seems I have to live with tearing or change player then.

[pirlouy]

Yet, I've seen players which are able to add subtitles to Overlay Mixer, so it should be possible for MPC-HC.

Indeed, internal subtitles of MPC-HC with EVR are very nice. But nobody works on subtitles renderer right now, and I don't want to be captive because of a feature which is not in development.

But, with ffdshow, since I let it do the upscaling, then add subtitles, subtitles are all at the same size whatever the size of video is.

[maxxximilian]

Yet, I've seen players which are able to add subtitles to Overlay Mixer, so it should be possible for MPC-HC.

Indeed, internal subtitles of MPC-HC with EVR are very nice. But nobody works on subtitles renderer right now, and I don't want to be captive because of a feature which is not in development.

But, with ffdshow, since I let it do the upscaling, then add subtitles, subtitles are all at the same size whatever the size of

video is.
Upscaling? So there isn't black borders up and down? This is exactly what I need, how do you do that?

[Jong]

@ar-jar,

I have been working with the MediaPortal guys, who seem to be using some of your code to enhance their EVR Presenter. Both of us have found that if we repeatedly pause/play uisng "Present at Nearest" (Reclock not used) we can get absolutely horrible judder that never stops. Basically, only about 2/3rds- 1/2 of the frames are big displayed.

It seems to happen when the "Sample Paint Time Correction" is almost exactly the frame time. In fact, specifically, with 25p material (PAL DVD) @50Hz the "Sample Paint Time Correction" oscillates between 20ms and 21ms when this is happening, which is interesting in itself of course as the frame time is only 20ms.

It looks like there is a small danger zone when EVR Sync itself cannot decide which vsync to target.

I don't normally see this because, as you may remember, I normally use EVR Sync with all sync option OFF, instead using Reclcok vsync correction.

[lych_necross]

I have been working with the MediaPortal guys, who seem to be using some of your code to enhance their EVR Presenter. Both of us have found that if we repeatedly pause/play uisng "Present at Nearest" (Reclock not used) we can get absolutely horrible judder that never stops. Basically, only about 2/3rds- 1/2 of the frames are big displayed.
Well, don't do that ;)

[Jong]

No I think you are missing my point. :rolleyes: probably I did not describe it accurately enough. :o

I meant there is a small chance on any seek or resume that it will get in this state, but the easiest way to make it happen is to keep pressing play/pause until it does.

[me7]

- Overlay Mixer
- ffdshow does the decoding, post-processing, subtitles
- MPC-HC changes refresh rate according to video
- Reclock deals with Sync.

Does ffdshow support BluRay subtitles by now?

[pirlouy]

Upscaling? So there isn't black borders up and down? This is exactly what I need, how do you do that?
ffdshow adds black border up and down in order to respect Aspect Ratio, else it does not add useless border.

@me7: I don't know for Blu-Ray as I don't have Blu-Ray equipment.

[lych_necross]

I was kidding Jong. I've noticed that bug as well. It seems to happen pretty randomly whether the renderer is EVR Sync, EVR CP, or standard EVR (I haven't tested others yet).

[Jong]

I was kidding Jong.No worries. :)

[THX-UltraII]

Any news on when the 'bottom tearing issue' will be fixed?

[maxxximilian]

Any news on when the 'bottom tearing issue' will be fixed?
I don't know if it will helping you but I got rid of it doing this:
View, Renderer Settings, Reset and reset to optimal renderer settings.
I'm using EVR Custom and under Renderer Settings, VSync are all options ticked - VSync, Accurate VSync and Alternative VSync.

[pirlouy]

But it's not the same renderer.
EVR Custom is not EVR Sync.
I have no tearing either with EVR Custom and one of its specific options.

[THX-UltraII]

Also using EVR Custom here with all three sync settings enabled to prevent bottom tearing.

Hope EVR Sync will be updated in the near future so we can use that one instead.

[THX-UltraII]

Is this project dead?

I was still hoping for a 'bottom tearing issue' solution......:(:(

[ianken]

Is there a way to get D3D exclusive mode AND refresh rate change on full-screen? It seems to be one or the other and D3D is the only way I get no tearing with this build.

Well: got refresh switching and vsync in line and on my Panasonic plasma (which does ecertying between 23 and 60hz, it looks great.

Oddly I have an MKV with VC1 content that is 24p, but the res mose change is to 60Hz as if it is "other." It could be the decoder, I vaguely recall VC1 defualting to 60Hz on the output pin, even though the player seems to know it is 23.976.

but man, H.264 24Hz and 25Hz stuff is AWESOME. I hope these changes make it into the mainline MPC-HC builds soon.

[THX-UltraII]

I think (but dont hope!) that this is a dead project........

[Jong]

Read ar-jars blog:

http://www.ostrogothia.com/video/

[ar-jar]

I think (but dont hope!) that this is a dead project........

Hi guys; This is the deal: I got stuck way back trying to get the D3D full-screen toggle to work with the built-in DXVA decoder and finally I gave up, at least for the time being. D3D is the only really fool-proof way of avoiding tearing on XP that I know of. (W7 uses a new graphics interface that avoids many of the problems.) The thing is that I can't get the DXVA decoder to "release" the graphics device properly and therefore I cannot design a stable toggle function. This issue is also present in EVR Custom. (Check the "Reinitialize when changing display", option, play something that throws in the DXVA decoder and then drag the window to a second display.)

The alternative would be to run in D3D mode all the time but that would require a whole menu manager that works in D3D (I still want to use the menus for subs etc.). In the mean time more people are moving to W7 and the problem of tearing is slowly going away. -A

[pirlouy]

In the mean time more people are moving to W7 and the problem of tearing is slowly going away. -A
As explained in another dedicaced thread, Aero causes several problems, and personnally, I don't use Aero for videos despite I use W7.

[ikarad]

Hi guys; This is the deal: I got stuck way back trying to get the D3D full-screen toggle to work with the built-in DXVA decoder and finally I gave up, at least for the time being. D3D is the only really fool-proof way of avoiding tearing on XP that I know of. (W7 uses a new graphics interface that avoids many of the problems.) The thing is that I can't get the DXVA decoder to "release" the graphics device properly and therefore I cannot design a stable toggle function. This issue is also present in EVR Custom. (Check the "Reinitialize when changing display", option, play something that throws in the DXVA decoder and then drag the window to a second display.)

The alternative would be to run in D3D mode all the time but that would require a whole menu manager that works in D3D (I still want to use the menus for subs etc.). In the mean time more people are moving to W7 and the problem of tearing is slowly going away. -A

I have one question about your evr sync.

When I use evr custom + ctrl+j function, red curve is a line but green curve is a line that up lightly during 40 seconds before go down on the red curve.

example:
http://img508.imageshack.us/img508/7184/debut.jpg (http://img508.imageshack.us/i/debut.jpg/)

http://img408.imageshack.us/img408/2992/suiteh.jpg (http://img408.imageshack.us/i/suiteh.jpg/)

What means because I don't understand?