一、說明

近兩年來直播行業越來越火，各個直播平臺加一起差不多300多家。有些直播平臺做秀場、綜娛類的直播(來瘋直播)，有的做游戲直播(熊貓直播)，有的做體育賽事的直播(樂視直播)，分類也各種各樣。下面一張圖很好地反映了國內直播平臺的大致分類。

本人有幸參與到了來瘋Android手機直播的研發，本著技術分享的精神，現在寫一系列的文章來介紹安卓手機直播，一方面希望能幫助大家了解Android手機直播相關的技術，另一方面也當作是自己工作一段時間的總結。

二、總體

如果讓大家馬上去開發一款Android直播應用，大家可能感覺到無從下手，因此從總體上了解整個手機直播過程是十分重要的。

手機直播需要實現的無非是將手機采集到的視頻和音頻經過處理后以一定的格式發送到服務器端，整個過程如下所示：

三、采集

采集主要包括兩個方面：視頻采集和音頻采集。視頻通過攝像頭進行采集，這里面涉及到攝像頭的相關操作以及攝像頭的參數設置，由于各個手機廠商的攝像頭存在差異，因此這方面有一些坑，之后的講攝像頭的文章中會一一講述。音頻通過麥克風進行采集，不同手機的麥克風對音頻采樣率的支持不同，而且有時候為了支持連麥功能需要對音頻進行回聲消除。

視頻采集技術要點：

• 檢測攝像頭是否可以使用;
• 攝像頭采集到的圖像是橫向的，需要對采集到的圖像進行一定的旋轉后再進行顯示;
• 攝像頭采集時有一系列的圖像大小可以選擇，當采集的圖像大小和手機屏幕大小比例不一致時，需要進行特殊處理;
• Android手機攝像頭有一系列的狀態，需要在正確的狀態下才能對攝像頭進行相應的操作;
• Android手機攝像頭的很多參數存在兼容性問題，需要較好地處理這些兼容性的問題。

音頻采集技術要點：

• 檢測麥克風是否可以使用;
• 需要檢測手機對某個音頻采樣率的支持;
• 在一些情況下需要對音頻進行回聲消除處理;
• 音頻采集時設置正確的緩沖區大小。

四、處理

視頻處理

美顏現在幾乎是一個手機直播軟件的標配，經過美顏后主播顏值更高，對粉絲也就更有吸引力，也有一些安卓直播應用可以對主播進行人臉識別，然后添加好玩的動畫特效，有些時候我們也需要對視頻添加水印。

其實對視頻進行美顏和添加特效都是通過OpenGL進行處理的。Android中有GLSurfaceView，這個類似于SurfaceView，不過可以利用Renderer對其進行渲染。通過OpenGL可以生成紋理，通過紋理的Id可以生成SurfaceTexture，而SurfaceTexture可以交給Camera，***通過紋理就將攝像頭預覽畫面和OpenGL建立了聯系，從而可以通過OpenGL進行一系列的操作。

美顏的整個過程無非是根據Camera預覽的紋理通過OpenGL中FBO技術生成一個新的紋理，然后在Renderer中的onDrawFrame()使用新的紋理進行繪制。添加水印也就是先將一張圖片轉換為紋理，然后利用OpenGL進行繪制。添加動態掛件特效則比較復雜，先要根據當前的預覽圖片進行算法分析識別人臉部相應部位，然后在各個相應部位上繪制相應的圖像，整個過程的實現有一定的難度。

下圖是整個美顏過程的流程圖：

下面的圖片很好地展示了美顏和動畫效果。

音頻處理

在一些情況下，主播需要添加一些額外的聲音以增加直播氣氛，比如：鼓掌聲等等。一種處理方式是讓附加的聲音直接播放出來，這樣麥克風會采集到然后一起錄制，但是這樣的處理在主播戴上耳機或者需要對聲音進行回聲消除處理的情況下就不能起到作用。由于我們項目中也未加入相應功能，暫時未有相關經驗進行分享，之后我們可能會加上這個功能，到時候再和大家分享。

五、編碼

