之前寫過一篇瀏覽器直播的文章，叫《用一個 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ū)е拢藭r可能需要提醒用戶“當前網(wǎng)絡擁堵”、或者顯示“直播加載中”的字樣，告訴用戶發(fā)生了什么。

而實現(xiàn)這些功能的前提，必須要知道流什么時候斷開，我們就需要做“斷流檢測”。

mpegts.js 提供了幾個內(nèi)置事件來監(jiān)聽直播的狀態(tài)，常用如下：

• mpegts.Events.ERROR：出現(xiàn)異常事件。
• mpegts.Events.LOADING_COMPLETE：流結束事件。
• mpegts.Events.STATISTICS_INFO：流狀態(tài)變化事件。

前兩個事件分別會在出現(xiàn)異常和直播結束的時候觸發(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("直播已結束");
});

當未發(fā)生異常、且直播未結束的情況下，我們就需要監(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í)行，打印結果如下：

可以看到，解碼幀一直在遞增，表示直播正常。

當直播卡頓時，打印結果是這樣的：

解碼幀連續(xù) 9 次卡在了 904 一個數(shù)值不變，這是因為直播卡頓了，沒有畫面需要解碼。

所以，判斷卡頓的方法是將上一次的解碼幀與當前解碼幀做對比，如果值一致則出現(xiàn)了卡頓。

當然輕微的卡頓不需要處理。我們可以將連續(xù) N 次出現(xiàn)相同的解碼幀視為一次卡頓，然后執(zhí)行自己的業(yè)務邏輯。

當解碼幀的值長時間沒有變化時，我們可以視為推流已結束，此時可以主動結束直播。