从很多方面来讲,HTTP动态流技术(在文章中以下部分简称HDS)是Adobe公司对苹果公司的Adaptive Bitrate Streaming技术以及微软公司的IIS Smooth Streaming技术的一个回应。这三项技术的共同之处在于它们通过HTTP网络连接传递媒体文件以及适应于用户当前带宽的媒体文件传输的能力。相对于连入以太网的个人电脑而言,Android设备的有效带宽就显得尤为不足了。(这项技术的)最终结果是,在各种设备上实现媒体文件的流畅回放,不管这些设备是智能手机还是台式计算机。
要更好地了解HDS是如何工作的,撇开技术上的内容,只考虑下述的虚拟场景:
ABC Video Services刚刚完成了一个一分钟短片的制作,它的老板Pete灵机一动,并没有使用录像带来承载其录音内容。Pete说:“我们何不放弃录像带,而是通过一种更为有效的方式把视频传输给用户呢?”
工作室的人对这个激进的想法都感到有些惊讶,因为每个人都知道,“这是我们一直在使用的方法。”Pete并没有接受这个论据,而是给出了下面一个假设:
“为什么不把录像内容切成十个六秒钟的小片段,然后顺序的把它们传输到设备中去播放?”
有点保守主义的Sam觉得这真是一个愚蠢的想法,但是Pete是他的老板,因此他并不想这么去说。他考虑了一会,想到了一个他认为可以把这个想法从根本上扼杀掉的反驳想法。他说:“Pete,这听起来很有趣,但不合实际啊。(如果按照你的想法,)客户将会拿到一堆看起来一样的录音条。我们如何能确保客户不会弄乱这些录音条的顺序?”
“这很简单”,Pete说,“我们可以给客户一个告诉他们应该在什么时间播放哪一个录音条的文件。我们所要做的就是把这个文件和录音条打包到一起传输给客户。客户所需要做的就是打开并阅读说明文件,然后一切都按计划进行了。”
这并不是HDS的产生过程,但它捕获了这项技术的本质。
HDS和Pete的想法又有什么关联呢?HDS可能就是由你伴随Flash Media Server (FMS)一同安装的Apache模块而来的。在这种情况下,FMS扮演着打包机的角色,制造内容片断,由Apache通过HTTP传输到Flash兼容的视频播放器。为了解决Sam所提出的反对意见,与F4M扩展一起,另外的一个清单文件也是通过同样的一个过程创建出来的。从根本上说,所需视频文件首先使用F4F扩展软件切割成若干片段,作为片段文件。清单文件中包含了视频的一些基本信息,包括每一个片段文件的位置以及其中最为重要的信息——这些片段传输到用户设备上的顺序。
如果这一切都是通过HTTP连接流动的,那么FMS 4.5是如何纳入这个过程的呢?Flash Media Server 4.5包含了两种类型的实时组件:live和Just-In-Time (JIT)。不管在哪种情况下,清单文件和F4F文件都能按照需求创建,并通过HTTP传输给客户来实现回放。例如,如果Sam有一部智能手机,想观看他刚编辑过的视频,他要做的就是打开他的手机上的浏览器,链接到包含这段视频的SWF文件的网页。SWF文件打开时,只需要F4M清单文件来启动视频片段有序的向设备浏览器的传输。
作为一个反对者,Sam马上就看到了这个方案存在的问题。“朋友们,我用的是3G网络,网速很慢;我没有你们所使用的以太网连接的带宽。这将会是一个很糟糕的体验。”
幸运的是,还有Pete。Pete说:“Sam,别激动。这不是问题。这个清单文件会把播放列表附在SWF文件上,它可以检测你的连接状况,如果你的带宽较低,在清单文件中查找该带宽下的最佳视频文件。我们称这个为‘多比特率流媒体’,你会喜欢上它的。”
既然这样说了,是时候让Sam喜欢上它了。