1、引言

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

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

2、蘑菇街的直播架構(gòu)概覽

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

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

• 1）一是通過集成SDK的方式進行推流（用于手機端開播）；
• 2）另一種是通過rtmp協(xié)議向遠端服務器進行推流（用于PC開播端或?qū)I(yè)控臺設(shè)備開播）。

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

3、推拉流架構(gòu)1：廠商SDK推拉流

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

這種推拉流架構(gòu)的邏輯原理是這樣的：

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

這種推拉流方式有幾點優(yōu)勢：

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

4、推拉流架構(gòu)2：旁路推流

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

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

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

旁路推流指的是：通過協(xié)議轉(zhuǎn)換將音視頻流對接到標準的直播 CDN 系統(tǒng)上。

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

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

5、推拉流架構(gòu)3：RTMP推流

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

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

我們首先在云直播后臺申請到推流地址和秘鑰，將推流地址和秘鑰配置到OBS軟件當中，調(diào)整推流各項參數(shù)，點擊推流以后，OBS就會通過RTMP協(xié)議向?qū)耐屏鞯刂吠扑鸵粢曨l流。

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

總結(jié)下來RTMP推流的優(yōu)勢和劣勢比較明顯。

相關(guān)學習資料整理、免費分享

內(nèi)容包括《Andoird音視頻開發(fā)必備手冊+音視頻最新學習視頻+大廠面試真題+2022最新學習路線圖》（C/C++，Linux，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）等等，點擊自取FFmpegWebRTCRTMPRTSPHLSRTP播放器-音視頻流媒體高級開發(fā)

優(yōu)勢主要是：

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

劣勢主要是：

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

6、高可用架構(gòu)方案：云互備

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

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

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

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

7、視頻直播數(shù)據(jù)流解封裝原理

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

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

第一步：解協(xié)議。

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

第二步：解封裝。

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

第三步：解碼音視頻。

到這里我們已經(jīng)獲取了音視頻的壓縮編碼數(shù)據(jù)。

我們?nèi)粘＝?jīng)常聽到的視頻壓縮編碼數(shù)據(jù)有H.26X系列和MPEG系列等，音頻編碼格式有我們熟悉的MP3、ACC等。

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

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

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

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

8、視頻直播傳輸協(xié)議1：HLS

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

從名字可以明顯看出：這一套協(xié)議是基于HTTP協(xié)議傳輸?shù)?/span>。

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

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

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

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

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

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

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

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

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

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

9、視頻直播傳輸協(xié)議2：HTTP-FLV

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

FLV是Flash Video的簡寫，是一種文件體積小，適合在網(wǎng)絡上傳輸?shù)姆獍绞?。FlV的視頻編碼格式通常是H.264，音頻編碼是ACC或MP3。

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

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

打開文件后可以讀取到16進制的文件流，通過和FLV包結(jié)構(gòu)對比，可以發(fā)現(xiàn)這些數(shù)據(jù)就是我們需要的FLV數(shù)據(jù)。

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

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

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

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

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

10、視頻直播傳輸協(xié)議3：RTMP

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

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

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

RTMP協(xié)議的優(yōu)缺點非常明顯。

RTMP協(xié)議的優(yōu)點主要是：

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

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

11、視頻直播傳輸協(xié)議4：MPEG-DASH

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

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

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

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

12、如何選擇最優(yōu)的視頻直播傳輸協(xié)議

視頻直播協(xié)議選擇非常關(guān)鍵的兩點，在前文都已經(jīng)有提到了，即低延時和更優(yōu)的兼容性。

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

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

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

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

在判斷播放環(huán)境時我們可以參照 [url=%5Burl=https://github.com/bilibili/flv.js%5Dflv.js[/url]]flv.js[/url] 內(nèi)部的判斷方式，通過調(diào)用MSE判斷方法和模擬請求的方式判斷MSE和StreamIO是否可用：

// 判斷MediaSource是否被瀏覽器支持，H.264視頻編碼和Acc音頻編碼是否能夠被支持解碼
window.MediaSource && window.MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E,mp4a.40.2"');

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

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

13、同層播放如何解決

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

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

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

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

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

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

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

? ? ? ? ? ? ? ? ? ? ? ? ? ?

版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權(quán)，不承擔相關(guān)法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 sumchina520@foxmail.com 舉報，一經(jīng)查實，本站將立刻刪除。

加我微信: sumwb886 備注:?外包

免費領(lǐng)推廣引流方案+100種賣貨方法