H265 RTP封包笔记

一、协议概述

H265的RTP封包遵守RFC7798协议标准，与H264的RTP封包协议类似，也分三种打包模式：

1、Single NAL Unit Packets：单一NALU单元模式，即一个RTP包仅由一个完整的NALU组成。

2、Aggregation Packets：当同一时间戳内的多个NALU数据，不足以太网的最大报文长度1500个字节，可以将这多个NALU数据，封装在一个RTP报文内。

3、Fragmentation Units：当一个NALU数据就大于1500个字节，需要将该NALU数据拆分成几块，分别封装在不同的RTP报文内。

二、打包详解

首先介绍一下H265的NAL Unit Header定义。

F：1bit，必须是0。

Type：6bits，nal_unit_type。指明该NAL Unit类型，可以参见《T-REC-H.265-201504-I!!PDF-E》协议的nal_unit_type定义。指明该NAL是SPS，还是PPS，还是IDR帧等。

LayerId：6 bits，必须是0。

TID：3 bits。时间参考层ID。

1、Single NAL Unit Packets

 

这种模式下，PayloadHeader与上面的Figure1的NALUHeader定义完全一致。只是该NALU传输的是CRA或者BAL时，NALU Type会变一下。

DONL：Decoding Order Number。当使用多slice编码模式时使用，用于判断一帧的每个slice是否收齐。不过目前webrtc默认都是使用单slice编码模式，所以封包时，没有该字段。

2、Aggregation Packets

很明显，若是所有NALU都打包成一个RTP的话，对带宽是很大的浪费，所以当编码一帧有多个NALU数据的时候（比如一个IDR帧，还会携带SPS、PPS、VPS、SEI等NALU数据），可以把这多个NALU数据都打包在一个RTP报文里面。但是需要控制打包报文总长度小于1500字节，否则会引起IP分片。

AP模式载荷头格式定义

F：1bit，

Type：6bits，必须为48，表示是AP报文。

LayerId：6 bits，

TID：3 bits。

AP模式首个NALU格式

AP模式非首个NALU格式

 

不携带DONL字段的AP报文示例

 

3、Fragmentation Units

同样，当编码一帧数据长度大于1500个字节的时候，一个RTP报文装不下一帧视频数据，需要将该NALU数据拆分N份，封包到N个RTP报文里面去。

FU模式载荷头格式定义

F：1bit。

Type：6bits，必须为49，表示是FU报文。

LayerId：6 bits，

TID：3 bits。

 

FU Header格式定义

 

S：1bit。1：表示是首个分片报文。0：非首个分片报文。

E：1bit。1：表示最后一个分片报文。0：非最后一个分片报文。

FuType：6 bits。该分片报文对应的NALU type。

 

三、参考

RFC7798