summaryrefslogtreecommitdiffstats
path: root/player
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-13 01:28:59 +0100
committerwm4 <wm4@nowhere>2020-02-13 01:32:58 +0100
commit5bf433b16f35234a04b8350634c471912fa80343 (patch)
treed2c5d3fc8b089cf53fe84c42c64f2dc555c27315 /player
parentf3c498c7f10dea395ee098a4d1d7e2f9602e2a99 (diff)
downloadmpv-5bf433b16f35234a04b8350634c471912fa80343.tar.bz2
mpv-5bf433b16f35234a04b8350634c471912fa80343.tar.xz
player: consider audio buffer if AO driver does not report underruns
AOs can report audio underruns, but only ao_alsa and ao_sdl (???) currently do so. If the AO was marked as not reporting it, the cache state was used to determine whether playback was interrupted due to slow input. This caused problems in some cases, such as video with very low video frame rate: when a new frame is displayed, a new frame has to be decoded, and since there it's so much further into the file (long frame durations), the cache gets into an underrun state for a short moment, even though both audio and video are playing fine. Enlarging the audio buffer didn't help. Fix this by making all AOs report underruns. If the AO driver does not report underruns, fall back to using the buffer state. pull.c behavior is slightly changed. Pull AOs are normally intended to be used by pseudo-realtime audio APIs that fetch an audio buffer from the API user via callback. I think it makes no sense to consider a buffer underflow not an underrun in any situation, since we return silence to the reader. (OK, maybe the reader could check the return value? But let's not go there as long as there's no implementation.) Remove the flag from ao_sdl.c, since it just worked via the generic mechanism. Make the redundant underrun message verbose only. push.c seems to log a redundant underflow message when resuming (because somehow ao_play_data() is called when there's still no new data in the buffer). But since ao_alsa does its own underrun reporting, and I only use ao_alsa, I don't really care. Also in all my tests, there seemed to be a rather high delay until the underflow was logged (with audio only). I have no idea why this happened and didn't try to debug this, but there's probably something wrong somewhere. This commit may cause random regressions. See: #7440
Diffstat (limited to 'player')
-rw-r--r--player/playloop.c9
1 files changed, 3 insertions, 6 deletions
diff --git a/player/playloop.c b/player/playloop.c
index 4f0efad275..66ce211322 100644
--- a/player/playloop.c
+++ b/player/playloop.c
@@ -691,7 +691,7 @@ static void handle_update_cache(struct MPContext *mpctx)
bool force_update = false;
struct MPOpts *opts = mpctx->opts;
- if (!mpctx->demuxer) {
+ if (!mpctx->demuxer || mpctx->encode_lavc_ctx) {
clear_underruns(mpctx);
return;
}
@@ -726,11 +726,8 @@ static void handle_update_cache(struct MPContext *mpctx)
// underrun detection.)
bool output_underrun = false;
- if (mpctx->ao_chain) {
- output_underrun |=
- !(mpctx->ao && ao_get_reports_underruns(mpctx->ao)) ||
- mpctx->ao_chain->underrun;
- }
+ if (mpctx->ao_chain)
+ output_underrun |= mpctx->ao_chain->underrun;
if (mpctx->vo_chain)
output_underrun |= mpctx->vo_chain->underrun;