跳到主要内容

4. RTCP 接收方报告扩展

本文档规定了六种新的反馈消息. 完全帧内请求 (Full Intra Request, FIR), 时空权衡请求 (Temporal-Spatial Trade-off Request, TSTR), 时空权衡通知 (Temporal-Spatial Trade-off Notification, TSTN) 和视频后向信道消息 (Video Back Channel Message, VBCM) 是 AVPF [RFC4585] 第 6.3 节定义的 "Payload Specific Feedback Messages". 临时最大媒体流比特率请求 (Temporary Maximum Media Stream Bit Rate Request, TMMBR) 和临时最大媒体流比特率通知 (Temporary Maximum Media Stream Bit Rate Notification, TMMBN) 是 AVPF 第 6.2 节定义的 "Transport Layer Feedback Messages".

以下小节定义这些新的反馈消息, 其结构与 AVPF 规范 [RFC4585] 第 6.2 节和第 6.3 节类似.

4.1. 扩展机制的设计原则​

RTCP 最初作为一种通道引入, 用于传达在线状态, 接收质量统计信息以及期望媒体编码的提示. 早期面向视频格式的 RTP 载荷格式引入了一组有限的媒体控制机制, 例如 RFC 2032 [RFC2032] 中的机制, 该 RFC 后来被 RFC 4587 [RFC4587] 废止. 然而, 本规范首次建议对其中某些消息使用双向握手. 这种引入存在被误解的风险, 即被视为使用 RTCP 作为 RTP 会话控制协议的先例. 为避免这种误解, 本小节试图阐明本文档所规定扩展的范围, 并强烈建议未来扩展遵循这里说明的理由, 或者有说服力地解释为何偏离这些理由.

本文档以及 AVPF [RFC4585] 中只包含满足以下条件的消息:

a) 具有相对严格的实时性约束, 因而在大多数应用场景中无法使用 SIP re-invite 等机制. 必要时, 每种消息都会单独说明其实时性约束;

b) 对组播是安全的, 因为在每种消息需要时, 都规定了对可能相互矛盾的反馈消息的反应; 并且

c) 与某个媒体编解码器, 某类媒体编解码器, 例如视频编解码器, 或某个给定 RTP 分组流的活动直接相关.

本文档只为满足以下条件的消息引入双向握手:

a) 由于消息自身性质而需要通知或确认. 对于每种消息, 都已单独分析是否存在此需求.

b) 该通知或确认无法轻易从媒体比特流中推导出来.

AVPF [RFC4585] 和本文档中的所有消息都以简单且固定的二进制格式呈现其内容. 这适合那些没有在媒体路径中实现更高层控制协议功能, 如 SDP, XML 解析器等的媒体接收方.

不符合上述设计原则的消息, 并不是对 RTCP 或本文档定义的编解码器控制框架 (Codec Control Framework) 的适当使用.

4.2. 传输层反馈消息​

如 RFC 4585 [RFC4585] 第 6.1 节所规定, 传输层反馈消息由 RTCP 分组类型值 RTPFB (205) 标识.

AVPF 已经定义了此类别中的一种消息. 本文档又规定了两种此类消息. 它们通过反馈消息类型 (Feedback Message Type, FMT) 参数标识如下:

在 AVPF [RFC4585] 中分配:

  • 1: 通用 NACK (Generic NACK)
  • 31: 保留用于将来扩展标识符编号空间

在本文档中分配:

  • 2: 保留 (见下方注释)

  • 3: 临时最大媒体流比特率请求 (Temporary Maximum Media Stream Bit Rate Request, TMMBR)

  • 4: 临时最大媒体流比特率通知 (Temporary Maximum Media Stream Bit Rate Notification, TMMBN)

    注: AVPF [RFC4585] 的早期版本曾将 FMT=2 保留给一个后来被移除的码点. 有人指出, 现场可能存在按照已过期文档使用该值的实现. 由于可用编号空间充足, 我们将 FMT=2 标记为保留, 以避免与这些早期实现发生可能的互操作问题.

可供分配:

  • 0: 未分配
  • 5-30: 未分配

以下小节分别定义 TMMBR 和 TMMBN 消息的反馈控制信息 (Feedback Control Information, FCI) 条目格式, 并规定媒体发送方和接收方的相关行为.

4.2.1. 临时最大媒体流比特率请求 (TMMBR)​

临时最大媒体流比特率请求由 RTCP 分组类型值 PT=RTPFB 和 FMT=3 标识.

临时最大媒体流比特率请求 (TMMBR) 消息的 FCI 字段必须包含一个或多个 FCI 条目.

4.2.1.1. 消息格式​

