aboutsummaryrefslogtreecommitdiffhomepage
path: root/player
diff options
context:
space:
mode:
authorGravatar wm4 <wm4@nowhere>2018-04-29 16:04:50 +0200
committerGravatar Jan Ekström <jeebjp@gmail.com>2018-05-03 01:08:44 +0300
commit1a339fa09d25e94833153f299af03e9c44b19a43 (patch)
tree3043f84cd1004f53653c7edd3b1a9cb1ccb74660 /player
parentf18c4175ad8e772c0005ac6280291af425c16cc2 (diff)
video: actually wait for last frame being rendered on EOF
The video timing code could just decide that EOF was reached before it was displayed. This is not really a problem for normal playback (if you use something like --keep-open it'd show the last frame anyway, otherwise it'd at best flash it on screen before destroying the window). But in encode mode, it really matters, and makes the difference between having one frame more or less in the output file. Fix this by waiting for the VO before starting the real EOF. vo_is_ready_for_frame() is normally used to determine when the VO frame queue has enough space to send a new frame. Since the VO frame queue is currently at most 1 frame, it being signaled means the remaining frame was consumed and thus sent to the VO driver. If it returns false, it will wake up the playloop as soon as the state changes. I also considered using vo_still_displaying(), but it's not reliable, because it checks the realtime of the frame end display time.
Diffstat (limited to 'player')
-rw-r--r--player/video.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/player/video.c b/player/video.c
index 5db76db3fd..693454ecb0 100644
--- a/player/video.c
+++ b/player/video.c
@@ -1017,7 +1017,11 @@ void write_video(struct MPContext *mpctx)
mpctx->time_frame = 0;
}
- if (mpctx->video_status == STATUS_DRAINING) {
+ // Wait for the VO to signal actual EOF, then exit if the frame timer
+ // has expired.
+ if (mpctx->video_status == STATUS_DRAINING &&
+ vo_is_ready_for_frame(vo, -1))
+ {
mpctx->time_frame -= get_relative_time(mpctx);
mp_set_timeout(mpctx, mpctx->time_frame);
if (mpctx->time_frame <= 0) {