作者：京東科技 吳磊

音視頻基本概念

視頻格式就是通常所說的??.mp4??,??.flv??,??.ogv??,??.webm??等。簡單來說，它其實就是一個盒子，用來將實際的視頻流以一定的順序放入，確保播放的有序和完整性。

(資料圖)

視頻壓縮格式和視頻格式具體的區別就是，它是將原始的視頻碼流變為可用的數字編碼。因為，原始的視頻流非常大，打個比方就是，你直接使用手機錄音，你會發現你幾分鐘的音頻會比市面上出現的 MP3 音頻大小大很多，這就是壓縮格式起的主要作用。

首先，由原始數碼設備提供相關的數字信號流，然后經由視頻壓縮算法，大幅度的減少流的大小，然后交給視頻盒子，打上相應的dts，pts字段，最終生成可用的視頻文件。

DTS（Decoding Time Stamp）：即解碼時間戳，這個時間戳的意義在于告訴播放器該在什么時候解碼這一幀的數據。

PTS（Presentation Time Stamp）：即顯示時間戳，這個時間戳用來告訴播放器該在什么時候顯示這一幀的數據。

視頻編碼

視頻實際上就是一幀一幀的圖片，拼接起來進行播放而已。而圖片本身也可以進行相關的壓縮，比如去除重復像素，合并像素塊等等。不過，還有另外一種壓縮方法就是，運動估計和運動補償壓縮，因為相鄰圖片一定會有一大塊是相似的，所以，為了解決這個問題，可以在不同圖片之間進行去重。

所以，總的來說，常用的編碼方式分為三種：

變換編碼：消除圖像的幀內冗余

運動估計和運動補償：消除幀間冗余

熵編碼：提高壓縮效率

熵編碼即編碼過程中按熵原理不丟失任何信息的編碼。信息熵為信源的平均信息量（不確定性的度量）。常見的熵編碼有：香農(Shannon)編碼、哈夫曼(Huffman)編碼和算術編碼(arithmetic coding)。

直播

現在，常用的直播協議有 RTMP，HLS，HTTP-FLV。最常用的還是 HLS 協議，因為支持度高，技術簡單，但是延遲非常嚴重。這對一些對實時性比較高的場景，比如運動賽事直播來說非常的不友好。這里來細分的看一下每個協議。

協議對比

協議	優勢	劣勢	延時
HLS	支持性廣	延時巨高	10s 以上
RTMP	延時性好，靈活	量大的話，負載較高	1s 以上
HTTP-FLV	延時性好，游戲直播常用	只能在手機 APP 播放	2s 以上

HLS

HLS 全稱是 HTTP Live Streaming。這是Apple提出的直播流協議。

HLS 由兩部分構成，一個是??.m3u8??文件，一個是??.ts??視頻文件（TS 是視頻文件格式的一種）。整個過程是，瀏覽器會首先去請求??.m3u8??的索引文件，然后解析??m3u8??，找出對應的??.ts??文件鏈接，并開始下載。

他的使用方式為：

直接可以將??m3u8??寫進??src??中，然后交由瀏覽器自己去解析。當然也可以采取??fetch??來手動解析并獲取相關文件。HLS 詳細版的內容比上面的簡版多了一個??playlist??，也可以叫做??master??。在??master??中，會根據網絡段實現設置好不同的 m3u8 文件，比如，3G/4G/wifi 網速等。比如，一個 master 文件中為：

#EXTM3U#EXT-X-VERSION:6#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2855600,CODECS="avc1.4d001f,mp4a.40.2",RESOLUTION=960x540live/medium.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=5605600,CODECS="avc1.640028,mp4a.40.2",RESOLUTION=1280x720live/high.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1755600,CODECS="avc1.42001f,mp4a.40.2",RESOLUTION=640x360live/low.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=545600,CODECS="avc1.42001e,mp4a.40.2",RESOLUTION=416x234live/cellular.m3u8

大家只要關注??BANDWIDTH??（帶寬）字段，其他的看一下字段內容大致就清楚了。假如這里選擇??high.m3u8??文件，那么，里面內容為：

#EXTM3U#EXT-X-VERSION:6#EXT-X-TARGETDURATION:10#EXT-X-MEDIA-SEQUENCE:26#EXTINF:9.901,http://media.example.com/wifi/segment26.ts#EXTINF:9.901,http://media.example.com/wifi/segment27.ts#EXTINF:9.501,http://media.example.com/wifi/segment28.ts

注意，其中以??ts??結尾的鏈接就是在直播中真正需要播放的視頻文件。該第二級的??m3u8??文件也可以叫做??media??文件。該文件，其實有三種類型：

live playlist: 動態列表。顧名思義，該列表是動態變化的，里面的 ts 文件會實時更新，并且過期的 ts 索引會被刪除。默認，情況下都是使用動態列表。

