| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This removes the arbitrary limit on the allowed number of slices and
parameter buffers.
From ffmpeg commit e4a6eb70f471eda36592078e8fa1bad87fc9df73.
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.
|
|
|
|
|
|
|
| |
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 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.
|
|
|
|
|
| |
This improves behaviour with drivers which do not support packed
headers, such as AMD VCE on mesa/gallium.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|