1
0
mirror of https://github.com/mpv-player/mpv synced 2025-04-01 23:00:41 +00:00

demux: fix being stuck in "buffering" when using --no-demuxer-thread

This is a regression. According to git bisect, commit 4b2cbefc0 broke
this. I'm not sure why; the commit in question should have been a
refactor with no functional changes. The commit message mentions brain
damage, though, and this is where I stopped my investigation.

Since with --no-demuxer-thread, there is no read-ahead, the concept of
an underrun makes no sense. We might block the playback thread long
enough that the user perceives an interruption, but we don't know about
this, nor do we care. Only when the demuxer is threaded it can happen
that we can't immediately return a packet to the user, and this
underrun.

(The underrun detection is a bit janky and roundabout, to be honest.
Probably could be simpler by setting a per-stream underrun flag simply
when no packet/EOF is available when the decoder reads a packet.)

It's interesting that the regression existed for half a year, yet nobody
cared. I guess nobody uses --no-demuxer-thread.

Fixes: 4b2cbefc0d
This commit is contained in:
wm4 2019-05-17 20:47:01 +02:00
parent c9d376acd8
commit fe4c1ecb7d

View File

@ -3217,7 +3217,7 @@ void demux_get_reader_state(struct demuxer *demuxer, struct demux_reader_state *
}
}
r->idle = (in->idle && !r->underrun) || r->eof;
r->underrun &= !r->idle;
r->underrun &= !r->idle && in->threading;
r->ts_reader = MP_ADD_PTS(r->ts_reader, in->ts_offset);
r->ts_end = MP_ADD_PTS(r->ts_end, in->ts_offset);
if (r->ts_reader != MP_NOPTS_VALUE && r->ts_reader <= r->ts_end)