一、說(shuō)明

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

本人有幸參與到了來(lái)瘋Android手機(jī)直播的研發(fā)，本著技術(shù)分享的精神，現(xiàn)在寫一系列的文章來(lái)介紹安卓手機(jī)直播，一方面希望能幫助大家了解Android手機(jī)直播相關(guān)的技術(shù)，另一方面也當(dāng)作是自己工作一段時(shí)間的總結(jié)。

二、總體

如果讓大家馬上去開(kāi)發(fā)一款A(yù)ndroid直播應(yīng)用，大家可能感覺(jué)到無(wú)從下手，因此從總體上了解整個(gè)手機(jī)直播過(guò)程是十分重要的。

手機(jī)直播需要實(shí)現(xiàn)的無(wú)非是將手機(jī)采集到的視頻和音頻經(jīng)過(guò)處理后以一定的格式發(fā)送到服務(wù)器端，整個(gè)過(guò)程如下所示：

三、采集

采集主要包括兩個(gè)方面：視頻采集和音頻采集。視頻通過(guò)攝像頭進(jìn)行采集，這里面涉及到攝像頭的相關(guān)操作以及攝像頭的參數(shù)設(shè)置，由于各個(gè)手機(jī)廠商的攝像頭存在差異，因此這方面有一些坑，之后的講攝像頭的文章中會(huì)一一講述。音頻通過(guò)麥克風(fēng)進(jìn)行采集，不同手機(jī)的麥克風(fēng)對(duì)音頻采樣率的支持不同，而且有時(shí)候?yàn)榱酥С诌B麥功能需要對(duì)音頻進(jìn)行回聲消除。

視頻采集技術(shù)要點(diǎn)：

• 檢測(cè)攝像頭是否可以使用;
• 攝像頭采集到的圖像是橫向的，需要對(duì)采集到的圖像進(jìn)行一定的旋轉(zhuǎn)后再進(jìn)行顯示;
• 攝像頭采集時(shí)有一系列的圖像大小可以選擇，當(dāng)采集的圖像大小和手機(jī)屏幕大小比例不一致時(shí)，需要進(jìn)行特殊處理;
• Android手機(jī)攝像頭有一系列的狀態(tài)，需要在正確的狀態(tài)下才能對(duì)攝像頭進(jìn)行相應(yīng)的操作;
• Android手機(jī)攝像頭的很多參數(shù)存在兼容性問(wèn)題，需要較好地處理這些兼容性的問(wèn)題。

音頻采集技術(shù)要點(diǎn)：

• 檢測(cè)麥克風(fēng)是否可以使用;
• 需要檢測(cè)手機(jī)對(duì)某個(gè)音頻采樣率的支持;
• 在一些情況下需要對(duì)音頻進(jìn)行回聲消除處理;
• 音頻采集時(shí)設(shè)置正確的緩沖區(qū)大小。

四、處理

視頻處理

美顏現(xiàn)在幾乎是一個(gè)手機(jī)直播軟件的標(biāo)配，經(jīng)過(guò)美顏后主播顏值更高，對(duì)粉絲也就更有吸引力，也有一些安卓直播應(yīng)用可以對(duì)主播進(jìn)行人臉識(shí)別，然后添加好玩的動(dòng)畫特效，有些時(shí)候我們也需要對(duì)視頻添加水印。

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

美顏的整個(gè)過(guò)程無(wú)非是根據(jù)Camera預(yù)覽的紋理通過(guò)OpenGL中FBO技術(shù)生成一個(gè)新的紋理，然后在Renderer中的onDrawFrame()使用新的紋理進(jìn)行繪制。添加水印也就是先將一張圖片轉(zhuǎn)換為紋理，然后利用OpenGL進(jìn)行繪制。添加動(dòng)態(tài)掛件特效則比較復(fù)雜，先要根據(jù)當(dāng)前的預(yù)覽圖片進(jìn)行算法分析識(shí)別人臉部相應(yīng)部位，然后在各個(gè)相應(yīng)部位上繪制相應(yīng)的圖像，整個(gè)過(guò)程的實(shí)現(xiàn)有一定的難度。

