RTE Wednesday丨AI Codec在音频的应用

近期,RTC 开发者社区声网Agora 组织了一场名为 RTE Wednesday 的线下闭门技术交流活动。来自北京理工大学的王晶老师、中国三星研究院的王立众、小米科技的相非、荔枝FM的沈俊聪、声网Agora 的赵晓涵等产学研的专家,就 AI Codec 在音频编解码领域的应用进行了深入探讨。我们整理了本次活动中各位嘉宾讨论内容的缩略版以飨读者,以下是正文。

音频 Codec 的过去和现在

音频编解码领域一直存在两个极端方向,一个是低码率和极低码率、一个是高码率。 前者通常用在军事通信领域,典型如无线对讲机、卫星电话等,但这个领域的技术基本上是不公开的;后者主要用在实时通信和广播电视领域,包括近几年以 OTT 和电信级业务为代表的实时通信应用,以及超高清广播电视等应用。传统音频 Codec 技术从语音到音乐、从窄带到宽带再到全频都有着广泛的应用,包括像 3D Audio、单通道、多通道、语音与音乐混合、场景编码等,但囿于当前的条件尤其是 4K 以下的编解码技术已经停滞多年,在这个码率下要做到3.5以上的 MOS 得分非常难,目前仅在窄带通信中艰难发展。但谷歌今年先后推出的 LyraSoundStream 给沉寂了多年的音频 Codec 领域注入了新(AI)的活力。

AI Codec 的核心诉求是在降低码率、提高效率的同时保证音质的可靠性。毋庸置疑,降低码率是一个长期存在的需求,无论是 VoIP 还是 OTT 都会占用一定的带宽,任何时候带宽的开销对用户和厂商都是不容忽视的压力。在传统音频 Codec 场景中,国际上的 3GPP 和 MPEG 组织都有相应的标准规范,前者更注重手机通信和视频会议,后者的范围要更广泛;相应的早期电信标准是 ITU GXXX 系列、后续发展为 VoIP,而实时通信的标准体系则是 Opus/EVS——但 3K 以下的窄带通信一直没有相关标准。

AI Codec 的应用场景展望

即便通信技术发展到了 5G 时代,但现实生活中依然有大量的低码率连通需求——尤其是弱网、蓝牙等带宽受限的环境中。如果说极低码率和高码率音频 Codec 的发展容易遭遇技术的天花板,那么处于中间地带的实时通信能否有更大的腾挪空间呢?从业界已有的成果来看,目前 AI Codec 在低码率音频编解码方面节省的带宽相对有限,远不如提升传输网络带来的效果明显。

一方面,音频 Codec 自身的演进的确也慢了一些,这对产业的成长是一个较大的考验。 以最近几年比较火的直播业务为例,厂商最大的成本是带宽,其次是 Codec 相关的 License 开销。因此业界普遍开始从网络传输和编解码两方面着手解决问题,例如三星的 X-net、声网Agora 的 SD-RTN™ 等。

除了低码率,视频会议、网络流媒体、移动通信、AR & VR、多播流媒体/广播、360 度视频和车联网通信等领域都对 AI Codec 有着广泛的需求,与会专家一致认为沉浸式音频体验将会是非常重要的发展方向。**在标准方面,2016 年初 AVS 已启动了相关标准的制定。**在新一代的 AVS3 音频标准中,除了传统的广播电视,像手机、VoIP、OTT 等应用场景有较多的体现。此外,智能家居和可穿戴设备市场的增长也非常快,产生了许多新的音频应用场景。基于阵列的、多通道的音频编解码和压缩(尤其是智能硬件、OTT 业务)未来也是一个重要的应用场景,但许多业务场景需要电信级的支持才能更好地实现。

众口难调的音质体验

对于音质体验的评价标准依赖于主观(缺乏统一的客观标准)且成本较高,因此相关技术在落地应用过程中存在不少困难。在业界,目前最大的音频设备品类是智能手机,**一个客观存在的现象是国内大众对低频敏感、对高频不敏感。**而业界厂商音频 Codec 技术对高频采样部分的默认处理是缺失的,其中一个重要的原因是处理高频采样的算力消耗过大、带来的主观感受提升有限、性价比太低,对于大众相对敏感的低频则只需要“加大音量”即可。但音乐类的在线教育、演唱会等业务场景,对高频 Codec 应用实际上是有刚性需求的。

另外一个值得注意的地方是蓝牙音频设备, 目前蓝牙耳机产品的音频和声学体验都欠佳,软件算法层面已然不是问题,最大的瓶颈在于芯片。尽管头部企业如高通、恒玄在蓝牙芯片技术方面已经取得了突破(实现了无损),但芯片的功耗墙和配套的解决方案仍然差强人意,并且上游企业对供应链的影响极大,另外蓝牙技术的人才也非常稀缺。蓝牙耳机市场的马太效应越来越明显,最终会形成一个相对细分的垂直领域。

底层技术与行业标准

如果一项技术,于厂商而言不能赚钱、于学界而言不能出科研成果,这项技术就很难持续。行业市场方面,从芯片到终端整个上下游的投资建设和市场培育都需要时间——最终成本都会分摊在终端设备厂商并进而转嫁到消费者身上。一个标准的制定和落地更是会受许多客观因素的影响,例如市场需求的推动、宏观政策的引导、以及诸如“新冠”之类的黑天鹅事件等等。

我们不妨回顾一下 WebRTC 的历史,2010 年Google收购了 GIPS 引擎和 ON2 并入 GTalk 通信库,于2011年将其纳入 Chrome 体系开源并更名为“WebRTC”。随即 WebRTC 被纳入 W3C 推荐标准。2014 年7 月1 日,WebRTC 浏览器 API 标准的 1.0 版由 W3C 发布。此后实时通信的发展迈入了快车道。WebRTC 在某种意义上统一了底层技术,虽然为后续生态的发展打下了良好的基础,但也封锁了该领域的基础研究,使得底层架构别无他选。学界人士呼吁产业界不能满足于在开源架构的基础上修修补补,也应该更积极地投身底层技术的研究,多考虑行业的长久繁荣之计。