Обзор API Meet Media

API Google Meet Media позволяет получать доступ к медиаконтенту в режиме реального времени из конференций Google Meet. Это открывает множество вариантов использования, например, в приложениях для документирования действий, предоставления аналитики в режиме реального времени о текущей встрече или потоковой передачи аудио и видео на новую платформу.

Варианты использования

Приложения, зарегистрированные в консоли Google Cloud, могут использовать API Meet Media для подключения к конференциям Meet, что позволяет им:

• Просмотр видеопотоков . Например:
  • Передавайте видеопотоки, созданные в конференциях Meet, в ваши собственные модели ИИ.
  • Фильтруйте потоки для индивидуальных записей.
• Прослушивание аудиопотоков . Например:
  • Передавайте аудио напрямую в Gemini и создайте своего собственного чат-бота на основе искусственного интеллекта для проведения совещаний.
  • Передавайте аудиопотоки, созданные в конференциях Meet, в свой собственный сервис транскрибации
  • Создавайте субтитры на разных языках.
  • Создавайте сгенерированные моделью потоки языка жестов из записанного звука.
  • Создавайте собственные модели шумоподавления, чтобы удалять фоновые и шумовые артефакты из конференции.
• Использовать метаданные участников . Например:
  • Определите, кто из участников находится на конференции, что позволит получить более точную информацию и аналитику.

Жизненный цикл API Meet Media

На следующих изображениях показан жизненный цикл API Meet Media:

Требования к согласию

Приложения API Meet Media допускаются к участию в совещании только в том случае, если в звонке участвует лицо, имеющее право давать согласие от имени совещания.

Для встреч Google Workspace

Чтобы предоставить согласие на собраниях Google Workspace, вы должны быть в организации, которой принадлежит собрание. В большинстве случаев владелец собрания совпадает с организатором. Если организатор или инициатор участвует в собрании и принадлежит организации, которой принадлежит собрание, диалоговое окно начала будет показано им в первую очередь.

Для встреч с потребителями

Для встреч, организованных с помощью учетных записей Gmail, инициатор должен присутствовать на встрече, чтобы дать согласие.

Общие термины

Номер облачного проекта

Неизменяемый идентификатор int64 , генерируемый для проекта Google Cloud. Эти значения генерируются консолью Google Cloud для каждого зарегистрированного приложения.

Конференция

Сгенерированный сервером экземпляр вызова в конференц-зале . Пользователи обычно рассматривают этот сценарий как отдельную конференцию.

Канал данных о ресурсах конференции

Вместо того чтобы запрашивать ресурсы по протоколу HTTP, как в случае с API REST Google Meet , клиенты API Meet Media запрашивают ресурсы у сервера по каналам данных.

Для каждого типа ресурса может быть открыт выделенный канал данных. После открытия клиент может отправлять запросы по этому каналу. Обновления ресурсов будут передаваться по тому же каналу.

Источник данных (CSRC)

При использовании виртуальных медиапотоков нельзя предполагать, что медиапоток всегда указывает на одного и того же участника . Значение CSRC в заголовке каждого RTP-пакета определяет истинный источник пакета.

Meet присваивает каждому участнику конференции уникальное значение CSRC при подключении. Это значение остаётся неизменным до тех пор, пока участник не покинет конференцию.

Каналы данных

Каналы данных WebRTC позволяют обмениваться произвольными данными (текстом, файлами и т. д.) независимо от аудио- и видеопотоков. Каналы данных используют то же соединение, что и медиапотоки, предоставляя эффективный способ добавления обмена данными в приложения WebRTC.

Создание интерактивной связи (ICE)

Протокол для установления соединения, поиска всех возможных маршрутов для связи двух компьютеров через одноранговую (P2P) сеть, а затем обеспечения постоянного соединения.

Медиа-поток

Медиапоток WebRTC представляет собой поток медиаданных, обычно аудио- или видеоданных, захваченных с устройства, например камеры или микрофона. Он состоит из одной или нескольких дорожек медиапотока , каждая из которых представляет отдельный источник медиаданных (например, видеодорожку или аудиодорожку).

Трек медиапотока

Состоит из одного однонаправленного потока RTP-пакетов. Дорожка медиапотока может содержать аудио или видео, но не оба сразу. Двунаправленное соединение по протоколу SRTP (Secure Real-time Transport Protocol ) обычно состоит из двух дорожек медиапотока: исходящей от локального к удалённому одноранговому узлу и входящей от удалённого однорангового узла к локальному одноранговому узлу.

Место для встреч

Виртуальное место или постоянный объект (например, конференц-зал), где проводится конференция . В одном пространстве одновременно может проводиться только одна активная конференция. Конференц-пространство также помогает пользователям встречаться и находить общие ресурсы.

