Amazon IVS 多轨道视频：广播软件集成指南

PDFRSS

简介

对于声称支持 IVS 多轨道视频的第三方广播公司软件工具或服务，必须遵循本指南并实施两个必需功能，即自动直播配置和广播性能指标。我们强烈建议也实现推荐功能。

下图显示了广播软件与 Amazon IVS 之间的高级别交互：

受众

本文档适用于想要为多轨道视频提供客户端支持的软件开发人员：

• 创作者广播软件旨在向 Amazon IVS 或使用 Amazon IVS 多轨道视频的服务直播。

• 第三方流直播平台，提供服务器端联播或转码服务，用户可以向 Amazon IVS 或使用 Amazon IVS 多轨道视频的服务直播。

术语

本文档使用一些可互用的术语：

• 用户、创作者、广播公司 – 使用广播软件创作和直播原创内容的最终用户。

• 服务、平台 – Amazon IVS 等视频平台或服务。

• 客户 – 可能使用 Amazon IVS 等服务为视频网站提供支持的企业。

必需功能：自动直播配置

自动直播配置可帮助用户快速入门，并随着时间的推移自动提高直播质量。自动直播配置不是用户手动选择只设置一次且很少调整的设置（例如比特率、分辨率、帧率），而是在用户每次启动新流时，根据当前的软件设置、硬件配置和平台支持进行调整。例如，用户升级设置（例如，使用新 GPU）、安装新的 GPU 驱动程序或目标开始支持新的编解码器（例如 H.265/HEVC）时，自动直播配置会做出反应并提高用户下一个直播的质量。

上线

用户开始直播时，软件必须查询有关用户硬件和软件设置的信息，调用 GetClientConfiguration，配置视频扩缩器/编码器，然后打开增强型 RTMP（E-RTMP）连接。这些步骤将在下文进行更详细的描述。

使用 GetClientConfiguration

GetClientConfiguration 需要有关用户硬件和软件设置的信息。

该算法考虑了许多因素来提供以下配置：

• 针对最佳观众体验进行优化 – 最高分辨率、最高帧率、最高比特率、最大轨道数、最新/最佳编解码器和最佳视频编码器设置。

• 由直播工具的设置和广播软件、用户配置的限制以及目标服务提供安全支持。

在实际操作中，较旧的 GPU、较差的第一英里网络、特定的用户设置、GPU 资源争用以及有限的平台编解码器支持都会限制实现此目标。遇到这些限制时，自动直播配置应该逐渐而合理地回退。例如：

• 在 10.2 Mbps（5 个格式副本）和 1.5 Mbps（2 个格式副本）之间调整所需的直播带宽。

• 将最高质量轨道的最大分辨率从 1080p（4 或 5 个格式副本）降低到 480p（2 个格式副本）。

• 在 5（1080p、720p、480p、360p、160p）和 2（480p、360p）之间调整个格式副本数量。

• 在一组广泛的支持分辨率（1080p、720p、540p、480p、360p、240p 和 160p）中改变格式副本选项。

• 将单个格式副本的比特率从 6 Mbps（例如 1080p60 AVC）调整为 200 Kbps（例如 160p AVC）。

• 在高（60、50 或 48 fps）和标准（30、25 或 24 fps）之间调整帧速率。

• 调整视频编解码器，平衡安全/查看器支持和编解码器效率（例如 H.264/AVC 或 H.265/HEVC）。

• 改变扩缩器算法来平衡 GPU 资源（例如 Lanczos、双立体和双线性）。

• 根据 GPU 供应商和驱动程序版本（例如 NVIDIA GeForce RTX 4080 上的 P6 降至 NVIDIA GeForce GTX 950 上的 P4），调整视频编码设置（包括编解码器配置文件、编码器预设、前瞻窗口、心理视觉 AQ 和 B 帧数）。

向用户公开首选项

必须允许用户配置以下设置：

• 输出分辨率

• 输出帧率

• 最大视频轨道数

• 最大直播比特率

可选：在广播软件中设置限制

软件或服务可能会提供默认设置或限制用户配置这些设置。例如，如果软件或服务需要保留 GPU 资源，并且您想限制多轨道视频使用的视频编码器会话数量，则可以选择将用户的最大视频轨道数限制为 3 个，并向用户明确表示自动表示“最多 3 个”。

目标设置的限制

