Hi Doug,
> I think you're probably seeing an effect that's taken care of in the
> video sync methods that can actually track the retrace time (phase) of
> the video refresh, rather than just its period. Those methods are
> nVidia, DRI (I think), and OpenGL. nVidia works for driver versions
> 43xx and older, and OpenGL works (properly) for 6111 and newer.
>> What happens is that if the display point drifts too near the vertical
> retrace, there's some uncertainty about whether we will show a frame
> before or after the retrace, mostly based on scheduler randomness. If
> we know where we are in relation to the retrace, we can adjust out of
> the danger zone.
Indeed, I am pretty sure this is the cause. Thanks for the note that I
should look to the OpenGL sync stuff. Will turn it on and see how it goes.
Interesting question though is why mplayer doesn't seem to suffer from
this effect? They do have a fairly involved sleep function which tracks
all kinds of stuff, but I don't think it is *that* clever.
It did occur to me that if this is an effect that lots of people are
seeing then we could improve things by instead of tracking frame to
frame time, we could instead assume a fixed refresh rate and sync to
that. As the audio time deviates from the assumed video time then
ocassionally you will drop/gain a frame, but you would at least keep in
sync with the notional clock (something like record the time when we
start playback and then we just use (now() - start)/50 as our notional
frame time point indicator - if you see what I mean?)
> Once it gets into this jittering state, does it eventually clear up if
> you let it keep playing? If so, we've drifted out of the danger zone
> and are solidly on one side or the other of the retrace.
Have never tried long enough, but it is always a random time from start
before it happens which is what gives me the clue it's when the two
traces line up.
> You could probably improve RTC by verifying that your refresh rate is
> *exactly* the same as the video's frame rate.
Well, it's a custom modeline doing as near 50Hz as I can get. Video is
25fps PAL from DVB-T.
However, it will always drift because peoples audio clocks are not
perfect. You will always gain or lose a bit of time if we clock the
video to the audio. I think the issue comes from trusting the audio
clock too much and not trying to estimate the frame redraw time and
stick to that? We could implement a software version of the OpenGl sync
stuff for example which just picks and arbitrary start point and counts
every N ms from there forwards...?
Interesting effect anyway. Thanks for the pointers
Ed W