牵着老婆满街逛

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

抛砖引玉话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
f329_mbtree.jpg 
P Frame 329 without mbtree
f329_no-mbtree.jpg 

B Frame 331 with mbtree
f331_mbtree.jpg 
B Frame 331 without mbtree
f331_no-mbtree.jpg 

令人惊讶的是，对于没有进行mbtree处理的B frame，各mb的码率也都比关闭mbtree有了明显的减少，一个可能的解释在于mbtree的使用增加了P frame中被大量参考的mb的预测精度，从而使GOP内其他B frame的残差数据很少，有效降低了码率。

另外，完全和mbtree无关的I Frame，虽然整帧qp的数值相差很少，但具体来看开启mbtree后码率却也有很大的降低。这让我百思不得其解。
I Frame 310 with mbtree
f310_mbtree.jpg 
I Frame 310 without mbtree
f310_no-mbtree.jpg 

//补充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 杨粼波 阅读(552) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理