本文由蘑菇街前端開發工程師“三體”分享，原題“蘑菇街云端直播探索——啟航篇”，有修訂。

1、引言

隨著移動網絡網速的提升與資費的降低，視頻直播作為一個新的娛樂方式已經被越來越多的用戶逐漸接受。特別是最近這幾年，視頻直播已經不僅僅被運用在傳統的秀場、游戲類板塊，更是作為電商的一種新模式得到迅速成長。

本文將通過介紹實時視頻直播技術體系，包括常用的推拉流架構、傳輸協議等，讓你對現今主流的視頻直播技術有一個基本的認知。

學習交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-3922-1-1.html）

2、蘑菇街的直播架構概覽

目前蘑菇街直播推拉流主流程依賴于某云直播的服務。

云直播提供的推流方式有兩種：

• 1）一是通過集成SDK的方式進行推流（用于手機端開播）；
• 2）另一種是通過RTMP協議向遠端服務器進行推流（用于PC開播端或專業控臺設備開播）。

除去推拉流，該云平臺也提供了云通信（IM即時通訊能力）和直播錄制等云服務，組成了一套直播所需要的基礎服務。

3、推拉流架構1：廠商SDK推拉流

如上題所示，這一種推拉流架構方式需要依賴騰訊這類廠商提供的手機互動直播SDK，通過在主播端APP和用戶端APP都集成SDK，使得主播端和用戶端都擁有推拉流的功能。

這種推拉流架構的邏輯原理是這樣的：

• 1）主播端和用戶端分別與云直播的互動直播后臺建立長連接；
• 2）主播端通過UDT私有協議向互動直播后臺推送音視頻流；
• 3）互動直播后臺接收到音視頻流后做轉發，直接下發給與之建立連接的用戶端。

這種推拉流方式有幾點優勢：

• 1）只需要在客戶端中集成SDK：通過手機就可以開播，對于主播開播的要求比較低，適合直播業務快速鋪開；
• 2）互動直播后臺僅做轉發：沒有轉碼，上傳CDN等額外操作，整體延遲比較低；
• 3）主播端和用戶端都可以作為音視頻上傳的發起方：適合連麥、視頻會話等場景。

4、推拉流架構2：旁路推流

之前介紹了通過手機SDK推拉流的直播方式，看起來在手機客戶端中觀看直播的場景已經解決了。

那么問題來了：如果我想要在H5、小程序等其他場景下觀看直播，沒有辦法接入SDK，需要怎么處理呢？

這個時候需要引入一個新的概念——旁路推流。

旁路推流指的是：通過協議轉換將音視頻流對接到標準的直播 CDN 系統上。

目前云直播開啟旁路推流后，會通過互動直播后臺將音視頻流推送到云直播后臺，云直播后臺負責將收到音視頻流轉碼成通用的協議格式并且推送到CDN，這樣H5、小程序等端就可以通過CDN拉取到通用格式的音視頻流進行播放了。

目前蘑菇街直播旁路開啟的協議類型有HLS、FLV、RTMP三種，已經可以覆蓋到所有的播放場景，在后續章節會對這幾種協議做詳細的介紹。

5、推拉流架構3：RTMP推流

隨著直播業務發展，一些主播逐漸不滿足于手機開播的效果，并且電商直播需要高保真地將商品展示在屏幕上，需要通過更加高清專業的設備進行直播，RTMP推流技術應運而生。

我們通過使用OBS等流媒體錄影程序，對專業設備錄制的多路流進行合并，并且將音視頻流上傳到指定的推流地址。由于OBS推流使用了RTMP協議，因此我們稱這一種推流類型為RTMP推流。

我們首先在云直播后臺申請到推流地址和秘鑰，將推流地址和秘鑰配置到OBS軟件當中，調整推流各項參數，點擊推流以后，OBS就會通過RTMP協議向對應的推流地址推送音視頻流。

這一種推流方式和SDK推流的不同之處在于音視頻流是直接被推送到了云直播后臺進行轉碼和上傳CDN的，沒有直接將直播流轉推到用戶端的下行方式，因此相比SDK推流延遲會長一些。

總結下來RTMP推流的優勢和劣勢比較明顯。

優勢主要是：

• 1）可以接入專業的直播攝像頭、麥克風，直播的整體效果明顯優于手機開播；
• 2）OBS已經有比較多成熟的插件，比如目前蘑菇街主播常用YY助手做一些美顏的處理，并且OBS本身已經支持濾鏡、綠幕、多路視頻合成等功能，功能比手機端強大。

