LongChair / FFmpeg

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Karthick Jeyapal <kjeyapal@akamai.com>

Fixes ticket #6935.

Raises the maximum resolution from 2716x2707 to approximately 4096x4095.

Fixes ticket #6795.

* commit 'c6558e8840fbb2386bf8742e4d68dd6e067d262e':
  x264: Support version 153

See
2a111c9
7e60c74

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

* commit '2beba58e0e4bda688bf96e12413231607ceafdd4':
  mmaldec: Fix compilation after 2fcb009

This commit is a noop, see 758fbc5

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

* commit 'ddea22a684611c1fec9d8b5c70d835e983a9252e':
  avconv: Use codec hardware config to configure hwaccels
  lavc: Mark all AVHWAccel structures as const
  lavc: Delete all fake hwaccels
  lavc: Remove register mechanism for hwaccels
  lavc: Deprecate av_hwaccel_next() and av_register_hwaccel()
  lavc: Use hardware config information in ff_get_format()
  webp: Fix alpha initialisation
  lavc: Add hardware config metadata for decoders supporting hardware output
  lavc: Add codec metadata to indicate hardware support

This commit is a noop, see
24cc0a5
758fbc5
9f00fa5
67e81d7
3536a3e
9bd326a
da4e02b
3a71bcc
b0cd14f

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

It has native simultaneus 8 and 10 bit support.

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>

… not available

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>

…time

This partially reverts a change in behavior introduced in 2a111c9.

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/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

…OSE_DD137iL0()

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/ffmpeg
Signed-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 840b41b 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