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時個人方向是正確的。