Meet Media API 概览

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

使用场景

在 Google Cloud 控制台中注册的应用可以使用 Meet Media API 连接到 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。

同意者要求

只有当通话中有人员可以代表会议提供同意声明时，Meet Media API 应用才能加入会议。

对于 Google Workspace 会议

如需在 Google Workspace 会议中表示同意，您必须属于会议所属的组织。在大多数情况下，会议的所有者与组织者相同。如果主持人或发起者在会议中且属于会议所属的组织，系统会优先向其显示开始对话框。

对于消费者会议

对于通过 Gmail 账号组织的会议，发起者必须出席会议才能提供同意声明。

常用术语

云项目编号
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 动态管理。