HTTP Dynamic Streaming 学习笔记[原理篇]-CSDN博客

转载自：http://www.mmihome.net/portal.php?mod=view&aid=278

一、什么是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，对于视频的缓存方面有了强有力的支持，感觉性能会提高很多(包括动态控制带宽)。至于还可以在哪些环境中应用，目前接触不多，还有待了解！

四、相关下载地址

（1）服务器模块 - 让Apache支持HTTP动态流
http://www.adobe.com/go/httpdynamicstreaming_bits
（2）OSMF播放器 - 支持HTTP动态流的播放器
http://www.osmf.com/downloads/OSFMPlayer_zeri2.zip
（3）HDS帮助在线手册
http://help.adobe.com/en_US/HTTPStreaming/1.0/Using/index.html

部分内容从adobe官方手册翻译而来，如有错误欢迎指出；欢迎转载，转载请注明出处！

下篇将讲如何进行安装部署

-EOF-

补充一下参考文章：