diff options
author | Uoti Urpala <uau@glyph.nonexistent.invalid> | 2017-04-24 13:28:37 +0300 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2017-05-15 15:47:20 +0200 |
commit | 3f17b101eebe8f266c63781f32d0a454dcb1e7d0 (patch) | |
tree | 942617e9569159170fc2b95fed30bf66025b073c /player/external_files.h | |
parent | 5aea98551b950de8ea96d9acb08ed1e65a003f80 (diff) | |
download | mpv-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