使用jrtplib（RTP）传输H.264视频文件（1）

继续上一篇博客，在使用x264对视频进行编码以后，咱们须要将编码好的视频进行网络传输，发送给其余的客户端，以后再进行解码。那么，这篇博客我将介绍下如何使用jrtplib这个库对编码后的文件传输。

RTP协议基础知识：

首先，咱们依然要先了解一些关于协议的基础知识，否则对于其中的传输参数与发送的数据包顺序什么的咱们也就无从下手。在这里，咱们仅对一些传输须要了解的关键知识进行介绍，若想了解更全面的关于RTP协议的知识，请直接参看RTP协议的rfc文档，另外，这里有一份翻译的中文版。或者你能够参考这篇博客：按照RFC3984协议实现H264视频流媒体（附源代码），其中有不少有用的资料。

RTP(Real-time Transport Protocol)协议，详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在不少单播应用中，因此这个协议既支持单播又支持多播。RTP协议和RTP控制协议RTCP一块儿使用，并且它是建立在UDP协议上的。可是网上也有人说若是不使用RTSP协议（不了解的话，点这里）的话，RTCP协议就等于形同虚设，我对此观点不太赞同，我以为不使用RTSP协议也是能够用RTCP配合RTP协议是用的。我在下面的介绍中将会有应用。

既然RTP协议定义的是一个数据包格式，那么下面咱们来具体研究下对于传输H264来讲，其数据包时如何定义的。

首先，咱们来看RTP数据包的结构，RTP数据包由RTPheader和RTPpayload组成，下图为RTP数据头部格式：

图1,RTP数据包格式

各个字段表明含义以下：

V:版本号，通常为2;

P：填充字段标识；

X：扩展头标识；

M：标志 1bit，在传输h264时表示h264 nalu的最后一包

PT: 负载类型 7 bits, H264类型为96

SN:序列号16 bits

Timestamp:  时间戳32bits，若是为视频的话，应该设置为1/9000,音频为1/8000

SSRC: 3bits，用以识别同步源。

CSRC：做用我也未搞清楚，我并未使用该字段。

 

下面咱们来探讨RTP的负载包（payload），在此以前，咱们必须先了解H264的NALU的负载，对于H264编码后的数据，通过网络层（NAL）编码后产生NALU，其格式已在上篇博客中说明，下面咱们介绍naluheader结构,nalu的头部只有一个字节，以下图所示：

其中各个部分定义以下：

F: 1 个比特.
  forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0.

NRI: 2 个比特.
  nal_ref_idc. 取 00 ~ 11, 彷佛指示这个 NALU的重要性, 如 00 的 NALU 解码器能够丢弃它而不影响图像的回放. 不过通常状况下不太关心这个属性.

Type: 5 个比特.
  nal_unit_type. 这个 NALU 单元的类型. 简述以下:

  0     没有定义
  1-23  NAL单元  单个 NAL 单元包.
  24    STAP-A   单一时间的组合包
  24    STAP-B   单一时间的组合包
  26    MTAP16   多个时间的组合包
  27    MTAP24   多个时间的组合包
  28    FU-A     分片的单元
  29    FU-B     分片的单元
  30-31 没有定义

 

H.264Payload 格式定义了三种不一样的基本的负载(Payload)结构. 接收端可能经过RTP Payload的第一个字节来识别它们. 这一个字节相似NALU 头的格式, 而这个头结构的NAL 单元类型字段，则指出了表明的是哪种结构,这个字节的结构以下, 能够看出它和H.264 的NALU 头结构是同样的.

字段Type:这个RTPpayload 中 NAL 单元的类型. 这个字段和 H.264 中类型字段的区别是, 当 type的值为 24 ~ 31 表示这是一个特别格式的 NAL 单元, 而 H.264 中, 只取 1~23 是有效的值.

关于NALU使用RTP包进行发送可能的类型有：

1. 单一 NAL 单元模式

   即一个 RTP 包仅由一个完整的 NALU 组成. 这种状况下 RTP NAL 头类型字段和原始的H.264的NALU 头类型字段是同样的.

2. 组合封包模式

  便可能是由多个 NAL 单元组成一个 RTP 包. 分别有4种组合方式:STAP-A, STAP-B, MTAP16, MTAP24。那么这里的类型值分别是 24,25, 26 以及 27.

