This is an ABI change in libva2: previously the Intel driver had this
behaviour and it was implemented as a driver quirk, but now it is part
of the specification so all drivers must do it.
Change the slice/parameter buffers to be allocated dynamically.
Signed-off-by: Wang, Yi A <yi.a.wang@intel.com>
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Use AVCodecContext.compression_level rather than a private option,
replacing the H.264-specific quality option (which stays only for
compatibility).
This now works with the H.265 encoder in the i965 driver, as well as
the existing cases with the H.264 encoder.
(cherry picked from commit 19388a7200e5d99c703271f05dba1c806720e808)
The non-H.26[45] codecs already use this form. Since we don't
currently generate I frames for codecs which support them separately
to IDR, the p_per_i variable is set to infinity by default so that it
doesn't interfere with any other calculation. (All the code for I
frames still exists, and it works for H.264 if set manually.)
(cherry picked from commit 6af014f4028238b4c50f1731b3369a41d65fa9c4)
Previously this was leaking, though it actually hit an assert making
sure that the buffer had already been cleared when freeing the picture.
(cherry picked from commit 17aeee5832b9188b570c3d3de4197e4cdc54c634)
Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.
(cherry picked from commit ff35aa8ca4069bf1543adeec4c28e51e4a012eee)
This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.
(cherry picked from commit f033ba470fbab1ff6838666d4d86411effa97b27)
This change makes the configured GOP size be respected exactly -
previously the value could be exceeded slightly due to flaws in the
frame type selection logic.
(cherry picked from commit 37fab0661a760b2a9d727939d72e629acee1a6ef)
Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.
This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.
This change makes the configured GOP size be respected exactly -
previously the value could be exceeded slightly due to flaws in the
frame type selection logic.
Only works if packed headers are supported, where we can know the
output before generating the first frame.
(cherry picked from commit 0cf86fabfa5820596cca2cfead63c6f8df76c3f2)
This was always too late; several fields related to it have been incorrectly
zero since the encoder was added.
(cherry picked from commit 314b421dd8910ebed7a8d419a0dbea239a00044e)
While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder. It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.
(cherry picked from commit 086e4b58b59ea3993107aa24d92bb962ec69667c)
This improves behaviour with drivers which do not support packed
headers, such as AMD VCE on mesa/gallium.
(cherry picked from commit 892bbbcdc171ff0d08d69636a240ffb95f54243c)
This allows better checking of capabilities and will make it easier
to add more functionality later.
It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.
(cherry picked from commit 80a5d05108cb218e8cd2e25c6621a3bfef0a832e)
No longer leaks memory when used with a driver with the "render does
not destroy param buffers" quirk (i.e. Intel i965).
(cherry picked from commit 221ffca6314ed3ba9d38464ea50cd85251c04e74)
Fixes ticket #5871.
* commit '8a62d2c28fbacd1ae20c35887a1eecba2be14371':
vaapi_encode: Maintain a pool of bitstream output buffers
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '11b8030309ee93d79b3a6cd4b83bf00757db1598':
vaapi_encode: Fix fallback when input does not match any format
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder. It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.
This allows better checking of capabilities and will make it easier
to add more functionality later.
It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.
Previously we would allocate a new one for every frame. This instead
maintains an AVBufferPool of them to use as-needed.
Also makes the maximum size of an output buffer adapt to the frame
size - the fixed upper bound was a bit too easy to hit when encoding
large pictures at high quality.
This prevents attempts to use unsupported modes, such as low-power
H.264 mode on non-Skylake targets. Also fixes a crash on invalid
configuration, when trying to destroy an invalid VA config/context.
These are all trivial to merge.
* commit '92fdea37477b5a2d1329e5ef0773e24473fa8f12':
vaapi_h265: Add -qp option, use it to replace use of -global_quality
vaapi_h265: Add constant-bitrate encode support
vaapi_h264: Add encode quality option (for quality-speed tradeoff)
vaapi_h264: Add -qp option, use it to replace use of -global_quality
vaapi_encode: Add support for codec-local options
vaapi_h264: Add constant-bitrate encode support
vaapi_encode: Refactor slightly to allow easier setting of global options
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>