QuickTime 流媒体编程介绍～～

最新推荐文章于 2024-06-28 18:01:33 发布

ligltc

最新推荐文章于 2024-06-28 18:01:33 发布

阅读量1.5k

点赞数

分类专栏： iPhone development 文章标签：编程服务器防火墙网络路由器存储

本文链接：https://blog.csdn.net/ligltc/article/details/6641223

版权

iPhone development 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

流媒体的传送包含从服务器经由网络（比如因特网）向客户机传送电影的过程。服务器将电影分解成可以通过网络传送的数据包。而在接收端，这些数据包被客户机重新组合，并且当电影还在传送时，客户机上已经可以播放该电影了。一系列互相关联的数据包称为流。

QuickTime 流媒体技术扩展了 QuickTime 的软件架构，为创建、传送、和接收多媒体流提供支持。这使得 QuickTime 编程人员能够创建支持实时接收多媒体的应用程序，以及创建制作和编辑流媒体内容的工具。对于现有的可以播放 QuickTime 电影的应用软件，通过对源码进行少量修改，甚至不用修改，就可以支持实时流媒体电影的播放。

流媒体不同于简单的文件传送。对于流媒体，当电影还在经由网络进行传送时，客户机便已经可以进行播放，而不必等到整部电影下载完成。实际上，一个流媒体的客户端可能永远不会真的下载一部流媒体电影，而只是在电影数据包到来的时候进行播放，然后就将其丢弃。

我们可以使用下列的协议来传送 QuickTime 流媒体：

HTTP (超文本传送协议)
FTP (文件传送协议)
RTP (实时传送协议)。

HTTP 和 FTP 实质上都是文件传送协议。任何用 QuickStart 选项保存的 QuickTime 电影都可以用这两种协议进行传送，因为 QuickTime 客户端软件在整个文件全部到来之前，就可以进行播放这种电影。

RTP 协议则用于实时流媒体。在这个协议中，电影的数据包按照实际的时间进行传送，所以一分钟的电影要在一分钟内经由网络传送完成。这些数据包都有时间戳，因此可以按时间顺序进行播放。由于数据包是按照实际的时间进行传送的，所以 RTP 流媒体除了应用于事先录制好的电影之外，还可以用于现场内容的传送。RTP 流媒体甚至可以混合承载这两种内容。

实时流媒体既能以一对一的方式发送 （单播），也能以一对多的方式发送（组播）。

单播

在单播（unicast）方式中, 客户端使用 RTSP 协议(实时流媒体协议)连接服务器，请求获取电影。之后，服务器基于 RTSP 协议对客户端做出响应，响应信息将电影描述为流媒体会话。流媒体会话由一个或者多个诸如视频流或音频流这样的数据流组成。服务器会通知客户端预计应收到多少个数据流，并且给出每个数据流的细节，比如数据流的媒体类型及所用的编码解码器。之后就遵循 RTP 协议，将实际的数据流发送给客户端。当一个 QuickTime 电影被按照 RTP 协议的约定，以流的方式进行传送的时候，电影中的每条轨道都作为一个独立的数据流进行传送，如图1-1所示。

图1-1 使用 RTSP 协议进行流媒体的单播

数据流可以包含现场内容，例如证券报价机或者无线广播；也可以包含事先存储的内容，例如 QuickTime 电影里的视频轨道。在接收到源于现场内容的单播流媒体时，客户端电影控制器将会带有“thumb”控件，该控件允许用户跳到电影的任意一点进行播放。这样，在将电影完全下载或者存放本地之前，客户已经可以选择电影的任意一点进行播放。客户端只须服务器发出请求，告诉服务器从指定的点开始传送电影流就可以了（见图1-2）。

图1-2 带 thumb 控件的电影控制器

请注意：RSTP 数据通过 TCP/IP 协议进行传送，而 RTP 数据则基于 UDP/IP 协议进行传送。如果客户机有防火墙保护，并且防火墙阻止 UDP 通过，那么电影开始播放时不会出现错误，但是屏幕上不会有媒体显示。苹果公司为几种操作系统提供的 RTSP 代理服务器，可以解决防火墙的问题。

组播

在组播（multicast）的传送方式中，网络的每条分支只传送一个数据流副本。当需要把数据流传送给大量的客户端时，这种方式能减少通讯负载。客户机通过“加入”组播来接收数据流。