通過攝像頭和麥克風我們可以采集到相應的視音頻數據，但是這些是固定格式的原始數據，一般來說攝像頭采集到的是一幀一幀畫面，而麥克風采集的是PCM音頻數據。如果直接將這些數據進行發送，這樣往往會數據量很大，造成很大的帶寬浪費，因此在發送前往往需要對視音頻進行編碼。

視頻編碼

1、預測編碼

眾所周知，一幅圖像由許多個所謂像素的點組成，大量的統計表明，同一幅圖像中像素之間具有較強的相關性，兩個像素之間的距離越短，則其相關性越強，通俗地講，即兩個像素的值越接近。于是，人們可利用這種像素間的相關性進行壓縮編碼，這種壓縮方式稱為幀內預測編碼。不僅如此，鄰近幀之間的相關性一般比幀內像素間的相關性更強，壓縮比也更大。由此可見，利用像素之間(幀內)的相關性和幀間的相關性，即找到相應的參考像素或參考幀作為預測值，可以實現視頻壓縮編碼。

2、變換編碼

大量統計表明，視頻信號中包含著能量上占大部分的直流和低頻成分，即圖像的平坦部分，也有少量的高頻成分，即圖像的細節。因此，可以用另一種方法進行視頻編碼，將圖像經過某種數學變換后，得到變換域中的圖像(如圖所示)，其中 u，v 分別是空間頻率坐標。

3、基于波形的編碼

基于波形的編碼采用了把預測編碼和變換編碼組合起來的基于塊的混合編碼方法。為了減少編碼的復雜性，使視頻編碼操作易于執行，采用混合編碼方法時，首先把一幅圖像分成固定大小的塊，例如塊 8×8(即每塊 8 行，每行 8 個像素)、塊 16×16(每塊 16 行，每行 16 個像素)等等，然后對塊進行壓縮編碼處理。

自 1989 年 ITU-T 發布***個數字視頻編碼標準——H.261 以來，已陸續發布了 H.263 等視頻編碼標準及 H.320、H.323 等多媒體終端標準。ISO 下屬的運動圖像專家組(MPEG)定義了 MPEG-1、MPEG-2、MPEG-4 等娛樂和數字電視壓縮編碼國際標準。

2003 年 3 月份，ITU-T 頒布了 H.264 視頻編碼標準。它不僅使視頻壓縮比較以往標準有明顯提高，而且具有良好的網絡親和性，特別是對 IP 互聯網、無線移動網等易誤碼、易阻塞、QoS 不易保證的網絡視頻傳輸性能有明顯的改善。 所有這些視頻編碼都采用了基于塊的混合編碼法，都屬于基于波形的編碼。

4、基于內容的編碼

還有一種基于內容的編碼技術，這時先把視頻幀分成對應于不同物體的區域，然后對其編碼。具體說來，即對不同物體的形狀、運動和紋理進行編碼。在最簡單情況下，利用二維輪廓描述物體的形狀，利用運動矢量描述其運動狀態，而紋理則用顏色的波形進行描述。

當視頻序列中的物體種類已知時，可采用基于知識或基于模型的編碼。例如，對人的臉部，已開發了一些預定義的線框對臉的特征進行編碼，這時編碼效率很高，只需少數比特就能描述其特征。對于人臉的表情(如生氣、高興等)，可能的行為可用語義編碼，由于物體可能的行為數目非常小，可獲得非常高的編碼效率。

MPEG-4 采用的編碼方法就既基于塊的混合編碼，又有基于內容的編碼方法。

5、軟編與硬編

在Android平臺上實現視頻的編碼有兩種實現方式，一種是軟編，一種是硬編。軟編的話，往往是依托于cpu，利用cpu的計算能力去進行編碼。比如我們可以下載x264編碼庫，寫好相關的jni接口，然后傳入相應的圖像數據。經過x264庫的處理以后就將原始的圖像轉換成為h264格式的視頻。

