From 9620e37d6a7e34f86bde7886f9c0b1e564576a68 Mon Sep 17 00:00:00 2001 From: wm4 Date: Wed, 8 Jul 2015 12:18:29 +0200 Subject: 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_.) --- video/decode/vaapi.c | 8 ++------ 1 file 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 -- cgit v1.2.3