2013-10-15 20:42:00 +00:00
|
|
|
OPTIONS
|
|
|
|
=======
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Track Selection
|
|
|
|
---------------
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``--alang=<languagecode[,languagecode,...]>``
|
2021-05-26 22:57:41 +00:00
|
|
|
Specify a priority list of audio languages to use, as IETF language tags.
|
|
|
|
Equivalent ISO 639-1 two-letter and ISO 639-2 three-letter codes are treated the same.
|
|
|
|
The first tag in the list whose language matches a track in the file will be used.
|
|
|
|
A track that matches more subtags will be preferred over one that matches fewer,
|
|
|
|
with preference given to earlier subtags over later ones. See also ``--aid``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2017-07-11 22:55:04 +00:00
|
|
|
- ``mpv dvd://1 --alang=hu,en`` chooses the Hungarian language track
|
|
|
|
on a DVD and falls back on English if Hungarian is not available.
|
|
|
|
- ``mpv --alang=jpn example.mkv`` plays a Matroska file with Japanese
|
|
|
|
audio.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--slang=<languagecode[,languagecode,...]>``
|
2023-08-07 02:39:17 +00:00
|
|
|
Equivalent to ``--alang``, for subtitle tracks.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
2013-01-04 15:19:49 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
- ``mpv dvd://1 --slang=hu,en`` chooses the Hungarian subtitle track on
|
|
|
|
a DVD and falls back on English if Hungarian is not available.
|
|
|
|
- ``mpv --slang=jpn example.mkv`` plays a Matroska file with Japanese
|
|
|
|
subtitles.
|
2021-05-26 22:57:41 +00:00
|
|
|
- ``mpv --slang=pt-BR example.mkv`` plays a Matroska file with Brazilian
|
|
|
|
Portuguese subtitles if available, and otherwise any Portuguese subtitles.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2017-10-12 22:31:43 +00:00
|
|
|
``--vlang=<...>``
|
|
|
|
Equivalent to ``--alang`` and ``--slang``, for video tracks.
|
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--aid=<ID|auto|no>``
|
|
|
|
Select audio track. ``auto`` selects the default, ``no`` disables audio.
|
|
|
|
See also ``--alang``. mpv normally prints available audio tracks on the
|
|
|
|
terminal when starting playback of a file.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-08-31 15:28:42 +00:00
|
|
|
``--audio`` is an alias for ``--aid``.
|
|
|
|
|
|
|
|
``--aid=no`` or ``--audio=no`` or ``--no-audio`` disables audio playback.
|
|
|
|
(The latter variant does not work with the client API.)
|
|
|
|
|
2020-04-13 13:42:52 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
The track selection options (``--aid`` but also ``--sid`` and the
|
|
|
|
others) sometimes expose behavior that may appear strange. Also, the
|
|
|
|
behavior tends to change around with each mpv release.
|
|
|
|
|
|
|
|
The track selection properties will return the option value outside of
|
2021-04-05 11:58:46 +00:00
|
|
|
playback (as expected), but during playback, the affective track
|
2020-04-13 13:42:52 +00:00
|
|
|
selection is returned. For example, with ``--aid=auto``, the ``aid``
|
|
|
|
property will suddenly return ``2`` after playback initialization
|
|
|
|
(assuming the file has at least 2 audio tracks, and the second is the
|
|
|
|
default).
|
|
|
|
|
|
|
|
At mpv 0.32.0 (and some releases before), if you passed a track value
|
|
|
|
for which a corresponding track didn't exist (e.g. ``--aid=2`` and there
|
|
|
|
was only 1 audio track), the ``aid`` property returned ``no``. However if
|
|
|
|
another audio track was added during playback, and you tried to set the
|
|
|
|
``aid`` property to ``2``, nothing happened, because the ``aid`` option
|
|
|
|
still had the value ``2``, and writing the same value has no effect.
|
|
|
|
|
|
|
|
With mpv 0.33.0, the behavior was changed. Now track selection options
|
|
|
|
are reset to ``auto`` at playback initialization, if the option had
|
|
|
|
tries to select a track that does not exist. The same is done if the
|
|
|
|
track exists, but fails to initialize. The consequence is that unlike
|
|
|
|
before mpv 0.33.0, the user's track selection parameters are clobbered
|
|
|
|
in certain situations.
|
|
|
|
|
2020-04-13 13:55:51 +00:00
|
|
|
Also since mpv 0.33.0, trying to select a track by number will strictly
|
|
|
|
select this track. Before this change, trying to select a track which
|
|
|
|
did not exist would fall back to track default selection at playback
|
|
|
|
initialization. The new behavior is more consistent.
|
|
|
|
|
|
|
|
Setting a track selection property at runtime, and then playing a new
|
|
|
|
file might reset the track selection to defaults, if the fingerprint
|
|
|
|
of the track list of the new file is different.
|
|
|
|
|
|
|
|
Be aware of tricky combinations of all of all of the above: for example,
|
|
|
|
``mpv --aid=2 file_with_2_audio_tracks.mkv file_with_1_audio_track.mkv``
|
|
|
|
would first play the correct track, and the second file without audio.
|
|
|
|
If you then go back the first file, its first audio track will be played,
|
|
|
|
and the second file is played with audio. If you do the same thing again
|
|
|
|
but instead of using ``--aid=2`` you run ``set aid 2`` while the file is
|
|
|
|
playing, then changing to the second file will play its audio track.
|
|
|
|
This is because runtime selection enables the fingerprint heuristic.
|
|
|
|
|
2020-04-13 13:42:52 +00:00
|
|
|
Most likely this is not the end.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sid=<ID|auto|no>``
|
|
|
|
Display the subtitle stream specified by ``<ID>``. ``auto`` selects
|
|
|
|
the default, ``no`` disables subtitles.
|
2014-06-04 22:25:24 +00:00
|
|
|
|
2016-08-31 15:28:42 +00:00
|
|
|
``--sub`` is an alias for ``--sid``.
|
|
|
|
|
|
|
|
``--sid=no`` or ``--sub=no`` or ``--no-sub`` disables subtitle decoding.
|
|
|
|
(The latter variant does not work with the client API.)
|
2014-06-04 22:25:24 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--vid=<ID|auto|no>``
|
|
|
|
Select video channel. ``auto`` selects the default, ``no`` disables video.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-08-31 15:28:42 +00:00
|
|
|
``--video`` is an alias for ``--vid``.
|
|
|
|
|
|
|
|
``--vid=no`` or ``--video=no`` or ``--no-video`` disables video playback.
|
|
|
|
(The latter variant does not work with the client API.)
|
|
|
|
|
2016-09-10 10:34:11 +00:00
|
|
|
If video is disabled, mpv will try to download the audio only if media is
|
2016-08-31 15:28:42 +00:00
|
|
|
streamed with youtube-dl, because it saves bandwidth. This is done by
|
|
|
|
setting the ytdl_format to "bestaudio/best" in the ytdl_hook.lua script.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--edition=<ID|auto>``
|
|
|
|
(Matroska files only)
|
|
|
|
Specify the edition (set of chapters) to use, where 0 is the first. If set
|
|
|
|
to ``auto`` (the default), mpv will choose the first edition declared as a
|
|
|
|
default, or if there is no default, the first edition defined.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2017-08-12 21:43:05 +00:00
|
|
|
``--track-auto-selection=<yes|no>``
|
|
|
|
Enable the default track auto-selection (default: yes). Enabling this will
|
|
|
|
make the player select streams according to ``--aid``, ``--alang``, and
|
|
|
|
others. If it is disabled, no tracks are selected. In addition, the player
|
|
|
|
will not exit if no tracks are selected, and wait instead (this wait mode
|
|
|
|
is similar to pausing, but the pause option is not set).
|
|
|
|
|
|
|
|
This is useful with ``--lavfi-complex``: you can start playback in this
|
|
|
|
mode, and then set select tracks at runtime by setting the filter graph.
|
|
|
|
Note that if ``--lavfi-complex`` is set before playback is started, the
|
|
|
|
referenced tracks are always selected.
|
|
|
|
|
2020-06-22 20:08:42 +00:00
|
|
|
``--subs-with-matching-audio=<yes|no>``
|
2021-05-26 18:57:35 +00:00
|
|
|
When autoselecting a subtitle track, select a full/non-forced one even if the selected
|
2023-08-29 17:34:27 +00:00
|
|
|
audio stream matches your preferred subtitle language (default: yes). If this option is
|
|
|
|
set to ``no``, a non-forced subtitle track that matches the audio language will never be
|
|
|
|
autoselected by mpv regardless of the value of ``--slang`` or ``--subs-fallback``.
|
2020-06-22 20:08:42 +00:00
|
|
|
|
2023-08-07 04:49:37 +00:00
|
|
|
``--subs-match-os-language=<yes|no>``
|
|
|
|
When autoselecting a subtitle track, select the track that matches the language of your OS
|
|
|
|
if the audio stream is in a different language if suitable (default track or a forced track
|
|
|
|
under the right conditions). Note that if ``-slang`` is set, this will be completely ignored
|
|
|
|
(default: yes).
|
|
|
|
|
2021-05-26 23:18:35 +00:00
|
|
|
``--subs-fallback=<yes|default|no>``
|
|
|
|
When autoselecting a subtitle track, if no tracks match your preferred languages,
|
2023-07-24 17:16:12 +00:00
|
|
|
select a full track even if it doesn't match your preferred subtitle language (default: default).
|
2021-05-26 23:18:35 +00:00
|
|
|
Setting this to `default` means that only streams flagged as `default` will be selected.
|
|
|
|
|
2023-08-26 04:38:57 +00:00
|
|
|
``--subs-fallback-forced=<yes|no|always>``
|
2021-05-26 23:18:35 +00:00
|
|
|
When autoselecting a subtitle track, if no tracks match your preferred languages,
|
|
|
|
select a forced track that matches the language of the selected audio track (default: yes).
|
2023-08-26 04:38:57 +00:00
|
|
|
`always` will always select a forced track if possible, regardles if the language matches the
|
|
|
|
selected audio track or not.
|
2021-05-26 23:18:35 +00:00
|
|
|
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Playback Control
|
|
|
|
----------------
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--start=<relative time>``
|
|
|
|
Seek to given time position.
|
2013-01-04 15:19:49 +00:00
|
|
|
|
2019-05-28 20:26:36 +00:00
|
|
|
The general format for times is ``[+|-][[hh:]mm:]ss[.ms]``. If the time is
|
|
|
|
prefixed with ``-``, the time is considered relative from the end of the
|
|
|
|
file (as signaled by the demuxer/the file). A ``+`` is usually ignored (but
|
|
|
|
see below).
|
|
|
|
|
|
|
|
The following alternative time specifications are recognized:
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``pp%`` seeks to percent position pp (0-100).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``#c`` seeks to chapter number c. (Chapters start from 1.)
|
2013-09-25 19:40:35 +00:00
|
|
|
|
2017-12-04 01:00:33 +00:00
|
|
|
``none`` resets any previously set option (useful for libmpv).
|
|
|
|
|
2019-05-28 20:26:36 +00:00
|
|
|
If ``--rebase-start-time=no`` is given, then prefixing times with ``+``
|
|
|
|
makes the time relative to the start of the file. A timestamp without
|
|
|
|
prefix is considered an absolute time, i.e. should seek to a frame with a
|
|
|
|
timestamp as the file contains it. As a bug, but also a hidden feature,
|
|
|
|
putting 1 or more spaces before the ``+`` or ``-`` always interprets the
|
|
|
|
time as absolute, which can be used to seek to negative timestamps (useful
|
|
|
|
for debugging at most).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2019-05-28 20:26:36 +00:00
|
|
|
``--start=+56``, ``--start=00:56``
|
2014-07-31 14:32:37 +00:00
|
|
|
Seeks to the start time + 56 seconds.
|
|
|
|
``--start=-56``, ``--start=-00:56``
|
|
|
|
Seeks to the end time - 56 seconds.
|
|
|
|
``--start=01:10:00``
|
|
|
|
Seeks to 1 hour 10 min.
|
|
|
|
``--start=50%``
|
|
|
|
Seeks to the middle of the file.
|
|
|
|
``--start=30 --end=40``
|
|
|
|
Seeks to 30 seconds, plays 10 seconds, and exits.
|
|
|
|
``--start=-3:20 --length=10``
|
|
|
|
Seeks to 3 minutes and 20 seconds before the end of the file, plays
|
|
|
|
10 seconds, and exits.
|
|
|
|
``--start='#2' --end='#4'``
|
|
|
|
Plays chapters 2 and 3, and exits.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2018-03-15 14:20:12 +00:00
|
|
|
``--end=<relative time>``
|
|
|
|
Stop at given time. Use ``--length`` if the time should be relative
|
2014-07-31 14:32:37 +00:00
|
|
|
to ``--start``. See ``--start`` for valid option values and examples.
|
2013-09-25 19:42:29 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--length=<relative time>``
|
|
|
|
Stop after a given time relative to the start time.
|
|
|
|
See ``--start`` for valid option values and examples.
|
2013-09-25 19:42:29 +00:00
|
|
|
|
2017-12-04 17:30:22 +00:00
|
|
|
If both ``--end`` and ``--length`` are provided, playback will stop when it
|
|
|
|
reaches either of the two endpoints.
|
|
|
|
|
2019-05-28 20:26:36 +00:00
|
|
|
Obscurity note: this does not work correctly if ``--rebase-start-time=no``,
|
|
|
|
and the specified time is not an "absolute" time, as defined in the
|
|
|
|
``--start`` option description.
|
|
|
|
|
2015-11-16 21:47:17 +00:00
|
|
|
``--rebase-start-time=<yes|no>``
|
|
|
|
Whether to move the file start time to ``00:00:00`` (default: yes). This
|
|
|
|
is less awkward for files which start at a random timestamp, such as
|
|
|
|
transport streams. On the other hand, if there are timestamp resets, the
|
|
|
|
resulting behavior can be rather weird. For this reason, and in case you
|
|
|
|
are actually interested in the real timestamps, this behavior can be
|
|
|
|
disabled with ``no``.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--speed=<0.01-100>``
|
|
|
|
Slow down or speed up playback by the factor given as parameter.
|
2013-09-25 19:42:29 +00:00
|
|
|
|
2015-02-27 05:21:42 +00:00
|
|
|
If ``--audio-pitch-correction`` (on by default) is used, playing with a
|
2021-01-20 18:07:08 +00:00
|
|
|
speed higher than normal automatically inserts the ``scaletempo2`` audio
|
2015-02-27 05:21:42 +00:00
|
|
|
filter.
|
2014-10-02 00:58:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--pause``
|
|
|
|
Start the player in paused state.
|
2013-01-04 15:19:49 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--shuffle``
|
|
|
|
Play files in random order.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-09-18 11:38:45 +00:00
|
|
|
``--playlist-start=<auto|index>``
|
2015-08-22 20:08:17 +00:00
|
|
|
Set which file on the internal playlist to start playback with. The index
|
2016-09-18 11:38:45 +00:00
|
|
|
is an integer, with 0 meaning the first file. The value ``auto`` means that
|
2015-08-22 20:08:17 +00:00
|
|
|
the selection of the entry to play is left to the playback resume mechanism
|
|
|
|
(default). If an entry with the given index doesn't exist, the behavior is
|
|
|
|
unspecified and might change in future mpv versions. The same applies if
|
|
|
|
the playlist contains further playlists (don't expect any reasonable
|
|
|
|
behavior). Passing a playlist file to mpv should work with this option,
|
2016-09-18 11:38:45 +00:00
|
|
|
though. E.g. ``mpv playlist.m3u --playlist-start=123`` will work as expected,
|
2015-08-22 20:08:17 +00:00
|
|
|
as long as ``playlist.m3u`` does not link to further playlists.
|
|
|
|
|
2016-09-18 11:38:45 +00:00
|
|
|
The value ``no`` is a deprecated alias for ``auto``.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--playlist=<filename>``
|
2020-11-16 03:06:59 +00:00
|
|
|
Play files according to a playlist file. Supports some common formats. If
|
2014-12-25 20:09:18 +00:00
|
|
|
no format is detected, it will be treated as list of files, separated by
|
2020-11-16 03:06:59 +00:00
|
|
|
newline characters. You may need this option to load plaintext files as
|
|
|
|
a playlist. Note that XML playlist formats are not supported.
|
2012-10-11 00:23:29 +00:00
|
|
|
|
2020-11-16 03:06:59 +00:00
|
|
|
This option forces ``--demuxer=playlist`` to interpret the playlist file.
|
|
|
|
Some playlist formats, notably CUE and optical disc formats, need to use
|
|
|
|
different demuxers and will not work with this option. They still can be
|
|
|
|
played directly, without using this option.
|
|
|
|
|
|
|
|
You can play playlists directly, without this option. Before mpv version
|
|
|
|
0.31.0, this option disabled any security mechanisms that might be in
|
|
|
|
place, but since 0.31.0 it uses the same security mechanisms as playing a
|
|
|
|
playlist file directly. If you trust the playlist file, you can disable
|
|
|
|
any security checks with ``--load-unsafe-playlists``. Because playlists
|
|
|
|
can load other playlist entries, consider applying this option only to the
|
|
|
|
playlist itself and not its entries, using something along these lines:
|
|
|
|
|
|
|
|
``mpv --{ --playlist=filename --load-unsafe-playlists --}``
|
2014-11-02 15:05:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. warning::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2020-11-16 03:06:59 +00:00
|
|
|
The way older versions of mpv played playlist files via ``--playlist``
|
|
|
|
was not safe against maliciously constructed files. Such files may
|
2023-03-27 20:42:17 +00:00
|
|
|
trigger harmful actions. This has been the case for all versions of
|
2020-11-16 03:06:59 +00:00
|
|
|
mpv prior to 0.31.0, and all MPlayer versions, but unfortunately this
|
|
|
|
fact was not well documented earlier, and some people have even
|
|
|
|
misguidedly recommended the use of ``--playlist`` with untrusted
|
|
|
|
sources. Do NOT use ``--playlist`` with random internet sources or
|
|
|
|
files you do not trust if you are not sure your mpv is at least 0.31.0.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2020-11-16 03:06:59 +00:00
|
|
|
In particular, playlists can contain entries using protocols other than
|
|
|
|
local files, such as special protocols like ``avdevice://`` (which are
|
|
|
|
inherently unsafe).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--chapter-merge-threshold=<number>``
|
|
|
|
Threshold for merging almost consecutive ordered chapter parts in
|
|
|
|
milliseconds (default: 100). Some Matroska files with ordered chapters
|
|
|
|
have inaccurate chapter end timestamps, causing a small gap between the
|
|
|
|
end of one chapter and the start of the next one when they should match.
|
|
|
|
If the end of one playback part is less than the given threshold away from
|
|
|
|
the start of the next one then keep playing video normally over the
|
|
|
|
chapter change instead of doing a seek.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--chapter-seek-threshold=<seconds>``
|
|
|
|
Distance in seconds from the beginning of a chapter within which a backward
|
|
|
|
chapter seek will go to the previous chapter (default: 5.0). Past this
|
|
|
|
threshold, a backward chapter seek will go to the beginning of the current
|
|
|
|
chapter instead. A negative value means always go back to the previous
|
|
|
|
chapter.
|
2013-06-30 16:46:29 +00:00
|
|
|
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
``--hr-seek=<no|absolute|yes|default>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Select when to use precise seeks that are not limited to keyframes. Such
|
|
|
|
seeks require decoding video from the previous keyframe up to the target
|
|
|
|
position and so can take some time depending on decoding performance. For
|
|
|
|
some video formats, precise seeks are disabled. This option selects the
|
|
|
|
default choice to use for seeks; it is possible to explicitly override that
|
2016-08-11 20:29:18 +00:00
|
|
|
default in the definition of key bindings and in input commands.
|
2013-06-30 16:46:29 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:no: Never use precise seeks.
|
|
|
|
:absolute: Use precise seeks if the seek is to an absolute position in the
|
|
|
|
file, such as a chapter seek, but not for relative seeks like
|
2022-06-08 20:34:17 +00:00
|
|
|
the default behavior of arrow keys.
|
player: dumb seeking related stuff, make audio hr-seek default
Try to deal with various corner cases. But when I fix one thing, another
thing breaks. (And it's 50/50 whether I find the breakage immediately or
a few months later.) So results may vary.
The default for--hr-seek is changed to "default" (not creative enough to
find a better name). In this mode, audio seeking is exact if there is no
video, or if the video has only a single frame. This change is actually
pretty dumb, since audio frames are usually small enough that exact
seeking does not really add much. But it gets rid of some weird special
cases.
Internally, the most important change is that is_coverart and is_sparse
handling is merged. is_sparse was originally just a special case for
weird .ts streams that have the corresponding low-level flag set. The
idea is that they're pretty similar anyway, so this would reduce the
number of corner cases. But I'm not sure if this doesn't break the
original intended use case for it (I don't have a sample anyway).
This changes last-frame handling, and respects the duration of the last
frame only if audio is disabled. This is mostly "coincidental" due to
the need to make seeking past EOF trigger player exit, and is caused by
setting STATUS_EOF early. On the other hand, this might have been this
way before (see removed chunk close to it).
2020-02-28 16:15:07 +00:00
|
|
|
:default: Like ``absolute``, but enable hr-seeks in audio-only cases. The
|
|
|
|
exact behavior is implementation specific and may change with
|
2022-06-08 20:34:17 +00:00
|
|
|
new releases (default).
|
2014-07-31 14:32:37 +00:00
|
|
|
:yes: Use precise seeks whenever possible.
|
2015-04-15 12:26:54 +00:00
|
|
|
:always: Same as ``yes`` (for compatibility).
|
2013-07-14 23:48:25 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--hr-seek-demuxer-offset=<seconds>``
|
|
|
|
This option exists to work around failures to do precise seeks (as in
|
|
|
|
``--hr-seek``) caused by bugs or limitations in the demuxers for some file
|
|
|
|
formats. Some demuxers fail to seek to a keyframe before the given target
|
|
|
|
position, going to a later position instead. The value of this option is
|
|
|
|
subtracted from the time stamp given to the demuxer. Thus, if you set this
|
|
|
|
option to 1.5 and try to do a precise seek to 60 seconds, the demuxer is
|
|
|
|
told to seek to time 58.5, which hopefully reduces the chance that it
|
|
|
|
erroneously goes to some time later than 60 seconds. The downside of
|
|
|
|
setting this option is that precise seeks become slower, as video between
|
|
|
|
the earlier demuxer position and the real target may be unnecessarily
|
|
|
|
decoded.
|
2013-07-14 23:48:25 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--hr-seek-framedrop=<yes|no>``
|
|
|
|
Allow the video decoder to drop frames during seek, if these frames are
|
|
|
|
before the seek target. If this is enabled, precise seeking can be faster,
|
|
|
|
but if you're using video filters which modify timestamps or add new
|
|
|
|
frames, it can lead to precise seeking skipping the target frame. This
|
|
|
|
e.g. can break frame backstepping when deinterlacing is enabled.
|
2013-07-14 23:48:25 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Default: ``yes``
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--index=<mode>``
|
|
|
|
Controls how to seek in files. Note that if the index is missing from a
|
|
|
|
file, it will be built on the fly by default, so you don't need to change
|
|
|
|
this. But it might help with some broken files.
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:default: use an index if the file has one, or build it if missing
|
|
|
|
:recreate: don't read or use the file's index
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option only works if the underlying media supports seeking
|
|
|
|
(i.e. not with stdin, pipe, etc).
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--load-unsafe-playlists``
|
2014-08-31 17:49:39 +00:00
|
|
|
Load URLs from playlists which are considered unsafe (default: no). This
|
|
|
|
includes special protocols and anything that doesn't refer to normal files.
|
2014-09-01 02:25:57 +00:00
|
|
|
Local files and HTTP links on the other hand are always considered safe.
|
2014-08-31 17:49:39 +00:00
|
|
|
|
loadfile, ytdl_hook: don't reject EDL-resolved URLs through playlist
The ytdl wrapper can resolve web links to playlists. This playlist is
passed as big memory:// blob, and will contain further quite normal web
links. When playback of one of these playlist entries starts, ytdl is
called again and will resolve the web link to a media URL again.
This didn't work if playlist entries resolved to EDL URLs. Playback was
rejected with a "potentially unsafe URL from playlist" error. This was
completely weird and unexpected: using the playlist entry directly on
the command line worked fine, and there isn't a reason why it should be
different for a playlist entry (both are resolved by the ytdl wrapper
anyway). Also, if the only EDL URL was added via audio-add or sub-add,
the URL was accessed successfully.
The reason this happened is because the playlist entries were marked as
STREAM_SAFE_ONLY, and edl:// is not marked as "safe". Playlist entries
passed via command line directly are not marked, so resolving them to
EDL worked.
Fix this by making the ytdl hook set load-unsafe-playlists while the
playlist is parsed. (After the playlist is parsed, and before the first
playlist entry is played, file-local options are reset again.) Further,
extend the load-unsafe-playlists option so that the playlist entries are
not marked while the playlist is loaded.
Since playlist entries are already verified, this should change nothing
about the actual security situation.
There are now 2 locations which check load_unsafe_playlists. The old one
is a bit redundant now. In theory, the playlist loading code might not
be the only code which sets these flags, so keeping the old code is
somewhat justified (and in any case it doesn't hurt to keep it).
In general, the security concept sucks (and always did). I can for
example not answer the question whether you can "break" this mechanism
with various combinations of archives, EDL files, playlists files,
compromised sites, and so on. You probably can, and I'm fully aware that
it's probably possible, so don't blame me.
2019-01-04 12:48:27 +00:00
|
|
|
In addition, if a playlist is loaded while this is set, the added playlist
|
|
|
|
entries are not marked as originating from network or potentially unsafe
|
|
|
|
location. (Instead, the behavior is as if the playlist entries were provided
|
|
|
|
directly to mpv command line or ``loadfile`` command.)
|
|
|
|
|
2016-12-04 22:15:31 +00:00
|
|
|
``--access-references=<yes|no>``
|
|
|
|
Follow any references in the file being opened (default: yes). Disabling
|
|
|
|
this is helpful if the file is automatically scanned (e.g. thumbnail
|
|
|
|
generation). If the thumbnail scanner for example encounters a playlist
|
|
|
|
file, which contains network URLs, and the scanner should not open these,
|
|
|
|
enabling this option will prevent it. This option also disables ordered
|
|
|
|
chapters, mov reference files, opening of archives, and a number of other
|
|
|
|
features.
|
|
|
|
|
|
|
|
On older FFmpeg versions, this will not work in some cases. Some FFmpeg
|
|
|
|
demuxers might not respect this option.
|
|
|
|
|
|
|
|
This option does not prevent opening of paired subtitle files and such. Use
|
|
|
|
``--autoload-files=no`` to prevent this.
|
|
|
|
|
|
|
|
This option does not always work if you open non-files (for example using
|
|
|
|
``dvd://directory`` would open a whole bunch of files in the given
|
|
|
|
directory). Prefixing the filename with ``./`` if it doesn't start with
|
|
|
|
a ``/`` will avoid this.
|
|
|
|
|
2017-04-10 19:19:47 +00:00
|
|
|
``--loop-playlist=<N|inf|force|no>``, ``--loop-playlist``
|
|
|
|
Loops playback ``N`` times. A value of ``1`` plays it one time (default),
|
|
|
|
``2`` two times, etc. ``inf`` means forever. ``no`` is the same as ``1`` and
|
|
|
|
disables looping. If several files are specified on command line, the
|
|
|
|
entire playlist is looped. ``--loop-playlist`` is the same as
|
|
|
|
``--loop-playlist=inf``.
|
|
|
|
|
|
|
|
The ``force`` mode is like ``inf``, but does not skip playlist entries
|
|
|
|
which have been marked as failing. This means the player might waste CPU
|
|
|
|
time trying to loop a file that doesn't exist. But it might be useful for
|
|
|
|
playing webradios under very bad network conditions.
|
|
|
|
|
2017-08-14 18:01:08 +00:00
|
|
|
``--loop-file=<N|inf|no>``, ``--loop=<N|inf|no>``
|
2014-09-22 20:56:00 +00:00
|
|
|
Loop a single file N times. ``inf`` means forever, ``no`` means normal
|
|
|
|
playback. For compatibility, ``--loop-file`` and ``--loop-file=yes`` are
|
|
|
|
also accepted, and are the same as ``--loop-file=inf``.
|
|
|
|
|
2017-04-11 10:15:38 +00:00
|
|
|
The difference to ``--loop-playlist`` is that this doesn't loop the playlist,
|
|
|
|
just the file itself. If the playlist contains only a single file, the
|
|
|
|
difference between the two option is that this option performs a seek on
|
|
|
|
loop, instead of reloading the file.
|
2012-12-10 17:52:06 +00:00
|
|
|
|
2021-01-22 20:48:13 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
``--loop-file`` counts the number of times it causes the player to
|
|
|
|
seek to the beginning of the file, not the number of full playthroughs. This
|
|
|
|
means ``--loop-file=1`` will end up playing the file twice. Contrast with
|
|
|
|
``--loop-playlist``, which counts the number of full playthroughs.
|
2021-01-03 17:13:35 +00:00
|
|
|
|
2017-08-14 18:01:08 +00:00
|
|
|
``--loop`` is an alias for this option.
|
|
|
|
|
2014-11-17 23:09:42 +00:00
|
|
|
``--ab-loop-a=<time>``, ``--ab-loop-b=<time>``
|
|
|
|
Set loop points. If playback passes the ``b`` timestamp, it will seek to
|
|
|
|
the ``a`` timestamp. Seeking past the ``b`` point doesn't loop (this is
|
2016-04-21 20:15:17 +00:00
|
|
|
intentional).
|
|
|
|
|
player: modify/simplify AB-loop behavior
This changes the behavior of the --ab-loop-a/b options. In addition, it
makes it work with backward playback mode.
The most obvious change is that the both the A and B point need to be
set now before any looping happens. Unlike before, unset points don't
implicitly use the start or end of the file. I think the old behavior
was a feature that was explicitly added/wanted. Well, it's gone now.
This is because of 2 reasons:
1. I never liked this feature, and it always got in my way (as user).
2. It's inherently annoying with backward playback mode.
In backward playback mode, the user wants to set A/B in the wrong order.
The ab-loop command will first set A, then B, so if you use this command
during backward playback, A will be set to a higher timestamps than B.
If you switch back to forward playback mode, the loop would stop
working. I want the loop to just continue to work, and the chosen
solution conflicts with the removed feature.
The order issue above _could_ be fixed by also switching the AB-loop
user option values around on direction switch. But there are no other
instances of option changes magically affecting other options, and doing
this would probably lead to unexpected misery (dying from corner cases
and such).
Another solution is sorting the A/B points by timestamps after copying
them from the user options. Then A/B options set in backward mode will
work in forward mode. This is the chosen solution. If you sort the
points, you don't know anymore whether the unset point is supposed to
signify the end or the start of the file.
The AB-loop code is slightly better abstracted now, so it should be easy
to restore the removed feature. It would still require coming up with a
solution for backwards playback, though.
A minor change is that if one point is set and the other is unset, I'm
rendering both the chapter markers and the marker for the set point.
Why? I don't know. My test file had chapters, and I guess I decided this
looked better.
This commit also fixes some subtle and obvious issues that I already
forgot about when I wrote this commit message. It cleans up some minor
code duplication and nonsense too.
Regarding backward playback, the code uses an unsanitary mix of internal
("transformed") and user timestamps. So the play_dir variable appears
more than usual.
To mention one unfixed issue: if you set an AB-loop that is completely
past the end of the file, it will get stuck in an infinite seeking loop
once playback reaches the end of the file. Fixing this reliably seemed
annoying, so the fix is "just don't do this". It's not a hard freeze
anyway.
2019-05-26 23:24:22 +00:00
|
|
|
If ``a`` is after ``b``, the behavior is as if the points were given in
|
|
|
|
the right order, and the player will seek to ``b`` after crossing through
|
|
|
|
``a``. This is different from old behavior, where looping was disabled (and
|
|
|
|
as a bug, looped back to ``a`` on the end of the file).
|
|
|
|
|
|
|
|
If either options are set to ``no`` (or unset), looping is disabled. This
|
|
|
|
is different from old behavior, where an unset ``a`` implied the start of
|
|
|
|
the file, and an unset ``b`` the end of the file.
|
2016-04-21 20:15:17 +00:00
|
|
|
|
|
|
|
The loop-points can be adjusted at runtime with the corresponding
|
|
|
|
properties. See also ``ab-loop`` command.
|
2014-11-17 23:09:42 +00:00
|
|
|
|
2020-02-08 13:57:45 +00:00
|
|
|
``--ab-loop-count=<N|inf>``
|
|
|
|
Run A-B loops only N times, then ignore the A-B loop points (default: inf).
|
|
|
|
Every finished loop iteration will decrement this option by 1 (unless it is
|
|
|
|
set to ``inf`` or 0). ``inf`` means that looping goes on forever. If this
|
|
|
|
option is set to 0, A-B looping is ignored, and even the ``ab-loop`` command
|
|
|
|
will not enable looping again (the command will show ``(disabled)`` on the
|
|
|
|
OSD message if both loop points are set, but ``ab-loop-count`` is 0).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ordered-chapters``, ``--no-ordered-chapters``
|
|
|
|
Enabled by default.
|
|
|
|
Disable support for Matroska ordered chapters. mpv will not load or
|
|
|
|
search for video segments from other files, and will also ignore any
|
|
|
|
chapter order specified for the main file.
|
2012-12-10 17:52:06 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ordered-chapters-files=<playlist-file>``
|
|
|
|
Loads the given file as playlist, and tries to use the files contained in
|
|
|
|
it as reference files when opening a Matroska file that uses ordered
|
|
|
|
chapters. This overrides the normal mechanism for loading referenced
|
|
|
|
files by scanning the same directory the main file is located in.
|
2012-12-10 17:52:06 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Useful for loading ordered chapter files that are not located on the local
|
|
|
|
filesystem, or if the referenced files are in different directories.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Note: a playlist can be as simple as a text file containing filenames
|
|
|
|
separated by newlines.
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-11-02 15:47:23 +00:00
|
|
|
``--chapters-file=<filename>``
|
|
|
|
Load chapters from this file, instead of using the chapter metadata found
|
|
|
|
in the main file.
|
|
|
|
|
2017-05-22 15:10:49 +00:00
|
|
|
This accepts a media file (like mkv) or even a pseudo-format like ffmetadata
|
|
|
|
and uses its chapters to replace the current file's chapters. This doesn't
|
|
|
|
work with OGM or XML chapters directly.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sstep=<sec>``
|
|
|
|
Skip <sec> seconds after every frame.
|
2014-04-24 15:56:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Without ``--hr-seek``, skipping will snap to keyframes.
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2014-10-28 18:51:44 +00:00
|
|
|
``--stop-playback-on-init-failure=<yes|no>``
|
2017-12-17 13:03:33 +00:00
|
|
|
Stop playback if either audio or video fails to initialize (default: no).
|
|
|
|
With ``no``, playback will continue in video-only or audio-only mode if one
|
|
|
|
of them fails. This doesn't affect playback of audio-only or video-only
|
|
|
|
files.
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2019-05-31 14:33:20 +00:00
|
|
|
``--play-dir=<forward|+|backward|->``
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
Control the playback direction (default: forward). Setting ``backward``
|
|
|
|
will attempt to play the file in reverse direction, with decreasing
|
|
|
|
playback time. If this is set on playback starts, playback will start from
|
|
|
|
the end of the file. If this is changed at during playback, a hr-seek will
|
|
|
|
be issued to change the direction.
|
|
|
|
|
2019-05-31 14:33:20 +00:00
|
|
|
``+`` and ``-`` are aliases for ``forward`` and ``backward``.
|
|
|
|
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
The rest of this option description pertains to the ``backward`` mode.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Backward playback is extremely fragile. It may not always work, is much
|
|
|
|
slower than forward playback, and breaks certain other features. How
|
|
|
|
well it works depends mainly on the file being played. Generally, it
|
|
|
|
will show good results (or results at all) only if the stars align.
|
|
|
|
|
|
|
|
mpv, as well as most media formats, were designed for forward playback
|
|
|
|
only. Backward playback is bolted on top of mpv, and tries to make a medium
|
|
|
|
effort to make backward playback work. Depending on your use-case, another
|
|
|
|
tool may work much better.
|
|
|
|
|
|
|
|
Backward playback is not exactly a 1st class feature. Implementation
|
|
|
|
tradeoffs were made, that are bad for backward playback, but in turn do not
|
|
|
|
cause disadvantages for normal playback. Various possible optimizations are
|
|
|
|
not implemented in order to keep the complexity down. Normally, a media
|
|
|
|
player is highly pipelined (future data is prepared in separate threads, so
|
|
|
|
it is available in realtime when the next stage needs it), but backward
|
|
|
|
playback will essentially stall the pipeline at various random points.
|
|
|
|
|
|
|
|
For example, for intra-only codecs are trivially backward playable, and
|
|
|
|
tools built around them may make efficient use of them (consider video
|
|
|
|
editors or camera viewers). mpv won't be efficient in this case, because it
|
|
|
|
uses its generic backward playback algorithm, that on top of it is not very
|
|
|
|
optimized.
|
|
|
|
|
|
|
|
If you just want to quickly go backward through the video and just show
|
|
|
|
"keyframes", just use forward playback, and hold down the left cursor key
|
|
|
|
(which on CLI with default config sends many small relative seek commands).
|
|
|
|
|
|
|
|
The implementation consists of mostly 3 parts:
|
|
|
|
|
|
|
|
- Backward demuxing. This relies on the demuxer cache, so the demuxer cache
|
|
|
|
should (or must, didn't test it) be enabled, and its size will affect
|
|
|
|
performance. If the cache is too small or too large, quadratic runtime
|
|
|
|
behavior may result.
|
|
|
|
|
|
|
|
- Backward decoding. The decoder library used (libavcodec) does not support
|
|
|
|
this. It is emulated by feeding bits of data in forward, putting the
|
|
|
|
result in a queue, returning the queue data to the VO in reverse, and
|
|
|
|
then starting over at an earlier position. This can require buffering an
|
|
|
|
extreme amount of decoded data, and also completely breaks pipelining.
|
|
|
|
|
|
|
|
- Backward output. This is relatively simple, because the decoder returns
|
|
|
|
the frames in the needed order. However, this may cause various problems
|
2019-05-25 12:59:48 +00:00
|
|
|
because filters see audio and video going backward.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
Known problems:
|
|
|
|
|
|
|
|
- It's fragile. If anything doesn't work, random non-useful behavior may
|
|
|
|
occur. In simple cases, the player will just play nonsense and artifacts.
|
|
|
|
In other cases, it may get stuck or heat the CPU. (Exceeding memory usage
|
|
|
|
significantly beyond the user-set limits would be a bug, though.)
|
|
|
|
|
|
|
|
- Performance and resource usage isn't good. In part this is inherent to
|
|
|
|
backward playback of normal media formats, and in parts due to
|
|
|
|
implementation choices and tradeoffs.
|
|
|
|
|
|
|
|
- This is extremely reliant on good demuxer behavior. Although backward
|
|
|
|
demuxing requires no special demuxer support, it is required that the
|
|
|
|
demuxer performs seeks reliably, fulfills some specific requirements
|
|
|
|
about packet metadata, and has deterministic behavior.
|
|
|
|
|
|
|
|
- Starting playback exactly from the end may or may not work, depending on
|
|
|
|
seeking behavior and file duration detection.
|
|
|
|
|
|
|
|
- Some container formats, audio, and video codecs are not supported due to
|
|
|
|
their behavior. There is no list, and the player usually does not detect
|
|
|
|
them. Certain live streams (including TV captures) may exhibit problems
|
|
|
|
in particular, as well as some lossy audio codecs. h264 intra-refresh is
|
demux_lavf: implement bad hack for backward playback of wav
This commit generally fixes backward playing in wav, at least in most
PCM cases.
libavformat's wav demuxer (and actually all other raw PCM based
demuxers) have a specific behavior that breaks backward demuxing. The
same thing also breaks persistent seek ranges in the demuxer cache,
although that's less critical (it just means some cached data gets
discarded). The backward demuxing issue is fatal, will log the message
"Demuxer not cooperating.", and then typically stop doing anything.
Unlike modern media formats, these formats don't organize media data in
packets, but just wrap a monolithic byte stream that is described by a
header. This is good enough for PCM, which uses fixed frames (a single
sample for all audio channels), and for which it would be too expensive
to have per frame headers.
libavformat (and mpv) is heavily packet based, and using a single packet
for each PCM frame causes too much overhead. So they typically "bundle"
multiple frames into a single packet. This packet size is obviously
arbitrary, and in libavformat's case hardcoded in its source code.
The problem is that seeking doesn't respect this arbitrary packet
boundary. Seeking is sample accurate. You can essentially seek inside a
packet. The resulting packets will not be aligned with previously
demuxed packets. This is normally OK.
Backward seeking (and some other demuxer layer features) expect that
demuxing an earlier demuxed file position eventually results in the same
packets, regardless of the seeks that were done to get there. I like to
call this "deterministic" demuxing. Backward demuxing in particular
requires this to avoid overlaps, which would make it rather hard to get
continuous output.
Fix this issue by detecting wav and hopefully other raw audio formats
with a heuristic (even PCM needs to be detected as heuristic). Then, if
a seek is requested, align the seek timestamps on the guessed number of
samples in the audio packets returned by the demuxer.
The heuristic excludes files with multiple streams. (Except "attachment"
video streams, which could be an ID3 tag. Yes, FFmpeg allows ID3 tags on
WAV files.) Such files will inherently use the packet concept in some
way.
We don't know how the demuxer chooses the internal packet size, but we
assume that it's fixed and aligned to PCM frame sizes. The frame size is
most likely given by block_align (the native wav frame size, according
to Microsoft). We possibly need to explicitly read and discard a packet
if the seek is done without reading anything before that. We ignore any
subsequent packet sizes; we need to avoid the very last packet, which
likely has a different size.
This hack should be rather benign. In the worst case, it will "round"
the seek target a little, but the maximum rounding amount is bounded.
Maybe we _could_ round up if SEEK_FORWARD is specified, but I didn't
bother.
An earlier commit fixed the same issue for mpv's demux_raw.
An alternative, and probably much better solution would be clipping
decoded data by timestamp. demux.c could allow the type of overlap the
wav demuxer introduces, and instruct the decoder to clip the output
against the last decoded timestamp. There's already an infrastructure
for this (demux_packet.end field) used by EDL/ordered chapters.
Although this sounds like a good solution, mpv unfortunately uses floats
for timestamps. The rounding errors break sample accuracy. Even if you
used integers, you'd need a timebase that is sample accurate (not always
easy, since EDL can merge tracks with different sample rates).
2019-05-25 14:59:20 +00:00
|
|
|
known not to work due to problems with libavcodec. WAV and some other raw
|
|
|
|
audio formats tend to have problems - there are hacks for dealing with
|
|
|
|
them, which may or may not work.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
- Backward demuxing of subtitles is not supported. Subtitle display still
|
|
|
|
works for some external text subtitle formats. (These are fully read into
|
|
|
|
memory, and only backward display is needed.) Text subtitles that are
|
|
|
|
cached in the subtitle renderer also have a chance to be displayed
|
|
|
|
correctly.
|
|
|
|
|
|
|
|
- Some features dealing with playback of broken or hard to deal with files
|
f_decoder_wrapper: reorganize, fix EDL/ordered chapters backward playback
Before this commit, there was a single process_decoded_frame() function.
It handled various aspects of dealing with a newly decoded frame. Move
some of these to a separate process_output_frame() function.
This new function is called in the order the frames are returned to the
playback core. Some correct_audio_pts() (was process_audio_frame())
becomes slightly less awkward due to this, and the timestamp smoothing
can actually work in backward playback mode now (thus moving p->pts out
of reset_decoder()).
Behavior for normal playback also changes subtly. This shouldn't matter
in sane cases, but if you mix broken files, --no-correct-pts, and
timeline stuff, differences in behavior might be visible.
Timeline clipping (EDL/ordered chapters) works now, because it's done
before "transforming" the timestamps. Audio timestamp smoothing happens
after it, which is a behavior change, but should be more correct. This
still runs crazy_video_pts_stuff() before everything else. On the pther
hand, --no-correct-pts or missing timestamp processing is done last. But
these things didn't really work with timeline before.
2019-05-31 17:52:26 +00:00
|
|
|
will not work fully (such as timestamp correction).
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
- If demuxer low level seeks (i.e. seeking the actual demuxer instead of
|
|
|
|
just within the demuxer cache) are performed by backward playback, the
|
|
|
|
created seek ranges may not join, because not enough overlap is achieved.
|
|
|
|
|
|
|
|
- Trying to use this with hardware video decoding will probably exhaust all
|
2019-05-31 18:13:57 +00:00
|
|
|
your GPU memory and then crash a thing or two. Or it will fail because
|
|
|
|
``--hwdec-extra-frames`` will certainly be set too low.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
2019-05-25 12:41:37 +00:00
|
|
|
- Stream recording is broken. ``--stream-record`` may keep working if you
|
|
|
|
backward play within a cached region only.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
- Relative seeks may behave weird. Small seeks backward (towards smaller
|
|
|
|
time, i.e. ``seek -1``) may not really seek properly, and audio will
|
|
|
|
remain muted for a while. Using hr-seek is recommended, which should have
|
|
|
|
none of these problems.
|
|
|
|
|
|
|
|
- Some things are just weird. For example, while seek commands manipulate
|
|
|
|
playback time in the expected way (provided they work correctly), the
|
|
|
|
framestep commands are transposed. Backstepping will perform very
|
|
|
|
expensive work to step forward by 1 frame.
|
|
|
|
|
|
|
|
Tuning:
|
|
|
|
|
2019-06-02 00:24:43 +00:00
|
|
|
- Remove all ``--vf``/``--af`` filters you have set. Disable hardware
|
|
|
|
decoding. Disable idiotic nonsense like SPDIF passthrough.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
- Increasing ``--video-reversal-buffer`` might help if reversal queue
|
|
|
|
overflow is reported, which may happen in high bitrate video, or video
|
2019-05-31 18:13:57 +00:00
|
|
|
with large GOP. Hardware decoding mostly ignores this, and you need to
|
|
|
|
increase ``--hwdec-extra-frames`` instead (until you get playback without
|
|
|
|
logged errors).
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
2019-06-02 00:24:43 +00:00
|
|
|
- The demuxer cache is essential for backward demuxing. Make sure to set
|
2020-06-23 18:46:52 +00:00
|
|
|
``--cache=yes``. The cache size might matter. If it's too small, a queue
|
|
|
|
overflow will be logged, and backward playback cannot continue, or it
|
|
|
|
performs too many low level seeks. If it's too large, implementation
|
|
|
|
tradeoffs may cause general performance issues. Use
|
|
|
|
``--demuxer-max-bytes`` to potentially increase the amount of packets the
|
|
|
|
demuxer layer can queue for reverse demuxing (basically it's the
|
|
|
|
``--video-reversal-buffer`` equivalent for the demuxer layer).
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
2020-02-29 23:40:03 +00:00
|
|
|
- Setting ``--vd-queue-enable=yes`` can help a lot to make playback smooth
|
|
|
|
(once it works).
|
|
|
|
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
- ``--demuxer-backward-playback-step`` also factors into how many seeks may
|
|
|
|
be performed, and whether backward demuxing could break due to queue
|
2019-06-02 00:24:43 +00:00
|
|
|
overflow. If it's set too high, the backstep operation needs to search
|
|
|
|
through more packets all the time, even if the cache is large enough.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
- Setting ``--demuxer-cache-wait`` may be useful to cache the entire file
|
|
|
|
into the demuxer cache. Set ``--demuxer-max-bytes`` to a large size to
|
|
|
|
make sure it can read the entire cache; ``--demuxer-max-back-bytes``
|
|
|
|
should also be set to a large size to prevent that tries to trim the
|
|
|
|
cache.
|
|
|
|
|
|
|
|
- If audio artifacts are audible, even though the AO does not underrun,
|
2019-06-02 00:24:43 +00:00
|
|
|
increasing ``--audio-backward-overlap`` might help in some cases.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
``--video-reversal-buffer=<bytesize>``, ``--audio-reversal-buffer=<bytesize>``
|
|
|
|
For backward decoding. Backward decoding decodes forward in steps, and then
|
|
|
|
reverses the decoder output. These options control the approximate maximum
|
|
|
|
amount of bytes that can be buffered. The main use of this is to avoid
|
|
|
|
unbounded resource usage; during normal backward playback, it's not supposed
|
|
|
|
to hit the limit, and if it does, it will drop frames and complain about it.
|
|
|
|
|
2019-06-02 00:24:43 +00:00
|
|
|
Use this option if you get reversal queue overflow errors during backward
|
|
|
|
playback. Increase the size until the warning disappears. Usually, the video
|
|
|
|
buffer will overflow first, especially if it's high resolution video.
|
|
|
|
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
This does not work correctly if video hardware decoding is used. The video
|
2019-06-02 00:24:43 +00:00
|
|
|
frame size will not include the referenced GPU and driver memory. Some
|
|
|
|
hardware decoders may also be limited by ``--hwdec-extra-frames``.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
How large the queue size needs to be depends entirely on the way the media
|
|
|
|
was encoded. Audio typically requires a very small buffer, while video can
|
|
|
|
require excessively large buffers.
|
|
|
|
|
|
|
|
(Technically, this allows the last frame to exceed the limit. Also, this
|
|
|
|
does not account for other buffered frames, such as inside the decoder or
|
|
|
|
the video output.)
|
|
|
|
|
|
|
|
This does not affect demuxer cache behavior at all.
|
|
|
|
|
|
|
|
See ``--list-options`` for defaults and value range. ``<bytesize>`` options
|
|
|
|
accept suffixes such as ``KiB`` and ``MiB``.
|
|
|
|
|
|
|
|
``--video-backward-overlap=<auto|number>``, ``--audio-backward-overlap=<auto|number>``
|
2019-05-24 17:17:31 +00:00
|
|
|
Number of overlapping keyframe ranges to use for backward decoding (default:
|
|
|
|
auto) ("keyframe" to be understood as in the mpv/ffmpeg specific meaning).
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
Backward decoding works by forward decoding in small steps. Some codecs
|
|
|
|
cannot restart decoding from any packet (even if it's marked as seek point),
|
|
|
|
which becomes noticeable with backward decoding (in theory this is a problem
|
|
|
|
with seeking too, but ``--hr-seek-demuxer-offset`` can fix it for seeking).
|
|
|
|
In particular, MDCT based audio codecs are affected.
|
|
|
|
|
|
|
|
The solution is to feed a previous packet to the decoder each time, and then
|
|
|
|
discard the output. This option controls how many packets to feed. The
|
2019-05-24 18:12:26 +00:00
|
|
|
``auto`` choice is currently hardcoded to 0 for video, and uses 1 for lossy
|
2019-05-31 14:24:06 +00:00
|
|
|
audio, 0 for lossless audio. For some specific lossy audio codecs, this is
|
|
|
|
set to 2.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
2019-05-24 17:17:31 +00:00
|
|
|
``--video-backward-overlap`` can potentially handle intra-refresh video,
|
|
|
|
depending on the exact conditions. You may have to use the
|
|
|
|
``--vd-lavc-show-all`` option as well.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
demux: demux multiple audio frames in backward playback
Until now, this usually passed a single audio frame to the decoder, and
then did a backstep operation (cache seek + frame search) again. This is
probably not very efficient, especially considering it has to search the
packet queue from the "start" every time again.
Also, with most audio codecs, an additional "preroll" frame was passed
first. In these cases, the preroll frame would make up 50% of audio
decoding time. Also not very efficient.
Attempt to fix this by returning multiple frames at once. This reduces
the number of backstep operations and the ratio the preoll frames. In
theory, this should help efficiency. I didn't test it though, why would
I do this? It's just a pain. Set it to unscientific 10 frames.
(Actually, these are 10 keyframes, so it's much more for codecs like
TrueHD. But I don't care about TrueHD.)
This commit changes some other implementation details. Since we can
return more than 1 non-preroll keyframe to the decoder, some new state
is needed to remember how much. The resume packet search is adjusted to
find N ("total") keyframe packets in general, not just preroll frames.
I'm removing the special case for 1 preroll packet; audio used this, but
doesn't anymore, and it's premature optimization anyway.
Expose the new mechanism with 2 new options. They're almost completely
pointless, since nobody will try them, and if they do, they won't
understand what these options truly do. And if they actually do, they
most likely would be capable of editing the source code, and we could
just hardcode the parameters. Just so you know that I know that the
added options are pointless.
The following two things are truly unrelated to this commit, and more
like general refactoring, but fortunately nobody can stop me.
Don't set back_seek_pos in dequeue_packet() anymore. This was sort of
pointless, since it was set in find_backward_restart_pos() anyway (using
some of the same packets). The latter function tries to restrict this to
the first keyframe range though, which is an optimization that in theory
might break with broken files (duh), but in these cases a lot of other
things would be broken anyway.
Don't set back_restart_* in dequeue_packet(). I think this is an
artifact of the old restart code (cf. ad9e473c555). It can be done
directly in find_backward_restart_pos() now. Although this adds another
shitty packet search loop, I prefer this, because clearer what's
actually happening.
2019-06-02 00:14:54 +00:00
|
|
|
``--video-backward-batch=<number>``, ``--audio-backward-batch=<number>``
|
|
|
|
Number of keyframe ranges to decode at once when backward decoding (default:
|
|
|
|
1 for video, 10 for audio). Another pointless tuning parameter nobody should
|
|
|
|
use. This should affect performance only. In theory, setting a number higher
|
|
|
|
than 1 for audio will reduce overhead due to less frequent backstep
|
|
|
|
operations and less redundant decoding work due to fewer decoded overlap
|
|
|
|
frames (see ``--audio-backward-overlap``). On the other hand, it requires
|
|
|
|
a larger reversal buffer, and could make playback less smooth due to
|
|
|
|
breaking pipelining (e.g. by decoding a lot, and then doing nothing for a
|
|
|
|
while).
|
|
|
|
|
|
|
|
It probably never makes sense to set ``--video-backward-batch``. But in
|
|
|
|
theory, it could help with intra-only video codecs by reducing backstep
|
|
|
|
operations.
|
|
|
|
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
``--demuxer-backward-playback-step=<seconds>``
|
|
|
|
Number of seconds the demuxer should seek back to get new packets during
|
|
|
|
backward playback (default: 60). This is useful for tuning backward
|
2019-05-31 14:33:20 +00:00
|
|
|
playback, see ``--play-dir`` for details.
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 00:10:51 +00:00
|
|
|
|
|
|
|
Setting this to a very low value or 0 may make the player think seeking is
|
|
|
|
broken, or may make it perform multiple seeks.
|
|
|
|
|
2019-06-02 00:24:43 +00:00
|
|
|
Setting this to a high value may lead to quadratic runtime behavior.
|
|
|
|
|
2014-09-01 02:25:57 +00:00
|
|
|
Program Behavior
|
|
|
|
----------------
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2016-09-10 14:29:24 +00:00
|
|
|
``--help``, ``--h``
|
2014-07-31 14:32:37 +00:00
|
|
|
Show short summary of options.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-12-16 15:09:10 +00:00
|
|
|
You can also pass a string to this option, which will list all top-level
|
|
|
|
options which contain the string in the name, e.g. ``--h=scale`` for all
|
|
|
|
options that contain the word ``scale``. The special string ``*`` lists
|
|
|
|
all top-level options.
|
2016-09-10 14:29:24 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``-v``
|
|
|
|
Increment verbosity level, one level for each ``-v`` found on the command
|
|
|
|
line.
|
|
|
|
|
|
|
|
``--version, -V``
|
|
|
|
Print version string and exit.
|
|
|
|
|
|
|
|
``--no-config``
|
2023-07-05 20:11:40 +00:00
|
|
|
Do not load default configuration or any user files. This prevents loading of
|
|
|
|
both the user-level and system-wide ``mpv.conf`` and ``input.conf`` files. Other
|
|
|
|
user files are blocked as well, such as resume playback files and cache files.
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. note::
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Files explicitly requested by command line options, like
|
|
|
|
``--include`` or ``--use-filedir-conf``, will still be loaded.
|
|
|
|
|
2015-12-19 08:26:27 +00:00
|
|
|
See also: ``--config-dir``.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
``--list-options``
|
|
|
|
Prints all available options.
|
|
|
|
|
|
|
|
``--list-properties``
|
|
|
|
Print a list of the available properties.
|
|
|
|
|
|
|
|
``--list-protocols``
|
|
|
|
Print a list of the supported protocols.
|
|
|
|
|
2015-01-27 07:46:46 +00:00
|
|
|
``--log-file=<path>``
|
|
|
|
Opens the given path for writing, and print log messages to it. Existing
|
2017-09-28 10:28:48 +00:00
|
|
|
files will be truncated. The log level is at least ``-v -v``, but
|
|
|
|
can be raised via ``--msg-level`` (the option cannot lower it below the
|
|
|
|
forced minimum log level).
|
2015-01-27 07:46:46 +00:00
|
|
|
|
2020-01-30 13:32:31 +00:00
|
|
|
A special case is the macOS bundle, it will create a log file at
|
|
|
|
``~/Library/Logs/mpv.log`` by default.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--config-dir=<path>``
|
|
|
|
Force a different configuration directory. If this is set, the given
|
|
|
|
directory is used to load configuration files, and all other configuration
|
|
|
|
directories are ignored. This means the global mpv configuration directory
|
|
|
|
as well as per-user directories are ignored, and overrides through
|
|
|
|
environment variables (``MPV_HOME``) are also ignored.
|
|
|
|
|
|
|
|
Note that the ``--no-config`` option takes precedence over this option.
|
|
|
|
|
|
|
|
``--dump-stats=<filename>``
|
|
|
|
Write certain statistics to the given file. The file is truncated on
|
|
|
|
opening. The file will contain raw samples, each with a timestamp. To
|
|
|
|
make this file into a readable, the script ``TOOLS/stats-conv.py`` can be
|
|
|
|
used (which currently displays it as a graph).
|
|
|
|
|
|
|
|
This option is useful for debugging only.
|
|
|
|
|
2014-12-07 11:49:07 +00:00
|
|
|
``--idle=<no|yes|once>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Makes mpv wait idly instead of quitting when there is no file to play.
|
2016-08-11 20:29:18 +00:00
|
|
|
Mostly useful in input mode, where mpv can be controlled through input
|
2017-12-05 22:34:25 +00:00
|
|
|
commands. (Default: ``no``)
|
2014-07-31 14:32:37 +00:00
|
|
|
|
2014-12-07 11:49:07 +00:00
|
|
|
``once`` will only idle at start and let the player close once the
|
|
|
|
first playlist has finished playing back.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--include=<configuration-file>``
|
|
|
|
Specify configuration file to be parsed after the default ones.
|
|
|
|
|
|
|
|
``--load-scripts=<yes|no>``
|
2014-12-14 23:31:30 +00:00
|
|
|
If set to ``no``, don't auto-load scripts from the ``scripts``
|
|
|
|
configuration subdirectory (usually ``~/.config/mpv/scripts/``).
|
2014-07-31 14:32:37 +00:00
|
|
|
(Default: ``yes``)
|
|
|
|
|
2019-10-25 11:41:34 +00:00
|
|
|
``--script=<filename>``, ``--scripts=file1.lua:file2.lua:...``
|
|
|
|
Load a Lua script. The second option allows you to load multiple scripts by
|
|
|
|
separating them with the path separator (``:`` on Unix, ``;`` on Windows).
|
2014-07-31 14:32:37 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
``--scripts`` is a path list option. See `List Options`_ for details.
|
|
|
|
|
2014-12-14 23:31:30 +00:00
|
|
|
``--script-opts=key1=value1,key2=value2,...``
|
|
|
|
Set options for scripts. A script can query an option by key. If an
|
2014-07-31 14:32:37 +00:00
|
|
|
option is used and what semantics the option value has depends entirely on
|
2014-12-14 23:31:30 +00:00
|
|
|
the loaded scripts. Values not claimed by any scripts are ignored.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--merge-files``
|
|
|
|
Pretend that all files passed to mpv are concatenated into a single, big
|
2016-02-20 15:22:15 +00:00
|
|
|
file. This uses timeline/EDL support internally.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
``--profile=<profile1,profile2,...>``
|
|
|
|
Use the given profile(s), ``--profile=help`` displays a list of the
|
|
|
|
defined profiles.
|
|
|
|
|
|
|
|
``--reset-on-next-file=<all|option1,option2,...>``
|
|
|
|
Normally, mpv will try to keep all settings when playing the next file on
|
|
|
|
the playlist, even if they were changed by the user during playback. (This
|
|
|
|
behavior is the opposite of MPlayer's, which tries to reset all settings
|
|
|
|
when starting next file.)
|
|
|
|
|
|
|
|
Default: Do not reset anything.
|
|
|
|
|
|
|
|
This can be changed with this option. It accepts a list of options, and
|
|
|
|
mpv will reset the value of these options on playback start to the initial
|
|
|
|
value. The initial value is either the default value, or as set by the
|
|
|
|
config file or command line.
|
|
|
|
|
|
|
|
In some cases, this might not work as expected. For example, ``--volume``
|
|
|
|
will only be reset if it is explicitly set in the config file or the
|
|
|
|
command line.
|
|
|
|
|
|
|
|
The special name ``all`` resets as many options as possible.
|
2013-01-23 09:56:36 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
2013-01-23 09:56:36 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
- ``--reset-on-next-file=pause``
|
|
|
|
Reset pause mode when switching to the next file.
|
|
|
|
- ``--reset-on-next-file=fullscreen,speed``
|
|
|
|
Reset fullscreen and playback speed settings if they were changed
|
|
|
|
during playback.
|
|
|
|
- ``--reset-on-next-file=all``
|
|
|
|
Try to reset all settings that were changed during playback.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--show-profile=<profile>``
|
2019-10-31 16:32:57 +00:00
|
|
|
Show the description and content of a profile. Lists all profiles if no
|
|
|
|
parameter is provided.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
``--use-filedir-conf``
|
|
|
|
Look for a file-specific configuration file in the same directory as the
|
|
|
|
file that is being played. See `File-specific Configuration Files`_.
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
May be dangerous if playing from untrusted media.
|
|
|
|
|
2014-11-19 17:51:53 +00:00
|
|
|
``--ytdl``, ``--no-ytdl``
|
|
|
|
Enable the youtube-dl hook-script. It will look at the input URL, and will
|
|
|
|
play the video located on the website. This works with many streaming sites,
|
2015-01-02 17:32:14 +00:00
|
|
|
not just the one that the script is named after. This requires a recent
|
2018-01-11 22:36:07 +00:00
|
|
|
version of youtube-dl to be installed on the system. (Enabled by default.)
|
2014-11-19 17:51:53 +00:00
|
|
|
|
|
|
|
If the script can't do anything with an URL, it will do nothing.
|
|
|
|
|
2020-02-20 23:30:41 +00:00
|
|
|
This accepts a set of options, which can be passed to it with the
|
|
|
|
``--script-opts`` option (using ``ytdl_hook-`` as prefix):
|
|
|
|
|
|
|
|
``try_ytdl_first=<yes|no>``
|
|
|
|
If 'yes' will try parsing the URL with youtube-dl first, instead of the
|
|
|
|
default where it's only after mpv failed to open it. This mostly depends
|
|
|
|
on whether most of your URLs need youtube-dl parsing.
|
|
|
|
|
|
|
|
``exclude=<URL1|URL2|...``
|
|
|
|
A ``|``-separated list of URL patterns which mpv should not use with
|
|
|
|
youtube-dl. The patterns are matched after the ``http(s)://`` part of
|
|
|
|
the URL.
|
|
|
|
|
|
|
|
``^`` matches the beginning of the URL, ``$`` matches its end, and you
|
|
|
|
should use ``%`` before any of the characters ``^$()%|,.[]*+-?`` to
|
|
|
|
match that character.
|
|
|
|
|
|
|
|
.. admonition:: Examples
|
|
|
|
|
|
|
|
- ``--script-opts=ytdl_hook-exclude='^youtube%.com'``
|
|
|
|
will exclude any URL that starts with ``http://youtube.com`` or
|
|
|
|
``https://youtube.com``.
|
|
|
|
- ``--script-opts=ytdl_hook-exclude='%.mkv$|%.mp4$'``
|
|
|
|
will exclude any URL that ends with ``.mkv`` or ``.mp4``.
|
|
|
|
|
|
|
|
See more lua patterns here: https://www.lua.org/manual/5.1/manual.html#5.4.1
|
|
|
|
|
|
|
|
``all_formats=<yes|no>``
|
|
|
|
If 'yes' will attempt to add all formats found reported by youtube-dl
|
|
|
|
(default: no). Each format is added as a separate track. In addition,
|
|
|
|
they are delay-loaded, and actually opened only when a track is selected
|
2020-02-21 13:18:35 +00:00
|
|
|
(this should keep load times as low as without this option).
|
|
|
|
|
|
|
|
It adds average bitrate metadata, if available, which means you can use
|
|
|
|
``--hls-bitrate`` to decide which track to select. (HLS used to be the
|
2020-02-20 23:30:41 +00:00
|
|
|
only format whose alternative quality streams were exposed in a similar
|
|
|
|
way, thus the option name.)
|
|
|
|
|
2020-02-21 13:18:35 +00:00
|
|
|
Tracks which represent formats that were selected by youtube-dl as
|
|
|
|
default will have the default flag set. This means mpv should generally
|
|
|
|
still select formats chosen with ``--ytdl-format`` by default.
|
2020-02-20 23:30:41 +00:00
|
|
|
|
|
|
|
Although this mechanism makes it possible to switch streams at runtime,
|
|
|
|
it's not suitable for this purpose for various technical reasons. (It's
|
|
|
|
slow, which can't be really fixed.) In general, this option is not
|
|
|
|
useful, and was only added to show that it's possible.
|
|
|
|
|
2020-02-21 10:50:58 +00:00
|
|
|
There are two cases that must be considered when doing quality/bandwidth
|
|
|
|
selection:
|
|
|
|
|
|
|
|
1. Completely separate audio and video streams (DASH-like). Each of
|
|
|
|
these streams contain either only audio or video, so you can
|
|
|
|
mix and combine audio/video bandwidths without restriction. This
|
|
|
|
intuitively matches best with the concept of selecting quality
|
|
|
|
by track (what ``all_formats`` is supposed to do).
|
|
|
|
|
|
|
|
2. Separate sets of muxed audio and video streams. Each version of
|
|
|
|
the media contains both an audio and video stream, and they are
|
|
|
|
interleaved. In order not to waste bandwidth, you should only
|
|
|
|
select one of these versions (if, for example, you select an
|
|
|
|
audio stream, then video will be downloaded, even if you selected
|
|
|
|
video from a different stream).
|
|
|
|
|
|
|
|
mpv will still represent them as separate tracks, but will set
|
|
|
|
the title of each track to ``muxed-N``, where ``N`` is replaced
|
|
|
|
with the youtube-dl format ID of the originating stream.
|
|
|
|
|
|
|
|
Some sites will mix 1. and 2., but we assume that they do so for
|
|
|
|
compatibility reasons, and there is no reason to use them at all.
|
|
|
|
|
|
|
|
``force_all_formats=<yes|no>``
|
2020-02-20 23:30:41 +00:00
|
|
|
If set to 'yes', and ``all_formats`` is also set to 'yes', this will
|
2020-02-21 10:50:58 +00:00
|
|
|
try to represent all youtube-dl reported formats as tracks, even if
|
|
|
|
mpv would normally use the direct URL reported by it (default: yes).
|
|
|
|
|
|
|
|
It appears this normally makes a difference if youtube-dl works on a
|
|
|
|
master HLS playlist.
|
|
|
|
|
|
|
|
If this is set to 'no', this specific kind of stream is treated like
|
|
|
|
``all_formats`` is set to 'no', and the stream selection as done by
|
|
|
|
youtube-dl (via ``--ytdl-format``) is used.
|
2020-02-20 23:30:41 +00:00
|
|
|
|
|
|
|
``use_manifests=<yes|no>``
|
|
|
|
Make mpv use the master manifest URL for formats like HLS and DASH,
|
|
|
|
if available, allowing for video/audio selection in runtime (default:
|
|
|
|
no). It's disabled ("no") by default for performance reasons.
|
2017-07-08 13:43:37 +00:00
|
|
|
|
2020-10-25 01:26:06 +00:00
|
|
|
``ytdl_path=youtube-dl``
|
2021-09-17 07:37:09 +00:00
|
|
|
Configure paths to youtube-dl's executable or a compatible fork's. The
|
|
|
|
paths should be separated by : on Unix and ; on Windows. mpv looks in
|
|
|
|
order for the configured paths in PATH and in mpv's config directory.
|
|
|
|
The defaults are "yt-dlp", "yt-dlp_x86" and "youtube-dl". On Windows
|
2023-08-13 05:10:27 +00:00
|
|
|
the suffix extension is not necessary, but only ".exe" is acceptable.
|
2020-10-25 01:26:06 +00:00
|
|
|
|
2020-02-19 15:33:48 +00:00
|
|
|
.. admonition:: Why do the option names mix ``_`` and ``-``?
|
|
|
|
|
|
|
|
I have no idea.
|
|
|
|
|
2020-02-19 15:31:04 +00:00
|
|
|
``--ytdl-format=<ytdl|best|worst|mp4|webm|...>``
|
2014-11-19 22:33:28 +00:00
|
|
|
Video format/quality that is directly passed to youtube-dl. The possible
|
|
|
|
values are specific to the website and the video, for a given url the
|
|
|
|
available formats can be found with the command
|
2014-12-07 21:58:54 +00:00
|
|
|
``youtube-dl --list-formats URL``. See youtube-dl's documentation for
|
2015-10-10 22:35:35 +00:00
|
|
|
available aliases.
|
2020-02-19 15:31:04 +00:00
|
|
|
(Default: ``bestvideo+bestaudio/best``)
|
|
|
|
|
|
|
|
The ``ytdl`` value does not pass a ``--format`` option to youtube-dl at all,
|
|
|
|
and thus does not override its default. Note that sometimes youtube-dl
|
|
|
|
returns a format that mpv cannot use, and in these cases the mpv default
|
|
|
|
may work better.
|
2014-11-19 22:33:28 +00:00
|
|
|
|
2015-02-22 20:32:42 +00:00
|
|
|
``--ytdl-raw-options=<key>=<value>[,<key>=<value>[,...]]``
|
2015-06-17 17:37:25 +00:00
|
|
|
Pass arbitrary options to youtube-dl. Parameter and argument should be
|
2015-02-22 20:32:42 +00:00
|
|
|
passed as a key-value pair. Options without argument must include ``=``.
|
2015-05-10 10:36:55 +00:00
|
|
|
|
2015-02-22 20:32:42 +00:00
|
|
|
There is no sanity checking so it's possible to break things (i.e.
|
|
|
|
passing invalid parameters to youtube-dl).
|
|
|
|
|
2018-01-15 17:56:44 +00:00
|
|
|
A proxy URL can be passed for youtube-dl to use it in parsing the website.
|
|
|
|
This is useful for geo-restricted URLs. After youtube-dl parsing, some
|
|
|
|
URLs also require a proxy for playback, so this can pass that proxy
|
|
|
|
information to mpv. Take note that SOCKS proxies aren't supported and
|
|
|
|
https URLs also bypass the proxy. This is a limitation in FFmpeg.
|
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2015-02-22 20:32:42 +00:00
|
|
|
.. admonition:: Example
|
2015-05-10 10:36:55 +00:00
|
|
|
|
2017-07-11 22:55:04 +00:00
|
|
|
- ``--ytdl-raw-options=username=user,password=pass``
|
|
|
|
- ``--ytdl-raw-options=force-ipv6=``
|
2018-01-15 17:56:44 +00:00
|
|
|
- ``--ytdl-raw-options=proxy=[http://127.0.0.1:3128]``
|
|
|
|
- ``--ytdl-raw-options-append=proxy=http://127.0.0.1:3128``
|
2015-02-22 20:32:42 +00:00
|
|
|
|
2017-09-26 23:17:47 +00:00
|
|
|
``--load-stats-overlay=<yes|no>``
|
|
|
|
Enable the builtin script that shows useful playback information on a key
|
|
|
|
binding (default: yes). By default, the ``i`` key is used (``I`` to make
|
|
|
|
the overlay permanent).
|
|
|
|
|
2019-12-07 16:16:10 +00:00
|
|
|
``--load-osd-console=<yes|no>``
|
2022-04-21 16:50:18 +00:00
|
|
|
Enable the built-in script that shows a console on a key binding and lets
|
|
|
|
you enter commands (default: yes). The ````` key is used to show the
|
|
|
|
console by default, and ``ESC`` to hide it again.
|
2019-12-07 16:16:10 +00:00
|
|
|
|
2020-08-05 20:37:47 +00:00
|
|
|
``--load-auto-profiles=<yes|no|auto>``
|
|
|
|
Enable the builtin script that does auto profiles (default: auto). See
|
|
|
|
`Conditional auto profiles`_ for details. ``auto`` will load the script,
|
|
|
|
but immediately unload it if there are no conditional profiles.
|
|
|
|
|
2016-09-23 19:24:50 +00:00
|
|
|
``--player-operation-mode=<cplayer|pseudo-gui>``
|
|
|
|
For enabling "pseudo GUI mode", which means that the defaults for some
|
|
|
|
options are changed. This option should not normally be used directly, but
|
|
|
|
only by mpv internally, or mpv-provided scripts, config files, or .desktop
|
2020-02-14 11:58:45 +00:00
|
|
|
files. See `PSEUDO GUI MODE`_ for details.
|
2016-09-23 19:24:50 +00:00
|
|
|
|
2021-11-01 14:15:52 +00:00
|
|
|
Watch Later
|
|
|
|
-----------
|
|
|
|
|
|
|
|
``--save-position-on-quit``
|
|
|
|
Always save the current playback position on quit. When this file is
|
|
|
|
played again later, the player will seek to the old playback position on
|
|
|
|
start. This does not happen if playback of a file is stopped in any other
|
|
|
|
way than quitting. For example, going to the next file in the playlist
|
|
|
|
will not save the position, and start playback at beginning the next time
|
|
|
|
the file is played.
|
|
|
|
|
|
|
|
This behavior is disabled by default, but is always available when quitting
|
|
|
|
the player with Shift+Q.
|
|
|
|
|
|
|
|
See `RESUMING PLAYBACK`_.
|
|
|
|
|
|
|
|
``--watch-later-directory=<path>``
|
|
|
|
The directory in which to store the "watch later" temporary files.
|
|
|
|
|
2023-05-03 00:29:27 +00:00
|
|
|
If this option is unset, the files will be stored in a subdirectory
|
|
|
|
named "watch_later" underneath the local state directory
|
|
|
|
(usually ``~/.local/state/mpv/``).
|
2021-11-01 14:15:52 +00:00
|
|
|
|
|
|
|
``--no-resume-playback``
|
|
|
|
Do not restore playback position from the ``watch_later`` configuration
|
|
|
|
subdirectory (usually ``~/.config/mpv/watch_later/``).
|
|
|
|
|
|
|
|
``--resume-playback-check-mtime``
|
|
|
|
Only restore the playback position from the ``watch_later`` configuration
|
|
|
|
subdirectory (usually ``~/.config/mpv/watch_later/``) if the file's
|
|
|
|
modification time is the same as at the time of saving. This may prevent
|
|
|
|
skipping forward in files with the same name which have different content.
|
|
|
|
(Default: ``no``)
|
|
|
|
|
|
|
|
``--watch-later-options=option1,option2,...``
|
|
|
|
The options that are saved in "watch later" files if they have been changed
|
|
|
|
since when mpv started. These values will be restored the next time the
|
2023-01-08 06:16:15 +00:00
|
|
|
files are played. Note that the playback position is saved via the ``start``
|
|
|
|
option.
|
2021-11-01 14:15:52 +00:00
|
|
|
|
|
|
|
When removing options, existing watch later data won't be modified and will
|
|
|
|
still be applied fully, but new watch later data won't contain these
|
|
|
|
options.
|
|
|
|
|
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
|
|
|
.. admonition:: Examples
|
|
|
|
|
|
|
|
- ``--watch-later-options-remove=fullscreen``
|
|
|
|
The fullscreen state won't be saved to watch later files.
|
|
|
|
- ``--watch-later-options-remove=volume``
|
|
|
|
``--watch-later-options-remove=mute``
|
|
|
|
The volume and mute state won't be saved to watch later files.
|
|
|
|
- ``--watch-later-options-clr``
|
2023-01-08 06:16:15 +00:00
|
|
|
No option will be saved to watch later files.
|
2021-11-01 14:15:52 +00:00
|
|
|
|
|
|
|
``--write-filename-in-watch-later-config``
|
|
|
|
Prepend the watch later config files with the name of the file they refer
|
|
|
|
to. This is simply written as comment on the top of the file.
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
This option may expose privacy-sensitive information and is thus
|
|
|
|
disabled by default.
|
|
|
|
|
|
|
|
``--ignore-path-in-watch-later-config``
|
|
|
|
Ignore path (i.e. use filename only) when using watch later feature.
|
|
|
|
(Default: disabled)
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Video
|
|
|
|
-----
|
|
|
|
|
2016-09-07 10:55:21 +00:00
|
|
|
``--vo=<driver>``
|
|
|
|
Specify the video output backend to be used. See `VIDEO OUTPUT DRIVERS`_ for
|
|
|
|
details and descriptions of available drivers.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
2016-12-23 17:12:29 +00:00
|
|
|
``--vd=<...>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Specify a priority list of video decoders to be used, according to their
|
|
|
|
family and name. See ``--ad`` for further details. Both of these options
|
|
|
|
use the same syntax and semantics; the only difference is that they
|
|
|
|
operate on different codec lists.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
See ``--vd=help`` for a full list of available decoders.
|
|
|
|
|
|
|
|
``--vf=<filter1[=parameter1:parameter2:...],filter2,...>``
|
|
|
|
Specify a list of video filters to apply to the video stream. See
|
|
|
|
`VIDEO FILTERS`_ for details and descriptions of the available filters.
|
|
|
|
The option variants ``--vf-add``, ``--vf-pre``, ``--vf-del`` and
|
|
|
|
``--vf-clr`` exist to modify a previously specified list, but you
|
|
|
|
should not need these for typical use.
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``--untimed``
|
2012-08-02 17:31:33 +00:00
|
|
|
Do not sleep when outputting video frames. Useful for benchmarks when used
|
2013-07-08 16:02:14 +00:00
|
|
|
with ``--no-audio.``
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
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
|
|
|
``--framedrop=<mode>``
|
|
|
|
Skip displaying some frames to maintain A/V sync on slow systems, or
|
|
|
|
playing high framerate video on video outputs that have an upper framerate
|
|
|
|
limit.
|
|
|
|
|
|
|
|
The argument selects the drop methods, and can be one of the following:
|
|
|
|
|
|
|
|
<no>
|
2019-11-02 13:29:24 +00:00
|
|
|
Disable any frame dropping. Not recommended, for testing only.
|
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
|
|
|
<vo>
|
2014-08-17 00:51:13 +00:00
|
|
|
Drop late frames on video output (default). This still decodes and
|
2019-11-02 13:29:24 +00:00
|
|
|
filters all frames, but doesn't render them on the VO. Drops are
|
|
|
|
indicated in the terminal status line as ``Dropped:`` field.
|
|
|
|
|
|
|
|
In audio sync. mode, this drops frames that are outdated at the time of
|
|
|
|
display. If the decoder is too slow, in theory all frames would have to
|
|
|
|
be dropped (because all frames are too late) - to avoid this, frame
|
|
|
|
dropping stops if the effective framerate is below 10 FPS.
|
|
|
|
|
|
|
|
In display-sync. modes (see ``--video-sync``), this affects only how
|
|
|
|
A/V drops or repeats frames. If this mode is disabled, A/V desync will
|
|
|
|
in theory not affect video scheduling anymore (much like the
|
|
|
|
``display-resample-desync`` mode). However, even if disabled, frames
|
|
|
|
will still be skipped (i.e. dropped) according to the ratio between
|
|
|
|
video and display frequencies.
|
|
|
|
|
|
|
|
This is the recommended mode, and the default.
|
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
|
|
|
<decoder>
|
|
|
|
Old, decoder-based framedrop mode. (This is the same as ``--framedrop=yes``
|
|
|
|
in mpv 0.5.x and before.) This tells the decoder to skip frames (unless
|
|
|
|
they are needed to decode future frames). May help with slow systems,
|
2015-06-17 17:37:25 +00:00
|
|
|
but can produce unwatchable choppy output, or even freeze the display
|
2019-11-02 13:29:24 +00:00
|
|
|
completely.
|
|
|
|
|
|
|
|
This uses a heuristic which may not make sense, and in general cannot
|
|
|
|
achieve good results, because the decoder's frame dropping cannot be
|
|
|
|
controlled in a predictable manner. Not recommended.
|
|
|
|
|
|
|
|
Even if you want to use this, prefer ``decoder+vo`` for better results.
|
|
|
|
|
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
|
|
|
The ``--vd-lavc-framedrop`` option controls what frames to drop.
|
|
|
|
<decoder+vo>
|
2019-11-02 13:29:24 +00:00
|
|
|
Enable both modes. Not recommended. Better than just ``decoder`` mode.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-09-20 13:14:43 +00:00
|
|
|
``--vo=vdpau`` has its own code for the ``vo`` framedrop mode. Slight
|
|
|
|
differences to other VOs are possible.
|
2013-09-10 13:09:24 +00:00
|
|
|
|
2018-03-02 14:37:34 +00:00
|
|
|
``--video-latency-hacks=<yes|no>``
|
|
|
|
Enable some things which tend to reduce video latency by 1 or 2 frames
|
|
|
|
(default: no). Note that this option might be removed without notice once
|
|
|
|
the player's timing code does not inherently need to do these things
|
|
|
|
anymore.
|
|
|
|
|
|
|
|
This does:
|
|
|
|
|
2020-06-02 06:10:02 +00:00
|
|
|
- Use the demuxer reported FPS for frame dropping. This avoids the
|
|
|
|
player needing to decode 1 frame in advance, lowering total latency in
|
2018-03-02 14:37:34 +00:00
|
|
|
effect. This also means that if the demuxer reported FPS is wrong, or
|
|
|
|
the video filter chain changes FPS (e.g. deinterlacing), then it could
|
|
|
|
drop too many or not enough frames.
|
|
|
|
- Disable waiting for the first video frame. Normally the player waits for
|
|
|
|
the first video frame to be fully rendered before starting playback
|
|
|
|
properly. Some VOs will lazily initialize stuff when rendering the first
|
|
|
|
frame, so if this is not done, there is some likeliness that the VO has
|
|
|
|
to drop some frames if rendering the first frame takes longer than needed.
|
|
|
|
|
2019-11-24 23:47:53 +00:00
|
|
|
``--override-display-fps=<fps>``
|
2015-11-25 21:11:14 +00:00
|
|
|
Set the display FPS used with the ``--video-sync=display-*`` modes. By
|
2016-01-18 15:36:06 +00:00
|
|
|
default, a detected value is used. Keep in mind that setting an incorrect
|
|
|
|
value (even if slightly incorrect) can ruin video playback. On multi-monitor
|
|
|
|
systems, there is a chance that the detected value is from the wrong
|
|
|
|
monitor.
|
|
|
|
|
|
|
|
Set this option only if you have reason to believe the automatically
|
|
|
|
determined value is wrong.
|
2014-08-15 22:05:02 +00:00
|
|
|
|
2019-11-24 23:47:53 +00:00
|
|
|
``--display-fps=<fps>``
|
|
|
|
Deprecated alias for ``--override-display-fps``.
|
|
|
|
|
vd_lavc: let the user provide a priority list of hwdecs to consider
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes #11797
2023-06-18 19:07:30 +00:00
|
|
|
``--hwdec=<api1,api2,...|no|auto|auto-safe|auto-copy>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Specify the hardware video decoding API that should be used if possible.
|
|
|
|
Whether hardware decoding is actually done depends on the video codec. If
|
|
|
|
hardware decoding is not possible, mpv will fall back on software decoding.
|
2013-09-10 13:09:24 +00:00
|
|
|
|
2022-03-05 18:49:56 +00:00
|
|
|
Hardware decoding is not enabled by default, to keep the out-of-the-box
|
|
|
|
configuration as reliable as possible. However, when using modern hardware,
|
|
|
|
hardware video decoding should work correctly, offering reduced CPU usage,
|
|
|
|
and possibly lower power consumption. On older systems, it may be necessary
|
|
|
|
to use hardware decoding due to insufficient CPU resources; and even on
|
|
|
|
modern systems, sufficiently complex content (eg: 4K60 AV1) may require it.
|
2019-11-03 23:01:05 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Use the ``Ctrl+h`` shortcut to toggle hardware decoding at runtime. It
|
2023-07-02 00:17:44 +00:00
|
|
|
toggles this option between ``auto-safe`` and ``no``.
|
2019-11-03 23:01:05 +00:00
|
|
|
|
2022-03-05 18:49:56 +00:00
|
|
|
If you decide you want to use hardware decoding by default, the general
|
|
|
|
recommendation is to try out decoding with the command line option, and
|
|
|
|
prove to yourself that it works as desired for the content you care
|
|
|
|
about. After that, you can add it to your config file.
|
|
|
|
|
|
|
|
When testing, you should start by using ``hwdec=auto-safe`` as it will
|
|
|
|
limit itself to choosing from hwdecs that are actively supported by the
|
2022-04-25 11:27:18 +00:00
|
|
|
development team. If that doesn't result in working hardware decoding,
|
2022-03-05 18:49:56 +00:00
|
|
|
you can try ``hwdec=auto`` to have it attempt to load every possible
|
|
|
|
hwdec, but if ``auto-safe`` didn't work, you will probably need to know
|
|
|
|
exactly which hwdec matches your hardware and read up on that entry
|
|
|
|
below.
|
|
|
|
|
|
|
|
If ``auto-safe`` or ``auto`` produced the desired results, we recommend
|
|
|
|
just sticking with that and only setting a specific hwdec in your config
|
|
|
|
file if it is really necessary.
|
|
|
|
|
|
|
|
If you use the Ubuntu package, keep in mind that their
|
|
|
|
``/etc/mpv/mpv.conf`` contains ``hwdec=vaapi``, which is less than
|
|
|
|
ideal as it may not be the right choice for your system, and it may end
|
|
|
|
up using an inefficient wrapper library under the covers. We recommend
|
|
|
|
removing this line or deleting the file altogether.
|
2019-11-03 23:01:05 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Even if enabled, hardware decoding is still only white-listed for some
|
|
|
|
codecs. See ``--hwdec-codecs`` to enable hardware decoding in more cases.
|
|
|
|
|
2019-12-24 08:24:22 +00:00
|
|
|
.. admonition:: Which method to choose?
|
|
|
|
|
|
|
|
- If you only want to enable hardware decoding at runtime, don't set the
|
|
|
|
parameter, or put ``hwdec=no`` into your ``mpv.conf`` (relevant on
|
|
|
|
distros which force-enable it by default, such as on Ubuntu). Use the
|
|
|
|
``Ctrl+h`` default binding to enable it at runtime.
|
|
|
|
- If you're not sure, but want hardware decoding always enabled by
|
|
|
|
default, put ``hwdec=auto-safe`` into your ``mpv.conf``, and
|
2022-03-05 18:49:56 +00:00
|
|
|
acknowledge that this may cause problems.
|
2019-12-24 08:24:22 +00:00
|
|
|
- If you want to test available hardware decoding methods, pass
|
2019-12-24 15:02:49 +00:00
|
|
|
``--hwdec=auto --hwdec-codecs=all`` and look at the terminal output.
|
|
|
|
- If you're a developer, or want to perform elaborate tests, you may
|
|
|
|
need any of the other possible option values.
|
2019-12-24 08:24:22 +00:00
|
|
|
|
vd_lavc: let the user provide a priority list of hwdecs to consider
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes #11797
2023-06-18 19:07:30 +00:00
|
|
|
This option accepts a comma delimited list of ``api`` types, along with certain
|
|
|
|
special values:
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:no: always use software decoding (default)
|
2023-07-02 00:17:44 +00:00
|
|
|
:auto-safe: enable any whitelisted hw decoder (see below)
|
2019-12-24 08:24:22 +00:00
|
|
|
:auto: forcibly enable any hw decoder found (see below)
|
2023-07-02 17:13:42 +00:00
|
|
|
:yes: exactly the same as ``auto-safe``
|
2016-09-15 11:50:50 +00:00
|
|
|
:auto-copy: enable best hw decoder with copy-back (see below)
|
2022-03-05 18:49:56 +00:00
|
|
|
|
vd_lavc: let the user provide a priority list of hwdecs to consider
Today, the only way to make mpv consider multiple hwdecs and pick the
first one that works is to use one of the `auto` modes. But the list
that is considered in those cases is hard-coded. If the user wants to
provide their own list, they are out of luck.
And I think that there is now a significant reason to support this -
the new Vulkan hwdec is definitely not ready to be in the auto list,
but if you want to use it by default, it will not work with many codecs
that are normally hardware decodable (only h.264, hevc and av1 if you
are very lucky). Everything else will fall back to software decoding.
Instead, what you really want to say is: use Vulkan for whatever it
supports, and fall back to my old hwdec for everything else.
One side-effect of this implementation is that you can freely mix
hwdec names and special values like `auto` and `no`. The behaviour will
be correct, so I didn't try and prohibit any combinations. However,
some combinations will be silly - eg: sticking any further values after
`no` will result in them being ignored. On the other hand, a
combination like `vulkan,auto` could be very useful as that will use
Vulkan if possible, and if not, run the normal auto routine.
Fixes #11797
2023-06-18 19:07:30 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
Special values can be mixed with api names. eg: ``vaapi,auto`` will try
|
|
|
|
and use the ``vaapi`` hwdec, and if that fails, will run through the
|
|
|
|
normal ``auto`` logic.
|
|
|
|
|
2022-03-05 18:49:56 +00:00
|
|
|
Actively supported hwdecs:
|
|
|
|
|
|
|
|
:d3d11va: requires ``--vo=gpu`` with ``--gpu-context=d3d11`` or
|
|
|
|
``--gpu-context=angle`` (Windows 8+ only)
|
|
|
|
:d3d11va-copy: copies video back to system RAM (Windows 8+ only)
|
2021-01-01 23:53:23 +00:00
|
|
|
:videotoolbox: requires ``--vo=gpu`` (macOS 10.8 and up),
|
2019-11-04 15:17:07 +00:00
|
|
|
or ``--vo=libmpv`` (iOS 9.0 and up)
|
2021-01-01 23:53:23 +00:00
|
|
|
:videotoolbox-copy: copies video back into system RAM (macOS 10.8 or iOS 9.0 and up)
|
2022-09-29 13:50:51 +00:00
|
|
|
:vaapi: requires ``--vo=gpu``, ``--vo=vaapi`` or ``--vo=dmabuf-wayland`` (Linux only)
|
2022-03-05 18:49:56 +00:00
|
|
|
:vaapi-copy: copies video back into system RAM (Linux with some GPUs only)
|
|
|
|
:nvdec: requires ``--vo=gpu`` (Any platform CUDA is available)
|
|
|
|
:nvdec-copy: copies video back to system RAM (Any platform CUDA is available)
|
hwdec/drmprime: add drmprime hwdec-interop
In the confusing landscape of hardware video decoding APIs, we have had
a long standing support gap for the v4l2 based APIs implemented for the
various SoCs from Rockship, Amlogic, Allwinner, etc. While VAAPI is the
defacto default for desktop GPUs, the developers who work on these SoCs
(who are not the vendors!) have preferred to implement kernel APIs
rather than maintain a userspace driver as VAAPI would require.
While there are two v4l2 APIs (m2m and requests), and multiple forks of
ffmpeg where support for those APIs languishes without reaching
upstream, we can at least say that these APIs export frames as DRMPrime
dmabufs, and that they use the ffmpeg drm hwcontext.
With those two constants, it is possible for us to write a
hwdec-interop without worrying about the mess underneath - for the most
part.
Accordingly, this change implements a hwdec-interop for any decoder
that produces frames as DRMPrime dmabufs. The bulk of the heavy
lifting is done by the dmabuf interop code we already had from
supporting vaapi, and which I refactored for reusability in a previous
set of changes.
When we combine that with the fact that we can't probe for supported
formats, the new code in this change is pretty simple.
This change also includes the hwcontext_fns that are required for us to
be able to configure the hwcontext used by `hwdec=drm-copy`. This is
technically unrelated, but it seemed a good time to fill this gap.
From a testing perspective, I have directly tested on a RockPRO64,
while others have tested with different flavours of Rockchip and on
Amlogic, providing m2m coverage.
I have some other SoCs that I need to spin up to test with, but I don't
expect big surprises, and when we inevitably need to account for new
special cases down the line, we can do so - we won't be able to support
every possible configuration blindly.
2022-07-31 20:47:23 +00:00
|
|
|
:drm: requires ``--vo=gpu`` (Linux only)
|
2023-03-27 20:42:17 +00:00
|
|
|
:drm-copy: copies video back to system RAM (Linux only)
|
hwdec_vulkan: add Vulkan HW Interop
Vulkan Video Decoding has finally become a reality, as it's now
showing up in shipping drivers, and the ffmpeg support has been
merged.
With that in mind, this change introduces HW interop support for
ffmpeg Vulkan frames. The implementation is functionally complete - it
can display frames produced by hardware decoding, and it can work with
ffmpeg vulkan filters. There are still various caveats due to gaps and
bugs in drivers, so YMMV, as always.
Primary testing has been done on Intel, AMD, and nvidia hardware on
Linux with basic Windows testing on nvidia.
Notable caveats:
* Due to driver bugs, video decoding on nvidia does not work right now,
unless you use the Vulkan Beta driver. It can be worked around, but
requires ffmpeg changes that are not considered acceptable to merge.
* Even if those work-arounds are applied, Vulkan filters will not work
on video that was decoded by Vulkan, due to additional bugs in the
nvidia drivers. The filters do work correctly on content decoded some
other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload
with --vf=format=vulkan)
* Vulkan filters can only be used with drivers that support
VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet.
There is an MR outstanding for this.
* When dealing with 1080p content, there may be some visual distortion
in the bottom lines of frames due to chroma scaling incorporating the
extra hidden lines at the bottom of the frame (1080p content is
actually stored as 1088 lines), depending on the hardware/driver
combination and the scaling algorithm. This cannot be easily
addressed as the mechanical fix for it violates the Vulkan spec, and
probably requires a spec change to resolve properly.
All of these caveats will be fixed in either drivers or ffmpeg, and so
will not require mpv changes (unless something unexpected happens)
If you want to run on nvidia with the non-beta drivers, you can this
ffmpeg tree with the work-around patches:
* https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 19:21:29 +00:00
|
|
|
:vulkan: requires ``--vo=gpu-next`` (Any platform with Vulkan Video Decoding)
|
|
|
|
:vulkan-copy: copies video back to system RAM (Any platform with Vulkan Video Decoding)
|
2022-03-05 18:49:56 +00:00
|
|
|
|
|
|
|
Other hwdecs (only use if you know you have to):
|
|
|
|
|
2017-12-05 12:47:59 +00:00
|
|
|
:dxva2: requires ``--vo=gpu`` with ``--gpu-context=d3d11``,
|
|
|
|
``--gpu-context=angle`` or ``--gpu-context=dxinterop``
|
|
|
|
(Windows only)
|
2015-03-19 22:48:32 +00:00
|
|
|
:dxva2-copy: copies video back to system RAM (Windows only)
|
2022-03-05 18:49:56 +00:00
|
|
|
:vdpau: requires ``--vo=gpu`` with X11, or ``--vo=vdpau`` (Linux only)
|
|
|
|
:vdpau-copy: copies video back into system RAM (Linux with some GPUs only)
|
2021-10-18 14:50:39 +00:00
|
|
|
:mediacodec: requires ``--vo=gpu --gpu-context=android``
|
|
|
|
or ``--vo=mediacodec_embed`` (Android only)
|
2017-07-06 17:40:40 +00:00
|
|
|
:mediacodec-copy: copies video back to system RAM (Android only)
|
2017-12-14 18:31:09 +00:00
|
|
|
:mmal: requires ``--vo=gpu`` (Raspberry Pi only - default if available)
|
|
|
|
:mmal-copy: copies video back to system RAM (Raspberry Pi only)
|
2019-12-29 22:28:34 +00:00
|
|
|
:cuda: requires ``--vo=gpu`` (Any platform CUDA is available)
|
|
|
|
:cuda-copy: copies video back to system RAM (Any platform CUDA is available)
|
2016-10-09 16:18:14 +00:00
|
|
|
:crystalhd: copies video back to system RAM (Any platform supported by hardware)
|
2017-10-23 19:12:45 +00:00
|
|
|
:rkmpp: requires ``--vo=gpu`` (some RockChip devices only)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``auto`` tries to automatically enable hardware decoding using the first
|
|
|
|
available method. This still depends what VO you are using. For example,
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
if you are not using ``--vo=gpu`` or ``--vo=vdpau``, vdpau decoding will
|
2014-11-12 16:47:09 +00:00
|
|
|
never be enabled. Also note that if the first found method doesn't actually
|
|
|
|
work, it will always fall back to software decoding, instead of trying the
|
|
|
|
next method (might matter on some Linux systems).
|
|
|
|
|
2019-12-24 08:24:22 +00:00
|
|
|
``auto-safe`` is similar to ``auto``, but allows only whitelisted methods
|
|
|
|
that are considered "safe". This is supposed to be a reasonable way to
|
|
|
|
enable hardware decdoding by default in a config file (even though you
|
|
|
|
shouldn't do that anyway; prefer runtime enabling with ``Ctrl+h``). Unlike
|
|
|
|
``auto``, this will not try to enable unknown or known-to-be-bad methods. In
|
|
|
|
addition, this may disable hardware decoding in other situations when it's
|
|
|
|
known to cause problems, but currently this mechanism is quite primitive.
|
|
|
|
(As an example for something that still causes problems: certain
|
|
|
|
combinations of HEVC and Intel chips on Windows tend to cause mpv to crash,
|
|
|
|
most likely due to driver bugs.)
|
|
|
|
|
|
|
|
``auto-copy-safe`` selects the union of methods selected with ``auto-safe``
|
|
|
|
and ``auto-copy``.
|
|
|
|
|
2016-05-11 14:18:58 +00:00
|
|
|
``auto-copy`` selects only modes that copy the video data back to system
|
2017-09-26 20:19:48 +00:00
|
|
|
memory after decoding. This selects modes like ``vaapi-copy`` (and so on).
|
2019-11-03 23:01:05 +00:00
|
|
|
If none of these work, hardware decoding is disabled. This mode is usually
|
|
|
|
guaranteed to incur no additional quality loss compared to software
|
|
|
|
decoding (assuming modern codecs and an error free video stream), and will
|
|
|
|
allow CPU processing with video filters. This mode works with all video
|
|
|
|
filters and VOs.
|
|
|
|
|
|
|
|
Because these copy the decoded video back to system RAM, they're often less
|
2019-12-29 22:28:34 +00:00
|
|
|
efficient than the direct modes, and may not help too much over software
|
2022-03-05 18:49:56 +00:00
|
|
|
decoding if you are short on CPU resources.
|
2019-11-03 23:01:05 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Most non-copy methods only work with the OpenGL GPU backend. Currently,
|
hwdec_vulkan: add Vulkan HW Interop
Vulkan Video Decoding has finally become a reality, as it's now
showing up in shipping drivers, and the ffmpeg support has been
merged.
With that in mind, this change introduces HW interop support for
ffmpeg Vulkan frames. The implementation is functionally complete - it
can display frames produced by hardware decoding, and it can work with
ffmpeg vulkan filters. There are still various caveats due to gaps and
bugs in drivers, so YMMV, as always.
Primary testing has been done on Intel, AMD, and nvidia hardware on
Linux with basic Windows testing on nvidia.
Notable caveats:
* Due to driver bugs, video decoding on nvidia does not work right now,
unless you use the Vulkan Beta driver. It can be worked around, but
requires ffmpeg changes that are not considered acceptable to merge.
* Even if those work-arounds are applied, Vulkan filters will not work
on video that was decoded by Vulkan, due to additional bugs in the
nvidia drivers. The filters do work correctly on content decoded some
other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload
with --vf=format=vulkan)
* Vulkan filters can only be used with drivers that support
VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet.
There is an MR outstanding for this.
* When dealing with 1080p content, there may be some visual distortion
in the bottom lines of frames due to chroma scaling incorporating the
extra hidden lines at the bottom of the frame (1080p content is
actually stored as 1088 lines), depending on the hardware/driver
combination and the scaling algorithm. This cannot be easily
addressed as the mechanical fix for it violates the Vulkan spec, and
probably requires a spec change to resolve properly.
All of these caveats will be fixed in either drivers or ffmpeg, and so
will not require mpv changes (unless something unexpected happens)
If you want to run on nvidia with the non-beta drivers, you can this
ffmpeg tree with the work-around patches:
* https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
2022-03-12 19:21:29 +00:00
|
|
|
only the ``vaapi``, ``nvdec``, ``cuda`` and ``vulkan`` methods work with
|
|
|
|
Vulkan.
|
2016-05-11 14:18:58 +00:00
|
|
|
|
2019-12-29 22:28:34 +00:00
|
|
|
The ``vaapi`` mode, if used with ``--vo=gpu``, requires Mesa 11, and most
|
2019-11-03 23:01:05 +00:00
|
|
|
likely works with Intel and AMD GPUs only. It also requires the opengl EGL
|
|
|
|
backend.
|
2015-09-29 19:14:56 +00:00
|
|
|
|
2019-12-29 22:28:34 +00:00
|
|
|
``nvdec`` and ``nvdec-copy`` are the newest, and recommended method to do
|
|
|
|
hardware decoding on Nvidia GPUs.
|
|
|
|
|
|
|
|
``cuda`` and ``cuda-copy`` are an older implementation of hardware decoding
|
|
|
|
on Nvidia GPUs that uses Nvidia's bitstream parsers rather than FFmpeg's.
|
|
|
|
This can lead to feature deficiencies, such as incorrect playback of HDR
|
|
|
|
content, and ``nvdec``/``nvdec-copy`` should always be preferred unless you
|
|
|
|
specifically need Nvidia's deinterlacing algorithms. To use this
|
|
|
|
deinterlacing you must pass the option:
|
2017-02-04 21:51:50 +00:00
|
|
|
``vd-lavc-o=deint=[weave|bob|adaptive]``.
|
|
|
|
Pass ``weave`` (or leave the option unset) to not attempt any
|
2019-12-29 22:28:34 +00:00
|
|
|
deinterlacing.
|
2017-10-28 17:59:08 +00:00
|
|
|
|
2016-05-23 20:55:30 +00:00
|
|
|
.. admonition:: Quality reduction with hardware decoding
|
|
|
|
|
2017-07-24 17:15:04 +00:00
|
|
|
In theory, hardware decoding does not reduce video quality (at least
|
|
|
|
for the codecs h264 and HEVC). However, due to restrictions in video
|
|
|
|
output APIs, as well as bugs in the actual hardware decoders, there can
|
2022-03-05 18:49:56 +00:00
|
|
|
be some loss, or even blatantly incorrect results. This has largely
|
|
|
|
ceased to be a problem with modern hardware, but there is a lot of
|
|
|
|
hardware out there, so caveat emptor. Known problems are discussed
|
|
|
|
below, but the list cannot be considered exhaustive, as even hwdecs that
|
|
|
|
work well on certain hardware generations may be problematic on other
|
|
|
|
ones.
|
2016-05-23 20:55:30 +00:00
|
|
|
|
|
|
|
In some cases, RGB conversion is forced, which means the RGB conversion
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
is performed by the hardware decoding API, instead of the shaders
|
|
|
|
used by ``--vo=gpu``. This means certain colorspaces may not display
|
2017-07-24 17:15:04 +00:00
|
|
|
correctly, and certain filtering (such as debanding) cannot be applied
|
|
|
|
in an ideal way. This will also usually force the use of low quality
|
|
|
|
chroma scalers instead of the one specified by ``--cscale``. In other
|
|
|
|
cases, hardware decoding can also reduce the bit depth of the decoded
|
|
|
|
image, which can introduce banding or precision loss for 10-bit files.
|
2016-05-23 20:55:30 +00:00
|
|
|
|
2019-12-29 22:28:34 +00:00
|
|
|
``vdpau`` always does RGB conversion in hardware, which does not
|
|
|
|
support newer colorspaces like BT.2020 correctly. However, ``vdpau``
|
|
|
|
doesn't support 10 bit or HDR encodings, so these limitations are
|
|
|
|
unlikely to be relevant.
|
2019-10-17 09:10:40 +00:00
|
|
|
|
2016-05-23 21:46:58 +00:00
|
|
|
``dxva2`` is not safe. It appears to always use BT.601 for forced RGB
|
|
|
|
conversion, but actual behavior depends on the GPU drivers. Some drivers
|
|
|
|
appear to convert to limited range RGB, which gives a faded appearance.
|
|
|
|
In addition to driver-specific behavior, global system settings might
|
|
|
|
affect this additionally. This can give incorrect results even with
|
|
|
|
completely ordinary video sources.
|
2016-05-23 20:55:30 +00:00
|
|
|
|
2016-09-30 09:35:25 +00:00
|
|
|
``rpi`` always uses the hardware overlay renderer, even with
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--vo=gpu``.
|
2016-09-30 09:35:25 +00:00
|
|
|
|
2021-10-18 14:50:39 +00:00
|
|
|
``mediacodec`` is not safe. It forces RGB conversion (not with ``-copy``)
|
|
|
|
and how well it handles non-standard colorspaces is not known.
|
|
|
|
In the rare cases where 10-bit is supported the bit depth of the output
|
|
|
|
will be reduced to 8.
|
|
|
|
|
2019-12-29 22:28:34 +00:00
|
|
|
``cuda`` should usually be safe, but depending on how a file/stream
|
|
|
|
has been mixed, it has been reported to corrupt the timestamps causing
|
|
|
|
glitched, flashing frames. It can also sometimes cause massive
|
|
|
|
framedrops for unknown reasons. Caution is advised, and ``nvdec``
|
|
|
|
should always be preferred.
|
2017-07-24 17:15:04 +00:00
|
|
|
|
2016-10-09 16:18:14 +00:00
|
|
|
``crystalhd`` is not safe. It always converts to 4:2:2 YUV, which
|
|
|
|
may be lossy, depending on how chroma sub-sampling is done during
|
|
|
|
conversion. It also discards the top left pixel of each frame for
|
|
|
|
some reason.
|
|
|
|
|
2022-03-05 18:49:56 +00:00
|
|
|
If you run into any weird decoding issues, frame glitches or
|
|
|
|
discoloration, and you have ``--hwdec`` turned on, the first thing you
|
|
|
|
should try is disabling it.
|
2016-05-23 20:55:30 +00:00
|
|
|
|
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=<auto|all|no|name>``
|
|
|
|
This option is for troubleshooting hwdec interop issues. Since it's a
|
|
|
|
debugging option, its semantics may change at any time.
|
|
|
|
|
2019-11-04 15:17:07 +00:00
|
|
|
This is useful for the ``gpu`` and ``libmpv`` VOs for selecting which
|
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
|
|
|
hwdec interop context to use exactly. Effectively it also can be used
|
|
|
|
to block loading of certain backends.
|
|
|
|
|
|
|
|
If set to ``auto`` (default), the behavior depends on the VO: for ``gpu``,
|
|
|
|
it does nothing, and the interop context is loaded on demand (when the
|
2019-11-04 15:17:07 +00:00
|
|
|
decoder probes for ``--hwdec`` support). For ``libmpv``, which has
|
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
|
|
|
has no on-demand loading, this is equivalent to ``all``.
|
|
|
|
|
|
|
|
The empty string is equivalent to ``auto``.
|
|
|
|
|
|
|
|
If set to ``all``, it attempts to load all interop contexts at GL context
|
|
|
|
creation time.
|
|
|
|
|
|
|
|
Other than that, a specific backend can be set, and the list of them can
|
|
|
|
be queried with ``help`` (mpv CLI only).
|
|
|
|
|
|
|
|
Runtime changes to this are ignored (the current option value is used
|
|
|
|
whenever the renderer is created).
|
|
|
|
|
|
|
|
The old aliases ``--opengl-hwdec-interop`` and ``--hwdec-preload`` are
|
|
|
|
barely related to this anymore, but will be somewhat compatible in some
|
|
|
|
cases.
|
2017-01-17 13:51:08 +00:00
|
|
|
|
2019-05-31 18:11:32 +00:00
|
|
|
``--hwdec-extra-frames=<N>``
|
|
|
|
Number of GPU frames hardware decoding should preallocate (default: see
|
|
|
|
``--list-options`` output). If this is too low, frame allocation may fail
|
|
|
|
during decoding, and video frames might get dropped and/or corrupted.
|
|
|
|
Setting it too high simply wastes GPU memory and has no advantages.
|
|
|
|
|
|
|
|
This value is used only for hardware decoding APIs which require
|
|
|
|
preallocating surfaces (known examples include ``d3d11va`` and ``vaapi``).
|
|
|
|
For other APIs, frames are allocated as needed. The details depend on the
|
|
|
|
libavcodec implementations of the hardware decoders.
|
|
|
|
|
|
|
|
The required number of surfaces depends on dynamic runtime situations. The
|
|
|
|
default is a fixed value that is thought to be sufficient for most uses. But
|
|
|
|
in certain situations, it may not be enough.
|
|
|
|
|
2017-10-16 12:37:28 +00:00
|
|
|
``--hwdec-image-format=<name>``
|
|
|
|
Set the internal pixel format used by hardware decoding via ``--hwdec``
|
|
|
|
(default ``no``). The special value ``no`` selects an implementation
|
|
|
|
specific standard format. Most decoder implementations support only one
|
|
|
|
format, and will fail to initialize if the format is not supported.
|
|
|
|
|
|
|
|
Some implementations might support multiple formats. In particular,
|
|
|
|
videotoolbox is known to require ``uyvy422`` for good performance on some
|
video: add mp_image_params.hw_flags and add an example
It seems this will be useful for Rokchip DRM hwcontext integration.
DRM hwcontexts have additional internal structure which can be different
depending on the decoder, and which is not part of the generic hwcontext
API. Rockchip has 1 layer, which EGL interop happens to translate to a
RGB texture, while VAAPI (mapped as DRM hwcontext) will use multiple
layers. Both will use sw_format=nv12, and thus are indistinguishable on
the mp_image_params level. But this is needed to initialize the EGL
mapping and the vo_gpu video renderer correctly.
We hope that the layer count is enough to tell whether EGL will
translate the data to a RGB texture (vs. 2 texture resembling raw nv12
data). For that we introduce MP_IMAGE_HW_FLAG_OPAQUE.
This commit adds the flag, infrastructure to set it, and an "example"
for D3D11.
The D3D11 addition is quite useless at this point. But later we want to
get rid of d3d11_update_image_attribs() anyway, while we still need a
way to force d3d11vpp filter insertion, so maybe it has some
justification (who knows). In any case it makes testing this easier.
Obviously it also adds some basic support for triggering the opaque
format for decoding, which will use a driver-specific format, but which
is not supported in shaders. The opaque flag is not used to determine
whether d3d11vpp needs to be inserted, though.
2017-10-16 12:44:59 +00:00
|
|
|
older hardware. d3d11va can always use ``yuv420p``, which uses an opaque
|
|
|
|
format, with likely no advantages.
|
2017-10-16 12:37:28 +00:00
|
|
|
|
2018-04-08 09:33:25 +00:00
|
|
|
``--cuda-decode-device=<auto|0..>``
|
vo_gpu: vulkan: hwdec_cuda: Add support for Vulkan interop
Despite their place in the tree, hwdecs can be loaded and used just
fine by the vulkan GPU backend.
In this change we add Vulkan interop support to the cuda/nvdec hwdec.
The overall process is mostly straight forward, so the main observation
here is that I had to implement it using an intermediate Vulkan buffer
because the direct VkImage usage is blocked by a bug in the nvidia
driver. When that gets fixed, I will revist this.
Nevertheless, the intermediate buffer copy is very cheap as it's all
device memory from start to finish. Overall CPU utilisiation is pretty
much the same as with the OpenGL GPU backend.
Note that we cannot use a single intermediate buffer - rather there
is a pool of them. This is done because the cuda memcpys are not
explicitly synchronised with the texture uploads.
In the basic case, this doesn't matter because the hwdec is not
asked to map and copy the next frame until after the previous one
is rendered. In the interpolation case, we need extra future frames
available immediately, so we'll be asked to map/copy those frames
and vulkan will be asked to render them. So far, harmless right? No.
All the vulkan rendering, including the upload steps, are batched
together and end up running very asynchronously from the CUDA copies.
The end result is that all the copies happen one after another, and
only then do the uploads happen, which means all textures are uploaded
the same, final, frame data. Whoops. Unsurprisingly this results in
the jerky motion because every 3/4 frames are identical.
The buffer pool ensures that we do not overwrite a buffer that is
still waiting to be uploaded. The ra_buf_pool implementation
automatically checks if existing buffers are available for use and
only creates a new one if it really has to. It's hard to say for sure
what the maximum number of buffers might be but we believe it won't
be so large as to make this strategy unusable. The highest I've seen
is 12 when using interpolation with tscale=bicubic.
A future optimisation here is to synchronise the CUDA copies with
respect to the vulkan uploads. This can be done with shared semaphores
that would ensure the copy of the second frames only happens after the
upload of the first frame, and so on. This isn't trivial to implement
as I'd have to first adjust the hwdec code to use asynchronous cuda;
without that, there's no way to use the semaphore for synchronisation.
This should result in fewer intermediate buffers being required.
2018-09-30 01:00:19 +00:00
|
|
|
Choose the GPU device used for decoding when using the ``cuda`` or
|
2019-12-28 20:58:39 +00:00
|
|
|
``nvdec`` hwdecs with the OpenGL GPU backend, and with the ``cuda-copy``
|
|
|
|
or ``nvdec-copy`` hwdecs in all cases.
|
2018-04-08 09:33:25 +00:00
|
|
|
|
2019-12-28 20:58:39 +00:00
|
|
|
For the OpenGL GPU backend, the default device used for decoding is the one
|
|
|
|
being used to provide ``gpu`` output (and in the vast majority of cases,
|
|
|
|
only one GPU will be present).
|
2018-04-08 09:33:25 +00:00
|
|
|
|
2019-12-28 20:58:39 +00:00
|
|
|
For the ``copy`` hwdecs, the default device will be the first device
|
|
|
|
enumerated by the CUDA libraries - however that is done.
|
vo_gpu: vulkan: hwdec_cuda: Add support for Vulkan interop
Despite their place in the tree, hwdecs can be loaded and used just
fine by the vulkan GPU backend.
In this change we add Vulkan interop support to the cuda/nvdec hwdec.
The overall process is mostly straight forward, so the main observation
here is that I had to implement it using an intermediate Vulkan buffer
because the direct VkImage usage is blocked by a bug in the nvidia
driver. When that gets fixed, I will revist this.
Nevertheless, the intermediate buffer copy is very cheap as it's all
device memory from start to finish. Overall CPU utilisiation is pretty
much the same as with the OpenGL GPU backend.
Note that we cannot use a single intermediate buffer - rather there
is a pool of them. This is done because the cuda memcpys are not
explicitly synchronised with the texture uploads.
In the basic case, this doesn't matter because the hwdec is not
asked to map and copy the next frame until after the previous one
is rendered. In the interpolation case, we need extra future frames
available immediately, so we'll be asked to map/copy those frames
and vulkan will be asked to render them. So far, harmless right? No.
All the vulkan rendering, including the upload steps, are batched
together and end up running very asynchronously from the CUDA copies.
The end result is that all the copies happen one after another, and
only then do the uploads happen, which means all textures are uploaded
the same, final, frame data. Whoops. Unsurprisingly this results in
the jerky motion because every 3/4 frames are identical.
The buffer pool ensures that we do not overwrite a buffer that is
still waiting to be uploaded. The ra_buf_pool implementation
automatically checks if existing buffers are available for use and
only creates a new one if it really has to. It's hard to say for sure
what the maximum number of buffers might be but we believe it won't
be so large as to make this strategy unusable. The highest I've seen
is 12 when using interpolation with tscale=bicubic.
A future optimisation here is to synchronise the CUDA copies with
respect to the vulkan uploads. This can be done with shared semaphores
that would ensure the copy of the second frames only happens after the
upload of the first frame, and so on. This isn't trivial to implement
as I'd have to first adjust the hwdec code to use asynchronous cuda;
without that, there's no way to use the semaphore for synchronisation.
This should result in fewer intermediate buffers being required.
2018-09-30 01:00:19 +00:00
|
|
|
|
2019-12-28 20:58:39 +00:00
|
|
|
For the Vulkan GPU backend, decoding must always happen on the display
|
|
|
|
device, and this option has no effect.
|
2018-04-08 09:33:25 +00:00
|
|
|
|
2018-04-08 09:42:16 +00:00
|
|
|
``--vaapi-device=<device file>``
|
|
|
|
Choose the DRM device for ``vaapi-copy``. This should be the path to a
|
|
|
|
DRM device file. (Default: ``/dev/dri/renderD128``)
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--panscan=<0.0-1.0>``
|
|
|
|
Enables pan-and-scan functionality (cropping the sides of e.g. a 16:9
|
|
|
|
video to make it fit a 4:3 display without black bands). The range
|
|
|
|
controls how much of the image is cropped. May not work with all video
|
|
|
|
output drivers.
|
2012-12-01 23:22:54 +00:00
|
|
|
|
2016-08-19 20:33:07 +00:00
|
|
|
This option has no effect if ``--video-unscaled`` option is used.
|
|
|
|
|
2019-10-04 16:45:37 +00:00
|
|
|
``--video-aspect-override=<ratio|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Override video aspect ratio, in case aspect information is incorrect or
|
2019-10-04 16:45:37 +00:00
|
|
|
missing in the file being played.
|
2012-12-01 23:22:54 +00:00
|
|
|
|
2016-08-31 16:10:11 +00:00
|
|
|
These values have special meaning:
|
2014-05-19 21:27:09 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:0: disable aspect ratio handling, pretend the video has square pixels
|
2016-08-31 16:10:11 +00:00
|
|
|
:no: same as ``0``
|
2014-07-31 14:32:37 +00:00
|
|
|
:-1: use the video stream or container aspect (default)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
But note that handling of these special values might change in the future.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
2013-05-25 13:03:30 +00:00
|
|
|
|
2019-10-04 16:45:37 +00:00
|
|
|
- ``--video-aspect-override=4:3`` or ``--video-aspect-override=1.3333``
|
|
|
|
- ``--video-aspect-override=16:9`` or ``--video-aspect-override=1.7777``
|
|
|
|
- ``--no-video-aspect-override`` or ``--video-aspect-override=no``
|
2014-06-22 00:50:52 +00:00
|
|
|
|
2017-07-21 18:19:39 +00:00
|
|
|
``--video-aspect-method=<bitstream|container>``
|
2015-08-30 21:01:46 +00:00
|
|
|
This sets the default video aspect determination method (if the aspect is
|
2019-10-04 16:45:37 +00:00
|
|
|
_not_ overridden by the user with ``--video-aspect-override`` or others).
|
2015-08-30 21:01:46 +00:00
|
|
|
|
|
|
|
:container: Strictly prefer the container aspect ratio. This is apparently
|
2017-06-29 20:34:57 +00:00
|
|
|
the default behavior with VLC, at least with Matroska. Note that
|
|
|
|
if the container has no aspect ratio set, the behavior is the
|
|
|
|
same as with bitstream.
|
2015-08-30 21:01:46 +00:00
|
|
|
:bitstream: Strictly prefer the bitstream aspect ratio, unless the bitstream
|
|
|
|
aspect ratio is not set. This is apparently the default behavior
|
2017-06-29 20:34:57 +00:00
|
|
|
with XBMC/kodi, at least with Matroska.
|
2015-08-30 21:01:46 +00:00
|
|
|
|
2017-06-29 20:34:57 +00:00
|
|
|
The current default for mpv is ``container``.
|
|
|
|
|
|
|
|
Normally you should not set this. Try the various choices if you encounter
|
|
|
|
video that has the wrong aspect ratio in mpv, but seems to be correct in
|
|
|
|
other players.
|
2015-08-30 21:01:46 +00:00
|
|
|
|
2016-08-19 08:24:26 +00:00
|
|
|
``--video-unscaled=<no|yes|downscale-big>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Disable scaling of the video. If the window is larger than the video,
|
2016-08-19 08:24:26 +00:00
|
|
|
black bars are added. Otherwise, the video is cropped, unless the option
|
|
|
|
is set to ``downscale-big``, in which case the video is fit to window. The
|
2016-08-19 20:33:07 +00:00
|
|
|
video still can be influenced by the other ``--video-...`` options. This
|
|
|
|
option disables the effect of ``--panscan``.
|
2014-06-22 00:50:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Note that the scaler algorithm may still be used, even if the video isn't
|
2016-04-10 15:26:32 +00:00
|
|
|
scaled. For example, this can influence chroma conversion. The video will
|
|
|
|
also still be scaled in one dimension if the source uses non-square pixels
|
|
|
|
(e.g. anamorphic widescreen DVDs).
|
2014-06-22 00:50:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option is disabled if the ``--no-keepaspect`` option is used.
|
2014-06-22 00:50:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--video-pan-x=<value>``, ``--video-pan-y=<value>``
|
|
|
|
Moves the displayed video rectangle by the given value in the X or Y
|
2023-08-31 19:16:03 +00:00
|
|
|
direction. The unit is in fractions of the size of the scaled video (the
|
|
|
|
full size, even if parts of the video are not visible due to panscan or
|
|
|
|
other options).
|
2014-06-22 00:50:52 +00:00
|
|
|
|
2023-08-20 23:48:31 +00:00
|
|
|
For example, displaying a video fullscreen on a 1920x1080 screen with
|
|
|
|
``--video-pan-x=-0.1`` would move the video 192 pixels to the left and
|
|
|
|
``--video-pan-y=-0.1`` would move the video 108 pixels up.
|
2014-06-22 00:50:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option is disabled if the ``--no-keepaspect`` option is used.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-01-02 13:31:46 +00:00
|
|
|
``--video-rotate=<0-359|no>``
|
2021-03-02 08:49:17 +00:00
|
|
|
Rotate the video clockwise, in degrees. If ``no`` is given, the video is
|
|
|
|
never rotated, even if the file has rotation metadata. (The rotation value
|
|
|
|
is added to the rotation metadata, which means the value ``0`` would rotate
|
|
|
|
the video according to the rotation metadata.)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2021-03-02 13:47:09 +00:00
|
|
|
When using hardware decoding without copy-back, only 90° steps work, while
|
|
|
|
software decoding and hardware decoding methods that copy the video back to
|
|
|
|
system memory support all values between 0 and 359.
|
|
|
|
|
2023-08-25 17:21:21 +00:00
|
|
|
``--video-crop=<[W[xH]][+x+y]>``, ``--video-crop=<x:y>``
|
|
|
|
Crop the video by starting at the x, y offset for w, h pixels. The crop is
|
|
|
|
applied to the source video rectangle (before anamorphic stretch) by the VO.
|
|
|
|
A crop rectangle that is not within the video rectangle will be ignored.
|
|
|
|
This works with hwdec, unlike the equivalent 'lavfi-crop'. Setting the crop
|
|
|
|
to '0x0' disables it.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--video-zoom=<value>``
|
2016-04-03 11:55:37 +00:00
|
|
|
Adjust the video display scale factor by the given value. The parameter is
|
|
|
|
given log 2. For example, ``--video-zoom=0`` is unscaled,
|
|
|
|
``--video-zoom=1`` is twice the size, ``--video-zoom=-2`` is one fourth of
|
|
|
|
the size, and so on.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option is disabled if the ``--no-keepaspect`` option is used.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2020-06-03 15:26:08 +00:00
|
|
|
``--video-scale-x=<value>``, ``--video-scale-y=<value>``
|
|
|
|
Multiply the video display size with the given value (default: 1.0). If a
|
|
|
|
non-default value is used, this will be different from the window size, so
|
|
|
|
video will be either cut off, or black bars are added.
|
|
|
|
|
|
|
|
This value is multiplied with the value derived from ``--video-zoom`` and
|
2022-02-03 10:47:09 +00:00
|
|
|
the normal video aspect ratio. This option is disabled if the
|
2020-06-03 15:26:08 +00:00
|
|
|
``--no-keepaspect`` option is used.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--video-align-x=<-1-1>``, ``--video-align-y=<-1-1>``
|
|
|
|
Moves the video rectangle within the black borders, which are usually added
|
|
|
|
to pad the video to screen if video and screen aspect ratios are different.
|
|
|
|
``--video-align-y=-1`` would move the video to the top of the screen
|
|
|
|
(leaving a border only on the bottom), a value of ``0`` centers it
|
|
|
|
(default), and a value of ``1`` would put the video at the bottom of the
|
|
|
|
screen.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If video and screen aspect match perfectly, these options do nothing.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option is disabled if the ``--no-keepaspect`` option is used.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2019-06-15 15:53:59 +00:00
|
|
|
``--video-margin-ratio-left=<val>``, ``--video-margin-ratio-right=<val>``, ``--video-margin-ratio-top=<val>``, ``--video-margin-ratio-bottom=<val>``
|
|
|
|
Set extra video margins on each border (default: 0). Each value is a ratio
|
|
|
|
of the window size, using a range 0.0-1.0. For example, setting the option
|
|
|
|
``--video-margin-ratio-right=0.2`` at a window size of 1000 pixels will add
|
|
|
|
a 200 pixels border on the right side of the window.
|
|
|
|
|
|
|
|
The video is "boxed" by these margins. The window size is not changed. In
|
|
|
|
particular it does not enlarge the window, and the margins will cause the
|
|
|
|
video to be downscaled by default. This may or may not change in the future.
|
|
|
|
|
|
|
|
The margins are applied after 90° video rotation, but before any other video
|
|
|
|
transformations.
|
|
|
|
|
|
|
|
This option is disabled if the ``--no-keepaspect`` option is used.
|
|
|
|
|
|
|
|
Subtitles still may use the margins, depending on ``--sub-use-margins`` and
|
|
|
|
similar options.
|
|
|
|
|
|
|
|
These options were created for the OSC. Some odd decisions, such as making
|
|
|
|
the margin values a ratio (instead of pixels), were made for the sake of
|
|
|
|
the OSC. It's possible that these options may be replaced by ones that are
|
|
|
|
more generally useful. The behavior of these options may change to fit
|
|
|
|
OSC requirements better, too.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--correct-pts``, ``--no-correct-pts``
|
|
|
|
``--no-correct-pts`` switches mpv to a mode where video timing is
|
|
|
|
determined using a fixed framerate value (either using the ``--fps``
|
|
|
|
option, or using file information). Sometimes, files with very broken
|
|
|
|
timestamps can be played somewhat well in this mode. Note that video
|
2018-05-08 16:44:08 +00:00
|
|
|
filters, subtitle rendering, seeking (including hr-seeks and backstepping),
|
|
|
|
and audio synchronization can be completely broken in this mode.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--fps=<float>``
|
|
|
|
Override video framerate. Useful if the original value is wrong or missing.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Works in ``--no-correct-pts`` mode only.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2017-08-22 17:08:07 +00:00
|
|
|
``--deinterlace=<yes|no>``
|
|
|
|
Enable or disable interlacing (default: no).
|
2014-07-31 14:32:37 +00:00
|
|
|
Interlaced video shows ugly comb-like artifacts, which are visible on
|
|
|
|
fast movement. Enabling this typically inserts the yadif video filter in
|
|
|
|
order to deinterlace the video, or lets the video output apply deinterlacing
|
|
|
|
if supported.
|
2013-08-14 01:25:50 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This behaves exactly like the ``deinterlace`` input property (usually
|
2015-11-23 23:16:19 +00:00
|
|
|
mapped to ``d``).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2017-08-22 17:08:07 +00:00
|
|
|
Keep in mind that this **will** conflict with manually inserted
|
|
|
|
deinterlacing filters, unless you take care. (Since mpv 0.27.0, even the
|
|
|
|
hardware deinterlace filters will conflict. Also since that version,
|
|
|
|
``--deinterlace=auto`` was removed, which used to mean that the default
|
|
|
|
interlacing option of possibly inserted video filters was used.)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2018-02-12 17:23:22 +00:00
|
|
|
Note that this will make video look worse if it's not actually interlaced.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--frames=<number>``
|
|
|
|
Play/convert only first ``<number>`` video frames, then quit.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--frames=0`` loads the file, but immediately quits before initializing
|
|
|
|
playback. (Might be useful for scripts which just want to determine some
|
|
|
|
file properties.)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
For audio-only playback, any value greater than 0 will quit playback
|
|
|
|
immediately after initialization. The value 0 works as with video.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-09-29 19:12:26 +00:00
|
|
|
``--video-output-levels=<outputlevels>``
|
|
|
|
RGB color levels used with YUV to RGB conversion. Normally, output devices
|
|
|
|
such as PC monitors use full range color levels. However, some TVs and
|
|
|
|
video monitors expect studio RGB levels. Providing full range output to a
|
|
|
|
device expecting studio level input results in crushed blacks and whites,
|
|
|
|
the reverse in dim gray blacks and dim whites.
|
|
|
|
|
|
|
|
Not all VOs support this option. Some will silently ignore it.
|
|
|
|
|
|
|
|
Available color ranges are:
|
|
|
|
|
|
|
|
:auto: automatic selection (equals to full range) (default)
|
|
|
|
:limited: limited range (16-235 per component), studio levels
|
|
|
|
:full: full range (0-255 per component), PC levels
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
It is advisable to use your graphics driver's color range option
|
|
|
|
instead, if available.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--hwdec-codecs=<codec1,codec2,...|all>``
|
|
|
|
Allow hardware decoding for a given list of codecs only. The special value
|
|
|
|
``all`` always allows all codecs.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
You can get the list of allowed codecs with ``mpv --vd=help``. Remove the
|
|
|
|
prefix, e.g. instead of ``lavc:h264`` use ``h264``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2020-12-30 14:58:48 +00:00
|
|
|
By default, this is set to ``h264,vc1,hevc,vp8,vp9,av1``. Note that
|
2016-07-30 13:47:51 +00:00
|
|
|
the hardware acceleration special codecs like ``h264_vdpau`` are not
|
|
|
|
relevant anymore, and in fact have been removed from Libav in this form.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This is usually only needed with broken GPUs, where a codec is reported
|
|
|
|
as supported, but decoding causes more problems than it solves.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``mpv --hwdec=vdpau --vo=vdpau --hwdec-codecs=h264,mpeg2video``
|
|
|
|
Enable vdpau decoding for h264 and mpeg2 only.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--vd-lavc-check-hw-profile=<yes|no>``
|
|
|
|
Check hardware decoder profile (default: yes). If ``no`` is set, the
|
|
|
|
highest profile of the hardware decoder is unconditionally selected, and
|
|
|
|
decoding is forced even if the profile of the video is higher than that.
|
|
|
|
The result is most likely broken decoding, but may also help if the
|
|
|
|
detected or reported profiles are somehow incorrect.
|
2014-03-26 13:03:24 +00:00
|
|
|
|
2015-11-03 13:03:02 +00:00
|
|
|
``--vd-lavc-software-fallback=<yes|no|N>``
|
2015-10-25 09:45:44 +00:00
|
|
|
Fallback to software decoding if the hardware-accelerated decoder fails
|
2015-11-03 13:03:02 +00:00
|
|
|
(default: 3). If this is a number, then fallback will be triggered if
|
|
|
|
N frames fail to decode in a row. 1 is equivalent to ``yes``.
|
2015-10-25 09:45:44 +00:00
|
|
|
|
2019-11-02 22:00:49 +00:00
|
|
|
Setting this to a higher number might break the playback start fallback: if
|
|
|
|
a fallback happens, parts of the file will be skipped, approximately by to
|
|
|
|
the number of packets that could not be decoded. Values below an unspecified
|
|
|
|
count will not have this problem, because mpv retains the packets.
|
|
|
|
|
2022-04-03 12:17:43 +00:00
|
|
|
``--vd-lavc-film-grain=<auto|cpu|gpu>``
|
|
|
|
Enables film grain application on the GPU. If video decoding is done on
|
|
|
|
the CPU, doing film grain application on the GPU can speed up decoding.
|
|
|
|
This option can also help hardware decoding, as it can reduce the number
|
|
|
|
of frame copies done.
|
|
|
|
|
|
|
|
By default, it's set to ``auto``, so if the VO supports film grain
|
|
|
|
application, then it will be treated as ``gpu``. If the VO does not
|
|
|
|
support this, then it will be treated as ``cpu``, regardless of the setting.
|
|
|
|
Currently, only ``gpu-next`` supports film grain application.
|
|
|
|
|
2023-01-21 14:45:11 +00:00
|
|
|
``--vd-lavc-dr=<auto|yes|no>``
|
|
|
|
Enable direct rendering (default: auto). If this is set to ``yes``, the
|
2017-07-23 07:41:51 +00:00
|
|
|
video will be decoded directly to GPU video memory (or staging buffers).
|
|
|
|
This can speed up video upload, and may help with large resolutions or
|
|
|
|
slow hardware. This works only with the following VOs:
|
|
|
|
|
2018-04-28 13:41:39 +00:00
|
|
|
- ``gpu``: requires at least OpenGL 4.4 or Vulkan.
|
2021-11-29 11:39:20 +00:00
|
|
|
- ``libmpv``: The libmpv render API has optional support.
|
2017-07-23 07:41:51 +00:00
|
|
|
|
2023-01-21 14:45:11 +00:00
|
|
|
The ``auto`` option will try to guess whether DR can improve performance
|
|
|
|
on your particular hardware. Currently this enables it on AMD or NVIDIA
|
|
|
|
if using OpenGL or unconditionally if using Vulkan.
|
|
|
|
|
2017-07-23 07:41:51 +00:00
|
|
|
Using video filters of any kind that write to the image data (or output
|
|
|
|
newly allocated frames) will silently disable the DR code path.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--vd-lavc-bitexact``
|
|
|
|
Only use bit-exact algorithms in all decoding steps (for codec testing).
|
|
|
|
|
2022-08-31 09:29:39 +00:00
|
|
|
``--vd-lavc-fast`` (MPEG-1/2 and H.264 only)
|
2014-07-31 14:32:37 +00:00
|
|
|
Enable optimizations which do not comply with the format specification and
|
|
|
|
potentially cause problems, like simpler dequantization, simpler motion
|
|
|
|
compensation, assuming use of the default quantization matrix, assuming YUV
|
|
|
|
4:2:0 and skipping a few checks to detect damaged bitstreams.
|
2014-02-25 20:04:04 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--vd-lavc-o=<key>=<value>[,<key>=<value>[,...]]``
|
|
|
|
Pass AVOptions to libavcodec decoder. Note, a patch to make the ``o=``
|
|
|
|
unneeded and pass all unknown options through the AVOption system is
|
|
|
|
welcome. A full list of AVOptions can be found in the FFmpeg manual.
|
2014-02-25 20:04:04 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Some options which used to be direct options can be set with this
|
|
|
|
mechanism, like ``bug``, ``gray``, ``idct``, ``ec``, ``vismv``,
|
|
|
|
``skip_top`` (was ``st``), ``skip_bottom`` (was ``sb``), ``debug``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-11-18 00:27:23 +00:00
|
|
|
``--vd-lavc-o=debug=pict``
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--vd-lavc-show-all=<yes|no>``
|
|
|
|
Show even broken/corrupt frames (default: no). If this option is set to
|
|
|
|
no, libavcodec won't output frames that were either decoded before an
|
|
|
|
initial keyframe was decoded, or frames that are recognized as corrupted.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2022-08-31 09:29:39 +00:00
|
|
|
``--vd-lavc-skiploopfilter=<skipvalue>`` (H.264, HEVC only)
|
|
|
|
Skips the loop filter (AKA deblocking) during decoding. Since
|
2014-07-31 14:32:37 +00:00
|
|
|
the filtered frame is supposed to be used as reference for decoding
|
|
|
|
dependent frames, this has a worse effect on quality than not doing
|
|
|
|
deblocking on e.g. MPEG-2 video. But at least for high bitrate HDTV,
|
|
|
|
this provides a big speedup with little visible quality loss.
|
2022-08-31 09:29:39 +00:00
|
|
|
Codecs other than H.264 or HEVC may have partial support for this option
|
|
|
|
(often only ``all`` and ``none``).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``<skipvalue>`` can be one of the following:
|
2013-09-08 00:46:19 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:none: Never skip.
|
|
|
|
:default: Skip useless processing steps (e.g. 0 size packets in AVI).
|
|
|
|
:nonref: Skip frames that are not referenced (i.e. not used for
|
|
|
|
decoding other frames, the error cannot "build up").
|
|
|
|
:bidir: Skip B-Frames.
|
|
|
|
:nonkey: Skip all frames except keyframes.
|
|
|
|
:all: Skip all frames.
|
core: add --deinterlace option, restore it with resume functionality
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
2013-09-13 16:06:08 +00:00
|
|
|
|
2022-08-31 09:29:39 +00:00
|
|
|
``--vd-lavc-skipidct=<skipvalue>`` (MPEG-1/2/4 only)
|
2014-07-31 14:32:37 +00:00
|
|
|
Skips the IDCT step. This degrades quality a lot in almost all cases
|
|
|
|
(see skiploopfilter for available skip values).
|
core: add --deinterlace option, restore it with resume functionality
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
2013-09-13 16:06:08 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--vd-lavc-skipframe=<skipvalue>``
|
|
|
|
Skips decoding of frames completely. Big speedup, but jerky motion and
|
|
|
|
sometimes bad artifacts (see skiploopfilter for available skip values).
|
core: add --deinterlace option, restore it with resume functionality
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
2013-09-13 16:06:08 +00:00
|
|
|
|
2014-08-08 22:35:25 +00:00
|
|
|
``--vd-lavc-framedrop=<skipvalue>``
|
|
|
|
Set framedropping mode used with ``--framedrop`` (see skiploopfilter for
|
|
|
|
available skip values).
|
|
|
|
|
2015-07-23 15:17:26 +00:00
|
|
|
``--vd-lavc-threads=<N>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Number of threads to use for decoding. Whether threading is actually
|
2015-07-23 15:17:26 +00:00
|
|
|
supported depends on codec (default: 0). 0 means autodetect number of cores
|
|
|
|
on the machine and use that, up to the maximum of 16. You can set more than
|
|
|
|
16 threads manually.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2017-12-26 04:53:44 +00:00
|
|
|
``--vd-lavc-assume-old-x264=<yes|no>``
|
|
|
|
Assume the video was encoded by an old, buggy x264 version (default: no).
|
|
|
|
Normally, this is autodetected by libavcodec. But if the bitstream contains
|
|
|
|
no x264 version info (or it was somehow skipped), and the stream was in fact
|
|
|
|
encoded by an old x264 version (build 150 or earlier), and if the stream
|
2022-08-31 09:29:39 +00:00
|
|
|
uses 4:4:4 chroma, then libavcodec will by default show corrupted video.
|
2017-12-26 04:53:44 +00:00
|
|
|
This option sets the libavcodec ``x264_build`` option to ``150``, which
|
|
|
|
means that if the stream contains no version info, or was not encoded by
|
|
|
|
x264 at all, it assumes it was encoded by the old version. Enabling this
|
|
|
|
option is pretty safe if you want your broken files to work, but in theory
|
|
|
|
this can break on streams not encoded by x264, or if a stream encoded by a
|
|
|
|
newer x264 version contains no version info.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2019-09-28 08:26:23 +00:00
|
|
|
``--swapchain-depth=<N>``
|
|
|
|
Allow up to N in-flight frames. This essentially controls the frame
|
|
|
|
latency. Increasing the swapchain depth can improve pipelining and prevent
|
|
|
|
missed vsyncs, but increases visible latency. This option only mandates an
|
|
|
|
upper limit, the implementation can use a lower latency than requested
|
|
|
|
internally. A setting of 1 means that the VO will wait for every frame to
|
|
|
|
become visible before starting to render the next frame. (Default: 3)
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Audio
|
|
|
|
-----
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-10-09 20:07:40 +00:00
|
|
|
``--audio-pitch-correction=<yes|no>``
|
2015-02-12 10:58:35 +00:00
|
|
|
If this is enabled (default), playing with a speed different from normal
|
2021-01-20 18:07:08 +00:00
|
|
|
automatically inserts the ``scaletempo2`` audio filter. For details, see
|
2014-10-09 20:07:40 +00:00
|
|
|
audio filter section.
|
2014-10-02 00:58:52 +00:00
|
|
|
|
2014-10-09 19:21:31 +00:00
|
|
|
``--audio-device=<name>``
|
|
|
|
Use the given audio device. This consists of the audio output name, e.g.
|
|
|
|
``alsa``, followed by ``/``, followed by the audio output specific device
|
2016-09-05 19:07:30 +00:00
|
|
|
name. The default value for this option is ``auto``, which tries every audio
|
|
|
|
output in preference order with the default device.
|
2014-10-09 19:21:31 +00:00
|
|
|
|
2014-10-19 14:36:38 +00:00
|
|
|
You can list audio devices with ``--audio-device=help``. This outputs the
|
|
|
|
device name in quotes, followed by a description. The device name is what
|
2016-09-05 19:07:30 +00:00
|
|
|
you have to pass to the ``--audio-device`` option. The list of audio devices
|
|
|
|
can be retrieved by API by using the ``audio-device-list`` property.
|
2014-10-09 19:21:31 +00:00
|
|
|
|
2016-09-05 19:07:30 +00:00
|
|
|
While the option normally takes one of the strings as indicated by the
|
|
|
|
methods above, you can also force the device for most AOs by building it
|
|
|
|
manually. For example ``name/foobar`` forces the AO ``name`` to use the
|
2018-03-14 05:49:22 +00:00
|
|
|
device ``foobar``. However, the ``--ao`` option will strictly force a
|
|
|
|
specific AO. To avoid confusion, don't use ``--ao`` and ``--audio-device``
|
|
|
|
together.
|
2014-10-09 19:21:31 +00:00
|
|
|
|
2016-09-07 10:55:21 +00:00
|
|
|
.. admonition:: Example for ALSA
|
|
|
|
|
|
|
|
MPlayer and mplayer2 required you to replace any ',' with '.' and
|
|
|
|
any ':' with '=' in the ALSA device name. For example, to use the
|
|
|
|
device named ``dmix:default``, you had to do:
|
|
|
|
|
|
|
|
``-ao alsa:device=dmix=default``
|
|
|
|
|
|
|
|
In mpv you could instead use:
|
|
|
|
|
|
|
|
``--audio-device=alsa/dmix:default``
|
|
|
|
|
|
|
|
|
2016-09-05 19:07:34 +00:00
|
|
|
``--audio-exclusive=<yes|no>``
|
|
|
|
Enable exclusive output mode. In this mode, the system is usually locked
|
|
|
|
out, and only mpv will be able to output audio.
|
|
|
|
|
2023-02-01 03:03:25 +00:00
|
|
|
This only works for some audio outputs, such as ``wasapi``, ``coreaudio``
|
|
|
|
and ``pipewire``. Other audio outputs silently ignore this option.
|
|
|
|
They either have no concept of exclusive mode, or the mpv side of the
|
|
|
|
implementation is missing.
|
2016-09-05 19:07:34 +00:00
|
|
|
|
2015-10-05 16:53:02 +00:00
|
|
|
``--audio-fallback-to-null=<yes|no>``
|
|
|
|
If no audio device can be opened, behave as if ``--ao=null`` was given. This
|
|
|
|
is useful in combination with ``--audio-device``: instead of causing an
|
|
|
|
error if the selected device does not exist, the client API user (or a
|
|
|
|
Lua script) could let playback continue normally, and check the
|
|
|
|
``current-ao`` and ``audio-device-list`` properties to make high-level
|
|
|
|
decisions about how to continue.
|
|
|
|
|
2016-09-07 10:55:21 +00:00
|
|
|
``--ao=<driver>``
|
|
|
|
Specify the audio output drivers to be used. See `AUDIO OUTPUT DRIVERS`_ for
|
|
|
|
details and descriptions of available drivers.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--af=<filter1[=parameter1:parameter2:...],filter2,...>``
|
|
|
|
Specify a list of audio filters to apply to the audio stream. See
|
|
|
|
`AUDIO FILTERS`_ for details and descriptions of the available filters.
|
|
|
|
The option variants ``--af-add``, ``--af-pre``, ``--af-del`` and
|
|
|
|
``--af-clr`` exist to modify a previously specified list, but you
|
|
|
|
should not need these for typical use.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2015-06-05 20:35:43 +00:00
|
|
|
``--audio-spdif=<codecs>``
|
|
|
|
List of codecs for which compressed audio passthrough should be used. This
|
|
|
|
works for both classic S/PDIF and HDMI.
|
|
|
|
|
2017-11-19 06:19:04 +00:00
|
|
|
Possible codecs are ``ac3``, ``dts``, ``dts-hd``, ``eac3``, ``truehd``.
|
|
|
|
Multiple codecs can be specified by separating them with ``,``. ``dts``
|
|
|
|
refers to low bitrate DTS core, while ``dts-hd`` refers to DTS MA (receiver
|
|
|
|
and OS support varies). If both ``dts`` and ``dts-hd`` are specified, it
|
|
|
|
behaves equivalent to specifying ``dts-hd`` only.
|
2015-06-05 20:35:43 +00:00
|
|
|
|
2017-06-29 14:24:17 +00:00
|
|
|
In earlier mpv versions you could use ``--ad`` to force the spdif wrapper.
|
|
|
|
This does not work anymore.
|
2015-06-05 20:35:43 +00:00
|
|
|
|
|
|
|
.. admonition:: Warning
|
|
|
|
|
|
|
|
There is not much reason to use this. HDMI supports uncompressed
|
|
|
|
multichannel PCM, and mpv supports lossless DTS-HD decoding via
|
2016-02-01 19:05:25 +00:00
|
|
|
FFmpeg's new DCA decoder (based on libdcadec).
|
2015-06-05 20:35:43 +00:00
|
|
|
|
2017-01-19 14:38:58 +00:00
|
|
|
``--ad=<decoder1,decoder2,...[-]>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Specify a priority list of audio decoders to be used, according to their
|
2016-12-23 17:12:29 +00:00
|
|
|
decoder name. When determining which decoder to use, the first decoder that
|
|
|
|
matches the audio format is selected. If that is unavailable, the next
|
|
|
|
decoder is used. Finally, it tries all other decoders that are not
|
2014-07-31 14:32:37 +00:00
|
|
|
explicitly selected or rejected by the option.
|
2013-07-14 21:44:50 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``-`` at the end of the list suppresses fallback on other available
|
|
|
|
decoders not on the ``--ad`` list. ``+`` in front of an entry forces the
|
|
|
|
decoder. Both of these should not normally be used, because they break
|
2016-12-23 17:18:17 +00:00
|
|
|
normal decoder auto-selection! Both of these methods are deprecated.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-12-23 17:12:29 +00:00
|
|
|
``--ad=mp3float``
|
2014-09-01 02:25:57 +00:00
|
|
|
Prefer the FFmpeg/Libav ``mp3float`` decoder over all other MP3
|
2014-07-31 14:32:37 +00:00
|
|
|
decoders.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ad=help``
|
|
|
|
List all available decoders.
|
2013-08-04 21:25:54 +00:00
|
|
|
|
2015-06-05 20:35:43 +00:00
|
|
|
.. admonition:: Warning
|
|
|
|
|
|
|
|
Enabling compressed audio passthrough (AC3 and DTS via SPDIF/HDMI) with
|
2017-01-19 14:38:58 +00:00
|
|
|
this option is not possible. Use ``--audio-spdif`` instead.
|
2015-06-05 20:35:43 +00:00
|
|
|
|
2015-05-22 16:35:03 +00:00
|
|
|
``--volume=<value>``
|
|
|
|
Set the startup volume. 0 means silence, 100 means no volume reduction or
|
2016-07-09 16:31:18 +00:00
|
|
|
amplification. Negative values can be passed for compatibility, but are
|
|
|
|
treated as 0.
|
2015-05-22 16:35:03 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
Since mpv 0.18.1, this always controls the internal mixer (aka "softvol").
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2017-04-26 22:21:17 +00:00
|
|
|
``--replaygain=<no|track|album>``
|
2018-12-18 20:28:53 +00:00
|
|
|
Adjust volume gain according to replaygain values stored in the file
|
|
|
|
metadata. With ``--replaygain=no`` (the default), perform no adjustment.
|
|
|
|
With ``--replaygain=track``, apply track gain. With ``--replaygain=album``,
|
|
|
|
apply album gain if present and fall back to track gain otherwise.
|
2017-04-26 19:45:50 +00:00
|
|
|
|
|
|
|
``--replaygain-preamp=<db>``
|
|
|
|
Pre-amplification gain in dB to apply to the selected replaygain gain
|
|
|
|
(default: 0).
|
|
|
|
|
|
|
|
``--replaygain-clip=<yes|no>``
|
|
|
|
Prevent clipping caused by replaygain by automatically lowering the
|
|
|
|
gain (default). Use ``--replaygain-clip=no`` to disable this.
|
|
|
|
|
|
|
|
``--replaygain-fallback=<db>``
|
|
|
|
Gain in dB to apply if the file has no replay gain tags. This option
|
|
|
|
is always applied if the replaygain logic is somehow inactive. If this
|
|
|
|
is applied, no other replaygain options are applied.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--audio-delay=<sec>``
|
|
|
|
Audio delay in seconds (positive or negative float value). Positive values
|
|
|
|
delay the audio, and negative values delay the video.
|
2013-06-28 13:26:30 +00:00
|
|
|
|
2016-09-18 09:58:24 +00:00
|
|
|
``--mute=<yes|no|auto>``
|
|
|
|
Set startup audio mute status (default: no).
|
|
|
|
|
|
|
|
``auto`` is a deprecated possible value that is equivalent to ``no``.
|
2015-12-19 08:26:27 +00:00
|
|
|
|
|
|
|
See also: ``--volume``.
|
2013-06-28 13:26:30 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
``--softvol=<no|yes|auto>``
|
|
|
|
Deprecated/unfunctional. Before mpv 0.18.1, this used to control whether
|
|
|
|
to use the volume controls of the audio output driver or the internal mpv
|
|
|
|
volume filter.
|
2013-06-28 13:26:30 +00:00
|
|
|
|
2016-11-19 00:17:12 +00:00
|
|
|
The current behavior is that softvol is always enabled, i.e. as if this
|
|
|
|
option is set to ``yes``. The other behaviors are not available anymore,
|
|
|
|
although ``auto`` almost matches current behavior in most cases.
|
2013-06-28 13:26:30 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
The ``no`` behavior is still partially available through the ``ao-volume``
|
|
|
|
and ``ao-mute`` properties. But there are no options to reset these.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--audio-demuxer=<[+]name>``
|
|
|
|
Use this audio demuxer type when using ``--audio-file``. Use a '+' before
|
|
|
|
the name to force it; this will skip some checks. Give the demuxer name as
|
|
|
|
printed by ``--audio-demuxer=help``.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ad-lavc-ac3drc=<level>``
|
|
|
|
Select the Dynamic Range Compression level for AC-3 audio streams.
|
|
|
|
``<level>`` is a float value ranging from 0 to 1, where 0 means no
|
2015-03-30 17:44:52 +00:00
|
|
|
compression (which is the default) and 1 means full compression (make loud
|
|
|
|
passages more silent and vice versa). Values up to 6 are also accepted, but
|
2014-07-31 14:32:37 +00:00
|
|
|
are purely experimental. This option only shows an effect if the AC-3 stream
|
|
|
|
contains the required range compression information.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2015-03-30 17:44:52 +00:00
|
|
|
The standard mandates that DRC is enabled by default, but mpv (and some
|
|
|
|
other players) ignore this for the sake of better audio quality.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ad-lavc-downmix=<yes|no>``
|
2020-02-29 21:08:38 +00:00
|
|
|
Whether to request audio channel downmixing from the decoder (default: no).
|
2014-07-31 14:32:37 +00:00
|
|
|
Some decoders, like AC-3, AAC and DTS, can remix audio on decoding. The
|
|
|
|
requested number of output channels is set with the ``--audio-channels`` option.
|
|
|
|
Useful for playing surround audio on a stereo system.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ad-lavc-threads=<0-16>``
|
|
|
|
Number of threads to use for decoding. Whether threading is actually
|
|
|
|
supported depends on codec. As of this writing, it's supported for some
|
|
|
|
lossless codecs only. 0 means autodetect number of cores on the
|
|
|
|
machine and use that, up to the maximum of 16 (default: 1).
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ad-lavc-o=<key>=<value>[,<key>=<value>[,...]]``
|
|
|
|
Pass AVOptions to libavcodec decoder. Note, a patch to make the o=
|
|
|
|
unneeded and pass all unknown options through the AVOption system is
|
|
|
|
welcome. A full list of AVOptions can be found in the FFmpeg manual.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ad-spdif-dtshd=<yes|no>``, ``--dtshd``, ``--no-dtshd``
|
2015-06-05 20:35:43 +00:00
|
|
|
If DTS is passed through, use DTS-HD.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2015-06-05 20:35:43 +00:00
|
|
|
.. admonition:: Warning
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2015-06-05 20:35:43 +00:00
|
|
|
This and enabling passthrough via ``--ad`` are deprecated in favor of
|
|
|
|
using ``--audio-spdif=dts-hd``.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
2016-08-04 18:49:20 +00:00
|
|
|
``--audio-channels=<auto-safe|auto|layouts>``
|
|
|
|
Control which audio channels are output (e.g. surround vs. stereo). There
|
|
|
|
are the following possibilities:
|
|
|
|
|
|
|
|
- ``--audio-channels=auto-safe``
|
|
|
|
Use the system's preferred channel layout. If there is none (such
|
|
|
|
as when accessing a hardware device instead of the system mixer),
|
|
|
|
force stereo. Some audio outputs might simply accept any layout and
|
|
|
|
do downmixing on their own.
|
|
|
|
|
|
|
|
This is the default.
|
|
|
|
- ``--audio-channels=auto``
|
|
|
|
Send the audio device whatever it accepts, preferring the audio's
|
|
|
|
original channel layout. Can cause issues with HDMI (see the warning
|
|
|
|
below).
|
|
|
|
- ``--audio-channels=layout1,layout2,...``
|
|
|
|
List of ``,``-separated channel layouts which should be allowed.
|
|
|
|
Technically, this only adjusts the filter chain output to the best
|
|
|
|
matching layout in the list, and passes the result to the audio API.
|
|
|
|
It's possible that the audio API will select a different channel
|
|
|
|
layout.
|
|
|
|
|
|
|
|
Using this mode is recommended for direct hardware output, especially
|
|
|
|
over HDMI (see HDMI warning below).
|
2022-09-06 02:20:07 +00:00
|
|
|
- ``--audio-channels=<stereo|mono>``
|
|
|
|
Force a downmix to stereo or mono. These are special-cases of the
|
|
|
|
previous item. (See paragraphs below for implications.)
|
2016-08-04 18:49:20 +00:00
|
|
|
|
|
|
|
If a list of layouts is given, each item can be either an explicit channel
|
|
|
|
layout name (like ``5.1``), or a channel number. Channel numbers refer to
|
|
|
|
default layouts, e.g. 2 channels refer to stereo, 6 refers to 5.1.
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
See ``--audio-channels=help`` output for defined default layouts. This also
|
|
|
|
lists speaker names, which can be used to express arbitrary channel
|
|
|
|
layouts (e.g. ``fl-fr-lfe`` is 2.1).
|
2013-06-28 13:13:43 +00:00
|
|
|
|
2016-08-04 18:49:20 +00:00
|
|
|
If the list of channel layouts has only 1 item, the decoder is asked to
|
|
|
|
produce according output. This sometimes triggers decoder-downmix, which
|
|
|
|
might be different from the normal mpv downmix. (Only some decoders support
|
|
|
|
remixing audio, like AC-3, AAC or DTS. You can use ``--ad-lavc-downmix=no``
|
|
|
|
to make the decoder always output its native layout.) One consequence is
|
|
|
|
that ``--audio-channels=stereo`` triggers decoder downmix, while ``auto``
|
|
|
|
or ``auto-safe`` never will, even if they end up selecting stereo. This
|
|
|
|
happens because the decision whether to use decoder downmix happens long
|
|
|
|
before the audio device is opened.
|
2014-07-16 20:40:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If the channel layout of the media file (i.e. the decoder) and the AO's
|
|
|
|
channel layout don't match, mpv will attempt to insert a conversion filter.
|
2017-11-19 06:19:04 +00:00
|
|
|
You may need to change the channel layout of the system mixer to achieve
|
|
|
|
your desired output as mpv does not have control over it. Another
|
|
|
|
work-around for this on some AOs is to use ``--audio-exclusive=yes`` to
|
|
|
|
circumvent the system mixer entirely.
|
2014-07-16 20:40:21 +00:00
|
|
|
|
2015-07-25 20:44:06 +00:00
|
|
|
.. admonition:: Warning
|
|
|
|
|
|
|
|
Using ``auto`` can cause issues when using audio over HDMI. The OS will
|
|
|
|
typically report all channel layouts that _can_ go over HDMI, even if
|
|
|
|
the receiver does not support them. If a receiver gets an unsupported
|
|
|
|
channel layout, random things can happen, such as dropping the
|
|
|
|
additional channels, or adding noise.
|
|
|
|
|
2016-08-04 18:49:20 +00:00
|
|
|
You are recommended to set an explicit whitelist of the layouts you
|
|
|
|
want. For example, most A/V receivers connected via HDMI and that can
|
|
|
|
do 7.1 would be served by: ``--audio-channels=7.1,5.1,stereo``
|
|
|
|
|
2021-07-28 15:00:38 +00:00
|
|
|
``--audio-display=<no|embedded-first|external-first>``
|
|
|
|
Determines whether to display cover art when playing audio files and with
|
|
|
|
what priority. It will display the first image found, and additional images
|
|
|
|
are available as video tracks.
|
|
|
|
|
|
|
|
:no: Disable display of video entirely when playing audio
|
|
|
|
files.
|
|
|
|
:embedded-first: Display embedded images and external cover art, giving
|
|
|
|
priority to embedded images (default).
|
|
|
|
:external-first: Display embedded images and external cover art, giving
|
|
|
|
priority to external files.
|
2014-07-16 20:40:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option has no influence on files with normal video tracks.
|
2014-04-17 19:47:00 +00:00
|
|
|
|
2017-07-02 14:26:41 +00:00
|
|
|
``--audio-files=<files>``
|
|
|
|
Play audio from an external file while viewing a video.
|
2014-04-17 19:47:00 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a path list option. See `List Options`_ for details.
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
|
2017-07-02 14:26:41 +00:00
|
|
|
``--audio-file=<file>``
|
|
|
|
CLI/config file only alias for ``--audio-files-append``. Each use of this
|
|
|
|
option will add a new audio track. The details are similar to how
|
|
|
|
``--sub-file`` works.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--audio-format=<format>``
|
|
|
|
Select the sample format used for output from the audio filter layer to
|
|
|
|
the sound card. The values that ``<format>`` can adopt are listed below in
|
|
|
|
the description of the ``format`` audio filter.
|
2014-06-10 19:44:50 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--audio-samplerate=<Hz>``
|
|
|
|
Select the output sample rate to be used (of course sound cards have
|
|
|
|
limits on this). If the sample frequency selected is different from that
|
|
|
|
of the current media, the lavrresample audio filter will be inserted into
|
|
|
|
the audio filter layer to compensate for the difference.
|
2014-06-10 19:44:50 +00:00
|
|
|
|
2014-10-26 11:02:00 +00:00
|
|
|
``--gapless-audio=<no|yes|weak>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Try to play consecutive audio files with no silence or disruption at the
|
|
|
|
point of file change. Default: ``weak``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:no: Disable gapless audio.
|
2015-12-19 08:26:27 +00:00
|
|
|
:yes: The audio device is opened using parameters chosen for the first
|
|
|
|
file played and is then kept open for gapless playback. This
|
2014-07-31 14:32:37 +00:00
|
|
|
means that if the first file for example has a low sample rate, then
|
|
|
|
the following files may get resampled to the same low sample rate,
|
|
|
|
resulting in reduced sound quality. If you play files with different
|
|
|
|
parameters, consider using options such as ``--audio-samplerate``
|
|
|
|
and ``--audio-format`` to explicitly select what the shared output
|
|
|
|
format will be.
|
|
|
|
:weak: Normally, the audio device is kept open (using the format it was
|
|
|
|
first initialized with). If the audio format the decoder output
|
|
|
|
changes, the audio device is closed and reopened. This means that
|
|
|
|
you will normally get gapless audio with files that were encoded
|
|
|
|
using the same settings, but might not be gapless in other cases.
|
2018-04-12 16:47:25 +00:00
|
|
|
The exact conditions under which the audio device is kept open is
|
|
|
|
an implementation detail, and can change from version to version.
|
|
|
|
Currently, the device is kept even if the sample format changes,
|
|
|
|
but the sample formats are convertible.
|
2019-10-06 18:28:55 +00:00
|
|
|
If video is still going on when there is still audio, trying to use
|
|
|
|
gapless is also explicitly given up.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2013-09-10 13:09:24 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This feature is implemented in a simple manner and relies on audio
|
|
|
|
output device buffering to continue playback while moving from one file
|
|
|
|
to another. If playback of the new file starts slowly, for example
|
|
|
|
because it is played from a remote network location or because you have
|
|
|
|
specified cache settings that require time for the initial cache fill,
|
|
|
|
then the buffered audio may run out before playback of the new file
|
|
|
|
can start.
|
2013-09-10 13:09:24 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--initial-audio-sync``, ``--no-initial-audio-sync``
|
|
|
|
When starting a video file or after events such as seeking, mpv will by
|
|
|
|
default modify the audio stream to make it start from the same timestamp
|
|
|
|
as video, by either inserting silence at the start or cutting away the
|
|
|
|
first samples. Disabling this option makes the player behave like older
|
|
|
|
mpv versions did: video and audio are both started immediately even if
|
|
|
|
their start timestamps differ, and then video timing is gradually adjusted
|
|
|
|
if necessary to reach correct synchronization later.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
``--volume-max=<100.0-1000.0>``, ``--softvol-max=<...>``
|
2015-05-22 16:44:59 +00:00
|
|
|
Set the maximum amplification level in percent (default: 130). A value of
|
|
|
|
130 will allow you to adjust the volume up to about double the normal level.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-07-09 16:31:18 +00:00
|
|
|
``--softvol-max`` is a deprecated alias and should not be used.
|
|
|
|
|
2015-02-02 20:23:12 +00:00
|
|
|
``--audio-file-auto=<no|exact|fuzzy|all>``, ``--no-audio-file-auto``
|
|
|
|
Load additional audio files matching the video filename. The parameter
|
2017-09-10 05:05:33 +00:00
|
|
|
specifies how external audio files are matched.
|
2015-02-02 20:23:12 +00:00
|
|
|
|
2017-09-10 05:05:33 +00:00
|
|
|
:no: Don't automatically load external audio files (default).
|
|
|
|
:exact: Load the media filename with audio file extension.
|
2021-06-21 15:07:19 +00:00
|
|
|
:fuzzy: Load all audio files containing the media filename.
|
2017-08-16 19:20:46 +00:00
|
|
|
:all: Load all audio files in the current and ``--audio-file-paths``
|
2015-12-25 12:17:11 +00:00
|
|
|
directories.
|
|
|
|
|
player: make all autoload extensions configurable
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes #12000.
2023-08-10 22:36:22 +00:00
|
|
|
``--audio-file-auto-exts=ext1,ext2,...``
|
|
|
|
Audio file extentions to try and match when using ``audio-file-auto``.
|
|
|
|
|
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2015-12-25 12:17:11 +00:00
|
|
|
``--audio-file-paths=<path1:path2:...>``
|
2017-07-02 14:26:41 +00:00
|
|
|
Equivalent to ``--sub-file-paths`` option, but for auto-loaded audio files.
|
2015-02-02 20:23:12 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a path list option. See `List Options`_ for details.
|
|
|
|
|
2014-11-07 14:54:35 +00:00
|
|
|
``--audio-client-name=<name>``
|
|
|
|
The application name the player reports to the audio API. Can be useful
|
|
|
|
if you want to force a different audio profile (e.g. with PulseAudio),
|
|
|
|
or to set your own application name when using libmpv.
|
|
|
|
|
2014-09-04 21:48:27 +00:00
|
|
|
``--audio-buffer=<seconds>``
|
|
|
|
Set the audio output minimum buffer. The audio device might actually create
|
|
|
|
a larger buffer if it pleases. If the device creates a smaller buffer,
|
|
|
|
additional audio is buffered in an additional software buffer.
|
|
|
|
|
|
|
|
Making this larger will make soft-volume and other filters react slower,
|
|
|
|
introduce additional issues on playback speed change, and block the
|
|
|
|
player on audio format changes. A smaller buffer might lead to audio
|
|
|
|
dropouts.
|
|
|
|
|
|
|
|
This option should be used for testing only. If a non-default value helps
|
|
|
|
significantly, the mpv developers should be contacted.
|
|
|
|
|
|
|
|
Default: 0.2 (200 ms).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-08-09 14:22:06 +00:00
|
|
|
``--audio-stream-silence=<yes|no>``
|
|
|
|
Cash-grab consumer audio hardware (such as A/V receivers) often ignore
|
|
|
|
initial audio sent over HDMI. This can happen every time audio over HDMI
|
|
|
|
is stopped and resumed. In order to compensate for this, you can enable
|
|
|
|
this option to not to stop and restart audio on seeks, and fill the gaps
|
|
|
|
with silence. Likewise, when pausing playback, audio is not stopped, and
|
|
|
|
silence is played while paused. Note that if no audio track is selected,
|
|
|
|
the audio device will still be closed immediately.
|
|
|
|
|
|
|
|
Not all AOs support this.
|
|
|
|
|
audio: fix stream-silence with push AOs (somewhat)
--audio-stream-silence is a shitty feature compensating for awful
consumer garbage, that mutes PCM at first to check whether it's
compressed audio, using formats advocated and owned by malicious patent
troll companies (who spend more money on their lawyers than paying any
technicians), wrapped in a wasteful way to make it constant bitrate
using a standard whose text is not freely available, and only rude users
want it. This feature has been carelessly broken, because it's
complicated and stupid. What would Jesus do? If not getting an aneurysm,
or pushing over tables with expensive A/V receivers on top of them, he'd
probably fix the feature. So let's take inspiration from Jesus Christ
himself, and do something as dumb as wasting some of our limited
lifetime on this incredibly stupid fucking shit.
This is tricky, because state changes like end-of-audio are supposed to
be driven by the AO driver, while playing silence precludes this. But it
seems code paths for "untimed" AOs can be reused.
But there are still problems. For example, underruns will just happen
normally (and stop audio streaming), because we don't have a separate
heuristic to check whether the buffer is "low enough" (as a consequence
of a network stall, but before the audio output itself underruns).
2020-09-03 20:39:23 +00:00
|
|
|
.. admonition:: Warning
|
|
|
|
|
|
|
|
This modifies certain subtle player behavior, like A/V-sync and underrun
|
|
|
|
handling. Enabling this option is strongly discouraged.
|
|
|
|
|
2016-08-09 14:26:44 +00:00
|
|
|
``--audio-wait-open=<secs>``
|
|
|
|
This makes sense for use with ``--audio-stream-silence=yes``. If this option
|
|
|
|
is given, the player will wait for the given amount of seconds after opening
|
|
|
|
the audio device before sending actual audio data to it. Useful if your
|
|
|
|
expensive hardware discards the first 1 or 2 seconds of audio data sent to
|
|
|
|
it. If ``--audio-stream-silence=yes`` is not set, this option will likely
|
|
|
|
just waste time.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Subtitles
|
|
|
|
---------
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-01-12 22:56:04 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
Changing styling and position does not work with all subtitles. Image-based
|
2016-07-09 13:48:27 +00:00
|
|
|
subtitles (DVD, Bluray/PGS, DVB) cannot changed for fundamental reasons.
|
2016-01-12 22:56:04 +00:00
|
|
|
Subtitles in ASS format are normally not changed intentionally, but
|
2017-06-06 20:16:29 +00:00
|
|
|
overriding them can be controlled with ``--sub-ass-override``.
|
2016-10-02 15:08:14 +00:00
|
|
|
|
|
|
|
Previously some options working on text subtitles were called
|
|
|
|
``--sub-text-*``, they are now named ``--sub-*``, and those specifically
|
|
|
|
for ASS have been renamed from ``--ass-*`` to ``--sub-ass-*``.
|
|
|
|
They are now all in this section.
|
2016-01-12 22:56:04 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-demuxer=<[+]name>``
|
|
|
|
Force subtitle demuxer type for ``--sub-file``. Give the demuxer name as
|
|
|
|
printed by ``--sub-demuxer=help``.
|
2012-12-28 16:17:16 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-delay=<sec>``
|
|
|
|
Delays subtitles by ``<sec>`` seconds. Can be negative.
|
2013-10-01 23:15:59 +00:00
|
|
|
|
2017-12-07 09:51:22 +00:00
|
|
|
``--sub-files=<file-list>``, ``--sub-file=<filename>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Add a subtitle file to the list of external subtitles.
|
2013-10-01 23:15:59 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If you use ``--sub-file`` only once, this subtitle file is displayed by
|
|
|
|
default.
|
2013-10-01 23:15:59 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If ``--sub-file`` is used multiple times, the subtitle to use can be
|
|
|
|
switched at runtime by cycling subtitle tracks. It's possible to show
|
|
|
|
two subtitles at once: use ``--sid`` to select the first subtitle index,
|
|
|
|
and ``--secondary-sid`` to select the second index. (The index is printed
|
|
|
|
on the terminal output after the ``--sid=`` in the list of streams.)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
``--sub-files`` is a path list option (see `List Options`_ for details), and
|
2017-12-07 09:51:22 +00:00
|
|
|
can take multiple file names separated by ``:`` (Unix) or ``;`` (Windows),
|
|
|
|
while ``--sub-file`` takes a single filename, but can be used multiple
|
|
|
|
times to add multiple files. Technically, ``--sub-file`` is a CLI/config
|
|
|
|
file only alias for ``--sub-files-append``.
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--secondary-sid=<ID|auto|no>``
|
|
|
|
Select a secondary subtitle stream. This is similar to ``--sid``. If a
|
|
|
|
secondary subtitle is selected, it will be rendered as toptitle (i.e. on
|
|
|
|
the top of the screen) alongside the normal subtitle, and provides a way
|
|
|
|
to render two subtitles at once.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-06-17 17:37:25 +00:00
|
|
|
There are some caveats associated with this feature. For example, bitmap
|
2014-07-31 14:32:37 +00:00
|
|
|
subtitles will always be rendered in their usual position, so selecting a
|
|
|
|
bitmap subtitle as secondary subtitle will result in overlapping subtitles.
|
|
|
|
Secondary subtitles are never shown on the terminal if video is disabled.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. note::
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Styling and interpretation of any formatting tags is disabled for the
|
|
|
|
secondary subtitle. Internally, the same mechanism as ``--no-sub-ass``
|
|
|
|
is used to strip the styling.
|
2012-09-17 06:38:19 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If the main subtitle stream contains formatting tags which display the
|
|
|
|
subtitle at the top of the screen, it will overlap with the secondary
|
|
|
|
subtitle. To prevent this, you could use ``--no-sub-ass`` to disable
|
|
|
|
styling in the main subtitle stream.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-scale=<0-100>``
|
|
|
|
Factor for the text subtitle font size (default: 1).
|
2014-08-03 18:25:03 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2014-08-03 18:25:03 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This affects ASS subtitles as well, and may lead to incorrect subtitle
|
2016-10-02 15:08:14 +00:00
|
|
|
rendering. Use with care, or use ``--sub-font-size`` instead.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
2015-01-05 18:18:08 +00:00
|
|
|
``--sub-scale-by-window=<yes|no>``
|
|
|
|
Whether to scale subtitles with the window size (default: yes). If this is
|
|
|
|
disabled, changing the window size won't change the subtitle font size.
|
|
|
|
|
|
|
|
Like ``--sub-scale``, this can break ASS subtitles.
|
|
|
|
|
2014-10-26 11:02:00 +00:00
|
|
|
``--sub-scale-with-window=<yes|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Make the subtitle font size relative to the window, instead of the video.
|
|
|
|
This is useful if you always want the same font size, even if the video
|
2016-11-06 00:38:19 +00:00
|
|
|
doesn't cover the window fully, e.g. because screen aspect and window
|
2014-07-31 14:32:37 +00:00
|
|
|
aspect mismatch (and the player adds black bars).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-02-16 19:04:15 +00:00
|
|
|
Default: yes.
|
|
|
|
|
2015-01-05 18:18:08 +00:00
|
|
|
This option is misnamed. The difference to the confusingly similar sounding
|
|
|
|
option ``--sub-scale-by-window`` is that ``--sub-scale-with-window`` still
|
|
|
|
scales with the approximate window size, while the other option disables
|
|
|
|
this scaling.
|
|
|
|
|
2017-06-06 20:16:29 +00:00
|
|
|
Affects plain text subtitles only (or ASS if ``--sub-ass-override`` is set
|
|
|
|
high enough).
|
2015-02-16 19:04:15 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-scale-with-window=<yes|no>``
|
2015-02-16 19:04:15 +00:00
|
|
|
Like ``--sub-scale-with-window``, but affects subtitles in ASS format only.
|
2014-07-31 14:32:37 +00:00
|
|
|
Like ``--sub-scale``, this can break ASS subtitles.
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2015-02-16 19:04:15 +00:00
|
|
|
Default: no.
|
|
|
|
|
2019-09-25 20:11:39 +00:00
|
|
|
``--embeddedfonts=<yes|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Use fonts embedded in Matroska container files and ASS scripts (default:
|
2019-09-25 20:11:39 +00:00
|
|
|
yes). These fonts can be used for SSA/ASS subtitle rendering.
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2020-08-12 15:30:30 +00:00
|
|
|
``--sub-pos=<0-150>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Specify the position of subtitles on the screen. The value is the vertical
|
2020-08-12 15:30:30 +00:00
|
|
|
position of the subtitle in % of the screen height. 100 is the original
|
|
|
|
position, which is often not the absolute bottom of the screen, but with
|
|
|
|
some margin between the bottom and the subtitle. Values above 100 move the
|
|
|
|
subtitle further down.
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2020-08-12 15:30:30 +00:00
|
|
|
.. admonition:: Warning
|
|
|
|
|
|
|
|
Text subtitles (as opposed to image subtitles) may be cut off if the
|
|
|
|
value of the option is above 100. This is a libass restriction.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This affects ASS subtitles as well, and may lead to incorrect subtitle
|
2020-08-12 15:30:30 +00:00
|
|
|
rendering in addition to the problem above.
|
|
|
|
|
|
|
|
Using ``--sub-margin-y`` can achieve this in a better way.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-speed=<0.1-10.0>``
|
|
|
|
Multiply the subtitle event timestamps with the given value. Can be used
|
2015-12-06 00:15:08 +00:00
|
|
|
to fix the playback speed for frame-based subtitle formats. Affects text
|
|
|
|
subtitles only.
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2017-07-11 22:55:04 +00:00
|
|
|
``--sub-speed=25/23.976`` plays frame based subtitles which have been
|
2014-07-31 14:32:37 +00:00
|
|
|
loaded assuming a framerate of 23.976 at 25 FPS.
|
2013-05-10 22:22:23 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-force-style=<[Style.]Param=Value[,...]>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Override some style or script info parameters.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
2014-06-08 21:54:05 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
- ``--sub-ass-force-style=FontName=Arial,Default.Bold=1``
|
|
|
|
- ``--sub-ass-force-style=PlayResY=768``
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. note::
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Using this option may lead to incorrect subtitle rendering.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-hinting=<none|light|normal|native>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Set font hinting type. <type> can be:
|
2013-01-23 09:56:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:none: no hinting (default)
|
|
|
|
:light: FreeType autohinter, light mode
|
|
|
|
:normal: FreeType autohinter, normal mode
|
|
|
|
:native: font native hinter
|
2013-02-24 22:35:13 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Warning
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Enabling hinting can lead to mispositioned text (in situations it's
|
2016-02-05 22:19:56 +00:00
|
|
|
supposed to match up video background), or reduce the smoothness
|
2014-07-31 14:32:37 +00:00
|
|
|
of animations with some badly authored ASS scripts. It is recommended
|
|
|
|
to not use this option, unless really needed.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-line-spacing=<value>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Set line spacing value for SSA/ASS renderer.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-shaper=<simple|complex>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Set the text layout engine used by libass.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:simple: uses Fribidi only, fast, doesn't render some languages correctly
|
|
|
|
:complex: uses HarfBuzz, slower, wider language support
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``complex`` is the default. If libass hasn't been compiled against HarfBuzz,
|
|
|
|
libass silently reverts to ``simple``.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-styles=<filename>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Load all SSA/ASS styles found in the specified file and use them for
|
|
|
|
rendering text subtitles. The syntax of the file is exactly like the ``[V4
|
|
|
|
Styles]`` / ``[V4+ Styles]`` section of SSA/ASS.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Using this option may lead to incorrect subtitle rendering.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2017-06-06 20:16:29 +00:00
|
|
|
``--sub-ass-override=<yes|no|force|scale|strip>``
|
|
|
|
Control whether user style overrides should be applied. Note that all of
|
|
|
|
these overrides try to be somewhat smart about figuring out whether or not
|
|
|
|
a subtitle is considered a "sign".
|
|
|
|
|
|
|
|
:no: Render subtitles as specified by the subtitle scripts, without
|
|
|
|
overrides.
|
|
|
|
:yes: Apply all the ``--sub-ass-*`` style override options. Changing the
|
|
|
|
default for any of these options can lead to incorrect subtitle
|
|
|
|
rendering (default).
|
|
|
|
:force: Like ``yes``, but also force all ``--sub-*`` options. Can break
|
|
|
|
rendering easily.
|
|
|
|
:scale: Like ``yes``, but also apply ``--sub-scale``.
|
2016-04-30 12:25:23 +00:00
|
|
|
:strip: Radically strip all ASS tags and styles from the subtitle. This
|
|
|
|
is equivalent to the old ``--no-ass`` / ``--no-sub-ass`` options.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2019-05-22 21:15:34 +00:00
|
|
|
This also controls some bitmap subtitle overrides, as well as HTML tags in
|
|
|
|
formats like SRT, despite the name of the option.
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-force-margins``
|
2015-02-16 19:04:15 +00:00
|
|
|
Enables placing toptitles and subtitles in black borders when they are
|
|
|
|
available, if the subtitles are in the ASS format.
|
|
|
|
|
|
|
|
Default: no.
|
|
|
|
|
|
|
|
``--sub-use-margins``
|
2014-07-31 14:32:37 +00:00
|
|
|
Enables placing toptitles and subtitles in black borders when they are
|
2015-02-16 19:04:15 +00:00
|
|
|
available, if the subtitles are in a plain text format (or ASS if
|
2017-06-06 20:16:29 +00:00
|
|
|
``--sub-ass-override`` is set high enough).
|
2015-02-16 19:04:15 +00:00
|
|
|
|
|
|
|
Default: yes.
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
Renamed from ``--sub-ass-use-margins``. To place ASS subtitles in the borders
|
|
|
|
too (like the old option did), also add ``--sub-ass-force-margins``.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-vsfilter-aspect-compat=<yes|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Stretch SSA/ASS subtitles when playing anamorphic videos for compatibility
|
|
|
|
with traditional VSFilter behavior. This switch has no effect when the
|
|
|
|
video is stored with square pixels.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
The renderer historically most commonly used for the SSA/ASS subtitle
|
|
|
|
formats, VSFilter, had questionable behavior that resulted in subtitles
|
|
|
|
being stretched too if the video was stored in anamorphic format that
|
|
|
|
required scaling for display. This behavior is usually undesirable and
|
|
|
|
newer VSFilter versions may behave differently. However, many existing
|
|
|
|
scripts compensate for the stretching by modifying things in the opposite
|
|
|
|
direction. Thus, if such scripts are displayed "correctly", they will not
|
|
|
|
appear as intended. This switch enables emulation of the old VSFilter
|
|
|
|
behavior (undesirable but expected by many existing scripts).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Enabled by default.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-vsfilter-blur-compat=<yes|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Scale ``\blur`` tags by video resolution instead of script resolution
|
2020-10-04 01:09:21 +00:00
|
|
|
(enabled by default). This is bug in VSFilter, which according to some,
|
2014-07-31 14:32:37 +00:00
|
|
|
can't be fixed anymore in the name of compatibility.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Note that this uses the actual video resolution for calculating the
|
|
|
|
offset scale factor, not what the video filter chain or the video output
|
|
|
|
use.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-ass-vsfilter-color-compat=<basic|full|force-601|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Mangle colors like (xy-)vsfilter do (default: basic). Historically, VSFilter
|
2014-09-01 02:25:57 +00:00
|
|
|
was not color space aware. This was no problem as long as the color space
|
2014-07-31 14:32:37 +00:00
|
|
|
used for SD video (BT.601) was used. But when everything switched to HD
|
|
|
|
(BT.709), VSFilter was still converting RGB colors to BT.601, rendered
|
|
|
|
them into the video frame, and handled the frame to the video output, which
|
|
|
|
would use BT.709 for conversion to RGB. The result were mangled subtitle
|
|
|
|
colors. Later on, bad hacks were added on top of the ASS format to control
|
|
|
|
how colors are to be mangled.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:basic: Handle only BT.601->BT.709 mangling, if the subtitles seem to
|
|
|
|
indicate that this is required (default).
|
2014-09-01 02:25:57 +00:00
|
|
|
:full: Handle the full ``YCbCr Matrix`` header with all video color spaces
|
2014-07-31 14:32:37 +00:00
|
|
|
supported by libass and mpv. This might lead to bad breakages in
|
|
|
|
corner cases and is not strictly needed for compatibility
|
|
|
|
(hopefully), which is why this is not default.
|
|
|
|
:force-601: Force BT.601->BT.709 mangling, regardless of subtitle headers
|
2014-09-01 02:25:57 +00:00
|
|
|
or video color space.
|
2014-07-31 14:32:37 +00:00
|
|
|
:no: Disable color mangling completely. All colors are RGB.
|
2013-10-25 18:33:46 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Choosing anything other than ``no`` will make the subtitle color depend on
|
2014-09-01 02:25:57 +00:00
|
|
|
the video color space, and it's for example in theory not possible to reuse
|
2017-06-06 20:16:29 +00:00
|
|
|
a subtitle script with another video file. The ``--sub-ass-override``
|
2014-07-31 14:32:37 +00:00
|
|
|
option doesn't affect how this option is interpreted.
|
2013-04-04 12:24:42 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--stretch-dvd-subs=<yes|no>``
|
|
|
|
Stretch DVD subtitles when playing anamorphic videos for better looking
|
|
|
|
fonts on badly mastered DVDs. This switch has no effect when the
|
|
|
|
video is stored with square pixels - which for DVD input cannot be the case
|
|
|
|
though.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Many studios tend to use bitmap fonts designed for square pixels when
|
|
|
|
authoring DVDs, causing the fonts to look stretched on playback on DVD
|
|
|
|
players. This option fixes them, however at the price of possibly
|
2014-09-01 02:25:57 +00:00
|
|
|
misaligning some subtitles (e.g. sign translations).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Disabled by default.
|
|
|
|
|
2015-07-18 12:36:17 +00:00
|
|
|
``--stretch-image-subs-to-screen=<yes|no>``
|
|
|
|
Stretch DVD and other image subtitles to the screen, ignoring the video
|
|
|
|
margins. This has a similar effect as ``--sub-use-margins`` for text
|
|
|
|
subtitles, except that the text itself will be stretched, not only just
|
|
|
|
repositioned. (At least in general it is unavoidable, as an image bitmap
|
|
|
|
can in theory consist of a single bitmap covering the whole screen, and
|
|
|
|
the player won't know where exactly the text parts are located.)
|
|
|
|
|
|
|
|
This option does not display subtitles correctly. Use with care.
|
|
|
|
|
|
|
|
Disabled by default.
|
|
|
|
|
2017-01-23 14:55:09 +00:00
|
|
|
``--image-subs-video-resolution=<yes|no>``
|
|
|
|
Override the image subtitle resolution with the video resolution
|
|
|
|
(default: no). Normally, the subtitle canvas is fit into the video canvas
|
|
|
|
(e.g. letterboxed). Setting this option uses the video size as subtitle
|
|
|
|
canvas size. Can be useful to test broken subtitles, which often happen
|
|
|
|
when the video was trancoded, while attempting to keep the old subtitles.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-ass``, ``--no-sub-ass``
|
|
|
|
Render ASS subtitles natively (enabled by default).
|
|
|
|
|
2016-04-30 12:25:23 +00:00
|
|
|
.. note::
|
|
|
|
|
2017-06-06 20:16:29 +00:00
|
|
|
This has been deprecated by ``--sub-ass-override=strip``. You also
|
2016-04-30 12:25:23 +00:00
|
|
|
may need ``--embeddedfonts=no`` to get the same behavior. Also,
|
2017-06-06 20:16:29 +00:00
|
|
|
using ``--sub-ass-override=style`` should give better results
|
2016-04-30 12:25:23 +00:00
|
|
|
without breaking subtitles too much.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If ``--no-sub-ass`` is specified, all tags and style declarations are
|
|
|
|
stripped and ignored on display. The subtitle renderer uses the font style
|
2016-10-02 15:08:14 +00:00
|
|
|
as specified by the ``--sub-`` options instead.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Using ``--no-sub-ass`` may lead to incorrect or completely broken
|
|
|
|
rendering of ASS/SSA subtitles. It can sometimes be useful to forcibly
|
|
|
|
override the styling of ASS subtitles, but should be avoided in general.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-auto=<no|exact|fuzzy|all>``, ``--no-sub-auto``
|
|
|
|
Load additional subtitle files matching the video filename. The parameter
|
|
|
|
specifies how external subtitle files are matched. ``exact`` is enabled by
|
|
|
|
default.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:no: Don't automatically load external subtitle files.
|
2020-05-09 21:31:33 +00:00
|
|
|
:exact: Load the media filename with subtitle file extension and possibly
|
|
|
|
language suffixes (default).
|
2021-06-21 15:07:19 +00:00
|
|
|
:fuzzy: Load all subs containing the media filename.
|
2017-08-16 19:20:46 +00:00
|
|
|
:all: Load all subs in the current and ``--sub-file-paths`` directories.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
player: make all autoload extensions configurable
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes #12000.
2023-08-10 22:36:22 +00:00
|
|
|
``--sub-auto-exts=ext1,ext2,...``
|
|
|
|
Subtitle extentions to try and match when using ``--sub-auto``. Note that
|
|
|
|
modifying this list will also affect what mpv recognizes as subtitles when
|
|
|
|
using drag and drop.
|
|
|
|
|
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-codepage=<codepage>``
|
2016-12-09 18:51:29 +00:00
|
|
|
You can use this option to specify the subtitle codepage. uchardet will be
|
|
|
|
used to guess the charset. (If mpv was not compiled with uchardet, then
|
|
|
|
``utf-8`` is the effective default.)
|
2013-09-08 10:02:30 +00:00
|
|
|
|
2016-12-09 18:51:29 +00:00
|
|
|
The default value for this option is ``auto``, which enables autodetection.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-12-09 18:51:29 +00:00
|
|
|
The following steps are taken to determine the final codepage, in order:
|
2012-12-11 17:16:42 +00:00
|
|
|
|
2016-12-09 18:51:29 +00:00
|
|
|
- if the specific codepage has a ``+``, use that codepage
|
|
|
|
- if the data looks like UTF-8, assume it is UTF-8
|
|
|
|
- if ``--sub-codepage`` is set to a specific codepage, use that
|
|
|
|
- run uchardet, and if successful, use that
|
|
|
|
- otherwise, use ``UTF-8-BROKEN``
|
2013-09-22 20:47:50 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
2013-12-05 20:23:15 +00:00
|
|
|
|
2016-12-09 18:51:29 +00:00
|
|
|
- ``--sub-codepage=latin2`` Use Latin 2 if input is not UTF-8.
|
|
|
|
- ``--sub-codepage=+cp1250`` Always force recoding to cp1250.
|
2015-08-01 21:51:51 +00:00
|
|
|
|
2016-12-09 18:51:29 +00:00
|
|
|
The pseudo codepage ``UTF-8-BROKEN`` is used internally. If it's set,
|
|
|
|
subtitles are interpreted as UTF-8 with "Latin 1" as fallback for bytes
|
|
|
|
which are not valid UTF-8 sequences. iconv is never involved in this mode.
|
2015-08-01 21:51:51 +00:00
|
|
|
|
2017-01-19 14:44:49 +00:00
|
|
|
This option changed in mpv 0.23.0. Support for the old syntax was fully
|
|
|
|
removed in mpv 0.24.0.
|
|
|
|
|
2020-02-01 17:52:30 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
This works for text subtitle files only. Other types of subtitles (in
|
|
|
|
particular subtitles in mkv files) are always assumed to be UTF-8.
|
|
|
|
|
2015-08-01 21:51:51 +00:00
|
|
|
|
2017-06-06 16:58:20 +00:00
|
|
|
``--sub-fix-timing=<yes|no>``
|
|
|
|
Adjust subtitle timing is to remove minor gaps or overlaps between
|
|
|
|
subtitles (if the difference is smaller than 210 ms, the gap or overlap
|
|
|
|
is removed).
|
2013-05-03 19:00:05 +00:00
|
|
|
|
2023-08-29 01:15:49 +00:00
|
|
|
``--sub-forced-events-only=<yes|no>``
|
player: remove auto choice from sub-forced-only
First of all, this never worked. Or if it ever did, it was in some
select few scenarios. c9474dc9ed6172a5f17f66f4b7d367da6b077909 is what
originally added support for the auto choice. However, that commit
worked by propagating a value to a fake option used internally. This
shouldn't have ever worked because the underlying m_config_cache was
never updated so the value shouldn't have been preserved when accessed
in sd_lavc. And indeed with some testing, the value there is always 0
unsurprisingly.
This was later rewritten in ba7cc071068f4f57ae354e77f64552712fda6855
along with a lot of other sub changes, but with that, it was still
mostly broken. The reason is because one of the key parts of having to
hit this logic (prefer_forced) required `--no-subs-with-matching-audio`
to be set. If the audio language matches the subtitle language (the
requirement also excludes forced subs), the option makes no subtitle
selection in the first place so pick->forced_only_def is not set to true
and nothing even happens. Another way around this would be to attempt to
change your OS language (like with the LANG environment variable) so
that the subtitle track gets selected but then audio_matches mistakenly
becomes false because it compares the OS language to the audio language
which then make preferred_forced 0, so nothing happens. I don't think
there's a scenario where pick->forced_only_def is actually set to true
(thus meaning `auto` is useless), but maybe someone could contrive
something very strange. Regardless, it's definitely not something even
remotely common.
fbe8f9919428a7ed24a61899bfd85bbb7680e389 changed track selection again
but didn't consider this particular case. The net result is that DVD/PGS
subs become equivalent to --sub-forced-only being yes, so this a change
in behavior and probably not a good one. Note that I wasn't able to
actually observe any difference in a PGS sample. It still displayed
subtitles fine but that sample probably didn't have the right flags to
hit the sub-forced-only logic.
Anyways, the auto feature is extremely questionable at best and in my
view, not actually worth it. It is meant to be used with
`--no-subs-with-matching-audio` to display forced pictures in subtitle
tracks that are not marked as forced, but that contradicts that
particular option's purpose and description in the manual (secretly
selecting a track under certain conditions even though it says not to).
Instead of trying to shove all this logic into select_default_track
which is already insanely complicated as it is, recognize that this is a
trivial lua script. If you absolutely want to turn --sub-forced-only on
under these certain conditions (DVD/PGS subtitles, matching audio and
subtitle languages, etc.), just look at the current-tracks property and
do your thing. The very, very niche behavior that this option tried to
accomplish basically never worked, no user even knows what this option
does, and well it's just not worth supporting in core mpv code. Drop
all this code for sanity's sake and change --sub-forced-only back to a
bool.
2023-08-28 22:24:24 +00:00
|
|
|
Enabling this displays only forced events within subtitle streams. Only
|
|
|
|
some bitmap subtitle formats (such as DVD or PGS) are capable of having a
|
|
|
|
mixture of forced and unforced events within the stream. Enabling this on
|
|
|
|
text subtitles will cause no subtitles to be displayed (default: ``no``).
|
2013-05-03 19:00:05 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-fps=<rate>``
|
2015-12-06 00:15:08 +00:00
|
|
|
Specify the framerate of the subtitle file (default: video fps). Affects
|
|
|
|
text subtitles only.
|
2013-05-03 19:00:05 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``<rate>`` > video fps speeds the subtitles up for frame-based
|
|
|
|
subtitle files and slows them down for time-based ones.
|
2014-06-13 00:05:37 +00:00
|
|
|
|
2015-12-19 08:26:27 +00:00
|
|
|
See also: ``--sub-speed``.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
``--sub-gauss=<0.0-3.0>``
|
2015-12-19 08:26:27 +00:00
|
|
|
Apply Gaussian blur to image subtitles (default: 0). This can help to make
|
2014-07-31 14:32:37 +00:00
|
|
|
pixelated DVD/Vobsubs look nicer. A value other than 0 also switches to
|
|
|
|
software subtitle scaling. Might be slow.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Never applied to text subtitles.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-gray``
|
2015-12-19 08:26:27 +00:00
|
|
|
Convert image subtitles to grayscale. Can help to make yellow DVD/Vobsubs
|
2014-07-31 14:32:37 +00:00
|
|
|
look nicer.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Never applied to text subtitles.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--sub-paths=<path1:path2:...>``
|
2017-07-02 14:26:41 +00:00
|
|
|
Deprecated, use ``--sub-file-paths``.
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
|
2017-07-02 14:26:41 +00:00
|
|
|
``--sub-file-paths=<path-list>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Specify extra directories to search for subtitles matching the video.
|
|
|
|
Multiple directories can be separated by ":" (";" on Windows).
|
|
|
|
Paths can be relative or absolute. Relative paths are interpreted relative
|
|
|
|
to video file directory.
|
2017-03-31 18:48:06 +00:00
|
|
|
If the file is a URL, only absolute paths and ``sub`` configuration
|
|
|
|
subdirectory will be scanned.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Assuming that ``/path/to/video/video.avi`` is played and
|
2017-07-02 14:26:41 +00:00
|
|
|
``--sub-file-paths=sub:subtitles`` is specified, mpv
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
searches for subtitle files in these directories:
|
2014-06-10 23:54:03 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
- ``/path/to/video/``
|
|
|
|
- ``/path/to/video/sub/``
|
|
|
|
- ``/path/to/video/subtitles/``
|
2014-10-03 09:18:48 +00:00
|
|
|
- the ``sub`` configuration subdirectory (usually ``~/.config/mpv/sub/``)
|
2014-04-24 15:27:27 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a path list option. See `List Options`_ for details.
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
|
2022-01-19 19:56:28 +00:00
|
|
|
``--sub-visibility``, ``--no-sub-visibility``
|
2014-07-31 14:32:37 +00:00
|
|
|
Can be used to disable display of subtitles, but still select and decode
|
|
|
|
them.
|
2014-06-10 23:54:03 +00:00
|
|
|
|
2022-01-19 19:56:28 +00:00
|
|
|
``--secondary-sub-visibility``, ``--no-secondary-sub-visibility``
|
|
|
|
Can be used to disable display of secondary subtitles, but still select and
|
|
|
|
decode them.
|
|
|
|
|
2014-08-14 21:59:35 +00:00
|
|
|
``--sub-clear-on-seek``
|
|
|
|
(Obscure, rarely useful.) Can be used to play broken mkv files with
|
|
|
|
duplicate ReadOrder fields. ReadOrder is the first field in a
|
|
|
|
Matroska-style ASS subtitle packets. It should be unique, and libass
|
|
|
|
uses it for fast elimination of duplicates. This option disables caching
|
|
|
|
of subtitles across seeks, so after a seek libass can't eliminate subtitle
|
|
|
|
packets with the same ReadOrder as earlier packets.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-09-03 15:05:11 +00:00
|
|
|
``--teletext-page=<1-999>``
|
|
|
|
This works for ``dvb_teletext`` subtitle streams, and if FFmpeg has been
|
|
|
|
compiled with support for it.
|
|
|
|
|
2020-12-23 06:40:32 +00:00
|
|
|
``--sub-past-video-end``
|
|
|
|
After the last frame of video, if this option is enabled, subtitles will
|
|
|
|
continue to update based on audio timestamps. Otherwise, the subtitles
|
|
|
|
for the last video frame will stay onscreen.
|
|
|
|
|
|
|
|
Default: disabled
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-font=<name>``
|
|
|
|
Specify font to use for subtitles that do not themselves
|
|
|
|
specify a particular font. The default is ``sans-serif``.
|
|
|
|
|
|
|
|
.. admonition:: Examples
|
|
|
|
|
|
|
|
- ``--sub-font='Bitstream Vera Sans'``
|
2017-06-21 13:47:36 +00:00
|
|
|
- ``--sub-font='Comic Sans MS'``
|
2016-10-02 15:08:14 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
The ``--sub-font`` option (and many other style related ``--sub-``
|
|
|
|
options) are ignored when ASS-subtitles are rendered, unless the
|
|
|
|
``--no-sub-ass`` option is specified.
|
|
|
|
|
|
|
|
This used to support fontconfig patterns. Starting with libass 0.13.0,
|
|
|
|
this stopped working.
|
|
|
|
|
|
|
|
``--sub-font-size=<size>``
|
|
|
|
Specify the sub font size. The unit is the size in scaled pixels at a
|
|
|
|
window height of 720. The actual pixel size is scaled with the window
|
|
|
|
height: if the window height is larger or smaller than 720, the actual size
|
|
|
|
of the text increases or decreases as well.
|
|
|
|
|
|
|
|
Default: 55.
|
|
|
|
|
|
|
|
``--sub-back-color=<color>``
|
2018-01-24 19:33:44 +00:00
|
|
|
See ``--sub-color``. Color used for sub text background. You can use
|
|
|
|
``--sub-shadow-offset`` to change its size relative to the text.
|
2016-10-02 15:08:14 +00:00
|
|
|
|
|
|
|
``--sub-blur=<0..20.0>``
|
|
|
|
Gaussian blur factor. 0 means no blur applied (default).
|
|
|
|
|
|
|
|
``--sub-bold=<yes|no>``
|
|
|
|
Format text on bold.
|
|
|
|
|
|
|
|
``--sub-italic=<yes|no>``
|
|
|
|
Format text on italic.
|
|
|
|
|
|
|
|
``--sub-border-color=<color>``
|
|
|
|
See ``--sub-color``. Color used for the sub font border.
|
|
|
|
|
|
|
|
``--sub-border-size=<size>``
|
|
|
|
Size of the sub font border in scaled pixels (see ``--sub-font-size``
|
|
|
|
for details). A value of 0 disables borders.
|
|
|
|
|
|
|
|
Default: 3.
|
|
|
|
|
|
|
|
``--sub-color=<color>``
|
|
|
|
Specify the color used for unstyled text subtitles.
|
|
|
|
|
|
|
|
The color is specified in the form ``r/g/b``, where each color component
|
|
|
|
is specified as number in the range 0.0 to 1.0. It's also possible to
|
|
|
|
specify the transparency by using ``r/g/b/a``, where the alpha value 0
|
|
|
|
means fully transparent, and 1.0 means opaque. If the alpha component is
|
|
|
|
not given, the color is 100% opaque.
|
|
|
|
|
|
|
|
Passing a single number to the option sets the sub to gray, and the form
|
|
|
|
``gray/a`` lets you specify alpha additionally.
|
|
|
|
|
|
|
|
.. admonition:: Examples
|
|
|
|
|
|
|
|
- ``--sub-color=1.0/0.0/0.0`` set sub to opaque red
|
|
|
|
- ``--sub-color=1.0/0.0/0.0/0.75`` set sub to opaque red with 75% alpha
|
|
|
|
- ``--sub-color=0.5/0.75`` set sub to 50% gray with 75% alpha
|
|
|
|
|
|
|
|
Alternatively, the color can be specified as a RGB hex triplet in the form
|
|
|
|
``#RRGGBB``, where each 2-digit group expresses a color value in the
|
|
|
|
range 0 (``00``) to 255 (``FF``). For example, ``#FF0000`` is red.
|
|
|
|
This is similar to web colors. Alpha is given with ``#AARRGGBB``.
|
|
|
|
|
|
|
|
.. admonition:: Examples
|
|
|
|
|
|
|
|
- ``--sub-color='#FF0000'`` set sub to opaque red
|
|
|
|
- ``--sub-color='#C0808080'`` set sub to 50% gray with 75% alpha
|
|
|
|
|
|
|
|
``--sub-margin-x=<size>``
|
|
|
|
Left and right screen margin for the subs in scaled pixels (see
|
|
|
|
``--sub-font-size`` for details).
|
|
|
|
|
|
|
|
This option specifies the distance of the sub to the left, as well as at
|
|
|
|
which distance from the right border long sub text will be broken.
|
|
|
|
|
|
|
|
Default: 25.
|
|
|
|
|
|
|
|
``--sub-margin-y=<size>``
|
|
|
|
Top and bottom screen margin for the subs in scaled pixels (see
|
|
|
|
``--sub-font-size`` for details).
|
|
|
|
|
|
|
|
This option specifies the vertical margins of unstyled text subtitles.
|
|
|
|
If you just want to raise the vertical subtitle position, use ``--sub-pos``.
|
|
|
|
|
|
|
|
Default: 22.
|
|
|
|
|
|
|
|
``--sub-align-x=<left|center|right>``
|
|
|
|
Control to which corner of the screen text subtitles should be
|
|
|
|
aligned to (default: ``center``).
|
|
|
|
|
|
|
|
Never applied to ASS subtitles, except in ``--no-sub-ass`` mode. Likewise,
|
|
|
|
this does not apply to image subtitles.
|
|
|
|
|
|
|
|
``--sub-align-y=<top|center|bottom>``
|
|
|
|
Vertical position (default: ``bottom``).
|
|
|
|
Details see ``--sub-align-x``.
|
|
|
|
|
2017-02-01 12:19:09 +00:00
|
|
|
``--sub-justify=<auto|left|center|right>``
|
|
|
|
Control how multi line subs are justified irrespective of where they
|
|
|
|
are aligned (default: ``auto`` which justifies as defined by
|
2022-04-21 16:00:36 +00:00
|
|
|
``--sub-align-x``).
|
2017-02-01 12:19:09 +00:00
|
|
|
Left justification is recommended to make the subs easier to read
|
|
|
|
as it is easier for the eyes.
|
|
|
|
|
|
|
|
``--sub-ass-justify=<yes|no>``
|
|
|
|
Applies justification as defined by ``--sub-justify`` on ASS subtitles
|
2017-06-06 20:16:29 +00:00
|
|
|
if ``--sub-ass-override`` is not set to ``no``.
|
2017-02-01 12:19:09 +00:00
|
|
|
Default: ``no``.
|
|
|
|
|
2016-10-04 14:52:36 +00:00
|
|
|
``--sub-shadow-color=<color>``
|
2016-10-02 15:08:14 +00:00
|
|
|
See ``--sub-color``. Color used for sub text shadow.
|
|
|
|
|
2022-01-10 19:09:12 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
ignored when ``--sub-back-color`` is
|
|
|
|
specified (or more exactly: when that option is not set to completely
|
|
|
|
transparent).
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--sub-shadow-offset=<size>``
|
|
|
|
Displacement of the sub text shadow in scaled pixels (see
|
|
|
|
``--sub-font-size`` for details). A value of 0 disables shadows.
|
|
|
|
|
|
|
|
Default: 0.
|
|
|
|
|
|
|
|
``--sub-spacing=<size>``
|
|
|
|
Horizontal sub font spacing in scaled pixels (see ``--sub-font-size``
|
|
|
|
for details). This value is added to the normal letter spacing. Negative
|
|
|
|
values are allowed.
|
|
|
|
|
|
|
|
Default: 0.
|
|
|
|
|
2017-02-02 09:53:19 +00:00
|
|
|
``--sub-filter-sdh=<yes|no>``
|
|
|
|
Applies filter removing subtitle additions for the deaf or hard-of-hearing (SDH).
|
|
|
|
This is intended for English, but may in part work for other languages too.
|
|
|
|
The intention is that it can be always enabled so may not remove
|
|
|
|
all parts added.
|
|
|
|
It removes speaker labels (like MAN:), upper case text in parentheses and
|
|
|
|
any text in brackets.
|
|
|
|
|
|
|
|
Default: ``no``.
|
|
|
|
|
|
|
|
``--sub-filter-sdh-harder=<yes|no>``
|
|
|
|
Do harder SDH filtering (if enabled by ``--sub-filter-sdh``).
|
|
|
|
Will also remove speaker labels and text within parentheses using both
|
|
|
|
lower and upper case letters.
|
|
|
|
|
|
|
|
Default: ``no``.
|
|
|
|
|
2020-02-16 01:03:36 +00:00
|
|
|
``--sub-filter-regex-...=...``
|
|
|
|
Set a list of regular expressions to match on text subtitles, and remove any
|
|
|
|
lines that match (default: empty). This is a string list option. See
|
|
|
|
`List Options`_ for details. Normally, you should use
|
|
|
|
``--sub-filter-regex-append=<regex>``, where each option use will append a
|
|
|
|
new regular expression, without having to fight escaping problems.
|
|
|
|
|
|
|
|
List items are matched in order. If a regular expression matches, the
|
|
|
|
process is stopped, and the subtitle line is discarded. The text matched
|
2021-07-23 17:31:15 +00:00
|
|
|
against is, by default, the ``Text`` field of ASS events (if the
|
2020-02-16 01:03:36 +00:00
|
|
|
subtitle format is different, it is always converted). This may include
|
|
|
|
formatting tags. Matching is case-insensitive, but how this is done depends
|
|
|
|
on the libc, and most likely works in ASCII only. It does not work on
|
|
|
|
bitmap/image subtitles. Unavailable on inferior OSes (requires POSIX regex
|
|
|
|
support).
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
``--sub-filter-regex-append=opensubtitles\.org`` filters some ads.
|
|
|
|
|
|
|
|
Technically, using a list for matching is redundant, since you could just
|
|
|
|
use a single combined regular expression. But it helps with diagnosis,
|
|
|
|
ease of use, and temporarily disabling or enabling individual filters.
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
This is experimental. The semantics most likely will change, and if you
|
|
|
|
use this, you should be prepared to update the option later. Ideas
|
|
|
|
include replacing the regexes with a very primitive and small subset of
|
|
|
|
sed, or some method to control case-sensitivity.
|
|
|
|
|
2021-07-23 16:11:23 +00:00
|
|
|
``--sub-filter-jsre-...=...``
|
|
|
|
Same as ``--sub-filter-regex`` but with JavaScript regular expressions.
|
|
|
|
Shares/affected-by all ``--sub-filter-regex-*`` control options (see below),
|
|
|
|
and also experimental. Requires only JavaScript support.
|
|
|
|
|
2021-07-23 17:31:15 +00:00
|
|
|
``--sub-filter-regex-plain=<yes|no>``
|
|
|
|
Whether to first convert the ASS "Text" field to plain-text (default: no).
|
|
|
|
This strips ASS tags and applies ASS directives, like ``\N`` to new-line.
|
|
|
|
If the result is multi-line then the regexp anchors ``^`` and ``$`` match
|
|
|
|
each line, but still any match discards all lines.
|
|
|
|
|
2020-02-16 01:03:36 +00:00
|
|
|
``--sub-filter-regex-warn=<yes|no>``
|
|
|
|
Log dropped lines with warning log level, instead of verbose (default: no).
|
|
|
|
Helpful for testing.
|
|
|
|
|
|
|
|
``--sub-filter-regex-enable=<yes|no>``
|
|
|
|
Whether to enable regex filtering (default: yes). Note that if no regexes
|
|
|
|
are added to the ``--sub-filter-regex`` list, setting this option to ``yes``
|
2020-10-10 22:26:15 +00:00
|
|
|
has no effect. It's meant to easily disable or enable filtering
|
2020-02-16 01:03:36 +00:00
|
|
|
temporarily.
|
|
|
|
|
2017-11-03 12:55:32 +00:00
|
|
|
``--sub-create-cc-track=<yes|no>``
|
|
|
|
For every video stream, create a closed captions track (default: no). The
|
|
|
|
only purpose is to make the track available for selection at the start of
|
|
|
|
playback, instead of creating it lazily. This applies only to
|
|
|
|
``ATSC A53 Part 4 Closed Captions`` (displayed by mpv as subtitle tracks
|
|
|
|
using the codec ``eia_608``). The CC track is marked "default" and selected
|
|
|
|
according to the normal subtitle track selection rules. You can then use
|
|
|
|
``--sid`` to explicitly select the correct track too.
|
|
|
|
|
|
|
|
If the video stream contains no closed captions, or if no video is being
|
|
|
|
decoded, the CC track will remain empty and will not show any text.
|
|
|
|
|
2019-09-25 20:11:39 +00:00
|
|
|
``--sub-font-provider=<auto|none|fontconfig>``
|
|
|
|
Which libass font provider backend to use (default: auto). ``auto`` will
|
|
|
|
attempt to use the native font provider: fontconfig on Linux, CoreText on
|
2021-01-01 23:53:23 +00:00
|
|
|
macOS, DirectWrite on Windows. ``fontconfig`` forces fontconfig, if libass
|
2019-09-25 20:11:39 +00:00
|
|
|
was built with support (if not, it behaves like ``none``).
|
|
|
|
|
|
|
|
The ``none`` font provider effectively disables system fonts. It will still
|
|
|
|
attempt to use embedded fonts (unless ``--embeddedfonts=no`` is set; this is
|
|
|
|
the same behavior as with all other font providers), ``subfont.ttf`` if
|
|
|
|
provided, and fonts in the ``fonts`` sub-directory if provided. (The
|
|
|
|
fallback is more strict than that of other font providers, and if a font
|
|
|
|
name does not match, it may prefer not to render any text that uses the
|
|
|
|
missing font.)
|
|
|
|
|
2022-02-11 02:36:34 +00:00
|
|
|
``--sub-fonts-dir=<path>``
|
|
|
|
Font files in this directory are used by mpv/libass for subtitles. Useful
|
|
|
|
if you do not want to install fonts to your system. Note that files in this
|
|
|
|
directory are loaded into memory before being used by mpv. If you have a
|
|
|
|
lot of fonts, consider using fonts.conf (see `FILES`_ section) to include
|
|
|
|
additional mpv user settings.
|
|
|
|
|
|
|
|
If this option is not specified, ``~~/fonts`` will be used by default.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Window
|
|
|
|
------
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--title=<string>``
|
2015-01-12 13:21:16 +00:00
|
|
|
Set the window title. This is used for the video window, and if possible,
|
|
|
|
also sets the audio stream title.
|
|
|
|
|
|
|
|
Properties are expanded. (See `Property Expansion`_.)
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. warning::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
There is a danger of this causing significant CPU usage, depending on
|
2015-01-12 13:21:16 +00:00
|
|
|
the properties used. Changing the window title is often a slow
|
|
|
|
operation, and if the title changes every frame, playback can be ruined.
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--screen=<default|0-32>``
|
|
|
|
In multi-monitor configurations (i.e. a single desktop that spans across
|
|
|
|
multiple displays), this option tells mpv which screen to display the
|
|
|
|
video on.
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Note (X11)
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option does not work properly with all window managers. In these
|
|
|
|
cases, you can try to use ``--geometry`` to position the window
|
|
|
|
explicitly. It's also possible that the window manager provides native
|
|
|
|
features to control which screens application windows should use.
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
See also ``--fs-screen``.
|
2012-10-13 19:10:20 +00:00
|
|
|
|
2020-11-23 19:26:57 +00:00
|
|
|
``--screen-name=<string>``
|
|
|
|
In multi-monitor configurations, this option tells mpv which screen to
|
|
|
|
display the video on based on the screen name from the video backend. The
|
|
|
|
same caveats in the ``--screen`` option also apply here. This option is
|
|
|
|
ignored and does nothing if ``--screen`` is explicitly set.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--fullscreen``, ``--fs``
|
|
|
|
Fullscreen playback.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--fs-screen=<all|current|0-32>``
|
|
|
|
In multi-monitor configurations (i.e. a single desktop that spans across
|
|
|
|
multiple displays), this option tells mpv which screen to go fullscreen to.
|
2019-12-22 00:19:53 +00:00
|
|
|
If ``current`` is used mpv will fallback on what the user provided with
|
|
|
|
the ``screen`` option.
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Note (X11)
|
2014-04-24 15:27:27 +00:00
|
|
|
|
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
|
|
|
This option works properly only with window managers which
|
2014-07-31 14:32:37 +00:00
|
|
|
understand the EWMH ``_NET_WM_FULLSCREEN_MONITORS`` hint.
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
.. admonition:: Note (macOS)
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
``all`` does not work on macOS and will behave like ``current``.
|
2014-04-24 15:27:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
See also ``--screen``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2020-11-23 19:26:57 +00:00
|
|
|
``--fs-screen-name=<string>``
|
|
|
|
In multi-monitor configurations, this option tells mpv which screen to go
|
|
|
|
fullscreen to based on the screen name from the video backend. The same
|
|
|
|
caveats in the ``--fs-screen`` option also apply here. This option is
|
|
|
|
ignored and does nothing if ``--fs-screen`` is explicitly set.
|
|
|
|
|
2014-12-12 23:14:07 +00:00
|
|
|
``--keep-open=<yes|no|always>``
|
2014-09-23 23:56:53 +00:00
|
|
|
Do not terminate when playing or seeking beyond the end of the file, and
|
2022-10-12 14:18:14 +00:00
|
|
|
there is no next file to be played (and ``--loop`` is not used).
|
core: add --keep-open, which doesn't close the file on EOF
The --keep-open option causes mpv not to close the current file.
Instead, it will pause, and allow the user to seek around. When
seeking beyond the end of the file, mpv does a precise seek back to
the previous last known position that produced video output.
In some corner cases, mpv might not be able to produce video output at
all, despite having created a VO. (Possibly when only 1 frame could be
decoded, but the video filter chain queues frames. Then a VO would be
created, without sending an actual video frame to the VO.) In these
cases, the VO window will not redraw, not even OSD.
Based on a patch by coax [1].
[1] http://devel.mplayer2.org/ticket/210#comment:4
2012-11-12 23:56:20 +00:00
|
|
|
Instead, pause the player. When trying to seek beyond end of the file, the
|
2014-12-12 22:45:16 +00:00
|
|
|
player will attempt to seek to the last frame.
|
|
|
|
|
2017-03-27 09:34:02 +00:00
|
|
|
Normally, this will act like ``set pause yes`` on EOF, unless the
|
|
|
|
``--keep-open-pause=no`` option is set.
|
|
|
|
|
2014-12-12 22:45:16 +00:00
|
|
|
The following arguments can be given:
|
|
|
|
|
|
|
|
:no: If the current file ends, go to the next file or terminate.
|
|
|
|
(Default.)
|
|
|
|
:yes: Don't terminate if the current file is the last playlist entry.
|
|
|
|
Equivalent to ``--keep-open`` without arguments.
|
|
|
|
:always: Like ``yes``, but also applies to files before the last playlist
|
|
|
|
entry. This means playback will never automatically advance to
|
|
|
|
the next file.
|
core: add --keep-open, which doesn't close the file on EOF
The --keep-open option causes mpv not to close the current file.
Instead, it will pause, and allow the user to seek around. When
seeking beyond the end of the file, mpv does a precise seek back to
the previous last known position that produced video output.
In some corner cases, mpv might not be able to produce video output at
all, despite having created a VO. (Possibly when only 1 frame could be
decoded, but the video filter chain queues frames. Then a VO would be
created, without sending an actual video frame to the VO.) In these
cases, the VO window will not redraw, not even OSD.
Based on a patch by coax [1].
[1] http://devel.mplayer2.org/ticket/210#comment:4
2012-11-12 23:56:20 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. note::
|
|
|
|
|
2014-12-12 22:45:16 +00:00
|
|
|
This option is not respected when using ``--frames``. Explicitly
|
|
|
|
skipping to the next file if the binding uses ``force`` will terminate
|
|
|
|
playback as well.
|
|
|
|
|
|
|
|
Also, if errors or unusual circumstances happen, the player can quit
|
|
|
|
anyway.
|
core: add --keep-open, which doesn't close the file on EOF
The --keep-open option causes mpv not to close the current file.
Instead, it will pause, and allow the user to seek around. When
seeking beyond the end of the file, mpv does a precise seek back to
the previous last known position that produced video output.
In some corner cases, mpv might not be able to produce video output at
all, despite having created a VO. (Possibly when only 1 frame could be
decoded, but the video filter chain queues frames. Then a VO would be
created, without sending an actual video frame to the VO.) In these
cases, the VO window will not redraw, not even OSD.
Based on a patch by coax [1].
[1] http://devel.mplayer2.org/ticket/210#comment:4
2012-11-12 23:56:20 +00:00
|
|
|
|
2014-09-23 23:56:53 +00:00
|
|
|
Since mpv 0.6.0, this doesn't pause if there is a next file in the playlist,
|
|
|
|
or the playlist is looped. Approximately, this will pause when the player
|
|
|
|
would normally exit, but in practice there are corner cases in which this
|
|
|
|
is not the case (e.g. ``mpv --keep-open file.mkv /dev/null`` will play
|
2014-12-12 22:45:16 +00:00
|
|
|
file.mkv normally, then fail to open ``/dev/null``, then exit). (In
|
|
|
|
mpv 0.8.0, ``always`` was introduced, which restores the old behavior.)
|
2014-09-23 23:56:53 +00:00
|
|
|
|
2017-03-27 09:34:02 +00:00
|
|
|
``--keep-open-pause=<yes|no>``
|
|
|
|
If set to ``no``, instead of pausing when ``--keep-open`` is active, just
|
|
|
|
stop at end of file and continue playing forward when you seek backwards
|
|
|
|
until end where it stops again. Default: ``yes``.
|
|
|
|
|
2016-08-17 20:45:44 +00:00
|
|
|
``--image-display-duration=<seconds|inf>``
|
|
|
|
If the current file is an image, play the image for the given amount of
|
|
|
|
seconds (default: 1). ``inf`` means the file is kept open forever (until
|
|
|
|
the user stops playback manually).
|
|
|
|
|
|
|
|
Unlike ``--keep-open``, the player is not paused, but simply continues
|
|
|
|
playback until the time has elapsed. (It should not use any resources
|
|
|
|
during "playback".)
|
|
|
|
|
|
|
|
This affects image files, which are defined as having only 1 video frame
|
|
|
|
and no audio. The player may recognize certain non-images as images, for
|
|
|
|
example if ``--length`` is used to reduce the length to 1 frame, or if
|
|
|
|
you seek to the last frame.
|
|
|
|
|
|
|
|
This option does not affect the framerate used for ``mf://`` or
|
|
|
|
``--merge-files``. For that, use ``--mf-fps`` instead.
|
|
|
|
|
2017-12-05 01:55:11 +00:00
|
|
|
Setting ``--image-display-duration`` hides the OSC and does not track
|
|
|
|
playback time on the command-line output, and also does not duplicate
|
|
|
|
the image frame when encoding. To force the player into "dumb mode"
|
|
|
|
and actually count out seconds, or to duplicate the image when
|
|
|
|
encoding, you need to use ``--demuxer=lavf --demuxer-lavf-o=loop=1``,
|
|
|
|
and use ``--length`` or ``--frames`` to stop after a particular time.
|
|
|
|
|
2015-05-08 19:47:39 +00:00
|
|
|
``--force-window=<yes|no|immediate>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Create a video output window even if there is no video. This can be useful
|
|
|
|
when pretending that mpv is a GUI application. Currently, the window
|
|
|
|
always has the size 640x480, and is subject to ``--geometry``,
|
|
|
|
``--autofit``, and similar options.
|
2013-08-25 18:40:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. warning::
|
2013-08-25 18:40:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
The window is created only after initialization (to make sure default
|
|
|
|
window placement still works if the video size is different from the
|
|
|
|
``--force-window`` default window size). This can be a problem if
|
|
|
|
initialization doesn't work perfectly, such as when opening URLs with
|
2015-05-08 19:47:39 +00:00
|
|
|
bad network connection, or opening broken video files. The ``immediate``
|
|
|
|
mode can be used to create the window always on program start, but this
|
|
|
|
may cause other issues.
|
2013-08-25 18:40:21 +00:00
|
|
|
|
2016-05-05 05:56:21 +00:00
|
|
|
``--taskbar-progress``, ``--no-taskbar-progress``
|
|
|
|
(Windows only)
|
|
|
|
Enable/disable playback progress rendering in taskbar (Windows 7 and above).
|
2016-09-12 04:18:04 +00:00
|
|
|
|
2016-05-05 05:56:21 +00:00
|
|
|
Enabled by default.
|
|
|
|
|
2016-12-09 18:22:33 +00:00
|
|
|
``--snap-window``
|
|
|
|
(Windows only) Snap the player window to screen edges.
|
|
|
|
|
2023-06-12 23:09:21 +00:00
|
|
|
``--drag-and-drop=<no|auto|replace|append>``
|
2023-06-12 23:42:49 +00:00
|
|
|
(X11, Wayland and Windows only)
|
2023-05-20 21:51:12 +00:00
|
|
|
Controls the default behavior of drag and drop on platforms that support this.
|
|
|
|
``auto`` will obey what the underlying os/platform gives mpv. Typically, holding
|
|
|
|
shift during the drag and drop will append the item to the playlist. Otherwise,
|
|
|
|
it will completely replace it. ``replace`` and ``append`` always force replacing
|
2023-06-12 23:09:21 +00:00
|
|
|
and appending to the playlist respectively. ``no`` disables all drag and drop
|
|
|
|
behavior.
|
2023-05-20 21:51:12 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--ontop``
|
|
|
|
Makes the player window stay on top of other windows.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-11-13 05:16:01 +00:00
|
|
|
On Windows, if combined with fullscreen mode, this causes mpv to be
|
|
|
|
treated as exclusive fullscreen window that bypasses the Desktop Window
|
|
|
|
Manager.
|
|
|
|
|
2020-09-15 14:24:36 +00:00
|
|
|
``--ontop-level=<window|system|desktop|level>``
|
2021-01-01 23:53:23 +00:00
|
|
|
(macOS only)
|
2017-02-13 19:08:43 +00:00
|
|
|
Sets the level of an ontop window (default: window).
|
|
|
|
|
|
|
|
:window: On top of all other windows.
|
|
|
|
:system: On top of system elements like Taskbar, Menubar and Dock.
|
2023-03-27 20:42:17 +00:00
|
|
|
:desktop: On top of the Desktop behind windows and Desktop icons.
|
2017-02-13 19:08:43 +00:00
|
|
|
:level: A level as integer.
|
|
|
|
|
2020-09-14 15:27:43 +00:00
|
|
|
``--focus-on-open``, ``--no-focus-on-open``
|
|
|
|
(macOS only)
|
|
|
|
Focus the video window on creation and makes it the front most window. This
|
|
|
|
is on by default.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--border``, ``--no-border``
|
|
|
|
Play video with window border and decorations. Since this is on by
|
|
|
|
default, use ``--no-border`` to disable the standard window decorations.
|
2014-04-17 21:55:04 +00:00
|
|
|
|
2015-01-16 22:38:47 +00:00
|
|
|
``--on-all-workspaces``
|
2021-02-20 20:07:00 +00:00
|
|
|
(X11 and macOS only)
|
2015-01-16 22:38:47 +00:00
|
|
|
Show the video window on all virtual desktops.
|
|
|
|
|
2020-07-11 22:12:55 +00:00
|
|
|
``--geometry=<[W[xH]][+-x+-y][/WS]>``, ``--geometry=<x:y>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Adjust the initial window position or size. ``W`` and ``H`` set the window
|
|
|
|
size in pixels. ``x`` and ``y`` set the window position, measured in pixels
|
|
|
|
from the top-left corner of the screen to the top-left corner of the image
|
|
|
|
being displayed. If a percentage sign (``%``) is given after the argument,
|
|
|
|
it turns the value into a percentage of the screen size in that direction.
|
|
|
|
Positions are specified similar to the standard X11 ``--geometry`` option
|
|
|
|
format, in which e.g. +10-50 means "place 10 pixels from the left border and
|
|
|
|
50 pixels from the lower border" and "--20+-10" means "place 20 pixels
|
2020-07-11 22:12:55 +00:00
|
|
|
beyond the right and 10 pixels beyond the top border". A trailing ``/``
|
|
|
|
followed by an integer denotes on which workspace (virtual desktop) the
|
|
|
|
window should appear (X11 only).
|
Add initial Lua scripting support
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
2013-09-25 22:41:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If an external window is specified using the ``--wid`` option, this
|
|
|
|
option is ignored.
|
2014-01-16 22:06:06 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
The coordinates are relative to the screen given with ``--screen`` for the
|
|
|
|
video output drivers that fully support ``--screen``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2013-11-19 21:36:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Generally only supported by GUI VOs. Ignored for encoding.
|
2013-11-19 21:36:33 +00:00
|
|
|
|
2023-06-15 16:28:18 +00:00
|
|
|
.. admonition:: Note (macOS)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
On macOS, the origin of the screen coordinate system is located on the
|
2014-07-31 14:32:37 +00:00
|
|
|
bottom-left corner. For instance, ``0:0`` will place the window at the
|
|
|
|
bottom-left of the screen.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Note (X11)
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option does not work properly with all window managers.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``50:40``
|
|
|
|
Places the window at x=50, y=40.
|
|
|
|
``50%:50%``
|
|
|
|
Places the window in the middle of the screen.
|
|
|
|
``100%:100%``
|
|
|
|
Places the window at the bottom right corner of the screen.
|
|
|
|
``50%``
|
|
|
|
Sets the window width to half the screen width. Window height is set
|
|
|
|
so that the window has the video aspect ratio.
|
|
|
|
``50%x50%``
|
|
|
|
Forces the window width and height to half the screen width and
|
|
|
|
height. Will show black borders to compensate for the video aspect
|
2016-12-20 15:18:45 +00:00
|
|
|
ratio (with most VOs and without ``--no-keepaspect``).
|
2020-07-11 22:12:55 +00:00
|
|
|
``50%+10+10/2``
|
2014-07-31 14:32:37 +00:00
|
|
|
Sets the window to half the screen widths, and positions it 10
|
2020-07-11 22:12:55 +00:00
|
|
|
pixels below/left of the top left corner of the screen, on the
|
|
|
|
second workspace.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
See also ``--autofit`` and ``--autofit-larger`` for fitting the window into
|
|
|
|
a given size without changing aspect ratio.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--autofit=<[W[xH]]>``
|
|
|
|
Set the initial window size to a maximum size specified by ``WxH``, without
|
|
|
|
changing the window's aspect ratio. The size is measured in pixels, or if
|
|
|
|
a number is followed by a percentage sign (``%``), in percents of the
|
|
|
|
screen size.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option never changes the aspect ratio of the window. If the aspect
|
|
|
|
ratio mismatches, the window's size is reduced until it fits into the
|
|
|
|
specified size.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Window position is not taken into account, nor is it modified by this
|
|
|
|
option (the window manager still may place the window differently depending
|
|
|
|
on size). Use ``--geometry`` to change the window position. Its effects
|
|
|
|
are applied after this option.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
See ``--geometry`` for details how this is handled with multi-monitor
|
|
|
|
setups.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Use ``--autofit-larger`` instead if you just want to limit the maximum size
|
|
|
|
of the window, rather than always forcing a window size.
|
2014-04-24 16:16:47 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Use ``--geometry`` if you want to force both window width and height to a
|
|
|
|
specific size.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2012-11-15 18:22:01 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Generally only supported by GUI VOs. Ignored for encoding.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Examples
|
2013-04-24 19:37:10 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``70%``
|
|
|
|
Make the window width 70% of the screen size, keeping aspect ratio.
|
|
|
|
``1000``
|
|
|
|
Set the window width to 1000 pixels, keeping aspect ratio.
|
2016-04-24 15:58:39 +00:00
|
|
|
``70%x60%``
|
2014-07-31 14:32:37 +00:00
|
|
|
Make the window as large as possible, without being wider than 70%
|
|
|
|
of the screen width, or higher than 60% of the screen height.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--autofit-larger=<[W[xH]]>``
|
|
|
|
This option behaves exactly like ``--autofit``, except the window size is
|
|
|
|
only changed if the window would be larger than the specified size.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``90%x80%``
|
|
|
|
If the video is larger than 90% of the screen width or 80% of the
|
|
|
|
screen height, make the window smaller until either its width is 90%
|
|
|
|
of the screen, or its height is 80% of the screen.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-01-16 21:30:32 +00:00
|
|
|
``--autofit-smaller=<[W[xH]]>``
|
|
|
|
This option behaves exactly like ``--autofit``, except that it sets the
|
|
|
|
minimum size of the window (just as ``--autofit-larger`` sets the maximum).
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
``500x500``
|
|
|
|
Make the window at least 500 pixels wide and 500 pixels high
|
|
|
|
(depending on the video aspect ratio, the width or height will be
|
|
|
|
larger than 500 in order to keep the aspect ratio the same).
|
|
|
|
|
2015-04-24 20:52:01 +00:00
|
|
|
``--window-scale=<factor>``
|
|
|
|
Resize the video window to a multiple (or fraction) of the video size. This
|
|
|
|
option is applied before ``--autofit`` and other options are applied (so
|
|
|
|
they override this option).
|
|
|
|
|
|
|
|
For example, ``--window-scale=0.5`` would show the window at half the
|
|
|
|
video size.
|
|
|
|
|
2019-11-29 12:49:33 +00:00
|
|
|
``--window-minimized=<yes|no>``
|
|
|
|
Whether the video window is minimized or not. Setting this will minimize,
|
2020-10-12 09:04:43 +00:00
|
|
|
or unminimize, the video window if the current VO supports it. Note that
|
2019-11-29 12:49:33 +00:00
|
|
|
some VOs may support minimization while not supporting unminimization
|
2019-11-29 13:27:27 +00:00
|
|
|
(eg: Wayland).
|
2019-11-29 12:49:33 +00:00
|
|
|
|
|
|
|
Whether this option and ``--window-maximized`` work on program start or
|
|
|
|
at runtime, and whether they're (at runtime) updated to reflect the actual
|
|
|
|
window state, heavily depends on the VO and the windowing system. Some VOs
|
|
|
|
simply do not implement them or parts of them, while other VOs may be
|
|
|
|
restricted by the windowing systems (especially Wayland).
|
|
|
|
|
|
|
|
``--window-maximized=<yes|no>``
|
|
|
|
Whether the video window is maximized or not. Setting this will maximize,
|
|
|
|
or unmaximize, the video window if the current VO supports it. See
|
|
|
|
``--window-minimized`` for further remarks.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cursor-autohide=<number|no|always>``
|
2023-03-02 05:17:33 +00:00
|
|
|
Make mouse cursor automatically hide after given number of milliseconds
|
|
|
|
(default: 1000 ms). ``no`` will disable cursor autohide. ``always``
|
|
|
|
means the cursor will stay hidden.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cursor-autohide-fs-only``
|
|
|
|
If this option is given, the cursor is always visible in windowed mode. In
|
|
|
|
fullscreen mode, the cursor is shown or hidden according to
|
|
|
|
``--cursor-autohide``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--no-fixed-vo``, ``--fixed-vo``
|
|
|
|
``--no-fixed-vo`` enforces closing and reopening the video window for
|
|
|
|
multiple files (one (un)initialization for each file).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--force-rgba-osd-rendering``
|
|
|
|
Change how some video outputs render the OSD and text subtitles. This
|
|
|
|
does not change appearance of the subtitles and only has performance
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
implications. For VOs which support native ASS rendering (like ``gpu``,
|
|
|
|
``vdpau``, ``direct3d``), this can be slightly faster or slower,
|
2014-07-31 14:32:37 +00:00
|
|
|
depending on GPU drivers and hardware. For other VOs, this just makes
|
|
|
|
rendering slower.
|
2013-12-14 20:52:37 +00:00
|
|
|
|
2022-11-11 19:57:53 +00:00
|
|
|
``--force-render``
|
|
|
|
Forces mpv to always render frames regardless of the visibility of the
|
|
|
|
window. Currently only affects X11 and Wayland VOs since they are the
|
|
|
|
only ones that have this optimization (i.e. everything else always renders
|
|
|
|
regardless of visibility).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--force-window-position``
|
|
|
|
Forcefully move mpv's video output window to default location whenever
|
|
|
|
there is a change in video parameters, video stream or file. This used to
|
|
|
|
be the default behavior. Currently only affects X11 VOs.
|
2013-12-14 20:52:37 +00:00
|
|
|
|
2021-10-20 02:47:23 +00:00
|
|
|
``--auto-window-resize=<yes|no>``
|
|
|
|
(Wayland, Win32, and X11)
|
|
|
|
By default, mpv will automatically resize itself if the video's size changes
|
|
|
|
(i.e. advancing forward in a playlist). Setting this to ``no`` disables this
|
|
|
|
behavior so the window size never changes automatically. This option does
|
|
|
|
not have any impact on the ``--autofit`` or ``--geometry`` options.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--no-keepaspect``, ``--keepaspect``
|
|
|
|
``--no-keepaspect`` will always stretch the video to window size, and will
|
|
|
|
disable the window manager hints that force the window aspect ratio.
|
|
|
|
(Ignored in fullscreen mode.)
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-10-04 20:17:36 +00:00
|
|
|
``--no-keepaspect-window``, ``--keepaspect-window``
|
|
|
|
``--keepaspect-window`` (the default) will lock the window size to the
|
|
|
|
video aspect. ``--no-keepaspect-window`` disables this behavior, and will
|
|
|
|
instead add black bars if window aspect and video aspect mismatch. Whether
|
|
|
|
this actually works depends on the VO backend.
|
|
|
|
(Ignored in fullscreen mode.)
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--monitoraspect=<ratio>``
|
|
|
|
Set the aspect ratio of your monitor or TV screen. A value of 0 disables a
|
|
|
|
previous setting (e.g. in the config file). Overrides the
|
|
|
|
``--monitorpixelaspect`` setting if enabled.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2019-10-04 16:45:37 +00:00
|
|
|
See also ``--monitorpixelaspect`` and ``--video-aspect-override``.
|
2014-01-30 23:41:54 +00:00
|
|
|
|
|
|
|
.. admonition:: Examples
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
- ``--monitoraspect=4:3`` or ``--monitoraspect=1.3333``
|
|
|
|
- ``--monitoraspect=16:9`` or ``--monitoraspect=1.7777``
|
2014-01-30 23:41:54 +00:00
|
|
|
|
2016-10-25 13:59:13 +00:00
|
|
|
``--hidpi-window-scale``, ``--no-hidpi-window-scale``
|
2021-01-01 23:53:23 +00:00
|
|
|
(macOS, Windows, X11, and Wayland only)
|
2016-10-25 13:59:13 +00:00
|
|
|
Scale the window size according to the backing scale factor (default: yes).
|
2016-11-11 20:44:27 +00:00
|
|
|
On regular HiDPI resolutions the window opens with double the size but appears
|
2023-03-02 05:13:57 +00:00
|
|
|
as having the same size as on non-HiDPI resolutions.
|
2016-11-11 20:44:27 +00:00
|
|
|
|
2017-07-27 19:28:33 +00:00
|
|
|
``--native-fs``, ``--no-native-fs``
|
2021-01-01 23:53:23 +00:00
|
|
|
(macOS only)
|
2017-07-27 19:28:33 +00:00
|
|
|
Uses the native fullscreen mechanism of the OS (default: yes).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--monitorpixelaspect=<ratio>``
|
|
|
|
Set the aspect of a single pixel of your monitor or TV screen (default:
|
|
|
|
1). A value of 1 means square pixels (correct for (almost?) all LCDs). See
|
2019-10-04 16:45:37 +00:00
|
|
|
also ``--monitoraspect`` and ``--video-aspect-override``.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2022-02-18 20:39:25 +00:00
|
|
|
``--stop-screensaver=<yes|no|always>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Turns off the screensaver (or screen blanker and similar mechanisms) at
|
2022-02-18 20:39:25 +00:00
|
|
|
startup and turns it on again on exit (default: yes). When using ``yes``,
|
|
|
|
the screensaver will re-enable when playback is not active. ``always`` will
|
|
|
|
always disable the screensaver. Note that stopping the screensaver is only
|
|
|
|
possible if a video output is available (i.e. there is an open mpv window).
|
2012-12-21 19:36:08 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This is not supported on all video outputs or platforms. Sometimes it is
|
2020-07-08 20:25:08 +00:00
|
|
|
implemented, but does not work (especially with Linux "desktops"). Read the
|
|
|
|
`Disabling Screensaver`_ section very carefully.
|
2012-12-21 19:36:08 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--wid=<ID>``
|
2014-10-09 17:35:43 +00:00
|
|
|
This tells mpv to attach to an existing window. If a VO is selected that
|
|
|
|
supports this option, it will use that window for video output. mpv will
|
|
|
|
scale the video to the size of this window, and will add black bars to
|
|
|
|
compensate if the aspect ratio of the video is different.
|
|
|
|
|
|
|
|
On X11, the ID is interpreted as a ``Window`` on X11. Unlike
|
|
|
|
MPlayer/mplayer2, mpv always creates its own window, and sets the wid
|
|
|
|
window as parent. The window will always be resized to cover the parent
|
|
|
|
window fully. The value ``0`` is interpreted specially, and mpv will
|
|
|
|
draw directly on the root window.
|
|
|
|
|
|
|
|
On win32, the ID is interpreted as ``HWND``. Pass it as value cast to
|
2023-01-09 15:14:20 +00:00
|
|
|
``uint32_t`` (all Windows handles are 32-bit), this is important as mpv will
|
|
|
|
not accept negative values. mpv will create its own window and set the
|
|
|
|
wid window as parent, like with X11.
|
2014-10-09 17:35:43 +00:00
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
On macOS/Cocoa, the ID is interpreted as ``NSView*``. Pass it as value cast
|
|
|
|
to ``intptr_t``. mpv will create its own sub-view. Because macOS does not
|
2014-10-09 17:35:43 +00:00
|
|
|
support window embedding of foreign processes, this works only with libmpv,
|
|
|
|
and will crash when used from the command line.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2017-07-06 17:54:40 +00:00
|
|
|
On Android, the ID is interpreted as ``android.view.Surface``. Pass it as a
|
|
|
|
value cast to ``intptr_t``. Use with ``--vo=mediacodec_embed`` and
|
2017-10-05 18:58:37 +00:00
|
|
|
``--hwdec=mediacodec`` for direct rendering using MediaCodec, or with
|
2021-10-18 14:50:39 +00:00
|
|
|
``--vo=gpu --gpu-context=android`` (with or without ``--hwdec=mediacodec``).
|
2017-07-06 17:54:40 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--no-window-dragging``
|
|
|
|
Don't move the window when clicking on it and moving the mouse pointer.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2023-05-03 05:53:17 +00:00
|
|
|
``--x11-name=<string>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Set the window class name for X11-based video output methods.
|
2013-01-04 15:04:08 +00:00
|
|
|
|
2014-10-04 13:03:02 +00:00
|
|
|
``--x11-netwm=<yes|no|auto>``
|
2014-07-31 14:32:37 +00:00
|
|
|
(X11 only)
|
2014-10-04 13:03:02 +00:00
|
|
|
Control the use of NetWM protocol features.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This may or may not help with broken window managers. This provides some
|
|
|
|
functionality that was implemented by the now removed ``--fstype`` option.
|
|
|
|
Actually, it is not known to the developers to which degree this option
|
|
|
|
was needed, so feedback is welcome.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-10-04 13:03:02 +00:00
|
|
|
Specifically, ``yes`` will force use of NetWM fullscreen support, even if
|
|
|
|
not advertised by the WM. This can be useful for WMs that are broken on
|
|
|
|
purpose, like XMonad. (XMonad supposedly doesn't advertise fullscreen
|
|
|
|
support, because Flash uses it. Apparently, applications which want to
|
|
|
|
use fullscreen anyway are supposed to either ignore the NetWM support hints,
|
|
|
|
or provide a workaround. Shame on XMonad for deliberately breaking X
|
|
|
|
protocols (as if X isn't bad enough already).
|
|
|
|
|
|
|
|
By default, NetWM support is autodetected (``auto``).
|
|
|
|
|
|
|
|
This option might be removed in the future.
|
2013-01-04 15:10:17 +00:00
|
|
|
|
2016-05-07 10:14:56 +00:00
|
|
|
``--x11-bypass-compositor=<yes|no|fs-only|never>``
|
2016-04-03 17:41:40 +00:00
|
|
|
If set to ``yes``, then ask the compositor to unredirect the mpv window
|
2016-05-06 17:57:17 +00:00
|
|
|
(default: ``fs-only``). This uses the ``_NET_WM_BYPASS_COMPOSITOR`` hint.
|
|
|
|
|
|
|
|
``fs-only`` asks the window manager to disable the compositor only in
|
2016-05-08 09:05:01 +00:00
|
|
|
fullscreen mode.
|
|
|
|
|
|
|
|
``no`` sets ``_NET_WM_BYPASS_COMPOSITOR`` to 0, which is the default value
|
|
|
|
as declared by the EWMH specification, i.e. no change is done.
|
2016-05-06 17:57:17 +00:00
|
|
|
|
2016-05-07 10:14:56 +00:00
|
|
|
``never`` asks the window manager to never disable the compositor.
|
2015-11-18 20:37:38 +00:00
|
|
|
|
2022-06-20 00:40:20 +00:00
|
|
|
``--x11-present=<no|auto|yes>``
|
|
|
|
Whether or not to use presentation statistics from X11's presentation
|
|
|
|
extension (default: ``auto``).
|
|
|
|
|
|
|
|
mpv asks X11 for present events which it then may use for more accurate
|
|
|
|
frame presentation. This only has an effect if ``--video-sync=display-...``
|
|
|
|
is being used.
|
|
|
|
|
|
|
|
The auto option enumerates XRandr providers for autodetection. If amd, radeon,
|
|
|
|
intel, or nouveau (the standard x86 Mesa drivers) is found and nvidia is NOT
|
|
|
|
found, presentation feedback is enabled. Other drivers are not assumed to
|
|
|
|
work, so they are not enabled automatically.
|
|
|
|
|
|
|
|
``yes`` or ``no`` can still be passed regardless to enable/disable this
|
|
|
|
mechanism in case there is good/bad behavior with whatever your combination
|
|
|
|
of hardware/drivers/etc. happens to be.
|
|
|
|
|
2023-08-10 02:11:53 +00:00
|
|
|
``--x11-wid-title`` ``--no-x11-wid-title``
|
|
|
|
Whether or not to set the window title when mpv is embedded on X11 (default:
|
|
|
|
``no``).
|
|
|
|
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Disc Devices
|
|
|
|
------------
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdrom-device=<path>``
|
|
|
|
Specify the CD-ROM device (default: ``/dev/cdrom``).
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--dvd-device=<path>``
|
|
|
|
Specify the DVD device or .iso filename (default: ``/dev/dvd``). You can
|
|
|
|
also specify a directory that contains files previously copied directly
|
|
|
|
from a DVD (with e.g. vobcopy).
|
2013-01-04 15:04:08 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``mpv dvd:// --dvd-device=/path/to/dvd/``
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--bluray-device=<path>``
|
|
|
|
(Blu-ray only)
|
|
|
|
Specify the Blu-ray disc location. Must be a directory with Blu-ray
|
|
|
|
structure.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``mpv bd:// --bluray-device=/path/to/bd/``
|
|
|
|
|
|
|
|
``--cdda-...``
|
|
|
|
These options can be used to tune the CD Audio reading feature of mpv.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdda-speed=<value>``
|
|
|
|
Set CD spin speed.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdda-paranoia=<0-2>``
|
|
|
|
Set paranoia level. Values other than 0 seem to break playback of
|
|
|
|
anything but the first track.
|
2013-05-14 12:10:27 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:0: disable checking (default)
|
|
|
|
:1: overlap checking only
|
|
|
|
:2: full data correction and verification
|
2013-12-10 18:58:57 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdda-sector-size=<value>``
|
|
|
|
Set atomic read size.
|
2013-01-04 15:04:08 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdda-overlap=<value>``
|
|
|
|
Force minimum overlap search during verification to <value> sectors.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdda-toc-bias``
|
|
|
|
Assume that the beginning offset of track 1 as reported in the TOC
|
|
|
|
will be addressed as LBA 0. Some discs need this for getting track
|
|
|
|
boundaries correctly.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cdda-toc-offset=<value>``
|
|
|
|
Add ``<value>`` sectors to the values reported when addressing tracks.
|
|
|
|
May be negative.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-10-26 11:02:00 +00:00
|
|
|
``--cdda-skip=<yes|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
(Never) accept imperfect data reconstruction.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2015-03-03 14:29:07 +00:00
|
|
|
``--cdda-cdtext=<yes|no>``
|
2015-06-17 17:37:25 +00:00
|
|
|
Print CD text. This is disabled by default, because it ruins performance
|
2015-03-03 14:29:07 +00:00
|
|
|
with CD-ROM drives for unknown reasons.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--dvd-speed=<speed>``
|
|
|
|
Try to limit DVD speed (default: 0, no change). DVD base speed is 1385
|
|
|
|
kB/s, so an 8x drive can read at speeds up to 11080 kB/s. Slower speeds
|
|
|
|
make the drive more quiet. For watching DVDs, 2700 kB/s should be quiet and
|
|
|
|
fast enough. mpv resets the speed to the drive default value on close.
|
|
|
|
Values of at least 100 mean speed in kB/s. Values less than 100 mean
|
|
|
|
multiples of 1385 kB/s, i.e. ``--dvd-speed=8`` selects 11080 kB/s.
|
2013-02-16 21:14:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
You need write access to the DVD device to change the speed.
|
2014-01-03 19:35:10 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--dvd-angle=<ID>``
|
|
|
|
Some DVDs contain scenes that can be viewed from multiple angles.
|
|
|
|
This option tells mpv which angle to use (default: 1).
|
2013-05-11 20:19:33 +00:00
|
|
|
|
2013-05-11 20:40:46 +00:00
|
|
|
|
2014-07-29 23:15:42 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Equalizer
|
|
|
|
---------
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--brightness=<-100-100>``
|
|
|
|
Adjust the brightness of the video signal (default: 0). Not supported by
|
|
|
|
all video output drivers.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--contrast=<-100-100>``
|
|
|
|
Adjust the contrast of the video signal (default: 0). Not supported by all
|
|
|
|
video output drivers.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--saturation=<-100-100>``
|
|
|
|
Adjust the saturation of the video signal (default: 0). You can get
|
|
|
|
grayscale output with this option. Not supported by all video output
|
|
|
|
drivers.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--gamma=<-100-100>``
|
|
|
|
Adjust the gamma of the video signal (default: 0). Not supported by all
|
|
|
|
video output drivers.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--hue=<-100-100>``
|
|
|
|
Adjust the hue of the video signal (default: 0). You can get a colored
|
|
|
|
negative of the image with this option. Not supported by all video output
|
|
|
|
drivers.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Demuxer
|
|
|
|
-------
|
2014-01-05 21:21:08 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer=<[+]name>``
|
|
|
|
Force demuxer type. Use a '+' before the name to force it; this will skip
|
|
|
|
some checks. Give the demuxer name as printed by ``--demuxer=help``.
|
2013-06-27 16:21:07 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-analyzeduration=<value>``
|
|
|
|
Maximum length in seconds to analyze the stream properties.
|
2013-06-27 16:21:07 +00:00
|
|
|
|
2018-03-02 12:59:10 +00:00
|
|
|
``--demuxer-lavf-probe-info=<yes|no|auto|nostreams>``
|
2017-02-23 17:18:22 +00:00
|
|
|
Whether to probe stream information (default: auto). Technically, this
|
|
|
|
controls whether libavformat's ``avformat_find_stream_info()`` function
|
|
|
|
is called. Usually it's safer to call it, but it can also make startup
|
|
|
|
slower.
|
|
|
|
|
|
|
|
The ``auto`` choice (the default) tries to skip this for a few know-safe
|
|
|
|
whitelisted formats, while calling it for everything else.
|
|
|
|
|
2018-03-02 12:59:10 +00:00
|
|
|
The ``nostreams`` choice only calls it if and only if the file seems to
|
|
|
|
contain no streams after opening (helpful in cases when calling the function
|
|
|
|
is needed to detect streams at all, such as with FLV files).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-probescore=<1-100>``
|
|
|
|
Minimum required libavformat probe score. Lower values will require
|
|
|
|
less data to be loaded (makes streams start faster), but makes file
|
|
|
|
format detection less reliable. Can be used to force auto-detected
|
|
|
|
libavformat demuxers, even if libavformat considers the detection not
|
|
|
|
reliable enough. (Default: 26.)
|
2013-01-30 23:39:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-allow-mimetype=<yes|no>``
|
|
|
|
Allow deriving the format from the HTTP MIME type (default: yes). Set
|
|
|
|
this to no in case playing things from HTTP mysteriously fails, even
|
|
|
|
though the same files work from local disk.
|
2013-01-30 23:39:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This is default in order to reduce latency when opening HTTP streams.
|
2013-06-27 16:21:07 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-format=<name>``
|
|
|
|
Force a specific libavformat demuxer.
|
2013-06-27 16:21:07 +00:00
|
|
|
|
2015-04-17 20:03:25 +00:00
|
|
|
``--demuxer-lavf-hacks=<yes|no>``
|
|
|
|
By default, some formats will be handled differently from other formats
|
|
|
|
by explicitly checking for them. Most of these compensate for weird or
|
|
|
|
imperfect behavior from libavformat demuxers. Passing ``no`` disables
|
|
|
|
these. For debugging and testing only.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-o=<key>=<value>[,<key>=<value>[,...]]``
|
|
|
|
Pass AVOptions to libavformat demuxer.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Note, a patch to make the *o=* unneeded and pass all unknown options
|
|
|
|
through the AVOption system is welcome. A full list of AVOptions can
|
|
|
|
be found in the FFmpeg manual. Note that some options may conflict
|
|
|
|
with mpv options.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2013-04-10 19:06:00 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-o=fflags=+ignidx``
|
2013-06-07 15:07:04 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-probesize=<value>``
|
|
|
|
Maximum amount of data to probe during the detection phase. In the
|
|
|
|
case of MPEG-TS this value identifies the maximum number of TS packets
|
|
|
|
to scan.
|
2013-04-10 19:06:00 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-lavf-buffersize=<value>``
|
|
|
|
Size of the stream read buffer allocated for libavformat in bytes
|
|
|
|
(default: 32768). Lowering the size could lower latency. Note that
|
|
|
|
libavformat might reallocate the buffer internally, or not fully use all
|
|
|
|
of it.
|
2013-04-10 19:06:00 +00:00
|
|
|
|
demux_lavf: compensate timestamp resets for OGG web radio streams
Some OGG web radio streams use timestamp resets when a new song starts
(you can find those Xiph's directory - other streams there don't show
this behavior). Basically, the OGG stream behaves like concatenated OGG
files, and "of course" the timestamps will start at 0 again when the
song changes. This is very inconvenient, and breaks the seekable demuxer
cache. In fact, any kind of seeking will break
This is more time wasted in Xiph's bullshit. No, having timestamp resets
by design is not reasonable, and fuck you. I much prefer the awful
ICY/mp3 streaming mess, even if that's lower quality and awful. Maybe it
wouldn't be so bad if libavformat could tell us WHERE THE FUCK THE RESET
HAPPENS. But it doesn't, and the randomly changing timestamps is the
only thing we get from its API.
At this point, demux_lavf.c is like 90% hacks. But well, if libavformat
applies this strange mixture of being clever for us vs. giving us
unfiltered garbage (while pretending it abstracts everything, and hiding
_useful_ implementation/low level details), not much we can do.
This timestamp linearizing would, in general, probably be better done
after the decoder, because then we wouldn't need to deal with timestamp
resets. But the main purpose of this change is to fix seeking within the
demuxer cache, so we have to do it on the lowest level.
This can probably be applied to other containers and video streams too.
But that is untested. Some further caveats are explained in the manpage.
2019-06-09 21:39:03 +00:00
|
|
|
``--demuxer-lavf-linearize-timestamps=<yes|no|auto>``
|
|
|
|
Attempt to linearize timestamp resets in demuxed streams (default: auto).
|
|
|
|
This was tested only for single audio streams. It's unknown whether it
|
|
|
|
works correctly for video (but likely won't). Note that the implementation
|
|
|
|
is slightly incorrect either way, and will introduce a discontinuity by
|
|
|
|
about 1 codec frame size.
|
|
|
|
|
|
|
|
The ``auto`` mode enables this for OGG audio stream. This covers the common
|
|
|
|
and annoying case of OGG web radio streams. Some of these will reset
|
|
|
|
timestamps to 0 every time a new song begins. This breaks the mpv seekable
|
|
|
|
cache, which can't deal with timestamp resets. Note that FFmpeg/libavformat's
|
|
|
|
seeking API can't deal with this either; it's likely that if this option
|
|
|
|
breaks this even more, while if it's disabled, you can at least seek within
|
|
|
|
the first song in the stream. Well, you won't get anything useful either
|
|
|
|
way if the seek is outside of mpv's cache.
|
|
|
|
|
demux_lavf: fight ffmpeg API some more and get the timeout set
It sometimes happens that HLS streams freeze because the HTTP server is
not responding for a fragment (or something similar, the exact
circumstances are unknown). The --timeout option didn't affect this,
because it's never set on HLS recursive connections (these download the
fragments, while the main connection likely nothing and just wastes a
TCP socket).
Apply an elaborate hack on top of an existing elaborate hack to somehow
get these options set. Of course this could still break easily, but hey,
it's ffmpeg, it can't not try to fuck you over. I'm so fucking sick of
ffmpeg's API bullshit, especially wrt. HLS.
Of course the change is sort of pointless. For HLS, GET requests should
just aggressively retried (because they're not "streamed", they're just
actual files on a CDN), while normal HTTP connections should probably
not be made this fragile (they could be streamed, i.e. they are backed
by some sort of real time encoder, and block if there is no data yet).
The 1 minute default timeout is too high to save playback if this
happens with HLS.
Vaguely related to #5793.
2019-11-16 12:15:45 +00:00
|
|
|
``--demuxer-lavf-propagate-opts=<yes|no>``
|
|
|
|
Propagate FFmpeg-level options to recursively opened connections (default:
|
|
|
|
yes). This is needed because FFmpeg will apply these settings to nested
|
|
|
|
AVIO contexts automatically. On the other hand, this could break in certain
|
|
|
|
situations - it's the FFmpeg API, you just can't win.
|
|
|
|
|
|
|
|
This affects in particular the ``--timeout`` option and anything passed
|
|
|
|
with ``--demuxer-lavf-o``.
|
|
|
|
|
|
|
|
If this option is deemed unnecessary at some point in the future, it will
|
|
|
|
be removed without notice.
|
|
|
|
|
2015-12-27 00:01:25 +00:00
|
|
|
``--demuxer-mkv-subtitle-preroll=<yes|index|no>``, ``--mkv-subtitle-preroll``
|
2014-07-31 14:32:37 +00:00
|
|
|
Try harder to show embedded soft subtitles when seeking somewhere. Normally,
|
|
|
|
it can happen that the subtitle at the seek target is not shown due to how
|
|
|
|
some container file formats are designed. The subtitles appear only if
|
|
|
|
seeking before or exactly to the position a subtitle first appears. To
|
|
|
|
make this worse, subtitles are often timed to appear a very small amount
|
|
|
|
before the associated video frame, so that seeking to the video frame
|
|
|
|
typically does not demux the subtitle at that position.
|
2013-04-10 19:06:00 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Enabling this option makes the demuxer start reading data a bit before the
|
|
|
|
seek target, so that subtitles appear correctly. Note that this makes
|
|
|
|
seeking slower, and is not guaranteed to always work. It only works if the
|
|
|
|
subtitle is close enough to the seek target.
|
2013-04-10 19:06:00 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Works with the internal Matroska demuxer only. Always enabled for absolute
|
|
|
|
and hr-seeks, and this option changes behavior with relative or imprecise
|
|
|
|
seeks only.
|
2013-09-22 00:40:29 +00:00
|
|
|
|
2014-11-14 22:52:47 +00:00
|
|
|
You can use the ``--demuxer-mkv-subtitle-preroll-secs`` option to specify
|
2015-06-17 17:37:25 +00:00
|
|
|
how much data the demuxer should pre-read at most in order to find subtitle
|
2014-11-14 22:52:47 +00:00
|
|
|
packets that may overlap. Setting this to 0 will effectively disable this
|
|
|
|
preroll mechanism. Setting a very large value can make seeking very slow,
|
|
|
|
and an extremely large value would completely reread the entire file from
|
|
|
|
start to seek target on every seek - seeking can become slower towards the
|
|
|
|
end of the file. The details are messy, and the value is actually rounded
|
|
|
|
down to the cluster with the previous video keyframe.
|
|
|
|
|
|
|
|
Some files, especially files muxed with newer mkvmerge versions, have
|
|
|
|
information embedded that can be used to determine what subtitle packets
|
|
|
|
overlap with a seek target. In these cases, mpv will reduce the amount
|
|
|
|
of data read to a minimum. (Although it will still read *all* data between
|
|
|
|
the cluster that contains the first wanted subtitle packet, and the seek
|
2015-12-27 00:01:25 +00:00
|
|
|
target.) If the ``index`` choice (which is the default) is specified, then
|
|
|
|
prerolling will be done only if this information is actually available. If
|
|
|
|
this method is used, the maximum amount of data to skip can be additionally
|
|
|
|
controlled by ``--demuxer-mkv-subtitle-preroll-secs-index`` (it still uses
|
|
|
|
the value of the option without ``-index`` if that is higher).
|
2014-11-14 22:52:47 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
See also ``--hr-seek-demuxer-offset`` option. This option can achieve a
|
|
|
|
similar effect, but only if hr-seek is active. It works with any demuxer,
|
|
|
|
but makes seeking much slower, as it has to decode audio and video data
|
|
|
|
instead of just skipping over it.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--mkv-subtitle-preroll`` is a deprecated alias.
|
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
|
|
|
|
2014-11-14 22:52:47 +00:00
|
|
|
``--demuxer-mkv-subtitle-preroll-secs=<value>``
|
|
|
|
See ``--demuxer-mkv-subtitle-preroll``.
|
|
|
|
|
2015-12-27 00:01:25 +00:00
|
|
|
``--demuxer-mkv-subtitle-preroll-secs-index=<value>``
|
|
|
|
See ``--demuxer-mkv-subtitle-preroll``.
|
|
|
|
|
2020-02-27 21:29:40 +00:00
|
|
|
``--demuxer-mkv-probe-start-time=<yes|no>``
|
|
|
|
Check the start time of Matroska files (default: yes). This simply reads the
|
|
|
|
first cluster timestamps and assumes it is the start time. Technically, this
|
|
|
|
also reads the first timestamp, which may increase latency by one frame
|
|
|
|
(which may be relevant for live streams).
|
|
|
|
|
2015-07-09 20:47:41 +00:00
|
|
|
``--demuxer-mkv-probe-video-duration=<yes|no|full>``
|
2014-11-18 22:07:20 +00:00
|
|
|
When opening the file, seek to the end of it, and check what timestamp the
|
|
|
|
last video packet has, and report that as file duration. This is strictly
|
|
|
|
for compatibility with Haali only. In this mode, it's possible that opening
|
2014-11-19 17:27:53 +00:00
|
|
|
will be slower (especially when playing over http), or that behavior with
|
2014-11-18 22:07:20 +00:00
|
|
|
broken files is much worse. So don't use this option.
|
|
|
|
|
2015-07-09 20:47:41 +00:00
|
|
|
The ``yes`` mode merely uses the index and reads a small number of blocks
|
|
|
|
from the end of the file. The ``full`` mode actually traverses the entire
|
|
|
|
file and can make a reliable estimate even without an index present (such
|
|
|
|
as partial files).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawaudio-channels=<value>``
|
|
|
|
Number of channels (or channel layout) if ``--demuxer=rawaudio`` is used
|
|
|
|
(default: stereo).
|
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
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawaudio-format=<value>``
|
|
|
|
Sample format for ``--demuxer=rawaudio`` (default: s16le).
|
2014-09-24 20:55:50 +00:00
|
|
|
Use ``--demuxer-rawaudio-format=help`` to get a list of all formats.
|
2014-06-01 16:25:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawaudio-rate=<value>``
|
2014-09-01 02:25:57 +00:00
|
|
|
Sample rate for ``--demuxer=rawaudio`` (default: 44 kHz).
|
2014-06-01 16:25:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-fps=<value>``
|
|
|
|
Rate in frames per second for ``--demuxer=rawvideo`` (default: 25.0).
|
2014-06-01 16:25:21 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-w=<value>``, ``--demuxer-rawvideo-h=<value>``
|
|
|
|
Image dimension in pixels for ``--demuxer=rawvideo``.
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Play a raw YUV sample::
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
mpv sample-720x576.yuv --demuxer=rawvideo \
|
2015-05-06 19:13:55 +00:00
|
|
|
--demuxer-rawvideo-w=720 --demuxer-rawvideo-h=576
|
2013-02-17 15:35:44 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-format=<value>``
|
2014-09-01 02:25:57 +00:00
|
|
|
Color space (fourcc) in hex or string for ``--demuxer=rawvideo``
|
2014-07-31 14:32:37 +00:00
|
|
|
(default: ``YV12``).
|
2012-08-02 18:44:28 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-mp-format=<value>``
|
2014-09-01 02:25:57 +00:00
|
|
|
Color space by internal video format for ``--demuxer=rawvideo``. Use
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-mp-format=help`` for a list of possible formats.
|
2012-08-02 18:44:28 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-codec=<value>``
|
|
|
|
Set the video codec instead of selecting the rawvideo codec when using
|
|
|
|
``--demuxer=rawvideo``. This uses the same values as codec names in
|
|
|
|
``--vd`` (but it does not accept decoder names).
|
2012-08-02 18:44:28 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-rawvideo-size=<value>``
|
|
|
|
Frame size in bytes when using ``--demuxer=rawvideo``.
|
2012-08-02 18:44:28 +00:00
|
|
|
|
2019-04-07 13:10:52 +00:00
|
|
|
``--demuxer-cue-codepage=<codepage>``
|
|
|
|
Specify the CUE sheet codepage. (See ``--sub-codepage`` for details.)
|
|
|
|
|
2018-01-24 00:32:56 +00:00
|
|
|
``--demuxer-max-bytes=<bytesize>``
|
2015-08-05 21:41:29 +00:00
|
|
|
This controls how much the demuxer is allowed to buffer ahead. The demuxer
|
|
|
|
will normally try to read ahead as much as necessary, or as much is
|
2017-04-14 17:19:44 +00:00
|
|
|
requested with ``--demuxer-readahead-secs``. The option can be used to
|
|
|
|
restrict the maximum readahead. This limits excessive readahead in case of
|
|
|
|
broken files or desynced playback. The demuxer will stop reading additional
|
|
|
|
packets as soon as one of the limits is reached. (The limits still can be
|
|
|
|
slightly overstepped due to technical reasons.)
|
2015-08-05 21:41:29 +00:00
|
|
|
|
2016-07-09 13:48:27 +00:00
|
|
|
Set these limits higher if you get a packet queue overflow warning, and
|
2015-08-05 21:41:29 +00:00
|
|
|
you think normal playback would be possible with a larger packet queue.
|
|
|
|
|
2018-01-24 00:32:56 +00:00
|
|
|
See ``--list-options`` for defaults and value range. ``<bytesize>`` options
|
|
|
|
accept suffixes such as ``KiB`` and ``MiB``.
|
2015-08-05 21:41:29 +00:00
|
|
|
|
2018-01-24 00:32:56 +00:00
|
|
|
``--demuxer-max-back-bytes=<bytesize>``
|
2017-10-21 17:26:33 +00:00
|
|
|
This controls how much past data the demuxer is allowed to preserve. This
|
2020-06-23 18:46:52 +00:00
|
|
|
is useful only if the cache is enabled.
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
Unlike the forward cache, there is no control how many seconds are actually
|
|
|
|
cached - it will simply use as much memory this option allows. Setting this
|
2017-11-10 11:37:19 +00:00
|
|
|
option to 0 will strictly disable any back buffer, but this will lead to
|
|
|
|
the situation that the forward seek range starts after the current playback
|
|
|
|
position (as it removes past packets that are seek points).
|
2017-10-21 17:26:33 +00:00
|
|
|
|
demux: allow backward cache to use unused forward cache
Until now, the following could happen: if you set a 1GB forward cache,
and a 1GB backward cache, and you opened a 2GB file, it would prune away
the data cached at the start as playback progressed past the 50% mark.
With this commit, nothing gets pruned, because the total memory usage
will still be 2GB, which equals the total allowed memory usage of 1GB +
1GB.
There are no explicit buffers (every packet is malloc'ed and put into a
linked list), so it all comes down to buffer size computations. Both
reader and prune code use these sizes to decide whether a new packet
should be read / an old packet discarded. So just add the remaining free
"space" from the forward buffer to the available backward buffer. Still
respect if the back buffer is set to 0 (e.g. unseekable cache where it
doesn't make sense to keep old packets).
We need to make sure that the forward buffer can always append, as long
as the forward buffer doesn't exceed the set size, even if the back
buffer "borrows" free space from it. For this reason, always keep 1 byte
free, which is enough to allow it to read a new packet. Also, it's now
necessary to call pruning when adding a packet, to get back "borrowed"
space that may need to be free'd up after a packet has been added.
I refrained from doing the same for forward caching (making forward
cache use unused backward cache). This would work, but has a
disadvantage. Assume playback starts paused. Demuxing will stop once the
total allowed low total cache size is reached. When unpausing, the
forward buffer will slowly move to the back buffer. That alone will not
change the total buffer size, so demuxing remains stopped. Playback
would need to pass over data of the size of the back buffer until
demuxing resume; consider this unacceptable. Live playback would break
(or rather, would not resume in unintuitive ways), even normal streaming
may break if the server invalidates the URL due to inactivity. As an
alternative implementation, you could prune the back buffer immediately,
so the forward buffer can grow, but then the back buffer would never
grow. Also makes no sense.
As far as the user interface is concerned, the idea is that the limits
on their own aren't really meaningful, the purpose is merely to vaguely
restrict the cache memory usage. There could be just a single option to
set the total allowed memory usage, but the separate backward cache
controls the default ratio of backward/forward cache sizes. From that
perspective, it doesn't matter if the backward cache uses more of the
total buffer than assigned, if the forward buffer is complete.
2019-07-06 22:57:39 +00:00
|
|
|
If the end of the file is reached, the remaining unused forward buffer space
|
2020-02-07 14:56:52 +00:00
|
|
|
is "donated" to the backbuffer (unless the backbuffer size is set to 0, or
|
|
|
|
``--demuxer-donate-buffer`` is set to ``no``).
|
demux: allow backward cache to use unused forward cache
Until now, the following could happen: if you set a 1GB forward cache,
and a 1GB backward cache, and you opened a 2GB file, it would prune away
the data cached at the start as playback progressed past the 50% mark.
With this commit, nothing gets pruned, because the total memory usage
will still be 2GB, which equals the total allowed memory usage of 1GB +
1GB.
There are no explicit buffers (every packet is malloc'ed and put into a
linked list), so it all comes down to buffer size computations. Both
reader and prune code use these sizes to decide whether a new packet
should be read / an old packet discarded. So just add the remaining free
"space" from the forward buffer to the available backward buffer. Still
respect if the back buffer is set to 0 (e.g. unseekable cache where it
doesn't make sense to keep old packets).
We need to make sure that the forward buffer can always append, as long
as the forward buffer doesn't exceed the set size, even if the back
buffer "borrows" free space from it. For this reason, always keep 1 byte
free, which is enough to allow it to read a new packet. Also, it's now
necessary to call pruning when adding a packet, to get back "borrowed"
space that may need to be free'd up after a packet has been added.
I refrained from doing the same for forward caching (making forward
cache use unused backward cache). This would work, but has a
disadvantage. Assume playback starts paused. Demuxing will stop once the
total allowed low total cache size is reached. When unpausing, the
forward buffer will slowly move to the back buffer. That alone will not
change the total buffer size, so demuxing remains stopped. Playback
would need to pass over data of the size of the back buffer until
demuxing resume; consider this unacceptable. Live playback would break
(or rather, would not resume in unintuitive ways), even normal streaming
may break if the server invalidates the URL due to inactivity. As an
alternative implementation, you could prune the back buffer immediately,
so the forward buffer can grow, but then the back buffer would never
grow. Also makes no sense.
As far as the user interface is concerned, the idea is that the limits
on their own aren't really meaningful, the purpose is merely to vaguely
restrict the cache memory usage. There could be just a single option to
set the total allowed memory usage, but the separate backward cache
controls the default ratio of backward/forward cache sizes. From that
perspective, it doesn't matter if the backward cache uses more of the
total buffer than assigned, if the forward buffer is complete.
2019-07-06 22:57:39 +00:00
|
|
|
This still limits the total cache usage to the sum of the forward and
|
|
|
|
backward cache, and effectively makes better use of the total allowed memory
|
|
|
|
budget. (The opposite does not happen: free backward buffer is never
|
|
|
|
"donated" to the forward buffer.)
|
|
|
|
|
2017-10-21 17:26:33 +00:00
|
|
|
Keep in mind that other buffers in the player (like decoders) will cause the
|
|
|
|
demuxer to cache "future" frames in the back buffer, which can skew the
|
|
|
|
impression about how much data the backbuffer contains.
|
|
|
|
|
|
|
|
See ``--list-options`` for defaults and value range.
|
|
|
|
|
2020-02-07 14:56:52 +00:00
|
|
|
``--demuxer-donate-buffer=<yes|no>``
|
|
|
|
Whether to let the back buffer use part of the forward buffer (default: yes).
|
|
|
|
If set to ``yes``, the "donation" behavior described in the option
|
|
|
|
description for ``--demuxer-max-back-bytes`` is enabled. This means the
|
|
|
|
back buffer may use up memory up to the sum of the forward and back buffer
|
|
|
|
options, minus the active size of the forward buffer. If set to ``no``, the
|
|
|
|
options strictly limit the forward and back buffer sizes separately.
|
|
|
|
|
|
|
|
Note that if the end of the file is reached, the buffered data stays the
|
|
|
|
same, even if you seek back within the cache. This is because the back
|
|
|
|
buffer is only reduced when new data is read.
|
|
|
|
|
2017-11-10 15:30:43 +00:00
|
|
|
``--demuxer-seekable-cache=<yes|no|auto>``
|
2020-06-23 18:46:52 +00:00
|
|
|
Debugging option to control whether seeking can use the demuxer cache
|
|
|
|
(default: auto). Normally you don't ever need to set this; the default
|
|
|
|
``auto`` does the right thing and enables cache seeking it if ``--cache``
|
|
|
|
is set to ``yes`` (or is implied ``yes`` if ``--cache=auto``).
|
|
|
|
|
|
|
|
If enabled, short seek offsets will not trigger a low level demuxer seek
|
2017-10-21 17:26:33 +00:00
|
|
|
(which means for example that slow network round trips or FFmpeg seek bugs
|
|
|
|
can be avoided). If a seek cannot happen within the cached range, a low
|
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
|
|
|
level seek will be triggered. Seeking outside of the cache will start a new
|
|
|
|
cached range, but can discard the old cache range if the demuxer exhibits
|
|
|
|
certain unsupported behavior.
|
2017-10-21 17:26:33 +00:00
|
|
|
|
2017-11-10 15:30:43 +00:00
|
|
|
The special value ``auto`` means ``yes`` in the same situation as
|
|
|
|
``--cache-secs`` is used (i.e. when the stream appears to be a network
|
|
|
|
stream or the stream cache is enabled).
|
|
|
|
|
demux: simplify some internals, stop trying to read packets after EOF
Remove some redundant fields that controlled or indicated whether the
demuxer was/could/should prefetch. Redefine how the eof/reading fields
work.
The in->eof field is now always valid, instead of weirdly being reset to
false in random situations. The in->reading field now corresponds to
whether the demuxer thread is working at all, and is reset if it stops
doing anything.
Also, I always found it stupid that dequeue_packet() forced the demuxer
thread to retry reading if it was EOF. This makes little sense, but was
probably added for files that are being appended to (running downloads).
It makes no sense, because if the cache really tried to read until file
EOF, it would encounter partial packets and throw errors, so all is lost
anyway. Plus stream_file now handles this better. So stop this behavior,
but add a temporary option that enables the old behavior.
I think checking for ds->eager when enabling prefetching never really
made sense (could be debated, but no, not really). On the other hand,
the change above exposed a missing wakeup in the backward demuxing code.
Some chances of regressions that could make it stuck in certain states
or so, or incorrect demuxer cache state reporting to the player
frontend.
2020-02-27 21:16:30 +00:00
|
|
|
``--demuxer-force-retry-on-eof=<yes|no>``
|
|
|
|
Whether to keep retrying making the demuxer thread read more packets each
|
|
|
|
time the decoder dequeues a packet, even if the end of the file was reached
|
|
|
|
(default: no). This does not really make sense, but was the default behavior
|
|
|
|
in mpv 0.32.0 and earlier. This option will be silently removed after a
|
|
|
|
while, and exists only to restore the old behavior for testing, in case this
|
|
|
|
was actually needed somewhere. This does _not_ help with files that are
|
|
|
|
being appended to (in these cases use ``appending://``, or disable the
|
|
|
|
cache).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--demuxer-thread=<yes|no>``
|
|
|
|
Run the demuxer in a separate thread, and let it prefetch a certain amount
|
2018-05-19 15:26:55 +00:00
|
|
|
of packets (default: yes). Having this enabled leads to smoother playback,
|
|
|
|
enables features like prefetching, and prevents that stuck network freezes
|
|
|
|
the player. On the other hand, it can add overhead, or the background
|
|
|
|
prefetching can hog CPU resources.
|
|
|
|
|
|
|
|
Disabling this option is not recommended. Use it for debugging only.
|
2012-08-02 18:44:28 +00:00
|
|
|
|
player: make playback termination asynchronous
Until now, stopping playback aborted the demuxer and I/O layer violently
by signaling mp_cancel (bound to libavformat's AVIOInterruptCB
mechanism). Change it to try closing them gracefully.
The main purpose is to silence those libavformat errors that happen when
you request termination. Most of libavformat barely cares about the
termination mechanism (AVIOInterruptCB), and essentially it's like the
network connection is abruptly severed, or file I/O suddenly returns I/O
errors. There were issues with dumb TLS warnings, parsers complaining
about incomplete data, and some special protocols that require server
communication to gracefully disconnect.
We still want to abort it forcefully if it refuses to terminate on its
own, so a timeout is required. Users can set the timeout to 0, which
should give them the old behavior.
This also removes the old mechanism that treats certain commands (like
"quit") specially, and tries to terminate the demuxers even if the core
is currently frozen. This is for situations where the core synchronized
to the demuxer or stream layer while network is unresponsive. This in
turn can only happen due to the "program" or "cache-size" properties in
the current code (see one of the previous commits). Also, the old
mechanism doesn't fit particularly well with the new one. We wouldn't
want to abort playback immediately on a "quit" command - the new code is
all about giving it a chance to end it gracefully. We'd need some sort
of watchdog thread or something equally complicated to handle this. So
just remove it.
The change in osd.c is to prevent that it clears the status line while
waiting for termination. The normal status line code doesn't output
anything useful at this point, and the code path taken clears it, both
of which is an annoying behavior change, so just let it show the old
one.
2018-05-19 16:41:13 +00:00
|
|
|
``--demuxer-termination-timeout=<seconds>``
|
|
|
|
Number of seconds the player should wait to shutdown the demuxer (default:
|
|
|
|
0.1). The player will wait up to this much time before it closes the
|
|
|
|
stream layer forcefully. Forceful closing usually means the network I/O is
|
|
|
|
given no chance to close its connections gracefully (of course the OS can
|
|
|
|
still close TCP connections properly), and might result in annoying messages
|
|
|
|
being logged, and in some cases, confused remote servers.
|
|
|
|
|
|
|
|
This timeout is usually only applied when loading has finished properly. If
|
|
|
|
loading is aborted by the user, or in some corner cases like removing
|
|
|
|
external tracks sourced from network during playback, forceful closing is
|
|
|
|
always used.
|
|
|
|
|
2014-10-26 11:02:00 +00:00
|
|
|
``--demuxer-readahead-secs=<seconds>``
|
2014-08-16 15:07:36 +00:00
|
|
|
If ``--demuxer-thread`` is enabled, this controls how much the demuxer
|
2015-02-27 11:44:40 +00:00
|
|
|
should buffer ahead in seconds (default: 1). As long as no packet has
|
2014-08-16 15:07:36 +00:00
|
|
|
a timestamp difference higher than the readahead amount relative to the
|
|
|
|
last packet returned to the decoder, the demuxer keeps reading.
|
|
|
|
|
2020-03-05 20:53:51 +00:00
|
|
|
Note that enabling the cache (such as ``--cache=yes``, or if the input
|
|
|
|
is considered a network stream, and ``--cache=auto`` is used), this option
|
|
|
|
is mostly ignored. (``--cache-secs`` will override this. Technically, the
|
|
|
|
maximum of both options is used.)
|
|
|
|
|
|
|
|
The main purpose of this option is to limit the readhead for local playback,
|
|
|
|
since a large readahead value is not overly useful in this case.
|
2014-12-11 22:56:20 +00:00
|
|
|
|
2014-08-16 15:07:36 +00:00
|
|
|
(This value tends to be fuzzy, because many file formats don't store linear
|
|
|
|
timestamps.)
|
|
|
|
|
2022-12-29 06:01:07 +00:00
|
|
|
``--demuxer-hysteresis-secs=<seconds>``
|
|
|
|
Once the ``--demuxer-max-bytes`` limit is reached, this value can be used
|
|
|
|
to specify a hysteresis before the demuxer will buffer ahead again. This
|
|
|
|
specifies the maximum number of seconds from the current playback position
|
|
|
|
that needs to be remaining in the cache before the demuxer will continue
|
|
|
|
buffering ahead.
|
|
|
|
|
|
|
|
For example, with a value of 10 seconds specified, the demuxer will buffer
|
|
|
|
ahead up to ``--demuxer-max-bytes`` and won't start buffering ahead again
|
|
|
|
until there is only 10 seconds of content left in the cache. When the
|
|
|
|
demuxer starts buffering ahead again, it will buffer ahead up to
|
|
|
|
``--demuxer-max-bytes`` and stop until there's only 10 seconds of content
|
|
|
|
remaining in the cache, and so on.
|
|
|
|
|
|
|
|
This can provide significant power savings and reduce load by making the
|
|
|
|
demuxer only buffer ahead in chunks at a time rather than buffering ahead
|
|
|
|
nonstop to keep the cache filled.
|
|
|
|
|
|
|
|
If you want to save power and reduce load, configure this to a small number
|
|
|
|
that's much lower than ``--cache-secs`` or ``--demuxer-readahead-secs``.
|
|
|
|
If it takes a long time to buffer anything at all for a given stream (like
|
|
|
|
when reading from a very slow disk is involved), then the hysteresis value
|
|
|
|
should be larger to compensate.
|
|
|
|
|
|
|
|
The default value is 0 seconds, which disables the caching hysteresis. A
|
|
|
|
value of 10 seconds probably works well for most usecases.
|
|
|
|
|
2017-01-18 18:02:50 +00:00
|
|
|
``--prefetch-playlist=<yes|no>``
|
|
|
|
Prefetch next playlist entry while playback of the current entry is ending
|
2020-12-06 19:49:34 +00:00
|
|
|
(default: no).
|
|
|
|
|
|
|
|
This does not prefill the cache with the video data of the next URL.
|
|
|
|
Prefetching video data is supported only for the current playlist entry,
|
|
|
|
and depends on the demuxer cache settings (on by default). This merely
|
|
|
|
opens the URL of the next playlist entry as soon the current URL is fully
|
|
|
|
read.
|
2017-01-18 18:02:50 +00:00
|
|
|
|
|
|
|
This does **not** work with URLs resolved by the ``youtube-dl`` wrapper,
|
|
|
|
and it won't.
|
|
|
|
|
|
|
|
This can give subtly wrong results if per-file options are used, or if
|
|
|
|
options are changed in the time window between prefetching start and next
|
|
|
|
file played.
|
|
|
|
|
|
|
|
This can occasionally make wrong prefetching decisions. For example, it
|
|
|
|
can't predict whether you go backwards in the playlist, and assumes you
|
|
|
|
won't edit the playlist.
|
|
|
|
|
|
|
|
Highly experimental.
|
|
|
|
|
2015-07-08 20:04:35 +00:00
|
|
|
``--force-seekable=<yes|no>``
|
|
|
|
If the player thinks that the media is not seekable (e.g. playing from a
|
2016-07-09 13:48:27 +00:00
|
|
|
pipe, or it's an http stream with a server that doesn't support range
|
2015-07-08 20:04:35 +00:00
|
|
|
requests), seeking will be disabled. This option can forcibly enable it.
|
|
|
|
For seeks within the cache, there's a good chance of success.
|
2012-08-02 18:44:28 +00:00
|
|
|
|
2019-05-16 14:29:45 +00:00
|
|
|
``--demuxer-cache-wait=<yes|no>``
|
|
|
|
Before starting playback, read data until either the end of the file was
|
|
|
|
reached, or the demuxer cache has reached maximum capacity. Only once this
|
|
|
|
is done, playback starts. This intentionally happens before the initial
|
|
|
|
seek triggered with ``--start``. This does not change any runtime behavior
|
|
|
|
after the initial caching. This option is useless if the file cannot be
|
|
|
|
cached completely.
|
|
|
|
|
2020-01-04 18:53:57 +00:00
|
|
|
``--rar-list-all-volumes=<yes|no>``
|
|
|
|
When opening multi-volume rar files, open all volumes to create a full list
|
|
|
|
of contained files (default: no). If disabled, only the archive entries
|
|
|
|
whose headers are located within the first volume are listed (and thus
|
|
|
|
played when opening a .rar file with mpv). Doing so speeds up opening, and
|
|
|
|
the typical idiotic use-case of playing uncompressed multi-volume rar files
|
|
|
|
that contain a single media file is made faster.
|
|
|
|
|
|
|
|
Opening is still slow, because for unknown, idiotic, and unnecessary reasons
|
|
|
|
libarchive opens all volumes anyway when playing the main file, even though
|
|
|
|
mpv iterated no archive entries yet.
|
|
|
|
|
2023-08-29 06:19:19 +00:00
|
|
|
``--directory-mode=<lazy|recursive|ignore>``
|
|
|
|
When opening a directory, open subdirectories lazily, recursively or not at
|
|
|
|
all (default: lazy).
|
2023-02-11 20:08:38 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Input
|
|
|
|
-----
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--native-keyrepeat``
|
|
|
|
Use system settings for keyrepeat delay and rate, instead of
|
|
|
|
``--input-ar-delay`` and ``--input-ar-rate``. (Whether this applies
|
|
|
|
depends on the VO backend and how it handles keyboard input. Does not
|
|
|
|
apply to terminal input.)
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-ar-delay``
|
|
|
|
Delay in milliseconds before we start to autorepeat a key (0 to disable).
|
2013-03-25 19:32:29 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-ar-rate``
|
|
|
|
Number of key presses to generate per second on autorepeat.
|
2013-03-25 19:32:29 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-conf=<filename>``
|
2014-10-03 09:18:48 +00:00
|
|
|
Specify input configuration file other than the default location in the mpv
|
|
|
|
configuration directory (usually ``~/.config/mpv/input.conf``).
|
2012-08-02 18:44:28 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--no-input-default-bindings``
|
2021-10-07 18:40:20 +00:00
|
|
|
Disable default-level ("weak") key bindings. These are bindings which config
|
|
|
|
files like ``input.conf`` can override. It currently affects the builtin key
|
|
|
|
bindings, and keys which scripts bind using ``mp.add_key_binding`` (but not
|
|
|
|
``mp.add_forced_key_binding`` because this overrides ``input.conf``).
|
2013-12-24 16:46:14 +00:00
|
|
|
|
input: new option: --no-input-builtin-bindings
This is similar to [no-]input-default-bindings, but affects only
builtin bindings (while input-default-bindings affects anything which
config files can override, like scripting mp.add_key_binding).
Arguably, this is what input-default-binding should have always done,
however, it does not.
The reason we add a new option rather than repurpose/modify the
existing option is that it behaves differently enough to raise
concerns that it will break some use cases for existing users:
- The new option is only applied once on startup, while
input-default-bindings can be modified effectively at runtime.
- They affects different sets of bindings, and it's possible that
the set of input-default-bindings is useful enough to keep.
Implementation-wise, both options are trivial, so keeping one or the
other or both doesn't affect code complexity.
It could be argued that it would be useful to make the new option
also effective for runtime changes, however, this opens a can of
worms of how the bindings are stored beyond the initial setup.
TL;DR: it's impossible to differentiate correctly at runtime between
builtin bindings, and those added with mp.add_key_bindings.
The gist is that technically mpv needs/uses two binding "classes":
- weak/builtin bindings - lower priority than config files.
- "user" bindings - config files and "forced" runtime bindings.
input-default-bindings affects the first class trivially, but
input-builtin-bindings would not be able split this class further
at runtime without meaningful changes to a lot of delicate code.
So a new option it is. It should be useful to some libmpv clients
(players) which want to disable mpv's builtin bindings without
breaking mp.add_key_bindings for scripts.
Fixes #8809
(again. the previous fix 8edfe70b only improved the docs, while
now we're actually making the requested behavior possible)
2021-10-06 23:18:19 +00:00
|
|
|
``--no-input-builtin-bindings``
|
|
|
|
Disable loading of built-in key bindings during start-up. This option is
|
|
|
|
applied only during (lib)mpv initialization, and if used then it will not
|
|
|
|
be not possible to enable them later. May be useful to libmpv clients.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-cmdlist``
|
|
|
|
Prints all commands that can be bound to keys.
|
2013-12-24 16:46:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-doubleclick-time=<milliseconds>``
|
|
|
|
Time in milliseconds to recognize two consecutive button presses as a
|
|
|
|
double-click (default: 300).
|
2013-12-24 16:46:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-keylist``
|
|
|
|
Prints all keys that can be bound to commands.
|
2013-12-24 16:46:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-key-fifo-size=<2-65000>``
|
|
|
|
Specify the size of the FIFO that buffers key events (default: 7). If it
|
2015-12-19 08:26:27 +00:00
|
|
|
is too small, some events may be lost. The main disadvantage of setting it
|
2014-07-31 14:32:37 +00:00
|
|
|
to a very large value is that if you hold down a key triggering some
|
|
|
|
particularly slow command then the player may be unresponsive while it
|
|
|
|
processes all the queued commands.
|
2013-12-24 16:46:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-test``
|
|
|
|
Input test mode. Instead of executing commands on key presses, mpv
|
|
|
|
will show the keys and the bound commands on the OSD. Has to be used
|
|
|
|
with a dummy video, and the normal ways to quit the player will not
|
|
|
|
work (key bindings that normally quit will be shown on OSD only, just
|
|
|
|
like any other binding). See `INPUT.CONF`_.
|
2013-12-24 16:46:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-terminal``, ``--no-input-terminal``
|
|
|
|
``--no-input-terminal`` prevents the player from reading key events from
|
|
|
|
standard input. Useful when reading data from standard input. This is
|
|
|
|
automatically enabled when ``-`` is found on the command line. There are
|
|
|
|
situations where you have to set it manually, e.g. if you open
|
|
|
|
``/dev/stdin`` (or the equivalent on your system), use stdin in a playlist
|
2016-08-11 20:29:18 +00:00
|
|
|
or intend to read from stdin later on via the loadfile or loadlist input
|
2014-07-31 14:32:37 +00:00
|
|
|
commands.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-03-23 12:01:57 +00:00
|
|
|
``--input-ipc-server=<filename>``
|
2014-10-14 20:35:37 +00:00
|
|
|
Enable the IPC support and create the listening socket at the given path.
|
|
|
|
|
2016-03-23 12:01:57 +00:00
|
|
|
On Linux and Unix, the given path is a regular filesystem path. On Windows,
|
|
|
|
named pipes are used, so the path refers to the pipe namespace
|
|
|
|
(``\\.\pipe\<name>``). If the ``\\.\pipe\`` prefix is missing, mpv will add
|
|
|
|
it automatically before creating the pipe, so
|
|
|
|
``--input-ipc-server=/tmp/mpv-socket`` and
|
|
|
|
``--input-ipc-server=\\.\pipe\tmp\mpv-socket`` are equivalent for IPC on
|
|
|
|
Windows.
|
2014-10-19 19:38:43 +00:00
|
|
|
|
2016-03-23 12:01:57 +00:00
|
|
|
See `JSON IPC`_ for details.
|
2014-10-19 20:35:45 +00:00
|
|
|
|
2020-04-08 23:05:51 +00:00
|
|
|
``--input-ipc-client=fd://<N>``
|
|
|
|
Connect a single IPC client to the given FD. This is somewhat similar to
|
|
|
|
``--input-ipc-server``, except no socket is created, and instead the passed
|
|
|
|
FD is treated like a socket connection received from ``accept()``. In
|
|
|
|
practice, you could pass either a FD created by ``socketpair()``, or a pipe.
|
|
|
|
In both cases, you must sure the FD is actually inherited by mpv (do not
|
|
|
|
set the POSIX ``CLOEXEC`` flag).
|
|
|
|
|
2020-05-14 19:40:43 +00:00
|
|
|
The player quits when the connection is closed.
|
|
|
|
|
2020-04-08 23:05:51 +00:00
|
|
|
This is somewhat similar to the removed ``--input-file`` option, except it
|
|
|
|
supports only integer FDs, and cannot open actual paths.
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
``--input-ipc-client=fd://123``
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Does not and will not work on Windows.
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
Writing to the ``input-ipc-server`` option at runtime will start another
|
|
|
|
instance of an IPC client handler for the ``input-ipc-client`` option,
|
|
|
|
because initialization is bundled, and this thing is stupid. This is a
|
|
|
|
bug. Writing to ``input-ipc-client`` at runtime will start another IPC
|
|
|
|
client handler for the new value, without stopping the old one, even if
|
|
|
|
the FD value is the same (but the string is different e.g. due to
|
|
|
|
whitespace). This is not a bug.
|
|
|
|
|
2019-10-22 14:41:19 +00:00
|
|
|
``--input-gamepad=<yes|no>``
|
2019-10-25 19:54:35 +00:00
|
|
|
Enable/disable SDL2 Gamepad support. Disabled by default.
|
2019-10-22 14:41:19 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-cursor``, ``--no-input-cursor``
|
|
|
|
Permit mpv to receive pointer events reported by the video output
|
|
|
|
driver. Necessary to use the OSC, or to select the buttons in DVD menus.
|
|
|
|
Support depends on the VO in use.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2022-05-12 21:26:49 +00:00
|
|
|
``--input-cursor-passthrough``, ``--no-input-cursor-passthrough``
|
|
|
|
(X11 and Wayland only)
|
|
|
|
Tell the backend windowing system to allow pointer events to passthrough
|
|
|
|
the mpv window. This allows windows under mpv to instead receive pointer
|
|
|
|
events as if the mpv window was never there.
|
|
|
|
|
2014-10-09 19:02:47 +00:00
|
|
|
``--input-media-keys=<yes|no>``
|
2021-08-09 12:46:58 +00:00
|
|
|
On systems where mpv can choose between receiving media keys or letting
|
|
|
|
the system handle them - this option controls whether mpv should receive
|
|
|
|
them.
|
|
|
|
|
|
|
|
Default: yes (except for libmpv). macOS and Windows only, because elsewhere
|
|
|
|
mpv doesn't have a choice - the system decides whether to send media keys
|
|
|
|
to mpv. For instance, on X11 or Wayland, system-wide media keys are not
|
|
|
|
implemented. Whether media keys work when the mpv window is focused is
|
|
|
|
implementation-defined.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--input-right-alt-gr``, ``--no-input-right-alt-gr``
|
|
|
|
(Cocoa and Windows only)
|
|
|
|
Use the right Alt key as Alt Gr to produce special characters. If disabled,
|
|
|
|
count the right Alt as an Alt modifier key. Enabled by default.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-10-09 16:28:37 +00:00
|
|
|
``--input-vo-keyboard=<yes|no>``
|
|
|
|
Disable all keyboard input on for VOs which can't participate in proper
|
2015-01-12 11:08:48 +00:00
|
|
|
keyboard input dispatching. May not affect all VOs. Generally useful for
|
client API, X11: change default keyboard input handling again
Commit 64b7811c tried to do the "right thing" with respect to whether
keyboard input should be enabled or not. It turns out that X11 does
something stupid by design. All modern toolkits work around this native
X11 behavior, but embedding breaks these workarounds.
The only way to handle this correctly is the XEmbed protocol. It needs
to be supported by the toolkit, and probably also some mpv support. But
Qt has inconsistent support for it. In Qt 4, a X11 specific embedding
widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently
supports it via QWindow, but if it really does, I couldn't get it to
work.
So add a hack instead. The new --input-x11-keyboard option controls
whether mpv should enable keyboard input on the X11 window or not. In
the command line player, it's enabled by default, but in libmpv it's
disabled.
This hack has the same problem as all previous embedding had: move the
mouse outside of the window, and you don't get keyboard input anymore.
Likewise, mpv will steal all keyboard input from the parent application
as long as the mouse is inside of the mpv window.
Also see issue #1090.
2014-09-28 18:11:00 +00:00
|
|
|
embedding only.
|
|
|
|
|
|
|
|
On X11, a sub-window with input enabled grabs all keyboard input as long
|
|
|
|
as it is 1. a child of a focused window, and 2. the mouse is inside of
|
2015-12-19 08:26:27 +00:00
|
|
|
the sub-window. It can steal away all keyboard input from the
|
client API, X11: change default keyboard input handling again
Commit 64b7811c tried to do the "right thing" with respect to whether
keyboard input should be enabled or not. It turns out that X11 does
something stupid by design. All modern toolkits work around this native
X11 behavior, but embedding breaks these workarounds.
The only way to handle this correctly is the XEmbed protocol. It needs
to be supported by the toolkit, and probably also some mpv support. But
Qt has inconsistent support for it. In Qt 4, a X11 specific embedding
widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently
supports it via QWindow, but if it really does, I couldn't get it to
work.
So add a hack instead. The new --input-x11-keyboard option controls
whether mpv should enable keyboard input on the X11 window or not. In
the command line player, it's enabled by default, but in libmpv it's
disabled.
This hack has the same problem as all previous embedding had: move the
mouse outside of the window, and you don't get keyboard input anymore.
Likewise, mpv will steal all keyboard input from the parent application
as long as the mouse is inside of the mpv window.
Also see issue #1090.
2014-09-28 18:11:00 +00:00
|
|
|
application embedding the mpv window, and on the other hand, the mpv
|
|
|
|
window will receive no input if the mouse is outside of the mpv window,
|
|
|
|
even though mpv has focus. Modern toolkits work around this weird X11
|
|
|
|
behavior, but naively embedding foreign windows breaks it.
|
|
|
|
|
|
|
|
The only way to handle this reasonably is using the XEmbed protocol, which
|
2015-01-12 11:08:48 +00:00
|
|
|
was designed to solve these problems. GTK provides ``GtkSocket``, which
|
|
|
|
supports XEmbed. Qt doesn't seem to provide anything working in newer
|
|
|
|
versions.
|
|
|
|
|
|
|
|
If the embedder supports XEmbed, input should work with default settings
|
|
|
|
and with this option disabled. Note that ``input-default-bindings`` is
|
|
|
|
disabled by default in libmpv as well - it should be enabled if you want
|
|
|
|
the mpv default key bindings.
|
2013-09-10 13:09:24 +00:00
|
|
|
|
2014-10-09 16:28:37 +00:00
|
|
|
(This option was renamed from ``--input-x11-keyboard``.)
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
OSD
|
|
|
|
---
|
2013-09-07 06:53:04 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osc``, ``--no-osc``
|
|
|
|
Whether to load the on-screen-controller (default: yes).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--no-osd-bar``, ``--osd-bar``
|
2018-01-06 02:52:04 +00:00
|
|
|
Disable display of the OSD bar.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
You can configure this on a per-command basis in input.conf using ``osd-``
|
2018-01-21 23:36:08 +00:00
|
|
|
prefixes, see ``Input Command Prefixes``. If you want to disable the OSD
|
2014-07-31 14:32:37 +00:00
|
|
|
completely, use ``--osd-level=0``.
|
2012-11-15 17:49:17 +00:00
|
|
|
|
2018-01-21 23:36:08 +00:00
|
|
|
``--osd-on-seek=<no,bar,msg,msg-bar>``
|
|
|
|
Set what is displayed on the OSD during seeks. The default is ``bar``.
|
|
|
|
|
|
|
|
You can configure this on a per-command basis in input.conf using ``osd-``
|
|
|
|
prefixes, see ``Input Command Prefixes``.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-duration=<time>``
|
|
|
|
Set the duration of the OSD messages in ms (default: 1000).
|
2012-11-18 17:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-font=<name>``
|
|
|
|
Specify font to use for OSD. The default is ``sans-serif``.
|
2012-11-15 17:49:17 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
- ``--osd-font='Bitstream Vera Sans'``
|
2017-06-21 13:47:36 +00:00
|
|
|
- ``--osd-font='Comic Sans MS'``
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-font-size=<size>``
|
|
|
|
Specify the OSD font size. See ``--sub-font-size`` for details.
|
2013-11-01 15:02:47 +00:00
|
|
|
|
2014-10-23 12:29:16 +00:00
|
|
|
Default: 55.
|
2012-10-23 23:06:00 +00:00
|
|
|
|
2014-09-17 23:19:27 +00:00
|
|
|
``--osd-msg1=<string>``
|
|
|
|
Show this string as message on OSD with OSD level 1 (visible by default).
|
2018-01-07 02:22:57 +00:00
|
|
|
The message will be visible by default, and as long as no other message
|
2014-09-17 23:19:27 +00:00
|
|
|
covers it, and the OSD level isn't changed (see ``--osd-level``).
|
|
|
|
Expands properties; see `Property Expansion`_.
|
|
|
|
|
|
|
|
``--osd-msg2=<string>``
|
2018-01-07 02:22:57 +00:00
|
|
|
Similar to ``--osd-msg1``, but for OSD level 2. If this is an empty string
|
2014-09-17 23:19:27 +00:00
|
|
|
(default), then the playback time is shown.
|
|
|
|
|
|
|
|
``--osd-msg3=<string>``
|
2018-01-07 02:22:57 +00:00
|
|
|
Similar to ``--osd-msg1``, but for OSD level 3. If this is an empty string
|
2014-09-17 23:19:27 +00:00
|
|
|
(default), then the playback time, duration, and some more information is
|
|
|
|
shown.
|
|
|
|
|
2018-01-21 23:36:08 +00:00
|
|
|
This is used for the ``show-progress`` command (by default mapped to ``P``),
|
|
|
|
and when seeking if enabled with ``--osd-on-seek`` or by ``osd-`` prefixes
|
|
|
|
in input.conf (see ``Input Command Prefixes``).
|
2014-09-17 23:19:27 +00:00
|
|
|
|
|
|
|
``--osd-status-msg`` is a legacy equivalent (but with a minor difference).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-status-msg=<string>``
|
|
|
|
Show a custom string during playback instead of the standard status text.
|
|
|
|
This overrides the status text used for ``--osd-level=3``, when using the
|
2018-01-21 23:36:08 +00:00
|
|
|
``show-progress`` command (by default mapped to ``P``), and when seeking if
|
|
|
|
enabled with ``--osd-on-seek`` or ``osd-`` prefixes in input.conf (see
|
|
|
|
``Input Command Prefixes``). Expands properties. See `Property Expansion`_.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-09-17 23:19:27 +00:00
|
|
|
This option has been replaced with ``--osd-msg3``. The only difference is
|
|
|
|
that this option implicitly includes ``${osd-sym-cc}``. This option is
|
|
|
|
ignored if ``--osd-msg3`` is not empty.
|
|
|
|
|
2014-09-01 22:09:03 +00:00
|
|
|
``--osd-playing-msg=<string>``
|
|
|
|
Show a message on OSD when playback starts. The string is expanded for
|
|
|
|
properties, e.g. ``--osd-playing-msg='file: ${filename}'`` will show the
|
|
|
|
message ``file:`` followed by a space and the currently played filename.
|
|
|
|
|
|
|
|
See `Property Expansion`_.
|
|
|
|
|
2022-04-07 22:00:00 +00:00
|
|
|
``--osd-playing-msg-duration=<time>``
|
|
|
|
Set the duration of ``osd-playing-msg`` in ms. If this is unset,
|
|
|
|
``osd-playing-msg`` stays on screen for the duration of ``osd-duration``.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-bar-align-x=<-1-1>``
|
|
|
|
Position of the OSD bar. -1 is far left, 0 is centered, 1 is far right.
|
|
|
|
Fractional values (like 0.5) are allowed.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-bar-align-y=<-1-1>``
|
|
|
|
Position of the OSD bar. -1 is top, 0 is centered, 1 is bottom.
|
|
|
|
Fractional values (like 0.5) are allowed.
|
|
|
|
|
|
|
|
``--osd-bar-w=<1-100>``
|
|
|
|
Width of the OSD bar, in percentage of the screen width (default: 75).
|
|
|
|
A value of 50 means the bar is half the screen wide.
|
|
|
|
|
|
|
|
``--osd-bar-h=<0.1-50>``
|
|
|
|
Height of the OSD bar, in percentage of the screen height (default: 3.125).
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-back-color=<color>``
|
2020-09-16 11:26:48 +00:00
|
|
|
See ``--sub-color``. Color used for OSD text background.
|
2013-06-13 22:24:41 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-blur=<0..20.0>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Gaussian blur factor. 0 means no blur applied (default).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-bold=<yes|no>``
|
2015-04-01 20:58:12 +00:00
|
|
|
Format text on bold.
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-italic=<yes|no>``
|
2016-04-08 08:43:34 +00:00
|
|
|
Format text on italic.
|
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-border-color=<color>``
|
2020-09-16 11:26:48 +00:00
|
|
|
See ``--sub-color``. Color used for the OSD font border.
|
2014-06-07 22:20:39 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2014-06-07 22:20:39 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
ignored when ``--osd-back-color`` is
|
2014-07-31 14:32:37 +00:00
|
|
|
specified (or more exactly: when that option is not set to completely
|
|
|
|
transparent).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-border-size=<size>``
|
|
|
|
Size of the OSD font border in scaled pixels (see ``--sub-font-size``
|
2014-07-31 14:32:37 +00:00
|
|
|
for details). A value of 0 disables borders.
|
2013-06-11 19:41:50 +00:00
|
|
|
|
2014-10-23 12:29:16 +00:00
|
|
|
Default: 3.
|
2014-04-24 15:42:54 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-color=<color>``
|
|
|
|
Specify the color used for OSD.
|
|
|
|
See ``--sub-color`` for details.
|
2013-09-10 13:09:24 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-fractions``
|
2015-03-03 10:12:11 +00:00
|
|
|
Show OSD times with fractions of seconds (in millisecond precision). Useful
|
|
|
|
to see the exact timestamp of a video frame.
|
2013-08-15 19:42:17 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-level=<0-3>``
|
|
|
|
Specifies which mode the OSD should start in.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:0: OSD completely disabled (subtitles only)
|
|
|
|
:1: enabled (shows up only on user interaction)
|
|
|
|
:2: enabled + current time visible by default
|
|
|
|
:3: enabled + ``--osd-status-msg`` (current time and status by default)
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-margin-x=<size>``
|
|
|
|
Left and right screen margin for the OSD in scaled pixels (see
|
|
|
|
``--sub-font-size`` for details).
|
2013-08-15 19:45:40 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
This option specifies the distance of the OSD to the left, as well as at
|
|
|
|
which distance from the right border long OSD text will be broken.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Default: 25.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-margin-y=<size>``
|
|
|
|
Top and bottom screen margin for the OSD in scaled pixels (see
|
|
|
|
``--sub-font-size`` for details).
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
This option specifies the vertical margins of the OSD.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-10-23 12:29:16 +00:00
|
|
|
Default: 22.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-align-x=<left|center|right>``
|
|
|
|
Control to which corner of the screen OSD should be
|
|
|
|
aligned to (default: ``left``).
|
2015-02-16 19:04:02 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-align-y=<top|center|bottom>``
|
|
|
|
Vertical position (default: ``top``).
|
2015-02-16 19:04:02 +00:00
|
|
|
Details see ``--osd-align-x``.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--osd-scale=<factor>``
|
2014-09-01 02:25:57 +00:00
|
|
|
OSD font size multiplier, multiplied with ``--osd-font-size`` value.
|
2013-06-24 21:06:34 +00:00
|
|
|
|
2014-10-26 11:02:00 +00:00
|
|
|
``--osd-scale-by-window=<yes|no>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Whether to scale the OSD with the window size (default: yes). If this is
|
|
|
|
disabled, ``--osd-font-size`` and other OSD options that use scaled pixels
|
|
|
|
are always in actual pixels. The effect is that changing the window size
|
|
|
|
won't change the OSD font size.
|
2013-06-24 21:06:34 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-shadow-color=<color>``
|
|
|
|
See ``--sub-color``. Color used for OSD shadow.
|
2013-06-24 21:06:34 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-shadow-offset=<size>``
|
|
|
|
Displacement of the OSD shadow in scaled pixels (see
|
|
|
|
``--sub-font-size`` for details). A value of 0 disables shadows.
|
2014-04-24 15:42:54 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Default: 0.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-10-02 15:08:14 +00:00
|
|
|
``--osd-spacing=<size>``
|
|
|
|
Horizontal OSD/sub font spacing in scaled pixels (see ``--sub-font-size``
|
2014-07-31 14:32:37 +00:00
|
|
|
for details). This value is added to the normal letter spacing. Negative
|
|
|
|
values are allowed.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Default: 0.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2016-08-28 16:15:37 +00:00
|
|
|
``--video-osd=<yes|no>``
|
|
|
|
Enabled OSD rendering on the video window (default: yes). This can be used
|
|
|
|
in situations where terminal OSD is preferred. If you just want to disable
|
|
|
|
all OSD rendering, use ``--osd-level=0``.
|
|
|
|
|
|
|
|
It does not affect subtitles or overlays created by scripts (in particular,
|
|
|
|
the OSC needs to be disabled with ``--no-osc``).
|
|
|
|
|
|
|
|
This option is somewhat experimental and could be replaced by another
|
|
|
|
mechanism in the future.
|
|
|
|
|
2019-09-25 20:11:39 +00:00
|
|
|
``--osd-font-provider=<...>``
|
|
|
|
See ``--sub-font-provider`` for details and accepted values. Note that
|
|
|
|
unlike subtitles, OSD never uses embedded fonts from media files.
|
|
|
|
|
2022-02-11 02:36:34 +00:00
|
|
|
``--osd-fonts-dir=<path>``
|
|
|
|
See ``--sub-fonts-dir`` for details. Defaults to ``~~/fonts``.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Screenshot
|
|
|
|
----------
|
2013-06-24 22:03:37 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--screenshot-format=<type>``
|
|
|
|
Set the image file type used for saving screenshots.
|
2012-11-24 23:06:16 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Available choices:
|
2012-11-24 23:06:16 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
:png: PNG
|
|
|
|
:jpg: JPEG (default)
|
2017-03-18 14:03:05 +00:00
|
|
|
:jpeg: JPEG (alias for jpg)
|
2019-09-14 20:18:02 +00:00
|
|
|
:webp: WebP
|
2022-04-26 15:23:21 +00:00
|
|
|
:jxl: JPEG XL
|
2023-03-24 23:30:57 +00:00
|
|
|
:avif: AVIF
|
2013-07-08 16:02:14 +00:00
|
|
|
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
``--screenshot-tag-colorspace=<yes|no>``
|
2023-07-17 21:16:46 +00:00
|
|
|
Tag screenshots with the appropriate colorspace (default: yes).
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
|
2023-07-17 21:16:46 +00:00
|
|
|
Note that not all formats support this. When it is unsupported, or when
|
|
|
|
this option is disabled, screenshots will be converted to sRGB before
|
|
|
|
being written.
|
Revert "Revert recent vo_opengl related commits"
Omitted a simple, but devastasting check. Fixed the relevant commits
now.
This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab.
diff --git a/video/out/gl_video.c b/video/out/gl_video.c
index 9c8a643..f1ea03e 100644
--- a/video/out/gl_video.c
+++ b/video/out/gl_video.c
@@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p)
shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma);
shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886",
- gamma_fun == MP_CSP_TRC_BT_1886);
+ use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886);
shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB",
- gamma_fun == MP_CSP_TRC_SRGB);
+ use_linear_light && gamma_fun == MP_CSP_TRC_SRGB);
shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid);
if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3)
shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
2015-02-28 19:15:12 +00:00
|
|
|
|
2015-04-29 19:05:04 +00:00
|
|
|
``--screenshot-high-bit-depth=<yes|no>``
|
|
|
|
If possible, write screenshots with a bit depth similar to the source
|
|
|
|
video (default: yes). This is interesting in particular for PNG, as this
|
2018-02-07 19:18:36 +00:00
|
|
|
sometimes triggers writing 16 bit PNGs with huge file sizes. This will also
|
|
|
|
include an unused alpha channel in the resulting files if 16 bit is used.
|
2015-04-29 19:05:04 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--screenshot-template=<template>``
|
|
|
|
Specify the filename template used to save screenshots. The template
|
|
|
|
specifies the filename without file extension, and can contain format
|
2014-09-01 02:25:57 +00:00
|
|
|
specifiers, which will be substituted when taking a screenshot.
|
2015-12-19 08:26:27 +00:00
|
|
|
By default, the template is ``mpv-shot%n``, which results in filenames like
|
2015-05-01 19:44:37 +00:00
|
|
|
``mpv-shot0012.png`` for example.
|
2012-11-25 22:32:35 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
The template can start with a relative or absolute path, in order to
|
|
|
|
specify a directory location where screenshots should be saved.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
If the final screenshot filename points to an already existing file, the
|
|
|
|
file will not be overwritten. The screenshot will either not be saved, or if
|
|
|
|
the template contains ``%n``, saved using different, newly generated
|
|
|
|
filename.
|
2012-11-25 22:32:35 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Allowed format specifiers:
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``%[#][0X]n``
|
|
|
|
A sequence number, padded with zeros to length X (default: 04). E.g.
|
|
|
|
passing the format ``%04n`` will yield ``0012`` on the 12th screenshot.
|
|
|
|
The number is incremented every time a screenshot is taken or if the
|
|
|
|
file already exists. The length ``X`` must be in the range 0-9. With
|
|
|
|
the optional # sign, mpv will use the lowest available number. For
|
|
|
|
example, if you take three screenshots--0001, 0002, 0003--and delete
|
|
|
|
the first two, the next two screenshots will not be 0004 and 0005, but
|
|
|
|
0001 and 0002 again.
|
|
|
|
``%f``
|
|
|
|
Filename of the currently played video.
|
|
|
|
``%F``
|
|
|
|
Same as ``%f``, but strip the file extension, including the dot.
|
|
|
|
``%x``
|
|
|
|
Directory path of the currently played video. If the video is not on
|
|
|
|
the filesystem (but e.g. ``http://``), this expand to an empty string.
|
|
|
|
``%X{fallback}``
|
|
|
|
Same as ``%x``, but if the video file is not on the filesystem, return
|
|
|
|
the fallback string inside the ``{...}``.
|
|
|
|
``%p``
|
|
|
|
Current playback time, in the same format as used in the OSD. The
|
|
|
|
result is a string of the form "HH:MM:SS". For example, if the video is
|
|
|
|
at the time position 5 minutes and 34 seconds, ``%p`` will be replaced
|
|
|
|
with "00:05:34".
|
|
|
|
``%P``
|
|
|
|
Similar to ``%p``, but extended with the playback time in milliseconds.
|
|
|
|
It is formatted as "HH:MM:SS.mmm", with "mmm" being the millisecond
|
|
|
|
part of the playback time.
|
2013-01-04 15:19:49 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2015-07-13 21:52:48 +00:00
|
|
|
This is a simple way for getting unique per-frame timestamps. (Frame
|
2014-07-31 14:32:37 +00:00
|
|
|
numbers would be more intuitive, but are not easily implementable
|
|
|
|
because container formats usually use time stamps for identifying
|
|
|
|
frames.)
|
|
|
|
``%wX``
|
|
|
|
Specify the current playback time using the format string ``X``.
|
|
|
|
``%p`` is like ``%wH:%wM:%wS``, and ``%P`` is like ``%wH:%wM:%wS.%wT``.
|
2012-11-17 19:56:45 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Valid format specifiers:
|
|
|
|
``%wH``
|
|
|
|
hour (padded with 0 to two digits)
|
|
|
|
``%wh``
|
|
|
|
hour (not padded)
|
|
|
|
``%wM``
|
|
|
|
minutes (00-59)
|
|
|
|
``%wm``
|
|
|
|
total minutes (includes hours, unlike ``%wM``)
|
|
|
|
``%wS``
|
|
|
|
seconds (00-59)
|
|
|
|
``%ws``
|
|
|
|
total seconds (includes hours and minutes)
|
|
|
|
``%wf``
|
|
|
|
like ``%ws``, but as float
|
|
|
|
``%wT``
|
|
|
|
milliseconds (000-999)
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``%tX``
|
|
|
|
Specify the current local date/time using the format ``X``. This format
|
|
|
|
specifier uses the UNIX ``strftime()`` function internally, and inserts
|
|
|
|
the result of passing "%X" to ``strftime``. For example, ``%tm`` will
|
|
|
|
insert the number of the current month as number. You have to use
|
|
|
|
multiple ``%tX`` specifiers to build a full date/time string.
|
|
|
|
``%{prop[:fallback text]}``
|
2016-08-11 20:29:18 +00:00
|
|
|
Insert the value of the input property 'prop'. E.g. ``%{filename}`` is
|
2014-07-31 14:32:37 +00:00
|
|
|
the same as ``%f``. If the property does not exist or is not available,
|
|
|
|
an error text is inserted, unless a fallback is specified.
|
|
|
|
``%%``
|
|
|
|
Replaced with the ``%`` character itself.
|
2013-01-04 15:19:49 +00:00
|
|
|
|
2015-05-01 17:55:43 +00:00
|
|
|
``--screenshot-directory=<path>``
|
|
|
|
Store screenshots in this directory. This path is joined with the filename
|
|
|
|
generated by ``--screenshot-template``. If the template filename is already
|
|
|
|
absolute, the directory is ignored.
|
|
|
|
|
2015-05-02 14:38:38 +00:00
|
|
|
If the directory does not exist, it is created on the first screenshot. If
|
|
|
|
it is not a directory, an error is generated when trying to write a
|
|
|
|
screenshot.
|
2015-05-01 17:55:43 +00:00
|
|
|
|
|
|
|
This option is not set by default, and thus will write screenshots to the
|
2015-05-01 20:17:09 +00:00
|
|
|
directory from which mpv was started. In pseudo-gui mode
|
2015-05-01 19:48:07 +00:00
|
|
|
(see `PSEUDO GUI MODE`_), this is set to the desktop.
|
2015-05-01 17:55:43 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--screenshot-jpeg-quality=<0-100>``
|
|
|
|
Set the JPEG quality level. Higher means better quality. The default is 90.
|
2014-06-14 17:17:31 +00:00
|
|
|
|
2015-04-29 19:01:08 +00:00
|
|
|
``--screenshot-jpeg-source-chroma=<yes|no>``
|
|
|
|
Write JPEG files with the same chroma subsampling as the video
|
|
|
|
(default: yes). If disabled, the libjpeg default is used.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--screenshot-png-compression=<0-9>``
|
|
|
|
Set the PNG compression level. Higher means better compression. This will
|
|
|
|
affect the file size of the written screenshot file and the time it takes
|
|
|
|
to write a screenshot. Too high compression might occupy enough CPU time to
|
|
|
|
interrupt playback. The default is 7.
|
2014-06-14 17:17:31 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--screenshot-png-filter=<0-5>``
|
|
|
|
Set the filter applied prior to PNG compression. 0 is none, 1 is "sub", 2 is
|
|
|
|
"up", 3 is "average", 4 is "Paeth", and 5 is "mixed". This affects the level
|
|
|
|
of compression that can be achieved. For most images, "mixed" achieves the
|
|
|
|
best compression ratio, hence it is the default.
|
2013-06-24 22:03:37 +00:00
|
|
|
|
2019-09-14 20:18:02 +00:00
|
|
|
``--screenshot-webp-lossless=<yes|no>``
|
|
|
|
Write lossless WebP files. ``--screenshot-webp-quality`` is ignored if this
|
|
|
|
is set. The default is no.
|
|
|
|
|
|
|
|
``--screenshot-webp-quality=<0-100>``
|
|
|
|
Set the WebP quality level. Higher means better quality. The default is 75.
|
|
|
|
|
2019-08-02 14:04:54 +00:00
|
|
|
``--screenshot-webp-compression=<0-6>``
|
|
|
|
Set the WebP compression level. Higher means better compression, but takes
|
|
|
|
more CPU time. Note that this also affects the screenshot quality when used
|
|
|
|
with lossy WebP files. The default is 4.
|
2013-06-24 22:03:37 +00:00
|
|
|
|
2022-04-23 18:24:09 +00:00
|
|
|
``--screenshot-jxl-distance=<0-15>``
|
2022-04-26 15:23:21 +00:00
|
|
|
Set the JPEG XL Butteraugli distance. Lower means better quality. Lossless
|
2022-04-23 18:24:09 +00:00
|
|
|
is 0.0, and 1.0 is approximately equivalent to JPEG quality 90 for
|
|
|
|
photographic content. Use 0.1 for "visually lossless" screenshots. The
|
|
|
|
default is 1.0.
|
|
|
|
|
|
|
|
``--screenshot-jxl-effort=<1-9>``
|
2022-04-26 15:23:21 +00:00
|
|
|
Set the JPEG XL compression effort. Higher effort (usually) means better
|
2023-02-18 11:16:21 +00:00
|
|
|
compression, but takes more CPU time. The default is 4.
|
2022-04-23 18:24:09 +00:00
|
|
|
|
2023-03-24 23:30:57 +00:00
|
|
|
``--screenshot-avif-encoder=<encoder>``
|
|
|
|
Specify the AV1 encoder to be used by libavcodec for encoding avif
|
|
|
|
screenshots.
|
|
|
|
|
|
|
|
Default: ``libaom-av1``
|
|
|
|
|
|
|
|
``--screenshot-avif-pixfmt=<format>``
|
|
|
|
Specify the pixel format to the libavcodec encoder.
|
|
|
|
|
|
|
|
Default: ``yuv420p``
|
|
|
|
|
|
|
|
``--screenshot-avif-opts=key1=value1,key2=value2,...``
|
|
|
|
Specifies libavcodec options for selected encoder. For more information,
|
|
|
|
consult the FFmpeg documentation.
|
|
|
|
|
|
|
|
Default: ``usage=allintra,crf=32,cpu-used=8,tune=ssim``
|
|
|
|
|
|
|
|
Note: the default is only guaranteed to work with the libaom-av1 encoder.
|
|
|
|
Above options may not be valid and or optimal for other encoders.
|
|
|
|
|
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
"``--screenshot-avif-opts=crf=32,aq-mode=complexity``"
|
|
|
|
sets the crf to 32 and quantization (aq-mode) to complexity based.
|
|
|
|
|
2020-10-04 22:16:46 +00:00
|
|
|
``--screenshot-sw=<yes|no>``
|
|
|
|
Whether to use software rendering for screenshots (default: no).
|
|
|
|
|
2023-07-19 21:12:47 +00:00
|
|
|
If set to no, the screenshot will be rendered by the current VO (only vo_gpu
|
|
|
|
or vo_gpu_next currently). The advantage is that this will (probably) always
|
2020-10-04 22:16:46 +00:00
|
|
|
show up as in the video window, because the same code is used for rendering.
|
|
|
|
But since the renderer needs to be reinitialized, this can be slow and
|
2023-07-19 21:12:47 +00:00
|
|
|
interrupt playback.
|
2020-10-04 22:16:46 +00:00
|
|
|
|
|
|
|
If set to yes, the software scaler is used to convert the video to RGB (or
|
|
|
|
whatever the target screenshot requires). In this case, conversion will
|
|
|
|
run in a separate thread and will probably not interrupt playback. The
|
|
|
|
software renderer may lack some capabilities, such as HDR rendering.
|
2023-07-19 21:12:47 +00:00
|
|
|
If ``window`` mode is used, the image will also be scaled in software
|
|
|
|
which may not accurately reflect the actual visible result.
|
2020-10-04 22:16:46 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Software Scaler
|
|
|
|
---------------
|
2013-06-24 22:03:37 +00:00
|
|
|
|
2014-06-10 20:41:14 +00:00
|
|
|
``--sws-scaler=<name>``
|
2012-11-24 20:18:50 +00:00
|
|
|
Specify the software scaler algorithm to be used with ``--vf=scale``. This
|
|
|
|
also affects video output drivers which lack hardware acceleration,
|
2013-07-08 16:02:14 +00:00
|
|
|
e.g. ``x11``. See also ``--vf=scale``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-06-10 20:41:14 +00:00
|
|
|
To get a list of available scalers, run ``--sws-scaler=help``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-06-10 20:41:14 +00:00
|
|
|
Default: ``bicubic``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-06-10 20:41:14 +00:00
|
|
|
``--sws-lgb=<0-100>``
|
2014-09-01 02:25:57 +00:00
|
|
|
Software scaler Gaussian blur filter (luma). See ``--sws-scaler``.
|
2014-06-10 20:41:14 +00:00
|
|
|
|
|
|
|
``--sws-cgb=<0-100>``
|
2014-09-01 02:25:57 +00:00
|
|
|
Software scaler Gaussian blur filter (chroma). See ``--sws-scaler``.
|
2014-06-10 20:41:14 +00:00
|
|
|
|
|
|
|
``--sws-ls=<-100-100>``
|
|
|
|
Software scaler sharpen filter (luma). See ``--sws-scaler``.
|
|
|
|
|
|
|
|
``--sws-cs=<-100-100>``
|
|
|
|
Software scaler sharpen filter (chroma). See ``--sws-scaler``.
|
|
|
|
|
|
|
|
``--sws-chs=<h>``
|
|
|
|
Software scaler chroma horizontal shifting. See ``--sws-scaler``.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-06-10 20:41:14 +00:00
|
|
|
``--sws-cvs=<v>``
|
|
|
|
Software scaler chroma vertical shifting. See ``--sws-scaler``.
|
2013-07-08 16:02:14 +00:00
|
|
|
|
sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.
Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.
The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.
Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 15:45:28 +00:00
|
|
|
``--sws-bitexact=<yes|no>``
|
|
|
|
Unknown functionality (default: no). Consult libswscale source code. The
|
|
|
|
primary purpose of this, as far as libswscale API goes), is to produce
|
|
|
|
exactly the same output for the same input on all platforms (output has the
|
|
|
|
same "bits" everywhere, thus "bitexact"). Typically disables optimizations.
|
|
|
|
|
|
|
|
``--sws-fast=<yes|no>``
|
|
|
|
Allow optimizations that help with performance, but reduce quality (default:
|
|
|
|
no).
|
|
|
|
|
|
|
|
VOs like ``drm`` and ``x11`` will benefit a lot from using ``--sws-fast``.
|
|
|
|
You may need to set other options, like ``--sws-scaler``. The builtin
|
|
|
|
``sws-fast`` profile sets this option and some others to gain performance
|
2020-02-10 17:11:42 +00:00
|
|
|
for reduced quality. Also see ``--sws-allow-zimg``.
|
sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.
Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.
The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.
Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 15:45:28 +00:00
|
|
|
|
2019-10-19 23:57:47 +00:00
|
|
|
``--sws-allow-zimg=<yes|no>``
|
|
|
|
Allow using zimg (if the component using the internal swscale wrapper
|
2020-02-12 17:06:53 +00:00
|
|
|
explicitly allows so) (default: yes). In this case, zimg *may* be used, if
|
|
|
|
the internal zimg wrapper supports the input and output formats. It will
|
|
|
|
silently or noisily fall back to libswscale if one of these conditions does
|
|
|
|
not apply.
|
2019-10-19 23:57:47 +00:00
|
|
|
|
|
|
|
If zimg is used, the other ``--sws-`` options are ignored, and the
|
|
|
|
``--zimg-`` options are used instead.
|
|
|
|
|
|
|
|
If the internal component using the swscale wrapper hooks up logging
|
|
|
|
correctly, a verbose priority log message will indicate whether zimg is
|
|
|
|
being used.
|
|
|
|
|
sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.
Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.
The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.
Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 15:45:28 +00:00
|
|
|
Most things which need software conversion can make use of this.
|
2019-10-19 23:57:47 +00:00
|
|
|
|
2020-02-10 17:11:42 +00:00
|
|
|
.. note::
|
|
|
|
|
2020-02-12 17:06:53 +00:00
|
|
|
Do note that zimg *may* be slower than libswscale. Usually,
|
2020-02-10 17:11:42 +00:00
|
|
|
it's faster on x86 platforms, but slower on ARM (due to lack of ARM
|
|
|
|
specific optimizations). The mpv zimg wrapper uses unoptimized repacking
|
|
|
|
for some formats, for which zimg cannot be blamed.
|
|
|
|
|
2019-10-31 16:01:31 +00:00
|
|
|
``--zimg-scaler=<point|bilinear|bicubic|spline16|spline36|lanczos>``
|
|
|
|
Zimg luma scaler to use (default: lanczos).
|
2019-10-19 23:54:45 +00:00
|
|
|
|
sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.
Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.
The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.
Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 15:45:28 +00:00
|
|
|
``--zimg-scaler-param-a=<default|float>``, ``--zimg-scaler-param-b=<default|float>``
|
|
|
|
Set scaler parameters. By default, these are set to the special string
|
|
|
|
``default``, which maps to a scaler-specific default value. Ignored if the
|
|
|
|
scaler is not tunable.
|
|
|
|
|
|
|
|
``lanczos``
|
|
|
|
``--zimg-scaler-param-a`` is the number of taps.
|
|
|
|
|
|
|
|
``bicubic``
|
|
|
|
a and b are the bicubic b and c parameters.
|
|
|
|
|
|
|
|
``--zimg-scaler-chroma=...``
|
2019-10-31 16:27:17 +00:00
|
|
|
Same as ``--zimg-scaler``, for for chroma interpolation (default: bilinear).
|
sws_utils, zimg: destroy vo_x11 and vo_drm performance
Raise swscale and zimg default parameters. This restores screenshot
quality settings (maybe) unset in the commit before. Also expose some
more libswscale and zimg options.
Since these options are also used for VOs like x11 and drm, this will
make x11/drm/etc. much slower. For compensation, provide a profile that
sets the old option values: sw-fast. I'm also enabling zimg here, just
as an experiment.
The core problem is that we have a single set of command line options
which control the settings used for most swscale/zimg uses. This was
done in the previous commit. It cannot differentiate between the VOs,
which need to be realtime and may accept/require lower quality options,
and things like screenshots or vo_image, which can be slower, but should
not sacrifice quality by default.
Should this have two sets of options or something similar to do the
right thing depending on the code which calls libswscale? Maybe. Or
should I just ignore the problem, make it someone else's problem (users
who want to use software conversion VOs), provide a sub-optimal
solution, and call it a day? Definitely, sounds good, pushing to master,
goodbye.
2019-10-31 15:45:28 +00:00
|
|
|
|
|
|
|
``--zimg-scaler-chroma-param-a``, ``--zimg-scaler-chroma-param-b``
|
|
|
|
Same as ``--zimg-scaler-param-a`` / ``--zimg-scaler-param-b``, for chroma.
|
|
|
|
|
|
|
|
``--zimg-dither=<no|ordered|random|error-diffusion>``
|
|
|
|
Dithering (default: random).
|
|
|
|
|
zimg: add slice threading and use it by default
This probably makes it much faster (I wouldn't know, I didn't run any
benchmarks ). Seems to work as well (although I'm not sure, it's not
like I'd perform rigorous tests).
The scale_zimg test seems to mysteriously treat color in fully
transparent alpha differently, which makes no sense, and isn't visible
(but makes the test fail). I can't be bothered with investigating this
more. What do you do with failing tests? Correct, you disable them. Or
rather, you disable whatever appears to cause them to fail, which is the
threading in this case.
This change follows mostly the tile_example.cpp. The slice size uses a
minimum of 64, which was suggested by the zimg author. Some of this
commit is a bit inelegant and weird, such as recomputing the scale
factor for every slice, or the way slice_h is managed. Too lazy to make
this more elegant.
zimg git had a regressio around active_region (which is needed by the
slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the
bug was never released, so just add a warning to the manpage.
2020-07-14 20:52:27 +00:00
|
|
|
``--zimg-threads=<auto|integer>``
|
|
|
|
Set the maximum number of threads to use for scaling (default: auto).
|
|
|
|
``auto`` uses the number of logical cores on the current machine. Note that
|
|
|
|
the scaler may use less threads (or even just 1 thread) depending on stuff.
|
|
|
|
Passing a value of 1 disables threading and always scales the image in a
|
|
|
|
single operation. Higher thread counts waste resources, but make it
|
|
|
|
typically faster.
|
|
|
|
|
|
|
|
Note that some zimg git versions had bugs that will corrupt the output if
|
|
|
|
threads are used.
|
|
|
|
|
2019-10-19 23:54:45 +00:00
|
|
|
``--zimg-fast=<yes|no>``
|
|
|
|
Allow optimizations that help with performance, but reduce quality (default:
|
2019-11-02 01:22:16 +00:00
|
|
|
yes). Currently, this may simplify gamma conversion operations.
|
2019-10-19 23:54:45 +00:00
|
|
|
|
|
|
|
|
2018-01-12 03:02:55 +00:00
|
|
|
Audio Resampler
|
|
|
|
---------------
|
|
|
|
|
|
|
|
This controls the default options of any resampling done by mpv (but not within
|
|
|
|
libavfilter, within the system audio API resampler, or any other places).
|
|
|
|
|
|
|
|
It also sets the defaults for the ``lavrresample`` audio filter.
|
|
|
|
|
|
|
|
``--audio-resample-filter-size=<length>``
|
|
|
|
Length of the filter with respect to the lower sampling rate. (default:
|
|
|
|
16)
|
|
|
|
|
|
|
|
``--audio-resample-phase-shift=<count>``
|
|
|
|
Log2 of the number of polyphase entries. (..., 10->1024, 11->2048,
|
|
|
|
12->4096, ...) (default: 10->1024)
|
|
|
|
|
|
|
|
``--audio-resample-cutoff=<cutoff>``
|
|
|
|
Cutoff frequency (0.0-1.0), default set depending upon filter length.
|
|
|
|
|
|
|
|
``--audio-resample-linear=<yes|no>``
|
|
|
|
If set then filters will be linearly interpolated between polyphase
|
|
|
|
entries. (default: no)
|
|
|
|
|
|
|
|
``--audio-normalize-downmix=<yes|no>``
|
|
|
|
Enable/disable normalization if surround audio is downmixed to stereo
|
|
|
|
(default: no). If this is disabled, downmix can cause clipping. If it's
|
|
|
|
enabled, the output might be too quiet. It depends on the source audio.
|
|
|
|
|
|
|
|
Technically, this changes the ``normalize`` suboption of the
|
|
|
|
``lavrresample`` audio filter, which performs the downmixing.
|
|
|
|
|
|
|
|
If downmix happens outside of mpv for some reason, or in the decoder
|
|
|
|
(decoder downmixing), or in the audio output (system mixer), this has no
|
|
|
|
effect.
|
|
|
|
|
2018-02-01 07:39:07 +00:00
|
|
|
``--audio-resample-max-output-size=<length>``
|
|
|
|
Limit maximum size of audio frames filtered at once, in ms (default: 40).
|
|
|
|
The output size size is limited in order to make resample speed changes
|
|
|
|
react faster. This is necessary especially if decoders or filters output
|
|
|
|
very large frame sizes (like some lossless codecs or some DRC filters).
|
|
|
|
This option does not affect the resampling algorithm in any way.
|
|
|
|
|
|
|
|
For testing/debugging only. Can be removed or changed any time.
|
|
|
|
|
2018-01-12 03:02:55 +00:00
|
|
|
``--audio-swresample-o=<string>``
|
|
|
|
Set AVOptions on the SwrContext or AVAudioResampleContext. These should
|
|
|
|
be documented by FFmpeg or Libav.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Terminal
|
|
|
|
--------
|
|
|
|
|
|
|
|
``--quiet``
|
|
|
|
Make console output less verbose; in particular, prevents the status line
|
|
|
|
(i.e. AV: 3.4 (00:00:03.37) / 5320.6 ...) from being displayed.
|
|
|
|
Particularly useful on slow terminals or broken ones which do not properly
|
|
|
|
handle carriage return (i.e. ``\r``).
|
|
|
|
|
2015-12-19 08:26:27 +00:00
|
|
|
See also: ``--really-quiet`` and ``--msg-level``.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
``--really-quiet``
|
|
|
|
Display even less output and status messages than with ``--quiet``.
|
|
|
|
|
|
|
|
``--no-terminal``, ``--terminal``
|
|
|
|
Disable any use of the terminal and stdin/stdout/stderr. This completely
|
|
|
|
silences any message output.
|
|
|
|
|
|
|
|
Unlike ``--really-quiet``, this disables input and terminal initialization
|
|
|
|
as well.
|
|
|
|
|
|
|
|
``--no-msg-color``
|
|
|
|
Disable colorful console output on terminals.
|
|
|
|
|
2015-02-06 15:48:52 +00:00
|
|
|
``--msg-level=<module1=level1,module2=level2,...>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Control verbosity directly for each module. The ``all`` module changes the
|
2017-10-30 11:58:55 +00:00
|
|
|
verbosity of all the modules. The verbosity changes from this option are
|
|
|
|
applied in order from left to right, and each item can override a previous
|
|
|
|
one.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
Run mpv with ``--msg-level=all=trace`` to see all messages mpv outputs. You
|
|
|
|
can use the module names printed in the output (prefixed to each line in
|
|
|
|
``[...]``) to limit the output to interesting modules.
|
|
|
|
|
2017-10-04 20:08:19 +00:00
|
|
|
This also affects ``--log-file``, and in certain cases libmpv API logging.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
Some messages are printed before the command line is parsed and are
|
|
|
|
therefore not affected by ``--msg-level``. To control these messages,
|
|
|
|
you have to use the ``MPV_VERBOSE`` environment variable; see
|
|
|
|
`ENVIRONMENT VARIABLES`_ for details.
|
|
|
|
|
|
|
|
Available levels:
|
|
|
|
|
|
|
|
:no: complete silence
|
|
|
|
:fatal: fatal messages only
|
|
|
|
:error: error messages
|
|
|
|
:warn: warning messages
|
|
|
|
:info: informational messages
|
|
|
|
:status: status messages (default)
|
|
|
|
:v: verbose messages
|
|
|
|
:debug: debug messages
|
|
|
|
:trace: very noisy debug messages
|
|
|
|
|
2016-04-02 18:57:20 +00:00
|
|
|
.. admonition:: Example
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
mpv --msg-level=ao/sndio=no
|
|
|
|
|
|
|
|
Completely silences the output of ao_sndio, which uses the log
|
|
|
|
prefix ``[ao/sndio]``.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
mpv --msg-level=all=warn,ao/alsa=error
|
|
|
|
|
|
|
|
Only show warnings or worse, and let the ao_alsa output show errors
|
|
|
|
only.
|
|
|
|
|
2016-08-28 16:15:37 +00:00
|
|
|
``--term-osd=<auto|no|force>``
|
|
|
|
Control whether OSD messages are shown on the console when no video output
|
|
|
|
is available (default: auto).
|
|
|
|
|
|
|
|
:auto: use terminal OSD if no video output active
|
|
|
|
:no: disable terminal OSD
|
|
|
|
:force: use terminal OSD even if video output active
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2016-08-28 16:15:37 +00:00
|
|
|
The ``auto`` mode also enables terminal OSD if ``--video-osd=no`` was set.
|
2014-01-13 19:11:18 +00:00
|
|
|
|
2014-01-15 15:14:37 +00:00
|
|
|
``--term-osd-bar``, ``--no-term-osd-bar``
|
|
|
|
Enable printing a progress bar under the status line on the terminal.
|
|
|
|
(Disabled by default.)
|
|
|
|
|
|
|
|
``--term-osd-bar-chars=<string>``
|
|
|
|
Customize the ``--term-osd-bar`` feature. The string is expected to
|
|
|
|
consist of 5 characters (start, left space, position indicator,
|
2014-09-01 02:25:57 +00:00
|
|
|
right space, end). You can use Unicode characters, but note that double-
|
2014-01-15 15:14:37 +00:00
|
|
|
width characters will not be treated correctly.
|
|
|
|
|
|
|
|
Default: ``[-+-]``.
|
|
|
|
|
2014-04-24 16:16:47 +00:00
|
|
|
``--term-playing-msg=<string>``
|
|
|
|
Print out a string after starting playback. The string is expanded for
|
2014-05-23 19:03:11 +00:00
|
|
|
properties, e.g. ``--term-playing-msg='file: ${filename}'`` will print the string
|
2014-04-24 16:16:47 +00:00
|
|
|
``file:`` followed by a space and the currently played filename.
|
|
|
|
|
|
|
|
See `Property Expansion`_.
|
|
|
|
|
2023-08-10 23:53:45 +00:00
|
|
|
``--term-remaining-playtime``, ``--no-term-remaining-playtime``
|
|
|
|
When printing out the time on the terminal, show the remaining time adjusted by
|
|
|
|
playback speed. Default: ``yes``
|
|
|
|
|
2014-04-24 16:16:47 +00:00
|
|
|
``--term-status-msg=<string>``
|
|
|
|
Print out a custom string during playback instead of the standard status
|
|
|
|
line. Expands properties. See `Property Expansion`_.
|
2020-05-25 18:37:37 +00:00
|
|
|
|
|
|
|
``--term-title=<string>``
|
|
|
|
Set the terminal title. Currently, this simply concatenates the escape
|
|
|
|
sequence setting the window title with the provided (property expanded)
|
|
|
|
string. This will mess up if the expanded string contain bytes that end the
|
|
|
|
escape sequence, or if the terminal does not understand the sequence. The
|
|
|
|
latter probably includes the regrettable win32.
|
|
|
|
|
|
|
|
Expands properties. See `Property Expansion`_.
|
2014-04-24 16:16:47 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--msg-module``
|
|
|
|
Prepend module name to each console message.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--msg-time``
|
2020-02-14 15:12:37 +00:00
|
|
|
Prepend timing information to each console message. The time is in
|
2020-09-18 12:26:10 +00:00
|
|
|
seconds since the player process was started (technically, slightly
|
2020-02-14 15:12:37 +00:00
|
|
|
later actually), using a monotonic time source depending on the OS. This
|
|
|
|
is ``CLOCK_MONOTONIC`` on sane UNIX variants.
|
2013-06-16 03:42:26 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Cache
|
|
|
|
-----
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2018-08-31 10:48:36 +00:00
|
|
|
``--cache=<yes|no|auto>``
|
|
|
|
Decide whether to use network cache settings (default: auto).
|
|
|
|
|
2019-10-14 16:28:14 +00:00
|
|
|
If enabled, use up to ``--cache-secs`` for the cache size (but still limited
|
2020-06-23 18:46:52 +00:00
|
|
|
to ``--demuxer-max-bytes``), and make the cached data seekable (if possible).
|
|
|
|
If disabled, ``--cache-pause`` and related are implicitly disabled.
|
2018-08-31 10:48:36 +00:00
|
|
|
|
2019-10-08 16:38:23 +00:00
|
|
|
The ``auto`` choice enables this depending on whether the stream is thought
|
|
|
|
to involve network accesses or other slow media (this is an imperfect
|
|
|
|
heuristic).
|
|
|
|
|
|
|
|
Before mpv 0.30.0, this used to accept a number, which specified the size
|
|
|
|
of the cache in kilobytes. Use e.g. ``--cache --demuxer-max-bytes=123k``
|
|
|
|
instead.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
|
|
|
``--no-cache``
|
|
|
|
Turn off input stream caching. See ``--cache``.
|
|
|
|
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-26 23:13:20 +00:00
|
|
|
``--cache-secs=<seconds>``
|
|
|
|
How many seconds of audio/video to prefetch if the cache is active. This
|
|
|
|
overrides the ``--demuxer-readahead-secs`` option if and only if the cache
|
2017-12-17 20:39:09 +00:00
|
|
|
is enabled and the value is larger. The default value is set to something
|
|
|
|
very high, so the actually achieved readahead will usually be limited by
|
2019-10-14 16:28:14 +00:00
|
|
|
the value of the ``--demuxer-max-bytes`` option. Setting this option is
|
|
|
|
usually only useful for limiting readahead.
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-26 23:13:20 +00:00
|
|
|
|
demux: add a on-disk cache
Somewhat similar to the old --cache-file, except for the demuxer cache.
Instead of keeping packet data in memory, it's written to disk and read
back when needed.
The idea is to reduce main memory usage, while allowing fast seeking in
large cached network streams (especially live streams). Keeping the
packet metadata on disk would be rather hard (would use mmap or so, or
rewrite the entire demux.c packet queue handling), and since it's
relatively small, just keep it in memory.
Also for simplicity, the disk cache is append-only. If you're watching
really long livestreams, and need pruning, you're probably out of luck.
This still could be improved by trying to free unused blocks with
fallocate(), but since we're writing multiple streams in an interleaved
manner, this is slightly hard.
Some rather gross ugliness in packet.h: we want to store the file
position of the cached data somewhere, but on 32 bit architectures, we
don't have any usable 64 bit members for this, just the buf/len fields,
which add up to 64 bit - so the shitty union aliases this memory.
Error paths untested. Side data (the complicated part of trying to
serialize ffmpeg packets) untested.
Stream recording had to be adjusted. Some minor details change due to
this, but probably nothing important.
The change in attempt_range_joining() is because packets in cache
have no valid len field. It was a useful check (heuristically
finding broken cases), but not a necessary one.
Various other approaches were tried. It would be interesting to list
them and to mention the pros and cons, but I don't feel like it.
2019-06-13 17:10:32 +00:00
|
|
|
``--cache-on-disk=<yes|no>``
|
|
|
|
Write packet data to a temporary file, instead of keeping them in memory.
|
|
|
|
This makes sense only with ``--cache``. If the normal cache is disabled,
|
|
|
|
this option is ignored.
|
|
|
|
|
|
|
|
The cache file is append-only. Even if the player appears to prune data, the
|
|
|
|
file space freed by it is not reused. The cache file is deleted when
|
|
|
|
playback is closed.
|
|
|
|
|
|
|
|
Note that packet metadata is still kept in memory. ``--demuxer-max-bytes``
|
|
|
|
and related options are applied to metadata *only*. The size of this
|
|
|
|
metadata varies, but 50 MB per hour of media is typical. The cache
|
|
|
|
statistics will report this metadats size, instead of the size of the cache
|
|
|
|
file. If the metadata hits the size limits, the metadata is pruned (but not
|
|
|
|
the cache file).
|
|
|
|
|
|
|
|
When the media is closed, the cache file is deleted. A cache file is
|
|
|
|
generally worthless after the media is closed, and it's hard to retrieve
|
|
|
|
any media data from it (it's not supported by design).
|
|
|
|
|
2019-06-30 18:09:27 +00:00
|
|
|
If the option is enabled at runtime, the cache file is created, but old data
|
|
|
|
will remain in the memory cache. If the option is disabled at runtime, old
|
|
|
|
data remains in the disk cache, and the cache file is not closed until the
|
|
|
|
media is closed. If the option is disabled and enabled again, it will
|
|
|
|
continue to use the cache file that was opened first.
|
|
|
|
|
demux: add a on-disk cache
Somewhat similar to the old --cache-file, except for the demuxer cache.
Instead of keeping packet data in memory, it's written to disk and read
back when needed.
The idea is to reduce main memory usage, while allowing fast seeking in
large cached network streams (especially live streams). Keeping the
packet metadata on disk would be rather hard (would use mmap or so, or
rewrite the entire demux.c packet queue handling), and since it's
relatively small, just keep it in memory.
Also for simplicity, the disk cache is append-only. If you're watching
really long livestreams, and need pruning, you're probably out of luck.
This still could be improved by trying to free unused blocks with
fallocate(), but since we're writing multiple streams in an interleaved
manner, this is slightly hard.
Some rather gross ugliness in packet.h: we want to store the file
position of the cached data somewhere, but on 32 bit architectures, we
don't have any usable 64 bit members for this, just the buf/len fields,
which add up to 64 bit - so the shitty union aliases this memory.
Error paths untested. Side data (the complicated part of trying to
serialize ffmpeg packets) untested.
Stream recording had to be adjusted. Some minor details change due to
this, but probably nothing important.
The change in attempt_range_joining() is because packets in cache
have no valid len field. It was a useful check (heuristically
finding broken cases), but not a necessary one.
Various other approaches were tried. It would be interesting to list
them and to mention the pros and cons, but I don't feel like it.
2019-06-13 17:10:32 +00:00
|
|
|
``--cache-dir=<path>``
|
2023-05-03 00:42:23 +00:00
|
|
|
Directory where to create temporary files. Cache is stored in the system's
|
|
|
|
cache directory (usually ``~/.cache/mpv``) if this is unset.
|
demux: add a on-disk cache
Somewhat similar to the old --cache-file, except for the demuxer cache.
Instead of keeping packet data in memory, it's written to disk and read
back when needed.
The idea is to reduce main memory usage, while allowing fast seeking in
large cached network streams (especially live streams). Keeping the
packet metadata on disk would be rather hard (would use mmap or so, or
rewrite the entire demux.c packet queue handling), and since it's
relatively small, just keep it in memory.
Also for simplicity, the disk cache is append-only. If you're watching
really long livestreams, and need pruning, you're probably out of luck.
This still could be improved by trying to free unused blocks with
fallocate(), but since we're writing multiple streams in an interleaved
manner, this is slightly hard.
Some rather gross ugliness in packet.h: we want to store the file
position of the cached data somewhere, but on 32 bit architectures, we
don't have any usable 64 bit members for this, just the buf/len fields,
which add up to 64 bit - so the shitty union aliases this memory.
Error paths untested. Side data (the complicated part of trying to
serialize ffmpeg packets) untested.
Stream recording had to be adjusted. Some minor details change due to
this, but probably nothing important.
The change in attempt_range_joining() is because packets in cache
have no valid len field. It was a useful check (heuristically
finding broken cases), but not a necessary one.
Various other approaches were tried. It would be interesting to list
them and to mention the pros and cons, but I don't feel like it.
2019-06-13 17:10:32 +00:00
|
|
|
|
|
|
|
Currently, this is used for ``--cache-on-disk`` only.
|
|
|
|
|
2018-01-03 20:19:59 +00:00
|
|
|
``--cache-pause=<yes|no>``
|
|
|
|
Whether the player should automatically pause when the cache runs out of
|
|
|
|
data and stalls decoding/playback (default: yes). If enabled, it will
|
|
|
|
pause and unpause once more data is available, aka "buffering".
|
player: redo how stream caching and pausing on low cache works
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
2014-08-26 23:13:20 +00:00
|
|
|
|
2018-01-03 20:28:28 +00:00
|
|
|
``--cache-pause-wait=<seconds>``
|
|
|
|
Number of seconds the packet cache should have buffered before starting
|
|
|
|
playback again if "buffering" was entered (default: 1). This can be used
|
|
|
|
to control how long the player rebuffers if ``--cache-pause`` is enabled,
|
|
|
|
and the demuxer underruns. If the given time is higher than the maximum
|
|
|
|
set with ``--cache-secs`` or ``--demuxer-readahead-secs``, or prefetching
|
2019-10-14 16:28:14 +00:00
|
|
|
ends before that for some other reason (like file end or maximum configured
|
|
|
|
cache size reached), playback resumes earlier.
|
2018-01-03 20:28:28 +00:00
|
|
|
|
2018-01-03 20:48:42 +00:00
|
|
|
``--cache-pause-initial=<yes|no>``
|
|
|
|
Enter "buffering" mode before starting playback (default: no). This can be
|
|
|
|
used to ensure playback starts smoothly, in exchange for waiting some time
|
|
|
|
to prefetch network data (as controlled by ``--cache-pause-wait``). For
|
|
|
|
example, some common behavior is that playback starts, but network caches
|
|
|
|
immediately underrun when trying to decode more data as playback progresses.
|
|
|
|
|
|
|
|
Another thing that can happen is that the network prefetching is so CPU
|
|
|
|
demanding (due to demuxing in the background) that playback drops frames
|
|
|
|
at first. In these cases, it helps enabling this option, and setting
|
|
|
|
``--cache-secs`` and ``--cache-pause-wait`` to roughly the same value.
|
|
|
|
|
|
|
|
This option also triggers when playback is restarted after seeking.
|
|
|
|
|
demux: add a on-disk cache
Somewhat similar to the old --cache-file, except for the demuxer cache.
Instead of keeping packet data in memory, it's written to disk and read
back when needed.
The idea is to reduce main memory usage, while allowing fast seeking in
large cached network streams (especially live streams). Keeping the
packet metadata on disk would be rather hard (would use mmap or so, or
rewrite the entire demux.c packet queue handling), and since it's
relatively small, just keep it in memory.
Also for simplicity, the disk cache is append-only. If you're watching
really long livestreams, and need pruning, you're probably out of luck.
This still could be improved by trying to free unused blocks with
fallocate(), but since we're writing multiple streams in an interleaved
manner, this is slightly hard.
Some rather gross ugliness in packet.h: we want to store the file
position of the cached data somewhere, but on 32 bit architectures, we
don't have any usable 64 bit members for this, just the buf/len fields,
which add up to 64 bit - so the shitty union aliases this memory.
Error paths untested. Side data (the complicated part of trying to
serialize ffmpeg packets) untested.
Stream recording had to be adjusted. Some minor details change due to
this, but probably nothing important.
The change in attempt_range_joining() is because packets in cache
have no valid len field. It was a useful check (heuristically
finding broken cases), but not a necessary one.
Various other approaches were tried. It would be interesting to list
them and to mention the pros and cons, but I don't feel like it.
2019-06-13 17:10:32 +00:00
|
|
|
``--cache-unlink-files=<immediate|whendone|no>``
|
|
|
|
Whether or when to unlink cache files (default: immediate). This affects
|
|
|
|
cache files which are inherently temporary, and which make no sense to
|
|
|
|
remain on disk after the player terminates. This is a debugging option.
|
|
|
|
|
|
|
|
``immediate``
|
|
|
|
Unlink cache file after they were created. The cache files won't be
|
|
|
|
visible anymore, even though they're in use. This ensures they are
|
|
|
|
guaranteed to be removed from disk when the player terminates, even if
|
|
|
|
it crashes.
|
|
|
|
|
|
|
|
``whendone``
|
|
|
|
Delete cache files after they are closed.
|
|
|
|
|
|
|
|
``no``
|
|
|
|
Don't delete cache files. They will consume disk space without having a
|
|
|
|
use.
|
|
|
|
|
|
|
|
Currently, this is used for ``--cache-on-disk`` only.
|
2014-07-31 14:32:37 +00:00
|
|
|
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
``--stream-buffer-size=<bytesize>``
|
2019-11-06 20:57:31 +00:00
|
|
|
Size of the low level stream byte buffer (default: 128KB). This is used as
|
stream: turn into a ring buffer, make size configurable
In some corner cases (see #6802), it can be beneficial to use a larger
stream buffer size. Use this as argument to rewrite everything for no
reason.
Turn stream.c itself into a ring buffer, with configurable size. The
latter would have been easily achievable with minimal changes, and the
ring buffer is the hard part. There is no reason to have a ring buffer
at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and
some subtle issues with demux_mkv.c wanting to seek back by small
offsets (the latter was handled with small stream_peek() calls, which
are unneeded now).
In addition, this turns small forward seeks into reads (where data is
simply skipped). Before this commit, only stream_skip() did this (which
also mean that stream_skip() simply calls stream_seek() now).
Replace all stream_peek() calls with something else (usually
stream_read_peek()). The function was a problem, because it returned a
pointer to the internal buffer, which is now a ring buffer with
wrapping. The new function just copies the data into a buffer, and in
some cases requires callers to dynamically allocate memory. (The most
common case, demux_lavf.c, required a separate buffer allocation anyway
due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_*
changes.
I'm not happy with this. There still isn't a good reason why there
should be a ring buffer, that is complex, and most of the time just
wastes half of the available memory. Maybe another rewrite soon.
It also contains bugs; you're an alpha tester now.
2019-11-06 20:36:02 +00:00
|
|
|
buffer between demuxer and low level I/O (e.g. sockets). Generally, this
|
|
|
|
can be very small, and the main purpose is similar to the internal buffer
|
|
|
|
FILE in the C standard library will have.
|
|
|
|
|
|
|
|
Half of the buffer is always used for guaranteed seek back, which is
|
|
|
|
important for unseekable input.
|
|
|
|
|
|
|
|
There are known cases where this can help performance to set a large buffer:
|
|
|
|
|
|
|
|
1. mp4 files. libavformat may trigger many small seeks in both
|
|
|
|
directions, depending on how the file was muxed.
|
|
|
|
|
|
|
|
2. Certain network filesystems, which do not have a cache, and where
|
|
|
|
small reads can be inefficient.
|
|
|
|
|
|
|
|
In other cases, setting this to a large value can reduce performance.
|
|
|
|
|
|
|
|
Usually, read accesses are at half the buffer size, but it may happen that
|
|
|
|
accesses are done alternating with smaller and larger sizes (this is due to
|
|
|
|
the internal ring buffer wrap-around).
|
|
|
|
|
|
|
|
See ``--list-options`` for defaults and value range. ``<bytesize>`` options
|
|
|
|
accept suffixes such as ``KiB`` and ``MiB``.
|
|
|
|
|
player: add optional separate video decoding thread
See manpage additions. This has been a topic in MPlayer/mplayer2/mpv
since forever. But since libavcodec multi-threaded decoding was added,
I've always considered this pointless. libavcodec requires you to
"preload" it with packets, and then you can pretty much avoid blocking
on it, if decoding is fast enough.
But in some cases, a decoupled decoder thread _might_ help. Users have
for example come up with cases where decoding video in a separate
process and piping it as raw video to mpv helped. (Or my memory is
false, and it was about vapoursynth filtering, who knows.) So let's just
see whether this helps with anything.
Note that this would have been _much_ easier if libavcodec had an
asynchronous (or rather, non-blocking) API. It could probably have
easily gained that with a small change to its multi-threading code and a
small extension to its API, but I guess not.
Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this
is due to annoying corner cases like legacy frame dropping and hardware
decoder state. These could probably be prettified later on.
There is also a change in playloop.c: this is because there is a need to
coordinate playback resets between demuxer thread, decoder thread, and
playback logic. I think this SEEK_BLOCK idea worked out reasonably well.
There are still a number of problems. For example, if the demuxer cache
is full, the decoder thread will simply block hard until the output
queue is full, which interferes with seeking. Could also be improved
later. Hardware decoding will probably die in a fire, because it will
run out of surfaces quickly. We could reduce the queue to size 1...
maybe later. We could update the queue options at runtime easily, but
currently I'm not going to bother.
I could only have put the lavc wrapper itself on a separate thread. But
there is some annoying interaction with EDL and backward playback shit,
and also you would have had to loop demuxer packets through the
playloop, so this sounded less annoying.
The food my mother made for us today was delicious.
Because audio uses the same code, also for audio (even if completely
pointless).
Fixes: #6926
2020-02-29 20:40:52 +00:00
|
|
|
``--vd-queue-enable=<yes|no>, --ad-queue-enable``
|
|
|
|
Enable running the video/audio decoder on a separate thread (default: no).
|
|
|
|
If enabled, the decoder is run on a separate thread, and a frame queue is
|
|
|
|
put between decoder and higher level playback logic. The size of the frame
|
|
|
|
queue is defined by the other options below.
|
|
|
|
|
|
|
|
This is probably quite pointless. libavcodec already has multithreaded
|
|
|
|
decoding (enabled by default), which makes this largely unnecessary. It
|
|
|
|
might help in some corner cases with high bandwidth video that is slow to
|
|
|
|
decode (in these cases libavcodec would block the playback logic, while
|
|
|
|
using a decoding thread would distribute the decoding time evenly without
|
|
|
|
affecting the playback logic). In other situations, it will simply make
|
|
|
|
seeking slower and use significantly more memory.
|
|
|
|
|
2020-03-05 10:15:29 +00:00
|
|
|
The queue size is restricted by the other ``--vd-queue-...`` options. The
|
|
|
|
final queue size is the minimum as indicated by the option with the lowest
|
|
|
|
limit. Each decoder/track has its own queue that may use the full configured
|
|
|
|
queue size.
|
|
|
|
|
2020-02-29 23:38:34 +00:00
|
|
|
Most queue options can be changed at runtime. ``--vd-queue-enable`` itself
|
|
|
|
(and the audio equivalent) update only if decoding is completely
|
2020-03-05 20:31:22 +00:00
|
|
|
reinitialized. However, setting ``--vd-queue-max-samples=1`` should almost
|
|
|
|
lead to the same behavior as ``--vd-queue-enable=no``, so that value can
|
|
|
|
be used for effectively runtime enabling/disabling the queue.
|
2020-02-29 23:38:34 +00:00
|
|
|
|
player: add optional separate video decoding thread
See manpage additions. This has been a topic in MPlayer/mplayer2/mpv
since forever. But since libavcodec multi-threaded decoding was added,
I've always considered this pointless. libavcodec requires you to
"preload" it with packets, and then you can pretty much avoid blocking
on it, if decoding is fast enough.
But in some cases, a decoupled decoder thread _might_ help. Users have
for example come up with cases where decoding video in a separate
process and piping it as raw video to mpv helped. (Or my memory is
false, and it was about vapoursynth filtering, who knows.) So let's just
see whether this helps with anything.
Note that this would have been _much_ easier if libavcodec had an
asynchronous (or rather, non-blocking) API. It could probably have
easily gained that with a small change to its multi-threading code and a
small extension to its API, but I guess not.
Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this
is due to annoying corner cases like legacy frame dropping and hardware
decoder state. These could probably be prettified later on.
There is also a change in playloop.c: this is because there is a need to
coordinate playback resets between demuxer thread, decoder thread, and
playback logic. I think this SEEK_BLOCK idea worked out reasonably well.
There are still a number of problems. For example, if the demuxer cache
is full, the decoder thread will simply block hard until the output
queue is full, which interferes with seeking. Could also be improved
later. Hardware decoding will probably die in a fire, because it will
run out of surfaces quickly. We could reduce the queue to size 1...
maybe later. We could update the queue options at runtime easily, but
currently I'm not going to bother.
I could only have put the lavc wrapper itself on a separate thread. But
there is some annoying interaction with EDL and backward playback shit,
and also you would have had to loop demuxer packets through the
playloop, so this sounded less annoying.
The food my mother made for us today was delicious.
Because audio uses the same code, also for audio (even if completely
pointless).
Fixes: #6926
2020-02-29 20:40:52 +00:00
|
|
|
This should not be used with hardware decoding. It is possible to enable
|
|
|
|
this for audio, but it makes even less sense.
|
|
|
|
|
|
|
|
``--vd-queue-max-bytes=<bytesize>``, ``--ad-queue-max-bytes``
|
|
|
|
Maximum approximate allowed size of the queue. If exceeded, decoding will
|
|
|
|
be stopped. The maximum size can be exceeded by about 1 frame.
|
|
|
|
|
|
|
|
See ``--list-options`` for defaults and value range. ``<bytesize>`` options
|
|
|
|
accept suffixes such as ``KiB`` and ``MiB``.
|
|
|
|
|
|
|
|
``--vd-queue-max-samples=<int>``, ``--ad-queue-max-samples``
|
|
|
|
Maximum number of frames (video) or samples (audio) of the queue. The audio
|
|
|
|
size may be exceeded by about 1 frame.
|
|
|
|
|
|
|
|
See ``--list-options`` for defaults and value range.
|
|
|
|
|
|
|
|
``--vd-queue-max-secs=<seconds>``, ``--ad-queue-max-secs``
|
|
|
|
Maximum number of seconds of media in the queue. The special value 0 means
|
|
|
|
no limit is set. The queue size may be exceeded by about 2 frames. Timestamp
|
|
|
|
resets may lead to random queue size usage.
|
|
|
|
|
|
|
|
See ``--list-options`` for defaults and value range.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Network
|
|
|
|
-------
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``--user-agent=<string>``
|
|
|
|
Use ``<string>`` as user agent for HTTP streaming.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cookies``, ``--no-cookies``
|
|
|
|
Support cookies when making HTTP requests. Disabled by default.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--cookies-file=<filename>``
|
|
|
|
Read HTTP cookies from <filename>. The file is assumed to be in Netscape
|
|
|
|
format.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--http-header-fields=<field1,field2>``
|
|
|
|
Set custom HTTP fields when accessing HTTP stream.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. admonition:: Example
|
2013-11-01 16:14:05 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
::
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
mpv --http-header-fields='Field1: value1','Field2: value2' \
|
|
|
|
http://localhost:1234
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Will generate HTTP request::
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
GET / HTTP/1.0
|
|
|
|
Host: localhost:1234
|
|
|
|
User-Agent: MPlayer
|
|
|
|
Icy-MetaData: 1
|
|
|
|
Field1: value1
|
|
|
|
Field2: value2
|
|
|
|
Connection: close
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2018-05-22 16:59:59 +00:00
|
|
|
``--http-proxy=<proxy>``
|
|
|
|
URL of the HTTP/HTTPS proxy. If this is set, the ``http_proxy`` environment
|
|
|
|
is ignored. The ``no_proxy`` environment variable is still respected. This
|
|
|
|
option is silently ignored if it does not start with ``http://``. Proxies
|
|
|
|
are not used for https URLs. Setting this option does not try to make the
|
|
|
|
ytdl script use the proxy.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--tls-ca-file=<filename>``
|
|
|
|
Certificate authority database file for use with TLS. (Silently fails with
|
2014-09-01 02:25:57 +00:00
|
|
|
older FFmpeg or Libav versions.)
|
2013-07-08 16:02:14 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--tls-verify``
|
|
|
|
Verify peer certificates when using TLS (e.g. with ``https://...``).
|
2014-09-01 02:25:57 +00:00
|
|
|
(Silently fails with older FFmpeg or Libav versions.)
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2015-10-20 18:27:58 +00:00
|
|
|
``--tls-cert-file``
|
|
|
|
A file containing a certificate to use in the handshake with the
|
|
|
|
peer.
|
|
|
|
|
|
|
|
``--tls-key-file``
|
|
|
|
A file containing the private key for the certificate.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--referrer=<string>``
|
|
|
|
Specify a referrer path or URL for HTTP requests.
|
2013-12-29 13:07:08 +00:00
|
|
|
|
2015-02-06 16:01:35 +00:00
|
|
|
``--network-timeout=<seconds>``
|
2019-11-14 12:46:03 +00:00
|
|
|
Specify the network timeout in seconds (default: 60 seconds). This affects
|
|
|
|
at least HTTP. The special value 0 uses the FFmpeg/Libav defaults. If a
|
|
|
|
protocol is used which does not support timeouts, this option is silently
|
|
|
|
ignored.
|
2015-02-06 16:01:35 +00:00
|
|
|
|
2018-01-25 16:36:43 +00:00
|
|
|
.. warning::
|
|
|
|
|
|
|
|
This breaks the RTSP protocol, because of inconsistent FFmpeg API
|
|
|
|
regarding its internal timeout option. Not only does the RTSP timeout
|
|
|
|
option accept different units (seconds instead of microseconds, causing
|
|
|
|
mpv to pass it huge values), it will also overflow FFmpeg internal
|
|
|
|
calculations. The worst is that merely setting the option will put RTSP
|
2019-11-14 12:46:03 +00:00
|
|
|
into listening mode, which breaks any client uses. At time of this
|
|
|
|
writing, the fix was not made effective yet. For this reason, this
|
|
|
|
option is ignored (or should be ignored) on RTSP URLs. You can still
|
|
|
|
set the timeout option directly with ``--demuxer-lavf-o``.
|
2018-01-25 16:36:43 +00:00
|
|
|
|
2020-02-27 15:22:20 +00:00
|
|
|
``--rtsp-transport=<lavf|udp|udp_multicast|tcp|http>``
|
2014-07-31 14:32:37 +00:00
|
|
|
Select RTSP transport method (default: tcp). This selects the underlying
|
|
|
|
network transport when playing ``rtsp://...`` URLs. The value ``lavf``
|
|
|
|
leaves the decision to libavformat.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2015-07-13 11:34:58 +00:00
|
|
|
``--hls-bitrate=<no|min|max|<rate>>``
|
2014-09-01 21:47:27 +00:00
|
|
|
If HLS streams are played, this option controls what streams are selected
|
|
|
|
by default. The option allows the following parameters:
|
|
|
|
|
|
|
|
:no: Don't do anything special. Typically, this will simply pick the
|
2015-01-26 02:58:13 +00:00
|
|
|
first audio/video streams it can find.
|
2014-09-01 21:47:27 +00:00
|
|
|
:min: Pick the streams with the lowest bitrate.
|
2015-01-26 02:58:13 +00:00
|
|
|
:max: Same, but highest bitrate. (Default.)
|
2014-09-01 21:47:27 +00:00
|
|
|
|
2015-07-13 11:34:58 +00:00
|
|
|
Additionally, if the option is a number, the stream with the highest rate
|
|
|
|
equal or below the option value is selected.
|
|
|
|
|
2014-09-01 21:47:27 +00:00
|
|
|
The bitrate as used is sent by the server, and there's no guarantee it's
|
|
|
|
actually meaningful.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
DVB
|
|
|
|
---
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2019-10-01 22:10:38 +00:00
|
|
|
``--dvbin-prog=<string>``
|
|
|
|
This defines the program to tune to. Usually, you may specify this
|
|
|
|
by using a stream URI like ``"dvb://ZDF HD"``, but you can tune to a
|
|
|
|
different channel by writing to this property at runtime.
|
|
|
|
Also see ``dvbin-channel-switch-offset`` for more useful channel
|
|
|
|
switching functionality.
|
|
|
|
|
2018-12-10 21:09:54 +00:00
|
|
|
``--dvbin-card=<0-15>``
|
|
|
|
Specifies using card number 0-15 (default: 0).
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--dvbin-file=<filename>``
|
2014-10-03 09:18:48 +00:00
|
|
|
Instructs mpv to read the channels list from ``<filename>``. The default is
|
|
|
|
in the mpv configuration directory (usually ``~/.config/mpv``) with the
|
2023-08-23 20:42:42 +00:00
|
|
|
filename ``channels.conf.{sat,ter,cbl,atsc,isdbt}`` (based on your card
|
|
|
|
type) or ``channels.conf`` as a last resort.
|
2015-01-05 19:29:04 +00:00
|
|
|
For DVB-S/2 cards, a VDR 1.7.x format channel list is recommended
|
|
|
|
as it allows tuning to DVB-S2 channels, enabling subtitles and
|
|
|
|
decoding the PMT (which largely improves the demuxing).
|
|
|
|
Classic mplayer format channel lists are still supported (without
|
|
|
|
these improvements), and for other card types, only limited VDR
|
|
|
|
format channel list support is implemented (patches welcome).
|
2015-01-05 22:41:54 +00:00
|
|
|
For channels with dynamic PID switching or incomplete
|
|
|
|
``channels.conf``, ``--dvbin-full-transponder`` or the magic PID
|
|
|
|
``8192`` are recommended.
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--dvbin-timeout=<1-30>``
|
|
|
|
Maximum number of seconds to wait when trying to tune a frequency before
|
|
|
|
giving up (default: 30).
|
2013-06-28 12:56:52 +00:00
|
|
|
|
2015-01-05 22:41:54 +00:00
|
|
|
``--dvbin-full-transponder=<yes|no>``
|
|
|
|
Apply no filters on program PIDs, only tune to frequency and pass full
|
2016-01-13 22:46:03 +00:00
|
|
|
transponder to demuxer.
|
|
|
|
The player frontend selects the streams from the full TS in this case,
|
|
|
|
so the program which is shown initially may not match the chosen channel.
|
|
|
|
Switching between the programs is possible by cycling the ``program``
|
|
|
|
property.
|
|
|
|
This is useful to record multiple programs on a single transponder,
|
|
|
|
or to work around issues in the ``channels.conf``.
|
2015-01-05 22:41:54 +00:00
|
|
|
It is also recommended to use this for channels which switch PIDs
|
|
|
|
on-the-fly, e.g. for regional news.
|
|
|
|
|
|
|
|
Default: ``no``
|
2013-05-15 13:14:24 +00:00
|
|
|
|
2019-10-01 22:10:38 +00:00
|
|
|
``--dvbin-channel-switch-offset=<integer>``
|
|
|
|
This value is not meant for setting via configuration, but used in channel
|
|
|
|
switching. An ``input.conf`` can ``cycle`` this value ``up`` and ``down``
|
|
|
|
to perform channel switching. This number effectively gives the offset
|
|
|
|
to the initially tuned to channel in the channel list.
|
|
|
|
|
|
|
|
An example ``input.conf`` could contain:
|
|
|
|
``H cycle dvbin-channel-switch-offset up``, ``K cycle dvbin-channel-switch-offset down``
|
|
|
|
|
2016-09-02 18:07:25 +00:00
|
|
|
ALSA audio output options
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
``--alsa-device=<device>``
|
2016-09-07 10:55:21 +00:00
|
|
|
Deprecated, use ``--audio-device`` (requires ``alsa/`` prefix).
|
2016-09-02 18:07:25 +00:00
|
|
|
|
|
|
|
``--alsa-resample=yes``
|
|
|
|
Enable ALSA resampling plugin. (This is disabled by default, because
|
|
|
|
some drivers report incorrect audio delay in some cases.)
|
|
|
|
|
|
|
|
``--alsa-mixer-device=<device>``
|
|
|
|
Set the mixer device used with ``ao-volume`` (default: ``default``).
|
|
|
|
|
|
|
|
``--alsa-mixer-name=<name>``
|
|
|
|
Set the name of the mixer element (default: ``Master``). This is for
|
|
|
|
example ``PCM`` or ``Master``.
|
|
|
|
|
|
|
|
``--alsa-mixer-index=<number>``
|
|
|
|
Set the index of the mixer channel (default: 0). Consider the output of
|
|
|
|
"``amixer scontrols``", then the index is the number that follows the
|
|
|
|
name of the element.
|
|
|
|
|
|
|
|
``--alsa-non-interleaved``
|
|
|
|
Allow output of non-interleaved formats (if the audio decoder uses
|
|
|
|
this format). Currently disabled by default, because some popular
|
|
|
|
ALSA plugins are utterly broken with non-interleaved formats.
|
|
|
|
|
|
|
|
``--alsa-ignore-chmap``
|
|
|
|
Don't read or set the channel map of the ALSA device - only request the
|
|
|
|
required number of channels, and then pass the audio as-is to it. This
|
|
|
|
option most likely should not be used. It can be useful for debugging,
|
|
|
|
or for static setups with a specially engineered ALSA configuration (in
|
|
|
|
this case you should always force the same layout with ``--audio-channels``,
|
|
|
|
or it will work only for files which use the layout implicit to your
|
|
|
|
ALSA device).
|
|
|
|
|
2018-04-05 14:32:22 +00:00
|
|
|
``--alsa-buffer-time=<microseconds>``
|
|
|
|
Set the requested buffer time in microseconds. A value of 0 skips requesting
|
|
|
|
anything from the ALSA API. This and the ``--alsa-periods`` option uses the
|
|
|
|
ALSA ``near`` functions to set the requested parameters. If doing so results
|
|
|
|
in an empty configuration set, setting these parameters is skipped.
|
|
|
|
|
|
|
|
Both options control the buffer size. A low buffer size can lead to higher
|
|
|
|
CPU usage and audio dropouts, while a high buffer size can lead to higher
|
|
|
|
latency in volume changes and other filtering.
|
|
|
|
|
|
|
|
``--alsa-periods=<number>``
|
|
|
|
Number of periods requested from the ALSA API. See ``--alsa-buffer-time``
|
|
|
|
for further remarks.
|
|
|
|
|
2016-09-02 18:07:25 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
GPU renderer options
|
2016-09-02 13:59:40 +00:00
|
|
|
-----------------------
|
|
|
|
|
2021-04-09 07:14:54 +00:00
|
|
|
The following video options are currently all specific to ``--vo=gpu``,
|
|
|
|
``--vo=libmpv`` and ``--vo=gpu-next``, which are the only VOs that implement
|
|
|
|
them.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--scale=<filter>``
|
2017-07-08 23:13:52 +00:00
|
|
|
The filter function to use when upscaling video.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``bilinear``
|
|
|
|
Bilinear hardware texture filtering (fastest, very low quality). This
|
|
|
|
is the default for compatibility reasons.
|
|
|
|
|
|
|
|
``spline36``
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
Mid quality and speed. This is the default when using ``gpu-hq``.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``lanczos``
|
|
|
|
Lanczos scaling. Provides mid quality and speed. Generally worse than
|
|
|
|
``spline36``, but it results in a slightly sharper image which is good
|
|
|
|
for some content types. The number of taps can be controlled with
|
|
|
|
``scale-radius``, but is best left unchanged.
|
|
|
|
|
|
|
|
(This filter is an alias for ``sinc``-windowed ``sinc``)
|
|
|
|
|
|
|
|
``ewa_lanczos``
|
|
|
|
Elliptic weighted average Lanczos scaling. Also known as Jinc.
|
|
|
|
Relatively slow, but very good quality. The radius can be controlled
|
|
|
|
with ``scale-radius``. Increasing the radius makes the filter sharper
|
|
|
|
but adds more ringing.
|
|
|
|
|
|
|
|
(This filter is an alias for ``jinc``-windowed ``jinc``)
|
|
|
|
|
|
|
|
``ewa_lanczossharp``
|
|
|
|
A slightly sharpened version of ewa_lanczos, preconfigured to use an
|
|
|
|
ideal radius and parameter. If your hardware can run it, this is
|
|
|
|
probably what you should use by default.
|
|
|
|
|
|
|
|
``mitchell``
|
|
|
|
Mitchell-Netravali. The ``B`` and ``C`` parameters can be set with
|
|
|
|
``--scale-param1`` and ``--scale-param2``. This filter is very good at
|
|
|
|
downscaling (see ``--dscale``).
|
|
|
|
|
|
|
|
``oversample``
|
|
|
|
A version of nearest neighbour that (naively) oversamples pixels, so
|
|
|
|
that pixels overlapping edges get linearly interpolated instead of
|
|
|
|
rounded. This essentially removes the small imperfections and judder
|
|
|
|
artifacts caused by nearest-neighbour interpolation, in exchange for
|
|
|
|
adding some blur. This filter is good at temporal interpolation, and
|
|
|
|
also known as "smoothmotion" (see ``--tscale``).
|
|
|
|
|
|
|
|
``linear``
|
|
|
|
A ``--tscale`` filter.
|
|
|
|
|
|
|
|
There are some more filters, but most are not as useful. For a complete
|
|
|
|
list, pass ``help`` as value, e.g.::
|
|
|
|
|
|
|
|
mpv --scale=help
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--cscale=<filter>``
|
|
|
|
As ``--scale``, but for interpolating chroma information. If the image is
|
|
|
|
not subsampled, this option is ignored entirely.
|
|
|
|
|
|
|
|
``--dscale=<filter>``
|
|
|
|
Like ``--scale``, but apply these filters on downscaling instead. If this
|
|
|
|
option is unset, the filter implied by ``--scale`` will be applied.
|
|
|
|
|
|
|
|
``--tscale=<filter>``
|
|
|
|
The filter used for interpolating the temporal axis (frames). This is only
|
|
|
|
used if ``--interpolation`` is enabled. The only valid choices for
|
|
|
|
``--tscale`` are separable convolution filters (use ``--tscale=help`` to
|
|
|
|
get a list). The default is ``mitchell``.
|
|
|
|
|
2017-12-05 22:34:25 +00:00
|
|
|
Common ``--tscale`` choices include ``oversample``, ``linear``,
|
|
|
|
``catmull_rom``, ``mitchell``, ``gaussian``, or ``bicubic``. These are
|
|
|
|
listed in increasing order of smoothness/blurriness, with ``bicubic``
|
|
|
|
being the smoothest/blurriest and ``oversample`` being the sharpest/least
|
|
|
|
smooth.
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-param1=<value>``, ``--scale-param2=<value>``, ``--cscale-param1=<value>``, ``--cscale-param2=<value>``, ``--dscale-param1=<value>``, ``--dscale-param2=<value>``, ``--tscale-param1=<value>``, ``--tscale-param2=<value>``
|
2019-10-24 22:25:05 +00:00
|
|
|
Set filter parameters. By default, these are set to the special string
|
|
|
|
``default``, which maps to a scaler-specific default value. Ignored if the
|
|
|
|
filter is not tunable. Currently, this affects the following filter
|
|
|
|
parameters:
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
bcspline
|
|
|
|
Spline parameters (``B`` and ``C``). Defaults to 0.5 for both.
|
|
|
|
|
|
|
|
gaussian
|
|
|
|
Scale parameter (``t``). Increasing this makes the result blurrier.
|
|
|
|
Defaults to 1.
|
|
|
|
|
|
|
|
oversample
|
|
|
|
Minimum distance to an edge before interpolation is used. Setting this
|
|
|
|
to 0 will always interpolate edges, whereas setting it to 0.5 will
|
|
|
|
never interpolate, thus behaving as if the regular nearest neighbour
|
|
|
|
algorithm was used. Defaults to 0.0.
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-blur=<value>``, ``--scale-wblur=<value>``, ``--cscale-blur=<value>``, ``--cscale-wblur=<value>``, ``--dscale-blur=<value>``, ``--dscale-wblur=<value>``, ``--tscale-blur=<value>``, ``--tscale-wblur=<value>``
|
2016-10-26 14:32:57 +00:00
|
|
|
Kernel/window scaling factor (also known as a blur factor). Decreasing this
|
|
|
|
makes the result sharper, increasing it makes it blurrier (default 0). If
|
|
|
|
set to 0, the kernel's preferred blur factor is used. Note that setting
|
|
|
|
this too low (eg. 0.5) leads to bad results. It's generally recommended to
|
|
|
|
stick to values between 0.8 and 1.2.
|
|
|
|
|
2017-07-12 17:08:58 +00:00
|
|
|
``--scale-clamp=<0.0-1.0>``, ``--cscale-clamp``, ``--dscale-clamp``, ``--tscale-clamp``
|
|
|
|
Specifies a weight bias to multiply into negative coefficients. Specifying
|
|
|
|
``--scale-clamp=1`` has the effect of removing negative weights completely,
|
|
|
|
thus effectively clamping the value range to [0-1]. Values between 0.0 and
|
|
|
|
1.0 can be specified to apply only a moderate diminishment of negative
|
|
|
|
weights. This is especially useful for ``--tscale``, where it reduces
|
|
|
|
excessive ringing artifacts in the temporal domain (which typically
|
|
|
|
manifest themselves as short flashes or fringes of black, mostly around
|
|
|
|
moving edges) in exchange for potentially adding more blur. The default for
|
|
|
|
``--tscale-clamp`` is 1.0, the others default to 0.0.
|
2016-10-26 14:51:21 +00:00
|
|
|
|
2017-07-03 09:23:48 +00:00
|
|
|
``--scale-cutoff=<value>``, ``--cscale-cutoff=<value>``, ``--dscale-cutoff=<value>``
|
|
|
|
Cut off the filter kernel prematurely once the value range drops below
|
|
|
|
this threshold. Doing so allows more aggressive pruning of skippable
|
|
|
|
coefficients by disregarding parts of the LUT which are effectively zeroed
|
|
|
|
out by the window function. Only affects polar (EWA) filters. The default
|
|
|
|
is 0.001 for each, which is perceptually transparent but provides a 10%-20%
|
|
|
|
speedup, depending on the exact radius and filter kernel chosen.
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-taper=<value>``, ``--scale-wtaper=<value>``, ``--dscale-taper=<value>``, ``--dscale-wtaper=<value>``, ``--cscale-taper=<value>``, ``--cscale-wtaper=<value>``, ``--tscale-taper=<value>``, ``--tscale-wtaper=<value>``
|
2016-10-26 14:32:57 +00:00
|
|
|
Kernel/window taper factor. Increasing this flattens the filter function.
|
|
|
|
Value range is 0 to 1. A value of 0 (the default) means no flattening, a
|
|
|
|
value of 1 makes the filter completely flat (equivalent to a box function).
|
|
|
|
Values in between mean that some portion will be flat and the actual filter
|
|
|
|
function will be squeezed into the space in between.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-radius=<value>``, ``--cscale-radius=<value>``, ``--dscale-radius=<value>``, ``--tscale-radius=<value>``
|
2016-09-02 13:59:40 +00:00
|
|
|
Set radius for tunable filters, must be a float number between 0.5 and
|
|
|
|
16.0. Defaults to the filter's preferred radius if not specified. Doesn't
|
|
|
|
work for every scaler and VO combination.
|
|
|
|
|
|
|
|
Note that depending on filter implementation details and video scaling
|
|
|
|
ratio, the radius that actually being used might be different (most likely
|
|
|
|
being increased a bit).
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-antiring=<value>``, ``--cscale-antiring=<value>``, ``--dscale-antiring=<value>``, ``--tscale-antiring=<value>``
|
2016-09-02 13:59:40 +00:00
|
|
|
Set the antiringing strength. This tries to eliminate ringing, but can
|
|
|
|
introduce other artifacts in the process. Must be a float number between
|
|
|
|
0.0 and 1.0. The default value of 0.0 disables antiringing entirely.
|
|
|
|
|
|
|
|
Note that this doesn't affect the special filters ``bilinear`` and
|
2017-07-04 22:25:32 +00:00
|
|
|
``bicubic_fast``, nor does it affect any polar (EWA) scalers.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-window=<window>``, ``--cscale-window=<window>``, ``--dscale-window=<window>``, ``--tscale-window=<window>``
|
2016-09-02 13:59:40 +00:00
|
|
|
(Advanced users only) Choose a custom windowing function for the kernel.
|
|
|
|
Defaults to the filter's preferred window if unset. Use
|
|
|
|
``--scale-window=help`` to get a list of supported windowing functions.
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--scale-wparam=<window>``, ``--cscale-wparam=<window>``, ``--cscale-wparam=<window>``, ``--tscale-wparam=<window>``
|
2016-09-02 13:59:40 +00:00
|
|
|
(Advanced users only) Configure the parameter for the window function given
|
2019-10-24 22:25:05 +00:00
|
|
|
by ``--scale-window`` etc. By default, these are set to the special string
|
|
|
|
``default``, which maps to a window-specific default value. Ignored if the
|
|
|
|
window is not tunable. Currently, this affects the following window
|
|
|
|
parameters:
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
kaiser
|
|
|
|
Window parameter (alpha). Defaults to 6.33.
|
|
|
|
blackman
|
|
|
|
Window parameter (alpha). Defaults to 0.16.
|
|
|
|
gaussian
|
|
|
|
Scale parameter (t). Increasing this makes the window wider. Defaults
|
|
|
|
to 1.
|
|
|
|
|
|
|
|
``--scaler-lut-size=<4..10>``
|
|
|
|
Set the size of the lookup texture for scaler kernels (default: 6). The
|
|
|
|
actual size of the texture is ``2^N`` for an option value of ``N``. So the
|
|
|
|
lookup texture with the default setting uses 64 samples.
|
|
|
|
|
|
|
|
All weights are linearly interpolated from those samples, so increasing
|
|
|
|
the size of lookup table might improve the accuracy of scaler.
|
|
|
|
|
|
|
|
``--scaler-resizes-only``
|
|
|
|
Disable the scaler if the video image is not resized. In that case,
|
|
|
|
``bilinear`` is used instead of whatever is set with ``--scale``. Bilinear
|
|
|
|
will reproduce the source image perfectly if no scaling is performed.
|
|
|
|
Enabled by default. Note that this option never affects ``--cscale``.
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--correct-downscaling``
|
|
|
|
When using convolution based filters, extend the filter size when
|
|
|
|
downscaling. Increases quality, but reduces performance while downscaling.
|
|
|
|
|
|
|
|
This will perform slightly sub-optimally for anamorphic video (but still
|
|
|
|
better than without it) since it will extend the size to match only the
|
|
|
|
milder of the scale factors between the axes.
|
|
|
|
|
2020-03-14 15:58:02 +00:00
|
|
|
Note: this option is ignored when using bilinear downscaling (the default).
|
|
|
|
|
2018-10-17 09:23:16 +00:00
|
|
|
``--linear-downscaling``
|
|
|
|
Scale in linear light when downscaling. It should only be used with a
|
|
|
|
``--fbo-format`` that has at least 16 bit precision. This option
|
|
|
|
has no effect on HDR content.
|
|
|
|
|
|
|
|
``--linear-upscaling``
|
|
|
|
Scale in linear light when upscaling. Like ``--linear-downscaling``, it
|
|
|
|
should only be used with a ``--fbo-format`` that has at least 16 bits
|
|
|
|
precisions. This is not usually recommended except for testing/specific
|
|
|
|
purposes. Users are advised to either enable ``--sigmoid-upscaling`` or
|
|
|
|
keep both options disabled (i.e. scaling in gamma light).
|
|
|
|
|
|
|
|
``--sigmoid-upscaling``
|
|
|
|
When upscaling, use a sigmoidal color transform to avoid emphasizing
|
|
|
|
ringing artifacts. This is incompatible with and replaces
|
|
|
|
``--linear-upscaling``. (Note that sigmoidization also requires
|
|
|
|
linearization, so the ``LINEAR`` rendering step fires in both cases)
|
|
|
|
|
|
|
|
``--sigmoid-center``
|
|
|
|
The center of the sigmoid curve used for ``--sigmoid-upscaling``, must be a
|
|
|
|
float between 0.0 and 1.0. Defaults to 0.75 if not specified.
|
|
|
|
|
|
|
|
``--sigmoid-slope``
|
|
|
|
The slope of the sigmoid curve used for ``--sigmoid-upscaling``, must be a
|
|
|
|
float between 1.0 and 20.0. Defaults to 6.5 if not specified.
|
|
|
|
|
2016-10-26 14:51:21 +00:00
|
|
|
``--interpolation``
|
|
|
|
Reduce stuttering caused by mismatches in the video fps and display refresh
|
|
|
|
rate (also known as judder).
|
|
|
|
|
|
|
|
.. warning:: This requires setting the ``--video-sync`` option to one
|
|
|
|
of the ``display-`` modes, or it will be silently disabled.
|
|
|
|
This was not required before mpv 0.14.0.
|
|
|
|
|
|
|
|
This essentially attempts to interpolate the missing frames by convoluting
|
|
|
|
the video along the temporal axis. The filter used can be controlled using
|
|
|
|
the ``--tscale`` setting.
|
|
|
|
|
|
|
|
``--interpolation-threshold=<0..1,-1>``
|
|
|
|
Threshold below which frame ratio interpolation gets disabled (default:
|
vo_gpu: adjust interpolation_threshold's default
When mpv attempts to play a video that is, on average, 60 FPS on a
display that is not exactly 60.00 Hz, two options try to fight each
other: `video-sync-max-video-change` and `interpolation-threshold`.
Normally, container FPS in something such as an .mp4 or a .mkv is
precise enough such that the video can be retimed exactly to the display
Hz and interpolation is not activated.
In the case of something like certain live streaming videos or other scenario
where container FPS is not known, the default option of 0.0001 for
`interpolation-threshold` is extremely low, and while
`video-sync-max-video-change` retimes the video to what it approximately
knows as the "real" FPS, this may or may not be outside of
`interpolation-threshold`'s logic at any given time, which causes
interpolation to be frequently flipped on and off giving an appearance
of stuttering or repeated frames that is oftern quite jarring and makes
a video unwatchable.
This commit changes the default of `interpolation-threshold` to 0.01,
which is the same value as `video-sync-max-video-change`, and guarantees
that if the user accepts a video being retimed to match the display,
they do not additionally have to worry about a much more
precise interpolation threshold randomly flipping on or off. No internal
logic is changed so setting `interpolation-threshold` to -1 will still
disable this logic entirely and always enable interpolation.
The documentation has been updated to reflect this change and give
context to the user for which scenarios they might want to disable
`interpolation-threshold` logic or change it to a smaller value.
2021-03-17 01:44:29 +00:00
|
|
|
``0.01``). This is calculated as ``abs(disphz/vfps - 1) < threshold``,
|
2016-10-26 14:51:21 +00:00
|
|
|
where ``vfps`` is the speed-adjusted video FPS, and ``disphz`` the
|
|
|
|
display refresh rate. (The speed-adjusted video FPS is roughly equal to
|
|
|
|
the normal video FPS, but with slowdown and speedup applied. This matters
|
|
|
|
if you use ``--video-sync=display-resample`` to make video run synchronously
|
|
|
|
to the display FPS, or if you change the ``speed`` property.)
|
|
|
|
|
vo_gpu: adjust interpolation_threshold's default
When mpv attempts to play a video that is, on average, 60 FPS on a
display that is not exactly 60.00 Hz, two options try to fight each
other: `video-sync-max-video-change` and `interpolation-threshold`.
Normally, container FPS in something such as an .mp4 or a .mkv is
precise enough such that the video can be retimed exactly to the display
Hz and interpolation is not activated.
In the case of something like certain live streaming videos or other scenario
where container FPS is not known, the default option of 0.0001 for
`interpolation-threshold` is extremely low, and while
`video-sync-max-video-change` retimes the video to what it approximately
knows as the "real" FPS, this may or may not be outside of
`interpolation-threshold`'s logic at any given time, which causes
interpolation to be frequently flipped on and off giving an appearance
of stuttering or repeated frames that is oftern quite jarring and makes
a video unwatchable.
This commit changes the default of `interpolation-threshold` to 0.01,
which is the same value as `video-sync-max-video-change`, and guarantees
that if the user accepts a video being retimed to match the display,
they do not additionally have to worry about a much more
precise interpolation threshold randomly flipping on or off. No internal
logic is changed so setting `interpolation-threshold` to -1 will still
disable this logic entirely and always enable interpolation.
The documentation has been updated to reflect this change and give
context to the user for which scenarios they might want to disable
`interpolation-threshold` logic or change it to a smaller value.
2021-03-17 01:44:29 +00:00
|
|
|
The default is intended to enable interpolation in scenarios where
|
|
|
|
retiming with the ``--video-sync=display-*`` cannot adjust the speed of
|
|
|
|
the video sufficiently for smooth playback. For example if a video is
|
|
|
|
60.00 FPS and your display refresh rate is 59.94 Hz, interpolation will
|
|
|
|
never be activated, since the mismatch is within 1% of the refresh
|
|
|
|
rate. The default also handles the scenario when mpv cannot determine the
|
|
|
|
container FPS, such as during certain live streams, and may dynamically
|
|
|
|
toggle interpolation on and off. In this scenario, the default would be to
|
|
|
|
not use interpolation but rather to allow ``--video-sync=display-*`` to
|
|
|
|
retime the video to match display refresh rate. See
|
|
|
|
``--video-sync-max-video-change`` for more information about how mpv
|
|
|
|
will retime video.
|
|
|
|
|
|
|
|
Also note that if you use e.g. ``--video-sync=display-vdrop``, small
|
|
|
|
deviations in the rate can disable interpolation and introduce a
|
|
|
|
discontinuity every other minute.
|
2016-10-26 14:51:21 +00:00
|
|
|
|
|
|
|
Set this to ``-1`` to disable this logic.
|
|
|
|
|
2021-04-09 07:14:54 +00:00
|
|
|
``--interpolation-preserve``
|
|
|
|
Preserve the previous frames' interpolated results even when renderer
|
|
|
|
parameters are changed - with the exception of options related to
|
|
|
|
cropping and video placement, which always invalidate the cache. Enabling
|
|
|
|
this option makes dynamic updates of renderer settings slightly smoother at
|
|
|
|
the cost of slightly higher latency in response to such changes. Defaults
|
2022-09-20 14:08:28 +00:00
|
|
|
to on. (Only affects ``--vo=gpu-next``, note that ``--vo=gpu`` always
|
2021-04-09 07:14:54 +00:00
|
|
|
invalidates interpolated frames)
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--opengl-pbo``
|
|
|
|
Enable use of PBOs. On some drivers this can be faster, especially if the
|
|
|
|
source video size is huge (e.g. so called "4K" video). On other drivers it
|
|
|
|
might be slower or cause latency issues.
|
|
|
|
|
|
|
|
``--dither-depth=<N|no|auto>``
|
|
|
|
Set dither target depth to N. Default: no.
|
|
|
|
|
|
|
|
no
|
|
|
|
Disable any dithering done by mpv.
|
|
|
|
auto
|
|
|
|
Automatic selection. If output bit depth cannot be detected, 8 bits per
|
|
|
|
component are assumed.
|
|
|
|
8
|
|
|
|
Dither to 8 bit output.
|
|
|
|
|
|
|
|
Note that the depth of the connected video display device cannot be
|
|
|
|
detected. Often, LCD panels will do dithering on their own, which conflicts
|
|
|
|
with this option and leads to ugly output.
|
|
|
|
|
|
|
|
``--dither-size-fruit=<2-8>``
|
|
|
|
Set the size of the dither matrix (default: 6). The actual size of the
|
|
|
|
matrix is ``(2^N) x (2^N)`` for an option value of ``N``, so a value of 6
|
|
|
|
gives a size of 64x64. The matrix is generated at startup time, and a large
|
|
|
|
matrix can take rather long to compute (seconds).
|
|
|
|
|
|
|
|
Used in ``--dither=fruit`` mode only.
|
|
|
|
|
2019-03-16 11:19:51 +00:00
|
|
|
``--dither=<fruit|ordered|error-diffusion|no>``
|
2016-09-02 13:59:40 +00:00
|
|
|
Select dithering algorithm (default: fruit). (Normally, the
|
|
|
|
``--dither-depth`` option controls whether dithering is enabled.)
|
|
|
|
|
2019-03-16 11:19:51 +00:00
|
|
|
The ``error-diffusion`` option requires compute shader support. It also
|
|
|
|
requires large amount of shared memory to run, the size of which depends on
|
|
|
|
both the kernel (see ``--error-diffusion`` option below) and the height of
|
|
|
|
video window. It will fallback to ``fruit`` dithering if there is no enough
|
|
|
|
shared memory to run the shader.
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--temporal-dither``
|
|
|
|
Enable temporal dithering. (Only active if dithering is enabled in
|
|
|
|
general.) This changes between 8 different dithering patterns on each frame
|
|
|
|
by changing the orientation of the tiled dithering matrix. Unfortunately,
|
|
|
|
this can lead to flicker on LCD displays, since these have a high reaction
|
|
|
|
time.
|
|
|
|
|
|
|
|
``--temporal-dither-period=<1-128>``
|
|
|
|
Determines how often the dithering pattern is updated when
|
|
|
|
``--temporal-dither`` is in use. 1 (the default) will update on every video
|
|
|
|
frame, 2 on every other frame, etc.
|
|
|
|
|
2019-03-16 11:19:51 +00:00
|
|
|
``--error-diffusion=<kernel>``
|
|
|
|
The error diffusion kernel to use when ``--dither=error-diffusion`` is set.
|
|
|
|
|
|
|
|
``simple``
|
|
|
|
Propagate error to only two adjacent pixels. Fastest but low quality.
|
|
|
|
|
|
|
|
``sierra-lite``
|
|
|
|
Fast with reasonable quality. This is the default.
|
|
|
|
|
|
|
|
``floyd-steinberg``
|
|
|
|
Most notable error diffusion kernel.
|
|
|
|
|
|
|
|
``atkinson``
|
|
|
|
Looks different from other kernels because only fraction of errors will
|
|
|
|
be propagated during dithering. A typical use case of this kernel is
|
|
|
|
saving dithered screenshot (in window mode). This kernel produces
|
|
|
|
slightly smaller file, with still reasonable dithering quality.
|
|
|
|
|
|
|
|
There are other kernels (use ``--error-diffusion=help`` to list) but most of
|
|
|
|
them are much slower and demanding even larger amount of shared memory.
|
|
|
|
Among these kernels, ``burkes`` achieves a good balance between performance
|
|
|
|
and quality, and probably is the one you want to try first.
|
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gpu-debug``
|
|
|
|
Enables GPU debugging. What this means depends on the API type. For OpenGL,
|
|
|
|
it calls ``glGetError()``, and requests a debug context. For Vulkan, it
|
|
|
|
enables validation layers.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--opengl-swapinterval=<n>``
|
|
|
|
Interval in displayed frames between two buffer swaps. 1 is equivalent to
|
|
|
|
enable VSYNC, 0 to disable VSYNC. Defaults to 1 if not specified.
|
|
|
|
|
|
|
|
Note that this depends on proper OpenGL vsync support. On some platforms
|
|
|
|
and drivers, this only works reliably when in fullscreen mode. It may also
|
|
|
|
require driver-specific hacks if using multiple monitors, to ensure mpv
|
|
|
|
syncs to the right one. Compositing window managers can also lead to bad
|
|
|
|
results, as can missing or incorrect display FPS information (see
|
2019-11-24 23:47:53 +00:00
|
|
|
``--override-display-fps``).
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_gpu: vulkan: implement a VkDisplayKHR backed context
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
2019-12-02 02:37:40 +00:00
|
|
|
``--vulkan-device=<device name>``
|
|
|
|
The name of the Vulkan device to use for rendering and presentation. Use
|
|
|
|
``--vulkan-device=help`` to see the list of available devices and their
|
|
|
|
names. If left unspecified, the first enumerated hardware Vulkan device will
|
|
|
|
be used.
|
|
|
|
|
vo_gpu: vulkan: initial implementation
This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop!
Current problems / limitations / improvement opportunities:
1. The swapchain/flipping code violates the vulkan spec, by assuming
that the presentation queue will be bounded (in cases where rendering
is significantly faster than vsync). But apparently, there's simply
no better way to do this right now, to the point where even the
stupid cube.c examples from LunarG etc. do it wrong.
(cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370)
2. The memory allocator could be improved. (This is a universal
constant)
3. Could explore using push descriptors instead of descriptor sets,
especially since we expect to switch descriptors semi-often for some
passes (like interpolation). Probably won't make a difference, but
the synchronization overhead might be a factor. Who knows.
4. Parallelism across frames / async transfer is not well-defined, we
either need to use a better semaphore / command buffer strategy or a
resource pooling layer to safely handle cross-frame parallelism.
(That said, I gave resource pooling a try and was not happy with the
result at all - so I'm still exploring the semaphore strategy)
5. We aggressively use pipeline barriers where events would offer a much
more fine-grained synchronization mechanism. As a result of this, we
might be suffering from GPU bubbles due to too-short dependencies on
objects. (That said, I'm also exploring the use of semaphores as a an
ordering tactic which would allow cross-frame time slicing in theory)
Some minor changes to the vo_gpu and infrastructure, but nothing
consequential.
NOTE: For safety, all use of asynchronous commands / multiple command
pools is currently disabled completely. There are some left-over relics
of this in the code (e.g. the distinction between dev_poll and
pool_poll), but that is kept in place mostly because this will be
re-extended in the future (vulkan rev 2).
The queue count is also currently capped to 1, because of the lack of
cross-frame semaphores means we need the implicit synchronization from
the same-queue semantics to guarantee a correct result.
2016-09-14 18:54:18 +00:00
|
|
|
``--vulkan-swap-mode=<mode>``
|
|
|
|
Controls the presentation mode of the vulkan swapchain. This is similar
|
|
|
|
to the ``--opengl-swapinterval`` option.
|
|
|
|
|
|
|
|
auto
|
|
|
|
Use the preferred swapchain mode for the vulkan context. (Default)
|
|
|
|
fifo
|
|
|
|
Non-tearing, vsync blocked. Similar to "VSync on".
|
|
|
|
fifo-relaxed
|
|
|
|
Tearing, vsync blocked. Late frames will tear instead of stuttering.
|
|
|
|
mailbox
|
|
|
|
Non-tearing, not vsync blocked. Similar to "triple buffering".
|
|
|
|
immediate
|
|
|
|
Tearing, not vsync blocked. Similar to "VSync off".
|
|
|
|
|
|
|
|
``--vulkan-queue-count=<1..8>``
|
|
|
|
Controls the number of VkQueues used for rendering (limited by how many
|
|
|
|
your device supports). In theory, using more queues could enable some
|
|
|
|
parallelism between frames (when using a ``--swapchain-depth`` higher than
|
vo_gpu: vulkan: support split command pools
Instead of using a single primary queue, we generate multiple
vk_cmdpools and pick the right one dynamically based on the intent.
This has a number of immediate benefits:
1. We can use async texture uploads
2. We can use the DMA engine for buffer updates
3. We can benefit from async compute on AMD GPUs
Unfortunately, the major downside is that due to the lack of QF
ownership tracking, we need to use CONCURRENT sharing for all resources
(buffers *and* images!). In theory, we could try figuring out a way to
get rid of the concurrent sharing for buffers (which is only needed for
compute shader UBOs), but even so, the concurrent sharing mode doesn't
really seem to have a significant impact over here (nvidia). It's
possible that other platforms may disagree.
Our deadlock-avoidance strategy is stupidly simple: Just flush the
command every time we need to switch queues, and make sure all
submission and callbacks happen in FIFO order. This required lifting the
cmds_pending and cmds_queued out from vk_cmdpool to mpvk_ctx, and some
functions died/got moved as a result, but that's a relatively minor
change.
On my hardware this is a fairly significant performance boost, mainly
due to async transfers. (Nvidia doesn't expose separate compute queues
anyway). On AMD, this should be a performance boost as well due to async
compute.
2017-09-24 13:05:24 +00:00
|
|
|
1), but it can also slow things down on hardware where there's no true
|
|
|
|
parallelism between queues. (Default: 1)
|
vo_gpu: vulkan: initial implementation
This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop!
Current problems / limitations / improvement opportunities:
1. The swapchain/flipping code violates the vulkan spec, by assuming
that the presentation queue will be bounded (in cases where rendering
is significantly faster than vsync). But apparently, there's simply
no better way to do this right now, to the point where even the
stupid cube.c examples from LunarG etc. do it wrong.
(cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370)
2. The memory allocator could be improved. (This is a universal
constant)
3. Could explore using push descriptors instead of descriptor sets,
especially since we expect to switch descriptors semi-often for some
passes (like interpolation). Probably won't make a difference, but
the synchronization overhead might be a factor. Who knows.
4. Parallelism across frames / async transfer is not well-defined, we
either need to use a better semaphore / command buffer strategy or a
resource pooling layer to safely handle cross-frame parallelism.
(That said, I gave resource pooling a try and was not happy with the
result at all - so I'm still exploring the semaphore strategy)
5. We aggressively use pipeline barriers where events would offer a much
more fine-grained synchronization mechanism. As a result of this, we
might be suffering from GPU bubbles due to too-short dependencies on
objects. (That said, I'm also exploring the use of semaphores as a an
ordering tactic which would allow cross-frame time slicing in theory)
Some minor changes to the vo_gpu and infrastructure, but nothing
consequential.
NOTE: For safety, all use of asynchronous commands / multiple command
pools is currently disabled completely. There are some left-over relics
of this in the code (e.g. the distinction between dev_poll and
pool_poll), but that is kept in place mostly because this will be
re-extended in the future (vulkan rev 2).
The queue count is also currently capped to 1, because of the lack of
cross-frame semaphores means we need the implicit synchronization from
the same-queue semantics to guarantee a correct result.
2016-09-14 18:54:18 +00:00
|
|
|
|
2017-10-07 19:36:16 +00:00
|
|
|
``--vulkan-async-transfer``
|
|
|
|
Enables the use of async transfer queues on supported vulkan devices. Using
|
|
|
|
them allows transfer operations like texture uploads and blits to happen
|
|
|
|
concurrently with the actual rendering, thus improving overall throughput
|
|
|
|
and power consumption. Enabled by default, and should be relatively safe.
|
|
|
|
|
|
|
|
``--vulkan-async-compute``
|
|
|
|
Enables the use of async compute queues on supported vulkan devices. Using
|
|
|
|
this, in theory, allows out-of-order scheduling of compute shaders with
|
|
|
|
graphics shaders, thus enabling the hardware to do more effective work while
|
|
|
|
waiting for pipeline bubbles and memory operations. Not beneficial on all
|
|
|
|
GPUs. It's worth noting that if async compute is enabled, and the device
|
|
|
|
supports more compute queues than graphics queues (bound by the restrictions
|
|
|
|
set by ``--vulkan-queue-count``), mpv will internally try and prefer the
|
2019-12-12 11:46:59 +00:00
|
|
|
use of compute shaders over fragment shaders wherever possible. Enabled by
|
|
|
|
default, although Nvidia users may want to disable it.
|
2017-10-07 19:36:16 +00:00
|
|
|
|
vo_gpu: vulkan: implement a VkDisplayKHR backed context
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
2019-12-02 02:37:40 +00:00
|
|
|
``--vulkan-display-display=<n>``
|
|
|
|
The index of the display, on the selected Vulkan device, to present on when
|
|
|
|
using the ``displayvk`` GPU context. Use ``--vulkan-display-display=help``
|
|
|
|
to see the list of available displays. If left unspecified, the first
|
|
|
|
enumerated display will be used.
|
|
|
|
|
|
|
|
|
|
|
|
``--vulkan-display-mode=<n>``
|
|
|
|
The index of the display mode, of the selected Vulkan display, to use when
|
|
|
|
using the ``displayvk`` GPU context. Use ``--vulkan-display-mode=help``
|
|
|
|
to see the list of available modes. If left unspecified, the first
|
|
|
|
enumerated mode will be used.
|
|
|
|
|
|
|
|
``--vulkan-display-plane=<n>``
|
|
|
|
The index of the plane, on the selected Vulkan device, to present on when
|
|
|
|
using the ``displayvk`` GPU context. Use ``--vulkan-display-plane=help``
|
|
|
|
to see the list of available planes. If left unspecified, the first
|
|
|
|
enumerated plane will be used.
|
|
|
|
|
2017-12-26 09:50:31 +00:00
|
|
|
``--d3d11-exclusive-fs=<yes|no>``
|
|
|
|
Switches the D3D11 swap chain fullscreen state to 'fullscreen' when
|
|
|
|
fullscreen video is requested. Also known as "exclusive fullscreen" or
|
|
|
|
"D3D fullscreen" in other applications. Gives mpv full control of
|
|
|
|
rendering on the swap chain's screen. Off by default.
|
|
|
|
|
vo_gpu: d3d11: initial implementation
This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL
generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross.
What works:
- All of mpv's internal shaders should work, including compute shaders.
- Some external shaders have been tested and work, including RAVU and
adaptive-sharpen.
- Non-dumb mode works, even on very old hardware. Most features work at
feature level 9_3 and all features work at feature level 10_0. Some
features also work at feature level 9_1 and 9_2, but without high-bit-
depth FBOs, it's not very useful. (Hardware this old is probably not
fast enough for advanced features anyway.)
Note: This is more compatible than ANGLE, which requires 9_3 to work
at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.)
- Hardware decoding with D3D11VA, including decoding of 10-bit formats
without truncation to 8-bit.
What doesn't work / can be improved:
- PBO upload and direct rendering does not work yet. Direct rendering
requires persistent-mapped PBOs because the decoder needs to be able
to read data from images that have already been decoded and uploaded.
Unfortunately, it seems like persistent-mapped PBOs are fundamentally
incompatible with D3D11, which requires all resources to use driver-
managed memory and requires memory to be unmapped (and hence pointers
to be invalidated) when a resource is used in a draw or copy
operation.
However it might be possible to use D3D11's limited multithreading
capabilities to emulate some features of PBOs, like asynchronous
texture uploading.
- The blit() and clear() operations don't have equivalents in the D3D11
API that handle all cases, so in most cases, they have to be emulated
with a shader. This is currently done inside ra_d3d11, but ideally it
would be done in generic code, so it can take advantage of mpv's
shader generation utilities.
- SPIRV-Cross is used through a NIH C-compatible wrapper library, since
it does not expose a C interface itself.
The library is available here: https://github.com/rossy/crossc
- The D3D11 context could be made to support more modern DXGI features
in future. For example, it should be possible to add support for
high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 10:18:06 +00:00
|
|
|
``--d3d11-warp=<yes|no|auto>``
|
|
|
|
Use WARP (Windows Advanced Rasterization Platform) with the D3D11 GPU
|
|
|
|
backend (default: auto). This is a high performance software renderer. By
|
|
|
|
default, it is only used when the system has no hardware adapters that
|
|
|
|
support D3D11. While the extended GPU features will work with WARP, they
|
|
|
|
can be very slow.
|
|
|
|
|
|
|
|
``--d3d11-feature-level=<12_1|12_0|11_1|11_0|10_1|10_0|9_3|9_2|9_1>``
|
|
|
|
Select a specific feature level when using the D3D11 GPU backend. By
|
|
|
|
default, the highest available feature level is used. This option can be
|
|
|
|
used to select a lower feature level, which is mainly useful for debugging.
|
|
|
|
Most extended GPU features will not work at 9_x feature levels.
|
|
|
|
|
|
|
|
``--d3d11-flip=<yes|no>``
|
|
|
|
Enable flip-model presentation, which avoids unnecessarily copying the
|
|
|
|
backbuffer by sharing surfaces with the DWM (default: yes). This may cause
|
|
|
|
performance issues with older drivers. If flip-model presentation is not
|
|
|
|
supported (for example, on Windows 7 without the platform update), mpv will
|
|
|
|
automatically fall back to the older bitblt presentation model.
|
|
|
|
|
|
|
|
``--d3d11-sync-interval=<0..4>``
|
|
|
|
Schedule each frame to be presented for this number of VBlank intervals.
|
|
|
|
(default: 1) Setting to 1 will enable VSync, setting to 0 will disable it.
|
|
|
|
|
2019-09-29 15:21:59 +00:00
|
|
|
``--d3d11-adapter=<adapter name|help>``
|
2019-04-19 22:26:39 +00:00
|
|
|
Select a specific D3D11 adapter to utilize for D3D11 rendering.
|
|
|
|
Will pick the default adapter if unset. Alternatives are listed
|
2019-09-29 15:21:59 +00:00
|
|
|
when the name "help" is given.
|
2019-04-19 22:26:39 +00:00
|
|
|
|
2019-10-14 17:30:09 +00:00
|
|
|
Checks for matches based on the start of the string, case
|
|
|
|
insensitive. Thus, if the description of the adapter starts with
|
|
|
|
the vendor name, that can be utilized as the selection parameter.
|
|
|
|
|
2019-04-19 22:26:39 +00:00
|
|
|
Hardware decoders utilizing the D3D11 rendering abstraction's helper
|
|
|
|
functionality to receive a device, such as D3D11VA or DXVA2's DXGI
|
|
|
|
mode, will be affected by this choice.
|
|
|
|
|
2019-10-11 21:35:22 +00:00
|
|
|
``--d3d11-output-format=<auto|rgba8|bgra8|rgb10_a2|rgba16f>``
|
|
|
|
Select a specific D3D11 output format to utilize for D3D11 rendering.
|
|
|
|
"auto" is the default, which will pick either rgba8 or rgb10_a2 depending
|
|
|
|
on the configured desktop bit depth. rgba16f and bgra8 are left out of
|
|
|
|
the autodetection logic, and are available for manual testing.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Desktop bit depth querying is only available from an API available
|
|
|
|
from Windows 10. Thus on older systems it will only automatically
|
|
|
|
utilize the rgba8 output format.
|
|
|
|
|
2018-05-06 00:01:58 +00:00
|
|
|
``--d3d11-output-csp=<auto|srgb|linear|pq|bt.2020>``
|
|
|
|
Select a specific D3D11 output color space to utilize for D3D11 rendering.
|
|
|
|
"auto" is the default, which will select the color space of the desktop
|
|
|
|
on which the swap chain is located.
|
|
|
|
|
|
|
|
Values other than "srgb" and "pq" have had issues in testing, so they
|
|
|
|
are mostly available for manual testing.
|
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
Swap chain color space configuration is only available from an API
|
|
|
|
available from Windows 10. Thus on older systems it will not work.
|
|
|
|
|
2017-11-01 11:38:41 +00:00
|
|
|
``--d3d11va-zero-copy=<yes|no>``
|
|
|
|
By default, when using hardware decoding with ``--gpu-api=d3d11``, the
|
|
|
|
video image will be copied (GPU-to-GPU) from the decoder surface to a
|
|
|
|
shader resource. Set this option to avoid that copy by sampling directly
|
|
|
|
from the decoder image. This may increase performance and reduce power
|
|
|
|
usage, but can cause the image to be sampled incorrectly on the bottom and
|
|
|
|
right edges due to padding, and may invoke driver bugs, since Direct3D 11
|
|
|
|
technically does not allow sampling from a decoder surface (though most
|
|
|
|
drivers support it.)
|
|
|
|
|
|
|
|
Currently only relevant for ``--gpu-api=d3d11``.
|
|
|
|
|
2020-08-12 14:51:51 +00:00
|
|
|
``--wayland-app-id=<string>``
|
2021-06-26 22:19:45 +00:00
|
|
|
Set the client app id for Wayland-based video output methods (default: ``mpv``).
|
2020-08-12 14:51:51 +00:00
|
|
|
|
2023-01-26 20:21:58 +00:00
|
|
|
``--wayland-configure-bounds=<auto|yes|no>``
|
2022-05-31 13:36:15 +00:00
|
|
|
Controls whether or not mpv opts into the configure bounds event if sent by the
|
2023-01-26 20:21:58 +00:00
|
|
|
compositor (default: auto). This restricts the initial size of the mpv window to
|
2022-05-31 13:36:15 +00:00
|
|
|
a certain maximum size intended by the compositor. In most cases, this simply
|
|
|
|
just prevents the mpv window from being larger than the size of the monitor when
|
2023-01-26 20:21:58 +00:00
|
|
|
it first renders. With the default value of ``auto``, configure-bounds will
|
|
|
|
silently be ignored if any ``autofit`` or ``geometry`` type option is also set.
|
2022-05-31 13:36:15 +00:00
|
|
|
|
wayland: add support for content-type protocol
The content-type protocol allows mpv to send compositor a hint about the
type of content being displayed on its surface so it could potentially
make some sort of optimization. Fundamentally, this is pretty simple but
since this requires a very new wayland-protocols version (1.27), we have
to mess with the build to add a new define and add a bunch of if's in
here. The protocol itself exposes 4 different types of content: none,
photo, video, and game.
To do that, let's add a new option (wayland-content-type) that lets
users control what hint to send to the compossitor. Since the previous
commit adds a VOCTRL that notifies us about the content being displayed,
we can also add an auto value to this option. As you'd expect, the
compositor hint would be set to photo if mpv's core detects an image,
video for other things, and it is set to none for the special case of
forcing a window when there is not a video track. For completion's sake,
game is also allowed as a value for this option, but in practice there
shouldn't be a reason to use that.
2022-11-15 21:51:45 +00:00
|
|
|
``--wayland-content-type=<auto|none|photo|video|game>``
|
|
|
|
If supported by the compositor, mpv will send a hint using the content-type
|
|
|
|
protocol telling the compositor what type of content is being displayed. ``auto``
|
|
|
|
(default) will automatically switch between telling the compositor the content
|
|
|
|
is a photo, video or possibly none depending on internal heuristics.
|
|
|
|
|
2019-10-14 17:16:42 +00:00
|
|
|
``--wayland-disable-vsync=<yes|no>``
|
2022-08-13 04:14:09 +00:00
|
|
|
Disable mpv's internal vsync for Wayland-based video output (default: no).
|
|
|
|
This is mainly useful for benchmarking wayland VOs when combined with
|
|
|
|
``video-sync=display-desync``, ``--no-audio``, and ``--untimed=yes``.
|
2019-10-14 17:16:42 +00:00
|
|
|
|
2020-05-08 16:34:20 +00:00
|
|
|
``--wayland-edge-pixels-pointer=<value>``
|
2023-03-07 17:24:53 +00:00
|
|
|
Defines the size of an edge border (default: 16) to initiate client side
|
2020-05-08 16:34:20 +00:00
|
|
|
resize events in the wayland contexts with the mouse. This is only active if
|
|
|
|
there are no server side decorations from the compositor.
|
|
|
|
|
|
|
|
``--wayland-edge-pixels-touch=<value>``
|
2021-08-08 03:05:05 +00:00
|
|
|
Defines the size of an edge border (default: 32) to initiate client side
|
2020-05-08 16:34:20 +00:00
|
|
|
resizes events in the wayland contexts with touch events.
|
|
|
|
|
2017-09-13 01:09:48 +00:00
|
|
|
``--spirv-compiler=<compiler>``
|
|
|
|
Controls which compiler is used to translate GLSL to SPIR-V. This is
|
2018-11-24 03:25:30 +00:00
|
|
|
(currently) only relevant for ``--gpu-api=vulkan`` and `--gpu-api=d3d11`.
|
|
|
|
The possible choices are currently only:
|
2017-09-13 01:09:48 +00:00
|
|
|
|
|
|
|
auto
|
|
|
|
Use the first available compiler. (Default)
|
|
|
|
shaderc
|
|
|
|
Use libshaderc, which is an API wrapper around glslang. This is
|
|
|
|
generally the most preferred, if available.
|
2018-11-24 03:25:30 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
This option is deprecated, since there is only one reasonable value.
|
|
|
|
It may be removed in the future.
|
2017-09-13 01:09:48 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
``--glsl-shader=<file>``, ``--glsl-shaders=<file-list>``
|
2016-09-02 13:59:40 +00:00
|
|
|
Custom GLSL hooks. These are a flexible way to add custom fragment shaders,
|
|
|
|
which can be injected at almost arbitrary points in the rendering pipeline,
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
and access all previous intermediate textures.
|
|
|
|
|
|
|
|
Each use of the ``--glsl-shader`` option will add another file to the
|
|
|
|
internal list of shaders, while ``--glsl-shaders`` takes a list of files,
|
|
|
|
and overwrites the internal list with it. The latter is a path list option
|
|
|
|
(see `List Options`_ for details).
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
.. admonition:: Warning
|
|
|
|
|
|
|
|
The syntax is not stable yet and may change any time.
|
|
|
|
|
|
|
|
The general syntax of a user shader looks like this::
|
|
|
|
|
|
|
|
//!METADATA ARGS...
|
|
|
|
//!METADATA ARGS...
|
|
|
|
|
|
|
|
vec4 hook() {
|
|
|
|
...
|
|
|
|
return something;
|
|
|
|
}
|
|
|
|
|
|
|
|
//!METADATA ARGS...
|
|
|
|
//!METADATA ARGS...
|
|
|
|
|
|
|
|
...
|
|
|
|
|
2017-07-10 23:59:21 +00:00
|
|
|
Each section of metadata, along with the non-metadata lines after it,
|
|
|
|
defines a single block. There are currently two types of blocks, HOOKs and
|
|
|
|
TEXTUREs.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2017-07-10 23:59:21 +00:00
|
|
|
A ``TEXTURE`` block can set the following options:
|
|
|
|
|
|
|
|
TEXTURE <name> (required)
|
|
|
|
The name of this texture. Hooks can then bind the texture under this
|
|
|
|
name using BIND. This must be the first option of the texture block.
|
|
|
|
|
2017-08-03 14:08:18 +00:00
|
|
|
SIZE <width> [<height>] [<depth>] (required)
|
2017-07-10 23:59:21 +00:00
|
|
|
The dimensions of the texture. The height and depth are optional. The
|
|
|
|
type of texture (1D, 2D or 3D) depends on the number of components
|
|
|
|
specified.
|
|
|
|
|
2017-08-03 14:08:18 +00:00
|
|
|
FORMAT <name> (required)
|
|
|
|
The texture format for the samples. Supported texture formats are listed
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
in debug logging when the ``gpu`` VO is initialized (look for
|
2017-08-03 14:08:18 +00:00
|
|
|
``Texture formats:``). Usually, this follows OpenGL naming conventions.
|
|
|
|
For example, ``rgb16`` provides 3 channels with normalized 16 bit
|
|
|
|
components. One oddity are float formats: for example, ``rgba16f`` has
|
|
|
|
16 bit internal precision, but the texture data is provided as 32 bit
|
|
|
|
floats, and the driver converts the data on texture upload.
|
|
|
|
|
|
|
|
Although format names follow a common naming convention, not all of them
|
|
|
|
are available on all hardware, drivers, GL versions, and so on.
|
2017-07-10 23:59:21 +00:00
|
|
|
|
|
|
|
FILTER <LINEAR|NEAREST>
|
|
|
|
The min/magnification filter used when sampling from this texture.
|
|
|
|
|
|
|
|
BORDER <CLAMP|REPEAT|MIRROR>
|
|
|
|
The border wrapping mode used when sampling from this texture.
|
|
|
|
|
|
|
|
Following the metadata is a string of bytes in hexadecimal notation that
|
|
|
|
define the raw texture data, corresponding to the format specified by
|
|
|
|
`FORMAT`, on a single line with no extra whitespace.
|
|
|
|
|
|
|
|
A ``HOOK`` block can set the following options:
|
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
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
HOOK <name> (required)
|
|
|
|
The texture which to hook into. May occur multiple times within a
|
|
|
|
metadata block, up to a predetermined limit. See below for a list of
|
|
|
|
hookable textures.
|
|
|
|
|
2017-07-10 23:59:21 +00:00
|
|
|
DESC <title>
|
|
|
|
User-friendly description of the pass. This is the name used when
|
|
|
|
representing this shader in the list of passes for property
|
|
|
|
`vo-passes`.
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
BIND <name>
|
2017-07-10 23:59:21 +00:00
|
|
|
Loads a texture (either coming from mpv or from a ``TEXTURE`` block)
|
|
|
|
and makes it available to the pass. When binding textures from mpv,
|
|
|
|
this will also set up macros to facilitate accessing it properly. See
|
|
|
|
below for a list. By default, no textures are bound. The special name
|
|
|
|
HOOKED can be used to refer to the texture that triggered this pass.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
SAVE <name>
|
|
|
|
Gives the name of the texture to save the result of this pass into. By
|
|
|
|
default, this is set to the special name HOOKED which has the effect of
|
|
|
|
overwriting the hooked texture.
|
|
|
|
|
|
|
|
WIDTH <szexpr>, HEIGHT <szexpr>
|
|
|
|
Specifies the size of the resulting texture for this pass. ``szexpr``
|
|
|
|
refers to an expression in RPN (reverse polish notation), using the
|
|
|
|
operators + - * / > < !, floating point literals, and references to
|
2016-07-03 12:06:41 +00:00
|
|
|
sizes of existing texture (such as MAIN.width or CHROMA.height),
|
|
|
|
OUTPUT, or NATIVE_CROPPED (size of an input texture cropped after
|
|
|
|
pan-and-scan, video-align-x/y, video-pan-x/y, etc. and possibly
|
|
|
|
prescaled). By default, these are set to HOOKED.w and HOOKED.h,
|
|
|
|
espectively.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
WHEN <szexpr>
|
|
|
|
Specifies a condition that needs to be true (non-zero) for the shader
|
|
|
|
stage to be evaluated. If it fails, it will silently be omitted. (Note
|
|
|
|
that a shader stage like this which has a dependency on an optional
|
|
|
|
hook point can still cause that hook point to be saved, which has some
|
|
|
|
minor overhead)
|
|
|
|
|
2019-03-12 02:24:51 +00:00
|
|
|
OFFSET <ox oy | ALIGN>
|
2016-09-02 13:59:40 +00:00
|
|
|
Indicates a pixel shift (offset) introduced by this pass. These pixel
|
|
|
|
offsets will be accumulated and corrected during the next scaling pass
|
|
|
|
(``cscale`` or ``scale``). The default values are 0 0 which correspond
|
|
|
|
to no shift. Note that offsets are ignored when not overwriting the
|
|
|
|
hooked texture.
|
|
|
|
|
2019-03-12 02:24:51 +00:00
|
|
|
A special value of ``ALIGN`` will attempt to fix existing offset of
|
|
|
|
HOOKED by align it with reference. It requires HOOKED to be resizable
|
|
|
|
(see below). It works transparently with fragment shader. For compute
|
|
|
|
shader, the predefined ``texmap`` macro is required to handle coordinate
|
|
|
|
mapping.
|
|
|
|
|
2017-07-10 23:59:21 +00:00
|
|
|
COMPONENTS <n>
|
2016-09-02 13:59:40 +00:00
|
|
|
Specifies how many components of this pass's output are relevant and
|
|
|
|
should be stored in the texture, up to 4 (rgba). By default, this value
|
|
|
|
is equal to the number of components in HOOKED.
|
|
|
|
|
2017-07-29 18:41:50 +00:00
|
|
|
COMPUTE <bw> <bh> [<tw> <th>]
|
2017-07-20 09:26:01 +00:00
|
|
|
Specifies that this shader should be treated as a compute shader, with
|
|
|
|
the block size bw and bh. The compute shader will be dispatched with
|
|
|
|
however many blocks are necessary to completely tile over the output.
|
2021-08-29 15:25:39 +00:00
|
|
|
Within each block, there will be tw*th threads, forming a single work
|
2017-07-29 18:41:50 +00:00
|
|
|
group. In other words: tw and th specify the work group size, which can
|
|
|
|
be different from the block size. So for example, a compute shader with
|
|
|
|
bw, bh = 32 and tw, th = 8 running on a 500x500 texture would dispatch
|
|
|
|
16x16 blocks (rounded up), each with 8x8 threads.
|
|
|
|
|
|
|
|
Compute shaders in mpv are treated a bit different from fragment
|
|
|
|
shaders. Instead of defining a ``vec4 hook`` that produces an output
|
|
|
|
sample, you directly define ``void hook`` which writes to a fixed
|
|
|
|
writeonly image unit named ``out_image`` (this is bound by mpv) using
|
|
|
|
`imageStore`. To help translate texture coordinates in the absence of
|
|
|
|
vertices, mpv provides a special function ``NAME_map(id)`` to map from
|
|
|
|
the texel space of the output image to the texture coordinates for all
|
|
|
|
bound textures. In particular, ``NAME_pos`` is equivalent to
|
|
|
|
``NAME_map(gl_GlobalInvocationID)``, although using this only really
|
|
|
|
makes sense if (tw,th) == (bw,bh).
|
2017-07-20 09:26:01 +00:00
|
|
|
|
2017-07-10 23:59:21 +00:00
|
|
|
Each bound mpv texture (via ``BIND``) will make available the following
|
2016-09-02 13:59:40 +00:00
|
|
|
definitions to that shader pass, where NAME is the name of the bound
|
|
|
|
texture:
|
|
|
|
|
|
|
|
vec4 NAME_tex(vec2 pos)
|
|
|
|
The sampling function to use to access the texture at a certain spot
|
|
|
|
(in texture coordinate space, range [0,1]). This takes care of any
|
|
|
|
necessary normalization conversions.
|
|
|
|
vec4 NAME_texOff(vec2 offset)
|
|
|
|
Sample the texture at a certain offset in pixels. This works like
|
|
|
|
NAME_tex but additionally takes care of necessary rotations, so that
|
|
|
|
sampling at e.g. vec2(-1,0) is always one pixel to the left.
|
|
|
|
vec2 NAME_pos
|
|
|
|
The local texture coordinate of that texture, range [0,1].
|
|
|
|
vec2 NAME_size
|
|
|
|
The (rotated) size in pixels of the texture.
|
|
|
|
mat2 NAME_rot
|
|
|
|
The rotation matrix associated with this texture. (Rotates pixel space
|
|
|
|
to texture coordinates)
|
|
|
|
vec2 NAME_pt
|
|
|
|
The (unrotated) size of a single pixel, range [0,1].
|
2017-07-06 09:27:24 +00:00
|
|
|
float NAME_mul
|
|
|
|
The coefficient that needs to be multiplied into the texture contents
|
|
|
|
in order to normalize it to the range [0,1].
|
2016-09-02 13:59:40 +00:00
|
|
|
sampler NAME_raw
|
|
|
|
The raw bound texture itself. The use of this should be avoided unless
|
|
|
|
absolutely necessary.
|
|
|
|
|
2017-07-06 09:27:24 +00:00
|
|
|
Normally, users should use either NAME_tex or NAME_texOff to read from the
|
|
|
|
texture. For some shaders however , it can be better for performance to do
|
|
|
|
custom sampling from NAME_raw, in which case care needs to be taken to
|
|
|
|
respect NAME_mul and NAME_rot.
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
In addition to these parameters, the following uniforms are also globally
|
|
|
|
available:
|
|
|
|
|
|
|
|
float random
|
|
|
|
A random number in the range [0-1], different per frame.
|
|
|
|
int frame
|
|
|
|
A simple count of frames rendered, increases by one per frame and never
|
|
|
|
resets (regardless of seeks).
|
2017-03-19 14:13:51 +00:00
|
|
|
vec2 input_size
|
|
|
|
The size in pixels of the input image (possibly cropped and prescaled).
|
2016-09-02 13:59:40 +00:00
|
|
|
vec2 target_size
|
|
|
|
The size in pixels of the visible part of the scaled (and possibly
|
|
|
|
cropped) image.
|
2016-07-15 06:26:35 +00:00
|
|
|
vec2 tex_offset
|
|
|
|
Texture offset introduced by user shaders or options like panscan, video-align-x/y, video-pan-x/y.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
Internally, vo_gpu may generate any number of the following textures.
|
|
|
|
Whenever a texture is rendered and saved by vo_gpu, all of the passes
|
2016-09-02 13:59:40 +00:00
|
|
|
that have hooked into it will run, in the order they were added by the
|
|
|
|
user. This is a list of the legal hook points:
|
|
|
|
|
|
|
|
RGB, LUMA, CHROMA, ALPHA, XYZ (resizable)
|
|
|
|
Source planes (raw). Which of these fire depends on the image format of
|
|
|
|
the source.
|
|
|
|
|
|
|
|
CHROMA_SCALED, ALPHA_SCALED (fixed)
|
|
|
|
Source planes (upscaled). These only fire on subsampled content.
|
|
|
|
|
|
|
|
NATIVE (resizable)
|
|
|
|
The combined image, in the source colorspace, before conversion to RGB.
|
|
|
|
|
|
|
|
MAINPRESUB (resizable)
|
|
|
|
The image, after conversion to RGB, but before
|
|
|
|
``--blend-subtitles=video`` is applied.
|
|
|
|
|
|
|
|
MAIN (resizable)
|
|
|
|
The main image, after conversion to RGB but before upscaling.
|
|
|
|
|
|
|
|
LINEAR (fixed)
|
|
|
|
Linear light image, before scaling. This only fires when
|
2018-10-17 09:23:16 +00:00
|
|
|
``--linear-upscaling``, ``--linear-downscaling`` or
|
|
|
|
``--sigmoid-upscaling`` is in effect.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
SIGMOID (fixed)
|
|
|
|
Sigmoidized light, before scaling. This only fires when
|
|
|
|
``--sigmoid-upscaling`` is in effect.
|
|
|
|
|
|
|
|
PREKERNEL (fixed)
|
|
|
|
The image immediately before the scaler kernel runs.
|
|
|
|
|
|
|
|
POSTKERNEL (fixed)
|
|
|
|
The image immediately after the scaler kernel runs.
|
|
|
|
|
|
|
|
SCALED (fixed)
|
|
|
|
The final upscaled image, before color management.
|
|
|
|
|
|
|
|
OUTPUT (fixed)
|
|
|
|
The final output image, after color management but before dithering and
|
|
|
|
drawing to screen.
|
|
|
|
|
|
|
|
Only the textures labelled with ``resizable`` may be transformed by the
|
|
|
|
pass. When overwriting a texture marked ``fixed``, the WIDTH, HEIGHT and
|
|
|
|
OFFSET must be left at their default values.
|
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--glsl-shader=<file>``
|
|
|
|
CLI/config file only alias for ``--glsl-shaders-append``.
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
|
2022-11-03 15:16:59 +00:00
|
|
|
``--glsl-shader-opts=param1=value1,param2=value2,...``
|
|
|
|
Specifies the options to use for tunable shader parameters. You can target
|
|
|
|
specific named shaders by prefixing the shader name with a ``/``, e.g.
|
|
|
|
``shader/param=value``. Without a prefix, parameters affect all shaders.
|
|
|
|
The shader name is the base part of the shader filename, without the
|
|
|
|
extension. (``--vo=gpu-next`` only)
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--deband``
|
|
|
|
Enable the debanding algorithm. This greatly reduces the amount of visible
|
2018-05-16 23:58:27 +00:00
|
|
|
banding, blocking and other quantization artifacts, at the expense of
|
2016-09-02 13:59:40 +00:00
|
|
|
very slightly blurring some of the finest details. In practice, it's
|
|
|
|
virtually always an improvement - the only reason to disable it would be
|
|
|
|
for performance.
|
|
|
|
|
|
|
|
``--deband-iterations=<1..16>``
|
|
|
|
The number of debanding steps to perform per sample. Each step reduces a
|
|
|
|
bit more banding, but takes time to compute. Note that the strength of each
|
|
|
|
step falls off very quickly, so high numbers (>4) are practically useless.
|
|
|
|
(Default 1)
|
|
|
|
|
|
|
|
``--deband-threshold=<0..4096>``
|
|
|
|
The debanding filter's cut-off threshold. Higher numbers increase the
|
|
|
|
debanding strength dramatically but progressively diminish image details.
|
2021-02-05 14:37:16 +00:00
|
|
|
(Default 32)
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--deband-range=<1..64>``
|
|
|
|
The debanding filter's initial radius. The radius increases linearly for
|
|
|
|
each iteration. A higher radius will find more gradients, but a lower
|
|
|
|
radius will smooth more aggressively. (Default 16)
|
|
|
|
|
|
|
|
If you increase the ``--deband-iterations``, you should probably decrease
|
|
|
|
this to compensate.
|
|
|
|
|
|
|
|
``--deband-grain=<0..4096>``
|
|
|
|
Add some extra noise to the image. This significantly helps cover up
|
|
|
|
remaining quantization artifacts. Higher numbers add more noise. (Default
|
|
|
|
48)
|
|
|
|
|
2023-06-19 11:06:01 +00:00
|
|
|
``--corner-rounding=<0..1>``
|
|
|
|
If set to a value above 0.0, the output will be rendered with rounded
|
|
|
|
corners, as if an alpha transparency mask had been applied. The value
|
|
|
|
indicates the relative fraction of the side length to round - a value of
|
|
|
|
1.0 rounds the corners as much as possible. (``--vo=gpu-next`` only)
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--sharpen=<value>``
|
|
|
|
If set to a value other than 0, enable an unsharp masking filter. Positive
|
|
|
|
values will sharpen the image (but add more ringing and aliasing). Negative
|
|
|
|
values will blur the image. If your GPU is powerful enough, consider
|
|
|
|
alternatives like the ``ewa_lanczossharp`` scale filter, or the
|
2021-11-03 14:36:04 +00:00
|
|
|
``--scale-blur`` option. (Only for ``--vo=gpu``)
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--opengl-glfinish``
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
Call ``glFinish()`` before swapping buffers (default: disabled). Slower,
|
|
|
|
but might improve results when doing framedropping. Can completely ruin
|
|
|
|
performance. The details depend entirely on the OpenGL driver.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--opengl-waitvsync``
|
|
|
|
Call ``glXWaitVideoSyncSGI`` after each buffer swap (default: disabled).
|
|
|
|
This may or may not help with video timing accuracy and frame drop. It's
|
|
|
|
possible that this makes video output slower, or has no effect at all.
|
|
|
|
|
|
|
|
X11/GLX only.
|
|
|
|
|
|
|
|
``--opengl-dwmflush=<no|windowed|yes|auto>``
|
|
|
|
Calls ``DwmFlush`` after swapping buffers on Windows (default: auto). It
|
|
|
|
also sets ``SwapInterval(0)`` to ignore the OpenGL timing. Values are: no
|
|
|
|
(disabled), windowed (only in windowed mode), yes (also in full screen).
|
|
|
|
|
|
|
|
The value ``auto`` will try to determine whether the compositor is active,
|
|
|
|
and calls ``DwmFlush`` only if it seems to be.
|
|
|
|
|
|
|
|
This may help to get more consistent frame intervals, especially with
|
|
|
|
high-fps clips - which might also reduce dropped frames. Typically, a value
|
|
|
|
of ``windowed`` should be enough, since full screen may bypass the DWM.
|
|
|
|
|
|
|
|
Windows only.
|
|
|
|
|
2017-02-04 08:16:02 +00:00
|
|
|
``--angle-d3d11-feature-level=<11_0|10_1|10_0|9_3>``
|
|
|
|
Selects a specific feature level when using the ANGLE backend with D3D11.
|
|
|
|
By default, the highest available feature level is used. This option can be
|
|
|
|
used to select a lower feature level, which is mainly useful for debugging.
|
|
|
|
Note that OpenGL ES 3.0 is only supported at feature level 10_1 or higher.
|
|
|
|
Most extended OpenGL features will not work at lower feature levels
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
(similar to ``--gpu-dumb-mode``).
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
Windows with ANGLE only.
|
|
|
|
|
2017-02-04 08:16:02 +00:00
|
|
|
``--angle-d3d11-warp=<yes|no|auto>``
|
|
|
|
Use WARP (Windows Advanced Rasterization Platform) when using the ANGLE
|
|
|
|
backend with D3D11 (default: auto). This is a high performance software
|
|
|
|
renderer. By default, it is used when the Direct3D hardware does not
|
|
|
|
support Direct3D 11 feature level 9_3. While the extended OpenGL features
|
|
|
|
will work with WARP, they can be very slow.
|
|
|
|
|
|
|
|
Windows with ANGLE only.
|
|
|
|
|
|
|
|
``--angle-egl-windowing=<yes|no|auto>``
|
|
|
|
Use ANGLE's built in EGL windowing functions to create a swap chain
|
|
|
|
(default: auto). If this is set to ``no`` and the D3D11 renderer is in use,
|
|
|
|
ANGLE's built in swap chain will not be used and a custom swap chain that
|
|
|
|
is optimized for video rendering will be created instead. If set to
|
|
|
|
``auto``, a custom swap chain will be used for D3D11 and the built in swap
|
|
|
|
chain will be used for D3D9. This option is mainly for debugging purposes,
|
|
|
|
in case the custom swap chain has poor performance or does not work.
|
|
|
|
|
2017-03-25 14:49:19 +00:00
|
|
|
If set to ``yes``, the ``--angle-max-frame-latency``,
|
|
|
|
``--angle-swapchain-length`` and ``--angle-flip`` options will have no
|
|
|
|
effect.
|
|
|
|
|
|
|
|
Windows with ANGLE only.
|
|
|
|
|
|
|
|
``--angle-flip=<yes|no>``
|
|
|
|
Enable flip-model presentation, which avoids unnecessarily copying the
|
|
|
|
backbuffer by sharing surfaces with the DWM (default: yes). This may cause
|
|
|
|
performance issues with older drivers. If flip-model presentation is not
|
|
|
|
supported (for example, on Windows 7 without the platform update), mpv will
|
|
|
|
automatically fall back to the older bitblt presentation model.
|
|
|
|
|
|
|
|
If set to ``no``, the ``--angle-swapchain-length`` option will have no
|
|
|
|
effect.
|
2017-02-04 08:16:02 +00:00
|
|
|
|
|
|
|
Windows with ANGLE only.
|
|
|
|
|
|
|
|
``--angle-renderer=<d3d9|d3d11|auto>``
|
|
|
|
Forces a specific renderer when using the ANGLE backend (default: auto). In
|
|
|
|
auto mode this will pick D3D11 for systems that support Direct3D 11 feature
|
|
|
|
level 9_3 or higher, and D3D9 otherwise. This option is mainly for
|
|
|
|
debugging purposes. Normally there is no reason to force a specific
|
|
|
|
renderer, though ``--angle-renderer=d3d9`` may give slightly better
|
|
|
|
performance on old hardware. Note that the D3D9 renderer only supports
|
|
|
|
OpenGL ES 2.0, so most extended OpenGL features will not work if this
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
renderer is selected (similar to ``--gpu-dumb-mode``).
|
2017-02-04 08:16:02 +00:00
|
|
|
|
|
|
|
Windows with ANGLE only.
|
|
|
|
|
2020-01-27 00:01:12 +00:00
|
|
|
``--macos-force-dedicated-gpu=<yes|no>``
|
2017-02-20 19:34:57 +00:00
|
|
|
Deactivates the automatic graphics switching and forces the dedicated GPU.
|
|
|
|
(default: no)
|
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
macOS only.
|
2017-02-20 19:34:57 +00:00
|
|
|
|
2018-07-22 21:07:32 +00:00
|
|
|
``--cocoa-cb-sw-renderer=<yes|no|auto>``
|
|
|
|
Use the Apple Software Renderer when using cocoa-cb (default: auto). If set
|
|
|
|
to ``no`` the software renderer is never used and instead fails when a the
|
|
|
|
usual pixel format could not be created, ``yes`` will always only use the
|
|
|
|
software renderer, and ``auto`` only falls back to the software renderer
|
|
|
|
when the usual pixel format couldn't be created.
|
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
macOS only.
|
2018-07-22 21:07:32 +00:00
|
|
|
|
2019-05-25 17:29:34 +00:00
|
|
|
``--cocoa-cb-10bit-context=<yes|no>``
|
|
|
|
Creates a 10bit capable pixel format for the context creation (default: yes).
|
|
|
|
Instead of 8bit integer framebuffer a 16bit half-float framebuffer is
|
|
|
|
requested.
|
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
macOS only.
|
2019-05-25 17:29:34 +00:00
|
|
|
|
2019-03-29 19:38:02 +00:00
|
|
|
``--macos-title-bar-appearance=<appearance>``
|
|
|
|
Sets the appearance of the title bar (default: auto). Not all combinations
|
|
|
|
of appearances and ``--macos-title-bar-material`` materials make sense or
|
|
|
|
are unique. Appearances that are not supported by you current macOS version
|
|
|
|
fall back to the default value.
|
|
|
|
macOS and cocoa-cb only
|
|
|
|
|
|
|
|
``<appearance>`` can be one of the following:
|
|
|
|
|
|
|
|
:auto: Detects the system settings and sets the title
|
|
|
|
bar appearance appropriately. On macOS 10.14 it
|
|
|
|
also detects run time changes.
|
|
|
|
:aqua: The standard macOS Light appearance.
|
|
|
|
:darkAqua: The standard macOS Dark appearance. (macOS 10.14+)
|
|
|
|
:vibrantLight: Light vibrancy appearance with.
|
|
|
|
:vibrantDark: Dark vibrancy appearance with.
|
|
|
|
:aquaHighContrast: Light Accessibility appearance. (macOS 10.14+)
|
|
|
|
:darkAquaHighContrast: Dark Accessibility appearance. (macOS 10.14+)
|
|
|
|
:vibrantLightHighContrast: Light vibrancy Accessibility appearance.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:vibrantDarkHighContrast: Dark vibrancy Accessibility appearance.
|
|
|
|
(macOS 10.14+)
|
|
|
|
|
|
|
|
``--macos-title-bar-material=<material>``
|
|
|
|
Sets the material of the title bar (default: titlebar). All deprecated
|
|
|
|
materials should not be used on macOS 10.14+ because their functionality
|
|
|
|
is not guaranteed. Not all combinations of materials and
|
|
|
|
``--macos-title-bar-appearance`` appearances make sense or are unique.
|
|
|
|
Materials that are not supported by you current macOS version fall back to
|
|
|
|
the default value.
|
|
|
|
macOS and cocoa-cb only
|
|
|
|
|
|
|
|
``<material>`` can be one of the following:
|
|
|
|
|
2023-03-27 20:42:17 +00:00
|
|
|
:titlebar: The standard macOS title bar material.
|
2019-03-29 19:38:02 +00:00
|
|
|
:selection: The standard macOS selection material.
|
|
|
|
:menu: The standard macOS menu material. (macOS 10.11+)
|
|
|
|
:popover: The standard macOS popover material. (macOS 10.11+)
|
|
|
|
:sidebar: The standard macOS sidebar material. (macOS 10.11+)
|
|
|
|
:headerView: The standard macOS header view material.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:sheet: The standard macOS sheet material. (macOS 10.14+)
|
|
|
|
:windowBackground: The standard macOS window background material.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:hudWindow: The standard macOS hudWindow material. (macOS 10.14+)
|
|
|
|
:fullScreen: The standard macOS full screen material.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:toolTip: The standard macOS tool tip material. (macOS 10.14+)
|
|
|
|
:contentBackground: The standard macOS content background material.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:underWindowBackground: The standard macOS under window background material.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:underPageBackground: The standard macOS under page background material.
|
|
|
|
(deprecated in macOS 10.14+)
|
|
|
|
:dark: The standard macOS dark material.
|
|
|
|
(deprecated in macOS 10.14+)
|
|
|
|
:light: The standard macOS light material.
|
|
|
|
(macOS 10.14+)
|
|
|
|
:mediumLight: The standard macOS mediumLight material.
|
|
|
|
(macOS 10.11+, deprecated in macOS 10.14+)
|
|
|
|
:ultraDark: The standard macOS ultraDark material.
|
|
|
|
(macOS 10.11+ deprecated in macOS 10.14+)
|
2018-02-16 12:07:15 +00:00
|
|
|
|
2019-03-29 19:39:42 +00:00
|
|
|
``--macos-title-bar-color=<color>``
|
|
|
|
Sets the color of the title bar (default: completely transparent). Is
|
|
|
|
influenced by ``--macos-title-bar-appearance`` and
|
|
|
|
``--macos-title-bar-material``.
|
|
|
|
See ``--sub-color`` for color syntax.
|
|
|
|
|
2018-02-27 23:46:16 +00:00
|
|
|
``--macos-fs-animation-duration=<default|0-1000>``
|
|
|
|
Sets the fullscreen resize animation duration in ms (default: default).
|
|
|
|
The default value is slightly less than the system's animation duration
|
|
|
|
(500ms) to prevent some problems when the end of an async animation happens
|
|
|
|
at the same time as the end of the system wide fullscreen animation. Setting
|
|
|
|
anything higher than 500ms will only prematurely cancel the resize animation
|
|
|
|
after the system wide animation ended. The upper limit is still set at
|
|
|
|
1000ms since it's possible that Apple or the user changes the system
|
|
|
|
defaults. Anything higher than 1000ms though seems too long and shouldn't be
|
|
|
|
set anyway.
|
2021-01-01 23:53:23 +00:00
|
|
|
(macOS and cocoa-cb only)
|
2018-02-27 23:46:16 +00:00
|
|
|
|
2020-09-15 14:44:12 +00:00
|
|
|
|
|
|
|
``--macos-app-activation-policy=<regular|accessory|prohibited>``
|
|
|
|
Changes the App activation policy. With accessory the mpv icon in the Dock
|
|
|
|
can be hidden. (default: regular)
|
|
|
|
|
|
|
|
macOS only.
|
|
|
|
|
2020-12-13 16:13:18 +00:00
|
|
|
``--macos-geometry-calculation=<visible|whole>``
|
|
|
|
This changes the rectangle which is used to calculate the screen position
|
|
|
|
and size of the window (default: visible). ``visible`` takes the the menu
|
|
|
|
bar and Dock into account and the window is only positioned/sized within the
|
|
|
|
visible screen frame rectangle, ``whole`` takes the whole screen frame
|
|
|
|
rectangle and ignores the menu bar and Dock. Other previous restrictions
|
|
|
|
still apply, like the window can't be placed on top of the menu bar etc.
|
|
|
|
|
|
|
|
macOS only.
|
|
|
|
|
2018-01-02 20:14:24 +00:00
|
|
|
``--android-surface-size=<WxH>``
|
2017-12-25 15:04:09 +00:00
|
|
|
Set dimensions of the rendering surface used by the Android gpu context.
|
2017-12-30 06:45:55 +00:00
|
|
|
Needs to be set by the embedding application if the dimensions change during
|
|
|
|
runtime (i.e. if the device is rotated), via the surfaceChanged callback.
|
2017-12-25 15:04:09 +00:00
|
|
|
|
|
|
|
Android with ``--gpu-context=android`` only.
|
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gpu-sw``
|
2016-09-02 13:59:40 +00:00
|
|
|
Continue even if a software renderer is detected.
|
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gpu-context=<sys>``
|
|
|
|
The value ``auto`` (the default) selects the GPU context. You can also pass
|
|
|
|
``help`` to get a complete list of compiled in backends (sorted by
|
|
|
|
autoprobe order).
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
auto
|
|
|
|
auto-select (default)
|
|
|
|
cocoa
|
2021-01-01 23:53:23 +00:00
|
|
|
Cocoa/macOS (deprecated, use --vo=libmpv instead)
|
2016-09-02 13:59:40 +00:00
|
|
|
win
|
vo_gpu: semi-fix --gpu-context/--gpu-api options and help output
This was confusing at best. Change it to output the actual choices.
(Seems like in the end it's always me who has to clean up other people's
bullshit.)
Context names were not unique - but they should be, so fix it. The whole
point of the original --opengl-backend option was to side-step the
tricky auto-detection, so you know exactly what you get. The goal of
this commit is to make --gpu-context work the same way. Fix the
non-unique names by appending "vk" to the names.
Keep in mind that this was not suitable for slecting the "UI" backend
anyway, since "x11" would force GLX, whereas people on not-NVIDIA
actually want "x11egl". Users trying to use --gpu-context=x11 to force
the X11 backend would always end up with GLX, which would at least break
VAAPI hardware decoding for them. Basically the idea that this option
could select the "UI" type is completely broken - it selects an
implementation, which implies a UI. Selecting the UI type This would
require a separate mechanism. (Although in theory this separate
mechanism could be part of the --gpu-context option - in any case,
someone would have to implement it.)
To achieve help output that can actually be understood, just duplicate
the code. Most of that code is duplicated anyway, and trying to share
just the list code with the result of making the output unreadable
doesn't make too much sense. If we wanted to save code/effort, we could
just remove the help output altogether.
--gpu-api has non-unique entries, and it would be nice to group them
(e.g. list all OpenGL capable contexts with "opengl"), but C makes this
simple idea too much of a pain, so don't do it.
Also remove a stray tab from the android entry on the manpage.
2017-10-16 08:53:33 +00:00
|
|
|
Win32/WGL
|
|
|
|
winvk
|
|
|
|
VK_KHR_win32_surface
|
2016-09-02 13:59:40 +00:00
|
|
|
angle
|
|
|
|
Direct3D11 through the OpenGL ES translation layer ANGLE. This supports
|
|
|
|
almost everything the ``win`` backend does (if the ANGLE build is new
|
|
|
|
enough).
|
|
|
|
dxinterop (experimental)
|
|
|
|
Win32, using WGL for rendering and Direct3D 9Ex for presentation. Works
|
|
|
|
on Nvidia and AMD. Newer Intel chips with the latest drivers may also
|
|
|
|
work.
|
vo_gpu: d3d11: initial implementation
This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL
generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross.
What works:
- All of mpv's internal shaders should work, including compute shaders.
- Some external shaders have been tested and work, including RAVU and
adaptive-sharpen.
- Non-dumb mode works, even on very old hardware. Most features work at
feature level 9_3 and all features work at feature level 10_0. Some
features also work at feature level 9_1 and 9_2, but without high-bit-
depth FBOs, it's not very useful. (Hardware this old is probably not
fast enough for advanced features anyway.)
Note: This is more compatible than ANGLE, which requires 9_3 to work
at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.)
- Hardware decoding with D3D11VA, including decoding of 10-bit formats
without truncation to 8-bit.
What doesn't work / can be improved:
- PBO upload and direct rendering does not work yet. Direct rendering
requires persistent-mapped PBOs because the decoder needs to be able
to read data from images that have already been decoded and uploaded.
Unfortunately, it seems like persistent-mapped PBOs are fundamentally
incompatible with D3D11, which requires all resources to use driver-
managed memory and requires memory to be unmapped (and hence pointers
to be invalidated) when a resource is used in a draw or copy
operation.
However it might be possible to use D3D11's limited multithreading
capabilities to emulate some features of PBOs, like asynchronous
texture uploading.
- The blit() and clear() operations don't have equivalents in the D3D11
API that handle all cases, so in most cases, they have to be emulated
with a shader. This is currently done inside ra_d3d11, but ideally it
would be done in generic code, so it can take advantage of mpv's
shader generation utilities.
- SPIRV-Cross is used through a NIH C-compatible wrapper library, since
it does not expose a C interface itself.
The library is available here: https://github.com/rossy/crossc
- The D3D11 context could be made to support more modern DXGI features
in future. For example, it should be possible to add support for
high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 10:18:06 +00:00
|
|
|
d3d11
|
|
|
|
Win32, with native Direct3D 11 rendering.
|
2016-09-02 13:59:40 +00:00
|
|
|
x11
|
2023-02-22 22:23:30 +00:00
|
|
|
X11/GLX (deprecated/legacy, EGL is preferred these days)
|
vo_gpu: semi-fix --gpu-context/--gpu-api options and help output
This was confusing at best. Change it to output the actual choices.
(Seems like in the end it's always me who has to clean up other people's
bullshit.)
Context names were not unique - but they should be, so fix it. The whole
point of the original --opengl-backend option was to side-step the
tricky auto-detection, so you know exactly what you get. The goal of
this commit is to make --gpu-context work the same way. Fix the
non-unique names by appending "vk" to the names.
Keep in mind that this was not suitable for slecting the "UI" backend
anyway, since "x11" would force GLX, whereas people on not-NVIDIA
actually want "x11egl". Users trying to use --gpu-context=x11 to force
the X11 backend would always end up with GLX, which would at least break
VAAPI hardware decoding for them. Basically the idea that this option
could select the "UI" type is completely broken - it selects an
implementation, which implies a UI. Selecting the UI type This would
require a separate mechanism. (Although in theory this separate
mechanism could be part of the --gpu-context option - in any case,
someone would have to implement it.)
To achieve help output that can actually be understood, just duplicate
the code. Most of that code is duplicated anyway, and trying to share
just the list code with the result of making the output unreadable
doesn't make too much sense. If we wanted to save code/effort, we could
just remove the help output altogether.
--gpu-api has non-unique entries, and it would be nice to group them
(e.g. list all OpenGL capable contexts with "opengl"), but C makes this
simple idea too much of a pain, so don't do it.
Also remove a stray tab from the android entry on the manpage.
2017-10-16 08:53:33 +00:00
|
|
|
x11vk
|
|
|
|
VK_KHR_xlib_surface
|
2016-09-02 13:59:40 +00:00
|
|
|
wayland
|
vo_gpu: semi-fix --gpu-context/--gpu-api options and help output
This was confusing at best. Change it to output the actual choices.
(Seems like in the end it's always me who has to clean up other people's
bullshit.)
Context names were not unique - but they should be, so fix it. The whole
point of the original --opengl-backend option was to side-step the
tricky auto-detection, so you know exactly what you get. The goal of
this commit is to make --gpu-context work the same way. Fix the
non-unique names by appending "vk" to the names.
Keep in mind that this was not suitable for slecting the "UI" backend
anyway, since "x11" would force GLX, whereas people on not-NVIDIA
actually want "x11egl". Users trying to use --gpu-context=x11 to force
the X11 backend would always end up with GLX, which would at least break
VAAPI hardware decoding for them. Basically the idea that this option
could select the "UI" type is completely broken - it selects an
implementation, which implies a UI. Selecting the UI type This would
require a separate mechanism. (Although in theory this separate
mechanism could be part of the --gpu-context option - in any case,
someone would have to implement it.)
To achieve help output that can actually be understood, just duplicate
the code. Most of that code is duplicated anyway, and trying to share
just the list code with the result of making the output unreadable
doesn't make too much sense. If we wanted to save code/effort, we could
just remove the help output altogether.
--gpu-api has non-unique entries, and it would be nice to group them
(e.g. list all OpenGL capable contexts with "opengl"), but C makes this
simple idea too much of a pain, so don't do it.
Also remove a stray tab from the android entry on the manpage.
2017-10-16 08:53:33 +00:00
|
|
|
Wayland/EGL
|
|
|
|
waylandvk
|
|
|
|
VK_KHR_wayland_surface
|
2016-09-27 14:29:22 +00:00
|
|
|
drm
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
DRM/EGL
|
vo_gpu: vulkan: implement a VkDisplayKHR backed context
This is the Vulkan equivalent of the drm context for OpenGL, with
the big difference that it's implemented purely in terms of Vulkan
calls and doesn't actually require drm or kms.
The basic idea is to identify a display, mode, and plane on a device,
and then create a display backed surface for the swapchain. In theory,
past that point, everything is the same, and this is in fact the case
on Intel hardware. I can get a video playing on a vt.
On nvidia, naturally, things don't work that way. Instead, nvidia only
implemented the extension for scenarios where a VR application is
stealing a display from a running window system, and not for
standalone scenarios. With additional code, I've got this scenario to
work but that's a separate incremental change.
Other people have tested on AMD, and report roughly the same behaviour
as on Intel.
Note, that in this change, the VT will not be correctly restored after
qutting. The only way to restore the VT is to introduce some drm
specific code which I will illustrate in a separate change.
2019-12-02 02:37:40 +00:00
|
|
|
displayvk
|
|
|
|
VK_KHR_display. This backend is roughly the Vukan equivalent of
|
|
|
|
DRM/EGL, allowing for direct rendering via Vulkan without a display
|
|
|
|
manager.
|
2016-09-02 13:59:40 +00:00
|
|
|
x11egl
|
|
|
|
X11/EGL
|
2017-10-05 18:58:37 +00:00
|
|
|
android
|
vo_gpu: semi-fix --gpu-context/--gpu-api options and help output
This was confusing at best. Change it to output the actual choices.
(Seems like in the end it's always me who has to clean up other people's
bullshit.)
Context names were not unique - but they should be, so fix it. The whole
point of the original --opengl-backend option was to side-step the
tricky auto-detection, so you know exactly what you get. The goal of
this commit is to make --gpu-context work the same way. Fix the
non-unique names by appending "vk" to the names.
Keep in mind that this was not suitable for slecting the "UI" backend
anyway, since "x11" would force GLX, whereas people on not-NVIDIA
actually want "x11egl". Users trying to use --gpu-context=x11 to force
the X11 backend would always end up with GLX, which would at least break
VAAPI hardware decoding for them. Basically the idea that this option
could select the "UI" type is completely broken - it selects an
implementation, which implies a UI. Selecting the UI type This would
require a separate mechanism. (Although in theory this separate
mechanism could be part of the --gpu-context option - in any case,
someone would have to implement it.)
To achieve help output that can actually be understood, just duplicate
the code. Most of that code is duplicated anyway, and trying to share
just the list code with the result of making the output unreadable
doesn't make too much sense. If we wanted to save code/effort, we could
just remove the help output altogether.
--gpu-api has non-unique entries, and it would be nice to group them
(e.g. list all OpenGL capable contexts with "opengl"), but C makes this
simple idea too much of a pain, so don't do it.
Also remove a stray tab from the android entry on the manpage.
2017-10-16 08:53:33 +00:00
|
|
|
Android/EGL. Requires ``--wid`` be set to an ``android.view.Surface``.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gpu-api=<type>``
|
|
|
|
Controls which type of graphics APIs will be accepted:
|
|
|
|
|
|
|
|
auto
|
|
|
|
Use any available API (default)
|
|
|
|
opengl
|
|
|
|
Allow only OpenGL (requires OpenGL 2.1+ or GLES 2.0+)
|
2017-09-26 15:46:29 +00:00
|
|
|
vulkan
|
|
|
|
Allow only Vulkan (requires a valid/working ``--spirv-compiler``)
|
vo_gpu: d3d11: initial implementation
This is a new RA/vo_gpu backend that uses Direct3D 11. The GLSL
generated by vo_gpu is cross-compiled to HLSL with SPIRV-Cross.
What works:
- All of mpv's internal shaders should work, including compute shaders.
- Some external shaders have been tested and work, including RAVU and
adaptive-sharpen.
- Non-dumb mode works, even on very old hardware. Most features work at
feature level 9_3 and all features work at feature level 10_0. Some
features also work at feature level 9_1 and 9_2, but without high-bit-
depth FBOs, it's not very useful. (Hardware this old is probably not
fast enough for advanced features anyway.)
Note: This is more compatible than ANGLE, which requires 9_3 to work
at all (GLES 2.0,) and 10_1 for non-dumb-mode (GLES 3.0.)
- Hardware decoding with D3D11VA, including decoding of 10-bit formats
without truncation to 8-bit.
What doesn't work / can be improved:
- PBO upload and direct rendering does not work yet. Direct rendering
requires persistent-mapped PBOs because the decoder needs to be able
to read data from images that have already been decoded and uploaded.
Unfortunately, it seems like persistent-mapped PBOs are fundamentally
incompatible with D3D11, which requires all resources to use driver-
managed memory and requires memory to be unmapped (and hence pointers
to be invalidated) when a resource is used in a draw or copy
operation.
However it might be possible to use D3D11's limited multithreading
capabilities to emulate some features of PBOs, like asynchronous
texture uploading.
- The blit() and clear() operations don't have equivalents in the D3D11
API that handle all cases, so in most cases, they have to be emulated
with a shader. This is currently done inside ra_d3d11, but ideally it
would be done in generic code, so it can take advantage of mpv's
shader generation utilities.
- SPIRV-Cross is used through a NIH C-compatible wrapper library, since
it does not expose a C interface itself.
The library is available here: https://github.com/rossy/crossc
- The D3D11 context could be made to support more modern DXGI features
in future. For example, it should be possible to add support for
high-bit-depth and HDR output with DXGI 1.5/1.6.
2017-09-07 10:18:06 +00:00
|
|
|
d3d11
|
|
|
|
Allow only ``--gpu-context=d3d11``
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--opengl-es=<mode>``
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
Controls which type of OpenGL context will be accepted:
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
auto
|
|
|
|
Allow all types of OpenGL (default)
|
2016-09-02 13:59:40 +00:00
|
|
|
yes
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
Only allow GLES
|
2016-09-02 13:59:40 +00:00
|
|
|
no
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
Only allow desktop/core GL
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--fbo-format=<fmt>``
|
2016-09-02 13:59:40 +00:00
|
|
|
Selects the internal format of textures used for FBOs. The format can
|
|
|
|
influence performance and quality of the video output. ``fmt`` can be one
|
|
|
|
of: rgb8, rgb10, rgb10_a2, rgb16, rgb16f, rgb32f, rgba12, rgba16, rgba16f,
|
2018-05-31 20:46:08 +00:00
|
|
|
rgba16hf, rgba32f.
|
|
|
|
|
|
|
|
Default: ``auto``, which first attempts to utilize 16bit float
|
|
|
|
(rgba16f, rgba16hf), and falls back to rgba16 if those are not available.
|
|
|
|
Finally, attempts to utilize rgb10_a2 or rgba8 if all of the previous formats
|
|
|
|
are not available.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gamma-factor=<0.1..2.0>``
|
|
|
|
Set an additional raw gamma factor (default: 1.0). If gamma is adjusted in
|
|
|
|
other ways (like with the ``--gamma`` option or key bindings and the
|
|
|
|
``gamma`` property), the value is multiplied with the other gamma value.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2022-09-30 21:14:58 +00:00
|
|
|
This option is deprecated and may be removed in the future.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--gamma-auto``
|
|
|
|
Automatically corrects the gamma value depending on ambient lighting
|
2017-09-19 04:35:24 +00:00
|
|
|
conditions (adding a gamma boost for bright rooms).
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2022-09-30 21:14:58 +00:00
|
|
|
This option is deprecated and may be removed in the future.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
NOTE: Only implemented on macOS.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2021-04-09 07:14:54 +00:00
|
|
|
``--image-lut=<file>``
|
|
|
|
Specifies a custom LUT file (in Adobe .cube format) to apply to the colors
|
|
|
|
during image decoding. The exact interpretation of the LUT depends on
|
|
|
|
the value of ``--image-lut-type``. (Only for ``--vo=gpu-next``)
|
|
|
|
|
|
|
|
``--image-lut-type=<value>``
|
|
|
|
Controls the interpretation of color values fed to and from the LUT
|
|
|
|
specified as ``--image-lut``. Valid values are:
|
|
|
|
|
|
|
|
auto
|
|
|
|
Chooses the interpretation of the LUT automatically from tagged
|
|
|
|
metadata, and otherwise falls back to ``native``. (Default)
|
|
|
|
native
|
|
|
|
Applied to the raw image contents in its native colorspace, before
|
|
|
|
decoding to RGB. For example, for a HDR10 image, this would be fed
|
|
|
|
PQ-encoded YCbCr values in the range 0.0 - 1.0.
|
|
|
|
normalized
|
|
|
|
Applied to the normalized RGB image contents, after decoding from
|
|
|
|
its native color encoding, but before linearization.
|
|
|
|
conversion
|
|
|
|
Fully replaces the color decoding. A LUT of this type should ingest the
|
|
|
|
image's native colorspace and output normalized non-linear RGB.
|
|
|
|
|
2021-11-14 15:50:02 +00:00
|
|
|
``--target-colorspace-hint``
|
2021-11-07 22:47:55 +00:00
|
|
|
Automatically configure the output colorspace of the display to pass
|
|
|
|
through the input values of the stream (e.g. for HDR passthrough), if
|
|
|
|
possible. Requires a supporting driver and ``--vo=gpu-next``.
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--target-prim=<value>``
|
|
|
|
Specifies the primaries of the display. Video colors will be adapted to
|
|
|
|
this colorspace when ICC color management is not being used. Valid values
|
|
|
|
are:
|
|
|
|
|
|
|
|
auto
|
2018-05-16 23:41:26 +00:00
|
|
|
Disable any adaptation, except for atypical color spaces. Specifically,
|
|
|
|
wide/unusual gamuts get automatically adapted to BT.709, while standard
|
|
|
|
gamut (i.e. BT.601 and BT.709) content is not touched. (default)
|
2016-09-02 13:59:40 +00:00
|
|
|
bt.470m
|
|
|
|
ITU-R BT.470 M
|
|
|
|
bt.601-525
|
|
|
|
ITU-R BT.601 (525-line SD systems, eg. NTSC), SMPTE 170M/240M
|
|
|
|
bt.601-625
|
|
|
|
ITU-R BT.601 (625-line SD systems, eg. PAL/SECAM), ITU-R BT.470 B/G
|
|
|
|
bt.709
|
|
|
|
ITU-R BT.709 (HD), IEC 61966-2-4 (sRGB), SMPTE RP177 Annex B
|
|
|
|
bt.2020
|
|
|
|
ITU-R BT.2020 (UHD)
|
|
|
|
apple
|
|
|
|
Apple RGB
|
|
|
|
adobe
|
|
|
|
Adobe RGB (1998)
|
|
|
|
prophoto
|
|
|
|
ProPhoto RGB (ROMM)
|
|
|
|
cie1931
|
|
|
|
CIE 1931 RGB (not to be confused with CIE XYZ)
|
|
|
|
dci-p3
|
|
|
|
DCI-P3 (Digital Cinema Colorspace), SMPTE RP431-2
|
|
|
|
v-gamut
|
|
|
|
Panasonic V-Gamut (VARICAM) primaries
|
2017-06-10 00:10:41 +00:00
|
|
|
s-gamut
|
|
|
|
Sony S-Gamut (S-Log) primaries
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--target-trc=<value>``
|
|
|
|
Specifies the transfer characteristics (gamma) of the display. Video colors
|
|
|
|
will be adjusted to this curve when ICC color management is not being used.
|
|
|
|
Valid values are:
|
|
|
|
|
|
|
|
auto
|
2018-05-16 23:41:26 +00:00
|
|
|
Disable any adaptation, except for atypical transfers. Specifically,
|
|
|
|
HDR or linear light source material gets automatically converted to
|
|
|
|
gamma 2.2, while SDR content is not touched. (default)
|
2016-09-02 13:59:40 +00:00
|
|
|
bt.1886
|
|
|
|
ITU-R BT.1886 curve (assuming infinite contrast)
|
|
|
|
srgb
|
|
|
|
IEC 61966-2-4 (sRGB)
|
|
|
|
linear
|
|
|
|
Linear light output
|
|
|
|
gamma1.8
|
|
|
|
Pure power curve (gamma 1.8), also used for Apple RGB
|
2018-08-22 12:39:40 +00:00
|
|
|
gamma2.0
|
|
|
|
Pure power curve (gamma 2.0)
|
2016-09-02 13:59:40 +00:00
|
|
|
gamma2.2
|
|
|
|
Pure power curve (gamma 2.2)
|
2018-08-22 12:39:40 +00:00
|
|
|
gamma2.4
|
|
|
|
Pure power curve (gamma 2.4)
|
|
|
|
gamma2.6
|
|
|
|
Pure power curve (gamma 2.6)
|
2016-09-02 13:59:40 +00:00
|
|
|
gamma2.8
|
|
|
|
Pure power curve (gamma 2.8), also used for BT.470-BG
|
|
|
|
prophoto
|
|
|
|
ProPhoto RGB (ROMM)
|
2017-06-13 15:09:02 +00:00
|
|
|
pq
|
|
|
|
ITU-R BT.2100 PQ (Perceptual quantizer) curve, aka SMPTE ST2084
|
|
|
|
hlg
|
|
|
|
ITU-R BT.2100 HLG (Hybrid Log-gamma) curve, aka ARIB STD-B67
|
2016-09-02 13:59:40 +00:00
|
|
|
v-log
|
|
|
|
Panasonic V-Log (VARICAM) curve
|
2017-06-10 00:05:28 +00:00
|
|
|
s-log1
|
|
|
|
Sony S-Log1 curve
|
2017-06-10 00:51:32 +00:00
|
|
|
s-log2
|
|
|
|
Sony S-Log2 curve
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2016-09-20 11:33:49 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
When using HDR output formats, mpv will encode to the specified
|
|
|
|
curve but it will not set any HDMI flags or other signalling that might
|
|
|
|
be required for the target device to correctly display the HDR signal.
|
|
|
|
The user should independently guarantee this before using these signal
|
|
|
|
formats for display.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2019-01-18 01:24:38 +00:00
|
|
|
``--target-peak=<auto|nits>``
|
2018-02-14 15:10:51 +00:00
|
|
|
Specifies the measured peak brightness of the output display, in cd/m^2
|
|
|
|
(AKA nits). The interpretation of this brightness depends on the configured
|
|
|
|
``--target-trc``. In all cases, it imposes a limit on the signal values
|
|
|
|
that will be sent to the display. If the source exceeds this brightness
|
|
|
|
level, a tone mapping filter will be inserted. For HLG, it has the
|
|
|
|
additional effect of parametrizing the inverse OOTF, in order to get
|
|
|
|
colorimetrically consistent results with the mastering display. For SDR, or
|
|
|
|
when using an ICC (profile (``--icc-profile``), setting this to a value
|
2020-05-17 01:17:28 +00:00
|
|
|
above 203 essentially causes the display to be treated as if it were an HDR
|
2018-02-14 15:10:51 +00:00
|
|
|
display in disguise. (See the note below)
|
|
|
|
|
2019-01-18 01:24:38 +00:00
|
|
|
In ``auto`` mode (the default), the chosen peak is an appropriate value
|
2020-05-17 01:17:28 +00:00
|
|
|
based on the TRC in use. For SDR curves, it uses 203. For HDR curves, it
|
|
|
|
uses 203 * the transfer function's nominal peak.
|
2018-02-14 15:10:51 +00:00
|
|
|
|
|
|
|
.. note::
|
|
|
|
|
|
|
|
When using an SDR transfer function, this is normally not needed, and
|
|
|
|
setting it may lead to very unexpected results. The one time it *is*
|
|
|
|
useful is if you want to calibrate a HDR display using traditional
|
|
|
|
transfer functions and calibration equipment. In such cases, you can
|
|
|
|
set your HDR display to a high brightness such as 800 cd/m^2, and then
|
|
|
|
calibrate it to a standard curve like gamma2.8. Setting this value to
|
|
|
|
800 would then instruct mpv to essentially treat it as an HDR display
|
|
|
|
with the given peak. This may be a good alternative in environments
|
|
|
|
where PQ or HLG input to the display is not possible, and makes it
|
|
|
|
possible to use HDR displays with mpv regardless of operating system
|
|
|
|
support for HDMI HDR metadata.
|
|
|
|
|
|
|
|
In such a configuration, we highly recommend setting ``--tone-mapping``
|
|
|
|
to ``mobius`` or even ``clip``.
|
|
|
|
|
2023-06-30 03:46:51 +00:00
|
|
|
``--target-contrast=<auto|10-1000000|inf>``
|
|
|
|
Specifies the measured contrast of the output display. ``--target-contrast``
|
|
|
|
in conjunction with ``--target-peak`` value is used to calculate display
|
|
|
|
black point. Used in black point compensation during HDR tone-mapping.
|
|
|
|
``auto`` is the default and assumes 1000:1 contrast as a typical SDR display
|
|
|
|
would have or an infinite contrast when HDR ``--target-trc`` is used.
|
|
|
|
``inf`` contrast specifies display with perfect black level, in practice OLED.
|
|
|
|
(Only for ``--vo=gpu-next``)
|
|
|
|
|
2021-04-09 07:14:54 +00:00
|
|
|
``--target-lut=<file>``
|
|
|
|
Specifies a custom LUT file (in Adobe .cube format) to apply to the colors
|
|
|
|
before display on-screen. This LUT is fed values in normalized RGB, after
|
|
|
|
encoding into the target colorspace, so after the application of
|
|
|
|
``--target-trc``. (Only for ``--vo=gpu-next``)
|
|
|
|
|
2017-08-03 10:46:57 +00:00
|
|
|
``--tone-mapping=<value>``
|
|
|
|
Specifies the algorithm used for tone-mapping images onto the target
|
|
|
|
display. This is relevant for both HDR->SDR conversion as well as gamut
|
|
|
|
reduction (e.g. playing back BT.2020 content on a standard gamut display).
|
|
|
|
Valid values are:
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2022-01-03 02:56:36 +00:00
|
|
|
auto
|
|
|
|
Choose the best curve according to internal heuristics. (Default)
|
2016-09-02 13:59:40 +00:00
|
|
|
clip
|
2017-06-09 07:16:06 +00:00
|
|
|
Hard-clip any out-of-range values. Use this when you care about
|
|
|
|
perfect color accuracy for in-range values at the cost of completely
|
|
|
|
distorting out-of-range values. Not generally recommended.
|
|
|
|
mobius
|
|
|
|
Generalization of Reinhard to a Möbius transform with linear section.
|
|
|
|
Smoothly maps out-of-range values while retaining contrast and colors
|
|
|
|
for in-range material as much as possible. Use this when you care about
|
|
|
|
color accuracy more than detail preservation. This is somewhere in
|
|
|
|
between ``clip`` and ``reinhard``, depending on the value of
|
2018-02-03 13:45:01 +00:00
|
|
|
``--tone-mapping-param``.
|
2016-09-02 13:59:40 +00:00
|
|
|
reinhard
|
|
|
|
Reinhard tone mapping algorithm. Very simple continuous curve.
|
2017-06-09 07:16:06 +00:00
|
|
|
Preserves overall image brightness but uses nonlinear contrast, which
|
|
|
|
results in flattening of details and degradation in color accuracy.
|
2016-09-02 13:59:40 +00:00
|
|
|
hable
|
2017-06-09 07:16:06 +00:00
|
|
|
Similar to ``reinhard`` but preserves both dark and bright details
|
2017-08-03 10:46:57 +00:00
|
|
|
better (slightly sigmoidal), at the cost of slightly darkening /
|
|
|
|
desaturating everything. Developed by John Hable for use in video
|
|
|
|
games. Use this when you care about detail preservation more than
|
|
|
|
color/brightness accuracy. This is roughly equivalent to
|
2018-08-16 18:55:08 +00:00
|
|
|
``--tone-mapping=reinhard --tone-mapping-param=0.24``. If possible,
|
2018-02-03 13:45:01 +00:00
|
|
|
you should also enable ``--hdr-compute-peak`` for the best results.
|
2020-05-29 19:39:05 +00:00
|
|
|
bt.2390
|
|
|
|
Perceptual tone mapping curve (EETF) specified in ITU-R Report BT.2390.
|
2016-09-02 13:59:40 +00:00
|
|
|
gamma
|
|
|
|
Fits a logarithmic transfer between the tone curves.
|
|
|
|
linear
|
|
|
|
Linearly stretches the entire reference gamut to (a linear multiple of)
|
|
|
|
the display.
|
2022-01-03 02:56:36 +00:00
|
|
|
spline
|
|
|
|
Perceptually linear single-pivot polynomial. (``--vo=gpu-next`` only)
|
|
|
|
bt.2446a
|
|
|
|
HDR<->SDR mapping specified in ITU-R Report BT.2446, method A. This is
|
|
|
|
the recommended curve for well-mastered content. (``--vo=gpu-next``
|
|
|
|
only)
|
2023-02-11 17:20:14 +00:00
|
|
|
st2094-40
|
|
|
|
Dynamic HDR10+ tone-mapping method specified in SMPTE ST2094-40 Annex
|
|
|
|
B. In the absence of metadata, falls back to a fixed spline matched to
|
|
|
|
the input/output average brightness characteristics. (``--vo=gpu-next``
|
|
|
|
only)
|
|
|
|
st2094-10
|
|
|
|
Dynamic tone-mapping method specified in SMPTE ST2094-10 Annex B.2.
|
|
|
|
Conceptually simpler than ST2094-40, and generally produces worse
|
|
|
|
results.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--tone-mapping-param=<value>``
|
2019-10-24 22:25:05 +00:00
|
|
|
Set tone mapping parameters. By default, this is set to the special string
|
|
|
|
``default``, which maps to an algorithm-specific default value. Ignored if
|
|
|
|
the tone mapping algorithm is not tunable. This affects the following tone
|
|
|
|
mapping algorithms:
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2017-07-07 19:00:21 +00:00
|
|
|
clip
|
|
|
|
Specifies an extra linear coefficient to multiply into the signal
|
|
|
|
before clipping. Defaults to 1.0.
|
2017-06-09 07:16:06 +00:00
|
|
|
mobius
|
|
|
|
Specifies the transition point from linear to mobius transform. Every
|
|
|
|
value below this point is guaranteed to be mapped 1:1. The higher the
|
|
|
|
value, the more accurate the result will be, at the cost of losing
|
|
|
|
bright details. Defaults to 0.3, which due to the steep initial slope
|
|
|
|
still preserves in-range colors fairly accurately.
|
2016-09-02 13:59:40 +00:00
|
|
|
reinhard
|
|
|
|
Specifies the local contrast coefficient at the display peak. Defaults
|
|
|
|
to 0.5, which means that in-gamut values will be about half as bright
|
|
|
|
as when clipping.
|
2022-09-27 23:53:42 +00:00
|
|
|
bt.2390
|
|
|
|
Specifies the offset for the knee point. Defaults to 1.0, which is
|
|
|
|
higher than the value from the original ITU-R specification (0.5).
|
|
|
|
(``--vo=gpu-next`` only)
|
2016-09-02 13:59:40 +00:00
|
|
|
gamma
|
|
|
|
Specifies the exponent of the function. Defaults to 1.8.
|
|
|
|
linear
|
|
|
|
Specifies the scale factor to use while stretching. Defaults to 1.0.
|
2022-01-03 02:56:36 +00:00
|
|
|
spline
|
|
|
|
Specifies the knee point (in PQ space). Defaults to 0.30.
|
2023-02-11 17:20:14 +00:00
|
|
|
st2094-10
|
|
|
|
Specifies the contrast (slope) at the knee point. Defaults to 1.0.
|
2022-01-03 02:56:36 +00:00
|
|
|
|
|
|
|
``--inverse-tone-mapping``
|
|
|
|
If set, allows inverse tone mapping (expanding SDR to HDR). Not supported
|
|
|
|
by all tone mapping curves. Use with caution. (``--vo=gpu-next`` only)
|
|
|
|
|
2019-01-02 02:03:38 +00:00
|
|
|
``--tone-mapping-max-boost=<1.0..10.0>``
|
|
|
|
Upper limit for how much the tone mapping algorithm is allowed to boost
|
|
|
|
the average brightness by over-exposing the image. The default value of 1.0
|
|
|
|
allows no additional brightness boost. A value of 2.0 would allow
|
|
|
|
over-exposing by a factor of 2, and so on. Raising this setting can help
|
|
|
|
reveal details that would otherwise be hidden in dark scenes, but raising
|
2022-09-20 14:08:28 +00:00
|
|
|
it too high will make dark scenes appear unnaturally bright. (``--vo=gpu``
|
2022-01-03 02:56:36 +00:00
|
|
|
only)
|
2019-01-02 02:03:38 +00:00
|
|
|
|
2023-02-19 20:01:40 +00:00
|
|
|
``--tone-mapping-visualize``
|
|
|
|
Display a (PQ-PQ) graph of the active tone-mapping LUT. Intended only for
|
|
|
|
debugging purposes. The X axis shows PQ input values, the Y axis shows PQ
|
|
|
|
output values. The tone-mapping curve is shown in green/yellow. Yellow
|
|
|
|
means the brightness has been boosted from the source, dark blue regions
|
|
|
|
show where the brightness has been reduced. The extra colored regions and
|
|
|
|
lines indicate various monitor limits, as well a reference diagonal
|
|
|
|
(neutral tone-mapping) and source scene average brightness information (if
|
|
|
|
available). (``--vo=gpu-next`` only)
|
|
|
|
|
2022-01-03 03:31:50 +00:00
|
|
|
``--gamut-mapping-mode``
|
|
|
|
Specifies the algorithm used for reducing the gamut of images for the
|
|
|
|
target display, after any tone mapping is done.
|
|
|
|
|
|
|
|
auto
|
|
|
|
Choose the best mode automatically. (Default)
|
|
|
|
clip
|
2023-06-19 10:59:51 +00:00
|
|
|
Hard-clip to the gamut (per-channel). Very low quality, but free.
|
|
|
|
perceptual
|
|
|
|
Performs a perceptually balanced gamut mapping using a soft knee
|
|
|
|
function to roll-off clipped regions, and a hue shifting function to
|
|
|
|
preserve saturation. (``--vo=gpu-next`` only)
|
|
|
|
relative
|
|
|
|
Performs relative colorimetric clipping, while maintaining an
|
|
|
|
exponential relationship between brightness and chromaticity.
|
|
|
|
(``--vo=gpu-next`` only)
|
|
|
|
saturation
|
|
|
|
Performs simple RGB->RGB saturation mapping. The input R/G/B channels
|
|
|
|
are mapped directly onto the output R/G/B channels. Will never clip,
|
|
|
|
but will distort all hues and/or result in a faded look.
|
|
|
|
(``--vo=gpu-next`` only)
|
|
|
|
absolute
|
|
|
|
Performs absolute colorimetric clipping. Like ``relative``, but does
|
|
|
|
not adapt the white point. (``--vo=gpu-next`` only)
|
2022-01-03 03:31:50 +00:00
|
|
|
desaturate
|
2023-06-19 10:59:51 +00:00
|
|
|
Performs constant-luminance colorimetric clipping, desaturing colors
|
|
|
|
towards white until they're in-range.
|
2022-01-03 03:31:50 +00:00
|
|
|
darken
|
2023-06-19 10:59:51 +00:00
|
|
|
Uniformly darkens the input slightly to prevent clipping on blown-out
|
|
|
|
highlights, then clamps colorimetrically to the input gamut boundary,
|
|
|
|
biased slightly to preserve chromaticity over luminance.
|
2022-01-03 03:31:50 +00:00
|
|
|
(``--vo=gpu-next`` only)
|
2023-06-19 10:59:51 +00:00
|
|
|
warn
|
|
|
|
Performs no gamut mapping, but simply highlights out-of-gamut pixels.
|
|
|
|
linear
|
|
|
|
Linearly/uniformly desaturates the image in order to bring the entire
|
|
|
|
image into the target gamut. (``--vo=gpu-next`` only)
|
2022-01-03 03:31:50 +00:00
|
|
|
|
2018-02-03 13:45:01 +00:00
|
|
|
``--hdr-compute-peak=<auto|yes|no>``
|
|
|
|
Compute the HDR peak and frame average brightness per-frame instead of
|
|
|
|
relying on tagged metadata. These values are averaged over local regions as
|
|
|
|
well as over several frames to prevent the value from jittering around too
|
|
|
|
much. This option basically gives you dynamic, per-scene tone mapping.
|
|
|
|
Requires compute shaders, which is a fairly recent OpenGL feature, and will
|
|
|
|
probably also perform horribly on some drivers, so enable at your own risk.
|
|
|
|
The special value ``auto`` (default) will enable HDR peak computation
|
|
|
|
automatically if compute shaders and SSBOs are supported.
|
2017-07-17 19:39:06 +00:00
|
|
|
|
2021-04-09 07:14:54 +00:00
|
|
|
``--allow-delayed-peak-detect``
|
|
|
|
When using ``--hdr-compute-peak``, allow delaying the detected peak by a
|
|
|
|
frame when beneficial for performance. In particular, this is required to
|
|
|
|
avoid an unnecessary FBO indirection when no advanced rendering is required
|
|
|
|
otherwise. Has no effect if there already is an indirect pass, such as when
|
|
|
|
advanced scaling is enabled. Defaults to on. (Only affects
|
|
|
|
``--vo=gpu-next``, note that ``--vo=gpu`` always delays the peak.)
|
|
|
|
|
2023-08-04 14:18:16 +00:00
|
|
|
``--hdr-peak-percentile=<0.0..100.0>``
|
|
|
|
Which percentile of the input image brightness histogram to consider as the
|
|
|
|
true peak of the scene. If this is set to 100 (default), the
|
|
|
|
brightest pixel is measured. Otherwise, the top of the frequency
|
|
|
|
distribution is progressively cut off. Setting this too low will cause
|
|
|
|
clipping of very bright details, but can improve the dynamic brightness
|
|
|
|
range of scenes with very bright isolated highlights. Values other than 100
|
2023-08-05 14:32:26 +00:00
|
|
|
come with a small performance penalty. (Only for ``--vo=gpu-next``)
|
2023-08-04 14:18:16 +00:00
|
|
|
|
2023-08-18 12:16:29 +00:00
|
|
|
``--hdr-peak-decay-rate=<0.0..1000.0>``
|
2019-01-01 06:30:00 +00:00
|
|
|
The decay rate used for the HDR peak detection algorithm (default: 100.0).
|
|
|
|
This is only relevant when ``--hdr-compute-peak`` is enabled. Higher values
|
|
|
|
make the peak decay more slowly, leading to more stable values at the cost
|
|
|
|
of more "eye adaptation"-like effects (although this is mitigated somewhat
|
2023-08-18 12:16:29 +00:00
|
|
|
by ``--hdr-scene-threshold``). A value of 0.0 (the lowest possible) disables
|
2019-01-01 06:30:00 +00:00
|
|
|
all averaging, meaning each frame's value is used directly as measured,
|
|
|
|
but doing this is not recommended for "noisy" sources since it may lead
|
|
|
|
to excessive flicker. (In signal theory terms, this controls the time
|
|
|
|
constant "tau" of an IIR low pass filter)
|
|
|
|
|
2019-01-04 15:46:38 +00:00
|
|
|
``--hdr-scene-threshold-low=<0.0..100.0>``, ``--hdr-scene-threshold-high=<0.0..100.0>``
|
|
|
|
The lower and upper thresholds (in dB) for a brightness difference
|
|
|
|
to be considered a scene change (default: 5.5 low, 10.0 high). This is only
|
2019-01-01 06:30:00 +00:00
|
|
|
relevant when ``--hdr-compute-peak`` is enabled. Normally, small
|
|
|
|
fluctuations in the frame brightness are compensated for by the peak
|
|
|
|
averaging mechanism, but for large jumps in the brightness this can result
|
|
|
|
in the frame remaining too bright or too dark for up to several seconds,
|
|
|
|
depending on the value of ``--hdr-peak-decay-rate``. To counteract this,
|
|
|
|
when the brightness between the running average and the current frame
|
|
|
|
exceeds the low threshold, mpv will make the averaging filter more
|
|
|
|
aggressive, up to the limit of the high threshold (at which point the
|
|
|
|
filter becomes instant).
|
|
|
|
|
2023-07-17 14:37:36 +00:00
|
|
|
``--hdr-contrast-recovery=<0.0..2.0>``, ``--hdr-contrast-smoothness=<1.0..100.0>``
|
|
|
|
Enables the HDR contrast recovery algorithm, which is to designed to
|
|
|
|
enhance contrast of HDR video after tone mapping. The strength (default:
|
|
|
|
0.0) indicates the degree of contrast recovery, with 0.0 being completely
|
|
|
|
disabled and 1.0 being 100% strength. Values higher than 1.0 are allowed,
|
|
|
|
but may result in excessive sharpening. The smoothness (default: 3.5)
|
|
|
|
indicates the degree to which the HDR source is low-passed in order to
|
|
|
|
obtain contrast information - a value of 2.0 corresponds to 2x downscaling.
|
|
|
|
Users on low DPI displays (<= 100) may want to lower this value, while
|
|
|
|
users on very high DPI displays ("retina") may want to increase it. (Only
|
|
|
|
for ``vo=gpu-next``)
|
|
|
|
|
2017-07-25 21:17:04 +00:00
|
|
|
``--use-embedded-icc-profile``
|
|
|
|
Load the embedded ICC profile contained in media files such as PNG images.
|
|
|
|
(Default: yes). Note that this option only works when also using a display
|
|
|
|
ICC profile (``--icc-profile`` or ``--icc-profile-auto``), and also
|
|
|
|
requires LittleCMS 2 support.
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--icc-profile=<file>``
|
|
|
|
Load an ICC profile and use it to transform video RGB to screen output.
|
|
|
|
Needs LittleCMS 2 support compiled in. This option overrides the
|
|
|
|
``--target-prim``, ``--target-trc`` and ``--icc-profile-auto`` options.
|
|
|
|
|
|
|
|
``--icc-profile-auto``
|
|
|
|
Automatically select the ICC display profile currently specified by the
|
|
|
|
display settings of the operating system.
|
|
|
|
|
|
|
|
NOTE: On Windows, the default profile must be an ICC profile. WCS profiles
|
|
|
|
are not supported.
|
|
|
|
|
2018-02-20 12:30:18 +00:00
|
|
|
Applications using libmpv with the render API need to provide the ICC
|
|
|
|
profile via ``MPV_RENDER_PARAM_ICC_PROFILE``.
|
|
|
|
|
2023-05-03 00:42:23 +00:00
|
|
|
``--icc-cache``
|
|
|
|
Store and load 3D LUTs created from the ICC profile on disk in the
|
2023-07-04 19:48:03 +00:00
|
|
|
cache directory (Default: ``yes``). This can be used to speed up loading,
|
|
|
|
since LittleCMS 2 can take a while to create a 3D LUT. Note that these
|
|
|
|
files contain uncompressed LUTs. Their size depends on the
|
|
|
|
``--icc-3dlut-size``, and can be very big.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
NOTE: This is not cleaned automatically, so old, unused cache files may
|
|
|
|
stick around indefinitely.
|
|
|
|
|
2023-05-03 00:42:23 +00:00
|
|
|
``--icc-cache-dir``
|
|
|
|
The directory where icc cache is stored. Cache is stored in the system's
|
|
|
|
cache directory (usually ``~/.cache/mpv``) if this is unset.
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--icc-intent=<value>``
|
|
|
|
Specifies the ICC intent used for the color transformation (when using
|
|
|
|
``--icc-profile``).
|
|
|
|
|
|
|
|
0
|
|
|
|
perceptual
|
|
|
|
1
|
|
|
|
relative colorimetric (default)
|
|
|
|
2
|
|
|
|
saturation
|
|
|
|
3
|
|
|
|
absolute colorimetric
|
|
|
|
|
|
|
|
``--icc-3dlut-size=<r>x<g>x<b>``
|
|
|
|
Size of the 3D LUT generated from the ICC profile in each dimension.
|
|
|
|
Default is 64x64x64. Sizes may range from 2 to 512.
|
|
|
|
|
2021-04-26 16:31:16 +00:00
|
|
|
``--icc-force-contrast=<no|0-1000000|inf>``
|
|
|
|
Override the target device's detected contrast ratio by a specific value.
|
|
|
|
This is detected automatically from the profile if possible, but for some
|
|
|
|
profiles it might be missing, causing the contrast to be assumed as
|
|
|
|
infinite. As a result, video may appear darker than intended. If this is
|
|
|
|
the case, setting this option might help. This only affects BT.1886
|
|
|
|
content. The default of ``no`` means to use the profile values. The special
|
|
|
|
value ``inf`` causes the BT.1886 curve to be treated as a pure power gamma
|
|
|
|
2.4 function.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
2023-04-23 20:49:33 +00:00
|
|
|
``--icc-use-luma``
|
|
|
|
Use ICC profile luminance value. (Only for ``--vo=gpu-next``)
|
|
|
|
|
2021-04-09 07:14:54 +00:00
|
|
|
``--lut=<file>``
|
|
|
|
Specifies a custom LUT (in Adobe .cube format) to apply to the colors
|
|
|
|
as part of color conversion. The exact interpretation depends on the value
|
|
|
|
of ``--lut-type``. (Only for ``--vo=gpu-next``)
|
|
|
|
|
|
|
|
``--lut-type=<value>``
|
|
|
|
Controls the interpretation of color values fed to and from the LUT
|
|
|
|
specified as ``--lut``. Valid values are:
|
|
|
|
|
|
|
|
auto
|
|
|
|
Chooses the interpretation of the LUT automatically from tagged
|
|
|
|
metadata, and otherwise falls back to ``native``. (Default)
|
|
|
|
native
|
|
|
|
Applied to raw image contents in its native RGB colorspace (non-linear
|
|
|
|
light), before conversion to the output color space.
|
|
|
|
normalized
|
|
|
|
Applied to the normalized RGB image contents, in linear light, before
|
|
|
|
conversion to the output color space.
|
|
|
|
conversion
|
|
|
|
Fully replaces the conversion from the image color space to the output
|
|
|
|
color space. If such a LUT is present, it has the highest priority, and
|
|
|
|
overrides any ICC profiles, as well as options related to tone mapping
|
|
|
|
and output colorimetry (``--target-prim``, ``--target-trc`` etc.).
|
|
|
|
|
2016-09-02 13:59:40 +00:00
|
|
|
``--blend-subtitles=<yes|video|no>``
|
|
|
|
Blend subtitles directly onto upscaled video frames, before interpolation
|
|
|
|
and/or color management (default: no). Enabling this causes subtitles to be
|
|
|
|
affected by ``--icc-profile``, ``--target-prim``, ``--target-trc``,
|
2017-09-29 18:12:45 +00:00
|
|
|
``--interpolation``, ``--gamma-factor`` and ``--glsl-shaders``. It also
|
2016-09-02 13:59:40 +00:00
|
|
|
increases subtitle performance when using ``--interpolation``.
|
|
|
|
|
|
|
|
The downside of enabling this is that it restricts subtitles to the visible
|
|
|
|
portion of the video, so you can't have subtitles exist in the black
|
|
|
|
margins below a video (for example).
|
|
|
|
|
|
|
|
If ``video`` is selected, the behavior is similar to ``yes``, but subs are
|
|
|
|
drawn at the video's native resolution, and scaled along with the video.
|
|
|
|
|
|
|
|
.. warning:: This changes the way subtitle colors are handled. Normally,
|
|
|
|
subtitle colors are assumed to be in sRGB and color managed as
|
|
|
|
such. Enabling this makes them treated as being in the video's
|
|
|
|
color space instead. This is good if you want things like
|
|
|
|
softsubbed ASS signs to match the video colors, but may cause
|
|
|
|
SRT subtitles or similar to look slightly off.
|
|
|
|
|
|
|
|
``--alpha=<blend-tiles|blend|yes|no>``
|
|
|
|
Decides what to do if the input has an alpha component.
|
|
|
|
|
|
|
|
blend-tiles
|
|
|
|
Blend the frame against a 16x16 gray/white tiles background (default).
|
|
|
|
blend
|
2016-11-12 18:19:40 +00:00
|
|
|
Blend the frame against the background color (``--background``, normally
|
|
|
|
black).
|
2016-09-02 13:59:40 +00:00
|
|
|
yes
|
|
|
|
Try to create a framebuffer with alpha component. This only makes sense
|
2020-12-05 08:39:10 +00:00
|
|
|
if the video contains alpha information (which is extremely rare) or if
|
|
|
|
you make the background color transparent. May not be supported on all
|
|
|
|
platforms. If alpha framebuffers are unavailable, it silently falls
|
|
|
|
back on a normal framebuffer. Note that if you set the ``--fbo-format``
|
|
|
|
option to a non-default value, a format with alpha must be specified,
|
|
|
|
or this won't work. Whether this really works depends on the windowing
|
|
|
|
system and desktop environment.
|
2016-09-02 13:59:40 +00:00
|
|
|
no
|
|
|
|
Ignore alpha component.
|
|
|
|
|
|
|
|
``--opengl-rectangle-textures``
|
|
|
|
Force use of rectangle textures (default: no). Normally this shouldn't have
|
|
|
|
any advantages over normal textures. Note that hardware decoding overrides
|
2016-10-01 10:01:57 +00:00
|
|
|
this flag. Could be removed any time.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
|
|
|
``--background=<color>``
|
2020-09-16 11:26:48 +00:00
|
|
|
Color used to draw parts of the mpv window not covered by video. See the
|
|
|
|
``--sub-color`` option for how colors are defined.
|
2016-09-02 13:59:40 +00:00
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gpu-tex-pad-x``, ``--gpu-tex-pad-y``
|
2016-10-01 10:01:57 +00:00
|
|
|
Enlarge the video source textures by this many pixels. For debugging only
|
|
|
|
(normally textures are sized exactly, but due to hardware decoding interop
|
|
|
|
we may have to deal with additional padding, which can be tested with these
|
|
|
|
options). Could be removed any time.
|
|
|
|
|
2016-10-21 15:23:26 +00:00
|
|
|
``--opengl-early-flush=<yes|no|auto>``
|
2016-10-05 10:18:44 +00:00
|
|
|
Call ``glFlush()`` after rendering a frame and before attempting to display
|
2016-10-21 15:23:26 +00:00
|
|
|
it (default: auto). Can fix stuttering in some cases, in other cases
|
|
|
|
probably causes it. The ``auto`` mode will call ``glFlush()`` only if
|
|
|
|
the renderer is going to wait for a while after rendering, instead of
|
|
|
|
flipping GL front and backbuffers immediately (i.e. it doesn't call it
|
|
|
|
in display-sync mode).
|
2016-10-05 10:18:44 +00:00
|
|
|
|
2021-01-01 23:53:23 +00:00
|
|
|
On macOS this is always deactivated because it only causes performance
|
2017-12-28 11:42:02 +00:00
|
|
|
problems and other regressions.
|
|
|
|
|
vo_opengl: refactor into vo_gpu
This is done in several steps:
1. refactor MPGLContext -> struct ra_ctx
2. move GL-specific stuff in vo_opengl into opengl/context.c
3. generalize context creation to support other APIs, and add --gpu-api
4. rename all of the --opengl- options that are no longer opengl-specific
5. move all of the stuff from opengl/* that isn't GL-specific into gpu/
(note: opengl/gl_utils.h became opengl/utils.h)
6. rename vo_opengl to vo_gpu
7. to handle window screenshots, the short-term approach was to just add
it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to
ra itself (and vo_gpu altered to compensate), but this was a stop-gap
measure to prevent this commit from getting too big
8. move ra->fns->flush to ra_gl_ctx instead
9. some other minor changes that I've probably already forgotten
Note: This is one half of a major refactor, the other half of which is
provided by rossy's following commit. This commit enables support for
all linux platforms, while his version enables support for all non-linux
platforms.
Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the
--opengl- options like --opengl-early-flush, --opengl-finish etc. Should
be a strict superset of the old functionality.
Disclaimer: Since I have no way of compiling mpv on all platforms, some
of these ports were done blindly. Specifically, the blind ports included
context_mali_fbdev.c and context_rpi.c. Since they're both based on
egl_helpers, the port should have gone smoothly without any major
changes required. But if somebody complains about a compile error on
those platforms (assuming anybody actually uses them), you know where to
complain.
2017-09-14 06:04:55 +00:00
|
|
|
``--gpu-dumb-mode=<yes|no|auto>``
|
|
|
|
This mode is extremely restricted, and will disable most extended
|
2017-07-07 12:46:46 +00:00
|
|
|
features. That includes high quality scalers and custom shaders!
|
2016-12-07 12:26:30 +00:00
|
|
|
|
|
|
|
It is intended for hardware that does not support FBOs (including GLES,
|
|
|
|
which supports it insufficiently), or to get some more performance out of
|
|
|
|
bad or old hardware.
|
|
|
|
|
|
|
|
This mode is forced automatically if needed, and this option is mostly
|
2017-07-07 12:46:46 +00:00
|
|
|
useful for debugging. The default of ``auto`` will enable it automatically
|
|
|
|
if nothing uses features which require FBOs.
|
2016-12-07 12:26:30 +00:00
|
|
|
|
|
|
|
This option might be silently removed in the future.
|
|
|
|
|
2023-05-03 00:42:23 +00:00
|
|
|
``--gpu-shader-cache``
|
2023-07-04 19:48:03 +00:00
|
|
|
Store and load compiled GLSL shaders in the cache directory (Default: ``yes``).
|
|
|
|
Normally, shader compilation is very fast, so this is not usually needed.
|
|
|
|
It mostly matters for GPU APIs that require internally recompiling shaders to
|
|
|
|
other languages, for example anything based on ANGLE or Vulkan. Enabling this
|
|
|
|
can improve startup performance on these platforms.
|
2017-04-08 14:38:56 +00:00
|
|
|
|
|
|
|
NOTE: This is not cleaned automatically, so old, unused cache files may
|
|
|
|
stick around indefinitely.
|
|
|
|
|
2023-05-03 00:42:23 +00:00
|
|
|
``--gpu-shader-cache-dir``
|
|
|
|
The directory where gpu shader cache is stored. Cache is stored in the system's
|
|
|
|
cache directory (usually ``~/.cache/mpv``) if this is unset.
|
|
|
|
|
2023-08-18 15:25:52 +00:00
|
|
|
``--libplacebo-opts=<key>=<value>[,<key>=<value>[,...]]``
|
|
|
|
Passes extra raw option to the libplacebo rendering backend (used by
|
|
|
|
``--vo=gpu-next``). May override the effects of any other options set using
|
|
|
|
the normal options system. Requires libplacebo v6.309 or higher. Included
|
|
|
|
for debugging purposes only. For more information, see:
|
|
|
|
|
|
|
|
https://code.videolan.org/videolan/libplacebo/-/blob/master/src/options.c#L877
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Miscellaneous
|
|
|
|
-------------
|
2013-09-01 01:27:03 +00:00
|
|
|
|
2014-12-29 21:51:18 +00:00
|
|
|
``--display-tags=tag1,tags2,...``
|
|
|
|
Set the list of tags that should be displayed on the terminal. Tags that
|
|
|
|
are in the list, but are not present in the played file, will not be shown.
|
2015-01-12 03:54:34 +00:00
|
|
|
If a value ends with ``*``, all tags are matched by prefix (though there
|
|
|
|
is no general globbing). Just passing ``*`` essentially filtering.
|
2014-12-29 21:51:18 +00:00
|
|
|
|
|
|
|
The default includes a common list of tags, call mpv with ``--list-options``
|
|
|
|
to see it.
|
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--mc=<seconds/frame>``
|
|
|
|
Maximum A-V sync correction per frame (in seconds)
|
2013-12-13 21:25:38 +00:00
|
|
|
|
2015-04-24 20:55:01 +00:00
|
|
|
``--autosync=<factor>``
|
|
|
|
Gradually adjusts the A/V sync based on audio delay measurements.
|
|
|
|
Specifying ``--autosync=0``, the default, will cause frame timing to be
|
|
|
|
based entirely on audio delay measurements. Specifying ``--autosync=1``
|
|
|
|
will do the same, but will subtly change the A/V correction algorithm. An
|
|
|
|
uneven video framerate in a video which plays fine with ``--no-audio`` can
|
|
|
|
often be helped by setting this to an integer value greater than 1. The
|
|
|
|
higher the value, the closer the timing will be to ``--no-audio``. Try
|
|
|
|
``--autosync=30`` to smooth out problems with sound drivers which do not
|
|
|
|
implement a perfect audio delay measurement. With this value, if large A/V
|
|
|
|
sync offsets occur, they will only take about 1 or 2 seconds to settle
|
|
|
|
out. This delay in reaction time to sudden A/V offsets should be the only
|
2015-12-19 08:26:27 +00:00
|
|
|
side effect of turning this option on, for all sound drivers.
|
2015-04-24 20:55:01 +00:00
|
|
|
|
2018-03-13 10:23:23 +00:00
|
|
|
``--video-timing-offset=<seconds>``
|
|
|
|
Control how long before video display target time the frame should be
|
|
|
|
rendered (default: 0.050). If a video frame should be displayed at a
|
|
|
|
certain time, the VO will start rendering the frame earlier, and then will
|
|
|
|
perform a blocking wait until the display time, and only then "swap" the
|
|
|
|
frame to display. The rendering cannot start before the previous frame is
|
|
|
|
displayed, so this value is implicitly limited by the video framerate. With
|
|
|
|
normal video frame rates, the default value will ensure that rendering is
|
|
|
|
always immediately started after the previous frame was displayed. On the
|
|
|
|
other hand, setting a too high value can reduce responsiveness with low
|
|
|
|
FPS value.
|
|
|
|
|
2021-11-29 11:39:20 +00:00
|
|
|
This option is interesting for client API users using the render API
|
|
|
|
because you can stop it from limiting your FPS
|
|
|
|
(see ``mpv_render_context_render()`` documentation).
|
2018-03-13 10:23:23 +00:00
|
|
|
|
|
|
|
This applies only to audio timing modes (e.g. ``--video-sync=audio``). In
|
|
|
|
other modes (``--video-sync=display-...``), video timing relies on vsync
|
|
|
|
blocking, and this option is not used.
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
``--video-sync=<audio|...>``
|
|
|
|
How the player synchronizes audio and video.
|
|
|
|
|
2017-03-25 16:06:04 +00:00
|
|
|
If you use this option, you usually want to set it to ``display-resample``
|
|
|
|
to enable a timing mode that tries to not skip or repeat frames when for
|
|
|
|
example playing 24fps video on a 24Hz screen.
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
The modes starting with ``display-`` try to output video frames completely
|
|
|
|
synchronously to the display, using the detected display vertical refresh
|
|
|
|
rate as a hint how fast frames will be displayed on average. These modes
|
|
|
|
change video speed slightly to match the display. See ``--video-sync-...``
|
|
|
|
options for fine tuning. The robustness of this mode is further reduced by
|
|
|
|
making a some idealized assumptions, which may not always apply in reality.
|
|
|
|
Behavior can depend on the VO and the system's video and audio drivers.
|
|
|
|
Media files must use constant framerate. Section-wise VFR might work as well
|
video: do not disable display-sync on A/V desync
On a audio/video desync by more than 0.5 seconds, display-sync mode was
disabled, and not enabled again (until playback restart, e.g. a seek).
The idea was that it this only happens when this playback mode is broken
and can't perform well anyway (A/V desync is a clear indication that
something is very wrong). Instead of behaving like a god damn POS, it
should revert to the more robust audio-sync mode.
Unfortunately, this could happen sporadically due to temporary system
performance problems, such as toggling fullscreen. Users didn't like
this, and asked for a function to disable it, or to recover in some
other way.
This mechanism is questionable anyway. If an ignorant user enables
display-sync, and encounters problems with it (without being able to
determine that display-sync is messing up), the player will still behave
like a POS on every playback, and even after every seek. It might
actually be helpful to fail more consistently. Also, I've found that
it's sill relatively reliable anyway even without this mechanism.
So just remove the fallback.
Fixes: #7048
2019-10-17 17:23:35 +00:00
|
|
|
with some container formats (but not e.g. mkv).
|
|
|
|
|
|
|
|
Under some circumstances, the player automatically reverts to ``audio`` mode
|
|
|
|
for some time or permanently. This can happen on very low framerate video,
|
|
|
|
or if the framerate cannot be detected.
|
|
|
|
|
|
|
|
Also in display-sync modes it can happen that interruptions to video
|
|
|
|
playback (such as toggling fullscreen mode, or simply resizing the window)
|
|
|
|
will skip the video frames that should have been displayed, while ``audio``
|
|
|
|
mode will display them after the renderer has resumed (typically resulting
|
|
|
|
in a short A/V desync and the video "catching up").
|
|
|
|
|
|
|
|
Before mpv 0.30.0, there was a fallback to ``audio`` mode on severe A/V
|
|
|
|
desync. This was changed for the sake of not sporadically stopping. Now,
|
|
|
|
``display-desync`` does what it promises and may desync with audio by an
|
|
|
|
arbitrary amount, until it is manually fixed with a seek.
|
|
|
|
|
|
|
|
These modes also require a vsync blocked presentation mode. For OpenGL, this
|
vo_gpu: vulkan: initial implementation
This time based on ra/vo_gpu. 2017 is the year of the vulkan desktop!
Current problems / limitations / improvement opportunities:
1. The swapchain/flipping code violates the vulkan spec, by assuming
that the presentation queue will be bounded (in cases where rendering
is significantly faster than vsync). But apparently, there's simply
no better way to do this right now, to the point where even the
stupid cube.c examples from LunarG etc. do it wrong.
(cf. https://github.com/KhronosGroup/Vulkan-Docs/issues/370)
2. The memory allocator could be improved. (This is a universal
constant)
3. Could explore using push descriptors instead of descriptor sets,
especially since we expect to switch descriptors semi-often for some
passes (like interpolation). Probably won't make a difference, but
the synchronization overhead might be a factor. Who knows.
4. Parallelism across frames / async transfer is not well-defined, we
either need to use a better semaphore / command buffer strategy or a
resource pooling layer to safely handle cross-frame parallelism.
(That said, I gave resource pooling a try and was not happy with the
result at all - so I'm still exploring the semaphore strategy)
5. We aggressively use pipeline barriers where events would offer a much
more fine-grained synchronization mechanism. As a result of this, we
might be suffering from GPU bubbles due to too-short dependencies on
objects. (That said, I'm also exploring the use of semaphores as a an
ordering tactic which would allow cross-frame time slicing in theory)
Some minor changes to the vo_gpu and infrastructure, but nothing
consequential.
NOTE: For safety, all use of asynchronous commands / multiple command
pools is currently disabled completely. There are some left-over relics
of this in the code (e.g. the distinction between dev_poll and
pool_poll), but that is kept in place mostly because this will be
re-extended in the future (vulkan rev 2).
The queue count is also currently capped to 1, because of the lack of
cross-frame semaphores means we need the implicit synchronization from
the same-queue semantics to guarantee a correct result.
2016-09-14 18:54:18 +00:00
|
|
|
translates to ``--opengl-swapinterval=1``. For Vulkan, it translates to
|
|
|
|
``--vulkan-swap-mode=fifo`` (or ``fifo-relaxed``).
|
2015-08-10 16:43:25 +00:00
|
|
|
|
|
|
|
The modes with ``desync`` in their names do not attempt to keep audio/video
|
|
|
|
in sync. They will slowly (or quickly) desync, until e.g. the next seek
|
|
|
|
happens. These modes are meant for testing, not serious use.
|
|
|
|
|
|
|
|
:audio: Time video frames to audio. This is the most robust
|
|
|
|
mode, because the player doesn't have to assume anything
|
|
|
|
about how the display behaves. The disadvantage is that
|
|
|
|
it can lead to occasional frame drops or repeats. If
|
|
|
|
audio is disabled, this uses the system clock. This is
|
|
|
|
the default mode.
|
|
|
|
:display-resample: Resample audio to match the video. This mode will also
|
|
|
|
try to adjust audio speed to compensate for other drift.
|
|
|
|
(This means it will play the audio at a different speed
|
|
|
|
every once in a while to reduce the A/V difference.)
|
|
|
|
:display-resample-vdrop: Resample audio to match the video. Drop video
|
|
|
|
frames to compensate for drift.
|
|
|
|
:display-resample-desync: Like the previous mode, but no A/V compensation.
|
2022-08-03 21:47:07 +00:00
|
|
|
:display-tempo: Same as ``display-resample``, but apply audio speed
|
|
|
|
changes to audio filters instead of resampling to avoid
|
|
|
|
the change in pitch. Beware that some audio filters
|
|
|
|
don't do well with a speed close to 1. It is recommend
|
|
|
|
to use a conditional profile to automatically switch to
|
|
|
|
``display-resample`` when speed gets too close to 1 for
|
|
|
|
your filter setup. Use (speed * video_speed_correction)
|
|
|
|
to get the actual playback speed in the condition.
|
|
|
|
See `Conditional auto profiles`_ for details.
|
2015-08-10 16:43:25 +00:00
|
|
|
:display-vdrop: Drop or repeat video frames to compensate desyncing
|
|
|
|
video. (Although it should have the same effects as
|
|
|
|
``audio``, the implementation is very different.)
|
2015-10-27 19:56:46 +00:00
|
|
|
:display-adrop: Drop or repeat audio data to compensate desyncing
|
2021-05-29 02:16:35 +00:00
|
|
|
video. This mode will cause severe audio artifacts if
|
|
|
|
the real monitor refresh rate is too different from
|
|
|
|
the reported or forced rate. Since mpv 0.33.0, this
|
|
|
|
acts on entire audio frames, instead of single samples.
|
2015-08-10 16:43:25 +00:00
|
|
|
:display-desync: Sync video to display, and let audio play on its own.
|
|
|
|
:desync: Sync video according to system clock, and let audio play
|
|
|
|
on its own.
|
|
|
|
|
2020-05-23 01:48:51 +00:00
|
|
|
``--video-sync-max-factor=<value>``
|
|
|
|
Maximum multiple for which to try to fit the video's FPS to the display's
|
|
|
|
FPS (default: 5).
|
|
|
|
|
|
|
|
For example, if this is set to 1, the video FPS is forced to an integer
|
|
|
|
multiple of the display FPS, as long as the speed change does not exceed
|
|
|
|
the value set by ``--video-sync-max-video-change``.
|
|
|
|
|
vo_gpu: adjust interpolation_threshold's default
When mpv attempts to play a video that is, on average, 60 FPS on a
display that is not exactly 60.00 Hz, two options try to fight each
other: `video-sync-max-video-change` and `interpolation-threshold`.
Normally, container FPS in something such as an .mp4 or a .mkv is
precise enough such that the video can be retimed exactly to the display
Hz and interpolation is not activated.
In the case of something like certain live streaming videos or other scenario
where container FPS is not known, the default option of 0.0001 for
`interpolation-threshold` is extremely low, and while
`video-sync-max-video-change` retimes the video to what it approximately
knows as the "real" FPS, this may or may not be outside of
`interpolation-threshold`'s logic at any given time, which causes
interpolation to be frequently flipped on and off giving an appearance
of stuttering or repeated frames that is oftern quite jarring and makes
a video unwatchable.
This commit changes the default of `interpolation-threshold` to 0.01,
which is the same value as `video-sync-max-video-change`, and guarantees
that if the user accepts a video being retimed to match the display,
they do not additionally have to worry about a much more
precise interpolation threshold randomly flipping on or off. No internal
logic is changed so setting `interpolation-threshold` to -1 will still
disable this logic entirely and always enable interpolation.
The documentation has been updated to reflect this change and give
context to the user for which scenarios they might want to disable
`interpolation-threshold` logic or change it to a smaller value.
2021-03-17 01:44:29 +00:00
|
|
|
See ``--interpolation-threshold`` for how this option affects
|
|
|
|
interpolation.
|
|
|
|
|
2015-08-10 16:43:25 +00:00
|
|
|
``--video-sync-max-video-change=<value>``
|
|
|
|
Maximum speed difference in percent that is applied to video with
|
|
|
|
``--video-sync=display-...`` (default: 1). Display sync mode will be
|
|
|
|
disabled if the monitor and video refresh way do not match within the
|
|
|
|
given range. It tries multiples as well: playing 30 fps video on a 60 Hz
|
|
|
|
screen will duplicate every second frame. Playing 24 fps video on a 60 Hz
|
|
|
|
screen will play video in a 2-3-2-3-... pattern.
|
|
|
|
|
|
|
|
The default settings are not loose enough to speed up 23.976 fps video to
|
|
|
|
25 fps. We consider the pitch change too extreme to allow this behavior
|
|
|
|
by default. Set this option to a value of ``5`` to enable it.
|
|
|
|
|
2022-08-03 21:47:07 +00:00
|
|
|
Note that ``--video-sync=display-tempo`` avoids this pitch change.
|
|
|
|
|
|
|
|
Also note that in the ``--video-sync=display-resample`` or
|
|
|
|
``--video-sync=display-tempo`` mode, audio speed will additionally be
|
|
|
|
changed by a small amount if necessary for A/V sync. See
|
2015-08-10 16:43:25 +00:00
|
|
|
``--video-sync-max-audio-change``.
|
|
|
|
|
2015-08-10 22:14:13 +00:00
|
|
|
``--video-sync-max-audio-change=<value>``
|
2015-08-10 16:43:25 +00:00
|
|
|
Maximum *additional* speed difference in percent that is applied to audio
|
|
|
|
with ``--video-sync=display-...`` (default: 0.125). Normally, the player
|
2016-08-20 16:15:24 +00:00
|
|
|
plays the audio at the speed of the video. But if the difference between
|
2015-08-10 16:43:25 +00:00
|
|
|
audio and video position is too high, e.g. due to drift or other timing
|
|
|
|
errors, it will attempt to speed up or slow down audio by this additional
|
|
|
|
factor. Too low values could lead to video frame dropping or repeating if
|
|
|
|
the A/V desync cannot be compensated, too high values could lead to chaotic
|
|
|
|
frame dropping due to the audio "overshooting" and skipping multiple video
|
|
|
|
frames before the sync logic can react.
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--mf-fps=<value>``
|
|
|
|
Framerate used when decoding from multiple PNG or JPEG files with ``mf://``
|
|
|
|
(default: 1).
|
2013-09-01 01:27:03 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--mf-type=<value>``
|
|
|
|
Input file type for ``mf://`` (available: jpeg, png, tga, sgi). By default,
|
|
|
|
this is guessed from the file extension.
|
2013-09-01 01:27:03 +00:00
|
|
|
|
2017-01-21 16:19:01 +00:00
|
|
|
``--stream-dump=<destination-filename>``
|
|
|
|
Instead of playing a file, read its byte stream and write it to the given
|
|
|
|
destination file. The destination is overwritten. Can be useful to test
|
|
|
|
network-related behavior.
|
2013-06-14 22:15:32 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--stream-lavf-o=opt1=value1,opt2=value2,...``
|
|
|
|
Set AVOptions on streams opened with libavformat. Unknown or misspelled
|
|
|
|
options are silently ignored. (They are mentioned in the terminal output
|
|
|
|
in verbose mode, i.e. ``--v``. In general we can't print errors, because
|
|
|
|
other options such as e.g. user agent are not available with all protocols,
|
|
|
|
and printing errors for unknown options would end up being too noisy.)
|
2013-06-14 22:15:32 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a key/value list option. See `List Options`_ for details.
|
|
|
|
|
2015-12-06 18:20:23 +00:00
|
|
|
``--vo-mmcss-profile=<name>``
|
|
|
|
(Windows only.)
|
|
|
|
Set the MMCSS profile for the video renderer thread (default: ``Playback``).
|
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
``--priority=<prio>``
|
|
|
|
(Windows only.)
|
|
|
|
Set process priority for mpv according to the predefined priorities
|
|
|
|
available under Windows.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
Possible values of ``<prio>``:
|
|
|
|
idle|belownormal|normal|abovenormal|high|realtime
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2014-07-31 14:32:37 +00:00
|
|
|
.. warning:: Using realtime priority can cause system lockup.
|
manpage: merge new manpage
About a year ago, ubitux converted most of the old manpage from the
hard to maintain nroff format to reStructuredText. This was not merged
back into the master repository immediately. The argument was that the
new manpage still required work to be done. However, progress was very
slow. Even worse: the old manpage wasn't updated, because it was
scheduled for deletion, and updating it would have meant useless work.
Now the situation is that the new manpage still isn't finished, and the
old manpage is grossly out of sync with the player. This is not helpful
for users. Additionally, keeping the new manpage in a separate branch,
while the normal development repository for code had the old manpage,
was very inconvenient, because you couldn't just update the
documentation in the same commit as the code.
Even though the new manpage isn't finished yet, merging it now seems to
be the best course of action. Squash-merge the manpage development
branch [1], revision e89f5dd3f2, which branches from the mplayer2
master branch after revision 159102e0cb.
Committers:
* Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.)
* Uoti Urpala <uau@mplayer2.org> (Many updates.)
* Myself (Minor edits.)
Most text of the manpage has been directly taken from the old manpage,
because this is a conversion, not a complete rewrite.
[1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
|
|
|
|
2015-05-24 05:16:12 +00:00
|
|
|
``--force-media-title=<string>``
|
2014-09-02 20:28:11 +00:00
|
|
|
Force the contents of the ``media-title`` property to this value. Useful
|
|
|
|
for scripts which want to set a title, without overriding the user's
|
|
|
|
setting in ``--title``.
|
2016-02-05 22:19:56 +00:00
|
|
|
|
2017-07-02 14:26:41 +00:00
|
|
|
``--external-files=<file-list>``
|
2017-05-16 10:20:01 +00:00
|
|
|
Load a file and add all of its tracks. This is useful to play different
|
|
|
|
files together (for example audio from one file, video from another), or
|
|
|
|
for advanced ``--lavfi-complex`` used (like playing two video files at
|
|
|
|
the same time).
|
|
|
|
|
2017-07-02 14:26:41 +00:00
|
|
|
Unlike ``--sub-files`` and ``--audio-files``, this includes all tracks, and
|
2017-05-16 10:20:01 +00:00
|
|
|
does not cause default stream selection over the "proper" file. This makes
|
2018-01-06 16:49:37 +00:00
|
|
|
it slightly less intrusive. (In mpv 0.28.0 and before, this was not quite
|
|
|
|
strictly enforced.)
|
2016-02-08 20:18:35 +00:00
|
|
|
|
options: increase consistency between list options and document them
Whenever I deal with this, I have to look at the code to make sense of
this. And beyond that, there are some strange inconsistencies. (I think
this code is cursed. It always was, and maybe always will be.)
Although the manpage claimed that using multiple items for -add etc. is
deprecated, string list options didn't warn against it. So add the
warning, and add something in the changelog (even though nobody will
ever read this).
The manpage mentioned --vf-append, but this didn't even exist. So add
it, I guess. We encourage using -append for the other option types, so
for consistency, it should work on filter options. (And I already
tricked me into believing it existed when I mentioned it in the
manpage.)
Make the "operations" table separate for all option types, and mention
the option type on every single of the top-level list options.
2019-12-18 04:11:57 +00:00
|
|
|
This is a path list option. See `List Options`_ for details.
|
options: change path list options, and document list options
The changes to path list options is basically getting rid of the need to
pass multiple paths to a single option. Instead, you can use the option
multiple times. The old behavior can be used by using the -set suffix
with the option.
Change some options to path lists. For example --script is now append by
default, and if you use --script-set, you need to use ":"/";" as
separator instead of ",".
--sub-paths/--audio-file-paths is a deprecated alias now, and will break
if the user tries to pass multiple paths to it. I'm assuming that if
these are used, most users will pass only 1 path anyway.
--opengl-shaders has more compatibility handling, since it's probably
rather common that users pass multiple options to it.
Also document all that in the manpage.
I'll probably regret this later, as it somewhat increases the complexity
of the option parser, rather than increasing it.
2017-06-30 14:39:36 +00:00
|
|
|
|
2017-07-02 14:26:41 +00:00
|
|
|
``--external-file=<file>``
|
|
|
|
CLI/config file only alias for ``--external-files-append``. Each use of this
|
2020-09-27 22:12:52 +00:00
|
|
|
option will add a new external file.
|
|
|
|
|
|
|
|
``--cover-art-files=<file-list>``
|
|
|
|
Use an external file as cover art while playing audio. This makes it appear
|
|
|
|
on the track list and subject to automatic track selection. Options like
|
|
|
|
``--audio-display`` control whether such tracks are supposed to be selected.
|
|
|
|
|
|
|
|
(The difference to loading a file with ``--external-files`` is that video
|
|
|
|
tracks will be marked as being pictures, which affects the auto-selection
|
|
|
|
method. If the passed file is a video, only the first frame will be decoded
|
|
|
|
and displayed. Enabling the cover art track during playback may show a
|
|
|
|
random frame if the source file is a video. Normally you're not supposed to
|
|
|
|
pass videos to this option, so this paragraph describes the behavior
|
|
|
|
coincidentally resulting from implementation details.)
|
|
|
|
|
|
|
|
This is a path list option. See `List Options`_ for details.
|
|
|
|
|
|
|
|
``--cover-art-file=<file>``
|
|
|
|
CLI/config file only alias for ``--cover-art-files-append``. Each use of this
|
|
|
|
option will add a new external file.
|
|
|
|
|
2021-07-21 08:10:29 +00:00
|
|
|
``--cover-art-auto=<no|exact|fuzzy|all>``
|
2021-03-22 09:21:52 +00:00
|
|
|
Whether to load _external_ cover art automatically. Similar to
|
|
|
|
``--sub-auto`` and ``--audio-file-auto``. If a video already has tracks
|
|
|
|
(which are not marked as cover art), external cover art will not be loaded.
|
|
|
|
|
|
|
|
:no: Don't automatically load cover art.
|
2021-12-03 15:59:26 +00:00
|
|
|
:exact: Load the media filename with an image file extension (default).
|
|
|
|
:fuzzy: Load all cover art containing the media filename.
|
2021-06-21 16:27:44 +00:00
|
|
|
:all: Load all images in the current directory.
|
2020-09-27 22:12:52 +00:00
|
|
|
|
|
|
|
See ``--cover-art-files`` for details about what constitutes cover art.
|
|
|
|
|
|
|
|
See ``--audio-display`` how to control display of cover art (this can be
|
|
|
|
used to disable cover art that is part of the file).
|
2017-07-02 14:26:41 +00:00
|
|
|
|
player: make all autoload extensions configurable
--audio-file-auto, --cover-art-auto, and --sub-auto all work by using an
internally hardcoded list that determine what file extensions get
recognized. This is fine and people periodically update it, but we can
actually expose this as a stringlist option instead. This way users can
add or remove any file extension for any type. For the most part, this
is pretty pretty easy and involves making sub_exts, etc. the defaults
for the new options (--audio-file-auto-exts, --cover-art-auto-exts, and
--sub-auto-exts). There's actually one slight complication however. The
input code uses mp_might_be_subtitle_file which guesses if the file drag
and dropped file is a subtitle. The input ctx has no access to mpctx so
we have to be clever here.
For this, the trick is to recognize that we can leverage the
m_option_change_callback. We add a new flag, UPDATE_SUB_EXTS, which
fires when the player starts up. Then in the callback, we can set the
value of sub_exts in external_files to opts->sub_auto_exts. Whenever the
option updates, the callback is fired again and sub_exts updates. That
way mp_might_be_subtitle_file can just operate off of this global
variable instead of trying to mess with the core mpv state directly.
Fixes #12000.
2023-08-10 22:36:22 +00:00
|
|
|
``--cover-art-auto-exts=ext1,ext2,...``
|
|
|
|
Cover art extentions to try and match when using ``cover-art-auto``.
|
|
|
|
|
|
|
|
This is a string list option. See `List Options`_ for details.
|
|
|
|
|
2021-12-03 15:52:53 +00:00
|
|
|
``--cover-art-whitelist=<no|yes>``
|
|
|
|
Whether to load filenames in an internal whitelist, such as ``cover.jpg``,
|
|
|
|
as cover art. If ``cover-art-auto`` is set to ``no``, the whitelisted
|
|
|
|
filenames are never loaded even if this option is set to ``yes``.
|
|
|
|
|
|
|
|
Default: ``yes``.
|
|
|
|
|
2016-08-10 20:22:50 +00:00
|
|
|
``--autoload-files=<yes|no>``
|
|
|
|
Automatically load/select external files (default: yes).
|
|
|
|
|
|
|
|
If set to ``no``, then do not automatically load external files as specified
|
2021-05-27 19:25:59 +00:00
|
|
|
by ``--sub-auto``, ``--audio-file-auto`` and ``--cover-art-auto``. If
|
|
|
|
external files are forcibly added (like with ``--sub-files``), they will
|
|
|
|
not be auto-selected.
|
2016-08-10 20:22:50 +00:00
|
|
|
|
|
|
|
This does not affect playlist expansion, redirection, or other loading of
|
|
|
|
referenced files like with ordered chapters.
|
|
|
|
|
2017-02-08 05:54:47 +00:00
|
|
|
``--record-file=<file>``
|
2019-07-13 13:41:42 +00:00
|
|
|
Deprecated, use ``--stream-record``, or the ``dump-cache`` command.
|
|
|
|
|
2017-02-07 16:05:17 +00:00
|
|
|
Record the current stream to the given target file. The target file will
|
|
|
|
always be overwritten without asking.
|
|
|
|
|
2019-07-13 13:41:42 +00:00
|
|
|
This was deprecated because it isn't very nice to use. For one, seeking
|
|
|
|
while this is enabled will be directly reflected in the output, which was
|
|
|
|
not useful and annoying.
|
2017-02-07 16:05:17 +00:00
|
|
|
|
2019-07-13 13:41:42 +00:00
|
|
|
``--stream-record=<file>``
|
|
|
|
Write received/read data from the demuxer to the given output file. The
|
|
|
|
output file will always be overwritten without asking. The output format
|
|
|
|
is determined by the extension of the output file.
|
2017-02-07 16:05:17 +00:00
|
|
|
|
2019-07-13 13:41:42 +00:00
|
|
|
Switching streams or seeking during recording might result in recording
|
|
|
|
being stopped and/or broken files. Use with care.
|
2017-02-07 16:05:17 +00:00
|
|
|
|
2019-07-13 13:41:42 +00:00
|
|
|
Seeking outside of the demuxer cache will result in "skips" in the output
|
|
|
|
file, but seeking within the demuxer cache should not affect recording. One
|
|
|
|
exception is when you seek back far enough to exceed the forward buffering
|
|
|
|
size, in which case the cache stops actively reading. This will return in
|
|
|
|
dropped data if it's a live stream.
|
2019-06-30 18:09:27 +00:00
|
|
|
|
|
|
|
If this is set at runtime, the old file is closed, and the new file is
|
|
|
|
opened. Note that this will write only data that is appended at the end of
|
demux, command: add a third stream recording mechanism
That's right, and it's probably not the end of it. I'll just claim that
I have no idea how to create a proper user interface for this, so I'm
creating multiple partially-orthogonal, of which some may work better in
each of its special use cases.
Until now, there was --record-file. You get relatively good control
about what is muxed, and it can use the cache. But it sucks that it's
bound to playback. If you pause while it's set, muxing stops. If you
seek while it's set, the output will be sort-of trashed, and that's by
design.
Then --stream-record was added. This is a bit better (especially for
live streams), but you can't really control well when muxing stops or
ends. In particular, it can't use the cache (it just dumps whatever the
underlying demuxer returns).
Today, the idea is that the user should just be able to select a time
range to dump to a file, and it should not affected by the user seeking
around in the cache. In addition, the stream may still be running, so
there's some need to continue dumping, even if it's redundant to
--stream-record.
One notable thing is that it uses the async command shit. Not sure
whether this is a good idea. Maybe not, but whatever. Also, a user can
always use the "async" prefix to pretend it doesn't.
Much of this was barely tested (especially the reinterleaving crap),
let's just hope it mostly works. I'm sure you can tolerate the one or
other crash?
2019-07-07 18:38:22 +00:00
|
|
|
the cache, and the already cached data cannot be written. You can try the
|
|
|
|
``dump-cache`` command as an alternative.
|
2018-09-01 14:06:41 +00:00
|
|
|
|
2019-07-13 13:41:42 +00:00
|
|
|
External files (``--audio-file`` etc.) are ignored by this, it works on the
|
|
|
|
"main" file only. Using this with files using ordered chapters or EDL files
|
|
|
|
will also not work correctly in general.
|
|
|
|
|
|
|
|
There are some glitches with this because it uses FFmpeg's libavformat for
|
|
|
|
writing the output file. For example, it's typical that it will only work if
|
|
|
|
the output format is the same as the input format. This is the case even if
|
|
|
|
it works with the ``ffmpeg`` tool. One reason for this is that ``ffmpeg``
|
|
|
|
and its libraries contain certain hacks and workarounds for these issues,
|
|
|
|
that are unavailable to outside users.
|
|
|
|
|
|
|
|
This replaces ``--record-file``. It is similar to the ancient/removed
|
2022-09-20 14:08:28 +00:00
|
|
|
``--stream-capture``/``--capture`` options, and provides better behavior in
|
2019-07-13 13:41:42 +00:00
|
|
|
most cases (i.e. actually works).
|
|
|
|
|
2016-02-05 22:19:56 +00:00
|
|
|
``--lavfi-complex=<string>``
|
|
|
|
Set a "complex" libavfilter filter, which means a single filter graph can
|
|
|
|
take input from multiple source audio and video tracks. The graph can result
|
|
|
|
in a single audio or video output (or both).
|
|
|
|
|
|
|
|
Currently, the filter graph labels are used to select the participating
|
|
|
|
input tracks and audio/video output. The following rules apply:
|
|
|
|
|
|
|
|
- A label of the form ``aidN`` selects audio track N as input (e.g.
|
|
|
|
``aid1``).
|
|
|
|
- A label of the form ``vidN`` selects video track N as input.
|
2016-05-06 08:15:33 +00:00
|
|
|
- A label named ``ao`` will be connected to the audio output.
|
2016-02-05 22:19:56 +00:00
|
|
|
- A label named ``vo`` will be connected to the video output.
|
|
|
|
|
|
|
|
Each label can be used only once. If you want to use e.g. an audio stream
|
|
|
|
for multiple filters, you need to use the ``asplit`` filter. Multiple
|
|
|
|
video or audio outputs are not possible, but you can use filters to merge
|
|
|
|
them into one.
|
|
|
|
|
2017-08-17 08:56:53 +00:00
|
|
|
It's not possible to change the tracks connected to the filter at runtime,
|
|
|
|
unless you explicitly change the ``lavfi-complex`` property and set new
|
|
|
|
track assignments. When the graph is changed, the track selection is changed
|
|
|
|
according to the used labels as well.
|
|
|
|
|
|
|
|
Other tracks, as long as they're not connected to the filter, and the
|
2016-02-05 22:19:56 +00:00
|
|
|
corresponding output is not connected to the filter, can still be freely
|
2017-08-17 08:56:53 +00:00
|
|
|
changed with the normal methods.
|
2016-02-05 22:19:56 +00:00
|
|
|
|
2016-02-12 19:28:39 +00:00
|
|
|
Note that the normal filter chains (``--af``, ``--vf``) are applied between
|
|
|
|
the complex graphs (e.g. ``ao`` label) and the actual output.
|
|
|
|
|
2016-02-05 22:19:56 +00:00
|
|
|
.. admonition:: Examples
|
|
|
|
|
2016-02-08 20:20:05 +00:00
|
|
|
- ``--lavfi-complex='[aid1] [aid2] amix [ao]'``
|
|
|
|
Play audio track 1 and 2 at the same time.
|
2016-02-05 22:19:56 +00:00
|
|
|
- ``--lavfi-complex='[vid1] [vid2] vstack [vo]'``
|
|
|
|
Stack video track 1 and 2 and play them at the same time. Note that
|
|
|
|
both tracks need to have the same width, or filter initialization
|
|
|
|
will fail (you can add ``scale`` filters before the ``vstack`` filter
|
|
|
|
to fix the size).
|
2018-03-22 16:17:43 +00:00
|
|
|
To load a video track from another file, you can use
|
|
|
|
``--external-file=other.mkv``.
|
2016-02-26 23:11:53 +00:00
|
|
|
- ``--lavfi-complex='[aid1] asplit [t1] [ao] ; [t1] showvolume [t2] ; [vid1] [t2] overlay [vo]'``
|
|
|
|
Play audio track 1, and overlay the measured volume for each speaker
|
|
|
|
over video track 1.
|
2016-03-04 22:51:55 +00:00
|
|
|
- ``null:// --lavfi-complex='life [vo]'``
|
2017-09-27 14:23:59 +00:00
|
|
|
A libavfilter source-only filter (Conways' Life Game).
|
2016-02-05 22:19:56 +00:00
|
|
|
|
2016-05-06 08:15:33 +00:00
|
|
|
See the FFmpeg libavfilter documentation for details on the available
|
|
|
|
filters.
|
test: make tests part of the mpv binary
Until now, each .c file in test/ was built as separate, self-contained
binary. Each binary could be run to execute the tests it contained.
Change this and make them part of the normal mpv binary. Now the tests
have to be invoked via the --unittest option. Do this for two reasons:
- Tests now run within a "properly" initialized mpv instance, so all
services are available.
- Possibly simplifying the situation for future build systems.
The first point is the main motivation. The mpv code is entangled with
mp_log and the option system. It feels like a bad idea to duplicate some
of the initialization of this just so you can call code using them.
I'm also getting rid of cmocka. There wouldn't be any problem to keep it
(it's a perfectly sane set of helpers), but NIH calls. I would have had
to aggregate all tests into a CMUnitTest list, and I don't see how I'd
get different types of entry points easily. Probably easily solvable,
but since we made only pretty basic use of this library, NIH-ing this is
actually easier (I needed a list of tests with custom metadata anyway,
so all what was left was reimplement the assert_* helpers).
Unit tests now don't output anything, and if they fail, they'll simply
crash and leave a message that typically requires inspecting the test
code to figure out what went wrong (and probably editing the test code
to get more information). I even merged the various test functions into
single ones. Sucks, but here you go.
chmap_sel.c is merged into chmap.c, because I didn't see the point of
this being separate. json.c drops the print_message() to go along with
the new silent-by-default idea, also there's a memory leak fix unrelated
to the rest of this commit.
The new code is enabled with --enable-tests (--enable-test goes away).
Due to waf's option parser, --enable-test still works, because it's a
unique prefix to --enable-tests.
2019-11-07 21:42:14 +00:00
|
|
|
|
2019-12-20 11:37:26 +00:00
|
|
|
``--metadata-codepage=<codepage>``
|
|
|
|
Codepage for various input metadata (default: ``utf-8``). This affects how
|
|
|
|
file tags, chapter titles, etc. are interpreted. You can for example set
|
|
|
|
this to ``auto`` to enable autodetection of the codepage. (This is not the
|
|
|
|
default because non-UTF-8 codepages are an obscure fringe use-case.)
|
|
|
|
|
|
|
|
See ``--sub-codepage`` option on how codepages are specified and further
|
|
|
|
details regarding autodetection and codepage conversion. (The underlying
|
|
|
|
code is the same.)
|
|
|
|
|
|
|
|
Conversion is not applied to metadata that is updated at runtime.
|