h.264對幀場編碼問題支援的比較完整，因為曾經有人問我，在h.264碼流中，是否有判別幀場編碼的元素。
我當時對h.264如果認定碼流幀場編碼不太了解，更別說是巨集塊級幀場編碼了。其實h.264對幀場編碼有兩種級別，分為
幀級和巨集塊級.幀級是對整個幀一開始就分為top field,bottom field.對兩個field分別進行me,mc,mode decision等.
而巨集塊級field編碼，就不一樣了。
我的答案是乙個巨集塊級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 0 1 2
mbinterlace
0 (1,n/a) (0,0) (0,0)
1 (0,1) (0,1) (0,1)
2 (0,1) (0,1) (0,1)
幀編碼和場編碼
在幀編碼中，參考為幀影象，採用幀運動補償，兩個場是聯合編碼 在場編碼中，參考為場影象，兩個場是分別編碼，採用場運動補償。場編碼適用場合 對於運動激烈的情況，也就是畫面變化快，畫面中的人物 背景等等短時間裡就會有很大的變化。這樣，如果使用幀編碼，由於相鄰兩行 一行在頂場，一行在底場 的掃瞄時間相差了許...
幀間差分自適應
一 目標提取 對 序列中相鄰 兩幀影象進 行幀間差 分得到運 動區域影象 運動區 域圖形與 背景影象進 行差分提 取出運動目 標影象，運 動目標影象與閾值 比較得到 二值化影象 a 對ak i，j 中每一對相鄰兩幀影象進行差分處理，獲得幀差影象dk i，j b 將幀差影象dk i，j 與背景影象bk...
關於Echart自適應的問題
echart官方提供了一套 查詢功能，可以在不同裝置上設定不同的樣式，自適應圖表，但是第一次使用卻發現無論怎麼放大縮小圖表都沒有任何變化，結果重新整理網頁之後才會生效，但是這很顯然是不符合要求的，後來查詢資源發現是使用window,resize可以監聽視窗大小，確實可以用，但是僅限於單個圖表，如果 ...