[mythtv] Interesting video jitter effect
terry1 at beam.ltd.uk
Tue Nov 30 17:18:39 UTC 2004
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
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:
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 !"
More information about the mythtv-dev