ios流媒体直播整个框架介绍（HLS、RTSP）

一、HTTP（WebService）

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

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

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

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

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

答案是：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流媒体系统由内容准备、内容分发和客户端软件三部分组成，如图所示。

2. 内容分发

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

在移动互联 环境下，由于 络覆盖面的不同和信 强弱的变化，移动终端可能随时在不同的无线接入 络(例如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移动互联 的流媒体标准。

HTTP渐进下载、RTSP/RTP和HTTP Live Streaming等三种流媒体协议，对各自的基本方法和特点进行了介绍，特别是对HTTP Live Streaming协议进行了较为详细的描述，并在此基础上对三种流媒体协议进行了对比分析。总体来说，
HTTP渐进下载系统部署起来最为简单，但仅适用于较小规模的短视频点播应用；
基于RTSP/RTP的协议栈适合于大规模可扩展的交互式实时流媒体应用，但需要专门流媒体服务器的支持，安装和维护起来都较为复杂；
HTTP Live Streaming可直接部署于目前拥有广泛运营基础的Web服务器 络环境，不需要对 络基础设施进行升级改造，特别适合于对实时性要求不是太高的消费级移动互联 流媒体应用。