本文由蘑菇街前端開發(fā)工程師“三體”分享浆熔，原題“蘑菇街云端直播探索——啟航篇”，有修訂。
1医增、引言
隨著移動網(wǎng)絡(luò)網(wǎng)速的提升與資費的降低慎皱，視頻直播作為一個新的娛樂方式已經(jīng)被越來越多的用戶逐漸接受。特別是最近這幾年叶骨，視頻直播已經(jīng)不僅僅被運用在傳統(tǒng)的秀場茫多、游戲類板塊，更是作為電商的一種新模式得到迅速成長忽刽。
本文將通過介紹實時視頻直播技術(shù)體系天揖，包括常用的推拉流架構(gòu)、傳輸協(xié)議等跪帝，讓你對現(xiàn)今主流的視頻直播技術(shù)有一個基本的認(rèn)知今膊。
（本文已同步發(fā)布于：http://www.52im.net/thread-3922-1-1.html）
2、蘑菇街的直播架構(gòu)概覽
目前蘑菇街直播推拉流主流程依賴于某云直播的服務(wù)伞剑。
云直播提供的推流方式有兩種：
1）一是通過集成SDK的方式進(jìn)行推流（用于手機端開播）斑唬；
2）另一種是通過RTMP協(xié)議向遠(yuǎn)端服務(wù)器進(jìn)行推流（用于PC開播端或?qū)I(yè)控臺設(shè)備開播）。
除去推拉流黎泣，該云平臺也提供了云通信（IM即時通訊能力）和直播錄制等云服務(wù)恕刘，組成了一套直播所需要的基礎(chǔ)服務(wù)。
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è)務(wù)快速鋪開；
2）互動直播后臺僅做轉(zhuǎn)發(fā)：沒有轉(zhuǎn)碼鹊碍，上傳CDN等額外操作厌殉，整體延遲比較低；
3）主播端和用戶端都可以作為音視頻上傳的發(fā)起方：適合連麥侈咕、視頻會話等場景公罕。
4、推拉流架構(gòu)2：旁路推流
之前介紹了通過手機SDK推拉流的直播方式耀销，看起來在手機客戶端中觀看直播的場景已經(jīng)解決了楼眷。
那么問題來了：如果我想要在H5、小程序等其他場景下觀看直播，沒有辦法接入SDK罐柳，需要怎么處理呢掌腰？
這個時候需要引入一個新的概念——旁路推流。
旁路推流指的是：通過協(xié)議轉(zhuǎn)換將音視頻流對接到標(biāo)準(zhǔn)的直播 CDN 系統(tǒng)上张吉。
目前云直播開啟旁路推流后齿梁，會通過互動直播后臺將音視頻流推送到云直播后臺，云直播后臺負(fù)責(zé)將收到音視頻流轉(zhuǎn)碼成通用的協(xié)議格式并且推送到CDN肮蛹，這樣H5勺择、小程序等端就可以通過CDN拉取到通用格式的音視頻流進(jìn)行播放了。
目前蘑菇街直播旁路開啟的協(xié)議類型有HLS蔗崎、FLV酵幕、RTMP三種，已經(jīng)可以覆蓋到所有的播放場景缓苛，在后續(xù)章節(jié)會對這幾種協(xié)議做詳細(xì)的介紹芳撒。
5、推拉流架構(gòu)3：RTMP推流
隨著直播業(yè)務(wù)發(fā)展未桥，一些主播逐漸不滿足于手機開播的效果笔刹，并且電商直播需要高保真地將商品展示在屏幕上，需要通過更加高清專業(yè)的設(shè)備進(jìn)行直播冬耿，RTMP推流技術(shù)應(yīng)運而生舌菜。
我們通過使用OBS等流媒體錄影程序，對專業(yè)設(shè)備錄制的多路流進(jìn)行合并亦镶，并且將音視頻流上傳到指定的推流地址日月。由于OBS推流使用了RTMP協(xié)議，因此我們稱這一種推流類型為RTMP推流缤骨。
我們首先在云直播后臺申請到推流地址和秘鑰爱咬，將推流地址和秘鑰配置到OBS軟件當(dāng)中，調(diào)整推流各項參數(shù)绊起，點擊推流以后精拟，OBS就會通過RTMP協(xié)議向?qū)?yīng)的推流地址推送音視頻流。
這一種推流方式和SDK推流的不同之處在于音視頻流是直接被推送到了云直播后臺進(jìn)行轉(zhuǎn)碼和上傳CDN的虱歪，沒有直接將直播流轉(zhuǎn)推到用戶端的下行方式蜂绎，因此相比SDK推流延遲會長一些。
總結(jié)下來RTMP推流的優(yōu)勢和劣勢比較明顯笋鄙。
優(yōu)勢主要是：
1）可以接入專業(yè)的直播攝像頭师枣、麥克風(fēng)，直播的整體效果明顯優(yōu)于手機開播萧落；
2）OBS已經(jīng)有比較多成熟的插件践美，比如目前蘑菇街主播常用YY助手做一些美顏的處理劳殖，并且OBS本身已經(jīng)支持濾鏡、綠幕拨脉、多路視頻合成等功能，功能比手機端強大宣增。
劣勢主要是：
1）OBS本身配置比較復(fù)雜玫膀，需要專業(yè)設(shè)備支持，對主播的要求明顯更高爹脾，通常需要一個固定的場地進(jìn)行直播帖旨；
2）RTMP需要云端轉(zhuǎn)碼，并且本地上傳時也會在OBS中配置GOP和緩沖灵妨，延時相對較長解阅。
6、高可用架構(gòu)方案：云互備
業(yè)務(wù)發(fā)展到一定階段后泌霍，我們對于業(yè)務(wù)的穩(wěn)定性也會有更高的要求货抄，比如當(dāng)云服務(wù)商服務(wù)出現(xiàn)問題時，我們沒有備用方案就會出現(xiàn)業(yè)務(wù)一直等待服務(wù)商修復(fù)進(jìn)度的問題朱转。
因此云互備方案就出現(xiàn)了：云互備指的是直播業(yè)務(wù)同時對接多家云服務(wù)商蟹地，當(dāng)一家云服務(wù)商出現(xiàn)問題時，快速切換到其他服務(wù)商的服務(wù)節(jié)點藤为，保證業(yè)務(wù)不受影響怪与。
直播業(yè)務(wù)中經(jīng)常遇到服務(wù)商的CDN節(jié)點下行速度較慢，或者是CDN節(jié)點存儲的直播流有問題缅疟，此類問題有地域性分别，很難排查，因此目前做的互備云方案存淫，主要是備份CDN節(jié)點耘斩。
目前蘑菇街整體的推流流程已經(jīng)依賴了原有云平臺的服務(wù)，因此我們通過在云直播后臺中轉(zhuǎn)推一路流到備份云平臺上纫雁，備份云在接收到了直播流后會對流轉(zhuǎn)碼并且上傳到備份云自身的CDN系統(tǒng)當(dāng)中煌往。一旦主平臺CDN節(jié)點出現(xiàn)問題，我們可以將下發(fā)的拉流地址替換成備份云拉流地址轧邪，這樣就可以保證業(yè)務(wù)快速修復(fù)并且觀眾無感知刽脖。
7、視頻直播數(shù)據(jù)流解封裝原理
介紹流協(xié)議之前忌愚，先要介紹我們從云端拿到一份數(shù)據(jù)曲管，要經(jīng)過幾個步驟才能解析出最終需要的音視頻數(shù)據(jù)。
如上圖所示硕糊，總體來說院水，從獲取到數(shù)據(jù)到最終將音視頻播放出來要經(jīng)歷四個步驟腊徙。
第一步：解協(xié)議。
協(xié)議封裝的時候通常會攜帶一些頭部描述信息或者信令數(shù)據(jù)檬某，這一部分?jǐn)?shù)據(jù)對我們音視頻播放沒有作用撬腾，因此我們需要從中提取出具體的音視頻封裝格式數(shù)據(jù)，我們在直播中常用的協(xié)議有HTTP和RTMP兩種恢恼。
第二步：解封裝民傻。
獲取到封裝格式數(shù)據(jù)以后需要進(jìn)行解封裝操作，從中分別提取音頻壓縮流數(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等吴菠。
之所以我們能見到如此多的編碼格式，是因為各種組織都提出了自己的編碼標(biāo)準(zhǔn)浩村，并且會相繼推出一些新的議案做葵，但是由于推廣和收費問題，目前主流的編碼格式也并不多心墅。
獲取壓縮數(shù)據(jù)以后接下來需要將音視頻壓縮數(shù)據(jù)解碼酿矢，獲取非壓縮的顏色數(shù)據(jù)和非壓縮的音頻抽樣數(shù)據(jù)。顏色數(shù)據(jù)有我們平時熟知的RGB怎燥，不過在視頻的中常用的顏色數(shù)據(jù)格式是YUV瘫筐，指的是通過明亮度、色調(diào)铐姚、飽和度確定一個像素點的色值策肝。音頻抽樣數(shù)據(jù)通常使用的有PCM。
第四步：音視頻同步播放隐绵。
最后我們需要比對音視頻的時間軸之众，將音視頻解碼后的數(shù)據(jù)交給顯卡聲卡同步播放。
PS：如果你對上述流程還不太理解依许，建議進(jìn)一步閱讀以下系列文章：
《移動端實時音視頻直播技術(shù)詳解（四）：編碼和封裝》
另外：有關(guān)音視頻編解碼技術(shù)的文章棺禾，也可以詳細(xì)學(xué)習(xí)以下文章：
視頻編解碼之：《理論概述》、《數(shù)字視頻介紹》峭跳、《編碼基礎(chǔ)》膘婶、《預(yù)測技術(shù)介紹》
《如何開始音頻編解碼技術(shù)的學(xué)習(xí)》
《實時視頻編碼H.264的特點與優(yōu)勢》缺前、《視頻編碼H.264、VP8的前世今生》
《詳解音頻編解碼的原理悬襟、演進(jìn)和應(yīng)用選型》衅码、《零基礎(chǔ)，史上最通俗視頻編碼技術(shù)入門》
8脊岳、視頻直播傳輸協(xié)議1：HLS
首先介紹一下HLS協(xié)議肆良。HLS是HTTP Live Streaming的簡寫，是由蘋果公司提出的流媒體網(wǎng)絡(luò)傳輸協(xié)議逸绎。
從名字可以明顯看出：這一套協(xié)議是基于HTTP協(xié)議傳輸?shù)?/b>。
說到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對應(yīng)的地址列表。如果是直播沮尿，那么每次請求M3U8文件里面的TS列表都會隨著最新的直播切片更新丛塌，從而達(dá)到直播流播放的效果。
HLS這種切片播放的格式在點播播放時是比較適用的畜疾，一些大的視頻網(wǎng)站也都有用這一種協(xié)議作為播放方案赴邻。
首先：切片播放的特性特別適用于點播播放中視頻清晰度、多語種的熱切換啡捶。比如我們播放一個視頻乍楚，起初選擇的是標(biāo)清視頻播放，當(dāng)我們看了一半覺得不夠清晰届慈，需要換成超清的徒溪，這時候只需要將標(biāo)清的M3U8文件替換成超清的M3U8文件忿偷，當(dāng)我們播放到下一個TS節(jié)點時，視頻就會自動替換成超清的TS文件臊泌，不需要對視頻做重新初始化鲤桥。
其次：切片播放的形式也可以比較容易地在視頻中插入廣告等內(nèi)容。
在直播場景下渠概，HLS也是一個比較常用的協(xié)議茶凳，他最大的優(yōu)勢是蘋果大佬的加持，對這一套協(xié)議推廣的比較好播揪，特別是移動端贮喧。將M3U8文件地址喂給video就可以直接播放，PC端用MSE解碼后大部分瀏覽器也都能夠支持猪狈。但是由于其分片加載的特性箱沦，直播的延遲相對較長。比如我們一個M3U8有5個TS文件雇庙，每個TS文件播放時長是2秒谓形，那么一個M3U8文件的播放時長就是10秒，也就是說這個M3U8播放的直播進(jìn)度至少是10秒之前的疆前，這對于直播場景來說是一個比較大的弊端寒跳。
HLS中用到的TS封裝格式，視頻編碼格式是通常是H.264或MPEG-4竹椒，音頻編碼格式為AAC或MP3童太。
一個ts由多個定長的packtet組成，通常是188個字節(jié)胸完，每個packtet有head和payload組成康愤，head中包含一些標(biāo)識符、錯誤信息舶吗、包位置等基礎(chǔ)信息征冷。payload可以簡單理解為音視頻信息，但實際上下層還有還有兩層封裝誓琼，將封裝解碼后可以獲取到音視頻流的編碼數(shù)據(jù)检激。
9、視頻直播傳輸協(xié)議2：HTTP-FLV
HTTP-FLV協(xié)議腹侣，從名字上就可以明顯看出是通過HTTP協(xié)議來傳輸FLV封裝格式的一種協(xié)議叔收。
FLV是Flash Video的簡寫，是一種文件體積小傲隶，適合在網(wǎng)絡(luò)上傳輸?shù)姆獍绞浇嚷伞lV的視頻編碼格式通常是H.264，音頻編碼是ACC或MP3跺株。
HTTP-FLV在直播中是通過走HTTP長連接的方式复濒，通過分塊傳輸向請求端傳遞FLV封包數(shù)據(jù)脖卖。
在直播中，我們通過HTTP-FLV協(xié)議的拉流地址可以拉取到一段chunked數(shù)據(jù)巧颈。
打開文件后可以讀取到16進(jìn)制的文件流畦木，通過和FLV包結(jié)構(gòu)對比，可以發(fā)現(xiàn)這些數(shù)據(jù)就是我們需要的FLV數(shù)據(jù)砸泛。
首先開頭是頭部信息：464C56轉(zhuǎn)換ASCII碼后是FLV三個字符十籍，01指的是版本號，05轉(zhuǎn)換為2進(jìn)制后第6位和第8位分別代表是否存在音頻和視頻唇礁，09代表頭部長度占了幾個字節(jié)勾栗。
后續(xù)就是正式的音視頻數(shù)據(jù)：是通過一個個的FLV TAG進(jìn)行封裝，每一個TAG也有頭部信息盏筐，標(biāo)注這個TAG是音頻信息围俘、視頻信息還是腳本信息。我們通過解析TAG就可以分別提取音視頻的壓縮編碼信息机断。
FLV這一種格式在video中并不是原生支持的，我們要播放這一種格式的封包格式需要通過MSE對影視片的壓縮編碼信息進(jìn)行解碼绣夺，因此需要瀏覽器能夠支持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一樣心俗，都是通過切片視頻的方式進(jìn)行播放傲武。
他產(chǎn)生的背景是早期各大公司都自己搞自己的一套協(xié)議。比如蘋果搞了HLS城榛、微軟搞了 MSS揪利、Adobe還搞了HDS，這樣使用者需要在多套協(xié)議封裝的兼容問題上痛苦不堪狠持。
于是大佬們湊到一起疟位，將之前各個公司的流媒體協(xié)議方案做了一個整合，搞了一個新的協(xié)議喘垂。
由于同為切片視頻播放的協(xié)議献汗，DASH優(yōu)劣勢和HLS類似，可以支持切片之間多視頻碼率王污、多音軌的切換罢吃，比較適合點播業(yè)務(wù)，在直播中還是會有延時較長的問題昭齐。
12尿招、如何選擇最優(yōu)的視頻直播傳輸協(xié)議
視頻直播協(xié)議選擇非常關(guān)鍵的兩點，在前文都已經(jīng)有提到了，即低延時和更優(yōu)的兼容性就谜。
首先從延時角度考慮：不考慮云端轉(zhuǎn)碼以及上下行的消耗怪蔑，HLS和MPEG-DASH通過將切片時長減短，延時在10秒左右丧荐；RTMP和FLV理論上延時相當(dāng)缆瓣，在2-3秒。因此在延時方面HLS ≈ DASH > RTMP ≈ FLV虹统。
從兼容性角度考慮：HLS > FLV > RTMP弓坞，DASH由于一些項目歷史原因，并且定位和HLS重復(fù)了，暫時沒有對其兼容性做一個詳盡的測試，被推出了選擇的考慮范圍蹦漠。
綜上所述：我們可以通過動態(tài)判斷環(huán)境的方式，選擇當(dāng)前環(huán)境下可用的最低延遲的協(xié)議碱茁。大致的策略就是優(yōu)先使用HTTP-FLV，使用HLS作為兜底，在一些特殊需求場景下通過手動配置的方式切換為RTMP。
對于HLS和HTTP-FLV：我們可以直接使用?hls.js?和?flv.js?做做解碼播放超歌，這兩個庫內(nèi)部都是通過MSE做的解碼。首先根據(jù)視頻封裝格式提取出對應(yīng)的音視頻chunk數(shù)據(jù)蒂教，在MediaSource中分別對音頻和視頻創(chuàng)建SourceBuffer巍举，將音視頻的編碼數(shù)據(jù)喂給SourceBuffer后SourceBuffer內(nèi)部會處理完剩下的解碼和音視頻對齊工作，最后MediaSource將Video標(biāo)簽中的src替換成MediaSource 對象進(jìn)行播放悴品。
在判斷播放環(huán)境時我們可以參照flv.js內(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解碼的方式進(jìn)行播放孤澎，直接將M3U8的地址交給video的src即可届氢。如果是PC端則判斷MSE是否可用，如果可用就使用hls.js解碼播放覆旭。
這些判讀可以在自己的邏輯里提前判斷后去拉取對應(yīng)解碼庫的CDN退子，而不是等待三方庫加載完成后使用三方庫內(nèi)部的方法判斷，這樣在選擇解碼庫時就可以不把所有的庫都拉下來型将，提高加載速度寂祥。
13、同層播放如何解決
電商直播需要觀眾操作和互動的部分比起傳統(tǒng)的直播更加多七兜，因此產(chǎn)品設(shè)計的時候很多的功能模塊會懸浮在直播視頻上方減少占用的空間丸凭。這個時候就會遇到一個移動端播放器的老大難問題——同層播放。
同層播放問題：是指在移動端H5頁面中，一些瀏覽器內(nèi)核為了提升用戶體驗惜犀，將video標(biāo)簽被劫持替換為native播放器铛碑，導(dǎo)致其他元素?zé)o法覆蓋于播放器之上。
比如我們想要在直播間播放器上方增加聊天窗口虽界，將聊天窗口通過絕對定位提升z-index置于播放器上方汽烦，在PC中測試完全正常。但在移動端的一些瀏覽器中莉御，video被替換成了native播放器撇吞，native的元素層級高于我們的普通元素，導(dǎo)致聊天窗口實際顯示的時候在播放器下方颈将。
要解決這個問題梢夯，首先要分多個場景。
首先在iOS系統(tǒng)中：正常情況下video標(biāo)簽會自動被全屏播放晴圾，但iOS10以上已經(jīng)原生提供了video的同層屬性颂砸，我們在video標(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)核會將video替換成原生定制的播放器已便于增強一些功能色罚。X5也提供了一套同層的方案（該方案官方文檔鏈接已無法打開），給video標(biāo)簽寫入X5同層屬性也可以在X5內(nèi)核中實現(xiàn)內(nèi)聯(lián)播放账劲。不過X5的同層屬性在各個X5版本中表現(xiàn)都不太一樣（比如低版本X5中需要使用X5全屏播放模式才能保證MSE播放的視頻同層生效）戳护，需要注意區(qū)分版本。
在蘑菇街App中瀑焦，目前集成的X5內(nèi)核版本比較老腌且，在使用MSE的情況下會導(dǎo)致X5同層參數(shù)不生效。但如果集成新版本的X5內(nèi)核榛瓮，需要對大量的線上頁面做回歸測試铺董，成本比較高，因此提供了一套折中的解決方案禀晓。通過在頁面URL中增加一個開關(guān)參數(shù)精续，容器讀取到參數(shù)以后會將X5內(nèi)核降級為系統(tǒng)原生的瀏覽器內(nèi)核，這樣可以在解決瀏覽器視頻同層問題的同時也將內(nèi)核變動的影響范圍控制在單個頁面當(dāng)中粹懒。
14重付、相關(guān)文章
[1]?移動端實時音視頻直播技術(shù)詳解（四）：編碼和封裝
[2]?移動端實時音視頻直播技術(shù)詳解（五）：推流和傳輸
[3]?實現(xiàn)延遲低于500毫秒的1080P實時音視頻直播的實踐分享
[4]?淺談開發(fā)實時視頻直播平臺的技術(shù)要點
[5]?直播系統(tǒng)聊天技術(shù)(七)：直播間海量聊天消息的架構(gòu)設(shè)計難點實踐
[6]?從0到1：萬人在線的實時音視頻直播技術(shù)實踐分享(視頻+PPT) [附件下載]
[9]?零基礎(chǔ)凫乖，史上最通俗視頻編碼技術(shù)入門
[10]?視頻編解碼之編碼基礎(chǔ)
[11]?零基礎(chǔ)入門：實時音視頻技術(shù)基礎(chǔ)知識全面盤點
[12]?實時音視頻面視必備：快速掌握11個視頻技術(shù)相關(guān)的基礎(chǔ)概念
（本文已同步發(fā)布于：http://www.52im.net/thread-3922-1-1.html）