event playlist: 靜態列表。它和動態列表主要區別就是，原來的 ts 文件索引不會被刪除，該列表是不斷更新，而且文件大小會逐漸增大。它會在文件中，直接添加 #EXT-X-PLAYLIST-TYPE:EVENT 作為標識。

VOD playlist: 全量列表。它就是將所有的 ts 文件都列在 list 當中。如果，使用該列表，就和播放一整個視頻沒有啥區別了。它是使用 #EXT-X-ENDLIST 表示文件結尾。

HLS 缺陷

HLS 缺陷就是延遲性太大了。HLS 中的延時包括：

TCP 握手

m3u8 文件下載

m3u8 文件下所有 ts 文件下載

這里先假設每個 ts 文件播放時長為 5s，每個 m3u8 最多可攜帶的 ts 文件數為 3~8。那么最大的延遲則為 40s。注意，只有當一個??m3u8??文件下所有的 ts 文件下載完后，才能開始播放。這里還不包括 TCP 握手，DNS 解析，m3u8 文件下載。所以，HLS 總的延時是非常令人絕望的。

那解決辦法有嗎？ 有，很簡單，要么減少每個 ts 文件播放時長，要么減少??m3u8??的中包含 ts 的數量。如果超過平衡點，那么每次請求新的 m3u8 文件時，都會加上一定的延時，所以，這里需要根據業務指定合適的策略。

RTMP

RTMP 全稱為：??Real-Time Messaging Protocol??。它是基于??FLV??格式進行開發的，所以，第一反應就是，又不能用了！！！

是的，在現在設備中，由于 FLV 的不支持，基本上 RTMP 協議在 Web 中，根本用不到。不過，由于??MSE??（MediaSource Extensions）的出現，在 Web 上直接接入 RTMP 也不是不可能的。基本思路是根據 WebSocket 直接建立長連接進行數據的交流和監聽。RTMP 協議根據不同的套層，也可以分為：

純 RTMP: 直接通過 TCP 連接，端口為 1935

RTMPS: RTMP + TLS/SSL，用于安全性的交流。

RTMPE: RTMP + encryption。在 RTMP 原始協議上使用，Adobe 自身的加密方法

RTMPT: RTMP + HTTP。使用 HTTP 的方式來包裹 RTMP 流，延遲性比較大。

RTMFP: RMPT + UDP。該協議常常用于 P2P 的場景中，針對延時有變態的要求。

RTMP 內部是借由 TCP 長連接協議傳輸相關數據，所以，它的延時性非常低。并且，該協議靈活性非常好（所以，也很復雜），它可以根據 message stream ID 傳輸數據，也可以根據 chunk stream ID 傳遞數據。兩者都可以起到流的劃分作用。流的內容也主要分為：視頻，音頻，相關協議包等。

HTTP-FLV

該協議和 RTMP 比起來其實差別不大，只是落地部分有些不同：

RTMP 是直接將流的傳輸架在 RTMP 協議之上，而 HTTP-FLV 是在 RTMP 和客戶端之間套了一層轉碼的過程，由于，每個 FLV 文件是通過 HTTP 的方式獲取的，所以，它通過抓包得出的協議頭需要使用chunked編碼。

Content-Type:video/x-flvExpires:Fri, 10 Feb 2017 05:24:03 GMTPragma:no-cacheTransfer-Encoding:chunked

它用起來比較方便，不過后端實現的難度和直接使用 RTMP 來說還是比較大的。

前端音視頻流

由于各大瀏覽器的對 FLV 的圍追堵截，導致 FLV 在瀏覽器的生存狀況堪憂，但是，FLV 憑借其格式簡單，處理效率高的特點，使各大視頻后臺的開發者都舍不得棄用，如果一旦更改的話，就需要對現有視頻進行轉碼，比如變為 MP4，這樣不僅在播放，而且在流處理來說都有點重的讓人無法接受。而 MSE 的出現，徹底解決了這個尷尬點，能夠讓前端能夠自定義來實現一個 Web 播放器，確實完美。（不過，蘋果覺得沒這必要，所以，在 IOS 上無法實現。）

MSE

MSE 全稱就是??Media Source Extensions??。它是一套處理視頻流技術的簡稱，里面包括了一系列 API：??Media Source??，??Source Buffer??等。在沒有 MSE 出現之前，前端對 video 的操作，僅僅局限在對視頻文件的操作，而并不能對視頻流做任何相關的操作。現在 MSE 提供了一系列的接口，使開發者可以直接提供 media stream。

來看一下 MSE 是如何完成基本流的處理的。

