Virtuelle Media-Streams sind im Kontext von WebRTC-Videokonferenzen 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 in großen Videokonferenzen ein komplexes Mesh 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.
Dadurch wird die Anzahl der gleichzeitigen eingehenden Streams reduziert, die jeder Teilnehmer verarbeiten muss, was die Anforderungen an Verarbeitung und Bandbreite senkt. 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 Videokonferenz, 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.
Damit der Client Audio empfangen kann, muss er genau drei Audio-Media-Beschreibungen anbieten, wodurch drei lokale Audio-Transceiver erstellt werden. Um Video zu empfangen, muss der Client ein bis drei Videomedienbeschreibungen anbieten, um die Anzahl der Video-Transceiver festzulegen.
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. Beispiel: Track A empfängt Audio von production-1, 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. Einmal festgelegt, ä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 zu berücksichtigen. 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. In Meet wird jedem Teilnehmer einer Videokonferenz beim Beitritt ein eigener CSRC zugewiesen. Dieser Wert bleibt konstant, bis sie die Besprechung verlassen.
Da die Anzahl der SSRC-Streams während der gesamten Meet Media API-Sitzung konstant ist, gibt es drei mögliche Szenarien:
Mehr Teilnehmer als verfügbare SSRCs:
Meet überträgt die drei lautesten Personen über die drei SSRC-Streams. 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 der SSRC besteht, zum lautesten Stream.
Abbildung 2. In Meet werden die RTP-Pakete an die neue lauteste Person weitergeleitet. Die 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 jedem Audio-Paket einen eigenen SSRC zu. Anzahl der aktiven Teilnehmer entspricht den drei Audio-SSRCs:
Bei einer gleichen Anzahl von Teilnehmern und verfügbaren SSRCs wird das Media jedes Teilnehmers einer dedizierten SSRC zugeordnet. Diese Zuordnungen bleiben bestehen, solange dieses bestimmte Szenario besteht.
Abbildung 4: In Meet werden die Medien jedes Teilnehmers einem dedizierten SSRC zugeordnet.