語(yǔ)音編碼格式文檔_第1頁(yè)
語(yǔ)音編碼格式文檔_第2頁(yè)
語(yǔ)音編碼格式文檔_第3頁(yè)
語(yǔ)音編碼格式文檔_第4頁(yè)
語(yǔ)音編碼格式文檔_第5頁(yè)
已閱讀5頁(yè),還剩6頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、speech codec (G.711, G.723, G.726, G.729, iLBC)各種各樣的編解碼在各種領(lǐng)域得到廣泛的應(yīng)用,下面就把各種codec的壓縮率進(jìn)行一下比較,不正確之處望各位同行指正。Speech codec :現(xiàn)主要有的speech codec 有:G.711, G.723, G.726 , G.729, ILBC , QCELP, EVRC, AMR, SMV 主要的audiocodec 有:real audio, AAC,AC3, MP3, WMA, SBC 等,各種編解碼都有其應(yīng)用的重點(diǎn)領(lǐng)域。 本文主要對(duì)speech codec相關(guān)指標(biāo)進(jìn)行總結(jié):ITU 推出G.7

2、XX系列的speechcodec,目前廣泛應(yīng)用的有: G.711 , G.723,G.726, G.729.每一種又有很多分支,如 G.729 就有 g.729A, g.729Band g.729ABG.711:G.711就是語(yǔ)音模擬信號(hào)的一種非線性量化,細(xì)分有二種 :G.711A-lawand G.711 u-law.不同的國(guó)家和地方都會(huì)選取一種作為自己 的標(biāo)準(zhǔn).G.711 bitrate 是64kbps.詳細(xì)的資料可以在ITU上下到 相關(guān)的spec ,下面主要列出一些性能參數(shù):G.711 (PCM 方式:PCM =脈碼調(diào)制 :Pulse Code Modulation )?采樣率:8kHz

3、?信息量:64kbps / channel?理論延遲:0.125msec?品質(zhì):MOS值4.10G.723.1:G.723.1是一個(gè)雙速率的語(yǔ)音編碼器, 是ITU-T建議的應(yīng)用于低速 率多媒體服務(wù)中語(yǔ)音或其它音頻信號(hào)的壓縮算法;其目標(biāo)應(yīng)用系統(tǒng)包括H.323、H.324等多媒體通信系統(tǒng),目前該算法已成為IP電話系統(tǒng)中的必選算法之一;編碼器的幀長(zhǎng)為30ms ,還有7.5ms的前瞻,編碼器的算法時(shí)延為 37.5ms ;編碼器首先對(duì)語(yǔ)音信號(hào)進(jìn)行 傳統(tǒng)電話帶寬的濾波(基于G.712 ),再對(duì)語(yǔ)音信號(hào)用傳統(tǒng)8000-Hz速率進(jìn)行抽樣(基于 G.711 ),并變換成16 bit線性PCM碼作為 該編碼器的輸

4、入;在解碼器中對(duì)輸出進(jìn)行逆操作來(lái)重構(gòu)語(yǔ)音信號(hào); 高速率編碼器使用多脈沖最大似然量化( MP-MLQ ),低速率編碼 器使用代數(shù)碼激勵(lì)線性預(yù)測(cè)(ACELP )方法,編碼器和解碼器都 必須支持此兩種速率,并能夠在幀間對(duì)兩種速率進(jìn)行轉(zhuǎn)換;此系統(tǒng)同樣能夠?qū)σ魳?lè)和其他音頻信號(hào)進(jìn)行壓縮和解壓縮,但它對(duì)語(yǔ)音信號(hào)來(lái)說(shuō)是最優(yōu)的;采用了執(zhí)行不連續(xù)傳輸?shù)撵o音壓縮,這就意味著在靜音期間的比特流中加入了人為的噪聲。除了預(yù)留帶寬之外,這種技術(shù)使發(fā)信機(jī)的調(diào)制解調(diào)器保持連續(xù)工作,并且避免了載波信號(hào)的時(shí)通時(shí)斷。G.726:G.726 有四種碼率:,32, 24, 16 kbit/s Adaptive Differential

