There's nothing requiring <= 64 channels except for getting the reorder
map and creating a channel mixing matrix, but those won't be possible to
call anyway as channel positions can only express up to 64 channels.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6828>
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/6784>
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/6742>
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/6597>
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)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6384>
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/6339>
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/6350>
This will mimic the playbin2 behaviour, which sets the "next" entry to be
NULL.
The biggest impact this has is that when going back to READY the current play
entry will be discarded (instead of being kept around for when you go back to
PAUSED/PLAYING).
Fixes#3371
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6338>
find_slot_for_stream_id() will return a slot which has the request stream-id as
active_stream *or* pending_stream (i.e. the slot on which that stream is
currently being outputted or will be outputted).
When figuring out which slot to use (if any) we want to consider stream-id
which *will* appear on a given slot which isn't outputting anything yet the same
way as if we didn't find a slot yet.
Fixes races when doing intensive state changes
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6332>
Cocoa version of glwindow only checks the preferred size upon window creation. glimagesink sets the size right before
calling gst_gl_window_show(), which might be way after the window is created in some cases. If the size was set too
late, glimagesink on macOS would remain 320x240 unless manually resized.
This change makes sure to resize the existing window when _show() is called.
Curiously, this has always been an issue, but went from manifesting every once in a while to being almost completely
broken once old event loop workarounds were removed and gst_macos_main() was introduced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6276>
