* if downstream provides us with a pool that can allocate DMA buffers,
gldownload wraps it into a GL buffer pool that uses
glEGLImageTargetTexture2DOES() to import dmabuf into textures
* upstream GL elements can allocate from that pool
* gldownload unwraps DMA buffers from incoming GL buffers and passes
them downstream
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6792>
When measuring video latency, one mechanism involves taking a photo
with a camera of two screens showing the test video overlayed with
timeoverlay or clockoverlay. In these cases, if the display's pixel
response time is crappy, you will see ghosting due to which it can be
quite difficult to discern what the current timestamp being shown is.
This commit adds a property that *also* shows the timestamp in
a different (sequentially predictable) location every frame, which
makes it easy to tell what the latest rendered timestamp is.
For bonus points, you can also use the fade-time of the previous frame
to measure with sub-framerate accuracy when the photo was taken, not
just clamped to the framerate, giving you a higher precision latency
value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6935>
Simple gst_gl_sync_meta_wait() is not sufficient to ensure GL commands
are executed before dma-buf devices get to see the buffer.
This is the first step that should make the code behave correctly for
everybody, although there may be performance penalty. In the future we
should introduce a more general sync meta that would allow to move the
waiting from gldownload (the producer) to the sink elements (the
consumers).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6968>
when pipline is
glvideomixerelement->glcolorconvertelement->gldownloadelement and
glcolorconvertelement is not passthrough, the gl bufferpool between
glvideomixerelement and glcolorconvertelement will not add gl sync meta
during allocating buffer. This will cause that glcolorconvert's inbuf
has no sync meta to wait for.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6756>
When overlay coordinates are updated, after the initial coordinates
are set, the shader indices are applied to the wrong buffer, resulting
in the background image appearing where the overlay should.
Bind the array buffer before applying subsequent coordinate
updates.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5901>
If text width ever reached 1px, for example after resizing the output window, the overlay would stop rendering
and never return again. The 1px condition itself does not seem to make much sense here anyway.
This was a chain of events: width reached 1, so the composition was set to NULL. Then, after resizing the output window,
push_frame() was called but would not attempt to renegotiate because composition is NULL. This caused the width/height
to never be updated again, as that only happens during negotiation, so the overlay was gone for good.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5614>
Followup to 75872c802b , clang version
While we ignore `discarded-qualifiers` already for gcc, clang seems
to assign this error to `incompatible-pointer-types-discards-qualifiers`
so we need to ignore that as well.
```
In file included from \
../subprojects/gst-plugins-base/ext/cdparanoia/gstcdparanoiasrc.h:37: \
/usr/include/cdda/cdda_interface.h:164:3: error: initializing 'char *' with an expression \
of type 'const char [8]' discards qualifiers [-Werror, \
-Wincompatible-pointer-types-discards-qualifiers]
"Success",
^~~~~~~~~
```
See 75872c802b for more
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5474>
The same is done in the set_property function. This was noticed when attempting
to dump a pipeline containing glsinkbin sink=gtk4paintablesink to dot format.
Critical warnings were raised due to the missing force-aspect-ratio property on
that sink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5311>
Fixes a potential GPU stall if an immediately freed texture/buffer is
attempted to be reused immediately by the CPU, e.g. when uploading.
Problematic scenario is this:
1. element does GPU processing reading from texture
2. frees the buffer back to the pool
3. pool acquire returns the just released buffer
4. GPU processing then has to wait for the previous GPU operation to
complete causing a stall
If there was a reliable way to know whether a buffer had been finished
with across all GPU drivers, we would use it. However as that does not
exist, this workaround is to keep the released buffer unusable until the
next released buffer.
This is the same approach as is used in the qml (Qt5) elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5144>
Subclasses may want to override the pad template with different formats
or with a different pad subclass.
The original beahviour is still available by calling
gst_gl_mixer_class_add_rgba_pad_templates() in _class_init() of the
subclass.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4608>
If gst_buffer_pool_set_config() fails then the pool will use its old
config. This may include different width or height when
pic_width/pic_height != frame_width/frame_height.
As a result, the assertions in theora_handle_image() will fail.
So check the result of gst_buffer_pool_set_config() and only use the pool
if it succeeds. Otherwise let the parrent decide_allocation() create a new
pool.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4600>
