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>
Split the funcion context_create() into context_create() and
config_create().
Decoupling VAConfig and VAContext during context creation, we could
query the VAConfig for the supported surface's formats without creating
a VAContext.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Originally the drm backend only tried to open the first render node
found. But in hybrid system this first render node might not support
VA-API (propietary Nvidia driver, for example).
This patch tries all the available nodes until a finding one with a
VA-API supported driver.
https://bugzilla.gnome.org/show_bug.cgi?id=774811
Original-patch-by: Stirling Westrup <swestrup@gmail.com> and
Reza Razavi <reza@userful.com>
In case libva-wayland has its headers not installed in default
locations (like /usr/include), the build fails to include "wayland-client.h":
CC libgstvaapi_egl_la-gstvaapiutils_egl.lo
In file included from gstvaapidisplay_wayland.h:27:0,
from gstvaapidisplay_egl.c:35:
/usr/include/va/va_wayland.h:31:28: fatal error: wayland-client.h: No such file or directory
#include <wayland-client.h>
As we already passed VA_CLAGS, /usr/include/va/va_wayland.h could be found, but it is
our fault not to instruct the system that we ALSO care for va_wayland. We correctly query
for libva-wayland.pc in configure and use this in other places as well. It is thus only
correct and consequent, to do it also at this spot.
https://bugzilla.gnome.org/show_bug.cgi?id=773946
This patch ensures to get the formats, as filter does, available in the
decoder / encoder context.
The context fills up the array as soon it is created, otherwise the pipeline
could get stalled (perhaps this is a bug in my HSW backend).
https://bugzilla.gnome.org/show_bug.cgi?id=752958
The query of all the supported formats for a VA config were only used by the
postprocessor (vaapifilter). But, in order to enable the vaapidecoder to
negotiate a suitable raw format with downstream, we need to query these
formats against the decoder's config.
This patch is the first step: moves the code in filter's ensure_image() to a
generic gst_vaapi_get_surface_formats() in vaapiutils_core, so it can be
shared later by the decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=752958
