For some inexplicable reason, the OSC runs the expand-text command a
_lot_. This command is logged at the log file default log level, so the
log file can quickly fill up with these messages. It directly violates
the mpv logging policy: per-frame (or similarly common) log messages
should not be enabled by default for the log file.
stats.lua uses the show-text command for some reason (instead of
creating its own OSD layer).
Explicitly reduce the log level for expand-text and some other commands.
Also reduce the log level for commands triggered by mouse movement.
The previous commit also contributed some to reduce log spam.
Fixes: #4771
This is supposed to turn input.conf comments into inline documentation.
Whether this will be useful depends on whether there'll be a script
using this field.
This changes a small aspect of input.conf parsing fundamentally: this
attempts to strip comments/whitespace from the command string, which
will later be used to generate the command when a key binding is
executed. This should not have any negative effects, but there could be
unknown bugs. (For some reason, every command is parsed when input.conf
is parsed, but it still only stores the string for the command. I guess
that saves some minor amount of memory.)
No reason to have this as bstr, just makes everything more complex.
Also clear mp_cmd.sender when it's copied. Otherwise it would be a
dangling pointer. Apparently it's never set to non-NULL in this
situation, but this is cleaner anyway.
Particularly for "any_unicode" mappings, so they don't have to
special-case keys like '#' and ' ', which are normally mapped to
symbolic names for input.conf reasons. (Though admittedly, this is a
pretty minor thing, since API users could map these manually.)
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.
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.
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.
wm4