Commit Graph

167 Commits

Author SHA1 Message Date
der richter d954646d29 various: make mentions of macOS consistent
change all mentions and variations of OSX, OS X, MacOSX, MacOS X, etc
consistent. use the official naming macOS.
2024-02-21 20:46:53 +01:00
der richter 0e441525cf vo: make libmpv last in the auto-probing order for cocoa-cb only
this partially reverts commit 7b5a258. back then the only properly
working vo on macOS was cocoa-cb (libmpv). it would always use the
deprecated opengl cocoa backend or no vo at all. because of that libmpv
was moved to the top of the auto-probing order, so the preferred vo
was used on macOS only.

we now have a working vulkan gpu/gpu-next backend on macOS which should
be the new default vo. though disabling the auto-probing again for
libmpv would probably cause the undesired behaviour on macOS that
cocoa-cb would never be auto selected again. especially if not build
with vulkan support or without vulkan driver on macOS, this would lead
to no video output at all. so instead of completely reverting the
mentioned commit, we instead move libmpv to the bottom of the
auto-probing order but only auto select it when mpv was built with
cocoa-cb support. this restores the previous behaviour on all other
platforms besides macOS, but also lets us auto select cocoa-cb if
supported.
2024-02-20 20:42:02 +01:00
Dudemanguy fcebee9080 libmpv: add mpv_time_ns()
9606c3fca9 added mp_time_ns(). Since we
apparently expose the mp_time_us() to clients already, there's no reason
to not also expose the new nanosecond one.
2023-10-10 19:10:55 +00:00
Kacper Michajłow eab3842d8b cplugin: allow loading mpv_* symbols dynamically
Defining MPV_CPLUGIN_DYNAMIC_SYM during plugin compilation will replace mpv_*
functions with function pointers. Those pointer will be initialized when
loading the plugin.

It is recommended to use this symbol table when targeting Windows. The loader
does not have notion of global symbols. Loading cplugin into mpv process will
not allow this plugin to call any of the symbols that may be available in
other modules. Instead cplugin has to link explicitly to specific PE binary,
libmpv-2.dll/mpv.exe or any other binary that may have linked mpv statically.
This limits portability of cplugin as it would need to be compiled separately
for each of target PE binary that includes mpv's symbols. Which in practice
is unrealictis, as we want one cplugin to be loaded without those restrictions.

Instead of linking to any PE binary, we create function pointer for all mpv's
exported symbols. For convinience names of entrypoints are redefined to those
pointer so no changes are required in cplugin source code, except defining
MPV_CPLUGIN_DYNAMIC_SYM. Those function pointer are exported to make them
available for mpv to init with correct values during runtime, before calling
`mpv_open_cplugin`.

Note that those pointer are decorated with `selectany` attribute, so no need
to worry about multiple definitions, linker will keep only single instance.

