HDS相关（一）之 HTTP Dynamic Streaming 学习笔记[原理篇]

一、什么是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流)

三、性能分析

扯到性能这个话题，我感到非常蛋疼，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之下它拥有：更低的延时、更短的载入时间、动态缓冲和基于流的加密。