Virtuelle Medienstreams sind im Kontext von WebRTC-Konferenzen Medienstreams, die von einer Selective Forwarding Unit (SFU) generiert werden, um Medien von mehreren Teilnehmern zu aggregieren und zu verteilen. Im Gegensatz zu direkten Peer-to-Peer-Medienstreams, die bei großen Konferenzen ein komplexes Netzwerk von Verbindungen schaffen würden, vereinfachen virtuelle Medienstreams die Topologie. Die SFU empfängt von jedem Teilnehmer individuelle Medienstreams und leitet die aktiven oder relevanten Streams selektiv an andere Teilnehmer weiter. Dabei werden sie auf eine kleinere, feste Anzahl von ausgehenden virtuellen Medienstreams multiplext.
Dadurch wird die Anzahl der gleichzeitigen eingehenden Streams reduziert, die jeder Teilnehmer verarbeiten muss. So werden die Verarbeitungsanforderungen und die Bandbreitenanforderungen gesenkt. Jeder virtuelle Stream kann Medien von jeweils einem Teilnehmer enthalten, die von der SFU dynamisch anhand von Faktoren wie der Sprecheraktivität oder der Videozuweisung angepasst werden. Die Teilnehmer erhalten 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 Medienstreams ist entscheidend für die Skalierung von WebRTC-Konferenzen auf eine große Anzahl von Teilnehmern.
Um Audio zu empfangen, muss der Client genau drei Audiomedienbeschreibungen anbieten, wodurch drei lokale Audio-Transceiver erstellt werden. Um Video zu empfangen, muss der Client eine bis drei Videomedienbeschreibungen anbieten, um die Anzahl der Videotransceiver festzulegen.
Receiver
Jeder clienteigene Transceiver hat eine eigene RtpReceiver und einen eigenen „Media-Track“, über den die Audio-RTP-Streams von Meet-Servern empfangen werden.
Jeder Track hat eine eindeutige ID und empfängt einen eigenen Stream von RTP-Paketen von der jeweiligen Medienquelle. 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 Headerwert für die Synchronisationsquelle (SSRC), der es mit einem bestimmten Track verknüpft.
Für Audiositzungen über die Meet Media API werden drei separate Medienstreams verwendet, die jeweils eine eigene statische SSRC haben. Diese SSRC-Werte ändern sich nach der Einrichtung nicht mehr während der gesamten Sitzung.
Virtuelle Streams
Die Meet Media API verwendet virtuelle Medienstreams. Sie bleiben während der gesamten Sitzung statisch, die Quelle der Pakete kann sich jedoch ändern, um die relevantesten Feeds widerzuspiegeln. Virtuelle Medienstreams verhalten sich für Audio und Video gleich.
Die Contributing Source (CSRC) in den RTP-Paketheadern gibt die wahre Quelle der RTP-Pakete an. Meet weist jedem Teilnehmer einer Konferenz bei der Teilnahme eine eindeutige CSRC zu. Dieser Wert bleibt konstant, bis der Nutzer die Website verlässt.
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:
Meet überträgt die drei lautesten Personen über die drei SSRCs. Da jeder RTP-Stream einen eigenen SSRC hat, kommt es nicht zu einer Vermischung der Streams.
Abbildung 1. Meet überträgt die drei lautesten Personen über die drei SSRCs. Wenn einer der ursprünglichen Streams in der Konferenz nicht mehr zu den lautesten Streams gehört, wechselt Meet die RTP-Pakete, aus denen der SSRC besteht, zu dem lautesten Stream.
Abbildung 2. Meet schaltet die RTP-Pakete auf die Person um, die gerade am lautesten spricht. Die Anzahl der aktiven Teilnehmer ist kleiner als die Anzahl der drei Audio-SSRCs:
Wenn mehr SSRCs verfügbar sind als Streams in der Konferenz, ordnet Meet allen verfügbaren Audiopaketen eine eigene eindeutige SSRC zu. Alle nicht verwendeten SSRCs sind weiterhin bereit und verfügbar, es werden jedoch keine RTP-Pakete übertragen.
Abbildung 3: Meet ordnet verfügbaren Audiopaketen eine eigene eindeutige SSRC zu. Die Anzahl der aktiven Teilnehmer entspricht den drei Audio-SSRCs:
Wenn die Anzahl der Teilnehmer gleich ist und genügend SSRCs verfügbar sind, werden die Medien jedes Teilnehmers einem bestimmten SSRC zugeordnet. Diese Zuordnungen bleiben so lange bestehen, wie dieses spezifische Szenario besteht.
Abbildung 4: Meet ordnet die Medien jedes Teilnehmers einem bestimmten SSRC zu.