下圖是整個(gè)美顏過(guò)程的流程圖：

下面的圖片很好地展示了美顏和動(dòng)畫效果。

音頻處理

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

五、編碼

通過(guò)攝像頭和麥克風(fēng)我們可以采集到相應(yīng)的視音頻數(shù)據(jù)，但是這些是固定格式的原始數(shù)據(jù)，一般來(lái)說(shuō)攝像頭采集到的是一幀一幀畫面，而麥克風(fēng)采集的是PCM音頻數(shù)據(jù)。如果直接將這些數(shù)據(jù)進(jìn)行發(fā)送，這樣往往會(huì)數(shù)據(jù)量很大，造成很大的帶寬浪費(fèi)，因此在發(fā)送前往往需要對(duì)視音頻進(jìn)行編碼。

視頻編碼

1、預(yù)測(cè)編碼

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

2、變換編碼

大量統(tǒng)計(jì)表明，視頻信號(hào)中包含著能量上占大部分的直流和低頻成分，即圖像的平坦部分，也有少量的高頻成分，即圖像的細(xì)節(jié)。因此，可以用另一種方法進(jìn)行視頻編碼，將圖像經(jīng)過(guò)某種數(shù)學(xué)變換后，得到變換域中的圖像(如圖所示)，其中 u，v 分別是空間頻率坐標(biāo)。

3、基于波形的編碼

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

自 1989 年 ITU-T 發(fā)布***個(gè)數(shù)字視頻編碼標(biāo)準(zhǔn)——H.261 以來(lái)，已陸續(xù)發(fā)布了 H.263 等視頻編碼標(biāo)準(zhǔn)及 H.320、H.323 等多媒體終端標(biāo)準(zhǔn)。ISO 下屬的運(yùn)動(dòng)圖像專家組(MPEG)定義了 MPEG-1、MPEG-2、MPEG-4 等娛樂(lè)和數(shù)字電視壓縮編碼國(guó)際標(biāo)準(zhǔn)。

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

4、基于內(nèi)容的編碼

還有一種基于內(nèi)容的編碼技術(shù)，這時(shí)先把視頻幀分成對(duì)應(yīng)于不同物體的區(qū)域，然后對(duì)其編碼。具體說(shuō)來(lái)，即對(duì)不同物體的形狀、運(yùn)動(dòng)和紋理進(jìn)行編碼。在最簡(jiǎn)單情況下，利用二維輪廓描述物體的形狀，利用運(yùn)動(dòng)矢量描述其運(yùn)動(dòng)狀態(tài)，而紋理則用顏色的波形進(jìn)行描述。

當(dāng)視頻序列中的物體種類已知時(shí)，可采用基于知識(shí)或基于模型的編碼。例如，對(duì)人的臉部，已開(kāi)發(fā)了一些預(yù)定義的線框?qū)δ樀奶卣鬟M(jìn)行編碼，這時(shí)編碼效率很高，只需少數(shù)比特就能描述其特征。對(duì)于人臉的表情(如生氣、高興等)，可能的行為可用語(yǔ)義編碼，由于物體可能的行為數(shù)目非常小，可獲得非常高的編碼效率。

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

5、軟編與硬編

在Android平臺(tái)上實(shí)現(xiàn)視頻的編碼有兩種實(shí)現(xiàn)方式，一種是軟編，一種是硬編。軟編的話，往往是依托于cpu，利用cpu的計(jì)算能力去進(jìn)行編碼。比如我們可以下載x264編碼庫(kù)，寫好相關(guān)的jni接口，然后傳入相應(yīng)的圖像數(shù)據(jù)。經(jīng)過(guò)x264庫(kù)的處理以后就將原始的圖像轉(zhuǎn)換成為h264格式的視頻。

