Add latency configuration logic to transportsendbin to
isolate it from the overall pipeline latency. That means that
it configures minimum latency internally based on the
latency query, and sends a latency event upstream that
matches.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1209
Otherwise it can happen that e.g. the stream-start event is tried to be
sent as part of pushing the first buffer. Downstream might not be in
PAUSED/PLAYING yet, so the event is rejected with GST_FLOW_FLUSHING and
because it's an event would not cause the blocking pad probe to trigger
first. This would then return GST_FLOW_FLUSHING for the buffer and shut
down all of upstream.
To solve this we return GST_PAD_PROBE_DROP for all events. In case of
sticky events they would be resent again later once we unblocked after
blocking on the buffer and everything works fine.
Don't handle events specifically in sink pad blocking pad probes as here
downstream is not linked yet and we are actually waiting for the
following CAPS event before unblocking can happen.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/1172
Refactor transportsendbin, and change the way
pads are blocked on dtlssrtpenc so that they
don't interfere with state changes.
As well as being easier to read, this fixes
spurious failures shutting down webrtcbin
if DTLS negotiation hasn't completed yet.
Move the errant piece of dtlssrtpenc state change
management from dtlstransport in the Webrtc libs,
into the transportsendbin that does the rest of
the element management so it's all in one place.
Move freeing of the pad blocks back to before we call the
GstBin state change function, as there's something racy
going on on the build server otherwise, where the pads don't
unblock during downward state changes.
This is a bit of a stab in the dark, since I can't recreate
the build server failure locally.
Release references in pad blocks and release the memory in the
dispose function too, in case the state change doesn't get
run (because calling the parent state change fails).
When changing state downward, we can't set pads
to inactive if they are blocked, it will deadlock
trying to acquire the streaming lock.
Just calling the parent state change function
will do the correct things to unblock probes and
set the pad inactive, so let it do that and
remove the probes after the parent state change
function has run
https://bugzilla.gnome.org/show_bug.cgi?id=796682
SDP's are generated and consumed according to the W3C PeerConnection API
available from https://www.w3.org/TR/webrtc/
The SDP is either created initially from the connected
sink pads/attached transceivers as in the case of generating an offer or
intersected with the connected sink pads/attached transceivers as in
the case for creating an answer. In both cases, the rtp payloaded streams
sent by the peer are exposed as separate src pads.
The implementation supports trickle ICE, RTCP muxing, reduced size RTCP.
With contributions from:
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
Edward Hervey <edward@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792523
