認識FLV

上一篇講了HTTP在流媒體中的應用，接下來我們先把基於HTTP的HTTP-FLV和HLS兩種直播中應用非常廣泛的協議提一下。

先看看HTTP-FLV長成什麼樣子：http://ip:port/live/livestream.flv，協議頭是http,另外”.flv”這個尾巴是它最明顯的特徵。

在流媒體尤其是直播應用中，為什麼我們要如此重視HTTP-FLV呢，因為他的使用非常廣泛，可以這麼說，當下的直播平臺中大部分的主線路使用的都是HTTP-FLV協議，備線路多為RTMP。小編隨便在Safari中開啟幾個直播平臺房間，一抓包就不難發現使用HTTP-FLV協議的身影：熊貓、鬥魚、虎牙、B站。

FLV格式

在說HTTP-FLV之前，我們有必要對FLV adobe 官方標準有個認識，因為HTTP-FLV協議中封裝格式使用的是FLV。

FLV檔案格式標準是寫F4V/FLV fileformat spec v10.1的附錄E裡面的FLVFile Format。

▣  單位說明

▣  FLV 檔案頭和檔案體 （E.2，E.3）

從整個檔案上看，FLV = FLV FileHeader + FLV File Body。通常，FLV的前13個位元組（flv header + PreviousTagSize0）完全相同，所以， 程式中會單獨定義一個常量來指定。

▣  

Timestamp和TimestampExtended組成了這個TAG包資料的PT 資訊，PTS =Timestamp | TimestampExtended << 24。

▣  AudioTag （E.4.2）

由於AAC編碼的特殊性， 這裡著重說明了AAC編碼的Tag格式。

AudioTagHeader的第一個位元組，也就是接跟著StreamID的1個位元組包含了音訊型別，取樣率等的基本資訊。

AudioTagHeader之後跟著的就是AUDIODATA部分了。但是，這裡有個特例，如果音訊格式（SoundFormat）是 AAC，AudioTagHeader中會多出1個位元組的資料AACPacketType，這個欄位來表示AACAUDIODATA的型別： 0 = AAC sequence header，1 = AAC raw。

AudioSpecificConfig結構描述非常複雜，在標準文件中是用虛擬碼描述的，這裡先假定要編碼的音訊格式，做一下簡化。

音訊編碼為：AAC-LC， 音訊取樣率為 44100。

在FLV的檔案中，一般情況下AAC sequence header這種包只出現1次， 而且是第一個audio tag，為什麼需要這種tag，因為在做FLV demux的時候，如果是AAC的音訊，需要在每幀AAC ES流前邊新增7個位元組ADST頭， ADST是解碼器通用的格式， 也就是說AAC的純ES流要打包成ADST格式的AAC檔案，解碼器才能正常播放。就是在打包ADST的時候，需要samplingFrequencyIndex這個資訊，samplingFrequencyIndex最準確的資訊是在AudioSpecificConfig中，這樣，你就完全可以把FLV檔案中的音訊資訊及資料提取出來，送給音訊解碼器正常播放了。

▣  VideoTag （E.4.3）

由於AVC（H.264）編碼的特殊性，這裡著重說明了AVC（H.264編碼的Tag格式。

VideoTagHeader的第一個位元組，也就是接跟著StreamID的1個位元組包含著視訊幀型別及視訊CodecID等最基本資訊。

VideoTagHeader之後跟著的就是VIDEODATA部分了。但是，這裡有個特例，如果視訊格式（CodecID）是AVC，VideoTagHeader會多出4個位元組的資訊。

AVCDecoderConfigurationRecord包含著是H.264解碼相關比較重要的SPS和PPS資訊，在給AVC解碼器送資料流之前一定要把SPS和PPS資訊送出，否則的話，解碼器不能正常解碼。而且在解碼器stop之後再次start之前， 如seek，快進快退狀態切換等，都需要重新送一遍SPS和PPS的資訊。AVCDecoderConfigurationRecord在FLV檔案中一般情況也只出現1次， 也就是第一個video tag。

AVCDecoderConfigurationRecord長度為sizeof(UI8) * (11 +sps_size + pps_size)

▣  SCRIPTDATA （E.4.4）

ScriptTagBody內容用AMF編碼。

一個SCRIPTDATAVALUE記錄包含一個有型別的ActionScript值。

▣  onMetadata （E.5）

FLV metadata object儲存在SCRIPTDATA中，叫onMetaData。不同的軟體生成的FLV的properties不同。

▣  keyframes索引資訊

官方的文件中並沒有對keyframesindex做描述， 但是，flv的這種結構每個tag又不像TS有同步頭，如果沒有keyframes index的話，seek及快進快退的效果會非常差，因為需要一個tag一個tag的順序讀取。後來在做flv檔案合成的時候，發現網上有的flv檔案將keyframes資訊隱藏在ScriptTag中。keyframes幾乎是一個非官方的標準, 也就是民間標準。

兩個常用的操作metadata的工具是flvtool2和FLVMDI，都是把keyframes作為一個預設的元資訊專案。在FLVMDI的主頁上有描述：

也就是說keyframes中包含著2個內容‘filepositions’和‘times’分別指的是關鍵幀的檔案位置和關鍵幀的PTS。通過keyframes可以建立起自己的Index，然後在seek和快進快退的操作中，快速有效地跳轉到你想要找的關鍵幀位置進行處理。

