Distribution of TU sizes over the I frame in X265 code

Issue #306 new
Amine Chaabouni created an issue

I am a phd student from Lorraine university and I am working in HEVC encoding standard using your solution x265 to analyze and encode full HD medical videos.

I need to know the histogram of quantified DCT coefficient (m_trCoeff) after coding this type of medical video. So, can you help me in finding the distribution of TU sizes over the I frame in X265 code. In which class and function can I find this information? Until now, I found the different CTU coefficient (ctu->m_trCoeff) after transformation and quantization in "encodeSlice()" of "frameencoder.cpp" and nothing about the distribution of TU sizes.

Thank you in advance! Amine Chaabouni

Comments (8)

  1. Ashok Kumar Mishra

    Hi Amine,

    TU size is decided in class Search. For intra frame, function Search::IntraLumaQT() is called for luma and function Search::codeIntraChromaQt() for chroma. From both the functions, Quant::transformNxN() is called for DCT. Then based on the RDO cost, TU size will be decided(size may vary from 4x4 to 32x32 in HEVC). In HEVC, one frame will be divided into CTUs, then each CTU will be divided into CUs, each CU will be divided into PUs, each PU will divided into TUs. After transform of a TU block, we encode it to find the number of bits to calculate the RDO cost. Based on the RDO cost, TU size will be decided.

    Hope this clarifies your question. Please let us know if you need any further clarification.

  2. Ashok Kumar Mishra

    Hi Amine,

    In HEVC, TU partitions are decided independently from PUs. But by mistake I wrote each PU will be divided into TUs. Apologies for the mistake.

  3. Amine Chaabouni reporter

    Thank you Ashok for your answers. In fact, I remarked that Search::codeIntraLumaQT() is called by Search::estIntraPredQT, called by Search::checkIntra. The last function is used by analysis::compressIntraCU in which PU size will be decided. So I think that TU partitions depends from PU partitions. Correct me if I am wrong!!

    I did some simple encoding tests (encoding full HD video in 5mbits/s) and I noticed that the parameter "mightSplit", located in Search::codeIntraLumaQT(), is always "false", which means that there is no TU split and that TU partitions depends from PU partitions. What do you think about my analysis? Thank you in advance for your help!

  4. Amine Chaabouni reporter

    Hi Ashok,

    I didn't receive any answer from your side about my issue. Do you have any new idea about it? I am really blocked and I need help. Thank you in advance!

  5. Ashok Kumar Mishra

    Hi Amine,

    Sorry for the delay.

    In the case of Intra, the PU sizes supported are: 2Nx2N and NxN(special case when the CU size is 8x8), both are square blocks. In the case of Inter, the PU sizes supported are: 2Nx2N, 2NxN, Nx2N, 2NxnU, 2NxnD, and so on. It's a combination of square and nonsquare blocks. Here comes the scenario that TU partitions are independent of PU. In HEVC, TU size may vary from 4x4 to 32x32 square blocks.

    Again in case of Intra, for example if CU size is 32, PU size is also 32x32(for PU mode 2Nx2N). And the TU size may vary from one 32x32, or four 16x16,...so on. In Search::codeIntraLumaQT(), "mightSplit" is not always false. The function codeIntraLumaQT() is called twice from estIntraPredQT(). In the second function call, "mightSplit" will become true. Set "veryslow" preset in your command line and let me know if you need further help.

  6. Amine Chaabouni reporter

    Hi Ashok,

    Thank you again for your help! As I told you, I am working in Intra Luma case.

    It is true that "mightSplit" can be true in the second call by estIntraPredQT(). However, in this case, "depthRange[0]" (quadTreeTULog2MinSize) is equal to 5. So, in "codeIntraLumaQT", we split the CU one time in 4 parts and it is not the final TU partitions as I understood.

    In fact, as I told you last time, I remarked that Search::codeIntraLumaQT() is called by Search::estIntraPredQT, called by Search::checkIntra. The last function is used by analysis::compressIntraCU, in which we look for the best PU size using "checkBestMode()" function. So, in each time (a PU size), we call Search::checkIntra, then we call Search::estIntraPredQT, in which we look for the best prediction mode for this PU size using "COPY2_IF_LT()". Finally, for each PU mode, we look for the TU best mode.

    Unfortunately, I didn't find the last TU partition size after all these mode comparisons. I focused on the Search::codeIntraLumaQT() function, displaying the "cu.m_cuPelX" and "cu.m_cuPelY" values and I find always many calls from "analysis::compressIntraCU": For example: for a ParentCTU.m_cuPelX=0 and ParentCTU.m_cuPelY=0, we found m_cuPelX/m_cuPelY={0, 8 ,16, 32, 64}.

    Can you correct me if I misunderstood this coding operations? Do you have any other idea how to get the final TU partition for each CTU (64x64)? Is there any parameters indicating us this final TU partition?

    Thank you in advance for your support!

  7. Log in to comment