TS 在阿里云視頻直播的基礎(chǔ)上進行底層技術(shù)優(yōu)化，通過集成阿里云播放器 SDK，支持在千萬級并發(fā)場景下節(jié)點間毫秒級延時直播的能力，彌補了傳統(tǒng)直播存在 3~6 秒延時的問題，確保了超低延時、低卡頓、秒開流暢的直播觀看體驗。本文介紹了基于 RTS 超低延遲直播優(yōu)化強互動場景體驗的最佳實踐方案，并以阿里云播放器 Aliplayer 為例，詳細介紹 RTS 超低延遲拉流接入、自動降級、排障信息獲取等邏輯的實現(xiàn)，助力企業(yè)打造互動直播行業(yè)的產(chǎn)品競爭力。
該方案適用于對超低延遲直播有訴求的客戶，尤其是業(yè)務(wù)中存在強互動場景直播的場景。強互動場景直播主要是指對主播和觀眾存在互動，或觀眾存在更高實時性觀看、畫面互動需求的情況，常見場景例如：
背景
某在線知識分享產(chǎn)品為核心的技術(shù)服務(wù)商，客戶期望能基于產(chǎn)品的原有普通直播 Paas 能力進行升級，降低終端用戶的直播延遲，提供更優(yōu)質(zhì)的用戶觀看體驗。推薦客戶底層接入 RTS 服務(wù)實現(xiàn)超低延遲的平臺直播解決方案，最終封裝后作為 Saas 產(chǎn)品能力提供給外部用戶付費接入使用，通過超低延遲的直播體驗打造其 SAAS 產(chǎn)品在市場上的核心競爭力。
本文圍繞著升級過程中客戶核心訴求進行展開。特別地，會對如何使用 RTS 解決傳統(tǒng) Web 端使用 HLS 播放存在高延遲的場景進行重點介紹。
業(yè)務(wù)場景
傳統(tǒng)直播升級 RTS 超低延遲直播過程中，僅涉及底層對接變更，無需改造終端用戶的功能使用習(xí)慣，直播核心功能訴求主要考慮推拉流側(cè)用戶場景：
當前解決方案及痛點
主要場景
推流部分通過 rtmp 直推標準直播或者 webrtc 采集后合流轉(zhuǎn)推標準直播實現(xiàn)；而拉流時，為了滿足用戶無需安裝app即可便捷觀看的需求，需要重點考慮移動端的瀏覽器頁面對媒體流的兼容性問題，相較 FLV 和 RTMP 協(xié)議在 HTML 5 頁面中不甚理想的表現(xiàn)，客戶優(yōu)先考慮使用 HLS 格式進行拉流。
未接入 RTS 時的核心痛點
由于 HLS 協(xié)議特性，默認 Web 端觀看直播畫面延遲在 10s 以上，盡管傳統(tǒng)直播中，客戶可以在直播延遲中配置 HLS 為低延遲，但此時拉流端的延遲也仍在 3-6s 左右，對存在強互動需求場景的體驗并不友好。
除 HLS 協(xié)議自身導(dǎo)致的高延遲痛點外，Saas 直播廠商在未接入阿里云標準直播前，還會額外面臨以下幾個痛點：
當前標準直播方案架構(gòu)圖
當前業(yè)務(wù)整體架構(gòu)圖
RTS 接入流程詳解
標準直播升級到 RTS 過程中，主要需要改造的部分為
接入RTS后直播方案架構(gòu)圖
實施步驟
準備工作
在正式開始接入前，默認您已經(jīng)在控制臺完成開通直播服務(wù)、添加推流域名和播流域名、配置CNAME、關(guān)聯(lián)推流域名和播流域名，并開通了超低延時直播功能等基礎(chǔ)準備工作。
在本案例的業(yè)務(wù)升級流程中，覆蓋了常見場景下的推薦步驟及功能說明，其中非必要的改造會在步驟中進行標注，可根據(jù)實際業(yè)務(wù)訴求選擇性應(yīng)用。
步驟一：RTS 推流地址及播放地址構(gòu)造
構(gòu)造推拉流地址前，需要準備好直播流的推流域名、播流域名、AppName（應(yīng)用）、StreamName（直播流）、鑒權(quán)串（如有）。以常用的RTMP推流，RTS拉流為例，基礎(chǔ)拼接規(guī)則如下：
推流地址：rtmp://http://demo.aliyundoc.com/app/stream?auth_key={鑒權(quán)串}
構(gòu)造規(guī)則：推流協(xié)議：//推流域名/AppName（應(yīng)用）/StreamName（直播流）? 鑒權(quán)串
拉流地址：artc://http://example.aliyundoc.com/app/stream?auth_key={鑒權(quán)串}
構(gòu)造規(guī)則：artc://播流域名/AppName（應(yīng)用）/StreamName（直播流）? 鑒權(quán)串
步驟二：RTS 服務(wù)端轉(zhuǎn)碼配置
由于原生瀏覽器對 WebRTC 的限制，在 Web 端播放 RTS 流時存在以下限制：
相對的，在推流時推薦使用
如果無法控制推流內(nèi)容的編碼，或者僅無法支持 OPUS 的音頻編碼直推，可以配置轉(zhuǎn)碼模板來兼容。不同轉(zhuǎn)碼配置對延遲影響略有不同，可參考如下配置說明進行選擇：
模板類型 | 使用場景 | 模板優(yōu)勢 |
原畫模板 | 僅需要去 B 幀或 OPUS 轉(zhuǎn)碼，推流編碼不含 B 幀時僅開啟 OPUS 轉(zhuǎn)碼即可 | 原畫僅 OPUS 轉(zhuǎn)碼時延遲最優(yōu) |
窄帶高清?模板 | 同等視頻質(zhì)量下，最高節(jié)省 20-40%帶寬 | 節(jié)省帶寬，帶寬成本最優(yōu) |
標準轉(zhuǎn)碼模板 | 傳統(tǒng)轉(zhuǎn)碼能力，對壓縮比例和延遲無極致需求。 | |
純音頻轉(zhuǎn)碼模板 | 刪除視頻只輸出 OPUS 音頻流 | 自動去視頻畫面 |
在當前客戶案例中，客戶優(yōu)先考慮延遲因素，因此轉(zhuǎn)碼模板選擇原畫模板，僅開啟 OPUS 轉(zhuǎn)碼，減少視頻處理過程中的轉(zhuǎn)碼耗時，配置示例如下。
模板配置完成后，轉(zhuǎn)碼流的播放地址需要在原播放地址的基礎(chǔ)上進行修改。如下圖所示，創(chuàng)建模板 ID 中填寫 example 時，結(jié)尾會自動補全后綴-RTS ，即此時模板ID全名為 example-RTS 。
注意：配置轉(zhuǎn)碼后，轉(zhuǎn)碼流的播放地址對應(yīng)為
轉(zhuǎn)碼流地址：artc://http://example.aliyundoc.com/app/stream_example-RTS?auth_key={鑒權(quán)串}
構(gòu)造規(guī)則：artc://播流域名/AppName（應(yīng)用）/StreamName（直播流）_轉(zhuǎn)碼模板ID? 鑒權(quán)串
特別提醒：如播放域名配置鑒權(quán)，鑒權(quán)串需要針對已拼接轉(zhuǎn)碼模板ID的地址進行簽算生成。
步驟三：RTS Web播放器對接
RTS超低延時直播以WebRTC信令交互方式為基礎(chǔ)，需要 HTML5 播放器播放時完成信令交互及媒體信息的編解碼，RTS拉流播放時有三種選擇：
當前案例中，客戶使用阿里云播放器 Aliplayer 完成 RTS 拉流接入、拉流自動降級、排障信息獲取等邏輯的實現(xiàn)。阿里云播放器已經(jīng)集成了 Web RTS SDK，可以直接用于播放 RTS 流，并且內(nèi)置了 RTS 自動降級邏輯，只需要提供一個降級地址即可使用，能夠?qū)崿F(xiàn)快速業(yè)務(wù)上線。
當用戶播放時使用的瀏覽器不支持 WebRTC ，或者用戶端通過 RTS 拉流失敗時，為了保證業(yè)務(wù)的可用性，播放頁面可以選擇降級至 HLS、FLV 播放，目前主要支持的降級場景包括：
以下為阿里云播放器 Aliplayer 示例代碼，實現(xiàn)了基礎(chǔ)播放的邏輯（含降級），示例代碼中的關(guān)鍵字段說明：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="IE=edge" >
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no"/>
<title>Aliplayer Rts Demo</title>
<link rel="stylesheet" href="https://g.alicdn.com/de/prismplayer/2.9.23/skins/default/aliplayer-min.css" />
<script type="text/javascript" charset="utf-8" src="https://g.alicdn.com/de/prismplayer/2.9.23/aliplayer-min.js"></script>
</head>
<body>
<div class="prism-player" id="player-con"></div>
<script>
/**
* 播放器默認播放 source 提供的 rts 拉流地址，如果失敗，則會自動降級至 rtsFallbackSource 提供的拉流地址（如 HLS 地址）。
* 可能的降級場景包括：
* 1. 瀏覽器不支持 RTS，直接降級
* 2. RTS 信令請求失敗（拉流地址無效、https配置無效、RTS配置無效等），直接降級
* 3. RTS 起播超時或中途斷流，按自定義策略重試失敗后降級
**/
// 更多播放器配置請參考 https://player.alicdn.com/aliplayer/index.html
var options={
"id": "player-con",
"source": "RTS播放地址",
"rtsFallbackSource": "降級地址，如HLS",
"width": "100%",
"height": "500px",
"autoplay": true,
"isLive": true,
"playsinline": true,
"skipRtsSupportCheck": false, // 對于不在 https://help.aliyun.com/document_detail/397569.html 中的瀏覽器，可以傳 true 跳過檢查，強制使用 RTS（有風(fēng)險，需要自測保證）
/**
* RTS 拉流超時會默認重試
* 以下兩個參數(shù)用來控制降級之前的重試策略，比如 3000 毫秒超時，重試一次，如果再拉不到流就降級，那么總共等待 6000 毫秒降級
**/
// RTS 多久拉不到流會重試，默認 3000 ms
// rtsLoadDataTimeout: 2000,
// RTS 拉不到流重試的次數(shù)，默認 5，此參數(shù)建議設(shè)為 1，即重試 1 次后降級，可以減少降級等待時間
liveRetry: 1,
};
var player=new Aliplayer(options, function () {/* player ready */});
// 降級時會觸發(fā)此事件
player.on('rtsFallback', function(event) {
console.log('[EVENT]rtsFallback', event.paramData);
// event.paramData.reason 降級的原因
// event.paramData.fallbackUrl 降級到的地址
})
player.on('error', function(event) {
console.log('[EVENT]error', event.paramData);
})
</script>
</body>步驟四：低延遲推流配置
通過 RTMP 協(xié)議推流時，需要控制推流數(shù)據(jù)的關(guān)鍵幀間隔（GOP），GOP值越大，拉流延遲越高，推薦 GOP 設(shè)置為 1s。
以 OBS 軟件推流為例，需要在推流軟件的輸出設(shè)置中，設(shè)置以下視頻編碼參數(shù)值。
輸出參數(shù)配置完成后，推流地址正確填寫即可開始推流。
步驟五：頁面播放測試及延遲觀測
完成推流和播放器對接后，可以在頁面播放器中手動輸入播放地址，或從業(yè)務(wù)后端接口獲取 RTS 播放地址進行播放。
延遲效果演示
https://v.youku.com/v_show/id_XNTg4ODEyNDYwNA==.html?spm=a1z3jc.11711052.0.0&isextonly=1
步驟六：H5 頁面播放時獲取 TraceID
在傳統(tǒng)直播中遇到延遲高、卡頓或其他問題需要提交售后排障工單時，往往需要用戶協(xié)助采集多種客戶端信息，排障效率較低，而在 RTS 接入直播時，我們只需捕獲信令交互階段中的traceid信息，即可提供給工程師結(jié)合問題現(xiàn)象進行問題分析。
該步驟為可選步驟，為了線上業(yè)務(wù)在排障場景中的便捷性和信息精準度，推薦作為接入改造步驟之一。以阿里云播放器 Aliplayer / 其他播放器集成 RTS SDK 接入兩種場景為例，提供了排障信息 TraceID 的獲取 Demo。
1.通過阿里云播放器 Aliplayer 播放
需要通過 player._rts.traceid 主動獲取，用戶可以在出現(xiàn)卡頓時選擇上報信息。
示例代碼：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="x-ua-compatible" content="IE=edge" >
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no"/>
<title>Aliplayer Online Settings</title>
<link rel="stylesheet" href="https://g.alicdn.com/de/prismplayer/2.9.23/skins/default/aliplayer-min.css" />
<script type="text/javascript" charset="utf-8" src="https://g.alicdn.com/de/prismplayer/2.9.23/aliplayer-min.js"></script>
</head>
<body>
<div class="prism-player" id="player-con"></div>
<button id="trace">獲取TraceId</button>
<script>
var btn=document.getElementById('trace');
var player=new Aliplayer({
"id": "player-con",
"source": "RTS拉流地址",
"width": "100%",
"height": "500px",
"autoplay": true,
}, function (player) {
console.log("The player is created");
}
);
btn.addEventListener('click', function() {
// 獲取 traceId，請使用 aliplayer 2.9.22 及以上版本
var traceId=player._rts.traceid;
console.log('traceId', traceId)
})
</script>
</body>2.通過其他播放器集成RTS SDK接入
RTS SDK 可以通過注冊 customReporter 函數(shù)獲取所有消息，當 msgid 為126即訂閱成功時，可以獲取 TraceID 。
示例代碼：
AliRTS.createClient({
customReporter: (params)=> {
const msgIds=[126/* 訂閱成功 */, 220/* 推流成功 */];
if (msgIds.includes(Number(params.msgid))) {
const args=JSON.parse(params.args);
const traceId=args.tcid;
console.log('traceId', traceId);
}
}
})優(yōu)勢一：自助接入便捷
無論直接接入阿里云 RTS ，或是基于阿里云標準直播升級為 RTS ，技術(shù)對接流程均支持自助化的極簡操作，1周可完成業(yè)務(wù)的接入到上線。
優(yōu)勢二：超低延遲的多平臺支持
端到端延時從10秒以上降低至百毫秒，且支持大部分主流平臺播放。
Native端：兼容 iOS、Andriod、Mac、Windows 平臺。
Web端：終端兼容率大于94%，開放 WebRTC 信令自研接入規(guī)范。
優(yōu)勢三：抗弱網(wǎng)能力
從 TCP 協(xié)議升級至 UDP 協(xié)議，疊加媒體特性，消除窗口阻塞和延時應(yīng)答，并獲得更強的抗卡頓能力，在丟包30%的情況下可以流暢播放。
優(yōu)勢四：提供高可用、靈活降級方案
服務(wù)端具備完善的推拉流全鏈路監(jiān)控及告警能力，客戶端支持 RTS 拉流失敗或個別瀏覽器無法兼容時自動降級，從客戶端和服務(wù)端雙重對業(yè)務(wù)高可用性進行保障。
優(yōu)勢五：海量節(jié)點提供高并發(fā)支持
超低延時直播復(fù)用 CDN 節(jié)點架構(gòu)，通過全球2800+節(jié)點提供服務(wù)。經(jīng)過實踐檢驗的千萬級高并發(fā)視頻云直播技術(shù)，有效提升私域流量的商業(yè)轉(zhuǎn)化。
優(yōu)勢六：強大轉(zhuǎn)碼能力
直播服務(wù)端轉(zhuǎn)碼配置極簡，觸發(fā)便捷，滿足對多碼率、不同分辨率、不同編碼的用戶需求。阿里云獨有的窄帶高清? 特性，保證畫質(zhì)的同時降低碼率，整體上幫助用戶降低成本，同等視頻質(zhì)量下最高可節(jié)省20%~40%帶寬。
優(yōu)勢七：豐富API可對接管理
提供 137 個豐富靈活的API接口支持，滿足業(yè)務(wù)全面訴求。客戶支持 StreamID 流維度用量統(tǒng)計，結(jié)合 RTS 及普通直播的域名用量統(tǒng)計，可以精確統(tǒng)計各流的用量數(shù)據(jù)，便于用戶統(tǒng)計下行業(yè)務(wù)具體用量。
如何解決部分安卓手機QQ瀏覽器無法推拉流？
部分安卓手機（如 vivo iQOO）安裝QQ瀏覽器后首次打開可能無法拉起X5內(nèi)核，導(dǎo)致WebRTC兼容問題推拉流失敗（報錯：Failed to execute 'setRemoteDescription' on 'RTCPeerConnection’）。如果遇到該場景請按照以下操作確保X5內(nèi)核初始化：
為什么部分瀏覽器不支持Web RTS SDK？
對于Web RTS SDK暫不支持的瀏覽器，主要有以下原因：
超低延遲直播簡介
實現(xiàn)超低延時直播基本流程
RTS 播放器 Demo
Web RTS SDK簡介
RTS 轉(zhuǎn)碼
RTS 信令協(xié)議規(guī)范
原文鏈接：https://click.aliyun.com/m/1000352469/
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
bs是一款開源的直播推流軟件，同時obs里面的配置項繁多，很多的人想利用obs進行推流直播，但是又不知道如何操作。而且很多時候操作會遇上延遲，如何設(shè)置推流直播無延遲？保利威的無延遲直播就吸引無數(shù)企業(yè)的目光。
首先回答該利用obs怎么推流直播呢？方法如下：①下載并安裝bos，安裝時，可能會出現(xiàn)是或否提示，選擇“是”。②安裝后會有配置引導(dǎo)，直接點 “否” 跳過這個引導(dǎo)流程。③打開 obs軟件主界面，點擊 “設(shè)置” 按鈕，并點擊左側(cè)欄 “輸出” 標簽，根據(jù)直播現(xiàn)場網(wǎng)絡(luò)，設(shè)置視頻比特率，即推流碼率。④基礎(chǔ)分辨率與輸出分辨率保持一致為1280*720即可。FPS，即視頻畫面的輸出幀率，選擇 25 即可。⑤界面選擇左側(cè)的“流”欄目，串流類型選擇 “自定義流媒體服務(wù)器” ，在下方的URL和流名稱欄中，分別輸入從上直播平臺獲取到的URL和流名稱信息。配置完成后，點擊 “確定”。這樣全部配置工作完成了。在obs主界面，點擊右下角 “開始推流” 按鈕，這時就可以開始你的直播了。
在直播中出現(xiàn)延遲，是很正常的事。但是對于像搶紅包、秒殺這些就出現(xiàn)延遲就有很大的影響了。所以要直播推流，必須做到無延遲，這時候保利威就可以幫到你。保利威推出的無延遲直播解決方案可以將傳統(tǒng)直播3-20秒的延時降至400毫秒。保利威的無延遲直播推流適用于互動性強、體驗要求高的場景和注重高品質(zhì)的vip服務(wù)場景。如秒殺活動、商品拍賣、在線答題、賽事直播等。因為只有無延遲體驗才能夠讓直播互動得更充分。
前在csdn上面看到一篇文章，叫《用一個 flv.js 播放監(jiān)控的例子，帶你深撅直播流技術(shù)》。這片文章的熱度還不錯，主要內(nèi)容就是科普直播是什么，以及如何在瀏覽器中播放直播。
實現(xiàn)方法很簡單，使用一個流行的第三方包 flv.js，即可快速播放直播。
在我們的項目中也使用這種方式，比如播放海康監(jiān)控器的直播、教學(xué)直播等都可以正常播放。然而在產(chǎn)品成熟后，我們發(fā)現(xiàn)直播中有兩個致命問題：
解決上述兩個問題是直播穩(wěn)定性和可用性的關(guān)鍵，下面就來詳解一下。
使用 flv.js 直播，需要一個 <video> 標簽承載直播畫面。默認情況下 video 標簽用于播放點播（錄制好的）視頻，因此它會一邊播放一邊下載。
點播不要求實時性，暫停之后再繼續(xù)播放，視頻會接著暫停的畫面繼續(xù)播放；而如果是直播，暫停后繼續(xù)播放時必須切換到最新的畫面幀，這就是 “追幀” 的概念。
一圖勝千言，不追幀的效果是這樣的：
追幀的效果是這樣的：
可以看到，設(shè)置追幀后的暫停重播，會立即切換到最新的畫面。
在實際場景中，直播沒有暫停按鈕，但是常常會因為網(wǎng)絡(luò)問題卡頓。如果卡頓恢復(fù)后視頻沒有追幀，就會導(dǎo)致直播延遲越來越高。
據(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 緩存的問題。
首先思考一個問題：直播的延遲越低越好嗎？
從需求上講，當然是越低越好；可從技術(shù)上講，并不是越低越好。
直播是實時流，從遠端拉流并實時解碼播放，但這個過程極容易受到網(wǎng)絡(luò)影響。不管是推流端或拉流端遇到了網(wǎng)路抖動，數(shù)據(jù)傳輸受阻，直播必然會卡頓，這個是正常現(xiàn)象。
怎么辦呢？這個時候就要用到 IO 緩存，犧牲一點實時性，用延遲換取流暢。
假設(shè)播放器緩存了 1 秒的數(shù)據(jù)流，并將直播延遲 1 秒播放。當遇到網(wǎng)絡(luò)抖動時，播放器會讀取緩存數(shù)據(jù)繼續(xù)播放，網(wǎng)絡(luò)恢復(fù)后再向緩沖區(qū)追加數(shù)據(jù)，這樣用戶在看直播時，完全感受不到卡頓。
但如果網(wǎng)絡(luò)異常時間超過 1 秒，緩沖區(qū)中的數(shù)據(jù)讀取完畢，直播還是會卡住；如果加大緩存量，緩存了 3 秒的數(shù)據(jù)，這又會導(dǎo)致直播延遲過高。
所以，設(shè)置緩存可以有效解決追幀卡頓問題；若要在保證流暢的前提下，盡可能地降低延遲，則需要一個合理的緩存值。
mpegts.js 提供了 liveBufferLatencyMaxLatency 和 liveBufferLatencyMinRemain 兩個配置項來控制緩存時間，分別表示最大緩存時間和最小緩存時間，單位為秒。
以下方配置為例，緩存時間設(shè)置越長、流暢性越好、延遲越高：
let config={
liveBufferLatencyChasing: true, // 開啟追幀
liveBufferLatencyMaxLatency: 0.9, // 最大緩存時間
liveBufferLatencyMinRemain: 0.2, // 最小緩存時間
};
實際的緩存時間會根據(jù)網(wǎng)絡(luò)情況動態(tài)變化，值的范圍在上述兩個配置項之間。
直播是實時流播放，任何一個環(huán)節(jié)出現(xiàn)異常，都會導(dǎo)致直播卡頓、出現(xiàn)黑屏等現(xiàn)象。這是因為實時拉取的流數(shù)據(jù)斷開了，我們稱之為“斷流”。
多數(shù)情況下的斷流都是網(wǎng)絡(luò)原因?qū)е拢藭r可能需要提醒用戶“當前網(wǎng)絡(luò)擁堵”、或者顯示“直播加載中”的字樣，告訴用戶發(fā)生了什么。
而實現(xiàn)這些功能的前提，必須要知道流什么時候斷開，我們就需要做“斷流檢測”。
mpegts.js 提供了幾個內(nèi)置事件來監(jiān)聽直播的狀態(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 這個值不變，這是因為直播卡頓了，沒有畫面需要解碼。
所以，判斷卡頓的方法是將上一次的解碼幀與當前解碼幀做對比，如果值一致則出現(xiàn)了卡頓。
當然輕微的卡頓不需要處理。我們可以將連續(xù) N 次出現(xiàn)相同的解碼幀視為一次卡頓，然后執(zhí)行自己的業(yè)務(wù)邏輯。
當解碼幀的值長時間沒有變化時，我們可以視為推流已結(jié)束，此時可以主動結(jié)束直播。
如果有小伙伴在本文中遇到了疑問，歡迎加我微信 ruidoc 拉你進讀者群交流咨詢，或者關(guān)注我的公眾號 江湖人稱CV工程師 查看更多文章。