HEVC_CJL的专栏

个人原因（实习，找工作等），对HEVC的学习研究，特别是本博客的更新已经有了较大的疏忽，对于大家的留言没有及时回复，还请大家海涵。自本文章发表之日起，重新恢复之前的研究强度，至于博客方面，更新可能就不会那么频繁了，毕竟也没有太多可以公开发表的了。不过，我也希望在接下来的一段时间能给大家提供尽可能多的帮助。如果大家有什么问题，可以在本博客进行留言，也可以发邮件至jlchen198901@163.co

本文将对实现merge模式的主函数xCheckRDCostMerge2Nx2N进行分析，方便理清merge模式的整个过程。之前的一篇分析了getInterMergeCandidates的具体实现，还有两个比较重要的函数motionCompensation和encodeResAndCalcRdInterCU，将留在后面陆续进行分析，但是根据它们的命名就不难猜出它们的作用，而且事实也是这样，因此对理解

为了更好地理解帧内预测中的各个函数的原理过程，有必要对CU、PU地址计算方法有着较好的了解，因此，本文将对这个问题先做个讨论。 对视频编解码有一定了解的人应该会知道，有一种扫描顺序叫光栅扫描，即从左往右，由上往下，先扫描完一行，再移至下一行起始位置继续扫描。H.264使用的主要就是光栅扫描顺序，（当然它还有其它扫描顺序，被包含在FMO即灵活宏块顺序技术里）。 HEVC里同样也有光栅

