[mythtv] Interesting video jitter effect

[Ed Wildgoose]

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