5、Pulse Code Modulation(ADPCM) ,最為常 用的方式是32 kbit/s ,但由于其只是 G.711速率的一半,所以可將網(wǎng)絡(luò)的可利用空間增加了一倍。G.726具體規(guī)定了一個(gè) 64 kbpsA-law 或 aw PCM 信號(hào)是如何被轉(zhuǎn)化為 40, 32, 24或16 kbps的ADPCM 通 道的。在這些通道中,24和16 kbps的通道被用于數(shù)字電路倍增設(shè)備 (DCME)中的語(yǔ)音傳輸,而40 kbps通 道則被用于DCME中的數(shù)據(jù)解調(diào)信號(hào)(尤其是 4800 kbps或更高的調(diào)制解調(diào)器)。G.726 encoder 輸入一力都是 G.711 encoder 的輸出:64k

6、bps A-law or u-law. 其算法實(shí)質(zhì)就是一個(gè) ADPCM ,自適應(yīng)量化算法。G.729:G.729語(yǔ)音壓縮編譯碼算法采用算法是共鈍結(jié)構(gòu)的代數(shù)碼激勵(lì)線性預(yù)測(cè)(CSACELP),是基于CELP編碼模型的算法;能夠?qū)崿F(xiàn)很高的語(yǔ)音質(zhì)量(長(zhǎng)話音質(zhì))和 很低的算法延世;算法幀長(zhǎng)為10ms,編碼器含5ms前瞻,算法時(shí)延15ms ;其重建語(yǔ)音質(zhì)量在大多數(shù)工作環(huán)境下等同于32kb/s的ADPCM (G.726 ) , MOS 分大于 4.0;編碼時(shí)輸入 16bitPCM 語(yǔ) 音信號(hào),輸出2進(jìn)制比特流;譯碼時(shí)輸入為2進(jìn)制比特流,輸出16bitPCM語(yǔ)音信號(hào);在語(yǔ)音信號(hào)8KHz取樣的基礎(chǔ)上,16bit

7、線性 PCM后進(jìn)行編碼,壓縮后數(shù)據(jù)速率為8Kbps ;具有相當(dāng)于16: 1的壓縮率。G.729系列在當(dāng)前的VOIP得到廣泛的應(yīng)用,且相關(guān)分支較多,可 以直接從ITU網(wǎng)上得到source code 和相關(guān)文檔。G.729 (CS-ACELP 方式:Conjugate Structure Algebraic Code Excited Linear Prediction ) ?采樣率:8kHz?信息量:8kbps / channel?幀長(zhǎng):10msec?理論延遲:15msec?品質(zhì):MOS值3.9是全球著名語(yǔ)音引擎提供商 Global IP Sound開(kāi)發(fā),它是低 比特率的編碼解碼器,提供在丟包時(shí)具

8、有的強(qiáng)大的健壯性。iLBC提供的語(yǔ)音音質(zhì)等同于或超過(guò) G.729和G.723.1 ,并比其它低比 特率的編碼解碼器更能阻止丟包。iLBC以13.3 kb/s (每幀30毫秒)和15.2 kb/s (每幀20毫秒)速度運(yùn)行,很適合撥號(hào)連接。iLBC的主要優(yōu)勢(shì)在于對(duì)丟包的處理能力。iLBC獨(dú)立處理每一個(gè)語(yǔ)音包,是一種理想的包交換網(wǎng)絡(luò)語(yǔ)音編解碼。在正常情況下,iLBC會(huì)記錄下當(dāng)前數(shù)據(jù)的相關(guān)參數(shù)和激勵(lì)信號(hào),以便在之后的數(shù) 據(jù)丟失的情況下進(jìn)行處理; 在當(dāng)前數(shù)據(jù)接收正常而之前數(shù)據(jù)包丟失 的情況下,iLBC會(huì)對(duì)當(dāng)前解碼出的語(yǔ)音和之前模擬生成的語(yǔ)音進(jìn) 行平滑處理,以消除不連貫的感覺(jué);在當(dāng)前數(shù)據(jù)包丟失的情況下,

