请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 0
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解

前言


即时通讯应用中的实时音视频技术,几乎是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:更多实时音视频技术文章


[1] 开源实时音视频技术WebRTC的文章:
开源实时音视频技术WebRTC的现状
简述开源实时音视频技术WebRTC的优缺点
访谈WebRTC标准之父:WebRTC的过去、现在和未来
良心分享:WebRTC 零基础开发者教程(中文)[附件下载]
WebRTC实时音视频技术的整体架构介绍
新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?
WebRTC实时音视频技术基础:基本架构和协议栈
浅谈开发实时视频直播平台的技术要点
[观点] WebRTC应该选择H.264视频编码的四大理由
基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
简述实时音视频聊天中端到端加密(E2EE)的工作原理
实时通信RTC技术栈之:视频编解码
开源实时音视频技术WebRTC在Windows下的简明编译教程
网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料:
专访微信视频技术负责人:微信实时视频聊天技术的演进
实时语音聊天中的音频处理与编码压缩技术简述
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端实时音视频直播技术详解(一):开篇
移动端实时音视频直播技术详解(二):采集
移动端实时音视频直播技术详解(三):处理
移动端实时音视频直播技术详解(四):编码和封装
移动端实时音视频直播技术详解(五):推流和传输
移动端实时音视频直播技术详解(六):延迟优化
理论联系实际:实现一个简单地基于HTML5的实时视频直播
IM实时音视频聊天时的回声消除技术详解
浅谈实时音视频直播中直接影响用户体验的几项关键技术指标
如何优化传输机制来实现实时音视频的超低延迟?
首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?
Android直播入门实践:动手搭建一套简单的直播系统
网易云信实时视频直播在TCP数据传输层的一些优化思路
实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器
>> 更多同类文章 ……

附录2:全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

(原文链接:http://silversand.blog.51cto.com/820613/166161

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

本帖已收录至以下技术专辑

推荐方案
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部