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

最新推荐文章于 2024-09-18 21:15:36 发布

少一些浮躁__

最新推荐文章于 2024-09-18 21:15:36 发布

阅读量5.5k

点赞数 1

分类专栏： IOS

本文链接：https://blog.csdn.net/fengjun10000/article/details/53431634

版权

本文深入介绍了基于HTTP的流媒体技术，包括HTTP Live Streaming (HLS) 和 Real Time Streaming Protocol (RTSP)。HLS通过HTTP协议实现流媒体直播和点播，支持网络自适应流间切换，但存在延迟问题。RTSP提供实时流控制，支持VCR操作，但部署和实现更为复杂。内容涵盖了HTTP渐进下载的原理、HLS的分段与索引文件、RTSP的关键协议组件以及三者的应用场景与优缺点比较。

摘要由CSDN通过智能技术生成

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