summaryrefslogtreecommitdiffstats
path: root/libmpv
Commit message (Collapse)AuthorAgeFilesLines
* client API: add mpv_get_wakeup_pipe convenience functionwm42014-04-121-1/+32
| | | | Should make integreating with some event loops easier. Untested.
* client API: include the reason in MPV_EVENT_END_FILEwm42014-04-111-0/+14
| | | | | | | | | 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 API: remove outdated commentswm42014-04-111-3/+3
|
* client API: improve commentswm42014-04-101-25/+31
|
* client API: avoid redundant property change events if possiblewm42014-04-081-0/+4
| | | | | 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-2/+59
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* libmpv: add pkg-config fileAlessandro Ghedini2014-03-111-0/+11
|
* client APIs: fix some typosxylosper2014-02-281-1/+1
|
* client API: rename MPV_EVENT_PLAYBACK_START, add MPV_EVENT_SEEKwm42014-02-281-2/+14
| | | | | | Rename MPV_EVENT_PLAYBACK_START to MPV_EVENT_FILE_LOADED. Add MPV_EVENT_SEEK and MPV_EVENT_PLAYBACK_RESTART.
* options: allow changing options at runtimewm42014-02-251-5/+8
| | | | | Allow changing all options at runtime, except some cherry-picked options, which are disabled with M_OPT_FIXED.
* client API: change description of format conversionswm42014-02-251-6/+10
| | | | | | | This changed during the time between writing the comment, and finishing up the implementation. Although I'm still unsure about this.
* client API: report pause/unpause reasonwm42014-02-241-0/+28
| | | | | | | | | 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/+12
| | | | | | | | | 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: add comment about character encoding issueswm42014-02-241-0/+10
| | | | | | 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).
* client API: add more data formats, add a structured data typewm42014-02-241-3/+156
| | | | | | | | | | | | | | | | | | | 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.
* client API: change semantics for MPV_FORMAT_STRINGwm42014-02-241-2/+14
| | | | | | | | | | | | 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: fix a typowm42014-02-241-1/+1
|
* client API: remove trailing "," from enumswm42014-02-241-3/+3
| | | | | | | 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.
* client API: spellingwm42014-02-241-1/+1
|
* client API: add event for metadata changeswm42014-02-191-0/+6
|
* client API: add events for video and audio reconfigwm42014-02-171-0/+16
|
* client API: add a client message eventwm42014-02-171-0/+19
| | | | | This comes with a "script_message" input command, which sends these messages. Used by the following commits.
* client API: fix description of mpv_event.error fieldwm42014-02-121-4/+7
| | | | The description was a left over from an earlier iteration of the API.
* Add a client APIwm42014-02-101-0/+809
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-24 03:23:58 +0000