目前移动互联网较为广泛的三种流媒体协议为：HTTP渐进下载流媒体协议，基于RTSP/RTP的实时流媒体协议栈，以及HTTP Live Streaming协议(苹果提出)。

HTTP渐进下载

该协议公是在完全下载模式上做了一些小的改进。在客户端播放前仅需等待一段短时间 用于下载和缓冲媒体文件最前面的一部分数据，之后便可以一边下载一边播放。HTTP渐进下载流媒体播放采用标准HTTP协议在Web服务器和客户端之间递送媒体数据，客户端需要在硬盘上缓存所有前面已经下载的媒体数据，播放过程中只能在已经下载的媒体数据时间范围内进行快进、快退等操作。HTTP渐进下载流媒体播放仅支持点播，而不能支持直播。

RTSP/RTP流媒体协议

RTSP/RTP是目前业界最为流行和广为采用的 实时流媒体协议。它实际上由一组在IETF中标准化 的协议所组成,包括RTSP(实时流媒体会话协议), SDP(会话描述协议),RTP(实时传输协议),以及针 对不同编解码标准的RTP净载格式等,共同协作来构成一个流媒体协议栈。

RTSP是用来建立和控制一个或多个时间同步的 连续音视频媒体流的会话协议。通过在客户机和服务 器之间传递RTSP会话命令,可以完成诸如请求播放、 开始、暂停、查找、快进和快退等VCR控制操作。

RTP又称为实时传输协议,用于实际承载媒体数 据并为具有实时特性的媒体数据交互提供端到端的传输 服务。

RTSP/RTP流媒体协议栈的使用需要专门的流媒 体服务器进行参与。

HTTP Live Streaming协议

HTTP Live Streaming最初是苹果公司针对其 信息通信技术 iPhone、iPod、iTouch和iPad等移动设备而开发的流 媒体协议,后来在桌面QuickTime播放器中也得到了应用。

HTTP Live Streaming允许内容提供者通过普通 Web服务器向上述客户端提供接近实时的音视频流媒 体服务,包括直播和点播。

HTTP Live Streaming支 持将同一节目编码为不同码率的多个替换流,客户端软 件可以根据网络带宽的变化在这些不同码率的替换流之间进行智能切换。还支 持通过媒体加密和用户认证等方式来达到媒体版权保护。

一个典型的HTTP Live Streaming流媒体系统由 内容准备、内容分发和客户端软件三部分组成 HTTP Live Streaming Overview

内容准备

内容准备部分负责将输入的音视频媒体内容转换成 为适合于内容分发组件进行递送的格式。 对于视频直播,编码器首先将摄像机实时采集的音 视频数据压缩编码为符合特定标准的音视频基本流(目 前苹果的系统仅支持H.264视频和AAC音频),然后再 复用和封装成为符合MPEG-2系统层标准的传输流 (TS)格式进行输出。

流分割器(Stream Segmenter)负责将编码器输出的 MPEG-2 TS流分割为一系列连续的、长度均等的小TS文件(后缀名为.ts),并依次发送至内容分发组件中的 Web服务器进行存储。流分割器还创建了一个含有指向这些小TS文件指针的索引文件（后缀名为 .m3u8）,同样放置于Web服务器之中。这个索引文件可以看作是一个连续媒体流中的播放列表滑动窗口,每当流分割器生成一个新的TS文件时,这个索引文件的内容也被更新,新的文 件URI(统一资源定位符)加入到滑动窗口的末尾,老的 文件URI则被移去,这样索引文件中将始终包含最新的 固定数量的x个分段。流分割器还可以对 其生成的每个小TS文件进行加密,并生成相应的密钥文件。

采用MPEG-2 TS格式来对编码后的媒体流 进行统一封装,是因为它能够将音视频媒体流严格按时 序进行交织复用,任意截取和分段后,每一个分段都可 能不依赖于之前的分段而独立进行解码和播放。

内容分发

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

.m3u8 : application/x-mpegURL或vnd.apple.mpegURL
.ts : video/MP2T

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

客户端软件

通常情况下,客户端软件通过访问Web网页中的 URL链接来获取和下载一个流媒体会话的索引文件。 这个索引文件进一步指定了服务器上当前可用的TS格式媒体文件、解密密钥和其他替换流的位置。

对于选定的媒体流,客户端依次下载索引文件中 列出的每一个可用媒体文件。当这些媒体文件缓冲够一定数量后,客户端将它们按顺序重新拼装成一个连贯的 TS流,然后发送至播放器进行解码和呈现。

对于加密的媒体文件,客户端还负责根据索引文件的指引来获取解密密钥,提供用户认证接口,并按需进行解密。

对于视频点播,上述过程不断持续下去,直到客户 端碰到索引文件中的#EXT-X-ENDLIST标签。

对于视频直播,索引文件中不存在#EXT-X- ENDLIST标签,客户端将周期性地向Web服务器重新 请求获取该索引文件的更新版本,然后在这个更新版的 索引文件中查找新的媒体文件和解密密钥,并将它们的 URI添加至下载队列的末尾。

HTTP Live Streaming并不是一个真正实时的流媒体系统,这是因为对应于媒体分段的大小和持续时间有一定潜在的时间延迟。在客户端中,至少在一个分段媒体文件被完全下载之后才能够开始播放,而 通常要求下载完成两个分段媒体文件之后才开始播放以保证不同分段音视频之间的无缝连接。此外,在客户端开始下载之前,必须等待服务器端的编码器和流分割器 至少生成一个TS文件,这也会带来潜在的时延。在推荐配置下,HTTP Live Streaming系统的典型时延约在30s左右。

###流媒体协议比较 —— | 渐进下载播放| RTSP/RTP | HTTP Live Streaming —|———–|———–|——————– 服务器端实现 | 普通Web服务器 | 流媒体服务器 | 普通Web服务器 客户端实现 |容易 | 较难 | 容易 系统安装、配置 |简单 |复杂 | 简单 支持业务类型 |点播 |直播、点播 | 直播、点播 实时性(起始时延) |>30s | <2s | 约30s(推荐配置下) 客户端缓冲区 |硬盘,文件大小 |内存,小 | 内存,较小 VCR支持 | 部分支持 | 支持,定位精度高 | 支持,定位精度略差 网络带宽适应 | 不支持 | 部分服务器支持 | 支持(灵活流间切换) 服务器故障保护 | 不支持 | 不支持 | 支持 DRM支持 | 差 | 较好 | 好 防火墙穿透性 | 好 | 差 | 好 网络层多播 | 不支持 | 支持 | 不支持 适用范围 | 低码率短视频(如广告、片花等) | 大规模、低延迟实时流媒体系统 | 嵌入式移动流媒体(实时性要求不是太高)