MPC-HC GothSync tryouts

[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