[mythtv] AVSync2 Improvements

[Peter Bennett]

On 2/14/19 6:05 PM, Mark Kendall wrote:
> Peter,
>
> This discussion and the direction the code is going worries me.
>
> Firstly, as I've said recently, I never took any interest in the a/v
> sync code before because it just worked. It might have a jitter or two
> after a seek, channel change etc - but it always recovered.
> Over the last few weeks I've realised that just isn't the case any
> more - for 'old' avsync  or avsync2. Both just get it wrong far too
> often and in the worst cases never recover and/or just lose the plot
> suddenly when playback has been fine and uninterrupted for minutes
> beforehand.
I have never noticed that - see the comment about Music Choice below.
> As far as I'm concerned this is a regression.
Please make sure you do not have the setting "Music Choice" checked. 
This may cause out of sync playback, so preferably leave it turned off 
if possible.

> Secondly and more importantly, I think you're fighting symptoms and
> not causes. I think David alluded too it in a previous email - but
> fundamentally the code is starting to control a/v sync after the
> battle has been lost. Audio and video are taking very different paths
> after being demuxed - and in the most common case, the far longer path
> is for video. I think you need to look at how playback is
> started/restarted and ensure that, for example, the audio doesn't
> start playing 20-30 frames ahead of the video (seen commonly here). It
> is so obvious sometimes that the playback window is still showing when
> the audio has started.
>
> If that can be addressed, then the job of the main a/v sync code
> becomes much easier - and the complexity that seems to be being
> introduced can be avoided.
Have you tried the latest patch? AVSync2 was designed to be smoother but 
it was unfortunately taking a few seconds to get audio and video 
synchronized at the start. The latest patch is primarily to address 
that. It also addresses the problem of audio starting too soon.
> I would definitely suggest that adding a setting to work around a
> semi-random/uncontrollable delay is a bad idea.
David requested that. It defaults to zero. See if you can convince him :).

Peter