summaryrefslogtreecommitdiffstats
path: root/etc
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2015-05-29 16:28:55 +0200
committerwm4 <wm4@nowhere>2015-05-29 16:28:55 +0200
commitd3894290ec1120fe33a0105b5b271cdb667f22e6 (patch)
treec8795ff06cc4a8b411f3c3af97500dd5e6a21b9e /etc
parent327b091909e713c2c53a45c2868ed6ae0e70a533 (diff)
downloadmpv-d3894290ec1120fe33a0105b5b271cdb667f22e6.tar.bz2
mpv-d3894290ec1120fe33a0105b5b271cdb667f22e6.tar.xz
vaapi: remove direct mapping non-sense
This must have been some non-sense in the original vaapi mplayer patch. While I still have no good idea what this "direct mapping" business is about, it appears to be pretty much pointless. Nothing can hold additional "real" surface references (due to how the API and mpv/lavc refcounting work), so removing the additional surfaces won't break anything. It still could be that this was for achieving additional buffering (not reusing surfaces as soon), but we buffer some additional data anyway. Plus, the original intention of the vaapi mplayer code was probably increasing surface count just by 1 or 2, not actually doubling it, and/or it was a "trick" to get to the maximum count of 21 when h264 is in use. gstreamer-vaapi uses "ref_frames + SCRATCH_SURFACES_COUNT" here, with SCRATCH_SURFACES_COUNT defined to 4. It doesn't appear to check the overlay attributes at all in the decoder. In any case, remove this non-sense.
Diffstat (limited to 'etc')
0 files changed, 0 insertions, 0 deletions