硬編則是采用Android自身提供的MediaCodec，使用MediaCodec需要傳入相應(yīng)的數(shù)據(jù)，這些數(shù)據(jù)可以是yuv的圖像信息，也可以是一個(gè)Surface，一般推薦使用Surface，這樣的話效率更高。Surface直接使用本地視頻數(shù)據(jù)緩存，而沒(méi)有映射或復(fù)制它們到ByteBuffers;因此，這種方式會(huì)更加高效。在使用Surface的時(shí)候，通常不能直接訪問(wèn)原始視頻數(shù)據(jù)，但是可以使用ImageReader類來(lái)訪問(wèn)不可靠的解碼后(或原始)的視頻幀。這可能仍然比使用ByteBuffers更加高效，因?yàn)橐恍┍镜鼐彺婵梢员挥成涞? direct ByteBuffers。當(dāng)使用ByteBuffer模式，可以利用Image類和getInput/OutputImage(int)方法來(lái)訪問(wèn)到原始視頻數(shù)據(jù)幀。

音頻編碼

Android中利用AudioRecord可以錄制聲音，錄制出來(lái)的聲音是PCM聲音。想要將聲音用計(jì)算機(jī)語(yǔ)言表述，則必須將聲音進(jìn)行數(shù)字化。將聲音數(shù)字化，最常見(jiàn)的方式是透過(guò)脈沖編碼調(diào)制PCM(Pulse Code Modulation) 。聲音經(jīng)過(guò)麥克風(fēng)，轉(zhuǎn)換成一連串電壓變化的信號(hào)。要將這樣的信號(hào)轉(zhuǎn)為 PCM 格式的方法，是使用三個(gè)參數(shù)來(lái)表示聲音，它們是：聲道數(shù)、采樣位數(shù)和采樣頻率。

1、采樣頻率

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

2、采樣位數(shù)

即采樣值或取樣值(就是將采樣樣本幅度量化)。它是用來(lái)衡量聲音波動(dòng)變化的一個(gè)參數(shù)，也可以說(shuō)是聲卡的分辨率。它的數(shù)值越大，分辨率也就越高，所發(fā)出聲音的能力越強(qiáng)。

在計(jì)算機(jī)中采樣位數(shù)一般有8位和16位之分，但有一點(diǎn)請(qǐng)大家注意，8位不是說(shuō)把縱坐標(biāo)分成8份，而是分成2的8次方即256份; 同理16位是把縱坐標(biāo)分成2的16次方65536份。

3、聲道數(shù)

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

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

• 存儲(chǔ)量=(采樣頻率 采樣位數(shù) 聲道 時(shí)間)? 8 (單位：字節(jié)數(shù))

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

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

對(duì)音頻進(jìn)行編碼也可以分為軟編和硬編兩種。軟編則下載相應(yīng)的編碼庫(kù)，寫好相應(yīng)的jni，然后傳入數(shù)據(jù)進(jìn)行編碼。硬編則是使用Android自身提供的MediaCodec。

六、打包

視音頻在傳輸過(guò)程中需要定義相應(yīng)的格式，這樣傳輸?shù)綄?duì)端的時(shí)候才能正確地被解析出來(lái)。

1、HTTP-FLV

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

HTTP-FLV即將音視頻數(shù)據(jù)封裝成FLV，然后通過(guò)HTTP協(xié)議傳輸給客戶端。而作為上傳端只需要將FLV格式的視音頻傳輸?shù)椒?wù)器端即可。

一般來(lái)說(shuō)FLV格式的視音頻，里面視頻一般使用h264格式，而音頻一般使用AAC-LC格式。

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

2、RTMP

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

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

使用RTMP格式進(jìn)行傳輸，需要先連接服務(wù)器，然后創(chuàng)建流，然后發(fā)布流，然后傳輸相應(yīng)的視音頻數(shù)據(jù)。整個(gè)發(fā)送是用消息來(lái)定義的，rtmp定義了各種形式的消息，而為了消息能夠很好地發(fā)送，又對(duì)消息進(jìn)行了分塊處理，整個(gè)協(xié)議較為復(fù)雜。

還有其他幾種形式的協(xié)議，比如RTP等等，大致原理差不多，也就不一一進(jìn)行說(shuō)明講述了。

七、差網(wǎng)絡(luò)處理

