HLS，Http Live Streaming 是由Apple公司定義的用于實時流傳輸的協議，HLS基于HTTP協議實現，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。

1、M3U8文件

   用文本方式對媒體文件進行描述，由一系列標簽組成。

#EXTM3U

#EXT-X-TARGETDURATION:5

#EXTINF:5,

./0.ts

#EXTINF:5,

./1.ts

#EXTM3U：每個M3U8文件第一行必須是這個tag。

#EXT-X-TARGETDURATION：指定最大的媒體段時間長度（秒），#EXTINF中指定的時間長度必須小于或等于這個最大值。該值只能出現一次。

#EXTINF：描述單個媒體文件的長度。后面為媒體文件，如./0.ts 

2、ts文件

    ts文件為傳輸流文件，視頻編碼主要格式h264/mpeg4，音頻為acc/MP3。

   ts文件分為三層：ts層Transport Stream、pes層 Packet Elemental Stream、es層 Elementary Stream. es層就是音視頻數據，pes層是在音視頻數據上加了時間戳等對數據幀的說明信息，ts層就是在pes層加入數據流的識別和傳輸必須的信息

注： 詳解如下

 （1）ts層     ts包大小固定為188字節，ts層分為三個部分：ts header、adaptation field、payload。ts header固定4個字節；adaptation field可能存在也可能不存在，主要作用是給不足188字節的數據做填充；payload是pes數據。

ts header

     ts層的內容是通過PID值來標識的，主要內容包括：PAT表、PMT表、音頻流、視頻流。解析ts流要先找到PAT表，只要找到PAT就可以找到PMT，然后就可以找到音視頻流了。PAT表的PID值固定為0。PAT表和PMT表需要定期插入ts流，因為用戶隨時可能加入ts流，這個間隔比較小，通常每隔幾個視頻幀就要加入PAT和PMT。PAT和PMT表是必須的，還可以加入其它表如SDT（業務描述表）等，不過hls流只要有PAT和PMT就可以播放了。

PAT表：他主要的作用就是指明了PMT表的PID值。

PMT表：他主要的作用就是指明了音視頻流的PID值。

音頻流/視頻流：承載音視頻內容。

adaption

     自適應區的長度要包含傳輸錯誤指示符標識的一個字節。pcr是節目時鐘參考，pcr、dts、pts都是對同一個系統時鐘的采樣值，pcr是遞增的，因此可以將其設置為dts值，音頻數據不需要pcr。如果沒有字段，ipad是可以播放的，但vlc無法播放。打包ts流時PAT和PMT表是沒有adaptation field的，不夠的長度直接補0xff即可。視頻流和音頻流都需要加adaptation field，通常加在一個幀的第一個ts包和最后一個ts包里，中間的ts包不加。

PAT格式

PMT格式

（2）pes層

     pes層是在每一個視頻/音頻幀上加入了時間戳等信息，pes包內容很多，我們只留下最常用的。

     pts是顯示時間戳、dts是解碼時間戳，視頻數據兩種時間戳都需要，音頻數據的pts和dts相同，所以只需要pts。有pts和dts兩種時間戳是B幀引起的，I幀和P幀的pts等于dts。如果一個視頻沒有B幀，則pts永遠和dts相同。從文件中順序讀取視頻幀，取出的幀順序和dts順序相同。dts算法比較簡單，初始值 + 增量即可，pts計算比較復雜，需要在dts的基礎上加偏移量。

     音頻的pes中只有pts（同dts），視頻的I、P幀兩種時間戳都要有，視頻B幀只要pts（同dts）。打包pts和dts就需要知道視頻幀類型，但是通過容器格式我們是無法判斷幀類型的，必須解析h.264內容才可以獲取幀類型。

舉例說明：

                         I          P          B          B          B          P

讀取順序：         1         2          3          4          5          6

dts順序：           1         2          3          4          5          6

pts順序：           1         5          3          2          4          6

點播視頻dts算法：

dts = 初始值 + 90000 / video_frame_rate，初始值可以隨便指定，但是最好不要取0，video_frame_rate就是幀率，比如23、30。

pts和dts是以timescale為單位的，1s = 90000 time scale , 一幀就應該是90000/video_frame_rate 個timescale。

用一幀的timescale除以采樣頻率就可以轉換為一幀的播放時長

點播音頻dts算法：

dts = 初始值 + (90000 * audio_samples_per_frame) / audio_sample_rate，audio_samples_per_frame這個值與編解碼相關，aac取值1024，mp3取值1158，audio_sample_rate是采樣率，比如24000、41000。AAC一幀解碼出來是每聲道1024個sample，也就是說一幀的時長為1024/sample_rate秒。所以每一幀時間戳依次0，1024/sample_rate，...，1024*n/sample_rate秒。

