JVET-Q0471: chroma QT split based on block height

JVET-Q0471 chroma QT split based on block height

Isn't minQtSize in units of luma samples, and areaC.height will be in units of chroma samples? Comparing these two doesn't seem to match the draft text, or am I missing something?

Maybe you want to use something like ( area.height <= ( (minQtSize * subHeightC) / subWidthC ) )?

Currently in software, minQtSize is in chroma sample when for chroma tree to avoid frequent conversion. I think it would be fine as long as the comparison is with the same unit. But yes, it is confusing and is easy to have bugs. Brian's suggestion looks better.

As far as I can tell, in the current software, it seems minQtSize is in luma sample units (at least in the decoder). Once !1259 (merged) is merged, that might change (I haven't studied that MR in detail). Maybe this MR is dependent on !1259 (merged) changes? Anyway, as long as it's kept straight that's fine.

According to the configuration files currently used in VTM, as copied below, the minQT for chroma appears to be in chroma samples. To be consistent with the current settings, we also used the unit of chroma samples in our implementation. MinQTLumaISlice : 8 MinQTChromaISlice : 4 MinQTNonISlice : 8

The setting of minQT was initially adopted in JVET-C0024 for JEM. The setting is inherited by VTM. In JVET-C0024, it said "For chroma components in I slice, the MinQTSize equal to 4x4 means 4x4 luma samples, i.e., 2x2 chroma samples in 4:2:0 chroma format." So I think the minQtSize (MinQTLumaISlice, MinQTChromaISlice, and MinQTNonISlice) are all in luma sample units. The MinQTChromaISlice set equal to 4 is because we want support 2x2 chroma partition in chroma-tree in early version of JEM.

Also, in VTM-7, the value of MAX_TT_SIZE_C and MAX_BT_SIZE_C are also in luma sample units. All these variables are in luma sample units.

So, in current SW, it uses "if( area.width <= minQtSize ) canQt = false;" to check the availability of QT-split. The area.width is the corresponding luma sample width. I think the current SW doesn't need to be modified.

Thanks Peter for your comment and the information! I've checked the document and software and it was confirmed that the MinQTChromaISlice was set in luma samples in JEM. But as there were some offline discussion with the software coordinators on this issue and the suggestion was to use the setting of MinQTChromaISlice in chroma samples, I would like to double check with the software coordinators to finalize the decision. We are fine with either way, as long as the definition is made clear to avoid confusions.

@ksuehring @bossen @XiangLi, regarding Peter's comment and the history of the settings, could you please help make some recommendations about the following items?

1. What unit shall we use for MinQTChromaISlice? To use Luma samples following the initial JEM setting or to use chroma samples as previously discussed?
2. If the decision is to use unit in luma samples, the configuration file seems incorrect, shall we update the configuration file to make the default setting of MinQTChromaISlice to be 8 in luma samples?

Thank you!

As I stated previously, chroma units would in my opinion make more sense in the config file, since it would avoid having to keep track of anther parameter when changing the chroma format. It seems to make sense, to have the same minimum block size in chroma samples rather than luma samples when switching for instance from 4:2:0 to 4:4:4.

The software can obviously easily covert units after reading the parameter file. But we should make sure, that the setting is used consistently and correctly in the software and also works for non-4:2:0 cases.

Thanks for your comment, Karsten. As currently the software we provide is using chroma units, and comments are added in the configuration files to clarify the unit for this setting (please see merge request 1259 !1259 (merged)), we will keep the code as is for now.

I think it's fine to use chroma units in config file as long as it's well defined/specified in the config file and the corresponding modifications are correct. But if we define the MinQTChromaISlice in config file in chroma units, we need to specify the MinQTChromaISlice means chroma CB width or chroma CB height, especially for 422 format. In the merge request of Q0469, the config file said "MinQTChromaISlice : 4 # minimum QT size in chroma samples for chroma separate tree". It doesn't specify it's in chroma CB width or chroma CB height.

In the spec text, section 7.4.11.4 Coding tree semantics, the coding block size is defined as coding block width:

– The allowed quad split process as specified in clause 6.4.1 is invoked with the coding block size cbSize set equal to cbWidth, ...

And how the min QT size is used in comparisons are also defined in 6.4 Availability processes, so i believe it's sufficient for the purpose.

So you mean the MinQTChromaISlice defined in config file is for chroma CB width in chroma unit? Suggest to specify this in the comment of the config file. For example, "MinQTChromaISlice : 4 # minimum QT size for chroma CB width in chroma samples for chroma separate tree". Because someone may not know he/she needs to find the spec text to find out it's for chroma CB width or chroma CB height. Also, even he/she found that in the spec, spec specifies MinQtSizeC in luma samlpe, not in chroma sample as in config file.

One question, for chroma separate tree in 422 format, if I want to stop QT-split when the chroma CB size is equal to 8x16 (width is equal to 8, height is equal to 16, both in chroma sample), which value I should use for MinQTChromaISlice in config file? 8 or 16?

That suggested cfg file comment sounds also like an appropriate description for the software manual.

Hi, Peter and Karsten,

I'm copying the related lines of spec text below for this discussion. The following one is for the cbSize definition, which is in luma width.

– The allowed quad split process as specified in clause 6.4.1 is invoked with the coding block size cbSize set equal to cbWidth, ... Following is the equation used in the comparison on chroma minQT: – treeType is equal to DUAL_TREE_CHROMA and cbSize is less than or equal to ( MinQtSizeC * SubHeightC / SubWidthC )

As described in the spec, following equation is used to check cbSize against MinQTSizeC, both in luma samples:

cbSize <= ( MinQtSizeC * SubHeightC / SubWidthC ) (1)

It can be converted into the following form:

(cbSize / SubHeightC) <= (MinQtSizeC / SubWidthC) (2)

Which is equivalent to:

cbHeightChroma <= MinQTSizeC_in_Chroma_width (3)

As stated in the meeting notes, this is a straight forward way of addressing the issue on non-square chroma block shape to check the threshold value with the consideration of current chroma CB height to allow one extra level of split.

We can get the desired threshold value from the equation, in order to get chroma CB 8x16 in 4:2:2 case, MinQTSizeC in Chroma shall be set to 16 according to the equations above.

Our implementation is using the simplified equivalent equation (3). If that doesn't seem clear, I will add some comments to clarify, or to implement it in the way of equation (1) to better align with the spec. I'll also add comments to configuration file and the software manual to clarify.

Thanks for the explanation. The equation (3) is equivalent to equation (1). Either way is fine.

However, I have one further question. From the example of chroma CB 8x16 in 4:2:2 case, it seems that you will specify the value equal to 16 for MinQTChromaISlice in config file. If my understanding is correct, the MinQTSizeC_in_Chroma_width in equation (3) is equal to the MinQTChromaISlice (correct me if I'm wrong). The value of MinQTSizeC_in_Chroma_width is equal to 16.

But from the naming of this variation, MinQTSizeC_in_Chroma_width seems to specify the value of chroma CB width, which should be 8 (for the case of 8x16 chroma CB). It seems that it has logical contradiction.

Since the cbSize was defined as luma width of a CB, we assumed all the settings were in block width. That's why we chose to use width for the setting. And the purpose of this change was to allow chroma block in 4:2:2 format to have one more level of QT split when using the same setting as in 4:2:0 format. So the smallest QT block width will be half, and the height would be equal to the setting. This is most straight forward way of aligning the setting with the spec. We will provide information in comment and software manual about how to set the value.

So you mean, since in the 422 format, the QT split allows one more level split than 420 and 444, if I want to the stop QT-split when the chroma CB size is equal to 8x16 in 422 format, I need to set the chroma CB size equal to 16x32 as the minQT size for chroma tree (so we set the value of 16 for MinQTChromaISlice). And the spec/SW will automatically allow one more level split to stop the QT split when the chroma CB size is equal to 8x16? Am I correct?

Why not just always use the actual chroma CB width as MinQTChromaISlice? If you want one more level split in 422 format, you just set a smaller value for MinQTChromaISlice. For example, in 422 format, if you want to stop QT split at 8x16 chroma CB, you just set the MinQTChromaISlice as 8 (for 8x16 CB), not 16 (for 16x32 CB with one more level split to be as 8x16 CB).

Hi, Peter, thanks for your comment and your point is well understood. But since the current spec text had an assumption that the setting of Intra Chroma minQT shall be in terms of width, and the comparison was taking chroma block hight into consideration, the current implementation is the best way to match with the spec. I would agree that there may be other better ways of setting the configuration, but if that would require some changes on the spec, we may have to bring it to the next meeting.

changed this line in version 5 of the diff

Updated the code to reflect the changes in the bug fix MR !1361 (merged) where onfiguration of MinQTChromaISlice is set in chroma sample unit, and converted in luma samples when applied in software. The software manual is also updated for this configuration.

changed title from JVET-Q0471 chroma QT split based on block height to JVET-Q0471: chroma QT split based on block height

added 79 commits

• 5b1888af...2b6a7e1a - 77 commits from branch jvet:master
• e12c3731 - JVET-Q0471 chroma QT split based on block height
• 1079790a - Merge branch 'Q0471-chroma-qt-split' of...

Compare with previous version

Only info

#if JVET_Q0471_CHROMA_QT_SPLIT_ON_HEIGHT
#if JVET_Q0438_MONOCHROME_BUGFIXES
  SizeType side = (chType == CHANNEL_TYPE_CHROMA) ? areaC->height : area.height;
#else
  SizeType side = (chType == CHANNEL_TYPE_CHROMA) ? areaC.height : area.height;
#endif
  if (side <= minQtSize)                                     canQt = false;
#else

Hi, Jamaika, thank you for the suggestion. I've added the change in this merge request.

added 64 commits

• 1079790a...8767517b - 63 commits from branch jvet:master
• f93e2a2e - Merge branch 'master' into 'Q0471-chroma-qt-split'

Compare with previous version

added 1 commit

• 2a6e8ab8 - Add harmonization with JVET-Q0438 MONOCHROME BUGFIXES

Compare with previous version

added 189 commits

• 2a6e8ab8...14842c68 - 185 commits from branch jvet:master
• 2182553d - JVET-Q0471 chroma QT split based on block height
• 4874f30f - Add harmonization with JVET-Q0438 MONOCHROME BUGFIXES
• f7f7a601 - In MR 1361, intra chroma minQT size are configured in chroma samples and...
• 06be3183 - Merge branch 'Q0471-chroma-qt-split' of...

Compare with previous version

added 26 commits

• 06be3183...24bac0b1 - 25 commits from branch jvet:master
• 68bc84b7 - Merge branch 'master' into 'Q0471-chroma-qt-split'

Compare with previous version

added 56 commits

• 68bc84b7...d43302e1 - 52 commits from branch jvet:master
• b956530a - JVET-Q0471 chroma QT split based on block height
• 86c39e94 - Add harmonization with JVET-Q0438 MONOCHROME BUGFIXES
• e93836c9 - In MR 1361, intra chroma minQT size are configured in chroma samples and...
• 9b667ee2 - Merge branch 'Q0471-chroma-qt-split' of...

Compare with previous version

merged

mentioned in commit d2083653