AFR: Enabling High Quality Real-Time Communications with Adaptive Frame-Rate

太网络传输了, 与笔者研究方向关联过低, ai过一遍, 权当了解些其他领域的背景知识

(1) 研究背景与问题发现

• 新兴的高质量实时通信 (如云游戏, 虚拟现实等) 正在向超高清 (UHD) 和高帧率 (HFR) 发展
• 边缘计算技术的应用显著降低了网络传输延迟, 这使得客户端解码器队列的排队延迟成为影响尾部延迟 (Tail Latency) 和用户体验的主要瓶颈
• 高帧率缩短了帧到达的间隔时间, 而超高清分辨率增加了每帧的解码耗时
• 这两种因素的结合导致帧的到达率经常超过解码器的处理率, 从而引发严重的队列堆积和高延迟

(2) 面临的核心挑战

• 传统的控制回路通常依赖 测量当前的队列长度或排队延迟, 但这种反馈信号具有滞后性, 无法满足超低延迟的要求
• 导致队列堆积的瞬态原因非常复杂, 可能是网络数据包的突发到达, 也可能源于解码器的短暂卡顿
• 对于不同的堆积原因, 系统需要采取完全不同的应对动作, 不能一味地降低帧率

(3) 解决方案: 自适应帧率 (AFR) 控制器

作者提出了一种分层设计的 AFR 控制器, 通过在编码端动态调整帧率来缓解解码器的压力

• 稳态控制器 (Stationary Controller):
  • 通过持续测量帧的到达过程和解码服务过程
  • 利用 Kingman 公式预测期望的排队延迟, 从而前瞻性地计算出最佳的目标帧率
• 异常值过滤 (Outlier Removal):
  • 稳态控制器中引入了基于先验知识的过滤机制, 剔除因突发卡顿造成的解码延迟异常点, 以保证稳态预测的准确性
• 瞬态控制器 (Transient Controller):
  • 针对突发的队列堆积, 通过观测队首帧在队列中的逗留时间来区分网络突发与解码器卡顿
  • 当确认为解码器卡顿造成的堆积时, 瞬态控制器会计算一个折扣因子, 进一步快速压低输出帧率, 从而及时清空队列

Introduction

高质量 RTC 的发展趋势与严苛要求:

随着 5G 等网络技术的发展, 云游戏, VR 和 4K 视频会议等新兴的高质量实时通信 (RTC) 应用正在迅速普及.

这类应用不仅追求超高清 (UHD) 和高帧率 (HFR), 对延迟的要求也极为苛刻 (例如云游戏通常要求尾部端到端延迟低于 100ms).

新出现的性能瓶颈: 解码器队列堆积:

在传统的标准画质 RTC 中, 解码速度很快, 解码器队列通常不会成为瓶颈, 系统只需根据网络带宽调整码率即可.

然而在高质量 RTC 中, 高帧率使得帧的到达间隔缩短, 超高分辨率又显著增加了每一帧的解码耗时.

当帧的到达率超过解码器的处理率时, 就会导致严重的队列堆积 (Figure 1)

基于真实生产环境的测量发现:

作者对腾讯 Start 云游戏平台的测量发现, 解码器排队延迟已成为导致尾部高延迟的核心因素.

在所有端到端延迟超过 100ms 的视频帧中, 有 57% 的帧在解码器队列中滞留了超过 50ms.

因此, 仅仅匹配网络带宽是不够的, 系统必须对解码器的排队延迟进行干预.

解决方案: 自适应帧率 (AFR) 控制器:

并非所有干预手段都有效 (比如调整码率无法改善解码延迟, 而调整分辨率或丢帧则会产生较大的带宽开销和额外延迟).

因此, 论文提出了一种自适应帧率 (AFR) 控制器. 通过在编码端降低帧率, 可以为解码器争取更多的处理时间, 从而有效缩短队列长度.

AFR 解决的两大关键挑战:

1. 反馈滞后: 传统依靠测量队列长度或排队延迟的机制反应太慢 (需要等队列堆积起来才发现)
   • AFR 改为综合测量帧的到达和服务过程, 以实现更及时的前瞻性控制
2. 堆积成因复杂: 并非所有排队现象都需要降低帧率 (例如, 仅仅是网络数据包的短暂突发到达)
   • AFR 设计了两个在不同时间尺度上运行的控制回路, 以此来针对不同的堆积原因采取正确的行动

Background: High-Quality RTC

