H264视频传输、编解码----RTP/RTCP协议

最新推荐文章于 2024-07-01 09:35:53 发布

猿诗人

最新推荐文章于 2024-07-01 09:35:53 发布

阅读量1.2k

点赞数 1

分类专栏： h264传输-编解码流媒体 RTSP/RTP/RTCP/RTMP H264 文章标签： H264

本文链接：https://blog.csdn.net/wujian946110509/article/details/79188221

版权

流媒体 RTSP/RTP/RTCP/RTMP H264 同时被 2 个专栏收录

10 篇文章 6 订阅

订阅专栏

h264传输-编解码

7 篇文章 3 订阅

订阅专栏

RTSP对流媒体提供了控制方法，使得实时流数据变得可控。但是它并不负责实时流数据的传输。实时流数据的传输和传输过程的同步、优化由RTP/RTCP来负责。

实时传输协议RTP（ Real-time Transport Protocol）和实时传输控制协议(Real-time ControlProtocol，RTCP)，在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，如下图所示。对于RTP会话或者广播，通常使用单个多目标广播地址，属于这个会话的所有RTP和RTCP信息包都使用这个多目标广播地址，通过使用不同的端口号可把RTP信息包和RTCP信息包区分开来。他们一般通过UDP协议发送相应的数据。

RTP

RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。

下面是 RFC 3550 中规定的 RTP 头的结构.

       0             1             2               3               4
       0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |V=2|P|X|  CC   |M|     PT    |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           timestamp                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           synchronization source (SSRC) identifier          |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
      |            contributing source (CSRC) identifiers           |
      |                             ....                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

负载类型 Payload type (PT): 7 bits

序列号 Sequence number (SN): 16 bits

时间戳 Timestamp: 32 bits

一张网上的图：

（1）IP是属于网络层部分的，UDP和RTP都是属于传输层部分的。

（2）RTP首部

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

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

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

4)CC：CSRC计数器，占4位，指示CSRC 标识符的个数（作用信源CSRC计数器）

5)M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。（对于分组中的重要事件可用该位标识）

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

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

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

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

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

取一段码流如下：

80 e0 00 1e 00 00 d2 f0 00 00 00 00 41 9b 6b 49 €?....??....A?kI

e1 0f 26 53 02 1a ff06 59 97 1d d2 2e 8c 50 01 ?.&S....Y?.?.?P.

cc 13 ec 52 77 4e e50e 7b fd 16 11 66 27 7c b4 ?.?RwN?.{?..f'|?

f6 e1 29 d5 d6 a4 ef3e 12 d8 fd 6c 97 51 e7 e9 ??)????>.??l?Q??

cfc7 5e c8 a9 51 f6 82 65 d6 48 5a 86 b0 e0 8c ??^??Q??e?HZ????

其中，

80 是V_P_X_CC

e0 是M_PT

00 1e 是SequenceNum

00 00 d2 f0 是Timestamp

00 00 00 00是SSRC

把前两字节换成二进制如下

1000 0000 1110 0000

按顺序解释如下：

10 是V；

0 是P；

0 是X；

0000 是CC；

1 是M；

110 0000 是PT；

RTP协议的目的是提供实时数据（如交互式的音频和视频）的端到端传输服务，因此在RTP中没有连接的概念，它可以建立在底层的面向连接（TCP）或面向非连接（UDP）的传输协议之上；RTP也不依赖于特别的网络地址格式，而仅仅只需要底层传输协议支持组帧（Framing）和分段（Segmentation）就足够了；

另外RTP本身还不提供任何可靠性机制，这些都要由传输协议或者应用程序自己来保证。在典型的应用场合下，RTP一般是在传输协议之上作为应用程序的一部分加以实现的，

RTP扩展头：

很多时候，在传输H264数据的时候，也需要传输其他的协议数据信息，这个时候，就可以放在RTP的扩展头部分传输。根据上面RTP协议格式，第一个字节的bit2(X)，这个字段如果是1的话，就表示当前RTP协议带着扩展头。

这个扩展头就跟在RTP确定的头部后面。如果有CSRC，就跟在CSRC后面，CSRC的个数，可以看第一个字节的bit4~bit7(CC)，每一个CSRC 4个字节。这样就可以确定扩展头的位置了。

