【AV1 spec学习一】OBU类型及码流结构

基本概念

刚开始看AV1 spec，对一些初见的名词在此做些记录，随见随添。

缩写	全称	含义
OBU	Open Bitstream Unit	AV1的语法结构都打包在OBU中。 每个OBU都有一个header，header提供该OBU所包含数据(payload)的标识信息。存在一种只有header的OBU（header-only OBU）。

基本语法表示形式

形式	含义
leb128()	用于编码表示一个变量的值 （如长度），解码时每次读一个字节，每个字节的MSB是信号位，低7-bit以二进制的形式表示值：字节的MSB为1表示解码该值需要继续读取下一个字节；字节的MSB为0表示该值的所有表示已达尾端。

OBU类型

AV1的语法结构都以OBU的形式打包，每个OBU都有自己的obu_header，obu_header中会标明obu_type，根据obu_type可将OBU区分为以下几类：

• sequence_header_obu，标识profile、still_picture、frame_width_bits_minus_1、frame_height_bits_minus_1等序列信息和一些滤波和编码工具开关信息。同时序列的BitDepth和颜色格式信息也在sequence_header_obu中以color_config的形式标识。（详见AV1 spec 5.5.1。）

• temporal_delimiter_obu，一个payload为空的obu。解码端发现这个OBU时不需要解析码流，但是要将SeenFrameHeader设置为0。（详见AV1 spec 5.6。）

• frame_header_obu，标识display_frame_id、frame_type等信息，同时也传输屏幕内容编码工具、MV精度控制、参考帧、tile划分、量化参数、滤波参数、frame_size等信息。可以说frame_header中存有解码所需要的大部分功能控制类信息。需要注意的是frame_header_obu可对应OBU_FRAME_HEADER和OBU_REDUNDANT_FRAME_HEADER两种obu_type。
  – 当obu_type为OBU_FRAME_HEADER时OBU payload中有完整的frame_header信息（SeenFrameHeader为0）；
  – 当obu_type为OBU_REDUNDANT_FRAME_HEADER时，复制此前得到的frame_header信息（SeenFrameHeader为1）。（详见AV1 spec 5.9。）
  Spec中关于frame_header_obu的几个重要备注摘录如下。

  Note1: Bitstreams may contain several copies of the frame_header_obu interspersed with tile_group_obu to allow for greater error resilience. However, the copies must contain identical contents to the original frame_header_obu.

  If obu_type is equal to OBU_FRAME_HEADER, it is a requirement of bitstream conformance that SeenFrameHeader is equal to 0.
  If obu_type is equal to OBU_REDUNDANT_FRAME_HEADER, it is a requirement of bitstream conformance that SeenFrameHeader is equal to 1.

  Note2: These requirements ensure that the first frame header for a frame has obu_type equal to OBU_FRAME_HEADER, while later copies of this frame header (if present) have obu_type equal to OBU_REDUNDANT_FRAME_HEADER.

  有个不解之处，按照Note1中所述，码流中为了提高容错性允许传输与原始frame_header_obu相同的多份header信息；按照Note2中所述，后传的frame_header_obu都是OBU_REDUNDANT_FRAME_HEADER类型的（此时SeenFrameHeader为1）。但是当SeenFrameHeader为1时解码器只是将之前已收到的“original frame_header_obu”信息复制一份插入使用，那么如果“original frame_header_obu”就已经出错或丢失的话，这个机制是如何提高容错性的呢？有一个可能是后续传输的是OBU_FRAME_HEADER类型的frame_header_obu，但在那之前要传一个temporal_delimiter_obu将*SeenFrameHeader *设置为0。当然这只是本人的一个猜测，先留个坑在这里，后续分析代码如果能有明确答案再填上。

• frame_obu，内含frame_header_obu和tile_group_obu。详见AV1 spec 5.10。）

• tile_group_obu，包含一个或多个tile（及tile内SB）的码流信息。（详见AV1 spec 5.11.1。）

• metadata_obu，包含已定义好的多种metadata，以metadata_type标识。解码器发现无法识别的metadata_type时，可将整个OBU丢弃。（详见AV1 spec 5.8.1。）

• tile_list_obu，标识output_frame_width_in_tiles_minus_1、output_frame_height_in_tiles_minus_1、tile_count_minus_1、tile_list_entry()信息。在tile_list_entry中包含anchor_frame_idx、anchor_tile_row、anchor_tile_col、tile_data_size_minus_1、coded_tile_data。从spec上看，这tile list是取自不多于127个frame的随机tile集合（集合中tile的个数不多于511个），coded_tile_data中存储的也是来自这个集合的下层码流数据。这是一个很有趣的语法，但是不知道应用场景是什么。在spec中也不要求解码器一定要能解码该类型的码流，引用AV1 spec 7.3.1部分内容如下：

  The large scale tile decoding process is used to decode a random subset of tiles taken from a number of coded frames.
  The list of tiles is specified by a tile list OBU. One possible use case for this process is described in Annex D.

  Note: A decoder is recommended to support decoding of tile list OBUs, but this is not a requirement for decoder conformance.

• padding_obu，一个填充数据OBU，可以被AV1标准解码器忽略。 该OBU类型的payload有效内容的最后一个字节被视为payload中最后一个非零字节（其他的OBU也有类似规则，如metadata_obu等）。（详见AV1 spec 5.7。）

• reserved_obu。若一个OBU的obu_type与上述所有OBU都不相同的话，则该OBU为reserved_obu。reserved_obu是payload为空的OBU，但是与temporal_delimiter_obu的不同之处在于，reserved_obu是既不解析码流也不对任何变量做任何操作。（详见AV1 spec 5.4。）
  

码流结构

从上文分析，一段AV1码流可以由sequence_header_obu,frame_obu组成，也可由sequence_header_obu,frame_obu,frame_header_obu, tile_group_obu,temporal_delimiter_obu穿插组成。下图是一个简单的码流结构示意图。