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_.)

1 files changed, 2 insertions, 6 deletions

diff --git a/video/decode/vaapi.c b/video/decode/vaapi.c
index 0a9250c900..b947b0c7de 100644
--- a/video/decode/vaapi.c
+++ b/video/decode/vaapi.c
@@ -40,15 +40,11 @@
  * The VAAPI decoder can work only with surfaces passed to the decoder at
  * creation time. This means all surfaces have to be created in advance.
  * So, additionally to the maximum number of reference frames, we need
- * surfaces for:
- * - 1 decode frame
- * - decoding 2 frames ahead (done by generic playback code)
- * - keeping the reference to the previous frame (done by vo_vaapi.c)
- * - keeping the reference to a dropped frame (done by vo.c)
+ * surfaces for all kinds of buffering between decoder and VO.
  * Note that redundant additional surfaces also might allow for some
  * buffering (i.e. not trying to reuse a surface while it's busy).
  */
-#define ADDTIONAL_SURFACES 5
+#define ADDTIONAL_SURFACES 6
 
 // Some upper bound.
 #define MAX_SURFACES 25