即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解

JackJiang · 8 年前

前言

即时通讯应用中的实时音视频技术，几乎是IM开发中的最后一道高墙。原因在于：实时音视频技术 = 音视频处理技术 + 网络传输技术的横向技术应用集合体，而公共互联网不是为了实时通信设计的。有关实时音视频开发时的技术难题请参见《音视频云声网Agora：从demo到实用，中间还差1万个WebRTC》：http://www.52im.net/article-119-1.html

本文是一篇详细介绍实时语音通讯过程中的丢包补偿技术的文章。

系列文章

本文是系列文章中的第11篇，本系列文章的大纲如下：

内容概述

现如今，随着移动互联网越来越普及，实时语音通讯应用越来越流行，但因网络状况及相关因素的影响，实时语音通讯的丢包问题在所难免，与视频不同，语音丢包处理不佳，会让通话双方体验非常糟糕。好在已经有越来越成熟的丢包补偿技术。

丢包补偿技术可以分为两类：基于发送端补偿和基于接受端补偿。基于发送端补偿包括前向差错纠正、交织和重传技术；基于接受端补偿包括了多种错误隐蔽算法。

基于发送端的丢包补偿技术原理

1简述

基于发送端补偿可以分为两类：主动重传（本文不讨论）和被动通道编码。被动通道编码包含传统的前向差错纠正技术（FEC）和基于交织的技术。按照和媒体内容的关系，前向差错纠正包括与媒体无关的方法和利用音频属性的媒体相关方法。这些总结如图1所示。

即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解_1.jpg

为了便于讨论，我们把一个语音包区分为多个单元。

2与媒体无关前向差错纠正

这种方式中每n个媒体数据包附带k个校验包。校验包的每个比特都是由相关的数据包的同位置比特产生的。图2是每4个媒体数据包附带1个校验包的情况。

优点：该方式补偿与具体的媒体内容无关，计算量小，易于实施。
缺点：不能立即解码，引入延时，带宽增加。

即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解_2.jpg

3媒体相关前向差错纠正

一种简单的抗丢包方式是，采用多个包传送同样的音频单元。一旦丢了一个，信息可以从另外一个包含该单元的恢复出来。图3表示了媒体相关前向差错纠正的原理。

第一个传输的复本称为主要编码，第二个传输的复本称为次要编码。次要编码可以是和第一个相同，但是大部分采用较低码率和较低音质的编码技术。编码器的选择取决于带宽需求和计算复杂度需求。

次要编码采用以下方法：

即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解_3.jpg

短时能量和过零率测量；
低比特分析合成编码，比如LPC(2.4-5.6kb/s)；
全速率GSM编码(13.2kb/s)。

如果主要编码器能做到高音质和低码率，那么次要编码器可以采用和主要编码器一样的方法。比如，ITU G.723.1可以采用这种方式，因其音质好，码率5.3/6.3kb/s，但计算量大。

媒体相关前向差错纠正引起了包大小的额外开销。比如，8kHz PCM U律的主要编码器占用64kb/s带宽，全速率GSM编码的次要编码器占用13.2kb/s带宽，这样就增加了20%的带宽开销。但是，额外的带宽开销并不是固定而是可变的。分析表明，利用语音的特性，并不需要在每个语音包附加媒体相关前向差错纠正，加上这些策略，可以节省30%的带宽。

媒体相关前向差错纠正的一个好处就是不会引入大的延时，最多也就是一个包的延时。这适合实时交互的应用。

4交织

当我们考虑比语音包还小的语音单元并且可以承受较大的延时，交织是一种很有用的抗丢包技术。语音单元在传输之前重新排序，这样在传输流中原来领近的语音单元变成有规律间隔的单元，接收端再按原来的顺序排列回来。图4显示20ms包分为5ms单元的例子。可以看到传输的一个丢包变成了分散的多包中的单元丢失。

即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解_4.jpg

交织带来两个好处：

长时间的丢包给听觉带来不舒适和难以理解，但是短时间的单元丢失是更易被听觉接受的，也容易理解；
错误隐藏比较容易处理短时间的单元丢失，因为时间短语音的变化小。

交织的不足就是也会引入延时，只适合非交互式的应用。交织的另外一大好处就是不会引起带宽需求的增加。

基于接收端的丢包补偿技术原理

1简述

