答：把 BLK_NUM[2][4][4] 前面四個一維數組和后面四個一維數組分別寫成矩陣形式：

0?? 4?? 8 12 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??? 0 1 2 3
1?? 5?? 9 13 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??? 4 5 6 7
2?? 6?? 10 14 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??? 8 9 10 11
3?? 7?? 11 15 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??? 12 13 14?? 15

觀察一下特點。再聯想一下濾波的順序——首先是垂直邊界從左到右，然后是水平邊界從上到下。可以推斷：第一矩陣就是用來標志邊界濾波強度每個 4*4 塊的垂直邊界的計算順序，第二個矩陣就是用來標志邊界濾波強度每個 4*4 塊的水平邊界的計算順序。

宏塊坐標乘 4 表示什么呢？首先我們想一下，什么東西的坐標與宏塊坐標存在 4 倍關系？是的，每個宏塊的第一個 4*4 塊的坐標與宏塊坐標存在 4 倍關系，那么宏塊坐標乘 4 當然就是表示得到每個宏塊的第一個 4*4 塊的坐標了。后面再進行一些 “+” 的操作得到的數值可能就應該是宏塊內某個 4*4 塊的坐標了（以整幅圖像左上角為原點）。

至于 blkQ >> 2和 blkQ?? & 3起什么作用，這個當然首先要看 blkQ 是什么意思了。然后把 blkQ 可能出現的值全部進行 &3 操作，一個個列在紙上，看看有什么特點。然后再推斷，驗證。


A:void DeblockMb(ImageParameters *img, byte **imgY, byte ***imgUV, int mb_y, int mb_x)
{
?? int ?? ?? ??? EdgeCondition;
?? int ?? ?? ??? dir, edge, QP ;??????? 各個參數的定義？????????????

?

多謝提示，剛剛在源碼中找到了關于環形濾波的部分，原來在編碼完成后，參考幀的更新中有deblocking filter??
/* ---------------------- Update encoder state ------------------------- */
/* update rc */
x264_cpu_restore( h->param.cpu );
x264_ratecontrol_end( h, i_frame_size * 8 );
/* handle references */
if( i_nal_ref_idc != NAL_PRIORITY_DISPOSABLE )
?? ???x264_reference_update( h );
#ifdef DEBUG_DUMP_FRAME
else
?? ??? x264_fdec_deblock( h );
#endif
x264_frame_put( h->frames.unused, h->fenc );

　我想知道，一個frame圖象結構里已經有plane保存數據了，為什么還要有filtered啊。搞的頭大死了，尤其在看幀間預測的時候，希望大家幫下忙，謝謝。原來是放半像素插值的，呵呵，終于弄懂了。

為什么在x264的編碼里面不對B幀進行濾波呢？就因為B幀不作為參考幀嗎？可還是要輸出的啊，不解，希望大家幫下忙，謝謝．

因為你在做開發的時候才需要輸出編碼端的重構圖像作參考。實際應用中，誰會把編碼的重構圖像輸出呢？輸出又有什么用呢？

if (p->MbaffFrameFlag && mb_y==16 && MbQ->mb_field)
filterTopMbEdgeFlag = 0;
這個判斷是針對域宏塊對來說的么？為什么mb_y要等于16而不是0呢？

對照標準 8.7 小節中變量 filterTopMbEdgeFlag 的推倒過程去理解。標準規定了 filterTopMbEdgeFlag = 0 有 5 種情況，自己去對照一下看該段代碼的功能與哪種情況比較吻合。
我在查閱了標準，他是這樣解釋的：
If any of the following conditions is true, the variable filterTopMbEdgeFlag is set equal to 0.
– ?? ??? MbaffFrameFlag is equal to 0 and CurrMbAddr is less than PicWidthInMbs.
– ?? ??? MbaffFrameFlag is equal to 1, ( CurrMbAddr >> 1 ) is less than PicWidthInMbs, and the macroblock CurrMbAddr is a field macroblock.
– ?? ??? MbaffFrameFlag is equal to 1, ( CurrMbAddr >> 1 ) is less than PicWidthInMbs, the macroblock CurrMbAddr is a frame macroblock, and CurrMbAddr % 2 is equal to 0.
– ?? ??? disable_deblocking_filter_idc for the slice that contains the macroblock CurrMbAddr is equal to 1
– ?? ??? disable_deblocking_filter_idc for the slice that contains the macroblock CurrMbAddr is equal to 2 and the macroblock mbAddrB is not available??? 就是第二條

看了城里漢子的帖子，并且在編碼端找到了
static const int?? b8_mode_table[6]?? = {0, 4, 5, 6, 7}; ?? ?? // DO NOT CHANGE ORDER !!!
static const int?? mb_mode_table[7]?? = {0, 1, 2, 3, P8x8, I16MB, I4MB}; // DO NOT CHANGE ORDER !!!

疑問一：b8_mode_table只有5個元素，為什么這邊數組長度定義了6？

疑問二：在解碼端ercWriteMBMODEandMV()函數中，有這樣的判斷
pRegion->regionMode = (currMB->mb_type?? ==I16MB?? ? REGMODE_INTRA ?? :
?? ?? ?? ?? ?? ?? ???currMB->b8mode==IBLOCK ? REGMODE_INTRA_8x8?? :
?? ?? ?? ?? ?? ??? currMB->b8mode==0 ?? ? REGMODE_INTER_COPY :
?? ?? ?? ?? ?? ??? currMB->b8mode==1 ?? ? REGMODE_INTER_PRED : REGMODE_INTER_PRED_8x8);

顯然這邊的currMB->b8mode值應該是在mb_mode_table[7]中，但是城里漢子說b8Mode劃分定在表格b8_mode_table中？

疑問三：能不能解釋下mb_mode_table[7]各個值的意義，我不太明白？

疑問四：currMB->mb_type的取值是劃分定在表格mb_mode_table[7]中的嗎？

1、b8_mode_table只用了5個元素。第6個空間一直沒用到，程序員的問題
2、保存宏塊模式mb_type時，都是以8*8為單位。比如16*16編碼，那么其4個8*8塊的模式都記錄為1。但不代表1就應該是b8_mode_table中的值。如果是p8*8模式，就要分別其4個8*8的具體模式（b8_mode_table中的一種），
3、分別是direct 8*8，8*8，8*4，4*8，4*4模式
4、見2