RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/DOCS/man/vf.rst

780 lines
35 KiB
ReStructuredText
Raw Normal View History

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
=============
manpage: clarify some --vf options In particular, mention deprecated things.
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
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``--vf=<filter1[=parameter1:parameter2:...],filter2,...>``
command: add better runtime filter toggling method Basically, see the example in input.rst. This is better than the "old" vf-toggle method, because it doesn't require the user to duplicate the filter string in mpv.conf and input.conf. Some aspects of this changes are untested, so enjoy your alpha testing.
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.
manpage: fix --vf exclamation mark description An exclamation mark disables the filter by default instead of enabling it.
2018-07-23 19:57:11 +00:00
A ``!`` before the filter name means the filter is disabled by default. It
command: add better runtime filter toggling method Basically, see the example in input.rst. This is better than the "old" vf-toggle method, because it doesn't require the user to duplicate the filter string in mpv.conf and input.conf. Some aspects of this changes are untested, so enjoy your alpha testing.
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> ]``
command: change and simplify filter toggle syntax "@name:!" becomes simply "@name". This is actually slightly more complex to parse, but makes for a much simpler syntax and will be less weird to the user. Suggested by haasn. The old syntax is now rejected with an error. Also add some more explicit error checks, instead of e.g. allowing empty filter names and erroring only when it's not found.
2017-03-26 11:13:34 +00:00
or for the special "toggle" syntax (see ``vf`` command):
``"@"<label-name>``
command: add better runtime filter toggling method Basically, see the example in input.rst. This is better than the "old" vf-toggle method, because it doesn't require the user to duplicate the filter string in mpv.conf and input.conf. Some aspects of this changes are untested, so enjoy your alpha testing.
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
manpage: clarify some --vf options In particular, mention deprecated things.
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.
options: add options that set defaults for af/vf/ao/vo There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
2013-11-30 23:12:10 +00:00
You can also set defaults for each filter. The defaults are applied before the
manpage: clarify some --vf options In particular, mention deprecated things.
2018-01-31 03:13:00 +00:00
normal filter parameters. This is deprecated and never worked for the
libavfilter bridge.
options: add options that set defaults for af/vf/ao/vo There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
2013-11-30 23:12:10 +00:00
``--vf-defaults=<filter1[=parameter1:parameter2:...],filter2,...>``
manpage: clarify some --vf options In particular, mention deprecated things.
2018-01-31 03:13:00 +00:00
Set defaults for each filter. (Deprecated. ``--af-defaults`` is deprecated
as well.)
options: add options that set defaults for af/vf/ao/vo There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
2013-11-30 23:12:10 +00:00
manpage: proofread and fix formatting
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
af, vf: improvements to libavfilter bridge Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
2017-05-31 15:42:03 +00:00
To get a full list of available video filters, see ``--vf=help`` and
DOCS: convert 3rd party http links to https Discovered with: find . -type f \( -name '*.md' -o -name '*.rst' \) -exec grep -n 'http://' {} + All real, i.e. non-example, links found were moved to https. There are some dead links and websites with no https available which were not converted.
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
manpage: add a note about libavfilter
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.
af, vf: improvements to libavfilter bridge Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
2017-05-31 15:42:03 +00:00
Most builtin filters are deprecated in some ways, unless they're only available
video: deprecate almost all video filters The plan is to nuke the custom filter chain completely. It's not clear what will happen to the still needed builtin filters (mostly hardware deinterlacing and vf_vapoursynth). Most likely we'll replace them with different filter chain concept (whose main purpose will be providing builtin things and bridging to libavfilter). The undocumented "warn" options are there to disable deprecation warnings when the player inserts filter automatically. The same will be done to audio filters, at a later point.
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).
video: add automatic libavfilter bridge to option parsing Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in mpv, so libavfilter's will be used. This has certain caveats (see manpage). The point of this is providing a relatively smooth transition path to removing our own filter stuff.
2017-04-02 16:47:36 +00:00
If a filter is not builtin, the ``lavfi-bridge`` will be automatically
video: support positional arguments for automatic lavfi option bridge Now e.g. --vf=pad=1000:1000 works. All in all pretty ugly and hacky. Just look away.
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``.)
video: add automatic libavfilter bridge to option parsing Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in mpv, so libavfilter's will be used. This has certain caveats (see manpage). The point of this is providing a relatively smooth transition path to removing our own filter stuff.
2017-04-02 16:47:36 +00:00
af, vf: improvements to libavfilter bridge Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
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.
manpage: clarify some --vf options In particular, mention deprecated things.
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
manpage: clarify some --vf options In particular, mention deprecated things.
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
options: add -remove action to list options Actually I wanted this for key/value lists only, but add it to the others for consistency too. (For vf/af it barely makes even sense, but anyway.)
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
options: deprecate -del for list options I never liked that these used integer indexes. -remove should have existed from the start. This deprecation is yet another empty threat, though.
2019-12-18 05:57:24 +00:00
compared. (Passing multiple filters is currently still possible, but
deprecated.)
options: add -remove action to list options Actually I wanted this for key/value lists only, but add it to the others for consistency too. (For vf/af it barely makes even sense, but anyway.)
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``.
manpage: clarify some --vf options In particular, mention deprecated things.
2018-01-31 03:13:00 +00:00
``--vf-del=filter``
options: add -remove action to list options Actually I wanted this for key/value lists only, but add it to the others for consistency too. (For vf/af it barely makes even sense, but anyway.)
2019-12-18 05:31:39 +00:00
Sort of like ``--vf-remove``, but also accepts an index number. Index
numbers start at 0, negative numbers address the end of the list (-1 is the
options: deprecate -del for list options I never liked that these used integer indexes. -remove should have existed from the start. This deprecation is yet another empty threat, though.
2019-12-18 05:57:24 +00:00
last). 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
manpage: proofread and fix formatting
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.
manpage: proofread and fix formatting
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.
af, vf: improvements to libavfilter bridge Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
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
manpage: update colormatrix property description
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,
manpage: finish an unfinished sentence
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
manpage: proofread and fix formatting
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.
manpage: finish an unfinished sentence
2019-10-21 14:54:13 +00:00
.. note::
manpage: fix RST formatting errorin vf_format description
2019-10-24 10:55:49 +00:00
For a list of available formats, use ``--vf=format=fmt=help``.
manpage: finish an unfinished sentence
2019-10-21 14:54:13 +00:00
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.
.. 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
video: move colorspace overrides to vf_format, simplify Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
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
manpage: update references to gpu VO
2018-01-09 12:20:37 +00:00
varying degrees of support. The ``gpu`` and ``vdpau`` video output
video: move colorspace overrides to vf_format, simplify Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
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)
:bt.601: ITU-R BT.601 (SD)
:bt.709: ITU-R BT.709 (HD)
:bt.2020-ncl: ITU-R BT.2020 non-constant luminance system
:bt.2020-cl: ITU-R BT.2020 constant luminance system
: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
man/vf: update vf_format documentation Brings it in line with changes to vo_opengl options.
2015-03-31 04:52:38 +00:00
used to override the setting.
video: move colorspace overrides to vf_format, simplify Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
2015-03-30 21:52:28 +00:00
This option only affects video output drivers that perform color
manpage: update references to gpu VO
2018-01-09 12:20:37 +00:00
management, for example ``gpu`` with the ``target-prim`` or
man/vf: update vf_format documentation Brings it in line with changes to vo_opengl options.
2015-03-31 04:52:38 +00:00
``icc-profile`` suboptions set.
video: move colorspace overrides to vf_format, simplify Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
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)
csputils: add some missing colorspaces With target-prim and target-trc it makes sense to include some common colorspaces that aren't strictly speaking used for video.
2015-03-30 12:54:52 +00:00
:apple: Apple RGB
:adobe: Adobe RGB (1998)
:prophoto: ProPhoto RGB (ROMM)
:cie1931: CIE 1931 RGB
manpage: add missing documentation for vf_format:gamma=dci-p3
2016-06-26 18:00:22 +00:00
:dci-p3: DCI-P3 (Digital Cinema)
csputils: add Panasonic V-Gamut primaries This is actually not entirely trivial since it involves negative Yxy coordinates, so the CMM has to be capable of full floating point operation. Fortunately, LittleCMS is, so we can just blindly implement it.
2016-06-26 17:57:29 +00:00
:v-gamut: Panasonic V-Gamut primaries
video: move colorspace overrides to vf_format, simplify Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
2015-03-30 21:52:28 +00:00
manpage: fix indenting issue in vf_format
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)
DOCS: update documentation related to color management Some of this documentation was left woefully inaccurate as color management in mpv evolved. This commit updates all of the wording and adds notes and comments where appropriate.
2016-05-06 16:00:39 +00:00
:bt.1886: ITU-R BT.1886 (EOTF corresponding to BT.601/BT.709/BT.2020)
manpage: fix indenting issue in vf_format
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)
video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.
2018-08-22 12:39:40 +00:00
:gamma2.0: Pure power curve (gamma 2.0)
manpage: fix indenting issue in vf_format
2016-02-10 23:14:02 +00:00
:gamma2.2: Pure power curve (gamma 2.2)
video: add pure gamma TRC curves for 2.0, 2.4 and 2.6.
2018-08-22 12:39:40 +00:00
:gamma2.4: Pure power curve (gamma 2.4)
:gamma2.6: Pure power curve (gamma 2.6)
manpage: fix indenting issue in vf_format
2016-02-10 23:14:02 +00:00
:gamma2.8: Pure power curve (gamma 2.8)
:prophoto: ProPhoto RGB (ROMM) curve
csputils: rename HDR curves st2084 and std-b67 are really weird names for PQ and HLG, which is what everybody else (including e.g. the ITU-R) calls them. Follow their example. I decided against naming them bt2020-pq and bt2020-hlg because it's not necessary in this case. The standard name is only used for the other colorspaces etc. because those literally have no other names.
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
vo_opengl: implement the Panasonic V-Log function User request and not that hard. Closes #3157. Note that FFmpeg doesn't support this and there's no signalling in HEVC etc., so the only way users can access it is by using vf_format manually. Mind: This encoding uses full range values, not TV range.
2016-06-26 17:28:06 +00:00
:v-log: Panasonic V-Log transfer curve
vo_opengl: implement sony s-log1 trc Source: https://pro.sony.com/bbsccms/assets/files/mkt/cinema/solutions/slog_manual.pdf Not 100% confident in the implementation since the values from the spec seem to be very subtly off (~1%), but it should be close enough for practical purposes.
2017-06-10 00:05:28 +00:00
:s-log1: Sony S-Log1 transfer curve
vo_opengl: implement sony s-log2 trc Apparently this is virtually identical to Panasonic's V-Log, but using the constants from S-Log1 and an extra scaling coefficient to make the S-Log1 curve less limited. Whatever floats their NIH boat, I guess. Source: https://pro.sony.com/bbsccms/assets/files/micro/dmpc/training/S-Log2_Technical_PaperV1_0.pdf
2017-06-10 00:51:32 +00:00
:s-log2: Sony S-Log2 transfer curve
vf_format: add gamma override option
2015-03-31 05:47:13 +00:00
video: refactor HDR implementation List of changes: 1. Kill nom_peak, since it's a pointless non-field that stores nothing of value and is _always_ derived from ref_white anyway. 2. Kill ref_white/--target-brightness, because the only case it really existed for (PQ) actually doesn't need to be this general: According to ITU-R BT.2100, PQ *always* assumes a reference monitor with a white point of 100 cd/m². 3. Improve documentation and comments surrounding this stuff. 4. Clean up some of the code in general. Move stuff where it belongs.
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.
vo_opengl: refactor HDR mechanism Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
2016-05-30 17:56:58 +00:00
vo_opengl: implement support for OOTFs and non-display referred content This introduces (yet another..) mp_colorspace members, an enum `light` (for lack of a better name) which basically tells us whether we're dealing with scene-referred or display-referred light, but also a bit more metadata (in which way is the scene-referred light expected to be mapped to the display?). The addition of this parameter accomplishes two goals: 1. Allows us to actually support HLG more-or-less correctly[1] 2. Allows people playing back direct “camera” content (e.g. v-log or s-log2) to treat it as scene-referred instead of display-referred [1] Even better would be to use the display-referred OOTF instead of the idealized OOTF, but this would require either native HLG support in LittleCMS (unlikely) or more communication between lcms.c and video_shaders.c than I'm remotely comfortable with That being said, in principle we could switch our usage of the BT.1886 EOTF to the BT.709 OETF instead and treat BT.709 content as being scene-referred under application of the 709+1886 OOTF; which moves that particular conversion from the 3dlut to the shader code; but also allows a) users like UliZappe to turn it off and b) supporting the full HLG OOTF in the same framework. But I think I prefer things as they are right now.
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)
vf_format: allow forcing stereo mode parameters
2015-04-02 21:57:56 +00:00
``<stereo-in>``
DOCS: remove references to --video-stereo-mode This option was removed by a5610b2a but the documentation persisted. Also adds an OPT_REMOVED. Closes #6938.
2019-09-14 03:25:40 +00:00
Set the stereo mode the video is assumed to be encoded in. Use
docs: Fix an old style parameter reference `--vf format:stereo-in=help` no longer works. It now must be `--vf=format:stereo-in=help`
2021-01-18 23:20:26 +00:00
``--vf=format:stereo-in=help`` to list all available modes. Check with
DOCS: remove references to --video-stereo-mode This option was removed by a5610b2a but the documentation persisted. Also adds an OPT_REMOVED. Closes #6938.
2019-09-14 03:25:40 +00:00
the ``stereo3d`` filter documentation to see what the names mean.
vf_format: allow forcing stereo mode parameters
2015-04-02 21:57:56 +00:00
``<stereo-out>``
Set the stereo mode the video should be displayed as. Takes the
DOCS: remove references to --video-stereo-mode This option was removed by a5610b2a but the documentation persisted. Also adds an OPT_REMOVED. Closes #6938.
2019-09-14 03:25:40 +00:00
same values as the ``stereo-in`` option.
vf_format: allow forcing stereo mode parameters
2015-04-02 21:57:56 +00:00
vf_format: allow forcing rotation flags
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.
vf_format: add w, h parameters Yes, this thing became vf_scale through the back door.
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.
vf_format: allow forcing display size
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.
vf_format: allow forcing aspect ratio Makes vf_dsize completely useless. Unfortunately, even our "official" encoding profiles still use it.
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).
vf_format: add gross mechanism for forcing scaler for testing This sucks, but is helpful for testing. Obviously, it would be much nicer if there were a way to specify _all_ scaler options per filter (if the user wanted), instead of always using the global options. But this is "too hard" for now. For testing, it is extremely convenient to select the scaler backend, so add this option, but make clear that it could go away. We'd delete it once there is a better mechanism for this.
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.
video: add alpha type metadata This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
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.
vf_lavfi: export a wrapper function This will allow old filter to run libavfilter instead by calling vf_lw_set_graph(), which turns the filter into a wrapper, using a given libavfilter graph. Later commits use that to automatically "reroute" a bunch of filters to libavfilter. We want to get rid of the old MPlayer filter code, because it's bad an unmaintained, but we still don't want to force everyone to use vf_lavfi, so this solution will do for a while.
2013-12-03 21:19:27 +00:00
``lavfi=graph[:sws-flags[:o=opts]]``
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
Filter video using FFmpeg's libavfilter.
``<graph>``
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
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.
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
See `<https://ffmpeg.org/ffmpeg-filters.html>`_ for syntax and available
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
2013-03-10 23:16:34 +00:00
filters.
manpage: proofread and fix formatting
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
manpage: add some minor documenation fixes - replace the incorrect reference to --opengl-shader - document a caveat when using --image-display-duration - add some documentation on --vf=lavfi=
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.)
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
2013-03-10 23:16:34 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
.. admonition:: Examples
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
2013-03-10 23:16:34 +00:00
manpage: add some minor documenation fixes - replace the incorrect reference to --opengl-shader - document a caveat when using --image-display-duration - add some documentation on --vf=lavfi=
2017-12-05 01:55:11 +00:00
``--vf=lavfi=[gradfun=20:30,vflip]``
manpage: proofread and fix formatting
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.
options: allow using [ ] for quoting in sub-options This is an attempt to make quoting of sub-option values less awkward, even if it works only with some shells. This is needed mainly for vf_lavfi. Also update the vf_lavfi manpage section.
2013-04-26 14:52:54 +00:00
manpage: proofread and fix formatting
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.
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
2013-03-10 23:16:34 +00:00
manpage: proofread and fix formatting
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.
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
2013-03-10 23:16:34 +00:00
vf_lavfi: export a wrapper function This will allow old filter to run libavfilter instead by calling vf_lw_set_graph(), which turns the filter into a wrapper, using a given libavfilter graph. Later commits use that to automatically "reroute" a bunch of filters to libavfilter. We want to get rid of the old MPlayer filter code, because it's bad an unmaintained, but we still don't want to force everyone to use vf_lavfi, so this solution will do for a while.
2013-12-03 21:19:27 +00:00
``<sws-flags>``
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
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.
DOCS: convert 3rd party http links to https Discovered with: find . -type f \( -name '*.md' -o -name '*.rst' \) -exec grep -n 'http://' {} + All real, i.e. non-example, links found were moved to https. There are some dead links and websites with no https available which were not converted.
2021-08-12 23:35:58 +00:00
See ``https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libswscale/swscale.h``.
vf_lavfi: add libavfilter bridge Requires recent FFmpeg/Libav git versions. Earlier versions will not be supported, as the API is different. (A libavfilter version that uses AVFrame instead of AVFilterBuffer is needed.) Note that this is sort of useless, because the option parser prevents you from making use of the full libavfilter graph syntax. This has to be fixed later. Most of the filter creation code (half of the config() function) has been taken from avplay.c. This code is not based on MPlayer's vf_lavfi. The MPlayer code doesn't compile as it hasn't been updated through multiple libavfilter API changes, making it completely useless as a starting point.
2013-03-10 23:16:34 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``<o>``
Set AVFilterGraph options. These should be documented by FFmpeg.
vf_lavfi: allow setting avopts
2013-05-25 13:53:55 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
.. admonition:: Example
vf_lavfi: allow setting avopts
2013-05-25 13:53:55 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``'--vf=lavfi=yadif:o="threads=2,thread_type=slice"'``
forces a specific threading configuration.
vf_lavfi: allow setting avopts
2013-05-25 13:53:55 +00:00
manpage: proofread and fix formatting
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.
options: move -ass-bottom-margin/-ass-top-margin options to vf_sub These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
2012-12-12 22:35:01 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``<bottom-margin>``
options: move -ass-bottom-margin/-ass-top-margin options to vf_sub These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
2012-12-12 22:35:01 +00:00
Adds a black band at the bottom of the frame. The SSA/ASS renderer can
sub: mess with styling defaults, change --ass-use-margins behavior Now --ass-use-margins doesn't apply to normal subtitles anymore. This is probably the inverse from the mpv behavior users expected so far, and thus a breaking change, so rename the option, that the user at least has a chance to lookup the option and decide whether the new behavior is wanted or not. The basic idea here is: - plain text subtitles should have a certain useful defalt behavior, like actually using margins - ASS subtitles should never be broken by default - ASS subtitles should look and behave like plaintext subtitles if the --ass-style-override=force option is used This also subtly changes --sub-scale-with-window and adds the --ass- scale-with-window option. Since this one isn't so important, don't bother with compatibility.
2015-02-16 19:04:15 +00:00
place subtitles there (with ``--sub-use-margins``).
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``<top-margin>``
sub: mess with styling defaults, change --ass-use-margins behavior Now --ass-use-margins doesn't apply to normal subtitles anymore. This is probably the inverse from the mpv behavior users expected so far, and thus a breaking change, so rename the option, that the user at least has a chance to lookup the option and decide whether the new behavior is wanted or not. The basic idea here is: - plain text subtitles should have a certain useful defalt behavior, like actually using margins - ASS subtitles should never be broken by default - ASS subtitles should look and behave like plaintext subtitles if the --ass-style-override=force option is used This also subtly changes --sub-scale-with-window and adds the --ass- scale-with-window option. Since this one isn't so important, don't bother with compatibility.
2015-02-16 19:04:15 +00:00
Black band on the top for toptitles (with ``--sub-use-margins``).
options: move -ass-bottom-margin/-ass-top-margin options to vf_sub These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
2012-12-12 22:35:01 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
.. admonition:: Examples
options: move -ass-bottom-margin/-ass-top-margin options to vf_sub These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
2012-12-12 22:35:01 +00:00
manpage: proofread and fix formatting
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
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
2014-05-14 18:41:31 +00:00
``vapoursynth=file:buffered-frames:concurrent-frames``
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
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
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
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
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
2014-04-12 15:51:19 +00:00
VapourSynth, but you can use certain filters.
manpage: slap "do not use" label on vf_vapoursynth Plus some other minor corrections.
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.
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
2019-10-23 20:27:07 +00:00
If you just want to play video generated by VapourSynth (i.e. using
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
2014-04-12 15:51:19 +00:00
a native VapourSynth video source), it's better to use ``vspipe`` and a
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
2019-10-23 20:27:07 +00:00
pipe or FIFO to feed the video to mpv. The same applies if the filter script
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
2014-05-14 18:41:31 +00:00
requires random frame access (see ``buffered-frames`` parameter).
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
2014-04-12 15:51:19 +00:00
``file``
Filename of the script source. Currently, this is always a python
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
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.
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
2014-04-12 15:51:19 +00:00
.. admonition:: Example:
::
import vapoursynth as vs
core = vs.get_core()
core.std.AddBorders(video_in, 10, 10, 20, 20).set_output()
manpage: vf_vapoursynth: document what happens on seeking Unfortunately, reloading on seeking causes real problems.
2014-04-13 10:27:26 +00:00
.. warning::
The script will be reloaded on every seek. This is done to reset
vf_vapoursynth: wipe vapoursynth state completely on reloading Before this commit, the filter attempted to keep the vsscript state (p->se) even when the script was reloaded. Change it to destroy the script state too on reloading. Now no workaround for LoadPlugin is necessary, and this also fixes a weird theoretical race condition when destroying and recreating the mpv source filter.
2014-04-14 16:03:13 +00:00
the filter properly on discontinuities.
manpage: vf_vapoursynth: document what happens on seeking Unfortunately, reloading on seeking causes real problems.
2014-04-13 10:27:26 +00:00
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
2014-05-14 18:41:31 +00:00
``buffered-frames``
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
2014-04-12 15:51:19 +00:00
Maximum number of decoded video frames that should be buffered before
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
2014-05-14 18:41:31 +00:00
the filter (default: 4). This specifies the maximum number of frames
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
2019-10-23 20:27:07 +00:00
the script can request in backward direction.
man: fix grammar issues
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.
video: add VapourSynth filter bridge Mainly meant to apply simple VapourSynth filters to video at runtime. This has various restrictions, which are listed in the manpage. Additionally, this actually copies video frames when converting frame references from mpv to VapourSynth, and a second time when going from VapourSynth to mpv. This is inefficient and could probably be easily improved. But for now, this is simpler, and in fact I'm not sure if we even can references VapourSynth frames after the core has been destroyed.
2014-04-12 15:51:19 +00:00
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
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``.
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
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``
vf_vapoursynth: autodetect CPU count This adds an "auto" choice to the concurrent-frames suboption, and makes it the default. I'm not so sure about making this the default, though. It could lead to excessive buffering with large CPU counts. But we'll see.
2015-01-05 11:49:13 +00:00
Number of frames that should be requested in parallel. The
vf_vapoursynth: allow parallel processing VapourSynth won't just filter multiple frames at once on its own. You have to request multiple frames at once manually. This is what this commit introduces: a sub-option controls how many frames will be requested at once. This also changes the semantics of the maxbuffer sub- option, now renamed to buffered-frames.
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.
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
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.
vf_vapoursynth: autodetect CPU count This adds an "auto" choice to the concurrent-frames suboption, and makes it the default. I'm not so sure about making this the default, though. It could lead to excessive buffering with large CPU counts. But we'll see.
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.
vf: improve vf_vapoursynth description In particular describe dataflow issues (see #7020). Insert complaint that I'm wasting time on this crap instead of things that benefit me.
2019-10-23 20:27:07 +00:00
The following ``.vpy`` script variables are defined by mpv:
manpage: vf_vapoursynth: document mpv-specific predefined variables
2015-01-03 02:25:51 +00:00
``video_in``
manpage: slap "do not use" label on vf_vapoursynth Plus some other minor corrections.
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.
manpage: vf_vapoursynth: document mpv-specific predefined variables
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).
vf_vapoursynth: pass through container FPS value This is basically a hack; but apparently a needed one, since many vapoursynth filters insist on having a FPS set. We need to apply the FPS override before creating the filters. Also change some terminal output related to the FPS value.
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
manpage: slap "do not use" label on vf_vapoursynth Plus some other minor corrections.
2019-10-24 10:55:26 +00:00
frames), the value of this variable will not be useful. Note that
vf_vapoursynth: pass through container FPS value This is basically a hack; but apparently a needed one, since many vapoursynth filters insist on having a FPS set. We need to apply the FPS override before creating the filters. Also change some terminal output related to the FPS value.
2015-01-03 02:37:05 +00:00
the ``--fps`` command line option overrides this value.
Useful for some filters which insist on having a FPS.
vf_vapoursynth: add display refresh rate property This value is not necessarily trustworthy (it might change) and can be 0.
2015-02-08 23:05:09 +00:00
``display_fps``
Refresh rate of the current display. Note that this value can be 0.
vaapi: add vf_vavpp and use it for deinterlacing Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
2013-09-20 13:55:13 +00:00
``vavpp``
man: clarify vavpp requirements I assume (but cannot confirm) that VA-AP-API is in fact a typo, because most if not all search engine results related to it are from mpv's manual page. By changing this to VA-API and clarifying that this requires VA-API support on a system to use it, we can hopefully make it clear to unsuspecting Windows users that this is not the filter they're looking for. Concerns #6690.
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
manpage: deinterlace is now the lowercase d there were a few places that that used an upper case D and one that still actually said Shift+D
2015-11-23 23:16:19 +00:00
deinterlacing is requested (either using the ``d`` key, by default mapped to
Fixing list of vo's that vavpp works with, in man page.
2013-11-22 09:21:31 +00:00
the command ``cycle deinterlace``, or the ``--deinterlace`` option).
vaapi: add vf_vavpp and use it for deinterlacing Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
2013-09-20 13:55:13 +00:00
``deint=<method>``
Select the deinterlacing algorithm.
no
Don't perform deinterlacing.
vf_vavpp: select best quality deinterlacing algorithm by default This switches the default away from "bob" to the best algorithm reported as supported by the driver. This is convenient for users, and there is no reason to use something worse by default. Untested.
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.
vaapi: add vf_vavpp and use it for deinterlacing Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
2013-09-20 13:55:13 +00:00
first-field
options: kill --field-dominance GPL-only author, no chance of relicensing.
2017-07-21 18:00:09 +00:00
Show only first field.
vaapi: add vf_vavpp and use it for deinterlacing Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
2013-09-20 13:55:13 +00:00
bob
vf_vavpp: select best quality deinterlacing algorithm by default This switches the default away from "bob" to the best algorithm reported as supported by the driver. This is convenient for users, and there is no reason to use something worse by default. Untested.
2018-02-12 17:44:46 +00:00
bob deinterlacing.
vf_vavpp: add more deinterlacing algorithms These are untested due to lack of hardware. From what I've heard, the drivers are pretty buggy, so it's not clear how well this works, if at all.
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.
vaapi: add vf_vavpp and use it for deinterlacing Merged from pull request #246 by xylosper. Minor cosmetic changes, some adjustments (compatibility with older libva versions), and manpage additions by wm4. Signed-off-by: wm4 <wm4@nowhere>
2013-09-20 13:55:13 +00:00
vf_vavpp: don't attempt to deinterlace progressive frames
2015-07-08 11:40:06 +00:00
``<interlaced-only>``
video: make --deinterlace and HW deinterlace filters always deinterlace Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
2018-02-12 17:23:22 +00:00
:no: Deinterlace all frames (default).
:yes: Only deinterlace frames marked as interlaced.
vf_vavpp: don't attempt to deinterlace progressive frames
2015-07-08 11:40:06 +00:00
vf_vavpp: add advanced deint bug compatibility for Intel vaapi drivers I'm not sure what's going on here, but it appears kodi switches forward and backwards references for advanced VPP deinterlacing modes. This in turn makes deinterlacing with these modes apparently work. If you don't switch the directions, you get a stuttering mess. As far as the libva trace dump is concerned, this makes mpv's libva deinterlacing API use behave like kodi's, and appears to reproduce smooth video with advanced libva deinterlacing enabled. I'm hearing that Mesa actually does it correctly, and I'm not sure what will happen there. For now, passing "reversal-bug=no" as sub-option to the vavpp filter will undo this behavior.
2017-02-27 23:54:54 +00:00
``reversal-bug=<yes|no>``
manpage: adjust description of libva deinterlacer ref direction mess Relevant: https://cgit.freedesktop.org/mesa/mesa/commit/?id=0798fddb5000f2b1edffc693ec65236a680ce61f Eventually I'll just remove this option. But it's probably good to leave it for while, possibly for letting Mesa VA driver users test and confirm this.
2017-03-07 08:09:54 +00:00
:no: Use the API as it was interpreted by older Mesa drivers. While
DOCS: fix spelling
2021-08-24 16:00:05 +00:00
this interpretation was more obvious and intuitive, it was
manpage: adjust description of libva deinterlacer ref direction mess Relevant: https://cgit.freedesktop.org/mesa/mesa/commit/?id=0798fddb5000f2b1edffc693ec65236a680ce61f Eventually I'll just remove this option. But it's probably good to leave it for while, possibly for letting Mesa VA driver users test and confirm this.
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.
vf_vavpp: add advanced deint bug compatibility for Intel vaapi drivers I'm not sure what's going on here, but it appears kodi switches forward and backwards references for advanced VPP deinterlacing modes. This in turn makes deinterlacing with these modes apparently work. If you don't switch the directions, you get a stuttering mess. As far as the libva trace dump is concerned, this makes mpv's libva deinterlacing API use behave like kodi's, and appears to reproduce smooth video with advanced libva deinterlacing enabled. I'm hearing that Mesa actually does it correctly, and I'm not sure what will happen there. For now, passing "reversal-bug=no" as sub-option to the vavpp filter will undo this behavior.
2017-02-27 23:54:54 +00:00
manpage: document vf_vdpaupp
2014-05-02 14:41:01 +00:00
``vdpaupp``
manpage: update references to gpu VO
2018-01-09 12:20:37 +00:00
VDPAU video post processing. Works with ``--vo=vdpau`` and ``--vo=gpu``
manpage: document vf_vdpaupp
2014-05-02 14:41:01 +00:00
only. This filter is automatically inserted if deinterlacing is requested
manpage: deinterlace is now the lowercase d there were a few places that that used an upper case D and one that still actually said Shift+D
2015-11-23 23:16:19 +00:00
(either using the ``d`` key, by default mapped to the command
manpage: document vf_vdpaupp
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
manpage: update references to gpu VO
2018-01-09 12:20:37 +00:00
if the ``vdpau`` VO is used, and also if ``gpu`` is used and hardware
manpage: document vf_vdpaupp
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.
vf_vdpaupp: don't attempt to deinterlace progressive frames
2015-07-08 13:14:38 +00:00
``interlaced-only=<yes|no>``
video: make --deinterlace and HW deinterlace filters always deinterlace Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
2018-02-12 17:23:22 +00:00
If ``yes``, only deinterlace frames marked as interlaced (default: no).
manpage: document vf_vdpaupp
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).
video/filter: add vf_buffer Mostly useful for debugging.
2014-07-30 20:44:35 +00:00
vf_d3d11vpp: add a D3D11 video processor filter Main use: deinterlacing. I'm not sure how to select the deinterlacing mode at all. You can enumate the available video processors, but at least on Intel, all of them either signal support for all deinterlacers, or none (the latter is apparently used for IVTC). I haven't found anything that actually tells the processor _which_ algorithm to use. Another strange detail is how to select top/bottom fields and field dominance. At least I'm getting quite similar results to vavpp on Linux, so I'm content with it for now. Future plans include removing the D3D11 video processor use from the ANGLE interop code.
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>``
video: make --deinterlace and HW deinterlace filters always deinterlace Before this, we made deinterlacing dependent on the video codec metadata (AVFrame.interlaced_frame for libavcodec). So even if --deinterlace=yes was set, we skipped deinterlacing if the flag wasn't set. This is very unreliable and there are many streams with flags incorrectly set. The potential problem is that this might upset people who alwase enabled deinterlace and hoped it worked. But it's likely these people were screwed by this setting anyway. The new behavior is less tricky and easier to understand, and this preferable. Maybe one day we could introduce a --deinterlace=auto, which does the right thing, but of course this would be hard to implement (esecially with hwdec). Fixes #5219.
2018-02-12 17:23:22 +00:00
If ``yes``, only deinterlace frames marked as interlaced (default: no).
vf_d3d11vpp: add video processor selection Unfortunately completely useless. I still don't know how to force a video processor to use a specific algorithm, if it's even possible.
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``
DOCS: fix spelling
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.
vf_gpu: add video filter using vo_gpu's renderer Probably pretty useless in this form (see: the wall of warnings), but someone wanted this. I think this should be useful to perform some automated tests, maybe. Fixes: #7194
2019-11-29 19:37:11 +00:00
``gpu=...``
Convert video to RGB using the OpenGL renderer normally used with
``--vo=gpu``. This requires that the EGL implementation supports off-screen
rendering on the default display. (This is the case with Mesa.)
Sub-options:
``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::
vf_gpu: render subtitles Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
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.)
vf_gpu: add video filter using vo_gpu's renderer Probably pretty useless in this form (see: the wall of warnings), but someone wanted this. I think this should be useful to perform some automated tests, maybe. Fixes: #7194
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.