IP和RTP语音编码带宽.docx
- 文档编号:8798053
- 上传时间:2023-05-15
- 格式:DOCX
- 页数:17
- 大小:25.06KB
IP和RTP语音编码带宽.docx
《IP和RTP语音编码带宽.docx》由会员分享,可在线阅读,更多相关《IP和RTP语音编码带宽.docx(17页珍藏版)》请在冰点文库上搜索。
IP和RTP语音编码带宽
IP和RTP语音编码带宽.txt“我羡慕内些老人羡慕他们手牵手一直走到最后。
━交话费的时候,才发现自己的话那么值钱。
speechcodec(G.711,G.723,G.726,G.729,iLBC)
各种各样的编解码在各种领域得到广泛的应用,下面就把各种codec的压缩率进行一下比较,不正确之处望各位同行指正。
Speechcodec:
现主要有的speechcodec有:
G.711,G.723,G.726,G.729,ILBC,QCELP,EVRC,AMR,SMV
主要的audiocodec有:
realaudio,AAC,AC3,MP3,WMA,SBC等,各种编解码都有其应用的重点领域。
本文主要对speechcodec相关指标进行总结:
ITU推出G.7XX系列的speechcodec,目前广泛应用的有:
G.711,G.723,G.726,G.729.每一种又有很多分支,如G.729就有g.729A,g.729Bandg.729AB
G.711:
G.711就是语音模拟信号的一种非线性量化,细分有二种:
G.711A-lawandG.711u-law.不同的国家和地方都会选取一种作为自己的标准.G.711bitrate是64kbps.详细的资料可以在ITU上下到相关的spec,下面主要列出一些性能参数:
G.711(PCM方式:
PCM=脉码调制:
PulseCodeModulation)
?
采样率:
8kHz
?
信息量:
64kbps/channel
?
理论延迟:
0.125msec
?
品质:
MOS值4.10?
G.723.1:
G.723.1是一个双速率的语音编码器,是ITU-T建议的应用于低速率多媒体服务中语音或其它音频信号的压缩算法;其目标应用系统包括H.323、H.324等多媒体通信系统,目前该算法已成为IP电话系统中的必选算法之一;编码器的帧长为30ms,还有7.5ms的前瞻,编码器的算法时延为37.5ms;编码器首先对语音信号进行传统电话带宽的滤波(基于G.712),再对语音信号用传统8000-Hz速率进行抽样(基于G.711),并变换成16bit线性PCM码作为该编码器的输入;在解码器中对输出进行逆操作来重构语音信号;高速率编码器使用多脉冲最大似然量化(MP-MLQ),低速率编码器使用代数码激励线性预测(ACELP)方法,编码器和解码器都必须支持此两种速率,并能够在帧间对两种速率进行转换;此系统同样能够对音乐和其他音频信号进行压缩和解压缩,但它对语音信号来说是最优的;采用了执行不连续传输的静音压缩,这就意味着在静音期间的比特流中加入了人为的噪声。
除了预留带宽之外,这种技术使发信机的调制解调器保持连续工作,并且避免了载波信号的时通时断。
G.726:
G.726有四种码率:
32,24,16kbit/sAdaptiveDifferentialPulseCodeModulation(ADPCM),最为常用的方式是32kbit/s,但由于其只是G.711速率的一半,所以可将网络的可利用空间增加了一倍。
G.726具体规定了一个64kbpsA-law或-lawPCM信号是如何被转化为40,32,24或16kbps的ADPCM通道的。
在这些通道中,24和16kbps的通道被用于数字电路倍增设备(DCME)中的语音传输,而40kbps通道则被用于DCME中的数据解调信号(尤其是4800kbps或更高的调制解调器)。
G.726encoder输入一般都是G.711encoder的输出:
64kbpsA-laworu-law.其算法实质就是一个ADPCM,自适应量化算法。
G.729:
G..729语音压缩编译码算法
采用算法是共轭结构的代数码激励线性预测(CSACELP),是基于CELP编码模型的算法;能够实现很高的语音质量(长话音质)和很低的算法延世;算法帧长为10ms,编码器含5ms前瞻,算法时延15ms;其重建语音质量在大多数工作环境下等同于32kb/s的ADPCM(G.726),MOS分大于4.0;编码时输入16bitPCM语音信号,输出2进制比特流;译码时输入为2进制比特流,输出16bitPCM语音信号;在语音信号8KHz取样的基础上,16bit线性PCM后进行编码,压缩后数据速率为8Kbps;具有相当于16:
1的压缩率。
G.729系列在当前的VOIP得到广泛的应用,且相关分支较多,可以直接从ITU网上得到sourcecode和相关文档。
G.729(CS-ACELP方式:
ConjugateStructureAlgebraicCodeExcitedLinearPrediction)
?
采样率:
8kHz
?
信息量:
8kbps/channel
?
帧长:
10msec
?
理论延迟:
15msec
?
品质:
MOS值3.9
iLBC(internetlowbitratecodec):
是全球著名语音引擎提供商GlobalIPSound开发,它是低比特率的编码解码器,提供在丢包时具有的强大的健壮性。
iLBC提供的语音音质等同于或超过G.729和G.723.1,并比其它低比特率的编码解码器更能阻止丢包。
iLBC以13.3kb/s(每帧30毫秒)和15.2kb/s(每帧20毫秒)速度运行,很适合拨号连接。
iLBC的主要优势在于对丢包的处理能力。
iLBC独立处理每一个语音包,是一种理想的包交换网络语音编解码。
在正常情况下,iLBC会记录下当前数据的相关参数和激励信号,以便在之后的数据丢失的情况下进行处理;在当前数据接收正常而之前数据包丢失的情况下,iLBC会对当前解码出的语音和之前模拟生成的语音进行平滑处理,以消除不连贯的感觉;在当前数据包丢失的情况下,iLBC会对之前记录下来的激励信号作相关处理并与随机信号进行混合,以得到模拟的激励信号,从而得到替代丢失语音的模拟语音。
总的来说,和标准的低位速率编解码相比,iLBC使用更多自然、清晰的元素,精确的模仿出原始语音信号,被誉为更适合包交换网络使用的可获得高语音质量的编解码。
此外,大部分标准的低位速率编解码,如G.723.1和G.729,仅对300Hz——3400Hz的频率范围进行编码。
在这个频率范围里,用G.711编解码所达到的语音质量,就是传统PSTN网络进行语音通话的效果。
iLBC充分利用了0——4000Hz的频率带宽进行编码,拥有超清晰的语音质量,这大大超出传统300Hz——3400Hz的频率范围。
广受欢迎的Skype网络电话的核心技术之一就是iLBC语音编解码技术,GlobalIPSound称该编码器语音品质优于PSTN,而且能忍受高达30%的封包损失。
总的来说,在相同的包交换通信条件下,iLBC的语音质量效果比G.729、G.723.1以及G.711更好,声音更加圆润饱满,且丢包率越高,iLBC在语音质量上的优势就越明显!
目前,在国际市场上已经有很多VoIP的设备和应用厂商把iLBC集成到他们的产品中。
如:
Skype,Nortel等。
在国内市场上,目前尚无VoIP厂家正式推出支持“iLBC”的网关设备,迅时公司率先推出支持“iLBC”的中继网关和IAD设备。
更多资料你链接:
www.itu.int
http:
//www.ilbcfreeware.org/documentation.html#presentations
http:
//itbbs-
http:
//en.wikipedia.org/wiki/G.726
http:
//www.itu.int/rec/T-REC-G.726/e
如何计算一路话音消耗的带宽
在voice这方面,是如何计算使用某种codec所消耗的带宽呢?
在默认情况下,把模拟话音转换为数字话音后,按20ms一段20ms一段切开,用rtp封装起来,然后包上udpheader,ipheader,最后是layer2的包头,然后发出去。
假设咱们用g.729编码,并在ethernet上传输。
一起来算算一路话音需要多大带宽吧。
g.729每路话音是8kbit/s,那么开始转换:
8000bps/8=1000bytes/s,得到g.729每秒需要带宽1000bytes
那么默认都是把20ms的话音封成一个packet,也就可以算出1秒内发送多少个packet:
1s/20ms=50个
也就是说g.729每20ms需要的带宽为:
1000bytes/s/50=20bytes/s
之后以太网帧头6-byte,ip包头20-byte,udp包头8-byte,rtp包头12-byte,这样,再加上g.729的payload为20bytes,也就是说每20ms就要产生一个6+20+8+12+20=66-byte长度的帧,那么一秒就要发送50个66-byte,等于3300-byte,转成kbit/s:
3300byte/s*8/1000=26.4kbit/s
最终得出g.729一路话音占用带宽(包括layer2header)为26.4kbps
本文来自CSDN博客,转载请标明出处:
语音编码的带宽计算
VOIPBandwidthconsumptionnaturallydependsonthecodecused.?
?
VOIP消耗的带宽一般取决于所使用的语音编码.
Whencalculatingbandwidth,onecan'tassumethateverychannelisusedallthetime.Normalconversationincludesalotofsilence,whichoftenmeansnopacketsaresentatall.Soevenifonevoicecallsetsuptwo64KbitRTPstreamsoverUDPoverIPoverEthernet(whichaddsoverhead),thefullbandwidthisnotusedatalltimes.?
?
计算带宽时,不能假设每一个通道都处于使用状态.正常的通话过程包括一系列的静音,也就意味着并不是一直都有包在传送.所以一个语音呼叫建立两个经过UDP,IP和以太网的64Kbit的RTP流(总开销),全部带宽并末一直被使用.
Acodecthatsendsa64kbstreamresultsinamuchlargerIPnetworkstream.ThemaincauseoftheextrabandwidthusageisIPandUDPheaders.VoIPsendssmallpacketsandso,manytimes,theheadersareactuallymuchlargerthanthedatapartofthepacket.?
?
一个传送64kb流的语音编码很大程度上都是IP网络流的结果.额外的带宽使用主要是IP或UDP头的增加.VOIP只传送少量的包,很多时候,实际上是包头远远大于包数据.
Codec?
?
BR?
?
NEB
G.71164Kbps87.2Kbps
G.7298Kbps31.2Kbps
G.723.16.4Kbps21.9Kbps
G.723.15.3Kbps20.8Kbps
G.72632Kbps55.2Kbps
G.72624Kbps47.2Kbps
G.72816Kbps31.5Kbps
iLBC15Kbps27.7Kbps?
?
BR=Bitrate
NEB=NominalEthernetBandwidth(onedirection)
根据我的使用经验,8K的G.729加上IP封装后达到32K,为了防封杀,还有的用户使用IPSec设备将语音做成VPN,这样G.729加上IP封装,再加上VPN会达到60多K。
注:
头三段中文是我自己译过来的,所以读起来并不怎么准确,而且会感觉别扭,呵呵.多多包涵了.有兴趣的朋友可以再译一次.以供借鉴.
集群通软交换电话-所需带宽说明
VoIP所需要的带宽,通常取决于它所使用的codec编码方法。
在计算带宽时,不能假定每个通道总是在使用之中。
通常的会话过程中包括大量的静默时段,就是不发送任何数据包。
一个会话建立了两个64kbps的RTP流,在UDP/IP/Ethernet上,并非在所有的时间都使用全部的带宽。
一种编码方法发送64kbps的数据流,会导致大得多的IP网的数据流,引起额外带宽的主要原因是IP和UDP的报文头.当VoIP发送小的数据包时,在大多数时候,报文头实际上要比包中的数据大得多。
下面的表列出了各种编码方法,所需要的带宽:
编码方法
编码所需带宽
实际所需要的网络带宽
G.711
64Kbps
87.2Kbps
G.729
8Kbps
31.2Kbps
G.723.1
6.4Kbps
21.9Kbps
G.723.1
5.3Kbps
20.8Kbps
G.726
32Kbps
55.2Kbps
G.726
24Kbps
47.2Kbps
G.728
16Kbps
31.5Kbps
编码所需带宽,是指理论上所需要的带宽。
但在实际的传输过程中,还要付出其他的消耗,如报文头。
真正需要的带宽是实际所需要的网络带宽,这是大致的数值,而不是严格的精确值。
实际所需要的网络带宽通常是以太网所需要的带宽,或者是ppp连接所要的带宽。
QQ使用的编码技术GIPS,实际使用起来感觉声音比较清晰,相对于SIP的编码就显得声音有些不好,请问,GIPS理论占用的带宽有多大?
能不能在SIP加入GIPS编码方式?
GIPS公司用的语音编码技术是iLBC编码。
iLBC若采30ms一帧,则理论带宽需要13.33kbps。
若20ms一帧,则理论带宽需要15.2kbps。
iLBC的语音质量要比G.729A好些,但是能够容忍丢失更多的包;也就是在丢包后,iLBC恢复能力更强。
iLBC计算复杂度与G.729A差不多。
都是计算度比较复杂的算法。
SIP终端中,也有使用iLBC编码的。
skype、QQ在语音编码上并没有什么优势。
由于它们是私有协议,目前在穿透私网(NAT)和防火墙上,更好做些,所以媒体流的路径,可能比SIP标准(目前)好做些而已。
穿透易,路径选得近些,音质就显得好些。
G711在大约有100Kbps带宽时,有很好的语音质量。
G.726在大约有50Kbps带宽时,有好的语音质量。
G.729在大约有30Kbps带宽时,有好的语音质量。
GIPS公司用的语音编码技术是带宽可变的码率,也就是根据网络实际的带宽状态,调整语音编码的压缩比率。
也就是带宽越少,语音压缩得越厉害,失真损失越多;带宽越好,就压缩不厉害,失真损失少。
注意语音编码用的压缩,都是有损压缩,也就压缩后语音会些失真。
iLBC与迅时通信
iLBC背景和优势
iLBC技术与Skype
什么是iLBC?
iLBC是一种专为包交换网络通信设计的编解码,优于目前流行的G.729、G.723.1,对丢包进行了特有处理,既使在丢包率相当高的网络环境下,仍可获得非常清晰的语音效果。
iLBC所占用带宽?
30msptime的iLBC所占用的总通信带宽比通常采用的ptime20ms的G.729的带宽还要小,以下是iLBC与传统编解码占用带宽列表:
iLBC——语音质量的飞跃
语音质量一直是VoIP应用的主要难点,如何保证和提高IP网络传输语音的通话效果,是VoIP应用迫切需要解决的问题。
“iLBC”编解码的出现,解决了在包交换的IP网络中,传输语音所遇到的网络丢包严重影响通话质量等实际问题,实现了“语音质量的飞跃”。
下图为在不同的网络丢包环境下,使用iLBC与G.729A、G.723.1编解码的语音质量比较。
图1.iLBC与G.729A、G.723.1的比较(Dynastat,Inc)
无论在高丢包率条件下还是在没有丢包的条件下,iLBC的语音质量都优于目前流行的G.723.1,G.729A等标准编解码;而且丢包率越大,使用iLBC的语音质量优势越明显。
通常情况下,为了衡量IP网络语音质量,将≥5%丢包率的网络情况定义为VoIP的极限网络条件。
经过语音质量测试,即使在5%丢包率的情况下,iLBC仍然能够提供相当于GSM手机的语音质量。
RTP冗余技术简介
众所周知,VoIP是一种利用RTP实时传输协议在包易丢失的Internet网上传输语音数据的技术。
RTP基于无连接UDP的应用协议,它不提供语音数据包的重传机制,这就要求VoIP技术在网络传输中应尽可能减少语音数据包的丢失,满足语音传输的实时性要求,减少网络丢包对语音质量的影响。
图1.常用编码在不同网络丢包条件下的语音质量对比
由上图可见,随着网络丢包率的增加,各种编解码的PESQ[1](PerceptualEvaluationofSpeechQuality)分值都有很大程度的下降。
为此,迅时通信提出RTP冗余机制,以改善由语音包传送丢失而引起的语音质量。
RTP冗余技术
早在1997年,IETF就已经制定了RFC2198(RTPPayloadforRedundantAudioData)协议,标准化多媒体应用的RTP冗余技术,以改善在IP网上进行多媒体应用中的质量问题。
[1]参见国际电联(ITU)的语音质量评估标准P.862,该标准评定的PESQMOS分值越大,语音质量越好。
PESQMOS分值有效范围为[-0.5,4.5]。
RTP冗余机制是指在RTP语音包里携带当前帧和前几个帧的语音数据,以便在丢包的网络环境下,接收方可以从后续包中获取相关数据,实现对已丢失语音包的重组和恢复,解决由于网络丢包所导致的语音质量问题。
在VoIP应用的RTP冗余机制中,当网关或IAD使用某种规定的编解码(如G729A或iLBC)进行语音数据流的打包时,系统将进行插入冗余语音数据包的处理,对当前帧和前几个帧的净荷语音数据进行RTP封装;在进行语音数据流的解包时,系统将进行去除冗余语音数据的处理,对RTP包进行重组。
因此,在网络随机丢包的情况下,如果某一个RTP语音包丢失了,则接收方还可通过后续RTP语音包中的冗余数据对失去的数据进行重组和恢复,解决由于网络丢包所导致的语音质量问题。
迅时通信的RTP冗余机制可有效改善音质,其理论抗随机丢包能力高达75%;其RTP语音包中的冗余帧个数可由用户设置,其设置范围为1-3。
然而大量冗余数据也可能会造成网络拥塞增加,加剧网络丢包的问题,这可能会使采用冗余数据试图解决的包丢失问题变得更糟。
因此,用户在配置RTP冗余数据多少的时候,需要根据自己的实际网络带宽来进行调整。
ITU-T(国际电信联盟)的G.729编码方式为例,这是一种8kbit/s的编码算法,该种编码抗随机比特错误的能力与抗随机突发消失帧的能力相同。
在噪声较大的环境下,它能有更好的语音质量。
G.729帧长为10个八位组(octet),有声段帧格式为:
每帧为10ms。
每帧长10个八位组。
每个RTP包可以放零个、一个或多个G.729帧。
抽样率8000Hz。
缺省打包时间段20ms。
Internet话音分组传输技术
在IP网中传输层有两个并列的协议:
TCP和UDP。
TCP是面向连接的,它提供高可靠性服务;UCP是无连接的,它提供高效率的服务。
高可靠性的TCP用于一次传输要交换大量报文的情况,高效率的UDP用于一次交换少量的报文或实时性要求较高的信息。
实时传输协议RTP提供具有实时特征的、端到端的数据传输业务,可以用来传送声音和活动图像数据,在这项数据传输业务中包含了装载数据的标识符、序列号、时戳以及传送监视。
通常RTP的协议数据单元是用UDP分组来承载的。
而且为了尽量减少时延,话音净荷通常都很短。
图3表示一个IP话音分组的结构,图中IP,UDP和RTP的控制头都按最小长度计算。
这种IP话音分组的开销很大,约为66%~80%。
于是有人提出了组合RTP分组的概念
?
采用这种组合复用方法的确可以大大提高传输效率,但是目前尚无标准。
如果支持RTP的网络能提供组播功能,则它也可用组播方式将数据送给多个目的用户。
RTP本身没有提供任何确保及时传送的机制,也没有提供任何传输质量保证的机制,因而业务质量完全由下层网络的质量来决定。
同时,RTP不保证数据包按序号传送,即使下层网络提供可靠性传送,也不能保证数据包的顺序到达。
包含在RTP中的序列号就是供接收方重新对数据包排序之用。
与RTP相配套的另一个协议是RTCP协议。
RTCP是RTP的控制协议,它用于监视业务质量并与正在进行的会话者传送信息。
因此,我们可以根据这个图3计算出每路G.729编码的带宽占用量:
带宽占用=传输的总字节数/传输的总时间
带宽=(20byte(IP头)+8byte(UDP头)+12byte(RTP头)+20byte(数据))/20ms
=60byte/20ms
以上计算公式含义为:
每20ms,需要传输的字节数包括20个字节的IP包头,8个字节的UDP包头,12各字节的RTP包头,20字节的语音数据共60字节,结果为:
3byte/ms=3000byte/s=24000bit/s=24kbit/s。
因此,理论上G.729中每个数据包包含两帧语音的编码方式,占用带宽24kbit/s,而又有封装效率的估算公式为:
封装效率=[(压缩后的语音包×n×帧长/8)]/[(压缩后的语音包×n×帧长/8)+40]。
n表示打进n个语音包。
以G.729信源编码为例,如一个RTP包打进一个语音包,则实际传送码流为40kbit/s,时延约为10ms;
如打两个语音包,则实际传送码流为24kbit/s,时延约为20ms;
如打四个语音包,实际传送码流为16kbit/s,时延为40ms。
为保证编码打包的时延,若将缺省语音包的数量定为两个,实际传送码流即为24kbit/s,而不是8kbit/s。
因此对于语音业务这类实时性要求非常高的业务,要保证语音的质量,根据ITU-T标准语音的全程往返时延应当控制在450ms为宜,编码打包后形成的单位码流通常是在20kbit/s。
由以上论述我们知道,每路G.729编码的IP语音占
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IP RTP 语音 编码 带宽