Handles new custom event GstVaapiEncoderRegionOfInterest
to enable/disable a ROI region.
Writes a way to use new event to document.
https://bugzilla.gnome.org/show_bug.cgi?id=768248
Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
This bin should have similar classification as decodebin which is
"Generic/Bin/Decoder" otherwise it will appear wrongly as video
decoder.
Signed-off-by: Victor Toso <victortoso@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782063
When downstream negotiates a pixel-aspect-ratio of 0/1, the
calculations for resizing and formatting in vaapipostproc and
vaapisink, respectively, failed, and thus the pipeline.
This patch handles this situation by converting p-a-r of 0/1 to
1/1. This is how other sinks, such as glimagesink, work.
https://bugzilla.gnome.org/show_bug.cgi?id=781759
Since it's created by itself, it should be unref-counted
after gst_buffer_pool_config_set_allocator call. Afterwards,
this allocator will be ref-counted again when assigning to priv->allocator.
https://bugzilla.gnome.org/show_bug.cgi?id=781577
Sometimes a video decoder could set different buffer pool
configurations, because their frame size changes. In this case we
did not reconfigure the allocator.
This patch enables this use case, creating a new allocator inside
the VAAPI buffer pool if the caps changed, if it is not dmabuf-based.
If so, it is just reconfigured, since it doesn't have a surface pool.
https://bugzilla.gnome.org/show_bug.cgi?id=781577
Direct rendering (use vaDeriveImage rather than vaPutImage) has better
performance in some Intel platforms (Haswell, for example) but in others
(Skylake) is the opposite.
In order to have some control, the patch enables the direct rendering
through the environment variable GST_VAAPI_ENABLE_DIRECT_RENDERING.
Also it seems to generating some problems with gallium/radeon backend.
See bug #779642.
https://bugzilla.gnome.org/show_bug.cgi?id=775848
Clear decoders out on a flush but keep the same instance,
rather than completely recreating them. That avoids
unecessarily freeing and recreating surface pools
and contexts, which can be quite expensive
https://bugzilla.gnome.org/show_bug.cgi?id=781142
When these definitions are false, they are undef in the
preprocessor, not a defined value of 0. When they are unset the
compile fails with:
'GST_GL_HAVE_WINDOW_WAYLAND' undeclared (first use in this function)
https://bugzilla.gnome.org/show_bug.cgi?id=780948
This new virtual method, get_profile(), if implemented by specific
encoders, will return the VA profile potentially determined by the
source caps.
Also it is implemented by h264 and h265 encoders, which are the main
users of this vmethod.
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
As in gstreamer-vaapi a common base class is used, the specific
default category is passed to the base-plugin initializator, thus
the log messages are categorized with the used plugin.
Nonetheless, when the gst-debug is disabled in compilation time,
it is needed to pass NULL to the base-plugin initializator. This
patch does that.
https://bugzilla.gnome.org/show_bug.cgi?id=780302
Particularly in GNOME Wayland, the negotiated or created GL context
defines a GLX environment, but VAAPI fails to create a GLX VA
display because there is no a DRI2 connection.
This patch retries to create the VA display if VA cannot create one
with the GL context parameters. Now using the old list of display
types.
This should also work in the case of systems with two GPU, when the
non-VAAPI has the graphics environment, and the VAAPI-enabled one
shall work headless.
https://bugzilla.gnome.org/show_bug.cgi?id=772838
Removes GstVideoGLTextureUploadMeta caps feature if the driver
doesn't support opengl.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772838
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
When dmabuf is negotiated downstream and decoding and rendering are
not done on the same device, the layout has to be linear in order for
the memory to be shared accross devices, since each device has its
own way to do tiling.
Right now this code is rather just a to-do comment, since we are not
fetching the device ids.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Use new -base API gst_video_decoder_allocate_output_frame_full() to
pass the current proxy/surface to the pool.
The pool will will export thins given surface instead of exporting a
brand new surface that will never be filled in with meaningfull data.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Overriding the vmethod acquire_buffer() it is possible to attach the
right GstMemory to the current acquired buffer.
As a matter of fact, this acquired buffer may contain any instantiated
GstFdmemory, since this buffer have been popped out from the buffer
pool, which is a FIFO queue. So there is no garantee that this buffer
matches with the current processed surface. Evenmore, the VA driver
might not use a FIFO queue. Therefore, it is no way to guess on the
ordering.
In short, acquire_buffer on the VA driver and on the buffer pool return
none matching data, we have to manually attach the right GstFdMemory to
the acquired GstBuffer. The right GstMemory is the one associated with
the current surface.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
gst_vaapi_dmabuf_memory_new() always exports a surface. Previously, it
had to create that surface. Now it can also export an already provided
surface. It is useful to export decoder's surfaces (from VA context).
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
element can handle dmabuf-based buffers, avoiding its negotiation.
Similar as "vaapidecode: do not add meta:GstVideoGLTextureUploadMeta
feature if can dmabuf"
https://bugzilla.gnome.org/show_bug.cgi?id=755072
If the negotiated caps are raw caps and downstream supports the
EGL_EXT_image_dma_buf_import extension, then the created allocator
is the DMAbuf, configured to downstream.
At this moment, the only element which can push dmabuf-based buffers
to downstream, is vaapipostproc.
In order to enable, in the future, dmabuf-based buffers, the vaapi base
plugin needs to check if downstream can import dmabuf buffers.
This patch checks if downstream can handle dmabuf, by introspecting the
shared GL context. If the GL context is EGL/GLES2 and have the extension
EGL_EXT_image_dma_buf_import, then dmabuf can be negotiated.
Original-patch-by: Julien Isorce <j.isorce@samsung.com>
The surface created for downstream is going to be filled by VAAPI
elements. So, the driver needs write access on that surface.
This patch releases the derived image held by the proxy, thus the
surface is unmarked as busy.
This is how it has to be done as discussed on libva mailing list.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
Add GstPadDirection param to gst_vaapi_dmabuf_allocator_new(), thus
we later could do different thing when the allocated memory is for
upstream or dowstream, as required by VA-API.
https://bugzilla.gnome.org/show_bug.cgi?id=755072
A value of width/height property should be set to out caps,
if negotiation had been going properly.
So we can use srcpad_info when making decision of scaling.
https://bugzilla.gnome.org/show_bug.cgi?id=778010
If a GstVaapiDisplay is not found in the GStreamer context sharing,
then VAAPI elements look for a local GstGLContext in gst context
sharing mechanism ('gst.gl.local.context').
If this GstGLContext not found either then, only the VAAPI decoders
and the VAAPI post-processor, will try to instantiate a new
GstGLContext.
If a valid GstGLContext is received, then a new GstVaapiDisplay will
be instantiated with the platform, API and windowing specified by the
instantiated GstGLContext.
Original-Patch-By: Matt Fischer <matt.fischer@garmin.com>
https://bugzilla.gnome.org/show_bug.cgi?id=777409
Instead of calling g_return_val_if_fail() to check the context type, we
should use a normal conditional, since it is possible that other context types
can arrive and try to be assigned. Otherwise a critical log message is
printed.
This happens when we use playbin3 with vaapipostproc as video-filter.
https://bugzilla.gnome.org/show_bug.cgi?id=777409
Every time a new buffer is allocated, the pool is activated. This
doesn't impact in performance since gst_buffer_pool_set_active()
checks the current state of the pool. Nonetheless it logs out a
message if the state is the same, and it floods the logging subsystem
if it is enabled.
To avoid this log flooding first the pool state is checked before
changing it.
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
Adds two buffers as the default value of minimum buffer.
This would be used when creating and proposing vaapi bufferpool for
sink pad, hence the upstream element will keep, at least, these two
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=775203
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Rename the parameters 'vip' and 'flags' to 'alloc_info' and
'surface_alloc_flags' respectively. The purpose of this change is
to auto-document those parameters.
Also, aligned to this patch, the local 'alloc_info' variable was
renamed as 'surface_info', because it stores the possible surface's
video info, not the allocate one.
In order to auto-document the code, this patch renames the 'vip'
parameter in the functions related to gst_vaapi_video_allocator_new ()
to 'alloc_info', since it declares the allocation video info from
the vaapi buffer pool.
gst_vaapi_surface_new_with_format() is a wrapper for
gst_vaapi_surface_new_full (). In this case, the former is simpler
than the first. This patch changes that.
If src pad caps have changed, it needs to notify it downstream. In
addition, do not set passthrough if they have changed.
Otherwise, transform sometimes starts processing before caps change.
The passthrough value will be set in fixate later in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=775204
Add a capsfilter forcing the caps
"video/x-raw(memory:VASurface), format=(string)NV12" between the
queue and the vaapipostproc so no renegotiation is required.
https://bugzilla.gnome.org/show_bug.cgi?id=776175
To detect and handle errors during allocator_configure_surface_info()
and allocator_conigure_image_info().
https://bugzilla.gnome.org/show_bug.cgi?id=776084
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
When an instance of GstVaapiVideoAllocator fails at initializing, the
log message should not include the allocator's object, because it is
going to be unrefed.
This reverts commit 3285121181.
videodecode's negotiate() vmethod is also called when events arrive,
but this would mean that the proper configuration of sink pad might
not be complete, thus we should not update the src pad.
Let's keep the old non-vmethod negotitate().
Added the inlined function allocator_configure_pools() moving out code
from gst_vaapi_video_allocator_new() to make clear that it is a
post-initalization of the object.
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
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.
