[mythtv] AVSync in master, Normal decoding, vga monitor and built-in audio analog stereo

John Pilkington johnpilk222 at gmail.com
Mon Dec 9 21:21:52 UTC 2019


On 09/12/2019 20:20, Peter Bennett wrote:
> 
> 
> On 12/9/19 1:46 PM, John Pilkington wrote:
>> Hi Mark, Peter, Tim et al...
>>
>> I'm now running b5edda1b06e, today's master, under el7 with hardware 
>> as in the subject.
>>
>> A recording that allows good sensory evaluation of a/v sync shows 
>> noticeable drift that is not evident from the -v playback log.
>>
>> The same recording plays with perfect a/v sync via the MythTV DLNA 
>> server on my TV
>>
>> This sample of the log shows a higher rate of frame-dropping than the 
>> average for that recording.  It suggests to me that the result of 
>> dropping a frame may not be getting through to the sync filter input. 
>> I first reported sync drift on 16 Nov, and IIRC I first noticed it a 
>> day or two earlier.  AVSync2 increment is 1 ms.
>>
>> HTH,
>>
>> John P
>>
>> {{{
>>
>> 2019-12-09 18:19:49.635638 I  Player(5): dropping frame to catch up, 
>> lateness=39890 usec
>> 2019-12-09 18:19:49.793242 I  Player(5): dropping frame to catch up, 
>> lateness=38490 usec
>> 2019-12-09 18:19:49.832012 I  Player(5): AV Sync: Audio ahead by 28 ms
>> 2019-12-09 18:19:49.960731 I  Player(5): dropping frame to catch up, 
>> lateness=48985 usec
>> 2019-12-09 18:19:49.988455 I  Player(5): AV Sync: Audio ahead by 24 ms
>> 2019-12-09 18:19:50.054778 I  Player(5): AV Sync: Audio ahead by 24 ms
>> 2019-12-09 18:19:50.116016 I  Player(5): dropping frame to catch up, 
>> lateness=47266 usec
>> 2019-12-09 18:19:50.156979 I  Player(5): AV Sync: Audio ahead by 33 ms
>> 2019-12-09 18:19:50.216963 I  Player(5): dropping frame to catch up, 
>> lateness=30218 usec
>> 2019-12-09 18:19:50.378709 I  Player(5): dropping frame to catch up, 
>> lateness=32955 usec
>> 2019-12-09 18:19:50.542979 I  Player(5): dropping frame to catch up, 
>> lateness=38217 usec
>> 2019-12-09 18:19:50.700887 I  Player(5): dropping frame to catch up, 
>> lateness=37134 usec
>> 2019-12-09 18:19:50.861823 I  Player(5): dropping frame to catch up, 
>> lateness=39076 usec
>> 2019-12-09 18:19:51.015041 I  Player(5): dropping frame to catch up, 
>> lateness=32288 usec
>> 2019-12-09 18:19:51.172908 I  Player(5): dropping frame to catch up, 
>> lateness=31159 usec
>> 2019-12-09 18:19:52.062073 I  Player(5): AV Sync: Audio behind by 1 ms
>> 2019-12-09 18:19:52.889115 I  Player(5): AV Sync: Audio ahead by 24 ms
>> 2019-12-09 18:19:52.921252 I  Player(5): AV Sync: Audio ahead by 23 ms
>> 2019-12-09 18:19:52.992925 I  Player(5): FPS:   24.94 Mean: 40102 
>> Std.Dev: 18410 CPUs: 91% 91%
>> 2019-12-09 18:19:56.984290 I  Player(5): FPS:   25.06 Mean: 39909 
>> Std.Dev:  1221 CPUs: 81% 78%
>> 2019-12-09 18:20:00.984315 I  Player(5): FPS:   25.00 Mean: 39996 
>> Std.Dev:  1200 CPUs: 80% 79%
>> 2019-12-09 18:20:01.868788 I  Player(5): dropping frame to catch up, 
>> lateness=66031 usec
>> 2019-12-09 18:20:01.901175 I  Player(5): AV Sync: Audio ahead by 57 ms
>> 2019-12-09 18:20:01.940942 I  Player(5): AV Sync: Audio ahead by 39 ms
>> 2019-12-09 18:20:01.977668 I  Player(5): AV Sync: Audio ahead by 35 ms
>> 2019-12-09 18:20:02.011394 I  Player(5): AV Sync: Audio ahead by 29 ms
>> 2019-12-09 18:20:02.045813 I  Player(5): AV Sync: Audio ahead by 24 ms
>>
>> )))
>> _______________________________________________
> 
> Audio ahead is worse for the user experience than audio behind. However, 
> per the wikipedia 
> (https://en.wikipedia.org/wiki/Audio-to-video_synchronization#Recommendations) 
> expert viewers could not detect anything less than 125ms behind to 45ms 
> ahead. Based in that I do not correct anything that is less than 40ms 
> off. You should not be able to detect errors of 39ms. I suspect that 
> your sound equipment or the linux alsa component may be giving incorrect 
> information back to mythtv about the state of audio output and amount of 
> audio being buffered.
> 
> With regard to dropping frames not getting through, each frame of audio 
> and each frame of video has a timestamp, and these are matched up. So 
> regardless of dropping video or audio, the timestamps of the following 
> frames will be used to sync up.
> 
> Peter

That is what I would hope to see, and I think the DLNA playback may well 
be using it;  but in this mythfrontend system I'm having to apply an 
adjustment of around 2000 ms after playing for around 40 minutes, 
starting from 0 ms.  It's a new feature, perhaps designed to make me 
watch election broadcasts :-)

John




More information about the mythtv-dev mailing list