H264 RTP头分析1111

h264 RTP头解析流程 结合NALDecoder.c分析

协议分析 ：每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前 12 个字节的含义是固定的，而负载则可以是音频或者视频数据。

一个活动顺序参数集在一个编码视频序列中保持不变,一个活动图像参数集在一个编码图像里保持不变。

 

H.264 编码器必须根据H.264规范设置NRI值(subclause 7.4.1)当nal_unit_type 范围的是1到12. 特别是, H.264规范， 要求对于nal_unit_type为6，9，10，11，12的NAL单元的NRI的值应该为0。

 

      对于nal_unit_type等于7，8 (指示顺序参数集或图像参数集)的NAL单元,H.264编码器应该设置NRI为11 (二进制格式）



      对于nal_unit_type等于5的主编码图像的编码片NAL单元(指示编码片属于一个IDR图像), H.264编码器应设置NRI为11。

 

打开H264文件，读取流

找到 NALU 标致startcode，即00 00 01 或 00 00 00 01 串

判断UALU单元数据段大小，（UDP一次能发送最大数据为64K字节）

使用何种发送方式（单一发送、聚合发送、分片发送）

如果UALU数据＜1500（自己设定），使用单一包发送：

填充RTP头（12 BYTE），payload(7 bit)：96 marker(1 bit)：0 seq_no(16 bit)：随机取 timestamp(32 bit)：

第13字节填充NALU头（startcode 的下一个字节），

如果NALU数据＞1500，使用分片发送：（分三种情况设备：第一次RTP，中间的RTP，最后一次RTP）

填充RTP头，类似单一包发送，发送整个NALU，timestamp只曾加一次。

不同的是，第13字节填FU INDICATOR，它的type要成28；第14字节才填FU HEADER，

• 第一次RTP：第13 BYTE 是FU INDICATOR ，其中它的TYPE设置成 28 ；第14 BYTE 是 FU HEADER ，S：E：R ＝ 1：0：0，之后才是视频数据。
• 中间的RTP：第13 BYTE 是FU INDICATOR，其中它的TYPE设置成 28 ；第14 BYTE 是 FU HEADER ，S：E：R ＝ 0：0：0，之后才是视频数据。
• 最后一次RTP：第13 BYTE 是FU INDICATOR，其中它的TYPE设置成 28 ；第14 BYTE 是 FU HEADER ，S：E：R ＝ 0：1：0，之后才是视频数据。

NALU数据很小时，用组合封装：

组合封装：NALU payload = NALU payload size + NALU payload header + NALU payload data

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

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

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

封装成 RTP 包可能如下:

[ RTP Header ] [78, STAP-A NAL HDR, 一个字节 ] [长度, 两个字节] [ 67 42 A0 1E 23 56 0E 2F ...] [长度, 两个字节] [ 67 42 A0 1E 23 56 0E 2F... ]

读rfc 3984搞混了的几个TYPE：

• RTP 中的PT 负载类型 Payload type (PT) : 7 bits －－发送H264视频，此值固定设成 96
• NALU 中的TYPE 描述了NALU的属性，如：7指示顺序参数集，8指示图像参数集
• RTP之后的TYPE，即13 BYTE开始，单一打包的TYPE，与NALU中的TYPE一样；FU 分片打包方式，TYPE设成28；

参考：

http://bbs.chinavideo.org/viewthread.php?tid=2451&highlight=rtp%2Bh264

 

http://www.cppblog.com/czanyou/archive/2010/02/09/67940.html#107573

转自：http://blog.csdn.net/yuanzhenhai/article/details/5704168