JVET-AO0290 Report of BoG on CfP drafting [F. Bossen, M. Wien]

First review conducted in JVET Tuesday 20 Jan. 2145UTC.

Notes taken during that review are in italics font below.

The BoG on CfP drafting met on January 19, 2026 from 2100 until approximately 2310 UTC. This report includes notes from the meeting as well as recommendations. A draft CfP document based on JVET-AO0045 and that includes recommended changes is attached.

1. Introduction

The BoG was tasked to develop a draft CfP document from JVET-AO0045

• Considering the suggestions from JVET-AO0130, JVET-AO0135, JVET-AO0184, JVET-AO0072
• Define additional rate points at the high end
• General editorial improvements

1. Discussion

Related to JVET-AO0130

Issue: Date of final CfP publication. The meeting report from the Geneva meeting mentions a July 2026 date. The introduction of the draft CfP mentions April 2026. It is suggested to modify the introduction to mention a final draft CfP in April 2026 and a final CfP in July 2026. This is consistent with the decision from Geneva.

It should be clarified that the intent is to have the testing conditions frozen in April (final draft), and that the changes made in July (final CfP) are expected to be minor.

Issue: The “hidden” dataset. This paragraph should be further refined. For example, the approximate size of hidden dataset should be known at time of CfP issuance (along with constraints, e.g., only a subset of runtime constraints or bitrates). Need to clarify timeline and who will define the hidden dataset. Need to clarify what happens if decoder fails on the hidden dataset.

It was agreed that clarification is needed. Possibilities are

• No visual testing to be conducted
• No precise rate matching
• Number of points for constrained complexity?
• Definition of number of sequences, duration of sequences (can be shorter), size of pictures (number HD, UHD, etc.), conditions RA/LD
• Timeline needs to be better defined
• Consequences of not delivering? Problems with only some sequences?

It would be sufficient for the draft to indicate that this will be better clarified in the final draft CfP

Issue: Disclosure of training scripts for learning-based tools. A sentence was added in section 11 to bring attention to the fact that training scripts may have to be disclosed upon further evaluation after the CfP (similar to disclosure of source code). The sentence was made more general to include any tool. A definition of “learning-based tool” may be needed for the purpose of complexity reporting. Further discussion was required, in particular with respect to a number of parameters threshold.

It was agreed that the formulation with “may” regarding the disclosure of training scripts is appropriate for indicating that this could happen during evaluation for standardization.

It was agreed not to require usage of certain training data. It is already written that it is mandatory to report which material was used for training. If a proposal is accepted as to be further investigated, part of that could be that it is re-trained with different material. Usage conditions can also be clarified later.

Related to JVET-AO0135

Issue: description of quantization parameter changes. BoG suggests adding clarification.

Related to JVET-AO0184

Reorganize HDR content into PQ and HLG classes instead of 4k and 8k cropped (as per meeting notes).

Related to JVET-AO0072

Added sentence is Annex D to require providing per frame bit counts for each test point.

Fifth target bitrate

It was previously agreed to add a fifth target bitrate above the highest target bitrate for the purpose of objective evaluation. It is suggested to have the fifth bitrate be equal to two times the fourth rate. Further refinements may be made if necessary (QP values at suggested rates should be checked).

A lower bound for rate matching may be needed for the fifth bitrate to guarantee sufficient overlap between the rate-distortion curves of the anchor and the test.

Further checks about appropriateness of the fifth bitrate to be done in the interim period.

Miscellaneous

Remove comments related to sequences (see JVET-AO0045).

It was clarified that not all test points may be evaluated subjectively.

Regarding desired usage of submitted decoder executable, it was asked whether decoder executable should be limited in size (because of potentially very large weight tables). The potential need to specify a platform more precisely (e.g., CPU architecture) was discussed.

It was agreed that the size limitation should not be imposed.

It was agreed to add clarification that the reproduction of the sequences from the decoder output should be bit-exact.

Bits per frame are to be reported, in a separate file with a format to be specified.

Liaison communications (4 incoming, 2 replies generated)

m75762 Liaison Statement from ITU-T SG 21 to SC 29 on technologies for 3D Gaussian splat coding [SG21-LS126]

This incoming liaison statement was presented in a joint meeting (see section 7.3.2). It was addressed to SC 29, with no need for a response from JVET.

m75822 Liaison statement from SMPTE to SC 29/WG 4 and 5 on Requesting SEI mechanism for new SMPTE ST 2094-60 standard

This incoming liaison letter relates to an associated contribution document JVET-AO0112; see the notes for that topic. W. Husak, D. Touzé, and A. Tourapis had been asked to work on a response, recommending to use the T.35 approach that appears more flexible.

