summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAman Gupta <aman@tmm1.net>2018-02-15 19:57:34 -0800
committerKevin Mitchell <kevmitch@gmail.com>2018-02-17 23:01:47 -0800
commitb67d2ede67a72d999d5afe4e4def802cf047fc4d (patch)
treed509c2e81dd12d48f3399ad32e04bfe69266833c
parent288ed66a355ed9a0e9a5730f87c2fb60e8e546cc (diff)
downloadmpv-b67d2ede67a72d999d5afe4e4def802cf047fc4d.tar.bz2
mpv-b67d2ede67a72d999d5afe4e4def802cf047fc4d.tar.xz
video: do not buffer extra frames with VO_CAP_NORETAIN outputs
This fixes playback stalls on some mediacodec hardware decoders, which expect that frame buffers will be rendered and returned back to the decoder as soon as possible. Specifically, the issue was observed on an NVidia SHIELD Android TV, only when playing an H264 sample which switched between interlaced and non-interlaced frames. On an interlacing change, the decoder expects all outstanding frames would be returned to it before it would emit any new frames. Since a single extra frame always remained buffered by mpv, playback would stall. After this commit, no extra frames are buffered by mpv when using vo_mediacodec_embed.
-rw-r--r--player/video.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/player/video.c b/player/video.c
index 27998c96a8..e0919a7c5e 100644
--- a/player/video.c
+++ b/player/video.c
@@ -408,6 +408,9 @@ static int get_req_frames(struct MPContext *mpctx, bool eof)
if (eof)
return 1;
+ if (mpctx->video_out->driver->caps & VO_CAP_NORETAIN)
+ return 1;
+
// On the first frame, output a new frame as quickly as possible.
// But display-sync likes to have a correct frame duration always.
if (mpctx->video_pts == MP_NOPTS_VALUE)