由于DPB中間的參考幀的MV都是以4X4塊為單位，現在以8X8塊作Direct mode模式，所以必須對子塊的MV作合并，
JM采用的東西是如下圖的方式:
x o | o x
o o | o o
- - - - -
o o | o o
x o | o x
每8X8塊取外角上的4X4塊的MV.
算法如下:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
??
b8Mode是幀間預測中對8X8塊的再次細分，稱為亞宏塊級模式，劃分定在表格b8_mode_table中
const int?? b8_mode_table[6]?? = {0, 4, 5, 6, 7};
其中0是8X8 Direct模式，只對B幀,4,8X8,5,8X4,6,4X8,7,4X4，以上5中模式在宏塊級中統稱為P8X8模式，這個可以在碼流TRACE文件中可以應證。

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

264標準中可以對宏塊級語法元素按照重要的等級進行分區，可以分為分區A,B,C, 這個數據分區可以根據數組映射獲得264時如何處理分區得.涉及到3個數組.
typedef enum??
{
?? SE_HEADER,
?? SE_PTYPE,
?? SE_MBTYPE,
?? SE_REFFRAME,
?? SE_INTRAPREDMODE,
?? SE_MVD,
?? SE_CBP_INTRA,
?? SE_LUM_DC_INTRA,
?? SE_CHR_DC_INTRA,
?? SE_LUM_AC_INTRA,
?? SE_CHR_AC_INTRA,
?? SE_CBP_INTER,
?? SE_LUM_DC_INTER,
?? SE_CHR_DC_INTER,
?? SE_LUM_AC_INTER,
?? SE_CHR_AC_INTER,
?? SE_DELTA_QUANT_INTER,
?? SE_DELTA_QUANT_INTRA,
?? SE_BFRAME,
?? SE_EOS,
?? SE_MAX_ELEMENTS?? //!< number of maximum syntax elements
} SE_type; ?? ?? // substituting the definitions in elements.h
以上定義了264宏塊級編碼要用到的語法元素，當然不是所有的宏塊編碼都有以上元素,根據幀內，幀間,實際編碼過程中，等有所不同。
關于以上的元素具體含義，參考JM或標準可以獲得，不過有些元素似乎在JM中并沒有利用到，比如SE_EOS，不知道最新版如何？

