【H264/AVC 句法和语义详解】(二)：h264码流格式与NALU详解一

╰+攻爆jí腚メ 2022-02-20 15:43 241阅读 0赞

> 本篇隶属于文集：[《H264/AVC 句法和语义详解》][H264_AVC]，查看文集全部文章，请点击文字链接。  
> 想看最新文章，可以直接关注微信公众号：金架构

上一篇中，我们站在句法元素（或称语法元素）的角度，介绍了H.264的句法和语义，和句法元素的分层结构。在这篇中，我们更进一步，从比特的角度出发，来探索h264码流的组成。通过这篇的学习，我们会初步具备解析h264码流的能力，从码流中分离出NAL单元，并识别NAL类型。

1. H264码流格式

不过大道始于脚下，我们还是先从头介绍一下，h264的两种码流格式，它们分别为：字节流格式和RTP包格式。

（1）字节流格式：这是在h264官方协议文档中规定的格式，处于文档附录B（Annex-B Byte stream format）中。所以它也成为了大多数编码器，默认的输出格式。它的基本数据单位为NAL单元，也即NALU。为了从字节流中提取出NALU，协议规定，在每个NALU的前面加上起始码：0x000001或0x00000001（0x代表十六进制） 。

（2）RTP包格式：这种格式并没有在h264中规定，那为什么还要介绍它呢？是因为在h264的官方参考软件JM里，有这种封装格式的实现。在这种格式中，NALU并不需要起始码Start\_Code来进行识别，而是在NALU开始的若干字节（1，2，4字节），代表NALU的长度。

显而易见，我们通常所指，以及接下来要研究的，是h264的字节流格式。由于它没有经过传输协议封装，所以也可以称之为裸流。比如我们打开一个，经编码器编码存于本地后缀为.h264文件，里面的数据即为h264裸流。

而我们接下来的研究方向，就从已经打开了一个本地的.h264文件，然后对里面的h264裸流，按照字节流格式进行分析开始。所以拿到码流的第一刻，我们需要知道，如何从中提取出NALU。

2. 起始码与NALU

通过上面我们已经知道：

> H264比特流 = Start\_Code\_Prefix + NALU + Start\_Code\_Prefix + NALU + …

只要我们从码流中，找到一个一个的起始码，那么位于起始码之间的数据，即为NALU。所以拿到码流，我们需要先从头开始，找到起始码0x000001或0x00000001，找到Start\_Code\_Prefix之后，从它之后的下一个字节开始，就是NALU的部分。

这部分的实现过程描述在H264官方文档附录B中，已经下载的同学可以查看B.1.1节：

![Image 1][]

B.1.1 字节流NAL单元语法

3. NALU

看到这一小节时，我们已经有能力根据附录B的内容，从h264码流中找出NALU，所以是时候来看一下，h264码流结构的组成了：

![Image 1][]

NALU构成H264码流结构

这就是NALU在H264码流中的构成了，由上图我们也知道：

NALU = NALU Header + RBSP

这就是接下来我们要干的，分析NALU Header 和 RBSP，为了对NALU有个宏观的认识，我们先来看一下，NALU有哪些句法元素构成，这位于h264文档的7.3.1节：

![Image 1][]

7.3.1节 NALU句法元素构成

可以看到，整个NALU语法元素分为三部分：（1）NALU Header、（3）RBSP、（2）1和3之间的部分。

其中第2部分，是近期的h264文档才更新的，所以我特意查看了JM、x264、FFmpeg等主流编解码器，这部分是还没有实现的，所以我们可以不必理睬。而且细心的同学会发现，只有当nal\_unit\_type等于14、20、21时，才会进入第二部分。

所以接下来呢，我们就重点介绍NALU Header和RBSP。

3.1 NALU Header

通过上面我们也可以看到，NALU Header由三个句法元素组成，分别为：forbidden\_zero\_bit、nal\_ref\_idc和nal\_unit\_type，它们总共占据一个字节，也就是说，NALU Header，在整个NALU中，占据一个字节。

而且forbidden\_zero\_bit的值对应1个bit，nal\_ref\_idc的值对应2个bit，nal\_unit\_type的值对应5个bit，加起来刚好一个字节。

正如在上一篇（链接）中所介绍的，知道了句法元素，我们就来分别看看它的语义：

3.1.1 forbidden\_zero\_bit

h264文档规定，这个值应该为0，当它不为0时，表示网络传输过程中，当前NALU中可能存在错误，解码器可以考虑不对这个NALU进行解码。

3.1.2 nal\_ref\_idc

取值0~3，代表当前这个NALU的重要性，取值越大，代表当前NALU越重要，就需要优先被保护。尤其是当前NALU为图像参数集、序列参数集或IDR图像时，或者为参考图像条带（片/Slice），或者为参考图像的条带数据分割时，nal\_ref\_idc值肯定不为0。

而当NALU 类型，nal\_unit\_type为6、9、10、11、或12时，nal\_ref\_idc都为0。

【注】IDR帧，即：即时解码刷新图像，它是一个序列的第一个图像，H.264引入IDR图像是为了解码的重新同步。当解码器解码到IDR图像时，立即将参考帧队列清空，将已解码的数据全部输出或抛弃，重新查找参数集，开始一个新的序列。这样一来，如果前一个序列发生重大错误，在这里就可以获得重新同步。

所以IDR图像之后的图像，永远不会引用IDR图像之前的图像来解码。并且IDR图像一定是I图像，而I图像不一定是IDR图像（H264里没有图像层，图像可以理解为帧、片或宏块）。

3.1.3 nal\_unit\_type

顾名思义，这个应该是最好理解的了，它表示NALU Header后面的RBSP的数据结构的类型。下图为nal\_unit\_type所有可能的取值，和对应的语义，它处于h264文档7.4.1节：

![Image 1][]

nal\_unit\_type 语义

可以看到，nal\_unit\_type的值为1-5时，表示RBSP里面包含的数据为条带（片/Slice）数据，所以值为1-5的NALU统称为VCL（视像编码层）单元，其他的NALU则称为非VCL NAL单元。

当nal\_unit\_type为7时，代表当前NALU为序列参数集，为8时为图像参数集。这也是我们打开.h264文件后，遇到的前两个NALU，它们位于码流的最前面。

而且当nal\_unit\_type为14-31时，我们可以不用理睬，目前几乎用不到。

解析完NALU Header之后，下面就开始解析RBSP了，它包含了NALU数据的主体部分，我们放在下一篇详细介绍。

4. 关于H.264的协议文档

有的同学可能还没下载H.264的官方文档，这里我再贴一下下载地址：

全部版本，下载2017最新版：

[http://www.itu.int/rec/T-REC-H.264][http_www.itu.int_rec_T-REC-H.264]

最新版为英文版，05年3月份有中文版：

[http://www.itu.int/rec/T-REC-H.264-200503-S/en][http_www.itu.int_rec_T-REC-H.264-200503-S_en]

作者：金架构  
链接：https://www.jianshu.com/p/a2dc69c8bf70  
来源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

[H264_AVC]: https://www.jianshu.com/nb/25987315
[Image 1]: 
[http_www.itu.int_rec_T-REC-H.264]: http://www.itu.int/rec/T-REC-H.264
[http_www.itu.int_rec_T-REC-H.264-200503-S_en]: http://www.itu.int/rec/T-REC-H.264-200503-S/en