summaryrefslogtreecommitdiffstats
path: root/player/external_files.h
diff options
context:
space:
mode:
authorUoti Urpala <uau@glyph.nonexistent.invalid>2017-04-24 13:28:37 +0300
committerwm4 <wm4@nowhere>2017-05-15 15:47:20 +0200
commit3f17b101eebe8f266c63781f32d0a454dcb1e7d0 (patch)
tree942617e9569159170fc2b95fed30bf66025b073c /player/external_files.h
parent5aea98551b950de8ea96d9acb08ed1e65a003f80 (diff)
downloadmpv-3f17b101eebe8f266c63781f32d0a454dcb1e7d0.tar.bz2
mpv-3f17b101eebe8f266c63781f32d0a454dcb1e7d0.tar.xz
cache: fix unnecessary seek blocking from f4d62dc4a0
Commit 374600cec0 ("cache: propagate seek failures") changed stream-level seeks to be done in the calling thread so possible errors could be reported. This commit included some rationale why doing the stream-level seeks synchronously was not a big issue. However, the following fixup commit f4d62dc4a0 changed the seek code to always synchronize with the cache thread and do seek handling there. This is a problem because it affects even seeks within already cached data (which require no stream-level seek). With a network server that sends data in bursts, the cache thread can be blocked in a read call for a long time; the added synchronization means that seeking within already downloaded data can have unnecessary long delays. Change cache_seek() to check whether the seek is expected to result in a stream-level seek, and skip synchronization if it is not. This means that seeks within the cached portion of the file now again happen immediately without possibly waiting for network. Signed-off-by: wm4 <wm4@nowhere>
Diffstat (limited to 'player/external_files.h')
0 files changed, 0 insertions, 0 deletions