mpv/libmpv
wm4 67689ff6b4 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.
2018-04-29 02:21:32 +03:00
..
client.h client API: preparations for allowing render API to use DR etc. 2018-04-29 02:21:32 +03:00
mpv.def client API: preparations for allowing render API to use DR etc. 2018-04-29 02:21:32 +03:00
mpv.pc.in
opengl_cb.h client API: add a new way to pass X11 Display etc. to render API 2018-03-26 19:47:08 +02:00
qthelper.hpp client API: deprecate qthelper.hpp 2018-03-15 23:13:53 -07:00
render.h client API: preparations for allowing render API to use DR etc. 2018-04-29 02:21:32 +03:00
render_gl.h client API: add a new way to pass X11 Display etc. to render API 2018-03-26 19:47:08 +02:00
stream_cb.h