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时个人方向是正确的。