В контексте WebRTC-конференций виртуальные медиапотоки представляют собой медиапотоки, генерируемые селективным пересылочным устройством (SFU) для агрегации и распределения медиаконтента от нескольких участников. В отличие от прямых одноранговых медиапотоков, которые создают сложную сеть соединений в крупных конференциях, виртуальные медиапотоки упрощают топологию. SFU принимает отдельные медиапотоки от каждого участника и выборочно пересылает активные или релевантные потоки другим участникам, мультиплексируя их в меньший фиксированный набор исходящих виртуальных медиапотоков.
Такой подход сокращает количество одновременных входящих потоков, которые должен обрабатывать каждый участник, снижая требования к обработке и пропускной способности. Каждый виртуальный поток может содержать медиаконтент от одного участника одновременно, динамически корректируемый SFU в зависимости от таких факторов, как активность докладчика или распределение видео. Участники получают эти виртуальные потоки, фактически видя целостное представление конференции без необходимости управления отдельными потоками от каждого участника. Эта абстракция, обеспечиваемая виртуальными медиапотоками, критически важна для масштабирования WebRTC-конференций до большого количества участников.
Для получения аудиоклиента клиент должен предоставить ровно три описания аудионосителей, создав три локальных аудиоприёмопередатчика . Для получения видеоклиента клиент должен предоставить от одного до трёх описаний видеоносителей, создав соответствующее количество видеоприёмопередатчиков.
Приемники
Каждый клиентский приемопередатчик имеет выделенный RtpReceiver и выделенную «медиадорожку», которая получает аудиопотоки RTP с серверов Meet.
Каждая дорожка имеет уникальный идентификатор и получает свой собственный поток RTP-пакетов из конкретного источника медиа. Например, дорожка A может получать аудио с production-1 , а дорожка B — с production-2 .
SSRC
Каждый пакет RTP имеет значение заголовка источника синхронизации (SSRC) , привязывающее его к определенному треку.
Аудиосеансы через API Meet Media используют три отдельных медиапотока, каждый из которых имеет свой статический код SSRC. После установки эти значения SSRC не меняются в течение всего сеанса.
Виртуальные потоки
API Meet Media использует виртуальные медиапотоки . Они статичны на протяжении всего сеанса, но источник пакетов может меняться в зависимости от наиболее важных каналов. Виртуальные медиапотоки работают одинаково для аудио и видео.
Участвующий источник (CSRC) в заголовках RTP-пакетов определяет истинный источник RTP-пакетов. Meet назначает каждому участнику конференции свой уникальный CSRC при подключении. Это значение остаётся неизменным до тех пор, пока участник не покинет конференцию.
Поскольку количество SSRC постоянно на протяжении всего сеанса API Meet Media, вот три возможных сценария:
Больше участников, чем доступно SSRC :
Meet транслирует трёх самых громких участников по трём каналам SSRC. Поскольку каждый RTP-поток идёт по отдельному выделенному каналу SSRC, микширование потоков не происходит.
Рисунок 1. Meet передает голоса трех самых громких людей по трем SSRC. Если какой-либо из исходных потоков в конференции больше не является одним из самых громких, Meet переключает пакеты RTP, составляющие SSRC, на самый громкий.
Рисунок 2. Meet переключает RTP-пакеты на нового самого громкого человека. Количество активных участников меньше трех аудио SSRC :
В случае, если число доступных SSRC превышает число потоков в конференции, Meet сопоставляет все доступные аудиопакеты со своим уникальным SSRC. Неиспользованные SSRC остаются доступными, но RTP-пакеты не передаются.
Рисунок 3. Meet сопоставляет доступные аудиопакеты со своим собственным уникальным SSRC. Количество активных участников равно трем аудио SSRC :
В сценарии с равными участниками и доступными SSRC медиа-данные каждого участника сопоставлены с выделенным SSRC. Эти сопоставления сохраняются до тех пор, пока сохраняется данный сценарий.
Рисунок 4. Meet сопоставляет медиафайлы каждого участника с выделенным SSRC.