The direct dmabuf upload does color conversion, so when it transforms
the caps, it replaces the format with all formats found through the
format query. When this uploader can't be used, it makes the upstream
source pick a unsupported format.
To fix this, we only append the caps with a list of format. So the
source will only pick one of these formats if the downstream preferred
format is not supported. A negotiation failure after this would be
normal.
This fixes pipelines without a glcolorconvert element.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
The idea is that some GPUs (like the Vivante series) can actually
perform the YUV->RGB conversion internally, so no custom conversion
shaders are needed. To make use of this feature, we need an additional
uploader that can import DMABUF FDs and also directly pass the pixel
format, relying on the GPU to do the conversion.
Based on patches from Nicolas Dufresne <nicolas.dufresne@collabora.com> and
Carlos Rafael Giani <dv@pseudoterminal.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
If a upload method is selected then use it exclusively in transform_caps().
Also, reconfigure if the current caps don't match the current upload
method.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This should not be necessary, but currently not all plugins that provide
dmabuf memory announce this with caps features, e.g. v4l2.
The static caps already contain the system memory. It didn't break before
because other upload methods provide the necessary transformation.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Reconfigure will trigger a set_caps which clears the upload method.
Remember the method in this case and start with it.
Wrap around once to try all methods if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
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
gst_gl_memory_setup_buffer() was not properly using the number
of pointers to wrapped. This also fixes the validation, as we
only support 1 wrapper per view, or num_planes * views wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
Using the correct blend modes for each case or converting to
premultipled in the very unlikely case that separate blend modes are
unavailable on ancient opengl hardware.
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
There are a lot of symbols in GstGL-1.0.gir generated by automake that
are not when it is generated by meson, because a lot of headers were
not included in meson's gir generation.
https://bugzilla.gnome.org/show_bug.cgi?id=797158
The purpose of value_name in GEnumValue structure is to express in
text format the name of the enum, not a description of the value, so
it can be use later for the gir file generation.
https://bugzilla.gnome.org/show_bug.cgi?id=797144
Reconfigure will trigger a set_caps which clears the upload method.
Remember the method in this case and start with it.
Wrap around once to try all methods if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
The idea is that some GPUs (like the Vivante series) can actually
perform the YUV->RGB conversion internally, so no custom conversion
shaders are needed. To make use of this feature, we need an additional
uploader that can import DMABUF FDs and also directly pass the pixel
format, relying on the GPU to do the conversion.
Based on patches from Nicolas Dufresne <nicolas.dufresne@collabora.com> and
Carlos Rafael Giani <dv@pseudoterminal.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
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
If a upload method is selected then use it exclusively in transform_caps().
Also, reconfigure if the current caps don't match the current upload
method.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This should not be necessary, but currently not all plugins that provide
dmabuf memory announce this with caps features, e.g. v4l2.
The static caps already contain the system memory. It didn't break before
because other upload methods provide the necessary transformation.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
gst_gl_memory_setup_buffer() was not properly using the number
of pointers to wrapped. This also fixes the validation, as we
only support 1 wrapper per view, or num_planes * views wrapper.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
gst_gl_window_dispmanx_egl_set_window_handle() removes native window handle
(dispmanx element), regardless it was foreign window handle
(set via gst_video_overlay_set_window_handle()) or not.
This problem prevents glimagesink reusable.
(PAUSED -> READY -> PAUSED does not work)
This patch corrects it comparing the native window handle with foreign window
handle. This behavior is same as gst_gl_window_dispmanx_egl_close().
https://bugzilla.gnome.org/show_bug.cgi?id=785199
The glimagesink wayland backend lacks the implementation of
gst_gl_window_wayland_egl_set_preferred_size. Because of this, glimagesink windows on
wayland are created with a fixed window size of 320x240.
[Matthew Waters]: gst-indent sources
https://bugzilla.gnome.org/show_bug.cgi?id=789384
This allows consumers of the gstgl dependency where gstgl is optional
to do things like:
config_data.set('HAVE_GST_GL', gstgl_dep.found())
deps = [gstvideo_dep, gstgl_dep]
meaning they can still use the dep unconditionally. With the
disabler we would just disable the whole target even if the
gstgl part was an optional extra. We can add an option to
dependency() later to let users/consumers of the dep decide
if they want a not-found dependency or a disabler instead.
It's also needed by the generic/states test and the variable
is currently checked as part of the opengl lib tests so wouldn't
be available if opengl was disabled.
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
This was miss-leading VAAPI which was not forcing linear back buffers,
would still export DMABuf. That caused bad rendering as the buffers are
tiled and most likely compressed.
https://bugzilla.gnome.org/show_bug.cgi?id=796822
This was miss-leading VAAPI which was not forcing linear back buffers,
would still export DMABuf. That caused bad rendering as the buffers are
tiled and most likely compressed.
e4bf9ed8f0 was not quite right and changed
the wrong thing. Intead we needed to change the multiplication order
and should have kept the previous to/from matrices as is done in this
patch.
We would make the subproject conditional on the wrap-mode=nodownload
however get_option('wrap-mode') or similar is not available from
meson.build files as the wrap-mode is meant to be used automatically.
Instead use the dependency fallback mechanism to get at the subproject
where possible i.e. when downloading is allows and only add the compat
includes when we have a valid internal dependency from the gl-headers
subproject.
https://bugzilla.gnome.org/show_bug.cgi?id=796534
This reverts commit 82c43ff9a3.
Reverting for the time being, since it trips up build bots
that don't have network connectivity.
We ideally shouldn't have a subproject that's used unconditionally.
The matrices were converting the wrong values with non-diagonal-only matrices.
e.g. a typical yflip matrix in [-1,1]^3 such as
1 0 0 0
0 -1 0 0
0 0 1 0
0 0 0 1
Would have actually required a matrix like this in [0,1]^3
1 0 0 0
0 -1 0 0
0 0 1 0
0 -2 0 1
Which is
1. not consistent with our multiplication convention and would require
transposing matrices or changing our multiplication order (from what is
generally used on opengl matrix guides/tutorials).
2. Produces incorrect values when input with actual vertices accounting for
the difference in multiplication order. e.g. some vertices multiplied by
the yflip matrix using vertex * yflip(== transpose(yflip) * vertex):
vertex: -> result: expected:
vec4(1,0,1,1) -> vec4(1,-2,1,1) vec4(1,1,1,1)
vec4(1,1,1,1) -> vec4(1,-3,1,1) vec4(1,0,1,1)
With the updated values, we now get the expected values.
Includes a test for this behaviour and the example above
For a single format in the caps, we were returning some weird answers,
like only RGB formats for a RGB input when we can also support YUV from
RGB.
Fixup of 3cfff727b1 where I thought my
previous (~6month) self had got this right. Don't trust your previous
self people!
Also yield common options to the outer project (gst-build in our case)
so that they don't have to be set manually and use array types for some
options.
Instead of having special cases at each GL texture creation, upload,
readback or copy for all non-8-bits-per-components.
Simply store the more specific format and retrieve the generic
component/type tuple from that.
Introduce a helper function for retrieving the generic GL format (RGBA,
RGB, RG, R, L, A) and type (BYTE, SHORT, SHORT_5_6_5) from a sized
GL format enum (RGBA8, RGB565, RG8, etc).