劣勢主要是：

• 1）OBS本身配置比較復雜，需要專業設備支持，對主播的要求明顯更高，通常需要一個固定的場地進行直播；
• 2）RTMP需要云端轉碼，并且本地上傳時也會在OBS中配置GOP和緩沖，延時相對較長。

6、高可用架構方案：云互備

業務發展到一定階段后，我們對于業務的穩定性也會有更高的要求，比如當云服務商服務出現問題時，我們沒有備用方案就會出現業務一直等待服務商修復進度的問題。

因此云互備方案就出現了：云互備指的是直播業務同時對接多家云服務商，當一家云服務商出現問題時，快速切換到其他服務商的服務節點，保證業務不受影響。

直播業務中經常遇到服務商的CDN節點下行速度較慢，或者是CDN節點存儲的直播流有問題，此類問題有地域性，很難排查，因此目前做的互備云方案，主要是備份CDN節點。

目前蘑菇街整體的推流流程已經依賴了原有云平臺的服務，因此我們通過在云直播后臺中轉推一路流到備份云平臺上，備份云在接收到了直播流后會對流轉碼并且上傳到備份云自身的CDN系統當中。一旦主平臺CDN節點出現問題，我們可以將下發的拉流地址替換成備份云拉流地址，這樣就可以保證業務快速修復并且觀眾無感知。

7、視頻直播數據流解封裝原理

介紹流協議之前，先要介紹我們從云端拿到一份數據，要經過幾個步驟才能解析出最終需要的音視頻數據。

如上圖所示，總體來說，從獲取到數據到最終將音視頻播放出來要經歷四個步驟。

第一步：解協議。

協議封裝的時候通常會攜帶一些頭部描述信息或者信令數據，這一部分數據對我們音視頻播放沒有作用，因此我們需要從中提取出具體的音視頻封裝格式數據，我們在直播中常用的協議有HTTP和RTMP兩種。

第二步：解封裝。

獲取到封裝格式數據以后需要進行解封裝操作，從中分別提取音頻壓縮流數據和視頻壓縮流數據，封裝格式數據我們平時經常見到的如MP4、AVI，在直播中我們接觸比較多的封裝格式有TS、FLV。

第三步：解碼音視頻。

到這里我們已經獲取了音視頻的壓縮編碼數據。

我們日常經常聽到的視頻壓縮編碼數據有H.26X系列和MPEG系列等，音頻編碼格式有我們熟悉的MP3、ACC等。

之所以我們能見到如此多的編碼格式，是因為各種組織都提出了自己的編碼標準，并且會相繼推出一些新的議案，但是由于推廣和收費問題，目前主流的編碼格式也并不多。

獲取壓縮數據以后接下來需要將音視頻壓縮數據解碼，獲取非壓縮的顏色數據和非壓縮的音頻抽樣數據。顏色數據有我們平時熟知的RGB，不過在視頻的中常用的顏色數據格式是YUV，指的是通過明亮度、色調、飽和度確定一個像素點的色值。音頻抽樣數據通常使用的有PCM。

第四步：音視頻同步播放。

最后我們需要比對音視頻的時間軸，將音視頻解碼后的數據交給顯卡聲卡同步播放。

PS：如果你對上述流程還不太理解，建議進一步閱讀以下系列文章：

《移動端實時音視頻直播技術詳解（一）：開篇》

《移動端實時音視頻直播技術詳解（二）：采集》

《移動端實時音視頻直播技術詳解（三）：處理》

《移動端實時音視頻直播技術詳解（四）：編碼和封裝》

《移動端實時音視頻直播技術詳解（五）：推流和傳輸》

《移動端實時音視頻直播技術詳解（六）：延遲優化》

另外：有關音視頻編解碼技術的文章，也可以詳細學習以下文章：

視頻編解碼之：《理論概述》、《數字視頻介紹》、《編碼基礎》、《預測技術介紹》

《認識主流視頻編碼技術H.264》

《如何開始音頻編解碼技術的學習》

《音頻基礎及編碼原理入門》

《常見的實時語音通訊編碼標準》

《實時視頻編碼H.264的特點與優勢》、《視頻編碼H.264、VP8的前世今生》

《詳解音頻編解碼的原理、演進和應用選型》、《零基礎，史上最通俗視頻編碼技術入門》

8、視頻直播傳輸協議1：HLS

首先介紹一下HLS協議。HLS是HTTP Live Streaming的簡寫，是由蘋果公司提出的流媒體網絡傳輸協議。

從名字可以明顯看出：這一套協議是基于HTTP協議傳輸的。

說到HLS協議：首先需要了解這一種協議是以視頻切片的形式分段播放的，協議中使用的切片視頻格式是TS，也就是我們前文提到的封裝格式。

在我們獲取TS文件之前：協議首先要求請求一個M3U8格式的文件，M3U8是一個描述索引文件，它以一定的格式描述了TS地址的指向，我們根據M3U8文件中描述的內容，就可以獲取每一段TS文件的CDN地址，通過加載TS地址分段播放就可以組合出一整段完整的視頻。

使用HLS協議播放視頻時：首先會請求一個M3U8文件，如果是點播只需要在初始化時獲取一次就可以拿到所有的TS切片指向，但如果是直播的話就需要不停地輪詢M3U8文件，獲取新的TS切片。

獲取到M3U8后：我們可以看一下里面的內容。首先開頭是一些通用描述信息，比如第一個分片序列號、片段最大時長和總時長等，接下來就是具體TS對應的地址列表。如果是直播，那么每次請求M3U8文件里面的TS列表都會隨著最新的直播切片更新，從而達到直播流播放的效果。

HLS這種切片播放的格式在點播播放時是比較適用的，一些大的視頻網站也都有用這一種協議作為播放方案。

首先：切片播放的特性特別適用于點播播放中視頻清晰度、多語種的熱切換。比如我們播放一個視頻，起初選擇的是標清視頻播放，當我們看了一半覺得不夠清晰，需要換成超清的，這時候只需要將標清的M3U8文件替換成超清的M3U8文件，當我們播放到下一個TS節點時，視頻就會自動替換成超清的TS文件，不需要對視頻做重新初始化。

其次：切片播放的形式也可以比較容易地在視頻中插入廣告等內容。

在直播場景下，HLS也是一個比較常用的協議，他最大的優勢是蘋果大佬的加持，對這一套協議推廣的比較好，特別是移動端。將M3U8文件地址喂給video就可以直接播放，PC端用MSE解碼后大部分瀏覽器也都能夠支持。但是由于其分片加載的特性，直播的延遲相對較長。比如我們一個M3U8有5個TS文件，每個TS文件播放時長是2秒，那么一個M3U8文件的播放時長就是10秒，也就是說這個M3U8播放的直播進度至少是10秒之前的，這對于直播場景來說是一個比較大的弊端。

HLS中用到的TS封裝格式，視頻編碼格式是通常是H.264或MPEG-4，音頻編碼格式為AAC或MP3。

一個ts由多個定長的packtet組成，通常是188個字節，每個packtet有head和payload組成，head中包含一些標識符、錯誤信息、包位置等基礎信息。payload可以簡單理解為音視頻信息，但實際上下層還有還有兩層封裝，將封裝解碼后可以獲取到音視頻流的編碼數據。

9、視頻直播傳輸協議2：HTTP-FLV

HTTP-FLV協議，從名字上就可以明顯看出是通過HTTP協議來傳輸FLV封裝格式的一種協議。

FLV是Flash Video的簡寫，是一種文件體積小，適合在網絡上傳輸的封包方式。FlV的視頻編碼格式通常是H.264，音頻編碼是ACC或MP3。

HTTP-FLV在直播中是通過走HTTP長連接的方式，通過分塊傳輸向請求端傳遞FLV封包數據。

在直播中，我們通過HTTP-FLV協議的拉流地址可以拉取到一段chunked數據。

打開文件后可以讀取到16進制的文件流，通過和FLV包結構對比，可以發現這些數據就是我們需要的FLV數據。

首先開頭是頭部信息：464C56轉換ASCII碼后是FLV三個字符，01指的是版本號，05轉換為2進制后第6位和第8位分別代表是否存在音頻和視頻，09代表頭部長度占了幾個字節。

后續就是正式的音視頻數據：是通過一個個的FLV TAG進行封裝，每一個TAG也有頭部信息，標注這個TAG是音頻信息、視頻信息還是腳本信息。我們通過解析TAG就可以分別提取音視頻的壓縮編碼信息。

