Commit Graph

161 Commits

Author SHA1 Message Date
LongChair 49bc07faea drm/atomic: add connector to atomic context
This patch adds
  - DRM connector object to atomic context.
  - fd property to the drm atomic object as well as a method to read blob type properties.

This allows to ensure that the proper connector is picked up, especially when specifying it
from the commandline, and also allows to make sure we're using the right one when embedding
with interop into an application.
2018-05-01 20:48:02 +03:00
LongChair 9f2970f28a drm/atomic: refactor hwdec_drmprime_drm with native resources
That new API was introduced and allows to have several native resources.
Thisuses that mechanisma for drm resources rather than the deprecated
opengl-cb structs.

This patch therefore add two structs that can be used with the drm atomic interop.
 - mpv_opengl_drm_params : which will hold all the drm handles
 - mpv_opengl_drm_osd_size : which will hold osd layer size

This commit adds a drm-osd-size=WxH parameter to commandline which
allows to define the OSD plane dimension. OSD can be upscaled to
screen resolution when having OSD at video resolution is too heavy.

This is especially useful for UHD modes on embedded devices where
the GPU cannot handle UHD modes at a decent framerate.
2018-05-01 20:48:02 +03:00
wm4 fff5fda74b client API: some doxygen clarifications
Strictly speaking redundant, but probably helpful.

In particular I want to push MPV_RENDER_PARAM_ADVANCED_CONTROL. Not
enabling this parameter is actually not very sane.
2018-04-29 02:21:32 +03:00
wm4 ce4d227986 client API: add some render API extensions for timing
Attempts to enable the following things:
- let a render API user do "proper" audio-sync video timing itself
- make it possible to not re-render repeated frames if the API user has
  better mechanisms available (e.g. waiting for a DisplayLink cycle
  instead)
- allow the user to delay or skip redraws if it makes sense

Basically this information will be needed by API users who want to be
"clever" about optimizing timing and rendering.
2018-04-29 02:21:32 +03:00
wm4 67689ff6b4 client API: preparations for allowing render API to use DR etc.
DR (letting the decoder allocate texture memory) requires running the
allocation on the render thread. This is rather hard with the render
API, because the user controls this thread and when it's entered. It was
not possible until now.

This commit adds a bunch of infrastructure to make this possible. We add
a new optional mode (MPV_RENDER_PARAM_ADVANCED_CONTROL) which basically
lets the user's render thread and libmpv agree how this should be done.

Misuse would lead to deadlocks. To make this less likely, strictly
document thread safety/locking issues. In particular, document which
libmpv functions can be called without issues. (The rest has to be
assumed unsafe.)

