深入剖析iLBC的丢包补偿技术(PLC)

转自:http://blog.csdn.net/wanggp_2007/article/details/5136609

丢包补偿技术(Packet Loss Concealment——PLC)是iLBC Codec中非常重要的一项技术,更是VOIP Codec应用中不可缺少的组成部分。iLBC的PLC只是在解码端进行封包补偿处理。在解码端根据收到的bitstream逐帧进行解码的过程中,iLBC decoder首先拿到每帧的 bitstream 要判断当前帧是否完整,如果没有问题则按照正常的iLBC 解码流程重建语音信号,见《深入剖析iLBC 解码器原理》;如果发生了语音封包丢失,那么就进入PLC单元进行处理。PLC主要根据前一帧的解码信息,利用基音同步重复的方法近似替代当前的丢失帧,以达到丢包补偿。

一、PLC unit 的几种情形

1、过去帧、当前帧都接收正确

进入正常的iLBC decoder解码流程,需要保存当前帧的状态信息,这些状态信息包括LPC信息、解码后的残差信号等。如果下一帧的比特率丢失的话,就要用到这些保存的信息。

2、仅当帧发生丢包

如果当前帧没有丢失,那么进入PLC unit重建LPC系数和残差信号。后面会详细介绍LPC和残差信号的补偿方法。

3、连续多帧发生丢包

如果发生连续多帧丢包,那么就需要多次进入PLC unit,并且需要利用经过补偿的帧状态信息。值得注意的是,越靠后面丢失的帧越难以精确的重建,所以对连续丢包的增益采用逐帧递减,以避免引入更大的信号失真。

4、过去帧经过PLC处理,需要与当前帧平滑处理

为了使经过PLC补偿的帧与接下来没有丢包的帧保持语音连续而需要进行平滑,主要根据前后帧的相关性处理。

二、PLC重建LPC系数

iLBC 的PLC对于丢失LPC的补偿是采用了过去帧的最后一个子帧的LPC系数来简单的重建。这个方法是显然的,因为无论从空间上还是时间上最后一个子帧都与当前丢失的LPC具有最大相关性。但是这种简单的复制当处理连续多帧时也显然会引入更大的失真。

三、PLC重建残差信号

激励信号(残差信号)通常可以分为两部分组成:准周期成分和类噪声成分。因此PLC实际上首先需要重建这两个部分,准周期成分可以根据测量前一帧的基音周期来近似得到,类噪声成分则可以通过产生随机噪声得到,二者的能量比例也可以借鉴前一帧的比例关系。所以首先要对前一帧进行基音检测,然后以基音同步的方式重建丢失帧的话音部分,然后利用相关性得到类噪声的增益,最后进行混合以重建整个残差信号。

在连续丢帧的情况下,为了减少各个补偿帧之间的相关性,会将能量进行逐帧递减,但依然会产生一定的听觉噪声。如果采用内插的方法,虽然可能音质会好些,但是却会引入更大的延时。

四、iLBC PLC的缺点

在连续丢帧的情况下,PLC所补偿的各个语音帧具有相同的频谱特性(相同的LPC造成)和基音频率,非常容易引入一种可察觉的噪声,尤其是当基音频率较高的时候,这种因为过分的周期性所引起的。通过适当的内插可以缓解这一问题,但往往引入更大的延时。

参考资料:

1、IETF:RFC3951.txt

2、潘搏胜《iLBC解码程序进阶处理之研究》

时间: 2024-10-21 16:32:06

深入剖析iLBC的丢包补偿技术(PLC)的相关文章

IP通信中音频编解码技术与抗丢包技术概要

此文较长,建议收藏起来看. 一.一个典型的IP通信模型 二.Server2Server技术分类 Server2Server这块也是一个专门的领域,这里只简单分个类. 1.同一国家相同运营商之间: 同一运营商之间也有丢包,在铁通,鹏博士等运营商中尤甚.并且在晚高峰的时候表现更加突出. 2.同一国家不同运营商之间: 在很多时候,由于运营商之间的结算和有限带宽的问题.运营商之间的网络不稳定. 3.不同国家之间: 同一个国家都这么多问题,不同国家的问题回更复杂,在不同的国家要选择好的机房,实时选择实时监

无线路由器wds桥接技术+丢包率

半根毛线http://www.cnblogs.com/hsd-/ 今天下午鼓捣了一下无线路由的wds桥接 算是计算机网络的作业 码来分享一下 1.首先设置主路由 我的主路由是斐讯4线 路由ip为192.168.2.1 就是简单的路由配置 在此不赘述 2.其次是副路由 副路由的ip为192.168.2.2  注意副路由ip应该与主路由的ip在一个频段 选择信道应当与主路由相同 3.勾选wds功能 大部分的路由器都有 4.点击扫描 找到主路由 连接 密钥为主路由的密码 5.查看是否wds设置成功 6

