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
Configuring GCC to verify possible usage of uninitialized variables,
shows that found_index might be used without previous assignation.
This patch assigns a initial value to found_index, also avoid a
branching when returning the result value.
https://bugzilla.gnome.org/show_bug.cgi?id=778782
Rename to be consistent with H.264 and also H.265 encoder. The
meson build assumed this was already consistently named, and so
previously was not able to actually build the H.265 decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=778576
This patch enables the Constant BitRate encoding mode in VP8 encoder.
Basically it adds the configuration parameters required by libva to
CBR enconding.
Original-Patch-By: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749950
Reduce frame num gaps so that we don't have to create unnecessary
dummy pictures, just throw them away.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777506
This patch adds a GstMemory as a variable member of the buffer proxy,
because we will need to associate the buffer proxy with the memory
which exposes it. Later, we will know which memory, in the video buffer
pool, is attached to the processed surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Thus, when generating the allowed caps, the element will throw a
warning and it will use its caps template.
This behavior might be a bug in the VA driver.
https://bugzilla.gnome.org/show_bug.cgi?id=775490
When a new sink caps arrive the internal decoder state is updated
and, if it is, request a downstream renegotiation.
Previously, when new caps arrived the whole decoder where destroyed
and recreated. Now, if the caps are compatible or has the same codec,
the internal decoder is kept, but a downstream renegotiation is
requested.
https://bugzilla.gnome.org/show_bug.cgi?id=776979
Redirect libva's logs to GStreamer logging mechanism. This is
particularly useful when VA is initialized, because it always logs
out the drivers details.
In order to achieve this a new helper function was added as a wrapper
for the vaInitialize() function.
https://bugzilla.gnome.org/show_bug.cgi?id=777115
If the frame is a cloned picture, its PTS comes from its parent
picture. In addition, the base decoder doesn't set a valid PTS to
the frame corresponding to the cloned picture.
https://bugzilla.gnome.org/show_bug.cgi?id=774254
This method will return the valid surface formats in the current
config. If the are no VAConfig it is created with the information
available.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Split set_context_info() adding init_context_info() which only
initialises the GstVaapiContextInfo structure inside GstVaapiEncoder
required for VAConfig.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
If GstVaapiContextInfo has just initial information, without frame's
width and height, skip the creation of the VAContext, just keep the
VAConfig.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