9、 iLBC會(huì)對(duì)之前記錄下來(lái)的激勵(lì)信號(hào)作相關(guān)處理并與隨機(jī)信號(hào)進(jìn)行 混合,以得到模擬的激勵(lì)信號(hào),從而得到替代丟失語(yǔ)音的模擬語(yǔ)音。 總的來(lái)說(shuō),和標(biāo)準(zhǔn)的低位速率編解碼相比,iLBC使用更多自然、清晰的元素,精確的模仿出原始語(yǔ)音信號(hào),被譽(yù)為更適合包交換網(wǎng)絡(luò)使用的可獲得高語(yǔ)音質(zhì)量的編解碼。此外,大部分標(biāo)準(zhǔn)的低位速率編解碼,如G.723.1和G.729 ,僅對(duì)300Hz 3400Hz的頻率范圍進(jìn)行編碼。在這個(gè)頻率范圍里,用 G.711編解碼所達(dá)到的語(yǔ)音質(zhì)量,就是傳統(tǒng)PSTN網(wǎng)絡(luò)進(jìn)行語(yǔ)音通 話的效果。iLBC充分利用了 04000Hz的頻率帶寬進(jìn)行編碼, 擁有超清晰 的語(yǔ)音質(zhì)量,這大大超出傳統(tǒng)300Hz 34

10、00Hz的頻率范圍。廣受歡迎的Skype網(wǎng)絡(luò)電話的核心技術(shù)之一就是 iLBC語(yǔ)音編解碼 技術(shù),Global IP Sound稱該編碼器語(yǔ)音品質(zhì)優(yōu)于 PSTN ,而且能 忍受高達(dá)30%的封包損失??偟膩?lái)說(shuō),在相同的包交換通信條件下,iLBC的語(yǔ)音質(zhì)量效果比G.729、G.723.1以及G.711更好,聲音更加圓潤(rùn)飽滿,且丟包率 越高,iLBC在語(yǔ)音質(zhì)量上的優(yōu)勢(shì)就越明顯!目前,在國(guó)際市場(chǎng)上已經(jīng)有很多VoIP的設(shè)備和應(yīng)用廠商把iLBC集成到他們的產(chǎn)品中。如:Skype, Nortel等。在國(guó)內(nèi)市場(chǎng)上,目前尚無(wú)VoIP廠家正式推出支持“iLBC的網(wǎng)關(guān)設(shè)備,迅時(shí)公司 率先推出支持“iLBC的中繼網(wǎng)關(guān)和I

11、AD設(shè)備。如何計(jì)算一路話音消耗的帶寬在voice這方面,是如何計(jì)算使用某種 codec所消耗的帶寬呢?在 默認(rèn)情況下,把模擬話音轉(zhuǎn)換為數(shù)字話音后,按 20ms 一段20ms 一段切開(kāi),用 rtp封裝起來(lái),然后包上 udp header , ip header , 最后是layer 2的包頭,然后發(fā)出去。假設(shè)咱們用g.729編碼,并在ethernet上傳輸。一起來(lái)算算一路話音需要多大帶寬吧。g.729每路話音是8kbit/s ,那么開(kāi)始轉(zhuǎn)換:8000bps / 8 = 1000 bytes/s ,得至U g.729 每秒需要帶寬 1000 bytes 那么默認(rèn)都是把20ms的話音封成一個(gè)pack

12、et ,也就可以算出1 秒內(nèi)發(fā)送多少個(gè)packet :1s / 20ms = 50 個(gè)也就是說(shuō)g.729每20ms需要的帶寬為:1000bytes/s / 50 =20bytes/s之后以太網(wǎng)幀頭 6-byte , ip包頭20-byte , udp包頭8-byte , rtp包頭12-byte ,這樣,再加上 g.729的payload為20bytes ,也就是 說(shuō)每20ms就要產(chǎn)生一個(gè) 6 + 20 + 8 + 12 + 20 = 66-byte 長(zhǎng)度的幀, 那么一秒就要發(fā)送 50個(gè)66-byte ,等于3300-byte ,轉(zhuǎn)成kbit/s : 3300byte/s * 8 /1000

13、= 26.4kbit/s最終得出g.729 一路話音占用帶寬(包括 layer2 header )為 26.4kbps本文來(lái)自CSDN博客,轉(zhuǎn)載請(qǐng)標(biāo)明出處: HYPERLINK /worldpharos/archive/2009/03/10/3977018.aspx /worldpharos/archive/2009/03/10/3977018.aspx語(yǔ)音編碼的帶寬計(jì)算VOIP Bandwidth consumption naturally depends on the codecused.VOIP消耗的帶寬一般取決于所使用的語(yǔ)音編碼.When calculating bandwidth,

14、one cant assume thateverychannel 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.

