JVET-AQ0238 AHG9: On software availability and CTC results [B. Kroon (Philips), G. Teniou (Tencent), J. Boyce (Nokia), L. Kerofsky (Qualcomm)] [late]

This contribution proposes rules for software available and CTC results of JEE and TuC-related proposals on GS related SEI messages. The establishment of such rules had been requested to be suggested during the joint AHG meeting on 12 July.

The following modified text based on further editing the proposal in JVET-AQ0238v2 was agreed:

For EE inclusion, a contribution should normally provide:

1. a clear description of the proposed method;
2. identification of the affected part of VSEI: syntax, semantics, generation of SEI parameters and input to video encoder, reconstruction of GS from video decoder output;
3. software (source code);
4. CTC results (when the proposal affects coding efficiency), by giving a complete reporting as per template, including objective quality, complexity per encoder/decoder runtime;
5. enough information to reproduce the results, including software version, configurations, command lines, and test material;
6. an indication of whether and how the result can be cross-checked.

For TuC inclusion of proposals that do not impact coding performance under CTC, A contribution should provide:

1. complete proposed text of both syntax and semantics
2. commitment to collaborate on software integration with the software coordinator, potentially with negotiated editing period on issues found in the merge request;
3. software integration is handled by the software coordinator, with negotiated editing period, with support of proponents if multiple proposals are interacting;

For TuC inclusion of proposals that impact coding performance under CTC, the requirements should be stronger. A contribution should provide:

1. complete proposed text, when syntax, semantics, decoding, conformance, or reconstruction are affected;
2. software implemented in the VSEI reference software or an agreed branch by issuing a merge request;
3. commitment to collaborate on software integration with the software coordinator, potentially with negotiated editing period on issues found in the merge request;
4. CTC results on top of the applicable anchor (as per CTC or as defined in the JEE where the proposal was investigated);
5. at least one successful cross-check confirming the reported results;
6. a clear statement whether the proposal is to be enabled in CTC, integrated but disabled, included only for EE study, or included in the TuC.

As a general rule, positive discussion should not be sufficient for TuC inclusion if the required software, results, or cross-check are missing. In such cases, the outcome should normally be “further study,” with the missing evidence explicitly identified.

For training-dependent or implicit-representation proposals, the required software should include the complete pipeline needed to reproduce the coded representation and results, including training or model-generation steps when these affect the result.

For software-only or CTC/script changes, the contribution should show that the change is reproducible and should clearly state whether previous and new results remain comparable.

A possible compact rule could be:

A VSEI contribution that affects syntax, decoding, reconstruction, conformance, CTC results, or reference software operation should not be included in the TuC unless the corresponding text, software, CTC results, and appropriate cross-check evidence are available. For JEE inclusion, the same information is expected when applicable, but the group may allow earlier study inclusion if the missing items are explicitly identified.

Elements included in the TuC at prior meetings will be removed if the rules above are not followed, i.e. for elements included in JVET-AQ2032 this will apply in October.

• Review of CTC N 826 was conducted, and some wording improvement on definition of anchors, and results to be delivered by proponents (to make comparison against anchors useful) were made
• It was reported that proposals relating to V-PCC are mostly comparing against the V-PCC anchor, and the proposals relating to G-PCC are mostly comparing against the G-PCC anchor. Also here, the problem exists that V-PCC may perform better for some cases, and G-PCC for other.
• The question had been raised in the JAHG meeting whether it would be useful to also define specific anchor(s) for SEI-based proposals.

The following proposal was agreed for anchors in the exploration:- JVET-AP0100- V-PCC GS (as per definition from WG 7 Amd1 development)- G-PCC GS (as per definition from WG 7 Amd1 development)

All anchors would be including adoptions of the current meeting (From joint activity, or WG 7 in case of V-PCC and G-PCC).

Joint meeting session 2 (Tue. 14 July 1600-1800)

Agenda for Tuesday:

• Approve JAHG recommendations
• Review JEE6.1 for potential new test sequences in CTC
• Review mandates of next JAHG
• Remaining 6.7
• Review JEEs 6.3, 6.4, 6.5, 6.6, 6.2
• CfP discussion planned on Wednesday with AG 5

An initial version of the JAHG report M77135 (elements collected and available in git) was presented

Regarding JAHG recommendations, aspects on general principles have already been conducted in the joint meeting on Monday (CTC, rules of implementation, reporting, etc.), or will be further conducted in the current or subsequent joint meetings.

