|author||wm4 <wm4@nowhere>||2014-08-23 12:02:40 +0200|
|committer||wm4 <wm4@nowhere>||2014-08-23 12:02:40 +0200|
player: restore silent seeking
Commit 846257da introduced an accidental feature: if you kept seeking (so playback never really resumes), the audio would never be played. This was nice, but commit 4c25b000 accidentally removed it again (due to the video_next_pts being earlier available than it used to be, so audio could be played before the player executed the next queued seek). Implicitly reintroduce the old behavior again by not decoding a second video frame immediately. Usually, the second frame is used to compute the frame duration needed to for accurate framedropping, but since the first frame after a seek is never dropped, we don't need this. Now the video code will queue the new frame to the VO immediately, and since fill_audio_out_buffers() is called in the playloop before write_video() and execute_queued_seek(), it never gets the chance to enter STATUS_READY, and seeks will be silent. This also has a nice side-effect: since the second frame is not decoded and filtered, seeking becomes slightly faster (back to the same level as with framedrop disabled). It seems this still sometimes plays a period of audio when keeping a seek key down. In my tests, this appeared to happen because the seek finished before the next key repeat was sent.
Diffstat (limited to 'player/video.c')
1 files changed, 2 insertions, 1 deletions
diff --git a/player/video.c b/player/video.c
index 6a8fade027..391d2c02bd 100644
@@ -504,7 +504,8 @@ static int video_output_image(struct MPContext *mpctx, double endpts)
return r <= 0 ? VD_EOF : VD_PROGRESS;
- bool need_2nd = !!(mpctx->opts->frame_dropping & 1); // we need the duration
+ bool need_2nd = !!(mpctx->opts->frame_dropping & 1) // we need the duration
+ && mpctx->video_pts != MP_NOPTS_VALUE; // ...except for the 1st frame
// Enough video filtered already?
if (mpctx->next_frame && (!need_2nd || mpctx->next_frame))