GetClientConfiguration 请求中的直播密钥是必需的，这样服务才能识别通道并确定是否存在每个通道的限制。例如，Amazon IVS 为 STANDARD 通道提供了 multitrackInputConfiguration.maximumResolution 属性。这可以用于限制任何单个轨道的分辨率，这样客户就可以向特定创作者提供特殊分辨率的直播（例如 720p60 或 1080p60 直播），或者以其他方式控制他们的输出成本。

处理警告和错误

GetClientConfiguration 在不同的情况下会返回警告和错误，因此必须实施面向用户的支持才能处理警告和错误。

警告仅供参考。允许用户继续直播或取消直播。以下是警告示例：

• 自 DD/MM/YYYY 起，用户计算机上安装的 NVIDIA 驱动程序版本将不再受支持。

错误被视为致命的。不允许用户继续直播。以下是错误示例：

• 该通道未配置为支持多轨道视频。

• 过时/不支持的 GPU 驱动程序版本。

• 您的 GPU 不受支持。

• 提供的直播密钥无效。

• Amazon IVS 多轨道视频不支持帧速率 59.94。在“设置 > 视频”中，选择下列支持的值之一：24、25、30、48、50、60。

• 配置请求缺少所需数据（GPU 驱动程序版本、GPU 型号等）。

配置视频缩放和编码

GetClientConfiguration 返回缩放和编码设置，这些设置会针对最佳观众体验进行优化，而不会影响应用程序（例如游戏/广播软件）的性能，还会会考虑用户的设置。使用 GetClientConfiguration 返回的确切缩放和编码设置。GetClientConfiguration 考虑了不同供应商的特定需求以及随时间变化的 GPU 架构。

除了缩放和编码设置（如预设）外，还必须进行以下操作：

• 对齐所有编码器并确保所有格式副本的 IDR 具有相同的 PTS。这是为了避免在使用分段 HLS 分发和观看视频时，需要进行服务器端转码来对齐多个格式副本。如果视频轨道上的 IDR 未对齐，则观众在 ABR 播放中切换格式副本时，将出现时移和卡顿现象。（有关可视化，请参阅《广播性能指标》中的图。）

• 克隆所有视频轨道中的 SEI/OBU 数据（例如字幕）。此操作是必需的，这样无论观看的单个直播的质量如何，视频回放器都可以访问 SEI/OBU 数据。

使用增强型 RTMP 进行连接

有关通过增强型 RTMP 进行多轨道直播的文档，请参阅《Enhanced RTMP v2 specification》。

使用增强型 RTMP 进行连接时，Amazon IVS 多轨道视频有以下几项要求：

• 必须将质量最高的主视频轨道打包并作为增强型 RTMP 单轨道视频数据包发送。例如，videoPacketType 可以是 CodedFrames、CodedFramesX、SequenceStart 和 SequenceEnd。

• 必须将所有其他视频轨道打包并作为增强型 RTMP 多轨道视频数据包（例如，videoPacketType 为 Multitrack）发送，并将多轨道数据包类型设置为一个轨道（例如，videoMultitrackType 为 OneTrack）。

• 必须使用 GetClientConfiguration 返回的 authentication 字段中的直播密钥连接到 RTMP 服务器。

• GetClientConfiguration 返回的 config_id 值必须作为查询参数附加到带密钥 clientConfigId 的 RTMP 连接字符串中。

下面是直播配置的示例：

videoPacketType	videoMultitrackType	trackId	解决方案
CodedFrames CodedFramesX SequenceStart SequenceEnd	NA – videoMultitrackType 不使用单轨道增强型 RTMP 发送。	NA – trackId 不使用单轨道增强型 RTMP 发送。	1920x1080
多轨道	单轨通	1	1280x720
多轨道	单轨通	2	852x480
多轨道	单轨通	3	640x360

广播软件应使用 ingest_endpoints 中 GetClientConfiguration 返回的数据和用户选择的协议（RTMP 或 RTMPS）来识别要连接的端点。使用 url_template 和 authentication 中返回的直播密钥创建 URL，并包含 config_id 作为 clientConfigId 查询参数。如果您允许用户指定 RTMP 查询参数（例如 ?bandwidthtest=1），则除了指定 clientConfigId 之外，还必须附加这些参数。以下是 GetClientConfiguration 的响应示例：

