在上一篇文章中，我們完成了對音頻前處理三劍客的學習，聲音信號經過音頻前處理模塊，已經“洗盡鉛華、去除雜質”，現在，你是否已迫不及待想要將它們分享到世界各地了呢？但稍安勿躁，想要更好地與世界分享我們的聲音，還有一個不得不考慮的問題，而這個問題將由我們今天的主角 “音頻編解碼”來解決，
音頻編碼壓縮的必要性
我們都知道，要想把音視頻資料實時分享到世界的各個角落，有一個傳輸工具必不可少：網路，而要用好這個傳輸工具，有一個必須關注的點：網路帶寬，
作為資深網民，大家肯定都了解過帶寬，它指的是網路鏈路1秒鐘內能傳輸的最大資料量，其單位一般使用 bps（bit per second），對應到推流（上傳）/拉流（下載），可以相應分為上行帶寬和下行帶寬，如果把網路比喻為高速路，那么帶寬就相當于這條路的寬度，音視頻資料相當于路上來往的車輛，公路越寬，則允許并行通過的車輛越多，其運輸能力就越強，如果道路太窄、需要并行通過的車輛又太多，可能會出現阻塞、甚至是車禍，對應的，網路帶寬越大，單位時間能傳輸的資料越多，如果帶寬不足，勢必導致傳輸例外，產生卡頓、甚至資料丟失等影響用戶體驗的問題，
基于對帶寬的了解，我們進一步看看純音頻場景對帶寬的需求情況，我們已經知道，音頻模擬信號經數字化處理會得到標準的數字?頻資料裸流，其格式為 PCM，不妨先來計算一下，如果直接傳輸 PCM 資料需要多少帶寬，
音頻資料傳輸所需的帶寬，可以通過音頻碼率來度量，在 音頻必知必會之音頻要素 一講中，我們已經學習了音頻碼率的概念及計算方式，對于采樣率 44.1K Hz，位深 16 bit 的雙聲道音頻 PCM 資料，它的碼率為：
采樣率/Hz * 位深/bit * 聲道數 * 時長(1s) = 44100 * 16 * 2 * 1 = 1411200 bps = 1.4112 Mbps（bps = bit per second）
也就是說，要求推流用戶的上行帶寬、拉流用戶的下行帶寬至少為：1.4112 Mbps，這是單條音頻流的情況，如果將場景擴展到語聊房或在線會議，帶寬要求還需要依據上麥人數翻 N 倍，而在一些特殊場景，比如曾風靡一時的 ClubHouse 或 勢頭正旺的 MetaWorld，它們甚至號稱“不限制上麥人數”，對于帶寬的要求必然會更高，根據統計資料顯示，2021年我國寬帶網路的上行速率中值約35Mbps，考慮到實際場景中除了音頻之外，還有其他資料需要傳輸（比如視頻資料，所需帶寬是音頻的數十倍），綜合考量下來，帶寬也算是“寸土寸金”了，PCM 資料的碼率著實讓人“高攀不起”，
所以，如何高效利用帶寬，如何在有限的帶寬下傳輸更多的音頻資料，是我們的重要課題，而音頻編
解碼，就是這個課題的一個有效解決方案，
在 RTC 音視頻資料的處理鏈路上，音頻編碼模塊位于音頻前處理模塊之后、網路傳輸模塊之前，其主要作用就是對原始音頻資料進行編碼壓縮，以減小資料量、降低帶寬消耗（音頻解碼模塊位于網路接收之后，可以認為是音頻編碼的反向流程，也即對壓縮后的資料進行解壓縮、還原），常見的編碼演算法，比如 AAC，能夠實作相對于 PCM 資料1/15以上的壓縮率，也即將碼率 1.4112 Mbps 降低至 0.094 Mbps，帶寬占用將得到顯著的優化，對于 RTC 場景來說，更低的帶寬消耗意味著更好的場景適配性、更好的弱網適應性，這對于 RTC 應用的普及、用戶體驗的保障都有裨益，除了帶寬優化外，如果有保存音頻為檔案的需求，編碼還能極大減輕存盤空間的壓力，
綜上，“降低帶寬消耗”和“降低存盤空間占用”構成了音頻編解碼存在的必要性，了解其必要性之后，我們再進一步探究，為什么音頻資料可以被編碼壓縮，編碼壓縮的“可行性”基礎究竟是什么呢？
音頻編碼壓縮的可行性
我們已經知道，音頻編碼程序是壓縮、減少資料量的程序，但“減少”并不代表可以隨意丟棄，而要在減少“資料量”時，同時盡可能避免“資訊量”的丟失，也即保真，如果被壓縮的音頻資料，其所有資訊可以被完整地解壓、還原，我們稱相應的處理為無損壓縮；否則，相應的處理即為有損壓縮，有損壓縮能夠帶來更好的壓縮效益，是 RTC 場景下普遍使用的方案，我們今天也著重了解有損壓縮相關的技術點，
值得一提的是，有損和無損也是相對而言的，目前任何數字編碼方案都無法做到完全無損，就像用數值表達圓周率 π = 3.1415926……，只能無限提高精度、無限接近，但永遠無法相等，
注：PCM 就屬于“無損”的音頻編碼，我們已了解其原理是對模擬音頻信號在時間軸、幅度軸上進行采樣、量化處理，以使重構的語音波形盡可能與原始語音信號的一致，其保真度好，但編碼碼率很高，不適用于RTC場景，
那么，既然是“有損壓縮”，實作可觀的壓縮率，又要最大限度避免“資訊量”丟失，這不是相互矛盾了嗎？
其實，“資訊量”再加上一個定語會更貼切，那就是避免“有用、重要的“的”資訊量丟失，壓縮程序中丟棄的資料相對于整體應該是“不必要”或“不重要” – 也即“冗余”的，在 RTC 場景中，人是音頻信號的消費者，我們可以充分利用人耳聽覺的生理、心理特性來尋找這些“不必要”、“不重要”的冗余成分，總結下來主要包括兩方面：
1人耳聽覺范圍之外的音頻信號
在系列第一講-音頻要素 中，我們了解到：人耳的聽力范圍僅限于頻率 20Hz ~ 20kHz，低于或者高于該頻率范圍的聲音無法被人耳感知，被稱為次聲波（＜20Hz）和超聲波（＞20KHz），這部分“無法被人耳感知”的聲音，就屬于音頻信號中“不必要” 的“冗余”部分，同時，因為不同型別信號的頻率特征不同，比如語音的頻率集中在 300 ~ 3400Hz，如果只關注語音信號，300~3400Hz 頻段之外的信號也可以視為“冗余”，可以在編碼壓縮程序中“丟棄”，
2被掩蔽掉的音頻信號
除了對特定頻率的聲音不敏感外，人耳還會因為“掩蔽效應”而忽略某些“弱音信號”，關于“掩蔽效應”，我們以響度（聲強級）作為參考（詳見系列課程第四講-音頻AGC），做如下理解：
人耳對于不同頻率的聲音，有相應的最小響度可聞閾，如果某個頻率的聲音響度小于該頻率的最小可聞閾，該聲音將無法被人耳聽到，并且，某一頻率聲音的最小可聞閾不是固定的，當存在能量較大的“強音信號”時，該“強音信號”附近頻率的“弱音信號”的最小可聞閾值會提高，這就是掩蔽效應中的“頻域掩蔽”，如下圖【頻域掩蔽】所示，
除了頻域掩蔽外，當強音信號和弱音信號同時存在時，在不同時機，還會有“時域掩蔽”，如下圖【時域掩蔽】所示，在強音信號出現前的短時間內（約20ms），已經存在的弱音信號會被掩蔽；當二者同時存在，弱音信號會被掩蔽；當強音信號消失后，還需要等上一段時間（約150ms），弱音信號才能重新被人耳聽到，以上三種型別的時域掩蔽分別稱為超前、同時和滯后掩蔽，
頻域掩蔽【圖源：網路】
時域掩蔽【圖源：網路】
在頻域掩蔽和時域掩蔽中，那些“被掩蔽的信號”無法被人耳感知，所以可以視為冗余信號，可以在編碼壓縮程序中“丟棄”，
除了利用人耳聽覺的生理、心理特性定義的“冗余”外，基于資訊論原理，音頻信號在時域和頻域上的特征具有統計相關性，也即存在資料冗余，這些冗余也可以通過資訊編碼的方式進行壓縮處理，
綜上，我們從聲音信號中找到了“冗余”成分，它們是支撐音頻編碼壓縮的“可行性”基礎，
現在，我們已經了解了音頻編碼壓縮的必要性和可行性，接下來該聊聊具體的音頻編碼格式了，
音頻編解碼技術的發展歷經了多個階段，從針對語音信號的時域編解碼、到針對音樂信號的頻域編解碼，最后也演變出同時兼顧兩種型別信號的“全能編解碼”，關于發展史大家靈活使用搜索引擎可以了解到很多干貨，在此不做贅述，
目前，已經有諸多成熟的方案供我們選擇，除了前面提及的 AAC ，常見的音頻編解碼格式還有：OPUS、SILK、SPEEX、MP3、iLBC、AMR、Vorbis、G.7 系列等等，而在 RTC 應用中常用的有 AAC 和 OPUS，我們今天將重點了解這兩種格式，并會圍繞音視頻業務開發者關注的：編碼方案的優缺點、如何根據場景來靈活選擇等維度進行講述，
如何選擇音頻編解碼格式
在具體介紹 AAC 和 OPUS 之前，先和大家聊聊：如何選擇一個合適的音頻編解碼格式？以及當我們選擇音頻編解碼方案時，我們究竟在 “選” 什么？
從大方向上看，我們選擇音頻編解碼方案時主要考慮兩點“可不可用” 和 “好不好用” ，而每個大方向上，會有其細分維度，
首先是“可不可用”，具體的應用場景，可能因為某些“限制”導致某些編解碼方式“不可用”或者“僅可用”，這些限制主要涉及“兼容性”和“適用性”兩方面，
對于兼容性，就音視頻場景來說，主要指流媒體傳輸協議兼容性和平臺兼容性，而平臺可能系結某種流媒體傳輸協議，二者一般是關聯考慮的，比如微信小程式平臺支持 RTMP 傳輸協議，而RTMP 協議支持 AAC 音頻編碼，就形成了一定制約，另外需要注意的是，如果某兩個平臺支持的音頻編解碼格式不同，又有互通需求，可能就需要通過服務端轉碼的方式來搭建橋梁，
對于適用性，主要指的是“頻寬支持是否符合場景需求”，頻寬指的是聲音頻率的支持范圍，人耳對聲音頻率的感知范圍（20Hz~20kHz）可以被劃分成四個頻寬區間：窄帶、寬帶（wideband）、超寬帶（super-Wideband）和 全帶（fullband），如下圖所示：
結合已學習的聲音頻率、采樣率、奈奎斯特采樣定理等概念，大家應該很容易就能理解上述圖表，舉一個簡單的例子，音頻編解碼格式 G.711 僅支持窄帶信號，所以在編碼普通語音（低頻）時“可用“，適用于固話、電話場景，但是在編碼全帶信號時“不可用”，不適用于音樂直播等場景，
考慮了“可不可用”這個基本標準后，我們還需要有進一步的追求，那就是 “好不好用”，
某種編解碼格式 “好不好用” ，主要指的是：它在滿足特定場景基本要求的基礎上，能否將編碼作業做到“盡善盡美”，而在 RTC 場景下，關于“盡善盡美” 我們主要考慮音質和延遲兩方面，
關于音質，音質是大家普遍關注的指標，它的影響因素還比較多，除了已經提到的采樣率，還有采樣位深和聲道數，支持的采樣位深越大、聲道數越多，自然可以更好的保證音質，比如 AAC 支持 96khz 采樣和多達 48 個聲道，這讓它在追求高音質的場景備受青睞，既然采樣率、采樣位深和聲道數均影響音質，那么基于三者計算的綜合指標 – 碼率，自然也不例外，一般來說，支持的碼率越高、越廣，音質越能得到保障、靈活性也越大，那些僅支持固定碼率的編碼格式，比如僅支持 64kbps 碼率的 G.711，其適用范圍、音質上限就受到很大的限制了，
關于延遲，延遲在音視頻傳輸中，指的是音視頻資料從“主播端麥克風采集“、到從“觀眾端揚聲器播放”的“端到端耗時”，這個耗時由音視頻處理鏈路上的各個環節引入，包括采集、前處理、編解碼、網路傳輸、渲染播放等等，顯然，延遲越低意味著實時性越高，也就越接近于“面對面溝通”，在有連麥互動需求的場景中，“低延遲”甚至是最重要的需求之一，關乎用戶體驗的核心，所以，根據場景需求，選擇一個延遲合適的編解碼格式相當重要，
綜上，當我們選擇編解碼方案時，我們其實是在選擇 “兼容性” 和 “適用性”，進一步的，還需要關注 “音質” 和 “延遲”，通過這四個細分維度，就基本能保證所選方案是”可用“且“好用”的，最后，我們就 RTC 場景下常用的編解碼：AAC 和 OPUS，再來對比說明下，
AAC 和 OPUS 的選取
AAC，是基于MPEG-2規范，由 Fraunhofer IIS、Dolby Laboratories、AT&T、Sony 等公司于1997 年合力研發推出，經過 25 年的發展已經被各個領域廣泛應用，而 OPUS 由 Xiph.Org、Skype 等基金會研發推出，2012 年才被 IETF 批準進行標準化，相對于 AAC ，OPUS 更“年輕”，關于 AAC 和 OPUS 以及其他常見音頻編解碼格式的特性對比，有兩張圖可以很直觀的展示，我們直接看圖說話，
上圖展示了各編碼演算法的編解碼耗時（Delay，縱軸）、支持碼率范圍（Bitrate，橫軸）、支持頻寬，
上圖展示了不同音頻編碼在不同碼率 （Bitrate）、不同頻寬上的音質表現（Quaity），
不難發現，在羅列的編碼演算法中，OPUS 格外矚目，它在 “頻寬支持”、“碼率支持”、“延遲” 和 “音質”方面，都有比較明顯的優勢，可以說是“學霸”一個，OPUS 的優勢，得益于它集成了兩種編碼器：語音編碼器 SILK、超低延遲的編碼器 CELT，并做了很多針對性的優化，它可以無縫調節高低碼率，具有極低并靈活可控的演算法延遲，并支持全頻寬，在實際場景的測驗中，OPUS 比 MP3、AAC 等編碼有著更低的延遲和更好的壓縮率，音質也不甘拜下風，因此，OPUS 在 RTC 場景下備受青睞，某些對端到端延遲極度敏感的場景，更是將其作為必選項，比如實時合唱KTV，多個用戶同時上麥K歌，需要依賴極低的端到端延遲來保證同步性，
而反觀 AAC，其編解碼耗時比 OPUS 高，相對來說不怎么適用于實時互動場景，但它在音質高保真方面，仍然有著不俗的實力，尤其是在極高采樣率、高碼率、多聲道配置下的編碼效果尤佳（AAC 最高支持 96kHz 采樣率，而OPUS 為 48kHz ，雖然都是全頻寬，但是 AAC 在高頻部分能保留更多細節），非常適合音樂直播，另外，除了標準規格，AAC 系列還在演算法延遲、編碼復雜度、編碼效率等方面進行針對優化，推出了多種擴展規格，便于我們靈活選擇，比如延遲優化版的 AAC-LD（Low Delay），從圖一中我們看到其延遲已接近 OPUS；編碼復雜度優化版的 AAC-LC （Low Complexity），在中高碼率上進一步尋求音質和編碼效率的平衡點，并提供更好的兼容性；編碼效率優化的 AAC-HE（High Efficiency），進一步提高壓縮效率，以追求在更低碼率下獲得更高的音質，
其實，從上面的介紹來看，各方實際測驗資料表明，OPUS 作為一種“年輕”的編解碼格式，的確有后來居上、長江后浪推前浪的實力，大部分場景下應該是更優于 AAC 的方案，但勝在“年輕”也輸在“年輕”，年僅十歲的 OPUS 和已經二十五歲的 AAC 比起來，還缺少一點“人生經歷”和“江湖地位”，別忘了，在“如何選擇音頻編解碼格式”的評估維度中，有一個重要的指標：“兼容性”，
作為前輩，并且背靠 Fraunhofer IIS、Dolby Laboratories、AT&T、Sony 等巨頭，AAC 在各領域已得到比較充分的普及，擁有廣泛的硬體設備、軟體應用和傳輸協議兼容性，這些都是 OPUS 短時間內無法超越的，比如，RTMP 是直播場景常用的流媒體傳輸協議，它對于 AAC 編碼具有良好的兼容性，卻不支持 OPUS 編碼，而大部分的 CDN 廠商均默認使用 RTMP 作為推流協議，某些平臺比如微信小程式也僅支持 RTMP 傳輸，為了保證兼容開發、推廣效率，我們往往只能選擇或優先選擇 AAC，
值得一提的是，Google 鼎鼎大名的開源專案 WebRTC 使用了同樣開源、免費的 OPUS ，作為其默認的音頻編解碼方案，但標準 WebRTC 不支持 AAC，這就導致，一些跨平臺的音視頻應用需要依賴服務端轉碼來實作與 WebRTC 的互通，轉碼操作一定程度上增加了傳輸延遲和開發運維成本，
最后，我們通過表格再整理一下 AAC 和 OPUS 的差別，并在細節上進行適當的補充，
總結
最后，簡要總結一下今天的課程內容：首先，我們了解了音頻編碼壓縮的必要性（帶寬和存盤空間）和可行性（冗余），學習了音頻編解碼方案的選擇標準（“兩大方向、四大維度”），并基于這些標準，對 RTC 場景下常用的編解碼格式 AAC 和 OPUS 進行了比較，了解了它們優劣勢和適用場景，今后你自己也能選擇一個合適的編解碼方案了，
至此，大家已完成了必知必會基礎-音頻編解碼部分的學習，我們的聲音走過了采集、前處理、編碼的漫漫長路，終于蓄勢待發，可以奔赴實時網路的各個角落，傳遞資訊、傳播價值，也希望大家能在音視頻應用開發的學習道路上，有所識訓，再邁出踏實的一步，
下面，我們再通過一個思維導圖，梳理一下整篇文章的內容：
問
本期思考題
作為采樣率、位寬、聲道數的綜合指標，音頻編碼碼率對音質會有顯著的回應，那對于碼率的選擇，是否越高就越好呢？
（??下期揭秘）
上期思考題\揭秘 ??
問:
諧波檢測為什么可以用于輔助定位人聲，提高 VAD 的準確度？
答:
在音頻信號中，存在基波和諧波，基波的頻率是音頻信號的主要頻率(基頻)、最低頻率，決定了聲音的音調，諧波的頻率比基波高，并且是基頻的整數倍，如基頻為50MHz，則諧波出現在100MHz、150MHz ……，諧波賦予了音頻音色，
語音的一個明顯特征是包含了基頻及其多個諧波頻率，即使在強噪聲環境下，這一特征也是存在的，可以用自相關的方法找到基頻所在頻點，所以，提取音頻信號中的諧波特征量，可以輔助判定人聲，（樂器的音頻也有明顯的諧波特征，并且和語音相似，
所以，基于諧波特征輔助VAD判定的AGC演算法，一般對樂器音頻也是生效的）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501711.html
標籤：其他