demux: avoid queue overflow warning when joining two ranges

If the backbuffer is much larger than the forward buffer, and if you
join a small range with a large range (larger than the forward buffer),
then the seek issues to the end of the range after joining will overflow
the queue.

Normally, read_more will be false when the forward buffer is full, but
the resume seek after joining will set need_refresh to true, which
forces more reading and thus triggers the overfloe warning.

Attempt to fix this by not setting read_more to true on refresh seeks.
Set prefetch_more instead. read_more will still be set if an A/V stream
has no data.

This doesn't help with the following problems related to using refresh
seeks for track switching:

- If the forward buffer is full, then enabling another track will
  obviously immediately overflow the queue, and immediately lead to
  marking the new track as having no more data (i.e. EOF). We could cut
  down the forward buffer or so, but there's no simple way to implement
  it. Another possibility would be dropping all buffers and trying to
  resume again, but this would likely be complex as well.
- Subtitle tracks will not even show a warning (because they are sparse,
  and we have no way of telling whether a packet is missing, or there's
  just no packet near the current position). Before this commit,
  enabling an empty subtitle track would probably have overflown the
  queue, because ds->refreshing was never set to true. Possibly this
  could be solved by determining a demuxer read position, which would
  reflect until which PTS all subtitle packets should have been demuxed.

The forward buffer limit was intended as a last safeguard to avoid
excessive memory usage against badly interleaved files or decoders going
crazy (up to reading the whole into memory and OOM'ing the user's
system). It's not good at all to limit prefetch. Possibly solutions
include having another smaller limit for prefetch, or maybe having only
a total buffer limit, and discarding back buffer if more data has to be
read. The current solution is making the forward buffer larger than the
forward duration (--cache-secs) would require, but of course this
depends on the stream's bitrate.

0 files changed, 0 insertions, 0 deletions