summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-11-16 13:15:45 +0100
committerwm4 <wm4@nowhere>2019-11-16 13:15:45 +0100
commitb6413f82b22b5c3bd7b0a4fec28fdd2625feaf94 (patch)
tree9947c7ca0acc90c15655503853cbaa0130016ec1 /player/video.c
parent8d4e012bfa622c2ec0cb9972c49c51f525edb744 (diff)
downloadmpv-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 'player/video.c')
0 files changed, 0 insertions, 0 deletions