The operations for the inside GstGLUploadElement->upload have race
condition. The _transform_caps() will creates this object if it does
not exist, while the _stop() and change_state() can destroy this object.
The _transform_caps() is called by the gst_base_transform_query(),
so it does not hold the stream lock. It may use the upload while the
_stop() and change_state() has already destroy that object, and then
crash.
Fix: #645
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/913>
Setting telemetry options, even to zero, causes libtheora to enable an expensive code path. For large enough videos (e.g. 1920x1080) this can increase the time to decode each frame by 30-40 ms, which can be enough to cause noticeable stutter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/887>
```
../subprojects/gst-plugins-base/ext/alsa/gstalsamidisrc.c:201:54: error: converting the result of '<<' to a boolean always evaluates to false [-Werror,-Wtautological-constant-compare]
snd_seq_ev_schedule_real (&ev, alsamidisrc->queue, SND_SEQ_TIME_MODE_ABS,
^
/usr/include/alsa/seq_event.h:215:34: note: expanded from macro 'SND_SEQ_TIME_MODE_ABS'
```
The ALSA API expects 0 or 1 here and will then add the flags accordingly,
and that's also what other code using this API does.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/777>
To document it, we instantiate a subclass and inspect the properties
on the created object. Subclasses (in that case textrender) may
initialize those properties with a different default, we do not
want to expose that in the base class documentation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/723>
If there are two elements and threads attempting to query each other for
an OpenGL context. The locking may result in a deadlock.
We need to unlock each element's context_lock when querying another
element for the OpenGL context in order to allow any other element to
take the lock when the other element is querying for an OpenGL context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/642>
Downstream may provide extra things when we ask it for caps that we may
need to remove.
Fixes the following pipeline warning:
gltestsrc ! glvideomixerelement ! glimagesinkelement
** (gst-launch-1.0:908581): WARNING **: 13:53:28.518: glvideomixer0: update_src_caps returned caps which are not a real subset of the filter caps
Fix the check for whether the element is operating in ARGB mode. It
was incorrectly checking if the output format has an alpha channel,
which is true for both ARGB and AYUV, leading to the element
incorrectly outputting ARGB values into AYUV caps.
* A copy-paste error was getting the information from the wrong
query
* The 'allocation_meta' GstStructure was being leaked
* No check was done on whether the query existed (to try to set the
resulting allocation meta on)
CID: 1439872
CID: 1439873
CID: 1439874
CID: 1439875
CID: 1439876
CID: 1439877
Fixes regression introduced by "clean-up" done as part of commit 98ebcb4.
dummy must live as long as use the return value of localtime_r() since
that's just a pointer to it, and by putting it inside the block we made
dummy go out of scope right after localtime_r() returned, which messed
up the time values since when we poked at the struct the contents might
already have been overwritten.
Fixes#722
This was added in 1.0.1 more than 16 years ago, I think we
can safely assume this is always present now. Also in tremor.
While at it, bump vorbis requirement to 1.3.1 from 2010.
When DMABuf was tried, we would renegotiate back and fourth between
DMABuf and system memory if the export failed. This would happen for
every single frame.
This patch introduces try_dmabuf_exports boolean, which is unset when
an export failed. This boolean is then put back to TRUE when upstream
pushes new caps, or downstream pushes a reconfigure event.
This introduces an enum in order to cleanup how we select the
transfer mode. It also fixes the case where we callback to PBO but
we didn't execute the PBO. That was not causing any issue, just that
the processing latency would be delayed to the next element, which
can be confusing.
