summaryrefslogtreecommitdiffstats
path: root/core/command.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-04-24 19:31:48 +0200
committerwm4 <wm4@nowhere>2013-04-24 20:27:12 +0200
commitff549a2f6ade72ee9af42e911139bbee41daee5a (patch)
treea495c7a77679c306ef1def02a510b21562880fd3 /core/command.c
parent40f822782d036d206a95b8447b709ea2a65b151e (diff)
downloadmpv-ff549a2f6ade72ee9af42e911139bbee41daee5a.tar.bz2
mpv-ff549a2f6ade72ee9af42e911139bbee41daee5a.tar.xz
core: add backstep support
Allows stepping back one frame via the frame_back_step inout command, bound to "," by default. This uses the precise seeking facility, and a perfect frame index built on the fly. The index is built during playback and precise seeking, and contains (as of this commit) the last 100 displayed or skipped frames. This index is used to find the PTS of the previous frame, which is then used as target for a precise seek. If no PTS is found, the core attempts to do a seek before the current frame, and skip decoded frames until the current frame is reached; this will create a sufficient index and the normal backstep algorithm can be applied. This can be rather slow. The worst case for backstepping is about the same as the worst case for precise seeking if the previous frame can be deduced from the index. If not, the worst case will be twice as slow. There's also some minor danger that the index is incorrect in case framedropping is involved. For framedropping due to --framedrop, this problem is ignored (use of --framedrop is discouraged anyway). For framedropping during precise seeking (done to make it faster), we try to not add frames to the index that are produced when this can happen. I'm not sure how well that works (or if the logic is sane), and it's sure to break with some video filters. In the worst case, backstepping might silently skip frames if you backstep after a user-initiated precise seek. (Precise seeks to do indexing are not affected.) Likewise, video filters that somehow change timing of frames and do not do this in a deterministic way (i.e. if you seek to a position, frames with different timings are produced than when the position is reached during normal playback) will make backstepping silently jump to the wrong frame. Enabling/disabling filters during playback (like for example deinterlacing) will have similar bad effects.
Diffstat (limited to 'core/command.c')
-rw-r--r--core/command.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/core/command.c b/core/command.c
index 6b00c9136f..11d987819d 100644
--- a/core/command.c
+++ b/core/command.c
@@ -1832,7 +1832,11 @@ void run_command(MPContext *mpctx, mp_cmd_t *cmd)
}
case MP_CMD_FRAME_STEP:
- add_step_frame(mpctx);
+ add_step_frame(mpctx, 1);
+ break;
+
+ case MP_CMD_FRAME_BACK_STEP:
+ add_step_frame(mpctx, -1);
break;
case MP_CMD_QUIT: