漫談直播：從零開始認識直播並快速搭建專屬直播平臺

雍飛宇發表於2018-12-06

autor：賀志兵

一、直播科普

1、直播是什麼

在之前一篇文章詳細解答過關於視訊的結構，這裡就直接上個思維導圖。

理解視訊的結構有助於我們更好的去理解直播。從本質上講，直播就是一幀幀的資料加上時序標籤流式傳輸。這裡有個悖論：一個容器封裝好後的視訊是“結構化”的，即不可變的，那直播又是怎麼產生的呢？或者說，怎麼去打破這個已經產生的“結果”，從而還往裡面加上時序標籤流式傳輸的呢？很簡單，那就是**“邊生產邊傳輸邊播放”。** 至於如何達到這種效果，我們繼續往下看。

2、視訊編碼壓縮

前面講直播，怎麼又突然講到視訊了呢？簡而言之，視訊和直播息息相關。當然，這也是既定的事實，所以也不多說。那這裡講的編碼壓縮又是什麼呢？採集裝置採集一幀影象會生成無損的**.bmp檔案格式的圖片檔案，一個6M通過有失真壓縮得到200kb的JPEG檔案，壓縮比就是1/30。但是視訊不需要單獨傳輸一張張壓縮圖，只需要記錄每幀之間的差別即可。於是，根據I幀（200K原始影象）生成差異檔案P幀，通過I幀和P幀再生成B幀。這，就是H.264編碼。

如上圖所示，編碼壓縮就像魔術一般，一段視訊，如果經過編碼壓縮後，可以大幅度的縮小體積。而各種不同的壓縮演算法就是編碼格式**，如今主流的音視訊編碼格式就是H.264+AAC，也是各大平臺相容性最好的編碼格式方案。視訊內容經過編碼壓縮大幅度的減少體積後，有利於儲存和壓縮。但是相應的，傳輸時也是被壓縮演算法所“加密”的視訊。所以，在播放端也需要一個“解密”的過程。因此，在編碼和解碼之間，顯然需要一個編碼器和解碼器都可以理解的約定，就影象而言：生產端的編碼器將多張影象進行編碼後生成一段端的GOP（Group of pictures），播放端的解碼器則是讀取一段段的GOP解碼後讀取畫面再渲染顯示。編碼過程如下圖所示：

一個公式： GOP = I(幀內編碼幀) + B（雙向預測幀） + P（前向預測幀） 其中I幀也叫關鍵幀，是一副完整的畫面，而P幀則是記錄I幀的變化（H.264中通過補償演算法根據I幀得到的差異檔案），B幀類似。再簡單點說，如果沒有I幀，P幀和B幀也無法解碼。這也很好理解，沒有原始對比檔案，只有差異檔案是無法渲染畫面的。 GOP結構一般兩個數字，如M=1，N=2。M指定I幀和P幀之間的距離，N指定兩個I幀之間的距離，其他都是B幀填充。如M=1，N=2這裡的例子是IDR PB I排序。有些地方會講IDR幀，其實就是GOP的第一個I幀，這個幀很重要，因為關於首開優化基本上都在去儘可能減小IDR幀的大小。

總結，編碼後的視訊（video） = 一組 GOP 畫面 = 一組 I幀 +B幀 +P幀。

如果用物理學上的概念來比喻，Video就是“物體”， GOP好比“分子”，I/P/B幀的影象就是“原子”。而直播，就是利用video的“原子”傳輸。

3、視訊直播的準確定義

到這裡，我們終於可以來嘗試來給直播表述較為準確的一個定義。

直播就是將每幀資料（Video/Audio/Data Frame），打上時序標籤後進行流式傳輸的過程。傳送端源源不斷的採集音視訊資料，經過編碼、封包、推流，再經過中繼分發網路進行擴散傳播。播放端則源源不斷的下載資料並按時序進行解碼播放。這樣就完成了“邊生產、邊傳輸、邊播放”的直播過程了。 簡而言之，視訊直播技術，就是將視訊內容的最小顆粒（I/P/B幀）,基於時序標籤，以流式傳輸的一種技術。

題外話：GOP越長，所包含的B幀和P幀越多，響應的壓縮比也會更高。 GOP越短，I幀比例增高，壓縮比增加，同位元速率下視訊質量會下降。

二、常見直播技術梳理

1、直播業務邏輯

直播也分為兩種，一種就是直播服務，一種叫互動直播。打個比方，如果直播服務是個訊號發射塔，那互動直播就是個帶舞臺的劇院。

今天我們這裡主要講述的主要是前一種，也就是“訊號塔”式直播。相比較“舞臺式”互動直播，“訊號塔”式直播只要知道發射塔的訊號頻率(即頻道號或連結)就能收看它傳送的節目，但是並不能很好的去實時互動動。而對於互動直播來說，“舞臺上”的演員可以很多個，觀眾也可能被邀請到舞臺上面對面交流，所以互動直播的延時會比直播更低，甚至達到了毫秒級（100ms）。當然，互動直播經過旁路轉推也可以經過“發射塔”播出去，這就是“旁路轉推”功能。

