[mythtv] DVD playback issues, patch

[davmac at davmac.org]

>
> it probably should be something like this
>

... (snipped)

yep, that looks good to me too

> also notice the labs for dvd check. I think that is also important though
> its only a guess.
> however is 2 seconds enough for dvd?

I don't know. That line of code was in there before I touched anything.

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

Davin