summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-04-08 20:16:53 +0200
committerwm4 <wm4@nowhere>2014-04-17 22:58:48 +0200
commitd06ff691ede6dc9efc33773acbe6b4797147e831 (patch)
tree61b00057c3c6d36cc3a70756f5e362ed03d6a7d1
parent34cee2a77d00d4986cba309d1758d1cfeeb25530 (diff)
downloadmpv-d06ff691ede6dc9efc33773acbe6b4797147e831.tar.bz2
mpv-d06ff691ede6dc9efc33773acbe6b4797147e831.tar.xz
vo_vdpau: add an additional check for timestamp robustness
This might be a good idea in order to prevent queuing a frame too far in the future (causing apparent freezing of the video display), or dropping an infinite number of frames (also apparent as freezing). I think at this point this is most of what we can do if the vdpau time source is unreliable (like with Mesa). There are still inherent race conditions which can't be fixed.
-rw-r--r--video/out/vo_vdpau.c16
1 files changed, 16 insertions, 0 deletions
diff --git a/video/out/vo_vdpau.c b/video/out/vo_vdpau.c
index 13c291e218..d80f5dab48 100644
--- a/video/out/vo_vdpau.c
+++ b/video/out/vo_vdpau.c
@@ -1037,6 +1037,22 @@ static void flip_page_timed(struct vo *vo, int64_t pts_us, int duration)
uint64_t ideal_pts = pts;
uint64_t npts = duration >= 0 ? pts + duration : UINT64_MAX;
+ /* This should normally never happen.
+ * - The last queued frame can't have a PTS that goes more than 50ms in the
+ * future. This is guaranteed by the playloop, which currently actually
+ * roughly queues 50ms ahead, plus the flip queue offset. Just to be sure
+ * give some additional room by doubling the time.
+ * - The last vsync can never be in the future.
+ */
+ int64_t max_pts_ahead = (vo->flip_queue_offset + 0.050) * 2 * 1e9;
+ if (vc->last_queue_time > now + max_pts_ahead ||
+ vc->recent_vsync_time > now)
+ {
+ vc->last_queue_time = 0;
+ vc->recent_vsync_time = 0;
+ MP_WARN(vo, "Inconsistent timing detected.\n");
+ }
+
#define PREV_VSYNC(ts) prev_vsync(vc, ts)
/* We hope to be here at least one vsync before the frame should be shown.