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>

Does not work. Even emits a warning with some compilers that the
attribute does not work on enums. It's likely that there is way to make
it work, but not worth the trouble.

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>

Fixes a segfault when reading a live playlist (without end tag) from non-http url (like a file on disk).
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>

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

This partially reverts a change in behavior introduced in 2a111c99.
Signed-off-by: James Almer <jamrial@gmail.com>

video_format is not used.

Fixes: runtime error: left shift of negative value -180
Fixes: 4626/clusterfuzz-testcase-minimized-5647837887987712

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: signed integer overflow: 2147483646 + 33554433 cannot be represented in type 'int'
Fixes: 4563/clusterfuzz-testcase-minimized-5438979567517696

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

x264 now supports multibitdepth builds, with a slightly changed API to
request bitdepth during initialization.
Reviewed-by: Ricardo Constantino <wiiaboo@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

The x264_bit_depth constant has been removed in newer x264 builds.
Signed-off-by: James Almer <jamrial@gmail.com>

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

This provides a generic way to the API user to deal with files that
either lack this SEI, or which have the SEI only in packets not passed
to the decoder (such as the common case of the SEI being in the very
firsat video packet, but decoding is started somewhere in the middle of
the file). Bugs like 840b41b2 make this
somewhat of a necessity.

This intentionally uses the version in the SEI instead, if any is found.

This is just a lot of complicated and confusing code that had no purpose
anymore.

Also, the functions return values were checked only sometimes. Locking
shouldn't fail anyway, so remove the return values. Barely any other
pthread lock calls check the return value (including more important code
that is more likely to fail horribly if locking fails).

It could be argued that it might be helpful in some debugging
situations, or when the user built FFmpeg without thread support against
all good advice.

But there are dummy atomics too, so the atomic check won't help with
ensuring correctness absolutely. You gain very little.

Also, for debugging, you can just raise the ASSERT_LEVEL, and then
libavutil/thread.h will redefine the locking functions to explicitly
check the return values.

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.