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>
The assertion that was present before is a bit too harsh, since there is now
a (understandable) use-case where this could happen.
In gapless use-case, with two files containing the same type (ex:audio). The
first one *does* expose a collection with an audio stream, but decoding
fails (for whatever reason).
That would cause us to have configured a audio combiner, which was never
used (i.e. not active).
Then the second file plays and we (wrongly) assume it should be activated
... whereas the combiner was indeed present.
Demote the assertion to a warning and properly handle it
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6737>
Clarify the fact that `encodebasebin->src_pad` is set when using a static source
pad (`encodebin`) and when not set it's dynamically added source
pads (`encodebin2`).
Fixes usage of encodebin2 when profiles are updated
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6667>
Since https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6153 ,
subtitle "decoders" (i.e. which decode to raw text) are no longer auto-plugged
by parsebin.
But if a given format does not have a parser at all, we would end up outputting
non-time/non-parsed outputs.
In order to mitigate the issue, until such parsers are available, we check if
the subtitle stream is in TIME format or not (i.e. whether it comes from a
parser or demuxer). If not, we attempt to plug in a subtitle "decoder".
Fixes#3463
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6592>
Reset the waiting thread counter in all places to be consistent
when sending signal for the audio ring buffer. This fix applies it to
pause, stop and release, which are states that will go into a callback
of the subclass. Having the waiting counter reset will avoid having
executing thread of the same subclass trying to take the mutex when
callong gst_audio_ring_buffer_advance.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6195>
On practice a failure happened due to a race condition, the instance
already have been freed, but it could also happen if the instance
would be null.
Instead of crashing this sanity check is a more suitable option,
since with G_DEBUG=fatal-warnings it will crash too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6475>
This reverts commit 8e923a8e2d.
This caused regressions, see #3303.
Without this commit, osxaudiosrc ! osxaudiosink won't work
right, but since that hasn't really been a huge problem
for years it's probably best to revert this until a proper
solution can be figured out.
(cherry picked from commit f04f86f3ee)
(cherry picked from commit 93255efece)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6405>
None of the GL allocators actually offer a generic alloc() implementation. As a
side effect, they cannot be offered as they don't work with generic video
buffer pool.
Our specialized buffer pool can be dropped by tee or alphacombine as sharing the
same buffer pool over two branch is not supported by the pool API.
Fixes#3372
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6327>
Memory from gst_adapter_map() could live shorter than the GstMemory that the GstBuffer wraps around it, which in lucky
cases 'just' caused a re-use of the same memory for multiple (potentially still in use!) input buffers, but could easily
end up pointing to an already-freed memory.
Manifested when an AudioToolbox encoder kept getting silence inserted in seemingly random circumstances, turned out
to be the memory being re-used by GStreamer at the same time that the AT API was processing it...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6320>
