diff options
author | wm4 <wm4@nowhere> | 2015-07-08 12:18:29 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2015-07-08 12:18:29 +0200 |
commit | 9620e37d6a7e34f86bde7886f9c0b1e564576a68 (patch) | |
tree | 9dd9609ddd7330b653cba55d718896af7ff8d5e6 /DOCS/waf-buildsystem.rst | |
parent | 0ebf5979d10388e8ac226d17aca4a4067ddbdbb1 (diff) | |
download | mpv-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 'DOCS/waf-buildsystem.rst')
0 files changed, 0 insertions, 0 deletions