当发送端不能做到较好的丢包补偿或发送端不能参与丢包补偿时，需要在接受端进行丢包补偿。错误隐蔽算法就是接受端的丢包补偿技术，它产生一个与丢失的语音包相似的替代语音。这种技术的可能性是基于语音的短时语音相似性，它可以处理较小的丢包率（<15%）和较小的语音包（4-40ms）。当丢包的长度达到音素的长度（5-100ms），该技术就不适应了，因为整个音素都会丢失。

基于接收端的差错隐藏技术可以分为三类：

即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解_5.jpg

2基于插入的方法

插入一个填充包来修复丢包，填充包一般都很简单，比如静音包、噪声包或重复前面的包。虽然容易实现。但这种方法的效果是很差的。该方式的缺点就是没有利用语音的信息来重新产生信号。

拼接法（Splicing）：直接把丢包两端的语音拼接起来，这种最简单的方法不但打乱了语音的时钟顺序，而且只适合很小的丢包间隔（4-16ms）和极低的丢包率，丢包率大于3%就不能忍受了。

静音置换法（Silence substitution）：该方法在丢包处加入静音，这样保持了语音的时钟顺序。它只有在很小的包大小（<4ms）和很低的丢包率（<2%）是有效的。随着包大小的增加，他的性能明显下降，到40ms的包大小就完全不能接受了。

噪声置换法（Noise substitution）：该方法在丢包处加入背景噪声或舒服噪声。它比静音置换法好处是提高了语音的可理解性，效果较好。

重复法（Repetition）：利用接受到的最近包来重复代替丢失的包，具有低计算量和适度的音质。较长的后续丢失包可以衰减重复的包来产生。比如GSM中，丢包前20ms采用重复，后续320ms的通过衰减重复包到零。

3基于插值的方法

该方式通过某种形式的模式匹配和插值技术以期望得到与原来丢包相似的代替包。该方式比插入方法实现难度要大但效果好些。该方式相对插入法的好点就是考虑到了语音的变化信息来产生信号。

波形置换法（Waveform substitution）：该方式使用丢包前（可选后）的语音来找到合适的信号代替丢包。它通过单端或双端模式来确认合适的基音周期。单端模式时，基因周期重复跨越丢包区域，双端模式时需要对两边的周期进行插值。

基音波形复制法（Pitch waveform replication）：这是一种带有基音周期检测算法的改进型波形置换法。它利用丢包双端的信息，在无声状态时可以重复前面的包，有声状态时重复基音波形。其效果比波形置换法要好。

时间尺度修正法（Time scale modification）：该方法允许语音从丢包两端按基音周期伸展来跨越丢包区域，在两者交叠的地方进行平均。该方法计算量较大，但是效果比前面两个好些。

4基于重构的方法

该方式通过丢包前后的解码信息来重构产生一个补偿包。该方式音质最好但是实现难度也是最大的。重构修复技术使用语音压缩算法的知识来获得编码参数，这样丢失的包就可以合成。该方法依赖于编码算法，但是由于有大量信息可用，效果较好，计算量也大。

传输状态插值法（Interpolation of transmitted state）：对变换域编码和线性预测编码而言，解码器可以在传输状态之间进行插值。比如 ITU G.723.1对丢包两端的线性预测系数进行插值，使用原先帧的周期激励。这种方法的计算量和解码是一样的，不会增加。

基于模型的恢复法（Model-based recovery）：该方法把丢包前后的语音嵌入到一个语音模型中用来产生丢失的包。有研究者采用过去的样本对语音进行自回归分析建模。这种方法的适应性是因为，第一，间隔的语音帧如果足够小（8-10ms）就有很强的相关性；第二，大部分的低比特率编码技术就是采用的自回归分析和激励信号的模型。

错误隐藏技术的复杂度和质量关系：

即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解_7.jpg

要获得好的丢包补偿效果就必须采用复杂的算法。上图显示了各种错误隐蔽算法的复杂度和质量对应关系，可以根据需要采用。比如带有衰减的包重复法是一种折衷方案。

应用建议

1非交互式应用

对于非交互式的语音应用，比如多点广播，对延时的要求没有音质高。交织是强烈推荐的丢包补偿技术，对于交织后的语音，还要采用合适的错误隐蔽算法。与媒体无关的前向误差纠正技术也适合这种应用。

2交互式应用

