En el contexto de las conferencias de WebRTC, las transmisiones de contenido multimedia virtuales son transmisiones de contenido multimedia generadas por una unidad de reenvío selectivo (SFU) para agregar y distribuir contenido multimedia de varios participantes. A diferencia de las transmisiones de contenido multimedia directas de par a par, que crearían 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 pertinentes a otros participantes, multiplexándolas en un conjunto más pequeño y fijo de transmisiones de contenido multimedia 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, lo que les permite ver 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 transceptores de audio locales . Para recibir video, el cliente debe ofrecer de una a tres descripciones de contenido multimedia de video, lo que establece esa cantidad de transceptores de video.
Receptores
Cada transceptor propiedad del cliente tiene un
RtpReceiver dedicado y una
"pista de contenido multimedia" dedicada que recibe las transmisiones RTP de audio 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, Track A podría recibir audio de production-1, mientras que Track B recibe audio de production-2.
SSRCs
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 transmisiones de contenido multimedia distintas, cada una con su propio SSRC estático. Una vez establecidos, estos valores de SSRC nunca cambian durante la vida útil de la sesión.
Transmisiones virtuales
La API de Meet Media usa transmisiones de contenido multimedia virtuales. Estas son estáticas durante toda la sesión, pero la fuente de los paquetes puede cambiar para reflejar los feeds más pertinentes. Las transmisiones de contenido multimedia virtuales se comportan de la misma manera para el audio y el video.
La fuente contribuyente (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, estas son las tres situaciones posibles:
Más participantes que SSRC disponibles:
Meet transmite a las tres personas más ruidosas a través de los tres SSRC. Dado que cada transmisión RTP está en su propio SSRC dedicado, no hay mezcla entre las transmisiones.
Figura 1. Meet transmite a las tres personas más ruidosas a través de los tres SSRC. Si alguna de las transmisiones originales de la conferencia ya no es una de las más ruidosas, Meet cambia los paquetes RTP que componen el SSRC a la más ruidosa.
Figura 2: Meet cambia los paquetes RTP a la nueva persona más ruidosa. La cantidad de participantes activos es menor que los tres SSRC de audio:
En el caso en 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 no utilizados aún están listos y disponibles, pero no se transmiten 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 que haya la misma cantidad de participantes 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 dedicado.