2014-11-29 19:53:24 +00:00
|
|
|
COMMAND INTERFACE
|
|
|
|
=================
|
|
|
|
|
|
|
|
The mpv core can be controlled with commands and properties. A number of ways
|
|
|
|
to interact with the player use them: key bindings (``input.conf``), OSD
|
|
|
|
(showing information with properties), JSON IPC, the client API (``libmpv``),
|
|
|
|
and the classic slave mode.
|
|
|
|
|
|
|
|
input.conf
|
|
|
|
----------
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
The input.conf file consists of a list of key bindings, for example::
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
s screenshot # take a screenshot with the s key
|
2014-08-11 21:32:37 +00:00
|
|
|
LEFT seek 15 # map the left-arrow key to seeking forward by 15 seconds
|
2012-09-27 01:20:12 +00:00
|
|
|
|
|
|
|
Each line maps a key to an input command. Keys are specified with their literal
|
|
|
|
value (upper case if combined with ``Shift``), or a name for special keys. For
|
|
|
|
example, ``a`` maps to the ``a`` key without shift, and ``A`` maps to ``a``
|
|
|
|
with shift.
|
|
|
|
|
2014-10-03 09:18:48 +00:00
|
|
|
The file is located in the mpv configuration directory (normally at
|
|
|
|
``~/.config/mpv/input.conf`` depending on platform). The default bindings are
|
|
|
|
defined here::
|
2014-08-02 04:57:36 +00:00
|
|
|
|
|
|
|
https://github.com/mpv-player/mpv/blob/master/etc/input.conf
|
|
|
|
|
2012-09-27 01:20:12 +00:00
|
|
|
A list of special keys can be obtained with
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``mpv --input-keylist``
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
In general, keys can be combined with ``Shift``, ``Ctrl`` and ``Alt``::
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
ctrl+q quit
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2012-10-23 23:06:00 +00:00
|
|
|
**mpv** can be started in input test mode, which displays key bindings and the
|
2013-07-08 16:02:14 +00:00
|
|
|
commands they're bound to on the OSD, instead of executing the commands::
|
2012-10-23 23:06:00 +00:00
|
|
|
|
2014-04-18 14:37:27 +00:00
|
|
|
mpv --input-test --force-window --idle
|
2012-10-23 23:06:00 +00:00
|
|
|
|
2014-04-18 14:37:27 +00:00
|
|
|
(Only closing the window will make **mpv** exit, pressing normal keys will
|
|
|
|
merely display the binding, even if mapped to quit.)
|
2012-10-23 23:06:00 +00:00
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
General Input Command Syntax
|
2012-09-27 01:20:12 +00:00
|
|
|
----------------------------
|
|
|
|
|
2013-07-08 17:27:45 +00:00
|
|
|
``[Shift+][Ctrl+][Alt+][Meta+]<key> [{<section>}] [<prefixes>] <command> (<argument>)* [; <command>]``
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-12-01 05:23:39 +00:00
|
|
|
Note that by default, the right Alt key can be used to create special
|
|
|
|
characters, and thus does not register as a modifier. The option
|
2014-04-24 15:27:27 +00:00
|
|
|
``--no-input-right-alt-gr`` changes this behavior.
|
2013-12-01 05:23:39 +00:00
|
|
|
|
2012-09-27 01:20:12 +00:00
|
|
|
Newlines always start a new binding. ``#`` starts a comment (outside of quoted
|
|
|
|
string arguments). To bind commands to the ``#`` key, ``SHARP`` can be used.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``<key>`` is either the literal character the key produces (ASCII or Unicode
|
2013-09-10 13:09:24 +00:00
|
|
|
character), or a symbolic name (as printed by ``--input-keylist``).
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``<section>`` (braced with ``{`` and ``}``) is the input section for this
|
|
|
|
command.
|
2013-06-23 00:31:51 +00:00
|
|
|
|
2012-09-27 01:20:12 +00:00
|
|
|
Arguments are separated by whitespace. This applies even to string arguments.
|
|
|
|
For this reason, string arguments should be quoted with ``"``. Inside quotes,
|
2013-07-08 16:02:14 +00:00
|
|
|
C-style escaping can be used.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 17:27:45 +00:00
|
|
|
You can bind multiple commands to one key. For example:
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
| a show-text "command 1" ; show-text "command 2"
|
2013-07-08 17:27:45 +00:00
|
|
|
|
2014-04-18 14:27:02 +00:00
|
|
|
It's also possible to bind a command to a sequence of keys:
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
| a-b-c show-text "command run after a, b, c have been pressed"
|
2014-04-18 14:27:02 +00:00
|
|
|
|
|
|
|
(This is not shown in the general command syntax.)
|
|
|
|
|
2014-04-19 12:21:57 +00:00
|
|
|
If ``a`` or ``a-b`` or ``b`` are already bound, this will run the first command
|
|
|
|
that matches, and the multi-key command will never be called. Intermediate keys
|
|
|
|
can be remapped to ``ignore`` in order to avoid this issue. The maximum number
|
|
|
|
of (non-modifier) keys for combinations is currently 4.
|
2014-04-18 14:27:02 +00:00
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
List of Input Commands
|
2012-09-27 01:20:12 +00:00
|
|
|
----------------------
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``ignore``
|
2012-09-27 01:20:12 +00:00
|
|
|
Use this to "block" keys that should be unbound, and do nothing. Useful for
|
|
|
|
disabling default bindings, without disabling all bindings with
|
options: drop --opt:subopt option names
For all suboptions, "flat" options were available by separating the
parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop
this syntax and use "-" as separator. This means even suboptions are
available as normal options now, e.g. "--rawvideo-w=123". The old syntax
doesn't work anymore.
Note that this is completely separate from actual suboptions. For
example, "-rawvideo w=123:h=123" still works. (Not that this syntax is
worth supporting, but it's needed anyway, for for other things like vf
and vo suboptions.)
As a consequence of this change, we also have to add new "no-" prefixed
options for flag suboptions, so that "--no-input-default-bindings"
works. ("--input-no-default-bindings" also works as a consequence of
allowing "-input no-default-bindings" - they are handled by the same
underlying option.)
For --input, always use the full syntax in the manpage. There exist
suboptions other than --input (like --tv, --rawvideo, etc.), but since
they might be handled differently in the future, don't touch these yet.
M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated
cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in
some places.
Unrelated: remove the duplicated --tv:buffersize option, fix a typo in
changes.rst.
2013-02-21 21:10:21 +00:00
|
|
|
``--no-input-default-bindings``.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2015-05-18 20:56:56 +00:00
|
|
|
``seek <seconds> [relative|absolute|absolute-percent|relative-percent|exact|keyframes]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Change the playback position. By default, seeks by a relative amount of
|
|
|
|
seconds.
|
|
|
|
|
2015-03-04 16:21:02 +00:00
|
|
|
The second argument consists of flags controlling the seek mode:
|
2012-09-27 01:20:12 +00:00
|
|
|
|
|
|
|
relative (default)
|
|
|
|
Seek relative to current position (a negative value seeks backwards).
|
|
|
|
absolute
|
2016-10-01 18:51:17 +00:00
|
|
|
Seek to a given time (a negative value starts from the end of the file).
|
2012-09-27 01:20:12 +00:00
|
|
|
absolute-percent
|
2012-10-23 23:06:00 +00:00
|
|
|
Seek to a given percent position.
|
2015-05-18 20:56:56 +00:00
|
|
|
relative-percent
|
|
|
|
Seek relative to current position in percent.
|
2012-09-27 01:20:12 +00:00
|
|
|
keyframes
|
|
|
|
Always restart playback at keyframe boundaries (fast).
|
2015-03-04 16:21:02 +00:00
|
|
|
exact
|
|
|
|
Always do exact/hr/precise seeks (slow).
|
|
|
|
|
|
|
|
Multiple flags can be combined, e.g.: ``absolute+keyframes``.
|
|
|
|
|
|
|
|
By default, ``keyframes`` is used for relative seeks, and ``exact`` is used
|
|
|
|
for absolute seeks.
|
|
|
|
|
|
|
|
Before mpv 0.9, the ``keyframes`` and ``exact`` flags had to be passed as
|
|
|
|
3rd parameter (essentially using a space instead of ``+``). The 3rd
|
|
|
|
parameter is still parsed, but is considered deprecated.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``revert-seek [mode]``
|
2013-12-01 01:07:32 +00:00
|
|
|
Undoes the ``seek`` command, and some other commands that seek (but not
|
|
|
|
necessarily all of them). Calling this command once will jump to the
|
|
|
|
playback position before the seek. Calling it a second time undoes the
|
2015-05-25 19:59:44 +00:00
|
|
|
``revert-seek`` command itself. This only works within a single file.
|
2014-12-17 21:56:45 +00:00
|
|
|
|
|
|
|
The first argument is optional, and can change the behavior:
|
|
|
|
|
|
|
|
mark
|
2015-05-25 19:59:44 +00:00
|
|
|
Mark the current time position. The next normal ``revert-seek`` command
|
2014-12-17 21:56:45 +00:00
|
|
|
will seek back to this point, no matter how many seeks happened since
|
|
|
|
last time.
|
|
|
|
|
|
|
|
Using it without any arguments gives you the default behavior.
|
2013-12-01 01:07:32 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``frame-step``
|
2014-08-03 18:25:03 +00:00
|
|
|
Play one frame, then pause. Does nothing with audio-only playback.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``frame-back-step``
|
core: add backstep support
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
2013-04-24 17:31:48 +00:00
|
|
|
Go back by one frame, then pause. Note that this can be very slow (it tries
|
|
|
|
to be precise, not fast), and sometimes fails to behave as expected. How
|
|
|
|
well this works depends on whether precise seeking works correctly (e.g.
|
|
|
|
see the ``--hr-seek-demuxer-offset`` option). Video filters or other video
|
2014-09-01 02:25:57 +00:00
|
|
|
post-processing that modifies timing of frames (e.g. deinterlacing) should
|
core: add backstep support
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
2013-04-24 17:31:48 +00:00
|
|
|
usually work, but might make backstepping silently behave incorrectly in
|
2014-05-07 20:01:17 +00:00
|
|
|
corner cases. Using ``--hr-seek-framedrop=no`` should help, although it
|
|
|
|
might make precise seeking slower.
|
core: add backstep support
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
2013-04-24 17:31:48 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
This does not work with audio-only playback.
|
core: add backstep support
Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.
This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.
This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.
There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)
Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.
2013-04-24 17:31:48 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``set <property> "<value>"``
|
2012-09-27 01:20:12 +00:00
|
|
|
Set the given property to the given value.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``add <property> [<value>]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Add the given value to the property. On overflow or underflow, clamp the
|
2013-07-08 16:02:14 +00:00
|
|
|
property to the maximum. If ``<value>`` is omitted, assume ``1``.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``cycle <property> [up|down]``
|
2012-10-12 07:21:26 +00:00
|
|
|
Cycle the given property. ``up`` and ``down`` set the cycle direction. On
|
2012-09-27 01:20:12 +00:00
|
|
|
overflow, set the property back to the minimum, on underflow set it to the
|
2012-10-12 07:21:26 +00:00
|
|
|
maximum. If ``up`` or ``down`` is omitted, assume ``up``.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-10-31 22:23:38 +00:00
|
|
|
``multiply <property> <factor>``
|
|
|
|
Multiplies the value of a property with the numeric factor.
|
|
|
|
|
2017-03-15 18:40:39 +00:00
|
|
|
``screenshot [subtitles|video|window|single|each-frame]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Take a screenshot.
|
|
|
|
|
2017-03-15 18:40:39 +00:00
|
|
|
Multiple flags are available (some can be combined with ``+``):
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2012-10-20 21:58:02 +00:00
|
|
|
<subtitles> (default)
|
|
|
|
Save the video image, in its original resolution, and with subtitles.
|
|
|
|
Some video outputs may still include the OSD in the output under certain
|
|
|
|
circumstances.
|
|
|
|
<video>
|
|
|
|
Like ``subtitles``, but typically without OSD or subtitles. The exact
|
|
|
|
behavior depends on the selected video output.
|
|
|
|
<window>
|
2012-10-21 10:33:18 +00:00
|
|
|
Save the contents of the mpv window. Typically scaled, with OSD and
|
2012-10-20 21:58:02 +00:00
|
|
|
subtitles. The exact behavior depends on the selected video output, and
|
|
|
|
if no support is available, this will act like ``video``.
|
2012-09-27 01:20:12 +00:00
|
|
|
<each-frame>
|
|
|
|
Take a screenshot each frame. Issue this command again to stop taking
|
2014-09-01 02:25:57 +00:00
|
|
|
screenshots. Note that you should disable frame-dropping when using
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 21:33:33 +00:00
|
|
|
this mode - or you might receive duplicate images in cases when a
|
2015-03-04 16:21:02 +00:00
|
|
|
frame was dropped. This flag can be combined with the other flags,
|
2015-03-05 11:41:43 +00:00
|
|
|
e.g. ``video+each-frame``.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2017-03-15 18:40:39 +00:00
|
|
|
Older mpv versions required passing ``single`` and ``each-frame`` as
|
|
|
|
second argument (and did not have flags). This syntax is still understood,
|
|
|
|
but deprecated and might be removed in the future.
|
|
|
|
|
player: make screenshot commands honor the async flag
And also change input.conf to make all screenshots async. (Except the
every-frame mode, which always uses synchronous mode and ignores the
flag.) By default, the "screenshot" command is still asynchronous,
because scripts etc. might depend on this behavior.
This is only partially async. The code for determining the filename is
still always run synchronously. Only encoding the screenshot and writing
it to disk is asynchronous. We explicitly document the exact behavior as
undefined, so it can be changed any time.
Some of this is a bit messy, because I wanted to avoid duplicating the
message display code between sync and async mode. In async mode, this is
called from a worker thread, which is not safe because showing a message
accesses the thread-unsafe OSD code. So the core has to be locked during
this, which implies accessing the core and all that. So the code has
weird locking calls, and we need to do core destruction in a more
"controlled" manner (thus the outstanding_async field).
(What I'd really want would be the OSD simply showing log messages
instead.)
This is pretty untested, so expect bugs.
Fixes #4250.
2017-04-01 18:45:20 +00:00
|
|
|
Setting the ``async`` flag will make encoding and writing the actual image
|
|
|
|
file asynchronous in most cases. (``each-frame`` mode ignores this flag
|
|
|
|
currently.) Requesting async screenshots too early or too often could lead
|
|
|
|
to the same filenames being chosen, and overwriting each others in undefined
|
|
|
|
order.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``screenshot-to-file "<filename>" [subtitles|video|window]``
|
2013-07-08 18:34:26 +00:00
|
|
|
Take a screenshot and save it to a given file. The format of the file will
|
|
|
|
be guessed by the extension (and ``--screenshot-format`` is ignored - the
|
|
|
|
behavior when the extension is missing or unknown is arbitrary).
|
|
|
|
|
|
|
|
The second argument is like the first argument to ``screenshot``.
|
|
|
|
|
2015-04-16 20:06:47 +00:00
|
|
|
If the file already exists, it's overwritten.
|
2013-07-08 18:34:26 +00:00
|
|
|
|
|
|
|
Like all input command parameters, the filename is subject to property
|
|
|
|
expansion as described in `Property Expansion`_.
|
|
|
|
|
player: make screenshot commands honor the async flag
And also change input.conf to make all screenshots async. (Except the
every-frame mode, which always uses synchronous mode and ignores the
flag.) By default, the "screenshot" command is still asynchronous,
because scripts etc. might depend on this behavior.
This is only partially async. The code for determining the filename is
still always run synchronously. Only encoding the screenshot and writing
it to disk is asynchronous. We explicitly document the exact behavior as
undefined, so it can be changed any time.
Some of this is a bit messy, because I wanted to avoid duplicating the
message display code between sync and async mode. In async mode, this is
called from a worker thread, which is not safe because showing a message
accesses the thread-unsafe OSD code. So the core has to be locked during
this, which implies accessing the core and all that. So the code has
weird locking calls, and we need to do core destruction in a more
"controlled" manner (thus the outstanding_async field).
(What I'd really want would be the OSD simply showing log messages
instead.)
This is pretty untested, so expect bugs.
Fixes #4250.
2017-04-01 18:45:20 +00:00
|
|
|
The ``async`` flag has an effect on this command (see ``screenshot``
|
|
|
|
command).
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``playlist-next [weak|force]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Go to the next entry on the playlist.
|
|
|
|
|
|
|
|
weak (default)
|
|
|
|
If the last file on the playlist is currently played, do nothing.
|
|
|
|
force
|
|
|
|
Terminate playback if there are no more files on the playlist.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``playlist-prev [weak|force]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Go to the previous entry on the playlist.
|
|
|
|
|
|
|
|
weak (default)
|
|
|
|
If the first file on the playlist is currently played, do nothing.
|
|
|
|
force
|
|
|
|
Terminate playback if the first file is being played.
|
|
|
|
|
2014-10-28 09:18:46 +00:00
|
|
|
``loadfile "<file>" [replace|append|append-play [options]]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Load the given file and play it.
|
|
|
|
|
|
|
|
Second argument:
|
|
|
|
|
|
|
|
<replace> (default)
|
|
|
|
Stop playback of the current file, and play the new file immediately.
|
|
|
|
<append>
|
|
|
|
Append the file to the playlist.
|
2014-07-22 22:20:53 +00:00
|
|
|
<append-play>
|
|
|
|
Append the file, and if nothing is currently playing, start playback.
|
2014-10-28 09:18:46 +00:00
|
|
|
(Always starts with the added file, even if the playlist was not empty
|
|
|
|
before running this command.)
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2014-02-24 22:59:51 +00:00
|
|
|
The third argument is a list of options and values which should be set
|
|
|
|
while the file is playing. It is of the form ``opt1=value1,opt2=value2,..``.
|
|
|
|
Not all options can be changed this way. Some options require a restart
|
|
|
|
of the player.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``loadlist "<playlist>" [replace|append]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Load the given playlist file (like ``--playlist``).
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``playlist-clear``
|
2012-09-27 01:20:12 +00:00
|
|
|
Clear the playlist, except the currently played file.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``playlist-remove current|<index>``
|
2013-07-02 11:17:50 +00:00
|
|
|
Remove the playlist entry at the given index. Index values start counting
|
2013-11-28 18:13:48 +00:00
|
|
|
with 0. The special value ``current`` removes the current entry. Note that
|
|
|
|
removing the current entry also stops playback and starts playing the next
|
|
|
|
entry.
|
2013-07-02 11:17:50 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``playlist-move <index1> <index2>``
|
2013-07-02 11:17:50 +00:00
|
|
|
Move the playlist entry at index1, so that it takes the place of the
|
|
|
|
entry index2. (Paradoxically, the moved playlist entry will not have
|
|
|
|
the index value index2 after moving if index1 was lower than index2,
|
|
|
|
because index2 refers to the target entry, not the index the entry
|
|
|
|
will have after moving.)
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``playlist-shuffle``
|
2015-05-17 19:16:10 +00:00
|
|
|
Shuffle the playlist. This is similar to what is done on start if the
|
|
|
|
``--shuffle`` option is used.
|
|
|
|
|
2013-11-29 22:36:44 +00:00
|
|
|
``run "command" "arg1" "arg2" ...``
|
|
|
|
Run the given command. Unlike in MPlayer/mplayer2 and earlier versions of
|
|
|
|
mpv (0.2.x and older), this doesn't call the shell. Instead, the command
|
|
|
|
is run directly, with each argument passed separately. Each argument is
|
|
|
|
expanded like in `Property Expansion`_. Note that there is a static limit
|
2014-05-11 13:42:12 +00:00
|
|
|
of (as of this writing) 9 arguments (this limit could be raised on demand).
|
2013-11-29 22:36:44 +00:00
|
|
|
|
2013-12-14 18:56:02 +00:00
|
|
|
The program is run in a detached way. mpv doesn't wait until the command
|
|
|
|
is completed, but continues playback right after spawning it.
|
|
|
|
|
2013-11-29 22:36:44 +00:00
|
|
|
To get the old behavior, use ``/bin/sh`` and ``-c`` as the first two
|
|
|
|
arguments.
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
``run "/bin/sh" "-c" "echo ${title} > /tmp/playing"``
|
|
|
|
|
|
|
|
This is not a particularly good example, because it doesn't handle
|
|
|
|
escaping, and a specially prepared file might allow an attacker to
|
|
|
|
execute arbitrary shell commands. It is recommended to write a small
|
|
|
|
shell script, and call that with ``run``.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``quit [<code>]``
|
2014-05-22 19:28:20 +00:00
|
|
|
Exit the player. If an argument is given, it's used as process exit code.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``quit-watch-later [<code>]``
|
core: add playback resume feature (manual/opt-in)
A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
2013-05-05 17:37:29 +00:00
|
|
|
Exit player, and store current playback position. Playing that file later
|
2014-05-22 19:28:20 +00:00
|
|
|
will seek to the previous position on start. The (optional) argument is
|
|
|
|
exactly as in the ``quit`` command.
|
core: add playback resume feature (manual/opt-in)
A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
2013-05-05 17:37:29 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``sub-add "<file>" [<flags> [<title> [<lang>]]]``
|
2014-09-05 00:42:25 +00:00
|
|
|
Load the given subtitle file. It is selected as current subtitle after
|
2012-09-27 01:20:12 +00:00
|
|
|
loading.
|
|
|
|
|
2014-10-20 21:55:29 +00:00
|
|
|
The ``flags`` args is one of the following values:
|
|
|
|
|
|
|
|
<select>
|
|
|
|
|
|
|
|
Select the subtitle immediately.
|
|
|
|
|
|
|
|
<auto>
|
|
|
|
|
|
|
|
Don't select the subtitle. (Or in some special situations, let the
|
|
|
|
default stream selection mechanism decide.)
|
|
|
|
|
2014-10-23 11:11:41 +00:00
|
|
|
<cached>
|
|
|
|
|
|
|
|
Select the subtitle. If a subtitle with the same filename was already
|
|
|
|
added, that one is selected, instead of loading a duplicate entry.
|
|
|
|
(In this case, title/language are ignored, and if the was changed since
|
|
|
|
it was loaded, these changes won't be reflected.)
|
|
|
|
|
2014-10-20 21:55:29 +00:00
|
|
|
The ``title`` argument sets the track title in the UI.
|
|
|
|
|
|
|
|
The ``lang`` argument sets the track language, and can also influence
|
|
|
|
stream selection with ``flags`` set to ``auto``.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``sub-remove [<id>]``
|
2012-11-15 19:26:52 +00:00
|
|
|
Remove the given subtitle track. If the ``id`` argument is missing, remove
|
|
|
|
the current track. (Works on external subtitle files only.)
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``sub-reload [<id>]``
|
2014-09-14 21:41:32 +00:00
|
|
|
Reload the given subtitle tracks. If the ``id`` argument is missing, reload
|
2012-11-15 19:26:52 +00:00
|
|
|
the current track. (Works on external subtitle files only.)
|
|
|
|
|
|
|
|
This works by unloading and re-adding the subtitle track.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``sub-step <skip>``
|
2013-07-08 16:02:14 +00:00
|
|
|
Change subtitle timing such, that the subtitle event after the next
|
|
|
|
``<skip>`` subtitle events is displayed. ``<skip>`` can be negative to step
|
|
|
|
backwards.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``sub-seek <skip>``
|
2013-10-02 19:05:04 +00:00
|
|
|
Seek to the next (skip set to 1) or the previous (skip set to -1) subtitle.
|
2015-05-25 19:59:44 +00:00
|
|
|
This is similar to ``sub-step``, except that it seeks video and audio
|
2013-10-02 19:05:04 +00:00
|
|
|
instead of adjusting the subtitle delay.
|
|
|
|
|
2015-12-06 00:15:08 +00:00
|
|
|
For embedded subtitles (like with Matroska), this works only with subtitle
|
|
|
|
events that have already been displayed, or are within a short prefetch
|
|
|
|
range.
|
2013-10-02 19:05:04 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``print-text "<string>"``
|
2013-06-08 16:04:36 +00:00
|
|
|
Print text to stdout. The string can contain properties (see
|
2013-07-08 16:02:14 +00:00
|
|
|
`Property Expansion`_).
|
2012-10-11 00:24:13 +00:00
|
|
|
|
2018-07-25 10:11:32 +00:00
|
|
|
``show-text "<string>" [<duration>|-1 [<level>]]``
|
2012-09-27 01:20:12 +00:00
|
|
|
Show text on the OSD. The string can contain properties, which are expanded
|
2013-07-08 16:02:14 +00:00
|
|
|
as described in `Property Expansion`_. This can be used to show playback
|
2013-06-08 16:04:36 +00:00
|
|
|
time, filename, and so on.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
<duration>
|
|
|
|
The time in ms to show the message for. By default, it uses the same
|
|
|
|
value as ``--osd-duration``.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
<level>
|
|
|
|
The minimum OSD level to show the text at (see ``--osd-level``).
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2017-03-26 17:29:10 +00:00
|
|
|
``expand-text "<string>"``
|
|
|
|
Property-expand the argument and return the expanded string. This can be
|
|
|
|
used only through the client API or from a script using
|
|
|
|
``mp.command_native``. (see `Property Expansion`_).
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``show-progress``
|
2012-09-27 01:20:12 +00:00
|
|
|
Show the progress bar, the elapsed time and the total duration of the file
|
|
|
|
on the OSD.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``write-watch-later-config``
|
|
|
|
Write the resume config file that the ``quit-watch-later`` command writes,
|
2014-05-27 18:23:47 +00:00
|
|
|
but continue playback normally.
|
2014-05-17 22:03:59 +00:00
|
|
|
|
2014-09-13 12:10:10 +00:00
|
|
|
``stop``
|
|
|
|
Stop playback and clear playlist. With default settings, this is
|
|
|
|
essentially like ``quit``. Useful for the client API: playback can be
|
|
|
|
stopped without terminating the player.
|
|
|
|
|
2015-01-23 20:45:13 +00:00
|
|
|
``mouse <x> <y> [<button> [single|double]]``
|
|
|
|
Send a mouse event with given coordinate (``<x>``, ``<y>``).
|
|
|
|
|
|
|
|
Second argument:
|
|
|
|
|
|
|
|
<button>
|
|
|
|
The button number of clicked mouse button. This should be one of 0-19.
|
|
|
|
If ``<button>`` is omitted, only the position will be updated.
|
|
|
|
|
|
|
|
Third argument:
|
|
|
|
|
|
|
|
<single> (default)
|
|
|
|
The mouse event represents regular single click.
|
|
|
|
|
|
|
|
<double>
|
|
|
|
The mouse event represents double-click.
|
|
|
|
|
2015-06-10 23:56:56 +00:00
|
|
|
``keypress <key_name>``
|
|
|
|
Send a key event through mpv's input handler, triggering whatever
|
|
|
|
behavior is configured to that key. ``key_name`` uses the ``input.conf``
|
|
|
|
naming scheme for keys and modifiers. Useful for the client API: key events
|
|
|
|
can be sent to libmpv to handle internally.
|
|
|
|
|
|
|
|
``keydown <key_name>``
|
|
|
|
Similar to ``keypress``, but sets the ``KEYDOWN`` flag so that if the key is
|
|
|
|
bound to a repeatable command, it will be run repeatedly with mpv's key
|
|
|
|
repeat timing until the ``keyup`` command is called.
|
|
|
|
|
|
|
|
``keyup [<key_name>]``
|
|
|
|
Set the ``KEYUP`` flag, stopping any repeated behavior that had been
|
|
|
|
triggered. ``key_name`` is optional. If ``key_name`` is not given or is an
|
|
|
|
empty string, ``KEYUP`` will be set on all keys. Otherwise, ``KEYUP`` will
|
|
|
|
only be set on the key specified by ``key_name``.
|
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``audio-add "<file>" [<flags> [<title> [<lang>]]]``
|
|
|
|
Load the given audio file. See ``sub-add`` command.
|
2015-02-03 08:15:14 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``audio-remove [<id>]``
|
|
|
|
Remove the given audio track. See ``sub-remove`` command.
|
2015-02-03 08:15:14 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``audio-reload [<id>]``
|
|
|
|
Reload the given audio tracks. See ``sub-reload`` command.
|
2015-02-03 08:15:14 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``rescan-external-files [<mode>]``
|
2015-02-16 21:06:41 +00:00
|
|
|
Rescan external files according to the current ``--sub-auto`` and
|
|
|
|
``--audio-file-auto`` settings. This can be used to auto-load external
|
|
|
|
files *after* the file was loaded.
|
|
|
|
|
|
|
|
The ``mode`` argument is one of the following:
|
|
|
|
|
2015-04-28 20:05:07 +00:00
|
|
|
<reselect> (default)
|
|
|
|
Select the default audio and subtitle streams, which typically selects
|
2015-12-19 08:26:27 +00:00
|
|
|
external files with the highest preference. (The implementation is not
|
2015-02-16 21:06:41 +00:00
|
|
|
perfect, and could be improved on request.)
|
|
|
|
|
2015-04-28 20:05:07 +00:00
|
|
|
<keep-selection>
|
|
|
|
Do not change current track selections.
|
|
|
|
|
2014-09-13 12:10:10 +00:00
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
Input Commands that are Possibly Subject to Change
|
2013-05-18 09:29:52 +00:00
|
|
|
--------------------------------------------------
|
|
|
|
|
2013-07-22 12:43:58 +00:00
|
|
|
``af set|add|toggle|del|clr "filter1=params,filter2,..."``
|
|
|
|
Change audio filter chain. See ``vf`` command.
|
2013-05-18 09:29:52 +00:00
|
|
|
|
2013-07-22 12:43:58 +00:00
|
|
|
``vf set|add|toggle|del|clr "filter1=params,filter2,..."``
|
2013-05-18 09:44:17 +00:00
|
|
|
Change video filter chain.
|
|
|
|
|
|
|
|
The first argument decides what happens:
|
|
|
|
|
|
|
|
set
|
|
|
|
Overwrite the previous filter chain with the new one.
|
|
|
|
|
|
|
|
add
|
|
|
|
Append the new filter chain to the previous one.
|
|
|
|
|
|
|
|
toggle
|
|
|
|
Check if the given filter (with the exact parameters) is already
|
|
|
|
in the video chain. If yes, remove the filter. If no, add the filter.
|
|
|
|
(If several filters are passed to the command, this is done for
|
|
|
|
each filter.)
|
|
|
|
|
2017-03-26 11:13:34 +00:00
|
|
|
A special variant is combining this with labels, and using ``@name``
|
|
|
|
without filter name and parameters as filter entry. This toggles the
|
|
|
|
enable/disable flag.
|
2017-03-25 16:07:40 +00:00
|
|
|
|
2013-05-18 09:44:17 +00:00
|
|
|
del
|
|
|
|
Remove the given filters from the video chain. Unlike in the other
|
|
|
|
cases, the second parameter is a comma separated list of filter names
|
|
|
|
or integer indexes. ``0`` would denote the first filter. Negative
|
|
|
|
indexes start from the last filter, and ``-1`` denotes the last
|
|
|
|
filter.
|
|
|
|
|
2013-07-22 12:43:58 +00:00
|
|
|
clr
|
|
|
|
Remove all filters. Note that like the other sub-commands, this does
|
|
|
|
not control automatically inserted filters.
|
|
|
|
|
2016-07-03 11:45:18 +00:00
|
|
|
The argument is always needed. E.g. in case of ``clr`` use ``vf clr ""``.
|
|
|
|
|
2013-05-22 21:19:57 +00:00
|
|
|
You can assign labels to filter by prefixing them with ``@name:`` (where
|
2013-07-08 16:02:14 +00:00
|
|
|
``name`` is a user-chosen arbitrary identifier). Labels can be used to
|
2013-05-22 21:19:57 +00:00
|
|
|
refer to filters by name in all of the filter chain modification commands.
|
|
|
|
For ``add``, using an already used label will replace the existing filter.
|
|
|
|
|
2013-08-03 11:54:02 +00:00
|
|
|
The ``vf`` command shows the list of requested filters on the OSD after
|
|
|
|
changing the filter chain. This is roughly equivalent to
|
2015-05-25 19:59:44 +00:00
|
|
|
``show-text ${vf}``. Note that auto-inserted filters for format conversion
|
2013-08-03 11:54:02 +00:00
|
|
|
are not shown on the list, only what was requested by the user.
|
|
|
|
|
2014-03-30 17:21:54 +00:00
|
|
|
Normally, the commands will check whether the video chain is recreated
|
|
|
|
successfully, and will undo the operation on failure. If the command is run
|
|
|
|
before video is configured (can happen if the command is run immediately
|
|
|
|
after opening a file and before a video frame is decoded), this check can't
|
|
|
|
be run. Then it can happen that creating the video chain fails.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Example for input.conf
|
2013-05-18 09:44:17 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
- ``a vf set flip`` turn video upside-down on the ``a`` key
|
|
|
|
- ``b vf set ""`` remove all video filters on ``b``
|
2018-01-16 10:30:16 +00:00
|
|
|
- ``c vf toggle gradfun`` toggle debanding on ``c``
|
2013-05-18 09:44:17 +00:00
|
|
|
|
2017-03-25 16:07:40 +00:00
|
|
|
.. admonition:: Example how to toggle disabled filters at runtime
|
|
|
|
|
2018-01-16 10:30:16 +00:00
|
|
|
- Add something like ``vf-add=@deband:!gradfun`` to ``mpv.conf``.
|
|
|
|
The ``@deband:`` is the label, an arbitrary, user-given name for this
|
|
|
|
filter entry. The ``!`` before the filter name disables the filter by
|
|
|
|
default. Everything after this is the normal filter name and possibly
|
|
|
|
filter parameters, like in the normal ``--vf`` syntax.
|
2017-03-26 11:13:34 +00:00
|
|
|
- Add ``a vf toggle @deband`` to ``input.conf``. This toggles the
|
2018-01-16 10:30:16 +00:00
|
|
|
"disabled" flag for the filter with the label ``deband`` when the
|
|
|
|
``a`` key is hit.
|
2017-03-25 16:07:40 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``cycle-values ["!reverse"] <property> "<value1>" "<value2>" ...``
|
2013-11-29 23:18:24 +00:00
|
|
|
Cycle through a list of values. Each invocation of the command will set the
|
command: change cycle-value command behavior
Instead of using an internal counter to keep track of the value that was
set last, attempt to find the current value of the property/option in
the value list, and then set the next value in the list.
There are some potential problems. If a property refuses to accept a
specific value, the cycle-values command will fail, and start from the
same position again. It can't know that it's supposed to skip the next
value. The same can happen to properties which behave "strangely", such
as the "aspect" property, which will return the current aspect if you
write "-1" to it. As a consequence, cycle-values can appear to get
"stuck".
I still think the new behavior is what users expect more, and which is
generally more useful. We won't restore the ability to get the old
behavior, unless we decide to revert this commit entirely.
Fixes #5772, and hopefully other complaints.
2018-04-28 16:14:43 +00:00
|
|
|
given property to the next value in the list. The command will use the
|
|
|
|
current value of the property/option, and use it to determine the current
|
|
|
|
position in the list of values. Once it has found it, it will set the
|
|
|
|
next value in the list (wrapping around to the first item if needed).
|
2013-11-29 23:18:24 +00:00
|
|
|
|
|
|
|
The special argument ``!reverse`` can be used to cycle the value list in
|
command: change cycle-value command behavior
Instead of using an internal counter to keep track of the value that was
set last, attempt to find the current value of the property/option in
the value list, and then set the next value in the list.
There are some potential problems. If a property refuses to accept a
specific value, the cycle-values command will fail, and start from the
same position again. It can't know that it's supposed to skip the next
value. The same can happen to properties which behave "strangely", such
as the "aspect" property, which will return the current aspect if you
write "-1" to it. As a consequence, cycle-values can appear to get
"stuck".
I still think the new behavior is what users expect more, and which is
generally more useful. We won't restore the ability to get the old
behavior, unless we decide to revert this commit entirely.
Fixes #5772, and hopefully other complaints.
2018-04-28 16:14:43 +00:00
|
|
|
reverse. The only advantage is that you don't need to reverse the value
|
|
|
|
list yourself when adding a second key binding for cycling backwards.
|
2013-11-29 23:18:24 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``enable-section "<section>" [flags]``
|
2013-06-22 23:28:28 +00:00
|
|
|
Enable all key bindings in the named input section.
|
|
|
|
|
|
|
|
The enabled input sections form a stack. Bindings in sections on the top of
|
|
|
|
the stack are preferred to lower sections. This command puts the section
|
2013-07-08 16:02:14 +00:00
|
|
|
on top of the stack. If the section was already on the stack, it is
|
|
|
|
implicitly removed beforehand. (A section cannot be on the stack more than
|
|
|
|
once.)
|
2013-06-22 23:28:28 +00:00
|
|
|
|
2015-08-05 22:31:47 +00:00
|
|
|
The ``flags`` parameter can be a combination (separated by ``+``) of the
|
|
|
|
following flags:
|
|
|
|
|
|
|
|
<exclusive>
|
|
|
|
All sections enabled before the newly enabled section are disabled.
|
|
|
|
They will be re-enabled as soon as all exclusive sections above them
|
|
|
|
are removed. In other words, the new section shadows all previous
|
|
|
|
sections.
|
|
|
|
<allow-hide-cursor>
|
|
|
|
This feature can't be used through the public API.
|
|
|
|
<allow-vo-dragging>
|
|
|
|
Same.
|
2013-06-22 23:28:28 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``disable-section "<section>"``
|
|
|
|
Disable the named input section. Undoes ``enable-section``.
|
2013-06-22 23:28:28 +00:00
|
|
|
|
2016-08-17 21:25:52 +00:00
|
|
|
``define-section "<section>" "<contents>" [default|force]``
|
2015-08-05 21:55:16 +00:00
|
|
|
Create a named input section, or replace the contents of an already existing
|
|
|
|
input section. The ``contents`` parameter uses the same syntax as the
|
|
|
|
``input.conf`` file (except that using the section syntax in it is not
|
|
|
|
allowed), including the need to separate bindings with a newline character.
|
|
|
|
|
2015-08-05 22:16:17 +00:00
|
|
|
If the ``contents`` parameter is an empty string, the section is removed.
|
|
|
|
|
2015-08-05 21:55:16 +00:00
|
|
|
The section with the name ``default`` is the normal input section.
|
|
|
|
|
|
|
|
In general, input sections have to be enabled with the ``enable-section``
|
|
|
|
command, or they are ignored.
|
|
|
|
|
|
|
|
The last parameter has the following meaning:
|
|
|
|
|
|
|
|
<default> (also used if parameter omitted)
|
|
|
|
Use a key binding defined by this section only if the user hasn't
|
|
|
|
already bound this key to a command.
|
2016-08-17 21:25:52 +00:00
|
|
|
<force>
|
2015-08-05 21:55:16 +00:00
|
|
|
Always bind a key. (The input section that was made active most recently
|
|
|
|
wins if there are ambiguities.)
|
|
|
|
|
2015-12-23 18:13:45 +00:00
|
|
|
This command can be used to dispatch arbitrary keys to a script or a client
|
|
|
|
API user. If the input section defines ``script-binding`` commands, it is
|
|
|
|
also possible to get separate events on key up/down, and relatively detailed
|
|
|
|
information about the key state. The special key name ``unmapped`` can be
|
|
|
|
used to match any unmapped key.
|
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``overlay-add <id> <x> <y> "<file>" <offset> "<fmt>" <w> <h> <stride>``
|
2013-09-30 20:27:37 +00:00
|
|
|
Add an OSD overlay sourced from raw data. This might be useful for scripts
|
|
|
|
and applications controlling mpv, and which want to display things on top
|
|
|
|
of the video window.
|
|
|
|
|
|
|
|
Overlays are usually displayed in screen resolution, but with some VOs,
|
|
|
|
the resolution is reduced to that of the video's. You can read the
|
|
|
|
``osd-width`` and ``osd-height`` properties. At least with ``--vo-xv`` and
|
|
|
|
anamorphic video (such as DVD), ``osd-par`` should be read as well, and the
|
2016-07-01 17:39:04 +00:00
|
|
|
overlay should be aspect-compensated.
|
2013-09-30 20:27:37 +00:00
|
|
|
|
|
|
|
``id`` is an integer between 0 and 63 identifying the overlay element. The
|
|
|
|
ID can be used to add multiple overlay parts, update a part by using this
|
|
|
|
command with an already existing ID, or to remove a part with
|
2015-08-05 22:35:09 +00:00
|
|
|
``overlay-remove``. Using a previously unused ID will add a new overlay,
|
2016-07-01 17:39:04 +00:00
|
|
|
while reusing an ID will update it.
|
2013-09-30 20:27:37 +00:00
|
|
|
|
|
|
|
``x`` and ``y`` specify the position where the OSD should be displayed.
|
|
|
|
|
|
|
|
``file`` specifies the file the raw image data is read from. It can be
|
|
|
|
either a numeric UNIX file descriptor prefixed with ``@`` (e.g. ``@4``),
|
2016-07-01 17:39:04 +00:00
|
|
|
or a filename. The file will be mapped into memory with ``mmap()``,
|
|
|
|
copied, and unmapped before the command returns (changed in mpv 0.18.1).
|
2013-09-30 20:27:37 +00:00
|
|
|
|
2014-10-02 23:24:48 +00:00
|
|
|
It is also possible to pass a raw memory address for use as bitmap memory
|
2015-06-29 15:51:43 +00:00
|
|
|
by passing a memory address as integer prefixed with an ``&`` character.
|
2014-12-26 16:43:59 +00:00
|
|
|
Passing the wrong thing here will crash the player. This mode might be
|
|
|
|
useful for use with libmpv. The ``offset`` parameter is simply added to the
|
|
|
|
memory address (since mpv 0.8.0, ignored before).
|
|
|
|
|
|
|
|
``offset`` is the byte offset of the first pixel in the source file.
|
|
|
|
(The current implementation always mmap's the whole file from position 0 to
|
|
|
|
the end of the image, so large offsets should be avoided. Before mpv 0.8.0,
|
|
|
|
the offset was actually passed directly to ``mmap``, but it was changed to
|
|
|
|
make using it easier.)
|
2013-09-30 20:27:37 +00:00
|
|
|
|
|
|
|
``fmt`` is a string identifying the image format. Currently, only ``bgra``
|
|
|
|
is defined. This format has 4 bytes per pixels, with 8 bits per component.
|
|
|
|
The least significant 8 bits are blue, and the most significant 8 bits
|
|
|
|
are alpha (in little endian, the components are B-G-R-A, with B as first
|
|
|
|
byte). This uses premultiplied alpha: every color component is already
|
|
|
|
multiplied with the alpha component. This means the numeric value of each
|
|
|
|
component is equal to or smaller than the alpha component. (Violating this
|
|
|
|
rule will lead to different results with different VOs: numeric overflows
|
|
|
|
resulting from blending broken alpha values is considered something that
|
|
|
|
shouldn't happen, and consequently implementations don't ensure that you
|
|
|
|
get predictable behavior in this case.)
|
|
|
|
|
|
|
|
``w``, ``h``, and ``stride`` specify the size of the overlay. ``w`` is the
|
|
|
|
visible width of the overlay, while ``stride`` gives the width in bytes in
|
|
|
|
memory. In the simple case, and with the ``bgra`` format, ``stride==4*w``.
|
|
|
|
In general, the total amount of memory accessed is ``stride * h``.
|
|
|
|
(Technically, the minimum size would be ``stride * (h - 1) + w * 4``, but
|
|
|
|
for simplicity, the player will access all ``stride * h`` bytes.)
|
|
|
|
|
2016-07-01 17:39:04 +00:00
|
|
|
.. note::
|
2013-09-30 20:27:37 +00:00
|
|
|
|
2016-07-01 17:39:04 +00:00
|
|
|
Before mpv 0.18.1, you had to do manual "double buffering" when updating
|
|
|
|
an overlay by replacing it with a different memory buffer. Since mpv
|
|
|
|
0.18.1, the memory is simply copied and doesn't reference any of the
|
|
|
|
memory indicated by the command's arguments after the commend returns.
|
|
|
|
If you want to use this command before mpv 0.18.1, reads the old docs
|
|
|
|
to see how to handle this correctly.
|
2013-09-30 20:27:37 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``overlay-remove <id>``
|
|
|
|
Remove an overlay added with ``overlay-add`` and the same ID. Does nothing
|
2013-09-30 20:27:37 +00:00
|
|
|
if no overlay with this ID exists.
|
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``script-message "<arg1>" "<arg2>" ...``
|
2014-03-17 17:26:56 +00:00
|
|
|
Send a message to all clients, and pass it the following list of arguments.
|
|
|
|
What this message means, how many arguments it takes, and what the arguments
|
|
|
|
mean is fully up to the receiver and the sender. Every client receives the
|
2016-05-09 18:39:33 +00:00
|
|
|
message, so be careful about name clashes (or use ``script-message-to``).
|
2014-03-17 17:26:56 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``script-message-to "<target>" "<arg1>" "<arg2>" ...``
|
2016-05-09 18:39:33 +00:00
|
|
|
Same as ``script-message``, but send it only to the client named
|
2014-03-17 17:26:56 +00:00
|
|
|
``<target>``. Each client (scripts etc.) has a unique name. For example,
|
|
|
|
Lua scripts can get their name via ``mp.get_script_name()``.
|
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``script-binding "<name>"``
|
2014-11-23 14:08:49 +00:00
|
|
|
Invoke a script-provided key binding. This can be used to remap key
|
|
|
|
bindings provided by external Lua scripts.
|
|
|
|
|
|
|
|
The argument is the name of the binding.
|
|
|
|
|
|
|
|
It can optionally be prefixed with the name of the script, using ``/`` as
|
2016-07-14 18:04:59 +00:00
|
|
|
separator, e.g. ``script-binding scriptname/bindingname``.
|
2014-11-23 14:08:49 +00:00
|
|
|
|
|
|
|
For completeness, here is how this command works internally. The details
|
2016-05-09 18:39:33 +00:00
|
|
|
could change any time. On any matching key event, ``script-message-to``
|
|
|
|
or ``script-message`` is called (depending on whether the script name is
|
2015-12-23 18:10:38 +00:00
|
|
|
included), with the following arguments:
|
|
|
|
|
|
|
|
1. The string ``key-binding``.
|
|
|
|
2. The name of the binding (as established above).
|
|
|
|
3. The key state as string (see below).
|
|
|
|
4. The key name (since mpv 0.15.0).
|
|
|
|
|
|
|
|
The key state consists of 2 letters:
|
|
|
|
|
|
|
|
1. One of ``d`` (key was pressed down), ``u`` (was released), ``r`` (key
|
|
|
|
is still down, and was repeated; only if key repeat is enabled for this
|
|
|
|
binding), ``p`` (key was pressed; happens if up/down can't be tracked).
|
|
|
|
2. Whether the event originates from the mouse, either ``m`` (mouse button)
|
|
|
|
or ``-`` (something else).
|
2014-03-17 17:26:56 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``ab-loop``
|
2014-11-18 20:33:15 +00:00
|
|
|
Cycle through A-B loop states. The first command will set the ``A`` point
|
|
|
|
(the ``ab-loop-a`` property); the second the ``B`` point, and the third
|
|
|
|
will clear both points.
|
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``drop-buffers``
|
2014-11-20 21:41:50 +00:00
|
|
|
Drop audio/video/demuxer buffers, and restart from fresh. Might help with
|
|
|
|
unseekable streams that are going out of sync.
|
|
|
|
This command might be changed or removed in the future.
|
2014-02-17 19:23:30 +00:00
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
``screenshot-raw [subtitles|video|window]``
|
2015-04-20 21:11:03 +00:00
|
|
|
Return a screenshot in memory. This can be used only through the client
|
|
|
|
API. The MPV_FORMAT_NODE_MAP returned by this command has the ``w``, ``h``,
|
2017-03-18 11:53:03 +00:00
|
|
|
``stride`` fields set to obvious contents. The ``format`` field is set to
|
2015-04-20 21:11:03 +00:00
|
|
|
``bgr0`` by default. This format is organized as ``B8G8R8X8`` (where ``B``
|
2017-03-18 11:53:03 +00:00
|
|
|
is the LSB). The contents of the padding ``X`` are undefined. The ``data``
|
2015-04-20 21:11:03 +00:00
|
|
|
field is of type MPV_FORMAT_BYTE_ARRAY with the actual image data. The image
|
2017-03-18 11:53:03 +00:00
|
|
|
is freed as soon as the result mpv_node is freed. As usual with client API
|
|
|
|
semantics, you are not allowed to write to the image data.
|
2015-04-20 21:11:03 +00:00
|
|
|
|
2016-01-22 15:18:28 +00:00
|
|
|
``vf-command "<label>" "<cmd>" "<args>"``
|
|
|
|
Send a command to the filter with the given ``<label>``. Use ``all`` to send
|
|
|
|
it to all filters at once. The command and argument string is filter
|
|
|
|
specific. Currently, this only works with the ``lavfi`` filter - see
|
|
|
|
the libavfilter documentation for which commands a filter supports.
|
|
|
|
|
2016-01-22 20:20:23 +00:00
|
|
|
Note that the ``<label>`` is a mpv filter label, not a libavfilter filter
|
|
|
|
name.
|
|
|
|
|
2016-01-22 19:36:54 +00:00
|
|
|
``af-command "<label>" "<cmd>" "<args>"``
|
2016-01-22 20:20:23 +00:00
|
|
|
Same as ``vf-command``, but for audio filters.
|
2016-01-22 19:36:54 +00:00
|
|
|
|
2016-09-17 19:01:59 +00:00
|
|
|
``apply-profile "<name>"``
|
|
|
|
Apply the contents of a named profile. This is like using ``profile=name``
|
|
|
|
in a config file, except you can map it to a key binding to change it at
|
|
|
|
runtime.
|
|
|
|
|
|
|
|
There is no such thing as "unapplying" a profile - applying a profile
|
|
|
|
merely sets all option values listed within the profile.
|
|
|
|
|
2016-09-22 18:43:33 +00:00
|
|
|
``load-script "<path>"``
|
scripting: change when/how player waits for scripts being loaded
Fundamentally, scripts are loaded asynchronously, but as a feature,
there was code to wait until a script is loaded (for a certain arbitrary
definition of "loaded"). This was done in scripting.c with the
wait_loaded() function.
This called mp_idle(), and since there are commands to load/unload
scripts, it meant the player core loop could be entered recursively. I
think this is a major complication and has some problems. For example,
if you had a script that does 'os.execute("sleep inf")', then every time
you ran a command to load an instance of the script would add a new
stack frame of mp_idle(). This would lead to some sort of reentrancy
horror that is hard to debug. Also misc/dispatch.c contains a somewhat
tricky mess to support such recursive invocations. There were also some
bugs due to this and due to unforeseen interactions with other messes.
This scripting stuff was the only thing making use of that reentrancy,
and future commands that have "logical" waiting for something should be
implemented differently. So get rid of it.
Change the code to wait only in the player initialization phase: the
only place where it really has to wait is before playback is started,
because scripts might want to set options or hooks that interact with
playback initialization. Unloading of builtin scripts (can happen with
e.g. "set osc no") is left asynchronous; the unloading wasn't too robust
anyway, and this change won't make a difference if someone is trying to
break it intentionally. Note that this is not in mp_initialize(),
because mpv_initialize() uses this by locking the core, which would have
the same problem.
In the future, commands which logically wait should use different
mechanisms. Originally I thought the current approach (that is removed
with this commit) should be used, but it's too much of a mess and can't
even be used in some cases. Examples are:
- "loadfile" should be made blocking (needs to run the normal player
code and manually unblock the thread issuing the command)
- "add-sub" should not freeze the player until the URL is opened (needs
to run opening on a separate thread)
Possibly the current scripting behavior could be restored once new
mechanisms exist, and if it turns out that anyone needs it.
With this commit there should be no further instances of recursive
playloop invocations (other than the case in the following commit),
since all mp_idle()/mp_wait_events() calls are done strictly from the
main thread (and not commands/properties or libmpv client API that
"lock" the main thread).
2018-04-15 08:14:00 +00:00
|
|
|
Load a script, similar to the ``--script`` option. Whether this waits for
|
|
|
|
the script to finish initialization or not changed multiple times, and the
|
|
|
|
future behavior is left undefined.
|
2016-09-22 18:43:33 +00:00
|
|
|
|
2018-01-24 02:20:15 +00:00
|
|
|
``change-list "<option>" "<operation>" "<value>"``
|
|
|
|
This command changes list options as described in `List Options`_. The
|
|
|
|
``<option>`` parameter is the normal option name, while ``<operation>`` is
|
|
|
|
the suffix or action used on the option.
|
|
|
|
|
|
|
|
Some operations take no value, but the command still requires the value
|
|
|
|
parameter. In these cases, the value must be an empty string.
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
``change-list glsl-shaders append file.glsl``
|
|
|
|
|
|
|
|
Add a filename to the ``glsl-shaders`` list. The command line
|
|
|
|
equivalent is ``--glsl-shaders-append=file.glsl`` or alternatively
|
|
|
|
``--glsl-shader=file.glsl``.
|
|
|
|
|
|
|
|
|
2015-08-05 22:35:09 +00:00
|
|
|
Undocumented commands: ``tv-last-channel`` (TV/DVB only),
|
2018-01-02 20:20:06 +00:00
|
|
|
``ao-reload`` (experimental/internal).
|
2015-02-04 18:20:17 +00:00
|
|
|
|
|
|
|
Hooks
|
|
|
|
~~~~~
|
|
|
|
|
|
|
|
Hooks are synchronous events between player core and a script or similar. This
|
2015-06-23 13:33:07 +00:00
|
|
|
applies to client API (including the Lua scripting interface). Normally,
|
2015-02-04 18:20:17 +00:00
|
|
|
events are supposed to be asynchronous, and the hook API provides an awkward
|
|
|
|
and obscure way to handle events that require stricter coordination. There are
|
|
|
|
no API stability guarantees made. Not following the protocol exactly can make
|
|
|
|
the player freeze randomly. Basically, nobody should use this API.
|
|
|
|
|
2018-03-23 15:24:49 +00:00
|
|
|
The C API is described in the header files. The Lua API is described in the
|
|
|
|
Lua section.
|
2015-02-04 18:20:17 +00:00
|
|
|
|
|
|
|
The following hooks are currently defined:
|
|
|
|
|
|
|
|
``on_load``
|
|
|
|
Called when a file is to be opened, before anything is actually done.
|
|
|
|
For example, you could read and write the ``stream-open-filename``
|
|
|
|
property to redirect an URL to something else (consider support for
|
|
|
|
streaming sites which rarely give the user a direct media URL), or
|
|
|
|
you could set per-file options with by setting the property
|
|
|
|
``file-local-options/<option name>``. The player will wait until all
|
|
|
|
hooks are run.
|
|
|
|
|
2018-01-02 14:20:53 +00:00
|
|
|
``on_load_fail``
|
|
|
|
Called after after a file has been opened, but failed to. This can be
|
|
|
|
used to provide a fallback in case native demuxers failed to recognize
|
|
|
|
the file, instead of always running before the native demuxers like
|
|
|
|
``on_load``. Demux will only be retried if ``stream-open-filename``
|
|
|
|
was changed.
|
|
|
|
|
2016-02-15 15:19:19 +00:00
|
|
|
``on_preloaded``
|
|
|
|
Called after a file has been opened, and before tracks are selected and
|
|
|
|
decoders are created. This has some usefulness if an API users wants
|
|
|
|
to select tracks manually, based on the set of available tracks. It's
|
|
|
|
also useful to initialize ``--lavfi-complex`` in a specific way by API,
|
|
|
|
without having to "probe" the available streams at first.
|
|
|
|
|
|
|
|
Note that this does not yet apply default track selection. Which operations
|
|
|
|
exactly can be done and not be done, and what information is available and
|
|
|
|
what is not yet available yet, is all subject to change.
|
|
|
|
|
2015-02-04 18:20:17 +00:00
|
|
|
``on_unload``
|
|
|
|
Run before closing a file, and before actually uninitializing
|
|
|
|
everything. It's not possible to resume playback in this state.
|
|
|
|
|
2018-03-23 15:24:49 +00:00
|
|
|
Legacy hook API
|
|
|
|
~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
The legacy API is deprecated and will be removed soon.
|
|
|
|
|
|
|
|
There are two special commands involved. Also, the client must listen for
|
|
|
|
client messages (``MPV_EVENT_CLIENT_MESSAGE`` in the C API).
|
|
|
|
|
|
|
|
``hook-add <hook-name> <id> <priority>``
|
|
|
|
Subscribe to the hook identified by the first argument (basically, the
|
|
|
|
name of event). The ``id`` argument is an arbitrary integer chosen by the
|
|
|
|
user. ``priority`` is used to sort all hook handlers globally across all
|
|
|
|
clients. Each client can register multiple hook handlers (even for the
|
|
|
|
same hook-name). Once the hook is registered, it cannot be unregistered.
|
|
|
|
|
|
|
|
When a specific event happens, all registered handlers are run serially.
|
|
|
|
This uses a protocol every client has to follow explicitly. When a hook
|
|
|
|
handler is run, a client message (``MPV_EVENT_CLIENT_MESSAGE``) is sent to
|
|
|
|
the client which registered the hook. This message has the following
|
|
|
|
arguments:
|
|
|
|
|
|
|
|
1. the string ``hook_run``
|
|
|
|
2. the ``id`` argument the hook was registered with as string (this can be
|
|
|
|
used to correctly handle multiple hooks registered by the same client,
|
|
|
|
as long as the ``id`` argument is unique in the client)
|
|
|
|
3. something undefined, used by the hook mechanism to track hook execution
|
|
|
|
|
|
|
|
Upon receiving this message, the client can handle the event. While doing
|
|
|
|
this, the player core will still react to requests, but playback will
|
|
|
|
typically be stopped.
|
|
|
|
|
|
|
|
When the client is done, it must continue the core's hook execution by
|
|
|
|
running the ``hook-ack`` command.
|
|
|
|
|
|
|
|
``hook-ack <string>``
|
|
|
|
Run the next hook in the global chain of hooks. The argument is the 3rd
|
|
|
|
argument of the client message that starts hook execution for the
|
|
|
|
current client.
|
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
Input Command Prefixes
|
2012-09-27 01:20:12 +00:00
|
|
|
----------------------
|
|
|
|
|
2013-09-10 13:09:24 +00:00
|
|
|
These prefixes are placed between key name and the actual command. Multiple
|
|
|
|
prefixes can be specified. They are separated by whitespace.
|
|
|
|
|
2017-04-01 19:47:19 +00:00
|
|
|
``osd-auto``
|
|
|
|
Use the default behavior for this command. This is the default for
|
|
|
|
``input.conf`` commands. Some libmpv/scripting/IPC APIs do not use this as
|
|
|
|
default, but use ``no-osd`` instead.
|
2013-07-08 16:02:14 +00:00
|
|
|
``no-osd``
|
2012-09-27 01:20:12 +00:00
|
|
|
Do not use any OSD for this command.
|
2013-07-08 16:02:14 +00:00
|
|
|
``osd-bar``
|
2012-09-27 01:20:12 +00:00
|
|
|
If possible, show a bar with this command. Seek commands will show the
|
|
|
|
progress bar, property changing commands may show the newly set value.
|
2013-07-08 16:02:14 +00:00
|
|
|
``osd-msg``
|
2012-10-23 23:06:00 +00:00
|
|
|
If possible, show an OSD message with this command. Seek command show
|
|
|
|
the current playback time, property changing commands show the newly set
|
|
|
|
value as text.
|
2013-07-08 16:02:14 +00:00
|
|
|
``osd-msg-bar``
|
2012-09-27 01:20:12 +00:00
|
|
|
Combine osd-bar and osd-msg.
|
2013-07-08 16:02:14 +00:00
|
|
|
``raw``
|
|
|
|
Do not expand properties in string arguments. (Like ``"${property-name}"``.)
|
2017-04-01 19:47:19 +00:00
|
|
|
This is the default for some libmpv/scripting/IPC APIs.
|
|
|
|
``expand-properties``
|
2013-07-08 16:02:14 +00:00
|
|
|
All string arguments are expanded as described in `Property Expansion`_.
|
2017-04-01 19:47:19 +00:00
|
|
|
This is the default for ``input.conf`` commands.
|
2014-11-20 22:41:01 +00:00
|
|
|
``repeatable``
|
|
|
|
For some commands, keeping a key pressed doesn't run the command repeatedly.
|
|
|
|
This prefix forces enabling key repeat in any case.
|
2017-04-01 18:36:39 +00:00
|
|
|
``async``
|
|
|
|
Allow asynchronous execution (if possible). Note that only a few commands
|
|
|
|
will support this (usually this is explicitly documented). Some commands
|
|
|
|
are asynchronous by default (or rather, their effects might manifest
|
|
|
|
after completion of the command). The semantics of this flag might change
|
2017-04-01 19:37:03 +00:00
|
|
|
in the future. Set it only if you don't rely on the effects of this command
|
|
|
|
being fully realized when it returns.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-05-18 10:56:22 +00:00
|
|
|
All of the osd prefixes are still overridden by the global ``--osd-level``
|
|
|
|
settings.
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
Input Sections
|
2013-06-23 00:31:51 +00:00
|
|
|
--------------
|
|
|
|
|
|
|
|
Input sections group a set of bindings, and enable or disable them at once.
|
|
|
|
In ``input.conf``, each key binding is assigned to an input section, rather
|
|
|
|
than actually having explicit text sections.
|
|
|
|
|
2016-07-14 18:04:59 +00:00
|
|
|
See also: ``enable-section`` and ``disable-section`` commands.
|
2013-06-23 00:31:51 +00:00
|
|
|
|
|
|
|
Predefined bindings:
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``default``
|
2013-06-23 00:31:51 +00:00
|
|
|
Bindings without input section are implicitly assigned to this section. It
|
|
|
|
is enabled by default during normal playback.
|
2013-07-08 16:02:14 +00:00
|
|
|
``encode``
|
2013-06-23 00:31:51 +00:00
|
|
|
Section which is active in encoding mode. It is enabled exclusively, so
|
|
|
|
that bindings in the ``default`` sections are ignored.
|
|
|
|
|
2012-09-27 01:20:12 +00:00
|
|
|
Properties
|
|
|
|
----------
|
|
|
|
|
2012-10-21 10:33:18 +00:00
|
|
|
Properties are used to set mpv options during runtime, or to query arbitrary
|
2012-09-27 01:20:12 +00:00
|
|
|
information. They can be manipulated with the ``set``/``add``/``cycle``
|
2015-05-25 19:59:44 +00:00
|
|
|
commands, and retrieved with ``show-text``, or anything else that uses property
|
2013-07-08 16:02:14 +00:00
|
|
|
expansion. (See `Property Expansion`_.)
|
2012-09-27 01:20:12 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
The property name is annotated with RW to indicate whether the property is
|
|
|
|
generally writable.
|
|
|
|
|
|
|
|
If an option is referenced, the property will normally take/return exactly the
|
|
|
|
same values as the option. In these cases, properties are merely a way to change
|
|
|
|
an option at runtime.
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
Property list
|
|
|
|
-------------
|
|
|
|
|
2016-09-01 18:00:43 +00:00
|
|
|
.. note::
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2016-09-01 18:00:43 +00:00
|
|
|
Most options can be set as runtime via properties as well. Just remove the
|
|
|
|
leading ``--`` from the option name. These are not documented. Only
|
|
|
|
properties which do not exist as option with the same name, or which have
|
|
|
|
very different behavior from the options are documented below.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2015-08-10 16:40:16 +00:00
|
|
|
``audio-speed-correction``, ``video-speed-correction``
|
|
|
|
Factor multiplied with ``speed`` at which the player attempts to play the
|
|
|
|
file. Usually it's exactly 1. (Display sync mode will make this useful.)
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
OSD formatting will display it in the form of ``+1.23456%``, with the number
|
|
|
|
being ``(raw - 1) * 100`` for the given raw property value.
|
|
|
|
|
|
|
|
``display-sync-active``
|
|
|
|
Return whether ``--video-sync=display`` is actually active.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``filename``
|
|
|
|
Currently played file, with path stripped. If this is an URL, try to undo
|
|
|
|
percent encoding as well. (The result is not necessarily correct, but
|
|
|
|
looks better for display purposes. Use the ``path`` property to get an
|
|
|
|
unmodified filename.)
|
|
|
|
|
2016-08-11 20:40:00 +00:00
|
|
|
This has a sub-property:
|
|
|
|
|
|
|
|
``filename/no-ext``
|
|
|
|
Like the ``filename`` property, but if the text contains a ``.``, strip
|
|
|
|
all text after the last ``.``. Usually this removes the file extension.
|
|
|
|
|
2014-05-05 21:52:50 +00:00
|
|
|
``file-size``
|
2014-05-06 18:43:20 +00:00
|
|
|
Length in bytes of the source file/stream. (This is the same as
|
2017-10-11 20:45:47 +00:00
|
|
|
``${stream-end}``. For segmented/multi-part files, this will return the
|
|
|
|
size of the main or manifest file, whatever it is.)
|
2014-05-05 21:52:50 +00:00
|
|
|
|
2014-08-19 19:19:38 +00:00
|
|
|
``estimated-frame-count``
|
2014-08-30 22:22:01 +00:00
|
|
|
Total number of frames in current file.
|
|
|
|
|
|
|
|
.. note:: This is only an estimate. (It's computed from two unreliable
|
|
|
|
quantities: fps and stream length.)
|
2014-08-19 19:19:38 +00:00
|
|
|
|
|
|
|
``estimated-frame-number``
|
|
|
|
Number of current frame in current stream.
|
|
|
|
|
2014-08-30 22:22:01 +00:00
|
|
|
.. note:: This is only an estimate. (It's computed from two unreliable
|
|
|
|
quantities: fps and possibly rounded timestamps.)
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``path``
|
2015-11-29 16:54:31 +00:00
|
|
|
Full path of the currently played file. Usually this is exactly the same
|
|
|
|
string you pass on the mpv command line or the ``loadfile`` command, even
|
|
|
|
if it's a relative path. If you expect an absolute path, you will have to
|
|
|
|
determine it yourself, for example by using the ``working-directory``
|
|
|
|
property.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
|
|
|
``media-title``
|
2014-10-25 18:07:44 +00:00
|
|
|
If the currently played file has a ``title`` tag, use that.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-02-23 15:43:04 +00:00
|
|
|
Otherwise, if the media type is DVD, return the volume ID of DVD.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
Otherwise, return the ``filename`` property.
|
|
|
|
|
2015-01-23 14:59:06 +00:00
|
|
|
``file-format``
|
|
|
|
Symbolic name of the file format. In some cases, this is a comma-separated
|
|
|
|
list of format names, e.g. mp4 is ``mov,mp4,m4a,3gp,3g2,mj2`` (the list
|
2015-01-23 16:09:25 +00:00
|
|
|
may grow in the future for any format).
|
2015-01-23 14:59:06 +00:00
|
|
|
|
2016-09-01 18:01:02 +00:00
|
|
|
``current-demuxer``
|
2014-02-12 20:56:43 +00:00
|
|
|
Name of the current demuxer. (This is useless.)
|
|
|
|
|
2016-09-01 18:01:02 +00:00
|
|
|
(Renamed from ``demuxer``.)
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``stream-path``
|
|
|
|
Filename (full path) of the stream layer filename. (This is probably
|
2017-10-11 20:45:47 +00:00
|
|
|
useless and is almost never different from ``path``.)
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2016-03-09 22:34:04 +00:00
|
|
|
``stream-pos``
|
|
|
|
Raw byte position in source stream. Technically, this returns the position
|
|
|
|
of the most recent packet passed to a decoder.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
|
|
|
``stream-end``
|
|
|
|
Raw end position in bytes in source stream.
|
|
|
|
|
2015-05-22 18:02:47 +00:00
|
|
|
``duration``
|
|
|
|
Duration of the current file in seconds. If the duration is unknown, the
|
2014-02-12 20:56:43 +00:00
|
|
|
property is unavailable. Note that the file duration is not always exactly
|
|
|
|
known, so this is an estimate.
|
|
|
|
|
2015-05-22 18:02:47 +00:00
|
|
|
This replaces the ``length`` property, which was deprecated after the
|
|
|
|
mpv 0.9 release. (The semantics are the same.)
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``avsync``
|
|
|
|
Last A/V synchronization difference. Unavailable if audio or video is
|
|
|
|
disabled.
|
|
|
|
|
2014-04-12 18:26:28 +00:00
|
|
|
``total-avsync-change``
|
|
|
|
Total A-V sync correction done. Unavailable if audio or video is
|
|
|
|
disabled.
|
|
|
|
|
2017-01-20 16:01:29 +00:00
|
|
|
``decoder-frame-drop-count``
|
2014-11-01 00:07:21 +00:00
|
|
|
Video frames dropped by decoder, because video is too far behind audio (when
|
|
|
|
using ``--framedrop=decoder``). Sometimes, this may be incremented in other
|
|
|
|
situations, e.g. when video packets are damaged, or the decoder doesn't
|
|
|
|
follow the usual rules. Unavailable if video is disabled.
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 21:33:33 +00:00
|
|
|
|
2017-01-20 16:01:29 +00:00
|
|
|
``drop-frame-count`` is a deprecated alias.
|
|
|
|
|
|
|
|
``frame-drop-count``
|
video: add VO framedropping mode
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
2014-08-15 21:33:33 +00:00
|
|
|
Frames dropped by VO (when using ``--framedrop=vo``).
|
2014-04-12 18:26:28 +00:00
|
|
|
|
2017-01-20 16:01:29 +00:00
|
|
|
``vo-drop-frame-count`` is a deprecated alias.
|
|
|
|
|
2015-10-30 13:05:41 +00:00
|
|
|
``mistimed-frame-count``
|
|
|
|
Number of video frames that were not timed correctly in display-sync mode
|
|
|
|
for the sake of keeping A/V sync. This does not include external
|
|
|
|
circumstances, such as video rendering being too slow or the graphics
|
|
|
|
driver somehow skipping a vsync. It does not include rounding errors either
|
|
|
|
(which can happen especially with bad source timestamps). For example,
|
|
|
|
using the ``display-desync`` mode should never change this value from 0.
|
|
|
|
|
2015-11-13 21:48:32 +00:00
|
|
|
``vsync-ratio``
|
|
|
|
For how many vsyncs a frame is displayed on average. This is available if
|
|
|
|
display-sync is active only. For 30 FPS video on a 60 Hz screen, this will
|
|
|
|
be 2. This is the moving average of what actually has been scheduled, so
|
|
|
|
24 FPS on 60 Hz will never remain exactly on 2.5, but jitter depending on
|
|
|
|
the last frame displayed.
|
|
|
|
|
2015-11-13 21:41:41 +00:00
|
|
|
``vo-delayed-frame-count``
|
|
|
|
Estimated number of frames delayed due to external circumstances in
|
|
|
|
display-sync mode. Note that in general, mpv has to guess that this is
|
|
|
|
happening, and the guess can be inaccurate.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``percent-pos`` (RW)
|
|
|
|
Position in current file (0-100). The advantage over using this instead of
|
|
|
|
calculating it out of other properties is that it properly falls back to
|
|
|
|
estimating the playback position from the byte position, if the file
|
|
|
|
duration is not known.
|
|
|
|
|
|
|
|
``time-pos`` (RW)
|
|
|
|
Position in current file in seconds.
|
|
|
|
|
2014-02-28 19:57:54 +00:00
|
|
|
``time-start``
|
2015-11-16 21:47:17 +00:00
|
|
|
Deprecated. Always returns 0. Before mpv 0.14, this used to return the start
|
|
|
|
time of the file (could affect e.g. transport streams). See
|
|
|
|
``--rebase-start-time`` option.
|
2014-02-28 19:57:54 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``time-remaining``
|
|
|
|
Remaining length of the file in seconds. Note that the file duration is not
|
|
|
|
always exactly known, so this is an estimate.
|
|
|
|
|
2016-09-19 17:11:14 +00:00
|
|
|
``audio-pts`` (R)
|
|
|
|
Current audio playback position in current file in seconds. Unlike time-pos,
|
|
|
|
this updates more often than once per frame. For audio-only files, it is
|
|
|
|
mostly equivalent to time-pos, while for video-only files this property is
|
|
|
|
not available.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``playtime-remaining``
|
2015-06-17 17:37:25 +00:00
|
|
|
``time-remaining`` scaled by the current ``speed``.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2015-08-21 13:51:50 +00:00
|
|
|
``playback-time`` (RW)
|
2015-11-16 21:47:17 +00:00
|
|
|
Position in current file in seconds. Unlike ``time-pos``, the time is
|
|
|
|
clamped to the range of the file. (Inaccurate file durations etc. could
|
2015-12-19 08:26:27 +00:00
|
|
|
make it go out of range. Useful on attempts to seek outside of the file,
|
|
|
|
as the seek target time is considered the current position during seeking.)
|
2014-06-29 17:27:46 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``chapter`` (RW)
|
|
|
|
Current chapter number. The number of the first chapter is 0.
|
|
|
|
|
|
|
|
``edition`` (RW)
|
|
|
|
Current MKV edition number. Setting this property to a different value will
|
|
|
|
restart playback. The number of the first edition is 0.
|
|
|
|
|
2014-03-15 19:53:59 +00:00
|
|
|
``disc-titles``
|
|
|
|
Number of BD/DVD titles.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-12-13 19:25:31 +00:00
|
|
|
This has a number of sub-properties. Replace ``N`` with the 0-based edition
|
|
|
|
index.
|
|
|
|
|
|
|
|
``disc-titles/count``
|
|
|
|
Number of titles.
|
|
|
|
|
|
|
|
``disc-titles/id``
|
|
|
|
Title ID as integer. Currently, this is the same as the title index.
|
|
|
|
|
|
|
|
``disc-titles/length``
|
|
|
|
Length in seconds. Can be unavailable in a number of cases (currently
|
|
|
|
it works for libdvdnav only).
|
|
|
|
|
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each edition)
|
|
|
|
"id" MPV_FORMAT_INT64
|
|
|
|
"length" MPV_FORMAT_DOUBLE
|
|
|
|
|
|
|
|
``disc-title-list``
|
|
|
|
List of BD/DVD titles.
|
|
|
|
|
2014-03-18 14:26:41 +00:00
|
|
|
``disc-title`` (RW)
|
|
|
|
Current BD/DVD title number. Writing works only for ``dvdnav://`` and
|
|
|
|
``bd://`` (and aliases for these).
|
2014-03-15 17:41:15 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``chapters``
|
|
|
|
Number of chapters.
|
|
|
|
|
|
|
|
``editions``
|
|
|
|
Number of MKV editions.
|
|
|
|
|
2014-02-18 23:41:12 +00:00
|
|
|
``edition-list``
|
|
|
|
List of editions, current entry marked. Currently, the raw property value
|
|
|
|
is useless.
|
|
|
|
|
|
|
|
This has a number of sub-properties. Replace ``N`` with the 0-based edition
|
|
|
|
index.
|
|
|
|
|
|
|
|
``edition-list/count``
|
|
|
|
Number of editions. If there are no editions, this can be 0 or 1 (1
|
|
|
|
if there's a useless dummy edition).
|
|
|
|
|
|
|
|
``edition-list/N/id``
|
|
|
|
Edition ID as integer. Use this to set the ``edition`` property.
|
|
|
|
Currently, this is the same as the edition index.
|
|
|
|
|
|
|
|
``edition-list/N/default``
|
|
|
|
``yes`` if this is the default edition, ``no`` otherwise.
|
|
|
|
|
|
|
|
``edition-list/N/title``
|
|
|
|
Edition title as stored in the file. Not always available.
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each edition)
|
|
|
|
"id" MPV_FORMAT_INT64
|
|
|
|
"title" MPV_FORMAT_STRING
|
|
|
|
"default" MPV_FORMAT_FLAG
|
2014-02-18 23:41:12 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``angle`` (RW)
|
|
|
|
Current DVD angle.
|
|
|
|
|
|
|
|
``metadata``
|
2014-03-30 17:09:31 +00:00
|
|
|
Metadata key/value pairs.
|
|
|
|
|
|
|
|
If the property is accessed with Lua's ``mp.get_property_native``, this
|
|
|
|
returns a table with metadata keys mapping to metadata values. If it is
|
|
|
|
accessed with the client API, this returns a ``MPV_FORMAT_NODE_MAP``,
|
|
|
|
with tag keys mapping to tag values.
|
|
|
|
|
|
|
|
For OSD, it returns a formatted list. Trying to retrieve this property as
|
|
|
|
a raw string doesn't work.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-02-19 15:16:42 +00:00
|
|
|
This has a number of sub-properties:
|
|
|
|
|
|
|
|
``metadata/by-key/<key>``
|
|
|
|
Value of metadata entry ``<key>``.
|
|
|
|
|
2014-02-19 15:29:04 +00:00
|
|
|
``metadata/list/count``
|
|
|
|
Number of metadata entries.
|
|
|
|
|
2014-02-21 12:19:09 +00:00
|
|
|
``metadata/list/N/key``
|
2014-02-19 15:29:04 +00:00
|
|
|
Key name of the Nth metadata entry. (The first entry is ``0``).
|
|
|
|
|
|
|
|
``metadata/list/N/value``
|
|
|
|
Value of the Nth metadata entry.
|
|
|
|
|
2014-02-19 15:16:42 +00:00
|
|
|
``metadata/<key>``
|
|
|
|
Old version of ``metadata/by-key/<key>``. Use is discouraged, because
|
|
|
|
the metadata key string could conflict with other sub-properties.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-02-19 15:29:04 +00:00
|
|
|
The layout of this property might be subject to change. Suggestions are
|
|
|
|
welcome how exactly this property should work.
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_MAP
|
2014-09-01 02:25:57 +00:00
|
|
|
(key and string value for each metadata entry)
|
2014-04-10 23:00:13 +00:00
|
|
|
|
2014-12-29 22:03:39 +00:00
|
|
|
``filtered-metadata``
|
|
|
|
Like ``metadata``, but includes only fields listed in the ``--display-tags``
|
|
|
|
option. This is the same set of tags that is printed to the terminal.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``chapter-metadata``
|
2014-04-13 14:08:58 +00:00
|
|
|
Metadata of current chapter. Works similar to ``metadata`` property. It
|
2014-02-19 15:32:54 +00:00
|
|
|
also allows the same access methods (using sub-properties).
|
|
|
|
|
|
|
|
Per-chapter metadata is very rare. Usually, only the chapter name
|
|
|
|
(``title``) is set.
|
|
|
|
|
|
|
|
For accessing other information, like chapter start, see the
|
|
|
|
``chapter-list`` property.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-04-13 14:08:58 +00:00
|
|
|
``vf-metadata/<filter-label>``
|
|
|
|
Metadata added by video filters. Accessed by the filter label,
|
2015-12-19 08:26:27 +00:00
|
|
|
which, if not explicitly specified using the ``@filter-label:`` syntax,
|
2014-04-13 14:08:58 +00:00
|
|
|
will be ``<filter-name>NN``.
|
|
|
|
|
|
|
|
Works similar to ``metadata`` property. It allows the same access
|
|
|
|
methods (using sub-properties).
|
|
|
|
|
2015-12-19 08:26:27 +00:00
|
|
|
An example of this kind of metadata are the cropping parameters
|
2014-04-13 14:08:58 +00:00
|
|
|
added by ``--vf=lavfi=cropdetect``.
|
|
|
|
|
2015-09-11 21:04:02 +00:00
|
|
|
``af-metadata/<filter-label>``
|
|
|
|
Equivalent to ``vf-metadata/<filter-label>``, but for audio filters.
|
|
|
|
|
2016-09-01 18:01:02 +00:00
|
|
|
``idle-active``
|
2014-12-10 13:42:57 +00:00
|
|
|
Return ``yes`` if no file is loaded, but the player is staying around
|
|
|
|
because of the ``--idle`` option.
|
|
|
|
|
2016-09-01 18:01:02 +00:00
|
|
|
(Renamed from ``idle``.)
|
|
|
|
|
2014-04-14 20:03:43 +00:00
|
|
|
``core-idle``
|
|
|
|
Return ``yes`` if the playback core is paused, otherwise ``no``. This can
|
|
|
|
be different ``pause`` in special situations, such as when the player
|
|
|
|
pauses itself due to low network cache.
|
|
|
|
|
2014-10-07 19:01:19 +00:00
|
|
|
This also returns ``yes`` if playback is restarting or if nothing is
|
|
|
|
playing at all. In other words, it's only ``no`` if there's actually
|
|
|
|
video playing. (Behavior since mpv 0.7.0.)
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``cache``
|
2014-07-01 22:14:30 +00:00
|
|
|
Network cache fill state (0-100.0).
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-04-09 17:15:23 +00:00
|
|
|
``cache-size`` (RW)
|
2015-09-10 12:10:44 +00:00
|
|
|
Network cache size in KB. This is similar to ``--cache``. This allows
|
2015-12-19 08:26:27 +00:00
|
|
|
setting the cache size at runtime. Currently, it's not possible to enable
|
2014-04-09 17:15:23 +00:00
|
|
|
or disable the cache at runtime using this property, just to resize an
|
|
|
|
existing cache.
|
|
|
|
|
2015-09-10 12:10:44 +00:00
|
|
|
This does not include the backbuffer size (changed after mpv 0.10.0).
|
|
|
|
|
2014-04-09 17:15:23 +00:00
|
|
|
Note that this tries to keep the cache contents as far as possible. To make
|
|
|
|
this easier, the cache resizing code will allocate the new cache while the
|
|
|
|
old cache is still allocated.
|
|
|
|
|
2014-09-01 02:25:57 +00:00
|
|
|
Don't use this when playing DVD or Blu-ray.
|
2014-04-09 17:15:23 +00:00
|
|
|
|
2014-07-01 22:14:30 +00:00
|
|
|
``cache-free`` (R)
|
2014-07-31 02:25:39 +00:00
|
|
|
Total free cache size in KB.
|
2014-07-01 22:14:30 +00:00
|
|
|
|
|
|
|
``cache-used`` (R)
|
2014-07-31 02:25:39 +00:00
|
|
|
Total used cache size in KB.
|
|
|
|
|
2016-03-20 18:48:55 +00:00
|
|
|
``cache-speed`` (R)
|
|
|
|
Current I/O read speed between the cache and the lower layer (like network).
|
2016-03-22 21:29:15 +00:00
|
|
|
This gives the number bytes per seconds over a 1 second window (using
|
|
|
|
the type ``MPV_FORMAT_INT64`` for the client API).
|
2016-03-20 18:48:55 +00:00
|
|
|
|
2014-07-31 02:25:39 +00:00
|
|
|
``cache-idle`` (R)
|
|
|
|
Returns ``yes`` if the cache is idle, which means the cache is filled as
|
|
|
|
much as possible, and is currently not reading more data.
|
2014-07-01 22:14:30 +00:00
|
|
|
|
2014-08-28 15:48:31 +00:00
|
|
|
``demuxer-cache-duration``
|
|
|
|
Approximate duration of video buffered in the demuxer, in seconds. The
|
|
|
|
guess is very unreliable, and often the property will not be available
|
|
|
|
at all, even if data is buffered.
|
|
|
|
|
2015-04-20 21:47:13 +00:00
|
|
|
``demuxer-cache-time``
|
|
|
|
Approximate time of video buffered in the demuxer, in seconds. Same as
|
2015-06-17 20:23:08 +00:00
|
|
|
``demuxer-cache-duration`` but returns the last timestamp of buffered
|
2015-04-20 21:47:13 +00:00
|
|
|
data in demuxer.
|
|
|
|
|
2014-08-28 15:48:31 +00:00
|
|
|
``demuxer-cache-idle``
|
|
|
|
Returns ``yes`` if the demuxer is idle, which means the demuxer cache is
|
|
|
|
filled to the requested amount, and is currently not reading more data.
|
|
|
|
|
2017-10-21 19:13:53 +00:00
|
|
|
``demuxer-cache-state``
|
2017-10-26 20:26:43 +00:00
|
|
|
Various undocumented or half-documented things.
|
2017-10-21 19:13:53 +00:00
|
|
|
|
2017-10-26 20:26:43 +00:00
|
|
|
Each entry in ``seekable-ranges`` represents a region in the demuxer cache
|
|
|
|
that can be seeked to. If there are multiple demuxers active, this only
|
|
|
|
returns information about the "main" demuxer, but might be changed in
|
demux: support multiple seekable cached ranges
Until now, the demuxer cache was limited to a single range. Extend this
to multiple range. Should be useful for slow network streams.
This commit changes a lot in the internal demuxer cache logic, so
there's a lot of room for bugs and regressions. The logic without
demuxer cache is mostly untouched, but also involved with the code
changes. Or in other words, this commit probably fucks up shit.
There are two things which makes multiple cached ranges rather hard:
1. the need to resume the demuxer at the end of a cached range when
seeking to it
2. joining two adjacent ranges when the lowe range "grows" into it (and
resuming the demuxer at the end of the new joined range)
"Resuming" the demuxer means that we perform a low level seek to the end
of a cached range, and properly append new packets to it, without adding
packets multiple times or creating holes due to missing packets.
Since audio and video never line up exactly, there is no clean "cut"
possible, at which you could resume the demuxer cleanly (for 1.) or
which you could use to detect that two ranges are perfectly adjacent
(for 2.). The way how the demuxer interleaves multiple streams is also
unpredictable. Typically you will have to expect that it randomly allows
one of the streams to be ahead by a bit, and so on.
To deal with this, we have heuristics in place to detect when one packet
equals or is "behind" a packet that was demuxed earlier. We reuse the
refresh seek logic (used to "reread" packets into the demuxer cache when
enabling a track), which checks for certain packet invariants.
Currently, it observes whether either the raw packet position, or the
packet DTS is strictly monotonically increasing. If none of them are
true, we discard old ranges when creating a new one.
This heavily depends on the file format and the demuxer behavior. For
example, not all file formats have DTS, and the packet position can be
unset due to libavformat not always setting it (e.g. when parsers are
used).
At the same time, we must deal with all the complicated state used to
track prefetching and seek ranges. In some complicated corner cases, we
just give up and discard other seek ranges, even if the previously
mentioned packet invariants are fulfilled.
To handle joining, we're being particularly dumb, and require a small
overlap to be confident that two ranges join perfectly. (This could be
done incrementally with as little overlap as 1 packet, but corner cases
would eat us: each stream needs to be joined separately, and the cache
pruning logic could remove overlapping packets for other streams again.)
Another restriction is that switching the cached range will always
trigger an asynchronous low level seek to resume demuxing at the new
range. Some users might find this annoying.
Dealing with interleaved subtitles is not fully handled yet. It will
clamp the seekable range to where subtitle packets are.
2017-11-09 08:53:46 +00:00
|
|
|
future to return unified information about all demuxers. The ranges are in
|
|
|
|
arbitrary order. Often, ranges will overlap for a bit, before being joined.
|
|
|
|
In broken corner cases, ranges may overlap all over the place.
|
2017-10-21 19:13:53 +00:00
|
|
|
|
2017-11-04 22:02:25 +00:00
|
|
|
The end of a seek range is usually smaller than the value returned by the
|
|
|
|
``demuxer-cache-time`` property, because that property returns the guessed
|
|
|
|
buffering amount, while the seek ranges represent the buffered data that
|
|
|
|
can actually be used for cached seeking.
|
|
|
|
|
2017-12-17 21:11:10 +00:00
|
|
|
``fw-bytes`` is the number of bytes of packets buffered in the range
|
|
|
|
starting from the current decoding position.
|
|
|
|
|
2017-10-21 19:13:53 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2017-10-26 20:26:43 +00:00
|
|
|
MPV_FORMAT_NODE_MAP
|
|
|
|
"seekable-ranges" MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP
|
|
|
|
"start" MPV_FORMAT_DOUBLE
|
|
|
|
"end" MPV_FORMAT_DOUBLE
|
2017-12-17 21:11:10 +00:00
|
|
|
"fw-bytes" MPV_FORMAT_INT64
|
2017-10-21 19:13:53 +00:00
|
|
|
|
2017-11-10 15:43:09 +00:00
|
|
|
Other fields (might be changed or removed in the future):
|
|
|
|
|
|
|
|
``eof``
|
|
|
|
True if the reader thread has hit the end of the file.
|
|
|
|
|
|
|
|
``underrun``
|
|
|
|
True if the reader thread could not satisfy a decoder's request for a
|
|
|
|
new packet.
|
|
|
|
|
|
|
|
``idle``
|
|
|
|
True if the thread is currently not reading.
|
|
|
|
|
|
|
|
``total-bytes``
|
|
|
|
Sum of packet bytes (plus some overhead estimation) of the entire packet
|
|
|
|
queue, including cached seekable ranges.
|
|
|
|
|
|
|
|
``fw-bytes``
|
|
|
|
Sum of packet bytes (plus some overhead estimation) of the readahead
|
|
|
|
packet queue (packets between current decoder reader positions and
|
|
|
|
demuxer position).
|
|
|
|
|
2017-03-24 14:31:01 +00:00
|
|
|
``demuxer-via-network``
|
|
|
|
Returns ``yes`` if the stream demuxed via the main demuxer is most likely
|
|
|
|
played via network. What constitutes "network" is not always clear, might
|
|
|
|
be used for other types of untrusted streams, could be wrong in certain
|
|
|
|
cases, and its definition might be changing. Also, external files (like
|
|
|
|
separate audio files or streams) do not influence the value of this
|
|
|
|
property (currently).
|
|
|
|
|
2017-03-10 00:44:55 +00:00
|
|
|
``demuxer-start-time`` (R)
|
|
|
|
Returns the start time reported by the demuxer in fractional seconds.
|
|
|
|
|
2014-04-12 18:26:28 +00:00
|
|
|
``paused-for-cache``
|
|
|
|
Returns ``yes`` when playback is paused because of waiting for the cache.
|
|
|
|
|
2014-10-07 20:07:07 +00:00
|
|
|
``cache-buffering-state``
|
|
|
|
Return the percentage (0-100) of the cache fill status until the player
|
|
|
|
will unpause (related to ``paused-for-cache``).
|
|
|
|
|
2014-04-14 20:19:07 +00:00
|
|
|
``eof-reached``
|
|
|
|
Returns ``yes`` if end of playback was reached, ``no`` otherwise. Note
|
|
|
|
that this is usually interesting only if ``--keep-open`` is enabled,
|
|
|
|
since otherwise the player will immediately play the next file (or exit
|
|
|
|
or enter idle mode), and in these cases the ``eof-reached`` property will
|
|
|
|
logically be cleared immediately after it's set.
|
|
|
|
|
2014-08-07 22:13:27 +00:00
|
|
|
``seeking``
|
|
|
|
Returns ``yes`` if the player is currently seeking, or otherwise trying
|
|
|
|
to restart playback. (It's possible that it returns ``yes`` while a file
|
2017-10-11 20:45:47 +00:00
|
|
|
is loadedThis is because the same underlying code is used for seeking and
|
|
|
|
resyncing.)
|
2014-08-07 22:13:27 +00:00
|
|
|
|
2016-01-26 14:12:42 +00:00
|
|
|
``mixer-active``
|
2016-07-09 16:31:18 +00:00
|
|
|
Return ``yes`` if the audio mixer is active, ``no`` otherwise.
|
2016-01-26 14:12:42 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
This option is relatively useless. Before mpv 0.18.1, it could be used to
|
|
|
|
infer behavior of the ``volume`` property.
|
2016-01-26 14:12:42 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
``ao-volume`` (RW)
|
|
|
|
System volume. This property is available only if mpv audio output is
|
|
|
|
currently active, and only if the underlying implementation supports volume
|
|
|
|
control. What this option does depends on the API. For example, on ALSA
|
|
|
|
this usually changes system-wide audio, while with PulseAudio this controls
|
|
|
|
per-application volume.
|
|
|
|
|
|
|
|
``ao-mute`` (RW)
|
|
|
|
Similar to ``ao-volume``, but controls the mute state. May be unimplemented
|
|
|
|
even if ``ao-volume`` works.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
|
|
|
``audio-codec``
|
|
|
|
Audio codec selected for decoding.
|
|
|
|
|
2015-05-22 18:05:04 +00:00
|
|
|
``audio-codec-name``
|
|
|
|
Audio codec.
|
|
|
|
|
2015-05-22 18:23:47 +00:00
|
|
|
``audio-params``
|
|
|
|
Audio format as output by the audio decoder.
|
|
|
|
This has a number of sub-properties:
|
|
|
|
|
|
|
|
``audio-params/format``
|
|
|
|
The sample format as string. This uses the same names as used in other
|
|
|
|
places of mpv.
|
|
|
|
|
|
|
|
``audio-params/samplerate``
|
|
|
|
Samplerate.
|
|
|
|
|
|
|
|
``audio-params/channels``
|
|
|
|
The channel layout as a string. This is similar to what the
|
|
|
|
``--audio-channels`` accepts.
|
|
|
|
|
2015-06-25 17:10:24 +00:00
|
|
|
``audio-params/hr-channels``
|
|
|
|
As ``channels``, but instead of the possibly cryptic actual layout
|
|
|
|
sent to the audio device, return a hopefully more human readable form.
|
|
|
|
(Usually only ``audio-out-params/hr-channels`` makes sense.)
|
|
|
|
|
2015-05-22 18:23:47 +00:00
|
|
|
``audio-params/channel-count``
|
|
|
|
Number of audio channels. This is redundant to the ``channels`` field
|
|
|
|
described above.
|
|
|
|
|
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2015-06-30 10:16:34 +00:00
|
|
|
MPV_FORMAT_NODE_MAP
|
|
|
|
"format" MPV_FORMAT_STRING
|
|
|
|
"samplerate" MPV_FORMAT_INT64
|
|
|
|
"channels" MPV_FORMAT_STRING
|
|
|
|
"channel-count" MPV_FORMAT_INT64
|
|
|
|
"hr-channels" MPV_FORMAT_STRING
|
2015-05-22 18:23:47 +00:00
|
|
|
|
|
|
|
``audio-out-params``
|
|
|
|
Same as ``audio-params``, but the format of the data written to the audio
|
|
|
|
API.
|
|
|
|
|
2015-04-27 15:51:06 +00:00
|
|
|
``colormatrix`` (R)
|
|
|
|
Redirects to ``video-params/colormatrix``. This parameter (as well as
|
|
|
|
similar ones) can be overridden with the ``format`` video filter.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2015-04-27 15:51:06 +00:00
|
|
|
``colormatrix-input-range`` (R)
|
|
|
|
See ``colormatrix``.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2015-04-27 15:51:06 +00:00
|
|
|
``colormatrix-primaries`` (R)
|
|
|
|
See ``colormatrix``.
|
2014-03-26 13:03:24 +00:00
|
|
|
|
2014-04-22 23:17:28 +00:00
|
|
|
``hwdec`` (RW)
|
2015-05-25 19:44:48 +00:00
|
|
|
Reflects the ``--hwdec`` option.
|
|
|
|
|
|
|
|
Writing to it may change the currently used hardware decoder, if possible.
|
|
|
|
(Internally, the player may reinitialize the decoder, and will perform a
|
|
|
|
seek to refresh the video properly.) You can watch the other hwdec
|
|
|
|
properties to see whether this was successful.
|
|
|
|
|
|
|
|
Unlike in mpv 0.9.x and before, this does not return the currently active
|
2016-06-25 10:39:08 +00:00
|
|
|
hardware decoder. Since mpv 0.18.0, ``hwdec-current`` is available for
|
2016-05-04 14:55:26 +00:00
|
|
|
this purpose.
|
|
|
|
|
|
|
|
``hwdec-current``
|
|
|
|
Return the current hardware decoding in use. If decoding is active, return
|
|
|
|
one of the values used by the ``hwdec`` option/property. ``no`` indicates
|
|
|
|
software decoding. If no decoder is loaded, the property is unavailable.
|
|
|
|
|
|
|
|
``hwdec-interop``
|
|
|
|
This returns the currently loaded hardware decoding/output interop driver.
|
|
|
|
This is known only once the VO has opened (and possibly later). With some
|
2018-01-09 12:20:37 +00:00
|
|
|
VOs (like ``gpu``), this might be never known in advance, but only when
|
2016-05-04 14:55:26 +00:00
|
|
|
the decoder attempted to create the hw decoder successfully. (Using
|
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 04:05:00 +00:00
|
|
|
``--gpu-hwdec-interop`` can load it eagerly.) If there are multiple
|
2017-01-17 13:51:08 +00:00
|
|
|
drivers loaded, they will be separated by ``,``.
|
2016-05-04 14:55:26 +00:00
|
|
|
|
|
|
|
If no VO is active or no interop driver is known, this property is
|
|
|
|
unavailable.
|
|
|
|
|
|
|
|
This does not necessarily use the same values as ``hwdec``. There can be
|
|
|
|
multiple interop drivers for the same hardware decoder, depending on
|
|
|
|
platform and VO.
|
2015-05-25 19:44:48 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``video-format``
|
|
|
|
Video format as string.
|
|
|
|
|
|
|
|
``video-codec``
|
|
|
|
Video codec selected for decoding.
|
|
|
|
|
|
|
|
``width``, ``height``
|
|
|
|
Video size. This uses the size of the video as decoded, or if no video
|
|
|
|
frame has been decoded yet, the (possibly incorrect) container indicated
|
|
|
|
size.
|
|
|
|
|
2014-02-15 15:42:48 +00:00
|
|
|
``video-params``
|
|
|
|
Video parameters, as output by the decoder (with overrides like aspect
|
|
|
|
etc. applied). This has a number of sub-properties:
|
|
|
|
|
|
|
|
``video-params/pixelformat``
|
|
|
|
The pixel format as string. This uses the same names as used in other
|
|
|
|
places of mpv.
|
|
|
|
|
2015-01-10 20:16:34 +00:00
|
|
|
``video-params/average-bpp``
|
2015-01-10 18:11:28 +00:00
|
|
|
Average bits-per-pixel as integer. Subsampled planar formats use a
|
|
|
|
different resolution, which is the reason this value can sometimes be
|
|
|
|
odd or confusing. Can be unavailable with some formats.
|
|
|
|
|
2015-01-10 20:16:34 +00:00
|
|
|
``video-params/plane-depth``
|
2015-01-10 18:11:28 +00:00
|
|
|
Bit depth for each color component as integer. This is only exposed
|
|
|
|
for planar or single-component formats, and is unavailable for other
|
|
|
|
formats.
|
2015-01-10 11:29:10 +00:00
|
|
|
|
2014-02-15 15:42:48 +00:00
|
|
|
``video-params/w``, ``video-params/h``
|
|
|
|
Video size as integers, with no aspect correction applied.
|
|
|
|
|
|
|
|
``video-params/dw``, ``video-params/dh``
|
|
|
|
Video size as integers, scaled for correct aspect ratio.
|
|
|
|
|
|
|
|
``video-params/aspect``
|
|
|
|
Display aspect ratio as float.
|
|
|
|
|
|
|
|
``video-params/par``
|
|
|
|
Pixel aspect ratio.
|
|
|
|
|
|
|
|
``video-params/colormatrix``
|
|
|
|
The colormatrix in use as string. (Exact values subject to change.)
|
|
|
|
|
|
|
|
``video-params/colorlevels``
|
|
|
|
The colorlevels as string. (Exact values subject to change.)
|
|
|
|
|
2014-03-26 13:03:24 +00:00
|
|
|
``video-params/primaries``
|
|
|
|
The primaries in use as string. (Exact values subject to change.)
|
|
|
|
|
2015-03-31 02:50:49 +00:00
|
|
|
``video-params/gamma``
|
|
|
|
The gamma function in use as string. (Exact values subject to change.)
|
|
|
|
|
2016-07-09 02:18:45 +00:00
|
|
|
``video-params/sig-peak``
|
|
|
|
The video file's tagged signal peak as float.
|
|
|
|
|
2017-06-14 18:06:56 +00:00
|
|
|
``video-params/light``
|
|
|
|
The light type in use as a string. (Exact values subject to change.)
|
|
|
|
|
2014-02-15 15:42:48 +00:00
|
|
|
``video-params/chroma-location``
|
|
|
|
Chroma location as string. (Exact values subject to change.)
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-04-21 20:54:43 +00:00
|
|
|
``video-params/rotate``
|
|
|
|
Intended display rotation in degrees (clockwise).
|
|
|
|
|
2015-06-23 13:20:21 +00:00
|
|
|
``video-params/stereo-in``
|
|
|
|
Source file stereo 3D mode. (See ``--video-stereo-mode`` option.)
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2015-06-30 10:16:34 +00:00
|
|
|
MPV_FORMAT_NODE_MAP
|
|
|
|
"pixelformat" MPV_FORMAT_STRING
|
|
|
|
"w" MPV_FORMAT_INT64
|
|
|
|
"h" MPV_FORMAT_INT64
|
|
|
|
"dw" MPV_FORMAT_INT64
|
|
|
|
"dh" MPV_FORMAT_INT64
|
|
|
|
"aspect" MPV_FORMAT_DOUBLE
|
|
|
|
"par" MPV_FORMAT_DOUBLE
|
|
|
|
"colormatrix" MPV_FORMAT_STRING
|
|
|
|
"colorlevels" MPV_FORMAT_STRING
|
|
|
|
"primaries" MPV_FORMAT_STRING
|
2016-07-13 09:05:27 +00:00
|
|
|
"gamma" MPV_FORMAT_STRING
|
|
|
|
"sig-peak" MPV_FORMAT_DOUBLE
|
2017-06-14 18:06:56 +00:00
|
|
|
"light" MPV_FORMAT_STRING
|
2015-06-30 10:16:34 +00:00
|
|
|
"chroma-location" MPV_FORMAT_STRING
|
|
|
|
"rotate" MPV_FORMAT_INT64
|
|
|
|
"stereo-in" MPV_FORMAT_STRING
|
2014-04-10 23:00:13 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``dwidth``, ``dheight``
|
|
|
|
Video display size. This is the video size after filters and aspect scaling
|
|
|
|
have been applied. The actual video window size can still be different
|
2014-09-15 16:29:53 +00:00
|
|
|
from this, e.g. if the user resized the video window manually.
|
|
|
|
|
|
|
|
These have the same values as ``video-out-params/dw`` and
|
|
|
|
``video-out-params/dh``.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2016-09-20 13:40:44 +00:00
|
|
|
``video-dec-params``
|
|
|
|
Exactly like ``video-params``, but no overrides applied.
|
|
|
|
|
2014-02-15 15:42:48 +00:00
|
|
|
``video-out-params``
|
|
|
|
Same as ``video-params``, but after video filters have been applied. If
|
|
|
|
there are no video filters in use, this will contain the same values as
|
|
|
|
``video-params``. Note that this is still not necessarily what the video
|
2014-09-15 16:29:53 +00:00
|
|
|
window uses, since the user can change the window size, and all real VOs
|
|
|
|
do their own scaling independently from the filter chain.
|
2014-02-15 15:42:48 +00:00
|
|
|
|
|
|
|
Has the same sub-properties as ``video-params``.
|
|
|
|
|
2015-11-22 17:54:22 +00:00
|
|
|
``video-frame-info``
|
|
|
|
Approximate information of the current frame. Note that if any of these
|
|
|
|
are used on OSD, the information might be off by a few frames due to OSD
|
|
|
|
redrawing and frame display being somewhat disconnected, and you might
|
|
|
|
have to pause and force a redraw.
|
|
|
|
|
2018-03-11 20:53:19 +00:00
|
|
|
Sub-properties::
|
2015-11-22 17:54:22 +00:00
|
|
|
|
2018-03-11 20:53:19 +00:00
|
|
|
video-frame-info/picture-type
|
|
|
|
video-frame-info/interlaced
|
|
|
|
video-frame-info/tff
|
|
|
|
video-frame-info/repeat
|
2015-11-22 17:54:22 +00:00
|
|
|
|
2016-09-01 18:01:02 +00:00
|
|
|
``container-fps``
|
2014-02-15 15:42:48 +00:00
|
|
|
Container FPS. This can easily contain bogus values. For videos that use
|
|
|
|
modern container formats or video codecs, this will often be incorrect.
|
|
|
|
|
2016-09-01 18:01:02 +00:00
|
|
|
(Renamed from ``fps``.)
|
|
|
|
|
2014-05-07 22:49:21 +00:00
|
|
|
``estimated-vf-fps``
|
|
|
|
Estimated/measured FPS of the video filter chain output. (If no filters
|
|
|
|
are used, this corresponds to decoder output.) This uses the average of
|
|
|
|
the 10 past frame durations to calculate the FPS. It will be inaccurate
|
2014-09-01 02:25:57 +00:00
|
|
|
if frame-dropping is involved (such as when framedrop is explicitly
|
2014-05-07 22:49:21 +00:00
|
|
|
enabled, or after precise seeking). Files with imprecise timestamps (such
|
|
|
|
as Matroska) might lead to unstable results.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``window-scale`` (RW)
|
|
|
|
Window size multiplier. Setting this will resize the video window to the
|
|
|
|
values contained in ``dwidth`` and ``dheight`` multiplied with the value
|
|
|
|
set with this property. Setting ``1`` will resize to original video size
|
2014-08-29 18:51:03 +00:00
|
|
|
(or to be exact, the size the video filters output). ``2`` will set the
|
2014-02-12 20:56:43 +00:00
|
|
|
double size, ``0.5`` halves the size.
|
|
|
|
|
2014-11-02 19:48:45 +00:00
|
|
|
``window-minimized``
|
|
|
|
Return whether the video window is minimized or not.
|
|
|
|
|
2014-11-06 02:16:32 +00:00
|
|
|
``display-names``
|
|
|
|
Names of the displays that the mpv window covers. On X11, these
|
2016-09-29 13:21:23 +00:00
|
|
|
are the xrandr names (LVDS1, HDMI1, DP1, VGA1, etc.). On Windows, these
|
|
|
|
are the GDI names (\\.\DISPLAY1, \\.\DISPLAY2, etc.) and the first display
|
|
|
|
in the list will be the one that Windows considers associated with the
|
|
|
|
window (as determined by the MonitorFromWindow API.)
|
2014-11-06 02:16:32 +00:00
|
|
|
|
2015-11-09 12:52:46 +00:00
|
|
|
``display-fps`` (RW)
|
2015-03-10 13:50:56 +00:00
|
|
|
The refresh rate of the current display. Currently, this is the lowest FPS
|
|
|
|
of any display covered by the video, as retrieved by the underlying system
|
2015-03-12 22:41:25 +00:00
|
|
|
APIs (e.g. xrandr on X11). It is not the measured FPS. It's not necessarily
|
|
|
|
available on all platforms. Note that any of the listed facts may change
|
|
|
|
any time without a warning.
|
2015-03-10 13:50:56 +00:00
|
|
|
|
2015-11-25 21:07:56 +00:00
|
|
|
``estimated-display-fps``
|
|
|
|
Only available if display-sync mode (as selected by ``--video-sync``) is
|
|
|
|
active. Returns the actual rate at which display refreshes seem to occur,
|
|
|
|
measured by system time.
|
|
|
|
|
|
|
|
``vsync-jitter``
|
|
|
|
Estimated deviation factor of the vsync duration.
|
|
|
|
|
2014-04-24 16:10:20 +00:00
|
|
|
``video-aspect`` (RW)
|
|
|
|
Video aspect, see ``--video-aspect``.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2016-09-01 18:00:43 +00:00
|
|
|
If video is active, this reports the effective aspect value, instead of
|
|
|
|
the value of the ``--video-aspect`` option.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``osd-width``, ``osd-height``
|
|
|
|
Last known OSD width (can be 0). This is needed if you want to use the
|
2016-07-14 18:04:59 +00:00
|
|
|
``overlay-add`` command. It gives you the actual OSD size, which can be
|
2014-02-12 20:56:43 +00:00
|
|
|
different from the window size in some cases.
|
|
|
|
|
|
|
|
``osd-par``
|
|
|
|
Last known OSD display pixel aspect (can be 0).
|
|
|
|
|
|
|
|
``program`` (W)
|
|
|
|
Switch TS program (write-only).
|
|
|
|
|
2016-01-08 19:40:57 +00:00
|
|
|
``dvb-channel`` (W)
|
|
|
|
Pair of integers: card,channel of current DVB stream.
|
2016-09-29 13:21:23 +00:00
|
|
|
Can be switched to switch to another channel on the same card.
|
2016-01-08 19:40:57 +00:00
|
|
|
|
|
|
|
``dvb-channel-name`` (RW)
|
|
|
|
Name of current DVB program.
|
|
|
|
On write, a channel-switch to the named channel on the same
|
2016-09-29 13:21:23 +00:00
|
|
|
card is performed. Can also be used for channel switching.
|
2016-01-08 19:40:57 +00:00
|
|
|
|
2016-08-27 19:14:41 +00:00
|
|
|
``sub-text``
|
|
|
|
Return the current subtitle text. Formatting is stripped. If a subtitle
|
|
|
|
is selected, but no text is currently visible, or the subtitle is not
|
|
|
|
text-based (i.e. DVD/BD subtitles), an empty string is returned.
|
|
|
|
|
|
|
|
This property is experimental and might be removed in the future.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``tv-brightness``, ``tv-contrast``, ``tv-saturation``, ``tv-hue`` (RW)
|
|
|
|
TV stuff.
|
|
|
|
|
|
|
|
``playlist-pos`` (RW)
|
|
|
|
Current position on playlist. The first entry is on position 0. Writing
|
|
|
|
to the property will restart playback at the written entry.
|
|
|
|
|
2016-05-26 16:43:49 +00:00
|
|
|
``playlist-pos-1`` (RW)
|
|
|
|
Same as ``playlist-pos``, but 1-based.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``playlist-count``
|
|
|
|
Number of total playlist entries.
|
|
|
|
|
|
|
|
``playlist``
|
|
|
|
Playlist, current entry marked. Currently, the raw property value is
|
|
|
|
useless.
|
|
|
|
|
2014-02-15 15:54:55 +00:00
|
|
|
This has a number of sub-properties. Replace ``N`` with the 0-based playlist
|
|
|
|
entry index.
|
|
|
|
|
|
|
|
``playlist/count``
|
|
|
|
Number of playlist entries (same as ``playlist-count``).
|
|
|
|
|
|
|
|
``playlist/N/filename``
|
|
|
|
Filename of the Nth entry.
|
|
|
|
|
2014-11-17 21:43:30 +00:00
|
|
|
``playlist/N/current``, ``playlist/N/playing``
|
2014-11-17 21:07:50 +00:00
|
|
|
``yes`` if this entry is currently playing (or being loaded).
|
2014-11-17 21:43:30 +00:00
|
|
|
Unavailable or ``no`` otherwise. When changing files, ``current`` and
|
|
|
|
``playing`` can be different, because the currently playing file hasn't
|
|
|
|
been unloaded yet; in this case, ``current`` refers to the new
|
|
|
|
selection. (Since mpv 0.7.0.)
|
2014-11-17 21:07:50 +00:00
|
|
|
|
2015-07-10 19:22:35 +00:00
|
|
|
``playlist/N/title``
|
|
|
|
Name of the Nth entry. Only available if the playlist file contains
|
|
|
|
such fields, and only if mpv's parser supports it for the given
|
|
|
|
playlist format.
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each playlist entry)
|
|
|
|
"filename" MPV_FORMAT_STRING
|
2014-11-17 21:43:30 +00:00
|
|
|
"current" MPV_FORMAT_FLAG (might be missing; since mpv 0.7.0)
|
|
|
|
"playing" MPV_FORMAT_FLAG (same)
|
2015-07-10 19:22:35 +00:00
|
|
|
"title" MPV_FORMAT_STRING (optional)
|
2014-04-10 23:00:13 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``track-list``
|
|
|
|
List of audio/video/sub tracks, current entry marked. Currently, the raw
|
|
|
|
property value is useless.
|
|
|
|
|
2014-02-15 15:53:11 +00:00
|
|
|
This has a number of sub-properties. Replace ``N`` with the 0-based track
|
|
|
|
index.
|
|
|
|
|
|
|
|
``track-list/count``
|
|
|
|
Total number of tracks.
|
|
|
|
|
|
|
|
``track-list/N/id``
|
|
|
|
The ID as it's used for ``-sid``/``--aid``/``--vid``. This is unique
|
|
|
|
within tracks of the same type (sub/audio/video), but otherwise not.
|
|
|
|
|
|
|
|
``track-list/N/type``
|
|
|
|
String describing the media type. One of ``audio``, ``video``, ``sub``.
|
|
|
|
|
|
|
|
``track-list/N/src-id``
|
|
|
|
Track ID as used in the source file. Not always available.
|
|
|
|
|
|
|
|
``track-list/N/title``
|
|
|
|
Track title as it is stored in the file. Not always available.
|
|
|
|
|
|
|
|
``track-list/N/lang``
|
|
|
|
Track language as identified by the file. Not always available.
|
|
|
|
|
|
|
|
``track-list/N/albumart``
|
|
|
|
``yes`` if this is a video track that consists of a single picture,
|
|
|
|
``no`` or unavailable otherwise. This is used for video tracks that are
|
|
|
|
really attached pictures in audio files.
|
|
|
|
|
|
|
|
``track-list/N/default``
|
|
|
|
``yes`` if the track has the default flag set in the file, ``no``
|
|
|
|
otherwise.
|
|
|
|
|
2015-06-28 11:23:16 +00:00
|
|
|
``track-list/N/forced``
|
2015-06-27 20:02:24 +00:00
|
|
|
``yes`` if the track has the forced flag set in the file, ``no``
|
|
|
|
otherwise.
|
|
|
|
|
2014-02-18 23:21:56 +00:00
|
|
|
``track-list/N/codec``
|
|
|
|
The codec name used by this track, for example ``h264``. Unavailable
|
|
|
|
in some rare cases.
|
|
|
|
|
2014-02-15 15:53:11 +00:00
|
|
|
``track-list/N/external``
|
|
|
|
``yes`` if the track is an external file, ``no`` otherwise. This is
|
|
|
|
set for separate subtitle files.
|
|
|
|
|
|
|
|
``track-list/N/external-filename``
|
|
|
|
The filename if the track is from an external file, unavailable
|
|
|
|
otherwise.
|
|
|
|
|
|
|
|
``track-list/N/selected``
|
|
|
|
``yes`` if the track is currently decoded, ``no`` otherwise.
|
|
|
|
|
2015-04-23 18:34:30 +00:00
|
|
|
``track-list/N/ff-index``
|
|
|
|
The stream index as usually used by the FFmpeg utilities. Note that
|
|
|
|
this can be potentially wrong if a demuxer other than libavformat
|
|
|
|
(``--demuxer=lavf``) is used. For mkv files, the index will usually
|
|
|
|
match even if the default (builtin) demuxer is used, but there is
|
|
|
|
no hard guarantee.
|
|
|
|
|
2016-02-29 19:55:44 +00:00
|
|
|
``track-list/N/decoder-desc``
|
|
|
|
If this track is being decoded, the human-readable decoder name,
|
|
|
|
|
|
|
|
``track-list/N/demux-w``, ``track-list/N/demux-h``
|
|
|
|
Video size hint as indicated by the container. (Not always accurate.)
|
|
|
|
|
|
|
|
``track-list/N/demux-channel-count``
|
|
|
|
Number of audio channels as indicated by the container. (Not always
|
|
|
|
accurate - in particular, the track could be decoded as a different
|
|
|
|
number of channels.)
|
|
|
|
|
|
|
|
``track-list/N/demux-channels``
|
|
|
|
Channel layout as indicated by the container. (Not always accurate.)
|
|
|
|
|
|
|
|
``track-list/N/demux-samplerate``
|
|
|
|
Audio sample rate as indicated by the container. (Not always accurate.)
|
|
|
|
|
|
|
|
``track-list/N/demux-fps``
|
|
|
|
Video FPS as indicated by the container. (Not always accurate.)
|
|
|
|
|
|
|
|
``track-list/N/audio-channels`` (deprecated)
|
|
|
|
Deprecated alias for ``track-list/N/demux-channel-count``.
|
|
|
|
|
2016-08-13 13:21:09 +00:00
|
|
|
``track-list/N/replaygain-track-peak``, ``track-list/N/replaygain-track-gain``
|
|
|
|
Per-track replaygain values. Only available for audio tracks with
|
|
|
|
corresponding information stored in the source file.
|
|
|
|
|
|
|
|
``track-list/N/replaygain-album-peak``, ``track-list/N/replaygain-album-gain``
|
|
|
|
Per-album replaygain values. If the file has per-track but no per-album
|
|
|
|
information, the per-album values will be copied from the per-track
|
|
|
|
values currently. It's possible that future mpv versions will make
|
|
|
|
these properties unavailable instead in this case.
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each track)
|
|
|
|
"id" MPV_FORMAT_INT64
|
|
|
|
"type" MPV_FORMAT_STRING
|
|
|
|
"src-id" MPV_FORMAT_INT64
|
|
|
|
"title" MPV_FORMAT_STRING
|
|
|
|
"lang" MPV_FORMAT_STRING
|
|
|
|
"albumart" MPV_FORMAT_FLAG
|
|
|
|
"default" MPV_FORMAT_FLAG
|
2015-06-27 20:02:24 +00:00
|
|
|
"forced" MPV_FORMAT_FLAG
|
2016-05-11 17:12:49 +00:00
|
|
|
"selected" MPV_FORMAT_FLAG
|
2014-04-10 23:00:13 +00:00
|
|
|
"external" MPV_FORMAT_FLAG
|
|
|
|
"external-filename" MPV_FORMAT_STRING
|
|
|
|
"codec" MPV_FORMAT_STRING
|
2016-05-11 17:12:49 +00:00
|
|
|
"ff-index" MPV_FORMAT_INT64
|
2016-02-29 19:55:44 +00:00
|
|
|
"decoder-desc" MPV_FORMAT_STRING
|
|
|
|
"demux-w" MPV_FORMAT_INT64
|
|
|
|
"demux-h" MPV_FORMAT_INT64
|
|
|
|
"demux-channel-count" MPV_FORMAT_INT64
|
|
|
|
"demux-channels" MPV_FORMAT_STRING
|
|
|
|
"demux-samplerate" MPV_FORMAT_INT64
|
|
|
|
"demux-fps" MPV_FORMAT_DOUBLE
|
|
|
|
"audio-channels" MPV_FORMAT_INT64
|
2016-08-13 13:21:09 +00:00
|
|
|
"replaygain-track-peak" MPV_FORMAT_DOUBLE
|
|
|
|
"replaygain-track-gain" MPV_FORMAT_DOUBLE
|
|
|
|
"replaygain-album-peak" MPV_FORMAT_DOUBLE
|
|
|
|
"replaygain-album-gain" MPV_FORMAT_DOUBLE
|
2014-04-10 23:00:13 +00:00
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``chapter-list``
|
|
|
|
List of chapters, current entry marked. Currently, the raw property value
|
|
|
|
is useless.
|
|
|
|
|
2014-02-15 15:55:40 +00:00
|
|
|
This has a number of sub-properties. Replace ``N`` with the 0-based chapter
|
|
|
|
index.
|
|
|
|
|
|
|
|
``chapter-list/count``
|
|
|
|
Number of chapters.
|
|
|
|
|
|
|
|
``chapter-list/N/title``
|
|
|
|
Chapter title as stored in the file. Not always available.
|
|
|
|
|
|
|
|
``chapter-list/N/time``
|
|
|
|
Chapter start time in seconds as float.
|
|
|
|
|
2014-04-10 23:00:13 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each chapter)
|
|
|
|
"title" MPV_FORMAT_STRING
|
|
|
|
"time" MPV_FORMAT_DOUBLE
|
|
|
|
|
2016-09-01 18:00:43 +00:00
|
|
|
``af``, ``vf`` (RW)
|
|
|
|
See ``--vf``/``--af`` and the ``vf``/``af`` command.
|
2014-02-12 20:56:43 +00:00
|
|
|
|
2014-04-24 00:14:27 +00:00
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each filter entry)
|
|
|
|
"name" MPV_FORMAT_STRING
|
|
|
|
"label" MPV_FORMAT_STRING [optional]
|
2017-03-25 17:13:04 +00:00
|
|
|
"enabled" MPV_FORMAT_FLAG [optional]
|
2014-04-24 00:14:27 +00:00
|
|
|
"params" MPV_FORMAT_NODE_MAP [optional]
|
|
|
|
"key" MPV_FORMAT_STRING
|
|
|
|
"value" MPV_FORMAT_STRING
|
|
|
|
|
|
|
|
It's also possible to write the property using this format.
|
|
|
|
|
2014-02-28 19:57:54 +00:00
|
|
|
``seekable``
|
|
|
|
Return whether it's generally possible to seek in the current file.
|
|
|
|
|
2015-01-26 12:46:33 +00:00
|
|
|
``partially-seekable``
|
|
|
|
Return ``yes`` if the current file is considered seekable, but only because
|
|
|
|
the cache is active. This means small relative seeks may be fine, but larger
|
|
|
|
seeks may fail anyway. Whether a seek will succeed or not is generally not
|
|
|
|
known in advance.
|
|
|
|
|
|
|
|
If this property returns true, ``seekable`` will also return true.
|
|
|
|
|
2014-10-21 11:32:30 +00:00
|
|
|
``playback-abort``
|
|
|
|
Return whether playback is stopped or is to be stopped. (Useful in obscure
|
|
|
|
situations like during ``on_load`` hook processing, when the user can
|
|
|
|
stop playback, but the script has to explicitly end processing.)
|
|
|
|
|
2014-10-21 11:41:19 +00:00
|
|
|
``cursor-autohide`` (RW)
|
|
|
|
See ``--cursor-autohide``. Setting this to a new value will always update
|
|
|
|
the cursor, and reset the internal timer.
|
|
|
|
|
2014-09-17 22:12:59 +00:00
|
|
|
``osd-sym-cc``
|
|
|
|
Inserts the current OSD symbol as opaque OSD control code (cc). This makes
|
2015-05-25 19:59:44 +00:00
|
|
|
sense only with the ``show-text`` command or options which set OSD messages.
|
2014-09-17 22:49:55 +00:00
|
|
|
The control code is implementation specific and is useless for anything else.
|
|
|
|
|
|
|
|
``osd-ass-cc``
|
|
|
|
``${osd-ass-cc/0}`` disables escaping ASS sequences of text in OSD,
|
|
|
|
``${osd-ass-cc/1}`` enables it again. By default, ASS sequences are
|
|
|
|
escaped to avoid accidental formatting, and this property can disable
|
|
|
|
this behavior. Note that the properties return an opaque OSD control
|
2015-05-25 19:59:44 +00:00
|
|
|
code, which only makes sense for the ``show-text`` command or options
|
2014-09-17 22:49:55 +00:00
|
|
|
which set OSD messages.
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
2015-01-16 11:17:47 +00:00
|
|
|
- ``--osd-status-msg='This is ${osd-ass-cc/0}{\\b1}bold text'``
|
2015-05-25 19:59:44 +00:00
|
|
|
- ``show-text "This is ${osd-ass-cc/0}{\b1}bold text"``
|
2014-09-17 22:49:55 +00:00
|
|
|
|
|
|
|
Any ASS override tags as understood by libass can be used.
|
|
|
|
|
|
|
|
Note that you need to escape the ``\`` character, because the string is
|
|
|
|
processed for C escape sequences before passing it to the OSD code.
|
2014-09-17 22:12:59 +00:00
|
|
|
|
2015-01-16 11:17:47 +00:00
|
|
|
A list of tags can be found here: http://docs.aegisub.org/latest/ASS_Tags/
|
|
|
|
|
2014-10-24 13:34:53 +00:00
|
|
|
``vo-configured``
|
|
|
|
Return whether the VO is configured right now. Usually this corresponds to
|
|
|
|
whether the video window is visible. If the ``--force-window`` option is
|
|
|
|
used, this is usually always returns ``yes``.
|
|
|
|
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
``vo-passes``
|
|
|
|
Contains introspection about the VO's active render passes and their
|
|
|
|
execution times. Not implemented by all VOs.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
This is further subdivided into two frame types, ``vo-passes/fresh`` for
|
|
|
|
fresh frames (which have to be uploaded, scaled, etc.) and
|
|
|
|
``vo-passes/redraw`` for redrawn frames (which only have to be re-painted).
|
|
|
|
The number of passes for any given subtype can change from frame to frame,
|
|
|
|
and should not be relied upon.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
Each frame type has a number of further sub-properties. Replace ``TYPE``
|
|
|
|
with the frame type, ``N`` with the 0-based pass index, and ``M`` with the
|
|
|
|
0-based sample index.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
``vo-passes/TYPE/count``
|
|
|
|
Number of passes.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
``vo-passes/TYPE/N/desc``
|
|
|
|
Human-friendy description of the pass.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
``vo-passes/TYPE/N/last``
|
|
|
|
Last measured execution time, in nanoseconds.
|
|
|
|
|
|
|
|
``vo-passes/TYPE/N/avg``
|
|
|
|
Average execution time of this pass, in nanoseconds. The exact
|
|
|
|
timeframe varies, but it should generally be a handful of seconds.
|
|
|
|
|
|
|
|
``vo-passes/TYPE/N/peak``
|
|
|
|
The peak execution time (highest value) within this averaging range, in
|
|
|
|
nanoseconds.
|
|
|
|
|
|
|
|
``vo-passes/TYPE/N/count``
|
|
|
|
The number of samples for this pass.
|
|
|
|
|
|
|
|
``vo-passes/TYPE/N/samples/M``
|
|
|
|
The raw execution time of a specific sample for this pass, in
|
|
|
|
nanoseconds.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_MAP
|
vo_opengl: refactor vo performance subsystem
This replaces `vo-performance` by `vo-passes`, bringing with it a number
of changes and improvements:
1. mpv users can now introspect the vo_opengl passes, which is something
that has been requested multiple times.
2. performance data is now measured per-pass, which helps both
development and debugging.
3. since adding more passes is cheap, we can now report information for
more passes (e.g. the blit pass, and the osd pass). Note: we also
switch to nanosecond scale, to be able to measure these passes
better.
4. `--user-shaders` authors can now describe their own passes, helping
users both identify which user shaders are active at any given time
as well as helping shader authors identify performance issues.
5. the timing data per pass is now exported as a full list of samples,
so projects like Argon-/mpv-stats can immediately read out all of the
samples and render a graph without having to manually poll this
option constantly.
Due to gl_timer's design being complicated (directly reading performance
data would block, so we delay the actual read-back until the next _start
command), it's vital not to conflate different passes that might be
doing different things from one frame to another. To accomplish this,
the actual timers are stored as part of the gl_shader_cache's sc_entry,
which makes them unique for that exact shader.
Starting and stopping the time measurement is easy to unify with the
gl_sc architecture, because the existing API already relies on a
"generate, render, reset" flow, so we can just put timer_start and
timer_stop in sc_generate and sc_reset, respectively.
The ugliest thing about this code is that due to the need to keep pass
information relatively stable in between frames, we need to distinguish
between "new" and "redrawn" frames, which bloats the code somewhat and
also feels hacky and vo_opengl-specific. (But then again, this entire
thing is vo_opengl-specific)
2017-06-29 15:00:06 +00:00
|
|
|
"TYPE" MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP
|
|
|
|
"desc" MPV_FORMAT_STRING
|
|
|
|
"last" MPV_FORMAT_INT64
|
|
|
|
"avg" MPV_FORMAT_INT64
|
|
|
|
"peak" MPV_FORMAT_INT64
|
|
|
|
"count" MPV_FORMAT_INT64
|
|
|
|
"samples" MPV_FORMAT_NODE_ARRAY
|
|
|
|
MP_FORMAT_INT64
|
|
|
|
|
|
|
|
Note that directly accessing this structure via subkeys is not supported,
|
|
|
|
the only access is through aforementioned ``MPV_FORMAT_NODE``.
|
2016-06-08 09:39:31 +00:00
|
|
|
|
2015-04-20 18:52:16 +00:00
|
|
|
``video-bitrate``, ``audio-bitrate``, ``sub-bitrate``
|
2014-12-12 00:00:58 +00:00
|
|
|
Bitrate values calculated on the packet level. This works by dividing the
|
|
|
|
bit size of all packets between two keyframes by their presentation
|
|
|
|
timestamp distance. (This uses the timestamps are stored in the file, so
|
|
|
|
e.g. playback speed does not influence the returned values.) In particular,
|
|
|
|
the video bitrate will update only per keyframe, and show the "past"
|
|
|
|
bitrate. To make the property more UI friendly, updates to these properties
|
|
|
|
are throttled in a certain way.
|
|
|
|
|
2015-04-20 18:52:16 +00:00
|
|
|
The unit is bits per second. OSD formatting turns these values in kilobits
|
|
|
|
(or megabits, if appropriate), which can be prevented by using the
|
|
|
|
raw property value, e.g. with ``${=video-bitrate}``.
|
|
|
|
|
|
|
|
Note that the accuracy of these properties is influenced by a few factors.
|
|
|
|
If the underlying demuxer rewrites the packets on demuxing (done for some
|
|
|
|
file formats), the bitrate might be slightly off. If timestamps are bad
|
|
|
|
or jittery (like in Matroska), even constant bitrate streams might show
|
|
|
|
fluctuating bitrate.
|
|
|
|
|
2014-12-12 00:00:58 +00:00
|
|
|
How exactly these values are calculated might change in the future.
|
|
|
|
|
2015-04-20 18:52:16 +00:00
|
|
|
In earlier versions of mpv, these properties returned a static (but bad)
|
|
|
|
guess using a completely different method.
|
|
|
|
|
|
|
|
``packet-video-bitrate``, ``packet-audio-bitrate``, ``packet-sub-bitrate``
|
|
|
|
Old and deprecated properties for ``video-bitrate``, ``audio-bitrate``,
|
|
|
|
``sub-bitrate``. They behave exactly the same, but return a value in
|
|
|
|
kilobits. Also, they don't have any OSD formatting, though the same can be
|
|
|
|
achieved with e.g. ``${=video-bitrate}``.
|
|
|
|
|
|
|
|
These properties shouldn't be used anymore.
|
|
|
|
|
2014-10-10 17:46:21 +00:00
|
|
|
``audio-device-list``
|
|
|
|
Return the list of discovered audio devices. This is mostly for use with
|
|
|
|
the client API, and reflects what ``--audio-device=help`` with the command
|
|
|
|
line player returns.
|
|
|
|
|
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each device entry)
|
|
|
|
"name" MPV_FORMAT_STRING
|
|
|
|
"description" MPV_FORMAT_STRING
|
|
|
|
|
|
|
|
The ``name`` is what is to be passed to the ``--audio-device`` option (and
|
|
|
|
often a rather cryptic audio API-specific ID), while ``description`` is
|
2016-11-14 12:33:53 +00:00
|
|
|
human readable free form text. The description is set to the device name
|
|
|
|
(minus mpv-specific ``<driver>/`` prefix) if no description is available
|
|
|
|
or the description would have been an empty string.
|
2014-10-10 17:46:21 +00:00
|
|
|
|
2015-02-12 15:53:56 +00:00
|
|
|
The special entry with the name set to ``auto`` selects the default audio
|
|
|
|
output driver and the default device.
|
|
|
|
|
|
|
|
The property can be watched with the property observation mechanism in
|
|
|
|
the client API and in Lua scripts. (Technically, change notification is
|
|
|
|
enabled the first time this property is read.)
|
|
|
|
|
2014-10-27 11:16:32 +00:00
|
|
|
``audio-device`` (RW)
|
|
|
|
Set the audio device. This directly reads/writes the ``--audio-device``
|
|
|
|
option, but on write accesses, the audio output will be scheduled for
|
|
|
|
reloading.
|
|
|
|
|
|
|
|
Writing this property while no audio output is active will not automatically
|
|
|
|
enable audio. (This is also true in the case when audio was disabled due to
|
|
|
|
reinitialization failure after a previous write access to ``audio-device``.)
|
|
|
|
|
|
|
|
This property also doesn't tell you which audio device is actually in use.
|
|
|
|
|
|
|
|
How these details are handled may change in the future.
|
|
|
|
|
2015-02-02 16:35:31 +00:00
|
|
|
``current-vo``
|
|
|
|
Current video output driver (name as used with ``--vo``).
|
|
|
|
|
|
|
|
``current-ao``
|
|
|
|
Current audio output driver (name as used with ``--ao``).
|
|
|
|
|
2015-03-24 21:00:01 +00:00
|
|
|
``working-directory``
|
|
|
|
Return the working directory of the mpv process. Can be useful for JSON IPC
|
|
|
|
users, because the command line player usually works with relative paths.
|
|
|
|
|
2015-05-23 13:26:55 +00:00
|
|
|
``protocol-list``
|
|
|
|
List of protocol prefixes potentially recognized by the player. They are
|
|
|
|
returned without trailing ``://`` suffix (which is still always required).
|
|
|
|
In some cases, the protocol will not actually be supported (consider
|
|
|
|
``https`` if ffmpeg is not compiled with TLS support).
|
|
|
|
|
2016-02-29 19:57:31 +00:00
|
|
|
``decoder-list``
|
|
|
|
List of decoders supported. This lists decoders which can be passed to
|
|
|
|
``--vd`` and ``--ad``.
|
|
|
|
|
|
|
|
``codec``
|
|
|
|
Canonical codec name, which identifies the format the decoder can
|
|
|
|
handle.
|
|
|
|
|
2016-03-01 20:46:49 +00:00
|
|
|
``driver``
|
2016-02-29 19:57:31 +00:00
|
|
|
The name of the decoder itself. Often, this is the same as ``codec``.
|
|
|
|
Sometimes it can be different. It is used to distinguish multiple
|
|
|
|
decoders for the same codec.
|
|
|
|
|
|
|
|
``description``
|
|
|
|
Human readable description of the decoder and codec.
|
|
|
|
|
|
|
|
When querying the property with the client API using ``MPV_FORMAT_NODE``,
|
|
|
|
or with Lua ``mp.get_property_native``, this will return a mpv_node with
|
|
|
|
the following contents:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
MPV_FORMAT_NODE_ARRAY
|
|
|
|
MPV_FORMAT_NODE_MAP (for each decoder entry)
|
|
|
|
"codec" MPV_FORMAT_STRING
|
2016-03-01 20:46:49 +00:00
|
|
|
"driver" MPV_FORMAT_STRING
|
2016-02-29 19:57:31 +00:00
|
|
|
"description" MPV_FORMAT_STRING
|
|
|
|
|
2016-03-01 20:46:49 +00:00
|
|
|
``encoder-list``
|
|
|
|
List of libavcodec encoders. This has the same format as ``decoder-list``.
|
|
|
|
The encoder names (``driver`` entries) can be passed to ``--ovc`` and
|
|
|
|
``--oac`` (without the ``lavc:`` prefix required by ``--vd`` and ``--ad``).
|
|
|
|
|
2018-01-02 20:46:58 +00:00
|
|
|
``demuxer-lavf-list``
|
|
|
|
List of available libavformat demuxers' names. This can be used to check
|
|
|
|
for support for a specific format or use with ``--demuxer-lavf-format``.
|
|
|
|
|
2014-11-02 16:44:24 +00:00
|
|
|
``mpv-version``
|
|
|
|
Return the mpv version/copyright string. Depending on how the binary was
|
|
|
|
built, it might contain either a release version, or just a git hash.
|
|
|
|
|
2014-11-13 15:18:40 +00:00
|
|
|
``mpv-configuration``
|
|
|
|
Return the configuration arguments which were passed to the build system
|
|
|
|
(typically the way ``./waf configure ...`` was invoked).
|
|
|
|
|
2016-02-29 19:59:20 +00:00
|
|
|
``ffmpeg-version``
|
|
|
|
Return the contents of the ``av_version_info()`` API call. This is a string
|
|
|
|
which identifies the build in some way, either through a release version
|
|
|
|
number, or a git hash. This applies to Libav as well (the property is
|
|
|
|
still named the same.) This property is unavailable if mpv is linked against
|
|
|
|
older FFmpeg and Libav versions.
|
|
|
|
|
2014-02-12 20:56:43 +00:00
|
|
|
``options/<name>`` (RW)
|
2014-02-25 22:59:27 +00:00
|
|
|
Read-only access to value of option ``--<name>``. Most options can be
|
|
|
|
changed at runtime by writing to this property. Note that many options
|
|
|
|
require reloading the file for changes to take effect. If there is an
|
|
|
|
equivalent property, prefer setting the property instead.
|
2014-06-20 20:45:03 +00:00
|
|
|
|
2016-09-01 18:00:43 +00:00
|
|
|
There shouldn't be any reason to access ``options/<name>`` instead of
|
|
|
|
``<name>``, except in situations in which the properties have different
|
|
|
|
behavior or conflicting semantics.
|
|
|
|
|
2014-10-15 20:39:33 +00:00
|
|
|
``file-local-options/<name>``
|
|
|
|
Similar to ``options/<name>``, but when setting an option through this
|
|
|
|
property, the option is reset to its old value once the current file has
|
|
|
|
stopped playing. Trying to write an option while no file is playing (or
|
|
|
|
is being loaded) results in an error.
|
|
|
|
|
|
|
|
(Note that if an option is marked as file-local, even ``options/`` will
|
|
|
|
access the local value, and the ``old`` value, which will be restored on
|
2016-07-09 13:48:27 +00:00
|
|
|
end of playback, cannot be read or written until end of playback.)
|
2014-10-15 20:39:33 +00:00
|
|
|
|
2014-11-13 16:27:31 +00:00
|
|
|
``option-info/<name>``
|
|
|
|
Additional per-option information.
|
2014-11-07 15:33:41 +00:00
|
|
|
|
|
|
|
This has a number of sub-properties. Replace ``<name>`` with the name of
|
2014-11-13 17:00:07 +00:00
|
|
|
a top-level option. No guarantee of stability is given to any of these
|
|
|
|
sub-properties - they may change radically in the feature.
|
|
|
|
|
|
|
|
``option-info/<name>/name``
|
|
|
|
Returns the name of the option.
|
|
|
|
|
|
|
|
``option-info/<name>/type``
|
|
|
|
Return the name of the option type, like ``String`` or ``Integer``.
|
|
|
|
For many complex types, this isn't very accurate.
|
2014-11-07 15:33:41 +00:00
|
|
|
|
2014-11-13 16:27:31 +00:00
|
|
|
``option-info/<name>/set-from-commandline``
|
2014-11-07 15:33:41 +00:00
|
|
|
Return ``yes`` if the option was set from the mpv command line,
|
|
|
|
``no`` otherwise. What this is set to if the option is e.g. changed
|
|
|
|
at runtime is left undefined (meaning it could change in the future).
|
|
|
|
|
2015-07-23 20:59:04 +00:00
|
|
|
``option-info/<name>/set-locally``
|
|
|
|
Return ``yes`` if the option was set per-file. This is the case with
|
|
|
|
automatically loaded profiles, file-dir configs, and other cases. It
|
|
|
|
means the option value will be restored to the value before playback
|
|
|
|
start when playback ends.
|
|
|
|
|
2014-11-13 17:00:07 +00:00
|
|
|
``option-info/<name>/default-value``
|
|
|
|
The default value of the option. May not always be available.
|
|
|
|
|
|
|
|
``option-info/<name>/min``, ``option-info/<name>/max``
|
|
|
|
Integer minimum and maximum values allowed for the option. Only
|
|
|
|
available if the options are numeric, and the minimum/maximum has been
|
|
|
|
set internally. It's also possible that only one of these is set.
|
|
|
|
|
|
|
|
``option-info/<name>/choices``
|
|
|
|
If the option is a choice option, the possible choices. Choices that
|
|
|
|
are integers may or may not be included (they can be implied by ``min``
|
|
|
|
and ``max``). Note that options which behave like choice options, but
|
|
|
|
are not actual choice options internally, may not have this info
|
|
|
|
available.
|
|
|
|
|
2014-08-01 23:35:32 +00:00
|
|
|
``property-list``
|
|
|
|
Return the list of top-level properties.
|
2013-06-08 16:04:36 +00:00
|
|
|
|
2016-08-28 17:42:03 +00:00
|
|
|
``profile-list``
|
|
|
|
Return the list of profiles and their contents. This is highly
|
|
|
|
implementation-specific, and may change any time. Currently, it returns
|
|
|
|
an array of options for each profile. Each option has a name and a value,
|
|
|
|
with the value currently always being a string. Note that the options array
|
|
|
|
is not a map, as order matters and duplicate entries are possible. Recursive
|
|
|
|
profiles are not expanded, and show up as special ``profile`` options.
|
|
|
|
|
2016-09-01 18:57:33 +00:00
|
|
|
Inconsistencies between options and properties
|
|
|
|
----------------------------------------------
|
|
|
|
|
|
|
|
You can access (almost) all options as properties, though there are some
|
|
|
|
caveats with some properties (due to historical reasons):
|
|
|
|
|
|
|
|
``vid``, ``aid``, ``sid``
|
|
|
|
While playback is active, you can set existing tracks only. (The option
|
|
|
|
allows setting any track ID, and which tracks to enable is chosen at
|
|
|
|
loading time.)
|
|
|
|
|
2016-09-17 18:48:22 +00:00
|
|
|
Option changes at runtime are affected by this as well.
|
|
|
|
|
2016-09-01 18:57:33 +00:00
|
|
|
``video-aspect``
|
player: more option/property consistency fixes
Some properties had a different type from their equivalent options (such
as mute, volume, deinterlace, edition). This wasn't really sane, as raw
option values should be always within their bounds. On the other hand,
these properties use a different type to reflect runtime limits (such as
range of available editions), or simply to improve the "UI" (you don't
want to cycle throuhg the completely useless "auto" value when cycling
the "mute" property).
Handle this by making them always return the option type, but also
allowing them to provide a "constricted" type, which is used for UI
purposes. All M_PROPERTY_GET_CONSTRICTED_TYPE changes are related to
this.
One consequence is that you can set the volume property to arbitrary
high values just like with the --volume option, but using the "add"
command it still restricts it to the --volume-max range.
Also deprecate --chapter, as it is grossly incompatible to the chapter
property. We pondered renaming it to --chapters, or introducing a more
powerful --range option, but concluded that --start --end is actually
enough.
These changes appear to take care of the last gross property/option
incompatibilities, although there might still be a few lurking.
2016-09-18 14:06:12 +00:00
|
|
|
While video is active, always returns the effective aspect ratio. Setting
|
|
|
|
a special value (like ``no``, values ``<= 0``) will make the property
|
|
|
|
set this as option, and return whatever actual aspect was derived from the
|
|
|
|
option setting.
|
2016-09-01 18:57:33 +00:00
|
|
|
|
|
|
|
``display-fps``
|
|
|
|
If a VO is created, this will return either the actual display FPS, or
|
|
|
|
an invalid value, instead of the option value.
|
|
|
|
|
2016-09-17 17:08:35 +00:00
|
|
|
``vf``, ``af``
|
|
|
|
If you set the properties during playback, and the filter chain fails to
|
|
|
|
reinitialize, the new value will be rejected. Setting the option or
|
|
|
|
setting the property outside of playback will always succeed/fail in the
|
|
|
|
same way. Also, there are no ``vf-add`` etc. properties, but you can use
|
|
|
|
the ``vf``/``af`` group of commands to achieve the same.
|
|
|
|
|
2016-09-17 18:48:22 +00:00
|
|
|
Option changes at runtime are affected by this as well.
|
|
|
|
|
player: more option/property consistency fixes
Some properties had a different type from their equivalent options (such
as mute, volume, deinterlace, edition). This wasn't really sane, as raw
option values should be always within their bounds. On the other hand,
these properties use a different type to reflect runtime limits (such as
range of available editions), or simply to improve the "UI" (you don't
want to cycle throuhg the completely useless "auto" value when cycling
the "mute" property).
Handle this by making them always return the option type, but also
allowing them to provide a "constricted" type, which is used for UI
purposes. All M_PROPERTY_GET_CONSTRICTED_TYPE changes are related to
this.
One consequence is that you can set the volume property to arbitrary
high values just like with the --volume option, but using the "add"
command it still restricts it to the --volume-max range.
Also deprecate --chapter, as it is grossly incompatible to the chapter
property. We pondered renaming it to --chapters, or introducing a more
powerful --range option, but concluded that --start --end is actually
enough.
These changes appear to take care of the last gross property/option
incompatibilities, although there might still be a few lurking.
2016-09-18 14:06:12 +00:00
|
|
|
``edition``
|
|
|
|
While a file is loaded, the property will always return the effective
|
|
|
|
edition, and setting the ``auto`` value will show somewhat strange behavior
|
|
|
|
(the property eventually switching to whatever is the default edition).
|
2016-09-18 09:58:24 +00:00
|
|
|
|
2016-09-17 17:08:35 +00:00
|
|
|
``playlist``
|
|
|
|
The property is read-only and returns the current internal playlist. The
|
|
|
|
option is for loading playlist during command line parsing. For client API
|
|
|
|
uses, you should use the ``loadlist`` command instead.
|
|
|
|
|
2016-09-18 11:59:46 +00:00
|
|
|
``window-scale``
|
|
|
|
Might verify the set value when setting while a window is created.
|
|
|
|
|
2016-09-03 11:05:19 +00:00
|
|
|
``audio-file``, ``sub-file``, ``external-file``
|
|
|
|
These options/properties are actually lists of filenames. To make the
|
|
|
|
command-line interface easier, each ``--audio-file=...`` option appends
|
|
|
|
the full string to the internal list. However, when used as properties,
|
|
|
|
every time you set the property as a string the internal list will be
|
|
|
|
replaced with a single entry containing the string you set. ``,`` or other
|
|
|
|
separators are never used. You have to use ``MPV_FORMAT_NODE_ARRAY`` (or
|
|
|
|
corresponding API, e.g. ``mp.set_property_native()`` with a table in Lua)
|
|
|
|
to set multiple entries.
|
|
|
|
|
|
|
|
Strictly speaking, option access via API (e.g. ``mpv_set_option_string()``)
|
|
|
|
has the same problem, and it's only a difference between CLI/API.
|
|
|
|
|
2016-11-22 14:38:01 +00:00
|
|
|
``playlist-pos``, ``chapter``
|
|
|
|
These properties behave different from the deprecated options with the same
|
|
|
|
names.
|
2016-09-01 18:57:33 +00:00
|
|
|
|
2017-06-15 13:22:06 +00:00
|
|
|
``profile``, ``include``
|
|
|
|
These are write-only, and will perform actions as they are written to,
|
|
|
|
exactly as if they were used on the mpv CLI commandline. Their only use is
|
|
|
|
when using libmpv before ``mpv_initialize()``, which in turn is probably
|
|
|
|
only useful in encoding mode. Normal libmpv users should use other
|
|
|
|
mechanisms, such as the ``apply-profile`` command, and the
|
|
|
|
``mpv_load_config_file`` API function. Avoid these properties.
|
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
Property Expansion
|
2013-06-08 16:04:36 +00:00
|
|
|
------------------
|
|
|
|
|
|
|
|
All string arguments to input commands as well as certain options (like
|
2015-05-13 18:44:41 +00:00
|
|
|
``--term-playing-msg``) are subject to property expansion. Note that property
|
|
|
|
expansion does not work in places where e.g. numeric parameters are expected.
|
|
|
|
(For example, the ``add`` command does not do property expansion. The ``set``
|
|
|
|
command is an exception and not a general rule.)
|
2013-06-08 16:04:36 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Example for input.conf
|
2013-06-08 16:04:36 +00:00
|
|
|
|
2015-05-25 19:59:44 +00:00
|
|
|
``i show-text "Filename: ${filename}"``
|
2013-07-08 16:02:14 +00:00
|
|
|
shows the filename of the current file when pressing the ``i`` key
|
2013-06-08 16:04:36 +00:00
|
|
|
|
|
|
|
Within ``input.conf``, property expansion can be inhibited by putting the
|
|
|
|
``raw`` prefix in front of commands.
|
|
|
|
|
|
|
|
The following expansions are supported:
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``${NAME}``
|
2013-06-08 16:04:36 +00:00
|
|
|
Expands to the value of the property ``NAME``. If retrieving the property
|
|
|
|
fails, expand to an error string. (Use ``${NAME:}`` with a trailing
|
|
|
|
``:`` to expand to an empty string instead.)
|
|
|
|
If ``NAME`` is prefixed with ``=``, expand to the raw value of the property
|
2013-09-20 20:53:06 +00:00
|
|
|
(see section below).
|
2013-07-08 16:02:14 +00:00
|
|
|
``${NAME:STR}``
|
2013-06-08 16:04:36 +00:00
|
|
|
Expands to the value of the property ``NAME``, or ``STR`` if the
|
2013-07-08 16:02:14 +00:00
|
|
|
property cannot be retrieved. ``STR`` is expanded recursively.
|
2013-09-20 20:53:06 +00:00
|
|
|
``${?NAME:STR}``
|
|
|
|
Expands to ``STR`` (recursively) if the property ``NAME`` is available.
|
2013-07-08 16:02:14 +00:00
|
|
|
``${!NAME:STR}``
|
|
|
|
Expands to ``STR`` (recursively) if the property ``NAME`` cannot be
|
2013-06-08 16:04:36 +00:00
|
|
|
retrieved.
|
2013-09-20 20:53:06 +00:00
|
|
|
``${?NAME==VALUE:STR}``
|
|
|
|
Expands to ``STR`` (recursively) if the property ``NAME`` expands to a
|
|
|
|
string equal to ``VALUE``. You can prefix ``NAME`` with ``=`` in order to
|
|
|
|
compare the raw value of a property (see section below). If the property
|
|
|
|
is unavailable, or other errors happen when retrieving it, the value is
|
|
|
|
never considered equal.
|
|
|
|
Note that ``VALUE`` can't contain any of the characters ``:`` or ``}``.
|
|
|
|
Also, it is possible that escaping with ``"`` or ``%`` might be added in
|
|
|
|
the future, should the need arise.
|
|
|
|
``${!NAME==VALUE:STR}``
|
|
|
|
Same as with the ``?`` variant, but ``STR`` is expanded if the value is
|
|
|
|
not equal. (Using the same semantics as with ``?``.)
|
2013-07-08 16:02:14 +00:00
|
|
|
``$$``
|
2013-06-08 16:04:36 +00:00
|
|
|
Expands to ``$``.
|
2013-07-08 16:02:14 +00:00
|
|
|
``$}``
|
2013-06-08 16:04:36 +00:00
|
|
|
Expands to ``}``. (To produce this character inside recursive
|
|
|
|
expansion.)
|
2013-07-08 16:02:14 +00:00
|
|
|
``$>``
|
2013-06-08 16:04:36 +00:00
|
|
|
Disable property expansion and special handling of ``$`` for the rest
|
|
|
|
of the string.
|
|
|
|
|
|
|
|
In places where property expansion is allowed, C-style escapes are often
|
|
|
|
accepted as well. Example:
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
- ``\n`` becomes a newline character
|
|
|
|
- ``\\`` expands to ``\``
|
2013-06-08 16:04:36 +00:00
|
|
|
|
2013-07-07 18:37:47 +00:00
|
|
|
Raw and Formatted Properties
|
2013-06-08 16:04:36 +00:00
|
|
|
----------------------------
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
Normally, properties are formatted as human-readable text, meant to be
|
2013-06-08 16:04:36 +00:00
|
|
|
displayed on OSD or on the terminal. It is possible to retrieve an unformatted
|
|
|
|
(raw) value from a property by prefixing its name with ``=``. These raw values
|
2013-07-08 16:02:14 +00:00
|
|
|
can be parsed by other programs and follow the same conventions as the options
|
2013-06-08 16:04:36 +00:00
|
|
|
associated with the properties.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
2013-06-08 16:04:36 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
- ``${time-pos}`` expands to ``00:14:23`` (if playback position is at 14
|
|
|
|
minutes 23 seconds)
|
|
|
|
- ``${=time-pos}`` expands to ``863.4`` (same time, plus 400 milliseconds -
|
|
|
|
milliseconds are normally not shown in the formatted case)
|
2013-06-08 16:04:36 +00:00
|
|
|
|
|
|
|
Sometimes, the difference in amount of information carried by raw and formatted
|
|
|
|
property values can be rather big. In some cases, raw values have more
|
|
|
|
information, like higher precision than seconds with ``time-pos``. Sometimes
|
2013-07-08 16:02:14 +00:00
|
|
|
it is the other way around, e.g. ``aid`` shows track title and language in the
|
|
|
|
formatted case, but only the track number if it is raw.
|