牵着老婆满街逛

严以律己,宽以待人. 三思而后行.
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 杨粼波 阅读(388) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理