diff options
| author | wm4 <wm4@nowhere> | 2016-06-19 19:58:40 +0200 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2016-06-19 19:58:40 +0200 |
| commit | 7be37337f4ceb5dd663f287f1601f704d3d42d73 (patch) | |
| tree | a1ab57ebc206aeb157056f8365db6592e35d8551 /DOCS/man/options.rst | |
| parent | 754ad1d7307a63fc580bebb485fff2ddda02b4c9 (diff) | |
| download | mpv-7be37337f4ceb5dd663f287f1601f704d3d42d73.tar.bz2 mpv-7be37337f4ceb5dd663f287f1601f704d3d42d73.tar.xz | |
vo_opengl: vdpau interop without RGB conversion
Until now, we've always converted vdpau video surfaces to RGB, and then
mapped the resulting RGB texture. Change this so that the surface is
mapped as NV12 plane textures.
The reason this wasn't done until now is because vdpau surfaces are
mapped in an "interlaced" way as separate fields, even for progressive
video. This requires messy reinterleraving. It turns out that even
though it's an extra processing step, the result can be faster than
going through the video mixer for RGB conversion.
Other than some potential speed-gain, doing this has multiple other
advantages. We can apply our own color conversion, which is important in
more complex cases. We can correctly apply debanding and potentially
other processing that requires chroma-specific or in-YUV handling.
If deinterlacing is enabled, this switches back to the old RGB
conversion method. Until we have at least a primitive deinterlacer in
vo_opengl, this will stay this way. The d3d11 and vaapi code paths are
similar. (Of course these don't require any crazy field reinterleaving.)
Diffstat (limited to 'DOCS/man/options.rst')
| -rw-r--r-- | DOCS/man/options.rst | 9 |
1 files changed, 6 insertions, 3 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index a8d118023e..a42d87912b 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -641,9 +641,12 @@ Video not display correctly, and not certain filtering (such as debanding) can not be applied in an ideal way. - ``vdpau`` forces RGB conversion. Currently, it does not treat certain - colorspaces like BT.2020 correctly. This is mostly a mpv-specific - restriction. This does not apply if the ``vdpauprb`` filter is used. + ``vdpau`` is usually safe. If deinterlacing enabled (or the ``vdpaupp`` + video filter is active in general), it forces RGB conversion. The latter + currently does not treat certain colorspaces like BT.2020 correctly + (which is mostly a mpv-specific restriction). If the ``vdpauprb`` + retrieves image data without RGB conversion, but does not work with + postprocessing. ``vaapi`` is safe if the ``vaapi-egl`` backend is indicated in the logs. If ``vaapi-glx`` is indicated, and the video colorspace is either BT.601 |