diff options
author | wm4 <wm4@nowhere> | 2018-08-31 16:33:15 +0200 |
---|---|---|
committer | Anton Kindestam <antonki@kth.se> | 2018-12-06 10:30:14 +0100 |
commit | 83884fdf03fc991679bea53d3d5bddf97ed16a9b (patch) | |
tree | 84248a21d9a50185dcc51bfb79077f84bdd0e96c /video/out/gpu | |
parent | 8b83c8996686072bc743b112ae5cb3bf93aa33ed (diff) | |
download | mpv-83884fdf03fc991679bea53d3d5bddf97ed16a9b.tar.bz2 mpv-83884fdf03fc991679bea53d3d5bddf97ed16a9b.tar.xz |
vo_gpu: glx: use GLX_OML_sync_control for better vsync reporting
Use the extension to compute the (hopefully correct) video delay and
vsync phase.
This is very fuzzy, because the latency will suddenly be applied after
some frames have already been shown. This means there _will_ be "jumps"
in the time accounting, which can lead to strange effects at start of
playback (such as making initial "dropped" etc. frames worse). The only
reasonable way to fix this would be running a few dummy frame swaps at
start of playback until the latency is known. The same happens when
unpausing.
This only affects display-sync mode.
Correct function was not confirmed. It only "looks right". I don't have
the equipment to make scientifically correct measurements.
A potentially bad thing is that we trust the timestamps we're receiving.
Out of bounds timestamps could wreak havoc. On the other hand, this will
probably cause the higher level code to panic and just disable DS.
As a further caveat, this makes a bunch of assumptions about UST
timestamps. If there are delayed frames (i.e. we skipped one or more
vsyncs), the latency logic is mostly reset. There is no attempt to make
the vo.c skipped vsync logic to use this. Also, the latency computation
determines a vsync duration, and there's no effort to reconcile or share
the vo.c logic for determining vsync duration.
Diffstat (limited to 'video/out/gpu')
-rw-r--r-- | video/out/gpu/context.h | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/video/out/gpu/context.h b/video/out/gpu/context.h index a2fcb3711a..b6b6ffcf43 100644 --- a/video/out/gpu/context.h +++ b/video/out/gpu/context.h @@ -83,6 +83,15 @@ struct ra_swapchain_fns { // Performs a buffer swap. This blocks for as long as necessary to meet // params.swapchain_depth, or until the next vblank (for vsynced contexts) void (*swap_buffers)(struct ra_swapchain *sw); + + // Return the latency at which swap_buffers() is performed. This is in + // seconds and always >= 0. Essentially, it's the predicted time the last + // shown frame will take until it is actually displayed on the physical + // screen. (A reasonable implementation is returning the duration the + // last actually displayed frame took after its swap_buffers() was called.) + // Should return -1 on error (e.g. discontinuities). + // Can be NULL 0 or always return -1 if unsupported. + double (*get_latency)(struct ra_swapchain *sw); }; // Create and destroy a ra_ctx. This also takes care of creating and destroying |