The draft liaison reply document WG 5 N 391 was reviewed in JVET on Wednesday 21 January at 2130 – 2200. The reply said that during the discussion, various experts questioned whether an ITU-T T.35 SEI message could be utilized in lieu of a new, dedicated SEI message, and that this approach would be consistent with a previous recommendation from JCT-VC for the use of private ITU-T T.35 messages that was communicated in WG11 N 16074 (of February 2016), which has led to successful deployments of the rest of the ST 2094 standards suite. It is our understanding that SMPTE has been assigned an ITU-T T.35 Terminal Provider Code (0x0090) under the United States Country Code (0xB5) that can be used for such purposes. The ITU-T T.35 method with this information is currently employed for the SMPTE ST 2094-50 standard.

Consequently, JVET said that it seeks clarification on why a different approach is being considered for ST 2094-60. JVET would appreciate further technical justification for the preference of a dedicated SEI message over the existing ITU-T T.35 mechanism.

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

This incoming liaison letter was sent from JPEG’s October meeting, with information that was further updated in another incoming liaison letter from JPEG’s January meeting. See the notes for the newer incoming liaison statement m75840.

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

This incoming liaison letter was sent from JPEG’s January meeting.

Beyond the two liaison letters which arrived during the interim period since the 40^th JVET meeting, another liaison letter from JPEG (SC 29/WG 1) had also been received as m74904 / WG 1 N 101272 / SC 29 N 22963 during the previous (40^th) meeting. JVET had originally planned to send a response from that meeting in October 2025, but that never happened, as it had arrived too late to be processed in the SG21 plenary. E. Alshina was asked to draft a single response for all three liaison letters received recently from JPEG.

The draft liaison document WG 5 N 390 was reviewed in JVET on Wednesday 21 January at 2200 – 2240.

The reply thanked JPEG for the information it provided including information about a visual quality comparison of JPEG AI with ECM, VVenC, and DCVC-FM, and a smartphone implementation of JPEG AI, and 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 two liaison documents WG 5 N 390 and WG 5 N 391 were also presented by G. Sullivan in the MPEG AG 3 Communication meeting on Thursday 25 Jan. during 1300 – 1500.

Project planning

Software timeline

ECM 19.1 software was planned to be available 1 week after the meeting (31 Jan.).

The NNVC 16.0 codebase software was planned to be available 4 weeks after the meeting (20 Feb.), including all elements needed for CTC and EE1. Additional integration of various SADL aspects and harmonization with VTM may be deferred for version 16.1.

VTM23.14 software was planned to be released within one week after the meeting (31 Jan.). VTM 24.0 was planned to be released within two week after the meeting (6 Feb.), including full implementation of all SEI messages in JVET-AN1019 and JVET-AN2001. Additional versions may be released as appropriate.

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). 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-AO2023.

An EE on enhanced compression technology beyond VVC capability using techniques other than neural-network technology was also established, as recorded in output document JVET-AO2024.

Initial versions of these documents were presented and approved (see section 10).

After the meeting (during the first telco meeting of the Joint AHG on Gaussian splat coding), a Joint EE on Gaussian splat coding was agreed as follows:

Mandates

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: Solicit contributions related to encapsulation method implementation.

Mandate 5: Perform compression and complexity evaluation of the encapsulation/high-level syntax technologies.

Test Configurations

Test sequences: The evaluation should follow the GSC CTC on I-3DGS, using the pre-generated I-3DGS data.

Evaluation metrics: The evaluation metrics should be reported following the GSC CTC

Reporting template: JEE 6.9 requires participants to report the results using the provided Excel template in the GSC CTC.

Test condition: The test conditions should follow the GSC CTC Video-based anchor (1F/NF) track.

Note: The CTC can be found in document MDS26077 (WG 7 N 1414).

JVET members who have difficulty accessing this document can contact the JVET chair or VCEG Rapporteur for assistance.

Timeline / meetings

To be discussed during the regular Joint AhG calls (see section 9).

Participants of the JEE

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 0900UTC on 23 Jan., 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 23 Jan. 2026 at 1520–1600.

It was suggested to discontinue AHG8 by the time of finalization of the TR (April or July 2026). For AHG8 and the previous AHG16 (generative face), it is necessary to find a persistent home for the software.

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 392) 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 7 was responsible, at the next meeting, WG 4 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 to be updated during each meeting period, and the version valid during the upcoming meeting cycle can be found as:

JVET members who have difficulty accessing this document can contact the JVET chair or VCEG Rapporteur for assistance.

For accessing software, test materials and anchors, JVET members should contact the AHG chairs. Documents relevant for usage of SEI messages in Gaussian splat representation should be submitted both as WG 4 documents and JVET documents, such that JVET members who are participating via ITU also can get access.

It was anticipated to agree on a joint exploration experiment on topics related to the last three AHG mandates during the first interim AHG meeting on Feb 10. The result can be found in MDS26086, also described in section 8.2 of this report.

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 392, 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 389.