Increased max values of periodic key frame for h26x codecs.
This allow more fine tunning of encoder that in certian scenario
want higher periodic key frame.
For example: it doesn't want a key frame each 10 seconds but
each 120 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=786320
Frames are encoded as different layers. Frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.
B-frames, except the one in top most layer, are reference frames.
All the base layer frames are I or P.
eg: with 3 temporal layers
T3: B1 B3 B5 B7
T2: B2 B6
T1: I0 P4 P8
T1, T2, T3: Temporal Layers
P1...Pn: P-Frames:
B1...Bn: B-frames:
T1: I0->P4 , P4->P8 etc..
T2: I0--> B2 <-- P4
T3: I0--> B1 <-- B2, B2 --> B3 <-- P4
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Frames are encoded as different layers. A frame in a particular
layer will use pictures in lower or same layer as references.
Which means decoder can drop the frames in upper layer but still
decode lower layer frames.
eg: with 3 temporal layers
T3: P1 P3 P5 P7
T2: P2 P6
T1: P0 P4 P8
T1, T2, T3: Temporal Layers
P1...pn: P-Frames:
P0->P1 , P0->P2, P2->P3, P0->P4......repeat
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
The frame_num generation was not correctly implemented.
According to h264 spec, frame_num should get incremented
for each frame if previous frame is a referece frame.
For eg: IPBPB sequece should have the frame numbers 0,1,2,2,3
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds new property "prediction-type" to select different reference
picture selection modes like hierarchical-p, hierarchical-b etc.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds some basic building blocks to ease the implementation
of hierarchical prediction modes.
-- add an utility method to find temporal level of each frame
-- define max_ref_frame count based on temporal level count
-- add temporal_level_div[] for finding temporal level each frame
to be encoded.
-- find ip_period based on temporal level count
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Adds new property "temporal-levels" to select the number of
temporal levels to be included in the encoded stream.
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788918
Instead of handling the macroblock bitrate control as a integer, this
patch changes it as a enum, which is more self documented in the
GStreamer elements.
https://bugzilla.gnome.org/show_bug.cgi?id=787855
Creates 2 properties, qp-ip and qp-ib for setting different QP for P/B
frames
and set slice_qp_delta for each frame according to the value provided.
In addition, remove the limitation of (<= 4) when setting
slice_qp_delta.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Creates new variable for QP for I frame and keep it at configuration and
use this for pic_init_qp and slice_qp_delta setting.
Since changing min qp doesn't make sense, keep min qp as is.
https://bugzilla.gnome.org/show_bug.cgi?id=785923
Follows the specification as below:
7.4.7.1 in Rec. ITU-T H.265 v4 (12/2016)
num_ref_idx_active_override_flag equal to 1 specifies that the syntax
element num_ref_idx_l0_active_minus1 is present for P and B slices and
that the syntax element num_ref_idx_l1_active_minus1 is present for B
slices.
num_ref_idx_active_override_flag equal to 0 specifies that the syntax
elements num_ref_idx_l0_active_minus1 and num_ref_idx_l1_active_minus1
are not present.
https://bugzilla.gnome.org/show_bug.cgi?id=783804
In VA-API 1.0 the enum VAEncPackedHeaderH264_SEI is deprecated, and
instead VAEncPackedHeaderRawData should be used.
This patch creates a compatibility symbol,
VA_ENC_PACKED_HEADER_H264_SEI, to expose the used enum according the
VA-API version.
https://bugzilla.gnome.org/show_bug.cgi?id=784398
Coverity scan bug:
An assigned value that is never used may represent unnecessary
computation, an incorrect algorithm, or possibly the need for cleanup
or refactoring.
ip_period is assigned first to be rewritter inmediatly after. The
first assignation is spurious.
Coverity scan bug:
The copied code will not have its intended effect.
This is a bug from commit cdaf15b2, where the intention is to
initialize RefPicList1 while setting RefPicList0.
Coverity scan bug:
Unintentional integer overflow. The expression's value may not be what
the programmer intended, because the expression is evaluated using a
narrow (i.e. few bits) integer type.
Cast operator to guint64 before computation to avoid narrowing.
merge with 3c5a6add
Using num_ref_frames provided and the result of the Query
VAConfigAttribEncMaxRefFrames, it determines the size of reference list
and perform encoding with multi reference frames as the following:
1\ The num_ref_frames is being considered as the number of
reference picture list0
2\ Encoder adds 1 reference frame more to the reference picture list1
internally if b-frame encoding.
3\ If num_ref_frames is bigger than the number of refrence frames
supported in the driver, it will be lowered.
https://bugzilla.gnome.org/show_bug.cgi?id=783803
Users can provide the number of reference frame by this property.
The value of the property will be considered as the number of
reference picture list0 and will add 1 reference frame more to the
reference picture list1 internally if b-frame encoding.
If the value provided is bigger than the number of refrence frames
supported in the driver, it will be lowered.
https://bugzilla.gnome.org/show_bug.cgi?id=783803
Added a new property "compliance-mode", which default is the normal
strict compliant mode.
The second mode, "restrict-buf-alloc", is to limit the coded buffer
allocation size to improve performance in some specific Intel
platforms (there is asignificant performance improvement in parallel
encodings). Under this new mode, we use the MinCR field in A.3.1 for
pre-calculating the coded-buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=784590
If the picture is IDR, also submit a SPS header.
This means when frame number reaches to keyframe-period or an force
key unit event arrives, we insert SPS/PPS again.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
GST_VIDEO_CODEC_FRAME_IS_FORCE_KEYFRAME() is a flag usually used to manage
the `frame-lost` event in the case of streaming, such as RTP.
In case of this event, it is needed to start new GOP rather than just
produce an I-frame.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
Insert an AUD as the first NAL of each encoded frame.
Some applications require Access Unit Delimiter for decoding the
stream.
The AU delimeter insertion is done only when the aud parameter is
TRUE (by default is disabled). The reason of this it is because this
header is only available from Intel Gen9 and the VA intel driver
should be 1.8 or superior. Otherwise, the output will be corrupted.
https://bugzilla.gnome.org/show_bug.cgi?id=776712
Signed-off-by: Victor Jaquez <vjaquez@igalia.com>
Currently when num_views is changed by multiview-mode on sink caps, it produces
wrong MVC encoded stream since the array view_ids is not set properly according
to changed num_views.
So this patch initializes all of the array sequentially to handle this case.
Side effect is not going to happen by this patch since this array is being
handled by num_views.
https://bugzilla.gnome.org/show_bug.cgi?id=784321
Until now, the encoder ignored the profile in src caps and chose one
according with the given parameters. But the encoder must honor the
profile specifed in src caps.
This patch do that, and if the encoder needs to choose the profile,
it will do it by following these rules:
1\ If given parameters are not compatible with given profile, the
encoder will bail out with an error.
2\ The encoder will choose the higher profile indicated in the
src caps.
https://bugzilla.gnome.org/show_bug.cgi?id=757941
There are some symbols that are not used when compiling with old
version of libva and those generates a compilation error.
Original-patch-by: Matt Staples <staples255@gmail.com>
Instead of recalculating the miscellaneous buffer parameters for
every buffer, it is only done once, when the encoder is configured.
And for every buffer, the same structures are just copied.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
This is patch pretends to decouple the assignation of the values
in the parameter structures and the VA buffer's parameters setting.
It may lead to some issues since HRD, framerate or controlrate may
not be handled by the specific encoder, but they are set in
the VA buffer's parameters.
I leave as it because this patch is just a transitional patch.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Move the Hypothetical Reference Decoder (HRD) parameter, from
ensure_misc_params() to ensure_control_rate_params(), since it
only shall be defined when the control rate is either VBR or CBR.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Instead of filling the control rate param in ensure_misc_params(),
this patch refactor it out, as a first step to merge the same code
for all the encoders.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Right now, H264 and HEVC can set as a property the number of slices to
process. But each driver can set a maximum number of slices, depending
on the supported profile & entry point.
This patch verifies the current num_slices to process against the maximum
permitted by the driver and the media size.
https://bugzilla.gnome.org/show_bug.cgi?id=780955
Set ROI params during encoding each frame, which are set via
gst_vaapi_encoder_add_roi ()
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This patch adds the handling of VAEncMiscParameterTypeQualityLevel,
in gstreamer-vaapi encoders:
The encoding quality could be set through this structure, if the
implementation supports multiple quality levels. The quality level set
through this structure is persistent over the entire coded sequence, or
until a new structure is being sent. The quality level range can be queried
through the VAConfigAttribEncQualityRange attribute. A lower value means
higher quality, and a value of 1 represents the highest quality. The quality
level setting is used as a trade-off between quality and speed/power
consumption, with higher quality corresponds to lower speed and higher power
consumption.
The quality level is set by the element's parameter "quality-level" with a
hard-coded range of 1 to 8.
Later, when the encoder is configured in run time, just before start
processing, the quality level is scaled to the codec range. If
VAConfigAttribEncQualityRange is not available in the used VA backend, then
the quality level is set to zero, which means "disabled".
All the available codecs now process this parameter if it is available.
https://bugzilla.gnome.org/show_bug.cgi?id=778733
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The current implementation is updating the POC values only
in Slice parameter Buffer.But we are not filling the
picture order count and reference flags in VAPictureH264
while populating VA Picture/Slice structures.The latest
intel-vaapi-driver is directly accessing the above fields
from VAPicutreH264 provided as RefPicLists, which resulted
some wrong maths and prediction errors in driver.
https://bugzilla.gnome.org/show_bug.cgi?id=780620
Implements gst_vaapi_utils_h26x_write_nal_unit(), which writes NAL
unit length and data to a bitwriter.
Note that this helper function applies EPB (Emulation Prevention
Bytes), since otherwise produced codec_data might be broken when
decoder/parser considering EPB, starts parsing.
See sections 7.3 and 7.4 of the H264 and H264 specifications, which
describes the emulation_prevention_three_byte.
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Since there is duplicated code in h264/265 encoder, we could
refactor it to avoid duplicated code.
https://bugzilla.gnome.org/show_bug.cgi?id=778750
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