{
   "ingest_endpoints": [
      {
         "protocol": "RTMP",
         "url_template": "rtmp://iad05.contribute.live-video.net/app/{stream_key}",
         "authentication": "v1_5f2e593731dad88b6bdb03a3517d306ef88a73e29619ee4b49012d557e881484_65c5dc81_7b2276223a302c2262223a393939392c2274223a5b7b2277223a3634302c2268223a3336302c2262223a3530302c226330223a312c226331223a302c226332223a307d2c7b2277223a313238302c2268223a3732302c2262223a313730302c226330223a312c226331223a302c226332223a307d2c7b2277223a313932302c2268223a313038302c2262223a363030302c226330223a312c226331223a302c226332223a307d5d7d_live_495665160_FC45sNuCYUwLnCVtCnXSjEWkusXzJI"
      },
      {
         "protocol": "RTMPS",
         "url_template": "rtmps://iad05.contribute.live-video.net/app/{stream_key}",
         "authentication": "v1_5f2e593731dad88b6bdb03a3517d306ef88a73e29619ee4b49012d557e881484_65c5dc81_7b2276223a302c2262223a393939392c2274223a5b7b2277223a3634302c2268223a3336302c2262223a3530302c226330223a312c226331223a302c226332223a307d2c7b2277223a313238302c2268223a3732302c2262223a313730302c226330223a312c226331223a302c226332223a307d2c7b2277223a313932302c2268223a313038302c2262223a363030302c226330223a312c226331223a302c226332223a307d5d7d_live_495665160_FC45sNuCYUwLnCVtCnXSjEWkusXzJI"
      }
   ],
   "meta": {
      "config_id": "d34c2f7e-ce3a-4be4-a6a0-f51960abbc4f",
      …
   }
   …
}

然后，如果用户选择了 RTMP，将打开以下连接：

rtmp://iad05.contribute.live-video.net/app/v1_5f2e593731dad88b6bdb03a3517d306ef88a73e29619ee4b49012d557e881484_65c5dc81_7b2276223a302c2262223a393939392c2274223a5b7b2277223a3634302c2268223a3336302c2262223a3530302c226330223a312c226331223a302c226332223a307d2c7b2277223a313238302c2268223a3732302c2262223a313730302c226330223a312c226331223a302c226332223a307d2c7b2277223a313932302c2268223a313038302c2262223a363030302c226330223a312c226331223a302c226332223a307d5d7d_live_495665160_FC45sNuCYUwLnCVtCnXSjEWkusXzJI?clientConfigId=d34c2f7e-ce3a-4be4-a6a0-f51960abbc4f

处理视频断开连接问题

多轨道视频系统强制执行多个限制。总的来说，这些限制的存在有以下三个原因：

1. 系统安全 – IVS 需要限制输入来实现可扩展性。示例包括影响输入处理的基于每个通道的直播带宽限制、影响输出容量/成本的基于轨道或分辨率的比特率授权，以及影响 CDN 复制/交付容量的轨道数量授权。

2. 系统功能 – 服务需要限制输入来实现功能兼容性（例如，对单个编解码器的平台支持或对高级编解码器的交付容器支持）。

3. 观众体验 – 服务需要限制输入来提高观众体验和品牌声誉。例如，服务会控制回放器 ABR 算法，该算法驱动所有目标用户设备（桌面、移动、TV/OTT 等）和应用程序（浏览器、本机等）的 QoE。

视频系统会在以下几种情况下断开客户端连接：

• 客户端尝试使用多轨道视频连接到 RTMP 服务器，但不使用 GetClientConfiguration 返回的直播密钥。

• 客户端提供的多轨道视频与 GetClientConfiguration 返回的规范不符；例如：

  • 轨道的数量不匹配。

  • 单个轨道的编解码器不匹配。

  • 单个轨道的分辨率不匹配。

  • 单个轨道的帧率不匹配。

  • 单个轨道的比特率不匹配。

• 客户端不提供已对齐 IDR 的视频轨道。

• 广播性能指标并不先于每个轨道上的每个 IDR。

连接断开的情况可能发生在直播开始时（即通道从未上线）或中途（即通道已上线，检测到不匹配，然后客户端断开连接）。

自动重新连接

GetClientConfiguration 返回的直播密钥的有效期为 48 小时，或者直到调用 DeleteStreamKey 让直播密钥失效为止。IVS 直播的最长时长为 48 小时；之后，直播将终止并断开直播会话。成功重新连接（自动或手动）将启动新流。

广播软件可能会实施自动重新连接。如果支持自动重新连接，则应允许用户启用/禁用自动重新连接，并遵循以下准则：

• 在连接尝试之间实施指数回退重试延迟（包括较小的随机偏差）。

