Since video_info stores the GstVideoInfo of the allocation caps,
it is clear if we rename it as allocation_info, to distinguish it
later from negotiation_info.
Instead of defining GstVaapiDmaBufAllocator as a hackish decorator of
GstDmaBufAllocator, now, since the expose of the GstDmaBufAllocator's
GType, GstVaapiDmaBufAllocator is a full feature GstAllocator inherited
from GstDmaBufAllocator.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Add a helper function to initialize the gst_debug_vaapivideomemory,
to use it either by the GstVaapiVideoAllocatorClass or
GstVaapiDmabufAllocator (which is a decorator of GstDmaBufAllocator).
Later, log possible errors when calling gst_vaapi_dmabuf_allocator_new ()
https://bugzilla.gnome.org/show_bug.cgi?id=755072
As the internal encoder is created at start(), let's release it at
stop() vmethod, to be consistent.
gst_vaapiencode_destroy() is called since it also resets the input and
output states, which is something that the base class does internally
after calling stop() vmethod.
https://bugzilla.gnome.org/show_bug.cgi?id=769266
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Currently, specific encoder is created during set_format(). This might
lead to race condition when creating profiles with multiple encoders.
This patch moves ensure_encoder() call to start() vmethod to ensure
avoiding the race condition.
https://bugzilla.gnome.org/show_bug.cgi?id=773546
In commit ca0c3fd6 we remove the dynamic configuration if the bin
because we assumed that the bin will be always static as it is
registered.
Nonetheless we were wrong, because it is possible to request, with a
property, to avoid the use of the post-processor.
Since we want to add a way to disable the post-processor through
environment variables, this remove feature is required again.
If the environment variable GST_VAAPI_DISABLE_VPP is defined the
postprocessor inside of the vaapidecodebin is disabled, then
vaapidecodebin is an alias of the old vaapidecode.
https://bugzilla.gnome.org/show_bug.cgi?id=775041
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
Instead of creating the VA display before setting the bus to the
element, it is created when the element is opened.
Basically, this commit is a revert of
5e5d62cac7
That was done when the GStreamer's context sharing was not mature
enough as now. There is no reason to keep this hack.
Since the differentiation of negotiation caps and allocation caps,
there is no need to add a video crop meta with the negotiation caps.
Hence, removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=773948
Since all the video converter were deprecated in gstreamer-1.2, we don't need
to handle them anymore in the vaapi's buffer meta.
This patch removes its usage and the buffer meta's API for that.
https://bugzilla.gnome.org/show_bug.cgi?id=745728
First, deactivate source pad pool when the out caps change, and if so,
destroy texture map, the source pad allocator and pool only if the
new caps are different from the ones already set.
This is related with bug 758907 when no vaapipostproc is used (no
vaapidecodebin). In order to negotiate downstream we need to destroy
the source pad allocator, otherwise the same allocated buffers are
used, failing the mapping.
Remove redundant GST_VAAPI_TYPE_VIDEO_INFO, since it is a duplicate of
GST_TYPE_VIDEO_INFO created before gstreamer 1.6, where the boxed type
was created.
https://bugzilla.gnome.org/show_bug.cgi?id=774782
This patch adds the created allocator to the allocation query either
in decide_allocation() and propose_allocation() vmehtods.
With it, there's no need to set the modified allocator's size in the
pool configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=774782
We should set the correct buffer size when we are configuring the pool,
otherwise the buffer will be discarded when it returns to the pool.
Indeed when the ref-count of a buffer reaches zero, its pool will queue
it back (and ref it) if, and only if, the buffer size matches the
configured buffer size on the pool.
This issue can be debugged with GST_DEBUG=*PERF*:6, see gstbufferpool.c
https://bugzilla.gnome.org/show_bug.cgi?id=774782
When calling gst_vaapi_video_memory_copy() the allocator of the memory
to copy should be allocated by the vaapi allocator.
This patch does this verification.
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
