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

The plural in the name clarifies the fact that the function
can check for multiple headers at once.

Their API and implementation is different from other require_foo() functions,
which violates the rule of least astonishment.

This fixes frame corruption issue when decoder started reusing frames
while they are still in use of encoding process

Issue with frame corruption  was reproduced using:

    avconv.exe -y -hwaccel d3d11va -hwaccel_output_format d3d11 -i input.h264 -an -c:v h264_amf output.mkv

It is recommended to use -extra_hw_frames 16 option in case if hw frames
number in pool is not enough
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Remove the wincrypt API calls since we don't support XP anymore and
bcrypt is available since Vista, even on Windows Store builds.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes building with clang in msvc mode, which does support
gcc style inline assembly.

This removes the XP compatibility code, and switches entirely to SRW
locks, which are available starting at Windows Vista.

This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.

Windows XP is hereby not a supported build target anymore.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Shift fixed point numbers to be actual decimal numbers.

Where tiny is less than the default CTU size.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Set the flag MFX_BITSTREAM_COMPLETE_FRAME when it is a progressive picture.
This can fix vc1 decoding segment fault issues because can't set the start
code correctly.

See: ./avconv -hwaccel qsv -c:v vc1_qsv -i /fate-suite/vc1/SA00040.vc1
-vf "hwdownload, format=nv12" -f rawvideo /dev/null

v2: fix some h264 interlaced clips regression
a. field_order of some h264 interlaced video (e.g: cama3_vtc_b.avc) is marked as AV_FIELD_UNKNOWN
   in h264_parser.c. This is not a completed frames.
   So only set the MFX_BITSTREAM_COMPLETE_FRAME when it is progressive.
b. some clips have both progressive and interlaced frames (e.g.CAPAMA3_Sand_F.264),
   the parsed field_order maybe changed druing the decoding progress.

This patch has been verified for other codecs(mpeg2/hevc/vp8).
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Starting from API 1.25 helps to improve performance of the simultaneous
encode, 1:N scenario, like:

./avconv  -y -hwaccel qsv -c:v h264_qsv -r 30000/1001 -i
~/bbb_sunflower_1080p_60fps_normal.mp4  -vframes 600 -an \
    -filter_complex "split=2[s1][s2]; [s1]scale_qsv=1280:720[o1];
[s2]scale_qsv=960:540[o2]" \
    -map [o1] -c:v h264_qsv -b:v 3200k -minrate 3200k -maxrate 3200k -f
rawvideo /tmp/3200a.264 \
    -map [o2] -c:v h264_qsv -b:v 1750k -minrate 1750k -maxrate 1750k -f
rawvideo /tmp/1750a.264
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Currently vpp pipeline is always created, even for the unnecessary
cases such as setting the option "vpp_qsv=w=1280:h=720" for an input
with native resolution 1280x720. Thus introduces unnecessary performance
dropping, so bypass vpp if not needed.
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Currently pict_type and key_frame are unset.
Add an extra param to fetch the picture type from qsv decoder

The judgement “key frame is equal to IDR frame” only suitable for H264.
For HEVC, all IRAP frames are key frames, and other codecs have no IDR
frame.
Signed-off-by: ChaoX A Liu <chaox.a.liu@intel.com>
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Support for it was apparently never in the codebase, and the enum
values were recently removed from the public headers [1]

Fixes build with latest libaom build.

[1] https://aomedia.googlesource.com/aom/+/3f29cc20e3a4c348cb41a797c68de856ddb84e12Signed-off-by: James Almer <jamrial@gmail.com>

Support for it was apparently never in the codebase, and the enum
values were recently removed from the public headers [1]

Fixes build with latest libaom build.

[1] https://aomedia.googlesource.com/aom/+/2e3cd5c5c30fa02134681cda900c32486807af3fSigned-off-by: James Almer <jamrial@gmail.com>

This is the same combination of .section directives as used in
aarch64/asm.S.

Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>

When targeting darwin, clang requires commas between arguments,
while the no-comma form is allowed for other targets.

Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
Signed-off-by: Martin Storsjö <martin@martin.st>

Main Profile is yuv420p 8 and 10 bit
High Profile is yuv444p 8 and 10 bit
Professional Profile is yuv422p 8, 10, and 12 bit, plus every other pixfmt at 12 bit
Signed-off-by: James Almer <jamrial@gmail.com>

Use the proper names instead of numbers
Signed-off-by: James Almer <jamrial@gmail.com>

The protocol requires libsrt (https://github.com/Haivision/srt) to be
installed
Signed-off-by: Sven Dueking <sven.dueking@nablet.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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>