反馈控制信息 (FCI) 由一个或多个 TMMBR FCI 条目组成, 其语法如下:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 2 - TMMBR 消息中 FCI 条目的语法

  • SSRC (32 bits): 被请求遵守新最大比特率的媒体发送方的 SSRC 值.

  • MxTBR Exp (6 bits): 最大总媒体比特率值尾数的指数缩放. 该值是无符号整数 [0..63].

  • MxTBR Mantissa (17 bits): 最大总媒体比特率值的尾数, 表示为无符号整数.

  • Measured Overhead (9 bits): 测得的平均分组开销值, 以字节为单位. 测量必须按照第 4.2.1.2 节的描述执行. 该值是无符号整数 [0..511].

最大总媒体比特率 (MxTBR) 值以 bit/s 为单位, 由 MxTBR 指数 (exp) 和尾数按如下方式计算:

MxTBR = mantissa * 2^exp

这允许在 0 到 1310722^63, 约 1.210^24, 的范围内提供 17 bit 分辨率.

TMMBR 反馈消息的长度必须设置为 2+2*N, 其中 N 是 TMMBR FCI 条目的数量.

4.2.1.2. 语义​

媒体接收方的行为 (TMMBR 的发送方)

TMMBR 用于指示作为媒体接收方的报告实体处存在与传输相关的限制. TMMBR 采用包含两个分量的元组形式. 第一个值是在接收方选择的协议层上, 接收方当前在此 RTP 会话中可支持的每个媒体流发送方的最高比特率. 第二个值是按第 2.2 节定义, 在所选协议层上对该流接收分组测得的头部开销, 单位为字节. 开销测量是一个运行平均值, 对该特定媒体源 (SSRC) 的每个接收分组按以下公式更新:

avg_OH (new) = 15/16*avg_OH (old) + 1/16*pckt_OH,

其中 avg_OH 是运行的指数平滑平均值, pckt_OH 是最新分组中观察到的开销.

如果已经通过信令协商了最大比特率, 则接收方在 TMMBR 消息中报告的最大总媒体比特率禁止超过换算到共同基准后的协商值, 即调整开销后使其位于同一参考协议层.

在反馈消息的公共分组头部中, 如 [RFC4585] 第 6.1 节所定义, "SSRC of packet sender" 字段指示请求的来源, "SSRC of media source" 不使用且必须设置为 0. 在某个 TMMBR FCI 条目中, FCI 字段内的 "SSRC of media source" 表示该元组适用的媒体发送方. 这在组播或转换器拓扑中很有用, 因为报告实体可以在单个 TMMBR 消息中使用多个 FCI 条目来寻址所有媒体发送方.

媒体接收方必须保存从每个媒体发送方收到的最新 TMMBN 消息内容.

在以下情况下, 媒体接收方可以向特定媒体发送方发送 TMMBR FCI 条目:

  • 尚未从该媒体发送方收到任何 TMMBN 消息时;

  • 媒体接收方已在从该媒体发送方收到的最新 TMMBN 消息中被标识为某个边界元组的来源, 且与该媒体发送方相关的最大总媒体比特率或开销值已经变化时;

  • 媒体接收方未在从该媒体发送方收到的最新 TMMBN 消息中被标识为边界元组的来源, 并且在媒体接收方应用第 3.5.4.2 节的增量算法或更严格的等效算法后, 与该媒体发送方相关的媒体接收方元组被判定属于边界集合时.

如果在发送下一个 RTCP 分组时尚未从媒体发送方收到临时最大媒体流比特率通知 (TMMBN) FCI, 则可以在后续 TMMBR 消息中重复 TMMBR FCI 条目. TMMBR FCI 条目的比特率值可以在不同 TMMBR 消息之间改变. 每次发送该条目时, 开销测量值必须更新为 avg_OH 的当前值.

如果预期 TMMBR 消息设置的值是永久性的, 则设置 TMMBR 的一方应当使用会话建立信令重新协商会话参数以反映这一点, 例如使用 SIP re-invite.

媒体发送方的行为 (TMMBR 的接收方)

当媒体发送方收到包含与自身相关 FCI 条目的 TMMBR 消息时, 必须根据新信息使用适用的初始算法或增量算法来确定元组的边界集合. 所使用的算法必须至少与第 3.5.4.2 节定义的相应算法一样严格. 媒体发送方可以在一个较短间隔内, 相对于 RTCP 发送间隔而言, 累积 TMMBR 后再进行此计算.

一旦确定了元组的边界集合, 媒体发送方可以在这些元组描述的可行区域内使用任意分组速率和净媒体比特率组合, 以产生更低的总媒体流比特率, 因为它可能需要处理拥塞状况或其他限制因素. 更多讨论见第 5 节, 拥塞控制.

