PACC: RTC 下基于用户感知的拥塞控制

由于网络的波动，拥塞控制对于保证实时通信（RTC）用户的体验质量（QoE）是必不可少的。这个组件调整媒体数据的发送速率，从而决定了视频编码的码率。然而，现有的控制方案要么只关注网络数值指标，要么不能适应各种网络环境。因而，我们在本文针对 RTC 提出了基于感知的拥塞控制（PACC: Perception-Aware Congestion Control）。利用卷积神经网络（CNN），我们开发了一个质量评估模型来预测视频质量。借助于用户感知的变化趋势分析，PACC 将朝着更好的 QoE 方向去调整码率。大量的实验证明了 PACC 的有效性，它在传输层和应用层的 QoE 指标方面分别比现有的方案高出 8.2% 至 32.4% 和 6.8% 至 18.0%。

论文题目：PACC: Perception Aware Congestion Control for Real-time Communication
来源：ICME 2023
作者：Feng Peng, Bingcong Lu, Li Song, Rong Xie, Yanmei Liu, Ying Chen
内容整理: 彭峰
本项工作为“上海交通大学电子信息与电气工程学院-淘宝(中国)软件有限公司媒体计算联合实验室”的合作研究成果。

介绍

正如思科公司所报告的那样，实时通信（RTC）服务在当今的网络环境中已经占据了举足轻重的地位。此外，对 RTC 的需求也在不断增加，包括会议、电子商务、云游戏、体育直播等多种应用。在具有各种特性的复杂网络环境中，为了使 RTC 用户获得满意的体验质量（QoE），设计一种拥塞控制方案来自适应地调整视频编码比特率已经成为一项基本挑战。为了解决这个问题，人们提出了大量的控制方案，从启发式方法到基于学习的方法都有。基于丢包的方法，如 TCP Reno 和 TCP Cubic 在数据包丢失之前不会停止增加速率，这导致了明显的延迟。TCP Vegas 设置了一个往返时间（RTT）阈值，以确定信道是否使用不足，LEDBAT 测量单向延迟，以估计未使用的带宽容量。基于模型的算法如 GCC 和 Rebera 根据反馈信息评估带宽，包括 RTT、接收速率、丢包率等。一般来说，这些方案只在网络数值指标的指导下调整速率，不考虑用户的感受。

在深度学习浪潮的推动下，一些方法利用强化学习（RL）来调整速率，部署以 QoE 为导向的奖励函数。例如，QARC 和 CLCC 旨在获得高视频质量而不是高码率。为了提高基于 RL 的方法的稳健性，混合方案如 Orca 和 HRCC 应用 RL-Agent 来定期调整启发式拥塞控制方案的输出速率，Bob 和 Gemini 采用不同的技术在基于RL的方案和启发式算法之间切换。即使设计得很好，但这些方法仍然存在与 RL 训练模拟环境和真实世界之间的差距有关的脆弱性，或者在训练阶段从未遇到的陌生场景中容易出现严重的传输质量下降。

在本文中，我们提出了 PACC（Perception Aware CongestionControl），它通过对排队延迟的变化趋势分析，将速率向更好的QoE方向调整。在每个决策时段，PACC通过计算用户对延迟的接受程度和视频质量的感知趋势来决定速率调整的方向。然而，评估视频质量趋势需要估计视频质量相对于码率的增长速度，这在 RTC 场景下是具有挑战性的。为了克服这个问题，我们利用强大的深度卷积神经网络（CNN）来设计感知视频质量评估模型（PVQS）。在多个具有不同视频场景的数据集上进行训练，PVQS 实现了令人印象深刻的质量增加率预测精度。此外，受益于轻量级属性，PVQS 能够应用于实时应用。我们在一个真实的视频系统中实现了 PACC，并对它与基于模型、混合和基于 RL 的算法进行了评估。在各种网络 trace 上进行的实验说明了 PACC 的有效性。详细来说，PACC 在传输层指标上实现了 8.2%-32.4% 的 QoE 改善，在应用层指标上实现了 6.8%-18.0% 的 QoE 改善。

观察和动机

在这一节中，我们首先设计实验来说明 RTC 场景中的两个观察，为说明我们的动机打下基础。

观察 1：带宽利用率是排队延迟的非递减函数。在 RTC 场景中，主要的传输数据是相机定期捕获的编码帧，因此，并不像传统的文件传输那样总是有数据等待发送。由于网络带宽的变化和编码帧大小的不稳定，网络空闲期存在，如图 1 所示。在这种情况下，增加视频编码的比特率可以缩短空闲期，从而提高带宽利用率，同时会产生增长的排队延迟。

