本文來自熊貓TV音視頻技術(shù)專家姜雨晴在LiveVideoStackCon 2017上的分享，并有LiveVideoStack整理成文。當(dāng)下，打造一款播放器已經(jīng)有比較好的開源實(shí)現(xiàn)，但熊貓TV為什么還要自研一款H5播放器呢？為了保證業(yè)務(wù)持續(xù)擴(kuò)展能力，需要對(duì)播放器做解耦。同時(shí)，在播放器上線初期還遇到了音畫不同步、故障定位、客戶端性能不足等問題。

文 / 姜雨晴

整理 / LiveVideoStack

大家知道HTML5播放器曾被廣泛運(yùn)用于視頻點(diǎn)播，而今天我想與大家分享的是運(yùn)用在直播領(lǐng)域的HTML5播放器?，F(xiàn)在熊貓已不再使用FLVJS作為播放器了，所以今天與大家探討一下直播HTML5播放器的技術(shù)難點(diǎn)與架構(gòu)探索。

我來自熊貓直播，從去年的7月份加入熊貓并在 11月中旬開始開發(fā)播放器，主要致力于HTML5播放器的研制開發(fā)。

接下來我將從以下幾個(gè)方面介紹HTML5播放器的相關(guān)內(nèi)容：

1. HTML5播放器產(chǎn)生背景

首先讓我們來看看HTML5播放的產(chǎn)生背景，

通過最近的一些新聞大家可以看到，包括谷歌的Chrome還有Adobe這樣的公司都在強(qiáng)調(diào)其產(chǎn)品不再專注Flash轉(zhuǎn)而更關(guān)注HTML5。在這樣一個(gè)后Flash時(shí)代，我們必須要有自己的新技術(shù)來支撐視頻播放，尤其是視頻直播的需求。

作為熊貓直播最重要的用戶之一，熊貓直播的老板王思聰之前提出H5播放器的開發(fā)需求，那么H5播放器具有哪些優(yōu)勢呢？

(1)高效性

第一點(diǎn)是高效性。我們需要明確Video標(biāo)簽為瀏覽器帶來的是什么？其實(shí)是在背后把H264的Codec打進(jìn)了瀏覽器，無需內(nèi)嵌應(yīng)用而是利用瀏覽器Codec進(jìn)行視頻解碼。

(2)兼容性

第二點(diǎn)是兼容性。之前我們遇見了很多非同尋常的案例與需求，包括將HTML5播放器技術(shù)運(yùn)用于電視直播或游戲主機(jī)，這其實(shí)是反映了H5解決方案的良好兼容性。這種兼容性體現(xiàn)在一次開發(fā)后可以在多個(gè)不同平臺(tái)應(yīng)用，降低開發(fā)成本。

(3)瀏覽器新技術(shù)

第三點(diǎn)是快速接入瀏覽器新技術(shù)。例如大家或多或少聽說過的流媒體加密的瀏覽器新接口Encrypted ?Media ?Extensions，還有 WebRTC、VP9、AV1、H.265等新技術(shù)，通過使用HTML5可以將這些新技術(shù)快速接入瀏覽器中。例如最新版本的Chrome瀏覽器便打入了H.265的Codec。相對(duì)于Flash播放器， HTML5可更便捷快速地引入新技術(shù)。

當(dāng)然，HTML5播放器的開發(fā)過程并不是一帆風(fēng)順的。

2. 直播領(lǐng)域H5播放器的問題

我們之前從未嘗試過將H5播放器技術(shù)運(yùn)用于視頻直播領(lǐng)域，因此在開發(fā)初期我們遇到了很多棘手的問題。2016年12月份上線的第一版便出現(xiàn)音畫不同步、碼率過高、播放器崩潰、瀏覽器崩潰、延遲高等問題。

我們團(tuán)隊(duì)曾經(jīng)將這些問題集中并研究解決方案，下面我將會(huì)選其中幾個(gè)比較具有代表性的問題進(jìn)行詳細(xì)闡述。