FLV這一種格式在video中并不是原生支持的，我們要播放這一種格式的封包格式需要通過MSE對影視片的壓縮編碼信息進行解碼，因此需要瀏覽器能夠支持MSE這一API。由于HTTP-FLV的傳輸是通過長連接傳輸文件流的形式，需要瀏覽器支持Stream IO或者fetch，對于瀏覽器的兼容性要求會比較高。

FLV在延遲問題上相比切片播放的HLS會好很多，目前看來FLV的延遲主要是受編碼時設置的GOP長度的影響。

這邊簡單介紹一下GOP：在H.264視頻編碼的過程中，會生成三種幀類型：I幀、B幀和P幀。I幀就是我們通常說的關鍵幀，關鍵幀內包括了完整的幀內信息，可以直接作為其他幀的參考幀。B幀和P幀為了將數據壓縮得更小，需要由其他幀推斷出幀內的信息。因此兩個I幀之間的時長也可以被視作最小的視頻播放片段時長。從視頻推送的穩定性考慮，我們也要求主播將關鍵幀間隔設置為定長，通常是1-3秒，因此除去其他因素，我們的直播在播放時也會產生1-3秒的延時。

10、視頻直播傳輸協議3：RTMP

RTMP協議實際可以與HTTP-FLV協議歸做同一種類型。

他們的封包格式都是FlV，但HTTP-FLV使用的傳輸協議是HTTP，RTMP拉流使用RTMP作為傳輸協議。

RTMP是Adobe公司基于TCP做的一套實時消息傳輸協議，經常與Flash播放器匹配使用。

RTMP協議的優缺點非常明顯。

RTMP協議的優點主要是：

• 1）首先和HTTP-FLV一樣，延遲比較低；
• 2）其次它的穩定性非常好，適合長時間播放（由于播放時借用了Flash player強大的功能，即使開多路流同時播放也能保證頁面不出現卡頓，很適合監控等場景）。

但是Flash player目前在web端屬于墻倒眾人推的境地，主流瀏覽器漸漸都表示不再支持Flash player插件，在MAC上使用能夠立刻將電腦變成燒烤用的鐵板，資源消耗很大。在移動端H5基本屬于完全不支持的狀態，兼容性是它最大的問題。

11、視頻直播傳輸協議4：MPEG-DASH

MPEG-DASH這一協議屬于新興勢力，和HLS一樣，都是通過切片視頻的方式進行播放。

他產生的背景是早期各大公司都自己搞自己的一套協議。比如蘋果搞了HLS、微軟搞了 MSS、Adobe還搞了HDS，這樣使用者需要在多套協議封裝的兼容問題上痛苦不堪。

于是大佬們湊到一起，將之前各個公司的流媒體協議方案做了一個整合，搞了一個新的協議。

由于同為切片視頻播放的協議，DASH優劣勢和HLS類似，可以支持切片之間多視頻碼率、多音軌的切換，比較適合點播業務，在直播中還是會有延時較長的問題。

12、如何選擇最優的視頻直播傳輸協議

視頻直播協議選擇非常關鍵的兩點，在前文都已經有提到了，即低延時和更優的兼容性。

首先從延時角度考慮：不考慮云端轉碼以及上下行的消耗，HLS和MPEG-DASH通過將切片時長減短，延時在10秒左右；RTMP和FLV理論上延時相當，在2-3秒。因此在延時方面HLS ≈ DASH > RTMP ≈ FLV。

從兼容性角度考慮：HLS > FLV > RTMP，DASH由于一些項目歷史原因，并且定位和HLS重復了，暫時沒有對其兼容性做一個詳盡的測試，被推出了選擇的考慮范圍。

綜上所述：我們可以通過動態判斷環境的方式，選擇當前環境下可用的最低延遲的協議。大致的策略就是優先使用HTTP-FLV，使用HLS作為兜底，在一些特殊需求場景下通過手動配置的方式切換為RTMP。

對于HLS和HTTP-FLV：我們可以直接使用?hls.js?和?flv.js?做做解碼播放，這兩個庫內部都是通過MSE做的解碼。首先根據視頻封裝格式提取出對應的音視頻chunk數據，在MediaSource中分別對音頻和視頻創建SourceBuffer，將音視頻的編碼數據喂給SourceBuffer后SourceBuffer內部會處理完剩下的解碼和音視頻對齊工作，最后MediaSource將Video標簽中的src替換成MediaSource 對象進行播放。