PACC: RTC 下基于用户感知的拥塞控制 | ICME 2023 — 图 1 实时视频传输特点

我们根据 WebRTC 的 pacing 机制，开发了一个测试平台。在收集了现实世界的网络 trace 后，测试平台模拟了在某一网络 trace 上的一组编码比特率下的编码视频的传输。图 2 显示了所有 trace 的带宽利用率波动范围以及平均、最小和最大带宽利用率。如图所示，带宽利用率随着排队延时的增加而提高，并且是一个非递减函数。

观察 2：感知视频质量是编码比特率的非递减函数，而视频质量变化情况对于不同内容的视频是不同的。通过采用视频多方法评估融合（VMAF）作为评估方法，我们建立了另一个测试平台来评估特定编解码器在给定码率下的感观视频质量得分。我们通过不同编解码器下不同内容的视频片段的 VMAF-码率曲线来证明这一观察。图 3 展示了 H.264 编解码器的情况，我们分别选择了卡通、风景和运动三个视频片段，实验结果可以用观察 2 来概括。

动机：在带宽有限的网络中，实现更高的带宽利用率就等于提高了接收速率和视频质量。同时，根据 ITU-T G.114，用户对延迟的接受程度与网络延迟成反比。因此，在用户接受度和感知视频质量之间，存在着相反变化趋势。用户倾向于平衡视频质量和延迟。例如，如果视频质量足够高，而延时分别很高，用户倾向于牺牲一些视频质量来减少延时。相反，如果有冗余的网络带宽而视频质量相对较差，用户可以在可接受的范围内忍受延迟的增加以换取质量的提高。这种直观的推理带来了我们探索的问题的动机。能否设计一个直接朝着更好 QoE 方向的控制方案？

PACC 架构

系统简述

在每个决策区间，PACC 从收到的帧和网络信息中估计出感知视频质量和用户对延迟的接受程度的变化趋势。通过一个数字趋势值 T，PACC 朝着更好的 QoE 方向调整码率。为了说明 T 的细节，我们分别用r、d 和 l 表示接收速率（Mbps）、排队延迟（ms）和丢包率。接收速率是排队延时的一个非递减函数，用 r=f(d) 表示，感知视频质量得分用 q=h(r) 计算，p=g(d) 表示用户对延时的接受程度。

其中，α 决定了用户对延迟的接受程度和用户对视频质量的感知程度的权重，β 将丢包率归一化为一致范围的系数。在我们的工作中，α 和 β 被设定为10。

控制算法

如图 4 中的蓝色部分，我们在 AlphaRTC 平台中实现了 PACC，这是谷歌 WebRTC 的一个分支。在发送端，视频流被编码，然后被打包成 RTP 流。在每个时间间隔（本工作中为 200ms），根据接收方控制器汇总的信息，PACC 取代 GCC 来调整比特率，如图 5 算法所示。之后，速率通过 RTCP 包被送回给发送端，由其决定视频编码码率。

Perceptual Video Quality Sensor

直接计算视频质量变化趋势 h^‘(r) 需要获取质量随码率变化曲线，这在 RTC 场景下是很困难的。受 CNN 在视频质量评估中应用的启发，我们开发了 PVQS 来推断 h^‘(r)。在实践中，我们使用两个比特率点，质量变化率为 20VMAF/Mbps（图 3 中红色点 b1 表示）和 2VMAF/Mbps（图 3 中绿色点 b2 表示），将质量增加率分为三个等级。PVQS 预测当前视频处于哪个级别，并将 h^‘(r) 视为 30、10 和 1VMAF/Mbps，即 b<b1，b1≤b≤b2，以及 b>b2。我们使用迁移学习来训练 PVQS，其架构如图 6 所示。

我们首先尝试建立一个端到端的模型。然而，由于性能不佳和缺乏可解释性，我们选择开发基于感知视频质量维度的 PVQS。正如在 ITU-T Rec. P.918 中所述，块状和模糊是 RTC 场景中广泛存在的两个质量损失维度，例如低编码比特率和上采样的损害。在我们的工作中，我们选择了 DenseNet-121 架构来提取块状和模糊的特征。选择 DenseNet-121 的另一个原因是其轻量级的优势，这使得 PVQS 可以应用于实时系统中。首先，我们将 DenseNet-121 转换为回归任务，将最后一层替换为一个输出的全连接层。使用大量具有 VMAF 得分的帧，我们裁剪大小为 299×299 的非重叠图像块作为输入，并将预测目标设定为加权块 VMAF 得分，表示如下：