This fixes cplugin usability on Windows. Without any API changes, only
recompilation with -DMPV_CPLUGIN_DYNAMIC_SYM is needed.
2023-09-20 02:16:45 +00:00
lights0123 f118faed42 DOCS: update LGPL building instructions
previous build system used --enable-lgpl
2023-08-10 11:05:31 +02:00
LaserEyess f2cce5f38f waf: remove waf as a build system
Remove waf entirely in favor of meson as the only supported build
system. Waf was officially deprecated in 0.36.0, and has not been
preferred over meson since 0.35.0.
2023-07-23 19:55:51 +00:00
Sam Van Den Berge b573a4967d libmpv: fix file name in documentation
render_cb.h doesn't exist but render.h does.
2023-04-11 20:06:42 +00:00
rcombs 2cfaa820e5 libmpv: add mpv_del_property() convenience function 2023-01-28 14:20:20 -06:00
Leo Izen 52e7269ea6 misc/random: add xoshiro random number implementation
Add xoshiro as a PRNG implementation instead of relying
on srand() and rand() from the C standard library. This,
in particular, lets us avoid platform-defined behavior with
respect to threading.
2022-08-17 10:21:55 -04:00
Dudemanguy 88120d4759 client API: always export symbols on windows
Windows is weird and symbols weren't actually being exported. This is
because __GNUC__ is defined and picked up in the conditional, but
__attribute__((visibility("default"))) doesn't actually export anything
to the dll. Instead, just check if we have win32 defined first and then
always set __declspec(dllexport). Fixes #10171.
2022-05-11 14:46:41 +00:00
sfan5 f9fd50c654 player: make deprecated track/chapter/metadata events internal
We still need these to track or notify of modifications to certain properties,
but they're now gone from the libmpv ABI.
2021-12-15 12:29:10 +01:00
sfan5 632059816a libmpv: remove opengl_cb API and other deprecated symbols
Not all deprecated symbols were removed. Only three events were removed for now
since these are not used internally.
This bumps the library version to 2.0.
2021-12-15 12:29:10 +01:00
Dudemanguy f08db00d26 client API: also export mpv_client_api_version
20c4036daa switched to using symbol
visibility attributes for mpv client api functions (for the meson build
at least). Unfortunately mpv_client_api_version was mistakenly missed.
We need to export this function as well. Fixes #9531.
2021-11-27 22:46:54 -06:00
Dudemanguy 20c4036daa client API: use symbol visibility attributes
In mpv, the only symbols we want to export are the functions from the
client API. This is accomplised using a specific .def whitelist, but the
main compilers people use (gcc or clang) like these attributes since it
allows for further optimizations. MSVC also allegedly supports this as
well (untested of course), so use __declspec for tht case.
2021-11-19 14:16:41 +00:00
wm4 e27c523a10 command: extend subprocess command stdin, change behavior
Make it possible to feed a string to stdin of a subprocess. Out of
laziness, it can't be an arbitrary byte string. (Would require adding an
option type that takes in a Lua byte string.)

Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore,
because it makes things more consistent. Enabling stdin didn't make too
much sense in the first place, so this behavior change seems
justifiable.

win32 support missing.

Fixes: #8003
2020-08-16 02:54:44 +02:00
Alcaro 57a0b897a2 client API: fix misleading remark 2020-08-13 12:38:15 +02:00
wm4 d5959df2be client API: comment about signal handlers
Sharing a process sure is hard in POSIX.

The rationale is that you'd have to handle EINTR on every single
blocking syscall. stream_file.c does not seem to handle it on read()
calls.

It appears that on most modern systems, this can happen only if you call
sigaction(), and incompetently forget to add SA_RESTART. signal()
usually adds it.
2020-07-20 21:02:17 +02:00
wm4 b93f142011 client API: add software rendering API
This can be used to make vo_libmpv render video to a memory buffer. It
only adds a new backend API that takes memory surfaces. All the render
API (such as frame rendering control and so on) is reused.

I'm not quite convinced of the usefulness of this, and until now I
always resisted providing something like this. It only seems to
facilitate inefficient implementation. But whatever.

Unfortunately, this duplicates the software rendering glue code yet
again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more).
But in theory, these could reuse this backend in the future, just like
vo_gpu could reuse the render_gl API.

Fixes: #7852
2020-07-08 22:42:05 +02:00
wm4 ebac24efe6 client API: correct an outdated comment 2020-05-06 15:27:25 +02:00
wm4 df0d8cda08 client API: report IDs of inserted playlist entries on loading playlist
May or may not help when dealing with playlist loading in scripts. It's
supposed to help with the mean fact that loading a recursive playlist
will essentially edit the playlist behind the API user's back.
2020-03-27 00:57:11 +01:00
wm4 d3be6a6163 client API: another minor clarification for convenience
The previous commit actually makes use of this.
2020-03-27 00:09:51 +01:00
wm4 ca34922130 client API: add a per client unique ID
I mostly intend this for internal purposes. Probably pretty useless for
external API users, but on the other hand trivial to expose. While it
makes a lot of sense internally, I'll probably regret exposing it.
2020-03-26 23:39:35 +01:00
wm4 0405b575d8 client API: update MPV_EVENT_PLAYBACK_RESTART docs
Ordered chapters haven't used user-visible seeks for over 4 years.
2020-03-26 22:51:25 +01:00
wm4 218d6643e9 client API, lua, ipc: unify event struct return
Both Lua and the JSON IPC code need to convert the mpv_event struct (and
everything it points to) to Lua tables or JSON.

