Opened 5 years ago
Closed 5 years ago
#506 closed defect (invalid)
The condition checks of RowHeight[ i ] prior to the signaling of brick_split_flag[ i ] and uniform_brick_spacing_flag[ i ]
Reported by: | yjchang | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | |
Keywords: | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
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:
- Remove the condition checks of RowHeight[ i ]:
{{
brick_split_flag[ i ]
}
{
uniform_brick_spacing_flag[ i ]
}}
- 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.
Change history (10)
comment:1 Changed 5 years ago by yk
comment:2 Changed 5 years ago by 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 the other PPS signaling. 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.
comment:3 Changed 5 years ago by 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?
comment:4 Changed 5 years ago by 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.
comment:5 follow-up: ↓ 7 Changed 5 years ago by bbross
Is it OK to close this ticket as invalid since the suggested improvement would a require a proposal?
comment:6 follow-up: ↓ 8 Changed 5 years ago by 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.
comment:7 in reply to: ↑ 5 Changed 5 years ago by 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?
comment:8 in reply to: ↑ 6 Changed 5 years ago by 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.
comment:9 Changed 5 years ago by 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.
comment:10 Changed 5 years ago by bbross
- Resolution set to invalid
- Status changed from new to closed
Thanks Jao-Yen for clarifying!
What is exactly the parsing dependency issue, noting that now we have the picture width and height signalled in the PPS?