客户端先通过打开一个 SDP（会话描述协议）文件，找出加入组播的方法。SDP 文件包含了客户端加入组播所需要的信息，例如组地址和端口号，同时也包含了单播方式中基于RTSP传送的数据流描述信息，见图1-3。SDP 文件通常张贴于网络服务器，它向客户端宣布即将开始的组播。

图1-3 QuickTime 允许计算机通过打开 SDP 文件加入组播

不是所有的路由器都支持组播的传送方式。如果 QuickTime 客户端的路由器不支持组播，则 QuickTime 客户端可以通过向反射器 (reflector) 请求数据流来实现对组播数据的接收。反射器是已经加入组播的 RTSP 服务器，它可以把组播转换成一系列单播，并以单播方式将数据流传送给请求该数据的客户端（见图 1-4）。在组播方式中，最初的服务器可以发送诸如音乐会或者新闻广播的现场内容，以及已经录制完成的电影。映射器按实际的时间传送数据流，它永远都是发送“现场”数据。

图1-4 您也可以通过反射器接收组播。

当 QuickTime 客户端浏览组播内容或者单播现场内容时，用户的电影控制器将不含有 “thumb” 控件（见图 1-5）。因此，用户可以停止或恢复播放，如果电影含有声音数据流，用户还可以进行音频控制，但是不可以在观看电影时向前跳动或者向后跳动。

图1-5 不带 thumb 控件的电影控制器

基于 RTP 或 HTTP 协议传送 QuickTime 流

QuickTime 支持基于 RTP 和 HTTP 协议的数据流传送。基于 RTP 传送数据流的主要优点是：

RTP 能用于现场转播和组播。
实时流媒体使用户可以直接观看时间很长的电影，或者进行持续的播放，而在本地最多只需存储几秒钟的数据。
使用 RTSP 控制下的 RTP 传送数据流的时候，用户可以直接跳到存放于服务器的电影的任意一点，然后进行播放，而不必下载中间数据。
RTP 可以以流的方式传送一条轨道，而 HTTP 只能传送整部电影。可以通过流媒体轨道（streaming tracks）把 RTP 数据流组合在电影里。流媒体轨道是 QuickTime 电影的一种轨道，它包含了指向流媒体内容的 URL。
QuickTime 电影可以包含流媒体轨道，也可以包含媒体数据存放于客户端计算机的非流媒体轨道。因此，我们可以把现场转播或因特网上的数据同客户端硬盘上的数据或 CD-ROM 里的材料组合在一部电影里。
RTP 使用 UDP/IP 协议，这种协议不会尝试重新传送已丢失的数据包。因此，组播和现场流传送都不能进行重新播放。

基于 HTTP 的流媒体的主要优点是：

HTTP 使用 TCP/IP 协议，确保所有的电影数据包都被传送，如果需要，该协议可以使应用程序对数据进行重新传送。
HTTP 不会试图以实际的时间来传送数据流。要按实际的时间传送数据流，网络的带宽必须大于电影的数据传送速率。如果没有足够的带宽，则基于 HTTP 传送的数据流会使客户端将媒体数据存储在本地机器上，并且在存储的数据足够多之后才进行播放。
大多数防火墙和网络配置策略不需要修改就可以通过基于 HTTP 的数据流。
任何 QuickTime 电影都可以基于 HTTP 协议来进行传送。QuickTime 支持对视频、音频、文本、以及 MIDI 进行基于 RTP 协议的传送。如果要传送的电影含有诸如动画（sprites）这样的媒体类型，则需要基于 HTTP 协议来进行传送。

多媒体流

早期版本的 QuickTime 支持对整个电影文件进行基于 HTTP 协议的单播。

现在，QuickTime 支持实时传送协议，该协议可以用于组播和转播现场内容，同时还可以用于事先存储的电影的单播。另外，QuickTime 也支持基于 RTP 协议传送单一的电影轨道，这使开发人员可以将现场的或者存储在异地的内容整合在本地电影中。

QuickTime 支持使用 RTSP 协议来进行流传输控制。QuickTime 包含客户端软件，可以直接从路由器接收组播。客户端软件是标准化的，它可以和诸如 VIC，VAT 或者 Cisco 的 IP/TV 等产品共同使用。QuickTime 可以识别 SDP 文件里的信息，并利用这些信息进行“调音”，从而进入组播流媒体会话。

QuickTime 支持对音频、视频、MIDI、文本（包含 HREF 轨道）和 tweens 进行基于 RTP 的流传送。其它类型的媒体不被支持。然而，含有其它媒体类型的电影可以和流媒体内容整合在一起。

QuickTime 支持 IETF 定义的 RTP 标准负载类型：