diff options
author | wm4 <wm4@nowhere> | 2017-01-13 13:36:02 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-01-13 18:43:35 +0100 |
commit | 812128bab7d14e92d778d97fd34b9f97bd07acc5 (patch) | |
tree | a2870d87990920ed05c25276d7d721b55e215d91 /video/vdpau_functions.inc | |
parent | d9376fc86ffec26f134e89293a4342c4b99f0e5b (diff) | |
download | mpv-812128bab7d14e92d778d97fd34b9f97bd07acc5.tar.bz2 mpv-812128bab7d14e92d778d97fd34b9f97bd07acc5.tar.xz |
vo_opengl, vaapi: properly probe 10 bit rendering support
There are going to be users who have a Mesa installation which do not
support 10 bit, but a GPU which can decode to 10 bit. So it's probably
better not to hardcode whether it is supported.
Introduce a more general way to signal supported formats from renderer
to decoder. Obviously this is imperfect, because it still isn't part of
proper format negotation (for example, what if there's a vavpp filter,
which accepts anything). Still slightly better than before.
I don't know any way to probe for vaapi dmabuf/EGL dmabuf support
properly (in particular testing specific formats, not just general
availability). So we stay with the current approach and try to create
and map dummy surfaces on init to probe for support. Overdo it and check
all formats that AVHWFramesConstraints reports, instead of only NV12 and
P010 surfaces.
Since we can support unknown formats now, add explicitly checks to the
EGL/dmabuf mapper code to reject unsupported formats. I also noticed
that libavutil signals support for RGB0/BGR0, but couldn't get it to
work. Remove the DRM formats that are unused/didn't work the way I tried
to use them.
With this, 10 bit decoding + rendering should work, provided you have
a capable CPU and a patched Mesa. The required Mesa patch adds support
for the R16 and GR32 formats. It was sent by a Kodi developer to the
Mesa developer mailing list and was not accepted yet.
Diffstat (limited to 'video/vdpau_functions.inc')
0 files changed, 0 insertions, 0 deletions