summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2017-01-18 19:02:50 +0100
committerwm4 <wm4@nowhere>2017-01-18 19:02:50 +0100
commite277fadd60350caad1fc31e92a5076692e61dcc9 (patch)
tree715593fc3cb52fee1daffa7e4fe6712a8de97777 /DOCS
parentc54c3b6991ac0273e6b7a42dc42c5103f87ff9f1 (diff)
downloadmpv-e277fadd60350caad1fc31e92a5076692e61dcc9.tar.bz2
mpv-e277fadd60350caad1fc31e92a5076692e61dcc9.tar.xz
player: add prefetching of the next playlist entry
Since for mpv CLI, the player state is a singleton, full prefetching is a bit tricky. We do it only on the demuxer layer. The implementation reuses the old "open thread". This means there is significant potential for regressions even if the new option is not used. This is made worse by the fact that I barely tested this code. The generic mpctx_run_reentrant() wrapper is also removed - this was its only user, and its remains become part of the new implementation.
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/man/options.rst21
1 files changed, 21 insertions, 0 deletions
diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index a812fb088c..079672533f 100644
--- a/DOCS/man/options.rst
+++ b/DOCS/man/options.rst
@@ -2737,6 +2737,27 @@ Demuxer
(This value tends to be fuzzy, because many file formats don't store linear
timestamps.)
+``--prefetch-playlist=<yes|no>``
+ Prefetch next playlist entry while playback of the current entry is ending
+ (default: no). This merely opens the URL of the next playlist entry as soon
+ as the current URL is fully read.
+
+ This does **not** work with URLs resolved by the ``youtube-dl`` wrapper,
+ and it won't.
+
+ This does not affect HLS (``.m3u8`` URLs) - HLS prefetching depends on the
+ demuxer cache settings and is on by default.
+
+ This can give subtly wrong results if per-file options are used, or if
+ options are changed in the time window between prefetching start and next
+ file played.
+
+ This can occasionally make wrong prefetching decisions. For example, it
+ can't predict whether you go backwards in the playlist, and assumes you
+ won't edit the playlist.
+
+ Highly experimental.
+
``--force-seekable=<yes|no>``
If the player thinks that the media is not seekable (e.g. playing from a
pipe, or it's an http stream with a server that doesn't support range