live555中数据的发送最后是要使用RTP协议发送的，下面介绍一下RTP包格式。
RTP packet
RTP是基于UDP协议的，RTP服务器会通过UDP协议，通常每次会发送一个RTP packet。客户端通过解析RTP packet，读取其中的数据然后进行播放了。
RTP packet的结构如下：
- RTP Header：RTP 包的头部
- contributing sources：个数为0-n个，所以可以为空。具体定义参考rfc3550
- 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的结构如下：
- RTP Header：RTP 包的头部
- contributing sources：个数为0-n个，所以可以为空。具体定义参考rfc3550
- 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