This should fix pipelines such as this one to work as expected
... ! opusenc ! capsfilter caps='audio/x-opus,
channels=1; audio/x-opus, channels=2' ! ...
The expectation is that the encoder will propose the first structure
before the second one to the source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3673>
The number of expected pads was:
* Defaulting to 1
* Or being overriden by GST_MESSAGE_STREAMS_SELECTED
This fails if upstream isn't a selectable source and has multiple streams, and
would therefore cause failures with multi-stream gapless playback
Fixes#1672
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3658>
It is quite possible to have the blocking probe called from different streaming
threads when all expected pads are present.
* Notify all waiters by using g_cond_broadcast instead of g_cond_signal
* Properly remove the probe after waiting
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3658>
Using the "GstBin" flags to check if an adaptive demuxer is streams-aware isn't
a good idea since it prevents using elements which aren't bins.
Instead we see if a collection was posted by the demuxer by the time a pad is
added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3601>
We want to make it so that we prefer a higher, not lower, number of
channels. Otherwise, this pipeline would convert from 2 to 1 channels:
gst-launch-1.0 audiotestsrc ! audio/x-raw,channels=2 ! opusenc ! queue ! opusdec ! queue ! opusenc ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3494>
Whenever the surface is resized before the stream is negotiated, we endup
with an assertion in libgstvideo.
gst_video_center_rect: assertion 'src->h != 0' failed
This fixes it, by following the style aready in place, which is to ensure
surfaces have a minimum size of 1x1.
Fixes#1139
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3467>
gst-launch-1.0 audiotestsrc ! udpsink host=127.0.0.1
gst-launch-1.0 udpsrc ! audioconvert ! autoaudiosink
would crash with a floating point exception when clipping the input
buffer owing to a division by zero because no caps event was received.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3469>
Make sure that group-id of a given play item are made consistent from the
start (sources) and all the way through the output.
This ensures that we can reliably detect that we have switched to the next play
item on the output of decodebin3 (and we can therefore properly free/release it)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3457>
When shutting down, we want to remove the urisourcebin blocking probes ... but
we also want to propagate a GST_FLOW_FLUSHING upstream (and not
GST_FLOW_NOT_LINKED) to make the upstream task gracefully stop instead of
posting an error message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3457>
When `is_selection_done` is called, it checks that all the requested streams are
present in the active stream list ...
... except there could very well be a (about to be removed) stream from the
previous selection present.
Therefore filter the list of streams we add to the message by the streams which
are actually requested.
Fixes issues when switching between different stream types (ex: video-only to
audio-only).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3457>
Currently, when rtspsrc property add-reference-timestamp-metadata=true,
a downstream rtph264depay element will attach multiple copies of the
same GstReferenceTimestampMeta to the depayloaded media buffers. This
can have signficant performance impacts further downstream in a pipeline
like the following:
rtspsrc add-reference-timestamp-metadata=true ! rtph264depay ! h264parse ! ... ! rtph264pay ! ...
For example, if there are 10 packet buffers for a frame of RTP H.264
video, each of those packet buffers will contain the same reference
timestamp meta. The rtph264depay element will then attach all 10
metadata to the depayloaded frame. And then later when we payload the
frame buffer again for proxying, we now have 10 more buffers each with
10 instance of the same metadata. Allocating/deallocating 100+ instances
of metadata @ 30fps for multiple streams has a pretty large performance
impact.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1578
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3431>
The tile width in pixel is not always available. Notably for
8L128 10bit format, the tile is 8x128 bytes, and the pixel
format is fully packed. That means that the tile contains at
least 6 pixels per line, but it also hold some bits of the
pixel from the same line on the previous or next tile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3424>
