path: root/DOCS
diff options
authorwm4 <wm4@nowhere>2017-01-12 17:37:11 +0100
committerwm4 <wm4@nowhere>2017-01-12 17:45:11 +0100
commit44e06b70d504d5a9073990851a353820370f3667 (patch)
treeffda223303ae592718ae8c2daadfc40b77f37808 /DOCS
parentac98ff71ddf3da7d864f149fc290fa07600b311a (diff)
player: add experimental C plugin interface
This basically reuses the scripting infrastructure. Note that this needs to be explicitly enabled at compilation. For one, enabling export for certain symbols from an executable seems to be quite toolchain-specific. It might not work outside of Linux and cause random problems within Linux. If C plugins actually become commonly used and this approach is starting to turn out as a problem, we can build mpv CLI as a wrapper for libmpv, which would remove the requirement that plugins pick up host symbols. I'm being lazy, so implementation/documentation are parked in existing files, even if that stuff doesn't necessarily belong there. Sue me, or better send patches.
Diffstat (limited to 'DOCS')
1 files changed, 56 insertions, 0 deletions
diff --git a/DOCS/man/libmpv.rst b/DOCS/man/libmpv.rst
index d3e78aa5bc..a85b2ed569 100644
--- a/DOCS/man/libmpv.rst
+++ b/DOCS/man/libmpv.rst
@@ -14,3 +14,59 @@ mpv, further documentation is spread over a few places:
+You can write C plugins for mpv. These use the libmpv API, although they do not
+use the libmpv library itself.
+Currently, they must be explicitlx enabled at build time with
+``--enable-cplugins``. They are available on Linux/BSD platforms only.
+C plugins location
+C plugins are put into the mpv scripts directory in its config directory
+(see the `FILES`_ section for details). They must have a ``.so`` file extension.
+They can also be explicitly loaded with the ``--script`` option.
+A C plugin must export the following function::
+ int mpv_open_cplugin(mpv_handle *handle)
+The plugin function will be called on loading time. This function does not
+return as long as your plugin is loaded (it runs in its own thread). The
+``handle`` will be deallocated as soon as the plugin function returns.
+The return value is interpreted as error status. A value of ``0`` is
+interpreted as success, while any other value signals an error. In the latter
+case, the player prints an uninformative error message that loading failed.
+Within the plugin function, you can call libmpv API functions. The ``handle``
+is created by ``mpv_create_client()`` (or actually an internal equivalent),
+and belongs to you. You can call ``mpv_wait_event()`` to wait for things
+happening, and so on.
+Note that the player might block until your plugin calls ``mpv_wait_event()``
+for the first time. This gives you a chance to install initial hooks etc.
+before playback begins.
+The details are quite similar to Lua scripts.
+Linkage to libmpv
+The current implementation requires that your plugins are **not** linked against
+libmpv. What your plugins uses are not symbols from a libmpv binary, but
+symbols from the mpv host binary.