diff options
author | wm4 <wm4@nowhere> | 2016-08-07 14:06:54 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2016-08-07 14:14:32 +0200 |
commit | 32cc190a552551cc7e7150e8603b6a75e0a6d94f (patch) | |
tree | 9e79b1ebe3aeb91ea7c2f82bf2797d452c72569a /player | |
parent | 39ae261cc59598426b6e6beea2c849a6c8a9d20f (diff) | |
download | mpv-32cc190a552551cc7e7150e8603b6a75e0a6d94f.tar.bz2 mpv-32cc190a552551cc7e7150e8603b6a75e0a6d94f.tar.xz |
player: fix display-sync timing if audio take long on resume
In display-sync mode, the very first video frame is idiotically fully
timed, even though audio has not been synced yet at this point, and the
video frame is more like a "preview" frame. But since it's fully timed,
an underflow is detected if audio takes longer than the display time of
the frame (we send the second frame only after audio is done).
The timing code will try to compensate for the determined desync, but it
really shouldn't. So explicitly discard the timing info in this specific
case. On the other hand, if the first frame still hasn't finished
display, we can pretend everything is ok.
This is a hack - ideally, we either would send a frame without timing
info (and then send it again or so when playback starts properly), or we
would add real pause support to the VO, and pause it during syncing.
Diffstat (limited to 'player')
-rw-r--r-- | player/video.c | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/player/video.c b/player/video.c index e3295b623a..9790f34966 100644 --- a/player/video.c +++ b/player/video.c @@ -1209,6 +1209,12 @@ static void handle_display_sync_frame(struct MPContext *mpctx, // Likewise, we know sync is off, but is going to be compensated. time_left += drop_repeat * vsync; + // If syncing took too long, disregard timing of the first frame. + if (mpctx->num_past_frames == 2 && time_left < 0) { + vo_discard_timing_info(vo); + time_left = 0; + } + if (drop_repeat) { mpctx->mistimed_frames_total += 1; MP_STATS(mpctx, "mistimed"); |