These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With the necessary pixel formats defined, we can now expose support for
the remaining 10/12bit combinations that VAAPI can handle.
Specifically, we are adding support for:
* HEVC
** 12bit 420
** 10bit 422
** 12bit 422
** 10bit 444
** 12bit 444
* VP9
** 10bit 444
** 12bit 444
These obviously require actual hardware support to be usable, but where
that exists, it is now enabled.
Note that unlike YUVA/YUVX, the Intel driver does not formally expose
support for the alphaless formats XV30 and XV360, and so we are
implicitly discarding the alpha from the decoder and passing undefined
values for the alpha to the encoder. If a future encoder iteration was
to actually do something with the alpha bits, we would need to use a
formal alpha capable format or the encoder would need to explicitly
accept the alphaless format.
As vaapi doesn't actually do anything useful with the alpha channel,
and we have an alphaless format available, let's use that instead.
The changes here are mostly 1:1 switching, but do note the explicit
change in the number of declared channels from 4 to 3 to reflect that
the alpha is being ignored.
Sufficiently recent Intel hardware is able to do encoding of 8bit 4:4:4
content in HEVC and VP9. The main requirement here is that the frames
must be provided in the AYUV format.
Enabling support is done by adding the appropriate encoding profiles
and noting that AYUV is officially a four channel format with alpha so
we must state that we expect all four channels.
Add support for max frame size:
- max_frame_size (bytes) to indicate the max allowed size for frame.
Control each encoded frame size into target limitation size by adjusting
whole frame's average QP value. The driver will use multi passes to
adjust average QP setp by step to achieve the target, and the result
may not strictly guaranteed. Frame size may exceed target alone with
using the maximum average QP value. The failure always happens on the
intra(especially the first intra frame of a new GOP) frames or set
max_frame_size with a very small number.
example cmdline:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
-v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
-c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
-bf 3 -max_frame_size 40000 -vframes 100 -y ./max_frame_size.h264
Max frame size was enabled since VA-API version (0, 33, 0), but query
is available since (1, 5, 0). It will be passed as a parameter in picParam
and should be set for each frame.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
The block size can be dependent on the profile and entrypoint selected.
It defaults to 16x16, with codecs able to override this choice with their
own function.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Use GPB frames to replace regular P/B frames if backend driver does not
support it.
- GPB:
Generalized P and B picture. Regular P/B frames replaced by B
frames with previous-predict only, L0 == L1. Normal B frames
still have 2 different ref_lists and allow bi-prediction
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
decrease. The reason is that vaRenderPicture() and vaSyncBuffer() are
called at the same time (vaRenderPicture() always followed by a
vaSyncBuffer()). Now I changed them to be called in a asynchronous way,
which will make better use of hardware.
Async_depth is added to increase encoder's performance. The frames that
are sent to hardware are stored in a fifo. Encoder will sync output
after async fifo is full.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Add vaSyncBuffer to VAAPI encoder. Old version API vaSyncSurface wait
surface to complete. When surface is used for multiple operation, it
waits all operations to finish. vaSyncBuffer only wait one channel to
finish.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Fixes ticket #9537.
Probably a regression since 2b3206891649f317c20993411efef4bee39ae784.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Announced in 14040a1d913794d9a3fd6406a6d8c2f0e37e0062.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit 489c5db0791f39518775b12eef6d48276c17f96f.
Treating EQUAL_MULTI_ROWS in the same way as the arbitrary-size cases is
just wrong. Consider 9 rows, 4 slices - we pick 4 slices with sizes
{ 3, 2, 2, 2 }, which EQUAL_MULTI_ROWS does not allow. It isn't possible
to split the frame into 4 slices at all with the EQUAL_MULTI_ROWS
structure - the closest options are 3 slices with sizes { 3, 3, 3 } or 5
slices with sizes { 2, 2, 2, 2, 1 }.
Add functions to initialize tile slice structure and make tile slice:
- vaapi_encode_init_tile_slice_structure
- vaapi_encode_make_tile_slice
Tile slice is not allowed to cross the boundary of a tile due to
the constraints of media-driver. Currently adding support for one
slice per tile.
N x N tile encoding is supposed to be supported with the the
capability of ARBITRARY_MACROBLOCKS slice structures.
N X 1 tile encoding should also work in ARBITRARY_ROWS slice
structure.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Wrap current whole-row slice codes into following functions:
- vaapi_encode_make_row_slice()
- vaapi_encode_init_row_slice_structure()
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
VA_ENC_SLICE_STRUCTURE_EQUAL_MULTI_ROWS is added to in the latest
libva (1.8.0) which matches the hardware behaviour:
/** \brief Driver supports any number of rows per slice but they must
* be the same for all slices except for the last one, which must be
* equal or smaller to the previous slices.
*/
And VA_ENC_SLICE_STRUCTURE_EQUAL_ROWS is kind of deprecated for iHD
since it's somehow introduced in [1] which is misleading from what we
actually handles.
[1]<0e6d5441f1>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.
amf encoders adapted by James Almer
librav1e encoder adapted by James Almer
nvidia encoders adapted by James Almer
MediaFoundation encoders adapted by James Almer
vaapi encoders adapted by Linjie Fu
v4l2_m2m encoders adapted by Andriy Gelman
Signed-off-by: James Almer <jamrial@gmail.com>
ff_vaapi_encode_close() is not enough to free the resources like cbs
if initialization failure happens after codec->configure (except for
vp8/vp9).
We need to call avctx->codec->close() to deallocate, otherwise memory
leak happens.
Add FF_CODEC_CAP_INIT_CLEANUP for vaapi encoders and deallocate the
resources at free_and_end inside avcodec_open2().
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Currently, assigning new buffer for pkt when multiple buffers were returned
from vaMapBuffer will overwrite the previous encoded pkt data and lead
to encode issues.
Iterate through the buf_list first to find out the total buffer size
needed for the pkt, allocate the whole pkt to avoid repeated reallocation
and memcpy, then copy data from each buf to pkt.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
This was a regression in 5fdcf85bbffe7451c227478fda62da5c0938f27d
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This removes the use of the nonstandard combined structures, which
generated some warnings with clang and will cause alignment problems
with some parameter buffer types.
This attaches the logic of picking the mode of for the next picture to
the output, which simplifies some choices by removing the concept of
the picture for which input is not yet available. At the same time,
we allow more complex reference structures and track more reference
metadata (particularly the contents of the DPB) for use in the
codec-specific code.
It also adds flags to explicitly track the available features of the
different codecs. The new structure also allows open-GOP support, so
that is now available for codecs which can do it.
This adds common code to query driver support and set appropriate
address/size information for each slice. It only supports rectangular
slices for now, since that is the most common use-case.
Add a larger warning more clearly explaining the consequences of missing
packed header support in the driver. Also only write the extradata if the
user actually requests it via the GLOBAL_HEADER flag.
Choose what types of reference frames will be used based on what types
are available, and make the intra-only mode explicit (GOP size one,
which must be used for MJPEG).
This was added in libva 2.1.0 (VAAPI 1.1.0). Use AVCodecContext.qmax,
matching the existing behaviour for qmin, and clean up the defaults so
that we only pass min/max when explicitly set.
Query which modes are supported and select between VBR and CBR based
on that - this removes all of the codec-specific rate control mode
selection code.
The codec sequence headers may contain fields which can overwrite the
fine parameters given in the specific settings (e.g. a crude bitrate
value vs. the max-rate / target-percentage / etc. values in
VAEncMiscParameterRateControl). Always reapply all global parameters
after a sequence header to avoid this causing problems.
Previously there was one fixed choice for each codec (e.g. H.265 -> Main
profile), and using anything else then required an explicit option from
the user. This changes to selecting the profile based on the input format
and the set of profiles actually supported by the driver (e.g. P010 input
will choose Main 10 profile for H.265 if the driver supports it).
The entrypoint and render target format are also chosen dynamically in the
same way, removing those explicit selections from the per-codec code.
