Slow drift in a/v sync on non-nVidia system

[jpilk]

In late 2019-render and now in master I get a slow drift, of order 2 seconds per hour, in a/v sync in a framed window display on a monitor. The system uses ffmpeg decoding and deinterlace. I don't see the drift on a system using nVidia graphics. Mismatched use of frame display rates seems a possible root cause, but #13531 did not fix it.

At frontend startup on the NV box 
 
2019-12-05 14:16:59.461932 I  DisplayX11: Raw/unsorted XRANDR modes:
2019-12-05 14:16:59.461950 I  3600x1080 50.00
2019-12-05 14:16:59.461958 I  1680x1050 51.00
2019-12-05 14:16:59.461964 I  1440x900  52.00

2019-12-05 14:16:59.464301 I  DisplayX11: Updated/sorted XRANDR modes (interlaced modes may be removed):
2019-12-05 14:16:59.464319 I  1680x1050 59.95
2019-12-05 14:16:59.464328 I  1440x900  59.89
2019-12-05 14:16:59.464335 I  1280x1024 75.02   60.02

$ xrandr
Screen 0: minimum 8 x 8, current 3600 x 1080, maximum 16384 x 16384
VGA-0 connected primary 1680x1050+0+0 (normal left inverted right x axis y axis) 433mm x 271mm
   1680x1050     59.95*+
   1440x900      59.89  
   1280x1024     75.02    60.02  

On the affected box only the raw/unsorted block is shown and the NV-CONTROL X extension is reported to be not available.

In both cases the 'raw' values have been rounded. This seems strange.

Skipping backwards and forwards makes the effect worse.

The -v playback log reports only small errors, and drops frames to keep them below around 40 ms.

[jpilk]

I have no doubt that the recent commits are improvements, but I'm still seeing drift in the no-nVidia system; around 1200 ms over a recent "Peston v Johnson" debate with lots of lip movement. It may not be the most technically stable of sources. Now the drift does seem to come in bursts of "dropping frame to catch up, lateness 30 to 50 ms" with other sequences in which the audio is reported to be ahead by around 20 ms and I detect no drift.

The display is in a framed window in a KDE-Plasma desktop. xrandr 74.98, AVSync2 1 ms

I have just noticed the "MythXOpenDisplay() failed" - and the line below it.

2019-12-07 15:16:26.169352 C  mythfrontend version: HEAD -> master [v31-Pre-19e3f36156b] www.mythtv.org
2019-12-07 15:16:26.169363 C  Qt version: compile: 5.9.7, runtime: 5.9.7

2019-12-07 15:16:28.213192 I  Display: Found screen 'VGA1'
2019-12-07 15:16:28.213223 I  Display: Using screen 'VGA1' (Make: Unknown Model: Unknown)
2019-12-07 15:16:28.213255 I  Display: Geometry 1440x900+0+0 Size 410mmx260mm
2019-12-07 15:16:28.213319 C  MythXOpenDisplay() failed
2019-12-07 15:16:28.213339 N  Display: Desktop video mode: 0x0 -1000000.000 Hz

2019-12-07 15:16:33.649756 I  Display: Available modes:
2019-12-07 15:16:33.649779 I  1440x900  74.98   59.89
2019-12-07 15:16:33.649788 I  1280x1024 75.02   60.02

[jpilk]

Now I find that the two lines I drew attention to are no longer appearing, with the same build as above. mythfrontend -v playback or mythfrontend -display :0 -v playback. I'll rewatch it - again.

[Mark Kendall]

John - are you happy that this is fixed?

[jpilk]

I have had c85a6877a8 running for a few minutes under f30 with nVidia, but initially using ffmpeg and (iirc) HQ deinterlacers. Frames were dropped and sync drifted badly with BBC4 *HD* h264 and got worse with forward/back skipping.

No drift seen so far on that box and recording with nvdec and NVDec Adaptive, and the OSD rarely moves from 0 ms.

I'll build for el7.

[jpilk]

OK, my "Peston v Johnson" test recording has previously shown serious lipsync problems in el7. I have just played it again and no a/v drift was noticeable.

