移動端互動直播(入門篇)

標籤：m3u   授權   Once   .net   ++   體會   策略   發送資料   架構   

本文來自網易雲社區前言

本文為手機ApsaraVideo for Live開發新手,為了快速入門,利用強大google搜尋引擎結合自身理解而整理的"ApsaraVideo for Live入門背景知識"。

背景知識
名詞解釋
推流協議
RTMP

Real Time Messaging Protocol（即時訊息傳送協議）

使用 Flash Player 作為播放器用戶端，而Flash Player 現在已經安裝在了全世界將近99%的PC上，因此一般情況下收看RTMP流媒體系統的視音頻是不需要安裝外掛程式的。使用者只需要開啟網頁，就可以直接收看流媒體，十分方便

1. 工作在TCP之上的明文協議，使用連接埠1935；

2. RTMPT封裝在HTTP請求之中，可穿越防火牆；

3. RTMPS類似RTMPT，但使用的是HTTPS串連；

HLS

HTTP Live Streaming

HLS 是蘋果公司QuickTime X和iPhone軟體系統的一部分。它的工作原理是把整個流分成一個個小的基於HTTP的檔案來下載，每次只下載一些。當媒體流現正播放時，用戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的資料速率。在開始一個流媒體會話時，用戶端會下載一個包含中繼資料的extended M3U (m3u8) playlist檔案，用於尋找可用的媒體流。

用戶端支援

• iOS從3.0開始成為標準功能。

• Adobe Flash Player從11.0開始支援HLS。

• Google的Android自Honeycomb（3.0）開始支援HLS。

• VODOBOX HLS Player (Android,iOS, Adobe Flash Player)

• JWPlayer (Adobe Flash)

• Flowplayer (Adobe Flash,使用hlsjs版本不使用Adobe Flash)

• Windows 10 的 EDGE 瀏覽器開始支援HLS。

H264編碼

H264是一種高壓縮率的編碼通訊協定，如何壓縮嘞？一般的視頻採集都是25幀/秒，也就是每秒25次，其實每一張圖片的內容都相差不大，壓縮的辦法就是利用演算法，只將每張圖片變動差異化的部分儲存下來，這樣視頻檔案就小多了

MKV

俄文матроска是матрёшка（俄羅斯套娃）的誤讀，因為Matroska的工作原理就跟層層套疊的俄羅斯娃娃一樣，是“愈包愈緊”的，故得名。而mkv只是Matroska媒體系列的其中一種檔案格式。

相關術語

YUV

YUV主要用於最佳化彩色視頻訊號的傳輸，使其向後相容老式黑白電視。與RGB視頻訊號傳輸相比，它最大的優點在於只需佔用極少的頻寬

PCM

脈衝編碼調製(PCM)就是把一個時間連續，取值連續的類比訊號變換成時間離散，取值離散的數字訊號後在通道中傳輸。脈衝編碼調製就是對類比訊號先抽樣，再對樣值幅度量化，編碼的過程

muxer

muxer是指合并檔案，即將視頻檔案、音頻檔案和字幕檔案合并為某一個視頻格式。比如把rmvb格式的視頻，mp3格式的音頻檔案以及srt格式的字幕檔案，合并成為一個新的mp4或者mkv格式的檔案。

demuxer

demuxer是muxer的逆過程，就是把合成的檔案中提取出不同的格式檔案。

整體架構
架構圖

角色職能

App端推流

音頻採集模型

最佳化策略
服務品質策略

推流端會根據當前上行網路情況控制音視頻資料發包和編碼，在網路較差的情況下，音視頻資料發送不出去，造成資料滯留在本地，這時，會停掉編碼器防止發送資料進一步滯留，同時會根據網路情況選擇合適的策略控制音視頻發送。

比如網路很差的情況下，推流端會優先發送音頻資料，保證使用者能聽到聲音，並在一定間隔內發主要畫面格資料，保證使用者在一定時間間隔之後能看到一些畫面的變化。

配置主要畫面格

合理控制主要畫面格發送間隔（建議2秒或1秒一個），這樣可以減少後端處理過程，為後端的緩衝區設定更小創造條件。

雲端伺服器
整體結構

 

服務合約
SRS

• 開源

• 1.架構簡潔，功能強大
  2.主要支援rtmp協議
  3.叢集支援

CRTMP

• 開源

• 1.c++開發
  2.支援協議豐富
  3.對叢集支援不夠好

nginx—rtmp

• 開源

• 1.全非同步模型實現，效能優勢
  2.穩定性不足

Red5

• 開源

• 1.純java
  2.效能不足

FMS

• 不開源

• 1.adobe流媒體伺服器
  2.效能和功能都不錯

  
  

ApsaraVideo for Live轉碼功能問題

錄製，直播轉碼，鑒黃，，分發。

ApsaraVideo for Live播流端的碼率是根據推流端決定的，即播流端的碼率是與推流端的碼率一致的。但是遇到以下情境會造成直播效果較差：

• 推流端碼率與播流端頻寬不相匹配。當推流端碼率較高而用戶端頻寬資源有限就會導致播放出現卡頓，而當推流端碼率較低但是用戶端對於直播效率要求較高時會導致播放效果較差。

• 播放器外掛程式需要實現多碼率切換。前端播放器外掛程式常可以設定碼率切換，這就需要同一路推流可以同時提供多種碼率的播流地址。

因此，ApsaraVideo for Live提供了即時轉碼功能對同一路推流地址同時提供多路不同碼率播流地址提供服務。

App端拉流

編碼策略
推流編碼-硬

推薦Andorid4.3（API18）或以上使用硬編，以下版本使用軟編；iOS使用全硬編方案；

拉流編碼-軟

Andorid、iOS播放器都使用軟解碼方案，經過我們和大量客戶的測試以及總結，雖然犧牲了功耗，但是在部分細節方面表現會較優，且可控性強，相容性也強，出錯情況少，推薦使用。

優缺點
軟編/解碼

• 優點

1. 相容性強

2. 色彩比寫入程式碼強

3. 編碼課操作空間大，自由度高

• 缺點

1. 吃cpu，消耗比較大

硬編/解碼

• 優點

1. 功耗低，執行效率高

• 缺點

1. 晶片的差異性

2. 可控性比較低
   

特色功能
互動白板
資料封裝

 

布局結構

彈幕
布局結構

DanmakuFlameMaster彈幕實現

參考資料

• 開源架構 RTMP live streaming client for Android https://github.com/begeekmyfriend/yasea

• 直播架構圖 https://netease.im/edu

• RTMP協議介紹 https://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol

• 音頻處理隊列 https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/AudioQueueProgrammingGuide/AboutAudioQueues/AboutAudioQueues.html#//apple_ref/doc/uid/TP40005343-CH5-SW1

• ApsaraVideo for Live技術原理和方案參考 https://github.com/f2e-journey/xueqianban/issues/61

 

網易雲新使用者大禮包：https://www.163yun.com/gift

 

本文來自網易雲社區，經作者金劍授權發布

移動端互動直播(入門篇)