一、HTTP（WebService）

基于HTTP的渐进下载Progressive Download流媒体播放仅是在完全下载后再播放模式基础上做了一些小的改进。与下载播放模式中必须等待整个文件下载完毕后才能开始播放不同，渐进下载客户端在开始播放之前仅需等待一段较短的时间用于下载和缓冲该媒体文件最前面的一部分数据，之后便可以一边下载一边播放。在正式开始播放之前的这一小段缓冲应使得后续即使在网络较为拥塞的情况下媒体数据也能够得以不间断地连续播放，通常需要几十秒甚至上百秒的时间。在这种模式下，客户端以自己以及Web服务器和网络所能允许的最大速度尽可能快地从服务器索取数据，而不考虑当前所播放压缩码流的实际码率参数。只有满足特定封装条件的媒体文件格式才支持这种类型的渐进下载播放，例如用于初始化解码器的编码参数必须放置在媒体文件的起始部位，音视频数据完全按照时间顺序进行交织等。

渐进下载流媒体播放采用标准HTTP协议来在Web服务器和客户端之间递送媒体数据，而HTTP又承载于TCP之上。TCP最初是为非实时性数据传输而设计的，其优化目标在于在保证整个网络总的稳定性和高吞吐量的前提下，最大化数据传输速率。为达到这个目的，TCP采用了一种称之为慢启动的算法，它首先以一个较低的速率来发送数据，然后再逐渐提高这个速率，直到接收到来自目的方的分组丢失反馈报告。此时TCP认为它已达到最高带宽限制或者网络中出现了拥塞，于是重新开始以一个较低速率来发送数据，然后逐渐提高，这个过程不断地重复下去。TCP通过重传丢失的分组来达到可靠传输的目的。然而，对于流媒体数据来说，TCP 无法保证所有重传的数据能在它们预定的播放时刻之前按时到达客户端。当这种情况出现时，客户端不能跳过这些丢失或迟到的数据直接播放时间上靠后的媒体数据，而必须停下来等待，从而导致播放器画面停顿和断断续续的现象发生。在渐进下载播放模式中，客户端需要在硬盘上缓存所有前面已经下载的媒体数据，对本地存储空间的需求较大。播放过程中用户只能在前面已经下载媒体数据的时间范围内进行进度条搜索和快进、快退等操作，而无法在整个媒体文件时间范围内执行这些操作。

严格意义上，基于HTTP的VOD不算是真的流媒体，英文称为“progressive downloading”或者“pseudo streaming”，为什么这样呢？因为HTTP缺乏流媒体基本的流控，由此基于HTTP协议很难实现媒体播放的快进，快退，暂停。那么，通常的媒体播 放器又是如何利用HTTP来实现这样的功能呢？

我们都知道，不管媒体文件有多大，HTTP都只是视它为一个HTTP的元素，可以只需要发送一个HTTP请求，WEB Server就会源源不断地将媒体流推送给客户端，而不管客户端是否接受，这就是HTTP协议本身没有流控的原因，那这样会带来什么后果呢？

如果服务器的推流速度和客户端同步， 那么基本不会出现什么大问题；如果小于客户端的接收流的速度，那么播放就会一卡一卡的；如果大于或者远大于客户端的接收速度，那又会是怎么样的结果呢？很 不幸，在我们所有的ISTV项目中，只要是基于HTTP的VOD，都无一例外是第三种情况。因为我们VOD是基于局域网的，大家都知道，局域网的带宽资源 是很丰富的，服务器的推流的速度肯定大于播放器的播放速度，那么在这么速度极端不协调的情况下，服务器的推流速度究竟由谁来限制呢？

答案是：TCP协议栈。我们的VOD点播是基于TCP的HTTP协议。TCP是安全的，可靠的，包肯定不会丢，服务器检测到客户端的接收缓冲区满了，就会减小发送数据滑动窗口的大小。所以HTTP的流控是通过TCP协议栈来调节的，不是HTTP本身。试想，这样对服务器造成的压力有多大!

下面就分析基于HTTP协议如何实现SEEK，PAUSE等操作

1.SEEK（快进和快退）

先关闭之前的tcp连接，重新连接，发送http请求，该请求带了媒体的偏移位置。由此可见，每一次的快进和快退，都等于是重新开始播放，只是每次开始播放的位置不一样。

2.PAUSE

