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