1. 布景
当下社会,实时音视频通话已经成为人们生活、工作中重要的组成部分,如商务会谈、亲友聊天等。而在通话进程中,总会存在着这样那样的意外状况:或许你坐在奔驰的高铁上——信号时好时坏;又或许在会议途中离开办公室——网络从 wifi 切换到 4G……完成高质量的实时音视频通话需求建立一座无视距离连接人们的“桥梁”,而这座“桥梁”需求优秀的“基建技能”来确保网络传输的稳定性和可靠性。
网络传输链路上存在着许多不稳定的状况,形成所发出去的数据包呈现丢包、延时或许颤动。不稳定的原因有很多,两个通讯两边在物理空间上存在距离,传输进程经过很多设备的处理,中途存在线路硬件毛病、软件驱动限制、或许链路数据拥塞等状况,都会导致发送出去的数据包在接纳端没有办法收到或许推迟收到。
咱们能够经过一些简单根底的东西检测网络是否处于动摇状况,比方 ping 指令或许 Iperf 东西能够协助计算丢包、延时以及单向颤动。咱们用 ping 指令向一个远端的主机发送 ICMP 音讯,远端主机会对你进行应对,这个进程中假如你发送出去的 ICMP 音讯丢了,或许远端服务器应对的音讯丢了,在指令行界面上,对应的 icmp_seq 就会显示超时未收到,这种状况就直观地表现了丢包。
ping vs iPerf
带宽分配和冗余战略是弱网对立核心模块,随着算法的演进迭代,咱们能够确保线上大部分场景的优质音视频体会。关于一些小概率或特别场景,如突发网损、拥塞康复、PPT 翻页等,咱们还引入了多种冗余战略,来兼顾流畅、康复功率和低延时的需求。
2. 常用包康复技能
一般,一个数据包在网络传输链路中丢失了,主要有两种方法将包进行康复:一种是发送端使用接纳端告诉或许超时的机制,重新将这个包发送过来;另一种则是依据其他收到的冗余包,在接纳端将该包康复出来。
第一种是咱们熟知的自动重传恳求 ARQ 技能。与 TCP 协议中的 ACK 应对机制不同,实时音视频场景运用的是 NACK 否定应对机制,经过接纳端查看包序号的接连性,自动将丢失的包信息告诉给发送端进行重新发送。这种方法的长处是在低延时场景下的康复功率高,带宽使用率好,但在高延时场景下的作用比较差,存在重传风暴等状况。
第二种是 Forward Error Correction (FEC) 即前向纠错编码,一种经过冗余发送对立网络丢包的技能。它主要的技能原理便是分组编码,组内进行冗余康复。假定每个分组由 k 个媒体包和 r 个冗余包组成,一个分组中 k+r 个数据包中恣意 k 个包能够用来重建 k 个原始媒体包。这种方法的优势是依据先验知识进行冗余决议计划,不受延时影响。
3. 冗余战略
在上述根本的包康复技能下,为了使各种场景的全体抗弱网才能最大化,需求针对带宽分配、抗丢包技能的组合装备等进行一系列的优化,然后到达抗丢包才能、端到端延时、卡顿率、冗余率的平衡,到达“耗费最小的价值,完成最优的体会”。
下面具体介绍咱们在这方面做的几项优化。
3.1 自适应调整战略
冗余战略大致能够分为两类,一类是前向冗余,一类是被迫冗余。依照前文的描绘,咱们知道前向冗余的长处是不需求交互,在高延时环境下更加适用,缺陷是带宽占用过多。被迫冗余的长处是按需发送,占用带宽较少,缺陷是高延时场景作用会急剧下滑。
咱们的冗余战略则是在寻觅一个平衡点,经过被迫冗余和前向冗余战略份额的调整,在确保丢包康复率(比方 99.5%)的前提下,尽量的减小冗余占比,尽量的减小抗丢包康复时刻。所以,咱们能够将当时问题笼统成如下一个数学场景:
-
假定 m 个媒体包,在重传 k 次后,收到 i 个包的概率记为: P(m, i, k)
-
假定 n 个冗余包,接纳端收到 j 个包的概率记为: P(n, j, 0)
-
依据当时的 FEC 算法,这个 m + n 的分组在重传 k 的状况下,接纳端只需求接纳到恣意 m 个包,就能够康复悉数的媒体包, 这个概率为:
- Nack FEC 算法便是依据康复概率大于 99% 的状况来计算当时最少需求装备的 FEC 冗余度 n
依据上面的模型,在 m (平均帧分组巨细), k (答应时刻范围内的重传次数), i,j 是能够自变量。咱们只要将 n 从 0 开端代入,上面求和的结果大于 99%,就能够将这个 n 作为 FEC 的冗余率。
经过上面的算法,咱们界说一个抗丢包康复时刻 resend_delay,就能够获得被迫重传次数 k。经过参数 k,能够推导出为了到达康复率 99%,还需求的 FEC 份额。上述便是理论上的最优冗余率计算逻辑。经过该算法逻辑,咱们能够获得一个自适应的冗余调整战略,然后获得最优的冗余份额、最合适的延时损耗、以及最佳的丢包康复率。
3.2 可靠重传战略
在接纳端媒体缓存中,关于 seq 最新和最老范围内没有接纳到的数据,接纳端会发送 Nack 恳求,然后发送端接纳 Nack 恳求,将相应的包传送过来。
正常工作状况中,Pacer 优先发送 RTX 重传数据,然后再发送媒体数据,这样接纳端这边较老的丢失数据包,总能够优先得到康复。
但是在一些场景下,比方大丢包(70% 或以上的丢包率),或许突然限宽(4M —> 300K)时,会呈现很多的数据包被丢弃掉。这个数据包既包括原始包,也包括 Nack 重传包,这样会导致如下图的一些问题。
如图,假如丢包康复作用比较差,比方上面 n + 3 的帧已经开端发送了,但是 n 帧还没有被接纳端悉数接纳到,这时,接纳端生成的需求重传的包列表 nack_list 就会很长。关于发送端来说,因为媒体数据还在持续发送,理论上接纳端恳求的 nack 会越来愈多,这样就会形成 nack 风暴。
Nack 风暴不但会导致很多的重传流量挤占媒体带宽,导致带宽分配模块分配给媒体的码率下降,也会导致 Pacer 拥堵,然后带来更大的端到端延时。一起,因为不是选择性的重传某个帧的媒体包,导致接纳端需求解码的帧能够被完好丢包康复的概率比较低。
为了避免上述状况,咱们引入了可靠重传模块:在检测到上述状况后,及时暂停媒体发送,一起全力确保已经发送的帧数据能够完全康复。
咱们经过 TccAck 和 Nack 恳求的信息来确认某一个包处于什么状况,然后计算当时已经发送的数据中没有被完好 ACK 的帧数量。假如这个数量过大,则会暂停媒体发送(一起暂停编码器)。暂停媒体发送后,依照帧从老到新的顺序,把 pacer 预算分配给最高优先级的帧,自动发送这些帧里面没有被 ACK 的数据。
经过上面的方法,咱们有效解决了目标场景长时刻卡死或许卡顿过多的问题。
3.3 拥塞康复场景下快速按捺 FEC 码率\
咱们 FEC 运用 loss 计算 FEC 冗余率,为了避免颤动带来的剧烈改变,这个 loss 值被平滑过。但是关于一些场景,比方带宽突然掉落到较低的场景下,当拥塞状况免除后,网络丢包就会消失。这个时分,咱们需求快速的按捺 FEC 码率,让出带宽给到媒体,这样能够尽快地提高画面质量。
运用上面的状况机,在接纳到拥塞免除信号(拥塞状况免除,而且瞬时 tcc loss 变为0)后,在平滑 loss 没有变为 0 的状况下,运用瞬时 loss,能够快速取消掉 FEC 冗余。
3.4 空余带宽使用优化
在同享场景下,冗余战略会遇到进一步的挑战。比方在 PPT 不翻页的时分,空余带宽需求让给视频。但是在翻页的时分同享流又会敏捷占有带宽。这样就会导致视频码率在翻页时呈现较大的动摇。假如全体可用带宽较低,就能够看到视频质量的显着改变——卡顿率、延时上升。
如图,在 PPT 翻页场景,video 会运用 screen 空余未被运用的带宽。静止画面下,video 运用了大部分本来同享的预算。一旦 PPT 翻页,同享的码率瞬时进步,而 video 没有及时把编码码率降下来,就会形成 pacer 模块的拥堵,导致丢帧然后摄像头流卡顿。
针对该场景,咱们对带宽分配战略进行了优化:
- 缓升快降
带宽分配进程中对每个媒体流运用的上一层传过来的空余码率进行缓升快降操作,避免高优先级码流过快让出空余带宽,导致低优先级码流的分配码率大幅动摇。
- 关键帧检测
当某个媒体流开端收到关键帧的时分,下降该流让出空余带宽的量,使得全体输出码率的动摇性下降。
- 波峰检测
运用 300ms 计算窗口判别波峰,呈现较大的波峰数据时,下降该流让出带宽的量,减小全体输出码率的动摇性。
4. 优化作用
在上述的冗余战略优化下,飞书会议全体冗余率大幅度下降(部分上涨是因为原有算法冗余不足,呈现很多卡顿,算法优化后,全体冗余率调整为最佳值)。一起,在确保了音视频全体作用的前提下,全体端到端延时也进一步下降,提高了飞书会议的全体音视频体会。
- 算法优化大幅度下降了低延时场景的冗余率,高延时场景的冗余率也趋于理论上的合理值。
- 解决了原有算法在高丢包场景下的问题,关于高延时,高丢包率的弱网场景下的体会大幅提高。
- 解决了场景,网络状况改变进程中的收敛速度,提高了改变进程中的音视频体会。
在与同类产品的比较中,咱们优化算法的冗余度显着低于同类产品,在流畅度对齐的状况下,耗费更小的带宽。特别是在高丢包,高延时场景下,咱们的冗余率只相当于同类产品的 40%。
5. 未来展望
经过这些经优化的冗余战略,当时飞书会议在弱网场景下的卡顿率、端到端延时、冗余率等指标得到了大幅度的优化。在此根底上,咱们未来会在极点弱网支持,带内冗余联动战略,智能场景辨认等方面,进一步加大投入,添加飞书会议在各种弱网场景下的客户端体会。
5.1 极点场景下的抗弱网才能支持
添加针对极高丢包、极高延时、丢包+延时,低带宽+高丢包等场景的支持,配合冗余战略以及带宽分配战略,到达极点弱网场景下面的最佳音视频体会。
5.2 带内冗余联动下的抗弱网战略
冗余战略,除了前面说到的非音视频编码内的带外冗余(Nack,FEC 等),也包括音视频编码内的带内冗余。比较于带外冗余,带内冗余往往结合编码本身的特色,运用更少的冗余码率价值,到达更高的抗弱网作用。
咱们的冗余战略也会进一步结合、更大化使用带内冗余算法,进一步进步抗弱网才能,下降全体延时和带宽占用。
5.3 场景辨认下的抗弱网战略优化
后续,咱们还将对当时的网络环境进行辨认,获取到当时的网络场景,然后能够进一步对冗余战略以及编码战略进行预判式的战略下发。
比方,咱们辨认到当时场景为高铁场景,就能够在冗余战略生成的时分倾向于抗接连丢包的战略,也能够预先添加默许前向冗余来添加突发弱网的抗性。依据辨认场景的特性,能够在实践发生弱网之前以及发生弱网之后,做出战略上的区别。
6. 参加咱们
火山引擎 RTC,致力于提供全球互联网范围内高质量、低延时的实时音视频通信才能,协助开发者快速构建语音通话、视频通话、互动直播、转推直播等丰厚场景功能,目前已覆盖互娱、教育、会议、游戏、汽车、金融、IoT 等丰厚实时音视频互动场景,服务数亿用户。
咱们是 RTC Lab 部门,担任 RTC 产品中音频、视频、网络等根底功能的研发,经过极致的工程和音视频算法,打磨顶级的实时音视频根底体会,期待优秀同学的参加!
扫描上方二维码,参加咱们吧!