该操作就更有意思了，客户端暂停了播放，也就是不从缓冲区读取数据了，但是服务器不知道客户端停止了播放，依然不停地发送数据给客户端，直到客户端的接收 缓冲区已满，然后服务器的数据发送不出去了，理论上是服务器端的滑动窗口的大小估计就是0了，然后协议栈还在不停在尝试发送数据，因为是基于tcp，这些 数据还不能丢。nnd，这种方式实现暂停，协议栈都哭了。很不幸，MPLAYER就是这么干的。所以暂停的时间长了，就容易出现问题。

虽然HTTP没有PAUSE的支持，但是针对PAUSE是可以优化的，优化的方法是，将媒体文件分片，分片的大小以稍小于TCP协议栈的缓冲区大小为宜。 HTTP请求一次只请求一个分片的大小，暂停播放后，就不在发送分片请求了。这样可以保证让服务器运行的时间长一些，播放器暂停理论上可以无限长了。

二、HTTP Live Streaming

HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。要实现HLS点播，重点在于对媒体文件分段，目前有不少开源工具可以使用，这里我就不再讨论，只谈HLS直播技术。一个典型的HTTP Live Streaming流媒体系统由内容准备、内容分发和客户端软件三部分组成，如图所示。

1. 内容准备

内容准备部分负责将输入的音视频媒体内容转换成为适合于内容分发组件进行递送的格式。对于视频直播，编码器首先将摄像机实时采集的音视频数据压缩编码为符合特定标准的音视频基本流(目前苹果的系统仅支持H.264视频和AAC音频)，然后再复用和封装成为符合MPEG-2系统层标准的传输流(TS)格式进行输出。流分割器(Stream Segmenter)负责将编码器输出的MPEG-2 TS流分割为一系列连续的、长度均等的小TS文件(后缀名为.ts)，并依次发送至内容分发组件中的

Web服务器进行存储。与此同时，为了跟踪播放过程中媒体文件的可用性和当前位置，流分割器还需创建一个含有指向这些小TS文件指针的索引文件，同样放置于Web服务器之中。这个索引文件可以看作是一个连续媒体流中的播放列表滑动窗口，每当流分割器生成一个新的TS文件时，这个索引文件的内容也被更新，新的文件URI(统一资源定位符)加入到滑动窗口的末尾，老的文件URI则被移去，这样索引文件中将始终包含最新的固定数量的x个分段，如图所示。流分割器还可以对其生成的每个小TS文件进行加密，并生成相应的密钥文件。

之所以采用MPEG-2 TS格式来对编码后的媒体流进行统一封装，是因为它能够将音视频媒体流严格按时序进行交织复用，任意截取和分段后，每一个分段都可能不依赖于之前的分段而独立进行解码和播放。为此，TS文件中必须仅包含一个MPEG-2节目，在每个文件的开头应包含一个节目关联表(PAT)和一个节目映射表(PMT)，包含视频的文件中还必须含有至少一个关键帧和其他足够信息(如序列头)用以完成解码器的初始化。索引文件采用扩展的M3U播放列表格式，后缀名为.m3u8。M3U播放列表是一个由若干文本行组成的文本文件，其中每一行要么是一个URI，一个空行，或者是一个以注释符“#”起始的行。每个URI行指向一个分段的媒体文件，或者一个衍生的索引(播放列表)文件。除了以“#EXT”起始的行是标签行外，其他以“#”起始的行是注释，应予忽略。下面是一个简单的.m3u8索引文件例子，其所表示的媒体流由3个未加密的长度为10秒的TS文件组成。

对 于 视 频 点 播 ( V O D ) ， 文 件 分 割 器 ( F i l e Segmenter)首先将预编码存储的媒体文件转码为MPEG-2 TS格式文件(已经封装为TS格式的文件则忽略这一步)，然后再将该TS文件分割成一系列长度均等的小TS文件。文件分割器同样也生成一个含有指向这些小文件指针的索引文件。与直播型会话不同的是，这里的索引文件是一个不随时间而更新的静态文件，其中包含一个节目从头到尾所有分段文件的URI列表，并以#EXT-X-ENDLIST标签结尾。可以通过下述方法将一个直播事件转换成VOD节目源供以后点播：在服务器上不删除已经过期的分段媒体文件，同时在索引文件中也不删除这些文件所对应的URI索引项，在直播结束的时候将#EXT-X-ENDLIST标签添加至索引文件的末尾。

2. 内容分发

