The colorspace conversion happens during the upload so the necessary hints
must be provided to ensure that the conversion works correctly.
At least the Mesa Intel driver will create a texture without error but
produces an incorrect result. Use eglQueryDmaBufModifiersEXT() to check if
non-external upload is supported for the given format.
Based on a patch from Carlos Rafael Giani <dv@pseudoterminal.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Building an image with yocto for an 'am335x' processor will fail,
because 'gbm.h' can not be found and 'EGL_PLATFORM_GBM_MESA' is not defined.
So simply adding define of 'EGL_PLATFORM_GBM_MESA' in 'gstgldisplay_egl.c'
and adding 'GBM_CFLAGS' in 'gst-gl.m4' to get rid of this errors and complete
a full build process.
ERRORs were:
-----------
gst-plugins-base-1.14.1/gst-libs/gst/gl/gbm/gstglwindow_gbm_egl.h:24:10:
fatal error: gbm.h: No such file or directory
#include <gbm.h>
^~~~~~~
gst-plugins-base-1.14.1/gst-libs/gst/gl/egl/gstgldisplay_egl.c:157:39:
error: 'EGL_PLATFORM_GBM_MESA' undeclared (first use in this function);
did you mean 'EGL_PLATFORM_WAYLAND'?
ret = _gst_eglGetPlatformDisplay (EGL_PLATFORM_GBM_MESA, (gpointer) display,
^~~~~~~~~~~~~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=796885
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
This patch adds code to gldownload to export the image as a
dmabuf if requested. The element now exposes memory:DMABuf as
a cap feature, and if it is selected, the element exports the
texture to an EGL image and then a dmabuf. It also implements a
fallback to system memory download in case the exportation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=776927
Except for gst/gl/gstglfuncs.h
It is up to the client app to include these headers.
It is coherent with the fact that gstreamer-gl.pc does not
require any egl.pc/gles.pc. I.e. it is the responsability
of the app to search these headers within its build setup.
For example gstreamer-vaapi includes explicitly EGL/egl.h
and search for it in its configure.ac.
For example with this patch, if an app includes the headers
gst/gl/egl/gstglcontext_egl.h
gst/gl/egl/gstgldisplay_egl.h
gst/gl/egl/gstglmemoryegl.h
it will *no longer* automatically include EGL/egl.h and GLES2/gl2.h.
Which is good because the app might want to use the gstgl api only
without the need to bother about gl headers.
Also added a test: cd tests/check && make libs/gstglheaders.check
https://bugzilla.gnome.org/show_bug.cgi?id=784779
Make a bunch of symbols private that are currently leaked
accidentally because they have a gst_* prefix and are used
internally. We mark those we can't make static with
G_GNUC_INTERNAL so that they get hidden with the autotools
build as well (although we could just pass -fvisibility=hidden
there too).
Found on rpi when gpu_mem is too low so there is not enough memory to
create the eglimage. But still gst_buffer_pool_acquire_buffer succeeded.
And it leads to a CRITICAL assert:
gst_egl_image_get_image: assertion 'GST_IS_EGL_IMAGE (image)' failed
https://bugzilla.gnome.org/show_bug.cgi?id=785518
It's been removed and thus compiling anything against GstGLMemoryEGL
would error with:
In file included from gstomxvideodec.c:41:0:
usr/include/gstreamer-1.0/gst/gl/egl/gstglmemoryegl.h:32:41: fatal error: gst/gl/egl/gstglcontext_egl.h: No such file or directory
#include <gst/gl/egl/gstglcontext_egl.h>
^
https://bugzilla.gnome.org/show_bug.cgi?id=774886