var vidElement = document.querySelector("video");if (window.MediaSource) {  var mediaSource = new MediaSource();  vidElement.src = URL.createObjectURL(mediaSource);  mediaSource.addEventListener("sourceopen", sourceOpen);} else {  console.log("The Media Source Extensions API is not supported.")}function sourceOpen(e) {  URL.revokeObjectURL(vidElement.src);  var mime = "video/webm; codecs="opus, vp9"";  var mediaSource = e.target;  var sourceBuffer = mediaSource.addSourceBuffer(mime);  var videoUrl = "droid.webm";  fetch(videoUrl)    .then(function(response) {      return response.arrayBuffer();    })    .then(function(arrayBuffer) {      sourceBuffer.addEventListener("updateend", function(e) {        if (!sourceBuffer.updating && mediaSource.readyState === "open") {          mediaSource.endOfStream();        }      });      sourceBuffer.appendBuffer(arrayBuffer);    });}

上面這個例子可以簡單理解為：

第一步，通過異步拉取數據。

第二步，通過 MediaSource 處理數據。

第三步，將數據流交給 audio/video 標簽進行播放。

而中間傳遞的數據都是通過??Buffer??的形式來進行傳遞的。

中間有個需要注意的點，MS 的實例通過??URL.createObjectURL()??創建的 url 并不會同步連接到 video.src。換句話說，??URL.createObjectURL()??只是將底層的流（MS）和 video.src 連接中間者，一旦兩者連接到一起之后，該對象就沒用了。

MediaSource

MediaSource 是 Media Source Extensions API 表示媒體資源 HTMLMediaElement 對象的接口。MediaSource 對象可以附著在 HTMLMediaElement 在客戶端進行播放。

MS(MediaSource) 只是一系列視頻流的管理工具，它可以將音視頻流完整的暴露給 Web 開發者來進行相關的操作和處理。所以，它本身不會造成過度的復雜性。

MS 整個只掛載了 4 個屬性，3 個方法和 1 個靜態測試方法。

4 個屬性：

sourceBuffers: 獲得當前創建出來的 SourceBuffer

activeSourceBuffers: 獲得當前正處于激活狀態的 SourceBuffer

readyState: 返回當前 MS 的狀態，比如:??closed??,??open??,??ended??.

duration: 設置當前 MS 的播放時長。

3 個方法：

addSourceBuffer(): 根據給定的 MIME 創建指定類型的 SourceBuffer

removeSourceBuffer(): 將 MS 上指定的 SourceBuffer 移除。

endOfStream(): 直接終止該流

1 個靜態測試方法：

isTypeSupported(): 主要用來判斷指定的音頻的 MIME 是否支持。

最基本的就是使用??addSourceBuffer??該方法來獲得指定的 SourceBuffer。

var sourceBuffer = mediaSource.addSourceBuffer("video/mp4; codecs="avc1.42E01E, mp4a.40.2"");

資料：

SourceBuffer

SourceBuffer 接口表示通過 MediaSource 對象傳遞到 HTMLMediaElement 并播放的媒體分塊。它可以由一個或者多個媒體片段組成。

一旦利用 MS 創建好 SourceBuffer 之后，后續的工作就是將額外獲得的流放進 Buffer 里面進行播放即可。所以，SourceBuffer 提供兩個最基本的操作??appendBuffer??，??remove??。之后，就可以通過??appendBuffer??直接將 ArrayBuffer 放進去即可。

其中，SourceBuffer 還提供了一個應急的方法??abort()??如果該流發生問題的話可以直接將指定的流給廢棄掉。

音視頻的 ArrayBuffer 通過 MediaSource 和 SourceBuffer 的處理直接將???&&???接入。然后，就可以實現正常播放的效果。

資料：

基于flv.js實現H5直播

flv.js 簡介

flv.js是來自Bilibli的開源項目。它解析FLV文件傳給原生HTML5 Video標簽播放音視頻數據，使瀏覽器在不借助Flash的情況下播放FLV成為可能。

flv.js 優勢

由于瀏覽器對原生Video標簽采用了硬件加速，性能很好，支持高清。

同時支持錄播和直播

去掉對Flash的依賴

flv.js 限制

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

對于錄播，依賴 原生HTML5 Video標簽 和 Media Source Extensions API

對于直播，依賴錄播所需要的播放技術，同時依賴 HTTP FLV 或者 WebSocket 中的一種協議來傳輸FLV。其中HTTP FLV需通過流式IO去拉取數據，支持流式IO的有fetch或者stream

由于依賴Media Source Extensions，目前所有iOS和Android4.4.4以下里的瀏覽器都不支持，也就是說目前對于移動端flv.js是有局限性的。

flv.js 原理

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

vue + flv.js

//下載flv.js包npm i flv.js -S//引入flv.js包import flv from "flv.js"http://HTML部分

flv.js資料：

參考資料：