其次，DenseNet-121 的最后一个 Dense 块在一个小型的图像数据集上进行了两次微调，该数据集含有对块效应和模糊程度的主观评分。

最后，根据用户更有可能看视频帧的中心，PVQS 从每一帧裁剪四个中心的和不重叠的图片块，并与精心设计的 DenseNet-121 并行提取特征。为了训练分类器，我们使用从两个公共视频质量数据集 LIVE-NFLX-II 和 MCML 的源视频中获得的 720P 视频来生成数据集。这些源视频包含很多不同类型的内容，如游戏、体育、卡通、运动等。在 LIVE-NFLX-II 上训练分类器并在 MCML 上测试，PVQS 在帧级预测上达到了 93.4% 的准确率。在实践中，PVQS 在一个决策区间内随机选择三帧，并使用平均预测值作为视频质量变化率。

为什么是分类而不是回归？一方面，对质量增长率的连续和准确估计需要一个更强大的模型，这意味着更多的参数和计算资源的消耗。另一方面，网络和视频内容是不断变化的，精确的计算并不能带来很大的性能提升。

验证

验证设置

我们采用 Mahimahi 作为网络仿真器。通过改变传播延迟、链路速率、丢包率和排队策略，Mahimahi 模拟了各种网络环境。此外，在 Linux 中通过 TUN/TAP 接口发送真实的数据包，使 Mahimahi 比其他模拟器更接近真实世界的网络。在实验中，我们采用从真实世界观察到的 LTE trace 和模拟其他网络环境的生成 trace。表 I 总结了这些 trace 的特点。两种 trace 都采用了随机的队列长度为 10-600 个数据包，并使用 tail-drop 队列管理机制。

对比算法：我们将 PACC 与基于不同机制的三种方案进行比较：

GCC：一种基于模型的方法，是 WebRTC 框架的默认控制方案；
HRCC：采用启发式拥塞控制方案来输出速率估计，由 RL-Agent 定期调整；
CLCC：使用 RL 架构，旨在追求高视频质量而不是高码率。

QoE度量：我们采用两个 QoE 函数作为我们的指标来评估方案的性能。第一个是 ACM MMSys’21 Grand Challenge 的网络得如下：

结果分析

我们使用MCML的 30 帧和 720P 的视频，并在相同的环境下对每种算法进行了总共 240 次和 6 小时的实验。图 7 和图 8 中总结了一般的性能。图 9 是归一化 QoE 得分的详细CDF。我们观察到，（1）在所有的网络条件和QoE指标下，PACC 都优于三个竞争方案。特别是，PACC 在 LTE traces 获得的 QoE 增益为 (12.2,7.5), (4.5, 6.0) 和 (3.7,4.2) 与 HRCC、GCC、CLCC 相比；在生成的 traces 上 PACC 获得了(17.1,12.2)、(4.4, 4.5) 和 (4.8,3.7) 的增益。此外，图 7(d) 和图 8(d) 显示了 PACC 获得更高的带宽利用率，排队延时的增加可以忽略不计。(2) 竞争方案并没有在所有的 QoE 分数中实现高性能。例如，最接近的方案 HRCC 与 PACC 相比，在丢包分数上有接近的表现，但在接收速率、质量和丢帧分数上分别只达到了 PACC 的 74.0%、92.5% 和93.7%。

图 10 显示了一个 90 秒会话的码率调整的展示。我们发现PACC是稳定的，并能迅速调整。相反，HRCC 没有取得可观的性能；GCC 有时过度使用带宽，恢复缓慢；CLCC 缺乏稳定性，这意味着质量波动较大。

消融实验：我们通过一个消融实验进一步证明 PVQS 的功能。为了进行公平的比较，我们只修改了质量传感器，而其他部分保持不变。(a)随机传感器(RS) 使用一个随机分类器来取代 PVQS 的分类器。(b)精确传感器(PS) 获得质量增加率的精确值，因为实验中的源视频序列是可以访问的，但在真实场景中是不可能的。(c ) PACC 的基于 CNN 的 PVQS。在相同的 2.5 小时网络 trace 下，结果如表 2 所示，这表明 PVQS 实现了与 PS 接近的性能，正如我们在前文节中所解释的。