The condition checks of RowHeight[ i ] prior to the signaling of brick_split_flag[ i ] and uniform_brick_spacing_flag[ i ]

[yjchang]

A parsing dependency issue is discovered after VVC adopted a bugfix which adds the syntax condition checks of RowHeight[ i ] to brick_split_flag[ i ] and uniform_brick_spacing_flag[ i ]:
{{
if( RowHeight[ i ] > 1 )

brick_split_flag[ i ]

}
{
if( RowHeight[ i ] > 2 )

uniform_brick_spacing_flag[ i ]

}}

---

It can be resolved by simply replacing the condition checks in the syntax with the conformance in the semantics as follows:

1. Remove the condition checks of RowHeight[ i ]:

{{

brick_split_flag[ i ]

}
{

uniform_brick_spacing_flag[ i ]

}}

2. Add conformance to the semantics of brick_split_flag[ i ] and uniform_brick_spacing_flag[ i ]:

brick_split_flag[ i ] equal to 1 specifies that the i-th tile is divided into two or more bricks. brick_split_flag[ i ] equal to 0 specifies that the i-th tile is not divided into two or more bricks. It is a requirement of bitstream conformance that the value of brick_split_flag[ i ] shall be zero if RowHeight[ i ] = 1.

uniform_brick_spacing_flag[ i ] equal to 1 specifies that horizontal brick boundaries are distributed uniformly across the i-th tile and signalled using the syntax element brick_height_minus1[ i ]. uniform_brick_spacing_flag[ i ] equal to 0 specifies that horizontal brick boundaries may or may not be distributed uniformly across i-th tile and signalled using the syntax element num_brick_rows_minus2[ i ] and a list of syntax elements brick_row_height_minus1[ i ][ j ]. When not present, the value of uniform_brick_spacing_flag[ i ] is inferred to be equal to 1. It is a requirement of bitstream conformance that the value of uniform_brick_spacing_flag[ i ] shall be one if RowHeight[ i ] = 2.

---

Alternatively, it can be resolved by adding a new syntax element to specify the value of RowHeight[ i ] in the i-th tile.

[yk]

What is exactly the parsing dependency issue, noting that now we have the picture width and height signalled in the PPS?

[yjchang]

The derivation of RowHeight[ i ] must be queued until the PPS syntax elements tile_rows_height_minus1 or tile_row_height_minus1[ i ] are parsed. Please note that pic_width_in_luma_samples, pic_height_in_luma_samples, and tile_rows_height_minus1 or tile_row_height_minus1[ i ] shall be known before the derivation. There is no this kind of dependencies between syntax elements in PPS. Since it can be easily fixed, it might be okay to fix this now without new proposal unless there is other concerns or I misunderstood anything.

[yk]

Why is that a problem, given that these syntax elements (pic_width_in_luma_samples, pic_height_in_luma_samples, and tile_rows_height_minus1 or tile_row_height_minus1[ i ] ) all come before the syntax conditions containing RowHeight[ i ]? Isn't it natural that earlier syntax elements in a syntax structure are used for parsing of later syntax elements?

[yjchang]

It should be understood that it needs some processing calculations and time delays to derive all of RowHeight[ i ], and it should be better if it can be removed from this point of view. I have no problem to not change it now if there is concern on this suggested change.

[bbross]

Is it OK to close this ticket as invalid since the suggested improvement would a require a proposal?

[jeromnhsu]

I saw inconsistency here.
If we have pic_width_in_luma_samples, pic_height_in_luma_samples in PPS, why is num_tiles_in_pic_minus1 a problem, which needs to be signaled, while RowHeight[ i ] is not an issue?
Maybe need a proposal to unify these.

[yjchang]

Replying to bbross: It can be closed if there is no more suggestions.

Is it OK to close this ticket as invalid since the suggested improvement would a require a proposal?

[yjchang]

Replying to jeromnhsu: I agree with your point. I will prepare a proposal next meeting for discussion.

I saw inconsistency here.
If we have pic_width_in_luma_samples, pic_height_in_luma_samples in PPS, why is num_tiles_in_pic_minus1 a problem, which needs to be signaled, while RowHeight[ i ] is not an issue?
Maybe need a proposal to unify these.

[yk]

Indeed, the group introduced some redundancy to the syntax before moving pic_width_in_luma_samples and pic_height_in_luma_samples to PPS (as part of the RPR adoption) at the Gothenburg meeting to avoid PPS parsing dependency on SPS. Now that pic_width_in_luma_samples and pic_height_in_luma_samples are in the PPS, that redundancy is no longer needed and can be removed. Having a proposal on that would be good.

[bbross]

Thanks Jao-Yen for clarifying!