详解低延时高音质:丢包、抖动与 last mile 优化那些事儿

标签: dev | 发表时间:2021-03-19 00:00 | 作者:
出处:http://itindex.net/relian

本篇是「详解低延时高音质系列」的第三篇技术分享。我们这次要将视角放大,从整个音频引擎链路的角度,来讲讲在时变的网络下,针对不同的应用场景,如何权衡音质和互动的实时性。


当我们在讨论实时互动场景下的低延时、高音质的时候,我们其实要面对的是从端到端整个音频引擎链路上的音质问题。我们在第一篇文章中,简单的描绘过一条音频传输的过程,如果在该基础上再进一步细化,音频引擎的整个链路包含以下各步骤:

1. 采集设备对声学信号进行 采样,形成计算机可操作的离散音频信号;

2. 由于音频信号的短时相关性,将音频信号进行 分帧处理,经过 3A 解决方案处理声学、环境噪音、回声、自动增益等问题;

3. 编码器对音频信号进行实时压缩,形成音频码流;

4. 根据 IP+UDP+RTP+Audio Payload 的格式 组包后发送端将音频数据包发向网络, 重组经过网络到达接收端的数据包;

5. 经过 抗抖缓存解码器重建连续的音频流播放设备将连续的音频流播放出来。

在以上不同的音频处理环节中,都会不可避免地对音频信号产生一些损伤。我们将上述因采集、播放而对音频信号引入的损伤称为「设备损伤」,在环节 2 引入的损伤称为「信号处理损伤」,在编码与解码过程中引入的称为「编码损伤」,环节 4 中的称为「网络损伤」。如果要为用户提供全频带的高质量音频互动体验,就需要在上述的音频引擎链路支持全频带的处理,并在一些约束条件下(比如来自设备、网络带宽、声学环境等),将各个环节引入的损伤尽可能降低到最小。
当音频数据进入网络,它会遇到……


如果将网络视作信息的公路,那么音频数据包就像是一辆辆跑在公路上的车。这辆车从北京开到上海,途径的高速公路就是主干网络,崎岖山路就是弱网环境。假设每分钟都有一辆车从北京出发上路,那么他们会遇到三个实时传输中的常见问题:丢包、延时、抖动。 丢包“丢包”指的是有的车无法在有效时间内无法达到终点,甚至可能永远也到不了终点。有的车可能永远堵在北京的三环上了,有的车可能中途出了车祸。假如我们的一百辆车里有五辆车因为各种原因没能按时到达上海,我们这次车队传输的“丢包率”就是 5%。是的,互联网传输也一样,它并不是百分百可靠的,总有数据无法按时传输到目的地。 延时“延时”指的是每辆车从北京鸟巢开到上海的平均时间。显然,车队走高速公路肯定要比走各种小公路快很多,而且从鸟巢出发沿着怎样的路线开上高速公路也有很大影响,万一堵在了三环可就要多花好几个小时了。所以这个值和车队选择的行驶路线有关。互联网传输也是一样的道理,需要传输数据的两点之间经常是有很多可选路径的,而这些路径的延时往往相差很大。 抖动“抖动”指的是车子到达的顺序、间隔和出发时的差异。虽然我们的一百辆车在北京是等间隔的一分钟一辆出发的,但是它们到达上海时却并不是按顺序一分钟一辆到达的,甚至可能有晚出发的车比早出发的车先到的情况。互联网传输也一样,如果简单地按照收到的音视频数据顺序直接播放出来,就会出现失真的现象。 总结来讲:1. 在网络上进行实时的音频交互,编码后的音频码流根据实时传输协议组装成数据包。其中数据包从发送端按照各自的路线经过网络前往接收端。2. 全球范围内,不同区域或者不同时间段,用户网络连接的服务质量有时非常差,且不可靠。基于上述原因,数据包往往不是按准确的顺序到达接收端,而是在错误的时间以错误的顺序到达接收端,或数据包丢失等,这就会出现实时传输领域通常提到的问题:网络抖动(jitter),丢包(packet loss),延时(latency)。丢包、延时、抖动,是基于互联网进行实时传输不可避免的三个问题,不论是在局域网、单一国家地区内传输,还是是跨国、跨地区传输,都会遇到。这些网络问题,在不同区域的分布不同,以声网Agora 监控的网络实况来看,在网络相对较好的中国地区,99% 的音频互动需要处理丢包、抖动和网络延时等。这些音频会话中,20%由于网络问题会有超过 3% 的丢包,10%的会话有超过 8%的丢包。而在印度的表现差异较大,80%的音频互动中,大约有 40% 的会话丢失。在印度地区优化 2G/3G 网络下的服务质量,仍是提供音频服务的重点。抖动、延迟、带宽的限制也是很多的,这些网络问题导致音频质量急剧下降,更甚者,影响音频信号的可懂度,即不能满足交换信息量的本质通信需求。因此, 不论对于使用 WebRTC 的自研团队,还是提供实时服务的 SDK 服务,尝试修复这个过程中对音频信号引入的损伤,都是必修的课题。
丢包控制


