| 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).
|
|
|
|
|
| |
... 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>
|
| |
|
|
|
|
|
|
|
|
|
| |
This should refer to the existing SPS structure, not the VAAPI sequence
parameter buffer (which is not yet initialised).
From ffmpeg commit f31478ba1472afe5c1eed60f219ae331816425a2.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
| |
|
|
|
|
|
| |
SEI headers should be inserted as generic raw data (the old specific
type has been deprecated in libva2).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With pre-2.0 Intel drivers in CBR mode, if an explicit SEI message with
the old (now deprecated) type is not included, the driver generates and
inserts some timing SEI which is almost certainly invlaid. Before
7a4fac5e91789b73e07bd4ad20493cfde028df76 we always inserted our own SEI
so this would not be visible, but since then it has been possible to
disable that. We would also like to avoid using the deprecated type,
and using the new type, while working in old drivers, does not suppress
the spurious message like the old type does.
Therefore, suppress the bad SEI insertion by providing a zero-length
buffer with the old type, which the driver can insert harmlessly.
|
|
|
|
|
|
| |
This has been deprecated in libva2 because hardware does not and will not
support it. Therefore never consider it for decode, and for encode assume
the user meant constrained baseline profile instead.
|
|
|
|
|
| |
This should be ticks, not time_scale steps - it was wrong for all
framerates not a multiple of 1/2.
|
|
|
|
| |
Included by default with non-IDR intra frames.
|
|
|
|
| |
Adds a new private option to enable them (off by default).
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This avoids confusion with equivalent H.265 SEI values when both are
being used at the same time.
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
| |
Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target. Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.
|
|
|
|
|
|
|
| |
Before this change, it was possible to overflow pic_order_cnt_lsb and
generate a stream with invalid POC numbering. This makes sure that
the field is large enough that a single IDR B* P sequence uses fewer
than half the available POC lsb values.
|
|
|
|
|
|
|
|
|
|
| |
In H.264 section 8.2.1, we have that "The bitstream shall not contain
data that result in Min(TopFieldOrderCnt, BottomFieldOrderCnt) not
equal to 0 for a coded IDR frame". This fixes the encoder to always
conform to this - previously the POC values formed an unbroken
sequence, not resetting to zero on IDR frames.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
There should be an extra offset of 6 on bit_rate_scale and of 4 on
cpb_size_scale which were not accounted for here.
|
|
|
|
|
| |
This will prevent conflicts e.g. in code that deals with both h264 and
hevc.
|
|
|
|
|
|
| |
Move the NAL unit types into it. This will allow to stop including the
whole decoder-specific h264dec.h in some code that is unrelated to the
decoder and only needs some enum values.
|
|
|
|
| |
This is more consistent with the naming of other decoders.
|
|
|
|
|
| |
Contains the libavcodec version, the VAAPI version and the libva
driver vendor string.
|
|
|
|
|
| |
Send buffering_period and pic_timing messages when in modes
targetting bitrate. Also adds NAL HRD parameters to VUI.
|
|
|
|
| |
Supports aspect ratio, colour format and timing information.
|
|
|
|
|
|
| |
Experimental; requires Skylake and VAAPI 0.39.1 (not yet released).
Also increases the allowed range of the quality option - in low-power
mode, the Intel driver supports levels 1-8 (and 0 meaning default).
|
|
|
|
|
|
|
| |
Non-reference frames (nal_ref_idc == 0) should be discardable, so
frame_num does not advance after them. Before this change, a stream
containing unreferenced B-frames would be rejected by the reference
decoder.
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
|
|
| |
Only supported on VAAPI 0.36 and higher.
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>
|
|
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|