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>
Don't call gst_vaapi_window_wayland_sync() when destroying the
wayland window instance, since it might lead to a lock at
gst_poll_wait() when more than one instances of vaapisink are
rendering in the same pipeline, this is because they share the
same window.
Since now all the frames are freed we don't need to freed the
private last_frame, since its address is invalid now.
https://bugzilla.gnome.org/show_bug.cgi?id=780442
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Fix leakage of the last wl buffer.
VAAPI wayland sink needs to send a null buffer while destruction,
it assures that all the wl buffers are released. Otherwise, the last
buffer's callback might be not called, which leads to leak of
GstVaapiDisplay.
This was inspired by gstwaylandsink.
https://bugzilla.gnome.org/show_bug.cgi?id=774029
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
The proxy object of wl_buffer for the last frame remains in the
wl_map. Even though we call wl_buffer_destroy() in
frame_release_callback(), the proxy object remains without being
removed, since proxy object is deleted when wayland server sees the
delete request and sends 'delete_id' event.
We need to call roundtrip before destroying event_queue so that the
proxy object is removed. Otherwise, it would be mess up as receiving
'delete_id' event from previous play, when playing in the next
va/wayland window with the same wl_display connection.
https://bugzilla.gnome.org/show_bug.cgi?id=773689
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Clear decoders out on a flush but keep the same instance,
rather than completely recreating them. That avoids
unecessarily freeing and recreating surface pools
and contexts, which can be quite expensive
https://bugzilla.gnome.org/show_bug.cgi?id=781142
The macro GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE only defines
a function that is never used, thus when compiling we might see
this warning (clang):
gstvaapiwindow.c:147:1: warning: unused function 'gst_vaapi_window_class' [-Wunused-function]
GST_VAAPI_OBJECT_DEFINE_CLASS_WITH_CODE (GstVaapiWindow,
^
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Since gst_vaapi_window_vpp_convert_internal is created,
GstVaapiWindowX11/Wayland can use it for conversion.
Note that once it chooses to use vpp, it's going to use vpp
until the session is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
If a backend doesn't support specific format, we can use vpp for conversion
and make it playing.
This api is originated from GstVaapiWindowWayland and moved to GstVaapiWindow,
so that GstVaapiWindowX11 could use it.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
Currently, GstVaapiWindowX11/Wayland are not descendants of GstVaapiWindow.
This patch chains them up to GstVaapiWindow to handle common members in GstVaapiWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=759533
If the profile is main-10 the bit_depth_luma_minus8, in the sequence
parameter buffer, shall be the color format bit depth minus 8, 10-8
which is 2. Also for bit_depth_chroma_minus8.
This patch gets the negotiated sink caps format and queries its
luma's depth and uses that value to fill the mentioned parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
When the function gst_vaapi_encoder_get_surface_formats() was added
it was under the assumption that any VA profile of the specific codec
supported the same format colors. But it is not, for example the
profiles that support 10bit formats.
In other words, different VA profiles of a same codec may support
different color formats in their upload surfaces.
In order to expose all the possible color formats, if no profile is
specified via source caps, or if the encoder doesn't have yet a
context, all the possible VA profiles for the specific codec are
iterated and their color formats are merged.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
In order to get the supported surface formats within a specific
profile this patch adds the GstVaapiProfile as property to
gst_vaapi_encoder_get_surface_formats().
Currently the extracted formats are only those related with the
default profile of the element's codec.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Instead of creating (if it doesn't exist, yet) the encoder's context
the method gst_vaapi_encoder_get_surface_formats() now it creates
dummy contexts, unless the encoder has it already created.
The purpose of this is to avoid setting a encoder's context with a
wrong profile.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
In order to generate vaapi contexts iterative, the function
init_context_info() is refactored to pass, as parameters the
GstVaapiContextInfo and the GstVaapiProfile.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
Instead of initialize the chroma_type with a undefined value, which
will be converted to GST_VAAPI_CHROMA_TYPE_YUV420 by GstVaapiContext,
this patch queries the VA config, given the received
GstVaapiContextInfo's parameters, and gets the first response.
In order to get the GstVaapiChromaType value, also it was needed to
add a new utility function: to_GstVaapiChromaType(), which, given a
VA_RT_FORMAT_* will return the associated GstVaapiChromaType.
https://bugzilla.gnome.org/show_bug.cgi?id=771291
gcc 7.0.1 gives a memset-elt-size warning in gst_vaapi_encoder_vp9_init:
'memset' used with length equal to number of elements without
multiplication by element size [-Werror=memset-elt-size]
https://bugzilla.gnome.org/show_bug.cgi?id=780947
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>
From man open(2):
The O_CLOEXEC, O_DIRECTORY, and O_NOFOLLOW flags are not specified
in POSIX.1-2001, but are specified in POSIX.1-2008. Since glibc
2.12, one can obtain their definitions by defining either
_POSIX_C_SOURCE with a value greater than or equal to 200809L or
_XOPEN_SOURCE with a value greater than or equal to 700. In glibc
2.11 and earlier, one obtains the definitions by defining
_GNU_SOURCE.
And indeed, with the uClibc C library, O_CLOEXEC is not exposed if
_GNU_SOURCE is not defined. Therefore, this commit fixes the build of
gstreamer-vaapi with the uClibc C library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779953
Currently, it set rate control information even when query fails.
In addition, it doesn't update any more since the flag
got_rate_control_mask is set to TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=779120
The encoder should be able to change its caps even it is already
processing a stream.
This is suppose to happen after a flush so the codedbuf_queue should
be empty.
https://bugzilla.gnome.org/show_bug.cgi?id=775490
