移動端直播相關技術總結

一、直播APP原理

二、直播APP架構

三、直播APP實現流程

四、流媒體開發

流媒體模塊架構

流媒體相關基礎知識

幀：每一幀代表一幅靜止的圖像

GOP：Group of Pictures，畫面組，一個GOP就是一組連續的畫面，很多幀的集合

碼率：比特率，單位時間內視頻或音頻的數據量

幀率：每秒顯示的圖片數量，幀率越大，畫面越流暢。幀率大于16人眼就會認為是連貫的

壓縮比：壓縮前的碼率/壓縮后碼率

視頻文件格式：文件的后綴，.wmv、.mp4、.mov、.avi

視頻封裝格式：存儲視頻信息的容器，流式封裝（TS、FLV）、索引式封裝（MP4、MOV、AVI）

五、直播基礎知識、原理

1．音視頻采集

1.1 音視頻采集編碼框架

AVFoundation：用于處理音頻、視頻和圖像的捕獲、播放、編輯和導出等功能，提供一套強大的API接口來操作這些視聽數據。

1.2 音視頻硬件設備

CCD：圖像傳感器，用于圖像采集和處理的過程，把圖像轉換成電信號。

拾音器：聲音傳感器，用于聲音采集和處理的過程，把聲音轉換成電信號。

音頻采樣數據：一般為PCM格式。

視頻采樣數據：一般為YUV或RGB格式。（YUV 主要用于視頻壓縮和傳輸，通過減少色度分量的采樣來實現較好的壓縮效果；而 RGB 主要用于圖像處理和顯示，能夠準確表示每個像素的顏色。）

2．視頻處理（美顏，水印）

視頻處理原理：視頻是通過GPU，一幀一幀渲染到屏幕上的，所以我們可以利用OpenGL ES，對視頻幀進行各種加工，從而視頻各種不同的效果。美顏和視頻添加特效可以利用GPUImage這個框架實現的。

GPUImage：GPUImage是一個基于OpenGL ES的一個強大的圖像/視頻處理框架，封裝好了各種濾鏡同時也可以編寫自定義的濾鏡。

OpenGL：Open Graphics Library是個定義了一個跨編程語言、跨平臺的編程接口的規格，它用于二維、三維圖象。OpenGL是個專業的圖形程序接口，是一個功能強大，調用方便的底層圖形庫。

OpenGL ES：OpenGL for Embedded Systems是 OpenGL三維圖形 API 的子集，針對手機、PDA和游戲主機等嵌入式設備而設計。

3．視頻編碼解碼

3.1 視頻編碼框架

FFmpeg：是一個跨平臺的開源視頻框架，能實現視頻編碼、解碼、轉碼、串流、播放等豐富

的功能。其幾乎支持包含了所有音視頻編解碼、封裝格式以及播放協議。

x264：開源的高性能視頻編碼器，把視頻原數據YUV編碼壓縮成H.264格式。

VideoToolbox：蘋果自帶的視頻硬編解碼API，在iOS8之后才開放。

AudioToolbox：蘋果自帶的音頻硬編解碼API，在iOS8之后才開放。

3.2 視頻編碼技術

視頻壓縮編碼標準：對視頻進行壓縮或者解壓縮的編碼技術，如MPEG、H.264。

主要作用：將視頻像素數據壓縮成為視頻碼流，從而降低視頻的數據量。如果視頻不經過壓縮

編碼的話，體積通常是非常大的，一部電影可能就要上百G的空間。

MPEG：它采用了幀間壓縮，僅存儲連續幀之間有差別的地方，從而達到較大的壓縮比。

H.264/AVC：采用事先預測和與MPEG中的P-B幀一樣的幀預測方法壓縮，它可以根據需要產生適合網絡情況傳輸的視頻流，還有更高的壓縮比，有更好的圖像質量。

MPEG和H.264對比：如果是從單個畫面清晰度比較，MPEG4有優勢；從動作連貫性上的清晰度，H.264有優勢；H.264的算法較復雜，需要更多的處理器和內存資源。

H.265/HEVC：基于H.264，保留原來的某些技術，同時對一些相關的技術加以改進，以改善碼流、編碼質量、延時和算法復雜度之間的關系，達到最優化設置。