• 最多重试 25 次连接尝试。例如，OBS Studio 重试 25 次，两次尝试之间的等待时间呈指数级增长，上限为 15 分钟。实际上，这意味着最后一次重试在断开连接大约 3 小时后进行。

• 如果在连接时发送 publish 后立即断开连接，请调用 GetClientConfiguration，重新配置编码器设置，然后尝试再次连接。

停止直播并断开连接

用户停止直播时，如果 TCP 连接仍处于打开状态（例如，较低级别的连接未重置），则必须在关闭 RTMP 连接之前发送 FCUnpublish（OBS Studio 中的示例实施）。这对于表明用户结束直播意图的信号至关重要，因为下游功能是否正常运行取决于此信号。

必需功能：广播性能指标（BPM）

为了持续改进自动直播配置，提供最佳的直播设置，必须测量和发送广播性能指标（BPM）。

这些指标是通过 SEI（适用于 AVC/HEVC）消息收集并在带内发送的。将收集两类数据：

• 收集时间戳，以便测量广播公司和观众之间的端到端延迟。这类数据可用于：

  • 向广播公司或观众提供端到端延迟的估算值。

  • 分析时间戳抖动，该抖动可能表明存在系统压力或第一英里网络连接不佳的问题。

  • 参考真实世界的事件时间来对齐和聚合时间序列计数器数据。

  广播公司发送的时间戳基于全球通用参考时钟，通常是使用 UTC+0 时区的 NTP 同步时钟。RFC3339 通常用于这种“互联网时间”场景。此时钟可作为绝对的参考，有助于轻松计算时间差值。

• 收集帧计数器，以便在帧级别测量广播软件和视频编码器的性能。这类数据可用于：

  • 向广播公司提供包含其他信号的性能控制面板，帮助他们改善直播设置。

  • 提供可能与新发布的 GPU 驱动程序或操作系统版本/补丁等环境变化相关的主动信号。

  • 提供反馈，让视频服务能够安全地进行迭代和发布 GetClientConfiguration 的改进，包括对新硬件供应商、新 GPU 型号、新编解码器、新驱动程序功能、额外的视频编码器设置调整以及新用户控制预设（例如，“双 PC 设置”与“游戏 + 直播设置”）的支持。

插入 SEI/OBU 消息

有关具体的消息字节直播定义，请参阅《BPM 消息定义》。

必须在 IDR 之前在所有视频轨道上插入 BPM 指标。这三条消息（BPM TS、BPM SM 和 BPM ERM）应一起发送，但每条消息都应作为单独的 NUT（AVC/HEVC）发送。

在第一个分段中发送的 BPM SM 和 BPM ERM 的帧计数器应设置为 0。这乍一看似乎有悖常理；然而，诸如每个格式副本帧数之类的计数器要直到编码完成之后才具有有意义的数据，结果是分段 N 中的帧计数器与分段 N-1 中的帧计数器保持一致。最好将 BPM 指标视为以 IDR 间隔在视频比特流中传送的时间数据序列。如有必要，接收器应使用提供的时间戳对数据序列进行精确的重新调整。

下图描绘了三重格式副本多轨道直播的典型场景。由于典型的分段大小为两秒，每个格式副本的指标将每两秒发送一次。

推荐的功能

允许进行自动服务器选择

自动服务器选择可帮助用户根据全球网络状况和接入点（PoP）可用性的变化，选择最佳的接入服务器来连接他们的直播流。

如果广播软件支持进行自动服务器选择，根据软件是否实施 GetClientConfiguration 和/或 FindIngest，我们预计会出现不同的行为。下面分别列出了每种场景。

如果广播软件同时实施了 GetClientConfiguration 和 FindIngest，则会出现以下行为：

用户 UI 选择	连接到由……指定的接入端点
自动	GetClientConfiguration
FindIngest 中的特定接入端点	用户的选择
指定自定义服务器	用户的选择

如果广播软件实施了 GetClientConfiguration，但未实施 FindIngest，则会出现以下行为：

用户 UI 选择	连接到由……指定的接入端点
自动	GetClientConfiguration
指定自定义服务器	用户的选择

如果广播软件没有实现 GetClientConfiguration，但实施了 FindinGest，则会出现以下行为：

用户 UI 选择	连接到由……指定的接入端点
自动	FindIngest
FindIngest 中的特定接入端点	用户的选择
指定自定义服务器	用户的选择

如果广播软件没有实施 GetClientConfiguration 或 FindIngest，则会出现以下行为：