扩展头的内部格式：

       0             1             2               3               4
       0 1 2 3 4 5 6 7 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       defined by profile    |            length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           header extension                  |
                                  ......  ......
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

defined by profile ：按照私有的协议文档自己定义就行了，相当于一个标识。
length：扩展头长度，更确切地说，是扩展头个数，比如length == 2，标识有两个，每个扩展头4字节，则共 2 * 4 = 8字节。即扩展头内容长度为 4 * length（字节）。

RTCP

一、RTCP协议作用

1、为应用程序提供会话质量或者广播性能质量的信息　

RTCP的主要功能是为应用程序提供会话质量或者广播性能质量的信息。每个RTCP信息包不封装声音数据或者电视数据，而是封装发送端（和 / 或者）接收端的统计报表。这些信息包括发送的信息包数目、丢失的信息包数目和信息包的抖动等情况，这些反馈信息反映了当前的网络状况，对发送端、接收端或者网络管理员都非常有用。RTCP规格没有指定应用程序应该使用这些反馈信息做什么，这完全取决于应用程序开发人员。例如，发送端可以根据反馈信息来调整传输速率，接收端可以根据反馈信息判断问题是本地的、区域性的还是全球性的，网络管理员也可以使用RTCP信息包中的信息来评估网络用于多目标广播的性能。

2、确定 RTP用户源　

RTCP为每个RTP用户提供了一个全局唯一的规范名称 (Canonical Name)标志符 CNAME，接收者使用它来追踪一个RTP进程的参加者。当发现冲突或程序重新启动时，RTP中的同步源标识符SSRC可能发生改变，接收者可利用CNAME来跟踪参加者。同时，接收者也需要利用CNAME在相关RTP连接中的几个数据流之间建立联系。当 RTP需要进行音视频同步的时候，接受者就需要使用 CNAME来使得同一发送者的音视频数据相关联，然后根据RTCP包中的计时信息(Network time protocol)来实现音频和视频的同步。

3、控制 RTCP传输间隔

由于每个对话成员定期发送RTCP信息包，随着参加者不断增加，RTCP信息包频繁发送将占用过多的网络资源，为了防止拥塞，必须限制RTCP信息包的流量，控制信息所占带宽一般不超过可用带宽的 5%，因此就需要调整 RTCP包的发送速率。由于任意两个RTP终端之间都互发 RTCP包，因此终端的总数很容易估计出来，应用程序根据参加者总数就可以调整RTCP包的发送速率。

4、传输最小进程控制信息　

这项功能对于参加者可以任意进入和离开的松散会话进程十分有用，参加者可以自由进入或离开，没有成员控制或参数协调。

二、RTCP协议格式

RTCP也是用UDP来传送的，但RTCP封装的仅仅是一些控制信息，因而分组很短，所以可以将多个RTCP分组封装在一个UDP包中。

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：

SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。
RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。
SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

接下来看一下SR包，其他包大同小异：

版本（V）：同RTP包头域。

填充（P）：同RTP包头域。

接收报告计数器（RC）：5比特，该SR包中的接收报告块的数目，可以为零。

包类型（PT）：8比特，SR包是200。

长度域（Length）：16比特，其中存放的是该SR包以32比特为单位的总长度减一。

同步源（SSRC）：SR包发送者的同步源标识符。与对应RTP包中的SSRC一样。

NTP Timestamp（Network time protocol）：SR包发送时的绝对时间值。NTP的作用是同步不同的RTP媒体流。

RTP Timestamp：与NTP时间戳对应，与RTP数据包中的RTP时间戳具有相同的单位和随机初始值。

Sender’s packet count：从开始发送包到产生这个SR包这段时间里，发送者发送的RTP数据包的总数. SSRC改变时，这个域清零。

