建一個完整的移動直播系統(tǒng)至少要做到這幾點

注：本文作者蔣海兵，趣拍產品總監(jiān)，直播行業(yè)老兵。

　　移動直播行業(yè)的火熱會在很長一段時間內持續(xù)，通過和各行業(yè)的整合，從而成為具有無限可能性的行業(yè)。主要有以下三個原因：

　　第一，移動直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，完全順應了互聯(lián)網時代的開放性原則，能刺激更多人去創(chuàng)造和傳播優(yōu)質內容。

　　第二，網絡帶寬和速度在逐漸提高，網絡成本在逐漸下降，為移動直播提供一個極佳的發(fā)展環(huán)境。文字、聲音、視頻、游戲等都會在移動直播中呈現(xiàn)，創(chuàng)造出更加豐富的用戶體驗。直播可以以SDK的形式接入到自己的應用中，比如，教育領域中的課后輔導完全可以以直播的形式開展業(yè)務、電商也可借助直播讓用戶挑選商品，促進銷售。

　　第三，一個與VR/AR技術相結合的移動直播為整個行業(yè)的未來提供了新的發(fā)展空間。VR/AR直播能夠讓用戶身臨其境，帶動主播與觀眾更貼近真實的互動，大大提高平臺的用戶參與度。

　　當下，有技術實力和流量優(yōu)勢的互聯(lián)網從業(yè)者都不愿錯過直播這個風口，如何快速搭建一個直播系統(tǒng)成了大家關心的問題，我想和大家分享下我的經驗。我從事于一家直播產品開發(fā)商，我們的產品為了快速趕上市場，使用了云服務提供商的直播SDK。

　　從業(yè)者都知道，一個完整直播產品應該包含以下環(huán)節(jié)：推流端（采集、前處理、編碼、推流）、服務端處理（轉碼、錄制、截圖、鑒黃）、播放器（拉流、解碼、渲染）、互動系統(tǒng)（聊天室、禮物系統(tǒng)、贊）。 下面我就一一講述下直播SDK在各個環(huán)節(jié)所做的工作。

　　一、移動直播推流端需要做哪些工作？

　　直播推流端即主播端，主要通過手機攝像頭采集視頻數(shù)據(jù)和麥克風采集音頻數(shù)據(jù)，經過一系列前處理、編碼、封裝，然后推流到CDN進行分發(fā)。

　　1、采集

　　移動直播SDK通過手機攝像頭和麥克風直接采集音視頻數(shù)據(jù)。其中，視頻采樣數(shù)據(jù)一般采用RGB或YUV格式、音頻采樣數(shù)據(jù)一般采用PCM格式。采集到的原始音視頻的體積是非常大的，需要經過壓縮技術處理來提高傳輸效率。
附：（采集，iOS是比較簡單的，Android則要做些機型適配工作，PC最麻煩各種奇葩攝像頭驅動，出了問題特別不好處理，建議放棄PC只支持手機主播，目前幾個新進的直播平臺都是這樣的。）

　　2、前處理

　　在這個環(huán)節(jié)主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標配功能（80%的主播不美顏壓根沒法看）。我們調研中發(fā)現(xiàn)太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印并回放留存15天以上。

　　3、編碼

　　為了便于手機視頻的推流、拉流以及存儲，通常采用視頻編碼壓縮技術來減少視頻的體積，現(xiàn)在比較常用的視頻編碼是H.264。在音頻方面，比較常用的是AAC 編碼格式，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮后的視頻在播放時必須進行解碼。
附：（編碼，肯定要采用硬編碼，軟編碼720p完全沒希望，勉強能編碼也會導致CPU過熱燙到攝像頭。硬編碼兼容性又是一個大坑，android上要有人去填。編碼要在分辨率，幀率，碼率，等參數(shù)設計上找到最佳平衡點。）

　　4、推流

　　要想用于推流還必須把音視頻數(shù)據(jù)使用傳輸協(xié)議進行封裝，變成流數(shù)據(jù)。常用的流傳輸協(xié)議有RTSP、RTMP、HLS等，使用RTMP傳輸?shù)难訒r通常在1–3秒，對于移動直播這種實時性要求非常高的場景，RTMP也成為移動直播中最常用的流傳輸協(xié)議。最后通過一定的Qos算法將音視頻流數(shù)據(jù)推送到網絡斷，通過CDN進行分發(fā)。在直播場景中，網絡不穩(wěn)定是非常常見的，這時就需要 Qos來保證網絡不穩(wěn)情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網絡狀況，動態(tài)碼率和幀率也是最常用的策略。
附：（推流，自己做不現(xiàn)實，交給CDN服務商吧，也就是貴了點，相信有志于做直播平臺改變世界的你不差錢。假設2W PCU大約每月帶寬費用100萬左右，因為清晰流暢的720p要1.5mbps左右。CDN只提供了帶寬和服務器間傳輸，發(fā)送和接收端的網絡連接抖動緩沖還是要自己寫的。不想要卡頓，必然要加大緩沖，會導致延遲高，延遲高影響互動性，要做權衡。）

　　二、服務端處理需要做哪些工作？

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

　　1、截圖、錄制、水印

　　2、鑒黃

　　第一種是對視頻進行截圖，然后對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業(yè)有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，經過服務端分析返回結果。通常由業(yè)務系統(tǒng)接入鑒黃服務，根據(jù)鑒黃結果對直播流進行控制，如切斷直播流、封禁賬號等。

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

　　三、播放器端需要做哪些工作？

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

　　1、拉流

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

　　各拉流協(xié)議的差異：

　　2、解碼和渲染

　　拉流獲取封裝的視頻數(shù)據(jù)后，必須通過解碼器解碼、渲染后才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數(shù)據(jù)中提取原始數(shù)據(jù)。前面介紹的H.264和 H.265編碼格式都是有損壓縮，所以在提取后的原始數(shù)據(jù)，并非原始采樣數(shù)據(jù)，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數(shù)保留最好的原始畫面，成為了各視頻公司的核心機密。

　　考慮對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，iOS系統(tǒng)由于硬件比較單一、比較封閉，支持的比較好，Android系統(tǒng)由于平臺差異非常大，編解碼要完全兼容各平臺還需要很多工作要做。

　　四、移動直播中的交互系統(tǒng)

　　移動直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，交互系統(tǒng)涉及消息的實時性和互動性，在技術實現(xiàn)上大多是使用IM的功能來實現(xiàn)的。對于在線人數(shù)比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解服務器壓力，在產品策略需要做一些必要的優(yōu)化。

　　1、聊天室

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

　　2、禮物系統(tǒng)

　　送禮物的形式增強了用戶和主播之間的互動交流，也是主播依賴平臺的最主要原因。禮物的收發(fā)在技術實現(xiàn)上也是用聊天室接口做的，通常采用IM中的自定義消息實現(xiàn)，當用戶收到或發(fā)送禮物時將自定義消息對應的禮物圖形渲染出來。

　　禮物的收發(fā)在技術實現(xiàn)上也是用聊天室接口做的，通常采用IM中的自定義消息實現(xiàn)，當用戶收到或發(fā)送禮物時將自定義消息對應的禮物圖形渲染出來。
附：（聊天室與禮物系統(tǒng) 到現(xiàn)在幾乎都是標配）