Virtuelle Media-Streams sind im Zusammenhang mit WebRTC-Konferenzen Media-Streams, die von einer Selective Forwarding Unit (SFU) generiert werden, um Medien von mehreren Teilnehmern zusammenzufassen und zu verteilen. Im Gegensatz zu direkten Peer-to-Peer-Media-Streams, die in großen Konferenzen ein komplexes Mesh aus Verbindungen erzeugen würden, vereinfachen virtuelle Media-Streams die Topologie. Die SFU empfängt einzelne Media-Streams von jedem Teilnehmer und leitet die aktiven oder relevanten Streams selektiv an andere Teilnehmer weiter. Dabei werden sie auf eine kleinere, feste Anzahl ausgehender virtueller Media-Streams gemultiplext.
Dieser Ansatz reduziert die Anzahl der gleichzeitigen eingehenden Streams, die jeder Teilnehmer verarbeiten muss, und senkt so die Anforderungen an Verarbeitung und Bandbreite. Jeder virtuelle Stream kann jeweils Medien von einem Teilnehmer enthalten. Diese werden von der SFU dynamisch an Faktoren wie die Aktivität des Sprechers oder die Videozuweisung angepasst. Die Teilnehmer empfangen diese virtuellen Streams und sehen so eine zusammengesetzte Ansicht der Konferenz, ohne einzelne Streams von allen anderen Teilnehmern verwalten zu müssen. Diese Abstraktion durch virtuelle Media-Streams ist entscheidend, um WebRTC-Konferenzen auf eine große Anzahl von Teilnehmern zu skalieren.
Um Audio zu empfangen, muss der Client genau drei Audio-Media-Beschreibungen anbieten, wodurch drei lokale Audio- Transceivererstellt werden. Um Video zu empfangen, muss der Client ein bis drei Video-Media-Beschreibungen anbieten, wodurch die entsprechende Anzahl von Video-Transceivern eingerichtet wird.
Receiver
Jeder Client-eigene Transceiver hat einen dedizierten
RtpReceiver und einen dedizierten
„Media-Track“, der die Audio-RTP-Streams von Meet
Servern empfängt.
Jeder Track hat eine eindeutige ID und empfängt einen eigenen Stream von RTP-Paketen aus dieser bestimmten Media-Quelle. So kann Track A beispielsweise Audio von production-1 empfangen, während Track B Audio von production-2 empfängt.
SSRCs
Jedes RTP-Paket hat einen Synchronization Source (SSRC)-Header-Wert, der es mit einem bestimmten Track verknüpft.
Audiositzungen über die Meet Media API verwenden drei verschiedene Media-Streams, die jeweils eine eigene statische SSRC haben. Sobald diese SSRC-Werte festgelegt sind, ändern sie sich für die Dauer der Sitzung nicht mehr.
Virtuelle Streams
Die Meet Media API verwendet virtuelle Media-Streams. Diese sind während der gesamten Sitzung statisch, aber die Quelle der Pakete kann sich ändern, um die relevantesten Feeds widerzuspiegeln. Virtuelle Media-Streams verhalten sich für Audio und Video gleich.
Die Contributing Source (CSRC) in den RTP-Paket headern gibt die tatsächliche Quelle der RTP-Pakete an. Meet weist jedem Teilnehmer einer Konferenz beim Beitritt eine eigene eindeutige CSRC zu. Dieser Wert bleibt konstant, bis der Teilnehmer die Konferenz verlässt.
Da die Anzahl der SSRCs während der gesamten Meet Media API-Sitzung konstant ist, gibt es die folgenden drei möglichen Szenarien:
Mehr Teilnehmer als verfügbare SSRCs:
Meet überträgt die drei lautesten Teilnehmer über die drei SSRCs. Da jeder RTP-Stream eine eigene dedizierte SSRC hat, gibt es keine Vermischung zwischen den Streams.
Abbildung 1. Meet überträgt die drei lautesten Teilnehmer über die drei SSRCs. Wenn einer der ursprünglichen Streams in der Konferenz nicht mehr zu den lautesten Streams gehört, ändert Meet die RTP-Pakete, aus denen die SSRC besteht, in die des lautesten Streams.
Abbildung 2. Meet ändert die RTP-Pakete in die des neuen lautesten Teilnehmers. Die Anzahl der aktiven Teilnehmer ist geringer als die Anzahl der drei Audio-SSRCs:
In diesem Szenario sind mehr SSRCs verfügbar als Streams in der Konferenz. Meet ordnet alle verfügbaren Audiopakete einer eigenen eindeutigen SSRC zu. Alle nicht verwendeten SSRCs sind weiterhin verfügbar, aber es werden keine RTP-Pakete übertragen.
Abbildung 3. Meet ordnet verfügbare Audiopakete einer eigenen eindeutigen SSRC zu. Die Anzahl der aktiven Teilnehmer entspricht der Anzahl der drei Audio-SSRCs:
In diesem Szenario wird das Media jedes Teilnehmers einer dedizierten SSRC zugeordnet. Diese Zuordnungen bleiben bestehen, solange dieses Szenario andauert.
Abbildung 4 Meet ordnet das Media jedes Teilnehmers einer dedizierten SSRC zu.