Return the ID of this client handle. Every client has its own unique ID. This
ID is never reused by the core, even if the mpv_handle at hand gets destroyed
and new handles get allocated.
Same as mpv_command(), but allows passing structured data in any format.
In particular, calling mpv_command() is exactly like calling
mpv_command_node() with the format set to MPV_FORMAT_NODE_ARRAY, and
every arg passed in order as MPV_FORMAT_STRING.
Same as mpv_command, but use input.conf parsing for splitting arguments.
This is slightly simpler, but also more error prone, since arguments may
need quoting/escaping.
Create a new mpv instance and an associated client API handle to control
the mpv instance. This instance is in a pre-initialized state,
and needs to be initialized to be actually used with most other API
functions.
Create a new client handle connected to the same player core as ctx. This
context has its own event queue, its own mpv_request_event() state, its own
mpv_request_log_messages() state, its own set of observed properties, and
its own state for asynchronous operations. Otherwise, everything is shared.
This is the same as mpv_create_client(), but the created mpv_handle is
treated as a weak reference. If all mpv_handles referencing a core are
weak references, the core is automatically destroyed. (This still goes
through normal uninit of course. Effectively, if the last non-weak mpv_handle
is destroyed, then the weak mpv_handles receive MPV_EVENT_SHUTDOWN and are
asked to terminate as well.)
Convert the given src event to a mpv_node, and set *dst to the result. dst
is set to a MPV_FORMAT_NODE_MAP, with fields for corresponding mpv_event and
mpv_event.data/mpv_event_ fields.
General function to deallocate memory returned by some of the API functions.
Call this only if it's explicitly documented as allowed. Calling this on
mpv memory not owned by the caller will lead to undefined behavior.
Frees any data referenced by the node. It doesn't free the node itself.
Call this only if the mpv client API set the node. If you constructed the
node yourself (manually), you have to free it yourself.
Get a property asynchronously. You will receive the result of the operation
as well as the property data with the MPV_EVENT_GET_PROPERTY_REPLY event.
You should check the mpv_event.error field on the reply event.
Return a UNIX file descriptor referring to the read end of a pipe. This
pipe can be used to wake up a poll() based processing loop. The purpose of
this function is very similar to mpv_set_wakeup_callback(), and provides
a primitive mechanism to handle coordinating a foreign event loop and the
libmpv event loop. The pipe is non-blocking. It's closed when the mpv_handle
is destroyed. This function always returns the same value (on success).
A hook is like a synchronous event that blocks the player. You register
a hook handler with this function. You will get an event, which you need
to handle, and once things are ready, you can let the player continue with
mpv_hook_continue().
Get a notification whenever the given property changes. You will receive
updates as MPV_EVENT_PROPERTY_CHANGE. Note that this is not very precise:
for some properties, it may not send updates even if the property changed.
This depends on the property, and it's a valid feature request to ask for
better update handling of a specific property. (For some properties, like
clock, which shows the wall clock, this mechanism doesn't make too
much sense anyway.)
Enable or disable receiving of log messages. These are the messages the
command line player prints to the terminal. This call sets the minimum
required log level for a message to be received with MPV_EVENT_LOG_MESSAGE.
Set an option. Note that you can't normally set options during runtime. It
works in uninitialized state (see mpv_create()), and in some cases in at
runtime.
Set a property to a given value. Properties are essentially variables which
can be queried or set at runtime. For example, writing to the pause property
will actually pause or unpause playback.
Set a property asynchronously. You will receive the result of the operation
as MPV_EVENT_SET_PROPERTY_REPLY event. The mpv_event.error field will contain
the result status of the operation. Otherwise, this function is similar to
mpv_set_property().
Set a custom function that should be called when there are new events. Use
this if blocking in mpv_wait_event() to wait for new events is not feasible.
Similar to mpv_destroy(), but brings the player and all clients down
as well, and waits until all of them are destroyed. This function blocks. The
advantage over mpv_destroy() is that while mpv_destroy() merely
detaches the client handle from the player, this function quits the player,
waits until all other clients are destroyed (i.e. all mpv_handles are
detached), and also waits for the final termination of the player.
Block until all asynchronous requests are done. This affects functions like
mpv_command_async(), which return immediately and return their result as
events.
Wait for the next event, or until the timeout expires, or if another thread
makes a call to mpv_wakeup(). Passing 0 as timeout will never wait, and
is suitable for polling.
Interrupt the current mpv_wait_event() call. This will wake up the thread
currently waiting in mpv_wait_event(). If no thread is waiting, the next
mpv_wait_event() call will return immediately (this is to avoid lost
wakeups).
