Виртуальные медиапотоки в контексте конференций WebRTC — это медиапотоки, генерируемые блоком выборочной пересылки (SFU) для агрегирования и распределения мультимедиа от нескольких участников. В отличие от прямых одноранговых медиапотоков, которые создают сложную сеть соединений в крупных конференциях, виртуальные медиапотоки упрощают топологию. SFU получает отдельные медиапотоки от каждого участника и выборочно пересылает активные или соответствующие потоки другим участникам, мультиплексируя их в меньший фиксированный набор исходящих виртуальных медиапотоков.
Такой подход уменьшает количество одновременных входящих потоков, которые должен обрабатывать каждый участник, снижая требования к обработке и пропускной способности. Каждый виртуальный поток может одновременно содержать медиафайлы от одного участника, динамически корректируемые SFU на основе таких факторов, как активность говорящего или назначение видео. Участники получают эти виртуальные потоки, эффективно просматривая комплексное представление конференции без необходимости управлять отдельными потоками каждого другого участника. Эта абстракция, обеспечиваемая виртуальными медиапотоками, имеет решающее значение для масштабирования конференций WebRTC для большого числа участников.
Для получения звука клиент должен предложить ровно три описания аудионосителей, создав три локальных аудиотрансивера . Для получения видео клиент должен предложить от одного до трех описаний видеоносителей, устанавливая это количество видеопередатчиков.
Ресиверы
Каждый клиентский трансивер имеет выделенный RtpReceiver и выделенную «медиа-дорожку», которая получает аудиопотоки RTP с серверов Meet.
Каждая дорожка имеет уникальный идентификатор и получает свой собственный поток пакетов RTP от конкретного источника мультимедиа. Например, дорожка A может получать звук от production-1 , а дорожка Б — от production-2 .
SSRC
Каждый пакет RTP имеет значение заголовка источника синхронизации (SSRC) , привязывающее его к определенной дорожке.
Аудиосеансы через Meet Media API используют три отдельных медиапотока, каждый из которых имеет собственный статический 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.
Связанные темы
,Виртуальные медиапотоки в контексте конференций WebRTC — это медиапотоки, генерируемые блоком выборочной пересылки (SFU) для агрегирования и распределения мультимедиа от нескольких участников. В отличие от прямых одноранговых медиапотоков, которые создают сложную сеть соединений в крупных конференциях, виртуальные медиапотоки упрощают топологию. SFU получает отдельные медиапотоки от каждого участника и выборочно пересылает активные или соответствующие потоки другим участникам, мультиплексируя их в меньший фиксированный набор исходящих виртуальных медиапотоков.
Такой подход уменьшает количество одновременных входящих потоков, которые должен обрабатывать каждый участник, снижая требования к обработке и пропускной способности. Каждый виртуальный поток может одновременно содержать медиафайлы от одного участника, динамически корректируемые SFU на основе таких факторов, как активность говорящего или назначение видео. Участники получают эти виртуальные потоки, эффективно просматривая комплексное представление конференции без необходимости управлять отдельными потоками каждого другого участника. Эта абстракция, обеспечиваемая виртуальными медиапотоками, имеет решающее значение для масштабирования конференций WebRTC для большого числа участников.
Для получения звука клиент должен предложить ровно три описания аудионосителей, создав три локальных аудиотрансивера . Для получения видео клиент должен предложить от одного до трех описаний видеоносителей, устанавливая это количество видеопередатчиков.
Ресиверы
Каждый клиентский трансивер имеет выделенный RtpReceiver и выделенную «медиа-дорожку», которая получает аудиопотоки RTP с серверов Meet.
Каждая дорожка имеет уникальный идентификатор и получает свой собственный поток пакетов RTP от конкретного источника мультимедиа. Например, дорожка A может получать звук из production-1 , а дорожка Б — из production-2 .
SSRC
Каждый пакет RTP имеет значение заголовка источника синхронизации (SSRC) , привязывающее его к определенной дорожке.
Аудиосеансы через Meet Media API используют три отдельных медиапотока, каждый из которых имеет собственный статический 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.