2.1 音畫不同步

音畫不同步的問題困擾了許久，很多開發(fā)者問到相關(guān)的問題，下面就是我們對(duì)于問題的定位與解決思路。

初期我們?cè)谟^察來自內(nèi)核的視頻時(shí)會(huì)發(fā)現(xiàn)主播口型與聲音無法準(zhǔn)確同步，延遲可達(dá)到兩三秒。這對(duì)用戶而言是一場糟糕的體驗(yàn)，那么究竟為什么會(huì)出現(xiàn)音畫不同步的問題呢？

1) 問題定位

我們發(fā)現(xiàn)，戶外直播是發(fā)生音畫不同步問題最為頻繁的版區(qū)。第一個(gè)原因是戶外主播手機(jī)性能及網(wǎng)絡(luò)問題導(dǎo)致上行數(shù)據(jù)掉幀頻發(fā)；第二個(gè)原因是音頻和視頻的掉幀時(shí)間長度存在差異；第三個(gè)原因是播放端音視頻實(shí)際播放時(shí)長不一致導(dǎo)致音畫不同步。

上圖為問題示意圖。灰色框?yàn)橐曨l幀組成的視頻流，紅色框?yàn)橐纛l幀組成的音頻流，理想狀態(tài)下的視頻流與音頻流應(yīng)當(dāng)是長度一致。其中虛線框表示幀片丟失的狀態(tài)，例如現(xiàn)在視頻流丟了3片，音頻流丟了1片，此時(shí)實(shí)際傳輸?shù)囊粢曨l為上圖，但實(shí)際播放的音視頻為下圖：

但看著一小段音視頻流，兩三幀的差異似乎不是特別明顯；一旦累計(jì)時(shí)間過長，視頻流與音頻流之間的時(shí)間差異越來越大，音畫不同步的現(xiàn)象也就會(huì)越來越明顯。相信現(xiàn)在使用FLVJS做視頻直播的朋友也都會(huì)遇到這樣一個(gè)問題：音畫不同步的現(xiàn)象隨時(shí)間的增長越來越顯著，那么如何改進(jìn)技術(shù)消除這個(gè)問題呢？

2) 解決方案

上圖是影視動(dòng)畫后期制作時(shí)使用Au將配音員配音人聲與視頻畫面做對(duì)接的處理過程。當(dāng)出現(xiàn)音畫不同步的現(xiàn)象時(shí)最常用的處理方案是調(diào)整軌道相對(duì)位置，再添加特效使得音畫自然同步。

視頻直播中出現(xiàn)音畫不同步時(shí)可以運(yùn)用類似方法進(jìn)行處理，我們稱為抽幀處理。當(dāng)然抽幀后需要進(jìn)行音頻補(bǔ)幀處理。

在這里大家一定會(huì)有疑問，后期補(bǔ)進(jìn)去的音頻幀并不是原生的，那么應(yīng)該補(bǔ)進(jìn)去什么幀呢？為了讓大家比較清晰地理解這個(gè)問題，也我們使用配音中的原理進(jìn)行解釋。

演員配音時(shí)，因?yàn)檠輪T說每個(gè)字時(shí)發(fā)聲的頻率不同，聲音聽上去也會(huì)不同。如果每個(gè)字的不同頻率切換得比較平滑便不會(huì)出現(xiàn)“嘶啦”的聲音也就是“過電”現(xiàn)象；但如果是補(bǔ)一個(gè)空白幀，便會(huì)出現(xiàn)這樣的現(xiàn)象，此時(shí)人耳會(huì)聽到短暫的電流雜音，體驗(yàn)很不好；尤其是當(dāng)直播頻繁掉幀時(shí)用戶會(huì)感覺到明顯的電流雜音。

所以我們?nèi)∏耙粠M(jìn)行音頻補(bǔ)幀，較好避免了過電現(xiàn)象的發(fā)生。