Sender`s octet 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包到发送本报告的延时。

不同类型的RTCP信息包可堆叠，不需要插入任何分隔符就可以将多个RTCP包连接起来形成一个RTCP组合包，然后由低层协议用单一包发送出去。由于需要低层协议提供整体长度来决定组合包的结尾，在组合包中没有单个RTCP包的显式计数。

组合包中每个RTCP包可独立处理，而不需要按照包组合的先后顺序处理。在组合包中有以下几条强制约束：

1、只要带宽允许，在SR包或RR包中的接收统计应该经常发送，因此每个周期发送的组合RTCP 包中应包含报告包。

2、每个组合包中都应该包含SDES CNAME，因为新接收者需要通过接收CNAME来识别源，并与媒体联系进行同步。

3、组合包前面是包类型数量，其增长应该受到限制。

所有RTCP包至少必须以两个包组合形式发送，推荐格式如下：

加密前缀（Encryption prefix）：

仅当组合包被加密，才加上一个32位随机数用于每个组合包发送。

SR或RR：

组合包中第一个RTCP包必须是一个报告包，以帮助分组头的确认。即使没有数据发送，也没有接收到数据，也要发送一个空RR，那怕组合包中RTCP包为BYE。

附加RR：

如报告统计源数目超过31，在初始报告包后应该有附加RR包。

SDES：

包含CNAME 项的SDES包必须包含在每个组合RTCP包中。SDES包可能包括其他源描述项，这要根据特别的应用需要，并同时考虑带宽限制。

BYE或APP：

除了BYE应作为最后一个包发送，其它RTCP包类型可以任意顺序排列，包类型出现可不止一次。

混合器从多个源组合单个RTCP包，如组合包整体长度超过网络路径最大传输单元，可分成多个较短组合包用低层协议以单个包形式发送。注意，每个组合包必须以SR或RR包开始。附加RTCP包类型可在Internet Assigned NumbersAuthority (IANA)处注册，以获得合法的类型号。

RTCP传输间隔

由于RTP设计成允许应用自动扩展，可从几个人的小规模系统扩展成上千人的大规模系统。而每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包，如每个参与者以固定速率发送接收报告，控制流量将随参与者数量线性增长。由于网络资源有限，相应的数据包就要减少，直接影响用户关心的数据传输。为了限制控制信息的流量，RTCP控制信息包速率必须按比例下降。

一旦确认加入到RTP会话中，即使后来被标记成非活动站，地址的状态仍会被保留，地址应继续计入共享RTCP带宽地址的总数中，时间要保证能扫描典型网络分区，建议为30分钟。注意，这仍大于RTCP报告间隔最大值的五倍。

SR源报告包和RR接收者报告包

SR源报告包和RR接收者报告包用于提供接收质量反馈，除包类型代码外，SR与RR间唯一的差别是源报告包含有一个20字节发送者信息段。RR针对每个信源都提供信息包丢失数、已收信息包最大序列号、到达时间抖动、接收最后一个SR的时间、接收最后一个SR的延迟等信息。SR不仅提供接收质量反馈信息（与RR相同），而且提供SSRC标识符、NTP时间戳、RTP时间戳、发送包数以及发送字节数等。根据接收者是否为发送者来决定使用SR还是RR包，活动源在发出最后一个数据包之后或前一个数据包与下一个数据包间隔期间发送SR；否则，就发送RR；SR和RR包都可没有接收报告块也可以包括多个接收报告块，其发布报告表示的源不一定是在CSRC列表上的起作用的源，每个接收报告块提供从特殊源接收数据的统计。最大可有31个接收报告块嵌入在SR 或 RR包中，丢失包累计数差别给出间隔期间丢包的数量，而系列号的差别给出间隔期间希望发送的包数量，两者之比等于经过间隔期间包丢失百分比。从发送者信息，第三方监控器可计算载荷平均数据速率与没收到数据间隔的平均包速率，两者比值给出平均载荷大小。如假设包丢失与包大小无关，那么特殊接收者收到的包数量给出此接收者收到的表观流量。

SDES源描述包

SDES源描述包提供了直观的文本信息来描述会话的参加者，包括CNAME、NAME、EMAIL、PHONE、LOC等源描述项，这些为接收方获取发送方的有关信息提供了方便。SDES 包由包头与数据块组成，数据块可以没有，也可有多个。包头由版本（V）、填充（P）、长度指示、包类型（PT）和源计数（SC）组成。PT占8位，用于识别RTCP的SDES包，SC占5位，指示包含在SDES包中的SSRC/CSRC块数量，零值有效，但没有意义。数据块由源描述项组成，源描述项的内容如下：

CNAME: 规范终端标识SDES项

类似SSRC标识，RTCP为RTP连接中每一个参加者赋予唯一一个CNAME标识。在发生冲突或重启程序时，由于随机分配的SSRC标识可能发生变化，CNAME项可以提供从SSRC标识到仍为常量的源标识的绑定。

为方便第三方监控，CNAME应适合程序或人员定位源。

NAME：用户名称SDES项

这是用于描述源的真正的名称，如"John Doe, Bit Recycler, Megacorp"，可以是用户想要的任意形式。由于采用文本信息来描述，对诸如会议应用，可以对参加者直接列表显示，NAME项是除CNAME项以外发送最频繁的项目。NAME值在一次RTP会话期间应该保持为常数，但它不该成为连接的所有参加者中唯一依赖。

EMAIL：电子邮件地址SDES项

邮件地址格式由RFC822规定，如"John.Doe@megacorp.com"。一次RTP会话期间，EMAIL项的内容希望保持不变。

PHONE：电话号码SDES项

电话号码应带有加号，代替国际接入代码，如"+1 908 555 1212"即为美国电话号码。　

LOC：用户地理位置SDES项

根据应用，此项具有不同程度的细节。对会议应用，字符串如"Murray Hill, New Jersey"就足够了。然而，对活动标记系统，字符串如"Room 2A244, AT&T BL MH"也许就适用。细节留给实施或用户，但格式和内容可用设置指示。在一次RTP会话期间，除移动主机外，LOC值期望保持不变。

TOOL：应用或工具名称SDES项

TOOL项包含一个字符串，表示产生流的应用的名称与版本，如"videotool 1.2"。这部分信息对调试很有用，类似于邮件或邮件系统版本SMTP头。TOOL值在一次RTP会话期间保持不变。

NOTE: 通知/状态SDES项

NOTE 项旨在描述源当前状态的过渡信息，如"on the phone, can't talk"，或在讲座期间用于传送谈话的题目，它的语法可在设置中显式定义。NOTE项一般只用于携带例外信息，而不应包含在全部参加者中，因为这将降低接收报告和CNAME发送的速度，损害协议的性能。一般NOTE 项不作为用户设置文件的项目，也不会自动产生。

由于NOTE项对显示很重要，当会话的参加者处于活动状态时，其它非CNAME项（如NAME）传输速率将会降低，结果使NOTE项占用RTCP部分带宽。若过渡信息不活跃，NOTE项继续以同样的速度重复发送几次，并以一个串长为零的字符串通知接收者。

PRIV: 专用扩展SDES项

PRIV项用于定义实验或应用特定的SDES扩展，它由长字符串对组成的前缀，后跟填充该项其他部分和携带所需信息的字符串值组成。前缀长度段为8位。前缀字符串是定义PRIV项人员选择的名称，唯一对应应用接收到的其它PRIV项。应用实现者可选择使用应用名称，如有必要，外加附加子类型标识。另外，推荐其它人根据其代表的实体选择名称，然后，在实体内部协调名称的使用。

注意，前缀应尽可能的短。SDES的PRIV项前缀没在IANA处注册。如证实某些形式的PRIV项具有通用性， IANA应给它分配一个正式的SDES项类型，这样就不再需要前缀，从而简化应用，并提高传输的效率。

BYE断开RTCP包

如混合器接收到一个BYE包，混合器转发BYE包，而不改变SSRC/CSRC 标识。如混合器关闭，在关闭之前它应该发出一个BYE包，列出混合器处理的所有源，而不只是自己的SSRC标识。作为可选项，BYE包可包括一个8位八进制计数，后跟文本信息，表示离开原因，如："cameramalfunction"或"RTPloop detected"。字符串的编码与在SDES 项中所描述的相同。如字符串信息至BYE包下32位边界结束处，字符串就不以空结尾；否则，BYE包以空八进制填充。

APP特殊应用包

APP包用于开发新应用和新特征的实验，不要求注册包类型值。带有不可识别名称的APP包应被忽略掉。测试后，如确定应用广泛，推荐重新定义每个APP包，而不用向IANA注册子类型和名称段。