On my system, when trying to use mpv with a read-only fd created by
python 3.7, `send` triggers ENOTSOCK, not EBADF. Extend the logic to
detect non-writable fds by this `errno`.
The `strncpy` function will not always place a terminating `NUL` if the
source is longer than the destination buffer. Instead, let `strncpy`
truncate as it normally would, but leave the last byte alone (it is
zero-initialized when declared).
This flag is used only by the command parser. Its value overlapped with
some of the existing m_option flags, but only flags that did not matter
for the command parser (i.e. the flag bits used had mostly private uses
in each component). It's still a bit unclean and dangerous to use an
essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it.
Since M_OPT_OPTIONAL_PARAM has a slightly longer name than
MP_CMD_OPT_ARG, I'm going to keep the old name.
The only effective difference is that the former explicitly checks
whether the JSON value type is string, and errors out if not. The rest
is exactly the same (mpv_set_property_string is mpv_set_property with
MPV_FORMAT_STRING).
It seems silly to keep this, so just remove it.
This was always a legacy thing. Remove it by applying an orgy of
mp_get_config_group() calls, and sometimes m_config_cache_alloc() or
mp_read_option_raw().
win32 changes untested.
Until now, they could be aborted only by ending playback, and calling
mpv_abort_async_command didn't do anything.
This requires furthering the mess how playback abort is done. The main
reason why mp_cancel exists at all is to avoid that a "frozen" demuxer
(blocked on network I/O or whatever) cannot freeze the core. The core
should always get its way. Previously, there was a single mp_cancel
handle, that could be signaled, and all demuxers would unfreeze. With
external files, we might want to abort loading of a certain external
file, which automatically means they need a separate mp_cancel. So give
every demuxer its own mp_cancel, and "slave" it to whatever parent
mp_cancel handles aborting.
Since the mpv demuxer API conflates creating the demuxer and reading the
file headers, mp_cancel strictly need to be created before the demuxer
is created (or we couldn't abort loading). Although we give every
demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer),
it's still rather messy to create/destroy it along with the demuxer.
This flag is used only by the command parser. Its value overlapped with
some of the existing m_option flags, but only flags that did not matter
for the command parser (i.e. the flag bits used had mostly private uses
in each component). It's still a bit unclean and dangerous to use an
essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it.
Since M_OPT_OPTIONAL_PARAM has a slightly longer name than
MP_CMD_OPT_ARG, I'm going to keep the old name.
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".)
I wanted to put all commands through mpv_command_node_async() instead of
mpv_command_node(). Using synchronous commands over a synchronous
transport doesn't make sense anyway.
This would have used the request_id field in IPC requests as reply ID
for the async commands. But the latter need to be [u]int64, while the
former can be any type. To avoid that we need an extra lookup table for
mapping reply IDs to request_id values, we now require that request_id
fields are integers.
Since this would be an incompatible change, just deprecate non-integers
for now, and plan the change for a later time.
The only effective difference is that the former explicitly checks
whether the JSON value type is string, and errors out if not. The rest
is exactly the same (mpv_set_property_string is mpv_set_property with
MPV_FORMAT_STRING).
It seems silly to keep this, so just remove it.
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.
This supports named arguments. It benefits from the infrastructure of
async commands.
The plan is to reimplement Lua's utils.subprocess() on top of it.
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.
This enables two types of command behavior:
1. Plain async behavior, like "loadfile" not completing until the file
is fully loaded.
2. Running parts of the command on worker threads, e.g. for I/O, such as
"sub-add" doing network accesses on a thread while the core
continues.
Both have no implementation yet, and most new code is actually inactive.
The plan is to implement a number of useful cases in the following
commits.
The most tricky part is handling internal keybindings (input.conf) and
the multi-command feature (concatenating commands with ";"). It requires
a bunch of roundabout code to make it do the expected thing in
combination with async commands.
There is the question how commands should be handled that come in at a
higher rate than what can be handled by the core. Currently, it will
simply queue up input.conf commands as long as memory lasts. The client
API is limited by the size of the reply queue per client. For commands
which require a worker thread, the thread pool is limited to 30 threads,
and then will queue up work in memory. The number is completely
arbitrary.
This gets rid of run_command() and its big switch statement, which was
an idiotically big function of almost 1000 lines.
The switch is replaced with a callback per command, and each command is
now implemented in its own function. Command IDs are not needed anymore,
so the mp_command_type enum disappears.
There should be no functional changes, but since this refactors 64
commands, regressions are possible.
The handler() parameter is void*, because in theory the input code is
supposed to be independent of the player core code. For example, you
should be able to reuse the command parser code for some other part of
mpv. In practice, the variable containing command list is defined in the
player core anyway, so you could say this doesn't work. But I'm still
trying to hold onto this idea, so I went with void*.
The plan is to remove the command ID enum. This will happen by replacing
the big switch statement in command.c with dispatching to per-command
callbacks. As preparation, remove uses of the command IDs outside of the
actual dispatching mechanism.
Also remove some instances of checking cmd->def for NULL. We now require
this always to be set.
These are old MPlayer commands that were redundant since 2007 or so. In
2013, mpv explicitly deprecated them (actually removed them, but left
this wrapper, which translated them to modern commands). The list was
not extended since 2013, and mpv always warned on the terminal when a
legacy command was used. So it's time to remove it.
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.
Requested. See manpage additions.
The main reason why this goes through the trouble to keep the
action/operation parameter separate is so that we don't expose some
option parser implementation details to the command (although that is a
relatively weak reason), and also to make it more different from the
"set" command, which can't support this type of option as it goes
through the property layer.
Fixes#5435.
It was actually already implemented as ta_dup_ptrtype(), but that seems
like a clunky name. Also we still use the talloc_ names throughout the
source, and I'd rather use an old name instead of a mixing inconsistent
naming conventions.
Replace the static array with dynamic memory allocation. This also
requires some code to honor mp_cmd.nargs more strictly. Generally
allocates more stuff.
Fixes#5375 (although we could also just raise the static limit).
I've decided that MP_TRACE means “noisy spam per frame”, whereas
MP_DBG just means “more verbose debugging messages than MSGL_V”.
Basically, MSGL_DBG shouldn't create spam per frame like it currently
does, and MSGL_V should make sense to the end-user and provide mostly
additional informational output.
MP_DBG is basically what I want to make the new default for --log-file,
so the cut-off point for MP_DBG is if we probably want to know if for
debugging purposes but the user most likely doesn't care about on the
terminal.
Also, the debug callbacks for libass and ffmpeg got bumped in their
verbosity levels slightly, because being external components they're a
bit less relevant to mpv debugging, and a bit too over-eager in what
they consider to be relevant information.
I exclusively used the "try it on my machine and remove messages from
MSGL_* until it does what I want it to" approach of refactoring, so
YMMV.
This was marked GPL, because the implementation in command.c (which is
shared with the subtitle code) was marked as GPL. This has been changed,
so this is unnecessary. The original commands for external audio tracks
have been added to mpv by someone who agreed with the relicensing.
There has been no new developments or agreements, but I was uncertain
about the copyright status of them. Thus this part of code was marked as
being potentially GPL, and was not built in LGPL mode. Now I've taken a
close look again, and decided that these can be relicensed using the
existing relicensing agreements.
OSD level 3 was introduced in commit 8d190244, with the author being
unreachable. As I decided in commit 6ddd95fd, OSD level 3 itself can
be kept, but the "osd" command had to go, and the "rendering" of OSD
level 3 (the HAVE_GPL code in osd.c) was uncertain. But the code for
this was rewritten: instead of duplicating the time/percent formatting
code, it was changed to use common code, and some weird extra logic was
removed. The code inside of the "if" is exactly the same as the code
that formats the OSD status line (covered by LGPL relicensing).
The current commands for adding/removing sub/audio tracks more or less
originated from commit 2f376d1b39, with the author being unreachable.
But the original code was very different, mostly due to MPlayer's
incredibly messy handling of subtitles in general. Nothing of this
remains in the current code. Even the command declarations were
rewritten. The commands (as seen from the user side) are rather similar
in naming and semantics, but we don't consider this copyrightable. So it
doesn't look like anything copyrightable is left.
The add/cycle commands were more or less based on step_property,
introduced in commit 7a71da01d6, with the patch author disagreeing with
the LGPL relicensing. But all code original to the patch has been
replaced in later mpv changes, and the original code was mostly copied
from MP_CMD_SET_PROPERTY anyway. The underlying property interface was
completely changed, the error handling was redone, and all of this is
very similar to the changes that were done on SET_PROPERTY. The command
declarations are completely different in the first place, because the
semantic change from step to add/cycle. The commit also seems to have
been co-authored by reimar to some degree. He also had the idea to
change the original patch from making the command modify a specific
property to making it generic.
(The error message line, especially with its %g formatting, might
contain some level of originality, so change that just to be sure.
This commit Copies and adapts the error message for SET_PROPERTY.)
Although I'm a bit on the fence with all the above things, it really
doesn't look like there's anything substantial that would cause issues.
I thus claim that there is no problem with changing the license to LGPL
for the above things. It's probably still slightly below the standard
that was usually applied in the code relicensing in mpv, but probably
still far above to the usual in open source relicensing (and above
commercial standards as well, if you look what certain tech giants do).
See "Copyright" file for caveats.
This changes the remaining "almost LGPL" files to LGPL, because we think
that the conditions the author set for these was finally fulfilled.
Anton Kindestam
Niklas Haas
Ben Boeckel
wm4
sfan5
Martin Shirokov
James Ross-Gowan