Adding FEI encoder to core lib.
The code is splitted into three session:
1: gstvaapiencoder_h264_fei.{h,c}
This is the replica of gstvaapiencoder_h264.{c,h} but with FEI.
All the modes ENC, PAK and ENC_PAK are running based
the code in these files.
2: gstvaapifeienc_h264.{h,c}
Abstract implementation intended for ENC (only VME) operation.
3: gstvaapifeipak_h264.{h,c}
Abstrct implementation intended for PAK (only the PAK module)
Right now ENC_PAK, ENC and PAK are running based on code
in gstvaapiencoder_h264_fei.{h,c}. The abstract implementations
in gstvaapifeienc_h264.{h,c} and gstvaapifeipak_h264.{h,c} are
needed if user request for ENC+PAK mode operation.
ENC+PAK: Here we need to invoke two sequence of
vaBeginPicture/vaRenderPicutre/vaEndPicture for each frame,
first for the ENC only and the second for PAK only.
Each mode associated with separate context ,but same pool of surfaces are
shared between the modes.
This is more useful once we have custom BRC algorithms.
Other Contributors:
Wang, Yi <yi.a.wang@intel.com>
Leilei <leilei.shang@intel.com>
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
MbCode, MV and Distortion buffers (fei codec objects)
can be treated as output of different fei modes based user request.
For eg: MbCode and MV are the output of ENC only. MbCode, MV and Dist
can be dumped as output in ENC_PAK mode for analysis purpose.
So treating them as a part of CodedBufferProxy too.
Here we avoided Qp, MbControl and MvPredictor codec objects since
there is no practical use case of treating them as "output buffers".
Other contributors:
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Leilei <leilei.shang@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Add fei codec objects to surface proxy since handling the
fei buffers(codec objects here) external to gstvaapisurfaceproxy
will make the code complicated. Especially considering the behavior
of encoder where the input frame order from upstream and output
frame order to the downstream are not sequential.
Other contributors:
Zhong, Xiaoxia <xiaoxia.zhong@intel.com>
xiaominc <xiaomin.chen@intel.com>
Leilei <leilei.shang@intel.com>
Li, Jing B <jing.b.li@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
There are 6 new va buffer types, each defined as a specific codec object.
Borrowed the code from gstvaapicodecobject , but made a clear separation
to avoid any possible mess-up. Because unlike the other gstvaaicodecobjects,
feicodecobjects can be shared between elements and also can be accessed
from different thread.
Unlike the other fei codecs object, VAEncMiscParameterTypeFEIFrameControl
object is not shared between elements.So we utilize the already
existing gst_vaapi_enc_misc_param_new(), but still keeping the code
in gstvaapfei_objects_priv.h in order to have a better
code readability.
Fixme:
-- Probably we need _locked_map() and _unlocked_map()
-- Context can be associated with PreEnc(not just Enoder)
once we have the proper support inplace, but for now we don't have
PreEnc support, so should be safe enough to use GstVaapiEncoder.
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Add a new vitrual method ensure_secondary_context to the
base encoder which is only required for the FEI entrypoint, that too
only when user configures the ENC+PAK mode. ENC+PAK mode is not something
supported directly by libva or driver, but this can be enabled
from the middleware.
Original Author of this idea: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: Leilei Shang <leilei.shang@intel.com>
Signed-off-by: xiaominc <xiaomin.chen@intel.com>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785712https://bugzilla.gnome.org/show_bug.cgi?id=784667
Drops non-base NALs when the base-only property is set to TRUE.
This modifies the behavior for MVC streams with base-only too: All the
non-base units are dropped before they are decoded instead of dropping
the non-base frames.
The relevant part from the H264 spec is:
> Decoders that conform to one or more of the profiles specified in
Annex A rather than the profiles specified in Annexes G or H shall
ignore (remove from the bitstream and discard) the contents of all NAL
units with nal_unit_type equal to 14, 15, or 20.
To eliminate side effects from the offending units:
- PPS's with a broken seq_parameter_set_id (referring to dropped subset
SPS's) are ignored.
- The NAL parsing is skipped and their flags are set to
GST_VAAPI_DECODER_UNIT_FLAG_SKIP.
- Prefix units are not stored in prev_pi. Otherwise, parse_slice() would
use them even if they are flagged to be skipped. Subset SPS's and slice
extension units are not stored there either.
https://bugzilla.gnome.org/show_bug.cgi?id=732266
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
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
In VA-API 1.0 the union bits in VAEncMiscParameterBufferROI has
renamed one member from roi_value_is_qp_delat to
roi_value_is_qp_delta, which is the correct name.
In order to keep back compatibility a macro has added to access this
union member.
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:
Logically dead code: The indicated dead code may have performed some
action; that action will never occur.
By using pointer arithmetic is impossible to get NULL.
Coverity scan bug:
Out-of-bounds write. This could cause an immediate crash or incorrect
computations.
Coverity basically found that it is possible to assign more than 4
attribs in the array.
In my opinion this was produced because code pattern used pointer
arithmetic, which is not readable nor maintainable.
This patch refactors config_create() to use an array index rather than
pointer arithmetic. Also a run-time check for index size was added.
Converity scan bug:
If the function returns an error value, the error value may be
mistaken for a normal value.
If g_atomic_pointer_compare_and_exchange() fails because the frame is
not the last one, the function fails. Thus, logging an info message.
Coverity scan bug:
If the function returns an error value, the error value may be
mistaken for a normal value.
Function sscanf returns the number of assignations done. Validate this
return value with the number of expected variables to match.
Coverity scan bug:
Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.
Variable klass has been validated as non-NULL several time before in
gst_vaapi_object_new() function, so there is no need to check it
again.
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
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.
In the return value of decode_slice() or
gst_mpeg4_parse_video_packet_header() are not success, thus fail
decode_packet() function.
Coverity scan bug:
Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.
While looking for hte lowest poc, according to rest of the code, the
picture in the dbp (decoded picture buffer) might be NULL, thus we
could check for a NULL picture before assigned as found.
Also, split a comma operator because it is considered as a bad
practice because it possible side effects.
Coverity scan bug:
Scalars (for example, integers) are not properly
bounds-checked (sanitized) before being used as array or pointer
indexes, loop boundaries, or function arguments are considered as
tainted.
In this case, num_nals were not checked before used as loop control.
Coverity scan bug:
Dereference after null check: Either the check against null is
unnecessary, or there may be a null pointer dereference.
In the original commit for fill_picture_gaps() (commit 5abd2b90) the
prev_picture could be NULL, that's why the code did a null check. But,
since commit 52adebe7, the previous reference frames are tracked, thus
there is no need to check null anymore.
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
This function will query VAConfigAttribEncMaxRefFrames to get the
maximum number of reference frames supported in the driver.
This will be used for h264/h265 encoding.
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
Push frames downstream as soon as possible instead of waiting until
they are ejected from the DPB.
This patch makes the decoder not comply with the H.264 specification,
but it is required for some video cameras.
https://bugzilla.gnome.org/show_bug.cgi?id=762509
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
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
Since commits in https://bugzilla.gnome.org/show_bug.cgi?id=781142 landed,
they introduced regression in seek.
Formerly, once seek is done, decoder drops P-frames until I-frame arrives.
But since the commits landed, it doesn't drop P-frame and does try to
decode it continuously because active_sps is still alive. See ensure_sps function.
But there are prev_frames and prev_ref_frames reset already, then it
causes assertion.
So it's necessary to reset active_sps/pps also in reset method.
https://bugzilla.gnome.org/show_bug.cgi?id=783726
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>
Change the hard-coded range of quality-level from {1-8} to {1-7},
since it is the range Intel Open source driver supports.
Also perform the range clamping only if the user provided
quality-level is greater than the max-range suppored by the driver,
because there could be non-intel drivers giving lower value than
the hard-coded max value 7.
https://bugzilla.gnome.org/show_bug.cgi?id=783567
Just set the framerate parameter if the framerate numerator and
denominator are bigger than zero.
Otherwise, in Intel Gen6 driver, a warning is raised disabling the
bitrate control.
Original-patch-by: Hyunjun Ko <zzoon@igalia.com>
https://bugzilla.gnome.org/show_bug.cgi?id=783532
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
According to the VA documentation:
The framerate is specified as a number of frames per second,
as a fraction. The denominator of the fraction is given in
the top half (the high two bytes) of the framerate field, and
the numerator is given in the bottom half (the low two bytes).
For example, if framerate is set to (100 << 16 | 750), this is
750 / 100, hence 7.5fps.
If the denominator is zero (the high two bytes are both zero)
then it takes the value one instead, so the framerate is just
the integer in the low 2 bytes.
This patch fixes the the framerate calculation in vp8 encoder
according to this.
https://bugzilla.gnome.org/show_bug.cgi?id=783449
Move frame-rate parameter from ensure_misc_params() to
ensure_contro_rate_param() since it only has meaning when the
control rate is either VBR or CBR.
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
Instead of using a proxy to story the buffer quality level, the
encoder now uses the native VA structure, which is copied to the
dynamically allocated VAEncMiscParameterBuffer.
This approach is computationally less expensive.
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
Since we started using VPP in VaapiWindowX11, we need to care about
the case that src rect and window's size are different.
So, once VPP has converted to other format, we should honor the
size of the VPP's surface as source rect. Otherwise, it is cropped
according the previous size of the source rect.
https://bugzilla.gnome.org/show_bug.cgi?id=782542
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>
Queries if the driver supports "Region of Interest" (ROI) during the config
creation.
This attribute conveys whether the driver supports region-of-interest (ROI)
encoding, based on user provided ROI rectangles. The attribute value is
partitioned into fields as defined in the VAConfigAttribValEncROI union.
If ROI encoding is supported, the ROI information is passed to the driver
using VAEncMiscParameterTypeROI.
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>
Sometimes gst_vaapi_window_wayland_sync returns FALSE when poll returns EBUSY
during destruction.
In this case, if GstVaapiWindow is using vpp, leak of vpp surface happens.
This surface is not attached to anything at this moment, so we should release
it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=781695
When the frame listener callbacks 'done', the number of pending
frames are decreased. Nonetheless, there might be occasions where
the buffer listener callbacks 'release', without calling previously
frame's 'done'. This leads to problem with
gst_vaapi_window_wayland_sync() operation.
This patch marks as done those frames which were callbacked, but if
the buffer callbacks 'release' and associated frame is not marked
as 'done' it is so, thus the number of pending frames keeps correct.
https://bugzilla.gnome.org/show_bug.cgi?id=780442
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
