(1)流媒体:流媒体是指Internet上使用流式传输技术的连续时基媒体。当前在Internet上传输音频和视频等信息主要有两种方式:下载和流式传输两种方式。
下载情况下,用户需要先下载整个媒体文件到本地,然后才能播放媒体文件。在视频直播等应用场合,由于生成整个媒体文件要等直播结束,也就是用户至少要在直播结束后才能看到直播节目,所以用下载方式不能实现直播。
流式传输是实现流媒体的关键技术。使用流式传输可以边下载边观看流媒体节目。由于Internet是基于分组传输的,所以接收端收到的数据包往往有延迟和乱序(流式传输构建在UDP上)。要实现流式传输,就是要从降低延迟和恢复数据包时序入手。在发送端,为降低延迟,往往对传输数据进行预处理(降低质量和高效压缩)。在接收端为了恢复时序,采用了接收缓冲;而为了实现媒体的流畅播放,则采用了播放缓冲。
(2)延迟:延迟是分组从点A行进到点B所花费的时间,延迟源一般包括:编码,打包,网络传输,jitter buffer。
(3)抖动:分组延迟的变化程度,网络延时随时都在不停的变化称为抖动。
(4)丢包:丢失是从点A发送的分组的数量,其从未使其到达点B,丢包即:发送了多少包,最后并没有收到同样多数量的包,网络丢包率是指测试中所丢失数据包数量占所发送数据包的比率。
RTP:实时传输协议,对应RFC文档为:RFC3550,在RFC3550中,RTP被定义为在一对一或者一对多的传输情况下工作,其目的是为了提供时间信息和实现流同步。RTP的典型应用是建立在UDP上的,也可以建立在TCP等其它协议之上进行工作,一般将其看作传输层的一部分,位于UDP层之上,应用层之下。RTP本身只保证实时数据的传输,并不为按序传送数据包提供可靠的传输机制,不能保证服务质量(服务质量有RTCP提供)。
每一个RTP数据报主要有头部和负载构成,其中头部前12个字节含义是固定的,负载可以是音频或者视频数据。RTP数据报头部格式如下:
0 1 2 3
0 1 2 3 4 5 6 78 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC)identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC)identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图1RTP头部格式
版本号(V):占2位,用来标志使用的RTP版本。
填充位(P):占1位,如果P=1,则该RTP包的尾部包含附加的填充字节。
扩展位(X):占1位,如果X=1,则RTP固定头部后面就跟有一个扩展头部。
CSRC计数器(CC):占4位,指示 CSRC标识符的数量。
标记位(M):占1位,当M=1时,对于视频流, 它表示一帧的结束,而对于音频,则表示一次谈话的开始。
载荷类型(PT):占7位,标识了RTP载荷的类型。
序列号(SN):占16位,发送方在每发送完一个RTP包后就将该域的值增加1,接收方可以由该域检测包的丢失及恢复包序列。序列号的初始值是随机的。
时间戳(timestamp):占32位,记录了该包中数据的第一个字节的采样时刻。在一次会话开始时,时间戳初始化成一个初始值(随机生成)。即使在没有信号发送时,时间戳的数值也要随时间而不断地增加。时间戳是去除抖动和实现同步不可缺少的。
同步源标识符(SSRC):占32位,同步源就是指RTP包流的来源。该标识符可以用来筛选来自同一来源的RTP。
特约信源(CSRC):每个CSRC标识符占32位,可以有0~15个,每个CSRC 标识了包含在该RTP报文有效载荷中的所有特约信源。
抓取的rtp数据包如下:
(1)RTP的序列号
序列号可以用来区分标识RTP报文,能够为检测是否有丢包和是否有包的乱序等问题提供很好的线索。序列号通常是一个16位的二进制整数,以1的步长逐步递增,当序列号达到最大时,会自动恢复为0,除了自动回复为0,序列号永远遵循连续的原则。因为报文每发一个,序列号就递增1,所以接收端可以根据检测序列号是否以1递增来判断是否有丢包(即当接收到的包序列号以大于1的步长跳跃即可认为是丢包),根据序列号是否被打乱来判断是否乱序。
(2)RTP的时间戳
时间戳记录了负载中第一个字节的采样时间,接收方可以根据时间戳来确定数据的到达是否受到了延迟抖动的影响,时间戳主要用于时间同步计算以及抖动控制。
时钟频率与负载类型有关,不同的负载类型对应的时间戳计算的单位不一样。时间戳的单位是采样频率的倒数。如下,给一些算时间戳增量的例子:
采样频率为90000HZ,那么时间戳的单位为:1/90000,那我们就可以假设1s中被划分成了90000个时间块,如果每秒发送25帧,那么每帧占用多少个时间块呢?显然是90000/25=3600,所以时间戳的增量应该是3600。
对于8kHz采样的音频信号,若每隔20ms构成一个数据块,则一个数据块中包含有160个样本(0.02×8000=160)。因此每发送一个RTP分 组,其时间戳的值就增加160。
(3)SSRC的作用
SSRC相当于一个RTP传输session的ID,即该RTP包的发出者的名称。因为同一个RTP会话中不会有两个相同的SSRC值,所以当RTP发送者传输地址改变时,SSRC会重新生成。注意SSRC值是随机产生的,并且保证唯一。
RTCP与RTP一样,一般也是用UDP来传送的,RTCP有如下五种类型:
RTCP的五种类型报文的封装都差不多,下面以SR为例:
版本(V):同RTP包头域。
填充(P):同RTP包头域。
接收报告计数器(RC):5比特,该SR包中的接收报告块的数目,可以为零。
包类型(PT):8比特,SR包是200。
长度域(Length):16比特,其中存放的是该SR包以32比特为单位的总长度减一。
同步源(SSRC):SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。
NTPTimestamp(Network time protocol)SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。
RTPTimestamp:与NTP时间戳对应,与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。
Sender’spacket count:从开始发送包到产生这个SR包这段时间里,发送者发送的RTP数据包的总数. SSRC改变时,这个域清零。
Sender`soctet count:从开始发送包到产生这个SR包这段时间里,发送者发送的净荷数据的总字节数(不包括头部和填充)。发送者改变其SSRC时,这个域要清零。
同步源n的SSRC标识符:该报告块中包含的是从该源接收到的包的统计信息。
丢失率(Fraction Lost):表明从上一个SR或RR包发出以来从同步源n(SSRC_n)来的RTP数据包的丢失率。
累计的包丢失数目:从开始接收到SSRC_n的包到发送SR,从SSRC_n传过来的RTP数据包的丢失总数。
收到的扩展最大序列号:从SSRC_n收到的RTP数据包中最大的序列号
接收抖动(Interarrival jitter):RTP数据包接受时间的统计方差估计
上次SR时间戳(Last SR,LSR):取最近从SSRC_n收到的SR包中的NTP时间戳的中间32比特。如果目前还没收到SR包,则该域清零。
上次SR以来的延时(Delay since last SR,DLSR):上次从SSRC_n收到SR包到发送本报告的延时。
下面是抓取得SR数据包:
当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。RTP的发送过程如下(接收过程相反):
(1) RTP协议从上层接收流媒体信息码流(如H.263),封装成RTP数据包;RTCP从上层接收控制信息,封装成RTCP控制包。
(2)RTP将RTP 数据包发往UDP端口对中偶数端口;RTCP将RTCP控制包发往UDP端口对中的接收端口。
(1)流内同步:对于流内同步,需要RTP的序列号以及时间戳共同作用来实现同步。一般情况下也可以使用序列号来作为流内同步标志,因为一般来说,包的发送时间都会有严格限制,比如音频包是每秒种发送30个数据包,也就是说,每个包间隔1000/30MS,而这个时间就可以作为一个同步时间来播放。也就是说,按照序列号,每1000/30MS间隔播放一个数据包,这样也能保证同步,但是这时候请考虑丢包问题。
(2)流间同步:流间同步是指不同媒体流之间的同步,例如音频和视频的同步。流间同步比流内同步要复杂得多。不同的编码有不同的采样频率,那么它们的时间戳的增长速度就不一样。要实现不同流之间的同步,不仅需要RTP的时间戳,还需要RTCP提供的绝对时间戳,根据这两个时间,我们可以通过将各自的相对间戳(即RTP的时间戳)映射到绝对时间轴上,来实现不同媒体间的同步。