Linux 下的实时流媒体（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 Protocol，PRT）是在 Internet 上处理多媒体数据流的一种网络协议，利用它能够在一对一（unicast，单播）或者一对多（multicast，多播）的网络环境中实现传流媒体数据的实时传输。RTP 通常使用 UDP 来进行多媒体数据的传输，但如果需要的话可以使用 TCP 或者 ATM 等其它协议，整个 RTP 协议由两个密切相关的部分组成：RTP 数据协议和 RTP 控制协议。实时流协议（Real Time Streaming Protocol，RTSP）最早由 Real Networks 和 Netscape 公司共同提出，它位于 RTP 和 RTCP 之上，其目的是希望通过 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 所示：