H.265 是一種更為高效的編碼標準，能夠在同等畫質效果下將內容的體積壓縮得更小，傳輸時更快更省帶寬。

H.264和H.265對比：H.265 相對于 H.264 在壓縮效率和視頻質量方面有較大的優勢，尤其在高分辨率和大帶寬環境下表現更為出色。然而，由于 H.265 存在處理復雜度和兼容性問題。

直播的數據，就是一組圖片，包括I幀、P幀、B幀。

用戶第一次觀看的時候，播放器會到服務器尋找最近的I幀反饋給用戶。

I幀：關鍵幀，保留一副完整的畫面，解碼時只需要本幀數據就可以完成。

P幀：差別幀，保留這一幀跟之前幀的差別，解碼時需要用之前緩存的畫面疊加上本幀定義的差別，生成最終畫面。（P幀沒有完整畫面數據，只有與前一幀的畫面差別的數據）

B幀：雙向差別幀，保留的是本幀與前后幀的差別，解碼B幀，不僅要取得之前的緩存畫面，還要解碼之后的畫面，通過前后畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高，但是解碼時更加消耗CPU。

幀內壓縮：當壓縮一幀圖像時，僅考慮本幀的數據而不考慮相鄰幀之間的冗余信息。幀內一般采用有損壓縮算法。

幀間壓縮：時間壓縮，它通過比較時間軸上不同幀之間的數據進行壓縮。幀間壓縮一般是無損的。

muxing（合成）：將視頻流、音頻流甚至是字幕流封裝到一個文件中（容器格式FLV、TS），作為一個信號進行傳輸。

3.3 音頻編碼技術

常見的音頻編碼格式：MP3、AAC、Speex、Opux等。

特點	MP3	AAC	Opus
壓縮效率	中等	較高	非常高
音頻質量	中等	較好	很好
支持比特率范圍	較窄（中等、較高）	較窄（中等、較高）	廣泛（低、中、高）
主要應用	音樂、廣播等	各種音頻應用	流媒體、視頻會議
兼容性	非常高	高	相對較低

3.4 碼率控制

多碼率：觀眾所處的網絡情況是非常復雜的，有可能是WiFi，有可能5G、4G、甚至3G，那么怎么滿足多方需求呢？多定義幾條線路，根據當前網絡環境自定義碼率。

例如：高清，標清，流暢等，指的就是各種碼率。

3.5 視頻封裝格式

TS：一種流媒體封裝格式，流媒體封裝有一個好處，就是不需要加載索引再播放，大大減少了首次載入的延遲，如果片子比較長，mp4文件的索引相當大，影響用戶體驗。而且兩個TS片段可以無縫拼接，播放器能連續播放。

FLV：一種流媒體封裝格式，由于它形成的文件極小、加載速度極快，使得在線觀看視頻文件成為可能，因此FLV格式成為了當今主流視頻格式。

4．推流

4.1 數據傳輸框架

librtmp：一個開源的 C 庫，用于實現 RTMP協議的客戶端功能，包括 RTMP 連接建立、握手過程、數據交互、音視頻傳輸等。

4.2 流媒體數據傳輸協議

RTMP：Real-Time Messaging Protocol，實時消息傳輸協議，由Adobe公司開發，基于TCP

協議，用于對象、視頻、音頻的傳輸。

RTMP工作原理：

握手：客戶端和服務器之間進行握手，以建立連接。握手過程中包括版本協商和密鑰交換等步驟，確保雙方能夠正常通信。

建立流：客戶端發送一個命令給服務器，請求建立一個流（Stream）。一個流可以包含一個或多個音視頻軌道。

數據交互：客戶端和服務器通過建立的流進行音視頻數據的傳輸。RTMP 會將音視頻數據分割成小的消息進行傳輸，每個消息包含一個時間戳和有效負載。

控制信息：RTMP 還支持發送控制信息，用于控制音視頻的播放、暫停、快進等操作。這些控制信息被封裝在特定的消息類型中，如 SetChunkSize、Play、Pause 等。

5．流媒體服務器

5.1 常用服務器

NGINX-RTMP：基于 Nginx 服務器的一個第三方模塊，支持直播和點播。

