Commit Graph

94 Commits

Author SHA1 Message Date
Aman Gupta fccc3d3894 Fix some typos in code comments
Signed-off-by: wm4 <wm4@nowhere>
2015-12-21 22:28:12 +01:00
wm4 3dc0f2ecf0 vo_opengl_cb: make operation more similar to normal VOs
vo_opengl_cb is a special case, because we somehow have to render video
asynchronously, all while "trusting" the API user to do it correctly.
This didn't quite work, and a while ago a compromise using a timeout to
prevent theoretically possible deadlocks was added.

Make it even more synchronous. Basically, go all the way, and
synchronize rendering between VO and user renderer thread to the
full extent possible.

This means the silly frame queue is dropped, and we event attempt to
synchronize the GL SwapBuffer call (via mpv_opengl_cb_report_flip()).

The changes introduced with commit dc33eb56 are effectively dropped. I
don't even remember if they mattered.

In the future, we might make all VOs fetch asynchronously from a frame
queue, which would mostly remove the differences between vo_opengl and
vo_opengl_cb, but this will take a while (if it will even be done).
2015-11-09 20:51:57 +01:00
wm4 878f12885b client API: fix typo and wording in a comment 2015-10-22 19:36:38 +02:00
wm4 46c499d02a DOCS/client_api_examples/README: rewrite
The new one is much more detailed.

Also add part of it to the libmpv doxygen.
2015-10-10 15:44:27 +02:00
wm4 0e9cfa6b64 vo_opengl: add mechanism to retrieve Display from EGL context
The VAAPI EGL interop code will need access to the X11 Display. While
GLX could return it from the current GLX context, EGL has no such
mechanism. (At least no standard one supported by all implementations.)
So mpv makes up such a mechanism.

For internal purposes, this is very rather awkward solution, but it's
needed for libmpv anyway.
2015-09-25 00:20:11 +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
wm4 b989bb96d1 client API: change subtle wording to different subtle wording
Make a difference between different mpv_handles pointing to the same mpv
core, or different mpv cores. While we're not explicit about it, at
least avoid that someone could misunderstand when really looking for the
case of mpv_handles pointing to the same core.
2015-08-12 23:04:05 +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 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 3477088741 player: use profiles for libmpv and encoding defaults
The client API (libmpv) and encoding (--o) have slightly different
defaults from the command line player. Instead of doing a bunch of calls
to set the options explicitly, use profiles. This is simpler and has the
advantage that they can be listed on command line (instead of possibly
forcing the user to find and read the code to know all the details).
2015-05-07 21:26:11 +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 90adf2904e client API: clarify mpv_opengl_cb_render() viewport parameter
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.
2015-03-09 22:51:28 +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 d77fdc8f82 client API: hint that opengl_cb is an alternative to window embedding 2015-02-23 16:07:11 +01:00
wm4 a799a4c57f client API: clarify filename string encoding
Admittedly, the behavior on Windows is not quite straightforward. The
behavior on the other platforms is equivalent to fopen().

Fixes #1585.
2015-02-14 14:36:48 +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
xylosper a4c0e254a3 vo_opengl_cb: make mpv_opengl_cb_render() return left frames
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.
2015-01-08 21:32:22 +01:00
wm4 a91f127246 client API: clarify some vo_opengl_cb requirements
Stupid drivers. I hope the problem described here isn't actually common.
2015-01-04 22:21:14 +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 a850bf786e vo_opengl_cb: simplify API uninitialization
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.
2014-12-31 20:31:19 +01:00
wm4 799e8861bb client API: qthelper: return NULL as handle if unset
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.
2014-12-30 23:28:07 +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 7f36d1532e client API: document requirement to block SIGPIPE
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.
2014-12-24 13:25:33 +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 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 e002ba74d3 client API: additional documentation comments
(I guess some of the mpv_event contents turned out relatively awkward.)
2014-11-07 16:21:51 +01:00
wm4 61b06f3756 client API: nothing uses the result parameter of mpv_command_node()
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.
2014-11-02 17:46:53 +01:00
wm4 8c3baffadb client API: qthelper: add set_option_variant() 2014-10-30 11:29:45 +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 98356b81b4 client API: clarify statement about thread-safety
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.
2014-10-28 20:30:11 +01:00
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