Virtuelle Media-Streams im Kontext von WebRTC-Videokonferenzen sind Media-Streams, die von einer Selective Forwarding Unit (SFU) generiert werden, um Media von mehreren Teilnehmern zusammenzufassen und zu verteilen. Im Gegensatz zu direkten Peer-to-Peer-Media-Streams, die bei großen Videokonferenzen ein komplexes Netz von 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 in einem kleineren, festen Satz 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, die von der SFU dynamisch an Faktoren wie Sprecheraktivität oder Videozuweisung angepasst werden. Die Teilnehmer erhalten diese virtuellen Streams und sehen so eine zusammengesetzte Ansicht der Konferenz, ohne einzelne Streams von jedem anderen Teilnehmer 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-Transceiver erstellt werden. Um Video zu empfangen, muss der Client ein bis drei Videomediabeschreibungen anbieten, die die Anzahl der Video-Transceiver festlegen.
Receiver
Jeder vom Kunden bereitgestellte 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 erhält einen eigenen Stream von RTP-Paketen von der jeweiligen Media-Quelle. Track A kann 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)-Headerwert, der es mit einem bestimmten Track verknüpft.
Für Audiositzungen über die Meet Media API werden drei separate Media-Streams verwendet, die jeweils eine eigene statische SSRC haben. Sobald sie festgelegt sind, ändern sich diese SSRC-Werte während der gesamten Sitzung nicht mehr.
Virtuelle Streams
Die Meet Media API verwendet virtuelle Media-Streams. Diese sind während der gesamten Sitzung statisch, die Quelle der Pakete kann sich jedoch ändern, um die relevantesten Feeds widerzuspiegeln. Virtuelle Media-Streams verhalten sich für Audio und Video gleich.
Die Contributing Source (CSRC) in den RTP-Paketheadern gibt die tatsächliche Quelle der RTP-Pakete an. Meet weist jedem Teilnehmer in einer Videokonferenz beim Beitreten einen eigenen eindeutigen CSRC zu. Dieser Wert bleibt konstant, bis sie die Sitzung beenden.
Da die Anzahl der SSRCs während der gesamten Meet Media API-Sitzung konstant ist, gibt es drei mögliche Szenarien:
Mehr Teilnehmer als verfügbare SSRCs:
In Meet werden die drei lautesten Personen über die drei SSRC-Streams übertragen. Da jeder RTP-Stream einen eigenen dedizierten SSRC hat, gibt es keine Vermischung zwischen den Streams.
Abbildung 1. Meet überträgt die drei lautesten Personen über die drei SSRCs. Wenn einer der ursprünglichen Streams in der Videokonferenz nicht mehr einer der lautesten Streams ist, wechselt Meet die RTP-Pakete, aus denen die SSRC besteht, zum lautesten Stream.
Abbildung 2. Meet leitet die RTP-Pakete an die neue lauteste Person weiter. Anzahl der aktiven Teilnehmer ist geringer als die drei Audio-SSRCs:
Wenn mehr SSRCs verfügbar sind als Streams in der Videokonferenz, ordnet Meet alle verfügbaren Audiopakete einer eigenen eindeutigen SSRC zu. Nicht verwendete SSRCs sind weiterhin verfügbar, aber es werden keine RTP-Pakete übertragen.
Abbildung 3: Meet ordnet verfügbare Audiopakete dem jeweiligen SSRC zu. Anzahl der aktiven Teilnehmer entspricht den drei Audio-SSRCs:
Bei einer gleichen Anzahl von Teilnehmern und verfügbaren SSRCs werden die Medien jedes Teilnehmers einer dedizierten SSRC zugeordnet. Diese Zuordnungen bleiben so lange bestehen, wie dieses spezielle Szenario.
Abbildung 4: In Meet werden die Medien jedes Teilnehmers einem dedizierten SSRC zugeordnet.