3）改進(jìn)效果

通過上述播放器對(duì)軌與補(bǔ)幀處理可以在掉幀頻繁時(shí)明顯降低音畫不同步帶來的對(duì)直播視頻觀看的影響。

2.2 碼率問題

1) 問題定位

相信大家無論是使用Flash還是在H5播放器都曾遇見正在播放時(shí)突然彈框顯示“頁面已崩潰”的問題。這是為什么？因?yàn)闉g覽器會(huì)限制網(wǎng)頁占用運(yùn)行內(nèi)存。普通的無音視頻流的網(wǎng)頁，除非代碼出現(xiàn)嚴(yán)重的Bug否則不會(huì)占用過高的運(yùn)行內(nèi)存；但如果網(wǎng)頁中有播放器的運(yùn)行便很容易使瀏覽器處于一個(gè)高內(nèi)存占用運(yùn)行狀態(tài)，一旦達(dá)到運(yùn)行內(nèi)存上限便會(huì)使得網(wǎng)頁崩潰。

上圖是藍(lán)光直播上線第一天的反饋情況，可以看到大家反饋的信息，無論是選手毛孔還是主播妝容都是纖毫畢現(xiàn)。

上圖是6000kbps的高清的直播，可以清晰看到主播面部的細(xì)節(jié)。對(duì)熊貓來說，高清直播是一座里程碑，也是我們產(chǎn)品的一個(gè)賣點(diǎn)。我們不可能用3000kbps的冒充藍(lán)光線路，所以在這種大型活動(dòng)熊貓基本上都維持在一個(gè)6000到8000kbps推流碼率下的高清直播。

而對(duì)于普通主播而言高碼率采集同樣重要。上圖是根據(jù)某天下午幾個(gè)FPS主播們的直播房間統(tǒng)計(jì)出來的結(jié)果，可以看到很多主播都將碼率采樣推到6000以上，對(duì)此主播們也是樂此不疲，這是為什么？

這是我自己喜歡的幾位主播平時(shí)的推流規(guī)律。其中有一個(gè)最高需要推到一萬四的碼率，這樣一個(gè)高碼率對(duì)熊貓來講可以說是非常普遍的。我們需要保證頁面不崩潰的同時(shí)維持這樣一個(gè)高碼率的推流，可以說難度不小。

這是FPS游戲《絕地求生》的直播畫面?？梢钥吹接螒蛑袑?duì)手距離非常遠(yuǎn)，有的時(shí)候在畫面中就是一個(gè)小黑點(diǎn)。像這樣的FPS游戲一旦推至很高的碼率便會(huì)大大降低用戶體驗(yàn)。因?yàn)闀?huì)帶來明顯的卡頓，包括主播也對(duì)這一點(diǎn)心知肚明。一般情況下如果出現(xiàn)卡頓的問題主播會(huì)給出“換線路板”、“調(diào)清晰度”等提示語。但無論如何我們需要支持主播的高碼率直播需求，那么如何解決？

2) 解決方案

如果你打開熊貓HTML5播放器并右鍵點(diǎn)擊打開監(jiān)控，會(huì)看到顯示“正在清洗能量槽”，很多人問我什么是正在清洗能量槽？其實(shí)是正在清理緩存的意思。這個(gè)功能的實(shí)現(xiàn)其實(shí)只需要幾行代碼，但背后會(huì)遇到了什么問題呢？

a.什么時(shí)候清洗

做前端的同學(xué)應(yīng)該知道這個(gè)Setinterval。當(dāng)Setinterval或新的GOP準(zhǔn)備好時(shí)會(huì)觸發(fā)清洗能量槽的功能。

b.一次清洗多少

