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 /options/m_property.h | |
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 'options/m_property.h')
0 files changed, 0 insertions, 0 deletions