3. 分片封包模式

用于把一个 NALU单元封装成多个 RTP 包. 存在两种类型 FU-A 和 FU-B. 类型值分别是 28 和 29.

 

在个人使用中只遇到第1种和第3中状况，所以我就对这两种进行下详细介绍：

1.      单一NAL单元发送：

对于 NALU的长度小于 MTU 大小的包, 通常采用单一 NAL 单元模式.

对于一个原始的H.264 NALU 单元常由 [StartCode] [NALU Header] [NALU Payload] 三部分组成, 其中 Start Code 用于标示这是一个NALU 单元的开始, 必须是"00 00 00 01" 或"00 00 01", NALU 头仅一个字节, 其后都是 NALU 单元内容.打包时去除 "00 00 01" 或"00 00 00 01" 的开始码, 把其余数据封包的 RTP 包便可.有以下例子：

有一个H.264 的 NALU 是这样的:

[00 0000 01 67 42 A0 1E 23 56 0E 2F ... ]

这是一个序列参数集 NAL 单元. [00 00 00 01] 是四个字节的开始码, 67 是 NALU 头, 42 开始的数据是 NALU 内容.

封装成 RTP 包将以下:

[ RTPHeader ] [ 67 42 A0 1E 23 56 0E 2F ]

（在这里要说明的是，若是客户端是通用的播放器，好比VLC或者JM的话须要将前导码去掉，可是若是使用的是ffmpeg在客户端解码的话，发送前不须要去掉前导码，去掉以后可能会致使ffmpeg解码错误）。

2.      分片封包模式

而当 NALU 的长度超过 MTU 时, 就必须对 NALU 单元进行分片封包. 也称为Fragmentation Units(FUs).将NALU拆分红小于ＭＴＵ的数据包进行发送，若是使用的是VLC等网络播放器的话，须要设置FU header，以下图所示：

可是，仍然注意一点，若是使用的是ffmpeg自行进行数据包接收与解码，则彻底没必要写FU header。

 

下面稍微介绍下RTCP协议：

RTCP的主要功能是：服务质量的监视与反馈，媒体间的同步，以及多播组中成员的标识。因为RTCP分组很短，所以把多个RTCP分组封装在一个UDP用户数据报中。RTCP分组周期性的在网上传送，它带有发送端和接收端对服务质量的统计信息报告（如已发送的分组数和字节数，分组丢失率，分组到达时间间隔的抖动等）。

RTCP能够说是控制交通的协议，它提供了：

 

1）SR发送者报告分组：用来使发送端周期的向全部接收端用多播方式进行报告。内容包括：该RTP流的SSRC；该RTP流中最新产生的RTP分组的时间戳和绝对时钟时间（或称墙上时间：wallclock time);该RTP流包含的分组数；该RTP流包含的字节数。

绝对时钟时间是必要的。由于RTP要求每一种媒体使用一个流。有了绝对时钟时间就能够进行图形和声音的同步。

 

2）RR接收者报告分组：用来使接收端周期性的向全部的点用多播方式进行报告。内容包括：所接收到的RTP流的SSRC；该RTP流的分组丢失率；在该RTP流中的最后一个RTP分组的序号；分组到达时间间隔的抖动等。

发送RR分组有两个目的：

第一，可使全部的接收端和发送端了解当前网络的状态。

第二，可使全部发送RTCP分组的站点自适应的调整本身发送RTCP分组的速率，RTCP分组的通讯量不超过网络中的数据分组的通讯量的5%，而接收端分组报告分组的通讯量又应小于全部RTCP分组的通讯量的75%。

 

3）SDES源描述分组：给出会话中参加者的描述，包括参加者的规范名（CNAME）

4）BYE分组：关闭一个数据流。

5）APP分组：应用程序可以定义新的分组类型。

 

在这其中我用到4,5分组，其他的能够用来作QoS，暂时我尚未用到。另外，关于显示网络当前情况的RTCP包是由jrtplib自动发送的，不须要本身写代码生成，可是若是你要使用这些包作QoS的话，是须要本身添加消息响应函数来处理的，jrtplib自己并无提供这样的机制。

关于怎样使用jrtplib进行传输我在下一篇博客中进行介绍。