According to H0326/H0475 adopted in San Jose meeting, the last two bins for intra_chroma_pred_mode are bypass coded. For clearer description, it might be better to insert a comment such as '(uses Decode Bypass)' in Table 9-39 for intra_chroma_pred_mode with binIdx 2,3 and 4 when chroma_pred_from_luma_enable_flag==true and with binIdx 1, 2,3 and 4 when chroma_pred_from_luma_enable_flag==false.

Replying to Smarter:

TDecSbac::parseIntraDirLumaAng implements the binarization process for intra_chroma_pred_mode. Xhen decoding the last two bits, bypass decoding is used but the spec makes no mention of this. Since maxBinIdxCtx is 2 for intra_chroma_pred_mode, they should both be decoded using "m_pcTDecBinIf->decodeBin( uiSymbol, m_cCUChromaPredSCModel.get( 0, 0, 2 ) );" (with the same changes on the encoder side) instead.

I confirm that the spec is not clear on that:

When you look at the binarization you will see that there are two cases that can be divided into two known binarization schemes: TU and FL

1. chroma_pred_from_luma_enabled_flag = 1

Prefix: TU cMax = 2
Suffix: FL, cMax = 2 -> Bypass coded

2. chroma_pred_from_luma_enabled_flag = 0

Prefix: TU, cMax = 1
Suffix: FL, cMax = 2 -> Bypass coded

The tricky thing is that the mapping between bin string and value of intra_chroma_pred_mode is NOT:

highest value-> longest bin string and lowest values -> shortest bin string or vice versa.

Consequently it should be like:
Type of binarization:
"prefix and suffix as specified in subclause 9.2.2.9"

maxBinIdxCtx:
"prefix: 0/0/0 or 1/1/1 (chroma_pred_from_luma_enabled_flag = 0 or 1)

suffix: na, (uses Decode Bypass)"

ctxIdxTable:
"prefix: Table 9-16

suffix: na, (uses Decode Bypass)"

ctxIdxOffset:
"prefix: 0/2/4 (or 0/1/2?)

suffix: na, (uses Decode Bypass)"

So we should split the binarization table row for the two cases:
chroma_pred_from_luma_enabled_flag = 0 or 1
Furthermore we should verify wether chroma_pred_from_luma_enabled_flag = 0 has the same ctxIdxOffset as chroma_pred_from_luma_enabled_flag = 1 like it is described now in current draft text.

The binarization process, ctx derivation and all other parts of CABAC related to this syntax element should be changed accordingly.

Any proponent who provides this fix?

Thanks for providing suggestions on the description fix of intra_chroma_pred_mode. A document containing the fix is provided in the attachment, please check it and share your comments to make it better.

This is fixed in JCTVC-I1003 d5 (v6).