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.

Deprecated and useless.

Use static mutexes instead of requiring a lock manager. The behavior
should be roughly the same before and after this change for API users
which did not set the lock manager at all (except that a minor memory
leak disappears).

This removes the XP compatibility code, and switches entirely to SWR
locks, which are available starting at Windows Vista.

This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.

Windows XP is hereby not a supported build target anymore. It was
decided in a project vote that this is OK.

fix CID: 1426931 1426929

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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.

Fixes compilation of libavresample/x86/audio_mix.asm

Reviewed-by: Gramner
Signed-off-by: James Almer <jamrial@gmail.com>

AVX-512 consists of a plethora of different extensions, but in order to keep
things a bit more manageable we group together the following extensions
under a single baseline cpu flag which should cover SKL-X and future CPUs:
 * AVX-512 Foundation (F)
 * AVX-512 Conflict Detection Instructions (CD)
 * AVX-512 Byte and Word Instructions (BW)
 * AVX-512 Doubleword and Quadword Instructions (DQ)
 * AVX-512 Vector Length Extensions (VL)

On x86-64 AVX-512 provides 16 additional vector registers, prefer using
those over existing ones since it allows us to avoid using `vzeroupper`
unless more than 16 vector registers are required. They also happen to
be volatile on Windows which means that we don't need to save and restore
existing xmm register contents unless more than 22 vector registers are
required.

Big thanks to Intel for their support.

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes #6926
Signed-off-by: Aman Gupta <aman@tmm1.net>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

It should not be needed for each filter that sets sample aspect ratio
to set it explicitly also for each and every frame, instead that is
automatically done in get_buffer call.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: wm4 <nfxjfg@googlemail.com>

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>

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 53e0d5d7 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>

Signed-off-by: Paul B Mahol <onemda@gmail.com>