來源：
如何快速搭建一個完整的手機直播系統(tǒng)
搭建一個完整的手機直播都包含哪些必須的環(huán)節(jié)：推流端（采集、前處理、編碼、推流），服務端處理（轉碼、錄制、截圖、鑒黃），播放器（拉流、解碼、渲染）、互動系統(tǒng)（聊天室、禮物系統(tǒng)、贊）。
手機直播推流端需要做哪些工作？
直播推流端即主播端，主要通過手機攝像頭采集視頻數(shù)據(jù)和麥克風采集音頻數(shù)據(jù)，經(jīng)過一系列前處理、編碼、封裝，然后推流到CDN進行分發(fā)。
采集
手機直播SDK通過手機攝像頭和麥克風直接采集視頻數(shù)據(jù)和音頻數(shù)據(jù)。其中,視頻采樣數(shù)據(jù)一般采用RGB或YUV格式、音頻采樣數(shù)據(jù)一般采用PCM格式。對于采集到的原始音視頻的體積是非常大的，因此需要經(jīng)過壓縮技術來處理，降低視頻的大小來提示傳輸效率。 在手機視頻采集方面，iOS系統(tǒng)在硬件的兼容性方面做得比較好，系統(tǒng)本身提供了比較完整的視頻采集的接口，使用起來也比較簡單。但是，Android系統(tǒng)就比較麻煩了，千奇百怪的機型都有，適配起來非常難。我們在初期做了一項調研，發(fā)現(xiàn)Android的適配率還不到50%。
前處理
在這個環(huán)節(jié)主要處理美顏、水印、模糊等效果。特別是美顏功能幾乎是直播的標配功能，沒有美顏的直播主播們根本提不起興趣。我們見過太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印并回放留存15天以上。所以，在選擇直播SDK時，沒有美顏和水印功能基本就可以選擇放棄了。美顏實際上是通過算法去識別圖像中的皮膚部分，再對皮膚區(qū)域進行色值調整。通常情況下人的膚色與周邊環(huán)境色調存在較大差異，通過顏色對比，找到皮膚的基本輪廓，進一步進行膚色檢查還可以確定人臉范圍。找到了皮膚的區(qū)域，可以進行色值調整、添加白色圖層或調整透明度等來等來達到美白效果。美顏除了美白效果還需要磨皮功能，磨皮實際上就是用模糊濾鏡實現(xiàn)的。濾鏡有很多種，如高斯濾波，雙邊濾波，導向濾波，到底選擇什么樣的模糊濾鏡各家也有自己的喜好。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持IOS和Android，還支持自己寫算法實現(xiàn)自己最理性的效果。GPUImage本事內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了，比如大家可以試試使用GPUImageBilateralFiter的雙邊濾波濾鏡來處理基本的磨皮效果，想要實現(xiàn)更理想的效果還是要通過自定義算法去實現(xiàn)的，各家也都有自己一套算法。
編碼
為了便于手機視頻的推流、拉流以及存儲，通常采用視頻編碼壓縮技術來減少視頻的體積?，F(xiàn)在比較常用的視頻編碼是H.264，但具有更高性能的H.265編碼技術正在飛速發(fā)展，并可能很快成為主流；在音頻方面，通比較常用的是用AAC編碼格式進行壓縮，其它如MP3、WMA也是可選方案。視頻經(jīng)過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經(jīng)過壓縮后的視頻在播放時必須進行解碼。通俗點講就是編碼器將多張圖像進行編碼后產(chǎn)生一段段GOP（Group of Pictures），播放時解碼器讀取一段段GOP進行解碼后讀取圖像并進行渲染顯示。 在編碼方面的核心是在分辨率、碼率、幀率等參數(shù)中找到最佳平衡點，達到體積最小畫面最優(yōu)的效果，這些參數(shù)各家也都有自己的一套核心參數(shù)。2012年8月，愛立信公司推出了首款H.265編解碼器，六個月后，國際電聯(lián)(ITU)就正式批準通過了HEVC/H.265標準，稱之為高效視頻編碼(High Efficiency Video Coding)，相較于之前的H.264標準有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低于1.5Mbps的網(wǎng)絡也能傳輸1080p的高清視頻。國內，如阿里云、金山云都在推自己的H.265編解碼技術，隨著直播的快速發(fā)展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。當然，全面推開應用還需要些時間。另外，硬件編碼已經(jīng)成為手機直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在IOS平臺上硬件編碼的兼容性比較好，可以直接采用，但在 Android 平臺上，Android的MediaCodec 編碼器，針對不同的芯片平臺表現(xiàn)差異還是非常大的，要完全實現(xiàn)全平臺兼容的成本還是非常高的。
推流
要想用于推流還必須把音視頻數(shù)據(jù)使用傳輸協(xié)議進行封裝，變成流數(shù)據(jù)。常用的流傳輸協(xié)議有RTSP、RTMP、HLS等，使用RTMP傳輸?shù)难訒r通常在1–3秒，對于手機直播這種實時性要求非常高的場景，RTMP也成為手機直播中最常用的流傳輸協(xié)議。最后通過一定的Qos算法將音視頻流數(shù)據(jù)推送到網(wǎng)絡斷，通過CDN進行分發(fā)。 在直播場景中，網(wǎng)絡不穩(wěn)定是非常常見的，這時就需要Qos來保證網(wǎng)絡不穩(wěn)情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網(wǎng)絡狀況，動態(tài)碼率和幀率也是最常用的策略。當然，在網(wǎng)絡傳輸方面全部自己來做基本不現(xiàn)實，找提供推流服務的CDN服務商提供解決方案是最好的選擇，可參考文章開頭介紹的云視頻服務商。據(jù)了解，阿里云是國內唯一能自研CDN緩存服務器的廠商，性能還是非常有保障的。通常，大多數(shù)直播平臺都會同時接入多個視頻云服務提供商，這樣可以做拉流線路互備，對推流后視頻集群再進行優(yōu)化也可提高直播的流暢性和穩(wěn)定性。
服務端處理需要做哪些工作？
要想適配各終端和平臺，服務端還需要對流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不同網(wǎng)絡和分辨率的終端設備。另外，像現(xiàn)在必備的鑒黃功能也需要服務端完成。
截圖、錄制、水印
像阿里云、金山云、UCloud等云服務商都提供了實時轉碼技術將用戶推流碼率較高（比如720P）實時轉化成較低清晰度（比如360P）的流以適應播放端的需求。如果要自己搭建實時轉碼系統(tǒng)，這個成本是極高的。一臺8核設備只能實時轉10 路流，如果一個正常的直播平臺有1000路流，那至少就需要100臺設備，加上后期的運維成本，一般公司就吃不消了。實時截圖功能和實時轉碼類似，只是一般單機可以處理100路流。市面上云服務提供商基本上都提供了服務端轉碼、截圖、錄制功能，建議選擇好的云服務提供商即可，可以節(jié)約大量成本。
鑒黃
2016年，4月14日上午10時，文化部公布了一則消息，斗魚、虎牙、YY、熊貓TV、戰(zhàn)旗TV、龍珠直播、六間房、9158等網(wǎng)絡直播平臺因涉嫌提供含宣揚淫穢、暴力、教唆犯罪等內容的互聯(lián)網(wǎng)文化產(chǎn)品，被列入查處名單。文化部已部署相關執(zhí)法機構查處涉案企業(yè)，將及時公布處罰結果。在前期的野蠻生長后，國家介入管制一定程度上遏制了直播的發(fā)展速度，但更有利于直播行業(yè)打造健康的生態(tài)，進入良性發(fā)展。這也意味著直播行業(yè)鑒黃成了必須環(huán)節(jié)，使用技術手段去鑒黃是手機直播平臺必然采用的方案。市面上提供鑒黃服務的方案主要有兩種，第一種是對視頻進行截圖，然后對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業(yè)有阿里（綠網(wǎng)）、圖譜科技，他們目前都支持直接傳入視頻，經(jīng)過服務端分析返回結果，鑒黃的結果分為色情、疑似色情、正常或性感，并對每種結果進行打分。通常由業(yè)務系統(tǒng)接入鑒黃服務，根據(jù)鑒黃結果對直播流進行控制，如切斷直播流、禁用用戶的賬號等。第二種是和CDN結合，直接對直播流進行分析，識別結果也分為色情、疑似色情、性感和正常，業(yè)務系統(tǒng)根據(jù)識別結果直接控制直播流。典型的企業(yè)是Viscovery，這套方案的優(yōu)點是實時性保證比較好，缺點是必須部署到CDN或自己的機房，使用成本相對高一些。趣拍微視頻云服務作為一站式直播解決方案提供商，我們的主旨是讓用戶以最短時間、最小成本接入直播服務。因此，用戶只需在控制臺對鑒黃服務進行配置就可以針對每個應用，每一路直播流進行實時審核，審核內容包括色情、暴恐、時政敏感等。在控制臺中，趣拍微視頻服務實時將鑒黃結果返回，用戶可以直接查看色情直播和違規(guī)界面的截圖，同時可以對直播流進行控制，切斷問題直播流。我們提供了短信、郵件和站內信提供功能，避免漏洞一個非法視頻，給平臺造成損失。數(shù)據(jù)統(tǒng)計功能讓用戶可以把握平臺最新的動態(tài)信息，為進一步采取必要的措施提供可靠的依據(jù)。同時，為了滿足用戶定制化需求，我們還提供了豐富的接口，可以很方便的將鑒黃服務接入到自己的業(yè)務系統(tǒng)。
播放器端需要做哪些工作？
在播放器端如何做到秒開，在直播過程中保證畫面和聲音清晰度的同時，穩(wěn)定、流程、無卡頓的直播流量，這些工作都需要播放器端配合服務端來做優(yōu)化，做到精確調度。
拉流
拉流實際是推流的逆過程。首先通過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協(xié)議，開源軟件和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播，直播延遲一般在1–3秒。HLS是蘋果提出的基于HTTP的流媒體傳輸協(xié)議，HTML5可以直接打開播放，通過微信、QQ等軟件分享出去，用戶也可以直接觀看直播，可以說手機直播app，HLS拉流協(xié)議是必須支持的，缺點是延遲通常大于10秒。FLV（HTTP-FLV）協(xié)議是使用HTTP協(xié)議傳輸流媒體內容的一個協(xié)議，也不用擔心被Adobe的專利綁架，直播延遲同樣可以做到1–3秒。趣拍微視頻云服務的直播拉流提供了RTMP、HLS、FLV三種格式，滿足不同業(yè)務場景的需求，如對即時性要求較高或有互動需求的可以采用RTMP或FLV格式進行直播拉流播放；對于有回放或跨平臺需求的，推薦使用HLS。當然，三種協(xié)議是可以同時使用的，分別用到自己的場景就可以了。
解碼和渲染
拉流獲取封裝的視頻數(shù)據(jù)后，必須通過解碼器解碼、渲染后才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數(shù)據(jù)中提取原始數(shù)據(jù)。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取后的原始數(shù)據(jù)，并非原始采樣數(shù)據(jù)，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數(shù)保留最好的原始畫面，成為了各視頻公司的核心機密?？紤]對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，IOS系統(tǒng)由于硬件比較單一、比較封閉，支持的比較好，Android系統(tǒng)由于平臺差異非常大，編解碼要完全兼容各平臺還需要很多工作要做。渲染最大的難點不在與畫面繪制，而在于畫音同步，業(yè)內大部分直播平臺在這塊做的都還是不夠的。我們在這方面積累了一些經(jīng)驗和大家分享。
手機直播中的交互系統(tǒng)
手機直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，有些比較有特色的手機直播平臺也加入了和主播互動的游戲功能。交互系統(tǒng)涉及消息的實時性和互動性，在技術實現(xiàn)上大多是使用IM的功能來實現(xiàn)的，對服務器的壓力也是比較大。 對于在線人數(shù)比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解服務器壓力，在產(chǎn)品策略可以做一些必要的優(yōu)化，比如對于發(fā)送消息的頻率進行限制或對每條消息發(fā)送對象的上限進行限制等。
禮物系統(tǒng)
禮物系統(tǒng)已是絕大多數(shù)手機直播平臺的標配了，它是這些平臺主要的收入來源。在手機直播平臺上我們常?？梢砸姷酵梁烂氚瘛⑼梁缹λ⒌那榫?，據(jù)報道，明星直播一場禮物收入幾十萬也是常有的事，一年千萬收入的網(wǎng)紅也不少，可見國內有禮物消費習慣的土豪還不少。另一方面，送禮物的形式增強了用戶和主播之間的互動交流，也是主播依賴平臺的最主要原因。禮物的收發(fā)在技術實現(xiàn)上也是用聊天室接口做的，通常采用IM中的自定義消息實現(xiàn)，當用戶收到或發(fā)送禮物時將自定義消息對應的禮物圖形渲染出來。另外，面對大量用戶刷禮物時，禮物系統(tǒng)對一致性要求就比較高了，所以在實現(xiàn)上存一份數(shù)據(jù)建多條索引是一種很好的選擇，也可以降低對事務的依賴。
連麥
連麥是互動直播中常見的需求，其流程如上圖所示。主播和部分觀眾之間可以進行實時互動，然后將互動結果實時播放給其他觀眾觀看。
基于以上業(yè)務需求，我們很容易想到基于單向直播原理，在主播端和連麥觀眾端進行雙向推流和雙向播流的方式互動，然后在服務端將兩路推流合成一路推送給其他觀眾。但 RTMP 帶來的延遲決定了這種方式無法做到用戶可接受的互動直播。
實際上，互動直播的主要技術難點在于：
1）低延遲互動：保證主播和互動觀眾之間能夠實時互動，兩者之間就像電話溝通，因此必須保證兩者能在秒級以內聽到對方的聲音，看到對方的視頻；
2）音畫同步：互動直播中對音畫同步的需求和單向直播中類似，只不過互動直播中的延遲要求更高，必須保證在音視頻秒級傳輸情況下的秒級同步。
3）音視頻實時合成：其他觀眾需要實時觀看到對話結果，因此需要在客戶端或者服務端將畫面和聲音實時合成，然后以低成本高品質的方式傳輸觀眾端。
在視頻和電話會議領域，目前比較成熟的方案是使用思科或者 WebEx 的方案，但這些商用的方案一不開源，二比較封閉，三成本比較高。對于互動人數(shù)比較少的互動直播，目前市場上比較成熟的方案是使用基于 WebRTC 的實時通訊方案。
上圖是一個基于 WebRTC 協(xié)議實現(xiàn)多方實時通訊的示意圖，本地用戶（主播）和遠程用戶（連麥觀眾）之間的連接通過 RTCPeerConnection API 管理，這個 API 包裝了底層流管理和信令控制相關的細節(jié)?；谠摲桨缚梢暂p松實現(xiàn)多人（14 人以下）的多方實時通信，如下圖所示：
當然，在通信人數(shù)少的情況下，其復雜度相對簡單，如 2 人情況下。但人數(shù)增多至 4 人之后，其可選的網(wǎng)絡結構就增多了，如上圖所示，可以每個點之間形成自組織網(wǎng)絡的方式通信，也可以以 1 人為中心形成星型通信網(wǎng)絡，還可以讓大家都通過一個集中式的服務端進行通信。
幾個概念
GOP:（Group of Pictures）畫面組，一個GOP就是一組連續(xù)的畫面，每個畫面都是一幀，一個GOP就是很多幀的集合
- 直播的數(shù)據(jù)，其實是一組圖片，包括I幀、P幀、B幀，當用戶第一次觀看的時候，會尋找I幀，而播放器會到服務器尋找到最近的I幀反饋給用戶。因此，GOP Cache增加了端到端延遲，因為它必須要拿到最近的I幀
- GOP Cache的長度越長，畫面質量越好
碼率:圖片進行壓縮后每秒顯示的數(shù)據(jù)量。
幀率:每秒顯示的圖片數(shù)。影響畫面流暢度，與畫面流暢度成正比：幀率越大，畫面越流暢；幀率越小，畫面越有跳動感。
- 由于人類眼睛的特殊生理結構，如果所看畫面之幀率高于16的時候，就會認為是連貫的，此現(xiàn)象稱之為視覺暫留。并且當幀速達到一定數(shù)值后，再增長的話，人眼也不容易察覺到有明顯的流暢度提升了。
分辨率:(矩形)圖片的長度和寬度，即圖片的尺寸
壓縮前的每秒數(shù)據(jù)量:幀率X分辨率(單位應該是若干個字節(jié))
`壓縮比':壓縮前的每秒數(shù)據(jù)量/碼率 （對于同一個視頻源并采用同一種視頻編碼算法，則：壓縮比越高，畫面質量越差。）
視頻處理框架
GPUImage:GPUImage是一個基于OpenGL ES的一個強大的圖像/視頻處理框架,封裝好了各種濾鏡同時也可以編寫自定義的濾鏡,其本身內置了多達120多種常見的濾鏡效果。
OpenGL:OpenGL（全寫Open Graphics Library）是個定義了一個跨編程語言、跨平臺的編程接口的規(guī)格，它用于三維圖象（二維的亦可）。OpenGL是個專業(yè)的圖形程序接口，是一個功能強大，調用方便的底層圖形庫。
OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集，針對手機、PDA和游戲主機等嵌入式設備而設計。
視頻編碼框架
FFmpeg:是一個跨平臺的開源視頻框架,能實現(xiàn)如視頻編碼,解碼,轉碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協(xié)議非常豐富,幾乎包含了所有音視頻編解碼、封裝格式以及播放協(xié)議。
X264:把視頻原數(shù)據(jù)YUV編碼壓縮成H.264格式
VideoToolbox:蘋果自帶的視頻硬解碼和硬編碼API，但是在iOS8之后才開放。
AudioToolbox:蘋果自帶的音頻硬解碼和硬編碼API
