I think new transform_tree() description in JCTVC-P1005_v1 was targetted to fix the bug in 4:2:2/4:4:4 chroma cbf coding (ticket #1225).

But It looks like there remains another bugs in transform_tree().

(1) In 4:4:4 case, chroma 4x4 TB still cannot have indivisiual cbf due to the restriction "log2TrafoSize > 2".

One possible solution: remove the restriction "log2TrafoSize > 2" when "ChromaArrayType = 3".

(2) In 4:2:2 case, chroma 4x4 TB cannot have indivisiual cbf when transform_tree(.., trafoDepth, ..) is invoked with "log2TrafoSize = 2" and split_transform_flag[][][trafoDepth] is signalled as "1".

One possible solution: replace

  if( ChromaArrayType  = =  2  &&  ! split_transform_flag[ x0 ][ y0 ][ trafoDepth ] )

to

  if( ChromaArrayType  = =  2  &&  ((! split_transform_flag[ x0 ][ y0 ][ trafoDepth ]) || (log2TrafoSize == 3) )

In 7.3.2.2, seq_parameter_set_rbsp():

for( i = ( sps_sub_layer_ordering_info_present_flag ?
           sps_max_sub_layers_minus1 : 0 );
           i <= sps_max_sub_layers_minus1; i++ ) {
...
}

Will only loop once when sps_sub_layer_ordering_info_present_flag = 1.

Which has the opposite interpretation of 7.4.2.2:

sps_sub_layer_ordering_info_present_flag equal to 1 specifies that sps_max_dec_pic_buffering[ i ], sps_max_num_reorder_pics, and sps_max_latency_increase[ i ] are present for sps_max_sub_layers_minus1 + 1 sub-layers, sps_sub_layer_ordering_info_present_flag equal to 0 specifies that the values of sps_max_dec_pic_buffering[ sps_max_sub_layers_minus1 ], sps_max_num_reorder_pics[ sps_max_sub_layers_minus1 ] , and sps_max_latency_increase[ sps_max_sub_layers_minus1 ] apply to all sub-layers.

7.3.8.10 Transform unit syntax

The residual coding syntax should be invoked up to two times when ChromaArrayType is equal to 2 and at most once for other cases.

Therefore, the four instances of the following loop:

for( tIdx = 0; tIdx < ( ChromaArrayType = = 2 ? 1 : 0 ); tIdx++)

Should be replaced with:

for( tIdx = 0; tIdx < ( ChromaArrayType = = 2 ? 2 : 1 ); tIdx++)