Ｐ２Ｐ流媒体点播系统的应用

任从容

[摘要]本文在分析了通用流媒體协议RTP/RTCP/RTSP的工作原理,以及传统C/S结构的流媒体系统的应用模式的基础上,结合P2P下流传输的特点提出P2P流媒体点播系统的应用模式。

[关键词]点播系统 流媒体传输协议 应用模式

点播系统的应用模式是指点播系统与用户的直接交互方式,在传统C/S结构的流媒体系统的应用模式是:用户通过通用播放器与流媒体服务器进行交互,二者之间的通信由一系列标准流媒体传输协议提供保证。在P2P环境下我们仍然希望能通过通用播放器将流媒体内容展现给用户。为此,我们跟据P2P的特点,对传统的应用模式进行了一些改动。以下我们先介绍流媒体协议族以及传统C/S模式下的应用模式。最后,讨论怎样在P2P下利用流媒体协议与用户交互。

一、流媒体传输协议

1.实时传输协议(RTP)

实时传输协议 RTP (Real Time Transport Protocol)为数据提供了具有实时特征的终端对终端传送服务,如在组播或单播网络服务下的交互式视频音频或仿真数据。应用程序在 UDP上执行 RTP,以便使用其多路技术和检验和服务;还有传输协议函数的协议捐助部分。但是 RTP可以与其它适合的底层网络或传输协议共同使用。如果底层网络提供组播分配,那么 RTP可以使用该组播分配支持多路目标文件的数据传输。

RTP本身并没有为及时传送提供任何机制或其它质量服务 QoS保证,但它依赖于低层服务去实现这一过程。RTP并不能保证传送过程或防止无序传送,也不能确定底层网络的可靠性。RTP实行有序传送,RTP中的序列号允许接收方重建发送方的包序列,同时序列号也能用于决定适当的包位置,例如在视频译码中,不需要顺次解码。完整的RTP由两个具体的协议组成。

(1)RTP。传送具有实时属性的数据。

(2)RTP控制协议 (RTCP)。监控服务质量并传送正在进行的会话参与者的相关信息。

RTP协议头的结构如图1所示。

V―版本。识别 RTP版本。

P―间隙(Padding)。设置时,数据包包含一个或多个附加间隙位组,其中这部分不属于有效载荷。

X―扩展位。设置时,在固定头后面,根据指定格式设置一个扩展头。

CSRC Count―包含 CSRC标识符(在固定头后)的编号。

M―标记。标记的解释由 Profile文件定义。允许重要事件如帧边界在数据包流中进行标记。

Payload Type―识别 RTP有效载荷的格式,并通过应用程序决定其解释。Profile文件规定了从 Payload编码到 Payload格式的缺省静态映射。另外的 Payload Type编码可能通过非 RTP方法实现动态定义。

Sequence Number―每发送一个 RTP数据包,序列号增加1。接收方可以依次检测数据包的丢失并恢复数据包序列。

Timestamp―反映 RTP数据包中的第一个八位组的采样时间。采样时间必须通过时钟及时提供线性无变化增量获取,以支持同步和抖动计算。

SSRC―同步源。该标识符随机选择,旨在确保在同一个 RTP会话中不存在两个同步源具有相同的 SSRC标识符。

CSRC―贡献源标识符。识别该数据包中的有效载荷的贡献源。

2. RTP控制协议(RTCP)

RTP控制协议RTCP(Real Time Control Protocol)采用与数据包相同的分发机制,将控制包周期性传输到所有会话参与者中。底层协议必须提供数据和控制包的多路发送,例如使用不同的 UDP端口号。RTCP主要完成四个功能服务。

(1)RTCP提供数据分发质量反馈信息。这是 RTP作为传输协议的部分功能并且它涉及到了其它传输协议的流控制和拥塞控制。

(2)RTCP为 RTP源携带一个持久性传输层标识符,称为规范名或 CNAME。由于一旦发现冲突或程序重启时,SSRC标识符会随之改变,所以接收方需要 CNAME来跟踪每一个参与者。同时接收方还要求 CNAME能够与一组相关 RTP会话中来自于给定参与者的多重数据流相关联,例如同步视频和音频。

(3)上述前两个功能要求所有的参与者都要发送 RTCP包,因此必须控制速率以便 RTP按比例增加大量的参与者。通过每一个参与者发送各自的控制包给其它所有参与者,每一个参与者能够独立观察到参与者数量,该数量可用来计算控制包的发送速率。

(4)OPTIONAL功能用于传送最少会话控制信息,例如在用户界面显示参与者标识。这对于“松散受控”会话(在没有成员控制或阐述协商的情况下,参与者可以加入或退出该会话)是非常有用的。

上述功能 1～3适用于所有环境,尤其是 IP组播环境。RTP应用程序设计者应该避免设计只能工作于单播模式并且不能增加到大量数量的机制。在某些情况下如单向链接中,不可能有来自接收方的反馈,所以 RTCP的传输就可能由发送方和接收方分别独立控制。

Version―识别 RTP版本。 RTP数据包中的该值与 RTCP数据包中的一样。当前规范定义的版本值为 2。