先說Setinterval和新GOP。 Setinterval解決方式有優(yōu)點(diǎn)與缺點(diǎn)，其問題在于此定時(shí)器在頁面掛起的狀態(tài)下并非按照設(shè)置的時(shí)間運(yùn)行，而只是把這一段代碼推至站并等待運(yùn)行；此時(shí)如果超過時(shí)間而又在休眠狀態(tài)便失去作用。而新GOP會(huì)過于頻繁, 干擾系統(tǒng)正常運(yùn)行，因此最后我們選擇Setinterval解決方式。那么關(guān)于清理多少，我們暫時(shí)是確定10秒以前的全部清洗。

c.容易洗出什么問題

BufferUpdating是MSE的Buffer的一個(gè)狀態(tài)。在新的GOP準(zhǔn)備好時(shí)這是一個(gè)寫操作，此時(shí)一定會(huì)存在這樣一個(gè)無法清理的狀態(tài)，這也是我們沒有用新GOP的原因。

3) 改進(jìn)效果

下面來看一下我們內(nèi)存控制的效果，這是我們新版內(nèi)核與老版內(nèi)核的對(duì)比，請(qǐng)注意內(nèi)存的變化。

在同樣的測試環(huán)境下，上面的標(biāo)簽頁是我們使用老版內(nèi)核得出的占用內(nèi)存值為285736k，下面的標(biāo)簽頁是我們使用新版內(nèi)核得出的占用內(nèi)存值為75632k，大概是老板內(nèi)核內(nèi)存占用的1/4。

2.3 累計(jì)延時(shí)問題

CDN的同事應(yīng)該知道累計(jì)延時(shí)也是一個(gè)困擾大家很久的問題。上圖是我自己直播間的一個(gè)界面，左半圖右側(cè)是老版內(nèi)核的，左側(cè)是新版內(nèi)核，右半圖是我在新版內(nèi)核網(wǎng)站刷新出的的一個(gè)狀態(tài)，最左邊的和最右邊我都是已經(jīng)放置了一段比較長的時(shí)間。先對(duì)比來看時(shí)間戳，老版內(nèi)核頁面與剛刷新完的頁面相比存在大概4分鐘的延遲，這4分鐘的延遲可以說為觀影體驗(yàn)帶來的影響是毀滅性的。

1) 問題定位

延遲問題與碼率有關(guān)。當(dāng)下行網(wǎng)速小于平均碼率時(shí)便會(huì)出現(xiàn)這種視頻卡頓的現(xiàn)象。瀏覽器的Video標(biāo)簽是針對(duì)點(diǎn)播設(shè)計(jì)的，出現(xiàn)卡頓后一定是從卡頓點(diǎn)開始繼續(xù)播放，這種小規(guī)模無法被輕易感知的卡頓累計(jì)多了便會(huì)造成明顯的延遲，那我們?cè)撊绾翁幚砟?#xff1f;

2) 解決方案

這一部分是我們寫的一個(gè)重新拉流，處理方法為網(wǎng)絡(luò)抖動(dòng)。如果使用網(wǎng)絡(luò)抖動(dòng)而后面網(wǎng)絡(luò)又平滑了該怎么辦？此時(shí)需要看最后一幀是否滿足需求，如果不滿足就重新拉流并重新計(jì)算起始時(shí)間；然后將始終時(shí)間和當(dāng)天時(shí)間作差，得出實(shí)際播出的時(shí)間以及實(shí)際消耗的時(shí)間，便是累計(jì)延時(shí)的時(shí)長。若大于一定閾值便會(huì)觸發(fā)重新拉流的操作，當(dāng)然這個(gè)閥值可根據(jù)應(yīng)用環(huán)境進(jìn)行修改，這里我設(shè)定的是15秒。

3) 改進(jìn)效果

以上是在弱網(wǎng)環(huán)境下的測試結(jié)果。大家可以看到如果在放置比較久的情況下會(huì)產(chǎn)生一定的累計(jì)延遲，大概為3秒。但這種體驗(yàn)已經(jīng)比之前好很多了，可以基本保證同步。

3. 熊貓HTML5播放器內(nèi)核架構(gòu)

3.1 明確問題

