path: root/libmpv
diff options
authorwm4 <wm4@nowhere>2014-08-14 19:29:21 +0200
committerwm4 <wm4@nowhere>2014-08-14 19:29:21 +0200
commita31330608b0e4e197160b30135bc444232f77e72 (patch)
tree528f03a4c446ccfceab518d891bebe352d0c7bdf /libmpv
parent51a7070e263121652ee39ea8e2d9f530966dd0f0 (diff)
client API: adjust documentation for mpv_suspend()
It's not true anymore that the core will stop replying for 50ms (waiting for video) without calling this function. Simplify the documentation accordingly. Accessing properties that go through the VO still have this problem, though.
Diffstat (limited to 'libmpv')
1 files changed, 5 insertions, 20 deletions
diff --git a/libmpv/client.h b/libmpv/client.h
index 4a653963eb..b9ec85576c 100644
--- a/libmpv/client.h
+++ b/libmpv/client.h
@@ -380,27 +380,14 @@ void mpv_terminate_destroy(mpv_handle *ctx);
int mpv_load_config_file(mpv_handle *ctx, const char *filename);
- * Stop the playback thread. Normally, the client API stops the playback thread
- * automatically in order to process requests. However, the playback thread is
- * restarted again after the request was processed. Then the playback thread
- * will continue to display the next video frame, during which it will not
- * reply to any requests. (This takes up to 50ms.)
- *
- * (Internally, it first renders the video and other things, and then blocks
- * until it can be displayed - and it won't react to anything else in that
- * time. The main reason for that is that the VO is in a "in between" state,
- * in which it can't process normal requests - for example, OSD redrawing or
- * screenshots would be broken.)
- *
- * This is usually a problem: only 1 request per video frame will be executed,
- * which will make the client API to appear extremely slow.
- *
- * Suspending the playback thread allows you to prevent the playback thread from
- * running, so that you can make multiple accesses without being blocked.
+ * Stop the playback thread. This means the core will stop doing anything, and
+ * only run and answer to client API requests. This is sometimes useful; for
+ * example, no new frame will be queued to the video output, so doing requests
+ * which have to wait on the video output can run instantly.
* Suspension is reentrant and recursive for convenience. Any thread can call
* the suspend function multiple times, and the playback thread will remain
- * suspended until the last thread resumes it. Note that during suspension,
+ * suspended until the last thread resumes it. Note that during suspension, all
* clients still have concurrent access to the core, which is serialized through
* a single mutex.
@@ -409,8 +396,6 @@ int mpv_load_config_file(mpv_handle *ctx, const char *filename);
* mpv_suspend() is not allowed.
* Calling this on an uninitialized player (see mpv_create()) will deadlock.
- *
- * Note: the need for this call might go away at some point.
void mpv_suspend(mpv_handle *ctx);