基于RTPRTCP和RTSP协议的流媒体快速流间同步机制

基于RTP/RTCP和RTSP协议的流媒体快速流间同步机制卢日北京邮电大学电信工程学院，北京（100876）E-mail：luri_149@摘要：多媒体同步技术是流媒体技术中一项关键的技术，在通常的流媒体客户端设计中，同步信息的建立依赖于典型地承载在UDP协议之上RTCP包，导致媒体对象的第一回放时间具有不可预测性。

为了缩短回放前的等待时间，本文基于RTP/RTCP协议和RTSP协议，提出了一种快速确定媒体流间同步关系的机制。

关键词：RTP，RTSP，流媒体，流间同步1. 引言流媒体技术是近几年Internet飞速发展的产物，它融合了媒体数据的采集、编解码、存储以及网络传输等多项技术，它的出现有效地解决了音频、视频等媒体数据在计算机网络中的实时传输的问题，被广泛应用于远程教育、视频点播、视频会议、IPTV等业务中。

多媒体同步技术[1]是流媒体技术中一项关键的技术，已经引起了国内外的广泛关注。

多媒体同步技术的目的就是向用户展示多媒体信息时，保持多媒体对象内和对象间固有的时域约束关系。

多媒体同步包含两类同步：一类是流内同步，其主要任务是保证媒体流内部的相对时态关系，也就是按一定的时间要求传送每一个多媒体对象，并在客户端能够进行连续的展现。

另一类是流间同步，主要任务是维护媒体对象间的时间关系，如音频和视频之间的时间关系（即唇同步）、音视频与文字之间的时间关系等等。

RTP/RTCP协议[2]是流媒体协议栈[3]中一个重要的组成部分，它承担了媒体数据的传送任务，RTSP协议[4]则在流媒体协议栈中负责控制媒体数据的有效传输，RTSP和RTP/RTCP 协议是整个流媒体协议栈的核心部分。

本文主要针对IP网络环境，并基于RTP/RTCP协议和RTSP协议，利用RTP时间戳、RTCP包中RTP时间戳和NTP（Network Time Protocol）时间戳的映射关系以及RTSP中RTP时间戳和NPT（Normal Play Time）时间戳的映射关系，快速地确定媒体流间的同步关系，同时还可以消除各媒体流间的同步依赖关系，使得流间同步的复杂度与媒体流的数目无关。

2. RTP/RTCP协议简介实时传输协议RTP（Realtime Transport Protocol）为具有实时特征的数据流提供端到端的传输服务，其目的是提供时间信息和实现流同步。

RTP的典型应用建立在UDP之上，并且提供了部分传输层协议的功能，但RTP也可以在其它的网络或传输层协议（如TCP）上工作。

RTP本身并不监控和传输会话的服务质量（QoS）和会话的相关信息，它依靠实时传输控制协议RTCP（Realtime Transport Control Protocol）来完成，在RTP会话期间，各参与者周期性地传送RTCP包，包中含有RTP时间戳与NTP时间戳的映射关系、已发送的数据包的数量、丢失的数据包的数量等信息，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型，客户端则可以利用这些信息实现媒体间的同步。

RTP和RTCP的配合使用，能以有效的反馈和最小的开销使传输效率最佳化。

图1给出了RTP/RTCP协议的典型应用在流媒体协议栈中的位置。

图1 流媒体协议栈3. RTSP协议在同步控制中的作用实时流协议RTSP（Real Time Streaming Protocol）是一种用于控制实时数据流有效传输的应用层协议，同时也提供对实时数据流的远程VCR（Video Cassette Recorder）功能，如播放、暂停、快进、快退等，也就是说通过RTSP协议，流媒体客户端可以实现对多媒体服务器的网络远程控制，其中实时数据流的传输则可以借助于RTP。

在RTSP协议中，所有的操作都是通过服务器和客户端的消息应答机制完成的，其中消息包括请求和应答两种，消息的格式由一个起始行（请求行或状态行）、若干个头域，以及一个可选的消息体组成。

RTSP 协议的请求和应答消息主要通过起始行中的请求方法（method）字段和状态码（status code）字段完成，其中常用的请求方法有OPTIONS 、DESCRIBE、SETUP、PAUSE、PLAY、TEARDOWN等，状态码是一个三位数字，用于反馈请求的执行情况。

RTSP协议在流媒体协议栈中的位置如图1所示。

下面介绍RTSP协议在多媒体同步控制中起重要作用的两个头域Range和RTP-Info：Range：本文所提到的Range头域特指出现在RTSP的PLAY方法应答消息中的Range头域，该头域给出待传输节目的播放时间范围，所支持的格式有smpte、npt和clock，而且npt格式是必须支持的，因此本文选用npt格式进行讨论。

如“Range: npt=10-30”表示待发送的节目播放范围是10秒（相对于节目的起始点）到30秒。

RTP-Info：该头域必须出现在RTSP的PLAY方法应答消息中，用于告知流媒体客户端随后RTP会话中的一些参数：url：指示与随后RTP参数对应的流的URL；seq：指示接下来的RTP会话中该流的第一个RTP包的序列号。

该域用于协助流媒体客户端进行选时播放，流媒体客户端可以通过该域来区分选时播放前后的RTP包，从而丢弃选时播放前的RTP包；rtptime：该域指示该流中与Range域中起始时间对应的RTP时间戳，即用于建立该流的RTP时间戳与NPT时间戳的映射关系。

当某条媒体流在Range头域中所指示的起始一段时间内不会产生媒体数据包时，该参数可能会不出现，但在流媒体业务中基本不会出现这种情况，因此本文在后面的讨论中都假设该参数存在。

