Opened 9 months ago

Closed 7 months ago

#1005 closed defect (fixed)

Rectangular slice map – CTU map in wrong order.

Reported by: bheng Owned by:
Priority: minor Milestone: VTM-9.0
Component: VTM Version: VTM-8.0
Keywords: Cc: ksuehring, XiangLi, fbossen, jvet@…

Description

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.

Change history (11)

comment:1 Changed 9 months ago by ksuehring

  • Milestone set to VTM-8.1
  • Resolution set to fixed
  • Status changed from new to closed
  • Summary changed from Subpictures – CTU map in wrong order. to Rectangular slice map – CTU map in wrong order.

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

comment:2 Changed 9 months ago by bheng

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 9 months ago by 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.

comment:5 Changed 9 months ago by ksuehring

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:6 Changed 9 months ago by ksuehring

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:7 Changed 9 months ago by 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.

comment:8 Changed 9 months ago by 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 {

...

comment:9 Changed 9 months ago by ksuehring

comment:10 Changed 7 months ago by ksuehring

  • Milestone changed from VTM-8.1 to VTM-9.0

The fix was merged

comment:11 Changed 7 months ago by ksuehring

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.