如果媒体发送方得出结论认为可以增加最大总媒体比特率值, 则在实际增加之前必须等待一段足够长的时间, 以便媒体接收方在判定自身元组属于边界集合时能够对 TMMBN 作出响应. 该延迟周期按以下公式估计:

2 * RTT + T_Dither_Max,

其中 RTT 是媒体发送方已知的最长往返时间, T_Dither_Max 在 [RFC4585] 第 3.4 节中定义. 即使在点到点会话中, 媒体发送方也必须遵守上述规则, 因为不能保证参与者能够正确判断所有源是否共置于单个节点中并受到协调.

媒体发送方必须在尽可能早的时间发送 TMMBN 消息, 以响应自上次发送 TMMBN 以来收到的任何 TMMBR 消息. TMMBN 消息指示在发送该消息时计算出的边界元组集合及这些元组的拥有者.

SSRC 可以按照 RTP 会话参与者的默认规则超时, 即媒体发送方在最近五个常规报告间隔内未从该拥有者收到任何 RTP 或 RTCP 分组. SSRC 也可以显式离开会话, 参与者通过发送 RTCP BYE 分组或使用外部信令通道来指示这一点. 如果媒体发送方确定边界集合中某个元组的拥有者已经离开会话, 则媒体发送方必须发送新的 TMMBN, 其中包含先前确定的边界元组集合, 但移除属于已离开拥有者的元组.

当媒体发送方知道其传输路径比当前限制更严格时, 可以主动向自身发起等效于 TMMBR 消息的操作. 其结果是发送一个 TMMBN, 指示媒体源本身是某个元组的拥有者, 从而避免其他参与者发送不必要的 TMMBR 消息. 但是, 与任何其他参与者一样, 当媒体发送方获知限制发生变化时, 它需要更改该元组并发送相应的 TMMBN.

讨论

由于 TMMBR 和 TMMBN 的传输具有不可靠性, 上述规则可能导致发送看起来违反这些规则的 TMMBR 消息. 此外, 在组播场景中, 可能会有多个 "非拥有者" 会话参与者正确或错误地判定自身元组属于边界集合. 基于以下原因, 这并不严重:

a) 如果 TMMBR 消息在传输中丢失, 媒体发送方要么响应某个其他媒体接收方而发送新的 TMMBN 消息, 要么根本不发送新的 TMMBN 消息. 在第一种情况下, 媒体接收方应用增量算法, 并且如果判定自身元组应当属于边界集合, 就发送另一个 TMMBR. 在第二种情况下, 它会无条件重复发送 TMMBR. 无论哪种情况, 媒体发送方最终都会获得所需信息.

b) 类似地, 如果 TMMBN 消息丢失, 发送相应 TMMBR 的媒体接收方不会收到通知, 并预期会重新发送请求, 从而触发另一个 TMMBN 的传输.

c) 如果不同会话参与者发送多个相互竞争的 TMMBR 消息, 则可以在考虑所有这些消息的情况下应用算法, 所生成的 TMMBN 会向参与者提供其元组与边界集合相比的更新视图.

d) 如果多个会话参与者碰巧同时发送具有相同元组分量值的 TMMBR 消息, 则将其中哪个元组纳入边界集合并不重要. 未被选中的会话参与者会在应用算法后判定自身元组未进入边界集合, 因而停止发送其 TMMBR.

考虑伪造 TMMBR 所涉及的安全风险非常重要. 见第 6 节的安全考虑事项.

如前所述, 这些反馈消息可在任何指定拓扑中的组播和单播会话中使用. 然而, 对于拥有大量参与者的会话, 按照此机制要求使用最低共同能力, 可能并不是最合适的做法. 大型会话可能需要考虑其他方式来使比特率适应参与者能力, 例如将会话划分为不同质量层级, 或使用其他方法实现比特率可伸缩性.

4.2.1.3. 定时规则​

当需要及时性时, TMMBR 消息的首次传输可以使用早期反馈或立即反馈. 请求消息的任何重复发送都应当使用常规 RTCP 模式作为其传输定时.

4.2.1.4. 转换器和混合器中的处理​

媒体转换器和混合器需要接收并响应 TMMBR 消息, 因为它们是向接收方提供某个媒体流的链路的一部分. 混合器或转换器可以在本地处理 TMMBR, 并因此生成 TMMBN 来指示它已完成处理. 或者, 对于媒体转换器, 它可以转发该请求; 对于混合器, 它可以自行生成请求并向前传递. 在后一种情况下, 混合器需要向原始请求方发送 TMMBN, 以指示它正在处理该请求.

4.2.2. 临时最大媒体流比特率通知 (TMMBN)​

临时最大媒体流比特率通知由 RTCP 分组类型值 PT=RTPFB 和 FMT=4 标识.

