In commit 6d11a00 were introduced a regression when gstreamer-vaapi is
compiled with out EGL/GLX support: it shall not support
GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS.
This patch guards the inclusion of GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS in the
allowed src caps for vaapedecode if EGL/GLX.
Previously the frame map counter increased independently if the map succeeded
or not. This leaded to critical messages and crashes if the frame was unable
to be mapped, but the counter increased.
This patch increases the map counter only if the map operation occurred.
https://bugzilla.gnome.org/show_bug.cgi?id=773939
When the allocator is created, it stores the allocation caps. But sometimes
the "allocation caps" may be different from the "negotiation caps".
In this case, the allocator should store the negotiation caps since they
are the ones used for frame mapping with GstVideoMeta.
When vaapispostproc is used, this is not a problem since the element is assume
to resize. But when using a vaapi decoder only, with a software renderer, it
fails in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=773323
Just as vaapipostproc, VA decoder's context can be queried to get the possible
raw formats, so, the src caps can negotiate the exact caps that the context
supports.
Since when the sink pad allocator is created, it is decided if the required
one is vaapi allocator or dmabuf allocator, there is no need to force its set
again.
When running gst-discoverer-1.0, in certain media, vaapipostroc is stopped
meanwhile it is transforming caps. The problem is that stop() calls
gst_vaapi_plugin_base_close(), which nullifies the element's va display, but
the va display is used in tranform_caps() when it is extracting the possible
format conversions. This display disappearing generates warning messages.
This patch holds a local reference of va display at ensure_allowed_raw_caps()
hence it doesn't go away meanwhile it is used, even if the
gst_vaapi_plugin_base_close() is called in other thread.
https://bugzilla.gnome.org/show_bug.cgi?id=773593
Enable the direct rendering with linear surfaces if the negotiated src caps
are video/x-raw without features.
Pass also the caps, since they are needed to know the requested caps features.
Just as we did in ensure_sinkpad_allocator(), let's move the error message
into the ensure_srcpad_allocator() from the caller,
gst_vaapi_plugin_base_decide_allocation()
Instead of receiving the GstVideoInfo structure as parameter, get the original
GstCaps from ensure_sinkpad_buffer_pool(), in this way we could decide better
which allocator instantiate.
If the allocator was configured to use direct upload or rendering, the
generated derived image created at mapping needs to be destroyed after
unmapping, because, in order to process the surface, it should not be marked
as "busy" by the driver.
The way to experiment with the direct rendering is through and internal
compiler pre-processor flag.
The current change set enables a way to specified at run-time, as a flag
passed to the allocator at instanciation time.
This patch is to change the inheritance of GstVaapiDisplay to GstObject,
instead of GstVaapiMiniObject. In this way we can use all the available
infrastructure for GObject/GstObject such as GstTracer, GIR, etc.
In addition, a new debug category for GstVaapiDisplay is created to make it
easier to trace debug messages. It is named "vaapidisplay" and it transverse
all the VA display backends (DRM, GLX, EGL, Wayland, ...)
This patch is a step forward to expose GstVaapiDisplay for users in a future
library.
https://bugzilla.gnome.org/show_bug.cgi?id=768266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Since vaapipostproc is only registered if the driver supports it, all the
support for dynamic loading were removed. Though some leftovers remained.
https://bugzilla.gnome.org/show_bug.cgi?id=773589
In the spirit of the codec split, this patch removes the documentation of
vaapidecode and adds a page per each possible decoder.
Nonetheless, only those available in the compilation system are going to be
instrospected, because the rest are not registered.
vaapidecode has a member named allowed_caps, but this name is not enough
explicit. This patch renames allowed_caps to allowed_sinkpad_caps.
No functional changes were included.
https://bugzilla.gnome.org/show_bug.cgi?id=773497
In order to clarify the use of flag as input parameter, it is renamed to
surface_alloc_flag, since it is used when creating a VA surface with certain
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=773497
When caps reconfiguration is called, the new downstream frame size might be
different. Thus, if the downstream caps change,the display's texture map is
reset.
In addition, during pipeline shutdown, textures in texture map have to be
released, since each one have a reference to the GstVaapiDisplay object, which
is a dangerous circular reference.
https://bugzilla.gnome.org/show_bug.cgi?id=769293
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
instances when created and reuse
This patch improves performance when glimagesink uploads a GL texture.
It caches the GStVaapiTexture instances in GstVaapiDisplay{GLX,EGL}, using an
instance of GstVaapiTextureMap, so our internal texture structure can be found
by matching the GL texture id for each frame upload process, avoiding the
internal texture structure creation and its following destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=769293
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
set_format() is called by upstream when the stream capabilites has changed.
Before, if the new stream is compatible with the old one the VA decoder was
not destroyed. Nonetheless, with this behavoir, the VA decoder ignores
when the upstreamer parsers gets more details of the stream, such as the
framerate. Hence, when the src caps are negotiates, the further sink caps
updates are ignored.
This patch forces the VA decoder destroying and recreation when set_format()
is called.
https://bugzilla.gnome.org/show_bug.cgi?id=770921
When calling gst_video_frame_map() with GST_MAP_WRITE flag, it doesn't call
ensure_image_is_current(), which means it doesn't guarentee VAImage is valid
in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=766978
In a multiple video cards system, a X11 environment may have different VA
capabilities. This patch tracks the DISPLAY environment variable to
invalidates the GStreamer features cache. Also tracks WAYLAND_DISPLAY.
https://bugzilla.gnome.org/show_bug.cgi?id=770357
Encoders claim to support a whole bunch of input formats but then
just error out if the format is not actually supported, even if
there's a converter in front. This means they're not fit for
autoplugging in encodebin or camerabin yet and therefore should
not have a rank. People can still use them in custom pipelines.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Check earlier if upstream video source has activated the dmabuf-import
io-mode (hack to disappear soon), thus we can avoid the re-assignation of a
new allocator.
