mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-12-13 03:46:34 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/gst/vaapi/gstvaapipluginbase.h

318 lines
9.8 KiB
C
Raw Normal View History

plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
/*
* gstvaapipluginbase.h - Base GStreamer VA-API Plugin element
*
* Copyright (C) 2010-2011 Splitted-Desktop Systems
* Author: Gwenole Beauchesne <gwenole.beauchesne@splitted-desktop.com>
* Copyright (C) 2011-2013 Intel Corporation
* Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public License
* as published by the Free Software Foundation; either version 2.1
* of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free
* Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
* Boston, MA 02110-1301 USA
*/
#ifndef GST_VAAPI_PLUGIN_BASE_H
#define GST_VAAPI_PLUGIN_BASE_H
#include <gst/base/gstbasetransform.h>
#include <gst/video/gstvideodecoder.h>
#include <gst/video/gstvideoencoder.h>
#include <gst/video/gstvideosink.h>
#include <gst/vaapi/gstvaapidisplay.h>
G_BEGIN_DECLS
typedef struct _GstVaapiPluginBase GstVaapiPluginBase;
typedef struct _GstVaapiPluginBaseClass GstVaapiPluginBaseClass;
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
typedef struct _GstVaapiPadPrivate GstVaapiPadPrivate;
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
#define GST_VAAPI_PLUGIN_BASE(plugin) \
((GstVaapiPluginBase *)(plugin))
#define GST_VAAPI_PLUGIN_BASE_CLASS(plugin) \
((GstVaapiPluginBaseClass *)(plugin))
#define GST_VAAPI_PLUGIN_BASE_GET_CLASS(plugin) \
GST_VAAPI_PLUGIN_BASE_CLASS(GST_ELEMENT_GET_CLASS( \
GST_VAAPI_PLUGIN_BASE_ELEMENT(plugin)))
#define GST_VAAPI_PLUGIN_BASE_PARENT(plugin) \
(&GST_VAAPI_PLUGIN_BASE(plugin)->parent_instance)
#define GST_VAAPI_PLUGIN_BASE_PARENT_CLASS(plugin) \
(&GST_VAAPI_PLUGIN_BASE_CLASS(plugin)->parent_class)
#define GST_VAAPI_PLUGIN_BASE_ELEMENT(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT(plugin)->element)
#define GST_VAAPI_PLUGIN_BASE_ELEMENT_CLASS(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT_CLASS(plugin)->element)
#define GST_VAAPI_PLUGIN_BASE_DECODER(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT(plugin)->decoder)
#define GST_VAAPI_PLUGIN_BASE_DECODER_CLASS(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT_CLASS(plugin)->decoder)
#define GST_VAAPI_PLUGIN_BASE_ENCODER(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT(plugin)->encoder)
#define GST_VAAPI_PLUGIN_BASE_ENCODER_CLASS(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT_CLASS(plugin)->encoder)
#define GST_VAAPI_PLUGIN_BASE_TRANSFORM(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT(plugin)->transform)
#define GST_VAAPI_PLUGIN_BASE_TRANSFORM_CLASS(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT_CLASS(plugin)->transform)
#define GST_VAAPI_PLUGIN_BASE_SINK(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT(plugin)->sink)
#define GST_VAAPI_PLUGIN_BASE_SINK_CLASS(plugin) \
(&GST_VAAPI_PLUGIN_BASE_PARENT_CLASS(plugin)->sink)
plugins: factor out GstImplementsInterface.
2013-12-13 12:24:24 +00:00
#define GST_VAAPI_PLUGIN_BASE_INIT_INTERFACES \
gst_vaapi_plugin_base_init_interfaces(g_define_type_id);
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
#define GST_VAAPI_PLUGIN_BASE_SINK_PAD(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->sinkpad)
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
#define GST_VAAPI_PLUGIN_BASE_SINK_PAD_PRIVATE(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->sinkpriv)
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
#define GST_VAAPI_PLUGIN_BASE_SINK_PAD_CAPS(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SINK_PAD_PRIVATE(plugin)->caps)
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
#define GST_VAAPI_PLUGIN_BASE_SINK_PAD_INFO(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(&GST_VAAPI_PLUGIN_BASE_SINK_PAD_PRIVATE(plugin)->info)
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->srcpad)
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->srcpriv)
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD_CAPS(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->caps)
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD_INFO(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(&GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->info)
plugins: check if negotiate dmabuf with downstream 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>
2016-06-02 20:13:51 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD_CAN_DMABUF(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->can_dmabuf)
plugins: use plugin base macros to access pad specific data Don't access base struct fields directly since the underlying definition can change. Instead, use the accessor macros.
2019-10-29 22:13:44 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD_BUFFER_POOL(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->buffer_pool)
plugins: use plugin base macros to access pad specific data Don't access base struct fields directly since the underlying definition can change. Instead, use the accessor macros.
2019-10-29 22:13:44 +00:00
#define GST_VAAPI_PLUGIN_BASE_SRC_PAD_ALLOCATOR(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->allocator)
plugins: use plugin base macros to access pad specific data Don't access base struct fields directly since the underlying definition can change. Instead, use the accessor macros.
2019-10-29 22:13:44 +00:00
#define GST_VAAPI_PLUGIN_BASE_OTHER_ALLOCATOR(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->other_allocator)
plugins: use plugin base macros to access pad specific data Don't access base struct fields directly since the underlying definition can change. Instead, use the accessor macros.
2019-10-29 22:13:44 +00:00
#define GST_VAAPI_PLUGIN_BASE_OTHER_ALLOCATOR_PARAMS(plugin) \
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
(GST_VAAPI_PLUGIN_BASE_SRC_PAD_PRIVATE(plugin)->other_allocator_params)
plugins: add COPY_OUTPUT_FRAME flag This patch add the member copy_output_frame and set it TRUE when when downstream didn't request GstVideoMeta API, the caps are raw and the internal allocator is the VA-API one. https://bugzilla.gnome.org/show_bug.cgi?id=785054
2018-02-15 18:29:51 +00:00
#define GST_VAAPI_PLUGIN_BASE_COPY_OUTPUT_FRAME(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->copy_output_frame)
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
#define GST_VAAPI_PLUGIN_BASE_DISPLAY(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->display)
plugins: factor out display creation process. Move common VA display creation code to GstVaapiPluginBase, with the default display type remaining "any". Also add a "display-changed" hook so that subclasses could perform additional tasks when/if the VA display changed, due to a new display type request for instance. All plug-ins are updated to cope with the new internal APIs.
2013-12-13 10:52:47 +00:00
#define GST_VAAPI_PLUGIN_BASE_DISPLAY_TYPE(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->display_type)
vaapisink: add support for "display-name" property. Add a "display-name" property to vaapisink so that the end user could select the desired output. Keep "display-name" in-line with the existing "display" (GstVaapiDisplayXXX type). So, for X11 or GLX, the "display-name" is the usual display name as we know for XOpenDisplay(); for Wayland, the "display-name" is the name used for wl_display_connect(); and for DRM, the "display-name" is actually the DRI device name. https://bugzilla.gnome.org/show_bug.cgi?id=722247
2014-07-25 09:13:29 +00:00
#define GST_VAAPI_PLUGIN_BASE_DISPLAY_NAME(plugin) \
(GST_VAAPI_PLUGIN_BASE(plugin)->display_name)
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
#define GST_VAAPI_PLUGIN_BASE_DISPLAY_REPLACE(plugin, new_display) \
(gst_vaapi_display_replace(&GST_VAAPI_PLUGIN_BASE_DISPLAY(plugin), \
(new_display)))
plugins: rework set_context() vmethod definition 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
2016-04-21 10:57:30 +00:00
#define GST_VAAPI_PLUGIN_BASE_DEFINE_SET_CONTEXT(parent_class) \
static void \
gst_vaapi_base_set_context (GstElement * element, GstContext * context) \
{ \
GstVaapiPluginBase *const plugin = GST_VAAPI_PLUGIN_BASE (element); \
\
gst_vaapi_plugin_base_set_context (plugin, context); \
GST_ELEMENT_CLASS (parent_class)->set_context (element, context); \
}
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
struct _GstVaapiPadPrivate
{
GstCaps *caps;
GstVideoInfo info;
GstBufferPool *buffer_pool;
GstAllocator *allocator;
guint buffer_size;
gboolean caps_is_raw;
gboolean can_dmabuf;
GstAllocator *other_allocator;
GstAllocationParams other_allocator_params;
};
plugins: base: add GstVideoAggregator subclass support
2019-11-14 19:54:59 +00:00
G_GNUC_INTERNAL
GstVaapiPadPrivate *
gst_vaapi_pad_private_new (void);
G_GNUC_INTERNAL
void
gst_vaapi_pad_private_reset (GstVaapiPadPrivate * priv);
G_GNUC_INTERNAL
void
gst_vaapi_pad_private_finalize (GstVaapiPadPrivate * priv);
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
struct _GstVaapiPluginBase
{
/*< private >*/
union
{
GstElement element;
GstVideoDecoder decoder;
GstVideoEncoder encoder;
GstBaseTransform transform;
GstVideoSink sink;
plugins: base: add GstVideoAggregator subclass support
2019-11-14 19:54:59 +00:00
GstVideoAggregator aggregator;
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
} parent_instance;
GstDebugCategory *debug_category;
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
GstPad *sinkpad;
GstPad *srcpad;
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
GstVaapiPadPrivate *sinkpriv;
GstVaapiPadPrivate *srcpriv;
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
GstVaapiDisplay *display;
plugins: factor out display creation process. Move common VA display creation code to GstVaapiPluginBase, with the default display type remaining "any". Also add a "display-changed" hook so that subclasses could perform additional tasks when/if the VA display changed, due to a new display type request for instance. All plug-ins are updated to cope with the new internal APIs.
2013-12-13 10:52:47 +00:00
GstVaapiDisplayType display_type;
GstVaapiDisplayType display_type_req;
vaapisink: add support for "display-name" property. Add a "display-name" property to vaapisink so that the end user could select the desired output. Keep "display-name" in-line with the existing "display" (GstVaapiDisplayXXX type). So, for X11 or GLX, the "display-name" is the usual display name as we know for XOpenDisplay(); for Wayland, the "display-name" is the name used for wl_display_connect(); and for DRM, the "display-name" is actually the DRI device name. https://bugzilla.gnome.org/show_bug.cgi?id=722247
2014-07-25 09:13:29 +00:00
gchar *display_name;
plugins: factor out support for raw YUV buffers on sink pads. Factor out propose_allocation() hooks, creation of video buffer pool for the sink pad, conversion from raw YUV buffers to VA surface backed buffers. Update vaapidecode, vaapiencode and vaapipostproc to cope with the new GstVaapiPluginBase abilities.
2013-12-17 17:52:23 +00:00
plugins: record downstream GstGLContext. Record GL context supplied by downstream elements. This can be useful, and further needed, to enforce run-time check that the GL context is compatible for use by libgstvaapi. e.g. check that we don't create a VA/GLX display for EGL/X11 contexts. https://bugzilla.gnome.org/show_bug.cgi?id=725643 Original-path-by: Matthew Waters <ystreet00@gmail.com>
2014-12-03 13:14:30 +00:00
GstObject *gl_context;
plugins: create a GL context on certain conditions 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
2017-01-26 11:02:56 +00:00
GstObject *gl_display;
GstObject *gl_other_context;
plugins: record downstream GstGLContext. Record GL context supplied by downstream elements. This can be useful, and further needed, to enforce run-time check that the GL context is compatible for use by libgstvaapi. e.g. check that we don't create a VA/GLX display for EGL/X11 contexts. https://bugzilla.gnome.org/show_bug.cgi?id=725643 Original-path-by: Matthew Waters <ystreet00@gmail.com>
2014-12-03 13:14:30 +00:00
remove gstvaapiuploader 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
2015-07-23 11:11:40 +00:00
GstCaps *allowed_raw_caps;
plugins: enable direct rendering with envvar 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
2016-12-08 17:51:54 +00:00
gboolean enable_direct_rendering;
plugins: add COPY_OUTPUT_FRAME flag This patch add the member copy_output_frame and set it TRUE when when downstream didn't request GstVideoMeta API, the caps are raw and the internal allocator is the VA-API one. https://bugzilla.gnome.org/show_bug.cgi?id=785054
2018-02-15 18:29:51 +00:00
gboolean copy_output_frame;
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
};
struct _GstVaapiPluginBaseClass
{
/*< private >*/
union
{
GstElementClass element;
GstVideoDecoderClass decoder;
GstVideoEncoderClass encoder;
GstBaseTransformClass transform;
GstVideoSinkClass sink;
plugins: base: add GstVideoAggregator subclass support
2019-11-14 19:54:59 +00:00
GstVideoAggregatorClass aggregator;
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
} parent_class;
plugins: factor out display creation process. Move common VA display creation code to GstVaapiPluginBase, with the default display type remaining "any". Also add a "display-changed" hook so that subclasses could perform additional tasks when/if the VA display changed, due to a new display type request for instance. All plug-ins are updated to cope with the new internal APIs.
2013-12-13 10:52:47 +00:00
plugins: factor out GstImplementsInterface.
2013-12-13 12:24:24 +00:00
gboolean (*has_interface) (GstVaapiPluginBase * plugin, GType type);
plugins: factor out display creation process. Move common VA display creation code to GstVaapiPluginBase, with the default display type remaining "any". Also add a "display-changed" hook so that subclasses could perform additional tasks when/if the VA display changed, due to a new display type request for instance. All plug-ins are updated to cope with the new internal APIs.
2013-12-13 10:52:47 +00:00
void (*display_changed) (GstVaapiPluginBase * plugin);
plugins: base: manage pad-specific data in a single struct Define a struct (GstVaapiPadPrivate) to encapsulate the pad-specific data (i.e. buffer pool, allocator, info, caps, etc.). Add an interface to retrieve the data struct for a given pad. Finally, update the base plugin to use the data struct throughout the implementation. This will enable us to easily extend the base plugin in the future to allow for N-to-1 pad subclasses (e.g. overlay/ composite).
2019-11-12 20:21:52 +00:00
GstVaapiPadPrivate * (*get_vaapi_pad_private) (GstVaapiPluginBase * plugin, GstPad * pad);
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
};
plugins: factor out GstImplementsInterface.
2013-12-13 12:24:24 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_init_interfaces (GType type);
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_class_init (GstVaapiPluginBaseClass * klass);
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_init (GstVaapiPluginBase * plugin,
GstDebugCategory * debug_category);
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_finalize (GstVaapiPluginBase * plugin);
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_open (GstVaapiPluginBase * plugin);
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_close (GstVaapiPluginBase * plugin);
plugins: ensure VA display matches GL context expectations. If a GstGLContext is supplied by the downstream element, then make sure that the VA plugin element gets a compatible display to what is requested by the GL context. e.g. re-allocate a VA/GLX display when a GLX context is provided by the downstream element.
2014-12-03 14:45:52 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_has_display_type (GstVaapiPluginBase * plugin,
GstVaapiDisplayType display_type_req);
plugins: factor out display creation process. Move common VA display creation code to GstVaapiPluginBase, with the default display type remaining "any". Also add a "display-changed" hook so that subclasses could perform additional tasks when/if the VA display changed, due to a new display type request for instance. All plug-ins are updated to cope with the new internal APIs.
2013-12-13 10:52:47 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_set_display_type (GstVaapiPluginBase * plugin,
GstVaapiDisplayType display_type);
vaapisink: add support for "display-name" property. Add a "display-name" property to vaapisink so that the end user could select the desired output. Keep "display-name" in-line with the existing "display" (GstVaapiDisplayXXX type). So, for X11 or GLX, the "display-name" is the usual display name as we know for XOpenDisplay(); for Wayland, the "display-name" is the name used for wl_display_connect(); and for DRM, the "display-name" is actually the DRI device name. https://bugzilla.gnome.org/show_bug.cgi?id=722247
2014-07-25 09:13:29 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_set_display_name (GstVaapiPluginBase * plugin,
const gchar * display_name);
plugins: factor out display creation process. Move common VA display creation code to GstVaapiPluginBase, with the default display type remaining "any". Also add a "display-changed" hook so that subclasses could perform additional tasks when/if the VA display changed, due to a new display type request for instance. All plug-ins are updated to cope with the new internal APIs.
2013-12-13 10:52:47 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_ensure_display (GstVaapiPluginBase * plugin);
plugins: factor out pad caps.
2013-12-17 17:46:07 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_set_caps (GstVaapiPluginBase * plugin, GstCaps * incaps,
GstCaps * outcaps);
plugins: base: add GstVideoAggregator subclass support
2019-11-14 19:54:59 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_pad_set_caps (GstVaapiPluginBase *plugin,
GstPad * sinkpad, GstCaps * incaps, GstPad * srcpad, GstCaps * outcaps);
plugins: factor out support for raw YUV buffers on sink pads. Factor out propose_allocation() hooks, creation of video buffer pool for the sink pad, conversion from raw YUV buffers to VA surface backed buffers. Update vaapidecode, vaapiencode and vaapipostproc to cope with the new GstVaapiPluginBase abilities.
2013-12-17 17:52:23 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_propose_allocation (GstVaapiPluginBase * plugin,
GstQuery * query);
plugins: base: add GstVideoAggregator subclass support
2019-11-14 19:54:59 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_pad_propose_allocation (GstVaapiPluginBase * plugin,
GstPad * sinkpad, GstQuery * query);
plugins: factor out decide_allocation() hook. Add a default decide_allocation() hook to GstVaapiPluginBase. The caps feature argument can be used to force a bufferpool with a specific kind of memory.
2014-08-21 12:10:36 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_base_decide_allocation (GstVaapiPluginBase * plugin,
plugins: remove param in gst_vaapi_plugin_base_decide_allocation()
2016-03-10 15:43:16 +00:00
GstQuery * query);
plugins: factor out decide_allocation() hook. Add a default decide_allocation() hook to GstVaapiPluginBase. The caps feature argument can be used to force a bufferpool with a specific kind of memory.
2014-08-21 12:10:36 +00:00
plugins: factor out support for raw YUV buffers on sink pads. Factor out propose_allocation() hooks, creation of video buffer pool for the sink pad, conversion from raw YUV buffers to VA surface backed buffers. Update vaapidecode, vaapiencode and vaapipostproc to cope with the new GstVaapiPluginBase abilities.
2013-12-17 17:52:23 +00:00
G_GNUC_INTERNAL
GstFlowReturn
gst_vaapi_plugin_base_get_input_buffer (GstVaapiPluginBase * plugin,
GstBuffer * inbuf, GstBuffer ** outbuf_ptr);
plugins: base: add GstVideoAggregator subclass support
2019-11-14 19:54:59 +00:00
G_GNUC_INTERNAL
GstFlowReturn
gst_vaapi_plugin_base_pad_get_input_buffer (GstVaapiPluginBase * plugin,
GstPad * sinkpad, GstBuffer * inbuf, GstBuffer ** outbuf_ptr);
plugins: rework set_context() vmethod definition 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
2016-04-21 10:57:30 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_set_context (GstVaapiPluginBase * plugin,
GstContext * context);
plugins: record downstream GstGLContext. Record GL context supplied by downstream elements. This can be useful, and further needed, to enforce run-time check that the GL context is compatible for use by libgstvaapi. e.g. check that we don't create a VA/GLX display for EGL/X11 contexts. https://bugzilla.gnome.org/show_bug.cgi?id=725643 Original-path-by: Matthew Waters <ystreet00@gmail.com>
2014-12-03 13:14:30 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_set_gl_context (GstVaapiPluginBase * plugin,
GstObject * object);
plugins: create a GL context on certain conditions 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
2017-01-26 11:02:56 +00:00
G_GNUC_INTERNAL
GstObject *
gst_vaapi_plugin_base_create_gl_context (GstVaapiPluginBase * plugin);
remove gstvaapiuploader 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
2015-07-23 11:11:40 +00:00
G_GNUC_INTERNAL
GstCaps *
plugins: Add more check for allowed raw caps. 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>
2018-12-24 06:08:42 +00:00
gst_vaapi_plugin_base_get_allowed_sinkpad_raw_caps (GstVaapiPluginBase * plugin);
plugins: add gst_vaapi_plugin_base_set_srcpad_can_dmabuf() This patch refactors the code by adding the function vaapi_plugin_base_set_srcpad_can_dmabuf(), it determines if the passed GstGLContext can handle dmabuf-based buffers. The function is exposed publicly since it is intended to be used later at GstVaapiDisplay instantiation. https://bugzilla.gnome.org/show_bug.cgi?id=788503
2017-10-04 06:30:51 +00:00
G_GNUC_INTERNAL
void
gst_vaapi_plugin_base_set_srcpad_can_dmabuf (GstVaapiPluginBase * plugin,
GstObject * object);
plugins: add gst_vaapi_copy_va_buffer() This helper function aims to copy buffers with VA memory to dumb buffers, when GstVideoMeta is not available dowstream. https://bugzilla.gnome.org/show_bug.cgi?id=785054
2018-02-15 18:32:19 +00:00
G_GNUC_INTERNAL
gboolean
gst_vaapi_plugin_copy_va_buffer (GstVaapiPluginBase * plugin,
GstBuffer * inbuf, GstBuffer * outbuf);
plugins: add new base object, store display in there. Introduce a new GstVaapiPluginBase object that will contain all common data structures and perform all common tasks. First step is to have a single place to hold VA displays. While we are at it, also make sure to store and subsequently release the appropriate debug category for the subclasses.
2013-12-13 09:24:26 +00:00
G_END_DECLS
#endif /* GST_VAAPI_PLUGIN_BASE_H */
Reference in a new issue Copy permalink