尽管RTCP可以用于将RTP时间戳对应到NTP时间戳上，却并不能建立RTP时间戳与NPT时间戳的映射关系，而且，由于该映射关系是通过RTSP控制信道传送的，因此可以确保节目刚开始播放和选时播放时该信息的可靠性，从而达到快速同步的目的，具体的同步机制将在下一节中介绍。

4. 快速流间同步机制多媒体流间同步的目的在与向用户展现媒体信息时，维持各媒体流间固有的时域约束关系。

在流媒体这种基于C/S模型的系统中，媒体流数据可以通过不同的信道进行传送，加之网络的时延抖动以及客户端和服务端时钟的差异等因素，使得媒体流间的时域约束关系遭到破坏，RTP协议便是在这种背景下提出来的，在为媒体数据流提供端到端传输服务的同时，还为媒体流提供时间信息，用于恢复媒体流间的时域约束关系[5]。

在使用RTP协议进行媒体数据传输时，每个RTP包中都携带有一个32位的RTP时间戳，该时间戳用于指定或导出包中各媒体访问单元（如音频帧等）的RTP时间戳，从而确定媒体流内各访问单元的相对时间关系，但由于RTP时间戳的起始点的随机性以及时间戳频率的差异，仅凭RTP时间戳并不能为恢复媒体流间的时域约束关系提供足够的信息，还需借助发送方传送过来的RTCP发送者报告SR（Sender Report），该报告中含有相关媒体流的RTP时间戳与NTP时间戳的映射关系，其中NTP时间戳是一个采用NTP时间戳格式表示的绝对时间（相对于1900年1月1日0点0分0秒），通过这种映射关系可以确定不同媒体流的RTP时间戳的关系，从而达到流间同步的目的。

但是这种RTP时间戳同步法存在一个问题：媒体流间第一次同步关系的确立依赖于各流的第一个RTCP SR包。

也就是说流媒体客户端必须要等待RTP会话中所有流的第一个RTCP SR报告来实现流间的第一次同步，从而会推迟媒体对象的起始回放时间，该问题在进行选时播放时显得尤为突出，因为下一个RTCP SR的发送时间可能会在选时后3秒甚至更长。

另外，考虑到RTP的典型应用是建立在UDP之上的，在网络存在丢包的情况下，有可能第一个甚至随后的多个RTCP SR包都被丢弃，这样所造成的媒体对象回放延时将十分严重而且不可预测。

基于这样的考虑，本文提出结合RTSP的PLAY方法应答消息中的Range头域和RTP-Info 头域来协助RTP的流间同步。

具体的实施方法是：流媒体客户端在接收到PLAY方法的应答消息后，将RTP-Info头域中各流的rtptime参数提取出来，并分别与NTP时间戳格式的0对应，即将各媒体流的第一个包的RTP时间戳映射到一个虚拟的NTP时间戳0上，在接下来RTP会话过程中，利用收到的第一个RTCP SR包计算出实际的NTP时间戳与NTP时间戳0的差值diff，而且随后的RTCP SR包的NTP时间戳都需要先减去该diff再与RTP时间戳建立映射关系。

也就是说在会话开始时，流媒体客户端首先利用RTP-Info头域中的rtptime参数建立RTP时间戳与本地虚拟NTP时间戳之间的对应关系，然后利用随后收到的第一个RTCP SR包，建立服务器端实际NTP时间戳与该虚拟NTP时间戳的映射关系，从而间接地建立起RTP时间戳与服务器端实际NTP时间戳的映射关系，后续的RTCP SR包则用于校准该映射关系，如图1所示，图中给出了两条媒体流的同步过程，多条流的情况与此类似。

该方案的有如下几个优点：1）流媒体客户端在会话开始时便可以建立RTP时间戳与NTP时间戳的对应关系，从而可以提前媒体对象的回放起始时间。

2）具有抗丢包能力。

由于媒体间的同步关系的是通过RTSP控制信道来建立的，因此即使在RTP会话中有RTCP SR包的丢失，也不会影响到媒体的第一回放时间。

3）当会话中有多条媒体流存在时，各媒体流间的同步无依赖关系，从而使得流间同步的复杂性与媒体流的数目无关。

4）由于此方案将RTP时间戳映射到的本地虚拟NTP时间戳的起始值为0，因此，该虚拟NTP 时间戳可直接作为该媒体流的绝对显示时间戳，从而减少了流媒体客户端计算量。

图2 两条媒体流的同步过程下面叙述流媒体客户端对媒体流实施各种VCR 控制后实现流间同步的详细步骤。

4. 1 第一次发送RTSP PLAY 请求当流媒体客户端利用RTSP 协议的DESCRIBE 、SETUP 等方法完成会话协商后，会向流媒体服务器发送RTSP PLAY 方法请求流媒体服务器开始发送媒体数据，为了实现流间同步，在流媒体客户端接收到该PLAY 方法的成功响应（即状态码为2xx ）后，应该顺序执行如下操作：1) 提取该PLAY 响应的RTP-Info 头域中各流的rtptime 参数；2) 将各流的rtptime 参数值对应到NTP 时间戳0上；3) 收到各流的第一个RTCP SR 包时计算出实际的NTP 时间戳与NTP 时间戳0的差值diff ；4) 收到各流的第n （n>1）个的RTCP SR 包时，先该SR 包的实际的NTP 时间戳减去diff ，然后与该SR 包的RTP 时间戳建立对应关系；如果不考虑流间同步的问题，流媒体客户端在执行完第2步操作后，便可以开始媒体对象的解码和回放，第3步和第4步操作则用于校准RTP 时间戳与NTP 时间戳的映射关系。