[mythtv] DVD playback issues, patch

Mark Spieth 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 
>> otherwise.
>> 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 mailing list