牽著老婆滿街逛

嚴以律己,寬以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

統計

隨筆 - 1513
文章 - 45
評論 - 907
引用 - 0

公告

言論：
1.每日自省；
2.享受人生；
3.盡力而為；
4.堅持不懈；
5.切莫急躁；
6.慎言敏行；
7.動心忍性；
8.上善若水。

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

搜索

積分與排名

積分 - 2530781
排名 - 2

閱讀排行榜

拋磚引玉話MBTree

轉載自:http://www.nmm-hd.org/bbs/thread-906-1-1.html

從x264的1197版引入MB Tree Ratecontrol以來，時間已經過了將近兩個月，本貼旨在從個人角度談一點對MB Tree的理解和使用心得，供大家參考。由于MB Tree仍然是一個非常新鮮的內容，而且MB Tree引入給x264解碼器，特別是CRF下碼率控制帶來了巨大的變化，本人的很多理解也許有錯誤，希望大家能從自己的角度暢所欲言，讓大家共同摸清MB Tree這個葫蘆里賣的是什么藥。

什么是Macroblock Tree
Macroblock Tree是一個基于macroblock的qp控制方法。MB Tree的工作原理類似于古典的qp compression，只不過qcomp處理的對象是整張frame而MB Tree針對的是每個MB進行處理。工作過程簡單來說，是對于每個MB，向前預測一定數量的幀（該數量由rc-lookahead和keyint的較小值決定）中該MB被參考的情況，根據引用次數的多寡，決定對該MB使用何種大小的qp進行quantization。而qp的大小與被參考次數成反比，也就是說，對于被參考次數多的MB，264的解碼器認為此對應于緩慢變化的場景，因此給與比較高的質量（比較低的qp數值）。至于視頻的變化率與人眼感知能力的關系，這是一個基于主觀測試的經驗結果：視頻變化率越大人眼的敏感度越低，也就是說，人眼可以容忍快速變化場景的某些缺陷，但相對而言某些平滑場景的缺陷，人眼則相當敏感。注意此處說的平滑，指的是沿時間維度上場景的變化頻率，而非普通意義上的像素域中的場景。

MBTree File
這是一個臨時文件，記錄了每個P幀中每個MB被參考的情況。

MB Tree的處理對象
根據DS blog上的文章，目前mbtree只處理p frames的mb，同時也不支持bpyramid。

與Mbtree相關的參數
--qcomp qcomp有削弱mbtree強度的傾向，具體來說，qcomp的值越趨近于1（Constant Quantizer），mbtree的效力越差。
--rc-lookahead 決定mbtree向前預測的幀數。

Mbtree的效率
這點似乎是mbtree帶來的最直接的實惠，比如之前1197中我的測試，同樣crf中碼率節省就達到30%。下面的log是VempX大人化物語第一卷BD NCED的測試結果，使用的是x264 rev.1259

啟用mbtree