内容分发系统用于通过HTTP协议将分割后的小媒体文件及其索引文件递送至客户端播放器，它既可以是一个普通的Web服务器，也可以是一个Web缓存系统。几乎不需要对Web服务器做任何特殊的配置，以及增加其他定制的模块。推荐的配置仅限于对.m3u8文件和.ts文件的MIME类型关联，如表所示。

由于索引文件需要频繁更新和下载，因此在Web cache的配置中有必要对.m3u8文件的TTL(time-to-live)值进行微调以保证客户端每次请求该文件时都能够下载到它的最新版本。

3. 客户端软件

通常情况下，客户端软件通过访问Web网页中的URL链接来获取和下载一个流媒体会话的索引文件。这个索引文件进一步指定了服务器上当前可用的TS格式媒体文件、解密密钥和其他替换流的位置。对于选定的媒体流，客户端依次下载索引文件中列出的每一个可用媒体文件。当这些媒体文件缓冲够一定数量后，客户端将它们按顺序重新拼装成一个连贯的TS流，然后发送至播放器进行解码和呈现。对于加密的媒体文件，客户端还负责根据索引文件的指引来获取解密密钥，提供用户认证接口，并按需进行解密。对于视频点播，上述过程不断持续下去，直到客户端碰到索引文件中的#EXT-X-ENDLIST标签。对于视频直播，索引文件中不存在#EXT-X-ENDLIST标签，客户端将周期性地向Web服务器重新请求获取该索引文件的更新版本，然后在这个更新版的索引文件中查找新的媒体文件和解密密钥，并将它们的URI添加至下载队列的末尾。需要注意HTTP Live Streaming并不是一个真正实时的流媒体系统，这是因为对应于媒体分段的大小和持续时间有一定潜在的时间延迟。在客户端中，至少在一个分段媒体文件被完全下载之后才能够开始播放，而通常要求下载完成两个分段媒体文件之后才开始播放以保证不同分段音视频之间的无缝连接。此外，在客户端开始下载之前，必须等待服务器端的编码器和流分割器至少生成一个TS文件，这也会带来潜在的时延。在推荐配置下，HTTP Live Streaming系统的典型时延约在30s左右。

4. 网络自适应的流间切换和故障保护

在基于HTTP Live Streaming的流媒体系统中，服务器可以为同一节目源准备多份以不同码率和质量编码的替换流，并为每个替换流都生成一个衍生的索引文件。在主索引文件中通过包含一系列指向其他衍生索引文件的URI指针来找到相应的替换流，如图所示。

在移动互联网环境下，由于网络覆盖面的不同和信号强弱的变化，移动终端可能随时在不同的无线接入网络(例如3G，EDGE，GPRS和WiFi等)之间进行切换。此时客户端软件可根据网络和带宽的变化情况随时切换到不同衍生索引文件所指向的替换流进行下载，从而自适应地为用户提供相应网络条件下接近最优的音视频QoS体验。上述替换流和衍生索引文件机制除了可以用于基于带宽波动的动态流间切换外，还可以用于服务器的故障保护。为此目的，首先在一台服务器上按照正常流程生成一个媒体流或者多个替换流，以及对应的索引文件，然后再在另一台服务器上生成一套并行的备份媒体流和索引文件。接下来将指向备份流的索引加入到主索引文件之中，使得其中针对每个带宽值都对应有一个主媒体流和一个备份媒体流。例如，假定主服务器和备份服务器分别为ALPHA和BETA，则主索引文件中的内容可能如下所示：

在上述例子中，当客户端连接主服务器ALPHA失败时，它将试图连接备份服务器BETA，从中获取最高带宽值替换流所对应的衍生索引文件，并进一步根据该索引文件下载相应的替换媒体流文件。

相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。

根据以上的了解要实现HTTP Live Streaming直播，需要研究并实现以下技术关键点

1.采集视频源和音频源的数据

2.对原始数据进行H264编码和AAC编码

3.视频和音频数据封装为MPEG-TS包

4.HLS分段生成策略及m3u8索引文件

5.HTTP传输协议

三、RTSP (Real Time Streaming Protocol)