TMMBN 反馈消息的 FCI 字段可以包含零个, 一个或多个 TMMBN FCI 条目.

4.2.2.1. 消息格式​

反馈控制信息 (FCI) 由零个, 一个或多个 TMMBN FCI 条目组成, 其语法如下:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MxTBR Exp |  MxTBR Mantissa                 |Measured Overhead|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 3 - TMMBN 消息中 FCI 条目的语法

  • SSRC (32 bits): 此元组 "拥有者" 的 SSRC 值.

  • MxTBR Exp (6 bits): 最大总媒体比特率值尾数的指数缩放. 该值是无符号整数 [0..63].

  • MxTBR Mantissa (17 bits): 最大总媒体比特率值的尾数, 表示为无符号整数.

  • Measured Overhead (9 bits): 测得的平均分组开销值, 以字节为单位, 表示为无符号整数 [0..511].

因此, TMMBN 消息中的 FCI 包含指示边界元组的条目. 对于每个元组, 条目先通过 SSRC 给出拥有者, 随后给出适用的最大总媒体比特率和开销值.

TMMBN 消息的长度必须设置为 2+2*N, 其中 N 是 TMMBN FCI 条目的数量.

4.2.2.2. 语义​

此反馈消息用于通知任何 TMMBR 消息的发送方, 已经收到一个或多个 TMMBR 消息, 或者某个拥有者已经离开会话. 它向所有参与者指示当前边界元组集合以及这些元组的 "拥有者".

在反馈消息的公共分组头部中, 如 [RFC4585] 第 6.1 节所定义, "SSRC of packet sender" 字段指示通知的来源. "SSRC of media source" 不使用且必须设置为 0.

在收到带有标识此媒体发送方的 FCI 条目的 TMMBR 消息后, 必须调度发送 TMMBN 消息. 即使在调度发送和实际发送 TMMBN 消息之间收到多个 TMMBR 消息, 也只能发送一个 TMMBN. TMMBN 消息指示发送该消息时的边界元组及其拥有者. 所包含的边界元组必须是通过应用第 3.5.4.2 节的适用算法或等效算法得到的集合, 该算法应用于先前的边界集合, 如果存在, 以及自上次发送 TMMBN 以来在 TMMBR 消息中收到的元组.

即使在应用算法后新报告的 TMMBR 元组未被接受进入边界集合, 收到 TMMBR 消息仍然必须导致发送 TMMBN 消息. 在这种情况下, 边界元组及其拥有者不会改变, 除非该 TMMBR 来自先前计算的边界集合中某个元组的拥有者. 此过程允许未看到上一条 TMMBN 消息的会话参与者获得此媒体发送方状态的正确视图.

如第 4.2.1.2 节所述, 当媒体发送方确定某个边界元组的 "拥有者" 已经离开会话时, 该元组会从边界集合中移除, 且媒体发送方必须发送 TMMBN 消息来指示剩余的边界元组. 如果没有剩余的边界元组, 则必须发送不带任何 FCI 的 TMMBN 来指示这一点. 在没有剩余边界元组的情况下, 如果会话信令中协商了最大媒体比特率和最大分组速率, 则适用这些值.

注: 如果会话中仍有任何媒体接收方, 最后一种情况将只是临时状态. 空 TMMBN 会使每个剩余媒体接收方判定其限制属于边界集合, 并因此发送 TMMBR.

在单播场景中, 即单个发送方与单个接收方通信时, 上述确定拥有权的算法会退化为: 媒体接收方一旦发出第一个 TMMBR 消息, 就成为唯一边界元组的 "拥有者".

4.2.2.3. 定时规则​

TMMBN 确认应当在会话所应用定时规则允许的最早时间发送. 这些消息应当使用立即反馈或早期反馈模式.

4.2.2.4. 转换器和混合器中的处理​

如第 4.2.1.4 节所讨论, 混合器或转换器可能需要针对其处理的 SSRC, 发出 TMMBN 消息作为对 TMMBR 消息的响应.

4.3. 载荷特定反馈消息​

如 RFC 4585 [RFC4585] 第 6.1 节所规定, 载荷特定反馈 (Payload-Specific FB) 消息由 RTCP 分组类型值 PSFB (206) 标识. AVPF [RFC4585] 定义了三种载荷特定反馈消息和一种应用层反馈消息. 本文档规定了另外四种载荷特定反馈消息. 所有这些消息均通过 FMT 参数标识如下:

在 [RFC4585] 中分配:

  • 1: 图像丢失指示 (Picture Loss Indication, PLI)
  • 2: 片丢失指示 (Slice Lost Indication, SLI)
  • 3: 参考图像选择指示 (Reference Picture Selection Indication, RPSI)
  • 15: 应用层 FB 消息 (Application layer FB message)
  • 31: 保留用于将来扩展编号空间

