github/mpv
1
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2024-10-30 04:46:41 +01:00
Code Releases Activity

vaapi: increase number of additional surfaces

Browse Source 
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_.)
This commit is contained in:
wm4 2015-07-08 12:18:29 +02:00
parent 0ebf5979d1
commit 9620e37d6a
1 changed files with 2 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
video/decode/vaapi.c
View File

@ -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