Android 關于直播，推流，拉流

1.直播

內建的騰訊的互動直播的SDK做到（注冊開發者，填寫資訊，建立項目，下載下傳SDK，導入項目，配置build檔案，添加user-pressen權限和Activity權限，在application檔案中初始化就完成了內建的步驟。）

用ijkplayer的實作播放，ijkplayer功能很強大，它是bilibili基于ffmpeg做的一個輕量級視訊播放架構，能播放本地視訊，也能播放網絡流媒體，Android和ios都可以用，支援編碼，解碼，轉碼，複用，解複用，流，過濾器等功能，支援大多是視訊格式的播放，并且還提供了錄制，轉換以及流化音頻格式的是方案，它有一個特别先進的libavcodec的編碼庫。

2.推流

通過攝像頭和麥克擷取視訊和音頻資料，把視訊和音頻資料壓縮成H264視訊格式和ACC音頻格式，封裝并發送給伺服器，伺服器再根據相關的協定分發。

3.拉流

從伺服器擷取相關的二進制資訊，再通過解複用得到封裝前的H264視訊和ACC音頻，再解壓，把解壓後的視訊和音頻同步到耳機和螢幕上。

4.推流拉流的三種協定

HLS協定：蘋果公司的開發的，把流媒體切分成若幹片段（TS檔案），通過一個m3u清單檔案，将這些TS檔案集中起來播放。分發的協定是http協定，優點是可以根據網絡狀态的不同選擇不同碼率的流，根據網絡狀态調整自動調整清晰度。

RTSP協定和RTMP協定：RTSP協定實時性比較好，是共有協定，有專門維護的機構，一般以TS或者mp4為傳輸格式，有兩個通道，可以滿足實時性0.5秒以内的直播需求。RTMP是私有協定，沒有被完全公開，隻有一個通道，一般一flv和f4v為傳輸格式

5.直播中音視訊不同步的問題

修改時間戳：選擇一個時間戳，在生成資料流時依據參考時間給每個資料庫都打上時間戳，播放時讀取資料庫上的時間戳。

6.優化延遲，卡頓，抖動，流暢度

産生原因：

1.推流端網絡抖動導緻資料無法發送到伺服器，造成播放端卡頓。

2.播放端網絡抖動導緻資料累積在伺服器上拉不下來，造成播放發困。

解決方案：

播放器将拉流線程和解碼線程分開，建立一個緩沖隊列用于緩沖音視訊資料，拉流線程從伺服器拉取音視訊流放入隊列，解碼線程從伺服器擷取音視訊資料解碼播放。列的長度可以調整。當網絡發生抖動時，播放器無法從伺服器上擷取到資料或擷取資料的速度較慢，此時隊列中緩存的資料可以起到一個過渡的作用，讓使用者感覺不到網絡發生了抖動。

7.丢包處理方案

7.1.重傳：丢什麼資料傳什麼資料，不會浪費資源

7.2.向前糾錯（FEC）：發送方将要發送的資料附加上一定的備援糾錯碼一并發送，接收方則根據糾錯碼對資料進行差錯檢測，如發現差錯，由接收方進行糾正，特點：使用糾錯碼（糾錯碼編碼效率低且裝置複雜）、單向信道、發送方無需設定緩沖器。(FEC 算法其中一個稱之為異或。假如有 4 個資料，那麼它們可以取 4 個異或值，其中每一個資料都可以由另外 4 個異或值計算出來。還可以把 ABCD 和 E 想象成一個資料包，如果我們傳輸 ABCD 這四個資料包，第五個資料包傳輸的是 E，這五個資料包可以丢失任何 1 個資料包。接收方收到資料之後，能夠把它丢的資料恢複出來。前向糾錯算法能處理的是連續資料裡隻丢 1 個包。同時丢失 A 和 B，這個算法不能解決。)

7.3.交叉傳輸 -- 處理連續丢包的情況

交叉傳輸，我們日常看到多媒體可能是按照時序的，一個多媒體片斷是由 1 到 10 組成。如果此過程當中有丢包，比如 3456 連續丢失，那麼此次丢包的影響可能表現在視訊播放出現停頓。若丢的是關鍵幀那麼影響非常大，會導緻後面一大片的花屏。是以當連續丢包對流媒體傷害特别大的情況下，可以采用交叉傳輸政策。1 到 10，原來是 3 個 3 個傳，如 123、456、789 各傳一次，那麼現在可以改變傳輸政策，采用 147、280 和 369 的傳輸政策，這樣一組資料丢掉，實際丢失在流媒體中間穿插的資料，播放程式可以在幾乎不失真的狀态下把視訊恢複出來。

8.直播流程

采集視訊，音頻→視訊處理（美顔，濾鏡等）→音視訊資料壓縮→推流→流媒體伺服器資料處理→拉流→音視訊解碼→播放→聊天互動→彈幕

9.音頻資料參數

9.1聲道數：單聲道，立體聲

9.2采樣率：每分鐘獲得聲音樣本的次數，

9.3采樣位數：8位，16位

10.視訊資料參數分析

10.1分辨率：一張圖由多少像素點組成

10.2幀率：一個視訊，每一秒由多少圖像構成

10.3碼率：視訊檔案體積/時間（kbit/s或者mbit/s）