在本文档中分配:

  • 4: 完全帧内请求命令 (Full Intra Request, FIR)
  • 5: 时空权衡请求 (Temporal-Spatial Trade-off Request, TSTR)
  • 6: 时空权衡通知 (Temporal-Spatial Trade-off Notification, TSTN)
  • 7: 视频后向信道消息 (Video Back Channel Message, VBCM)

未分配:

  • 0: 未分配
  • 8-14: 未分配
  • 16-30: 未分配

以下小节定义载荷特定反馈消息的新 FCI 格式.

4.3.1. 完全帧内请求 (FIR)​

FIR 消息由 RTCP 分组类型值 PT=PSFB 和 FMT=4 标识.

FCI 字段必须包含一个或多个 FIR 条目. 每个条目适用于一个不同的媒体发送方, 该发送方由其 SSRC 标识.

4.3.1.1. 消息格式​

完全帧内请求的反馈控制信息 (FCI) 由一个或多个 FCI 条目组成, 其内容如图 4 所示. FIR 反馈消息的长度必须设置为 2+2*N, 其中 N 是 FCI 条目的数量.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |    Reserved                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 4 - FIR 消息中 FCI 条目的语法

  • SSRC (32 bits): 被请求发送解码器刷新点的媒体发送方的 SSRC 值.

  • Seq nr. (8 bits): 命令序列号. 对于命令来源 SSRC 与命令目标 SSRC 的每个配对, 序列号空间都是唯一的. 每个新命令的序列号必须按模 256 增加 1. 重复发送禁止增加序列号. 初始值任意.

  • Reserved (24 bits): 发送方必须将所有 bit 设置为 0, 接收时必须忽略这些 bit.

此反馈消息的语义与 RTP 载荷类型无关.

4.3.1.2. 语义​

在反馈消息的公共分组头部中, 如 [RFC4585] 第 6.1 节所定义, "SSRC of packet sender" 字段指示请求的来源, "SSRC of media source" 不使用且必须设置为 0. FIR 命令适用的媒体发送方 SSRC 位于相应的 FCI 条目中. 一个 FIR 消息可以包含针对多个媒体发送方的请求, 每个目标媒体发送方使用一个 FCI 条目.

收到 FIR 后, 编码器必须尽快发送解码器刷新点, 见第 2.2 节.

发送方必须考虑第 5 节概述的拥塞控制, 这可能限制其快速发送解码器刷新点的能力.

禁止将 FIR 作为对图像丢失的反应来发送. 推荐改用 PLI [RFC4585]. FIR 应当仅在不发送解码器刷新点会导致用户无法使用视频的情况下使用.

发送 FIR 的典型适用示例是, 在多点会议中, 新用户加入会话且尚未建立常规解码器刷新点间隔. 另一个示例是进行流切换的视频切换 MCU. 在这种情况下, MCU 通常向新的发送方发出 FIR, 以强制其发出解码器刷新点. 解码器刷新点通常包含冻结图像释放 (Freeze Picture Release, 在本规范之外定义), 它会重新启动接收方的渲染过程. 上述两种技术都常用于基于 MCU 的多点会议.

其他 RTP 载荷规范, 如 RFC 2032 [RFC2032], 已经为某些编解码器定义了反馈机制. 支持两种方案的应用在发送反馈时必须使用本规范定义的反馈机制. 出于向后兼容原因, 如果相应 RTP 载荷格式要求, 这类应用还应当能够接收并响应该 RTP 载荷格式中定义的反馈方案.

4.3.1.3. 定时规则​

定时遵循 [RFC4585] 第 3 节概述的规则. FIR 命令可以与早期反馈或立即反馈一起使用. FIR 反馈消息可以重复发送. 如果使用立即反馈模式, 重复发送前应当至少等待一个 RTT. 在早期或常规 RTCP 模式下, 重复消息在下一个常规 RTCP 分组中发送.

4.3.1.4. 混合器和转换器中的 FIR 消息处理​

如果会话参与者针对某内容发出 FIR, 则对该内容执行媒体编码的媒体转换器或混合器负责处理该 FIR. 处理 FIR 的混合器不应原样转发该消息; 相反, 它应当自行发出 FIR.

4.3.1.5. 备注​

