En el contexto de las conferencias de WebRTC, las transmisiones de contenido multimedia virtuales son transmisiones de contenido multimedia que genera una unidad de reenvío selectivo (SFU) para agregar y distribuir contenido multimedia de varios participantes. A diferencia de las transmisiones de contenido multimedia punto a punto directas, que crean una malla compleja de conexiones en conferencias grandes, las transmisiones de contenido multimedia virtuales simplifican la topología. La SFU recibe transmisiones de contenido multimedia individuales de cada participante y reenvía de forma selectiva las transmisiones activas o relevantes a otros participantes, multiplexándolas en un conjunto más pequeño y fijo de transmisiones de contenido multimedia virtual salientes.
Este enfoque reduce la cantidad de transmisiones entrantes simultáneas que cada participante debe controlar, lo que reduce los requisitos de procesamiento y ancho de banda. Cada transmisión virtual puede contener contenido multimedia de un participante a la vez, que la SFU ajusta de forma dinámica en función de factores como la actividad del orador o la asignación de video. Los participantes reciben estas transmisiones virtuales y ven una vista compuesta de la conferencia sin necesidad de administrar transmisiones individuales de todos los demás participantes. Esta abstracción que proporcionan las transmisiones de contenido multimedia virtuales es fundamental para escalar las conferencias de WebRTC a una gran cantidad de participantes.
Para recibir audio, el cliente debe ofrecer exactamente tres descripciones de contenido multimedia de audio, lo que crea tres transmisores-receptores de audio locales. Para recibir video, el cliente debe ofrecer de una a tres descripciones de contenido multimedia de video y establecer esa cantidad de transceptores de video.
Receptores
Cada transceptor que pertenece al cliente tiene un RtpReceiver y una "pista de contenido multimedia" dedicados que reciben las transmisiones de audio RTP de los servidores de Meet.
Cada pista tiene un ID único y recibe su propia transmisión distinta de paquetes RTP
de esa fuente de contenido multimedia específica. Por ejemplo, Pista A podría recibir audio de production-1 mientras que Pista B recibe audio de production-2.
SSRC
Cada paquete RTP tiene un valor de encabezado de fuente de sincronización (SSRC), que lo vincula a una pista específica.
Las sesiones de audio a través de la API de Meet Media usan tres flujos de contenido multimedia distintos, cada uno con su propio SSRC estático. Una vez establecidos, estos valores de SSRC nunca cambian durante la sesión.
Transmisiones virtuales
La API de Meet Media usa transmisiones de contenido multimedia virtual. Estos son estáticos durante la sesión, pero la fuente de los paquetes puede cambiar para reflejar los feeds más relevantes. Las transmisiones de contenido multimedia virtual se comportan de la misma manera para el audio y el video.
La fuente de contribución (CSRC) en los encabezados de los paquetes RTP identifica la fuente real de los paquetes RTP. Meet asigna a cada participante de una conferencia su propio CSRC único cuando se une. Este valor permanece constante hasta que el usuario sale.
Dado que la cantidad de SSRC es constante durante la sesión de la API de Media de Meet, estos son los tres casos posibles:
Hay más participantes que SSRC disponibles:
Meet transmite a las tres personas más ruidosas en los tres SSRC. Dado que cada flujo de RTP tiene su propio SSRC dedicado, no hay intermezcla entre los flujos.
Figura 1: Meet transmite a las tres personas más ruidosas en los tres SSRC. Si alguna de las transmisiones originales de la conferencia ya no es una de las más fuertes, Meet cambia los paquetes RTP que conforman el SSRC a la más fuerte.
Figura 2: Meet cambia los paquetes RTP a la nueva persona más alta. La cantidad de participantes activos es menor que los tres SSRC de audio:
En el caso de que haya más SSRC disponibles que transmisiones en la conferencia, Meet asigna cualquier paquete de audio disponible a su propio SSRC único. Los SSRC que no se usen seguirán listos y disponibles, pero no se transmitirán paquetes RTP.
Figura 3: Meet asigna los paquetes de audio disponibles a su propio SSRC único. La cantidad de participantes activos es igual a los tres SSRC de audio:
En el caso de participantes iguales y SSRC disponibles, el contenido multimedia de cada participante se asigna a un SSRC dedicado. Estas asignaciones persisten mientras persista esta situación específica.
Figura 4: Meet asigna el contenido multimedia de cada participante a un SSRC exclusivo.