为保证可靠的实时互动,处理丢包是必须的。如果没有提供连续的音频数据,用户会听到卡顿(glitches、gaps),降低了通话质量和用户体验。丢包问题可以抽象为,如何在不可靠传输的网络上,完成可靠传输。通常使用前向纠错 FEC(Forward Error Correction)和 自动重传请求 ARQ(Automatic Repeat-reQuest)两个纠错算法,根据准确的信道状态估计制定相应策略来解决丢包问题。FEC 是发送端通过信道编码和发送冗余信息,接收端检测丢包,且在不需要重传的前提下根据冗余信息恢复丢失的大部分数据包。即以更高的信道带宽作为恢复丢包的开销。 相比ARQ的丢包恢复,FEC 体验上的延时更小,但由于发送了冗余的数据包,所以信道带宽消耗较多。ARQ 使用确认信息 ack(acknowledgements signal,即接收端发回的确认信息表征已正确接收数据包)和 timeouts,即如果发送方在超时前没有收到确认信息 ack,则通过滑动窗口协议帮助发送端决策是否重传数据包,直到发送方收到确认信息 ack 或直到超过预先定义的重传次数。 相比 FEC 的丢包恢复,ARQ 延时较大(因为要等待 ack 或不断重传),带宽利用率不高。 简单讲,丢包控制中使用的 FEC、ARQ 方法是通过额外的信道带宽,以及延时对丢失的数据包进行恢复。这就是传统抗丢包方法的现状,那么有什么可行的方法能解决呢?我们就以 之前开源的 Agora SOLO为例。通常,编解码器做的事情是压缩、去冗余,而抗丢包从一定程度上讲是信道处理的扩大化。抗丢包是一种纠错算法的扩展,通过加冗余实现抗丢包。而 Agora SOLO 的策略,是把去冗余和加冗余进行结合,对重点信息加冗余,对非重点信息则更多的去冗余,以达到在信道和信源的联合编码的效果。
延时、抖动控制


数据包在网络传输、排队时本身就会产生延迟、抖动。同时,我们通过丢包控制恢复的数据包也会引入延时和抖动,通常使用自适应的 de-jitter buffer 机制进行对抗,确保音频等媒体流连续播放。正如我们上文比喻的,数据包延迟的变化,我们称之为抖动(jitter),是一条音频流或其他媒体流数据包之间端到端单向延时的差异。自适应的逻辑是基于数据包到达间隔(IAT,inter-arrival times)的延时估计进行决策。当出现丢包控制未恢复的数据包、过度的抖动、延时、突发丢包,即超出自适应缓存可对抗的延时时,就会出现卡顿。此时接收端一般使用 PLC(Packet Loss Concealment)模块预测新的音频数据,以填充音频数据缺失(由于丢包、过度的抖动和延时引入的丢包、突发丢包)等产生的不连续的音频信号。综上所述,处理网络损伤,是在不可靠的通信信道上面,通过丢包、延时、抖动控制方法确保数据包尽可能的顺序输出,结合 PLC 预测填充音频数据的缺失。要尽可能减小网络损伤,需要结合以下五点增强弱网边界:

1. 准确的网络信道状态的估计,动态的对丢包控制的策略进行调整和应用;

2. 以及相配套的 de-jitter buffer,以更快、更准的学习速度适应网络的非稳态(好网络转差,差网络转好,突发的梳状网络)的变化,调整抗抖缓存至大于且更接近于稳态时等价延时的大小,才能确保收听者在该瞬时网络环境下的音质好,延时低,逐渐趋于理论最优;

3. 超出弱网可恢复边界时,通过降低码率(也常用来解决信道拥塞),提升信道带宽中冗余数据或重传次数的开销;

4. 并结合 PLC 对输入信号的适应能力,确保不同说话者,时变的背景噪声下尽可能的减小可察觉的噪声;

5. 在较小带宽下,通过编码器编码低码率且高质量的语音,结合3在网络服务质量差的情况下,增加弱网对抗的鲁棒性。

基于以上在丢包、延时、抖动的对抗策略,我们就可以基于互联网传输,提供更好的音频实时互动体验。就像我们之前说的,不同地区、不同时间段、不同网络下,网络的延时、抖动、丢包情况都不同。而声网Agora SDK 是面向全球提供高质量的音频交互服务,让全球各区域的用户在线上进行实时互动,通过音频引擎尽可能将线下的声学体验带给用户。因此我们也做了多次实地的测试,并观察 SDK 的 MoS 分(ITU-T P.863)和延时数据表现。以下是我们在上海中环环线,使用相同设备,在相同运营商网络下,同时测试的Agora RTC SDK与友商产品的 MOS 分和延时数据。从统计来看,声网Agora SDK提供的实时音频交互服务,在提供较高音质的同时,延时更低。