在整個(gè)開發(fā)過程中我們遇到了以下的一些問題使得我們將內(nèi)核進(jìn)行重新架構(gòu)。

1) 不同業(yè)務(wù)

不同業(yè)務(wù)對(duì)播放器內(nèi)核的需求是不一樣的。雖然這是個(gè)外層問題，但當(dāng)我們?cè)偃テ饰鰰r(shí)會(huì)發(fā)現(xiàn)，其實(shí)針對(duì)不同需求的不同業(yè)務(wù)下所需要的內(nèi)核也不太一樣。這個(gè)時(shí)候該怎么辦呢？當(dāng)然不可能將所有的業(yè)務(wù)都寫在內(nèi)核里，一個(gè)業(yè)務(wù)對(duì)應(yīng)一個(gè)內(nèi)核會(huì)帶來龐大的開發(fā)體量。

2) 新技術(shù)接入

大家可以看到熊貓之前有十個(gè)多月處于Bata階段。為什么我們一直沒有發(fā)布正式版？因?yàn)槲覀兿朐诓シ牌鳟?dāng)中接入一些新技術(shù)。而每次新技術(shù)的接入就需要改變包中代碼，可想而知其有多么不穩(wěn)定。

3) 團(tuán)隊(duì)新人加入

我們團(tuán)隊(duì)會(huì)遇到的一個(gè)很正常的問題就是當(dāng)有新人加入該怎么辦？新人一開始不熟悉開發(fā)過程，在開發(fā)過程中有時(shí)對(duì)內(nèi)核造成不必要的影響。

3.2 構(gòu)架特征

我們對(duì)于新版內(nèi)核的要求就是——“高度解耦”、“模塊化”、“易擴(kuò)展”，也就是下面我們重構(gòu)的架構(gòu)。

1) Modules層

大家可以看到在Modules層是由Loader模塊、Demuxer模塊、Remuxer模塊與Build Packages模塊組成，每個(gè)模塊都有一些自己的插件。講到這里，大家可能會(huì)想到一些以前的庫，包括HLSJS、FLAVJS等都大概有這樣的一個(gè)架構(gòu)，那么我們?cè)贛ccree Core層做了哪些工作？

2) Mccree Core層

首先我們?cè)O(shè)置了一個(gè)消息通道Message Channal，其作用是當(dāng)有模塊要完成某些任務(wù)時(shí)會(huì)通知給下一個(gè)模塊，然后會(huì)把數(shù)據(jù)給到緩沖區(qū)。

這個(gè)消息通道采用廣播模式，任何一個(gè)模塊在得到對(duì)應(yīng)的消息時(shí)會(huì)觸發(fā)對(duì)應(yīng)功能。

3) 底層

底層的數(shù)據(jù)結(jié)構(gòu)分為Loader Buffer、Tracks與Remuxed Buffer，分別用來放置原始的流數(shù)據(jù)、Demuxer后的數(shù)據(jù)與Demuxer前的數(shù)據(jù)，并提供給MICE。其中MICE是一個(gè)插件，其他的幾個(gè)部分是我們的核心模塊?？赡艽蠹覄傞_始看到這個(gè)構(gòu)架有些復(fù)雜，接下來我會(huì)向大家介紹這些模塊是如何工作的。

3.3 模塊、插件與封裝

注冊(cè)、調(diào)用、銷毀的流程會(huì)經(jīng)常在工程化中被用到。那么在我們的Mccree Core中模塊是如何被接入的？

首先初始化模塊，接下來進(jìn)行模塊調(diào)用；這一步比較簡單的是調(diào)用標(biāo)準(zhǔn)接口也就是Loader加載數(shù)據(jù)；最后在我不用的時(shí)候進(jìn)行銷毀。需要注意的是這里的Unload也是一個(gè)標(biāo)準(zhǔn)接口， Unload是promise，如果有人想比著這個(gè)東西去改FLVJS，可以把改掉，因?yàn)檫@個(gè)是個(gè)promise，泛指是個(gè)promise，其他的也都必須做成一個(gè)promise才能兼容這樣的一個(gè)接口。