硬編則是采用Android自身提供的MediaCodec，使用MediaCodec需要傳入相應的數據，這些數據可以是yuv的圖像信息，也可以是一個Surface，一般推薦使用Surface，這樣的話效率更高。Surface直接使用本地視頻數據緩存，而沒有映射或復制它們到ByteBuffers;因此，這種方式會更加高效。在使用Surface的時候，通常不能直接訪問原始視頻數據，但是可以使用ImageReader類來訪問不可靠的解碼后(或原始)的視頻幀。這可能仍然比使用ByteBuffers更加高效，因為一些本地緩存可以被映射到 direct ByteBuffers。當使用ByteBuffer模式，可以利用Image類和getInput/OutputImage(int)方法來訪問到原始視頻數據幀。

音頻編碼

Android中利用AudioRecord可以錄制聲音，錄制出來的聲音是PCM聲音。想要將聲音用計算機語言表述，則必須將聲音進行數字化。將聲音數字化，最常見的方式是透過脈沖編碼調制PCM(Pulse Code Modulation) 。聲音經過麥克風，轉換成一連串電壓變化的信號。要將這樣的信號轉為 PCM 格式的方法，是使用三個參數來表示聲音，它們是：聲道數、采樣位數和采樣頻率。

1、采樣頻率

即取樣頻率，指每秒鐘取得聲音樣本的次數。采樣頻率越高，聲音的質量也就越好，聲音的還原也就越真實，但同時它占的資源比較多。由于人耳的分辨率很有限，太高的頻率并不能分辨出來。在16位聲卡中有22KHz、44KHz等幾級，其中，22KHz相當于普通FM廣播的音質，44KHz已相當于CD音質了，目前的常用采樣頻率都不超過48KHz。

2、采樣位數

即采樣值或取樣值(就是將采樣樣本幅度量化)。它是用來衡量聲音波動變化的一個參數，也可以說是聲卡的分辨率。它的數值越大，分辨率也就越高，所發出聲音的能力越強。

在計算機中采樣位數一般有8位和16位之分，但有一點請大家注意，8位不是說把縱坐標分成8份，而是分成2的8次方即256份; 同理16位是把縱坐標分成2的16次方65536份。

3、聲道數

很好理解，有單聲道和立體聲之分，單聲道的聲音只能使用一個喇叭發聲(有的也處理成兩個喇叭輸出同一個聲道的聲音)，立體聲的pcm可以使兩個喇叭都發聲(一般左右聲道有分工) ，更能感受到空間效果。

那么，現在我們就可以得到pcm文件所占容量的公式：

• 存儲量=(采樣頻率 采樣位數 聲道 時間)? 8 (單位：字節數)

如果音頻全部用PCM的格式進行傳輸，則占用帶寬比較大，因此在傳輸之前需要對音頻進行編碼。

現在已經有一些廣泛使用的聲音格式，如：wav、MIDI、MP3、WMA、AAC、Ogg等等。相比于pcm格式而言，這些格式對聲音數據進行了壓縮處理，可以降低傳輸帶寬。

對音頻進行編碼也可以分為軟編和硬編兩種。軟編則下載相應的編碼庫，寫好相應的jni，然后傳入數據進行編碼。硬編則是使用Android自身提供的MediaCodec。

六、打包

視音頻在傳輸過程中需要定義相應的格式，這樣傳輸到對端的時候才能正確地被解析出來。

1、HTTP-FLV

Web 2.0時代，要說什么類型網站最火，自然是以國外的Youtube，國內的優酷、土豆網站了。這類網站提供的視頻內容可謂各有千秋，但它們無一例外的都使用了Flash作為視頻播放載體，支撐這些視頻網站的技術基礎就是——Flash 視頻(FLV) 。FLV 是一種全新的流媒體視頻格式，它利用了網頁上廣泛使用的Flash Player 平臺，將視頻整合到Flash動畫中。也就是說，網站的訪問者只要能看Flash動畫，自然也能看FLV格式視頻，而無需再額外安裝其它視頻插件，FLV視頻的使用給視頻傳播帶來了極大便利。

HTTP-FLV即將音視頻數據封裝成FLV，然后通過HTTP協議傳輸給客戶端。而作為上傳端只需要將FLV格式的視音頻傳輸到服務器端即可。

一般來說FLV格式的視音頻，里面視頻一般使用h264格式，而音頻一般使用AAC-LC格式。