上述基于渐进下载的流媒体播放仅能支持点播而不能支持直播，媒体流数据到达客户端的速率无法精确控制，客户端仍需维持一个与服务器上媒体文件同样大小的缓冲存储空间，在开始播放之前需要等待一段较长的缓冲时间从而导致实时性较差，播放过程中由于网络带宽的波动或分组丢失可能会导致画面停顿或断续等待，不支持全时间范围的搜索、快进、快退等VCR操作。为克服这些问题，需要引入专门的流媒体服务器以及相应的实时流媒体传输和控制协议来进行支持。RTSP/RTP是目前业界最为流行和广为采用的实时流媒体协议。它实际上由一组在IETF中标准化的协议所组成，包括RTSP(实时流媒体会话协议)， SDP(会话描述协议)，RTP(实时传输协议)，以及针对不同编解码标准的RTP净载格式等，共同协作来构成一个流媒体协议栈，如图所示。基于该协议栈的扩展已被ISMA(互联网流媒体联盟)和3GPP(第三代合作伙伴计划)等组织采纳成为互联网和3G移动互联网的流媒体标准。

RTSP是用来建立和控制一个或多个时间同步的连续音视频媒体流的会话协议。通过在客户机和服务器之间传递RTSP会话命令，可以完成诸如请求播放、开始、暂停、查找、快进和快退等VCR控制操作。虽然RTSP会话通常承载于可靠的TCP连接之上，但也可以使用UDP等无连接协议来传送RTSP会话命令。在RTSP协议中起关键作用的命令主要包括下面几个：

1) SETUP：使服务器分配媒体流资源，并启动一个RTSP会话。

2) PLAY和RECORD：在SETUP所启动会话并分配资源的某个流上开始数据传输。

3) PAUSE：暂时中止一个流的数据传输而不释放服务器资源。

4) TEARDOWN：释放服务器上的流资源，结束RTSP会话。

SDP协议用来描述多媒体会话。SDP协议的主要作用在于公告一个多媒体会话中所有媒体流的相关描述信息，以使得接收者能够感知这些描述信息并根据这些描述参与到这个会话中来。SDP会话描述信息通常是通过RTSP命令交互来进行传递的，其中携带的媒体类信息主要包括：

1) 媒体的类型(视频，音频等)。

2) 传输协议(RTP/UDP/IP，RTP/TCP/IP等)。

3) 媒体编码格式(H.264视频，AVS视频等)。

4) 流媒体服务器接收媒体流的IP地址和端口号。

RTP又称为实时传输协议，用于实际承载媒体数据并为具有实时特性的媒体数据交互提供端到端的传输服务，例如净载类型识别、序列号、时间戳和传输监控等。应用程序通常选择在UDP之上来运行RTP协议，以便利用UDP的复用和校验和等功能，并提高网络传输的有效吞吐量。然而RTP仍可选择与其它网络传输协议(例如TCP)一块使用。一个RTP分组由RTP头和RTP净载(payload)两部分组成。上层应用程序主要通过RTP头中的序列号字段(sequence number)和时间戳(timestamp)字段来实施其所承载媒体流数据的同步定时播放和QoS控制。RTP净载部分实际承载客户端所需要的音视频媒体数据。针对不同的音视频编码标准可能需要定义不同的RTP净载格式，例如H.264的RTP净载格式标准和AVS视频的RTP净载格式标准。流媒体服务器和客户端播放器依照这些净载格式标准来进行媒体数据流的RTP打包和分拆重组工作。RTSP/RTP流媒体协议栈的使用需要专门的流媒体服务器进行参与。与渐进下载中媒体数据的被动突发递送不同，在有流媒体服务器参与的媒体分发过程中，媒体数据是以与压缩的音视频媒体码率相匹配的速率主动和智能地发送的。在整个媒体递送过程中，服务器与客户端紧密联系，并能够对来自客户端的反馈信息做出响应。RTP是真正的实时传输协议，客户端仅需要维持一个很小的解码缓冲区用于缓存视频解码所需的少数参考帧数据，从而大大缩短了起始播放时延，通常可控制在1秒之内。使用UDP来承载RTP数据包可提高媒体数据传输的实时性和吞吐量。当因为网络拥塞而发生RTP丢包时，服务器可以根据媒体编码特性智能地进行选择性重传，故意丢弃一些不重要的数据包；客户端也可以不必等待未按时到达的数据而继续向前播放，从而保证媒体播放的流畅性。

RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。类似HTTP协议的流控制协议。它们都使用纯文本来发送信息，而且rtsp协议的语法也和HTTP类似，和HTTP协议相比RTSP协议所不同的地方是，RTSP协议是有状态的协议，而HTTP是无状态的协议。RTSP通过维护一个session来维护其状态的转换。RTSP协议的默认端口是554，默认的承载协议为TCP。

