[mythtv] DVD playback issues, patch
mark at digivation.com.au
Mon Nov 23 06:20:16 UTC 2009
>Slow reply, but...
>On 16/11/09 13:32, Mark Spieth wrote:
>> avsync_adjustment is used to advance or retard video the next time
>> through the loop (the call to AVSync()).
>> it is 0 as only if the measured avdelay is too big does it get set
>> it is always in integral # of frames at the rate being displayed, i.e.
>> the refresh rate.
>Having looked at the code for quite a while now, I still can't understand
>why the avdelay needs to be an integral number of refresh intervals. The
>videosync object will make sure the frame is displayed during vertical
>retrace, regardless of what avdelay you feed it.
>> avsync_adjustment is calculated by the avsync_delay. if this delay is 1.5
>> frames ahead or behind, set avsync_adjustment such that the next time
>> through, a frame is doubled or skipped.
>I understand what it's doing, I just don't understand:
>- why it waits to be 1.5 frames ahead or behind before it adjusts
>- why it adjusts by only one refresh interval
note: I dont really know too much other than the small tweeks I too have
made personally. so YMMV
there are a few output sync methods.
1 is the timer method which has no hardware basis
2 is the various h/w sync methods, of which I use opengl_sync
to my thinking, it doesnt matter as both have the same underlying
quantization of output presentation.
>refresh interval != frame interval!!
that is correct. audio timestamps vary more finely than video ones which are
always quantized to frame interval. this is modified by the playback speed
output rate is always at the refresh interval.
so we have 2 problems here. massaging the frame rate to coincide with the
refresh/output rate and keeping the avsync in check.
what we see is at the refresh rate but we have no direct knowledge of which
frame is actually displayed. we also need to know which frame is shown next.
this the output vtimestamp (based on refresh rate) is adjusted to keep the
atimestamp within bounds. but since the video is a more coarsely quantised
system, we modify our knowledge of the vtimestamp by the amount that the
output system would change it. i.e. at the refresh rate.
we cant change when a frame is displayed as that is controlled by the output
hardware and is always at the frame rate. better we control dropping, dups
than the hardware anyway.
we are talking about a control system with estimated variables.
the better the estimation, the better the result.
note: the current audio timestamp is also estimated.
>> also if you want to handle bigger # frames simultaneously, then
>> avsync_adjustment would need to be multiples of the output frame rate and
>> be handled apropriately. all possible. ATM only 1 frame per pass thorugh
>> AVSync is allowed. thus double speed or 1/2 speed until in sync.
>But why does avsync_adjustment need to be multiples of the refresh rate??
hope Ive answered this adequately.
More information about the mythtv-dev