Prevent race condition where gst_play_sink_do_reconfigure() could be called
from a pad probe while stream synchronizer pads are being released during
GST_STATE_CHANGE_PAUSED_TO_READY transition.
The race occurred when:
1. State change starts releasing stream synchronizer pads
2. Pads are unblocked earlier in the state change, allowing events to flow
3. A streaming thread triggers sinkpad_blocked_cb -> gst_play_sink_do_reconfigure
4. Reconfiguration tries to use already-released pad pointers
5. New pad creation fails with assertion in gst_pad_iterate_internal_links
The fix adds GST_PLAY_SINK_LOCK around the pad cleanup to ensure atomic
cleanup and prevent concurrent access during state transitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9233>
The copy of the exact same stream-start event prevents the multiqueue's sink
event function from being called because it is already stored on both pads at
link time
The text streams are no longer considered sparse by the multiqueue, so
interleave calculation is broken and makes us consume a lot of ram and we can
end up killed by the kernel because of this
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8412>
The profile argument passed to gst_encode_base_bin_set_profile is now
transfer-full. This issue was noticed after commit
6beb709d43d2023e7e5dc8f1ee1323bc28c9d1d8 which fixed profile refcount handling
in transcodebin.
Driving-by, an encoding profile leak was also fixed in _set_profile, in case
it's called for an already active element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9167>
When using the custom WebKitMediaSrc element (used by WebKit and able to
perform an initial seek in playbin), a stall caused by streamsynchronizer
was detected during an initial seek. The flow of events revealed that the
intertwining of the initial configuration of the streams with the reset
caused by the flush events from the seek left streamsynchronizer in an
inconsistent state:
streamsynchronizer0:sink_0 (video) events, starting before the seek:
stream-start --> Sets the stream to wait
flush-stop --> Clears the stream wait flag
caps
tag
segment
stream-collection
(buffers start to come and flow properly)
streamsynchronizer0:sink_1 (audio) events, happening after seek:
(no flush events, because the stream hadn't been initialized when the seek happened)
stream-start --> Sets the stream to wait
caps
segment
(stalled because the stream is in wait mode!)
The code in streamsynchronizer expects that all the streams are in wait
state before releasing all of them at once. The flush on the video stream
broke that assumption and that's why the audio stream is never released in
that scenario.
Avoiding the clearing of the wait flag on flush-stop isn't an actual solution
to the problem, as it creates other side effects and at least makes the
gst-editing-services/seek_with_stop test to timeout. The alternate solution
implemented in this patch consists on analyzing if the other streams different
from the one newly added (after the flush) aren't waiting (which would mean
that they've all been unlocked after all of them were waiting before), and,
in that case, mark the new stream as also not waiting.
A new test_stream_start_wait test case has been added to demonstrate this
problem. The test case creates a video stream, pushes a buffer, then
simulates a seek by pushing flush-start, flush-stop, stream-start and segment
events. Note that the flush-stop clears the video stream waiting flag.
After that, a new audio stream is created and stream-start and new segment
events are sent. Note that stream-start will set the audio stream to wait.
Then a buffer is pushed on each stream. In the failing case, the test hangs.
In the working case (after this fix), the test runs properly because the
fact of having seen a stream-start also helps to clear the wait flag.
A second new test_stream_start_wait_sparse test has also been added to prove
that this mechanism can also work with sparse streams (a special case of the
current stream-start handling code). This test behaves like the previous one,
but there's no video buffer after the seek (it'll come in the future, as the
stream is sparse, but actually never comes). The buffer after the seek in the
audio stream starts at its due time. Streamsynchronizer is able to ignore
the wait for the video stream and produce audio buffers on time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4544>
The 'new-pref' property sets the preference to use the new (next)
instead of the old (previous) buffer. The default is set to 0.5 to get
a similar behaviour as before the change.
Value 0.0 makes sure that only frames are shown where it's known that
the frame content is visible at that time, always show the old frame
until the new frame timestamp is reached.
Then, if the next buffer replaces the previous buffer the new buffer
is pushed as often as possible until PTS is reached. Before the new
buffer was only pushed once the new next buffer arrived.
Use GstClockTimeDiff because it's known that the current buffer time
is inside the time interval of previous buffer and next buffer the
calculation can be done with building absolute values. Special macros
are not needed here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8579>
`parsebin` is potentially added by a `typefind` callback.
That `typefind` was activated by a `READY_TO_PAUSED` state change on `urisourcebin`
We want to ensure that it is the "setup_parsebin_for_slot" method that activates
the underlying `parsebin`, and not the external state-change.
Otherwise we would risk a potential deadlock where elements activating in
`parsebin`, and which would cause the upstream `typefind` to switch scheduling
mode, would not be able to acquire the STREAM_LOCK of the `typefind` task.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8511>
The property is defined as:
> The difference between incoming timestamp and next timestamp must exceed
> the given value for audiorate to add or drop samples.
so if the gap duration < tolerance, we should not act.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8498>
AV1 specification [1] define 2 AV1 raw bitstreams storage
formats without containers:
- OBU in chapiter 5.2
- Annexb in chapiter 11.
Implement a detection function for the both cases mostly
by testing OBU forbidden, type, has_size_field and reserved bits.
For annexb case testing if temporal unit size, frame unit size and
obu length are valid. If they are check that the first OBU is
a temporal delimiter.
[1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8502>
The videotestsrc is not build if the adder plugin is disabled. This is a
copy/paste error introduced in Commit 3de86b2b9725 ("docs: port plugins to
explicit sources").
Fix the check to actually test the 'videotestsrc' option.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8399>
Some pixel aspect ratios found in dash streams have very large numerators and
denominators (while being close to 1:1). These values can cause integer overflow
during multiplication, leading to negotiation failures.
Add fallback path using gdouble when integer multiplication would overflow,
trading some precision for reliability instead of failing outright.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8262>
Fix-up after commit e56b78417. Unclear how that could
ever have worked. Code only built because basically
everything was disabled due to the missing config.h
include.
- Include config.h so that HAVE_* defines are available.
- Fix missing variable declarations that somehow disappeared
when moving the stats gathering code block into a separate
function in a new file.
- Fix structure variable modified to match name in new function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8211>
The reason why the STATE lock was taken was to avoid issues where we would be
adding (and activating) elements at the same time as urisourcebin would be
brought down to READY. That would cause those new elements to potentially return
ERRORS because of not-negotiated/flushing-pads
But that creates a really bad deadlock (state lock is taken to deactivate the
streaming thread which .. is currently grabbing the state lock).
Instead, we can just ignore the warning/error messages that might occur when
shutting down.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4075
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8162>
There is no reason why we should mandate people to "at least" use the static
sink pad. This caused issues, like mandating that it should always have valid
content linked to it (problematic in case of upstream stream changes).
Instead we only use it if it's actually linked to, in which case it gets added
to the list of inputs.
This actually simplifies the code too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7949>
When checking whether a no-longer used output could be re-used for another slot,
we only want to do that for streams which are not still used.
Otherwise we end up potentially re-assigning a demuxer stream to a completely
different one
Furthermore, if we *are* re-using an output slot, indicate what the replacement
GstStream will be so slot matching can work properly (which can happen in the
case of demuxers which add/remove all pads even if only a single one changed)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7949>
