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 FILTERS
|
|
|
|
|
=============
|
|
|
|
|
|
2018-01-31 03:13:00 +00:00
|
|
|
Video filters allow you to modify the video stream and its properties. All of
|
|
|
|
|
the information described in this section applies to audio filters as well
|
|
|
|
|
(generally using the prefix ``--af`` instead of ``--vf``).
|
|
|
|
|
|
|
|
|
|
The exact syntax is:
|
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
|
|
|
``--vf=<filter1[=parameter1:parameter2:...],filter2,...>``
|
2017-03-25 16:07:40 +00:00
|
|
|
Setup a chain of video filters. This consists on the filter name, and an
|
|
|
|
|
option list of parameters after ``=``. The parameters are separated by
|
|
|
|
|
``:`` (not ``,``, as that starts a new filter entry).
|
|
|
|
|
|
|
|
|
|
Before the filter name, a label can be specified with ``@name:``, where
|
|
|
|
|
name is an arbitrary user-given name, which identifies the filter. This
|
|
|
|
|
is only needed if you want to toggle the filter at runtime.
|
|
|
|
|
|
2018-07-23 19:57:11 +00:00
|
|
|
A ``!`` before the filter name means the filter is disabled by default. It
|
2017-03-25 16:07:40 +00:00
|
|
|
will be skipped on filter creation. This is also useful for runtime filter
|
|
|
|
|
toggling.
|
|
|
|
|
|
|
|
|
|
See the ``vf`` command (and ``toggle`` sub-command) for further explanations
|
|
|
|
|
and examples.
|
|
|
|
|
|
|
|
|
|
The general filter entry syntax is:
|
|
|
|
|
|
|
|
|
|
``["@"<label-name>":"] ["!"] <filter-name> [ "=" <filter-parameter-list> ]``
|
|
|
|
|
|
2017-03-26 11:13:34 +00:00
|
|
|
or for the special "toggle" syntax (see ``vf`` command):
|
|
|
|
|
|
|
|
|
|
``"@"<label-name>``
|
|
|
|
|
|
2017-03-25 16:07:40 +00:00
|
|
|
and the ``filter-parameter-list``:
|
|
|
|
|
|
|
|
|
|
``<filter-parameter> | <filter-parameter> "," <filter-parameter-list>``
|
|
|
|
|
|
|
|
|
|
and ``filter-parameter``:
|
|
|
|
|
|
|
|
|
|
``( <param-name> "=" <param-value> ) | <param-value>``
|
|
|
|
|
|
|
|
|
|
``param-value`` can further be quoted in ``[`` / ``]`` in case the value
|
|
|
|
|
contains characters like ``,`` or ``=``. This is used in particular with
|
|
|
|
|
the ``lavfi`` filter, which uses a very similar syntax as mpv (MPlayer
|
|
|
|
|
historically) to specify filters and their 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
|
|
|
|
2023-08-14 15:41:11 +00:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
|
|
``--vf`` can only take a single track as input, even if the filter supports
|
|
|
|
|
dynamic input. Filters that require multiple inputs can't be used.
|
|
|
|
|
Use ``--lavfi-complex`` for such a use case. This also applies for ``--af``.
|
|
|
|
|
|
2018-01-31 03:13:00 +00:00
|
|
|
Filters can be manipulated at run time. You can use ``@`` labels as described
|
|
|
|
|
above in combination with the ``vf`` command (see `COMMAND INTERFACE`_) to get
|
|
|
|
|
more control over this. Initially disabled filters with ``!`` are useful for
|
|
|
|
|
this as well.
|
|
|
|
|
|
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
|
|
|
|
2017-05-31 15:42:03 +00:00
|
|
|
To get a full list of available video filters, see ``--vf=help`` and
|
2021-08-12 23:35:58 +00:00
|
|
|
https://ffmpeg.org/ffmpeg-filters.html .
|
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-11 21:48:47 +00:00
|
|
|
Also, keep in mind that most actual filters are available via the ``lavfi``
|
|
|
|
|
wrapper, which gives you access to most of libavfilter's filters. This
|
|
|
|
|
includes all filters that have been ported from MPlayer to libavfilter.
|
|
|
|
|
|
2017-05-31 15:42:03 +00:00
|
|
|
Most builtin filters are deprecated in some ways, unless they're only available
|
2017-04-02 15:59:45 +00:00
|
|
|
in mpv (such as filters which deal with mpv specifics, or which are
|
|
|
|
|
implemented in mpv only).
|
|
|
|
|
|
2017-04-02 16:47:36 +00:00
|
|
|
If a filter is not builtin, the ``lavfi-bridge`` will be automatically
|
2017-04-03 16:04:18 +00:00
|
|
|
tried. This bridge does not support help output, and does not verify
|
|
|
|
|
parameters before the filter is actually used. Although the mpv syntax
|
|
|
|
|
is rather similar to libavfilter's, it's not the same. (Which means not
|
|
|
|
|
everything accepted by vf_lavfi's ``graph`` option will be accepted by
|
|
|
|
|
``--vf``.)
|
2017-04-02 16:47:36 +00:00
|
|
|
|
2017-05-31 15:42:03 +00:00
|
|
|
You can also prefix the filter name with ``lavfi-`` to force the wrapper.
|
|
|
|
|
This is helpful if the filter name collides with a deprecated mpv builtin
|
|
|
|
|
filter. For example ``--vf=lavfi-scale=args`` would use libavfilter's
|
|
|
|
|
``scale`` filter over mpv's deprecated builtin one.
|
|
|
|
|
|
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 filters are managed in lists. There are a few commands to manage the
|
|
|
|
|
filter list.
|
|
|
|
|
|
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
|
|
|
``--vf-append=filter``
|
|
|
|
|
Appends the filter given as arguments to the filter list.
|
|
|
|
|
|
2018-01-31 03:13:00 +00:00
|
|
|
``--vf-add=filter``
|
|
|
|
|
Appends the filter given as arguments to the filter list. (Passing multiple
|
|
|
|
|
filters is currently still possible, but deprecated.)
|
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-01-31 03:13:00 +00:00
|
|
|
``--vf-pre=filter``
|
|
|
|
|
Prepends the filters given as arguments to the filter list. (Passing
|
|
|
|
|
multiple filters is currently still possible, but deprecated.)
|
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-12-18 05:31:39 +00:00
|
|
|
``--vf-remove=filter``
|
|
|
|
|
Deletes the filter from the list. The filter can be either given the way it
|
|
|
|
|
was added (filter name and its full argument list), or by label (prefixed
|
|
|
|
|
with ``@``). Matching of filters works as follows: if either of the compared
|
|
|
|
|
filters has a label set, only the labels are compared. If none of the
|
|
|
|
|
filters have a label, the filter name, arguments, and argument order are
|
2019-12-18 05:57:24 +00:00
|
|
|
compared. (Passing multiple filters is currently still possible, but
|
|
|
|
|
deprecated.)
|
2019-12-18 05:31:39 +00:00
|
|
|
|
|
|
|
|
``-vf-toggle=filter``
|
|
|
|
|
Add the given filter to the list if it was not present yet, or remove it
|
|
|
|
|
from the list if it was present. Matching of filters works as described in
|
|
|
|
|
``--vf-remove``.
|
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``--vf-clr``
|
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
|
|
|
Completely empties the filter list.
|
|
|
|
|
|
|
|
|
|
With filters that support it, you can access parameters by their name.
|
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``--vf=<filter>=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
|
|
|
Prints the parameter names and parameter value ranges for a particular
|
|
|
|
|
filter.
|
|
|
|
|
|
2017-05-31 15:42:03 +00:00
|
|
|
Available mpv-only filters are:
|
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-04-27 15:51:06 +00:00
|
|
|
``format=fmt=<value>:colormatrix=<value>:...``
|
filters: extend vf_format so that it can convert color parameters
Form some reason (and because of my fault), vf_format converts image
formats, but nothing else. For example, setting the "colormatrix"
sub-parameter would not convert it to the new value, but instead
overwrite the metadata (basically "reinterpreting" the image data
without changing it).
Make the historical mistake worse, and go all the way and extend it such
that it can perform a conversion. For compatibility reasons, this needs
to be requested explicitly. (Maybe this would deserve a separate filter
to begin with, but things are messed up anyway. Feel free to suggest an
elegant and simple solution.)
This demonstrates how zimg can properly perform some conversions which
swscale cannot (see examples added to vf.rst).
Stupidly this requires 2 code paths, one for conversion, and one for
overriding the parameters.
Due to the filter bullshit (what was I thinking), this requires quite
some acrobatics that would not be necessary without these abstractions.
On the other hand, it'd definitely be more of a mess without it. Oh
whatever.
2019-10-20 23:29:48 +00:00
|
|
|
Applies video parameter overrides, with optional conversion. By default,
|
2019-10-21 14:54:13 +00:00
|
|
|
this overrides the video's parameters without conversion (except for the
|
|
|
|
|
``fmt`` parameter), but can be made to perform an appropriate conversion
|
|
|
|
|
with ``convert=yes`` for parameters for which conversion is supported.
|
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
|
|
|
``<fmt>``
|
filters: extend vf_format so that it can convert color parameters
Form some reason (and because of my fault), vf_format converts image
formats, but nothing else. For example, setting the "colormatrix"
sub-parameter would not convert it to the new value, but instead
overwrite the metadata (basically "reinterpreting" the image data
without changing it).
Make the historical mistake worse, and go all the way and extend it such
that it can perform a conversion. For compatibility reasons, this needs
to be requested explicitly. (Maybe this would deserve a separate filter
to begin with, but things are messed up anyway. Feel free to suggest an
elegant and simple solution.)
This demonstrates how zimg can properly perform some conversions which
swscale cannot (see examples added to vf.rst).
Stupidly this requires 2 code paths, one for conversion, and one for
overriding the parameters.
Due to the filter bullshit (what was I thinking), this requires quite
some acrobatics that would not be necessary without these abstractions.
On the other hand, it'd definitely be more of a mess without it. Oh
whatever.
2019-10-20 23:29:48 +00:00
|
|
|
Image format name, e.g. rgb15, bgr24, 420p, etc. (default: don't change).
|
|
|
|
|
|
|
|
|
|
This filter always performs conversion to the given format.
|
|
|
|
|
|
2019-10-21 14:54:13 +00:00
|
|
|
.. note::
|
|
|
|
|
|
2019-10-24 10:55:49 +00:00
|
|
|
For a list of available formats, use ``--vf=format=fmt=help``.
|
2019-10-21 14:54:13 +00:00
|
|
|
|
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
|
|
|
.. note::
|
|
|
|
|
|
|
|
|
|
Conversion between hardware formats is supported in some cases.
|
|
|
|
|
eg: ``cuda`` to ``vulkan``, or ``vaapi`` to ``vulkan``.
|
|
|
|
|
|
filters: extend vf_format so that it can convert color parameters
Form some reason (and because of my fault), vf_format converts image
formats, but nothing else. For example, setting the "colormatrix"
sub-parameter would not convert it to the new value, but instead
overwrite the metadata (basically "reinterpreting" the image data
without changing it).
Make the historical mistake worse, and go all the way and extend it such
that it can perform a conversion. For compatibility reasons, this needs
to be requested explicitly. (Maybe this would deserve a separate filter
to begin with, but things are messed up anyway. Feel free to suggest an
elegant and simple solution.)
This demonstrates how zimg can properly perform some conversions which
swscale cannot (see examples added to vf.rst).
Stupidly this requires 2 code paths, one for conversion, and one for
overriding the parameters.
Due to the filter bullshit (what was I thinking), this requires quite
some acrobatics that would not be necessary without these abstractions.
On the other hand, it'd definitely be more of a mess without it. Oh
whatever.
2019-10-20 23:29:48 +00:00
|
|
|
``<convert=yes|no>``
|
|
|
|
|
Force conversion of color parameters (default: no).
|
|
|
|
|
|
|
|
|
|
If this is disabled (the default), the only conversion that is possibly
|
|
|
|
|
performed is format conversion if ``<fmt>`` is set. All other parameters
|
|
|
|
|
(like ``<colormatrix>``) are forced without conversion. This mode is
|
|
|
|
|
typically useful when files have been incorrectly tagged.
|
|
|
|
|
|
|
|
|
|
If this is enabled, libswscale or zimg is used if any of the parameters
|
|
|
|
|
mismatch. zimg is used of the input/output image formats are supported
|
|
|
|
|
by mpv's zimg wrapper, and if ``--sws-allow-zimg=yes`` is used. Both
|
|
|
|
|
libraries may not support all kinds of conversions. This typically
|
|
|
|
|
results in silent incorrect conversion. zimg has in many cases a better
|
|
|
|
|
chance of performing the conversion correctly.
|
|
|
|
|
|
|
|
|
|
In both cases, the color parameters are set on the output stage of the
|
|
|
|
|
image format conversion (if ``fmt`` was set). The difference is that
|
|
|
|
|
with ``convert=no``, the color parameters are not passed on to the
|
|
|
|
|
converter.
|
|
|
|
|
|
|
|
|
|
If input and output video parameters are the same, conversion is always
|
|
|
|
|
skipped.
|
|
|
|
|
|
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
|
|
|
When converting between hardware formats, this parameter has no effect,
|
|
|
|
|
and the only conversion that is done is the format conversion.
|
|
|
|
|
|
filters: extend vf_format so that it can convert color parameters
Form some reason (and because of my fault), vf_format converts image
formats, but nothing else. For example, setting the "colormatrix"
sub-parameter would not convert it to the new value, but instead
overwrite the metadata (basically "reinterpreting" the image data
without changing it).
Make the historical mistake worse, and go all the way and extend it such
that it can perform a conversion. For compatibility reasons, this needs
to be requested explicitly. (Maybe this would deserve a separate filter
to begin with, but things are messed up anyway. Feel free to suggest an
elegant and simple solution.)
This demonstrates how zimg can properly perform some conversions which
swscale cannot (see examples added to vf.rst).
Stupidly this requires 2 code paths, one for conversion, and one for
overriding the parameters.
Due to the filter bullshit (what was I thinking), this requires quite
some acrobatics that would not be necessary without these abstractions.
On the other hand, it'd definitely be more of a mess without it. Oh
whatever.
2019-10-20 23:29:48 +00:00
|
|
|
.. admonition:: Examples
|
|
|
|
|
|
|
|
|
|
``mpv test.mkv --vf=format:colormatrix=ycgco``
|
|
|
|
|
Results in incorrect colors (if test.mkv was tagged correctly).
|
|
|
|
|
|
|
|
|
|
``mpv test.mkv --vf=format:colormatrix=ycgco:convert=yes --sws-allow-zimg``
|
|
|
|
|
Results in true conversion to ``ycgco``, assuming the renderer
|
|
|
|
|
supports it (``--vo=gpu`` normally does). You can add ``--vo=xv``
|
|
|
|
|
to force a VO which definitely does not support it, which should
|
|
|
|
|
show incorrect colors as confirmation.
|
|
|
|
|
|
|
|
|
|
Using ``--sws-allow-zimg=no`` (or disabling zimg at build time)
|
|
|
|
|
will use libswscale, which cannot perform this conversion as
|
|
|
|
|
of this writing.
|
video: rewrite filtering glue code
Get rid of the old vf.c code. Replace it with a generic filtering
framework, which can potentially handle more than just --vf. At least
reimplementing --af with this code is planned.
This changes some --vf semantics (including runtime behavior and the
"vf" command). The most important ones are listed in interface-changes.
vf_convert.c is renamed to f_swscale.c. It is now an internal filter
that can not be inserted by the user manually.
f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed
once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is
conceptually easy, but a big mess due to the data flow changes).
The existing filters are all changed heavily. The data flow of the new
filter framework is different. Especially EOF handling changes - EOF is
now a "frame" rather than a state, and must be passed through exactly
once.
Another major thing is that all filters must support dynamic format
changes. The filter reconfig() function goes away. (This sounds complex,
but since all filters need to handle EOF draining anyway, they can use
the same code, and it removes the mess with reconfig() having to predict
the output format, which completely breaks with libavfilter anyway.)
In addition, there is no automatic format negotiation or conversion.
libavfilter's primitive and insufficient API simply doesn't allow us to
do this in a reasonable way. Instead, filters can use f_autoconvert as
sub-filter, and tell it which formats they support. This filter will in
turn add actual conversion filters, such as f_swscale, to perform
necessary format changes.
vf_vapoursynth.c uses the same basic principle of operation as before,
but with worryingly different details in data flow. Still appears to
work.
The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are
heavily changed. Fortunately, they all used refqueue.c, which is for
sharing the data flow logic (especially for managing future/past
surfaces and such). It turns out it can be used to factor out most of
the data flow. Some of these filters accepted software input. Instead of
having ad-hoc upload code in each filter, surface upload is now
delegated to f_autoconvert, which can use f_hwupload to perform this.
Exporting VO capabilities is still a big mess (mp_stream_info stuff).
The D3D11 code drops the redundant image formats, and all code uses the
hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a
big mess for now.
f_async_queue is unused.
2018-01-16 10:53:44 +00:00
|
|
|
|
2015-03-30 21:52:28 +00:00
|
|
|
``<colormatrix>``
|
|
|
|
|
Controls the YUV to RGB color space conversion when playing video. There
|
|
|
|
|
are various standards. Normally, BT.601 should be used for SD video, and
|
|
|
|
|
BT.709 for HD video. (This is done by default.) Using incorrect color space
|
|
|
|
|
results in slightly under or over saturated and shifted colors.
|
|
|
|
|
|
|
|
|
|
These options are not always supported. Different video outputs provide
|
2018-01-09 12:20:37 +00:00
|
|
|
varying degrees of support. The ``gpu`` and ``vdpau`` video output
|
2015-03-30 21:52:28 +00:00
|
|
|
drivers usually offer full support. The ``xv`` output can set the color
|
|
|
|
|
space if the system video driver supports it, but not input and output
|
|
|
|
|
levels. The ``scale`` video filter can configure color space and input
|
|
|
|
|
levels, but only if the output format is RGB (if the video output driver
|
|
|
|
|
supports RGB output, you can force this with ``-vf scale,format=rgba``).
|
|
|
|
|
|
|
|
|
|
If this option is set to ``auto`` (which is the default), the video's
|
|
|
|
|
color space flag will be used. If that flag is unset, the color space
|
|
|
|
|
will be selected automatically. This is done using a simple heuristic that
|
|
|
|
|
attempts to distinguish SD and HD video. If the video is larger than
|
|
|
|
|
1279x576 pixels, BT.709 (HD) will be used; otherwise BT.601 (SD) is
|
|
|
|
|
selected.
|
|
|
|
|
|
|
|
|
|
Available color spaces are:
|
|
|
|
|
|
|
|
|
|
:auto: automatic selection (default)
|
2024-02-10 23:51:58 +00:00
|
|
|
:bt.601: ITU-R Rec. BT.601 (SD)
|
|
|
|
|
:bt.709: ITU-R Rec. BT.709 (HD)
|
|
|
|
|
:bt.2020-ncl: ITU-R Rec. BT.2020 (non-constant luminance)
|
|
|
|
|
:bt.2020-cl: ITU-R Rec. BT.2020 (constant luminance)
|
|
|
|
|
:bt.2100-pq: ITU-R Rec. BT.2100 ICtCp PQ variant
|
|
|
|
|
:bt.2100-hlg: ITU-R Rec. BT.2100 ICtCp HLG variant
|
|
|
|
|
:dolbyvision: Dolby Vision
|
2015-03-30 21:52:28 +00:00
|
|
|
:smpte-240m: SMPTE-240M
|
|
|
|
|
|
|
|
|
|
``<colorlevels>``
|
|
|
|
|
YUV color levels used with YUV to RGB conversion. This option is only
|
|
|
|
|
necessary when playing broken files which do not follow standard color
|
|
|
|
|
levels or which are flagged wrong. If the video does not specify its
|
|
|
|
|
color range, it is assumed to be limited range.
|
|
|
|
|
|
|
|
|
|
The same limitations as with ``<colormatrix>`` apply.
|
|
|
|
|
|
|
|
|
|
Available color ranges are:
|
|
|
|
|
|
|
|
|
|
:auto: automatic selection (normally limited range) (default)
|
|
|
|
|
:limited: limited range (16-235 for luma, 16-240 for chroma)
|
|
|
|
|
:full: full range (0-255 for both luma and chroma)
|
|
|
|
|
|
|
|
|
|
``<primaries>``
|
|
|
|
|
RGB primaries the source file was encoded with. Normally this should be set
|
|
|
|
|
in the file header, but when playing broken or mistagged files this can be
|
2015-03-31 04:52:38 +00:00
|
|
|
used to override the setting.
|
2015-03-30 21:52:28 +00:00
|
|
|
|
|
|
|
|
This option only affects video output drivers that perform color
|
2018-01-09 12:20:37 +00:00
|
|
|
management, for example ``gpu`` with the ``target-prim`` or
|
2015-03-31 04:52:38 +00:00
|
|
|
``icc-profile`` suboptions set.
|
2015-03-30 21:52:28 +00:00
|
|
|
|
|
|
|
|
If this option is set to ``auto`` (which is the default), the video's
|
|
|
|
|
primaries flag will be used. If that flag is unset, the color space will
|
|
|
|
|
be selected automatically, using the following heuristics: If the
|
|
|
|
|
``<colormatrix>`` is set or determined as BT.2020 or BT.709, the
|
|
|
|
|
corresponding primaries are used. Otherwise, if the video height is
|
|
|
|
|
exactly 576 (PAL), BT.601-625 is used. If it's exactly 480 or 486 (NTSC),
|
|
|
|
|
BT.601-525 is used. If the video resolution is anything else, BT.709 is
|
|
|
|
|
used.
|
|
|
|
|
|
|
|
|
|
Available primaries are:
|
|
|
|
|
|
|
|
|
|
:auto: automatic selection (default)
|
|
|
|
|
:bt.601-525: ITU-R BT.601 (SD) 525-line systems (NTSC, SMPTE-C)
|
|
|
|
|
:bt.601-625: ITU-R BT.601 (SD) 625-line systems (PAL, SECAM)
|
|
|
|
|
:bt.709: ITU-R BT.709 (HD) (same primaries as sRGB)
|
|
|
|
|
:bt.2020: ITU-R BT.2020 (UHD)
|
2015-03-30 12:54:52 +00:00
|
|
|
:apple: Apple RGB
|
|
|
|
|
:adobe: Adobe RGB (1998)
|
|
|
|
|
:prophoto: ProPhoto RGB (ROMM)
|
|
|
|
|
:cie1931: CIE 1931 RGB
|
2016-06-26 18:00:22 +00:00
|
|
|
:dci-p3: DCI-P3 (Digital Cinema)
|
2016-06-26 17:57:29 +00:00
|
|
|
:v-gamut: Panasonic V-Gamut primaries
|
2015-03-30 21:52:28 +00:00
|
|
|
|
2016-02-10 23:14:02 +00:00
|
|
|
``<gamma>``
|
|
|
|
|
Gamma function the source file was encoded with. Normally this should be set
|
|
|
|
|
in the file header, but when playing broken or mistagged files this can be
|
|
|
|
|
used to override the setting.
|
|
|
|
|
|
|
|
|
|
This option only affects video output drivers that perform color management.
|
|
|
|
|
|
|
|
|
|
If this option is set to ``auto`` (which is the default), the gamma will
|
|
|
|
|
be set to BT.1886 for YCbCr content, sRGB for RGB content and Linear for
|
|
|
|
|
XYZ content.
|
|
|
|
|
|
|
|
|
|
Available gamma functions are:
|
|
|
|
|
|
|
|
|
|
:auto: automatic selection (default)
|
2016-05-06 16:00:39 +00:00
|
|
|
:bt.1886: ITU-R BT.1886 (EOTF corresponding to BT.601/BT.709/BT.2020)
|
2016-02-10 23:14:02 +00:00
|
|
|
:srgb: IEC 61966-2-4 (sRGB)
|
|
|
|
|
:linear: Linear light
|
|
|
|
|
:gamma1.8: Pure power curve (gamma 1.8)
|
2018-08-22 12:39:40 +00:00
|
|
|
:gamma2.0: Pure power curve (gamma 2.0)
|
2016-02-10 23:14:02 +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-02-10 23:14:02 +00:00
|
|
|
:gamma2.8: Pure power curve (gamma 2.8)
|
|
|
|
|
:prophoto: ProPhoto RGB (ROMM) curve
|
2017-06-13 15:09:02 +00:00
|
|
|
:pq: ITU-R BT.2100 PQ (Perceptual quantizer) curve
|
|
|
|
|
:hlg: ITU-R BT.2100 HLG (Hybrid Log-gamma) curve
|
2016-06-26 17:28:06 +00:00
|
|
|
:v-log: Panasonic V-Log transfer curve
|
2017-06-10 00:05:28 +00:00
|
|
|
:s-log1: Sony S-Log1 transfer curve
|
2017-06-10 00:51:32 +00:00
|
|
|
:s-log2: Sony S-Log2 transfer curve
|
2015-03-31 05:47:13 +00:00
|
|
|
|
2017-06-10 12:01:25 +00:00
|
|
|
``<sig-peak>``
|
|
|
|
|
Reference peak illumination for the video file, relative to the
|
|
|
|
|
signal's reference white level. This is mostly interesting for HDR, but
|
|
|
|
|
it can also be used tone map SDR content to simulate a different
|
|
|
|
|
exposure. Normally inferred from tags such as MaxCLL or mastering
|
|
|
|
|
metadata.
|
|
|
|
|
|
|
|
|
|
The default of 0.0 will default to the source's nominal peak luminance.
|
2016-05-30 17:56:58 +00:00
|
|
|
|
2017-06-14 18:06:56 +00:00
|
|
|
``<light>``
|
|
|
|
|
Light type of the scene. This is mostly correctly inferred based on the
|
|
|
|
|
gamma function, but it can be useful to override this when viewing raw
|
|
|
|
|
camera footage (e.g. V-Log), which is normally scene-referred instead
|
|
|
|
|
of display-referred.
|
|
|
|
|
|
|
|
|
|
Available light types are:
|
|
|
|
|
|
|
|
|
|
:auto: Automatic selection (default)
|
|
|
|
|
:display: Display-referred light (most content)
|
|
|
|
|
:hlg: Scene-referred using the HLG OOTF (e.g. HLG content)
|
|
|
|
|
:709-1886: Scene-referred using the BT709+BT1886 interaction
|
|
|
|
|
:gamma1.2: Scene-referred using a pure power OOTF (gamma=1.2)
|
|
|
|
|
|
2022-01-07 05:41:55 +00:00
|
|
|
``<dolbyvision=yes|no>``
|
|
|
|
|
Whether or not to include Dolby Vision metadata (default: yes). If
|
|
|
|
|
disabled, any Dolby Vision metadata will be stripped from frames.
|
|
|
|
|
|
2024-02-10 23:50:02 +00:00
|
|
|
``<hdr10plus=yes|no>``
|
|
|
|
|
Whether or not to include HDR10+ metadata (default: yes). If
|
|
|
|
|
disabled, any HDR10+ metadata will be stripped from frames.
|
|
|
|
|
|
2022-04-01 20:26:23 +00:00
|
|
|
``<film-grain=yes|no>``
|
|
|
|
|
Whether or not to include film grain metadata (default: yes). If
|
|
|
|
|
disabled, any film grain metadata will be stripped from frames.
|
|
|
|
|
|
2015-04-02 21:57:56 +00:00
|
|
|
``<stereo-in>``
|
2019-09-14 03:25:40 +00:00
|
|
|
Set the stereo mode the video is assumed to be encoded in. Use
|
2021-01-18 23:20:26 +00:00
|
|
|
``--vf=format:stereo-in=help`` to list all available modes. Check with
|
2019-09-14 03:25:40 +00:00
|
|
|
the ``stereo3d`` filter documentation to see what the names mean.
|
2015-04-02 21:57:56 +00:00
|
|
|
|
|
|
|
|
``<stereo-out>``
|
|
|
|
|
Set the stereo mode the video should be displayed as. Takes the
|
2019-09-14 03:25:40 +00:00
|
|
|
same values as the ``stereo-in`` option.
|
2015-04-02 21:57:56 +00:00
|
|
|
|
2015-04-02 21:59:00 +00:00
|
|
|
``<rotate>``
|
|
|
|
|
Set the rotation the video is assumed to be encoded with in degrees.
|
|
|
|
|
The special value ``-1`` uses the input format.
|
|
|
|
|
|
2020-02-09 13:14:14 +00:00
|
|
|
``<w>``, ``<h>``
|
|
|
|
|
If not 0, perform conversion to the given size. Ignored if
|
|
|
|
|
``convert=yes`` is not set.
|
|
|
|
|
|
2015-04-02 22:02:40 +00:00
|
|
|
``<dw>``, ``<dh>``
|
|
|
|
|
Set the display size. Note that setting the display size such that
|
|
|
|
|
the video is scaled in both directions instead of just changing the
|
|
|
|
|
aspect ratio is an implementation detail, and might change later.
|
|
|
|
|
|
2015-04-02 22:06:29 +00:00
|
|
|
``<dar>``
|
|
|
|
|
Set the display aspect ratio of the video frame. This is a float,
|
|
|
|
|
but values such as ``[16:9]`` can be passed too (``[...]`` for quoting
|
|
|
|
|
to prevent the option parser from interpreting the ``:`` character).
|
|
|
|
|
|
2020-04-12 19:55:35 +00:00
|
|
|
``<force-scaler=auto|zimg|sws>``
|
|
|
|
|
Force a specific scaler backend, if applicable. This is a debug option
|
|
|
|
|
and could go away any time.
|
|
|
|
|
|
2020-04-24 12:41:50 +00:00
|
|
|
``<alpha=auto|straight|premul>``
|
|
|
|
|
Set the kind of alpha the video uses. Undefined effect if the image
|
|
|
|
|
format has no alpha channel (could be ignored or cause an error,
|
|
|
|
|
depending on how mpv internals evolve). Setting this may or may not
|
|
|
|
|
cause downstream image processing to treat alpha differently, depending
|
|
|
|
|
on support. With ``convert`` and zimg used, this will convert the alpha.
|
|
|
|
|
libswscale and other FFmpeg components completely ignore this.
|
|
|
|
|
|
2013-12-03 21:19:27 +00:00
|
|
|
``lavfi=graph[:sws-flags[:o=opts]]``
|
2013-07-08 16:02:14 +00:00
|
|
|
Filter video using FFmpeg's libavfilter.
|
|
|
|
|
|
|
|
|
|
``<graph>``
|
2013-03-10 23:16:34 +00:00
|
|
|
The libavfilter graph string. The filter must have a single video input
|
|
|
|
|
pad and a single video output pad.
|
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
See `<https://ffmpeg.org/ffmpeg-filters.html>`_ for syntax and available
|
2013-03-10 23:16:34 +00:00
|
|
|
filters.
|
|
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
If you want to use the full filter syntax with this option, you have
|
|
|
|
|
to quote the filter graph in order to prevent mpv's syntax and the
|
2017-12-05 01:55:11 +00:00
|
|
|
filter graph syntax from clashing. To prevent a quoting and escaping
|
|
|
|
|
mess, consider using ``--lavfi-complex`` if you know which video
|
|
|
|
|
track you want to use from the input file. (There is only one video
|
|
|
|
|
track for nearly all video files anyway.)
|
2013-03-10 23:16:34 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
2013-03-10 23:16:34 +00:00
|
|
|
|
2017-12-05 01:55:11 +00:00
|
|
|
``--vf=lavfi=[gradfun=20:30,vflip]``
|
2013-07-08 16:02:14 +00:00
|
|
|
``gradfun`` filter with nonsense parameters, followed by a
|
|
|
|
|
``vflip`` filter. (This demonstrates how libavfilter takes a
|
|
|
|
|
graph and not just a single filter.) The filter graph string is
|
|
|
|
|
quoted with ``[`` and ``]``. This requires no additional quoting
|
|
|
|
|
or escaping with some shells (like bash), while others (like
|
|
|
|
|
zsh) require additional ``"`` quotes around the option string.
|
2013-04-26 14:52:54 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``'--vf=lavfi="gradfun=20:30,vflip"'``
|
|
|
|
|
Same as before, but uses quoting that should be safe with all
|
|
|
|
|
shells. The outer ``'`` quotes make sure that the shell does not
|
|
|
|
|
remove the ``"`` quotes needed by mpv.
|
2013-03-10 23:16:34 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``'--vf=lavfi=graph="gradfun=radius=30:strength=20,vflip"'``
|
|
|
|
|
Same as before, but uses named parameters for everything.
|
2013-03-10 23:16:34 +00:00
|
|
|
|
2013-12-03 21:19:27 +00:00
|
|
|
``<sws-flags>``
|
2013-03-10 23:16:34 +00:00
|
|
|
If libavfilter inserts filters for pixel format conversion, this
|
|
|
|
|
option gives the flags which should be passed to libswscale. This
|
|
|
|
|
option is numeric and takes a bit-wise combination of ``SWS_`` flags.
|
|
|
|
|
|
2021-08-12 23:35:58 +00:00
|
|
|
See ``https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libswscale/swscale.h``.
|
2013-03-10 23:16:34 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``<o>``
|
|
|
|
|
Set AVFilterGraph options. These should be documented by FFmpeg.
|
2013-05-25 13:53:55 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Example
|
2013-05-25 13:53:55 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``'--vf=lavfi=yadif:o="threads=2,thread_type=slice"'``
|
|
|
|
|
forces a specific threading configuration.
|
2013-05-25 13:53:55 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``sub=[=bottom-margin:top-margin]``
|
|
|
|
|
Moves subtitle rendering to an arbitrary point in the filter chain, or force
|
|
|
|
|
subtitle rendering in the video filter as opposed to using video output OSD
|
|
|
|
|
support.
|
2012-12-12 22:35:01 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``<bottom-margin>``
|
2012-12-12 22:35:01 +00:00
|
|
|
Adds a black band at the bottom of the frame. The SSA/ASS renderer can
|
2015-02-16 19:04:15 +00:00
|
|
|
place subtitles there (with ``--sub-use-margins``).
|
2013-07-08 16:02:14 +00:00
|
|
|
``<top-margin>``
|
2015-02-16 19:04:15 +00:00
|
|
|
Black band on the top for toptitles (with ``--sub-use-margins``).
|
2012-12-12 22:35:01 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
.. admonition:: Examples
|
2012-12-12 22:35:01 +00:00
|
|
|
|
2013-07-08 16:02:14 +00:00
|
|
|
``--vf=sub,eq``
|
|
|
|
|
Moves sub rendering before the eq filter. This will put both
|
|
|
|
|
subtitle colors and video under the influence of the video equalizer
|
|
|
|
|
settings.
|
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-05-14 18:41:31 +00:00
|
|
|
``vapoursynth=file:buffered-frames:concurrent-frames``
|
2014-04-12 15:51:19 +00:00
|
|
|
Loads a VapourSynth filter script. This is intended for streamed
|
|
|
|
|
processing: mpv actually provides a source filter, instead of using a
|
|
|
|
|
native VapourSynth video source. The mpv source will answer frame
|
|
|
|
|
requests only within a small window of frames (the size of this window
|
2014-05-14 18:41:31 +00:00
|
|
|
is controlled with the ``buffered-frames`` parameter), and requests outside
|
|
|
|
|
of that will return errors. As such, you can't use the full power of
|
2014-04-12 15:51:19 +00:00
|
|
|
VapourSynth, but you can use certain filters.
|
|
|
|
|
|
2019-10-24 10:55:26 +00:00
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
Do not use this filter, unless you have expert knowledge in VapourSynth,
|
|
|
|
|
and know how to fix bugs in the mpv VapourSynth wrapper code.
|
|
|
|
|
|
2019-10-23 20:27:07 +00:00
|
|
|
If you just want to play video generated by VapourSynth (i.e. using
|
2014-04-12 15:51:19 +00:00
|
|
|
a native VapourSynth video source), it's better to use ``vspipe`` and a
|
2019-10-23 20:27:07 +00:00
|
|
|
pipe or FIFO to feed the video to mpv. The same applies if the filter script
|
2014-05-14 18:41:31 +00:00
|
|
|
requires random frame access (see ``buffered-frames`` parameter).
|
2014-04-12 15:51:19 +00:00
|
|
|
|
|
|
|
|
``file``
|
|
|
|
|
Filename of the script source. Currently, this is always a python
|
2019-10-23 20:27:07 +00:00
|
|
|
script (``.vpy`` in VapourSynth convention).
|
|
|
|
|
|
|
|
|
|
The variable ``video_in`` is set to the mpv video source, and it is
|
|
|
|
|
expected that the script reads video from it. (Otherwise, mpv will
|
|
|
|
|
decode no video, and the video packet queue will overflow, eventually
|
|
|
|
|
leading to only audio playing, or worse.)
|
|
|
|
|
|
|
|
|
|
The filter graph created by the script is also expected to pass through
|
|
|
|
|
timestamps using the ``_DurationNum`` and ``_DurationDen`` frame
|
|
|
|
|
properties.
|
|
|
|
|
|
|
|
|
|
See the end of the option list for a full list of script variables
|
|
|
|
|
defined by mpv.
|
2014-04-12 15:51:19 +00:00
|
|
|
|
|
|
|
|
.. admonition:: Example:
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
import vapoursynth as vs
|
2022-09-26 22:36:25 +00:00
|
|
|
from vapoursynth import core
|
2014-04-12 15:51:19 +00:00
|
|
|
core.std.AddBorders(video_in, 10, 10, 20, 20).set_output()
|
|
|
|
|
|
2014-04-13 10:27:26 +00:00
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
The script will be reloaded on every seek. This is done to reset
|
2014-04-14 16:03:13 +00:00
|
|
|
the filter properly on discontinuities.
|
2014-04-13 10:27:26 +00:00
|
|
|
|
2014-05-14 18:41:31 +00:00
|
|
|
``buffered-frames``
|
2014-04-12 15:51:19 +00:00
|
|
|
Maximum number of decoded video frames that should be buffered before
|
2014-05-14 18:41:31 +00:00
|
|
|
the filter (default: 4). This specifies the maximum number of frames
|
2019-10-23 20:27:07 +00:00
|
|
|
the script can request in backward direction.
|
|
|
|
|
|
2015-12-19 08:26:27 +00:00
|
|
|
E.g. if ``buffered-frames=5``, and the script just requested frame 15,
|
|
|
|
|
it can still request frame 10, but frame 9 is not available anymore.
|
|
|
|
|
If it requests frame 30, mpv will decode 15 more frames, and keep only
|
|
|
|
|
frames 25-30.
|
2014-04-12 15:51:19 +00:00
|
|
|
|
2019-10-23 20:27:07 +00:00
|
|
|
The only reason why this buffer exists is to serve the random access
|
|
|
|
|
requests the VapourSynth filter can make.
|
|
|
|
|
|
|
|
|
|
The VapourSynth API has a ``getFrameAsync`` function, which takes an
|
|
|
|
|
absolute frame number. Source filters must respond to all requests. For
|
|
|
|
|
example, a source filter can request frame 2432, and then frame 3.
|
|
|
|
|
Source filters typically implement this by pre-indexing the entire
|
|
|
|
|
file.
|
|
|
|
|
|
|
|
|
|
mpv on the other hand is stream oriented, and does not allow filters to
|
|
|
|
|
seek. (And it would not make sense to allow it, because it would ruin
|
|
|
|
|
performance.) Filters get frames sequentially in playback direction, and
|
|
|
|
|
cannot request them out of order.
|
|
|
|
|
|
|
|
|
|
To compensate for this mismatch, mpv allows the filter to access frames
|
|
|
|
|
within a certain window. ``buffered-frames`` controls the size of this
|
|
|
|
|
window. Most VapourSynth filters happen to work with this, because mpv
|
|
|
|
|
requests frames sequentially increasing from it, and most filters only
|
|
|
|
|
require frames "close" to the requested frame.
|
|
|
|
|
|
|
|
|
|
If the filter requests a frame that has a higher frame number than the
|
|
|
|
|
highest buffered frame, new frames will be decoded until the requested
|
|
|
|
|
frame number is reached. Excessive frames will be flushed out in a FIFO
|
|
|
|
|
manner (there are only at most ``buffered-frames`` in this buffer).
|
|
|
|
|
|
|
|
|
|
If the filter requests a frame that has a lower frame number than the
|
|
|
|
|
lowest buffered frame, the request cannot be satisfied, and an error
|
|
|
|
|
is returned to the filter. This kind of error is not supposed to happen
|
|
|
|
|
in a "proper" VapourSynth environment. What exactly happens depends on
|
|
|
|
|
the filters involved.
|
|
|
|
|
|
|
|
|
|
Increasing this buffer will not improve performance. Rather, it will
|
|
|
|
|
waste memory, and slow down seeks (when enough frames to fill the buffer
|
|
|
|
|
need to be decoded at once). It is only needed to prevent the error
|
|
|
|
|
described in the previous paragraph.
|
|
|
|
|
|
|
|
|
|
How many frames a filter requires depends on filter implementation
|
|
|
|
|
details, and mpv has no way of knowing. A scale filter might need only
|
|
|
|
|
1 frame, an interpolation filter may require a small number of frames,
|
|
|
|
|
and the ``Reverse`` filter will require an infinite number of frames.
|
|
|
|
|
|
|
|
|
|
If you want reliable operation to the full extend VapourSynth is
|
|
|
|
|
capable, use ``vspipe``.
|
|
|
|
|
|
2014-05-14 18:41:31 +00:00
|
|
|
The actual number of buffered frames also depends on the value of the
|
|
|
|
|
``concurrent-frames`` option. Currently, both option values are
|
|
|
|
|
multiplied to get the final buffer size.
|
|
|
|
|
|
|
|
|
|
``concurrent-frames``
|
2015-01-05 11:49:13 +00:00
|
|
|
Number of frames that should be requested in parallel. The
|
2014-05-14 18:41:31 +00:00
|
|
|
level of concurrency depends on the filter and how quickly mpv can
|
|
|
|
|
decode video to feed the filter. This value should probably be
|
|
|
|
|
proportional to the number of cores on your machine. Most time,
|
|
|
|
|
making it higher than the number of cores can actually make it
|
|
|
|
|
slower.
|
|
|
|
|
|
2019-10-23 20:27:07 +00:00
|
|
|
Technically, mpv will call the VapourSynth ``getFrameAsync`` function
|
|
|
|
|
in a loop, until there are ``concurrent-frames`` frames that have not
|
|
|
|
|
been returned by the filter yet. This also assumes that the rest of the
|
|
|
|
|
mpv filter chain reads the output of the ``vapoursynth`` filter quickly
|
|
|
|
|
enough. (For example, if you pause the player, filtering will stop very
|
|
|
|
|
soon, because the filtered frames are waiting in a queue.)
|
|
|
|
|
|
|
|
|
|
Actual concurrency depends on many other factors.
|
|
|
|
|
|
2015-01-05 11:49:13 +00:00
|
|
|
By default, this uses the special value ``auto``, which sets the option
|
|
|
|
|
to the number of detected logical CPU cores.
|
|
|
|
|
|
2019-10-23 20:27:07 +00:00
|
|
|
The following ``.vpy`` script variables are defined by mpv:
|
2015-01-03 02:25:51 +00:00
|
|
|
|
|
|
|
|
``video_in``
|
2019-10-24 10:55:26 +00:00
|
|
|
The mpv video source as vapoursynth clip. Note that this has an
|
|
|
|
|
incorrect (very high) length set, which confuses many filters. This is
|
|
|
|
|
necessary, because the true number of frames is unknown. You can use the
|
|
|
|
|
``Trim`` filter on the clip to reduce the length.
|
2015-01-03 02:25:51 +00:00
|
|
|
|
|
|
|
|
``video_in_dw``, ``video_in_dh``
|
|
|
|
|
Display size of the video. Can be different from video size if the
|
|
|
|
|
video does not use square pixels (e.g. DVD).
|
|
|
|
|
|
2015-01-03 02:37:05 +00:00
|
|
|
``container_fps``
|
|
|
|
|
FPS value as reported by file headers. This value can be wrong or
|
|
|
|
|
completely broken (e.g. 0 or NaN). Even if the value is correct,
|
|
|
|
|
if another filter changes the real FPS (by dropping or inserting
|
2019-10-24 10:55:26 +00:00
|
|
|
frames), the value of this variable will not be useful. Note that
|
2023-10-15 14:36:56 +00:00
|
|
|
the ``--container-fps-override`` command line option overrides this value.
|
2015-01-03 02:37:05 +00:00
|
|
|
|
|
|
|
|
Useful for some filters which insist on having a FPS.
|
|
|
|
|
|
2015-02-08 23:05:09 +00:00
|
|
|
``display_fps``
|
|
|
|
|
Refresh rate of the current display. Note that this value can be 0.
|
|
|
|
|
|
2023-08-11 01:15:04 +00:00
|
|
|
``display_res``
|
|
|
|
|
Resolution of the current display. This is an integer array with the
|
|
|
|
|
first entry corresponding to the width and the second entry coresponding
|
|
|
|
|
to the height. These values can be 0. Note that this will not respond to
|
|
|
|
|
monitor changes and may not work on all platforms.
|
|
|
|
|
|
2013-09-20 13:55:13 +00:00
|
|
|
``vavpp``
|
2019-05-05 17:15:01 +00:00
|
|
|
VA-API video post processing. Requires the system to support VA-API,
|
|
|
|
|
i.e. Linux/BSD only. Works with ``--vo=vaapi`` and ``--vo=gpu`` only.
|
|
|
|
|
Currently deinterlaces. This filter is automatically inserted if
|
2015-11-23 23:16:19 +00:00
|
|
|
deinterlacing is requested (either using the ``d`` key, by default mapped to
|
2013-11-22 09:21:31 +00:00
|
|
|
the command ``cycle deinterlace``, or the ``--deinterlace`` option).
|
2013-09-20 13:55:13 +00:00
|
|
|
|
|
|
|
|
``deint=<method>``
|
|
|
|
|
Select the deinterlacing algorithm.
|
|
|
|
|
|
|
|
|
|
no
|
|
|
|
|
Don't perform deinterlacing.
|
2018-02-12 17:44:46 +00:00
|
|
|
auto
|
|
|
|
|
Select the best quality deinterlacing algorithm (default). This
|
|
|
|
|
goes by the order of the options as documented, with
|
|
|
|
|
``motion-compensated`` being considered best quality.
|
2013-09-20 13:55:13 +00:00
|
|
|
first-field
|
2017-07-21 18:00:09 +00:00
|
|
|
Show only first field.
|
2013-09-20 13:55:13 +00:00
|
|
|
bob
|
2018-02-12 17:44:46 +00:00
|
|
|
bob deinterlacing.
|
2015-01-23 12:25:24 +00:00
|
|
|
weave, motion-adaptive, motion-compensated
|
|
|
|
|
Advanced deinterlacing algorithms. Whether these actually work
|
|
|
|
|
depends on the GPU hardware, the GPU drivers, driver bugs, and
|
|
|
|
|
mpv bugs.
|
2013-09-20 13:55:13 +00:00
|
|
|
|
2015-07-08 11:40:06 +00:00
|
|
|
``<interlaced-only>``
|
2018-02-12 17:23:22 +00:00
|
|
|
:no: Deinterlace all frames (default).
|
|
|
|
|
:yes: Only deinterlace frames marked as interlaced.
|
2015-07-08 11:40:06 +00:00
|
|
|
|
2017-02-27 23:54:54 +00:00
|
|
|
``reversal-bug=<yes|no>``
|
2017-03-07 08:09:54 +00:00
|
|
|
:no: Use the API as it was interpreted by older Mesa drivers. While
|
2021-08-24 16:00:05 +00:00
|
|
|
this interpretation was more obvious and intuitive, it was
|
2017-03-07 08:09:54 +00:00
|
|
|
apparently wrong, and not shared by Intel driver developers.
|
|
|
|
|
:yes: Use Intel interpretation of surface forward and backwards
|
|
|
|
|
references (default). This is what Intel drivers and newer Mesa
|
|
|
|
|
drivers expect. Matters only for the advanced deinterlacing
|
|
|
|
|
algorithms.
|
2017-02-27 23:54:54 +00:00
|
|
|
|
2014-05-02 14:41:01 +00:00
|
|
|
``vdpaupp``
|
2018-01-09 12:20:37 +00:00
|
|
|
VDPAU video post processing. Works with ``--vo=vdpau`` and ``--vo=gpu``
|
2014-05-02 14:41:01 +00:00
|
|
|
only. This filter is automatically inserted if deinterlacing is requested
|
2015-11-23 23:16:19 +00:00
|
|
|
(either using the ``d`` key, by default mapped to the command
|
2014-05-02 14:41:01 +00:00
|
|
|
``cycle deinterlace``, or the ``--deinterlace`` option). When enabling
|
|
|
|
|
deinterlacing, it is always preferred over software deinterlacer filters
|
2018-01-09 12:20:37 +00:00
|
|
|
if the ``vdpau`` VO is used, and also if ``gpu`` is used and hardware
|
2014-05-02 14:41:01 +00:00
|
|
|
decoding was activated at least once (i.e. vdpau was loaded).
|
|
|
|
|
|
|
|
|
|
``sharpen=<-1-1>``
|
|
|
|
|
For positive values, apply a sharpening algorithm to the video, for
|
|
|
|
|
negative values a blurring algorithm (default: 0).
|
|
|
|
|
``denoise=<0-1>``
|
|
|
|
|
Apply a noise reduction algorithm to the video (default: 0; no noise
|
|
|
|
|
reduction).
|
|
|
|
|
``deint=<yes|no>``
|
|
|
|
|
Whether deinterlacing is enabled (default: no). If enabled, it will use
|
|
|
|
|
the mode selected with ``deint-mode``.
|
|
|
|
|
``deint-mode=<first-field|bob|temporal|temporal-spatial>``
|
|
|
|
|
Select deinterlacing mode (default: temporal).
|
|
|
|
|
|
|
|
|
|
Note that there's currently a mechanism that allows the ``vdpau`` VO to
|
|
|
|
|
change the ``deint-mode`` of auto-inserted ``vdpaupp`` filters. To avoid
|
|
|
|
|
confusion, it's recommended not to use the ``--vo=vdpau`` suboptions
|
|
|
|
|
related to filtering.
|
|
|
|
|
|
|
|
|
|
first-field
|
|
|
|
|
Show only first field.
|
|
|
|
|
bob
|
|
|
|
|
Bob deinterlacing.
|
|
|
|
|
temporal
|
|
|
|
|
Motion-adaptive temporal deinterlacing. May lead to A/V desync
|
|
|
|
|
with slow video hardware and/or high resolution.
|
|
|
|
|
temporal-spatial
|
|
|
|
|
Motion-adaptive temporal deinterlacing with edge-guided spatial
|
|
|
|
|
interpolation. Needs fast video hardware.
|
|
|
|
|
``chroma-deint``
|
|
|
|
|
Makes temporal deinterlacers operate both on luma and chroma (default).
|
|
|
|
|
Use no-chroma-deint to solely use luma and speed up advanced
|
|
|
|
|
deinterlacing. Useful with slow video memory.
|
|
|
|
|
``pullup``
|
|
|
|
|
Try to apply inverse telecine, needs motion adaptive temporal
|
|
|
|
|
deinterlacing.
|
2015-07-08 13:14:38 +00:00
|
|
|
``interlaced-only=<yes|no>``
|
2018-02-12 17:23:22 +00:00
|
|
|
If ``yes``, only deinterlace frames marked as interlaced (default: no).
|
2014-05-02 14:41:01 +00:00
|
|
|
``hqscaling=<0-9>``
|
|
|
|
|
0
|
|
|
|
|
Use default VDPAU scaling (default).
|
|
|
|
|
1-9
|
|
|
|
|
Apply high quality VDPAU scaling (needs capable hardware).
|
2014-07-30 20:44:35 +00:00
|
|
|
|
2016-05-28 16:23:17 +00:00
|
|
|
``d3d11vpp``
|
|
|
|
|
Direct3D 11 video post processing. Currently requires D3D11 hardware
|
|
|
|
|
decoding for use.
|
|
|
|
|
|
|
|
|
|
``deint=<yes|no>``
|
|
|
|
|
Whether deinterlacing is enabled (default: no).
|
|
|
|
|
``interlaced-only=<yes|no>``
|
2018-02-12 17:23:22 +00:00
|
|
|
If ``yes``, only deinterlace frames marked as interlaced (default: no).
|
2016-07-15 17:48:58 +00:00
|
|
|
``mode=<blend|bob|adaptive|mocomp|ivctc|none>``
|
|
|
|
|
Tries to select a video processor with the given processing capability.
|
|
|
|
|
If a video processor supports multiple capabilities, it is not clear
|
|
|
|
|
which algorithm is actually selected. ``none`` always falls back. On
|
|
|
|
|
most if not all hardware, this option will probably do nothing, because
|
|
|
|
|
a video processor usually supports all modes or none.
|
video: add vf_fingerprint and a skip-logo script
skip-logo.lua is just what I wanted to have. Explanations are on the top
of that file. As usual, all documentation threatens to remove this stuff
all the time, since this stuff is just for me, and unlike a normal user
I can afford the luxuary of hacking the shit directly into the player.
vf_fingerprint is needed to support this script. It needs to scale down
video frames as part of its operation. For that, it uses zimg. zimg is
much faster than libswscale and generates more correct output. (The
filter includes a runtime fallback, but it doesn't even work because
libswscale fucks up and can't do YUV->Gray with range adjustment.)
Note on the algorithm: seems almost too simple, but was suggested to me.
It seems to be pretty effective, although long time experience with
false positives is missing. At first I wanted to use dHash [1][2], which
is also pretty simple and effective, but might actually be worse than
the implemented mechanism. dHash has the advantage that the fingerprint
is smaller. But exact matching is too unreliable, and you'd still need
to determine the number of different bits for fuzzier comparison. So
there wasn't really a reason to use it.
[1] https://pypi.org/project/dhash/
[2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
2019-07-15 01:20:40 +00:00
|
|
|
|
|
|
|
|
``fingerprint=...``
|
|
|
|
|
Compute video frame fingerprints and provide them as metadata. Actually, it
|
|
|
|
|
currently barely deserved to be called ``fingerprint``, because it does not
|
|
|
|
|
compute "proper" fingerprints, only tiny downscaled images (but which can be
|
|
|
|
|
used to compute image hashes or for similarity matching).
|
|
|
|
|
|
|
|
|
|
The main purpose of this filter is to support the ``skip-logo.lua`` script.
|
|
|
|
|
If this script is dropped, or mpv ever gains a way to load user-defined
|
|
|
|
|
filters (other than VapourSynth), this filter will be removed. Due to the
|
|
|
|
|
"special" nature of this filter, it will be removed without warning.
|
|
|
|
|
|
|
|
|
|
The intended way to read from the filter is using ``vf-metadata`` (also
|
|
|
|
|
see ``clear-on-query`` filter parameter). The property will return a list
|
|
|
|
|
of key/value pairs as follows:
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
fp0.pts = 1.2345
|
|
|
|
|
fp0.hex = 1234abcdef...bcde
|
|
|
|
|
fp1.pts = 1.4567
|
|
|
|
|
fp1.hex = abcdef1234...6789
|
|
|
|
|
...
|
|
|
|
|
fpN.pts = ...
|
|
|
|
|
fpN.hex = ...
|
|
|
|
|
type = gray-hex-16x16
|
|
|
|
|
|
|
|
|
|
Each ``fp<N>`` entry is for a frame. The ``pts`` entry specifies the
|
|
|
|
|
timestamp of the frame (within the filter chain; in simple cases this is
|
|
|
|
|
the same as the display timestamp). The ``hex`` field is the hex encoded
|
|
|
|
|
fingerprint, whose size and meaning depend on the ``type`` filter option.
|
|
|
|
|
The ``type`` field has the same value as the option the filter was created
|
|
|
|
|
with.
|
|
|
|
|
|
|
|
|
|
This returns the frames that were filtered since the last query of the
|
|
|
|
|
property. If ``clear-on-query=no`` was set, a query doesn't reset the list
|
|
|
|
|
of frames. In both cases, a maximum of 10 frames is returned. If there are
|
|
|
|
|
more frames, the oldest frames are discarded. Frames are returned in filter
|
|
|
|
|
order.
|
|
|
|
|
|
|
|
|
|
(This doesn't return a structured list for the per-frame details because the
|
|
|
|
|
internals of the ``vf-metadata`` mechanism suck. The returned format may
|
|
|
|
|
change in the future.)
|
|
|
|
|
|
|
|
|
|
This filter uses zimg for speed and profit. However, it will fallback to
|
|
|
|
|
libswscale in a number of situations: lesser pixel formats, unaligned data
|
|
|
|
|
pointers or strides, or if zimg fails to initialize for unknown reasons. In
|
|
|
|
|
these cases, the filter will use more CPU. Also, it will output different
|
|
|
|
|
fingerprints, because libswscale cannot perform the full range expansion we
|
|
|
|
|
normally request from zimg. As a consequence, the filter may be slower and
|
|
|
|
|
not work correctly in random situations.
|
|
|
|
|
|
|
|
|
|
``type=...``
|
|
|
|
|
What fingerprint to compute. Available types are:
|
|
|
|
|
|
|
|
|
|
:gray-hex-8x8: grayscale, 8 bit, 8x8 size
|
|
|
|
|
:gray-hex-16x16: grayscale, 8 bit, 16x16 size (default)
|
|
|
|
|
|
|
|
|
|
Both types simply remove all colors, downscale the image, concatenate
|
|
|
|
|
all pixel values to a byte array, and convert the array to a hex string.
|
|
|
|
|
|
|
|
|
|
``clear-on-query=yes|no``
|
|
|
|
|
Clear the list of frame fingerprints if the ``vf-metadata`` property for
|
|
|
|
|
this filter is queried (default: yes). This requires some care by the
|
|
|
|
|
user. Some types of accesses might query the filter multiple times,
|
|
|
|
|
which leads to lost frames.
|
|
|
|
|
|
|
|
|
|
``print=yes|no``
|
2021-08-24 16:00:05 +00:00
|
|
|
Print computed fingerprints to the terminal (default: no). This is
|
video: add vf_fingerprint and a skip-logo script
skip-logo.lua is just what I wanted to have. Explanations are on the top
of that file. As usual, all documentation threatens to remove this stuff
all the time, since this stuff is just for me, and unlike a normal user
I can afford the luxuary of hacking the shit directly into the player.
vf_fingerprint is needed to support this script. It needs to scale down
video frames as part of its operation. For that, it uses zimg. zimg is
much faster than libswscale and generates more correct output. (The
filter includes a runtime fallback, but it doesn't even work because
libswscale fucks up and can't do YUV->Gray with range adjustment.)
Note on the algorithm: seems almost too simple, but was suggested to me.
It seems to be pretty effective, although long time experience with
false positives is missing. At first I wanted to use dHash [1][2], which
is also pretty simple and effective, but might actually be worse than
the implemented mechanism. dHash has the advantage that the fingerprint
is smaller. But exact matching is too unreliable, and you'd still need
to determine the number of different bits for fuzzier comparison. So
there wasn't really a reason to use it.
[1] https://pypi.org/project/dhash/
[2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
2019-07-15 01:20:40 +00:00
|
|
|
mostly for testing and such. Scripts should use ``vf-metadata`` to
|
|
|
|
|
read information from this filter instead.
|
2019-11-29 19:37:11 +00:00
|
|
|
|
|
|
|
|
``gpu=...``
|
2024-04-20 06:34:34 +00:00
|
|
|
Convert video to RGB using the Vulkan or OpenGL renderer normally used with
|
|
|
|
|
``--vo=gpu``. In case of OpenGL, this requires that the EGL implementation
|
|
|
|
|
supports off-screen rendering on the default display. (This is the case with
|
|
|
|
|
Mesa.)
|
2019-11-29 19:37:11 +00:00
|
|
|
|
|
|
|
|
Sub-options:
|
|
|
|
|
|
2024-04-20 06:34:34 +00:00
|
|
|
``api=<type>``
|
|
|
|
|
The value ``type`` selects the rendering API. You can also pass
|
|
|
|
|
``help`` to get a complete list of compiled in backends.
|
|
|
|
|
|
|
|
|
|
egl
|
|
|
|
|
EGL (default if available)
|
|
|
|
|
vulkan
|
|
|
|
|
Vulkan
|
|
|
|
|
|
2019-11-29 19:37:11 +00:00
|
|
|
``w=<pixels>``, ``h=<pixels>``
|
|
|
|
|
Size of the output in pixels (default: 0). If not positive, this will
|
|
|
|
|
use the size of the first filtered input frame.
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
This is highly experimental. Performance is bad, and it will not work
|
|
|
|
|
everywhere in the first place. Some features are not supported.
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
2019-11-30 17:09:31 +00:00
|
|
|
This does not do OSD rendering. If you see OSD, then it has been
|
|
|
|
|
rendered by the VO backend. (Subtitles are rendered by the ``gpu``
|
|
|
|
|
filter, if possible.)
|
2019-11-29 19:37:11 +00:00
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
If you use this with encoding mode, keep in mind that encoding mode will
|
|
|
|
|
convert the RGB filter's output back to yuv420p in software, using the
|
|
|
|
|
configured software scaler. Using ``zimg`` might improve this, but in
|
|
|
|
|
any case it might go against your goals when using this filter.
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
|
|
|
|
Do not use this with ``--vo=gpu``. It will apply filtering twice, since
|
|
|
|
|
most ``--vo=gpu`` options are unconditionally applied to the ``gpu``
|
|
|
|
|
filter. There is no mechanism in mpv to prevent this.
|
|
|
|
|
|
