提醒：本文最後更新於 776 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

前不久工作中遇到了在移動 WEB 端直播視訊的需求，研究了一下相關技術，記錄一下。

目前 WEB 上主流的視訊直播方案有 HLS 和 RTMP，移動 WEB 端目前就只有 HLS 能用，我們重點介紹它。

update @ 2016.11.25，本文寫於一年半前，如今有一個可以用於移動端的 FLV 方案，非常不錯，推薦大家關注。詳見：https://github.com/Bilibili/flv.js

HTTP Live Streaming

HTTP Live Streaming（簡稱 HLS）是一個基於 HTTP 的視訊流協議，由 Apple 公司實現，Mac OS 上的 QuickTime、Safari 以及 iOS 上的 Safari 都能很好的支援 HLS，高版本 Android 也增加了對 HLS 的支援。一些常見的客戶端如：MPlayerX、VLC 也都支援 HLS 協議。

HLS 協議基於 HTTP，非常簡單。一個提供 HLS 的伺服器需要做兩件事：

• 編碼：以 H.263 格式對影象進行編碼，以 MP3 或者 HE-AAC 對聲音進行編碼，最終打包到 MPEG-2 TS（Transport Stream）容器之中；
• 分割：把編碼好的 TS 檔案等長切分成字尾為 ts 的小檔案，並生成一個 .m3u8 的純文字索引檔案；

瀏覽器使用的是 m3u8 檔案。m3u8 跟音訊列表格式 m3u 很像，可以簡單的認為 m3u8 就是包含多個 ts 檔案的播放列表。播放器按順序逐個播放，全部放完再請求一下 m3u8 檔案，獲得包含最新 ts 檔案的播放列表繼續播，周而復始。整個直播過程就是依靠一個不斷更新的 m3u8 和一堆小的 ts 檔案組成，m3u8 必須動態更新，ts 可以走 CDN。一個典型的 m3u8 檔案格式如下：

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000
gear1/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=311111
gear2/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=484444
gear3/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=737777
gear4/prog_index.m3u8

可以看到 HLS 協議本質還是一個個的 HTTP 請求 / 響應，所以適應性很好，不會受到防火牆影響。但它也有一個致命的弱點：延遲現象非常明顯。如果每個 ts 按照 5 秒來切分，一個 m3u8 放 6 個 ts 索引，那麼至少就會帶來 30 秒的延遲。如果減少每個 ts 的長度，減少 m3u8 中的索引數，延時確實會減少，但會帶來更頻繁的緩衝，對服務端的請求壓力也會成倍增加。所以只能根據實際情況找到一個折中的點。

對於支援 HLS 的瀏覽器來說，直接這樣寫就能播放了：

<video src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"
height="300" width="400"></video>

對於不支援 m3u8 的瀏覽器，比如 PC / Mac 上的 Chrome，需要藉助 Flash 來實現了。網上有一些較為成熟的方案可以直接用，如：Sewise Player（免費）、JW Player（收費）。

Real Time Messaging Protocol

Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發的一套視訊直播協議，現在屬於 Adobe。這套方案需要搭建專門的 RTMP 流媒體服務如 Adobe Media Server，並且在瀏覽器中只能使用 Flash 實現播放器。它的實時性非常好，延遲很小，但無法支援移動端 WEB 播放是它的硬傷。

前面提到的 JW Player 能很好的播放採用 RTMP 協議的直播服務。

這次先寫這麼多，下一篇寫一個另類的直播方案。

--EOF--

發表於 2015-04-24 01:13:11 ，並被新增「 HTML5 、 Video 」標籤 ，最後修改於 2016-11-25 21:36:23 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 776 天前，文中所描述的資訊可能已發生改變，請謹慎使用。