用户 UI 选择	连接到由……指定的接入端点
自动	全球接入 URL： 对于 RTMP：rtmp://ingest.global-contribute.live-video.net/app 对于 RTMPS：rtmps://ingest.global-contribute.live-video.net:443/app
指定自定义服务器	用户的选择

有关使用 FindIngest 指定的接入端点的更多信息，请参阅使用 FindIngest 服务器作为自动直播目标。

允许用户配置直播目标

用户配置直播目标时，您应该查询 FindIngest，让用户能够执行以下操作：

• 在 RTMP 或 RTMPS（Amazon IVS 的默认设置）之间进行选择。

• 为服务器选择自动。

• 从 FindIngest 返回的列表中选择特定的服务器

• 输入自定义服务器；例如，使用指定自定义服务器。

可以根据用户选择的协议（RTMP 与 RTMPS）或其他注意事项来筛选 FindIngest 返回的列表。

例如，OBS Studio 中 Amazon IVS 的实现通过提供具有以下选项的简单服务器下拉列表来实现这一点：

• 自动（RTMPS，推荐）

• 自动（RTMP）

• 美国东部：弗吉尼亚州阿什本（5）（RTMPS）

• 美国东部：纽约州纽约（50）（RTMPS）

• 美国东部：纽约州纽约（RTMPS）

• 美国东部：弗吉尼亚州阿什本（5）（RTMP）

• 美国东部：纽约州纽约（50）（RTMP）

• 美国东部：纽约州纽约（RTMP）

• 指定自定义服务器

选择指定自定义服务器后，系统将提供一个文本框供用户输入 RTMP URL。

使用 FindIngest 服务器作为自动直播目标

如果在为直播目标指定“自动”时使用 FindIngest 指定的接入端点，请使用 FindIngest 返回的 priority 值最低的条目。为了缩短直播上线所需的时间，可以缓存 FindIngest 响应。如果缓存了响应，请定期更新缓存的值。

如果用户选择 RTMP，则使用 url_template 字符串作为 RTMP 广播目标。如果用户选择 RTMPS，则使用 url_template_secure 字符串作为 RTMPS 广播目标。在这两种情况下，都将 {stream_key} 替换为用户的直播密钥。

广播性能指标（BPM）消息定义

BPM 消息基于《H.264 标准》SEI 语法。作为参考，H.264 规范中用户数据未注册的 SEI 语法为：

对于 BPM 消息，H.264 标准中的所有解析和符号规则均适用，例如，“u(128)”表示无符号 128 位整数，MSB 优先。

为 BPM 定义了三种 SEI 消息：

• BPM TS SEI：时间戳消息

• BPM SM SEI：会话指标消息

• BPM ERM SEI：编码的格式副本指标消息

所有 BPM SEI 消息都会发送 user_data_unregistered() 语法所需的 128 位 UUID，后跟一串有效载荷字节。然后，将生成的消息封装在更高级的语义中（例如，NALU、RBSP 和启动代模拟预防）。

BPM TS（时间戳）SEI

BPM TS SEI 消息传达一个或多个相关时间戳。例如，客户端可以在单个 SEI 消息中发出帧合成、帧编码请求、帧编码请求完成和数据包交错的时间戳，客户端可以决定这些时间戳是否应以挂钟（RFC3339/ISO8601 风格）、增量（差值）时钟或自纪元以来的持续时间发送。应该有一个时间戳作为增量类型时钟的参考；这应该由部署来处理，而不是由任何语法约束来处理。

user_data_unregistered_bpm_ts( payloadSize ) {	C	描述符
uuid_iso_iec_11578	5	u(128)
ts_reserved_zero_4bits	5	b(4)
num_timestamps_minus1	5	u(4)
for( i = 0; i <= num_timestamps_minus1; i++ ) {
timestamp_type[i]	5	u(8)
timestamp_event[i]	5	u(8)
if (timestamp_type[i] == 1)
rfc3339_ts[i]	5	st(v)
else if (timestamp_type[i] == 2)
duration_since_epoch_ts[i]	5	u(64)
else if (timestamp_type[i] == 3)
delta_ts[i]	5	i(64)
}
}

BPM TS SEI 字段描述表

