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 /video/out/vo.h | |
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 'video/out/vo.h')
-rw-r--r-- | video/out/vo.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/video/out/vo.h b/video/out/vo.h index 511954c153..a5280e5611 100644 --- a/video/out/vo.h +++ b/video/out/vo.h @@ -366,6 +366,7 @@ double vo_get_estimated_vsync_interval(struct vo *vo); double vo_get_estimated_vsync_jitter(struct vo *vo); double vo_get_display_fps(struct vo *vo); double vo_get_delay(struct vo *vo); +void vo_discard_timing_info(struct vo *vo); void vo_wakeup(struct vo *vo); void vo_wait_default(struct vo *vo, int64_t until_time); |