1.一個可以忽略的前言

最近在做的一個項目，客戶要做一個直播平臺，主播發起視頻直播，然後其他人進入房間觀看這樣子，跟其他直播平臺不同的是，主播可以打賞觀眾,噗，不過這些千奇百怪的想法我也見怪不怪了，而且也不是技術難點所在。

因為客戶要做的是一個民宿的微信小程序，所以這個直播發起也是在微信小程序中完成的，好在後來查到微信小程序中有這種組件,之前想說用H5來做但是發現在移動端不同型號的兼容性問題非常不理想基本放棄了，

還有一種方式就是做個app了，但這就在我的知識範圍之外了，用webApp的話也沒找到這種采集攝像頭視頻的api，只找到發起攝像頭攝像的api，並且這樣就要脫離開微信小程序就跟客戶的要求不一致了。

2.直播流程

大概三步走，第一步，視頻采集端： 可以是電腦上的音視頻輸入設備、或手機端的攝像頭、或麥克風，今天的主題則是通過移動端手機視頻。

第二步，直播流視頻服務端：開通一個雲直播服務（比如 騰訊雲 ），或者自己搭建一個rtmp服務器（例如 nginx-rtmp 服務）。

采集視頻錄制端傳輸的視頻流(H264/ACC編碼)，由服務器端進行解析編碼，推送RTMP/HLS格式視頻流至視頻播放端。

第三步,視頻播放端：可以是電腦上的播放器（QuickTime Player、VLC），手機端的native播放器，還有就是 H5 的video標簽等

3.視頻流協議

一. 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 中的索引數，延時確實會減少，但會帶來更頻繁的緩沖，對服務端的請求壓力也會成倍增加。所以只能根據實際情況找到一個折中的點。

二. Real Time Messaging Protocol

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

雖然無法在iOS的H5頁面播放，但是對於iOS原生應用是可以自己寫解碼去解析的, RTMP 延遲低、實時性較好。瀏覽器端，HTML5 video