• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            iLBC編解碼相關知識

            轉自:http://www.eetchina.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 是為專為提供穩健的 IP 語音通信而開發的語音 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 性能

            GIPS 公司和一些獨立實驗室對 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 的部分公司:

          1. 應用/軟件電話:Skype、Nortel、Webex、Hotsip、Marratech、Gatelinx、K-Phone、 XTen;

             

          2. IP 電話:WorldGate、Grandstream、Pingtel;

             

          3. 芯片:Audiocodes、TI Telogy、LeadTek、Mindspeed。

            iLBC 使用許可

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

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

            選擇供應商的準則包括:

             

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

             

          5. 對于所選定的平臺,在 MIPS、質量、代碼大小,以及存儲器等方面能滿足相關的技術要求。

             

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

             

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

             

          8. 提供語音 codec 的定點 ANSI C 轉換記錄,提供 DSP 優化和信號處理技術。

             

          9. 所選定的平臺,必須在 iLBC 獲授權者中擁有良好的表現記錄。

             

          10. 必需選擇一家經驗證的 iLBC 供應商,以確保獲得及時的成果和高質量的性能。

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

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

             

          11. 由一位在 codec、FIP 及 DSP 方面具備豐富知識的高級工程師來執行設計任務;

             

          12. “標準” 優化 (大部分代碼采用 C 程序,關鍵部分采用匯編語言);

             

          13. DSP 轉換基于高質 iLBC FIP 代碼進行。


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

             

          14. 內部培訓;

             

          15. 熟習 iLBC codec 所需的時間;

             

          16. 項目風險 ?D?D 若是從外部供應商處獲得 iLBC 授權,其復雜性、性能和質量不可以預先驗證;

             

          17. 一般的技術及商業風險;

             

          18. 文檔處理;

             

          19. 測試;

             

          20. 支持成本與生命周期成本;

             

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

             

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

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

            作者:Yann Lejas

            亞太區客戶工程總監

            Global IP Sound (GIPS) 公司

          23. iLBC codec 官方主頁:http://www.ilbcfreeware.org/software.html

          24. posted on 2010-10-27 14:10 楊粼波 閱讀(730) 評論(0)  編輯 收藏 引用

            久久精品国产91久久麻豆自制 | 久久综合色老色| 婷婷国产天堂久久综合五月| 久久精品人人做人人爽电影| 久久婷婷五月综合色高清| 97久久超碰国产精品旧版| 99久久精品免费国产大片| 亚洲欧美日韩久久精品| 97精品伊人久久大香线蕉app| 久久亚洲国产精品五月天婷| 国产成人精品白浆久久69| 无码任你躁久久久久久老妇| 久久精品aⅴ无码中文字字幕不卡 久久精品aⅴ无码中文字字幕重口 | 天堂无码久久综合东京热| 久久精品国产亚洲AV电影| 人妻丰满?V无码久久不卡| 精品精品国产自在久久高清| 亚洲午夜无码久久久久小说| 麻豆精品久久久一区二区| 国产A级毛片久久久精品毛片| 国内精品久久久久久久久| 久久国产精品成人影院| 99久久免费国产精品特黄| 91秦先生久久久久久久| 久久精品国产亚洲AV嫖农村妇女| 久久中文字幕视频、最近更新| 久久综合丁香激情久久| 久久久久久午夜成人影院 | 色欲久久久天天天综合网| 青青青青久久精品国产h久久精品五福影院1421 | 久久99国产综合精品免费| 久久久久av无码免费网| 久久久午夜精品福利内容| 亚洲国产成人精品91久久久| 久久久无码精品午夜| 久久久WWW成人| 久久久久无码精品| 日本高清无卡码一区二区久久| 国产一区二区三精品久久久无广告| 韩国无遮挡三级久久| 久久亚洲高清观看|