aboutsummaryrefslogtreecommitdiffhomepage
path: root/DOCS/man
diff options
context:
space:
mode:
authorGravatar wm4 <wm4@nowhere>2017-11-04 23:02:25 +0100
committerGravatar wm4 <wm4@nowhere>2017-11-04 23:18:42 +0100
commit10d0963d851fad338d5d4457172fb20e76bc88aa (patch)
treea585270483bc5f923ea69481d10c714046f0d54c /DOCS/man
parent6e998be7bed7d25e98bfe1c7d6ca079f081da7d1 (diff)
demux: improve and optimize cache pruning and seek range determination
The main purpose of this commit is avoiding any hidden O(n^2) algorithms in the code for pruning the demuxer cache, and for determining the seekable boundaries of the cache. The old code could loop over the whole packet queue on every packet pruned in certain corner cases. There are two ways how to reach the goal: 1) commit a cardinal sin 2) do everything incrementally The cardinal sin is adding an extra field to demux_packet, which caches the determined seekable range for a keyframe range. demux_packet is a rather general data structure and thus shouldn't have any fields that are not inherent to its use, and are only needed as an implementation detail of code using it. But what are you gonna do, sue me? In the future, demux.c might have its own packet struct though. Then the other existing cardinal sin (the "next" field, from MPlayer times) could be removed as well. This commit also changes slightly how the seek end is determined. There is a note on the manpage in case anyone finds the new behavior confusing. It's somewhat cleaner and might be needed for supporting multiple ranges (although that's unclear).
Diffstat (limited to 'DOCS/man')
-rw-r--r--DOCS/man/input.rst5
1 files changed, 5 insertions, 0 deletions
diff --git a/DOCS/man/input.rst b/DOCS/man/input.rst
index f591d695ef..987e369a15 100644
--- a/DOCS/man/input.rst
+++ b/DOCS/man/input.rst
@@ -1268,6 +1268,11 @@ Property list
only at most 1 range. Should the player implement caching for multiple
ranges, the order of the ranges will be unspecified and arbitrary.
+ The end of a seek range is usually smaller than the value returned by the
+ ``demuxer-cache-time`` property, because that property returns the guessed
+ buffering amount, while the seek ranges represent the buffered data that
+ can actually be used for cached seeking.
+
When querying the property with the client API using ``MPV_FORMAT_NODE``,
or with Lua ``mp.get_property_native``, this will return a mpv_node with
the following contents: