Refactor the set_config() virtual method considering a cleaner
approach to allocator instanciation, if it it not set or if it is
not valid for the pool.
https://bugzilla.gnome.org/show_bug.cgi?id=783599
The vaapi video decoders might have different allocation caps from
the negotiation caps, thus the GstVideoMeta shall use the negotiation
caps, not the allocation caps.
This was done before reusing gst_allocator_get_vaapi_video_info(),
storing there the negotiation caps if they differ from the allocation
ones, but this strategy felt short when the allocator had to be reset
in the vaapi buffer pool, since we need both.
This patch adds gst_allocator_set_vaapi_negotiated_video_info() and
gst_allocator_get_vaapi_negotiated_video_info() to store the
negotiated video info in the allocator, and distinguish it from
the allocation video info.
https://bugzilla.gnome.org/show_bug.cgi?id=783599
Renamed local video info structure names in set_config() vitual
method. The purpose of their renaming is to clarify the origin
of those structures, whether come from passed caps parameter
(new_allocation_vinfo) or from the configured allocator
(allocator_vinfo).
https://bugzilla.gnome.org/show_bug.cgi?id=783599
Renamed private GstVideoInfo structure video_info to allocation_vinfo
and alloc_info to negotiated_vinfo.
The purpose of these renaming is to clarify the origin and purpose of
these private variables:
video_info (now allocation_vinfo) comes from the bufferpool
configuration. It describes the physical video resolution to be
allocated by the allocator, which may be different from the
negotiated one.
alloc_info (now vmeta_vinfo) comes from the negotiated caps in
the pipeline. It represents how the frame is going to be mapped
using the video meta.
In Intel's VA-API backend, the allocation_vinfo resolution is
bigger than the negotiated_info.
https://bugzilla.gnome.org/show_bug.cgi?id=783599
When state of vaapisink is changed from PLAYING to NULL, the handle_events
flag is set to FALSE, and never recovered, and then event thread is never
going to run.
So we should allow to set the flag only when users try it.
https://bugzilla.gnome.org/show_bug.cgi?id=782543
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
