作者 | 阿里文娛前端技術(shù)專家 歸影
責(zé)編 | 夕顏
出品 | CSDN（ID:CSDNnews）
這不是一篇基于MSE開發(fā)Web播放器的入門文章，而是圍繞Web播放器開發(fā)遇到的常見(jiàn)問(wèn)題與解決方案，畢竟入門文章常有而趟坑干貨不常有。如果您有Web播放開發(fā)經(jīng)驗(yàn)和音視頻技術(shù)基礎(chǔ)，讀起來(lái)會(huì)更有共鳴。
Web播放器開發(fā)基礎(chǔ)知識(shí)
先介紹Web播放器開發(fā)的一些基礎(chǔ)知識(shí)。有人要問(wèn)了，Web播放器開發(fā)難道不是一個(gè)video標(biāo)簽就夠了么？非也！
1、瀏覽器Video支持的格式非常有限
在W3C的標(biāo)準(zhǔn)里面Video只支持MP4格式 準(zhǔn)確的說(shuō)是ISOBMFF(Fragment MP4)。當(dāng)然chrome支持WEBM，safari支持HLS(MPEG-TS)這都是自家的私有實(shí)現(xiàn)，做不得數(shù)。
2、瀏覽器Video無(wú)法逐個(gè)加載視頻切片
現(xiàn)在主流的流媒體點(diǎn)播/直播技術(shù)，都會(huì)把視頻切片。而video標(biāo)簽src只能掛載整個(gè)MP4資源。沒(méi)法逐個(gè)的加載視頻分段。
所以我們的主角出場(chǎng)—— MediaSource Extenstion，簡(jiǎn)稱MSE，是一套能不斷的把音視頻二進(jìn)制數(shù)據(jù)塞給video標(biāo)簽播放的API。
圖1：MSE簡(jiǎn)明結(jié)構(gòu)
MSE內(nèi)部可以創(chuàng)建一系列的sourcebuffer，一般是一個(gè)音頻buffer，一個(gè)視頻buffer。把MSE做成blob url之后綁定給video的src。然后就可以通過(guò)AppendBuffer往video里追加音視頻數(shù)據(jù)了。有了MSE，播放器器的整體結(jié)構(gòu)是什么樣的呢，見(jiàn)下圖。
圖2：Web播放器簡(jiǎn)明結(jié)構(gòu)
首先在瀏覽器層面，主要使用video標(biāo)簽、MSE、XHR 和UI。那么播放器主要由Manager驅(qū)動(dòng)加載視頻的playlist（比如HLS里的m3u8，dash里的MPD，F(xiàn)LV雖然不是playlist概念，但是是原理上差別不大，都是為了拿到視頻的一個(gè)個(gè)的片段的地址），并通過(guò)數(shù)據(jù)服務(wù)加載這一個(gè)個(gè)的分片。然后通過(guò)transmuxer也就是所謂的轉(zhuǎn)封裝器，把分片的封裝格式比如TS拆開（demux） 把連原始的音視頻數(shù)據(jù)解出來(lái)，再重新打包成fmp4(remux)，最后通過(guò)MSE API喂給video標(biāo)簽里，讓video去播放。
因此播放器所做的事情最主要有兩點(diǎn)：
1） 轉(zhuǎn)封裝。即將video不支持的封裝格式轉(zhuǎn)碼成video所支持的封裝格式；
2） 如何驅(qū)動(dòng)整個(gè)播放進(jìn)行。即決定何時(shí)下載下一個(gè)分片，何時(shí)需要解碼插入到video的buffer里。
時(shí)間戳對(duì)齊
轉(zhuǎn)封裝除了的封裝格式的解復(fù)用(demux)和再?gòu)?fù)用（remux）之外最重要的環(huán)節(jié)就是分片的時(shí)間戳對(duì)齊策略，以及音視頻同步。
圖3（傳說(shuō)中的“開局一張圖 原理全靠猜”）
簡(jiǎn)單講一下上圖：紅色代表音頻的時(shí)間軸。藍(lán)色/青色是視頻的時(shí)間軸。PTS(Presentation Time Stamp) 指的是這一幀需要渲染的時(shí)間。DTS(Decoding Time Stamp) 指的是這一幀需要解碼的時(shí)間。
1、首片首幀的對(duì)齊策略
正常來(lái)說(shuō)音頻PTS和DTS是一樣的，而視頻如果有B幀的話DTS往往要比PTS早一些(因?yàn)橐A(yù)留一定的時(shí)間解碼)。因此視頻的首幀會(huì)有一個(gè)洞(gap/shift隨便你怎么叫)，如果不經(jīng)處理插到video里，那么video里的buffer也會(huì)呈現(xiàn)出一小段的洞，一般是0.08s(比如10s的分片 插進(jìn)去可能出現(xiàn)0.08~10.08的情況)。現(xiàn)在主流的做法是削掉這個(gè)洞。就是把DTS跟PTS強(qiáng)行拉平，一般來(lái)說(shuō)chrome 不會(huì)出現(xiàn)太大的問(wèn)題。但是safari不行，如果不預(yù)留一定的DTS/PTS偏移，safari前兩幀的播放會(huì)明顯卡頓。
2、后續(xù)對(duì)齊策略后續(xù)分片的對(duì)齊，會(huì)通過(guò)DTS/PTS兩個(gè)尾部指針來(lái)做。如果發(fā)現(xiàn)后續(xù)分片時(shí)間軸有間隔就往前推從而填上間隔。如果發(fā)現(xiàn)重疊，就把重疊幀后移。這樣雖然會(huì)導(dǎo)致后續(xù)分片的前幾幀重疊。但在播放的過(guò)程中幾乎沒(méi)有影響。
音視頻同步
首先，什么情況下會(huì)導(dǎo)致音畫不同步？
1、視頻源流壓根沒(méi)對(duì)齊。沒(méi)救了，看下一點(diǎn)。
2、還是因?yàn)橛卸础?/strong>很多時(shí)候視頻切出來(lái)的每個(gè)分片之間都不一定是嚴(yán)絲合縫的，分片間的音視頻時(shí)間戳可能有洞。而且對(duì)于TS由于音頻每一幀的duration（≈23ms） 跟視頻每一幀的duration(40ms@25fps) 無(wú)法吻合(整除) 所以加劇了這種參差不齊的情況。那么，重點(diǎn)來(lái)了！chrome有個(gè)特殊的機(jī)制， 如果發(fā)現(xiàn)音頻之間有洞之后，為了保證音頻的平順，會(huì)自動(dòng)把后續(xù)音頻往前推抹平這個(gè)洞。如果每個(gè)分片都有洞，悲劇了，這種往前推的操作就會(huì)積累越來(lái)越多導(dǎo)致音視頻不同步。
小tips:
打開chrome的媒體調(diào)試頁(yè)面 chrome://media-internals 可以看到媒體播放相關(guān)的所有debug信息和error信息非常有用。其中就會(huì)有一條關(guān)于音頻處理的提示：
當(dāng)然這條顯示的具體原因是自動(dòng)切掉重疊overlap導(dǎo)致的。其實(shí)gap/overlap本質(zhì)是一樣的。怎么辦？當(dāng)然是播放器自己主動(dòng)把洞填上。具體做法是插幀。目前主要是插靜音幀，或者復(fù)制前一幀。靜音幀會(huì)帶來(lái)毛刺音，復(fù)制幀會(huì)導(dǎo)致拖音。我們目前的優(yōu)化方案是判斷附近的音頻數(shù)據(jù)量，數(shù)據(jù)量大時(shí)說(shuō)明此處聲音豐富(其實(shí)不算靠譜，姑且這么處理，因?yàn)闆](méi)有更好的判斷方式)，如果插靜音幀會(huì)毛刺很明顯，所以此時(shí)用復(fù)制幀，反之插靜音幀。
那些年我們趟過(guò)的坑
1、 不同版本表現(xiàn)差異 容忍度不同
1） Chrome 35分水嶺。chrome35之前要求關(guān)鍵幀之后的第一幀dts不允許跟關(guān)鍵幀dts相同，否則拋錯(cuò)。
2） 低延遲的模式。把轉(zhuǎn)封裝出來(lái)的FMP4中的視頻軌duration(tkhd box) 設(shè)置成0xffffffff 時(shí)會(huì)讓chrome認(rèn)為這是直播流，會(huì)開啟低延遲模式，所謂低延遲模式就是會(huì)極大的減少幀緩存，基本上視頻幀立馬解碼立馬播放減少每個(gè)分片的起播延遲。但是呢在CPU負(fù)載過(guò)高的情況下（解不過(guò)來(lái)）會(huì)造成視頻頻繁卡頓（網(wǎng)絡(luò)無(wú)關(guān)的）。
2、 不同瀏覽器表現(xiàn)有差異
1) timeupdate事件。W3C的標(biāo)準(zhǔn)是不能超過(guò)250ms觸發(fā)一次。windows下360等瀏覽器會(huì)達(dá)到500ms左右。
2) safari對(duì)每一幀duration平順度更敏感。safari需要對(duì)每一視頻幀的duration標(biāo)準(zhǔn)化處理，例如TS下要處理成3600。
3) 對(duì)洞的容忍度不同。chrome遇到buffer中有0.08的間隔以內(nèi)會(huì)自動(dòng)跳過(guò)去。像IE edge等瀏覽器不行會(huì)卡住，所以播放器一定要有跳洞邏輯。比如判斷當(dāng)前卡在洞的邊界，要主動(dòng)跳過(guò)去（seek）。
3、內(nèi)存限制
通過(guò)MSE push給video的視頻數(shù)據(jù)會(huì)在內(nèi)部維護(hù)一個(gè)buffer，這個(gè)尺寸是有限制的。
1） chrome系列約100M
2） IE系列約30M
超過(guò)的話就會(huì)導(dǎo)致拋出 QuotaExceededError 。所以需要處理好buffer的尺寸以及及時(shí)清除不用的buffer。比如已經(jīng)播放過(guò)的，正常瀏覽器會(huì)自己清除，但是不那么的及時(shí)。
優(yōu)化
簡(jiǎn)單說(shuō)一下卡頓相關(guān)的優(yōu)化。
- 多級(jí)Buffer控制
- ABR 自適應(yīng)碼率算法
- 基于WebRTC的P2P
1、多級(jí)buffer
為什么要有多級(jí)的buffer？因?yàn)関ideo本身的解碼buffer有大小限制，而且buffer過(guò)長(zhǎng)會(huì)導(dǎo)致長(zhǎng)時(shí)間解碼，會(huì)導(dǎo)致CPU一直占用高。所以我們搞了兩級(jí)buffer一級(jí)就是video的buffer另外一級(jí)是內(nèi)存中的，只負(fù)責(zé)下載，二級(jí)很長(zhǎng)。可以消除網(wǎng)絡(luò)抖動(dòng)帶來(lái)的卡頓影響。
2、ABR自適應(yīng)碼率的算法
這個(gè)主要是來(lái)預(yù)測(cè)用戶本身的帶寬范圍，然后選用不同碼率的視頻流來(lái)無(wú)縫切換播放。當(dāng)然還有一些策略算法，比如根據(jù)用戶現(xiàn)在buffer的水位，或者檢測(cè)到用戶頻繁超時(shí)，來(lái)采用不同的策略。
3、基于WebRTC的P2P
因?yàn)镻2P是基于UDP的傳輸，可以突破一些帶寬限制或網(wǎng)絡(luò)擁塞而導(dǎo)致的卡頓問(wèn)題。不過(guò)P2P不一定靠譜所以還是要輔以普通的HTTP傳輸相結(jié)合。我們一般是利用P2P加indexDB 來(lái)變相延長(zhǎng)視頻的緩沖區(qū)。因?yàn)镻2P帶寬成本便宜，我們利用P2P做了一個(gè)非常長(zhǎng)又很便宜的buffer。這樣的話網(wǎng)絡(luò)再波動(dòng)也不會(huì)導(dǎo)致卡頓了。
