跳到主要内容

3. 动机

本节讨论不同视频和媒体控制消息的动机与用途. 视频控制消息已经讨论了很长时间, 并曾形成一份需求文档 [Basso]. 该文档已经过期, 但本文引用其中相关部分来说明动机和需求.

3.1. 用例​

拟议反馈消息有多种可能用途. 我们先查看 Basso 等人 [Basso] 提出的用例. 其中一些用例已重新表述, 并添加了注释.

  1. RTP video mixer 把多个已编码视频源组合成单个已编码视频流. 每次添加新视频源时, RTP mixer 都需要向该视频源请求一个 decoder refresh point, 以便在混合画面中由新视频源数据占据的空间区域上启动未受损的预测链.

  2. RTP video mixer 从会议参与者接收多个已编码 RTP 视频流, 并动态选择其中一个流纳入其输出 RTP 流. 在比特流发生切换时 (例如由语音激活或用户界面决定), mixer 会向远端源请求 decoder refresh point, 以避免把无关内容用作帧间图像预测的参考数据. 请求 decoder refresh point 后, video mixer 停止交付当前 RTP 流, 并监视新源的 RTP 流, 直到检测到属于 decoder refresh point 的数据. 此时, RTP mixer 开始把新选择的流转发给接收方.

  3. 应用需要向远端编码器指示期望的时间分辨率和空间分辨率折中已经变化. 例如, 一个用户可能偏好较高帧率和较低空间质量, 另一个用户可能偏好相反选择. 该选择也高度依赖内容. 许多现有视频会议系统在用户界面中提供选择机制, 通常是滑块形式. 该机制对点到点, 集中式多点和非集中式多点用法都有帮助.

  4. Basso 文档的用例 4 只适用于 AVPF [RFC4585] 中定义的 Picture Loss Indication (PLI), 因此本文不再重述.

  5. Basso 文档的用例 5 涉及一种称为 "freeze picture request" 的机制. 已经确认, 通过不可靠的前向 RTCP 信道发送 freeze picture request 存在问题. 因此, 本备忘录没有包含 freeze picture request, 也不再重述该用例讨论.

  6. video mixer 动态选择接收到的一个视频流发送给参与者, 并尝试向所有参与者提供尽可能高的比特率, 同时最小化流转码. 一种实现方式是使用各端点可接受且 mixer 所用呼叫准入方法也接受的最大比特率来建立会话. 通过把最大媒体流比特率降低到会话建立时协商值以下的命令, mixer 可以把端点发送的最大比特率降低到所有可接受比特率中的最低值. 随着端点加入和离开或网络拥塞导致最低可接受比特率变化, mixer 可以调整端点发送流的限制以匹配新值. 随后 mixer 请求新的最大比特率, 该值小于或等于特定媒体流在会话建立时协商的最大比特率, 远端端点可以用它实际支持的比特率响应.

Basso 等人描绘的图景覆盖了我们预见的大多数应用. 不过, 我们希望用另外两个用例扩展该列表:

  1. 当前部署的拥塞控制算法 (AIMD 和 TCP Friendly Rate Control (TFRC) [RFC3448]) 只要仍有数据要发送, 就会探测额外可用容量. 当拥塞控制算法以丢包作为拥塞指示时, 这种探测通常会因丢包和延迟增加导致媒体质量下降, 往往降到失真足以使媒体不可用的程度.

    在许多部署场景中, 尤其是蜂窝场景中, 瓶颈链路通常是最后一跳链路. 该蜂窝链路也常常具有某种 QoS 协商, 使蜂窝设备能够获知最后一跳上可用的最大比特率. 位于该链路之后的媒体接收方在大多数 (如果不是全部) 情况下, 至少可以计算出它当前接收的每个媒体流可用比特率的上界. 如何完成这一点属于实现细节, 本文不讨论. 向发送方指示各媒体流的最大可用比特率是有益的, 因为它可以防止发送方为该流探测超过已知硬限制的带宽. 对蜂窝或其他移动设备而言, 每个流的已知可用比特率 (从链路比特率推导) 可能由于切换到另一种传输技术, 因拥塞重新协商 QoS 等原因快速变化. 为了尽量减少服务中断, 需要快速收敛, 因而希望使用媒体路径信令.

  2. 通常在点到点会话中, 媒体发送方负责配置媒体流, 使其保持在可用路径带宽限制内. 但在某些点到点视频场景中, 让接收方进一步限制最大媒体比特率是有利的. 一个例子是接收方渲染能力下降, 例如 CPU 资源不足. 在这种情况下, 接收方可能希望通知发送方把媒体比特率降低到可处理的水平. 另一个例子是接收方想记录会话. 这种情况下, 接收方可能希望限制媒体速率, 使其不超过存储设备可靠写入速度.

