summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-11-23 22:28:39 +0100
committerwm4 <wm4@nowhere>2013-12-01 19:32:44 +0100
commit600193749d0edef7532a6ad0312b3b78bd468b1d (patch)
tree20abf588ca60f4c8072a34f37bf19a712e8a2d80
parentfc465f1f2622c313cacd9513de54669228bb3709 (diff)
downloadmpv-600193749d0edef7532a6ad0312b3b78bd468b1d.tar.bz2
mpv-600193749d0edef7532a6ad0312b3b78bd468b1d.tar.xz
vd_lavc: when falling back to software, revert filter error status
When mpv is started with some video filters set (--vf is used), and hardware decoding is requested, and hardware decoding would be possible, but is prevented due to video filters that accept software formats only, the fallback didn't work properly sometimes. This fallback works rather violently: it tries to initialize the filter chain, and if it fails it throws away the frame decoded using the hardware, and retries with software. The case that didn't work was when decoding the current packet didn't immediately lead to a new frame. Then the filter chain wouldn't be reinitialized, and the playloop would stop playback as soon as it encounters the error flag. Fix this by resetting the filter error flag (back to "uninitialized"), which is a rather violent, but somewhat working solution. The fallback in general should perhaps be cleaned up later. Conflicts: video/decode/vd_lavc.c
-rw-r--r--video/decode/vd_lavc.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/video/decode/vd_lavc.c b/video/decode/vd_lavc.c
index 479e36df6a..6c89b53886 100644
--- a/video/decode/vd_lavc.c
+++ b/video/decode/vd_lavc.c
@@ -791,6 +791,8 @@ static struct mp_image *decode_with_fallback(struct sh_video *sh,
init_avctx(sh, decoder, NULL);
if (ctx->avctx) {
mpi = NULL;
+ if (sh->vf_initialized < 0)
+ sh->vf_initialized = 0;
decode(sh, packet, flags, reordered_pts, &mpi);
return mpi;
}