字段	描述
uuid_iso_iec_11578	设置为十六进制：0aecffe752724e2fa62fd19cd61a93b5 使用未注册的 SEI 消息时，需要使用 UUID 来区分此消息与任何其他未注册的消息。
ts_reserved_zero_4bits	留待将来使用。设置为 b('0000')。接收器应忽略这些位。
num_timestamps_minus1	num_timestamps=num_timestamps_minus1+1 num_timestamps_minus1 应介于 0 至 15 之间，这意味着可以发出 1 到 16 个时间戳。
timestamp_type	请参阅 timestamp_type 表。
timestamp_event	下列情况之一： BPM_TS_EVENT_CTS = 1 // 合成时间事件 BPM_TS_EVENT_FER = 2 // 帧编码请求事件 BPM_TS_EVENT_FERC = 3 // 帧编码请求完成事件 BPM_TS_EVENT_PIR = 4 // 数据包交错请求事件 在大于 num_timestamps_minus1 0（即发出多个时间戳）时，没有语法鉴别器可以识别唯一性；因此，在 SEI 循环中 timestamp_event 应是唯一的。不排除使用相同 timestamp_event 发出多个时间戳；但是，对时间戳的解释超出了消息的范围。

timestamp_type 表

timestamp_type 指定类型，例如：

• “挂钟”格式，以日历为基础显示日期和时间。

• 自纪元以来的持续时间。

• 增量时间戳，表示两个事件之间的差值。

• 将来可能需要的其他时间戳格式。

timestamp_type	名称	描述
0	未定义	未定义 – 请勿使用。
1	rfc3339_ts	RFC3339 是 ISO8601 针对互联网使用的配置文件，它限制了 ISO8601 中的某些选项。 timestamp_type==1 应使用基于 RFC3339 的时间表示法。请注意，RFC3339 不支持时区。所有时间戳均相对于 UTC（又名“祖鲁时间”），顾名思义，其为 UTC 偏移量 00:00。 rfc3339_ts 应该是一个字符串。st(v) 在 H.264 standard 第 7.2 节中定义。 请参阅此表下方关于闰秒的注释。 示例：2024-03-25T15:10:34.489Z（489 表示毫秒）
2	duration_since_epoch_ts	1970-01-01T00:00:00Z000 时自纪元以来的持续时间（以毫秒为单位）。 请参阅此表下方关于闰秒的注释。
3	delta_ts	增量时间戳，表示两个事件之间以纳秒为单位的差值。有符号整数允许以信号形式表示正数和负数增量。
4-255	预留	预留。

关于闰秒的注释：值得注意的是，已达成协议，将在 2035 年前逐步停止使用闰秒。有关详细信息，请参阅维基百科中关于闰秒的条目。我们建议使用不包括闰秒的时间戳。这与 2035 年的预期做法一致，并避免了可能出现的时间错误估计。

BPM SM（会话指标）SEI

BPM SM SEI 消息传达与整体发送器会话相关的一组指标。在 OBS Studio 中，这意味着发送以下帧计数器：

• 已渲染的会话帧

• 已丢弃的会话帧

• 滞后的会话帧

• 输出的会话帧

此 SEI 消息还包含时间戳。这在 BPM TS SEI 中是多余的；但是，在每条 SEI 消息中提供明确的时间戳可以提供原子行为单位，并减少接收器重新调整数据的负载。此外，如果需要删除或不发送 BPM TS SEI，BPM SM SEI 消息中仍会有明确的时间戳可供使用。

user_data_unregistered_bpm_sm( payloadSize ) {	C	描述符
uuid_iso_iec_11578	5	u(128)
ts_reserved_zero_4bits	5	b(4)
num_timestamps_minus1	5	u(4)
for( i = 0; i <= num_timestamps_minus1; i++ ) {
timestamp_type[i]	5	u(8)
timestamp_event[i]	5	u(8)
if (timestamp_type[i] == 1)
rfc3339_ts[i]	5	st(v)
else if (timestamp_type[i] == 2)
duration_since_epoch_ts[i]	5	u(64)
else if (timestamp_type[i] == 3)
delta_ts[i]	5	i(64)
}
ts_reserved_zero_4bits	5	b(4)
num_counters_minus1	5	u(4)
for( i = 0; i <= num_counters_minus1; i++ ) {
counter_tag[i]	5	b(8)
counter_value[i]	5	b(32)
}
}

BPM SM SEI 字段描述表

此 SEI 消息中的许多字段与 BPM TS SEI 字段类似。显著的区别在于 UUID 值、预期的时间戳数量以及正在传输的计数器。

