一、什麽是HTTP Dynamic Streaming

使用傳統的HTTP協議進行在線播放叫做“漸進下載”，所有的視頻內容從頭到尾必須從服務器傳輸到客戶端，用戶只能在傳輸完的視頻長度中選擇播放點，而不能自定義播放點及傳輸點，比如我們在看視頻的時候是邊下邊看，沒下載完則看不了，而且也不能繞到視頻後面的片段。當視頻觀看完畢之後，在瀏覽器的緩存中會存在一個視頻文件。

而使用RTMP協議進行傳輸的數據包叫做“流”（如Flash Media Server）,它能夠讓視頻內容分割成多個數據包並源源不斷從服務器端傳輸到客戶端，客戶端可以在視頻內容任意一個點開始請求傳輸，而不用關心該點之前的內容是否已經傳輸。這樣我們看視頻的時候可以在任意一個地方開始觀看，點到哪裏就從哪裏開始下載，觀看完畢之後在客戶端不會有緩存文件。

兩種協議各有各的優缺點，比如http協議在第二次觀看視頻的時候會直接使用緩存文件進行播放，速度也比較快，而RTMP協議必須保持源源不斷送出“流”，同時本地也無緩存。

而HTTP Dynamic Streaming則是對兩種協議的優點進行了一個組合，達到了兩個協議取長補短的服務平臺。其通過對來自RTMP端的“流”進行包裝處理，轉化成HTTP“流”提供給客戶端解析，用戶再也不用下載整個文件，同時又能使用HTTP協議進行快速觀看視頻。

架構圖：

工作模式：

HTTP Dynamic Streaming有兩種工作模式，一種是On-demand模式，直接對文件進行“流”處理，把單個文件分離成N個片段，用戶跳到相應的片段，則傳輸該片段，用戶沒請求該片段，則不傳輸(貌似能達到節省帶寬的作用)；一種是live模式，也就是所謂的直播，這裏需要FMS的支持，FMS通過把直播流傳遞給HTTP Dynamic Streaming，然後進行包裝處理，傳遞給客戶端，此模式可以應用在視頻會議，視頻聊天室，網絡直播等應用中，HTTP Dynamic Streaming的主要作用也在這個模式中體現。

二、原理分析

用過Flash Media Server(簡稱：FMS)的技術人員都知道FMS的工作原理，而HTTP Dynamic Streaming(簡稱：HDS)的實際效果則是工作在FMS計算結果上的，從架構圖上不難看出，無論是On-demand模式或live模式，多多少少都會依賴FMS，比如On-demand模式，FLV文件必須通過FILE PACKAGER進行轉碼得到".f4f",".f4m",".bootstrap"等文件才能夠提供給“HTTP ORIGIN MODULE”處理，而一般線上的環境的視頻文件何止千千萬萬！再說效率是否達到要求還很難說。而live模式中LIVE PACKAGER能夠把來自RTMP的“流”直接生成所需要的文件，提供給“HTTP ORIGIN MODULE”處理，但依然也是得有FMS的支持才行。

實際的工作流程是這樣的：

On-demand: FLV /F4V(目前只支持兩種格式)------>File Packager------->(.f4f/.f4m/.f4x/..bootstrap/.drmmeta)------->Apache-------->HTTP ORIGIN MODULE-------->客戶端播放器(需支持HTTP流)

Live: FLV /F4V(目前只支持兩種格式)------->FMS(Using RTMP)------->Live Packager------->(.f4f/.f4m/.f4x/..bootstrap/.drmmeta)------->Apache-------->HTTP ORIGIN MODULE-------->客戶端播放器(需支持HTTP流)

相關模塊：

File Packager:一個命令行工具,它可以按照需求把多媒體文件形成流碎片並把碎片寫進\.f4f文件。文件包裝機是一種離線工具。同時也支持Flash Access驗證訪問的需求。

Live Packager:該工具只針對HDS,同時集成在FMS(version 3.8以上)。它可以實時測量RTMP流(live),並將之轉化成新的\.f4f文件，滿足實時性要求。內置的apache服務器使用HTTP ORIGIN MODULE對生成的文件進行解析，然後提供出HTTP流。

HTTP ORIGIN MODULE:HDS的重要組成部分，其為apache的一個modules，負責對(.f4f/.f4m/.f4x/..bootstrap/.drmmeta)等文件進行解析，然後轉換成HTTP流輸出。

