This reverts commit 3cad3455377d5a22faa138d9df840257059776c8.
That commit was breaking the association between an audio and
a video track in the standard case.
In practice, to support carrying separate MediaStream, we are
going a way to map what MediaStreamTrack belong to what MediaStream,
but that will require some thinking about the API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2023>
From https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msid-16:
> Multiple media descriptions with the same value for msid-id and
> msid-appdata are not permitted.
Our previous implementation of simply using the CNAME as the msid
identifier and the name of the transceiver as the msid appdata was
misguided and incorrect, and created issues when bundling multiple
video streams together: the ontrack event was emitted with the same
streams for the two bundled medias, at least in Firefox.
Instead, use the transceiver name as the identifier, and expose
a msid-appdata property on transceivers to allow for further
customization by the application. When the property is not set,
msid-appdata can be left empty as it is specified as optional.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2003>
We bind transceivers' fec_percentage property to the FEC encoder
percentage property, and with the binding bidirectional a deadlock
was introduced by the latest changes from !1762:
We take hold of the transceiver's object lock, then add the binding
and set the property to its initial value on the encoder, which causes
set_property to deadlock in the transceiver when the binding kicks in.
Changing the binding type to DEFAULT (source to target) is enough
to address the deadlock and still serves the original intent.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1967>
We need to always add the RTX/RED/ULPFEC elements as rtpbin will only
call us once to request aux/fec senders/receivers.
We also need to regenerate the media section of the SDP instead of
blindly copying from the previous offer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1762>
* Add fec / red encoders as direct children of webrtcbin, instead
of providing them to rtpbin through the request-fec-encoder signal.
That is because they need to be placed before the rtpfunnel, which
is placed upstream of rtpbin.
* Update configuration of red decoders to set a list of RED payloads
on them, instead of setting the pt property.
That is because there may be one RED pt per media in the same session.
* Connect to request-fec-decoder-full instead of request-fec-decoder,
in order to instantiate FEC decoders according to the payload type
of the stream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1429>
When an extmap is defined twice for the same ID, firefox complains and
errors out (chrome is smart enough to accept strict duplicates).
To work around this, we deduplicate extmap attributes, and also error
out when a different extmap is defined for the same ID.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1383>
Upstream caps might for example be
application/x-rtp,media=audio,encoding-name={OPUS, X-GST-OPUS-DRAFT-SPITTKA-00, multiopus}
and while that is not fixed caps it is enough to match it with a media.
Only caps structures that have the correct structure name and that have
the media and encoding-name field are preserved, but if both are present
then these caps are used as "codec preferences".
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1291>
.. if a current direction has already been set
When `webrtcbin` has created an offer based on codec_preferences,
it might not have received caps on its sinkpads by the time a
remote description is set, in which case we want to connect the
input stream upon actual reception of the caps instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1233>