字段	描述
uuid_iso_iec_11578	设置为十六进制：ca60e71c-6a8b-4388-a377-151df7bf8ac2 使用未注册的 SEI 消息时，需要使用 UUID 来区分此消息与任何其他未注册的消息。
ts_reserved_zero_4bits	留待将来使用。设置为 b('0000')。接收器应忽略这些位。
num_timestamps_minus1	num_timestamps=num_timestamps_minus1+1 num_timestamps_minus1 应介于 0 至 15 之间，这意味着可以发出 1 到 16 个时间戳。 当前，该值应为 0（表示单个时间戳）。
timestamp_type	请参阅 timestamp_type 表。对于 BPM SM SEI，这应该是类型 1 – RFC3339 字符串。
timestamp_event	下列情况之一： BPM_TS_EVENT_CTS = 1 // 合成时间事件 BPM_TS_EVENT_FER = 2 // 帧编码请求事件 BPM_TS_EVENT_FERC = 3 // 帧编码请求完成事件 BPM_TS_EVENT_PIR = 4 // 数据包交错请求事件 在大于 num_timestamps_minus1 0（即发出多个时间戳）时，没有语法鉴别器可以识别唯一性；因此，在 SEI 循环中 timestamp_event 应是唯一的。不排除使用相同 timestamp_event 发出多个时间戳；但是，对时间戳的解释超出了消息的范围。 注意：Amazon IVS 预计 BPM SM SEI 使用仅设置为 4 (BPM_TS_EVENT_PIR) 的 timestamp_event。随着对其他时间戳事件的支持不断增加，这一情况将不断变化。
num_counters_minus1	num_counters=num_counters_minus1+1 num_counters_minus1 应介于 0 至 15 之间，这意味着可以发出 1 到 16 个计数器。 对于 BPM SM SEI，该值应为 3（表示可以发出 4 个计数器）。
counter_tag	下列情况之一： BPM_SM_FRAMES_RENDERED = 1 // 合成器渲染的帧 BPM_SM_FRAMES_LAGGED = 2 // 合成器滞后的帧 BPM_SM_FRAMES_DROPPED = 3 // 由于网络拥塞而丢弃的帧 BPM_SM_FRAMES_OUTPUT = 4 // 总输出帧数（所有视频编码器格式副本接收器的总和）
counter_value	指定 counter_tag 相对于上次发送时的 32 位差值。例如，以 60 fps 渲染时，每 2 秒 counter_value 应为 120。

BPM SM 示例

以下是发送到 Amazon IVS 的 BPM SM SEI 示例：

• uuid_iso_iec_11578（16 字节）：ca60e71c-6a8b-4388-a377-151df7bf8ac2

• ts_reserved_zero_4bits（4 位）：0x0

• num_timestamps_minus1（4 位）：0x0（表示正在发送 1 个时间戳）

• timestamp_type（1 字节）：0x01（RFC3339 时间戳 – 字符串格式）

• timestamp_event（1 字节）：0x04（BPM_TS_EVENT_PIR）

• rfc3339_ts：“2024-03-25T15:10:34.489Z”

• ts_reserved_zero_4bits（4 位）：0x0

• num_counters_minus1（4 位）：0x3（表示正在发送 4 个计数器）

• counter_tag（1 字节）：0x01（自上一条消息以来合成器渲染的帧）

• counter_value：（4 字节）

• counter_tag（1 字节）：0x02（自上一条消息以来合成器滞后的帧）

• counter_value：（4 字节）

• counter_tag（1 字节）：0x03（自上一条消息以来由于网络拥塞而丢弃的帧）

• counter_value：（4 字节）

• counter_tag（1 字节）：0x04（总帧输出（自上一条消息以来所有视频编码器格式副本接收器的总和））

• counter_value：（4 字节）

BPM ERM（编码的格式副本指标）SEI

BPM ERM SEI 消息传达与每个编码格式副本相关的一组指标。在 OBS Studio 中，这意味着发送以下帧计数器：

• 输入的格式副本帧

• 跳过的格式副本帧

• 输出的格式副本帧

此 SEI 消息还包含时间戳。这在 BPM TS SEI 中是多余的；但是，在每条 SEI 消息中提供明确的时间戳可以提供原子行为单位，并减少接收器重新调整数据的负载。此外，如果需要删除或不发送 BPM TS SEI，BPM ERM SEI 消息中仍会有明确的时间戳可供使用。

