[转]RTP协议栈简介

流媒体指的是在网络中使用流技术传输的连续时基媒体,其特点是在播放前不需要下载整个文件,而是采用边下载边播放的方式,它是视频会议、 IP 电话等应用场合的技术基础。 RTP 是进行实时流媒体传输的标准协议和关键技术,本文介绍如何在 Linux 下利用 JRTPLIB 进行实时流媒体编程。

随着 Internet 的日益普及,在网络上传输的数据已经不再局限于文字和图形,而是逐渐向声音和视频等多媒体格式过渡。目前在网络上传输音频 / 视频( Audio/Video ,简称 A/V )等多媒体文件时,基本上只有下载和流式传输两种选择。通常说来, A/V 文件占据的存储空间都比较大,在带宽受限的网络环境中下载可能要耗费数分钟甚至数小时,所以这种处理方法的延迟很大。如果换用流式传输的话,声音、影像、动画等多媒体文件将由专门的流媒体服务器负责向用户连续、实时地发送,这样用户可以不必等到整个文件全部下载完毕,而只需要经过几秒钟的启动延时就可以了,当这些多媒体数据在客户机上播放时,文件的剩余部分将继续从流媒体服务器下载。

流( Streaming )是近年在 Internet 上出现的新概念,其定义非常广泛,主要是指通过网络传输多媒体数据的技术总称。流媒体包含广义和狭义两种内涵:广义上的流媒体指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称,即流媒体技术;狭义上的流媒体是相对于传统的下载 回放方式而言的,指的是一种从 Internet 上获取音频和视频等多媒体数据的新方法,它能够支持多媒体数据流的实时传输和实时播放。通过运用流媒体技术,服务器能够向客户机发送稳定和连续的多媒体数据流,客户机在接收数据的同时以一个稳定的速率回放,而不用等数据全部下载完之后再进行回放。

由于受网络带宽、计算机处理能力和协议规范等方面的限制,要想从 Internet 上下载大量的音频和视频数据,无论从下载时间和存储空间上来讲都是不太现实的,而流媒体技术的出现则很好地解决了这一难题。目前实现流媒体传输主要有两种方法:顺序流( progressive streaming )传输和实时流( realtime streaming )传输,它们分别适合于不同的应用场合。

顺序流传输

顺序流传输采用顺序下载的方式进行传输,在下载的同时用户可以在线回放多媒体数据,但给定时刻只能观看已经下载的部分,不能跳到尚未下载的部分,也不能在传输期间根据网络状况对下载速度进行调整。由于标准的 HTTP 服务器就可以发送这种形式的流媒体,而不需要其他特殊协议的支持,因此也常常被称作 HTTP 流式传输。顺序流式传输比较适合于高质量的多媒体片段,如片头、片尾或者广告等。

实时流传输

实时流式传输保证媒体信号带宽能够与当前网络状况相匹配,从而使得流媒体数据总是被实时地传送,因此特别适合于现场事件。实时流传输支持随机访问,即用户可以通过快进或者后退操作来观看前面或者后面的内容。从理论上讲,实时流媒体一经播放就不会停顿,但事实上仍有可能发生周期性的暂停现象,尤其是在网络状况恶化时更是如此。与顺序流传输不同的是,实时流传输需要用到特定的流媒体服务器,而且还需要特定网络协议的支持。

实时传输协议( Real-time Transport ProtocolPRT )是在 Internet 上处理多媒体数据流的一种网络协议,利用它能够在一对一( unicast ,单播)或者一对多( multicast ,多播)的网络环境中实现传流媒体数据的实时传输。 RTP 通常使用 UDP 来进行多媒体数据的传输,但如果需要的话可以使用 TCP 或者 ATM 等其它协议,整个 RTP 协议由两个密切相关的部分组成: RTP 数据协议和 RTP 控制协议。实时流协议( Real Time Streaming ProtocolRTSP )最早由 Real NetworksNetscape 公司共同提出,它位于 RTPRTCP 之上,其目的是希望通过 IP 网络有效地传输多媒体数据。

2.1 RTP 数据协议

