要搭建本身的實時音視頻服務？你須要留意這些坑

實時音視頻數據的處理、傳輸流程能夠簡要歸納爲：採集、編碼、前處理、傳輸、解碼、後處理、渲染，流程以下圖所示，咱們曾不止一次地講解過這個流程，相信你們早已捻熟於心。從數據採集後進行編碼，到解碼並提供給應用層作渲染，聲網 Agora 視頻/音頻 SDK，能夠幫助開發者解決這個過程當中的開發問題，快速實現多種實時音視頻互動場景。

行業中也有不少團隊，他們有能力自研編解碼，或採用特殊編碼格式、自定義加密編碼、非主流編碼格式，例如：

1. 開發 IoT 產品

與 RTC 相關智能硬件產品有不少，最典型的就是智能眼鏡、智能攝像頭等。它們的編解碼方式通常有兩種，一種是使用芯片廠商提供的 API 進行編解碼，優勢是速度快，但與硬件平臺綁定，缺乏靈活性；另外一種是使用x26四、x265 等進行軟件的方式，優勢是定製化靈活度高，但速度慢。在解決編解碼問題以後，開發團隊還須要本身部署服務器，實現設備間的音視頻互通。

2. 基於 WebRTC 開發

WebRTC 爲不少開發者提供了一個很好的入門階梯，WebRTC 已經自帶了編解碼、降噪、回聲消除的模塊，解決了開發者們在客戶端上的須要開發問題。固然，也有一些團隊有本身優化的編解碼算法，他們能夠在編解碼環節作出更多的優化。很多開發團隊會基於 WebRTC 搭建本身的應用，好比在線教育、社交直播等。不過抽取 WebRTC 中好的部分，進行二次開發，工做量很大。並且，不管怎樣都須要本身搭建信令服務器、媒體服務器，併合理部署節點，優化傳輸策略等。

以上只是比較典型的兩種情。不過對於這類開發團隊來說，最麻煩的問題就是不得不踩一遍「服務端搭建」的那些坑：

1. 複雜網絡的應對

與通常應用不一樣，帶有實時音視頻通話或實時消息指令的應用對服務端的要求更高，須要關注丟包、抖動、延時三個關鍵指標。以丟包爲例，在作公網的實時數據傳輸時，丟包對抗是少不了的。丟包，即未能按時到達的包，一般發生在兩個傳輸階段：Server to Device、Server to Server。

首先，Server to Device 有兩種通路：

a. 服務器-基站-設備。要考慮不一樣類型基站（3G/4G/WDCDMA/TD）、同類基站不一樣地點（好比演唱會附近）、同類基站同地點不一樣時間（好比用網高峯期）、不一樣國家的基站幾種狀況下的傳輸狀況。

b. 服務器-路由-設備。路由分爲 2.4G 和 5G兩個頻段。2.4G 雖然覆蓋面積廣，但容易有干擾和丟包；5G 頻段相比起來干擾、丟包少，但覆蓋面積小，多人鏈接同一路由的話，帶寬競爭嚴重，有時丟包也會很高。並且質量差的路由易出現各類網絡抖動或其它 bug。這些也須要服務端團隊考慮進去。

Server to Server 階段，即骨幹網絡與邊緣網絡。在骨幹網絡中，傳輸也會遇到網絡擁塞。你須要關注同一國家相同運營商之間的傳輸質量，由於在同一運營商間也會出現丟包；還須要關注同一國家不一樣運營商之間的傳輸，由於不少時候，運營商之間的結算和有限帶寬會使得網絡不穩定；若是你的業務是跨地區、跨國的，好比應用出海、在線教育，那麼不一樣國家的傳輸問題會更負責，要在不一樣國家選擇好的機房，並實時監控，不一樣國家的網絡質量差別很大，好比東南亞、部分中東國家。這個階段的傳輸優化是一個專門的技術領域，若是自研須要投入大量人力、精力和開發成本。

2. 運維

要創建一個可靠的 toC 或 toB 服務，24x7 的實時監控與運維必不可少。不只須要作到能及時監測並修復數據傳輸的問題，還須要有效地手段將質量問題透明給本身的研發團隊和用戶。同時，自研開發者還須要作好容災備份策略、鏈路與故障恢復機制。

3. 團隊組建與開發成本

團隊組建確定是基礎。除了自研編解碼算法的團隊之外，還須要一支大前端開發團隊，基於 Web、Native 或基於跨平臺方案來實現多個平臺的客戶端。更重要的是，須要一支服務端團隊解決複雜的網絡架構問題。

另外，從選擇在哪裏部署服務器，到實際開發、實時調配、實時監控等，若是要自已邁過上述這些「坑」，都須要付出研發、時間成本。

聲網正式推出 實時碼流加速 SDK。自研編解碼的開發者，在客戶端完成音視頻數據的處理後，能夠經過實時碼流 SDK 的 API 接入聲網 SD-RTN™實時網，在 SDK 的幫助下全部音視頻數據均可以低延時、高質量傳輸。對於WebRTC 開發者來說，你能夠基於WebRTC 來開發端上的音視頻功能，而後經過RTSA SDK的接口來實現音視頻數據的傳輸，開發者無需本身再搭建服務器。更多詳情：www.agora.io/cn/rtsa/