JVET-AM0121 AHG9: On the SEI processing order SEI message [M. M. Hannuksela, J. Boyce, F. Cricri (Nokia)]

Discussed during 1700–1855 on 26 June 2025 (chaired by S. Deshpande).

This contribution proposes the following items that are related to the SEI processing order (SPO) SEI message:

1. It is proposed to enable the packed regions information (PRI) SEI message in a processing chain defined by an SPO SEI message with the following changes:
   1. It is proposed to include the SEI message payload type of the PRI SEI message in SeiProcessingOrderSeiList and SpoProcessSeiList in HEVC and VVC.

Decision: Agreed

• 1. When a PRI SEI message is associated with a processing chain defined by an SPO SEI message, it is proposed that pri_target_pic_params_present_flag shall be equal to 1. In other words, when a PRI SEI message is included in a processing chain, it is proposed that the PRI SEI message can only be used as a process.

Specification text option A includes the constraint in the semantics of the SPO SEI message, whereas specification text option B includes the constraint in the semantics of the PRI SEI message.

It was asserted by the proponents that the text changes would be less if it is required that pri_target_pic_params_present_flag shall be equal to 1.

A use case where the pri_target_pic_params_present_flag may be 0 in case of a stand-alone PRI SEI was described (ROI processing).

Decision: Agreed on Option A.

1. It is proposed to allow processing chains of a single entry by replacing po_num_sei_messages_minus2 with po_num_sei_messages_minus1.

The motivation is to enable the use of the processing order nesting (PON) SEI message for carrying SEI messages that are alternatives to each other and/or extend the SEI message payload relative to an earlier VSEI version. For example, with this change, film grain characteristics (FGC) SEI messages of different target resolutions can be included into different processing chains.

It was commented that the motivation for the current minus2 coding is that previous thinking was that SPOs with 2 or more SEIs only are meaningful, but the new use case modifies that previous understanding.

Decision: Agreed

1. Asserted clarifications relating to associating SEI messages with SEI message types are proposed:
   1. Conditions that specify when an SEI message is associated with the i-th SEI message type of an SPO SEI message are proposed.

It was asked if the list of changes to define this condition, as proposed are really necessary.

Discussed after offline discussion on 30 June 2025. Some existing specification text was identified which addresses this. So no action.

• 1. As an editorial change, it is proposed to use the phrase "an SEI message associated with the i-th SEI message type" consistently.

Decision: Agreed on item b above (editorial).

1. It is proposed to disallow bitstreams with more than one SEI message associated with the same SEI message type for the same picture.

It was commented that there was a discussion of this at the previous meeting. It was commented that the proposed green highlighted text may be unnecessarily too restrictive. It was clarified by the proponent that the green highlight text change should be considered together with the yellow highlight association text.

Discussed after offline discussion together with item 3a above on 30 June 2025. After checking this constraint was not found existing in the current specification text. Some related text in the current specification was identified but was found to not be having a “shall” requirement. The offline suggestion was to add the proposed constraint or let the decoder handle it (which would need some text to be proposed).

Decision: Agreed on item 4.

1. The following changes related to the concept of the types of SEI messages are proposed:
   1. The concept of the "types of SEI messages" is proposed to be described to refer to entries of the SPO SEI message rather than SEI messages.
   2. It is proposed that types of SEI messages are different when processing order nesting is used for both and their processing order values differ. Specification text option A uses plain English, and option B refers to syntax elements.
   3. It is proposed that types of SEI messages are different when processing order nesting is used for one but not the other one. Specification text option A uses plain English, and option B refers to syntax elements.

Discussed further on 28 June 2025. See notes under JVET-AM0321.

1. It is proposed not to include byte alignment after the last SEI prefix.

It was commented that this breaks the aspect of carrying strings of “bytes” - only for the last prefix, and then it should also be considered to completely remove the byte alignment in the for loop.SEI prefix indication SEI message has similar alignment as in current VSEI v4 draft. Thus there was a preference to leave the current design as it is.

No action.

1. The following constraints related to po_complexity_info_present_flag are proposed:
   1. It is proposed that when no NNPFs are present in a processing chain, po_complexity_info_present_flag shall be equal to 0 in bitstreams conforming to this version of VSEI. Consequently, complexity could be indicated for any future neural-network-related SEI messages included in a processing chain.
   2. It is proposed that when no NNPFs are present in a processing chain and po_complexity_info_present_flag is equal to 1, decoders of this version of VSEI allow and ignore the complexity syntax elements.

Decision: Agreed to add the following constraint: When po_sei_payload_type[ i ] is not equal to the payload type value of the NNPFA SEI message for any value of i in the range of 0 to po_num_sei_messages_minus2 + 1, inclusive, po_complexity_info_present_flag shall be equal to 0.

1. As an asserted clarification, it is proposed that po_num_parameters_idc, po_num_kmac_operations_idc, and po_total_kilobyte_size indicate the cumulative values of all the NNPFs that are included in the processing chain and activated by NNPFA SEI messages for any picture.

It was discussed whether it is intended/ better to indicate the property of the network or the bitstream.

Different people had different preferences regarding whether i) or ii) below should be the design intent.

1. the cumulative values of all the NNPFs that are included in the processing chain, or
2. the cumulative values of all the NNPFs that are included in the processing chain and activated by NNPFA SEI messages for any picture.

Discussed on 30 June 2025 during 15:20-15:25

Proponents prefer ii) above. Some other participant preferred i).

Decision: Delegate to the editors to ensure that the specification text implements option i)

1. editorial proposals are proposed:
   1. It is proposed to rename po_num_sei_messages_minus1 or po_num_sei_messages_minus2 (depending on the outcome of item 2) to po_num_sei_msg_types_minus1 or po_num_sei_msg_types_minus2, since it counts SEI message types rather than SEI messages.
   2. Both "type of SEI message" and "SEI message type" have been used in the text in their singular and plural forms. It is proposed to use only "SEI message type" consistently.

Delegated to the editors.

JVET-AM0121 AHG9: On the SEI processing order SEI message

JVET-AM0121 AHG9: On the SEI processing order SEI message

Editorial improvements and bug fixes

It is noted that the list above may not be complete; if some adoption is missing that is recorded somewhere else in the meeting notes it shall also be considered included.

Primary editor: G. J. Sullivan.

Editors are requested to make preparations for integration into a new edition until the next meeting.

JVET-AM2006 Additional SEI messages for VSEI version 4 (Draft 7) [J. Boyce, J. Chen, S. Deshpande, M. M. Hannuksela, S. McCarthy, G. J. Sullivan, H. Tan, Y.-K. Wang] (2025-08-01)

Changes agreed at this meeting:

Multiple SEI messages

JVET-AM0121 AHG9: On the SEI processing order SEI message