[mythtv] AVSync2 Improvements

[David Engel]

On Tue, Feb 12, 2019 at 06:38:46PM -0500, Peter Bennett wrote:
> 
> 
> On 2/12/19 3:59 PM, Mark Spieth wrote:
> > On 2/13/2019 3:01 AM, Peter Bennett wrote:
> > > I have been using the latest patch https://code.mythtv.org/trac/attachment/ticket/13383/20190208_1644_catchup_plus.patch
> > > for a couple of days and it looks good now.
> > > 
> > > Mark- you said you may have some improvements - I plan to commit it
> > > anyway and those can always be done afterwards.
> > > 
> > > You said that making the wait into a series of short waits may
> > > improve things. Currently on a desktop system everything is between
> > > -5 and +5 ms so I don't know if much improvement is possible. Also
> > > on thinking about it I don't know how that would help, if the
> > > operating system is going to delay resuming a process on one wait,
> > > would it be less likely to delay it on a bunch of smaller waits?
> > > 
> > > If I don't hear anything back I will commit that patch to master and
> > > fixes/30.
> > > 
> > By all means commit. It seems pretty good to me. Haven't tested live TV
> > since I don't use it but the periodic video stutter is ok. Not as smooth
> > as it could be but pretty good at all speeds so far used. I see on the
> > shield +-20ms which I don't understand ATM. The opensles driver chunks
> > things into 10ms blocks so that is currently the best audio time quantum
> > that is available. Ill look at providing a better estimate which should
> > be possible using the buffer callback and a time delta.
> > 
> > The original AVSync used some averaging/smoothing of the AV delta, so
> > that may be useful to improve playback smoothness. Panning shots and
> > ticks show this effect quite clearly.
> > 
> I added the avsync averaging code to address the problems with OpenMAX
> Audio. AVSync2 is supposed to achieve the same by limiting the size of each
> adjustment to 10 ms or other value as specified in settings. You could try
> changing that to see if it helps.
> > Not sure how much the smaller delays affect things. When I get time Ill
> > disable or maybe put in a config and do some A/B tests.
> > 
> > As mentioned before, there may be a timestamp wrap issue but only saw
> > strangeness once and have deleted that program so Ill have to wait until
> > I see it again.
> > 
> The code under "if ((lateness > AVSYNC_MAX_LATE || lateness < -
> AVSYNC_MAX_LATE)" is supposed to address timestamp wrap, which should occur
> without anything unusual being visible. If you have any example which wraps
> I would like to test it and make sure.
> > Cheers
> > 
> > Mark
> > 
> I have attached a new patch to the ticket to address the LiveTV problem.

Recordings worked fine with the new patch.  Live TV was also better in
that it did sync up.  I think we can and should do better, though.
Several seconds before the big stuttering settles down 60+ seconds for
the little, jerkiness to go away is too long, IMO.  I know most of us
either don't use live TV or don't mind pausing briefly when we do.
However, some of us have family members who do use live TV and, at
least in my case, it has been a point of contention.

My hope is that we can find a good, deterministic way to handle the
live TV case better.  Failing that, we might need to capitulate add a
delay.  I know someone objected to that recently.  Perhaps we could
make such a delay configurable with the default being 0.

David
-- 
David Engel
david at istwok.net