vo_opengl_cb: simplify API uninitialization

Until now, calling mpv_opengl_cb_uninit_gl() at a "bad moment" could
make the whole thing to explode. The API user was asked to avoid such
situations by calling it only in "good moments". But this was probably a
bit too subtle and could easily be overlooked.

Integrate the approach the qml example uses directly into the
implementation. If the OpenGL context is to be unitialized, forcefully
disable video, and block until this is done.

1 files changed, 13 insertions, 4 deletions

diff --git a/libmpv/opengl_cb.h b/libmpv/opengl_cb.h
index 3f5010b26e..8f7e1df76d 100644
--- a/libmpv/opengl_cb.h
+++ b/libmpv/opengl_cb.h
@@ -96,6 +96,17 @@ extern "C" {
  *    as used with mpv_opengl_cb_init_gl()
  *  - never can be called from within the callbacks set with
  *    mpv_set_wakeup_callback() or mpv_opengl_cb_set_update_callback()
+ *
+ * Context and handle lifecycle
+ * ----------------------------
+ *
+ * Video initialization will fail if the OpenGL context was not initialized yet
+ * (with mpv_opengl_cb_init_gl()). Likewise, mpv_opengl_cb_uninit_gl() will
+ * disable video.
+ *
+ * When the mpv core is destroyed (e.g. via mpv_terminate_destroy()), the OpenGL
+ * context must have been uninitialized. If this doesn't happen, undefined
+ * behavior will result.
  */
 
 /**
@@ -181,10 +192,8 @@ int mpv_opengl_cb_render(mpv_opengl_cb_context *ctx, int fbo, int vp[4]);
 /**
  * Destroy the mpv OpenGL state.
  *
- * This will trigger undefined behavior (i.e. crash hard) if the hardware
- * decoder is still active, because the OpenGL hardware decoding interop state
- * can't be destroyed synchronously. If no hardware decoding is active, the
- * state can be destroyed at any time.
+ * If video is still active (e.g. a file playing), video will be disabled
+ * forcefully.
  *
  * Calling this multiple times is ok.
  *