summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-07 13:32:07 +0100
committerwm4 <wm4@nowhere>2020-02-07 13:32:21 +0100
commita3bd8c3b5f84c5d48785552fc7bd2505ee839736 (patch)
tree9f6ad3cb81cd52895bbde24761f7ebe26bf3db45 /player/video.c
parent3d17e19c2c5ca80f916411e7e61126cac8443baa (diff)
downloadmpv-a3bd8c3b5f84c5d48785552fc7bd2505ee839736.tar.bz2
mpv-a3bd8c3b5f84c5d48785552fc7bd2505ee839736.tar.xz
player: make screenshot each-frame mode more accurate
Due to asynchronicity, we generally can't guarantee that a video frame matches up with other events such as playback time change exactly (since decoding, presentation, and property update all happen at different times). This is a complaint in the referenced bug report, where screenshot filenames in each-frame screenshot did not use the correct timestamp, and instead was lagging behind by 1 frame. But in this case, synchronicity was already pretty much forced with wait calls. The only problem was that the playback time was updated at a later time, which results in the observed 1 frame lag. Fix this by moving the place where the screenshot is triggered in this mode. Normal screenshots may still have the old problem. There is no effort made to guarantee the timestamps absolutely line up, same as with the OSD. (If you want a guarantee, you need to use a video filter, such as libavfilter's drawtext. These will obviously use the proper timestamp, instead of going through the somewhat asynchronous property etc. system in the player frontend.) Fixes: #7433
Diffstat (limited to 'player/video.c')
-rw-r--r--player/video.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/player/video.c b/player/video.c
index e92aaf7024..d8b7728fe8 100644
--- a/player/video.c
+++ b/player/video.c
@@ -1224,8 +1224,6 @@ void write_video(struct MPContext *mpctx)
vo_c->underrun_signaled = false;
- screenshot_flip(mpctx);
-
mp_wakeup_core(mpctx);
return;