Regarding recommendations made by the AHG that relate to SEI contributions, better coordination should be implemented how this is reaching the SEI experts in JVET.

All recommendations related to proposals on SEI-based technology were agreed in the joint meeting, except for aspects of JVET-AQ0167. This relates to the integer implementation of operations in the reconstruction pipeline that are currently implemented in floating point representation, which however comes with a loss of 0.5% in the results presented in the proposal.

This does not have impact on the current syntax and semantics of GSI. As long as the reconstruction process is not defined to be normative, it might even be possible to do reconstruction either by integer and floating point processing. It was agreed to adopt this to the software (also in SEI anchor).

Another revisit was found necessary on JVET-AQ0168. This proposes a conversion of quantization and transform parameters to integer representation in the syntax. The loss reported for JVET-AQ0167 also includes already this modification (separate impact of the two changes is unknown).

It was agreed to include the changes of JVET-AQ0168 in JVET-AQ2032 (next TuC), and also implement in software.

JEE6.1:

Presentation of following documents:

m77290 A-3DGS Dynamic Representation Sequences Generated using FreeTimeGS Kelei Liu, Lu Yu, Yiyi Liao

Presented on Tuesday 14 July

Investigation on conversion between I-3DGS and A-3DGS for current test material, generated with FreeTimeGS. The latter produces more compact Gaussian splats (total number of Gaussians below is for 32 frames each). In Manwithfruit, some artifacts are visible at object boundaries.

m78033 360-degree multiview basketball dataset for Gaussian Splat Coding Chao Wang, Jiayu Yang, Song Xu, Qi Wang, Ronggang Wang

Presented on Tuesday

Sports scene from stadium, captured by 36 fixed cameras, 700 frames at 25 fps. Metadata such as camera parameters, as well as the original camera captures would also be available.

For consideration in CfP (not in CTC at this meeting)

It was asked to provide usage/licensing conditions in an update of the contribution

Joint AHG mandates were discussed by the end of the meeting of Tuesday. It was agreed to keep the existing mandates 1-12 unchanged. A mandate 13 was agreed to be added to “coordinate the software integration of the codecs under investigation.”

Furthermore, the list of output documents (all to be made available as WG 5 outputs in the dms.mpeg.expert) was agreed as follows, including some minor updates of titles of JEEs (no new EE was introduced), as well as editing periods.

Two more joint sessions were held on Wednesday 15 July 1600 and Thursday 16 July 1600, which from the perspective of JVET, after the closing of the JVET meeting, were already activities in the context of the Joint AHG. On behalf of JVET, these sessions were co-chaired by W. Husak. One major activity during these session was review of remaining documents submitted in the context of JEEs 6.1-6.6, as well as a one remaining document of JEE 6.7 (none of the reviewed documents related to study of SEI messages for Gaussian splats). The results of discussions during these sessions can be found in the JAHG report m77135.

Joint session 0830-0900 Tuesday 14 July on Joint Call for Proposals: MPEG WG 2 / Requirements, MPEG WG 5 / JVET, MPEG AG 5 Visual Quality Assessment, and ITU-T WP3/21)

This joint session was chaired by Jens-Rainer Ohm (JVET Chair and WG 5 Convenor), Justin Ridge WP3/21 Co-chair), Mathias Wien (AG 5 Convenor), and Igor Curcio (WG 2 Convenor).

This section is based on notes taken by JRO and Gary J. Sullivan (Q6/21 Rapporteur).

J. Ridge opened the meeting, mentioning that the meeting was requested by WP3/21, considering that the Joint CfP was planned to be issued as document by WP3/21.

M. Wien presented the latest draft of the CfP (JVET-AP2026v6 available as attachment in JVET-AQ0201).

It was discussed whether the selection of test model by October 2028 (as written in the timeline) would be not sufficiently ambitious, but as it is expressed as “at latest” and the timeline being tentative, that should not be a problem and not be changed.

It was discussed whether the statement about software availability would be sufficient, but as also the proposal description template contains a section where proponents need to unveil under which conditions their software would be available, and it is also expressed that it needs to be compatible with common patent policy and licensing rules imposed by ITU-T and ISO/IEC, this is asserted to be sufficient.

No issues were found in the presented document. The version presented should be prepared as output document JVET-AQ2021 and be delivered for final approval as WG 5 and WP3/21 documents.

Joint CfP to be approved in WP3/21 on Thursday.

