summaryrefslogtreecommitdiffstats
path: root/player/client.c
Commit message (Collapse)AuthorAgeFilesLines
* client API: remove mpv_event_pause_reasonwm42014-04-141-4/+0
| | | | | | | | | And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE. The real pause state can now be queried with the "core-idle" property, the user pause state with the "pause" property, whether the player is paused due to cache with "paused-for-cache", and the keep open event can be guessed with the "eof-reached" property.
* client API: add mpv_get_wakeup_pipe convenience functionwm42014-04-121-0/+32
| | | | Should make integreating with some event loops easier. Untested.
* client API: include the reason in MPV_EVENT_END_FILEwm42014-04-111-0/+3
| | | | | | | | | Otherwise, the client API user could not know why playback was stopped. Regarding the fact that 0 is used both for normal EOF and EOF on error: this is because mplayer traditionally did not distinguish these, and in general it's hard to tell the real reason. (There are various weird corner cases which make it hard.)
* client: change equality rules for MPV_FORMAT_NONEwm42014-04-091-1/+1
|
* client: add a commentwm42014-04-091-0/+2
|
* client API: avoid redundant property change events if possiblewm42014-04-081-5/+50
| | | | | This is done simply by comparing the previous and current values. Do this only if the requested format is not MPV_FORMAT_NONE.
* client API: add a way to notify clients of property changeswm42014-04-061-1/+213
| | | | | | | | | | | | | | | | | | | | | | | | This turned out ridiculously complex. I think it will have to be simplified some day. Main reason for the complexity are: - filtering properties by forcing clients to observe individual properties explicitly (to avoid spamming clients with changes they don't want) - optional retrieval of property value with the notification (the basic idea was that this is more user friendly) - allowing to the client to specify a format in which the value should be retrieved (because if a property changes its type, the client API couldn't convert it properly, and compatibility would break) I don't know yet which of these are important, and everything could change. In particular, the interface and semantics should be adjusted to reduce the implementation complexity. While I consider the API complete, there could (and probably will) be bugs left. Also while the implementation is complete, it's inefficient. The complexity of the property matching is O(a*b*c) with a clients, b observed properties, and c properties changing at once. I threw away an earlier implementation using bitmasks, because it was too unwieldy.
* client API: use a manual ringbufferwm42014-04-061-31/+31
| | | | | | | Remove the use of mp_ring and use a simple array and a bunch of variables instead. This is way less awkwad. The change in reserve_reply fixes incorrect tracking of free events.
* command, lua: change script_message semanticswm42014-03-171-0/+12
| | | | | | | | Change script_message to broadcast the message to all clients. Add a new script_message_to command, which does what the old script_message command did. This is intended as simplification, although it might lead to chaos too.
* client API: fix timeout handlingwm42014-03-011-1/+4
| | | | | | (Again.) Fixed Lua timers as well.
* client API: rename MPV_EVENT_PLAYBACK_START, add MPV_EVENT_SEEKwm42014-02-281-1/+3
| | | | | | Rename MPV_EVENT_PLAYBACK_START to MPV_EVENT_FILE_LOADED. Add MPV_EVENT_SEEK and MPV_EVENT_PLAYBACK_RESTART.
* client API: wait for remaining asynchronous requests before terminatingwm42014-02-281-0/+9
| | | | | | Sending an asynchronous request and then calling mpv_destroy() would crash the player when trying to send the reply to the removed client. Fix this by waiting until all remaining replies have been sent.
* client API: don't explode when destroying uninitialized mpv_handlewm42014-02-261-1/+2
|
* client API: accept NULL as mpv_destroy() argumentwm42014-02-261-0/+3
|
* client API: treat MPV_FORMAT_STRING differently in mpv_set_propertywm42014-02-261-19/+20
| | | | | | | | | | | | | | Always map MPV_FORMAT_STRING to setting property value directly through M_PROPERTY_SET_STRING, instead of trying to go through M_PROPERTY_SET_NODE. This treats a direct MPV_FORMAT_STRING query differently from a MPV_FORMAT_STRING wrapped in a mpv_node. This was already the case in mpv_get_property(). The reason for all this is that mpv_node is supposed to be the exact type, while a direct MPV_FORMAT_STRING goes through all possible conversions. Not sure if these semantics are good.
* client API: fix broken property/option functionsxylosper2014-02-261-3/+4
| | | | | | | | | | | | | | | | | | 1. Cannot set option after initialized: it seems that this bug has existed since libmpv was introduced first. Maybe just a typo. 2. Crash when setting property with native format: mpv_set_property just causes a crash when using a native format. I found an invalid casting and fixed it. 3. Wrong error value for mpv_get_property: when an error occurred, mpv_get_property always returns wrong format error because every error for property except M_PROPERTY_NOT_IMPLEMENTED is just ignored. Signed-off-by: wm4 <wm4@nowhere> Closes pull request #593. Does not incldue the first fix, which was not correct. The underlying bug will be fixed by a later commit. Commit message extracted from pull request and slightly edited.
* client API: report pause/unpause reasonwm42014-02-241-8/+22
| | | | | | | | | 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.
* client API: expose the internal clockwm42014-02-241-0/+6
| | | | | | | | | 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.
* client API: implement setting options using their native type toowm42014-02-241-4/+13
| | | | | | | | | | | This is only half-implemented: actually the option will first be converted from mpv_node to its native type, then it's converted to a string, and then back to its native type. This is because the option API was made for strings and not anything else. Other than being grossly inelegant, the only downside is probably with string lists and key/value lists, which don't escape strings containing syntax elements correctly.
* client API: add support for accessing properties by their native typewm42014-02-241-33/+158
| | | | | | | | | | | | | | This actually makes use of the client.h declarations and the mpv_node mechanisms added some commits ago. For now, using MPV_FORMAT_STRING will usually fallback to explicit string conversion, but not in the other cases. E.g. reading a numeric property as string will work, but not reading a string property as number. Other than that, only MPV_FORMAT_INT64->MPV_FORMAT_DOUBLE does an automatic conversion. I'm not sure whether these semantics and API are good, so comments and suggestions are welcome.
* client API: adjust error stringswm42014-02-241-2/+2
| | | | | These error codes can be used for setting and getting, not just for settings (although currently there's no API to get options directly).
* client API: change semantics for MPV_FORMAT_STRINGwm42014-02-241-5/+5
| | | | | | | | | | | | 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().
* client API: add event for metadata changeswm42014-02-191-0/+1
|
* client API: add events for video and audio reconfigwm42014-02-171-0/+2
|
* client API: add a client message eventwm42014-02-171-0/+1
| | | | | This comes with a "script_message" input command, which sends these messages. Used by the following commits.
* Add a client APIwm42014-02-101-0/+856
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).
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 18:33:31 +0000