AnnexB是一种常见的视频流NALU封装格式，主要用于H.264和H.265视频编码标准。其特性包括插入开始代码以标识NALU单元的开始，以及使用字节流方式传输数据。
在理解AnnexB格式之前，首先需要了解NALU（Network Abstraction Layer Units）单元的概念。在H.264/H.265编码中，每个视频帧被编码为一个或多个NALU单元。
每个NALU单元都可以看作是视频数据的一个独立包，它包含一定数量的原始字节数据。这些数据可以是图像切片、序列参数集（SPS）、图像参数集（PPS）等类型。
为了在字节流中识别出每个NALU单元的开始位置，AnnexB格式引入了所谓的"开始代码"。开始代码可以是两种形式：0x000001或0x00000001。当解析器在字节流中遇到这样的模式时，它知道一个新的NALU单元开始了。
接下来深入探讨一下AnnexB格式的具体内容和结构。
AnnexB格式基本上就是一连串的NALU单元，每个单元由一个开始代码和随后的原始字节数据组成。
[开始代码] [NALU单元] [开始代码] [NALU单元] ...
在某些情况下，例如当数据被封装到其他容器（如MPEG-TS、MP4等）时，可能需要使用"长度前缀"而不是"开始代码"。长度前缀是一个固定长度的字段，通常为4个字节，表示接下来的NALU单元的长度。然而，这并不是AnnexB格式的一部分，而是属于AVCC格式。
正如上文所述，有时需要将AnnexB格式转换为AVCC格式。这主要涉及两步：去掉开始代码，并添加长度前缀。
以下是一个简单的Python示例，演示如何进行此转换：
def annexb_to_avcc(annexb):
avcc = b''
nal_units = annexb.split(b'\x00\x00\x01')
for nal_unit in nal_units:
if len(nal_unit) == 0: continue
length_prefix = len(nal_unit).to_bytes(4, 'big')
avcc += length_prefix + nal_unit
return avcc
注意，上述示例假设所有的开始代码都是0x000001。实际上，开始代码也可能是0x00000001，这种情况在处理时会稍微复杂一点。
AnnexB格式的主要优点是它非常简单。只需通过查找开始代码就可以在字节流中定位NALU单元。此外，由于每个NALU单元都是独立的，因此可以轻松处理视频流的一部分，而不必解析整个流。
AnnexB格式的主要缺点是它无法直接用于某些应用场景，例如封装到其他容器中（如MP4和MOV）。这就需要转换为AVCC格式或其他类似的格式。此外，由于开始代码可能存在于NALU单元的原始数据中，所以在处理时需要特别小心。
一种常见的问题是如何确定开始代码的长度。在理想情况下，开始代码应该是0x000001，但在实践中，它也可能是0x00000001。解决方案通常是检查第一个非零字节后面的字节：如果它是1，则开始代码的长度为3，否则为4。
另一个常见的问题是如何处理存在于NALU单元原始数据中的开始代码。解决方案是在编码过程中进行"逃逸编码"：每当遇到0x000003的模式时，就将其替换为0x00000303。这样，在解码时就可以安全地忽略第二个03字节，而不会误判为开始代码。
AnnexB格式主要出现在视频流传输和存储的环境中。它是ITU-T H.264（也称为MPEG-4 AVC）和H.265（也称为HEVC）视频编码标准的一部分。
在实时视频流传输中，如RTSP（Real Time Streaming Protocol）和RTP（Real-time Transport Protocol），AnnexB格式被广泛使用。在这些情况下，每个NALU单元都可以被视为一个独立的包，可以单独发送。这种NALU单元级别的可分割性使得AnnexB格式非常适合于实时视频流传输。
在视频文件存储中，如MP4、MKV等容器格式，原始的H.264/H.265数据通常需要从AnnexB格式转换为AVCC或其他类似格式。这是因为这些容器格式通常使用长度前缀而不是开始代码来标识NALU单元的边界。然而，在某些情况下，例如在MPEG-2 TS流中，仍然可能使用AnnexB格式。
许多硬件和软件编解码器都支持AnnexB格式。例如，FFmpeg库和x264/x265编解码器就提供了对AnnexB格式的内置支持。这些编解码器通常允许用户选择是否使用AnnexB格式，以及如何处理SPS和PPS等NALU单元。
总的来说，AnnexB格式在各种视频编解码、传输和存储的应用场景中都有重要作用。其简单的结构和灵活的NALU单元级别的可分割性使其在处理H.264/H.265视频数据时具有广泛的适用性。