為什么要在這個(gè)時(shí)候探索flv.js做直播呢？原因在于各大瀏覽器廠商已經(jīng)默認(rèn)禁用Flash，之前常見的Flash直播方案需要用戶同意使用Flash后才可以正常使用直播功能，這樣的用戶體驗(yàn)很致命。

在介紹flv.js之前先介紹下常見的直播協(xié)議以及給出我對(duì)它們的延遲與性能所做的測(cè)試得出的數(shù)據(jù)。

如果你看的很吃力可以先了解下音視頻技術(shù)的一些基礎(chǔ)概念。

常見直播協(xié)議

• RTMP: 底層基于TCP，在瀏覽器端依賴Flash。

• HTTP-FLV: 基于HTTP流式IO傳輸FLV，依賴瀏覽器支持播放FLV。

• WebSocket-FLV: 基于WebSocket傳輸FLV，依賴瀏覽器支持播放FLV。WebSocket建立在HTTP之上，建立WebSocket連接前還要先建立HTTP連接。

• HLS: Http Live Streaming，蘋果提出基于HTTP的流媒體傳輸協(xié)議。HTML5可以直接打開播放。

• RTP: 基于UDP，延遲1秒，瀏覽器不支持。

常見直播協(xié)議延遲與性能數(shù)據(jù)以下數(shù)據(jù)只做對(duì)比參考

在支持瀏覽器的協(xié)議里，延遲排序是：

RTMP = HTTP-FLV = WebSocket-FLV

而性能排序恰好相反：

RTMP > HTTP-FLV = WebSocket-FLV > HLS

也就是說(shuō)延遲小的性能不好。

可以看出在瀏覽器里做直播，使用HTTP-FLV協(xié)議是不錯(cuò)的，性能優(yōu)于RTMP+Flash，延遲可以做到和RTMP+Flash一樣甚至更好。

flv.js 簡(jiǎn)介

flv.js是來(lái)自Bilibli的開源項(xiàng)目。它解析FLV文件喂給原生HTML5 Video標(biāo)簽播放音視頻數(shù)據(jù)，使瀏覽器在不借助Flash的情況下播放FLV成為可能。

flv.js 優(yōu)勢(shì)

• 由于瀏覽器對(duì)原生Video標(biāo)簽采用了硬件加速，性能很好，支持高清。

• 同時(shí)支持錄播和直播

• 去掉對(duì)Flash的依賴

flv.js 限制

• FLV里所包含的視頻編碼必須是H.264，音頻編碼必須是AAC或MP3， IE11和Edge瀏覽器不支持MP3音頻編碼，所以FLV里采用的編碼最好是H.264+AAC，這個(gè)讓音視頻服務(wù)兼容不是問(wèn)題。

• 對(duì)于錄播，依賴 原生HTML5 Video標(biāo)簽 和 Media Source Extensions API

• 對(duì)于直播，依賴錄播所需要的播放技術(shù)，同時(shí)依賴 HTTP FLV 或者 WebSocket 中的一種協(xié)議來(lái)傳輸FLV。其中HTTP FLV需通過(guò)流式IO去拉取數(shù)據(jù)，支持流式IO的有fetch或者stream

• flv.min.js 文件大小 164Kb，gzip后 35.5Kb，flash播放器gzip后差不多也是這么大。

• 由于依賴Media Source Extensions，目前所有iOS和Android4.4.4以下里的瀏覽器都不支持，也就是說(shuō)目前對(duì)于移動(dòng)端flv.js基本是不能用的。

flv.js依賴的瀏覽器特性兼容列表

• HTML5 Video

• Media Source Extensions

• WebSocket

• HTTP FLV: fetch 或 stream

flv.js 原理

flv.js只做了一件事，在獲取到FLV格式的音視頻數(shù)據(jù)后通過(guò)原生的JS去解碼FLV數(shù)據(jù)，再通過(guò)Media Source Extensions API 喂給原生HTML5 Video標(biāo)簽。(HTML5 原生僅支持播放 mp4/webm 格式，不支持 FLV)

flv.js 為什么要繞一圈，從服務(wù)器獲取FLV再解碼轉(zhuǎn)換后再喂給Video標(biāo)簽?zāi)?？原因如下?

1. 兼容目前的直播方案：目前大多數(shù)直播方案的音視頻服務(wù)都是采用FLV容器格式傳輸音視頻數(shù)據(jù)。

2. FLV容器格式相比于MP4格式更加簡(jiǎn)單，解析起來(lái)更快更方便。

flv.js兼容方案

