Meet Media API 概览

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

使用场景

在 Google Cloud 控制台中注册的应用可以使用 Meet Media API 连接到 Meet 会议，从而执行以下操作：

  • 使用视频串流。例如：
    • 将 Meet 会议中生成的视频流馈送到您自己的 AI 模型。
    • 过滤自定义录制的直播。
  • 使用音频串流。例如：
    • 直接将音频馈送到 Gemini，创建您自己的会议 AI 聊天机器人。
    • 将 Meet 会议中生成的音频流馈送到您自己的转写服务
    • 生成多种语言的字幕。
    • 根据捕获的音频创建模型生成的手语动作画面。
    • 创建您自己的降噪模型，以从会议中移除背景和噪声工件。
  • 使用参与者元数据。例如：
    • 检测会议中的参与者，以便获得更准确的情报和分析。

Meet 媒体 API 生命周期

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

  • Meet Media API 聊天机器人会尝试加入第三方网站上的会议。
    图 1. Meet Media API 聊天机器人会尝试加入第三方网站上的会议。 如果存在未成年人账号，系统会拒绝关联。
  • 加密会议和添加了水印的会议。
    图 2. 会议可以标记为已加密并带有水印。当会议启用了加密或添加了水印时，无法连接 Meet Media API。
  • 确保管理员设置正确无误。
    图 3. 确保管理员设置正确无误。
  • 在日历中设置会议。
    图 4. 在日历中设置会议。主机需要在 Google 日历设置中向第三方应用授予权限，否则系统会拒绝连接。
  • 通话期间的设置更改。
    图 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 用于协商点对点连接的信号机制。RFC 8866 对其进行管理。

SDP 回答

对 SDP 报价的响应。该答案会拒绝或接受来自远程对等方的任何收到的串流。它还会协商计划将哪些数据流传回提供方对等方。请务必注意，SDP 响应无法添加初始报价中已发送信号的数据流。附带说明一下，如果提供方对等发出信号，表示它最多接受来自远程对等的三个音频串流，则此远程对等无法发出四个音频串流的信号进行传输。

SDP 方案

提议-回复点对点协商流程中的初始 SDP。该报价由发起端对等方创建，并决定点对点会话的条款。优惠始终由 Meet Media API 客户端创建并提交给 Meet 服务器。

例如，一个优惠可能指示提供方正在发送（或能够接收）的音频或视频串流数量，以及是否要打开数据信道。

同步源 (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 动态管理的来自多个参与者的媒体。