summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-08-07 14:06:54 +0200
committerwm4 <wm4@nowhere>2016-08-07 14:14:32 +0200
commit32cc190a552551cc7e7150e8603b6a75e0a6d94f (patch)
tree9e79b1ebe3aeb91ea7c2f82bf2797d452c72569a /player/video.c
parent39ae261cc59598426b6e6beea2c849a6c8a9d20f (diff)
downloadmpv-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/video.c')
-rw-r--r--player/video.c6
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");