[mythtv] DVD playback issues, patch

[Mark Spieth]

>>
>> no as avsync_adjustment is for realigning, not measuring and is based on
>> the
>> refresh rate not the delivered rate.
>
>In vsync.cpp, "AdvanceTrigger()" advances the trigger by the frame
>interval, not the refresh interval. The avsync_delay gets added to the
>trigger value in WaitForFrame(). It is totally about keeping the video
>frames in sync with the audio. It is calculated based on the current
>difference between the audio and video timecode. I don't know what you
>mean by "based on the refresh rate".
>
>(Admittedly, this is only what I understand from looking at the code. I
>asked questions on this list previously about how things were meant to
>work, but no-one answered then. In any case, my patches are based on these
>assumptions, and they happen to fix real problems).
>
>Just to make it clear, here's my understanding of what goes on:
>- video and audio are played. The vsync implementation is used to delay
>between video frames.
>- avsync_delay is the delay between video and audio
>- if video and audio are perfectly in sync then avsync_delay should be 0
>or very close to it
>- as you say avsync_avg is a smoothed-out version of avsync_delay
>- there does however tend to be a constant drift, either positive or
>negative, in sync. That is video is either slightly faster or slightly
>slower than it should be.
>- also, sometimes the video and audio get out of sync by quite a bit and
>this requires a large correction to be made
>- avsync_adjustment is used to alter video frame rate by slowing down or
>speeding up the display of the next frame
>
>And yes, avsync_adjustment is used for realigning, but it's added to the
>standard trigger delay (i.e. the frame interval, in vsync.cpp) so it
>should be taken into account when calculating avsync_delay. (or otherwise,
>avsync_adjustment shouldn't be reset to 0 every frame like it is
>currently. Perhaps that's really the better answer).
>
>Before my patch, it's true that avsync_adjustment was limited to a refresh
>interval (or even half of one - can't quite remember). But that never made
>sense. What if the AV sync was way out (particularly, if the video was way
>ahead) and a large adjustment was needed? This was, incidentally, the
>exact problem I was seeing.
>
>> avsync_delay is the instantaneous estimation of avsync.
>> avsync_avg is smoothed so that any minor variations dont cause excessive
>> frame double/skip jerkiness.
>
>Yes, I understood that already.
>
>>
>> avsync_adjustment is not part of the delay estimation algo and shouldnt
>> be.
>
>Then it should be maintained as a cumulative and not reset to 0 every
>frame. Otherwise you bounce in and out of sync, because the sync drift
>tends to be constant.

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.
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.

now this could be changed by doing the avsync_avg calc before the frame 
tweek is done in the same loop so that its done earlier. but after diverge 
is calculated I think. I would have to analyse the flow more to get a better 
picture in my head. just initial thoughts.

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.

HTH
mark