跳到主要内容

6. RTCP 反馈消息格式 (Format of RTCP Feedback Messages)

本节定义低时延 RTCP 反馈消息的格式, 分三类:

  • 传输层 FB 消息
  • 载荷专用 FB 消息
  • 应用层 FB 消息

传输层 FB 用于通用反馈, 与具体编解码或应用无关, 预期在传输/RTP 层生成与处理. 目前仅定义通用否定确认 (NACK).

载荷专用 FB 携带与某载荷类型相关的信息, 在编解码 "层" 生成与处理. 本文档为所有载荷专用 FB 定义公共头; 具体消息由 RTP 载荷格式规范或附加反馈格式文档定义.

应用层 FB 在接收端应用与发送端应用之间透明传送反馈, 预期不在传输/RTP 或编解码层处理. 两应用实例间数据通常在应用协议中定义, 应用可自行识别, 无需额外外部信息. 故本文档仅为所有应用层 FB 定义公共头; 从协议角度, 应用层 FB 视为载荷专用 FB 的特例.

注: 发送端正确处理部分 FB 可能需知 FB 所指载荷类型. 单载荷流通常可推断. 若同时使用多种编解码 (如音频与 DTMF) 或发生切换, 可能需在 FB 内显式携带载荷类型. 适用于所有载荷专用与应用层 FB; 具体 FB 规范须定义如何携带载荷类型.

本文档定义两种传输层与三种 (视频) 载荷专用 FB 及一种应用层容器. 更多传输层与载荷专用 FB MAY 在其他文档定义, 且 MUST 经 IANA 注册 (见第 9 节).

6.1. 反馈消息公共分组格式​

所有 FB MUST 采用图 3 所示公共格式:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|   FMT   |       PT      |          length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of packet sender                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  SSRC of media source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Feedback Control Information (FCI)                 |
|                                                               |

        Figure 3: Common Packet Format for Feedback Messages

V, P, SSRC, length 见 RTP 规范 [1], 含义概述如下:

version (V): 2 比特, RTP 版本, 当前为 2.

padding (P): 1 比特, 置位表示末尾有填充八位组, 计入 length 但不属控制信息.

Feedback message type (FMT): 5 比特, 标识 FB 类型, 相对传输层/载荷专用/应用层反馈解释, 取值见各节.

Payload type (PT): 8 比特, RTCP 分组类型. IANA 定义:

NameValueBrief Description
RTPFB205Transport layer FB message
PSFB206Payload-specific FB message

Length: 16 比特, 以 32 比特字为单位的分组长度减一, 含首部与填充, 与 SR/RR [1] 一致.

SSRC of packet sender: 32 比特, 本分组发起者的同步源标识.

SSRC of media source: 32 比特, 本反馈所关联媒体源的 SSRC.

FCI: 变长, 后文三节分别规定各类反馈可含信息. 更多 FCI MAY 在后续文档规定.

每个 RTCP 反馈分组 FCI 中 MUST 至少含一条 FB. 第 6.2 与 6.3 节分别说明各 FCI 类型是否可将多条 FB 压入同一 FCI; 若可, 须同类型 (同 FMT). 多种 FMT MUST 生成多条 RTCP FB, SHOULD 在同一复合 RTCP 中拼接.

6.2. 传输层反馈消息​

传输层 FB 的 RTCP 消息类型值为 RTPFB.

本文档定义一种通用传输层 FB: Generic NACK, 由 FMT 标识:

  • 0: 未分配
  • 1: Generic NACK
  • 2--30: 未分配
  • 31: 保留扩展

下节定义该类型的 FCI. 将来 MAY 定义更多通用反馈.

6.2.1. Generic NACK​

PT=RTPFB 且 FMT=1.

FCI MUST 至少含一条, MAY 含多条 Generic NACK.

用于指示丢失的一个或多个 RTP 包, 以包标识与位掩码表示.

若底层传输已能提供类似反馈 (如 DCCP), Generic NACK feedback SHOULD NOT 使用.

FCI 语法见图 4:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            PID                |             BLP               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Syntax for the Generic NACK message

PID: 16 比特, 丢失包的 RTP 序号.

BLP: 16 比特, 紧随 PID 所指包之后的 16 个 RTP 包的丢失位图, 定义同 [6]. 最低位为 bit 1, 最高为 bit 16; bit i 为 1 表示未收到序号 (PID+i) (mod 2^16) 并报告丢失. 发送端 MUST NOT 因某位为 0 就推断接收端已收到对应包.

FB 消息 length MUST 设为 2+n, n 为 FCI 中 Generic NACK 条数.

Generic NACK 通过序号隐式关联载荷类型.

6.3. 载荷专用反馈消息​

载荷专用 FB 的 RTCP 类型为 PSFB.

目前已定义三种载荷专用 FB 加一种应用层 FB, FMT 如下:

ValueMeaning
0未分配
1Picture Loss Indication (PLI)
2Slice Loss Indication (SLI)
3Reference Picture Selection Indication (RPSI)
4-14未分配
15Application layer FB (AFB)
16-30未分配
31保留扩展

以下各节定义载荷专用 FCI; 第 6.4 节定义应用层 FCI.

6.3.1. Picture Loss Indication (PLI)​

PT=PSFB, FMT=1. FCI 中 MUST 恰好一条 PLI.

6.3.1.1. 语义​

解码器告知编码器丢失未指明数量的、属于一幅或多幅图像的编码视频数据. 与基于帧间预测的视频编码联用时, 收到 PLI 的编码器可知预测链可能断裂. 发送端 MAY 以帧内图像响应 (效果类似 [6] 的 FIR), 但 MUST 考虑第 7 节拥塞控制, MAY 限制发帧内能力.

