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 ff35aa8ca4)
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 37fab0661a)
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 80a5d05108)
* commit '8a62d2c28fbacd1ae20c35887a1eecba2be14371':
vaapi_encode: Maintain a pool of bitstream output buffers
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
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.
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>
Mark Thompson
Mark ThompsonandMark Thompson
Hendrik Leppkes
Clément Bœsch
Derek Buitenhuis
