圖網長期致力于web前端開發，難免會和各種視頻、音頻打交道，除了常見的mp4、mp3等格式，其實還有m3u8、oga等等其他沒有那么常見的格式，那么你都了解了嗎？下面介紹一下html5常見的音視頻格式和解決方案。

萬能播放插件js

1.ckplayerhttp://www.ckplayer.com/

2.Sewise Player

一款專業的免費網頁HTML5視頻、流播放器，它功能強大，體積小，跨平臺，兼容性好，使用方便簡潔。確定html5與flash播放的優先級。支持跨終端播放，不僅適用PC端播放，也適配ipad、iphone、android手機、平板電腦等移動終端。 支持多系統多平臺，PC端支持Window、MacOS、Linux 等，移動端支持Android、IOS、Window Phone等。 兼容HTML5，確保98％的互聯網用戶可以看到您的視頻。 支持多瀏覽器兼容，IE6/7/8/9/10、Chrome、Firefox、Safari、Opera等。 接收來自任何地方的音視頻流 支持mp4、m3u8、oga、webm、theora、flv、f4v等視頻格式播放。 支持Flash播放m3u8文件，以及AES-128解碼播放。 支持播放地址AMF, AJAX, JOSNP類型請求。 支持PC與Mobile平臺播放器自動識別功能。 支持瀏覽器HTML5與Flash特性檢測。

3.hls

http://www.bootcdn.cn/hls.js/

僅支持hls(m3u8)地址，不支持flv,mp4,mov,f4v,3gp格式，做了跨平臺的適配， 支持PC終端,Android安卓終端,iOS蘋果終端,WP終端的正常播放。

m3u8是m3u的一種，是utf-8格式的，Apple 為了提高流播效率開發的技術，特點是將流媒體切分為若干 TS 片段（比如每10秒一段），然后通過一個擴展的 m3u 列表文件將這些 TS 片段集中起來供客戶端播放器接收。可以做多碼率的適配，根據網絡帶寬，客戶端會自動選擇一個適合自己碼率的文件進行播放，保證視頻流的流暢。

MP4是一套用于音頻、視頻信息的壓縮編碼標準，支持所有音頻和視頻以及高級內容（或它們的混合），編碼格式：H.264格式高清

