[mythtv] Frames Played issues

[Piotr Oniszczuk]

> Wiadomość napisana przez Mark Spieth <mark at digivation.com.au> w dniu 10.02.2020, o godz. 07:36:
> 
> 
> On 10/02/2020 2:37 pm, Peter Bennett wrote:
>> 
>> 
>> On 2/9/20 10:26 PM, Mark Spieth wrote:
>>> I still get some issues when timestamps reset/wrap. This all assumes timestamps are monotonic increasing which is not necessarily true.
>> 
>> My intention was that resets , wraps and any other anomalies would be handled in avsync here -
>> 
>>         // sanity check - reset m_rtcBase if time codes have gone crazy.
>>         if ((lateness > AVSYNC_MAX_LATE || lateness < - AVSYNC_MAX_LATE))
>>            ......
>> 
>> Of course, it may not be working correctly or as well as I hoped.
>> 
> How does this affect timestamp derived duration?
> 
> Mark
> 

Guys,

As small data point related probably to A/V sync: I have issue of playback occasionally entering jumpy video playback for some time and recover to good playback after some time (10..30sec). 

I have this on amlogic s905 platform and only on recordings as I can play bluray rips hours without this issue.
More and more I’m tending to think this issue is related to A/V sync - that’s why I’m writing here.  

What I’m thinking: 
as issue is on recordings (interlaced content with not low probability of stream errors) and not on bluray (progressive with rather low stream errors rate) - my hypothesis is that stream errors are impacting video decoder and video decoder behaviour impacting A/V sync in a way it can’t re-sync quickly and enters jumpy video playback.
Just hypothesis.

Maybe in this A/V sync related discussion we can include considerations (and dedicated code to recover) for non-typical cases like i.e video decoder non-expected behaviour or stream errors causing A/V sync not able to quickly recover?

Exemplary fe log where at end I have jumpy playback is here: https://pastebin.com/ezGvPPtw