I am very new to the HM HEVC (and the JEM) reference software, and I am currently trying to understand the source code. I want to add some lines to display for each component: name of Algo (i.e. inter/intra Algos) + length of the bitstream+ position in output bin file.
To know which component cost more bits to code and how codec is working. I want to do same thing for the JEM also after that.
my problem first is that I am unable of understanding a lot of function there, the comment is not sufficient, so is there any references to understand the code??!! (I already read the Manuel ,doesn’t help).
2nd I don’t know where & how exactly to add these lines; is it in TEncGOP
, TEncSlice
or TEncCU
. Ps: I don’t think in TEncGOP.compressGOP
so maybe in the 2 other classes.

- 60
- 6
2 Answers
Point 1: There is one rule of tumb that logging coding decisions (e.g. pred mode, MV, IPM, block size) is much easier at the decoder side than encoder. This is because of the fact that you have super complicated RDO process at the encoder side that can easily make you get lost in the loops. But at the decoder side, everything appears only once. However, if you insist on doing it at the encoder side, you may find some tips here: Get some information from HEVC reference software
Point 2: Unlike coding decisions, logging rate (i.e. number of written bits for different syntax elements) is more complicated at the decoder side than encoder. This is particularly true for fractional bits associated to anything that is encoded in non-EP mode (i.e. with CABAC contexts). So you may do this part at the ecoder side. But I am afraid it is not easy.
Point 3: I think the best way to understand the code is to read it line-by-line. It's very time-consuming but if you theoritically know the standard(s), you will probably be able to distiguish important parts and ignore the rest.
PS: I think there are too many questions, mostly too general, in your post. It makes it a bit difficult for me to answer them all together. So you I'll wait for you to take your next step and ask more precise questions.

- 403
- 2
- 7
-
1Thanks @Mohsen , actually I saw your comments in the last question and it was my start point , very very helpful. so I think after having a quick surface look on the code I will go line by line now and try to ignore the less important parts , hope doing this for HM will save some time for the JEM so my question now can I get the exact number of bins for a tool just after making the last best decision of RDO and is it in the `xEncodeCU` or `xCompressCU` ? and the position where it will be written in the bin file? . – Mourad Jun 12 '18 at 11:55
-
See my next comment. – Mosen Jun 12 '18 at 15:44
(I put the answer to comment that @Mourad put four hours ago here, becuase it will be long)
I assume that you could manage to find where the actual encoding after the RDO loop is implemented. As you correctly mentioned, xEncodeCU
is the function you need to refer to make sure you are not still in the RDO.
Now you need to find the exact function in xEncodeCU
that is responsible for your target codec tool.
For instance, if you want to count the number of bits for coefficient coding, you should be looking into the m_pcEntropyCoder->encodeCoeff()
(It's a JEM function and may have different name in the HM). Once you find this line in the xEncodeCU
, you may do this and get the number of bits written inside encodeCoeff()
function:
UInt b_before = m_pcEntropyCoder->getNumberOfWrittenBits();
m_pcEntropyCoder->encodeCoeff( ... );
UInt b_after = m_pcEntropyCoder->getNumberOfWrittenBits();
UInt writtenBitsCoeff = b_after - b_before;
One important point: as you cas see, the function getNumberOfWrittenBits()
gives you integer rates, which is obtained by rounding sum of fractional rates corresponding to all syntax elements coded inside the function encodeCoeff
. This error might or might not be acceptable, depending on your problem. For example, if instead of coefficient coding rate, you wanted to know the rate of CBF
, then this error would not be acceptable at all. Because, CBF
rate is mostly less than one bit. If this is your case, then you would need to calculate the fractional bits one-by-one. It would be totally different and relatively more complicated than this.

- 403
- 2
- 7
-
1thank you so much , i will try to do what you explained and i will return for new question if i get stuck somewhere. – Mourad Jun 13 '18 at 14:02
-
1hi; I am back again . do you mean by CBF "coded block flag" ? do all flags and indxs coded with less than 1 bit ? because yes i displayed some flags ( in int format ) and they are all 0 ! e.g. prediction mod is always 0 in I and B slices which is not supposed to. – Mourad Jun 21 '18 at 14:37
-
1Not all bins and flags are coded with a fractional rate. For instance, each coefficient sign is bypassed and therefore, has an integer rate of 1. Even for the rest (compressed bins), the fractional rate can be more than 1.0, depending on their CABAC context probabilities. – Mosen Jun 22 '18 at 07:37
-
1In two occasions, you can get the rate of zero for prediction mode: 1) In a B slice, when the predMode is inter: because it has a very low rate so after rounding you get zero. 2) In an I slice, we don't actually encode the predMode flag, because we are not allowed to have any mode other than intra. So you rate is zero because nothing is written. – Mosen Jun 22 '18 at 07:42