Участник

Участник, присоединившийся к конференции или использующий режим Companion Mode , наблюдающий в качестве зрителя, или устройство в комнате, подключенное к вызову. При присоединении к конференции участнику присваивается уникальный идентификатор.

Соответствующие потоки

Существует ограничение на количество виртуальных аудиопотоков и виртуальных видеопотоков, которые может открыть клиент.

Число участников конференции вполне может превысить это число. В таких ситуациях серверы Meet передают аудио- и видеопотоки участников, считающихся «наиболее релевантными». Релевантность определяется по различным характеристикам, таким как демонстрация экрана и время последнего выступления участника.

Блок выборочной пересылки (SFU)

Модуль селективной пересылки (SFU) — это серверный компонент WebRTC-конференций, управляющий распределением медиапотоков. Участники подключаются только к SFU, который выборочно пересылает нужные потоки другим участникам. Это снижает требования к обработке данных на стороне клиента и пропускной способности, обеспечивая масштабируемость конференций.

Протокол описания сеанса (SDP)

Механизм сигнализации, который WebRTC использует для установления P2P-соединения. Он регламентируется RFC 8866 .

ответ СДП

Ответ на предложение SDP . В ответе отклоняются или принимаются любые полученные потоки от удалённого однорангового узла. Он также согласовывает, какие потоки планируется передать обратно предлагающему одноранговому узлу. Важно отметить, что ответ SDP не может добавлять сигнализированные потоки из первоначального предложения. Как показывает практика, если предлагающий одноранговый узел сообщает, что принимает до трёх аудиопотоков от своего удалённого однорангового узла, этот удалённый одноранговый узел не может передавать четыре аудиопотока.

предложение СДП

Начальный SDP в одноранговом сеансе связи типа «предложение-ответ». Предложение создаётся инициирующим одноранговым узлом и определяет условия однорангового сеанса. Предложение всегда создаётся клиентом API Meet Media и отправляется на серверы Meet.

Например, в предложении может быть указано количество аудио- или видеопотоков, которые отправляет оферент (или может получить), а также будут ли открыты каналы передачи данных.

Источник синхронизации (SSRC)

SSRC — это 32-битный идентификатор, который однозначно идентифицирует отдельный источник медиапотока в сеансе RTP (Real-time Transport Protocol). В WebRTC SSRC используются для различения разных медиапотоков, исходящих от разных участников, или даже разных треков одного и того же участника (например, с разных камер).

RTP-трансивер

Как подробно изложено в RFC 8829 , приемопередатчик — это абстракция потоков RTP в одноранговом сеансе.

Один приёмопередатчик сопоставляется с одним описанием носителя в SDP и описывается им. Приёмопередатчик состоит из RtpSender и RtpReceiver .

Поскольку протокол RTP является двунаправленным, у каждого однорангового узла есть собственный экземпляр приёмопередатчика для одного и того же RTP-соединения. RtpSender данного приёмопередатчика локального однорангового узла сопоставляется с RtpReceiver определённого приёмопередатчика удалённого однорангового узла. Обратное также верно. RtpSender того же приёмопередатчика удалённого однорангового узла сопоставляется с RtpReceiver локального однорангового узла.

Каждое описание медиа-контента имеет свой выделенный приёмопередатчик. Таким образом, одноранговый сеанс с несколькими потоками RTP имеет несколько приёмопередатчиков с несколькими RtpSenders и RtpReceiver для каждого однорангового узла.

Виртуальные медиапотоки

Виртуальные медиапотоки — это агрегированные медиапотоки, генерируемые селективным пересылочным устройством (SFU) в конференциях WebRTC. Вместо того, чтобы каждый участник отправлял отдельные потоки всем остальным, SFU мультиплексирует выбранные потоки участников в меньшее количество исходящих виртуальных потоков. Это упрощает топологию соединения и снижает нагрузку на участников, обеспечивая масштабируемость конференций. Каждый виртуальный поток может содержать медиаданные от нескольких участников, динамически управляемые SFU.

Похожие темы

• Чтобы узнать, как приступить к разработке клиента API Meet Media, следуйте инструкциям в разделе Начало работы .

• Чтобы узнать, как настроить и запустить образец эталонного клиента API Meet Media, прочтите краткое руководство по эталонному клиенту C++ .

• Для получения концептуального обзора см. раздел Концепции API Meet Media .

• Дополнительную информацию о WebRTC можно найти в статье WebRTC для любопытных .

• Информацию о разработке с использованием API Google Workspace, включая обработку аутентификации и авторизации, см. в разделе Разработка в Google Workspace .