Meet Media API 概览

借助 Google Meet Media API，您可以访问 Google Meet 会议中的实时媒体。这可实现各种用例，例如记录行动项、提供有关当前会议的实时数据分析或将音频和视频流式传输到新界面的应用。

使用场景

在 Google Cloud 控制台中注册的应用可以使用 Meet Media API 连接到 Meet 会议，从而实现以下功能：

  • 使用视频流。例如：
    • 将 Meet 会议中生成的 Feed 视频流输入到您自己的 AI 模型中。
    • 过滤自定义录制的视频流。
  • 消耗音频流。例如：
    • 直接将音频馈送到 Gemini，并创建自己的会议 AI 聊天机器人。
    • 将 Meet 会议中生成的音频流馈送到您自己的转写服务
    • 生成各种语言的字幕。
    • 根据捕获的音频创建模型生成的手语 Feed。
    • 创建自己的降噪器模型，以移除会议中的背景噪声和嘈杂伪影。
  • 使用参与者元数据。例如：
    • 检测哪些参与者加入了会议，从而实现更出色的智能功能和分析功能。

Meet Media API 生命周期

下图显示了 Meet Media API 生命周期：

  • Meet Media API 机器人尝试在第三方网站上加入会议。
    图 1. Meet Media API 机器人尝试加入第三方网站。 如果存在未成年人账号，系统会拒绝关联。
  • 加密会议和带有水印的会议。
    图 2. 会议可以标记为已加密，并带有水印。当会议具有加密功能或水印时，无法连接 Meet Media API。
  • 确保管理员设置正确无误。
    图 3. 确保管理员设置正确无误。
  • 在日历中设置会议。
    图 4. 在日历中设置会议。主持人需要在日历设置中向第三方应用授予权限，否则连接会被拒绝。
  • 通话期间的设置更改。
    图 5.通话期间的设置更改。如果主持人决定在通话期间关闭 Meet Media API 设置，连接会停止。
  • 发起者必须在消费者会议期间在场。
    图 6. 如果会议所有者使用的是消费者账号（以 @gmail.com 结尾的账号），则发起者必须在场才能同意，否则连接会被拒绝。
  • 已建立连接。
    图 7. 连接建立后，主持人、共同主持人或与主持人同属一个组织的任何参与者都会看到启动对话框。
  • 通话期间，任何人都可以停止 Meet Media API。
    图 8. 通话期间，任何人都可以停止 Meet Media API。

常用术语

Cloud 项目编号
Google Cloud 项目的不可变生成 int64 标识符。这些值由 Google Cloud 控制台为每个已注册的应用生成。
会议
在会议空间内由服务器生成的通话实例。用户通常会将此场景视为一次会议。
会议资源数据通道

与 Google Meet REST API 不同，Meet Media API 客户端不是通过 HTTP 请求资源，而是通过数据通道从服务器请求资源。

可为每种资源类型打开一个专用数据通道。打开后，客户端可以通过该渠道发送请求。资源更新将通过同一渠道传输。

贡献来源 (CSRC)

使用虚拟媒体流时，您不能假定媒体流始终指向同一参与者。每个 RTP 数据包的标头中的 CSRC 值用于标识数据包的真实来源。

当参与者加入会议时，Meet 会为每位参与者分配一个唯一的 CSRC 值。此值在用户离开之前保持不变。

数据渠道

WebRTC 数据通道可实现任意数据（文本、文件等）的交换，而无需依赖音频和视频流。数据通道使用与媒体流相同的连接，从而为 WebRTC 应用提供了一种高效的数据交换方式。

交互式连接创建 (ICE)

一种用于建立连接的协议，可找到两台计算机通过对等 (P2P) 网络相互通信的所有可能路由，然后确保您保持连接。

媒体流

WebRTC 媒体流表示从摄像头或麦克风等设备捕获的媒体数据流（通常是音频或视频）。它由一个或多个媒体流轨道组成，每个轨道代表一个媒体源（例如视频轨道或音频轨道）。

