Opened 7 weeks ago

Closed 10 days ago

#1378 closed defect (worksforme)

Incorrect pps_tile_idx_delta_val[i] range

Reported by: kerzhy Owned by:
Priority: minor Milestone:
Component: spec Version:
Keywords: tile delta Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…, kirillsuverov@…


In the ranges of pps_tile_idx_delta_val[i] are specified from -NumTilesInPic + 1 to NumTilesInPic - 1 inclusive

So, if we want to get min pps_tile_idx_delta_val[i] (by spec) we need to take bottom right tile and than the top left tile. Only in these cases we will get -NumTilesInPic + 1

But we know from 7.4.8:

"The shapes of the slices of a picture shall be such that each CTU, when decoded, shall have its entire left boundary and entire top boundary consisting of a picture boundary or consisting of boundaries of previously decoded CTU(s)."

So, if we have more than 1 tile (only in this case pps_tile_idx_delta_val[i] can exist due to from spec) it is unable to reach pps_tile_idx_delta_val[i] = -NumTilesInPic + 1 because all CTUs in current tile need to have specified top&left boundaries, but if we will start from last tile (bottom right) condition from 7.4.8 don't be met.

The min value of pps_tile_idx_delta_val[i] we can get, is -NumTilesInPic + 3, like in this case:

About max value: if we accept, that pps_tile_delta_idx_val[i] can be applied in raster-scan case (I haven't found any contradiction in spec), in that way max value = NumTilesInPic - 1 is correct (i.e. we have 2 tiles in pic, so 2nd tileIdx (=1) - 1st tileIdx(=0) = 1 = NumTilesInPic(2) - 1). But using pps_tile_delta_idx_present_flag for case of 2 tiles makes no sence.

And if we consider more than 2 tiles, the max value will be NumTilesInPic - 3 (by analogy with min value, with the only difference that firstly we need to take 3rd and then 2nd tile (check tile scan order)).

After all of this, I suppose that at least min range boundary needs to be corrected, and pps_tile_idx_delta_val[i] range should be from -NumTilesInPic + 3 to NumTilesInPic - 1 (or even from -NumTilesInPic + 3 to NumTilesInPic - 3).

Change history (4)

comment:1 Changed 7 weeks ago by kerzhy

  • Cc kirillsuverov@… added
  • Version set to VVC D10 vG

comment:2 Changed 7 weeks ago by kerzhy

  • Version VVC D10 vG deleted

comment:3 Changed 5 weeks ago by yk

Thanks for the analysis and the suggestion. I personally think that herein it'd be better to keep the current value range because 1) although the current value range may be not optimal, it is not wrong, as it won't affect bitstream conformance and so on; 2) changing the min value of the value range from −NumTilesInPic + 1 to −NumTilesInPic + 3 is not a straightforward change.

Do others have an opinion on this?

comment:4 Changed 10 days ago by yk

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

Closing this ticket.

Note: See TracTickets for help on using tickets.