3

声网 2020 实时大会后的弱网对抗实践

 2 years ago
source link: https://segmentfault.com/a/1190000040795456
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

声网 2020 实时大会后的弱网对抗实践

声网2020实时大会后的弱网对抗实践

基于 IP 的音视频传输是一种实时视频通话技术,经由 Internet 协议来达成音视频通话,以及多媒体会议。VoIP 可用于包括 VoIP 电话、智能手机、个人计算机在内的诸多互联网接入设备,通过蜂窝网络、Wi-Fi、同轴电缆、光纤等设备进行信令传输、音视频通话、发送短信,以及部分控制信息的传输。

一旦移动电话或者监控设备链接网络时,由于互联网的异构和各种媒介的传输效率的递减,必然出现网络传输中音视频数据包的丢失,因而直接影响用户的感官、以及主观体验。在 TCP 中有 ack 反馈进行验证包的完整性,而在 UDP 中增加 NACK 进行丢包的确认和判断,以及 RR 和 SR 相关的报告用于统计 RTT 相关数据。WebRTC 横空出世,以及自带的 JitterBuffer 和 NetEQ 的实现,让音视频 UDP 的传输有了足够的保证。

img

2020 年声网的 RTE 大会,有幸参与线上分享,学习到很多内容,其中音视频实时传输分会中提到的优化项,以及声网优化的结果对自己留下深刻印象。以下介绍一下当时看的 PPT,以及看完之后学习实时音视频之后针对性优化相关内容。

来自北京大学王选计算机所的张行功老师介绍《数据驱动的实时视频传输技术》一章节。在互联网兴旺的现在,实时视频无处不在,包括不限于视频会议、视频直播、VR/AR、360°全景视频、以及音视频监控,音视频通话等。

img

但是实时视频传输面对很多挑战,包括:网络限制、不同网络之间传输延迟、抖动比较大,网络切换或 4G 网络丢包比较严重,视频传输质量低,容易卡顿、马赛克、黑屏、绿屏等现象,直接影响用户体验。TCP 虽然可以解决一部分问题,但是对于网络敏感程度却有待加强,同时会有一定延迟,不利于实时传输。WebRTC 的兴起,可以解决大部分问题,包括基于丢包和时延的控制器,可以极大程度缓解。同时强化学习的引入进一步提高问题的解决能力。之后 BBR 模型对于传输提供很好的解决,包括低延迟和高带宽。但是仍然是基于 RTT 的模型,并没有公平性参考,适应性没有那么强。同时 BBR 是基于探测的方式,对于网络探测是滞后的。

而张老师团队提供的将数学模型与统计模型结合的 CC 提供了一个很好的思路。包括以公平性为目标函数的数学模型+无模型网络状态的统计模型结合,如下图所示:

img

该模型主要目标就是为了解决两个不可知和一个滞后的问题:包括用户不可知,网络状态不可知,以及网络状况反馈滞后。

img

学习借鉴相关经验之后,对我司产品进行了优化,主要包括以下几部分:

第一步完善测试环境。因为我司产品大部分条件下都是有线连接方式,而且有些是光纤介入,网络环境相对比较稳定。所以在 Android 和 linux 产品中增加支持 Traffic Control 命令的方式进行数据发送端的网络模拟。TC 可以支持丢包、网络抖动、延迟、带宽限制等多种方式,可以最大化接近实时网络环境,进一步提升实验室模拟的准确度和测试方法。为之后弱网优化提供更加健全、方便的测试手段,并且结合 TC 命令,完成测试 APP 的开发,可以结合命令进行随意设置,实现无开发经验的测试小姐姐也可以随心所欲的测试验证。

img

第二步提升弱网对抗技术。我司产品沿用比较早期的 WebRTC 版本,相对于最新的已经无法抗衡,但是为了稳定性,只能进行部分功能逐步优化,压测之后再上线,因此增加软件工程师的维护难度。我们学习最新的 BBR 模型,以及张老师提出的数据驱动网络模型,优化了网络探测的精度,同时开启 FEC 和 NACK 同时工作的机制,针对 JTB 中部分流程进行判断条件优化和更改,提升了处理效率。将原先公司 VGA 模式下 TC 设置 20%丢包率就卡顿无画面,提升到 720P TC 设置 30%可以流畅播放的体验改善。相关算法经过一个多月质量部压测已经上线,效果提升明显,得到用户的赞赏。在和竞争对手的正面 PK 中,由于我司产品弱网视频质量较好而赢得客户的合作机会,并且签署长期备忘录。

img

第三步 H264 编解码参数的调整。由于 H264 编码参数的不同,对于编码后码率的影响非常大,因此结合硬件厂商的支撑力度,以及软编软解的优化,我们对部分编解码参数进行了调整和优化,包括 CABAC 和 CAVLC 的选择(之前厂商提供的接口中就有,但是原先设计开发的大佬们没有用到这个参数),包括码率控制参数的调研和更改,包括 IDR 和 Intra-Refresh 参数的引进和优化,包括接下来要和厂商对接的 LRT 和 SRT(长短参考帧的适配)等。适当微调编解码参数,在不影响视频质量和用户主观感受前提下,可以把编码后的码率控制在最优的状态,对于条件较差的网络环境压力就减轻很多,从而最大程度上在源头上节省码率、提升编码质量,全力保障用户体验。

问题和目标

以上三部分内容是我们最近在做的优化和提升,但是相关内容对于丢包和延迟对抗还可以,但是抖动非常严重时,就无能为力了。由于我司产品 WIFI 模块能力受限(成本考量问题)导致 wifi 传输数据时,抖动非常厉害,而且有一定丢包率,该硬件性能直接导致我们研究的弱网对抗体系效果欠佳。除了更换更加稳定更加可靠的 wifi 模块之外,高抖动也是我们弱网对抗团队接下来要面对的挑战。

img

下一个研发周期,我们继续保持学习,钻研,认真查阅资料尝试深入理解张老师团队提出的数据驱动的相关模型;尝试结合自身设备环境和使用场景,形成自主研发的数据模型进行网络状况探测、拥塞控制和网络灵敏反馈体系,进一步提升 WiFi 和 4G 链接模式下更加可靠、高质量的视频传输,为公司产品的推广提供有力的保障。

路漫漫其修远兮,吾将上下而求索。实时音视频传输的弱网对抗是一个长期的过程,我们将勇于尝试,学习借鉴,不敢保证行业领先,但是提供完美的实时视频通话质量是我们团队的目标:毕竟明天取得所有成就都源于今天的不将就。

以上是自己的分享,随时欢迎和大家一起交流探讨,感兴趣的可以一键三联。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK