腾讯天籁:音频联合信源信道编码技术白皮书

2024-03-23 20:38

本文主要是介绍腾讯天籁:音频联合信源信道编码技术白皮书,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前言

2020年疫情的突如其来,让数字通信成为了人与人沟通的重要手段;同时也对实时音视频通信(RTC)的稳定性和通讯效果提供了极大考验。由于业务量激增,在保障用户体验方面,RTC业务面临着诸多困难,包括但不限于通话质量、最小化卡顿、端到端延时、带宽成本等。在网络传输过程中,RTC方案,需要面对用户体验、运营成本的双重约束,挑战巨大。本白皮书,将聚焦RTC业务中网络抗性下的体验保障这一命题展开讨论。本文首先对相关技术的特点进行描述。然后,本文重点介绍腾讯天籁推出的音频联合信源信道编码方案。该方案已经在腾讯会议、TRTC等产品推广和部署;在保障用户体验同时,显著降低带宽和延时。

1.背景介绍     

图1. 端到端视角下音频通话体验的影响因素

VoIP是一个复杂的链式系统,以单侧的发送端到接收端通信为例,要经过采集、前处理、编码、传输、解码、增强、回放等多个阶段。每个阶段都会影响最终体验。从端到端到角度,影响通话体验的因素,可以分成信源和信道(链路)两个部分。信源部分,主要干扰因素是声学侧的噪声、回声等物理特征;一般地,通过优化音频信号处理方案(包括结合深度学习技术等)进行质量保证。如果说,信源决定最终体验的上界,信道则决定了体验“打折”后的上界。

图2. 语音丢包

RTC业务中,一个重要的挑战就是传输过程中出现丢包;丢包导致接收端解码声音不连续或卡顿,影响体验(图2)。因此,网络抗性提升是RTC业务绕不开的话题。然而,任何一种抗性提升手段,避免不了增加带宽冗余、CPU消耗等。同时,任何一种单一手段,并不能很完美解决上述问题。因此,打造一个好的RTC通话体验,需要联合信源和信道,自顶向下地设计系统。本文将重点讨论如何提升RTC系统中的网络抗性。

2.相关技术概述

1)WebRTC        

图3. WebRTC引擎

RTC主流商用方案,始于开源。目前的开源体系中,WebRTC使用得最为广泛[1]。WebRTC实现了基于网页的RTC视频会议能力,核心技术包括音视频的采集、编解码、网络传输、显示等功能,并且还支持跨平台:Windows,Linux,Mac,Android。相对全面的平台能力,使得RTC公司优选其作为开发平台,搭建自主品牌的SDK。

因此,相当一部分RTC厂商采用的策略,是完全基于WebRTC,不做底层的改动;针对应用场景,发力于易用性等方面的改进。

然而,在疫情这一特殊背景下,用户对实时音视频通信的稳定性和通讯效果提出了更高要求。简单地基于开源平台改动,并不能从根本上,将通话体验提升一个档次。因此,具备更多核心能力、底层技术的方案,将在市场上更具竞争力。

2)嵌入式编码技术(分层编码)

嵌入式编码,也叫分层编码,通过对信源中不同成份,进行分层处理,以适应网络抗性方面的要求(图4)。原理可以概述为:

  • 通过带通滤波器,将输入的语音信号分离成窄带和宽带部分。

  • 对窄带部分使用更多码率进行压缩,减少失真。如果还有带宽资源,会先花少量码率对高频进行高效率的参数编码,恢复出质量可接受的高频。进一步,如果还有更多带宽资源,对高频做更为精细编码,恢复出高质量的高频。

  • 上述编码的码流,将使用不同优先级传输保障策略,发给接收端。特别地,网络非常差情况下,只发送窄带部分的码流。

  • 如果接收端至少收到低频部分,可恢复出窄带语音,基础质量可以保障。根据收到不同编码精度的高频,输出不同质量水平的宽带语音。

图4. 嵌入式编码基本架构

嵌入式编码,在视频编码系统中被普遍采纳;语音编领域,在2000-2010年这个区间,流行过一段时间,比如ITU-T G729.1和G.718 ,以及相关标准的超宽带演进版本[2, 3]。

然而,嵌入式编码,对于语音业务,存在效率不高的问题。究其原因,语音业务的基础码率偏低,比如20kbps;如果引入嵌入式编码,为了2kbps的分层编码,系统需要做复杂的分层逻辑,在QoE综合质量上不见得是最优策略。因此,2010年之后的主流标准,如IETF OPUS[4],并没有采用嵌入式编码。一般地,即使未采用嵌入编码,相关的编码标准也会采纳多速率编码技术,即支持多种编码码率,用户根据业务特点进行合理配置。

3)多描述编码技术(MDC)

多描述编码(MDC)是一种码流分离技术,具体说,就是将一段音频信号,分离成不同子部分(称之为“描述”);每个部分分别组包,并使用不同的传输路径进行传输。接收端如果收到部分的描述,可以恢复出低质量的音频;如果收到全部描述,可以恢复出高质量的音频[5]。

一个最简单的MDC实施方式是,对一段音频信号进行奇偶抽样;奇数抽样和偶数抽样分别组包传输;接收端即使只收到奇数或者偶数抽样相关的数据包,通过解码和插值,即可恢复出低质量的音频。更为复杂的MDC,包括对奇偶帧进行反复残差分析,确定失真最小的组合变量进行编码和传输。一般地,MDC编码器包含了多个描述的编码器和描述残差关系的编码器,编码器复杂度很高。

MDC的设计理念,假设了网络状态一定不好。MDC的代价,是牺牲(同等码率)天花板质量。一般地,在理想信道下,需要额外消耗20-30%带宽完成MDC。因此,MDC并不会降低带宽的使用量;并且,MDC主要用于窄带部分,宽带部分还是结合了结合了嵌入式编码、频带扩展等技术,提升带宽利用率;否则,带宽使用量会增加。

4)RED机制

RED机制,即IETF RTP Payload for Redundant Audio Data[6]。这个机制提出,跟上文提到的音频码率偏低有关。比如说,每20ms语音帧进行打包操作,包头假设是10kbps、有效载荷是20kbps;这样一种分配,码率浪费严重。因此,RED的建议是,将相邻两个20ms的有效载荷合并成一个数据包。这样,一个数据包中有效载荷比例可达80%。OPUS就沿用了RED机制,甚至将相邻60ms数据合并成一个数据包,共享一个包头。然而,RED机制并没有任何包内抗性;如果没有其它抗性保障,一旦包丢失,影响连续40-60ms数据。

5)带外FEC       

图5. 带外FEC示意图

带外FEC,即在包层进行数据冗余操作的技术[7]。举个例子:如果分组是4,那么在网络传输过程中任意丢掉一个,在接收端任意收到任何顺序的4个属于本分组的数据包,那就可以把丢失的包恢复。具体包括,发送端:将数据包按照参数下发,对数据包进行分组(block),对分组数据加冗余。接收端:收齐分组后即可恢复数据(丢失不超过冗余包数),因为要等分组到齐,存在FEC恢复算法上的延时, FecDelay = Block * 帧长。

6)ARQ重传

所谓ARQ重传,即包确定丢失且无法恢复时,通过请求重传,以增加延时的方式,提升网络抗性[8]。音频快速重传ARQ是“选择重传”算法作为基本的请求策略,算法的关键特色在于重传请求与Jitter Buffer的紧密配合上。几个基本准则包括:

  • 请求重传模块记录并缓存所有重传数据包的重传成功所消耗的时间,并将重传延时ArqDelay告知JitterBuffer模块,提高了数据的缓冲等待时长的高可控性。

  • 接收端通过ARQ请求,在数据缓冲队列的数据帧被播放之前,当还未重传成功的数据帧在已经达到播放时间时,接收端通过ACK通知取消请求重传,减少无用请求。

3.联合信源信道编码架构

1)方案的设计理念

如前文所述,针对网络抗性问题,主流的RTC解决方案还是围绕信道侧方法进行;特别地,通过加网络冗余,维护一个高的抗性水平。然而,如果完全依赖信道侧方法,实际应用中又面临其它问题:

  • 如果网络抗性完全来自于带外,带宽成本激增。

  • 重传等操作,带来了包的组合、解析等迭代操作,增加时延。

因此,腾讯天籁的解决方案优先从信源入手,优化带内FEC。所谓带内FEC,最直观的解释就是在第T个包中除了包头和第T帧以外,还包含第T-1帧的信息。事实上,OPUS已经支持上述带内FEC的功能。经过测算,OPUS带内FEC帧的有效载荷约为普通帧的70-80%;然而,只能提供20%丢包率的抗性;投入产出比偏低。

综合上述考虑,腾讯天籁提出下列的联合信源信道编码策略:

  • 首先,提升信源侧方法的能力上界。相对于标准带内FEC,新的信源侧FEC,需要更强的单独抗性;比如,支持40%丢包率。

  • 其二,灵活调用带外和带内抗性。以期在抗性稳定性和带宽消耗上有一个更为灵活的折衷。相关的控制参数,依赖于测试平台提供的经验数据,进行迭代升级。

  • 第三,前向兼容性问题,要保证新旧两种协议无互通问题。

2)方案框架         

图6. 联合信源信道编码基本框架

腾讯天籁联合信源信道编码的基本框架进行介绍:

  • 系统可以分解为发送端、网络侧、接收端。

  • 发送端将新方案的码流发往上行媒体代理。其中,cFEC提供了信源侧抗性,带外和流控,根据实际的网络状态,下发具体配置,确保最小带宽和延时成本下的QoE保障。

  • 上行媒体代理处,将新方案对应的协议,转换成标准协议。

  • 下行媒体代理处,将标准协议转换成新方案的协议,并发给接收端。

  • 接收端接收新方案的协议,具备了联合信源信道的能力;以更少的带宽和延时,获得稳定可靠的网络抗性能力。此外,接收端也集成cPLC丢包补偿模块处理突发丢包状态。实时策略,由带外和流控模块控制。在网络有损的情况下,带外FEC或者ARQ重传,最大程度保障数据包可以完整发送到接收端。如果仍然有丢包发生,首先基于cFEC的带内抗性进行质量保障;如果有更多连续数据包丢失,则启动cPLC进行丢包补偿。

3)核心模块

a.信源侧FEC(cFEC)

腾讯天籁的cFEC方案,充分借鉴了语音信号的时间上相关性建模,提升带宽利用率。因此,在带宽有限情况下,大幅度提升抗性。

图7是cFEC与OPUS原生FEC的效果比较。除了纯净网络外, cFEC相对OPUS原生FEC,可以提升0.1-1.1MOS。特别地,在40%这种比较大丢包率下,采用cFEC技术仍然将MOS分保持在3.0以上。信源侧单独抗性提升,为联合信源信道编码实施提供了足够保障。

图7. cFEC技术与OPUS原生FEC的抗性能力对比

我们以40%丢包率为例,展示自研cFEC技术,相对现有技术,在抗性提升方面的能力。每个文件的前一段为OPUS原生技术处理结果,后一段为cFEC处理结果。从主观体验看,cFEC处理后的语音质量和连续性非常显著。

40%丢包率下,OPUS与cFEC原生技术效果对比(上为女生,下为男生)

b.自适应带外控制策略

首先一个概念就是“流控”。我们可以从三种不同维度去描述“流控”。第一,它是一个配置系统,无论双人或多人通话,系统所需要的基础配置参数,做到云端可控。第二,“流控”是把源端到目标端的传输行为,进行动态的能力交换。第三,基于网络拥塞控制(Congestion control),进行自适应控制;这样,就实现了丢包的时候怎样去抗丢包,抖动的时候怎么样去抗抖动,所有流程进行动态控制。拥塞控制,通过实时监控端到端延时的变化量(Jitter),从而判断当前这个网络是否趋于达到网络拥塞的情况,并给出当前一个合理的带宽预测值。基于带宽预测值,系统会动态配置带外FEC和ARQ策略,从而实现自适应带外控制策略。

c.媒体代理与前向兼容问题的解决

联合信源信道编码应用挑战,是与线上老版本的协议兼容问题、或者说,新旧客户端之间的互联互通问题。如果不进行全面考量,客户端接收到不兼容的码流,解码错误后会引起杂音等问题。如图6所示,我们通过媒体代理处部署相关的协议转录器,进行各种标准或者非标准协议之间的转换,对特定的客户端,接收或者发送对应的协议数据包。

d.基于上下文的连续丢包补偿(cPLC)

丢包补偿技术部署在解码端。它是在带外和带内FEC均失效情况下,根据已经恢复的语音帧,去预测丢失帧。这项技术无需额外带宽,兼容性好。主流PLC只能恢复约20ms的丢失内容,效果十分有限。随着深度学习的发展,工业界和学术界均在尝试引入深度学习,解决连续丢包补偿的问题[9]。这些方案,包括基于谱回归或者生成模型等方式,预测出相关的频谱或者信号。一般地,上述方案可以最多补偿120ms连续丢包数据。但模型大、复杂度高。

腾讯天籁提出的cPLC方案,通过加大了信号处理在算法建模过程中的权重,提取上下文关系进行参数建模,并调用深度学习网络,重建丢失语音。cPLC方案不仅复杂度低,还有着零延时、部署难度低和兼容性好等优势。

图8展示了离散丢包和突发丢包场景下,cPLC与OPUS原生PLC的补偿效果。实验结果表明,在所有测试条件下,cPLC在质量上均优于OPUS原生PLC技术。特别地,在突发丢包场景下,cPLC的优势更为明显。

  

图8. cPLC技术与OPUS原生PLC的能力对比

4.实验结果

目前,腾讯天籁联合信源信道编码方案已经在腾讯会议上线。经过测试,可以降低带宽30%;同时,进一步降低延时40-60ms,进一步提升用户体验。

5.结论

