NetEQ 是 WebRTC 音视频核心技术之一,对于提高 VoIP 质量有明显的效果,本文将从更为宏观的视角,用通俗白话介绍 WebRTC 中音频 NetEQ 的相关概念背景和框架原理,以及相关的优化实践。
作者| 良逸
审校| 泰一
随便搜索一下,我们就能在网上找到很多关于 WebRTC 中音频 NetEQ 的文章,比如下面的几篇文章都是非常不错的学习资料和参考。特别是西安电子科技大学 2013 年吴江锐的硕士论文《WebRTC 语音引擎中 NetEQ 技术的研究》,非常详尽地介绍了 NetEQ 实现细节,也被引用到了很多很多的文章中。
《WebRTC 语音引擎中 NetEQ 技术的研究》
NetEQ 算法
WebRTC 中音频相关的 NetEQ
这些文章大部分从比较 “学术” 的或 “算法” 的角度,对 NetEQ 的细节做了非常透彻的分析,所以这里我想从更宏观一些的角度,说一下我个人的理解。白话更容易被大家接受,争取一个数学公式都不用,一行代码都不上就把思路说清楚,有理解不对的地方,还请大家不吝赐教。
丢包、抖动和优化的理解在音视频实时通信领域,特别是移动办公(4G),疫情下的居家办公和在线课堂 (WIFI),网络环境成了影响音视频质量最关键的因素,在差的网络质量面前,再好的音视频算法都显得有些杯水车薪。网络质量差的表现主要有延时、乱序、丢包、抖动,谁能处理和平衡好这几类问题,谁就能获得更好的音视频体验。由于网络的基础延时是链路的选择决定的,需优化链路调度层来解决;而乱序在大部分网络条件下并不是很多,而且乱序的程度也不是很严重,所以接下来我们主要会讨论丢包和抖动。
抖动是数据在网络上的传输忽快忽慢,丢包是数据包经过网络传输,因为各种原因被丢掉了,经过几次重传后被成功收到是恢复包,重传也失败的或者恢复包过时的,都会形成真正的丢包,需要丢包恢复 PLC 算法来无中生有的产生一些假数据来补偿。丢包和抖动从时间维度上又是统一的,等一会来了的是抖动,迟到很久才来的是重传包,等一辈子也不来的就是 “真丢包”,我们的目标就是要尽量降低数据包变成 “真丢包” 的概率。
优化,直观来讲就是某个数据指标,经过一顿猛如虎的操作之后,从 xxx 提升到了 xxx。但我觉得,评判优化好坏不能仅仅停留在这个维度,优化是要 “知己知彼”,己是自己的产品需求,彼是现有算法的能力,己彼合一才是最好的优化,不管算法是简单还是复杂,只要能完美的匹配自己的产品需求,就是最好的算法,“能捉到老鼠的就是好猫”。
NetEQ 及相关模块 NetEQ 的出处《GIPS NetEQ 原始文档》,这是由 GIPS 公司提供的最原始的 NetEQ 的说明文档(中文翻译),里面介绍了什么是 NetEQ 以及对其性能的简单说明。NetEQ 本质上就是一个音频的 JitterBuffer(抖动缓冲器),名字起的非常贴切,Network Equalizer(网络均衡器)。大家都知道 Audio Equalizer 是用来均衡声音的效果器,而这里的 NetEQ 是用来均衡网络抖动的效果器。而且 GIPS 还给这个名字注册了商标,所以很多地方看到的是 NetEQ (TM) 。
上面的官方文档中,有一条很重要信息,“最小化抖动缓冲带来的延时影响”,这说明 NetEQ 的设计目标之一就是:“追求极低延时”。这个信息很关键,为我们后续的优化提供了重要线索。
NetEQ 在音视频通讯 QoS 流程中的位置
音视频通讯对于普通用户来说,只要网络是通的,WIFI 和 4G 都可以,一个呼叫过去,看到人且听到声音,就 OK 了,很简单的事情,但对于底层的实现却没有看起来那么简单。单 WebRTC 开源引擎的相关代码文件数量就有 20 万个左右,代码行数不知道有没有人具体算过,应该也是千万数量级的了。不知道多少码农为此掉光了头发