內容原貼出自：http://www.lxweimin.com/p/e516a5b31480
首先說下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
HLS 的請求流程是：
http 請求 m3u8 的 url。
服務端返回一個 m3u8 的播放列表，這個播放列表是實時更新的，一般一次給出5段數據的 url。
客戶端解析 m3u8 的播放列表，再按序請求每一段的 url，獲取 ts 數據流。
Paste_Image.png
關于HLS延遲原因：
hls 協議是將直播流分成一段一段的小段視頻去下載播放的，所以假設列表里面的包含5個 ts 文件，每個 TS 文件包含5秒的視頻內容，那么整體的延遲就是25秒。因為當你看到這些視頻時，主播已經將視頻錄制好上傳上去了，所以時這樣產生的延遲。當然可以縮短列表的長度和單個 ts 文件的大小來降低延遲，極致來說可以縮減列表長度為1，并且 ts 的時長為1s，但是這樣會造成請求次數增加，增大服務器壓力，當網速慢時回造成更多的緩沖，所以蘋果官方推薦的ts時長時10s，所以這樣就會大改有30s的延遲
視頻直播的整個流程：
視頻錄制端：一般是電腦上的音視頻輸入設備或者手機端的攝像頭或者麥克風，目前以移動端的手機視頻為主。
視頻播放端：可以是電腦上的播放器，手機端的 native 播放器。
視頻服務器端：一般是一臺 nginx 服務器，用來接受視頻錄制端提供的視頻源，同時提供給視頻播放端流服務。
簡單流程
Paste_Image.png
數據采集原理：
下面將利用 ios 上的攝像頭，進行音視頻的數據采集，主要分為以下幾個步驟：
音視頻的采集，ios 中，利用 AVCaptureSession和AVCaptureDevice 可以采集到原始的音視頻數據流。
對視頻進行 H264 編碼，對音頻進行 AAC 編碼，在 ios 中分別有已經封裝好的編碼庫來實現對音視頻的編碼。
對編碼后的音、視頻數據進行組裝封包；
建立 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（操作同上）
關于如果想給視頻增加一些特殊效果，例如增加濾鏡等，一般在編碼前給使用濾鏡庫，但是這樣也會造成一些耗時，導致上傳視頻數據有一定延時。
RTMP介紹：
Real Time Messaging Protocol（簡稱 RTMP）是 Macromedia 開發的一套視頻直播協議。和 HLS 一樣都可以應用于視頻直播，區別是 RTMP 基于 flash 無法在 ios 的瀏覽器里播放，但是實時性比 HLS 要好。所以一般使用這種協議來上傳視頻流，也就是視頻流推送到服務器。
對比：
RTMP 首先就是延遲低，基于TCP的長鏈接，對于數據處理及時，收到即刻發送，推薦使用場景：即時互動。
HLS 延遲高，短鏈接，原理是集合了一段時間的視頻數據，切割ts片，逐個下載播放。優點是跨平臺。
推流：
推流，就是將我們已經編碼好的音視頻數據發往視頻流服務器中，一般常用的是使用 rtmp 推流，可以使用第三方庫 librtmp-iOS 進行推流，librtmp 封裝了一些核心的 api 供使用者調用，如果覺得麻煩，可以使用現成的 ios 視頻推流sdk，也是基于 rtmp 的。具體說下：
也就是對編碼好的音視頻數據推到服務器上，這里我們又分為兩類推流模式：手機端推流，服務器本地推流。就拿我上一家公司的電視直播來說，視頻源是來自電視臺的，需要通過ffmpeg命令來進行個推流，那么推流協議的話這里又分為了：HLS推流和rtmp推流，這里的取舍主要涉及到了是否需要及其實時的直播問題，也就是延遲20 30s是否接受，當然電視直播并不是主播實時互動，所以不需要使用實時流媒體協議的rtmp，所以通過ffmpeg -loglevel 這么一個命令將電視臺給的視頻進行各像nginx服務器的一個推流，那么我們就可以通過nginx服務器給的鏈接，配合我的第三方的直播框架，就可以實現個直播，這個是服務器本地的HLS協議的一個推流。當然如果我們要做一個沒有延遲的比如實現各主播互動的一個直播，那么就是iOS客戶端用rtmp協議的一個往nginx服務器的一個推流了。在iOS設備上進行各推流的話，是通過AVCaptureSession這么一個捕捉會話，指定兩個AVCaptureDevice 也就是iOS的攝像頭和麥克風，獲取個原始視頻和音頻，然后需要進行個H.264的視頻編碼和AAC的音頻編碼，再將編碼后的數據整合成一個音視頻包，通過rmtp推送到nginx服務器。這里這些步驟，我們可以通過各第三方集成好的推流工具進行推流，這個工具有librtmp，和騰訊的GDLiveStreaming進行個推流。
