These are supported by llvm-dlltool.
Signed-off-by: Martin Storsjö <martin@martin.st>

This reverts commit 67c72f08.

While the linker produced import libraries might work with MSVC in
simple test cases, they don't if e.g. linking to multiple GNU ld
produced import libraries at the same time. (They end up importing
functions from the wrong libraries.) The ones produced by dlltool
work fine though.

This issue was pointed out by Hendrik Leppkes.
Signed-off-by: Martin Storsjö <martin@martin.st>

Bug-Id: 1100
Bug-Id: ffmpeg/Ticket2531
Cc: libav-stable@libav.org

MFX_LOOKAHEAD_DS_UNKNOWN means auto.
-1 is not a valid value.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

AVBR is supported from API 1.3 but only available for Windows
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

The initialisation should be common.  For libmfx, it was previously
happening in the derivation function and this moves it out.

These filters do not directly know whether the API they are using will
support dynamic frame pools, so this is somewhat tricky.  If the user
sets extra_hw_frames, we assume that they are aware of the problem and
set a fixed size based on that.  If not, most cases use dynamic sizing
just like they did previously.  The hardware-reverse-mapping case for
hwmap previously had a large fixed size (64) here, primarily as a hack
for QSV use - this is removed and extra_hw_frames will need to be set
for QSV to work since it requires fixed-size pools (as the other cases
do, and which didn't work before).

The deinterlacer does not change, because it does not allocate any new
frames (for output it uses the same pool as the input).

Defaults to 10 frames to preserve compatibility, but can allocate
fewer if extra_hw_frames is set explicitly.

AVFilterContext.extra_hw_frames functions identically to the field of
the same name in AVCodecContext.

This number is definitely required when frame threading is enabled, so
add it here rather than forcing all users to handle it themselves.

DXVA2 contained this addition in specific code as well (therefore being
added twice in the internal case) - just remove it from there.

AVCodecContext.extra_hw_frames is added to the size of hardware frame
pools created by libavcodec for APIs which require fixed-size pools.
This allows the user to keep references to a greater number of frames
after decode, which may be necessary for some use-cases.

It is also added to the initial_pool_size value returned by
avcodec_get_hw_frames_parameters() if a fixed-size pool is required.

Skip a variable indirection and only redefine restrict if necessary.

This also moves the setting of the licensing string out of a block that
is skipped when quiet operation is requested.

From ffmpeg commit 9365dfcb.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

This makes sure that consumers of the side data actually can
rely on the padding as intended, without having the callers of
av_packet_new_side_data to explicitly zero initialize it.
Signed-off-by: Martin Storsjö <martin@martin.st>

Bug-Id: 1101
Cc: libav-stable@libav.org

Fix a common vp8 decoding failure.

Many vp8 clips cannot decode if hw_frames_ctx is enabled, reporting
"Error during QSV decoding.: incompatible video parameters (-14)".

It is due to mfx.FrameInfo.Width/Height not matching coded_w/coded_h.

See: avconv -hwaccel qsv -init_hw_device qsv -c:v vp8_qsv -i vp8-test-vectors-r1/vp80-00-comprehensive-001.ivf
-vf "hwdownload,format=nv12" -pix_fmt yuv420p -f md5 -
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

MediaSDK may fail to decode some frame, just skip it.
Otherwise, it will keep decoding the failure packet repeatedly
without processing any packet afterwards.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

This attribute is supported for this architecture in MSVC as well
(but produces errors if used for 32 bit x86).
Signed-off-by: Martin Storsjö <martin@martin.st>

Requires AMF headers for at least version 1.4.4.1.
Signed-off-by: Mikhail Mironov <mikhail.mironov@amd.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

It is used by the deprecated API avcodec_decode_video2 and ignored by the
new decode APIs (avcodec_send_packet/avcodec_receive_frame).
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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.