An application that triggers a state transition from PLAYING to PAUSED
needs to acquire the LIVE_LOCK. Consequently the LIVE_LOCK must not be
taken while pushing anything on the pads because this operation might
get blocked by something that cannot be unblocked without the
application being able to proceed with the state transitions for other
elements in the pipeline. This commit extends the previous behaviour
where the live lock was released before pushing buffers (indirectly
through the unlock before subclass->create) to now also include
unlocking before pushing events.
The issue was discovered in a case for WebRTC where the application
tried to shut down a pipeline but an event originating from a video
source element (based on basesrc) was in the process of being pushed
down the pipeline when it got stuck on the STREAM_LOCK for the pad after
the rtpgccbwe element. This lock in turn was held by the rtcpgccbwe
element as it was in the process of pushing data down the pipeline but
was stuck on the blocking probes installed on dtlssrtpenc to prevent
data from flowing before dtls keys had been negotiated. What should have
happened here is that the blocking probes should be removed, but that
can only happen if the application may continue driving the state
transitions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6671>
And handle the case of a NULL buffer being returned cleanly, which is
valid as long as a buffer list is returned instead. Previously this
would cause an assertion because of calling gst_buffer_unref() with
NULL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6460>
decodebin(3) runs a scheduling query before pads are activated which
ultimately triggers basesrc->start which will automatically call
`gst_base_src_start_complete` for any source that is not marked as
'async'. This calls will harmlessly bail out in `not_activated_yet`
so we should not warn in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6011>
When we finish a frame, we pass a size which semantic can easily be confused.
Improve the documentation to clarify that the parameter size is the amount of
input data being consumed and, if set, the output_buffer size can differ.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5754>
Test included.
The problem appears when aggregator drops the query while
it's being proccessed by the klass->sink_query handler.
This can happen on FLUSH_START event. If the query is still
in the queue, it can be safely dropped, but if it's already
in the klass->sink_query() handler, then sink pad has no
choice and has to wait for the proccessing to complete.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5765>
When the subclass attempts to finish without an explicit `out_buffer`,
we take a buffer from our adapter. We need to make this buffer writable
before copying the metadata.
This led to data races such as in the following pipeline, which randomly
messed up the buffer PTS:
gst-launch-1.0 -e audiotestsrc timestamp-offset=5555 num-buffers=100 \
! opusenc ! tee name=t ! queue ! opusparse ! fakesink silent=0 \
t. ! queue ! opusparse ! fakesink silent=0 -v | grep '0000, dur'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5718>
When the property "start-time-selection" is set to "first", it
calculates the start time of the output from the buffer pts
(converting it to running time of the segment), but if the
rate is negative, the real start is not the pts, but the
pts + duration, because it plays from the end of the buffer
to it's start.
As a result of this bug, in the negative rate, when the
start-time-selection=first, the first frame is dropped
by the videoaggregator (reproduced on d3d11compositor).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5276>
unlock_stop() is expected to be run while the streaming thread is idle. To
guaranty this is the case, we should take the streamlock, but its not
possible to take this lock during state transitions from PAUSED to
PLAYING as the wait function that we want to terminate is holding it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
After a create() call, which may have returned FLUSHING or a filled buffer,
if it possible that we detect that we are now in pause. As live sourced
don't produce data in pause, drop the buffer is any and later retry creating
a buffer. This will ensure that we resume from pause while avoiding displaying
ancient frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
When the pipeline goes from Playing to Paused, this change will invoke
unlock in the derived class. When the pipeline goes from Paused to
Playing, this change will invoke unlock_stop in the derived class.
This feature was removed in commit 523de1a9 and is now being restored.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
Adds gst_queue_array_sort for sorting and gst_queue_array_push_sorted{,struct} for pushing in a sorted order.
All three functions accept a comparison GCompareDataFunc along with optional user_data to pass to it.
In gst_queue_array_sort a small workaround was needed to correctly sort non-struct arrays. Like what _find() already
does, we need to dereference our pointers first, to make sure we can use the same comparison functions everywhere.
This is done via a small wrapper around the provided comparison function.
The array can also wrap around (tail ends up 'before' the head), in which case we have to reorder the array (similar to
what do_expand() does) to then be able to use an existing sorting function, like g_qsort_with_data().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5112>
Race condition without this patch:
- srcpad task is being stopped in gst_aggregator_stop_srcpad_task()
- at that moment, in pre-queue event handler, gst_pad_get_task_state()
returned GST_TASK_PAUSED
- then in srcpad task got stopped in gst_aggregator_stop_srcpad_task()
- finally srcpad task got resumed in pre-queue event handler
To address it, checks "running" flag in pre-queue event handler.
Both pre-queue stream-start event handler and "running" flag
are protected by SRC_LOCK already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4847>
The generated gir file marks the size parameter as "out" by default.
This is wrong in the context of a caller allocated buffer with a given size.
Explicitly marking the size parameter as (in) fixes the issue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4399>
gst_base_src_new_segment() does not send the segment right away, which
may break events ordering if subclass sends other events after
calling it.
Introducing a variant pushing the segment right away to preserve
ordering in such cases.
Will be used by appsrc which has its own internal queue where we need to
preserve events order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4297>
A flush is resetting or not depending on the reset_time argument in the
FLUSH_STOP event is set.
Resetting flushes reset the running time to zero and clear any existing
segment. These are the kind of flushes used by flushing seeks, and by far the
most common. Non-resetting flushes are much more niche, used for instance for
quality changes in adaptivedemux2 and MediaSource Extensions in WebKit.
A key difference between the seek use case and the quality change use case is
that the latter is much more removed from the player. Seeks generally occur
because an user request it, whereas quality changes can be automatic.
Currently, there are three notable cases where position queries fail:
(a) before pre-roll, as there is no segment yet. This is one is understandable,
as for at least some time before pre-roll, we cannot know if a media stream
would start at 0 or any other position, or the duration of the stream for that
matter.
(b) after a resetting flush caused by a seek. This kind of flush resets the
segment, so it's not surprising position queries fail. This is inconvenient for
applications, as it means they always need to handle position reporting (e.g.
in UI) separately every time they request a seek, e.g. by caching the seek
target and using it when the position query fail. I'm not fond of this
behavior, as it's unintuitive and makes GStreamer harder to use, but at this
point could be difficult to change and it's not within the scope of this
proposal.
(c) after a non-resetting flush, e.g. caused by a quality change. The segment
is not reset in this case. Position queries work until a FLUSH_STOP is sent.
Querying position after a FLUSH_START but before a FLUSH_STOP works, and
returns the position the sink was at the moment the FLUSH_START was received.
**This in fact the only reliable way (short of adding probes to the sink
element) to get this position**, as FLUSH_START receival is asynchronous with
playback.
In the case (c), as of currently, position queries fail once the FLUSH_STOP is
received. But unlike in (b), the application has no position to fall back to,
as the FLUSH_START was initiated by elements inside the pipeline that are in a
lower layer of abstraction. Specific applications that have control of both the
player and the internal element doing the flushing -- such as WebKit -- can
still work around this problem through layer violations (lucky!), but this
still puts in question this behavior in GStreamer.
This patch fixes this case by amending the position query handler of basesink,
which was previously erroneously returning early with "wrong state", even
though the flush occurs in PAUSED or PLAYING.
A unit test checking this behavior has also been added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3471>
The previous implementation was a bit primitive, assuming the subclass
had registered a template name starting with sink_ . Instead make
the effort of parsing the actual template name, and use that to generate
the final pad name.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4032>
Pads are activated automatically when they are added if the element
state is >=PAUSED, so it's not necessary to activate them manually
anymore.
This patch removes manual pad activation from gstaggregator, gstconcat,
gstfunnel, and gstinputselector.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3636>
