一個成熟的直播系統應該具有什麼條件

移動直播行業的火了很長一段時間，經過和各行業的整合，從而成爲具備無限可能性的行業，因此直播這個行業上也有了不少的商機和潛在價值。主要有如下三個緣由：

 

　　第一，移動直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，徹底順應了互聯網時代的開放性原則，能刺激更多人去創造和傳播優質內容。

 

　　第二，網絡帶寬和速度在逐漸提升，網絡成本在逐漸降低，爲移動直播提供一個極佳的發展環境。文字、聲音、視頻、遊戲等都會在移動直播中呈現，創造出更加豐富的用戶體驗。直播能夠以SDK的形式接入到本身的應用中，好比，教育領域中的課後輔導徹底能夠以直播的形式開展業務、電商也可藉助直播讓用戶挑選商品，促進銷售。

 

　　第三，一個與VR/AR技術相結合的移動直播爲整個行業的將來提供了新的發展空間。VR/AR直播可以讓用戶身臨其境，帶動主播與觀衆更貼近真實的互動，大大提升平臺的用戶參與度。

 

　　當下，有技術實力和流量優點的互聯網從業者都不肯錯過直播這個風口，如何快速搭建一個直播系統成了你們關心的問題，我想和你們分享下個人經驗。我從事於一家直播產品開發商，咱們的產品爲了快速遇上市場，使用了雲服務提供商的直播SDK。

 

　　從業者都知道，一個完整直播產品應該包含如下環節：推流端（採集、前處理、編碼、推流）、服務端處理（轉碼、錄製、截圖、鑑黃）、播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）。 下面我就一一講述下直播SDK在各個環節所作的工做。

 

　　1、移動直播推流端須要作哪些工做？

 

　　直播推流端即主播端，主要經過手機攝像頭採集視頻數據和麥克風採集音頻數據，通過一系列前處理、編碼、封裝，而後推流到CDN進行分發。

 

　　手機端推流

 

　　一、採集

 

　　移動直播SDK經過手機攝像頭和麥克風直接採集音視頻數據。其中，視頻採樣數據通常採用RGB或YUV格式、音頻採樣數據通常採用PCM格式。採集到的原始音視頻的體積是很是大的，須要通過壓縮技術處理來提升傳輸效率。

附：（採集，iOS是比較簡單的，Android則要作些機型適配工做，PC最麻煩各類奇葩攝像頭驅動，出了問題特別很差處理，建議放棄PC只支持手機主播，目前幾個新進的直播平臺都是這樣的。）

二、前處理

 

　　在這個環節主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標配功能（80%的主播不美顏壓根無法看）。咱們調研中發現太多case是由於沒有美顏功能被拋棄使用的。另外國家明確提出了，全部直播都必須打有水印並回放留存15天以上。

 

　　三、編碼

 

　　爲了便於手機視頻的推流、拉流以及存儲，一般採用視頻編碼壓縮技術來減小視頻的體積，如今比較經常使用的視頻編碼是H.264。在音頻方面，比較經常使用的是AAC 編碼格式，其它如MP三、WMA也是可選方案。視頻通過編碼壓縮大大提升了視頻的存儲和傳輸效率，固然，通過壓縮後的視頻在播放時必須進行解碼。

附：（編碼，確定要採用硬編碼，軟編碼720p徹底沒但願，勉強能編碼也會致使CPU過熱燙到攝像頭。硬編碼兼容性又是一個大坑，android上要有人去填。編碼要在分辨率，幀率，碼率，等參數設計上找到最佳平衡點。）

 

　　四、推流

 

　　要想用於推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。經常使用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時一般在1–3秒，對於移動直播這種實時性要求很是高的場景，RTMP也成爲移動直播中最經常使用的流傳輸協議。最後經過必定的Qos算法將音視頻流數據推送到網絡斷，經過CDN進行分發。在直播場景中，網絡不穩定是很是常見的，這時就須要 Qos來保證網絡不穩狀況下的用戶觀看直播的體驗，一般是經過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網絡情況，動態碼率和幀率也是最經常使用的策略。    

