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