Not sure about this... might redo.
At least this provides a case of a broadcasted event, which requires
per-event data allocation.
See github issue #576.
May or may not be useful in some ways.
We require a context parameter for this just to be sure, even if the
internal implementation currently doesn't.
That's one less mpv internal function for the Lua wrapper.
Also mention that NULL isn't valid. Although I'm not sure whether the
implementation strictly follows this (it should, but there are some
wacky corner cases).
This adds declarations for new formats. The implementation will be added
in the following commits. (It still compiles and runs with this commit,
because it adds constants only.)
The obvious new types are MPV_FORMAT_FLAG, MPV_FORMAT_INT64,
MPV_FORMAT_DOUBLE. MPV_FORMAT_FLAG is a boolean, but to avoid nasty ABI
issues or with languages that don't have a bool data type (C89), it uses
int. Thus the format is not named MPV_FORMAT_BOOL, to avoid confusion.
The MPV_FORMAT_NONE type (mpv_node) is a generic structured type, like a
variant or, say, JSON. It can store strings/bools/numbers, as well as
arrays and key/value pairs (with string keys only).
The MPV_FORMAT_NODE_ARRAY and MPV_FORMAT_NODE_MAP types are used
internally by mpv_node only and can't be used with most of the other API
(like mpv_set_property()) directly.
With mpv_set_property(h, "property", MPV_FORMAT_STRING, ptr), ptr now
has to be of type char** instead of char*. This makes it more consistent
with mpv_get_property() and also non-pointer formats, which will be
introduced in the following commits. mpv_set_property() of course does
not change its interface (only its implementation is adjusted to keep
its interface).
This also affects mpv_set_option(), but again not
mpv_set_option_string().
This is allowed in C99 and C++11, but apparently not in C89 and C++98.
Make it conform to the older standards, since we want the client API
header to be highly portable.
Add a client API, which is intended to be a stable API to get some rough
control over the player. Basically, it reflects what can be done with
input.conf commands or the old slavemode. It will replace the old
slavemode (and enable the implementation of a new slave protocol).