|author||wm4 <wm4@nowhere>||2016-09-19 19:58:14 +0200|
|committer||wm4 <wm4@nowhere>||2016-09-19 20:02:53 +0200|
client API: revert some relaxations about calling mpv_initialize()
My original idea was making mpv_initialize() a no-op, but it seems this can't happen after all. The problem is especially with subtle interactions in option parsing (basically all pre-parse options). Instead, I might go into the opposite direction, and add a new API function that takes over the role of mpv_create+mpv_initialize, and which will take a list of options. This list will be for the purpose of setting options that can be set only at initialization time (such as config-dir). This would also make it more uniform with the command- line player initialization. Maybe. In any case, for now revert parts of commit 453fea87 to remove the initialization-related freedoms it added. Fortunately, this wasn't released yet, so we remove it from the API as if it never happened. (The rest of that commit is still fine, just not the additional freedom.)
Diffstat (limited to 'DOCS')
1 files changed, 0 insertions, 2 deletions
diff --git a/DOCS/client-api-changes.rst b/DOCS/client-api-changes.rst
index 36b0d92368..c76881fbd4 100644
@@ -35,8 +35,6 @@ API changes
--- mpv 0.21.0 ---
1.23 - deprecate setting "no-" options via mpv_set_option*(). For example,
instead of "no-video=" you should set "video=no".
- - be much more permissive what API calls are allowed before
- do not override the SIGPIPE signal handler anymore. This was done as
workaround for the FFmpeg TLS code, which has been fixed long ago.
- deprecate mpv_suspend() and mpv_resume(). They will be stubbed out