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.

The iHD driver looks at entries beyond num_ref_idx_l[01]_active_minus1
for unknown reasons.

The buffers are created associated with the context, so they should be
destroyed before the context is.  This is enforced by the iHD driver.

This removes the arbitrary limit on the allowed number of slices and
parameter buffers.

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

Also fix conversion specifiers used for the unit type.

... instead of making callers allocate it themselves.  This is more
consistent with other APIs in libav.

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.