15、計(jì)算帶寬時(shí),不能假設(shè)每一個(gè)通道都處于使用狀態(tài).正常的通話過(guò)程包括一系列的靜音,也就意味著并不是一直都有包在傳送.所以一個(gè) 語(yǔ)音呼叫建立兩個(gè)經(jīng)過(guò) UDP,IP和以太網(wǎng)的64Kbit的RTP流(總開(kāi) 銷),全部帶寬并末一直被使用.A codec that sends a 64kb stream results in a much largerIP network stream. The main cause of the extra bandwidth usage isIP and UDPheaders. VoIP sends small packets and so, many times, t

16、he headers are actuallymuch larger than the data part of the packet.一個(gè)傳送64kb流的語(yǔ)音編碼很大程度上都是 IP網(wǎng)絡(luò)流的結(jié)果.額 外的帶寬使用主要是IP或UDP頭的增加.VOIP只傳送少量的包, 很多時(shí)候,實(shí)際上是包頭遠(yuǎn)遠(yuǎn)大于包數(shù)據(jù).Codec BR NEBG.71164 Kbps 87.2 KbpsG.7298 Kbps31.2 KbpsG.723.16.4 Kbps21.9 KbpsG.723.15.3 Kbps20.8 KbpsG.72632 Kbps55.2 KbpsG.72624 Kbps47.2 KbpsG.7

17、2816 Kbps31.5 KbpsiLBC15 Kbps27.7 KbpsBR = Bit rateNEB = Nominal Ethernet Bandwidth (one direction)根據(jù)我的使用經(jīng)驗(yàn),8K的G.729加上IP封裝后達(dá)到32K,為了防 封殺,還有的用戶使用IP Sec設(shè)備將語(yǔ)音做成 VPN,這樣G.729 加上IP封裝,再加上 VPN會(huì)達(dá)到60多K。注:頭三段中文是我自己譯過(guò)來(lái)的,所以讀起來(lái)并不怎么準(zhǔn)確,而且 會(huì)感覺(jué)別扭,呵呵.多多包涵了 .有興趣的朋友可以再譯一次.以供借 鑒.集群通軟交換電話-所需帶寬說(shuō)明VoIP所需要的帶寬,通常取決于它所使用的 codec編

18、碼方法。在 計(jì)算帶寬時(shí),不能假定每個(gè)通道總是在使用之中。 通常的會(huì)話過(guò)程 中包括大量的靜默時(shí)段,就是不發(fā)送任何數(shù)據(jù)包。一個(gè)會(huì)話建立了兩個(gè) 64kbps的RTP流,在UDP/IP/Ethernet 上, 并非在所有的時(shí)間都使用全部的帶寬。一種編碼方法發(fā)送64kbps的數(shù)據(jù)流,會(huì)導(dǎo)致大得多的IP網(wǎng)的數(shù) 據(jù)流,引起額外帶寬的主要原因是IP和UDP的報(bào)文頭.當(dāng)VoIP發(fā)送小的數(shù)據(jù)包時(shí),在大多數(shù)時(shí)候,報(bào)文頭實(shí)際上要比包中的數(shù)據(jù)大 得多。F面的表列出了各種編碼方法,所需要的帶寬:編碼方法編碼所需帶寬實(shí)際所需要的網(wǎng)絡(luò)帶寬G.71164 Kbps87.2 KbpsG.7298 Kbps31.2 KbpsG.7

19、23.16.4 Kbps21.9 KbpsG.723.15.3 Kbps20.8 KbpsG.72632 Kbps55.2 KbpsG.72624 Kbps47.2 KbpsG.72816 Kbps31.5 Kbps編碼所需帶寬,是指理論上所需要的帶寬。但在實(shí)際的傳輸過(guò)程中, 還要付出其他的消耗,如報(bào)文頭。真正需要的帶寬是實(shí)際所需要的 網(wǎng)絡(luò)帶寬,這是大致的數(shù)值,而不是嚴(yán)格的精確值。實(shí)際所需要的網(wǎng)絡(luò)帶寬通常是以太網(wǎng)所需要的帶寬,或者是 ppp連接所要的帶寬。QQ使用的編碼技術(shù) GIPS ,實(shí)際使用起來(lái)感覺(jué)聲音比較清晰,相 對(duì)于SIP的編碼就顯得聲音有些不好,請(qǐng)問(wèn), GIPS理論占用的帶 寬有多大