這是我們一個(gè)具體的數(shù)據(jù)傳輸方式。首先是向緩存中填充數(shù)據(jù)，再通過消息通道通知下一個(gè)模塊獲取數(shù)據(jù)；之后會(huì)給出獲取數(shù)據(jù)的長度，否則下一塊模塊無法確定獲取數(shù)據(jù)量；接下來收到這些消息后下一模塊從緩存中提取數(shù)據(jù)。大家都知道FLV的視頻Header等于13位，就是以上的一段代碼，大家可以在開源庫上看到這段代碼，我就不再贅述了。

3.4 工程管理

這個(gè)較為復(fù)雜的流程本身會(huì)有一些工程管理上的麻煩：

1)?工程體積大，模塊多

解決方案：多包管理系統(tǒng)

我們現(xiàn)在使用Lerna package管理系統(tǒng)，我想做前端的同學(xué)應(yīng)該了解這是Babel的多包管理工具。

2)?參與開發(fā)復(fù)性工作多

解決方案：完整的開發(fā)套件

當(dāng)你第一次布局這套環(huán)境時(shí)會(huì)發(fā)現(xiàn)需要一個(gè)個(gè)裝所有的庫，還要做Lerna Bootstrap的工作，參與開發(fā)復(fù)性工作多，如何改進(jìn)？我們可以做一套完整的開發(fā)套件，將包括自動(dòng)檢測在內(nèi)的全部工作做好。

3)?模塊質(zhì)量保證

解決方案：完整的測試用例、文檔支持。

我們要求需要有一個(gè)完整的測試用例與文檔支持，即使是上一個(gè)模塊我們也會(huì)做A/B ?Test和軟切換。保證其模塊的質(zhì)量。

4. 技術(shù)創(chuàng)新與展望

關(guān)于這一點(diǎn)我想與大家分享一個(gè)簡單的例子：P2P技術(shù)想必大家并不陌生。

上圖是我們實(shí)際中接入一位合作方P2P的代碼。如果需要我在外層去控制使用P2P該如何解決？

我們?cè)赑2PLoader層先寫了一些如剛才提到的Loade還有URLsource這樣的標(biāo)準(zhǔn)接口，再寫了這一套代碼；之后把P2P完整接入到我們的HTML5播放器。

我們花了半天工時(shí)寫了一個(gè)模塊與幾行控制代碼就可以將這樣一個(gè)P2P技術(shù)完整接入到播放器中。?

4.1 WebVR

WebVR想必大家都了解一些。但現(xiàn)在距離產(chǎn)品化還有一段探索的路，故而一直沒有推向市場。只需封裝一個(gè)WebVR接口，也就是去做一個(gè)插件就可很快取代我們現(xiàn)有的純MSE，很快就可以上線。

4.2 服務(wù)端應(yīng)用接入

這應(yīng)該是前端的同學(xué)比較熟悉的NodeJS。由于現(xiàn)在的框架包括大部分的模塊和瀏覽器是不相關(guān)的，而唯一和瀏覽器相關(guān)的是部分Loader與基于瀏覽器的MSE。我們可以使用Node服務(wù)端運(yùn)行提供音視頻服務(wù)，將來需要去自建CDN時(shí)可以很輕易地將我們現(xiàn)在所做的包括解決音畫不同步在內(nèi)的一切優(yōu)化都轉(zhuǎn)接到一個(gè)邊緣節(jié)點(diǎn)上。

Q&A

Q1.1：播放器剛啟動(dòng)時(shí)默認(rèn)使用大碼率還是小碼率？

A：大碼率

Q1.2：如果用戶的網(wǎng)絡(luò)環(huán)境比較差怎么辦？

