Commit Graph

60 Commits

Author SHA1 Message Date
wm4 f30c5d09f4 client API: turn mpv_suspend() and mpv_resume() into stubs
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.
2016-11-22 15:54:44 +01:00
wm4 f843ae9983 Fix some future release version numbers
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.
2016-11-21 20:17:41 +01:00
Martin Herkt eafc273d2c
DOCS: update interface changes 2016-11-20 18:14:41 +01:00
wm4 274c6f36f5 DOCS/client-api-changes.rst: fix typo 2016-11-15 23:49:36 +01:00
wm4 e6dedbcc23 qthelper: introduce new convenience functions
(Why the heck is the C++ helper not in a separate repository?)
2016-09-26 16:49:35 +02:00
wm4 7783f0b7d7 client API: more or less deprecate mpv_set_option()
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.
2016-09-21 17:35:00 +02:00
wm4 df85c76b7f client API: revert some relaxations about calling mpv_initialize()
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.)
2016-09-19 20:02:53 +02:00
wm4 15baf2789c client API: declare mpv_suspend/mpv_resume deprecated
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.
2016-09-16 14:39:47 +02:00
wm4 1b5b23b948 client API: remove SIGPIPE overriding code
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.
2016-09-15 13:13:23 +02:00
wm4 453fea87fa client API: create core thread at an earlier time
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().
2016-09-01 21:55:21 +02:00
wm4 b10dcecf7d client API: deprecate "no-..." option handling
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.
2016-08-31 22:16:43 +02:00
Martin Herkt 795b65b2ff
DOCS: Update version 2016-08-15 16:16:17 +02:00
wm4 3a21d71ad0 client API: bump API for stream_cb
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.)
2016-08-07 19:42:20 +02:00
wm4 26b6873ffd client API: remove "status" log level from mpv_request_event docs
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.
2016-07-08 16:10:57 +02:00
wm4 d1d864546c DOCS: change version references from 0.17.1 to 0.18.0
0.17.1 was never released, so the actual 0.18.0 release takes its place.
2016-06-25 12:39:08 +02:00
wm4 c1cb04b6a3 vo_opengl: apply vo-cmdline command incrementally
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.
2016-06-05 16:56:34 +02:00
wm4 b2646911a9 client API: access choices as flags if appropriate
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.
2016-05-04 17:37:54 +02:00
wm4 a9bd4535d2 client API: improve mpv_set_property() handling of MPV_FORMAT_NODE
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.
2016-04-15 11:32:40 +02:00
wm4 b14c9eb748 client API: rename GL_MP_D3D_interfaces
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.
2015-09-24 21:07:37 +02:00
Martin Herkt 79f8ee2808
DOCS: update client API changes for release 2015-09-23 01:12:15 +02:00
wm4 d3bd5c9541 DOCS: cleanup API changes version markers
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.
2015-09-10 14:08:10 +02:00
wm4 561416597e client API, dxva2: add a workaround for OpenGL fullscreen issues
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.
2015-07-03 16:38:12 +02:00
wm4 23b83c6676 client API: allow using msg-level option for log messages
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.
2015-06-20 21:40:47 +02:00
wm4 e53cb0890e 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 21:42:09 +02:00
wm4 17b3cab983 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 19:16:42 +02:00
wm4 4858c47e1c 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 17:38:35 +02:00
wm4 4df8c21f81 DOCS/client-api-changes: fix release marker
The release was pushed back and now actually happened; the marker became
incorrect.
2015-04-25 20:42:35 +02:00
wm4 ccfe4d6418 client API: add MPV_FORMAT_BYTE_ARRAY type
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.
2015-04-20 23:09:34 +02:00
wm4 e76f6929e5 vo_opengl_cb: deprecate mpv_opengl_cb_render()
Its vp parameter made no sense anymore. Introduce a new one.
2015-04-09 19:31:01 +02:00
wm4 8dc7156bc0 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 19:30:26 +02:00
wm4 963c92eea2 client API: mention the changes to the seek/screenshot commands
Also fix a typo in the manpage.
2015-03-05 12:41:43 +01:00
wm4 2e26639155 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 11:22:15 +01:00
wm4 0283815ee1 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 23:42:25 +01:00
wm4 ffe894ec0a options: change --msg-level option
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.
2015-02-06 16:48:52 +01:00
wm4 ef827af06c 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 18:07:37 +01:00
wm4 64f72687ce 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 21:26:42 +01:00
wm4 84fe12fab5 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 20:50:06 +01:00
wm4 50c40b6ded 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 22:24:57 +01:00
wm4 fb855b8659 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 17:59:04 +01:00
wm4 16025a07bb DOCS/client-api-changes: mark release 0.7.0 2014-12-02 20:36:55 +01:00
wm4 ae5df9be98 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 15:13:35 +01:00
wm4 f5c2e3d6e2 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 10:19:07 +01:00
wm4 8c3baffadb client API: qthelper: add set_option_variant() 2014-10-30 11:29:45 +01:00
wm4 2c320fb609 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 20:30:12 +01:00
wm4 65db3291b3 client API: better error reporting
Give somewhat more information on playback failure.
2014-10-28 20:30:12 +01:00
wm4 3cde02fe22 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 20:30:12 +01:00
wm4 1c5dbdbfc2 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 23:54:19 +02:00
wm4 63e2b6c4ae 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-11 00:33:09 +02:00
wm4 e294656cb1 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 18:28:37 +02:00
wm4 0ec5d35d57 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 14:17:33 +02:00