1、引言

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

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

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

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

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

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

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

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

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

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

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

這種推拉流方式有幾點(diǎn)優(yōu)勢(shì)：

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

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

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

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

這個(gè)時(shí)候需要引入一個(gè)新的概念——旁路推流。

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

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

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

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

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

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

我們首先在云直播后臺(tái)申請(qǐng)到推流地址和秘鑰，將推流地址和秘鑰配置到OBS軟件當(dāng)中，調(diào)整推流各項(xiàng)參數(shù)，點(diǎn)擊推流以后，OBS就會(huì)通過RTMP協(xié)議向?qū)?yīng)的推流地址推送音視頻流。

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

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

相關(guān)學(xué)習(xí)資料整理、免費(fèi)分享

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

優(yōu)勢(shì)主要是：

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

劣勢(shì)主要是：

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

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

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

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

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

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

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

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

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

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

協(xié)議封裝的時(shí)候通常會(huì)攜帶一些頭部描述信息或者信令數(shù)據(jù)，這一部分?jǐn)?shù)據(jù)對(duì)我們音視頻播放沒有作用，因此我們需要從中提取出具體的音視頻封裝格式數(shù)據(jù)，我們?cè)谥辈ブ谐Ｓ玫膮f(xié)議有HTTP和RTMP兩種。

第二步：解封裝。

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

第三步：解碼音視頻。

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

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

之所以我們能見到如此多的編碼格式，是因?yàn)楦鞣N組織都提出了自己的編碼標(biāo)準(zhǔn)，并且會(huì)相繼推出一些新的議案，但是由于推廣和收費(fèi)問題，目前主流的編碼格式也并不多。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從兼容性角度考慮：HLS > FLV > RTMP，DASH由于一些項(xiàng)目歷史原因，并且定位和HLS重復(fù)了，暫時(shí)沒有對(duì)其兼容性做一個(gè)詳盡的測(cè)試，被推出了選擇的考慮范圍。

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

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

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

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

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

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

13、同層播放如何解決

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

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

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

要解決這個(gè)問題，首先要分多個(gè)場(chǎng)景。

首先在iOS系統(tǒng)中：正常情況下video標(biāo)簽會(huì)自動(dòng)被全屏播放，但iOS10以上已經(jīng)原生提供了video的同層屬性，我們?cè)趘ideo標(biāo)簽上增加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)核會(huì)將video替換成原生定制的播放器已便于增強(qiáng)一些功能。X5也提供了一套同層的方案（該方案官方文檔鏈接已無法打開），給video標(biāo)簽寫入X5同層屬性也可以在X5內(nèi)核中實(shí)現(xiàn)內(nèi)聯(lián)播放。不過X5的同層屬性在各個(gè)X5版本中表現(xiàn)都不太一樣（比如低版本X5中需要使用X5全屏播放模式才能保證MSE播放的視頻同層生效），需要注意區(qū)分版本。

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

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

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

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

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