Currently, audio service type is a field in AVCodecContext. However,
side data is more appropriate for this kind of information.

It is unreliable, especially when the stream codec context is not the
encoding context. Use the codec descriptor properties instead.

Handle its only existing use case internally.

It does not work correctly and apparently never did. There is no
indication that this (mis)feature is ever used in the wild or even that
any software other than the reference supports it.

Since the code that attempts to support it adds some nontrivial
complexity and has resulted in several bugs in the past, it is better to
just drop it.

They are always constructed anew when needed, so there is no need to
reset them explicitly.

Currently, it needs to be initialized by the ER caller (which is
currently either a mpegvideo decoder or h264dec). However, since none of
those decoders use MECmpContext for anything except ER, it makes more
sense to handle it purely inside ER.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

For future use by hardware accelerators.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Hardware Accelerators require access to the escaped bitstream.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This enables decode_nal_unit to access additional fields added in
subsequent commits.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Makes the example work with all the supported AAC encoders.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Prevents DPB from filling up with damaged input.

There is no point in clearing reference explicitly, since that will be
done as a part of ff_h264_unref_picture() right below.

CC: libav-stable@libav.org
Bug-Id: CID 1265713

Fix a memory leak.

CC: libav-stable@libav.org
Bug-Id: CID 717999

This partially reverts cf70ba37, since
it didn't take into account when rotation is 0, but there is another
valid operation (eg. translation) in the matrix.
Found-by: Michael Niedermayer <michaelni@gmx.at>

This improves motion estimation and avoids using uninitialized data
for resolutions that aren't a multiple of 16.

Prior to d2a25c40, the edges used to be initialized so that encoding
was deterministic, but after that commit it started using uninitialized
data (for non multiple of 16 resolutions).

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Martin Storsjö <martin@martin.st>

Previously this always used the "lld" format for all parameters,
not only time parameters.
Signed-off-by: Martin Storsjö <martin@martin.st>

It's better to steer users at these, since they are both better
and more alive than the mingw.org versions.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This avoids needing an attribute for silencing warnings about
it being unused.
Signed-off-by: Martin Storsjö <martin@martin.st>

libopenh264enc: Remove a workaround for silencing warnings about unused variables in the OpenH264 header

The 1.3 release branch of OpenH264 (as well as the master branch)
have been updated so that GCC no longer warns about this variable
as being unused.
Signed-off-by: Martin Storsjö <martin@martin.st>

This goto wasn't necessary originally, but it should have been
added when the write_manifest call was added in 8e276378.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes sending chunked packets (packets larger than the output
chunk size, which often can be e.g. 4096 bytes) with a timestamp delta
(or absolute timstamp, if it's a timestamp step backwards, or the
first packet of the stream) larger than 0xffffffff.

The RTMP spec explicitly says (in section 5.3.1.3.) that packets of
type 3 (continuation packets) should include this field, if the
previous non-continuation packet had it included.

The receiving code handles these packets correctly.

Pointed out by Cheolho Park.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>