如图1.1所示,通过IP网络传输实时音视频数据的系统的核心是RTP协议:RTP协议提供了通用的、独立于信令和应用的媒体传输层。在我们进一步详细考察RTP协议及那些使用RTP协议的系统的设计之前,很有必要先大概了解在一个系统中RTP发送者和接收者的职责。
RTP发送者行为
发送者的负责采集和转换音视频数据,生成RTP数据包,然后传输这些RTP数据包。此外,发送者也会参与纠错和拥塞控制,这可以根据接收者反馈来调整发送的媒体流来实现。发送过程如图1.2所示。
Figure 1.3. BlockDiagram of an RTP Receiver
发送者采集未压缩的音视频数据到缓冲区,然后用缓冲区中的数据生成压缩的数据帧。取决于不同的压缩算法,这些数据帧可能会用不同方法生成,压缩的数据帧可能会依赖此帧数据前面和后面的数据。
压缩的数据帧被封装为RTP包,用来发送。如果帧比较大,那么可能会被分片封装到几个RTP包中;如果比较小,那么可能几个帧被封装到一个RTP包中。根据所使用的纠错方案,在传输之前可能会使用信道编码器生成纠错包或者重新排序这些数据包。
RTP数据包发送之后,与这些RTP包对应的媒体数据最终会被释放。发送者不能丢弃那些会被纠错算法或者编码算法所用到的数据。这意味着根据所使用的编解码器和纠错方案,在对应的数据包发送之后,发送者必须把这些数据缓冲一段时间。
发送者负责为其生成的媒体流周期性的生成状态报告,包括音唇同步所需要的信息。发送者还接收其他参与者发送的接收质量反馈并使用这些信息来调整其发送的媒体流。
RTP接收者行为
接收者负责从网络上收集RTP数据包,恢复那些丢失的数据包,恢复时序,解码媒体数据并把结果呈现给用户。接收者还发送接收质量反馈,这使得发送者可以调整其发送的媒体流。接收者还在会话中维护一个参与者数据库。图1.3是一个可能的接收过程框图,在某些时候,根据具体需求的不同,其操作过程会有所不同。
Figure 1.2. BlockDiagram of an RTP Sender
接收过程的第一步是从网络收集RTP数据包,验证它们的正确性并把它们插入一个和特定发送者相关的输入缓冲区。然后从输入缓冲区收集数据包并把它们送入一个可选的信道编码例程做丢包恢复。在信道编码器之后,数据包被插入到一个和某个特定源相关的播放缓冲中。播放缓冲区使用时间戳排序,数据包插入播放缓冲时要对传输引入的乱序进行重新排序。数据包一直留在播放缓冲中,直到收到组成一个完整帧的所有数据包,此外,缓冲这些数据包也可以消除网络导致的数据包之间的间隔时间的变化。在一个RTP实现的设计中最关键的方面之一是计算延迟的增加量。每个数据包都被打上了对应的帧的播放时间。
在到达播放时间后,数据包被组合成完整的帧,并且损坏或者丢弃的帧将被修复。在进行必要的修复工作之后,将解码数据帧(根据所用的编解码器,或许在丢失的帧能修复之前,必须解码媒体数据)。在这一点,有可能会观察到发送者和接收者标称时钟速率之间的差异。这种差异体现为RTP媒体时钟相对于播放时钟之间的一个漂移值。接收者必须补偿这种时钟偏差以避免播放间断。
最后,媒体数据呈现给用户。根据媒体格式和输出设备,有可能单独地播放每个流,例如,播放几路视频流,每一路流呈现在自己的窗口中。另外,可能需要把所有源的媒体混合为一个单一流来播放,例如,混合几路音频为一路,然后通过一组扬声器播放。
从上面简要的概述可以明显的看出,RTP接收者的操作时复杂的,并且它比发送者的操作复杂。复杂性的增加主要是由IP网络的可变性引起的:复杂性主要源于对丢包的补偿和恢复受到抖动影响的媒体流时序。
小结
本章介绍了IP网络多媒体实时传输的协议和标准,特别是RTP协议。本书剩余部分将详细讨论RTP协议的特色及使用,目标是在标准文档的基础上扩展,揭示标准背后的基本原理和可能的实现选择及其折中。