本文主要是介绍[AVC(H.264)] 抛砖引玉话MBTree，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
从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%（意味着重复利用的信息被高精度的保存了）。
我又做了一个简单的测试，使用的片源是Chobits的NCOP。
首先我使用我一直以来做DVDRip用的参数，在crf18下，以r1195版本进行了1pass的压制。
r1195的crf18得到了码率1200K，接下来，我用r1268，在保持所有参数不变的前提下，关闭了mbtree，以1200K码率进行了2pass的编码
参数不变，打开mbtree，2pass编码
PSNR我只是顺便计算了，不过我们无视掉它好了，只看SSIM就够了
r1195 crf 18: SSIM Mean Y:0.9903087
r1268 no-mbtree: SSIM Mean Y:0.9905871
r1268 mbtree: SSIM Mean Y:0.9908447
这是SSIM的比较结果，再看看各自的平均QP
r1195 crf 18：
x264 [info]: slice I:39 Avg QP:13.23
x264 [info]: slice P:930 Avg QP:15.56
x264 [info]: slice B:1367 Avg QP:17.43
r1268 no-mbtree：
x264 [info]: profile High, level 4.1
x264 [info]: frame I:39 Avg QP:13.52
x264 [info]: frame P:932 Avg QP:15.50
x264 [info]: frame B:1365 Avg QP:17.60
r1268 mbtree：
x264 [info]: frame I:39 Avg QP:14.38
x264 [info]: frame P:934 Avg QP:17.07
x264 [info]: frame B:1363 Avg QP:19.28
结果很有意思，打开了mbtree之后，平均的QP都比前两个有所提高，但是SSIM却没有降低，不知道这是不是dark shikari嘴里所说的Magic XD
这篇关于[AVC(H.264)] 抛砖引玉话MBTree的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
