Changes between Initial Version and Version 1 of Ticket #13494, comment 4


Ignore:
Timestamp:
10/26/19 21:41:36 (7 years ago)
Author:
madscientist159

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #13494, comment 4

    initial v1  
    11I've updated the patch to use the output framerate instead of the source framerate.  This was messing up my initial analysis since MythTV can select 60Hz output rates for 30FPS content.
    22
    3 It looks like a small static delay (under 100ms) plus 6 frames of delay just about handles the A/V sync problem completely when switching from 24FPS to 60FPS.  I do use the GL renderer, so I wonder if there's some extra video buffering in the host stack as well that's contributing to the overall delay.
     3It looks like a small static delay (under 100ms) plus 6 frames of delay* just about handles the A/V sync problem completely when switching from 24FPS to 60FPS.  I do use the GL renderer, so I wonder if there's some extra video buffering in the host stack as well that's contributing to the overall delay.
     4
     5* My setup is a bit more complex than even this -- direct measurement of the A/V sync as projected / played over audio shows a ~88ms audio delay and a 12 frame video delay from the source, so the exact parameters to fix the A/V sync permanently on my setup are 12 frames of video delay combined with -88ms of fixed audio delay.  I seem to be cursed with the ability to see even a few dozen ms of delay, hence my wanting to fix this for good, but other people that have watched the same desynced video didn't notice anything amiss.  It's very likely that the sub-100ms desync inherent in any modern split system (separate video path from audio path) was simply undetected by most MythTV users.