aboutsummaryrefslogtreecommitdiffhomepage
path: root/libmpv
Commit message (Collapse)AuthorAge
* client API: fully document opengl-cb hardware decoding interopGravatar wm42016-06-01
| | | | | Document it exhaustively. Most of these issues were basically burried in the code.
* client API: improve mpv_set_property() handling of MPV_FORMAT_NODEGravatar wm42016-04-15
| | | | | | | | | 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.
* qthelper: fix potential NULL deref in error pathGravatar wm42016-03-22
| | | | Found by clang-tidy.
* DOCS: add some hints to the new examples repositoryGravatar wm42016-03-10
|
* client API: explain when mpv_create() can return NULLGravatar wm42016-02-14
|
* Fix some typos in code commentsGravatar Aman Gupta2015-12-21
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl_cb: make operation more similar to normal VOsGravatar wm42015-11-09
| | | | | | | | | | | | | | | | | | | | | 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).
* client API: fix typo and wording in a commentGravatar wm42015-10-22
|
* DOCS/client_api_examples/README: rewriteGravatar wm42015-10-10
| | | | | | The new one is much more detailed. Also add part of it to the libmpv doxygen.
* vo_opengl: add mechanism to retrieve Display from EGL contextGravatar wm42015-09-25
| | | | | | | | | | 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.
* client API: rename GL_MP_D3D_interfacesGravatar wm42015-09-24
| | | | | | | | | | | | | 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.
* client API: change subtle wording to different subtle wordingGravatar wm42015-08-12
| | | | | | | 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.
* client API, dxva2: add a workaround for OpenGL fullscreen issuesGravatar wm42015-07-03
| | | | | | | | | 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 messagesGravatar wm42015-06-20
| | | | | | | | | | | | | | | | 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_REDIRECTGravatar wm42015-06-11
| | | | | Requested. Minor incompatible behavior change, as it was signalling MPV_END_FILE_REASON_EOF previously.
* Always block SIGPIPE globallyGravatar wm42015-05-11
| | | | | | | | | | | | | | | 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.
* player: use profiles for libmpv and encoding defaultsGravatar wm42015-05-07
| | | | | | | | 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).
* client API: add MPV_FORMAT_BYTE_ARRAY typeGravatar wm42015-04-20
| | | | | | | | | | | | 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()Gravatar wm42015-04-09
| | | | Its vp parameter made no sense anymore. Introduce a new one.
* vo_opengl_cb: add a function to report vsync timeGravatar wm42015-04-09
| | | | | | | And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
* client API: clarify mpv_opengl_cb_render() viewport parameterGravatar wm42015-03-09
| | | | | | | | | | | | 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.
* player, client API: refactor cplayer init, reduce client API differencesGravatar wm42015-03-05
| | | | | | | | | | | | | 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.)
* client API: hint that opengl_cb is an alternative to window embeddingGravatar wm42015-02-23
|
* client API: clarify filename string encodingGravatar wm42015-02-14
| | | | | | | Admittedly, the behavior on Windows is not quite straightforward. The behavior on the other platforms is equivalent to fopen(). Fixes #1585.
* client API: add mpv_wait_async_requests()Gravatar wm42015-02-02
| | | | | | | | | | | | | | | | | | | | 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 overflowGravatar wm42015-01-19
| | | | | | | | | | | | | | | 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.
* vo_opengl_cb: make mpv_opengl_cb_render() return left framesGravatar xylosper2015-01-08
| | | | | | 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.
* client API: clarify some vo_opengl_cb requirementsGravatar wm42015-01-04
| | | | Stupid drivers. I hope the problem described here isn't actually common.
* client API: add function to create new mpv_handles from existing onesGravatar wm42014-12-31
| | | | | | | 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.
* vo_opengl_cb: simplify API uninitializationGravatar wm42014-12-31
| | | | | | | | | | | 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.
* client API: qthelper: return NULL as handle if unsetGravatar wm42014-12-30
| | | | | | | | | 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.
* client API: qthelper: add a refcounting wrapper around mpv_handleGravatar wm42014-12-30
| | | | | This is useful to deal with crazy Qt object lifetime issues (the following commit needs it).
* client API: document requirement to block SIGPIPEGravatar wm42014-12-24
| | | | | | | | | 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.
* client API: expose OpenGL rendererGravatar wm42014-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* input, lua: redo input handlingGravatar wm42014-11-23
| | | | | Much of it is the same, but now there's the possibility to distinguish key down/up events in the Lua API.
* client API: deprecate some eventsGravatar wm42014-11-08
| | | | | | | | | | | 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.
* client API: additional documentation commentsGravatar wm42014-11-07
| | | | (I guess some of the mpv_event contents turned out relatively awkward.)
* client API: nothing uses the result parameter of mpv_command_node()Gravatar wm42014-11-02
| | | | | | 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.
* client API: qthelper: add set_option_variant()Gravatar wm42014-10-30
|
* client API: better error reportingGravatar wm42014-10-28
| | | | Give somewhat more information on playback failure.
* client API: add an enum for mpv_event_end_file.reasonGravatar wm42014-10-28
| | | | | | | | | 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.
* client API: clarify statement about thread-safetyGravatar wm42014-10-28
| | | | | | | | | 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.
* client API: qthelper: remove commented codeGravatar wm42014-10-14
| | | | This is already taken care of by Q_DISABLE_COPY().
* client API: qthelper: fix bugsGravatar wm42014-10-14
| | | | Pretty dumb oversights.
* client API: add qthelper.hppGravatar wm42014-10-13
| | | | | | | | | | | | | | 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.
* libmpv/mpv.def: add mpv_command_node[_async]Gravatar James Ross-Gowan2014-10-12
|
* client API: add mpv_command_node[_async]Gravatar wm42014-10-11
| | | | | | | | | 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.
* client API: introduce numeric log levelsGravatar wm42014-10-08
| | | | | | | | | | | | | | | | 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.
* msg, client API: buffer partial linesGravatar wm42014-10-08
| | | | | | | | | | | | | | | 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.
* msg: set an explicit overflow messageGravatar wm42014-10-08
| | | | | | | | 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.)
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 03:07:58 +0000