3.2. 使用媒体路径​

为支持上述用例, 可以使用信令信道 (例如 SIP) 并重新协商媒体流定义. 但这有几个缺点.

第一, 通过信令信道重新协商参数可能较慢. 在某些控制协议 (如 H.323) 中, 拆除现有信道和建立新信道是不同阶段, 媒体播放可能出现 "gap".

第二, 控制信道使用的协议 (通常是 TCP) 不同于媒体路径 (通常是 UDP/RTP). 在许多拓扑中, 信令信道的 "路径" 与媒体路径不同. 如果存在 NAT-fw 等中间盒, 控制信道可能无法对媒体路径特征变化作出反应, 甚至可能并不知道媒体路径.

第三, 使用信令信道重新协商媒体参数通常较重.

因此, 在媒体路径中以轻量且快速的方式执行媒体控制是有利的.

3.3. 使用 AVPF​

对于反馈消息, 本文使用 AVPF profile [RFC4585]. 关于使用 RTCP 承载反馈消息的理由, 见 [RFC4585]. AVPF 提供了有效的 RTCP 包类型和操作模式来传输反馈消息.

3.3.1. 可靠性​

AVPF 不提供内建可靠性. 在组播中, 确认包, 重传和其他可靠性机制难以实现和使用.

对本文定义的消息, 我们选择一种依赖反馈消息发送方监视其接收流的设计. 如果反馈消息丢失, 或媒体发送方尚未对其采取行动, 反馈消息发送方 (例如媒体接收方) 将看不到修改后的 RTP 流这一预期反应. 在这种情况下, 反馈消息发送方应重新发送该消息. 此类重传间隔应遵守 AVPF timing rules. 但有些消息本身不需要可靠性 (notification), 另一些消息则通过重复发送来解决可靠性问题.

3.4. 组播​

本文定义的反馈消息主要面向点到点和集中式多点场景. 不过, 并不禁止在非集中式组播场景中使用它们. 但是, 在这些场景中使用这些消息时, 必须充分理解其影响.

在组播中, 媒体发送方向所有接收方发送同一个比特流. 如果某个接收方请求较低比特率或请求 intra picture, 满足该请求会影响会话中的所有其他接收方. 这可能并非期望结果.

此外, AVPF 要求组播会话中的所有 RTCP 包发送给所有参与者. 这意味着一个接收方发送的反馈消息会被所有其他接收方看到. 如果许多接收方同时发送相同消息, 可能造成反馈消息洪泛. AVPF timing rules 旨在防止此类洪泛, 但并非完美.

3.5. 反馈消息​

本节从高层描述本规范定义的反馈消息. 消息的正式定义见第 4 节.

3.5.1. 完全帧内请求 (Full Intra Request) 命令​

Full Intra Request (FIR) command 指示媒体发送方需要尽快发送 decoder refresh point (对视频而言是 Intra picture). 第 3.1 节中的用例 1 和 2 是该消息的主要驱动因素.

FIR 消息类似于 [RFC4585] 定义的 Picture Loss Indication (PLI) 消息. 但二者存在细微差别. PLI 用于接收方丢失部分数据并希望恢复画面时. 发送方可以选择发送 Intra picture, 或使用其他方式恢复画面, 例如如果知道接收方拥有哪些数据, 可以发送差分数据. 相比之下, FIR 是一种命令, 会强制发送方发送 decoder refresh point. 当接收方没有任何有效参考画面时, 例如 mixer 中切换流时, 这就是必要的.

3.5.1.1. 可靠性​

FIR 消息是命令. 如果它丢失, 视频会继续损坏或空白. 因此, FIR 消息发送方通常会重复发送该消息, 直到在接收流中看到 decoder refresh point. 这些重复发送适用 AVPF timing rules.