由于目前flv.js兼容性還不是很好，要用在產(chǎn)品中必要要兼顧到不支持flv.js的瀏覽器。兼容方案如下：

PC端

1. 優(yōu)先使用 HTTP-FLV，因?yàn)樗舆t小，性能也不差1080P都很流暢。

2. 不支持 flv.js 就使用 Flash播放器播 RTMP 流。Flash兼容性很好，但是性能差默認(rèn)被很多瀏覽器禁用。

3. 不想用Flash兼容也可以用HLS，但是PC端只有Safari支持HLS

移動(dòng)端

1. 優(yōu)先使用 HTTP-FLV，因?yàn)樗舆t小，支持HTTP-FLV的設(shè)備性能運(yùn)行 flv.js 足夠了。

2. 不支持 flv.js 就使用 HLS，但是 HLS延遲非常大。

3. HLS 也不支持就沒(méi)法直播了，因?yàn)橐苿?dòng)端都不支持Flash。

flv.js實(shí)戰(zhàn)

說(shuō)了這么多介紹與原理，接下來(lái)教大家如何用flv.js搭建一個(gè)完整的直播系統(tǒng)。

這里教大家用AMS創(chuàng)建一個(gè)直播頻道，具體詳細(xì)介紹，參考這里 : http://www.cqlpj.cn/article/99.html

關(guān)注微信公眾號(hào):Aoku2017，可獲取更多關(guān)于AMS的介紹

搭建完成后，flv_over_http的觀看地址是:Flv_over_http觀看地址: http://192.168.2.10:9001/flv/live/test

實(shí)現(xiàn)播放頁(yè)

在react體系里使用react flv.js 組件reflv 快速實(shí)現(xiàn)。

先安裝npm i reflv，再寫代碼：

import React,{PureComponent}from'react';

import Reflv from'reflv';

exportclassHttpFlvextendsPureComponent{

render(){

return(

)

}

}

讓以上代碼在瀏覽器里運(yùn)行。這是你還看不到直播，

flv.js延遲優(yōu)化

按照上面的教程運(yùn)行起來(lái)的直播延遲大概有3秒，經(jīng)過(guò)優(yōu)化可以到1秒。在教你怎么優(yōu)化前先要介紹下直播運(yùn)行流程：

1. 主播端在采集到一段時(shí)間的音視頻原數(shù)據(jù)后，因?yàn)橐粢曨l原數(shù)據(jù)龐大需要先壓縮數(shù)據(jù)：

• 通過(guò)H264視頻編碼壓縮數(shù)據(jù)數(shù)據(jù)

• 通過(guò)PCM音頻編碼壓縮音頻AAC數(shù)據(jù)

2. 壓縮完后再通過(guò)FLV容器格式封裝壓縮后的數(shù)據(jù)，封裝成一個(gè)FLV TAG

3. 再把FLV TAG通過(guò)RTMP協(xié)議推流到音視頻服務(wù)器，音視頻服務(wù)器再?gòu)腞TMP協(xié)議里解析出FLV TAG。

4. 音視頻服務(wù)器再通過(guò)HTTP協(xié)議通過(guò)和瀏覽器建立的長(zhǎng)鏈接流式把FLV TAG傳給瀏覽器。

5. flv.js 獲取FLV TAG后解析出壓縮后的音視頻數(shù)據(jù)喂給Video播放。

知道流程后我們就知道從哪入手優(yōu)化了：

• 主播端采集時(shí)收集了一段時(shí)間的音視頻原數(shù)據(jù)，它專業(yè)的叫法是GOP?？s短這個(gè)收集時(shí)間(也就是減少GOP長(zhǎng)度)可以優(yōu)化延遲，但這樣做的壞處是導(dǎo)致視頻壓縮率不高，傳輸效率低。

• 關(guān)閉音視頻服務(wù)器的I楨緩存可以優(yōu)化延遲，壞處是用戶看到直播首屏的時(shí)間變大。

• 減少音視頻服務(wù)器的buffer可以優(yōu)化延遲，壞處是音視頻服務(wù)器處理效率降低。

• 減少瀏覽器端flv.js的buffer可以優(yōu)化延遲，壞處是瀏覽器端處理效率降低。

• 瀏覽器端開啟flv.js的Worker，多進(jìn)程運(yùn)行flv.js提升解析速度可以優(yōu)化延遲，這樣做的flv.js配置代碼是：

{

enableWorker: true,

enableStashBuffer: false,

stashInitialSize: 128,

}

這里是優(yōu)化后的完整代碼