RTP 数据协议负责对流媒体数据进行封包并实现媒体流的实时传输,每一个 RTP 数据报都由头部( Header )和负载( Payload )两个部分组成,其中头部前 12 个字节的含义是固定的,而负载则可以是音频或者视频数据。 RTP 数据报的头部格式如图 1 所示:

1 RTP 头部格式

其中比较重要的几个域及其意义如下:

  • CSRC 记数( CC 表示 CSRC 标识的数目。 CSRC 标识紧跟在 RTP 固定头部之后,用来表示 RTP 数据报的来源, RTP 协议允许在同一个会话中存在多个数据源,它们可以通过 RTP 混合器合并为一个数据源。例如,可以产生一个 CSRC 列表来表示一个电话会议,该会议通过一个 RTP 混合器将所有讲话者的语音数据组合为一个 RTP 数据源。
  • 负载类型( PT 标明 RTP 负载的格式,包括所采用的编码算法、采样频率、承载通道等。例如,类型 2 表明该 RTP 数据包中承载的是用 ITU G.721 算法编码的语音数据,采样频率为 8000Hz ,并且采用单声道。
  • 序列号 用来为接收方提供探测数据丢失的方法,但如何处理丢失的数据则是应用程序自己的事情, RTP 协议本身并不负责数据的重传。
  • 时间戳 记录了负载中第一个字节的采样时间,接收方能够时间戳能够确定数据的到达是否受到了延迟抖动的影响,但具体如何来补偿延迟抖动则是应用程序自己的事情。

RTP 数据报的格式不难看出,它包含了传输媒体的类型、格式、序列号、时间戳以及是否有附加数据等信息,这些都为实时的流媒体传输提供了相应的基础。 RTP 协议的目的是提供实时数据(如交互式的音频和视频)的端到端传输服务,因此在 RTP 中没有连接的概念,它可以建立在底层的面向连接或面向非连接的传输协议之上; RTP 也不依赖于特别的网络地址格式,而仅仅只需要底层传输协议支持组帧( Framing )和分段( Segmentation )就足够了;另外 RTP 本身还不提供任何可靠性机制,这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下, RTP 一般是在传输协议之上作为应用程序的一部分加以实现的,如图 2 所示:

2 RTP 与各种网络协议的关系

2.2 RTCP 控制协议

RTCP 控制协议需要与 RTP 数据协议一起配合使用,当应用程序启动一个 RTP 会话时将同时占用两个端口,分别供 RTP RTCP 使用。 RTP 本身并不能为按序传输数据包提供可靠的保证,也不提供流量控制和拥塞控制,这些都由 RTCP 来负责完成。通常 RTCP 会采用与 RTP 相同的分发机制,向会话中的所有成员周期性地发送控制信息,应用程序通过接收这些数据,从中获取会话参与者的相关资料,以及网络状况、分组丢失概率等反馈信息,从而能够对服务质量进行控制或者对网络状况进行诊断。

RTCP 协议的功能是通过不同的 RTCP 数据报来实现的,主要有如下几种类型:

  • SR 发送端报告,所谓发送端是指发出 RTP 数据报的应用程序或者终端,发送端同时也可以是接收端。
  • RR 接收端报告,所谓接收端是指仅接收但不发送 RTP 数据报的应用程序或者终端。
  • SDES 源描述,主要功能是作为会话成员有关标识信息的载体,如用户名、邮件地址、电话号码等,此外还具有向会话成员传达会话控制信息的功能。
  • BYE 通知离开,主要功能是指示某一个或者几个源不再有效,即通知会话中的其他成员自己将退出会话。
  • APP 由应用程序自己定义,解决了 RTCP 的扩展性问题,并且为协议的实现者提供了很大的灵活性。

RTCP 数据报携带有服务质量监控的必要信息,能够对服务质量进行动态的调整,并能够对网络拥塞进行有效的控制。由于 RTCP 数据报采用的是多播方式,因此会话中的所有成员都可以通过 RTCP 数据报返回的控制信息,来了解其他参与者的当前情况。

在一个典型的应用场合下,发送媒体流的应用程序将周期性地产生发送端报告 SR ,该 RTCP 数据报含有不同媒体流间的同步信息,以及已经发送的数据报和字节的计数,接收端根据这些信息可以估计出实际的数据传输速率。另一方面,接收端会向所有已知的发送端发送接收端报告 RR ,该 RTCP 数据报含有已接收数据报的最大序列号、丢失的数据报数目、延时抖动和时间戳等重要信息,发送端应用根据这些信息可以估计出往返时延,并且可以根据数据报丢失概率和时延抖动情况动态调整发送速率,以改善网络拥塞状况,或者根据网络状况平滑地调整应用程序的服务质量。

2.3 RTSP 实时流协议

作为一个应用层协议, RTSP 提供了一个可供扩展的框架,它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来, RTSP 是一个流媒体表示协议,主要用来控制具有实时特性的数据发送,但它本身并不传输数据,而是必须依赖于下层传输协议所提供的某些服务。 RTSP 可以对流媒体提供诸如播放、暂停、快进等操作,它负责定义具体的控制消息、操作方法、状态码等,此外还描述了与 RTP 间的交互操作。

RTSP 在制定时较多地参考了 HTTP/1.1 协议,甚至许多描述与 HTTP/1.1 完全相同。 RTSP 之所以特意使用与 HTTP/1.1 类似的语法和操作,在很大程度上是为了兼容现有的 Web 基础结构,正因如此, HTTP/1.1 的扩展机制大都可以直接引入到 RTSP 中。

RTSP 控制的媒体流集合可以用表示描述( Presentation Description )来定义,所谓表示是指流媒体服务器提供给客户机的一个或者多个媒体流的集合,而表示描述则包含了一个表示中各个媒体流的相关信息,如数据编码 / 解码算法、网络地址、媒体流的内容等。

虽然 RTSP 服务器同样也使用标识符来区别每一流连接会话( Session ),但 RTSP 连接并没有被绑定到传输层连接(如 TCP 等),也就是说在整个 RTSP 连接期间, RTSP 用户可打开或者关闭多个对 RTSP 服务器的可靠传输连接以发出 RTSP 请求。此外, RTSP 连接也可以基于面向无连接的传输协议(如 UDP 等)。

RTSP 协议目前支持以下操作:

  • 检索媒体 允许用户通过 HTTP 或者其它方法向媒体服务器提交一个表示描述。如表示是组播的,则表示描述就包含用于该媒体流的组播地址和端口号;如果表示是单播的,为了安全在表示描述中应该只提供目的地址。
  • 邀请加入 媒体服务器可以被邀请参加正在进行的会议,或者在表示中回放媒体,或者在表示中录制全部媒体或其子集,非常适合于分布式教学。
  • 添加媒体 通知用户新加入的可利用媒体流,这对现场讲座来讲显得尤其有用。与 HTTP/1.1 类似, RTSP 请求也可以交由代理、通道或者缓存来进行处理。

RTP 是目前解决流媒体实时传输问题的最好办法,如果需要在 Linux 平台上进行实时流媒体编程,可以考虑使用一些开放源代码的 RTP 库,如 LIBRTP JRTPLIB 等。 JRTPLIB 是一个面向对象的 RTP 库,它完全遵循 RFC 1889 设计,在很多场合下是一个非常不错的选择,下面就以 JRTPLIB 为例,讲述如何在 Linux 平台上运用 RTP 协议进行实时流媒体编程。

3.1 环境搭建

JRTPLIB 是一个用 C++ 语言实现的 RTP 库,目前已经可以运行在 WindowsLinuxFreeBSD SolarisUnixVxWorks 等多种操作系统上。要为 Linux 系统安装 JRTPLIB ,首先从 JRTPLIB 的网站( http: //lumumba.luc.ac.be/jori/jrtplib/jrtplib.html )下载最新的源码包,此处使用的是 jrtplib- 2.7b.tar.bz2 。假设下载后的源码包保存在 /usr/local/src 目录下,执行下面的命令可以对其进行解压缩:

稿源:szu030606的专栏 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合技术 » [转]RTP协议栈简介

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录