Frame dropping was reported "quite often", particularly when I was reloading Thunderbird, and CPU load, usually 2 x 85%, seems high for SD. The log sample below looks as if sensible things are happening. I'm not sure that the recording does.

Commit 234f34b0

OSD shows Codec/Dec? MPEG-2 ffmpeg, CPUs 2 x (2.80 GHz) ~85%, Deint 2x CPU onefield

2019-12-11 19:36:32.119275 I  Player(1): FPS:   25.01 Mean: 39987 Std.Dev:  1237 CPUs: 88% 82% 
2019-12-11 19:36:33.119052 I  Player(1): FPS:   25.01 Mean: 39980 Std.Dev:   660 CPUs: 80% 86% 
2019-12-11 19:36:33.671667 I  Player(1): AV Sync: Audio ahead by 33 ms
2019-12-11 19:36:33.709330 I  Player(1): AV Sync: Audio ahead by 32 ms
2019-12-11 19:36:33.746729 I  Player(1): AV Sync: Audio ahead by 30 ms
2019-12-11 19:36:33.785031 I  Player(1): AV Sync: Audio ahead by 27 ms
2019-12-11 19:36:33.821721 I  Player(1): dropping frame to catch up, lateness=31845 usec
2019-12-11 19:36:33.892225 I  Player(1): AV Sync: Audio behind by 27 ms
2019-12-11 19:36:33.936415 I  Player(1): AV Sync: Audio behind by 24 ms
2019-12-11 19:36:34.116205 I  Player(1): FPS:   25.08 Mean: 39875 Std.Dev: 10713 CPUs: 88% 83% 
2019-12-11 19:36:35.119459 I  Player(1): FPS:   24.93 Mean: 40118 Std.Dev:   802 CPUs: 86% 84% 
2019-12-11 19:36:36.119252 I  Player(1): FPS:   25.01 Mean: 39980 Std.Dev:   599 CPUs: 86% 81% 

[jpilk]

It seems worth identifying the critical commits here. I think the main one is

​https://github.com/MythTV/mythtv/commit/bd4822af363ea810d25d48fe4d1179a6571ba277

which moved the deinterlacer inside the sync loop.

​https://github.com/MythTV/mythtv/commit/c85a6877a8acd001c74f0ada1ab57f7f68fb66d6

simplified that loop and may give quicker response with less jitter.

[ggervasio]

I am still seeing a significant drift using the 2x software deinterlacers. I will attach a log of "mythavtest -v playback,timestamp" although the drift I see is more than what is being reported in the log.

[jpilk]

Yes. Using Normal profile, Standard decoder, 2 CPUs, Deblocking filter, OpenGL YV12 renderer, both deinterlacer modes the same and other boxes unticked, the HQ bwdif and the Medium yadif still have broken sync. The Low quality onefield setting gives locked good sync for me. Reported CPU loads are above ~85% for all those settings. I haven't noticed video badness. BBC4 DVB-T 704x576@25.00fps

[jpilk]

Newer box, intel i3-2100 4-core @ 3.10 GHz, Fedora 30 and nVidia GT_710 440.36 at commit 5049d4b

I have this using OpenGL HQ profile, Standard decoder, max 4 CPUs, Deblock, OpenGL YV12, both deinterlacers HQ with no boxes ticked. 1920x1080@25.00fps, H.264 ffmpeg, CPUs 4x 35% to 40%, Deint 2x CPU bwdif, playing as a 'Video' with no seektable.

I'm not seeing a/v drift, and the picture 'waviness' when panning has largely gone too, although it's still not perfectly smooth. It was still there when using nvdec decoding and the nvidia adaptive deinterlacer. The nVidia driver says it is synced to the TV display.

With these settings the viewing quality in continuous playback seems similar to that from DLNA, or the leanback frontend for FireTVstick 4k in a format that it supports.

[Mark Kendall]

John - I'm assuming from your last comment that this is fixed.

[jpilk]

I haven't noticed a/v drift recently, and with a sufficiently powerful cpu 'Normal' decoding plays better than nvdec did, at least before the recent c/c++ headers reversion. Yes, fixed.