summaryrefslogtreecommitdiffstats
path: root/libmpv
Commit message (Collapse)AuthorAgeFilesLines
* client API: clarify mpv_opengl_cb_render() viewport parameterwm42015-03-091-1/+4
| | | | | | | | | | | | Basically, the idea behind the vp parameter is broken - I guess the intention was to enable rendering to a specific subrectangle of the target framebuffer, but there's nothing to specify the actual target rectangle (the VO will still clear e.g. the borders between video and framebuffer borders). We're not going to keep the current semantics either with the upcoming rework of vo_opengl, so declare this for broken. Maybe we can introduce a function later which does this properly.
* player, client API: refactor cplayer init, reduce client API differenceswm42015-03-051-3/+5
| | | | | | | | | | | | | Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
* client API: hint that opengl_cb is an alternative to window embeddingwm42015-02-231-0/+7
|
* client API: clarify filename string encodingwm42015-02-141-0/+24
| | | | | | | Admittedly, the behavior on Windows is not quite straightforward. The behavior on the other platforms is equivalent to fopen(). Fixes #1585.
* client API: add mpv_wait_async_requests()wm42015-02-022-1/+16
| | | | | | | | | | | | | | | | | | | | This does what it's documented to do. The implementation reuses the code in mpv_detach_destroy(). Due to the way async requests currently work, just sending a synchronous dummy request (like a "ignore" command) would be enough to ensure synchronization, but this code will continue to work even if this changes. The line "ctx->event_mask = 0;" is removed, but it shouldn't be needed. (If a client is somehow very slow to terminate, this could silence an annoying queue overflow message, but all in all it does nothing.) Calling mpv_wait_async_requests() and mpv_wait_event() concurrently is in theory allowed, so change pthread_cond_signal() to pthread_cond_broadcast() to avoid missed wakeups. As requested in issue #1542.
* client API: notify API user on event queue overflowwm42015-01-191-5/+16
| | | | | | | | | | | | | | | Before this, we merely printed a message to the terminal. Now the API user can determine this properly. This might be important for API users which somehow maintain complex state, which all has to be invalidated if (state-changing) events are missing due to an overflow. This also forces the client API user to empty the event queue, which is good, because otherwise the event queue would reach the "filled up" state immediately again due to further asynchronous events being added to the queue. Also add some minor improvements to mpv_wait_event() documentation, and some other minor cosmetic changes.
* vo_opengl_cb: make mpv_opengl_cb_render() return left framesxylosper2015-01-081-1/+1
| | | | | | Instead of error code which was not helpful because it's always 0, mpv_opengl_cb_render() returns the number of left frames in the frame queue now.
* client API: clarify some vo_opengl_cb requirementswm42015-01-041-0/+6
| | | | Stupid drivers. I hope the problem described here isn't actually common.
* client API: add function to create new mpv_handles from existing oneswm42014-12-312-0/+27
| | | | | | | This may or may not be useful for client API users. Fold this API extension into the previous API bump. The previous bump was only yesterday, so it's ok.
* vo_opengl_cb: simplify API uninitializationwm42014-12-311-4/+13
| | | | | | | | | | | Until now, calling mpv_opengl_cb_uninit_gl() at a "bad moment" could make the whole thing to explode. The API user was asked to avoid such situations by calling it only in "good moments". But this was probably a bit too subtle and could easily be overlooked. Integrate the approach the qml example uses directly into the implementation. If the OpenGL context is to be unitialized, forcefully disable video, and block until this is done.
* client API: qthelper: return NULL as handle if unsetwm42014-12-301-2/+6
| | | | | | | | | Creating a plain Handle() should yield a NULL mpv_handle. Also, remove the redundant non-const definition of the conversion operator. At least in this situation it's not needed. Also, add include guards around qthelper.hpp.
* client API: qthelper: add a refcounting wrapper around mpv_handlewm42014-12-302-1/+31
| | | | | This is useful to deal with crazy Qt object lifetime issues (the following commit needs it).
* client API: document requirement to block SIGPIPEwm42014-12-241-0/+2
| | | | | | | | | I noticed that the IPC code does not use MSG_NOSIGNAL or SO_NOSIGPIPE. The former is "only" POSIX 2008 and also requires switching to sendto(), while the latter is even less portable. Not going to bother with this obsolete 80ies crap, just block SIGPIPE, and instruct client API users to do the same.
* client API: expose OpenGL rendererwm42014-12-093-6/+240
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
* input, lua: redo input handlingwm42014-11-231-17/+9
| | | | | Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
* client API: deprecate some eventswm42014-11-081-0/+23
| | | | | | | | | | | Following the discussion in #1253. The events won't be removed for a while, though. (Or maybe never, unless we run out of bits for the uint64_t event mask.) This is not a real change (the events still work, and the alternative mechanisms were established a few API revisions earlier), but for the sake of notifying API users, update DOCS/client-api-changes.rst.
* client API: additional documentation commentswm42014-11-071-5/+19
| | | | (I guess some of the mpv_event contents turned out relatively awkward.)
* client API: nothing uses the result parameter of mpv_command_node()wm42014-11-021-0/+2
| | | | | | Add a comment about this to avoid confusing users of this function. The parameter is essentially unused, but exists so that we don't need to add extra APIs if the need for it arises.
* client API: qthelper: add set_option_variant()wm42014-10-301-0/+10
|
* client API: better error reportingwm42014-10-281-1/+38
| | | | Give somewhat more information on playback failure.
* client API: add an enum for mpv_event_end_file.reasonwm42014-10-281-8/+26
| | | | | | | | | Using magic integer values was an attempt to keep the API less verbose. But it was probably not a good idea. Reason 1 (restart) is not made explicit, because it is not used anymore starting with the previous commit. For ABI compatibility, the value is left as a hole in the enum.
* client API: clarify statement about thread-safetywm42014-10-281-5/+6
| | | | | | | | | The only reason for mpv_wait_event() not being thread-safe is that it returns a pointer to a mpv_event struct member in the mpv_handle context, which in turn is done for ABI-safety (user doesn't allocate or manage the struct), and to avoid the need additional memory management. Some users were interpreting this incorrectly.
* 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/