RFC 2032 [6] 等已为部分编解码定义反馈. 同时支持两种机制的应用在发送反馈时 MUST 使用本文机制; 为兼容 SHOULD 仍能接收并按该载荷格式要求响应旧机制.

6.3.1.2. 消息格式​

PLI 无参数. length MUST 为 2, MUST 无 FCI. 语义与载荷类型无关.

6.3.1.3. 时序规则​

遵循第 3 节. 若同时使用 PLI 与其他反馈, 对 PLI 可采用 Regular RTCP RR 时序, 因 PLI 对延迟不如其他类型敏感.

6.3.1.4. 说明​

PLI 常触发完整帧内图像, 其体积通常数倍于帧间图像且与生成时刻无关. 带宽受限时, 帧内往往意味着数倍帧周期的时延. 例如 10 fps 且帧内约为帧间 10 倍, 则约接受 1 秒时延. 此类场景下 FB 不必极短延迟; 按 [2] 且 Tmin=0 的 RTCP 时隙等待不致损害性能.

6.3.2. Slice Loss Indication (SLI)​

PT=PSFB, FMT=2. FCI MUST 至少一条, MAY 多条.

6.3.2.1. 语义​

解码器告知编码器在扫描顺序下丢失或损坏一个或多个连续宏块. MUST NOT 用于宏块大小非均匀且可动态变化的编解码 (如启用 Annex Q 的 H.263), 因此时编码器未必能定位损坏区域.

6.3.2.2. 格式​

见图 6. length MUST 为 2+n, n 为 SLI 条数.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            First        |        Number           | PictureID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Syntax of the Slice Loss Indication (SLI)

First: 13 比特, 首个丢失宏块地址; 左上为 1, 光栅扫描递增.

Number: 13 比特, 丢失宏块数 (同上扫描顺序).

PictureID: 6 比特, 引用图像的编解码专用标识的最低 6 位; 许多编解码中与 Temporal Reference 相同.

适用编解码集较小, 故不提供显式载荷类型.

6.3.2.3. 时序规则​

SLI 若不及时发送, 相关算法效率大降; 运动补偿会扩散未报告的损坏像素. 强烈推荐使用第 3 节算法.

6.3.2.4. 说明​

此处 Slice 含义同 MPEG-1: 扫描顺序上连续的宏块. 新标准中 Slice 含义可能不同. H.263(1998) 有 "矩形 slice" 等, 丢一块矩形 slice 可能需多条 SLI 才能精确标区域.

FCI 中首宏块编号从 1 起 (非 0), 为与 ITU-T H.245 [24] 对齐. 最大宏块数 2**13=8192 覆盖多数 ITU/ISO 视频编解码. 若将来图像更大或宏块更小需另定义 FB. Temporal Reference 低 6 位足以指示丢失所在图像.

对 SLI 的反应不在本文规定; 常见做法是对受影响区域做帧内刷新.

有算法跟踪运动补偿影响区域以发帧内宏块, 与 FB 时序关系较弱 (见 H.263(2000) 附录 I [17], [15]); 但此类算法在 FB 延迟时会修正大块区域, 数据量更大.

6.3.3. Reference Picture Selection Indication (RPSI)​

PT=PSFB, FMT=3. FCI 中 MUST 恰好一条 RPSI.

6.3.3.1. 语义​

MPEG-4 visual v2 [16], H.263 v2 [17] 等允许预测编码使用非最近参考帧; 通常维护 FIFO 参考队列. 编码器若知编解码失步, 可选用已知正确的旧参考帧, 预测码流比特更多.

MPEG-4 与 H.263 为 RPSI "载荷" 定义二进制格式, 含损坏图像时间 ID 与区域大小等; 通常位数少, 变长且自包含.

二者亦允许 RPSI 携带肯定反馈. 多方会话中 MUST NOT 使用任何形式的肯定反馈 (在 RTCP 间隔报告各参考帧的肯定反馈本也无大用).

6.3.3.2. 格式​

见图 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PB       |0| Payload Type|    Native RPSI bit string     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   defined per codec          ...                | Padding (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Syntax of the Reference Picture Selection Indication (RPSI)

PB: 8 比特, 将 RPSI 长度填到 32 比特边界所需填充位数.

0: 1 比特, 发送 MUST 为 0, 接收忽略.

Payload Type: 7 比特, 解释 native RPSI 位串时的 RTP 载荷类型.

Native RPSI bit string: 变长, 视频编解码原生 RPSI.

Padding: #PB 比特, 填零至下一 32 比特边界, 位数由 PB 指示.

6.3.3.3. 时序规则​

RPSI 对延迟比 SLI 更敏感: 消息越旧, 编码器恢复同步所需比特越多, 见 [15]. 通常应尽快发送, 使用第 3 节算法.

6.4. 应用层反馈消息​

PT=PSFB, FMT=15, 为载荷专用的特例. FCI 中 MUST 恰好一条应用层 FB, 除非应用层结构自身允许堆叠 (固定长度或显式长度).

用于承载应用定义数据. 载荷不由 FB 标识, 应用 MUST 能识别消息内容.

例如 MPEG-4 的 NEWPRED [16] (RFC 3016 [23] RTP 承载), H.263 Annex N/U [17] (RFC 2429 [14]). 通常不需 RTCP 额外信息, 直接将应用消息放入 FCI 并设 length.

Application Message (FCI): 变长, 格式由应用决定. 若未 32 比特对齐 MUST 加填充; 如何识别填充由应用层规定.

应用层 FB 规范 MUST 规定是否须在特定编解码 (RTP 载荷类型) 上下文中解释. 若需要载荷类型, 规范 MUST 在应用层 FB 自身内定义携带方式.

最后于 更新