diff options
author | wm4 <wm4@nowhere> | 2017-08-08 14:55:02 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-08-08 14:55:02 +0200 |
commit | 0e0b87b6f3297074b6c355d58a04e0b71d323bf1 (patch) | |
tree | 945cb67a6106e1558a25ad79d6b22c3ec7365a63 /player | |
parent | 8ef50016befd8e684866a84c09dd0460d379e2ee (diff) | |
download | mpv-0e0b87b6f3297074b6c355d58a04e0b71d323bf1.tar.bz2 mpv-0e0b87b6f3297074b6c355d58a04e0b71d323bf1.tar.xz |
player: fix confusion in audio resync code
Just the audio resync code in its normal state: buggy. This time,
AD_NO_PROGRESS was handled about the same as AD_WAIT. But it means the
decoder didn't output data, even though input is still readily
available.
This happened in particular when the timeline code was used (potentially
skipping many packets), and thus should fix #4688.
Diffstat (limited to 'player')
-rw-r--r-- | player/audio.c | 8 |
1 files changed, 6 insertions, 2 deletions
diff --git a/player/audio.c b/player/audio.c index d1e4c83a9a..62a5ddb5d6 100644 --- a/player/audio.c +++ b/player/audio.c @@ -878,7 +878,9 @@ static int filter_audio(struct MPContext *mpctx, struct mp_audio_buffer *outbuf, break; res = decode_new_frame(ao_c); - if (res == AD_NO_PROGRESS || res == AD_WAIT) + if (res == AD_NO_PROGRESS) + continue; + if (res == AD_WAIT) break; if (res < 0) { // drain filters first (especially for true EOF case) @@ -970,7 +972,9 @@ void fill_audio_out_buffers(struct MPContext *mpctx) if (ao_c->af->initialized < 1 || !mpctx->ao) { // Probe the initial audio format. Returns AD_OK (and does nothing) if // the format is already known. - int r = decode_new_frame(mpctx->ao_chain); + int r = AD_NO_PROGRESS; + while (r == AD_NO_PROGRESS) + r = decode_new_frame(mpctx->ao_chain); if (r == AD_WAIT) return; // continue later when new data is available if (r == AD_EOF) { |