|
1. 参考帧的选择 从JMVC的MbEncoder::encodeMacroblock函数往下运行，对于P帧或B帧，需要在16x16到4x4的7种宏块分块模式中按EDCost进行选择(在MVC学习的第三周小结（2009.5.25-2009.5.31）-运动估计1中已经提及相关内容)。现在进入这些估计函数内部，来看看他们调用运动估计的过程。在MbEncoder::xEstimateMb16x16（）进行16x16的宏块RDcost计算，这里我们会看到有一段代码是判断pcMbDataAccessBase是否存在，这个变量在JMVC全部被赋值为0，不必去担心这段对于层间的参考帧初始化代码（在JSVM中会有所应用）。同样的道理if( iRefIdxTest == iBLRefIdx[uiDir] )//uiDir =0 or 1 后面跟随的代码也不会在MVC用到。去除这些，将可以减少xEstimateMb16x16（）一半的代码量。然后看看剩下部分，分别是 LIST 0 PREDICTION, LIST 1 PREDICTION,BI PREDICTION这三部分，就是先分别对两边的参考帧做运动估计，然后再计算双向估计，运动估计的入口函数estimateBlockWithStart在这里被调用，其中的双向估计用到【1】中提到的叠代估计法。最后要做的事情就是判断三种方式下的RDCost，选出最小值的模式作为16x16的最佳值数输出。。。还要和16x8。。。4x4等做比较，他们每一种的逻辑过程也和16x16类似。多大的运算量啊 2. 运动估计入口函数 estimateBlockWithStart（）这个函数一直被提到，在调用该函数之前，rpcMbTempData->getMbDataAccess().getMvPredictor（）被计算，利用中值预测产生MVPred，这个值被输入运动估计中作为搜索起点。进入estimateBlockWithStart（）后，很多过程在以前的文章中已经分析过，这里想说一下m_cParams.getSearchMode()和配置文件中的参数SearchMode是相联系的，所以按代码，可以把该项灵活配置而使用一些JMVC使用说明里没有提及的运动估计方法，甚至可以扩展自定义的方法。 对于一个宏块，以最简单的P为例，需要计算运动估计的代价是多少呢？下面给出了不同的分割对应得estimateBlockWithStart（）被调用的次数。 16x16 1 如此计算，一块P宏块要调用41次运动估计入口函数。而在实际的JMVC代码实验中，是45次。JMVC有一个xEstimateMb8x8Frext（）函数，也进行了4次函数调用。xEstimateMb8x8Frext（）和xEstimateMb8x8（）有什么区别呢？根据代码，前者会对bTrafo8x8变量赋值true而后者为false，这可以导致在xSetRdCostInterSubMb（）中计算RDCost的时候，前者的残差用8x8DCT处理，而后者用4x4DCT。一般而言，8x8DCT去相关性相对优越，所以更可能得到小的RDcost，但是块效应也比较明显。 帧间（视点间）优化有很多途径，减少运动估计的次数也是非常重要的方法。在实际的工程领域，宏块分割模式的选择应该更灵活,根据实际情况和性能需求，减少运算次数。 3. xTZSearch分析 对xTZSearch（）函数每周都陆陆续续在分析，根据上周的概括可以知道，在xTZSearch中实际被调用的只有xTZ8PointDiamondSearch，raster search和后面的star refinement过程。这里将要把这三个过程逐一说明。 .xTZ8PointDiamondSearch
当iDist>8，根据实际的输出可以看到以下搜索点 .raster search .star refinement 本周进一步学习运动估计参考帧和入口函数，并实验分析了xTZSearch（）函数，在JMVC当前代码中，视差估计和运动估计是共用的，xTZSearch可以再实际使用中，设置一些提前终止的配置值，具体利用视差特点进行优化的过程没有见到。（难道是raster search？） 本周由于时间原因，没有对亚像素点进行学习，对于视差相关论文也只看了少数，在下周（2009.6.15-2009.6.22）要进行亚像素运动估计分析，并且分析一些视差的论文。 【参考文献】 1. Siu-Wai Wu and Allen Gersho, "Joint Estimation of Forward and Backward Motion |
