summaryrefslogtreecommitdiffstats
path: root/video/out/gpu/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2017-09-30 16:20:37 +0200
committerwm4 <wm4@nowhere>2017-09-30 16:22:16 +0200
commit5597db7081b9420e0305c717435b18c71e72cb02 (patch)
tree56f1862d50ae389ab790cb97b956ac28419f2a13 /video/out/gpu/video.c
parentf3512686eee6c1a7650e1e769169b4018ee4466d (diff)
downloadmpv-5597db7081b9420e0305c717435b18c71e72cb02.tar.bz2
mpv-5597db7081b9420e0305c717435b18c71e72cb02.tar.xz
vf_vavpp: restrict allowed sw upload formats to nv12/yuv420p
We allowed any input format that was generally supported by libva, but this is probably nonsense, as the actual surface format was always fixed to nv12. We would have to check whether libva can upload a given pixel format to a nv12 surface. Or we would have to use a separate frame pool for input surfaces with the exact sw_format - but then we'd also need to check whether the vaapi VideoProc supports the surface type. Hardcode nv12 and yuv420p as input formats, which we know can be uploaded to nv12 surfaces. In theory we could get a list of supported upload formats from libavutil, but that also require allocating a dummy hw frames context just for the query. Add a comment to the upload code why we can allocate an output surface for input. In the long run, we'll probably want to use libavfilter's vaapi deinterlacer, but for now this would break at least user options.
Diffstat (limited to 'video/out/gpu/video.c')
0 files changed, 0 insertions, 0 deletions