RTP协议解析及H264／H265音视频RTP打包分析
动态统计数据传输协定（Real-time Transport Protocol或缩写RTP）是两个互联网统计数据传输协定，它是由IETF的影音统计数据传输组织工作组成员1996年在RFC 1889中发布的。
RTP协定详尽表明了在互联网上传达音频和音频的国际标准报文文件格式。它一已经开始被结构设计为两个多播协定，但而后被用在许多多播应用领域中。RTP协定常见作在线视频控制系统（相互配合RTSP协定），音频会议和一键通（Push to Talk）控制系统（相互配合H.323或SIP），使它正式成为IP电话号码产业发展的控制技术此基础。RTP协定和RTP控制协定RTCP一同采用，所以它是创建在UDP协定上的。
当RTSP程序代码创建获得成功，并已经开始统计数据传输时，音频统计数据以RTP协定装箱推送给应用领域程序；
V：RTP协定的正式版，占2位，现阶段协定正式版为2
P：充填标象征，占1位，假如P=1，则在该统计数据流的前部充填两个或数个附加的六位组，它并非酬载的一小部分。
X：扩充象征，占1位，假如X=1，则在RTPcustom后跟有两个扩充custom
CC：CSRC计时器，占4位，命令CSRC URL的特征值
M：记号，占1位，相同的酬载有相同的涵义，对音频，记号一格的完结；对音频，记号程序代码的已经开始
PT：酬载类别，占7位，用作表明RTP统计数据流中酬载的类别，如GSM音频、JPEM影像等
sequence number：序号，占16位，用作标记推送者所推送的RTP统计数据流的序号，每推送两个统计数据流，序号增1。发送者透过序号来检验统计数据流遗失情形，再次次序统计数据流，恢复正常统计数据
timestamp：时间戳，占32位，时戳反映了该RTP统计数据流的第两个六位组的采样时刻。发送者采用时戳来计算延迟和延迟抖动，并进行同步控制
SSRC：同步信源URL，占32位，用作标记同步信源。该URL是随机选择的，对弈同两个音频源，每个程序代码都有自己独立的同步信源
CSRC：特约信源URL，每个CSRC信源占32位，可以有0-15个，具体数量由CC决定，每个CSRC标记了包含在该RTP统计数据流酬载中的所有特约信源
装箱时，每帧报文均需要添加二中所述RTP包头，对每路音频流，RTP包头除序号外，基本保持不变；另两个要注意的时，由于包头需要按位充填，当充填/推送统计数据时，应注意推送端统计数据的大小端限制。
此处以h264，h265，aac，g711来举例表明
g711统计数据在推送时，不需要附加的头部信息，其他三种统计数据流，在rtp包头后，应按文件格式封装自己的统计数据头
其中h264为两个字节，h265为两个字节，aac统计数据为四个字节
音频包时需要考虑到MTU的大小，每包统计数据不能超过MTU的大小，通常情形下，设备是不知道现阶段互联网的MTU大小的。
因此都会在代码中指定两个大小，开发时，可以参考ffmpeg中给定该值的大小
H264统计数据装箱文件格式如下：
RTP头+h264字节头+音频统计数据帧
h264字节头为两个字节，文件格式如下
第两个字节
根据ffmpeg代码，F为0，此处type为28，
nri=buff[0] & 0x60;
buff[0] 为音频帧的第两个统计数据
第二个字节
此处type=buff[0] & 0x1f;
其中S E R的解释如下，注意当报文被分成多包统计数据后，处S E R三位，其他均与第一包保持一致，不得改变
装箱和h264过程类似，区别就是H265的统计数据头为三个字节，
h265的三个字节，结构如下：
第一第二个字节
参考ffmpeg代码 此处F为0，Type为49，LayerId为0，TID为1
第三个字节
其中FuType=(buf[0] >> 1) & 0x3F;
S E的用法和h264中相同，此处不再叙述
aac在装箱为RTP报文时，每帧统计数据前还应该由四个字节头，即文件格式如下
RTP包头+AAC字节头+AAC统计数据
当AAC统计数据前由ADTS头时， 装箱时应该跳过7字节的ADTS头
AAC字节头定义如下
字节1：0x00
字节2：0x01
字节3：(data_len & 0x1fe0) >> 5
字节4：(data_len &0x1f) << 3
ffmpeg代码 rtpenc_h264_hevc.c文件
void ff_rtp_send_h264_hevc(AVFormatContext *s1, const uint8_t *buf1, int size)；
此处注意，该函数将h264和h265的nalu装箱放在了同两个函数中，注意根据判断语句来区分。
