Обзор API Meet Media

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

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

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

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

Знакомство с жизненным циклом Media API

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

  • Бот Meet Media API пытается подключиться к стороннему веб-сайту.
    Рисунок 1. Бот Meet Media API пытается подключиться к стороннему веб-сайту. Подключение отклоняется при наличии учетных записей несовершеннолетних.
  • Зашифрованные встречи и встречи с водяным знаком.
    Рисунок 2. Встречи могут быть помечены как зашифрованные и иметь водяной знак. Подключение к Meet Media API невозможно, если встреча зашифрована или имеет водяной знак.
  • Убедитесь, что настройки администратора верны.
    Рисунок 3. Убедитесь, что настройки администратора указаны правильно.
  • Настройте встречу в Календаре.
    Рисунок 4. Настройка встречи в Календаре. Организатор должен предоставить разрешение стороннему приложению в настройках Календа, в противном случае соединение будет отклонено.
  • Изменение настроек во время звонка.
    Рисунок 5. Изменение настроек во время звонка. Если организатор решит отключить параметр Meet Media API во время звонка, соединение прервётся.
  • Инициатор должен присутствовать на встречах с потребителями.
    Рисунок 6. Если у владельца встречи есть учетная запись потребителя (учетная запись, заканчивающаяся на @gmail.com), то инициатор должен присутствовать на встрече, чтобы дать согласие, в противном случае соединение будет отклонено.
  • Соединение установлено.
    Рисунок 7. После установления соединения хост, сохост или любые участники той же организации, что и хост, видят диалоговое окно инициации.
  • Любой пользователь может остановить работу API Meet Media во время звонка.
    Рисунок 8. Любой пользователь может остановить работу API Meet Media во время звонка.

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

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

Для встреч в Google Workspace

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

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

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

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

номер облачного проекта
Неизменяемый сгенерированный идентификатор int64 для проекта Google Cloud. Эти значения генерируются консолью Google Cloud для каждого зарегистрированного приложения.
Конференция
Созданный сервером экземпляр звонка в рамках переговорного пространства . Пользователи обычно рассматривают этот сценарий как отдельную встречу.
Канал данных ресурсов конференции

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

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

Участник программы (CSRC)

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

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

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

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

Интерактивное соединение (ICE)

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

Медиапоток

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

Отслеживание медиапотока

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

Место для проведения встреч

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

Участник

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

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

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

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

Подразделение выборочной пересылки (SFU)

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

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

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

ответ SDP

The response to a SDP offer . The answer rejects or accepts any received streams from the remote peer. It also negotiates which streams it plans to transmit back to the offering peer. It's important to note that the SDP answer can't add signaled streams from the initial offer. Anecdotally, if an offering peer signals it accepts up to three audio streams from its remote peer, this remote peer can't signal four audio streams for transmission.

Предложение SDP

Исходный SDP в процессе переговоров между участниками сети по принципу «предложение-ответ». Предложение создается инициирующим участником и определяет условия сессии между участниками сети. Предложение всегда создается клиентом Meet Media API и отправляется на серверы 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.