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

本文來自網易雲社區

前言

本文爲手機視頻直播開發新手,爲了快速入門,利用強大google搜索引擎結合自身理解而整理的"視頻直播入門背景知識"。

背景知識

名詞解釋

推流協議

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.性能和功能都不錯

   

視頻直播轉碼功能問題

錄製，直播轉碼，鑑黃，截圖，分發。

 

視頻直播播流端的碼率是根據推流端決定的，即播流端的碼率是與推流端的碼率一致的。可是遇到如下場景會形成直播效果較差：

 

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

• 播放器插件須要實現多碼率切換。前端播放器插件常能夠設置碼率切換，這就須要同一路推流能夠同時提供多種碼率的播流地址。

 

所以，視頻直播提供了實時轉碼功能對同一路推流地址同時提供多路不一樣碼率播流地址提供服務。

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

• 視頻直播技術原理和方案參考 https://github.com/f2e-journey/xueqianban/issues/61

 

 

 

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

 

本文來自網易雲社區，經做者金劍受權發佈