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

714 lines
32 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 OUTPUT DRIVERS
====================
Video output drivers are interfaces to different video output facilities. The
syntax is:
manpage: remove more references to deprecated sub-option syntax Fixes #3497.
2016-09-07 10:55:21 +00:00
``--vo=<driver1,driver2,...[,]>``
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
Specify a priority list of video output drivers to be used.
manpage: remove more references to deprecated sub-option syntax Fixes #3497.
2016-09-07 10:55:21 +00:00
If the list has a trailing ``,``, mpv will fall back on drivers not contained
in the list.
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::
See ``--vo=help`` for a list of compiled-in video output drivers.
manpage: merge new manpage About a year ago, ubitux converted most of the old manpage from the hard to maintain nroff format to reStructuredText. This was not merged back into the master repository immediately. The argument was that the new manpage still required work to be done. However, progress was very slow. Even worse: the old manpage wasn't updated, because it was scheduled for deletion, and updating it would have meant useless work. Now the situation is that the new manpage still isn't finished, and the old manpage is grossly out of sync with the player. This is not helpful for users. Additionally, keeping the new manpage in a separate branch, while the normal development repository for code had the old manpage, was very inconvenient, because you couldn't just update the documentation in the same commit as the code. Even though the new manpage isn't finished yet, merging it now seems to be the best course of action. Squash-merge the manpage development branch [1], revision e89f5dd3f2, which branches from the mplayer2 master branch after revision 159102e0cb. Committers: * Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.) * Uoti Urpala <uau@mplayer2.org> (Many updates.) * Myself (Minor edits.) Most text of the manpage has been directly taken from the old manpage, because this is a conversion, not a complete rewrite. [1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
vo_opengl: refactor into vo_gpu This is done in several steps: 1. refactor MPGLContext -> struct ra_ctx 2. move GL-specific stuff in vo_opengl into opengl/context.c 3. generalize context creation to support other APIs, and add --gpu-api 4. rename all of the --opengl- options that are no longer opengl-specific 5. move all of the stuff from opengl/* that isn't GL-specific into gpu/ (note: opengl/gl_utils.h became opengl/utils.h) 6. rename vo_opengl to vo_gpu 7. to handle window screenshots, the short-term approach was to just add it to ra_swchain_fns. Long term (and for vulkan) this has to be moved to ra itself (and vo_gpu altered to compensate), but this was a stop-gap measure to prevent this commit from getting too big 8. move ra->fns->flush to ra_gl_ctx instead 9. some other minor changes that I've probably already forgotten Note: This is one half of a major refactor, the other half of which is provided by rossy's following commit. This commit enables support for all linux platforms, while his version enables support for all non-linux platforms. Note 2: vo_opengl_cb.c also re-uses ra_gl_ctx so it benefits from the --opengl- options like --opengl-early-flush, --opengl-finish etc. Should be a strict superset of the old functionality. Disclaimer: Since I have no way of compiling mpv on all platforms, some of these ports were done blindly. Specifically, the blind ports included context_mali_fbdev.c and context_rpi.c. Since they're both based on egl_helpers, the port should have gone smoothly without any major changes required. But if somebody complains about a compile error on those platforms (assuming anybody actually uses them), you know where to complain.
2017-09-14 06:04:55 +00:00
The recommended output driver is ``--vo=gpu``, which is the default. All
manpage: remove more references to deprecated sub-option syntax Fixes #3497.
2016-09-07 10:55:21 +00:00
other drivers are for compatibility or special purposes. If the default
does not work, it will fallback to other drivers (in the same order as
listed by ``--vo=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
Available video output drivers are:
DOCS/options.rst DOCS/vo.rst: Update discussion of hwdec usage The documentation's current discussion of hwdec usage is out of date, and unnecessarily pessemistic when applied to modern hardware. The reality is that modern APIs on modern hardware produce reasonable results and there's no need to pretend otherwise. The current language that tries to drive people away from using hwdecs at all leads to them making bad choices when they do try to use it. Let's also make it clearer that users should use vo=gpu with hwdecs rather than vo=vaapi or vo=vdpau. Even the existing admonitions have proven insufficient, so let's strengthen that language.
2022-03-05 18:49:56 +00:00
``gpu``
General purpose, customizable, GPU-accelerated video output driver. It
supports extended scaling methods, dithering, color management, custom
shaders, HDR, and more.
See `GPU renderer options`_ for options specific to this VO.
DOCS: update notes about new profiles
2023-09-20 13:21:15 +00:00
By default, mpv utilizes settings that balance quality and performance.
Additionally, two predefined profiles are available: ``fast`` for maximum
performance and ``high-quality`` for superior rendering quality. You can
apply a specific profile using the ``--profile=<name>`` option and inspect
its contents using ``--show-profile=<name>``.
DOCS/options.rst DOCS/vo.rst: Update discussion of hwdec usage The documentation's current discussion of hwdec usage is out of date, and unnecessarily pessemistic when applied to modern hardware. The reality is that modern APIs on modern hardware produce reasonable results and there's no need to pretend otherwise. The current language that tries to drive people away from using hwdecs at all leads to them making bad choices when they do try to use it. Let's also make it clearer that users should use vo=gpu with hwdecs rather than vo=vaapi or vo=vdpau. Even the existing admonitions have proven insufficient, so let's strengthen that language.
2022-03-05 18:49:56 +00:00
This VO abstracts over several possible graphics APIs and windowing
contexts, which can be influenced using the ``--gpu-api`` and
``--gpu-context`` options.
Hardware decoding over OpenGL-interop is supported to some degree. Note
that in this mode, some corner case might not be gracefully handled, and
color space conversion and chroma upsampling is generally in the hand of
the hardware decoder APIs.
``gpu`` makes use of FBOs by default. Sometimes you can achieve better
quality or performance by changing the ``--fbo-format`` option to
``rgb16f``, ``rgb32f`` or ``rgb``. Known problems include Mesa/Intel not
accepting ``rgb16``, Mesa sometimes not being compiled with float texture
support, and some macOS setups being very slow with ``rgb16`` but fast
with ``rgb32f``. If you have problems, you can also try enabling the
``--gpu-dumb-mode=yes`` option.
``gpu-next``
Experimental video renderer based on ``libplacebo``. This supports almost
the same set of features as ``--vo=gpu``. See `GPU renderer options`_ for a
list.
Should generally be faster and higher quality, but some features may still
be missing or misbehave. Expect (and report!) bugs. See here for a list of
known differences and bugs:
https://github.com/mpv-player/mpv/wiki/GPU-Next-vs-GPU
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``xv`` (X11 only)
manpage: various improvements Took a superficial look at the manpage, and fixed whatever I spotted.
2013-09-10 13:09:24 +00:00
Uses the XVideo extension to enable hardware-accelerated display. This is
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
the most compatible VO on X, but may be low-quality, and has issues with
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
OSD and subtitle display.
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 notes when to use/not use certain AO and VO drivers
2014-04-19 13:29:05 +00:00
.. note:: This driver is for compatibility with old systems.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
``--xv-adaptor=<number>``
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Select a specific XVideo adapter (check xvinfo results).
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--xv-port=<number>``
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
Select a specific XVideo port.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--xv-ck=<cur|use|set>``
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Select the source from which the color key is taken (default: cur).
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
cur
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
The default takes the color key currently set in Xv.
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
use
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Use but do not set the color key from mpv (use the ``--colorkey``
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
option to change it).
set
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Same as use but also sets the supplied color key.
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: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--xv-ck-method=<none|man|bg|auto>``
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Sets the color key drawing method (default: man).
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
vo_xv: remove an aliased option Trying to get rid of them, and no-colorkey is an instance of it. Kill it.
2016-08-31 11:22:32 +00:00
none
Disables color-keying.
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
man
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Draw the color key manually (reduces flicker in some cases).
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
bg
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Set the color key as window background.
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
auto
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Let Xv draw the color key.
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: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--xv-colorkey=<number>``
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Changes the color key to an RGB value of your choice. ``0x000000`` is
options: move --colorkey option to vo_xv
2013-07-21 23:03:22 +00:00
black and ``0xffffff`` is white.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--xv-buffers=<number>``
vo_xv: make number of buffers configurable
2015-05-20 21:07:47 +00:00
Number of image buffers to use for the internal ringbuffer (default: 2).
Increasing this will use more memory, but might help with the X server
not responding quickly enough if video FPS is close to or higher than
the display refresh rate.
Revert "vo_x11: remove this video output" This reverts commit d11184a256ed709a03fa94a4e3940eed1b76d76f. Unfortunately, there was a lot of unexpected resistance. Do note that this is still extremely slow, crappy, etc. Note that vo_x11.c was further edited. Compared to the removed vo_x11.c, an additional ~200 lines of code was removed in order to simplify it. I tried to strip it down as much as possible. In particular, support for odd non-32 bit formats (24, 16, 15, 8 bit) is dropped. Closes #2300.
2015-09-30 20:52:22 +00:00
``x11`` (X11 only)
Shared memory video output driver without hardware acceleration that works
whenever X11 is present.
sws_utils, zimg: destroy vo_x11 and vo_drm performance Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
2019-10-31 15:45:28 +00:00
Since mpv 0.30.0, you may need to use ``--profile=sw-fast`` to get decent
performance.
Revert "vo_x11: remove this video output" This reverts commit d11184a256ed709a03fa94a4e3940eed1b76d76f. Unfortunately, there was a lot of unexpected resistance. Do note that this is still extremely slow, crappy, etc. Note that vo_x11.c was further edited. Compared to the removed vo_x11.c, an additional ~200 lines of code was removed in order to simplify it. I tried to strip it down as much as possible. In particular, support for odd non-32 bit formats (24, 16, 15, 8 bit) is dropped. Closes #2300.
2015-09-30 20:52:22 +00:00
.. note:: This is a fallback only, and should not be normally used.
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``vdpau`` (X11 only)
manpage: merge new manpage About a year ago, ubitux converted most of the old manpage from the hard to maintain nroff format to reStructuredText. This was not merged back into the master repository immediately. The argument was that the new manpage still required work to be done. However, progress was very slow. Even worse: the old manpage wasn't updated, because it was scheduled for deletion, and updating it would have meant useless work. Now the situation is that the new manpage still isn't finished, and the old manpage is grossly out of sync with the player. This is not helpful for users. Additionally, keeping the new manpage in a separate branch, while the normal development repository for code had the old manpage, was very inconvenient, because you couldn't just update the documentation in the same commit as the code. Even though the new manpage isn't finished yet, merging it now seems to be the best course of action. Squash-merge the manpage development branch [1], revision e89f5dd3f2, which branches from the mplayer2 master branch after revision 159102e0cb. Committers: * Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.) * Uoti Urpala <uau@mplayer2.org> (Many updates.) * Myself (Minor edits.) Most text of the manpage has been directly taken from the old manpage, because this is a conversion, not a complete rewrite. [1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
Uses the VDPAU interface to display and optionally also decode video.
DOCS/options.rst DOCS/vo.rst: Update discussion of hwdec usage The documentation's current discussion of hwdec usage is out of date, and unnecessarily pessemistic when applied to modern hardware. The reality is that modern APIs on modern hardware produce reasonable results and there's no need to pretend otherwise. The current language that tries to drive people away from using hwdecs at all leads to them making bad choices when they do try to use it. Let's also make it clearer that users should use vo=gpu with hwdecs rather than vo=vaapi or vo=vdpau. Even the existing admonitions have proven insufficient, so let's strengthen that language.
2022-03-05 18:49:56 +00:00
Hardware decoding is used with ``--hwdec=vdpau``. Note that there is
absolutely no reason to use this, other than compatibility. We strongly
recommend that you use ``--vo=gpu`` with ``--hwdec=nvdec`` instead.
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: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
.. note::
Earlier versions of mpv (and MPlayer, mplayer2) provided sub-options
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
to tune vdpau post-processing, like ``deint``, ``sharpen``, ``denoise``,
manpage: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
``chroma-deint``, ``pullup``, ``hqscaling``. These sub-options are
deprecated, and you should use the ``vdpaupp`` video filter instead.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
``--vo-vdpau-sharpen=<-1-1>``
manpage: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
(Deprecated. See note about ``vdpaupp``.)
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
For positive values, apply a sharpening algorithm to the video, for
negative values a blurring algorithm (default: 0).
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-denoise=<0-1>``
manpage: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
(Deprecated. See note about ``vdpaupp``.)
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
Apply a noise reduction algorithm to the video (default: 0; no noise
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
reduction).
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-chroma-deint``
manpage: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
(Deprecated. See note about ``vdpaupp``.)
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
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.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-pullup``
manpage: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
(Deprecated. See note about ``vdpaupp``.)
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
Try to apply inverse telecine, needs motion adaptive temporal
deinterlacing.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-hqscaling=<0-9>``
manpage: deprecated vo_vdpau postprocessing options This seems a bit silly, but the way vf_vdpaupp works, this is cleaner.
2014-05-02 14:57:39 +00:00
(Deprecated. See note about ``vdpaupp``.)
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
0
Use default VDPAU scaling (default).
1-9
Apply high quality VDPAU scaling (needs capable hardware).
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-fps=<number>``
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
Override autodetected display refresh rate value (the value is needed
for framedrop to allow video playback rates higher than display
refresh rate, and for vsync-aware frame timing adjustments). Default 0
means use autodetected value. A positive value is interpreted as a
refresh rate in Hz and overrides the autodetected value. A negative
value disables all timing adjustment and framedrop logic.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-composite-detect``
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
NVIDIA's current VDPAU implementation behaves somewhat differently
under a compositing window manager and does not give accurate frame
timing information. With this option enabled, the player tries to
detect whether a compositing window manager is active. If one is
detected, the player disables timing adjustments as if the user had
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
specified ``fps=-1`` (as they would be based on incorrect input). This
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
means timing is somewhat less accurate than without compositing, but
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
with the composited mode behavior of the NVIDIA driver, there is no
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
hard playback speed limit even without the disabled logic. Enabled by
manpage: fix a renamed option name
2016-10-21 16:50:40 +00:00
default, use ``--vo-vdpau-composite-detect=no`` to disable.
vo_vdpau: rename some sub-options Since the sub-options have been deprecated very recently, and are redirected to global options, we don't need to document this change.
2016-09-06 16:43:51 +00:00
``--vo-vdpau-queuetime-windowed=<number>`` and ``queuetime-fs=<number>``
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
Use VDPAU's presentation queue functionality to queue future video
frame changes at most this many milliseconds in advance (default: 50).
See below for additional information.
vo_vdpau: rename some sub-options Since the sub-options have been deprecated very recently, and are redirected to global options, we don't need to document this change.
2016-09-06 16:43:51 +00:00
``--vo-vdpau-output-surfaces=<2-15>``
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
Allocate this many output surfaces to display video frames (default:
3). See below for additional information.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-colorkey=<#RRGGBB|#AARRGGBB>``
vo_vdpau: allow setting colorkey Formally, this sets the "background color" of the presentation queue. But in practice, this color is also used as colorkey. This commit doesn't change the VDPAU default yet.
2013-08-17 17:57:18 +00:00
Set the VDPAU presentation queue background color, which in practice
is the colorkey used if VDPAU operates in overlay mode (default:
vo_vdpau: use color close to black as default colorkey (instead of green) The VDPAU default colorkey, although it seems to be driver specific, is usually green. This is a pretty annoying color, and you usually see it briefly (as flashes) if the VDPAU window resizes. Change it to some shade of black. The new default color is close to what MPlayer picks as colorkey (and apparently it worked well for them): VdpColor vdp_bg = {0.01, 0.02, 0.03, 0}; Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead, which should be the same assuming 8 bit colors. Obviously, you can't use black, because black is a way too common color, and would make it too easy to observe the colorkey effect when e.g. moving a terminal with black background over the video window.
2013-08-17 18:05:28 +00:00
``#020507``, some shade of black). If the alpha component of this value
is 0, the default VDPAU colorkey will be used instead (which is usually
green).
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vdpau-force-yuv``
vo_vdpau: add RGB support Apparently this was dropped some years ago, but judging from MPlayer's handling of this, the original code wasn't so great anyway. The new code handling clearing of panscan borders correctly, and integrates better with the YUV path. (Although the VDPAU API sure makes this annoying with its separate surface types for RGB.) Note that we create 5 surfaces for some reason - I don't think this makes too much sense (because we can't use the deinterlacer with RGB surfaces), but at least it reduces the amount of differences with the YUV code path. Clearing the borders is done by drawing a single black pixel over the window. This sounds pretty dumb, but it appears to work well, and there is no other API for that. (One could try to use the video mixer for this purpose, since it has all kinds of features, including compositing multiple RGBA surfaces and clearing the window background. But it would require an invisible dummy video surface to make the video mixer happy, and that's getting too messy.)
2013-08-18 03:12:21 +00:00
Never accept RGBA input. This means mpv will insert a filter to convert
to a YUV format before the VO. Sometimes useful to force availability
of certain YUV-only features, like video equalizer or deinterlacing.
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
man: fix a whole bunch of typos
2014-09-01 02:25:57 +00:00
Using the VDPAU frame queuing functionality controlled by the queuetime
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
options makes mpv's frame flip timing less sensitive to system CPU load and
allows mpv to start decoding the next frame(s) slightly earlier, which can
reduce jitter caused by individual slow-to-decode frames. However, the
NVIDIA graphics drivers can make other window behavior such as window moves
choppy if VDPAU is using the blit queue (mainly happens if you have the
composite extension enabled) and this feature is active. If this happens on
your system and it bothers you then you can set the queuetime value to 0 to
disable this feature. The settings to use in windowed and fullscreen mode
are separate because there should be no reason to disable this for
fullscreen mode (as the driver issue should not affect the video itself).
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
You can queue more frames ahead by increasing the queuetime values and the
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``output_surfaces`` count (to ensure enough surfaces to buffer video for a
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
certain time ahead you need at least as many surfaces as the video has
frames during that time, plus two). This could help make video smoother in
some cases. The main downsides are increased video RAM requirements for
the surfaces and laggier display response to user commands (display
changes only become visible some time after they're queued). The graphics
driver implementation may also have limits on the length of maximum
queuing time or number of queued surfaces that work well or at all.
vo_direct3d: deprecate direct3d_shaders alias And remove the difference between the aliases. This is needed to make the sub-option changes less painful.
2016-09-05 19:05:31 +00:00
``direct3d`` (Windows only)
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
Video output driver that uses the Direct3D interface.
manpage: add notes when to use/not use certain AO and VO drivers
2014-04-19 13:29:05 +00:00
.. note:: This driver is for compatibility with systems that don't provide
vo_direct3d: deprecate direct3d_shaders alias And remove the difference between the aliases. This is needed to make the sub-option changes less painful.
2016-09-05 19:05:31 +00:00
proper OpenGL drivers, and where ANGLE does not perform well.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
``--vo-direct3d-disable-texture-align``
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
Normally texture sizes are always aligned to 16. With this option
enabled, the video texture will always have exactly the same size as
the video itself.
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
Debug options. These might be incorrect, might be removed in the future,
might crash, might cause slow downs, etc. Contact the developers if you
actually need any of these for performance or proper operation.
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-direct3d-force-power-of-2``
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
Always force textures to power of 2, even if the device reports
non-power-of-2 texture sizes as supported.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-direct3d-texture-memory=<mode>``
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
Only affects operation with shaders/texturing enabled, and (E)OSD.
vo_direct3d: fix texture-memory sub-option, extend it This sub-option was turned into a flag when the sub-option parser was changed to the generic one (probably accidentally). Turn it into a proper choice-option. Also, adjust what the options do. Though none of this probably makes much sense; the default should work, and if it doesn't, the GPU/driver is probably beyond help.
2014-11-18 15:30:24 +00:00
Possible values:
``default`` (default)
Use ``D3DPOOL_DEFAULT``, with a ``D3DPOOL_SYSTEMMEM`` texture for
locking. If the driver supports ``D3DDEVCAPS_TEXTURESYSTEMMEMORY``,
``D3DPOOL_SYSTEMMEM`` is used directly.
``default-pool``
Use ``D3DPOOL_DEFAULT``. (Like ``default``, but never use a
shadow-texture.)
``default-pool-shadow``
Use ``D3DPOOL_DEFAULT``, with a ``D3DPOOL_SYSTEMMEM`` texture for
locking. (Like ``default``, but always force the shadow-texture.)
``managed``
Use ``D3DPOOL_MANAGED``.
``scratch``
Use ``D3DPOOL_SCRATCH``, with a ``D3DPOOL_SYSTEMMEM`` texture for
locking.
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-direct3d-swap-discard``
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
Use ``D3DSWAPEFFECT_DISCARD``, which might be faster.
Might be slower too, as it must(?) clear every frame.
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-direct3d-exact-backbuffer``
manpage: document gl3, direct3d, portaudio, remove v4l2 The documentation is mostly taken from the help text embedded in the code of each output driver. vo_v4l2 and ao_v4l2 have been removed. Minor modifications to vo_xv, vo_directx and vo_gl.
2012-08-07 21:53:14 +00:00
Always resize the backbuffer to window size.
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``sdl``
vo/ao: SDL 1.2+ audio driver, SDL 2.0+ accelerated video driver This mainly serves as a fallback for platforms where nothing better is available; also as a debugging help. Both the audio and video driver are not first class - the audio driver lacks delay detection, and the video driver only supports a single YUV color space. Configure options: --disable-sdl2 to disable SDL 2.0+ detection, --disable-sdl to disable SDL 1.2+ detection. Both options need to be specified to turn off SDL support entirely.
2012-12-28 07:07:14 +00:00
SDL 2.0+ Render video output driver, depending on system with or without
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
hardware acceleration. Should work on all platforms supported by SDL 2.0.
For tuning, refer to your copy of the file ``SDL_hints.h``.
vo/ao: SDL 1.2+ audio driver, SDL 2.0+ accelerated video driver This mainly serves as a fallback for platforms where nothing better is available; also as a debugging help. Both the audio and video driver are not first class - the audio driver lacks delay detection, and the video driver only supports a single YUV color space. Configure options: --disable-sdl2 to disable SDL 2.0+ detection, --disable-sdl to disable SDL 1.2+ detection. Both options need to be specified to turn off SDL support entirely.
2012-12-28 07:07:14 +00:00
manpage: add notes when to use/not use certain AO and VO drivers
2014-04-19 13:29:05 +00:00
.. note:: This driver is for compatibility with systems that don't provide
manpage: minor fixes to VO manpage
2019-08-29 20:02:09 +00:00
proper graphics drivers.
manpage: add notes when to use/not use certain AO and VO drivers
2014-04-19 13:29:05 +00:00
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
``--sdl-sw``
vo_sdl: add a "sw" flag like in opengl Also, rework the renderer creation for the flag being generally effective even if the "SW renderer" is detected only after creating a context.
2013-01-04 16:43:37 +00:00
Continue even if a software renderer is detected.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--sdl-switch-mode``
video/out: remove video mode switching (--vm) This allowed making the player switch the monitor video mode when creating the video window. This was a questionable feature, and with today's LCD screens certainly not useful anymore. Switching to a random video mode (going by video width/height) doesn't sound too useful either. I'm not sure about the win32 implementation, but the X part had several bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any larger changes for a long time), this code is buggy and doesn't do the right thing anyway. (And what the hell _did_ it do when using multiple physical monitors?) If you really want this, write a shell script that calls xrandr before and after calling mpv. vo_sdl still can do mode switching, because SDL has native support for it, and using it is trivial. Add a new sub-option for this.
2013-02-24 22:36:40 +00:00
Instruct SDL to switch the monitor video mode when going fullscreen.
vo_vaapi_wayland: remove, as it is superceded by vo_dmabuf_wayland
2022-09-29 13:50:51 +00:00
``dmabuf-wayland``
Experimental Wayland output driver designed for use with either drm stateless
or VA API hardware decoding. The driver is designed to avoid any GPU to CPU copies,
and to perform scaling and color space conversion using fixed-function hardware,
if available, rather than GPU shaders. This frees up GPU resources for other tasks.
DOCS/vo: clarify dmabuf-wayland a bit Make it clearer that you should be using --hwdec with this VO. Also make some comments about the things that are required for this to work correctly (i.e. working drivers/GPU and the right compositor).
2023-07-22 21:01:14 +00:00
It is highly recommended to use this VO with the appropriate ``--hwdec`` option such
as ``auto-safe``. It can still work in some circumstances without ``--hwdec`` due to
mpv's internal conversion filters, but this is not recommended as it's a needless
extra step. Correct output depends on support from your GPU, drivers, and compositor.
Weston and wlroots-based compositors like Sway and Intel GPUs are known to generally
work.
vo: add new vaapi-wayland driver This driver makes use of dmabuffer and viewporter interfaces to enable efficient display of vaapi surfaces, avoiding any unnecessary colour space conversion, and avoiding scaling or colour conversion using GPU shader resources.
2022-05-18 14:35:53 +00:00
video: add vaapi decode and output support This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
2013-08-09 12:01:30 +00:00
``vaapi``
Intel VA API video output driver with support for hardware decoding. Note
manpage: discourage vo_vaapi further I don't know what's this comment about hardware decoding. Possibly it was written before vo_opengl had vaapi decoding support.
2017-02-17 20:01:59 +00:00
that there is absolutely no reason to use this, other than compatibility.
DOCS/options.rst DOCS/vo.rst: Update discussion of hwdec usage The documentation's current discussion of hwdec usage is out of date, and unnecessarily pessemistic when applied to modern hardware. The reality is that modern APIs on modern hardware produce reasonable results and there's no need to pretend otherwise. The current language that tries to drive people away from using hwdecs at all leads to them making bad choices when they do try to use it. Let's also make it clearer that users should use vo=gpu with hwdecs rather than vo=vaapi or vo=vdpau. Even the existing admonitions have proven insufficient, so let's strengthen that language.
2022-03-05 18:49:56 +00:00
This is low quality, and has issues with OSD. We strongly recommend that
you use ``--vo=gpu`` with ``--hwdec=vaapi`` instead.
manpage: add notes when to use/not use certain AO and VO drivers
2014-04-19 13:29:05 +00:00
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
``--vo-vaapi-scaling=<algorithm>``
video: add vaapi decode and output support This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
2013-08-09 12:01:30 +00:00
default
Driver default (mpv default as well).
fast
Fast, but low quality.
hq
Unspecified driver dependent high-quality scaling, slow.
nla
``non-linear anamorphic scaling``
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--vo-vaapi-scaled-osd=<yes|no>``
video: add vaapi decode and output support This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
2013-08-09 12:01:30 +00:00
If enabled, then the OSD is rendered at video resolution and scaled to
display resolution. By default, this is disabled, and the OSD is
rendered at display resolution if the driver supports it.
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``null``
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
Produces no video output. Useful for benchmarking.
vo_null: add framerate emulation
2015-05-24 13:48:48 +00:00
Usually, it's better to disable video with ``--no-video`` instead.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
``--vo-null-fps=<value>``
vo_null: add framerate emulation
2015-05-24 13:48:48 +00:00
Simulate display FPS. This artificially limits how many frames the
VO accepts per second.
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``caca``
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
Color ASCII art video output driver that works on a text console.
manpage: add notes when to use/not use certain AO and VO drivers
2014-04-19 13:29:05 +00:00
.. note:: This driver is a joke.
vo_tct: introduce modern caca alternative
2016-10-12 23:30:45 +00:00
``tct``
Color Unicode art video output driver that works on a text console.
DOCS/vo.rst: TCT: add note on interleaved output
2020-08-16 09:22:22 +00:00
By default depends on support of true color by modern terminals to display
DOCS: fix spelling
2021-08-24 16:00:05 +00:00
the images at full color range, but 256-colors output is also supported (see
DOCS/vo.rst: TCT: add note on interleaved output
2020-08-16 09:22:22 +00:00
below). On Windows it requires an ansi terminal such as mintty.
vo_tct: introduce modern caca alternative
2016-10-12 23:30:45 +00:00
sws_utils, zimg: destroy vo_x11 and vo_drm performance Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
2019-10-31 15:45:28 +00:00
Since mpv 0.30.0, you may need to use ``--profile=sw-fast`` to get decent
performance.
DOCS/vo.rst: TCT: add note on interleaved output
2020-08-16 09:22:22 +00:00
Note: the TCT image output is not synchronized with other terminal output
from mpv, which can lead to broken images. The options ``--no-terminal`` or
``--really-quiet`` can help with that.
vo_tct: introduce modern caca alternative
2016-10-12 23:30:45 +00:00
``--vo-tct-algo=<algo>``
Select how to write the pixels to the terminal.
half-blocks
Uses unicode LOWER HALF BLOCK character to achieve higher vertical
resolution. (Default.)
plain
Uses spaces. Causes vertical resolution to drop twofolds, but in
theory works in more places.
vo_tct: optional custom size, support non-posix with 80x25 default Also, replace the UTF8 half block char at the source code with C escape.
2016-10-21 23:38:32 +00:00
``--vo-tct-width=<width>`` ``--vo-tct-height=<height>``
Assume the terminal has the specified character width and/or height.
These default to 80x25 if the terminal size cannot be determined.
vo_tct: support also 256 colors output
2016-10-22 13:48:30 +00:00
``--vo-tct-256=<yes|no>`` (default: no)
Use 256 colors - for terminals which don't support true color.
vo_kitty: Introduce modern sixel alternative See https://sw.kovidgoyal.net/kitty/graphics-protocol/ This makes no attempt at querying terminal features or handling terminal errors, as it would require mpv to pass the response codes from the terminal to the vo instead of interpreting them as keystrokes made by the user and acting very unpredictably. Tested with kitty and konsole. Fixes #9605
2022-12-13 14:58:13 +00:00
``kitty``
Graphical output for the terminal, using the kitty graphics protocol.
Tested with kitty and Konsole.
You may need to use ``--profile=sw-fast`` to get decent performance.
Kitty size and alignment options:
``--vo-kitty-cols=<columns>``, ``--vo-kitty-rows=<rows>`` (default: 0)
Specify the terminal size in character cells, otherwise (0) read it
from the terminal, or fall back to 80x25.
``--vo-kitty-width=<width>``, ``--vo-kitty-height=<height>`` (default: 0)
Specify the available size in pixels, otherwise (0) read it from the
terminal, or fall back to 320x240.
``--vo-kitty-left=<col>``, ``--vo-kitty-top=<row>`` (default: 0)
Specify the position in character cells where the image starts (1 is
the first column or row). If 0 (default) then try to automatically
determine it according to the other values and the image aspect ratio
and zoom.
``--vo-kitty-config-clear=<yes|no>`` (default: yes)
Whether or not to clear the terminal whenever the output is
reconfigured (e.g. when video size changes).
``--vo-kitty-alt-screen=<yes|no>`` (default: yes)
Whether or not to use the alternate screen buffer and return the
terminal to its previous state on exit. When set to no, the last
kitty image stays on screen after quit, with the cursor following it.
``--vo-kitty-use-shm=<yes|no>`` (default: no)
Use shared memory objects to transfer image data to the terminal.
This is much faster than sending the data as escape codes, but is not
supported by as many terminals. It also only works on the local machine
and not via e.g. SSH connections.
This option is not implemented on Windows.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
``sixel``
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
Graphical output for the terminal, using sixels. Tested with ``mlterm`` and
``xterm``.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
vo_sixel: Make buffering optional It can be slower than unbuffered.
2022-12-20 09:06:49 +00:00
Note: the Sixel image output is not synchronized with other terminal
output from mpv, which can lead to broken images.
The option ``--really-quiet`` can help with that, and is recommended.
On some platforms, using the ``--vo-sixel-buffered`` option may work as
well.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
You may need to use ``--profile=sw-fast`` to get decent performance.
Note: at the time of writing, ``xterm`` does not enable sixel by default -
launching it as ``xterm -ti 340`` is one way to enable it. Also, ``xterm``
does not display images bigger than 1000x1000 pixels by default.
To render and align sixel images correctly, mpv needs to know the terminal
size both in cells and in pixels. By default it tries to use values which
the terminal reports, however, due to differences between terminals this is
an error-prone process which cannot be automated with certainty - some
terminals report the size in pixels including the padding - e.g. ``xterm``,
while others report the actual usable number of pixels - like ``mlterm``.
Additionally, they may behave differently when maximized or in fullscreen,
and mpv cannot detect this state using standard methods.
Sixel size and alignment options:
``--vo-sixel-cols=<columns>``, ``--vo-sixel-rows=<rows>`` (default: 0)
Specify the terminal size in character cells, otherwise (0) read it
from the terminal, or fall back to 80x25. Note that mpv doesn't use the
the last row with sixel because this seems to result in scrolling.
``--vo-sixel-width=<width>``, ``--vo-sixel-height=<height>`` (default: 0)
Specify the available size in pixels, otherwise (0) read it from the
terminal, or fall back to 320x240. Other than excluding the last line,
the height is also further rounded down to a multiple of 6 (sixel unit
height) to avoid overflowing below the designated size.
``--vo-sixel-left=<col>``, ``--vo-sixel-top=<row>`` (default: 0)
Specify the position in character cells where the image starts (1 is
the first column or row). If 0 (default) then try to automatically
determine it according to the other values and the image aspect ratio
and zoom.
``--vo-sixel-pad-x=<pad_x>``, ``--vo-sixel-pad-y=<pad_y>`` (default: -1)
Used only when mpv reads the size in pixels from the terminal.
Specify the number of padding pixels (on one side) which are included
at the size which the terminal reports. If -1 (default) then the number
of pixels is rounded down to a multiple of number of cells (per axis),
to take into account padding at the report - this only works correctly
when the overall padding per axis is smaller than the number of cells.
vo_sixel: Rename draw-clear -> config-clear
2022-12-20 09:29:49 +00:00
``--vo-sixel-config-clear=<yes|no>`` (default: yes)
Whether or not to clear the terminal whenever the output is
reconfigured (e.g. when video size changes).
vo_sixel: Add option to skip clear while drawing
2022-12-17 05:07:28 +00:00
vo_sixel: Alias/deprecate exit-clear -> alt-screen Also update documentation to reflect actual behavior.
2022-12-20 09:22:51 +00:00
``--vo-sixel-alt-screen=<yes|no>`` (default: yes)
Whether or not to use the alternate screen buffer and return the
terminal to its previous state on exit. When set to no, the last
sixel image stays on screen after quit, with the cursor following it.
``--vo-sixel-exit-clear`` is a deprecated alias for this option and
may be removed in the future.
vo_sixel: Make buffering optional It can be slower than unbuffered.
2022-12-20 09:06:49 +00:00
``--vo-sixel-buffered=<yes|no>`` (default: no)
Buffers the full output sequence before writing it to the terminal.
On POSIX platforms, this can help prevent interruption (including from
man/vo: Correct --vo-sixel-buffered
2022-12-20 10:10:28 +00:00
other applications) and thus broken images, but may come at a
man/vo: Typo
2022-12-20 10:12:23 +00:00
performance cost with some terminals and is subject to implementation
man/vo: Correct --vo-sixel-buffered
2022-12-20 10:10:28 +00:00
details.
vo_sixel: support --vo-sixel-exit-clear[=yes] By default we still clear the screen, but now it's possible to leave the last sixel image on screen. Allows mpv to be used as img2sixel of sorts, but with our auto-fit and various mpv scaling/filters etc.
2020-11-25 17:33:35 +00:00
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
Sixel image quality options:
``--vo-sixel-dither=<algo>``
Selects the dither algorithm which libsixel should apply.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
Can be one of the below list as per libsixel's documentation.
vo_sixel: change default dither to "auto" For two reasons: 1. It was counter intuitive that there's an "auto" value (which is actually a libsixel value and not an mpv one), but it's not the default value - our default was Atkinson. 2. "auto" provides better dithering than Atkinson with libsixel, which is especially noticeable with smooth gradients - where Atkinson has visible banding. In libsixel 1.8.2 the "auto" value maps to Atkinson if the output palette has up to 16 colors, or to Floyd-Steinberg otherwise (e.g. using fixed palette with 256 colors chooses Floyd-Steinberg).
2020-11-26 21:42:20 +00:00
auto (Default)
Let libsixel choose the dithering method.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
none
Don't diffuse
atkinson
vo_sixel: change default dither to "auto" For two reasons: 1. It was counter intuitive that there's an "auto" value (which is actually a libsixel value and not an mpv one), but it's not the default value - our default was Atkinson. 2. "auto" provides better dithering than Atkinson with libsixel, which is especially noticeable with smooth gradients - where Atkinson has visible banding. In libsixel 1.8.2 the "auto" value maps to Atkinson if the output palette has up to 16 colors, or to Floyd-Steinberg otherwise (e.g. using fixed palette with 256 colors chooses Floyd-Steinberg).
2020-11-26 21:42:20 +00:00
Diffuse with Bill Atkinson's method.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
fs
Diffuse with Floyd-Steinberg method
jajuni
Diffuse with Jarvis, Judice & Ninke method
stucki
Diffuse with Stucki's method
burkes
Diffuse with Burkes' method
arithmetic
Positionally stable arithmetic dither
xor
Positionally stable arithmetic xor based dither
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
``--vo-sixel-fixedpalette=<yes|no>`` (default: yes)
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
Use libsixel's built-in static palette using the XTERM256 profile
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
for dither. Fixed palette uses 256 colors for dithering. Note that
using ``no`` (at the time of writing) will slow down ``xterm``.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
``--vo-sixel-reqcolors=<colors>`` (default: 256)
vo_sixel: fix the image corruption with mlterm The issue was that we only uploaded the palette to the terminal when it changed (once on init with fixed palette, every frame with dynamic palette with trheshold=-1, only on scene change with threshold >= 0). Now we upload it on every frame, and it seems to fix the mlterm image corruption both with fixed palette and also with dynamic palette with threshold (i.e. at frames which did not upload a palette). It's not entirely clear why it's required with mlterm. It would seem that the palette which libsixel uses with fixed palette matches the built in default palette in xterm, but not in mlterm. With dynamic palette we can guess that mlterm resets the palette after a sixel image, but that's not confirmed. Uploading the palette on every frame doesn't seem to slow down xterm when using fixed palette - not clear yet why uploading a different palette (when using fixedpalette=no) slows it down while same palette on every frame doesn't. In mlterm there's no slowdown either way - and now also no corruption.
2020-11-26 21:25:07 +00:00
Has no effect with fixed palette. Set up libsixel to use required
number of colors for dynamic palette. This value depends on the
terminal emulator as well. Xterm supports 256 colors. Can set this to
a lower value for faster performance.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
``--vo-sixel-threshold=<threshold>`` (default: -1)
vo_sixel: fix the image corruption with mlterm The issue was that we only uploaded the palette to the terminal when it changed (once on init with fixed palette, every frame with dynamic palette with trheshold=-1, only on scene change with threshold >= 0). Now we upload it on every frame, and it seems to fix the mlterm image corruption both with fixed palette and also with dynamic palette with threshold (i.e. at frames which did not upload a palette). It's not entirely clear why it's required with mlterm. It would seem that the palette which libsixel uses with fixed palette matches the built in default palette in xterm, but not in mlterm. With dynamic palette we can guess that mlterm resets the palette after a sixel image, but that's not confirmed. Uploading the palette on every frame doesn't seem to slow down xterm when using fixed palette - not clear yet why uploading a different palette (when using fixedpalette=no) slows it down while same palette on every frame doesn't. In mlterm there's no slowdown either way - and now also no corruption.
2020-11-26 21:25:07 +00:00
Has no effect with fixed palette. Defines the threshold to change the
vo_sixel: Add aspect ratio based output centering Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
2020-11-12 10:37:33 +00:00
palette - as percentage of the number of colors, e.g. 20 will change
the palette when the number of colors changed by 20%. It's a simple
measure to reduce the number of palette changes, because it can be slow
vo_sixel: fix the image corruption with mlterm The issue was that we only uploaded the palette to the terminal when it changed (once on init with fixed palette, every frame with dynamic palette with trheshold=-1, only on scene change with threshold >= 0). Now we upload it on every frame, and it seems to fix the mlterm image corruption both with fixed palette and also with dynamic palette with threshold (i.e. at frames which did not upload a palette). It's not entirely clear why it's required with mlterm. It would seem that the palette which libsixel uses with fixed palette matches the built in default palette in xterm, but not in mlterm. With dynamic palette we can guess that mlterm resets the palette after a sixel image, but that's not confirmed. Uploading the palette on every frame doesn't seem to slow down xterm when using fixed palette - not clear yet why uploading a different palette (when using fixedpalette=no) slows it down while same palette on every frame doesn't. In mlterm there's no slowdown either way - and now also no corruption.
2020-11-26 21:25:07 +00:00
in some terminals (``xterm``). The default (-1) will choose a palette
on every frame and will have better quality.
video/out/vo_sixel.c: Implement sixel as a output device Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
2020-11-01 11:13:31 +00:00
manpage: proofread and fix formatting
2013-07-08 16:02:14 +00:00
``image``
manpage: reflect recent VO changes
2012-08-06 17:15:04 +00:00
Output each frame into an image file in the current directory. Each file
manpage: merge new manpage About a year ago, ubitux converted most of the old manpage from the hard to maintain nroff format to reStructuredText. This was not merged back into the master repository immediately. The argument was that the new manpage still required work to be done. However, progress was very slow. Even worse: the old manpage wasn't updated, because it was scheduled for deletion, and updating it would have meant useless work. Now the situation is that the new manpage still isn't finished, and the old manpage is grossly out of sync with the player. This is not helpful for users. Additionally, keeping the new manpage in a separate branch, while the normal development repository for code had the old manpage, was very inconvenient, because you couldn't just update the documentation in the same commit as the code. Even though the new manpage isn't finished yet, merging it now seems to be the best course of action. Squash-merge the manpage development branch [1], revision e89f5dd3f2, which branches from the mplayer2 master branch after revision 159102e0cb. Committers: * Clément Bœsch <ubitux@gmail.com> (Initial conversion to RST.) * Uoti Urpala <uau@mplayer2.org> (Many updates.) * Myself (Minor edits.) Most text of the manpage has been directly taken from the old manpage, because this is a conversion, not a complete rewrite. [1] http://git.mplayer2.org/uau/mplayer2.git/log/?h=man
2012-08-02 19:37:33 +00:00
takes the frame number padded with leading zeros as name.
vo_image: move to global options This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
2016-09-05 19:04:55 +00:00
The following global options are supported by this video output:
``--vo-image-format=<format>``
manpage: reflect recent VO changes
2012-08-06 17:15:04 +00:00
Select the image file format.
jpg
manpage: various fixes
2012-11-15 13:25:20 +00:00
JPEG files, extension .jpg. (Default.)
manpage: reflect recent VO changes
2012-08-06 17:15:04 +00:00
jpeg
JPEG files, extension .jpeg.
png
PNG files.
image_writer: add WebP support (lossy or lossless)
2019-09-14 20:18:02 +00:00
webp
WebP files.
manpage: reflect recent VO changes
2012-08-06 17:15:04 +00:00
vo_image: move to global options This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
2016-09-05 19:04:55 +00:00
``--vo-image-png-compression=<0-9>``
manpage: reflect recent VO changes
2012-08-06 17:15:04 +00:00
PNG compression factor (speed vs. file size tradeoff) (default: 7)
vo_image: move to global options This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
2016-09-05 19:04:55 +00:00
``--vo-image-png-filter=<0-5>``
image_writer: Add PNG filter option (default "mixed") The use of filters prior to PNG compression can greatly improve compression ratio, with "mixed" (ImageMagick calls it "adaptive") typically achieving the best results.
2013-06-15 13:14:06 +00:00
Filter applied prior to PNG compression (0 = none; 1 = sub; 2 = up;
3 = average; 4 = Paeth; 5 = mixed) (default: 5)
vo_image: move to global options This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
2016-09-05 19:04:55 +00:00
``--vo-image-jpeg-quality=<0-100>``
manpage: update default jpeg quality for vo_image
2012-08-23 12:12:30 +00:00
JPEG quality factor (default: 90)
vo_image: move to global options This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
2016-09-05 19:04:55 +00:00
``--vo-image-jpeg-optimize=<0-100>``
manpage: fix various typos
2012-08-22 13:45:34 +00:00
JPEG optimization factor (default: 100)
image_writer: add WebP support (lossy or lossless)
2019-09-14 20:18:02 +00:00
``--vo-image-webp-lossless=<yes|no>``
Enable writing lossless WebP files (default: no)
``--vo-image-webp-quality=<0-100>``
WebP quality (default: 75)
image_writer: add webp-compression option
2019-08-02 14:04:54 +00:00
``--vo-image-webp-compression=<0-6>``
WebP compression factor (default: 4)
vo_image: move to global options This is a bit "special", because the config tree wants unique m_sub_options pointers in the whole thing.
2016-09-05 19:04:55 +00:00
``--vo-image-outdir=<dirname>``
manpage: reflect recent VO changes
2012-08-06 17:15:04 +00:00
Specify the directory to save the image files to (default: ``./``).
wayland: shm based software rendering A wayland output based on shared memory. This video output is useful for x11 free systems, because the current libGL in mesa provides GLX symbols. It is also useful for embedded systems where the wayland backend for EGL is not implemented like the raspberry pi. At the moment only rgb formats are supported, because there is still no compositor which supports planar formats like yuv420p. The most used compositor at the moment, weston, supports only BGR0, BGRA and BGR16 (565). The BGR16 format is the fastest to convert and render without any noticeable differences to the BGR32 formats. For this reason the current (very basic) auto-detection code will prefer the BGR16 format. Also the weston source code indicates that the preferred format is BGR16 (RGB565). There are 2 options: * default-format (yes|no) Which uses the BGR32 format * alpha (yes|no) For outputting images and videos with transparencies
2013-04-15 20:37:02 +00:00
client API: deprecate opengl-cb API and introduce a replacement API The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
2018-02-20 12:30:18 +00:00
``libmpv``
manpage: rename OS X references to macOS Apple has decided that Mac OS X is now named macOS for the time being. For consistency, it makes sense to use the same name for the operating system in all places where it occurs. This commit renames OS X to macOS in the documentation in places where it was otherwise still using the old name.
2021-01-01 23:53:23 +00:00
For use with libmpv direct embedding. As a special case, on macOS it
cocoa-cb: initial implementation via opengl-cb API this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
2018-02-12 11:28:19 +00:00
is used like a normal VO within mpv (cocoa-cb). Otherwise useless in any
other contexts.
client API: deprecate opengl-cb API and introduce a replacement API The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
2018-02-20 12:30:18 +00:00
(See ``<mpv/render.h>``.)
vo_opengl_cb: introduce frame queue The previous implementation of opengl-cb kept only latest flipped frame. This can cause massive frame drops because rendering is done asynchronously and only the latest frame can be rendered. This commit introduces frame queue and releated options to opengl-cb. frame-queue-size: the maximum size of frame queue (1-100, default: 1) frame-drop-mode: behavior when frame queue is full (pop, clear, default: pop) The frame queue holds delayed frames and drops frames if the frame queue is overflowed with next method: 'pop' mode: drops all the oldest frames overflown. 'clear' mode: drops all frames in queue and clear it. With default options(frame-queue-size=1:frame-drop-mode=pop), opengl-cb behaves in the same way as previous implementation effectively. For frame-queue-size > 1, opengl-cb tries to calls update() without waiting next flip_page() in order to consume queued frames. Signed-off-by: wm4 <wm4@nowhere>
2015-01-08 16:06:17 +00:00
client API: deprecate opengl-cb API and introduce a replacement API The purpose of the new API is to make it useable with other APIs than OpenGL, especially D3D11 and vulkan. In theory it's now possible to support other vo_gpu backends, as well as backends that don't use the vo_gpu code at all. This also aims to get rid of the dumb mpv_get_sub_api() function. The life cycle of the new mpv_render_context is a bit different from mpv_opengl_cb_context, and you explicitly create/destroy the new context, instead of calling init/uninit on an object returned by mpv_get_sub_api(). In other to make the render API generic, it's annoyingly EGL style, and requires you to pass in API-specific objects to generic functions. This is to avoid explicit objects like the internal ra API has, because that sounds more complicated and annoying for an API that's supposed to never change. The opengl_cb API will continue to exist for a bit longer, but internally there are already a few tradeoffs, like reduced thread-safety. Mostly untested. Seems to work fine with mpc-qt.
2018-02-20 12:30:18 +00:00
This also supports many of the options the ``gpu`` VO has, depending on the
backend.
RPI support This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
2015-03-29 13:12:11 +00:00
``rpi`` (Raspberry Pi)
Native video output on the Raspberry Pi using the MMAL API.
DOCS/vo: remove some dated deprecation warnings about --vo=rpi Very amusingly, the manual previously said "The rpi VO will be removed in mpv 0.23.0." Obviously, this didn't happen. It looks like wm4 changed his mind on this with 51fd8f6fe16ef0a8fa35aec89cab82d435e4d4d9, but never updated the docs. What was the problem? Who knows but allegedly there are people that use --vo=rpi (it's supposed to work at least). Actually context_rpi is probably broken since wm4 changed fullscreen handling in 59cdfe50b261e06bdf04d2f7e2e18f6c19cbb26d and no one ever bothered to fix it after that commit. In fact, that's the last commit that touched that particular file. Someone did actually fix vo_rpi after that so that one probably works at least. Anyways, I wouldn't mind just deleting all rpi stuff, but there's probably some people out there that use it so whatever. Remove the outdated deprecated language in the documentation and just accept that we support this unfortunately.
2023-09-20 02:29:47 +00:00
The following global options are supported by this video output:
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--rpi-display=<number>``
RPI support This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
2015-03-29 13:12:11 +00:00
Select the display number on which the video overlay should be shown
(default: 0).
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--rpi-layer=<number>``
RPI support This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
2015-03-29 13:12:11 +00:00
Select the dispmanx layer on which the video overlay should be shown
(default: -10). Note that mpv will also use the 2 layers above the
selected layer, to handle the window background and OSD. Actual video
rendering will happen on the layer above the selected layer.
vo_drm: add missing documentation
2015-04-16 19:43:01 +00:00
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--rpi-background=<yes|no>``
vo_rpi: disable background by default And add an option to enable it.
2015-08-20 17:07:18 +00:00
Whether to render a black background behind the video (default: no).
Normally it's better to kill the console framebuffer instead, which
gives better performance.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
``--rpi-osd=<yes|no>``
vo_rpi: add an option to disable OSD The OSD takes up an entire fullscreen dispmanx layer. Although the GPU should be able to handle it (possibly even without any disadvantages), it'll still be useful for debugging performance issues.
2015-11-25 21:06:17 +00:00
Enabled by default. If disabled with ``no``, no OSD layer is created.
This also means there will be no subtitles rendered.
vo_drm: add missing documentation
2015-04-16 19:43:01 +00:00
``drm`` (Direct Rendering Manager)
Video output driver using Kernel Mode Setting / Direct Rendering Manager.
vo_opengl: add DRM EGL backend Notes: - Unfortunately the only way to talk to EGL from within DRM I could find involves linking with GBM (generic buffer management for Mesa.) Because of this, I'm pretty sure it won't work with proprietary NVidia drivers, but then again, last time I checked NVidia didn't offer proper screen resolution for VT. - VT switching doesn't seem to work at all. It's worth mentioning that using vo_drm before introduction of VT switcher had an anomaly where user could switch to another VT and input text to it, while video played on top of that VT. However, that isn't the case with drm_egl: I can't switch to other VT during playback like this. This makes me think that it's either a limitation coming from my firmware or from EGL/KMS itself rather than a bug with my code. Nonetheless, I still left (untestable) VT switching code in place, in case it's useful to someone else. - The mode_id, connector_id and device_path should be configurable for power users and people who wish to watch videos on nonprimary screen. Unfortunately I didn't see anything that would allow OpenGL backends to register their own set of options. At the same time, adding them to global namespace is pointless. - A few dozens of lines could be shared with vo_drm (setting up VT switching, most of code behind page flipping). I don't have any strong opinion on this. - Sometimes I get minor visual glitches. I'm not sure if there's a race condition of some sort, unitialized variable (doubtful), or if it's buggy driver. (I'm using integrated Intel HD Graphics 4400 with Mesa) - .config and .control are very minimal. Signed-off-by: wm4 <wm4@nowhere>
2015-11-07 18:06:57 +00:00
Should be used when one doesn't want to install full-blown graphical
environment (e.g. no X). Does not support hardware acceleration (if you
manpage: update references to gpu VO
2018-01-09 12:20:37 +00:00
need this, check the ``drm`` backend for ``gpu`` VO).
vo_drm: add missing documentation
2015-04-16 19:43:01 +00:00
sws_utils, zimg: destroy vo_x11 and vo_drm performance Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
2019-10-31 15:45:28 +00:00
Since mpv 0.30.0, you may need to use ``--profile=sw-fast`` to get decent
performance.
options: deprecate suboptions for the remaining AO/VOs
2016-09-05 19:07:03 +00:00
The following global options are supported by this video output:
vo_drm: change CLI options + refactors - Change connector selection to accept human readable names (such as eDP-1, HDMI-A-2) rather than arbitrary numbers. - Change GPU selection to accept GPU number rather than device paths. - Merge connector and GPU selection into one --drm-connector. - Add support for --drm-connector=help. - Add support for --drm-* in EGL backend. - Refactor KMS; reduce state sharing across drm_common.
2016-10-04 20:07:19 +00:00
``--drm-connector=[<gpu_number>.]<name>``
Select the connector to use (usually this is a monitor.) If ``<name>``
is empty or ``auto``, mpv renders the output on the first available
drm_common: Add proper help option to drm-mode This was implemented by using OPT_STRING_VALIDATE for drm-mode, instead of OPT_INT. Using a string here also prepares for future additions to drm-mode that aim to allow specifying a mode by its resolution.
2018-06-02 10:53:58 +00:00
connector. Use ``--drm-connector=help`` to get a list of available
drm_common: enable specific device selection by means of path
2021-01-22 21:07:38 +00:00
connectors. The ``<gpu_number>`` argument can be used to disambiguate
multiple graphic cards, but is deprecated in favor of ``--drm-device``.
(default: empty)
``--drm-device=<path>``
Select the DRM device file to use. If specified this overrides automatic
card selection and any card number specified ``--drm-connector``.
vo_drm: change CLI options + refactors - Change connector selection to accept human readable names (such as eDP-1, HDMI-A-2) rather than arbitrary numbers. - Change GPU selection to accept GPU number rather than device paths. - Merge connector and GPU selection into one --drm-connector. - Add support for --drm-connector=help. - Add support for --drm-* in EGL backend. - Refactor KMS; reduce state sharing across drm_common.
2016-10-04 20:07:19 +00:00
(default: empty)
vo_drm: Expose mode ID option to users
2015-05-28 18:53:14 +00:00
drm_common: Support --drm-mode=<preferred|highest|N|WxH[@R]> This allows to select the drm mode using a string specification. You can either select the the preferred mode, the mode with the highest resolution, by specifying WxH[@R] or by its index in the list of modes as before.
2018-06-05 07:15:54 +00:00
``--drm-mode=<preferred|highest|N|WxH[@R]>``
Mode to use (resolution and frame rate).
Possible values:
:preferred: Use the preferred mode for the screen on the selected
connector. (default)
:highest: Use the mode with the highest resolution available on the
selected connector.
:N: Select mode by index.
:WxH[@R]: Specify mode by width, height, and optionally refresh rate.
In case several modes match, selects the mode that comes
first in the EDID list of modes.
Use ``--drm-mode=help`` to get a list of available modes for all active
connectors.
vo_opengl: deprecate sub-options, add them as global options vo_opengl sub-option were always rather annoying to handle. It seems better to make them global options instead. This is simpler and easier to use. The only disadvantage we are aware of is that it's not clear that many/all of these new global options work with vo_opengl only. --vo=opengl-hq is also deprecated. There is extensive compatibility with the old behavior. One exception is that --vo-defaults will not apply to opengl-hq (though with opengl it still works). vo-cmdline is also dysfunctional and will be removed in a following commit. These changes also affect opengl-cb. The update mechanism is still rather inefficient: it requires syncing with the VO after each option change, rather than batching updates. There's also no granularity (video.c just updates "everything", and if auto-ICC profiles are enabled, vo_opengl.c will fetch them on each update). Most of the manpage changes were done by Niklas Haas <git@haasn.xyz>.
2016-09-02 13:59:40 +00:00
drm: rename plane options to better, invariant, names This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
2018-12-01 11:01:17 +00:00
``--drm-draw-plane=<primary|overlay|N>``
Select the DRM plane to which video and OSD is drawn to, under normal
circumstances. The plane can be specified as ``primary``, which will
pick the first applicable primary plane; ``overlay``, which will pick
the first applicable overlay plane; or by index. The index is zero
based, and related to the CRTC.
drm_atomic: Add general primary/overlay plane option Add general primary/overlay plane option to drm-osd-plane-id and drm-video-plane-id, so that the user can just request any usable primary or overlay plane for either of these two options. This should be somewhat more user-friendly (especially as neither of these two options currently have a useful help function), as usually you would only be interested in the type of the plane, and not exactly which plane gets picked.
2018-06-02 10:54:05 +00:00
(default: primary)
vo_gpu/hwdec: rename and introduce legacy names for some interops We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
2022-08-27 16:53:31 +00:00
When using this option with the drmprime-overlay hwdec interop, only the
OSD is rendered to this plane.
drm: rename plane options to better, invariant, names This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
2018-12-01 11:01:17 +00:00
``--drm-drmprime-video-plane=<primary|overlay|N>``
vo_gpu/hwdec: rename and introduce legacy names for some interops We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
2022-08-27 16:53:31 +00:00
Select the DRM plane to use for video with the drmprime-overlay hwdec
drm: rename plane options to better, invariant, names This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
2018-12-01 11:01:17 +00:00
interop (used by e.g. the rkmpp hwdec on RockChip SoCs, and v4l2 hwdec:s
on various other SoC:s). The plane is unused otherwise. This option
accepts the same values as ``--drm-draw-plane``. (default: overlay)
To be able to successfully play 4K video on various SoCs you might need
to set ``--drm-draw-plane=overlay --drm-drmprime-video-plane=primary``
and setting ``--drm-draw-surface-size=1920x1080``, to render the OSD at a
lower resolution (the video when handled by the hwdec will be on the
drmprime-video plane and at full 4K resolution)
drm/atomic: refactor planes names We are currently using primary / overlay planes drm objects, assuming that primary plane is osd and overlay plane is video. This commit is doing two things : - replace the primary / overlay planes members with osd and video planes member without the assumption - Add two more options to determine which one of the primary / overlay is associated to osd / video. - It will default osd to overlay and video to primary if unspecified
2018-04-29 15:46:23 +00:00
manpage: minor fix to --drm-format Looking at other examples, a bar should be used when listing OPT_CHOICE options.
2018-09-05 11:42:31 +00:00
``--drm-format=<xrgb8888|xrgb2101010>``
context_drm_egl: Introduce 30bpp support This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
2018-02-13 17:40:47 +00:00
Select the DRM format to use (default: xrgb8888). This allows you to
choose the bit depth of the DRM mode. xrgb8888 is your usual 24 bit per
pixel/8 bits per channel packed RGB format with 8 bits of padding.
xrgb2101010 is a packed 30 bits per pixel/10 bits per channel packed RGB
format with 2 bits of padding.
vo_drm: 30bpp support
2018-02-19 18:23:44 +00:00
There are cases when xrgb2101010 will work with the ``drm`` VO, but not
with the ``drm`` backend for the ``gpu`` VO. This is because with the
``gpu`` VO, in addition to requiring support in your DRM driver,
requires support for xrgb2101010 in your EGL driver
context_drm_egl: Introduce 30bpp support This introduces the option --drm-format (currently used only by context_drm_egl, vo_drm implementation is pending) which allows you to pick between a xrgb8888 or a xrgb2101010 visual for --gpu-context=drm. Requires a recent mesa (18.0.0_rc4 or later) to work. This also fixes a bug when using --gpu-context=drm on a 30bpp-enabled mesa (allow_rgb10_configs set to true). Previously it would've set up an XRGB8888 format at the DRM/GBM level, while a 30bpp EGLConfig would be picked, resulting in a garbled image.
2018-02-13 17:40:47 +00:00
drm: rename plane options to better, invariant, names This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
2018-12-01 11:01:17 +00:00
``--drm-draw-surface-size=<[WxH]>``
Sets the size of the surface used on the draw plane. The surface will
then be upscaled to the current screen resolution. This option can be
vo_gpu/hwdec: rename and introduce legacy names for some interops We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
2022-08-27 16:53:31 +00:00
useful when used together with the drmprime-overlay hwdec interop at
high resolutions, as it allows scaling the draw plane (which in this
case only handles the OSD) down to a size the GPU can handle.
drm: rename plane options to better, invariant, names This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
2018-12-01 11:01:17 +00:00
vo_gpu/hwdec: rename and introduce legacy names for some interops We've had some annoying names for interops, which we can't simply rename because that would break config files and command lines. So we need to put a little more effort in and add a concept of legacy names that allow us to continue loading them, but with a warning. The two I'm renaming here are: * vaapi-egl -> vaapi (vaapi works with Vulkan too) * drmprime-drm -> drmprime-overlay (actually describes what it does) * cuda-nvdec -> cuda (cuda interop is not nvdec specific)
2022-08-27 16:53:31 +00:00
When used without the drmprime-overlay hwdec interop this option will
just cause the video to get rendered at a different resolution and then
drm: rename plane options to better, invariant, names This commit bumps the libmpv version to 1.102 drm-osd-plane -> drm-draw-plane drm-video-plane -> drm-drmprime-video-plane drm-osd-size -> drm-draw-surface-size "draw plane", as in the plane that OpenGL draws to, whether it be video + OSD or just OSD. "drmprime video plane", as in the plane used for hwdec video imported via drmprime. "draw surface size", as in the size of the surface used for the draw plane The new names are invariant whether or not hwdec_drmprime_drm is being used or not. The original naming was very confusing, as when doing regular rendering (swdec or vaapi) the video would be displayed on the "OSD plane", and the "Video plane" would remain unused.
2018-12-01 11:01:17 +00:00
scaled to screen size.
drm/atomic: refactor hwdec_drmprime_drm with native resources That new API was introduced and allows to have several native resources. Thisuses that mechanisma for drm resources rather than the deprecated opengl-cb structs. This patch therefore add two structs that can be used with the drm atomic interop. - mpv_opengl_drm_params : which will hold all the drm handles - mpv_opengl_drm_osd_size : which will hold osd layer size This commit adds a drm-osd-size=WxH parameter to commandline which allows to define the OSD plane dimension. OSD can be upscaled to screen resolution when having OSD at video resolution is too heavy. This is especially useful for UHD modes on embedded devices where the GPU cannot handle UHD modes at a decent framerate.
2018-04-29 13:09:16 +00:00
(default: display resolution)
drm: context_drm_egl: add support for enabling VRR Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used with DRM by setting the VRR_ENABLED property on a crtc if the connector reports that it is VRR_CAPABLE. This is a useful feature for us as it is common to play 24/25/50 fps content on displays that are nominally locked to 60Hz. VRR can allow this content to play at native framerates. This is a simple change as we just need to check the capability and set the enabled property if requested by the user. I've defaulted it to disabled for now, but it might make sense to default to auto in the long term.
2022-04-04 03:08:33 +00:00
``--drm-vrr-enabled=<no|yes|auto>``
various: fix typos
2022-04-25 11:27:18 +00:00
Toggle use of Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync
drm: context_drm_egl: add support for enabling VRR Variable Refresh Rate (VRR), aka Freesync or Adaptive Sync can be used with DRM by setting the VRR_ENABLED property on a crtc if the connector reports that it is VRR_CAPABLE. This is a useful feature for us as it is common to play 24/25/50 fps content on displays that are nominally locked to 60Hz. VRR can allow this content to play at native framerates. This is a simple change as we just need to check the capability and set the enabled property if requested by the user. I've defaulted it to disabled for now, but it might make sense to default to auto in the long term.
2022-04-04 03:08:33 +00:00
on compatible systems. VRR allows for the display to be refreshed at any
rate within a range (usually ~40Hz-60Hz for 60Hz displays). This can help
with playback of 24/25/50fps content. Support depends on the use of a
compatible monitor, GPU, and a sufficiently new kernel with drivers
that support the feature.
:no: Do not attempt to enable VRR. (default)
:yes: Attempt to enable VRR, whether the capability is reported or not.
:auto: Attempt to enable VRR if support is reported.
vo: add mediacodec_embed output driver Allows rendering IMGFMT_MEDIACODEC frames directly onto an android.view.Surface
2017-07-06 17:58:26 +00:00
``mediacodec_embed`` (Android)
Renders ``IMGFMT_MEDIACODEC`` frames directly to an ``android.view.Surface``.
Requires ``--hwdec=mediacodec`` for hardware decoding, along with
``--vo=mediacodec_embed`` and ``--wid=(intptr_t)(*android.view.Surface)``.
Since this video output driver uses native decoding and rendering routines,
many of mpv's features (subtitle rendering, OSD/OSC, video filters, etc)
are not available with this driver.
vo_gpu: add android opengl backend At the moment, rendering on Android requires ``--vo=opengl-cb`` and a lot of java<->c++ bridging code to receive the receive and react to the render callback in java. Performance also suffers with opengl-cb, due to the overhead of context switching in JNI. With this patch, Android can render using ``--vo=gpu --gpu-context=android`` (after setting ``--wid`` to point to an android.view.Surface on-screen).
2017-10-05 18:58:37 +00:00
vo_gpu: hwdec: add Android hwdec utilizing AImageReader
2021-10-18 14:50:39 +00:00
To use hardware decoding with ``--vo=gpu`` instead, use ``--hwdec=mediacodec``
or ``mediacodec-copy`` along with ``--gpu-context=android``.
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
``wlshm`` (Wayland only)
Shared memory video output driver without hardware acceleration that works
whenever Wayland is present.
sws_utils, zimg: destroy vo_x11 and vo_drm performance Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
2019-10-31 15:45:28 +00:00
Since mpv 0.30.0, you may need to use ``--profile=sw-fast`` to get decent
performance.
Reintroduce vo_wayland as vo_wlshm vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
2018-08-27 20:06:38 +00:00
.. note:: This is a fallback only, and should not be normally used.