From 2c572e2bb1cfa4e225a6a1599f5ecdbcf4bf2dc6 Mon Sep 17 00:00:00 2001 From: wm4 Date: Tue, 13 Mar 2018 11:23:23 +0100 Subject: video: add an option to tune waiting for video timing Probably mostly useful for the libmpv render API. --- DOCS/man/options.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'DOCS') diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index 8713cf7244..16e4998453 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -5410,6 +5410,26 @@ Miscellaneous out. This delay in reaction time to sudden A/V offsets should be the only side effect of turning this option on, for all sound drivers. +``--video-timing-offset=`` + Control how long before video display target time the frame should be + rendered (default: 0.050). If a video frame should be displayed at a + certain time, the VO will start rendering the frame earlier, and then will + perform a blocking wait until the display time, and only then "swap" the + frame to display. The rendering cannot start before the previous frame is + displayed, so this value is implicitly limited by the video framerate. With + normal video frame rates, the default value will ensure that rendering is + always immediately started after the previous frame was displayed. On the + other hand, setting a too high value can reduce responsiveness with low + FPS value. + + For client API users using the render API (or the deprecated ``opengl-cb`` + API), this option is interesting, because you can stop the render API + from limiting your FPS (see ``mpv_render_context_render()`` documentation). + + This applies only to audio timing modes (e.g. ``--video-sync=audio``). In + other modes (``--video-sync=display-...``), video timing relies on vsync + blocking, and this option is not used. + ``--video-sync=`` How the player synchronizes audio and video. -- cgit v1.2.3