在判斷播放環境時我們可以參照flv.js內部的判斷方式，通過調用MSE判斷方法和模擬請求的方式判斷MSE和StreamIO是否可用：

// 判斷MediaSource是否被瀏覽器支持，H.264視頻編碼和Acc音頻編碼是否能夠被支持解碼

window.MediaSource && window.MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E,mp4a.40.2"');

如果FLV播放不被支持的情況下：需要降級到HLS，這時候需要判斷瀏覽器環境是否在移動端，移動端通常不需要?hls.js?通過MSE解碼的方式進行播放，直接將M3U8的地址交給video的src即可。如果是PC端則判斷MSE是否可用，如果可用就使用hls.js解碼播放。

這些判讀可以在自己的邏輯里提前判斷后去拉取對應解碼庫的CDN，而不是等待三方庫加載完成后使用三方庫內部的方法判斷，這樣在選擇解碼庫時就可以不把所有的庫都拉下來，提高加載速度。

13、同層播放如何解決

電商直播需要觀眾操作和互動的部分比起傳統的直播更加多，因此產品設計的時候很多的功能模塊會懸浮在直播視頻上方減少占用的空間。這個時候就會遇到一個移動端播放器的老大難問題——同層播放。

同層播放問題：是指在移動端H5頁面中，一些瀏覽器內核為了提升用戶體驗，將video標簽被劫持替換為native播放器，導致其他元素無法覆蓋于播放器之上。

比如我們想要在直播間播放器上方增加聊天窗口，將聊天窗口通過絕對定位提升z-index置于播放器上方，在PC中測試完全正常。但在移動端的一些瀏覽器中，video被替換成了native播放器，native的元素層級高于我們的普通元素，導致聊天窗口實際顯示的時候在播放器下方。

要解決這個問題，首先要分多個場景。

首先在iOS系統中：正常情況下video標簽會自動被全屏播放，但iOS10以上已經原生提供了video的同層屬性，我們在video標簽上增加playsinline/webkit-playsinline可以解決iOS系統中大部分瀏覽器的同層問題，剩下的低系統版本的瀏覽器以及一些APP內的webview容器（譬如微博），用上面提的屬性并不管用，調用三方庫iphone-inline-video可以解決大部分剩余問題。

在Android端：大部分騰訊系的APP內置的webview容器用的都是X5內核，X5內核會將video替換成原生定制的播放器已便于增強一些功能。X5也提供了一套同層的方案（該方案官方文檔鏈接已無法打開），給video標簽寫入X5同層屬性也可以在X5內核中實現內聯播放。不過X5的同層屬性在各個X5版本中表現都不太一樣（比如低版本X5中需要使用X5全屏播放模式才能保證MSE播放的視頻同層生效），需要注意區分版本。

在蘑菇街App中，目前集成的X5內核版本比較老，在使用MSE的情況下會導致X5同層參數不生效。但如果集成新版本的X5內核，需要對大量的線上頁面做回歸測試，成本比較高，因此提供了一套折中的解決方案。通過在頁面URL中增加一個開關參數，容器讀取到參數以后會將X5內核降級為系統原生的瀏覽器內核，這樣可以在解決瀏覽器視頻同層問題的同時也將內核變動的影響范圍控制在單個頁面當中。

14、相關文章

[1]?移動端實時音視頻直播技術詳解（四）：編碼和封裝

[2]?移動端實時音視頻直播技術詳解（五）：推流和傳輸

[3]?實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享

[4]?淺談開發實時視頻直播平臺的技術要點

[5]?直播系統聊天技術(七)：直播間海量聊天消息的架構設計難點實踐

[6]?從0到1：萬人在線的實時音視頻直播技術實踐分享(視頻+PPT) [附件下載]

[7]?實時視頻編碼H.264的特點與優勢

[8]?視頻編碼H.264、VP8的前世今生

[9]?零基礎，史上最通俗視頻編碼技術入門

[10]?視頻編解碼之編碼基礎

[11]?零基礎入門：實時音視頻技術基礎知識全面盤點

[12]?實時音視頻面視必備：快速掌握11個視頻技術相關的基礎概念

[13]?寫給小白的實時音視頻技術入門提綱

（本文已同步發布于：http://www.52im.net/thread-3922-1-1.html）

總結

以上是生活随笔為你收集整理的视频直播技术分享：一文读懂主流视频直播系统的推拉流架构、传输协议等的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。