HTML5視頻直播技術

分享內容簡介：
目前視頻直播，尤其是移動端的視頻直播已經火到不行了，基本上各大互聯網公司都有了自己的直播產品，所以對于直播的一些基本知識和主要技術點也要有所了解，本次分享就向大家介紹一下其中的奧秘。

內容大體框架:

1. 怎樣利用 HTML5 來播放直播視頻
2. 怎樣錄制直播視頻
3. 怎樣實時上傳直播視頻
4. 直播中的用戶交互

下面是本期分享內容整理

Hello, 大家好，我是呂鳴，目前是在騰訊 SNG 的即通應用部負責手Q的興趣部落 Web 前端開發工作。

針對目前比較火的視頻直播，我做了一些研究和探索，同時我們的項目將會用到直播為此打下技術基礎，下面就向大家分享一下直播的整個流程和一些技術點。
一、移動視頻直播發展

大家首先來看下面這張圖:

可以看到，直播從 PC 到一直發展到移動端，越來越多的直播類 App 上線，同時移動直播進入了前所未有的爆發階段，但是對于大多數移動直播來說，還是要以 Native 客戶端實現為主，但是 HTML5 在移動直播端也承載著不可替代的作用，例如 HTML5 有著傳播快，易發布的優勢，同時最為關鍵的時 HTML5 同樣可以播放直播視頻。

大家可以看下面這張大概的實現圖

完整的直播可以分為以下幾塊：

視頻錄制端：一般是電腦上的音視頻輸入設備或者手機端的攝像頭或者麥克風，目前以移動端的手機視頻為主。
視頻播放端：可以是電腦上的播放器，手機端的 Native 播放器，還有就是 HTML5 的 video 標簽等，目前還是已手機端的 Native 播放器為主。
視頻服務器端：一般是一臺 nginx 服務器，用來接受視頻錄制端提供的視頻源，同時提供給視頻播放端流服務。

大家可以看下大致的結構圖：

二、HTML5 錄制視頻：

對于HTML5視頻錄制，可以使用強大的 webRTC （Web Real-Time Communication）是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，缺點是只在 PC 的 Chrome 上支持較好，移動端支持不太理想。

使用 webRTC 錄制視頻基本流程是：

調用 window.navigator.webkitGetUserMedia() 獲取用戶的PC攝像頭視頻數據。
將獲取到視頻流數據轉換成 window.webkitRTCPeerConnection (一種視頻流數據格式)。
利用 webscoket 將視頻流數據傳輸到服務端

由于許多方法都要加上瀏覽器前綴，所以很多移動端的瀏覽器還不支持 webRTC，所以真正的視頻錄制還是要靠客戶端（iOS,Android）來實現,效果會好一些。
三、HTML5 播放直播視頻：

對于視頻播放，可以使用 HLS(HTTP Live Streaming)協議播放直播流，iOS和 Android 都天然支持這種協議，配置簡單，直接使用 video 標簽即可。

下面是簡單的代碼使用 video 播放直播視頻：

1.什么是 HLS 協議:

簡單講就是把整個流分成一個個小的，基于 HTTP 的文件來下載，每次只下載一些，前面提到了用于 HTML5 播放直播視頻時引入的一個 .m3u8 的文件，這個文件就是基于 HLS 協議，存放視頻流元數據的文件。

每一個 .m3u8 文件，分別對應若干個 ts 文件，這些 ts 文件才是真正存放視頻的數據，m3u8 文件只是存放了一些 ts 文件的配置信息和相關路徑，當視頻播放時，.m3u8 是動態改變的，video 標簽會解析這個文件，并找到對應的 ts 文件來播放，所以一般為了加快速度，.m3u8 放在 Web 服務器上，ts 文件放在 CDN 上。

.m3u8 文件，其實就是以 UTF-8 編碼的 m3u 文件，這個文件本身不能播放，只是存放了播放信息的文本文件。

打開之后就是這個樣子：

下面這個是 ts 文件，就是存放視頻的文件：

2.HLS 的請求流程：

HTTP 請求 m3u8 的 url。
服務端返回一個 m3u8 的播放列表，這個播放列表是實時更新的，一般一次給出5段數據的 url。
客戶端解析 m3u8 的播放列表，再按序請求每一段的 url，獲取 ts 數據流。

大概是這個流程：

3.HLS 直播延時:

我們知道 hls 協議是將直播流分成一段一段的小段視頻去下載播放的，所以假設列表里面的包含5個 ts 文件，每個 TS 文件包含5秒的視頻內容，那么整體的延遲就是25秒。因為當你看到這些視頻時，主播已經將視頻錄制好上傳上去了，所以時這樣產生的延遲。當然可以縮短列表的長度和單個 ts 文件的大小來降低延遲，極致來說可以縮減列表長度為1，并且 ts 的時長為1s，但是這樣會造成請求次數增加，增大服務器壓力，當網速慢時回造成更多的緩沖，所以蘋果官方推薦的 ts 時長時10s，所以這樣就會大改有30s的延遲。所以服務器接收流，轉碼，保存，切塊，再分發給客戶端，這里就延時的根本原因。

更多關于延遲的問題可以參考蘋果官方地址：
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html

但是 HTML5 直播視頻卻有一些不可替代的優勢:

傳播性好，利于分享等操作。
可以動態發布，有利于實時迭代產品需求并迅速上線。
不用安裝 App，直接打開瀏覽器即可。

四、iOS 采集（錄制）音視頻數據OS

關于音視頻采集錄制，首先明確下面幾個概念：

視頻編碼：所謂視頻編碼就是指通過特定的壓縮技術，將某個視頻格式的文件轉換成另一種視頻格式文件的方式，我們使用的 iPhone 錄制的視頻，必須要經過編碼，上傳，解碼，才能真正的在用戶端的播放器里播放。
編解碼標準：視頻流傳輸中最為重要的編解碼標準有國際電聯的 H.261、H.263、H.264，其中 HLS 協議支持 H.264 格式的編碼。
音頻編碼：同視頻編碼類似，將原始的音頻流按照一定的標準進行編碼，上傳，解碼，同時在播放器里播放，當然音頻也有許多編碼標準，例如 PCM 編碼，WMA 編碼，AAC 編碼等等，這里我們 HLS 協議支持的音頻編碼方式是 AAC 編碼。

利用 iOS 上的攝像頭，進行音視頻的數據采集，主要分為以下幾個步驟：

音視頻的采集，iOS 中，利用 AVCaptureSession 和 AVCaptureDevice 可以采集到原始的音視頻數據流。
對視頻進行 H264 編碼，對音頻進行 AAC 編碼，在 iOS 中分別有已經封裝好的編碼庫來實現對音視頻的編碼。
對編碼后的音、視頻數據進行組裝封包；
建立 RTMP 連接并上推到服務端。

下面是具體的采集音視頻數據的流程：

1.關于 RTMP：

Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發的一套視頻直播協議，現在屬于 Adobe。和 HLS 一樣都可以應用于視頻直播，區別是 RTMP 基于 flash 無法在 iOS 的瀏覽器里播放，但是實時性比 HLS 要好。所以一般使用這種協議來上傳視頻流，也就是視頻流推送到服務器。

下面是 HLS 和 RTMP 的對比：

2.推流

所謂推流，就是將我們已經編碼好的音視頻數據發往視頻流服務器中，在 iOS 代碼里面一般常用的是使用 RTMP 推流，可以使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 API 供使用者調用。例如推流 API 等等，配置服務器地址，即可將轉碼后的視頻流推往服務器。

那么如何搭建一個推流服務器呢？

簡單的推流服務器搭建，由于我們上傳的視頻流都是基于 RTMP 協議的，所以服務器也必須要支持 RTMP 才行，大概需要以下幾個步驟：

安裝一臺 nginx 服務器。
安裝 nginx 的 RTMP 擴展，目前使用比較多的是 https://github.com/arut/nginx-rtmp-module
配置 nginx 的 conf 文件
重啟 nginx，將 RTMP 的推流地址寫為 rtmp://ip:1935/hls/mystream， 其中 hls_path 表示生成的 .m3u8 和 ts 文件所存放的地址，hls_fragment 表示切片時長，mysteam 表示一個實例，即將來要生成的文件名可以先自己隨便設置一個。

更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/

下面是 nginx 的配置文件

五、直播中的用戶交互：

對于直播中的用戶交互大致可以分為：

送禮物
發表評論或者彈幕

對于送禮物，在 HTML5 端可以利用 DOM 和 CSS3 實現送禮物邏輯和一些特殊的禮物動畫，實現技術難點不大。

對于彈幕來說，要稍微復雜一些，可能需要關注以下幾點：

彈幕實時性，可以利用 webscoket 來實時發送和接收新的彈幕并渲染出來。
對于不支持 webscoket 的瀏覽器來說，只能降級為長輪詢或者前端定時器發送請求來獲取實時彈幕。
彈幕渲染時的動畫和碰撞檢測(即彈幕不重疊)等等

六、總結

目前較為成熟的直播產品，大致都是以 Server 端和 HTML5 和 Native(android,ios)搭配實現直播：

基本是下圖這個套路：

所以 HTML5 在整個直播中，還是有著重要的地位的！