Microsoft Azure Media Services：微軟提供的云端流媒體解決方案。

騰訊云：云直播（Cloud Live）、點播（VOD）、直播連麥（RTC）。

5.2 數據分發

CDN：Content Delivery Network，內容分發網絡，是一種分布式的網絡架構，它將內容緩存到離用戶最近的節點服務器上，可以幫助加速音視頻內容的傳輸，減少加載時間，提高用戶訪問網站的響應速度和觀看體驗，另外CDN 還能分擔源站點的負載壓力，提高系統的可擴展性和穩定性。

CDN工作原理：代理服務器，相當于一個中介。例如：請求流媒體數據時

5.3 CDN鏈路

傳統CND鏈路——樹形網絡拓撲：

Cache 系統是整個 CDN 系統中的成本所在，設計樹形結構可以最大化的節省 Cache 系統的資本投入。因為只有中心節點需要保持所有的 Cache 副本，向下逐級減少，到了邊緣節點只需要少量的熱點 Cache 就可以命中大部分 CDN 訪問請求，這樣極大的降低了 CDN 網絡的成本。

網狀網絡拓撲結構：

直播業務是流式業務，很少涉及到 Cache 系統，播完就可以釋放掉存儲資源，對于存儲的投入相對非常低，而且不要求存儲在所有節點中，只要保證數據可回溯即可。

用戶的可選擇鏈路變為：無向圖的指定兩點間的所有路徑，數量非常大。

回源：當有用戶訪問某一個URL的時候，如果被解析到的那個CDN節點沒有緩存響應的內容，或者是緩存已經到期，就會回源站去獲取搜索。如果沒有訪問，那么CDN節點不會主動去源站拿。

帶寬：在固定的時間可傳輸的數據總量，比如64位、800MHz的前端總線，它的數據傳輸率就等于64bit×800MHz÷8(Byte)=6.4GB/s。

QoS：帶寬管理，限制每一個組群的帶寬，讓有限的帶寬發揮最大的效用。

集群、分布式、負載均衡：由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具有等價的地位，都可以單獨對外提供服務而無須其他服務器的輔助。通過某種負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地回應客戶的請求。解決大量并發訪問服務問題。

6．拉流

6.1 RTMP

1>RTMP協議

RTMP協議是基于TCP長連接，既可推流又可以拉流的協議，地址是rtmp://開頭的，并且推流地址和播放地址是一樣的，高并發下可能會出現一些不穩定的問題，所以一般只用作直播源推流、推流到CDN等場景。

2>RTMP強制切片

強制切片也一定程度上保證了實時性，有一定的弱網抵抗能力，因為每個數據包都不會太大，當數據包校驗失敗時，重新發送的成本不會太大，但合并數據包需要CPU的性能消耗。

6.2 HTTP-FLV

1>HTTP-FLV協議

HTTP-FLV協議基于HTTP長連接，可以看作是RTMP的HTTP版本，與RTMP的工作原理相似，延遲為1-3s，比RTMP協議延遲略高，HTTP-FLV協議一般只用作客戶端拉流觀看。

2>HTTP-FLV播放

3>HTTP-FLV流媒體播放器

4>流行的方案：

6.3 HLS

1>HLS協議

HLS基于HTTP短連接，一般只用于拉流觀看，但嚴格地說HLS協議并不是流式協議，工作原理是通過HTTP協議下載靜態文件，HLS協議的文件由兩部分組成，一是多個幾秒長度的ts碎片視頻文件，另一個是記錄這些視頻文件地址的m3u8索引文件，這些靜態文件都是直接寫入磁盤的。

HLS觀看地址是以https://開頭.m3u8結尾的，實際上這個地址就是索引文件地址，客戶端獲取到索引文件后，就可以下載對應的碎片視頻并開始播放了，由于HLS協議實際上是通過HTTP協議請求文件的，且HLS相關文件是直接寫入磁盤的，所以不需要特殊的流媒體服務軟件，使用Nginx的HTTP服務就可以了，網頁加入HLS的js插件就可以播放了。

蘋果設備是原生支持HLS協議的，點播的情況，也就是普通網絡視頻觀看的場景下，m3u8索引文件會記錄所有的碎片視頻文件地址。

