[mythtv] AVSync2 Improvements

[Peter Bennett]

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.

Peter