summaryrefslogtreecommitdiffstats
path: root/DOCS/client-api-changes.rst
Commit message (Collapse)AuthorAgeFilesLines
* client API: add a first class hook API, and deprecate old APIwm42018-03-261-0/+3
| | | | | | | | | | | | | | | As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
* client API: deprecate mpv_get_wakeup_pipe()wm42018-03-261-0/+3
| | | | I don't think anything even uses it.
* client API: add a new way to pass X11 Display etc. to render APIwm42018-03-261-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hardware decoding things often need access to additional handles from the windowing system, such as the X11 or Wayland display when using vaapi. The opengl-cb had nothing dedicated for this, and used the weird GL_MP_MPGetNativeDisplay GL extension (which was mpv specific and not officially registered with OpenGL). This was awkward, and a pain due to having to emulate GL context behavior (like needing a TLS variable to store context for the pseudo GL extension function). In addition (and not inherently due to this), we could pass only one resource from mpv builtin context backends to hwdecs. It was also all GL specific. Replace this with a newer mechanism. It works for all RA backends, not just GL. the API user can explicitly pass the objects at init time via mpv_render_context_create(). Multiple resources are naturally possible. The API uses MPV_RENDER_PARAM_* defines, but internally we use strings. This is done for 2 reasons: 1. trying to leave libmpv and internal mechanisms decoupled, 2. not having to add public API for some of the internal resource types (especially D3D/GL interop stuff). To remain sane, drop support for obscure half-working opengl-cb things, like the DRM interop (was missing necessary things), the RPI window thing (nobody used it), and obscure D3D interop things (not needed with ANGLE, others were undocumented). In order not to break ABI and the C API, we don't remove the associated structs from opengl_cb.h. The parts which are still needed (in particular DRM interop) needs to be ported to the render API.
* client API: deprecate qthelper.hppwm42018-03-151-0/+6
| | | | | | | It's a WTF that we have something as specific in the API. It could be argued that we should provide helpers for other language and GUI toolkit combinations. Obviously that's not going to scale, and it's somewhat likely that it will bitrot. The rest is said in the API changelog.
* client API: send MPV_EVENT_SHUTDOWN only oncewm42018-03-151-0/+2
| | | | | | | | | | | | Before this change, mpv_wait_event() could inconsistently return multiple MPV_EVENT_SHUTDOWN events to a single mpv_handle, up to the point of spamming the event queue under certain circumstances. Change this and just send it exactly once to each mpv_handle. Some client API users might have weird requirements about destroying their state asynchronously (and not reacting immediately to the SHUTDOWN event). This change will help a bit to make this less weird and surprising.
* client API: rename mpv_detach_destroy() to mpv_destroy()wm42018-03-151-0/+2
| | | | | Since this has clearer semantics now, the old name is just clunky and confusing.
* client API: add mpv_create_weak_client()wm42018-03-151-0/+1
|
* client API: cleanup mpv_handle terminationwm42018-03-151-0/+4
| | | | | | | | | | | | | | | This changes how mpv_terminate_destroy() and mpv_detach_destroy() behave. The doxygen in client.h tries to point out the differences. The goal is to make this more useful to the API user (making it behave like refcounting). This will be refined in follow up commits. Initialization is unfortunately closely tied to termination, so that changes as well. This also removes earlier hacks that make sure that some parts of FFmpeg initialization are run in the playback thread (instead of the user's thread). This does not matter with standard FFmpeg, and I have no reason to care about this anymore.
* client API: deprecate opengl-cb API and introduce a replacement APIwm42018-02-281-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
* vo: make opengl-cb first in the autoprobing orderwm42018-02-131-0/+6
| | | | | | | This should be helpful for the new OSX Cocoa backend, which uses opengl-cb internally. Since it comes with a behavior change that could possibly interfere with libmpv/opengl_cb users, we mark it as explicit API change.
* options: drop some previously deprecated optionswm42017-12-251-1/+1
| | | | | | | | A release has been made, so drop options deprecated for that release. Also drop some options which have been deprecated a much longer time before. Also fix a typo in client-api-changes.rst.
* Release 0.28.0v0.28.0Martin Herkt2017-12-251-1/+1
|
* client API: change --stop-playback-on-init-failure defaultwm42017-12-171-0/+3
| | | | | | | | | | | | | | | | This was off for mpv CLI, but on for libmpv. The motivation behind this was that it would be confusing for applications if libmpv continued playback in a severely "degraded" way (without either audio or video), and that it would be better to fail early. In reality the behavior was just a confusing difference to mpv CLI, and has confused actual users as well. Get rid of it. Not bothering with a version bump, since this is so minor, and it's easy to ensure compatibility in affected applications by just setting the option explicitly. (Also adding the missing next-release-marker in client-api-changes.rst.)
* client API: minor bump + change entry for DRM related opengl-cb changeswm42017-10-231-0/+3
| | | | Commit cfcee4cfe705 forgot those.
* Release 0.27.0v0.27.0Martin Herkt2017-09-131-1/+1
|
* client API: drop old "no-" option emulationwm42017-06-261-0/+3
| | | | | | | You could do mpv_set_option(h, "no-fs", ""), which would behave like "--no-fs" on the command line. At one point, this had to be emulated for compatibility, and printed a deprecation warning. This was almost a year ago, so remove it.
* client API: add MPV_ENABLE_DEPRECATED symbolwm42017-04-201-0/+3
| | | | | (Of course this is on by default, because otherwise we'd randomly break downstream applications.)
* client API: turn mpv_suspend() and mpv_resume() into stubswm42016-11-221-0/+2
| | | | | | | | | | | As threatened by the API changes document. This commit also removes or stubs equivalent calls in IPC and Lua scripting. The stubs are left to maintain ABI compatibility. The semantics of the API functions have been close enough to doing nothing that this probably won't even break existing API users. Probably.
* Fix some future release version numberswm42016-11-211-1/+1
| | | | | | Since the recent release was named 0.22.0 instead of 0.21.1, bump all mentions of 0.22.0 to 0.23.0. These were planned removals of deprecated versions, which obviously didn't happen in 0.22.0.
* DOCS: update interface changesMartin Herkt2016-11-201-1/+1
|
* DOCS/client-api-changes.rst: fix typowm42016-11-151-2/+2
|
* qthelper: introduce new convenience functionswm42016-09-261-0/+3
| | | | (Why the heck is the C++ helper not in a separate repository?)
* client API: more or less deprecate mpv_set_option()wm42016-09-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | With the merging of options and properties, the mpv_set_option() function is close to being useless, and mpv_set_property() can be used for everything instead. There are certain conflicts remaining, which are explained in depth in the docs. For now, none of this should affect existing code using the client API. Make mpv_set_property() redirect to mpv_set_option() before initialization. Remove some options marked as M_OPT_FIXED. The "pause" and "speed" options cannot be written anymore without the playloop being notified by it, so the M_OPT_FIXED does nothing. For "vo-mmcss-profile", the problem was lack of synchronization, which has been added. I'm not sure what the problem was with "frames" - I think it was only marked as M_OPT_FIXED because changing it during playback will have no effect. Except for pause/speed, these changes are needed to make them writable as properties after mpv_initialize(). Also replace all remaining uses of CONF_GLOBAL with M_OPT_FIXED.
* client API: revert some relaxations about calling mpv_initialize()wm42016-09-191-2/+0
| | | | | | | | | | | | | | | | | | | | | | My original idea was making mpv_initialize() a no-op, but it seems this can't happen after all. The problem is especially with subtle interactions in option parsing (basically all pre-parse options). Instead, I might go into the opposite direction, and add a new API function that takes over the role of mpv_create+mpv_initialize, and which will take a list of options. This list will be for the purpose of setting options that can be set only at initialization time (such as config-dir). This would also make it more uniform with the command- line player initialization. Maybe. In any case, for now revert parts of commit 453fea87 to remove the initialization-related freedoms it added. Fortunately, this wasn't released yet, so we remove it from the API as if it never happened. (The rest of that commit is still fine, just not the additional freedom.)
* client API: declare mpv_suspend/mpv_resume deprecatedwm42016-09-161-0/+2
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* client API: remove SIGPIPE overriding codewm42016-09-151-0/+2
| | | | | | | This workaround prevented that libmpv users could accidentally crash when the SIGPIPE signal was triggered by FFmpeg's OpenSSL/GnuTLS usage. But it also modifies the global signal handler state, so remove it now that this workaround is not required anymore.
* client API: create core thread at an earlier timewm42016-09-011-0/+2
| | | | | | | | | | | | | Create the core thread right in mpv_create(), and reduce what mpv_initialize() does further. This is simpler, and allows the API user to do more before calling mpv_initialize(). The latter is not the real goal, rather we'd like mpv_intialize() reduced to do almost nothing. It still does a lot, but nothing truly special anymore that is absolutely required for basic mpv workings. One thing we want the user to be able to do is changing properties before mpv_initialize() to reduce the special status of mpv_set_option().
* client API: deprecate "no-..." option handlingwm42016-08-311-1/+4
| | | | | | | | The client API can do this (and there are apparently some libmpv using projects which rely on this). But it's just unnecessary bloat as it requires a separate code path from the option parser. It would be better to remove this code. Formally deprecate it, including API bump and warning in the API changes file to make it really clear.
* DOCS: Update versionMartin Herkt2016-08-151-1/+1
|
* client API: bump API for stream_cbwm42016-08-071-0/+2
| | | | | | | | | Forgotten in previous commit. Also minor semi-related change: remove the extra "," from the mpv_sub_api enum, which I accidentally added in the previous commit. (C99 is fine with trailing ",", C89 strictly speaking not. So do this for maximum compatibility.)
* client API: remove "status" log level from mpv_request_event docswm42016-07-081-0/+4
| | | | | | Although it appears to be accepted by the function, MSGL_STATUS messages are never passed to the client API. Consequently "status" has the same meaning as "v" and is useless.
* DOCS: change version references from 0.17.1 to 0.18.0wm42016-06-251-1/+1
| | | | 0.17.1 was never released, so the actual 0.18.0 release takes its place.
* vo_opengl: apply vo-cmdline command incrementallywm42016-06-051-0/+5
| | | | | | | | | | Instead of implicitly resetting the options to defaults and then applying the options, they're always applied on top of the current options (in the same way adding new options to the CLI command line will). This does not apply to vo_opengl_cb, because that has an even worse mess which I refuse to deal with.
* client API: access choices as flags if appropriatewm42016-05-041-0/+5
| | | | | | | | | | | | Options/properties that are choices, and which include "yes" or "no" values (or both) can now be read and written as MPV_FORMAT_FLAG. For write access, rejecting flags in these cases was obnoxiously unintuitive and inconvenient. For read access, the value of this is less convincing, and actually it's a major API change. At this point I probably have to admit that the finer details of the client API are very unstable.
* client API: improve mpv_set_property() handling of MPV_FORMAT_NODEwm42016-04-151-0/+9
| | | | | | | | | If a mpv_node wrapped a string, the behavior was different from calling mpv_set_property() with MPV_FORMAT_STRING directly. Change this. The original intention was to be strict about types if MPV_FORMAT_NODE is used. But I think the result was less than ideal, and the same change towards less strict behavior was made to mpv_set_option() ages ago.
* client API: rename GL_MP_D3D_interfaceswm42015-09-241-0/+5
| | | | | | | | | | | | | This is a pseudo-OpenGL extension for letting libmpv query native windowing system handles from the API user. (It uses the OpenGL extension mechanism because I'm lazy. In theory it would be nicer to let the user pass them with mpv_opengl_cb_init_gl(), but this would require a more intrusive API change to extend its argument list.) The naming of the extension and associated function was unnecessarily Windows specific (using "D3D"), even though it would work just fine for other platforms. So deprecate the old names and introduce new ones. The old ones still work.
* DOCS: update client API changes for releaseMartin Herkt2015-09-231-1/+1
|
* DOCS: cleanup API changes version markerswm42015-09-101-8/+9
| | | | | | Make it so that they don't need to be edited on release (no change in tense). Also, move the "stray" changes after client API version 1.19 to 1.19 itself.
* client API, dxva2: add a workaround for OpenGL fullscreen issueswm42015-07-031-0/+2
| | | | | | | | | This is basically a hack for drivers which prevent the mpv DXVA2 decoder glue from working if OpenGL is in fullscreen mode. Since it doesn't add any "hard" new API to the client API, some of the code would be required for a true zero-copy hw decoding pipeline, and sine it isn't too much code after all, this is probably acceptable.
* client API: allow using msg-level option for log messageswm42015-06-201-0/+1
| | | | | | | | | | | | | | | | Client API users can enable log output with mpv_request_log_messages(). But you can enable only a single log level. This is normally enough, but the --msg-level option (which controls the terminal log level) provides more flexibility. Due to internal complexity, it would be hard to provide the same flexibility for each client API handle. But there's a simple way to achieve basically the same thing: add an option that sends log messages to the API handle, which would also be printed to the terminal as by --msg-level. The only change is that we don't disable this logic if the terminal is disabled. Instead we check for this before the message is output, which in theory can lower performance if messages are being spammed. It could be handled with some more effort, but the gain would be negligible.
* client API: add MPV_END_FILE_REASON_REDIRECTwm42015-06-111-0/+3
| | | | | Requested. Minor incompatible behavior change, as it was signalling MPV_END_FILE_REASON_EOF previously.
* DOCS: add a changelog for option/command/property changeswm42015-05-221-3/+10
| | | | | All these make up both user interface and API. It's a good idea to actually keep track of changes to it.
* Always block SIGPIPE globallywm42015-05-111-1/+2
| | | | | | | | | | | | | | | 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.
* DOCS/client-api-changes: fix release markerwm42015-04-251-1/+1
| | | | | The release was pushed back and now actually happened; the marker became incorrect.
* client API: add MPV_FORMAT_BYTE_ARRAY typewm42015-04-201-0/+1
| | | | | | | | | | | | This will be used in the following commit, which adds screenshot_raw. The reasoning is that this will be better for binding scripting languages. One could special-case the screenshot_raw commit and define fixed semantics for passing through a pointer using the current API, like formatting a pointer as string. But that would be ridiculous and unclean.
* vo_opengl_cb: deprecate mpv_opengl_cb_render()wm42015-04-091-0/+1
| | | | Its vp parameter made no sense anymore. Introduce a new one.
* vo_opengl_cb: add a function to report vsync timewm42015-04-091-0/+1
| | | | | | | And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
* client API: mention the changes to the seek/screenshot commandswm42015-03-051-0/+2
| | | | Also fix a typo in the manpage.
* player, client API: refactor cplayer init, reduce client API differenceswm42015-03-051-0/+4
| | | | | | | | | | | | | 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.)
* DOCS/client-api-changes: mark 0.8.0 releasewm42015-02-171-2/+3
| | | | | (There was a missing version bump for the msg-level change; just move it under 1.14.)
* options: change --msg-level optionwm42015-02-061-0/+2
| | | | | | | | | | | | | | Make it accept "," as separator, instead of only ":". Do this by using the key-value-list parser. Before this, the option was stored as a string, with the option parser verifying that the option value as correct. Now it's stored pre-parsed, although the log levels still require separate verification and parsing-on-use to some degree (which is why the msg-level option type doesn't go away). Because the internal type changes, the client API "native" type also changes. This could be prevented with some more effort, but I don't think it's worth it - if MPV_FORMAT_STRING is used, it still works the same, just with a different separator on read accesses.
* client API: add mpv_wait_async_requests()wm42015-02-021-0/+1
| | | | | | | | | | | | | | | | | | | | 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-0/+1
| | | | | | | | | | | | | | | 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.
* client API: add function to create new mpv_handles from existing oneswm42014-12-311-0/+3
| | | | | | |