直播視頻的dts和pts應該直接用直播數據流中的時間，不應該按公式計算。

（3）es層

     es層指的就是音視頻數據，我們只介紹h.264視頻和aac音頻。

h.264視頻：

     打包h.264數據我們必須給視頻數據加上一個nalu（Network Abstraction Layer unit），nalu包括nalu header和nalu type，nalu header固定為0x00000001（幀開始）或0x000001（幀中）。h.264的數據是由slice組成的，slice的內容包括：視頻、sps、pps等。nalu type決定了后面的h.264數據內容。

     紅色字體顯示的內容是最常用的，打包es層數據時pes頭和es數據之間要加入一個type=9的nalu，關鍵幀slice前必須要加入type=7和type=8的nalu，而且是緊鄰。

轉自：http://my.oschina.NET/u/727148/blog/666824

M3U8的簡單介紹和在Android中使用的思路

 (在項目中有用到m3u8，現在寫篇博文，算是簡單的總結

首先是名詞介紹，什么是m3u8。m3u8是m3u的一種，不過是utf-8格式的，我記憶中說m3u8是蘋果公司搞出來的一種播放的標準吧，其實簡單來說就是把整個視頻切成一段一段的，然后呢用一個m3u8格式來存這些個小段視頻們的地址。可能大家就要問了，這么麻煩干嘛。其實m3u8是為了碼率適配而生，而怎樣去適配碼率呢，這個下面介紹格式的時候會介紹到。

上兩個m3u8文件的例子地址，大家能有直觀的認識，這是我從Vitamio的官網上扒的。

http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8

我總結了一下我遇到的m3u8格式，雖然不能說涵蓋了全部的情況，但是也差不多了：

1、一級目錄（我覺著一級的目錄沒有適配碼率的功能）

1.1、打開第一級m3u8文件，能找到真正的視頻地址

1.2、第一級m3u8文件中，沒有真正的視頻地址，需要拼接才能找到真正的視頻地址

2、二級目錄

2.1、二級地址在一級文件中直接能看到

2.2、二級地址在一級文件中不能直接看到，需要拼接一級鏈接的地址才能找到二級文件的地址

2.2、打開二級目錄，能找到整整的視頻地址

2.3、沒有真正的視頻地址，需要拼接才能找到真正的視頻地址

篇幅關系我不能給大家全部列舉出這些全部的可能性。我就拿最麻煩的舉個例子，其他的大家自行腦補吧，原理都是一樣的，怎么樣都跑不出協議的范疇之外。

我們在瀏覽器中輸入http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8，會得到一個名為bipbopall.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

這就符合上面的2.2種情況，這四種碼率的m3u8的地址你都不能直接得到，那怎么辦呢，我們用得到這個文件的鏈接地址的前半段http://devimages.apple.com/iphone/samples/bipbop/拼接上二級文件的相對地址gear1/prog_index.m3u8得到一個地址http://devimages.apple.com/iphone/samples/bipbop/gear1/prog_index.m3u8。

把此地址放到瀏覽器中，我們又會得到一個同樣名為prog_index.m3u8的文件，內容如下：

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10, no desc

fileSequence0.ts

#EXTINF:10, no desc

fileSequence1.ts

#EXTINF:10, no desc

fileSequence2.ts

#EXTINF:10, no desc

fileSequence3.ts

#EXTINF:10, no desc

fileSequence4.ts

#EXTINF:10, no desc

fileSequence5.ts

#EXTINF:10, no desc

.

.

.

#EXTINF:10, no desc

fileSequence179.ts

#EXTINF:1, no desc

fileSequence180.ts

#EXT-X-ENDLIST

我們很開心的發現，這設計簡直是巧(sang)奪(xin)天(bing)工(kuang)，我們還是沒有得到真正的視頻地址，老辦法拼接后我們得到這么一段鏈http://devimages.apple.com/iphone/samples/bipbop/gear1/fileSequence179.ts，這就是真正的視頻地址。

我舉的這個例子是最復雜的情況，一般的情況對于這個來說都是相對簡單的。就跟軟件設計一樣，我們先考慮到最難得情況，簡單的來說就迎刃而解了

此篇博文沒有具體介紹m3u8的格式，各位看管不了解的話還請自行Google之。

此篇博文完全是作者的經驗之談，可能有不確切的地方還請見諒，轉載請貼原文地址。