Android IOS WebRTC 音視頻開發總結（七十）-- 移動端音視頻技術最佳化的七個方向

標籤：

最近直播很火，很多朋友對背後的技術比較感興趣，所以今天我們整理一篇關於移動端視頻最佳化的文章，這篇文章是我朋友在一個技術大會上分享過的，更多內容請關注我們的公眾號：rtcblacker

 

ApsaraVideo for Live為什麼會這麼火？

首先，音ApsaraVideo for Live、點播的需求一直大量存在，包括各種行業應用，比如視頻門戶、娛樂直播、遊戲直播、線上教育、遠程醫學，遠程監控，企業協作，社交應用等等。“以前之所以沒有全面爆發，是因為硬體條件不滿足，比如網路的頻寬有限”，目前網速仍在不斷提升，光纖普及到小區，有線網路的上下行頻寬已經達到要求，“移動網路4G接入速度也很快，滿足了基本的ApsaraVideo for Live頻寬要求。而且網路資費也比較低，變得福士可接受。”

 

其次，智能硬體裝置大量普及，特別是大屏智能手機、平板，基本是人手一台。同時這些裝置的效能也越來越強勁。硬體效能的提升解決了視頻編解碼的效能瓶頸，可以拿手機、平板作為PC機器使用。

 

再次，回到商業本質就是直播賺錢快，有興趣的朋友可以看看我之前寫的：三個角度分析美女ApsaraVideo for Live這個行業

 

接下來看看移動端音視頻技術最佳化的幾個方向：

第一，選擇通用性好，效能良好，複雜度相對較低的編碼器，主流的是H.264編碼器，開源的主要是x264和openh264，其中openh264是思科開源項目，針對即時視訊通話情境做了最佳化。另外vp8也針對移動端也做了很多最佳化。

 

第二，在選定一個編碼通訊協定之後，就要看是否採用硬體編碼方式，如果採用軟體編碼，那麼會比較耗費cpu資源，表現出來就是裝置發燙，耗電快，但是裝置相容性好，幾乎可以在任何裝置上運行。如果採用硬體編碼方式，那麼編碼效能好，完全可以支援1080p映像全高清的即時編碼，而且也省電，但是裝置的適配性比較差，特別Android裝置的硬體編碼模式支援的比較差。ios裝置支援的適配性比較好，但是，沒有開放更底層的編碼介面，難做到按幀擷取碼流，進行即時直播。另外用硬體編碼方式，也比較難做動態碼率控制。針對網路直播和點播情境，在編碼階段要盡量做到碼率波動的平滑，這個需要最佳化碼率控制演算法。

第三，對於Gop的大小也要根據應用情境做適當的調整，如果主要畫面格之間的間隔小，那麼碼率會出現頻繁的尖峰，發送資料的時候，會造成瞬間的擁塞。
　　

第四，可以通過設定buffer來解決碼率波動問題，比如在推流端增加一個發送緩衝區，按照固定的碼率發送資料，而不是根據每幀資料來發送。同樣在播放器也可以設定一個接收buffer，解決網路波動對播放造成的頻繁卡頓。但是這個設定過大的buffer會增加延時，不適合直播應用，比較適合點播應用。對於直播情境，要求端到端的延時盡量小，播放端能快速啟動，看到畫面。對於rtmp直播還要解決累計延時，可以採用在播放器主動清空buffer的方法。
　　

第五，不管是直播還是點播服務，都存在一個端到端的資料轉送鏈路問題。在推流端先要串連到接流伺服器，這時就要選擇合適的節點，一種是根據用戶端的DNS網域名稱來選擇就近的節點，當DNS配置有誤的時候，可能會存在調度不準的問題。另外一種是根據用戶端的出口IP來選擇節點，這種調度方式會比較準確一些。同樣對於播放器端也是採用類似的方式來選擇流媒體伺服器叢集的邊緣節點。
　　

第六，在整個直播或點播過程中，最好有即時統計資料，包括網路類型，機器資訊，即時網路狀況，幀率，碼率，分別率等。這樣可以分析遇到的各種問題，特別是對於直播情境，當網路波動，出現卡頓時，可以為動態調整qos提供依據。
　　

第七，對於直播情境，採用qos策略，動態調整編碼參數，包括幀率，碼率，解析度，緩衝區。當直播出現卡頓，採用快降慢升的策略，當網路波動比較厲害，這樣可以避免編碼參數頻繁的來回調整，造成惡性迴圈。當進行編碼參數調整時，一般是根據解析度把碼率，幀率分成幾個檔次，然後在根據一定時間段內的統計資料，在這幾組參加集會之間進行來回切換，確保音視頻流暢的同時，盡量提高映像品質。

 

喜歡系列文章，歡迎掃描下方二維碼關注我們的公眾號：rtcblacker

Android IOS WebRTC 音視頻開發總結（七十）-- 移動端音視頻技術最佳化的七個方向