From cd9ee1a8533a3d5fb4c163802347e83c7db91923 Mon Sep 17 00:00:00 2001 From: wm4 Date: Wed, 20 Apr 2016 13:05:29 +0200 Subject: player: really start audio only once video is ready The check whether video is ready yet was done only in STATUS_FILLING. But it also switched to STATUS_READY, which means the next time fill_audio_out_buffers() was called, audio would actually be started before video. In most situations, this bug didn't show up, because it was only triggered if the demuxer didn't provide video packets quickly enough, but did for audio packets. Also log when audio is started. (I hate fill_audio_out_buffers(), why did I write it?) --- player/audio.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/player/audio.c b/player/audio.c index 3a2c60b8ab..2ce1669366 100644 --- a/player/audio.c +++ b/player/audio.c @@ -886,13 +886,18 @@ void fill_audio_out_buffers(struct MPContext *mpctx) assert(mpctx->audio_status >= STATUS_FILLING); + // We already have as much data as the audio device wants, and can start + // writing it any time. + if (mpctx->audio_status == STATUS_FILLING) + mpctx->audio_status = STATUS_READY; + // Even if we're done decoding and syncing, let video start first - this is // required, because sending audio to the AO already starts playback. - if (mpctx->audio_status == STATUS_FILLING && mpctx->vo_chain && - !mpctx->vo_chain->is_coverart && mpctx->video_status <= STATUS_READY) - { - mpctx->audio_status = STATUS_READY; - return; + if (mpctx->audio_status == STATUS_READY) { + if (mpctx->vo_chain && !mpctx->vo_chain->is_coverart && + mpctx->video_status <= STATUS_READY) + return; + MP_VERBOSE(mpctx, "starting audio playback\n"); } bool audio_eof = status == AD_EOF; -- cgit v1.2.3