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

時間 2019-12-09

標籤漫談直播開始認識快速搭建專屬平臺简体版

原文原文鏈接

autor：賀志兵web

1、直播科普

一、直播是什麼

在以前一篇文章詳細解答過關於視頻的結構，這裏就直接上個思惟導圖。算法

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

二、視頻編碼壓縮

前面講直播，怎麼又忽然講到視頻了呢？簡而言之，視頻和直播息息相關。固然，這也是既定的事實，因此也很少說。那這裏講的編碼壓縮又是什麼呢？採集設備採集一幀圖像會生成無損的**.bmp文件格式的圖片文件，一個6M經過有損壓縮獲得200kb的JPEG文件，壓縮比就是1/30。可是視頻不須要單獨傳輸一張張壓縮圖，只須要記錄每幀之間的差異便可。因而，根據I幀（200K原始圖像）生成差別文件P幀，經過I幀和P幀再生成B幀。這，就是H.264編碼。 windows

如上圖所示，編碼壓縮就像魔術通常，一段視頻，若是通過編碼壓縮後，能夠大幅度的縮小體積。而各類不一樣的壓縮算法就是編碼格式**，現在主流的音視頻編碼格式就是 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的「原子」傳輸。網絡

三、視頻直播的準肯定義

到這裏，咱們終於能夠來嘗試來給直播表述較爲準確的一個定義。框架

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

題外話：GOP越長，所包含的B幀和P幀越多，響應的壓縮比也會更高。 GOP越短，I幀比例增高，壓縮比增長，同碼率下視頻質量會降低。工具

2、常見直播技術梳理

一、直播業務邏輯

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

今天咱們這裏主要講述的主要是前一種，也就是「信號塔」式直播。相比較「舞臺式」互動直播，「信號塔」式直播只要知道發射塔的信號頻率(即頻道號或連接)就能收看它發送的節目，可是並不能很好的去實時交互動。而對於互動直播來講，「舞臺上」的演員能夠不少個，觀衆也可能被邀請到舞臺上面對面交流，因此互動直播的延時會比直播更低，甚至達到了毫秒級（100ms）。固然，互動直播通過旁路轉推也能夠通過「發射塔」播出去，這就是「旁路轉推」功能。

常見直播業務邏輯以下：

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

二、直播技術棧

上圖是一個現在主流的直播泳道，很是直白的表述了從主播端採集視頻到觀看端播放直播的數據流向，下面咱們根據其中主要的幾大模塊一一詳解。

數據採集→數據預處理→數據編碼→數據傳輸(流媒體服務器)→解碼數據→直播播放

一、數據採集（主播端）

採集設備：手機、電腦、攝像機

二、數據預處理

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

三、數據編碼

編碼器主要流程：

上圖爲幀內編碼（I 幀），幀間編碼（P幀）相似。

編碼方式：CBR（靜態碼率）和VBR（動態碼率）視頻編碼格式：H.26五、H.26四、MPEG-4等音頻編碼格式： Opus、G7十一、AAC、Speex、3A等視頻封裝容器：封裝容器有TS、MKV、AVI、MP4等音頻封裝容器：MP三、OGG、AAC等

四、數據傳輸

傳輸協議：

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

五、解碼數據

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

六、數據播放（播放端）

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

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

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

一、推流

推流協議：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形式。