summaryrefslogtreecommitdiffstats
path: root/video/filter/vf_vapoursynth.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-07-05 17:02:37 +0200
committerwm4 <wm4@nowhere>2014-07-05 17:07:16 +0200
commit6fcb34d887d7db9c90e20fd427751b047f649d5e (patch)
tree0ce762317b6f23a5c733ea054461a0c1801f4013 /video/filter/vf_vapoursynth.c
parentd27a2bc546a2ba8dcb69931c9a1f7b60a1b95b03 (diff)
downloadmpv-6fcb34d887d7db9c90e20fd427751b047f649d5e.tar.bz2
mpv-6fcb34d887d7db9c90e20fd427751b047f649d5e.tar.xz
vf_vapoursynth: reset error state on seeking
When seeking, we violently destroy the filter, because vapoursynth has no proper API for terminating a video with unknown frame count. This looks like an error to vapoursynth, and the error is returned via the frame callbacks. The bug is that we remember this error state across reinitialization, so on the first filter call after reinitialization, we thought filtering the current frame failed. This caused a shift by 1 frame on each seek. CC: @mpv-player/stable
Diffstat (limited to 'video/filter/vf_vapoursynth.c')
-rw-r--r--video/filter/vf_vapoursynth.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/video/filter/vf_vapoursynth.c b/video/filter/vf_vapoursynth.c
index 8af3d02bb0..5e104bb49c 100644
--- a/video/filter/vf_vapoursynth.c
+++ b/video/filter/vf_vapoursynth.c
@@ -434,6 +434,7 @@ static void destroy_vs(struct vf_instance *vf)
p->next_image = NULL;
p->out_pts = MP_NOPTS_VALUE;
p->out_frameno = p->in_frameno = 0;
+ p->failed = false;
MP_DBG(vf, "uninitialized.\n");
}