JVET-AP0146 AHG9: Software implementation of the Green SEI message and demonstration of the use of attenuation map information metadata for display adaptation [C. H. Demarty, N. Caramelli, F. Aumont (InterDigital)]

This contribution informs of the implementation of the carriage of the display attenuation maps as auxiliary pictures in the bitstream, and of their usage at the decoder side for display adaptation, with the goal of reducing the energy consumption of the display.

This contribution also proposes a demonstration of the encoding/decoding of a green MPEG bitstream and its rendering result on a TV.

In v2 version, the number of a related contribution was added.

In v3, some typos were corrected and a slide deck was added.

A demo will be shown on Wednesday at lunch time in room C2.

A software implementation is available.

Non-SEI HLS aspects (0)

Section kept as template for future use.

Plenary meetings, joint meetings, BoG reports, and liaison communications

General

Plenary on Friday 24 April, 1645-1745

The following topic was discussed in this JVET plenary: Consideration of possible VSEI version 5

Questions to be considered:

• Urgency of defining new SEI messages in terms of market relevance
• Maturity of those SEI messages, criteria such as showcase, implementation, expectation on usage, etc.
• Possible need of normative behaviour of SEI message processing
• Possible relation with elements of new video standard
• Possible timeline

SEI messages proposed in this meeting for a possible version 5 (in JVET-AP0067, JVET-AP0073, JVET-AP0074, JVET-AP0075, JVET-AP0097, JVET-AP0196, plus some verbal proposals)

• Shutter interval extension
• Lens optical correction
• Localization and mapping
• Sample interleaving
• Constituent rectangles
• Quality metrics
• Display overlay info
• Display rectangles
• Colour mapping info
• Danmu info
• Photosensitive content info
• Etc. …

None of those appears to overly urgent in terms of market needs, a timeline of finalizing by April 2028 (when SG21 meets) appears sufficient. At this moment, no need is seen to issue a separate working draft. For achieving further technical maturity, keeping all messages in TuC might be sufficient. In the review, highest priority should be given to be able to get through all documents, and potentially put notes in the TuC where open issues are left (rather than resolving every detail).

It was requested to provide a table (or similar) about the current content of TuC until Monday

• New SEI message, or extension of existing one
• History: How long has it been in TuC
• What is the new functionality
• Assessment of technical maturity
• Availability and implementation, a possible need of additional processing (for extraction and output), possible need for normative processing
• Availability of showcase, justification by application case and usage foreseen.

After availability of this table, further discussion should be conducted at plenary level about the advantage for JVET of maintaining a separate working draft document. At this moment, considering the long timeline and the potential danger of cancellation, no official request, or “official” WD should be issued by WG 5.

A joint meeting with parent bodies should also be held to discuss this (including the plan for timeline).

Plenary on Monday 27 April 1400-1600

The following topics were discussed in this JVET plenary:

• Status of documents: Only two documents (JVET-AP0254, JVET-AP0268) were still missing
• Liaison communication (section 7.5) JPEG m76981 – E. Alshina will draft a response
• Scheduling for the remaining week was discussed (further detail on scheduling is recorded in section 2.12)
• Joint meetings (different zoom link, see calendar)
  • Joint meeting with VCEG/WG 4/7 on Gaussian Splat (Monday 1600-1800)
  • Joint meeting with VCEG/AG 5 on Verification/quality testing and metrics (Monday 1800-1930)
  • Joint meeting with VCEG/WG 2/AG 5 on next gen requirements and CfP Wednesday 1800-1900
• Review status from main track
  • All EE1/EE2 reviewed
    • Adoption of RDO based frame-level switching for E2E AI intra interface, two more possible adoptions from EE1 when training successful
    • No new EE2
    • Two possible adoptions from EE2, dependent on issuing a new ECM
  • It was decided to issue another version ECM20.0, including the two candidates from EE, but from the next meeting (as EE2 is discontinued) likely not to further continue ECM development-
  • Tool assessment and hardware complexity categories were reviewed – no new complexity reporting template was generated from this meeting
• Gaussian splat status
  • Delivery of Joint AhG report was requested, including a review about status of results and cross-checking
  • Dependency with JEEs on GS video packing improvements, CTC, anchor definition was recommended to be further discussed in joint meetings
• Review status from HLS track and discussion on potential open issues
  • Roughly 40% reviewed so far.
  • As it is likely that the time will run out without being able to review all documents, the following option was suggested: Give the AHG the authority to conduct further review and improvements on the TuC during interim AHG meeting(s), before issuing version 12. In this context, no new contributions should be allowed at the interim meeting, unless explicitly requested by the AHG. Otherwise, review of contributions might need to be shifted to the next meeting.
  • Gaussian splat SEI (if included) and new proposals from 6.3 should be definitely reviewed during the meeting.
  • It was requested that more discussion about criteria for including SEI messages in VSEI would be performed – Wednesday plenary.
• Review of documents at plenary level: Documents in section 4.1

Plenary on Wednesday 29 April 1045-1230

The following topics were discussed in this JVET plenary:

