Encoder crash when setting MinQTChromaISlice larger or equal to 32

[hanhuang]

Encoder crash when setting MinQTChromaISlice larger or equal to 32. It's due to coding a negative value in xWriteUvlc(). It seems the problem is caused by the following code:
#if JVET_Q0468_Q0469_MIN_LUMA_CB_AND_MIN_QT_FIX

convert the Intra Chroma minQT setting from chroma unit to luma unit
m_uiMinQT[2] <<= getChannelTypeScaleX(CHANNEL_TYPE_CHROMA, m_chromaFormatIDC);

#endif

The min QT size for Chroma tree is scaled according to chroma format, but the maximum BT size and maximum TT size are not scaled. Therefore, the value of sps_log2_diff_max_tt_min_qt_intra_slice_luma/pic_log2_diff_max_tt_min_qt_intra_slice_chroma can be negative if maxTT size is default 32.

Coding of syntax elements relate to chroma tree sizes are in luma sample units, but the encoder configures are in chroma sample unit? or sometimes in chroma sample unit sometimes in luma sample units?

[guichunli]

Hi, Han,

Yes, the encoder configuration for intra chroma min QT size (MinQTChromaISlice) is set in Chroma samples. So in 4:2:0 case, setting it to larger than 32 is not valid according to current spec.
I'll prepare a merge request to add related encoder parameter checking to ensure the value are in valid range, and the max BT/TT size and min QT size are valid combinations.

[hanhuang]

Hi Guichun.
I think the problem is the inconsistency between min QT size and max BT and TT sizes. One is scaled according to color format, the others are not. Otherwise, it's weird that one configure is in chroma unit and the others are in luma unit. Right?

Replying to guichunli:

Hi, Han,

Yes, the encoder configuration for intra chroma min QT size (MinQTChromaISlice) is set in Chroma samples. So in 4:2:0 case, setting it to larger than 32 is not valid according to current spec.
I'll prepare a merge request to add related encoder parameter checking to ensure the value are in valid range, and the max BT/TT size and min QT size are valid combinations.

[guichunli]

Hi, Han,

There was initially some discussions about whether to use chroma unit or luma unit in software configurations for intra chroma min QT size, and it was agreed to use chroma samples. Unfortunately now there's some inconsistency between this and the way JVET-Q0330 is setting chroma BT/TT size configurations.

To align the settings internally, a change is submitted in the following merge request to add/fix encoder parameter validations related to MinQTChromaISlice.
​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1435

Could you please help check whether this change help resolve the issue? Thanks!

[hanhuang]

Dear software coordinators, Guichun and proponents of JVET-Q0330,

Could you agree on aconsistent configure setting regarding those sizes and make changes to current VTM? Guichun's solution of simply checking input configure but leaves the inconsistency unchanged is not best.

Thank you!

[rlliao]

Hi Han and Guichunli,

I would like to clarify that Q0330 does not change any size configurations. In VTM-7.0, the max chroma BT/TT sizes are set in luma samples. So Q0330 just follows the same rule.
If we decide to config the max chroma BT/TT sizes in chroma samples, should these two values set according to the height of max chroma BT/TT size in 422 color format?

Replying to hanhuang:

Dear software coordinators, Guichun and proponents of JVET-Q0330,

Could you agree on aconsistent configure setting regarding those sizes and make changes to current VTM? Guichun's solution of simply checking input configure but leaves the inconsistency unchanged is not best.

Thank you!

[hanhuang]

Hi Ru-Ling,

Personally I prefer keeping the same convention as in previous VTMs, as the draft spec. also uses luma samples in comparison between sizes. But I didn't involved in the discussion that Guichun mentioned and I think this is up to the S/W coordinators discretion as long as it's consistent.

Replying to rlliao:

Hi Han and Guichunli,

I would like to clarify that Q0330 does not change any size configurations. In VTM-7.0, the max chroma BT/TT sizes are set in luma samples. So Q0330 just follows the same rule.
If we decide to config the max chroma BT/TT sizes in chroma samples, should these two values set according to the height of max chroma BT/TT size in 422 color format?

Replying to hanhuang:

Dear software coordinators, Guichun and proponents of JVET-Q0330,

Could you agree on aconsistent configure setting regarding those sizes and make changes to current VTM? Guichun's solution of simply checking input configure but leaves the inconsistency unchanged is not best.

Thank you!

[ksuehring]

I was involved into the discussion whether parameters should use luma or chroma sample size.

I was trying to look at the problem from a users perspective. My general idea for the configuration options is that the user should not have to know the exact syntax if the bitstream to be able to understand the software settings. We should assist the user to select the options that make sense for the desired encoding. Then the encoder can translate these settings to proper bitstream syntax.

In the case of minimum block sizes, I asked whether the minimum block size is something, that we would expect to change, when the encoder operates in a different chroma format and I was told that this wouldn't be the case.

So when switching a configuration from e.g. 4:2:0 to 4:4:4 with luma block size specified, the chroma block size would be different. This felt like it would be unexpected for a user, because they would have to switch multiple parameters when changing the chroma format, which may not be easy to understand. So I suggested using chroma samples as unit.

I agree that it may be hard to understand the meaning of parameters, when they have similar names, but different units, e.g. max and min partition size.

So I see two possible solutions:

1) use the same unit everywhere
2) if different units make sense, add the unit to the parameter name, e.g. xxxBlockSizeInChromaSamples.

I don't have a strong preference for either of the options. From the discussion above it just seemed useful to use chroma sample units in some cases.

[guichunli]

Hi, Karsten,

Thanks for your comments and suggestions.
I still agree with you that using chroma sample unit is more convenient for users as they don't need to change this setting when chroma format is changed.
I've taken your suggestion 2) and updated the merge request with the encoder parameter name changed from MinQTChromaISlice to MinQTChromaISliceInChromaSamples, and also updated the software manual.
But as stated in our initial discussion, we are OK with either way. Please let us know if there's any one suggests otherwise. Thank you!

[fbossen]

​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1435