I was getting sick of having to make the same changes to Lua and IPC. Do
what has been done everywhere else, and let the core handle this by
going through mpv_node (which is supposed to serve both Lua tables and
JSON, and potentially other scripting language backends). Expose it as
new libmpv API function.

The new API is still a bit "rough" and support for other event types
might be added in the future.

This silently adds support for the playlist_entry_id fields to both Lua
and JSON IPC.

There is a small API change for Lua; I don't think this matters, so I
didn't care about compatibility. The new code in client.c is mashed up
from the Lua and the IPC code. The manpage additions are moved from the
Lua docs, and made slightly more "general".

Some danger for unintended regressions both in Lua and IPC. Also damn
these node functions suck, expect crashes due to UB.

Not sure why this became more code instead of less compared to before
(according to the diff stat), even though some code duplication across
Lua and IPC was removed. Software development sucks.
2020-03-21 19:33:48 +01:00
wm4 7e885a3bc3 client API: add a playlist entry unique ID
This should make dealing with some async. things easier.

It's intentionally not a globally unique ID.
2020-03-21 19:33:03 +01:00
wm4 26ac6ead91 player: fix subtle idle mode differences on early program start
If the user manages to run a "loadfile x append" command before the loop
in mp_play_files() is entered, then the player could start playing
these. This isn't expected, because appending files to the playlist in
idle mode does not normally start playback. It could happen because
there is a short time window where commands are processed before the
loop is entered (such as running the command when a script is loaded).

The idle mode semantics are pretty weird: if files were provided in
advance (on the command line), then these should be played immediately.
But if idle mode was already entered, and something is appended to the
playlist using "append", i.e. without explicitly triggering playback,
then it should remain in idle mode.

Try to follow this by redefining PT_STOP to strictly mean idle mode.
Remove the playlist->current check from idle_loop(), since only the
stop_play field counts now (cf. what mp_set_playlist_entry() does).

This actually introduces the possibility that playlist->current, and
with it playlist-pos, are set to something, even though playback is not
active or being started. Previously, this was only possible during state
transitions, such as when changing playlist entries.

Very annoyingly, this means the current way MPV_EVENT_IDLE was sent
doesn't work anymore. Logically, idle mode can be "active" even if
idle_loop() was not entered yet (between the time after mp_initialize()
and before the loop in mp_play_files()). Instead of worrying about this,
redo the "idle-active" property, and deprecate the event.

See: #7543
2020-03-21 19:32:50 +01:00
wm4 a9e6b9ea36 client API: minor clarification when asynchronous commands send events 2020-02-24 00:09:51 +01:00
wm4 d06ebe2251 client API: document requirement about PID management
Basically, UNIX sucks. (Not as much as the other POS of course.)
2020-02-19 22:16:26 +01:00
wm4 ae0520cafc client API: document srand() use 2020-01-21 17:07:40 +01:00
wm4 0eabc6614a client API: deprecate tick event
This is conceptually outdated and should not exist. This affects Lua
scripting and JSON IPC too.
2019-12-22 14:37:28 +01:00
wm4 ce9d2c9f8e client API: remove comment about error status
mpv_event_property (for property observation) actually never sets an
error status. You cannot distinguish between unavailable properties and
properties which returned an error. Not sure if it ever did.
2019-12-19 11:21:30 +01:00
wm4 0a30a4a432 DOCS: explicitly mention that property observing has an initial event
This is definitely intended from the start, and it's generally useful,
but for some reason it wasn't actually documented.
2019-10-08 21:11:55 +02:00
wm4 49a075d01e DOCS/compatibility.rst: add this file
Another thing nobody will read. I'm attempting to document the rules by
which incompatible changes can be made. These rules have always been
present in this project, but I don't think they were written down. Or
maybe they were, but I forgot where.

