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

[Peter Bennett]

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