int assignSE2partition_NoDP[SE_MAX_ELEMENTS] =
?? {?? 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
int assignSE2partition_DP[SE_MAX_ELEMENTS] =
?? {?? 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 2, 2, 2, 2, 0, 0, 0, 0 } ;
上面元素0，代表DPA,1代表DPB,2代表DPC,可以看出來假如沒有定義數據分區得話:所有的語法元素都是DPA,定義了數據分區，那么幀內系數是分區B,幀間系數是分區C，其他的元素都是分區A.可以看得出來，遭遇信道丟包時，
光有DPB或DPC，沒有DPA是無法解出碼流的，假如沒有DPB,DPC的話，還可以根據DPA的元素獲得近似值。 那么JM是如何實現宏塊級數據分區管理的呢，這個由Slice里面的datapartition數組管理，第一個成員為DPA， 第二個為DPB，第三個為DPC，可以根據語法元素切換輸出到A,B,C中.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
??
把編碼方式切換到CAVLC，其實在foreman測試序列，個人覺得CABAC,CAVLC編碼壓縮效率差別不大
SNR更是差不多,但是CAVLC要簡單很多。
經過一個晚上的艱苦戰斗，初步得出結論,SKIP模式對B,P幀而言，DIRECT模式只對B而言,
個人覺得DIRECT模式,SKIP模式，這種說法有些讓人困惑。
下面講B幀的DIRECT,SKIP模式:
DIRECT,SKIP，模式相同的是，他們的宏塊類型都是0，運動向量殘差都為0，因為MVD可以通過臨塊預測方式得到
但是SKIP模式的cbp為0，也就是沒有殘差傳輸，它是雙向預測，參考幀在LIST0,LIST1中的
序號也是根據臨塊的參考幀情況獲得(注意不一定序號非的是0)，所以連參考幀都不用傳輸.,
SKIP模式有更嚴格的要求,CBP為0，也就是沒有殘差系數，達到最大的壓縮效率。
再講P幀的SKIP模式，但前象預測，參考幀為LIST0中序號為0幀，無參考幀編碼，CBP為0，無殘差系數編碼.
她們的分塊模式為0，都是16X16.
但是在CAVLC中，SKIP模式，對SKIP宏塊沒有任何實際編碼碼流，解碼器是如何識別這個宏塊存在的，
大家打開TRACE文件，可以看到為一個SKIP或者連續幾個SKIP宏塊結束后，接著下一個非SKIP宏塊，
一開始就有一個語法元素,mb_skip_run有一個值，這個元素采用Exp-Golomb編碼,這個值的意思就是前面有多少個SKIP塊，這就是264碼流
巧妙的解決方案，當遇到這個元素非0的時候，就自動往前面做SKIP宏塊填充,.
@34679 mb_skip_run ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 1 (?? 0)??
@34680 mb_type (P_SLICE) ( 4, 1) = 2 ?? ?? ?? ?? ?? ?? ?? ?? ??? 010 (?? 1)??
@34683 mvd_l0 (0) =?? -6?? (org_mv -10 pred_mv?? -4) ?? ?? ?? ??? 0001101 ( -6)??
@34690 mvd_l0 (1) = 0?? (org_mv 0 pred_mv 0) ?? ?? ?? ?? ?? ??? 1 (?? 0)??
@34691 mvd_l0 (0) = -11?? (org_mv -20 pred_mv?? -9) ?? ?? ?? 000010111 (-11)??
@34700 mvd_l0 (1) = 7?? (org_mv 9 pred_mv 2) ?? ?? ?? ??? 0001110 (?? 7)??
@34707 CBP ( 4, 1) = 0 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 1 (?? 0)??

*********** Pic: 2 (I/P) MB: 16 Slice: 0 **********


*********** Pic: 2 (I/P) MB: 17 Slice: 0 **********


*********** Pic: 2 (I/P) MB: 18 Slice: 0 **********

@34708 mb_skip_run ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 011 (?? 2)??
@34711 mb_type (P_SLICE) ( 7, 1) = 8 ?? ?? ?? ?? ?? ?? ?? ?? 00101 (?? 4)??
上面表示18號宏塊前面有2個SKIP宏塊，解碼器然后可以自動填充。
其實本來解決這個問題，可以用更少的時間來解決這個問題，但是，JM97對TRACE文件輸出，有一個bug，
導致,輸出的TRACE混亂錯誤，無法理解，浪費了大量的時間，花了幾個小時才找出解決這個bug，該bug位于
writeSyntaxElement2Buf_Fixed函數中，這個地方需要注釋掉TRACE輸出。
int writeSyntaxElement2Buf_Fixed(SyntaxElement *se, Bitstream* this_streamBuffer )
{

?? writeUVLC2buffer(se, this_streamBuffer );

#if TRACE
// if(se->type <= 1)
//?? trace2out (se);
#endif
?? return (se->len);
}
其實上面兩句是留給MBHEADER輸出的，因為它不用參加RDO rate計算
個人覺得JM對TRACE文件的輸出管理還有些問題，有待修改，不知道在新的JM版本中有沒有修正這個bug.
這個也算是解決這個問題的副產品.

另外CABAC對貸這個問題好像不一樣，有時間可以在研究這個問題

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
??
求象素的灰度.....
#define MAX_LEN (1000*3)
unsigned char RGB[MAX_LEN]={2,2,2,4,5,6,7,8,9,0};
unsigned int mulData[7] = {313524,615514,119538};
__int64 mask1 = 0xFFFFFFFF00000000;
__int64 mask2 = 0x00000000FFFF0000;
__int64 mask3 = 0x000000000000FFFF;

int main(int argc, char* argv[])
{
char gray = 0;
unsigned int Y=(((RGB[0]*mulData[0]))+((RGB[1]*mulData[1]))+((RGB[2]*mulData[2])))>>20;
_asm{
pxor mm7,mm7
pxor mm6,mm6
mov ecx,0
sloop: movd mm0,[mulData+ecx*4]
punpcklwd mm0,mm7
mov al,[RGB+ecx]
and eax,0X000000FF
movd mm1,eax
movd mm2,eax
;;;;;;;;;;;;;;;;;;;;;;;;;;;
punpckldq mm1,mm2
movq mm4,mm1
movq mm5,mm0
punpcklwd mm4,mm1
punpcklbw mm5,mm7
pmullw mm4,mm5
;;;;;;;;;;;;;;;;;;;;;;;;;;;
pmullw mm1,mm0
pand mm1,mask1
movq mm0,mm4
pand mm0,mask2
pand mm4,mask3
psrlq mm0,8
paddd mm1,mm0
paddd mm1,mm4
movq mm3,mm1
pand mm3,mask1
psrlq mm3,16
paddd mm1,mm3
paddd mm6,mm1
inc ecx
cmp ecx,3
jl sloop
psrld mm6,20
movd eax,mm6
mov gray,al
emms
}
return 0;
}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
??
H.264對幀場編碼問題支持的比較完整，因為曾經有人問我，在h.264碼流中，是否有判別幀場編碼的元素。
我當時對H.264如果認定碼流幀場編碼不太了解，更別說是宏塊級幀場編碼了。其實H.264對幀場編碼有兩種級別，分為
幀級和宏塊級.幀級是對整個幀一開始就分為top field,bottom field.對兩個field分別進行ME,MC,mode decision等. 而宏塊級Field編碼，就不一樣了。曾經在流媒體網站H.264分塊看到有一牛人對宏塊級Field編碼的解釋，我感到疑惑，
但當時修行不夠，說不出所以然，現在把那段話貼在這里:
jamie80:
"
當 MbaffFrameFlag = 1 & currMb->mb_field 時，偶數行放在宏塊的上半部分(16x8)來編碼,而奇數行位于下半部分來編碼。
如果當前宏塊的mb_field為0(幀編碼)而左鄰居宏塊的mb_field為1(場編碼)，這樣其左鄰居像素就可以屬于不同的4x4塊，
至少左鄰居奇數行的像素和偶數行的像素肯定不屬于同一個4x4塊，所以我們需要對它們區別對待。
(MB Adaptive Frame/Field給H.264帶來不少麻煩)
我的答案是一個宏塊級field編碼，是這樣子的，JM里面給出解釋的是Field MB pair，場宏塊對。也就是a couple of Field
沒有單獨存在的一個Field宏塊，只有Field MB pair.上面一個是Top field MB(兩個MB的偶數行),下面一個是Bottom MB
(兩個宏塊的奇數行),宏塊序號上下是連續的，這個和一般的編號方式不同,上面一個是偶數,下面一個是奇數.
而不是象上面那段話那樣，只有半個宏塊的問題.
對此，我們做出解釋,現在我們研究函數void dpb_split_field(FrameStore *fs),該函數完成的任務是對即將送入DPB的重建幀
進行幀場分解，解出top,bottom field,對頂底場進行1/4象素插值,復制場參數，分解運動向量，參考幀序號，參考幀id等。
宏塊級幀場自適應模式需要對宏塊對進行場模式和幀模式分別編碼，計算她們的RDCOST，選其中最少的RDCOST作為編碼方式，所以
自適應方式做最佳編碼是付出了計算復雜度大大增加的代價。同樣幀級幀場自適應方式需要幀編碼，和場編碼分別進行，
計算RDCOST最少值作為最佳編碼，同樣付出計算復雜度.
?? 回到文章開始時候提出的問題，碼流中是否有標志指示后面訪問單元(Access Unit)的幀場編碼方式，答案是肯定的，在一個
SPS(sequence parameter set)中能找到frame_mbs_only_flag標志，該標志顯示是否幀編碼，如果為0，那么還有一個參數
mb_adaptive_frame_field_flag，下面對配置參數和以上兩個元素的關系進行說明
PicInterlace代表幀級隔行掃描,MbInterlace代表宏塊級隔行掃描
PicInterlace ?? ?? ?? =?? 0 ??? # Picture AFF (0: frame coding, 1: field coding, 2:adaptive frame/field coding)
MbInterlace ?? ?? ?? ??? =?? 0 ??? # Macroblock AFF (0: frame coding, 1: field coding, 2:adaptive frame/field coding)
交叉位置(frame_mbs_only_flag, mb_adaptive_frame_field_flag),N/A為不需要該元素

?? ?? ?? ＼PicInterlace MbInterlace ＼	0	1	2
0	(1,N/A)	(0,0)	(0,0)
1	(0,1)	(0,1)	(0,1)
2	(0,1)	(0,1)	(0,1)