交互式的应用比如IP电话、即时通讯应用中的实时语音聊天等，对延时很敏感，因此，交织和与媒体无关的前向误差纠正技术都不适合这种应用。媒体相关的前向误差纠正技术只引入很小的延时和较小的带宽增加，是较好的选择，可以利用低比特率的次要编码器获得丢包补偿效果。另外，还可以采用带有衰减的包重复法等效果较好计算简单的错误隐蔽算法进一步提高音质。

附录：更多实时音视频技术文章

[1] 开源实时音视频技术WebRTC的文章：
《开源实时音视频技术WebRTC的现状》
《简述开源实时音视频技术WebRTC的优缺点》
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《WebRTC实时音视频技术的整体架构介绍》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《WebRTC实时音视频技术基础：基本架构和协议栈》
《浅谈开发实时视频直播平台的技术要点》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《实时通信RTC技术栈之：视频编解码》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
《了不起的WebRTC：生态日趋完善，或将实时音视频技术白菜化》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《融云技术分享：基于WebRTC的实时音视频首帧显示时间优化实践》
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料：
《实时语音聊天中的音频处理与编码压缩技术简述》
《网易视频云技术分享：音频处理与压缩技术快速入门》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《声网架构师谈实时音视频云的实现难点(视频采访)》
《浅谈开发实时视频直播平台的技术要点》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡》
《如何用最简单的方法测试你的实时音视频方案》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《移动端实时音视频直播技术详解（一）：开篇》
《移动端实时音视频直播技术详解（二）：采集》
《移动端实时音视频直播技术详解（三）：处理》
《移动端实时音视频直播技术详解（四）：编码和封装》
《移动端实时音视频直播技术详解（五）：推流和传输》
《移动端实时音视频直播技术详解（六）：延迟优化》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《IM实时音视频聊天时的回声消除技术详解》
《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》
《如何优化传输机制来实现实时音视频的超低延迟？》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《Android直播入门实践：动手搭建一套简单的直播系统》
《网易云信实时视频直播在TCP数据传输层的一些优化思路》
《实时音视频聊天技术分享：面向不可靠网络的抗丢包编解码器》
《P2P技术如何将实时视频直播带宽降低75%？》
《专访微信视频技术负责人：微信实时视频聊天技术的演进》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《近期大热的实时直播答题系统的实现思路与技术难点分享》
《福利贴：最全实时音视频开发要用到的开源工程汇总》
《七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！》
《实时音视频聊天中超低延迟架构的思考与技术实践》
《理解实时音视频聊天中的延时问题一篇就够》
《实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序》
《写给小白的实时音视频技术入门提纲》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《新浪微博技术分享：微博短视频服务的优化实践之路》
《实时音频的混音在视频直播应用中的技术原理和实践总结》
《以网游服务端的网络接入层设计为例，理解实时通信的技术挑战》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《新浪微博技术分享：微博实时直播答题的百万高并发架构实践》
《技术干货：实时视频直播首屏耗时400ms内的优化实践》
《爱奇艺技术分享：轻松诙谐，讲解视频编解码技术的过去、现在和将来》
《零基础入门：实时音视频技术基础知识全面盘点》
《实时音视频面视必备：快速掌握11个视频技术相关的基础概念》
《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
>> 更多同类文章 ……

（原文链接：http://silversand.blog.51cto.com/820613/166161）

2 楼: kbenh · 6 年前

不错

3 楼: 新垣结衣的老公 · 6 年前

请问语音衰落需要怎么理解呢?是将语音幅值进行衰减吗

4 楼: haha748123 · 6 年前

感谢分享

5 楼: zruibin · 4 年前

信息量有点大

6 楼: wantjoy · 4 年前

说得很清楚

7 楼: Rayman · 2 年前

很不错~学习了

8 楼: JackJiang · 2 年前

引用：Rayman 发表于 2022-02-07 17:43
很不错~学习了

初七就开始卷了。。。

9 楼: Rayman · 1 年前

引用：JackJiang 发表于 2022-02-07 18:02
初七就开始卷了。。。

这不初七就上班了吗...之前哈，现在都忘光光了，又来论坛再吃吃

10 楼: JackJiang · 1 年前

引用：Rayman 发表于 2023-03-02 16:57
这不初七就上班了吗...之前哈，现在都忘光光了，又来论坛再吃吃

本文目录

前言

系列文章

内容概述

基于发送端的丢包补偿技术原理