MP4是遵循MPEG-4（ISO 14496-14）的官方容器格式定義的廣義文件擴展名。它可以流媒體化并支持眾多多媒體的內容（多音軌(multiple audio)、視頻流(video)、字幕(subtitlestreams)、圖片(pictures)、可變楨率(variable-framerates)、碼率(bitrates)、采樣率(samplerates)等）和高級內容(advanced content)（官方稱之為“Richmedia”(超媒體)或“BIFS”(Binary Format for Scenes/二進制格式場景），類似2D和3D圖形，動畫、用戶界面、類DVD菜單，上述這些AVI搞不定的東西。

其他相關的擴展名：

– .m4v：是.mp4文件的錯誤擴展名，由apple提出，支持視頻+音頻，m4v擴展名可以安全地更名為.mp4

– .m4a：是.mp4文件的錯誤擴展名，由apple提出，只支持音頻，m4a擴展名可以安全地更名為.mp4

– .m4p：隨iTunes發售的DRM(Digital Rights Management/數字版權保護技術)產權保護的文件，使用Apple開發的DRM sheme

– .m4e：由.sdp修改擴展名的來的文件，Envivio用其于流媒體播放。

– .m4v, -.mp4v, -.cmp, -.divx, .-xvid, .264：raw的mpeg-4視頻流（并非內含于mp4）。

– .3gp, -.3g2：手機中使用的格式，其中儲存的內容同樣在.mp4未被定義（H.263, AMR(Adaptive Multi Rate/自適應多碼率)）。

OGG OGGVobis(oggVorbis)是一種音頻壓縮格式，類似于MP3等的音樂格式。Ogg是完全免費、開放和沒有專利限制的。OggVorbis文件的擴展名是”.ogg”。Ogg文件格式可以不斷地進行大小和音質的改良，而不影響舊有的編碼器或播放器。

OGV是html5中的一個名為Ogg Theora的視頻格式，起源于ogg容器格式。

webm由Google提出，是一個開放、免費的媒體文件格式。WebM標準的網絡視頻更加偏向于開源并且是基于HTML5標準的，WebM 項目旨在為對每個人都開放的網絡開發高質量、開放的視頻格式，其重點是解決視頻服務這一核心的網絡用戶體驗。

MOV(QuickTime)它是Apple公司開發的一種音頻、視頻文件格式，用于存儲常用數字媒體類型。QuickTime用于保存音頻和視頻信息，包括Apple Mac OS，MicrosoftWindows95/98/NT/2003/XP/VISTA，甚至WINDOWS7在內的所有主流電腦平臺支持。

WMV 是微軟推出的一種采用獨立編碼方式并且可以直接在網上實時觀看視頻節目的文件壓縮格式。WMV格式的主要優點包括：本地或網絡回放、可擴充的媒體類型、部件下載、可伸縮的媒體類型、流的優先級化、多語言支持、環境獨立性、豐富的流間關系以及擴展性等。

MPG/MPEG(.mpg, .mpeg)

Realmedia(.rm, .rmvb)

AVI(.avi)

Flv/swf

本文由專業的WEB前端外包公司-切圖網原創，轉載請保留版權（ WEB前端開發外包www.qietu.com ）切圖網始于2007年，提供高品質的前端開發服務、前端外包、切圖外包。歡迎來電咨詢！

要

本文章主要對在瀏覽器環境中實現直播相關的技術介紹，其中包括了對音視頻的格式以及推送、播放技術的探索。分享過程中還會對目前自己已經實現的一套Web直播方案進行分析。最后還會簡單介紹現在比較熱門的WebRTC技術。

什么是音視頻串流

音視頻串流從廣義角度來說，就是能夠實現設備A將音視頻畫面同步傳輸給設備B進行播放，例如電視投屏、會議投屏。而今天所介紹的Web音視頻串流主要是實現允許用戶在瀏覽器環境就能完成串流。

一個完整的Web媒體串流應當具備3種角色，推流客戶端（主播側），媒體服務器（MediaServer）和拉流客戶端（觀眾側）。其中推流和拉流客戶端其實都是在網頁中進行處理的，而MediaServer位于服務端，并且要能夠完成同時接收來自不同推流客戶端的流數據，并對這些流進行區分，向拉流客戶端提供獲取對應流的渠道。

需要知道的音視頻概念

音視頻編碼格式

在封裝格式里的視頻可以用不同的編碼格式,編碼格式簡單的理解就是用特定的壓縮技術把視頻做些處理。不過容器其實也可以做些壓縮處理。所以視頻是可以在編碼格式、容器格式中做兩次壓縮。

常見的編碼格式有:mpeg-2、mpeg-4、h.263、h.264、RV40

音視頻封裝格式 封裝格式就是把已經編碼封裝好的視頻、音頻按照一定的規范放到一起 同一種封裝格式中可以放不同編碼的視頻，不過一種視頻容器格式一般是只支持某幾類編碼格式的視頻。我們能夠最直觀判斷封裝格式的方法就是文件后綴。 常見的容器格式有: MP4、rmvb、rm、flv、AVI、mov、WMV、mk

瀏覽器支持的格式

對于video標簽來說，瀏覽器支持視頻播放的封裝格式有：MP4、WebM和Ogg。其中我們就MP4來說，必須使用h.264編碼的視頻和aac編碼的音頻，才能被瀏覽器正確解析，否則是沒有辦法播放的。

下面列出了另外兩種封裝格式下瀏覽器能直接解碼的音視頻編碼組合：

• WebM ：使用 VP8 視頻編解碼器和 Vorbis 音頻編解碼器
• Ogg：使用 Theora 視頻編解碼器和 Vorbis音頻編解碼器

瀏覽器支持的格式

對于video標簽來說，瀏覽器支持視頻播放的封裝格式有：MP4、WebM和Ogg。其中我們就MP4來說，必須使用h.264編碼的視頻和aac編碼的音頻，才能被瀏覽器正確解析，否則是沒有辦法播放的。

下面列出了另外兩種封裝格式下瀏覽器能直接解碼的音視頻編碼組合：

• WebM ：使用 VP8 視頻編解碼器和 Vorbis 音頻編解碼器
• Ogg：使用 Theora 視頻編解碼器和 Vorbis音頻編解碼器

C++音視頻開發學習資料：點擊領取→音視頻開發（資料文檔+視頻教程+面試題）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

適合媒體串流中的封裝格式

由于在媒體串流的過程中，客戶端是需要源源不斷接受來自外界傳輸的音視頻，并且需要播放已經接受到的部分，后文中把這種特殊的媒體簡寫為流媒體。

而不論是MP4還是WebM還是Ogg都是需要等待完整的數據傳遞完成后才能夠開始播放，并且不能將多個音視頻進行無縫連接播放，所以這三種格式統統無法沒流媒體利用，涼涼。

因此我們需要其他更加適合串流的媒體封裝格式，這里主要介紹下面兩種，為后文作鋪墊。

FLV（Flash Video）

FLV格式的流中， 每一個音視頻數據都被封裝成了包含時間戳信息頭的數據包。在傳輸時，只需要當播放器拿到這些數據包解包的時候能夠根據時間戳信息把這些音視頻數據和之前到達的音視頻數據連續起來播放。

而MP4，MKV等等類似這種封裝，必須拿到完整的音視頻文件才能播放，因為里面的單個音視頻數據塊不帶有時間戳信息，播放器不能將這些沒有時間戳信息數據塊連續起來，所以就不能實時的解碼播放。

TS（Transport Stream）

就如TS（傳輸流）的命名，似乎天生就是為了流媒體而生的一種封裝格式，其特點是多個TS片段可以被播放器無縫拼接進行播放，無需等待重新載入。不過TS的實現相對FLV要復雜許多，在此不再說明，這里我們簡單知道它的特點就可以了。

Web音視頻串流的協議

RTMP（Real Time Messaging Protocol 實時信息控制協議） RTMP是 Adobe Systems 公司為 Flash 播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議， 該協議在國內直播平臺中較為普及。 RTMP 是一種基于TCP進行實時流媒體通信的網絡協議，主要用來在 Flash 平臺和支持 RTMP 協議的流媒體服務器之間進行音視頻和數據通信。RTMP協議下可以用來拉流，也可以進行退流。在瀏覽器中并不支持RTMP協議，只能通過Flash插件進行處理。RTMP傳輸是所支持的媒體格式為FLV。 主播 ==> MediaServer ==> 觀眾

HTTP-FLV

這種協議主要是為了讓原本只能在RTMP中進行傳輸的FLV音視頻流也能夠在HTTP下進行傳輸。主要是用于FLV能夠在瀏覽器頁面中進行播放，由于HTML的Video不直接支持Flv格式的音視頻，所以在早期需要在網頁中加入Flash插件才能夠播放。目前大量的流媒體服務器 Media Server都支持了將FLV格式流通過HTTP-FLV的形式對外界進行開放。

HLS

HLS（HTTP Living Stream） 是一個由蘋果公司提出的基于 HTTP 的流媒體網絡傳輸協議。 HLS 的工作原理是把整個流分成一個個小的基于 HTTP 的文件來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。在開始一個流媒體會話時，客戶端會下載一個包含元數據的 extended M3U (m3u8) playlist文件，用于尋找可用的媒體流。

來解釋一下這張圖，從左到右講，左下方的inputs的視頻源是什么格式都無所謂，他與server之間的通信協議也可以任意（比如RTMP），總之只要把視頻數據傳輸到服務器上即可。這個視頻在server服務器上被轉換成HLS格式的視頻（既TS和m3u8文件）文件。細拆分來看server里面的Media encoder的是一個轉碼模塊負責將視頻源中的視頻數據轉碼到目標編碼格式（H264）的視頻數據。轉碼成H264視頻數據之后，在stream segmenter模塊將視頻切片，切片的結果就是index file（m3u8）和ts文件了。圖中的Distribution其實只是一個普通的HTTP文件服務器，然后客戶端只需要訪問一級m3u8文件的路徑就會自動播放HLS視頻流了。

說說m3u8文件

m3u8的命名來源是m3u文件 + utf-8編碼而來，兩者的文件內容是完全一樣的。下文中直接稱為m3u

m3u (移動圖像專家組音頻層3統一資源定位器)

m3u實際上就是一個索引文件，其中可以記錄TS文件地址，客戶端會按照下載的順序進行連續播放。

對于一個記錄了TS的文件M3U的文件內容如下

#EXTM3U // 聲明文件為M3U，必須寫在第一行
#EXT-X-PLAYLIST-TYPE:VOD // 當前播放類型為點播
#EXT-X-TARGETDURATION:10 //每個視頻分段最大的時長（單位秒）
#EXTINF:10, //下面ts切片的播放時長
2000kbps-00001.ts //ts文件路徑
#EXTINF:10,
2000kbps-00002.ts
#ZEN-TOTAL-DURATION:20
#ZEN-AVERAGE-BANDWIDTH:2190954
#ZEN-MAXIMUM-BANDWIDTH:3536205
#EXT-X-ENDLIST // m3u結束指令

不光如此，m3u還可以記錄二級m3u的文件的地址。

下面是一個記錄了文件地址的m3u8內容

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2128000
drawingSword(1080p).m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1064000
drawingSword(720p).m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=564000
drawingSword(480p).m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=282000
drawingSword(360p).m3u8
#EXT-X-ENDLIST 

bandwidth指定視頻流的比特率，PROGRAM-ID表示資源的ID，每一個#EXT-X-STREAM-INF的下一行是二級index文件的路徑，可以用相對路徑也可以用絕對路徑。例子中用的是相對路徑。這個文件中記錄了不同比特率視頻流的二級index文件路徑，客戶端可以當前環境的網絡帶寬，來決定播放哪一個視頻流。也可以在網絡帶寬變化的時候平滑切換到和帶寬匹配的視頻流。

HLS目前的不足 由于HLS需要將采集到的音視頻進行分片、客戶端也需要對接受到的分片后的音視頻進行合并處理，因此相對來時會存在比較大的延遲，大概會達到 10s左右。

HLS在瀏覽器中的兼容情況

事實上，HLS 在 PC 端僅支持safari瀏覽器，而其他大部分PC瀏覽器使用HTML5 video標簽由于無法解析TS所以不能直接播放(需要通過hls.js)。移動端不論是安卓還是IOS統統都原生支持HLS。這點主要是由于HLS是由Apple公司推廣的，蘋果自家的瀏覽器上都是支持的，而安卓也進行了跟進。所以如果想要在PC瀏覽器上使用到HLS，仍然需要使用其他技術手段才能實現。

各協議總結：

Web音視頻串流實踐方案（WebSocket + RTMP）

這里簡單介紹一種在網頁中進行音視頻串流的方案: 把RTMP推流的工作放到中間服務層（此次以Node為例）去,而拉流通過流媒體服務器開放的HTTP-FLV，并在播放前使用Flv.js將轉換后的流數據喂給Video去解析播放。

FFmpeg:一款處理音視頻非常有效的工具, 這款工具提供以命令行的方式去對視頻進行轉碼、轉封裝格式、增加水印等等功能其中還包括了RTMP推流的功能。同時FFmpeg也為Node提供了一些控制的Bridge，在后文中，我會在中間層使用Node來控制FFmpeg進行音視頻的推流。

STEP1：推流客戶端 => Node中間處理層

這里有包括兩種推流的音視頻源，一種是實時錄制自己的攝像頭進行推流。另外一種是使用本地的視頻文件進行發送。這里我們分開來講

對于推流客戶端推送實時錄制的音視頻數據時，其核心操作就用過瀏覽器來調用攝像頭數據，并通過MediaStreamRecorder.js去捕獲音視頻二進制數據（Blob）注意此處每個時間片返回一個blob，獲得當前時間片的Blob后通過WebSocket將blob數據傳遞給Node中間層。

而對于推流客戶端推送視頻格式的文件時，需要做的就是將視頻文件按照每段時間的視頻量進行分片。例如對于一個100s的視頻，如果按照每段blob需要發送4s的數據量，那就需要分為25段blob，這些可以通過前端去進行分片，分片發送的中間Node層。后面的操作就和攝像頭推流一致了。

STEP2：Node中間處理層 => 流媒體服務器

在Blob數據抵達Node中間層后會被轉化為Buffer，在Node層我們需要做的這些分段的視頻格式轉化為ts格式的片段，再將ts片段（這里就利用到了TS能夠無縫拼接進行播放的特性，能夠讓ffmpeg推送持續的流媒體）通過ffmpeg將持續不斷接受到的TS格式的流媒體轉化為Flv流并通過RTMP推流到流媒體服務器上。

C++音視頻開發學習資料：點擊領取→音視頻開發（資料文檔+視頻教程+面試題）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

流媒體服務器是在Node.js環境下通過node-media-server第三方包進行搭建。Node-media-server許多不同協議的推流和拉流的方法。其中它支持外界通過RTMP的方式進行推流拉流（端口1935），也支持將RTMP流轉換為HTTP-FLV協議的流對外開放（端口8000）。通過Node-media-server建立一個流媒體服務步驟也很簡單，只需要如下代碼：

const NodeMediaServer = require('node-media-server');

const config = {
  rtmp: {
    port: 1935,
    chunk_size: 60000,
    gop_cache: true,
    ping: 30,
    ping_timeout: 60
  },
  http: {
    port: 8000,
    allow_origin: '*'
  }
};

const nms = new NodeMediaServer(config)
nms.run();

在Node-media-server中，提供了通過使用不用的URL路徑來對流進行區分。這里貼上一個官方提供的URL格式

rtmp://hostname:port/appname/stream
http://hostname:port/appname/stream.flv

例如對于音視頻流A，它的URL是這樣的： rtmp://47.110.88.142:1935/live/root_14465 可以看出對于這個流，appName這里被命名為了live, 而stream被命名為了root_14465。對應的，如果想通過HTTP-FLV進行拉這條流，可以通過下面這條URL: http://47.110.88.142:8000/live/root_14465.flv 在完成流媒體服務器的搭建后，不同用戶會生成對應不同的推流URL，只要為觀眾發放正確對應的拉流URL就會播放正確的流數據。實現了并行串流的目的。 本地演示：

1. 起流媒體服務器
2. 通過ffmpeg推流
3. 通過http-flv拉流

STEP3: 流媒體服務器 => 拉流客戶端

通過Http-flv進行傳輸，瀏覽器的video標簽通過http獲取到flv流后，使用Flv.js【后文中介紹】進行轉換封包格式后為MP4后便能夠持續播放。

Flv.js

在實現過程中，我們用到了flv.js, 這是B站開源的一款媒體流轉碼插件，該插件能夠利用Js將接受到的HTTP-FLV實時轉碼為Video能夠接受的MP4格式。

得益于瀏覽器提供了Media Source Extensions API（MSE）,使得flv.js能夠通過JavaScript來對流數據格式進行轉換，并分片為

這里我們貼一段flv.js的簡單的使用代碼

<script src="flv.min.js"></script>
<video id="videoElement"></video>
<script>
    if (flvjs.isSupported()) {
        var videoElement = document.getElementById('videoElement');
        var flvPlayer = flvjs.createPlayer({
            type: 'flv',
            url: 'http://example.com/flv/video.flv'
        });
        flvPlayer.attachMediaElement(videoElement);
        flvPlayer.load();
        flvPlayer.play();
    }
</script>

Flv.js不足

MSE目前在PC端瀏覽器上支持較好，但是一些較低版本的移動端流覽器就不是那么理想了如圖：

由于Flv.js是基于MSE制作的，所以一些低版本移動端流覽器中是無法正常播放的，因此在考慮兼容性的情況下需要慎用。 關于WebRTC和音視頻會議 我們不難發現市場已經出現了一種新興的平臺 - Web視頻會議，用戶直接通過PC瀏覽器即可加入音視頻會議。

我們知道移動端的瀏覽器由于種類繁多并不能較好的適配，因此不被推薦直接在移動端瀏覽器中使用web視頻會議。

音視頻會議的思考

那讓我們從音視頻串流的角度來考慮，視頻會議就是讓傳統的單向直播變化為了雙向直播，即每個參與者即需要推流，也需要拉流。例如下圖，3位參會者，服務器就需要接受3條推流和6條拉流，顯然這樣對流媒體服務器的壓力過于龐大，并且還有不可忽視的延時問題。

大部分主流瀏覽器為開發者開放了可以開箱即用WebRTC - API，可以通過執行API就能呼叫指定的Peer并建立連接。但需要注意使用WebRTC技術雖然音視頻數據不經過服務端傳輸，但是仍然需要服務端去交換一些連接的必要信息。我們在開頭所說的兩款Web音視頻會議產品就是通過WebRTC實現的。

WebRTC技術的工作流

WebRTC更適合用來做Web視頻會議的原因就是它能夠實現瀏覽器和瀏覽器之間進行音視頻的傳輸

這其中的傳輸過程如圖。這里面的PeerN指的是連接的瀏覽器客戶端，在多個Peer連接之前，每個Peer需要和信令服務器（Signaling Server）進行連接，這里面提到的信令服務器需要由開發者自行搭建。 可以看到Peer與 信令服務器的連接是雙向的，這是因為連接的各方需要通過信令服務器交換一些關鍵信息，這些信息都會以信令的信息發送和接受。 Peer之間主要需要交換下面3種類型的信息

• 初始化和關閉通信，及報告錯誤；
• 用戶WebRTC的的IP和端口號
• 當前瀏覽器支持播放的音視頻編碼及封裝格式，以及能播放的最高分辨率等信息。

其中需要重點關注第二點，因為需要交換各個Peer之間的IP來進行Peer之間的連接，所以要保證Peer之間是要能夠正確訪問到對方ip的，如果所有的Peer都是在同一個局域網下沒有問題，但是如果參會的Peer來自不通的局域網，那么他們交換的IP是無法訪問到的。 所以在這里還需要增加一個借助另一種服務器（稱為STUN server）實現NAT/Firewall穿越。主要做的工作就是將用戶交換IP的過程中需要把根據局域網IP生成一個公網IP，這樣就實現了公網環境的傳輸。

最后

我們在文章中了解了Web傳統的音視頻串流、初窺了新興的WebRTC技術，這兩項技術能力其實也對應著兩種不同的應用場景。前者輔以CDN更符合面向觀眾的直播場景，后者適合中小型的音視頻會議的場景，短期來看WebRTC無法代替傳統音視頻串流。