The relationship between Cu,tu,pu in hevc-i frames

Here is mainly combined with HEVC decoding end I frame to explain, wherein the p,b frame is basically not too large, mainly PU also exist irregular situation on p frame is not sure

After a clear analysis, then add

The relevant concepts of the coding tree structure are mentioned in the previous blog post, which is explained in detail in the code.

In the intra- frame mode :

35 The prediction mode is defined on the basis of Pu, but in the specific frame prediction process is in TU units, the standard stipulates that PU can be divided into the form of quadtree, and the same pu within the TU share a predictive model

in the actual predictions, each Tu himself predicts its own, referencing itself to the surrounding pixel points

So, Pu is just the way to define predictions, and the real and predictive pixels and refactoring processes are processed through TU.

The following is the entropy decoding to read out some of the data recorded clues:

PCu represents a structure that is a CTU counterpart.

Uiabspartidx represents the position of the current CU in CTU, in the minimum Tu in the configuration document

The last parameter indicates how many Tu are in the current CU or Pu

< record depth information in the process of recursively entering CU from CTU

memset (pcu->ppuhdepth + uiabspartidx, Uidepth+splitflag, uicurnumparts);

< record current CU prediction portion of Pu is n*n,or2n*2n, while recording current CU width,height

memset (pcu->ppepartsize+uiabspartidx,partsize,uicurnumparts);

memset (pcu->ppuhwidth+uiabspartidx,psps->uimaxcuwidth>>uidepth,uicurnumparts);

memset (pcu->ppuhheight+uiabspartidx,psps->uimaxcuheight>>uidepth,uicurnumparts);

< write prediction mode, within or between frames

memset (pcu->ppepredmode+uiabspartidx,mode_intra,uicurnumparts); (currently in the write frame)

< mode write brightness for Pu, direction of chroma prediction Section

memset (pcu->ppuhintradir[CHANNEL_TYPE_LUMA]+uiabspartidx+i*partoffset, Intrapredmode,uicurnumparts);

I mean if I split it, I write it four times.

memset (pcu->ppuhintradir[CHANNEL_TYPE_CHROMA]+uiabspartidx,symbol, Uicurnumparts);

< from the CU to the root node into the Tu, recursive to obtain the last minimum Tu for the decoding of the residual coefficient. Intra-frame and Pu-related is: if the intra-frame mode, while Pu split, then tu need to split

< in each recursive process, the value of CBF

memset (pcu->ppuhcbf[compid]+uiabspartidx,uicbf,pimg->numpartitionsinctu>> (uiDepthAdj< <1));

<tu the depth of the current Tu relative to CU when recursive to the minimum

memset (pcu->ppuhtridx + uiabspartidx,uitrdepth,uicurnumparts);

< residual coefficient in each tu

stored in:

Pcoeff = pcu->Ptrcoeff[compid]+ptu->offsets[compid];

Offsets represents the offset position of the current TU in CTU, obtained by recursion

Note: Each split to the minimum decoding TU does not mean that the current TU is necessarily the smallest tu in the configuration information, which is determined at the coding end

After obtaining the corresponding information, the operation is decoded by CTU.

The first is to enter

M_PCCUDECODER->DECOMPRESSCTU (PCTU); Function

After entering the recursive process, and reading the data when the process is the same, get the smallest CU after decoding:

<span style= "FONT-SIZE:18PX;" > Case Mode_intra:
      xreconintraqt (m_ppccu[uidepth], uidepth),//< start in-frame prediction </span>

The CU is then divided into corresponding PU according to the Partsize

Tcomturecurse <span style= "color: #ff0000;" ><strong>tuRecurseCU</strong></span> (PcCU, 0);
    Tcomturecurse Turecursewithpu (Turecursecu, False, (uiinittrdepth==0)? TCOMTU::D ont_split:tcomtu::quad_split);

    Do
    {
      xintrarecqt (m_ppcyuvreco[uidepth], m_ppcyuvreco[uidepth], m_ppcyuvresi[uidepth], Chantype, TURECURSEWITHPU);
    } while (Turecursewithpu.nextsection (TURECURSECU));

Because although it is now the PU to obtain the prediction mode, but finally still through tu to decode, so here still uses TU's storage structure

The process of PU starting to solve Tu is entered in the while loop.

Void tdeccu::<strong><span style= "color: #ff0000;"
                    >xIntraRecQT</span></strong> (tcomyuv* pcrecoyuv, tcomyuv* PCPREDYUV,
  tcomyuv* PCRESIYUV, const channeltype chtype, Tcomtu &rtu) {
  UInt uitrdepth = Rtu.gettransformdepthrel ();
  Tcomdatacu *PCCU = Rtu.getcu ();
  UInt uiabspartidx = Rtu.getabspartidxtu ();
  UInt Uitrmode = Pccu->gettransformidx (UIABSPARTIDX);  if (Uitrmode = = uitrdepth) {if (Isluma (chtype)) xintrarecblk (PCRECOYUV, PCPREDYUV, PCRESIYUV, Component_y,
    RTU);
      else {const UINT numvalidcomp=getnumbervalidcomponents (Rtu.getchromaformat ()); for (UInt COMPID=COMPONENT_CB; compid<numvalidcomp; compid++) {xintrarecblk (PCRECOYUV, PCPREDYUV, PcResi
      Yuv, ComponentID (compid), rTu);
    }}}} else {Tcomturecurse turecursechild (RTu, false); do {xintrarecqt (PCRECOYUV, pCPREDYUV, PCRESIYUV, Chtype, Turecursechild);
  } while (Turecursechild.nextsection (rTu)); }
}

It can be seen from this function that a recursive operation that corresponds to a read parameter is performed after a pu enters tu.

The process of data reconciliation from reading data can be seen.

Cu,tu,pu can be said to be independent of each other because they are responsible for part of the module

But there is a certain connection, in terms of intra-frame prediction:

The root node is all CU, encoding process is cu->pu,cu->tu, in the case of intra-frame mode if PU is N*n, then Cu->tu is bound to split one time

decoding process, first determine the frame of the situation, so according to PU first determine whether the CU split once, and then based on the depth of information to get TU

For inter-frame situations, then supplement