diff options
author | wm4 <wm4@nowhere> | 2016-09-26 14:45:55 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2016-09-26 16:49:35 +0200 |
commit | 0f110ad0e27583c5161cf27a3c17d1563253b368 (patch) | |
tree | 104289fc48d70a2d482851c31e9c3f30a566d699 /player/scripting.c | |
parent | 41002c46f5256c170160aab5d45f2983c5bcf600 (diff) | |
download | mpv-0f110ad0e27583c5161cf27a3c17d1563253b368.tar.bz2 mpv-0f110ad0e27583c5161cf27a3c17d1563253b368.tar.xz |
stream_lavf: fix determining seekability
demux_lavf.c forces seek to being determined as supported if
STREAM_CTRL_HAS_AVSEEK is returned as success. But it always succeeds
with current FFmpeg versions. (Seems like Libav commit cae448cf broke
this in early 2016.)
Now we can't determine via private API whether the underlying protocol
supports read_seek anymore. The affected protocols (mostly rtmp) also
set seekable=0, meaning they signal they're not seekable, even though
read_seek would work. (My guess is that this can't be fixed because even
though seekable is in theory a combination of elaborate flags [of which
only 1 is defined, AVIO_SEEKABLE_NORMAL], a seekable!=0 always means
it's byte-seekable in some way.)
So the FFmpeg API is being garbage _again_, and all what we can do is
determining this via protocol name and a whitelist.
Should fix the behavior reported in #1701.
Diffstat (limited to 'player/scripting.c')
0 files changed, 0 insertions, 0 deletions