H265/HEVC编解码系列（1）：图像分割（Slice、Tile、CTU）

一、Slice 和 Slice Segment

  H265和H264类似，图片也采用了slice的分割方法，一帧图片可以被分割成一个或者多个slice，每一个slice都可以独立解码，不依赖于同张图片的其他slice。那也就意味着在进行帧内和帧间预测时不能越过slice的边界，但是在解码最后环路滤波时，允许滤波器跨越slice边界进行滤波。
 
  采用slice分割主要有以下好处：
  第一，鲁棒性良好，把一张图片分成一个个独立的slice，在解码时遇到错误，也可以实现再同步，减少错误蔓延，而代价仅仅是失去了一个slice。
  第二，匹配MTU（Maximum Transmission Unit）大小，这涉及到网络层的概念，网络上发包时，每个包的大小受到限制，把图像分割成slice可以减小打包的大小。
  第三，并行处理，由于每个slice相互独立的缘故，编码、解码以至环路滤波均可以并行处理，加快处理速度，提高效率。
 
  如下图，为一张图片分割后的结果，这张图片被分割成两个slice，图中黑色实线（即Slice Boundary）为slice边界，可以看到实线下方为一块完整的区域，而实线上方又被分成了3块小区域，以虚线分隔。这每一块小区域称为片段SS（Slice Segment），即slice又可以分为SS，每个slice的第一块SS称为独立SS（图中蓝色部分），后面的均为依赖SS（图中未涂色部分）；独立SS是指它所涉及的句法元素可以由自身确定，依赖SS是指它所涉及的某些句法元素由已解码的独立SS推导得到，依赖SS可以共享独立SS携带的一些信息。预测的过程不可以跨越独立SS的边界，但是可以跨越依赖SS的边界，一个slice中的SS可以互相参考。
 
  下面的图中，还可以看到标有数字的小方格，每个SS由这一个个小方格组成，这每一个小方格称为一个树形编码单元CTU（Coding Tree Unit），这类似于H264中的宏块。有些文章里把这些小方格叫做树形编码块CTB（Coding Tree Block），其实差不多。实际上，一个CTU是由一个亮度（luma）CTB和相应色度（chroma）CTB构成。

二、Tile单元

  H265与H264不同之处在于引入了Tile的概念，PPS（Picture Parameter Set）中tiles_enabled_flag参数指定了是否使用Tile格式，num_tile_columns_minus1、num_tile_rows_ minus1、uniform_spacing_flag、column_width_minus1、row_ height_minus1规定了Tile的结构大小（这些参数以后再说）。Tile和slice一样也是可以单独解码，不依赖其他Tile。
 
  如下图，一张图片被分为了九个区域，但是这些区域必须是矩形，而slice是条带状。可以看到，Tile是由CTU直接组成。相比于slice的分割方法，Tile的分割方法使得编码效率更高，因为条带状的分割方式使得像素之间的关联程度大大下降，编解码的效率大打折扣。同时，slice的传输需要加上一个slice header，当码率较大时，header的开销无法被忽略，而Tile不需要header，进一步提高了编码效率。

  细心一点可以注意到，slice中的CTU是以光栅扫描（raster scan）的形式排布的，即从左到右、从上到下；而Tile在划分为矩形块后，不仅每个小块内以光栅扫描方式排布，而且每个矩形块也是按光栅扫描方式排布。这种扫描方式可以减少运动估计（Motion Estimation）时所需行buffer大小。如下图所示，虚线矩形框代表的时运动估计的范围，涂黑的方格为一行参与编码的CTU，若用公式表达一般raster scan和Tile的扫描方式所占用的运动估计buffer：
 

RSBuffer = PicW * （2 * SRy + CtuHeight）
TileBuffer = （TileW + 2 * SRx） * （2 * SRy + CtuHeight）

 
  PicW是图像的宽度，SRy是CTU上下延伸的范围（图中绿色双向箭头），SRx是CTU左右延伸的范围（图中黑色双向箭头），CtuHeight为每个CTU的高度。能看到，当PicW大于（TileW + 2 * SRx)时，Tile在做运动估计时将占用更小的内存。

  如下图所示，图片中使用了Tile和slice结合的分割方法。左图和右图均被分为了两个Tile，中间竖直虚线为分界线。左图中只划分了一个slice，一个独立SS和四个依赖SS（蓝色部分为独立SS，未涂色部分为依赖SS）；而右图划分了3个slice，每个slice包含一个独立SS和一个依赖SS。这两种划分方式并不是随意划分，而是需要遵循一定规则：
  第一，一个slice/SS中的所有CTU属于同一个Tile；
  第二，一个Tile中的所有CTU属于同一个slice/SS。

三、CTU、CU

  之前传统的编码（例如H264）均是基于宏块实现的，对于4:2:0的采样格式，每个宏块包含一个16x16大小的色度块，以及一个8x8大小的亮度块。而H265提出了CTU的概念，它的尺寸可以由编码器指定，在图像细节较多的地方可以采用较小的编码块，在平坦的地方可以选择较大的编码块。除了CTU，H265还提出了CU（Coding Unit）、PU（Prediction Unit）、TU（Transform Unit），这些后面再说。
 
  上面说了一个CTU由一个亮度CTB和相应色度CTB构成，因为采样的格式不同，亮度CTB相同的情况下，色度CTB的大小会不一样，所以我们只需要关注亮度CTB大小即可。一个CTU所含亮度CTB的大小为NxN，N取值为16、32、64。下图a即是16x16大小的CTU，b图是64x64大小的CTU，可以看到，a图CTU所包含的区域很小，而b图CTU包含的区域又很大，所以在H265中，大的区域可以以四叉树的形式继续往下分割。

  CTU再往下一级叫做CU，和它的老大CTU一样，CU也是由一个亮度CB（Coding Block）和相应色度CB构成。同样道理，CTU可以继续分割，CTB也可以继续往下分割为更小的CB，上面讲到亮度CTB最小为16x16，而分割成的CB最小为8x8。先看一张直观的图，很直观，直观到应该不用我过多赘述。

  再看一张抽象一点的，四叉树模型，这图应该也不难懂，下左图中的数字就代表了CTU编码的顺序。至于PU、TU后面再补上。文章有错误的请指正，共同学习。

参考

• [1] [新一代高效视频编码H.265/HEVC原理、标准与实现]
• [2] [High Efficiency Video Coding(Hevc) Algorithms and Architectures]
• [3] [An Overview of Tiles in HEVC, Kiran Misra, Member, IEEE]