[mythtv] Interesting video jitter effect

[Terry Barnaby]

Ed Wildgoose wrote:
> 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Are you using an interlaced display mode, perhaps driving a TV ?
If so there is another issue that can come into play here.
If the 25Hz frame write is not in sync with the interlace output
frame display you will get bad jitter. I have this problem with MythTv
on an M10K box using TVout. The display is sometimes jitter free on
motion and then switches to jitter for a time unless I pause and
restart. More info on my problem is at:

http://www.kingcot.eclipse.co.uk/unichrome/unichromeTvOut.html

Terry

-- 
Dr Terry Barnaby                     BEAM Ltd
Phone: +44 1454 324512               Northavon Business Center, Dean Rd
Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
Email: terry at beam.ltd.uk             Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
                       "Tandems are twice the fun !"