20、?能不能在 SIP加入GIPS編碼方式?GIPS公司用的語(yǔ)音編碼技術(shù)是iLBC編碼。iLBC若采30ms 一幀,則理論帶寬需要 13.33 kbps 。若20ms 一 幀,則理論帶寬需要 15.2kbps 。iLBC的語(yǔ)音質(zhì)量要比 G.729A好些,但是能夠容忍丟失更多的包; 也就是在丟包后,iLBC恢復(fù)能力更強(qiáng)。iLBC計(jì)算復(fù)雜度與G.729A差不多。都是計(jì)算度比較復(fù)雜的算法。SIP終端中,也有使用 iLBC編碼的。skype、QQ在語(yǔ)音編碼上并沒(méi)有什么優(yōu)勢(shì)。由于它們是私有協(xié)議,目前在穿透私網(wǎng)( NAT) 和防火墻上,更好做些,所以媒體流的路徑,可能比 SIP標(biāo)準(zhǔn)(目 前)好做些而已。穿透易

21、,路徑選得近些,音質(zhì)就顯得好些。G711在大名有100Kbps帶寬時(shí),有很好的語(yǔ)音質(zhì)量。G.726在大名有50Kbps帶寬時(shí),有好的語(yǔ)音質(zhì)量。G.729在大名有30Kbps帶寬時(shí),有好的語(yǔ)音質(zhì)量。GIPS公司用的語(yǔ)音編碼技術(shù)是帶寬可變的碼率,也就是根據(jù)網(wǎng)絡(luò)實(shí)際的帶寬狀態(tài),調(diào)整語(yǔ)音編碼的壓縮比率。也就是帶寬越少,語(yǔ)音壓縮得越厲害,失真損失越多;帶寬越好,就壓縮不厲害,失 真損失少。注意語(yǔ)音編碼用的壓縮,都是有損壓縮,也就壓縮后語(yǔ)音會(huì)些失真。什么是iLBC ?iLBC是一種專為包交換網(wǎng)絡(luò)通信設(shè)計(jì)的編解碼,優(yōu)于目前流行的 G.729、G.723.1 ,對(duì)丟包進(jìn)行了特有處理,既使在丟包率相當(dāng)高的網(wǎng)絡(luò)環(huán)

22、境下,仍可獲得非常清晰的語(yǔ)音效果。iLBC所占用帶寬?30ms ptime的iLBC所占用的總通信帶寬比通常采用的 ptime 20ms的G.729的帶寬還要小,以下是iLBC與傳統(tǒng)編解碼占用帶 寬歹!J表:iLBC 語(yǔ)音質(zhì)量的飛躍語(yǔ)音質(zhì)量一直是 VoIP應(yīng)用的主要難點(diǎn),如何保證和提高IP網(wǎng)絡(luò)傳 輸語(yǔ)音的通話效果,是 VoIP應(yīng)用迫切需要解決的問(wèn)題?!癷LBC編解碼的出現(xiàn),解決了在包交換的 IP網(wǎng)絡(luò)中,傳輸語(yǔ)音所遇到的網(wǎng) 絡(luò)丟包嚴(yán)重影響通話質(zhì)量等實(shí)際問(wèn)題,實(shí)現(xiàn)了語(yǔ)音質(zhì)量的飛躍 工下圖為在不同的網(wǎng)絡(luò)丟包環(huán)境下,使用iLBC與G.729A、G.723.1編解碼的語(yǔ)音質(zhì)量比較。圖 1. iLBC 與 G.729A、G.723.1 的比較(Dynastat, Inc)無(wú)論在高丟包率條件下還是在沒(méi)有丟包的條件下,iLBC的語(yǔ)音質(zhì)量都優(yōu)于目前流行的 G.723.1, G.729A 等標(biāo)準(zhǔn)編解碼;而且丟包率 越大,使用iLBC的語(yǔ)音質(zhì)量?jī)?yōu)勢(shì)越明顯。通常情況下,為了衡量 IP網(wǎng)絡(luò)語(yǔ)音質(zhì)量,將A %丟包率的網(wǎng)絡(luò)情況定義為VoIP的極限網(wǎng)絡(luò)條件。經(jīng)過(guò)語(yǔ)音質(zhì)量測(cè)試,即使在5%丟包率的情況下,iLBC仍然能夠

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論