2>點播場景

HLS在點播的情況下優勢更加明顯，由于HLS的相關文件是無狀態的靜態文件，且每個文件的大小是有限的，所以負載均衡、CDN加速的效果更佳明顯，HLS的點播視頻會比mp4、FLV的視頻更快的播放出來，并且在加載中跳轉視頻也會更佳順滑。

3>直播場景

直播的場景下，轉碼軟件可以直接生成HLS相關文件到磁盤，客戶端通過HTTP服務下載文件即可；另外可以在Nginx加入RTMP插件，轉碼軟件以及RTMP協議推流到Nginx，再由Nginx生成HLS相關文件，第2種方案對于前期研發和后期對接直播CND的過度更加順滑。

4>直播的HLS文件

直播場景下的HLS文件與點播有些不同，視頻流數據每幾秒會打包成一個以ts為后綴的碎片視頻文件，每生成一個新的視頻文件都會同步更新m3u8索引文件，且碎片視頻文件的個數是有上限的，當達到上限后，默認將最舊的視頻文件刪除且更新m3u8索引文件所以在直播的場景下，客戶端也需要不斷定時重新獲取m3u8索引文件。

5>HLS協議的優缺點

HLS由于要生成靜態文件，延遲很大5-30s，也可能會有1分鐘延遲。

HLS的直播優勢是ts視頻碎片文件可以一直保留不刪除，不需要花額外的性能保存錄像；直播轉點播、錄播都是更加簡單的，只需要修改m3u8索引文件即可，不需要重新花費性能編解碼。

6>二級索引

m3u8索引文件支持二級索引，就是高清、標清、流暢、等多個觀看地址可以整合到一個索引文件中，播放器可以根據帶寬自動切換不同的觀看地址，很多網頁播放器的“自動”也是因為這個。

7>緩解磁盤壓力

由于HLS協議的視頻文件、索引文件都是直接寫入磁盤的，如果長時間且多個直播流同時處理，會造成磁盤寫入壓力過大，機械磁盤可能出現磁盤損壞，固態硬盤壽命衰減，最好掛載一段內存空間作為HLS相關文件的寫入位置。

掛載一段內存空間作為寫入位置

Linux命令：mount -t tmpfs -o size=10g tmpfs /data

把文件寫入/data，即可寫入內存，而非磁盤

重啟數據會消失，但可以做一些定時保存的措施

6.4 WebRTC

1>WebRTC協議

WebRTC是一種點對點的視頻/語音通話協議，基于UDP，建立通信后，會不斷的以流式發送數據，延遲要比RTMP還要低1s內，再一些交互型較高的直播場景，例如直播帶貨。

2>WebRTC服務器

Webrtc地址一般是webrtc:/開頭的，推流和拉流地址一般也是一樣的，它是點對點的協議，用在直播中需要搭建WebRTC服務器。

例如：一個基于 WebRTC 協議實現多方實時通訊。

6.5 RTSP

RTSP實時流傳輸協議,定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據，一般用在攝像頭、監控等硬件設備的實時視頻流觀看、推送上。

RTSP協議有諸多優點：TCP/UDP切換，支持推流/拉流，支持點播/直播，但是Web領域一般不使用RTSP，現代瀏覽器不支持播放。

7．解碼

7.1 解封裝

Demultiplexing（分離）：將復合音視頻流(容器格式FLV、TS)中的多個單獨的音頻、視頻、字幕或其他媒體流分離出來各自進行解碼的過程。

7.2 音頻編碼框架

FDK-AAC：出色的音頻編解碼器，PCM音頻數據和AAC音頻數據互轉，高音質、低延遲。

7.3 解碼方式對比

特點	硬解碼	軟解碼
原理	利用專用的硬件解碼器（GPU）來解碼視頻數據	使用通用的軟件算法（CPU）來解碼視頻數據
性能	高性能，播放流暢	性能較低，在播放高分辨率、高比特率的視頻時可能出現卡頓
解碼速度	快	慢
資源消耗	CPU占用低	CPU占用較高
兼容性	較差，受硬件平臺限制	較好
適用場景	適用于資源有限的移動設備和嵌入式系統等	適用于處理能力較為強大的計算機或服務器等