user_data_unregistered_bpm_erm( payloadSize ) {	C	描述符
uuid_iso_iec_11578	5	u(128)
ts_reserved_zero_4bits	5	b(4)
num_timestamps_minus1	5	u(4)
for( i = 0; i <= num_timestamps_minus1; i++ ) {
timestamp_type[i]	5	u(8)
timestamp_event[i]	5	u(8)
if (timestamp_type[i] == 1)
rfc3339_ts[i]	5	st(v)
else if (timestamp_type[i] == 2)
duration_since_epoch_ts[i]	5	u(64)
else if (timestamp_type[i] == 3)
delta_ts[i]	5	i(64)
}
ts_reserved_zero_4bits	5	b(4)
num_counters_minus1	5	u(4)
for( i = 0; i <= num_counters_minus1; i++ ) {
counter_tag[i]	5	b(8)
counter_value[i]	5	b(32)
}
}

BPM ERM SEI 字段描述表

此 SEI 消息中的许多字段与 BPM TS SEI 字段和 BPM SM SEI 字段类似。显著的区别在于 UUID 值、预期的时间戳数量以及正在传输的计数器。

字段	描述
uuid_iso_iec_11578	设置为十六进制：f1fbc1d5-101e-4fb5-a61e-b8ce3c07b8c0 使用未注册的 SEI 消息时，需要使用 UUID 来区分此消息与任何其他未注册的消息。
ts_reserved_zero_4bits	留待将来使用。设置为 b('0000')。接收器应忽略这些位。
num_timestamps_minus1	num_timestamps=num_timestamps_minus1+1 num_timestamps_minus1 应介于 0 至 15 之间，这意味着可以发出 1 到 16 个时间戳。 当前，该值应为 0（表示单个时间戳）。
timestamp_type	请参阅 timestamp_type 表。 这应该是类型 1 – RFC3339 字符串。
timestamp_event	下列情况之一： BPM_TS_EVENT_CTS = 1 // 合成时间事件 BPM_TS_EVENT_FER = 2 // 帧编码请求事件 BPM_TS_EVENT_FERC = 3 // 帧编码请求完成事件 BPM_TS_EVENT_PIR = 4 // 数据包交错请求事件 在大于 num_timestamps_minus1 0（即发出多个时间戳）时，没有语法鉴别器可以识别唯一性；因此，在 SEI 循环中 timestamp_event 应是唯一的。不排除使用相同 timestamp_event 发出多个时间戳；但是，对时间戳的解释超出了消息的范围。 注意：Amazon IVS 预计 BPM ERM SEI 使用仅设置为 4 (BPM_TS_EVENT_PIR) 的 timestamp_event。随着对其他时间戳事件的支持不断增加，这一情况将不断变化。
num_counters_minus1	num_counters=num_counters_minus1+1 num_counters_minus1 应介于 0 至 15 之间，这意味着可以发出 1 到 16 个计数器。 对于 BPM ERM SEI，该值应为 2（表示可以发出 3 个计数器）。
counter_tag	下列情况之一： BPM_ERM_FRAMES_INPUT = 1 // 输入编码器格式副本的帧 BPM_ERM_FRAMES_SKIPPED = 2 // 编码器格式副本跳过的帧 BPM_ERM_FRAMES_OUTPUT = 3 // 编码器格式副本输出（编码）的帧
counter_value	指定 counter_tag 相对于上次发送时的 32 位差值。例如，以 60 fps 渲染时，每 2 秒 counter_value 应为 120。

BPM ERM 示例

以下是发送到 Amazon IVS 的 BPM ERM SEI 示例：

• uuid_iso_iec_11578（16 字节）：f1fbc1d5-101e-4fb5-a61e-b8ce3c07b8c0

• ts_reserved_zero_4bits（4 位）：0x0

• num_timestamps_minus1（4 位）：0x0（表示正在发送 1 个时间戳）

• timestamp_type（1 字节）：0x01（RFC3339 时间戳 – 字符串格式）

• timestamp_event（1 字节）：0x04（BPM_TS_EVENT_PIR）

• rfc3339_ts：“2024-03-25T15:10:34.489Z”

• ts_reserved_zero_4bits（4 位）：0x0

• num_counters_minus1（4 位）：0x2（表示正在发送 3 个计数器）

• counter_tag（1 字节）：0x01（自上一条消息以来输入的编码格式副本帧）

• counter_value：（4 字节）

• counter_tag（1 字节）：0x02（自上一条消息以来跳过的编码格式副本帧）

• counter_value：（4 字节）

• counter_tag（1 字节）：0x03（自上一条消息以来输出的编码格式副本帧）

• counter_value：（4 字节）