目前, 视频似乎是 FIR 唯一有用的应用, 因为它似乎是唯一广泛部署且高度依赖跨 RTP 分组边界媒体预测的 RTP 载荷. 然而, 对于与压缩视频共享基本属性的其他媒体类型, 即跨帧预测, 无论该媒体类型中的帧具体指什么, 也可以合理设想使用 FIR. 一个可能的示例是 MPEG-4 场景描述的动态更新. 建议此类媒体类型的载荷格式引用本规范和 AVPF [RFC4585] 中定义的 FIR 及其他消息类型, 而不是在载荷规范中创建类似机制. 载荷规范可能需要解释载荷特定术语如何映射到本文使用的以视频为中心的术语.

与视频编解码器结合使用时, FIR 消息通常触发发送完整帧内图像或 IDR 图像. 两者都比预测图像, 即帧间图像, 大数倍. 它们的大小与生成时间无关. 在大多数环境中, 尤其是在使用带宽受限链路时, 使用帧内图像意味着需要允许一个明显大于典型帧时长的延迟. 例如, 如果发送帧率为 10 fps, 并假设帧内图像是帧间图像的 10 倍大, 则必须接受整整一秒的时延. 在这种环境下, 发送 FIR 消息并不需要特别短的延迟. 因此, 按照 [RFC4585] 的 RTCP 定时规则等待下一个可能的时间槽, 不应对系统性能产生过大的负面影响.

从应用角度看, 强制规定完成发送解码器刷新点的最大延迟是有吸引力的, 但从拥塞控制角度看会带来问题. 上文提到的 "尽快" 看起来是一个合理折中.

在发送方无法控制编解码器的环境中, 例如流式传输预录制且预编码的内容时, 无法规定对该命令的反应. 发送方的一种合适反应是, 在视频比特流中向前跳到下一个解码器刷新点. 在其他场景中, 完全不响应该命令可能更可取, 例如向大型组播组进行流式传输时. 也可能存在其他反应. 在决定策略时, 发送方可以考虑接收组大小, FIR 消息发送方的 "重要性", 无论该特定应用如何定义 "重要性", 内容中解码器刷新点的频率等因素. 不过, 主要处理预编码内容的会话预期完全不使用 FIR.

图像丢失指示 (Picture Loss Indication) 与 FIR 的关系如下. 如 AVPF [RFC4585] 第 6.3.1 节所讨论, 图像丢失指示会告知解码器图像丢失, 因而编码器和解码器之间的参考图像可能不一致. 这种场景通常与正在进行的连接中的丢失有关. 在点到点场景中, 且没有高级错误恢复工具时, 编码器的一种可能选择是发送解码器刷新点. 但是, 还有其他选择. 一个示例是媒体发送方忽略 PLI, 因为嵌入式流冗余可能会在合理时间内修复重建图像. 相比之下, FIR 不给实时编码器留下其他选择, 必须发送解码器刷新点. 它不允许编码器考虑上述任何因素.

4.3.2. 时空权衡请求 (TSTR)​

TSTR 反馈消息由 RTCP 分组类型值 PT=PSFB 和 FMT=5 标识.

FCI 字段必须包含一个或多个 TSTR FCI 条目.

4.3.2.1. 消息格式​

时空权衡请求的 FCI 条目内容如图 5 所示. 反馈消息长度必须设置为 2+2*N, 其中 N 是所包含 FCI 条目的数量.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 5 - TSTR 消息中 FCI 条目的语法

  • SSRC (32 bits): 被请求应用 Index 中给定权衡值的媒体发送方的 SSRC.

  • Seq nr. (8 bits): 请求序列号. 对于请求来源 SSRC 与请求目标 SSRC 的配对, 序列号空间是唯一的. 每个新命令的序列号必须按模 256 增加 1. 重复发送禁止增加序列号. 初始值任意.

  • Reserved (19 bits): 发送方必须将所有 bit 设置为 0, 接收时必须忽略这些 bit.

  • Index (5 bits): 介于 0 到 31 之间的整数值, 指示所请求的相对权衡. 索引值 0 表示最高可能空间质量, 31 表示最高可能时间分辨率.

4.3.2.2. 语义​

解码器可以通过向编码器发送 TSTR 消息来建议时空权衡级别. 如果编码器能够调整其时空权衡, 则应当在后续图像编码中考虑收到的 TSTR 消息. 值 0 表示建议高空间质量, 值 31 表示建议高帧率. 从 0 到 31 的值递增, 单调地表示对更高帧率的期望. 索引值不对应空间质量或帧率的精确数值.

媒体发送方从不同媒体接收方收到多个 TSTR 消息时如何反应, 由实现自行决定. 所选择的权衡必须通过 TSTN 消息传达给媒体接收方.

在反馈消息的公共分组头部中, 如 [RFC4585] 第 6.1 节所定义, "SSRC of packet sender" 字段指示请求的来源, "SSRC of media source" 不使用且必须设置为 0. TSTR 适用的媒体发送方 SSRC 位于相应的 FCI 条目中.

