使用 flv.js 直播，需要一個(gè) <video> 標(biāo)簽承載直播畫面。默認(rèn)情況下 video 標(biāo)簽用于播放點(diǎn)播（錄制好的）視頻，因此它會(huì)一邊播放一邊下載。點(diǎn)播不要求實(shí)時(shí)性，暫停之后再繼續(xù)播放，視頻會(huì)接著暫停的畫面繼續(xù)播放；而如果是直播，暫停后繼續(xù)播放時(shí)必須切換到最新的畫面幀，這就是 “追幀” 的概念。
之前寫過一篇瀏覽器直播的文章，叫《用一個(gè) flv.js 播放監(jiān)控的例子，帶你深撅直播流技術(shù)》。主要內(nèi)容就是科普直播是什么，以及如何在瀏覽器中播放直播。
實(shí)現(xiàn)方法很簡單，使用一個(gè)流行的第三方包 flv.js，即可快速播放直播。
在我們的項(xiàng)目中也使用這種方式，比如播放海康監(jiān)控器的直播、教學(xué)直播等，都可以正常播放。
然而在產(chǎn)品成熟后，我們發(fā)現(xiàn)直播中有兩個(gè)致命問題：
- 直播延遲，播越久延遲越高。
- 直播卡頓，無法判斷什么時(shí)候卡頓。
解決上述兩個(gè)問題是直播穩(wěn)定性和可用性的關(guān)鍵，下面就來詳解一下。
抗延遲關(guān)鍵 —— 追幀
使用 flv.js 直播，需要一個(gè) <video> 標(biāo)簽承載直播畫面。默認(rèn)情況下 video 標(biāo)簽用于播放點(diǎn)播（錄制好的）視頻，因此它會(huì)一邊播放一邊下載。
點(diǎn)播不要求實(shí)時(shí)性，暫停之后再繼續(xù)播放，視頻會(huì)接著暫停的畫面繼續(xù)播放；而如果是直播，暫停后繼續(xù)播放時(shí)必須切換到最新的畫面幀，這就是 “追幀” 的概念。
一圖勝千言，不追幀的效果是這樣的：
追幀的效果是這樣的：
可以看到，設(shè)置追幀后的暫停重播，會(huì)立即切換到最新的畫面。
在實(shí)際場景中，直播沒有暫停按鈕，但是常常會(huì)因?yàn)榫W(wǎng)絡(luò)問題卡頓。如果卡頓恢復(fù)后視頻沒有追幀，就會(huì)導(dǎo)致直播延遲越來越高。
使用 mpegts.js 替代 flv.js
據(jù)傳說，flv.js 的作者是一個(gè)高中畢業(yè)在 B 站上班的小伙子，月薪僅僅不到 5k。后來小伙離職去了日本，無法更新 flv.js，于是有了 mpegts.js。
目前 flv.js 已停止維護(hù)，mpegts.js 是其升級(jí)版，開發(fā)者是同一個(gè)人。涉及到追幀的高級(jí)功能，mpegts.js 支持地更好。
在 flv.js 主頁也可以看到推薦：
mpegts.js 的用法與 flv.js 基本一致，如下：
import mpegts from 'mpegts.js';
let config = {};
let player = mpegts.createPlayer(
{
type: 'flv',
isLive: true,
url: 'http://xxxx.flv',
},
config,
);
mpegts.js 提供了自動(dòng)追幀的配置項(xiàng) liveBufferLatencyChasing，開啟自動(dòng)追幀方法如下：
let config = {
liveBufferLatencyChasing: true,
};
設(shè)置自動(dòng)追幀后，雖然延遲問題解決了，但畫面可能會(huì)更加卡頓。這里涉及到 IO 緩存的問題。
配置 IO 緩存，優(yōu)化追幀卡頓
首先思考一個(gè)問題：直播的延遲越低越好嗎？
從需求上講，當(dāng)然是越低越好；可從技術(shù)上講，并不是越低越好。
直播是實(shí)時(shí)流，從遠(yuǎn)端拉流并實(shí)時(shí)解碼播放，但這個(gè)過程極容易受到網(wǎng)絡(luò)影響。不管是推流端或拉流端遇到了網(wǎng)路抖動(dòng)，數(shù)據(jù)傳輸受阻，直播必然會(huì)卡頓，這個(gè)是正常現(xiàn)象。
怎么辦呢？這個(gè)時(shí)候就要用到 IO 緩存，犧牲一點(diǎn)實(shí)時(shí)性，用延遲換取流暢。
假設(shè)播放器緩存了 1 秒的數(shù)據(jù)流，并將直播延遲 1 秒播放。當(dāng)遇到網(wǎng)絡(luò)抖動(dòng)時(shí)，播放器會(huì)讀取緩存數(shù)據(jù)繼續(xù)播放，網(wǎng)絡(luò)恢復(fù)后再向緩沖區(qū)追加數(shù)據(jù)，這樣用戶在看直播時(shí)，完全感受不到卡頓。
但如果網(wǎng)絡(luò)異常時(shí)間超過 1 秒，緩沖區(qū)中的數(shù)據(jù)讀取完畢，直播還是會(huì)卡住；如果加大緩存量，緩存了 3 秒的數(shù)據(jù)，這又會(huì)導(dǎo)致直播延遲過高。
所以，設(shè)置緩存可以有效解決追幀卡頓問題；若要在保證流暢的前提下，盡可能地降低延遲，則需要一個(gè)合理的緩存值。
mpegts.js 提供了 liveBufferLatencyMaxLatency 和 liveBufferLatencyMinRemAIn 兩個(gè)配置項(xiàng)來控制緩存時(shí)間，分別表示最大緩存時(shí)間和最小緩存時(shí)間，單位為秒。
以下方配置為例，緩存時(shí)間設(shè)置越長、流暢性越好、延遲越高：
let config = {
liveBufferLatencyChasing: true, // 開啟追幀
liveBufferLatencyMaxLatency: 0.9, // 最大緩存時(shí)間
liveBufferLatencyMinRemain: 0.2, // 最小緩存時(shí)間
};
實(shí)際的緩存時(shí)間會(huì)根據(jù)網(wǎng)絡(luò)情況動(dòng)態(tài)變化，值的范圍在上述兩個(gè)配置項(xiàng)之間。
處理卡頓關(guān)鍵 —— 斷流檢測
直播是實(shí)時(shí)流播放，任何一個(gè)環(huán)節(jié)出現(xiàn)異常，都會(huì)導(dǎo)致直播卡頓、出現(xiàn)黑屏等現(xiàn)象。這是因?yàn)閷?shí)時(shí)拉取的流數(shù)據(jù)斷開了，我們稱之為“斷流”。
多數(shù)情況下的斷流都是網(wǎng)絡(luò)原因?qū)е拢藭r(shí)可能需要提醒用戶“當(dāng)前網(wǎng)絡(luò)擁堵”、或者顯示“直播加載中”的字樣，告訴用戶發(fā)生了什么。
而實(shí)現(xiàn)這些功能的前提，必須要知道流什么時(shí)候斷開，我們就需要做“斷流檢測”。
mpegts.js 提供了幾個(gè)內(nèi)置事件來監(jiān)聽直播的狀態(tài)，常用如下：
- mpegts.Events.ERROR：出現(xiàn)異常事件。
- mpegts.Events.LOADING_COMPLETE：流結(jié)束事件。
- mpegts.Events.STATISTICS_INFO：流狀態(tài)變化事件。
前兩個(gè)事件分別會(huì)在出現(xiàn)異常和直播結(jié)束的時(shí)候觸發(fā)，監(jiān)聽方法如下：
let player = mpegts.createPlayer({...})
player.on(mpegts.Events.ERROR, e=> {
console.log('發(fā)生異常')
});
player.on(mpegts.Events.LOADING_COMPLETE, (e) => {
console.log("直播已結(jié)束");
});
當(dāng)未發(fā)生異常、且直播未結(jié)束的情況下，我們就需要監(jiān)聽直播卡頓。通過監(jiān)聽 STATISTICS_INFO 事件來實(shí)現(xiàn)。
首先科普一下：播放器在播放直播時(shí)需要實(shí)時(shí)解碼，每一幀畫面過來，就需要解碼一次。當(dāng)直播卡頓時(shí)，沒有畫面過來，解碼也會(huì)暫停，因此可以通過已解碼的幀數(shù)來判斷是否卡頓。
STATISTICS_INFO 事件的回調(diào)函數(shù)參數(shù)中，有一個(gè) decodedFrames 屬性，正是表示當(dāng)前已解碼的幀數(shù)，我們來看一下：
player.on(mpegts.Events.STATISTICS_INFO, (e) => {
console.log("解碼幀："e.decodedFrames); // 已經(jīng)解碼的幀數(shù)
});
在直播過程中，上述回調(diào)函數(shù)會(huì)一直執(zhí)行，打印結(jié)果如下：
可以看到，解碼幀一直在遞增，表示直播正常。
當(dāng)直播卡頓時(shí)，打印結(jié)果是這樣的：
解碼幀連續(xù) 9 次卡在了 904 一個(gè)數(shù)值不變，這是因?yàn)橹辈タD了，沒有畫面需要解碼。
所以，判斷卡頓的方法是將上一次的解碼幀與當(dāng)前解碼幀做對比，如果值一致則出現(xiàn)了卡頓。
當(dāng)然輕微的卡頓不需要處理。我們可以將連續(xù) N 次出現(xiàn)相同的解碼幀視為一次卡頓，然后執(zhí)行自己的業(yè)務(wù)邏輯。
當(dāng)解碼幀的值長時(shí)間沒有變化時(shí)，我們可以視為推流已結(jié)束，此時(shí)可以主動(dòng)結(jié)束直播。
