| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
| |
The iHD driver looks at entries beyond num_ref_idx_l[01]_active_minus1
for unknown reasons.
|
|
|
|
|
| |
... instead of making callers allocate it themselves. This is more
consistent with other APIs in libav.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
| |
Also fixes the default, which previously contained a nonsense value.
|
|
|
|
|
|
|
|
| |
To match vaapi_h264.
From ffmpeg commit 385cafb07ac1e46433931ea9749a134efd7350be.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
|
|
|
|
|
|
| |
This reverts commit a14a12ca137bf1526452b97bedfc9f7b301d4e04.
The CTU size is always 32x32; the surface size is what actually sets
the desired property, and it is already correct.
|
|
|
|
|
|
| |
It is not necessary to pad to the CTU size. The CB size of 8x8 should be
sufficient, but due to constraints in the Intel driver (the one usable
implementation of this) it has to be padded to 16x16 like in H.264.
|
|
|
|
| |
Matching the H.264 encoder.
|
|
|
|
|
| |
Also improves the metadata and generally makes the configuration
a bit cleaner.
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
10-bit surface support was added in libva 1.6.2, earlier versions
support H.265 encoding in 8-bit only.
|
|
|
|
| |
Same issue as 17a0f9481cf07af0feb3838ca315b970117e8000.
|
|
|
|
|
| |
Those values are decoder-independent and are also use by the VA-API
encoder.
|
|
|
|
|
|
| |
The include was changed correctly in 4abe3b049d987420eb891f74a35af2cebbf52144
but then mistakenly changed back by c359d624d3efc3fd1d83210d78c4152bd329b765
(it's not just the NAL unit types which are used).
|
|
|
|
|
|
|
| |
This way they can be reused by other code without including the whole
decoder-specific hevcdec.h
Also, add the HEVC_ prefix to them, since similarly named values exist
for H.264 as well and are sometimes used in the same code.
|
|
|
|
|
| |
This is more consistent with the rest of libav and frees up the hevc.h
name for decoder-independent shared declarations.
|
| |
|
|
|
|
|
| |
A decoder may need this to be set correctly to output frames in the
right order.
|
|
|
|
|
|
|
|
|
|
|
| |
This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit. The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|