In gstvaapipluginbase.c we are using the macro USE_GST_GL_HELPERS to guard the
code related with GstGL. Nonetheless, in gstvaapipluginbase.h we are using
HAVE_GST_GL_GL_H macro in order to include the GstGLContext's header.
We should use only one to be homogeneous. This patch sets USE_GST_GL_HELPERS
in the header file.
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
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>
Since gstreamer 1.4 is not required to have pad query functions if the query
vmethods are used.
This patch guards out the pad query functions for gstreamer < 1.4
Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=757629
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
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.
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>
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.
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
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.
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.
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.
