Обзор API Meet Media

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

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

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

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

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

Номер облачного проекта
Неизменяемый идентификатор 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) обычно состоит из двух дорожек медиапотока: исходящего от локального узла к удаленному узлу и входящего от удаленного узла к локальному узлу.

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

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

Участник

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

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

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

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

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

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

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

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

ответ СДП

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

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

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

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

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

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

RtpТрансивер

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

Один трансивер отображается и описывается одним описанием носителя в SDP. Трансивер состоит из RtpSender и RtpReceiver .

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

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

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

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

,

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

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

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

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

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

Номер облачного проекта
Неизменяемый идентификатор 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) обычно состоит из двух дорожек медиапотока: исходящего от локального узла к удаленному узлу и входящего от удаленного узла к локальному узлу.

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

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

Участник

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

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

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

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

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

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

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

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

ответ СДП

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

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

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

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

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

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

RtpТрансивер

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

Один трансивер отображается и описывается одним описанием носителя в SDP. Трансивер состоит из RtpSender и RtpReceiver .

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

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

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

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