fix CID: 1426991
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
There is no POSIX error code for EOF - recv() signals EOF by simply
returning 0. But libavformat recently changed its conventions and
requires an explicit AVERROR_EOF, or it might get into an endless retry
loop, consuming 100% CPU while doing nothing.
pts_wrap_bits defaults to 33 (like MPEG), that causes valid
timestamps to be unwrapped and become invalid.
Inspired by a patch by Wu Zhiqiang <mymoeyard@gmail.com>.
Encrypted HLS segments have regular http:// urls, but open_input()
actually prefixes them with crypto+ before calling open_url(), so
they end up using the crypto protocol and not the http protocol.
This means invoking ff_http_do_new_request will fail, so we avoid
calling it in the first place. After the earlier http.c commit,
the failure results in a warning printed to the user. In earlier
versions, the failure would cause a segfault.
Signed-off-by: Aman Gupta <aman@tmm1.net>
This is required for AV playout from master.m3u8.
Otherwise master.m3u8 lists only video-only and/or audio-only streams.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Some http/1.0 implementations, like python's SimpleHTTPServer, can only support one client connection at a time. Making a second request while the first is still connected leads to a deadlock.
This change enables multiple connections for http/1.1 servers only, which need to support keepalive by default and should have no problem with concurrent requests.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Can be used by the api user to figure out what http features the server supports based on the response received.
Signed-off-by: Aman Gupta <aman@tmm1.net>
This makes do_new_request fail early when dealing with a http/1.0 server, avoiding unnecessary "reconnecting" warnings shown to the user.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Fixes compile error when building with network or protocols disabled.
This code would never be reached (because the demuxer fails much earlier on http playlists or segments), so it doesn't matter much what we do here as long as it compiles.
Signed-off-by: Aman Gupta <aman@tmm1.net>
It's completely absurd that libavcodec would care about libavformat
locking, but it was there because the lock manager was in libavcodec.
This is more stright forward. Changes ABI, but we don't require ABI
compatibility currently.
Currently http end of chunk is signalled implicitly in hlsenc_io_open().
This mean playlists http writes would have to wait upto a segment duration to signal end of chunk causing delays.
This patch will fix that problem and improve performance.
AVERROR_EOF is an internal error which means the http socket is no longer
valid for new requests. It informs the caller that a new connection must
be established, and as such does not need to be surfaced to the user as
a warning.
Signed-off-by: Aman Gupta <aman@tmm1.net>
This fixes a deadlock when using the hls demuxer's new http_persistent feature
to stream a youtube live stream over HTTPS. The youtube servers are http/1.1
compliant, but return a "Connecton: close". Before this commit, the demuxer
would attempt to send a new request on the partially shutdown connection and
cause a deadlock in the tls protocol.
Signed-off-by: Aman Gupta <aman@tmm1.net>
This improves network throughput of the hls demuxer by avoiding
the latency introduced by downloading segments one at a time.
The problem is particularly noticable over high-latency network
connections: for instance, if RTT is 250ms, there will a 250ms idle
period between when one segment response is read and the next one
starts.
The obvious solution to this is to use HTTP pipelining, where a
second request can be sent (on the persistent http/1.1 connection)
before the first response is fully read. Unfortunately the way the
http protocol is implemented in avformat makes implementing pipleining
very complex.
Instead, this commit simulates pipelining using two separate persistent
http connections. This has the advantage of working independently of
the http_persistent option, and can be used with http/1.0 servers as
well. The pair of connections is swapped every time a new segment starts
downloading, and a request for the next segment is sent on the secondary
connection right away. This means the second response will be ready and
waiting by the time the current response is fully read.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
This teaches the HLS demuxer to use the HTTP protocols
multiple_requests=1 option, to take advantage of "Connection:
Keep-Alive" when downloading playlists and segments from the HLS server.
With the new option, you can avoid TCP connection and TLS negotiation
overhead, which is particularly beneficial when streaming via a
high-latency internet connection.
Similar to the http_persistent option recently implemented in hlsenc.c
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
This mimics logging that was added in 53e0d5d724 for security
purposes.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will prevent improper use of ff_http_do_new_request() if the user
tries to send a request for a different host to a previously connected
persistent http/1.1 connection.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Karthick J <kjeyapal@akamai.com>
Before this patch persistent http connections would work only for media segments.
The playlists were still opening a new connection everytime.
This patch extends persistent http connections to playlists as well.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
