summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorPhilip Langdale <philipl@overt.org>2016-09-10 20:12:27 -0700
committerwm4 <wm4@nowhere>2016-09-11 10:46:22 +0200
commit3f7e43c2e2658eb8a1a22cc4e7359392ec70dc3b (patch)
tree761336d58bb5928690232f5a918dc986a5bc22d1 /DOCS
parent71681e04ee956a64f2d6e067f3540ea918a16b61 (diff)
downloadmpv-3f7e43c2e2658eb8a1a22cc4e7359392ec70dc3b.tar.bz2
mpv-3f7e43c2e2658eb8a1a22cc4e7359392ec70dc3b.tar.xz
hwdec_cuda: Add trivial cuda-copy wrapper
The cuvid decoder already knows how to copy back to system memory if NV12 frames are requested, and this will happen if the decoder is used without the hwdec. For convenience, let's add a wrapper hwdec so people don't have to explicitly pick the cuvid decoder if they want this behaviour.
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/man/options.rst13
1 files changed, 9 insertions, 4 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index fc52f3f33e..8e97c87c67 100644
--- a/DOCS/man/options.rst
+++ b/DOCS/man/options.rst
@@ -607,6 +607,7 @@ Video
:mediacodec: copies video back to system RAM (Android only)
:rpi: requires ``--vo=rpi`` (Raspberry Pi only - default if available)
:cuda: requires ``--vo=opengl`` (Any platform CUDA is available)
+ :cuda-copy: copies video back to system RAM (Any platform CUDA is available)
``auto`` tries to automatically enable hardware decoding using the first
available method. This still depends what VO you are using. For example,
@@ -678,10 +679,14 @@ Video
affect this additionally. This can give incorrect results even with
completely ordinary video sources.
- ``cuda`` is usually safe. However, it will usually not fallback cleanly
- for unsupported profiles of otherwise supported codecs - most obviously,
- this is the case for 10bit H.264 content. 10bit HEVC is currently not
- supported but we can add support after CUDA 8 is released.
+ ``cuda`` is usually safe. Interlaced content will be weaved by the
+ decoder, and it may not be possible for a deinterlacing filter to
+ do anything useful with this. 10bit HEVC is currently not
+ supported but maybe we can add support after CUDA 8 is released (and
+ it will be rounded down to 8 bits).
+
+ ``cuda-copy`` has the same limitations as ``cuda`` - particularly
+ its handling of deinterlacing.
All other methods, in particular the copy-back methods (like
``dxva2-copy`` etc.) are either fully safe, or not worse than software