summaryrefslogtreecommitdiffstats
path: root/video/out/vo.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-05-07 21:50:16 +0200
committerwm4 <wm4@nowhere>2014-05-07 21:50:16 +0200
commitf3362e22ebd8a39419c8225c3254fbbebe57d6e9 (patch)
treed520b97bc5b948b060417b2f7a4bdf8d4b8824cb /video/out/vo.c
parentbd2bcc4399a86420523a1c0bdf3d3e2a9d683513 (diff)
downloadmpv-f3362e22ebd8a39419c8225c3254fbbebe57d6e9.tar.bz2
mpv-f3362e22ebd8a39419c8225c3254fbbebe57d6e9.tar.xz
player: remove VO from seeking code path
Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
Diffstat (limited to 'video/out/vo.c')
-rw-r--r--video/out/vo.c5
1 files changed, 0 insertions, 5 deletions
diff --git a/video/out/vo.c b/video/out/vo.c
index 61143ea340..8cf867ef3b 100644
--- a/video/out/vo.c
+++ b/video/out/vo.c
@@ -354,11 +354,6 @@ static void shift_queue(struct vo *vo)
vo->video_queue[n] = vo->video_queue[n + 1];
}
-void vo_skip_frame(struct vo *vo)
-{
- shift_queue(vo);
-}
-
void vo_new_frame_imminent(struct vo *vo)
{
assert(vo->num_video_queue > 0);