WebRTC 架構優化及實踐

WebRTC首先是一種標準，目前WebRTC 1.0的w3c標準現已推出，2.0版本也在推進過程中（演講時間為止）。其次是一種協議，開發者可以通過follow這個協議來實現和WebRTC的互通。另外它還是一款引擎，因為它前身就是處理音視訊的GIPS引擎。另外在這套引擎下還有大量的音視訊演算法，所以WebRTC也可以說是演算法。

上文提到WebRTC的前身是GIPS，而GIPS的發展其實分為兩個階段，第一階段為Global IP Sound，第二個階段為Global IP Solution。它在Global IP Sound 階段是作為音訊通訊引擎用於各種嵌入式系統裝置中，主要負責回聲消除、降噪、編解碼等基礎功能。

之後繼音訊服務又加入了video服務，也就是Global IP Solution階段，後來在和客戶的溝通中他們不斷的加入IP通訊的協議、RTP協議等，以實現和網路連線的能力。但是由於商業上的不合理和銷售策略的失敗，最終還是被google以6千多萬美元的價格給收購。

而從技術的演進來講，GIPS到WebRTC，其實是對Engine層做了封裝，順便還新增了原先GIPS缺失的網路模組。一般要提供音視訊服務必須要有伺服器，為了避免這種模式，WebRTC採用了P2P的通訊模式。

個人覺得現在99%以上和實時通訊相關的app越來越離不開WebRTC，即使應用的程式碼框架不相同，但WebRTC還是有很多經典演算法值得借鑑。

通常我們可以將WebRTC作為學習和移植演算法的入門程式碼，或者抽象出它的音視訊引擎，還可以用作PaaS或者SaaS服務。

雖然WebRTC有各種不同應用，但是由於目標不同，所以在結合WebRTC本身能力上會有不同的側重點，需要針對性的檢視相應的程式碼，找出其中有缺陷的部分並做出突破。比如要做SaaS和PaaS服務就要準備伺服器相關的工作。

WebRTC確實可以用來做SaaS服務，但是需要先考慮要做的是什麼型別的SaaS服務。比如對於不是基於Web的音視訊通訊服務，就還要考慮額客戶端進行互通。

而不同的行業對此的要求也不一樣，像呼叫中心和教育類的通常會直接使用web進行服務。不過WebRTC在多瀏覽器上的相容性並不好，視訊編解碼的支援也有所不同。

使用的時候我們要根據服務質量要求和使用者特點靈活使用p2p，比如在大部分使用者都處於WiFi環境的情況下p2p可能是更好的選擇，而對於4g網路p2p效果會差一些。

若使用者對服務質量要求比較高，個人建議應先著手建立伺服器，並部署運維監控負載均衡等能力，讓後端伺服器出現的問題對使用者無感知。

應用這些措施應對純web端的SaaS服務其實還有所不足，有很多細節問題仍需處理。比如使用者外接了音訊裝置，或者某款瀏覽器的音訊通訊產品在本機上沒有適配好，從而產生回聲等各種問題。

又因為底層不是自己做的，因此只能提醒使用者在使用服務的時候先測試一遍，或者給出一些其他建議。

所謂PaaS就是提供一個平臺給廠商使用，不同於SaaS它在上層應用上並沒有做的過於精細，其主要目標還是為了提供更穩定更高效的通訊服務。

在SaaS服務中，我們可以分析使用者行為，針對使用者的使用場景進行優化。但是Paas服務中，使用者千差萬別，可能會涉及IoT、教育、遊戲等個各種不同領域，原有的WebRTC引擎肯定不夠用。

因此在包含SaaS的各種基礎服務之外，還需要抽象出一套API，然後再針對各個移動裝置做適配，還要根據應用場景提供多種增值功能，提供針對場景的特殊優化和包裁剪等。

由於WebRTC本質上更接近於音視訊引擎，所以如果當AV SDK用，會更便捷。

當然前提是使用者有相當的經驗，能夠根據具體的場景定製化引數。

音訊部分在WebRTC中一共封裝了4個模組，ANM（網路模組）、APM、ACM（編解碼模組）、ADM，對應的video也有同樣的4個模組，所以總共是8個模組。個人認為WebRTC的重點就在於這8個模組本身和它們之間的引數配置。

但是這也帶來了相應的缺點，我們要做面向移動端的功能例項優化、效能例項優化以及一些特殊優化，這也使得除錯的次數越來越多。

只有在學習了WebRTC的演算法之後，才能從不同的層面給客戶解釋清楚為什麼要採用當前方案以及為什麼不用其他方案。WebRTC的精髓在於底層的引擎部分，不過要想對這部分有深入的理解，首先就要對其中的演算法有一定的研究。

前面提到過WebRTC中有8個模組和2大引擎，其中音訊模組包括APM、ACM和ADM，視訊模組包括VNM、VPM、VCM。

APM

APM中涵蓋AGC、ANS、DE和回聲消除的演算法NLP。接下我們逐步看下這裡面到底都是些什麼。

通常的回聲消除有兩種演算法，一種是自適應濾波，一種是NLP。在WebRTC之前其實自適應濾波已經做的足夠好了，目前這方面的研究基本上已經停滯，可能在多通道和立體聲的回聲消除上還有一定的研究價值。NLP則不一樣，它還有很多細節值得探討，這是因為每個聲腔的聲音設計不同，造成了非線性部分的差異。

WebRTC中有兩個回聲消除模組分別是AEC和ANS，AEC的NLP演算法考慮到了非常多的細節，如果想要研究它的演算法，可以好好的看下它的專利說明。

DE是延時估計模組，現在幾乎所有的延時估計模組的都用的這一套演算法。AGC主要任務是將非噪聲部分調高，噪聲部分調低，這裡的重點就在於如何區分噪聲，等於一個降噪的問題。

WebRTC中的AGC是和VAD放在一起的，VAD採用的是GMM模型，通過統計學的方式來判斷當前是否是Voice，然後在結合到AGC上，所有雖然AGC中的引數仍然要調整，但是演算法還是不錯的，可以直接拿來用。

ACM

WebRTC的編解碼器有ILBC、ISAC 、Opus，ILBC是窄帶編碼器、ISAC是寬頻編碼器、Opus是全帶的音訊和語音統一的編碼器。在CPU效能較強且能夠接受高頻寬的情況下Opus可以做的非常好。

ANM

ANM做的是頻寬估計和擁塞控制，由於現在頻寬較大，所以音訊方面的頻寬估計已經很少有人在做了，視訊方面還是比較常見。比較有意思的是音訊的頻寬估計被寫入到了ISAC的程式碼中。

我們知道丟包一般分為兩種，隨機丟包和bond丟包，擁塞就屬於bond丟包的範疇，比如連續丟失多個包或無法發包都算作擁塞。

ANM中的PLC是一種拉伸快進和慢放的演算法，比如要在100毫秒的包中存放200毫秒的資料的時候，PLC就會將包給慢放以實現200毫秒的效果，通過這種方式來應對網路丟包。PLC的優勢在於變速不變調。

視訊

相對音訊模組，視訊部分可以挖掘的空間還很多，容易做出差異化。

視訊對網路的要求會更高，直播和通訊是常見的場景。直播的時候關注的是清晰度，而通訊方面更注重流暢度。側重點的不同，帶來了更多的引數調整。比如結合編解碼器考慮抗丟包、結合降噪考慮編解碼等，以及硬體的適配。