RTP 协议_rtp 一个包会包含多个帧吗-CSDN博客

概述：

实时传送协议（Real-time Transport Protocol或简写RTP，也可以写成RTTP）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。

RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统（配合RTCP协议或者RTSP协议）。因为RTP自身具有Time stamp所以在ffmpeg 中被用做一种formate.

RTP协议格式：

    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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上图引自rfc3550，由上图中可知道RTP报文由两个部分构成--RTP报头和RTP的负载：

RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图6.7所示，其中：

1.V：RTP协议的版本号，占2位，当前协议版本号为2。

2. P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。

3. X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。

4. CC：CSRC计数器，占4位，指示CSRC 标识符的个数。

5. M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

6. PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

7. 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，在helix服务器中这个字段是从0开始的，同时音频包和视频包的sequence是分别记数的。

8. 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

9. 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

10. 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

如果扩展标志被置位则说明紧跟在报头后面是一个头扩展，其格式如下：

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

RTP协议的用途：

概述中已经基本阐述了ＲＴＰ协议的用途了，其主要用于在互联网上传递音频和视频的标准数据包。在当前三网融合中ＲＴＰ可以用来承载TS流，进行电视媒体数据的传播。ＲＴＰ可以用来传送像TS流这种自身已经具有ｆｏｒｍａｔｅ的媒体流，同时也可以用来承载ＡＶＣ，ＡＡＣ等去除了fromate的媒体流，这时rtp协议可被看做为一种formate，这种形式最少常见于helix 流媒体服务器的rtp流。其控制流由RTSP协议来提供。

RTP协议的使用：

ＲＴＰ的使用实例之一如上图：

上面是某省IPTV２.０早期的一个数据包的情况。从包中可以看出RTP是怎么和RTSP配合一起使用的。从包402到411为RTSP的协商过程，RTSP在PLAYer命令后数据包就到来。紧跟其后412包就是一个mpeg 的PES包，它是有由rtp来承载的TS来形成。从在420包中就可以更加清析的看出这个RTP流的情况。其PT即payload type为mpeg2 transport streams 也就是ts流，其SSRC为：0x65737D6c，其Seq号为15764，从中也可以看出对于一个RTP流其SEQ号可以开始于一个随机的数值，但是肯定是逐包递增的。下图为420包的展开图：

从中可以看出承载RTP的为UDP的数据流这个包中有x标志位为1则说明其有 header extensions.其header extensions为最下面。extension 的 profile为23128,长度为：2内容如上图最后两部分。

1、协议简介

RTP是针对Internet上多媒体数据流的一个传输协议。可以实现一对一或一对多的传输情况。RTP的典型应用建立在UDP上，但也可以在TCP或ATM等其他协议之上工作。

RTP本身只保证实时数据的传输，并不能为按顺序传送数据包提供可靠的传送机制，也不提供流量控制或拥塞控制。

2、工作机制

多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。

rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据流的播放。发送端依照即时的采样在数据包里设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始的适时的数据。

在rtp协议中，一帧数据被分割成几个包，这几个包具有相同的时间标签，但是每一个包又具有不同的序号

3、协议头

①版本（V）

2位，标识RTP版本。

②填充标识（P）

1位，如设置填充位，在包尾将包含附加填充字，它不属于有效载荷。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法

③扩展（X）

1位，如设置扩展位，固定头后跟一个头扩展。

④CSRC计数（CC）

4位，CSRC计数包括紧接在固定头后CSRC标识符个数。

⑤标记（M）

1位，标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件，如帧边界

⑥载荷类型（PT）

7位，记录后面资料使用哪种编码，接收端找出相应的 decoder 解码出来。H264的为96

⑦系列号

16位，系列号随每个RTP数据包而增加1，由接收者用来探测包损失。系列号初值是随机的。

⑧时标

32位，时标反映RTP数据包中第一个八进制数的采样时刻，采样时刻必须从单调、线性增加的时钟导出，以允许同步与抖动计算。时标可以让receiver端知道在正确的时间将资料播放出来。

只有系列号而没有时标，并不能完整按照顺序的将data播放出来，因为如果data中间有一段是没有资料的，只有系列号的话会造成错误.一般rtp头以0x80 60开头

H264 over RTP基本上分三种类型：

1.Single NAL unitpacket 也就是实际的NAL类型，可以理解为一个包就是一帧H264数据，这个在实际中是比较多的。

2. Aggregation packet 一包数据中含有多个H264帧。

3. Fragmentationunit 一帧数据被分为多个RTP包，这也是很常见的，特别是对于关键帧。

为什么要使用RTP: http://ticktick.blog.51cto.com/823160/462746
谈谈RTP传输中的负载类型和时间戳: http://ticktick.blog.51cto.com/823160/350142/
关于RTP中的时间戳问题: http://www.cppblog.com/koople/archive/2010/01/25/106396.aspx
ortp库使用入门: http://ticktick.blog.51cto.com/823160/345642
RTP协议分析: http://blog.csdn.net/niu_gao/article/details/6946781
http://blog.csdn.net/bripengandre/article/details/2238818
RTP timestamp与帧率及时钟频率的关系: http://blog.csdn.net/jasonhwang/article/details/7316128