H264 编码RawBitstream 格式分析以及SPS&PPS数据分析

基于MPP框架开发了demo展示应用，方案数据流如下图所示，简单说明一下.

1.支持一路sensor输入，四路输出.

2.第一路VIPP0输出YUV大小为1920*1080. 编码为H264main profile大小的压缩BitStream存盘。

3.第二路预览，源分辨率1920*1080，目标分辨率640*480，中间经过一次VIPP1的 scale down.

4.第三路提供供NPU做人形识别的图像，源分辨率1920*1080，目标分辨率352*198.

5.第四路用于抓怕jpg格式的照片。

原型框架已经设计完成，下图显示的是录制到磁盘的原始编码视频文件以及供NPU计算的小图文件：

下面我们来分析一下H264_REC.raw的文件格式:

首先上代码：

vbvbuffer是一个循环buffer,所以要由两个指针和长度信息。

根据以上代码，我们可以看到，我们可以大概看出，H264_REC.raw的格式大概如下：

对于这种格式的数据（带有sps,pps的原始压缩帧数据）,可以通过ffmpeg -i或者mediainfo工具查看其内容：

可以看到，每笔压缩数据都是完整的数据帧,这是由通道参数配置阶段的bByFrame决定的，如下图所示，当bByFrame设置为TRUE时，表示每个完整的YUV帧只编码为一笔VBV,反之，可能会分成多笔Slice编码一帧图像。

加入调试打印：

sps&&pps(Sequence Parameter Set/Picture Parameter Set)起始地址0xc28138c0,长度28字节，dump出来如下：

dump出来文件如下：

和原始编码码流文件对比：

可见其头部28字节完全一样，并且符合annex-b格式

00 00 00 01 67 4d 00 33 96 54 03 c0 11 2f 2c dc 14 18 14 08 00 00 00 01 68 ee 3c 80

其中0x67表示SPS，0x68表示PPS。

现在我们分析一下SPS的格式，SPS格式

00 00 00 01 67 4d 00 33 96 54 03 c0 11 2f 2c dc 14 18 14 08 00 00 00 01 68 ee 3c 80

0x4d=77，表示编码格式为main profile.还有最大参考帧个数，以及图像的长宽等等信息。

尝试发现，分理处来的H264裸文件，需要首先写入SPS和PPS，否则会导致分离出来的数据没有SPS、PPS而无法播放。比如，将H264_REC.raw文件中的头部28字节去掉，文件无法通过ffplay和vlc播放出来。对于AW的video codec,如果一开始找不到sps和pps，解码会继续查找，直到片源结束,不播球.

根据VLC码率信息可以看到，我们的编码参数设置的CBR，8M码率，还是比较符合的。 

---

需要注意的是，编码器会根据码率生成每笔BITSTREAM的PTS时间戳，用于控制解码后的帧率。 

---

结束！