目前对于RTSP在IOS客户端播放技术还是以FFMPEG+贴图的方式为主。

四、架构：

出于便于管理和扩展，带宽限制和多用户并发的考虑，商用方案都会采用流媒体服务器+WEB服务器+中转服务器+手机客户端的方案，其中：

• 流媒体服务器(streaming server)负责采集视频源并压缩编码并随时等待来自客户端的rtsp连接请求；

• WEB服务器(web server)便于发布和管理视频信息；

• 中转服务器(transmission server）是可选的，用于把来自client的RTSP请求转发给server,并把服务器端的实时流转给client，这样的好处是在相同带宽下支持更多的用户同时观看；

• 手机客户端(client)可以用手机内置的播放器（如nokia上的realplayer)或者自己开发的独立播放器，前者的好处是降低用户使用门槛，便于大规模应用；后者方便扩展和定制，满足更多的功能。

streaming server是整个方案的核心，目前主流的流媒体服务器解决方案如下：

1. helix server :借助Real公司的强大实力，这是目前最流行的方案， 可以支持所有音视频格式，性能稳定，是唯一可以横跨 Windows Mac 及 Linux， Solaris ，HP/UX 使用者流媒体服务的平台，支持在手机自带播放器播放。helix server免费的版本只支持1M流量，企业版很贵。当然你要就是另外一回事了

2. darwin server: 这是apple公司推出的开源的流媒体解决方案，支持格式没helix那么多，但由于是开源的免费的，对于开发者有很大的开发空间。

3. live555 media server:性能稳定,但支持格式比较少(只有mp3,amr,aac,mpeg4 es等几种流)，很少独立使用而一般作为系统的一部分。

4. Windows Media Server：仅限微软平台，就不考虑了。

手机端框架流程如下：

手机客户端与服务器端的传输协议目前常用有HTTP,RTSP两种：

早期的手机电视多用的HTTP，HTTP的优点有不用特殊的服务器软件，有IIS即可，不用考虑防火墙NAT，但HTTP不支持实时流，也会浪费带宽；RTSP则是当前流媒体传输的主流标准，连微软都抛弃了MMS而转而支持RTSP， RTSP可以支持客户端暂停回放停止等操作，基本不用考虑音视频同步问题（因为音频视频分别从不同RTP PORT读入缓冲）。值得说明的是，RTSP成功后，就开始RTP传输，分为RTP OVER TCP和RTP OVER UDP，前者保证每个数据包都能收到，如果没收到就重传，而且不用考虑防火墙NAT；后者只保证尽最大努力的传输，不会重传丢帧，实时性好，要解决防火墙NAT问题。如果对帧率要求比较高的手机电视，推荐采用UDP传输，因为延迟较大的重传数据对用户是没有意义的，宁可丢弃。

网络部分可采用强大的开源库live555实现RTSP/RTP协议，其性能稳定而且支持大多数音视频格式的传输。(当然ffmpeg也实现了网络传输部分,经过改动后也能用）对live555经过裁剪后移植到symbian和windows mobile，这部分工作在symbian真机调试比较费时。

视频解码部分当然还是采用ffmpeg,移植了mpeg4 sp/h.264解码器，在没有任何优化的情况下可支持32K,CIF,5-10fps的效果，对于一般的流媒体应用足够了。以后还要经过算法和汇编优化。解码后还需要经过yuv2rgb和scale，需要注意的是ffmpeg的解码有消隐区的说法，即qcif的图像其linesize不是176而是192，如果你发现解码后图像呈绿色，需用img_convert转一下(目的格式也是PIX_FMT_YUV420P)。symbian上用DSA直接写屏就行。windows mobile上可以用sdl.

音频解码主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge带宽支持的音频（aac效果比amrnb好),AMRWB是3G后的音频格式。在ffmpeg 0.5 release中已经支持amrnb/wb的fixed point解码，很强大。

五、分析与比较

作为最简单和原始的流媒体解决方案，HTTP渐进下载唯一显著的优点在于它仅需要维护一个标准的Web服务器，而这样的服务器基础设施在互联网中已经普遍存在，其安装和维护的工作量和复杂性比起专门的流媒体服务器来说要简单和容易得多。然而其缺点和不足却也很多，首先是仅适用于点播而不支持直播，其次是缺乏灵活的会话控制功能和智能的流量调节机制，再次是客户端需要硬盘空间以缓存整个文件而不适合于嵌入式设备等。基于RTSP/RTP的流媒体系统专门针对大规模流媒体直播和点播等应用而设计，需要专门的流媒体服务器支持，与HTTP渐进下载相比主要具有如下优势：

