From 9c22108fec447183a85f8775e92d7c19ea251d75 Mon Sep 17 00:00:00 2001 From: wm4 Date: Wed, 3 Jan 2018 21:28:28 +0100 Subject: player: use fixed timeout for cache pausing (buffering) duration This tried to be clever by waiting for a longer time each time the buffer was underrunning, or shorter if it was getting better. I think this was pretty weird behavior and makes no sense. If the user really wants the stream to buffer longer, he/she/it can just pause the player (the network caches will continue to be filled until they're full). Every time I actually noticed this code triggering in my own use, I didn't find it helpful. Apart from that it was pretty hard to test. Some waiting is needed to avoid that the player just plays the available data as fast as possible (to compensate for late frames and underrunning audio). Just use a fixed wait time, which can now be controlled by the new --cache-pause-wait option. --- DOCS/man/options.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'DOCS') diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst index 556299853f..3d1c2ade2d 100644 --- a/DOCS/man/options.rst +++ b/DOCS/man/options.rst @@ -3856,6 +3856,15 @@ Cache data and stalls decoding/playback (default: yes). If enabled, it will pause and unpause once more data is available, aka "buffering". +``--cache-pause-wait=`` + Number of seconds the packet cache should have buffered before starting + playback again if "buffering" was entered (default: 1). This can be used + to control how long the player rebuffers if ``--cache-pause`` is enabled, + and the demuxer underruns. If the given time is higher than the maximum + set with ``--cache-secs`` or ``--demuxer-readahead-secs``, or prefetching + ends before that for some other reason (like file end), playback resumes + earlier. + Network ------- -- cgit v1.2.3