JVET-M0904 BoG report on neural networks for video coding [Y. Li, S. Liu]
This BoG report was presented in Track B on Thursday 17 January 1500-1815 (chaired by JRO).
This contribution provides the report of the BoG on neural networks (NN) for video coding, especially for neural network-based loop filtering. An information report (JVET-M0691) was discussed in this BoG, and then a CE plan.
The BoG recommended the following plan of a CE:
- Divide the 6 NN based loop filter methods into two categories and build two sub CE tests.
SubCE1 is the test for sequence-adaptive (two-pass) method, SubCE2 is the test for sequence-independent (one-pass) method.
- Investigate the impact of NN filter position in the filter chain.
Due to there being many test cases, only choose some cases to test, as defined below.
- For SubCE1:
anchor: DBF + SAO + ALF
case 1a: DBF + SAO + ALF + NN filter, which is the case currently subCE1 contributions used.
case 2a: NN filter. (optional test)
- For SubCE2:
anchor: DBF + SAO + ALF
case 1a: DBF + NN filter + SAO + ALF, which is the case that most of the contributions used.
case 2a: NN filter. (optional test)
case 3a: NN filter + ALF. (optional test)
- Investigate the benefit of the CTU/block level NN filter adaptive on/off.
Define some cases to test. To test this part, other parts should be fixed, e.g., using case 1a as the position set and case 1c as the QP set.
case 1b: make the NN filter adaptive on/off at CTU level.
case 2b: always use NN filter in one slice. (optional test)
- Investigate the performance of the NN filter when the test QP is not the same as the training QP.
Define some cases to test. To test this part, one should fix using case 1a and case 1b.
Using CTC QP (22, 27, 32, 37) for training and get the NN parameter.
case 1c: based on the NN parameter, use CTC QP for testing
case 2c: based on the NN parameter, use CTC QP + 2 for testing (24, 29, 34, 39) (optional test)
case 3c: based on the NN parameter, use CTC QP - 2 for testing (20, 27, 30, 35) (optional test)
- More detailed assignment of CE can be seen in tables provided in the BoG report.
The BoG recommended the following to be discussed.
- For subCE1, due to the online training, the NN parameter is not fixed. Thus, only providing the code in the inference stage is insufficient for others to use. (Although the parameter training/generation process is encoder only)
The proponent of Intel is willing to provide the training method, but not before the next meeting. The use of Tensorflow or other third-party framework in the common test conditions should be discuss in the track. Answer from the track: It may be useful if it is precisely described by which parameters a package like tensorflow is operated. An external optimization framework does not necessarily need to be part of our software package at the current stage of investigation.
- For subCE1, training process need GPU (using CPU is 10x slower), but the inference stage/second pass only use CPU. The training process is separated from the second pass. Currently, the encoding time listed in the table only includes the coding time for the second pass, and the training time is reported separately. Does it need to add the training time and second coding time for reporting? Or whether there is another better solution? Answer from the track: Should be reported, but not necessarily included in encoding time, as this would mix inhomogeneous computing platforms, and conclusions about the possibility of doing this in a meaningful amount of time can be drawn from separate reporting
An initial draft of a CE description was also included in the BoG report.
It was planned to run some of the tests only for short parts (e.g. one Intra refresh period). It was questioned whether this would give sufficient information; it was, however, planned to proceed like this for initial tests to identify configurations which will then be finally tested with entire sequences.
For the resulting CE plan, see JVET-M1033.
JVET-M0904 BoG report on neural networks for video coding [Y. Li, S. Liu]
See section 6.17.
List of actions taken affecting Draft 3 of VVC, VTM 3, and 360Lib
The following is a summary, in the form of a brief list, of the actions taken at the meeting that affect the text of the VVC draft text, VTM or 360Lib description. Both technical and editorial issues are included. This list is provided only as a summary – details of specific actions are noted elsewhere in this report and the list provided here may not be complete and correct. The listing of a document number only indicates that the document is related, not that it was adopted in whole or in part.
Category | Motivation | Modification | AI | RA | Document | Decision |
In-loop filters | ||||||
ALF | Fix | pcm_loop_filter_disabled_flag for ALF | 0.0% | 0.0% | Decision (BF/text): Include disabling ALF as a third loop filter when the pcm_loop_filter_disabled_flag is set, as suggested in JVET-M0277 | |
Deblocking | Subjective quality | Long deblocking | 0.1% | 0.0% | Decision: Adopt JVET-M0471, version 11.1.8 (specification text available in v2 upload, but needs another small modification for restriction of line buffer, was shortly reviewed in track B Thursday 17 January 1330), pending on confirmation from the viewing, and the more detailed report on complexity impact | |
Deblocking | Subjective quality | Deblocking of CIIP boundaries | combination of JVET-M0103 and JVET-M0294 | |||
Reconstruction | Coding efficiency | Picture reconstructon with mapping | -0.9% | -1.3% | Decision: Adopt (modified as noted). | |
Intra | ||||||
Prediction mode | Coding efficiency | Intra subpartitions | -0.6% | -0.3% | Decision: Adopt 1.1.1 proposal, pending the provision of text and its review. | |
CCLM | Coding efficiency (HDR) | Modified CCLM downsampling filter | 0.0% | 0.0% | Decision: Adopt 2.4.c with a high-level flag to switch between two chroma format type optimizations (pending test results for applying the type 2 scheme to type 0 content). | |
CCLM | Simplification | Table reduction in CCLM modelling | 0.0% | 0.0% | Decision: Adopted | |
Prediction | Cleanup | Harmonize the ref sample filtering | Editorial action item: Agreed | |||
PDPC | Simplification | Simplified linear interpolation | 0.0% | 0.0% | Decision: Adopted | |
CPR | Coding efficiency (SCC) | Reference sample memory reuse | Decision: Adopt JVET-M0407 (variant a) | |||
CPR | Cleanup | CPR signalling - interaction with inter tools | Decision: Adopt JVET-M0483 (text in zip v4, “r1”, probably needs some more update along the lines above) | |||
Transform | ||||||
MTS | Complexity reduction | Fast DST-7/DCT-8 | 0.0% | 0.0% | Decision (complexity reduction): Adopt CE6-2.3a. | |
MTS | Complexity reduction | 32-length DST-7/DCT-8 using zero-out | 0.1% | 0.0% | Decision: Adopt JVET-M0297 Test 2. | |
MTS/TS | Simplification + coding efficiency (SCC) | Unifed MTS/TS syntax + TS up to 32x32 | 0.0% | 0.0% | Decision: Adopt transform skip up to 32x32, with associated syntax approach in JVET-M0464 using tu_mts_idx. And enable TS in CTC for all test sequences. | |
TU partitioning | Coding efficiency | Sub-block Transform (SBT) for inter blocks | -0.5% | Decision (coding efficiency): Adopt CE6-4.1a (pending the test results of avoiding 32-point DST). The same high-level flag as used for CE6-3.1b is to be used to determine whether DCT2 is used always or not and also applies to CE3-1.1.1. | ||
DCT2 | Fix (editorial) | Ticket #135: Downsampling of the DCT2 transform matrix should be separate horizontally and vertically (not assumed square) | Decision (BF editorial): The downsampling of the DCT2 transform matrix should be separate horizontally and vertically (not assumed square) for #135. | |||
Quantization | ||||||
QP | Fix | Bug fix for quantization group QP signalling | Decision: Adopt (text in JVET-M0113). | |||
QP | Fix | QP Prediction fix for parallel encoding | Decision: Initialize QP from the bottom left CU of the above CTU row when decoding the first CU of a CTU on the left edge of a tile group | |||
Scaling | Fix | Modified dequantization scaling for TS | Decision (bug fix): Adopt. | |||
CABAC | ||||||
Contexts | Complexity reduction | Reduce merge idx ctx coded bins | 0.0% | Decision: Adopt JVET-M0381 Test 2.2.2a (reducing number of context coded bins in affine merge). Text is available with the contribution. | ||
Contexts | Coding efficiency | 1 additional context for pred_mode_flag | -0.1% | Decision: all the suggested adoptions are confirmed by trackB. (Method 2) | ||
Engine | Coding efficiency | Probability estimation | -1.0% | -1.0% | Decision: adopt “5.1.13* +new init from 5.1.2” | |
Residual Coding | Complexity reduction | rem_abs_gt3_flag in first coding pass | -0.1% | -0.1% | Decision (complexity reduction): Adopt CE7.4. | |
Residual Coding | Fix | Limited EGk for abs_rem/ dec_abs_level | 0.0% | 0.0% | Decision (BF): Adopt JVET-M0470. | |
Residual Coding | Fix | Last position coding for large block-size transforms | Decision (BF): Adopt JVET-M0251/JVET-M0257 (software from JVET-M0257). | |||
Inter | ||||||
SBTMVP | Complexity reduction | Only using left neighbour for SbTMVP | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
Affine | Coding efficiency | AMVR for affine | -0.2% | Decision: Adopt JVET-M0246 (Test 2.1.2), extending AMVR to affine. Use the AMVR high level flag for disabling both “normal” AMVR and “affine” AMVR. | ||
Affine merge | Cleanup | Affine sub-block MV clipping | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
Affine merge | Complexity reduction | Remove MV comparison | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. JVET-M0166 (change 2)/ JVET-M0228 (modification 1)/ JVET-M0477(change 2) | ||
Merge | Fix | Fix for cu_cbf when merge | Decision: Agreed in Track A review – this was just an error in drafting the text. | |||
Merge | Complexity reduction | Parallel processing for merge mode | 0.0% | Decision: Adopt JVET-M0170 (type 2, draft text “…type2sharing” of Jan. 12) | ||
Merge | Complexity reduction | Pairwise Average Candidate Reduction | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
Merge/AMVP | Complexity reduction | Rounding before any MV pruning | 0.0% | Decision: Adopt JVET-M0281 (subtest 4.1.5a) | ||
AMVP | Complexity reduction | MVP candidate list generation for AMVP | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
HMVP | Cleanup | Reduce HMVP number from 6 to 5 | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
HMVP | Complexity reduction | HMVP and parallel processing with tiles | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
HMVP | Cleanup | GBi weight is also stored in HMVP | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
HMVP | Simplification | HMVP candidate pruning | 0.0% | Decision: Adopt JVET-M0126 version 4.1.2.4 (text is available, but needs to be reduced reflect that only this aspect is changed. | ||
BDOF | Complexity reduction | Integer positions in extended region | 0.1% | Decision: Adopt JVET-M0487 (solution 9.1.1.b) | ||
BDOF | Fix | Generalization of BDOF bit-depth | 0.0% | Decision (BF): Adopt JVET-M0063. | ||
MMVD | Coding efficiency (SCC) | MMVD w/o Fractional Distances for SCC | -0.1% | Adopt the approach of not signalling the triangular prediction mode flag in cases where the combination is not allowed (MMVD, CIIP) – various contributions on that, gives 0.07%. | ||
MMVD | Cleanup | Harmonize MV scaling | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
MMVD | Fixes/cleanup | M0068+Forbid 4*4 bi + align SW with WD | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
MVD | Coding efficiency | Symmetrical MVD coding for L0 to L1 | -0.3% | Decision: all the suggested adoptions are confirmed by trackB. | ||
WP | fixes/cleanup | Disable GBI signalling when WP is enabled | Decision: all the suggested adoptions are confirmed by trackB. | |||
MV | cleanup | Clip MVs to 18 bits | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
MV | Complexity reduction | TMVP Storage Reduction | 0.0% | Decision: Adopt JVET-M0512 second aspect as described in notes | ||
MV | Complexity reduction | Sub-block MV derivation for chroma | 0.0% | Decision: all the suggested adoptions are confirmed by trackB. | ||
DMVR | Coding efficiency | DMVR | -1.1% | Decision: Adopt JVET-M0147 with SAD cost function, and without the MVD based early termination check. | ||
Triangular | Simplification | -0.1% | 1. Adopt syntax change of JVET-M0118: Same as in JVET-M0185, JVET-M0190, JVET-M207 (test 1), JVET-M0216 (the first aspect), JVET-M0234 (change corresponding to the result table 7 and 8), JVET-M0317 (section 2.2), JVET-M0328 (test E). This does not signal the triangular prediction mode flag in cases where the combination is not allowed (MMVD, CIIP). Approx. 0.07% rate reduction | |||
Triangular | Simplification | 0.0% | 2. Adopt using only weight group (second weight as in JVET-M0328). The weighting is currently dependent on comparing MVs of the two partitions, loss approx. 0.01% for RA, 0.03% for LB, also simplifies the spec. | |||
Triangular | Simplification | 0.0% | 4. Adopt signalling change of triangular merging candidate which does not need LUT (JVET-M0883). This is a combination from various proposals. Does not change merge list construction, simplifies the specification, and gives tiny gain (0.01% both for RA and LB) | |||
Partitioning | ||||||
Cleanup | inferred QT split to avoid 32x128/128x32 partitions at picture boundaries | 0.1% | Decision (cleanup/consistency): Adopt inferred QT split to avoid 32x128/128x32 partitions at picture boundaries (0.06% penalty in RA configuration). | |||
Cleanup | Split-first signalling for partitioning | Decision: adopt | ||||
High-level syntax | ||||||
Picture referencing | Simplification | RPL-based reference picture management | Decision: Adopt with modifications as described in notes | |||
Replace IRAP_NUT with 3 new NAL unit types: IDR_W_RADL, IDR_N_LP, CRA_NUT | ||||||
Add external means flag HandleCraAsCvsStartFlag | ||||||
Add a NUT value for STSA and AUD | ||||||
Add sps_max_sub_layers_minus1 syntax element to SPS, and decoding process in 8.1.1, 8.1.2 and 8.1.3 of JVET-M0101 | ||||||
Add profile_tier_level( ) syntax structure which includes sub layer level idc | ||||||
Add general_non_packed_constraint_flag with semantics as in JVET-M0101 | ||||||
Add the temporal scalability sub-bitstream extraction process in JVET-M0101 | ||||||
Change the sps_ref_wraparound_offset to sps_ref_wraparound_offset_minus1 and changing the units to be MinCbSizeY, subject to review by the 360° BoG | ||||||
Add 7 new constraint flags corresponding to VVC WD 3 tools as described in JVET-M0451 | ||||||
Add reference picture signalling from JVET-M0128 (basic text version) – modified after Track A discussion as described in the notes for that document | ||||||
Decision: Add RASL and RADL NUTs | ||||||
Tiles and WPP | Decision: Adopted, with constraints as in notes | |||||
Decision: Adopt an adaptation parameter set (APS) to carry ALF parameters. The tile group header contains an aps_id which is conditionally present when ALF is enabled. The APS contains an aps_id and the ALF parameters. A new NUT value is assigned for APS (from JVET-M0132). For the CTC, we will just use aps_id = 0 and send the APS with each picture. For now, the range of APS ID values will be 0..31 and APSs can be shared across pictures (and can be different in different tile groups within a picture). The ID value should be fixed-length coded when present. ID values cannot be re-used with different content within the same picture. | ||||||
Add loop_filter_across_tile_group_enabled_flag to the PPS | Decision: Adopted (confirmed Thursday morning plenary). | |||||
Software & CTC | ||||||
Intra prediction | Fix | Ticket #132: Mismatch between spec and software in the order of syntax elements | Decision (SW): A software fix was needed for #132. | |||
Motion search | Coding efficiency (SCC) | Hash-based Motion Search for SCC | 0.0% | 0.0% | Decision (SW): Adopt JVET-M0253 | |
Subblock merge | Fix | Mismatch between text specification and reference software on ATMVP candidate derivation when CPR is enabled | 0.0% | 0.0% | Decision (SW/BF): Adopt JVET-M0409 (align software with text) | |
MV | Fix | Clean-up on MV Rounding | 0.0% | 0.0% | Decision (BF/consistency): Adopt rounding away from zero for MV averages. | |
MMVD | Coding efficiency | MMVD improvement | -0.1% | Decision (SW): Adopt JVET-M0823, also CTC | ||
PCM | Coding efficiency/fixes | SAO/ALF | 0.0% | 0.0% | Decision (BF/SW): Disable SAO and ALF in chroma part when dual tree is used and the flag is set, and disable ALF in luma part when dual tree is used and the flag is set, as suggested in JVET-M0277 | |
Partitioning | Coding efficientcy | Encoder optimization for RDO | 0.0% | 0.0% | Decision (SW): Adopt JVET-M0428, not for CTC (-0.6% -0.7%) | |
Tiles | Encoder motion constraints for MCTSs | Decision (SW): Adopted | ||||
AMVR | Affine motion estimation for affine AMVR+C94 | -0.1% | Decision: all the suggested adoptions are confirmed by trackB. | |||
Affine merge | Increasing the amount of RD checking for affine merge mode coding | -0.1% | Decision: all the suggested adoptions are confirmed by trackB. | |||
Analysis | Functionality | Enhancement of the tool to measure the memory bandwidth in VTM | Decision (SW): Adopt JVET-M0864 memory bandwidth analysis method. | |||
Functionality | VTM transcoding capabilities | Decision (SW): adopt, usage should be documented in VTM SW package | ||||
Quantization | Functionality | Clean-up of perceptually optimized QP adaptation | Decision (SW): Adopt | |||
Quantization | Fix (CTC) | Rebalance luma-vs.-chroma QP setting | -1.0% | Decision (CTC): Adopt | ||
Rate control | Functionality | Bug fix for rate control | Decision (SW): Adopt | |||
Functionality | Quality dependency factor based rate control | Decision (SW): Adopt | ||||
Adopt Hemisphere CMP and Hemisphere EAC projection formats (from JVET-M0452) | ||||||
Modify chroma sample location in blending process for PHEC (from JVET-M0368) – basically a bug fix | ||||||
Overall (CTC) ex Class F & SCC | -2.4% | -6.2% |
Project planning
Core experiment planning
Core experiment plans were established, and initial drafts of the CE plans were reviewed in the closing sessions.
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 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:
- No review of normative contributions without draft specification text
- VTM algorithm description text is strongly encouraged for non-normative contributions
- Early upload deadline to enable substantial study prior to the meeting
- Using a clock timer to ensure efficient proposal presentations (5 min) and discussions
The document upload deadline for the next meeting was planned to be Tuesday 12 March 2019.
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 during the opening plenary on January 9 that those rules which had been set up or refined during the 12th meeting should be observed. In particular, for some CEs, results had been available late, and some changes in the experimental setup (particularly in CE4) had not been 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 the draft standard by the next meeting.
- 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 have read access to the CE software branches (using shared read-only credentials; one account has been set up to use the usual shared WG 11 credentials and another is set up for SG 16 members with credentials shared in the TIES system at the location https://www.itu.int/ifa/t/2017/sg16/exchange/wp3/q06/vceg_account.txt).
- During the experiment, revisions of the experiment plans can be made, but not substantial changes to the proposed technology.
- 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 plan.
- 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). The reports of cross-checking activities may (and generally should) be integrated into the CE report rather than submitted as separate documents.
It is possible to define sub-experiments within particular CEs, for example designated as CE9-2.3a, CE9-2.3b, etc., for subtests 2.3a and 2.3b in CE9.
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 are described in the output document JVET-M1010.
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”, 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.
Some agreements relating to CE activities were established as follows:
- Only qualified JVET members can be identified participants in a CE.
- Participation in a CE is possible without a commitment of submitting an input document to the next meeting. Participation is 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.
- All substantial communications about a CE, other than logistics arrangements, exchange of data, minor refinement of the test plans, and preparation of documents shall be conducted on the main JVET reflector. In the case that large amounts of data are to be distributed is recommended to send an announcement to the JVET reflector without attaching the materials, and send the materials to those who have requested it directly, or provide a link to it, 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.
T2 = Test model software release + 2 weeks or 4 March, whichever is earlier: 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 and announced on the JVET reflector. The name of the cross-checkers and list of specific tests for each tool under study in the CE plan description by this time. Full test results must be provided at this time (at least for proposals targeting to be promoted to the draft standard at the next meeting).
CE reports may contain additional information about tests of straightforwared 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, we would like see comprehensive cross-checking done, with analysis that the description matches the software, and recommendation of value of the tool 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.
Draft specification text shall be provided with CE input documents. Availability of spec text is important to have a detailed understanding of the technology and also to judge what its impact on the complexity of the spec will be. There must also be sufficient time to study it in detail. CE contributions without sufficiently mature draft spec text in the CE input document (available by the time of the document deadline) should not be considered for adoption. Furthermore, CE contribution documents should be complete and not make it necessary to open old documents to understand the technology.
Plans for the CEs to be conducted were established Thursday 18 January (chaired by GJS); CE plan documents were reviewed Friday 19 January (GJS & JRO).
Lists of participants in CE documents should be pruned to include only the active participants. Read access to software is available to all members.
Software development and anchor generation
The planned timeline for software releases was established as follows:
- VTM4.0 will be released by 2019-02-11. VTM4.1 with non-CTC adoptions will be released later. (If necessary, VTM4.0 may not include final tuning of context initialization values.)
- Further versions of VTM may be released for additional bug fixing, as appropriate.
- Preparation of the VTM software will include immediate removal of macros that were added in the previous meeting cycle. The software coordinator has the discretion to retain some such macros.
- Timeline of 360lib9.0: 1 week after the release of VTM4.0 (2019-02-18). Further versions may be released as appropriate for bug fixing.
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).
Title and Email Reflector | Chairs | Mtg |
Project Management (AHG1)
| J.-R. Ohm, G. J. Sullivan (co-chairs) | N |
Draft text and test model algorithm description editing (AHG2)
| B. Bross, J. Chen (co-chairs), J. Boyce, S. Kim, S. Liu, Y. Ye (vice-chairs) | N |
Test model software development (AHG3)
| F. Bossen, X. Li, A. Norkin, K. Sühring (co-chairs) | N |
Test material and visual assessment (AHG4)
| T. Suzuki (chair), V. Baroncini, R. Chernyak, P. Hanhart, A. Norkin, J. Ye (vice-chairs) | N |
Memory bandwidth consumption of coding tools (AHG5)
| R. Hashimoto (chair), T. Ikai, X. Li, D. Luo, H. Yang, M. Zhou (vice-chairs) | N |
360° video conversion software development (AHG6)
| Y. He, K. Choi (co-chairs) | N |
Coding of HDR/WCG material (AHG7)
| A. Segall (chair), E. François, W. Husak, D. Rusanovskyy (vice-chairs) | N |
360° video coding tools and test conditions (AHG8)
| J. Boyce (chair), K. Choi, P. Hanhart, J.-L. Lin (vice-chairs) | N |
Neural networks in video coding (AHG9)
| S. Liu (chair), B. Choi, K. Kawamura, Y. Li, L. Wang, P. Wu, H. Yang (vice-chairs) | N |
Encoding algorithm optimization (AHG10)
| A. Duenas, A. Tourapis (co-chairs), C. Helmrich, S. Ikonin, A. Norkin, R. Sjöberg, T. Toma (vice-chairs) | N |
Screen content coding (AHG11)
| S. Liu (chair), J. Boyce, A. Filippov, Y.-C. Sun, J. Xu, M. Zhou (vice-chairs) | N |
High-level parallelism and coded picture regions (AHG12)
| S. Deshpande (chair), M. M. Hannuksela, R. Sjöberg, R. Skupin, W. Wan, Y.-K. Wang S. Wenger (vice-chairs) | N |
Tool reporting procedure (AHG13)
| W.-J. Chien, J. Boyce (co-chairs), Y.-W. Chen, R. Chernyak, K. Choi, R. Hashimoto, Y.-W. Huang, H. Jang, S. Liu, D. Luo (vice-chairs) | N |
Progressive intra refresh (AHG14)
| J.-M. Thiesse (chair), A. Duenas, K. Kazui, R. Sjöberg, A. Tourapis (vice-chairs) | N |
Bitstream decoding properties signalling (AHG15)
| J. Boyce (chair), J. Chen, S. Deshpande, M. Karczewicz, A. Tourapis, Y.-K. Wang, S. Wenger (vice-chairs) | N |
Implementation studies (AHG16)
| M. Zhou (chair), J. An, E. Chai, K. Choi, S. Ethuraman, T. Hsieh, X. Xiu (vice-chairs) | N |
High-level syntax (AHG17)
| R. Sjöberg (chair), S. Deshpande, M. M. Hannuksela, R. Skupin, Y.-K. Wang, S. Wenger, H. Yu (vice-chairs) | N |
Quantization control (AHG18)
| R. Chernyak (chair), E. François, C. Helmrich, A. Segall (vice-chairs) | N |
Layered coding and resolution adaptivity (AHG19)
| S. Wenger and A. Segall (co-chairs), M. M. Hannuksela, Hendry, S. McCarthy, Y.-C. Sun (vice-chairs) | N |
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 MPEG output document, a separate version under the MPEG document header should be generated. This version should be sent to GJS and JRO for upload.