Обзор API Meet Media

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

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

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

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

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

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

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

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

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

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

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

Источник вклада (CSRC)

С виртуальными медиапотоками вы не можете предполагать, что медиапоток всегда указывает на одного и того же участника . Значение CSRC в заголовке каждого пакета RTP идентифицирует истинный источник пакета.

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

Каналы передачи данных

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

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

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

Медиа поток

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

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

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

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

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

Участник

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

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

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

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

Избирательное пересылочное устройство (SFU)

Selective Forwarding Unit (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.