Fixes several warnings from -Wformat.

libavcodec/hapenc.c:121:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Wformat=]
libavcodec/hapenc.c:121:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘size_t {aka unsigned int}’ [-Wformat=]

This also kills some warnings with certain compiler options.

The code has little usefulness and uses the __PRETTY_FUNCTION__ GNU extension.

The output is rather silly and the code uses non-standard __FUNCTION__.

libavcodec/h264_loopfilter.c:531:111: warning: variable 'edge' is uninitialized when used here [-Wuninitialized]

libavcodec/mpegaudiodec_template.c:885:97: warning: variable 'x' is uninitialized when used here [-Wuninitialized]

Since avversion.h is a generated header it must be created before
dependencies can be determined as a side effect of compilation.
Otherwise Make stops and restarts the build process to generate
avversion.h and produces related error messages.

When the macro is expanded with a semicolon following it and the
macro itself contains a semicolon, we ended up in double semicolons,
which is treated as a statement that disallows further declarations.

This avoids errors about mixed declarations and statements on gcc,
after ee050797.
Signed-off-by: Martin Storsjö <martin@martin.st>

Useful to test protocols that require options to be used.

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

The buffer map/unmap code was in an early version of this before it
was committed, but the unmap was never removed.  While wrong, this
was harmless (and therefore unnoticed) because the buffers can't be
mapped at this point - all drivers just did nothing with the call.

When decoding interlaced pictures, the structure is reused to render
to the same surface twice.  The parameter buffers were not being
cleared, which caused the i965 driver to error out.

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>