A：關(guān)于這一點(diǎn)我們有一個(gè)降級(jí)的解決方案。熊貓直播可切換三個(gè)清晰度，但默認(rèn)是超清；用戶上傳多少碼率，我就可以拉多少碼率。比如說有P2P推一個(gè)8000kbps的碼率，其用戶可在超清鏈路上拉到8000，如果出現(xiàn)卡頓可切換到高清或更低的碼流。

Q1.3：播放器是否會(huì)推薦給用戶合適的碼流？

A：這是一個(gè)業(yè)務(wù)層面需要解決的問題。我們?cè)贚oader里集成了一個(gè)實(shí)時(shí)監(jiān)控的插件監(jiān)控實(shí)時(shí)傳輸速率?；诒ＷC沉浸且連續(xù)的用戶體驗(yàn)與業(yè)務(wù)方的需求，我們不會(huì)默認(rèn)在直播中向用戶彈出推薦合適碼流的提示框。

Q1.4：一般碼流切換時(shí)播放器會(huì)緩存多長時(shí)間？

A：這個(gè)問題與我們的首屏優(yōu)化有一定關(guān)系的，我預(yù)測今天會(huì)有很多人講首屏優(yōu)化。因?yàn)橹辈ヒ曨l里是沒有B幀的，不存在向后預(yù)測的幀，只存在向前預(yù)測的幀。我們進(jìn)行首屏優(yōu)化時(shí)，如果是在GOP比較長的情況下會(huì)在到下一個(gè)I幀前開始播放。我們只會(huì)給I幀緩存并且直接開始播放以實(shí)現(xiàn)秒開的效果，此時(shí)用戶會(huì)看到直播畫面閃一下。

當(dāng)然在這個(gè)過程中需要切換碼率， MOOV的Header需要改變，所以必須要清空之前MSE上所有的數(shù)據(jù)。

Q2：這些視頻插件在Chrome、Safari、IE等平臺(tái)上如何實(shí)現(xiàn)適配？

A：其實(shí)大部分國內(nèi)的瀏覽器廠商使用的都是谷歌的Chromium內(nèi)核解決方案，除此之外還有火狐、蘋果的Safari、微軟的Edge。Chrome與火狐已經(jīng)支持了這些插件，而為什么我最后說Safari與Edge？因?yàn)檫@個(gè)問題的解決很大程度上取決于瀏覽器的市場覆蓋率。但是這兩個(gè)瀏覽器在Fetch Loader上存在問題，我們只能去加載HLS流。如果我的Remuxer不變，MSE控制插件也不變的情況下降級(jí)兼容HLS，只需要換一個(gè)Loader一個(gè)Master就可以解決。

Q3：關(guān)于解決音視頻不同步問題的修正碼插件，是集成在原生播放器中嗎？

A：在Remaster中，暫時(shí)還沒有提取出來。 FLV流拉過來時(shí)會(huì)給出一個(gè)PTS差值。當(dāng)被檢測到時(shí)我們就改動(dòng)時(shí)間或重新輸出數(shù)據(jù)包。

HTML5原生播放器支持MP4、WebM，不支持FLV，PC端也不支持HLS。我們會(huì)將數(shù)據(jù)進(jìn)行拆包和分包再傳輸給瀏覽器以實(shí)現(xiàn)格式支持。

Q4：客戶端會(huì)緩存多少？追趕策略是什么？

A：首先說一下幾個(gè)不同拉流方式的差異：Fetch方式拉流時(shí)，因?yàn)槭情L鏈接所以是挨著拉。如果出現(xiàn)網(wǎng)絡(luò)抖動(dòng)，保持在比較卡的狀態(tài)下拉流會(huì)和服務(wù)器端產(chǎn)生很大差距；但如果是網(wǎng)絡(luò)抖動(dòng)，后面的數(shù)據(jù)密度大，可與服務(wù)器保持一個(gè)相似的狀態(tài)。這兩種不同追幀方式，如果只是抖動(dòng)，最后拉流多少就是多少。我們會(huì)監(jiān)測實(shí)際播放時(shí)長和理論播放時(shí)長的差值，根據(jù)差值找最新的GOP里的I幀。如果有就不用重新拉流，如果沒有則需要重新拉流。

