The function _get_stats_from_ice_transport returns a string which must be
freed by the caller. However, _get_stats_from_dtls_transport was ignoring
the return value from this function, resulting in a leak.
Ran this with valgrind. Before this fix there was a leak of 40 bytes each
time this was called. After there was no leak.
When negotiating a data channel, Chrome as recent as 75 still uses SDP
based on version 05 of the SCTP SDP draft, for example:
m=application 9 DTLS/SCTP 5000
a=sctpmap:5000 webrtc-datachannel 1024
Implement support for parsing SCTP port out of SDP message with sctpmap
attribute. Fixes data channel negotiation with Chrome browser.
There's no reason for it to inherit from GstObject apart from
locking, which is easily replaced, and inheriting from
GInitiallyUnowned made introspection awkward and needlessly
complicated.
Regression introduced by b4bdcf15b7
This commit prevents the handshake from reaching dtlsdec when
the receive state of the receive bin is set to DROP (for example
when transceivers are sendonly).
This preserves the intent of the commit, by blocking the bin
at its sinks until the receive state is no longer BLOCK, but
makes sure the handshake still goes through, by only dropping
data at the src pads, as was the case before.
1. The spec indicates that the notification should occur near the end of
'setting the description' processing
2. The current location with the drop of the lock could cause the 'check
if negotiation is needed' logic to execute and become confused about
the state of the webrtcbin's current local descriptions.
In the bad case, the following assertions could be hit:
g_assert (trans->mline < gst_sdp_message_medias_len (webrtc->current_local_description->sdp));
g_assert (trans->mline < gst_sdp_message_medias_len (webrtc->current_remote_description->sdp));
Moving the signalling state change later in the set description task
means that checking for a renegotiation will early abort as the
signalling state is not STABLE before the session description and
transceivers have been updated.
If both data channels become ready simultaneously, then the two integer
read-add-update cycles can execute concurrently and only ever increment
once instead of the required twice. Use an atomic add instead.
It is very possible for badly behaving signalling or peers to send
us ICE candidates before we receive an SDP. While we had consideration
for that on the first set SDP, subsequent SDP's could result in
misconfigured ICE transports. Expand the previous code to also take
into account reconfigurations.
Limitations:
- No transport changes at all (ICE, DTLS)
- Codec changes are untested and probably don't work
- Stream removal doesn't remove transports (i.e. non-bundled transports
will stay around until webrtcbin is shutdown)
- Unified Plan SDP only. No Plan-B support.
Some GIR annotations were incorrect or even missing. The former isn't
good for bindings, while the latter is especially annoying for signal
handlers, as that means your arguments will get the wrong names in the
rendered documentation.
Since the addition of BUNDLE support, the pads and the transceivers
share a single transport stream. When getting stats from the stream,
filter by the ssrc of the current pad to avoid merging the stats for
different pads.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/889
If bundle was used in combination with rtx, only the bundled transport
stream would have correctly configured rtx parameters.
Iterate over the payloads upfront in the bundled case to ensure the
correct payload mapping is set for the RTX elements.
This is the equivalent of iceTransportPolicy in the RTCConfiguration
dictionary.
Only two values are implemented:
* all: default behaviour
* relay: only gather relay candidates
The third member of the iceTransportPolicy enum, "public", is
obsolete.
Currently master code of gst1-plugins-bad use plain-string host name while passing it to
libnice agent: nice_agent_set_relay_info() in gstwebrtcice.c while adding turn_server(_add_turn_server).
It is observered that if we don't convert the host parameter by using gst_uri_get_host, it fails in libnice agent(0.1.14-1).
Code does, actually, set the host correctly but while passing params to nice_agent_set_relay_info, it uses incorrect one.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/823
With prenegotiated channels, the data-channel protocol is not used and
instead the channel's negotiation is intended to be performed out of band in
some application-specific manner.
Comes with test!
This means that we will reject all operations before we've transitioned
into READY.
This also fixes the tests using the default GMainContext in the NULL
state instead of the webrtcbin internal GMainContext and thread. Also
removes a potential ordering race where on the element transitioning to
READY, an operations could have been queued on two different threads and
removing a guarentee on operation ordering.
It might be possible that if we set webrtcbin to the NULL state some
tasks (idle sources) are still executed and they might even freeze. The freeze
is caused because the webrtcbin tasks don't hold a reference to webrtcbin and
if it's last unref inside the idle source itself this will not allow the main
loop to finish because the main loop is waiting on the idle source to finish.
We now start and stop webrtcbin thread when changing states. This will allow
the idle sources to finish properly.
https://bugzilla.gnome.org/show_bug.cgi?id=797251
It is possible and often desirable to pass multiple ICE relays
to libnice agents, the "turn-server" property, while convenient
to use from the command line, does not allow that.
This adds a new action signal, "add-turn-server" to address that.
https://bugzilla.gnome.org/show_bug.cgi?id=797012
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.
When negotiation is triggered by receiving caps on our sink pad
probes, we could encounter a race condition where need-negotiation
is emitted and the application requires the creation of an offer
before the current caps were actually updated.
This led to retrieving incomplete caps when creating the offer,
using find_codec_preferences -> pad_get_current_caps.
Instead, as we save the caps in the probe callback anyway, it is better
and thread safe to use these if they were set.
https://bugzilla.gnome.org/show_bug.cgi?id=796801
Fixes random crashes when an allocated webrtcbin isn't
given fresh 0-filled memory in its allocation. It works
mostly because GMutex and GCond are automatically initialised
in that case.
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
This lets users call gst_pad_get_current_caps on newly-added
pads to easily determine what to plug them into.
We cannot copy sticky events unconditionally in core,
see #719437https://bugzilla.gnome.org/show_bug.cgi?id=796387
Fixes ffeb09e4ab
if (sscanf(...)) { // != 0
error;
}
Is not correct where != 0 indicates some kind of success.
Check instead that the correct number of elements were slurped.
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