图:MoS 分对比

图:延时数据对比
可以从 MoS 分对比图看出,Agora SDK 的 MOS 主要分布在高分值[4.5, 4.7]区间段,友商主要分布在[3.4, 3.8]。再说一个数据大家可能会有更直观的概念。我们使用的微信,尽管与 RTC SDK 不属于同一类型的产品,但也提供语音通话服务。微信在无弱网环境下测量的最高 MoS 分是 4.19。用户体验的实际音频质量,可由以下音频质量地图中圆点的颜色显示,绿色表示 MOS 分大于4.0;黄色表示 MOS 分处于[3.0, 4.0],红色表示[1, 3.0]。

图:上海中环,Agora SDK 的音频质量

图:上海中环,友商 的音频质量 小结

丢包、延时、抖动是在实时互动场景下不可避免的问题。而且这些问题不仅会由于网络环境、时段、用户设备等因素不断产生变化,也会由于底层技术的发展而产生新的变化(比如 5G 的大规模应用)。所以我们针对它们的优化策略也要不断迭代优化。

 

在跟随音频信号从发送端经过网络到达接收端之后,音频体验的优化并没有结束。为了“高音质体验”,我们还要进一步在端上优化音质,下一篇我们详细分享其冰山一角,敬请期待。



相关阅读

详解低延时高音质:编解码篇

详解低延时高音质:回声消除与降噪篇

END


相关 [高音 丢包 抖动] 推荐:

详解低延时高音质:丢包、抖动与 last mile 优化那些事儿

- - IT瘾-dev
本篇是「详解低延时高音质系列」的第三篇技术分享. 我们这次要将视角放大,从整个音频引擎链路的角度,来讲讲在时变的网络下,针对不同的应用场景,如何权衡音质和互动的实时性. 当我们在讨论实时互动场景下的低延时、高音质的时候,我们其实要面对的是从端到端整个音频引擎链路上的音质问题. 我们在第一篇文章中,简单的描绘过一条音频传输的过程,如果在该基础上再进一步细化,音频引擎的整个链路包含以下各步骤: 1.

Android之网络丢包事件

- - 开源小站
有那么一个应用,同样的服务器端,同样的Wi-Fi网络下,Android连接速度总是慢过iphone一个数量级. 起先怀疑跟Android的硬件有关,无奈的是通过3G甚至于2G EDGE无线连接,速度均超过Wi-Fi. 然后这个责任就一把归结到了“Android不如iPhone”,“Android七拼八凑”之类无休止的平台沙文主义之上了.

Linux网络丢包排查 - 墨天轮

- -
工作中遇到的服务器,最常用的操作系统就是linux系统,linux 系统使用网络适配器和外部进行数据交换. 当在高速链路或异常环境下进行网络通信时,就有可能出现网络数据丢包现象,接下来我主要要说的是:网路丢包的故障定位思路和解决方法. 、网络消息的收发(报文收发过程). 在说丢包故障定位之前,我先来了介绍“网络报文收发过程”.

dropwatch 网络协议栈丢包检查利器

- - 系统技术非业余研究
原创文章,转载请注明: 转载自 系统技术非业余研究. dropwatch 网络协议栈丢包检查利器. 在做网络服务器的时候,会碰到各种各样的网络问题比如说网络超时,通常一般的开发人员对于这种问题最常用的工具当然是tcpdump或者更先进的wireshark来进行抓包分析. 通常这个工具能解决大部分的问题,但是比如说wireshark发现丢包,那深层次的原因就很难解释了.

数据中心丢包分析及解决方案

- - 小红老窝
上周对数据中心tcp数据传输的超时重传时间进行了探究,是的,我们可以缩短重传超时时间,但为什么在数据中心内部也会出现丢包呢. 下面几种丢包情形是大家所熟悉的:1、数据中心内网的某个端口的带宽跑满2、四层,如lvs状态表溢出,新建连接时无法分配状态,所以放弃新连接3、七层,包括web服务器的监听队列backlog满,丢弃新建的连接请求接下来分析一个跟应用部署架构相关的丢包场景,如下图:.

Linux丢包故障的解决与思路 - Albert的博客 | Albert's Blog

- -
Linux丢包故障的解决与思路. 原文地址,和之前一样,在原文的基础上进行了一些格式的调整,包括一些错别字的修正,以及进行了一些博文链接的插入,以便于读者或者我自己更好的理解. Linux作为服务器操作系统时,为了达到高并发处理能力,充分利用机器性能,经常会进行一些内核参数的调整优化,但不合理的调整常常也会引起意想不到的其他问题,本文就一次.