diff options
author | wm4 <wm4@nowhere> | 2019-11-16 13:15:45 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-11-16 13:15:45 +0100 |
commit | b6413f82b22b5c3bd7b0a4fec28fdd2625feaf94 (patch) | |
tree | 9947c7ca0acc90c15655503853cbaa0130016ec1 /osdep | |
parent | 8d4e012bfa622c2ec0cb9972c49c51f525edb744 (diff) | |
download | mpv-b6413f82b22b5c3bd7b0a4fec28fdd2625feaf94.tar.bz2 mpv-b6413f82b22b5c3bd7b0a4fec28fdd2625feaf94.tar.xz |
demux_lavf: fight ffmpeg API some more and get the timeout set
It sometimes happens that HLS streams freeze because the HTTP server is
not responding for a fragment (or something similar, the exact
circumstances are unknown). The --timeout option didn't affect this,
because it's never set on HLS recursive connections (these download the
fragments, while the main connection likely nothing and just wastes a
TCP socket).
Apply an elaborate hack on top of an existing elaborate hack to somehow
get these options set. Of course this could still break easily, but hey,
it's ffmpeg, it can't not try to fuck you over. I'm so fucking sick of
ffmpeg's API bullshit, especially wrt. HLS.
Of course the change is sort of pointless. For HLS, GET requests should
just aggressively retried (because they're not "streamed", they're just
actual files on a CDN), while normal HTTP connections should probably
not be made this fragile (they could be streamed, i.e. they are backed
by some sort of real time encoder, and block if there is no data yet).
The 1 minute default timeout is too high to save playback if this
happens with HLS.
Vaguely related to #5793.
Diffstat (limited to 'osdep')
0 files changed, 0 insertions, 0 deletions