HEVC编码之Intra/Inter预测分析

在OSC上潜水已经有2年多了，一直看众芸芸众生，想到如此，自己也情不自禁的投入其中。以后我也就算正式加入会员了。

第一篇博文，想想不知从何开始说起。本人是做video codec出身的，因此我打算把博客的内容主题就定位为视讯处理这个特定的圈子了。

就从工作当中的内容开始说起。记录博客，权在总结与归纳，也为了日后有困惑的地方可以有据可查。从毕业到现在一直在做视频解码的工作，我就从近期的工作开始讲起吧。

Intra&Inter宏快预测：

Intra prediction是不使用其他frame而仅仅使用当前数据快的相关区域进行预测。比较h.264的预测，HEVC除了Horizontal Vertical DC Planar 左右45度之外，还拓展了很多其他方向，在spec中称其为Angular Direction,实际上预测方向多达34种。然而使用top & left border的reference pixels也颇有讲究。这种复杂度体现在如下方面：

 1）：计算ref pixels cache的复杂度：这一点同h.264相同，对于H.265的intra TUs，首先要考虑其left 或 above相邻PUs的可用性，如果可用，则直接拷贝，否则需要做部分拷贝并进行pad extend或采取dc_avg的形式获取。那么在推倒PUs的可用性方面需要做很多推断处理(这在entropy decode中的CABAC中进行运算)。

2）：ref pixels cache的差值运算：在某些条件下，上面的cache会不能直接利用，我们需要根据TUs的size和预测方向来查表运算得到一个threshold，如果大于这个数值，那么ref pixels需要再次做interpolation差值。（大爷的！这段code我花了一周才搞定）。

  当我们大费周章的计算参考点之后，intra预测才正式开始，同h.264的8中预测模式相同的方向上，H.265采用类似优化策略。可是对于其他任意角度dir>2 && dir<34&&&dir!=HOR&&dir!=VER时，预测就会显得十分麻烦。具体参见spec的实现。个人认为，将通用模块展开成4x4到64x64的枚举case可以有效减少分支处理，在写MMX 或NEON时提供方便。

 

 Inter Prediction宏快预测:

    H.265的MC相比h.264也在复杂度上更上一层楼，对于Luma，其采用高达8-tap 四分之一像素精度的差值滤波器，在我们看起来是完全的负担（压力山大啊！汇编可要写死我也！）。对于YUV420格式的数据而言，其展开的数据预测包含如下流程：

  1): Uni-direction: 8bit--->8bit

  2): Bi-direction: 8bit--->16bit (ref0) + 8bit--->16bit (ref1) ===> ref0 + ref1 --->Add_Avg()

  3): Uni-direction(weighted mode): 8bit--->16bit===>Do_weighed ---> 8bit

  4): Bi-direction(weighted mode这个最变态)：8bit--->16bit(ref0 no-weighed with ref0) 8bit--->16bit(ref1 no-weighted with ref1)  16bit temp0(with weighted coeff) + 16bit temp1(wth weighted coeff) ===> 8 bit

   对于4x4到64x64的PU:大小划分按照如下展开：

  1：对称正方形PUs: 4x4 8x8 16x16 32x32 64x64

  2：非对称矩形PUs: 8x4 16x4 4x8 4x16 16x8 8x16 8x32 32x8 16x32 32x16 32x64 64x32 16x64 64x16

 

   优化过ffmpeg的同学应该清楚，这些不同尺寸的宏快可以通过嵌套调用来实现：比如16x16可以由4个8x8叠加来完成。而ffmpeg对于h.264只写了4x4 8x8类型，其他依照基础结构来融合。

 

  码了一个晚上，累死了，但愿inter在写neon时我的方向是正确的。