iLBC編解碼相關知識)

轉自http://www.cnblogs.com/huaping-audio/archive/2008/11/23/1339527.html

 

iLBC編解碼相關知識

轉自:http://www.eet-china.com/ART_8800438611_617685_TA_558b9f36.HTM

自 VoIP
技術面世以來，業界對現存的低位元速率轉碼器
(codec
)
標準的關注一直不斷。影響 VoIP 裝置製造和應用開發商的主要問題包括涉及眾多專利持有人的複雜智慧財產權 (IPR)
管理、昂貴的使用許可模式，以及實際 IP 網路的低劣品質。在　2000 年，Global IP Sound (GIPS)
公司決定開發一種能夠滿足 VoIP 產業需求的 codec，目標是利用 GIPS 內部的專業能力開發一款免授權費
(royalty-free)、專為資料包通訊而設計，而且在理想無錯情況和丟包情況下都能提供高音質的
codec，並把它引入不同的標準化機構以符合互通性的要求。這就是 iLBC
codec 誕生的緣起。

曆史

目前大多數的語音 codec 都是基於代碼激勵線性預測 (Code Excited Linear Prediction,
CELP) 編碼模型的，例如 ITU G.729 和 G.723.1、GSM-EFR 和 3GPP-AMR。CELP
一直都被視為在交換網路中以低位元速率電路獲得高品質的一種非常成功的方法。這種編碼方法具有高效性，主要是由於它利用了連續語音片斷之間的互相依賴性，因
此 CELP codec 的效能主要取決於前面編碼的曆史。CELP
編碼器是基於儲存空間的，故丟包或延遲所造成的誤差會擴散開來，結果是單個丟包會影響到隨後多個資料包的品質，這顯然是資料包通訊的一大缺陷。

iLBC 轉碼器

iLBC 是為專為提供穩健的 VoIP通訊而開發的語音 codec，以窄帶語音為設計基礎，具有 8 kHz 的採樣率。iLBC
codec 支援兩種基本的幀長度：13.3 kbps 位元速率下編碼幀長度為 30 ms；而 15.2 kbps位元速率下編碼幀長度則為 20
ms。

採用 iLBC 演算法可以獲得一個具有丟包響應控制的語音編碼系統。iLBC
對每一個資料包的處理都能夠獨立於其它資料包來進行，是資料包通訊的理想選擇。即使 IP 丟包和/或延遲現象的惡化，這種 codec
的語音品質下降情況也不會太差。這與基於 CEIP 模型的一般 codec 的行為不同，這類 codec
最先是為交換電路網路或無線網路而設計的，是設計來恢複位錯誤而非丟包的。

丟包現象發生時，語音 codec 的一項相關基準是從單個丟包情況下恢複過來所需的幀/包數量。在 iLBC 的情況中，數量是零。在丟包之後的第一個資料包總仍能按原本安排的被精確解碼。

iLBC 是一種窄帶語音 codec，使用了整個 4kHz 頻帶，而大多數標準低位元速率 codec 只利用從 300 Hz 到
3400 Hz 的頻帶。這一點對音質的影響是相當明顯的。此外，iLBC 語音編碼的頻譜特性精確類比了原始訊號的特性，其語音比標準低位元速率
codec 的更自然清晰。

總而言之，iLBC 演算法為資料包網路實現了尖端的固定位元速率編碼，在品質與位元速率之間取得了非常出色的平衡。

標準化

2004 年 4 月，在針對多媒體終端機介面卡 (multiple terminal adapter, MTA) 和媒體網關發布的
CableLabs PacketCableTM 1.1 音頻/視頻 codec 規範中，iLBC 被規定為一種強制式 codec。Comcast
公司新媒體開發進階副總裁兼 CableLabs 的 PacketCable 業務部門主席 Steve Craddock 表示：“由於 GIPS
iLBC 編碼是專門為資料包網路而設計的，所以我們深信該種專業水平的規範，能夠為有線電訊廠商提供所需的高效能和音質，讓其 VoIP
解決方案在客戶中贏得優勢。”

iLBC 在 2002 年 3 月獲互連網工程工作小組 (Internet Engineering Task Force,
IETF)　認可，成為第一個標準化的語音/音頻 codec。現在，iLBC codec 處於 IEIF 標準化過程的最後一個階段，是 IETF
視聽傳輸工作小組 (Audio Visual Transport Work Group) 的一部分。

Codec 效能