OSMF Player:一個開源的播放器，建立在Open Source Media Framework(OSMF)的框架上，支持HTTP流，要求Flash player 10.1或以上


相關文件描述：

.f4f:Packager的輸出文件，它來自源多媒體文件的輸出，為其中的一個或多個片段，其中片段可以由一個或多個“流”組成，可以理解為HTTP流中的源文件

.f4m:Packager的輸出文件，它記錄了源多媒體文件的編碼率，分辨率等信息，同時定義了每個流的大小

.f4x:索引文件，定義關鍵幀等

.bootstrap:它將告訴apache及其中的模塊如何去讀取./f4f文件，可以理解為引導文件，引導信息來自於.f4m文件，但是也可以額外指定其它信息來源(--external-bootstrap)

.drmmeta:用於保存加密的信息，需要使用(--external-bootstrap)來引用進來

從上面的一些模塊及重要文件描述可以具體了解到各個環節的工作及原理，具體也可以解釋到HDS是怎樣配合Flash Access Server來做播放認證，把具體的文件或RTMP流轉換成HTTP流的工作過程，但同時要註意一點，播放器必須支持讀取HTTP流，比如OSMF Player.

三、性能分析

扯到性能這個話題，我感到非常蛋疼，FMS的最低要求是4G內存，還得奔騰4以上的CPU，一開服務跑一段時間，內存基本吃光，而且不會釋放，一般線上的服務器都是8G內存左右，CPU當然不用說了，所以我們運維人員做優化的空間非常小，比如優化單個流的大小，降低視頻文件的碼率，提高系統的I/O等等，這些都是以更高級的配置換取更好的性能(難怪人家說做視頻燒錢，錢都燒在設備裏面了)。回到HDS，那麽這個最低要求肯定要比FMS高(雖然官網表明跟FMS一樣)，你要是想跑的順點的話，那你只能在這個基礎上翻一倍的硬件質量了，尤其是內存和硬盤速度方面的要求，服務器要不斷從內存中讀取RTMP的流，然後寫成本地文件，高並發的情況下，內存和硬盤的負載是非常大的。但用戶對流暢性要求比較高的時候，減小單個流的大小是一個不錯的選擇，但這個也是以提高CPU負載為代價的，流變小了，流的個數也多了，那麽也增加了IO的負擔。。。。當然這個只是理論上的推測，因為沒有實際的情況來做測試，假如有人有條件做個測試，可以交流一下。


總體來說，HDS讓流媒體更加擴展開來，讓更多的環境都能夠通過HTTP實現流播放，而拋棄了RTMP的束縛之後，在一些應用的開發上也減少了很多限制。而采用HTTP流的方式，對於一些非驗證性的業務（如免費視頻分享）有了更好的選擇，不用死磕RTMP了，同時加上APACHE，對於視頻的緩存方面有了強有力的支持，感覺性能會提高很多(包括動態控制帶寬)。至於還可以在哪些環境中應用，目前接觸不多，還有待了解！

四、相關下載地址

服務器模塊 - 讓Apache支持HTTP動態流
http://www.adobe.com/go/httpdynamicstreaming_bits
OSMF播放器 - 支持HTTP動態流的播放器
http://www.osmf.com/downloads/OSFMPlayer_zeri2.zip
HDS幫助在線手冊
http://help.adobe.com/en_US/HTTPStreaming/1.0/Using/index.html

部分內容從adobe官方手冊翻譯而來，如有錯誤歡迎指出；歡迎轉載，轉載請註明出處！

五、與HTTP Live Streaming比較

與APPLE家的HTTP Live Streaming差不多，主要異同如下：

1、文件切片采用MP4的格式而非ts格式；
2、索引在APPLE家是foo.m3u8文件，Adobe家是manifest文件；
3、Adobe家除了支持APPLE家支持的H.264/AAC之外還支持VP6/MP3編碼；
4、不同於APPLE家，內容保護通過Flash Access Server來實現；
5、通過Adobe AIR可達範圍更廣（Mac OS、Windows、Linux都可以），但目前顯然過不了APPLE家 iOS的審核；
6、兩家同樣都支持點播和直播；
7、Adobe家提供了一個全套的解決框架“Open Source Media Framework”。
8、HTTP Dynamic Streaming作為Adobe自家RTMP的補充。它自己的優點就不提了。相較RTMP之下它擁有：更低的延時、更短的載入時間、動態緩沖和基於流的加密。

HDS協議介紹