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.
