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.
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>
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>
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>
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 7cb9296db8 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>
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 should refer to the existing SPS structure, not the VAAPI sequence
parameter buffer (which is not yet initialised).
From ffmpeg commit f31478ba14.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
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=1103
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