在上一篇介绍的函数中，在求TMVP时调用了一个比较重要的函数，xGetColMVP。本文对该函数进行较为详细的分析：Bool TComDataCU::xGetColMVP( RefPicList eRefPicList, Int uiCUAddr, Int uiPartUnitIdx, TComMv& rcMv, Int& riRefIdx ){//! 这部分的内容可以参考draft 8.

从今天开始，正式转入到帧间预测方向。由于帧间预测涉及到的方面广且复杂，所以我的理解出现错误的情况可能会更多，请大家以辩证的眼光来看待我的帖子，有问题欢迎大家批评指正。 大家都知道xCompressCU是实际进行预测编码的函数，故很容易就能锁定帧间预测的一个大致范围，在研究了帧内预测的基础上，相信很快就能在该函数中找到与帧间预测相关的函数：xCheckRDCostInter，xCheckRD

接下来有关HEVC的文章都是HEVC学习系列的延续，但由于序号偏多，为方便起见，就不再单独编号，直接以讨论内容作为题目了。 要研究CU级的代码，少不了要接触到这么一个类TComDataCU。为了比较顺畅地看代码，对这个类的重要成员自然需要有比较好的认识才行，这就是本文的目的，给大家提供一个共同讨论类中私有成员含义与作用的平台。 class TComDataCU{privat

//! 用于significant_coeff_flag的上下文推导过程的模式选择 draft 9.3.3.1.4Int TComTrQuant::calcPatternSigCtx( const UInt* sigCoeffGroupFlag, UInt posXCG, UInt posYCG, Int width, Int height ){ if( width == 4 &&

为了更好地与draft进行对应，看HM中的反量化部分代码：Void TComTrQuant::xDeQuant(Int bitDepth, const TCoeff* pSrc, Int* pDes, Int iWidth, Int iHeight, Int scalingListType ){ const TCoeff* piQCoef = pSrc; Int*

Void TComTrQuant::transformNxN( TComDataCU* pcCU, Pel* pcResidual, //!< 残差 UInt uiStride,

先列出HM中与draft对应的几个表格，随着研究的深入，本文会慢慢补充。enum ScalingListSize{ SCALING_LIST_4x4 = 0, SCALING_LIST_8x8, SCALING_LIST_16x16, SCALING_LIST_32x32, SCALING_LIST_SIZE_NUM}; //!< Table 7-2 (S

本文首先介绍系数扫描模式的初始化。直接给出代码及相应的注释： // scanning order tableUInt* g_auiSigLastScan[ 3 ][ MAX_CU_DEPTH ]; //!< [pattern][depth]const UInt g_sigLastScan8x8[ 3 ][ 4 ] ={ {0, 2, 1, 3}, //!< rig

本文考察实现去方块滤波的核心函数xDeblockCU：Void TComLoopFilter::xDeblockCU( TComDataCU* pcCU, UInt uiAbsZorderIdx, UInt uiDepth, Int Edge ){ if(pcCU->getPic()==0||pcCU->getPartitionSize(uiAbsZorderIdx)==SIZE_N

先看HM中定义tC、β这两个变量的表格，与draft中的Table 8-10相对应：const UChar tctable_8x8[54] ={ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,5,5,6,6,7,8,9,10,11,13,14,16,18,20,22,24};

其实HM的运动估计这部分与H.264相比基本没有变化，如果看过JMVC运动估计的代码，会发现xTZSearch的结构几乎就是一样的。所以，严格来讲，这部分的东西没有什么太多新鲜的东西，相信以前研究过TZSearch的人看这部分代码会很轻松。先看运动估计的主调函数：//!< 运动估计Void TEncSearch::xMotionEstimation( TComDataCU* pcCU, T

应该有不少人跟我一样，在刚开始时不知道到哪去下载HEVC的标准测试序列，之前曾经在百度检索过，查找到如下网址：ftp://ftp.tnt.uni-hannover.de/testsequences/账号为hvc，密码为US88Hula。 当时的这个网址的确是可以打开的，但是最近一阵子网页是打不开的，之后有人提醒我，网址现在为：ftp://hevc@ftp.tnt.uni-han

分析xTZSearch这个函数，xTZSearchHelp是当中最为重要的子函数之一。它实现最基本的功能：根据输入的搜索点坐标，参考图像首地址，原始图像首地址，以及当前PU大小等相关信息，计算出SAD，并与之前保存的最佳值进行比较，更新到目前为止的最佳值相关参数，如uiBestSad，搜索点坐标，搜索步长等。其他的函数如xTZ8PointSearch等搜索函数，最终都是调用xTZSearchHel

在刚开始看HM的时候，对着7个工程，可能有人会感到困惑，该从哪里看起呢？当然了，对于已经有一定代码量积累的人或者之前研究过H.264代码如JM的人来说，从何入手应该不成问题。但我写这篇出来，一方面是自己做个总结，备忘，另一方面也是希望能够帮助刚刚入手HM的朋友。好了，不多废话，还是进入正题吧。 对于一个完整的HM解决方案来说，总共包含了7个工程：1. TAppCommon 2. TAppD

有了前面几篇的铺垫，本文就可以把整像素部分的运动估计给结束掉了。到目前为止，只剩下xTZSearch这个函数没分析了，在开始这个函数的代码解释之前，让我们共同来理一下TZSearch的基本流程：1. 搜索预测得到的mv所指向的点：中值预测mv，当前PU的左，上及右上PU的mv，还有零运动矢量（0,0）2. 在步骤1中找到匹配误差最小的点作为接下来搜索的起始点3. 步长从1开始，以2的指

上次留下两个帧内预测中最为重要的两个函数xPredIntraPlanar和xPredIntraAng，本文先介绍第一个函数。先看代码及相应的注释：/** Function for deriving planar intra prediction. * \param pSrc pointer to reconstructed sample array * \param srcStride

继续分析第一篇提到的compressSlice中对LCU的RC参数初始化：#if RATE_CONTROL_LAMBDA_DOMAIN Double oldLambda = m_pcRdCost->getLambda(); if ( m_pcCfg->getUseRateCtrl() ) { Int estQP = pc

续上文继续分析m_pcRateCtrl->initRCPic( )Void TEncRateCtrl::initRCPic( Int frameLevel ){ m_encRCPic = new TEncRCPic; m_encRCPic->create( m_encRCSeq, m_encRCGOP, frameLevel, m_listRCPictures );}

上一篇文章主要讨论了RC的总体框架，本文开始分析具体的代码实现细节。分析的顺序按照总体框架来，即初始化-->更新。 （1）m_cRateCtrl.init()#if M0036_RC_IMPROVEMENTVoid TEncRateCtrl::init( Int totalFrames, Int targetBitrate, Int frameRate, Int GOPSize,

HM的码率控制提案主要参考如下三篇：K0103，M0036，M0257。本文及后续文章将基于HM12.0进行讨论，且首先仅讨论K0103对应的代码，之后再陆续补充M0036，M0257对应的代码分析，这么做可能会使得剧情不会显得那么地跳跃，分析起来能够更好地被接受。 按照我的个人习惯，还是先分析HM中码率控制部分（以后简称RC）的总体框架吧。跟RC有关的头文件和源文件为工程TLibEn

今天主要介绍帧内预测一个很重要的函数initAdiPattern，它的主要功能有三个，（1）检测当前PU的相邻样点包括左上、上、右上、左、左下邻域样点值的可用性，或者说检查这些点是否存在；（2）参考样点的替换过程，主要实现的是JCTVC-J1003即draft 8.4.4.2.2的内容，主要由函数fillReferenceSamples来完成，这个在之前的文章已经讨论过了；（3）相邻样点即参考样点

有时候我们想禁用掉HM的去方块滤波，测试下去方块滤波的效果，很容易就想到要修改配置文件，根据注释，容易找到：       LoopFilterDisable             : 1           # Disable deblocking filter (0=Filter, 1=No Filter)       但是运行完程序后就会发现，这个参数改为0或者改为1结果根本就是一样

相信只要是做算法改进的，首先都会遇到这么一个问题：CU，PU及TU这几个在HM中该如何打印出它们最终的划分情况呢？也经常有人来问我这个问题，一般来说，因为问我的时候我一般手头都没有现成的代码可以提供，另一方面，也没空把vs打开写上一段，所以只能是告诉他们大概的思路，其实我很早之前的一篇博客已经进行了介绍，只是当时没有把代码附上，后来也找不到了，就不了了之了。本文算是把这个遗憾给补上吧。直接附上代码

本文以下部分为翻译(1)   编码树单元（CTU）和编码树块（CTB）结构：在之前的标准中，编码层的核心是宏块，一个宏块包含一个16×16的亮度块，以及对于常用的4:2:0采样格式来说还包含两个8×8的色度块；而在HEVC中类似的结构为编码树单元（CTU），其尺寸由编码器进行指定且可以比传统的宏块大。一个CTU包含一个亮度CTB和两个对应的色度CTB及句法元素。一个L×L的亮度CTB的L可

本文分析xTZSearch调用了两个最为主要的函数：xTZ8PointDiamondSearch和xTZ2PointSearch，值得一提的是，HM中还提供了另外一个搜索函数xTZ8PointSquareSearch，但由于实际并没有使用这个函数，且它其实跟钻石搜索只是搜索点的选择略有不同，分析起来基本上也是一样的，这里就不重复啰嗦了。__inline Void TEncSearch::xTZ

本文介绍关于去方块滤波的最后一个函数（这一系列基本上只讨论了亮度分量的情况，色度分量的情况类似，不单独做出分析）。Void TComLoopFilter::xEdgeFilterLuma( TComDataCU* pcCU, UInt uiAbsZorderIdx, UInt uiDepth, Int iDir, Int iEdge ){ TComPicYuv* pcPicYuvR

本文考察Boundary Strength (BS)的获取过程：Void TComLoopFilter::xGetBoundaryStrengthSingle ( TComDataCU* pcCU, UInt uiAbsZorderIdx, Int iDir, UInt uiAbsPartIdx ){ TComSlice* const pcSlice = pcCU->getSlice

去方块滤波的详细过程可参看draft 8.7.1 to 8.7.2 。     在compressGOP中可以找到下面一段代码，这里就是调用去方块滤波的地方 //-- Loop filter Bool bLFCrossTileBoundary = pcSlice->getPPS()->getLoopFilterAcrossTilesEnabledFlag();

关于SAO的原理和流程的解析，已经在我转载的一篇博客HEVC中SAO--自适应样点补偿 详细分析解读有了比较清楚的介绍了，本文就不再重复这个过程，而把主要精力放在具体函数实现的解析上。在我自己的一篇博客HEVC学习（八） —— 以SAO为例浅析跟踪代码方法里其实也作了相关的铺垫了，当中重点放在跟踪代码的方法上，本文在此基础上对重要的函数进行解析，它们的调用位置这里就不提了，有关这部分的内容请参

Void TEncSampleAdaptiveOffset::saoComponentParamDist(Int allowMergeLeft, Int allowMergeUp, SAOParam *saoParam, Int addr, Int addrUp, Int addrLeft, Int yCbCr, Double lambda, SaoLcuParam *compSaoParam,

/** rate distortion optimization of all SAO units * \param saoParam SAO parameters * \param lambda * \param lambdaChroma */#if SAO_ENCODING_CHOICEVoid TEncSampleAdaptiveOffset::rdoSaoUnit

HM的代码跟踪其实在我转载的一篇博客HEVC/H.265参考代码跟踪里就已经有很不错的介绍了，因此，我就不重复里面所说的了，而是对里面一些我觉得需要稍微补充下并且以另一个具体实例SAO即Sample Adaptive Offset的跟踪过程进行说明。由于只是一个跟踪说明，代码的具体细节就不去探究了，其实这也是一个方法，有些时候，你仅仅需要知道实现某个功能的代码在哪，而不需要知道它的实现细节，那

原文地址：http://blog.youkuaiyun.com/feixiang_john/article/details/8258452HEVC中SAO--自适应样点补偿:  本文分三个部分, 1.Sample Adaptive Offset原理, 2.SAO处理流程分析, 3.SAO意义何在!a)  SAO原理:    SAO是在DB之后进行, 输入是重建帧和原始帧数据, 输出是SAO数据

相信会有不少人对如何确定CU最终的划分有所困惑（包括我在内，刚开始接触时也不知道该怎么做），我觉得很大的一个原因就是CU是递归划分的，这就导致在寻找确定最佳分割位置时比较困难。 其实，解决问题的办法说难也不难，关键在于思路的转换，既然对于xCompressCU中是如何保存划分模式的觉得难以理解，何不跳出这个小圈子寻找新的方法呢？ 我们可以从解码器的角度来考虑，因为最终编码后的码流是

从今天开始，会陆续发表HEVC学习过程中的一些总结，主要目的是与大家一起交流学习，由于水平有限，恳请大家能够不吝赐教。 由于这是第一次写博客，而且学习也是个循序渐进的过程，第一篇文章就简单介绍下如何使用HEVC的官方标准测试模型HM吧。其实如果之前学习过H.264的话，肯定也是用过JM的，HM的使用方法与JM基本上是相同的，只是配置文件的内容有所不同罢了。好了，不多说，马上进入正题。

这篇博客写得不错，觉得对我对大家刚开始学习时会有帮助，于是转载之。原文地址：http://blog.youkuaiyun.com/feixiang_john/article/details/7876227#comments 1.编码器程序从"TAppEncoder"工程中的encmain.cpp文件开始的，此文件中包含程序运行的入口函数"main"，在main函数中主要做了编码器对象的创建、分析配置文

这个可以算是帧内预测中最为核心的一个部分了，不过相信有了前面那些基础积淀，这个部分看起来反而没有原来那么难了。下面直接给出代码及其相关注释：// Function for deriving the angular Intra predictions/** Function for deriving the simplified angular intra predictions.