（轉(zhuǎn)帖著名出處：謝謝！）
首先說下HLS協(xié)議：
簡單講就是把整個流分成一個個小的，基于 HTTP 的文件來下載，每次只下載一些，前面提到了用于 H5 播放直播視頻時引入的一個 .m3u8 的文件，這個文件就是基于 HLS 協(xié)議，存放視頻流元數(shù)據(jù)的文件。
每一個 .m3u8 文件，分別對應(yīng)若干個 ts 文件，這些 ts 文件才是真正存放視頻的數(shù)據(jù)，m3u8 文件只是存放了一些 ts 文件的配置信息和相關(guān)路徑，當視頻播放時，.m3u8 是動態(tài)改變的，video 標簽會解析這個文件，并找到對應(yīng)的 ts 文件來播放，所以一般為了加快速度，.m3u8 放在 web 服務(wù)器上，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文件結(jié)束符
#EXTINF 指定每個媒體段(ts)的持續(xù)時間（秒），僅對其后面的URI有效mystream-12.ts
HLS 的請求流程是：
- http 請求 m3u8 的 url。
- 服務(wù)端返回一個 m3u8 的播放列表，這個播放列表是實時更新的，一般一次給出5段數(shù)據(jù)的 url。
- 客戶端解析 m3u8 的播放列表，再按序請求每一段的 url，獲取 ts 數(shù)據(jù)流。
關(guān)于HLS延遲原因：
hls 協(xié)議是將直播流分成一段一段的小段視頻去下載播放的，所以假設(shè)列表里面的包含5個 ts 文件，每個 TS 文件包含5秒的視頻內(nèi)容，那么整體的延遲就是25秒。因為當你看到這些視頻時，主播已經(jīng)將視頻錄制好上傳上去了，所以時這樣產(chǎn)生的延遲。當然可以縮短列表的長度和單個 ts 文件的大小來降低延遲，極致來說可以縮減列表長度為1，并且 ts 的時長為1s，但是這樣會造成請求次數(shù)增加，增大服務(wù)器壓力，當網(wǎng)速慢時回造成更多的緩沖，所以蘋果官方推薦的ts時長時10s，所以這樣就會大改有30s的延遲
視頻直播的整個流程：
視頻錄制端：一般是電腦上的音視頻輸入設(shè)備或者手機端的攝像頭或者麥克風，目前以移動端的手機視頻為主。
視頻播放端：可以是電腦上的播放器，手機端的 native 播放器。
視頻服務(wù)器端：一般是一臺 nginx 服務(wù)器，用來接受視頻錄制端提供的視頻源，同時提供給視頻播放端流服務(wù)。
簡單流程
數(shù)據(jù)采集原理：
下面將利用 ios 上的攝像頭，進行音視頻的數(shù)據(jù)采集，主要分為以下幾個步驟：
- 音視頻的采集，ios 中，利用 AVCaptureSession和AVCaptureDevice 可以采集到原始的音視頻數(shù)據(jù)流。
- 對視頻進行 H264 編碼，對音頻進行 AAC 編碼，在 ios 中分別有已經(jīng)封裝好的編碼庫來實現(xiàn)對音視頻的編碼。
- 對編碼后的音、視頻數(shù)據(jù)進行組裝封包；
- 建立 RTMP 連接并上推到服務(wù)端。
ps：由于編碼庫大多使用 c 語言編寫，需要自己使用時編譯，對于 ios，可以使用已經(jīng)編譯好的編碼庫。
x264編碼：https://github.com/kewlbear/x264-ios（復(fù)制此鏈接到瀏覽器打開）
faac編碼：https://github.com/fflydev/faac-ios-build（操作同上）
ffmpeg編碼：https://github.com/kewlbear/FFmpeg-iOS-build-script（操作同上）
關(guān)于如果想給視頻增加一些特殊效果，例如增加濾鏡等，一般在編碼前給使用濾鏡庫，但是這樣也會造成一些耗時，導(dǎo)致上傳視頻數(shù)據(jù)有一定延時。
RTMP介紹：
Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發(fā)的一套視頻直播協(xié)議。和 HLS 一樣都可以應(yīng)用于視頻直播，區(qū)別是 RTMP 基于 flash 無法在 ios 的瀏覽器里播放，但是實時性比 HLS 要好。所以一般使用這種協(xié)議來上傳視頻流，也就是視頻流推送到服務(wù)器。
對比：
- RTMP 首先就是延遲低，基于TCP的長鏈接，對于數(shù)據(jù)處理及時，收到即刻發(fā)送，推薦使用場景：即時互動。
- HLS 延遲高，短鏈接，原理是集合了一段時間的視頻數(shù)據(jù)，切割ts片，逐個下載播放。優(yōu)點是跨平臺。
推流：
推流，就是將我們已經(jīng)編碼好的音視頻數(shù)據(jù)發(fā)往視頻流服務(wù)器中，一般常用的是使用 rtmp 推流，可以使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 api 供使用者調(diào)用，如果覺得麻煩，可以使用現(xiàn)成的 ios 視頻推流sdk，也是基于 rtmp 的。具體說下：
也就是對編碼好的音視頻數(shù)據(jù)推到服務(wù)器上，這里我們又分為兩類推流模式：手機端推流，服務(wù)器本地推流。就拿我上一家公司的電視直播來說，視頻源是來自電視臺的，需要通過ffmpeg命令來進行個推流，那么推流協(xié)議的話這里又分為了：HLS推流和rtmp推流，這里的取舍主要涉及到了是否需要及其實時的直播問題，也就是延遲20 30s是否接受，當然電視直播并不是主播實時互動，所以不需要使用實時流媒體協(xié)議的rtmp，所以通過ffmpeg -loglevel 這么一個命令將電視臺給的視頻進行各像nginx服務(wù)器的一個推流，那么我們就可以通過nginx服務(wù)器給的鏈接，配合我的第三方的直播框架，就可以實現(xiàn)個直播，這個是服務(wù)器本地的HLS協(xié)議的一個推流。當然如果我們要做一個沒有延遲的比如實現(xiàn)各主播互動的一個直播，那么就是iOS客戶端用rtmp協(xié)議的一個往nginx服務(wù)器的一個推流了。在iOS設(shè)備上進行各推流的話，是通過AVCaptureSession這么一個捕捉會話，指定兩個AVCaptureDevice 也就是iOS的攝像頭和麥克風，獲取個原始視頻和音頻，然后需要進行個H.264的視頻編碼和AAC的音頻編碼，再將編碼后的數(shù)據(jù)整合成一個音視頻包，通過rmtp推送到nginx服務(wù)器。這里這些步驟，我們可以通過各第三方集成好的推流工具進行推流，這個工具有l(wèi)ibrtmp，和騰訊的GDLiveStreaming進行個推流。
