H264 RTP头分析

来源:互联网 发布:手机软件连不上网络 编辑:程序博客网 时间:2024/05/02 02:05

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