Signed-off-by: Diego Biurrun <diego@biurrun.de>

hevc seems to be the only place where the C implementation
of the av_clip function is explicitly selected, precluding
platform-specific optimizations

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

The scaling list can be specified in either the SPS or PPS.
Additionally, compensate for the diagonal scan permutation applied
in the decoder.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Some files contain a few additional, all-0 bits.
Check for that case and don't print incorrect "not supported"
message.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Alex Converse <alex.converse@gmail.com>

Based in part on work from Niel van der Westhuizen <espes@pequalsnp.com>.

It can be less than -1.

Bug-Id: CID 1194397 / CID 1194398
CC: libav-stable@libav.org

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

It will be reused by the AAC decoder.

This fixes builds with vc1_parser enabled without vc1_decoder. All
the vc1_decoder object files were included in the vc1_parser line
in libavcodec/Makefile before, but architecture specific object files
for vc1_decoder were not.

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

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

This prevents several uninitialized variable uses that take
place towards the end of encoding.

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

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Error out in case of unknown values.

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

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

CC: libav-stable@libav.org

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

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>

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>

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.

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: 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>

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>