Opened 4 years ago

Closed 3 years ago

#1443 closed defect (fixed)

Availability of suffix APS

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

Description

In the context of MR !1971 it was noted that the specification text on the availability of suffix APS to the decoding process is not sufficiently clear.

The design intention for the suffix APS was to be available for the following pictures, but not for the current picture. With the adoption of JVET-R0201 the intent was even more confirmed where we allowed a prefix and a suffix APS with the same ID within the same picture unit, expecting the prefix APS to be available for decoding the picture itself, while the suffix APS would only be available for following pictures.

Section 8.2 describes the invocation of the parsing process rather briefly:

Inputs to this process are NAL units of the current picture and their associated non-VCL NAL units.

Outputs of this process are the parsed RBSP syntax structures encapsulated within the NAL units.

The decoding process for each NAL unit extracts the RBSP syntax structure from the NAL unit and then parses the RBSP syntax structure.

This seems like all NAL units of a picture are parsed before the decoding/filtering process is invoked. Thus the suffix APS would already be available before decoding starts.

Since VVC does not have an activation process for parameter sets and uses "referred to" language instead, it could be argued that this reference is already established in the parsing process. Thus when the picture/slice header is parsed a reference can only be made to a parameter set that was parsed earlier, i.e. a prefix APS or a suffix APS of a previous picture, but not the suffix APS of the current picture.

We also seem to imply that once the parameter set is referred to, the content of this reference is fixed. For instance when PU A contains a PPS with a specific picture width and height and PU B contains a PPS with the same ID, but different picture with and height, the size of picture A in the DPB is not expected to change when picture B is decoded. It could thus be concluded that the content of the suffix APS does not overwrite the content of a previously parsed APS, that was referred to by the current picture.

These mechanisms are not described very clearly.

I would suggest to add clarifying language to the specification. I'm working on an errata input for the upcoming meeting.

Change history (1)

comment:1 Changed 3 years ago by yk

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

Text changes for fixing the issue have been provided in JVET-U0073-v3 and will be integrated into JVET-U2005-v1.

Note: See TracTickets for help on using tickets.