FLV格式是先傳輸FLV頭信息，然后傳輸帶有視音頻參數的元數據(Metadata)，然后傳輸視音頻的參數信息，然后傳輸視音頻數據。

2、RTMP

RTMP是Real Time Messaging Protocol(實時消息傳輸協議)的首字母縮寫。該協議基于TCP，是一個協議簇，包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。RTMP是一種設計用來進行實時數據通信的網絡協議，主要用來在Flash/AIR平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通信。

RTMP協議是Adobe公司推出的實時傳輸協議，主要用于基于flv格式的音視頻流的實時傳輸。得到編碼后的視音頻數據后，先要進行FLV包裝，然后封包成rtmp格式，然后進行傳輸。

使用RTMP格式進行傳輸，需要先連接服務器，然后創建流，然后發布流，然后傳輸相應的視音頻數據。整個發送是用消息來定義的，rtmp定義了各種形式的消息，而為了消息能夠很好地發送，又對消息進行了分塊處理，整個協議較為復雜。

還有其他幾種形式的協議，比如RTP等等，大致原理差不多，也就不一一進行說明講述了。

七、差網絡處理

好的網絡下視音頻能夠得到及時的發送，不會造成視音頻數據在本地的堆積，直播效果流暢，延時較小。而在壞的網絡環境下，視音頻數據發送不出去，則需要我們對視音頻數據進行處理。差網絡環境下對視音頻數據一般有四種處理方式：緩存區設計、網絡檢測、丟幀處理、降碼率處理。

1、緩沖區設計

視音頻數據傳入緩沖區，發送者從緩沖區獲取數據進行發送，這樣就形成了一個異步的生產者消費者模式。生產者只需要將采集、編碼后的視音頻數據推送到緩沖區，而消費者則負責從這個緩沖區里面取出數據發送。

上圖中只顯示了視頻幀，顯然里面也有相應的音頻幀。要構建異步的生產者消費者模式，java已經提供了很好的類，由于之后還需要進行丟幀、插入、取出等處理，顯然LinkedBlockingQueue是個很不錯的選擇。

2、網絡檢測

差網絡處理過程中一個重要的過程是網絡檢測，當網絡變差的時候能夠快速地檢測出來，然后進行相應的處理，這樣對網絡反應就比較靈敏，效果就會好很多。

我們這邊通過實時計算每秒輸入緩沖區的數據和發送出去數據，如果發送出去的數據小于輸入緩沖區的數據，那么說明網絡帶寬不行，這時候緩沖區的數據會持續增多，這時候就要啟動相應的機制。

3、丟幀處理

當檢測到網絡變差的時候，丟幀是一個很好的應對機制。視頻經過編碼后有關鍵幀和非關鍵幀，關鍵幀也就是一副完整的圖片，而非關鍵幀描述圖像的相對變化。

丟幀策略多鐘多樣，可以自行定義，一個需要注意的地方是：如果要丟棄P幀(非關鍵幀)，那么需要丟棄兩個關鍵幀之間的所有非關鍵幀，不然的話會出現馬賽克。對于丟幀策略的設計因需求而異，可以自行進行設計。

4、降碼率

在Android中，如果使用了硬編進行編碼，在差網絡環境下，我們可以實時改變硬編的碼率，從而使直播更為流暢。當檢測到網絡環境較差的時候，在丟幀的同時，我們也可以降低視音頻的碼率。在Android sdk版本大于等于19的時候，可以通過傳遞參數給MediaCodec，從而改變硬編編碼器出來數據的碼率。

Bundle bitrate = new Bundle();bitrate.putInt(MediaCodec.PARAMETER_KEY_VIDEO_BITRATE, bps * 1024); 
mMediaCodec.setParameters(bitrate); 

八、發送

經過各種處理，***需要將數據發送出去，這一步較為簡單。無論是HTTP-FLV，還是RTMP，我們這邊都是使用TCP建立連接的。直播開始之前需要通過Socket連接服務器，驗證是否能連接服務器，連接之后便使用這個Socket向服務器發送數據，數據發送完畢后關閉Socket。