本文设计了一种新的实时视频流传输方法Reparo,旨在提高用户在低速网络中的QoE。在上传客户端方面,Reparo 丢弃视频帧,使其不会被编码或传输。为了决定应该丢弃哪些帧,我们设计了一个实时视频帧丢弃(VFD)模型,该模型旨在在最大程度减少对视频质量的影响的同时最大化带宽节省。为了补充这一点,Reparo 进一步提出了一种修改后的自适应比特率算法和两种编码模式,针对低帧率编码。在服务器端,Reparo 然后使用轻量级视频帧插值深度神经网络(VFI-DNN)恢复被丢弃的帧。实验结果表明,与普通的DASH相比,Reparo 的 SSIM 增益为0.018,或将带宽消耗降低了30.86%。在平均带宽为0.974Mbps的情况下,与DASH相比,它平均提高了18.13%的QoE。
标题:Reparo: QoE-Aware Live Video Streaming in low-rate Networks by Intelligent Frame Recovery
作者:Fulin Wang Qing Li Wanxin Shi
团队:清华,鹏城,腾讯云
来源:MM 2023
链接: https://dl.acm.org/doi/10.1145/3581783.3613441
内容整理:李江龙
引言
动机
实时视频流传输中,从上传客户端到媒体服务器的上行带宽通常是不足的。因此,上传客户端可能需要以更低的比特率对高质量的视频帧进行编码,从而降低用户的QoE。为解决这个问题,已经有一些方案被提出:
- 空间域:发端降采样,收端超分。这种方案存在的问题是低速网络中表现不佳。
- 时间域:发端丢帧,收端插帧。这种方案存在的问题是:最近的研究BETA和VOXEL,为点播流设计,丢帧策略耗时长,不能实时。
因此本文提出了Reparo,一种通过策略性丢弃视频帧来增强视频传输的新型实时视频流传输系统。部署在上传客户端和服务器上。Reparo步骤如下:
- 在上传客户端上,我们提取相邻帧之间的差异,并将其输入到一个视频帧丢弃(VFD)模型中。该模型确定其两个相邻帧之间的中间帧是否应该被丢弃。
- 选择要丢弃的帧后,上传客户端使用ABR算法确定编码比特率,然后选择适当的低帧率编码模式。Reparo提出了两种模式,称为Hbit和BWSave,根据网络条件在两者之间切换。Hbit模式旨在提高视频的每帧比特率,同时保持类似的上行带宽开销,而BWSave模式旨在节省上行带宽而不带来严重的质量降低。
- 在服务器端,视频帧解码后,运行基于DNN的插值,并且进行VFD模型的更新。
- 更新的VFD模型发送回上传客户端。
挑战
对于发端丢帧,收端插帧方案,挑战在于:
- 上传客户端要能实时预测帧丢弃对视频质量的影响,要求轻量级的VFD模型
- 无法预先评估不同低帧率编码模式(Hbit和BWSave)的实时影响
- 预训练的VFD模型性能会随着视频内容的变化而衰减,需要在服务器端实时更新,如何在服务器端生成用于更新VFD的数据集
贡献
本方案的贡献如下:
- 实施和评估了Reparo。
- 我们提出了一个轻量级的VFD模型。
- 提出了两种编码模式,以更好地匹配所选比特率和预测带宽。这两种模式分别带来了0.018的SSIM增益和30.86%的带宽节省比率。它们使QoE相对于基线提高了9.28%至18.13%。
- Reparo实时推断VFI-DNN以恢复丢弃的帧,并为计算能力有限提供了更少层的VFI-DNN。
- 提出了一种机制,使用服务器上接收到的不完整帧以在线方式更新VFD模型。这导致两种模式分别获得了额外的22.96%的质量增益和46.53%的带宽节省。
系统架构
Reparo架构由上传客户端和服务器组成:
- 上传客户端:帧丢弃器+视频编码器,上传低帧率视频。
- 媒体服务器:视频帧插值+VFD训练,回传 VFD 模型。
上传客户端设计
帧丢弃器
选择最优的帧进行丢弃,它计算帧差异特征来衡量场景变化。然后,它使用这些特征构建一个二元分类器,以估计服务器的VFI-DNN有效性。
- 帧丢弃器目标:努力选择可以通过服务器的VFI-DNN有效恢复的帧。
- 只在偶数帧中进行丢弃。
具体步骤:
- 提取帧差异特征(只提取奇数帧)。
包括四个低级特征:像素差异、边缘差异、区域差异和灰度直方图差异。
- 测量插值效果。
提取特征之后,测量VFI-DNN的性能下降是否可接受。使用SSIM值进行评估,原始帧作为参考。设置了一个0.97的SSIM阈值。 - 确定要丢弃的帧,训练一个二元分类器来选择要丢弃的帧。分类器的目标是预测一个被丢弃的帧是否可以被VFI-DNN恢复,同时达到最小的SSIM阈值。
VFD模型设计与训练:
- 一个轻量级的多层感知器模型(即,2层),来表示 VFD 二元分类器,可在客户端实时运行。
- 选择了相同直播频道最近(即,前 5 分钟)的视频来离线预训练 VFD 模型。
视频编码器
视频编码器的作用是在帧丢弃后选择最佳编码比特率。ABR选择比特率级别之后,reparo从两种编码模式Hbit 和 BWSave中选一个进行编码。
- 比特率级别选择
ABR算法MPC用于点播流,依赖于即将到来的视频块的大小和质量、历史网络带宽以及其他因素来选择最佳的比特率级别。为了应用于实时视频流,Reparo 修改了 MPC 算法,通过使用每个比特率级别的平均大小和质量来替代未来视频块的信息。 - 编码模式调整
由于实时约束,Reparo 只能从有限的级别中选择编码比特率。这可能导致所选的比特率级别与预测的上行带宽之间存在差距。如果预测的带宽高于比特率级别,则用Hbit;反之用BWsave。
媒体服务器设计
VFI processer
VFI processer 实现了 VFI-DNN,将解码后的低帧率视频块恢复到它们原始的 25fps 帧率。仅支持480p和720p,插帧算法 base 了AdaCoF。
文中测试了VFI-DNN 对不同计算资源的支持:
VFD Trainer
作用是根据视频内容的变化更新 VFD 模型,以维持帧丢弃策略的性能。工作流程如下:
- 获取更新的数据集:重新训练基于服务器端接收到的不完整帧序列。
- 更新 VFD 模型并将其发送到客户端 得到训练数据之后,对给定数据进行三次迭代以更新 VFD 模型。然后,它每 3 秒将更新的模型发送回上传客户端,这是可行的,因为通常服务器到上传客户端的下行带宽是充裕的。
实验设计与验证
评估设置
测试平台
测试平台基于Intel® Xeon® Gold 5218 CPU @ 2.30GHz和NVIDIA GeForce RTX 2080 Super GPU,对客户端没有提供GPU资源。
模型训练
- VFI-DNN :在vimeo-triplet数据集上进行训练的,类似于AdaCoF,泛化能力良好,不需要在线更新。
- VFD:两个隐藏层,大小分别为100和10。其大小仅为30KB,可以在智能手机上进行推断,推断时间为10-50ms。
评估视频
- 六种不同类型的1080p视频片段,来自YouTube和Twitch。
- 至少持续10分钟,首先将它们转码为1080p分辨率,使用H.264软件编解码器,比特率为4.8Mbps,帧率为25fps。视频的前5分钟用于训练VFD模型,而剩余部分用于视频流模拟。
- 对于每个视频,我们为编码比特率选择算法提供了七种不同的比特率。分辨率设置为从240p到1080p
网络trace
为了模拟上行带宽,我们使用了一个4G上行数据集,其中包含123个trace,平均带宽为0.617Mbps,以及来自FCC 2019数据集的105个trace,平均带宽为1.391Mbps。需要注意的是,从FCC选取的105个trace是基于平均带宽低于2Mbps的标准进行选择的。这两种类型的trace一起具有0.974Mbps的平均值,并可用于模拟带宽受限的环境。
QoE计算
使用Pensieve提出的线性QoE模型, 综合考虑视频质量,视频卡顿以及视频质量震荡,其中 μ 设置为 4.3:
Baseline
- DASH:上传客户端使用DASH比特率自适应算法确定原始视频帧的比特率,不使用任何帧丢弃或插值方法。
- Reparo-g:上传客户端使用预训练的通用VFD模型丢弃视频帧,并使用VFI-DNN进行恢复。Hbit和BWSave模式分别表示为Hbit_ge和BWSave_ge。
- BETA-Live 和VOXEL-Live:上传客户端对每个GOP(Group of Pictures)进行一次编码以获得时间编码顺序。然后,提供了额外的选择,即丢弃前50%的不重要帧(对于BETA-Live是B帧,对于VOXEL是P帧和B帧)以节省带宽,供编码比特率选择算法使用。
- 仅VFI:上传客户端丢弃所有偶数索引帧,并利用VFI-DNN来重建这些丢失的帧。
- 仅VFD:上传客户端利用我们的VFD模型识别可能被丢弃的帧,但是这些帧被简单地替换为其前面的最后一帧。
实验结果
- 使用 SSIM、带宽节省比例和 QoE 作为我们的评估指标。
- SSIM、带宽节省比例被分别用于评估 Reparo 的两种固定编码模式。
- QoE 是根据实际网络条件选择编码模式的结果。
通过图 5,图 6得出以下结论:
- 与普通的 DASH 流媒体相比Hbit 模式获得了 0.018 的 SSIM,相当于 41.27%-56.11% 的比特率改善,而 BWsave 模式平均节省了 30.86% 的带宽。
- 使用更新的 VFD 模型的 Reparo 达到了 22.96% 的质量改善和比使用通用 VFD 模型多出 46.53% 的带宽节省。
- Reparo 的 BWsave 模式在质量和带宽开销方面优于 BETA-Live。
通过图7,图8得出以下结论:
- 在 DASH 上实现了 18.13% 的整体 QoE 增益,
- 在 VOXEL-Live 上实现了 13.26% 的整体 QoE 增益,
- 在 BETA-Live 上实现了 9.28% 的整体 QoE 增益,
- 在 Reparo-g 上实现了 3.3% 的整体 QoE 增益。
表 2 和表 3 展示了 Reparo 的客户端以及服务器端的延迟性能,满足实时性要求。
版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。