(轉)HLS協議，html5視頻直播一站式掃盲
本文來自於騰訊bugly開發者社區，原文地址：http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=1277
視頻直播這麽火，再不學就 out 了。
為了緊跟潮流，本文將向大家介紹一下視頻直播中的基本流程和主要的技術點，包括但不限於前端技術。
1. H5 到底能不能做視頻直播？
當然可以， H5 火了這麽久，涵蓋了各個方面的技術。
對於視頻錄制，可以使用強大的 webRTC（Web Real-Time Communication）是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，缺點是只在 PC 的 chrome 上支持較好，移動端支持不太理想。
對於視頻播放，可以使用 HLS(HTTP Live Streaming)協議播放直播流， ios 和 android 都天然支持這種協議，配置簡單，直接使用 video 標簽即可。
webRTC 兼容性：
video 標簽播放 hls 協議視頻：
<video controls autoplay> <source src="http://10.66.69.77:8080/hls/mystream.m3u8" type="application/vnd.apple.mpegurl" /> <p class="warning">Your browser does not support HTML5 video.</p> </video>
2. 到底什麽是 HLS 協議？
簡單講就是把整個流分成一個個小的，基於 HTTP 的文件來下載，每次只下載一些，前面提到了用於 H5 播放直播視頻時引入的一個 .m3u8 的文件，這個文件就是基於 HLS 協議，存放視頻流元數據的文件。
每一個 .m3u8 文件，分別對應若幹個 ts 文件，這些 ts 文件才是真正存放視頻的數據，m3u8 文件只是存放了一些 ts 文件的配置信息和相關路徑，當視頻播放時，.m3u8 是動態改變的，video 標簽會解析這個文件，並找到對應的 ts 文件來播放，所以一般為了加快速度，.m3u8 放在 web 服務器上，ts 文件放在 cdn 上。
.m3u8 文件，其實就是以 UTF-8 編碼的 m3u 文件，這個文件本身不能播放，只是存放了播放信息的文本文件：
#EXTM3U m3u文件頭
#EXT-X-MEDIA-SEQUENCE 第一個TS分片的序列號
#EXT-X-TARGETDURATION 每個分片TS的最大的時長
#EXT-X-ALLOW-CACHE 是否允許cache
#EXT-X-ENDLIST m3u8文件結束符
#EXTINF 指定每個媒體段(ts)的持續時間（秒），僅對其後面的URI有效
mystream-12.ts
ts 文件：
HLS 的請求流程是：
1 http 請求 m3u8 的 url。
2 服務端返回一個 m3u8 的播放列表，這個播放列表是實時更新的，一般一次給出5段數據的 url。
3 客戶端解析 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
4. 視頻直播的整個流程是什麽？
當視頻直播可大致分為：
1 視頻錄制端：一般是電腦上的音視頻輸入設備或者手機端的攝像頭或者麥克風，目前以移動端的手機視頻為主。
2 視頻播放端：可以是電腦上的播放器，手機端的 native 播放器，還有就是 h5 的 video 標簽等，目前還是已手機端的 native 播放器為主。
3 視頻服務器端：一般是一臺 nginx 服務器，用來接受視頻錄制端提供的視頻源，同時提供給視頻播放端流服務。
簡單流程：
5. 怎樣進行音視頻采集？
當首先明確幾個概念：
視頻編碼：所謂視頻編碼就是指通過特定的壓縮技術，將某個視頻格式的文件轉換成另一種視頻格式文件的方式，我們使用的 iphone 錄制的視頻，必須要經過編碼，上傳，解碼，才能真正的在用戶端的播放器裏播放。
編解碼標準：視頻流傳輸中最為重要的編解碼標準有國際電聯的H.261、H.263、H.264，其中 HLS 協議支持 H.264 格式的編碼。
音頻編碼：同視頻編碼類似，將原始的音頻流按照一定的標準進行編碼，上傳，解碼，同時在播放器裏播放，當然音頻也有許多編碼標準，例如 PCM 編碼，WMA 編碼，AAC 編碼等等，這裏我們 HLS 協議支持的音頻編碼方式是AAC編碼。
下面將利用 ios 上的攝像頭，進行音視頻的數據采集，主要分為以下幾個步驟：
1 音視頻的采集，ios 中，利用 AVCaptureSession和AVCaptureDevice 可以采集到原始的音視頻數據流。
2 對視頻進行 H264 編碼，對音頻進行 AAC 編碼，在 ios 中分別有已經封裝好的編碼庫來實現對音視頻的編碼。
3 對編碼後的音、視頻數據進行組裝封包；
4 建立 RTMP 連接並上推到服務端。
ps：由於編碼庫大多使用 c 語言編寫，需要自己使用時編譯，對於 ios，可以使用已經編譯好的編碼庫。
x264編碼：https://github.com/kewlbear/x264-ios
faac編碼：https://github.com/fflydev/faac-ios-build
ffmpeg編碼：https://github.com/kewlbear/FFmpeg-iOS-build-script
關於如果想給視頻增加一些特殊效果，例如增加濾鏡等，一般在編碼前給使用濾鏡庫，但是這樣也會造成一些耗時，導致上傳視頻數據有一定延時。
簡單流程：
6. 前面提到的 ffmpeg 是什麽？
和之前的 x264 一樣，ffmpeg 其實也是一套編碼庫，類似的還有 Xvid，Xvid 是基於 MPEG4 協議的編解碼器，x264是基於 H.264 協議的編碼器， ffmpeg 集合了各種音頻，視頻編解碼協議，通過設置參數可以完成基於 MPEG4,H.264 等協議的編解碼，demo 這裏使用的是 x264 編碼庫。
7. 什麽是 RTMP？
Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發的一套視頻直播協議，現在屬於 Adobe。和 HLS 一樣都可以應用於視頻直播，區別是 RTMP 基於 flash 無法在 ios 的瀏覽器裏播放，但是實時性比 HLS 要好。所以一般使用這種協議來上傳視頻流，也就是視頻流推送到服務器。
這裏列舉一下 hls 和 rtmp 對比：
8. 推流
簡所謂推流，就是將我們已經編碼好的音視頻數據發往視頻流服務器中，一般常用的是使用 rtmp 推流，可以使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 api 供使用者調用，如果覺得麻煩，可以使用現成的 ios 視頻推流sdk，也是基於 rtmp 的，https://github.com/runner365/LiveVideoCoreSDK
9. 推流服務器搭建
簡簡單的推流服務器搭建，由於我們上傳的視頻流都是基於 rtmp 協議的，所以服務器也必須要支持 rtmp 才行，大概需要以下幾個步驟：
1 安裝一臺 nginx 服務器。
2 安裝 nginx 的 rtmp 擴展，目前使用比較多的是https://github.com/arut/nginx-rtmp-module
3 配置 nginx 的 conf 文件：
rtmp {
server {
listen 1935; #監聽的端口
chunk_size 4000;
application hls { #rtmp推流請求路徑
live on;
hls on;
hls_path /usr/local/var/www/hls;
hls_fragment 5s;
}
}
}
4 重啟 nginx，將 rtmp 的推流地址寫為 rtmp://ip:1935/hls/mystream，其中 hls_path 表示生成的 .m3u8 和 ts 文件所存放的地址，hls_fragment 表示切片時長，mysteam 表示一個實例，即將來要生成的文件名可以先自己隨便設置一個。更多配置可以參考：https://github.com/arut/nginx-rtmp-module/wiki/
根據以上步驟基本上已經實現了一個支持 rtmp 的視頻服務器了。
10. 在 html5 頁面進行播放直播視頻？
簡單來說，直接使用 video 標簽即可播放 hls 協議的直播視頻：
<video autoplay webkit-playsinline>
<source src="http://10.66.69.77:8080/hls/mystream.m3u8" type="application/vnd.apple.mpegurl" />
<p class="warning">Your browser does not support HTML5 video.</p>
</video>
需要註意的是，給 video 標簽增加 webkit-playsinline 屬性，這個屬性是為了讓 video 視頻在 ios 的 uiwebview 裏面可以不全屏播放，默認 ios 會全屏播放視頻，需要給 uiwebview 設置 allowsInlineMediaPlayback＝YES。 業界比較成熟的 videojs，可以根據不同平臺選擇不同的策略，例如 ios 使用 video 標簽，pc 使用 flash 等。
11. 坑點總結
簡根據以上步驟，筆者寫了一個 demo，從實現 ios 視頻錄制，采集，上傳，nginx 服務器下發直播流，h5 頁面播放直播視頻者一整套流程，總結出以下幾點比較坑的地方：
1 在使用 AVCaptureSession 進行采集視頻時，需要實現 AVCaptureVideoDataOutputSampleBufferDelegate 協議，同時在- (void)captureOutput:(AVCaptureOutput )captureOutput didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer fromConnection:(AVCaptureConnection)connection 捕獲到視頻流，要註意的是 didOutputSampleBuffer 這個方法不是 didDropSampleBuffer 方法，後者只會觸發一次，當時開始寫的是 didDropSampleBuffer 方法，差了半天才發現方法調用錯了。
2 在使用 rtmp 推流時，rmtp 地址要以 rtmp:// 開頭，ip 地址要寫實際 ip 地址，不要寫成 localhost，同時要加上端口號，因為手機端上傳時是無法識別 localhos t的。
這裏後續會補充上一些坑點，有的需要貼代碼，這裏先列這麽多。
12. 業界支持
目前，騰訊雲，百度雲，阿裏雲都已經有了基於視頻直播的解決方案，從視頻錄制到視頻播放，推流，都有一系列的 sdk 可以使用，缺點就是需要收費，如果可以的話，自己實現一套也並不是難事哈。
demo地址：https://github.com/lvming6816077/LMVideoTest/
參考資料：http://www.nihaoshijie.com.cn/index.php/archives/615
更多精彩內容歡迎關註bugly的微信公眾賬號：
騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合並功能幫助開發同學把每天上報的數千條 Crash 根據根因合並分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同學定位到出問題的代碼行，實時上報可以在發布後快速的了解應用的質量情況，適配最新的 iOS, Android 官方操作系統，鵝廠的工程師都在使用，快來加入我們吧！
(轉)HLS協議，html5視頻直播一站式掃盲