1. 流媒体播放的实时性。与渐进下载客户端需要先缓冲一定数量媒体数据才能开始播放不同，基于RTSP/RTP的流媒体客户端几乎在接收到第一帧媒体数据的同时就可以启动播放。

2. 支持进度条搜索、快进、快退等高级VCR控制功能。

3. 平滑、流畅的音视频播放体验。在基于RTSP的流媒体会话期间，客户端与服务器之间始终保持会话联系，服务器能够对来自客户端的反馈信息动态做出响应。当因网络拥塞等原因导致可用带宽不足时，服务器可通过适当降低帧率等方式来智能调整发送速率。此外，UDP传输协议的使用使得客户端在检测到有丢包发生时，可选择让服务器仅选择性地重传部分重要的数据(如关键帧)，而忽略其他优先级较低的数据，从而保证在网络不好的情况下客户端也仍能连续、流畅地进行播放。

4. 支持大规模用户扩展。普通的Web服务器主要针对大量小的HTML文件下载而进行优化，在传输大容量媒体文件方面缺少性能优势。而专业的流媒体服务器在大容量媒体文件硬盘读取、内存缓冲和网络发送等方面进行了优化，可支持大规模用户接入。

5. 支持网络层多播。网络层多播允许单一媒体流共享网络路径，同时发送到多个客户端，可大大缩减网络带宽需求。只有借助专门的流媒体服务器才能实现这一功能。

6. 内容版权保护。在渐进下载模式中，下载后的文件缓存在客户端硬盘的临时目录中，用户可将其拷贝至其他位置供以后再次播放。而在基于RTSP/RTP的流媒体系统中，客户端只在内存中维持一个较小的解码缓冲区，播放后的媒体数据随时清除，用户不容易截取和拷贝。

此外还可利用DRM等版权保护系统进行加密处理。尽管如此，基于RTSP/RTP的流媒体系统在实际的应用部署特别是移动互联网应用中仍然遇到了不少问题，主要体现在：

1. 与Web服务器相比，流媒体服务器的安装、配置和维护都较为复杂，特别是对于已经建有CDN(内容分发网络)等基础设施的运营商来说，重新安装配置支持RTSP/RTP的流媒体服务器工作量很大。

2. RTSP/RTP协议栈的逻辑实现较为复杂，与HTTP相比支持RTSP/RTP的客户端软硬件实现难度较大，特别是对于嵌入式终端来说。

3. RTSP协议使用的网络端口号(554)可能被部分用户网络中的防火墙和NAT等封堵，导致无法使用。虽然有些流媒体服务器可通过隧道方式将RTSP配置在HTTP的80端口上承载，但实际部署起来并不是特别方便。

苹果公司的HTTP Live Streaming正是为了解决这些问题应运而生的，其主要特点是：放弃专门的流媒体服务器，而返回到使用标准的Web服务器来递送媒体数据；将容量巨大的连续媒体数据进行分段，分割为数量众多的小文件进行传递，迎合了Web服务器的文件传输特性；采用了一个不断更新的轻量级索引文件来控制分割后小媒体文件的下载和播放，可同时支持直播和点播，以及VCR类会话控制操作。HTTP协议的使用降低了HTTP Live Streaming系统的部署难度，同时也简化了客户端(特别是嵌入式移动终端)软件的开发复杂度。此外，文件分割和索引文件的引入也使得带宽自适应的流间切换、服务器故障保护和媒体加密等变得更加方便。与RTSP/RTP相比，HTTP Live Streaming的最大缺点在于它并非一个真正的实时流媒体系统，在服务器和客户端都存在一定的起始延迟。而且目前主要面向移动多媒体应用，推荐支持的最高视频码率仅为800 Kbps，对于更高码率特别是高清视频的支持程度尚需进一步的探究和验证。归纳起来，上述三种流媒体协议的综合比较见表所示。

HTTP渐进下载、RTSP/RTP和HTTP Live Streaming等三种流媒体协议，对各自的基本方法和特点进行了介绍，特别是对HTTP Live Streaming协议进行了较为详细的描述，并在此基础上对三种流媒体协议进行了对比分析。总体来说，HTTP渐进下载系统部署起来最为简单，但仅适用于较小规模的短视频点播应用；

返回首页] [打印] [返回上页]   下一篇