I think due to the time of the day it became increasingly incoherent
(not necessarily near the end of the text). Hopefully no logical or
freudian lapses in there.
2019-10-05 02:11:55 +02:00
wm4 e49cec5832 manpage: clarify some details about async. commands and "subprocess"
There's potential confusion about how long a process started with the
"subprocess" command is allowed to live. Add some more explanations
regarding "subprocess" specifics (such as the playback_only field), and
things that apply to asynchronous commands in general.

Partially for #7025.
2019-10-04 16:18:10 +02:00
Aman Gupta c7d0a8f58e stream_cb: add cancel_fn callback
This allows stream_cb backends to implement blocking
behavior inside read_fn, and still get notified when the user
wants to cancel and stop playback.

Signed-off-by: Aman Gupta <aman@tmm1.net>
2019-09-27 13:00:45 -07:00
wm4 4d43c79e4c client API: fix potential deadlock problems by throwing more shit at it
The render API (vo_libmpv) had potential deadlock problems with
MPV_RENDER_PARAM_ADVANCED_CONTROL. This required vd-lavc-dr to be
enabled (the default). I never observed these deadlocks in the wild
(doesn't mean they didn't happen), although I could specifically provoke
them with some code changes.

The problem was mostly about DR (direct rendering, letting the video
decoder write to OpenGL buffer memory). Allocating/freeing a DR image
needs to be done on the OpenGL thread, even though _lots_ of threads are
involved with handling images. Freeing a DR image is a special case that
can happen any time. dr_helper.c does most of the evil magic of
achieving this. Unfortunately, there was a (sort of) circular lock
dependency: freeing an image while certain internal locks are held would
trigger the user's context update callback, which in turn would call
mpv_render_context_update(), which processed all pending free requests,
and then acquire an internal lock - which the caller might not release
until a further DR image could be freed.

"Solve" this by making freeing DR images asynchronous. This is slightly
risky, but actually not much. The DR images will be free'd eventually.
The biggest disadvantage is probably that debugging might get trickier.

