Instead of having a gst_vaapi_video_memory_free() that is only going to
be called by gst_vaapi_video_allocator_free(), let's just remove the first
and merged into the second.
There were duplicated code in gst_video_meta_unmap_vaapi_memory() and
gst_vaapi_video_memory_unmap() when unmapping.
This patch refactors both methods adding the common function
unmap_vaapi_memory(). This also ensures, if direct rendering is enabled, it
is correctly reset.
Additionally, only when mapping flag has the WRITE bit, it set the image as
current, which was done in gst_video_meta_map_vaapi_memory() but no in
gst_vaapi_video_memory_map().
In order to make this, the mapping flags were required, so instead of
overloading mem_unmap() virtual function, mem_unmap_full() is overloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=774213
There were duplicated code in gst_video_meta_map_vaapi_memory() and
gst_vaapi_video_memory_map() when doing the READ and WRITE mapping.
This patch refactors both methods adding the common function
map_vaapi_memory().
Additionally, only when flag has the READ bit it calls
ensure_images_is_current(), which was done in
gst_video_meta_map_vaapi_memory() but no in
gst_vaapi_video_memory_map().
https://bugzilla.gnome.org/show_bug.cgi?id=772151
The variable member allowed_sinkpad_caps is constructed querying the
current VA display. Bearing that in mind, the variable shall be freed
when the VA display changes or is removed.
This patch moves the freeing of allowed_sinkpad_caps to close(), when
the VA display is freed.
The thread that handles window's events should be finished during
pipeline's shutdown, otherwise it will remain alive during pipeline
re-activation, leading to unexpected problems.
This patch fixes failures of intensive_state_change scenario of
gst-validate
https://bugzilla.gnome.org/show_bug.cgi?id=774241
Returning GST_FLOW_ERROR always when gst_pad_push fails might lead to
deadlock during seek.
This patch returns the same error of gst_pad_push() and log out the
return value.
https://bugzilla.gnome.org/show_bug.cgi?id=774030
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.
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
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.
When creating a GstVaapiWindowEGL, it also creates native window by its own
native display. It should pass the native display, either X11 or Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=768266
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.
