Y210 is a 10-bit YUY2, so we may re-use the YUY2 shaders but gl format
is set to RG16
Sample pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw,format=Y210 ! glimagesink
NV16/NV61 is basically the same as NV12/NV21 with a higher chroma resolution.
Since only the size of the UV plane/texture is different, the same shaders are used as for NV12/NV21.
This is done by reusing `gst_gl_memory_setup_buffer` avoiding to
duplicate code.
Without a VideoMeta, mapping those buffers lead to GstBuffer mapping the
buffer in system memory even when specifying the GL flags (through the
buffer merging mechanism) making the result totally broken.
We are using ARC to cleanup after ourselves.
../gst-libs/gst/gl/cocoa/gstglwindow_cocoa.m:159:20: error: unused variable 'queue' [-Werror,-Wunused-variable]
dispatch_queue_t queue = (__bridge_transfer dispatch_queue_t) window->priv->gl_queue;
^
This is needed for using GstGL with ANGLE as the GLES implementation
in Universal Windows Platform apps that use the Windows Runtime
(WinRT) instead of Win32, which is deprecated and not allowed in
Windows Store apps.
This has been tested with Servo on the Microsoft HoloLens 2, and seems
to work quite well.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
Simple addition for supporting EXT_platform_device typed display.
It's a kind of special display type (part of EGL specification)
which has no window at all.
To use EGLDevice explicitly, set environment "GST_GL_WINDOW=egl-device"
See also https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_platform_device.txt
The gltestsrc element was refactored to inherit from this base class which
handles the GL context. The sub-class only needs to implement the gl_start,
gl_stop and fill_gl_memory vfuncs, along with properly advertizing the GL APIs
it supports through the supported_gl_api GstGLBaseSrc class attribute.
Commit c71dd72b "gl/wayland: fix glib mainloop integration" was overeager
in removing the poll result test from the check function. This caused
dispatch to be called even if no new events are available on the
Wayland connection, which in turn would wake up the glib mainloop,
causing effectively a tight loop without ever blocking on the poll.
Fixes#603
We use this property in gst_gl_display_egl_from_gl_display, to set
foreign_display for the new GstGLDisplayEGL instance. This fixes a
problem where gst_gl_display_egl_finalize calls EglTerminate on a
pre-existing EGL connection.
It seems that eglCreatePlatformWindowSurfaceEXT is failing (with
EGL_BAD_ALLOC) because it thinks an EGL surface has already been created
for the wl_egl_window. The reason is that the "driver_private" field of
the wl_egl_window is getting clobbered by the function
wl_proxy_set_queue().
Since a wl_egl_window is not a wl_proxy, it shouldn't be passed to
wl_proxy_set_queue(). It just wraps a wl_surface (which is a wl_proxy).
And it looks like the queue for that surface is getting set earlier on
in the function anyway.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/621#note_184582
This patch fixes the following critical warning:
CRITICAL **: 11:33:32.843: Unknown GL format 0x0 provided
It would happen during the setup of a second pipeline involving the DMABuf
uploader, typically with a v4l2src element. The warning was raised because the
uploader had a cached EGLImage already filled but the formats were not
synchronized accordingly.
This makes a pipeline below works:
little endian:
gst-launch-1.0 videotestsrc ! video/x-raw,format=P010_10LE ! glimagesink
big endian:
gst-launch-1.0 videotestsrc ! video/x-raw,format=P010_10BE ! glimagesink
Instead of checking if the requested GL API is GLES2 (because ANY can
be set) the string is matched with the GLES2 prefix, and if so, then
the string is offset.
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means we
no longer need the macro there, but for most types in base/gst-libs we
don't want to break ABI, which means it's better to just keep it like it
is (and use the `#ifdef` instead).
As part of commit 808e7127, we prefixed the `GstWlWindow`'s `shell`
field with wl_, to differentiate it from the other types of shells a
Wayland compositor might support. However, this is apparently a struct
that we expose to our users, so changing it means we have an API break.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/592
When the glupload element renegotiates the caps, set_caps will reset the
method_impl to NULL, but the method will be kept. transform_caps tries
to use the method_impl to transform the caps, because a method is set,
but will segfault.
gst_gl_memory_setup_buffer() was marked as introspectable=0
anyway, so might just as well mark it as '(skip)' and suppress
the warning. Reason is the (element-type gpointer) on wrapped_data.
gstglmemory.c:1426: Warning: GstGL: gst_gl_memory_setup_buffer: argument wrapped_data: Missing (element-type) annotation
gstglmemory.c:1426: Warning: GstGL: gst_gl_memory_setup_buffer: argument wrapped_data: Missing (element-type) annotation
egl/gstegl.h:40: Warning: GstGL: symbol='EGL_EGLEXT_PROTOTYPES': Unknown namespace for symbol 'EGL_EGLEXT_PROTOTYPES'
Using a single condition variable for synchronization across all GL
messages is very slow on Windows and uses up to 20% CPU usage in some
workloads due to lock contention and false broadcasts.
Using per-message event handles reduces the CPU usage to negligible
amounts despite having to allocate a new event handle for each
message.
Implement the prepare and check functions according to the
documentation by returning TRUE when events should be dispatched
via the dispatch function.
As wl_display_read_events never blocks we can call it unconditionally
without looking at the poll status.
This simplifies the implementation and gets rid of a race where the
mainloop could get blocked due to nobody actually reading the events
from the wayland connection.
Doing so involves retrieving the current viewport from OpenGL which as
with any glGet operation, is expensive.
This means that the various sinks need to reset the viewport on draw.
In the process, fix resizing on cocoa.
If we only ever make it to READY, transform_caps can create an
internal convert object that will never be freed by basetransform's
stop vmethod (PAUSED->READY).
The use of mediump as a specifier in GLSL shaders will have limited
resolution and when used as texture coordinates may become inaccurate
over texture sizes of 1024.
Make consistent with what autotools puts into enabled_gl_apis
variable. Autotools puts 'gl' in there instead of 'opengl'.
This would cause problems when building -bad glmixers plugin
in meson against a -base that was built with autotools.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/871
Otherwise surface_width/surface_height stored in GstGLWindowPrivate
isn't changed, sometimes an unnecessary reconfigure event is sent on
sinkpad, then result in upstream reconfiguring.
Example pipeline:
gst-launch-1.0 videotestsrc ! msdkvpp ! glimagesink
Binding the vertex array to 0 will unbind everything else already.
In the previous order older versions of the Intel GL driver caused
errors to be printed for every single call when disabling the vertex
attrib arrays after binding the vertex array to 0.
Non-direct dmabuf uploads, just as direct dmabuf uploads, create EGL
images and thus GL textures of the same width as the imported image.
The input dmabuf line stride is not relevant to the resulting texture
in both cases.
This fixes the case where non-direct uploads of input dmabufs with line
stride larger than the width will for example cause glcolorconvert to
sample only the left part (width * bytes per pixel / stride) of the
image, causing a horizontally stretched and cropped output image.
If multiple DRM connectors are connected, currently the first one is
picked. Improve this by adding an environment variable that allows for
choosing a connector by name. The connector name has been made so they
are compatible with modetest/modeprint DRM utilities.
Related to #490
* List all connectors, modes, and encoders, even after picking one
* Add missing DRM_MODE_CONNECTOR_DPI string for logging and improve
existing strings
* Make sure the names matches modetest/modeprint from DRM utilities
Related to #490
This adds a few missing gst_object_unref calls for the opengl context in
gstglwindow_gbm_egl.c, as well as the missing close call for the
drm node fd in gst_gl_display_gbm_finalize.
Currently in Python it would become a signed 64 bit value but should
actually be an unsigned 32 bit value with all bits set.
This is the same problem as with GST_MESSAGE_TYPE_ANY.
See https://bugzilla.gnome.org/show_bug.cgi?id=732633
Rather then letting gst_gl_memory_setup_buffer guess the GL format used
for an eglimage after importing a dmabuf be explicit about it. This
fixes issues where dmabuf import may have used another format then
gst_gl_format_from_video_info would guess on the basis of the available
GL extensions.
In particular on etnaviv the gst_gl_format_from_video_info would
assuming a luminance + alpha GL format is used for YUY2, but the dmabuf
import will always use RG88. Which causes images to end up somewhat pink when
displayed on the screen.
When importing an egl image from dmabuf gst_gl_format_from_video_info
was used to work what the result GL format will be. Unfortunately that
will only work if the conventional format and the choosen DRM fourcc for
the format match up.
On etnaviv platforms there is no support for GL_EXT_texture_rg, so the
GL format chosen for YUY2 ends up being GST_GL_LUMINANCE_ALPHA. However
DRM does not do luminance + alpha as it's a legacy GL thing, so the
dmabuf import ends up using DRM_FORMAT_GR88.
To fix this, tie the DRM_FORMAT and the GL format together so they
always match up.
There is new code that ensures that we renegotiate after an
uploader transition if the negotiated caps have changed.
The problem is that the raw uploader will not really try and
fixate the input caps, but instead of return a subset with the
only the supported target texture.
This had two effect, raw uploads was always done renegotiated
once and the raw upload unit test was now failing as it didn't
expect a renegotiation.
As it's a valid check, simply relax the gst_caps_is_equal() check
and use a gst_caps_is_subset() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
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
