summaryrefslogtreecommitdiffstats
path: root/player
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-09-06 13:24:44 +0200
committerwm4 <wm4@nowhere>2014-09-06 13:33:29 +0200
commit7791e25fa0a795c7e042c3938405024468669c29 (patch)
treebc6dfd804b1c578ac89c2817896b65b7e21478ef /player
parent39609fc19acb8ebe04e476ca7ad964c3f15903e7 (diff)
downloadmpv-7791e25fa0a795c7e042c3938405024468669c29.tar.bz2
mpv-7791e25fa0a795c7e042c3938405024468669c29.tar.xz
audio: fix initial sync with huge AO buffer
With e.g --start=-3 --audio-buffer=10 the decoder entered EOF state before the initial sync was finished, entered STATUS_EOF, and just started playing audio from a random position. This doesn't handle seeking outside of the file, which is a different case. E.g. --start=30:00 with audio and video enabled in a file shorter than 30:00 will play a random last part of audio. This could perhaps be fixed by using the hr-seek target for cutting audio, instead of the video PTS, but that would be kind of intrusive, so don't do it for now. The simpler solution, assuming audio EOF on video EOF, wouldn't work, because we allow audio to start before video, or to last after video.
Diffstat (limited to 'player')
-rw-r--r--player/audio.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/player/audio.c b/player/audio.c
index 958269ec65..5de4fd449e 100644
--- a/player/audio.c
+++ b/player/audio.c
@@ -466,7 +466,7 @@ void fill_audio_out_buffers(struct MPContext *mpctx, double endpts)
if (mpctx->audio_status == STATUS_SYNCING) {
if (end_sync)
mpctx->audio_status = STATUS_FILLING;
- if (status != AD_OK)
+ if (status != AD_OK && !mp_audio_buffer_samples(mpctx->ao_buffer))
mpctx->audio_status = STATUS_EOF;
mpctx->sleeptime = 0;
return; // continue on next iteration