一个 TSTR 消息可以包含针对多个媒体发送方的请求, 每个目标媒体发送方使用一个 FCI 条目.

4.3.2.3. 定时规则​

定时遵循 [RFC4585] 第 3 节概述的规则. 此请求消息不是时间关键的, 应当使用常规 RTCP 定时发送. 只有在已知用户界面需要快速反馈时, 才可以使用早期反馈或立即反馈定时发送该消息.

4.3.2.4. 混合器和转换器中的消息处理​

对发送给发出 TSTR 的会话参与者的内容进行编码的混合器或媒体转换器, 必须考虑该请求, 以确定是否可以通过更改自身编码参数来满足它. 无法满足该请求的媒体转换器可以将请求原样转发给媒体发送方. 为多个会话参与者编码的混合器, 在代表自身向媒体发送方生成 TSTR 之前, 需要考虑这些参与者的共同需求. 另见第 3.5.2 节的讨论.

4.3.2.5. 备注​

"空间质量" 一词并不一定指按重建视频所用像素数量衡量的分辨率. 实际上, 在大多数场景中, 视频分辨率在会话生命周期内保持不变. 但是, 所有视频压缩标准都有在给定分辨率下调整空间质量的方法, 这些方法通常受量化参数 (Quantizer Parameter, QP) 影响. 数值较低的 QP 会产生较好的重建图像质量, 而数值较高的 QP 会产生较粗糙的图像. 编码器对此请求的典型反应是更改其码率控制参数, 使用较低帧率和数值较低的平均 QP, 或者反过来. Index 值到帧率和 QP 的精确映射在此有意保持开放, 因为它取决于所采用的压缩标准, 空间分辨率, 内容, 比特率等因素.

4.3.3. 时空权衡通知 (TSTN)​

TSTN 消息由 RTCP 分组类型值 PT=PSFB 和 FMT=6 标识.

FCI 字段必须包含一个或多个 TSTN FCI 条目.

4.3.3.1. 消息格式​

时空权衡通知的 FCI 条目内容如图 6 所示. TSTN 消息长度必须设置为 2+2*N, 其中 N 是 FCI 条目的数量.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Seq nr.      |  Reserved                           | Index   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 6 - TSTN 的语法

  • SSRC (32 bits): 导致此通知的 TSTR 来源的 SSRC.

  • Seq nr. (8 bits): 正在确认的 TSTR 中的序列号值.

  • Reserved (19 bits): 发送方必须将所有 bit 设置为 0, 接收时必须忽略这些 bit.

  • Index (5 bits): 媒体发送方此后使用的权衡值.

资料性注释: 返回的权衡值 (Index) 可能不同于请求值, 例如媒体编码器无法调整其权衡时, 或使用预录制内容时.

4.3.3.2. 语义​

此反馈消息用于确认收到 TSTR. 对于收到的每个以该会话参与者为目标的 TSTR, 必须在 TSTN 反馈消息中发送一个 TSTN FCI 条目. 单个 TSTN 消息可以使用多个 FCI 条目确认多个请求. TSTN 消息所有 FCI 条目中包含的索引值必须相同. 为每个请求方包含一个 FCI, 可使每个请求实体判断媒体发送方已经收到该请求. 收到重复的 TSTR 时, 也必须发送该通知作为响应. 如果请求接收方从单个请求方收到具有多个不同序列号的 TSTR, 则它必须只响应具有最高模 256 序列号的请求. 注意, 由于字段回绕, 最高序列号可能是较小的整数值. [RFC3550] 附录 A.1 中有一种用于跟踪 RTP 分组最高已接收序列号的算法; 该算法可适配于此用途.

TSTN 必须包含作为该请求结果而将使用的时空权衡索引. 该索引不一定与请求的索引相同, 因为媒体发送方可能需要聚合来自多个请求会话参与者的请求. 它也可能有其他限制选择的策略或规则.

在反馈消息的公共分组头部中, 如 [RFC4585] 第 6.1 节所定义, "SSRC of packet sender" 字段指示通知的来源, "SSRC of media source" 不使用且必须设置为 0. 该通知适用的请求实体 SSRC 位于相应的 FCI 条目中.

4.3.3.3. 定时规则​

定时遵循 [RFC4585] 第 3 节概述的规则. 此确认消息不是极端时间关键的, 应当使用常规 RTCP 定时发送.

4.3.3.4. 混合器和转换器中的 TSTN 处理​

对 TSTR 采取动作的混合器或转换器也必须发送相应的 TSTN. 在其自身需要转发 TSTR 的情况下, 通知消息可能需要延迟到 TSTR 已得到响应之后.

4.3.3.5. 备注​

无.

