【技術流】實時音視頻技術應用——如何設計一個端到端的音樂教學解決方案？

實時音視頻的應用市場隨著基礎技術的不斷成熟，基礎設施(如網路)的不斷升級，以及用戶需求的不斷豐富而持續擴張。作為一個跨越物理距離實現人與人溝通交流的最重要的網路解決方案，人們對於實時音視頻的需求和期望也越來越高。今天就來討論下傳統的VOIP應用在在線音樂場景下面臨的痛點，以及網易雲信是如何設計一個端到端的在線音樂教學解決方案的。

首先我們先來介紹下一般的VOIP框架。VOIP即Voice over Internet Protocol，用中文簡單描述就是將模擬信號（Voice）數字化，再進行前處理，編碼，以數據封包（Data Packet）的形式在IP網路(IP Network）上做實時傳遞。VOIP區別於傳統電話的最大變化就是不再獨佔信道，採用數據包發送至IP網路。它的優點是成本低、信道利用率高，缺點也很明顯，就是網路狀況的好壞直接影響通話的質量。VOIP的通話的首要目標是對抗網路狀況實現語音的流暢、可理解、實時性，在很多子模塊設計也都是以這個為目標的。在VOIP框架下（如圖一所示），聲音從一端到達另一端一般是要經過：採集，前處理，編碼，網路傳輸，解碼，播放幾個模塊的。

為了達到流暢、可理解、實時性這樣的目標，一般VOIP的每個環節這麼做的：

• 採集/播放模塊：由於一般的人聲都是中低頻為主，高頻的諧波不多。大部分採集模塊都選用性價比最高的16KHz採樣率，早期的採集模塊的採樣率則是更低的窄帶8KHz。16KHz採樣率不僅能保存絕大部分的人聲，也降低了後面模塊如前處理和編碼器的計算量，同時還大大減少了編碼的輸出碼率（相對於48Khz採樣率）。
• 前處理：一般的音頻前處理主要有：回聲消除，雜訊抑制，自動增益控制等。任何的前處理都是希望保留或放大我們想要的聲音，消除或抑制不想要的聲音。所以處理一定是對本體聲音造成影響的。在一般的VOIP框架下，前處理演算法不僅可以扔掉高頻信息來保證計算量，同時在演算法的偏向性上也更偏向於去除掉不想要保留的聲音如噪音，回聲等。最大限度保證可理解即可。
• 編解碼器：一般的VOIP系統除了會使用國際電信聯盟的G.711、G.722、G.723等編碼器（如：IP電話等），更多的即時通訊軟體則會使用針對網路傳輸設計的Opus 等編碼器，Opus在人聲場景下，會使用口腔發音模型建模silk語音編碼器，可以實現高壓縮比，大大提升低帶寬下表現。
• 網路傳輸：在對抗網路傳輸的不穩定，包括：隨機丟包，擁塞，抖動等，常見的對抗技術和策略有：FEC（Forward Error Correction）前向糾錯技術，PLC（Packet loss concealment）丟包隱藏技術，ARQ（Automatic Repeat Request）自動重傳機制，JitterBuffer 抖動緩存區策略，帶寬與冗餘包分配策略等等。一般VOIP在設計這些策略和方案的時候會最大限度的保留流暢性和實時性的同時，利用盡量少的帶寬來恢復更多的數據，滿足可理解性，同時也能兼顧低帶寬純音頻場景以及正常帶寬下的音視頻混合場景。

這些環節的設計，可以讓人聲場景下節約計算量的同時又比較高效的被壓縮最大限度的利益網路帶寬，來達到最高的性價比的語音通話。但是切換到音樂場景下，由於聲音的內容的豐富程度大大增加，加上人對於音樂內容的要求更高，普通的VOIP框架的設計就顯得有些不夠用了，痛點如下：

• 採集/播放模塊：由於音樂內容的高頻諧波非常豐富，16Khz的採集相對於絕大多數44.1KHz的音樂源來說，造成了大量的高頻損失。經過對比測試，人耳可以在幾秒內明顯感知。
• 前處理：一些前處理演算法，考慮到計算量會直接扔掉高頻信息，這個效果會和16Khz採樣的最後效果差不多，但是信息少了，大小卻沒有變，最後造成編碼器計算量的增加和編碼碼率的提高。除此之外，前處理在語音內容的處理目標是可理解，在對本體語音的損傷較大，在語音內容下不易感知，但是在音樂內容下就非常容易感知了，極端情況下會帶來非常不好的體驗。
• 編解碼器：普通的語音編碼器一般是口腔發聲模型建模的，在編碼由樂器彈奏出來的曲子的時候由於模型不匹配將造成很多聲音細節的丟失。所以音樂通常會使用基於人耳聽覺模型建模的音樂編碼器如Opus裡面的celt編碼器。相比於語音編碼器，音樂編碼器在高碼率輸出的時候還原度要好很多，但是壓縮比要明顯低一些，帶來的直接影響是低碼率下的音樂編碼失真非常嚴重。
• 網路傳輸：傳統的VOIP基於實時性、可理解以及順暢的目標下，會給音頻預留較低的帶寬，冗餘包的信息較少，jitterbuffer等策略的設計也是滿足基本可理解聲音的要求下盡量的降低時延。在音樂的內容下，整體的音質在對抗網路的狀況中變化較大，用戶體驗不好。

網易雲信，在設計在線音樂教學解決方案的時候，首先去了解了類似VIP陪練等在線音樂教學類的痛點，再加上技術框架下的重新思考，旨在給用戶提供端到端的音樂教學解決方案。

• 採集/播放模塊：採用48KHz全頻帶方案採集方案，在採集和播放處最大限度的減少音質的損失。針對Android等移動端系統，會在前處理可以處理的範圍內，盡量選擇適合音樂內容採集播放的模式，減少由於系統硬體前後處理帶來的音質的損失。
• 前處理：支持48KHz的全頻帶處理能力，同時針對音樂內容做部分偏向性優化，希望能盡量減少音質的損失。
• 編解碼器：設置更加適合音樂編碼器的碼率範圍，在注重編碼效率的同時兼顧音樂內容的音質，實現最大限度的高保真。
• 網路傳輸：重新定義了音頻，視頻，冗餘音頻，冗餘視頻等部分的優先順序，定製化的調整了音頻的整體帶寬分配策略，以及冗餘音頻的大小。在實時性和質量的平衡中針對音樂場景做了定製化調優，最大限度的減少音質的變化帶來的用戶體驗不佳。
• 除了在音質上對端到端音樂內容體驗有了全新定義之外，我們還創新性地打造極速相應機制，讓用戶在無感知的情況下快速解決問題。事實上，面對成百上千的設備差異性，聲音的效果在部分設備上表現會非常不理想。傳統方案流程中用戶發現問題、反饋問題再到手機適配解決問題的流程，版本迭代周期長、升級成本高、用戶體驗修復慢，這些都是非常大的弊端。雲信下發極速響應機制，使分析問題、解決問題、實時同步部署成為可能，最快可以使用戶從反饋問題到下一通電話就在用戶無感知的情況下解決，大大提升了聲音類問題從發現到解決到用戶使用的閉環時間。

網易雲信的在線音樂解決方案，也是我們的第一個版本，儘管在設計上考慮到了端到端的每個一個環節，但是其中的裡面的每個環節還有持續的優化空間。我們也會在接下來的版本里持續針對我們的在線音樂解決方案做持續優化的。也歡迎大家在評論區與我們互動交流~