P―间隙(Padding)。设置时,RTCP数据包包含一些其它 padding八位位组,它们不属于控制信息。Padding的最后八位是用于计算应该忽略多少间隙八位位组。一些加密算法中需要计算固定块大小时也可能需要使用 Padding字段。在一个复合 RTCP数据包中,只有最后的个别数据包中才需要使用 padding,这是因为复合数据包是作为一个整体来加密的。

RC―接收方报告计数。包含在该数据包中的接收方报告块的数量,有效值为 0。

Packet type―包括常量 200,识别这是一个 RTCP SR数据包。

Length― RTCP数据包的大小(32位字减去 1),包含头和任意间隙(偏移量的引入使得 0成为有效值,并避免了扫描复合 RTCP数据包过程中的无限循环现象,而采用 32位字计数方法则避免了对 4的倍数的有效性校验)。

3.实时流协议(RTSP)

实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体,如音频和视频。尽管连续媒体流与控制流交叉是可能的,RTSP本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控制。RTSP提供了一个可扩展框架,实现实时数据(如音频与视频)的受控、按需传送。数据源包括实况数据与存储的剪辑。RTSP用于控制多个数据发送会话,提供了选择发送通道(如 UDP、组播 UDP与 TCP等)的方式,并提供了选择基于 RTP的发送机制的方法。

目前还没有 RTSP连接的概念;服务器维护由识别符标识的会话。RTSP会话不会绑定到传输层连接,如 TCP。在 RTSP会话期间,RTSP客户端可打开或关闭多个对服务器的可靠传输连接以发出 RTSP请求。它也可选择使用无连接传输协议,如 UDP。

RTSP控制的流可能用到 RTP,但 RTSP操作并不依赖用于传输连续媒体的传输机制。RTSP在语法和操作上与 HTTP/1.1类似,因此 HTTP的扩展机制在多数情况下可加入 RTSP。然而,在很多重要方面 RTSP仍不同于 HTTP。

(1)RTSP引入了大量新方法并具有一个不同的协议标识符。

在大多数情况下,RTSP服务器需要保持缺省状态,与 HTTP的无状态相对。

(2)RTSP中客户端和服务器都可以发出请求。

(3)在多数情况下,数据由不同的协议传输。

(4)RTSP使用 ISO-10646(UTF-8)而并非 ISO 8859-1,与当前的国际标准 HTML相一致。

(5)URI请求总是包含绝对 URI。为了与过去的错误相互兼容,HTTP/1.1只在请求过程中传送绝对路径并将主机名置于另外的头字段。

该协议支持如下操作:

(1)从媒体服务器上检索媒体。用户可通过 HTTP或其它方法提交一个演示描述请求。

(2)媒体服务器邀请进入会议。媒体服务器可被邀请参加正进行的会议,或回放媒体,或记录部分或全部演示。

(3)将新媒体加到现有演示中。如服务器能告诉客户端接下来可用的媒体内容,对现场直播显得尤其有用。

4.流媒体传输协议在C/S结构中的应用模式

流媒体的传统应用模式是在客户端/服务器C/S(或B/S)下工作。其工作方式如图3所示。客户端先向WEB服务器请求媒体的描述信息(Media MetaInfo)。再跟据此信息连接特定的流媒体服务器,通过RTSP协议进行指令操作,RTP协议进行流媒体数据传输,RTCP协议进行流量控制及拥塞反馈。

二、P2P流媒体点播系统的应用模式

与C/S架构下的流媒体点播模式不同在P2P环境下,流媒体数据的传输有以下这几个特点。

1.流媒体数据不是来自流媒体服务器,而是来自于不同的对等节点。

2.用户收到的流媒体数据不只是供用户自己使用,可能还需要保存下来为其它用户提供服务。

3.直接采用RTP/UDP的流媒体传输方式,可能会在传输过程中丢包(当然,可在应用层实现数据包的重传),少量的丢包也许是用户可以忍受的,但其它节点再向其请求数据时,丢包的损失进一步被放大。

因此,如圖4所示,在我们系统的应用模式中,数据在网络传输过程中没有流化(没有对数据进行RTP封包),只是将一般的流媒体文件数据分片发送到点播节点,点播节点通过数据分片重组模块对来自不同节点的数据进行排序重组,并输出到一个数据分片队列。数据流化模块实际上实现了一个小型的本地流媒体服务器。此模块从数据分片队列中提取数据,对数据进行流化处理,并在本地回环地址loopback address上开启一个提供RTSP服务的端口,接收响应用户的RTSP请求。当用户用播放器连接回环地址上的服务端口时,数据流化模块将流化后的数据通过RTP协议发送给播放器,用户即可看到点播的流媒体内容,并可通过RTSP进行VCR操作。

参考文献:

[1] Network Working Group.RFC1889.RTP: A Transport Protocol for Real-Time Applications.Lawrence Berkeley National Laboratory, 1996.

[2] Network Working Group.RFC3550.RTP: A Transport Protocol for Real-Time Applications.Columbia University, 2003..

[3] Network Working Group.RFC2326.Real Time Streaming Protocol (RTSP). Columbia University,1998.

[4]李炜,曾珂,戴琼海.基于RTSP协议流媒体服务器的实现.