4.3.4. H.271 视频后向信道消息 (VBCM)​

VBCM 由 RTCP 分组类型值 PT=PSFB 和 FMT=7 标识.

FCI 字段必须包含一个或多个 VBCM FCI 条目.

4.3.4.1. 消息格式​

VBCM 指示中 FCI 条目的语法如图 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SSRC                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr.       |0| Payload Type| Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    VBCM Octet String....      |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 7 - VBCM 中 FCI 条目的语法

  • SSRC (32 bits): 被请求指示其编码器对 VBCM 作出反应的媒体发送方的 SSRC 值.

  • Seq nr. (8 bits): 命令序列号. 对于命令来源 SSRC 与命令目标 SSRC 的配对, 序列号空间是唯一的. 每个新命令的序列号必须按模 256 增加 1. 重复发送禁止增加序列号. 初始值任意.

  • 0: 发送方必须设置为 0, 消息接收方不应对其采取动作.

  • Payload Type (7 bits): 必须据此解释 VBCM 比特流的 RTP 载荷类型.

  • Length (16 bits): VBCM 八位组串的长度, 以八位组为单位, 不包括任何填充八位组.

  • VBCM Octet String (variable length): 这是解码器生成的八位组串, 承载特定反馈子消息.

  • Padding (variable length): 设置为 0 的 bit, 用于补齐到 32 bit 边界.

4.3.4.2. 语义​

VBCM 指示的 "payload" 承载不同类型的编解码器特定反馈信息. 反馈信息类型可分类为 "状态报告", 例如指示某比特流已无错误接收, 或某个部分或完整图像或块已丢失, 或 "更新请求", 例如请求完全刷新比特流.

注: VBCM 子消息与 CCM/AVPF 反馈消息, 如 FIR, 之间可能存在重叠. 更多讨论请见第 3.5.3 节.

VBCM 中承载的不同反馈子消息类型由 [H.271] 中定义的 "payloadType" 指示. 为方便起见, 以下重列这些子消息类型. 在 ITU-T Rec. H.271 术语中, "payloadType" 指 H.271 消息的子类型, 不应与 RTP 载荷类型混淆.

表 2: H.271 消息类型 ("payloadTypes")

载荷类型 (Payload Type)消息内容 (Message Content)
0一个或多个未检测到比特流错误不匹配的图像
1一个或多个完全或部分丢失的图像
2一个完全或部分丢失图像中的一组块
3一个参数集的 CRC
4某一类型所有参数集的 CRC
5一个 "reset" 请求, 指示发送方应当完全刷新视频比特流, 如同此前未接收任何比特流数据
> 5保留供 ITU-T 将来使用

VBCM 的比特串或 "payload" 长度可变, 是自包含的, 并以可变长度二进制格式编码. 媒体发送方必须能够解析这种优化的二进制格式, 才能使用 VBCM.

每种不同类型的子消息, 由 payloadType 指示, 都可能根据所使用的编解码器具有不同语义.

在反馈消息的公共分组头部中, 如 [RFC4585] 第 6.1 节所定义, "SSRC of packet sender" 字段指示请求的来源, "SSRC of media source" 不使用且必须设置为 0. VBCM 适用的媒体发送方 SSRC 位于相应的 FCI 条目中. VBCM 的发送方可以向多个媒体发送方发送 H.271 消息, 也可以在同一个 VBCM 中向同一媒体发送方发送多个 H.271 消息.

4.3.4.3. 定时规则​

定时遵循 [RFC4585] 第 3 节概述的规则. 不同子消息类型在应使用的消息定时方面可能具有不同属性. 如果同一个反馈分组中包含若干不同类型, 则应遵循要求最严格的子消息类型的要求.

4.3.4.4. 混合器或转换器中的消息处理​

混合器或转换器中对 VBCM 的处理取决于子消息类型.

4.3.4.5. 备注​

关于 H.271 消息以及 AVPF [RFC4585] 和本文档中定义的具有类似功能消息的使用讨论, 请见第 3.5.3 节.

注: 关于此消息中是否需要 RTP 载荷类型字段, 曾有一些讨论. 如果同一会话中可能存在多个支持 VBCM 的 RTP 载荷类型, 且给定 VBCM 的语义会随载荷类型而变化, 则需要该字段. 例如, H.271 类型 0 消息中的图像标识机制在 H.263 和 H.264 之间存在根本差异, 尽管两者使用相同语法. 因此, 这里设置 payload 字段是合理的. 另有意见指出, 对于 TSTR 和 FIR 并不存在这种需求, 因为 TSTR 和 FIR 的语义要么定义得足够宽松, 要么足够通用, 可以适用于当前存在或可预见的所有视频载荷.

最后于 更新