附：（推流，本身作不現實，交給CDN服務商吧，也就是貴了點，相信有志於作直播平臺改變世界的你不差錢。假設2W PCU大約每個月帶寬費用100萬左右，由於清晰流暢的720p要1.5mbps左右。CDN只提供了帶寬和服務器間傳輸，發送和接收端的網絡鏈接抖動緩衝仍是要本身寫的。不想要卡頓，必然要加大緩衝，會致使延遲高，延遲高影響互動性，要作權衡。）

 

　　2、服務端處理須要作哪些工做？

 

　　要想適配各終端和平臺，服務端還須要對推流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不一樣網絡和分辨率的終端設備。

 

　　一、截圖、錄製、水印

 

　　二、鑑黃

 

　　第一種是對視頻進行截圖，而後對圖片進行鑑黃，返回鑑黃結果和分值。典型的企業有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，通過服務端分析返回結果。一般由業務系統接入鑑黃服務，根據鑑黃結果對直播流進行控制，如切斷直播流、封禁帳號等。

 

　　第二種是和CDN結合，直接對直播流進行分析，識別結果分爲色情、疑似色情、性感和正常，業務系統根據識別結果直接控制直播流。典型的企業是Viscovery，這套方案的優勢是實時性保證比較好，缺點是必須部署到CDN或本身的機房，使用成本相對高一些。

 

　　3、播放器端須要作哪些工做？

 

　　在播放器端如何作到秒開，直播過程當中保證畫面和聲音清晰度的同時，穩定、流程、無卡頓的直播流量，這些工做都須要播放器端配合服務端來作優化，作到精確調度。

 

　　一、拉流

 

　　拉流實際是推流的逆過程。首先經過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協議，開源軟件和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能很是簡單的播放RTMP直播，直播延遲通常在1–3秒。

 

　　各拉流協議的差別：

 

　　協議差別

 

　　二、解碼和渲染

 

　　拉流獲取封裝的視頻數據後，必須經過解碼器解碼、渲染後才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數據中提取原始數據。前面介紹的H.264和 H.265編碼格式都是有損壓縮，因此在提取後的原始數據，並不是原始採樣數據，存在必定的信息丟失。所以，在視頻體積最小的狀況下經過各類編碼參數保留最好的原始畫面，成爲了各視頻公司的核心機密。

 

　　考慮對高清的支持，解碼確定仍是要選擇硬解碼的。前面介紹過，iOS系統因爲硬件比較單1、比較封閉，支持的比較好，Android系統因爲平臺差別很是大，編解碼要徹底兼容各平臺還須要不少工做要作。

4、移動直播中的交互系統

 

　　移動直播中最多見的交互有聊天室（彈幕）、點贊、打賞和禮物等，交互系統涉及消息的實時性和互動性，在技術實現上大可能是使用IM的功能來實現的。對於在線人數比較多的房間，彈幕消息量是很是大，主播與用戶其實都看不過來，爲了緩解服務器壓力，在產品策略須要作一些必要的優化。

 

　　一、聊天室

 

　　移動直播中的彈幕交互是用戶和主播互動的主要方式，實際上就是IM中的聊天室功能。聊天室和羣聊功能相似，但聊天室的消息是不須要分發給不在線的用戶的，歷史消息也不須要查看，用戶只有進入聊天室後才能查看聊天消息和羣成員信息。面對複雜多變的網絡情況，還須要根據用戶位置就近選擇近對應運營商的單線機房接入彈幕消息服務，讓彈幕更及時。

 

　　二、禮物系統

 

　　送禮物的形式加強了用戶和主播之間的互動交流，也是主播依賴平臺的最主要緣由。禮物的收發在技術實現上也是用聊天室接口作的，一般採用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。

 

　　禮物的收發在技術實現上也是用聊天室接口作的，一般採用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。

        附：（聊天室與禮物系統 到如今幾乎都是標配）

 

那麼如今美麗播直播系統開發團隊到來，把最優質的技術和手段呈上，咱們有強大的技術人員和運維，爲你解決一切的直播+方案，爲您量身定製你的直播平臺！http://www.meilibo.net