The worst issue is destruction of the render context while video is
still active. To avoid certain unintended recursive locks (i.e.
deadlocks, unless we'd make the locks recursive), make the update
callback lock separate. Make "killing" the video chain asynchronous, so
we can do extra work while video is being destroyed.

Because losing wakeups is a big deal, setting the update callback now
triggers a wakeup. (It would have been better if the wakeup callback
were a parameter to mpv_render_context_create(), but too late.)

This commit does not add DR yet; the following commit does this.
2018-04-29 02:21:32 +03:00
wm4 2e768ad0d8 client API: minor clarification
This was a bit confusing.
2018-04-20 14:09:25 +02:00
wm4 f9bcb5c42c client API: clarify that Display pointers etc. need to stay valid
Normally, MPV_RENDER_PARAM* arguments are copied, unless documented
otherwise. Of course we can't copy X11 Display or Wayland wl_display
types, but for arguments that are "summarized" in a struct (like
MPV_RENDER_PARAM_OPENGL_FBO), a copy is expected.

Also add some unused infrastructure to make this explicit, and to make
it easier to add parameter types that require a copy.

Untested.
2018-04-16 01:21:59 +03:00
wm4 f60826c3a1
client API: add a first class hook API, and deprecate old API
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.
2018-03-26 23:02:23 -07:00
wm4 6d7cfdfae5 client API: deprecate mpv_get_wakeup_pipe()
I don't think anything even uses it.
2018-03-26 19:47:08 +02:00
wm4 52dd38a48a client API: add a new way to pass X11 Display etc. to render API
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.
2018-03-26 19:47:08 +02:00
wm4 2c572e2bb1 video: add an option to tune waiting for video timing
Probably mostly useful for the libmpv render API.
2018-03-15 23:13:53 -07:00
wm4 8163b8d390 client API: deprecate qthelper.hpp
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.
2018-03-15 23:13:53 -07:00
wm4 2edf00fb94 client API: send MPV_EVENT_SHUTDOWN only once
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.
2018-03-15 00:00:04 -07:00
wm4 4d9c6ab6b9 client API: rename mpv_detach_destroy() to mpv_destroy()
Since this has clearer semantics now, the old name is just clunky and
confusing.
2018-03-15 00:00:04 -07:00
wm4 a7f3cf4737 client API: add mpv_create_weak_client() 2018-03-15 00:00:04 -07:00
wm4 410a1b49ed client API: cleanup mpv_handle termination
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.
2018-03-15 00:00:04 -07:00
wm4 b037121430 client API: deprecate opengl-cb API and introduce a replacement API
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.
2018-02-28 00:55:06 -08:00
wm4 70b74d32cd client API: clarify license, fix some typos 2018-02-28 00:55:06 -08:00
wm4 7b5a2588bd vo: make opengl-cb first in the autoprobing order
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.
2018-02-13 17:45:29 -08:00
wm4 9e64b93822 client API: be more explicit about what can be done in wakeup callbacks
Don't leave any room for interpretation.
2018-01-25 20:18:32 -08:00
wm4 4f49334318 client API: mention that SIGPIPE is sometimes blocked
ipc-unix.c does this out of convenience. Since signals are global
process state, this deserves a mention, since applications could in
theory rely on SIGPIPE being set to something else.
2018-01-18 00:25:00 -08:00
Leo Izen 17e7f653d3 libmpv/opengl_cb.h: mention OpenGL ES 2.0 support
opengl_cb.h should mention GLES 2.0 support, since this
support is available. Now it does mention it.
2018-01-14 15:23:19 -08:00
wm4 69d062ce37 client API: remove ytdl=no default
With the recent changes to the script it does not incur a startup delay
by default due to starting youtube-dl and waiting for it. This was the
main reason for making libmpv have a different default.

Starting sub processes from a library can still be a bit fishy, but I
think it's ok. Still mention it in the libmpv header. There were already
other cases where libmpv would start its own processes, such as the X11
backend calling xdg-screensaver. (The reason why this is fishy is
because UNIX process management sucks: SIGCHLD and the wait() syscall
make sub processes non-transparent and could potentially introduce
conflicts with code trying to use them.)
2018-01-13 03:26:45 -08:00
wm4 08bcf1d92d client API: be more explicit about how to make libmpv use config files 2018-01-02 15:02:03 -08:00
wm4 91586c3592 vo_gpu: make it possible to load multiple hwdec interop drivers
Make the VO<->decoder interface capable of supporting multiple hwdec
APIs at once. The main gain is that this simplifies autoprobing a lot.
Before this change, it could happen that the VO loaded the "wrong" hwdec
API, and the decoder was stuck with the choice (breaking hw decoding).
With the change applied, the VO simply loads all available APIs, so
autoprobing trickery is left entirely to the decoder.

In the past, we were quite careful about not accidentally loading the
wrong interop drivers. This was in part to make sure autoprobing works,
but also because libva had this obnoxious bug of dumping garbage to
stderr when using the API. libva was fixed, so this is not a problem
anymore.

The --opengl-hwdec-interop option is changed in various ways (again...),
and renamed to --gpu-hwdec-interop. It does not have much use anymore,
other than debugging. It's notable that the order in the hwdec interop
array ra_hwdec_drivers[] still matters if multiple drivers support the
same image formats, so the option can explicitly force one, if that
should ever be necessary, or more likely, for debugging. One example are
the ra_hwdec_d3d11egl and ra_hwdec_d3d11eglrgb drivers, which both
support d3d11 input.

vo_gpu now always loads the interop lazily by default, but when it does,
it loads them all. vo_opengl_cb now always loads them when the GL
context handle is initialized. I don't expect that this causes any
problems.

It's now possible to do things like changing between vdpau and nvdec
decoding at runtime.

This is also preparation for cleaning up vd_lavc.c hwdec autoprobing.
It's another reason why hwdec_devices_request_all() does not take a
hwdec type anymore.
2017-12-01 05:57:01 +01:00
wm4 2c00687641 client API: minor bump + change entry for DRM related opengl-cb changes
Commit cfcee4cfe7 forgot those.
2017-10-23 21:11:44 +02:00
Lionel CHAZALLON cfcee4cfe7 Add DRM_PRIME Format Handling and Display for RockChip MPP decoders
This commit allows to use the AV_PIX_FMT_DRM_PRIME newly introduced
format in ffmpeg that allows decoders to provide an AVDRMFrameDescriptor
struct.

That struct holds dmabuf fds and information allowing zerocopy rendering
using KMS / DRM Atomic.

This has been tested on RockChip ROCK64 device.
2017-10-23 21:07:24 +02:00
wm4 168ffbaf23 client API: more opengl_cb clarifications
Also fix a typo in ra_gl.c. Too greedy for a separate commit.
2017-08-07 19:24:25 +02:00
wm4 dddda6e4a5 vo_opengl: move GL state resetting to vo_opengl_cb
This code is pretty much for the sake of vo_opengl_cb API users. It
resets certain state that either the user or our code doesn't reset
correctly. This is somewhat outdated. With GL implicit state being
so awfully large, it seems more reasonable require that any code
restores the default state when returning to the caller. Some
exceptions are defined in opengl_cb.h.
2017-08-05 16:27:09 +02:00
wm4 6f80a694d3 client API: drop old "no-" option emulation
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.
2017-06-26 20:07:20 +02:00
wm4 82aa1ea87f client API: document mpv_request_log_messages() return value 2017-06-14 10:23:13 +02:00
wm4 2b616c0682 vo_opengl: drop TLS usage
TLS is a headache. We should avoid it if we can.

The involved mechanism is unfortunately entangled with the unfortunate
libmpv API for returning pointers to host API objects. This has to be
kept until we change the API somehow.

Practically untested out of pure laziness. I'm sure I'll get a bunch of
reports if it's broken.
2017-05-11 17:47:33 +02:00
wm4 5ae25ae424 client API: add MPV_ENABLE_DEPRECATED symbol
(Of course this is on by default, because otherwise we'd randomly break
downstream applications.)
2017-04-20 06:19:55 +02:00
wm4 bbfafb5614 Fix use of ISC license
The license text refers a "above copyright notice", so I guess it'd be
good to actually provide such a notice.

Add the license to some files that were missing it (since in theory, our
Copyright file says that such files are LGPL by default).

Remove the questionable remarks about the license in the client API.
2017-04-15 16:20:00 +02:00
wm4 dc7d71fc8e manpage, client API: add some clarifications when commands use OSD
The APIs that run commands in a more API-like manner disable OSD and
string expansion by default.
2017-04-01 21:47:19 +02:00
wm4 a071d5fcfe input: add "async" flag
Obviously, this has no effect on commands which do not support this
explicitly. A later commit will enable this for screenshots.

Also add some wording on mpv_command_async(), which has nothing to do
with this. Having a more elegant, unified behavior would be nice. But
the API function was not created for this - it's merely for running
commands _synchronously_ on the core, but without blocking the client
API caller (if the API user consistently uses only async functions).
2017-04-01 20:36:39 +02:00
wm4 38872463a0 client API: clarify what stream_cb callbacks can do
See #4227.
2017-03-17 04:54:39 +01:00
wm4 8fb0d2ee27 client API: update outdated recommendations about window embedding
Basically, the opengl-cb API causes fewer issues, even if it's a bit
harder on the API user.

See #4197.
2017-03-02 05:53:05 +01:00
wm4 5519d0dde4 stream_cb: remove leftover doxygen line 2017-02-20 15:32:31 +01:00
wm4 6e2d3d9919 vo_opengl: remove dxva2 dummy hwdec backend
This was a hack to let libmpv API users pass a d3d device to mpv. It's
not needed anymore for 2 reasons:

1. ANGLE does not have this problem
2. Even native GL via nVidia (where this failed) seems to not require
   this anymore
2017-02-20 08:39:08 +01:00
Aman Gupta 53fab20c6d vo_opengl: implement videotoolbox hwdec on iOS
Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but
using CVPixelBuffer APIs available on iOS instead of the equivalent
IOSurface APIs in macOS.
2017-02-17 11:43:24 -08:00
wm4 bdbb3142ec client API: adjust opengl_cb hardware decoding comments
Replace the reprecated --hwdec-preload option.

Add a comment about cuvid/cuda decoding.
2017-01-26 11:32:09 +01:00
wm4 c2fdedc2ec client API: correct a comment in the API doxygen 2017-01-08 10:05:07 +01:00
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
wm4 b344da22ae client API: "priority" option is now runtime settable
So it doesn't have to be in the list of options that can be set before
mpv_initialize() only.
2016-09-28 15:26:24 +02: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 9eef41dec1 player: do not let pseudo-gui override user config settings
Seems like this confused users quite often.

Instead of --profile=pseudo-gui, --player-operation-mode=pseudo-gui now
has to be used to invoke pseudo GUI mode. The old way still works, and
still behaves in the old way.
2016-09-23 21:24:50 +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 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