summaryrefslogtreecommitdiffstats
path: root/options/options.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-02-29 23:03:39 +0100
committerwm4 <wm4@nowhere>2020-02-29 23:03:39 +0100
commitb31a5e3a580c3245433a59767921e6766a302e8b (patch)
treee20c6a9794517678284d677baba55f0c3fb51ced /options/options.c
parentfaf24a286fb69ef6b93522a4678fad81b6e989f6 (diff)
downloadmpv-b31a5e3a580c3245433a59767921e6766a302e8b.tar.bz2
mpv-b31a5e3a580c3245433a59767921e6766a302e8b.tar.xz
demux: another hack to deal with track switching refresh
The demuxer cache employs a strange method to make track switching instant with caching enabled. Normally this would mean you have to wait until the cache has played out (and you get new packets, including packets from the newly selected track), or you have to perform a slow high level seek (decoding video again etc.). The strange method is that it performs a demuxer-level seek without a high level seek so it looks like a continuous stream to the decoder, and the newly select stream gets packets at the current playback position. This is called a refresh seek. This works only if some weird heuristics work. It needs a packet "unique ID", for which it uses either dts or pts. The value must be strictly monotonic increasing. If this doesn't work, the referesh seek can't be executed, and the user has to wait until the end of the cache. Sometimes there are files that simply do not work. In the present case, there's actually a hack that we can extend. Packets with unset position are likely generated by the parser, and the hack which this commit touches simply attempts to make up a new (hopefully unique) position value, even if the value itself makes no sense. It only ha to be deterministic. It turns out libavcodec sometimes output packets with repeating position values. This commit tries to handle this case too with the same hack. Fixes: #7498
Diffstat (limited to 'options/options.c')
0 files changed, 0 insertions, 0 deletions