RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-12-24 15:52:25 +00:00
Code Issues Releases Wiki Activity
8b44be54e7
mpv/DOCS/client-api-changes.rst

108 lines
5.0 KiB
ReStructuredText
Raw Normal View History

DOCS: add a file listing API changes for the client API
2014-07-02 23:24:41 +00:00
Introduction
============
This file lists all changes that can cause compatibility issues when using
mpv through the client API (libmpv and ``client.h``). Since the client API
interfaces to input handling (commands, properties) as well as command line
DOCS: add a changelog for option/command/property changes All these make up both user interface and API. It's a good idea to actually keep track of changes to it.
2015-05-22 17:00:13 +00:00
options, you should also look at ``interface-changes.rst``.
DOCS: add a file listing API changes for the client API
2014-07-02 23:24:41 +00:00
Normally, changes to the C API that are incompatible to previous iterations
receive a major version bump (i.e. the first version number is increased),
while C API additions bump the minor version (i.e. the second number is
increased). Changes to properties/commands/options may also lead to a minor
version bump, in particular if they are incompatible.
The version number is the same as used for MPV_CLIENT_API_VERSION (see
``client.h`` how to convert between major/minor version numbers and the flat
32 bit integer).
Also, read the section ``Compatibility`` in ``client.h``.
DOCS: add a changelog for option/command/property changes All these make up both user interface and API. It's a good idea to actually keep track of changes to it.
2015-05-22 17:00:13 +00:00
Options, commands, properties
=============================
Changes to these are not listed here, but in ``interface-changes.rst``. (Before
client API version 1.17, they were listed here partially.)
This listing includes changes to the bare C API and behavior only, not what
you can access with them.
DOCS: add a file listing API changes for the client API
2014-07-02 23:24:41 +00:00
API changes
===========
DOCS/client-api-changes: try to fix rst formatting again
2014-07-06 17:05:45 +00:00
::
client API: add MPV_END_FILE_REASON_REDIRECT Requested. Minor incompatible behavior change, as it was signalling MPV_END_FILE_REASON_EOF previously.
2015-06-11 19:39:48 +00:00
1.18 - add MPV_END_FILE_REASON_REDIRECT, and change behavior of
MPV_EVENT_END_FILE accordingly
- a bunch of interface-changes.rst changes
Always block SIGPIPE globally OpenSSL and GnuTLS are still causing this problem (although FFmpeg could be blamed as well - but not really). In particular, it was happening to libmpv users and in cases the pseudo-gui profile is used. This was because all signal handling is in the terminal code, so if terminal is disabled, it won't be set. This was obviously a questionable shortcut. Avoid further problems by always blocking the signal. This is done even for libmpv, despite our policy of not messing with global state. Explicitly document this in the libmpv docs. It turns out that a version bump to 1.17 was forgotten for the addition of MPV_FORMAT_BYTE_ARRAY, so document that change as part of 1.16.
2015-05-11 15:38:35 +00:00
1.17 - mpv_initialize() now blocks SIGPIPE (details see client.h)
DOCS/client-api-changes: fix release marker The release was pushed back and now actually happened; the marker became incorrect.
2015-04-25 18:42:35 +00:00
--- mpv 0.9.0 is released ---
vo_opengl_cb: add a function to report vsync time And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
2015-04-09 17:30:26 +00:00
1.16 - add mpv_opengl_cb_report_flip()
vo_opengl_cb: deprecate mpv_opengl_cb_render() Its vp parameter made no sense anymore. Introduce a new one.
2015-04-09 17:31:01 +00:00
- introduce mpv_opengl_cb_draw() and deprecate mpv_opengl_cb_render()
Always block SIGPIPE globally OpenSSL and GnuTLS are still causing this problem (although FFmpeg could be blamed as well - but not really). In particular, it was happening to libmpv users and in cases the pseudo-gui profile is used. This was because all signal handling is in the terminal code, so if terminal is disabled, it won't be set. This was obviously a questionable shortcut. Avoid further problems by always blocking the signal. This is done even for libmpv, despite our policy of not messing with global state. Explicitly document this in the libmpv docs. It turns out that a version bump to 1.17 was forgotten for the addition of MPV_FORMAT_BYTE_ARRAY, so document that change as part of 1.16.
2015-05-11 15:38:35 +00:00
- add MPV_FORMAT_BYTE_ARRAY
player, client API: refactor cplayer init, reduce client API differences 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.)
2015-03-05 10:17:22 +00:00
1.15 - mpv_initialize() will now load config files. This requires setting
the "config" and "config-dir" options. In particular, it will load
mpv.conf.
client API: mention the changes to the seek/screenshot commands Also fix a typo in the manpage.
2015-03-05 11:41:43 +00:00
- minor backwards-compatible change to the "seek" and "screenshot"
commands (new flag syntax, old additional args deprecated)
DOCS/client-api-changes: mark 0.8.0 release (There was a missing version bump for the msg-level change; just move it under 1.14.)
2015-02-17 22:42:25 +00:00
--- mpv 0.8.0 is released ---
client API: add mpv_wait_async_requests() 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.
2015-02-02 16:24:33 +00:00
1.14 - add mpv_wait_async_requests()
DOCS/client-api-changes: mark 0.8.0 release (There was a missing version bump for the msg-level change; just move it under 1.14.)
2015-02-17 22:42:25 +00:00
- the --msg-level option changes its native type from a flat string to
a key-value list (setting/reading the option as string still works)
client API: notify API user on event queue overflow 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.
2015-01-19 18:54:20 +00:00
1.13 - add MPV_EVENT_QUEUE_OVERFLOW
client API: qthelper: add a refcounting wrapper around mpv_handle This is useful to deal with crazy Qt object lifetime issues (the following commit needs it).
2014-12-30 21:24:57 +00:00
1.12 - add class Handle to qthelper.hpp
client API: add function to create new mpv_handles from existing ones 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.
2014-12-31 19:32:35 +00:00
- improve opengl_cb.h API uninitialization behavior, and fix the qml
example
- add mpv_create_client() function
client API: expose OpenGL renderer 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
2014-12-09 16:47:02 +00:00
1.11 - add OpenGL rendering interop API - allows an application to combine
its own and mpv's OpenGL rendering
Warning: this API is not stable yet - anything in opengl_cb.h might
be changed in completely incompatible ways in minor API bumps
DOCS/client-api-changes: mark release 0.7.0
2014-12-02 18:25:25 +00:00
--- mpv 0.7.0 is released ---
input, lua: redo input handling Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
2014-11-23 14:08:49 +00:00
1.10 - deprecate/disable everything directly related to script_dispatch
(most likely affects nobody)
client API: add an enum for mpv_event_end_file.reason 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.
2014-10-28 14:44:25 +00:00
1.9 - add enum mpv_end_file_reason for mpv_event_end_file.reason
client API: better error reporting Give somewhat more information on playback failure.
2014-10-28 15:19:07 +00:00
- add MPV_END_FILE_REASON_ERROR and the mpv_event_end_file.error field
for slightly better error reporting on playback failure
player: add an option to abort playback on partial init failures This is probably what libmpv users want; and it also improves error reporting (or we'd have to add a way to communicate such mid-playback failures as events).
2014-10-28 18:51:44 +00:00
- add --stop-playback-on-init-failure option, and make it the default
behavior for libmpv only
client API: qthelper: add set_option_variant()
2014-10-30 10:26:31 +00:00
- add qthelper.hpp set_option_variant()
client API: deprecate some events 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.
2014-11-08 08:59:38 +00:00
- mark the following events as deprecated:
MPV_EVENT_TRACKS_CHANGED
MPV_EVENT_TRACK_SWITCHED
MPV_EVENT_PAUSE
MPV_EVENT_UNPAUSE
MPV_EVENT_METADATA_UPDATE
MPV_EVENT_CHAPTER_CHANGE
They are handled better with mpv_observe_property() as mentioned in
the documentation comments. They are not removed and still work.
client API: add qthelper.hpp 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.
2014-10-13 19:38:54 +00:00
1.8 - add qthelper.hpp
client API: add mpv_command_node[_async] 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.
2014-10-10 21:58:59 +00:00
1.7 - add mpv_command_node(), mpv_command_node_async()
client API: clarify pause/unpause events, modify core-idle property 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.
2014-10-07 19:01:19 +00:00
1.6 - modify "core-idle" property behavior
msg, client API: buffer partial lines 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.
2014-10-08 11:11:55 +00:00
- MPV_EVENT_LOG_MESSAGE now always sends complete lines
client API: introduce numeric log levels 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.
2014-10-08 12:15:14 +00:00
- introduce numeric log levels (mpv_log_level)
client API: clarify pause/unpause events, modify core-idle property 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.
2014-10-07 19:01:19 +00:00
--- mpv 0.6.0 is released ---
client API, X11: change default keyboard input handling again 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.
2014-09-28 18:11:00 +00:00
1.5 - change in X11 and "--wid" behavior again. The previous change didn't
work as expected, and now the behavior can be explicitly controlled
with the "input-x11-keyboard" option. This is only a temporary
measure until XEmbed is implemented and confirmed working.
client API: rename --input-x11-keyboard to --input-vo-keyboard Apparently we need this for Cocoa too. (The option was X11 specific in the hope that only X11 would need this hack.)
2014-10-09 16:28:37 +00:00
Note: in 1.6, "input-x11-keyboard" was renamed to "input-vo-keyboard",
although the old option name still works.
x11: when using --wid, inherit event flags from parent window 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)
2014-08-31 12:26:31 +00:00
1.4 - subtle change in X11 and "--wid" behavior
client API, X11: change default keyboard input handling again 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.
2014-09-28 18:11:00 +00:00
(this change was added to 0.5.2, and broke some things, see #1090)
DOCS: mark the recent release in client-api-changes.rst Also add instructions to release-policy.md, since this can be easily forgotten. CC: @mpv-player/stable
2014-08-12 19:55:42 +00:00
--- mpv 0.5.0 is released ---
client API: add and use the MPV_MAKE_VERSION macro 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.
2014-08-05 00:23:14 +00:00
1.3 - add MPV_MAKE_VERSION()
Remove stream_pts stuff This was used by DVD/BD, but its usage was removed with one of the previous commits.
2014-07-06 17:05:59 +00:00
1.2 - remove "stream-time-pos" property (no replacement)
DOCS: add a file listing API changes for the client API
2014-07-02 23:24:41 +00:00
1.1 - remap dvdnav:// to dvd://
- add "--cache-file", "--cache-file-size"
- add "--colormatrix-primaries" (and property)
- add "primaries" sub-field to image format properties
- add "playback-time" property
- extend the "--start" option; a leading "+", which was previously
insignificant is now significant
- add "cache-free" and "cache-used" properties
- OSX: the "coreaudio" AO spdif code is split into a separate AO
DOCS/client-api-changes: try to fix rst formatting again
2014-07-06 17:05:45 +00:00
--- mpv 0.4.0 is released ---
DOCS: add a file listing API changes for the client API
2014-07-02 23:24:41 +00:00
1.0 - the API is declared stable
DOCS/client-api-changes: try to fix rst formatting again
2014-07-06 17:05:45 +00:00
Reference in New Issue Copy Permalink