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>
