From 67689ff6b42173b72bffecf23de3507e3ab605b0 Mon Sep 17 00:00:00 2001 From: wm4 Date: Fri, 20 Apr 2018 19:26:04 +0200 Subject: client API: preparations for allowing render API to use DR etc. DR (letting the decoder allocate texture memory) requires running the allocation on the render thread. This is rather hard with the render API, because the user controls this thread and when it's entered. It was not possible until now. This commit adds a bunch of infrastructure to make this possible. We add a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically lets the user's render thread and libmpv agree how this should be done. Misuse would lead to deadlocks. To make this less likely, strictly document thread safety/locking issues. In particular, document which libmpv functions can be called without issues. (The rest has to be assumed unsafe.) The worst issue is destruction of the render context while video is still active. To avoid certain unintended recursive locks (i.e. deadlocks, unless we'd make the locks recursive), make the update callback lock separate. Make "killing" the video chain asynchronous, so we can do extra work while video is being destroyed. Because losing wakeups is a big deal, setting the update callback now triggers a wakeup. (It would have been better if the wakeup callback were a parameter to mpv_render_context_create(), but too late.) This commit does not add DR yet; the following commit does this. --- libmpv/mpv.def | 1 + 1 file changed, 1 insertion(+) (limited to 'libmpv/mpv.def') diff --git a/libmpv/mpv.def b/libmpv/mpv.def index 1d828f4b2b..efbf713622 100644 --- a/libmpv/mpv.def +++ b/libmpv/mpv.def @@ -38,6 +38,7 @@ mpv_render_context_render mpv_render_context_report_swap mpv_render_context_set_parameter mpv_render_context_set_update_callback +mpv_render_context_update mpv_request_event mpv_request_log_messages mpv_resume -- cgit v1.2.3