Commit Graph

57 Commits

Author SHA1 Message Date
wm4 fe5ba6e217 client API: qthelper: remove commented code
This is already taken care of by Q_DISABLE_COPY().
2014-10-14 22:05:15 +02:00
wm4 95dda1050d client API: qthelper: fix bugs
Pretty dumb oversights.
2014-10-14 13:20:05 +02: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
James Ross-Gowan e48b2bd4d1 libmpv/mpv.def: add mpv_command_node[_async] 2014-10-12 00:56:40 +11: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 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
wm4 f73778ad82 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 13:11:55 +02:00
wm4 046ad8c5ae msg: set an explicit overflow message
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.)
2014-10-08 12:49:04 +02:00
wm4 5feec17ca8 client API: improve mpv_observe_property docs
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.
2014-10-07 21:22:05 +02:00
wm4 128bb68d29 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 21:01:19 +02:00
wm4 3273db1ef7 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 20:11:00 +02:00
wm4 64b7811c28 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 14:48:26 +02:00
wm4 a31330608b client API: adjust documentation for mpv_suspend()
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.
2014-08-14 19:29:21 +02:00
wm4 7898169484 build: add hacks to force waf to generate valid .pc files
Don't like this? You're invited to fix this crap.
2014-08-07 23:45:40 +02:00
wm4 5a0db9bf8a build: move def file to libmpv/
This is more consistent with mpv.pc, which is also in libmpv/.
2014-08-05 20:02:41 +02:00
wm4 43ddf2099b 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 02:23:14 +02:00
wm4 0f5aed9c62 player: some further playloop cleanups
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.
2014-08-03 20:31:00 +02:00
wm4 b4f24544bb client API: make "cache" property and similar observable
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.
2014-07-31 04:19:41 +02:00
wm4 471dfba018 client API: fix typos in documentation 2014-07-30 03:33:37 +02:00
wm4 acd60736ef Remove stream_pts stuff
This was used by DVD/BD, but its usage was removed with one of the
previous commits.
2014-07-06 19:05:59 +02:00
wm4 0004aaf788 DOCS: add a file listing API changes for the client API 2014-07-03 01:26:19 +02:00
wm4 05fd3e701b client API: declare as stable
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.
2014-06-20 19:26:04 +02:00
wm4 09dd1ed47c client API: minor documentation fixes/enhancements 2014-06-08 16:11:39 +02:00
wm4 5cc68c792b client API: restructure waiting, do log msg wakeup properly
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.
2014-06-07 23:16:46 +02:00
wm4 fca608ccb9 client API: rename mpv_destroy() to mpv_detach_destroy()
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.
2014-06-07 20:25:48 +02:00
wm4 0b9468f65f client API: clarify mpv_get_wakeup_pipe docs
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.
2014-06-07 20:13:01 +02:00
wm4 500ce69a06 client API: add API function that ensures total destruction
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.)
2014-06-07 15:57:54 +02:00
wm4 d64bd9efa1 client API: docs: some clarifications 2014-06-07 15:57:54 +02:00
wm4 a1000962e3 client API: change mpv_wait_event() timeout semantics
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.
2014-06-07 15:57:47 +02:00
wm4 5a5a3c53f7 client API: report success status when running commands
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.
2014-06-01 03:41:46 +02:00
wm4 537ac1a15f client API: add mpv_load_config_file()
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()).
2014-05-18 19:21:39 +02:00
wm4 e8a996cede client API: add chapter change event
Also works for mpv_observe_property() on the "chapter" property.
2014-04-27 22:28:07 +02:00
wm4 196619671d client API: remove mpv_event_pause_reason
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.
2014-04-14 22:33:41 +02:00
wm4 4e5cea86c2 client API: add mpv_get_wakeup_pipe convenience function
Should make integreating with some event loops easier. Untested.
2014-04-12 20:13:07 +02:00
wm4 86094c2c5a client API: include the reason in MPV_EVENT_END_FILE
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.)
2014-04-11 01:23:32 +02:00
wm4 fa35079361 client API: remove outdated comments 2014-04-11 00:12:35 +02:00
wm4 f0c8c26e29 client API: improve comments 2014-04-10 23:53:42 +02:00
wm4 89d400dc21 client API: avoid redundant property change events if possible
This is done simply by comparing the previous and current values. Do
this only if the requested format is not MPV_FORMAT_NONE.
2014-04-08 22:06:39 +02:00
wm4 49d1b42f70 client API: add a way to notify clients of property changes
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.
2014-04-06 03:22:49 +02:00
Alessandro Ghedini dfc57e6d32 libmpv: add pkg-config file 2014-03-11 19:15:42 +01:00
xylosper dd13e29cc2 client APIs: fix some typos 2014-02-28 20:54:47 +01:00
wm4 c30bf22d8d client API: rename MPV_EVENT_PLAYBACK_START, add MPV_EVENT_SEEK
Rename MPV_EVENT_PLAYBACK_START to MPV_EVENT_FILE_LOADED.

Add MPV_EVENT_SEEK and MPV_EVENT_PLAYBACK_RESTART.
2014-02-28 01:31:38 +01:00
wm4 f3c933e5d3 options: allow changing options at runtime
Allow changing all options at runtime, except some cherry-picked
options, which are disabled with M_OPT_FIXED.
2014-02-25 23:59:27 +01:00
wm4 279bd8db1f client API: change description of format conversions
This changed during the time between writing the comment, and finishing
up the implementation.

Although I'm still unsure about this.
2014-02-25 22:57:48 +01:00
wm4 0adb8a9aaf client API: report pause/unpause reason
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.
2014-02-24 22:50:25 +01:00
wm4 5d7007c644 client API: expose the internal clock
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.
2014-02-24 22:50:25 +01:00
wm4 38a36fd7ea client API: add comment about character encoding issues
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).
2014-02-24 22:50:24 +01:00
wm4 43ad09393c client API: add more data formats, add a structured data type
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.
2014-02-24 20:50:47 +01:00
wm4 1e27d130a2 client API: change semantics for MPV_FORMAT_STRING
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().
2014-02-24 20:50:47 +01:00
wm4 1e30048184 client API: fix a typo 2014-02-24 20:48:59 +01:00