[mythtv] AVSync2 Improvements

Mark Kendall mark.kendall at gmail.com
Thu Feb 14 23:05:50 UTC 2019


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.

As far as I'm concerned this is a regression.

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.

I would definitely suggest that adding a setting to work around a
semi-random/uncontrollable delay is a bad idea.

Regards,
Mark

On Thu, 14 Feb 2019 at 20:25, Peter Bennett <pb.mythtv at gmail.com> wrote:
>
> There is a new patch that adds the wait to channel change and "switch
> input".
>
> https://code.mythtv.org/trac/attachment/ticket/13383/20190214_1507_catchup_plus.patch


More information about the mythtv-dev mailing list