It is benefit to diagnose issues related to different libmfx version.
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

It has native simultaneus 8 and 10 bit support.

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

Removes specific support for all hwaccels supported by the generic code
(CUVID, DXVA2, D3D11VA, VAAPI and VDPAU).

They are now unused.

There is no longer any need for a list of them at runtime, because
decoders now carry the pointers to their associated hwaccels internally.
The file containing external declarations is now used to make the list
of hwaccels for configure.

This removes the dependency that hardware pixel formats previously had on
AVHWAccel instances, meaning only those which actually do something need
exist after this patch.

Also updates avcodec_default_get_format() to be able to choose hardware
formats if either a matching device has been supplied or no additional
external configuration is required, and avcodec_get_hw_frames_parameters()
to use the hardware config rather than searching the old hwaccel list.

ff_get_format() in the next patch will reject formats which aren't in the
offered list, so the hack in 7cb9296d is
no longer valid.  Change the hack by adding a new field in the VP8 decoder
context to indicate that it's actually WebP and don't call ff_get_format()
at all in that case.

This includes a pointer to the associated hwaccel for decoders using
hwaccels - these will be used later to implement the hwaccel setup
without needing a global list.

Also added is a new file listing all hwaccels as external declarations -
this will be used later to generate the hwaccel list at configure time.

Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.

Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.

AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.

Based on a patch by Philip Langdale <philipl@overt.org>.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Hypothetical Reference Decoding (HRD) model assumes that data flows
into a buffer of the fixed size BufferSizeInKB with a constant bitrate.
Smaller BufferSizeInKB means smaller frame size variations,
but more difficult to maintain HRD.
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

This fixes fate-checkasm-hevc_mc on ARMCC 5.0 after adding
NEON HEVC MC assembly.
Signed-off-by: Martin Storsjö <martin@martin.st>

Checkasm timings:
block size bitdepth  C       NEON
4           8 bit:    146.7   48.7
           10 bit:    146.7   52.7
8           8 bit:    430.3   84.4
           10 bit:    430.4  119.5
12          8 bit:    812.8  141.0
           10 bit:    812.8  195.0
16          8 bit:   1499.1  268.0
           10 bit:   1498.9  368.4
24          8 bit:   4394.2  574.8
           10 bit:   3696.3  804.8
32          8 bit:   5108.6  568.9
           10 bit:   4249.6  918.8
48          8 bit:  16819.6 2304.9
           10 bit:  13882.0 3178.5
64          8 bit:  13490.8 1799.5
           10 bit:  11018.5 2519.4
Signed-off-by: Martin Storsjö <martin@martin.st>

Also fixes the default, which previously contained a nonsense value.

Also fixes a bug where it could attempt to decode with an unsupported
codec if allow-profile-mismatch was set.

This should refer to the existing SPS structure, not the VAAPI sequence
parameter buffer (which is not yet initialised).

From ffmpeg commit f31478ba.
Signed-off-by: Mark Thompson <sw@jkqxz.net>

To match vaapi_h264.

From ffmpeg commit 385cafb0.
Signed-off-by: Mark Thompson <sw@jkqxz.net>

These may be read by the bitstream reader, so they should include the
necessary padding for overreads.

Fix suggested by Luca Barbato.

This was causing spurious EOFs when using -rtsp_transport udp, as
reported in https://bugzilla.libav.org/show_bug.cgi?id=1103Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Implement detection in h264 and hevc and insertion in framepack filter.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

As defined by the specification.

Moving option definition to h264 implementation and fixing command line defaults
in order to properly respect cavlc input value
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

Software plugin is not available on Linux, Only works on Windows.
Similar changes have been applied to qsv hevc encoder by
b05128f3.
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

The only purpose of dllexport (which is set while building the library
that exports the symbols) is to have the linker automatically
export such symbols into a DLL without using a def file - it doesn't
affect the generated code.

For both MSVC and mingw builds, this isn't essential since we override
what symbols to export via an autogenerated def file instead.

Update a comment in configure to refer to the right concept.

With lld, this avoids warnings about duplicate export directives,
when some symbols are requested to be exported both via dllexport
attributes and via the autogenerated def file.

This also reduces the number of lines of code marginally.
Signed-off-by: Martin Storsjö <martin@martin.st>

This avoids having to use either "dumpbin -headers" to find out
the current architecture, or pass $ARCH from configure to deduce it.

When configuring with --disable-asm, ARCH is equal to "c", which doesn't
give any indication of what symbol prefix is to be used.
Signed-off-by: Martin Storsjö <martin@martin.st>

- Move a variable closer to where it is used
- Add an explanatory comment
- Simplify a crosscompile check
- Minor SHFLAGS simplification
- Coalesce some threads tests

It must imply clean. Regression since 7ebe7e8e.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>