Similar indirections are used for the -o compiler/assembler flag to
account for differences in compiler/assembler syntax. For x86asm half
the infrastructure for doing the same currently exists unused.
Finish and use that infrastructure for consistency.

Per MediaSDK documentation, it requires width/height to 16 alignment.
Without this patch, hwupload pipeline may fail if 16 alignment is
not met. Although this patch also apply 16 alignment to qsv encoder/decoder,
it will not bring any side-effect to them as they are already aligned.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

With GCC, request it to maintain 16 byte alignment, and the existing
entry points already align it via attribute_align_arg.

With clang, do the same as for mingw; disable the aligned stack
and let the assembly functions that require it do the alignment
instead.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

If we'd enable a 16 byte aligned stack, clang/llvm would also assume
that alignment everywhere and produce code that strictly requires it.
That would require adding realignment (via attribute_align_arg) on every
single public library function or enable -mstackrealign (which does the
same on every single function).

Also relatedly; the parameter currently tested (-mllvm
-stack-alignment=16) hasn't actually been supported for quite some
time; current clang versions use -mstack-alignment=16 for the same.
Actually testing for that parameter would be a different change
though, since it has a real risk of changing behaviour on any other
platform where clang is used.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Previously the bit pattern for the endianness test was declared as a
global, instead of a local, variable. This ensures that the pattern
appears unchanged in the object file and is not optimized out.

AMFTraceWriter is an abstraction to configure how AMF outputs its logs
for the current process and can be configured to output different levels
of trace output. If multiple LibavWriter objects are used in one process,
there will be duplication of output in av_log. Use a constant writer_id
to prevent this scenario.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Fail if AMF is requested but unavailable, as we do for all
other external libraries that need to be explicitly enabled.

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

It seems to improve the compatibility with the js demuxers.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Currently it always shows "Selected ratecontrol mode is not supported
by the QSV runtime. Choose a different mode", but sometimes it is not
accurate.
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

If configure fails before config.fate is generated, the report file misses
some values and gets discarded by the FATE server. In these cases, print
those values as "failed" along with the failing configure command line.

Bug-Id: 1116
Cc: libav-stable@libav.org
Signed-off-by: James Almer <jamrial@gmail.com>

The PicStruct is required by MediaSDK, so give a default value.
hwupload does not work without this.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Deletes both filler NAL units and filler SEI messages.  (Annex B zero_bytes
between NAL units are already discarded by the read/write process.)

It's very large, and is only used in some FMO streams.

This should be added even if the first access unit does not contain
parameter sets.

This makes it easier for users of the CBS API to get alloc/free right -
all subelements use the buffer API so that it's clear how to free them.
It also allows eliding some redundant copies: the packet -> fragment copy
disappears after this change if the input packet is refcounted, and more
codec-specific cases are now possible (but not included in this patch).

If there is exactly one possible SPS but it is not yet active then just
assume that it should be the active one.

This is harmless and should not be a warning - unknown units are passed
through to the write functions unchanged, and no other code will interact
with them.