Rectangular slice map – CTU map in wrong order.

[bheng]

The PPS::initRectSliceMap( ) function adds CTUs in raster-scan order rather than tile-scan order for the SingleSlicePerSubPic case. CTUs will be coded/decoded in the wrong order.

[ksuehring]

It seems the rectangular slice map was never correctly initialized for the syntax shortcut, where the slice layout is inferred from the subpicture layout. More a slice issue than a subpicture issue.

Fixed in MR 1507

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

[bheng]

The fix for subpictures using single_slice_per_subpic_flag doesn't work correctly. Specifically, the following condition used to find the final subpicture in the current tile is not right.

while (sps->getSubPicCtuTopLeftY(sliceIdxInTile) < getTileRowBd(row + 1))

Assume SubPic N is the final subpicture in the current tile, and SubPic N+1 is the next subpicture (in a new tile).

The top position of SubPic N+1 is not necessarily in the next tile row. SubPic N+1 is just as likely to be in the same tile row as SubPic N. In which case the above condition will still be true and the slice map will be incorrect.

[ksuehring]

Another fix is submitted in

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

[bheng]

In the latest fix, the following equations don't work correctly when used in combination with RPR (can only happen for a single subpic).

uint32_t leftX = sps->getSubPicCtuTopLeftX(i);
uint32_t rightX = leftX + sps->getSubPicWidth(i) - 1;
subpicWidthInTiles[i] = m_ctuToTileCol[rightX] + 1 - m_ctuToTileCol[leftX];

The sps->getSubPicWidth(i) is set during SPS parsing and based only on the maximum picture width. The actual picture width could be smaller. Therefore, by using the maximum subpic width, the subpicWidthInTiles derivation above will be incorrect and will possibly overrun the m_ctuToTileCol array.

The text might have the same issue, because this code is taken directly from the text, and I believe the text defines subpic width in the same way (only based on maximum picture width).

"When not present, the value of subpic_width_minus1[ i ] is inferred to be equal to ( ( pic_width_max_in_luma_samples + CtbSizeY− 1 ) >> CtbLog2SizeY ) − subpic_ctu_top_left_x[ i ] − 1."

The subpic height also has the same problem as the width.

[ksuehring]

When res_change_in_clvs_allowed_flag is equal to 1, the value of subpic_info_present_flag shall be equal to 0.

Since we don't allow the combination of RPR and subpictures in the specification, this should not be a problem. There is no process mapping subpicture boundaries to different resolutions.

[ksuehring]

I just noticed you are referring to the single subpicture case. I thought that single_slice_per_subpic_flag could not be used in this case. But it seems we don't have a syntax or bitstream constraint.

[ksuehring]

I contacted Miska for the text issue. He suggested to fix equation 30 with a special case for a single subpicture as follows

if( single_slice_per_subpic_flag ) {
      if( sps_num_subpics_minus1  = =  0 )
            AddCtbsToSlice( 0, 0, PicWidthInCtbsY, 0 PicHeightInCtbsY )
      else for( i = 0; i  <=   sps_num_subpics_minus1; i++ ) {
            …

I think that should resolve the issue without complicated syntax inferences.

[yk]

The spec fix should be as follows instead, as the picture may have multiple tiles:

if( pps_single_slice_per_subpic_flag ) {

if( !sps_subpic_info_present_flag ) /* There is no subpicture info and only one slice in a picture. */

for( j = 0; j < NumTileRows; j++ )

for( i = 0; i < NumTileColumns; i++ )

AddCtbsToSlice( 0, tileColBd[ i ], tileColBd[ i + 1 ], tileRowBd[ j ], tileRowBd[ j + 1 ] )

else {

...

[ksuehring]

I submitted MR 1583 for the software fix.

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

[ksuehring]

The fix was merged