Whenever that caps changes does not imply that a new segment will start.
Don't reset the last_ts if only the caps have changed. This fixes issues
if you have a stream without only first frame with TS=0, and have resolution
change happening. This was a regression introduced by !3059, which issue was
described in #1352. The reported issue is still fix after this change.
Fixes#1034
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5712>
When switching from a raw stream to an encoded stream we need to make sure the
slot is unlinked, there is code in place for this but it wasn't triggered
because the slot being reconfigured wasn't advertised as linked beforehand.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5133>
Do not attempt to send a streams-selected message when reassigning
an output slot in case upstream signalled that it is handling stream selection.
In this case decodebin3 doesn't keep track of stream
collections (`dbin->collection` is NULL).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5069>
Setting the input field on the empty slot prevents future linking of it and will
result in flow errors later on.
This was observed in WebKit's MediaStream source element, when it changes the
caps on one of its associated streams, from an encoded format to a raw video
format. The associated stream-id on the sticky stream-start event doesn´t
change, but the element creates a new GstStream with a different ID and sets it
on the stream-start event. Stream parsing is disabled in urisourcebin, so
decodebin3 handles the parsing. Without this patch we would end-up with unlinked
pads in decodebin3 after switching to the raw video format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5067>
Generating the source element is done when urisourcebin is doing the READY to
PAUSED state change, so it is reasonable to set the new source element to that
state.
This also allows detecting early failures with backing libraries or
hardware (checks done in NULL->READY).
Finally it makes more sense to have an element in READY when attempting to query
information from it (such as SCHEDULING queries or probing live-ness).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5058>
Fix compiler warnings about not using the return value when
freeing the GString segment with g_string_free(.., FALSE):
ignoring return value of ‘g_string_free_and_steal’ declared with attribute ‘warn_unused_result’
which we get with newer GLib versions. These were all harmless.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5015>
This is a small optimization and avoids restarting the next parsing
iteration on already accepted data.
On its own it would also fix ZDI-CAN-20968 (see previous commit) but the
previous commit independently is also a valid fix for it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4898>
self->eos was never reset after streamsynchronizer has sent EOS
(except on explicit flush or switching back to PAUSED).
As a result, synchronization was broken if new streams were pushed later
as gst_stream_synchronizer_wait() does not wait if self->eos is set.
Fix this by reseting self->eos on STREAM_START as that means a new
stream is being sent upstream and so a new EOS will follow later on.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4755>
When reconfigure_output_stream entry missing decoder path,
requested_selection should been update with what is really
active/selected immdiately with SELECTION_LOCK hold. So
use an optional message return from reconfigure_output_stream
and post it after release SELECTION_LOCK. This can make sure
other thread call to check_slot_reconfiguration will got
a correct requested_selection.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4656>
decodebin3 will do its best to figure out whether a parsebin is required to
process the incoming stream.
The problem is that for push-based stream it could happen that the stream would
not provide any caps, resulting in nothing being linked internally.
Furthermore, there is the possibility that a stream *with* caps would not be
using a TIME segment, which is required for multiqueue to properly work.
In order to fix those two issues, we force the usage of parsebin on push-based
streams:
* When the pad is linked, if upstream can't provide any caps
* When we get a non-TIME segment
Fixes#2521
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4499>
The goal of parsebin is to figure out which elements to link together in order
to provide elementary streams given any random input.
The problem is that deciding whether a given stream should still have more
elements plugged in or not was dependent on ... the presence of compatible
decoders (sic).
Instead of that, if we can't plug anymore elements on a given stream *and* it is
detected as being an elementary stream, expose it.
Fixes#2118
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4237>
If sticky events are present on parsebin source pads, we propagate them to the
multiqueue source pads. Those will be propagated on the new urisourcebin source
pads like in the other code paths.
This ensures that STREAM_START event are present on new source pads. If CAPS
event are also present (not guaranteed), they will also be available.
Fixes#2384
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4218>
Generating the source element is done when uridecodebin is doing the
READY to PAUSED state change, so it is reasonable to set the new source
element to that state.
This also allows detecting early failures with backing libraries or
hardware (checks done in NULL->READY).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4016>
The goal of the "global" group-id is to fix new inputs that do not come from the
same "source" as others. In order to ensure all "current" streams have the same
group-id we distribute the first valid group-id to all streams.
This commit fixes two issues with that:
* When inputs are unlinked they weren't always properly resetted (it would only
work if parsebin is used, which is no longer the default in
uridecodebin3/playbin3).
* When computing the global group-id, take into account unset
group-id (i.e. GST_GROUP_ID_INVALID).
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1698
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3712>
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>