• Ballot results on ISO/IEC DTR 23888-3.2 were available in m76996 – no technical comments, two small editorial changes. According to ISO management, a DoCR should be issued.
• Status of documents: JVET-AP0254 was still missing (a crosscheck on EE2-4.1)
• Scheduling
  • Announcement of a demo by K. Sühring
• JPEG liaison review (conducted in a follow-up session Thursday morning)
• Reports and issues from tracks
  • Main track
    • Finalization of draft CfP
    • Revisits on EE1
    • CICP to be reviewed
  • HLS track:
    • Status/delivery of AVC next version
    • General status of review / new messages in particular (in total roughly 30% still to be reviewed)
    • Gain map SEI was recommended for inclusion, two other new ones still need review
    • Review of GS SEI messages (to be included in TuC)
  • Criteria for progression of SEI messages were discussed (see under JVET-AP0290).
• Output document planning (section 10)
• Review of documents at plenary level: section 4.13 (see notes in that section)

Plenary on Friday 1 May 0900-1240

The following topics were discussed in this JVET plenary:

• The following information was given:
  • Meeting notes d7 could not be uploaded last night due to problem with ITU ftp.
  • Recently, there was some problem with outlook.com email. Due to multiple bounces, a few people with such addresses were automatically unsubscribed from the JVET email reflector
• Remaining revisits were conducted
• EE1 document review and approval
• Joint EE on Gaussian splat (approval of JEE6.7 and JEE6.9 relating to JVET work)
• List of HLS adoptions was approved
• Establishment of AHGs
• Approval of output docs (including review as needed) – see section 10.
• Review of WG 5 meeting recommendations
• Software timelines were defined – see section 8.1
• Future planning, a.o.b.

MPEG information sharing meetings

Information sharing sessions with other WGs and AGs of the MPEG community were held on Monday 27 April 0900–1300, Wednesday 29 April 0900–1030, and Friday 1 May 1400–1600.

The status and plans for the work in the MPEG WGs and AGs was reviewed at these information sharing sessions.

Joint meetings

Joint sessions on Gaussian splat coding: MPEG WG 4 / Video, MPEG WG 5 / JVET, MPEG WG 7 3D Graphics, and VCEG (ITU-T Q6/21)

Joint meeting session 1 (Mon. 27 April 1600-1800)

The first joint session was chaired by Lu Yu (MPEG WG 4 Convenor), Jens-Rainer Ohm (JVET Chair), Gary J. Sullivan (SC 29 Chair & Q6/21 Rapporteur), and M. Preda (MPEG WG 7 Convenor). The following topics were discussed:

• Further proceeding on VSEI related contributions

The following session description is based on notes by GJS and LY. Additional notes taken by JRO on decisions about VSEI related contributions can be found in section 6.4.

VSEI-related input review was suggested to be the focus for the first joint meeting.

Potential inclusion of Gaussian splatting into the JVET TuC was also to be discussed, along with what should be investigated before the next meeting.

A joint viewing session (Wed. 1100-1200) was suggested to be added.

A new contribution JVET-AP0288 was noted.

The proposal JVET-AP0100 was suggested to be considered. It was produced from the Joint AHG activity of JVET, WG 4, and WG 7. A corresponding WG 4 document update was also to be uploaded.

A participant expressed concern that this is a union of various different proposals in a possibly hasty way, without evaluation of each feature. It was also commented that JVET-AP0233 had been cross checked and others had not.

Several versions of JVET-AP0100 had been uploaded. It was particularly commented that a proposal from HHI was not included in the v2 version, but it could be included as well. A v3 version had just been provided that integrated more approaches into the scheme. Change marks were included to show changes relative to the prior version.

Some of the software was based on a PLY file format that has been widely used. The "implicit" schemes did not use this. It was questioned whether both explicit and implicit approaches should be in the same SEI message. A proponent indicated that a potential split could be done later if having such a distinction would be helpful.

The base technologies in the new version was a combination of the original version of JVET-AP0100, the common picture format (JVET-AP0194/AP0195), and transform parameter signaling (JVET-AP0108).

It was initially suggested that JVET-AP0100-v3 be considered "baseline" and integrated into the TuC pending testing. However, another participant said the cross-check did not seem to be a full evaluation and comparison to a reference approach – just a check that the software produced the same results as reported by the proponent. There was some cross-check mentioned also for the HHI proposal.

The enhancement technologies include:

1. Triplane video-based implicit Gaussian splatting with a scaffold-based anchor point (JVET-AO0079)

2. Implicit representations (JVET-AP0213)

3. Spatial random access (JVET-AP0205)

4. SH non-uniform quantization and 2D transforms (JVET-AO0225)

5. Content-adaptive packing order optimization (JVET-AO0227)

It was suggested to be more important to have a joint EE looking forward. Others suggested including all of these approaches in the TuC (as originally proposed, without trying to harmonize them) and perform testing, then we could remove some later after experiments to study them (with software).

Joint meeting session 2 (Tue. 28 April 1600-1800)

The joint session was chaired by Lu Yu (MPEG WG 4 Convenor), Gary J. Sullivan (SC 29 Chair & Q6/21 Rapporteur), and M. Preda (MPEG WG 7 Convenor). The following topics were discussed:

