summaryrefslogtreecommitdiffstats
path: root/player/client.c
Commit message (Collapse)AuthorAgeFilesLines
* client API: directly lock playloopwm42014-08-141-4/+3
| | | | | | | | Until recently, vo_opengl could be accessed from a single thread only, due to the OpenGL API context being thread-specific. This issue doesn't exist anymore, because VOs run on their own thread. This means we can simply lock/unlock the playloop instead of doing something complicated to get the playloop thread to execute our code.
* client API: minor optimizations for property notificationwm42014-08-021-32/+44
| | | | | | | | | | | | | | | | | | | | | Internally, there are two mechanisms which can trigger property notification as used with "observed" properties in the client API. The first mechanism associates events with a group of properties that are potentially changed by a certain event. mp_event_property_change[] declares these associations, and maps each event to a set of strings. When an event happens, the set of strings is matched against the list of observed properties of each client. Make this more efficient by comparing bitsets of events instead. This way, only a bit-wise "and" is needed for each observed property. Even better, we can completely skip clients which have no observed properties that match. The second mechanism just updates individual properties explicitly by name. Optimize this by using the property index instead. It would be nice if we could reuse the first mechanism for the second one, but there are too many properties to fit into a 64 bit mask. (Though the limit on 64 events might get us into trouble later...)
* client API: fix deadlock when calling mpv_terminate_destroy before initwm42014-07-311-1/+1
| | | | | | | | | | This is perfectly allowed, but was ignored, because it's a corner case. It doesn't actually wait for other clients to be destroyed, but on the other hand I think there's no way to have other clients before initialization. CC: @mpv-player/stable
* audio, client API: check mp_make_wakeup_pipe() return valuewm42014-07-251-3/+4
| | | | Could fail e.g. due to FD exhaustion.
* client API: allow calling mpv_terminate_destroy(NULL)wm42014-07-041-0/+3
| | | | | | This is an oversight and a bug. CC: @mpv-player/stable
* Add more constwm42014-06-111-3/+3
| | | | | | | While I'm not very fond of "const", it's important for declarations (it decides whether a symbol is emitted in a read-only or read/write section). Fix all these cases, so we have writeable global data only when we really need.
* client API: disable LIRC input by defaultwm42014-06-091-0/+1
| | | | | | Not only should using libmpv hog such global resources; it's also very unlikely an application embedding mpv will ever want to make use of this.
* client API: minor documentation fixes/enhancementswm42014-06-081-2/+2
|
* client API: trigger wakeup when creating wakeup pipe/callbackwm42014-06-081-1/+5
| | | | | | | | | Since redundant wakeups are avoided now, it's easy to miss a wakeup when creating/setting the pipe/callback after the client API was signalled. If the client API is signalled, need_wakeup is set to true, and wakeup_client skips writing to the pipe or calling the client API. That this can happen is not very obvious to the client API, so trigger a wakeup right on start in order to remove this special case.
* client API: restructure waiting, do log msg wakeup properlywm42014-06-071-42/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | Until now, availability of new log messages (through the mechanism associated with mpv_request_log_messages()) did not wakeup the client API properly. Commit 3b7402b5 was basically a hack to improve that somewhat, but it wasn't a solution. The main problem is that the client API itself is producing messages, so the message callback would attempt to lock the client API lock, resulting in a deadlock. Even if the lock was recursive, we'd run into lock-order issues. Solve this by using a separate lock for waiting and wakeup. Also, since it's a natural addition, avoid redundant wakeups. This means the wakeup callback as well as the wakeup pipe will be triggered only once until the next mpv_wait_event() call happens. This might make the wakeup callback be invoked in a reentrant way for the first time, for example if a mpv_* function prints to a log. Adjust the docs accordingly. (Note that non-reentrant beheavior was never guaranteed - basically the wakeup callback is somewhat dangerous and inconvenient.) Also remove some traces of unneeded code. ctx->shutdown for one was never set, and probably a leftover of an abandoned idea.
* client API: rename mpv_destroy() to mpv_detach_destroy()wm42014-06-071-4/+3
| | | | | | A bit verbose, but less misleading. In most cases, the API user probably actually wants mpv_terminate_destroy() instead, so the less-useful function shouldn't have a simnpler name anyway.
* client API: add API function that ensures total destructionwm42014-06-071-2/+32
| | | | | | | | | | | | mpv_destroy() should perhaps better be called mpv_detach(), because it destroys only the handle, not necessarily the player. The player is only terminated if a quit command is sent. This function quits automatically, and additionally waits until the player is completely destroyed. It removes the possibility that the player core is still uninitializing, while all client handles are already destroyed. (Although in practice, the difference is usually not important.)
* client API: change mpv_wait_event() timeout semanticswm42014-06-071-1/+4
| | | | | | | | | Now a negative timeout mean an infinite timeout. This is similar to the poll() system call. Apparently this is more intuitive and less confusing than specifying a "very high" value as timeout if you want to wait forever. For callers that never pass negative timeouts, nothing changes.
* client API: enlarge the message buffer if log level is highwm42014-06-061-1/+2
|
* client API: call wakeup callback if there are new messageswm42014-06-061-13/+17
| | | | | | | | | | | | | | | | | | Listening on messages currently uses polling (every time mpv_wait_event() has no new events, the message buffer is polled and a message event is possibly created). Improve this situation a bit, and call the user-supplied wakeup callback. This will increase the frequency with which the wakeup callback is called, but the client is already supposed to be able to deal with this situation. Also, as before, calling mpv_wait_event() from the wakeup callback is forbidden, so the client can't read new messages from the callback directly. The wakeup pipe is written either. Since the wakeup pipe is created lazily, we can't access the pipe handle without creating a race condition or a deadlock. (This is actually very silly, since in practice the race condition won't matter, but for now let's keep it clean.)
* client API: don't update properties in uninitialized statewm42014-06-061-0/+2
| | | | | | If an API user calls mpv_wait_event() and mpv_observe_property() before mpv_initialize(), it could happen that a property was accessed before initialization, which is not ok.
* client API: don't use the mpv config files by defaultwm42014-06-061-0/+1
| | | | | | | | | This was always intended this way, and even documented in client.h. Due to an oversight it was never actually implemented. The intention is that mpv embedded in applications and "real mpv" don't conflict. An API user can undo this by setting the "config" option to "yes", if using the user's mpv config is desired.
* client API: use shared code for creating the wakeup pipewm42014-06-061-12/+2
| | | | Should be equivalent, reduces code duplication.
* client API: fix swapped pipe ends used with mpv_set_wakeup_callbackwm42014-06-061-2/+2
| | | | | This was extremely wrong. It was never tested because nobody ever used it (the feature was added for someone who never tried it in the end).
* client API: report success status when running commandswm42014-06-011-2/+3
| | | | | | Until now, an error was reported only if the command couldn't be parsed. Attempt to do more fine-grained reporting. This is not necessarily perfect, but it's an improvement.
* client API: fix mpv_observe_property with MP_FORMAT_NONEwm42014-05-241-2/+3
| | | | | It returned only 1 change event (after registration), and then went silent. This was accidentally broken some time ago.
* client API: add mpv_load_config_file()wm42014-05-181-0/+15
| | | | | | | This is probably a good idea, because it would make it easier for software embedding mpv to configure the mpv parts, without requiring the host program to provide explicit mechanisms for this (other than calling mpv_load_config_file()).
* options: unify code for setting string and "raw" optionswm42014-05-181-41/+39
| | | | | | | | | The code paths for setting options by string and by direct "raw" value were too different, which resulted in some weird code. Make the code paths closer to each other. Also, use this to remove the weirdness in the mpv_set_option() implementation.
* threads: use mpv time for mpthread_cond_timedwait wrapperwm42014-05-181-2/+2
| | | | | | Use the time as returned by mp_time_us() for mpthread_cond_timedwait(), instead of calculating the struct timespec value based on a timeout. This (probably) makes it easier to wait for a specific deadline.
* client API: fix "missed" property notificationswm42014-05-181-19/+25
| | | | | | | | | | | | | | | | | | If a property is notified as changed, and then again (before the change notification is returned to the client), and the second change is a sporadic change (i.e. nothing actually changed) and the change notification was associated with with a data type, it could happen that a change was "overlooked", because it would detect no change on the second notification. This is actually a pretty annoying corner case, due to the annoying way we do things, so just store both the previously returned _and_ the newly obtained property value. then we always compare with the user value to check for a change, excluding any possibility of a missed change. Note that we don't (can't/shouldn't) care if a value changes, and then changes back; it's fine if that doesn't generate a notification. This is due to how property notifications are supposed to be coalesced.
* player: reorganize how lua scripts are loadedwm42014-05-131-0/+5
| | | | | | Make loading of scripts independent of Lua. Move some of the loading code from lua.c to scripting.c, and make it easier to add new scripting backends.
* client API: fix inverted conditionwm42014-05-021-1/+1
| | | | Oops. Sigh.
* client API: add chapter change eventwm42014-04-271-0/+1
| | | | Also works for mpv_observe_property() on the "chapter" property.
* dispatch: move into its own source filewm42014-04-231-0/+1
| | | | | | | This was part of osdep/threads.c out of laziness. But it doesn't contain anything OS dependent. Note that the rest of threads.c actually isn't all that OS dependent either (just some minor ifdeffery to work around the lack of clock_gettime() on OSX).
* client API: make mpv_set_option set options nativelywm42014-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This should fix some issues, such as not being able to set the "no-video" option with MPV_FORMAT_FLAG. Note that this changes semantics a bit. Now setting an option strictly overwrite it, even if the corresponding command line option does not. For example, if we change --sub to append by default, then setting the "sub" option via the client API would still never append. (Oddly, this also applies to --vf-add, which will overwrite the old value when using the client API.) I'm doing this because there's no proper separation between the command line parser and setting an option using the MPV_FORMAT_STRING format. Maybe the solution to this mess would be adding format aware code (i.e. m_option_set_node) to every option type, and falling back to strings only if needed - but this would mean that you couldn't set e.g. an integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal either. In conclusion, the current approach seems to be most robust, but I'm open to suggestions should someone find that these semantics are a problem.
* 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-30 21:37:55 +0000