GIP小型股份有限公司和一些獨立實驗室對 codec 的若干效能進行了評測。2002 年，Dynastat 公司對 iLBC
實施了正式的聽力測試。2003 年，AT&T 的音質評估實驗室 (Voice Quality Assessment Lab, VQA)
也對 iLBC codec 進行了廣泛的測試。

所示為 Dynastat 的評估結果，其根據現有編碼通訊協定 G.729A 和 G.723.1 對 iLBC 的 30ms
模式進行了標準測試。結果明顯表明，用於實際環境時，iLBC 的效能卓越，即使在惡劣的網路條件下，其固有的資料包網路屬性也能提供很高的品質。

 

這些測試還顯示了 iLBC 在丟包條件下的效能不僅顯著優於目前的標準 codec (G.723.1、G.728、G.729、GSM 等)，而且還等於甚至優於理想通道 (無丟包) 條件下的標準 codec。

 

AT&T 的測試結果也顯示，iLBC 中，20 ms 和 30 ms 模式之間沒有顯著的效能差異；而在丟包情況下，20 ms
模式甚至表現出更好的丟包穩健性。AT&T VQA 實驗室也表示，iLBC 在存在背景雜訊時的效能十分優秀，可媲美通道無丟包的
G.729.E。

實現方案

目前，好幾家 VoIP 裝置及應用生產商都在自己的產品中整合了 iLBC。下面我們列出了在自家商用產品中選用了 iLBC 的部分公司：

 

應用/軟體電話：Skype、Nortel、Webex、Hotsip、Marratech、Gatelinx、K-Phone、 XTen；

 

VoIP：WorldGate、Grandstream、Pingtel；

 

晶片：Audiocodes、TI Telogy、LeadTek、Mindspeed。

iLBC 使用許可

裝置和應用生產商一直在尋找高成本效益的方法來滿足新的要求，並為市場提供新的功能。在決定是由內部自行開發 iLBC、還是從其它供應商那裡獲得 iLBC 編碼使用授權時，需要對好幾個方面進行全面考慮。

從其它供應商那裡獲得 iLBC 編碼使用授權能夠大量節省開發成本；提高品質；加快上市速度；降低風險，並增強靈活性。不過，選擇供應商時應該非常謹慎，力求把風險或額外成本降至最低。

選擇供應商的準則包括：

 

具備應付把 iLBC 移植到定點 DSP 環境時一些極敏感的推行和測試問題的專業能力

 

對於所選定的平台，在 MIPS、品質、代碼大小，以及儲存空間等方面能滿足相關的技術要求。

 

浮點　(FLP) 到定點　(FIP)　的轉換必需在效率、儲存空間利用率和最重要的音質之間進行權衡。

 

不良的 iLBC FIP 代碼推行將有礙 DSP 的移植。

 

提供語音 codec 的定點 ANSI C 轉換記錄，提供 DSP 最佳化和訊號處理技術。

 

所選定的平台，必須在 iLBC 獲授權者中擁有良好的表現記錄。

 

必需選擇一家經驗證的 iLBC 供應商，以確保獲得及時的成果和高品質的效能。

計算自行開發 iLBC 設計的成本

為了計算一位經驗豐富的設計人員把浮點代碼轉換為定點 ANSI C 代碼、或轉換為 DSP 平台所花費的設計時間，我們作出了以下的假設：

 

由一位在 codec、FIP 及 DSP 方面具備豐富知識的進階工程師來執行設計任務；

 

“標準” 最佳化 (大部分代碼採用 C 程式，關鍵區段採用組合語言)；

 

DSP 轉換基於高質 iLBC FIP 代碼進行。

 

上表只考慮到設計工作量。要對總體成本進行全面的評估，我們還必須考慮以下各種因素：

 

內部培訓；

 

熟習 iLBC codec 所需的時間；

 

項目風險 ?D?D 若是從外部供應商處獲得 iLBC 授權，其複雜性、效能和品質不可以預先驗證；

 

一般的技術及商業風險；

 

文檔處理；

 

測試；

 

支援成本與生命週期成本；

 

開銷 ?D?D 與員工、工具等相關的固定成本；

 

無法抽調工程資源以開發其它產品和/或功能

此外，還不應該低估上市時間縮短的價值。相比內部自行開發的代碼，採用授權最佳化 iLBC 編碼，最終產品的上市時間能夠提早好幾個月。

作者：Yann Lejas

亞太地區區客戶工程總監

Global IP Sound (GIPS) 公司

iLBC codec 官方首頁：http://www.ilbcfreeware.org/software.html