3.5.2. 时空权衡请求和通知 (Temporal-Spatial Trade-off Request and Notification)​

Temporal-Spatial Trade-off Request (TSTR) 和 Notification (TSTN) 消息允许媒体接收方指示其对时间分辨率 (帧率) 和空间分辨率 (图像质量) 折中的偏好. 这对应用例 3.

该折中用 0 到 31 的整数表示, 其中 0 表示最高空间质量 (并可能对应最低帧率), 31 表示最高帧率 (并可能对应最低空间质量).

TSTR 消息由接收方发送, 用于请求特定折中. TSTN 消息由发送方发送, 用于通知接收方当前折中设置, 或确认 TSTR.

3.5.2.1. 点到点​

在点到点场景中, 接收方发送 TSTR. 发送方通常调整其编码并发送 TSTN 进行确认.

3.5.2.2. 使用组播或 Translator 的点到多点​

在这些场景中, 多个接收方可能发送相互冲突的 TSTR 消息. 发送方必须决定如何反应. 例如, 它可以满足最高帧率请求, 或最高空间质量请求, 或取某种平均值. 然后发送方发送 TSTN, 告知所有接收方实际设置.

3.5.2.3. 使用 RTP Mixer 的点到多点​

Mixer 可以处理来自多个接收方的 TSTR 消息, 并可能为不同接收方生成不同流, 或聚合请求并向原始发送方发送单个 TSTR.

3.5.2.4. 可靠性​

TSTR 和 TSTN 分别是请求和通知. 如果 TSTR 丢失, 发送方不会改变折中. 接收方可以通过未收到 TSTN 或未看到流变化检测到这一点, 并重新发送 TSTR.

3.5.3. H.271 视频后向信道消息 (Video Back Channel Message)​

该消息允许在 RTCP 中承载 ITU-T H.271 video back channel message. 对使用 H.271 进行反馈的既有视频编解码器而言, 这很有用.

3.5.3.1. 可靠性​

VBCM 的可靠性取决于应用. 某些 H.271 消息可能需要可靠性, 而另一些不需要. 本文描述的机制不在 RTCP 层提供可靠性; 如有必要, 应用负责处理重传.

3.5.4. 临时最大媒体流比特率请求和通知 (Temporary Maximum Media Stream Bit Rate Request and Notification)​

Temporary Maximum Media Stream Bit Rate Request (TMMBR, 发音为 "timber") 和 Notification (TMMBN, 发音为 "tim-ben") 消息用于控制媒体流比特率. 这对应用例 6, 7 和 8.

TMMBR 是接收方向发送方提出的请求, 要求把媒体流比特率限制为某个值. TMMBN 是发送方向接收方发送的通知, 指示发送方当前遵守的最大比特率.

3.5.4.1. 使用 TMMBR 的媒体接收方行为​

接收方估计自己可以处理的最大比特率, 例如基于链路容量, 并发送包含该值的 TMMBR 消息.

3.5.4.2. 建立当前限制的算法​

发送方可能从多个接收方收到 TMMBR 消息. 它需要计算这些请求的 "bounding set". 基本上, 它需要找出所有接收方中的最低请求比特率 (或至少是它关注的接收方集合), 并把发送速率限制到该值. 该算法描述如何维护收到的 TMMBR 消息状态并计算当前限制.

3.5.4.3. 在基于 Mixer 的多点操作中使用 TMMBR​

Mixer 对向它发送的端点而言充当接收方, 对从它接收的端点而言充当发送方. 它可以使用 TMMBR 限制入站流速率, 并且必须遵守它向其发送的端点发来的 TMMBR 消息.

3.5.4.4. 使用组播或 Translator 的点到多点中使用 TMMBR​

在组播中, 发送方必须遵守接收方组中最低的请求比特率, 或使用其他策略.

3.5.4.5. 在点到点操作中使用 TMMBR​

简单情况是接收方请求限制, 发送方遵守.

3.5.4.6. 可靠性​

TMMBR 是请求. TMMBN 是通知, 也充当确认. 如果接收方发送 TMMBR 后未收到对应 TMMBN, 或未看到速率降低, 它会重新发送 TMMBR.

最后于 更新