JVET-AK0055 AHG9: Semantics of the SPO SEI message [Y.-K. Wang, J. Xu, L. Zhang (Bytedance), K. Yang, Y. Li, Y. Xu (SJTU)]

This contribution proposes the following changes to the semantics of the SPO SEI message:

1. Add a constraint to require that the value of po_sei_importance_flag[ i ] shall be equal to 0 when po_sei_payload_type[ i ] is equal to any value in spoPropertySeiList, i.e., the i-th type of SEI message indicates a property.

Justification: It is asserted that an SEI message type that only indicates a property should never determine that a processing chain must be ignored when the post processor does not recognize the SEI message type.

A participant questioned if this change was necessary, and it doesn’t seem harmful to let the encoder have this flexibility.

A participant noted that there are two flags to which this might apply.

No action.

1. Add a constraint to require that a processing chain shall not include both an ERP SEI message type and a GCMP SEI message type.

Justification: It is asserted that it does not make sense for a processing chain to include an RWP SEI message but not an ERP or GCMP SEI message.

A participant questioned if there was a restriction against having both ERP and GCMP SEI messages in the same scope. If we do have such a constraint, it would be good to be consistent.

It was questioned whether it would be more appropriate for such a constraint to be present in in the video coding spec (VVC, HEVC, AVC) rather than in VSEI. The proponent suggests that if a video coding spec refers to both ERP and GCMP, the constraint could be applied in VSEI.

Discussed on 18 January 2025 at 14:30 PM. Consideration of this was chaired by S. Deshpande.

The proponent reported that he has confirmed that semantic constraint like this already exists and so having it in SPO also makes sense. Support was expressed to include this constraint.

It was asked if additional projection type is added in future how it should be handled. It was answered that similar approach (and new constraint) can be added at that time or it can be added now in a generic way to make it future proof.

Decision: Adopt #2 as noted above to make it future proof.

1. Add a constraint to require that, when a processing chain includes an RWP SEI message type, it shall also include either an ERP or GCMP SEI message type.

Justification: It is asserted that it does not make sense for a processing chain to include an RWP SEI message type but not either an ERP or GCMP SEI message type.

It was suggested that the wording should not preclude use of a different projection format defined in the future with RWP. It is possible to change constraints in the future if/when a different projection format is defined, but we need to remember to do that.

It was suggested that it would be desirable to impose such constraints in a similar way to how the constraints are imposed in the absence of SPO.

It was noted that sometimes an SEI message has the same name in more than one video coding spec but has a somewhat different definition.

Decision: Adopt #3.

1. Due to that certain order in omnidirectional processing at the decoder side needs to be followed, the following constraints are proposed:
   1. When a processing chain includes both an RWP SEI message type and an ERP SEI message type, the indicated processing order for the RWP SEI message type shall be later than that for the ERP SEI message type.
   2. When a processing chain includes both an RWP SEI message type and a GCMP SEI message type, the indicated processing order for the RWP SEI message type shall be later than that for the GCMP SEI message type.
   3. When a processing chain includes both an ERP SEI message type and a frame packing arrangement (FPA) SEI message type, the indicated processing order for the ERP SEI message type shall be later than that for the FPA SEI message type.
   4. When a processing chain includes both a GCMP SEI message type and an FPA SEI message type, the indicated processing order for the GCMP SEI message type shall be later than that for the FPA SEI message type.
   5. When a processing chain includes an ERP SEI message type, an FPA SEI message type, and an RWP SEI message type, the indicated processing order for the ERP SEI message type shall be later than that for the FPA SEI message type, and the indicated processing order for the FPA SEI message type shall be later than that for the RWP SEI message type.
   6. When a processing chain includes a GCMP SEI message type, an FPA SEI message type, and an RWP SEI message type, the indicated processing order for the GCMP SEI message type shall be later than that for the FPA SEI message type, and the indicated processing order for the FPA SEI message type shall be later than that for the RWP SEI message type.

It was suggested that the abstract wording is not consistent with the language in the spec attachment.

Decision: Adopt #4 as described in the spec attachment. A new version of this contribution was to be uploaded that fixes the abstract to be consistent with the spec text.

1. Many SEI messages include a persistence cancel flag in the syntax. For example, the NNPFA SEI message syntax includes the nnpfa_cancel_flag, which, when equal to 1, cancels the persistence of the target NNPF established by any previous NNPFA SEI message with the same nnpfa_target_id. Currently, it is allowed for the SEI prefix indication of an SEI message type in the SPO SEI message to have the persistence cancel flag equal to 1. However, it is asserted that that does not make sense.

It is therefore proposed that, when an SPO SEI message includes an SEI message type and the SEI prefix indication for the SEI message type includes the persistence cancel flag, it is required that the value of the persistence cancel flag included in the SEI prefix indication for this SEI message type shall be equal to 0. Specifically, the following constraints are proposed:

The detailed proposed text changes, marked relative to JVET-AJ2006-v3, are included in an attachment to this contribution.

It was suggested that a note may be able to used in place of the amount of text, although a note may be difficult to provide correct language for.

No action.