▣  FLV分析工具

▲  http://www.flvmeta.com/

▲  yamdi：將flv轉成帶索引的flv，yamdi -i i.flv -o o.flv

▲  flvlib：pip install flvlib，檢視索引資訊：debug-flv--metadata file.flv

▲  flvchek：http://www.adobe.com/products/adobe-media-server-family/tool-downloads.html

HTTP-FLV

我們這裡說的HTTP-FLV，主要是說的是HTTP-FLV流，而不是基於HTTP的FLV視訊檔案點播，也不是能夠隨意SEEK的HTTP FLV偽流。

FLV漸進式下載：通過HTTP協議將FLV下載到播放器中播放，無法直接拉到中間去播放。

HTTP FLV偽流：支援SEEK，可從未下載的部分開始播放。

HTTP-FLV流：擁有和流式協議RTMP一樣的特徵，長連線，流式資料。

▣  HTTP-FLV技術實現

HTTP協議中有個content-length欄位的約定，即http的body部分的長度。伺服器回覆http請求時如果有這個欄位，客戶端就接收這個長度的資料然後認為資料傳輸完成了，開始播放。

如果伺服器回覆http請求中沒有這個欄位，客戶端就一直保持長連線接收資料，直到伺服器跟客戶端的socket斷開。

HTTP-FLV流就利用了上述的第二個原理，伺服器回覆客戶端請求的時候不加content-length欄位，在回覆了http內容之後，進行持續的資料傳送，客戶端就一直接收資料，以此實現了HTTP-FLV流直播。

資料傳輸依然是之前講過的內容，每一個音視訊資料都被封裝成包含時間戳資訊頭的資料包，封裝格式採用FLV，傳輸協議採用http。

▣  HTTP-FLV抓包分析

開啟熊貓TV的一條直播流：

http://175.25.168.16/pl3.live.panda.tv/live_panda/d4e0a83a7e0b0c6e4c5d03774169fa3e.flv?wshc_tag=0&wsts_tag=57e233b1&wsid_tag=6a27c14e&wsiphost=ipdbm

返回資訊如下：

我們發現響應頭中出現Connection:close的欄位，表示網宿採用的是短連線方式，直接通過伺服器關閉連線來確定訊息的傳輸長度。

還有一種實現方式，如果HTTP Header中有Content-Length，那麼這個Content-Length既表示實體長度，又表示傳輸長度。而HTTP-FLV這種流，伺服器是不可能預先知道內容大小的，這時就可以使用Transfer-Encoding:chunked模式來傳輸資料了。如下的響應就是採用的Chunked的方式進行的傳輸的響應頭：

▣  HTTP-FLV延遲分析

通過http-flv的實現中不難發現，HTTP-FLV的延遲方面和RTMP能夠保持一致。

▣  HTTP-FLV與其他流媒體協議的比較

當前，RTMP、HLS、HTTP-FLV是直播應用的三種主協議，說他主流，主要是因為國內所有的CDN都支援對它們的分發。這裡需要注意的是，有些廠商如網宿所指的HDL，國外所稱的HFL，本質上都是我們今天所講的HTTP-FLV協議。

觀止雲的BMS是在國內最早支援HTTP-FLV的流媒體伺服器，且相對於其他方案，觀止雲BMS叢集內部全走RTMP，只是在邊緣實時轉為HTTP-FLV。如此一來系統架構更簡單，穩定，且一路RTMP回源節省了不少回源流量。

❶  延遲比較

HTTP-FLV：低延遲，內容延遲可以低於3秒

RTMP：低延遲，內容延遲可以低於3秒

HLS:：延遲較高，一般在10秒左右

❷  易用性比較

RTMP和HTTP-FLV：二者一樣，服務端需要專門的流媒體伺服器，播放端需要專門的FlashPlayer。但目前瀏覽器支援Flash較好，所以PC上的播放問題不大，移動端需要專門的SDK解碼。

HLS：更為易用，服務端就是WEB伺服器外加切片工具。播放端只要是蘋果裝置、HTML5平臺的瀏覽器均可直接播放。也就是說，移動端不論是IOS還是Android，微信，朋友圈等都可以直播播放HLS直播流。

❸  RTMP和HTTP-FLV的比較：

RTMP和HTTP-FLV延遲上保持一致，在這二者的區別如下：

▲  穿牆：很多防火牆會牆掉RTMP，但是不會牆HTTP，因此HTTPFLV更不容易出問題。

▲  排程：雖然RTMP也能支援302，單實現起來較麻煩。HTTP FLV本身就支援302，更方便CDN進行重定向以便更精準的排程。

▲  容錯： HTTP-FLV回源時也可以回多個源，能做到和RTMP一樣，支援多級熱備。

▲  簡單：FLV是最簡單的流媒體封裝，HTTP是最廣泛的協議，這兩個組合在一起維護性更高，比RTMP簡單。

▲  友好：HTTP-FLV程式碼量更小，整合SDK也更輕便。使用起來也更簡單。

綜上，HTTP-FLV協議具有RTMP的延遲優勢，又繼承了HTTP所有優勢，是流媒體直播首選的分發協議。

另外，HTTP-FLV也能在推流端實現，用HTTP進行資料推流。就同樣能在推流端實現上述一切優勢了，只是目前國內還沒有廠商實現。