[mythtv] AVSync2 Improvements

Mark Spieth mark at digivation.com.au
Sat Mar 2 02:32:20 UTC 2019


On 3/2/2019 10:50 AM, Peter Bennett wrote:
>
>
> On 3/1/19 5:28 PM, Mark Spieth wrote:
>> On 3/2/2019 7:21 AM, Peter Bennett wrote:
>>>
>>>
>>> On 2/28/19 4:10 PM, Mark Spieth wrote:
>>>> I watched too last night with the patch using mediacodec however I 
>>>> had it on old AVSync but the finish early issue still existed which 
>>>> is strange too.
>>>>
>>> The "finish early" fix only applies to AVSync2. See comment 1 in the 
>>> ticket.
>>>> Will have to repeat tonight with AVSync2.
>>>>
>>>> I can make some programs available again if it helps Peter. Use my 
>>>> previous link but use recordings/1020_20190228080000.ts (news last 
>>>> night) or some of the other recent ones. The one listed is 
>>>> guaranteed to show the issue. 1020 is HD and 1021 is SD.
>>>
>>> I will try that one. Does it always glitch in the same place?
>>
>> I dont see any glitches at all during playback of any of these 
>> programs. The time is just wrong but this also does not happen 
>> linearly. My test last night with AVSync2 worked well except I had 
>> mythcommflag suck 21g out of my ram bringing the whole backend to a 
>> grinding halt until I deleted the errant process, but thats 
>> another/different problem. Playback on the shield paused at that 
>> period but the timestamp was correct at that point. I thought 
>> originally that the deletemap search for the timestamp had an 
>> infinite loop but I suspect that is wrong, but more testing will 
>> ensue today.
>>
>> There are others too. anything with a channel number in 10xx is a 
>> dvbt recording. I have left some around for this purpose 
>> (testing/validation).
>>
>>>
>>> I did see a period of stuttery playback during David's recording 
>>> while I was testing the finish earky fix. The thing is, during the 
>>> stuttery playback the system was unresponsive to the remote. This 
>>> indicates that something on the system was pre-empting mythfrontend.
>>>
>> I had a different problem the other day where with mediacodec with 
>> both AVSync and AVSync2, both exhibited a play 1sec then skip 1 sec 
>> type behaviour which was really weird. Unfortunately I deleted that 
>> without thinking after playing successfuly with SW decode. This may 
>> be the same as the stuttery playback but not sure. Only ever happened 
>> once, on a program I watch weekly.
>>
>>> What springs to mind is that it may have been doing a java full 
>>> garbage collect operation. My experience with java (non-android) is 
>>> you need to be careful to avoid full garbage collect operations 
>>> during a real-time process like playback. Mediacodec decoding goes 
>>> through java code so it may be a possibility. I don't know how you 
>>> adjust the garbage collect settings on android, on regular systems 
>>> it is via parameters on the java command line.
>> I dont either, but if this was a problem, other apps would have seen 
>> this too. Unlikely cause.
>>>
>>> Do you notice that it is unresponsive to the remote while the 
>>> stuttering takes place?
>>>
>> No. But I have only seen it once.
>>
>> Mark
>>
>>
> I tried your news program at 1.5x. At 6:42 the audio became way out of 
> sync with the video. Repeating the test and going to 6:42 did not show 
> it again, so it is not something special in the video causing it.  I 
> will try it again and see if I can track down the problem.
>
> It may be something that goes away when we have direct rendering. It 
> could be related to the fact that some 75 frames per second are being 
> copied into memory. Even with some frames being skipped on display to 
> keep up, it remains that they are still all copied to memory. I had 
> thought of inserting some code into the decoder so that frames that 
> are destined to be skipped are not copied to memory, but if we get 
> direct rendering that would become moot, so I decided to wait for 
> direct rendering.

The time issue happens at the same rate irrespective of the playback 
speed. I suspect your problem may be an NTP twiddle which would stuff 
things right up since I think only video uses system time. Thats why I 
implemented QElapseTimer to do timing since it uses monotonic CPU time. 
I can post a patch if you like.

Also I have a stuttering program again. Its recording right now. When 
complete it will be 6.5h but is only 25m in ATM. I can keep it if you 
want but normally I delete straight after watching, which I'm doing now.

1013_20190302020000.ts

Stuttering occurs right at the start of the program with mediacodec 
decoder. SW dec is fine. Either avsync method exhibits this so its 
mediacodec related.

HTH

Mark



More information about the mythtv-dev mailing list