1.HLS官網
閱讀本文前，也可以參考前面文章，手把手配置HLS流媒體服務器
如果想更全面了解HLS，參考官網地址:
https://developer.Apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/DeployingHTTPLiveStreaming/DeployingHTTPLiveStreaming.html
HLS官網界面
2.HLS數據流程框架
這個框架圖，在這篇文章里手把手配置HLS流媒體服務器，已經講解過了，這里就不再贅述了。貼上圖，溫故而知新。
這里詳細說說推流端、服務器端，拉流端是如何使用。基本的流程框架如下圖:
推流端涉及到采集、編碼、推流(FFmpeg、librtmp)等模塊。推流端框架可以參考前面這篇文章流媒體之推流拉流實戰之關鍵點優化分析(2)。
流媒體服務器一般需要做如下工作：
關于流媒體服務器搭建和基本認識，可以閱讀這篇文章，流媒體服務器架構與應用分析
手把手搭建流媒體服務器詳細步驟。
(1)協議轉換，將rtmp協議轉換為hls協議。
(2)封裝格式轉換，將flv的封裝格式要轉換為ts的封裝格式。
(3)如果要將推流視頻源轉碼(先解碼再編碼)，如把1080P的視頻轉碼為高清、標清等，就需要轉碼。注意：目前的技術還很少將標清轉換為1080P，這方面技術還不成熟，而且業務需求也不是很大。
(4)存儲轉換文件，如將ts文件存儲到web server(srs也是支持web服務器)，早期srs版本是用Nginx提供ts、m3u8載。
HLS拉流端拉流播放
拉流端一般涉及到音視頻解封裝，解碼，顯示等模塊。關于拉流端可以閱讀這幾篇文章。
流媒體之推流拉流實戰之關鍵點優化分析(2)
手把手配置HLS流媒體服務器
手把手搭建流媒體服務器詳細步驟
理解流媒體服務器和HLS拉流播放，需要注意如下幾點:
(1)m3u8、ts和拉流路數沒有關系。只要有新的ts文件，xxx.m3u8文件(由很多個ts文件構成)就會更新。
(2)在直播場景，最多緩存多少秒的ts文件，過期會刪除。
(3)在點播場景，不會刪除ts文件，是保存為整個點播節目。
3.詳解流媒體服務器(主要是直播場景)工作
流媒體服務器負責將輸?的?視頻媒體內容轉換成為適合于內容分發組件進?遞送的格式。對于視頻直播，流媒體服務器需要做如下工作。
（1）采集和編碼，編碼器?先將攝像機實時采集的?視頻數據壓縮編碼為符合特定標準的?視頻基本流(注意：?前蘋果的系統僅?持H.264視頻和AAC?頻)。
（2）TS封裝，復?和封裝成為符合MPEG-2系統層標準的傳輸流(TS)格式進?輸出。
（3）流分割器(Stream Segmenter)負責將編碼器輸出的MPEG-2 TS流分割為?系列連續的、?度均等的?TS?件(后綴名為.ts)，并依次發送?內容分發組件中的Web服務器進?存儲。
（4）同時，記錄分片的位置。為了跟蹤播放過程中媒體?件的可?性和當前位置，流分割器還需創建?個含有指向這些?TS?件指針的索引?件(就是前面文章提到的indexfile)，同樣放置于Web服務器之中。這個索引?件可以看作是?個連續媒體流中的播放列表滑動窗?，每當流分割器?成?個新的TS?件時，這個索引?件的內容也被更新，新的?件URI(統?資源定位符)加?到滑動窗?的末尾，?的?件URI則被移去，這樣索引?件中將始終包含最新的固定數量的x個分段(主要是在直播場景下)。流分割器還可以對其?成的每個?TS?件進?加密，并?成相應的密鑰?件。“滑動窗口”如下圖所示：
為什么要采用MPEG-2 TS格式對音視頻封裝呢？
因為它能夠將?視頻媒體流嚴格按時序進?交織復?，任意截取和分段后，每?個分段都可能不依賴于之前的分段?獨?進?解碼和播放。
TS?件中必須僅包含?個MPEG-2節?列表，在每個?件的開頭應包含?個節?關聯表(PAT)和?個節?映射表(PMT)，包含視頻的?件中還必須含有?少?個關鍵幀和其他?夠信息(如序列頭)?以完成解碼器的初始化。
什么是xxx.m3u8文件？
索引?件采?擴展的M3U播放列表格式，后綴名為.m3u8。M3U播放列表是?個由若??本?組成的?本?件，用于索引，其中每??要么是?個URI，?個空?，或者是?個以注釋符“#”起始的?。每個URI?指向?個分段的媒體?件，或者?個衍?的索引(播放列表)?件。后面的文章還會詳細說明m3u8的格式。
除了以“#EXT”起始的?是標簽?外，其他以“#”起始的?是注釋，應予忽略。下?是?個簡單的.m3u8索引?件例?，其所表示的媒體流由3個未加密的?度為10秒的TS?件組成。
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXTINF:10, 表示10s
http://media.example.com/segment1.ts
#EXTINF:10, 表示10s
http://media.example.com/segment2.ts
#EXTINF:10, 表示10s
http://media.example.com/segment3.ts
#EXT-X-ENDLIST
4.詳解流媒體服務器(主要是點播場景)工作
視頻點播，大部分工作類似直播，但有些部分，也有區別，如下：
（1）對 于 視 頻 點 播 ( V O D ) ， ? 件 分 割 器 ( F i l e Segmenter)?先將預編碼存儲的媒體?件轉碼為MPEG-2 TS格式?件(已經封裝為TS格式的?件則忽略這?步)。
(2)然后再將該TS?件分割成?系列?度均等的?TS?件。?件分割器同樣也?成?個含有指向這些??件指針的索引?件。
千萬注意：與直播型會話不同的是，這?的索引?件是?個不隨時間?更新的靜態?件，其中包含?個節?從頭到尾所有分段?件的URI列表(也就是分片并不會過期)，并以#EXT-X-ENDLIST標簽結尾。
在直播中，可以將一個直播事件轉換為點播(VOD)節目源，供以后點播。這時就可以不刪除已過期的分段媒體文件，同時在索引?件中也不刪除這些?件所對應的URI索引項，在直播結束的時候將#EXT-X-ENDLIST標簽添加?索引?件的末尾。
5.內容分發
怎樣把切片ts文件分發出去呢？
內容分發系統?于通過HTTP協議將分割后的?媒體?件及其索引?件遞送?客戶端播放器，它既可以是?個普通的Web服務器，也可以是?個Web緩存系統。?乎不需要對Web服務器做任何特殊的配置和增加其他定制的模塊。推薦的配置僅限于對.m3u8?件和.ts?件的MIME類型關聯，如表所示。
HTTP Live Streaming中建議的MIME類型
xxx.m3u8和xxx.ts文件的MIME類型如下表所示：
由于索引?件需要頻繁更新和下載，因此在Web cache的配置中有必要對.m3u8?件的TTL(time-to-live)值進?微調，以保證客戶端每次請求該?件時都能夠下載到它的最新版本。
6.拉流播放端
當播放器去拉取流媒體服務器的分片ts文件，詳細步驟如下:
(1)拉流端通過訪問Web??中的URL鏈接來獲取和下載?個流媒體會話的索引?件。這個索引?件進?步指定了服務器上當前可?的TS格式媒體?件、解密密鑰和其他替換流的位置。
(2)拉流端依次下載索引?件中列出的每?個可?媒體?件。當這些媒體?件緩沖夠?定數量后，客戶端將它們按順序重新拼裝成?個連貫的TS流，然后發送?播放器進?解碼和呈現。
(3)如果是加密媒體文件，需要根據索引?件的指引來獲取解密密鑰，提供?戶認證接?(服務端提供)，并按需進?解密。如果是視頻點播，則步驟(2)是反復進行，直到拉流端碰到索引?件中的#EXT-X-ENDLIST標簽。
(4)如果是視頻直播，索引?件中不存在#EXT-X-ENDLIST標簽，拉流端將周期性地向Web服務器重新請求獲取該索引?件的更新版本，然后在這個更新版的索引?件中查找新的媒體?件和解密密鑰，并將它們的URI添加?下載隊列的末尾。
注意：HTTP Live Streaming并不是?個真正實時的流媒體系統，這是因為對應于媒體分段的??和持續時間有?定潛在的時間延遲。在拉流端，至少在?個分段媒體?件被完全下載之后才能夠開始播放，即先下載，后才能播放，延時必定大。在實際項目設計中，通常要求下載完成兩個分段媒體?件(這也會增加延遲)之后才開始播放以保證不同分段?視頻之間的?縫連接。
在拉流端開始下載之前，必須等待服務器端的編碼器和流分割器?少?成?個TS?件，這也會帶來潛在的時延。
在推薦配置下，HTTP Live Streaming系統的典型時延約在30s左右(這是一個參考值，不適合延時大的場景)。
7.?絡?適應的流間切換和故障保護
前面文章提到過，在基于HTTP Live Streaming的流媒體系統中，服務器可以為同?節?源準備多份以不同碼率和質量編碼的替換流，并為每個替換流都?成?個衍?的索引?件。在主索引?件中通過包含?系列指向其他衍?索引?件的URI指針來找到相應的替換流，如下圖所示。
在移動互聯?環境下，由于?絡覆蓋?的不同和信號強弱的變化，移動終端可能隨時在不同的?線接??絡(例如3G，EDGE，GPRS和WiFi等)之間進?切換。此時客戶端軟件可根據?絡和帶寬的變化情況隨時切換到不同衍?索引?件所指向的替換流進?下載，從??適應地為?戶提供相應?絡條件下接近最優的?視頻QoS體驗。上述替換流和衍?索引?件機制除了可以?于基于帶寬波動的動態流間切換外，還可以?于服務器的故障保護。
服務器故障保護
(1)?先在?臺服務器上按照正常流程?成?個媒體流或者多個替換流，以及對應的索引?件，
(2)然后再在另?臺服務器上?成?套并?的備份媒體流和索引?件。
(3)將指向備份流的索引加?到主索引?件之中，使得其中針對每個帶寬值都對應有?個主媒體流和?個備份媒體流。
如，假定主服務器和備份服務器分別為ALPHA和BETA，則主索引?件中的內容可能如下所示：
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000
http://ALPHA.example.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000
http://BETA.example.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000
http://ALPHA.example.com/md/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000
http://BETA.example.com/md/prog_index.m3u8
在上述例?中，當客戶端連接主服務器ALPHA失敗時，它將試圖連接備份服務器BETA，從中獲取最?帶寬值替換流所對應的衍?索引?件，并進?步根據該索引?件下載相應的替換媒體流?件。
相對于常?的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播協議最?的不同在于，直播客戶端獲取到的，并不是?個完整的數據流。HLS協議在服務器端將直播數據流存儲為連續的、很短時?的媒體?件（MPEG-TS格式），而拉流端則不斷的下載并播放這些??件，因為服務器端總是會將最新的直播數據?成新的??件，這樣拉流端只要不停的按順序播放從服務器獲取到的?件，就實現了直播。由此可?，基本上可以認為，HLS是以點播的技術?式來實現直播。
由于數據通過HTTP協議傳輸，所以完全不?考慮防?墻或者代理的問題，?且分段?件的時?很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。
優點：HLS能夠快速切換不同碼率，適應不同帶寬。
缺點：它的延遲?般總是會遠遠?于普通的流媒體直播協議。
8.研究關鍵技術點
還有以下關鍵技術點，有待研究，在這里先提出來，在后面的文章會繼續寫。
(1)采集視頻源和?頻源的數據。
(2)對原始數據進?H264編碼和AAC編碼。
(3)視頻和?頻數據封裝為MPEG-TS包。
(4)HLS分段?成策略及m3u8索引?件。
(5)HTTP傳輸協議。
9.測試說明
經過測試，不同播放器拉取同一份xxx.m3u8文件，延時差別很大，說明播放器策略不一樣。延時差別如下圖:
FFplay拉流的延時是最大。為什么會這樣呢？
對于FFplay，拉取到m3u8文件，從第一個ts文件開始去播放。而對于srs播放器，不是從第一個ts文件播放，一般是播最后2個ts文件，所以這樣會更快。知道其中的原因，以后設計播放器，就便于去優化。
本篇文章就分析到這里，歡迎大家關注歡迎關注，點贊，轉發，收藏，分享，評論區討論。
后面關于項目知識，后期會更新。歡迎關注微信公眾號"記錄世界 from antonio"。
