summaryrefslogtreecommitdiffstats
path: root/video/filter
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2015-07-08 12:18:29 +0200
committerwm4 <wm4@nowhere>2015-07-08 12:18:29 +0200
commit9620e37d6a7e34f86bde7886f9c0b1e564576a68 (patch)
tree9dd9609ddd7330b653cba55d718896af7ff8d5e6 /video/filter
parent0ebf5979d10388e8ac226d17aca4a4067ddbdbb1 (diff)
downloadmpv-9620e37d6a7e34f86bde7886f9c0b1e564576a68.tar.bz2
mpv-9620e37d6a7e34f86bde7886f9c0b1e564576a68.tar.xz
vaapi: increase number of additional surfaces
Sometime recently, hardware decoding started to fail if h264 with full reference frames was decoded, and --vo=vaapi was used. VAAPI requires registering all surfaces that the decoder will ever use in advance, so if the playback chain uses more surfaces than originally allocated, we fail and drop back to software decoding. I'm not really sure why or when this started happening. Commit 7b9d7265 for one is not the cause - it can be reproduced with earlier commits. It also seems to be timing dependent. Possibly it has to do with the way vo.c retains previous surfaces, and the way they can be queued/unqueued asynchronously. Increasing the number of reserved additional surfaces by 1 fixes it. (Though I have no idea where exactly all these surfaces are being used. Or rather, _when_.)
Diffstat (limited to 'video/filter')
0 files changed, 0 insertions, 0 deletions