Joint session 1535-1605 Tuesday 14 July on SEI messages for avatar coding: MPEG WG 5 / JVET, MPEG WG 3 Systems and MPEG WG 7 3D Graphics

This session was chaired by Jens-Rainer Ohm (JVET Chair and WG 5 Convenor), Marius Preda (WG 7 Convenor), and Thomas Stockhammer (on behalf of WG 3).

See notes under section 6.6.

BoGs (0)

Section kept as template for future use.

Liaison communications (3 incoming, 2 replies generated)

ISO/IEC JTC1/SC29/WG1-N101352 (SC29-N23183) LS on JPEG AI, also addressed to WG 5 as m78006

A draft response was presented by E. Alshina on Tuesday 14 July 0920-1000.

3GPP TSG SA4-S4-261360 LS on HEVC multi-layer profiles, chroma subsampling and bit depth combinations, also addressed to WG 5 as m77997

A draft response was presented by Y.-K. Wang on Tuesday 14 July 1000-1020.

Various further edits were made during the presentations of the drafts. The new versions of the documents were requested to be sent to JRO and GJS for further processing and forwarding for approval by SG21.

• The drafts were forwarded for further processing in Q6/21, and issued as follows:
• Liaison to JPEG on JPEG AI and explorations on video coding, included as item 1 in SG21 TD354/WP3
• Liaison to 3GPP SA4 on HEVC multi-layer profiles, chroma subsampling and bit depth combinations, included as item 2 in SG21 TD354/WP3

Another liaison statement m77998 was addressed to WG 5 via SC 29 by SMPTE on SEI messages (no corresponding communication via SG21). It was informally inspected, and concluded that it does not need a response.

(kept for future use) The liaison response was also presented by XXXX in the MPEG AG 3 Communication meeting on Thursday XXXX during 1500 – 1700.

Project planning

Software timeline

The NNVC 18.0 codebase software was planned to be available 2 weeks after the meeting (31 July). 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.

An initial update on top of HM18.0 should be generated for submission of the ISO/IEC CD 23008-5 3^rd within 2 weeks (July 31), integrating at least the elements for supporting new multiview profiles..

Further updates on top of HM18.0 and JM19.1 software were planned to be released later (integration and updates of SEI messages included in JVET-AN1018 and JVET-AN1017, and merging them with the new HEVC multiview software). Additional versions may be released as appropriate, also investigating the integration of full SHVC support in HM.

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

The exploration experiment on improved compression compared to VVC (EE2) had been discontinued by the 42^nd meeting. At the 43^rd meeting, the exploration experiment on neural network-based video coding (EE1) was discontinued as well.

Joint EEs on Gaussian splat technology are planned to be conducted within the Joint AHG. The proposals that are planned to be investigated are listed in the Joint AHG report JVET-AQ2019, as confirmed during joint meetings (see section 7.3.1). Technology related to SEI messages will be investigated in JEE 6.7 and JEE 6.9, based on common test conditions JVET-AQ2028. The JAHG was mandated to finalize the CTC document and the nine JEE descriptions during a telco on August 11, to be made available with an editing period until August 15 (description of JEEs which have relation to the investigation of performance and improvements of SEI messages will also be made available in JVET-AQ2040).

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 14 July, 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 Wednesday 15 July 2026 at 0905–1015.

As a follow-up of discussions conducted in previous meetings, it had been confirmed during the opening plenary on 7 July that it would be highly beneficial to make software that had been developed in various activities (AHGs, explorations conducted by JVET or previous joint teams, processing related to SEI messages, etc.) better visible, and potentially publicly available. It was suggested that a first step could be issuing a document which would summarize the existence of such JVET software assets, and indicate where these can be found. To take further action, it was agreed during the closing plenary on 15 July to establish a new AHG 6 on the topic of non-reference software assets, rather than making it an additional mandate of AHG3 (which is responsible for development of reference software).

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 418) 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 (discussed and approved 1050-1100 on Wednesday 15 July). The last mandate was added, other mandates are identical to those of the last meeting cycle. Dates of meetings require updates, and other WGs are free in nominating their co-chairs until the end of their respective meetings.

The definition of the Joint AHG was issued as WG 5 N 419.

It is noted that only one instance of the joint AHG is routinely installed over all MPEG WGs, and at the current meeting, JVET WG 5 was responsible, as well as for managing all input and output documents of 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/

For accessing software, test materials and anchors, JVET members should contact the AHG chairs. In the next meeting, WG 7 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 7 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 7 documents.

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

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 418, 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 417.