speech codec (G.711, G.723, G.726, G.729, iLBC)
各种各样的编解码在各种领域得到广泛的应用，下面就把各种codec的压缩率进行一下比较，不正确之处望各位同行指正。
Speech codec：
现主要有的speech codec 有:
G.711, G.723, G.726 , G.729, ILBC，QCELP, EVRC, AMR, SMV
主要的audiocodec 有:
real audio, AAC,AC3, MP3, WMA, SBC等，各种编解码都有其应用的重点领域。
本文主要对speech codec相关指标进行总结：
ITU 推出G.7XX系列的speechcodec, 目前广泛应用的有：G.711，G.723,G.726, G.729. 每一种又有很多分支，如G.729就有g.729A, g.729Band g.729AB
G.711:
G.711就是语音模拟信号的一种非线性量化，细分有二种:G.711 A-lawand G.711 u-law.不同的国家和地方都会选取一种作为自己的标准. G.711 bitrate 是64kbps. 详细的资料可以在ITU 上下到相关的spec，下面主要列出一些性能参数：
G.711（PCM方式：PCM＝脉码调制 ：Pulse Code Modulation）
• 采样率：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），并变换成16 bit线性PCM码作为该编码器的输入；在解码器中对输出进行逆操作来重构语音信号；高速率编码器使用多脉冲最大似然量化（MP-MLQ），低速率编码器使用代数码激励线性预测（ACELP）方法，编码器和解码器都必须支持此两种速率，并能够在帧间对两种速率进行转换；此系统同样能够对音乐和其他音频信号进行压缩和解压缩，但它对语音信号来说是最优的；采用了执行不连续传输的静音压缩，这就意味着在静音期间的比特流中加入了人为的噪声。除了预留带宽之外，这种技术使发信机的调制解调器保持连续工作，并且避免了载波信号的时通时断。
G.726:
G.726有四种码率：, 32, 24, 16 kbit/s Adaptive Differential Pulse Code Modulation(ADPCM)，最为常用的方式是 32 kbit/s，但由于其只是 G.711速率的一半，所以可将网络的可利用空间增加了一倍。G.726具体规定了一个 64 kbpsA-law 或 µ-law PCM 信号是如何被转化为40, 32, 24或16 kbps 的ADPCM 通道的。在这些通道中，24和16 kbps 的通道被用于数字电路倍增设备(DCME)中的语音传输，而40 kbps 通道则被用于 DCME 中的数据解调信号（尤其是4800 kbps 或更高的调制解调器）。
G.726 encoder 输入一般都是G.711 encoder的输出：64kbps A-law or u-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网上得到source code 和相关文档。
G.729（CS-ACELP方式：Conjugate Structure Algebraic Code Excited Linear Prediction）
• 采样率：8kHz
• 信息量：8kbps／channel
• 帧长：10msec
• 理论延迟：15msec
• 品质：MOS值3.9
iLBC(internet low bitrate codec):
是全球著名语音引擎提供商Global IP Sound开发，它是低比特率的编码解码器，提供在丢包时具有的强大的健壮性。iLBC 提供的语音音质等同于或超过 G.729 和 G.723.1，并比其它低比特率的编码解码器更能阻止丢包。iLBC 以13.3 kb/s (每帧30毫秒)和15.2 kb/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语音编解码技术，Global IP Sound称该编码器语音品质优于PSTN，而且能忍受高达30%的封包损失。
总的来说，在相同的包交换通信条件下，iLBC的语音质量效果比G.729、G.723.1以及G.711更好，声音更加圆润饱满，且丢包率越高，iLBC在语音质量上的优势就越明显！
目前，在国际市场上已经有很多VoIP的设备和应用厂商把iLBC集成到他们的产品中。如：Skype, Nortel等。在国内市场上，目前尚无VoIP厂家正式推出支持“iLBC”的网关设备，迅时公司 率先推出支持“iLBC”的中继网关和IAD设备。
如何计算一路话音消耗的带宽
在voice这方面，是如何计算使用某种codec所消耗的带宽呢？在默认情况下，把模拟话音转换为数字话音后，按20ms一段20ms一段切开，用rtp封装起来，然后包上udp header，ip header，最后是layer 2的包头，然后发出去。
假设咱们用g.729编码，并在ethernet上传输。一起来算算一路话音需要多大带宽吧。
g.729每路话音是8kbit/s，那么开始转换：
8000bps / 8 = 1000 bytes/s，得到g.729每秒需要带宽1000 bytes
那么默认都是把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一路话音占用带宽（包括layer2 header）为26.4kbps
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/worldpharos/archive/2009/03/10/3977018.aspx
语音编码的带宽计算
VOIP Bandwidth consumption naturally depends on the codecused.
VOIP消耗的带宽一般取决于所使用的语音编码.
When calculating bandwidth, one can't assume that everychannel is used all the time. Normal conversation includes a lot of silence,which often means no packets are sent at all.So even if one voice call sets uptwo 64 Kbit RTP streams over UDP over IP over Ethernet (which adds overhead),the full bandwidth is not used at all times.
计算带宽时,不能假设每一个通道都处于使用状态.正常的通话过程包括一系列的静音,也就意味着并不是一直都有包在传送.所以一个语音呼叫建立两个经过UDP,IP和以太网的64Kbit的RTP流(总开销),全部带宽并末一直被使用.
A codec that sends a 64kb stream results in a much largerIP network stream. The main cause of the extra bandwidth usage is IP and UDPheaders. VoIP sends small packets and so, many times, the headers are actuallymuch larger than the data part of the packet.
一个传送64kb流的语音编码很大程度上都是IP网络流的结果.额外的带宽使用主要是IP或UDP头的增加.VOIP只传送少量的包,很多时候,实际上是包头远远大于包数据.
Codec BR NEB
G.711 64 Kbps 87.2 Kbps
G.729 8 Kbps 31.2 Kbps
G.723.1 6.4 Kbps 21.9 Kbps
G.723.1 5.3 Kbps 20.8 Kbps
G.726 32 Kbps 55.2 Kbps
G.726 24 Kbps 47.2 Kbps
G.728 16 Kbps 31.5 Kbps
iLBC 15 Kbps 27.7 Kbps
BR = Bit rate
NEB = Nominal Ethernet Bandwidth (one direction)
根据我的使用经验，8K的G.729加上IP封装后达到32K,为了防封杀，还有的用户使用IP Sec设备将语音做成VPN，这样G.729加上IP封装，再加上VPN会达到60多K。
注:头三段中文是我自己译过来的,所以读起来并不怎么准确,而且会感觉别扭,呵呵.多多包涵了.有兴趣的朋友可以再译一次.以供借鉴.
集群通软交换电话-所需带宽说明
VoIP所需要的带宽，通常取决于它所使用的codec编码方法。在计算带宽时，不能假定每个通道总是在使用之中。通常的会话过程中包括大量的静默时段，就是不发送任何数据包。
一个会话建立了两个64kbps的RTP流，在UDP/IP/Ethernet上,并非在所有的时间都使用全部的带宽。
一种编码方法发送64kbps的数据流，会导致大得多的IP网的数据流，引起额外带宽的主要原因是IP和UDP的报文头.当VoIP发送小的数据包时，在大多数时候，报文头实际上要比包中的数据大得多。
下面的表列出了各种编码方法，所需要的带宽：
| 编码方法 | 编码所需带宽 | 实际所需要的网络带宽 |
| G.711 | 64 Kbps | 87.2 Kbps |
| G.729 | 8 Kbps | 31.2 Kbps |
| G.723.1 | 6.4 Kbps | 21.9 Kbps |
| G.723.1 | 5.3 Kbps | 20.8 Kbps |
| G.726 | 32 Kbps | 55.2 Kbps |
| G.726 | 24 Kbps | 47.2 Kbps |
| G.728 | 16 Kbps | 31.5 Kbps |
编码所需带宽，是指理论上所需要的带宽。但在实际的传输过程中，还要付出其他的消耗，如报文头。真正需要的带宽是实际所需要的网络带宽，这是大致的数值，而不是严格的精确值。实际所需要的网络带宽通常是以太网所需要的带宽，或者是ppp连接所要的带宽。
QQ使用的编码技术GIPS，实际使用起来感觉声音比较清晰，相对于SIP的编码就显得声音有些不好，请问，GIPS理论占用的带宽有多大？能不能在SIP加入GIPS编码方式？
GIPS公司用的语音编码技术是 iLBC编码。
iLBC若采30ms一帧，则理论带宽需要13.33 kbps。若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是一种专为包交换网络通信设计的编解码，优于目前流行的G.729、G.723.1，对丢包进行了特有处理，既使在丢包率 相当高的网络环境下，仍可获得非常清晰的语音效果。
iLBC所占用带宽？
30ms ptime的iLBC所占用的总通信带宽比通常采用的ptime 20ms的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手机的语音质量。
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的控制协议，它用于监视业务质量并与正在进行的会话者传送信息。
因此，我们可以根据这个图３计算出每路G.729编码的带宽占用量：
带宽占用＝传输的总字节数 / 传输的总时间
带宽＝(20byte（IP头）+8byte（UDP头）+12byte（RTP头）+20byte(数据))/２０ms
=60byte/20ms
以上计算公式含义为：每20ms，需要传输的字节数包括20个字节的IP包头，8个字节的UDP包头，12各字节的RTP包头，20字节的语音数据共60字节，结果为：3 byte/ms=3000 byte/s=24000bit/s＝24kbit/s。
因此，理论上G.729中每个数据包包含两帧语音的编码方式，占用带宽24kbit/s，而又有封装效率的估算公式为：
封装效率=[（压缩后的语音包× n × 帧长/ 8）] / [（压缩后的语音包×n× 帧长/ 8 ）＋40] 。
n表示打进n个语音包。
以G.729信源编码为例，如一个RTP包打进一个语音包，则实际传送码流为40kbit/s，时延约为 10 ms；
如打两个语音包，则实际传送码流为24kbit/s，时延约为 20ms；
如打四个语音包，实际传送码流为16kbit/s，时延为40ms。
为保证编码打包的时延，若将缺省语音包的数量定为两个，实际传送码流即为24kbit/s，而不是8kbit/s。
因此对于语音业务这类实时性要求非常高的业务，要保证语音的质量，根据ITU-T标准语音的全程往返时延应当控制在450ms为宜，编码打包后形成的单位码流通常是在20kbit/s。
由以上论述我们知道，每路G.729编码的IP语音占用约20Kbit/s的带宽，实际占用的总带宽数＝语音总路数*20Kbit/s。
语音编解码方式及其所占用的带宽的关系
语音编码的带宽和实际所占用的带宽是不同的，语音编码的带宽是实际语音包的带宽，而语音包在IP网络上传输时，还需要增加各种包头，如RTP包头、UDP包头、IP包头。由于语音包本身很小，所以相对而言这些额外的带宽是很可观的。在下表中列出了各种编码方式下的打包时长以及所对应的实际带宽。
实际带宽与语音编码和打包时长的关系：
语音编解码 打包时长 语音数据带宽 实际所占带宽
G.723.1(5.3K) 30ms 5.3K 5.3*(20+40)/20 = 16.2K
G.723.1(5.3K) 60ms 5.3K 5.3*(40+40)/40 = 10.6K
G.723.1(6.3K) 30ms 6.3K 6.3*(24+40)/24 = 16.8K
G.723.1(6.3K) 60ms 6.3K 6.3*(48+40)/48 = 11.6K
G.729 20ms 8K 8*(20+40)/20 = 24K
G.729 60ms 8K 8*(60+40)/60 = 13.3K
由上表可以很明显的看出，打包时间越长，所占用的实际带宽越小，但时延越大。
说明
1、RTP包头：12bytes UDP包头：8bytes IP包头：20bytes。
2、表中的带宽计算中没有包含物理帧头，需根据具体网络而定。
3、表中的带宽计算中，没有考虑静音检测。静音检测的效率按60％计算。
音频：
名称 采样率 采样精度 占用带宽(kbps)
| G.723.1 | 8k | 16bit | 5.3 ~ 6.3kbps |
| ILBC | 8k | 16bit | 13.33 ~ 15.2kbps |
| CCITT A-LAW | 8k | 16bit | 64 ~ 128kbps |
视频：
| 图像分辨率 —— 帧数 | 占用带宽(kbps) |
| 160 × 120 —— 5 ~ 30fps | 20 ~ 100kbps |
| 176 × 144 —— 5 ~ 25fps | 20 ~ 110kbps |
| 320 × 240 —— 5 ~ 30fps | 40 ~ 200kbps |
| 352 × 288 —— 5 ~ 25fps | 40 ~ 220kbps |
| 640 × 480 —— 5 ~ 30fps | 120 ~ 1000kbps |
| 720 × 576 —— 5 ~ 25fps | 120 ~ 1500kbps |
国际电信联盟 G 系列典型语音压缩标准的参数比较
| 算法 | 类型 | 码率 (kbit/s) | 算法延时 (ms) |
| G.711 | A-Law / μ -Law | 64 | 0 |
| G.722 | SB-ADPCM | 64/56/48 | 0 |
| G.723.1 | MP-MLQ/ACELP | 6.3/5.3 | 37.5 |
| G.726 | ADPCM | 16/24/32/40 | 0 |
| G.727 | Embedded ADPCM | 16/24/32/40 | 0 |
| G.728 | LD-CELP | 16 | < 2 |
| G.729 | CS-ACELP | 8 | 15 |
扫一扫
2655
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
