使用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进行传输我在下一篇博客中进行介绍。