live555中数据的发送最后是要使用RTP协议发送的,下面介绍一下RTP包格式。

RTP packet

RTP是基于UDP协议的,RTP服务器会通过UDP协议,通常每次会发送一个RTP packet。客户端通过解析RTP packet,读取其中的数据然后进行播放了。

RTP packet的结构如下:

  1. RTP Header:RTP 包的头部
  2. contributing sources:个数为0-n个,所以可以为空。具体定义参考rfc3550
  3. RTP payload:即RTP要传输的数据

RTP Header

这是RTP流的头部,在网上搜索RTP格式,就会搜到很多文章介绍这个头部的定义。我们这里参考rfc3550的定义,在5.1节(http://tools.ietf.org/html/rfc3550#section-5.1)。

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

每行是32 bits,由此可以直观看到每个表示部分所占的位数。简单介绍一下:

V(version):2 bits,RTP的版本,这里统一为2

P(padding):1 bit,如果置1,在packet的末尾被填充,填充有时是方便一些针对固定长度的算法的封装

X(extension):1 bit,如果置1,在RTP Header会跟着一个header extension

CC(CSRC count): 4 bits,表示头部后contributing sources的个数

M(marker): 1 bit,具体这位的定义会在一个profile里

PT(playload type): 7 bits,表示所传输的多媒体的类型,对应的编号在另一份文档rfc3551中有列出(http://tools.ietf.org/html/rfc3551)

sequence number: 16 bits,每个RTP packet的sequence number会自动加一,以便接收端检测丢包情况

timestamp: 32 bits,时间戳

SSRC: 32 bits,同步源的id,没两个同步源的id不能相同

CSRC: 上文说到,个数由CC指定,范围是0-15

RTP packet

RTP是基于UDP协议的,RTP服务器会通过UDP协议,通常每次会发送一个RTP packet。客户端通过解析RTP packet,读取其中的数据然后进行播放了。

RTP packet的结构如下:

  1. RTP Header:RTP 包的头部
  2. contributing sources:个数为0-n个,所以可以为空。具体定义参考rfc3550
  3. RTP payload:即RTP要传输的数据

RTP Header

这是RTP流的头部,在网上搜索RTP格式,就会搜到很多文章介绍这个头部的定义。我们这里参考rfc3550的定义,在5.1节(http://tools.ietf.org/html/rfc3550#section-5.1)。

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

每行是32 bits,由此可以直观看到每个表示部分所占的位数。简单介绍一下:

V(version):2 bits,RTP的版本,这里统一为2

P(padding):1 bit,如果置1,在packet的末尾被填充,填充有时是方便一些针对固定长度的算法的封装

X(extension):1 bit,如果置1,在RTP Header会跟着一个header extension

CC(CSRC count): 4 bits,表示头部后contributing sources的个数

M(marker): 1 bit,具体这位的定义会在一个profile里

PT(playload type): 7 bits,表示所传输的多媒体的类型,对应的编号在另一份文档rfc3551中有列出(http://tools.ietf.org/html/rfc3551)

sequence number: 16 bits,每个RTP packet的sequence number会自动加一,以便接收端检测丢包情况

timestamp: 32 bits,时间戳

SSRC: 32 bits,同步源的id,没两个同步源的id不能相同

CSRC: 上文说到,个数由CC指定,范围是0-15

05-11 22:43