[mythtv] AVSync2 Improvements
Mark Spieth
mark at digivation.com.au
Tue Feb 12 23:48:18 UTC 2019
On 13/02/2019 10:38 am, 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.
It was just a gut feeling. No evidence. Have to find another instance
and chase it when I see it.
>> Cheers
>>
>> Mark
>>
> I have attached a new patch to the ticket to address the LiveTV problem.
>
LGTM but it does change the pause nature of the system. Not sure of this
effect, but resetting rtcbase seems key.
Mark
More information about the mythtv-dev
mailing list