• Review remaining documents
• Decision on documents

The following session description is based on notes by GJS and LY.

After discussion, it was planned that JVET-AP0100-v3 will be dismissed. JVET-AP0100-v4 will be generated with the original version of JVET-AP0100, combined with JVET-AP0108, JVET-AP0225 and the common picture format part of the JVET-AP0194 and JVET-AP0195.

It was planned to make software available and define experiments in JEE6.7 on those technologies in JVET-AP0100-v4. The technologies should be compared with the anchor defined in GSC CTCs in performance and coding time.

JVET-AP0205 will be integrated in TuC as a separated message.

JVET-AP0108 was for further study in a JEE.

JVET-AP0227 is only for encoder improvement.

JVET-AP0109 has a bug fix of JVET-AP0223 in software (to be integrated in JVET-AP0100).

Three schemes were to be included in the TuC: JVET-AP0100v1 + JVET-AP0194 + part of JVET-AP0195, JVET-AP0079, JVET-AP0213,

See also the notes recorded by JRO in section 6.4.

It was agreed to plan how comparisons are to be made, roughly like the prior CE 6.7.

• JEE 6.7 video based technologies
• JEE 6.9 design capsulation of signals by VSEI messages

One contribution can tagged with multiple JEEs. Any new technologies try to use video codec should be studied in JEE 6.7, that also include technologies based on VPCC.

The CTC was to be a JVET output document (also the next AHG report will be a JVET document).

JVET-AP0225 was to be integrated and tested.

A draft of the CfP was requested to be produced.

Informal joint viewing session (Wed. 29 April 1100-1200)

Viewing of Guassian splat demonstrations was conducted informally during this session.

Joint meeting session 3 (Wed. 29 April 1600-1800)

The joint session was chaired by Lu Yu (MPEG WG 4 Convenor), Gary J. Sullivan (SC 29 Chair & Q6/21 Rapporteur), and M. Preda (MPEG WG 7 Convenor). The following topics were discussed:

• BoG report on data selection (m77048)
• Draft CfP
• Review remaining documents

The following session descriptions are based on notes by LY.

• • • • Agreed on the recommendations from the JBoG
      • Preliminary structure of draft CfP
        • Introduction
        • Timeline
        • Definitions
        • Requirements
        • Test materials
        • Anchors
        • Evaluation procedure including test cases (objective and subjective)
        • Submission requirements
        • IPR
        • Contacts
        • Annexes (Information, Anchors, objective metrics...)
      • Scope of the call
        • The format could not be limited to I-3DGS, but should be made clear when issuing the CfP.
        • Establish JEE to study on alternative formats.
        • Test materials: both dynamic contents and static contents (especially large scene)
      • Draft of CfP to be prepared for review: Ralf, Yiyi, Gun, Alexandre, Bart, Patrice, Neus, Walt, Joel
      • In 2 weeks, output the draft

Joint meeting session 4 (Thu. 30 April 0830-1030)

The joint session was chaired by Lu Yu (MPEG WG 4 Convenor), JRO (JVET Chair & WG 5 Convenor), and M. Preda (MPEG WG 7 Convenor). The following topics were discussed:

• Define CTC
• Establish the next round of JEEs and review the descriptions
• Review AhG mandates

The following session description is based on notes by JRO and LY.

CTC for video-based approaches: No changes in sequences, rate points, metrics, renderer (to replicate the original source views) relative to previous (WG 7 N1414 of previous meeting). Points for lossless and near lossless will be added, but at this moment this is only relevant for G-PCC based proposals, as video-based approaches will come with a lossy mapping, anyway. Will not be used in computing BD rates. It was noted that theoretically video based approaches using HEVC might come to the near lossless range, but not guaranteed, and perhaps only with very high rate not supported by profiles for real time decoding.

Anchors are V-PCC and G-PCC newest versions (configurations in WG 7 N 1443 and N 1444, list of new adoptions in WG 7 N 1445 and N 1447, respectively). Anchors are expected to be available within 4 weeks after the meeting.

• CTC for I-3DGS and A-3DGS are specified. If any A-3DGS is studied, the proponent should also provide the renderer for the format.
• New modification:
  • • • • video based anchors: GSCodec Studio with the lasted update, and latest version of VPCC anchor from this meeting (available in 4w)
  • mandated test conditions: the rate points defined in CTC (sufficient quality overlay with anchor)
  • optional test conditions: waiting anchor generation inputs to test the video anchor also use test conditions as geo-based:
    • near lossless geo with lossy attributes (C1)
    • near lossless geo with near lossless attributes (CW)
    • One rate point per-sequence per condition
      • • YUV-SSIM as optional

For VSEI

• JVET-AP0108 also integrated into JVET-AP0100. And JVET-AP0225 also integrated in the TuC. But they will be test separately in JEE.
• JVET-AP0205 can be compared with similar contribution in VPCC.
• JVET-AP0288 is based on JVET-AP0100 and further study in JEE.
• JVET-AP0109: the second aspect (change the syntax table) integrated into JVET-AP0100.