High-quality RTC applications are attracting attention from the industry and academia. A series of high-quality RTC products have been released recently, including cloud gaming [3, 1, 5], virtual reality (VR) [12, 11, 6], and 4K videoconferencing [8]. For example, by generating high-quality content and streaming to the user via Internet, users can enjoy better video quality with low-cost devices. Specifically, the high-quality RTC has the following features standing out from traditional RTC applications:

• High frame-rate. Traditional RTC usually delivers content with a low frame rate (LFR) of 24fps [9]. However, high-quality RTC requires a frame rate of up to 60fps, some of which even require a frame-rate of 240fps [73].

• High resolution. Most existing RTC applications are delivered at SD resolutions by default (e.g., 360p for Google Meet [7]). In contrast, high-quality RTC applications require a resolution of 1080p to 4K or higher [62]. • Stringent delay requirement. Furthermore, high-quality RTC applications also have stringent latency requirements. For example, videoconferencing requires a round-trip interaction delay of 150ms [9] and gaming for 100ms [43].

Existing delivery pipeline. To better understand the bottleneck of high-quality RTC, we present the key components of the existing RTC delivery pipeline in Figure 2. First, the video encoder captures the contents generated from video sources (e.g., gaming applications [23, 57]) and encodes them into video frames. Then, encoded frames are sent over the network from the streaming server to user clients. After that, on the client side, upon receiving new frames from the network, the decoder will decode those frames. Finally, decoded video frames will be displayed on users’ displays.

Optimization goal: low tail delay. With the intelligence from each community, the delay of each component has been intensively optimized in recent research efforts. To reduce the network delay, existing providers either deploy stream servers at the edge [57, 74], introduce low-latency congestion controllers [16, 25], or suggest users use wired connections. For example, recent measurements unveil that cloud gaming services could deliver the RTC streams with an average round-trip network delay of 20ms [57, 26]. Similarly, streaming encoders are optimized for low latency to satisfy the stringent delay requirements in high-quality RTC services [58, 69, 34].

Meanwhile, optimizing the tail performance is also critical for user’s experience for high-quality RTC [56]. The increase in tail delay will result in frame stuttering or freezing, degrading the user’s experience. Quality of experience assessment frameworks in video streaming usually individually calculate the stuttering time as a penalty to the user’s experience [33, 80]. Considering the high frame rate of high-quality RTC, further tails of 99th or 99.9th percentiles need to be focused on. For example, at the frame rate of 60fps, even the 99.9th percentile delay could happen every 16 seconds. Especially for applications such as cloud gaming, such a delay might lead to the loss of the game (e.g., stalls when the gamer is discovered by the opponent in a shooting game) [67, 43]. Therefore, it is essential to control the tail delay and reduce frame stutters for high-quality RTC.

(1) 高质量 RTC 的特征与要求

云游戏, VR 和 4K 视频会议等高质量 RTC 应用正受到学术界和工业界的广泛关注.

与传统 RTC 相比, 高质量 RTC 具有以下三个显著特征:

• 高帧率 (HFR): 传统 RTC 通常为 24fps 的低帧率, 而高质量 RTC 需要高达 60fps, 部分应用甚至要求 240fps
• 高分辨率 (UHD): 大多数现有 RTC 默认以标清分辨率交付 (例如 360p), 而高质量 RTC 则要求 1080p 到 4K 或更高的分辨率
• 严苛的延迟要求: 例如视频会议要求 150ms 的交互延迟, 而云游戏的要求更是严苛到 100ms

(2) 现有的传输流水线

如 Figure 2 所示, 一个通用的 RTC 交付流程主要包含:

1. 视频编码器捕获视频源并编码
2. 编码后的帧通过网络从服务器发送到用户客户端
3. 客户端接收新帧后, 将其放入解码器队列并进行解码
4. 最终显示在用户的屏幕上

图中用红色高亮标出了造成高质量 RTC 端到端尾部延迟 (Tail Delay) 的主要组件!

(3) 核心优化目标: 极低的尾部延迟

• 目前, 网络和编码等组件的延迟已被大幅优化
  • 例如, 通过部署边缘计算服务器和低延迟拥塞控制器, 云游戏服务的平均网络往返延迟可降至 20ms
  • 视频编码器也进行了低延迟优化以满足严苛要求
• 对于高质量 RTC 而言, 优化尾部 (如 99% 或 99.9% 分位数) 性能对用户体验至关重要
  • 尾部延迟的增加会导致帧卡顿或冻结, 严重降低用户体验 (例如, 在射击类云游戏中可能导致玩家输掉比赛)
  • 因此, 控制尾部延迟并减少帧卡顿 对于高质量 RTC 来说必不可少