Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4317
This patch fixes a regression in
a35bf1e3847351703542869755b6b9e536b9d2fd.
The new calls to tracers in the affected change were being done while
holding the pad object lock, which wasn't the case in the old ones,
leading to the latency tracer deadlocking in gst_object_get_parent().
The dependency on the pad lock for those calls was accidental. This
patch removes it by temporarily unlocking during the affected calls,
not unlike how it's done when calling a probe callback or the
send_event() function of the downstream element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8925>
Similar to de30de865cd, this allows to follow the flow of events as they
arrive to a pad rather than only when they are pushed to a peer.
The hook is installed in gst_pad_send_event_unchecked() instead of
gst_pad_send_event() because the latter is often omitted: that is the
case especifically in gst_pad_push_event_unchecked(), where most event
propagation occurs.
This patch also makes use of the new hooks in the log tracer to log the
begining and end of the send_event processing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8330>
Previously, the tracer pad-push-event was only signalled on
gst_pad_push_event(). However, the sticky event handling code in
GStreamer uses gst_pad_push_event_unchecked() instead, which meant those
events were not logged.
This patch extends the definition of the pad-push-event tracer to cover
both calls to gst_pad_push_event() and any direct calls to
gst_pad_push_event_unchecked() that skip the former inside GstPad
private code.
gst_pad_push_event_unchecked() returns GstFlowReturn instead of
gboolean like gst_pad_push_event(). To maintain API compatibility, the
GstFlowReturn is converted to gboolean.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4182
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8342>
In the case where the bufferlist is writable, send the
buffers immediately without adding to the refcount. This
allows writable buffers to maintain their writability, even
without implementing a chain_list function on the element.
Adds a test to verify this property, where a writable list
maintains refcount 1, but a readonly list increases it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7894>
FLUSH_STOP is meant to clear the flushing state of pads and elements
downstream, not to process data. Hence, a FLUSH_STOP should not
propagate sticky events. This is also consistent with how flushes are a
special case for probes.
Currently this is almost always the case, since a FLUSH_STOP is
__usually__ preceded by a FLUSH_START, and events (sticky or not) are
discarded while a pad has the FLUSHING flag active (set by FLUSH_START).
However, it is currently assumed that a FLUSH_STOP not preceded by a
FLUSH_START is correct behavior, and this will occur while autoplugging
pipelines are constructed. This leaves us with an unhandled edge case!
This patch explicitly disables sending sticky events when pushing a
FLUSH_STOP, instead of relying on the flushing flag of the pad, which
will break in the edge case of a FLUSH_STOP not preceded by a
FLUSH_START.
If sticky events are propagated in response to a FLUSH_STOP, the
flushing thread can end up deadlocked in blocking code of a downstream
pad, such as a blocking probe. Instead, those events should be
propagated from the streaming thread of the pad when handling a
non-flushing synchronized event or buffer.
This fixes a deadlock found in WebKit with playbin3 when seeks occur
before preroll, where the seeking thread ended up stuck in the blocking
probe of playsink:
https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1367
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7632>
This commit makes sure that pads are valid for linking
after the pads has been temporarily unlocked in the linking process.
Not doing this opens up for a race condition where
pads potentially can be linked twice.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5670>
When the task already exists, we forgot to free the passed `user_data`.
This wasn't an issue for most C code, which doesn't pass a
`GDestroyNotify`, but bindings such as gstreamer-rs do!
That said, allocating a trampoline in gstreamer-rs just for it to get
thrown away again is awkward. Maybe we need a `gst_pad_resume_task`?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3920>
The event type for instant-rate-change events was poorly chosen,
leading to them being re-sent too late and even after EOS.
Add a mechanism in GstPad for the sticky event order to be
different to the value of the event type to fix that up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3387>
The scenario is the following:
* Thread 1 is pushing an EOS event on a sinkpad
* Thread 2 is pushing a STREAM_START event on the same sinkpad before Thread 1
returns. Note : It starts pushing the event after Thread 1 took the object lock.
There is a potential race between:
* The moment Thread 1 sets the EOS flag once it has finished sending the
event (via store_sticky_event). When it does that it has both the STREAM and
OBJECT lock
* The moment Thread 2 sends the STREAM_START event (Which should release that
EOS status), but removing the EOS flag is only done while holding the OBJECT
lock and not the STREAM_LOCK, which means it could be re-set by Thread 1 before
it then checks again the EOS flag (without the STREAM lock taken).
The EOS flag unsetting by STREAM_START should be done with the STREAM lock
taken, otherwise it will be racy.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1452
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3320>
With non-serialized sticky events, such as GST_EVENT_INSTANT_RATE, we both want
to store the event (for later re-linking) *AND* push the event in a non-blocking
way.
We therefore must *not* propagate pending sticky events if the event is "sticky
or serialized" but only if it's "serialized"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3254>