媒体流轨道

由单个单向 RTP 数据包流组成。媒体流轨道可以是音频或视频，但不能同时是音频和视频。双向安全实时传输协议 (SRTP) 连接通常包含两个媒体流轨道：从本地对等互连到远程对等互连的出站流量，以及从远程对等互连到本地对等互连的入站流量。

会议空间

用于举行会议的虚拟场所或持久对象（例如会议室）。在任何时间，一个会议室中只能有一场正在进行的会议。会议空间还可帮助用户开会和查找共享资源。

参与者

加入会议或使用副屏模式的用户、以观众身份观看会议的用户，或连接到通话的会议室设备。当参与者加入会议时，系统会为其分配一个唯一 ID。

相关信息流

客户端可以打开的虚拟音频流和虚拟视频流的数量存在上限。

会议的参与者人数很可能会超过此人数。在这些情况下，Meet 服务器会传输被视为“最相关”的参与者的音频和视频流。相关性取决于各种特征，例如屏幕共享以及参与者最近一次发言的时间。

选择性转发单元 (SFU)

选择性转发单元 (SFU) 是 WebRTC 会议中的服务器端组件，用于管理媒体流分发。参与者仅连接到 SFU，后者会选择性地将相关视频流转发给其他参与者。这样可以减少客户端处理和带宽需求，从而实现可伸缩的会议。

会话描述协议 (SDP)

WebRTC 用于协商 P2P 连接的信令机制。RFC 8866 对其进行管理。

SDP 应答

对 SDP offer 的响应。该回答会拒绝或接受来自远程对等方的任何接收到的流。它还会协商计划传回给提供方对等方的哪些流。请务必注意，SDP 应答无法添加初始提议中的已发出信号的数据流。举例来说，如果提供方对等方发出信号，表明其最多接受来自远程对等方的三个音频流，则该远程对等方不能发出信号，表明其要传输四个音频流。

SDP offer

在提议-应答对等协商流程中的初始 SDP。该 offer 由发起方对等互联设备创建，并规定了对等互联会话的条款。邀约始终由 Meet Media API 客户端创建并提交给 Meet 服务器。

例如，某个 offer 可能表示 offer 发送方正在发送（或能够接收）的音频或视频流的数量，以及是否要打开数据通道。

同步源 (SSRC)

SSRC 是一个 32 位标识符，用于在 RTP（实时传输协议）会话中唯一标识媒体流的单个来源。在 WebRTC 中，SSRC 用于区分来自不同参与者的不同媒体流，甚至来自同一参与者的不同轨道（例如不同的摄像头）。

RtpTransceiver

如 RFC 8829 中所述，收发器是点对点会话中 RTP 流的抽象。

单个收发器映射到 SDP 中的单个媒体说明，并由该说明进行描述。收发器由 RtpSender 和 RtpReceiver 组成。

由于 RTP 是双向的，因此每个对等方都具有自己的收发器实例，用于同一 RTP 连接。本地对等方的给定收发器的 RtpSender 会映射到远程对等方中特定收发器的 RtpReceiver。反之亦然。远程对等方的同一收发器的 RtpSender 映射到本地对等方的 RtpReceiver。

每个媒体说明都有自己的专用收发器。因此，具有多个 RTP 流的点对点会话具有多个收发器，每个对等方都有多个 RtpSenders 和 RtpReceiver。

虚拟媒体流

虚拟媒体流是指 WebRTC 会议中由选择性转发单元 (SFU) 生成的聚合媒体流。SFU 不会让每个参与者都向其他所有人发送单独的流，而是将所选参与者的流多路复用到较少的传出虚拟流中。这样可以简化连接拓扑并减轻参与者的负担，从而实现可扩缩的会议。每个虚拟流都可以包含来自多个参与者的媒体，并由 SFU 动态管理。