MTU-TCP/IP协议栈-linux kernel-TCP丢包重传-UDP高性能-AI-

http://view.inews.qq.com/a/20161025A0766200窄带时代的QQ QQ是窄带时代极具代表性的产品,在那个网络传输效率比较低的年代,大家还记得Google的首页吗?Google的那个简洁页面,为什么如此简洁? Google诞生于1998年,也是身处窄带时代,你会发现它的首页字节大小是小于1024的,为什么要小于1024字节,因为以太网的MTU(也就是最大传输单元)是1024,Google为了让用户在一个网络包中传输完成,所以它把页面大小降到了1024以下.这是一

深度剖析:CDN内容分发网络技术原理--转载

1.前言 Internet的高速发展,给人们的工作和生活带来了极大的便利,对Internet的服务品质和访问速度要求越来越高,虽然带宽不断增加,用户数量也在不断增加,受Web服务器的负荷和传输距离等因数的影响,响应速度慢还是经常抱怨和困扰.解决方案就是在网络传输上利用缓存技术使得Web服务数据流能就近访问,是优化网络数据传输非常有效的技术,从而获得高速的体验和品质保证. 网络缓存技术,其目的就是减少网络中冗余数据的重复传输,使之最小化,将广域传输转为本地或就近访问.互联网上传递的内容,大部分为重

为什么TCP在高时延和丢包的网络中传输效率差?

说明:有同学私信问到,为什么TCP在高时延和丢包的网络中传输效率差? Google可以搜到很多的信息,这里转译了部分IBM Aspera fasp技术白皮书的第一章节内容,作为参考. -在这个数字世界中,数字数据的快速和可靠移动,包括全球范围内的大规模数据传送,对于几乎所有行业的业务成功都变得至关重要. -然而,传统的TCP协议具有固有的性能瓶颈,特别是对于具有高往返时间(RTT)和丢包的高带宽网络上最为显著. TCP固有的传输性能瓶颈主要是由TCP的加性增/乘性减(AIMD)拥塞避免算法引起的

UDP 两种丢包处理策略:丢包重传(ARQ) 和 前向纠错(FEC)

目录 1. 两种丢包处理策略 2. 前向纠错(FEC) 3. 丢包重传(ARQ) [参考文献] 1. 两种丢包处理策略 为了保证实时性,通常适应UDP协议来针对RTP数据进行传输,而UDP无法保证数据传输的质量,所以在网络环境不好的时候,丢包是经常出现的问题,有什么策略来改善这个问题吗? 常用的方法有: 丢包重传(ARQ)和前向纠错(FEC). 通常抗丢包有两种方式,FEC和ARQ.FEC是前向冗余,举个例子,发送数据A和B,增加发送一个数据C等于A和B的异或.接收方接到这3个包的任意2个包,异

节点的排队时延与丢包

节点时延中最复杂和有趣的部分是排队时延\(d_{queue}\).与其他三种时延不同,排队时延对不同的分组是不同的. 在表征排队时延时,通常使用统计量测度,比如平均排队时延.排队时延的方差和排队时延超过某些特定值的概率. 排队时延的决定因素 流量到达该队列的速率\(a\ pkt/s\) 链路的传输速率\(R\ b/s\),即队列中推出比特的速率(不是接收) 到达流量的性质,周期性到达或者以突发形式到达 流量强度与排队时延 假定所有分组都是\(L\)比特组成,且队列无限大,则称\(La/R\)为流

OS X 在Cisco无线环境下丢包分析 part 2

part 1说到,单播的ARP请求最终都被网关丢弃了,从而造成了丢包.先说我最终怎么解决的吧,我最终把核心交换上针对无线VLAN的arp inspection和dhcp snooping删掉了,然后出于安全考虑,启用了WLC(Wireless Controller)上的一个feature,该feature相当于是DHCP snooping和arp inspection的结合,功能是不让客户端私自配静态IP,只允许DHCP获取,那么有这个feature做保障,我也就放心的删掉了核心交换上的arp

Jump The Great Firewall【step16 优化丢包率】

一.为何会丢包 经过博主长期使用的经验所得,使用UDP协议在互联网上传输数据时,存在一定的丢包率.尤其是在晚间繁忙时段,丢包率更为明显,那么我们如何进行优化来降低丢包率呢? 二.如何解决 服务器端与客户端同时进行校验,在一定时间内如果发现有丢包时,发送一条新的消息通知对方重新发送该条消息 服务器端与客户端在发送消息时,每次都将一条消息发送多次 我们先来看下第一种方案:这种方案属于最传统的方式,不过该方法有一个缺点.当网络状况非常差时,发出去的请求重发消息也可能会丢失,因此对端可能会再次请求丢失的