For JEE 6.7

• 9 tests defined.
• One of the tests is one a compression of non-I3DGS representation (Triplane implicit representation). New anchor need to be generated for this representation.

Proponents do not need to conduct rate matching with the rates of the anchors, but rather sufficient quality matching, such that reasonable BD rates can be computed.

Revisits were conducted on document review from section 6.4 – clarification was reached which elements are to be integrated in JVET-AP0100, and which aspects are to be investigated separately in the upcoming JEE.

The setup of new EEs was discussed and agreed. For alternative representations (such as (JVET-AP0079) it may not be possible to fully check the benefit by quality of input original views; additional rendered views would need to be investigated.

As time ran out, continuation of this discussion was conducted Thu 30 April 1600-1700. to discuss the topics of JEE 6.7 and JEE6.9 (see under section 8.2), and AHG mandates (see under section 9).

Joint meeting session 5 (Thu. 30 April 1600-1800)

1600-1700 Joint meeting with WG 4, WG 7 and VCEG on Gaussian splats: Define Review AhG mandates and JEE6.9 (Room P2+P3)

These notes are based on those taken by LY.

Discussion topics:

• Review JEE 6.9
• Review AhG mandates
• Review remaining inputs
• Establish the next round of JEEs and review the descriptions

Notes:

• JEE 6.9
  • It was commented that technologies studied in JEE6.7 related with SEI messages report the bitrate for metadata.
  • Change Mandate 4 to: Encourage contributions and evaluate encapsulation method implementation and investigate matching with the text description.
  • Mandate 5: Encourage and evaluate contributions related to additional functionalities (beyond that studied in JEE 6.7) to be supported by SEI messages.
  • Mandate 6: encourage contributions on simplifying the SEI framework for GS coding.
• JEE 6.7
  • additional mandata: encourage and evaluation contributions on video-based GS coding.
• Next meeting, WG 5 will be the host of the JEEs. How to register input documents was to be announced and the deadline time of the document submission should be clarified.
• Review of the 3 inputs.
• JEE 6.3
  • mandates 1: exploration of new coding technologies those are non-geo-based or video-based
  • mandates 2: investigation of coding technologies for A-3DGS of dynamic content

Joint session 1815-1935 Monday 27 April on multi-layer verification tests, subjective viewing and metrics: MPEG WG 5 / JVET, MPEG AG 5 Visual Quality Assessment and VCEG (ITU-T Q6/21)

This session was chaired by Jens-Rainer Ohm (JVET Chair and WG 5 Convenor), Gary Sullivan (VCEG Rapporteur and SC 29 Chair), and Mathias Wien (AG 5 Convenor).

Review of documents in sections 4.5 (subjective quality testing and verification testing, with discussion focused primarily on the multilayer verification testing reported in JVET-AP0268) and 4.4 (objective quality assessment) was conducted (with the latter discussion only including JVET and AG 5) was conducted. See the notes in those sections.

Joint session 1810-1915 Wednesday 29 April on next generation video standardization Call for Proposals: MPEG WG 2 / Requirements, MPEG WG 5 / JVET, MPEG AG 5 Visual Quality Assessment, and VCEG (ITU-T Q6/21)

This joint session was chaired by Jens-Rainer Ohm (JVET Chair and WG 5 Convenor), Gary Sullivan (VCEG Rapporteur and SC 29 Chair), Mathias Wien (AG 5 Convenor), and Igor Curcio (WG 2 Convenor).

This section is based on notes taken by JRO and GJS.

It was agreed that the reviewed document is to be issued as the “final draft” (i.e., still a draft, but the final draft before the final CfP).

WG 2 N 448 and VCEG-BX25 were the previous approved requirements.

The previous draft text of the final draft CfP (JVET-AO2026_v6 in JVET-AP0047-v5.zip) was presented by JRO. For the requirements document reference in the document, it was agreed to convert the preliminary requirements documents of WG 2 and VCEG (from the April 2025 meeting) into a more finalized version by only changing the titles.

There was a requirements input document m76950 / VCEG-CA03 / JVET-AP0286. JVET-AP0286 was presented and discussed during this session. It focused on ultra-low latency and packet loss resilience. See further notes taken by JRO in section 4.17. Test conditions had previously been documented in JVET-AN2039. It was commented that substantial discussions of this topic had been held at previous meetings. The proponent said the request was to plan to regularly check the status of the standard under development, not to change the requirements document. The proponent suggested to establish related CTCs for planning for such future work.

MPEG WG 2 Requirements and VCEG approved issuing a requirements document to improve the title of the previous one referenced above.

BoGs (0)

Section kept as template for future use.

Liaison communications (1 incoming, 1 reply generated)

m76981 Liaison statement from SC 29/WG 1 to WG 5 on JPEG AI [SC 29/WG 1 N 101465]

The draft liaison document WG 5 N 403 was reviewed in JVET on Thursday 30 April at 1130 – 1200.

The reply thanked JPEG for the information it provided including update on the status of the JPEG AI project, thanking JPEG for providing a training set of images for use in neural network-based video coding (NNVC) development, and confirming the inclusion of this training set into the common test conditions of NNVC. It further appreciates the information about implementation of a JPEG AI decoder using SADL, and JPEG’s investigation of the possibility of achieving bit-exact reproducibility for JPEG AI inference. Finally, it provided updated information on neural network-based video coding studies in JVET, the Enhanced Compression Model (ECM), and the preparations toward issuing a Call for Proposals on video compression with capability beyond VVC.

The liaison response was also presented by G. J. Sullivan in the MPEG AG 3 Communication meeting on Thursday 30 April during 1500 – 1700.

Project planning

Software timeline

ECM 20.0 software was planned to be available 3 weeks after the meeting (22 May).

The NNVC 17.0 codebase software was planned to be available 4 weeks after the meeting (29 May), no new elements needed for CTC and EE1, such that experimentation can start based on NNVC16. Additional integration of various SADL aspects and harmonization with VTM may be done as appropriate in later versions.

Additional versions on top of VTM 24.0 may be released as appropriate (VTM 24.0 will be used for CfP).

Updates on top of HM18.0 and JM19.1 software were planned to be released within approximately 3 weeks after the meeting (integration and updates of SEI messages included in JVET-AN1018 and JVET-AN1017, merging of new HEVC multiview software). Additional versions may be released as appropriate.

An update on top of SHM12.4 was planned to be released within approximately 2 weeks after the meeting (harmonization with HM, updates of build system, and other improvements). Additional versions may be released as appropriate.

As a general rule in software development, a person who is executing a merge shall not be from the same company as the person who submitted that merge request.

Core experiment and exploration experiment planning

An EE on neural network-based video coding was established, as recorded in output document JVET-AP2023. An initial versions of this document was presented and approved (see section 10).

The following joint EEs on Gaussian splat technology are conducted based on JVET inputs and were presented and agreed in the JVET plenary on Friday (an update was made later upon request, as it was found that some JVET related proposals that had been agreed to be investigated during the joint meetings had been missing in the first version that was presented):

JEE 6.7 on coordinating the video-based coding technologies

(only tests relevant for JVET listed below, full description in WG 4 N 833)

• Mandate 1: Select video coding tools and investigate methods to wrap them in a coherent solution to meet the requirements of the Lightweight scenario.
• Mandate 2: Explore approaches for mapping GS parameters to 2D pixel space for optimizing coding performance.
• Mandate 3: Experiment the proposed solution on the content currently under discussion in GSC following the CTC. Additional experiments on lightweight content are encouraged to validate the effectiveness of the solution. Report the rate-distortion performance.
• Mandate 4: Analyse video coding requirements in terms of decoder complexity, depthwidth, profiles and levels to cope with the “lightweight” scenario.

Test on Quantization (Test 1)

The parameters are quantized because the original 3DGS parameters are typically represented as 32-bit floating-point numbers. This test aims to investigate the effects of various quantization techniques:

• Uniform quantization: A commonly used approach in which each attribute is normalized based on its min-max range and then uniformly quantized.
• Gaussian quantization: This method allocates more quantization levels near a specified mean value and fewer levels in the tails.
• Non-uniform quantization, m76701 / JVET-AP0225: Split SH coefficient values into multiple regions and apply region-dependent quantization step sizes and offsets.
• Generic exponential transform, m76839 / JVET-AP0108: Add syntax to signal the base and scaling factor of the generic exponential transform in the GSI SEI message, enabling nonlinear remapping of scale parameters for improved coding efficiency.

(Tests 2-7 not related to JVET contributions)

Test on unified packing and reconstruction framework (Test 8)

This test aims to investigate a unified framework for packing video-based GSC attributes into coded video and reconstructing 3DGS data unambiguously at the decoder.

• “Unified” framework, m76926 / JVET-AP0100: Provide a framework that signals component identities, explicit/implicit packing layout, picture format, bit depth, and dequantization parameters for unambiguous reconstruction of 3DGS attributes from coded video.

Test on Spatial random access and patch representation (Test 9)

This test aims to investigate enabling spatial random access and patch-based representation for selective access and common picture formats.

• Spatial random access, m76928 / JVET-AP0205: Partition a 3DGS scene into cubes and signal cube size, position, Gaussian count, and per-component entry offsets so viewport-dependent subsets can be accessed independently.
• Patch representation and common picture format, m76930 / JVET-AP0195: Signal patch counts, splats per patch, and patch-level packing/position metadata so patch-based access is supported and a common picture format with V-PCC-style designs can be used.

Test on Implicit intermediate representation-based compression (Test 10)

This test aims to investigate the effectiveness of compressing the content based on implicit representations, where the original I-3DGS can be decoded.

• Feature-plane implicit representation, m76929 / JVET-AP0213: Factorize original 3DGS attributes into feature planes and use GSI SEI together with NNPF to recover the original I-3DGS attributes, with scene-adaptive mapping to improve coding efficiency.

Test on Triplane video-based implicit representation compression (Test 11)

This test aims to investigate the effectiveness of compressing the content based on implicit representations, where another implicit representation instead of original I-3DGS is decoded. The comparison will be conducted against the ground truth images.

• Triplane-based representation, m76855 / JVET-AP0079: Use anchor points, triplanes, and lightweight MLPs to decode neural Gaussians directly as an alternative implicit representation, rather than reconstructing the original I-3DGS attributes.

JEE 6.9 description was presented by J. Jung on Friday 1 May (full description in WG 4 N 835)

• Mandate 1: Investigate encapsulation/high-level syntax technologies (VSEI, SEI, V3C, …) for the transport and storage of static and dynamic Gaussian Splats focusing on attribute mapping to video planes.
• Mandate 2: Enumerate technologies that could be integrated to encapsulation/high-level syntax technologies addressing the 1F/NF common test conditions and lightweight requirements. 
• Mandate 3: Develop a candidate high-level syntax that matches common VSEI practices, in terms of size, complexity and flexibility.
• Mandate 4: Encourage contributions and evaluate encapsulation method implementation and investigate if the text description matches.
• Mandate 5: Encourage and evaluate contributions related to additional functionalities to be supported by SEI messages.
• Mandate 6: Encourage contributions on simplifying the SEI framework for Gaussian splats coding.

No specific experiments were planned to be conducted beyond the investigations in JEE6.7, regarding the effectiveness of SEI related proposals in terms of representation, compression, and functionality.

Drafting of specification text, encoder algorithm descriptions, and software

The following agreement has been established: the editorial team has the discretion to not integrate recorded adoptions for which the available text is grossly inadequate (and cannot be fixed with a reasonable degree of effort), if such a situation hypothetically arises. In such an event, the text would record the intent expressed by the committee without including a full integration of the available inadequate text.

Plans for improved efficiency and contribution consideration

The group considered it important to have the full design of proposals documented to enable proper study.

Adoptions need to be based on properly drafted working draft text (on normative elements) and HM/VTM encoder algorithm descriptions – relative to the existing drafts. Proposal contributions should also provide a software implementation (or at least such software should be made available for study and testing by other participants at the meeting, and software must be made available to cross-checkers in EEs).

Suggestions for future meetings included the following generally-supported principles:

• Normative contributions (relating to changes in bitstream/decoder) shall include draft specification text
• Proposals shall contain all details relevant for understanding and be self-contained. In cases where the document is a follow-up of a previous contribution, the overall concept and the novelties should be highlighted at minimum
• Coding tool and encoder optimization proposals shall contain Excel sheets that allow assessment on a per-sequence basis
• Algorithm description text is strongly encouraged for non-normative contributions that are intended to be included in model description documents (VTM, ECM, etc.), and that is required for inclusion in TR drafts.
• Early upload deadline to enable substantial study prior to the meeting
• Using a clock timer to ensure efficient proposal presentations (5 min) and discussions (not exercised currently)

As general guidance, it was suggested to avoid usage of company names in document titles, software modules etc., and not to describe a technology by using a company name.

General issues for experiments

It was emphasized that those rules which had been set up or refined during the 12th JVET meeting should be observed. In particular, for some CEs of some previous meetings, results were available late, and some changes in the experimental setup had not been sufficiently discussed on the JVET reflector.

Group coordinated experiments have been planned as follows:

• “Core experiments” (CEs) are the coordinated experiments on coding tools which are deemed to be interesting but require more investigation and could potentially become part of a draft standard by the next meeting or in the near future.
• “Exploration experiments” (EEs) are also coordinated experiments. These are conducted on technology which is not foreseen to become part of a draft standard in the near future. The investigating methodology for assessment of such technology can also be an important part of an EE. (Further general rules for EEs, as far as deviating from the CE rules below, should be discussed in a future meeting. For the current meeting, procedures as described in the EE description document are deemed to be sufficient.)
• A CE is a test of a specific fully described technology in a specific agreed way. It is not a forum for thinking of new ideas (like an AHG). The CE coordinators are responsible for making sure that the CE description is complete and correct and has adequate detail. Reflector discussions about CE description clarity and other aspects of CE plans are encouraged.
• A description of each experiment is to be approved at the meeting at which the experiment plan is established. This should include the issues that were raised by other experts when the tool was presented, e.g., interference with other tools, contribution of different elements that are part of a package, etc. The experiment description document should provide the names of individual people, not just company names.
• Software for tools investigated in a CE will be provided in one or more separate branches of the software repository. Each CE will have a “fork” of the software, and within the CE there may be multiple branches established by the CE coordinator. The software coordinator will help coordinate the creation of these forks and branches and their naming. All JVET members will have read access to the CE software branches (using shared read-only credentials as described below).
• During the experiment, revisions of the experiment plans can be made, but not substantial changes to the proposed technology. Withdrawing parts of experiments that were intended to show the individual benefits of a tool or parts of a tool is strongly discouraged. Combination tests may not be considered in such cases. Any changes made to individual tools in a combination shall be documented.
• The CE description must match the CE testing that is done. The CE description needs to be revised if there has been some change of plans.
• The CE summary report must describe any changes that were made in the process of finalizing the CE.
• By the next meeting it is expected that at least one independent cross-checker will report a detailed analysis of each proposed feature that has been tested and confirm that the implementation is correct. Commentary on the potential benefits and disadvantages of the proposed technology in cross-checking reports is highly encouraged. Having multiple cross-checking reports is also highly encouraged (especially if the cross-checking involves more than confirmation of correct test results). In cases where combinations of different elements are planned to be tested, mutual cross-checking of the individual elements by other parties of the combination is discouraged. The combination must be cross-checked by an independent party. The reports of cross-checking activities may (and generally should) be integrated into the CE report rather than submitted as separate documents.
• It is mandatory to report encoder optimizations made for the benefit of a tool, and if an equivalent optimization could be applied on the anchor, a comparison against the improved anchor shall be provided.
• A new proposal can be included in a CE based on group decision, regardless if an independent party has already performed a cross-check in the meeting when it was first proposed.

It is possible to define sub-experiments within particular CEs, for example designated as CEX.a, CEX.b, etc., where X is the basic CE number.

As a general rule, it was agreed that each CE should be run under the same testing conditions using one software codebase, which should be based on the group test model software codebase. An experiment is not to be established as a CE unless there is access given to the participants in (any part of) the CE to the software used to perform the experiments.

The general agreed common conditions for single-layer coding efficiency experiments for SDR video are described in the prior output document JVET-AL2010.

Experiment descriptions should be written in a way such that it is understood as a JVET output document (written from an objective “third party perspective”, not a proponent perspective – e.g., not referring to methods as “improved”, “optimized”, “enhanced”, etc.). The experiment descriptions should generally not express opinions or suggest conclusions – rather, they should just describe what technology will be tested, how it will be tested, who will participate, etc. Responsibilities for contributions to CE work should identify individuals in addition to company names.

CE descriptions contain a basic description of the technology under test, but should not contain excessively verbose descriptions of a technology (at least not unless the technology is not adequately documented elsewhere). Instead, the CE descriptions should refer to the relevant proposal contributions for any necessary further detail. However, the complete detail of what technology will be tested must be available – either in the CE description itself or in documents that are referenced in the CE description that are also available in the JVET document archive.

Any technology must have at least one cross-check partner to establish a CE – a single proponent is not enough. It is highly desirable have more than just one proponent and one cross-checker.

The CE development workflow was previously described at:

https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/wikis/Core-experiment-development-workflow

However, it was noted that the link doesn’t seem to exist anymore.

CE read access is available using shared accounts: One account exists for MPEG members, which uses the usual MPEG account data. A second account exists for VCEG members with account information available in the TIES informal ftp area (IFA) system at:

https://www.itu.int/ifa/t/2017/sg16/exchange/wp3/q06/vceg_account.txt

Some agreements relating to CE activities were established as follows:

• Only qualified JVET members can participate in a CE.
• Participation in a CE is possible without a commitment of submitting an input document to the next meeting. Participation was requested by contacting the CE coordinator.
• All software, results, and documents produced in the CE should be announced and made available to JVET in a timely manner.
• A JVET CE reflector will be established and announced on the main JVET reflector. Discussion of logistics arrangements, exchange of data, minor refinement of the test plans, and preparation of documents shall be conducted on the JVET CE reflector, with subject lines prefixed by “[CEx: ]”, where “x” is the number of the CE. All substantial communications about a CE other than such details shall take place on main JVET reflector. In the case that large amounts of data are to be distributed, it is recommended to send a link to the data rather than the data itself, or upload the data as an input contribution to the next meeting.

General timeline for CEs

T1= 3 weeks after the JVET meeting: To revise the CE description and refine questions to be answered. Questions should be discussed and agreed on JVET reflector. Any changes of planned tests after this time need to be announced and discussed on the JVET reflector. Initially assigned description numbers shall not be changed later. If a test is skipped, it is to be marked as “withdrawn”.

T2 = Test model software release + 2 weeks: Integration of all tools into a separate CE branch of the VTM is completed and announced to JVET reflector.

• Initial study by cross-checkers can begin.
• Proponents may continue to modify the software in this branch until T3.
• 3rd parties are encouraged to study and make contributions to the next meeting with proposed changes

T3: 3 weeks before the next JVET meeting or T2 + 1 week, whichever is later: Any changes to the CE test branches of the software must be frozen, so the cross-checkers can know exactly what they are cross-checking. A software version tag should be created at this time. The name of the cross-checkers and list of specific tests for each tool under study in the CE plan description shall be documented in an updated CE description by this time.

T4: Regular document deadline minus 1 week: CE contribution documents including specification text and complete test results shall be uploaded to the JVET document repository (particularly for proposals targeting to be promoted to the draft standard at the next meeting).

The CE summary reports shall be available by the regular contribution deadline. This shall include documentation about crosscheck of software, matching of CE description and confirmation of the appropriateness of the text change, as well as sufficient crosscheck results to create evidence about correctness (crosscheckers must send this information to the CE coordinator at least 3 days ahead of the document deadline). Furthermore, any deviations from the timelines above shall be documented. The numbers used in the summary report shall not be changed relative to the description document.

CE reports may contain additional information about tests of straightforward combinations of the identified technologies. Such supplemental testing needs to be clearly identified in the report if it was not part of the CE plan.

New branches may be created which combine two or more tools included in the CE document or the VTM (as applicable).

It is not necessary to formally name cross-checkers in the initial version of the CE description document. To adopt a proposed feature at the next meeting, JVET would like to see comprehensive cross-checking done, with analysis of whether the description matches the software, and a recommendation of the value of the tool and given tradeoffs.

The establishment of a CE does not indicate that a proposed technology is mature for adoption or that the testing conducted in the CE is fully adequate for assessing the merits of the technology, and a favourable outcome of CE does not indicate a need for adoption of the technology into a standard or test model.

Availability of specification text is important to have a detailed understanding of the technology and also to judge what its impact on the complexity of the specification will be. There must also be sufficient time to study this in detail. CE contributions without sufficiently mature draft specification text in the CE input document should not be considered for adoption.

Lists of participants in CE documents should be pruned to include only the active participants. Read access to software will be available to all members.

Establishment of ad hoc groups

The ad hoc groups established to progress work on particular subject areas until the next meeting are described in the table below. The discussion list for all of these ad hoc groups was agreed to be the main JVET reflector (jvet@lists.rwth-aachen.de).

Chairs of AHGs had been asked to send draft mandates to JRO before 1800 on 30 April, preferably copy from the table below and sending with changemarks or yellow highlight of changes.

Review of AHG plans was conducted during the plenary on Friday 1 May 2026 at 1050–1150.

For consideration in future meetings For software developed in the context of activities such as Optimization of encoders and receiving systems for machine analysis of coded video content and the generative face SEI, it may be useful to find a persistent home. A first step could be issuing a document specifically summarizing JVET software assets (could also be an update of Ax1012).

Related to this, it had been discussed during the 41^st JVET meeting that it could be useful to generate a permanent repository (instead of AHG branches that may be forgotten) plus documentation for software parts that do extraction of SEI message parameters directly from video, and perform corresponding synthesis. Examples would be NNPF, FGC, GFV, … This was left for further study.

It was confirmed that the rules which can be found in document ISO/IEC JTC 1/‌SC 29/‌AG 2 N 046 “Ad hoc group rules for MPEG AGs and WGs” (available at https://www.mpegstandards.org/adhoc/), are consistent with the operation mode of JVET AHGs. It is pointed out that JVET does not maintain separate AHG reflectors, such that any JVET member is implicitly a member of any AHG. This shall be mentioned in the related WG Recommendations. The list above was also issued as a separate WG 5 document (ISO/IEC JTC 1/‌SC 29/‌WG 5 N 404) in order to make it easy to reference.

A Joint AHG group was installed with ISO/IEC JTC 1/‌SC 29/‌WG 4 and ISO/IEC JTC 1/‌SC 29/‌WG 7 as follows:

It is planned that formally only one instance of the joint AHG is installed over all MPEG WGs, and the responsibility for doing this is rotating among the involved WGs. At the current meeting, WG 4 was responsible, at the next meeting, JVET / WG 5 will take over (including management of documents submitted to the joint activity).

JVET members are invited to subscribe to the reflector of this AHG via https://lists.aau.at/mailman/listinfo/mpeg-gsc.

GS content is stored at https://content.mpeg.expert/data/Explorations/GSC/CTC/

The CTC is updated during each meeting period, and the version valid during the upcoming meeting cycle can be found as:

For accessing software, test materials and anchors, JVET members should contact the AHG chairs. In the next meeting, WG 5 will manage input and output documents of the joint activity. Documents relevant for usage of SEI messages in Gaussian splat representation should be submitted both as WG 5 documents and as JVET documents, such that JVET members who are participating via ITU also can get access. Documents not relevant for usage of SEI messages shall only be submitted as WG 5 documents. In this context, the following rules are to be observed:

• register all GSC exploration contributions as documents to WG 5 by using MDMS (not to jvet-experts.org), with registration/upload deadline 6 July
• proponents shall duplicate all contributions related to SEI messages to JVET (by using jvet-experts.org), with JVET registration/upload deadline, as discussion on SEI messages may start from Tuesday.
• JEE6.7 and JEE6.9 to be discussed before Wednesday 14 July
• output documents to be ready Friday 16 July and issued by WG 5 (not by JVET that is closing Wed)

For definition of joint exploration experiment on topics relevant for JVET, see section 8.2 of this report. CTC is available as JVET-AP2028 (duplicate of N 826 of WG 4).

Output documents

The following documents were agreed to be produced or endorsed as outputs of the meeting. Names recorded below indicate the editors responsible for the document production. Where applicable, dates of planned finalization and corresponding parent-body document numbers are also noted.

It was reminded that in cases where the JVET document is also made available as a WG 5 output document, a separate version under the WG 5 document header should be generated. This version should be sent to GJS and JRO for upload.

The list of JVET ad hoc groups was also issued as a WG 5 output document WG 5 N 404, as noted in section 9.

A list of JVET-only output documents from the current meeting (including links to jvet-experts.org) was issued as a WG 5 document WG 5 N 402.