# 一、协议概述 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