Use new H264Ref.reference field to track field picture flags. The
H264Picture.reference flag in DPB is now irrelevant here.

This is a regression from git commit a12d3188, and that affected
multiple interlaced video streams.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Further simplifications by Martin Storsjö, to minimize the
diff.
Signed-off-by: Martin Storsjö <martin@martin.st>

Instead use our own struct, which we already use when using
gcrypt and gnutls.

In OpenSSL 1.1, the DH struct has been made opaque.
Signed-off-by: Martin Storsjö <martin@martin.st>

sigaction is not defined in standards as a struct starting with another
struct. Some *BSD variants do however, resulting in a warning from the
zero initialization, which this change eliminates.

This partially reverts a92be9b8.

Initially written by Pierre Edouard Lepere <Pierre-Edouard.Lepere@insa-rennes.fr>,
extended by James Almer <jamrial@gmail.com>.
Signed-off-by: Alexandra Hájková <alexandra@khirnov.net>

For 'nclx', the latest edition of the standard switched from JPEG XR
to 23001-8, which matches the current order of our entries. Bounds
are preserved as a sanity check.

For 'nclc', qtff edition 2016-09-13 introduced a few new entries.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

It didn't take into account the new pattern used for bitstream filters
and protocols.

Those values are decoder-independent and are also use by the VA-API
encoder.

Avoids superfluous error message spam after
8e2ea691

Its single forward declaration can be moved to the only place
it is used, like is done for all other dsp init files.

libavcodec/x86/videodsp.asm:128: warning: signed dword value exceeds bounds

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

x29 (FP) is a callee saved register and should be restored on
return. Instead of backing up x29 and restoring it here, back up
sp in a register that we are allowed to overwrite.

This fixes crashes in checkasm on aarch64 since f1b3e131.
For some reason, gcc builds didn't crash, but clang builds do.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The variable needs to be reset for each subdirectory.

Only works if packed headers are supported, where we can know the
output before generating the first frame.

The include was changed correctly in 4abe3b04
but then mistakenly changed back by c359d624
(it's not just the NAL unit types which are used).

This fixes many warnings of the sort
warning: label alone on a line without a colon might be in error

They only contain one line and will never contain more.

And move the asm recipe to the top-level Makefile next to the other
local pattern rules for .o files.

This, combined with clobbering the stack space prior to the call,
increases the chances of finding cases where 32 bit parameters
are erroneously treated as 64 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

Even if MAX_ARGS - 2 (for arm) or MAX_ARGS - 7 (for aarch64) parameters
are passed on the stack to checkasm_checked_call, we actually only
need to store MAX_ARGS - 4 (for arm) or MAX_ARGS - 8 (for aarch64)
parameters on the stack when calling the tested function.
Signed-off-by: Martin Storsjö <martin@martin.st>

This also fixes a minor bug introduced in the codecpar conversion, where
the termination condition for extracting the extradata does not match
the actual extradata setting code. As a result, the packet durations
made up by lavf go back to their values before the codecpar conversion.
That is of little consequence since that code should eventually be
dropped completely.

This is intended as a replacement for the 'split' function exported by
some parsers.

This code is independent from the decoder, so it makes more sense for it
to to have its own header.

This will be useful in the following commits.

This way they can be reused by other code without including the whole
decoder-specific hevcdec.h
Also, add the HEVC_ prefix to them, since similarly named values exist
for H.264 as well and are sometimes used in the same code.

This is more consistent with the rest of libav and frees up the hevc.h
name for decoder-independent shared declarations.

The spec says

9: Interlaced with bottom field displayed first and top field stored first
14: Interlaced with top field displayed first and bottom field stored first

And avcodec.h states

AV_FIELD_TB,          //< Top coded first, bottom displayed first
AV_FIELD_BT,          //< Bottom coded first, top displayed first
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This is consistent with what file_open() does.

CC: libav-stable@libav.org

According to the public RTMP specification, these 4 bytes should
be zero.

librtmp in server mode assumes that the RTMPE (FP9) handshake is
used if these bytes are nonzero.
Signed-off-by: Martin Storsjö <martin@martin.st>