avis [info]: 1920x1080 @ 23.98 fps (2193 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:32 Avg QP:13.43  size: 81885
x264 [info]: frame P:984 Avg QP:17.83  size: 62360
x264 [info]: frame B:1177  Avg QP:18.68  size: 35058
x264 [info]: consecutive B-frames:  8.5% 52.2% 18.5% 13.7%  5.1%  1.4%  0.6%  0.0%  0.0%
x264 [info]: mb I  I16..4: 67.8%  0.0% 32.2%
x264 [info]: mb P  I16..4: 57.4%  0.0%  0.0%  P16..4: 39.5%  0.0%  0.0%  0.0%  0.0% skip: 3.0%
x264 [info]: mb B  I16..4: 18.4%  0.0%  0.0%  B16..8: 37.3%  0.0%  0.0%  direct:14.9%  skip:29.3%  L0:44.5% L1:43.7% BI:11.8%
x264 [info]: direct mvs  spatial:99.8%  temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra:23.1% 41.6% 30.4% inter:26.5% 26.7% 9.8%
x264 [info]: kb/s:9205.2

encoded 2193 frames, 3.20 fps, 9205.83 kb/s

關閉mbtree

avis [info]: 1920x1080 @ 23.98 fps (2193 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:32 Avg QP:11.89  size:110902
x264 [info]: frame P:984 Avg QP:15.05  size: 94913
x264 [info]: frame B:1177  Avg QP:17.10  size: 44859
x264 [info]: consecutive B-frames:  8.5% 52.2% 18.5% 13.7%  5.1%  1.4%  0.6%  0.0%  0.0%
x264 [info]: mb I  I16..4: 65.9%  0.0% 34.1%
x264 [info]: mb P  I16..4: 60.1%  0.0%  0.0%  P16..4: 39.2%  0.0%  0.0%  0.0%  0.0% skip: 0.7%
x264 [info]: mb B  I16..4: 25.9%  0.0%  0.0%  B16..8: 40.2%  0.0%  0.0%  direct:16.6%  skip:17.2%  L0:45.6% L1:42.2% BI:12.2%
x264 [info]: direct mvs  spatial:99.6%  temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra:49.8% 71.0% 63.4% inter:35.7% 36.6% 19.2%
x264 [info]: kb/s:13097.1

encoded 2193 frames, 3.44 fps, 13097.75 kb/s

開啟mbtree后碼率節省也達到了將近30%
至于兩者壓完后的主觀質量上的區別，我覺得在如此極端的碼率下，普通的觀看場合是看不出區別的。（逐幀的比較讓VempX來？）

一點深入的分析：
對于使用encoder的我們來說，也許需要更進一步的關注下mbtree具體是如何將碼率節省到這個地步的，在這之前，我們先回顧下264的碼率控制方法。
所謂碼率控制，指的是在給定碼率和解碼端緩沖區的限制下，如何選擇最優編碼參數的系統優化問題。x264一共支持5種碼率控制模式，而VBV的啟用可以使264以mb為單位而非以幀為單位指定qp。
簡而言之，CRF模式下碼率控制的過程由下面三步決定：
1、首先確定當前正在處理幀的碼率：由于x264使用了與畫面復雜度相關的經驗公式，于是問題被歸結于如何預測畫面復雜度。
2、對于1pass的CRF而言，畫面復雜度由殘差的SATD決定，后續GOP中的I幀qp則由之前編碼的I幀qp繼承決定。
3、之后，我們需要根據所選crf的數值，對2中獲得的數據進行scaling，以獲得最終碼率。

對于VempX壓制的化物語NCED，我稍微做點說明，這是一個符合ds描述的典型的anime片段，2193幀被分為了將近30個場景，而每個場景中大部分畫面都是靜止和緩慢運動的，也就是說這從理論上應是一個符合mbtree優化條件的樣本。
我通過H.264visa仔細觀察了下329-333這個GOP中首部P幀和中部B幀的mb碼率分布情況，329-333的編碼順序如下
329(P)->333(P)->330(B)->331(B)->332(B)
根據前面分析，mbtree在處理第一個Pframe（329），會向前預測該幀在330-333幀中被參考的多少（以mb為單位）。

P Frame 329 with mbtree

P Frame 329 without mbtree

B Frame 331 with mbtree

B Frame 331 without mbtree

令人驚訝的是，對于沒有進行mbtree處理的B frame，各mb的碼率也都比關閉mbtree有了明顯的減少，一個可能的解釋在于mbtree的使用增加了P frame中被大量參考的mb的預測精度，從而使GOP內其他B frame的殘差數據很少，有效降低了碼率。

另外，完全和mbtree無關的I Frame，雖然整幀qp的數值相差很少，但具體來看開啟mbtree后碼率卻也有很大的降低。這讓我百思不得其解。
I Frame 310 with mbtree

I Frame 310 without mbtree

//補充1：
就mbtree本身而言，其理應不會影響某一mb編碼時mode decision的判定（inter[p,b]/intra）。但由于之后該GOP內剩余的B幀皆要使用頭尾的IDR frame做預測（no-bpyramid），開啟mbtree之后由于影響了IDR frame（首位p frame）中的mb，而之前的假定又表明對于大量參考的mb，mbtree會分配一個較小的qp（意味著更準確的重建質量），故之后GOP中其余B frame的mb mode decision，會產生一定變化。如331幀中B-MB的數量增加了1000多（意味著從前后兩個IDR中的預測更準確），而B-MB中skip的數量更是增加了接近300%（意味著重復利用的信息被高精度的保存了）。

（或許未完待續）

posted on 2013-08-15 16:42 楊粼波閱讀(609) 評論(0) 編輯收藏引用

只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

牽著老婆滿街逛

導航

統計

公告

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

工具官網

技術網站

開源網站

其他窩點

收藏網站

銀行官網

友情鏈接

資源共享

搜索

積分與排名

最新評論

閱讀排行榜

拋磚引玉話MBTree