In this change we now protect the internal srcpads list using the
stream lock and limit usage of the internal stream lock to
preventing data flowing on the other src pad type while creating
and signalling the new pad.
This fixes a deadlock with RTPBin shutdown lock. These two locks would
end up being taken in two different order, which caused a deadlock. More
generally, we should not rely on a streamlock when handling out-of-band
data, so as a side effect, we should not take a stream lock when
iterating internal links.
This is an extra internal recurisve lock use to avoid having to take
both sink pad streams lock all the time. This patch renamed it
INTERLNAL_STREAM_LOCK/UNLOCK() to avoid confusion with possible upstream
GST_PAD API.
This reverts "6f3734c305 rtpssrcdemux: Only forward stick events while
holding the sinkpad stream lock" and actually hold on the internal
stream lock. This prevents in some needed case having a second
streaming thread poping in and messing up event ordering.
While forwarding serialized event, we use gst_pad_forward() function.
In the forward callback (GstPadForwardFunction) we always return
TRUE. Returning true there will stop the dispatching procedure. As a
side effect, only one events is receiving the events. This breaks
when sending EOS from the applicaiton, it also breaks the latency
tracer.
According to RFC 5506, reduce size packages can be sent, this
packages may not be compound, so we need to add support for
getting ssrc from other types of packages.
https://bugzilla.gnome.org/show_bug.cgi?id=750327
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Otherwise we get a race where if the RTCP packet comes in first and while
it is added the pads, the segment event arrives on the RTP stream, the event
may be lost completely and never forwarded.
Block the RTP pad and associated RTCP pads while they are being
announced. This it to prevent a race where one is announced and
before the callback has connected it, the other one gets a buffer.
We can't use the "padlock" of ssrcdemux because it causes deadlocks.
This prevents a deadlock where something would try to push an event
through the SSRC demux from the callback, causing the pads to be iterated
and the lock taken.
We need to keep the lock held because we don't want a push before the "new-ssrc-pad"
handler has completed. But we may want to push an event from inside that handler, hence
the recursive mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=650916
* use G_DEFINE_TYPE
* adjust to new GstBuffer and corresponding rtp and rtcp buffer interfaces
* misc caps and segment handling changes
FIXME: also relies on being able to pass caps along with a buffer,
which has no evident equivalent yet, so that either needs one,
or still needs quite some code path modification to drag along caps.
