En el contexto de las conferencias de WebRTC, los flujos de medios virtuales son flujos de medios que genera una unidad de reenvío selectivo (SFU) para agregar y distribuir contenido multimedia de varios participantes. A diferencia de las transmisiones de medios punto a punto directas, que crearían una malla compleja de conexiones en conferencias grandes, las transmisiones de medios virtuales simplifican la topología. La SFU recibe transmisiones de medios 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 medios virtuales salientes.
Este enfoque reduce la cantidad de transmisiones entrantes simultáneas que cada participante debe controlar, lo que disminuye 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 según 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 cada uno de los demás participantes. Esta abstracción que proporcionan los flujos de medios 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 medios de audio, lo que crea tres transceptores de audio locales. Para recibir video, el cliente debe ofrecer de una a tres descripciones de medios de video, lo que establece esa cantidad de transceptores de video.
Receptores
Cada transceptor propiedad del cliente tiene un RtpReceiver y una "pista de medios" dedicados que reciben los flujos de RTP de audio de los servidores de Meet.
Cada pista tiene un ID único y recibe su propio flujo distinto de paquetes RTP de esa fuente de medios 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 un segmento específico.
Las sesiones de audio a través de la API de Meet Media usan tres transmisiones de medios distintas, cada una 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 medios virtuales. Son estáticos durante toda la sesión, pero la fuente de los paquetes puede cambiar para reflejar los feeds más relevantes. Los flujos de medios virtuales se comportan de la misma manera para el audio y el video.
La fuente de contribución (CSRC) en los encabezados de paquetes RTP identifica la fuente verdadera 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 se va.
Dado que la cantidad de SSRC es constante durante toda la sesión de la API de Meet Media, estos son los tres casos posibles:
Hay más participantes que SSRCs disponibles:
Meet transmite las tres personas más ruidosas a través de los tres SSRC. Dado que cada transmisión de RTP tiene su propio SSRC dedicado, no hay ninguna combinación entre las transmisiones.
Figura 1: Meet transmite las voces de las tres personas más ruidosas a través de los tres SSRCs. Si alguno de los flujos originales de la conferencia ya no es uno de los más altos, Meet cambia los paquetes RTP que componen el SSRC al más alto.
Figura 2. Meet cambia los paquetes RTP a la persona más ruidosa nueva. La cantidad de participantes activos es menor que la cantidad de tres SSRCs de audio:
En el caso de que haya más SSRCs disponibles que transmisiones en la conferencia, Meet asigna los paquetes de audio disponibles a su propio SSRC único. Los SSRC sin usar siguen listos y disponibles, pero no se transmiten paquetes RTP.
Figura 3: Los mapas de reuniones asignan paquetes de audio disponibles a su propio SSRC único. La cantidad de participantes activos es igual a los tres SSRCs de audio:
En el caso de que haya la misma cantidad de participantes y de SSRCs disponibles, el contenido multimedia de cada participante se asigna a un SSRC exclusivo. Estas asignaciones persisten mientras persista esta situación específica.
Figura 4: Meet asigna el contenido multimedia de cada participante a un SSRC dedicado.