常見直播業務邏輯如下：

推流：指的是把採集階段封包好的內容傳輸到伺服器的過程拉流：即將伺服器封包好的內容拉取到播放端解碼播放的過程

2、直播技術棧

上圖是一個如今主流的直播泳道，非常直白的表述了從主播端採集視訊到觀看端播放直播的資料流向，下面我們根據其中主要的幾大模組一一詳解。

資料採集→資料預處理→資料編碼→資料傳輸(流媒體伺服器)→解碼資料→直播播放

1、資料採集（主播端）

採集裝置：手機、電腦、攝像機

2、資料預處理

涉及功能：美顏、濾鏡涉及技術：SDK內建演算法或第三方特效

3、資料編碼

編碼器主要流程：

上圖為幀內編碼（I 幀），幀間編碼（P幀）類似。

編碼方式：CBR（靜態位元速率）和VBR（動態位元速率）視訊編碼格式：H.265、H.264、MPEG-4等音訊編碼格式： Opus、G711、AAC、Speex、3A等視訊封裝容器：封裝容器有TS、MKV、AVI、MP4等音訊封裝容器：MP3、OGG、AAC等

4、資料傳輸

傳輸協議：

推流：RTSP、RTMP、QUIC
拉流：RTMP、HTTP-FLV、HLS 控制信令：SIP、SDP、SNMP

5、解碼資料

涉及技術：編碼器自帶解碼器

6、資料播放（播放端）

播放渠道：移動端（手機、平板等）、客戶端（PC等）、網頁端（各終端）

三、直播協議的區別以及應用場景

在第二部分，我們已經詳細介紹了直播的流程，其中還簡要的介紹的直播過程中拉流和推流所使用到的協議，下面我們來一一詳解。

1、推流

推流協議：RTMP、RTSP和QUIC 備註：RTSP、RTMP、QUIC協議都在應用層。

RTSP是流媒體協議，主要應用於安防監控，目前絕大多數的攝像頭預設支援RTSP推流。一般傳輸的是 ts、mp4 格式的流。RTSP在體系結構上位於RTP和RTCP之上，它使用TCP或UDP完成資料傳輸。但是實現複雜，各家CDN支援度不高，一般需要將直播流轉碼成CDN支援更好的RTMP。
一般來說，視訊資料由RTP傳輸、視訊質量由RTVP/RTCP控制，視訊建議和控制由RTSP控制。備註：作為點播協議實現倍數播放必須使用到RTSP，因為RTSP是雙向協議。
RTMP也是流媒體協議，屬於Adobe，基於TCP長連結一般傳輸的是 flv，f4v 格式流。優點是延時低，國內CDN廠商都相容。這也是主要的推流方式。但是在瀏覽器中只能使用 Flash 實現播放器。但作為拉流協議時無法支援移動端 Web 播放（手機無法安裝flash）是它的硬傷。
QUIC全稱 quick udp internet connection，即“快速 UDP 網際網路連線”。是谷歌公司制定的一種基於 UDP 協議的低時延網際網路傳輸協議。使用QUIC推流，針對弱網使用者也能夠有很好的使用者體驗。
各大平臺對QUIC都大同小異，而在七牛。主要是將基於TCP的RTMP傳輸改成基於QUIC的RTMP傳輸，即對外暴露的推流地址都是RTMP形式。

2、拉流

有直播推流到流媒體伺服器，那肯定也會有相應的拉流方式。相比較於推流，目前主流的拉流協議有三種：RTMP、HLS、HTTP-FLV。

RTMP拉流：

基於TCP長連線，預設使用埠1935，延時在1-3s左右
Web端依賴flash，H5需要安裝外掛
手機瀏覽器由於flash原因，不能使用RTMP拉流

HLS拉流：

基於HTTP短連線，預設80埠，由蘋果公司創造。
對H5支援較好，但是延時一般在10S以上
可以使用 HTTPS 做加密通道

HTTP-FLV：

基於HTTP長連結，預設80埠，延時在1-3s左右
使用B站開源flv.js可以很好的支援H5，否則也依賴flash
很好的支援移動端（Android，IOS）
可以使用 HTTPS 做加密通道

在支援瀏覽器的協議裡，延遲排序是： HTTP-FLV >= RTMP < HLS 而效能排序恰好相反： RTMP > HTTP-FLV > HLS 就目前主流直播平臺（鬥魚、虎牙、熊貓等）清一色的都是使用HTTP-FLV（主）+RTMP（備）協議。而手機web端（小程式）則大多數使用的HLS協議。

3、開源推拉流軟體推薦

1、推流工具

Windows端：

OBS（Open Broadcaster Software）
Adobe Flash Media Encoder（不再更新）
XSplit推流器
ffmpeg命令列工具

移動端（IOS和Andriod）：

七牛開源SDK

備註：不支援H5推流

2、播放工具

Web端：

七牛雲Web sdk
超酷開源播放軟體

Windows：

七牛windows開源播放器
VLC播放器