Any solution to this problem will probably add images to free to some
sort of queue, and then process it later. I considered making this more
explicit (so there'd be a point where the caller forcibly waits for all
queued items to be free'd), but discarded these ideas as this probably
would only increase complexity.

Another consequence is that freeing DR images on the GL thread is not
synchronous anymore. Instead, it mpv_render_context_update() will do it
with a delay. This seems roundabout, but doesn't actually change
anything, and avoids additional code.

This also fixes that the render API required the render API user to
remain on the same thread, even though this wasn't documented. As such,
it was a bug. OpenGL essentially forces you to do all GL usage on a
single thread, but in theory the API user could for example move the GL
context to another thread.

The API bump is because I think you can't make enough noise about this.
Since we don't backport fixes to old versions, I'm specifically stating
that old versions are broken, and I'm supplying workarounds.

Internally, dr_helper_create() does not use pthread_self() anymore, thus
the vo.c change. I think it's better to make binding to the current
thread as explicit as possible.

Of course it's not sure that this fixes all deadlocks (probably not).
2019-09-26 14:14:49 +02:00
Dark a41f1a21d6 client API: add mpv_command_ret
This change adds a version of `mpv_command` that also returns a result.
The main rationale behind this is `mpv_command_node` requires defining
multiple structs before you can even use it, which results in a pretty
painful to use interface just to get the result from a command.

There isn't really a good name for this function, so I'm open to
suggestions on a better name for it.
2019-09-21 14:24:42 +02:00
wm4 e60bcf0d98 client API: fix some comments 2019-09-19 20:37:05 +02:00
Anton Kindestam e08f235578 drm: fix libmpv ABI breakage introduced in 351c083487
Extending the client-allocated mpv_opengl_drm_params struct
constituted a break of ABI that could cause UB.

Create a clean break by deprecating "drm_params" and related structs
and enum values, and replacing it with "drm_params_v2".

Also fix some comments and code that wrongly assumed that open could
return any other negative number than -1 for failure.

This commit updates the libmpv version to 1.104
2019-09-18 23:59:32 +03:00
Anton Kindestam 8b83c89966 Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into wm4-commits--merge-edition
This bumps libmpv version to 1.103
2018-12-05 19:19:24 +01:00
Anton Kindestam f0509d3738 drm: rename plane options to better, invariant, names
This commit bumps the libmpv version to 1.102

drm-osd-plane -> drm-draw-plane
drm-video-plane -> drm-drmprime-video-plane
drm-osd-size -> drm-draw-surface-size

"draw plane", as in the plane that OpenGL draws to, whether it be
video + OSD or just OSD.

"drmprime video plane", as in the plane used for hwdec video imported
via drmprime.

"draw surface size", as in the size of the surface used for the draw plane

The new names are invariant whether or not hwdec_drmprime_drm is being
used or not. The original naming was very confusing, as when doing
regular rendering (swdec or vaapi) the video would be displayed on the
"OSD plane", and the "Video plane" would remain unused.
2018-12-01 15:42:20 +02:00
wm4 332907e1d7 command: give named arguments to almost all commands
Before this change, only 1 command or so had named arguments. There is
no reason why other commands can't have them, except that it's a bit of
work to add them.

Commands with variable number of arguments are inherently incompatible
to named arguments, such as the "run" command. They still have dummy
names, but obviously you can't assign multiple values to a single named
argument (unless the argument has an array type, which would be
something different). For now, disallow using named argument APIs with
these commands. This might change later.

2 commands are adjusted to not need a separate default value by changing
flag constants. (The numeric values are C only and can't be set by
users.)

Make the command syntax in the manpage more consistent. Now none of the
allowed choice/flag names are in the command header, and all arguments
are shown with their proper name and quoted with <...>.

Some places in the manpage and the client.h doxygen are updated to
reflect that most commands support named arguments. In addition, try to
improve the documentation of the syntax and need for escaping etc. as
well.

(Or actually most uses of the word "argument" should be "parameter".)
2018-05-24 19:56:34 +02:00
wm4 e4fb23ed7d command: add a way to abort asynchronous commands
Many asynchronous commands are potentially long running operations, such
as loading something from network or running a foreign process.
Obviously it shouldn't just be possible for them to freeze the player if
they don't terminate as expected. Also, there will be situations where
you want to explicitly stop some of those operations explicitly. So add
an infrastructure for this.

Commands have to support this explicitly. The next commit uses this to
actually add support to a command.
2018-05-24 19:56:34 +02:00
wm4 1aae88b487 input: add glue code for named arguments
Named arguments should make it easier to have long time compatibility,
even if command arguments get added or removed. They're also much nicer
for commands with a large number of arguments, especially if many
arguments are optional.

As of this commit, this can not be used, because there is no command yet
which supports them. See the following commit.
2018-05-24 19:56:34 +02:00
wm4 f0678afba0 client API: add returning of data from async commands
This was not done sooner out of laziness.
2018-05-24 19:56:34 +02:00
wm4 005d3bc81a client API: clarify asynchronous call ordering non-guarantees
Both asynchronous and synchronous calls used to be put into the core's
dispatch queue. Also, asynchronous calls were actually synchronous, just
without forcing a wait on the client's thread. This meant that both
kinds of calls were always strictly ordered.

A longer time ago, synchronous calls were changed to simply lock the
core. This could possibly lead to reordering. Recently, some commands
were changed to run on worker threads, which made the order even looser.

Also remove another now incorrect doxygen comment regarding async
commands.
2018-05-24 19:56:34 +02:00
wm4 95ab93d9f1 client API: some doxygen fixes/additions 2018-05-24 19:56:33 +02: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 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