diff options
author | wm4 <wm4@nowhere> | 2020-02-29 23:03:39 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2020-02-29 23:03:39 +0100 |
commit | b31a5e3a580c3245433a59767921e6766a302e8b (patch) | |
tree | e20c6a9794517678284d677baba55f0c3fb51ced /demux/cue.h | |
parent | faf24a286fb69ef6b93522a4678fad81b6e989f6 (diff) | |
download | mpv-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 'demux/cue.h')
0 files changed, 0 insertions, 0 deletions