Q4.1：可能緩存一個(gè)GOP？

A：有可能，如果說服務(wù)器本身緩存了三個(gè)GOP，我們會(huì)緩存三個(gè)。

Q5：移動(dòng)端的相關(guān)問題解決方案有什么？

A：移動(dòng)端我們暫時(shí)使用HLS拉流的方式，這一點(diǎn)策略與我們的業(yè)務(wù)相關(guān)。對(duì)我們而言移動(dòng)端本身只是用來分享，沒有必要使用這么高的碼。我們直接用的HLS流，不需要拆分包以提高移動(dòng)端效率。

Q5.1：大概介紹一下碼流監(jiān)控的埋點(diǎn)與監(jiān)控的思路。

A：我們會(huì)監(jiān)控一些參數(shù)，例如某個(gè)Buffer不夠用了，此時(shí)就開始埋這個(gè)卡頓點(diǎn)，開始計(jì)時(shí)到重新播放的狀態(tài)；此時(shí)會(huì)統(tǒng)計(jì)時(shí)間與卡頓次數(shù)并上報(bào)給我們自己的數(shù)據(jù)中心。其實(shí)在CDN會(huì)看到一個(gè)主播推流的上行狀態(tài)，我們還會(huì)監(jiān)控下行網(wǎng)絡(luò)速度等。通過這些埋點(diǎn)我們可以看出到底是哪個(gè)環(huán)節(jié)出現(xiàn)問題，防患于未然。

Q6：補(bǔ)幀的策略是怎么樣的？

A：以視頻幀為基準(zhǔn)。根據(jù)視頻幀的位置計(jì)算音頻幀的位置，如果這幀出現(xiàn)缺失我們就補(bǔ)幀。

Q6.1：補(bǔ)前一幀與后一幀的區(qū)別？

A：根據(jù)不同場景選擇最優(yōu)化的方案，從代碼修改簡便的角度我們會(huì)優(yōu)先選擇補(bǔ)前一幀。

Q7：國外有一種DASH的解決方案，但是國內(nèi)CDN廠商對(duì)DASH的支持不太積極，為何不做相關(guān)的適配工作？

A：我們盡量去推動(dòng)，但在時(shí)間成本上無法保證。技術(shù)過渡期是有必要存在這種技術(shù)的。

Q8：熊貓HTML5播放器是否參考flv.js？能否對(duì)比一下二者優(yōu)劣？

A：我們之前有調(diào)研過他的東西，但最后未使用。原因一是開發(fā)包臃腫，很多東西對(duì)我們來說是沒有必要的。為了防止日后維護(hù)上的混亂我們重構(gòu)了架構(gòu)。原因二是維護(hù)風(fēng)險(xiǎn)過大，跟不上我們的業(yè)務(wù)節(jié)奏。

LiveVideoStackCon 2018講師招募

LiveVideoStackCon 2018是音視頻技術(shù)領(lǐng)域的綜合技術(shù)大會(huì)，今年是在10月19-20日在北京舉行。大會(huì)共設(shè)立18個(gè)專題，預(yù)計(jì)邀請(qǐng)超過80位技術(shù)專家。如果你在某一領(lǐng)域獨(dú)當(dāng)一面，歡迎申請(qǐng)成為LiveVideoStackCon 2018的講師，讓你的經(jīng)驗(yàn)幫到更多人，你可以通過speaker@livevideostack.com提交演講信息。了解大會(huì)更多詳情，點(diǎn)擊【閱讀原文】訪問LiveVideoStackCon 2018官網(wǎng)，報(bào)名即刻享受7折優(yōu)惠。

總結(jié)

以上是生活随笔為你收集整理的熊猫TV直播H5播放器架构探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。