summaryrefslogtreecommitdiffstats
path: root/libmpv
Commit message (Collapse)AuthorAgeFilesLines
* client API: qthelper: remove commented codewm42014-10-141-2/+0
| | | | This is already taken care of by Q_DISABLE_COPY().
* client API: qthelper: fix bugswm42014-10-141-1/+3
| | | | Pretty dumb oversights.
* client API: add qthelper.hppwm42014-10-132-1/+235
| | | | | | | | | | | | | | This provides some helper functions and classes for C++/Qt. As the top of qthelper.hpp says, this is built on top of the client API, and is a mere helper provided for convenience. Maybe this should be a separate library, but on the other hand I don't see much of a point in that. It's also header-only, but C++ people like such things. This makes it easier for us, because we don't need to care about ABI compatibility. The client API doesn't change, but bump it so that those who are using this header can declare a proper dependency.
* libmpv/mpv.def: add mpv_command_node[_async]James Ross-Gowan2014-10-121-0/+2
|
* client API: add mpv_command_node[_async]wm42014-10-111-3/+43
| | | | | | | | | Allows passing native types as arguments. Also some minor doc improvements, including giving some (natural) improvements to mpv_free_node_contents(). Note: mpv_command_node_async() is completely untested.
* client API: introduce numeric log levelswm42014-10-081-1/+24
| | | | | | | | | | | | | | | | Maybe using strings for log levels was a mistake (too broad and too impractical), so I'm adding numeric log level at least for the receiver side. This makes it easier to map mpv log levels to other logging systems. I'm still too stingy to add a function to set the log level by a numeric value, though. The numeric values are not directly mapped to the internal mpv values, because then almost every file in mpv would have to include the client API header. Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
* msg, client API: buffer partial lineswm42014-10-081-7/+3
| | | | | | | | | | | | | | | The API could return partial lines, meaning the message could stop in the middle of a line, and the next message would have the rest of it (or just the next part of it). This was a pain for the user, so do the nasty task of buffering the lines ourselves. Now only complete lines are sent. To make things even easier for the API user, don't put multiple lines into a single event, but split them. The terminal output code needed something similar (inserting a prefix header on start of each line). To avoid code duplication, this commit refactors the terminal output so that lines are split in a single place.
* msg: set an explicit overflow messagewm42014-10-081-1/+4
| | | | | | | | So client API users don't have to worry about this specifically. Also document the overflow case. (Not sure if we really need to do this; maybe it'd be better not to, since this just adds more noise to the docs.)
* client API: improve mpv_observe_property docswm42014-10-071-11/+18
| | | | | | | Document the "normal" behavior (if MPV_FORMAT_NONE is not used) first, and then introduce MPV_FORMAT_NONE as exception. The actual semantics didn't change in mpv; this is only clarification.
* client API: clarify pause/unpause events, modify core-idle propertywm42014-10-071-5/+16
| | | | | | | | Whether you consider the semantics weird or not depends on your use case, but I suppose it's a bit confusing anyway. At this point, we keep MPV_EVENT_PAUSE/UNPAUSE for compatibility only. Make the "core-idle" property somewhat more useful in this context.
* client API, X11: change default keyboard input handling againwm42014-09-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 64b7811c tried to do the "right thing" with respect to whether keyboard input should be enabled or not. It turns out that X11 does something stupid by design. All modern toolkits work around this native X11 behavior, but embedding breaks these workarounds. The only way to handle this correctly is the XEmbed protocol. It needs to be supported by the toolkit, and probably also some mpv support. But Qt has inconsistent support for it. In Qt 4, a X11 specific embedding widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently supports it via QWindow, but if it really does, I couldn't get it to work. So add a hack instead. The new --input-x11-keyboard option controls whether mpv should enable keyboard input on the X11 window or not. In the command line player, it's enabled by default, but in libmpv it's disabled. This hack has the same problem as all previous embedding had: move the mouse outside of the window, and you don't get keyboard input anymore. Likewise, mpv will steal all keyboard input from the parent application as long as the mouse is inside of the mpv window. Also see issue #1090.
* x11: when using --wid, inherit event flags from parent windowwm42014-08-311-1/+1
| | | | | | | | | | | | | | | | | | | When embedding a X window, it's hard to control whether it receives mouse/keyboard input or not. It seems the X protocol itself makes this hard (basically due to the outdated design mismatching with modern toolkits), and we have to take care of these things explicitly. Simply do this by manually querying and using the parent window event flags. This restores some MPlayer behavior (it doesn't add back exactly the same code, but it's very similar). This probably has some potential to interfere with libmpv embedding, so bump the client API minor. CC: @mpv-player/stable (if applied, client-api-changes.rst has to be adjusted to include the 0.5.2 release)
* client API: adjust documentation for mpv_suspend()wm42014-08-141-20/+5
| | | | | | | It's not true anymore that the core will stop replying for 50ms (waiting for video) without calling this function. Simplify the documentation accordingly. Accessing properties that go through the VO still have this problem, though.
* build: add hacks to force waf to generate valid .pc fileswm42014-08-071-0/+1
| | | | Don't like this? You're invited to fix this crap.
* build: move def file to libmpv/wm42014-08-051-0/+34
| | | | This is more consistent with mpv.pc, which is also in libmpv/.
* client API: add and use the MPV_MAKE_VERSION macrowm42014-08-051-5/+4
| | | | | | | This is probably nicer. The actual version number doesn't change (other than the minor being incremented). The "| 0UL" is to make the type unsigned long int, like it was before.
* player: some further playloop cleanupswm42014-08-031-2/+4
| | | | | | | | | | | | | Handle --term-playing-msg at a better place. Move MPV_EVENT_TICK hack into a separate function. Also add some words to the client API that you shouldn't use it. (But better leave breaking it for later.) Handle --frames and frame_step differently. Remove the mess from the playloop, and do it after frame display. Give up on the weird semantics for audio-only mode (they didn't make sense anyway), and adjust the manpage accordingly.
* client API: make "cache" property and similar observablewm42014-07-311-0/+1
| | | | | | Achieve this by polling. Will be used by the OSC. Basically a bad hack - but the point is that the mpv core itself is in the best position to improve this later.
* client API: fix typos in documentationwm42014-07-301-2/+2
|
* Remove stream_pts stuffwm42014-07-061-1/+1
| | | | | This was used by DVD/BD, but its usage was removed with one of the previous commits.
* DOCS: add a file listing API changes for the client APIwm42014-07-031-2/+25
|
* client API: declare as stablewm42014-06-201-10/+6
| | | | | | | | It is reasonably stable, so all further changes will be versioned. Also change how the libmpv version number is generated. Fix the patch version number to 0; I don't think we have a use for this. In particular, the version doesn't version mpv, just the client API.
* client API: minor documentation fixes/enhancementswm42014-06-081-2/+4
|
* client API: restructure waiting, do log msg wakeup properlywm42014-06-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-16/+16
| | | | | | 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: clarify mpv_get_wakeup_pipe docswm42014-06-071-13/+43
| | | | | | | | | | | It wasn't necessarily clear how this works. Especially make clear that the API user shouldn't expect that there's one byte per readable event in the wakeup pipe. Actually, the reason why this currently won't work is because property notifications can generate more events than wakeups. The limit of 4096 is a more fundamental issue, but the event ringbuffer is currently limited to 1000 entries anyway. Also add some important comments to mpv_set_wakeup_callback.
* client API: add API function that ensures total destructionwm42014-06-071-1/+18
| | | | | | | | | | | | 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: docs: some clarificationswm42014-06-071-1/+7
|
* client API: change mpv_wait_event() timeout semanticswm42014-06-071-1/+2
| | | | | | | | | 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: report success status when running commandswm42014-06-011-6/+6
| | | | | | 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: add mpv_load_config_file()wm42014-05-181-0/+24
| | | | | | | 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()).
* client API: add chapter change eventwm42014-04-271-1/+5
| | | | Also works for mpv_observe_property() on the "chapter" property.
* client API: remove mpv_event_pause_reasonwm42014-04-141-30/+5
| | | | | | | | | 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-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-11-05 01:59:34 +0000