summaryrefslogtreecommitdiffstats
path: root/player
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-09-26 14:45:55 +0200
committerwm4 <wm4@nowhere>2016-09-26 16:49:35 +0200
commit0f110ad0e27583c5161cf27a3c17d1563253b368 (patch)
tree104289fc48d70a2d482851c31e9c3f30a566d699 /player
parent41002c46f5256c170160aab5d45f2983c5bcf600 (diff)
downloadmpv-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')
0 files changed, 0 insertions, 0 deletions