RTC场景下,抗性提升是决定用户体验的重要因素。本文分析了几种典型的机制,并对每种机制的特点进行了描述。然而,疫情背景下,RTC产品的稳定性和通讯效果面临更多挑战,对新方案的需求更为强烈。腾讯天籁联合信源信道编码方案,通过有效地组合信源和信道侧的抗性策略,保证用户体验的同时,有效降低带宽和延时成本。从效果上看,结合了信源、信道的联合优化策略、结合经典信号处理和深度学习的新技术,将成为未来RTC解决方案中的关注点。

参考资料

[1] https://webrtc.org/

[2] ITU-T G.729.1 : G.729-based embedded variable bit-rate coder: An 8-32 kbit/s scalable wideband coder bitstream interoperable with G.729

[3] ITU-T G.718 : Frame error robust narrow-band and wideband embedded variable bit-rate coding of speech and audio from 8-32 kbit/s

[4] https://opus-codec.org/

[5] V. K. Goyal, "Multiple Description Coding: Compression Meets the Network," IEEE Signal Processing Magazine, vol. 18, no. 5, pp. 74–94, Sept. 2001.

[6] IETF RFC6354: RTP Payload for Redundant Audio Data.

[7] J. Bolot, etc. The Case for FEC-based Error Control for Packet Audio in the Internet. 1997.

[8] H. Seferoglu, etc. Rate Distortion Optimized Joint ARQ-FEC Scheme for Real-Time Wireless Multimedia. In ICC 2005.

[9] https://ai.googleblog.com/2020/04/improving-audio-quality-in-duo-with.html

这篇关于腾讯天籁:音频联合信源信道编码技术白皮书的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/839476

相关文章

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业

金融业开源技术 术语

金融业开源技术  术语 1  范围 本文件界定了金融业开源技术的常用术语。 本文件适用于金融业中涉及开源技术的相关标准及规范性文件制定和信息沟通等活动。

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出 在数字化时代,文本到语音(Text-to-Speech, TTS)技术已成为人机交互的关键桥梁,无论是为视障人士提供辅助阅读,还是为智能助手注入声音的灵魂,TTS 技术都扮演着至关重要的角色。从最初的拼接式方法到参数化技术,再到现今的深度学习解决方案,TTS 技术经历了一段长足的进步。这篇文章将带您穿越时

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

Java 后端接口入参 - 联合前端VUE 使用AES完成入参出参加密解密

加密效果: 解密后的数据就是正常数据: 后端:使用的是spring-cloud框架,在gateway模块进行操作 <dependency><groupId>com.google.guava</groupId><artifactId>guava</artifactId><version>30.0-jre</version></dependency> 编写一个AES加密

前端技术(七)——less 教程

一、less简介 1. less是什么? less是一种动态样式语言,属于css预处理器的范畴,它扩展了CSS语言,增加了变量、Mixin、函数等特性,使CSS 更易维护和扩展LESS 既可以在 客户端 上运行 ,也可以借助Node.js在服务端运行。 less的中文官网:https://lesscss.cn/ 2. less编译工具 koala 官网 http://koala-app.

Spring的设计⽬标——《Spring技术内幕》

读《Spring技术内幕》第二版,计文柯著。 如果我们要简要地描述Spring的设计⽬标,可以这么说,Spring为开发者提供的是⼀个⼀站式的轻量级应⽤开发框架(平台)。 作为平台,Spring抽象了我们在 许多应⽤开发中遇到的共性问题;同时,作为⼀个轻量级的应⽤开发框架,Spring和传统的J2EE开发相⽐,有其⾃⾝的特点。 通过这些⾃⾝的特点,Spring充分体现了它的设计理念:在

java线程深度解析(六)——线程池技术

http://blog.csdn.net/Daybreak1209/article/details/51382604 一种最为简单的线程创建和回收的方法: [html]  view plain copy new Thread(new Runnable(){                @Override               public voi

java线程深度解析(二)——线程互斥技术与线程间通信

http://blog.csdn.net/daybreak1209/article/details/51307679      在java多线程——线程同步问题中,对于多线程下程序启动时出现的线程安全问题的背景和初步解决方案已经有了详细的介绍。本文将再度深入解析对线程代码块和方法的同步控制和多线程间通信的实例。 一、再现多线程下安全问题 先看开启两条线程,分别按序打印字符串的

AIGC6: 走进腾讯数字盛会

图中是一个程序员,去参加一个技术盛会。AI大潮下,五颜六色,各种不确定。 背景 AI对各行各业的冲击越来越大,身处职场的我也能清晰的感受到。 我所在的行业为全球客服外包行业。 业务模式为: 为国际跨境公司提供不同地区不同语言的客服外包解决方案,除了人力,还有软件系统。 软件系统主要是提供了客服跟客人的渠道沟通和工单管理,内部管理跟甲方的合同对接,绩效评估,BI数据透视。 客服跟客人