Opened 4 months ago

Closed 5 weeks ago

#671 closed defect (fixed)

Inference rule missing for num_tiles_in_slice_minus1?

Reported by: vdrugeon Owned by:
Priority: minor Milestone:
Component: spec Version: VVC D7 vE
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…

Description

Should there be some form of inference rule for num_tiles_in_slice_minus1? Currently it is only signalled when rect_slice_flag is 0 and NumTilesInPic is greater than 1. As far as I can tell, it seems to be used only when rect_slice_flag is equal to 0, so there does not seem to be any reason to infer it when rect_slice_flag is equal to 1.
However, what about the case when rect_slice_flag is 0 and NumTilesInPic is equal to 1? Please note that this is really a corner case, since it corresponds to a picture with only one tile and one slice (i.e. no partitioning), but for which no_pic_partition_flag would be equal to 0. While this corner case does not really seem to make sense, it does not seem to be prohibited either.
Any comments?

Change history (10)

comment:1 Changed 4 months ago by bbross

  • Version changed from VVC D7 vB to VVC D7 vC

comment:2 Changed 4 months ago by bbross

  • Version changed from VVC D7 vC to VVC D7 vD

comment:3 Changed 4 months ago by bbross

  • Version changed from VVC D7 vD to VVC D7 vE

comment:4 Changed 3 months ago by yk

This issue could be fixed by 1) conditioning rect_slice_flag on "if( NumTilesInPic > 1 )", 2) requiring the value of rect_slice_flag to be equal to 1 when NumTilesInPic is equal to 1, or 3) add the inference of num_tiles_in_slice_minus1 to equal to 0 when rect_slice_flag is 0 and NumTilesInPic is equal to 1. I personally prefer option 1, as that's more aligned with not signalling rect_slice_flag and inferring the value to be equal to 1 when no_pic_partition_flag is equal to 1.

Any other opinions?

comment:5 Changed 3 months ago by jeromnhsu

I prefer the inference: " when not present, num_tiles_in_slice_minus1 is inferred to be equal to 0. " and adding 'raster scan' in the semantics:

num_tiles_in_slice_minus1 plus 1, when present, specifies the number of tiles in the raster scan slice. The value of num_tiles_in_slice_minus1 shall be in the range of 0 to NumTilesInPic − 1, inclusive. When not present, num_tiles_in_slice_minus1 is inferred to be equal to 0.

As num_tiles_in_slice_minus1 is used only for the raster scan slice. When not present, it means NumTilesInPic is equal to 1 (only one slice).

comment:6 Changed 3 months ago by fhendry

It seems to me this issue occurs because the semantics of no_pic_partition_flag when equal to 0 still allows number of tile in picture to be equal to 1, which was agreed in the last meeting. My understanding is when number of tile in pic is 1, slice(s) in the picture is / are rectangular slice(s) and this seems not changed yet so far. I think option 1 and 2 are aligned with that understanding.

I have a question related to this. What is the difference between "signalling that there is only 1 tile and the tile is split into 3 slices" with "signalling that there are 3 tiles and each tile is contained in a / different slice"?

comment:7 Changed 3 months ago by yk

Hendry's understanding is correct. The key here is, it is determined at the PPS level that there is only one tile and there is only one slice, whether to consider that slice as a rectangular slice or raster scan slice. Considering it as a rectangular slice in this case makes more sense and is more aligned with earlier spec versions and more aligned with current case when not signalling rect_slice_flag and inferring the value to be equal to 1 when no_pic_partition_flag is equal to 1.

The difference between "signalling that there is only 1 tile and the tile is split into 3 slices" with "signalling that there are 3 tiles and each tile is contained in a / different slice" is as follows. In the former case, the slices are rectangular slices, while in the latter case, the slices could be either rectangular slices or raster-scan slices. When both are rectangular slices, then there is only signalling difference, no essential difference.

comment:8 Changed 3 months ago by hendry197

If there is only signalling difference but essentially the same in rectangular slices, I am wondering if we need to revisit our decision about this. The key here is when we have only 1 tile, whether we have one or multiple slices, the slices are rectangular. We cannot have raster-scan slices with single tile.

With the current semantics of no_pic_partition_flag, when it is 0 decoder cannot tell if the pic really have partition or not. Having stricter semantics like we had before for single_tile_in_pic_flag will not cause any loss of feature.

comment:9 Changed 3 months ago by jeromnhsu

Thanks for your reply which make things much clearer.
I agreed that the problem is whether to consider that slice as a rectangular slice or raster scan slice when there is only one tile, and to treat it as a rectangular slice is more aligned with that of "no_pic_partition_flag is equal to 1" case.
However, as current spec still supports signalling rect_slice_flag when there is only one tile, fix with solution 1) and 2) seems involving more normative change

Based on the current VVC text, two cases to talk about num_tiles_in_slice_minus1.
1) When no_pic_partition_flag is 1, rect_slice_flag is inferred to equal to 1. Then single tile or slice is implied, and num_tiles_in_slice_minus1 is not used at all.
2) When no_pic_partition_flag is 0, there is tile partitions.

  • For rect_slice_flag = 1, num_tiles_in_slice_minus1 is not used at all, as the number of tile in each slice is known as the slice is specified in the PPS already.
  • For rect_slice_flag = 0, when NumTilesInPic > 1 , num_tiles_in_slice_minus1 is signalled as in the current text. The case needs inference is when NumTilesInPic = 1, which is missing.

So, I prefer 3) to fix the missing part and maybe 1) and 2) could be further discussed if there is contribution next meeting

comment:10 Changed 5 weeks ago by yk

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

Fixed by actions taken at the 17th JVET meeting.

Note: See TracTickets for help on using tickets.