一、什麼是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之下它擁有：更低的延時、更短的載入時間、動态緩沖和基于流的加密。
