[wl_shell] is officially [deprecated], so provide support for the
XDG-shell protocol should be provided by all desktop-like compositors.
(In case they don't, we can of course fall back to wl_shell).
Note that the XML file is directly provided by the `wayland-protocols`
dependency and generates the protocol marshalling code.
[wl_shell]: https://people.freedesktop.org/~whot/wayland-doxygen/wayland/Client/group__iface__wl__shell.html
[deprecated]: 698dde1958
The gst_vaapi_plugin_base_get_allowed_raw_caps is used for both sink
pad and src pad, which cause some bugs. For sink pad, we need to verify
vaPutImage() while for the src pad we need to verify vaGetImage().
For vaapidecoderXXX kind of plugins, the case is more complex. We need
to verify whether the decoded result(in some surface, NV12 format most
of the time) can be vaGetImage to some raw image format. Add more check
to fix all these problems.
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/123
Signed-off-by: He Junyan <junyan.he@hotmail.com>
Don't subscribe to button press events when using a foreing window,
because the user created window would trap those events, preveting the
show of frames.
https://bugzilla.gnome.org/show_bug.cgi?id=791615
Check for display's color-balance properties, available by the VA-API
driver, before setting them.
Also logs an info message of those unavailable properties.
https://bugzilla.gnome.org/show_bug.cgi?id=792638
Instead of using gst_vaapi_display_set_property() or
gst_vaapi_display_get_property(), this patch set replace it usage
with g_object_set() or g_object_get().
Also the internal helper cb_set_value() is removed since it is not
used anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=788058
Make sure vaapisink create a va surface backed buffer pool and all
required attributes get assigned correctly for drm display type.
This is needed to make the below pipeline working:
gst-launch-1.0 filesrc location= raw_video.mov ! videoparse format=uyvy
width=320 height=240 framerate=30/1 ! vaapisink display=drm
https://bugzilla.gnome.org/show_bug.cgi?id=786954
Replacing GstVaapiDisplay during rendering might be hiding problems
at some cases, even though it's safe currently since we use cache
of GstVaapidisplay.
Play safe by failing if this happens.
https://bugzilla.gnome.org/show_bug.cgi?id=766704
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
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
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
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.
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
If vaapisink received a caps query before getting a VA display, it returned
only the surfaces related caps. This behavior broke the autovideosink
negotiation.
This patch returns the pad's template caps if no VA display, otherwise the
caps are crafted as before.
https://bugzilla.gnome.org/show_bug.cgi?id=767699
In bug 757598 was added the set_context() vmethod chain up in
GstVaapiPluginBase. But it is buggy, since the parent_class address is
assigned to the last element which called gst_vaapi_plugin_base_class_init().
No error has shown up since none of the element's base classes redefined
set_context() vmethod from GstElement, so always the correct function was
called. Still this code is wrong and this patch make it right.
Since set_context() is the same code, a macro is used to implement that code
in all the gst-vaapi elements.
https://bugzilla.gnome.org/show_bug.cgi?id=765368
There is no difference in VAAPI surface caps between encoders and decoders.
Thus, the patch makes a simplification by removing encoders specific caps and
shares the same definition of VAAPI surfaces caps for all the elements.
The P010 video format is the native format used by the vaapi intel driver
for HEVCMain10 decode . Add support for planes and images of this video format.
https://bugzilla.gnome.org/show_bug.cgi?id=759181
As gstreamer-vaapi now only supports from GStreamer 1.6, this patch removes
all the old GStreamer version guards.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
When gst_vaapi_plugin_base_get_input_buffer() fail to copy the input buffer
into a VAAPI buffer, the return value is GST_FLOW_NOT_SUPPORTED, and it was
ignored by the vaapisink, leading to a segmentation fault.
This patch ignores the frame that generated the GST_FLOW_NOT_SUPPORTED
returned by gst_vaapi_plugin_base_get_input_buffer(), avoiding the
segmentation fault, but doing and effort to continue rendering. This is
the same behavior of ximagesink.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=759332
Caps query can happen before the element has a bus. The display creation should
be should occur on the context negotiation, when the bus is already configured.
Then at caps query no display should be created.
Instead of force the display creation, we graciously fail the allowed_caps()
creation.
This change only applies for vaapidecode and vaapisink. The vaapipostroc, as a
basetransform descendant, seems to be not affected by this, nor the encoders.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
The current context query handling design is flawed: the function
gst_vaapi_reply_to_query() returns FALSE either if the query is not a
GST_CONTEXT_QUERY of if the query could not be handled correctly. But the
pad query function should handle differently each case.
This patch changes the gst_vaapi_reply_to_query() for
gst_vaapi_handle_context_query() and changes it usage in all the vaapi plugins
to match the correct context query handling.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757598
Refactor the main vaapi caps strings into three macros:
GST_VAAPI_MAKE_SURFACE_CAPS, GST_VAAPI_MAKE_ENC_SURFACE_CAPS and
GST_VAAPI_MAKE_GLTEXUPLOAD_CAPS.
Those are in gstvaapipluginutil.h so all the elements could use them, instead
of re-declaring them every time.
No functional changes.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Working on bug #744042 I realized that the gstvaapiuploader is practically not
used.
This patch removes the gstvaapiuploader and add the method
gst_vaapi_plugin_base_get_allowed_raw_caps () that returns the raw caps that
the system can handle, which is used by vaapisink and vaapipostproc.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752777
vaapisink takes the display lock, then does a gst_buffer_replace which can
take the lock on the gst_vaapi_video_pool.
vaapipostproc asks the gst_vaapi_video_pool for a new surface. This takes
the lock on the gst_vaapi_video_pool; if you're unlucky, there are no free
surfaces, which means that gst_vaapi_surface_create is
called. gst_vaapi_surface_create takes the display lock.
If vaapisink and vaapipostproc are in different threads, and this happens,
you get a deadlock. vaapisink holds the display lock, and wants the
gst_vaapi_video_pool lock. vaapipostproc holds the gst_vaapi_video_pool lock
and wants the display lock.
Work around this by releasing the display lock in vaapisink around the
gst_buffer_replace.
https://bugzilla.gnome.org/show_bug.cgi?id=738249
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
This patch enhance the code path when an error is found when rendering a
buffer.
If the video meta doesn't contain a surface proxy or a surface, a warning
message is printed.
If the rendering backend fails, a error message is posted in the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=749382
This fixes the regression introduced in 64acc74.
If a pad supports multiple set of capsfeatures, it needs to add
multiple equal structures with different feature sets to the caps.
Because caps structures with the same name but with a non-equal
set of caps features are not compatible.
Without this patch, playbin will autoplug xvimagesink instead of vaapisink.
https://bugzilla.gnome.org/show_bug.cgi?id=750095
Otherwise wl_display_dispatch_queue() might prevent the pipeline from
shutting down. This can happen e.g. if the wayland compositor exits while
the pipeline is running.
Changes:
* renamed unlock()/unlock_stop() to unblock()/unblock_cancel() in gstvaapiwindow
* splitted the patch removing wl_display_dispatch_queue()
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=747492https://bugzilla.gnome.org/show_bug.cgi?id=749078
vaapisink inherits from GstVideoSink, in order to use its functionality (such
as ::show-preroll-frame property), we should use its vmethod show_frame(),
rather than call ourselves render() and preroll().
