diff options
| author | wm4 <wm4@nowhere> | 2017-01-08 12:50:26 +0100 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2017-01-08 14:47:53 +0100 |
| commit | c4ad2732f99bd6dd8e09e284590ac0f3428482a1 (patch) | |
| tree | 9c9b4477c416bba2484432ccb05ae35f6ab6ac3c | |
| parent | e0f25010c7e7bc5375917d8f5dc2a009849c68fc (diff) | |
| download | mpv-c4ad2732f99bd6dd8e09e284590ac0f3428482a1.tar.bz2 mpv-c4ad2732f99bd6dd8e09e284590ac0f3428482a1.tar.xz | |
audio: stop being dumb
Obvious mistake: we entered EOF drain mode if the decoder returned
AD_WAIT, which is very wrong. AD_WAIT means we should retry after
waiting for a while (or to be precise, until the demuxer/decoder
have more data). We should just pass down this status, and not
change the audio chain state.
This was exposed by a libavfilter EOF handling bug. Feeding a filter
chain with af_dynaudnorm, and sending an EOF before a frame is returned
makes it stuck and keeps returning EAGAIN, instead of returning the
buffered audio. In combination with the bug at hand, which entered
EOG drain mode, it could happen that it got stuck due to libavfilter
discarding buffered data each time the demuxer ran out of data.
Fixes #3997.
| -rw-r--r-- | player/audio.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/player/audio.c b/player/audio.c index 5c393f3d3a..e1766143b9 100644 --- a/player/audio.c +++ b/player/audio.c @@ -817,7 +817,7 @@ static int filter_audio(struct MPContext *mpctx, struct mp_audio_buffer *outbuf, break; res = decode_new_frame(ao_c); - if (res == AD_NO_PROGRESS) + if (res == AD_NO_PROGRESS || res == AD_WAIT) break; if (res < 0) { // drain filters first (especially for true EOF case) |