好的網(wǎng)絡(luò)下視音頻能夠得到及時(shí)的發(fā)送，不會(huì)造成視音頻數(shù)據(jù)在本地的堆積，直播效果流暢，延時(shí)較小。而在壞的網(wǎng)絡(luò)環(huán)境下，視音頻數(shù)據(jù)發(fā)送不出去，則需要我們對(duì)視音頻數(shù)據(jù)進(jìn)行處理。差網(wǎng)絡(luò)環(huán)境下對(duì)視音頻數(shù)據(jù)一般有四種處理方式：緩存區(qū)設(shè)計(jì)、網(wǎng)絡(luò)檢測(cè)、丟幀處理、降碼率處理。

1、緩沖區(qū)設(shè)計(jì)

視音頻數(shù)據(jù)傳入緩沖區(qū)，發(fā)送者從緩沖區(qū)獲取數(shù)據(jù)進(jìn)行發(fā)送，這樣就形成了一個(gè)異步的生產(chǎn)者消費(fèi)者模式。生產(chǎn)者只需要將采集、編碼后的視音頻數(shù)據(jù)推送到緩沖區(qū)，而消費(fèi)者則負(fù)責(zé)從這個(gè)緩沖區(qū)里面取出數(shù)據(jù)發(fā)送。

上圖中只顯示了視頻幀，顯然里面也有相應(yīng)的音頻幀。要構(gòu)建異步的生產(chǎn)者消費(fèi)者模式，java已經(jīng)提供了很好的類，由于之后還需要進(jìn)行丟幀、插入、取出等處理，顯然LinkedBlockingQueue是個(gè)很不錯(cuò)的選擇。

2、網(wǎng)絡(luò)檢測(cè)

差網(wǎng)絡(luò)處理過(guò)程中一個(gè)重要的過(guò)程是網(wǎng)絡(luò)檢測(cè)，當(dāng)網(wǎng)絡(luò)變差的時(shí)候能夠快速地檢測(cè)出來(lái)，然后進(jìn)行相應(yīng)的處理，這樣對(duì)網(wǎng)絡(luò)反應(yīng)就比較靈敏，效果就會(huì)好很多。

我們這邊通過(guò)實(shí)時(shí)計(jì)算每秒輸入緩沖區(qū)的數(shù)據(jù)和發(fā)送出去數(shù)據(jù)，如果發(fā)送出去的數(shù)據(jù)小于輸入緩沖區(qū)的數(shù)據(jù)，那么說(shuō)明網(wǎng)絡(luò)帶寬不行，這時(shí)候緩沖區(qū)的數(shù)據(jù)會(huì)持續(xù)增多，這時(shí)候就要啟動(dòng)相應(yīng)的機(jī)制。

3、丟幀處理

當(dāng)檢測(cè)到網(wǎng)絡(luò)變差的時(shí)候，丟幀是一個(gè)很好的應(yīng)對(duì)機(jī)制。視頻經(jīng)過(guò)編碼后有關(guān)鍵幀和非關(guān)鍵幀，關(guān)鍵幀也就是一副完整的圖片，而非關(guān)鍵幀描述圖像的相對(duì)變化。

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

4、降碼率

在Android中，如果使用了硬編進(jìn)行編碼，在差網(wǎng)絡(luò)環(huán)境下，我們可以實(shí)時(shí)改變硬編的碼率，從而使直播更為流暢。當(dāng)檢測(cè)到網(wǎng)絡(luò)環(huán)境較差的時(shí)候，在丟幀的同時(shí)，我們也可以降低視音頻的碼率。在Android sdk版本大于等于19的時(shí)候，可以通過(guò)傳遞參數(shù)給MediaCodec，從而改變硬編編碼器出來(lái)數(shù)據(jù)的碼率。

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

八、發(fā)送

經(jīng)過(guò)各種處理，***需要將數(shù)據(jù)發(fā)送出去，這一步較為簡(jiǎn)單。無(wú)論是HTTP-FLV，還是RTMP，我們這邊都是使用TCP建立連接的。直播開(kāi)始之前需要通過(guò)Socket連接服務(wù)器，驗(yàn)證是否能連接服務(wù)器，連接之后便使用這個(gè)Socket向服務(wù)器發(fā)送數(shù)據(jù)，數(shù)據(jù)發(fā)送完畢后關(guān)閉Socket。