JVET-M Notes DF

Joint Video Experts Team (JVET)
Document: JVET-M_Notes_dFE
of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11
13th Meeting: Marrakech, MA, 9–18 Jan. 2019
Title: Meeting Report of the 13th Meeting of the Joint Video Experts Team (JVET),
Marrakech, MA, 9–18 January 2019
Status: Report document from the chairs of JVET
Purpose: Report
Author(s) or Gary Sullivan
Contact(s): Microsoft Corp. Tel: +1 425 703 5308
1 Microsoft Way Email: garysull@microsoft.com
Redmond, WA 98052 USA
Jens-Rainer Ohm
Institute of Communication Engineering Tel: +49 241 80 27671
RWTH Aachen Email: ohm@ient.rwth-aachen.de
Melatener Straße 23
D-52074 Aachen
Source: Chairs of JVET
_____________________________
1 Summary
The Joint Video Experts Team (JVET) of ITU-T WP3/16 and ISO/IEC JTC 1/ SC 29/ WG 11 held its
thirteenth meeting during 9–18 January 2019 at the Palais des Congrès Mogador (Tourist Zone Agdal,
40000, Marrakech, Morocco, Tel: + 212 530 530 530). The JVET meeting was held under the
chairmanship of Dr Gary Sullivan (Microsoft/USA) and Dr Jens-Rainer Ohm (RWTH Aachen/Germany).
For rapid access to particular topics in this report, a subject categorization is found (with hyperlinks) in
section 2.13 of this document. It is further noted that the unabbreviated name of JVET was formerly
known as “Joint Video Exploration Team”, but the parent bodies modified it when entering the phase of
formal development of a new standard. The name Versatile Video Coding (VVC) was chosen in April
2018 as the informal nickname for the new standard.
The JVET meeting began at approximately 0910 hours on Wednesday 9 January 2019. Meeting sessions
were held on all days (including weekend days) until the meeting was closed at approximately 1318 hours
on Friday 18 October 2019. Approximately 268 people attended the JVET meeting, and approximately
830 input documents, 17 AHG reports, and 13 CE summary reports were discussed. The meeting took
place in a collocated fashion with a meeting of WG11 – one of the two parent bodies of the JVET. The
subject matter of the JVET meeting activities consisted of developing video coding technology with a
compression capability that significantly exceeds that of the current HEVC standard, or otherwise gives
better support regarding the requirements of future application domains of video coding. As a primary
goal, the JVET meeting reviewed the work that was performed in the interim period since the twelfth
JVET meeting in producing a third draft of the VVC standard and the third version of the associated VVC
test model (VTM). Further important goals were reviewing the results of 13 Core Experiments (CE),
reviewing other technical input on novel aspects of video coding technology, and producing the next
versions of the VVC draft text and VTM, and plan next steps for further investigation of candidate
technology towards the formal standard development.
The JVET produced 18 output documents from the meeting:
 JVET-M1001 Versatile Video Coding specification text (Draft 4)
 JVET-M1002 Algorithm description for Versatile Video Coding and Test Model 4 (VTM 4)
Page: 1 Date Saved: 2019-03-172019-03-14

 JVET-M1004 Algorithm descriptions of projection format conversion and video quality metrics
in 360Lib (Version 9)
 JVET-M1006 Methodology and reporting template for coding tool testing and for neural network
tool testing
 JVET-M1010, JVET-L1011, and JVET-L1012 JVET common test conditions and software
reference configurations for SDR, HDR/WCG, and 360° video
 JVET-M1021 through JVET-M1033, Description of Core Experiments 1 through 13
For the organization and planning of its future work, the JVET established 19 “ad hoc groups” (AHGs) to
progress the work on particular subject areas. At this meeting, 13 Core Experiments (CE) were defined.
The next four JVET meetings were planned for 19–27 March 2019 under ITU-T SG16 auspices in
Geneva, CH, during 3–12 July 2019 under WG 11 auspices in Gothenburg, SE, during 1–9 October 2019
under ITU-T SG16 auspices in Geneva, CH, and during 8–17 January 2020 under WG 11 auspices in
Brussels, BE.
The document distribution site http://phenix.it-sudparis.eu/jvet/ was used for distribution of all
documents.
The reflector to be used for discussions by the JVET and all its AHGs is the JVET reflector:
jvet@lists.rwth-aachen.de hosted at RWTH Aachen University. For subscription to this list, see
https://mailman.rwth-aachen.de/mailman/listinfo/jvet.
2 Administrative topics
2.1 Organization
The ITU-T/ISO/IEC Joint Video Experts Team (JVET) is a group of video coding experts from the ITU-
T Study Group 16 Visual Coding Experts Group (VCEG) and the ISO/IEC JTC 1/SC 29/WG 11 Moving
Picture Experts Group (MPEG). The parent bodies of the JVET are ITU-T WP3/16 and ISO/IEC
JTC 1/SC 29/WG 11.
The Joint Video Experts Team (JVET) of ITU-T WP3/16 and ISO/IEC JTC 1/SC 29/WG 11 held its
thirteenth meeting during 9–18 January 2019 at the Palais des Congrès Mogador (Tourist Zone Agdal,
40000, Marrakech, Morocco, Tel: + 212 530 530 530). The JVET meeting was held under the
chairmanship of Dr Gary Sullivan (Microsoft/USA) and Dr Jens-Rainer Ohm (RWTH Aachen/Germany).
It is further noted that the unabbreviated name of JVET was formerly known as “Joint Video Exploration
Team”, but the parent bodies modified it when entering the phase of formal development of a new
standard. The name Versatile Video Coding (VVC) was chosen in April 2018 as the informal nickname
for the new standard.
2.2 Meeting logistics

Information regarding logistics arrangements for the meeting had been provided via the email reflector
jvet@lists.rwth-aachen.de and at http://wftp3.itu.int/av-arch/jvet-site/2019_01_M_Marrakech/.
2.3 Primary goals

As a primary goal, the JVET meeting reviewed the work that was performed in the interim period since
the twelfth JVET meeting in producing a third draft of the VVC standard and the third version of the
associated VVC test model (VTM). Further important goals were reviewing the results of 13 Core
Experiments (CE), reviewing other technical input on novel aspects of video coding technology, and
producing the next versions of draft text and VTM, and plan next steps for further investigation of
candidate technology towards the formal standard development.
Page: 2 Date Saved: 2019-03-172019-03-14

2.4 Documents and document handling considerations
2.4.1 General
The documents of the JVET meeting are listed in Annex A of this report. The documents can be found at
http://phenix.it-sudparis.eu/jvet/.
Registration timestamps, initial upload timestamps, and final upload timestamps are listed in Annex A of
this report.
The document registration and upload times and dates listed in Annex A and in headings for documents in
this report are in Paris/Geneva time. Dates mentioned for purposes of describing events at the meeting
(other than as contribution registration and upload times) follow the local time at the meeting facility.
Highlighting of recorded decisions in this report is practised as follows:
 Decisions made by the group that might affect the normative content of a future standard are
identified in this report by prefixing the description of the decision with the string “Decision:”.
 Decisions that affect the VTM or BMS software but have no normative effect are marked by the
string “Decision (SW):”.
 Decisions that fix a “bug” in the VTM description (an error, oversight, or messiness) or in the
software are marked by the string “Decision (BF):”.
This meeting report is based primarily on notes taken by the JVET chairs. The preliminary notes were
also circulated publicly by ftp and http during the meeting on a daily basis. It should be understood by the
reader that 1) some notes may appear in abbreviated form, 2) summaries of the content of contributions
are often based on abstracts provided by contributing proponents without an intent to imply endorsement
of the views expressed therein, and 3) the depth of discussion of the content of the various contributions
in this report is not uniform. Generally, the report is written to include as much information about the
contributions and discussions as is feasible (in the interest of aiding study), although this approach may
not result in the most polished output report.
2.4.2 Late and incomplete document considerations

The formal deadline for registering and uploading non-administrative contributions had been announced
as Wednesday, 2 January 2019. Any documents uploaded after 1159 hours Paris/Geneva time on
Thursday 3 January were considered “officially late”, giving a grace period of 12 hours to accommodate
those living in different time zones of the world. The deadline does not apply to AHG reports, CE
summaries, and other such reports which can only be produced after the availability of other input
documents.
All contribution documents with registration numbers JVET-M0535 and higher were registered after the
“officially late” deadline (and therefore were also uploaded late). However, some documents in the
“M0535+” range might include break-out activity reports that were generated during the meeting, and are
therefore better considered as report documents rather than as late contributions. Also, many cross-check
reports were uploaded late.
In many cases, contributions were also revised after the initial version was uploaded. The contribution
document archive website retains publicly accessible prior versions in such cases. The timing of late
document availability for contributions is generally noted in the section discussing each contribution in
this report.
One suggestion to assist with the issue of late submissions was to require the submitters of late
contributions and late revisions to describe the characteristics of the late or revised (or missing) material
at the beginning of discussion of the contribution. This was agreed to be a helpful approach to be
followed at the meeting.
Page: 3 Date Saved: 2019-03-172019-03-14

The following technical design proposal contributions were registered and/or uploaded late:qq
 JVET-M0155 (a proposal on tile group identification…), uploaded 01-03.
 JVET-M0156 (a proposal on component type identification…), uploaded 01-03.
 JVET-M0157 (a proposal on picture order count…), uploaded 01-03.
 JVET-M0228 (a proposal on subblock motion compensation…), uploaded 01-03.
 JVET-M0235 (a proposal on 360° projection with rotation…), uploaded 01-03.
 JVET-M0245 (a proposal on chroma block coding complexity…), uploaded 01-04.
 JVET-M0320 (a proposal on 360° projection …), uploaded 01-04.
 JVET-M0321 (a proposal on 360° video seam artefacts…), uploaded 01-04.
 JVET-M0322 (a proposal on 360° video projection map discontinuities…), uploaded 01-04.
 JVET-M0323 (a proposal on using adaptive QP for 360° coding…), uploaded 01-05.
 JVET-M0351 (a proposal on a neural network filter for intra coding…), uploaded 01-03.
 JVET-M0360 (a proposal on cross-RAP referencing for video streaming…), uploaded 01-04.
 JVET-M0369 (a proposal on syntax for merge data…), uploaded 01-04.
 JVET-M0378 (a proposal on reference picture set syntax…), uploaded 01-03.
 JVET-M0387 (a proposal on low-delay intra refresh…), uploaded 01-11.
 JVET-M0396 (a proposal on multiple transform selection memory complexity…), uploaded 01-
03.
 JVET-M0424 (a proposal on wordlength for interpolation filtering…), uploaded 01-12.
 JVET-M0452 (a proposal on hemisphere cubemap projection…), uploaded 01-03.
 JVET-M0510 (a proposal on a neural network based loop filter…), uploaded 01-09.
 JVET-M0530 (a proposal on signalling for tiles…), uploaded 01-04.
 JVET-M0534 (a proposal on 360° video with rotation and frame packing…), uploaded 01-03.
 JVET-M0536 (a proposal on tile structures at the picture and sequence level…), uploaded 01-03.
 JVET-M0537 (a proposal on tile groups with motion-constrained tile sets…), uploaded 01-03.
 JVET-M0538 (a proposal on multiple transform sets…), uploaded 01-03.
 JVET-M0539 (a proposal on multiple transform sets…), uploaded 01-05.
 JVET-M0541 (a proposal on MMVD with CPR mode…), uploaded 01-03.
 JVET-M0542 (a proposal on multi-hypothesis intra with CPR mode…), uploaded 01-03.
 JVET-M0544 (a proposal on CPR with 4x4 chroma and dual tree coding…), uploaded 01-03.
 JVET-M0547 (a proposal on 360° video with uncoded areas…), uploaded 01-03.
 JVET-M0558 (a proposal on template-based Rice parameter derivation…), uploaded 01-04.
 JVET-M0566 (a proposal on an adaptive convolutional neural network loop filter…), uploaded
01-05.
 JVET-M0581 (a proposal on bidirectional MV storage for triangular prediction…), uploaded 01-
04.
Page: 4 Date Saved: 2019-03-172019-03-14

 JVET-M0634 (a proposal on an affine motion mode for intra coding…), uploaded 01-06.
 JVET-M0640 (a proposal on in-loop “reshaping” with approximate inverse mapping function…),
uploaded 01-07.
 JVET-M0661 (a proposal on merge list size…), uploaded 01-07.
 JVET-M0685 (a proposal on quantization parameter prediction…), uploaded 01-07.
 JVET-M0713 (a proposal on a proposed simplification of a CE subtest on inter prediction…),
uploaded 01-08.
 JVET-M0725 (a proposal on arithmetic coding CE testing…), uploaded 01-08.
 JVET-M0727 (a proposal on an arithmetic coding CE test…), uploaded 01-08.
 JVET-M0736 (a proposal on triangular prediction…), uploaded 01-09.
 JVET-M0765 (a proposal on current picture referencing with multiview frame packing…),
uploaded 01-09.
 JVET-M0772 (a proposal on context model initialization for arithmetic coding CE tests…),
uploaded 01-09.
 JVET-M0783 (a proposal on modification of intra MPM list order…), uploaded 01-10.
 JVET-M0792 (a proposal on multi-hypothesis inter prediction and OBMC …), uploaded 01-11.
 JVET-M0799 (a proposal on bit-width reduction in CCLM derivation and prediction …),
uploaded 01-10.
 JVET-M0814 (a proposal on block size restriction on PDPC…), uploaded 01-11.
 JVET-M0815 (a proposal on MPM list derivation for intra prediction…), uploaded 01-11.
 JVET-M0832 (a proposal on block size restrictions for PDPC with disabled linear filtering for
PDPC in skew non-diagonal modes…), uploaded 01-11.
 JVET-M0838 (a proposal on combined testing of schemes with multi-hypothesis prediction and
combined intra and inter prediction…), uploaded 01-11.
 JVET-M0839 (a proposal on the number of fast merge candidates for affine merge mode…),
uploaded 01-11.
 JVET-M0848 (a proposal on speedups for uniform directional diffusion filters …), uploaded 01-
12.
 JVET-M0851 (a proposal on u…sing inter merge list derivation for triangle mode), uploaded 01-
12.
 JVET-M0853 (a proposal on tile grouping…), uploaded 01-12.
 JVET-M0854 (a proposal on combining techniques in inter prediction…), uploaded 01-12.
 JVET-M0870 (a proposal on testing a scheme for subpicture handling with motion-constrained
tile sets…), uploaded 01-13.
 JVET-M0872 (a proposal on …a convolutional neural network filter), uploaded 01-13.
 JVET-M0875 (a proposal on flexible tile size…), uploaded 01-13.
 JVET-M0878 (a proposal on a combination of tests in an SCC CE…), uploaded 01-13.
 JVET-M0883 (a proposal on triangular merging…), uploaded 01-14.
 JVET-M0885 (a proposal on bilateral filtering…), uploaded 01-14.
Page: 5 Date Saved: 2019-03-172019-03-14

 JVET-M0888 (a proposal on picture boundary handling with VPDU constraints…), uploaded 01-
15.
 JVET-M0890 (a proposal on bidirectional optical flow complexity reduction…), uploaded 01-15.
 JVET-M0892 (a proposal on …disabling of loop filter for 360° video), uploaded 01-14.
 JVET-M0894 (a proposal on …bilateral filter operation), uploaded 01-15.
 JVET-M0905 (a proposal on boundary handling for processing video using VPDUs…), uploaded
01-16.
 JVET-M0908 (a proposal of specification text for a combination of proposalsn …), uploaded 01-
17.
 ….
It may be observed that some of the above-listed contributions were submissions made in response to
issues that arose in discussions during the meeting or from the study of other contributions, and thus
could not have been submitted by the ordinary deadline. For example, some of them were proposing
combinations or simplifications of other proposals.
The following other document not proposing normative technical content, but with some need for
consideration, were registered and/or uploaded late:
 JVET-M0511 (a document on rate control for all-intra coding…), uploaded 01-03.
 JVET-M0540 (a document on a software tool for computing transform throughput …), uploaded
01-04.
 JVET-M0600 (a document on rate control using a quality factor…), uploaded 01-05.
 JVET-M0691 (a document on complexity analysis of neural network video coding…), uploaded
01-08.
 JVET-M0759 (a document on testing complexity and throughput aspects for hardware…),
uploaded 01-09.
 JVET-M0762 (a document on …throughput analysis of arithmetic coding), uploaded 01-09.
 JVET-M0774 (a document on summary of JVET-M contributions on picture partitioning…),
uploaded 01-09.
 JVET-M0776 (a document on summary of JVET-M contributions on general HLS…), uploaded
01-10.
 JVET-M0822 (a document on encoder optimization for palette mode…), uploaded 01-11.
 JVET-M0823 (a document on an encoder optimization used in CE4 on inter prediction and
motion vector coding…), uploaded 01-11.
 JVET-M0864 (a document on enhancement of cache model analysis by adopting a block-based
format…), uploaded 01-13.
 JVET-M0871 (a document on the performance of CTU-based intra refresh…), uploaded 01-13.
 ….
The following cross-verification reports were registered before the deadline and uploaded late: JVET-
M0242 [uploaded 01-04], JVET-M0243 [uploaded 01-04], JVET-M0371 [uploaded 01-04], JVET-
M0532 [uploaded 01-08], JVET-M0533 [uploaded 01-10]. Cross-verification reports that were both
Page: 6 Date Saved: 2019-03-172019-03-14

registered late and uploaded late (those with numbers higher than JVET-M0534) are not specifically
identified here, in the interest of brevity. Initial upload times for each document are recorded in Annex A
of this report.
The following (23) contribution registrations were later cancelled, withdrawn, never provided, were
cross-checks of a withdrawn contribution, or were registered in error: JVET-M0041 (withdrawn), JVET-
M0074 (withdrawn), JVET-M0205 (withdrawn), JVET-M0325 (withdrawn), JVET-M0370 (withdrawn),
JVET-M0414 (withdrawn), JVET-M0505 (withdrawn), JVET-M0565 (withdrawn), JVET-M0608
(withdrawn), JVET-M0607 (withdrawn by chair as it was still missing three weeks after the end of the
meeting), JVET-M0609 (registered but still missing at the end of the meeting, and then uploaded with the
wrong document number in the header), JVET-M0642 (withdrawn by chair as it was still missing three
weeks after the end of the meeting), JVET-M0695 (withdrawn by chair as it was still missing three weeks
after the end of the meeting), JVET-M0784 (withdrawn), JVET-M0788 (withdrawn), JVET-M0824
(withdrawn), JVET-M0825 (withdrawn), JVET-M0841 (withdrawn), JVET-M0903 (withdrawn by chair
as it was still missing three weeks after the end of the meeting), JVET-M0639 (registered but still missing
at the end of the meeting, became available 01-21), JVET-M0751 (withdrawn by chair as it was still
missing three weeks after the end of the meeting), JVET-M0770 (withdrawn by chair as it was still
missing three weeks after the end of the meeting), and JVET-M0909 (withdrawn).
“Placeholder” contribution documents that were basically empty of content, or lacking any results
showing benefit for the proposed technology, and obviously uploaded with an intent to provide a more
complete submission as a revision, had been agreed to be considered unacceptable and to be rejected in
the document management system until a more complete version was available (which would then
typically be counted as a late contribution). At the current meeting, this situation applied to the initial
uploads of documents JVET-M0245, JVET-M0325 (later withdrawn), JVET-M0351, JVET-M0396,
JVET-M0424, JVET-M0526, and JVET-M0660.
Contributions that had significant problems with uploaded versions included the following:
 JVET-M0042 (improperly formatted filename)
 JVET-M0067 (proposal described as a report in header)
 JVET-M0080 (incorrect document number in a filename)
 JVET-M0084 (incomplete patent rights declaration)
 JVET-M0147 (no author or contact information in header)
 JVET-M0204 (unreadable file uploaded)
 JVET-M0244 (incorrect company identified in patent rights declaration)
 JVET-M0245 (proposal missing all clearly necessary experiment results)
 JVET-M0325 (proposal missing all clearly necessary experiment results) – later withdrawn
 JVET-M0336 (unreadable file uploaded in -v2)
 JVET-M0339 (unreadable file uploaded in -v2)
 JVET-M0352 (document number missing in header and most test results missing)
 JVET-M0374 (wrong meeting number in header)
 JVET-M0376 (wrong meeting start date in header)
Page: 7 Date Saved: 2019-03-172019-03-14

 JVET-M0400 (wrong meeting start date and incorrect country abbreviation in header)
 JVET-M0416 (wrong meeting identified in header)
 JVET-M0588 (copy of wrong contribution uploaded)
 JVET-M0594 (zero-byte zip file uploaded in -v2, another unreadable file uploaded later)
 JVET-M0605 (wrong document number in header)
 JVET-M0621 (uploaded file with confusing change marks relative to an irrelevant document)
 JVET-M0692 (uploaded file with confusing change marks relative to an irrelevant document)
 JVET-M0657 (title referred to the wrong document)
 JVET-M0660 (cross-check document with only a tiny fraction of the necessary experiment results)
 JVET-M0802, JVET-M0803, JVET-M0804, JVET-M0805, JVET-M0806, JVET-M0819, JVET-
M0839 (document number missing in header)
As a general policy, missing documents were not to be presented, and late documents (and substantial
revisions) could only be presented when there was a consensus to consider them and there was sufficient
time available for their review. Again, an exception is applied for AHG reports, CE summaries, and other
such reports which can only be produced after the availability of other input documents. There were no
objections raised by the group regarding presentation of late contributions, although there was some
expression of annoyance and remarks on the difficulty of dealing with late contributions and late
revisions.
It was remarked that documents that are substantially revised after the initial upload can also be a
problem, as this becomes confusing, interferes with study, and puts an extra burden on synchronization of
the discussion. This can especially be a problem in cases where the initial upload is clearly incomplete,
and in cases where it is difficult to figure out what parts were changed in a revision. For document
contributions, revision marking is very helpful to indicate what has been changed. Also, the “comments”
field on the web site can be used to indicate what is different in a revision although participants tend to
seldom notice what is recorded there.
A few contributions may have had some problems relating to IPR declarations in the initial uploaded
versions (missing declarations, declarations saying they were from the wrong companies, etc.). These
issues were corrected by later uploaded versions in a reasonably timely fashion in all cases (to the extent
of the awareness of the responsible coordinators).
Some other errors were noticed in other initial document uploads (wrong document numbers or meeting
dates or meeting locations in headers, etc.) which were generally sorted out in a reasonably timely
fashion. The document web site contains an archive of each upload.
2.4.3 Outputs of the preceding meeting

All output documents of the previous meeting, particularly the meeting report JVET-L1000, the Versatile
Video Coding specification text (Draft 3) JVET-L1001, the Algorithm description for Versatile Video
Coding and Test Model 3 (VTM 3) JVET-L1002, the Algorithm descriptions of projection format
conversion and video quality metrics in 360Lib Version 8 JVET-L1004, the Methodology and reporting
template for tool testing JVET-L1005, the JVET common test conditions and software reference
configurations for SDR, HDR/WCG, and 360° video (JVET-L1010, JVET-L1011, and JVET-L1012),
and the Description of Core Experiments 1 through 13 (JVET-L1021 through JVET-L1033), had been
Page: 8 Date Saved: 2019-03-172019-03-14
completed and were approved. The software implementation of VTM (versions 3.0 and 3.1), and the
360Lib software implementation (version 8.0) were also approved.
The group was initially asked to review the meeting report of the previous meeting for finalization. The
meeting report was later approved without modification.
The available output documents of the previous meeting and the software had been made available in a
reasonably timely fashion.
2.5 Attendance
The list of participants in the JVET meeting can be found in Annex B of this report.
The meeting was open to those qualified to participate either in ITU-T WP3/16 or ISO/IEC JTC 1/‌SC 29/‌
WG 11 (including experts who had been personally invited as permitted by ITU-T or ISO/IEC policies).
Participants had been reminded of the need to be properly qualified to attend. Those seeking further
information regarding qualifications to attend future meetings may contact the responsible coordinators.
2.6 Agenda
The agenda for the meeting was as follows:
 Opening remarks and review of meeting logistics and communication practices
 IPR policy reminder and declarations
 Contribution document allocation
 Review of results of the previous meeting
 Reports of ad hoc group (AHG) activities
 Reports of core experiments planned at the previous meeting
 Consideration of contributions and communications on project guidance
 Consideration of additional video coding technology contributions
 Consideration of information contributions
 Coordination activities
 Approval of output documents and associated editing periods
 Future planning: Determination of next steps, discussion of working methods, communication
practices, establishment of coordinated experiments, establishment of AHGs, meeting planning,
other planning issues
 Other business as appropriate for consideration
2.7 IPR policy reminder

Participants were reminded of the IPR policy established by the parent organizations of the JVET and
were referred to the parent body websites for further information. The IPR policy was summarized for the
participants.
The ITU-T/ITU-R/ISO/IEC common patent policy shall apply. Participants were particularly reminded
that contributions proposing normative technical content shall contain a non-binding informal notice of
whether the submitter may have patent rights that would be necessary for implementation of the resulting
standard. The notice shall indicate the category of anticipated licensing terms according to the
ITU-T/ITU-R/ISO/IEC patent statement and licensing declaration form.
Page: 9 Date Saved: 2019-03-172019-03-14

This obligation is supplemental to, and does not replace, any existing obligations of parties to submit
formal IPR declarations to ITU-T/ITU-R/ISO/IEC.
Participants were also reminded of the need to formally report patent rights to the top-level parent bodies
(using the common reporting form found on the database listed below) and to make verbal and/or
document IPR reports within the JVET necessary in the event that they are aware of unreported patents
that are essential to implementation of a standard or of a draft standard under development.
Some relevant links for organizational and IPR policy information are provided below:
 http://www.itu.int/ITU-T/ipr/index.html (common patent policy for ITU-T, ITU-R, ISO, and IEC,
and guidelines and forms for formal reporting to the parent bodies)
 http://ftp3.itu.int/av-arch/jvet-site (JVET contribution templates)
 http://www.itu.int/ITU-T/dbase/patent/index.html (ITU-T IPR database)
 http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm (JTC 1/‌SC 29 Procedures)
It is noted that the ITU TSB director’s AHG on IPR had issued a clarification of the IPR reporting process
for ITU-T standards, as follows, per SG 16 TD 327 (GEN/16):
“TSB has reported to the TSB Director’s IPR Ad Hoc Group that they are receiving Patent Statement
and Licensing Declaration forms regarding technology submitted in Contributions that may not yet be
incorporated in a draft new or revised Recommendation. The IPR Ad Hoc Group observes that, while
disclosure of patent information is strongly encouraged as early as possible, the premature submission
of Patent Statement and Licensing Declaration forms is not an appropriate tool for such purpose.
In cases where a contributor wishes to disclose patents related to technology in Contributions, this can
be done in the Contributions themselves, or informed verbally or otherwise in written form to the
technical group (e.g. a Rapporteur’s group), disclosure which should then be duly noted in the
meeting report for future reference and record keeping.
It should be noted that the TSB may not be able to meaningfully classify Patent Statement and
Licensing Declaration forms for technology in Contributions, since sometimes there are no means to
identify the exact work item to which the disclosure applies, or there is no way to ascertain whether
the proposal in a Contribution would be adopted into a draft Recommendation.
Therefore, patent holders should submit the Patent Statement and Licensing Declaration form at the
time the patent holder believes that the patent is essential to the implementation of a draft or approved
Recommendation.”
The responsible coordinators invited participants to make any necessary verbal reports of previously-
unreported IPR in technology that might be considered as prospective candidate for inclusion in future
standards, and opened the floor for such reports: No such verbal reports were made.
2.8 Software copyright disclaimer header reminder

It was noted that the VTM software implementation package uses the same software copyright license
header as the HEVC reference software, where the latter had been agreed at the 5 th meeting of the JCT-
VC and approved by both parent bodies at their collocated meetings at that time. This license header
language is based on the BSD license with a preceding sentence declaring that other contributor or third
party rights, including patent rights, are not granted by the license, as recorded in N 10791 of the 89th
meeting of ISO/IEC JTC 1/‌SC 29/‌WG 11. Both ITU and ISO/IEC will be identified in the <OWNER>
and <ORGANIZATION> tags in the header. This software is used in the process of designing the VTM
software, and for evaluating proposals for technology to be potentially included in the design. This
software or parts thereof might be published by ITU-T and ISO/IEC as an example implementation of a
future video coding standard and for use as the basis of products to promote adoption of such technology.
Different copyright statements shall not be committed to the committee software repository (in the
absence of subsequent review and approval of any such actions). As noted previously, it must be further
Page: 10 Date Saved: 2019-03-172019-03-14

understood that any initially-adopted such copyright header statement language could further change in
response to new information and guidance on the subject in the future.
These considerations apply to the 360Lib video conversion software and and HDRtools as well.
2.9 Communication practices

The documents for the meeting can be found at http://phenix.it-sudparis.eu/jvet/.
It was reminded to send a notice to the chairs in cases of changes to document titles, authors etc.
JVET email lists are managed through the site https://mailman.rwth-aachen.de/mailman/options/jvet, and
to send email to the reflector, the email address is jvet@lists.rwth-aachen.de. Only members of the
reflector can send email to the list. However, membership of the reflector is not limited to qualified JVET
participants.
It was emphasized that reflector subscriptions and email sent to the reflector must use real names when
subscribing and sending messages and subscribers must respond to inquiries regarding the nature of their
interest in the work. The current number of subscribers was 928.
For distribution of test sequences, a password-protected ftp site had been set up at RWTH Aachen
University, with a mirror site at FhG-HHI. Accredited members of JVET may contact the responsible
JVET coordinators to obtain the password information (but the site is not open for use by others).
2.10 Terminology
Some terminology used in this report is explained below:
 ACT: Adaptive colour transform.
 AI: All-intra.
 AIF: Adaptive interpolation filtering.
 ALF: Adaptive loop filter.
 AMP: Asymmetric motion partitioning – a motion prediction partitioning for which the sub-
regions of a region are not equal in size (in HEVC, being N/2x2N and 3N/2x2N or 2NxN/2 and
2Nx3N/2 with 2N equal to 16 or 32 for the luma component).
 AMVP: Adaptive motion vector prediction.
 AMT or MTS: Adaptive multi-core transform, or multiple transform set.
 AMVR: (Locally) adaptive motion vector resolution.
 APS: Adaptation parameter set.
 ARC: Adaptive resolution change / conversion (synonymous with DRC, and a form of RPR).
 ARSS: Adaptive reference sample smoothing.
 ATMVP or “subblock-based temporal merging candidates” : Alternative temporal motion vector
prediction.
 AU: Access unit.
 AUD: Access unit delimiter.
 AVC: Advanced video coding – the video coding standard formally published as ITU-T
Recommendation H.264 and ISO/IEC 14496-10.
 BA: Block adaptive.
 BC: See CPR or IBC.
Page: 11 Date Saved: 2019-03-172019-03-14

 BD: Bjøntegaard-delta – a method for measuring percentage bit rate savings at equal PSNR or
decibels of PSNR benefit at equal bit rate (e.g., as described in document VCEG-M33 of April
2001).
 BDOF: Bi-directional optical flow (formerly known as BIO).
 BL: Base layer.
 BMS: Bench-mark set, a compilation of coding tools on top of VTM, which provide somewhat
better compression performance, but are not deemed mature for standardzation.
 BoG: Break-out group.
 BR: Bit rate.
 BV: Block vector (used for intra BC prediction).
 CABAC: Context-adaptive binary arithmetic coding.
 CBF: Coded block flag(s).
 CC: May refer to context-coded, common (test) conditions, or cross-component.
 CCLM: Cross-component linear model.
 CCP: Cross-component prediction.
 CE: Core Experiment – a coordinated experiment conducted toward assessment of coding
technology.
 CG: Coefficient group.
 CGS: Colour gamut scalability (historically, coarse-grained scalability).
 CIIP: Combined Inter/Intra prediction.
 CL-RAS: Cross-layer random-access skip.
 CPMV: Control-point motion vector.
 CPMVP: Control-point motion vector prediction (used in affine motion model).
 CPR: Current-picture referencing, also known as IBC – a technique by which sample values are
predicted from other samples in the same picture by means of a displacement vector called a
block vector, in a manner conceptually similar to motion-compensated prediction.
 CTC: Common test conditions.
 CVS: Coded video sequence.
 DCT: Discrete cosine transform (sometimes used loosely to refer to other transforms with
conceptually similar characteristics).
 DCTIF: DCT-derived interpolation filter.
 DF: Deblocking filter.
 DMVR: Decoder-side motion vector refinement.
 DRC: Dynamic resolution conversion (synonymous with ARC, and a form of RPR).
 DT: Decoding time.
 ECS: Entropy coding synchronization (typically synonymous with WPP).
 EMT: Explicit multiple-core transform.
Page: 12 Date Saved: 2019-03-172019-03-14

 EOTF: Electro-optical transfer function – a function that converts a representation value to a
quantity of output light (e.g., light emitted by a display.
 EPB: Emulation prevention byte (as in the emulation_prevention_byte syntax element).
 ECV: Extended Colour Volume (up to WCG).
 EL: Enhancement layer.
 ET: Encoding time.
 FRUC: Frame rate up conversion (pattern matched motion vector derivation).
 HDR: High dynamic range.
 HEVC: High Efficiency Video Coding – the video coding standard developed and extended by
the JCT-VC, formalized by ITU-T as Rec. ITU-T H.265 and by ISO/IEC as ISO/IEC 23008-2.
 HLS: High-level syntax.
 HM: HEVC Test Model – a video coding design containing selected coding tools that constitutes
our draft standard design – now also used especially in reference to the (non-normative) encoder
algorithms (see WD and TM).
 HMVP: History based motion vector prediction.
 HyGT: Hyper-cube Givens transform (a type of NSST).
 IBC (also Intra BC): Intra block copy, also known as CPR – a technique by which sample values
are predicted from other samples in the same picture by means of a displacement vector called a
block vector, in a manner conceptually similar to motion-compensated prediction.
 IBDI: Internal bit-depth increase – a technique by which lower bit-depth (8 bits per sample)
source video is encoded using higher bit-depth signal processing, ordinarily including higher bit-
depth reference picture storage (ordinarily 12 bits per sample).
 IBF: Intra boundary filtering.
 ILP: Inter-layer prediction (in scalable coding).
 IPCM: Intra pulse-code modulation (similar in spirit to IPCM in AVC and HEVC).
 JEM: Joint exploration model – the software codebase for future video coding exploration.
 JM: Joint model – the primary software codebase that has been developed for the AVC standard.
 JSVM: Joint scalable video model – another software codebase that has been developed for the
AVC standard, which includes support for scalable video coding extensions.
 KLT: Karhunen-Loève transform.
 LB or LDB: Low-delay B – the variant of the LD conditions that uses B pictures.
 LD: Low delay – one of two sets of coding conditions designed to enable interactive real-time
communication, with less emphasis on ease of random access (contrast with RA). Typically refers
to LB, although also applies to LP.
 LIC: Local illumination compensation.
 LM: Linear model.
 LP or LDP: Low-delay P – the variant of the LD conditions that uses P frames.
 LUT: Look-up table.
 LTRP: Long-term reference pictures.
Page: 13 Date Saved: 2019-03-172019-03-14

 MC: Motion compensation.
 MCP: Motion compensated prediction.
 MDNSST: Mode dependent non-separable secondary transform.
 MMLM: Multi-model (cross component) linear mode.
 MMVD: Merge mode with motion vector difference
 MPEG: Moving picture experts group (WG 11, the parent body working group in ISO/IEC
JTC 1/‌SC 29, one of the two parent bodies of the JVET).
 MPM: Most probable mode (in intra prediction).
 MV: Motion vector.
 MVD: Motion vector difference.
 NAL: Network abstraction layer (as in AVC and HEVC).
 NSQT: Non-square quadtree.
 NSST: Non-separable secondary transform.
 NUH: NAL unit header.
 NUT: NAL unit type (as in AVC and HEVC).
 OBMC: Overlapped block motion compensation (e.g., as in H.263 Annex F).
 OETF: Opto-electronic transfer function – a function that converts to input light (e.g., light input
to a camera) to a representation value.
 OOTF: Optical-to-optical transfer function – a function that converts input light (e.g. l,ight input
to a camera) to output light (e.g., light emitted by a display).
 PDPC: Position dependent (intra) prediction combination.
 PMMVD: Pattern-matched motion vector derivation.
 POC: Picture order count.
 PoR: Plan of record.
 PPS: Picture parameter set (as in AVC and HEVC).
 QM: Quantization matrix (as in AVC and HEVC).
 QP: Quantization parameter (as in AVC and HEVC, sometimes confused with quantization step
size).
 QT: Quadtree.
 BT: Binary tree.
 TT: Ternary tree.
 RA: Random access – a set of coding conditions designed to enable relatively-frequent random
access points in the coded video data, with less emphasis on minimization of delay (contrast with
LD).
 RADL: Random-access decodable leading.
 RASL: Random-access skipped leading.
 R-D: Rate-distortion.
Page: 14 Date Saved: 2019-03-172019-03-14

 RDO: Rate-distortion optimization.
 RDOQ: Rate-distortion optimized quantization.
 ROT: Rotation operation for low-frequency transform coefficients.
 RPLM: Reference picture list modification.
 RPR: Reference picture resampling (e.g., as in H.263 Annex P), a special case of which is also
known as ARC or DRC.
 RPS: Reference picture set.
 RQT: Residual quadtree.
 RRU: Reduced-resolution update (e.g. as in H.263 Annex Q).
 RVM: Rate variation measure.
 SAO: Sample-adaptive offset.
 SBT: Subblock transform.
 SbTMVP: Subblock based temporal motion vector prediction.
 SD: Slice data; alternatively, standard-definition.
 SDT: Signal-dependent transform.
 SEI: Supplemental enhancement information (as in AVC and HEVC).
 SH: Slice header.
 SHM: Scalable HM.
 SHVC: Scalable high efficiency video coding.
 SIMD: Single instruction, multiple data.
 SMVD: Symmetric MVD.
 SPS: Sequence parameter set (as in AVC and HEVC).
 STMVP: Spatial-temporal motion vector prediction.
 TBA/TBD/TBP: To be announced/determined/presented.
 TGM: Text and graphics with motion – a category of content that primarily contains rendered
text and graphics with motion, mixed with a relatively small amount of camera-captured content.
 TPM: Triangular partitioning mode
 UCBDS: Unrestricted center-biased diamond search.
 UWP: Unequal weight prediction.
 VCEG: Visual coding experts group (ITU-T Q.6/16, the relevant rapporteur group in ITU-T
WP3/16, which is one of the two parent bodies of the JVET).
 VPDU: Virtual data processing unit – a unit of data for decoding processing without accessing an
entire CTU.
 VPS: Video parameter set – a parameter set that describes the overall characteristics of a coded
video sequence – conceptually sitting above the SPS in the syntax hierarchy.
 VTM: VVC Test Model.
Page: 15 Date Saved: 2019-03-172019-03-14

 VVC: Versatile Video Coding, the standardization project developed by JVET.
 WCG: Wide colour gamut.
 WG: Working group, a group of technical experts (usually used to refer to WG 11, a.k.a. MPEG).
 WPP: Wavefront parallel processing (usually synonymous with ECS).
 Block and unit names in HEVC:
o CTB: Coding tree block (luma or chroma) – unless the format is monochrome, there are
three CTBs per CTU.
o CTU: Coding tree unit (containing both luma and chroma, synonymous with LCU), with
a size of 16x16, 32x32, or 64x64 for the luma component.
o CB: Coding block (luma or chroma), a luma or chroma block in a CU.
o CU: Coding unit (containing both luma and chroma), the level at which the prediction
mode, such as intra versus inter, is determined in HEVC, with a size of 2Nx2N for 2N
equal to 8, 16, 32, or 64 for luma.
o PB: Prediction block (luma or chroma), a luma or chroma block of a PU, the level at
which the prediction information is conveyed or the level at which the prediction process
is performed in HEVC.
o PU: Prediction unit (containing both luma and chroma), the level of the prediction control
syntax within a CU, with eight shape possibilities in HEVC:
 2Nx2N: Having the full width and height of the CU.
 2NxN (or Nx2N): Having two areas that each have the full width and half the
height of the CU (or having two areas that each have half the width and the full
height of the CU).
 NxN: Having four areas that each have half the width and half the height of the
CU, with N equal to 4, 8, 16, or 32 for intra-predicted luma and N equal to 8, 16,
or 32 for inter-predicted luma – a case only used when 2N×2N is the minimum
CU size.
 N/2x2N paired with 3N/2x2N or 2NxN/2 paired with 2Nx3N/2: Having two
areas that are different in size – cases referred to as AMP, with 2N equal to 16 or
32 for the luma component.
o TB: Transform block (luma or chroma), a luma or chroma block of a TU, with a size of
4x4, 8x8, 16x16, or 32x32.
o TU: Transform unit (containing both luma and chroma), the level of the residual
transform (or transform skip or palette coding) segmentation within a CU (which, when
using inter prediction in HEVC, may sometimes span across multiple PU regions).
 Block and unit names in VVC:
o CTB: Coding tree block (luma or chroma) – there are three CTBs per CTU in a P or B
slice or in an I slice that uses a single tree, and one CTB per luma CTU and two CTBs
per chroma CTU in an I slice that uses separate trees.
o CTU: Coding tree unit (synonymous with LCU, containing both luma and chroma in a P
or B slice or in an I slice that uses a single tree, containing only luma or only chroma in
an I slice that uses separate trees), with a size of 16x16, 32x32, 64x64, or 128x128 for the
luma component.
o CB: Coding block, a luma or chroma block in a CU.
Page: 16 Date Saved: 2019-03-172019-03-14

o CU: Coding unit (containing both luma and chroma in P/B slice, containing only luma or
chroma in I slice), a leaf node of a QTBT. It’s the level at which the prediction process
and residual transform are performed in JEM. A CU can be square or rectangle shape.
o PB: Prediction block, a luma or chroma block of a PU.
o PU: Prediction unit, has the same size as a CU in the VVC context.
o TB: Transform block, a luma or chroma block of a TU.
o TU: Transform unit, has the same size as a CU in the VVC context.
2.11 Opening remarks

Remarks during the opening session of the meeting 0900 Wednesday 9 January (chaired by GJS and
JRO) were as follows.
 The meeting logistics, agenda, working practices, policies, and document allocation were reviewed.
 The results of the previous meeting were reviewed.
 On placeholders – there were a number of cases where there was some description of a concept but no
test results (see section 2.4.2).
 The primary goals of the meeting were to review the results of CEs, identify promising technology
directions, and adopt proposed technology into the VVC draft text and VTM.
 Due to the high number of input contributions, parallelization and breakout work were planned to be
used at the meeting.
 Principles of standards development were discussed.
2.12 Scheduling of discussions

Scheduling: Generally, meeting time was scheduled during 0900–2100+ hours, with coffee and lunch
breaks as convenient. Ongoing scheduling refinements were announced on the group email reflector as
needed. Some particular scheduling notes are shown below, although not necessarily 100% accurate or
complete:
 Wed. 9 January, 1st day
o 0900–1100, 1130-1400 Opening plenary (chaired by GJS & JRO)
o 1530–1700 Track A CE1: Partitioning [GJS]
o 1750–2030 Track A CE3.1: Intra prediction and mode coding [GJS]
o 1530–2100 Track B CE2: Subblock motion compensation [JRO]
 Thu. 10 January, 2nd day
o 0900–1330, 1500–1630 Track A CE3.2 & CE3.3 Intra prediction & mode coding [GJS]
o 1700–2030 Track A CE5: Arithmetic coding engine [Y. Ye]
o 2030–2200 Track A CE6: Transforms and transform signalling [GJS]
o 0900–1100 Track B CE2: Subblock motion compensation [JRO]
o 1120–1340, 1500-2000 Track B CE4: Inter prediction and motion vector coding [JRO]
o 2030–2230 Track B CE9: Decoder-side motion vector derivation [JRO]
o 0900–2100 BoG on tiles & wavefronts [Y.-K. Wang & M. M. Hannuksela in Chellah JVET-
M0782]
o 2030–2300 BoG on CE2 related [Y. He in Lixus JVET-M0862]
Page: 17 Date Saved: 2019-03-172019-03-14

 Fri. 11 January, 3rd day
o 0900–1100, 1130–1400, 1530–2000 Track A CE6: Transforms and transform signalling
[GJS]
o 0900–1100 Track B CE11: Deblocking [JRO]
o 1120–1330 and 1500–1615 Track B CE8: Screen content coding tools [JRO]
o 1620–2010 Track B CE8 related screen content coding [JRO]
o 0900–2100 BoG on high-level syntax [J. Boyce in Chellah JVET-M0816]
o 0900–1300, 1500–18900 BoG on CE3 and CE3-related intra prediction and mode coding
[G. Van der Auwera in Ourica JVET-M0857]
o 1540–2020 BoG on CE4 related inter prediction and motion vector coding [K. Zhang JVET-
M0843]
o 2045–2330 BoG on CE2 subblock motion compensation [Y. He in Lixus JVET-M0862]
 Sat. 12 January, 4th day
o 0900–1330 JCT-VC [outside of JVET in Chella]
o 0900–1045, 1830–2300 BoGs sharing room in Olympia, then Colliseum
 BoG on CE4 related inter prediction and motion vector coding [K. Zhang JVET-
M0843]
 BoG on CE2 subblock motion compensation [Y. He JVET-M0862]
o 0900–1300, 1500–1800 BoG on CE3 and CE3-related intra prediction and mode coding
[G. Van der Auwera in Colliseum in morning, Salon marocain in afternoon JVET-M0857]
o 1130–1345, 1515–1815 Track B on CE10: Combined and multi-hypothesis prediction [JRO]
o 15300–2015 BoG on CE9 related decoder-side motion vector derivation [S. Esenlik JVET-
M0858]
o 1500–1600 Track A CE7: Quantization and coefficient coding [GJS]
o 1600–1645, 1700–1800 Track A CE12 – Mapping functions [GJS]
o 1600–1740 BoG on tiles & wavefronts [Y.-K. Wang & M. M. Hannuksela in Chellah JVET-
M0782]
o 1800–1830 Track A CE12 related – Mapping functions [GJS]
o 1815–2130 Track B CE8 related screen content coding [JRO]
o 1800–2100 BoG on high-level syntax [J. Boyce in Chellah JVET-M0816]
 Sun. 13 January, 5th day
o 0900–1045, 1115–1400 Plenary
o 1530–1645, 1700–1800 Track A BoG reporting on high-level syntax JVET-M0816
o 1530–1800 Track B Loop filtering [JRO]
o 1530–XXXXqq BoG on CE13 and CE13 related 360° video coding [J. Boyce in Chella
JVET-M0874]
o 1530–XXXX 2130 BoG on CE6 related transforms and transform signalling [X. Zhao in
Luxor JVET-M0877]
o 1530–XXXXqq BoGs sharing room in Salon Mmarocain
M0843]
o 1800–2030 BoG on CE13 and CE13 related 360° video coding [J. Boyce in Chella JVET-
M0874]
o 1800-2230 BoG on CE10 related [C.-W. Hsu and M. Winken in Olympia JVET-M0873]
 Mon. 14 January, 6th day
o 0900–1400 MPEG parent-body opening plenary
o 1300–XXXX 2000 Track A BoG reporting
 1300-1430 BoG on HLS
 1430-1630, 1920-2000 BoG on tiles and wavefronts JVET-M0782
Page: 18 Date Saved: 2019-03-172019-03-14

o 2015–2240 Track A Use case studies and general prediction [GJS]
o 13400-1600?, 1930–2300 BoG on CE10 related [C.-W. Hsu and M. Winken in Olympia, then
Ourika JVET-M0873]
o 1600–1945 Track B [JRO]
 1600–1715 6.14 Loop filtering tools
 1715–1815 6.11 CE11 related (deblocking)
 1815–1945 6.18 Tools based on NN technology
o 1700–1830 VCEG parent-body opening plenary [outside of JVET in Chellah]
o 1900–2345 BoG on CE7 related quantization and coefficient coding [Y. Ye in Sabah JVET-
M0891]
o 180045–XXXX 1900 BoG on CE13 and CE13 related 360° video coding [J. Boyce in Lodge
2, then Chella JVET-M0874]
o 1900–XXXX BoGs sharing room in Olympia
M0843]
o 22302030–XXXX 2210 BoG on CE6 related transforms and transform signalling [X. Zhao in
Luxor JVET-M0877]
 Tue. 15 January, 7th day
o 0900–1000 VCEG-MPEG joint meeting [incl. JVET systems coord, in Lixus]
o 1030–1400 JCT-VC meeting [outside of JVET in Chella]
o 1000–1215 Track B BoG on CE2 reporting in Olympia [JRO]
o 1215–1330, 1430–1800 Track B BoG on CE4 reporting in Coliseum [JRO]
o 1430–1630 Track A BoG reporting on CE3 related intra prediction and mode coding JVET-
M0857
o 1700 Track A BoG reporting on CE6 related transforms and transform signalling [X. Zhao
JVET-M0877]
o 1800 BoG on high-level syntax (J. Boyce in Chellah JVET-M0816)
o 1915 BoG on complexity analysis and reduction [A. Filippov & B. Bross in Coliseum.
o 2000–2330 BoG on quantization control (8) [Y. Ye in Olympia]
o XXXX BoG on tools based on NN technology (7) (section 6.18) (Y. Li)
 Wed. 16 January, 8th day
o 0900–1115 MPEG mid-week plenary
o 1130–1200 VCEG-MPEG joint meeting (outside of JVET in Lixus)
o 1200–1300 MPEG liaison meeting (outside of JVET)
o 1300 BoG on CE7 related quantization and coefficient coding (13) [Y. Ye in Saba JVET-
M0891]
o 1300–1400 Track A BoG reporting on CE6 related transforms and transform signalling
[X. Zhao JVET-M0877]
o 1400–1445 Track A BoG reporting on high-level syntax JVET-M0816
o 1445–1515 Track A BoG further review on tiles and wavefronts JVET-M0782
o 1515–1630 Track A BoG reporting on complexity analysis and reduction JVET-M0902 and
related contribution JVET-M0265.
o 1645–1800 Track A BoG reporting on quantization control JVET-M0901
o 1700–XXXX 1800 BoG on CE13 and CE13 related 360° video coding [J. Boyce in Chella
JVET-M0874]
o 1820 Departures starting for social event @ Soleiman Palace
 Thu. 17 January, 9th day
Page: 19 Date Saved: 2019-03-172019-03-14

o 0900–0930 JVET-VCEG-MPEG joint meeting on systems interface in Coliseum
o 1400–1500 ISO standards editing guidance [Outside of JVET in Lixus]
o 0945–1200 JVET plenary
o 1200–1330 Track B: Review of CE11 viewing results [JRO]
o 1500–1815 Track B Review of NN BoG, revisits [JRO]
o 1200 JCT-VC (outside of JVET)
o 1300–1400 BoG on CE7 related quantization and coefficient coding (13) [Y. Ye in Saba
JVET-M0891]
o 1500–1545 Track A further discussion of VPDU shape penalty and special treatment of edges
in CE1
o 1545–1600 Track A further discussion of CE6-5 secondary transform
o 1600–1700 Track A BoG reporting on 360° video (CE13 & related JVET-M0874)
o 1700–1800 Track A BoG reporting on CE7 related quantization and coefficient coding
[Y. Ye JVET-M0891]
o XXXX Track A Use case studies and general prediction (3 remaining)
o XXXX Track A CE5-related entropy coding (1 needing presentation)
o XXXX Track A Entropy coding (1)
o XXXX Track A CE1 related partitioning (1 TBP)
o XXXX Track A Encoder optimization (3)
o XXXX Plenary common test conditions (1)
o XXXX Plenary software development (1)
o 1800 MPEG chairs meeting
 Fri. 19 January, 10th day
o 0800–0900 Track B on CE11 and CE11 related revisits [JRO]
o 0800 VCEG? (outside of JVET)
2.13 Contribution topic overview

The approximate subject categories and quantity of contributions per category for the meeting were
summarized as follows (note that the noted document counts do not include crosschecks, and may not be
completely accurate):
 AHG reports (17) (section 3) (Plenary)
 Project development (10) (section 4) (Plenary)
o Software development (1)
o Common test conditions (1)
o Coding studies and specific use cases (8)
 Core Experiments (xxqq) (section 5) with subtopics
o CE1: Partitioning (3) (section 5.1) (Track A)
o CE2: Subblock motion compensation (24) (section 5.2) (Track B)
o CE3: Intra prediction and mode coding (16) (section 5.3) (Track A)
o CE4: Inter prediction and motion vector coding (18) (section 5.4) (Track B)
o CE5: Arithmetic coding engine (10) (section 5.5) (Track A)
o CE6: Transforms and transform signalling (21) (section 5.6) (Track A)
o CE7: Quantization and coefficient coding (2) (section 5.7) (Track A & BoG JVET-M0891)
o CE8: Screen content coding tools (15) (section 5.8) (Track B)
o CE9: Decoder side motion vector derivation (8) (section 5.9) (Track B)
o CE10: Combined and multi-hypothesis prediction (15) (section 5.10) (Track B)
o CE11: Deblocking (9) (section 5.11) (Track B)
o CE12: Mapping functions (2) (section 5.12) (Track A)
o CE13: Coding tools for 360° video (11) (section 5.13) (Track A & BoG JVET-M0874)
Page: 20 Date Saved: 2019-03-172019-03-14

 Non-CE technology proposals (xx) (section 6) with subtopics
• CE1 related – Partitioning (3) (section 6.1) (Track A)
• CE2 related – Subblock motion compensation (31) (section 6.2) (Track B & BoG Y. He
JVET-M0862)
• CE3 related – Intra prediction and mode coding (50) (section 6.3) (Track A & BoG G. Van
der Auwera JVET-M0857)
• CE4 related – Inter prediction and motion vector coding (49) (section 6.4) (Track B & BoG
K. Zhang JVET-M0843)
• CE5 related – Arithmetic coding engine (4) (section 6.5) (Track A)
• CE6 related – Transforms and transform signalling (25) (section 6.6) (Track A & BoG
X. Zhao JVET-M0877)
• CE7 related – Quantization and coefficient coding (13) (section 6.7) (Track A & BoG Y. Ye)
• CE8 related – Screen content coding tools (29) (section 6.8) (Track B)
• CE9 related – Decoder side motion vector derivation (12) (section 6.9) (Track B & BoG
S. Esenlik JVET-M0858)
• CE10 related – Combined and multi-hypothesis prediction (42) (section 6.10) (Track B &
BoG C.-W. Hsu & M. Winken JVET-M0873)
• CE11 related – Deblocking (3) (section 6.11) (Track B)
• CE12 related – Mapping functions (2) (section 6.12) (Track A)
• CE13 related – Coding tools for 360° content (7) (section 6.13) (Track A & BoG J. Boyce
JVET-M0874)
• Loop filtering tools (12) (section 6.14) (Track B)
• General prediction aspects (5) (section 6.15) (Track A)
• Quantization control (8) (section 6.16) (Track A & BoG Y. Ye)
• Entropy coding (2) (section 6.17) (Track A)
• Tools based on NN technology (7) (section 6.18) (Track B & BoG Y. Li)
• High-level syntax (51) (section 6.19) (Track A & BoG Y.-K. Wang & M. M. Hannuksela on
tiles & wavefronts JVET-M0782 & BoG J. Boyce JVET-M0816)
 Complexity analysis and reduction (10) (section 7) (Track A & BoG A. Filippov & B. Bross)
 Encoder optimization (3) (section 8) (Track A)
 Metrics and evaluation criteria (0) (section 9) (Track none)
 Joint meetings, plenary discussions, BoG reports, Summary of actions (section 10)
 Project planning (section 11)
 Establishment of AHGs (section 12)
 Output documents (section 13)
 Future meeting plans and concluding remarks (section 14)
Track A (238) was generally chaired by GJS, and Track B (272) by JRO.
As a general remark, it was established that in Track B “further study” meant that a technology should be
studied in next CE on the subject area, whereas if such a remark is missing it implicitly meant it should
not be studied in CE. If further study in an AHG was expected, that would be explicitly expressed. In
Track A, “further study” (expressed by itself) did not necessarily indicate whether the encouraged study
should be in a CE or AHG or unstructured effort.
3 AHG reports (17)

These reports were discussed Wednesday 9 January 0945–1400 (chaired by GJS and JRO).
Page: 21 Date Saved: 2019-03-172019-03-14

JVET-M0001 JVET AHG report: Project management (AHG1) [J.-R. Ohm, G. J. Sullivan]
This document reported on the work of the JVET ad hoc group on Project Management, including an
overall status report on the VVC standardization project and the progress made during the interim period
since the preceding meeting.
At the 12th meeting of the ITU-T/ISO/IEC Joint Video Experts Team (JVET), an ad hoc group on Project
Management was established with the following mandates:
 Coordinate overall JVET interim efforts.
 Supervise CE and AHG studies.
 Report on project status to JVET reflector.
 Provide a report to next meeting on project coordination status.
The reflector used for discussions by the JVET and all of its AHGs is the JVET reflector:
jvet@lists.rwth-aachen.de. For subscription to this list, see
http://mailman.rwth-aachen.de/mailman/listinfo/jvet.
In the interim period since the 12th JVET meeting, work towards finalizing the following (21) documents
had been performed:
 JVET-L1001 Versatile Video Coding specification text (Draft 3)
 JVET-L1002 Algorithm description for Versatile Video Coding and Test Model 3 (VTM 3)
 JVET-L1004 Algorithm descriptions of projection format conversion and video quality metrics in
360Lib (Version 8)
 JVET-L1005 and JVET-L1006 Methodology and reporting template for coding tool testing and for
neural network tool testing
 JVET-L1010, JVET-L1011, and JVET-L1012 JVET common test conditions and software reference
configurations for SDR, HDR/WCG, and 360° video
 JVET-L1021 through JVET-L1033, descriptions of Core Experiments 1 through 13
The work of the JVET overall had proceeded well in the interim period, and many input documents had
been submitted for consideration at the current meeting. Intense discussion had been carried out on the
group email reflector, and all output documents from the preceding meeting had been produced.
As noted below, all output documents from the preceding meeting had been made available at the
"Phenix" site (http://phenix.it-sudparis.eu/jvet/) or the ITU-based JCT-VC site (http://wftp3.itu.int/av-
arch/jvet-site/2018_10_M_Macao/), although some of these documents were noted to potentially need
further refinement:
 The meeting report (JVET-L1000) [Posted 2019-01-08]
 Versatile Video Coding (Draft 3) (JVET-L1001) [Posted 2018-10-31, last update 2019-01-08]
 Algorithm description for Versatile Video Coding and Test Model 3 (VTM 3) (JVET-L1002) [Posted
2018-12-03, last update 2018-12-24]
 Algorithm descriptions of projection format conversion and video quality metrics in 360Lib Version
8 (JVET-L1004) [Posted 2018-11-10]
 Methodology and reporting template for coding tool testing (JVET-L1005) [Posted 2018-10-27]
 Methodology and reporting template for neural network coding tool testing (JVET-L1006) [Posted
2018-10-25]
 JVET common test conditions and software reference configurations (JVET-L1010) [Posted 2018-11-
16]
Page: 22 Date Saved: 2019-03-172019-03-14

 JVET common test conditions and evaluation procedures for HDR/WCG video (JVET-L1011)
[Posted 2018-11-20]
 JVET common test conditions and evaluation procedures for 360° video (JVET-L1012) [Posted
2018-11-19]
Description of CE 1..13 (JVET-L1021..35) [all first posted 2018-10-11 or 2018-10-12, further updated
during the CE definition period of 3 weeks after the meeting, i.e., until 2018-11-02]. The following CE
description documents had substantially later updates (more than 4 weeks after the meeting):
 JVET-L1022 [last updated 2019-01-08] (for which some experiment plans had changed and the
change had been announced on the JVET reflector)
 JVET-L1023 [last updated 2018-12-27]
 JVET-L1024 [last updated 2019-01-08] (for which some experiment plans had changed but the
change had not been announced on the JVET reflector)
The seventeen ad hoc groups had made progress, and reports from those activities had been submitted.
Software integration of the VTM was finalized approximately according to the plan.
Various problem reports relating to asserted bugs in the software, draft specification text, and reference
encoder description had been submitted to an informal "bug tracking" system. That system is not intended
as a replacement of our ordinary contribution submission process. However, the bug tracking system was
considered to have been helpful to the software coordinators and text editors. The bug tracker reports had
been automatically forwarded to the group email reflector, where the issues were discussed – and this is
reported to have been helpful.
The software distribution had been migrated to GitLab before the previous meeting, and the method for
obtaining access to the software had been changed after the last meeting – using shared accounts for read
access by members (with one account for MPEG members using its usual credentials and another for
VCEG members with access managed through the TIES system). The bug tracking system for software
aspects was not integrated yet with GitLab for the time being.
At the time the meeting began, roughly 700 input contributions to the current meeting (not counting the
AHG reports) had been registered for consideration at the meeting. Though the topics of Core
Experiments and related documents for the development of low-level coding tools reflected the bulk of
these documents, around 50 documents were submitted on aspects of high-level syntax, including tile
partitioning.
A preliminary basis for the document subject allocation and meeting notes for the 13th meeting had been
made publicly available on the ITU-hosted site.
JVET-M0002 JVET AHG report: Draft text and test model algorithm description editing
(AHG2) [B. Bross, J. Chen, J. Boyce, S. Kim, S. Liu, Y. Ye]
This document reported the work of the JVET ad hoc group on draft text and test model algorithm
description editing (AHG2) between the 12th meeting in Macao, CN (3–12 October 2018) and the 13th
meeting in Marrakech, MA (9–18 January 2019).
At the 12th JVET meeting, it was decided to include more coding features for intra picture-prediction,
inter-picture prediction, transform coefficient coding, transform, adaptive loop filtering and a tile group
based high-level syntax in the third draft of Versatile Video Coding (VVC D3) and the VVC Test
Page: 23 Date Saved: 2019-03-172019-03-14

Model 3 (VTM3) encoding. Draft reference software to implement the VVC decoding process and VTM3
encoding method had also been developed.
The normative decoding process for Versatile Video Coding is specified in the VVC draft 3 text
specification document. The VVC Test Model 3 (VTM 3) Algorithm and Encoder Description document
provides an algorithm description as well as an encoder-side description of the VVC Test Model 3, which
serves as a tutorial for the algorithm and encoding model implemented in the VTM3.0 software.
An issue tracker (https://jvet.hhi.fraunhofer.de/trac/vvc) was used to facilitate the reporting of errata with
the VVC documents.
Nine versions of the JVET-L1001 VVC draft 3 specification text were published by the editing AHG
between the 12th meeting in Macao, CN (3–12 October 2018) and the 13th meeting in Marrakech, MA
(9–18 January 2019).
The specific items integrated into the text were listed in the AHG report.
The following items had been discussed within the AHG:
 Deblocking over SubCUs: There had been two different understandings of the decision from the last
meeting how deblocking over SubPU boundaries is performed – recorded as "Recommendation:
Apply the same logic to VVC (both ATMVP and affine) sub-blocks (on 8x8 grid) as to PU in HEVC
deblocking. This means check the deblocking motion conditions for ATMVP and affine motion sub-
block boundaries as if they were PUs in HEVC". The two interpretations were:
– All edges on a 8x8 sample grid can be deblocked, irrespective of the type of the edge (i.e. CU,
SubCU, TU edge).
– Only Sub-CU and TU edges of a CU that is aligned on the 8x8 grid in one direction can be
deblocked in the respective direction.
The current draft and the VTM-3.0 macro L0074_SUBBLOCK_DEBLOCKING followed the second
understanding. However, the AHG requested JVET to discuss which solution is preferred. The
following document was identified to be related:
– JVET-M0339 CE11-related: subblock boundary filter at 8x8 Grid [H. Jang, J. Nam, S. Kim, J.
Lim (LGE)]
 Interaction of CPR with other newly adopted inter tools: There had been six items discussed which
were related to CPR interaction with newly adopted inter tools. They were summarized as follows.
1. In the current draft spec, when the first merge candidate of the current CU is coded in CPR mode,
(0, 0) motion vector is used for the derivation of the collocated block, while in VTM-3.0, the next
merge candidate will be examined. It was recommended to change the software to match the
spec. A related contribution JVET-M0409 was noted.
2. For CPR to work with the newly adopted pairwise average merging candidates, two options were
discussed:
– Option 1. Disallow any combination involves CPR
– Option 2. Integrate CPR-CPR combination in draft text.
The draft spec and VTM-3.0 had implemented Option 2.
3. For CPR interaction with Affine motion, neither current draft spec nor VTM-3.0 allows the
combination of both being enabled at the same time. Bitstream conformance check is used in both
VTM-3.0 and the current draft spec. The generation of merge candidate excludes CPR
neighbours, while the generation of motion vector predictor (AMVP mode) includes CPR
neighbours. [Ed. sp. neighbor (done), artifact (done), “ ^p” (done), “analyze” (done), “signaled”
(done), “signaling” (done), “bitrate” (done), bold “. ” (p. 221+), -1, “ ”, “Jan” as word]
Page: 24 Date Saved: 2019-03-172019-03-14

4. For CPR interaction with MMVD partition, neither current draft spec nor VTM-3.0 allows the
VTM-3.0 and the current draft spec. The generation of MMVD base motion vector excludes CPR
neighbours.
5. For CPR interaction with Triangular partition, neither current draft spec nor VTM-3.0 allows the
VTM-3.0 and the current draft spec. The generation of partition motion vector excludes CPR
neighbours.
6. For CPR interaction with CIIP, neither current draft spec nor VTM-3.0 allows the combination of
both being enabled at the same time. Bitstream conformance check is used in both VTM-3.0 and
the current draft spec. The generation of inter-merge motion vector includes CPR neighbours.
 The maximum number of HMVP candidates is 6, but six cases were never actually used and thus can
be reduced to 5. The following document was identified to be related:
– JVET-M0436 AHG2: Regarding HMVP Table Size [J. Zhao, S. Kim (LGE)]
 Open bug tracker issues (tickets): The following tickets were suggested to need discussion:
o #128 incorrect modulo value used in adjacent mode calculations. Is there a mismatch between
VTM and spec?
o #132 Mismatch between specification and software in the order of syntax elements for intra
prediction
o #135 DCT2 transform matrix down-sampling might be wrong in the spec
In the JVET discussion of these items, the following outcomes were agreed:
o No action was needed on ticket #128.
o Decision (SW): A software fix was needed for #132.
o Decision (BF editorial): The downsampling of the DCT2 transform matrix should be separate
horizontally and vertically (not assumed square) for #135.
Two versions of the JVET-L1002 VVC Test Model 3 (VTM 3) document were published by the Editing
AHG between the 12th meeting in Macao, CN (3–12 October 2018) and the 13th meeting in Marrakech,
MA (9–18 January 2019). The items added to VTM 3 were listed in the AHG report.
A general encoder description and some other features such as high-level syntax, the tiling mechanism
and miscellaneous small coding features (such PCM mode and Delta QP signalling) had yet to be added
to the document.
The AHG recommended to:
 Approve the edited JVET-L1001 and JVET-L1002 documents as JVET outputs,
 Continue to edit the VVC draft and Test Model documents to ensure that all agreed elements of VVC
are fully described,
 Compare the VVC documents with the VVC software and resolve any discrepancies that may exist,
in collaboration with the software AHG,
 Encourage the use of the issue tracker to report issues with the text of both the VVC specification
draft and the algorithm and encoder description,
 Continue to improve the editorial consistency of VVC WD and Test Model documents,
 Ensure that, when considering the addition of new feature to VVC, properly drafted text for addition
to the VVC Test Model and/or the VVC Working Draft are made available in a timely manner.
Page: 25 Date Saved: 2019-03-172019-03-14

JVET-M0003 JVET AHG report: Test model software development (AHG3) [F. Bossen,
X. Li, K. Sühring]
This report summarized the activities of the AhG3 on Test model software development that took place
between the 12th and 13th JVET meetings.
The software development continued on the GitLab server. VTM versions 3.0 was tagged on Nov. 22.
VTM 3.1 is expected during the 13th JVET meeting.
For core experiments (CEs) the same development workflow was followed as for the last meeting.
VTM software development was continued on the GitLab server, which allows participants to register
accounts and use a distributed development workflow based on git.
The server is located at:
https://vcgit.hhi.fraunhofer.de
The registration and development workflow is documented at:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_BMS/wikis/VVC-Software-Development-Workflow
The VTM software can be found at:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/
After one release candidate, VTM 3.0 was tagged on Nov. 22, 2018.
Changes relative to VTM 2.1 were listed in the AHG report.
Given the large amount of adoptions, it was reported that there may be some oddities in the syntax, for
example for signalling the various motion modes (see ticket #105, merge request 111) where the syntax
allows to encode mutually exclusive modes.
VTM 3.1 was tagged during the 13th JVET meeting. Changes included in that version were listed in the
AHG report.
At the beginning of the meeting, implementation of one topic was reported to be still pending:
 JVET-L0686 Spec text for the agreed starting point on slicing and tiling
The following shows VTM 3.0 performance over HM 16.19:

All Intra Main10
Over HM-16.19
Y U V EncT DecT
Class A1 -21.65% -36.75% -33.60% 1163% 173%
Class A2 -20.85% -23.30% -17.93% 1923% 169%
Class B -17.31% -23.05% -29.55% 2101% 169%
Class C -17.62% -22.65% -25.57% 2865% 161%
Class E -20.90% -25.39% -28.38% 1590% 146%
Overall -19.29% -25.68% -27.21% 1919% 164%
Class D -14.47% -18.51% -19.92% 3252% 158%
Class F
-17.76% -24.92% -27.37% 1727% 157%
(mandatory)
Page: 26 Date Saved: 2019-03-172019-03-14

Random Access Main 10
Over HM-16.19
Y U V EncT DecT
Class A1 -28.65% -42.56% -43.76% 498% 144%
Class A2 -32.73% -38.95% -33.94% 529% 137%
Class B -27.65% -40.16% -40.99% 517% 128%
Class C -22.59% -32.16% -34.22% 594% 126%
Class E
Overall -27.52% -38.26% -38.33% 535% 132%
Class D -21.82% -29.43% -31.05% 599% 142%
Class F
-21.90% -30.08% -31.64% 309% 101%
(mandatory)
Low delay B Main10

Over HM-16.19
Y U V EncT DecT
Class A1
Class A2
Class B -21.73% -32.19% -32.34% 495% 128%
Class C -18.62% -27.43% -28.89% 551% 123%
Class E -23.26% -30.48% -32.79% 270% 92%
Overall -21.08% -30.17% -31.30% 441% 116%
Class D -18.22% -23.75% -25.60% 502% 132%
Class F
-22.06% -32.28% -34.02% 281% 92%
(mandatory)
Low delay P Main10

Over HM-16.19
Y U V EncT DecT
Class A1
Class A2
Class B -26.26% -35.35% -35.39% 418% 133%
Class C -20.83% -28.44% -29.82% 458% 127%
Class E -26.08% -33.71% -35.83% 217% 99%
Overall -24.41% -32.64% -33.64% 366% 122%
Class D -19.88% -24.96% -26.36% 404% 131%
Class F
-21.49% -31.26% -33.44% 239% 94%
(mandatory)
The following table shows VTM 3.0 compared to VTM 2.1:

All Intra Main10
Over VTM 2.1
Y U V EncT DecT
Class A1 -0.77% -3.79% -4.99% 98% 97%
Class A2 -1.80% -2.69% -2.83% 102% 97%
Class B -1.42% -3.19% -4.84% 106% 97%
Class C -2.09% -3.89% -4.17% 107% 97%
Class E -1.91% -2.13% -2.96% 109% 94%
Overall -1.61% -3.19% -4.07% 104% 97%
Class D -1.16% -2.92% -3.38% 107% 94%
Class F
-1.89% -3.69% -4.61% 106% 95%
(mandatory)
Page: 27 Date Saved: 2019-03-172019-03-14

Random access Main10
Over VTM 2.1
Y U V EncT DecT
Class A1 -4.51% -5.28% -7.11% 137% 106%
Class A2 -6.45% -6.00% -5.64% 146% 94%
Class B -6.24% -6.66% -7.79% 145% 100%
Class C -5.76% -6.22% -7.07% 146% 102%
Class E
Overall -5.81% -6.14% -7.03% 144% 101%
Class D -5.85% -6.15% -6.69% 148% 94%
Class F
-3.52% -4.48% -5.07% 141% 92%
(mandatory)
Low delay B Main10

Over VTM 2.1
Y U V EncT DecT
Class A1
Class A2
Class B -3.46% -3.27% -4.87% 136% 96%
Class C -3.48% -3.71% -4.36% 138% 91%
Class E -3.18% -4.00% -3.70% 139% 83%
Overall -3.39% -3.60% -4.41% 137% 91%
Class D -3.08% -3.76% -5.51% 137% 83%
Class F
-3.38% -3.52% -4.58% 140% 83%
(mandatory)
Low delay P Main10

Over VTM 2.1
Y U V EncT DecT
Class A1
Class A2
Class B -3.48% -2.94% -3.98% 123% 95%
Class C -3.59% -3.35% -4.12% 125% 90%
Class E -2.56% -2.48% -2.08% 124% 84%
Overall -3.29% -2.96% -3.55% 124% 91%
Class D -3.38% -4.26% -5.44% 123% 81%
Class F
-2.54% -2.22% -3.03% 125% 82%
(mandatory)
Full results were attached to the AHG report as Excel files.

For each CE, a group was created in GitLab, and CE coordinators were given owner rights to the group.
This way they could clone the VTM as required, create branches for different tests, and assign user access
to the group themselves.
The CE development workflow was described at:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/wikis/Core-experiment-development-workflow
CE read access was available using shared accounts: One account was available for MPEG members,
which uses the usual MPEG account data (as announced on the appropriate email lists). A second account
was available for VCEG members. The account login information for VCEG members is available in the
TIES system:
https://www.itu.int/ifa/t/2017/sg16/exchange/wp3/q06/vceg_account.txt
Page: 28 Date Saved: 2019-03-172019-03-14

The bug tracker for the VTM and specification text is located at:
https://jvet.hhi.fraunhofer.de/trac/vvc
The bug tracker uses the same accounts as the HM software bug tracker. Users may need to log in again
due to the different sub-domain. For spam fighting reasons, account registration is only possible at the
HM software bug tracker at
https://hevc.hhi.fraunhofer.de/trac/hevc
Participants were requested to please file all issues related to the VVC reference software into the bug
tracker, and to try to provide all the details that are necessary to reproduce the issue. Patches for solving
issues and improving the software were said to always be appreciated.
 Continue to develop the VTM reference software
 Resolve any normative issues resulting from the large number of integrations in the most recent
development cycle
 Encourage people to test the VTM software more extensively outside of common test conditions.
 Encourage people to report all (potential) bugs that they are finding.
 Encourage people to submit bitstreams/test cases that trigger bugs in the VTM.
 Develop guidelines for SIMD code
In the discussion of the report, ticket #105 on the allowed mode combinations was noted, and the plan for
VTM v3.1 to be released during the meeting was noted.
Remarks on the CTC in the meeting discussion included:
 CPR is not enabled (it was remarked that perhaps this should be enabled for SCC test sequences)
 MTS is not enabled for inter (it was remarked that perhaps this should be enabled for low-resolution
test sequences)
JVET-M0004 JVET AHG report: Test material and visual assessment (AHG4) [T. Suzuki,
V. Baroncini, R. Chernyak, P. Hanhart, A. Norkin, J. Ye]
The test sequences used for the CfP and CTC are available on ftp://jvet@ftp.ient.rwth-aachen.de in
directory “/jvet-cfp” (accredited members of JVET may contact the JVET chairs for login information).
Due to copyright restrictions, the JVET database of test sequences is only available to accredited
members of JVET (i.e. members of ISO/IEC MPEG and ITU-T VCEG).
There was discussion that the current directory structure of test sequence ftp site is not good for the
current activities. The ftp directory was created during the preparation of the CfE and CfP, and the same
directory structure is still used. One possibility was suggested to re-design the directory as follows, for
example,
 ctc/ : Contains the active test set of the common testing conditions
 ahg/ : Contains subdirectories with sequences under consideration. The subfolder might be structured
by meeting period (e.g. named by the doc-number of the corresponding meeting report?)
 ce/ : Contains subdirectories for data exchange for specific CE (already implemented, see ce/JVET-
{K,L}1031_Deblocking
 upload : stays as before
Page: 29 Date Saved: 2019-03-172019-03-14

During the last meeting, there was a comment that all sequences, all classes should be at the same place.
But there is still meaningful to separate SDR, HDR, 360. Further detail should be discussed in the
meeting.
The AHG recommended:
 To discuss further ftp directory structure
 To continue to collect new test sequences available for JVET with licensing statement
It was noted that some test sequences had been submitted to the previous meeting, and that there was
especially some interest in improving the SCC test set. Side activity was encouraged to study that.
JVET-M0005 JVET AHG report: Memory bandwidth consumption of coding tools

(AHG5) [R. Hashimoto, T. Ikai, X. Li, D. Luo, H. Yang, M. Zhou]
The document summarized the activities of AHG on memory bandwidth consumption of coding tools
between the 12th and the 13th JVET meetings.
There is no related email discussion during this meeting cycle.
A patch on memory bandwidth measurement tools on VTM-3.0 has been provided by the AHG
https://jvet.hhi.fraunhofer.de/trac/vvc/ticket/121
Relevant contributions to this meeting were as follows.
 CE2.4 (affine motion / block restriction) and related contributions
o JVET-M0049 “CE2-related: A restriction on memory bandwidth consumption of affine
mode”, M. Zhou (Broadcom)
o JVET-M0150 “CE2.4.3: Affine restriction for worst-case memory bandwidth reduction”, L.
Pham Van, W.-J. Chien, H. Huang, V. Seregin, M. Karczewicz (Qualcomm)
o JVET-M0226 “CE2: Reducing worst-case memory bandwidth of affine mode (test 2.4.1)”,
Y.-W. Chen, X. Wang (Kwai Inc.)
o JVET-M0309 “CE2: Memory bandwidth reduction for affine mode (test 2.4.2)”, J. Li, R.-L.
Liao, C. S. Lim (Panasonic)
o JVET-M0311 “CE2-related: Memory bandwidth reduction for affine mode with less
dependency”, J. Li, R.-L. Liao, C. S. Lim (Panasonic)
o JVET-M0400, “CE2-related: Worst-case memory bandwidth reduction for VVC”, W.-J.
Chien, L. Pham Van, H. Huang, V. Seregin, M. Karczewicz (Qualcomm)
o JVET-M0472 “CE2: Affine sub-block size restrictions (Test 2.4.4)”, H. Chen, T. Solovyev,
H. Yang, J. Chen (Huawei)
o JVET-M0488 “CE2: Sub-block MV clip in affine prediction (test 2.4.5)”, M Gao, X Li, M
Xu, S Liu(Tencent)
o JVET-M0702 “CE2-related: Adaptive sub-block MV clip for affine blocks”, X. Li, M. Gao,
S. Liu (Tencent)
 CE4.5 (block size restriction) and related contributions
o JVET-M0313 “CE4: Motion compensation constraints for complexity reduction (test 4.5.1
and test 4.5.2)”, R.-L. Liao, J. Li, C. S. Lim (Panasonic)
o JVET-M0348 “CE4-related: Further reducing VVC memory bandwidth worst case by
combining 4x4/4x8/8x4 bi-prediction with AMVR”, X.W. Meng (Peking Univ.), X. Zheng
(DJI), S.S. Wang, S.W. Ma
Page: 30 Date Saved: 2019-03-172019-03-14

 Others
o JVET-M0357 “CE10-related: Reduction of the worst-case memory bandwidth and operation
number of OBMC”, Y. Kidani, K. Kawamura, K. Unno, S. Naito (KDDI)
The AHG recommended to review the related contributions.
JVET-M0006 JVET AHG Report: 360 video conversion software development (AHG6)
[Y. He, K. Choi]
This document summarized activities on 360-degree video content conversion software development
between the 12th (3–12 Oct. 2018) and the 13th (9–18 January 2019) JVET meetings.
A brief summary for these activities is as follows:
The 360Lib-8.0 software package included following changes:
 Projection format conversion:
o Chroma sample location type support (JVET-L0238).
 Configurations:
o Added chroma sample location type for the output in the encoding parameter settings.
Software:
 Fixed the compilation error reported by ticket #118 to support GCC 8.2.1.
360Lib-8.0 related release:
 360Lib-8.0rc1 with support of VTM-3.0rc1 was released on Nov. 16, 2018;
 360Lib-8.0 with support of VTM-3.0 was released on Nov. 22, 2018;
The 360Lib software is developed using a Subversion repository located at:
https://jvet.hhi.fraunhofer.de/svn/svn_360Lib/
The released version of 360Lib-8.0 can be found at:
https://jvet.hhi.fraunhofer.de/svn/svn_360Lib/tags/360Lib-8.0/
360Lib-8.0 testing results can be found at:
ftp.ient.rwth-aachen.de/testresults/360Lib-8.0
360Lib bug tracker
https://hevc.hhi.fraunhofer.de/trac/jem/newticket?component=360Lib
The first table below is for the projection formats comparison using VTM-3.0 according to 360 o video
CTC (JVET-L1012). It compares padded hybrid equi-angular cubemap (PHEC) coding and padded equi-
rectangular projection (PERP) coding using VTM-3.0.
VTM-3.0 PHEC vs PERP (VTM-3.0 PERP as anchor)

PHEC over PERP (VTM-3.0)
End-to-end WS-PSNR End-to-end S-PSNR-NN
Y U V Y U V
Class S1 -11.14% -8.48% -8.95% -11.06% -8.40% -8.90%
Class S2 -4.99% -5.50% -5.75% -4.97% -5.40% -5.67%
Overall -8.68% -7.29% -7.67% -8.62% -7.20% -7.61%
Page: 31 Date Saved: 2019-03-172019-03-14

The next table below is for PERP comparison between these two codecs.
VTM-3.0 PERP vs HM-16.16 PERP (HM-16.16 PERP as anchor)

VTM-3.0 PERP - Over HM-16.16 PERP
Y U V Y U V
Class S1 -21.25% -40.15% -40.88% -21.24% -40.15% -40.82%
Class S2 -29.62% -44.01% -44.94% -29.61% -44.03% -44.97%
Overall -24.60% -41.69% -42.50% -24.59% -41.70% -42.48%
The following table is to compare VTM-3.0 with PHEC coding and HM-16.16 with CMP coding.
VTM-3.0 PHEC vs HM-16.16 CMP (HM-16.16 CMP as anchor)

VTM-3.0 PHEC - Over HM-16.16 CMP
Y U V Y U V
Class S1 -25.82% -41.35% -41.88% -25.71% -41.32% -41.84%
Class S2 -32.70% -47.14% -48.10% -32.69% -47.13% -48.11%
Overall -28.57% -43.66% -44.37% -28.50% -43.65% -44.35%
The AHG recommended to continue software development of the 360Lib software package, to generate
CTC VTM anchors according to the 360° video CTC, and to finalize the reporting template for the
common test conditions.
JVET-M0007 JVET AHG report: Coding of HDR/WCG material (AHG7) [A. Segall,

E. François, D. Rusanovskyy]
This document summarized the activity of AHG7: Coding of HDR/WCG Material between the 12th
meeting in Macao, CN (3–12 October 2018) and the 13th meeting in Marrakech, MA (9–18 January
2019).
The AHG used the main JVET reflector, jvet@lists.rwth-aachen.de, with an [AHG7] indication on
message headers. The primary activity of the AhG was related to the mandates of arranging for a
demonstration event for viewing JVET-L0205 and JVET-L0245 and maintaining test content.
In the previous AHG study (as well as the previous JVET meeting), it was determined that it was unlikely
that HDR viewing equipment would be present at the Marrakech meeting due to meeting logistics. In
response to that, some HDR proponents proposed to have a demonstration event during the recent AHG
period. The goal of the demonstration event was to facilitate the viewing of JVET-L-0205 and JVET-
L0245.
During the AHG study period, several companies and locations were contacted to schedule such an event.
However, all contacts reported scheduling issues due to year-end HDR movie title releases as well as
industry preparation for the Consumer Electronics Show (CES). Because of these scheduling issues, no
event was held.
It was observed that the situation continues to enforce the importance of HDR content in current,
consumer entertainment and consumer electronic industries.
During the recent meetings, it has been determined that there are some inconsistencies in how the
copyright statements are managed within the HDR test sequences. For example, some sequences contain
the copyright statement as a text file, while other sequences include the copyright sequences in the last
frame of the sequence. During the AHG period, there was an effort to clean up and unify the copyright
Page: 32 Date Saved: 2019-03-172019-03-14

handling, with emphasis on the HLG content. While this did not affect the content of any sequence, it did
result in changing the md5sums for the sequences (in cases that had copyright frames). These changes
were also reflected in the CTCs.
There were 6 contributions identified as related to HDR video coding:
 JVET-M0032 CE12: Summary report on mapping functions [E. Francois, P. Yin]
 JVET-M0109 CE12-related: block-based in-loop reshaping [E. Francois, C. Chevance, F. Hiron
(Technicolor)]
 JVET-M0427 CE12: Mapping functions (test CE12-1 and CE12-2) [T. Lu, F. Pu, P. Yin, W. Husak,
S. McCarthy, T. Chen (Dolby)]
 JVET-M0580 Crosscheck of JVET-M0109 (CE12-related: block-based in-loop luma reshaping) [T.
Lu, P. Yin (Dolby)]
 JVET-M0640 CE12-related: in-loop reshaping with approximate inverse mapping function [E.
Francois (Technicolor)]
 JVET-M0703 Crosscheck of JVET-M0640 (CE12-related: in-loop luma reshaping with approximate
inverse mapping function) [T. Lu, P. Yin]
The AHG recommended to review the related input contributions and discuss whether a demonstration
and/or viewing event should be performed prior to (or at the) 14th JVET meeting.
JVET-M0008 JVET AHG report: 360° video coding tools and test conditions (AHG8)
[J. Boyce, K. Choi, P. Hanhart, J.-L. Lin]
This document summarized the activity of AHG8: 360º video coding tools and test conditions, between
the 12th meeting in Macao, CN (3–12 October 2018) and the 13th meeting in Marrakech, MA (9–18
January 2019).
There was no AHG email activity on the main jvet reflector, jvet@lists.rwth-aachen.de, with an [AHG8]
indication on message headers.
There were five non-CE related input documents identified (three contributions and one cross-check)
related to 360º video coding, which are listed below. In addition, CE13 on projection formats is related to
360º video coding, and has ten input documents, which are in the CE report in JVET-M0033. There are
four additional CE13-related input documents (three contributions and one cross-check) listed below.
 360 video contributions not related to CE13
o JVET-M0225 AHG8: On wrap around motion compensation [B. Choi, W. Feng, S. Liu
(Tencent)
o JVET-M0368 AHG8: 360Lib support for chroma sample location in PHEC blending process
[C.-H. Shih, Y.-H. Lee, J.-L. Lin, Y.-C. Chang, C.-C. Ju (MediaTek)
o JVET-M0452 AHG8: Hemisphere cubemap projection format [J. Boyce, M. Dmytrychenko
(Intel)
 Crosschecks of 360 video contributions not related to CE13
o JVET-M0644 Crosscheck of JVET-M0368 (AHG8: 360Lib support for chroma sample
location in PHEC blending process) [P. Hanhart (InterDigital)
 CE13-related contributions
o JVET-M0322 CE13-related: In-loop filters disabled across face discontinuities on PHEC with
2-pixel padding [Yule Sun, Xuchang Huangfu, Lu Yu (Zhejiang Univ.)
Page: 33 Date Saved: 2019-03-172019-03-14

o JVET-M0323 CE13-related: Adaptive QP to improve subjective quality for PHEC [Yule Sun,
Xuchang Huangfu, Lu Yu (Zhejiang Univ.)
o JVET-M0534 CE13-related: HEC with Pre-rotation + Adaptive Frame Packing(Test
4.2.a+4.1) [C. Pujara, A. Konda, A. Singh, R. Gadde, W. Choi, K. Choi, K.P. Choi(Samsung)
o JVET-M0547 360° coding tools using uncoded areas [J. Sauer, M. Bläser
 Crosschecks of 360 video contributions not related to CE13
o JVET-M0645 Crosscheck of JVET-M0534 (CE13-related: HEC with Pre-rotation + Adaptive
Frame Packing(Test 4.2.a+4.1)) [P. Hanhart (InterDigital)
The AHG recommended the following:
 Review input contributions
 Conduct informal subjective viewing of contributions
 Review common test conditions for 360° video, including objective metrics and viewports
 Review 360° video test material, and consider adding or replacing test sequences for common test
conditions
JVET-M0009 JVET AHG report: Neural Networks in Video Coding (AHG9) [S. Liu,
B. Choi, K. Kawamura, Y. Li, L. Wang, P. Wu, H. Yang]
This document summarized the activity of AHG9: neural networks in video coding between the 12th
meeting in Macao, CN (3–12 Oct 2018) and the 13th meeting in Marrakech, MA (9–18 Jan. 2019).
The AHG used the main JVET reflector, jvet@lists.rwth-aachen.de, with [AHG9] in message headers.
Subjects such as software sharing, training data and process, neural network structure and complexity,
etc. had been actively discussed among proponents and participants.
Some contributions to previous meetings were noted in the AHG report, with participants in the AHG
discussions. Following a BoG (see JVET-L0704 of the previous meeting) and plenary discussions in the
previous meeting, a Gitlab repository (https://vcgit.hhi.fraunhofer.de/jvet-l-ahg9/VVCSoftware_VTM)
had been set up for AHG9-related proponents to voluntarily share their software for interested parties to
explore. As of the beginning of the current meeting, proponents of two proposals had uploaded their
software: JVET-J0032 (by USTC) and JVET-L0242 (by Wuhan Univ.).
High resolution images in the DIV2K set (https://data.vision.ee.ethz.ch/cvl/DIV2K/) were used as the
base image dataset for offline training, which consists of 800 images for training, and 100 images for
validation. The original images (in RGB format) were first converted to YUV420 format, and then
compressed using QP values {22, 27, 32, 37} to generate the training images (in YUV420 format).
Proponents were welcome to use other image and video training datasets, for various purposes such as
inter frame prediction, or online training, etc. but should report the used training dataset clearly in their
proposals. A reporting template for describing the training stage was established. In the inference stage,
the coding schemes use the model parameters for prediction. Information to be provided about the
inference stage, with a reporting template, was described in the report. More details on the work are
described in JVET-L1006.
An informational contribution JVET-M0691 provided a summary of some AHG9 related coding tools
with compression performance and complexity analyses.
The organized tests were implemented on top of VTM3 and tests were conducted under the common test
conditions (CTC) for VTM3.
AHG9 related input documents for this meeting were identified as follows.
 JVET-M0159, AHG9: Convolutional neural network loop filter [Y.-L. Hsiao, C.-Y. Chen, T.-D.
Chuang, C.-W. Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
Page: 34 Date Saved: 2019-03-172019-03-14

 JVET-M0215, AHG9-related: CNN-based lambda-domain rate control for intra frames [Y. Li, D.
Liu, Z. Chen (USTC)]
 JVET-M0351, AHG9: Convolutional Neural Network Filter (CNNF) for Intra Frame [C. Lin, J. Yao,
L. Wang (Hikvision)]
 JVET-M0508, AHG9: Test Results of Dense Residual Convolutional Neural Network based In-Loop
Filter [Y. Wang, Z. Chen, Y. Li (Wuhan Univ.), L. Zhao, S. Liu, X. Li (Tencent)]
 JVET-M0510, AHG9: CNN-based in-loop filter proposed by USTC [Y. Dai, D. Liu, Y. Li, F. Wu
(USTC)]
 JVET-M0566, Adaptive convolutional neural network loop filter [H. Yin, R. Yang, X. Fang, S. Ma,
Y. Yu (Intel)]
 JVET-M0691, AHG9: Complexity analysis about neural network video coding tools [Y. Li, Z. Chen
(WHU), S. Liu (Tencent)]
The AHG recommended to review the related contributions and to continue investigating the benefits and
complexity of using neural networks in video coding.
JVET-M0010 JVET AHG report: Encoding algorithm optimizations (AHG10)

[A. M. Tourapis, A. Duenas, C. Helmrich, S. Ikonin, A. Norkin, R. Sjöberg]
The document summarized the activities of the AHG on encoding algorithm optimizations between the
12th meeting in Macao, CN (3–12 October 2018) and the 13th meeting in Marrakech, MA (9–18 January
2019).
No e-mail related to AHG10 activity was sent to the JVET reflector during the AHG period.
The following input documents were identified to be related to the AHG, which were summarized in the
report:
 JVET-M0083: AHG10: Quantization matrices for MTS
This contribution discusses the necessity of quantization matrices customized for MTS basis
functions. Differences in characteristics of transform coefficients between DCT2 and MTS basis
functions are shown. Then additional syntax to support quantization matrices customized for MTS is
proposed on top of the syntax for non-MTS (DCT2). This syntax is implemented in VTM3.0.
 JVET-M0090: On the use of chroma QP offsets in the VVC common test conditions
Since version 2 of the VTM reference software for the Versatile Video Coding (VVC) standard,
chroma QP offsets of value 1 have been used for testing according to the common test conditions
(CTC), but only in such (Intra) frames for which dual-tree coding has been enabled. This contribution
illustrates that, in comparison with the HEVC reference software, HM 16.x, the current VTM 3.x
version provides much higher BD-rate gains in the chroma channels than in the luma channel. To
counteract this uneven distribution of the coding gain, which was found to be perceptually
questionable, the contribution recommends to revert the CTC settings to the use of chroma QP offsets
of 1 not only in dual-tree frames but in all frames. Note that this modification has virtually no effect
on the all-Intra (AI) coding configuration (only the frame headers change by one bit) and does not
require changes to the draft VVC syntax specification, as currently published in JVET-L1001.
 JVET-M0091: Clean-up and finalization of perceptually optimized QP adaptation method in VTM
This contribution proposes a clean-up and a completion of the perceptually optimized QP adaptation
(QPA) algorithm already integrated into the VTM codec software. Specifically, the following points
are addressed:
o for HD and smaller input sequences, the previously employed reduction of the CTU size is
removed
Page: 35 Date Saved: 2019-03-172019-03-14

o for HD and smaller input, a depth-1 QPA (4 QPs per CTU) is used instead of the CTU size
reduction
o the QPA parameter apic is now defined as a function of the picture size instead of by a case-
statement
o an extension of the QPA algorithm for better visual handling of CTUs with glaring colors is
provided
o some remaining obsolete QPA related is code removed and some DC offset calculations are
unified.
The proposed changes, whose integration into the next VTM software version is suggested,
reportedly result in slightly reduced bitstream sizes for HD or smaller sequences and the Campfire
UHD sequence and reportedly provide between 1.7 and 2.5% additional luma BD-rate gain on the
random-access coded sequences of the SDR common test conditions (CTC). However, the proposal
does not affect the CTC since QPA is disabled by default.
 JVET-M0253: Non-CE8: Hash-based Motion Search
This contribution presents a hash-based motion search scheme for the VVC test model. For 4x4 to
64x64 square blocks and 4x8, 8x4 blocks, a hash table is generated for each reference picture. A
hash-based block matching is then performed before existing motion estimation for those block sizes.
When a block finds its match, the following motion estimation can be skipped. For TGM sequences,
experimental results report 9.6% and 18.87% coding gain for RA and LD_B, with encoding time
reduced to 89% and 88%. When CPR is on, 7.81% and 14.91% coding gain is reported, with
encoding time reduced to 91% and 89%.
 JVET-M0323: CE13-related: Adaptive QP to improve subjective quality for PHEC
This contribution proposes a geometry based adaptive QP method together with in-loop filters
disabled across face discontinuities and padding (padding of 2 samples around face row) on PHEC.
Boundary areas are coded with better quality by using lower QP to further reduce visible artefacts.
The experimental results show that the proposed method can significantly improve subjective quality
with some coding loss in objective performance.
 Crosscheck of JVET-M0083 (AHG10: Quantization matrices for MTS)
This contribution reports cross-check results of JVET-M0083 which is AHG10: Quantization
matrices for MTS which is extended into MTS compared to the one in the Macau meeting. The
simulation was conducted with VTM-3.0 under Common Test Conditions. It was confirmed that the
test results were matched with those proponents provided.
 JVET-M0428: Encoder optimization with deblocking filter
A deblocking filter is included in VTM-3.0 to apply to reconstructed pixels in order to reduce the
blocking artefacts between blocks. However, the encoder of VTM-3.0 doesn’t apply deblocking filter
in rate distortion optimization (RDO). In this contribution, to enhance the coding performance,
deblocking filter is applied during RDO, such that distortion is calculated between filtered
reconstructed samples and original ones. Test results reportedly show 0.58%, 0.71% and 0.66% luma
gain with similar encoding and decoding time, in AI, RA and LDB configuration respectively over
VTM-3.0 anchor.
 JVET-M0466: Adaptive Streaming Test Conditions for VTM
This document describes a proposal for an additional set of test conditions to be included in the
Common Test Conditions (CTC), referred to as Adaptive Streaming Random Access (AS-RA). The
test conditions proposed are intended to simulate a video streaming scenario, which is characterized
by the availability of multiple streams of the same video content at the server side, obtained by an
offline encoding of the input video at distinct bit rates/qualities/resolutions. The goal of the proposed
Page: 36 Date Saved: 2019-03-172019-03-14

test conditions is to cover this use case, currently missing in the CTC, with less than 50% of the
computational cost of the current Random Access CTC for classes A1/A2 and B.
 JVET-M0511: Bug fix for rate control under all-intra in VTM software
In VVC Common Test conditions, a TemporalSubsampleRatio value is set to be 8 under all intra
configuration. This strategy is to simplify the testing procedure. For example, the sequence
FoodMarket4 has totally 300 frames, when coding in all intra configuration, only 38 frames are
extracted and coded. And the actual frame rate is the original sequence frame rate set in the config file
divided by 8. However, as the the sequence original frame rate takes the value of 50 fps or 60 fps.
Both two numbers are indivisible by 8. So how to represent the actual frame rate is an option. In
VTM, the actual frame rate is implicitly regarded as a float number when printing out the statistic
information of bit-rate. However, in case of rate control is enabled, the actual frame rate is explicitly
set as a int number, by a successive rounding operation of the division. This inconsistency makes the
target bits calculated by the bit-rate a bit different from the actually coded bits, from which the bit-
rate is calculated. In this document, we propose to explicitly set the actual frame rate to be a float
number in case of TemporalSubsampleRatio is enabled.
 JVET-M0600: AHG10: Quality dependency factor based rate control for VVC
This contribution presents some improvements based on the current rate control scheme proposed in
JVET-K0390. With the proposed quality dependency factor based bit allocation algorithm, when
using the anchor bit rate of VTM 3.0 as the target, there are 0.34%/3.45%/3.02% for Y/U/V coding
efficiency improvements in random access (RA) configuration when compared with the rate control
algorithm in JVET-K0390.
The AHG recommended that the related input contributions be reviewed and recommended to further
continue the study of encoding algorithm optimizations in JVET.
JVET-M0011 JVET AHG report: Screen Content Coding (AHG11) [S. Liu, J. Boyce,
A. Filippov, Y.-C. Sun, J. Xu, M. Zhou]
This document summarized the activity of AHG11: Screen Content Coding between the 12th meeting in
Macao, CN (3–12 Oct 2018) and the 13th meeting in Marrakech, MA (9–18 Jan. 2019).
The AHG used the main JVET reflector, jvet@lists.rwth-aachen.de, with [AHG11] in message headers.
There were about a dozen emails exchanged on the JVET reflector with some discussions about testing
sequences. There were also some email discussions about the interaction between CPR and inter coding
tools adopted in Macao. Through the discussions, some mismatches between software VTM3 and spec
VVC Draft 3 were identified. Some possible solutions are suggested in JVET-M0409. More in-depth
technical discussions were carried in CE8 mailing list.
In total there were 26 CPR related technical contributions, 8 Palette related technical contributions, and 7
other SCC related technical contributions identified for this meeting that were noted in the report:
 CPR related:
o JVET-M0151, CE8-related: Virtual search area for current picture referencing (CPR) [L.
Pham Van, T. Hsieh, W.-J. Chien, V. Seregin, H. Wang, M. Karczewicz (Qualcomm)
o JVET-M0174, CE8-related: Removal of subblock-based chroma MC in CPR [C.-Y. Lai, T.-
D. Chuang, Y.-L. Hsiao, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
o JVET-M0175, CE8-related: Clarification on interaction between CPR and other inter coding
tools [C.-Y. Lai, T.-D. Chuang, Y.-L. Hsiao, C.-Y. Chen, Y.-W. Huang, S.-M. Lei
(MediaTek)]
o JVET-M0254, Non-CE8: Subblock Operation Removal for Chroma CPR [J. Xu, K. Zhang,
L. Zhang, H. Liu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
Page: 37 Date Saved: 2019-03-172019-03-14

o JVET-M0325, CE8-related: CPR with previous CTU availability at frame and tile edge [C.
Rosewarne, A. Dorrell (Canon)] – Later withdrawn
o JVET-M0326, CE8-related: Remove the redundancy of CPR-related syntax coding [S. Ye, F.
Chen, L. Wang (Hikvision)]
o JVET-M0327, CE8-related: A new CPR syntax scheme [S. Ye, F. Chen, L. Wang
(Hikvision)]
o JVET-M0332, CE8: Block vector prediction for CPR (test 8.1.1a and test 8.1.1b) [J. Nam, J.
Lim, S. Kim (LGE)]
o JVET-M0333, Non-CE8: Coding on block vector difference [J. Nam, J. Lim, S. Kim (LGE)]
o JVET-M0334, Non-CE8: Removal of redundant syntax between CPR and other inter coding
tools [J. Nam, J. Lim, S. Kim (LGE)]
o JVET-M0335, Non-CE8: modification on SbTMVP process regarding with CPR [H. Jang, J.
Nam, S. Kim, J. Lim (LGE)]
o JVET-M0336, Non-CE11: Considering boundary strength on CPR coded block boundary [H.
Jang, J. Nam, S. Kim, J. Lim (LGE)]
o JVET-M0341, Non-CE8: MMVD harmonization with CPR [H. Jang, J. Nam, S. Kim, J. Lim
(LGE)]
o JVET-M0393, Non-CE8: chroma block vector initialization for CPR in dual tree [T. Poirier,
F. Le Léannec, F. Galpin (Technicolor)]
o JVET-M0402, Non-CE8: Proposed Cleanup for Current Picture Referencing [B. Heng, M.
Zhou, W. Wan (Broadcom)]
o JVET-M0407, CE8: CPR reference memory reuse without increasing memory requirement
(CE8.1.2a and CE8.1.2d) [X. Xu, X. Li, S. Liu (Tencent), E. Chai (Ubilinx)]
o JVET-M0408, CE8: CPR reference memory reuse with reduced memory requirement
(CE8.1.2b and CE8.1.2c) [X. Xu, X. Li, S. Liu (Tencent), E. Chai (Ubilinx)]
o JVET-M0409, Non-CE8: Mismatch between text specification and reference software on
ATMVP candidate derivation when CPR is enabled [X. Xu, X. Li, S. Liu (Tencent), W.-J.
Chien, M. Karczewicz (Qualcomm)]
o JVET-M0410, Non-CE8: CPR flag signalling at slice level [X. Xu, X. Li, S. Liu (Tencent)]
o JVET-M0411, Non-CE8: Inter mode related flag signalling when current picture is the only
reference picture [X. Xu, X. Li, S. Liu (Tencent)]
o JVET-M0418, CE8-related: Context modeling on pred_mode_flag when current picture is the
only reference picture (CPR) [Yu-Chen Sun, Jian Lou (Alibaba)]
o JVET-M0474, CE8.1.3: Extended CPR reference with 1 buffer line [L. Pham Van, V.
Seregin, W.-J. Chien, T. Hsieh, M. Karczewicz (Qualcomm)]
o JVET-M0483, CE8-related: CPR mode signalling and interaction with inter coding tools [W.-
J. Chien, V. Seregin, M. Karczewicz (Qualcomm)]
o JVET-M0541, Non-CE8: Combination of MMVD and CPR mode [Y. Li, Z. Chen (Wuhan
Univ.), X. Xu, S. Liu (Tencent)]
o JVET-M0542, Non-CE8: Combination of Multi Hypothesis Intra and CPR mode [Y. Li, Z.
Chen (Wuhan Univ.), X. Xu, S. Liu (Tencent)]
Page: 38 Date Saved: 2019-03-172019-03-14

o JVET-M0544, Non-CE8: CPR with chroma 4x4 sub-block size when dual-tree is on [X. Xu,
X. Li, S. Liu (Tencent)]
 Palette related:
o JVET-M0050, Palette Mode in HEVC (test 8.2.1) [Y.-C. Sun, J. Lou (Alibaba), Y.-H. Chao,
H. Wang, V. Seregin, M. Karczewicz (Qualcomm)]
o JVET-M0051, CE8: Palette Mode and Intra Mode Combination (test 8.2.2) [Y.-C. Sun, J.
Lou (Alibaba)]
o JVET-M0052, CE8: Separate Palette Coding for Luma and Chroma (test 8.2.5) [Y.-C. Sun, J.
Lou (Alibaba), Y.-H.n Chao, H. Wang, V. Seregin, M. Karczewicz (Qualcomm),
R.Chernyak, S. Ikonin, J. Chen (Huawei)[
o JVET-M0417, CE8-related: Combination test of CE8.2.2 and CE8.2.5 [Y.-C. Sun, J. Lou
(Alibaba)]
o JVET-M0419, CE8-related: Context modeling on palette mode flag [Y.-C. Sun, J. Lou
(Alibaba)]
o JVET-M0455, CE8: Palette index map scan order constraints (Test 8.2.3) [J. Ye, X. Xu, M.
Xu, X. Li, S. Liu (Tencent)]
o JVET-M0456, CE8: palette mode when dual-tree is enabled (Test 8.2.4) [J. Ye, X. Xu, X. Li,
S. Liu (Tencent)]
o JVET-M0457, CE8: Palette predictor list enhancement (Test 8.2.6) [J. Ye, X. Xu, M. Xu, X.
Li, S. Liu (Tencent)]
 Other:
o JVET-M0056, CE8: BDPCM with LOCO-I and independently decodable areas (test 8.3.1a)
[F. Henry, A. Mohsen (Orange), P. Philippe, G. Clare (bcom)]
o JVET-M0057, CE8: BDPCM with horizontal/vertical predictor and independently decodable
areas (test 8.3.1b) [F. Henry, M. Abdoli (Orange), P. Philippe, G. Clare (bcom)]
o JVET-M0058, CE8: BDPCM with modified binarization (test 8.3.2) [F. Henry, M. Abdoli
(Orange), G. Clare, P. Philippe (bcom)]
o JVET-M0253, Non-CE8: Hash-based Motion Search [J. Xu, J. Li, K. Zhang, L. Zhang
(Bytedance), R. Xiong (Peking Univ.)]
o JVET-M0365, Non-CE3: modified PDPC for horizontal and vertical modes [A. Filippov, V.
Rufitskiy, J. Chen (Huawei)]
o JVET-M0449, CE8-related: BDPCM entropy coding with reduced number of context coded
bins [M. Xu, X. Li, X. Xu, M. Gao, S. Liu (Tencent)]
o JVET-M0464, Non-CE8: Unified Transform Type Signalling and Residual Coding for
Transform Skip [B. Bross, T. Nguyen, P. Keydel, H. Schwarz, D. Marpe, T. Wiegand (HHI)]
The AHG recommended to review all related contributions, to continue investigating SCC coding tool
performance, complexity and interactions between themselves and with other coding tools, and to
continue evaluating new and modified test materials and consider including some of them in Class F.
See also the notes for AHG3 relating to a desire to improve the SCC test sequences.
Page: 39 Date Saved: 2019-03-172019-03-14

JVET-M0012 JVET AHG report: High-level parallelism and coded picture regions
(AHG12) [T. Ikai, M. M. Hannuksela, R. Sjöberg, R. Skupin, W. Wan, Y.-K.
Wang, S. Wenger]
The document summarized activities of AHG on High-level parallelism and coded picture regions
between the 12th and the 13th JVET meetings.
Related contributions to this meeting were categorized as follows:
 Flexible size tiles
o JVET-M0066 AHG12: Flexible Tile Partitioning [Y. Yasugi, T. Ikai (Sharp)]
o JVET-M0423 Cross-check of JVET-M0066: AHG12: Flexible Tile Partitioning [A.
Wieckowski (HHI)]
o JVET-M0376 AHG12: On signalling of flexible tiles [M. Damghanian, R. Sjöberg, M.
Pettersson (Ericsson)]
o JVET-M0459 AHG12: On tiles with partial CTUs [R. Skupin, K. Suehring, Y. Sanchez, T.
Schierl (HHI)]
o JVET-M0527 AHG12: Comments on Tiles and Flexible Tile Partitioning [W. Wan, M. Zhou,
T. Hellman, B. Heng, P. Chen (Broadcom)]
o JVET-M0530 is also related to the flexible tile size.
 Tile partitioning and signalling (extraction also related)
o JVET-M0121 AHG12: On Rectangular Tile Group [Y. He, A. Hamza (InterDigital)]
o JVET-M0123 AHG12: On hierarchical tile design [Y. He, A. Hamza (InterDigital)]
o JVET-M0129 AHG12: On flexible tiling [Y.-K. Wang, Hendry, M. Sychev (Huawei)]
o JVET-M0130 AHG12: On tile grouping [Y.-K. Wang, Hendry, J. Chen, M. Sychev
(Huawei)]
o JVET-M0134 AHG12: On explicit signalling of tile IDs [Hendry, Y.-K. Wang, J. Chen, M.
Sychev (Huawei)]
o JVET-M0137 AHG12: On tile configuration signalling [M. Sychev, Hendry, Y.-K. Wang
(Huawei)]
o JVET-M0160 AHG17: Flexible tile grouping for VVC [L. Chen, T.-D. Chuang, Y.-W.
Huang, S.-M. Lei (MediaTek)]
o JVET-M0261 AHG12: On grouping of tiles [M. M. Hannuksela, A. Aminlou (Nokia)]
o JVET-M0373 AHG12: Merge friendly tile group address signalling [R. Sjöberg, M.
Damghanian, M. Pettersson (Ericsson)]
o JVET-M0374 AHG12: Flexible tiles to support MCTS use cases [R. Sjöberg, M.
Damghanian, M. Pettersson (Ericsson)]
o JVET-M0375 AHG12: On uniform tile spacing, M. Damghanian [R. Sjöberg, M. Pettersson
(Ericsson)]
o JVET-M0388 AHG12/AHG17: On merging of MCTSs for viewport-dependent streaming
[M. M. Hannuksela (Nokia)]
o JVET-M0416 AHG12: On Tile Information Signalling [S. Deshpande (Sharp)]
o JVET-M0430 AHG12: On Tiles and Tile Groups for VVC [R. Skupin, K. Suehring, Y.
Sanchez, T. Schierl (HHI)]
Page: 40 Date Saved: 2019-03-172019-03-14
o JVET-M0530 AHG12: On signalling of tiles [M. Coban, M. Karczewicz (Qualcomm)]
 Motion constraint tile (inter) and high level signalling
o MCTS
 JVET-M0136 AHG12: Treating tile and tile group boundaries as picture boundaries
[J. Chen, Y.-K. Wang, Hendry, M. Sychev (Huawei)]
 JVET-M0445 AHG12: On motion constrained tiles for VVC [R. Skupin, V. George,
K. Suehring, Y. Sanchez, T. Schierl (HHI)]
o Nal unit level signalling
 JVET-M0155 AHG12: On tile group identification for VVC [B. Choi, S. Wenger, S.
Liu (Tencent)]
 JVET-M0536 AHG12: On picture-level tiles and sequence-level tiles for VVC [E.
Thomas, A. Gabriel (TNO)]
 Wrap around tile (intra)
o JVET-M0209 AHG12: On tile group configuration [W. Choi, K. Choi, K. Choi (Samsung)]
 Specific tool changes for tile
o JVET-M0300 CE4-related: HMVP and parallel processing with tiles and tile groups [A. M.
Kotra, J. Chen, B. Wang, S. Esenlik, H. Gao (Huawei)]
o JVET-M0325 CE8-related: CPR with previous CTU availability at frame and tile edge [C.
Rosewarne, A. Dorrell (Canon)] – Later withdrawn
 WPP related
o JVET-M0070 AHG12: Wavefront processing in a tile group [T. Ikai, S. Deshpande, T.
Chujoh, E. Sasaki, T. Aono (Sharp)]
o JVET-M0071 AHG12: Improved parallel processing capability with WPP [Y. Fujimoto, M.
Ikeda, T. Suzuki (Sony)]
o JVET-M0593 Crosscheck of JVET-M0071 (AHG12: Improved parallel processing capability
with WPP) [Y. Yasugi, T. Ikai (Sharp)]
The AHG recommended to review the related contributions.
JVET-M0013 JVET AHG report: Tool reporting procedure (AHG13) [W.-J. Chien,
J. Boyce, R. Chernyak, R. Hashimoto, Y.-W. Huang, S. Liu, D. Luo]
This document summarized the activity of AHG13: “Tool reporting procedure” between the 12th Meeting
in Macao, CN (3–12 Oct. 2018) and the 13th meeting in Marrakech, MA (9–18 Jan. 2019). Tool on/off
experimental results vs. VTM anchor are provided for the tools specified in JVET-L1005.
The initial version of JVET-L1005 “Methodology and reporting template for tool testing” was provided
on Oct 27th. The document contained a reporting template.
All tests described in JVET-L1005 were conducted, except 67IPM and PDPC. VTM tool tests were
conducted on VTM-3.0 software with VTM configuration by switching off specific tool either in
configuration files or macros. Tool tests of 67IPM and PDPC were not conducted because there was no
associated configuration setting nor associated macros in VTM-3.0 in order to disable the coding tools.
The tested tools, testers, and cross-checkers are listed in the tables below.
Page: 41 Date Saved: 2019-03-172019-03-14

Tool Name Abbrev. Document AI RA LD Tester Crosscheck
Name reference(s)
Tzu-Der Wei-Jung
Chuang Chien
Chroma dual CST JVET-K0230, X X X (peter.chuang (wchien@qti
tree JVET-K0556 @mediatek.co .qualcomm.c
m) om)
Wei-Jung
Yuwen He
Chien
Dependent JVET-K0072, (yuwen.he@i
DQ X X X (wchien@qti.
quantization JVET-L0274 nterdigital.c
qualcomm.co
om)
m)
JVET-K0190, Roman
JVET-L0085, Shan Liu
Cross- Chernyak
JVET-L0136, (shanl;
component CCLM X X X (chernyak.ro
JVET-L0191, leolzhao@
linear model man@huawei
JVET-L0338, tencent.com)
.com)
JVET-L0340,
JVET-K0171,
JVET-K0173, Wei-Jung
Shan Liu
JVET-K0096, Chien
multiple (shanl;
MTS JVET-L0059, X X X (wchien@qti
transform set xinzzhao@
JVET-L0111, .qualcomm.c
tencent.com)
JVET-L0118, om)
JVET-L0285,
67 intra
prediction Roman
mode +6 MPM JVET-K0529, Shan Liu
Chernyak
intra mode JVET-K0368, (shanl;
67IPM X X X (chernyak.ro
coding + Wide JVET-L0165, xinzzhao@
man@huawe
angle intra JVET-L0279 tencent.com)
i.com)
prediction (test
not available)
Position Wei-Jung
dependent Shan Liu
Chien
prediction (shanl;
PDPC JVET-K0063 X X X (wchien@qti
combination leolzhao@
.qualcomm.c
(test not tencent.com)
om)
available)
JVET-K0371, Wei-Jung
JVET-L0082, Yuwen He
Chien
Adaptive loop JVET-L0083, (yuwen.he@i
ALF X X X (wchien@qti.
filter JVET-L0147, nterdigital.c
qualcomm.co
JVET-L0392, om)
m)
JVET-L0664
JVET-L0045,
JVET-L0047,
JVET-L0142, Roman
Shan Liu
JVET-L0265, Chernyak
Affine motion (shanl;
AFF JVET-L0260, X X (chernyak.ro
model guichunli@
JVET-L0271, man@huawei
tencent.com)
JVET-L0632, .com)
JVET-L0694
Page: 42 Date Saved: 2019-03-172019-03-14

JVET-K0346,
subblock- JVET-L0055, Wei-Jung
Shan Liu
based JVET-L0104, Chien
SbTMV (shanl;
temporal JVET-L0195, X X (wchien@qti
P guichunli@
merging JVET-L0257, .qualcomm.c
tencent.com)
candidates JVET-L0369, om)
JVET-L0468
Wei-Jung
Shan Liu
Adaptive Chien
JVET-K0357, (shanl;
motion vector AMVR X X (wchien@qti
JVET-L0377, guichunli@
resolution .qualcomm.c
tencent.com)
om)
Wei-Jung
Kiho Choi
History based JVET-L0106, Chien
(kiho14.choi
motion vector HMVP JVET-L0158, X X (wchien@qti
@samsung.co
prediction JVET-L0266 .qualcomm.c
m)
om)
Tzu-Der Roman
Pairwise Chuang Chernyak
merge PMC JVET-L0090 X X (peter.chuang (chernyak.ro
candidate @mediatek.co man@huawe
m) i.com)
Kiho Choi Shan Liu
Triangular JVET-L0124, (kiho14.choi (shanl;
TAP X X X
partition JVET-L0208 @samsung.co leolzhao@
m) tencent.com)
Tzu-Der
Kiho Choi
Chuang
Bi-directional (kiho14.choi
BDOF JVET-L0256 X X (peter.chuan
optical flow @samsung.co
g@mediatek.
m)
com)
Tzu-Der
Chuang
(peter.chuan
g@mediatek.
Kiho Choi
Combined com)
(kiho14.choi
intra/inter CIIP JVET-L0100 X X
@samsung.co
prediction Roman
m)
Chernyak
(chernyak.ro
man@huawe
i.com)
Roman
Kiho Choi
Chernyak
Merge with (kiho14.choi
MMVD JVET-L0054 X X (chernyak.ro
MVD @samsung.co
man@huawe
m)
i.com)
Wei-Jung
Yuwen He
Bi-predictive Chien
(yuwen.he@i
weighted BPWA JVET-L0646 X X (wchien@qti
nterdigital.co
averaging .qualcomm.c
m)
om)
Roman
Shan Liu
Multi- Chernyak
(shanl;
reference line MRLP JVET-L0283 X X X (chernyak.ro
xinzzhao@
prediction man@huawe
tencent.com)
i.com)
Current Shan Liu Yuwen He

CPR JVET-L0293 X X X
picture (shanl; (yuwen.he@i
Page: 43 Date Saved: 2019-03-172019-03-14

xiaozhongxu
nterdigital.c
referencing* @
om)
tencent.com)
* indicates a tool-on test against the VTM-3.0 anchor.
The results of the tests are summarized in the tables below. The spreadsheet attached to the AHG report
provides additional data. Scatter plots are also provided for the tested tools in random access
configuration, comparing PSNR-Y based bd-rate on the Y axis vs. each of Enc runtime ratio, Dec runtime
ratio, and a weighted average of Enc and Dec runtime ratio, (Enc + a*Dec)/(a+1), with a configurable
weight, a. The exemplary weighting is set to 6 and can be adjusted in the spreadsheet attached to this
report.
Full experimental results and configuration files can be found at the link below:
https://hevc.hhi.fraunhofer.de/svn/svn_VVCTestConfig/branches/VTM-3.0/
There were no bit rate or PSNR differences between testers and cross-checkers.
Encoder and Decoder runtime ratios provided by both the testers and cross-checkers were included in the
reporting template, to identify whether there were significant runtime differences.
Simulation results in all-intra configuration (AI) of VTM tool “off” test. (VTM anchor)
AI
Tester Tester XChecker XChecker
Abbreviation BDR-Y BDR-U BDR-V EncTime DecTime EncTime DecTime
CST 2.14% -3.28% -2.62% 129% 102% 131% 99%
DQ 1.91% 1.15% 0.86% 82% 101% 84% 101%
CCLM 2.07% 18.76% 18.66% 99% 100% 99% 100%
MTS 2.81% 2.35% 2.38% 47% 85% 47% 84%
ALF 2.25% 3.05% 3.18% 99% 88% 100% 90%
MRLP 0.54% 0.26% 0.28% 95% 98% 95% 103%
CPR -0.27% -0.40% -0.33% 137% 100% 133% 100%
SAO 0.30% 0.41% 0.72% 100% 101% 100% 98%
Simulation results in random access configuration (RA) of VTM tool “off” test. (VTM anchor)
RA
CST 0.30% 2.44% 2.58% 101% 101% 100% 100%
DQ 1.66% 0.51% 0.06% 95% 102% 96% 102%
CCLM 0.95% 16.61% 16.67% 99% 100% 100% 103%
MTS 1.26% 1.14% 1.28% 90% 97% 89% 98%
ALF 3.68% 3.54% 3.15% 100% 87% 101% 87%
AFF 2.57% 1.85% 1.79% 89% 98% 89% 97%
SBTMC 0.53% 0.42% 0.48% 100% 99% 100% 99%
AMVR 0.88% 1.39% 1.41% 91% 101% 91% 101%
HMVP 0.42% 0.49% 0.49% 102% 100% 101% 100%
PMC 0.13% 0.07% 0.05% 100% 100% 100% 100%
TAP 0.37% 0.66% 0.67% 90% 101% 90% 103%
BDOF 1.19% 0.39% 0.26% 93% 96% 91% 93%
CIIP 0.47% 0.23% 0.28% 96% 100% 95% 100%
MMVD 0.86% 0.63% 0.65% 89% 101% 88% 100%
BPWA 0.44% 0.65% 0.66% 97% 101% 97% 100%
Page: 44 Date Saved: 2019-03-172019-03-14

MRLP 0.26% 0.13% 0.14% 99% 97% 99% 100%
CPR 0.09% -0.01% 0.05% 100% 100% 99% 99%
SAO 0.71% 1.21% 1.17% 104% 102% 102% 99%
Simulation results in low-delay B configuration (LDB) of VTM tool “off” test. (VTM anchor)
RA
CST 0.15% -0.54% -0.03% 101% 100% 100% 101%
DQ 1.48% 0.86% -0.31% 95% 103% 96% 101%
CCLM 0.08% 4.25% 4.67% 100% 100% 100% 105%
MTS 0.34% 0.54% 0.67% 96% 102% 96% 100%
ALF 2.59% 3.38% 3.40% 101% 89% 101% 89%
AFF 2.10% 1.34% 1.51% 82% 96% 81% 95%
SBTMC 0.63% 0.73% 0.57% 100% 97% 101% 99%
AMVR 0.54% 0.94% 0.97% 87% 101% 89% 101%
HMVP 0.25% 0.21% 0.28% 100% 98% 102% 102%
PMC 0.01% -0.08% -0.11% 100% 103% 100% 100%
TAP 0.89% 1.19% 1.18% 88% 104% 87% 104%
CIIP 0.47% 0.54% 0.59% 96% 102% 95% 100%
MMVD 0.21% 0.09% -0.02% 95% 99% 95% 100%
BPWA 0.31% 0.29% 0.25% 96% 100% 97% 101%
MRLP 0.12% 0.16% 0.15% 100% 98% 100% 100%
CPR 0.14% 0.26% 0.01% 107% 99% 106% 100%
SAO 1.41% 3.25% 4.20% 101% 97% 100% 98%
Pixel usage and memory bandwidth results of VTM tool “off” test. (VTM anchor)
AI RA LDB
Abbreviatio Pixel Ave mem Max mem Ave mem Max mem
n usage Pixel usage BW BW Pixel usage BW BW
CCLM 51% 3% 1%
ALF 99% 62% 59%
AFF 24% 28%
SBTMC 16% 95% 94% 15% 97% 98%
AMVR 4% 102% 102% 2% 101% 100%
TAP 2% 100% 5% 98%
BDOF 42% 98%
CIIP 2% 99% 2% 100%
MMVD 10% 99% 8% 98%
BPWA 10% 100% 100% 7% 100% 99%
MRLP 7% 1% 0%
Page: 45 Date Saved: 2019-03-172019-03-14

PSNR-Y vs encoding runtime ratio of VTM with VTM tool “off” test (VTM anchor) are shown in the
figure below.
4.00% VTM : PSNR-Y vs Enc runtime ratio CST

DQ
3.50% CCLM
MTS
3.00% ALF
AFF
2.50%
SBTMC
AMVR
HMC
2.00%
PMC
TAP
1.50%
BDOF
CIIP
1.00% MMVD
BPWA
0.50% MRLP
CPR
0.00%
SAO
85% 88% 90% 93% 95% 98% 100% 103% 105%
Page: 46 Date Saved: 2019-03-172019-03-14

PSNR-Y vs decoding runtime ratio of VTM with VTM tool “off” test (VTM anchor) is shown in the
figure below.
VTM : PSNR-Y vs Dec runtime ratio

4.00%
CST
DQ
3.50% CCLM
MTS
ALF
3.00%
AFF
SBTMC
2.50%
AMVR
HMC
2.00% PMC
TAP
1.50%
BDOF
CIIP
MMVD
1.00%
BPWA
MRLP
0.50% CPR
SAO
0.00%
85% 88% 90% 93% 95% 98% 100% 103% 105% 108% 110%
Page: 47 Date Saved: 2019-03-172019-03-14

PSNR-Y vs weighted runtime ratio (a = 6) of VTM with VTM tool “off” test (VTM anchor) is shown in
the figure below.
VTM : PSNR-Y vs Dec runtime ratio

CST
4.00%
DQ
CCLM
3.50%
MTS
ALF
3.00% AFF
SBTMC
2.50% AMVR
HMC
2.00% PMC
TAP
1.50%
BDOF
CIIP
MMVD
1.00%
BPWA
MRLP
0.50%
CPR
SAO
0.00%
85% 88% 90% 93% 95% 98% 100% 103% 105% 108% 110%
A related contribution was noted to be the following:

 JVET-M0111 AHG13: On bi-prediction with weighted averaging and weighted prediction [Y. Ye, J.
Chen, M. Yang (Alibaba), P. Bordes, E. Francois (Technicolor)]
For two topics, testing was not performed because this part of the design could not be disabled in the
software:
 67 intra prediction mode +6 MPM intra mode coding + Wide angle intra prediction
 Position dependent prediction combination
 Consider the reported tool test results during tool adoption decision making
 Review related contributions
 Refine list of tested tools and test methodology for the next meeting cycle
 Consider the reported tool test results as a benchmark for CE tests
 Consider including reporting of compute system information for testers and cross-checkers
 Consider additional performance or complexity metrics
It was remarked that decisions need to be made regarding which features can be disabled, and it is
difficult to measure the benefit for a feature if it cannot be turned off. See also the AHG15 report on this
topic.
[Check integration of glossary terms]
Page: 48 Date Saved: 2019-03-172019-03-14

JVET-M0014 JVET AHG report: Progressive intra refresh (AHG14) [J.-M. Thiesse,
A. Duenas, K. Kazui, A. Tourapis]
This document summarized the activities of the AhG on progressive intra refresh between the 12th and
13th JVET meetings.
An AHG14 kick-off email was sent on 17 December 2018.
A Gitlab repository had been setup for the AHG participants (https://vcgit.hhi.fraunhofer.de/jvet-l-ahg-
14/VVCSoftware_VTM). The software based on VTM 3.0 with changes proposed in contributions JVET-
M0197 and JVET-M0387 was shared in respective branches for review by participants.
Relevant contributions to this meeting were identified as follows:
 JVET-M0197 “AHG14: Software for ultra low-latency encoding” [K. Kazui (Fujitsu)]
 JVET-M0387 “AHG14: Updates on Intra Refresh Proposal” [J.-M. Thiesse, D. Gommelet, D.
Nicholson (Vitec)]
 JVET-M0529 “AHG14: Normative Recovery Point Indication” [M. Pettersson, R. Sjöberg, M.
Damghanian (Ericsson)]
Another related contribution is:
 JVET-M0871 AHG14: Performance Evaluation by CTU based Intra Refresh [K. Kawamura, S. Naito
(KDDI)] [late]
The AhG recommended to:
 Review the related contributions.
 Combine all proposed software modifications in AHG software (a Gitlab branch).
 Agree on common test conditions for progressive intra refresh.
 Integrate the encoder-only modifications in the next VTM.
JVET-M0015 JVET AHG report: Bitstream decoding properties signalling (AHG15)

[J. Boyce, J. Chen, S. Deshpande, M. Karczewicz, A. Tourapis, Y.-K. Wang,
S. Wenger]
This AHG report was not available when the meeting began, so its consideration was deferred. As the
report indicated little activity, it was not discussed in detail but was made available for consideration.
This document summarizes the activity of AHG15: Bitstream decoding properties signalling, between the
between the 12th meeting in Macao, CN (3–12 October 2018) and the 13th meeting in Marrakech, MA,
9–18 January 2019.
There was no email activity on the reflector for this AHG during this period. Although when the AHG
was established, a phone conference call was indicated as a possibility, but because of lack of activity, no
phone conference call was held. One related contribution was noted in the AHG report:
 JVET-M0451 Update to interoperability point syntax [J. Boyce (Intel)]
 Review contributions
 Consider high-level syntax location(s) for tool restriction syntax
Page: 49 Date Saved: 2019-03-172019-03-14

JVET-M0016 JVET AHG report: Implementation studies (AHG16) [M. Zhou, J. An,
E. Chai, K. Choi, S. Sethuraman, T. Hsieh, X. Xiu]
This document summarized the activity of AHG16: implementation studies, between the 12th JVET
meeting in Macao, CN (3–12 October 2018) and the 13th JVET meeting in Marrakech, MA (9–18
January 2019).
There were not many email exchanges on the main JVET email reflector (jvet@lists.rwth-aachen.de) with
an [AHG16] indication on message headers. A summary of the AHG activities was provided as follows:
Feedback provided during the finalization of CE descriptions:
 Multiple hypothesis inter prediction (MHIP): It was suggested to test coding efficiency impact after
the line buffer for motion vectors of the additional hypotheses is removed and the total number of
distinct reference frames is constrained to 2 for the hypotheses. This is captured in the CE10
description.
 Decoder-side motion vector refinement (DMVR): It was suggested to take the following elements as
the baseline DMVR algorithm, i.e.
o Block sizes for DMVR W*H=64 && H>=8 && W*H<=1024
o Reference block size (w+7)*(h+7) (for luma)
o Integer DMVR
o MV mirroring between list0 and list1 to allow bilateral matching
o 25 points SAD-based integer-pel search (i.e. +/− 2 refinement search range)
o “Parametric error surface equation” based sub-pel refinement
o Refined MVs used for MC only
o Luma/chroma MC w/ reference block padding (if needed)
Additional tests were recommended to quantify the benefits of the following DMVR elements in the
context of VTM3.0:
o Mean removed SAD (MRSAD)
o Bilateral interpolation
o Use of the refined MVs from the top neighbouring CTUs for merging/AMVP/TMVPs/de
blocking
o and splitting a large block to multiple of 16x16 sub-blocks for the DMVR
o The suggestion above is integrated into in the CE9 description.
 Bi-directional optical flow (BDOF aka. BIO): It was commented that it is desirable to avoid the
processing irregularity in the extended area during the prediction block generation for the BIO. In the
current design the bilinear filters are used in the extended area. If the 8-tap MC filters are consistently
used for the prediction block generation including the extended area, the reference block padding
should be used to avoid memory bandwidth increase. Such a test is already planned in CE9.
 Overlapped motion compensation (OBMC): It was suggested to test OBMC when current block is
uni-prediction and the neighbouring blocks only use uni-prediction to generate OBMC region. When
testing sub-block OBMC combined with affine mode, it is suggested to only do blending for top one
line and left one column without doing blending for right column and bottom line. Such tests are
planned in CE10.
 Current picture referencing (CPR, aka. IBC): It was commented that sharing the line buffer in the de-
blocking filter for IBC will likely lead to the local memory increase (to avoid memory access
Page: 50 Date Saved: 2019-03-172019-03-14

conflicts between the de-blocking and the IBC). This is generally agreed and reflected in the final
CE8 description.
 Planar motion vector prediction (PMVP): It was commented that using 8x8 sub-block size (or 8x8 for
bi-pred and 8x4/4x8 for uni-pred) is most relevant for the CE tests. It is also desirable to avoid further
stressing the merging list derivation process and signal the PMVP mode separately (as opposed to
signalling it as an additional merging candidate. This comment might be valid for the regression-
based motion vector field (RMVF) too). Such tests are planned in CE2.
Other general comments from the report:
 Flexible tiling is reported to have a profound impact on block-level decoder implementation and was
recommended to be carefully studied. Potential implications include the increased VDPU processing
rate, the increased memory bandwidth if tiling is not VDPU aligned vertically, the increased buffering
for frame compression, for in-loop filters and for TMVP storage, and the increased VDPU memory
addressing overhead.
 (Affine) merging/AMVP list derivation is a block by block sequential operation within a CTU.
Throughput study was reported to be needed to make sure that the current VTM3.0 design meets the
throughput requirement (e.g. cycle budget of ~50 cycles per 8x8 block for 4K@60 at ~400 MHz
clock rate).
 Separate luma/chroma partitioning tree was reported to introduce a long latency for chroma intra
prediction when the CCLM is on. In the worst case, the chroma intra prediction cannot be kicked off
until the whole 64x64 luma block is reconstructed (e.g. when a 64x64 luma block is split horizontally
while the chroma blocks are split vertically, and vice versa). Suggest quantifying the gain of separate
tree on the top of CCLM to see whether the CCLM and the separate tree can be made mutually
exclusive.
 2x2 chroma intra-prediction itself was reported to be a serious concern from the throughput and
processing overhead point of view, given the fact that the CCLM made the luma/chroma intra-
prediction sequential, the luma intra prediction has been made more complicated (e.g. 4-tap
interpolation filters, PDPC), and the combined intra/inter prediction was already adopted into the
intra prediction/reconstruction critical path. It is helpful to test whether the CCLM can be disabled for
4x4 PUs.
 New tools such as diffusion filters, local illumination compensation (LIC), Hadamard transform
domain/bilateral filtering of reconstructed blocks, and combined intra/inter prediction were all
reported to be in the critical path of the intra prediction/reconstruction loop. Given the CCLM, PDPC
and combined intra/inter prediction that are already adopted, the additional tools that could be
absorbed into this loop is likely very limited from the throughput point of view. Therefore, the
benefits of those tools should be carefully studied against each other.
 Line buffer removal from the Adaptive Loop Filter (ALF) was reported to be a significant cost
reduction which should be pursued.
 The current design of the Bi-directional optical flow (BDOF aka. BIO) was reported to prohibit the
64x64-based decoder pipeline due to the early termination which requires a SAD computation up to
128x128 block size.
 32x32/32x16/16x32 DST7/DCT8 based transform units were reported to be the bottleneck for the
implementation of primary transforms.
 Transform coefficients “Zero out” of large TUs (e.g. 64x64/32x64/64x32) should reportedly be
enforced at the syntax-level to avoid unnecessary CABAC context storage on the decoder side.
 Combination of Current Picture Referencing (CPR, aka. IBC) with other tools was reported to require
careful thinking. CPR combinations with triangle prediction, bi-prediction, weighted prediction, GBI
prediction, BDOF and OBMC will require replication of those motion compensation logics into the
intra prediction/reconstruction block. Moreover, using other tools (e.g. MMVD) to signal a CPR
Page: 51 Date Saved: 2019-03-172019-03-14

vector or using the CPR vectors as neighbouring spatial and/or temporal candidates may further
complicate the logic of the (affine) merging/AMVP list derivations due to additional CPR-related
checks.
Broadcom conducted a memory bandwidth study on multiple hypothesis inter prediction by running both
the CE software provided by HHI and the VTM3.0 with a commercial motion compensation cache model
integrated. The summary results for the random access configuration are provided in the tables below.
Effect of multiple hypothesis inter prediction (up to using 4 reference frames)
TCM_dif ABW_dif
Y U V f f MBW_diff MBW_I MBW_D MBW_E
Class A1 -0.24% -0.46% -0.36% 1.81% 1.70% 2.58% 91.67% 8.33% 0.00%
Class A2 -0.16% -0.16% 0.05% 0.77% 0.83% 7.59% 75.00% 16.67% 8.33%
Class B -0.52% -0.13% -0.16% 2.05% 1.92% 4.42% 90.00% 0.00% 10.00%
Class C -0.14% 0.01% -0.03% 0.87% 0.82% 1.86% 75.00% 12.50% 12.50%
Class D -0.08% 0.00% 0.06% 0.45% 0.43% 0.00% 50.00% 37.50% 12.50%
Class E
Class F -0.62% -0.43% -0.32% 0.49% 0.78% 6.56% 62.50% 6.25% 31.25%
All -0.29% -0.16% -0.12% 1.07% 1.08% 7.59% 83.33% 8.33% 8.33%
Effect of multiple hypothesis inter prediction (up to using 2 reference frames)

ABW_dif MBW_dif
Y U V TCM_diff f f MBW_I MBW_D MBW_E
Class A1 -0.10% -0.33% -0.15% 0.95% 0.87% 0.97% 75.00% 16.67% 8.33%
Class A2 -0.11% -0.09% 0.09% 0.45% 0.54% 0.32% 58.33% 25.00% 16.67%
Class B -0.37% -0.03% -0.16% 0.87% 0.80% -1.29% 70.00% 10.00% 20.00%
Class C -0.12% -0.04% -0.06% 0.33% 0.28% -0.70% 50.00% 37.50% 12.50%
Class D -0.09% -0.05% -0.06% 0.09% 0.11% 4.04% 37.50% 56.25% 6.25%
Class E
Class F -0.57% -0.29% -0.28% 0.27% 0.40% 3.12% 62.50% 12.50% 25.00%
All -0.20% -0.10% -0.08% 0.49% 0.50% 4.04% 63.33% 21.67% 15.00%
The following contributions were identified as relevant to the AHG.

 JVET-M0527, “AHG12: Comments on Tiles and Flexible Tile Partitioning” [W. Wan, M. Zhou, T.
Hellman, B. Heng, P. Chen (Broadcom)]
o Elaborated the potential implications of the flexible tiling on decoder designs.
 Contributions aiming for addressing the 64x64 decoder pipeline issue of the BDOF (aka. BIO)
o JVET-M0284, “CE9-related: BDOF Modifications to Enable 64x64 VPDU” [H. Chen, X.
Ma, S. Esenlik, H. Yang, J. Chen (Huawei)]
o JVET-M0073, “Non-CE9: On early termination for BIO” [K. Kondo, M. Ikeda, T. Suzuki
(Sony)]
o JVET-M0249”, Non-CE9: Modifications on Bi-Directional Optical Flow” [H. Liu, L. Zhang,
K. Zhang, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
 Contributions relating to ALF line buffer reduction
o JVET-M0164, “Adaptive loop filter with virtual boundary processing” [C.-Y. Chen, T.-D.
Chuang, Z.-Y. Lin, C.-Y. Lai, Y.-W. Huang, S.-M. Lei (MediaTek)]
o JVET-M0301, “Non-CE: Loop filter line buffer reduction” [A. M. Kotra, S. Esenlik, B.
Wang, H. Gao, J. Chen (Huawei)]
Page: 52 Date Saved: 2019-03-172019-03-14

 Contributions aiming to prohibit the transform coefficients from being transmitted in the “zero-out”
regions of 64x64/64x32/32x64 transform units at the syntax level
o JVET-M0250, “Non-CE7: Simplified CSBF coding for large block-size transforms” [J. Choi,
J. Heo, S. Yoo, J. Choi, L. Li, J. Lim, S. Kim (LGE)]
o JVET-M0257, “CE7-related: coefficient scanning and last position coding for TUs of greater
than 32 width or height” [M. Coban, M. Karczewicz (Qualcomm)]
 Contributions relating to CPR vector usage and CPR combination with other tools
o JVET-M0402, “Non-CE8: Comments on Current Picture Referencing” [B. Heng, M. Zhou,
W. Wan (Broadcom)]
o JVET-M0175, “CE8-related: Clarification on interaction between CPR and other inter coding
tools” [C.-Y. Lai, T.-D. Chuang, Y.-L. Hsiao, C.-Y. Chen, Y.-W. Huang, S.-M. Lei
(MediaTek)]
o JVET-M0483, “CE8-related: CPR mode signalling and interaction with inter coding tools”
[W.-J. Chien, V. Seregin, M. Karczewicz (Qualcomm)]
 JVET-M0046, “CE6-related: A study of primary transforms” [M. Zhou, Y. Hu (Broadcom)]
o Identified the 32-point DST7/DCT8 as a bottleneck for the implementation of primary
transforms and recommended a “zero-out” solution.
 JVET-M0245, “AHG16-related: Chroma block coding and size restriction” [C. Rosewarne, A.
Dorrell (Canon)]
o JVET-M0065 Non-CE: Intra chroma partitioning and prediction restriction [T. Zhou, T. Ikai
(Sharp)]
o Removal of 2x2/2x4/4x2 block sizes from the chroma intra prediction (for the separate tree
case only)
 JVET-M0248, “AHG16: Motion compensation with padded samples for small coding units” [H. Liu,
J. Chon, H.-C. Chuang, L. Zhang, K. Zhang, J. Xu (Bytedance)]
o Memory bandwidth reduction for motion compensation of small size PUs.
o There are many other contributions in this category.
 JVET-M0265, “AHG16: Clean-up on MV Rounding” [K. Zhang, L. Zhang, H. Liu, J. Xu, Y. Wang,
P. Zhao, D. Hong (Bytedance)]
o Discusses design consistency of the MV rounding.
The AHG recommended reviewing the input contributions.
JVET-M0017 JVET AHG report: High-level syntax (AHG17) [R. Sjöberg, S. Deshpande,

M. M. Hannuksela, R. Skupin, Y.-K. Wang, S. Wenger]
This document summarized the activities of the AHG on High-level syntax (HLS) between the 12th JVET
meeting in Macao, CN (3–12 Oct. 2018) and the 13th meeting in Marrakech, MA (9–18 Jan. 2019).
No e-mail related to AHG17 was sent to the JVET reflector during the AHG period except a kick-off
message.
It was reported that the amount of input contributions related to the mandates of this AHG has increased
from 8 in Macau to 22 for this meeting. For the wider category of high-level syntax contributions
including AHG12, AHG14, AHG15 and AHG17, the number of input contributions is reported to have
increased from 28 in Macau to 50 for this meeting. Note that the count differs from the JVET-
Page: 53 Date Saved: 2019-03-172019-03-14

M_Notes_d0.docx categorization in which 49 documents are allocated to section 6.19 “High-level
syntax”.
It is reported that of the 12 JCT-VC meetings where the first version of HEVC was developed, the first 6
meetings had fewer high-level syntax contributions than this JVET meeting and the last 6 had a higher
number with a peak of 96 of high-level syntax contributions at the 11th meeting in Stockholm 2012.
The number of documents in the high-level syntax category was noted to have increased from 8 to 50 in
two meeting cycles.
22 of the input documents registered by January 7 were identified as related to the mandates of this AHG.
 JVET-M0101 AHG17: On VVC HLS [R. Skupin, K. Suehring, Y. Sanchez (HHI),M. M. Hannuksela,
K. Kammachi-Sreedhar (Nokia), Y.-K. Wang, Hendry (Huawei), S. Wenger, B. Choi (Tencent), S.
Deshpande (Sharp), R. Sjöberg (Ericsson)]
 JVET-M0120 AHG17: Proposed NAL Unit Header Design Principles [S. Wenger, B. Choi, S. Liu
(Tencent)]
 JVET-M0128 AHG17: On reference picture management for VVC [Y.-K. Wang, Hendry (Huawei),
S. Deshpande (Sharp), M. M. Hannusela (Nokia), G. Ryu, W. Choi (Samsung), X. Wang, Y.-W.
Chen (Kawi), L. Zhang (Bytedance), P. Wu, M. Li (ZTE), S.-H. Kim (LG), J. Boyce (Intel), A. M.
Tourapis, D. Singer (Apple), F. Edouard, P. Andrivon (Technicolor), Y.-W. Huang, C.-W. Hsu, C.-Y.
Chen, T.-D. Chuang, L. Chen (MediaTek), K. Kawamura (KDDI), Y.-C. Sun, J. Lou (Alibaba)]
 JVET-M0131 AHG17: On NAL unit types for IRAP pictures and leading pictures [Y.-K. Wang,
Hendry (Huawei)]
 JVET-M0132 AHG17: On header parameter set (HPS) [Y.-K. Wang, Hendry, J. Chen (Huawei)]
 JVET-M0133 AHG17: On parsing dependency between parameter sets [Y.-K. Wang (Huawei), J.
Boyce (Intel)]
 JVET-M0152 AHG17: On random access point for VVC [B. Choi, S. Wenger, S. Liu (Tencent)]
 JVET-M0153 AHG17: On leading picture for VVC [B. Choi, S. Wenger, S. Liu (Tencent)]
 JVET-M0154 AHG17: On decoded picture buffer management for VVC [B. Choi, S. Wenger, S. Liu
(Tencent)]
 JVET-M0156 AHG17: On component type indication for VVC [B. Choi, S. Wenger, S. Liu
(Tencent)]
 JVET-M0157 AHG17: On picture order count for VVC [B. Choi, S. Wenger, S. Liu (Tencent)]
 JVET-M0160 AHG17: Flexible tile grouping for VVC [L. Chen, T.-D. Chuang, Y.-W. Huang, S.-M.
Lei (MediaTek)]
 JVET-M0161 AHG17: Signalling random access properties in the NAL unit header [L. Chen, C.-W.
Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
 JVET-M0260 AHG17: Carriage of tile group header parameters in higher level structures [M. M.
Hannuksela (Nokia)]
 JVET-M0377 AHG17: Picture header NAL unit type [R. Sjöberg, M. Damghanian, M. Pettersson
(Ericsson)]
 JVET-M0378 AHG17: RPS for VVC [R. Sjöberg, M. Damghanian, M. Pettersson (Ericsson)]
 JVET-M0386 AHG17: On slice_type (tile_group_type) [K. Suehring, Y. Sanchez, R. Skupin (HHI)]
 JVET-M0388 AHG12/AHG17: On merging of MCTSs for viewport-dependent streaming [M. M.
Hannuksela (Nokia)]
Page: 54 Date Saved: 2019-03-172019-03-14

 JVET-M0415 AHG17: Comments on High-Level Syntax of VVC [S. Deshpande (Sharp)]
 JVET-M0520 AHG17: On NAL unit header design for VVC [S. Wenger, B. Choi, S. Liu]
 JVET-M0537 AHG17: On signalling of tile group set with MCTS properties (NAL unit header and
new parameter set) [E. Thomas, A. Gabriel (TNO)]
 JVET-M0579 On Frame Rate Support and Extraction in VVC [A. Segall, S. Deshpande (Sharp Labs
of America), M. Hannuksela (Noka)]
It was noted that at some point in the HEVC development, we started having AHG pre-meetings for HLS
work.
The AHG recommended reviewing the related input contributions and to continue to study VVC high-
level syntax aspects.
4 Project development (10)

Contributions in this category were discussed XXday XX March XXXX–XXXX (chaired by XXXqq).
4.1 Text and general standard development (0)
4.2 Software development (1)

JVET-M0055 AHG3: VTM transcoding capabilities for bit rate matching and debugging
[T. Hinz, A. Wieckowski (HHI)]
Presented Thu 17 January 2040 (chaired by F. Bossen).
The VTM contains extensions allowing for effective troubleshooting by faster debugging as well as
alternative capabilities for bit rate matching. Both of these functionalities are implemented by
incorporating the decoder into the encoder, effectively allowing transcoding of existing bitstreams,
possibly switching to actual encoding at a predefined point. The purpose of this document is to highlight
and document these, as well as to propose a further extension allowing to switch between transcoding and
encoding with per-CTU rather than per-frame granularity.
The usage should be documented in the VTM SW package (to be added as a mandate to AHG3).
Decision (SW): Adopt.
4.3 Common test conditions (1)

CPR in CTC?
[Ensure reflected in notes: CPR and hash search enabled for Class F. This hash search is for ordinary
inter, not just CPR. CPR also has a hash search, but a different one.]
JVET-M0090 On the use of chroma QP offsets in the VVC common test conditions
[C. Helmrich, H. Schwarz, D. Marpe, T. Wiegand (HHI)]
Discussed Thursday 17 January ~2200 (GJS & F. Bossen).
Since version 2 of the VTM reference software for the Versatile Video Coding (VVC) standard, chroma
QP offsets of value 1 have been used for testing according to the common test conditions (CTC), but only
in (Intra) frames for which dual-tree coding has been enabled. This contribution reports that, in
comparison with the HEVC reference software, HM 16.x, the current VTM 3.x version provides much
higher BD-rate gains in the chroma channels than in the luma channel. To counteract this uneven
Page: 55 Date Saved: 2019-03-172019-03-14

distribution of the coding gain, which was found to be perceptually questionable, it is recommended to
revert the CTC settings to the use of chroma QP offsets of 1 not only in dual-tree frames but in all frames.
Note that this modification has virtually no effect on the all-Intra (AI) coding configuration (only the
frame headers change by one bit).
Currently:
 for the all-Intra (AI) configuration, the BD-rate gain in chroma is about 7% higher than that in luma,
 for the random-access (RA) configuration, the gain in chroma is about 11% higher than that in luma.
As proposed:
 for the AI configuration, the BD-rate gain in chroma remains 7% higher than the gain in luma,
 for the RA configuration, the gain in chroma now is about 5–6% higher than the gain in luma.
A comment was to consider low QP.
In some experiments, the contributor found that it was also perceptually better to increase the chroma QP
offset.
With this change, we would also no longer have a different setting for different frame types.
Decision (CTC): Adopt (effect is AI: no change, RA: 1% benefit for luma 8% degradation for chroma,
LB: 0.8% benefit for luma and 17% degradation for chroma).
4.4 Coding studies on specific use cases (8)

Contributions on this topic were discussed in Track A Monday 14 January 2015–2240 (chaired by GJS)
except as noted.
4.4.1 Adaptive resolution change
JVET-M0135 On adaptive resolution change (ARC) for VVC [Hendry, Y.-K Wang,
J. Chen (Huawei), T. Davies, A. Fuldseth (Cisco), Y.-C Sun, T.-S Chang,
J. Lou (Alibaba)]
This contribution discusses use cases or application scenarios that it was asserted would benefit from an
adaptive resolution change (ARC) capability where the spatial resolution may change at a non-IRAP
picture. A preliminary design of ARC was presented and suggested to be a place-holder just to trigger the
discussion. It was proposed that the support of ARC for VVC be discussed, and if there is sufficient
interest, either to start a CE or include aspects of ARC support as one or more mandates of an AHG.
The need to switch may be motivated by wanting to reduce bit rate – being required to send an I frame is
obviously a problem for that purpose.
 Rate adaption in video telephony and conferencing
 Active speaker change in multi-party video conferencing
 Fast start in streaming
 Adaptive stream switching in streaming
The basic tools constraints for supporting ARC are as follows:
 The spatial resolution may differ from the nominal resolution by a factor 0.5, applied to both
dimensions. The spatial resolution may increase or decrease, yielding scaling ratios of 0.5 and 2.0.
 The aspect ratios and chroma formats of the video format are not changed.
 The cropping areas are scaled in proportion to spatial resolutions.
Page: 56 Date Saved: 2019-03-172019-03-14

 The reference pictures are simply re-scaled as needed and inter prediction is applied as usual.
It is proposed to use simple, zero-phase separable down- and up-scaling filters. Note that these filters are
for prediction only; a decoder may use more sophisticated scaling for output purposes.
The following 1:2 down-scaling filter is used, which has zero phase and 5 taps:
( −1, 9, 16, 9, −1 ) / 32
The down-sampling points are at even sample positions and are co-sited. The same filter is used for luma
and chroma.
For 2:1 up-sampling, additional samples at odd grid positions are generated using the half-pel motion
compensation interpolation filter coefficients in the latest VVC WD.
The combined up- and down-sampling will not change phase or the position of chroma sampling points.
This can be considered a coding efficiency feature (esp. for subjective benefit).
A suggested alternative was spatial pre-filtering in the encoder while sending a higher resolution. This
could be tested as an alternative. The technique known as “reduced resolution update” was also noted as
an alternative.
It was commented that this would also be a natural element of scalable coding. With this an reference
picture selection, this is basically all that is needed to support spatial scalability.
Further study in an AHG was encouraged. See also JVET-M0259.
JVET-M0259 Use cases and proposed design choices for adaptive resolution changing
(ARC) [M. M. Hannuksela, A. Aminlou (Nokia)]
The following high-level design choices were proposed for VVC version 1:
1. It was proposed to include a reference picture resampling process in VVC version 1 for the following
use cases:
 Usage of efficient prediction structures (e.g. so-called open groups of pictures) in adaptive
streaming without compromising from the fast and seamless representation switching capability
between representations of different properties, such as different spatial resolutions.
 Adapting low-delay conversational video content to network conditions and application-
originated resolution changes without significant delay or delay variation.
2. The VVC design was proposed to allow merging of a sub-picture originating from a random-access
picture and another sub-picture originating from a non-random-access picture into the same coded
picture conforming to VVC. This is asserted to enable efficient handling of viewing orientation
changes in mixed-quality and mixed-resolution viewport-adaptive 360° streaming. This design choice
is discussed also in JVET-M0388.
3. It was proposed to include a sub-picture-wise resampling process in VVC version 1. This was
asserted to enable efficient prediction structure for more efficient handling of viewing orientation
changes in mixed-resolution viewport-adaptive 360° streaming.
Section 5.13 ("Support for Adaptive Streaming") of MPEG N 17074 was reported to include the
following requirement for VVC:
The standard shall support fast representation switching in the case of adaptive streaming services
that offer multiple representations of the same content, each having different properties (e.g. spatial
resolution or sample bit depth). The standard shall enable the use of efficient prediction structures
(e.g. so-called open groups of pictures) without compromising from the fast and seamless
representation switching capability between representations of different properties, such as different
spatial resolutions.
The contribution suggested that using this with a CRA picture can provide a gradual quality change.
Page: 57 Date Saved: 2019-03-172019-03-14

See also the prior JCT-VC contribution JCTVC-F158 (T. Davies/Cisco) of July 2011.
Region-wise mixed resolution encoding, including the use of MCTSs, was described. Using the region-
wise packing SEI message with MCTSs can reportedly provide mixed-resolution viewport-dependent
streaming for 360° video content and is described in an informative annex of the OMAF standard.
It was commented that DASH has something called stream structure ID that supports stream switching
without resolution change.
Further study in an AHG was encouraged. See also JVET-M0135.
4.4.2 Gradual decoder refresh / ultra-low latency

See also JVET-M0529.
JVET-M0197 AHG14: Software for ultra low-latency encoding [K. Kazui (Fujitsu)]

Presented Thursday 17 January 1850 (chaired by F. Bossen).
This contribution proposes software modifications for integrating encoder-only progressive intra refresh
in the VTM model, in accordance with the mandates of AHG14 “Progressive intra refresh”. The proposed
software modifications are the use of flexible tile partitioning in JVET-M0066 and the methods described
in JVET-L0079 “AHG14: Study of methods for progressive intra refresh”.
Version 2 contains two additional test results. The first one is the comparison with low-delay B. The
second one is the comparison with the proposal with normative changes.
Each CTU row is partitioned into 2 tiles, a “refreshed tile” and a “not-refreshed tile”.
Significant overhead was reported: +29% for LDB (RA results were incomplete).
The contribution suggested some normative changes to reduce the overhead.
This proposes to use the provided software for future AHG14 experiments.
No action was taken on this except to encourage AHG14 to consider / decide on the desirability and use
of the proposed software. It could be uploaded to an AHG14 space on Gitlab.
JVET-M0387 AHG14: Updates on Intra Refresh Proposal [J.-M. Thiesse, D. Gommelet,

D. Nicholson (VITEC)] [late]
This contribution reported an update of the software modifications for the study of progressive intra
refresh (used in AHG14). This code had been made available in the AHG Gitlab repository (see the
AHG14 report). Both encoder-only modifications and a normative solution have been reported to VTM
3.0.1 with handling of new tools adopted at the Macao meeting. The corresponding performance is
reportedly in the same range as the results presented at the Macao meeting, with a loss of 21.29% in
average for the encoder-only modifications against a low-delay B reference with a comparable intra
Page: 58 Date Saved: 2019-03-172019-03-14

period of 32 for classes B, C and E. The normative proposal reportedly brings an improvement of
approximately 5.26% (test results for classes C and E; class B data not available) against an encoder-only
modification solution by adding identify the position of the intra refresh area and then exploit this
position for decoding process.
Test conditions were proposed for further AHG activity.
It was also proposed to integrate the proposed encoder-only modifications for intra-refresh support on
VTM 4.
In the proposed normative approach, there is a disabling of the loop filter at the boundary of the refresh
area and avoidance of MVs that reference potentially corrupted samples. Tiles can be used with disabling
of the loop filter at tile boundaries.
The proposal used whole-picture encoding. It was asked whether that is appropriate for what is intended
as ultra-low-delay operation. This implies a whole picture of latency.
The refresh was not using whole-CTU refresh; it was using CU-level intra. It was saving the sending of a
couple of CU-level flags based on a signalled width for the refresh region. There was discussion of
whether that aspect is desirable and provides any meaningful bit rate savings by itself.
It was suggested to consider thicker refresh regions, perhaps not spanning the whole picture vertically.
This would present a much less severe restriction on motion vectors. Using an adaptive-size region was
also suggested.
Part of the measured gain seems to be based on the use of a fine-granularity refresh area.
The application usage was discussed. Suggested applications were multicast real-time communication,
video gaming, surveillance, drone video, remote driving, remote display.
It did not yet seem fully clear whether the proposed method is appropriate and the testing conditions are
reasonable.
JVET-M0871 AHG14: Performance Evaluation by CTU based Intra Refresh

[K. Kawamura, S. Naito (KDDI)] [late]
This contribution was presented Thursday 17 January at 1830 (chaired by F. Bossen).
This contribution reports a performance evaluation of a CTU-based intra refresh approach as information.
While the anchor condition candidate in JVET-L0160 used a CU line as a granularity of the refresh area,
this contribution used a CTU line. For 1080p content, CTU size was set to 64 instead of 128 to produce
an intra refresh period of 30 frames. The preliminary simulation results reportedly showed 7.4% Y-BD
rate loss compared to with/without the intra refresh coding condition. This contribution also suggests to
change the intra refresh period to 30 frames instead of 32 frame.
This was presented for information only. No action was taken on it.
4.4.3 Adaptive streaming and cross-RAP referencing
JVET-M0360 Video coding based on cross RAP referencing (CRR) [H. Yu, X. Gao,
Q. Yuan, X. Lin, L. Yu (Zhejiang Univ.), Y. Fan, Y. Zhao, H. Yang, Y.-K.
Wang, J. Chen (Huawei)] [late]
This contribution proposes an approach to allow inter prediction referencing across random access points
(RAPs), referred to as cross-RAP referencing (CRR). Simulation results reportedly show BD coding gains
in the range from 11.21% to 25.91% based on VTM3.0 in VVC CTC and from 19.6% to 37.38% based
on HM16.15 in HEVC CTC. A brief description of signalling, decoding process, and random access
operations is provided. It is proposed to start a CE on this.
The idea of a “library picture” provided by external (unicast) means and referenced across what are
otherwise random access points was described.
Page: 59 Date Saved: 2019-03-172019-03-14

This proposed scheme does not have any “drift”.
It was noted that the DRAP concept as specified in an HEVC SEI message (see JCTVC-S0095) has a
close relationship to this.
It was asked what impact on syntax this would have. It was remarked that, with system support for
managing the library, this seems possible with the current syntax (e.g., using long-term reference
pictures – possibly more than one of them).
System support would be required no matter what, as the system needs to deliver the library pictures.
Possibly some property indicator could be used to assist – e.g., an SEI message that just indicates that no
following pictures in decoding and/or output order will refer to any previous pictures in decoding that are
not in the RPS of the current picture.
Further study in an AHG was encouraged to study the properties of such an approach and determine
whether this or similar functionality would need to have some impact on the syntax or decoding process.
Such an impact does not seem strictly necessary for basically achieving this usage, given appropriate
systems support, but may be determined helpful in some way in further study. It was suggested for
systems experts to also study this and determine whether file-format / DASH / other system support
should be specified for this sort of usage.
JVET-M0855 Crosscheck of JVET-M0360 (Video coding based on cross RAP referencing

(CRR)) [H. Liu (Bytedance)] [late]
JVET-M0466 Adaptive Streaming Test Conditions for VTM [M. Afonso, A. Norkin,

A. Aaron, J. Sole, K. Swanson (Netflix), Y. Ye, W. Jiang (Alibaba), J. Kim,
K. Kolarov, D. Singer, A. Tourapis (Apple)]
This contribution was presented Thursday 17 January at 1905 (chaired by F. Bossen).
This document proposes an additional set of test conditions to be included in the Common Test
Conditions (CTC), referred to as Adaptive Streaming Random Access (AS-RA). The test conditions
proposed are intended to simulate a video streaming scenario, which is characterized by the availability of
multiple streams of the same video content at the server side, obtained by an offline encoding of the input
video at distinct bit rates/qualities/resolutions. The goal of the proposed test conditions is to cover this use
case that is currently not tested in the CTC. This is reported to have less than 50% of the computational
cost of the current Random Access CTC for classes A1/A2 and B.
 Proposed option 1: AS-RA test conditions: encode same sequence 4 times at different
combinations of resolutions and QP (combinations are sequence-dependent). This has a reported
+44% total run time increase
 Proposed option 2: MR-RA test conditions: encode same sequence 16 times at different
combinations of 4 resolutions and 4 QP values (combinations are same for each sequence), and
take the convex hull. This has a reported +171% total run time increase.
SHVC filters are proposed for up and downsampling. It was commented that different filters may give
slightly different results.
It was mentioned that closed GOPs are used (instead of open GOPs as in the current RA configuration).
It was unclear whether this would bring new information that would lead to different decisions on a tool-
by-tool basis, and agreed that this should be further studied before making any changes to the CTC for it.
It could make sense to run this metric for each major VTM release. Netflix volunteered to do this for
VTM 4.0. It was suggested to include that in an AHG mandate.
Further study was encouraged, e.g. with testing on a tool-by-tool basis.
Page: 60 Date Saved: 2019-03-172019-03-14

4.4.4 Constrained intra prediction
JVET-M0514 Removal of CIP from Multi-hypothesis Intra Prediction [C.-C. Chen, W.-J.
[Should this be in a different section?]
This contribution was presented Thursday 17 January 1830. Chaired by F. Bossen.
This report proposes to remove the constrained intra prediction (CIP) scheme from multi-hypothesis intra
prediction (MHIntra). Specifically, the CIP flag was proposed to not take effect on the derivation process
of reference samples when MHIntra flag is on. It was reported that the proposed method reduces the
Y/U/V BD-rate loss from VTM-3.0 with CIP=1 by 0.83%/0.44%/0.43% for Random Access and
0.93%/2.01%/2.09% for Low Delay B.
It was remarked that there was no CIP in the current design, and had been no agreement to add it.
No action was thus taken on the proposal at this time.
JVET-M0667 Crosscheck of JVET-M0514 (Removal of CIP from Multi-hypothesis Intra

Prediction) [J. Li, C. S. Lim (Panasonic)] [late]
4.5 Test material (0)

qq
5 Core Experiments
5.1 CE1: Partitioning (3)
JVET-M0021 CE1: Summary report on partitioning [J. Ma, F. Le Léannec, M. W. Park]
This contribution was discussed on Wednesday 9 January at 1530–1700 (chaired by GJS).
This document evaluates CE1: Partitioning JVET-L1021. There were two tests that were conducted by
proponents and cross-checked by at least one cross-checker. There were no mismatches reported to the
coordinators.
The current VTM Software has split restrictions implemented to allow 64x64 pipelining. More precisely,
the concept of (square shaped) virtual pipelining data units (VPDUs) is used to allow for 64x64 pipelining
inside the picture.
The software used for both tests can be found at:
https://vcgit.hhi.fraunhofer.de/JVET-L-CE1/VVCSoftware_VTM.git
SubCE1.1.1
(JVET-M0446, Tencent)
Proponents study non-square VPDUs to enhance RD-performance and unify with boundary partitioning
of the current VTM software.
Conditions for CU_TRIH_SPLIT and CU_TRIV_SPLIT are changed so that, e.g. 128x32 and 32x128
block sizes are possible. Sub-partitions of such blocks are also allowed. However, 128x64 and 64x128 are
not allowed to be split using a ternary split whereas 128x128 can be split using a ternary split. Results do
not effect AI.
Page: 61 Date Saved: 2019-03-172019-03-14

# Tester Comments Cross-checkers
1.1.1 M. Xu The cross-checkers (CC) generally confirm the C. W. Hsu
(Tencent) simulation results and the matching of the (MediaTek)
implementation with the CE description. Mismatches
for encoder timings were reported as follows:
LDB 110% (CC) vs 105% (proponent).
Further comment/suggestions were made by CC:
 Formulate the constraints in a more general way,
e.g. instead of not allowing a ternary split for
128x64 and 64x128, the proponents can constraint
the size by 2·MAX_TU_SIZE_FOR_PROFILE
x
MAX_TU_SIZE_FOR_PROFILE
 It should be considered how many extra partitions
would be supported if using rectangular VPDUs
mixed with squared VPDUs instead of only squared
VPDUs.
 More details on the latency impact of using
different VPDU shapes are desired. For example, in
Figure 1 two cases are compared: First: all 64x64
VPDU structures
vs
Second: First four 32x128 VPDUs and then four
64x64 VPDUs.
Now VPDU4 in case 1 of the figure below would
have less pipeline dependency and latency issues if
data from VPDU1 is used compared to case 2 of the
figure below were data from VPDU3 is always used.
 Interest for interactions with other tools such as
CPR/WPP were expressed.
Example for different VPDU structures. Numbers denote the processing order of VPDUs
While the cross-checker indicated that case 2 had more cases where the immediately previous decoded
region was needed for prediction (e.g., intra prediction) than case 1. The proponent indicated that the
worst case was the same in both cases. And if what matters is average rather than worst case, case 2
would be more rarely encountered.
It was suggested that the key test sequences for this issue are the high resolution ones, since there is
generally little gain for using very large blocks with low-resolution test sequences.
The VTM uses 64x64 VPDUs (for luma). The proposal tries to get coding efficiency by allowing
rectangular shapes 32x128/128x32.
In the current draft spec, these rectangular shapes are available for the edge of the picture.
Page: 62 Date Saved: 2019-03-172019-03-14

All Intra Main 10 Random Access Main 10 Low delay B Main10
Over VTM-3.0 Over VTM-3.0 Over VTM-3.0
Y U V EncT DecT Y U V EncT DecT Y U V EncT DecT
117
Class A1 0.00% 0.00% 0.00% 97% 98% -0.48% -0.48% -0.42% 99%
%
101 100 110
Class A2 0.00% 0.00% 0.00% -0.48% -0.37% -0.31% 99%
% % %
100 110 105
Class B 0.00% 0.00% 0.00% 99% -0.17% -0.17% -0.24% 100% -0.15% -0.65% -0.09% 96%
% % %
100 100 104 102
Class C 0.00% 0.00% 0.00% 0.00% 0.00% -0.03% 102% -0.01% 0.26% 0.19% 98%
% % % %
102 101 109
Class E 0.00% 0.00% 0.00% -0.54% -1.06% -1.41% 96%
% % %
100 100 110 105
Overall 0.00% 0.00% 0.00% -0.25% -0.23% -0.23% 100% -0.20% -0.45% -0.33% 97%
% % % %
100 101 102 100 100
Class D 0.00% 0.00% 0.00% 0.02% -0.12% -0.09% 102% -0.01% 0.31% 0.22%
% % % % %
100 100 108 102
Class F (mandatory) 0.00% 0.00% 0.00% -0.11% -0.11% -0.04% 102% -0.17% -0.15% -0.25% 99%
% % % %
Low delay P Main10

Over VTM-3.0
Y U V EncT DecT
Class A1
Class A2
Class B -0.14% 0.00% 0.07% 106% 96%
Class C 0.03% 0.14% -0.34% 101% 100%
Class E -0.49% -0.87% -0.91% 109% 101%
Overall -0.17% -0.17% -0.31% 105% 99%
Class D 0.01% -0.40% -0.36% 101% 101%
Class F (mandatory) -0.07% -0.40% -0.72% 102% 101%
The proponent highlighted the benefit of 0.5% for Class A in RA configuration.

Further simulation results are available in JVET-M0446 including:
 Simulations without some VTM encoder speedups (0.48% becomes 0.54% benefit for Class A in RA
configuration)
 Simulations for limiting the VTM to not use 32x128/128x32 partitions at boundaries (0.06% penalty
in RA configuration)
It was commented that the coding efficiency benefit of the proposal comes with a substantial encoder
search penalty (~13%) and a similar increase in encoder search complexity without changing the
syntax/decoding process would also provide some coding efficiency benefit.
It was suggested that removing the special treatment of the edges without adding support for alternative
VPDU shapes seemed to be the likely outcome.
This was further discussed Thursday 17 January 1500 (GJS) after simulations completed to measure the
penalty for for limiting the VTM to not use 32x128/128x32 partitions at boundaries. See also the related
contributions JVET-M0888 and JVET-M0905. There had been some bug in the original test results for
JVET-M0446. After fixing that, JVET-M0446 is proposing the same scheme as proposed in JVET-
M0888 method 1 and in JVET-M0905.
Decision (cleanup/consistency): Adopt inferred QT split to avoid 32x128/128x32 partitions at picture
boundaries (0.06% penalty in RA configuration).
SubCE1.2.1
(JVET-M0236, Canon)
Proponents extend current TU tiling such that TUs do not cross the boundaries of a 64x64 grid. It is also
proposed that by using this technology the ternary split at the top level becomes available and therefore an
improved RD-performance is possible.
Page: 63 Date Saved: 2019-03-172019-03-14

Conditions for TU_MAX_TR_SPLIT are changed such that each resulting TU is contained in a single
64x64 region on a 64x64 grid. This is obtained by using smaller TUs than what is currently being used in
the VTM software. For instance, by allowing the ternary split at the top level a 64x128 center block arises
which is then tiled into four 64x32 TUs to match the constraint. Results do not effect AI.
All Intra Main10 Random Access Main 10 Low delay B Main10

Over VTM-3.0 Over VTM-3.0 Over VTM-3.0
Class A1 0.00% 0.00% 0.00% 102% 106% -0.52% -0.71% -0.50% 132% 98%
Class A2 0.00% 0.00% 0.00% 100% 103% -0.66% -0.59% -0.45% 123% 100%
Class B 0.00% 0.00% 0.00% 100% 102% -0.28% -0.26% -0.24% 122% 101% -0.20% -0.47% 0.03% 118% 97%
Class C 0.00% 0.00% 0.00% 100% 103% -0.03% -0.05% 0.00% 113% 104% 0.00% 0.24% -0.12% 106% 107%
Class E 0.00% 0.00% 0.00% 99% 99% -0.70% -0.61% -0.40% 123% 99%
Overall 0.00% 0.00% 0.00% 100% 103% -0.34% -0.36% -0.27% 122% 101% -0.26% -0.27% -0.13% 115% 101%
Class D 0.00% 0.00% 0.00% 96% 105% -0.05% -0.08% -0.03% 113% 105% 0.00% 0.29% 0.21% 103% 96%
Class F
0.00% 0.00% 0.00% 100% 102% -0.17% -0.22% -0.16% 120% 101% -0.35% -0.21% -0.36% 110% 104%
(mandatory)
Remarks:
 The gain is substantial (0.59% for Class A in RA configuration)
 There is a substantial encoder complexity increase (~27%)
 This has a latency issue for decoding, since the TU coefficient data needs to be buffered up for VPDU
pipeline processing. A related contribution JVET-M0237 proposes to shift this buffering burden to
the encoder.
No action was taken on this.
Related proposals JVET-M0195 and JVET-M0285 allows PUs to straddle the VPDU boundaries but
requires there to be no residual in those cases (0.38% benefit for Class A in RA configuration with
encoder complexity increase of 19% if allowing all modes with zero residual, or 0.2% benefit for Class A
in RA configuration with encoder complexity increase of 5% if allowing only skip mode in these cases).
No action was taken on these as well.
JVET-M0236 CE1: Transform tiling for pipelined processing of CTUs (Test 1.2.1)
[C. Rosewarne, A. Dorrell (Canon)]
JVET-M0446 CE1: Rectangular virtual pipeline data unit (test 1.1.1) and supplementary
results [M. Xu, X. Li, S. Liu (Tencent)]
JVET-M0856 Cross-check of JVET-M0446: CE1: Rectangular virtual pipeline data unit

(test 1.1.1) and supplementary results [A. Wieckowski (HHI)] [late]
5.2 CE2: Subblock motion compensation (24)

Contributions in this category were discussed Wednesday 9 Jan. 1540–2100 and Thursday 10 Jan. 0900-
1100 (in Track B chaired by JRO).
Page: 64 Date Saved: 2019-03-172019-03-14

JVET-M0022 CE2: Summary report on sub-block based motion prediction [Y. He, C.-Y.
Chen, C.-C. Chen]
The goal of Core Experiment 2 (CE2) is to investigate sub-block based motion prediction techniques on
top of VTM-3.0. It comprises 5 categories,
 CE 2.1: Affine motion compensation
 CE 2.2: Affine merge mode
 CE 2.3: Sub-block based merge mode
 CE 2.4: Complexity reduction
 CE 2.5: ATMVP and related topics
For each test, a comparative study along with related tests is conducted, results and complexity analysis
are provided. Crosschecking reports of all tests are integrated in this document as well.
CE2.1: Affine motion compensation
Test# Description Document#
Adaptive precision for affine MVD coding:
2.1.1 JVET-M0420
a{1-pel,1/4-pel,1/4-pel}, b{1/4-pel,1/4-pel,1/4-pel}, c{1/8-pel,1/8-pel,1/8-pel}
Adaptive MVD precision for affine inter mode coding:
2.1.2 JVET-M0246
{1-pel,1-pel,1-pel}, {1/4-pel,1/4-pel, 1/4-pel}, {1/16-pel,1/16-pel,1/16-pel}
The numbers are referring to {top-left,top-right,bottom-left}
Current affine uses 1/4 pel precision for signalling, but 1/16 pel precision in sub-blocks; affine merge uses
1/16 pel (but does not need to signalling)
Both tests use signalling and are only modifying affine MV coding, merge is unchanged. Test 2.1.1 uses 1
flag to signal 1/4 (case b) or not, and 1 flag to signal (if not) if it is a or c. Test 2.1.2 re-uses the adaptive
MV precision signalling (but with 2 additional contexts) for affine, and also uses switching 1/16,1/4, 1 pel
(instead 1/4, 1, 4 pel) precision.
The method comes with increase in encoder runtime, whereas decoder complexity increase is marginal
(some additional logic and 2 contexts)
Method of 2.1.2 has slightly higher gain, and is assessed to be conceptually more straightforward,
consistent with AMVR (it is however reported that by just reusing AMVR with same precision steps and
same context coding, loss would occur).
The motion vector rounding is also consistent with the current design.
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.
Specification text was later provided and reviewed by B. Bross.
Random Access Main 10 Low delay B Main10

Test# Y U V EncT DecT Y U V EncT DecT
2.1.1 -0.19% -0.08% -0.12% 105% 101% -0.13% -0.16% 0.04% 106% 100%
2.1.2 -0.23% -0.21% -0.27% 104% 99% -0.20% -0.08% -0.30% 112% 100%
CE2.2: Affine merge

2.2.1.a Bypass Affine flag for Skip CU JVET-M0380
2.2.1.b CABAC context change for Affine Flag JVET-M0380
Page: 65 Date Saved: 2019-03-172019-03-14

2.2.2.a 2 contexts: one for Affine and one for regular Merge index JVET-M0381
2.2.2.b 1 context: one for both Affine Merge index and regular Merge index JVET-M0381
2.2.3.a Applying affine HMVP candidates to affine merge JVET-M0125
2.2.3.b Applying affine HMVP candidates for affine motion vector prediction JVET-M0125
2.2.3.c Combined test of 2.2.3a and 2.2.3b JVET-M0125
2.2.3.d Replace existing inherited affine candidates with affine HMVP candidates JVET-M0125
2.2.4.a Affine merge with offset and block level signalling JVET-M0431
2.2.4.b Based on 2.2.4a, but offset value range depends on picture height JVET-M0431
2.2.4.c Based on 2.2.4b, but POC distance based offset mirroring for Bi-prediction JVET-M0431
2.2.4.d Based on 2.2.4b, but POC distance based offset scaling for Bi-prediction JVET-M0431
2.2.5 Affine MV offset merge candidates JVET-M0476
Simplification for 6-param and 4-param constructed candidates by setting P = 3 in 7
2.2.6.a JVET-M0477
availability cases
Simplification for 6-param and 4-param constructed candidates by setting P = 3 in 2
2.2.6.b JVET-M0477
availability cases
“Low complexity” affine merge with temporal candidates (however, increases
2.2.7.a JVET-M0256
complexity compared to VTM, see notes below)
“Medium complexity” affine merge with temporal candidates (however, increases
2.2.7.b JVET-M0256
complexity compared to VTM, see notes below)
2.2.7.c Withdrawn
2.2.7.d Withdrawn
2.2.7.e Withdrawn
In affine AMVP, apply some pruning on candidates. Rounding, clipping applied
2.2.8.a JVET-M0282
before pruning
2.2.8.b In affine merge, apply some pruning on inherited candidates JVET-M0282
2.2.8.c 2.2.8.a + 2.2.8.b JVET-M0282
2.2.8.d 2.2.8.c + 4.1.5.c JVET-M0282

2.2.1.a 0.09% 0.21% 0.20% 102% 98% 0.03% 0.04% 0.06% 103% 92%
2.2.1.b -0.01% 0.02% -0.01% 100% 100% 0.00% 0.02% 0.06% 99% 98%
2.2.2.a 0.00% 0.00% -0.01% 100% 98% 0.03% -0.05% 0.10% 99% 94%
2.2.2.b 0.07% 0.04% 0.06% 100% 104% 0.05% 0.03% 0.15% 100% 96%
2.2.3.a -0.06% -0.04% -0.02% 100% 100% -0.06% 0.04% 0.09% 101% 100%
2.2.3.b -0.01% 0.01% 0.02% 100% 100% 0.00% 0.00% 0.09% 102% 101%
2.2.3.c -0.07% -0.04% -0.04% 100% 100% -0.03% -0.05% -0.18% 101% 102%
2.2.3.d 0.07% 0.10% 0.06% 100% 100% 0.09% 0.09% 0.02% 101% 101%
2.2.4.a -0.16% -0.13% -0.14% 104% 100% 0.01% -0.05% -0.07% 107% 100%
2.2.4.b -0.17% -0.12% -0.13% 104% 100% -0.02% 0.09% -0.04% 106% 100%
2.2.4.c -0.20% -0.08% -0.09% 104% 100% 0.04% -0.01% 0.19% 105% 100%
2.2.4.d -0.20% -0.09% -0.09% 104% 99% 0.02% 0.07% 0.07% 106% 99%
2.2.5 -0.06% -0.02% -0.05% 104% 101% -0.03% 0.06% -0.03% 105% 99%
2.2.6.a 0.00% 0.01% -0.01% 100% 100% 0.07% -0.01% 0.18% 99% 99%
2.2.6.b 0.02% 0.04% 0.00% 100% 100% 0.08% 0.14% 0.04% 99% 98%
2.2.7.a -0.08% -0.02% -0.13% 105% 102% -0.03% -0.12% -0.09% 116% 115%
2.2.7.b -0.10% -0.10% -0.14% 106% 102% -0.07% -0.21% -0.08% 117% 116%
2.2.8.a 0.00% 0.01% 0.00% 100% 100% -0.01% 0.04% -0.07% 100% 100%
2.2.8.b -0.01% -0.01% 0.00% 101% 100% -0.03% 0.00% -0.05% 100% 100%
2.2.8.c -0.02% 0.00% 0.00% 100% 100% 0.00% 0.05% 0.10% 100% 100%
2.2.8.d -0.04% -0.01% -0.01% 100% 100% -0.03% -0.12% -0.17% 100% 100%
Page: 66 Date Saved: 2019-03-172019-03-14

Complexity analysis
Max
number of
Max Max Max
AMVP/ Max conditional
number of number of number
Merge number of cases to Others
potential ref idx of MV
list size MV comp. enable
candidates comp. scaling
constructed
candidates
2.2.1.a same same same same same same
2.2.1.b same same same same same same
2.2.3.a same Merge +5 sSame same same *Affine HMVP 170 bytes
*Do ref index selection for
affine HMVP based on the
2.2.3.b same AMVP + 2 sSame +2 same
selected ref. in AMVP
*Affine HMVP 68 bytes
Merge +5 /
2.2.3.c same sSame +2 same *Affine HMVP 170 bytes
AMVP +2
Reduce CPMV buffer from
1296 bytes to 170 bytes.
Note: 1296 bytes requires
optimized affine CPMV
2.2.3.d same same sSame -1 same buffer update. Otherwise,
storage of a full CTU's
CPMV needs 6192 bytes.
Position comp: merge +
5/AMVP +4
2.2.4.c same same same same same same
2.2.4.d same same same same same same
2.2.5 same same same same same same
2.2.6.a same -3 -8 -22 same same
2.2.6.b same -3 -8 -22 same 2(-5)
2.2.7.a same same + 38 -12 +2
2.2.7.b same +3 +98 +26 3
2.2.8.a same same +3 same same
2.2.8.b same same +6 +2 same
+3 for +0 for
AMVP AMVP
2.2.8.c same same same
+6 for +2 for
Merge Merge
2.2.8.d
2.2.1a has loss, but does not really solve a problem in terms of complexity
2.2.1b uses different neighbour positions (A1/B1) for the context of affine flag coding (which currently
uses A2/B3), claiming that these are positions different from those used in merge. However, other
elements (e.g. AMVR, triangular, quadtree/MTT split flag) use also A2/B3. Therefore, making this
change only for affine flag does not seem to be a unification/simplification.
The current affine merge has 4 context coded bins. Both tests 2.2.2a/b reduce this to only one (as in
normal merge mode), where 2.2.2a uses different contexts for affine and normal merge, whereas 2.2.2b
uses the same. 2.2.2a has no loss in RA, very small loss in LB, whereas 2.2b also shows 0.07% loss in
RA.
Page: 67 Date Saved: 2019-03-172019-03-14

Decision: Adopt JVET-M0381 Test 2.2.2a (reducing number of context coded bins in affine merge). Text
is available with the contribution.
2.2.3.x establishes a history-based motion vector prediction for affine, however the HMVP candidates are
different (specifically collected from affine coded blocks) than in normal HMVP.
It is commented that no coordinates are used for a/b/c (which theoretically might lead to wrong model
depending on distance)
a/b/c have additional complexity in list derivation and storage of history camdidates, which is not justified
by the small (highest 0.07% for 2.2.3c)
2.2.3d is interesting as it reduces the need of local storage for spatial CPMV (control point motion
vectors) and replaces CPMV by history-based candidates. It however also disables the inheritance at CTU
boundaries, which is asserted to be the main reason for the loss of 0.07% (there are CE related
contributions JVET-M0432, JVET-M0110, JVET-M0168, JVET-M0262, JVET-M0270) that tackle this
issue in various ways. The approach should be further studied to solve the complexity reduction with less
penalty in terms of compression performance.
Test 2.2.4.x signals offset for affine merge mode (applied to all CPMV). The method b based on picture
height only provides small additional benefit. The method d has some additional complexity for scaling,
without showing benefit over c (which just uses mirroring). Gain is on average between 0.16% (for a) and
0.20% for c/d, generally higher for high resolution sequences.
It was initilly recommended in Track B to adopt JVET-M0431, test CE3-2.2.4c, but on top of 2.2.4a
(using distance offsets 1/2, 1, 2, 4, and 8-pel as per table 2.1 of JVET-M0431). Add a high-level enabling
flag.
Specification text was to be provided and reviewed.
This decision was later reverted. See the discussion of this topic in the notes of the plenary of Sunday 13
January in section 10.1. It was agreed that this should be further studied in a CE.
2.2.5 is a similar approach with same number of offset candidates (total 20), but supports larger offset
values, and different combinations. Gives less compression benefit.
2.2.6.x reduce the number of constructed affine candidates from 6 to 3. However, loss of 0.07% is
observed in LDB (where constructed candidates may be used more often). Furthermore, the study of
AHG16 shows that affine merge is not the most critical path in VVC. Therefore, proposals which reduce
complexity in this area should rather come with very low penalty in compression.
2.2.7.a removes “mixed” spatial-temporal constructed candidates, replacing them by pure temporal
candidates. The total number of candidates is unchanged, but the list construction (pruning) becomes
more complicated. Gain is 0.08%/0.03% for RA/LB
2.2.7b keeps the original candidates, and adds three more pure temporal candidates. The list construction
(pruning) has significantly higher complexity than current VVC (almost 3x number of MV comparisons).
Gain is 0.1%/0.07% for RA/LDB
Some of the reported gain may also be due to encoder changes. No good tradeoff of performance
compared to additional complexity. Also reports increased encoder runtime.
2.2.8.x adds some pruning processes to affine MV prediction and merge modes. Benefit in terms of
compression not obvious. (Note that the technology had more promising compression benefit before
VTM3).
Page: 68 Date Saved: 2019-03-172019-03-14

Sub-CE 2.3: Sub-block based merge mode
Planar motion vector prediction (PMVP) as a single mode with the sub-block size
2.3.1.a.1
setting: 8x4 for BI, 4x4 for UNI
2.3.1.a.2 PMVP as a single mode with the sub-block size setting: 4x8 for BI, 4x4 for UNI
PMVP as a single mode with the sub-block size setting: Adaptive 8x4/4x8 for BI, 4x4
2.3.1.a.3
for UNI
2.3.1.a.4 PMVP as a single mode with the sub-block size setting: 8x8 for BI, 4x4 for UNI
JVET-M0104
PMVP as a single mode with the sub-block size setting: Adaptive 8x4/4x8 for BI and
2.3.1.a.5
UNI
2.3.1.a.6 PMVP as a single mode with the sub-block size setting: 8x8 for BI and UNI
2.3.1.b Withdraw
2.3.1.c PMVP as a candidate in sub-block (affine) merge list
2.3.1.d Withdraw
2.3.2.a The threshold is set as 1 pixel for the sub-blocks inside the 4x16, 16x4 and 8x8 blocks
The threshold is set to 0 pixel for 4x16 and 16x4 blocks along vertical and horizontal
JVET-M0485
2.3.2.b directions, respectively; and the threshold is set as 1 pixel for the sub-blocks inside
8x8 blocks
Regression-based Motion Vector Field (RMVF) as a separate merge mode as
2.3.3.a
described in JVET-L0171
2.3.3.b 2.3.3.a + the RMVF-coded blocks are used for affine merge candidate inheritance
JVET-M0302
2.3.3.a + complexity reduction (i.e., lower number of neighbouring motion
2.3.3.c
information for RMVF parameter derivation)
2.3.3.d 2.3.3.b + 2.3.3.c

2.3.1.a.1 -0.11% -0.10% -0.17% 103% 103% -0.08% 0.01% 0.09% 104% 103%
2.3.1.a.2 -0.10% -0.18% -0.18% 103% 103% -0.05% 0.03% 0.01% 104% 103%
2.3.1.a.3 -0.11% -0.13% -0.22% 103% 103% -0.04% -0.11% -0.07% 104% 104%
2.3.1.a.4 -0.11% -0.07% -0.15% 103% 101% -0.05% -0.07% -0.19% 104% 102%
2.3.1.a.5 -0.10% -0.15% -0.18% 103% 102% -0.06% 0.01% 0.02% 104% 103%
2.3.1.a.6 -0.11% -0.10% -0.17% 103% 103% -0.08% 0.01% 0.09% 104% 103%
2.3.1.c 0.08% 0.12% 0.06% 0.07% -0.01% 0.22%
2.3.2.a -0.12% -0.18% -0.21% 104% 107% -0.08% -0.05% 0.05% 106% 112%
(over
VTM-3.0)
Over 2.3.1
2.3.2.b -0.12% -0.15% -0.23% 104% 107% -0.08% 0.22% 0.08% 106% 112%
Over 2.3.1
2.3.3.a -0.18% -0.17% -0.26% 105% 102% -0.02% -0.10% 0.09% 106% 102%
2.3.3.b -0.20% -0.25% -0.24% 104% 101% -0.02% 0.12% 0.21% 103% 102%
2.3.3.c -0.19% -0.13% -0.19% 105% 102% 0.01% 0.05% -0.03% 106% 101%
2.3.3.d -0.19% -0.22% -0.23% 105% 100% 0.00% 0.07% -0.16% 106% 101%
Test 2.3.1.a adds PMVP as a new mode to determine subblock vectors. 2.3.1.a3 imposes the same
restrictions as current (non-affine) subblock MC. Low gain (around 0.1%), whereas encoder/decoder run
time increases. The CE report does not have a detailed complexity analysis, but it can be asserted to be
not insignificant, as MV scaling is necessary for each subblock.
Test 2.3.1.c puts PMVP as additional candidate into the affine merge list (but uses 8x8 subblocks) –
therefore, loss is observed, probably as affine usually has 4x4 subblocks, and/or merge list size is
reduced.
PMVP had 0.6% gain before, which is now down to 0.1%. This does not justify adding another subblock
mode with additional processing.
Page: 69 Date Saved: 2019-03-172019-03-14

Test 2.3.3 is about Regression-based Motion Vector Field (RMVF), where a set of maximum of 112 candidates is
fed into the regression in case of a 128x128 block , or 7 candidates in case of an 8x8 block (each of which has to be
scaled before). The derivation performs regression versus a 6-parameter affine model. 2.3.3a determines the
subblock candidates (8x8 SB) directly, 2.3.3b puts them as a candidate for affine merge, and then uses it with 4x4
subblocks.
Tests c and d correspond to a and b, but reduce the number of input candidates to roughly half. Gain is around 0.2%
for b, and 0.19% for c/d. This gain is much lower than reported originally (which was around 0.7%). Also the
dependency of the regression on block size and number of candidates is of some concern (integer 16 bit, division-
free). No precise analysis of complexity was made, but it is likely that the complexity of the regression (worst case
of number of multiplications, availability checks, scaling operations, number of cycles) as used in the current CE
would not justify adding another subblock mode, or an additional derivation of the affine model
construction. Further study in CE to further reduce the number of candidates, and perform analysis of
complexity impact.
Sub-CE2.4: Complexity reduction

4x4 block is used as the sub-block size for a uni-directional affine coded CU
2.4.1.a while 8x4/4x8 block is used as the sub-block size for a bi-directional affine coded
CU according to the width/height of the CU.
2.4.1.b while 8x4 block is used as the sub-block size for a bi-directional affine coded JVET-M0226
CU.
2.4.1.c while 4x8 block is used as the sub-block size for a bi-directional affine coded
CU.
2.4.2 Restricted motion vector field for affine mode. JVET-M0309
Affine restrictions for the worst-case bandwidth reduction:
2.4.3.a The worst-case bandwidth is bi-prediction of an INTER_8x4/INTER_4x8 block.
(*changes only luma)
The worst-case bandwidth is uni-prediction of an INTER_4x4 block. (*changes JVET-M0150
2.4.3.b
only luma)
The worst-case bandwidth is bi-prediction of an INTER_9x9 block. (*changes
2.4.3.c
only luma)
Affine sub-block size restrictions: 8x4 for BI, 4x4 for UNI. (* changes applied to
2.4.4.a
both luma and chroma)
2.4.4.b 4x8 for BI, 4x4 for UNI. (* changes applied to both luma and chroma)
JVET-M0472
Adaptive 8x4/4x8 for BI, 4x4 for UNI. (* changes applied to both luma and
2.4.4.c
chroma)
2.4.4.d 8x8 for BI, 4x4 for UNI. (* changes applied to both luma and chroma)
2.4.5.a clip sub-block MVs in 8x8 block for UNI and BI prediction.
JVET-M0488
2.4.5.b Withdrawn.
2.4.6 Modified affine inheritance from above CTU. JVET-M0054
2.4.7 Size constrain for inherited affine motion prediction. JVET-M0053
2.4.8 Affine model inheritance with reduced memory requirement. JVET-M0262
2.4.9 Withdrawn.
Page: 70 Date Saved: 2019-03-172019-03-14

2.4.1.a 0.11% 0.10% 0.09% 100% 99% 0.10% 0.12% 0.11% 101% 97%
2.4.1.b 0.10% 0.09% 0.08% 101% 99% 0.11% 0.00% 0.20% 99% 95%
2.4.1.c 0.12% 0.07% 0.09% 99% 96% 0.13% 0.16% 0.16% 99% 95%
-
2.4.2 0.01% 0.00% 0.05% 101% 100% 0.01% 0.07% 101% 100%
0.05%
- - -
2.4.3.a 0.02% 0.01% 99% 100% 0.02% 101% 101%
0.01% 0.04% 0.05%
2.4.3.b 0.27% 0.14% 0.18% 97% 98% 0.27% 0.22% 0.08% 99% 100%
- - -
2.4.3.c 0.03% 0.06% 0.01% 99% 99% 101% 100%
0.01% 0.08% 0.07%
2.4.4.a 0.10% 0.09% 0.08% 99% 99% 0.11% 0.00% 0.20% 98% 98%
2.4.4.b 0.12% 0.07% 0.09% 99% 99% 0.13% 0.16% 0.16% 99% 99%
2.4.4.c 0.11% 0.10% 0.09% 99% 99% 0.10% 0.12% 0.11% 99% 99%
2.4.4.d 0.22% 0.18% 0.16% 98% 98% 0.20% 0.24% 0.31% 97% 99%
- - -
2.4.5.a 0.01% 0.00% 100% 100% 0.06% 102% 103%
0.03% 0.02% 0.10%
- - -
2.4.6 0.01% 100% 100% 0.02% 0.02% 100% 99%
0.01% 0.02% 0.03%
-
2.4.7 0.02% 0.02% 0.03% 100% 100% 0.05% 0.05% 100% 99%
0.11%
- -
2.4.8 0.00% 0.02% 100% 99% 0.03% 0.15% 100% 103%
0.02% 0.04%
Complexity analysis:
Test# Bandwidth for Affine MVs storage Others (additional operations for MV
uni/bi-prediction clipping or derivation, and so on.)
Translational model 6.25 / 8.56
Affine model 8.33 / 16.66
8.33 / 11.84 Same 2 comparisons per CU
2.4.1.a
(1 for width/height + 1 for uni/bi)
8.33 / 11.84 Same 1 comparison per CU
2.4.1.b
(1 for uni/bi)
2.4.1.c
(1 for uni/bi)
8.33 / 8.56 Same MV clipping for subblk MVs
2.4.2
2.4.3.a (1 for width/height + 1 for uni/bi + 1 for
restriction)
8.33 /8.56 Same 1 comparison per CU
2.4.3.b
(1 for uni/bi)
2.4.3.c (1 for uni/bi + 12 for restriction)

2.4.4.a
(1 for uni/bi)
8.33/11.84 Same 1 comparison per CU
2.4.4.b
(1 for uni/bi)
8.33 /11.84 Same 2 comparisons per CU
2.4.4.c (1 for width/height + 1 for uni/bi)

2.4.4.d
(1 for uni/bi)
2.4.5.a 4.77 / 9.53 Same MV clipping for subblk MVs +
Find min every 4 subblk MVs
Page: 71 Date Saved: 2019-03-172019-03-14

(note: 9x9 luma)
14 comparisons for each 8x8 block
2.4.6 Same Same 4 POC comparisons

2.4.7 Same 25% Same
Same 10 bit less per CU
2.4.8
??%
The following aspects are studied in this sub-CE:
1. Reduce worst case memory bandwidth for affine. This can be done either by disallowing 4x4 subblocks
(Tests 2.4.1, 2.4.3b, 2.4.4). All these come with some penalty in compression performance (typically
0.1% when 4x8/8x4 SB are used for bi pred, 0.2+% when restriction 8x8 is used). It is noted that these
approaches also reduce the number of computations for motion comp (more lines have to be interpolated
at boundaries of 4x4 blocks before the vertical interpolation can be performed)
It is also mentioned that possible impact on visual quality might occur when using larger subblocks in
afine MC, in particular for sequences with stronger affine motion. This has not been investigated yet
Other approaches (Tests 2.4.2, 2.4.3a/c, 2.4.5) keep 4x4 subblocks and impose some restrictions (e.g. by
clipping, grouping, adaptive selection of subblock size based on CPMV), such that adjacent subblocks’
vectors are not too much different, and joint memory access could be made. These come with practically
no loss in compression, but may require some additional logic. Keeping 4x4 subblocks and not losing
compression performance appears the more desirable concept, but more study is necessary to understand
the impact of different approaches how it can be achieved. The following aspects are important:
 - Number of operations at decoder (for determining SB MVs and MC)
 - More detailed study of worst case memory bandwidth in relation to memory access models, cache
size, etc.
 - Possibility of formulating by encoder/bitstream restrictions
 - Possibility of applying such concepts not only for affine, but also for other small-size CU cases
 - Possible impact on subjective quality
2. Reduction of local buffers for storing affine related CPMV inheritance (2.4.7, 2.4.8). 2.2.3.d is
targeting the same issue. It appears from CE results (and possibly from CE related contributions) that this
can be achieved by almost no loss in compression. However, also here more detailed analysis is necessary
in terms of additional logic, and the effective saving in number of bits for local buffers.
Further analysis of the different approaches in BoG (Y. He), also review the CE related proposals, and
suggest approaches to be further studied in upcoming CE. It is unquestionable that something is necessary
in VVC to restrict the worst case memory bandwidth, but the optimum solution of achieving this may not
be identified yet.
3. Sub-Test 2.4.6 enables 6-parameter model inheritance across CTU boundary. However in VTM3 this
does not seem to have any benefit.
Sub-CE 2.5: ATMVP related

2.5.1 Simplification of ATMVP, add additional CU size restriction (>64) JVET-M0165
2.5.2.a Withdrawn JVET-M0227
2.5.2.b Withdrawn
Page: 72 Date Saved: 2019-03-172019-03-14

Insert the new ATMVP into the affine merge candidate list in additional to the
2.5.2.c
original ATMVP for non-low-delay picture with pruning
2.5.2.d Withdrawn
2.5.2.e Withdrawn
2.5.2.f Withdrawn
2.5.2.g Withdrawn
For non-low-delay picture, insert the new ATMVP; for low-delay picture, insert
2.5.2.h
VTM-3.0 ATMVP
2.5.3.a Withdrawn
2.5.3.b Withdrawn
2.5.4 Non-sub-block ATMVP JVET-M0086

2.5.1 0.00% 0.00% 0.05% 100% 100% 0.00% -0.04% 0.08% 100% 101%
2.5.2.c -0.04% -0.07% -0.06% 100% 101% 0.00% 0.00% 0.00% 100% 100%
2.5.2.h 0.26% 0.14% 0.15% 101% 101% 0.00% 0.00% 0.00% 100% 99%
2.5.4 0.19% 0.28% 0.26% 100% 99% 0.52% 0.52% 0.66% 101% 97%
2.5.2.x is adding something without showing benefit any more on top of VTM3.
For 2.5.4, it is not obvious that the restriction is necessary (e.g., there is no memory bandwidth problem)
– it generates loss. Further, there may be some interdependency with subblock boundary deblocking that
was added in VTM3, so the subjective issue of ATMVP which might have occurred with VTM2 is no
longer relevant.
2.5.1 is a simplification for subblock merge (including affine) by using it only for subblocks where no
side is smaller than 8 (which is an existing condition), and the area shall be larger than 64 samples (which
disallows 8x8 blocks. There is no loss in performance. However, there is no real problem in implementing
8x8 blocks, so this restriction seems unnecessary.
The subsequent notes contain descriptions of technology which were copied from JVET-M0022. Actions
taken are noted above.
JVET-M0053 CE2.4.7 Size constrain for inherited affine motion prediction [H. Huang, W.-
J. Chien, M. Karczewicz (Qualcomm)]
It is proposed to disable inherited affine motion prediction from a neighbouring affine coded block if the
width or height of the neighbouring block is less than threshold.
JVET-M0054 CE2.4.6 Modified affine inheritance from above CTU [H. Huang, W.-J.
In the proposed method, deriving a 6-parameter affine inherited candidate from a neighbouring block in
the above CTU is illustrated in Fig. 1. The top-left CPMV ⃗v 0and top-right CPMVs ⃗v1 are derived by the
the bottom-left MV ⃗v LB and bottom-right MV ⃗v RB of the neighbouring candidate block:
⃗v RB −⃗v LB
⃗v 0= ∗( posCurX− posNeiX )+ ⃗v LB
neiW
⃗v RB −⃗v LB
⃗v1 = ∗( posCurX +curW − posNeiX ) + ⃗v LB
neiW
Page: 73 Date Saved: 2019-03-172019-03-14

Wherein neiW is the width of the neighbouring block, curW is the width of current block, posNeiX is the
x coordinate of the top-left pixel of neighbouring block, and posCurX is the x coordinate of the top-left
pixel of current block.
The bottom-left CPMV ⃗v 2is proposed to be derived as follows:
 If the MV from left neighbour ⃗v ¿¿is available and has the same reference picture as ⃗v LB
⃗v 2=⃗v ¿ ¿;
 Otherwise, if the MV from bellow-left neighbour ⃗v bellowleftis available and has the same reference
picture as ⃗v LB
⃗v 2=⃗v bellowleft ;
 Otherwise
⃗v RB−⃗v LB
( deltaHorX , deltaHorY )=
neiW
∇ ⃗v Ver =(−deltaHorY , deltaHorX )
⃗v RB −⃗v LB
⃗v 2= ∗( posCurX− posNeiX )+ ∇ ⃗v Ver∗curH + ⃗v LB
neiW
where curH is the height of current block.
JVET-M0086 CE2: Non-sub-block ATMVP (test 2.5.4) [K. Abe, T. Toma (Panasonic)]

The proposed non-sub-block ATMVP is based on the existing ATMVP. The corresponding area is
derived by the same method as current ATMVP. But it selects a set of MV in the centre position of
corresponding area for entire target CU as shown in the figure below. The derived MV is CU unit,
therefore, all processes after MV derivation are the same as for other merge candidates. It is also claimed
to solve a subjective image quality problem of strong sub-block boundary noise.
JVET-M0104 CE2.3.1: Planar Motion Vector Prediction [N. Zhang, X. Chen, J. Zheng,

Y. Lin (HiSilicon)]
To generate a smooth fine granularity motion field, the figure below gives a brief description of the planar
motion vector prediction (PMVP) process.
Planar motion vector prediction is achieved by averaging a horizontal and a vertical linear interpolation
on sub-block basis as follows.
P( x , y )=( H×P h ( x , y )+W×P v ( x , y )+H ×W )/(2×H ×W )
 Separately signalling for each coding unit.
 Once there are two different MVs in the L-shaped area, the mode is activated.
 Ref_idx in L0 and L1 are set to 0, all the MVs in the L-shaped area are scaled if needed.
 In the case a neighbouring block in the L-shaped area is intra coded, it is padded in the same manner
as intra reference pixel padding, separately for L0 and L1.
 BR temporal motion is used for planar interpolation. If BR temporal motion is not available, exactly
the same planar prediction for intra mode is applied.
 It is a merge mode.
Page: 74 Date Saved: 2019-03-172019-03-14


JVET-M0125 CE2: History Based Affine Motion Candidate (Test 2.2.3) [J. Zhao, S. Kim
(LGE), G. Li, X. Xu, X. Li, S. Liu (Tencent)]
In these tests, history based affine MV candidate (Affine HMVP) methods will be applied to affine merge
list or affine AMVP list generation or both. The following aspects will be investigated:
 Generation of a table to store motion information of coded affine CUs
 The derivation of affine HMVP candidate from the stored affine motion information.
 Simplified pruning for affine HMVP candidates.
 Impact of various history table sizes, e.g. 4, 6, 8
 Coexist or replace existing affine inherited candidates

JVET-M0150 CE2.4.3: Affine restriction for worst-case memory bandwidth reduction

[L. Pham Van, W.-J. Chien, H. Huang, V. Seregin, M. Karczewicz
(Qualcomm)]
In this test, the performance of affine restrictions for worst-case bandwidth reduction is evaluated.
a) The worst-case bandwidth is bi-prediction of an INTER_8x4/INTER_4x8 block.
b) The worst-case bandwidth is uni-prediction of an INTER_4x4 block.
c) The worst-case bandwidth is bi-prediction of an INTER_8x8 block.
JVET-M0664 Crosscheck of JVET-M0150 [S. Jeong, K. Choi (Samsung)] [late]
JVET-M0165 CE2.5.1: Simplification of SbTMVP [C.-C. Chen, C.-W. Hsu, Y.-W. Huang,
S.-M. Lei (MediaTek)]
In JVET-L0092, a simplification method for ATMVP was described to simply disable the ATMVP for
small size of CU. This method can reduce the hardware processing cycles for small CUs. Currently, the
sub-block merge mode is disabled when width or height is smaller than 8. This CE test wants to disable
ATMVP when the number of samples in one CU is smaller than 128, 256, or other value. Within this CE,
the performance of the method described in JVET-L0092 is to be studied for different requirements, such
as disabling ATMVP for small area, small width, small height, and so on. Due to combination of ATMVP
and affine merge into a unified subblock-based merge list, the coherence of the disabling rule related to
affine merge is also be studied.
JVET-M0226 CE2.4.1: Reducing worst-case memory bandwidth of affine mode [Y.-W.

Chen, X. Wang (Kwai Inc.)]
In JVET-L0104, it was proposed to restrict a 4x4 block from using bi-directional motion compensation.
The details of the proposal are as follows:
1) Disallow bi-directional inter mode (AMVP mode and Merge mode) for each 4x4 inter CU.
2) Enlarge the minimum sub-block size of ATMVP merge mode from 4x4 to 8x8; ATMVP is not
allowed when either width or height of a CU is equal to 4.
Page: 75 Date Saved: 2019-03-172019-03-14

3) 4x4 block is used as the sub-block size for a uni-directional affine coded CU while 8x4/4x8 block is
used as the sub-block size for a bi-directional affine coded CU
The items 1) and 2) have been adopted into VVC and item 3) is further studied in this CE. The tests
related to the item 3) are illustrated as shown in the table in section 4.1 test 2.4.1.
JVET-M0227 CE2.5.2: A second ATMVP candidate [Y.-W. Chen, X. Wang (Kwai Inc.)]
In the method proposed in JVET-L0105, a new ATMVP-like merge candidate is generated and inserted
into the merge candidate list in addition to the original ATMVP. The derivation process of the new
ATMVP is similar to the original ATMVP, with slightly different rules used in selecting motion vectors
(MV) from corresponding reference sub-blocks. More specifically, the MV selection rules for TMVP
from a reference block are used in deriving MVs for each subblock under the new ATMVP mode.
JVET-M0246 CE2: Adaptive Motion Vector Resolution for Affine Inter Mode (Test 2.1.2)
[H. Liu, K. Zhang, L. Zhang, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
The contribution extends Adaptive Motion Vector Resolution (AMVR) to affine inter mode coding,
wherein MVD in affine inter mode can be coded with adaptive precision.
JVET-M0256 CE2: Affine temporal constructed candidates (test 2.2.7) [F. Galpin,

A. Robert, F. Le Léannec, T. Poirier (Technicolor)]
Performed on top of the VTM 3 for affine merge mode by using the concepts described in JVET-L0522
(constructed temporal candidates and improved affine flag coding).
JVET-M0699 Crosscheck of JVET-M0256 (CE2: Affine temporal constructed candidates

(test 2.2.7)) [H. Huang (Qualcomm)] [late]
JVET-M0262 CE2: Affine model inheritance from single-line motion vectors (Test 2.4.8)
[K. Zhang, L. Zhang, H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
In affine model inheritance, fewer MVs stored in neighbouring blocks are required.
JVET-M0282 CE2: Affine motion predictor pruning (test 2.2.8) [A. Robert, F. Le Léannec,
T. Poirier, F. Galpin (Technicolor)]
This proposal includes two aspects. First, before any pruning operation takes place the involved motion
vectors are computed in their final representation. This means the MVs are set to the appropriate precision
level, rounded to the right motion vector resolution or clipped, before being compared to candidates
already present in the concerned list. Second aspect consists in adding some pruning operations between
candidates to improve the trade-off between coding efficiency and complexity.
JVET-M0302 CE2: Merge Mode with Regression-based Motion Vector Field (Test 2.3.3)
[R. Ghaznavi-Youvalari, A. Aminlou, J. Lainema (Nokia)]
JVET-L0171 proposed a new sub-block merge mode with Regression-based Motion Vector Field
(RMVF). RMVF uses a 6-parameter motion model for calculating the motion vectors of sub-blocks.
[ MV X
MV Y
subPU
subPU
][
=
][ ] [ ]
a xx a xy X subPU b x
+
a yx a yy Y subPU b y
Motion parameters are calculated based on one line and row of spatially neighbouring 4x4 sub-blocks
using their motion vectors and center locations as an input to a linear regression method.
Page: 76 Date Saved: 2019-03-172019-03-14

In this test RMVF is implemented as a new merge mode in VTM-3.0. As part of the experiment the
complexity aspects of the tool will be analysed.
JVET-M0309 CE2: Memory bandwidth reduction for affine mode (test 2.4.2) [J. Li, R.-L.
Liao, C. S. Lim (Panasonic)]
To reduce the worst-case memory bandwidth of an affine CU, the sub-block motion vectors of the affine
CU are constrained to be within a pre-defined motion vector field which is calculated according to the
motion vector of first sub-block, the size of the affine CU and the prediction direction of the affine CU
(i.e. uni-prediction or bi-prediction). Assume that the memory is retrieved per CU instead of per sub-
block and the motion vectors of first (top left) and the second sub-blocks are (v 0x,v0y) and (vix, viy), values
of vix and viy exhibit the following constraints:
vix ∊ [v0x-H, v0x+H],
viy ∊ [v0y-V, v0y+V].
The values H and V are chosen to guarantee that the worst case memory bandwidth of the affine CU does
not exceed that of normal inter MC of a 8×8 bi-prediction block. If the motion vector of any sub-block
exceeds the pre-defined motion vector field, the motion vector is clipped.
JVET-M0380 CE2: Affine Merge flag coding (Test 2.2.1) [G. Laroche, C. Gisquet, P. Onno,
J. Taquet (Canon)]
Test: CE2.2.1.a (Bypass Affine flag for Skip CU)
The affine motion compensation prediction is particularly efficient for complex motion like rotation,
zoom in, zoom out and perspective motion. The Skip mode is efficient for static content or constant
motion. It seems that these modes compensate different kinds of motion and are not compatible. This test
proposes to bypass the affine mode flag coding when the current CU is “skip” coded.
Test: CE2.2.1.b (Affine flag context simplification)
This test aligns the block positions used to derive the affine flag context with the Merge candidate
positions. The new proposed block positions for the Affine flag context are A1 and B1 instead of A2 and
B3 in VTM3. With this modification, only 5 block positions (instead of 7) needs to be checked before
decoding or parsing the Affine flag.
JVET-M0381 CE2: On Subblock Merge index coding (Test CE2.2.2) [G. Laroche,

C. Gisquet, P. Onno, J. Taquet (Canon)]
The proposed modification will consist in reducing the number of CABAC coded bins for the Affine
Merge index. Similarly to L0194, which was related to the classical Merge mode, only one context for the
first bit of the Affine Merge index will be used while the 4 other bits will be CABAC bypassed.
JVET-M0420 CE2: Adaptive precision for affine MVD coding (Test 2.1.1) [J. Luo, Y. He,
X. Xiu (InterDigital)]
In VTM-3.0, affine MVD precision for the signalling is fixed ({1/4-pel, 1/4-pel, 1/4-pel}). Adaptive
precision is proposed for affine MVD signalling. Three precisions are proposed for affine MVD coding at
those control points. The precision set {prec_TL, prec_TR, prec_BL} is used to indicate the MVD
precision for top-left, top-right and bottom-left control points. For 6-parameter affine model, three
precision sets are used: {1-pel, 1/4-pel, 1/4-pel}, {1/4-pel, 1/4-pel, 1/4-pel}, and {1/8-pel, 1/8-pel, 1/8-
pel}. For 4-parameter affine mode, the same three precisions are used, except that the precision for
bottom-left control point is not needed.
Page: 77 Date Saved: 2019-03-172019-03-14

JVET-M0431 CE2: Affine merge with prediction offset (Test CE2.2.4) [G. Li, X. Xu, X. Li,
S. Liu (Tencent)]
These tests affine merge with prediction offset were proposed in JVET-L0320. The proposed method
selects the first available affine merge candidate as a base predictor. Then it applies a motion vector offset
to each control point’s motion vector value from the base predictor. If there’s no affine merge candidate
available, the proposed methods will not be used.
Two signalling methods were proposed:
1) Per control point (CP) signalling
The selected base predictor’s inter prediction direction, and the reference index of each direction
is used without change.
For each control point, a zero_MVD flag is used to indicate whether the control point needs offset
signalling. If zero_MVD flag is true, there’s no other signalling needed for the control point.
Otherwise, a distance index and an offset direction index is signalled for the control point.
Distance index is signalled to indicate which distance offset to use from the offset table.
Distance IDX 0 1 2 3 4
Distance- 2-
1/2-pel 1-pel 4-pel 8-pel
offset pel
The direction index can represent four directions as shown below, where only x or y direction
may have an MV difference, but not in both directions.
Offset Direction
00 01 10 11
IDX
x-dir-factor +1 –1 0 0
y-dir-factor 0 0 +1 –1
If the inter prediction is Uni-prediction, the signalled distance offset is applied on the offset
direction for each control point predictor. Results will be the MV value of each control point.
If the inter prediction is Bi-prediction, the signalled distance offset is applied on the signalled
offset direction for control point predictor’s L0 motion vector; the offset to be applied on L1 MV
is applied on a mirrored basis.
2) Per block signalling

In this method, the distance offset index and the offset direction index are signalled per block.
The same offset will be applied to all available control points. The number of control points is
determined by the base predictor’s affine type. The distance offset table and the offset direction
tables are the same as in 1).
Since the signalling is done for all the control points of the block at once, the zero_MVD flag is
not used in this method.
JVET-M0472 CE2: Affine sub-block size restrictions (Test 2.4.4) [H. Chen, T. Solovyev,
H. Yang, J. Chen (Huawei)]
In affine mode, different sub-block shapes are used, which depends on the prediction direction and the
CU size, as shown in the table below.
a) For uni-prediction affine coded CU, the sub-block size is set equal to 4x4.
Page: 78 Date Saved: 2019-03-172019-03-14

b) For bi-prediction affine coded CU, and if the width of the CU is larger than or equal to its height, the
sub-block size is set equal to 8x4;
c) For bi-prediction affine coded CU, and if the width of the CU is smaller than its height, the sub-block
size is set equal to 4x8;
Prediction direction and CU size Sub-block size

uni-prediction 4x4
bi-prediction, CU width >= CU height 8x4
bi-prediction, CU width < CU height 4x8
Affine sub-block restrictions:

1) 8x4 for BI, 4x4 for UNI
3) Adaptive 8x4/4x8 for BI, 4x4 for UNI
JVET-M0476 CE2: Control point MV offset for Affine merge mode (Test 2.2.5) [Y.-C.
Yang, Y.-J. Chang (Foxconn)]
New Affine merge candidates are generated based on the MVs offsets of the first Affine merge candidate
or the first sub-block MV merge candidate. In Uni-prediction, the MV offsets are applied to the MVs of
the first candidate. In Bi-prediction with List 0 and List 1 on the same direction, the MV offsets are
applied to the MVs of the first candidate as follows:
MVnew(L0), i = MVold(L0) + MVoffset(i)
In Bi-prediction with List 0 and List 1 on the opposite direction, the MV offsets are applied to the MVs of
the first candidate as follows:
MVnew(L1), i = MVold(L1) - MVoffset(i)
On top of new adoptions in Affine merge aspect, this sub-test will test various offset directions combined
with various offset magnitudes for the proposed Affine MV offset merge candidates. The various
numbers of the Affine MV offset merge candidates will be tested.
JVET-M0477 CE2: Simplification of Affine constructed merge candidates (Test 2.2.6) and
supplementary results [Y.-C. Yang, Y.-J. Chang (Foxconn)]
The first aspect in JVET-L0390 is related to reduction of the maximum number of available merge
candidates. This test focuses on the simplification of the constructed Affine merge candidates. Define 6-
param constructed candidates and 4-param constructed candidates as follows:
0: Null
1: [CP0, CP1, CP2]
2: [CP0, CP1, CP3]
Page: 79 Date Saved: 2019-03-172019-03-14

3: [CP0, CP2, CP3]
4: [CP1, CP2, CP3]
5: [CP0, CP1]
6: [CP0, CP2].
The constructed candidate indexes enabled in 7 availability cases are shown as the following table:
V: Availability X:Unavailability Constructed candidate index
CP0 CP1 CP2 CP3
V V V V 1 2 3 4 5 6
V V V X 1 5 6
V V X V 2 5
V X V V 3 6
X V V V 4
V V X X 5
V X V X 6
others 0
The modifications are as one or combination of the following descriptions:

a. At most M constructed candidates are allowed to be selected out of 6-parameter Affine model (6-
param) constructed candidates, where M < 4
b. At most N constructed candidates are allowed to be selected out of 4-parameter Affine model (4-
param) constructed candidates, where N < 2
c. At most P constructed candidates are allowed to be selected out of constructed candidates, where P <
6
d.
JVET-M0798 Crosscheck of supplementary results of JVET-M0477 (CE2: Simplification

of Affine constructed merge candidates (Test 2.2.6) and supplementary
results) [H. Liu (Bytedance)] [late]
JVET-M0485 CE2: Sub-block MV clip in planar motion vector prediction (test 2.3.2)
[M. Gao, X. Li, M. Xu, S. Liu (Tencent)]
The MVs for all 4x4 sub-blocks inside the 4x16, 16x4 or 8x8 blocks are constrained such that the max
difference between integer parts of these sub-blocks is no more than a given threshold.
JVET-M0488 CE2: Sub-block MV clip in affine prediction (test 2.4.5) [M. Gao, X. Li,
M. Xu, S. Liu (Tencent)]
For affine prediction, it is proposed to constrain the MVs of four 4x4 sub-blocks within one 8x8 block
such that the max difference between integer parts of the four 4x4 sub-block MVs is no more than 1 pixel.
5.3 CE3: Intra prediction and mode coding (16)

JVET-M0023 CE3: Summary report on intra prediction and mode coding [G. Van der
Auwera, J. Heo, A. Filippov]
This contribution was discussed Wednesday 9 January 1750–2030 (GJS)
Page: 80 Date Saved: 2019-03-172019-03-14

This is the summary report of the third Core Experiment (CE3). The goal of CE3 is to study intra
prediction tools, including mode coding, for potential inclusion into the VVC standard.
The following is the list of defined sub-tests in CE3:
 CE3.1: Intra prediction modes (5 tests)
 CE3.2: Cross-component prediction (11 tests)
 CE3.3: Intra mode coding (10 tests)
This document summarizes the objective results (BD-rates, runtimes), cross-check reports, and related
input contributions.
The source codes of the tests and full test results are uploaded by proponents into the following CE3
GitLab repository:
The following changes were made to the CE3 test description document after the T2 deadline (December
6, 2018) had passed. Besides changes to contact persons and assignment of cross-checkers, the following
changes were requested on the JVET reflector and discussed for clarification, if needed:
 CE3.2:
o Added test CE3.2.2.1 (MMLM; combination of tests CE3.2.1 and CE3.2.2)
o Added test CE3.2.6.2 (CCLM; testing 3 columns of neighbouring samples on left side of
block, 1 row above block)
 CE3.3:
o Reduction and clarification of test CE3.3.1 from 7 subtests to 4 (decoder-side intra mode
derivation)
o Additional result for test 3.5 (multiple DM for chroma)
CE3.1 on ‘Intra prediction modes’
Test # Description Doc. #

1.1.1 Intra sub-partitions coding mode (conceptually similar to prior “short- JVET-M0102
distance intra prediction”) with a different trade-off between gain and
encoding run-time (at least 16 samples per partition; 2 or 4 partitions)
1.1.2 Test 1.1.1 with a restriction: the resulting partitions must have a width
of at least 4 samples (but height can be 1, 2, or 4)
1.2.1 Affine linear weighted intra prediction modes with encoder speedup JVET-M0043
1.2.2 Affine linear weighted intra prediction modes with a fixed number of
weights needed per NxN block
1.3 Harmonization simplified linear interpolation intra prediction (LIP) JVET-M0252
with PDPC
All Intra Main 10 - Over VTM-3.0 Random Access Main 10 - Over VTM-3.0
Test # Y U V EncT DecT Y U V EncT DecT
1.1.1 -0.59% -0.44% -0.47% 112% 103% -0.29% -0.31% -0.15% 102% 103%
1.1.2 -0.46% -0.34% -0.34% 112% 104% -0.24% -0.28% -0.18% 102% 102%
1.2.1 -1.36% -1.02% -1.01% 153% 105% -0.85% -0.92% -0.98% 112% 99%
1.2.2 -0.95% -0.42% -0.46% 153% 101% -0.57% -0.73% -0.83% 110% 98%
1.3 -0.08% -0.14% -0.11% 106% 100% -0.04% 0.00% -0.01% 101% 100%
Page: 81 Date Saved: 2019-03-172019-03-14

Regarding 1.1.x, it was commented that this does not really increase decoder complexity. Another
participant commented that this has a difficult pipeline dependency. However, other difficult pipline
dependencies are already in the VTM, and this is not increasing the difficulty of the worst case.
CE3.1: Related contributions
Doc. # Related Title
test #
JVET- 1.1.2 CE3-related: Improvement on the Intra Sub-Partitions Coding Mode
M0426
(HHI)
CE3.1: Additional test results

All Intra Main10 - Over VTM-3.0 Random Access Main10 - Over VTM-3.0
Test# Description Y U V EncT DecT Y U V EncT DecT
1.1.2.1 Test 1.1.2 with -0.52% -0.40% -0.42% 112% 104% -0.25% -0.25% -0.16% 102% 102%
1-D transform
and entropy
coding for 4xN
(N>4) blocks
that cannot be
vertically
divided (JVET-
M0102)
It was noted that 1.1.x shows more gain on Class F (SCC content) than on other content, and Class F is
not included in the average. A non-proponent participant focused on implementation issues indicated that
they had analysed it and found it acceptable for implementation.
This was further discussed in the plenary on Sunday 13 January, and it was agreed to revisit this topic
since it has an aspect of reversal of decoding order which may cause it to be difficult to implement. This
aspect was studied further and was agreed to be removed. See the notes of the two plenary discussions of
this in section 10.1.
Decision: Adopt CE3-1.1.1 proposal (without the reverse coding order aspect); text was provided in a
revision of JVET-M0102.
Regarding 1.2.1, this has (in the decoder perspective) a selection of a matrix of stored fixed values among
a set of such matrices, followed by a matrix multiply applied to boundary sample values to generate the
prediction signal in the frequency domain and then an inverse transform is applied to generate a spatial
domain prediction, followed by an ordinary residual difference.
It was noted that this has a bit more gain on RA than is usual for intra coding efficiency proposals
(0.85/1.36=0.625 versus the usual ~0.5).
This has some decoder runtime increase. For 1.2.1 there is an increase in computational operations.
It was commented that the need to include an inverse transform in the 1.2.1 variant is an additional
functional block unlike anything typically done for intra.
The amount of stored coefficient data is another issue, especially for the 1.2.1 variant (~300 kbytes). The
1.2.2 variant omits the inverse transform and has a (simple 2-tap one-dimensional average) downsampling
that reduces the size of the matrices (to about ~18 kbytes – a total of around 14,000 numbers of 10 bits
each), with a corresponding (bilinear) upsampling in the decoder. The proponent pointed to CPR as an
instance where added storage of a greater amount is needed (although, for screen content, that has quite
high gain).
Page: 82 Date Saved: 2019-03-172019-03-14

The encoding complexity is another significant concern; both proposed variants increase that by ~50%.
Additional encoder-only variants are reported in JVET-M0043 with different trade-offs.
The proponent said the training set did not include the CTC test set.
Between 1/3 and 1/2 of the intra blocks were reportedly using this mode (which is a lot).
Further study was encouraged (not necessarily in a CE). Side activity was encouraged during the meeting
to potentially come up with a plan for further study.
For 1.3, the proposal is to add an additional mode; the measured gain was quite small and the encoder
runtime increased by about 6%, so no action was taken on this.
CE3.2 on ‘Cross-component prediction’

2.1 CCLM + MDLM + MMLM JVET-M0097
2.2 CCLM + MDLM + MMLM + Above-MMLM + Left-MMLM JVET-M0475
2.2.1 Combination of 2.1 and 2.2 (*) JVET-M0098
2.3 CCLM + MDLM + Adaptive multiple cross-component linear model JVET-M0504
2.4 Modified CCLM downsampling filter for “type-2” content (chroma JVET-M0142
sampling)
2.5.1 CCLM + MDLM, using MaxMin method, and β derived by usingC mean JVET-M0401
and Lmean
2.5.2 CCLM + MDLM, using classification-based mean value method
2.5.3 CCLM + MDLM, using MaxMin method; using the first top row and the
second left column
2.5.4 CCLM + MDLM, using classification-based mean value method; using
the first top row and the second left column
2.6.1 CCLM accessing less neighbouring luma samples, interaction with other JVET-M0263
adopted coding tools: one row above and one column left luma samples
are accessed
2.6.2 2.6.1 with three columns of left luma samples as in the anchor
The VTM has 3 CCLM modes (CCLM, CCLM-above, and CCLM-left). The selection between these
modes is signalled, but the model parameters are not. The tests in the CE are to improve coding efficiency
by adding more models.
Test 2.1 Test 2.2 Combination test 2.2.1

Signalling Adds MMLM modes Uses flag and index to Same as 2.2
in LM symbol list indicate MMLM mode
Number of lines used Same as (Y: 4 lines above, 5 Same as
for model derivation CCLM/MDLM lines left, C: 2 lines CCLM/MDLM
(i.e., Y: 2 lines above, above and left) (i.e., Y: 2 lines above,
3 lines left, C: 1 line 3 lines left, C: 1 line
above and left) above and left)
 2.1 uses 3 columns to the left and 2 lines above (except at the CTU boundary)
 2.2 uses 5 columns to the left and 4 lines above (except at the CTU boundary)
 Between 2.1, 2.2, and 2.2.1, it was suggested to focus on the combination test 2.2.1, for using fewer
lines and cleaner signalling
Page: 83 Date Saved: 2019-03-172019-03-14
2.1 -0.25% -1.71% -2.19% 100% 100% -0.12% -1.36% -1.70% 99% 99%
2.2 -0.29% -1.94% -2.51% 100% 100% -0.15% -1.70% -1.99% 101% 100%
2.2.1 -0.27% -1.71% -2.26% 99% 99% -0.13% -1.30% -1.73% 99% 98%
2.3 -0.10% -0.86% -0.88% 102% 100% -0.03% -0.62% -0.66% 100% 100%
2.4 See below (*)
2.5.1 -0.09% -0.44% -0.47% 100% 99% -0.08% -0.31% -0.39% 100% 99%
2.5.2 -0.18% -0.88% -0.90% 100% 99% -0.11% -0.74% -0.84% 100% 99%
2.5.3 0.05% 0.45% 0.48% 100% 100% 0.02% 0.51% 0.51% 100% 99%
2.5.4 -0.14% -0.51% -0.51% 100% 101% -0.09% -0.41% -0.46% 100% 99%
2.6.1 0.09% 0.71% 0.79% 99% 97% 0.06% 0.88% 0.95% 100% 99%
2.6.2 0.03% 0.16% 0.21% 100% 97% 0.00% 0.35% 0.35% 100% 99%
(*) Summary of test 2.4:
All Intra – Over VTM3.0 WCG_EXT=1

Test # Description DE100 PSNRL wPsnr wPsnr wPsnr PsnrY PsnrU PsnrV EncT DecT
100 Y U V
2.4.a LM -2.5% -0.2% -0.2% -4.2% -8.6% -0.2% -3.4% -6.7% 101% 101%
determination:
3-tap filter;
prediction: 3-
tap filter
2.4.b LM -2.2% -0.2% -0.2% -4.7% -8.6% -0.2% -4.0% -6.8% 101% 102%
determination:
3-tap filter;
prediction: 5-
tap filter
2.4.c LM -2.6% -0.3% -0.2% -5.5% -9.6% -0.2% -4.6% -7.6% 99% 101%
determination:
5-tap filter;
prediction: 5-
tap filter
Random Access – Over VTM3.0 WCG_EXT=1

Test # Description DE100 PSNRL wPsnr wPsnr wPsnr PsnrY PsnrU PsnrV EncT DecT
100 Y U V
2.4.a LM -1.9% -0.2% -0.1% -4.2% -5.8% -0.1% -3.3% -4.5% 101% 99%
determination:
3-tap filter;
prediction: 3-
tap filter
2.4.b LM -1.7% -0.1% -0.1% -4.7% -6.0% -0.1% -3.7% -4.6% 101% 100%
determination:
3-tap filter;
prediction: 5-
tap filter
2.4.c LM -2.1% -0.2% -0.2% -5.1% -6.6% -0.2% -4.1% -5.1% 102% 101%
determination:
5-tap filter;
prediction: 5-
tap filter
Page: 84 Date Saved: 2019-03-172019-03-14

Some comments:
 Chroma gain tends to roughly translate to luma gain at about a 1:10 ratio
 Chroma gain in the CTC is often dominated by one particular test sequence: CampFire
 The MDLM scheme adopted at the previous meeting provided about 2.7% chroma gain
 The proposed MMLM schemes double the number of models derived and used.
Notes of the previous meeting: “MMLM (and its add-ons MNLM, MFLM) need to determine two
models. Whereas the number of samples that is used to compute the models is the same in total, it cannot
be foreseen how many samples fall into which class. Therefore, it is more difficult for pipeline processing
than CCLM. The classification step, though it is a simple averaging criterion, also may impose some
additional pipelining issues. Gain of MMLM standalone is 0.3% luma, approx. 2.5% for chroma [for AI;
RA: 0.1% luma, approx. 2.0% for chroma – for 5.2.3.4 scheme]. It is recommended to further study
whether the complexity concerns are less valid in combination with the LM computation of JVET-L0191,
and whether the gain would still be preserved. It should also be investigated if MMLM and CCLM can
use same building blocks.”
In response to the above notes:
 The gain is somewhat less now: AI: -0.27%, -1.71%, -2.26%, RA: -0.13%, -1.30%, -1.73%
 The complexity concern (e.g., latency added by determining the threshold and applying the
classification step; although the cross-component prediction may not be in a critical-latency path)
remains valid.
 It was remarked that even with the current scheme, the complexity is a problem, esp. for small blocks
(2x2 chroma).
Due to complexity concerns, no action was taken on 2.1/2.2/2.2.1. This will be further discussed in the
CE-related BoG to clarify the concerns and recommend what to further study.
2.3 has an adaptive number of models, sometimes more than two per component, and showed less gain,
so no action was taken on that.
Regarding 2.4.x, the current scheme is optimized for type 0 chroma (the usual chroma per Rec. 709); 2.4
compensates for co-sited chroma (type 2 per BT.2100). The 2.4 test was done only on the PQ sequences.
A decoder might need to support two chroma types, with encoder high-level selection of which to apply.
Testing was not done to determine the potential penalty of running the type 2 optimized scheme on type 0
content. Test results for this were requested.
A participant remarked that he had done some testing on self-generated content that used type 1 (centered
both horizontally and vertically) and found not so much (~1-2%) benefit for customizing for that chroma
siting. Here the experiments show a much more substantial gain for optimization to type 2.
It was commented that proper chroma alignment may be more visually important than what shows up in
objective metrics.
The kernel of the 2.4.c 5-tap filter (except at CTU boundaries, where only one line above is used) is:
010
141
010
Decision: Adopt 2.4.c with a high-level flag to switch between two chroma format type optimizations.
Test results for applying the type 2 scheme to type 0 content. were discussed in a plenary. See notes in
section 10.1 about that.
Page: 85 Date Saved: 2019-03-172019-03-14

For 2.5.x, there was a focus on the first two variants. These are adding some additional complexity. The
gain seemed insuffient to justify changing the current scheme.
2.6.1 reduces the number of neighbour lines used to compute the model parameters to 1 (where the
current VTM scheme uses 3 columns to the left and 2 rows above when within the current CTU). 2.6.2
uses 3 columns to the left but only one row above. These would make the processing consistent whether
within a CTU or at the boundary.
But it was commented that adoption of the 2.6.1 or 2.6.2 scheme would not be reducing the line buffering
needed in a decoder, since it does not apply for the other chroma type. It was also commented that the
question of 1 or 2 lines had been discussed at the previous meeting and the 2 line scheme was considered
not a problem. So no action was taken on the 2.6.x proposals.
CE3.3 on ‘Intra mode coding’

3.1.1 Decoder-side intra mode derivation JVET-M0094
3.1.2 Decoder-side intra mode selection with predictor coding (3 candidates)
3.1.3 Decoder-side intra mode derivation with extended gradient filtering for
directly neighbouring pixels
3.1.4 Decoder-side intra mode derivation restricted for blocks with a number of
samples <= 128
3.2 6 MPMs and 32 remaining modes (5-bit FLC) JVET-M0495
3.3.1 Simplified MDMS with 5 chroma intra modes (2-point DM, 5 non-LM) JVET-M0218
3.3.2 Simplified MDMS with the reduced chroma intra modes (2-point DM, 3
non-LM)
3.4.1 Simplified MDMS by reducing the number of operations (2-point DM, 5 JVET-M0503
non-LM)
3.4.2 Simplified MDMS by reducing the number of candidates (2-point DM, 3
non-LM)
3.5 Simplified MDMS with one DM (1-point DM, 5 non-LM) JVET-M0203
Test #
Y U V EncT DecT Y U V EncT DecT
3.1.1 -0.11% -0.09% -0.08% 122% 103% -0.07% -0.06% -0.07% 104% 101%
3.1.2 -0.01% -0.05% -0.02% 122% 102% 0.01% 0.06% 0.04% 103% 100%
3.1.3 -0.12% -0.04% -0.05% 124% 104% -0.05% -0.01% 0.03% 103% 101%
3.1.4 -0.09% -0.09% -0.06% 113% 103% -0.05% 0.10% 0.01% 100% 100%
3.2 -0.03% -0.04% -0.05% 97% 100% 0.02% 0.14% 0.13% 99% 99%
3.3.1 -0.03% -0.88% -0.86% 100% 100% -0.01% -0.46% -0.50% 100% 100%
3.3.2 -0.02% -0.29% -0.20% 97% 100% 0.00% -0.12% -0.05% 99% 100%
3.4.1 -0.02% -0.96% -1.03% 101% 99% 0.04% -0.98% -1.04% 100% 100%
3.4.2 0.03% -0.34% -0.32% 97% 100% 0.10% -0.86% -0.92% 99% 100%
3.5 -0.01% -0.61% -0.64% 100% 100% 0.06% -0.68% -0.76% 100% 101%
CE3.3: Additional test results

Test # Description Y U V EncT DecT Y U V EncT DecT
3.5.1 Simplified -0.02% -0.58% -0.61% 100% 100% -0.02% -0.37% -0.39% 100% 100%
MDMS with
one DM by
using aligned
chroma coding
of VVC-3.0
(1-point DM, 4
Page: 86 Date Saved: 2019-03-172019-03-14

non-LM)
For 3.1.x, the proposal is to add another mode in which the intra prediction mode is inferred by decoder
processing rather than signalled. This adds encoder (and some decoder) complexity, but the test results do
not show much benefit from this, so no action was taken on this.
For 3.2, the proposal is to restrict the number of selectable intra prediction modes to 32 of the 67. Some
gain is observed, but only a small amount, and it was commented that the restriction of what modes an
encoder would be allowed to select would restrict encoder freedom on how to make its mode decisions
(not allowing an encoder to choose a mode until after it is able to determine which 32 of the 67 are
allowed for selection), so no action was taken on this.
3.3.1, 3.3.2, 3.4.1, 3.4.2, and 3.5 are regarding chroma mode coding, which is dependent on luma mode.
3.3.1 and 3.4.1 would increase decoder complexity. One key aspect is how many luma points are
considered for deriving the chroma mode candidates (1 or 2). Another key aspect is how many chroma
mode candidates there are (3 or 5).
Schemes 3.3.2 and 3.4.2 reduce the number of candidates from 5 to 3. As tested, this reduced encoding
time since the encoder checked fewer modes, although the decoder complexity is higher than for the
current scheme (because it uses a 2-point check for direct mode selection). It was commented that the DC,
planar, horizontal and vertical modes are especially important for some encoder implementations. If these
are not always selectable, it would force a dependency between luma and chroma for encoding decisions.
These two schemes did not provide much coding gain, although in the way they were tested, they reduced
encoding time. The lack of significant coding gain, together with that dependency, did not appear to
justify action on those.
Results for an additional scheme called 3.5.1 (proposed in JVET-M0203) were included in the CE report.
This was a late addition that was not in the CE plan, so it was considered a non-CE proposal.
3.3.1 and 3.4.1 check two luma locations, whereas the VTM checks only 1 (the central position of the
luma block). The VTM sends a flag on whether to use that mode; if not, it sends a CCLM mode flag; if
not, it sends 2 bypass-coded bins to select between four modes. If the luma mode was not DC, planar,
horizontal or vertical, then those are the four modes; otherwise the luma mode is replaced with the
vertical diagonal mode to determine the four modes.
3.3.1 and 3.4.1 check two luma locations and perform some comparison flowchart operations to
determine what is the primary selectable mode and what are the other four modes. The DC and planar
modes are always among the 5 selectable modes. It was noted that this forces a dependency between the
luma and chroma mode decisions unless the encoder only used DC and planar modes for chroma.
The possibility of supporting both the current scheme and the alternative was discussed. The gain seemed
insufficient to want to need two different ways to be supported in the decoder.
3.5 checks one luma location (same as VTM); if the luma mode is DC or planar and the block shape is
vertical, then instead of the vertical diagonal mode being considered special, the horizontal diagonal
mode is considered special; if the luma mode is angular, the other selectable modes are determined by a
flowchart (but the horizontal and vertical modes are not always available). This has basically the same
forced cross-component dependency as 3.3.1 and 3.4.1.
Since the gain is relatively small and the 3.3.1, 3.3.2, 3.4.1, 3.4.2, and 3.5 proposals introduce an
undesirable cross-component dependency for encoders, no action was taken on on these.
JVET-M0043 CE3: Affine linear weighted intra prediction (test 1.2.1, test 1.2.2) [J. Pfaff,
B. Stallenberger, M. Schäfer, P. Merkle, P. Helle, R. Rischke, H. Schwarz,
D. Marpe, T. Wiegand (HHI)]
Page: 87 Date Saved: 2019-03-172019-03-14

JVET-M0094 CE3: Decoder-side Intra Mode Derivation (tests 3.1.1, 3.1.2, 3.1.3 and 3.1.4)
[E. Mora, A. Nasrallah, M. Abdoli, M. Raulet (Ateme)]
JVET-M0097 CE3: On MMLM (Test 2.1) [A. K. Ramasubramonian, G. Van der Auwera,

T. Hsieh, V. Seregin, M. Karczewicz (Qualcomm)]
JVET-M0098 CE3: Joint test on MMLM (Test 2.2.1) [A. K. Ramasubramonian, G. Van

der Auwera, T. Hsieh, V. Seregin, M. Karczewicz (Qualcomm), H.-J. Jhu, Y.-
J. Chang (Foxconn)]
JVET-M0102 CE3: Intra Sub-Partitions Coding Mode (Tests 1.1.1 and 1.1.2) [S. De-
Luxán-Hernández, V. George, J. Ma, T. Nguyen, H. Schwarz, D. Marpe,
T. Wiegand (HHI)]
JVET-M0142 CE3: Modified CCLM downsampling filter for “type 2” content (Test 2.4)
[P. Hanhart, Y. He (InterDigital)]
JVET-M0203 CE3: DM-based chroma intra prediction mode (Test 3.5) [N. Choi,
M. W. Park, K. Choi (Samsung)]
JVET-M0218 CE3: Simplified MDMS (test 3.3.1 and test 3.3.2) [J. Choi, J. Heo, S. Yoo,
L. Li, J. Choi, J. Lim, S. Kim (LGE)]
JVET-M0252 CE3-1.3: Harmonization of Linear interpolation intra prediction (LIP) with

Multiple reference line prediction (MRL) [J. Heo, J. Choi, J. Choi, S. Yoo,
L. Li, J. Lim (LGE)]
JVET-M0263 CE3: CCLM prediction with single-line neighbouring luma samples (Test
2.6.1 and Test 2.6.2) [K. Zhang, L. Zhang, H. Liu, J. Xu, Y. Wang, P. Zhao,
D. Hong (Bytedance)]
JVET-M0401 CE3: Classification-based mean value for CCLM coefficients derivation

(tests 2.5.1-2.5.4) [X. Ma, A. Filippov, V. Rufitskiy, H. Yang, J. Chen
(Huawei)]
JVET-M0475 CE3: Multiple neighbour LM (Test 3.2.2) [H.-J. Jhu, Y.-J. Chang (Foxconn)]
Page: 88 Date Saved: 2019-03-172019-03-14

JVET-M0495 CE3: Intra mode coding (Test 3.2) [L. Zhao, X. Zhao, X. Li, S. Liu
(Tencent)]
JVET-M0503 CE3: Chroma intra prediction simplification (Test 3.4.1 and 3.4.2) [C.-H.
Yau, C.-C. Lin, C.-L. Lin (ITRI)]
JVET-M0504 CE3: adaptive multiple cross-component linear model (Test 3.2.3) [S.-P.
Wang, C.-H. Yau, C.-C. Lin, C.-L. Lin (ITRI)]
5.4 CE4: Inter prediction and motion vector coding (18)

Contributions in this category were discussed Thursday 10 Jan. 1120–1340 and 1500-2000 (Track B
chaired by JRO).
JVET-M0024 CE4: Summary report on inter prediction and motion vector coding
[H. Yang, S. Liu, K. Zhang]
This contribution provides a summary report of Core Experiment 4 on inter prediction and motion vector
coding. CE4 comprises 5 categories,
1) Merge mode simplification
2) Merge mode enhancement
3) Parallel processing for merge mode
4) Motion vector coding
5) Motion compensation constraints for complexity reduction
All techniques are implemented on top of and test against VTM 3.0. Simulation results and crosschecking
reports of each test specified in this document are provided.
CE4.1: Merge mode simplification
Test# Source Description

Reduce HMVP candidates from 5 to 5 - NST (NST: number of spatial/temporal
4.1.1.a JVET-M0124
candidates)
4.1.1.b JVET-M0124 Reduce HMVP candidates from 5 to 6 - NST
4.1.1.c JVET-M0124 Apply 4.1.1.a when NST >=3
4.1.1.d JVET-M0124 Apply 4.1.1.b when NST >=3
1) HMVP buffer size is increased from 6 to 10, with no pruning to update the buffer.
2) One out of every 3 is picked to add in the merge list. 4 HMVP candidates at most
4.1.2.a JVET-M0126
3) Pairwise candidates are generated not using HMVP candidates.
4) First 3 HMVP candidates are pruned to the left and above spatial candidates
4.1.2.a 1) 2) 3) + 4) First 2 HMVP candidates are pruned to the left and above spatial
4.1.2.b JVET-M0126 candidates
4.1.5.a JVET-M0281 Motion vector pruning: rounding before any MV pruning
Page: 89 Date Saved: 2019-03-172019-03-14

In merge apply some pruning on combined HEVC candidates, and/or pairwise
4.1.5.b JVET-M0281
averaged candidates
4.1.5.c JVET-M0281 4.1.5.a + 4.1.5.b
Regarding JVET-M0126, only aspects 1) and 2) were in the original proposal (JVET-L0401), whereas
aspects 3) and 4) were included in the first release of the software. It is suggested that the proponents also
provide separate results which show the benefit of combination 1/2, as well as 3-only and 4-only
separately.
Results were made available in JVET-M0126v8. Based on this analysis, it was found that only the
method 4.1.2.4 (First 2 HMVP candidates are pruned to the left and above spatial candidates) is relevant. This
would be competing with 4.1.1.a. Both methods have significant reduction in number of pruning process compared
to the current design, where 4.1.2.4 has even slightly less complexity, and loss of compression seems to be more
homogeneous over RA and LB (approx. 0.04% luma), and over different sequences.
Decision: Adopt JVET-M0126 version 4.1.2.4 (text is available, but needs to be reduced reflect that only this aspect
is changed.

4.1.1.a 0.00% 0.07% 0.02% 100% 100% 0.07% 0.14% 0.22% 101% 99%
4.1.1.b 0.00% 0.02% 0.06% 100% 101% 0.02% 0.01% 0.00% 101% 100%
4.1.1.c -0.04% 0.00% -0.01% 100% 100% 0.05% 0.06% 0.00% 101% 99%
4.1.1.d -0.02% 0.00% 0.01% 100% 99% 0.03% -0.04% -0.02% 100% 100%
4.1.2.a 0.03% 0.06% 0.03% 100% 100% 0.08% 0.07% 0.13% 100% 99%
4.1.2.b 0.03% 0.02% 0.04% 100% 100% 0.08% -0.03% 0.08% 99% 98%
4.1.5.a 0.00% -0.01% 0.00% 100% 100% -0.01% -0.04% -0.01% 100% 100%
4.1.5.b -0.02% 0.00% 0.00% 100% 100% 0.02% 0.09% -0.09% 99% 100%
4.1.5.c -0.02% -0.03% -0.01% 100% 100% -0.02% 0.06% 0.07% 99% 100%
Difference in
the number of
Max number of
Test# candidate Others RA LB
pruning stages
comparison
(+/- xx)
4.1.1.a -4 unchanged 0.00% 0.07%
4.1.1.b -2 unchanged 0.00% 0.02%
4.1.1.c -3 unchanged -0.04% 0.05%
4.1.1.d -2 unchanged -0.02% 0.03%
4.1.2.a -8 -2 HMVP table = 10 0.03% 0.08%
HMVP table=10, runtime saving of
4.1.2.b -10 -3 0.03% 0.08%
HMVP functions is 59%(RA), 62%(LB)
4.1.5.a +0 +0 0.00% -0.01%
4.1.5.b +6 +1 Discard pairwise calculation -0.02% 0.02%
4.1.5.c +6 +1 Discard pairwise calculation -0.02% -0.02%
It was remarked that the table above should be updated to get better understanding of the properties. 4.1.1
and 4.1.2 are modifying HMVP. In particular, the number of maximum pruning operations and
comparison operations necessary during table construction and during merge should be listed separately.
Number of cycles should also be calculated rather than number of pruning stages. It is reported that 4.1.2
is not doing any pruning during table construction (using FIFO list, but with extended length from 5 to
10) and also reduces the number of pruning operations in merge list construction. 4.1.1. is keeping the
HMVP list construction unchanged, but reduces the pruning operations in merge list construction.
More analysis later became available (see under the discussion of the adoption of JVET-M0126 above).
Page: 90 Date Saved: 2019-03-172019-03-14

4.1.5a is performing rounding of candidates before the AMVP list construction. Currently, it is done
before AMVP list construction for AMVP 1 pel and 4 pel accuracy, and from 1/16 pel to 1/4 pel after
merge list construction for AMVP 1/4 pel accuracy. This makes the design more consistent. It is noted
that alternatively consistency could be achieved by doing rounding after merge list construction for 1 pel
and 4 pel accuracy, however this was reported to have been tried and gave loss, as candidates which were
identical after rounding would have been different before rounding. Some support and no objection was
raised on this approach. Decision: Adopt JVET-M0281 (subtest 4.1.5a)
4.1.5b adds another pruning stage in merge list construction for 0.02% coding gain. (before VTM3, there
was higher gain on such an approach)
CE4.2: Merge mode enhancement
4.2.1.a JVET-M0059 +One non-scaling STMVP: Averaging the first two spatial candidates and TMVP
+One non-scaling STMVP: STMVP using a single adjacent above candidate, a single
4.2.2.a JVET-M0106 adjacent left candidate and a TMVP candidate. The single adjacent candidate is the
first valid one checked at three potential positions.
4.2.2.b JVET-M0106 4.2.2.a with merge list size = 8
4.2.2.a + One more STMVP candidate (two spatial average) + Remove pair-wise
4.2.2.c JVET-M0106
candidate
4.2.2.d JVET-M0106 4.2.2.c with merge list size = 8
4.2.3.a JVET-M0221 +One non-scaling STMVP: Averaging the left spatial, above spatial and TMVP
4.2.4.a JVET-M0404 +One non-scaling STMVP: Averaging the first two HMVP candidates and TMVP
MMVD modifications: 1) increase base candidates from 2 to 3; 2) Decrease distance
4.2.5.a JVET-M0291
index from 8 to 4.
MMVD modifications: 1) increase directions from 4 to 8; 2) Decrease distance index
4.2.5.b JVET-M0291
from 8 to 4.

4.2.1.a -0.09% -0.04% -0.06% 100% 100% 0.00% 0.00% 0.00% 100% 102%
4.2.2.a -0.11% -0.03% 0.00% 101% 99% 0.00% -0.12% 0.02% 107% 110%
4.2.2.b -0.17% -0.10% -0.09% 101% 100% -0.06% -0.14% -0.25% 107% 110%
4.2.2.c -0.15% -0.10% -0.13% 100% 100% 0.00% -0.18% 0.01% 107% 110%
4.2.2.d -0.23% -0.15% -0.13% 101% 100% -0.06% -0.16% -0.11% 107% 111%
4.2.3.a 0.00% 0.00% -0.01% 101% 101% 0.11% 0.18% 0.29% 100% 101%
4.2.4.a -0.03% 0.05% 0.00% 108% 106% 0.16% 0.28% 0.13% 110% 109%
4.2.5.a 0.07% 0.17% 0.14% 100% 95% 0.03% 0.13% 0.24% 100% 97%
4.2.5.b 0.02% 0.17% 0.14% 100% 97% -0.07% 0.10% 0.10% 100% 94%
Current VTM3: Merge list size 6, Max number of potential candidates 18, Max number of candidate
comparisons 15, Max number of pruning stages 8-9(?)
Max number Max number Max number
Merge Max number
Test# of potential of candidate of pruning Others RA LB
list size of MV scaling
candidates comparison stages
4.2.1.a 6 +1 0 0 0 -0.09% 0.00%
4.2.2.a 6 +1 +4 +1 +0 -0.11% 0.00%
4.2.2.b 8 +1 +4 +1 +0 -0.17% -0.06%
4.2.2.c 6 +2 +9 +2 +0 -0.15% 0.00%
4.2.2.d 8 +2 +9 +2 +0 -0.23% -0.06%
4.2.3.a 6 0.00% 0.11%
4.2.4.a 6 -0.03% 0.16%
4.2.5.a 6 0.07% 0.03%
4.2.5.b 6 0.02% -0.07%
Page: 91 Date Saved: 2019-03-172019-03-14

4.2.1 through 4.2.4 relate to STMVP, 4.2.5 relates to MMVD. All proposals target providing compression
gain by doing some additional processing. 4.2.3 and 4.2.4 have not provided complexity data so far (by
2nd day of meeting), but also do not seem to provide advantage in compression.
From the results above, better results are obviously possible with more complexity.
It was agreed that the merge list size should not be increased. Therefore, only 4.2.1a, 4.2.2a/c are
reasonable proposals. Among these, 4.2.1a has the best tradeoff performance/complexity. It is however
mentioned that the method was disabled for LB test, because it would have provided small loss (due to
missing scaling). It would be an undesirable design to change the list of candidates depending on the
frame dependencies.
In 4.2.1a, the additional STMVP candidate is put into the list at the position before the B2 (and therefore
also before pairwise and HMVP candidates). Furthermore, there are some additional checks in the
algorithm that are not reflected in the table above.
After all, none of the proposals provides sufficient benefit to take action.
4.2.5 should better be considered in context of CE4.4 (MV coding)
CE4.3: Parallel processing for merge mode

4.3.1.a JVET-M0170 Share merge list for translational merge and sub-CU merge with fixed threshold = 32
4.3.1.b JVET-M0170 Share merge list for translational merge and sub-CU merge with fixed threshold = 64
4.3.1.c JVET-M0170 Share merge list for translational merge and sub-CU merge with fixed threshold = 128
4.3.1.d JVET-M0170 Share merge list for translational merge and sub-CU merge with fixed threshold = 256
4.3.1.e JVET-M0170 Share merge list for translational merge and sub-CU merge with fixed threshold = 512
S1: A neighbour coding block is marked as unavailable if its bottom right coordinate
4.3.2.a JVET-M0289 falls in the extended merge estimation region of the current block.
Fixed square MER = 8x8
4.3.2.b JVET-M0289 S1. Fixed square MER = 16x16
4.3.2.c JVET-M0289 S1. Fixed square MER = 32x32
4.3.2.d JVET-M0289 S1. Fixed square MER = 64x64
falls in the estimation region of the current block and the QT depth of the current block
4.3.2.e JVET-M0289
is equal to or greater than the value of CTU size divided by MER size.
Fixed square MER = 8x8
4.3.2.f JVET-M0289 S2. Fixed square MER = 16x16
4.3.2.g JVET-M0289 S2. Fixed square MER = 32x32
4.3.2.h JVET-M0289 S2. Fixed square MER = 64x64
4.3.2.i JVET-M0289 falls in the rectangular merge estimation region of the current block.
Rectangular MER = 32
4.3.2.j JVET-M0289 S3: Rectangular MER = 64
4.3.2.k JVET-M0289 S3: Rectangular MER = 128
4.3.2.l JVET-M0289 S3: Rectangular MER = 256
Page: 92 Date Saved: 2019-03-172019-03-14

Test# Thrs/MER Y U V EncT DecT Y U V EncT DecT
4.3.1.a 32 0.00% 0.00% 0.00% 101% 102% 0.02% -0.05% -0.04% 101% 102%
4.3.1.b 64 0.04% 0.02% 0.05% 101% 104% 0.08% -0.04% 0.15% 101% 102%
4.3.1.c 128 0.12% 0.18% 0.16% 101% 102% 0.14% 0.22% 0.28% 102% 102%
4.3.1.d 256 0.44% 0.52% 0.66% 102% 103% 0.63% 0.68% 0.69% 103% 102%
4.3.1.e 512 0.68% 0.85% 0.92% 102% 102% 0.93% 0.86% 1.09% 103% 101%
4.3.2.a 8x8 (S1) 0.16% 0.27% 0.25% 100% 101% 0.14% 0.13% 0.36% 100% 101%
4.3.2.b 16x16 (S1) 0.55% 0.67% 0.78% 101% 101% 0.56% 0.66% 0.70% 101% 102%
4.3.2.c 32x32 (S1) 1.41% 1.64% 1.69% 104% 100% 1.41% 1.38% 1.54% 103% 100%
4.3.2.d 64x64 (S1) 2.62% 2.72% 2.97% 106% 100% 2.51% 2.56% 2.61% 104% 100%
4.3.2.e 8x8 (S2) 0.02% 0.01% 0.03% 99% 100% 0.01% 0.08% 0.04% 100% 101%
4.3.2.f 16x16 (S2) 0.16% 0.24% 0.26% 100% 99% 0.16% 0.11% 0.18% 101% 101%
4.3.2.g 32x32 (S2) 1.09% 1.27% 1.44% 102% 99% 1.13% 1.20% 1.20% 102% 100%
4.3.2.h 64x64 (S2) 2.59% 2.66% 2.92% 105% 98% 2.44% 2.45% 2.51% 103% 96%
4.3.2.i 32 (S3) 0.00% 0.07% 0.04% 100% 101% 0.00% 0.04% 0.04% 101% 104%
4.3.2.j 64 (S3) 0.03% 0.06% 0.06% 101% 102% 0.01% 0.04% -0.17% 101% 105%
4.3.2.k 128 (S3) 0.15% 0.20% 0.27% 101% 102% 0.15% 0.22% 0.06% 102% 104%
4.3.2.l 256 (S3) 0.35% 0.47% 0.55% 102% 101% 0.37% 0.31% 0.50% 102% 104%
Similar concepts (shared merge of JVET-M0170, parallel merge of JVET-M0289) have been used in
HEVC, where parallel is regarded mostly beneficial for parallel processing at the encoder, whereas shared
merge could also have some benefit for the decoder, as it is not necessary to generate merge lists
separately for very small blocks (however only if the sharing would be made mandatory, which is not the
case in HEVC). However, due to the fact that VVC has more irregular (non-square) block structures,
consistent definition of regions which use shared merge / parallel merge becomes more difficult. For
example, if the regions are square, it may happen that a rectangular block is only partially included. 4.3.1
and 4.3.2 S3 try to solve that by introducing non-square regions below some parent node of the tree.
Both approaches require normative changes. Making the decoder more complex for the benefit of a
parallel encoder may be not as desirable as it was in HEVC, in particular as it is more irregular due to
non-square blocks. Reducing decoder complexity by sharing merge lists between very small blocks (e.g.
two adjacent 4x4 blocks use same merge seems relative simple to define and would be beneficial if it is
normative. Results from test 4.3.1a above are from a version called “type1” in JVET-M0170, whereas
“type2” (that is also described in JVET-M0170) with threshold 32 would be the desirable solution. The
type2 is understood in a way that if after a split any block is smaller than the threshold, all blocks of that
split share the same merge list (e.g. 16x4 split ternary or 8x8 with quad split). This needs to be
mandatory. Reportedly, this comes with no loss for luma, and some negligible loss (0.03/0.06%) for
chroma. This was being cross-checked in JVET-M0584 (“supplementary test D1”) which was not
finished yet.
This was revisited after the cross-check was finished. Cross-checkers had been asked to investigate the
code and associated specification. The specification text should be simplified such that the threshold is
not signalled, but always used as 32. X.Li is also asked to inspect the code and text.
It was later confirmed (Tue 15 Jan afternoon) by the cross-checkers and X. Li that everything is
consistent as requested above. Text is available in v4 of JVET-M0170.
Decision: Adopt JVET-M0170 (type 2, draft text “…type2sharing” of Jan. 12)
Further study on the aspects that simplify encoder, in particular also by investigating the potential of non-
normative solutions. It is mentioned that by the time when parallel merge was introduced in HEVC, a
corresponding non-normative solution would have lost about 2% in compression performance.
CE4.4: Motion vector coding
4.4.1.a JVET-M0403 MVD is not signalled as x/y components but as layer and index: Two layer-groups.
4.4.1.b JVET-M0403 MVD is not signalled as x/y components but as layer and index: Four layer-groups.
Symmetrical MVD mode: BiDirPredFlag, RefIdxSymL0 and RefIdxSymL1 are
4.4.3 JVET-M0481 derived at slice level; Only mvp_l0_flag, mvp_l1_flag and MVD0 are explicitly
signalled; MVD1=-MVD0.
Page: 93 Date Saved: 2019-03-172019-03-14

4.4.4.a JVET-M0060 Diagonal direction candidate for MMVD: Increase MMVD directions from 4 to 8.
4.4.4.b JVET-M0060 Multiple distance lists for MMVD: Two distance lists, each of which has 4 entries.
4.4.4.c JVET-M0060 4.4.4.a + 4.4.4.b
4.4.4.c+ full-pel position for large range: MV is rounded to integer if the second list is
4.4.4.d JVET-M0060
selected and distance index > 1
4.4.4.e JVET-M0061 Combination of 4.4.4.a and 4.4.5.c
MMVD with adaptive distance table based on occurrences: The distance table is
4.4.5.a JVET-M0312
updated at slice level according to a gain-comparison algorithm.
MMVD with adaptive distance table based on picture resolution: A special distance
4.4.5.b JVET-M0312
table is used on 4K-sequences.
4.4.5.c JVET-M0312 4.4.5.a + 4.4.5.b

4.4.1.a 0.01% 0.02% 0.02% 96% 96% 0.03% -0.09% -0.11% 97% 92%
4.4.1.b 0.00% 0.04% 0.02% 96% 96% -0.01% 0.01% -0.02% 97% 92%
4.4.3 -0.16% -0.12% -0.16% 105% 100% 0.00% 0.00% 0.00% 100% 100%
4.4.4.a -0.13% -0.07% -0.08% 106% 100% -0.05% 0.03% 0.00% 104% 100%
4.4.4.b -0.05% 0.03% 0.01% 102% 100% 0.09% 0.09% 0.11% 101% 100%
4.4.4.c -0.28% -0.16% -0.19% 106% 100% 0.01% 0.14% 0.25% 104% 100%
4.4.4.d -0.28% -0.17% -0.20% 106% 100% 0.00% 0.28% 0.07% 103% 100%
4.4.4.e -0.38% -0.39% -0.48% 101% 100% -0.15% -0.11% -0.01% 102% 100%
4.4.5.a -0.22% -0.33% -0.35% 103% 98% -0.13% -0.10% -0.04% 105% 100%
4.4.5.b -0.21% -0.34% -0.41% 103% 98% -0.08% -0.11% -0.10% 105% 100%
4.4.5.c -0.24% -0.43% -0.46% 103% 98% -0.13% -0.10% -0.04% 105% 100%
4.4.5 * -0.11% -0.14% -0.18% 103% 98% -0.08% -0.11% -0.10% 105% 106%
4.4.5* is an encoder optimization that is done on top of VTM3. All other 4.4.5 results use this encoder
optimization, but compare against VTM3 without it. 4.4.4.e is a combination of 4.4.5.c and 4.4.4.a, which
additionally has some other encoder optimization.
4.4.1: The claimed benefit is that the number of context-coded bins in MVD coding is reduced from 4 to
1. This is achieved by joint coding of x and y differences, where the “layer” is the sum of x and y, and the
index is an addressing in a layer. Index is coded as truncated binary (number of indices depends on the
layer). In total, the number of bits for expressing the layer and the index is not changed relative to the
independent coding of MVD.
Only the MVD coding part was changed, motion estimation, RDO etc. were identical.
4.4.1a is the simpler solution, difference in compression performance is marginal.
It was initially planned in Track B to adopt JVET-M0403 (test 4.4.1a, 2 layer groups, where the first
group is just the 0,0 MVD).
Specification text was available.
In the Sunday plenary it was discussed that the benefit of context coding reduction in MVD coding is
almost marginal, and might not justify changing a well established scheme. Further, in the context of later
discussion related to CE8, it was detected that this might have coding efficiency problems with CPR.
Furthermore, it would be more difficult to check in the layer/index representation if the CPR range
constraints are valid. It was therefore agreed to revert the decision above (Thu. 17 Jan. afternoon).
4.4.3: The compression gain of symmetric MVD coding is 0.16% (was approx. 0.6% before), could be
reduced by the fact that VTM3 incudes MMVD, which also uses symmetric coding, and also other
elements of improved MV coding. Encoding time increases by 5%, very simple for decoder.
Some concern is expressed that not all of the current gain may be retained when MMVD would be further
improved.
Page: 94 Date Saved: 2019-03-172019-03-14

There was another contribution (JVET-M0444) which reported that by further encoder optimization and
disallowing combination with BDOF further gain is possible. See further notes reported on discussion of
the BoG report JVET-M0843.
Proposals related to MMVD:
4.4.4.a: Add diagonal direction candidates. This saves 0.13% for RA, 0.05% for LB, encoder time
increases by about 5%.
4.4.4.b: Instead one list with 8 MVD, use two lists with 4 each, where the first list is narrow range, the
second list wider range of differences. Whereas the maximum MVD in current design is 32, here it is
suggested as 8. This has 0.05% gain for RA, 0.09% loss for LB. One more context coded bin. Encoding
time is increased by 2%
4.4.4.c: Combination of a/b, giving 0.28% in RA. The new distance table seems to be more efficient for
diagonal direction. Furthermore, 4.4.4.a has more encoding checks, which may be another reason.
It is noted that the VTM encoder has also a “non fast” MMVD check which also provides additional
compression gain by doing more checks.
4.4.4.d: Integer rounding does not give benefit.
Not clear how much the elements of the proposal (introducing diagonal directions, and modifying the
MVD coding) contribute to the compression gain, and how much is due to additional encoder
optimization. Generally for LB, no benefit at all.
4.4.5.a is recording the occurrences of the different MVD for each picture, and reordering of the distances
for the current picture is performed based on the data that were collected in the picture of list 0, refidx 0.
Some mechanism providing a “score” for a table is used as well.
It is pointed out that explicit signalling would be at almost no rate increase and without additional
decoding complexity, and also give up the dependency between slices. Generally, from the note on 4.4.5*
above, the benefit of reordering is relatively small (maybe in the range of 0.1%).
4.4.5.b makes the distance table dependent on picture resolution. The coding gain is observed mainly on
4K sequences (where a different table is used).
It is also pointed out that this could better be explicitly signalled rather than inferring it from the picture
size. The signalling overhead would be low.
4.4.5.c is combination of a and b, where the gain seems not to be additive.
4.4.4.e is a combination of 4.4.4 and 4.4.5, where some more fast algorithm for 4.4.4.c is included.
The results of 4.4.4b and 4.4.5 indicate that some improvement could be possible by adapting/modifying
the distance table, but it is not clear how much gain is due to encoder optimization as well. Further study
is necessary, and there are also CE related proposals which may provide more information.
In upcoming experiments on MMVD, it should be observed that it is possible to judge the benefit of new
normative aspects versus encoder optimization.
Proponents offer to provide additional results on just combining 4.4.4.a and 4.4.5.b. This should report
results versus an anchor that is VTM3+4.4.5*.
This was further discussed after such results were available (see JVET-M0854), and then also after
review of non-CE proposals and an initial expectation of how many different new aspects would be
investigated on MMVD in the next round of CE, decide whether such a combination could be a candidate
for VTM4, or be further studied in the next round of CE as well.
The encoder optimization of 4.4.5* is documented in JVET-M0823; it was cross-checked, and it was
agreed that this would be a candidate for a software adoption.
4.2.5 (JVET-M0291) is also MMVD related. The following aspect are included:
- increase base candidates from 2 to 3, and decrease size of distance table from 8 to 4 (4.2.5.a)
Page: 95 Date Saved: 2019-03-172019-03-14
- introduce diagonal directions, and decrease size of distance table from 8 to 4 (4.2.5.b)
A misalignment of software and text is also reported, where test 4.2.5.b follows the VVC3 spec which
disables combination of MMVD with triangle mode, and with CIIP. This may give some additional gain.
4.2.5.a gives small loss (0.07%, 0.03%) in RA and LB
4.2.5.b gives loss in RA (0.02%), small gain (-0.07%) in LB. These compare against the anchor without
the misalignment fix, which may mean that the results are worse both for RA and LB.
There is report about decoding time decrease, but it is unclear how around 5% could be explainable by
just reducing the distance table from 8 to 4.
CE4.5: Motion compensation constraints for complexity reduction

4.5.1 JVET-M0313 Disabling bi-prediction for 4x8 and 8x4 CUs
Disabling bi-prediction or inter prediction for CU which memory bandwidth
4.5.2 JVET-M0313 exceeds that of 8x8 bi-prediction: bi-prediction is disabled for 4×8, 8×4, 4×16 and
16×4 CUs, and inter prediction is disabled for 4×4 CUs.

4.5.1 0.09% 0.19% 0.25% 99% 96% 0.13% 0.08% 0.31% 99% 105%
4.5.2 0.32% 0.71% 0.81% 99% 97% 0.49% 0.88% 0.80% 98% 99%
The following table is provided:
Number of luma samples to be
CU size (W×H) fetched per luma sample
(W + 7) × (H + 7) / (W × H)
8×8 Bi-prediction 7.03
4×4 Uni-prediction 7.56
It is noted that the table above does not consider memory access patterns, is only pixel level access.
Further study on these aspects is needed. There are also non-CE proposals which use other methods (e.g.
shorter interpolation filters, integer pel, padding, …) which could be considered for reducing memory
access.
Establish BoG (K. Zhang) to review the CE4 related proposals, and suggest aspects to be studied in CE.
Consider either significant complexity reduction without losing compression performance, or proposals
with significant improvement of compression without increasing complexity. If there are proposals that
are closely related to proposals that were investigated in CE (e.g. some beneficial encoder optimization,
or minor syntax change with benefit, or further complexity reduction), these should be reported to Track
B for possible consideration for adoption.
Page: 96 Date Saved: 2019-03-172019-03-14

JVET-M0059 CE4: Non-scaling STMVP (Test 4.2.1) [T. Zhou, T. Ikai (Sharp)]

The proposed method derives an averaging candidate as STMVP candidate using two spatial merge
candidates and one collocated merge candidate.
i=0
if( availableFlagA1 )
mergeCandList[ i++ ] = A1
if( availableFlagB1 )
mergeCandList[ i++ ] = B1
mergeCandList[ i++ ] = B0 (8-118)
if( availableFlagSbCol )
mergeCandList[ i++ ] = STMVP
if( availableFlagCol )
mergeCandList[ i++ ] = Col
For the spatial candidates, the first and second candidates in the current merge candidate list is used.
For the temporal candidate, the same position as VTM / HEVC collocated position is used.
If three candidates, of which the reference are equal to zero, are available, the following apply.
mvLX[0] = (mvLX_A[0] * 3 + mvLX_L[0] * 3 + mvLX_C[0] * 2 ) / 8
mvLX[1] = (mvLX_A[1] * 3 + mvLX_L[1] * 3 + mvLX_C[1] * 2 ) / 8
If two motion information, of which the reference are equal to zero, is available, the following apply
mvLX[0] = (mvLX_A[0] + mvLX_C[0] ) / 2
mvLX[1] = (mvLX_A[1] + mvLX_C[1] ) / 2
or
mvLX[0] = (mvLX_B[0] + mvLX_C[0] ) / 2
mvLX[1] = (mvLX_B[1] + mvLX_C[1] ) / 2
Note: If the temporal candidate is unavailable, the STMVP mode is off.
JVET-M0060 CE4: Enhanced Merge with MVD (Test 4.4.4) [T. Hashimoto, E. Sasaki,
T. Ikai (Sharp)]
Directional candidates
Directional candidates are used in addition to horizontal / vertical candidates of VTM-3.0. The directional
candidates are shown as below.
Motion direction (proposal)
Direction IDX 000 001 010 011 100 101 110 111
x-axis +2 –2 0 0 +1 -1 -1 +1
y-axis 0 0 +2 –2 +1 -1 +1 -1
Note: the value of x-axis and y-axis of diagonal direction are half of that of horizontal and vertical
direction respectively.
Page: 97 Date Saved: 2019-03-172019-03-14

Multiple distance lists
Two set of distance lists are proposed. The selection flag is context coded so that it applies in an optimal
way. The distance list is shown as follows.
First distance list
Distance IDX 0 1 2 3
Pixel distance 1/4-pel 1/2-pel 3/4-pel 5/4-pel
Second distance list
Pixel distance 1-pel 2-pel 4-pel 8-pel
Full-pel position for large range
In test d, motion vectors are converted into an integer position if the distance is large. Since integer
position doesn’t need additional pixels for interpolation, necessary area size for MMVD encoding /
decoding decreases, which would reduce memory band requirement. When the second distance list is
selected and distance index is larger than 1, the motion vectors are converted into an integer position.
JVET-M0061 CE4: Combination of CE4.4.4.a and CE4.4.5.c (Test 4.4.4.e) [T. Hashimoto,

E. Sasaki, T. Ikai (Sharp), J. Li, R.-L. Liao, C. S. Lim (Panasonic)]
A combination of CE4.4.4.a and CE4.4.5.c.
JVET-M0687 Crosscheck of JVET-M0061 (CE4.4.4e: Combination of CE4.4.4.a and

CE4.4.5.c) [L. Xu, F. Chen, L. Wang (Hikvision)] [late]
JVET-M0106 CE4: STMVP without scaling (tests 4.2.2) [F. Le Léannec, T. Poirier,
F. Galpin (Technicolor)]
Test 4.2.2.a
The proposed STMVP technique is based on JVT-L0207. It consists in constructing the STMVP merge
candidate as follows.
 One top-neighbouring motion vector (MV) of current CU is selected among spatial position (w/2,-1),
(2*w,-1) and (w-1,-1). The first found position where all available MVs use the reference picture
index 0 is selected.
 One left-neighbouring motion vector (MV) of current CU is selected among spatial position (-1,h/2),
(-1,2*h) and (-1,h-1). The first found position where all available MVs use the reference picture index
0 is selected.
 The same temporal MV predictor as in JVET-L0207 is used. The temporal candidate is set as always
available, given that the Right-Bottom position of the current block is inside the picture. The y-
position of the temporal candidate is clipped to ensure it lies inside the current CTU row.
 The STMVP candidate is considered as available if at least 2 spatial-temporal MV predictors are
found. If only one neighbouring MV is retrieved, no STVMP candidate is included into the merge
list.
 No MV scaling is applied.
 The STMVP candidate is computed as the average between the 2 or 3 retrieved spatial and temporal
MV predictors.
Test 4.2.2.c
Page: 98 Date Saved: 2019-03-172019-03-14

Test 4.2.2.c involves 2 additional aspects over test 4.2.2.a.
 A second STMVP candidate is added to the merge candidate list, if 3 motion vectors (thus including
the temporal predictor) had been used to generate the first STMVP candidate. The additional STMVP
candidate consists in the average of two spatial MV predictors used to construct the first STMVP
candidate.
 Pairwise average candidates are disallowed.
JVET-M0124 CE4: Methods of Reducing Number of Pruning Checks of History Based

Motion Vector Prediction (Test 4.1.1) [J. Zhao, S. Kim (LGE)]
A method was proposed to limit the number of HMVP candidates to check based on how many spatial
and temporal candidates already exist in the merge list. The idea is that if there are not many spots left in
the merge list for the HMVP candidates, it may not need to check all the available HMVP candidates in
the table. The benefit is to reduce the number of pruning checks when inserting HMVP to the merge list.
Four subtests with different thresholds are tests as listed below.
a) NHMVPChecked = 5 - NST . Threshold 5 is picked because it equals to maxNumMergeCand -1 , which is the
max number of HMVP candidates allowed to be added to the merge list, so 5- N ST is how many spots
left in the merge list for HMVP candidates, i.e. N mrgToBeAdded
b) NHMVPChecked = 6 - NST . 6 is picked because it equals the maxNumMergeCand
c) NHMVPChecked = (NST >=3) ? 5 - NST : NHMVP . This is applying a) when NST >=3
d) NHMVPChecked = (NST >=3) ? 6 - NST : NHMVP . This is applying b) when NST >=3
JVET-M0126 CE4: Modification on History-based Motion Vector Prediction [Y. Han, W.-

J. Chien, C.-C. Chen, H. Huang, C.-H. Hung, Y. Zhang, M. Karczewicz
(Qualcomm)]
HMVP table without pruning
In this conurbation, redundancy check is removed from HMVP table update.
Subsampling HMVP table when adding HMVP candidates in merger list
In this contribution, the size of HMVP table is increased to 10, and one out of every 3 is picked to add in
the merge list. At most 4 HMVP candidates can be used.
In order to reduce the number of pruning, partial pruning is used when adding a new HMVP candidate in
merge list. In the sub test CE4.1.2.a, only the first 3 HMVP candidates are pruned by the left and above
spatial candidates. In the sub test CE4.1.2.b, only the first 2 HMVP candidates are pruned by the left and
above spatial candidates.
HMVP in AMVP mode
The size of HMVP table is increased to 10, and one out of every 3 HMVP candidates is picked to add in
the AMVP list.
Remove dependency between HMVP and pairwise candidates
In VTM3.0, pairwise candidates are derived from the candidates in the merge list which brings
dependency between pairwise predictors and HMVP predictors. In this contribution, pairwise candidates
are generated not using HMVP predictors.
Page: 99 Date Saved: 2019-03-172019-03-14

JVET-M0826 Crosscheck of JVET-M0126 supplemental data (CE4: Modification on
history-based motion vector prediction) [Y.-C. Lin (MediaTek)] [late]
JVET-M0170 CE4.3.1: Shared merging candidate list [C.-C. Chen, Y.-C. Lin, M.-S.
Chiang, C.-W. Hsu, T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S.-M. Lei
(MediaTek)]
It is proposed to share the same merging candidate list for all leaf CUs of one ancestor node in the CU
split tree for enabling parallel processing of small skip/merge-coded CUs. The ancestor node is named
merge sharing node. The shared merging candidate list is generated at the merge sharing node pretending
the merge sharing node is a leaf CU.
There are 2 types of size threshold definitions, which are denoted as Type-1 and Type-2 definitions. For
Type-1 definition, the merge sharing node will be decided for each CU inside a CTU during parsing stage
of decoding; moreover, the merge sharing node is the largest ancestor node among all the ancestor nodes
of the leaf CUs satisfying the following two criteria.
1) The merge sharing node size is equal to or smaller than the size threshold
2) No samples of the merge sharing node are outside the picture boundary.
For Type-2 definition, the merge sharing node will be decided for each CU inside a CTU during parsing
stage of decoding; moreover, the merge sharing node is an ancestor node of leaf CU which must satisfy
the following 2 criteria:
1) The merge sharing node size is equal to or larger than the size threshold
2) In the merge sharing node, one of the child CU size is smaller than the size threshold
The proposed shared merging candidate list algorithm supports translational merge (including merge
mode and triangle merge mode, history-based candidate is also supported) and subblock-based merge
mode. For all kinds of merge mode, the behavior of shared merging candidate list algorithm looks
basically the same, and it just generates candidates at the merge sharing node pretending the merge
sharing node is a leaf CU.
Besides, it is proposed to add new syntax elements to sequence parameter set (SPS) and picture parameter
set (PPS).
Notes from the BoG report review: JVET-M0507 has two aspects, where the aspect of removing the
clipping for the shared merge list might also be beneficial on top of JVET-M0170. It is reported to come
at no coding loss. The proponents of JVET-M0507 discussed with proponents of JVET-M0170 that the
check for one of the subbocks being outside of the picture could be removed, whereas another check
whether the CU center is still inside needed to be added, to make it consistent with other boundary check
conditions in VVC. Proponents of JVET-M0170 were to make an update on this aspect.
JVET-M0584 Crosscheck of JVET-M0170 (CE4.3.1: Shared merging candidate list)

Supplementary Tests [Y. Han, H. Wang, C.-C. Chen, W.-J. Chien
(Qualcomm)] [late]
Note: The title of the crosscheck was initially wrong and was later corrected.
JVET-M0221 CE4: STMVP simplification (test 4.2.3a) [Y.-H. Chao, Y. Han, W.-J. Chien,
M. Karczewicz (Qualcomm)]
In this proposal, four modifications are proposed to simplify the complexity in the non-sub-PU STMVP
in JVET_L0399, as described as follows:
1. No MV scaling for the two spatial neighbours.
Page: 100 Date Saved: 2019-03-172019-03-14

2. STMVP candidates with non-local spatial neighbours are removed. As a result, only one STMVP
is added into merge candidate list.
3. For STMVP with local spatial neighbours, instead of searching up to two positions for above
(left) spatial neighbours, only one position is checked. The positions are the same as the 1st and
2nd checked candidates in the non-sub-block merge candidate list.
4. If three candidates are available, i.e., the temporal candidate ( MV T ¿ on co-located block is
available and the two spatial candidates are available with reference index equals to zero, the
STMVP candidate is calculated as
MV S 0+ MV S 1 MV T
MV STMVP= +
4 2
Note that the denominators in the divisions are always a power of two, and therefore can be
implemented using shift operations.
JVET-M0281 CE4: Inter motion predictor pruning (test 4.1.5) [A. Robert, F. Le Léannec,
T. Poirier, F. Galpin (Technicolor)]
In AMVP, a motion predictor is a motion vector dedicated to a particular reference picture, and a list must
contain 2 motion predictors. The process is repeated for each reference frame of each reference frame list.
In VTM3, when performing the AMVR rounding, the ¼-pel rounding should be performed at the same
time. This rounding step takes place just before the existing pruning. But for motion predictors that do not
use AMVR, the needed ¼-pel rounding is performed at the end of the list construction.
This contribution then proposes to perform all the rounding operations before pruning even if AMVR is
off, i.e. either ¼-pel or AMVR and ¼-pel rounding is done before any pruning.
In Merge mode, a motion predictor is one or two motion vector(s) with its associated reference picture,
and a list must contain 6 motion predictors.
The pruning process of the spatial candidates has been simplified and the one of the temporal candidate
has been removed. But, for pair-wise candidates, no pruning process exists.
This contribution then proposes to perform an early and simple pruning of the pair-wise candidates. For
each used pair (A, B), the pair-wise candidate is not calculated:
 If both A and B are bi-directional and both motion vectors are equal,
 If both A and B are uni-directional or only A is bi-directional and motion vectors of the common list
are equal,
If only B is bi-directional and motion vectors and reference frame of the common list are equal.
JVET-M0289 CE4: Parallel Merge Estimation for VVC (Test 4.3.2) [H. Gao, S. Esenlik,
B. Wang, A. M. Kotra, J. Chen (Huawei)]
Variant 1
In the variant 1, the MER is defined as a fixed non-overlapped square grid.
According to the proposal the rule for setting a neighbour unavailable for merge list construction is
changed as follows.
New parallel merge estimation rule: “A neighbour coding block is marked as unavailable if its bottom
right coordinate falls in the extended merge estimation region of the current block”. The extended MER is
depicted in the following figure:
Page: 101 Date Saved: 2019-03-172019-03-14

Assume that the bottom right coordinate a neighbour block is given by (XN b, YNb) and the top-left
coordinate of the current block is given by (XCt, YCt). Moreover, assume that the binary logarithm of
MER size is given by N. The neighbour block is marked as unavailable for prediction if;
(XNb >> N is equal to XCt >> N) AND (YNb >> N smaller than or equal to YCt >> N)
OR
(YNb >> N is equal to YCt >> N) AND (XNb >> N smaller than or equal to XCt >> N)
Variant 2
In the variant 2, the MER is defined as a fixed non-overlapped square grid by QT depth.
changed as follows.
right coordinate falls in the estimation region of the current block and the QT depth of the current block is
equal to or greater than the value of CTU size divided by MER size ”.
Assume that the CTU size is given by CTUSize, the bottom right coordinate a neighbour block is given
by (XNb, YNb), the top-left coordinate of the current block is given by (XC t, YCt) and the QT Depth of the
current block is given by CuQtDepth. Moreover assume that the binary logarithm of MER size is given
by N. The neighbour block is marked as unavailable for prediction if;
(CTUSize >> CuQtDepth smaller than or equal to 1<< N)
AND
(YNb >> N is equal to YCt >> N) AND (XNb >> N equal to XCt >> N)
Variant 3
1. Definition of rectangular MER
In the variant 3, the MER is defined rectangular block with same number of luma samples.
changed as follows.
Page: 102 Date Saved: 2019-03-172019-03-14

right coordinate falls in the rectangular merge estimation region of the current block”. The MER of the
current block is defined in the follow:
Assuming the MER number of luma samples is the MER threshold, an ancestor block of the current block
is equal to the threshold. Then the region of the ancestor is defined as the MER of the current block.
For example in the Figure 1, if the current block is block D with size 4x8, the MER threshold is 256,
based on the definition of the MER, the whole Figure 1 is defined as the MER of block D. Therefore,
block A, B, C and E are marked as unavailable for merge estimation.
2. Worst Case Guarantee
Worst case of parallel merge estimation is defined as how many sets of parallel processing merge per
MER threshold number of luma samples.
For example if the current block is 4x4, the MER threshold is 32 samples and the parent of the current
block is 4x8. Then the 4x8 region is defined as MER based on 3.3.1, and per 32 samples 1 set of parallel
processing merge.
However, based on the MER definition in 3.3.1, in some special case, the worst case is not guaranteed by
1 set of parallel processing merge.
For example, if the current block is 4x4, the MER threshold is 32 and the current block is split from QT
which means the parent block size is 8x8. Then MER is not defined, and per 64 samples 4 sets of (parallel
processing) merge, which equivalents to per 32 samples 2 sets of (parallel processing) merge
In another example, if the current block is 4x4, the MER threshold is 32 and the current block is split
from vertical TT which means the parent block size is 4x16. Then MER is not defined, and per 64
samples 3 sets of (parallel processing) merge, which equivalents to per 32 samples 1.5 sets of (parallel
processing) merge
To guarantee the worst case, on top of 3.3.1, the MER of current block is additional defined as follow:
Assuming the MER number of luma samples is the MER threshold, an ancestor block of the current block
is equal to the threshold multiplied by 2 and the current block is split from QT or TT. Then the region of
the ancestor is defined as the MER of the current block.
JVET-M0291 CE4: Extension on MMVD (Test 4.2.5) [X. Chen, J. Zheng (HiSilicon)]

Variant 1
For the merge candidates, three candidates can be selected, and choice one to be the starting point.
Distance index indicates the pre-defined distance from the starting point information. Pre-defined distance
is as follows:
Pixel distance 1/4-pel 1/2-pel 1-pel 2-pel
Variant 2
For variant 2, 4 new diagonal directionMV offsets for each distance is induced. Distance of diagonal
offsets are half of vertical and horizontal direction distance of exited offsets.
Distance index indicates the pre-defined distance from the starting point information. Pre-defined distance
is as follows:
Pixel distance 1/4-pel 1/2-pel 1-pel 2-pel
For variant 2, Bug of MMVD flag signalling (When MMVD mode is selected, no need to transfer triangle
flag or Intra-Inter combined mode flag) is fixed.
Page: 103 Date Saved: 2019-03-172019-03-14

JVET-M0686 Crosscheck of JVET-M0291 (CE4.2.5: Extension on MMVD) [L. Xu,
F. Chen, L. Wang (Hikvision)] [late]
JVET-M0312 CE4: MMVD improvement (test 4.4.5) [J. Li, R.-L. Liao, C. S. Lim
(Panasonic)]
Adaptive distance table is proposed to improve coding gain of MMVD.
Test 1
Use adaptive distance table based on occurrence-based distance table reordering.
1. An optimal reordered distance table is determined after coding each inter picture. If current
picture is intra picture, base distance table is used as optimal reordered distance table.
2. The optimal reordered distance table of reference picture in list 0 and reference index 0 is used as
distance table for current inter picture.
3. Weighted table is used for determining optimal reordered distance table. And weighted table is
determined using gain table.
gain_table[8][8] = {
{ 0, -1, -2, -3, -4, -5, -6, -6},
{ 2, 1, 0, -1, -2, -3, -4, -4},
{ 4, 3, 2, 1, 0, -1, -2, -2},
{ 6, 5, 4, 3, 2, 1, 0, 0},
{ 8, 7, 6, 5, 4, 3, 2, 2},
{10, 9, 8, 7, 6, 5, 4, 4},
{12, 11, 10, 9, 8, 7, 6, 6},
{14, 13, 12, 11, 10, 9, 8, 8} };
gain_table_4K[8][8] = {
{ 4, 3, 2, 1, 0, -1, -2, -2},
{ 6, 5, 4, 3, 2, 1, 0, 0},
{ 8, 7, 6, 5, 4, 3, 2, 2},
{10, 9, 8, 7, 6, 5, 4, 4},
{12, 11, 10, 9, 8, 7, 6, 6},
{14, 13, 12, 11, 10, 9, 8, 8},
{16, 15, 14, 13, 12, 11, 10, 10},
{18, 17, 16, 15, 14, 13, 12, 12} };
Test 2
Use adaptive distance table based on picture resolution, i.e., if picture resolution is not larger than 2K, i.e.,
for 1920×1080, the table below is used as the base distance table:
MMVD distance table candidate
Distance IDX 0 1 2 3 4 5 6 7
Pixel distance 1/4-pel 1/2-pel 1-pel 2-pel 4-pel 8-pel 16-pel 32-pel
Otherwise, the table below is used as the base distance table.

MMVD distance table
Distance IDX 0 1 2 3 4 5 6 7
Pixel distance 1-pel 2-pel 4-pel 8-pel 16-pel 32-pel 64-pel 128-pel
Page: 104 Date Saved: 2019-03-172019-03-14

Test 3 : Test 1 + Test 2
In the CE results, the encoder is changed. Some early termination operations for MMVD ME in VTM-3.0
are removed. 0.11%/0.08% BD-rate reduction is reported on RA/LB with this encoder change.
JVET-M0867 Crosscheck of CE4.4.5* [E. Sasaki, T. Ikai (Sharp)] [late]
JVET-M0313 CE4: Motion compensation constraints for complexity reduction (test 4.5.1
and test 4.5.2) [R.-L. Liao, J. Li, C. S. Lim (Panasonic)]
To guarantee that the worst-case memory bandwidth is not exceeded that of 8×8 bi-prediction, bi-
prediction is disabled for small CU. For the CU coded in merge mode, the motion vector from L0
direction of a bi-prediction motion vector candidate is used to predict the CU, which is the same situation
in HEVC. For the CU coded in inter mode, only uni-prediction is allowed and the first bin of the inter
direction which indicates uni-prediction or bi-prediction is not signalled.
JVET-M0403 CE4: Generic Vector Coding of Motion Vector Difference (Tests 4.4.1.a and
4.4.1.b) [S. Paluri, M. Salehifar, S. Kim (LGE)]
Modifications to the algorithm have been carried out to reduce the worst case use of context coded bins
from 24 to 6 by coding MVDx and MVDy components together. MVD (x,y) is coded using a
combination of Layer and index information, wherein the index identifies the MVD(x,y) combination
within a group of MVDs (i.e., a Layer). Both the tests differ in their groupings of the layers. In the
former, all the layers greater than 0 are grouped together, while in the later test, layers greater than or
equal to 3 are grouped together while layers 1 and 2 are grouped separately.
JVET-M0698 Crosscheck of JVET-M0403: CE4: Generic Vector Coding of Motion Vector

Difference (Tests 4.4.1.a and 4.4.1.b) [L. Pham Van, W.-J. Chien,
M. Karczewicz (Qualcomm)] [late]
JVET-M0404 CE4: History based spatial-temporal MV prediction (Test 4.2.4) [X. Xu,

The proposed method derives a new candidate using last two history MVs and one collocated merge
candidate (referred as HMVP-TMVP). The new candidate is inserted after A1, B1, B0 and A0 candidates,
as follows:
i=0
if( availableFlagSbCol )
mergeCandList[ i++ ] = HMVP+TMVP
if( availableFlagCol )
mergeCandList[ i++ ] = Col
Page: 105 Date Saved: 2019-03-172019-03-14

For the two MVs from HMVP, the last coded and second to last coded MVs in the buffer are used
(referred as A and B). For the temporal candidate, the same position as VTM-3.0 collocated position
(referred as C) is used.
If three candidates, of which the reference indices are equal to zero, are available, the following apply.
mvLX[0] = (mvLX_A[0] * 3 + mvLX_B[0] * 3 + mvLX_C[0] * 2 ) / 8
mvLX[1] = (mvLX_A[1] * 3 + mvLX_B[1] * 3 + mvLX_C[1] * 2 ) / 8
If two motion information, of which the reference indices are equal to zero, is available, the following
apply
mvLX[0] = (mvLX_A[0] + mvLX_C[0] ) / 2
mvLX[1] = (mvLX_A[1] + mvLX_C[1] ) / 2
or
mvLX[0] = (mvLX_B[0] + mvLX_C[0] ) / 2
mvLX[1] = (mvLX_B[1] + mvLX_C[1] ) / 2
Note: If the temporal candidate is unavailable, the HMVP-TMVP mode is off.
JVET-M0481 CE4: Symmetrical MVD mode (Test 4.4.3) [H. Chen, T. Solovyev, H. Yang,
J. Chen (Huawei)]
In slice level, variables BiDirPredFlag, RefIdxSymL0 and RefIdxSymL1 are derived by searching the
reference pictures in List 0 and List 1.
In CU level, a symmetrical mode flag indicating whether symmetrical mode is used or not is explicitly
signalled if the prediction direction for the CU is bi-prediction and BiDirPredFlag is equal to 1.
When the flag is true, only mvp_l0_flag, mvp_l1_flag and MVD0 are explicitly signalled. The reference
indices are set equal to RefIdxSymL0, RefIdxSymL1 for list 0 and list 1, respectively. MVD1 is just set
equal to –MVD0. The final motion vectors are shown in below formula.
¿
5.5 CE5: Arithmetic coding engine (10)

Contributions in this category were discussed Thursday 10 January 1700–2030 (in Track A chaired by Y.
Ye).
JVET-M0025 CE5: Summary report on the Arithmetic Coding Engine [H. Kirchhoffer,

A. Said]
This is the summary report of Core Experiment 5 (CE5) on the Arithmetic Coding Engine. Subtest 1
(experiments CE5.1.1 – 5.1.13) addresses the effect on the compression efficiency of training parameters
of the probability estimation stage of the proposed arithmetic coding engines. Subtest 2 addresses the
achievable throughput of the different coding engines of subtest 1 in an optimized software
implementation. Subtest 3 provides a summary of the analysis of hardware implementation aspects.
The experiments were implemented in separate branches in the following git repository:
For subtest 2, a testbed is available in branch CE5.2, which contains throughput-optimized software
implementations of the coding engines of subtest 1.
Page: 106 Date Saved: 2019-03-172019-03-14

The following table lists all tests that were performed in this CE and gives a summary of the tools.
Note on the naming convention of CE tests: ‘CE5.x.y.z’ means ‘CE5.x.y’ as specified in the CE5
description with configuration ‘z’ according to the following tables.
CE5.1 – Probability estimation with retrained parameters
CE5.1 – Probability estimation with retrained parameters
CE # Related Docs. Summary of the tool Crosscheckers
(Proponent)
5.1.1 JVET-M0725 2 linear states (10+14 bits), fixed MediaTek
(HHI)
5.1.2 JVET-M0725 2 linear states (10+14 bits), variable MediaTek
(HHI)
5.1.3 JVET-M0412 2 linear states (10+14 bits), variable: HHI
(Qualcomm) Configuration 1: Coding interval subdivision from
JVET-L0335 is used
Configuration 2: Coding interval subdivision from
JVET-L0117 is used
5.1.4 JVET-M0413 1 linear state (14 bits), variable: Sharp Labs
(Qualcomm) Configuration 1: Coding interval subdivision from
JVET-L0335 is used
Configuration 2: Coding interval subdivision from
JVET-L0117 is used
5.1.5 JVET-M0727 2 log. states (8+12 bits), fixed Sharp Labs
(HHI)
5.1.6 JVET-M0727 2 log. states, variable Sharp Labs
(HHI) Configuration 1: 8+12 bits
Configuration 2: 10+14 bits
5.1.7 JVET-M0727 1 log. state (12 bits), variable Sharp Labs
(HHI)
5.1.8 JVET-M0199 2 linear states (15+15 bits), fixed MediaTek
(Samsung) Only the short window size model is updated for the
first 31 bins of a context model.
5.1.9 JVET-M0172 2 linear states (10+14 bits), fixed Samsung
(MediaTek) Multiplier-based coding interval subdivision.
Configuration 1: 6-bit by 5-bit multiplier.

Configuration 2: 6-bit by 4-bit multiplier.
Both configurations can implemented as 32x8x8 bit

LUT.
5.1.10 JVET-M0453 2 linear states, fixed HHI
(Sharp Labs) Uses 2b−1 instead of 2b in probability update
5.1.11 JVET-M0453 2 linear states, variable HHI
5.1.12 JVET-M0453 1 linear state, variable MediaTek
(Sharp Labs) Uses 2 −1 instead of 2 in probability update
b b
5.1.13 JVET-M0453 2 linear states, variable HHI

Uses 5x4 multiplier for coding interval
subdivision
Page: 107 Date Saved: 2019-03-172019-03-14

AI RA LB
EncT/ EncT/ EncT/
CE # Y U V DecT Y U V DecT Y U V DecT
(%) (%) (%)
5.1.1 -0.81% -1.15% -1.20% 105/101 -0.71% -1.06% -0.97% 102/100 -0.60% -0.22% -0.18% 102/100
5.1.2 -0.97% -1.18% -1.27% 107/101 -0.97% -0.99% -0.93% 103/99 -0.89% -0.08% -0.25% 102/99
5.1.3.1 -0.95% -1.35% -1.44% 107/103 -0.90% -1.06% -0.97% 105/106 -0.77% -0.01% -0.23% 106/103
5.1.3.2 -0.99% -1.42% -1.53% 107/105 -0.95% -1.07% -1.04% 106/106 -0.82% -0.04% -0.15% 107/104
5.1.4.1 -0.80% -1.12% -1.11% 108/107 -0.64% -0.11% -0.01% 107/110 -0.56% 1.01% 1.51% 107/104
5.1.4.2 -0.89% -1.21% -1.18% 108/107 -0.71% -0.26% -0.05% 108/109 -0.61% 1.02% 1.76% 107/107
5.1.5 -0.76% -1.47% -1.41% 101/98 -0.63% -0.79% -0.70% 97/93 -0.68% -0.29% 0.08% 94/91
5.1.6.1 -0.83% -1.51% -1.53% 103/98 -0.76% -0.77% -0.75% 98/93 -0.76% -0.44% -0.15% 95/92
5.1.6.2 -0.91% -1.44% -1.44% 104/97 -0.81% -0.92% -0.85% 98/93 -0.72% -0.42% -0.05% 95/92
5.1.7 -0.66% -1.12% -1.10% 100/98 -0.53% -0.96% -0.95% 97/93 -0.52% -0.66% -0.52% 94/92
5.1.8 -0.86% -1.36% -1.37% 106/101 -0.68% -0.86% -0.71% 102/101 -0.53% -0.60% 0.51% 99/95
5.1.9.1 -0.79% -1.05% -1.18% 105/101 -0.57% -1.05% -1.00% 102/100 -0.50% -0.82% -0.66% 103/101
5.1.9.2 -0.76% -1.02% -1.15% 105/102 -0.55% -1.03% -0.98% 102/100 -0.49% -0.81% -0.65% 102/101
5.1.10 -0.79% -1.10% -1.16% 108/104 -0.67% -1.06% -1.02% 104/102 -0.54% -0.38% -0.78% 103/101
5.1.11 -0.94% -1.14% -1.23% 108/103 -0.93% -0.95% -1.05% 103/101 -0.80% -0.27% -0.38% 102/101
5.1.12 -0.66% -0.74% -0.50% 108/103 -0.55% 0.18% 0.94% 102/100 -0.54% 0.81% 2.33% 101/99
5.1.13 -0.93% -1.13% -1.21% 109/103 -0.91% -0.93% -1.03% 104/101 -0.78% -0.24% -0.35% 101/98
2 states variable, 2 states fixed, 1 state variable
It was reported that some of the encoding/decoding time in the table may not be reliable. It was
commented that these tests have similar encoding/decoding time, and variation is in the noise range.
The CABAC engine and the initialization states are tested together.
VTM 3 uses HEVC CABAC engine with the following characteristics:
 1 log. state, 7 bits, fixed window size
 Coding interval subdivision of 64x4x8 bits LUT
Throughput-optimized software implementations of the configurations in CE5.1 are tested in terms of the
achievable throughput in the decoder. Two types of bin sequences are used for the evaluation:
 VTM3: Bin sequences extracted from VTM-3.0 CTC bitstreams
 RND: Randomly generated bin sequences
Three contributions report results for CE5.2:
 JVET-M0453 (Sharp)
 JVET-M0463 (Qualcomm)
 JVET-M0762 (HHI)
It was commented that JVET-M0453 and JVET-M0463 reported consistent trends in terms of throughput
numbers for the CE tests. JVET-M0762 was a late contribution that was updated shortly before the CE
review started. It was agreed to review JVET-M0762 for further discussion of this CE. See notes under
JVET-M0762.
JVET-M0172 CE5.1.9: CABAC engine with simplified range sub-interval derivation [T.-D.
Chuang, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0199 CE5: Counter-based probability estimation (CE5.1.8) [K. Choi, Y. Piao

(Samsung)]
Page: 108 Date Saved: 2019-03-172019-03-14

JVET-M0412 CE5: Per-context CABAC initialization with double windows (Test 5.1.3)
[A. Said, J. Dong, H. Egilmez, Y.-H. Chao, M. Karczewicz, V. Seregin
(Qualcomm)]
JVET-M0413 CE5: Per-context CABAC initialization with single window (Test 5.1.4)
[A. Said, J. Dong, H. Egilmez, Y.-H. Chao, M. Karczewicz, V. Seregin
(Qualcomm)]
JVET-M0453 CE5 on arithmetic coding: experiments 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6,
5.1.7, 5.1.8, 5.1.10, 5.1.11, 5.1.12, 5.1.13, 5.2, and more [F. Bossen (Sharp)]
This report provides results for the following CE5 experiments: 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6,
5.1.7, 5.1.8, 5.1.10, 5.1.11, 5.1.12, 5.1.13 and 5.2. Additional variants of these experiments are considered
where constants, such as initial state values and shift amounts, are modified.
Version 2 of the document provides additional results for experiment 5.2 on throughput, as well as BD-
rate results for a configuration that yields no encoder run time increase.
The following table reports the decoder throughput from an actual bin stream (first 10 million context-
coded bins from ParkRunning, RA configuration, QP22). Three compilers have been tested: clang 10.0
(Apple LLVM version 10.0.0), gcc 7.4 (Homebrew GCC 7.4.0) and gcc 8.2 (Homebrew GCC 8.2.0). The
test bed was configured with the macro NOBRANCH_MPS either on (left half of table) or off (right half
of table). Results were obtained on an Intel® Xeon® W-2140B CPU @ 3.20GHz.
In almost all cases the combination of clang and NOBRANCH_MPS enabled yielded the highest
throughput. This configuration is thus considered for comparing the various engines.
The rightmost column in the table below reports the decoder throughput for a different bin stream (first 10
million context-coded bins from BQTerrace, RA configuration, QP22, clang, NOBRANCH_MPS
enabled).
Page: 109 Date Saved: 2019-03-172019-03-14

Engine clang gcc 7 gcc 8 clang gcc 7 gcc 8 clang
stream #2
AVC/HEVC CABAC 132.03 134.9 128.64 127.2 121.13 124.9 137.88
2 7 8
CE5.1.1 120.17 117.4 118.58 113.5 108.52 109.2 121.51
8 4 6
CE5.1.2 115.00 110.9 113.28 104.0 108.47 102.2 114.67
3 1 0
CE5.1.3 106.63 104.9 104.60 95.89 96.84 96.37 102.79
8
CE5.1.4 109.09 106.6 107.28 104.7 104.45 104.7 110.55
8 7 7
CE5.1.4 mult 134.85 133.0 131.12 120.0 116.32 117.7 135.13
9 9 2
CE5.1.5 113.46 106.7 107.56 111.6 102.44 104.7 113.02
5 7 5
CE5.1.6 (8+12 bit) 110.75 105.0 103.62 103.6 98.89 100.0 108.50
7 4 7
CE5.1.7 119.00 110.9 112.45 118.5 110.15 107.8 120.23
8 1 4
CE5.1.8 118.80 114.2 107.99 107.7 103.96 100.4 119.39
7 1 7
CE5.1.9 / CE 5.1.10 125.05 122.6 120.02 120.4 113.33 115.9 127.29
8 7 6
CE5.1.11 121.79 117.3 117.14 107.2 113.08 111.2 123.35
3 5 2
CE5.1.12 128.95 123.8 127.78 118.6 119.66 120.2 129.01
0 0 2
CE5.1.13 / CE5.1.3 mult 127.28 121.0 122.57 109.9 109.25 110.6 127.32
0 0 7
Experiments were run a second time, where each test is done 7 times and the highest throughput value is
recorded. While the numbers are slightly higher, the same trends persist.
Page: 110 Date Saved: 2019-03-172019-03-14

Engine clang gcc 7 gcc 8 clang gcc 7 gcc 8 clang
stream #2
AVC/HEVC CABAC 137.27 137.8 131.01 131.6 124.68 127.9 141.37
3 9 3
CE5.1.1 124.17 121.6 120.26 117.4 112.53 110.4 124.48
4 1 2
CE5.1.2 116.69 115.3 116.85 106.2 110.39 109.2 115.93
6 2 4
CE5.1.3 107.96 106.1 105.99 96.69 98.59 97.68 108.09
3
CE5.1.4 111.83 109.1 109.93 106.8 106.21 106.5 112.09
4 0 1
CE5.1.4 mult 136.30 133.9 132.36 120.8 116.32 121.0 137.27
6 5 1
CE5.1.5 115.84 109.1 108.83 114.7 105.29 105.2 115.73
1 1 1
CE5.1.6 (8+12 bit) 112.69 106.8 103.99 105.0 102.27 102.2 112.68
8 0 1
CE5.1.7 120.75 112.9 113.24 119.1 106.58 114.9 120.89
4 2 7
CE5.1.8 122.01 116.0 108.10 110.0 107.50 102.5 125.28
4 9 4
CE5.1.9 / CE 5.1.10 128.67 124.2 121.22 122.2 119.20 117.5 129.44
0 2 5
CE5.1.11 124.55 118.7 119.37 114.5 114.48 112.3 125.28
3 3 9
CE5.1.12 130.26 128.1 130.77 121.1 121.84 120.4 131.45
7 3 5
CE5.1.13 / CE5.1.3 mult 128.51 122.6 126.85 112.1 111.23 112.9 128.87
3 0 6
It was agreed that the second table of throughput numbers had much lower probability of having outlier
values in it.
The table below summarizes the performance of various arithmetic coding engines, classifying them in
three groups:
 Two states, fixed window sizes
 Two states, variable (context-adaptive) window sizes
 Single state, variable (context-adaptive) window sizes
BD rate numbers are reported as combined YUV, where BD rate numbers for Y, U and V are weighted as
90%/5%/5% to obtain a single number. This is done to account for the fact that results for individual color
components can sometimes diverge.
Also provided for each engine are encoder/decoder run times relative to VTM3, as well as SW throughput
results from experiment 5.2.
Within each group and each test condition the best BD rate and throughput results are highlighted in
green. The worst results are highlighted in red.
Experiment numbers with a star indicate a variant, where some constants are modified as described.
Page: 111 Date Saved: 2019-03-172019-03-14

Engine AI RA LB LP AI RA LB Thruput
2 states, fixed window size
5.1.1 -0.85% -0.74% -0.56% -0.56% 106/103 103/102 101/100 120.17
5.1.5 -0.83% -0.64% -0.62% -0.60% 109/107 105/103 103/103 113.46
5.1.8 -0.91% -0.69% -0.48% -0.50% 106/102 103/101 100/98 118.80
5.1.10 -0.83% -0.70% -0.55% -0.61% 108/104 104/102 103/101 125.05
5.1.10* + new init from 5.1.2 -0.84% -0.73% -0.51% -0.53% 109/107 105/104 105/104 125.05
5.1.10* 5x6 mult -0.85% -0.73% -0.58% -0.64% 109/107 105/104 104/104 127.86
2 states, variable window
size
5.1.2 -1.00% -0.97% -0.82% -0.76% 109/105 104/103 101/101 115.00
5.1.3 clz + 8x8 table -1.03% -0.96% -0.74% -0.83% 107/108 104/104 104/104 106.63
5.1.3 4x5 mult -0.99% -0.91% -0.71% -0.83% 109/105 104/102 103/102 127.28
5.1.3* 5x6 mult -1.07% -0.99% -0.79% -0.91% 108/104 104/103 104/103 127.28
5.1.6 8+12 bit state -0.90% -0.76% -0.72% -0.69% 111/105 105/103 105/102 110.75
5.1.6 10+14 bit state -0.97% -0.82% -0.67% -0.73% 112/105 105/102 105/102 110.75
5.1.11 -0.97% -0.93% -0.75% -0.76% 108/103 103/101 102/101 121.79
5.1.11* + new init from 5.1.2 -1.00% -0.98% -0.77% -0.75% 110/105 104/102 104/102 121.79
5.1.13 -0.95% -0.91% -0.73% -0.74% 109/103 104/101 101/98 127.28
5.1.13* +new init from 5.1.2 -0.98% -0.96% -0.75% -0.73% 110/105 104/103 106/103 127.28
5.1.13* 5x6 mult -1.03% -0.98% -0.75% -0.75% 109/105 104/102 104/104 127.28
1 state, variable window size
5.1.4 clz + 8x8 table -0.92% -0.65% -0.41% -0.44% 108/107 103/104 104/103 109.09
5.1.4 4x5 mult -0.83% -0.58% -0.37% -0.41% 108/105 104/102 102/102 132.95
5.1.4* 5x6 mult -0.93% -0.67% -0.46% -0.49% 107/105 104/102 104/103 132.95
5.1.7 -0.70% -0.57% -0.53% -0.52% 107/107 104/103 103/104 119.00
5.1.12 -0.65% -0.44% -0.33% -0.25% 108/103 102/100 101/99 128.95
The table above was copied from JVET-M0453 and then updated in group discussion to form the
modified table below. The each category in the table was reviewed and particular tests that provided the
highest coding efficiency in each category with good throughput numbers were highlighted for further
focused discussion. The properties, similarities and differences between the tested methods were
discussed.
The following table was obtained by updating the table above as follows: 1) adding 5.1.9, 2) replacing
throughput numbers with the second throughput number table, and 3) keeping only rows that pertain to
the CE tests.
Engine AI RA LB LP AI RA LB Thruput
VTM3 w/ HEVC engine 0 0 0 0 100/100 100/100 100/100 137.83
2 states, fixed window size
5.1.1 -0.85% -0.74% -0.56% -0.56% 106/103 103/102 101/100 124.17
5.1.5 -0.83% -0.64% -0.62% -0.60% 109/107 105/103 103/103 115.84
5.1.8 -0.91% -0.69% -0.48% -0.50% 106/102 103/101 100/98 122.01
5.1.9 -0.79% -0.57% -0.50% N/A 128.67
5.1.10 -0.83% -0.70% -0.55% -0.61% 108/104 104/102 103/101 128.67
5.1.10* + new init from 5.1.2 -0.84% -0.73% -0.51% -0.53% 109/107 105/104 105/104 128.67
2 states, variable window size
5.1.2 -1.00% -0.97% -0.82% -0.76% 109/105 104/103 101/101 116.69
5.1.3 clz + 8x8 table (config. 2) -1.03% -0.96% -0.74% -0.83% 107/108 104/104 104/104 107.96
5.1.3 4x5 mult (config. 1) -0.99% -0.91% -0.71% -0.83% 109/105 104/102 103/102 128.51
5.1.6 8+12 bit state -0.90% -0.76% -0.72% -0.69% 111/105 105/103 105/102 112.69
5.1.6 10+14 bit state -0.97% -0.82% -0.67% -0.73% 112/105 105/102 105/102 112.69*
5.1.11 -0.97% -0.93% -0.75% -0.76% 108/103 103/101 102/101 124.55
5.1.11* + new init from 5.1.2 -1.00% -0.98% -0.77% -0.75% 110/105 104/102 104/102 124.55
5.1.13 -0.95% -0.91% -0.73% -0.74% 109/103 104/101 101/98 128.51
5.1.13* +new init from 5.1.2 -0.98% -0.96% -0.75% -0.73% 110/105 104/103 106/103 128.51
Page: 112 Date Saved: 2019-03-172019-03-14

1 state, variable window size
5.1.4 clz + 8x8 table (config. 2) -0.92% -0.65% -0.41% -0.44% 108/107 103/104 104/103 111.83
5.1.4 4x5 mult (config. 1) -0.83% -0.58% -0.37% -0.41% 108/105 104/102 102/102 136.30
5.1.7 -0.70% -0.57% -0.53% -0.52% 107/107 104/103 103/104 120.75
5.1.12 -0.65% -0.44% -0.33% -0.25% 108/103 102/100 101/99 130.77
It was suggested to look at the hardware aspect of these different engines, which was provided as part of
JVET-M0025 subtest 3.
It was agreed that no hardware problem had been identified for any of the CE tests, and that such a
hardware problem could be fixed if/when it was identified.
When looking at different categories, it was remarked that the “1 state, variable window” category has the
highest throughput (closest to HEVC engine), and the “2 state, variable window” category has the highest
coding performance. Regarding the “2 state, fixed window” category, it was remarked that this category
does not need custom window size parameters for different context models, but needs re-training of
initialization parameters.
Regarding custom window size parameters, it was remarked that that does not seem to increase
complexity to such a degree that it justifies going for a simpler solution (i.e. fixed window size).
It was remarked that some of the coding efficiency gain from the tests that use custom window size
parameters may have come from training of custom window size parameters based on the test set.
It was remarked that the initialization parameters were also trained on the test set, which also may have
provided some of the coding efficiency gain.
In terms of coding efficiency, the options “5.1.3 4x5 mult (config. 1)”, “5.1.13” and “5.1.13* +new init
from 5.1.2” are the most attractive options. Between “5.1.3” and “5.1.13,” the latter has a slight advantage
for hardware implementations due to needing to support fewer shift values. And the difference between
“5.1.13” and “5.1.13* +new init from 5.1.2” is purely due to training of initialization parameters, with the
new initialization parameters providing better coding efficiency.
Decision: Adopt “5.1.13* +new init from 5.1.2”.
JVET-M0463 CE5: Report of throughput analysis of CE5 contributions (CE5.2) [J. Dong,

A. Said, V. Seregin, M. Karczewicz (Qualcomm)]
JVET-M0725 CE5: Results of tests CE5.1.1 and CE5.1.2 [J. Stegemann, H. Kirchhoffer,

H. Schwarz, D. Marpe, T. Wiegand (HHI)] [late]
JVET-M0727 CE5: Results of tests CE5.1.5, CE5.1.6, and CE5.1.7 [H. Kirchhoffer,

C. Bartnik, P. Haase, S. Matlage, J. Stegemann, D. Marpe, H. Schwarz,
T. Wiegand (HHI)] [late]
JVET-M0759 CE5: Report of subtest 3 on complexity and throughput aspects for

hardware [B. Stabernack (HHI), T. Hsieh (Qualcomm)] [late]
Page: 113 Date Saved: 2019-03-172019-03-14

JVET-M0762 CE5: Report of software throughput analysis for CE5.2 by HHI
[H. Kirchhoffer, C. Bartnik, T. Hinz, J. Stegemann, P. Haase, S. Matlage,
B. Stabernack, H. Schwarz, D. Marpe, T. Wiegand (HHI)] [late]
This contribution presents results for CE5 subtest 2. The throughput measurement testbed as implemented
in CE5.2 was used to produce throughput numbers for the test configurations of subtest 1.
The throughput numbers in version 1 of this document contained a bug. They are replaced with corrected
values in version 2.
The preprocessor macros of the testbed software of the CE5.2 branch are set according to the following
table from JVET-M0453-r1, section 3.1.
The throughput is measured for 11 synthetical bin sequences and 12 VTM-3.0 bitstreams.
Three combinations of two macros (NOBRANCH_MPS and NOBRANCH) were tested as follows.
2.1 NOBRANCH off, NOBRANCH_MPS off:
Page: 114 Date Saved: 2019-03-172019-03-14

2.2 (NOBRANCH off, NOBRANCH_MPS on:
Page: 115 Date Saved: 2019-03-172019-03-14

2.3 (NOBRANCH on, NOBRANCH_MPS on
It was commented that these graphs contained outliers. It was also commented that the graphs were
uploaded very late (~20 minutes before the CE5 discussion started). It was then agreed to review JVET-
M0453 instead, which provided throughput numbers for each CE test, for the further discussion of this
CE. See notes under JVET-M0453.
5.6 CE6: Transforms and transform signalling (21)

Contributions in this category were discussed Thursday 10 January 2030–2230, Friday 11 January 0900–
1100, 1130–1400, and 1530–2000 (chaired by GJS).
JVET-M0026 CE6: Summary Report on Transforms and Transform Signalling [A. Said,

X. Zhao (??)]
This contribution summarizes the activities of Core Experiment (CE) on Transforms and Transform
Signalling. The goal of this CE is to study transform design and signalling for the VVC standard. The CE
studies were divided into three categories, including:
(1) CE6.1: Transform core design (19 tests, 7 proposals)
(2) CE6.2: Fast transform (3 tests, 3 proposals)
(3) CE6.3: Transform selection and signalling (10 tests, 5 proposals)
(4) CE6.4: Sub-block transform (8 tests, 4 proposals)
(5) CE6.5: Secondary transform (1 tests, 1 proposal)
In this CE all experiments were done using based on the VTM 3.0 software with a bug-fix for low QP
configuration (without which the encoder could crash, a fix having no impact on CTC results since the
Page: 116 Date Saved: 2019-03-172019-03-14
CTC didn’t use extremely low QP values). This document summarizes the test results, brief experiment
definition, cross-check reports and complexity measurements.
For all tests, two configurations were tested: CTC and CTC+Inter MTS. For this meeting report, only the
CTC tables were included. The JVET-M0026 document contains the other tables as well.
For CE6.1 and CE6.2, additional low QP tests were done for QP values 1, 5, 9, 13, using only 100 frames
of each test sequence (since the encoding is very slow at these QP values).
CE6-1 Transform core design

Test # Docs. Description Tester Cross-checker
6-1.1a JVET-M0496 JVET-L0287: Replacing 4-pt DST-7 / DCT-8 by 4-pt X. Zhao A. Karabutov
DST-4 / DCT-4 used in MTS (Tencent) (Huawei)
6-1.1b JVET-L0287: Replacing 4-pt and 8-pt DST-7 / DCT-8 X. Zhao A. Karabutov
by 4-pt and 8-pt DST-4 / DCT-4 used in MTS, (Tencent) (Huawei)
respectively.
6-1.1c JVET-L0287: Compound Orthonormal Transform X. Zhao A. Karabutov
(Tencent) (Huawei)
6-1.1d 6-1.1c + 6.2.3a X. Zhao A. Karabutov
(Tencent) (Huawei)
6-1.1e JVET-M0084 JVET-L0262: Replacing all DST-7 / DCT-8 by DST-4 / K. Abe A. Karabutov
DCT-4 used in MTS (Panasonic) (Huawei)
Sony
Technicolor
6-1.2a JVET-M0200 JVET-L0060: Unified matrix for transform K. Choi X. Zhao
(Samsung) (Tencent)
6-1.3a JVET-M0244 JVET-L0353: MTS using DST-4 and transposed DCT-2 Y. Lin H. Egilmez
(HiSilicon) (Qualcomm)
6-1.3b MTS using DCT-2 like transforms Y. Lin H. Egilmez
(HiSilicon) (Qualcomm)
6-1.4a JVET-M0538 JVET-L0386, JVET-L0682: TAF for 32-pt MTS A. Said A. Karabutov
(Qualcomm) (Huawei)
X. Zhao
(Tencent)
6-1.4b JVET-L0386, JVET-L0682: TAF for 32-pt and 64-pt A. Said A. Karabutov
MTS (Qualcomm) (Huawei)
6-1.4c JVET-L0386, JVET-L0682: TAF for 16-pt and 32-pt A. Said A. Karabutov
MTS (Qualcomm) (Huawei)
X. Zhao
(Tencent)
6-1.4d JVET-L0386, JVET-L0682: TAF for 16-pt, 32-pt and A. Said A. Karabutov
64-pt MTS (Qualcomm) (Huawei)
6-1.5a JVET-M0080 JVET-L0135: TAF simplification for 32-pt MTS P. Philippe LGE
(Orange)
6-1.5b JVET-L0135: TAF simplification for 32-pt and 64-pt P. Philippe LGE
MTS (Orange)
6-1.5c JVET-L0135: TAF simplification for 16-pt and 32-pt P. Philippe LGE
MTS (Orange)
6-1.5d JVET-L0135: TAF simplification for 16-pt, 32-pt and P. Philippe LGE
64-pt MTS (Orange)
6-1.6a JVET-M0521 JVET-L0395:4-pt DST-4 and DCT-4 replacing DST-7 H. Egilmez Y. Lin
and DCT-8 used in MTS (Qualcomm) (HiSilicon)
6-1.6b JVET-L0395: 4-pt and 8-pt DST-4 and DCT-4 replacing H. Egilmez Y. Lin
DST-7 and DCT-8 used in MTS (Qualcomm) (HiSilicon)
6-1.6c JVET-L0395: 4-pt, 8-pt and 16-pt DST-4 and DCT-4 H. Egilmez Y. Lin
replacing DST-7 and DCT-8 used in MTS (Qualcomm) (HiSilicon)
Page: 117 Date Saved: 2019-03-172019-03-14

For CTC:
AI RA LB
Test # Doc. # Y U V EncT DecT Y U V EncT DecT Y U V EncT DecT
CE6-1.1a JVET-M0496 -0.17% -0.14% -0.11% 101% 99% -0.06% 0.05% 0.04% 101% 99% 0.02% 0.30% 0.13% 100% 98%
CE6-1.1b JVET-M0496 -0.10% -0.17% -0.18% 102% 99% -0.01% 0.14% 0.05% 100% 100% 0.05% 0.00% 0.01% 100% 97%
CE6-1.1c JVET-M0496 -0.03% -0.09% -0.09% 101% 100% 0.07% 0.12% 0.11% 101% 100% 0.15% 0.20% -0.42% 99% 98%
CE6-1.1d JVET-M0496 -0.04% -0.11% -0.13% 96% 91% 0.06% 0.08% 0.04% 99% 99% 0.10% 0.27% -0.05% 100% 100%
CE6-1.1e JVET-M0084 0.23% 0.03% 0.07% 103% 98% 0.16% 0.30% 0.26% 101% 101% 0.04% 0.22% -0.17% 101% 100%
CE6-1.2a JVET-M0200 -0.06% -0.14% -0.12% 101% 99% 0.07% 0.14% 0.11% 99% 99% 0.17% 0.32% 0.18% 97% 95%
CE6-1.3a JVET-M0244 0.08% 0.11% 0.10% 98% 97% 0.07% 0.25% 0.19% 100% 99% -0.02% 0.32% 0.33% 100% 101%
CE6-1.3b JVET-M0244 0.22% 0.34% 0.32% 97% 93% 0.17% 0.39% 0.36% 99% 99% 0.03% 0.34% 0.10% 100% 101%
CE6-1.4a JVET-M0538 0.00% 0.07% 0.05% 98% 94% -0.01% 0.08% 0.13% 100% 99% -0.02% 0.09% 0.11% 99% 99%
CE6-1.4b JVET-M0538 -0.07% 0.01% 0.00% 98% 94% -0.12% -0.12% -0.22% 100% 98% 0.01% 0.28% 0.01% 99% 97%
CE6-1.4c JVET-M0538 0.12% 0.17% 0.15% 95% 91% 0.04% 0.09% 0.18% 99% 99% 0.04% 0.20% 0.19% 99% 100%
CE6-1.4d JVET-M0538 0.05% 0.09% 0.08% 95% 90% -0.06% -0.11% -0.14% 99% 98% 0.01% -0.03% 0.01% 98% 96%
CE6-1.5a JVET-M0080 0.07% 0.06% 0.06% 96% 88% 0.06% 0.11% 0.11% 99% 99% 0.03% 0.18% 0.16% 100% 100%
CE6-1.5b JVET-M0080 0.02% -0.03% -0.02% 98% 88% -0.03% -0.14% -0.12% 101% 99% -0.01% 0.04% -0.15% 101% 100%
CE6-1.5c JVET-M0080 0.15% 0.09% 0.09% 94% 85% 0.09% 0.19% 0.25% 99% 98% 0.06% 0.16% 0.14% 100% 100%
CE6-1.5d JVET-M0080 0.09% 0.01% 0.02% 96% 85% 0.01% -0.07% -0.07% 101% 98% 0.07% 0.04% 0.05% 101% 100%
CE6-1.6a JVET-M0521 -0.17% -0.14% -0.11% 99% 103% -0.06% 0.05% 0.04% 100% 101% 0.02% 0.30% 0.13% 100% 99%
CE6-1.6b JVET-M0521 -0.12% -0.18% -0.16% 99% 101% -0.02% 0.16% 0.02% 100% 100% 0.02% 0.11% -0.07% 100% 100%
CE6-1.6c JVET-M0521 0.08% -0.06% -0.04% 101% 101% 0.09% 0.14% 0.18% 100% 100% 0.07% 0.00% 0.18% 100% 100%
For low QP
The following table summarizes the results for CE6-1 using low QP configuration and VTM-3.0 as
anchor.
AI RA LB
CE6-1.1a JVET-M0496 0.00% -0.06% -0.06% 99% 100% 0.00% -0.02% -0.01% 100% 100% -0.01% 0.00% -0.01% 101% 101%
CE6-1.1b JVET-M0496 0.24% 0.00% 0.01% 101% 101% 0.06% -0.03% -0.01% 100% 101% 0.02% -0.01% 0.00% 100% 101%
CE6-1.1c JVET-M0496 0.26% 0.03% 0.04% 102% 101% 0.12% 0.04% 0.06% 100% 101% 0.05% 0.06% 0.07% 99% 101%
CE6-1.1d JVET-M0496 0.28% 0.04% 0.04% 99% 100% 0.13% 0.05% 0.06% 100% 100% 0.05% 0.08% 0.06% 100% 102%
CE6-1.1e JVET-M0084 0.41% 0.20% 0.20% 101% 101% 0.11% 0.05% 0.08% 100% 100% 0.04% 0.03% 0.03% 100% 100%
CE6-1.2a JVET-M0200
CE6-1.3a JVET-M0244 0.20% 0.17% 0.18% 99% 100%
CE6-1.3b JVET-M0244 0.21% 0.18% 0.18% 99% 99%
CE6-1.4a JVET-M0538 0.03% 0.04% 0.05% 87% 101% 0.01% 0.04% 0.04% 95% 104% 0.00% 0.01% 0.01% 91% 102%
CE6-1.4b JVET-M0538 0.03% 0.04% 0.05% 87% 102% 0.01% 0.04% 0.05% 95% 105% 0.00% 0.01% 0.01% 91% 101%
CE6-1.4c JVET-M0538 0.13% 0.18% 0.18% 85% 100% 0.05% 0.09% 0.10% 94% 103% 0.02% 0.05% 0.04% 90% 101%
CE6-1.4d JVET-M0538 0.13% 0.18% 0.18% 85% 101% 0.05% 0.09% 0.09% 95% 104% 0.02% 0.04% 0.03% 90% 101%
CE6-1.5a JVET-M0080 0.05% 0.07% 0.07% 98% 100% 0.02% 0.08% 0.07% 99% 100%
CE6-1.5b JVET-M0080 0.05% 0.07% 0.07% 99% 100% 0.02% 0.07% 0.06% 100% 100%
CE6-1.5c JVET-M0080 0.23% 0.28% 0.28% 96% 100% 0.10% 0.16% 0.19% 99% 100%
CE6-1.5d JVET-M0080 0.23% 0.28% 0.28% 97% 100% 0.10% 0.16% 0.19% 99% 100%
CE6-1.6a JVET-M0521 0.00% -0.06% -0.06% 94% 97% 0.00% -0.02% -0.01% 99% 105% -0.01% 0.00% -0.01% 96% 102%
CE6-1.6b JVET-M0521
CE6-1.6c JVET-M0521
Page: 118 Date Saved: 2019-03-172019-03-14

 Coding efficiency
o Replacing 4-pt DST-7/DCT-8 by DST-4/DCT4
 CE6-1.1a/b, CE6-1.6a/b/c
o Enabling 64-length MTS
 CE6-1.4 b/d
 CE6-1.5 b/d
 Simplification
o Memory reduction
 CE6-1.1 c/e
 CE6-1.2 a
 CE6-1.3 a/b
 CE6-1.4 a/c, CE6-1.5 a/c
o Complexity (operation) reduction
 CE6-1.1 d
 CE6-1.3 b
 CE6-1.4 a/c, CE6-1.5a/c
Variant 1.6c tried also replacing the 8-pt and 16-pt in addition to the 4-pt and showed worse performance
than the anchor. Variants 1.1b and 1.6b tried also replacing the 8-pt in addition to the 4-pt and did not
perform as well as only replacing the 4-pt. It was suggested to focus on the “a” variants of 1.1 and 1.6.
Variants 1.1a and 1.6a are actually the same as each other, only replacing the 4-pt DST-7/DCT-8 by DST-
4/DCT4; there is a little gain, but it is small (0.06% in RA, 0.17% in AI, mostly for lower resolutions). It
was commented that introducing a design inconsistency was undesirable. It was remarked that the DST-4
and DCT4 are subsets of the 8-point DCT2, which could save some memory (16 bytes) if implemented to
take advantage of that. In terms of the amount of computation, there is no difference – it’s just a matter of
what numbers are used in a matrix multiply.
A complexity reduction proposal, 1.1e, proposes replacing all sizes (8, 16, and 32 as well as 4). It has a
loss of 0.23% for AI, 0.16% for RA (more loss on class A: 0.6% for AI and 0.2-0.3% for RA). Its
complexity benefit is reducing storage for the smaller block sizes since the matrix elements for the DST4
and DCT4 of smaller block sizes become subsets of those of larger block sizes of a DCT2. The
implementation is a matrix multiply, so it does not affect cycle counts. The loss for that was considered
excessive.
In Track A, it was initially planned to adopt 1.1a/1.6a, pending review of other things in CE6. It was later
agreed in the plenary on Sunday 13 January not to take this action (see the notes in section 10.1).
[Copy in the short descriptions]

For considering 64-point transform, two basic approaches, 6-1.4 and 6-1.5, are proposed. For the decoder,
to approximate an inverse DST7/DCT8:
 6-1.4 uses an 8x8 “adjustment” transformation followed by a clipping and an inverse DCT2
 6-1.5 use a forward DCT2 followed by a sparse matrix
Page: 119 Date Saved: 2019-03-172019-03-14

For each of these, four sub-variants are tested:
a) The scheme is applied for 32 length (and MTS is not used for 64-length)
b) The scheme is applied for 32 and 64 lengths
c) The scheme is applied for 16 length and 32 length (and MTS is not used for 64-length)
d) The scheme is applied for 16, 32, and 64 lengths.
The number computations for the worst was reported to be cut approximately in half by 6-1.4 for the
cases where the scheme is applied. In the VTM, the worst case is reportedly the length-32 MTS
transform.
A participant commented that these increase the number of sequential stages in a way that is undesirable
for latency (esp. in hardware). Another participant said it should be possible to “hide” the extra latency
for 6-1.4 in the decoder but maybe not for 6-1.5. On the other hand, encoding latency may more of an
issue for 6-1.4 (in hardware). It was asked to allow some time for study to consider that issue.
A participant commented that applying this technique to 16 length is not necessary because 32-length
DCT2 also needs to be supported and a subset of the 32 point logic that can be used for the 16 point
transform (at least for hardware – perhaps there could be an average benefit for software). Based on this
understanding, it was suggested to focus on the “a” and “b” variants.
For the CTC, the “a” variant had roughly no effect on coding efficiency, but a little bit of loss was
measured in the low QP case (although the loss is very small ~0.05%). In the discussion it was
commented that there is some problem in the software that can cause prohibited “zero-out” coefficient
positions to be coded (although very rarely – just once for an entire test sequence). A contributor
commented that the loss was not observed if RDOQ is disabled.
A participant said that on some well-known sequences (SteamLocomotive and Nebuta) losses up to 1%
were observed at ordinary QP values when the 16 point transform was done using this scheme.
For the “b” variants in CTC testing, 6-1.4b showed a little bit of gain (CTC: 0.1% for AI , 0.1% for RA
0.0% for LB) from enabling the longer transform, but 6-1.5b basically did not (on average). A proponent
suggested to focus on class A, which is where a longer transform would seem to be more helpful (0.2%
for AI , 0.2% for RA).
After discussion, it was discovered that “6-1.4” was some new proposal that was not really part of the CE.
That specific scheme had not been documented in the CE plan. It was expressed that the latency issue
would need significant time for detailed study.
For schemes targeting memory reduction, up to about 2.7 kbytes of ROM were reported to potentially be
saved by each of the following schemes.
 CE6-1.1 c/e (previously discussed)
 CE6-1.2 a
 CE6-1.3 a/b
 CE6-1.4 a/c (non-CE)
 CE6-1.5 a/c
Except for CE6-1.5, these change the DCT2 so it is not quite a DCT2 anymore.
A loss for low QP in the range of 0.2-0.4% was reported for most of these – not for 6-1.5.
It was commented that implementations might not really have as much ROM savings is appears to be
possible, and that the ability to reuse HEVC logic is a nice property of the current VTM.
CE6-1.5 had a cascading of stages (discussed above) that seemed to have a latency issue.
No action was taken after considering these issues.
Page: 120 Date Saved: 2019-03-172019-03-14

Next category is CE6.2 fast transforms for DST7/DST8 (the DCT is not proposed to be modified).
Test # Docs Description Tester Cross-
checker
6-2.1a JVET- Fast DST-7/DCT-8 based on DFT M. Koo P. Philippe
M0288 Simplification of transform kernel coefficients, intermediate (LGE) (Orange,
variables, operations, etc. bcom)
Implementation-friendly architecture based on regular matrix
multiply
6-2.2a JVET- JVET-L0421: Fast DST-7/DCT-8 based on DFT and matrix K. Naser H. Gao
M0372 multiplication (Technicolor (Huawei)
)
6-2.3a JVET- JVET-L0286: Fast DST-7/DCT-8 with dual implementation X. Zhao K. Choi
M0497 support (Tencent) (Samsung)
6-1.4a JVET- See above description
6-1.4c M0538 See above description
6-1.5a JVET- See above description
6-1.5c M0080 See above description
The following table summarizes the results for CE6-2 using CTC configuration and VTM-3.0 as anchor.
AI RA LB
CE6-2.1a JVET-M0288 0.00% 0.02% 0.00% 96% 90% -0.01% 0.01% 0.07% 99% 98% 0.02% 0.26% -0.06% 100% 99%
CE6-2.2a JVET-M0372 0.08% 0.05% 0.04% 118% 112% 0.01% 0.07% 0.12% 116% 105% 0.04% 0.22% -0.17% 101% 100%
CE6-2.3a JVET-M0497 0.01% -0.01% 0.01% 96% 91% -0.01% -0.03% -0.02% 100% 100% 0.00% 0.22% -0.22% 99% 101%
The following table summarizes the results for CE6-2 using low QP configuration and VTM-3.0 as
anchor.
AI RA LB
CE6-2.1a JVET-M0288 0.08% 0.08% 0.09% 98% 99%
CE6-2.2a JVET-M0372
CE6-2.3a JVET-M0497 0.02% 0.00% 0.00% 98% 99% 0.01% 0.00% 0.01% 99% 99% 0.00% -0.01% 0.00% 100% 100%
The following table summarizes the results for CE6-2 using CTC w/ Inter MTS configuration and VTM-
3.0 as anchor.
AI RA LB
CE6-2.1a JVET-M0288 0.00% 0.02% 0.00% 96% 90% -0.01% -0.03% 0.03% 97% 98% 0.01% 0.11% -0.19% 97% 96%
CE6-2.2a JVET-M0372 0.08% 0.05% 0.04% 118% 112% 0.03% 0.00% 0.12% 0.07% 0.13% -0.18%
CE6-2.3a JVET-M0497 0.01% -0.01% 0.01% 96% 91% 0.00% -0.04% -0.04% 98% 100% 0.00% 0.18% -0.37% 97% 97%
Some test results were missing.

The reported runtimes were said to not reflect true differences in complexity; rather, they just reflect
implementation-specific code optimizations.
6-2.1a and 6-2.2a were said to be very similar.
6-2.3a had identical results with a matrix multiply. It also had no significant penalty in coding efficiency.
Page: 121 Date Saved: 2019-03-172019-03-14

A participant remarked that if a scheme requires cascading multiple stages to get the correct result, this
would be undesirable, since the fastest implementation in hardware may typically use parallel-processing
matrix multiply.
The 6-2.3a scheme would not provide a benefit for some implementations, but would not be worse to
implement in any implementations, and would be desirable for some implementations.
From a spec perspective, 6-2.3a is just changing the value of some numbers in the spec by +/-1.
Decision (complexity reduction): Adopt CE6-2.3a.
In the plenary discussion of Sunday 13 January, it was noted that in the AI configuration, this provides a
reported 9% speed-up for the decoder, 4% for the encoder (as tested) – see section 10.1.
Then MTS signalling and selection

CE6.3: Transform signalling
checker
6-3.1a Shape adaptive transform selection (up to 32-point DST-7) J. Lainema H. Egilmez
JVET- (Nokia) (Qualcomm)
6-3.1b M0303 Shape adaptive transform selection (up to 16-point DST-7) J. Lainema H. Egilmez
(Nokia) (Qualcomm)
6-3.2a Applying MTS to smaller side in case of Nx64 and 64xN) for H. Egilmez J. Lainema
N < 64, where max. MTS size is set to 32 by default (Qualcomm) (Nokia)
6-3.2b JVET- Applying MTS for MxN in a way that DCT2 is used for M, N H. Egilmez X. Zhao
M0522 > 16, and MTS is applied for M, N <= 16 (Qualcomm) (Tencent)
6-3.2c MTS with max. MTS size is set to 16 H. Egilmez J. Lainema
(Qualcomm) (Nokia)
6-3.3a For 64xN and Nx64 luma transform blocks (N < 64), MTS J. Jung A. Karabutov
can be applied to the shorter side. (Wilus) (Huawei)
JVET-
6-3.3b For 64xN and Nx64 luma transform blocks (N<64), MTS can J. Jung A. Karabutov
M0319
be applied to the shorter side, with the increased max_BT and (Wilus) (Huawei)
max_TT sizes for I-slices to 64.
6-3.7a JVET- MTS size restriction to 16 P. Philippe X. Zhao
M0079 (Orange) (Tencent)
6-3.8a Signal horizontal transform if width is less than or equal to J. Jung P. Philippe
16-point and height is less than or equal to 32, and signal (Wilus) (Orange)
vertical transform if height is less than or equal to 16-point X. Zhao
JVET- and and width is less than or equal to 32 (Tencent)
6-3.8b M0498 Signal horizontal transform if width is less than or equal to J. Jung P. Philippe
16-point and height is less than or equal to 64, and signal (Wilus) (Orange)
vertical transform if height is less than or equal to 16-point X. Zhao
and and width is less than or equal to 64 (Tencent)
Page: 122 Date Saved: 2019-03-172019-03-14

AI RA LB
CE6-3.1a JVET-M0303 -0.08% 0.02% 0.00% 99% 102% -0.03% 0.01% 0.07% 101% 103% 0.02% 0.37% 0.24% 100% 99%
CE6-3.1b JVET-M0303 -0.06% -0.02% -0.08% 100% 99% -0.03% 0.05% 0.02% 100% 101% 0.02% 0.18% -0.01% 99% 99%
CE6-3.2a JVET-M0522 0.00% 0.00% 0.00% 99% 99% -0.04% -0.09% -0.16% 99% 98% 0.02% -0.02% 0.10% 101% 99%
CE6-3.2b JVET-M0522 0.33% 0.40% 0.38% 92% 93% 0.18% 0.39% 0.48% 97% 99% 0.07% 0.27% 0.19% 99% 99%
CE6-3.2c JVET-M0522 0.55% 0.62% 0.63% 86% 92% 0.32% 0.62% 0.68% 95% 99% 0.12% 0.49% 0.16% 98% 99%
CE6-3.3a JVET-M0319 0.00% 0.00% 0.00% 100% 100% -0.04% -0.09% -0.16% 101% 100% 0.02% -0.02% 0.10% 100% 100%
CE6-3.3b JVET-M0319 -0.65% -1.51% -1.56% 154% 100% -0.18% -0.66% -0.71% 103% 100% 0.00% -0.48% -0.57% 101% 100%
CE6-3.7a JVET-M0079 0.55% 0.62% 0.63% 86% 87% 0.32% 0.62% 0.68% 95% 98% 0.12% 0.49% 0.16% 98% 99%
CE6-3.8a JVET-M0498 0.33% 0.40% 0.38% 91% 92% 0.18% 0.39% 0.48% 98% 99% 0.07% 0.27% 0.19% 99% 100%
CE6-3.8b JVET-M0498 0.33% 0.40% 0.38% 91% 93% 0.17% 0.29% 0.43% 99% 99% 0.06% 0.29% 0.22% 99% 100%
The following table summarizes the results for CE6-3.1 using CTC w/ MTS = 0 configuration for both
test and the VTM-3.0 anchor.
AI RA LB
CE6-3.1a JVET-M0303 -1.66% -2.31% -2.28% 99% 119% -0.75% -0.87% -0.96% 100% 108% -0.09% -0.18% -0.33% 99% 102%
CE6-3.1b JVET-M0303 -1.61% -2.11% -2.12% 101% 111% -0.71% -0.81% -0.84% 100% 102% -0.14% -0.02% -0.33% 100% 100%
6-3.1 is motivated by improving coding efficiency (esp. for the case with MTS off). The others in this
category are to reduce the maximum MTS transform size (eliminating the 32-point transform).
6-3.1 provides substantial coding gain for when MTS is disabled.
When MTS is disabled or when it is enabled but the low-level MTS flag is 0:
 The CE6-3.1b variant always uses DCT2 when the length of the transform is 32 (or 64).
 The CE6-31.a variant uses 2 transforms of length 32 (but only DCT for length 64).
When the low-level MTS flag is 1, the current 4 combinations are selectable (including for length 32)
Decision: Adopt CE6-3.1b, but with an extra high-level flag to use DCT2 always.
See also the notes of the further discussion of this topic in the plenary of Sunday 13 January in section
10.1.
CE6-3.2b/c, CE6-3.7a, CE6-3.8a/b limit the maximum non-DCT2 transform size to 16. All of these have a loss of
more than 0.5% for AI in Class A, which seems unacceptable, so no action was taken on these.
CE6-3.2a, CE6-3.3a/b, use transform type signalling only on one side when one side is length 32 or
smaller but the other side 64 long. If both sides are small, signalling is used in both dimensions. The gain
for these is approximately negligible (no gain for AI since that case cannot occur, 0.04% in RA when
compared to the current MTS, 0.03% benefit in LB when compared to the current MTS) and the encoder
runtime is increased by the consideration of these additional cases. So no action was taken on these.
(CE6-3.8a/b also has some usage of signalling for only one direction, but is motivated by trying to
eliminate the long non-DCT2 transforms, as discussed above – it has some compression loss.)
CE6-3.3b has gain from two changes: 1) increasing the maximum BT/TT size for I pictures from 32x32
to 64x64, and 2) the signalling scheme from CE6-3.3a. One of these is just an encoder configuration
setting. The encoding runtime increased by 54% for AI, with a coding efficiency benefit of 0.65%. The
benefit reported for the second modification when using the first modification as an anchor was
Page: 123 Date Saved: 2019-03-172019-03-14
reportedly 0.08% for AI. Since this affects only a case we chose not to use in CTC and provides only a
small benefit, no action was taken on that.
CE6.4: Sub-block transform:
checker
6-4.1a Sub-block Transform (SBT) for inter blocks Y. Zhao X. Zhao
- 1-d split (symmetric or 1/4) (Huawei) (Tencent)
- if symmetric, signal which half; others use the 1/4
- transform type of residual TU inferred
6-4.1b Sub-block Transform (SBT) for inter blocks Y. Zhao C.-M. Tsai
- transform type of residual TU always DCT-2 (Huawei) (MediaTek)
6-4.1c Sub-block Transform (SBT) for inter blocks Y. Zhao K. Choi
- transform type of residual TU signalled (two transform (Huawei) (Samsung)
JVET-M0140 candidates each TU)
6-4.1d Sub-block Transform (SBT) for inter blocks Y. Zhao M. Ikeda
- transform type of residual TU signalled (four transform (Huawei) (Sony)
candidates each TU, like inter MTS but with more
complex context modeling)
6-4.1e Sub-block Transform (SBT) for inter blocks Y. Zhao X. Zhao
- splits of 6-4.1a are allowed, plus (Huawei) (Tencent)
- with Quad-tree split (max TU depth still 1)
- transform type of residual TU inferred
6-4.2a RQT-like concept of transform sub-block splitting Qualcomm Y. Zhao
JVET-M0523
 One 4-way QT split (Huawei)
6-4.3a RQT-like concept of transform sub-block splitting X. Zhao Y. Zhao
 Square blocks have one 4-way QT split (Tencent) (Huawei)
JVET-M0499
 Rectangular blocks have one long-dimension binary
split
6-4.4a RQT-like concept of transform sub-block splitting Y. Zhao H. Egilmez
JVET-M0141  4 choices – binary or ternary split (horizontally or (Huawei) (Qualcomm)
vertically)
Two approaches to sub-block transform:

 Only one sub-block has non-zero coefficients:
o CE6-4.1a/b/c/d/e
 Each sub-block can have coefficients, with RQT-like scheme
o CE6-4.2a
o CE6-4.3a
o CE6-4.4a
These are all targeting higher coding gain and most are only applicable with inter prediction. Less coding
gain is observed when inter-MTS is enabled.
It was suggested to focus on the inter-MTS reference case.
Among the 4.1a/b/c/d/e variations, we would rule out b as not performing so well, and rule out c and d as
requiring signalling that doesn’t provide much benefit and adds encoder search complexity and increases
decoder support combinations. Variation e is a superset of variation a, adding a 4-way split that provides a
small additional gain (0.06% in RA when MTS is enabled).
It was remarked that the length 32 non-DCT2 transform is a problem, and the 4.1a/e schemes are using
that transform. It was requested to run a variation where the 32-point DST is not used for 32x64 and
64x32, which are cases not supported in the current VTM and are difficult cases. It was expected that this
Page: 124 Date Saved: 2019-03-172019-03-14

restriction would have a very small impact. The proponent said they could run a test of that. Revisit for
test results on that. [Resolved per notes elsewhere]
The 6-4.4a scheme has 4 choices to make within the sub-block transform mode. The 6-4.2a and 6-4.3a
schemes have no choices needed by the encoder and no syntax for such choices.
4.1a/e, 6-4.3a and 6-4.4a are splitting both luma and chroma together, while 6-4.2a is applying the
scheme only to luma.
6-4.3a is applying the scheme to intra CUs and the others are not.
Some data was missing for 6-4.3a.
It was commented that 4.1a had been studied quite a bit. It was in a CfP response and has been tested in
two CE meeting cycles.
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.
It was also agreed to not have another CE study of sub-block transform schemes for the next meeting
cycle.
AI RA LB
CE6-4.1a JVET-M0140 -0.47% -0.16% 0.00% 108% 101% -0.83% -0.98% -0.06% 113% 102%
CE6-4.1b JVET-M0140 -0.25% -0.16% -0.07% 107% 101% -0.42% -0.89% -0.04% 111% 101%
CE6-4.1c JVET-M0140 -0.54% -0.20% 0.08% 110% 101% -0.94% -0.75% 0.23% 116% 102%
CE6-4.1d JVET-M0140 -0.52% -0.10% 0.14% 114% 101% -0.90% -0.70% 0.25% 121% 102%
CE6-4.1e JVET-M0140 -0.55% -0.26% 0.00% 109% 101% -0.93% -0.91% 0.07% 115% 102%
CE6-4.2a JVET-M0523 -0.36% 0.09% 0.35% 122% 102% -0.59% -0.65% 0.47% 129% 101%
CE6-4.2a +JVET-M0523 -0.62% 0.61% 0.80% 146% 105% -0.94% 0.68% 1.41% 161% 107%
InterMTS
CE6-4.3a JVET-M0499 -0.29% -0.16% -0.17% 192% 107% -0.42% -0.30% -0.10% 143% 103% -0.45% -0.64% -0.01% 142% 104%
CE6-4.4a JVET-M0141 -0.59% -0.35% 0.10% 120% 102% -1.01% -1.77% -0.19% 127% 103%
3.0 as anchor.
AI RA LB
CE6-4.1a JVET-M0140 -0.28% -0.21% -0.06% 98% 101% -0.43% -0.72% -0.26% 96% 100%
CE6-4.1b JVET-M0140 -0.12% -0.15% -0.06% 97% 101% -0.20% -0.67% -0.21% 95% 101%
CE6-4.1c JVET-M0140 -0.33% -0.25% 0.03% 100% 100% -0.53% -0.88% -0.28% 98% 101%
CE6-4.1d JVET-M0140 -0.29% -0.14% 0.03% 103% 100% -0.47% -0.64% -0.06% 102% 100%
CE6-4.1e JVET-M0140 -0.34% -0.23% -0.06% 99% 101% -0.55% -0.73% -0.21% 97% 101%
CE6-4.2a JVET-M0523 -0.25% 0.06% 0.24% 120% 103% -0.40% -0.23% 0.31% 124% 101%
CE6-4.3a JVET-M0499
CE6-4.4a JVET-M0141 -0.30% -0.29% 0.01% 107% 101% -0.52% -1.32% -0.54% 105% 102%
Page: 125 Date Saved: 2019-03-172019-03-14

CE6.5: Secondary transform
Test # Docs Description Tester Cross-checker
6-5.1 Reduced Secondary Transform (RST) M. Koo P. Philippe
(LGE) (Orange, bcom)
JVET- - Searching best configurations of RST parameters, such as
M0292 the number of transform kernels, transform set, and matrix
dimension.
- RST index signalling optimization
In JVET-M0292, test results of CE 6-5.1 on reduced secondary transform (RST) are reported. According
to the request of the previous 12th JVET meeting, all tests were performed without normative change of
MTS signalling, which are described as the following:
1) Test 1: (A),
2) Test 2: (A) + (B),
3) Test 3: (A) + (B) + (C),
4) Test 4: (A) + (B) + (D), where
Feature Description
(A) 4 transform sets (instead of 35). 2 transforms per set
(B) Secondary transform uses at most maximum 8 multiplications/sample
(C) Secondary transform is disabled for 4x4 TU
(D) 16x48 matrices are employed instead of 16x64 ones
The transform set is determined from the intra prediction mode, then a syntax flag is sent to select which
kernel in that set is to be applied. The “secondary” (inverse) transform is applied first in the decoding
process and then the ordinary (inverse) transform is applied.
AI RA LB
CE6-5.1 JVET-M0292 -1.59% -2.75% -3.22% 128% 98% -0.88% -1.88% -2.27% 108% 100% -0.24% -0.83% -1.19% 104% 101%
(Test 1)
CE6-5.1 JVET-M0292 -1.40% -2.60% -3.09% 128% 97% -0.76% -1.83% -2.25% 108% 100% -0.21% -0.78% -0.85% 104% 98%
(Test 2)
CE6-5.1 JVET-M0292 -1.25% -2.48% -2.88% 125% 97% -0.69% -1.59% -2.03% 107% 100% -0.18% -0.68% -1.11% 103% 100%
(Test 3)
CE6-5.1 JVET-M0292 -1.34% -2.50% -2.95% 129% 97% -0.71% -1.60% -2.02% 107% 100% -0.18% -0.35% -1.00% 104% 99%
(Test 4)
3.0 as anchor.
AI RA LB
CE6-5.1 JVET-M0292 -0.91% -1.94% -2.34% 106% 100% -0.29% -0.84% -1.37% 103% 100%
(Test 1)
CE6-5.1 JVET-M0292 -0.80% -1.89% -2.27% 106% 99% -0.24% -0.66% -1.21% 103% 98%
(Test 2)
CE6-5.1 JVET-M0292 -0.74% -1.61% -2.03% 105% 99% -0.22% -0.64% -1.21% 102% 100%
(Test 3)
CE6-5.1 JVET-M0292
(Test 4)
A cross-checker said the gains are about the same regardless of the test sequence class. Chroma gain as
well as luma gain was observed.
Page: 126 Date Saved: 2019-03-172019-03-14

The scheme is only applied to intra.
Encoder complexity is increased due to checking both selectable transforms.
It was commented that the encoder runtime tradeoff looks reasonable.
This has some table storage requirement (about 10 kbytes) and a multi-stage latency (but not in the
critical path of latency).
The A and B aspects had been tested before.
It was commented that the CE plan did not describe a specific scheme to be tested – a substantial amount
of specific design aspects and details were not in the description (the values to be used in the matrices and
other aspects).
At the previous meeting it had been suggested to
 Reduce the table size (5 kbytes and 10 kbytes had previously been proposed, where the 5 kbyte
scheme had only one candidate secondary transform in each “set” rather than two to choose from);
the current proposal has 10 kbytes or with variant D has 7.6 kbytes.
 Reduce the number samples to process with the secondary transform – e.g., applying the secondary
transform to only a minimally small subset of the coefficients of the primary transform. In the tested
scheme the maximum input vector size is 16 coefficients.
It was remarked that since other changes to the transform have been made, there could be interactions.
It was also remarked that the AI encoding runtime impact is high ~28% and other encoding runtime
increases have been adopted, so this could result in an excessive speed impact.
This was further discussed 1545 in Track A on Thursday 17 Jan.The JVET-M0292 document had been
updated to include more details and spec text. Further study in a CE was requested.
JVET-M0079 CE6: MTS size restriction to 16 (test 3.7) [P. Philippe (bcom Orange)]
JVET-M0080 CE6: MTS simplification with TAF (tests 1.5a-d) [P. Philippe (bcom
Orange)]
JVET-M0084 CE6: JVET-L0262: Replacing all DST-7 / DCT-8 by DST-4 / DCT-4 used in
MTS (test 6.1.1e) [K. Abe, T. Toma (Panasonic), M. Ikeda, T. Tsukuba
(Sony), K. Naser, F. Le Léannec, E. François (Technicolor)]
JVET-M0140 CE6: Sub-block transform for inter blocks (Test 6.4.1) [Y. Zhao, H. Gao,
JVET-M0141 CE6: RQT-like sub-block transform for inter blocks (Test 6.4.4) [Y. Zhao,
H. Gao, H. Yang, J. Chen (Huawei)]
Page: 127 Date Saved: 2019-03-172019-03-14

JVET-M0200 CE6: Unified matrix for transform (Test 6-1.2a) [K. Choi, M. Park,
M. W. Park, W. Choi (Samsung)]
JVET-M0244 CE6: MTS using DST-4 and transposed DCT-2 (test 6-1.3) [Y. Lin, J. Zheng,
Q. Yu, N. Zhang (HiSilicon), C. Zhu (UESTC)]
JVET-M0288 CE6-2.1: Fast DST-7/DCT-8 based on DFT [M. Koo, M. Salehifar, J. Lim,

S. Kim (LGE)]
JVET-M0292 CE6-5.1: Reduced Secondary Transform (RST) [M. Koo, M. Salehifar,

J. Lim, S. Kim (LGE)]
JVET-M0303 CE6: Shape adaptive transform selection (Test 3.1) [J. Lainema (Nokia)]
JVET-M0319 CE6: MTS for non-square CUs (test 6.3.3) [J. Jung, D. Kim, G. Ko, J. Son,
J. Kwak (Wilus)]
JVET-M0372 CE6-2.2: Fast DST-7/DCT-8 based on DFT and matrix multiplication

[K. Naser, E. François, F. Le Léannec (Technicolor)]
JVET-M0496 CE6: Compound Orthonormal Transform (Test 6.1.1 a/b/c/d) [X. Zhao,

JVET-M0497 CE6: Fast DST-7/DCT-8 with dual implementation support (Test 6.2.3)
[X. Zhao, X. Li, Y. Luo, S. Liu (Tencent)]
JVET-M0498 CE6: MTS up to 16-length (Test 6.3.8) [J. Jung, D. Kim, G. Ko, J.-H. Son,
J. S. Kwak (Wilus), X. Zhao, X. Li, S. Liu (Tencent)]
JVET-M0499 CE6: RQT-like transform sub-block splitting (Test 6.4.3) [X. Zhao, X. Li,
S. Liu (Tencent)]
JVET-M0521 CE6: Replacement of 4-point DST7/DCT8 with DST4/DCT4 in MTS (Test

6.1.6) [H. Egilmez, V. Seregin, A. Said, T. Hsieh, M. Karczewicz
(Qualcomm)]
Page: 128 Date Saved: 2019-03-172019-03-14

JVET-M0522 CE6: MTS support for large rectangular blocks (Test 6.3.2) [H. Egilmez,
V. Seregin, A. Said, M. Karczewicz (Qualcomm)]
JVET-M0523 CE6: RQT-like transform partitioning for inter blocks (Test 6.4.2)
[H. Egilmez, V. Seregin, A. Said, M. Karczewicz (Qualcomm)]
5.7 CE7: Quantization and coefficient coding (2)

Contributions in this category were discussed Saturday 12 Jan. 1500–XXXX (chaired by GJS).
JVET-M0027 CE7: Summary report on quantization and coefficient coding [H. Schwarz,

M. Coban, C. Auyeng]
The CE report summarizes the test results and crosschecks reports for CE7 on quantization and
coefficient coding. The CE includes 4 tests on transform coefficient coding.
The purpose of this core experiment is to explore the coding efficiency and complexity impact of
proposed algorithms for quantization and transform coefficient coding. This core experiment evaluates
the impact of:
Context modeling/selection/coding order for syntax elements related to transform coefficients
The objectives of this CE include:
Investigation of the impact of context selection and signalling schemes for transform coefficient levels on
the coding efficiency and complexity.
Transform coefficient coding

Tester Tool Cross checker
7.1 Tzu-Der Chuang [1] Constraints on the number of context-coded bins Yu-Chen Sun
(MediaTek) depend on whether luma or chroma is coded (and, for (Alibaba)
chroma, on the subblock size)
7.2 Tzu-Der Chuang [1] Constraints on the number of context-coded bins Jung-Ah Choi (LGE)
(MediaTek) depend on whether luma or chroma is coded (and, for M. Coban (Qualcomm)
+
[2] Constraints on the number of context-coded bins
depend on last significant scan position
7.3 Tzu-Der Chuang [1] Constraints on the number of context-coded bins H. Schwarz (HHI)
(MediaTek) depend on whether luma or chroma is coded (and, for M. Coban (Qualcomm)
+
[2] Constraints on the number of context-coded bins
depend on last significant scan position
+
[3] Include rem_abs_gt2_flag into first coding pass
7.4 Tzu-Der Chuang [3] Include rem_abs_gt2_flag into first coding pass H. Schwarz (HHI)
(MediaTek)
In JVET-L0145, three methods to constrain the usage of context-coded bins are proposed. The first
constraint is dependent on color component and coefficient sub-block size. The second method is to
release the constraints values according to the last significant sub-block position to improve the coding
efficiency. The third modification is to move the greater than 2 flag into the first pass to further improve
the decoding throughput. The details are described as follows.
Page: 129 Date Saved: 2019-03-172019-03-14

[1] Different constraints according to colour components and sub-block sizes
The number of context-coded bins (including greater than 2 flag) constraints are set to 30 on 4x4 luma
subblocks, 16 on 4x4 chroma subblocks, and 4 on 2x2 chroma subblocks, respectively. The number of
context-coded bin constraints on greater than 2 are set to 4 on 4x4 luma subblocks, 2 on 4x4 chroma
subblocks, and 1 on 2x2 chroma sub-blocks, respectively.
[2] Last significant subblock position dependent constraint

According to the last significant subblock position, the number of to-be-coded sub-blocks in a TB can be
derived. The constraint value is determined according to the color component and the coefficient sub-
block size. With the number of to-be-coded sub-blocks (NumToBeCodedSb) and the number of total
coefficient sub-blocks in a TB (NumTotalSb), the constraint value (ConstraintValue) is modified as
follows.
(if (NumToBeCodedSb * 2 <= NumTotalSb)
( (ConstraintValue = ConstraintValue * 2;
(else if (NumToBeCodedSb * 5 <= NumTotalSb * 4)
( (ConstraintValue = (ConstraintValue * 5) >> 2;
[3] Include greater than 2 flag into the first coding pass
The greater than 2 flag is proposed to be moved to the first coding pass after the parity bit. The parsed
greater than 2 flag is used to calculate the locSumAbsPass1in the context modeling of sig_coeff_flag,
par_level_flag, rem_abs_gt1_flag, and rem_abs_gt2_flag. The reserved number of context-coded bins for
greater than 2 flag in the second coding pass is also merged into the number of context-coded bins for the
first coding pass. The test that moving the greater than 2 flag before parity bit will also be evaluated.
Specification of tests:
Test 7.1: Aspect [1] ( (To reduce worst-case context coded bins (2 per coeff to ~1.6)
Test 7.2: Aspects [1] + [2] ( (Improving coding efficiency relative to 7.1
Test 7.3: Aspects [1] + [2] + [3] (Reduces the scan passes relative to 7.2
Test 7.4: Aspect [3] ( (Reduces the scan passes without including other changes
Average test results for CE 7. The table shows results for a high-complexity encoder configurations (same
as CTC) as well as a low-complexity encoder configuration (dependent quantization and RDOQ
disabled). All results are relative to VTM-3.0 (using the same configuration as the tested approach).
Page: 130 Date Saved: 2019-03-172019-03-14

High complexity (CTC) Low complexity (DQ off, RDOQ off)
CE 7
Y U V encT decT Y U V encT decT
7.1 0.08% 0.64% 0.44% 102% 101% 0.12% 0.42% 0.47% 100% 101%
7.2 0.06% 0.19% 0.10% 104% 102% 0.06% 0.12% 0.14% 100% 102%
AI
7.3 0.00% 0.09% 0.05% 103% 101% 0.00% 0.03% 0.11% 99% 101%
7.4 -0.08% -0.09% -0.10% 100% 101% -0.05% -0.08% -0.08% 99% 101%
7.1 0.07% 0.87% 0.69% 101% 100% 0.09% 0.45% 0.58% 100% 102%
7.2 0.03% 0.35% 0.30% 101% 101% 0.03% 0.15% 0.22% 100% 102%
RA
7.3 0.00% 0.30% 0.23% 101% 102% 0.02% 0.14% 0.17% 100% 102%
7.4 -0.06% 0.03% -0.06% 100% 100% -0.02% -0.12% -0.02% 100% 102%
7.1 0.09% 1.58% 0.89% 101% 102% -0.02% 1.03% 0.66% 100% 100%
7.2 0.00% 0.57% 0.14% 102% 101% -0.01% 0.40% 0.13% 100% 99%
LB
7.3 0.02% 0.58% -0.12% 101% 100% -0.01% 0.50% 0.09% 100% 99%
7.4 -0.04% 0.00% 0.12% 100% 100% 0.02% -0.15% -0.09% 100% 99%
For test 7.1, there is clear loss, and especially in Class A.

It was asked whether this had been tested with low QPs. It had not.
The current scheme imposes this limit by counting the number of context coded bins in a coefficient
group and switching to bypass when a limit is exceeded.
It was commented that limiting the context coded bins at this very low level – the 4x4 level, may not be
desirable – that imposing such a limit at a higher level may be better. However, it was commented by
others that HEVC has a similar counting and switching requirement.
Aspect number [3] (test CE7.4), which reduces scan passes, was suggested to be “cleaner” and should
increase throughput.
Decision (complexity reduction): Adopt CE7.4.
There was interest in further work for reducing the worst-case number of context-coded bins, but the
currently tested methods may not be the right approach for that.
A suggestion for the further study was to establish a limit at some higher level rather than on each
coefficient group. It was recommended to study the matter of the worst-case number of context-coded
bins in an AHG.
JVET-M0173 CE7 (Tests 7.1, 7.2, 7.3, and 7.4): Constraints on context-coded bins for
coefficient coding [T.-D. Chuang, S.-T. Hsiang, Z.-Y. Lin, C.-Y. Chen, Y.-W.
5.8 CE8: Screen content coding tools (15)

Contributions in this category were discussed Friday 11 Jan. 1120–1330 and 1500-1615 (Track B chaired
by JRO).
JVET-M0028 CE8: Summary Report on Screen Content Coding [X. Xu, Y.-C. Chao, Y.-C.
Sun, J. Xu]
Subtests:
8.1: CPR related
8.2: Palette related
8.3: Block-based DPCM
Page: 131 Date Saved: 2019-03-172019-03-14

Test Tester Document Tool description Cross
checker
8.1.1a J. Nam JVET-M0332 Block vector prediction for merge mode and X. Xu
(LGE) AMVP mode using default positions. (Tencent)
8.1.1b J. Nam JVET-M0332 Block vector prediction for merge mode and A.
(LGE) AMVP mode. Consider alternative candidates with Karabutov
various positions (Huawei)
8.1.2a X. Xu JVET-M0407 Reference sample memory reuse, update reference A.

(Tencent) sample memory on 64x64 basis, keep the Karabutov
requirement for total memory (4 64x64 blocks) (Huawei)
unchanged
8.1.2b X. Xu JVET-M0408 Reference sample memory reuse, update reference J. Nam

(Tencent) sample memory on 64x64 basis, reduce the (LGE)
requirement for total memory to 3 64x64 blocks
8.1.2c X. Xu JVET-M0408 Reference sample memory reuse, update reference J. Nam

(Tencent) sample memory on 64x64 basis, reduce the (LGE)
requirement for total memory to 2 64x64 blocks
8.1.2d X. Xu JVET-M0407 Reference sample memory reuse, update reference A.

(Tencent) sample memory on CU basis, keep the requirement Karabutov
for total memory (4 64x64 blocks) unchanged (Huawei)
8.1.3 L. P. Van JVET-M0474 CPR using extended search range with line buffers
(Qualcomm) from top of CTU and the left columns of the
current CTU
8.2.1 Y.-H. Chao JVET-M0050 Palette mode as in HEVC SCC, CE base software R.
(Qualcomm) Chernyak
Y.-C. Sun (Huawei)
(Alibaba)
8.2.2 Y.-C. Sun JVET-M0051 Palette mode and intra mode combination Y.-W. Chen
(Alibaba) (Kwai)
8.2.3 J. Ye JVET-M0455 Palette index map scan order constraints R.

(Tencent) Chernyak
(Huawei)
8.2.4 J. Ye JVET-M0456 Apply palette mode on separate chroma CU only Y.-C. Sun
(Tencent) when corresponding luma samples are all coded in (Alibaba)
palette mode
8.2.5a R. Chernyak JVET-M0052 Separate palette coding for luma and chroma J. Ye
(Huawei) Sub test 1: palette coding is applied separately on (Tencent)
Y.-H. Chao luma and chroma components in both intra and
(Qualcomm) inter slices when dual tree is disabled in
Y.-C. Sun configuration (SPS)
(Alibaba)
8.2.5b R. Chernyak JVET-M0052 Separate palette coding for luma and chroma J. Ye
(Huawei) Sub test 2: palette coding is applied separately on (Tencent)
Y.-H. Chao luma and chroma components in both intra and
(Qualcomm) inter slices when dual tree is enabled in
Y.-C. Sun configuration (SPS)
(Alibaba)
8.2.6 J. Ye JVET-M0457 Palette predictor list enhancement by using palette Y.-C. Sun
Page: 132 Date Saved: 2019-03-172019-03-14

(Tencent) coded spatial neighbours (Alibaba)
8.3.1a F. Henry JVET-M0056 BDPCM with throughput reduction, investigating: B. Bross

(Orange) - Block size limitation of BDPCM and impact on (HHI)
throughput
- Independently decodable regions inside BDPCM
block (in a manner similar to RDPCM throughput
reduction proposed in JCT-VC- M0439 [16]) and
impact on throughput
8.3.1b F. Henry JVET-M0057 Same as 8.3.1a with vertical and horizontal B. Bross
(Orange) predictors (in a way similar to RDPCM), allowing (HHI)
the reconstruction to proceed line by line / column
by column and thus increase throughput
8.3.2 F. Henry JVET-M0058 BDPCM bin/context reduction B. Bross

(Orange) - Use different approaches to encode the BDPCM (HHI)
residual in order to reduce the number of bins and
associated contexts
Results compared to CTC (without CPR), all CE results have CPR enabled
AI RA
VTM+CPR -0.27% -0.40% -0.33% 137% 100% 0.09% -0.01% 0.05% 100% 100%
CE8.1.1a -0.34% -0.43% -0.41% 144% 104% 0.05% -0.06% 0.00% 101% 101%
CE8.1.1b -0.34% -0.41% -0.37% 144% 104% 0.05% 0.00% 0.05% 101% 102%
CE8.1.2a -0.35% -0.46% -0.42% 142% 102% 0.05% -0.04% -0.03% 100% 99%
CE8.1.2b -0.31% -0.41% -0.35% 143% 98% 0.07% -0.04% 0.04% 99% 98%
CE8.1.2c -0.22% -0.30% -0.30% 139% 100% 0.11% -0.07% 0.08% 99% 99%
CE8.1.2d -0.39% -0.48% -0.48% 143% 99% 0.05% 0.01% 0.02% 99% 99%
CE8.1.3 -0.29% -0.37% -0.34% 137% 103% 0.08% 0.01% 0.02% 100% 100%
CE8.2.1 -0.19% -0.26% -0.26% 146% 105% 0.20% 0.07% 0.20% 108% 104%
CTC
CE8.2.1* -0.36% -0.65% -0.81% 142% 100% 0.16% -0.30% -0.22% 107% 102%
overall
CE8.2.2 -0.19% -0.24% -0.26% 147% 105% 0.22% 0.07% 0.18% 106% 103%
CE8.2.3 -0.19% -0.26% -0.25% 142% 104% 0.20% 0.05% 0.15% 100% 99%
CE8.2.4 -0.21% -0.30% -0.26% 141% 105% 0.20% 0.10% 0.22% 101% 99%
CE8.2.5a -0.36% -0.63% -0.81% 142% 100% 0.15% -0.32% -0.24% 106% 101%
CE8.2.5b -0.19% -0.26% -0.26% 146% 105% 0.20% 0.05% 0.13% 105% 103%
CE8.2.6 -0.19% -0.27% -0.26% 143% 104% 0.20% 0.08% 0.18% 101% 100%
CE8.3.1a -0.24% -0.42% -0.36% 134% 104% 0.11% 0.03% 0.09% 101% 102%
CE8.3.1b -0.34% -0.37% -0.32% 137% 106% 0.07% -0.01% 0.09% 102% 102%
CE8.3.2 -0.34% -0.37% -0.33% 137% 106% 0.07% -0.01% 0.08% 102% 102%
Class F VTM+CPR -12.09% -12.04% -12.10% 158% 99% -9.89% -9.92% -9.95% 107% 99%
CE8.1.1a -12.42% -12.24% -12.27% 161% 104% -10.10% -9.99% -10.12% 108% 102%
CE8.1.1b -12.41% -12.37% -12.34% 162% 106% -10.07% -9.94% -10.16% 108% 102%
CE8.1.2a -14.47% -14.32% -14.26% 175% 103% -11.62% -11.63% -11.49% 109% 98%
CE8.1.2b -13.66% -13.52% -13.49% 172% 97% -11.04% -11.05% -11.07% 109% 97%
CE8.1.2c -12.11% -12.04% -11.94% 164% 97% -9.88% -9.89% -10.04% 108% 98%
CE8.1.2d -15.34% -15.20% -15.15% 178% 96% -12.34% -12.28% -12.22% 109% 97%
CE8.1.3 -12.21% -12.14% -12.19% 159% 104% -9.96% -10.10% -9.99% 106% 101%
CE8.2.1 -15.51% -14.05% -14.13% 174% 97% -11.90% -11.77% -11.99% 119% 103%
CE8.2.1* -13.16% -13.63% -13.62% 159% 96% -10.48% -11.17% -11.20% 118% 102%
CE8.2.2 -15.53% -14.03% -14.11% 174% 97% -11.94% -11.72% -11.94% 119% 103%
CE8.2.3 -15.50% -14.03% -14.09% 173% 100% -11.90% -11.72% -11.92% 110% 98%
Page: 133 Date Saved: 2019-03-172019-03-14

CE8.2.4 -15.62% -13.29% -13.31% 169% 99% -12.03% -11.00% -11.12% 110% 98%
CE8.2.5a -14.59% -14.28% -14.61% 167% 93% -11.43% -11.08% -11.70% 118% 99%
CE8.2.5b -15.51% -14.05% -14.13% 174% 97% -11.97% -11.64% -11.89% 118% 104%
CE8.2.6 -15.49% -13.98% -14.09% 175% 100% -11.87% -11.53% -11.90% 110% 99%
CE8.3.1a -13.09% -13.59% -13.60% 136% 103% -10.41% -10.92% -10.98% 109% 101%
CE8.3.1b -15.75% -14.12% -14.14% 139% 106% -12.48% -11.27% -11.42% 111% 102%
CE8.3.2 -15.68% -14.05% -14.06% 139% 106% -12.43% -11.30% -11.34% 110% 102%
VTM+CPR -36.92% -36.11% -36.36% 143% 90% -22.03% -21.58% -22.10% 103% 96%
CE8.1.1a -37.81% -36.76% -37.03% 139% 102% -22.77% -22.27% -22.78% 104% 100%
CE8.1.1b -37.80% -36.76% -37.03% 138% 101% -22.69% -22.18% -22.73% 104% 100%
CE8.1.2a -42.96% -41.68% -41.99% 147% 90% -25.89% -25.17% -25.82% 103% 95%
CE8.1.2b -41.02% -39.81% -40.12% 151% 86% -24.55% -23.96% -24.54% 104% 94%
CE8.1.2c -36.76% -35.55% -35.83% 150% 89% -21.43% -20.80% -21.35% 105% 94%
CE8.1.2d -45.00% -43.77% -44.06% 151% 85% -27.25% -26.61% -27.20% 103% 94%
CE8.1.3 -37.14% -36.32% -36.57% 144% 97% -22.17% -21.75% -22.27% 105% 100%
CE8.2.1 -44.77% -41.06% -41.27% 157% 75% -25.67% -24.47% -24.82% 110% 96%
SCC
CE8.2.1* -39.08% -38.45% -38.66% 149% 80% -22.67% -22.57% -22.80% 107% 93%
1080p
CE8.2.2 -45.18% -41.22% -41.45% 155% 76% -26.03% -24.68% -25.04% 110% 95%
CE8.2.3 -44.75% -41.03% -41.26% 156% 77% -25.64% -24.50% -24.80% 102% 90%
CE8.2.4 -44.78% -41.04% -41.26% 158% 80% -25.65% -24.40% -24.77% 102% 91%
CE8.2.5a -41.75% -40.55% -40.56% 157% 70% -24.88% -24.46% -24.44% 106% 91%
CE8.2.5b -44.77% -41.06% -41.27% 157% 75% -26.03% -24.75% -24.95% 108% 95%
CE8.2.6 -44.78% -41.04% -41.26% 158% 80% -25.65% -24.40% -24.77% 102% 91%
CE8.3.1a -38.67% -38.38% -38.57% 104% 94% -23.03% -22.87% -23.29% 105% 98%
CE8.3.1b -42.26% -39.36% -39.70% 107% 101% -25.50% -23.29% -23.84% 106% 99%
CE8.3.2 -41.97% -39.22% -39.55% 107% 102% -25.45% -23.27% -23.78% 104% 99%
* PLT mode in HEVC SCC, when dual-tree SPS is off (the baseline version of CE 8.2.1 uses dual tree)
Results compared to CTC (without CPR), all CE results have CPR+PLT enabled
AI Over RA
VTM- Over

3.0 VTM-
3.0
AI RA
VTM+CPR -0.19% -0.26% -0.26% 145% 103% 0.20% 0.07% 0.20% 105% 102%
+PLT
CE8.1.1a -0.25% -0.32% -0.36% 151% 104% 0.17% 0.06% 0.05% 106% 102%
CE8.1.1b -0.24% -0.30% -0.30% 151% 105% 0.18% 0.09% 0.04% 105% 101%
CE8.1.2a -0.26% -0.33% -0.37% 149% 101% 0.19% 0.11% 0.17% 104% 99%
CE8.1.2b -0.22% -0.31% -0.30% 152% 104% 0.21% 0.05% 0.15% 106% 102%
CE8.1.2c -0.14% -0.19% -0.21% 150% 105% 0.23% 0.07% 0.17% 106% 102%
CE8.1.2d -0.30% -0.37% -0.38% 152% 105% 0.18% 0.08% 0.12% 105% 102%
CE8.1.3 -0.19% -0.31% -0.25% 144% 103% 0.21% 0.05% 0.16% 104% 100%
CTC
CE8.2.1 -0.19% -0.26% -0.26% 146% 105% 0.20% 0.07% 0.20% 108% 104%
overall
CE8.2.2 -0.19% -0.24% -0.26% 147% 105% 0.22% 0.07% 0.18% 106% 103%
CE8.2.3 -0.19% -0.26% -0.25% 142% 104% 0.20% 0.05% 0.15% 100% 99%
CE8.2.4 -0.21% -0.30% -0.26% 141% 105% 0.20% 0.10% 0.22% 101% 99%
CE8.2.5a -0.36% -0.63% -0.81% 142% 100% 0.15% -0.32% -0.24% 106% 101%
CE8.2.5b -0.19% -0.26% -0.26% 146% 105% 0.20% 0.05% 0.13% 105% 103%
CE8.2.6 -0.19% -0.27% -0.26% 143% 104% 0.20% 0.08% 0.18% 101% 100%
CE8.3.1a -0.16% -0.30% -0.32% 170% 116% 0.24% 0.07% 0.17% 141% 122%
CE8.3.1b -0.27% -0.29% -0.24% 141% 109% 0.18% 0.14% 0.24% 104% 105%
CE8.3.2 -0.27% -0.28% -0.24% 141% 109% 0.18% 0.15% 0.26% 105% 106%
Page: 134 Date Saved: 2019-03-172019-03-14

VTM+CPR -15.51% -14.05% -14.13% 173% 97% -11.90% -11.77% -11.99% 115% 100%
+PLT
CE8.1.1a -15.61% -14.25% -14.33% 176% 97% -12.01% -11.77% -12.05% 116% 100%
CE8.1.1b -15.62% -14.18% -14.25% 176% 98% -12.02% -11.78% -11.95% 116% 100%
CE8.1.2a -16.95% -15.79% -15.92% 182% 95% -13.09% -13.00% -13.18% 115% 97%
CE8.1.2b -16.44% -15.15% -15.25% 185% 99% -12.66% -12.51% -12.73% 118% 101%
CE8.1.2c -15.29% -13.87% -13.97% 179% 97% -11.79% -11.59% -11.76% 117% 100%
CE8.1.2d -17.71% -16.58% -16.68% 191% 100% -13.66% -13.50% -13.75% 118% 101%
CE8.1.3 -15.57% -14.12% -14.27% 171% 96% -12.00% -11.84% -12.07% 112% 97%
Class F CE8.2.1 -15.51% -14.05% -14.13% 174% 97% -11.90% -11.77% -11.99% 119% 103%
CE8.2.2 -15.53% -14.03% -14.11% 174% 97% -11.94% -11.72% -11.94% 119% 103%
CE8.2.3 -15.50% -14.03% -14.09% 173% 100% -11.90% -11.72% -11.92% 110% 98%
CE8.2.4 -15.62% -13.29% -13.31% 169% 99% -12.03% -11.00% -11.12% 110% 98%
CE8.2.5a -14.59% -14.28% -14.61% 167% 93% -11.43% -11.08% -11.70% 118% 99%
CE8.2.5b -15.51% -14.05% -14.13% 174% 97% -11.97% -11.64% -11.89% 118% 104%
CE8.2.6 -15.49% -13.98% -14.09% 175% 100% -11.87% -11.53% -11.90% 110% 99%
CE8.3.1a -15.81% -14.80% -14.98% 175% 113% -12.12% -11.98% -12.30% 147% 119%
CE8.3.1b -16.81% -15.47% -15.63% 143% 104% -12.95% -12.24% -12.56% 113% 104%
CE8.3.2 -16.80% -15.44% -15.62% 143% 105% -12.93% -12.26% -12.57% 114% 105%
VTM+CPR -44.77% -41.06% -41.27% 158% 77% -25.67% -24.49% -24.84% 106% 93%
+PLT
CE8.1.1a -45.08% -41.40% -41.60% 155% 80% -26.14% -24.92% -25.30% 108% 95%
CE8.1.1b -45.09% -41.40% -41.61% 155% 80% -26.12% -24.91% -25.30% 108% 95%
CE8.1.2a -48.16% -44.73% -44.97% 156% 75% -28.04% -26.75% -27.18% 104% 91%
CE8.1.2b -46.92% -43.43% -43.67% 164% 79% -27.13% -25.86% -26.32% 107% 94%
CE8.1.2c -43.87% -40.16% -40.35% 164% 77% -24.73% -23.54% -23.90% 109% 94%
CE8.1.2d -49.80% -46.50% -46.74% 159% 78% -29.13% -27.90% -28.39% 106% 93%
SCC CE8.1.3 -44.89% -41.21% -41.42% 157% 77% -25.74% -24.58% -24.94% 107% 95%
1080p CE8.2.1 -44.77% -41.06% -41.27% 157% 75% -25.67% -24.47% -24.82% 110% 96%
CE8.2.2 -45.18% -41.22% -41.45% 155% 76% -26.03% -24.68% -25.04% 110% 95%
CE8.2.3 -44.75% -41.03% -41.26% 156% 77% -25.64% -24.50% -24.80% 102% 90%
CE8.2.4 -45.03% -40.16% -40.41% 158% 82% -25.77% -23.77% -24.18% 102% 91%
CE8.2.5a -41.75% -40.55% -40.56% 157% 70% -24.88% -24.46% -24.44% 106% 91%
CE8.2.5b -44.77% -41.06% -41.27% 157% 75% -26.03% -24.75% -24.95% 108% 95%
CE8.2.6 -44.78% -41.04% -41.26% 158% 80% -25.65% -24.40% -24.77% 102% 91%
CE8.3.1a -45.25% -42.15% -42.34% 130% 93% -24.20% -23.13% -23.45% 133% 111%
CE8.3.1b -46.17% -42.67% -42.88% 106% 89% -25.31% -23.46% -23.88% 104% 102%
CE8.3.2 -46.16% -42.65% -42.86% 106% 90% -25.30% -23.48% -23.88% 105% 99%
Results compared to CTC (without CPR), all CE results have PLT enabled
AI Over RA
VTM- Over

3.0 VTM-
3.0
AI RA
CTC VTM+PLT 0.09% 0.10% 0.06% 107% 101% 0.14% 0.20% 0.09% 106% 102%
overall CE8.2.1 0.09% 0.10% 0.06% 107% 101% 0.14% 0.20% 0.09% 106% 102%
CE8.2.1* 0.07% 0.07% 0.01% 108% 101% 0.14% 0.09% 0.08% 106% 101%
CE8.2.2 0.08% 0.09% 0.11% 108% 103% 0.14% 0.18% 0.10% 106% 102%
CE8.2.3 0.08% 0.10% 0.07% 106% 101% 0.12% 0.17% 0.13% 100% 98%
CE8.2.4 0.06% 0.07% 0.05% 106% 102% 0.13% 0.16% 0.10% 100% 98%
CE8.2.5a 0.07% 0.09% 0.03% 104% 98% 0.13% 0.08% 0.10% 104% 99%
Page: 135 Date Saved: 2019-03-172019-03-14

CE8.2.5b 0.09% 0.10% 0.06% 111% 105% 0.11% 0.18% 0.12% 105% 101%
CE8.2.6 0.09% 0.10% 0.06% 106% 101% 0.13% 0.20% 0.11% 100% 98%
VTM+PLT -11.43% -8.94% -9.04% 117% 89% -8.52% -8.02% -8.31% 110% 101%
CE8.2.1 -11.43% -8.94% -9.04% 117% 89% -8.52% -8.02% -8.31% 110% 101%
CE8.2.1* -5.55% -6.57% -7.23% 114% 95% -3.89% -5.15% -5.83% 111% 102%
CE8.2.2 -11.65% -9.08% -9.19% 118% 91% -8.80% -8.28% -8.66% 110% 101%
Class F CE8.2.3 -11.41% -8.92% -8.98% 118% 93% -8.47% -8.06% -8.26% 103% 95%
CE8.2.4 -11.50% -8.30% -8.35% 117% 93% -8.56% -7.60% -7.78% 102% 95%
CE8.2.5a -9.75% -9.29% -10.06% 113% 86% -7.51% -7.08% -8.08% 107% 96%
CE8.2.5b -11.43% -8.94% -9.04% 121% 94% -8.65% -7.95% -8.32% 110% 102%
CE8.2.6 -11.43% -8.83% -8.89% 116% 92% -8.54% -8.01% -8.25% 102% 95%
VTM+PLT -33.06% -27.59% -27.70% 131% 68% -15.71% -14.68% -14.53% 106% 93%
CE8.2.1 -33.06% -27.59% -27.70% 131% 68% -15.71% -14.68% -14.53% 106% 93%
CE8.2.1* -17.97% -18.43% -18.73% 122% 81% -9.03% -10.12% -10.01% 106% 96%
CE8.2.2 -34.47% -28.70% -28.82% 122% 70% -16.56% -15.23% -15.12% 105% 94%
SCC
CE8.2.3 -33.03% -27.60% -27.66% 126% 67% -15.73% -14.64% -14.50% 99% 87%
1080p
CE8.2.4 -33.15% -26.95% -27.08% 127% 69% -15.77% -14.33% -14.23% 99% 88%
CE8.2.5a -27.02% -26.01% -25.52% 126% 62% -14.78% -15.28% -14.62% 102% 88%
CE8.2.5b -33.06% -27.59% -27.70% 135% 69% -16.64% -15.24% -15.02% 108% 94%
CE8.2.6 -33.13% -27.64% -27.75% 128% 71% -15.73% -14.59% -14.50% 99% 89%
8.1.x
The following question is discussed: Should CTC enable CPR for class F? This would be realistic for the
case where the encoder could know that it is screen content or natural content.
The methods of CE8.1.2 provide additional gain of >3% for class F, 8% for TGM class. These are re-
using existing data from the previous CTU (assuming 2 or 4 buffers of size 64x64 each, depending on
version). This is generally agreed to be practical and give good benefit. It could however be coplicated to
specify as an encoder/bitstream restriction that the limits of CPR vectors are valid.
Shan Liu and other interested experts were asked to inspect the specification text (all 4 versions a…d),
and it was reported back that version a was the most practical solution.
Decision: Adopt JVET-M0407 (variant a).
The methods of CE8.1.1 provide additional gain (0.4% class F, 0.9% for class TGM), but modify AMVP
and merge list construction. Question is raised whether VVC would require to use exactly the same
principle for CPR and normal MV coding. Probably this might be OK if it does not deviate too much, and
does not require much additional processing. In HEVC SCC, it was required to have exactly the same
process for CPR and MV coding, which may not be the case for VVC.
See the notes of further discussion in the JVET Sunday plenary about general design limitations we
would impose on CPR vector coding
8.1.3 uses the line/columns buffers at CTU boundary (which is there for intra prediction) to enable CPR
by one line/column more across CTU boundary. Gives 0.1% for class F, 0.2% for TGM. Probably, part of
that gain (as far as the left boundary is concerned) is overlapping with 8.1.2.
A combination on top of 8.1.2.d was reported in JVET-M0878. It seemed that the additional benefit was
very small, so no action was taken on it.
8.2.x
Current VVC does not include palette mode, however a kind of “baseline” exists which is HEVC palette
plus dual tree. This provides roughly 3%/7.5% gain over VVC+CPR for classes F/TGM. Results from CE
also indicate that this gain goes to 2.5%/4.5% when combined with the improved CPR from 8.1.2. This
may be even less when other aspects such as transform skip come into play. Such a relative low gain
might not justify adding
Page: 136 Date Saved: 2019-03-172019-03-14

See the notes of further discussion in the JVET Sunday plenary – regarding the design targets for palette,
improved compression performance may be more important than reducing complexity.
8.2.2 is a method that performs intra prediction and provides one signal in the palette that inserts the
predicted sample instead of inserting a value from the palette. Gain is very low, and does not justify the
additional complexity.
8.2.3 targets complexity reduction of (index map scan order is constrained by the block shape). Results
show minimum loss compared to 8.2.1 (CE palette basis). At the current status of palette, no urgent need
to make such changes of the basis method.
8.2.4 uses separate trees (and separate palettes for luma and chroma), but the chroma part can only use
palette mode, if the corresponding luma area entirely uses palette. The palette mode signalling is removed
for such CUs where it is not the case. This however introduces some dependency (including parsing)
which does not allow independent decoding of luma and chroma trees any more. Furthermore, the benefit
on compression is practically zero.
It is understood that the intent is to disallow cases where the luma does not use palette and the chroma
uses it. However, this could also be achieved by an encoder only decision.
8.2.5a uses one tree but allows different palettes for luma and chroma. This performs better than 8.2.1*,
which uses one tree and one palette. It however performs still worse than 8.2.1 which uses separate trees
and separate palettes for luma and chroma. This indicates that only part of the gain of 8.2.1 versus 8.2.1*
comes from the different palettes, another part comes from different partitioning.
8.2.5b is identical to 8.2.1 for intra coding, but uses same tree (but different palettes) for inter coding. For
RA this gives <0.4% in TGM; <0.1% in class F (with CPR on), With CPR off, the gain is 0.9+% (TGM)
amd 0.1+% (class F). At the current status of palette, no urgent need to make such changes of the basis
method. It provides some (small) gain, and this aspect should be further studied. There is also a CE
related proposal on this.
8.2.6 targets better compression performing by predicting the palette. This however can only be observed
for the palette only compression, and is very small (0.06% for class TGM).
8.3.x
These approaches perform sample-wise DPCM as an additional concept that demonstrates some benefit
for screen content types. The most viable approach (according to proponents) is 8.3.2 which can best be
optimized in terms of throughput and also shows best compression. The gain over VTM+CPR is
3.7%/4.9% for classes F/TGM, and gain over VTM+CPR+PLT is 1.3%/1.4%, respectively. The encoder
runtimes are significantly faster when those methods are used, as some early termination approach is
employed (not searching other intra modes when the prediction works well).
The current method uses a maximum of 12 context coded bins per sample, which is much too large.
Furthermore, this would be yet another alternative prediction method (and building block) which needs to
be implemented in parallel with existing ones, which needs some justification in terms of compression
performance to be included.
Could the residual coding be unified with the existing approach of VVC (in that case, the method could
just be seen as another intra prediction mode with transform skip)?
It is also asked how the current residual coding method would perform in the low QP range
Further study was considered necessary.
Page: 137 Date Saved: 2019-03-172019-03-14

JVET-M0050 CE8: Palette Mode in HEVC (test 8.2.1) [Y.-C. Sun, J. Lou (Alibaba), Y.-H.
Chao, H. Wang, V. Seregin, M. Karczewicz (Qualcomm)]
Palette coding as in HEVC SCC.
For dual tree enabled in SPS, palette coding is applied separately for luma tree and chorma tree in intra
slice/P slice where current picture is the only reference and jointly for luma and chroma in inter slice. For
dual tree disabled in SPS, palette coding is applied jointly for both intra and inter slice.
JVET-M0051 CE8: Palette Mode and Intra Mode Combination (test 8.2.2) [Y.-C. Sun,
J. Lou (Alibaba)]
In this test, the method combining palette mode and intra prediction is tested. The decoder first derives
the prediction block based on the intra prediction information. Then, the decoder decodes a palette and an
index map. Using the decoding palette information, the decoder refines the prediction block and
reconstructs the block.
JVET-M0052 CE8: Separate Palette Coding for Luma and Chroma (test 8.2.5) [Y.-C. Sun,
J. Lou (Alibaba), Y.-H. Chao, H. Wang, V. Seregin, M. Karczewicz
(Qualcomm), R. Chernyak, S. Ikonin, J. Chen (Huawei)]
In the palette anchor (test CE8.2.1), when dual tree is enabled in the configuration (SPS), palette coding is
applied separately on luma tree and chroma tree in intra slices and jointly on luma/chroma in inter slices.
When dual tree is disabled in the configuration, palette mode is applied jointly for both luma and chroma
in all slice types.
In this test, separated palette coding for luma/chroma components are investigated based on the same
palette coding functions in anchor software:
Sub test 1: palette coding is applied separately on luma and chroma components in both intra and inter
slices when dual tree is disabled in configuration (SPS).
Sub test 2: palette coding is applied separately on luma and chroma components in both intra and inter
slices when dual tree is enabled in configuration (SPS).
JVET-M0056 CE8: BDPCM with LOCO-I and independently decodable areas (test 8.3.1a)
[F. Henry, A. Mohsen (Orange), P. Philippe, G. Clare (B-com)]
It is contribution proposes to use a classical DPCM approach at the block level.
A bdpcm_flag is transmitted at the CU level whenever it is a luma intra CU having each dimension
smaller or equal to 32. This flag indicates whether regular intra coding or DPCM is used. This flag is
encoded using a single CABAC context.
Block DPCM uses the Median Edge Detector of LOCO-I. For a current pixel X having pixel A as left
neighbour, pixel B as top neighbour and C as top-left neighbour, the prediction P(X) is determined by
P(X)= min(A,B) if C≥max(A,B)
max(A,B) if C≤min(A,B)
A+B-C otherwise
The predictor uses unfiltered reference pixels when predicting the top row and left column of the CU. The
predictor then uses reconstructed pixels for the rest of the CU. Pixels are processed in raster-scan order
inside the CU. The prediction error is quantized in the spatial domain, after rescaling, in a way identical to
Page: 138 Date Saved: 2019-03-172019-03-14

the Transform Skip quantizer. Each pixel is reconstructed by adding the dequantized prediction error to
the prediction. Thus, the reconstructed pixels are used to predict the next pixels in raster-scan order.
Amplitude and signs of the quantized prediction error are encoded separately. A cbf_bdpcm_flag is
coded. If it is equal to 0, it indicates that all amplitudes of the block are to be decoded as zero. If the flag
is equal to 1, all amplitudes of the block are encoded individually in raster-scan order. In order to keep
complexity low, the amplitude is limited to at most 31 (inclusive). The amplitude is encoded using unary
binarization, with three contexts for the first bit, then one context for each additional bin until the 12th
bin, and one context for all remaining bins. A sign is encoded in bypass mode for each non-zero residue.
In order to maintain the coherence of the regular intra mode prediction, the first mode in the MPM list is
associated with a Block-DPCM CU (without being transmitted) and is available for MPM generation for
subsequent blocks.
The deblocking filter is de-activated on a border between two Block-DPCM blocks, since neither of the
blocks uses the transform stage usually responsible for blocking artefacts.
Block-DPCM does not use any other step than the ones described here. In particular it does not use any
transform.
JVET-M0057 CE8: BDPCM with horizontal/vertical predictor and independently

decodable areas (test 8.3.1b) [F. Henry, M. Abdoli, P. Philippe, G. Clare
(Orange)]
It is contribution proposes to use a classical DPCM approach at the block level.
A bdpcm_flag is transmitted at the CU level whenever it is a luma intra CU having each dimension
smaller or equal to 32. This flag indicates whether regular intra coding or DPCM is used. This flag is
encoded using a single CABAC context.
Block DPCM uses the Median Edge Detector of LOCO-I. For a current pixel X having pixel A as left
neighbour, pixel B as top neighbour and C as top-left neighbour, the prediction P(X) is determined by
P(X)= min(A,B) if C≥max(A,B)
max(A,B) if C≤min(A,B)
A+B-C otherwise
The predictor uses unfiltered reference pixels when predicting the top row and left column of the CU. The
predictor then uses reconstructed pixels for the rest of the CU. Pixels are processed in raster-scan order
inside the CU. The prediction error is quantized in the spatial domain, after rescaling, in a way identical to
the Transform Skip quantizer. Each pixel is reconstructed by adding the dequantized prediction error to
the prediction. Thus, the reconstructed pixels are used to predict the next pixels in raster-scan order.
Amplitude and signs of the quantized prediction error are encoded separately. A cbf_bdpcm_flag is
coded. If it is equal to 0, it indicates that all amplitudes of the block are to be decoded as zero. If the flag
is equal to 1, all amplitudes of the block are encoded individually in raster-scan order. In order to keep
complexity low, the amplitude is limited to at most 31 (inclusive). The amplitude is encoded using unary
binarization, with three contexts for the first bit, then one context for each additional bin until the 12th
bin, and one context for all remaining bins. A sign is encoded in bypass mode for each non-zero residue.
In order to maintain the coherence of the regular intra mode prediction, the first mode in the MPM list is
associated with a Block-DPCM CU (without being transmitted) and is available for MPM generation for
subsequent blocks.
The deblocking filter is de-activated on a border between two Block-DPCM blocks, since neither of the
blocks uses the transform stage usually responsible for blocking artefacts.
Block-DPCM does not use any other step than the ones described here. In particular it does not use any
transform.
Page: 139 Date Saved: 2019-03-172019-03-14

JVET-M0058 CE8: BDPCM with modified binarization (test 8.3.2) [F. Henry, M. Abdoli,
G. Clare, P. Philippe (Orange)]
In this test the BDPCM residue amplitude is limited to 28, and it is encoded with truncated unary
binarization for the first 12 bits, followed by order-2 Exp-Golomb EP bits for the remainder (using the
existing encodeRemAbsEP() function). As a basis for this test we used 8.3.1b (in order to limit the
number of configurations to crosscheck).
JVET-M0332 CE8: Block vector prediction for CPR (test 8.1.1a and test 8.1.1b) [J. Nam,
In this test, alternative candidates for CPR is proposed. It is added in both AMVP and merge mode. For
AMVP mode, when reference picture of current coding block indicated by reference index is same as
current picture and the number of candidates in the constructed list is smaller than the maximum number
of candidates, default candidates are inserted into MVP candidate list. For Merge mode, when the current
picture exists in the reference picture list and the number of candidates in the constructed list is smaller
than the maximum number of candidates, default candidates are added to merge candidate list. Various
positions for alternative candidates will be tested.
In subtest 1, (-2W, 0) and (0, -2H) are tested, where (W, H) is the size of current coding block
In subtest 2, (-mid, 0) and (0, -mid)) are tested, which is the middle positions between the CTU boundary
and current block position.
JVET-M0407 CE8: CPR reference memory reuse without increasing memory requirement
(CE8.1.2a and CE8.1.2d) [X. Xu, X. Li, S. Liu (Tencent), E. Chai (Ubilinx)]
See under JVET-M0408.
JVET-M0408 CE8: CPR reference memory reuse with reduced memory requirement
(CE8.1.2b and CE8.1.2c) [X. Xu, X. Li, S. Liu (Tencent), E. Chai (Ubilinx)]
X Curr
X X Curr
X X X X
X Curr
X X Curr
Currently, the search range of CPR mode is constrained to be within the current CTU. The effective
memory requirement to store reference samples for CPR mode is 1 CTU size of samples. Considering the
Page: 140 Date Saved: 2019-03-172019-03-14

existing reference sample memory to store reconstructed samples in current 64x64 region, 3 more 64x64
sized reference sample memory are required. Based on this fact, the proposed method in JVET-L0297
extends the effective search range of the CPR mode to some part of the left CTU while the total memory
requirement for storing reference pixels are kept unchanged (1 CTU size, 4 64x64 reference sample
memory in total). This is done by updating the stored reference samples from the left CTU to the
reconstructed samples from the current CTU:
1:) The update process is done on a 64x64 luma sample basis, for each of the four 64x64 block regions in
the CTU size memory, the reference samples in the same region from the left CTU can be used to predict
the coding block in current CTU with CPR mode until any of the blocks in the same region of the current
CTU is being coded or has been coded.
2:) Similar as in 1:), but the required reference sample memory size is reduced. For example, in addition
to the 64x64 size memory for storing reconstructed samples of the current 64x64 region, additional 2 (or
1) 64x64 size memory can be used to store previously coded regions. Therefore, the total requirement
reference sample memory is reduced from 4 64x64 size to 3 (or 2) 64x64 size.
3:) Similar as in 1:), but the update process is done on a CU basis. The reference samples in the left CTU
can be used to predict the coding block in current CTU with CPR mode until the block in the same
location of the current CTU is being coded or has been coded.
Page: 141 Date Saved: 2019-03-172019-03-14

JVET-M0455 CE8: Palette index map scan order constraints (Test 8.2.3) [J. Ye, X. Xu,
M. Xu, X. Li, S. Liu (Tencent)]
In this test, index map scan order is constraint by the block shape. it is proposed when the block height /
width ratio is greater than a threshold, only vertical traverse scan is used in the index map scan. If the
block width / height ratio is greater than or equal to a threshold, only horizontal traverse scan is used.
Different thresholds will be tested. In the CE proposal, a threshold equal to 8 is tested. For these blocks, a
scan order starting along the longer side of the block is used. For example, a 64x8 block will use
horizontal traverse scan.
JVET-M0456 CE8: palette mode when dual-tree is enabled (Test 8.2.4) [J. Ye, X. Xu, X. Li,
S. Liu (Tencent)]
In this test, palette mode with dual tree coding structure is investigated.
Sub test b: apply palette mode to luma plane when dual tree is enabled. When coding chroma plane, if the
co-located luma block are all palette mode, the chroma block are also have the flexibility to use palette
mode. A flag is signalled whether the chroma block using palette mode or not. If the chroma block using
palette mode, the corresponding palette mode syntax will be signalled.
JVET-M0457 CE8: Palette predictor list enhancement (Test 8.2.6) [J. Ye, X. Xu, M. Xu,
In this test, the palette predictor will be derived from previously palette coded coding blocks.
1. Derive the spatial palette predictor:
To derive the spatial palette predictor, the adjacent neighbouring and non-adjacent neighbouring are both
checked from the neighbouring blocks that are close to the current block to the blocks that are far away.
The left block (Ai) and above block (Bi) are checked. The non-adjacent neighbouring candidates are in a
virtual box that surrounding the current block. The virtual block size and position are illustrated in Fig.1.
In the current implementation, the gridX is block width and gridY is block height. The number of search
rounds will be tested. Pruning of palette entries will be tested. The orders for checking each candidate will
be tested.
2. Combine the spatial palette predictor and the HEVC SCC palette predictor:
After deriving the spatial palette predictor, the spatial palette predictor will be inserted into the palette
predictor list for the current block first. If the size of palette predictor list for the current block doesn’t
exceed the maximum palette predictor size, the HEVC SCC palette predictor is inserted into the palette
predictor list. If the list size exceeds the maximum palette predictor size, the rest palette entry will be
discarded. The combined palette predictor will be used to code the palette table entry of the current block.
JVET-M0474 CE8.1.3: Extended CPR reference with 1 buffer line [L. Pham Van,
V. Seregin, W.-J. Chien, T. Hsieh, M. Karczewicz (Qualcomm)]
The current CPR reference area is limited to the reconstructed samples of the current CTU. However,
neighbour samples around a CTU are required for intra prediction, that samples can be available for CPR
reference as well. In the CE, the following tests are performed:
The search range is the current CTU and 1 line above, and 1 left column to the current CTU.
Page: 142 Date Saved: 2019-03-172019-03-14

JVET-M0543 Crosscheck of JVET-M0474: CE8.1.3- Extended CPR reference with 1
buffer line [S. Paluri, S. Kim (LGE)] [late]
5.9 CE9: Decoder-side motion vector derivation (8)

Contributions in this category were discussed Thursday 10 Jan. 2030–2230 (Track B chaired by JRO).
JVET-M0029 CE9: Summary report on decoder side motion vector derivation [X. Xiu,
S. Esenlik]
The core experiment summary report is organized into 2 sub-tests as follows:
 CE9.1: BDOF design (3 tests)
 CE9.2: DMVR design (24 tests)
CE9.1: BDOF design

# Description Tester Cross-checker
9.1.1.a 1. use 8-tap DCTIF filters to generate the prediction Xiu, Xiaoyu H. Liu
samples in extended region and inside CU
2. padding for reference samples outside [w+7, h+7] for
final MC (DCTIF)
9.1.1.b 1. use integer positions to generate the prediction samples Xiu, Xiaoyu H. Liu
in extended region
2. use 8-tap DCTIF filters to generate the prediction
samples inside CU
9.1.1.c 1. apply different gradient calculation method for Xiu, Xiaoyu H. Liu
prediction samples on the CU boundaries and inside CU
2. use 8-tap DCTIF filters to generate the prediction
samples inside CU
VTM Crosscheck
VTM Cross-Check
Test Document Crosschecker Y U V EncT DecT EncT DecT
9.1.1 a JVET-M0487 H. Liu -0.01% 0.03% 0.02% 103% 102% 105% 104%
9.1.1 b H. Liu 0.05% 0.02% 0.02% 99% 98% 99% 100%
9.1.1 c H. Liu 0.10% 0.03% 0.01% 99% 98% 100% 100%
9.1.1.a does not simplify, replaces bilinear filters in extended region by DCTIF
9.1.1.b simplifies by using no interpolation in extended region (just integer positions)
9.1.1.c changes the gradient calculation at boundaries and does not need extended region any more, it
simplifies, but the design becomes less unified
Several experts supported 9.1.1.b as the best simplified design approach.
Decision: Adopt JVET-M0487 (solution 9.1.1.b)
Specification text was made available, to be confirmed to be consistent with software by cross-checkers,
and reviewed by spec editors.
CE9.2: DMVR design
Page: 143 Date Saved: 2019-03-172019-03-14

# Description Document
1. padding for reference samples outside [w+7, h+7] for final MC (DCTIF) JVET-M0147
2. use bi-linear filter to generate prediction samples [w+4, h+4] for motion (S.
refinement Sethuraman)
3a. MRSAD is used as metric for motion refinement
9.2.1 a 3b. MRSAD calculation on every other row
DMVR 4. error surface based sub-pixel refinement
base s/w 5a. DMVR early termination based on MV distance
5b. DMVR early termination based on sample difference
Block size criteria: CUs with height >= 8 and size > 64 and CUs with size <=
1024
Refined MV: MC, DBF, TMVP, spatial MV prediction from top and top-left
CTU
9.2.1 b0 CE9.2.1a + Integer DMVR, SAD, and refined MV used only for MC
CE9.2.1b0 + Enable 32x32 forced split + enable DMVR for w*h > 1024 +
9.2.1 b
Replace CU level early termination to Sub-PU level
9.2.1 c CE9.2.1b + Replace SAD with MR-SAD
9.2.1 d CE9.2.1c + Replace Integer DMVR with Bilinear MC
CE9.2.1d + use of refined MV for deblocking, TMVP and for spatial MV
9.2.1 e
prediction from top/top-left CTU neighbours
CE9.2.1e + use of refined MV also within CTU row from VPDUs that were
9.2.1 f
processed 2 VPDUs behind current VPDU
CE9.2.1f + MC restricted to use samples within (64+7)*(64+7) for VPDU of
9.2.1 f1
CUs larger than 64x64
9.2.1 g CE9.2.1e + replace sub-PU size to 16x16 from 32x32
9.2.2 c CE9.2.1g + replace MR-SAD with PR-MR-SAD JVET-M0147
CE9.2.2c + Change sub-CU level early termination threshold (3 times) to know (S.
9.2.2 d
DecT impact Sethuraman)
Results for CE9.2.2c when BDOF is disabled in both VTM3.0 and with DMVR
*9.2.2 f
+ DMVR is enabled for ATMVP and MMVD
9.2.2 f1 Disabling refined MV usage for anything other than MC in CE9.2.2c
9.2.2 f2 Replacing PR-MR-SAD with SAD in CE9.2.2c
No diagonal direction checking when all cross points' cost value not less than JVET-M0306
9.2.3 a
center point cost value (X.Chen)
9.2.3 b Down sampling for MRSAD's mean value calculation
9.2.3 c Replacing MRSAD with SAD in CE9.2.1a
9.2.4 a CE9.2.1a + allow inter reconstruction to be used as intra reference JVET-M0447
9.2.4 b CE9.2.1a + don't allow inter reconstruction to be used as intra reference (M. Xu)
9.2.4 c CE9.2.1a + don't allow DMVR reconstruction to be used as intra reference
CE9.2.1a is changed as follows: JVET-M0062
9.2.5 a minCost equal to zero replaces minCost less than (w*h*(1<<(Max(2, 14 – Bit (T. Chujoh )
Depth) + (Bit Depth-8)+0))
CE9.2.1a is changed as follows:
9.2.5 b minCost equal to zero replaces minCost less than (w*h*(1<<(Max(2, 14 – Bit
Depth) + (Bit Depth-8)-1))
9.2.6
Disable DMVR for CUs with size > 4096 (K. Unno)
9.2.7 Bilinear filter is replaced by no interpolation (rounding to nearest integer (S. Esenlik)
sample)
* Below, CE9.2.2.f result is reported compared to BDOF off anchor.
VTM
Test Description Y U V EncT DecT

9.2.1 a 1. padding for reference samples outside [w+7, h+7] -0.71% -0.81% -0.87% 110% 118%
Page: 144 Date Saved: 2019-03-172019-03-14

DMVR for final MC (DCTIF)
base s/w 2. use bi-linear filter to generate prediction samples
[w+4, h+4] for motion refinement
3a. MRSAD is used as metric for motion refinement
3b. MRSAD calculation on every other row
4. error surface based sub-pixel refinement
5a. DMVR early termination based on MV distance
5b. DMVR early termination based on sample
difference
Block size criteria: CUs with height >= 8 and size >
64 and CUs with size <= 1024
Refined MV: MC, DBF, TMVP, spatial MV
prediction from top and top-left CTU
DMVR is enabled for ATMVP and MMVD (disabled
for all other tests exceptz 9.2.3ff.)
9.2.1 b0 CE9.2.1a + Integer DMVR, SAD, and refined MV -0.30% -0.39% -0.40% 101% 103%
used only for MC
9.2.1 b CE9.2.1b0 + Enable 32x32 forced split + enable -0.58% -0.86% -0.86% 102% 106%
DMVR for w*h > 1024 + Replace CU level early
termination to Sub-PU level
9.2.1 c CE9.2.1b + Replace SAD with MR-SAD -0.66% -0.88% -0.92% 102% 108%
9.2.1 d CE9.2.1c + Replace Integer DMVR with Bilinear -0.74% -1.02% -1.07% 102% 111%
MC
9.2.1 e CE9.2.1d + use of refined MV for deblocking, TMVP -1.12% -1.25% -1.30% 103% 114%
and for spatial MV prediction from top/top-left CTU
neighbours
9.2.1 f CE9.2.1e + use of refined MV also within CTU row -1.25% -1.33% -1.43% 103% 114%
from VPDUs that were processed 2 VPDUs before
current VPDU
9.2.1 f1 CE9.2.1f + MC restricted to use samples within -1.25% -1.33% -1.42% 103% 114%
(64+7)*(64+7) for VPDU of CUs larger than 64x64
9.2.1 g CE9.2.1e + replace sub-PU size to 16x16 from 32x32 -1.13% -1.33% -1.44% 103% 118%
9.2.2 c CE9.2.1g + replace MR-SAD with PR-MR-SAD -1.07% -1.27% -1.36% 103% 118%
9.2.2 d CE9.2.2c + Change sub-CU level early termination -1.04% -1.27% -1.36% 103% 117%
threshold (3 times) to know DecT impact
*9.2.2 f Results for CE9.2.2c when BDOF is disabled in both -1.51% -1.58% -1.59% 116% 126%
VTM3.0 and with DMVR + DMVR is enabled for
ATMVP and MMVD
9.2.2 f1 Disabling refined MV usage for anything other than -0.72% -1.05% -1.11% 102% 115%
MC in CE9.2.2c
9.2.2 f2 Replacing PR-MR-SAD with SAD in CE9.2.2c -1.02% -1.29% -1.35% 103% 115%
9.2.3 a CE9.2.1a, No diagonal direction checking when all -0.71% -0.84% -0.90% 108% 116%
cross points' cost value not less than center point cost
value
9.2.3 b CE9.2.1a, Down sampling for MRSAD's mean value -0.68% -0.84% -0.89% 108% 115%
calculation
9.2.3 c CE9.2.1a, Replacing MRSAD with SAD -0.60% -0.78% -0.84% 107% 115%
9.2.4 a CE9.2.1a + allow inter reconstruction to be used as -0.71% -0.81% -0.87% 108% 115%
intra reference
9.2.4 b CE9.2.1a + don't allow inter reconstruction to be 3.87% 8.82% 9.62% 103% 113%
used as intra reference
9.2.4 c CE9.2.1a + don't allow DMVR reconstruction to be -0.46% -0.34% -0.36% 108% 115%
used as intra reference
9.2.5 a CE9.2.1a is changed as follows: -0.67% -0.80% -0.86% 109% 118%
minCost equal to zero replaces minCost less than
(w*h*(1<<(Max(2, 14 – Bit Depth) + (Bit Depth-
8)+0))
9.2.5 b CE9.2.1a is changed as follows: -0.70% -0.81% -0.87% 109% 119%
minCost equal to zero replaces minCost less than
(w*h*(1<<(Max(2, 14 – Bit Depth) + (Bit Depth-8)-
Page: 145 Date Saved: 2019-03-172019-03-14

1))
9.2.6 CE9.2.1a is changed as follows: -0.89% -0.99% -1.08% 111% 119%
Disable DMVR for CUs with size > 4096
9.2.7 CE9.2.1a is changed as follows: -0.58% -0.69% -0.74% 109% 115%
Bilinear filter is replaced by no interpolation
(rounding to nearest integer sample)
Additional results in JVET-M0147 which show results on CE9.2.1g but without using refined MV for
spatial MV prediction and deblocking: Overall -1.01%. This could be a reasonable approach avoiding
some of the dependency problems that were observed in DMVR before. It was asked for some cross-
check and specification text to be made available.
Cross check became available as JVET-M0887. Has two results: For MR-SAD and SAD. MR-SAD -
1.01%, SAD -0.92%. Results provided above are confirmed. Specification text was provided in JVET-
M0147v5, has been investigated by cross-checker and spec editor as being appropriate.
Decoding time increase is reported as 15%.
It was confirmed that the following criteria are fulfilled by the SAD version, which are agreed to be a
tradeoff between software and hardware implementation aspects:
 Early termination w/ (0,0) position SAD between list0 and list1
 Block sizes for DMVR W*H>=64 && H>=8
 Split the CU into multiple of 16x16 sub-blocks for DMVR of CU size > 16*16
 Reference block size (W+7)*(H+7) (for luma)
 25 points SAD-based integer-pel search (i.e. (+/−) 2 refinement search range, single stage)
 Bilinear-interpolation based DMVR
 MVD mirroring between list0 and list1 to allow bilateral matching
 “Parametric error surface equation” based sub-pel refinement
 Luma/chroma MC w/ reference block padding (if needed)
 Refined MVs used for MC and TMVPs only
It is further noted that the proposal contains an additional element which checks the MV difference with
regard to previous MVs in the merge list to make an early termination in DMVR. This has hardly any
impact on the BD rate, but reduces decoding time by 3%. This has however some impact on hardware
implementation, and decoding time is not overly critical.
Further reducing decoding time for software implementation (and possible optimization of code) is
desirable.
Decision: Adopt JVET-M0147 with SAD cost function, and without the MVD based early termination
check.
Note that the MVD based early termination should also not be used in upcoming CEs.
It is noted that disallowing DMVR blocks for intra prediction may not be that relevant in practical
pipeline implementations. Typically, within a CTU first all inter blocks would be reconstructed, and
finally the intra coded blocks,
Early termination approaches do not seem to be very effective in terms of runtime reduction, and also are
not beneficial for hardware.
Generally, the investigation on DMVR has led to a point where it might be manageable implementation-
wise (not low complex, but still giving around 1% gain)
Page: 146 Date Saved: 2019-03-172019-03-14

A problem of the methods investigated in the CE could still be that DMVR and BDOF could be applied
sequentially, before finally motion comp and reconstruction can be done. JVET-M0223 considers this
issue.
The next step was review of CE related contributions (there were not too many on DMVR) and the assess
whether they provide further improvement or complexity reduction.
A BoG was established (coordinated by S. Esenlik) to review the CE9 related contributions and suggest
aspects to be studied in a CE (for BIO and DMVR). See the notes for the BoG report JVET-M0858.
The subsequent notes in this section only contain abstracts copied from the documents. Actions taken are
noted above under JVET-M0029.
JVET-M0062 CE9: An early termination of DMVR (Test 9.2.5) [T. Chujoh, T. Ikai

(Sharp)]
This contribution is a report of CE9.2.5. In this contribution, a result of an early termination of DMVR
(Decoder Motion Vector Refinement) has been reported. DMVR is a method of improving coding
efficiency without explicitly sending overheads by motion vectors refinement of the merge mode on the
both encoder and decoder side. One of the tasks is to reduce the complexity of the decoder side. In this
contribution, an early termination of DMVR is improved. As experimental results, the decoding time was
reduced by 2% without additional SIMD, and the coding loss is 0.04%.
JVET-M0076 CE9: Block size restriction for DMVR (test 9.2.6) [K. Unno, K. Kawamura,
S. Naito (KDDI)]
In this contribution, it is tested that coding performances with block size restriction for decoder-side
motion vector refinement (DMVR). Threshold 4096 pixels for block size restriction is used in proposed
method. On the other hand, threshold 1024 pixels is used in CE9.2 base software (same as CE9.2.1a).
BD-rate for luma is -0.89% with threshold 4096 compared with VTM-3.0.
JVET-M0147 CE9: Results of DMVR related Tests CE9.2.1 and CE9.2.2 [S. Sethuraman
(Ittiam)]
In this proposal, the results of sub-tests CE9.2.1 and 9.2.2 are summarized. In CE9.2.1b0, a simplified
base with refinement disabled for coding units with luma sample counts larger than 1024, integer grid
samples based refinement, SAD as the cost function, and use of refined MVs for only the MC of the
current CU is considered. The progressive impact of the key elements of DMVR design such as forced
partitioning of large CUs into sub-CUs that have a constraint on their maximum width and height, type of
interpolation done for refinement, mean-removed SAD as cost function, and use of refined MVs for
purposes other than MC for current CU are studied in the other sub-tests of CE9.2.1. The results indicate
that DMVR can provide average BDRATE gains of up to -1.13%, -1.33%, -1.44% over VTM3 for the
combination of (a) sub-CUs of maximum width and height of 16 luma samples, (b) bilinear interpolation
for refinement, (c) block mean removed SAD as cost function, and (d) use of refined MVs for de-
blocking, temporal MV prediction, and spatial MV prediction from top and top-left CTU neighbours. The
average encoding and decoding time ratios have increased to up to 103% and 118% respectively due to
performing motion compensation and BDOF at sub-CU granularity. The results also indicate that use of
refined MVs for purposes other than MC provides more than one-third of the coding gain offered by
DMVR.
In CE9.2.2, an alternative cost function that replaces block level mean removed SAD cost function with a
row-level mean removed SAD cost function is studied at two different sub-PU level early exit thresholds.
The results indicate that half of the BDRATE gain provided by block-level MR-SAD over SAD can be
achieved using row-level mean removed SAD cost function. Further study may be required to study
Page: 147 Date Saved: 2019-03-172019-03-14
variants of such cost functions and suitable early exit thresholds that can provide a larger reduction in
average decoding time increase at minimal impact to the coding gains. One result is also provided when
BIO is disabled to show an average BDRATE gain of -1.51%, -1.58%, -1.59% over VTM3 with BIO
disabled.
Complexity analysis for aspects such as pre-fetch cache accesses, internal memory requirements, and
worst-case operation count are provided for the various choices. The analysis results indicate that sub-
CUs of maximum width and height of 16 luma samples provide the least internal memory requirements
while not increasing the pre-fetch cache accesses in the worst-case. The average luma BDRATE drop for
SAD as a cost function when compared to MR-SAD as the cost function is seen to be only ~0.11%.
JVET-M0887 Crosscheck of additional tests in JVET-M0147 (CE9: Results of DMVR

related Tests CE9.2.1 and CE9.2.2) [T. Chujoh, T. Ikai (Sharp)] [late]
JVET-M0287 CE9: Integer DMVR (Test 9.2.7) [S. Esenlik, H. Gao, A. M. Kotra, B. Wang,
J. Chen (Huawei)]
This contribution document reports the results of the core experiment CE9.2.7. In the test the initial
motion vectors are rounded to integer precision before the application of motion vector refinement in
order to reduce the computational complexity of DMVR. The test CE9.2.7 is designed to show the impact
of the application of rounding of the initial motion vectors to integer precision in isolation. Therefore the
proposed method is implemented on top of the DMVR Base Software (CE9.2.Base) and no other
modification is included in the test.
Simulation results show 0.13% luma BD-rate increase and 5% decoding time reduction compared to the
DMVR Base Software.
JVET-M0306 CE9: DMVR Simplifications (Test 9.2.3) [X. Chen, J. Zheng (HiSilicon)]

This contribution presents DMVR simplifications based on VTM3.0. Firstly, only 4 integer precision
surround check for certain condition, followed by MRSAD mean value calculation by sampling process,
then use SAD calculation to replace MRSAD. The proposed technologies have 0.71%/ 0.68%, 0.60%
gain respectively compared to VTM3.0 anchor.
JVET-M0447 CE9: Constrained intra prediction with DMVR (test 9.2.4) [M. Xu, X. Li,
S. Liu (Tencent)]
This contribution presents DMVR simplifications based on VTM3.0. Firstly, only 4 integer precision
surround check for certain condition, followed by MRSAD mean value calculation by sampling process,
then use SAD calculation to replace MRSAD. The proposed technologies have 0.71%/ 0.68%, 0.60%
gain respectively compared to VTM3.0 anchor.
JVET-M0487 CE9: Simplifications on bi-directional optical flow (BDOF) (test 9.1.1)

[X. Xiu, Y. He (InterDigital), C.-Y. Lai, Y.-C. Su, T.-D. Chuang, C.-Y. Chen,
Y.-W. Huang, S.-M. Lei (MediaTek)]
This document reports the results of Core Experiment (CE) 9.1 on simplifications on bi-directional optical
flow (BDOF). In this CE test, three solutionvariations are tested to reduce the BDOF computational
complexity by reducing or skipping the interpolation of prediction samples in the extended region of one
Page: 148 Date Saved: 2019-03-172019-03-14

BDOF CU. Compared to VTM-3.0 anchor, the performance of the proposed BDOF solutionvariations are
summarized as follows:
SolutionVariation one: {Y, U, V} BD-rates {-0.01%, 0.03%, 0.02%}, EncT=103%, DecT=102%
SolutionVariation two: {Y, U, V} BD-rates {0.05%, 0.02%, 0.02%}, EncT=99%, DecT=98%
SolutionVariation three: {Y, U, V} BD-rates {0.10%, 0.03%, 0.01%}, EncT=99%, DecT=98%
5.10 CE10: Combined and multi-hypothesis prediction (15)

Contributions in this category were discussed Saturday 12 Jan. 1100–1345 and 1515-1815 (Track B
chaired by JRO).
JVET-M0030 CE10: Summary report on combined and multi-hypothesis prediction [C.-W.

Hsu, M. Winken]
Five sub CEs are created to test different methods of combined predictions, including:
 CE10.1: multi-hypothesis prediction,
 CE10.2: overlapped block motion compensation,
 CE10.3: multiple shape prediction partitions,
 CE10.4: diffusion filtering of inter- and intra-prediction signals,
 CE10.5: local illumination compensation.
There are 13, 4, 1, 2 and 2 tests for each sub CE, respectively.
CE proposals are listed as follows,

Proposal Corresponding Author(s) Title
Document # tTests
JVET-M0176 CE10.1.1 M.-S. Chiang, C.- CE10.1.1: Multi-hypothesis prediction for
W. Hsu, Y.-W. improving non-skip & non-merge inter mode and
Huang, S.-M. Lei merge mode
(MediaTek)
JVET-M0425 CE10.1.2 M. Winken, H. CE10: Multi-hypothesis inter prediction (Test
Schwarz, D. 10.1.2)
Marpe, T.
Wiegand (HHI)
JVET-M0290 CE10.1.3 W. Xu, B. CE10: Simplification on Combined Inter-Intra
Wang, H. Yang, Prediction (Test 10.1.3)
J. Chen (Huawei)
JVET-M0177 CE10.1.4 M.-S. Chiang, C.- CE10.1.4: Simplification of combined inter and
W. Hsu, Y.-W. intra prediction
Huang, S.-M. Lei
(MediaTek)
JVET-M0293 CE10.1.5 W. Xu, B. CE10: Simplification on Combined Inter-Intra
Wang, H. Yang, Prediction with size restriction (Test 10.1.5)
J. Chen
(Huawei), M.-S.
Chiang, C.-W.
Hsu, Y.-W.
Huang, S.-M. Lei
(MediaTek)
JVET-M0178 CE10.2.1 Z.-Y. Lin, T.-D. CE10.2.1: Uni-prediction-based CU-boundary-
Page: 149 Date Saved: 2019-03-172019-03-14

Chuang, C.-Y. only OBMC
Chen, C.-W. Hsu,
C.-C. Chen, Y.-C.
Lin, Y.-W.
Huang, S.-M. Lei
(MediaTek), X.
Xiu, Y. He
(InterDigital)
JVET-M0179 CE10.2.2 Z.-Y. Lin, T.-D. CE10.2.2: Integer-MV-based CU-boundary-only
Chuang, C.-Y. OBMC
Chen, C.-W. Hsu,
C.-C. Chen, Y.-C.
Lin, Y.-W.
Huang, S.-M. Lei
(MediaTek), X.
Xiu, Y. He
(InterDigital)
JVET-M0180 CE10.2.3 Y.-C. Lin, C.-C. CE10.2.3: Subblock OBMC with uni-prediction-
Chen, C.-W. Hsu, based OBMC at CU boundaries
Z.-Y. Lin, T.-D.
Chuang, C.-Y.
Chen, Y.-W.
Huang, S.-M. Lei
(MediaTek)
JVET-M0181 CE10.2.4 Y.-C. Lin, C.-C. CE10.2.4: Subblock OBMC with integer-MV-
Chen, C.-W. Hsu, based OBMC at CU boundaries
Z.-Y. Lin, T.-D.
Chuang, C.-Y.
Chen, Y.-W.
Huang, S.-M. Lei
(MediaTek)
JVET-M0189 CE10.3.1 Y. Ahn, D. Sim CE10.3.1: AMVP mode for triangle prediction
(Digital Insights)
JVET-M0042 CE10.4.1 J. Rasch, A. CE10: Uniform Directional Diffusion Filters For
CE10.4.2 Henkel, J. Pfaff,H. Video Coding
Schwarz, D.
Marpe, T.
Wiegand (HHI)
JVET-M0087 CE10.5.2 K. Abe, T. CE10: Low pipeline latency LIC (test 10.5.2)
Toma,J. Li
(Panasonic)
JVET-M0112 CE10.5.3 P. Bordes, T. CE10: LIC confined within current CTU (test
Poirier, F. 10.5.3)
LeLeannec
(Technicolor)
CE10.1: Multi-hypothesis prediction

# Supported Signalling # of Block BW Hypothesis Reference Color
modes of additional constraint reduction inheritance frame components
hypothesis hypotheses in luma technique access
samples constraints
‍
CE10.1.1.a AMVP merge 1 >= 8x8 up to 2 luma +
(uni only) index chroma
JVET-
M0176
CE10.1.1.b skip/merge merge 1 or 2 full-pel for no up to 4 luma +
Page: 150 Date Saved: 2019-03-172019-03-14

(uni or bi) index additional temporal chroma
JVET- (implicitly hypotheses
M0176 derived)
(luma) spatial: no
CTU
constraints
CE10.1.2.a merge ref index + 1 or 2 > 8x8 full-pel for no up to 4 luma +
AMVP mvp index additional temporal chroma
JVET- + hypotheses
M0425 MVDs +
weight
index
(luma + spatial:
chroma) from left or
within
CTU
CE10.1.2.b merge ref index + 1 or 2 > 8x8 full-pel for not allowed up to 4 luma +
AMVP mvp index additional chroma
JVET- + hypotheses
M0425 MVDs +
weight
index
(luma +
chroma)
CE10.1.2.c merge ref index + 1 or 2 > 8x8 full-pel for no up to 2 luma +
AMVP mvp index additional temporal chroma
JVET- + hypotheses
M0425 MVDs +
weight
index
(luma + spatial:
within
CTU
CE10.1.2.d merge ref index + 1 or 2 > 8x8 full-pel for no up to 4 luma
AMVP mvp index additional temporal
JVET- + hypotheses
M0425 MVDs +
weight
index
(luma + spatial:
within
CTU
Page: 151 Date Saved: 2019-03-172019-03-14

The test results for this aspect are summarized as follows,
# Proposal Config. VTM
Proposal Config. Y U V EncT DecT
CE10.1.1.a JVET-M0176 RA -0.17% -0.13% -0.10% 107% 100%
LB 0.00% 0.10% 0.25% 107% 101%
CE10.1.1.b JVET-M0176 RA -0.17% -0.25% -0.22% 103% 102%
LB -0.12% -0.19% -0.17% 103% 102%
CE10.1.2.a JVET-M0425 RA -0.29% -0.16% -0.12% 107% 97%
LB -0.41% -0.04% -0.04% 110% 99%
CE10.1.2.b JVET-M0425 RA -0.20% -0.02% -0.05% 107% 96%
LB -0.30% -0.10% -0.17% 111% 102%
CE10.1.2.c JVET-M0425 RA -0.20% -0.10% -0.08% 105% 97%
LB -0.20% -0.19% -0.24% 107% 100%
CE10.1.2.d JVET-M0425 RA -0.29% 0.03% 0.04% 107% 96%
LB -0.40% 0.06% -0.02% 110% 99%
According to the CE description, for investigating the impact of multi-hypothesis inter prediction on
cache-related aspects, the cache model compiled into the reference decoder software by setting #define
JVET_J0090_MEMORY_BANDWITH_MEASURE to 1 is used, in conjunction with the cache config
file provided in JVET-K0451. For each bit stream, the decoder outputs a total hit ratio when using the
cache model. The following table compares the average hit ratios (in percentage) of the tests with those of
VTM-3.0:
Data quoted from JVET-M0176:
VTM-3.0 (%) CE10.1.1.b (%)
Class A1 99.4735 99.4663
Class A2 99.5509 99.5461
Class B 99.5308 99.5249
Class C 99.3467 99.3435
Class E
Overall 99.4755 99.4702
Class D 99.3402 99.3401
Class F 98.8734 98.8607
(mandatory)
Low delay B Main10

VTM-3.0 (%) CE10.1.1.b (%)
Class A1
Class A2
Class B 99.6490 99.6414
Class C 99.5511 99.5415
Class E 99.5562 99.5517
Overall 99.5854 99.5782
Class D 99.5090 99.496
Class F 99.0382 99.0268
(mandatory)
Page: 152 Date Saved: 2019-03-172019-03-14

Data quoted from JVET-M0425:
Random
Access
VTM-3.0 CE10.1.2.a CE10.1.2.b CE10.1.2.c CE10.1.2.d
A1 99.4888 99.4781 99.4878 99.4858 99.4866
A2 99.5513 99.5474 99.5505 99.5488 99.5505
B 99.5340 99.5259 99.5330 99.5326 99.5345
C 99.3629 99.3593 99.3615 99.3630 99.3634
Overall 99.4843 99.4777 99.4832 99.4826 99.4838
D 99.3416 99.3379 99.3412 99.3414 99.3415
F 98.9343 98.9258 98.9267 98.9297 98.9291
Low Delay B
VTM-3.0 CE10.1.2.a CE10.1.2.b CE10.1.2.c CE10.1.2.d
B 99.6547 99.6462 99.6531 99.6539 99.6567
C 99.5650 99.5548 99.5594 99.5656 99.5628
E 99.5242 99.5147 99.5187 99.5224 99.5225
Overall 99.5813 99.5719 99.5771 99.5806 99.5807
D 99.5715 99.5657 99.5683 99.5727 99.5737
F 99.1095 99.0934 99.0978 99.1081 99.1034
1.1.a uses two hypotheses in uni prediction and merge. Basically, the same prediction could be invoked
by using bi prediction. However, only one AMVP list is generated, and it may save some signalling.
Encoder time increases by 7%, no gain in LB.
Are gains of 1.1.a/b additive? They are said to have been almost additive before this CE cycle, but in the
current CE the combination was not tested.
Worst case memory BW of 1.1.a is uncritical, of 1.1.b was analysed as roughly 80% of VTM.
Combination of 1.1.a/b would be somewhat similar to 1.2.a, which uses multi hypothesis for both merge
and AMVP, and additionally allows kind of different weighting of the hypotheses. 1.2.a is the “full set” of
functionality of this proposal, whereas b..d are somewhat simplifications, mainly for the benefit of saving
local storage (b), or memory bandwidth (c,d). d still uses up to 4 hypotheses (2 each in bi with >=8x16
block size restriction), but only for luma, which is the reason for worse performance in chroma. It is
reported that worst case memory BW is 0.97%
It is also mentioned that potentially gains of 1.1.a might add up to 1.2.x.
Generally, the gain of all 1.1.x and 1.2.x proposals is significantly less than it was over VTM2 (cut by
half or even more). In particular, the 1.1.b and 1.2.x proposals add need for more building blocks. 1.1.a is
relatively simple and ce re-use existing memory access structures and MC logic, but for getting the gain
of 0.17% for RA (no gain for LB), the encoder runtime also increases by 7%.
By doing more encoder checks and increasing runtime by 7%, probably it should be possible to get
similar gain without a syntax change.
1.1.3…5 target simplification of VTM3 (CIIP)

For simplification aspects, the tests and corresponding results are summarized as follows, where the
current design in VTM-3.0 and the differences between each test and VTM-3.0 are listed
Page: 153 Date Saved: 2019-03-172019-03-14

# Proposal Supported Reference PDPC Weights for CU constraints Notes
intra modes sample combined
smoothing
VTM-3.0 4: DC, PL, Yes Yes PL, DC: equal area >=64
VER, HOR weights
VER, HOR: W<128 &&
fixed, position H<128
dependent
weights
CE10.1.3.a JVET-M0290 1: PL Yes Yes equal weights
CE10.1.3.b JVET-M0290 4: DC, PL, No for PL* No for PL, DC: equal
VER, HOR PL weights
VER, HOR:
fixed, position
dependent
weights
CE10.1.3.c JVET-M0290 4: DC, PL, Yes Yes equal weights
VER, HOR
CE10.1.3.d JVET-M0290 1: PL No for PL* No equal weights CE10.1.3.a +
(4:4) CE10.1.3.b
LD frame: 6:2*
CE10.1.4 JVET-M0177 VTM
constraints +
area <=1024
CE10.1.5.a JVET-M0293 1: PL equal weights VTM CE10.1.3.a +
constraints + CE10.1.4
area <=1024
CE10.1.5.b JVET-M0293 1: PL No equal weights VTM CE10.1.3.a +
(4:4) constraints + CE10.1.4 +
no PDPC
LD frame: 6:2* area <=1024
* Not in original CE description.
Page: 154 Date Saved: 2019-03-172019-03-14

The test results for this aspect are summarized as follows,

CE10.1.3.a JVET-M0290 RA -0.01% 0.13% 0.09% 99% 100%
LB 0.10% 0.35% 0.36% 99% 100%
CE10.1.3.b JVET-M0290 RA 0.01% 0.00% -0.02% 100% 100%
LB 0.01% -0.01% -0.07% 100% 101%
CE10.1.3.c JVET-M0290 RA 0.05% 0.12% 0.10% 100% 100%
LB 0.10% 0.18% 0.05% 100% 100%
CE10.1.3.d JVET-M0290 RA 0.02% 0.07% 0.03% 99% 100%
LB 0.01% 0.12% 0.13% 99% 100%
CE10.1.4 JVET-M0177 RA 0.01% 0.02% 0.05% 99% 102%
LB 0.04% -0.04% 0.13% 100% 100%
CE10.1.5.a JVET-M0293 RA 0.02% 0.16% 0.12% 98% 100%
LB 0.11% 0.23% 0.29% 98% 100%
CE10.1.5.b JVET-M0293 RA 0.06% 0.07% 0.03% 98% 100%
LB 0.07% 0.15% 0.03% 98% 99%
It is commented that 10.1.3.b/d was not originally planned in the CE.

In the context of reviewing 10.1.3.x proposals, the following aspects were identified in CIIP:
- does it need a specific MPM derivation? If there was only one mode (as in 10.1.3a/d) it is not needed at
all, and it is mentioned that there are proposals just suggesting fixed length coding
- CIIP does not have any serious latency issue. Therefore, simplifications that remove some processing
steps that are otherwise used in intra prediction is not necessary.
- Sample-wise unequal weighting is not an implementation issue, whereas equal weighting would be
preferrable, unless it costs compression performance or causes qualty problems.
Beyond the solutions approachs tested in 10.1.3 more study is necessary on these aspects.
10.1.4 requests restricting the maximum block size of CIIP to 32x32 (now it is 64x64). The motivation is
saving need for additional memory. As however the maximum size of a inter-only or intra-only prediction
block is large anyway, the real need for such a restriction is not obvious.
10.1.5 is combining some 10.1.3.x and 10.1.4.
CE10.2: OBMC
# Proposal Applied # of blending lines BW reduction Runtime Cost
boundaries technique reduction reduction
technique technique
CE10.2.1 JVET- CU 2: width < 8 (left); height apply OBMC to uni- 1. reuse L CTU row
M0178 boundaries < 8 (top) prediction blocks shape buffer buffer
4: otherwise use uni-prediction to 2. apply CU removal
generate OBMC region size constraints
3. apply MV
Page: 155 Date Saved: 2019-03-172019-03-14

merge
4. skip similar
MVs
CE10.2.2 JVET- CU 2: width < 8 (left); height use integer MV to 1. reuse L CTU row
M0179 boundaries < 8 (top) generate OBMC region shape buffer buffer
3: otherwise 2. apply CU removal
size constraints
3. apply MV
merge
4. skip similar
MVs
CE10.2.3 JVET- CU CU boundary: CU boundary: 1. reuse L CTU row
M0180 boundaries + 2: width < 8 (left); apply OBMC to uni- shape buffer buffer
sub-block height < 8 (top) prediction blocks 2. apply CU removal
boundaries 4: otherwise use uni-prediction to size constraints
sub-block: generate OBMC region
1: top, left, right
(when sub-block OBMC sub-block: 3. apply MV

is applied, the number of only apply to uni- merge
blending line at CU prediction affine blocks 4. skip similar
boudnary is 1) MVs
CE10.2.4 JVET- CU CU boundary: CU boundary: 1. reuse L CTU row
M0181 boundaries + 2: width < 8 (left); use integer MV to shape buffer buffer
sub-block height < 8 (top) generate OBMC region 2. apply CU removal
boundaries 3: otherwise size constraints
sub-blcok:
1: top, left, right
(when sub-block OBMC sub-block: 3. apply MV
is applied, the number of only apply to uni- merge
blending line at CU prediction affine blocks 4. skip similar
boudnary is 1) MVs
All proposals impose a CU size constraint >= 64 samples. It is requested to provide a more detailed
analysis of the memory bandwidth. Likely, for processing on-the-fly, the worst case would be that the
current block is 8x8, and all of the top and left neighbours are 4x4. Another option would be to store
samples from the current block that were already fetched to perform interpolation in the neighbour
blocks. In that case, it should be reported how large the additional local buffer would be, for all four
methods.
Additional analysis is shown Sat. afternoon for 10.2.1 and 10.2.2 (to be provided in updated version of
JVET-M0178/9). This analysis indicates that for those tw approaches the worst-case memory bandwidth
of VVC is not increased for on-the-fly fetch (and even a little less for 10.2.2), or if the pre-generation
method is used, the memory BW is even lower, but 1.96/1.28 kByte is necessary as local buffers.
In terms of processing, it is reported that worst case number of sample interpolations is not increased
relative to the current bi prediction case. Method 10.2.1 uses uni prediction in a 8x8 block, and
additionally needs to interpolate four 4x4 areas with other vectors for OBMC. Method 10.2.2 does not use
any interpolations for OBMC. For 10.2.1, weighted superposition requires at most 4 shifts and 2 adds per
sample. Furthermore, since the operations are locally varying, some additional logic is necessary. For
10.2.2., the latter numbers duplicate. Furthermore, 10.2.2 is more challenging in terms of local memory
acces, as 6 different sources need to be blended.
10.2.1 seems manageable from complexity perspective (but definitely adds some complexity).
Page: 156 Date Saved: 2019-03-172019-03-14

The test results are summarized as follows,
Y U V EncT DecT
CE10.2.1 JVET-M0178 RA -0.27% -0.58% -0.62% 104% 103%
LB -0.36% -0.50% -0.51% 106% 105%
CE10.2.2 JVET-M0179 RA -0.37% -0.91% -0.90% 105% 104%
LB -0.39% -0.55% -0.48% 106% 106%
CE10.2.3 JVET-M0180 RA -0.39% -0.59% -0.63% 105% 104%
LB -0.39% -0.69% -0.76% 107% 108%
CE10.2.4 JVET-M0181 RA -0.49% -0.91% -0.87% 106% 105%
LB -0.45% -0.62% -0.34% 108% 110%
As a general note, the gain in compression performance is lower than it was with VTM2 (approx. half).
However, from the results, OBMC even gives more gain for LB than for RA, and LB is in overall
performance of VVC still worse than RA, this is assessed to be valuable enough. Some support, and no
opposition is raised in Track B against adopting it.
It was initially agreed in Track B to adopt JVET-M0178. Specification text was available. This decision
was later reverted in the JVET Sunday plenary (see the notes in section 10.1).
This would have a high-level flag for disabling it.
CE10.3: Multiple shape prediction partitions

In CE10.3, the goal is to test AMVP to be combined with non-rectangular prediction partitions within one
CU. The tests and corresponding results are summarized as follows:,
# Proposal Config. VTM Description

Y U V EncT DecT
CE10.3.1 JVET-M0189 RA -0.06% -0.03% -0.06% 123% 100% Two triangle prediction units
(PUs) for AMVP mode
LB -0.07% -0.10% -0.01% 122% 103% Restricted to uni-prediction
Restricted to RefIdx0
Applied to block width >= 8
&& block height >= 8
From the results (low gain versus high increase in encoder run time), not worthwhile to consider
CE10.4: Diffusion filters for intra and inter prediction
In CE10.4, the goal is to test prediction to be combined using filtering, where three types of filters, two
directional filters and one uniform filter are used. The filters are FIR filters, applied on the prediction
signal, not iterative. The 1D filters are 9-tap, symmetric, only 1 multiplication, otherwise shifts. The 2D
filter is a 5-tap diamond shape, only shift/add operations. At the boundaries, pixel replication is used.
Page: 157 Date Saved: 2019-03-172019-03-14

The tests and corresponding results are summarized as follows,
Y U V EncT DecT
CE10.4.1 JVET- AI -0.19% -0.03% -0.03% 123% 101% Uniform Diffusion filters with
M0042 encoder speedup and simplified
filter masks
RA -0.44% -0.51% -0.35% 113% 98%
LB -0.17% 0.27% 0.59% 114% 98%
LP -0.86% -0.26% -0.11% 119% 97%
CE10.4.2 JVET- AI -0.17% -0.03% -0.05% 119% 101% Like CE10.4.1, but
M0042 • In case of temporal layer depth
larger than 3, no diffusion filter
is applied
RA -0.42% -0.54% -0.42% 111% 98% • Simplified encoder search for
intra blocks
LB -0.17% 0.41% 0.43% 113% 98%
LP -0.87% -0.15% -0.10% 118% 96%
Generally, it was agreed that this method gives interesting gain, and is straightforward to implement at the
decoder. Two concerns are raised:
 - As it needs to be run after the prediction signal is generated, it produces additional delay in the intra
prediction loop.
 - For inter blocks, it can be used for 128x128 CU, which would break concepts of 64x64VPDU.
It is requested to provide additional results without using the method in intra prediction (and the intra part
of CIIP), and restrict the largest CU size to 64x64.
It is also reported that a late contribution (JVET-M0848) provides new results for the same method of
10.4.2 with some (small) encoder speedup and slightly increased performance (-0.44% for luma).
Furthermore, it would be desirable to use only the prediction samples (no reconstructed samples from
current picture). A version which did that was shown in the previous CE.
Was revisited (Track B Thu 17 Jan.1630) after new results were made available in JVET-M0042v3. The
restrictions were implemented as requested, including not using reconstructed samples from neighbour
blocks. Results are as follows:

Over VTM-3.0
Y U V EncT DecT
Class A1 -0.27% -0.45% -0.19% 108% 100%
Class A2 -0.35% -0.19% -0.16% 109% 101%
Class B -0.41% -0.37% -0.45% 109% 99%
Class C -0.15% -0.11% -0.12% 110% 99%
Class E
Overall -0.30% -0.28% -0.25% 109% 100%
Class D -0.11% -0.18% -0.20% 110% 102%
Class F (mandatory) -0.09% -0.13% -0.11% 108% 101%
The spec text was available and straightforward.

One expert points out that the multiplication by 6 can be implemented by shift and add.
LB results are not complete yet, but by tendency similar as in the original scheme, lower gain than for
RA.
Page: 158 Date Saved: 2019-03-172019-03-14

Further study in CE, along with LIC and post rec filters. This CE should also identify how potentially
gains add up. The restriction of not using recosntructed samples from neighbouring inter blocks may not
be necessary.
CE10.5: Local illumination compensation

In CE10.5, the goal is to test prediction to be combined using linear model derived from reconstructed
and reference neighbouring samples. The tests and corresponding results are summarized as follows:

Y U V EncT DecT
CE10.5.2 JVET-M0087 RA -0.56% -0.31% -0.37% 135% 99% 1. Remove all encoder and
decoder LIC processes other
than the reconstruction stage
LB -0.51% -0.44% -0.58% 140% 101% 2. Modify bS calculation of
DBF for LIC boundary.
CE10.5.3 JVET-M0112 RA -0.44% -0.31% -0.34% 134% 101% Based on CE10.5.2
LB -0.39% -0.40% -0.42% 138% 100% LIC is confined to use

reference samples only from
the current CTU
The method of 10.5.2 is mainly for the benefit of encoders, and does not solve the latency issue that LIC
imposes on decoder pipeline. The problem is that a current block needs to wait for reconstruction of the
neighbours, and then it requires a certain number of cycles until the parameters of the linear model are
computed. Of particular concern is the fact that many decoder implementations target processing inter and
intra coded blocks independently in order to make best benefit of parallel processing. Typically, inter
coded blocks of a CTU are decoded first. For this, has a non-negligible complexity impact (in particular
for parallel processing) if LIC of an inter coded block uses the reconstruction of intra coded neighbours.
If such an approach (disabling LIC from intra coded neighbours, including CPR) would be combined with
the approach of 10.5.3 (only using reconstructed inter coded samples from current CTU), the situation
would be better, however would still mean that the inter reconstruction within a CTU would need to be
sequential (similar as the situation in intra is). Regardless of that, LIC has some additional processing
complexity (which doubles in case of bi prediction) which needs to be justified by performance. The
processing should also be aligned with the 64x64 VPDU concept. (See further notes on these aspects
under JVET-M0873.)
Further study was recommended on these aspects.
A BoG (coordinated by C.-W. Hsu and M. Winken) was established to review CE10 related proposals,
and suggest candidates for further study in a CE. See the further notes for the discussion of the BoG
report JVET-M0873.
The subsequent notes only contain abstracts copied from the documents. Actions taken are noted above
under JVET-M0029.
JVET-M0042 CE10: Uniform Directional Diffusion Filters for Video Coding [J. Rasch,
A. Henkel, J. Pfaff, H. Schwarz, D. Marpe, T. Wiegand (HHI)]
An encoder speedup for the Uniform Diffusion filters described in JVET-L0157 is investigated. The filter
masks are simplified and no iterations are used. There are three types of filters, two directional filters and
one weighted interpolation of the directional filters. Further, a restriction of the Diffusion filters is
investigated.
Page: 159 Date Saved: 2019-03-172019-03-14

JVET-M0900 Cross-check of JVET-M0042: CE10: Uniform Directional Diffusion Filters
For Video Coding [J. Ström (Ericsson)] [late]
JVET-M0087 CE10: Low pipeline latency LIC (test 10.5.2) [K. Abe, T. Toma, J. Li
(Panasonic)]
This contribution provides test results of Low pipeline latency LIC which is described in CE10.5.2.
Proposed LIC is based on the existing LIC implemented in JEM, but it removes all encoder and decoder
LIC processes other than the reconstruction stage. According to this modification, feedback loop of
neighbouring image reference in hardware pipeline can be closed to the reconstruction stage only.
Additionally, it is proposed to modify bS calculation of DBF for LIC boundary. Simulation results
reportedly show that the proposed method provides 0.56% BD-rate gain for RA, 0.51% BD-rate gain for
LDB.
JVET-M0112 CE10: LIC confined within current CTU (test 10.5.3) [P. Bordes, T. Poirier,
F. Le Léannec (Technicolor)]
This contribution describes test CE10.5.3 corresponding to Local Illumination Compensation (LIC) with
reduced memory bandwidth, where the pipelining dependency between the reconstruction of the area to
the left and the current region is confined within the current CTU only.
The proposed process has been implemented in the JVET VTM3.0 on top of regular LIC (CE10.5.2). The
reported simulation results show an average luma BD-rate gain of -0.44% in RA configuration and of -
0.39% in LDB configuration. The encoding and decoding times stay identical to the regular LIC.
JVET-M0176 CE10.1.1: Multi-hypothesis prediction for improving non-skip & non-merge

inter mode and merge mode [M.-S. Chiang, C.-W. Hsu, Y.-W. Huang, S.-M.
Lei (MediaTek)]
In this proposal, multi-hypothesis (MH) prediction is proposed to improve the existing prediction modes
in inter pictures, including uni-prediction of non-skip & non-merge inter (NSNM-inter) mode and merge
mode. The general concept is to combine an existing prediction mode with an extra merge indexed
prediction. The merge indexed prediction is performed as in merge mode, where a merge index is
signalled to acquire motion information for the motion compensated prediction. The final prediction is the
weighted average of the merge indexed prediction and the prediction generated by the existing prediction
mode. It is reported that, compared to VTM3.0, the proposed MH prediction for uni-prediction of NSNM-
inter achieves -0.17% and 0.00% luma BD-rates with 7% and 7% encoding time increases and 0% and
1% decoding time increases for RA and LB, respectively. In CE10.1.1.b, when MH prediction is applied
to merge mode, -0.17% and -0.12% luma BD-rates with 3% and 3% encoding time increases and 2% and
2% decoding time increases for RA and LB, respectively, are reported.
JVET-M0177 CE10.1.4: Simplification of combined inter and intra prediction [M.-S.

Chiang, C.-W. Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
This contribution proposes to simplify combined inter and intra prediction (CIIP). The concept is to
disable CIIP for coding units (CUs) with luma coding block (CB) sizes larger than 1024 luma samples for
reducing intra prediction buffer size when CIIP is applied. It is reported that, compared to VTM3.0, the
proposed simplification method results in 0.01% and 0.04% luma BD-rates with 1% and 0% encoding
time decreases for RA and LB, respectively.
Page: 160 Date Saved: 2019-03-172019-03-14

JVET-M0611 Crosscheck of JVET-M0177 (CE10.1.4: Simplification of combined inter and
intra prediction) [B. Wang (Huawei)] [late]
JVET-M0178 CE10.2.1: Uni-prediction-based CU-boundary-only OBMC [Z.-Y. Lin, T.-D.

Chuang, C.-Y. Chen, C.-W. Hsu, C.-C. Chen, Y.-C. Lin, Y.-W. Huang, S.-M.
Lei (MediaTek), X. Xiu, Y. He (InterDigital)]
This contribution reports the results of Core Experiment 10.2.1 (CE10.2.1) on complexity reduction
methods for overlapped block motion compensation (OBMC). In the proposed CE10.2.1, OBMC is
applied only when the current coding unit (CU) is uni-prediction, and the prediction block from each
neighbouring bi-prediction block is converted from bi-prediction to uni-prediction by choosing the
neighbouring bi-prediction block motion vector (MV) that points to a reference picture closer to the
current picture. Besides, encoder-only lossless complexity reduction methods are developed. To further
reduce the worst case complexity, OBMC is disabled for CUs smaller than 64 luma samples. As for the
syntax, an OBMC flag is signalled at CU level for inter mode. It is reported that CE10.2.1 results in -
0.27% and -0.36% luma BD-rates with 4% and 6% encoding time increases and 3% and 5% decoding
time increases for VTM3.0-RA and VTM3.0-LB, respectively, and the worst case motion compensation
(MC) complexity of CE10.2.1 OBMC does not exceed the worst case in VTM3.0 (8x4 or 4x8 bi-
prediction).
JVET-M0179 CE10.2.2: Integer-MV-based CU-boundary-only OBMC [Z.-Y. Lin, T.-D.

Chuang, C.-Y. Chen, C.-W. Hsu, C.-C. Chen, Y.-C. Lin, Y.-W. Huang, S.-M.
Lei (MediaTek), X. Xiu, Y. He (InterDigital)]
This contribution proposes complexity reduction methods for overlapped block motion compensation
(OBMC). In the proposed Core Experiment 10.2.2 (CE10.2.2), the generation of the prediction blocks
from neighbouring blocks is restricted to use integer motion vectors (MVs), resulting in interpolation-free
OBMC. Besides, encoder-only lossless complexity reduction methods are developed. To further reduce
the worst case complexity, OBMC is disabled for coding units (CUs) smaller than 64 luma samples. As
for the syntax, an OBMC flag is signalled at CU level for inter mode. It is reported that OBMC using
integer MVs (CE10.2.2) results in -0.37% and -0.39% luma BD-rates with 5% and 6% encoding time
increases and 4% and 6% decoding time increases for VTM3.0-RA and VTM3.0-LB, respectively, and
the worst case MC complexity of OBMC does not exceed the worst case in VTM3.0 (8x4 or 4x8 bi-
prediction).
JVET-M0180 CE10.2.3: Subblock OBMC with uni-prediction-based OBMC at CU

boundaries [Y.-C. Lin, C.-C. Chen, C.-W. Hsu, Z.-Y. Lin, T.-D. Chuang, C.-
Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
This contribution reports the results of Core Experiment 10.2.3 (CE10.2.3) on subblock overlapped block
motion compensation (OBMC). In CE10.2.3, except for affine mode of uni-prediction, the coding-unit-
boundary-only OBMC from CE10.2.1 in JVET-M0178 is applied as it is. For affine mode of uni-
prediction, OBMC is applied at top, left, and right subblock boundaries for each subblock of the coding
unit (CU), and the number of OBMC lines for weighted averaging at subblock boundaries is set to one. It
is reported that CE10.2.3 results in -0.39% and -0.39% luma BD-rates with 105% and 107% encoding
time increases and 104% and 108% decoding time increases for VTM3.0-RA and VTM3.0-LB,
respectively, and the worst case motion compensation (MC) complexity of CE10.2.3 OBMC does not
exceed the worst case in VTM3.0 (i.e., 8x4 or 4x8 bi-prediction).
Page: 161 Date Saved: 2019-03-172019-03-14

JVET-M0181 CE10.2.4: Subblock OBMC with integer-MV-based OBMC at CU
boundaries [Y.-C. Lin, C.-C. Chen, C.-W. Hsu, Z.-Y. Lin, T.-D. Chuang, C.-
This contribution reports the results of Core Experiment 10.2.4 (CE10.2.4) on subblock overlapped block
motion compensation (OBMC). In CE10.2.4, except for affine mode of uni-prediction, the coding-unit-
boundary-only OBMC from CE10.2.2 in JVET-M0179 is applied as it is. For affine mode of uni-
prediction, OBMC is applied at top, left, and right subblock boundaries for each subblock of the coding
unit (CU), and the number of OBMC lines for weighted averaging at subblock boundaries is set to one. It
is reported that CE10.2.4 results in -0.49% and -0.45% luma BD-rates with 106% and 108% encoding
time increases and 105% and 110% decoding time increases for VTM3.0-RA and VTM3.0-LB,
respectively, and the worst case motion compensation (MC) complexity of CE10.2.4 OBMC does not
exceed the worst case in VTM3.0 (i.e., 8x4 or 4x8 bi-prediction).
JVET-M0189 CE10.3.1: AMVP mode for triangle prediction [Y. Ahn, D. Sim (Digital
Insights)]
This contribution provides the simulation results of CE10.3.1. In this test, AMVP mode for triangle
prediction is applied. The test 10.3.1 can achieve 0.06% and 0.07% BD-rate gain in random access and
low-delay B configuration, respectively.
JVET-M0564 Cross-check of JVET-M0189: CE10.3.1 AMVP mode for triangle prediction

[J. Kim, T. Na (SK Telecom), J. Shin, K. Ko (Pixtree)] [late]
JVET-M0290 CE10: Simplification on Combined Inter-Intra Prediction (Test 10.1.3)

[W. Xu, B. Wang, H. Yang, J. Chen (Huawei)]
This proposal simplifies the combined Inter-Intra prediction adopted in Macao meeting from three
aspects. It aims to reduce the 4 intra modes used in the combined Inter-Intra prediction to only Planar
mode, to simplify the Planar prediction process by skipping PDPC, and to use simpler weighting factor
for the whole CU in Inter-Intra prediction sample averaging. Four Tests with different combinations of
above simplifications are performed, named as 10.1.3.a, 10.1.3.b, 10.1.3.c and 10.1.3.d.
It is reported that, compared to VTM3.0, the luma BD-rate of proposed CE10.1.3.a are -0.01% in RA, and
0.10% in LDB with encoding time slightly decreased and decoding time remains the same; the luma BD-
rate of proposed CE10.1.3.b are 0.01% in RA, and 0.01% in LDB with encoding and decoding time
remains the same; the luma BD-rate of proposed CE10.1.3.c are 0.05% in RA, and 0.10% in LDB with
encoding and decoding time remains the same; the luma BD-rate of proposed CE10.1.3.d are 0.02% in
RA, and 0.01% in LDB with encoding time slightly decreased, respectively.
JVET-M0293 CE10: Simplification on Combined Inter-Intra Prediction with size

restriction (Test 10.1.5) [W. Xu, B. Wang, H. Yang, J. Chen (Huawei), M.-S.
This proposal simplifies the Combined Inter-Intra Prediction (CIIP) adopted in Macao meeting from three
aspects. First, the four intra modes is reduced to only Planar mode. Second, the Planar prediction process
is performed by skipping PDPC. Third, the number of weights is reduced. In addition, the proposed
simplifications are combined with the test in CE10.1.4, where the size of blocks applied with combined
inter-intra prediction is restricted no larger than 1024 samples. Two Tests CE10.1.5.a and CE10.1.5.b are
performed: CE10.1.5.a uses only Planar mode in CIIP, with equal weights, and applies the size
restriction; CE10.1.5.b uses only Planar mode in CIIP, skip the PDPC step, and applies the size
Page: 162 Date Saved: 2019-03-172019-03-14
restriction. In addition, CE10.1.5.a applies equal weights for all configurations while CE10.1.5.b applies
equal weights except for low delay P, where (2, 6) weights are used with 2 applied for intra.
It is reported that, compared to VTM3.0, the luma BD-rate of proposed CE10.1.5.a are 0.02% in RA, and
0.11% in LDB with encoding time slightly decreased and decoding time remains the same; the luma BD-
rate of proposed CE10.1.5.b are 0.06% in RA, and 0.07% in LDB with encoding and decoding time
remains the same, respectively.
JVET-M0425 CE10: Multi-hypothesis inter prediction (Test 10.1.2) [M. Winken,

H. Schwarz, D. Marpe, T. Wiegand (HHI)]
This document reports results for tests CE10.1.2.a – CE10.1.2.d on multi-hypothesis inter prediction. The
total number of motion-compensated prediction signals (per block) which constitute the overall prediction
signal is limited to 4 (i.e., up to 2 additional prediction signals). The multi-hypothesis inter prediction
mode is restricted to be available only for blocks that are larger than 8x8 luma samples and have both
width and height greater than or equal to 8 luma samples (i.e., the smallest applicable block sizes are 8x16
and 16x8). The additional prediction signals use full-pel reference sample positions for both luma and
chroma (i.e., there is no sub-pel interpolation filtering). Multi-hypothesis inter prediction cannot be used
together with BIO, triangular partition, or combined intra/inter prediction within the same PU.
For test CE10.1.2.a, the following results are reported for this test relative to VTM-3.0:
RA: -0.29% (Y), -0.16% (Cb), -0.12% (Cr) 107% enc. time 97% dec. time
LB: -0.41% (Y), -0.04% (Cb), -0.04% (Cr) 110% enc. time 99% dec. time
For test CE10.1.2.b, the additional prediction parameters are not re-used for merging. The following
results are reported for this test relative to VTM-3.0:
For test CE10.1.2.c, only 2 different reference pictures can be used within each PU. The following results
are reported for this test relative to VTM-3.0:
For test CE10.1.2.d, the additional predictions are only used for the luma component. The following
results are reported for this test relative to VTM-3.0:
RA: -0.29% (Y), 0.03% (Cb), 0.04% (Cr) 107% enc. time 96% dec. time
LB: -0.40% (Y), 0.06% (Cb), -0.02% (Cr) 110% enc. time 99% dec. time
5.11 CE11: Deblocking (9)

Contributions in this category were discussed Friday 11 Jan. 0900–XXXX (Track B chaired by JRO).
JVET-M0031 CE11: Summary Report on Deblocking [A. Norkin, A. M. Kotra]

This contribution provides a summary report of Core Experiment 11 on deblocking filtering. Two
categories of proposals are covered by this CE, split into two sub-tests. These sub-tests are 1) long-tap
deblocking filters, and 2) deblocking at 4x4 block boundaries.
The proposals were encoded according to two test conditions, which correspond to two anchors.
Anchor-1 is VTM-3.0 according to the CTC.
Page: 163 Date Saved: 2019-03-172019-03-14

Anchor-2 is VTM-3.0 with ALF switched off (other conditions are the same as in Anchor 2).
11.1.1 Very strong deblocking filtering with conditional activation signalling JVET-M0092
11.1.2 Extended deblocking filter for luma and chroma JVET-M0075
11.1.3 Long deblocking filters (only luma) JVET-M0186
11.1.4 CE11: Test results of CE11.1.5 long-tap deblocking filter JVET-M0208
11.1.5 Longer tap Luma deblocking filter JVET-M0298
Combination of JVET-L0403, JVET-L0327, JVET-L0405, JVET-
11.1.6 JVET-M0471
L0140. JVET-L0337, JVET-L0572, JVET-L0072
11.1.7 L0140. JVET-L0337, JVET-L0572, JVET-L0072 with 6 line buffers at JVET-M0471
CTU boundary
11.1.8 L0140. JVET-L0337, JVET-L0572, JVET-L0072 with 4 line buffers at JVET-M0471
CTU boundary
Deblocking for 4xN, Nx4 blocks and 8xN, Nx8 blocks that are not
11.2.1 JVET-M0299
aligned with 8x8 sample grid
11.2.2 Parallel deblocking filter JVET-M0337
Test CE11.1
Tests Luma modified (Y/N) Chroma modified (Y/N)
CE11.1.1 Y Y
CE11.1.2 Y Y
CE11.1.3 Y N
CE11.1.4 Y N
CE11.1.5 Y N
CE11.1.6 Y Y
CE11.1.7 Y Y
CE11.1.8 Y Y
Luma deblocking complexity

Tests Samples Samples Max num. Max number of Num. line Worst case
from block from block oper for oper. for decision buffers complexity
bound. bound. filtering per per line increased
modified deblocking line (add/mult/compa (Y/N)
decision (add/mult/co r/shift)
mpar/shift)
VTM3.0 3+3 4+4 56 94 per 8 line 4
(28/2/12/14) segment
11.75 per line
CE11.1.1 M=3+3...16+ 1+1 (2/3/2/1)*M 6 (5/0/0/1) per 4 N
16 line
CE11.1.2 7+7 8+8 246 4.5 8 Y (for
(138/12/28/68) (12/0/6/0)/4 in filtering)
additional to
VTM
CE11.1.3 7+7, 7+3, 16 266 12.5 (24/0/22/4)/4 8 N
3+7, 3+3 (168/34/28/36) in addition to
VTM
CE11.1.4 7+7, 3+7 16 190 2.5 (6/0/2/2)/4 in 4 N
(124/12/0/54) addition to VTM
Page: 164 Date Saved: 2019-03-172019-03-14

CE11.1.5 7+7, 3+7 16 187(85/4/28/4 9 (24/4/4/4)/4 in 4 N
2) addition to VTM
CE11.1.6 7+7, 7+5, 8+8, 8+6, 148 12 (26/0/10/12)/4 8 N
5+7, 5+5, 6+8, 6+6, (74,24,28,22) in addition to
7+3, 3+7, 8+4, 4+8, VTM
5+3, 3+5 6+4, 4+6
CE11.1.7 7+7, 7+5, 8+8, 8+6, 148 12 (26/0/10/12)/4 6 N
5+7, 5+5, 6+8, 6+6, (74,24,28,22) in addition to
7+3, 3+7, 8+4, 4+8, VTM
5+3, 3+5 6+4, 4+6
CE11.1.8 7+7, 7+5, 8+8, 8+6, 148 12 (26/0/10/12)/4 4 N
5+7, 5+5, 6+8, 6+6, (74,24,28,22) in addition to
7+3, 3+7, 8+4, 4+8, VTM
5+3, 3+5 6+4, 4+6
Chroma deblocking complexity
Tests Samples fromSamples Max number of Max number of Number of Worst case
block from block operations for oper. for decision line buffers complexity
boundary boundary filtering per line per line increased
modified for (add/mult/compa (add/mult/compar/sh (Y/N)
deblocking r/shift) ift)
decision
VTM3.0 1+1 None 10 (6/0/2/2) None 2
CE11.1.1 M=1+1...8+8 1+1 (2/3/2/1)*M 6 (5/0/0/1) per line 2 Y
CE11.1.2 3+3 4+4 56 (28/2/12/14) 17.5 (19/0/10/6)/2 4 Y
per line
CE11.1.3 VTM VTM VTM VTM 2 N
CE11.1.6 3+3 4+4 76 (48, 2, 12, 14) 17 (17, 0, 12, 5)/2 4 Y
per line
CE11.1.7 3+3 4+4 76 (48, 2, 12, 14) 17 (17, 0, 12, 5)/2 3 Y
per line
CE11.1.8 3+3 4+4 76 (48, 2, 12, 14) 17 (17, 0, 12, 5)/2 2 Y
per line
11.1.6-8 are the same (combined from 4 previous proposals) with different mumber of line buffers (8/6/4)
at CTU boundary.
11.1.5, 11.1.6-8 use sample-based adaptation of clipping range
It was suggested to translate the maximum number of operations per line into the maximum number of
operations per sample (also considering that the long filters are only applied for large blocks), and decode
the value “M” of 11.1.1 into a number. Some of the statements in the table above (worst case increased
Y/N) may not be true. More detailed analysis is needed but it appears that if proposals increase worst case
complexity in terms of number of operations it would not be by a large factor.
This analysis became available in JVET-M0031v4 and was presented in Track B at Friday 18 January
0800 (JRO).
Beyond the number of operations, the number of line buffers is another complexity issue. VTM uses 4
lines for luma and 2 lines for chroma, which is duplicated by some proposals.
Parallel processing capability is given by all proposals at some sufficiently small granularity (though
larger than current VVC) – see table below.
Tests Smallest unit size needed to perform proposed
Page: 165 Date Saved: 2019-03-172019-03-14

deblocking operations separately from any other units
VTM3.0 8x8
CE11.1.1 luma 16x16, chroma 8x8 (to be verified)
CE11.1.2 16x16
CE11.1.3 16x16
CE11.1.4 16x16
CE11.1.5 16x16
CE11.1.6 32x32
CE11.1.7 32x32
CE11.1.8 32x32
It is however pointed out that some of the proposals 11.1.1-5 did not consider that VTM3 now uses
subblock boundary deblocking, whereas the decision of using long filters is based only on CU boundary
properties. Therefore, it could happen that a long filter is applied first, and afterwards a subblock
boundary within the CU is deblocked again. This would inhibit parallelism. This could be classified as a
bug, which however in terms of subjective testing might not be too harmful.
None of the proposals comes with a specification text. For the decision on using long filters, CU and
subblock boundaries should be handled equal.
SNR based Results with ALF on
AI RA
Test Y U V EncT DecT Y U V EncT DecT
CE11.1.1 0.05% 0.01% 0.03% 100% 100% 0.35% 0.12% 0.12% 100% 101%
CE11.1.2 -0.01% -0.56% -0.52% 100% 102% -0.06% -0.41% -0.32% 100% 102%
CE11.1.3 0.00% 0.00% 0.00% 100% 101% -0.02% -0.02% 0.00% 100% 103%
CE11.1.4 0.01% 0.00% -0.01% 102% 103% 0.00% 0.01% 0.00% 102% 102%
CE11.1.5 0.00% 0.00% 0.00% 99% 100% 0.02% -0.01% 0.00% 99% 99%
CE11.1.6 -0.02% -0.53% -0.49% 100% 99% 0.00% -0.80% -0.82% 100% 102%
CE11.1.7 -0.02% -0.54% -0.50% 101% 99% -0.01% -0.82% -0.85% 101% 102%
CE11.1.8 -0.02% -0.43% -0.39% 101% 103% 0.00% -0.71% -0.68% 100% 101%
LD-B LD-P
CE11.1.1 0.40% 0.20% 0.15% 101% 102% 0.40% 0.22% 0.05% 101% 102%
CE11.1.2 0.03% 0.53% 0.23% 100% 102% -0.01% 0.15% -0.32% 100% 102%
CE11.1.3 0.01% -0.02% 0.00% 100% 103% -0.02% 0.13% 0.03% 100% 102%
CE11.1.4 0.13% -0.03% -0.09% 99% 103% 0.06% 0.21% -0.10% 101% 104%
CE11.1.5 0.13% 0.15% 0.07% 98% 99% 0.02% 0.17% -0.09% 98% 96%
CE11.1.6 0.13% -1.32% -1.58% 100% 102% -0.03% -1.54% -1.88% 100% 102%
CE11.1.7 0.12% -1.38% -1.48% 102% 103% -0.02% -1.49% -1.86% 101% 102%
CE11.1.8 0.08% -1.15% -1.42% 99% 101% -0.02% -1.21% -1.62% 101% 100%
SNR based results with ALF off

AI RA
CE11.1.1 0.04% -0.03% -0.01% 100% 101% 0.36% 0.09% 0.07% 101% 102%
CE11.1.2 -0.01% -0.72% -0.63% 100% 102% -0.09% -0.45% -0.36% 100% 102%
CE11.1.3 0.00% 0.00% 0.00% 100% 102% -0.01% 0.00% 0.00% 100% 102%
CE11.1.4 0.01% 0.00% 0.00% 100% 102% -0.03% -0.08% -0.03% 102% 105%
CE11.1.5 -0.01% 0.00% 0.00% 99% 100% 0.00% -0.03% 0.03% 98% 99%
CE11.1.6 -0.03% -0.71% -0.61% 92%* 101% -0.02% -0.88% -0.89% 84%* 103%
CE11.1.7 -0.03% -0.71% -0.62% 108% 99% -0.04% -0.86% -0.86% 100% 102%
CE11.1.8 0.05% -1.13% -1.49% 104% 103% -0.02% -1.64% -1.65% 102% 103%
qq
Page: 166 Date Saved: 2019-03-172019-03-14

LD-B LD-P
CE11.1.1 0.42% 0.21% 0.09% 101% 102% 0.42% 0.13% 0.13% 101% 101%
CE11.1.2 -0.01% 0.17% -0.41% 100% 102% -0.09% -0.43% -0.61% 100% 102%
CE11.1.3 -0.04% 0.01% -0.22% 100% 102% 0.00% -0.04% 0.02% 100% 103%
CE11.1.4 0.07% 0.19% 0.04% 100% 105% 0.01% 0.09% 0.02% 99% 103%
CE11.1.5 0.09% 0.13% -0.17% 98% 98% -0.06% 0.10% -0.14% 98% 99%
CE11.1.6 0.04% -1.12% -1.74% 89%* 103% -0.02% -1.77% -1.94% 81%* 102%
CE11.1.7 0.04% -1.32% -1.60% 105% 105% -0.06% -1.85% -2.01% 95% 104%
CE11.1.8 -0.03% -0.58% -0.50% 104% 105% -0.03% -0.77% -0.76% 103% 103%
*Unreliable encoding times.
CE11.2
Test Proponent(s) Cross-checker(s)
CE11.2.1 Kenneth Andersson Hyeongmun Jang
kenneth.r.andersson@ericsson.com hm.jang@lge.com
Anand Meher Kotra
Anand.meher.kotra@huawei.com
Chia-Ming Tsai
chia-ming.tsai@mediatek.com
JVET-M0299
CE11.2.2 Hyeongmun Jang Kenneth Andersson
hm.jang@lge.com kenneth.r.andersson@ericsson.com
JVET-M0337
Complexity for luma
Tests Samples from Samples from Max num. oper for Max number of oper. Num. Worst case
block bound. block bound. filtering per line for decision per line line complexity
modified for deblocking (add/mult/compar/ (add/mult/compar/shift buffers increased
decision shift) ) (Y/N)
CE11.2.1 VTM VTM VTM (additional VTM (additional VTM N

(additional (additional boundary 14 boundary 20/4
boundary 1+1 boundary 3+3 (6/2/5/1) but then 14 (11/0/5/4) /4 per line but
but then 1+1 but then 3+3 instead of 56 for then 20/4 instead of 94/8
instead of 3+3 instead of 4+4 same boundary as for same boundary as
for same for same VTM) VTM)
boundary as boundary as
VTM) VTM)
CE11.2.2 VTM(no VTM VTM VTM VTM N
filtering on
block boundary
of 4xN for
EDGE_VER,
Nx4 for
EDGE_HOR)
Complexity for chroma

Tests Samples from Samples Max num. oper for Max number of Num. line Worst case
block bound. from block filtering per line oper. for decision buffers complexity
modified bound. for (add/mult/compar/ for 8-sample increased
deblocking shift) boundary (Y/N)
decision (add/mult/compar/
shift)
CE11.2.1 VTM VTM VTM VTM VTM N
CE11.2.2 VTM (no VTM VTM VTM VTM N
filtering on
Page: 167 Date Saved: 2019-03-172019-03-14

block boundary
of 2xN for
EDGE_VER
and Nx2 for
EDGE_HOR)
It is suggested to translate the maximum number of operations per line into the maximum number of
operations per sample. This is included in JVET-M0031v4.
VTM3 operates deblocking on an 8x8 grid. If a CU boundary is not on an 8x8 grid, it is not deblocked. If
a CU is on an 8x8 grid, furthermore subblocks within that CU are deblocked (provided they are on the
8x8 grid as well). 4xN blocks are deblocked whenever they are coinciding with the 8x8 grid
11.2.1 deblocks on a 4x4 grid, where a boundary is deblocked with VTM filter when the next block or
subblock is more than four samples apart, and with a weak and short filter if it is only samples apart.
11.2.2 uses an 8x8 grid and VTM deblocking filter but disables deblocking whenever the boundary would
be only four samples apart.
SNR based results (ALF on)
AI RA
CE11.2.1 0.02% 0.00% 0.00% 99% 99% -0.12% 0.07% 0.03% 98% 98%
CE11.2.2 -0.09% 0.22% 0.15% 100% 99% 0.01% 0.15% 0.05% 100% 99%
LB LP
CE11.2.1 -0.14% -0.17% -0.01% 98% 98% -0.18% -0.06% -0.20% 98% 98%
CE11.2.2 0.00% 0.00% 0.06% 100% 99% 0.00% -0.02% -0.33% 100% 100%
SNR based results (ALF off)
AI RA
CE11.2.1 -0.05% -0.01% 0.00% 99% 99% -0.23% -0.02% -0.04% 98% 98%
CE11.2.2 -0.03% -0.22% -0.41% 100% 100% 0.08% 0.18% 0.15% 100% 100%
LB LP
CE11.2.1 -0.21% 0.04% -0.23% 98% 98% -0.36% 0.14% -0.16% 97% 98%
CE11.2.2 0.01% 0.01% -0.33% 100% 100% 0.09% -0.11% -0.15% 100% 100%
Subjective testing to be done. It is suggested to use an ”AB” comparison where each proposal is
compared against VTM3 at same QP.
From the test plan, it would be 96 test cases (2 QPs 34,39, 5 sequences, 8 proposals for 11.1, 2 QPs 30,34,
4 sequences, 2 proposals for 11.2). It would be highly desirable to test both ALF on and ALF off cases. If
only one of these cases is possible out of logistic reasons, the ALF off case should be used (as planned in
the original CE description). The ALF on bitstreams for subjective testing still need crosscheck.
JVET-M0906 Subjective assessment of CE11 (deblocking filter) proposals [V. Baroncini,

A. Norkin, A. M. Kotra, K. Andersson, K. Misra, H. Jang, C. M. Tsai,
D. Rusanovskyy]
This report was presented in Track B Thu Jan. 17 1200-1330
This contribution provides a report of the subjective test for the proposals in Core Experiment 11 on
deblocking filtering. Two set of tests were performed during the Marrakech meeting in accordance with
Page: 168 Date Saved: 2019-03-172019-03-14

the CE11 description document JVET-L1031. Both tests involved visually evaluating CE proposals
versus VTM3 with ALF turned OFF as anchor. ALF was also turned OFF for the CE proposals.
To facilitate further analysis a score representing the number of times the Mean Opinion Score of a CE
proposal is better than the anchor, and the anchor lies outside the confidence interval was also computed.
Expert viewing was conducted during the Marrakech meeting for both CE 11.1 (Longer tap filter)
category and CE 11.2 (4 x 4 luma sample grid filtering). The sequences and the QP points used are as
listed in the core experiment plan description JVET-L1031[2]. The invitation for the subjective viewing
participation was issued on the JVET reflector. 12 non-proponent viewers were selected as the test
participants for subjective testing for both the categories. All theThe 12 participants were divided into 4
groups containing 3 participants each.
The dates and the actual timings of the viewing sessions are included with the attached spreadsheets along
with the contribution. Each coded video was compared with the anchor; the order of presentation of
anchor and coded videos was randomly changed. The Anchor used in all the configurations was with ALF
(adaptive loop filter) tool turned off. The coded video also had the ALF (adaptive loop filter) tool turned
off.
A video (preceded by the latter A) was shown on the screen, followed a second video (preceded by the
letter B); once again A video (preceded by the latter A), followed by the second video (preceded by the
letter B) is shown on the screen; then the message “Vote N” was presented asking to the viewers to rate if
“A was much better than B”, “A was better than B” or “B was better than A” or “B was much better than
A”.
The order of presentation of the video clips inside each test session was assigned randomly taking care
not to show the same sequence two consecutive times.
For the CE 11.1 category, following test sequences and conditions were used in the subjective tests. The
sequence length is 10 seconds.
Num Name Resolution fps Frames Mode QP

01 FoodMarket 3840x2160p 60fps 600 RA 39, 34
02 Campfire 3840x2160p 30fps 300 RA 39, 34
03 Kimono 1920x1080p 24fps 240 LDB 34, 39
04 KristenAndSara 1280x720p 60fps 600 LDP 34, 39
05 Red Kayak* 1920x1080p 30fps 300 RA 34, 39
*
= The first 300 frames of the RedKayak sequence were used.
To facilitate analysis, the scores provided by viewers were translated to a fix scale of 1, 2, 3 or 4, with:
1 representing anchor is much better than a CE proposal,
2 representing anchor is better than a CE proposal,
3 representing a CE proposal is better than the anchor, and
4 representing a CE proposal is much better than the anchor.
The anchor used is VTM3 with ALF OFF. Mean Opinion Score (MOS) and Confidence Intervals (CI)
were computed for each data-point. For each QP, these were in turn used to compute:
 Number of times (x) a CE proposal beats the anchor i.e. number of times (MOS – CI) is greater than
2.5; and
 Number of times (y) anchor beats the CE proposal i.e. (MOS + CI) is less than 2.5.
The total score for each CE proposal, for a given QP, is then computed as x – y.
Page: 169 Date Saved: 2019-03-172019-03-14

Example (range: 1 to 4)
5
4
3
2 Anchor
1
0
TESTB(TIE:0)
IN:+1)
TESTC(LOSS:-1)
TESTA(W
Example illustrating Test A wins, Test B tie, Test C loses for a sequence
From such an approach, it was found that in all cases proposals were either better equal, no case was
found worse than the anchors. All tests were performed with “ALF off” anchor. When “ALF on” was
compared to “ALF off”, it was also found to be visually better than the anchor in 6 out of 10 test cases,
whereas some proposals are better than the anchor in 9 of the test cases, as shown by the following table:
Listed below are the total score of the CE proposals in CE11.1. The attached excel contains more detailed
results.CE11.1: Long Filters Tests – highest possible total score per QP is +5, lowest possible score per
QP is -5:
CE Total Total
Proposal score for score for
QP34 QP39
CE11.1.1 2 4
CE11.1.2 3 4
CE11.1.3 1 2
CE11.1.4 2 2
CE11.1.5 3 4
CE11.1.6 4 5
CE11.1.7 2 5
CE11.1.8 4 5
Page: 170 Date Saved: 2019-03-172019-03-14

5
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0
Total score for QP34 Total score for QP39
CE11.1.1 CE11.1.2 CE11.1.3 CE11.1.4

CE11.1.5 CE11.1.6 CE11.1.7 CE11.1.8
One conclusion that can be drawn is that longer-tap deblocking helps for visual quality at large CU
boundaries. However, it can not directly be concluded that the effect would still be visible with similar
clarity when ALF was on. From looking at scores of individual sequences, it can be seen that some of the
ne deblocking with ALF off are still working better than existing deblocking with ALF on in
approximately half of the cases, such that it can be concluded that new deblocking methods give a benefit
in terms of subjective quality that is additive to the benefit of ALF. Therefore, a conclusion might be
drawn that when both new deblocking and ALF were enabled, a visual benefit would still be visible. To
investigate if such a statement is true, additional viewing should be done with a selected proposal, one
“best performing” (from the table above, where 11.1.8 seems to be the best candidate, as it has good
performance and does not increase the need of line buffering). Additional viewing to be performed to
confirm that 11.1.8 with ALF on still gives benefit compared to VTM3 with ALF on.
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 review in Track B Thu 1330),
pending on confirmation from the viewing, and the more detailed report on complexity impact.
Informal viewing (3 sessions, around 20 participants, 12 of which were not involved in this CE) was
conducted Thu 17 Jan evening. It is reported that also in comparison to the ALF on anchor, differences
are clearly visible in particular for sequences Campfire, Redkayak, and also slight improvement for
Foodmarket and KristenSara.
The complexity analysis in JVET-M0031v4 was presented Fri 18 Jan in Track B. For the adopted
proposal, the worst case number of operations is not increased for luma, and the number of line buffers is
kept the same. Additional complexity is the need for switching to another filter mode in the case of large
Page: 171 Date Saved: 2019-03-172019-03-14

blocks, which is not critical. For chroma, the worst case number of operations is increased by
approximately 10, as a separate decision is employed. This increase of complexity appears justified by the
fact that it gives considerable visual improvement in cases of sequences where chroma is critical.
For CE11.2, results are not as conclusive. A similar analysis as above provides the following table (where
in this case, the highest score would be 4):
CE Total Score Total Score
Proposal for QP30 for QP34
CE11.2.1 0 -1
CE11.2.2 0 1
Compared to that, ALF on versus ALF off has a score of 3 and 2, for QP30 and 34, respectively. This
indicates that ALF has a clear benefit over any of the proposals, and it can hardly be concluded that they
would further improve the quality when combined. At least in this range of bit rates, deblocking on an
aligned 4x4 grid does not seem to improve the visual quality. No action necessary from these results.
Could be due to the fact that the design of the CE had a flaw in selecting too low QP range. Might be
worthwhile to continue the study now in combination with longer filters, and comparing with ALF on as
anchor.
The subsequent notes only contain abstracts copied from the documents. Actions taken are noted above
under JVET-M0031 and JVET-M0906.
JVET-M0075 CE11: Extended Deblocking Filter (test 11.1.2) [K. Unno, K. Kawamura,

S. Naito (KDDI)]
This contribution presents a proposal of extended deblocking filtering method. In the proposed method,
long tap deblocking filters are applied to both luma and chroma samples. BD-rates for luma and chroma
(Y, U, V) are (-0.01%, -0.56, -0.52), (-0.06%, -0.41%, -0.32), (0.03%, 0.53%, 0.23%), and (-0.01%,
0.15%, -0.32) for AI, RA, LDB, and LDP conditions, respectively, in case of comparing with VTM-3.0
ALF ON. In a similar way, BD-rates for luma and chroma (Y, U, V) are (-0.01%, -0.72, -0.63), (-0.09%, -
0.45%, -0.36), (-0.01%, 0.17%, -0.41%), and (-0.09%, -0.43%, -0.61) under the AI, RA, LDB, and LDP
conditions, respectively, in case of comparing with VTM-3.0 ALF OFF.
JVET-M0092 CE11: Very strong deblocking with conditional activation signalling (Test
11.1.1) [C. Helmrich, B. Bross (HHI)]
This contribution describes the configuration of the authors’ conditionally signalled very strong
deblocking approach, as previously presented in JVET-L0523, in the VTM software for the Core
Experiment (CE) on improved deblocking filtering for the Versatile Video Coding (VVC) standard. The
integration of this proposal into VTM 3.0 reportedly results in negligible luma BD-rate changes while
providing subjective gains. It is kindly requested to adopt one of the proposed two variants (differing in
algorithmic complexity) of the very strong deblocking method in the next revision of the VVC
specification and VTM reference software.
JVET-M0186 CE11.1.3: Long deblocking filters [C.-M. Tsai, T.-D. Chuang, C.-W. Hsu, C.-
This contribution proposes to add three long strong filter sets in addition to the HEVC strong filter set for
deblocking. It is reported that the proposed long strong filtering leads to negligible changes in BD-rate
and encoding time, and decoding time increase is 3% for VTM3.0 CTC and and for CTC with ALF off. It
is asserted that the subjective quality at high QPs is improved because of the long strong filter sets.
Page: 172 Date Saved: 2019-03-172019-03-14

JVET-M0208 CE11: long-tap deblocking filter (Test 11.1.4) [W. Choi, K. Choi (Samsung)]
This contribution is corresponding to CE11 test 11.1.4 and it proposes changes on filtering process of
deblocking filter on large block boundary. The purpose of this document is to show the performance
result of JVET-K0112 algorithm implemented on VTM 3.0 software. The test results show that the
proposed method achieves 0.01%, 0.00%, 0.13% and 0.06% BDBR for AI, RA, LDB, LDP compared to
VTM 3.0 and 0.01%, -0.03%, 0.07% and 0.01% BDBR for AI, RA, LDB, LDP compared to VTM 3.0
with ALF switched off, respectively.
JVET-M0298 CE11: Longer tap deblocking filter (test 11.1.5) [A. M. Kotra, B. Wang,
S. Esenlik, H. Gao, J. Chen (Huawei)]
This contribution reports the results of CE 11 test 11.1.5 which uses a longer tap deblocking filter to
reduce blocking artefacts which are observed at large block boundaries. Furthermore, to reduce line
buffer requirements for the “longer tap” filter: for the horizontal edges which overlap with the CTU
boundaries, the maximum number of samples used in filter decision and the maximum number of samples
used in filter modification from the top block are restricted to be the same as in VTM 3.0 deblocking
filter.
Objective results are as follows:
Over VTM 3.0 Anchor with ALF OFF (AI, RA, LDB, LDP): Luma BD-Rate of -0.01%, 0.00%, 0.09%, -
0.06% is achieved without any increase in EncT and DecT.
Over VTM 3.0 Anchor with ALF ON (AI, RA, LDB, LDP): Luma BD-Rate of 0.00%, 0.02%, 0.13%,
0.02% is achieved without any increase in EncT and DecT.
JVET-M0299 CE11: Deblocking for 4 x N, N x 4 blocks and 8 x N, N x 8 blocks that are not
aligned with 8 x 8 sample grid (test 11.2.1) [K. Andersson, Z. Zhang,
R. Sjöberg (Ericsson), A. M. Kotra, J. Chen, S. Esenlik, B. Wang, H. Gao
(Huawei), C.-M. Tsai, C.-W. Hsu, T.-D. Chuang, C.-Y. Chen, Y.-W. Huang,
S.-M. Lei (MediaTek)]
This contribution document reports the results of the core experiment CE11.2.1, which is a joint proposal
from Ericsson, Huawei and MediaTek Inc. VTM-3.0 does not apply deblocking filter for some edges
belonging to the blocks whose size is Nx4, 4xN blocks and also for some blocks whose size is Nx8, 8xN
where N value can be upto 64 samples. This test applies deblocking on 4x4 grid to not only allow
deblocking of Nx4, 4xN, Nx8 and 8xN blocks aligned with the current 8x8 sample grid but also for the
Nx4, 4xN, Nx8, 8xN blocks that are not aligned on the current 8x8 sample grid. The number of samples
to read and modify during deblocking filtering is limited to allow for parallel friendly processing. For a
given edge, if at least one of the blocks sharing the edge has a size of 4 samples (orthogonally) then the
VTM-3.0 weak deblocking filter is chosen to be applied. Furthermore, the weak filter is constrained to
only modify one sample on either side of the edge.
Subjective analysis shows that when compared to the Anchor (VTM-3.0), the proposed test improves the
subjective quality of sequences.
Objective results show luma BD-Rate gain with negligible run-time changes.
Over VTM 3.0 Anchor with ALF OFF (AI, RA, LDB, LDP): Luma BD-Rate of -0.05%, -0.23%, -0.21%,
-0.36% is achieved with negligible run-time changes.
Over VTM 3.0 Anchor with ALF ON (AI, RA, LDB, LDP): Luma BD-Rate of 0.02%, -0.12%, -0.14%, -
0.18% is achieved with negligible run-time changes.
Page: 173 Date Saved: 2019-03-172019-03-14

JVET-M0337 CE11: Test CE11.2.1 Parallel deblocking filter [H. Jang, J. Nam, S. Kim,
J. Lim (LGE)]
This proposal presents a parallel deblocking filter based on current block size. The performance of the
proposed parallel deblocking method is evaluated in terms of subjective and objective quality.
Experimental results reportedly show -0.09%, 0.01%, 0.00%, 0.00% BD-rate changes for AI, RA, LD-B
and LD-P configurations respectively.
JVET-M0471 CE11.1.6, CE11.1.7 and CE11.1.8: Joint proposals for long deblocking from
Sony, Qualcomm, Sharp, Ericsson [M. Ikeda, T. Suzuki (Sony),
D. Rusanovskyy, M. Karczewicz (Qualcomm), W. Zhu, K. Misra, P. Cowan,
A. Segall (Sharp Labs of America), K. Andersson, J. Enhorn, Z. Zhang,
R. Sjöberg (Ericsson)]
This contribution describes a parallel friendly long filter design for deblocking of large blocks common
for CE11.1.6, CE11.1.7 and CE11.1.8. It further describes two variants of CTU line buffer reduction in
CE11.1.7 and CE11.1.8 respectively. The CE tests are based on technologies that scored highly in
subjective assessment carried out for CE11 before Macao meeting. It is asserted that all three tests give
better subjective quality than the VTM-3.0 anchor.
The BD-Rate number for CE11.1.6 is Y/U/V reportedly shows 0.0%/-0.5%/-0.5% at AI, 0.0%/-0.8%/-
0.8% at RA, 0.1%/-1.3% /-1.6% at LDB and 0.0%/-1.5%/-1.9% at LDP over VTM-3.0 with ALF
switched on, respectively. When ALF is switched off, the BD-Rate results for Y/U/V reportedly shows
0.0%/-0.7%/-0.6 % at AI, 0.0%/-0.9%/ -0.9% at RA, 0.0%/-1.1%/-1.7% at LDB and 0.0%/-1.8%/-1.9% at
LDP, respectively.
0.0%/-0.7%/-0.6 % at AI, 0.0%/-0.9%/ -0.9% at RA, 0.0%/-1.3%/-1.6% at LDB and -0.1%/-1.9%/-2.0%
at LDP, respectively.
0.0%/-0.6%/-0.5 % at AI, 0.0%/-0.8%/ -0.8% at RA, 0.1%/-1.1%/-1.5% at LDB and 0.0%/-1.6%/-1.7% at
LDP, respectively.
5.12 CE12: Mapping functions (2)

Contributions in this category were discussed Saturday 12 Jan. 1600–1645, 1700-1800 (chaired by GJS).
JVET-M0032 CE12: Summary report on mapping functions [E. François, P. Yin]

This contribution provides a summary report of Core Experiment 12 on mapping functions. CE12
evaluates approaches for mapping of HDR and SDR content, with main focus on SDR. The considered
technologies are in-loop reshaping and related variants. Test results against VTM3.0 anchors are provided
for each performed test. Crosschecking reports are integrated in this contribution.
CE12-1: In-loop Reshaping for SDR on coding efficiency (JVET-L0247)

Test Proponent Description Xchecker
Page: 174 Date Saved: 2019-03-172019-03-14

CE12-1 Dolby Test in-loop reshaping for SDR focused on coding E. François
(JVET-L0247) efficiency improvement, such as making reshaping (Technicolor)
function rate adaptive, disable towards higher rates.
In JVET-L0247, the reshaper has two main components: 1) in-loop reshaping applied to the luma
component; 2) additional luma-dependent chroma residue scaling applied to chroma components.
The two elements had been tested separately (see JVET-K0308) and it had been concluded that the two
should be tested together.
CE12-1 was testing a method proposed at the previous meeting with some encoder improvement.
However, a somewhat different method had been developed since then, and there was no longer any
interest in considering the CE12-1 scheme.
CE12-2: In-loop Reshaping for SDR on In-loop Reshaping for SDR on implementation investigation
Test Proponent Description Xchecker
CE12-2 Dolby Test in-loop reshaping for SDR focused on J. Xu (ByteDance),
(JVET-L0247) implementation investigation on pipelining of the block- E. François
wise prediction loop: such as piece-wise linear (Technicolor)
interpolation replacing LUT-based mapping, disable
intra-block in inter slices.
In-loop luma reshaping: CE12-2 tests a lower complexity pipeline that also eliminates decoding latency
for block-wise intra prediction in inter slice reconstruction. Intra prediction is performed in reshaped
domain for both inter and intra slices.
CE12-2 also tests 16-piece PWL models for luma and chroma residue scaling instead of the 32-piece
PWL models of CE12-1.
Inter slice reconstruction with in-loop luma reshaper in CE12-2 (light-green shaded blocks indicate signal
in reshaped domain: luma residue; intra luma predicted; and intra luma reconstructed)
Luma-dependent chroma residue scaling is a multiplicative process implemented with fixed-point
integer operation. Chroma residue scaling compensates for luma signal interaction with the chroma
signal. Chroma residue scaling is applied at the TU level.
For intra the reconstructed luma is averaged.
For inter, the luma prediction is averaged.
The average is used to identify an index in a PWL model. The index identifies a scaling factor cScaleInv.
The chroma residual is multiplied by that number.
Page: 175 Date Saved: 2019-03-172019-03-14

BD-rate of CE12-1 and CE12-2 for SDR
All Intra psnrY psnrU psnrV EncT DecT
12-1 -0.89% 1.52% 1.15% 103% 100%
12-2 -0.89% 1.49% 1.18% 102% 101%
Random Access psnrY psnrU psnrV EncT DecT

12-1 -1.28% 0.53% 0.52% 105% 101%
12-2 -1.30% 1.45% 1.44% 105% 104%
Low Delay B psnrY psnrU psnrV EncT DecT

12-1 -0.72% 0.46% 0.11% 100% 101%
12-2 -0.76% 1.78% 1.42% 98% 105%
The parameters are (currently) sent in the tile group header (similar to ALF). These reportedly take 40-
100 bits.
Suggestions for easing implementation were:
 Disabling the chroma residual scaling for separate tree operation
 Disabling the chroma residual scaling for 2x2 chroma
 Using the prediction signal rather than the reconstruction signal for intra as well as inter
The proponent indicated that these suggestions had previously been tested and should not affect the
performance, and said test results would be provided in a revision of their contribution JVET-M0427.
It was noted that in the current CTC, separate trees are used for intra slices.
It was noted that some loss was observed for the chroma, although the luma gain was enough to more
than compensate for that.
A participant commented that there could be rate allocation effects that could be achieved by local delta
QP or setting of QP based on temporal layer. It was remarked that some tests along those lines were
Page: 176 Date Saved: 2019-03-172019-03-14

reported in L0246. In L0246 some gain was reported in class B but not class A and not as much as for
using this technique. Rate-distortion optimized local QP selection (e.g., testing +/1 values of QP) was one
suggested way to get improvement using local QP adjustment.
As used, the PWL mapping uses 16 equal size segments for the forward mapping, so determining the
index is just a shift. For the inverse mapping, though, it is not using equal spacing. There are two
contributions related to this, JVET-M0640 which tries to simplify the index determination and JVET-
M0109 to make the scale factor for the luma processing be determined on a 4x4 basis instead of on a per-
sample basis.
The spec would be written that CPR is not affected; the prediction signal in that case does not go through
the special processing.
Revisit for review of test results. [Resolved per notes elsewhere]
JVET-M0427 CE12: Mapping functions (test CE12-1 and CE12-2) [T. Lu, F. Pu, P. Yin,
W. Husak, S. McCarthy, T. Chen (Dolby)]
5.13 CE13: Coding tools for 360° omnidirectional video (11)

Contributions in this category were discussed XXday X Jan. XXXX–XXXX (chaired by XXX)were
considered in a BoG reported in JVET-M0874.
JVET-M0874 BoG report on CE13 and CE13 related 360° video coding [J. Boyce]
This BoG report was reviewed in Track A 1600-1700 Thursday 17 January (GJS).
The BoG met on 13 January 2019 from 1800 to 2030, on 14 January 2019 from 1800 to 1900, and on 16
January from 1700 to 1800.
The BoG recommended to adopt JVET-M0892 for disabling of in-loop filters (deblocking, SAO, and
ALF) at vertical and horizontal boundaries signalled in the SPS at MinCbSizeY granularity.
It was noted that the change that was requested was not specific to 360° video.
It was noted that this proposed change is for entire columns / entire rows, not line segments that do not
cut through the entire picture.
For a conventional cubemap, the filter would be disabled for one horizontal line in the middle of the
picture.
It was discussed what sort of limit there would be for how many of these cuts would be allowed. One
suggestion was a limit of 3 cuts in each direction.
The granularity was also discussed – whether it was really necessary to have 4x4 granularity.
It was discussed how this would be implemented in a real decoder. Checking a long list of positions
would not be reasonable.
Due to a desire for further study of this before making a decision, no action was taken on this.
Further study was also recommended to consider more flexible in-loop filter disabling patterns, use cases,
and HW implementation complexity.
The BoG endorsed the recommendation of HLS BoG to change the sps_ref_wraparound_offset to
sps_ref_wraparound_offset_minus1 and changing the units to be MinCbSizeY as in option 1.
The BoG recommended, and Track A endorsed, the following for the 360Lib software:
Page: 177 Date Saved: 2019-03-172019-03-14

 Modify chroma sample location in blending process for PHEC (from JVET-M0368) – basically a bug
fix
 Adopt Hemisphere CMP and Hemisphere EAC projection formats (from JVET-M0452)
Profiling was discussed. Thus far, we have not made any decisions that we believe would require having
different profiles (perhaps for bit depth, colour format, etc., but not for coding features).
JVET-M0033 CE13: Summary report on coding tools for 360° omnidirectional video
[P. Hanhart, J.-L. Lin, C. Pujara]
JVET-M0143 CE13: Face row based geometry padding using projection with bilinear
interpolation based on test 1.1.a (Test 2.1.b) [P. Hanhart, Y. He
(InterDigital)]
JVET-M0144 CE13: Adaptive frame packing based on test 1.1.a (Test 4.1) [P. Hanhart,
Y. He (InterDigital)]
JVET-M0235 CE13: HEC with Pre-rotation based on test 1.1a and 1.1b (Test 4.2)
[C. Pujara, A. Konda, A. Singh, R. Gadde, W. Choi, K. Choi, K. P. Choi
(Samsung)] [late]
JVET-M0320 CE13: HEC with deblocking using spherical neighbours, SAO and ALF
disabled across face discontinuities (Test 1.4) [X. Huangfu, Y. Sun, L. Yu
(Zhejiang Univ.)] [late]
JVET-M0321 CE13: Post-filtering of seam artefacts based on test 1.1.a (Test 3.1)
[X. Huangfu, Y. Sun, L. Yu (Zhejiang Univ.)] [late]
JVET-M0355 CE13: Results on CE13.2.2 and CE13.5.2 [J. Sauer, M. Bläser (RWTH

Aachen Univ.)]
JVET-M0362 CE13: In-loop filters disabled across face discontinuities (Test 1.1.a and
Test1.1.b) [S.-Y. Lin, L. Liu, J.-L. Lin, Y.-C. Chang, C.-C. Ju (MediaTek),
P. Hanhart, Y. He (InterDigital)]
JVET-M0363 CE13: HEC with in-loop filters using spherical neighbours (Test 1.3) [S.-Y.
Lin, L. Liu, J.-L. Lin, Y.-C. Chang, C.-C. Ju (MediaTek)]
Page: 178 Date Saved: 2019-03-172019-03-14

JVET-M0364 CE13: Test 1.1.a with face row based geometry padding of reference pictures
(Test 2.1.a, Test 2.1.c and Test 2.1.d) [C.-H. Shih, J.-L. Lin, Y.-C. Chang, C.-
C. Ju (MediaTek)]
JVET-M0367 CE13: Face row based geometry padding of reference pictures and in-loop
filters using spherical neighbours (Test 5.1) [C.-H. Shih, S.-Y. Lin, L. Liu, J.-
L. Lin, Y.-C. Chang, C.-C. Ju (MediaTek)]
6 Non-CE Technology proposals

6.1 CE1 related – Partitioning (6)
Contributions in this category were discussed XXday X Jan. XXXX–XXXX (chaired by XXX).
JVET-M0195 CE1-related: Non-Residual Block on VPDU Boundary [A. Tamse,

M. W. Park, M. Park, K. Choi (Samsung)]
Discussed elsewhere in notes.
JVET-M0630 Crosscheck of JVET-M0195 (CE1-related: Non-Residual Block on VPDU

Boundary) [C. Rosewarne (Canon)] [late]
JVET-M0237 CE1-related: Transform tiling with residual reordering for pipelined

processing of CTUs [C. Rosewarne, A. Dorrell (Canon)]
JVET-M0285 CE1-related: Prediction Mode Restriction and Implicit Transform Splitting

to Enable VPDU [Y. Zhao, S. Esenlik, H. Yang, J. Chen (Huawei)]
JVET-M0628 Crosscheck of JVET-M0285 (CE1-related: Prediction Mode Restriction and

Implicit Transform Splitting to Enable VPDU) [C. Rosewarne (Canon)]
[late]
JVET-M0421 Non-CE1: Split-first signalling for partitioning [A. Wieckowski, T. Nguyen,

H. Schwarz, D. Marpe, T. Wiegand (HHI)]
Presented Thu 8pm. Chaired by FJB
In the current draft of VVC, the partitioning is a straightforward extension of the HEVC partitioning
approach. At the CTU level, a quad-split (QT) flag is signalled indicating whether a square block should
be split into four equally sized square blocks. Once no further quad-split is signalled, a binary-and-ternary
tree (BTT) is signalled, for which the splits are signalled more extensively using up to three flags,
indicating if a block should be split, in which direction it should be split, and if a ternary or binary split is
to be performed. If a block should not be split, it is required to signal up to two flags indicating that
neither a QT nor BTT split is to be performed. The proposed approach in this document adapted
signalling in which a single flag indicates if a block should be split, followed by coding of the split mode.
Page: 179 Date Saved: 2019-03-172019-03-14

The proposed adaptation of split binarization, together with adapted context modelling introduces
AI/RA/LB/LP luma BD-rate gains of -0.03/-0.07/-0.06/-0.05.
Two additional contexts compared to VTM3.
Allowable partitions remain the same. Only encoding changes.
Main benefit is simplified and cleaner text.
Decision: adopt
JVET-M0780 Crosscheck of JVET-M0421 (Non-CE1: Split-first signalling for

partitioning) [Y. Yasugi, T. Ikai (Sharp)] [late]
JVET-M0888 CE1-related: Picture boundary handling with VPDU constraints [C.-M.

Tsai, S.-T. Hsiang, C.-W. Hsu, T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S.-
M. Lei (MediaTek)] [late]
Discussed Thu 1515
Two approaches are proposed for changing the handling at the picture boundaries so that VPDUs are the
same at picture boundaries as within the picture. This proposes inferred splits at picture boundaries. One
approach uses an inferred QT split (0.06% penalty in RA, higher penalty in Class E); another uses a
signalled choice between QT split and a BT split perpendicular to the picture boundary (0.05% penalty in
RA).
JVET-M0897 Crosscheck of JVET-M0888 (CE1-related: Picture boundary handling with

VPDU constraints) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0905 CE1-related: Picture Boundary Handling regarding to VPDU [H. Gao,

S. Esenlik, B. Wang, A. M. Kotra, J. Chen (Huawei)] [late]
Discussed Thu 1515
This is the same as the first approach in JVET-M0888.
6.2 CE2 related – Subblock motion compensation (31)

Contributions in this category were discussed in BoG JVET-M0862 unless otherwise noted.
JVET-M0862 BoG report on CE2 related subblock motion compensation contributions

[Y. He]
This report was reviewed in Track B Tuesday 15 January 1010-1215 (JRO).
 Adoptions recommended by the BoG:
o Normative changes
1) JVET-M0145: affine sub-block MV clipping, no loss, BF
2) JVET-M0192 (method 4)/JVET-M0462: sub-block MV derivation for chroma
component, very small loss in chroma
3) JVET-M0166 (change 2)/JVET-M0228 (modification 1)/JVET-M0477(change 2), all
proposing the same: remove MV comparison in constructed affine merge candidate
derivation, 0.01% gain in RA, 0.01% loss in LB
Page: 180 Date Saved: 2019-03-172019-03-14

4) JVET-M0273 (change 1)/JVET-M0240/JVET-M0116 (method 1)/JVET-M0338 (method
1)/JVET-M0204 (method 2): only using left neighbour for SbTMVP offset derivation.
This has a loss of LDB 0.01%, none in RA
Decision: all these suggested adoptions were confirmed by Track B.
o Encoder optimization
1) JVET-M0247: affine motion estimation for affine AMVR, gives 0.09% gain, but
increases encoder runtime by 3% for RA.
2) JVET-M0839: increasing the number of RD checking for affine merge mode coding,
0.05% gain in RA, no runtime increase, somewhat larger gain in class A1. However,
cross-checkers report that the runtime is slightly increased by 1–2%.
It was discussed in Track B whether these are giving enough benefit to justify them. After all, the
performance of the respective tools is somewhat increased, particularly for high resolutions.
Decision: all the suggested adoptions were confirmed by Track B.
 Technologies suggested for CE study:
o Affine motion compensation and affine MV coding:
1) JVET-M0467: affine Symmetric MVD: Improves compression by 0.16% for RA with
8% runtime increase. It is pointed out in the discussion in Track B that such a small gain
for this amount of runtime increase would not justify adoption.
o Affine merge mode:
1) JVET-M0166 (Change 1): selecting the MV having the reference index equal to 0 for
both lists (this has 0.05% loss in LB, 0.01% in RA, but is asserted to be significant
complexity reduction)
2) JVET-M0434: Applying constraint to constructed affine merge candidate (0.02% gain in
RA, no change in LB, complexity reduction)
o Worst case memory bandwidth reduction for sub-block modes:
These methods resolve the problem that the worst-case memory bandwidth of these modes is not
worse than for other modes in HEVC. The comparison point should be using 4x8/8x4 also for bi
pred or 4x4 uni in subblock (as per item 1), as this would be necessary without imposing such
vector constraints. It is raised in the Track B discussion that this CE should also investigate the
visual quality impact.
1) Sub-block selection based on uni/bi-prediction: one test for JVET-M0226 (2.4.1.a,
2.4.1.b, 2.4.1.c), JVET-M0150 (2.4.3.b), JVET-M0472 (2.4.4.a, 2.4.4.b, 2.4.4.c and
2.4.4.d)
2) Sub-block MV clipping: JVET-M0309 (2.4.2), JVET-M0702
3) Adaptive sub-block size selection and interpolation filter switching: JVET-M0400,
JVET-M0310
4) Padding based MC method for small block: JVET-M0248
5) Conformance methods: a) JVET-M0049, b) JVET-M0049 plus the formula in JVET-
M0400
6) Integer motion for small block bi-prediction MC (e.g. 4x8 and 8x4): JVET-M0348
o Local buffer storage reduction: JVET-M0110, JVET-M0168, JVET-M0270, JVET-M0266
It was agreed in Track B that all the items above shall be investigated in a CE.
Page: 181 Date Saved: 2019-03-172019-03-14

 Open issues from BoG, where additional presentation and discussion was performed in Track B:
o JVET-M0268, Non-CE2: Interweaved Prediction for Affine Motion Compensation
Additional results were presented in Track B which observe the VPDU constraint (denoted as
test3/test4 in r2). These show that the gain of 0.27% (RA) is retained, while current worst case
memory bandwidth of subblocks (relating to 4x4 bi) is not exceeded, also number of
interpolations is not higher, and the additional superposition is cheap. However, as it is the goal to
establish more restrictions on the memory bandwidth of affine subblocks (see notes on planned
CE above) it would depend how the method of JVET-M0268 would perform in combination with
those. Study this aspect in CE.
o JVET-M0432, CE2-related: Combination of CE2.2.3.d and affine inheritance from motion data
line buffer
In comparison to CE 2.2.3.d (which replaces the local buffer for CPMV by a history-based
approach and this way reduces local memory storage), but came with 0.07%/0.09% loss for
RA/LB, this method reinvokes the usage of the CPMV candidate from the normal MV buffer at
upper CTU boundary. The loss compared to VTM3 is now 0.03%/0.07%. Further study in CE.
o JVET-M0343, Non-CE2: Simplified subblock motion derivation for SbTMVP
The complexity reduction is negligible, but there is a small loss – no action.
JVET-M0311 was also reviewed and agreed to become part of the CE on affine memory bandwidth
reduction.
JVET-M0049 CE2-related: A restriction on memory bandwidth consumption of affine

mode [M. Zhou (Broadcom)]
JVET-M0441 Crosscheck of JVET-M0049 (CE2-related: A restriction on memory

bandwidth consumption of affine mode) [K. Zhang (Bytedance)] [late]
JVET-M0110 CE2-related: Alignment of affine control-point motion vector and subblock

motion vector [H. Huang, W.-J. Chien, V. Seregin, H. Wang, M. Karczewicz
(Qualcomm)]
JVET-M0747 Crosscheck of JVET-M0110 Test 2 (CE2-related: Alignment of affine

control-point motion vector and subblock motion vector) [J. Luo
(InterDigital)] [late]
JVET-M0737 Crosscheck of JVET-M0110 (CE2-related: Alignment of affine control-point

motion vector and subblock motion vector) [A. Tamse (Samsung)] [late]
JVET-M0598 Crosscheck of JVET-M0110 (CE2-related: Alignment of affine control-point

motion vector and subblock motion) [T. Zhou, T. Ikai (Sharp)] [late]
Page: 182 Date Saved: 2019-03-172019-03-14

JVET-M0116 CE2-related: ATMVP simplification [R. Yu, D. Liu, K. Andersson,
JVET-M0460 Crosscheck of JVET-M0116 (CE2-related: ATMVP simplification)

[L. Zhang (Bytedance)] [late]
JVET-M0145 Non-CE2: Motion vector clipping in affine sub-block motion vector

derivation [P. Hanhart, Y. He (InterDigital)]
JVET-M0735 Crosscheck of JVET-M0145 (Non-CE2: Motion vector clipping in affine sub-

block motion vector derivation) [H. Chen (Huawei)] [late]
JVET-M0166 CE2-related: Simplification of constructed affine merge candidate derivation

[Z.-Y. Lin, T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0575 Crosscheck of JVET-M0166 (CE2-related: Simplification of constructed

affine merging candidate derivation) [Y. He (InterDigital)] [late]
JVET-M0167 CE2-related: Decoupling of SbTMVP and affine merge candidate derivation

in subblock merge mode [Y.-L. Hsiao, T.-D. Chuang, C.-W. Hsu, C.-Y. Chen,
Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0850 Cross-check of JVET-M0167 (CE2-related: Decoupling of SbTMVP and

affine merge candidate derivation in subblock merge mode) [S. Sethuraman
(Ittiam)] [late]
JVET-M0168 CE2-related: Simplifications for inherited affine candidates [Y.-L. Hsiao, T.-
D. Chuang, C.-W. Hsu, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0720 Crosscheck of JVET-M0168 (CE2-related: Simplifications for inherited

affine candidates) [H. Chen, T. Solovyev (Huawei)] [late]
JVET-M0192 CE2-related: MV Derivation for Affine Chroma [A. Tamse, M. W. Park,

K. Choi (Samsung)]
Page: 183 Date Saved: 2019-03-172019-03-14

JVET-M0603 Crosscheck of JVET-M0192 (CE2-related: MV Derivation for Affine
Chroma) [G. Li (Tencent)] [late]
JVET-M0204 CE2-related: Simplification of ATMVP [M. Park, M. W. Park, S. Jeong,

A. Tamse, K. Choi (Samsung)]
JVET-M0594 Crosscheck of JVET-M0204 (CE2-related: Simplification of ATMVP)

[T. Zhou, T. Ikai (Sharp)] [late]
JVET-M0217 CE2-related: Constructed affine merge candidate simplification [L. Li,

J. Nam, N. Park, H. Jang, J. Lim, S. Kim (LGE)]
JVET-M0719 Crosscheck of JVET-M0217 (CE2-related: Constructed affine merge

candidate simplification) [H. Chen (Huawei)] [late]
JVET-M0228 CE2-related: Affine mode simplifications [Y.-W. Chen, X. Wang (Kwai Inc.)]
JVET-M0601 Crosscheck of JVET-M0228 (CE2-related: Affine mode simplifications) [T.-

S. Chang, Y.-C. Sun, J. Lou (Alibaba)] [late]
JVET-M0240 CE2-related: Simplification of subblock-based temporal merging candidates

[H. Lee, S.-C. Lim, J. Lee, J. Kang, H. Y. Kim (ETRI)]
JVET-M0620 Crosscheck of JVET-M0240 (CE2-related: Simplification of subblock-based

temporal merging candidates) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0247 CE2 related: Joint test of AMVR for Affine Inter mode (Test 2.1.1 and Test
2.1.2) [H. Liu, K. Zhang, L. Zhang, J. Xu (Bytedance), D. Luo, Y. He, X. Xiu
(InterDigital)]
JVET-M0863 Crosscheck of JVET-M0247 (CE2-related: Joint Test of AMVR for Affine

Inter Mode (Test 2.1.1 and Test 2.1.2)) [K. Choi] [late]
JVET-M0266 CE2-related: History-based affine merge candidates [K. Zhang, L. Zhang,

H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
Page: 184 Date Saved: 2019-03-172019-03-14

JVET-M0662 Crosscheck of JVET-M0266 (CE2-related: History-based affine merge
candidates) [R.-L. Liao, C. S. Lim (Panasonic)] [late]
JVET-M0268 Non-CE2: Interweaved Prediction for Affine Motion Compensation

[K. Zhang, L. Zhang, H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
JVET-M0744 Crosscheck of JVET-M0268 (Non-CE2: Interweaved Prediction for Affine

Motion Compensation) [J. Luo (InterDigital)] [late]
JVET-M0270 CE2-related: An alternative storing method for affine inheritance [K. Zhang,

L. Zhang, H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
JVET-M0572 Crosscheck of JVET-M0270 (CE2-related: An alternative storing method for

affine inheritance) [G. Li (Tencent)] [late]
JVET-M0273 CE2-related: Early awareness of accessing temporal blocks in sub-block

merge list construction [L. Zhang, K. Zhang, H. Liu, J. Xu, Y. Wang,
JVET-M0531 Crosscheck of JVET-M0273 (CE2-related: Early awareness of accessing

temporal blocks in sub-block merge list construction) [R. Yu (Ericsson)]
[late]
JVET-M0310 CE2-related: Using shorter-tap filter for 4x4 sized partition [J. Li, R.-L.
JVET-M0827 Crosscheck of JVET-M0310 (CE2-related: Using shorter-tap filter for 4x4

sized partition) [Y.-C. Lin (MediaTek)] [late]
JVET-M0311 CE2-related: Memory bandwidth reduction for affine mode with less
dependency [J. Li, R.-L. Liao, C. S. Lim (Panasonic)]
This presented in Track B Tue 15 January 1210
This contribution is a further simplification on JVET-M0309. In this contribution, the first control point is
used instead of first sub-block’s motion vector as center of motion vector constrained region of affine
mode.
the BD-rate difference is 0.03% in RA, 0.01% in LD_B respectively.
Further study.
Page: 185 Date Saved: 2019-03-172019-03-14

JVET-M0622 Crosscheck of JVET-M0311 (CE2-related: Memory bandwidth reduction for
affine mode with less dependency) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0338 Non-CE2: Simplified derivation process for SbTMVP [H. Jang, J. Nam,

S. Kim, J. Lim (LGE)]
JVET-M0535 Crosscheck of JVET-M0338 (Non-CE2: Simplified neighbouring spatial

coding unit derivation for SbTMVP) [R. Yu (Ericsson)] [late]
JVET-M0343 Non-CE2: Simplified derivation process for SbTMVP [H. Jang, J. Nam,

JVET-M0690 Cross check of JVET-M0343 [K. Misra (Sharp Labs of America)] [late]
JVET-M0382 CE2-related: Modification of Triangle and MMVD merge indexes coding

[G. Laroche, C. Gisquet, P. Onno, J. Taquet (Canon)]
JVET-M0560 Crosscheck of JVET-M0382 (CE2-related: Modification of Triangle and

MMVD merge indexes coding) [H. Lee, S.-C. Lim, J. Lee, J. Kang (ETRI)]
[late]
JVET-M0400 CE2-related: Worst-case memory bandwidth reduction for VVC [W.-J.

Chien, L. Pham Van, H. Huang, V. Seregin, M. Karczewicz (Qualcomm)]
JVET-M0665 Crosscheck of JVET-M0400 [S. Jeong, K. Choi (Samsung)] [late]
JVET-M0406 CE2/4-related: Unified merge list size for block and sub-block merge modes
[X. Xu, X. Li, S. Liu (Tencent)]
JVET-M0576 Crosscheck of JVET-M0406 (CE2/4-related: Unified merge list size for block
and sub-block merge modes) [C.-Y. Lai (MediaTek)] [late]
JVET-M0432 CE2-related: Combination of CE2.2.3.d and affine inheritance from motion

data line buffer [G. Li, X. Xu, X. Li, S. Liu (Tencent), J. Zhao, S. Kim
(LGE)]
Page: 186 Date Saved: 2019-03-172019-03-14

JVET-M0740 Crosscheck of JVET-M0432 (CE2-related: Combination of CE2.2.3.d and
affine inheritance from motion data line buffer) [A. Tamse (Samsung)] [late]
JVET-M0434 CE2-related: Constraint on constructed affine merge candidates [G. Li,

X. Xu, X. Li, S. Liu (Tencent)]
JVET-M0546 Crosscheck of JVET-M0434 (CE2-related: Constraint on constructed affine

merge candidates) [L. Zhang (Bytedance)] [late]
JVET-M0462 CE2-related: 4x4 chroma affine motion compensation and motion vector
rounding unification [L. Pham Van, W.-J. Chien, H. Huang, V. Seregin,
JVET-M0859 Crosscheck of JVET-M0462: CE2-related: 4x4 chroma affine motion

compensation and motion vector rounding unification [X. Zheng, Y. Wang
(DJI)] [late]
JVET-M0467 CE2-related: Symmetric MVD for Affine Bi-prediction Coding [J. Luo,

Y. He (InterDigital)]
JVET-M0795 Crosscheck of JVET-M0467 (CE2-related: Symmetric MVD for Affine Bi-

prediction Coding) [C.-C. Chen, W.-J. Chien (Qualcomm)] [late]
JVET-M0490 CE2-related: Simplified context model for triangular prediction mode

[M. Gao, X. Li, S. Liu (Tencent)]
JVET-M0753 Crosscheck of JVET-M0490 (CE2-related: Simplified context model for

triangular prediction mode) [R.-L. Liao, C. S. Lim (Panasonic)] [late]
JVET-M0515 Non-CE2.5: ATMVP Collocated Block Derivation from History-based

Candidate [C.-C. Chen, W.-J. Chien, Y. Zhang, C.-H. Hung, Y. Han,
H. Huang, M. Karczewicz (Qualcomm)]
JVET-M0746 Crosscheck of JVET-M0515 (Non-CE2.5: ATMVP Collocated Block

Derivation from History-based Candidate) [J. Luo (InterDigital)] [late]
Page: 187 Date Saved: 2019-03-172019-03-14

JVET-M0526 CE2-related: Further simplification of ATMVP collocated block derivation
[S. H. Wang (Peking Univ.), X. Zheng (DJI), S. S. Wang, S. W. Ma (Peking
Univ.)] [late]
Initial upload rejected as placeholder
JVET-M0602 Cross-check of JVET-M0526: CE2-related: Further simplification of

ATMVP collocated block derivation [S. Bandyopadhyay (InterDigital)] [late]
JVET-M0702 CE2-related: Adaptive sub-block MV clip for affine blocks [X. Li, M. Gao,
S. Liu (Tencent)] [late]
JVET-M0756 CE2.2.7 related: Affine temporal constructed candidates without pruning

[F. Galpin, A. Robert, F. Le Léannec, T. Poirier (Technicolor)] [late]
JVET-M0812 Crosscheck of JVET-M0756: CE2.2.7 related: Affine temporal constructed

candidates without pruning [L. Pham Van, G. Van der Auwera, H. Huang,
M. Karczewicz (Qualcomm)] [late]
JVET-M0839 CE2-related: On number of fast merge candidates for Affine Merge mode
[A. Robert, F. Le Léannec, F. Galpin (Technicolor)] [late]
JVET-M0889 Crosscheck of JVET-M0839 (CE2-related: On number of fast merge

candidates for Affine Merge mode) [Y.-W. Chen (Kwai Inc.)] [late]
6.3 CE3 related – Intra prediction and mode coding (44)

Contributions in this area were primarily first considered in a BoG reported in JVET-qq.Contributions in
this category were discussed XXday X Jan. XXXX–XXXX (chaired by XXX).
See also JVET-M0203 which contains a new proposal called 3.5.1 that was not part of the CE.
See also section 7, which discusses related complexity analysis and reduction proposals.
JVET-M0857 BoG report on CE3-related intra prediction and mode coding [G. Van der
Auwera]
This BoG report was discussed in Track A on Tuesday 1430–1630 (GJS).
The BoG reviewed related input contributions to Core Experiment 3 on intra prediction and mode coding,
and formulated recommendations for consideration by the track (A).
The CE3-related documents were categorized as follows:
 Cross-component prediction (14)
Page: 188 Date Saved: 2019-03-172019-03-14

 Luma intra mode coding (8)
 Chroma intra mode coding (6)
 Interpolation of intra reference samples (4)
 PDPC-related (7)
 Various (7)
The BoG met on 11 Jan. 2019 from 9:00am–1:00pm, from 3pm–7pm, and on 12 Jan. 2019, from 9am–
1:00pm, 3pm–6pm.
The BoG made the following recommendations:
 Adoptions:
o JVET-M0064: simplification of the current VTM3 division operation used in CCLM modelling;
VTM3 includes 2×512 tables (16 bit elements), which is reduced to one table with 16 entries (4
bit elements), and in addition the bit depth of the model slope parameter (alpha) is reduced from
15 bits to 5 bits. No significant coding efficiency impact was reported. Among proposals, this
was the simplest approach. Decision: Adopted.
o JVET-M0095 (editorial): third proposed aspect harmonizes the filtering decision for the reference
samples for all directional intra modes (VVC draft Table 8-4 value for nTbS=2 entry modified
from 20 to 16). Editor action item: Agreed.
o JVET-M0238: linear interpolation that PDPC uses on the secondary boundary for adjacent
angular modes is simplified to nearest neighbour. No significant coding efficiency impact was
reported. This saves several calculations. Decision: Adopted.
 CE tests:
o Reducing the number of reference samples used to compute the cross-component linear model
parameters: JVET-M0108, JVET-M0211, JVET-M0212, JVET-M0219, JVET-M0229, JVET-
M0274
o Multi-model LM (MMLM): JVET-M0384 (determine the block size restriction that is required to
improve the worst case of MMLM and evaluate different formulas to determine the knee-point
for deriving the two models)
o Harmonization and simplification of MPM list construction: JVET-M0210, JVET-M0239, JVET-
M0295 (method 1 + JVET-M0783 = JVET-M0815), JVET-M0494 (methods 2, 4, 5), JVET-
M0528
 Question: Does the scope of this test include MPM list construction of ISP, CIIP?
 Remark: It is proposed to have one software codebase for testing the unification proposals and
separate the unification tests from intra search RD effects. The planar prioritization aspects,
context changes, can be tested on top of the unification tests in additional tests.
 In Track A review Tuesday afternoon, it was suggested that the main goal should be to have a
simplification and harmonization the different ways of how modes are selected. It was noted
that CE10 also includes other proposals relating to MPM list construction (and for eliminating
MPM usage) relating to CIIP and suggested that issues relating to MPM list construction be
considered together in a CE.
 Intra reference sample deblocking: JVET-M0138 (comparing the proposed method with strong
intra smoothing method from HEVC in terms of complexity, artefact reduction) – this has a
subjective effect – in Track A, it was agreed to plan to put this in the same CE as deblocking,
since it has a similar need for subjective evaluation of deblocking artefacts.
 Open issues:
Page: 189 Date Saved: 2019-03-172019-03-14

o The BoG recommended to present and discuss following documents related to small block size
restrictions in the category of complexity analysis and reduction (section 7): JVET-M0065,
JVET-M0169.
o JVET-M0099: The BoG recommended first considering other proposals are presented in the luma
mode coding category. In Track A review it was agreed that such an optimization proposal should
be deferred to later consideration once the elements of the design that are being optimized
become more stable.
o The BoG recommended considering the block size restrictions for PDPC preferably when
additional hardware/software experts are present: JVET-M0045, JVET-M0122, JVET-M0238. In
Track A review, this was suggested to also apply to JVET-M0814
o JVET-M0358: The BoG recommended testing during the meeting, as additional result (AI and
RA conditions; 1 tile/CTU configuration), the “AND condition” version of the reference sample
availability conditions and report back during the current meeting. The proposal is that when the
prediction mode is DC or planary only use PDPC when the above and left samples are both
available. A test was run both for CTC and for a case with 1 CTU = 1 tile, so that there would be
many instances of partial availability. The coding efficiency difference was very small, but was
suggested to be larger subjectively. For the 1 CTU = 1 tile case, the coding efficiency benefit was
0.1%. This would introduce a different type of processing for planar and DC than what is
currently included in the design – currently, these modes don’t need a “PDPC off” path. In CE10
there was a consideration of using planar mode without PDPC but this was not done. In the Track
A discussion, it was agreed that the benefit seemed insufficient for adding an additional
processing type that is otherwise not in the design (i.e., planar and DC without PDPC), since the 1
CTU = 1 tile case should have shown more benefit if there was a strong need. So no action was
taken on this.
In the Track A review, there was a comment that there was an aspect of JVET-M0158 that might need
further consideration. There are two 4-tap filters for angular mode intra prediction using the reference
samples (one smoother one derived by training and the other a sharper filter derived as DCTIF which is
the same filter used for MC interpolation of chroma). This contribution proposed using filter tap values
derived from a formula instead of the values currently defined in a table. The contributor said there was a
phase inconsistency in the current table of phases. An illustration of a case with a sine wave in the
reference samples to show a periodic edge generation phenomenon with the current filters.
Another proposal JVET-M0095 would reduce the number of phases from 32 to 16 (for both luma and
chroma). No action had been taken on that, as it was considered a minor issue at this stage.
No difference in coding efficiency was shown. This could be kept in mind in further work, but there
didn’t seem to be a need to consider this change at this stage. It was remarked that these proposals may be
logical, but we don’t need to consider such a small change before the design is more mature.
JVET-M0044 Non-CE3: Alternative LM Chroma Implementation [S. Keating, K. Sharman

(Sony)]
JVET-M0047 Non-CE3: Intra Angular Prediction and Modified PDPC Based on Two
Reference Lines [D. Jiang, J. Lin, F. Zeng, C. Fang (Dahua)]
JVET-M0048 Non-CE3: Modified Chroma Derived Mode [F. Zeng, J. Lin, D. Jiang,

C. Fang (Dahua)]
Page: 190 Date Saved: 2019-03-172019-03-14

JVET-M0064 Non-CE3: CCLM table reduction and bit range control [Y. Yasugi,
F. Bossen, E. Sasaki (Sharp)]
JVET-M0548 Crosscheck of JVET-M0064 (Non-CE3: CCLM table reduction and bit

range control) [C.-M. Tsai (MediaTek)] [late]
JVET-M0093 Non-CE3: Improved robustness for calculation of cross-component linear

model parameters [C. Helmrich (HHI)]
JVET-M0095 Non-CE3: Intra simplifications [G. Van der Auwera,

A. K. Ramasubramonian, V. Seregin, M. Karczewicz (Qualcomm)]
JVET-M0676 Crosscheck of JVET-M0095 (Non-CE3: Intra simplifications) [P. Merkle

(HHI)] [late]
JVET-M0099 Non-CE3: Partial sorting for non-MPM modes [A. K. Ramasubramonian,

G. Van der Auwera, T. Hsieh, V. Seregin, M. Karczewicz (Qualcomm)]
JVET-M0658 Crosscheck of JVET-M0099 (Non-CE3: Partial sorting for non-MPM

modes) [K. Choi (Samsung)] [late]
JVET-M0100 CE3-related: DM-dependent chroma intra prediction modes [G. Rath,

F. Urban, F. Racapé (Technicolor)]
JVET-M0439 Crosscheck of JVET-M0100 (CE3-related: DM-dependent chroma intra

prediction modes) [H. Liu (Bytedance)] [late]
JVET-M0108 CE3-related: Reducing the number of reference samples and table size in
LM Chroma process [E. François, T. Poirier, F. Le Léannec (Technicolor)]
JVET-M0571 Crosscheck of JVET-M0108 (CE3-related: Reducing the number of

reference samples and table size in LM Chroma process) [L. Zhang
(Bytedance)] [late]
Page: 191 Date Saved: 2019-03-172019-03-14

JVET-M0643 Crosscheck of JVET-M0108 (CE3-related: Reducing the number of
reference samples and table size in LM Chroma process) [P. Hanhart
JVET-M0138 Non-CE3: Intra reference sample deblocking [Z. Zhang, K. Andersson,

JVET-M0550 Crosscheck of JVET-M0138 (Non-CE3: Intra reference sample deblocking)

[C.-M. Tsai (MediaTek)] [late]
JVET-M0139 Non-CE3: History-based intra most probable modes derivation [Z. Zhang,

P. Wennersten, R. Yu, J. Ström, R. Sjöberg (Ericsson)]
JVET-M0639 Crosscheck of JVET-M0139 (Non-CE3: History-based intra most probable

modes derivation) [B. Wang (Huawei)] [late]
Not considered, became available 01-21
JVET-M0443 Crosscheck of JVET-M0139 (Non-CE3: History-based intra most probable

modes derivation) [J. Li, L. Zhang (Bytedance)] [late]
JVET-M0146 Non-CE3: MDLM template downsampling [P. Hanhart, Y. He

(InterDigital)]
JVET-M0733 Crosscheck of JVET-M0146 (Non-CE3: MDLM template downsampling)

[C. Chevance (Technicolor)] [late]
JVET-M0149 Non-CE3: On simplification of PDPC basic equation [A. Filippov,

V. Rufitskiy, J. Chen (Huawei)]
JVET-M0677 Crosscheck of JVET-M0149 (Non-CE3: simplification of PDPC basic

equation) [F. Racapé (Technicolor)] [late]
JVET-M0158 Non-CE3: LUT-free interpolation filters for intra prediction [A. Filippov,

Page: 192 Date Saved: 2019-03-172019-03-14

JVET-M0805 Cross-check of contribution JVET-M0158 (Non-CE3: LUT-free
interpolation filters for intra prediction) [M. Schäfer, J. Pfaff (HHI)] [late]
JVET-M0680 Crosscheck of JVET-M0158 (Non-CE3: LUT-free interpolation filters for

intra prediction) [F. Racapé (Technicolor)] [late]
JVET-M0191 CE3-related: Construction of non-MPM mode list in intra prediction

[S. Cha, G. Lee, G. Kim, J. Han (Sejong Univ.)]
JVET-M0242 Crosscheck of JVET-M0191 (CE3-related: Construction of non-MPM mode

list in intra prediction) [J. Lee, H. Lee, S.-C. Lim, J. Kang (ETRI)] [late]
JVET-M0210 Non-CE3: Intra prediction information coding [J. Yao, J. Zhu, W. Cai,

K. Kazui (Fujitsu)]
JVET-M0758 Crosscheck of JVET-M0210 (Non-CE3: Intra prediction information coding)

[C.-C. Kuo, C.-H. Yau, C.-C. Lin (ITRI)] [late]
JVET-M0211 CE3-related: Fixed Reference Samples Design for CCLM [J.-Y. Huo, X.-W.
Li, J.-L. Wang, Y.-Z. Ma, F.-Z. Yang (Xidian Univ.), S. Wan (NPU), Y.-F.
Yu, Y. Liu (Oppo)]
JVET-M0716 Crosscheck of JVET-M0211 (CE3-related:Fixed Reference Samples Design

for CCLM) [X. Ma (Huawei)] [late]
JVET-M0212 CE3-related: Improved reference samples range for MDLM [S. Wan (NPU),
Q.-H.Ran, X.-W. Li, Y.-Z. Ma, J.-Y. Huo, F.-Z. Yang (Xidian Univ.), Y.-F.
Yu, Y. Liu (Oppo)]
JVET-M0717 Crosscheck of JVET-M0212 (CE3-related:Improved reference samples

range for MDLM) [X. Ma (Huawei)] [late]
JVET-M0213 CE3-related: Chroma intra candidates modification based on directional

DM [Y.-Z. Ma, J.-L. Wang, X.-W. Li, J.-Y. Huo, F.-Z. Yang (Xidian Univ.),
S. Wan (NPU), Y.-F. Yu, Y. Liu (Oppo)]
Page: 193 Date Saved: 2019-03-172019-03-14

JVET-M0718 Crosscheck of JVET-M0213 (CE3-related: Chroma intra candidates
modification based on directional DM) [X. Ma (Huawei)] [late]
JVET-M0214 CE3-related: Uniform Chroma intra candidates modification based on DM

[Y.-Z. Ma, X.-W. Li, J.-L. Wang, J.-Y. Huo, F.-Z. Yang (Xidian Univ.),
S. Wan (NPU), Y.-F. Yu, Y. Liu (Oppo)]
JVET-M0219 CE3-related: Reduced number of reference samples for CCLM parameter

calculation [J. Choi, J. Heo, S. Yoo, L. Li, J. Choi, J. Lim, S. Kim (LGE)]
JVET-M0586 Crosscheck of JVET-M0219 (CE3-related: Reduced number of reference

samples for CCLM parameter calculation) [K. Zhang (Bytedance)] [late]
JVET-M0229 CE3-related: Simplification of LM Mode [Y.-W. Chen, X. Wang (Kwai Inc.)]
JVET-M0632 Crosscheck of JVET-M0229 (CE3-related: Simplification of LM Mode)

[K. Abe (Panasonic)] [late]
JVET-M0239 Non-CE3: Modification of MPM derivation [J. Lee, H. Lee, S.-C. Lim,

J. Kang, H. Y. Kim (ETRI)]
JVET-M0609 Crosscheck of JVET-M0239 (Non-CE3: Modification of MPM derivation)

[B. Wang (Huawei)] [late]
Not considered, became available 01-21 with wrong header
JVET-M0258 CE3-related: Chroma intra candidates modification based on non-

directional DM [J.-Y. Huo, J.-L. Wang, X.-W. Li, Y.-Z. Ma, F.-Z. Yang
(Xidian Univ.), S. Wan (NPU), Y.-F. Yu, Y. Liu (Oppo)]
JVET-M0274 CE3-related: Modified linear model derivation for CCLM modes [M. Wang,
K. Zhang, L. Zhang, H. Liu, J. Xu, S. Wang (Bytedance), J. Li, S. Wang,
W. Gao (Peking Univ.)]
JVET-M0641 Crosscheck of JVET-M0274 (CE3-related: Modified linear model derivation

for CCLM modes) [E. François (Technicolor)] [late]
Page: 194 Date Saved: 2019-03-172019-03-14

JVET-M0295 CE3-related: Harmonization of MPM list construction [B. Wang, S. Esenlik,
A. M. Kotra, H. Gao, J. Chen (Huawei)]
JVET-M0865 Crosscheck of JVET-M0295 (CE3-related: Harmonization of MPM list

construction) [L. Li (LGE)] [late]
JVET-M0324 CE3-related: Modified Chroma Intra Mode Coding [J. Park, B. Jeon

(SKKU)]
JVET-M0818 Crosscheck of JVET-M0324 (CE3-related: Modified Chroma Intra Mode

Coding) [L. Zhang (Bytedance)] [late]
JVET-M0356 CE3-related: simplified calculation for CCLM parameters derivation

[A. Filippov, X. Ma, V. Rufitskiy, H. Yang, J. Chen (Huawei)]
JVET-M0679 Crosscheck of JVET-M0356 (CE3-related: On CCLM simplification)

[F. Racapé (Technicolor)] [late]
JVET-M0723 Crosscheck of JVET-M0356 (CE3-related: simplified calculation for CCLM

parameters derivation) [G. Laroche, P. Onno (Canon)] [late]
JVET-M0358 CE3-related: disabling PDPC based on availability of reference samples

[V. Drugeon (Panasonic)]
JVET-M0629 Crosscheck of JVET-M0358 (CE3-related: disabling PDPC based on

availability of reference samples) [C. Rosewarne (Canon)] [late]
JVET-M0365 Non-CE3: modified PDPC for horizontal and vertical modes [A. Filippov,
JVET-M0804 Cross-check of contribution JVET-M0365 (Non-CE3: modified PDPC for

horizontal and vertical modes) [M. Schäfer, J. Pfaff (HHI)] [late]
JVET-M0383 Non-CE3: Table size reduction and bit width limitation for CCLM
implementation [P. Onno, C. Gisquet, G. Laroche, J. Taquet (Canon)]
Page: 195 Date Saved: 2019-03-172019-03-14

JVET-M0741 Crosscheck of JVET-M0383 (Non-CE3: Table size reduction and bit width
limitation for CCLM implementation) [A. Filippov, V. Rufitskiy (Huawei)]
[late]
JVET-M0384 Non-CE3: LM in the middle [C. Gisquet, G. Laroche, P. Onno, J. Taquet

(Canon)]
JVET-M0689 Crosscheck of JVET-M0384 (Non-CE3: LM in the middle) [J. Lainema

(Nokia)] [late]
JVET-M0391 CE3-related: Improvements on the Decoder-side Intra Mode Derivation

[M. Abdoli, E. Mora, T. Guionnet, M. Raulet (Ateme)]
JVET-M0651 Crosscheck of JVET-M0391 (CE3-related: Improvements on the Decoder-

side Intra Mode Derivation) [F. Henry, G. Clare (Orange)] [late]
JVET-M0392 Non-CE3: Extended Mode-Dependent Intra Smoothing [A. Filippov,

JVET-M0803 Cross-check of contribution JVET-M0392 (Non-CE3: Extended Mode-

Dependent Intra Smoothing) [M. Schäfer, J. Pfaff (HHI)] [late]
JVET-M0426 CE3-related: Improvement on the Intra Sub-Partitions Coding Mode [S. De-

Luxán-Hernández, V. George, J. Ma, T. Nguyen, H. Schwarz, D. Marpe,
T. Wiegand (HHI)]
JVET-M0458 Non-CE3: Combined-Hypothesis Intra-Prediction [G. Kulupana, A. Seixas

Dias, S. Blasi (BBC)]
JVET-M0613 Crosscheck of JVET-M0458 (Non-CE3: Combined-Hypothesis Intra-

Prediction) [S. De-Luxán-Hernández (HHI)] [late]
JVET-M0478 Non-CE3: PDPC extension [G. Van der Auwera, A. K. Ramasubramonian,

V. Seregin, M. Karczewicz (Qualcomm)]
Page: 196 Date Saved: 2019-03-172019-03-14

JVET-M0682 Crosscheck of JVET-M0478 (Non-CE3: PDPC extension) [F. Racapé
(Technicolor)] [late]
JVET-M0493 CE3-related: Simplified look-up table for CCLM mode [L. Zhao, X. Zhao,
JVET-M0624 Crosscheck of JVET-M0493 (CE3-related: Simplified look-up table for

CCLM mode) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0494 CE3-related: Modifications on MPM list generation [L. Zhao, X. Zhao, X. Li,

S. Liu (Tencent)]
JVET-M0745 Crosscheck of JVET-M0494 (CE3-related: Modifications on MPM list

generation) [J. Luo (InterDigital)] [late]
JVET-M0524 CE3/6-related: Unification of RQT-like transform partitioning for intra and

inter blocks [H. Egilmez, V. Seregin, A. Said, M. Karczewicz (Qualcomm)]
JVET-M0528 Non-CE3: A unified luma intra mode list construction process [F. Bossen,
K. Misra (Sharp Labs of America)]
JVET-M0626 Crosscheck of JVET-M0528 (Non-CE3: A unified luma intra mode list

construction process) [J. Yao (Fujitsu)] [late]
JVET-M0817 Crosscheck of JVET-M0528 (Non-CE3: A unified luma intra mode list

construction process) [L. Zhao, X. Zhao (Tencent)] [late]
JVET-M0653 Non-CE3: Harmonization of integer-slope directional modes without

interpolation filtering process [A. Filippov, V. Rufitskiy, J. Chen (Huawei)]
[late]
JVET-M0802 Cross-check of contribution JVET-M0653 (Non-CE3: Harmonization of

integer-slope directional modes without interpolation filtering process)
[M. Schäfer, J. Pfaff (HHI)] [late]
Page: 197 Date Saved: 2019-03-172019-03-14

JVET-M0783 CE3-related: Modification of MPM list order [J. Heo, J. Choi, J. Choi,
S. Yoo, L. Li, J. Lim, S. Kim (LGE)] [late]
JVET-M0799 Bit-width reduction of multiplier in CCLM derivation and prediction

JVET-M0844 Crosscheck of JVET-M0799 (Bit-width reduction of multiplier in CCLM

derivation and prediction) [Y. Kato, K. Abe, T. Toma (Panasonic)] [late]
JVET-M0815 CE3-related: Harmonization on MPM list [L. Li, J. Heo, J. Choi, S. Yoo,

J. Choi, J. Lim, S. Kim (LGE)] [late]
JVET-M0832 Non-CE3: On block size restrictions for PDPC with disabled linear filtering
for PDPC in the case of skew non-diagonal modes [A. Filippov, V. Rufitskiy,
J. Chen (Huawei), J. Lee, J. Kang (ETRI)] [late]
JVET-M0866 Crosscheck of JVET-M0832 (Non-CE3: On block size restrictions for PDPC

with disabled linear filtering for PDPC in the case of skew non-diagonal
modes) [L. Li (LGE)] [late]
6.4 CE4 related – Inter prediction and motion vector coding (51)
Contributions in this category were first considered discussed in a BoG JVET-M0843 unless otherwise
noted.
See also section 7, which discusses related complexity analysis and reduction proposals.
JVET-M0843 BoG report on CE4 related inter prediction and motion vector coding
contributions [K. Zhang]
This report was reviewed in Track B Tue 15 Jan 1215-1330 and 1435-1800.
Five BoG sessions were held, 1540 ~ 2020 on Jan. 11, 0900 ~ 1045 on Jan. 12, 1830 ~ 2000 on Jan. 12,
1945~2300 on Jan. 13, 2130~2230 on Jan. 14 for discussing 47 technical contributions in five categories:
1) Merge Modifications (19)
2) MMVD Modifications (12)
3) AMVP Modifications (7)
4) Weighted-Prediction Modifications (2)
5) Complexity Reduction (7)
Adoptions recommended by the BoG were as follows (see the notes for each individual contribution
regarding specifics for each document):
Normative changes
Page: 198 Date Saved: 2019-03-172019-03-14

 Complexity Reduction:
– JVET-M0193 CE4-related: Pairwise Average Candidate Reduction
– JVET-M0300 CE4-related: HMVP and parallel processing with tiles and tile groups
– JVET-M0117 CE4-related: On MVP candidate list generation for AMVP
 Bug Fix/Cleanup/Harmonization:
– JVET-M0436 AHG2: Regarding HMVP Table Size
– JVET-M0264 Non-CE4: Harmonization between HMVP and GBi
– JVET-M0068 Non-CE4: MMVD scaling fix
– JVET-M0171 CE4-related: MMVD cleanups
– JVET-M0111 AHG13: On bi-prediction with weighted averaging and weighted prediction
– JVET-M0479 Non-CE4: On clipping of scaled motion vectors
 Coding Efficiency:
– JVET-M0255 AHG11: MMVD without Fractional Distances for SCC
– JVET-M0444 CE4-related: Simplified symmetric MVD based on CE4.4.3
– JVET-M0502 CE4-related: Improved context for prediction mode flag
Proposals suggested for study in upcoming CE (not all of which were later endorsed):
 Merge-related
o Syntax modification
– JVET-M0069 Non-CE4: Syntax change of MMVD
– JVET-M0231 CE4-related: Regular merge flag coding
– JVET-M0359 Non-CE4: Modification of merge data syntax
– JVET-M0369 CE4-related: Syntax changes of merge data
It was noted in the Track B discussion that the benefit of some of the last three methods
is low, in particular if the separation of MMVD from merge (JVET-M0069) would be
implemented. Therefore, also combination of JVET-M0069 and each of the other three
should be tested.
o Merge list simplification
– JVET-M0405 CE4-related: Simplified merge candidate list for small blocks
– JVET-M0433 CE4-related: Constraint on GBi index inheritance in Merge Mode
 STMVP
– JVET-M0518 CE4-related: Supplemental results on STMVP design of CE4.2.3.a and
combination with methods of JVET-M0126 (CE4.1.2.a) and JVET-M0127
– JVET-M0713 CE4-related: simplification of CE4.2.2
 MMVD-related
From Track B discussion: This part should be combined with the Sub-CE on MMVD mode signalling
above, in particular combination with JVET-M0069 should be investigated.
Page: 199 Date Saved: 2019-03-172019-03-14
– JVET-M0206 CE4-related: MMVD improvements
– JVET-M0267 Non-CE4: Harmonization of MMVD and AMVR
– JVET-M0307 CE4-related: Candidates optimization on MMVD
– JVET-M0308 Non-CE4: MMVD simplification
– JVET-M0314 CE4-related: MMVD improving with signalling distance table
– JVET-M0315 Non-CE4: MMVD scaling simplification
– JVET-M0435 CE4-related: MMVD offset table signalling
 TMVP Storage Reduction
From dicussion in Track B: This sub-CE is not needed, as the JVET-M0512 solution was adopted.
– JVET-M0230 CE4-related: Temporal MV buffer reduction
– JVET-M0346 CE4-related: Non-square compression grid for temporal motion data storage
– JVET-M0512 Non-CE4: On Temporal Motion Buffer Compression
Open questions reported by the BoG (see the notes for each contribution):
 Depending on CE decision
o Pending on JVET-M0170 (which was adopted)
– JVET-M0272 CE4-related: Restrictions on History-based Motion Vector Prediction
– JVET-M0345 CE4-related: Remove redundancy between TMVP and ATMVP
– JVET-M0473 Simplified HMVP
– JVET-M0350 CE4-related: Quadtree-based Merge Estimation Region for VVC
o Related to JVET-M0281
– JVET-M0081 Non-CE4: Simplification of AMVP list generation in AMVR
o Related to JVET-M0403
– JVET-M0422 CE4-related: Simplified MVD coding
– JVET-M0406 CE2/4-related: Unified merge list size for block and sub-block merge
modes
– JVET-M0661 AHG-13: On Merge List Size
– JVET-M0330 CE4-related: Simplification of MMVD scheme
JVET-M0067 Non-CE4: Weighted prediction with BDOF and bi-prediction with CU

weights harmonization [T. Hashimoto, T. Chujoh, T. Ikai, E. Sasaki (Sharp)]
JVET-M0394 Crosscheck of JVET-M0067 (Non-CE4: Weighted prediction with BDOF

and bi-prediction with CU weights harmonization) [P. Bordes (Technicolor)]
[late]
Page: 200 Date Saved: 2019-03-172019-03-14

JVET-M0068 Non-CE4: MMVD scaling fix [E. Sasaki, T. Ikai (Sharp)]
Notes from BoG report review: -0.02%/0.00%, remove redundant scaling, makes it identical with regular
MV scaling.
JVET-M0509 Crosscheck of JVET-M0068 (Non-CE4: MMVD scaling fix) [X. Chen

(HiSilicon)] [late]
JVET-M0069 Non-CE4: Syntax change of MMVD [E. Sasaki, T. Chujoh, T. Ikai (Sharp)]

Notes from BoG report review: -0.11% (102%, 100%)/-0.23% (102%, 100%). Decouples MMVD mode
and merge mode. The proposal signals MMVD as separate mode, which appears desirable for a more
clean design. There are also additional checks which might contribute to the improvement of
compression, but also increase encoder runtime. Results should also be provided which implement the
syntax change without increasing number of encoder RD checks.
JVET-M0554 Crosscheck of JVET-M0069 (Non-CE4: Syntax change of MMVD) [G. Li

(Tencent)] [late]
JVET-M0585 Crosscheck of JVET-M0069 (Non-CE4: Syntax change of MMVD)

[K. Zhang (Bytedance)] [late]
JVET-M0081 Non-CE4: Simplification of AMVP list generation in AMVR [Y. Kato,

K. Abe, T. Toma (Panasonic)]
Notes from BoG report discussion: 0.01% (101%, 99%)/0.03% (101%, 99%), Remove all intermediate
rounding for AMVR mode, only keep the final rounding
From discussion in Track B: The unification of where the rounding is done was achieved by adoption of
JVET-M0281, no need to change that again.
JVET-M0807 Cross-check result of JVET-M0081 (Non-CE4: Simplification of AMVP list

generation in AMVR) [K. Kawamura, S. Naito (KDDI)] [late]
JVET-M0111 AHG13: On bi-prediction with weighted averaging and weighted prediction

[Y. Ye, J. Chen, M. Yang (Alibaba), P. Bordes, E. François (Technicolor)]
Notes from BoG report review: The same syntax design to support WP is also proposed in JVET-M0067.
It is noted that inclusion of WP was decided at the 12th meeting, but had not yet been implemented in the
text (although the software had it). Furthermore, it had been decided to disallow combination of GBi and
WP. This was implemented by disabling GBi signalling whenever WP is enabled for the current bi-
predicted block.
JVET-M0117 CE4-related: On MVP candidate list generation for AMVP [R. Yu, D. Liu,
K. Andersson, P. Wennersten, J. Ström, R. Sjöberg (Ericsson)]
Notes from BoG report review: 0.01%/0.01%, pruning number 10->1, MV rounding 13->3.
Page: 201 Date Saved: 2019-03-172019-03-14

JVET-M0763 Cross-check of JVET-M0117 [H. Jang, J. Nam, S.-H. Kim, J. Lim (LGE)]
[late]
JVET-M0127 CE4-related: Modification on Merge List [Y. Han, W.-J. Chien,

D. Rusanovskyy, Y.-H. Chao, C.-C. Chen, H. Wang, H. Huang, C.-H. Hung,
Y. Zhang, M. Karczewicz (Qualcomm)]
JVET-M0532 Crosscheck of JVET-M0127 (CE4-related: Modification on Merge List)

[H. Dou, Z. Deng, L. Xu (Intel)] [late]
JVET-M0171 CE4-related: MMVD cleanups [C.-Y. Lai, T.-D. Chuang, Y.-L. Hsiao, C.-Y.
Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
Notes from BoG report review: -0.03%/0.02%, JVET-M0068+Forbid 4*4 bi + align SW with WD.
JVET-M0757 Cross-check of JVET-M0171 (CE4-related: MMVD cleanups) [B.-J. Fuh, C.-

H. Yau, C.-C. Lin (ITRI)] [late]
JVET-M0193 CE4-related: Pairwise Average Candidate Reduction [A. Tamse,

M. W. Park, K. Choi (Samsung)]
Notes from BoG report review: 0.01%/0.00% loss in RA/LB, reduce pairwise candidate from 6 to 1
JVET-M0551 Crosscheck of JVET-M0193 (CE4-related: Pairwise average candidate

reduction) [S.-T. Hsiang (MediaTek)] [late]
JVET-M0206 CE4-related: MMVD improvements [S. Jeong, M. W. Park, K. Choi

(Samsung)]
Notes from BoG report review: -0.10% (102%, 103%)/0.01% (100%, 101%). Change the binarization
method for MMVD distance index.
JVET-M0595 Crosscheck of JVET-M0206 (CE4-related: MMVD improvements)

[T. Hashimoto, T. Ikai (Sharp)] [late]
JVET-M0220 Non-CE4: Subjective quality analysis of non-sub-block ATMVP [Y.-H Chao,

W.-J Chien, M. Karczewicz (Qualcomm)]
JVET-M0230 CE4-related: Temporal MV buffer reduction [Y.-W. Chen, X. Wang (Kwai

Inc.)]
Notes from BoG report review: 0.03% (100%, 100%)/0.09% (100%, 99%). Lower MV bits.
This is a relevant reduction of buffer. However, it is suggested that instead of using scaling (1/16 to 1/4),
simple clipping from 18 to 16 bits should be investigated as well.
Page: 202 Date Saved: 2019-03-172019-03-14

In this context, it is mentioned in the Track B discussion if it might be useful to define some restriction of
MVs, just to prevent for some future application with extremely large picture sizes valid ranges might be
exceeded.
JVET-M0591 Crosscheck of JVET-M0230 (Non-CE4: Temporal MV buffer reduction)

[T. Zhou, T. Ikai (Sharp)] [late]
JVET-M0231 CE4-related: Regular merge flag coding [X. Wang, Y.-W. Chen (Kwai Inc.)]
Notes from BoG report review: 0.00% (100%, 96%)/-0.23% (102%, 92%). The codeword length for
regular merge mode becomes the shortest one.
JVET-M0559 Crosscheck of JVET-M0231 (Non-CE4: Regular merge flag coding) [H. Lee,

S.-C. Lim, J. Lee, J. Kang (ETRI)] [late]
JVET-M0845 Crosscheck of JVET-M0231 (Non-CE4: Regular merge flag coding)

JVET-M0255 AHG11: MMVD without Fractional Distances for SCC [H. Liu, L. Zhang,
In the merge with motion vector difference (MMVD) mode, fractional distances including 1/4-pel and
1/2-pel are included in the distance table. However, fractional distances maybe inefficient for screen
contents. To address this issue, this contribution proposes to disable fraction distances adaptively in
MMVD mode. When fractional distances are disabled, distances in the default table are all multiplied by
4. Simulation results reportedly show 0.76% and 1.66% luma BD-rate saving on SCC sequences in
Random Access configuration and Low Delay B configuration respectively. When CPR is off, 1.58% and
2.74% luma BD-rate saving on SCC sequences are achieved in Random Access configuration and Low
Delay B configuration respectively.
More related to MMVD (not SCC). A similar approach was investigated in CE 4.4.5b (see remarks there),
where switching to an integer table was proposed for UHD resolution.
This contribution was initially discussed Friday 11 January afternoon in Track B; discussion was then
moved to CE4 BoG (see JVET-M0843).
Notes from BoG report review: -1.58%/-2.74% in SCC (TGM class) tests with CPR off, -0.76%/-1.66%
with CPR on, one slice level flag indicates whether distance is full-pel. It is further pointed out in the
Track B dicussion that it was demonstrated to provide benefit for UHD when such an option is available
(see under CE 4.4.5). A version shall be used that just multiplies the current MVD distances by 4.
JVET-M0726 Cross-check of JVET-M0255 (AHG11: MMVD without Fractional Distances

for SCC) [A. Karabutov (Huawei)] [late]
JVET-M0264 Non-CE4: Harmonization between HMVP and GBi [J. Li, S. Wang, W. Gao
(Peking Univ.), L. Zhang, K. Zhang, H. Liu, J. Xu (Bytedance), X. Xiu,
D. Luo, Y. He (InterDigital)]
Notes from BoG report review: Harmonization such that the GBi weight is also stored in HMVP. Can be
seen as a bug fix – gives very small improvement -0.01%/-0.01%.
Page: 203 Date Saved: 2019-03-172019-03-14

JVET-M0574 Crosscheck of JVET-M0264 (Non-CE4: Harmonization between HMVP and
GBi) [J. Zhao (LGE)] [late]
JVET-M0267 Non-CE4: Harmonization of MMVD and AMVR [K. Zhang, L. Zhang,

H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
Notes from BoG report review: -0.14% (100%, 100%)/0.00% (100%, 100%). Distance based on signalled
AMVR
From Track B discussion: It should be clarified how this relates to the adoption of JVET-M0255, and
different combinations tested (e.g. enabling only one, different ways of interpreting them together).
JVET-M0599 Crosscheck of JVET-M0267 (Non-CE4: Harmonization of MMVD and

AMVR) [T. Hashimoto, T. Ikai (Sharp)] [late]
JVET-M0272 CE4-related: Restrictions on History-based Motion Vector Prediction

[L. Zhang, K. Zhang, H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
Notes from BoG report review: 0.00% (101%, 101%)/0.02% (100%, 97%), disable HMVP table update
for 4*4 block; disable using virtual merge candidate for HMVP update; HMVP candidate is only pruned
to the first two spatial/temporal merge candidates
From Track B: The first aspect was not relevant after adoption of JVET-M0170. The third aspect was not
relevant due to the CE4.1.1/2 decision which solved the problem of reducing pruning steps. The
additional benefit of the second aspect standalone was not obvious.
JVET-M0286 Non-CE4: Simplifications for triangular prediction mode [T. Solovyev,

S. Esenlik, S. Ikonin, J. Chen (Huawei)]
JVET-M0793 Crosscheck of JVET-M0286 (Non-CE4: Simplifications for Triangular

Prediction Mode) [C.-C. Chen, W.-J. Chien (Qualcomm)] [late]
JVET-M0300 CE4-related: HMVP and parallel processing with tiles and tile groups
[A. M. Kotra, J. Chen, B. Wang, S. Esenlik, H. Gao (Huawei)]
Notes from BoG report review: This resets the history table at the beginning of each tile, however under
the assumption that tile boundaries coincide with CTU boundaries which may not be the case with
flexible tile concepts. It was suggested that proponents should communicate with tile experts and see
whether there is a misaligment with concepts that will be put into VVC draft 4). It was later confirmed by
the text editor that only a small (kind of editorial) change would be required. (might be that depending on
further discussion on tile concepts; some more alignments may be necessary).
JVET-M0307 CE4-related: Candidates optimization on MMVD [N. Park, H. Jang, J. Nam,

Notes from BoG report review: -0.08% (96%, 99%)/-0.02% (99%, 101%). Reduces distance candidates
and introduces distance refinement.
Page: 204 Date Saved: 2019-03-172019-03-14

JVET-M0621 Crosscheck of JVET-M0307 (CE4-related: Candidates optimization on
MMVD) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0779 Crosscheck of JVET-M0307 (CE4-related: Candidates optimization on

MMVD) [T. Hashimoto, T. Ikai (Sharp)] [late]
JVET-M0308 Non-CE4: MMVD simplification [X. Chen, J. Zheng (HiSilicon)]

Notes from BoG report review: -0.01% (97%, 98%)/0.08% (100%, 99%). Removes MVD scaling in
MMVD.
From Track B: Not worthwhile, not in CE.
JVET-M0592 Crosscheck of JVET-M0308 (Non-CE4: MMVD simplification)

JVET-M0315 Non-CE4: MMVD scaling simplification [J. Li, R.-L. Liao, C. S. Lim

(Panasonic)]
Notes from BoG report review: Same as JVET-M0308, and add one SPS flag.
From Track B: Not worthwhile, not in CE),
JVET-M0794 Crosscheck of JVET-M0315 (Non-CE4: MMVD Scaling Simplification) [C.-

C. Chen, W.-J. Chien (Qualcomm)] [late]
JVET-M0314 CE4-related: MMVD improving with signalling distance table [J. Li, R.-L.
Notes from BoG report review: -0.20% (103%, 97%)/0.02% (104%, 100%). Signalling the distance table
in the slice header.
From Track B: Part of the gain comes from the encoder optimization “4.4.5*”. So, the benefit of
signalling as such seems to be low, in particular considering the increased encoder runtime. Not
worthwhile, not in CE.
JVET-M0597 Crosscheck of JVET-M0314 (CE4-related: MMVD improving with

signalling distance table) [T. Hashimoto, T. Ikai (Sharp)] [late]
JVET-M0315 Non-CE4: MMVD scaling simplification [J. Li, R.-L. Liao, C. S. Lim

(Panasonic)]
JVET-M0794 Crosscheck of JVET-M0315 (Non-CE4: MMVD Scaling Simplification) [C.-

C. Chen, W.-J. Chien (Qualcomm)] [late]
Page: 205 Date Saved: 2019-03-172019-03-14

JVET-M0330 CE4-related: Simplification of MMVD scheme [L. Xu, F. Chen, L. Wang
(Hikvision)]
Notes from the BoG report discussion: 0.25% (93%, 98%)/0.07% (98%, 100%), reduce MMVD base
candidates to 1; -0.06% (100%, 101%)/-0.12% (101%, 100%) reorder merge list construction based on
block dimensions; Combined: 0.07% (94%, 98%)/-0.11% (98%, 100%).
From discussion in Track B: Reduction of MMVD candidates gives loss and is mainly at benefit of
encoder. At the last meeting, when MMVD was adopted, different numbers of candidates were
considered and it was finally decided to use two, based performance/complexizy tradeoff. As the gap
between using one and two candidates may have become smaller, it could be worthwhile to consider this
aspect again on top of VTM4. Test this as part of the MMVD sub-CE, in combination with other
proposals.
Changing the sequence of candidates based on block shape introduces some irregularity in merge list
construction, which is not desirable (the same proposal was investigated in an earlier CE but not
considered).
JVET-M0590 Crosscheck of JVET-M0330 (CE4-related: Simplification of candidate list

derivation for MMVD mode) [T. Hashimoto, T. Ikai (Sharp)] [late]
JVET-M0345 CE4-related: Remove redundancy between TMVP and ATMVP [S. H. Wang

(Peking Univ.), X. Zheng (DJI), S. S. Wang, S. W. Ma (Peking Univ.)]
Notes from BoG report review: -0.04% (100%, 100%)/0.00% (101%, 102%), Skip TMVP process in
merge mode when CU size is equal to 8x8 or W=4 or H=4
From follow-up in Track B: The case of 4x4 is no longer relevant after adoption of JVET-M0170. This
proposal would modify the merge list construction for cases for 8x8, 4xN, Nx4, N!=4. This introduces
some irregularity, has only small gain, and is not critical case of processing. Put in CE.
JVET-M0754 Cross-check of JVET-M0345: CE4-related: Remove redundancy between

TMVP and ATMVP [S. Bandyopadhyay (InterDigital)] [late]
JVET-M0346 CE4-related: Non-square compression grid for temporal motion data storage
[S. H. Wang (Peking Univ.), X. Zheng (DJI), S. S. Wang, S. W. Ma (Peking
Univ.)]
Notes from BoG report review: 0.06% (100%, 100%)/ 0.23% (100%, 100%). MV stored in grid.
JVET-M0348 CE4-related: Improvement on 4x4 bi-prediction [X. W. Meng (Peking Univ.),

X. Zheng (DJI), S. S. Wang, S. W. Ma (Peking Univ.)]
JVET-M0809 Crosscheck of JVET-M0348: CE4-related: Further reducing VVC memory

bandwidth worst case by combining 4x4/4x8/8x4 bi-prediction with AMVR
[L. Pham Van, W.-J. Chien, M. Karczewicz (Qualcomm)] [late]
JVET-M0350 CE4-related: Quadtree-based Merge Estimation Region for VVC [T. L. Fu

(Peking Univ.), X. Zheng (DJI), S. S Wang, S. W. Ma (Peking Univ.)]
Notes from BoG report review: 0.49% (94%, 90%)/0.49% (93%, 91%)
Page: 206 Date Saved: 2019-03-172019-03-14

In the follow-up discussion in Track B, it was asked whether there would be much difference if it was
implemented as encoder-only approach? It is probably good for some encoder runtime reduction, but has
also quite some loss, so we would likely not adopt it or put it in CTC.
JVET-M0583 Crosscheck of JVET-M0350 (CE4-related: Quadtree-based Merge

Estimation Region for VVC) [G. Li (Tencent)] [late]
JVET-M0359 Non-CE4: Modification of merge data syntax [G. Ko, D. Kim, J. Jung,

J. Son, J. Kwak (Wilus)]
Notes from BoG report review: -0.06% (100%, 101%)/-0.17% (100%, 101%). MMVD flag is signalled
when merge_idx < 2.
JVET-M0789 Crosscheck of JVET-M0359 (Non-CE4: Modification of merge data syntax)

[B. Lee (Chosun Univ.)] [late]
JVET-M0369 CE4-related: Syntax changes of merge data [Y. Ahn, D. Sim (Digital

Insights)] [late]
Notes from BoG report review: -0.07% (100%, 101%)/-0.14% (101%, 101%). Re-arrange order of the
syntax elements for varieties of merge modes.
JVET-M0750 Cross-check of JVET-M0369 (CE4-related: Syntax changes of merge data)

[S.-C. Lim, H. Lee, J. Lee, J. Kang (ETRI)] [late]
JVET-M0405 CE4-related: Simplified merge candidate list for small blocks [X. Xu, X. Li,
S. Liu (Tencent)]
Notes from BoG report review: 0.09% (106%, 104%)/0.14% (108%, 107%). Only keep one
spatial/temporal candidate without pruning when W*H <=32.
From Track B dscussion: the loss does not justify the simplification, as there is no real complexity
problem at the decoder. No value was seen for investigating this in a CE.
JVET-M0659 Crosscheck of JVET-M0405 (CE4-related: Simplified merge candidate list

for small blocks) [K. Choi (Samsung)] [late]
[X. Xu, X. Li, S. Liu (Tencent)]
Notes from BoG report discussion: 0.06% (101%, 101%)/ 0.10% (100%, 103%), unified merge list size =
5; -0.02% (101%, 101%)/ 0.00% (100%, 103%), merge list size = 6
From the discussion in Track B: VTM3 has the choice of signalling merge list size. This is inherited from
HEVC, where the design choice was to give an encoder the option to check less merge candidate,
however it imposes some burden on decoders, as the parsing and signalling of merge candidates depends
on the selected maximum number. It was discussed whether such encoder choice is still relevant for
VVC.
Page: 207 Date Saved: 2019-03-172019-03-14

It was further questioned whether unification of the merge list sizes is a relevant unification, as the merge
list construction is different for regular blocks and subblocks, anyway. Even the coding and the context
definitions are different.
No action was taken on JVET-M0406 and JVET-M0661.
JVET-M0422 CE4-related: Simplified MVD coding [X. Li, X. Xu, X. Zhao, S. Liu

(Tencent)]
Notes from BoG report review: 0.03% (100%, 100%)/0.02% (99%, 103%), bypass code coding
abs_mvd_greater1_flag
From discussion in Track B: Saving context coded bins in MV coding does not have high relevance, as it
hardly influences the worst case of CABAC throughput. Getting it at expense of loss is not desirable.
JVET-M0440 Crosscheck of JVET-M0422 (CE4-related: Simplified MVD coding)

[L. Zhang (Bytedance)] [late]
JVET-M0433 CE4-related: Constraint on GBi index inheritance in Merge Mode [G. Li,

X. Xu, X. Li, S. Liu (Tencent)]
Notes from BoG review: 0.03% (101%, 101%)/0.03% (102%, 102%). Remove GBI inheritance for affine
merge and MMVD.
From Track B discussion: The benefit is rather small, only 3 out of 84 bits are saved, and it generates a
small loss. No value was seen for investigating this in a CE.
JVET-M0700 Cross-check of JVET-M0433 (CE4-related: Constraint on GBi index

inheritance in Merge Mode [J. Zhao (LGE)]
JVET-M0435 CE4-related: MMVD offset table signalling [G. Li, X. Xu, X. Li, S. Liu
(Tencent)]
Notes from BoG report review: -0.19% (100%, 99%)/0.01% (103%, 97%). Like JVET-M0314 but with
differential coding
The same comment applies as above for JVET-M0314.
JVET-M0623 Crosscheck of JVET-M0435 (CE4-related: MMVD offset table signalling)

[Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0436 AHG2: Regarding HMVP Table Size [J. Zhao, S. Kim (LGE)]

Notes from BoG report review: Reducing number from 6 to 5. As the entry 6 is never used in the current
spec, this is an editorial issue..
JVET-M0562 Cross-check of JVET-M0436: AHG2: Regarding HMVP Table Size

[S. Bandyopadhyay (InterDigital)] [late]
JVET-M0437 Non-CE4: Size constraint on MMVD [J. Zhao, S. Kim (LGE)]
Page: 208 Date Saved: 2019-03-172019-03-14

JVET-M0555 Crosscheck of JVET-M0437 (Non-CE4: Size constraint on MMVD) [G. Li
(Tencent)] [late]
JVET-M0444 CE4-related: Simplified symmetric MVD based on CE4.4.3 [J. Luo, Y. He

(InterDigital)]
Notes from BoG report review: RA -0.33%, encoder is improved and BDOF is disabled on SMVD. 4.4.3
had a gain of 0.16%, but runtime increase of 5%, which is still the case here. By disabling BDOF, some
run time is saved, but then more encoder checks are done on the SMVD, which is where the gain comes
from.
JVET-M0721 Crosscheck of JVET-M0444 (CE4-related: Simplified symmetric MVD based

on CE4.4.3) [H. Chen, T. Solovyev (Huawei)] [late]
JVET-M0448 CE4-related: Triangle merge index signalling [M. Xu, X. Li, S. Liu

(Tencent)]
JVET-M0836 Crosscheck of JVET-M0448 (CE4-related: Triangle merge index signalling)

[X. Wang (Kwai Inc.)] [late]
JVET-M0473 Simplified HMVP [W. Zhu, A. Segall (Sharp)]

Notes from BoG report review: 0.02% (100%, 101%)/0.02% (100%, 100%), HMVP table is updated at
16x16 grid, Remove reference checking in merge list pruning on HMVP candidates
From follow-up in Track B: Is not in a critical path and has a slight loss – not worthwhile to consider.
JVET-M0778 Crosscheck of JVET-M0473: Simplified HMVP [C.-H. Hung, W.-J. Chien

(Qualcomm)] [late]
JVET-M0479 Non-CE4: On clipping of scaled motion vectors [K. Misra, F. Bossen

(Sharp)]
Notes from BoG report review: 0.00%/0.00%, always clip MVs to 18 bits.
JVET-M0777 Crosscheck of JVET-M0479: Non-CE4: On clipping of scaled motion vectors

[C.-H. Hung, W.-J. Chien (Qualcomm)] [late]
JVET-M0484 Non-CE4: Line buffer size reduction method for generalized bi prediction
[T. Solovyev, H. Gao, S. Esenlik, S. Ikonin, J. Chen (Huawei)]
JVET-M0819 Crosscheck of JVET-M0484 (Non-CE4: Line buffer size reduction method

for generalized bi prediction) [A. Robert (Technicolor)] [late]
Page: 209 Date Saved: 2019-03-172019-03-14

JVET-M0519 Non-CE: Context modeling for coding the prediction mode flag [S.-T.
Hsiang, S.-M. Lei (MediaTek)]
JVET-M0739 Crosscheck of JVET-M0519 (Non-CE: Context modeling for coding the

prediction mode flag) [A. Tamse (Samsung)] [late]
JVET-M0502 CE4-related: Improved context for prediction mode flag [X. Zhao, X. Li,
S. Liu (Tencent)]
Notes from BoG report review: -0.09%/-0.02%, add one context to code pred_mode_flag, no change of
run time..
JVET-M0657 Crosscheck of JVET-M0502 (CE4-related: Improved context for prediction

mode flag) [K. Choi (Samsung)] [late]
JVET-M0513 CE7-related: Context modeling of pred_mode_flag [Y. Zhao, S. Hong,

JVET-M0882 Cross check of CE7-related: Context modeling of pred_mode_flag (JVET-

M0513) [M. W. Park, H. Yang (Samsung)] [late]
JVET-M0507 CE4-related: Hybrid Merge Estimation Region [H. Wang, V. Seregin, W.-J.

Chien, T. Hsieh, Y. Han, M. Karczewicz (Qualcomm)]
Notes from the BoG report review: JVET-M0507 has two aspects, where the aspect of removing the
clipping for the shared merge list might also be beneficial on top of JVET-M0170. It is reported to come
at no coding loss. The proponents of JVET-M0507 discussed with proponents of JVET-M0170 that the
check for one of the subbocks being outside of the picture could be removed, whereas another check
whether the CU center is still inside needed to be added, to make it consistent with other boundary check
conditions in VVC. Proponents of JVET-M0170 were to make an update on this aspect.
JVET-M0712 Crosscheck of JVET-M0507 (CE4-related: Hybrid Merge Estimation

Region) [F. Chen, L. Wang (Hikvision)] [late]
JVET-M0837 Crosscheck of JVET-M0507 (CE4-related: Hybrid Merge Estimation

Region) [X. Wang (Kwai Inc.)] [late]
JVET-M0512 Non-CE4: On Temporal Motion Buffer Compression [F. Bossen, K. Misra,

A. Segall (Sharp Labs of America)]
Notes from BoG report review: 0.00% (99%, 100%)/0.02% (100%, 102%). Remove POC storage and
store MV in a converted way.
From subsequent discussion in Track B:
Page: 210 Date Saved: 2019-03-172019-03-14

This approach stores the MV 8x8 grid in a floating point format, 6 bit mantissa (incl. sign) and 4 bit
exponent. This has been cross-checked, text is available, and it provides significant reduction of MV
memory. It comes with practically no loss and is well understood.
Decision: Adopt JVET-M0512 second aspect as described above.
JVET-M0764 Cross-check of JVET-M0512 [H. Jang, J. Nam, S.-H. Kim, J. Lim (LGE)]

[late]
JVET-M0518 CE4-related: Supplemental results on STMVP design of CE4.2.3.a and

combination with methods of JVET-M0127 (CE4.1.2.a) and JVET-M0127
[D. Rusanovskyy, Y.-H. Chao, Y. Han, W.-J. Chien, M. Karczewicz
(Qualcomm)]
Notes from BoG report review: -0.10% (100%, 100%)/0.06% (101%, 99%).
It was noted in the discussion in Track B that this would definitely not be worthwhile to consider when
there is still loss in LB. It might be better withdrawn if this is still the case by the time of submitting the
CE software.
JVET-M0820 Crosscheck of JVET- M0518 (CE4-related: Supplemental results on STMVP

design of CE4.2.3.a and combination with methods of JVET-M0127
(CE4.1.2.a) and JVET-M0127) [T. Y. Zhou, T. Ikai (Sharp)] [late]
JVET-M0625 Crosscheck of JVET-M0518 (CE4-related: Supplemental results on STMVP

design of CE4.2.3.a and combination with methods of JVET-M0127
(CE4.1.2.a) and JVET-M0127) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0627 Non-CE4: Supplementary results of combined solution of JVET-M0255,

JVET-M0267 and JVET-M0069 [H. Liu, K. Zhang, L. Zhang (Bytedance),
E. Sasaki, T. Chujoh, T. Ikai (Sharp)] [late]
JVET-M0895 Cross-check result of JVET-M0627 (Non-CE4: Supplementary results of

combined solution of JVET-M0255, JVET-M0267 and JVET-M0069)
JVET-M0661 AhG-13: On Merge List Size [X. Li, X. Xu, S. Liu (Tencent)] [late]
Notes from BoG report discussion: the CTC uses a unified merge list size = 5.
From the discussion in Track B: VTM3 has the choice of signalling merge list size. This is inherited from
on the selected maximum number. It was discussed whether such encoder choice is still relevant for
VVC.
Page: 211 Date Saved: 2019-03-172019-03-14

No action was taken on JVET-M0406 and JVET-M0661.
JVET-M0713 CE4-related: simplification of CE4.2.2 [F. Le Léannec, A. Robert, T. Poirier

(Technicolor)] [late]
Notes from BoG report review: -0.11% (100%, 100%)/0.00% (107%, 110%)
It was noted in the discussion in Track B that CE4.2.2 disabled the method in LD, as it reportedly gave
loss. Therefore, the same statement would apply as for JVET-M0518.
JVET-M0786 Crosscheck of JVET-M0713 (CE4-related: simplification of CE4.2.2) [Y.-H.

Chao (Qualcomm)] [late]
JVET-M0823 CE4-related: Encoder optimization of CE4.4.5 [J. Li, R.-L. Liao, C. S. Lim

(Panasonic)] [late]
This contribution provides the simulation results of encoder optimization algorithm used in JVET-M0312
CE4: MMVD improvement (test 4.4.5). Experimental results show 0.11% (RA) and 0.08% (LDB) luma
BD-rate reduction with 3-5% increase in encoding timing time and no impact on decoding time.
Reviewed in Track B Thu 17 Jan 1600 (JRO), as this seemed to be the current best known encoder for
MMVD.
Decision (SW): Adopt JVET-M0823, and also use in CTC.
JVET-M0833 Crosscheck of JVET-M0823 (CE4-related: Encoder optimization of CE4.4.5)

[C.-C. Chen, W.-J. Chien (Qualcomm)] [late]
JVET-M0854 CE4-related: Combination of CE4.4.4a and CE4.4.5b [T. Hashimoto,

E. Sasaki, T. Ikai (Sharp), J. Li, R.-L. Liao, C. S. Lim (Panasonic)] [late]
This contribution reports results of combining CE4.4.4.a and CE4.4.5.b. It shows 0.2% B-D rate
reduction with 100% encoding time and 100% decoding time in RA condition and 0% B-D rate reduction
with 100% encoding time and 100% decoding time in LDB condition, compared to a VTM3+4.4.5*
anchor.
Reviewed in Track B Thu 17 Jan 1600.
The aspect of 4.4.5.b was already resolved by adoption of JVET-M0255 (via explicit signalling). Aspect
of 4.4.4a should be investigated in ongoing CE.
JVET-M0861 Crosscheck of JVET-M0854: (CE4-related: Combination of CE4.4.4a and

CE4.4.5b) [V. Seregin (Qualcomm)] [late]
6.5 CE5 related – Arithmetic coding engine (5)

Page: 212 Date Saved: 2019-03-172019-03-14

JVET-M0089 Non-CE5: CABAC skip mode for super low delay [K. Abe, T. Toma
(Panasonic)]
Presented Thu 7:40pm. Chaired by FJB
Because CABAC requires sequential processing, the number of processing cycles of CABAC may
fluctuate due to the change in the local bit amount. Some systems introduce a kind of buffering to avoid
it, but it would be a cause of delay especially for the use case of high bit rate with low performance
hardware. This contribution proposes to introduce CABAC skip mode which directly outputs binarized
bits as a bitstream without CABAC processing. This mode decreases the coding efficiency, but it is very
useful for the super low delay use cases which need to guarantee several milliseconds delay. Simulation
results reportedly show that the proposed mode can guarantee the fixed delay with the cost of 23%, 25%,
and 30% bits increasing for AI, RA, and LDB on VTM-3.0.
Question about HRD assumptions. It was mentioned that there may not be a problem to be solved here.
This could be further discussed in AHG16 ( implementation complexity ) or AHG14 (progressive intra
refresh).
No action at this time.
JVET-M0344 Crosscheck of JVET-M0089 (Non-CE5: CABAC skip mode for super low
delay) [R. Hashimoto (Renesas)]
JVET-M0196 CE5-related: Counter-based multi-CABAC for partial context models

[Y. Piao, K. Choi (Samsung)]
Detailed presentation of this was not requested by the presenter, due to actions taken earlier at the
meeting.
JVET-M0545 Crosscheck of JVET-M0196 (CE5-related: Counter-based multi-CABAC for

partial context models) [J. Dong (Qualcomm)] [late]
JVET-M0389 CE5-related: Minor optimizations for increasing the throughput of CE5.1.5

and CE5.1.6 [H. Kirchhoffer, C. Bartnik, P. Haase, T. Hinz, S. Matlage,
B. Stabernack, J. Stegemann, D. Marpe, H. Schwarz, T. Wiegand (HHI)]
meeting.
JVET-M0395 CE5-related: Alternative implementation of CABAC range sub-interval

derivation for CE5.1.5, CE5.1.6 and CE5.1.7 [P. Haase, H. Kirchhoffer,
S. Matlage, H. Schwarz, D. Marpe, T. Wiegand (HHI)]
meeting.
JVET-M0772 CE5-related: Clean up of the context model initialization process for CE5.1.5
and CE5.1.6 [J. Stegemann, H. Kirchhoffer, D. Marpe, H. Schwarz,
T. Wiegand (HHI)] [late]
meeting.
Page: 213 Date Saved: 2019-03-172019-03-14

6.6 CE6 related – Transforms and transform signalling (25)
Contributions in this category were discussed XXday X Jan. XXXX–XXXX (chaired by XXX)reviewed
in the BoG reported in JVET-M0877.
Contribution JVET-M0538 had been discussed in the CE report but was not part of the CE. See the CE report for
some discussion of thisthat.
JVET-M0877 BoG report on CE6 related transforms and transform signalling

contributions [X. Zhao (Tencent]
This BoG report was reviewed in Track A Tuesday 15 January at 1700 and Wednesday 16 January 1300-
1400 (GJS)
The BoG met on Sunday January 13rd from 15:35 to 21:24 and Monday 14th from 20:30 to 22:10.
This BoG was mandated to review the CE6 related contributions of the 13 th JVET meeting. Totally 25
contributions were reviewed, which are categorized as follows,
1. Complexity reduction (14 proposals)
2. Transform skip (6 proposals)
3. Transform selection (2 proposals)
4. Others (5 proposals)
The following BoG results were reviewed:
 Recommended adoptions:
o Context reduction (6 contexts reduced to 1 context) of MTS flag signalling (JVET-M0347).
In Track A review, this was considered too small an optimization to bother with at this stage.
It should be kept in mind when finalizing the spec as an opportunity for cleanup.
o Bug-fix for mismatch between spec text and software related to CBF signalling (JVET-
M0361, bug-fix on spec text). Decision: Agreed in Track A review – this was just an error in
drafting the text.
 CE tests proposed by the BoG:
o Modified transform selection
 Transform selection for chroma components (JVET-M0480, JVET-M0501). We
currently only have MTS for luma. In the Track A review, the potential improvement
seemed small and this would involve needing to support multiple chroma transforms
for chroma, so no CE was planned for this.
 Transform selection to multi-hypothesis inter-intra mode (JVET-M0482). This
proposal is to reduce the number of transform candidates in that mode. This would
introduce a design inconsistency and has no benefit in coding efficiency. A non-
normative approach has not yet been tried. No CE was planned for this.
 Unification between MTS and transform skip (JVET-M0501). This reportedly shows
2.8% gain on Class F. In the Track A review, it was agreed to establish a CE for this.
 Open issues:
o Complexity reduction of 32-length DST-7/DCT-8
 With a zero-out approach (JVET-M0297, JVET-M0046) (0.1% penalty for AI,
0.04% for RA).
 Using a two-stage transform scheme
Page: 214 Date Saved: 2019-03-172019-03-14

 Track A Decision: Adopt JVET-M0297 Test 2.
 No CE.
o MTS simplifications with modified transform candidates and signalling
 BOG recommended revisiting in Track B to discuss whether a CE study is to be set
up for related contributions (JVET-M0304, JVET-M0366, JVET-M0340, JVET-
M0202, JVET-M0464) – these propose ways to reduce the number of candidates. In
Track A, it was agreed to study these in a CE:
 M0304 eliminates DCT8 completely, so uses only DCT2 and DST7, and
only sends one flag (reduces runtime, different tradeoffs with non-normative
search changes)
 M0366 uses a choice between 4 transform types instead of 5 (some gain and
encoder time reduction)
 M0340 (number of candidates depends and selection depends on block size
and intra prediction mode, at most three transform pairs considered, a little
loss and encoder runtime reduction) – Track A review indicated that this
seems contrary to a Ljubljana action and complicates the scheme – not to be
included in CE.
 M0202 (tests removal of some candidates normatively or encoder-only).
 The BoG recommended extending transform skip up to 16x16 (or 32x32?) only for
class F (and TGM test sequences). The transform skip change is suggested in JVET-
M0072 and JVET-M0464. A new version of JVET-M0464 was provided with
experiment results combined with CPR, showing additional benefit. It proposes a
truncated unary binarization for the signalling. JVET-M0072 does not change the
signalling but has significant encoder runtime increase. JVET-M0464 has an encoder
search modification that avoids encoder runtime increase. A cross-checker liked the
encoder search modifications as a logical cleanup. Track A Decision: Adopt
transform skip up to 32x32, with associated syntax approach in JVET-M0464 using
tu_mts_idx. And enable TS for block sizes up to 32x32 in CTC for all test sequences.
Further study was requested to identify potential runtime savings for disabling TS for
some categories of test sequences.
 The BoG recommended Track A to discuss further actions regarding the syntax
changes of MTS signalling (JVET-M0464, JVET-M0201). This is resolved by action
on JVET-M0464 noted above.
 Software tool for computing transform throughput (JVET-M0540): The BoG
recommended discussion in Track A to collect more opinions whether the proposed
software tool can be used for evaluating the CE6 study. No action was taken on this,
since there was not a plan for further CE work on transform speed-up approaches.
JVET-M0046 CE6-related: A study of primary transforms [M. Zhou, Y. Hu (Broadcom)]
JVET-M0465 Cross-check of JVET-M0046: CE6-related: A study of primary transforms

[S. Bandyopadhyay (InterDigital)]
Page: 215 Date Saved: 2019-03-172019-03-14

JVET-M0072 Non-CE6: On transform skip for larger block [T. Tsukuba, M. Ikeda,
T. Suzuki (Sony)]
JVET-M0748 Crosscheck of JVET-M0072, in aspect of 8x8 transform skip extension (Non-

CE6: On transform skip for lager block) [S. Yoo, J. Lim (LGE)] [late]
JVET-M0637 Crosscheck of JVET-M0072 (Non-CE6: On transform skip for lager block)

[T. Toma, K. Abe (Panasonic)] [late]
JVET-M0085 CE6-related: Fast algorithm for DST-4/DCT-4 as alternative transforms for

MTS [T. Toma, K. Abe (Panasonic), M. Ikeda, T. Tsukuba (Sony)]
JVET-M0800 Cross-check report of JVET-M0085 on Fast algorithm for DST-4/DCT-4 as

alternative transforms for MTS (CE6-related) [K. Naser (Technicolor)] [late]
JVET-M0201 CE6-related: Syntax clean-up related to MTS [K. Choi, M. Park,

M. W. Park, W. Choi (Samsung)]
JVET-M0671 Crosscheck of JVET-M0201 (CE6-related: Syntax clean-up related to MTS)

[X. Cao (Hikvision)] [late]
JVET-M0202 CE6-related: Simplification related to MTS with reduced modes [K. Choi,

M. Park, M. W. Park, W. Choi (Samsung)]
JVET-M0672 Crosscheck of JVET-M0202 (CE6-related: Simplification related to MTS

with reduced modes) [X. Cao (Hikvision)] [late]
JVET-M0269 Non-CE6: Extension of transform skip block size to 8x8 [S. Yoo, J. Choi,
J. Heo, J. Choi, L. Li, J. Lim, S. Kim (LGE)]
JVET-M0709 Crosscheck of JVET-M0269 (Non-CE6: Extension of transform skip block

size to 8x8) [T. Tsukuba (Sony)] [late]
JVET-M0275 Non-CE6: On transform skip conditions [S. Yoo, J. Choi, J. Heo, J. Choi,

L. Li, J. Lim, S. Kim (LGE)]
Page: 216 Date Saved: 2019-03-172019-03-14

JVET-M0846 Cross-check of JVET-M0275 (Non-CE6: On transform skip conditions)
[P. Keydel (HHI)] [late]
JVET-M0280 CE6-related: Context selection for entropy coding the MTS flag [S.-T.
Hsiang, S.-M. Lei (MediaTek)]
JVET-M0738 Crosscheck of JVET-M0280 (CE6-related: Context selection for entropy

coding the MTS flag) [A. Tamse (Samsung)] [late]
JVET-M0297 CE6-related: 32 point MTS based on skipping high frequency coefficients

[M. Koo, M. Salehifar, J. Lim, S. Kim (LGE)]
JVET-M0801 Cross-check report of JVET-M0297 on 32 point MTS based on skipping high

frequency coefficients (CE6-related) [K. Naser (Technicolor)] [late]
JVET-M0304 CE6-related: 2-mode MTS with shape adaptive transform selection

[J. Lainema (Nokia)]
JVET-M0340 CE6-related: Simplification on MTS for intra residual coding [X. Cao,

F. Chen, L. Wang (Hikvision)]
JVET-M0654 Crosscheck of JVET-M0340 (CE6-related: Simplification on MTS for intra

residual coding) [K. Choi (Samsung)] [late]
JVET-M0347 CE6-related: On MTS CU flag coding [X. Cao, F. Chen, L. Wang

(Hikvision)]
JVET-M0655 Crosscheck of JVET-M0347 (CE6-related: Simplification on MTS CU flag

coding) [K. Choi (Samsung)] [late]
JVET-M0354 CE6-related: MTS with Haar transform for Screen Contents Coding
[K. Naser, F. Galpin, T. Poirier (Technicolor)]
JVET-M0869 Cross-check report of JVET-M0354 (CE6-related: MTS with Haar

transform for Screen Contents Coding) [M. Koo (LGE)] [late]
Page: 217 Date Saved: 2019-03-172019-03-14

JVET-M0361 Non-CE6: Mismatch between text specification and reference software on
the signalling root CBF [J. Jung, D. Kim, G. Ko, J. Son, J. Kwak (Wilus)]
JVET-M0790 Cross-check of JVET-M0361 (Non-CE6: Mismatch between text

specification and reference software on the signalling root CBF) [B. Lee
(Chosun Univ.)] [late]
JVET-M0366 CE6 related: Transform Simplification [C. Hollman, D. Saffar,

P. Wennersten, J. Ström (Ericsson)]
JVET-M0876 Crosscheck for JVET-M0366 (CE-6 related: Transform Simplification)

[J. Rasch (HHI)] [late]
JVET-M0379 CE6-related: Further Simplification on top of CE6-2.2 [K. Naser,

E. François, F. Le Léannec (Technicolor)]
JVET-M0638 Crosscheck of JVET-M0379 (CE6-related: Further Simplification on top of

tests CE6-2.2) [T. Toma, K. Abe (Panasonic)] [late]
JVET-M0396 CE6-related: MTS kernel derivation for efficient memory usage [S. Shrestha,
A. Kumar, B. Lee (Chosun Univ), Y. Lee, J. Park (Humax)] [late]
Initial upload rejected as a placeholder.
JVET-M0773 Crosscheck of JVET-M0396 (“CE6-related: MTS kernel derivation for

efficient memory usage”) [J. Jung, D. Kim, G. Ko, J. Son, J. Kwak (Wilus)]
[late]
JVET-M0397 CE6-related: DST-3 based transform kernels derivation [S. Shrestha,

A. Kumar, B. Lee (Chosun Univ.), Y. Lee, J. Park (Humax)]
JVET-M0852 Crosscheck of JVET-M0397 (CE6-related: DST-3 based transform kernels

derivation) [J. Kim (SK Telecom), K. Ko (Pixtree), J. Jung (Wilus)] [late]
JVET-M0398 CE6-related Further simplification of CE6-1.5 [P. Philippe (bcom Orange)]
Page: 218 Date Saved: 2019-03-172019-03-14

JVET-M0480 CE6-related: Implicit transform selection for Multi directional LM
[S. Iwamura, S. Nemoto, A. Ichigaya (NHK)]
JVET-M0573 Crosscheck of JVET-M0480 (CE6-related: Implicit transform selection for

Multi directional LM) [K. Kazui (Fujitsu)] [late]
JVET-M0482 CE6-related: Implicit transform selection for Multi-hypothesis inter-intra

mode [S. Iwamura, S. Nemoto, A. Ichigaya (NHK)]
JVET-M0569 Crosscheck of JVET-M0482 (CE6-related: Implicit transform selection for

Multi-hypothesis inter-intra mode) [T. Chujoh (Sharp)] [late]
JVET-M0501 CE6 related: Unification of Transform Skip mode and MTS [X. Zhao, X. Li,
S. Liu (Tencent)]
JVET-M0656 Crosscheck of JVET-M0501 (CE6 related: Unification of Transform Skip

mode and MTS) [K. Choi (Samsung)] [late]
JVET-M0524 CE3/6-related: Unification of RQT-like transform partitioning for intra and

inter blocks [H. Egilmez, V. Seregin, A. Said, M. Karczewicz (Qualcomm)]
JVET-M0847 Cross-check of JVET-M0524 (CE3/6-related: Unification of RQT-like

transform partitioning for intra and inter blocks) [P. Philippe (bcom
Orange)] [late]
JVET-M0538 CE6: Efficient Implementations of MTS with Transform Adjustments (tests

1.4a-d) [A. Said, H. E. Egilmez, Y.-H. Chao, V. Seregin, M. Karczewicz
(Qualcomm)] [late]
This had been included in the CE report but was a late contribution that was not in the CE plan.
JVET-M0539 CE6-related: Efficient computation of MTS transform combinations [A.

Said, H. E. Egilmez, Y.-H. Chao, V. Seregin, M. Karczewicz (Qualcomm)]
[late]
JVET-M0540 CE6-related: Software tool for computing transform throughput [A. Said,

H. E. Egilmez, Y. H. Chao, V. Seregin, M. Karczewicz (Qualcomm)] [late]
Page: 219 Date Saved: 2019-03-172019-03-14

6.7 CE7 related – Quantization and coefficient coding (17)
See also section 6.16 for quantization control related contributions.
JVET-M0891 BoG report on CE7 related quantization and coefficient coding contributions
[Y. Ye]
This report was discussed in Track A Thursday 17 January 1700-1800 (GJS).
There were 13 technical contributions in the CE7 related category. These contributions are classified into
the following three categories:
 Rice parameter related
 Complexity reduction and simplification
The first BoG session was held 1900–2345 on January 14 2019 in Saba.
The second BoG session was held 1300–1400 on January 17 2019 in Saba.
Section 1 of this document summarizes the BoG’s recommendations. Section 2 of this document contains
detailed notes on BoG discussion.
Recommended adoptions:
 JVET-M0470, CE7-related: Golomb-Rice/exponential Golomb coding for abs_remainder and
dec_abs_level syntax elements
o In VTM 3.0, worst case is 33 bits for abs_gt3_level_flag, and 35 bits for dec_abs_level for
escape codes of coefficient levels, in comparison with is 32 bits for both syntax elements in
HEVC.
o Two aspects in this proposal: the first aspect uses a constant transition prefix code length of
6, and eliminates a LUT; the second aspect uses HEVC RExt extended precision scheme to
limit worst case code length to 32 bits
o Performance: 0.00%/0.01%/0.02% for AI/RA/LB
o Proposed aspects seemed to be straightforward and aligned with HEVC. It also would solve a
software issue that currently exists in VTM 3 that could cause decoder crash.
Decision (BF): Adopt JVET-M0470.
 JVET-M0251 (Non-CE7: Last position coding for large block-size transforms) and JVET-M0257
(CE7-related: coefficient scanning and last position coding for TUs of greater than 32 width or
height)
o Three contributions in this BoG tried to address the coefficient coding issues due to high
frequency zeroing: JVET-M0250, JVET-M0251 (which is a superset of JVET-M0250), and
JVET-M0257
o Propose to scan only the portions of the transform blocks that have not been zeroed out
o JVET-M0257 and JVET-M0251 are identical from spec text point of view, but simulation
results are slightly different due to some difference in encoder implementation
o M0257: 0.00% AI, -0.01% RA, -0.01% LB
o M0251: 0.01% AI, 0.01% RA, full set of LB results not yet available at time of discussion
Page: 220 Date Saved: 2019-03-172019-03-14

o Recommend to adopt JVET-M0251/ JVET-M0257. Use JVET-M0257’s encoder
implementation (better performance and cleaner code)
Decision (BF): Adopt JVET-M0251/JVET-M0257 (software from JVET-M0257).
 JVET-M0305 CE7-related: Joint coding of chrominance residuals
o The proposal adds a chroma residual coding mode where the Cr residual is not signalled, and
is derived from the Cb residual by reversing the signs of the Cr residual.
o The proposed method is applied to intra and inter coded blocks.
o At the encoder side, the Cb and -Cr residuals are averaged together. In the proposed mode,
that average residual is coded. RD decision is made to select between the conventional
chroma coding method and this proposed method (in which case the average residual thus
computed is coded). The mode flag is sent when the cbfs for both Cb and Cr are 1.
Overall Y U V Ave-UV
AI -0.29% -0.79% -2.16% -1.48%
RA -0.19% -1.44% -2.00% -1.72%
LD-B -0.08% -2.38% -4.83% -3.61%
LD-P -0.11% -2.46% -5.08% -3.77%
o This method is simpler than an LM chroma mode that predicts Cr from Cb that was
previously proposed, and achieves similar coding performance as that previous LM chroma
mode. This complexity reduction of this proposed method compared to the previous LM
chroma mode could be especially beneficial for the decoder.
o It seems that such coding gain was usually not available from coefficient coding methods.
o Low QP results (provided in a v3 of the contribution) were discussed at the second BoG
session. The chroma gains are reported to be somewhat lower than those of CTC, but the
gains in luma are similar to (AI case) or higher than (RA and LB cases) those of CTC.
o In Track A, a participant commented wondered whether there could be subjective artefacts.
o A participant asked how many blocks used this, and it was said that around half of the time
that both channels had a residual, it would use this mode.
o The proponent said it seems to also work for HDR.
Further study in a CE was planned for this.
BoG recommendations for CE testing:
 CE on coefficient coding (cleanup):
o JVET-M0198, CE7-related: Unified Rice parameter derivation for coefficient level coding
(some more computes but hardware friendly, removing one variation)
o No test of this one (some loss): JVET-M0469, CE7-related: Unified Rice parameter
derivation for coefficient coding
o JVET-M0558: CE7-related: Template-based Rice parameter derivation (some more storage
of reconstructed values and computes but hardware friendly, removing one variation)
o No test of this one (don’t worry about number of contexts at this point): JVET-M0107: CE7-
related: Reduced local neighbourhood usage for transform coefficients coding
related: Reduced context models for transform coefficients coding
Page: 221 Date Saved: 2019-03-172019-03-14

o JVET-M0491: CE7-related: Reduced maximum number of context-coded bins for transform
coefficient coding
 CE on screen content coding (coding efficiency)
o JVET-M0278: Non-CE7: Residual rearrangement for transform skipped blocks
o JVET-M0279: Non-CE7: Sign coding for transform skip
Regarding JVET-M0198, JVET-M0469 and JVET-M0558, during the BoG discussion, the pros and cons
of the proposed approach vs the current design in VVC draft 3 were discussed. The approaches of JVET-
M0198 and JVET-M0558 seemed to be more hardware friendly, whereas the current coefficient coding
method in VVC draft 3 seemed to be more software implementation friendly.
This was discussed in Track A when determining which CEs to conduct.

JVET-M0107 CE7-related: reduced local neighbourhood usage for transform coefficients

coding [F. Le Léannec, Y. Chen (Technicolor)]
JVET-M0781 Cross-Check of JVET-M0107 (CE7-related: reduced local neighbourhood

usage for transform coefficients coding) [M. Gao (Tencent)] [late]
JVET-M0198 CE7-related: Unified Rice parameter derivation for coefficient level coding
[Y. Piao, K. Choi (Samsung)]
JVET-M0668 Crosscheck of JVET-M0198 (CE7-related: Unified Rice parameter

derivation for coefficient level coding) [M. Coban (Qualcomm)] [late]
JVET-M0250 Non-CE7: Simplified CSBF coding for large block-size transforms [J. Choi,
JVET-M0760 Crosscheck of JVET-M0250 (Non-CE7: Simplified CSBF coding for large

block-size transforms) [Z.-Y. Lin (MediaTek)] [late]
JVET-M0251 Non-CE7: Last position coding for large block-size transforms [J. Choi,
JVET-M0646 Crosscheck of JVET-M0251 (Non-CE7: Last position coding for large block-
size transforms) [H. Schwarz (Fraunhofer HHI)] [late]
Page: 222 Date Saved: 2019-03-172019-03-14

JVET-M0257 CE7-related: Coefficient scanning and last position coding for TUs of greater
than 32 width or height [M. Coban, M. Karczewicz (Qualcomm)]
JVET-M0761 Crosscheck of JVET-M0257 (CE7-related: Coefficient scanning and last

position coding for TUs of greater than 32 width or height) [Z.-Y. Lin
(MediaTek)] [late]
JVET-M0278 Non-CE7: Residual rearrangement for transform skipped blocks [S. Yoo,

J. Choi, J. Heo, J. Choi, L. Li, J. Lim, S. Kim (LGE)]
JVET-M0683 Crosscheck of JVET-M0278 (Non-CE7: Residual rearrangement for

transform skipped blocks) [Y.-C. Lin (MediaTek)] [late]
JVET-M0279 Non-CE7: Sign coding for transform skip [S. Yoo, J. Choi, J. Heo, J. Choi,
L. Li, J. Lim, S. Kim (LGE)]
JVET-M0649 Crosscheck of JVET-M0279 (Non-CE7: Sign coding for transform skip)

[F. Henry, G. Clare (Orange)] [late]
JVET-M0305 CE7-related: Joint coding of chrominance residuals [J. Lainema (Nokia)]
JVET-M0688 Cross-check of JVET-M0305, "CE7-related: Joint coding of chrominance

residuals" [C. Gisquet (Canon)] [late]
JVET-M0469 CE7-related: Unified Rice parameter derivation for coefficient coding

[M. Karczewicz, M. Coban (Qualcomm)]
JVET-M0647 Crosscheck of JVET-M0469 (CE7-related: Unified Rice parameter

derivation for coefficient coding) [H. Schwarz (Fraunhofer HHI)] [late]
JVET-M0470 CE7-related: Golomb-Rice/exponential Golomb coding for abs_remainder

and dec_abs_level syntax elements [M. Coban, M. Karczewicz (Qualcomm)]
Page: 223 Date Saved: 2019-03-172019-03-14

JVET-M0831 Cross-check of JVET-M0470 (CE7-related: Golomb-Rice/exponential
Golomb coding for abs_remainder and dec_abs_level syntax elements)
[K. Sharman, S. Keating (Sony)] [late]
JVET-M0489 CE7-related: Reduced context models for transform coefficients coding

[M. Gao, X. Li, X. Zhao, S. Liu (Tencent)]
JVET-M0697 Cross-check of JVET-M0489 "CE7-related: Reduced context models for

transform coefficients coding" [Y. Chen, F. Le Léannec (Technicolor)] [late]
JVET-M0491 CE7-related: Reduced the maximum number of context-coded bins for

transform coefficient coding [M. Gao, X. Li, X. Zhao, S. Liu (Tencent)]
JVET-M0684 Crosscheck of JVET-M0491 (CE7-related: Reduced the maximum number

of context-coded bins for transform coefficient coding) [Y.-C. Lin
(MediaTek)] [late]
JVET-M0558 CE7-related: Template based Rice parameter derivation [M. Karczewicz

(Qualcomm)] [late]
JVET-M0660 Crosscheck of JVET-M0558 [Y. Piao, K. Choi (Samsung)] [late]
6.8 CE8 related – Screen content coding tools (29)

Contributions in this category were discussed Friday 11 Jan. 1620–2010 and Saturday 1815-2130 (Track
B chaired by JRO).
See also JVET-M0255 on MMVD for screen content coding and JVET-M0418 on context modeling for
CPR.
JVET-M0151 CE8-related: Virtual search area for current picture referencing (CPR)
[L. Pham Van, T. Hsieh, W.-J. Chien, V. Seregin, H. Wang, M. Karczewicz
(Qualcomm)]
This contribution proposes a method to extend the CPR search area by padding the area using the line
buffer and the column to the left of the current CTU. Without any additional memory cost, the luma BD-
rate changes for [CTC, Class F, class SCC 1080p] with the use of the proposed technique are reported as
test 1:
CPR on and PLT off:
AI: (0.02%, -0.39%, -1.23%) over VTM3+CPR on, resp.
RA: (0.02%, -0.29%, -0.60%) over VTM3+CPR on, resp.
LB: (-0.03%, -0.20%, -0.35%) over VTM3+CPR on, resp.
CPR on and PLT on:
Page: 224 Date Saved: 2019-03-172019-03-14

AI: (0.03%, -0.09%, -0.31%) over VTM3+CPR+PLT on, resp.
RA:( 0.03%, -0.12%, -0.35%) over VTM3+CPR+PLT on, resp.
LB:( 0.01%, -0.27%, -0.17%) over VTM3+CPR+PLT on, resp.
Test 2: In addition, this document also reports the results of the proposed padding scheme when 4 lines
above and 4 columns to the left of the current CTU are included into the CPR search area.
Test 2 is not realistic, as only one line buffer is available
Test 1 is kind of extension of CE 8.1.3, which uses only 1 line without padding
It is pointed out by one expert that a similar method of padding could also be used generally when an MV
in CPR would point outside the valid range
Padding generally is not of much complexity concern
Further study.
JVET-M0174 CE8-related: Removal of subblock-based chroma MC in CPR [C.-Y. Lai, T.-

D. Chuang, Y.-L. Hsiao, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
This contribution proposes a modification on current picture referencing (CPR). In the current CPR, when
dual tree coding is enabled, a chroma coding unit (CU) selecting CPR inter mode has to check all
collocated luma subblock motion vectors (MVs), scale the collocated luma subblock MVs for chroma,
and perform subblock-based chroma motion compensation (MC) if all the collocated luma subblock MVs
are available and valid. To simplify the chroma CPR inter CUs in dual tree coding, it is proposed to use
only the center collocated luma subblock MV to replace subblock-based chroma MC with CU-based
chroma MC. Two default MVs can be checked when the center collocated luma subblock MV is
unavailable or invalid. Simulation results are as follows, where the anchor enabled CPR.
For common test condition (CTC) sequences without class F
VTM3.0-AI: {Y/U/V-BD-rate = 0.00% / -0.04% / -0.06%, EncT=100%, DecT=99%}
VTM3.0-RA: {Y/U/V-BD-rate = 0.01%/ -0.07% / -0.04%, EncT=100%, DecT=99%}
For class F sequences
VTM3.0-AI: {Y/U/V-BD-rate = -0.04% / -0.25% / -0.14%, EncT=101%, DecT=100%}
VTM3.0-RA: {Y/U/V-BD-rate = -0.04% / -0.21% / -0.07%, EncT=100%, DecT=101%}
For TGM sequences
VTM3.0-AI: {Y/U/V-BD-rate = -0.27% / -0.47% / -0.55%, EncT=101%, DecT=101%}
VTM3.0-RA: {Y/U/V-BD-rate = -0.06% / -0.25% / -0.25%, EncT=100%, DecT=99%}
It is pointed out that one of the design goals of keeping luma and chroma aligned in CPR with dual tree
was to avoid luma/chroma mismatches (which might be critical in screen content with sharp edges).Not
clear if this would be critical in terms of complexity; compression gain is not an argument; more evidence
would be necessary that the current design is overly complicated and would need additional checks at the
encoder to guarantee the compliance of a vector. The decoder complexity is not a big issue as long as the
decoder can trust an encoder to deliver a valid vector.
JVET-M0769 Crosscheck of JVET-M0174 (CE8-related: Removal of subblock-based

chroma MC in CPR) [T.-S. Chang, Y.-C. Sun, J. Lou (Alibaba)] [late]
Page: 225 Date Saved: 2019-03-172019-03-14

JVET-M0175 CE8-related: Clarification on interaction between CPR and other inter
coding tools [C.-Y. Lai, T.-D. Chuang, Y.-L. Hsiao, C.-Y. Chen, Y.-W.
In VTM3.0 encoder, current picture referencing (CPR) for each coding unit (CU) is never tested with
combined inter intra prediction (CIIP), merge mode with motion vector difference (MMVD), and
subblock modes including subblock-based temporal motion vector prediction (SbTMVP) merge mode,
affine merge mode, and affine inter mode. When the reference picture list contains only the current
picture and no other reference picture, mh_intra_flag (indicating CIIP on/off of the CU; it is suggested to
rename it as ciip_flag), mmvd_flag (indicating MMVD on/off of the CU), merge_subblock_flag (equal to
1 indicating SbTMVP merge or affine merge is on; equal to 0 indicating SbTMVP merge and affine
merge are off), and inter_affine_flag (indicating affine inter mode on/off) are always zero and still
signalled. In addition, in both VTM3.0 decoder and VVC draft text JVET-L1001-v7.docx, decoding
process is not defined. This contribution proposes two methods to deal with this issue. Method 1 is to add
a normative encoder-only constraint in the VVC draft text, i.e., conformant encoders shall not enable any
of the four flags when CPR is enabled at CU level. Method 2 is to skip signalling and parsing the above
four flags when the reference picture list only contains the current picture at encoder and decoder,
respectively. Method 1 does not cause any BD-rate change for VTM3.0. Method 2 reportedly causes
minor BD-rate impact. It is claimed that Method 2 is a preferred solution than Method 1 in order to
reduce the possibility of related illegal bitstreams generated by careless encoders.
Method1 was already included in V8 of VVC draft 3, therefore the problem is solved. The addititional
benefit of method 2 is minimum (if at all present, as it might require additional low-level checks of
decoder).
JVET-M0253 Non-CE8: Hash-based Motion Search [J. Xu, J. Li, K. Zhang, L. Zhang

(Bytedance), R. Xiong (Peking Univ.)]
This contribution presents a hash-based motion search scheme for the VVC test model. For 4x4 to 64x64
square blocks and 4x8, 8x4 blocks, a hash table is generated for each reference picture. A hash-based
block matching is then performed before existing motion estimation for those block sizes. When a block
finds its match, the following motion estimation can be skipped. For TGM sequences, experimental
results report 9.6% and 18.87% coding gain for RA and LD_B, with encoding time reduced to 89% and
88%. When CPR is on, 7.81% and 14.91% coding gain is reported, with encoding time reduced to 91%
and 89%.
Basically, same apporach as known from HEVC-SCC
The new algorithm automatically detects if hash-based search is applicable and switches to conventional
search. This does not increase encoder run time (according to tables III and IV of v2 of the doc).
Decision (SW): Adopt JVET-M0253.
JVET-M0704 Crosscheck for JVET-M0253: Non-CE8: Hash-based Motion Search [X. Xu

(Tencent)] [late]
JVET-M0254 Non-CE8: Subblock Operation Removal for Chroma CPR [J. Xu, K. Zhang,
L. Zhang, H. Liu, Y. Wang, P. Zhao, D. Hong (Bytedance)]
In the current design of CPR, when separate tree is applied, chroma blocks inherit collocated luma
blocks’ block vectors, which requires sub-block by sub-block operation. This contribution proposes to
remove such a subblock-wise operation and reports a 0.26% coding gain for class TGM420.
Similar to JVET-M0174 (see notes on that contribution).
Page: 226 Date Saved: 2019-03-172019-03-14

JVET-M0785 Crosscheck of JVET-M0254 (Non-CE8: Subblock Operation Removal for
Chroma CPR) [Y.-H. Chao (Qualcomm)] [late]
JVET-M0255 AHG11: MMVD without Fractional Distances for SCC [H. Liu, L. Zhang,
In the merge with motion vector difference (MMVD) mode, fractional distances including 1/4-pel and
1/2-pel are included in the distance table. However, fractional distances maybe inefficient for screen
contents. To address this issue, this contribution proposes to disable fraction distances adaptively in
MMVD mode. When fractional distances are disabled, distances in the default table are all multiplied by
4. Simulation results reportedly show 0.76% and 1.66% luma BD-rate saving on SCC sequences in
Random Access configuration and Low Delay B configuration respectively. When CPR is off, 1.58% and
2.74% luma BD-rate saving on SCC sequences are achieved in Random Access configuration and Low
Delay B configuration respectively.
More related to MMVD (not SCC). A similar approach was investigated in CE 4.4.5b (see remarks there),
where switching to an integer table was proposed for UHD resolution.
Initially discussed Friday 11 January afternoon in Track B; discussion moved to CE4 BoG (see JVET-
M0843).
JVET-M0726 Cross-check of JVET-M0255 (AHG11: MMVD without Fractional Distances

for SCC) [A. Karabutov (Huawei)] [late]
JVET-M0326 CE8-related: Remove the redundancy of CPR-related syntax coding [S. Ye,

F. Chen, L. Wang (Hikvision)]
This document proposes to remove the redundancy of CPR-related syntax coding. CPR-P frame is called
for one frame where the current picture is the only reference picture. In fact, it is not allowed to use
MMVD (Merge with MVD), Affine, merge triangle mode or Combined inter merge / intra prediction
(CIIP) mode in the CPR-P frame. Therefore, this contribution proposes to remove those unused tools
related syntax coding for CPR blocks in the CPR-P frame. By doing so, a small gain for luma BD rate of
0.01% was observed on AI configuration.
Similar to JVET-M0175. See notes there.
JVET-M0615 Crosscheck of JVET-M0326 (CE8-related: Remove the redundancy of CPR-

related syntax coding) [Y.-C. Sun (Alibaba)] [late]
JVET-M0327 CE8-related: A new CPR syntax scheme [S. Ye, F. Chen, L. Wang

(Hikvision)]
This document describes a new CPR syntax scheme.
In the VTM3.0, the current (partially) decoded picture is considered as a reference picture. This current
picture is put in the last position of reference picture list 0. Therefore, for a frame using the current picture
as the only reference picture, it is a P frame. To distinguish it with traditional P frame, we denoted it as a
CPR-P frame. The bitstream syntax follows the same syntax structure for inter coding while the decoding
process is unified with inter coding. The only outstanding difference is that the block vector (which is the
motion vector pointing to the current picture) always uses integer-pel resolution.
The reported BD rate changes from the VTM3.0 with CPR enabled are as follows:
Page: 227 Date Saved: 2019-03-172019-03-14

Scheme 1(Using initial context values of I frame for CPR-P frame):
 In AI, -0.05%/-0.05%/-0.02% for CTC/Class F/SCC 1080p classes, separately.
Scheme 2(Remain the frame type as I frame if the original frame type is I):
Scheme 3(Take CPR as an intra mode in IBP frame):
Presentation deck to be uploaded.
From the discussion, it is generally agreed that it would be much more desirable to handle CPR as a
separate mode, and remove the signalling via reference picture list, and not use a P picture for that
purpose. For VVC, there is no need to design it the same way as in HEVC (in HEVC, P picture was re-
used, as CPR was defined in a later stage).
This would also resolve the problem of prohibiting combination with other MC tools
It is however desirable to re-use building blocks from MC.
JVET-M0327 does not come with a syntax proposal.
JVET-M0483 goes a similar direction. See further notes on that contribution.
JVET-M0616 Crosscheck of JVET-M0327 (CE8-related: A new CPR syntax scheme) [Y.-

C. Sun (Alibaba)] [late]
JVET-M0333 Non-CE8: Coding on block vector difference [J. Nam, J. Lim, S. Kim (LGE)]
This contribution proposes a block vector difference coding for CPR mode. Considering that the absolute
value of block vector difference (i.e., abs_mvd_minus2) for CPR mode is larger than that of conventional
motion vector difference, higher order (K is equal to 3) of Exp-Golomb code is applied. From experiment
results, following luma BD-rate changes are observed over VTM-3.0 with CPR:
 AI: -0.02% (CTC), -0.19% (Class F), -0.41% (SCC)
 RA: 0.00% (CTC), -0.27% (Class F), -0.10% (SCC)
 LD: 0.00% (CTC), -0.15% (Class F), -0.76% (SCC)
This would require a different binarization in the context of MV coding. During discussion in a JVET
plenary about importance of consistency between CPR and MV coding whether we would encourage
such low level changes, it was agreed that they could be done if they provide sufficient benefit. This
proposal should be studied in CE to exercise such a case, though it remains tbd what “sufficient” means in
case of screen content.
It is noted that the same statement applies to methods that had been investigated in CE8.1, provided they
deliver similar gain.
JVET-M0705 Crosscheck for JVET-M0333: Non-CE8: Coding on block vector difference

[X. Xu (Tencent)] [late]
Page: 228 Date Saved: 2019-03-172019-03-14

JVET-M0334 Non-CE8: Removal of redundant syntax between CPR and other inter
coding tools [J. Nam, J. Lim, S. Kim (LGE)]
When CPR tool is enabled in SPS, I-Slice is treated as P-Slice so that all syntax elements of the picture
are signalled as P-Slice instead of I-Slice. Considering that current CPR mode does not work with some
inter coding tools, such as MMVD, affine, multi-hypothesis, and tri-angular prediction, this contribution
proposes to remove redundant syntax from those inter coding tools. Specifically, when the current
decoded picture is the only reference picture for the current slice, syntax elements for inter coding tools,
which does not work with CPR mode, is not signalled. From experiment results, following luma BD-rate
changes are observed over VTM-3.0 with CPR:
 AI: -0.01% (CTC), -0.01% (Class F), -0.07% (Class SCC)
 RA: 0.00% (CTC), -0.03% (Class F), -0.06% (Class SCC)
Same as JVET-M0175 method 2. See further notes there.
JVET-M0767 Crosscheck of JVET-M0334 (Non-CE8: Removal of redundant syntax

between CPR and other inter coding tools) [X. Xu (Tencent)] [late]
JVET-M0335 Non-CE8: modification on SbTMVP process regarding with CPR [H. Jang,

J. Nam, S. Kim, J. Lim (LGE)]
In VTM-3.0, SbTMVP and TMVP are not allowed when fetched motion vector in collocated picture uses
collocated picture itself as reference picture (i.e., fetched colPb is CPR coded). In current VVC
specification, however there may be a coding unit, which is coded by PRED_BI with L0 referring current
picture and L1 previous decoded picture as reference. In this case, SbTMVP and TMVP, which is bi-
predicted mode, is supposed to be operated based on motion vector of L1. Therefore, in this proposal,
SbTMVP and TMVP are to be disallowed when the picture corresponding to L0 reference index of ColPb
is collocated picture. The proposed method shows 0.00% and 0.00% BD-rate change in RA and LDB
respectively.
It is the opinion of other experts that somehow the usage is restricted in VVC draft 3.
Anyway, if CPR would be defined as a separate mode, the issue would be resolved anyway.
JVET-M0706 Crosscheck for JVET-M0335 Non-CE8: modification on SbTMVP process

regarding with CPR [X. Xu (Tencent)] [late]
JVET-M0341 Non-CE8: MMVD harmonization with CPR [H. Jang, J. Nam, S. Kim,

J. Lim (LGE)]
This contribution presents a simplified MMVD considering CPR mode. When the current decoded picture
is the only reference picture for the current slice, mmvd_merge_flag is not signalled and also 4 indices for
mmvd_distance_idx are allowed. From experimental results, following BD-rate changes are observed
over VTM-3.0 with CPR:
 AI: -0.03% (CTC avg.), -0.13% (Class F), -0.3% (Class SCC)
 RA: -0.01% (CTC avg.), -0.07% (Class F), -0.13% (Class SCC)
There is no conceptual reason to disable the combination of CPR and MMVD. There are other proposals
(JVET-M0541). Furthermore, there is also relation with proposals which suggest similar action
(alternative integer precision MVD table), e.g. JVET-M0255.
Page: 229 Date Saved: 2019-03-172019-03-14

Further study.
JVET-M0768 Crosscheck of JVET-M0341 (Non-CE8: MMVD harmonization with CPR)

[X. Xu (Tencent)] [late]
JVET-M0393 Non-CE8: chroma block vector initialization for CPR in dual tree
[T. Poirier, F. Le Léannec, F. Galpin (Technicolor)]
This contribution describes a method to initialize chroma block vectors when dual tree is enabled and
collocated luma block uses CPR partially. The method is implemented on top of VTM-3.0 with chroma
subpel interpolation activated. The method is reported to result in PSNR-Y, U, V BD-rate variations of -
0.01%, 0.00%, -0.01% with 100% and 99% encoding and decoding times in AI configuration, 0%, -
0.01%, -0.03% with 100% and 100% encoding and decoding times in RA configuration.
Further results in the document show somewhat higher gains for class TGM.
There are two aspects: subpel chroma (4-tap) and determination of a chroma CPR vector in case of dual
tree when no luma vector is available.
With dual tree enabled (which is CTC and also been known to be most beneficial in combination with
CPR), it gives 0.3% for class TGM, 0.1% for class F. This is rather low, does not justify the additional
complexity (e.g. determining and checking the derived vector, interpolation).
JVET-M0402 Non-CE8: Proposed Cleanup for Current Picture Referencing [B. Heng,

M. Zhou, W. Wan (Broadcom)]
The following document discusses some potential issues with the current picture referencing (CPR) tool.
It provides a few different proposals for changes that would help reduce the likelihood that the tool is
used in unintended or invalid ways. Specifically:
 Separate intra-picture CPR offsets from inter-picture motion vectors.
o Signal CPR mode with explicit cpr_flag rather than reusing ref_idx.
o Treat CPR as intra for existing motion vector prediction.
o Explore separate CPR vector prediction that actually generates legal CPR vectors.
 Modified handling of illegal CPR vectors.

o Add required clipping for any CPR vectors that point outside the current CTU.
o Initialize not-yet-decoded pixels to some pre-defined value.
 Syntax modification for illegal dual-tree chroma CPR.

o Prevent illegal usage of chroma CPR when underlying luma CU do not use CPR mode by
modifying the syntax to make it impossible.
The contribution has different aspects.

 - It supports an approach to define CPR as a separate mode. This also makes it simpler to define
which other tools can be combined with it
 - It suggests a decoder-side mechanism to preserve the valid range of MVs
 - It suggests a decoder-side mechanism to ignore a CPR flag in chroma tree if any of the colocated
luma blocks does not use CPR.
Page: 230 Date Saved: 2019-03-172019-03-14

There is no concrete syntax/semantics proposal associated with the proposal.
Needs further consideration (probably in future meetings)

The current approach of imposing bitstream constraints is probably viable (and sufficient for the time
being), but it might be safer to provide some “sanity check” at the decoder. Whether such a check needs
to be normative or not needs still to be determined. Furthermore, we cannot describe the exact decoder
behaviour upon an illegal bitstream, because it is impossible to check conformance.
JVET-M0409 Non-CE8: Mismatch between text specification and reference software on

ATMVP candidate derivation when CPR is enabled [X. Xu, X. Li, S. Liu
(Tencent), W.-J. Chien, M. Karczewicz (Qualcomm)]
This contribution provides a specification aligned CPR software implementation regarding ATMVP CU
level MV offset derivation. In a previous VVC specification, when performing alternative temporal
motion vector prediction (ATMVP), a motion offset at CU level is obtained from the motion vector of the
first available spatial neighbouring merge candidate that has the collocated picture as its reference picture.
In BMS2.1, if a neighbouring merge candidate is coded in CPR mode, it is considered as not available.
This implementation is inherited into VTM3.0 as part of CPR mode. In the current VVC specification,
only the first available spatial candidate in the merge list will be checked. If the candidate doesn’t satisfy
the condition of ATMVP neighbouring block requirement, zero motion vector will be used to derive the
collocated block in the collocated picture. Therefore, there is a mismatch between the specification and
software implementation. Simulation results report that when the provided specification aligned
implementation is compared to VTM-3.0 anchor (CPR=1):
 BD rate changes are 0.00%/0.00%/ 0.00% in AI/RA/LB configurations, respectively, for CTC
average.
 BD rate changes are 0.00%/-0.01%/ -0.10% in AI/RA/LB configurations, respectively, for Class F.
 BD rate changes are 0.00%/-0.03%/ -0.10% in AI/RA/LB configurations, respectively, for SCC TGM
class.
There are no apparent runtime changes observed.
Decision (SW/BF): Adopt JVET-M0409 (align software with text)
JVET-M0732 Crosscheck of JVET-M0409 (Non-CE8: Mismatch between text specification

and reference software on ATMVP candidate derivation when CPR is
enabled) [T.-S. Chang, Y.-C. Sun, J. Lou (Alibaba)] [late]
JVET-M0410 Non-CE8: CPR flag signalling at slice level [X. Xu, X. Li, S. Liu (Tencent)]
This contribution proposes to control the usage of CPR at slice level, in addition to the current CPR SPS
flag. That means, when CPR SPS flag is true, for each slice, an encoder can choose to turn on or off the
usage of CPR. On top of this change, an encoder algorithm is provided in a way that when the hash hit
rate of a picture is below a certain threshold, the slice level CPR is turned off. The intent of the suggested
algorithm is that CPR mode is turned off for slices where CPR may not contribute much to the BD rate
reduction while CPR mode is turned on for screen content materials. Simulation results report that:
 The BD rate/runtime changes for CTC average are -0.01%/-0.01%/0.13% and 103%/101%/103% for
AI/RA/LB, separately, when compared to VTM-3.0+CPR=0 anchor;
 The BD rate/runtime changes for Class F average are 0.13%/0.07%/0.03% and 96%/100%/99% for
AI/RA/LB, separately, when compared to VTM-3.0+CPR=1 anchor
Page: 231 Date Saved: 2019-03-172019-03-14

 The BD rate/runtime changes for Class SCC 1080p average are 0.00%/0.00%/0.01% and
98%/101%/98% for AI/RA/LB, separately, when compared to VTM-3.0+CPR=1 anchor
No urgent need to do this currently – for CTC, the usage of the sequence level flag is good enough.
JVET-M0670 Crosscheck of JVET-M0410 (Non-CE8: CPR flag signalling at slice level)

[J. Nam (LGE)] [late]
JVET-M0411 Non-CE8: Inter mode related flag signalling when current picture is the only
reference picture [X. Xu, X. Li, S. Liu (Tencent)]
This contribution proposes not to signal the following inter coding related flags in condition that the
current picture is the only reference picture for a slice. Specifically, sub-block merge flag, affine flag,
mmvd flag and intra-inter flag are not signalled. Simulation results report that BD rate changes are
negligible (within +-0.1%) when compared to VTM-3.0 anchor (CPR=1).
No need for further discussion – see notes under JVET-M0175.
JVET-M0635 Crosscheck of JVET-M0411 (Non-CE8: Inter mode related flag signalling

when current picture is the only reference picture) [C.-Y. Lai (MediaTek)]
[late]
JVET-M0417 CE8-related: Combination test of CE8.2.2 and CE8.2.5 [Y.-C. Sun, J. Lou
(Alibaba)]
This document reports the results of the combination of CE8.2.2 (palette mode and intra mode
combination) and CE8.2.5 (separated palette design for the joint CUs containing both luma and chroma
CBs). The tests are performed on top of CE8.2.1 (JVET-M0050). Compared with CE8.2.1, when the
method is tested with CPR turned off in the setting, the results of the combination show that:
1) For 4:2:0 TGM sequences, the proposed method reportedly provides 2.5%, 2.8%, and 3.0% BD-rate
gains for luma with 92%, 99% and 98% for encoding time, and 101%, 97% and 92% in decoding
time under AI, RA, and LD configurations, respectively.
2) For Class F sequences, the proposed method reportedly provides 0.3%, 0.5%, and 1.5% BD-rate gains
for luma, with 100%, 99% and 99% for encoding time, and 101%, 98% and 97% in decoding time
under AI, RA, and LD configurations, respectively.
When the method was tested with CPR turned on in the setting,
1) For 4:2:0 TGM sequences, the proposed method reportedly provides 0.9%, 1.3%, and 2.4% BD-rate
gains for luma with 95%, 99% and 100% for encoding time, and 100%, 98% and 100% in decoding
time under AI, RA, and LD configurations, respectively.
2) For Class F sequences, the proposed method reportedly provides 0.0%, 0.2%, and 0.9% BD-rate gains
for luma, with 99%, 100% and 103% for encoding time, and 100%, 101% and 98% in decoding time
under AI, RA, and LD configurations, respectively.
It’s worthwhile to note that, compared with the results of CE8.2.2 and CE8.2.5 individually, the results of
the proposed combination show further synergy between CE8.2.2 and CE8.2.5.
The contribution shows that palette has some subjective benefit.
Goal is to further improve palette over the basis configuration. Further study.
Page: 232 Date Saved: 2019-03-172019-03-14

JVET-M0556 Crosscheck of JVET-M0417 (CE8-related: Combination test of CE8.2.2 and
CE8.2.5) [C.-Y. Lai (MediaTek)] [late]
JVET-M0791 Crosscheck of JVET-M0417 (CE8-related: Combination test of CE8.2.2 and

CE8.2.5) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0418 CE8-related: Context modeling on pred_mode_flag when current picture is

the only reference picture (CPR) [Y.-C. Sun, J. Lou (Alibaba)]
This document modifies context modeling for pred_mode_flag signalling in VTM-3.0. Three methods are
proposed to add new context models based on CU luma/chroma type and CU size. Compared with VTM-
3.0 with CPR turned on, under AI configuration, the results show that:
1) Method 1 provides 0.2% and 0.0% BD-rate gains for luma for 4:2:0 TGM and Class F sequences,
respectively.
respectively.
respectively.
It is proposed to have different context models for 4x4 and other luma CUs, and for CUs in luma/chroma
trees (method 3 makes both cases different and shows highest coding gain).
This would only apply for CPR in intra picture, inter picture case is not changed.
For non-screen content sequences and COR turned on, all methods show loss for non screen content
classes, compared to the existing context modelling.
No action.
JVET-M0711 Crosscheck of JVET-M0418 (CE8-related: Context modeling on

pred_mode_flag when current picture is the only reference picture (CPR))
[S. Ye (Hikvision)] [late]
JVET-M0419 CE8-related: Context modeling on palette mode flag [Y.-C. Sun, J. Lou
(Alibaba)]
This document modifies context modeling for palette flag signalling of CE8.2.1. Compared with CE8.2.1,
the results of the proposed method show that, under AI configurations, the proposed method provides
0.1% and 0.1% BD-rate gains for luma for 4:2:0 TGM when the method is tested with CPR turned off and
on, respectively.
Relative low gain in terms of TGM.
JVET-M0557 Crosscheck of JVET-M0419 (CE8-related: Context modeling on palette

mode flag) [C.-Y. Lai (MediaTek)] [late]
Page: 233 Date Saved: 2019-03-172019-03-14

JVET-M0449 CE8-related: BDPCM entropy coding with reduced number of context coded
bins [M. Xu, X. Li, X. Xu, M. Gao, S. Liu (Tencent)]
Block DPCM (BDPCM) is tested in CE8.3 and shown noticeable gains. For each residual sample, up to
12 bins are coded with context. A restriction is proposed to improve the entropy coding throughput,
where up to 2 context coded bins are allowed for each sample on average. It shows almost no loss on
CTC for AI and RA. Compared to the original method, it shows 0.09% and 0.13% BD-rate loss on
average for class F in AI and RA configurations, respectively, and 0.12% and 0.32% BD-rate loss on
average for class SCC in AI and RA configurations, respectively.
Further study (see also notes under CE8.3)
BDPCM plus palette was used in the results of this contribution. Generally, different combinations of
enabling/disabling the various screen content specific tools should be studied to identify which gain they
still provide when not used standalone.
JVET-M0648 Crosscheck of JVET-M0449 (CE8-related: BDPCM entropy coding with

reduced number of context coded bins) [F. Henry, G. Clare (Orange)] [late]
JVET-M0464 Non-CE8: Unified Transform Type Signalling and Residual Coding for
Transform Skip [B. Bross, T. Nguyen, P. Keydel, H. Schwarz, D. Marpe,
T. Wiegand (HHI)]
This contribution proposes two modifications related to transform type signalling and residual coding for
transform skip. The first modification includes aligning the cases in which transform skip (TS) and
multiple transform selection (MTS) apply. This limits TS to luma transform blocks as well as extends it to
transform block sizes up to 32x32. The second modification constitutes of a modified transform
coefficient level coding for the TS residual. Relative to the regular residual coding case, the residual
coding for TS includes no signalling of the last x/y position, coded_sub_block_flag coded for every
subblock, sig_coeff_flag context modelling with reduced template, a single context model for
abs_level_gt1_flag and par_level_flag, context modeling for the sign flag, additional greater than 5, 7, 9
flags, modified Rice parameter derivation for the remainder binarization and a limit for the number of
context coded bins per sample. The proposed joint signalling (first modification) provides on average
(BD-rate Y, enc. time, dec.time):
 Natural: 0.01%, 103%, 101% (AI), -0.02%, 98%, 100% (RA), -0.07%, 102%, 102% (LB)
 Class F: -1.96%, 103%, 97% (AI), -2.14%, 98%, 100% (RA), -2.79%, 103%, 99% (LB)
 TGM: -8.04%, 106%, 88% (AI), -8.74%, 106%, 96% (RA), -9.21%, 112%, 97% (LB)
Additionally changing the residual coding for transform skip (first modification and second modification)
results on average in (BD-rate Y, enc. time, dec.time):
 Natural: -0.16%, 103%, 100% (AI), -0.07%, 98%, 101% (RA), -0.07%, 101%, 101% (LB)
 Class F: -7.16%, 104%, 94% (AI), -5.76%, 98%, 100% (RA), -5.85%, 102%, 99% (LB)
 TGM: -21.03%, 108%, 82% (AI), -15.57%, 105%, 94% (RA), -14.01%, 111%, 95% (LB)
v2 provides updated full frame results, details about the combined TS/MTS encoder search with results
for different encoder operation points as well as draft text for unified TS/MTS syntax.
v3 corrects wrongly pasted results to match with the cross-check provided in JVET-M0708.
Page: 234 Date Saved: 2019-03-172019-03-14

The aspect on TS/MTS in the proposal signals TS before MTS (and therefore also enables it for blocks up
to 32x32), but also changes the MTS binarization
Results of TS modification are on top of VTC, would be desirable to see benefit for SC classes when CPR
is on
There is also an aspect of encoder speedup, by another approach of early skip for testing MTS cases.
The modified coding method employs max 8 context coded bins per sample – much higher than current
VVC limit.
The way of restricting the number of context coded bins (once the budget is consumed, TS is not used any
more) is not elegant.
Question is raised whether it has subjective quality impact?
It is dicussed whether the aspect of signalling TS before MTS (and by that way enabling TS for block
sizes up to 32x32, but also restricting it to luma) would rather be a straightforward syntax cleanup, which
could be adopted at this meeting (but without modifying the MTS index binarization, which is discussed
in CE6).
Later, results with a CPR-on anchor were reported. It was demonstrated that large-block TS still provides
a benefit for screen content (1.6%, 4.9% for F/TGM in AI, 1.7%, 5.9% for LD). The adoption is reported
elsewhere (from Track A).
JVET-M0650 Crosscheck of JVET-M0464 (Non-CE8: Unified Transform Type Signalling

and Residual Coding for Transform Skip, test TSRC-CCB8) [F. Henry,
G. Clare (Orange)] [late]

and Residual Coding for Transform Skip, test TS32Y/uniMTS) [T. Tsukuba
(Sony)] [late]

and Residual Coding for Transform Skip, test TSRC-CCB3 and CCB2)
[S. Yoo, J. Lim (LGE)] [late]
JVET-M0483 CE8-related: CPR mode signalling and interaction with inter coding tools
[W.-J. Chien, V. Seregin, M. Karczewicz (Qualcomm)]
This contribution proposes two schemes to align the interaction between CPR mode with all other inter
coding tools. The method is implemented on top of VTM-3.0 with CPR enabled. The first scheme
removes CPR dependency in motion derivation process. It results in negligible BD-rate difference for all
test configurations on regular or screen content materials. The second scheme uses CPR mode as a third
mode other than intra or inter modes. Motion predictor for CPR mode and inter mode would be derived
mutual-exclusively from each other. The simulations show 1.1% in RA configuration and 1.5% in LDB
configuration in screen content coding materials.
(see also discussion under JVET-M0327)
In Track B, the general consensus is that it is a right direction to signal CPR as a separate mode rather
than using a special reference picture index. As this is a fundamental conceptual decision, this was later
discussed and decided in the JVET plenary.
Page: 235 Date Saved: 2019-03-172019-03-14

JVET-M0483 comes with spec text (“method 3”), which would probably need more careful inspection
and modifications (also alignment with v9 of VVC draft 3).
This was further discussed in Track B Thursday 17 Jan 1730.
Generally, consensus that the text is appropriate. Open issues are raised as follows:
 - How to implement HMVP? It is agreed that separate HMVP buffers (5 candidates each) should be
used for conventional MV and IBC.
 - How to implement merge? Share same process as in regular MV merge, but disallow TMVP, 0
vector means unavailable as it is invalid
 - Constraints to be implemented in bitstream, no invalid vectors, merge shall not be used if the merge
candidate is invalid (out of range or 0)
 - For deblocking, IBC is handled as inter mode
 - CIIP does not use IBC
 - AMVP does not use quarterpel.
 - In dual tree, the mode is signalled both for luma and chroma, same derivation of chroma vector as in
VTM3.
For the time being, the VTM4 encoder uses a maximum block size of 16x16, which may be released in
the future. No normative impact.
Decision: Adopt JVET-M0483 (text in zip v4, “r1”, probably needs some more update along the lines
above).
JVET-M0860 Cross check of JVET-M0483 [K. Misra (Sharp Labs of America)] [late]
JVET-M0541 Non-CE8: Combination of MMVD and CPR mode [Y. Li, Z. Chen (Wuhan
Univ.), X. Xu, S. Liu (Tencent)] [late]
This document describes unification methods of CPR merge mode with MMVD expansions. In the
proposed methods, merge candidates with default merge type (MRG_TYPE_DEFAULT_N) and CPR
merge type (MRG_TYPE_CPR) may both exist in the MMVD candidate list. Thus CPR will not be
excluded when MMVD is used. It is reported that the BD rate can be improved by enabling CPR with
MMVD expansions.
Several methods are proposed, such as clipping the fractional pel offset into integer values. The average
BD rate gain is around 0.3% for TGM, and 0.1% for class F in AI. Similar gain was reported in JVET-
M0341.
Further study.
JVET-M0542 Non-CE8: Combination of Multi Hypothesis Intra and CPR mode [Y. Li,
Z. Chen (Wuhan Univ.), X. Xu, S. Liu (Tencent)] [late]
This document proposes to unify the CPR mode operation with multi hypothesis intra mode. In the
proposed method, a multi-hypothesis can be a combination of intra mode and CPR merge mode. Thus
CPR mode is unified with inter mode coding when multi hypothesis intra mode tool is used. It is reported
that the BD rate changes by enabling CPR with multi-hypothesis intra mode are negligible.
The contribution shows that it would not be a problem to release the current bitstream constraint of
disallowing combination of CPR and CIIP. On the other hand, results show that it obviously does not give
benefit in terms of compression performance.
May be obsolete if CPR would be a separate mode.
Page: 236 Date Saved: 2019-03-172019-03-14

JVET-M0696 Crosscheck of JVET-M0542 (Non-CE8: Combination of Multi Hypothesis
Intra and CPR mode) [T. Poirier (Technicolor)] [late]
JVET-M0544 Non-CE8: CPR with chroma 4x4 sub-block size when dual-tree is on [X. Xu,
X. Li, S. Liu (Tencent)] [late]
This contribution proposes to unify the handling of chroma sub-block size for CPR mode to that of inter
sub-block mode (4x4), when dual-tree is enabled for CPR. For each group of four 2x2 chroma sub-blocks
in a chroma CU under dual-tree condition, the collocated luma block vector of the top-left 2x2 chroma
sub-block is used to derive the chroma block vector for all four sub-blocks. Simulation results report that:
 The BD rate changes for CTC average are 0.00%/0.00%/0.00% when compared to VTM-3.0+CPR=1
anchor
 The BD rate changes for Class F average are 0.06%/0.11%/0.07% when compared to VTM-
3.0+CPR=1 anchor
 The BD rate changes for Class SCC 1080p average are 0.57%/0.25%/-0.08% when compared to
VTM-3.0+CPR=1 anchor
Does not have advantage for CPR, as due to the integer precision of displacement vectors the 2x2
subblocks are no problem. It causes loss, and there may even be the possibility of luma/chroma mismatch
e.g. at edges.
JVET-M0669 Crosscheck of JVET-M0544 (Non-CE8: CPR with chroma 4x4 sub-block size
when dual-tree is on) [J. Nam (LGE)]
JVET-M0634 Affine motion mode in intra coding [S. Cao, H. Han, J. Wang, F. Liang,
Y. Yu, Y. Liu] [late]
This was discussed in Track A Thursday night 1115-1130 (GJS & F. Bossen) – picked up by Track A to
ensure presentation before the meeting ended.
In the contribution, the results of affine motion mode in intra coding are reported. This proposed
technique combines the affine motion mode with current picture referencing (CPRAffine). The use of
CPRAffine is signalled by using a reference picture index pointing to this current reference picture. In this
way, the syntax structure and decoding process of CPRAffine mode are aligned with the regular intra
mode. The proposed test reportedly shows BD-rate gain under AI for VTM anchors are:
-0.08%/-0.06%/-0.00% for Y, U, V component of Class F, separately.
The runtime impact was reported as 213%. This is clearly not a good tradeoff, but it was commented that
there might be some issue with how this is implemented. Further study was suggested to determine
whether there is some problem with the implementation.
JVET-M0765 CE8-related: Unified Screen Content and Multiview Video Coding –

Experimental results [J. Samelak, M. Domański] [late]
The HEVC standard provides separate screen-content and multiview profiles. Application of the
multiview coding technology provides some gains over simulcast video coding of multiple views.
Unfortunately, the multiview video coding technology was adopted in the limited number of applications
only. On the other hand, the frame compatible approach to compress stereoscopic video was quite
common recently. Moreover, the technology of sScreen cContent cCoding seems to be successful in real-
word applications. In this paper, we provide a modification HEVC sScreen cContent cCoding that
Page: 237 Date Saved: 2019-03-172019-03-14

exhibits roughly the same coding efficiency as HEVC SCC and MV-HEVC for graphics and frame-
compatible multiview content, respectively.
Current development of CPR (as needed for screen content) would not fulfil the requirements for FC
multiview, as it has only integer precision and does not access the entire picture. For future
stereo/multiview, frame compatible may no longer the main stream, as it penalizes spatial resolution, and
it may be better to keep the pictures separate.
JVET-M0822 Non-CE8: Encoder optimization for palette mode [H. Wang, Y.-H. Chao,
V. Seregin, M. Karczewicz (Qualcomm)] [late]
This contribution proposes an encoder optimization for palette mode. The results show more than 20%
encoding time reduction for AI for screen content sequences. When tested with CPR enabled, the partial
results show that the encoding time is reduced from 157% to 115% with only 0.14% (Y) BD rate loss for
TGM420 sequences, and the encoding time is reduced from 174% to 151% with 0.11% (Y) BD rate loss
for class F.
Early termination criteria are used to avoid full checking of all intra modes if palette mode shows good
performance (i.e. testing palette before intra modes but after CPR). Further, termination criteria for not
testing palette are applied for areas that are too small (which also avoids checks in partitioning).
In the setup of the CE, this might be considered as becoming part of the CE software (for the palette basis
configuration 8.2.1).
JVET-M0835 Crosscheck of JVET-M0822 (Non-CE8: Encoder optimization for palette

mode) [Y.-C. Sun (Alibaba)] [late]
JVET-M0878 CE8-Related: A combination of Test CE8.1.3 and Test CE8.1.2d [L. Pham

Van, T. Hsieh, V. Seregin, W.-J. Chien, M. Karczewicz (Qualcomm)] [late]
Was reported in Track B – see notes under JVET-M0028.
6.9 CE9 related – Decoder-side motion vector derivation (13)

Contributions in this category were initially assigned to Track B and were discussed in BoG JVET-
M0858 unless otherwise noted.
JVET-M0858 BoG report on CE9 related decoder-side motion vector derivation

contributions [S. Esenlik]
This report reviewed in Track B Wednesday 16 January 1115-1320 (JRO).
One session was held between 15:00 ~ 20:15 on January 12, 2019, for discussing 12 technical
contributions in two categories, BDOF (7 contributions) and DMVR (5 contributions).
Recommended for adoption by BoG:
 JVET-M0063 Non-CE9: An improvement of BDOF
o Generalization of BDOF bit-depth restriction for internal bit-depths other than 10 bit.
o No impact on CTC.
o 8-bit coding scenario: -0.32/-0.32/-0.31% change in BD-rate (Y/CB/CR)
o 12-bit coding scenario: -0.46/-0.03/0.08% change in BD-rate (Y/CB/CR)
Page: 238 Date Saved: 2019-03-172019-03-14

From discussion in Track B: A possible reason for this behaviour might be the wrong interpretation of the
gradient in case of bit depths other than 10.
It was asked if the change would still be supporting the 16 bit SIMD design of software? The proponent
confirms that this is the case; this may need further checking by SW coordinators.
This was further discussed in plenary: What is the general support of different bit depths in VVC? There
might be other tools that were added in recent meetings that have similar problems. Definitely, bit depths
up to 12 bits should be supported consistently, whereas it is likely that for higher bit depths some more
precision might be required. The editors were asked to consider this; it needs to be resolved in further
work.
Recommended CE tests, BDOF related:
 JVET-M0073 Non-CE9: On early termination for BIO
 JVET-M0249 Non-CE9: Modifications on Bi-Directional Optical Flow
 JVET-M0284 CE9-related: BDOF Modifications to Enable 64x64 VPDU
o Regarding hardware implementation of BDOF, at least, there are two or three problems.
o One is a buffering latency of SAD calculation for early termination before BDOF.
o Second is huge number of memory access with large CU.
o Third is memory access limitation to enable VPDU.
o Creating a new CE to solve above problems.
o None of the methods has significant impact on compression performance.
It was discussed in Track B if it might be better to remove early termination totally to simplify the design
and solve the buffer latency problem, as this does not have impact on worst case complexity. Document
JVET-M0890 reports that by removing the early termination, the result improves by 0.04%, but decoder
runtime increases by 3%. This should be one of the comparison tests in the CE. Furthermore, the
maximum size where early termination is used should be blocks of size 256 luma samples.
Recommended CE tests, DMVR related:
 JVET-M0077 CE9-related: Relaxation of block size restriction for DMVR
o -0.81/-0.90/-1.00% change in BD-rate (Y/U/V) with 111/119% enc/dec time.
From the discussion in Track B: This is estimated to have up to 0.2% loss compared to the adopted
version, and does not show decoding time decrease (even though it performs subsampling in SAD
calculation). Not worthwhile to consider in CE.
 JVET-M0078 CE9-related: Combination of JVET-M0077 and CE9.2.5
o Study early termination aspect of JVET-M0078 (which is also described in JVET-M0062)
separately if MRSAD version of DMVR is included.
From discussion in Track B: It is not necessary to study MRSAD, since SAD version of DMVR was
adopted. There is another aspect that points out a similar problem as in JVET-M0063 where the early
termination is dependent on bit depth and block size. As this would not affect CTC condition, there is
no need to study in CE. Proponents are requested to study this aspect further with regard to the
adopted version of DMVR.
 JVET-M0148 Non-CE9: Simplifications to DMVR search pattern and interpolation for refinement
o First part proposes to replace 25 sample search space with 13 total points.
Page: 239 Date Saved: 2019-03-172019-03-14

o Approximately: 0.08/0.1/0.09% BD-rate change (Y/U/V) w.r.t. to the anchor that is used
(CE9.2.1g).
o Second part proposes simplification in complexity of bilinear interpolation of DMVR
CE9.2.1g version
o 0.04/0.03/0.04 BD-rate change (Y/U/V) w.r.t the anchor that is used (CE9.2.1g).
From discussion in Track B: This reduces decoder run time by approx. 1%. It also introduces some
more specific processing at boundaries. The benefit was not obvious, as it introduces some
compression loss. This was determined not worthwhile to consider.
 JVET-M0516 Non-CE9.2.1.e: Non-local-mean-based MRSAD and Row-subsampled Search Pattern
for DMVR
o Approach 1: proposes Non-local mean value calculation for MRSAD
 0.07% luma BD-rate increase with same enc/dec times. Benefit over SAD might be
around 0.05% bit rate decrease.
From discussion in Track B: This still would require one more stage to first compute the mean before
the SAD can be computed.
o Approach 2: proposes 15 point row-subsampled search pattern.
 0.17% luma BD-rate increase with about 2% reduction in dec time
From discussion in Track B: This amount of loss is not a good tradeoff versus the complexity benefit.
o Approach 3: proposes to disable DMVR for 4xN and 8x8 DMVR.
o Approach 4: proposes to disable DMVR for 4xN and 8x8 DMVR, and also remove padding,
such that in this combination the worst-case memory BW would still be the same as 8x4 bi
pred.
It is further claimed that for the current DMVR (which only disables DMVR for Nx4 but not 4xN), the
current worst-case memory bandwidth may still be exceeded for certain memory access patterns.
Study the aspects 3 and 4 in CE, including an analysis of memory access bandwidth of current scheme
and proposed schemes.
The following contributions were further discussed in Track B:
 JVET-M0223 Non-CE9: Co-existence analysis for DMVR with BDOF
From discussion in Track B: In the current design, DMVR and BDOF may be processed sequentially
(depending on condition that DMVR does not determine a modified MV, BDOF is computed). This
contribution shows that parallel computation, and deciding by an additional cost criterion, does not
provide benefit. No action was taken to change the current approach, but it would be desirable to find
another solution on the cascade operation.
 JVET-M0316 CE9-related: simplification of BDOF
From discussion in Track B: This has the benefit of re-defining the BDOF refinement such that no
multiplications are necessary. Rate increase 0.15% for luma, with 4-5% decoding time reduction.
As we don’t know the BDOF gain when operated together with DMVR, the loss may become lower
in VTM4. Depending on the outcome, such a complexity reduction could be attractive. It was agreed
to study this in a CE.
 JVET-M0517 Non-CE9: Methods for BDOF complexity reduction
Page: 240 Date Saved: 2019-03-172019-03-14

From discussion in Track B: Two aspects are considered a) subsampling in OF computation b)
reduction of precision of multipliers. There is no noticeable change in decoder runtime, the benefit
would be more relevant for hardware (in particular aspect b). However, in BDOF the gradient
computation is less of concern in terms of complexity. The overall benefit was not clear – so this was
considered not relevant for a CE.
JVET-M0063 Non-CE9: An improvement of BDOF [T. Chujoh, T. Ikai (Sharp)]
JVET-M0652 Crosscheck of JVET-M0063 (Non-CE9: An improvement of BDOF) [K. Choi

(Samsung)] [late]
JVET-M0073 Non-CE9: On early termination for BIO [K. Kondo, M. Ikeda, T. Suzuki

(Sony)]
JVET-M0813 Cross-check of JVET-M0073: Non-CE9: On early termination for BDOF

[S. Bandyopadhyay (InterDigital)] [late]
JVET-M0077 CE9-related: Relaxation of block size restriction for DMVR [K. Unno,

K. Kawamura, S. Naito (KDDI)]
JVET-M0567 Crosscheck of JVET-M0077 (CE9-related: Relaxation of block size

restriction for DMVR) [T. Chujoh (Sharp)] [late]
JVET-M0078 CE9-related: Combination of JVET-M0077 and CE9.2.5 [K. Unno,

K. Kawamura, S. Naito (KDDI), T. Chujoh, T. Ikai (Sharp)]
JVET-M0636 Cross-check of JVET-M0078 (CE9-related: Combination of JVET-M0077

and CE9.2.5) [Y. Kato, K. Abe, T. Toma (Panasonic)] [late]
JVET-M0148 Non-CE9: Simplifications to DMVR search pattern and interpolation for

refinement [S. Sethuraman (Ittiam)]
JVET-M0506 Crosscheck of JVET-M0148 (Non-CE9: Simplifications to DMVR search

pattern and interpolation for refinement) [X. Chen (HiSilicon)] [late]
Page: 241 Date Saved: 2019-03-172019-03-14

JVET-M0223 Non-CE9: Co-existence analysis for DMVR with BDOF [S. Sethuraman
(Ittiam)]
JVET-M0797 Crosscheck of JVET-M0223 (Non-CE9: Co-existence Analysis for DMVR

with BDOF) [C.-C. Chen, W.-J. Chien (Qualcomm)] [late]
JVET-M0241 CE9-related: A simple gradient calculation at the CU boundaries for BDOF

[H. Lee, J. Kang, S.-C. Lim, J. Lee, H. Y. Kim (ETRI)]
JVET-M0568 Crosscheck of JVET-M0241 (CE9-related: A simple gradient calculation at

the CU boundaries for BDOF) [T. Chujoh (Sharp)] [late]
JVET-M0249 Non-CE9: Modifications on Bi-Directional Optical Flow [H. Liu, L. Zhang,

JVET-M0731 Crosscheck of JVET-M0249 (Non-CE9: Modifications on Bi-Directional

Optical Flow) [T.-H. Li, Y.-C. Yang (Foxconn)] [late]
JVET-M0284 CE9-related: BDOF Modifications to Enable 64x64 VPDU [H. Chen, X. Ma,

S. Esenlik, H. Yang, J. Chen (Huawei)]
JVET-M0486 Cross-check of JVET-M0284: CE9-related: BDOF Modifications to Enable

64x64 VPDU [S Bandyopadhyay (InterDigital)] [late]
JVET-M0316 CE9-related: simplification of BDOF [J. Li, R.-L. Liao, C. S. Lim

(Panasonic)]
JVET-M0701 Cross-check of JVET- M0316 (CE9-related: simplification of BDOF)

[J. Zhao (LGE)] [late]
JVET-M0516 Non-CE9.2.1.e: Non-local-mean-based MRSAD and Row-subsampled Search

Pattern for DMVR [C.-C. Chen, W.-J. Chien, M. Karczewicz (Qualcomm)]
JVET-M0577 Crosscheck of JVET-M0516 (Non-CE9.2.1.e: Non-local-mean-based MRSAD

and Row-subsampled Search Pattern for DMVR) [S. Esenlik (Huawei)] [late]
Page: 242 Date Saved: 2019-03-172019-03-14

JVET-M0517 Non-CE9: Methods for BDOF complexity reduction [S. Sethuraman
(Ittiam)]
JVET-M0796 Crosscheck of JVET-M0517 (Non-CE9: Methods for BDOF Complexity

Reduction) [C.-C. Chen, W.-J. Chien (Qualcomm)] [late]
JVET-M0890 CE9-related: BDOF buffer reduction and enabling VPDU based application
[H. Chen, X. Ma, S. Esenlik, H. Yang, J. Chen (Huawei), K. Kondo,
M. Ikeda, T. Suzuki] [late]
See notes under JVET-M0858.
JVET-M0893 Crosscheck of disabling early termination in JVET-M0890 (CE9-related:

BDOF buffer reduction and enabling VPDU based application) [T. Chujoh,
T. Ikai (Sharp)] [late]
JVET-M0896 Crosscheck of JVET-M0890 (CE9-related: BDOF buffer reduction and

enabling VPDU based application) [Y.-W. Chen (Kwai Inc.)] [late]
6.10 CE10 related – Combined and multi-hypothesis prediction (44)

Contributions in this category were initially assigned to Track B and were discussed in the BoG reported
in JVET-M0873.
JVET-M0873 BoG report on CE10 related combined and multi-hypothesis prediction

contributions [C.-W. Hsu, M. Winken]
This report was reviewed in Track B Wednesday 16 January 1500-1820 (JRO).
 CIIP modifications (12)
 OBMC (2)
 TPM modifications (23)
 LIC (6)
 Other (1)
The BoG met on 13 Jan. 2019 from 6:00pm-10:30pm, 14 Jan. 2019 from 1:00pm-4:00pm, 14 Jan. 2019
from 7:30pm-11:00pm
 Normative changes recommendationed by the BoG:
o Triangular mode:
1) Adopt syntax change of JVET-M0118: Same as in JVET-M0185, JVET-M0190, 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.
Page: 243 Date Saved: 2019-03-172019-03-14

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.
3) Adopt using only one context model for merge_triangle_flag (JVET-M0490). Increases
bit rate approx. 0.01% for both RA and LDB, not a real severe complexity issue. Was
discussed in Track B, and concluded to better keep it unchanged for now.
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)
Decision: Adopt recommendations 1, 2, and 4 from the list above
 Recommendations for testing in next CE:
o TPM:
1) Merging candidate list construction (aspects from JVET-M0184, JVET-M0194, JVET-
M0233, JVET-M0271, JVET-M0283, JVET-M0286, JVET-M0317, JVET-M0349,
JVET-M0399):
 Re-use general merging candidate list construction as common part
 Study different variants thereof within CE
It was reported that this comes with basically no loss, and makes the merge not only
unified but some proposals also simplify the merge list construction of triangular mode.
It was emphasized in Track B that it might already be an advantage if the first part of
merge list construction would be unified, and such a unification should not make the
regular merge list derivation more complicated.
Further, the merge list construction of triangular merge list construction is not overly
critical, so such modifications shall not penalize compression performance.
From discussion in Track B: This topic was agreed to be included in CE4.
2) Signalling (has become obsolete by adoption 4. above, no CE necessary):
 All proposals use 3 syntax elements for the signalling (split direction and 2
merge indices)
 Study different variants thereof within CE
o Study combination of triangular prediction and MMVD (within CE about motion vector coding)
From discussion in Track B: As the reported compression gain is probably lower due to the first
adoption above, and the current approach has a high impact on encoder runtime, proponents
should study the method and whether a fast encoder method is available, make input to the next
meeting; no CE was planned.
o CIIP
1) Study intra/inter weights within a CE (JVET-M0096, JVET-M0454): JVET-M0454
reduces CIIP only with planar mode, and has identical weighting for the entire block
(which is signalled). Compression gain 0.1%, but somewhat simplifies by removing
unequal weighting, and also does not need special MPM list. JVET-M0096 has 0.1%
gain in RA, 0.15% in LB, and uses equal for whole block, and only planar. The part of
JVET-M0096 which applies PDPC after blending should be removed (see notes under
JVET-M0492 below)
Page: 244 Date Saved: 2019-03-172019-03-14

2) Study MPM generation for CIIP within a Sub-CE of CE3 (for comparison purposes this
shall also include methods which don’t use MPM list for CIIP) (JVET-M0183, JVET-
M0232, JVET-M0276, JVET-M0296): These target either simplification, harmonization,
or improvement of the CIIP MPM coding. Gains are reported up to 0.02%. Compared to
the benefits of CE CIIP 1., this does not seem to be competitive, as the latter does not
need MPM signalling for CIIP at all, removes the non-uniform blending, and has slightly
more gain. This sub-experiment would not have chances for adoption, unless something
improves in these regards. Such ideas would better be brought as new proposals by next
meeting.
3) Propagation of intra modes from CIIP blocks shall also be studied within CE (M0294):
There is no compression benefit, and though some of the current design my appear
“unlogical”, there is no problem with it, and propagating this information may even
require more storage. If CE CIIP 1 would be successful, it is not needed anyway.
From discussion in Track B: Establish bullet point 1. as CE.
o LIC (JVET-M0088, JVET-M0115, JVET-M0182, JVET-M0224, JVET-M0450, JVET-M0500)
Given that there will be further action on LIC, to minimize implementation complexity, LIC
should be investigated having the following properties:
1) Usage of reconstructed intra coded, CIIP and IBC blocks, as this would have impact on
complexity and parallel implementation pipelining (test with and without, and further
study the impact)
2) Disabling LIC over CTU boundaries is not necessary
3) Disable for CIIP blocks
4) No temporal inheritance of LIC flag
5) No pruning based on LIC flag in merging candidate list generation
6) Disable LIC for all subblock modes
7) The VPDU issue should be solved (e.g., disabling for 128xN or by other method which
avoids violating VPDU constraint).
8) Bi-Prediction issue should be solved (LIC should not have to be applied twice, i.e. for
each L0/L1 as done in CE10.5.2). Possible solutions: Do it after bi-predictive
combination or restrict LIC to uni-prediction.
 Open issues discussed in Track B:
o CIIP:
1) JVET-M0492: ask hardware experts about their assessment.
From Track B discussion: It was not possible to conclude. Some concern was raised that
in hardware it may not allow re-using existing PDPC logic, as it is usually in pipelining
connected to intra prediction, and here it would be connected to inter prediction.
Furthermore, the proposal does not provide compression benefit (small loss in RA, small
gain in LB, and the reduction of software runtime is low.
2) JVET-M0082 raises an issue on appearance of banding within CIIP blocks when
horizontal/vertical modes are used, appearing at positions where the weight changes.
Though it is not obvious that such such artefacts would still appear in a moving video, it
is well noted but would be resolved in case when these modes would be removed, or the
non-uniform weighting would disappear. However, there is no benefit (even some small
compression loss) when only planar and DC are retained.
o OBMC:
Page: 245 Date Saved: 2019-03-172019-03-14

1) JVET-M0357 has new OBMC results, which is however not directly related to current
CE results. It uses uni prediction for the current block, and bi prediction (not integer
accuracy, but sub-pel with shorter interpolation filter) for the overlap areas. It provides
slightly higher gain than 10.2.2 (0.42% instead of 0.37%), but is not obvious to be less
complex (though it has only 5 instead of 6 references to access, it employs additional
interpolation, so in terms of signal processing there appears to be more complexity).
Following the plenary decision, this is not enough evidence to re-open the OBMC CE.
o JVET-M0424 addresses an issue that might be with interpolation filtering (i.e., requiring 32 bit
arithmetic in software)
This issue was discussed on the JVET reflector (see email of F. Bossen) – it was not clear if there
is really a problem. Further evidence was considered necessary before any action could be taken.
Otherwise, gain by new filters is so small that it would not justify adoption by coding efficiency
benefit. This needs further study but was not planned as a topic for a CE.
The current SIMD implementation is with 32 bit.
JVET-M0082 CE10-related: Simplification of Multi hypothesis intra prediction [Y. Kato,

K. Abe, T. Toma (Panasonic)]
JVET-M0808 Cross-check result of JVET-M0082 (CE10-related: Simplification of Multi

hypothesis intra prediction) [K. Kawamura, S. Naito (KDDI)] [late]
JVET-M0088 CE10-related: LIC restriction for pipeline structure [K. Abe, T. Toma

(Panasonic)]
JVET-M0371 Crosscheck of JVET-M0088 (CE10-related: LIC restriction for pipeline

structure) [P. Bordes (Technicolor)] [late]
JVET-M0096 CE10.1-related: Inter-intra prediction [L. Pham Van, G. Van der Auwera,

A. K. Ramasubramonian, V. Seregin, M. Karczewicz (Qualcomm)]
JVET-M0681 Crosscheck of JVET-M0096 (CE10.1-related: Inter-intra prediction)

[F. Galpin, T. Poirier (Technicolor)] [late]
JVET-M0115 CE10-related: pipeline reduction for LIC and GBI [P. Bordes, F. Galpin,
T. Poirier (Technicolor)]
JVET-M0570 Crosscheck of JVET-M0115 (CE10-related: pipeline reduction for LIC and

GBI) [T. Chujoh (Sharp)] [late]
Page: 246 Date Saved: 2019-03-172019-03-14

JVET-M0118 CE10-related: A fix for merge triangle flag signalling [R. Yu (Ericsson)]
JVET-M0631 Crosscheck of JVET-M0118 (CE10-related: A fix for merge triangle flag

signalling) [M.-S. Chiang (MediaTek)] [late]
JVET-M0182 CE10-related: Simplification of local illumination compensation [C.-M. Tsai,

C.-C. Chen, C.-W. Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0596 Crosscheck of JVET-M0182 (CE10-related: Simplification of local

illumination compensation) [Y. Yasugi, T. Ikai (Sharp)] [late]
JVET-M0183 CE10-related: Simplification of MPM generation for CIIP [M.-S. Chiang, C.-
W. Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0693 Crosscheck of JVET-M0183 (CE10-related: Simplification of MPM

generation for CIIP) [Z. Zhang, K. Andersson, R. Sjöberg (Ericsson)] [late]
JVET-M0184 CE10-related: Simplification of triangle merging candidate list derivation

[T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0729 Crosscheck of JVET-M0184 (CE10-related: Simplification of triangle

merging candidate list derivation) [M. Winken (HHI)] [late]
JVET-M0185 CE10-related: Syntax redundancy removal in triangle prediction [M.-S.

JVET-M0582 Cross-check of JVET-M0185 (CE10-related: Syntax redundancy removal in

triangle prediction) [K. Andersson, R. Yu (Ericsson)] [late]
JVET-M0190 CE10-related: Redundant syntax reduction for triangle prediction [Y. Ahn,

D. Sim (Digital Insights)]
JVET-M0749 Cross-check of JVET-M0190 (CE10-related: Redundant syntax reduction

for triangle prediction) [S.-C. Lim, H. Lee, J. Lee, J. Kang (ETRI)] [late]
Page: 247 Date Saved: 2019-03-172019-03-14

JVET-M0194 CE10-related: Triangle Prediction Mode Harmonization [A. Tamse,
M. W. Park, S. Jeong, M. Park, K. Choi (Samsung)]
JVET-M0207 CE10-related: Joint optimizations of Triangular prediction unit mode and

Multi-Hypothesis prediction mode [S. Jeong, M. W. Park, A. Tamse,
M. Park, K. Choi (Samsung)]
JVET-M0775 Crosscheck of JVET-M0207: CE10-related: Joint optimizations of

Triangular prediction unit mode and Multi-Hypothesis prediction mode
[L. Pham Van, W.-J. Chien, M. Karczewicz (Qualcomm)] [late]
JVET-M0216 CE10-related: syntax clean-up on triangle prediction [L. Li, J. Nam, N. Park,

H. Jang, J. Lim, S. Kim (LGE)]
JVET-M0849 Crosscheck of JVET-M0216 (CE10-related: syntax clean-up on triangle

prediction) [C. Rosewarne (Canon)] [late]
JVET-M0224 CE10-related: Local illumination compensation simplifications

[S. Bandyopadhyay, X. Xiu, Y. He (InterDigital)]
JVET-M0714 Crosscheck of JVET-M0224 (CE10-related: Local illumination

compensation simplifications) [P. Bordes (Technicolor)] [late]
JVET-M0232 CE10-related: Simplification of CIIP Intra mode coding [Y.-W. Chen,

X. Wang (Kwai Inc.)]
JVET-M0552 Crosscheck of JVET-M0232 (Non-CE10: Simplification of CIIP Intra mode

coding) [M.-S. Chiang (MediaTek)] [late]
JVET-M0233 CE10-related: Triangle prediction merge list construction [X. Wang, Y.-W.

Chen (Kwai Inc.)]
JVET-M0674 Crosscheck of JVET-M0233 (Non-CE10: Triangle prediction merge list

construction) [S. Esenlik (Huawei)] [late]
Page: 248 Date Saved: 2019-03-172019-03-14

JVET-M0234 CE10-related: Triangle prediction merge index coding [X. Wang, Y.-W.
Chen (Kwai Inc.)]
JVET-M0675 Crosscheck of JVET-M0234 (Non-CE10: Triangle prediction merge index

coding) [S. Esenlik (Huawei)] [late]
JVET-M0271 CE10-related: Merge list construction process for triangular prediction

mode [L. Zhang, K. Zhang, H. Liu, J. Xu, Y. Wang, P. Zhao, D. Hong
(Bytedance)]
JVET-M0588 Crosscheck of JVET-M0271 (CE10-related: Merge list construction process

for triangular prediction mode) [H. Dou, Z. Deng, L. Xu (Intel)] [late]
JVET-M0276 CE10-related: MPM list alignment between CIIP and intra mode [J. Li,
S. Wang, W. Gao (Peking Univ.), L. Zhang, K. Zhang, H. Liu, J. Xu
(Bytedance)]
JVET-M0755 Crosscheck of JVET-M0276 (CE10-related: MPM list alignment between

CIIP and intra mode) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0283 CE10-related: Reduction of motion predictor pruning in Triangle Merge

mode [A. Robert, F. Le Léannec, T. Poirier, F. Galpin (Technicolor)]
JVET-M0868 Crosscheck of JVET-M0283 (CE10-related: Reduction of motion predictor

pruning in Triangle Merge mode) [A. Filippov, V. Rufitskiy (Huawei)] [late]
JVET-M0296 CE10-related: Simplification on combined inter-intra mode prediction

[B. Wang, S. Esenlik, A. M. Kotra, H. Gao, J. Chen (Huawei)]
JVET-M0734 Crosscheck of JVET-M0296 (CE10-related: Simplification on combined

inter-intra mode prediction) [L. Zhao (Tencent)] [late]
JVET-M0317 CE10-related: Simplification of triangular prediction unit mode [R.-L. Liao,

J. Li, C. S. Lim (Panasonic)]
On deblock aspect: See notes at the end of CE11 related section.
Page: 249 Date Saved: 2019-03-172019-03-14

JVET-M0710 Crosscheck of JVET-M0317 (CE10-related: Simplification of triangular
prediction unit mode) [F. Chen (Hikvision)] [late]
JVET-M0328 CE10-related: Simplified triangle prediction unit mode [F. Chen, L. Wang

(Hikvision)]
JVET-M0666 Crosscheck of JVET-M0328 (CE10-related: Simplified triangle prediction

unit mode) [R.-L. Liao, C. S. Lim (Panasonic)] [late]
JVET-M0329 CE10-related: Modified enabling condition for triangle prediction unit mode
[F. Chen, L. Wang (Hikvision)]
JVET-M0692 Crosscheck of JVET-M0329 (CE10-related: Modified enabling condition for

triangle prediction unit mode) [S. H. Wang (Peking Univ.), X. Zheng,
S. S. Wang, S. W. Ma] [late]
JVET-M0331 CE10-related: A simplification method for Multi-intra-inter mode scheme

[L. Xu, F. Chen, L. Wang (Hikvision)]
JVET-M0533 Crosscheck of JVET-M0331 (CE10-related: A simplification of inter

prediction information derivation for Multi-intra-inter mode scheme)
[X. Chen (HiSilicon)] [late]
JVET-M0349 CE10-related: Simplification of triangle prediction merging candidate list

derivation [X. W. Meng (Peking Univ.), X. Zheng (DJI), S. S. Wang,
S. W. Ma (Peking Univ.)]
JVET-M0742 Crosscheck of JVET-M0390 (CE-10: related multi-hypothesis with uni-

directional inter prediction restriction) [H. Wang (Qualcomm)] [late]
JVET-M0352 CE10-related: Simplification of triangular partitions [D. Park, Y. Yoon, J.-

G. Kim (KAU), J. Lee, J. Kang (ETRI)]
JVET-M0722 Crosscheck of JVET-M0352 (CE10-related: Simplification of triangular

partitions) [G. Laroche (Canon)] [late]
Page: 250 Date Saved: 2019-03-172019-03-14

JVET-M0357 CE10-related: Reduction of the worst-case memory bandwidth and
operation number of OBMC [Y. Kidani, K. Kawamura, K. Unno, S. Naito
(KDDI)]
JVET-M0828 Crosscheck of JVET-M0357 (CE10-related: Reduction of the worst-case

memory bandwidth and operation number of OBMC) [Y.-C. Lin
(MediaTek)] [late]
JVET-M0390 CE10 related: Multi-hypothesis with uni-directional inter prediction

restriction [T. Poirier, E. François, K. Naser (Technicolor)]
JVET-M0742 Crosscheck of JVET-M0390 (CE-10: related multi-hypothesis with uni-

directional inter prediction restriction) [H. Wang (Qualcomm)] [late]
JVET-M0399 CE10-related: Modifications of Triangular PU Mode [H. Wang, W.-J. Chien,

V. Seregin, Y.-H. Chao, H. Huang, M. Karczewicz (Qualcomm)]
JVET-M0694 Crosscheck of JVET-M0399 (CE10-related: Modifications of Triangular PU

Mode) [T. Poirier (Technicolor)] [late]
JVET-M0424 CE10-related: On enhancement of 4-tap interpolation filters [M. Sychev,

J. Chen (Huawei)] [late]
JVET-M0752 Crosscheck of JVET-M0424 [A. Henkel (HHI)] [late]
JVET-M0438 CE10-related: Size constraint on Triangular Prediction [J. Zhao, S. Kim

(LGE)]
JVET-M0663 Crosscheck of JVET-M0438 (CE10-related: Size constraint on Triangular

Prediction) [C.-W. Kuo, R.-L. Liao, C. S. Lim (Panasonic)] [late]
JVET-M0450 CE10-related: LIC inheritance restrictions and interaction with GBI [M. Xu,
X. Li, X. Xu, S. Liu (Tencent)]
Page: 251 Date Saved: 2019-03-172019-03-14

JVET-M0454 CE10-related: Multi-Hypothesis Intra with Weighted Combination
[A. Seixas Dias, G. Kulupana, S. Blasi (BBC)]
JVET-M0610 Crosscheck of JVET-M0454 (CE10-related: Multi-Hypothesis Intra with

Weighted Combination) [B. Wang (Huawei)] [late]
JVET-M0492 CE10-related: Simplified multi-hypothesis intra-inter mode [L. Zhao,

X. Zhao, X. Li, S. Liu (Tencent)]
JVET-M0589 Crosscheck of JVET-M0492 (CE10-related: Simplified multi-hypothesis

intra-inter mode) [H. Dou, Z. Deng, L. Xu (Intel)] [late]
JVET-M0500 CE10-related: Unidirectional illumination compensation [V. Seregin, W.-J.

Chien, T. Hsieh, N. Hu, M. Karczewicz (Qualcomm)]
JVET-M0633 Crosscheck of JVET-M0500 (CE10-realated: Unidirectional illumination

compensation) [K. Abe (Panasonic)] [late]
JVET-M0525 CE10-related: Simplification of intra prediction in CIIP [P.-H. Lin, Y.-J.

Chang (Foxconn)]
JVET-M0578 Crosscheck of JVET-M0525 (CE10-related: Simplification of intra

prediction in CIIP) [M.-S. Chiang (MediaTek)] [late]
JVET-M0581 CE10-related: Bi-directional motion vector storage for triangular prediction

[M. Bläser, J. Sauer (RWTH Aachen Univ.)] [late]
JVET-M0829 Crosscheck of JVET-M0581 (CE10-related: Bi-directional motion vector

storage for triangular prediction) [H. Gao (Huawei)] [late]
JVET-M0736 CE10-related: Triangular prediction with MMVD [M. Bläser, J. Sauer

(RWTH Aachen Univ.)] [late]
JVET-M0830 Crosscheck of JVET-M0736 (CE10-related: Triangular prediction with

MMVD) [H. Gao (Huawei)] [late]
Page: 252 Date Saved: 2019-03-172019-03-14

JVET-M0792 CE10-related: Combined test of multi-hypothesis inter prediction and
OBMC [Z.-Y. Lin, T.-D. Chuang, C.-Y. Chen, C.-W. Hsu, C.-C. Chen, Y.-C.
Lin, Y.-W. Huang, S.-M. Lei (MediaTek), X. Xiu, Y. He (InterDigital),
M. Winken, H. Schwarz, D. Marpe, T. Wiegand (HHI)] [late]
JVET-M0884 Crosscheck of JVET-M0792 (CE10-related: Combined test of multi-

hypothesis inter prediction and OBMC) [Z. Deng (Intel)] [late]
JVET-M0838 CE 10 related: JVET-M0390 / JVET--M0096 combination [F. Galpin,

T. Poirier, E. François (Technicolor)] [late]
JVET-M0848 CE10 related Document: Speedups for Uniform Directional Diffusion Filters
For Video Coding (JVET-M0042) [J. Rasch, A. Henkel, J. Pfaff, H. Schwarz,
D. Marpe, T. Wiegand (HHI)] [late]
JVET-M0851 CE10-related: Using inter merge list derivation for triangle mode [H. Wang,
W.-J. Chien, V. Seregin, Y.-H. Chao, H. Huang, M. Karczewicz (Qualcomm),
X. Wang, Y.-W. Chen (Kwai), T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S.-
M. Lei (MediaTek), A. Tamse, M. W. Park, S. Jeong, M. Park, K. Choi
(Samsung)] [late]
JVET-M0883 CE10-related: Using regular merge index signalling for triangle mode
[H. Wang, W.-J. Chien, V. Seregin, Y.-H. Chao, H. Huang, M. Karczewicz
(Qualcomm), X. Wang, Y.-W. Chen (Kwai), T. Solovyev, S. Esenlik,
S. Ikonin, J. Chen (Huawei), M. Xu, X. Li, S. Liu (Tencent)] [late]
JVET-M0886 Crosscheck of JVET-M0883 (CE10-related: Using regular merge index

signalling for triangle mode) [H. Liu (Bytedance)] [late]
6.11 CE11 related – Deblocking (4)

Contributions in this category were discussed Monday 14 Jan. 1715–1815 (Track B chaired by JRO).
JVET-M0103 Deblocking for multi-hypothesis intra inter prediction [K. Andersson,

J. Enhorn, R. Yu, Z. Zhang, R. Sjöberg (Ericsson)]
Multi-hypothesis intra inter prediction can produce boundaries on both CU and sub-block level due to
uniform scaling of intra and inter prediction samples. Currently no deblocking is applied for such
boundaries in VVC when transform, motion or intra deblocking criterions are false. This contribution
proposes to set the boundary strength to 1 for boundaries of multi-hypothesis intra inter prediction on an
8x8 grid such that the boundaries will be deblocked as other inter modes.
The proposed fix is claimed to produce better subjective quality especially noticeable at low bit rates.
Reported Y/U/V BD-rates are -0.02%/-0.02%/0.03% for random access, 0.00%/-0.01%/-0.09% for low
Page: 253 Date Saved: 2019-03-172019-03-14

delay B and -0.05%/-0.07%/-0.34% for low delay P over VTM-3.0.
Currently, no deblocking is performed when there is a CIIP block and next to it an inter block with same
motion vector. This should be corrected.
JVET-M0294 is targeting the same issue and was also discussed in this context.
JVET-M0549 Crosscheck of JVET-M0103 (Deblocking for multi-hypothesis intra inter

prediction) [C.-M. Tsai (MediaTek)] [late]
JVET-M0294 CE10-related: Modification for blocks applied with Combined Inter-Intra

prediction [B. Wang, A. M. Kotra, S. Esenlik, H. Gao, J. Chen (Huawei)]
This contribution proposes two modifications for blocks applied with combined inter-intra prediction (for
simplification, these blocks are named as combined prediction blocks). The first modification occurs to
MPM (Most Probable Mode) list construction, where combined prediction blocks are considered as inter
blocks always. The second modification is applied for deblocking filter, where combined prediction
blocks are considered as intra blocks in boundary strength derivation. Two solutions are proposed: the
first solution applies modification only for MPM list construction, the second solution applies both
modification of MPM list construction and boundary strength derivation. The BD-rate results over the
VTM3.0 anchor are:
 -0.01% (RA), 0.01% (LDB), -0.04% (LDP) for luma component with the first solution
 0.00% (RA), 0.00% (LDB), -0.07% (LDP) for luma component with the second solution
AI results are the same to the anchor as modifications have no effect on I frames, wherein no combined
prediction blocks exist.
Similar to the previous but it is suggested to set boundary strength to 2, which would typically be used
when one side of the boundary is intra. Furthermore, subblocks are not deblocked here.
Proponents of JVET-M0103 and JVET-M0294 were asked to come together and suggest a reasonable
solution to fix this bug. It was later recommended to use BS2 at CU/TU boundary, whereas BS1 is used at
motion subblock boundaries. The proponents were asked to provide a combined specification text.
JVET-M0908 CE11-related: Specification text for combination of JVET-M0103 and

JVET-M0294 [K. Andersson, J. Enhorn, R. Yu, Z. Zhang, R. Sjöberg,
B. Wang, A. M. Kotra, S. Esenlik, H. Gao, J. Chen] [late]
This was presented in Track B Fri 18 Jan 0800. Text is available
Decision: Adopt JVET-M0908
JVET-M0587 Crosscheck of JVET-M0294 (CE10-related: Modification for blocks applied

with Combined Inter-Intra prediction) [K. Zhang (Bytedance)] [late]
JVET-M0187 CE11-related: Long deblocking filters with reduced line buffer requirement
and enhanced parallel processing accessibility [C.-M. Tsai, C.-W. Hsu, Y.-W.
This contribution proposes two aspects of modifications on top of the CE11.1.3 long deblocking filters in
JVET-M0186. In both VTM3.0 and CE11.1.3, deblocking can be performed at 8x8 grids and is skipped at
non-8x8 grids. The maximum numbers of to-be-read luma samples on one side of an edge during
deblocking are four and eight for VTM3.0 and CE11.1.3, respectively. The maximum numbers of to-be-
modified luma samples on one side of an edge during deblocking are three and seven for VTM3.0 and
Page: 254 Date Saved: 2019-03-172019-03-14

CE11.1.3, respectively. In the first aspect, to keep the number of luma sample lines needed to be stored in
the line buffer as low as that in VTM3.0, during vertical filtering across horizontal coding tree unit (CTU)
boundaries, the maximum number of to-be-read luma samples above the horizontal CTU boundary is
reduced from eight to four, and in addition, the maximum number of to-be-modified luma samples above
the horizontal CTU boundary is set to three. In the second aspect, to better support parallel deblocking at
multiple parallel subblock boundaries on 8x8 grids, during horizontal filtering across vertical subblock
boundaries and vertical filtering across horizontal subblock boundaries, if a subblock coding mode is
chosen on one side of the subblock boundary, the number of to-be-read luma samples on that side of the
subblock boundary is reduced from eight to four, and in addition, the maximum number of to-be-modified
luma samples on that side of the subblock boundary is set to three. It is reported that the proposed
deblocking results in negligible changes in BD-rate and encoding time, and the decoding time increase is
3% for VTM3.0 common test condition (CTC) and for VTM3.0 CTC with adaptive loop filter (ALF) off.
Generally similar approach as in CE11.1.7/8 and CE11.1.5, to reduce number of line buffers at CTU
boundary. Further, the issue of duplicate deblocking of subblock boundaries (as mentioned under CE11)
is solved for 11.1.3, in a similar fashion as used in CE11.1.6/7/8.
This would probably be something worthwhile to do as bug fix on the CE proposal (respectively to save
line buffers).
The issue is no longer relevant due to adoption of CE11.1.8.
JVET-M0604 Crosscheck of JVET-M0187 (CE11-related: Long deblocking filters with

reduced line buffer requirement and enhanced parallel processing
accessibility) [A. M. Kotra (Huawei)] [late]
JVET-M0336 Non-CE11: Considering boundary strength on CPR coded block boundary

[H. Jang, J. Nam, S. Kim, J. Lim (LGE)]
This proposal presents boundary strength design on CPR coded block boundary. Specifically, following
two methods for boundary strength design are suggested.
 Boundary strength is set to 0 when at least one of block is coded as CPR across the block boundary.
 Boundary strength is set to 0 when both block are coded as CPR and set to 1 when only one block is
coded as CPR across the block boundary
The proposed method has been shown to provide visual quality improvement on computer generated
video sequence where CPR mode occurs frequently.
It is obvious that for screen content, deblocking may not be optimum for certain cases. On the other hand,
an encoder might just decide turning it off, and QP37 as shown here is no a typical operation point of
screen content, as usually the target is high visual quality, and even low QP typically does not have realy
high rates.
Not obvious that there is a problem and if yes, if the suggested solution is solving it.
Put the aspect of studying impact of various loop filters on screen content as a mandate for the screen
content AHG.
JVET-M0605 Crosscheck of JVET-M0336 (Non-CE11: Considering boundary strength on

CPR coded block boundary) [A. M. Kotra (Huawei)] [late]
Page: 255 Date Saved: 2019-03-172019-03-14

JVET-M0339 CE11-related: subblock boundary filter at 8x8 Grid [H. Jang, J. Nam,
This contribution proposes a modification on subblock boundary filtering on 8x8 grid. In order to filter all
subblock boundaries on 8x8 grid, subblock boundaries where the current PU is not aligned with 8x8 grid
are also filtered in the proposed method, 4x4 block boundaries for affine and 8x8 block boundaries for
SbTMVP. The proposed method shows -0.01% BD-rate change for RA configuration and also gives
subjective quality improvement on subblock boundaries.
This is another variant over CE11.2, which gives up the restriction that only when the CU boundary is on
an 8x8 grid, the corresponding boundaries of underlying subblocks are not deblocked in current VTM.
This still allows parallel processing.
The case happens when a 16-wide or 16-high unit is ternary split, and then the middle partition is split
into subblocks. Questionable whether this would have any visual impact, in particular after experiencing
that CE11.2 (with its current test settings) did not have any significant visual impact.
Not related to this contribution: One expert asked if we should not potentially give up the requirement of
parallel processing (i.e. deblock in a sort of AVC style on a 4x4 grid), instead of imposing sophisticated
rules when to deblock or not, depending on the block structure.
JVET-M0606 Crosscheck of JVET-M0339 (CE11-related: subblock boundary filter at 8x8

Grid) [A. M. Kotra (Huawei)] [late] [miss]
JVET-M0317 has also an aspect deblocking for triangular partitions. It is however not evident that there
is a problem that causes artefacts, and therefore imposing another condition in deblocking based on
triangle mode may not be necessary.
After reviewing all contributions of this section and the CE11 viewing results, it was suggested to
perform further CE study on CE11.2 aspects, but also include a study whether deblocking at subblock
boundaries is necessary at all. This was intrduced in VVC draft 2 without considering if there is impact on
visual quality.
Further, the question was raised if everything in terms of deblocking is aligned with the new adoption of
SBT.
6.12 CE12 related – Mapping functions (2)

Contributions in this category were discussed Saturday 12 Jan. 1800–1830 (chaired by GJS).
JVET-M0109 CE12-related: block-based in-loop reshaping [E. François, C. Chevance,

F. Hiron (Technicolor)]
This document describes a block-based implementation of the in-loop luma reshaping approach proposed
in contributions JVET-L0246 and JVET-L0247. In-loop luma reshaping requires at the decoder two basic
sample mapping operations: forward reshaping of the prediction signal, inverse reshaping of the
reconstructed signal. Both operations are by default operated per sample, requiring a per-sample access to
a look-up-table. In the proposed approach, the process is performed per block. For each 4x4 block, linear
model parameters are computed from three luma values and their mapped version. The linear model is
then applied to the block samples. The proposal results in PSNR-Y, U, V BD-rate variations compared to
the VTM3.0 of -0.74%, 1.49%, 1.22% in AI configuration, -1.17%, 1.50%, 1.50% in RA configuration, -
0.54%, 2.62%, 3.21% in LB configuration.
The described method does not perform quite as well as the per-sample look-up.
Some banding was reported for content with flat areas (esp. screen content).
Further work was encouraged to try to find some complexity reduction of the remapping process,
although this scheme does not seem adequate as-is.
Page: 256 Date Saved: 2019-03-172019-03-14

It was commented that for hardware it might actually be easier to do the per-sample processing, as this
avoids the extra step of computing an average.
JVET-M0580 Crosscheck of JVET-M0109 (CE12-related: block-based in-loop luma

reshaping) [T. Lu, P. Yin (Dolby)] [late]
JVET-M0640 CE12-related: in-loop reshaping with approximate inverse mapping function

[E. Francois (Technicolor)] [late]
This contribution relates to the in-loop luma reshaping approach proposed in contributions JVET-L0246
and JVET-L0247. In-loop luma reshaping requires at the decoder two basic sample mapping operations:
forward reshaping of the prediction signal, inverse reshaping of the reconstructed signal. In its current
implementation, the forward mapping can be achieved on-the-fly per sample using simple operations,
whereas inverse mapping requires more complex operations. In this contribution it is proposed to
approximate the inverse mapping function using a piece-wise linear (PWL) model of limited size, each
piece being defined per luma interval of fixed length, power of 2, so that simple shifting can be used to
identify the interval containing the sample value to map. It is reported that for most of the natural
sequences, the gain of in-loop reshaping an be preserved using the proposed approximation with a PWL
model size of 32 elements. For class E, F and some HDR content, larger PWL model size is required.
As with the technique described in JVET-M0109, some artefacts and loss were observed, although further
work was encouraged to try to find some complexity reduction of the remapping process, although this
scheme does not seem adequate as-is.
JVET-M0703 Crosscheck of JVET-M0640 (CE12-related: in-loop luma reshaping with

approximate inverse mapping function) [T. Lu, P. Yin] [late]
6.13 CE13 related – Coding tools for 360° omnidirectional video (8)
Contributions in this category were were considered in a BoG reported in JVET-M0874. See section 5.13.
JVET-M0322 CE13-related: In-loop filters disabled across face discontinuities on PHEC

with 2-pixel padding [Y. Sun, X. Huangfu, L. Yu (Zhejiang Univ.)] [late]
JVET-M0810 Crosscheck of JVET-M0322 (CE13-related: In-loop filters disabled across

face discontinuities on PHEC with 2-pixel padding) [P. Hanhart
JVET-M0323 CE13-related: Adaptive QP to improve subjective quality for PHEC [Y. Sun,

X. Huangfu, L. Yu (Zhejiang Univ.)] [late]
JVET-M0811 Crosscheck of JVET-M0323 (CE13-related: Adaptive QP to improve

subjective quality for PHEC) [P. Hanhart (InterDigital)] [late]
Page: 257 Date Saved: 2019-03-172019-03-14

JVET-M0534 CE13-related: HEC with Pre-rotation + Adaptive Frame Packing (Test
4.2.a+4.1) [C. Pujara, A. Konda, A. Singh, R. Gadde, W. Choi, K. Choi,
K. P. Choi (Samsung)] [late]
JVET-M0645 Crosscheck of JVET-M0534 (CE13-related: HEC with Pre-rotation +

Adaptive Frame Packing (Test 4.2.a+4.1)) [P. Hanhart (InterDigital)] [late]
JVET-M0225 AHG8: On wrap around motion compensation [B. Choi, W. Feng, S. Liu

(Tencent)] [late]
JVET-M0368 AHG8: 360Lib support for chroma sample location in PHEC blending
process [C.-H. Shih, Y.-H. Lee, J.-L. Lin, Y.-C. Chang, C.-C. Ju (MediaTek)]
JVET-M0644 Crosscheck of JVET-M0368 (AHG8: 360Lib support for chroma sample

location in PHEC blending process) [P. Hanhart (InterDigital)] [late]
JVET-M0452 AHG8: Hemisphere cubemap projection format [J. Boyce,

M. Dmytrychenko (Intel)] [late]
JVET-M0547 360° coding tools using uncoded areas [J. Sauer, M. Bläser (RWTH Aachen
Univ.)] [late]
JVET-M0892 CE-13 related: Loop filter disabled across virtual boundaries [S.-Y. Lin,
L. Liu, J.-L. Lin, Y.-C. Chang, C.-C. Ju (MediaTek), P. Hanhart, Y. He
6.14 Loop filtering tools (14)

Contributions in this category were discussed Sunday 13 Jan. 1530–1800 and Monday 14 Jan. 1600-1715
(Track B chaired by JRO).
JVET-M0162 Adaptive loop filter with a maximum number of luma filters per slice
constraint [C.-Y. Chen, Z.-Y. Lin, C.-Y. Lai, Y.-W. Huang, S.-M. Lei
(MediaTek)]
This contribution proposes a “maximum number of luma filters per slice” constraint to adaptive loop filter
(ALF) in order to reduce the storage of filter coefficients in the on-chip memory. In the current ALF
design, up to 25 luma filters can be signalled and used in one slice, which requires one on-chip memory
with size equal to 25 filters x 13 coefficients per filter x 8 bits per coefficient = 2600 bits. The proposed
method is to constrain the number of luma filters per slice. When the maximum number of luma filters is
reduced from 25 to 16, the BD-rates for AI, RA, and LB are 0.00%, 0.00%, and 0.00%, respectively and
36% on-chip memory of luma filter coefficients is saved. When the maximum number of luma filters is
Page: 258 Date Saved: 2019-03-172019-03-14

12, the BD-rates for AI, RA, and LB are 0.01%, 0.01%, and -0.01%, respectively, and 52% on-chip
memory of luma filter coefficients is saved. When the maximum number of luma filters is 8, the BD-rates
for AI, RA, and LB are 0.04%, 0.04%, and 0.01%, respectively, and 68% on-chip memory of luma filter
coefficients is saved.
Generally, not a big deal (low amount of memory saving, while possibly giving up flexibility). It is
however argued by proponents that this becomes more relevant together with JVET-M0163.
JVET-M0618 Crosscheck of JVET-M0162 (Adaptive loop filter with a maximum number

of luma filters per slice constraint) [Y.-W. Chen (Kwai Inc.)] [late]
JVET-M0163 Adaptive loop filter with history filters [C.-Y. Chen, Z.-Y. Lin, C.-Y. Lai, Y.-
W. Huang, S.-M. Lei (MediaTek)]
This contribution proposes history filters in adaptive loop filter (ALF). The concept of history filters is to
allow using history filters for the current slice to increase coding efficiency, where the history filters are
decoded filters from previously decoded slices. When the maximum number of history filter set is five,
where one filter set contains all signalled filters of one slice, BD-rate savings are 0.16% and 0.34% for
RA and LB, respectively, and the required memory of history filter set storage is 1660 bytes (5 sets * 25
luma filters per set * 13 coefficients per luma filter * 1 byte per coefficient + 5 sets * 1 chroma filter per
set * 7 coefficients per chroma filter * 1 byte per coefficient). To reduce the memory requirement, it is
further proposed to apply history filters with the “maximum number of luma filters per slice” constraint in
JVET-M0162. When the maximum number of luma filters per slice is reduced from 25 to 16, BD-rate
savings are 0.16% and 0.33% for RA and LB, respectively, and the required memory size is 1075 bytes
(65% of no constraint). When the maximum number of luma filters per slice is 12, BD-rate savings are
0.15% and 0.33% for RA and LB, respectively, and the required memory size is 815 bytes (49% of no
constraint).
The proposal targets compression improvement by re-using filters from previous pictures. The argument
of saving on-chip memory (as under JVET-M0162) is not fully understood, as it would be external
memory that is needed to store the coefficients along with the refernce pictures.
The reduction in bit rate is relatively low, and the approach would introduce some additional dependency
between parameters of pictures. The current design of coding ALF parameters independently for every
picture is quite clean.
It was also asked how it is determined which filter to use. This is based on matching with the covariance
matrix.
No action.
JVET-M0619 Crosscheck of JVET-M0163 (Adaptive loop filter with history filters) [Y.-W.
Chen (Kwai Inc.)] [late]
JVET-M0164 Adaptive loop filter with virtual boundary processing [C.-Y. Chen, T.-D.
Chuang, Z.-Y. Lin, C.-Y. Lai, Y.-W. Huang, S.-M. Lei (MediaTek)]
In the adaptive loop filter (ALF) of VTM3.0, 7x7 diamond filters with 4x4 block-based classification are
used for luma, and a 5x5 diamond filter without classification is used for chroma, which induces seven
luma sample line buffers and four chroma sample line buffers in ALF implementation at the decoder. In
order to reduce the line buffer requirement, ALF with virtual boundary (VB) processing is proposed:
when one sample located at one side of a VB is filtered, accessing samples located at the other side of the
VB is forbidden. The originally required samples at the other side of the VB are replaced with padded
samples. To accommodate deblocking filter (DF) and sample adaptive offset (SAO) in VTM3.0, the VBs
are set as four luma lines and two chroma lines above CTU row boundaries. It is reported that ALF with
Page: 259 Date Saved: 2019-03-172019-03-14

VB processing results in 0.07%, 0.10%, and 0.11% BD-rates for AI, RA, and LB, respectively, while the
VB processing can totally remove the line buffer requirement of ALF.
It is asked whether this might introduce artefacts that make the CTU structure visible. The proponents
report that they include a weighted average after the filtering, where the original sample is superimposed
in a weighted fashin with the filtered sample. It is reported that such an approach in the context of HEVC
ALF was effective to avoid visibility of artefacts.
Generally, the reduction of line buffers is very desirable, and would also justify the reported compression
loss. It would however definitely be necessary to assess if it might introduce viusal artefacts in the context
of VVC and its ALF design.
Similar concept in JVET-M0301.
Investigate in CE, and this should include subjective testing
JVET-M0730 Crosscheck of JVET-M0164 (Adaptive loop filter with virtual boundary

processing) [T.-H. Li, P.-H. Lin (Foxconn)] [late]
JVET-M0277 Fixes of enabling pcm_loop_filter_disabled_flag with pcm mode signalling

under dual tree partition [L. Zhang, K. Zhang, H. Liu, J. Xu, Y. Wang,
In current VVC, PCM mode flags for luma and chroma components are signalled separately when dual
tree partition is enabled. However, when the pcm_loop_filter_disabled_flag is enabled, determination of
enabling/disabling SAO filtering process for chroma blocks is wrongly based on the signalled PCM mode
flag for luma blocks. In addition, ALF is performed even when pcm_loop_filter_disabled_flag is true. In
this contribution, these two issues are fixed wherein whether to filter a block is dependent on the signalled
PCM mode flag for the associated color component. Simulation results reportedly show that there is no
performance changes under common test conditions.
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.
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.
Some experts commented that it might be better to get rid of PCM mode, as it is hardly used in practical
encoders. This issue was also shortly raised in the closing plenary; it could be an action item for future
consideration.
JVET-M0614 Crosscheck of JVET-M0277 (Non-CE: Fixes of enabling

pcm_loop_filter_disabled_flag with PCM mode signalling under dual tree
partition) [Y.-C. Sun (Alibaba)] [late]
JVET-M0301 Non-CE: Loop filter line buffer reduction [A. M. Kotra, S. Esenlik, B. Wang,
H. Gao, J. Chen (Huawei)]
The current contribution proposes a mechanism of reducing the line buffer requirement of ALF (adaptive
loop filter). The contribution uses the concept of virtual boundaries (VBs) which are upward shifted
horizontal CTU boundaries by “N” samples. Modified ALF block classification and modified ALF
filtering are applied for the samples which are near the virtual boundary to reduce the number of line
buffers required. Modified ALF block classification only uses the samples which are above the VB to
classify the given 4 x 4 block which is above VB. Similarly for the classification of the 4 x 4 block below
VB, samples belonging to the lines below the VB are used. Modified ALF filtering uses a combination of
conditional disabling and truncated versions of the original ALF filter.
Page: 260 Date Saved: 2019-03-172019-03-14

Objective results are as follows: Over VTM 3.0 Anchor, for the case when “N” is 4 (AI, RA, LDB, LDP):
Luma BD-Rate of 0.07%, 0.09%, 0.08%, 0.07% with no increase in EncT and DecT.
Over VTM 3.0 Anchor, for the case when “N” is 6 (AI, RA, LDB, LDP): Luma BD-Rate of 0.10%,
0.12%, 0.16%, 0.16% with no increase in EncT and DecT.
In terms of virtual boundary, the method is following the same concept as JVET-M0164. It is however
somehow different in how the classification for padded samples is determined.
Investigate in CE, and this should include subjective testing.
JVET-M0553 Crosscheck of JVET-M0301 (Non-CE: Loop filter line buffer reduction) [C.-
M. Tsai (MediaTek)] [late]
JVET-M0353 In-loop filtering: Simplification of ALF coefficients merge [M. Ikeda,

T. Suzuki (Sony)]
In this contribution, the simplification of ALF (Adaptive Loop Filter) coefficients merge is proposed. In
VTM-3.0, ALF coefficients can be merged after deriving 25 sets of luma filter coefficients in order to
reduce signalling bits overhead in encoder side. In the merge process, pairs of classification index to be
merged are identified by an exhaustive search. In this contribution, three variants are presented, and they
can simplify the process and provide the similar coding efficiency: variant1: AI 0.07%, RA 0.10% LDB
0.18%, variant2: AI 0.08%%, RA 0.11% LDB 0.15%, variant3: AI 0.07%, RA 0.09% LDB 0.17%,
respectively.
The approach would simplify the syntax, but add a number of tables to describe which options of merging
can be used (less flexible than the current method) Furthermore, all three methods give a loss. The benefit
in runtime reduction is not visible. No action.
JVET-M0728 Crosscheck of JVET-M0353 (Non-CE: Simplification of ALF coefficients

merge Variant 3) [N. Hu (Qualcomm)] [late]
JVET-M0724 Crosscheck of JVET-M0353 (Non-CE: Simplification of ALF coefficients

merge) [G. Laroche, J. Taquet (Canon)] [late]
JVET-M0385 Non-linear Adaptive Loop Filter [J. Taquet, C. Gisquet, G. Laroche, P. Onno

(Canon)]
This contribution introduces an adaptive clipping operation on the input samples values of the Adaptive
Loop Filter in VTM3.0. The goal of this adaptive clipping is to introduce some non-linearities to cap the
difference between the input sample value to be filtered and the other neighbour input sample values of
the filter.
Compared to VTM3.0, the average Luma/Cr/Cb BDR gains are reported to be -0.44%/-0.49%/-0.69% for
the AI configuration, -0.70%/-1.00%/-1.04% for the RA configuration, -0.72%/-0.94%/-1.22% for the
Low Delay B configuration, and -1.02%/-1.44%/-1.58% for the Low Delay P configuration.
The method requires 24 subtractions and 24 clipping operations per sample. Threshold values for clipping
are determined by solving a linear equation system and using the covariance matrix, and are signalled (12
per luma filter, 6 per chroma filter). Encoder runtime is approx. unchanged, decoder runtime increases by
roughly 30% on average.
It was agreed to sStudy this in a CE.
Page: 261 Date Saved: 2019-03-172019-03-14

JVET-M0766 Crosscheck of JVET-M0385 (Non-linear Adaptive Loop Filter) [M. Ikeda
(Sony)] [late]
JVET-M0428 Encoder optimization with deblocking filter [N. Hu, V. Seregin, W.-J. Chien,
Deblocking filter is included in VTM-3.0 to apply to reconstructed pixels in order to reduce the blocking
artefacts between blocks. However, the encoder of VTM-3.0 doesn’t apply the deblocking filter in rate
distortion optimization (RDO). In this contribution, to enhance the coding performance, deblocking filter
is applied during RDO, such that distortion is calculated between filtered reconstructed pixels and original
ones. Test results reportedly show 0.58%, 0.71% and 0.66% luma gain with similar encoding and
decoding time, in AI, RA and LDB configuration respectively over VTM-3.0 anchor.
Decision (SW): Adopt JVET-M0428, not for CTC.
Some CE might to use this for additional comparison exercising normative vs. non-normative
optimizations.
However, when VVC performance is compared e.g. against HEVC, such tricks should not be used, or the
HM should use such option as well.
JVET-M0612 Crosscheck of JVET-M0428 (Encoder optimization with deblocking filter)

[Y.-C. Sun (Alibaba)] [late]
JVET-M0429 Coding tree block based adaptive loop filter [N. Hu, V. Seregin, H. Egilmez,
JVET-M0243 Cross-check of JVET-M0429 (Coding tree block based adaptive loop filter)
[S.-C. Lim, J. Kang, H. Lee, J. Lee (ETRI)] [late]
In this proposal, the coding tree block (CTB) based ALF scheme proposed in JVET-K0382 and JVET-
L0391 was tested in VTM-3.0. Test results reportedly show 0.16%, 0.51% and 0.67% luma gain with
similar encoding and decoding time, in AI, RA and LDB configuration respectively over VTM-3.0
anchor.
Each CTU can select one out of 22 filter sets (16 fixed, 5 temporal, 1 picture optimized). The 16 fixed
filters were optimized from HM encoded, range of qualities as in common test conditions.
As it was said before (see comments under JVET-M0163), the usage of temporal filter sets might be
undesirable, as it introduces further dependency between pictures.
(It is noted that depending on possible alternatives how the filter parameters would be signalled in HLS,
the above comment might need to be revised.)
It is also asked how the performance would be in non-CTC QP ranges, as the fixed sets were ptimized
specifically for the CTC QPs.
Compared to previous proposals on this issue, the gain is similar, but the encoding complexity is not
increased.
Study in CE, also considering the questions above, performance without temporal filters, lower QP range.
Page: 262 Date Saved: 2019-03-172019-03-14

JVET-M0461 Alternate ALF filter shapes for luma [D. Socek, A. Puri (Intel)]
In the contribution, it is proposed to modify luma filter shape for adaptive loop filter (ALF). In VTM3.0,
the ALF shape for luma is fixed to 7x7 diamond (25 taps and 13 unique coefficients). Two modified luma
ALF shapes are considered: (1) combined 7x7 diamond and 9x9 cross filter with fully symmetric
outermost cross coefficient (29 taps and 14 unique coefficients, Figure 1a), and (2) combined 7x7
diamond and 9x9 cross filter with fully symmetric two outermost cross coefficients (29 taps and 13
unique coefficients). Alternate shapes are combined with TC offsets of -2 for LB and RA, and -6 for AI.
It is reported that, compared to VTM3.0, the first alternate ALF luma shape (1) yields -0.57%, -0.17%,
and -0.36% luma BD-rates for AI, RA, and LB, respectively, while the second ALF luma shape (2) yields
-0.57%, -0.15%, and -0.34% luma BD-rates for AI, RA, and LB, respectively. There are minor runtime
changes in the performed tests.
Beyond the filter shape change, Tc for deblocking is also change.
It is commented that the new filters would require two more line buffers which is undesirable. If
combined with the methods of virtual CTU boundary processing, even more padding would be necessary
than with the existing 7x7 filter, such that likely gain would be considerably reduced.
JVET-M0468 Non-CE: Hadamard transform domain filter [S. Ikonin, V. Stepin, J. Chen

(Huawei)]
This contribution reports simulation results of post-reconstruction filter based on Hadamard transform
similar to one tested in JVET-K-CE14.3b. Depending in filter appliance condition the simulations results
over VTM-3.0 are:
 Test 1: For minimum block size 4x8 and 8x4: -0.50%/-0.72%/-0.58% of the luma BD-rate change
with 106%/103%/102% of encoding time and 105%/101%/101% of decoding time for AI/RA/LDB
configurations correspondingly.
 Test 2: For minimum block size 8x8: -0.37%/-0.64%/-0.50% of the luma BD-rate change with
105%/103%/101% of encoding time and 105%/101%/101% of decoding time for AI/RA/LDB
 Test 3: For minimum block size 8x8 and filtering of inter blocks only: -0.39%/-0.40% of the luma
BD-rate change with 102%/101% of encoding time and 101%/101% of decoding time for RA/LDB
Test 1 and Test 2 are technology-wise identical to what had previously been investigated in CE14 before
the 12th meeting, but after more analysis on the impact on intra prediction pipelining it had not been
adopted.
Test 3 is new, only using the filter for inter blocks, and always using it when coefficients are coded
(CBF=1), has gain of approx. 0.4% for both RA and LB. It is an additional processing stage, with
complexity as per subsequent table (from BoG of last meeting):
[This table is a picture!]
Page: 263 Date Saved: 2019-03-172019-03-14

Filter Comp. Parallel Latency for Latency for Memory How to derive Sequential
shape complexity friendly filtering buffering required filter coeffs operation to
per sample process (in get 1 sample
clock cycles) (bytes) filtered
3x3 0 mult yes 2 X 70 Pre-calculated 5 add;

20 adds + 4 in LUT
1-bit add for (16 of 7-bit 1 look-up
rounding values per table (14
6 checks CU) bytes);
2 check.
It is pointed out that the filtering should also be disabled for CIIP and IBC, as this would have the same
latency problem as intra prediction. Whereas it was said in the last meeting for another proposal (bilateral
filter) that had similar latency problem for inter and only 0.4% for RA, it is interesting to note that the
post-filtering gain seems still to be preserved in VTM3. It is also verbally reported that for the bilateral
filter a new reduced complexity exists (at last meeting, BF was more complex than Hadamard domain
filter). The proponents of BF announce that they intend to submit a late contribution on these changes.
It is discussed what the relation with other approaches, particularly diffusion filter would be. Each of
those would add another stage in the pipeline of prediction, residual generation by inverse transform, etc.,
where one expert argues, that this pipeline should not be extended by too many steps. Complexity-wise,
the diffusion filter is simpler in terms of number of operations per sample (however, has one
multiplication), and a decision on that is still to be made.
During the discussion, it is questioned whether it would be better to enable switching at block level.
Further study in CE for Test 3 with constraint on CIIP and IBC, also version with block-level flag. It
should also be tested how the performance is when it is outside of the loop, i.e. not used for predicting
intra blocks (in which it could be applied somewhere before deblocking).
JVET-M0787 Cross-check of JVET-M0468 (Non-CE: Hadamard transform domain filter)

[J. Ström (Ericsson)] [late]
JVET-M0842 Crosscheck of JVET-M0468 (Non-CE: Hadamard transform domain filter)

[M. Salehifar (LGE)] [late]
JVET-M0885 Non-CE: Reduced complexity bilateral filter [J. Ström (Ericsson)] [late]

To be studied in CE1.
Page: 264 Date Saved: 2019-03-172019-03-14

JVET-M0898 Crosscheck for JVET-M0885 (Reduced complexity bilateral filtering)
[J. Rasch (HHI)] [late]
JVET-M0894 Non-CE: Test on parametrizable bilateral filter from JVET-L0406 in

VTM3.0 [M. Karczewicz (Qualcomm)] [late]
To be studied in CE1.
JVET-M0899 Cross-check of JVET-M0894 (Non-CE: Test on parametrizable bilateral

filter from JVET-L0406 in VTM3.0) [S.-C. Lim, H. Lee, J. Lee, J. Kang
(ETRI)] [late]
6.15 General prediction aspects (0)

6.16 Quantization control (8)

JVET-M0901 BoG report on quantization control related contributions [Y. Ye]

This report was reviewed in Track A on Monday 16 January 1645–1800 (GJS).
There were 8 technical contributions in the quantization control category.
The first BoG session was held 2000–2330 on 15 Janurary 2019 in Olympia. The second BoG session
was held 1300–1510 on 16 January 2019 in Saba.
Section 1 of the document summarizes the BoG’s recommendations. Section 2 of the document contains
detailed notes on the BoG discussions. The following aspects were discussed in the track review:
 JVET-M0188 (On quantization parameter signalling considering CU area) and JVET-M0113 (CE7-
related: Quantization Group size uniformity)
o These two proposals solved the same problem of incoherent quantization group (QG)
definition in VVC draft 3. They proposed essentially the same solution. However, the two
proposals had different ways of expressing their solution in terms of WD text change. The
proponents were encouraged to harmonize the suggested WD changes, and the final decision
on WD text change should be deferred to the editors. The difference between the two
descriptions is purely editorial. Further work was later done to harmonize the text.
Decision: Adopt (text in JVET-M0113).
 JVET-M0119 CE7-related: Modified dequantization scaling
o The second aspect of this proposal was recommended for adoption
o In VVC draft 3, a scaling factor is applied when a transform block is of rectangular shape.
This scaling factor should not be applied in the transform skip case. It was reported that in the
reference software VTM-3.0, the scaling factor is applied in the inverse quantization stage
and then removes it during the inverse transform stage. However, in VVC draft 3, the scaling
factor is applied but not removed, which causes a mismatch between the software and the
Page: 265 Date Saved: 2019-03-172019-03-14

spec. This contribution removes the (unnecessary) application and removal of this scaling
factor for transform skip blocks in the reference software, and proposes a WD change that
fixes the mismatch between software and spec. Decision (bug fix): Adopt.
 JVET-M0685 Non-CE7: On derivation of quantization parameter predictor
o This discusses prediction of the QP value.
o HEVC had a different QP prediction operation for when WPP is on and off. When WPP is
off, any QP change will propagate to all subsequently coded blocks in the slice.
o In the current draft the QP is predicted as the average of the QP above and to the left. If either
of those is outside the CTU, the previous one in decoding order is used as the predictor.
o This is a problem for parallel encoding, e.g., when encoding a CTU at the left edge, the QP
predictor (which is from the right edge) may not be known.
o JVET-M0685 proposed storing the QP values of the bottom of the above CTU and
considering those “available”. If both are available, an average would be used; if one is
unavailable, the other would be used.
o In the discussion of the contribution, another method was discussed, which was to only have
the QP of the above CTU available if the current CTU is the first CTU of the row.
o It was noted that the QP values of the neighbour are already stored for deblocking purposes,
so they could be used. Another person commented that the storage for deblocking may be in a
different part of the decoding pipeline that would not be readily available.
o The left-edge-only idea was suggested to potentially be beneficial for rate control in avoiding
“dilution” of a delta QP.
o 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 (text was provided in a revision of JVET-M0685).
The BoG recommended further study in an AHG on quantization control. This was agreed to be
established.
It was noted that MTS affects the concept of quantization matrices.
JVET-M0083 AHG10: Quantization matrices for MTS [T. Toma, K. Abe (Panasonic)]
JVET-M0342 Crosscheck of JVET-M0083 (AHG10: Quantization matrices for MTS)

[M. Ikeda (Sony)]
JVET-M0105 Delta QP for Chroma CU [R. Chernyak, S. Ikonin, J. Chen (Huawei)]
JVET-M0188 On quantization parameter signalling considering CU area [O. Chubach, T.-

D. Chuang, C.-W. Hsu, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0707 Crosscheck for JVET-M0188: CE7-related: On quantization parameter

signalling considering CU area [Y. Wang, X. Xu (Tencent)] [late]
Page: 266 Date Saved: 2019-03-172019-03-14

JVET-M0113 CE7-related: Quantization Group size uniformity [P. de Lagrange,
E. François, P. Bordes (Technicolor)]
JVET-M0114 CE7-related: implicit QP-offset based on block size [P. de Lagrange,

E. François, F. Le Léannec (Technicolor)]
JVET-M0119 CE7-related: Modified dequantization scaling [K. Sharman, S. Keating

(Sony)]
JVET-M0318 CE7-related: QP prediction and neighbour availability [P. de Lagrange,

P. Bordes (Technicolor)]
JVET-M0685 Non-CE7: On derivation of quantization parameter predictor [K. Misra,

A. Segall (Sharp Labs of America)] [late]
6.17 Entropy coding (1)

JVET-M0222 Context Reduction for CABAC in VVC [Y.-H. Chao, A. Said, V. Seregin,
J. Dong, M. Karczewicz (Qualcomm)]
Discussed Thu 8pm. Chaired by FJB
No planned CE on context reduction.
Encouraged to resubmit in future meetings when cleaning up spec.
JVET-M0617 Crosscheck of JVET-M0222 (Context Reduction for CABAC in VVC) [Y.-C.

Sun (Alibaba)] [late]
6.18 Tools based on NN technology (7)

Contributions in this category were discussed Monday 14 Jan. 1815–1945 (chaired by JRO). A BoG was
then requested to further discuss this area, as reported in JVET-M0904.
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 (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.
Page: 267 Date Saved: 2019-03-172019-03-14

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.
o 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)
o For SubCE2:
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,
Page: 268 Date Saved: 2019-03-172019-03-14

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-M0159 AHG9: Convolutional neural network loop filter [Y.-L. Hsiao, C.-Y. Chen,
T.-D. Chuang, C.-W. Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
This document presents two modifications of convolution neural network loop filter (CNNLF) introduced
in JVET-K0222. The first modification is to reduce two 4-layer networks separate for luma and chroma to
only one 3-layer network shared by luma and chroma. The second modification is to conditionally signal
the CNNLF parameters in the I-slice header. Compared with VTM3.0, the proposed CNNLF reportedly
achieves -1.23% (Y), -10.11% (Cb), and -9.96% (Cr) BD-rates with 42% decoding time increase in
random access (RA) condition without using any GPUs. After shifting coding gain from chroma to luma
by increasing chroma quantization parameter (QP) offsets, the BD-rates are -2.47% (Y), +2.90% (Cb),
and +3.01% (Cr). It is shown that Class C (small resolution, 832x480) has no coding gain because of the
relatively “expensive” side information bits of CNNLF parameters while Class A (large resolution,
3840x2160) has higher coding gains (-3.7% luma BD-rate and +3% chroma BD-rate). Further research on
CNNLF to reduce complexity and enhance training for improving coding efficiency is suggested.
It is assumed that the CNN parameters are offline trained per RA period.
Results with chroma QP offset are non-CTC, difficult to conclude something from that.
It is reported that the gain becomes lower for low resolution sequences such as class C, due to the higher
relative amount of network parameters (which is about 10 kbit/s).
Software would be available.
JVET-M0771 Crosscheck of JVET-M0159 (AHG9: Convolutional neural network loop

filter) [H. Dou, Z. Deng, J. Boyce (Intel)] [late]
JVET-M0215 AHG9-related: CNN-based lambda-domain rate control for intra frames

[Y. Li, D. Liu, Z. Chen (USTC)]
This contribution proposes a CNN-based λ -domain rate control approach for intra frame coding.
Compared with the exiting SATD-based intra rate control approach in VTM, the contribution reuses the
R-lambda model in VTM inter frame rate control and train two convolutional neural networks to predict
the model parameters, alpha and beta respectively. Compared with the rate control method in VTM 3.0,
the proposed method can achieve an average bd-rate reduction of 2% under All Intra configuration. When
considering the mismatch between target bit rate and actually coded bit rate, the CNN-based method can
achieve a smaller rate control error, especially for the first I frame.
The uploaded presentation deck is different from the one shown in the presentation.
Approximately 5% run time increase compared to current rate control (CPU).
Software would be available. To be further studied in the AHG on NN technology.
Very interesting to see that NN based rate control can outperform conventional approaches, but extension
of its applicability to other frames (e.g. predicting rates for the different levels of B picture hierarchy)
would be desirable.
Page: 269 Date Saved: 2019-03-172019-03-14

JVET-M0907 Crosscheck of AHG9-related: CNN-based lambda-domain rate control for
intra frames [X. Zheng, Y. Wang (DJI)] [late]
JVET-M0351 Convolutional Neural Network Filter (CNNF) for Intra Frame [C. Lin,
J. Yao, L. Wang (Hikvision)] [late]
This contribution provides a convolutional neural network filter (CNNF) for intra frames. In the current
VTM, multiple filters, i.e., deblocking filter (DF) and sample adaptive offset (SAO) are used to remove
artefacts or improve performance. CNNF is motivated by the latest advances in deep learning and is
proposed as a single type of filter to replace multiple filters in intra frame. Simulation results report -
4.94%, -7.07%, -8.17% BD-rate savings for luma, and both chroma components for VTM-3.0 with AI
configuration.
Same method was proposed in JVET-I0022 (by that time run on top of JEM). Similar gain.
Software was already released by that time.
JVET-M0743 Crosscheck of JVET-M0351 (AHG9: Convolutional Neural Network Filter

(CNNF) for Intra Frame) [Y. Dai, D. Liu, Y. Li, F. Wu] [late]
JVET-M0508 AHG9: Test Results of Dense Residual Convolutional Neural Network based
In-Loop Filter [Y. Wang, Z. Chen, Y. Li (Wuhan Univ.), L. Zhao, S. Liu,
X. Li (Tencent)]
This contribution reports the test results for dense residual convolutional neural network based in-loop
filter (DRNLF) JVET-L0242 according to the methodology in JVET-L1006. The proposed DRNLF is
implemented on VTM 3.0. Simulation results report -2.17%, -1.47%, -1.48% BD-rate savings for luma ,
and both chroma components compared with VTM 3.0 under AI configuration in CPU only platform, and
-2.15%, -3.04%, -1.96% for RA configuration, and -2.06%, -3.73%, -2.86% for LDB configuration.
Operated between deblocking and SAO.
Different networks were trained specifically for the different QP values of CTC.
It is noted that it would be interesting to investigate how large the loss would be when used for another
QP value.
Gain over VTM3 is slightly lower than it was for VTM2.
JVET-M0510 AHG9: CNN-based in-loop filter proposed by USTC [Y. Dai, D. Liu, Y. Li,
F. Wu (USTC)] [late]
This contribution presents the simulation results of an efficient network for loop filter. To reduce storage
space and reduce complexity, we build two light weight deep convolutional neural networks by reduce
network parameters. Simulation results report -0.96%, -0.32%, -0.45% BD-rate savings for Y, Cb, and Cr
components compared with VTM3.0 under AI configuration, -0.61%, -0.25%, -0.26% for RA
configuration, and -0.76%, -0.56%, -0.69% for LDB configuration.
Operated between deblocking and SAO.
For AI; Decoding time 21x/13x for the two versions used. For LB: 3-4x. Encoding time increases approx.
25%.
Can be enabled/disabled at CTU level.
Question: Does this produce visual artefacts?
Page: 270 Date Saved: 2019-03-172019-03-14

JVET-M0673 Crosscheck of JVET-M0510: AHG9: CNN-based in-loop filter proposed by
USTC [F. Chen (Hikvision)] [late]
JVET-M0566 Adaptive convolutional neural network loop filter [H. Yin, R. Yang, X. Fang,
S. Ma, Y. Yu (Intel)] [late]
This document proposes an adaptive convolution neural network loop filter (ACNNLF) design. In this
design, 3 CNN based loop filters are adaptively trained for luma and chroma respectively from the current
video sequence. Each filter is a small 2 layer CNN with total 692 parameters. The encoder selects one of
the three ACNNLFs for luma and chroma respectively for each CTB block during encoding. The weights
of the trained set of ACNNLFs are signalled in the slice header of I frames and the index of selected
ACNNLF is signalled for each CTB.
Compared with VTM-3.0-RA, the proposed ACNNLF achieves -2.37%, -1.34%, and -2.77% BD-rates for
Y, U, and V, respectively, for Class A1 video sequences; -0.45%, -10.92%, and -6.19% BD-rates for Y,
U, and V, respectively, for Class A2 video sequences; -0.49%, -11.29%, and -10.73% BD-rates for Y, U,
and V, respectively, for Class B video sequences; and 0.12%, -3.31%, and -1.62% BD-rates for Y, U, and
V, respectively, for Class C video sequences.
Operated after ALF (last loop filter)
Two different CNN for luma and chroma. At CTU level, it can be decided which out of three filters to use
(or no filter). An additional weighting is signalled at slice level, which weights the residual that is
generated by the network and superimposed.
The gain comes mainly from a few sequences (Campfire has the biggest gain).
JVET-M0691 AHG9: Complexity analysis about neural network video coding tools [Y. Li,
Z. Chen (Wuhan Univ.), S. Liu (Tencent)] [late]
Reviewed in BoG JVET-M0904.
JVET-M0872 AHG9: A Result of Convolutional Neural Network Filter [K. Kawamura,

S. Naito (KDDI)] [late]
This contribution contains a performance evaluation of the convolutional neural network filter proposed
in JVET-L0383. Compared with the contribution in the previous meeting, the result in this meeting comes
from not only intra picture but also from inter picture. Coding gain of Y BD-rates are -1.65% / -1.82% /
00.49% for all intra, random access, and low-delay B condition, respectively.
Previous contribution had only results on AI. Gains in AI over VTM3 are similar as they were over
VTM2.
qqBoG on planning a CE on NN based loop filters (Yiming Li). The main target of that CE should be to
investigate the impact of adaptation/switching (e.g. sequence basis, CTU basis, QP related); impact of
position in the loop filtering chain; investigate performance and complexity of different architectures, etc.
6.19 High-level syntax (53)

Contributions in this category were discussed XXday X Jan. XXXX–XXXX (chaired by XXX)Two
BoGs were held on topics in this area, reported in JVET-M0782 and JVET-M0816.
6.19.1 General high-level syntax and parameter sets (212)
Page: 271 Date Saved: 2019-03-172019-03-14

JVET-M0776 AHG17&AHG15: A summary of JVET-M contributions on general HLS
[Y.-K. Wang (Huawei)] [late]
6.19.1.1General high-level syntax and NAL unit header (11)
JVET-M0816 BoG report on high level syntax [J. Boyce]

This BoG report was reviewed in Track A Sunday 13 January 1530 and further discussed Wednesday 16
January 1400 (GJS).
The BoG suggested discussion in the track or plenary regarding:
 Ask the following questions to ALF experts, for consideration when evaluating proposed solutions to
improve coding efficiency of tile group headers:
1) How much bit rate do ALF parameters typically require? Perhaps typically about 200 bits (4 luma
and 1 chroma), could be up to perhaps 2k bits
2) Do we expect that multiple pictures would use the same ALF parameters? 0.5% for RA in JVET-
M0429. It was said to be undesirable to put them in the PPS since they change frequently.
3) What is the expected coding gain when ALF is used?
4) Does the ALF design support having different ALF parameters in different tile groups in the same
picture? This hasn’t been tested but seems necessary to support having tiles that were generated
by different encoders, and potentially desirable for other reasons as well.
5) If it is allowed to have different ALF parameters in different tile groups in the same picture, do
we expect that they would frequently differ? See previous item. It hasn’t been tried.
The BoG met on 11 Jan 2019. The BoG also met on 12 Jan 2019, with the notes reflected in the -v2
version of the report document.
Decision: The following BoG recommendations were adopted in Track A:
 Replace the existing IRAP_NUT with 3 new NAL unit types: IDR_W_RADL, IDR_N_LP,
CRA_NUT (from JVET-M0101).
 Add external means flag HandleCraAsCvsStartFlag, with similar text as in HEVC. Text provided in a
v3 of JVET-M0101.
 Add a NUT value for step-wise temporal access STSA (from JVET-M0101).
 Add a NUT value for AUD (from JVET-M0101).
 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 text of sections 7.4.2.4 to 7.4.2.4.5 on NAL unit order and AU boundary detection from JVET-
M0101, which is primarily editorial, but has some technical aspects.
 Add profile_tier_level( ) syntax structure which includes sub-layer level idc (similar to HEVC but
without sub-layer-specific profiles).
 Add general_non_packed_constraint_flag with semantics as in JVET-M0101 (rename the flag to
display_suitability_flag? – that’s editorial).
 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 as in option 1, subject to review by the 360° BoG (minor cleanup).
Page: 272 Date Saved: 2019-03-172019-03-14

 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.
 Consider between adding 2 NUT values for RASL and RADL leading pictures or staying with no
dedicated NUT values for leading pictures. Decision: Add RASL and RADL NUTs.
Further review of the BoG results was conducted Monday 14 January 1330 (GJS)
 Consider whether profile_space should be included. This, and profile compatibility flags, were agreed
to be for further study.
 Consider removing concept of I, P, and B slice (tile group) types, but to have flags to control the
types of prediction (intra prediction, current picture referencing, inter prediction with one list or two
lists), and whether this signalling should be for pictures or for tile groups. It was commented that it
may not be necessary to indicate at the tile group level whether CPR is used in the tile or not. (Note
that a tile has no header.) No need for action on this was identified.
 Consider whether an AHG should be formed to study solutions to problem of temporal judder when
temporal scalability sub-bitstream extraction is used to lower frame rate. Consider whether this
should have a normative impact or be supported in an SEI message (which could perhaps be done in
JCT-VC for HEVC or AVC). Such a study could include consideration of pre- and post-processing.
See JVET-M0579. It was suggested to establish an AHG on layered-coding scalability and resolution
adaptation, and to include this topic in its mandates.
 Consider whether there is interest to normatively specify Gradual Decoder Refresh (GDR) operation,
such that a conforming CVS can start with a GDR non-IRAP picture (as proposed in JVET-M0529).
Further study in an AHG was encouraged. Some issues for study include how HRD interacts with the
use case and whether it would be a burden to decoders to be required to support this capability.
The BoG also met 15 Jan from 1800 to 1930, with the notes reflected in the -v3 version of this document.
This was discussed in Track A Wednesday 16 January 1400-1445.
At the 16 January meeting, the BoG also recommended, and Track A agreed, to the following further
recommendation:
 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.
Further study was encouraged for making use of shared values across pictures and different APSs in the
same picture. Further study was also encouraged on whether to relax the constraint on re-using ID values.
JVET-M0776 AHG17&AHG15: A summary of JVET-M contributions on general HLS

[Y.-K. Wang (Huawei)] [late]
Page: 273 Date Saved: 2019-03-172019-03-14

JVET-M0101 AHG17: On VVC HLS [R. Skupin, K. Sühring, Y. Sanchez (HHI),
M. M. Hannuksela, K. Kammachi-Sreedhar (Nokia), Y.-K. Wang, Hendry
(Huawei), S. Wenger, B. Choi (Tencent), S. Deshpande (Sharp), R. Sjöberg
(Ericsson)]
JVET-M0120 Proposed NAL Unit Header Design Principles [S. Wenger, B. Choi, S. Liu
(Tencent)]
JVET-M0131 AHG17: On NAL unit types for IRAP pictures and leading pictures [Y.-K.
Wang, Hendry (Huawei)]
JVET-M0152 AHG17: On random access point for VVC [B. Choi, S. Wenger, S. Liu
(Tencent)]
JVET-M0153 AHG17: On leading picture for VVC [B. Choi, S. Wenger, S. Liu (Tencent)]
JVET-M0156 AHG17: On component type indication for VVC [B. Choi, S. Wenger, S. Liu
(Tencent)] [late]
JVET-M0157 AHG17: On picture order count for VVC [B. Choi, S. Wenger, S. Liu
(Tencent)] [late]
JVET-M0161 AHG17: Signalling random access properties in the NAL unit header
[L. Chen, C.-W. Hsu, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0520 AHG17: On NAL unit header design for VVC [S. Wenger, B. Choi, S. Liu
(Tencent)]
JVET-M0529 AHG14: Normative Recovery Point Indication [M. Pettersson, R. Sjöberg,

M. Damghanian (Ericsson)]
JVET-M0537 AHG17: On tile group signalling in NAL unit header and as non-VCL NAL
unit [E. Thomas, A. Gabriel (TNO)] [late]
Page: 274 Date Saved: 2019-03-172019-03-14

6.19.1.2Reference picture management (3)
JVET-M0128 AHG17: On reference picture management for VVC [Y.-K. Wang, Hendry
(Huawei), S. Deshpande (Sharp), M. M. Hannusela (Nokia), G. Ryu, W. Choi
(Samsung), X. Wang, Y.-W. Chen (Kawi), L. Zhang (Bytedance), P. Wu,
M. Li (ZTE), S.-H. Kim (LG), J. Boyce (Intel), A. M. Tourapis, D. Singer
(Apple), F. Edouard, P. Andrivon (Technicolor), Y.-W. Huang, C.-W. Hsu,
C.-Y. Chen, T.-D. Chuang, L. Chen (MediaTek), K. Kawamura (KDDI), Y.-
C. Sun, J. Lou (Alibaba)]
After BoG discussion, this was discussed Sunday 13 January 1700 (GJS).
This contribution proposes a reference picture management approach for VVC based on direct signalling
and derivation of reference picture lists 0 and 1, without use of reference picture set (RPS) as in HEVC or
the sliding window plus memory management control operation (MMCO) process as in AVC.
It is asserted that the proposed approach is significantly simpler compared to the approaches in HEVC
and AVC.
The proposed direct-RPL-based reference picture management approach is summarized as follows:
Two reference picture lists, list 0 and list 1, are directly signalled and derived. They are not based on RPS
as in HEVC or the sliding window plus MMCO process as in AVC.
Reference picture marking is directly based on reference picture lists 0 and 1, utilizing both active and
inactive entries in the reference picture lists, while only active entries may be used as reference indices in
inter prediction of CTUs.
Information for derivation of the two reference picture lists is signalled by syntax elements and syntax
structures in the SPS, the PPS, and the slice header. Predefined RPL structures are signalled in the SPS,
for use by referencing in the slice header.
The two reference picture lists are generated for all types of slices, i.e., B, P, and I slices.
The two reference picture lists are constructed without using a reference picture list initialization process
or a reference picture list modification process.
Long-term reference pictures (LTRPs) are identified by POC LSBs. When needed, additional POC LSBs
are signalled for LTRPs, determined at a picture by picture basis.
In the discussion, a problem was identified with the POC MSB handling when considering random access
that is not at the start of the first CVS in the “original” bitstream. Instead of signalling MSBs directly, it
was suggested to use the scheme of HEVC with delta_poc_msb_present_flag[ i ] and
delta_poc_msb_cycle_lt[ i ] (and remove the proposed additional MSB length syntax in the PPS).
In the discussion, it was noted that there should be a POC wrap-around prevention constraint for short-
term pictures (see HEVC C.4 item 8). It was agreed that this is needed.
Decision: Adopt with modifications as described above.
JVET-M0154 AHG17: On decoded picture buffer management for VVC [B. Choi,

S. Wenger, S. Liu (Tencent)]
Page: 275 Date Saved: 2019-03-172019-03-14

JVET-M0378 AHG17: RPS for VVC [R. Sjöberg, M. Damghanian, M. Pettersson
(Ericsson)] [late]
6.19.1.3Picture header and header parameter set (HPS) (4)
JVET-M0132 AHG17: On header parameter set (HPS) [Y.-K. Wang, Hendry, J. Chen
(Huawei)]
JVET-M0260 AHG17: Carriage of tile group header parameters in higher level structures
JVET-M0377 AHG17: Picture header NAL unit type [R. Sjöberg, M. Damghanian,

M. Pettersson (Ericsson)]
JVET-M0415 AHG17: Comments on High-Level Syntax of VVC [S. Deshpande (Sharp)]
6.19.1.4Miscellaneous general HLS topics (3)
JVET-M0133 AHG17: On parsing dependency between parameter sets [Y.-K. Wang

(Huawei), J. Boyce (Intel)]
JVET-M0386 AHG17: On slice_type (tile_group_type) [K. Sühring, Y. Sanchez, R. Skupin

(HHI)]
JVET-M0579 On Frame Rate Support and Extraction in VVC [A. Segall, S. Deshpande

(Sharp Labs of America), M. M. Hannuksela (Nokia)]
6.19.2 Interoperability and capability points definition and signalling (1)
JVET-M0451 Update to interoperability point syntax [J. Boyce (Intel)]
6.19.3 Tiling and tile partitioning (2830)

Contributions in this area were initially reviewed in a BoG reported in JVET-M0782 and then discussed
in Track A.
6.19.3.1 General (0)
JVET-M0782 BoG report on tiles and WPP [Y.-K. Wang, M. M. Hannuksela]

This report was discussed in Track A Monday 14 January 1430-1630, 1830-2000 (chaired by GJS)
Page: 276 Date Saved: 2019-03-172019-03-14

This contribution provides the report of the BoG on tiles and WPP.
The BoG recommended the following adoptions:
 Adopt JVET-M00853-v2 and add a NOTE like the following:
NOTE: When extracting an MCTS to form a conforming bitstream, active PPSs in the extracted sub-
bitstream should have signalled_tile_group_id_flag equal to 1.
JVET-M00853-v2 adds the support of rectangular tile groups in addition to the existing raster scan
ordered tile groups, and enables extraction of MCTSs without changing VLC NAL units.
Decision: Adopted, with constraints as follows:
 the tiles in a tile group need to be in raster-scan order.
 the tile groups need to be in increasing address order (see below: dark orange, then light blue, then
pale yellow, then dark blue, then light orange, …)
 The tile group shapes shall be such that each tile, when decoded, shall have its entire left boundary
and entire top boundary consisting of a picture boundary or previously decoded tile(s). In other
words, the light yellow and light green tiles in the figure below are not allowed.
The following tile group picture was drawn for illustration and discussion purposes regarding the above
constraints (an accidental homage to Piet Mondrian).
The BoG recommended to adopt the software implementation in JVET-M0445 into the VTM.
Decision (SW): Adopted.
The software implementation in JVET-M0445 implements encoder motion constraints for MCTSs.
 Add loop_filter_across_tile_group_enabled_flag to the PPS, with syntax as proposed in JVET-
M0160, and semantics as follows:
loop_filter_across_tile_groups_enabled_flag equal to 1 specifies that in-loop filtering operations
may be performed across tile group boundaries in pictures referring to the PPS.
loop_filter_across_tile_group_enabled_flag equal to 0 specifies that in-loop filtering operations are
not performed across tile group boundaries in pictures referring to the PPS. The in-loop filtering
Page: 277 Date Saved: 2019-03-172019-03-14

operations include the deblocking filter, sample adaptive offset filter, and adaptive loop filter
operations. When not present, the value of loop_filter_across_tile_groups_enabled_flag is inferred to
be equal to 0.
Decision: Adopted (confirmed Thursday morning plenary).
 Add an AHG mandate on WPP into AHG 12. This was agreed in Track A.
The BoG and Track A agreed that it was desirable to have WPP support in VVC. The syntax, semantics,
and decoding process for WPP are for further study.
The BoG recommended the following to be discussed:
 Whether to allow tiling with a tile width or tile height that is not a multiple of the CTU size
The late document JVET-M0875 was discussed – see notes on that contribution.
JVET-M0527 raised some concerns related to hardware implementation. And it was commented that in
addition to the issues mentioned in JVET-M0527, this design also causes issues with line buffer ing, as
well as in VDPU rate.
It was commented that a benefit of the design is enable turning off loop filtering across CMP faces. It was
suggested that enabling loop filtering turning off within a tile would be a lighter solution than having this
design. It was commented that there is ongoing CE on this.
Discussion resumed 1920 Monday 14 January (GJS).
It was thus suggested that these two topics should be discussed and decided together.
 The latest HEVC text specifies, as part of the semantics of an SEI message, the MCTS sub-bitstream
extraction process and requires the extracted sub-bitstream to be conforming bitstream. For VVC,
should we do more than this way of defining conformance for MCTSs? For example, should
normative decoding process be specified for decoding of MCTSs instead of just specifying SEI
messages for indication of the encoder motion constraints? There were several related proposals. For
example, whether MCTS sequences are signalled in parameter sets or whether an MCTS sequence
would have its own associated parameter sets. Whether to provide a level definition at the MCTS
sequence level. Whether to define a normative decoder interface and conforming decoding behaviour
for MCTS-specific decoding. Further study is highly encouraged.
 On whether to (allow) treat boundaries of MCTS / sub-picture sequences as picture boundaries (i.e.,
to do padding).
Allowing this is expected to help in coding efficiency. However, it would impose some burden for
hardware implementations. Tests showing coding efficiency gain numbers and an analysis on hardware
implementation complexity are needed for making a decision on this. Note that JVET-M0445 provides a
software implementation that could be used as the basis and anchor for such coding efficiency
comparison.
Interested parties were requested to work offline to prepare the test conditions. This effort was
coordinated by M. Coban, the proposed test conditions were included in JVET-M0870.
It was thus suggested that JVET-M0870 be reviewed.
 Whether an interface for inputting/outputting reference pictures to/from the decoder could be
acceptable in decoder implementation architectures.
This relates to allowing empty tiles and applying geometry padding to fill in the empty tiles in an external
process as proposed in JVET-M0547. The contribution was also discussed in the 360 o video BoG (see that
BoG report).
It was commented that there could be other ways to indicate uncoded areas in the picture than using
empty tiles.
Page: 278 Date Saved: 2019-03-172019-03-14

The contribution would need an interface of outputting reference pictures (with uncoded areas) from the
decoder to an external process and inputting reference pictures (with uncoded areas filled in by geometry
padding) to the decoder from an external process. It was commented that this has some similarity to the
external base layer concept of SHVC.
The bitstream would have some tiles that are not coded. The PPS could indicate where the uncoded areas
are.
It was suggested that the tested benefit for cubeface geometry padding was about 2%. The subjective
benefit may be greater. The anticipated benefit is rather limited, perhaps too small to be of interest by
itself unless there is some other motivation for establishing a similar functionality. There have been other
proposals for considering external management of reference picture memory and external control of the
decoding process below the picture level. If there is a study of that broader potential need for a different
system interface to the video decoding process, this could be part of it.
This was further discussed Wednesday 16 January 1445-1515 (GJS)
It was noted that the BoG had recommended considering JVET-M0375 after flexible tiling had been
resolved.
This proposal would enable extraction of any row(s) or column(s) of tiles while still allowing the default
layout to be indicated rather than requiring use of the explicit layout syntax.
It was commented that this may not fit the way some systems specs have a special mode for when the
tiles are all the same size except at the picture edge. However, the proponent indicated that this scheme is
better than that one for load balancing, and noted that HEVC was also using a default scheme that uses
differing widths across the picture.
Another participant commented that this shifts larger tiles to the top-left and groups those together, which
may not be optimal for load balancing when each thread is processing multiple tiles.
Further study was encouraged to determine whether the load balancing concern is valid and to consider
the alternative of using equal tile sizes except at the right and bottom edges.
JVET-M0774 AHG12: A summary of JVET-M contributions on picture partitioning [Y.-

K. Wang (Huawei), M. M. Hannuksela (Nokia)] [late]
6.19.3.2Tiling allowing tile size unit less than CTU size (5)
JVET-M0066 AHG12: Flexible Tile Partitioning [Y. Yasugi, T. Ikai (Sharp)]
JVET-M0423 Cross-check of JVET-M0066: AHG12: Flexible Tile Partitioning

[A. Wieckowski (HHI)]
JVET-M0376 AHG12: On signalling of flexible tiles [M. Damghanian, R. Sjöberg,

JVET-M0459 AHG12: On tiles with partial CTUs [R. Skupin, K. Sühring, Y. Sanchez,

T. Schierl (HHI)]
Page: 279 Date Saved: 2019-03-172019-03-14

JVET-M0527 AHG12: Comments on Tiles and Flexible Tile Partitioning [W. Wan,
M. Zhou, T. Hellman, B. Heng, P. Chen (Broadcom)]
JVET-M0875 Request for flexible unit size tile with implementation friendly restriction
[T. Ikai, Y. Yasugi (Sharp), G. Bang (ETRI), Y.-W. Chen, X. Wang (Kwai
Inc.), M. Coban (Qualcomm), C.-C. Lin (ITRI), P.-H. Lin (Foxconn),
A. Ichigaya (NHK), K. Kawamura (KDDI), K. Kazui (Fujitsu), R. Sjöberg
(Ericsson), R. Skupin, K. Sühring, Y. Sanchez, T. Schierl (HHI), L. Zhang
(Bytedance)] [late]
This contribution proposes flexible unit size tile with certain restrictions, allowing tiling with tile size unit
that is not a multiple of the CTU size. In the tile BoG, the implementation difficulty for less than CTU
size and loop filter control for 360° video has been discussed. In this contribution, it is asserted that CTU
alignment is too restricted to enable important tile use cases. It is also argued that the proposed specific
restrictions alleviate the concerns implementation cost increase.
In JVET-M0066, the main part of this proposal had reportedly been implemented, tested and cross-
checked. The software and working draft had been uploaded at 2018-12-28 05:28:56 and this was
announced in the JVET main reflector at 2018-12-29.
The contribution reported the following points as the main difficulty for hardware implementation which
could affect cost:
1) Throughput capability, i.e. Partial size CTUs could need the same time processing time as full size
CTUs in pipeline processing.
2) Memory bandwidth / compression, i.e. temporal motion vector or other information needs to be
transferred between internal memory and external memory via burst transfer.
3) Address generator, i.e. address generator needs more flexible calculation which depends on tile
position.
The contribution proposed that the minimum unit granularity (TileUnitSizeY) be required to be 32 or
larger.
A participant commented that if the 32x32 restriction is imposed, the desired functionality can be
obtained with no special support in the standard, at a small loss of coding efficiency – by using 32x32 as
the CTU size.
It was also commented that the 32x32 granularity is still restrictive and may not align with natural content
boundaries.
The proponent showed some test results that indicated that the penalty of using 32x32 CTUs was large.
Other participants questioned whether that penalty could really be that large. The data had not been cross-
checked.
A participant commented that pipelining implementation requires fetching and processing data in large
chunks with a regular structure that this would interfere with.
There were strong concerns about this expressed by some participants. It was said that the 32x32 CTU
case is not as difficult because these come in strings.
Further study was encouraged. It was planned to ask AHG13 to measure the effect of CTU size on coding
efficiency.
Page: 280 Date Saved: 2019-03-172019-03-14

6.19.3.3Flexible tiling (4)
Option 3 of JVET-M0261 is effectively another way to achieve the flexible tiling functionality, through
dividing pictures into rectangular sub-pictures and each sub-picture may refer to its own PPS and may
hence have its own tile partitioning.
JVET-M0123 AHG12: On hierarchical tile design [Y. He, A. Hamza (InterDigital)]
JVET-M0129 AHG12: On flexible tiling [Y.-K. Wang, Hendry, M. Sychev (Huawei)]
JVET-M0374 AHG12: Flexible tiles to support MCTS use cases [R. Sjöberg,

M. Damghanian, M. Pettersson (Ericsson)]
JVET-M0530 AHG12: On signalling of tiles [M. Coban, M. Karczewicz (Qualcomm)] [late]
6.19.3.4Rectangular tile grouping (5)
JVET-M0121 AHG12: On Rectangular Tile Group [Y. He, A. Hamza (InterDigital)]
JVET-M0130 AHG12: On tile grouping [Y.-K. Wang, Hendry, J. Chen, M. Sychev

(Huawei)]
JVET-M0160 AHG17: Flexible tile grouping for VVC [L. Chen, T.-D. Chuang, Y.-W.
JVET-M0209 AHG12: On tile group configuration [W. Choi, K. Choi, K. Choi (Samsung)]
JVET-M0416 AHG12: On Tile Information Signalling [S. Deshpande (Sharp)]
6.19.3.5Tile and tile group identification and addressing (5)
JVET-M0134 AHG12: On explicit signalling of tile IDs [Hendry, Y.-K. Wang, J. Chen,
M. Sychev (Huawei)]
JVET-M0155 AHG12: On tile group identification for VVC [B. Choi, S. Wenger, S. Liu
(Tencent)] [late]
Page: 281 Date Saved: 2019-03-172019-03-14

JVET-M0373 AHG12: Merge friendly tile group address signalling [R. Sjöberg,
M. Damghanian, M. Pettersson (Ericsson)]
JVET-M0430 AHG12: On Tiles and Tile Groups for VVC [R. Skupin, K. Sühring,
Y. Sanchez, T. Schierl (HHI)]
JVET-M0853 AHG12: On Tile Grouping [S Deshpande (Sharp), Hendry, Y.-K. Wang

(Huawei), M. M. Hannuksela (Nokia), Y. He (Interdigital), L. Chen
(MediaTek), W. I. Choi (Samsung), B. D. Choi (Tencent), R. Sjöberg
(Ericsson), R. Skupin (HHI)] [late]
6.19.3.6MCTS and sub-picture sequence (5)

JVET-M0416 also includes one aspect on MCTS signalling in the PPS.
JVET-M0261 AHG12: On grouping of tiles [M. M. Hannuksela, A. Aminlou (Nokia)]
JVET-M0388 AHG12/AHG17: On merging of MCTSs for viewport-dependent streaming

JVET-M0445 AHG12: On motion constrained tiles for VVC [R. Skupin, V. George,

K. Sühring, Y. Sanchez, T. Schierl (HHI)]
JVET-M0536 AHG12: On picture-level tiles and sequence-level tiles for VVC [E. Thomas,
A. Gabriel (TNO)] [late]
JVET-M0870 AHG12: Proposed JVET common test conditions and evaluation procedures
for MCTS and sub-pictures with boundary padding [M. Coban (Qualcomm),
R. Skupin (HHI)] [late]
Discussed Monday 1940 (GJS).
This document proposes common test conditions (CTC), conversion practices, and software reference
configurations to be used in evaluation of MCTS and sub-picture coding schemes.
This is for coding efficiency testing. The suggested method is to encode and decode MCTSs separately
and compute and substract the duplicate header overhead data quantity to measure results. Software
decoder runtimes might not be properly measured that way, since that is not likely to match how the
feature would be implemented. The tested use case is a cubemap projection 360° video source.
In Track A, it was suggested to make this a CE, since it was a plan for one specific test of a particular
technology (see CE12).
Page: 282 Date Saved: 2019-03-172019-03-14

6.19.3.7Miscellaneous tiling topics (3)
JVET-M0136 AHG12: Treating tile and tile group boundaries as picture boundaries
[J. Chen, Y.-K. Wang, Hendry, M. Sychev (Huawei)]
JVET-M0137 AHG12: On tile configuration signalling [M. Sychev, Hendry, Y.-K. Wang

(Huawei)]
JVET-M0375 AHG12: On uniform tile spacing [M. Damghanian, R. Sjöberg,

6.19.4 Wavefront parallel processing (2)
JVET-M0070 AHG12: Wavefront processing in a tile group [T. Ikai, S. Deshpande,

T. Chujoh, E. Sasaki, T. Aono (Sharp)]
JVET-M0071 WPP: Improved parallel processing capability with WPP [Y. Fujimoto,

M. Ikeda, T. Suzuki (Sony)]
JVET-M0593 Crosscheck of JVET-M0071 (AHG12: Improved parallel processing

capability with WPP) [Y. Yasugi, T. Ikai (Sharp)] [late]
7 Complexity analysis and reduction (10)

Contributions in this category were discussed XXday X Jan. XXXX–XXXX (chaired by XXX)initially
discussed in a BoG reported in JVET-M0902 and later reviewed in Track A.
JVET-M0902 BoG report on contributions related to complexity analysis and reduction

[B. Bross, A. Filippov]
This BoG report was reviewed in Track A on Wed 16 January 1515-1600 (GJS).
There are 10 technical contributions in the complexity related category. These contributions are classified
into the following 4 categories:
 Small block size restrictions
 Complexity analysis
 Block size restrictions for PDPC
 Complexity reduction of motion compensation and MV coding
BoG sessions were held 19:15–21:00 on 01/15 in Coliseum. Section 1 of this document summarizes the
BoG’s recommendations. Section 2 of this document contains detailed notes on BoG discussion.
The BoG recommended software adoption of JVET-M0864, which suggests an enhancement of the tool
to measure the memory bandwidth in VTM.
Page: 283 Date Saved: 2019-03-172019-03-14

Decision (SW): Adopt JVET-M0864 memory bandwidth analysis method.
The BoG recommended further discussion of the following:
Summary of contributions on small block size restrictions

Contribution Coding performance Disallowed Intra prediction loop Other
(Y, Cb, Cr) block sizes (throughput)
JVET-M0169 AI: 0.04%, 0.23%, 0.31% None 16 sample granularity Unchanged
(can help both RA: 0.07%, 0.43%, 0.54%
single and LD: 0.07%, 0.38%, 0.27%
separate tree)
JVET-M0245 AI: 0.05%, 0.29%, 0.40% Separate tree: 16 sample granularity Coef. Group:
(does not help RA: 0.02%, 0.39%, 0.42% Chroma in separate tree case, 4 2x8/8x2 for
single tree case) LD: -0.01%, 0.33%, 0.50% 2x2/2x4/4x2 otherwise. width/height 2
chroma blocks.
JVET-M0065 Option 1 Option 1: Option 1: Option 1:
(not helpful for AI: 0.00%, 0.04%, 0.03% Separate tree: 8 sample granularity in Single tree: 2x2
single tree case in RA: 0.01%, 0.17%, 0.17% chroma 2x2 separate tree case, 4 intra use DC
hardware) LD: 0.03%, 0.27%, -0.11% otherwise. only.
Option 2 Option 2:
AI: 0.03%, 0.26%, 0.38% Separate tree: Option 2: Option 2:
RA: 0.09%, 0.63%, 0.84% chroma 16 sample granularity Single tree:
LD: 0.00%, 0.24%, -0.43 2x2/2x4/4x2 in separate tree case, 4 2x2/2x4/4x2
otherwise. intra use DC
only.
VTM-3.0 without AI: 0.03%, 0.26%, 0.38% Chroma: 16 sample granularity
small intra CU RA: 0.33%, 0.55%, 0.78% 2x2,4x2,2x4
LD: 0.21%, 0.17%, 0.60% Luma:
4x4,4x8,8x4
It was commented that it may be undesirable to depend on requiring decoders to be able to use parallel
processing, since some (e.g., software) decoders may not be able to do that.
It was agreed to consider these approaches in CE3.
Summary of contributions on block size restrictions for PDPC

Contribution Test # Restriction Compression performance (Y/U/V)
width + height <= 8 AI: 0.05% / 0.02% / 0.03%
JVET-M0045
RA: 0.03% / 0.04% / 0.00%
1 1. width + height <= 8 AI: 0.03% / 0.04% / 0.02%
2. width + height > 64 RA: 0.03% / 0.03% / 0.07%
2 1. width + height <= 8 AI: 0.03% / 0.03% / 0.04%
2. width + height > 64 (applicable only RA: 0.02% / 0.06% / 0.05%
to blocks with worst-case intra-
prediction modes)
JVET-M0122
3 1. width + height <= 8 AI: 0.01% / -0.03% / 0.00%
2. width + height > 64 RA: 0.02% / 0.07% / 0.04%
Both restrictions are applied only to blocks
with worst-case intra-prediction modes
3a width + height <= 8 (applied only to blocks AI: 0.02% / -0.03% / -0.07%
with worst-case intra-prediction modes) RA: 0.01% / 0.01% / -0.04%
width + height > 64 AI: -0.01% / -0.02% / 0.02%
JVET-M0238
RA: 0.00% / 0.08% / 0.10%
JVET-M0814 1 width * height <= 16 AI: 0.05% / 0.01% / 0.03%
RA: 0.03% / -0.05% / -0.01%
2 1. width * height <= 16 AI: 0.06% / -0.08% / -0.08%
Page: 284 Date Saved: 2019-03-172019-03-14

2. max(width, height) <=32 for luma, RA: 0.05% / -0.08% / -0.05%
max(width, height) <=16 for chroma
3 width * height <= 8 for chroma AI: 0.00% / 0.03% / 0.02%
RA: 0.00% / 0.06% /0.02%
It seemed unclear whether PDPC is particularly an issue for small blocks.

A participant indicated that it may be too early in the process, so that we shouldn’t optimize such aspects
until the design is more stable.
No action was taken on these proposals, and no CE for them was planned.
M0248 was reviewed in the context of CE2 rather than in this BoG.
M0265 was not reviewed in the BoG. It was considered in Track A, and notes for that are recorded
separately.
JVET-M0245 AHG16-related: Chroma block coding and size restriction [C. Rosewarne,

A. Dorrell (Canon)] [late]
Initial upload rejected as placeholder
JVET-M0821 Crosscheck of JVET-M0245 (AHG16-related: Chroma block coding and size

restriction) [T. Y. Zhou, T. Ikai (Sharp)] [late]
JVET-M0065 Non-CE3: Intra chroma partitioning and prediction restriction [T. Zhou,

T. Ikai (Sharp)]
JVET-M0442 Crosscheck of JVET-M0065 (Non-CE3: Intra chroma partitioning and

prediction restriction) [K. Zhang (Bytedance)] [late]
JVET-M0169 CE3-related: Shared reference samples for multiple chroma intra CBs [Z.-Y.
Lin, T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S.-M. Lei (MediaTek)]
JVET-M0715 Crosscheck of JVET-M0169 (CE3-related: Shared reference samples for

multiple chroma intra CBs) [X. Ma (Huawei)] [late]
JVET-M0248 AHG16: Motion compensation with padded samples for small coding units
[H. Liu, J. Chon, H.-C. Chuang, L. Zhang, K. Zhang, J. Xu (Bytedance)]
JVET-M0265 AHG16: Clean-up on MV Rounding [K. Zhang, L. Zhang, H. Liu, J. Xu,

Y. Wang, P. Zhao, D. Hong (Bytedance)]
This was discussed in Track A Wednesday 16 January 1600-1630 (GJS).
Page: 285 Date Saved: 2019-03-172019-03-14

In VTM-3.0, MV averaging is performed by pair-wise merge candidate, triangular prediction and affine
prediction for chroma components with different ways of rounding. It is proposed to unify the MV
rounding operation to be the same as MV rounding in affine MV derivation. In addition, it is proposed not
to clip MVs for the luma component before calculating the MV for chroma components in affine
prediction, to align the VTM software and the working draft. Simulation results reportedly show 0.00%
BD-rate change under Random Access (RA) configurations.
Decision: Change the software to match the WD to remove clipping of luma MVs before deriving chroma
MVs.
It was reported that prior to VTM 3, there was only one rounding in MV averages.
Offset = 1 << (F-1);
M= S >= 0 ? (S + Offset) >> F: -((-S + Offset) >> F).
This is rounding away from zero. Some recent changes to VTM 3 were not consistent with that, and it
was proposed to always use this same rule.
Decision (BF/consistency): Adopt rounding away from zero for MV averages.
JVET-M0563 Cross-check of JVET-M0265 (AHG16: Clean-up on MV Rounding) [X. Chen

(HiSilicon)] [late]
JVET-M0864 [AHG5] Enhancement of cache model by adopting block-based format

[R. Hashimoto, S. Mochizuki (Renesas)] [late]
JVET-M0879 Crosscheck of JVET-M0864 ([AHG5] Enhancement of cache model by

adopting block-based format) [T. Zhou, Y. Yasugi, T. Ikai (Sharp)] [late]
JVET-M0045 Non-CE3: PDPC Restriction [S. Keating, K. Sharman (Sony)]
JVET-M0561 Crosscheck of JVET-M0045 (Non-CE3: PDPC Restriction) [J. Lee, H. Lee,

S.-C. Lim, J. Kang (ETRI)] [late]
JVET-M0122 Non-CE3: On block size restrictions for PDPC [A. Filippov, V. Rufitskiy,

J. Chen (Huawei)]
JVET-M0880 Cross-check of contribution JVET-M0122, test 3.a (Non-CE3: On block size

restrictions for PDPC) [F. Racapé (Technicolor)] [late]
JVET-M0806 Cross-check of contribution JVET-M0122 (Non-CE3: On block size

restrictions for PDPC) [M. Schäfer, J. Pfaff (HHI)] [late]
Page: 286 Date Saved: 2019-03-172019-03-14

JVET-M0238 Non-CE3: Modification of PDPC [J. Lee, H. Lee, S.-C. Lim, J. Kang,
H. Y. Kim (ETRI)]
JVET-M0678 Crosscheck of JVET-M0238 (Non-CE3: Modification of PDPC) [S. Keating

(Sony)] [late]
JVET-M0814 Non-CE3: block size restriction on PDPC [L. Li, J. Heo, J. Choi, S. Yoo,
J. Choi, J. Lim, S. Kim (LGE)] [late]
JVET-M0881 Crosscheck of JVET-M0814 (Non-CE3: block size restriction on PDPC)

[A. Filippov, V. Rufitskiy (Huawei)] [late]
8 Encoder optimization (3)

JVET-M0091 AHG10: Clean-up and finalization of perceptually optimized QP adaptation

method in VTM [C. Helmrich (HHI)]
Presented Thursdayy 17 January 2020 (chaired by F. Bossen).
This contribution proposes a clean-up and a completion of the perceptually optimized QP adaptation
(QPA) algorithm already integrated into the VTM codec software. Specifically, the following points are
addressed:
1. for HD and smaller input sequences, the previously employed reduction of the CTU size is
removed
2. for HD and smaller input, a depth-1 QPA (4 QPs per CTU) is used instead of the CTU size
reduction
3. the QPA parameter a pic is now defined as a function of the picture size instead of by a case-
statement
4. an extension of the QPA algorithm for better visual handling of CTUs with glaring colors is
provided
5. some remaining obsolete QPA related is code removed and some DC offset calculations are
unified.
The proposed changes, whose integration into the next VTM software version is suggested, result in
slightly reduced bitstream sizes for HD or smaller sequences and the Campfire UHD sequence and
reportedly provides between 1.7 and 2.5% additional luma BD-rate gain on the random-access coded
sequences of the SDR common test conditions (CTC). However, the proposal does not affect the CTC
since QPA is off by default.
Decision (SW): Adopt
JVET-M0511 Bug fix for rate control under all-intra [Y. Li, D. Liu, Z. Chen (USTC)] [late]
Presented Thu 8:30pm. Chaired by FJB
Page: 287 Date Saved: 2019-03-172019-03-14

In VVC Common Test conditions, a TemporalSubsampleRatio value is set to be 8 under all intra
configuration. This strategy is to simplify the testing procedure. For example, the sequence FoodMarket4
has totally 300 frames, when coding in all intra configuration, only 38 frames are extracted and coded.
And the actual frame rate is the original sequence frame rate set in the config file divided by 8. However,
as the the sequence original frame rate takes the value of 50 fps or 60 fps. Both two numbers are
indivisible by 8. So how to represent the actual frame rate is an option. In VTM, the actual frame rate is
implicitly regarded as a float number when printing out the statistic information of bit-rate. However, in
case of rate control is enabled, the actual frame rate is explicitly set as a int number, by a successive
rounding operation of the division. This inconsistency makes the target bits calculated by the bit-rate a bit
different from the actually coded bits, from which the bit-rate is calculated. In this document, we propose
to explicitly set the actual frame rate to be a float number in case of TemporalSubsampleRatio is enabled.
This was considered a simple bug fix.
JVET-M0600 AHG10: Quality dependency factor based rate control for VVC [Z. Liu,
Z. Chen, Y. Li (Wuhan Univ.), Y. Wu, S. Liu (Tencent)] [late]
Presented Thursday 17 January 2030 (chaired by F. Bossen).
This contribution presents some improvements based on the current rate control scheme proposed in
JVET-K0390. With the proposed quality dependency factor based bit allocation algorithm, when using
the anchor bit rate of VTM 3.0 as the target, there are 0.34%/3.45%/3.02% for Y/U/V coding efficiency
improvements in random access (RA) configuration when compared with the rate control algorithm in
JVET-K0390.
JVET-M0840 Crosscheck of JVET-M0600 (AHG10: Quality dependency factor based rate

control for VVC) [X. Wang (Kwai Inc.)] [late]
9 Metrics and evaluation criteria (0)

10 Plenary meetings, joint Meetings, BoG Reports, and Summary of

Actions Taken
10.1 Plenary meeting Sunday 13 January 0900-1045, 1115-1400
Reports of the tracks were presented as follows:
Track A:
 The initial review had been completed for CEs assigned to Track A
 CE3-1.1.1 Intra sub-partitions coding mode (conceptually similar to prior “short-distance intra
prediction”) with a different trade-off between gain and encoding run-time (at least 16 samples per
partition; 2 or 4 partitions); this includes a reversal of coding order
All Intra Main 10 - Over VTM-3.0 Random Access Main 10 - Over VTM-3.0
1.1.1 -0.59% -0.44% -0.47% 112% 103% -0.29% -0.31% -0.15% 102% 103%
Page: 288 Date Saved: 2019-03-172019-03-14

In the plenary review, it was said that the reverse coding order part of this (which had not been
discussed in the initial track review) was difficult to support in implementations, and it was asked
whether the gain would be preserved if the reverse coding order aspect was removed. The proponent
said they thought the coding order reversal was a key part of the scheme. It was requested for a test to
be performed of what the impact would be for not having that part of it. See the notes on further
discussion of this aspect in another plenary held on 17 January in section 10.3.
 CE3-2.4.c CCLM customization for chroma type (~6% for chroma for type 2 chroma content)
In the plenary review, it was reported that in a revision of JVET-M0142, test results had been
provided for what would happen if type 2 processing were applied to type 0 content. The results
indicated 0.17% degradation for luma, and ~2.1% for chroma. For class A1, the Campfire sequence
had 0.83% degradation for luma, 11.36% for U, and 4.56% for V. It was noted that the subjective
effect seemed likely to be greater. sps_cclm_collocated_chroma_flag = 0 would indicate type 0
processing.
 CE5-5.1.13* +new init from 5.1.2 arithmetic coding engine
Engine AI RA LB LP AI RA LB
5.1.13* +new init from -0.98% -0.96% -0.75% -0.73% 110/105 104/103 106/103
5.1.2
 CE6-1.1a/1.6a replacing 4-pt DST-7/DCT-8 by DST-4/DCT4
Rando
All m Low
Intra Access Delay B
AI RA LB
Test #
Doc. #
CE6-1.1a/1.6a -0.17% -0.14% -0.11% 101% 99% -0.06% 0.05% 0.04% 101% 99% 0.02% 0.30% 0.13% 100% 98%
This has very small benefit, but no real impact on complexity. From a spec perspective, it is just a
matter of the values of numbers in tables. It increases the number of types of transforms being used in
the design and it was commented that having something different just for 4x4 seems conceptually
inconsistent. It was noted that DST4 is part of DCT2. It was also noted that the impact on LB is
negative. Some participants commented that the gain is too small to justify a change of the spec. The
proponent commented that some gain was shown for LDB with inter-MTS on (0.07% with low-delay
B). No gain was shown for low QP. It was agreed in the plenary not to adopt this change.
 CE6-2.3a DST-7/DCT-8 with dual implementation support (no coding efficiency impact)
In the AI configuration, this provides a reported 9% speed-up for the decoder, 4% for the encoder (as
tested).
 CE6-3.1b Block shape adaptive transform selection, but with an extra high-level flag to use DCT2
always (benefit relative to an anchor that is not using MTS: AI 1.61%, RA 0.71%, LB 0.14%)
It was asked how much benefit this has relative to an encoder that, for rectangular blocks, chooses a
fixed combination using the MTS syntax. The particular transform combination that this proposal
uses for rectangular blocks has a DCT2 in one direct and a non-DCT2 transform in the other
direction, which is not a combination supported in the MTS syntax, so that combination could not be
selected in the suggested alternative low-complexity approach. It was commented that this may call
into question the way MTS has been designed. Further study of these issues was encouraged.
Page: 289 Date Saved: 2019-03-172019-03-14

 CE6-4.1a Sub-block transform with residual in only one sub-block (1-d split symmetric or 1/4; if
symmetric, flag to indicate which half, otherwise use the smaller sub-block; transform type of
residual TU inferred)
Rando
All m Low
Intra Access Delay B
AI RA LB
CE6-4.1a JVET-M0140 -0.47% -0.16% 0.00% 108% 101% -0.83% -0.98% -0.06% 113% 102%
 CE7.4: In transform coefficient coding, the greater than 2 flag is moved to the first coding pass after
the parity bit and the number of scans is reduced from 3 to 2 (very small coding efficiency
improvement)
 In-loop “reshaping” seemed likely to be adopted.
Track B:
[Clean up the relationship between this section and the related notes elsewhere, avoiding duplication and
adding cross-references]
As a general remark, it was established in Track B that “further study” means that technology should be
studied in next CE on the subject area, whereas if such a remark is missing it implicitly means it shall not
be studied in CE. If further study in an AHG is expected, that would be explicitly expressed.
Furthermore, the issue was raised that many of (or most of) the CE proposals had come without
specification text. It was agreed that in future CEs, the text should be available by the time of the
document deadline. Furthermore, CE contribution documents should be complete and not make it
necessary to open old documents to understand the technology.
CE2: Subblock motion compensation

 CE 2.1: Affine motion compensation
Decision: Adopt JVET-M0246 (Test 2.1.2), extending AMVR to affine (but switching 1/16,1/4,full-pel).
Use the AMVR high level flag for disabling both “normal” AMVR and “affine” AMVR. This provides
0.23% bit rate reduction.
In JVET plenary, it was agreed to use a separate flag, and disable this feature in CTC for LB, as the
encoder runtime increase is not acceptable there.
 CE 2.2: Affine merge mode
Decision: Adopt JVET-M0381 Test 2.2.2a (reducing number of context coded bins in affine merge).
Track B initially suggested adoption of JVET-M0431, Affine merge with offset and block level
signalling, and POC distamce based offset mirroring for bi pred. (test 2.2.4c on top of 2.2.4a) (using
distance offsets 1/2, 1, 2, 4, and 8-pel as per table 2.1 of JVET-M0431). Add a high-level enabling flag.
In a follow-up discussion in the JVET plenary Sunday, it was agreed that the gain of 0.2% is too small to
justify the additional syntax and increase in encoder runtime. No Adoption.
No action from following sub-CEs
Page: 290 Date Saved: 2019-03-172019-03-14

 CE 2.3: Sub-block based merge mode
 CE 2.4: Complexity reduction
 CE 2.5: ATMVP and related topics
CE4: Inter prediction and motion vector coding

CE4.1: Merge mode simplification
Decision: Adopt JVET-M0281 (subtest 4.1.5a), Motion vector pruning: rounding before any MV pruning
(unification for all DMVR cases)
CE4.2: Merge mode enhancement: No action
CE4.3: Parallel processing for merge mode: No action
CE4.4: Motion vector coding
Track B initially suggested adoption of JVET-M0403 modified MV coding (test 4.4.1a, 2 layer groups,
where the first group is just the 0,0 MVD). This does not have compression benefit, but reduces the
number of context coded bins from 4 to one, using joint coding of x/y. However, in the context of later
discussion related to CE8, it was detected that this might have coding efficiency problems with CPR
whichhad not been checked. Furthermore, it would be more difficult to check in the layer/index
representation if the CPR range constraints are valid. It was also discussed in the JVET plenary that the
benefit would be rather small.
Further, some revisits (depending on availability of additional data) for modifications of MMVD
CE4.5: Motion compensation constraints for complexity reduction: No action
CE8: Screen content coding tools
8.1 CPR related

It was suggested to enable CPR for class F in the CTC. This would be realistic for the case where the
encoder could know that it is screen content or natural content.
The methods of CE8.1.2 provide additional gain of >3% for class F, 8% for TGM class. These are re-
using existing data from the previous CTU (assuming 2 or 4 buffers of size 64x64 each, depending on
version). This is generally agreed to be practical and give good benefit. It could however be complicated
to specify as an encoder/bitstream restriction that the limits of CPR vectors are valid. This still needs to be
decided if it is mature for adoption.
Some methods provide additional gain (e.g. 0.4% class F, 0.9% for class TGM), but modify AMVP and
merge list construction. Question is raised whether VVC would require to use exactly the same principle
for CPR and normal MV coding. Probably this might be OK if it does not deviate too much, and does not
require much additional processing. In HEVC SCC, it was required to have exactly the same process for
CPR and MV coding, which may not be the case for VVC.
As a more fundamental aspect, it was discussed in the JVET plenary what general limitations we would
impose on CPR design such as vector coding, and the status of CPR at large. In this context, it was agreed
that it is desirable to define CPR as a separate mode that is also named differently, e.g. IBC. In terms of
keeping the specification simple, it is nevertheless desirable to avoid arbitrary differences from building
blocks of motion compensation, e.g. MV coding. IBC building blocks may deviate from those of motion
comp if beneficial in terms of substantial improved compression or simplification. It is also notified that
in the area of SCC material, “substantial” may mean several percents.
Page: 291 Date Saved: 2019-03-172019-03-14

8.2: Palette related
Current VVC does not include palette mode, however a kind of “baseline” exists which is HEVC palette
plus dual tree. This provides roughly 3%/7.5% gain over VVC+CPR for classes F/TGM. Results from CE
also indicate that this gain goes to 2.5%/4.5% when combined with the improved CPR from 8.1.2. This
may be even less when other aspects such as transform skip come into play. Such a relative low gain
might not justify adding palette as an additional building block, and need for substantial amount of text in
the spec.
As a more fundamental aspect, it was discussed what should be the design targets for palette. Improved
compression performance may be more important than lowering complexity, to justify addition of such a
mode.
In the JVET plenary, it was also suggested that it would be useful to include testing on 4:4:4 for screen
content, renew the data set for screen content (no action was taken on this), and generally to provide
mechanisms in the VVC text and VTM to support 4:4:4 content.
8.3: Block-based DPCM

These approaches perform sample-wise DPCM as an additional concept that demonstrates some benefit
for screen content types. The most viable approach (according to proponents) is 8.3.2 which can best be
optimized in terms of throughput and also shows best compression. The gain over VTM+CPR is
3.7%/4.9% for classes F/TGM, and gain over VTM+CPR+PLT is 1.3%/1.4%, respectively. The encoder
runtimes are significantly faster when those methods are used, as some early termination approach is
employed (not searching other intra modes when the prediction works well).
The current method uses a maximum of 12 context coded bins per sample, which is much too large. No
candidate for adoption, but further study in CE, with simplifications proposed in non-CE.
From CE8 related:

As mentioned above, the general consensus is that it is a right direction to signal CPR as a separate mode
rather than using a special reference picture index.
JVET-M0483 comes with spec text (“method 3”), which however needs more careful inspection and
modifications (also alignment with v9 of VVC draft 3).
JVET-M0464 Unified Transform Type Signalling and Residual Coding for Transform Skip
Signals TS before MTS (and therefore also enables it for blocks up to 32x32), but also changes the MTS
binarization
 CTC: 0.01%, 103%, 101% (AI), -0.02%, 98%, 100% (RA), -0.07%, 102%, 102% (LB)
 Class F: -1.96%, 103%, 97% (AI), -2.14%, 98%, 100% (RA), -2.79%, 103%, 99% (LB)
 TGM: -8.04%, 106%, 88% (AI), -8.74%, 106%, 96% (RA), -9.21%, 112%, 97% (LB)
Additionally changing the residual coding for transform skip (first modification and second modification)
results on average in (BD-rate Y, enc. time, dec.time):
 CTC: -0.16%, 103%, 100% (AI), -0.07%, 98%, 101% (RA), -0.07%, 101%, 101% (LB)
 Class F: -7.16%, 104%, 94% (AI), -5.76%, 98%, 100% (RA), -5.85%, 102%, 99% (LB)
 TGM: -21.03%, 108%, 82% (AI), -15.57%, 105%, 94% (RA), -14.01%, 111%, 95% (LB)
Page: 292 Date Saved: 2019-03-172019-03-14

It is dicussed whether the aspect of signalling TS before MTS (and by that way enabling TS for block
sizes up to 32x32, but also restricting it to luma) would rather be a straightforward syntax cleanup, which
could be adopted at this meeting (but without modifying the MTS index binarization, which is discussed
in CE6). However, results of TS modification are on top of VTC, would be desirable to see benefit for SC
classes when CPR is on. This requires further consideration.
There are also other contributions JVET-M0072, JVET-M0269, JVET-M0279 and JVET-M0501 which
also target TS.
CE9: Decoder-side motion vector derivation

CE9.1: BDOF design
Decision: Adopt JVET-M0487 (solution 9.1.1.b) which uses integer positions to generate the prediction
samples in extended region, and uses 8-tap DCTIF filters to generate the prediction samples inside the
CU.
No loss, but simplifies BDOF
CE9.2: DMVR design

Not decided yet, but good candidate for adoption: JVET-M0147 shows results without using refined MV
for spatial MV prediction and deblocking: Overall -1.01%. This seems a reasonable approach avoiding all
major dependency problems that were observed in DMVR before. This is however a variant for which
cross-check still needs to be provided; specification text to be made available.
Generally, the investigation on DMVR has led to a point where it might be manageable implementation-
wise (not low complex, but still giving around 1% gain)
A problem to be investigated: As currently tested, DMVR and BDOF could be applied sequentially,
before finally motion comp and reconstruction can be done. JVET-M0223 considers this issue, still needs
to be reviewed.
CE10: Combined and multi-hypothesis prediction

CE10.1:
10.1/10.2: Multi-hypothesis prediction: No action – gains are too low (and became lower than before, cut
by half or even more) to justify additional complexity
In the context of reviewing 10.1.3.x proposals, which target simplifications of CIIP, the following aspects
were identified:
- does it need a specific MPM derivation? If there was only one mode (as in 10.1.3a/d) it is not needed at
all, and it is mentioned that there are proposals just suggesting fixed length coding
- CIIP does not have any serious latency issue. Therefore, simplifications that remove some processing
steps that are otherwise used in intra prediction is not necessary.
- Sample-wise unequal weighting is not an implementation issue, whereas equal weighting would be
preferrable, unless it costs compression performance or causes qualty problems.
Beyond the solutions tested in 10.1.3 more study is necessary on these aspects.
CE10.2: OBMC
Among the four proposals, version 10.2.1 seems the only one which is manageable from complexity
perspective (but definitely adds some complexity). The test results are summarized as follows:
Page: 293 Date Saved: 2019-03-172019-03-14


CE10.2.1 JVET-M0178 RA -0.27% -0.58% -0.62% 104% 103%
LB -0.36% -0.50% -0.51% 106% 105%
Track B initially suggested adoption of JVET-M0178.

During the JVET plenary, it was questioned whether such small gain was justifying the additional
complexity. It is commented by several experts that OBMC may have positive impact on subjective
quality. However, no such proof was available (and would probably be difficult to get). The decision was
reverted.
CE on the previous investgated technologies 10.2.1…10.2.4 should be closed.
CE10.3: Multiple shape prediction partitions: No action
CE10.4: Diffusion filters for intra and inter prediction

The new proposed version uses FIR filters, applied on the prediction signal, switchable, not iterative. Two
different 1D filters are 9-tap, symmetric, only 1 multiplication, otherwise shifts. One 2D filter is a 5-tap
diamond shape, only shift/add operations. At the boundaries, one sample from neighboured reconstruction
is used. The approach provides gains of 0.17%/0.42%/0.17%/0.87% for AI/RA/LB/LP. The method has
been brought down to acceptable complexity impact for decoder, at some penalty in performance.
Two concerns are raised:
- As it needs to be run after the prediction signal is generated, it produces additional delay in the intra
prediction loop.
- For inter blocks, it can be used for 128x128 CU, which would break concepts of 64x64VPDU.
It was requested to provide additional results without using the method in intra prediction (and the intra
part of CIIP), and restrict the largest CU size to 64x64.
It is also reported that a late contribution (JVET-M0848) provides new results for the same method of
10.4.2 with some (small) encoder speedup and slightly increased performance.
Furthermore, it would be desirable to use only the prediction samples (no reconstructed samples from
current picture). A version which did that was shown in the previous CE.
No decision was made yet on this at the time of this plenary meeting.
CE10.5: Local illumination compensation

No action on current technologies, but continuation of CE to fulfill dependency/pipeline latency
requirements.
CE11: Deblocking
Sub-tests
1) long-tap deblocking filters (11.1)
2) deblocking at 4x4 block boundaries (11.2).
Page: 294 Date Saved: 2019-03-172019-03-14

The proposals were encoded according to two test conditions, which correspond to two anchors.
Anchor-1 is VTM-3.0 according to the CTC.
Anchor-2 is VTM-3.0 with ALF switched off (other conditions are the same as in Anchor 2).
CE11.1
Technology-wise understood and complexity-wise analysed, with some additional information on
complexity requested.
It was pointed out that some of the proposals 11.1.1-5 did not consider that VTM3 now uses subblock
boundary deblocking, whereas the decision of using long filters is based only on CU boundary properties.
Therefore, it could happen that a long filter is applied first, and afterwards a subblock boundary within the
CU is deblocked again. This would inhibit parallelism. This could be classified as a bug, which however
in terms of subjective testing might not be too harmful.
CE11.2
VTM3 operates deblocking on an 8x8 grid. If a CU boundary is not on an 8x8 grid, it is not deblocked. If
a CU is on an 8x8 grid, furthermore subblocks within that CU are deblocked (provided they are on the
8x8 grid as well). 4xN blocks are deblocked whenever they are coinciding with the 8x8 grid
11.2.1 deblocks on a 4x4 grid, where a boundary is deblocked with VTM filter when the next block or
subblock is more than four samples apart, and with a weak and short filter if it is only samples apart.
11.2.2 uses an 8x8 grid and VTM deblocking filter but disables deblocking whenever the boundary would
be only four samples apart.
Viewing in CE11 to assess necessity and benefit still to be done (being prepared).
General remarks on late delivery of text – text needs to be provided.
10.2 Joint meeting Thursday 17 January 0900-0945

JVET with MPEG Systems and Requirements.
M46578 On the decoding interface for immersive media [Emmanuel Thomas (TNO) Rob
Koenen (Tiledmedia) Thomas Stockhammer (Qualcomm)]
This has been called “Immersive media access and delivery” in some MPEG work, and there was an
MPEG output document N 18071 at the October 2018 MPEG meeting.
This is for a scenario with additional processing that takes place after decoding; not a 1:1 mapping
between output of decoder and display of the decoded video by the decoding system.
Example: 360° video tiled streaming using cubemap with each face of the cubemap segmented further
into tiles. Using view-port-dependent streaming to only serve the tiles needed for viewing. Problems
mentioned:
 Some systems having limits on the number of decoder instantiations.
 Need for systems coordination of timing.
An example approach is rewriting the bitstream to produce a “packed picture” that is decoded.
Page: 295 Date Saved: 2019-03-172019-03-14

The proposed alternative is a decoder interface with a relatively large number of decoders – not
necessarily a tile-level decoding interface from the video spec perspective – each decoder could be
processing whole pictures from its perspective.
Another example: decoding of a background scene and a foreground object that are later composited by
the system into a combined scene.
It is proposed to be able to mix profiles, colour formats, frame rates, picture resolutions, etc., using this
tile-level interface.
Issues:
 Timing coordination (and ensuring decoding speed)
 Reference picture (or picture regions) management
 Other associated data used by a decoder
 Buffer flow characteristics
The subject was reported to be under consideration in MPEG Systems and Requirements, including as
MPEG-I Architecture.
Simulcast “layers” as a way to do that. The proposal is a multi-stream model in which there are multiple
independent (but synchronized) bitstreams.
It was commented that from an implementation perspective it is more complicated than a matter of
memory capacities and resolution-dependent frame rates.
It was commented that this could involve a conformance point that constrains a combined set of decoders
or decoder resources or bitstreams.
10.3 Plenary meeting Thursday 17 January 0945-1200
Track A:
 Reference picture management in high-level syntax per JVET-M0128 (modified as noted)
 Small bug fixes from JVET-M0265
o Fix the software to match the WD to remove clipping of luma MVs before deriving chroma
MVs.
o Adopt rounding away from zero for MV averages to remove inconsistency for similar
averages: Offset = 1 << (F-1); M= S >= 0 ? (S + Offset) >> F: -((-S + Offset) >> F).
Flexible rectangular tile groups per JVET-M0853-v2 (constrained as noted), with software in JVET-
M0445 and with loop_filter_across_tile_groups_enabled_flag from JVET-M0160 (confirmed in plenary)
 High-level syntax actions noted in discussion of JVET-M0816 BoG report.
 Simplification of division operation used in CCLM modelling from JVET-M0064.
 Simplifying PDPC linear interpolation to use nearest neighbour on secondary boundary for adjacent
angular modes
 Bug fix in spec text related to CBF signalling identified in JVET-M0361.
 Reduce complexity of 32-length DST-7/DCT-8 using zero-out approach of JVET-M0297 Test 2.
 Enable transform skip up to 32x32 block size, with associated syntax approach in JVET-M0464 using
tu_mts_idx (substantial gain for Class F / SCC).
Page: 296 Date Saved: 2019-03-172019-03-14

 Bug fix for quantization group QP signalling to make the size consistent per JVET-M0113 & JVET-
M0188 (text in JVET-M0113)
 Bug fix for transform skip quantization scaling factor for rectangular block shapes from JVET-
M0119
 Bug fix for QP with parallel encoding – 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 (text in a revision JVET-M0685).
 Non-normative (CTC): Enable transform skip for block sizes up to 32x32 in CTC (no effect on
encoder runtime with JVET-M0464 encoder search modifications)
 Non-normative: Adopt JVET-M0864 memory bandwidth analysis method.
The reverse coding order part of CE3-1.1.1 intra sub-partitions coding mode and text was discussed in the
plenary. It was reported that there was only a 0.04% penalty for not doing the reverse coding order, so it
was agreed to adopt the proposed scheme without that aspect; text was made available in a revision of
JVET-M0102. Further study was suggested for limiting the sub-partition width to be greater than or equal
to 4.
Track A action item: Avoiding 32-point DST (with 64-length DCT2 on the other side) in CE6-4.1a
[0.01% penalty reported in plenary Thu and avoiding all DST combined with 64-length DCT2 has 0.02%
penalty, so no DST (including size 32, 16, 8 and 4) combined with 64-length DCT2]
Track A action item: CE12-2 in-loop remapping function (adoption action likely) – experiment results
were discussed in a plenary Thu 17th; there was no significant penalty for the additional restrictions.
The encoder algorithm was discussed. It was described in JVET-M0427.
At a previous meeting, a curve-crossing problem had been observed and it had been suggested to do
something about low-QP operation. There was said to be a very large amount of code in the encoder
optimization, with resolution dependency and a smoothness measure and various thresholds and checks.
Some of that code was reportedly related to a different variant (CE12-1) and can be removed. Some of it
was for HDR, which was not measured in this test (but is also in-scope for VVC). It was discussed
whether the code would be difficult to maintain and might have excessive tuning within the code. It was
commented that the complexity had been reduced from previous versions. This has been tested in
multiple rounds of CE and appears to provide significant gain if an adequate encoding method is use.
Decision: Adopt (modified as noted).

Further study is requested to study the encoder software and check the behaviour outside of the tested
conditions.
Two other Track A action items were left open.
Track A also had recommended to discuss enabling CPR in CTC, at least for Class F.
Track B:
Reviewed all CE related BoGs (CEs 2, 4, 9, 10), CE8 & CE11 related had been reviewed in track
CE11 viewing ready, not reviewed, no conclusion yet
BoG on NN technology not reviewed yet
Various revisits still open pending on availability of more information. Most relevant are on CPR/IBC,
deblocking, diffusion filters
Page: 297 Date Saved: 2019-03-172019-03-14

New decisions:
- Adopt DMVR JVET-M0147 with SAD cost function&more details somewhere else (approx. 0.9%, 15%
decoder runtime);
- Adopt combined merge list for adjacent 4x4 subblocks, JVET-M0170
- Adopt variant of CE4.4.3, symmetric MVD, and disable BDOF when used – gives 0.33% in RA,
increases encoder time by 5%, JVET-M0444
- MMVD with switch (tile group header) to integer distance, benefical for screen content and UHD,
JVET-M0255
- 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%
- Encoder RD optimization with deblocking knowledge shows 0.58%, 0.71% and 0.66% luma gain with
similar encoding and decoding time, in AI, RA and LDB configuration respectively over VTM-3.0 anchor
(SW adoption, not CTC unless HM would do the same). Could be used in some CEs as additional option,
or mandatory.
- Hash-based motion search (JVET-M0253) – provides 7.8%/14.9% for classes F/TGM in RA, version
that does not affect encoder run time for natural video, switches back to conventional ME – CTC or CTC
only for SC. It was suggested in the plenary to go with the solution of enabling CPR via the SPS flag
specifically for class F in CTC, and also manually enabling hash-based search for class F in CTC, but
have the automatic switching as non-CTC in SW.
- Various adoptions of cleanups, harmonizations, simplifications with minor impact (look under BoG
report)

o No impact on CTC.
gradient in case of other bit depths than 10.
Question if the change would still be supporting the 16 bit SIMD design of software? Proponent confirms
that this is the case, may need further checking by SW coordinators.
For plenary: What is general support of different bit depths in VVC? Might other tools that were added in
recent meetings have similar problems. Definitely, bit depths up to 12 bits should be supported
consistently, whereas it is likely that for higher bit depths some more precision might be required.
(also flexibility of spec in terms of other extensions, e.g. 4:4:4 would be desirable)
Action item for editors to identify potential actions.
Already detailed review and suggestions of technology to be investigated in ongoing CEs

Intent to start a new CE on NN technology, primary intent to get better understanding of adaptation
mechanisms and complexity/compression performance impact, studying various methods that have been
proposed with unified conditions and constraints.
Page: 298 Date Saved: 2019-03-172019-03-14

Some aspects for ALF (particularly for saving line buffers) to be investigated in CE, also requires
subjective inspection
Re-start CE investigations on post reconstruction filters (bilateral, Hadamard) but only using for inter.
These give around 0.4% bit rate reduction for RA, which is still approximately the same as it was over
VTM 2, so the gain seems to be additive with in VTM3. Both methods have quite some impact on
complexity, where the new version of the bilateral filter is somewhat reduced relative to the previous
version. Could however be conflicting with LIC in terms of latency, the latter is also under further
investigation with additional constraints, these should be studied in combination.
10.4 Closing plenary sessions
10.5 Joint meetings
10.6 BoGs (12)
JVET-M0782 BoG report on tiles and WPP [Y.-K. Wang, M. M. Hannuksela]

This report was discussed in Track A Monday 14 January 1430-1630, 1830-2000 (chaired by GJS)
This contribution provides the report of the BoG on tiles and WPP.
The BoG recommended the following adoptions:
 Adopt JVET-M00853-v2 and add a NOTE like the following:
NOTE: When extracting an MCTS to form a conforming bitstream, active PPSs in the extracted sub-
bitstream should have signalled_tile_group_id_flag equal to 1.
JVET-M00853-v2 adds the support of rectangular tile groups in addition to the existing raster scan
ordered tile groups, and enables extraction of MCTSs without changing VLC NAL units.
Decision: Adopted, with constraints as follows:
 the tiles in a tile group need to be in raster-scan order.
 the tile groups need to be in increasing address order (see below: dark orange, then light blue, then
pale yellow, then dark blue, then light orange, …)
 The tile group shapes shall be such that each tile, when decoded, shall have its entire left boundary
and entire top boundary consisting of a picture boundary or previously decoded tile(s). In other
words, the light yellow and light green tiles in the figure below are not allowed.
The following tile group picture was drawn for illustration and discussion purposes regarding the above
constraints (an accidental homage to Piet Mondrian).
Page: 299 Date Saved: 2019-03-172019-03-14

The BoG recommended to adopt the software implementation in JVET-M0445 into the VTM.
Decision (SW): Adopted.
The software implementation in JVET-M0445 implements encoder motion constraints for MCTSs.
 Add loop_filter_across_tile_group_enabled_flag to the PPS, with syntax as proposed in M0160, and
semantics as follows:
loop_filter_across_tile_groups_enabled_flag equal to 1 specifies that in-loop filtering operations
may be performed across tile group boundaries in pictures referring to the PPS.
loop_filter_across_tile_group_enabled_flag equal to 0 specifies that in-loop filtering operations are
not performed across tile group boundaries in pictures referring to the PPS. The in-loop filtering
operations include the deblocking filter, sample adaptive offset filter, and adaptive loop filter
operations. When not present, the value of loop_filter_across_tile_groups_enabled_flag is inferred to
be equal to 0.
Decision: Adopted (confirmed Thursday morning plenary).
 Add an AHG mandate on WPP into AHG 12. This was agreed in Track A.
The BoG and Track A agreed that it was desirable to have WPP support in VVC. The syntax, semantics,
and decoding process for WPP are for further study.
The BoG recommended the following to be discussed:
 Whether to allow tiling with a tile width or tile height that is not a multiple of the CTU size
The late document M0875 was discussed – see notes on that contribution.
JVET-M0527 raised some concerns related to hardware implementation. And it was commented that in
addition to the issues mentioned in JVET-M0527, this design also causes issues with line buffer ing, as
well as in VDPU rate.
It was commented that a benefit of the design is enable turning off loop filtering across CMP faces. It was
suggested that enabling loop filtering turning off within a tile would be a lighter solution than having this
design. It was commented that there is ongoing CE on this.
Discussion resumed 1920 Monday 14 January (GJS).
It was thus suggested that these two topics should be discussed and decided together.
Page: 300 Date Saved: 2019-03-172019-03-14

 The latest HEVC text specifies, as part of the semantics of an SEI message, the MCTS sub-bitstream
extraction process and requires the extracted sub-bitstream to be conforming bitstream. For VVC,
should we do more than this way of defining conformance for MCTSs? For example, should
normative decoding process be specified for decoding of MCTSs instead of just specifying SEI
messages for indication of the encoder motion constraints? There were several related proposals. For
example, whether MCTS sequences are signalled in parameter sets or whether an MCTS sequence
would have its own associated parameter sets. Whether to provide a level definition at the MCTS
sequence level. Whether to define a normative decoder interface and conforming decoding behaviour
for MCTS-specific decoding. Further study is highly encouraged.
 On whether to (allow) treat boundaries of MCTS / sub-picture sequences as picture boundaries (i.e.,
to do padding).
Allowing this is expected to help in coding efficiency. However, it would impose some burden for
hardware implementations. Tests showing coding efficiency gain numbers and an analysis on hardware
implementation complexity are needed for making a decision on this. Note that JVET-M0445 provides a
software implementation that could be used as the basis and anchor for such coding efficiency
comparison.
Interested parties were requested to work offline to prepare the test conditions. This effort was
coordinated by M. Coban, the proposed test conditions were included in JVET-M0870.
It was thus suggested that JVET-M0870 be reviewed.
 Whether an interface for inputting/outputting reference pictures to/from the decoder could be
acceptable in decoder implementation architectures.
This relates to allowing empty tiles and applying geometry padding to fill in the empty tiles in an external
process as proposed in JVET-M0547. The contribution was also discussed in the 360 o video BoG (see that
BoG report).
It was commented that there could be other ways to indicate uncoded areas in the picture than using
empty tiles.
The contribution would need an interface of outputting reference pictures (with uncoded areas) from the
decoder to an external process and inputting reference pictures (with uncoded areas filled in by geometry
padding) to the decoder from an external process. It was commented that this has some similarity to the
external base layer concept of SHVC.
The bitstream would have some tiles that are not coded. The PPS could indicate where the uncoded areas
are.
It was suggested that the tested benefit for cubeface geometry padding was about 2%. The subjective
benefit may be greater. The anticipated benefit is rather limited, perhaps too small to be of interest by
itself unless there is some other motivation for establishing a similar functionality. There have been other
proposals for considering external management of reference picture memory and external control of the
decoding process below the picture level. If there is a study of that broader potential need for a different
system interface to the video decoding process, this could be part of it.
This was further discussed Wednesday 16 January 1445-1515 (GJS)
It was noted that the BoG had recommended considering M0375 after flexible tiling had been resolved.
This proposal would enable extraction of any row(s) or column(s) of tiles while still allowing the default
layout to be indicated rather than requiring use of the explicit layout syntax.
It was commented that this may not fit the way some systems specs have a special mode for when the
tiles are all the same size except at the picture edge. However, the proponent indicated that this scheme is
better than that one for load balancing, and noted that HEVC was also using a default scheme that uses
differing widths across the picture.
Page: 301 Date Saved: 2019-03-172019-03-14

Another participant commented that this shifts larger tiles to the top-left and groups those together, which
may not be optimal for load balancing when each thread is processing multiple tiles.
Further study was encouraged to determine whether the load balancing concern is valid and to consider
the alternative of using equal tile sizes except at the right and bottom edges.See section 6.19.3.1.
JVET-M0816 BoG report on high level syntax [J. Boyce]

This BoG report was reviewed in Track A Sunday 13 January 1530 and further discussed Wednesday 16
January 1400 (GJS).
 Ask the following questions to ALF experts, for consideration when evaluating proposed solutions to
improve coding efficiency of tile group headers:
6) How much bit rate do ALF parameters typically require? Perhaps typically about 200 bits (4 luma
and 1 chroma), could be up to perhaps 2k bits
7) Do we expect that multiple pictures would use the same ALF parameters? 0.5% for RA in
M0429. It was said to be undesirable to put them in the PPS since they change frequently.
8) What is the expected coding gain when ALF is used?
9) Does the ALF design support having different ALF parameters in different tile groups in the same
picture? This hasn’t been tested but seems necessary to support having tiles that were generated
by different encoders, and potentially desirable for other reasons as well.
10) If it is allowed to have different ALF parameters in different tile groups in the same picture, do
we expect that they would frequently differ? See previous item. It hasn’t been tried.
The BoG met on 11 Jan 2019. The BoG also met on 12 Jan 2019, with the notes reflected in the -v2
version of the report document.
Decision: The following BoG recommendations were adopted in Track A:
 Replace the existing IRAP_NUT with 3 new NAL unit types: IDR_W_RADL, IDR_N_LP,
CRA_NUT (from JVET-M0101).
 Add external means flag HandleCraAsCvsStartFlag, with similar text as in HEVC. Text provided in a
v3 of JVET-M0101.
 Add a NUT value for step-wise temporal access STSA (from JVET-M0101).
 Add a NUT value for AUD (from JVET-M0101).
 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 text of sections 7.4.2.4 to 7.4.2.4.5 on NAL unit order and AU boundary detection from JVET-
M0101, which is primarily editorial, but has some technical aspects.
 Add profile_tier_level( ) syntax structure which includes sub-layer level idc (similar to HEVC but
without sub-layer-specific profiles).
 Add general_non_packed_constraint_flag with semantics as in JVET-M0101 (rename the flag to
display_suitability_flag? – that’s editorial).
 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 as in option 1, subject to review by the 360° BoG (minor cleanup).
 Add 7 new constraint flags corresponding to VVC WD 3 tools as described in M0451.
Page: 302 Date Saved: 2019-03-172019-03-14

 Add reference picture signalling from M0128 (basic text version) – modified after Track A discussion
as described in the notes for that document.
 Consider between adding 2 NUT values for RASL and RADL leading pictures or staying with no
dedicated NUT values for leading pictures. Decision: Add RASL and RADL NUTs.
Further review of the BoG results was conducted Monday 14 January 1330 (GJS)
 Consider whether profile_space should be included. This, and profile compatibility flags, were agreed
to be for further study.
 Consider removing concept of I, P, and B slice (tile group) types, but to have flags to control the
types of prediction (intra prediction, current picture referencing, inter prediction with one list or two
lists), and whether this signalling should be for pictures or for tile groups. It was commented that it
may not be necessary to indicate at the tile group level whether CPR is used in the tile or not. (Note
that a tile has no header.) No need for action on this was identified.
 Consider whether an AHG should be formed to study solutions to problem of temporal judder when
temporal scalability sub-bitstream extraction is used to lower frame rate. Consider whether this
should have a normative impact or be supported in an SEI message (which could perhaps be done in
JCT-VC for HEVC or AVC). Such a study could include consideration of pre- and post-processing.
See JVET-M0579. It was suggested to establish an AHG on layered-coding scalability and resolution
adaptation, and to include this topic in its mandates.
 Consider whether there is interest to normatively specify Gradual Decoder Refresh (GDR) operation,
such that a conforming CVS can start with a GDR non-IRAP picture (as proposed in JVET-M0529).
Further study in an AHG was encouraged. Some issues for study include how HRD interacts with the
use case and whether it would be a burden to decoders to be required to support this capability.
The BoG also met 15 Jan from 1800 to 1930, with the notes reflected in the -v3 version of this document.
This was discussed in Track A Wednesday 16 January 1400-1445.
At the 16 January meeting, the BoG also recommended, and Track A agreed, to the following further
recommendation:
 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 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.
Further study was encouraged for making use of shared values across pictures and different APSs in the
same picture. Further study was also encouraged on whether to relax the constraint on re-using ID values.
See section 6.19.1.1.
JVET-M0843 BoG report on CE4 related inter prediction and motion vector coding
contributions [K. Zhang]
See section 6.4.This report was reviewed in Track B Tue 15 Jan 1215-1330 and 1435-1800.
Five sessions were held, 1540 ~ 2020 on Jan. 11, 0900 ~ 1045 on Jan. 12, 1830 ~ 2000 on Jan. 12,
1945~2300 on Jan. 13, 2130~2230 on Jan. 14 for discussing 47 technical contributions in five categories:
Page: 303 Date Saved: 2019-03-172019-03-14

1) Merge Modifications (19)
2) MMVD Modifications (12)
3) AMVP Modifications (7)
4) Weighted-Prediction Modifications (2)
5) Complexity Reduction (7)
Adoptions recommended by BoG:

Normative changes
Complexity Reduction
JVET-M0193 CE4-related: Pairwise Average Candidate Reduction
0.01%/0.00% loss in RA/LB, reduce pairwise candidate from 6 to 1
JVET-M0300 CE4-related: HMVP and parallel processing with tiles and tile groups
(this resets the history table at the beginning of each tile, however under the assumption that tile
boundaries coincide with CTU boundaries which may not be the case with flexible tile concepts. It was
suggested that proponents should communicate with tile experts and see whether there is a misaligment
with concepts that will be put into VVC draft 4). It was later confirmed by the text editor that only a small
(kind of editorial) change would be required. (might be that depending on further discussion on tile
concepts, some more alignments may be necessary)
JVET-M0117 CE4-related: On MVP candidate list generation for AMVP
0.01%/0.01%, pruning number 10->1, MV rounding 13->3
Bug Fix/Cleanup/Harmonization:
JVET-M0436 AHG2: Regarding HMVP Table Size. Reducing number from 6 to 5. As the entry 6 is
never used in the current spec, this is an editorial issue.
JVET-M0264 Non-CE4: Harmonization between HMVP and GBi, such that the GBi weight is also
stored in HMVP. Can be seen as a bug fix – gives very small improvement -0.01%/-0.01%.
JVET-M0068 Non-CE4: MMVD scaling fix
-0.02%/0.00%, remove redundant scaling, makes it identical with regular MV scaling
JVET-M0171 CE4-related: MMVD cleanups
-0.03%/0.02%, M0068+Forbid 4*4 bi + align SW with WD
JVET-M0111 AHG13: On bi-prediction with weighted averaging and weighted prediction
The same syntax design to support WP is also proposed in JVET-M0067
It is noted that inclusion of WP was decided at the 12th meeting, but had not yet been
implemented in the text (although the software had it). Furthermore, it had been decided
to disallow combination of GBi and WP. This was implemented by disabling GBi
signalling whenever WP is enabled for the current bi-predicted block.
JVET-M0479 Non-CE4: On clipping of scaled motion vectors
0.00%/0.00%, always clip MVs to 18 bits
Coding Efficiency:
JVET-M0255 AHG11: MMVD without Fractional Distances for SCC
Page: 304 Date Saved: 2019-03-172019-03-14

-1.58%/-2.74% in SCC (TGM class) tests with CPR off, -0.76%/-1.66% with CPR on,
one slice level flag indicates whether distance is full-pel. It is further pointed out in the
Track B dicussion that it was demonstrated to provide benefit for UHD when such an
option is available (see under CE 4.4.5). A version shall be used that just multiplies the
current MVD distances by 4.
JVET-M0444 CE4-related: Simplified symmetric MVD based on CE4.4.3
RA -0.33%, encoder is improved and BDOF is disabled on SMVD. 4.4.3 had a gain of
0.16%, but runtime increase of 5%, which is still the case here. By disabling BDOF,
some run time is saved, but then more encoder checks are done on the SMVD, which is
where the gain comes from.
JVET-M0502 CE4-related: Improved context for prediction mode flag
-0.09%/-0.02%, add one context to code pred_mode_flag, no change of run time.

(put the detail above under the corresponding contributions)
Proposals suggested for study in upcoming CE:

Merge-related
Syntax modification
JVET-M0069 Non-CE4: Syntax change of MMVD
-0.11% (102%, 100%)/-0.23% (102%, 100%). Decouple MMVD mode and merge
mode
The proposal signals MMVD as separate mode, which appears desirable for a more
clean design. There are also additional checks which might contribute to the
improvement of compression, but also increase encoder runtime. Results should also
be provided which implement the syntax change without increasing number of
encoder RD checks.
JVET-M0231 CE4-related: Regular merge flag coding
0.00% (100%, 96%)/-0.23% (102%, 92%). The codeword length for regular merge
mode becomes the shortest one
JVET-M0359 Non-CE4: Modification of merge data syntax
-0.06% (100%, 101%)/-0.17% (100%, 101%). MMVD flag is signalled when
merge_idx < 2
JVET-M0369 CE4-related: Syntax changes of merge data
-0.07% (100%, 101%)/-0.14% (101%, 101%). Re-arrange order of the syntax elements
for varieties of merge modes
It is noted in the Track B discussion that the benefit of some of the last three methods is low, in particular
if the separation of MMVD from merge (M0069) would be implemented. Therefore, also combination of
M0069 and each of the other three should be tested.
Merge list simplification
JVET-M0405 CE4-related: Simplified merge candidate list for small blocks
Page: 305 Date Saved: 2019-03-172019-03-14

0.09% (106%, 104%)/0.14% (108%, 107%). Only keep one spatial/temporal candidate
without pruning when W*H <=32.
From Track B dscussion: the loss does not justify the simplification, as there is no real complexity
problem at the decoder. No value investigating this in CE.
JVET-M0433 CE4-related: Constraint on GBi index inheritance in Merge Mode
0.03% (101%, 101%)/0.03% (102%, 102%). Remove GBI inheritance for affine merge
and MMVD
From Track B discussion: The benefit is rather small, only 3 out of 84 bits are saved, and it generates a
small loss. No value investigating this in CE.
STMVP
JVET-M0518 CE4-related: Supplemental results on STMVP design of CE4.2.3.a and combination
with methods of JVET-M0126 (CE4.1.2.a) and JVET-M0127
-0.10% (100%, 100%)/0.06% (101%, 99%)
It is noted in the discussion in Track B that this would definitely not be worthwhile to consider when
there is still loss in LB. Might be better withdrawn when this is still the case by the time of submitting the
CE software.
JVET-M0713 CE4-related: simplification of CE4.2.2
-0.11% (100%, 100%)/0.00% (107%, 110%)
It is noted in the discussion in Track B that CE4.2.2 disabled the method in LD, as it reportedly gave loss.
Therefore, the same statement would apply as for JVET-M0518.
MMVD-related
From Track B discussion: This part should be combined with the Sub-CE on MMVD mode signalling
above, in particular combination with JVET-M0069 should be investigated.
JVET-M0206 CE4-related: MMVD improvements
-0.10% (102%, 103%)/0.01% (100%, 101%). Change the binarization method for
MMVD distance index
JVET-M0267 Non-CE4: Harmonization of MMVD and AMVR
-0.14% (100%, 100%)/0.00% (100%, 100%). Distance based on signalled AMVR
From Track B discussion: It should be clarified how this relates to the adoption of JVET-M0255, and
different combinations tested (e.g. enabling only one, different ways of interpreting them together)
JVET-M0307 CE4-related: Candidates optimization on MMVD
-0.08% (96%, 99%)/-0.02% (99%, 101%). Reduce distance candidates and introduce
distance refinement
JVET-M0308 Non-CE4: MMVD simplification
-0.01% (97%, 98%)/0.08% (100%, 99%). Remove MVD scaling in MMVD
From Track B: Not worthwhile, not in CE.
JVET-M0314 CE4-related: MMVD improving with signalling distance table
-0.20% (103%, 97%)/0.02% (104%, 100%). Signalling the distance table in slice
header
Page: 306 Date Saved: 2019-03-172019-03-14

From Track B: Part of the gain comes from the encoder optimization “4.4.5*”. So, the benefit of
signalling as such seems to be low, in particular considering the increased encoder runtime. Not
worthwhile, not in CE.
JVET-M0315 Non-CE4: MMVD scaling simplification
Same as JVET-M0308, and add one SPS flag
From Track B: Not worthwhile, not in CE)
JVET-M0435 CE4-related: MMVD offset table signalling
-0,19% (100%, 99%)/0.01% (103%, 97%). Like JVET-M0314 but with differential
coding
The same comment applies as above for JVET-M0314.
TMVP Storage Reduction
From dicussion in Track B: This sub-CE is not needed, as the JVET-M0512 solution was adopted.
JVET-M0230 CE4-related: Temporal MV buffer reduction
0.03% (100%, 100%)/0.09% (100%, 99%). Lower MV bits
This is a relevant reduction of buffer. However, it is suggested that instead of using scaling (1/16 to 1/4),
simple clipping from 18 to 16 bits should be investigated as well.
In this context, it is mentioned in the Track B discussion if it might be useful to define some restriction of
MVs, just to prevent for some future application with extremely large picture sizes valid ranges might be
exceeded.
JVET-M0346 CE4-related: Non-square compression grid for temporal motion data storage
0.06% (100%, 100%)/ 0.23% (100%, 100%). MV stored in grid
JVET-M0512 Non-CE4: On Temporal Motion Buffer Compression
0.00% (99%, 100%)/0.02% (100%, 102%). Remove POC storage and store MV in a
converted way
From subsequent discussion in Track B:
This approach stores the MV 8x8 grid in a floating point format, 6 bit mantissa (incl. sign) and 4 bit
exponent. Has been cross-checked, text is available, provides significant reduction of MV memory.
Comes with practically no loss and is well understood.
Decision: Adopt JVET-M0512 second aspect as described above.
The following open questions were reported by the BoG:

Depending on CE decision
Pending on JVET-M0170 (which was adopted)
(JVET-M0272 CE4-related: Restrictions on History-based Motion Vector Prediction
0.00% (101%, 101%)/0.02% (100%, 97%), disable HMVP table update for 4*4
block; disable using virtual merge candidate for HMVP update; HMVP candidate
is only pruned to the first two spatial/temporal merge candidates
From Track B: first aspect not relevant after adoption of M0170. The third aspect was not relevant due to
the CE4.1.1/2 decision which solved the problem of reducing pruning steps. The additional benefit of the
second aspect standalone was not obvious.
Page: 307 Date Saved: 2019-03-172019-03-14

JVET-M0345 CE4-related: Remove redundancy between TMVP and ATMVP
-0.04% (100%, 100%)/0.00% (101%, 102%), Skip TMVP process in merge mode
when CU size is equal to 8x8 or W=4 or H=4
From follow-up in Track B: The case of 4x4 is no longer relevant after adoption of M0170. This proposal
would modify the merge list construction for cases for 8x8, 4xN, Nx4, N!=4. This introduces some
irregularity, has only small gain, and is not critical case of processing. Put in CE.
JVET-M0473 Simplified HMVP

0.02% (100%, 101%)/0.02% (100%, 100%), HMVP table is updated at 16x16 grid,
Remove reference checking in merge list pruning on HMVP candidates
From follow-up in Track B: Is not in a critical path and has a slight loss – not worthwhile to consider.
JVET-M0350 CE4-related: Quadtree-based Merge Estimation Region for VVC

0.49% (94%, 90%)/0.49% (93%, 91%)
In the follow-up discussion in Track B, it was asked whether there would be much difference if it was
implemented as encoder-only approach? It is probably good for some encoder runtime reduction, but has
also quite some loss, so we would likely not adopt it or put it in CTC.
JVET-M0507 has two aspects, where the aspect of removing the clipping for the shared merge list might
also be beneficial on top of JVET-M0170. It is reported to come at no coding loss. The proponents of
M0507 discussed with proponents of M0170 that the check for one of the subbocks being outside of the
picture could be removed, whereas another check whether the CU center is still inside needed to be
added, to make it consistent with other boundary check conditions in VVC. Proponents of M0170 were to
make an update on this aspect.
Related to JVET-M0281
JVET-M0081 Non-CE4: Simplification of AMVP list generation in AMVR
0.01% (101%, 99%)/0.03% (101%, 99%), Remove all intermediate rounding for
AMVR mode, only keep the final rounding
From discussion in Track B: The unification of where the rounding is done was achieved by adoption of
JVET-M0281, no need to change that again.
Related to JVET-M0403
JVET-M0422 CE4-related: Simplified MVD coding
0.03% (100%, 100%)/0.02% (99%, 103%), bypass code coding
abs_mvd_greater1_flag
From discussion in Track B: Saving context coded bins in MV coding does not have high relevance, as it
hardly influences the worst case of CABAC throughput. Getting it at expense of loss is not desirable.
0.06% (101%, 101%)/ 0.10% (100%, 103%), unified merge list size = 5; -0.02%
(101%, 101%)/ 0.00% (100%, 103%), merge list size = 6
JVET-M0661 AHG-13: On Merge List Size
Page: 308 Date Saved: 2019-03-172019-03-14

CTC use unified merge list size = 5.
From the discussion in Track B: VVC3 has the choice of signalling merge list size. This is inherited from
on the selected maximum number. It is discussed whether such encoder choice is still relevant for VVC.
No action was taken on these two proposals.
JVET-M0330 CE4-related: Simplification of MMVD scheme

0.25% (93%, 98%)/0.07% (98%, 100%), reduce MMVD base candidates to 1; -0.06%
(100%, 101%)/-0.12% (101%, 100%) reorder merge list construction based on block
dimensions; Combined: 0.07% (94%, 98%)/-0.11% (98%, 100%)
From discussion in Track B: Reduction of MMVD candidates gives loss and is mainly at benefit of
encoder. At the last meeting, when MMVD was adopted, different numbers of candidates were
considered and it was finally decided to use two, based performance/complexizy tradeoff. As the gap
between using one and two candidates may have become smaller, it could be worthwhile to consider this
aspect again on top of VTM4. Test this as part of the MMVD sub-CE, in combination with other
proposals.
Changing the sequence of candidates based on block shape introduces some irregularity in merge list
construction, which is not desirable (same proposal was investigated in earlier CE but not considered).
JVET-M0857 BoG report on CE3-related intra prediction and mode coding [G. Van der
Auwera]
(Track A Tuesday 1430–1630 GJS)
The BoG reviewed related input contributions to Core Experiment 3 on intra prediction and mode coding,
and formulated recommendations for consideration by the track (A).
 Cross-component prediction (14)
 Luma intra mode coding (8)
 Chroma intra mode coding (6)
 Interpolation of intra reference samples (4)
 PDPC-related (7)
 Various (7)
The BoG met on 11 Jan. 2019 from 9:00am–1:00pm, from 3pm–7pm, and on 12 Jan. 2019, from 9am–
1:00pm, 3pm–6pm. [Incorporate into section 2]
The BoG made the following recommendations:
Page: 309 Date Saved: 2019-03-172019-03-14

 Adoptions:
o JVET-M0064: simplification of the current VTM3 division operation used in CCLM modelling;
VTM3 includes 2×512 tables (16 bit elements), which is reduced to one table with 16 entries (4
bit elements), and in addition the bit depth of the model slope parameter (alpha) is reduced from
15 bits to 5 bits. No significant coding efficiency impact was reported. Among proposals, this
was the simplest approach. Decision: Adopted.
o JVET-M0095 (editorial): third proposed aspect harmonizes the filtering decision for the reference
samples for all directional intra modes (VVC draft Table 8-4 value for nTbS=2 entry modified
from 20 to 16). Editor action item: Agreed.
o JVET-M0238: linear interpolation that PDPC uses on the secondary boundary for adjacent
angular modes is simplified to nearest neighbour. No significant coding efficiency impact was
reported. This saves several calculations. Decision: Adopted.
 CE tests:
o Reducing the number of reference samples used to compute the cross-component linear model
parameters: JVET-M0108, JVET-M0211, JVET-M0212, JVET-M0219, JVET-M0229, JVET-
M0274
o Multi-model LM (MMLM): JVET-M0384 (determine the block size restriction that is required to
improve the worst case of MMLM and evaluate different formulas to determine the knee-point
for deriving the two models)
o Harmonization and simplification of MPM list construction: JVET-M0210, JVET-M0239, JVET-
M0295 (method 1 + JVET-M0783 = JVET-M0815), JVET-M0494 (methods 2, 4, 5), JVET-
M0528
 Question: Does the scope of this test include MPM list construction of ISP, CIIP?
 Remark: It is proposed to have one software codebase for testing the unification proposals and
separate the unification tests from intra search RD effects. The planar prioritization aspects,
context changes, can be tested on top of the unification tests in additional tests.
 In Track A review Tuesday afternoon, it was suggested that the main goal should be to have a
simplification and harmonization the different ways of how modes are selected. It was noted
that CE10 also includes other proposals relating to MPM list construction (and for
eliminating MPM usage) relating to CIIP and suggested that issues relating to MPM list
construction be considered together in a CE.
 Intra reference sample deblocking: JVET-M0138 (comparing the proposed method with strong
intra smoothing method from HEVC in terms of complexity, artefact reduction) – this has a
subjective effect – in Track A, it was agreed to plan to put this in the same CE as deblocking,
since it has a similar need for subjective evaluation of deblocking artefacts.
 Open issues:
o BoG recommended to present and discuss following documents related to small block size
restrictions in the category of complexity analysis and reduction (section 7): JVET-M0065,
JVET-M0169.
o JVET-M0099: BoG recommended first considering other proposals are presented in the luma
mode coding category. In Track A review it was agreed that such an optimization proposal should
be deferred to later consideration once the elements of the design that are being optimized
become more stable.
o BoG recommended considering the block size restrictions for PDPC preferably when additional
hardware/software experts are present: JVET-M0045, JVET-M0122, JVET-M0238. In Track A
review, this was suggested to also apply to JVET-M0814
Page: 310 Date Saved: 2019-03-172019-03-14

o JVET-M0358: BoG recommended testing during the meeting, as additional result (AI and RA
conditions; 1 tile/CTU configuration), the “AND condition” version of the reference sample
availability conditions and report back during the current meeting. The proposal is that when the
prediction mode is DC or planary only use PDPC when the above and left samples are both
available. A test was run both for CTC and for a case with 1 CTU = 1 tile, so that there would be
many instances of partial availability. The coding efficiency difference was very small, but was
suggested to be larger subjectively. For the 1 CTU = 1 tile case, the coding efficiency benefit was
0.1%. This would introduce a different type of processing for planar and DC than what is
currently included in the design – currently, these modes don’t need a “PDPC off” path. In CE10
there was a consideration of using planar mode without PDPC but this was not done. In the Track
A discussion, it was agreed that the benefit seemed insufficient for adding an additional
processing type that is otherwise not in the design (i.e., planar and DC without PDPC), since the 1
CTU = 1 tile case should have shown more benefit if there was a strong need. So no action was
taken on this.
In the Track A review was a comment that there was an aspect of M0158 that might need further
consideration. There are two 4-tap filters for angular mode intra prediction using the reference samples
(one smoother one derived by training and the other a sharper filter derived as DCTIF which is the same
filter used for MC interpolation of chroma). This contribution proposed using filter tap values derived
from a formula instead of the values currently defined in a table. The contributor said there was a phase
inconsistency in the current table of phases. An illustration of a case with a sine wave in the reference
samples to show a periodic edge generation phenomenon with the current filters.
Another proposal M0095 would reduce the number of phases from 32 to 16 (for both luma and chroma).
No action had been taken on that, as it was considered a minor issue at this stage.
No difference in coding efficiency was shown. This could be kept in mind in further work, but there
didn’t seem to be a need to consider this change at this stage. It was remarked that these proposals may be
logical, but we don’t need to consider such a small change before the design is more mature.See section
6.3.
JVET-M0858 BoG report on CE9 related decoder-side motion vector derivation

contributions [S. Esenlik]
See section 6.9.This report reviewed in Track B Wednesday 16 Jan 1115-1320 (JRO).
One session was held between 15:00 ~ 20:15 on January 12, 2019, for discussing 12 technical
contributions in two categories, BDOF (7 contributions) and DMVR (5 contributions).
Recommended for adoption by BoG:
o No impact on CTC.
gradient in case of other bit depths than 10.
Question if the change would still be supporting the 16 bit SIMD design of software? Proponent confirms
that this is the case, may need further checking by SW coordinators.
Revisit (plenary): What is the general support of different bit depths in VVC? Might other tools that were
added in recent meetings have similar problems. Definitely, bit depths up to 12 bits should be supported
Page: 311 Date Saved: 2019-03-172019-03-14

consistently, whereas it is likely that for higher bit depths some more precision might be required.
[Editors to consider – needs to be resolved in further work]
Recommended CE tests, BDOF related:

 JVET-M0073 Non-CE9: On early termination for BIO
 JVET-M0249 Non-CE9: Modifications on Bi-Directional Optical Flow
 JVET-M0284 CE9-related: BDOF Modifications to Enable 64x64 VPDU
o Regarding hardware implementation of BDOF, at least, there are two or three problems.
o One is a buffering latency of SAD calculation for early termination before BDOF.
o Second is huge number of memory access with large CU.
o Third is memory access limitation to enable VPDU.
o Creating a new CE to solve above problems.
o None of the methods has significant impact on compression performance.
It was discussed in Track B if it might be better to remove early termination totally to simplify the design
and solve the buffer latency problem, as this does not have impact on worst case complexity. Document
JVET-M0890 reports that by removing the early termination, the result improves by 0.04%, but decoder
runtime increases by 3%. This should be one of the comparison tests in the CE. Furthermore, the
maximum size where early termination is used should be blocks of size 256 luma samples.
Recommended CE tests, DMVR related:

 JVET-M0077 CE9-related: Relaxation of block size restriction for DMVR
o -0.81/-0.90/-1.00% change in BD-rate (Y/U/V) with 111/119% enc/dec time.
From the discussion in Track B: This is estimated to have up to 0.2% loss compared to the adopted
version, and does not show decoding time decrease (even though it performs subsampling in SAD
calculation). Not worthwhile to consider in CE.
 JVET-M0078 CE9-related: Combination of JVET-M0077 and CE9.2.5
o Study early termination aspect of M0078 (which is also described in M0062) separately if
MRSAD version of DMVR is included.
From discussion in Track B: Not necessary to study MRSAD, since SAD version of DMVR was
adopted. There is another aspect that points out a similar problem as in JVET-M0063 where the early
termination is dependent on bit depth and block size. As this would not affect CTC condition, there is
no need to study in CE. Proponents are requested to study this aspect further with regard to the
adopted version of DMVR.
 JVET-M0148 Non-CE9: Simplifications to DMVR search pattern and interpolation for refinement
o First part proposes to replace 25 sample search space with 13 total points.
o Approximately: 0.08/0.1/0.09% BD-rate change (Y/U/V) w.r.t. to the anchor that is used
(CE9.2.1g).
o Second part proposes simplification in complexity of bilinear interpolation of DMVR
CE9.2.1g version
o 0.04/0.03/0.04 BD-rate change (Y/U/V) w.r.t the anchor that is used (CE9.2.1g).
Page: 312 Date Saved: 2019-03-172019-03-14

From discussion in Track B: Reduces decoder run time by approx. 1%. It also introduces some more
specific processing at boundaries. Benefit not obvious, introduces some compression loss. Not
worthwhile to consider.
 JVET-M0516 Non-CE9.2.1.e: Non-local-mean-based MRSAD and Row-subsampled Search Pattern
for DMVR
o Approach 1: proposes Non-local mean value calculation for MRSAD
 0.07% luma BD-rate increase with same enc/dec times. Benefit over SAD might be
around 0.05% bit rate decrease.
From discussion in Track B: This still would require one more stage to first compute the mean before
the SAD can be computed.
o Approach 2: proposes 15 point row-subsampled search pattern.
From discussion in Track B: This amount of loss is not a good tradeoff versus the complexity benefit.
o Approach 3: proposes to disable DMVR for 4xN and 8x8 DMVR.
o Approach 4: proposes to disable DMVR for 4xN and 8x8 DMVR, and also remove padding,
such that in this combination the worst case memory BW would still be the same as 8x4 bi
pred.
It is further claimed that for the current DMVR (which only disables DMVR for Nx4 but not 4xN), the
current worst case memory bandwidth may still be exceeded for certain memory access patterns.
Study the aspects 3 and 4 in CE, including an analysis of memory access bandwidth of current scheme
and proposed schemes.
The following contributions were further discussed in Track B:

 JVET-M0223 Non-CE9: Co-existence analysis for DMVR with BDOF
From discussion in Track B: In the current design, DMVR and BDOF may be processed sequentially
(depending on condition that DMVR does not determine a modified MV, BDOF is computed). This
contribution shows that parallel computation, and deciding by an additional cost criterion does not
provide benefit. No action from the current approach, but it would be desirable to find another
solution on the cascade operation.
 JVET-M0316 CE9-related: simplification of BDOF
From discussion in Track B: Benefit of re-defing the BDOF refinement such that no multiplications
are necessary. Rate increase 0.15% for luma, 4-5% decoding time reduction.
As we don’t know the BDOF gain when operated together with DMVR, the loss may become lower
in VTM4. Depending on the outcome, such a complexity reduction could be attractive. Study in CE.
 JVET-M0517 Non-CE9: Methods for BDOF complexity reduction
From discussion in Track B: Two aspects are considered a) subsampling in OF computation b)
reduction of precision of multipliers. There is no noticeable change in decoder runtime, the benefit
would be more relevant for hardware (in particular b). However, in BDOF the gradient computation
is less of concern in terms of complexity. Overall benefit not clear – not relevant for CE.
Page: 313 Date Saved: 2019-03-172019-03-14

JVET-M0862 BoG report on CE2 related subblock motion compensation contributions
[Y. He]
This report was reviewed in Track B Tue 15 Jan 1010-1215 (JRO).
Adoptions recommended by the BoG:
Normative changes
JVET-M0145: affine sub-block MV clipping, no loss, BF
JVET-M0192 (method 4)/JVET-M0462: sub-block MV derivation for chroma component, very small
loss in chroma
JVET-M0166 (change 2)/JVET-M0228 (modification 1)/JVET-M0477(change 2), all proposing the
same: remove MV comparison in constructed affine merge candidate derivation, 0.01% gain in RA,
0.01% loss in LB
JVET-M0273 (change 1)/JVET-M0240/JVET-M0116 (method 1)/JVET-M0338(method 1)/JVET-
M0204(method 2): only using left neighbour for SbTMVP offset derivation. This has a loss of LDB
0.01%, none in RA
Encoder optimization
JVET-M0247: affine motion estimation for affine AMVR, gives 0.09% gain, but increases encoder
runtime by 3% for RA.
JVET-M0839: increasing the number of RD checking for affine merge mode coding, 0.05% gain in RA,
no runtime increase, somewhat larger gain in A1 [Ed. Is that A1 or AI?]. However, cross-checkers report
that the runtime is slightly increased by 1–2%.
It was discussed in Track B whether these are giving enough benefit to justify. After all, the performance
of the respective tools is somewhat increased, particular for large resolutions.
Technologies suggested for CE study:

Affine motion compensation and affine MV coding:
JVET-M0467: affine Symmetric MVD: Improves compression by 0.16% for RA with 8% runtime
increase. It is pointed out in the discussion in Track B that such a small gain for this amount of runtime
increase would not justify adoption.
Affine merge mode:
JVET-M0166 (Change 1): selecting the MV having the reference index equal to 0 for both lists
(has 0.05% loss in LB, 0.01% in RA, but is asserted to be significant complexity reduction)
JVET-M0434: Applying constraint to constructed affine merge candidate
(0.02% gain in RA, no change in LB, complexity reduction)
Worst case memory bandwidth reduction for sub-block modes:
These methods resolve the problem that the worst-case memory bandwidth of these modes is not worse
than for other modes in HEVC. The comparison point should be using 4x8/8x4 also for bi pred or 4x4 uni
Page: 314 Date Saved: 2019-03-172019-03-14

in subblock (as per item 1), as this would be necessary without imposing such vector constraints. It is
raised in the Track B discussion that this CE should also investigate the visual quality impact.
(1) sub-block selection based on uni/bi-prediction: one test for JVET-M0226 (2.4.1.a, 2.4.1.b,
2.4.1.c), JVET-M0150 (2.4.3.b), JVET-M0472 (2.4.4.a, 2.4.4.b, 2.4.4.c and 2.4.4.d)
(2) sub-block MV clipping: JVET-M0309 (2.4.2), JVET-M0702
(3) adaptive sub-block size selection and interpolation filter switching: JVET-M0400, JVET-M0310
(4) padding based MC method for small block: JVET-M0248
(5) conformance method: a) JVET-M0049, b) JVET-M0049 plus the formula in JVET-M0400
(6) integer motion for small block bi-prediction MC (e.g. 4x8 and 8x4): JVET-M0348
Local buffer storage reduction:
(JVET-M0110, JVET-M0168, JVET-M0270, JVET-M0266
It was agreed in Track B that all the items above shall be investigated in CE.
Open issues from BoG, where additional presentation and discussion was performed in Track B:
JVET-M0268, Non-CE2: Interweaved Prediction for Affine Motion Compensation
Additional results were presented in Track B which observe the VPDU constraint (denoted as test3/test4 in r2).
These show that the gain of 0.27% (RA) is retained, while current worst case memory bandwidth of subblocks
(relating to 4x4 bi) is not exceeded, also number of interpolations is not higher, and the additional superposition is
cheap. However, as it is the goal to establish more restrictions on the memory bandwidth of affine subblocks (see
notes on planned CE above) it would depend how the method of M0268 would perform in combination with those.
Study this aspect in CE.
JVET-M0432, CE2-related: Combination of CE2.2.3.d and affine inheritance from motion data line buffer
In comparison to CE 2.2.3.d (which replaces the local buffer for CPMV by a history-based approach and this way
reduces local memory storage), but came with 0.07%/0.09% loss for RA/LB, this method reinvokes the usage of the
CPMV candidate from the normal MV buffer at upper CTU boundary. The loss compared to VTM3 is now
0.03%/0.07%. Further study in CE.
JVET-M0343, Non-CE2: Simplified subblock motion derivation for SbTMVP
The complexity reduction is negligible, but small loss – no action.
M0311 was reviewed and agreed to become part of the CE on affine memory bandwidth reduction.
See section 6.2.
JVET-M0873 BoG report on CE10 related combined and multi-hypothesis prediction

contributions [C.-W. Hsu, M. Winken]
This report was reviewed in Track B Wed 16 Jan. 1500-1820 (JRO).
 CIIP modifications (12)
 OBMC (2)
 TPM modifications (23)
 LIC (6)
 Other (1)
Page: 315 Date Saved: 2019-03-172019-03-14

The BoG met on 13 Jan. 2019 from 6:00pm-10:30pm, 14 Jan. 2019 from 1:00pm-4:00pm, 14 Jan. 2019
from 7:30pm-11:00pm
Normative changes: recommendations of BoG:
Triangular mode:
1. Adopt syntax change of JVET-M0118: Same as in M0185, M0190, M207 (test 1), M0216 (the first
aspect), M0234 (change corresponding to the result table 7 and 8), M0317 (section 2.2), 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.
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.
3. Adopt using only one context model for merge_triangle_flag (JVET-M0490). Increases bit rate
approx. 0.01% for both RA and LDB, not a real severe complexity issue. Was discussed in Track B,
and concluded to better keep it unchanged for now.
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)
Decision: Adopt recommendations 1, 2, and 4 from the list above
Recommendations for testing in next CE:

TPM:
1. Merging candidate list construction (aspects from M0184, M0194, M0233, M0271, M0283, M0286,
M0317, M0349, M0399):
 Re-use general merging candidate list construction as common part
 Study different variants thereof within CE
It was reported that this comes with basically no loss, and makes the merge not only unified but some
proposals also simplify the merge list construction of triangular mode.
It was emphasized in Track B that it might already be an advantage if the first part of merge list
construction would be unified, and such a unification should not make the regular merge list
derivation more complicated.
Further, the merge list construction of triangular merge list construction is not overly critical, so such
modifications shall not penalize compression performance.
2. Signalling (has become obsolete by adoption 4. above, no CE necessary):
 All proposals use 3 syntax elements for the signalling (split direction and 2 merge indices)
 Study different variants thereof within CE
3. Study combination of triangular prediction and MMVD (within CE about motion vector coding)
(From discussion in Track B: As the reported compression gain is probably lower due to the adoption 1.
above, and the current approach has a high impact on encoder runtime, proponents should study the
method and if a fast encoder method is available, make input to the next meeting, no CE)
TPM CE bullet point 1. To be included in CE4.
CIIP
Page: 316 Date Saved: 2019-03-172019-03-14

1. Study intra/inter weights within a CE (M0096, M0454): M0454 reduces CIIP only with planar mode,
and has identical weighting for the entire block (which is signalled). Compression gain 0.1%, but
somewhat simplifies by removing unequal weighting, and also does not need special MPM list.
M0096 has 0.1% gain in RA, 0.15% in LB, and uses equal for whole block, and only planar. The part
of M0096 which applies PDPC after blending should be removed (see notes under M0492 below)
2. Study MPM generation for CIIP within a Sub-CE of CE3 (for comparison purposes this shall also
include methods which don’t use MPM list for CIIP) (M0183, M0232, M0276, M0296): These target
either simplification, harmonization, or improvement of the CIIP MPM coding. Gains are reported up
to 0.02%. Compared to the benefits of CE CIIP 1., this does not seem to be competitive, as the latter
does not need MPM signalling for CIIP at all, removes the non-uniform blending, and has slightly
more gain. This sub-experiment would not have chances for adoption, unless something improves in
these regards. Such ideas would better be brought as new proposals by next meeting.
3. Propagation of intra modes from CIIP blocks shall also be studied within CE (M0294): There is no
compression benefit, and though some of the current design my appear “unlogical”, there is no
problem with it, and propagating this information may even require more storage. If CE CIIP 1 would
be successful, it is not needed anyway.
Establish bullet point 1. as CE.
LIC (M0088, M0115, M0182, M0224, M0450, M0500)

 Given that there will be further action on LIC, to minimize implementation complexity, LIC should
be investigated having the following properties:
o Usage of reconstructed intra coded, CIIP and IBC blocks, as this would have impact on
complexity and parallel implementation pipelining (test with and without, and further study
the impact)
o Disabling LIC over CTU boundaries is not necessary
o Disable for CIIP blocks
o No temporal inheritance of LIC flag
o No pruning based on LIC flag in merging candidate list generation
o Disable LIC for all subblock modes
o The VPDU issue should be solved (e.g., disabling for 128xN or by other method which
avoids violating VPDU constraint).
o Bi-Prediction issue should be solved (LIC should not have to be applied twice, i.e. for each
L0/L1 as done in CE10.5.2). Possible solutions: Do it after bi-predictive combination or
restrict LIC to uni-prediction.
Open issues discussed in Track B:

CIIP:
 JVET-M0492 ask hardware experts about their assessment.
From Track B discussion: It was not possible to conclude. Some concern was raised that in hardware
it may not allow re-using existing PDPC logic, as it is usually in pipelining connected to intra
prediction, and here it would be connected to inter prediction. Furthermore, the proposal does not
provide compression benefit (small loss in RA, small gain in LB, and the reduction of software
runtime is low.
Page: 317 Date Saved: 2019-03-172019-03-14

JVET-M0082 raises an issue on appearance of banding within CIIP blocks when horizontal/vertical
modes are used, appearing at positions where the weight changes. Though it is not obvious that such
such artefacts would still appear in a moving video, it is well noted but would be resolved in case
when these modes would be removed, or the non-uniform weighting would disappear. However, there
is no benefit (even some small compression loss) when only planar and DC are retained.
OBMC:
 JVET-M0357 has new OBMC results, which is however not directly related to current CE results. It
uses uni prediction for the current block, and bi prediction (not integer accuracy, but sub-pel with
shorter interpolation filter) for the overlap areas. It provides slightly higher gain than 10.2.2 (0.42%
instead of 0.37%), but is not obvious to be less complex (though it has only 5 instead of 6 references
to access, it employs additional interpolation, so in terms of signal processing there appears to be
more complexity). Following the plenary decision, this is not enough evidence to re-open the OBMC
CE.
Other:
 JVET-M0424 addresses an issue that might be with interpolation filtering (i.e., requiring 32 bit
arithmetic in software)
This issue was discussed on the JVET reflector (see email of F. Bossen) – not clear if there is really a
problem. Further evidence necessary before any action could be taken. Otherwise, gain by new filters
is so small that it would not justify adoption by coding efficiency benefit. Needs further study but no
topic for CE.
The current SIMD implementation is with 32 bit.
See section 6.10.
JVET-M0874 BoG report on CE13 and CE13 related 360° video coding [J. Boyce]
See section 5.13.(Track A 1600-1700 Thursday 17 January GJS)
The BoG met on 13 Jan 2019 from 1800 to 2030. The BoG met on 14 Jan 2019 from 1800 to 1900. The
BoG met again on 16 Jan from 1700 to 1800.
The BoG recommended to adopt JVET-M0892 for disabling of in-loop filters (deblocking, SAO, and
ALF) at vertical and horizontal boundaries signalled in the SPS at MinCbSizeY granularity.
It was noted that the change that was requested was not specific to 360° video.
It was noted that this proposed change is for entire columns / entire rows, not line segments that do not
cut through the entire picture.
For a conventional cubemap, the filter would be disabled for one horizontal line in the middle of the
picture.
It was discussed what sort of limit there would be for how many of these cuts would be allowed. One
suggestion was a limit of 3 cuts in each direction.
The granularity was also discussed – whether it was really necessary to have 4x4 granularity.
It was discussed how this would be implemented in a real decoder. Checking a long list of positions
would not be reasonable.
Due to a desire for further study of this before making a decision, no action was taken on this.
Further study was also recommended to consider more flexible in-loop filter disabling patterns, use cases,
and HW implementation complexity.
Page: 318 Date Saved: 2019-03-172019-03-14

The BoG endorsed the recommendation of HLS BoG to change the sps_ref_wraparound_offset to
sps_ref_wraparound_offset_minus1 and changing the units to be MinCbSizeY as in option 1.
The BoG recommended, and Track A endorsed, the following for the 360Lib software:
Modify chroma sample location in blending process for PHEC (from JVET-M0368) – basically a bug fix
Adopt Hemisphere CMP and Hemisphere EAC projection formats (from JVET-M0452)
Profiling was discussed. Thus far, we have not made any decisions that we believe would require having
different profiles (perhaps bit depth, colour format, etc, but not coding features).
JVET-M0877 BoG report on CE6 related transforms and transform signalling

contributions [X. Zhao (Tencent]
(Reviewed in Track A Tuesday 15 January 1700 and Wednesday 16 January 1300-1400 (GJS)
The BoG met on Sunday January 13rd from 15:35 to 21:24 and Monday 14th from 20:30 to 22:10.
This BoG is mandated to review the CE6 related contributions of the 13 th JVET meeting. Totally 25
contributions have been reviewed, which are categorized as follows,
5. Complexity reduction (14 proposals)
6. Transform skip (6 proposals)
7. Transform selection (2 proposals)
8. Others (5 proposals)
The following BOG recommendations were made:

 Recommended adoptions:
o Context reduction (6 contexts reduced to 1 context) of MTS flag signalling (JVET-M0347).
In Track A review, this was considered too small an optimization to bother with at this stage.
It should be kept in mind when finalizing the spec as an opportunity for cleanup.
o Bug-fix for mismatch between spec text and software related to CBF signalling (JVET-
M0361, bug-fix on spec text). Decision: Agreed in Track A review – this was just an error in
drafting the text.
 CE tests proposed by the BoG:
o Modified transform selection
 Transform selection for chroma components (JVET-M0480, JVET-M0501). We
currently only have MTS for luma. In the Track A review, the potential improvement
seemed small and this would involve needing to support multiple chroma transforms
for chroma, so no CE was planned for this.
 Transform selection to multi-hypothesis inter-intra mode (JVET-M0482). This
proposal is to reduce the number of transform candidates in that mode. This would
introduce a design inconsistency and has no benefit in coding efficiency. A non-
normative approach has not yet been tried. No CE was planned for this.
 Unification between MTS and transform skip (JVET-M0501). This reportedly shows
2.8% gain on Class F. In the Track A review, it was agreed to establish a CE for this.
 Open issues:
Page: 319 Date Saved: 2019-03-172019-03-14

o Complexity reduction of 32-length DST-7/DCT-8
 With a zero-out approach (JVET-M0297, JVET-M0046) (0.1% penalty for AI,
0.04% for RA).
 Using a two-stage transform scheme
 Track A Decision: Adopt JVET-M0297 Test 2.
 No CE.
o MTS simplifications with modified transform candidates and signalling
 BOG recommended revisiting in Track B to discuss whether a CE study is to be set
up for related contributions (JVET-M0304, JVET-M0366, JVET-M0340, JVET-
M0202, JVET-M0464) – these propose ways to reduce the number of candidates. In
Track A, it was agreed to study these in a CE:
 M0304 eliminates DCT8 completely, so uses only DCT2 and DST7, and
only sends one flag (reduces runtime, different tradeoffs with non-normative
search changes)
 M0366 uses a choice between 4 transform types instead of 5 (some gain and
encoder time reduction)
 M0340 (number of candidates depends and selection depends on block size
and intra prediction mode, at most three transform pairs considered, a little
loss and encoder runtime reduction) – Track A review indicated that this
seems contrary to a Ljubljana action and complicates the scheme – not to be
included in CE.
 M0202 (tests removal of some candidates normatively or encoder-only).
 The BoG recommended extending transform skip up to 16x16 (or 32x32?) only for
class F (and TGM test sequences). The transform skip change is suggested in M0072
and M0464. A new version of M0464 was provided with experiment results
combined with CPR, showing additional benefit. It proposes a truncated unary
binarization for the signalling. M0072 does not change the signalling but has
significant encoder runtime increase. M0464 has an encoder search modification that
avoids encoder runtime increase. A cross-checker liked the encoder search
modifications as a logical cleanup. Track A Decision: Adopt transform skip up to
32x32, with associated syntax approach in M0464 using tu_mts_idx. And enable TS
for block sizes up to 32x32 in CTC for all test sequences. Further study was
requested to identify potential runtime savings for disabling TS for some categories
of test sequences.
 The BoG recommended Track A to discuss further actions regarding the syntax
changes of MTS signalling (JVET-M0464, JVET-M0201). This is resolved by action
on M0464 noted above.
 Software tool for computing transform throughput (JVET-M0540): The BoG
recommended discussion in Track A to collect more opinions whether the proposed
software tool can be used for evaluating the CE6 study. No action was taken on this,
since there was not a plan for further CE work on transform speed-up approaches.
See section 6.6.
JVET-M0891 BoG report on CE7 related quantization and coefficient coding contributions
[Y. Ye]
This report was discussed in Track A Thursday 17 January 1700-1800 (GJS).
Page: 320 Date Saved: 2019-03-172019-03-14

There were 13 technical contributions in the CE7 related category. These contributions are classified into
the following three categories:
 Rice parameter related
 Complexity reduction and simplification
The first BoG session was held 1900 – 2345 on Jan 14 2019 in Saba.
The second BoG session was held 1300 – 1400 on Jan 17 2019 in Saba.
Recommended adoptions:
 JVET-M0470, CE7-related: Golomb-Rice/exponential Golomb coding for abs_remainder and
o In VTM 3.0, worst case is 33 bits for abs_gt3_level_flag, and 35 bits for dec_abs_level for
escape codes of coefficient levels, in comparison with is 32 bits for both syntax elements in
HEVC.
o Two aspects in this proposal: the first aspect uses a constant transition prefix code length of
6, and eliminates a LUT; the second aspect uses HEVC RExt extended precision scheme to
limit worst case code length to 32 bits
o Performance: 0.00%/0.01%/0.02% for AI/RA/LB
o Proposed aspects seemed to be straightforward and aligned with HEVC. It also would solve a
software issue that currently exists in VTM 3 that could cause decoder crash.
 JVET-M0251 (Non-CE7: Last position coding for large block-size transforms) and JVET-M0257
(CE7-related: coefficient scanning and last position coding for TUs of greater than 32 width or
height)
o Three contributions in this BoG tried to address the coefficient coding issues due to high
frequency zeroing: M0250, M0251 (which is a superset of M0250), and M0257
o Propose to scan only the portions of the transform blocks that have not been zeroed out
o JVET-M0257 and JVET-M0251 are identical from spec text point of view, but simulation
results are slightly different due to some difference in encoder implementation
o M0257: 0.00% AI, -0.01% RA, -0.01% LB
o M0251: 0.01% AI, 0.01% RA, full set of LB results not yet available at time of discussion
o Recommend to adopt M0251/M0257. Use M0257’s encoder implementation (better
performance and cleaner code)
Decision (BF): Adopt JVET-M0251/M0257 (software from M0257).
 JVET-M0305 CE7-related: Joint coding of chrominance residuals
o The proposal adds a chroma residual coding mode where the Cr residual is not signalled, and
is derived from the Cb residual by reversing the signs of the Cr residual.
o The proposed method is applied to intra and inter coded blocks.
o At the encoder side, the Cb and -Cr residuals are averaged together. In the proposed mode,
that average residual is coded. RD decision is made to select between the conventional
Page: 321 Date Saved: 2019-03-172019-03-14
chroma coding method and this proposed method (in which case the average residual thus
computed is coded). The mode flag is sent when the cbfs for both Cb and Cr are 1.
Overall Y U V Ave-UV
AI -0.29% -0.79% -2.16% -1.48%
RA -0.19% -1.44% -2.00% -1.72%
LD-B -0.08% -2.38% -4.83% -3.61%
LD-P -0.11% -2.46% -5.08% -3.77%
o This proposal achieves similar gains for all sequence classes and all coding configurations.
o This method is simpler than an LM chroma mode that predicts Cr from Cb that was
previously proposed, and achieves similar coding performance as that previous LM chroma
mode. This complexity reduction of this proposed method compared to the previous LM
chroma mode could be especially beneficial for the decoder.
o It seems that such coding gain was usually not available from coefficient coding methods.
o Low QP results (provided in a v3 of the contribution) were discussed at the second BoG
session. The chroma gains are reported to be somewhat lower than those of CTC, but the
gains in luma are similar to (AI case) or higher than (RA and LB cases) those of CTC.
o In Track A, a participant commented wondered whether there could be subjective artefacts.
o A participant asked how many blocks used this, and it was said that around half of the time
that both channels had a residual, it would use this mode.
o The proponent said it seems to also work for HDR.
Further study in a CE was planned for this.
BoG recommendations for CE testing:
 CE on coefficient coding (cleanup):
o JVET-M0198, CE7-related: Unified Rice parameter derivation for coefficient level coding
(some more computes but hardware friendly, removing one variation)
o No test of this one (some loss): JVET-M0469, CE7-related: Unified Rice parameter
derivation for coefficient coding
o JVET-M0558: CE7-related: Template-based Rice parameter derivation (some more storage
of reconstructed values and computes but hardware friendly, removing one variation)
related: Reduced local neighbourhood usage for transform coefficients coding
related: Reduced context models for transform coefficients coding
o JVET-M0491: CE7-related: Reduced maximum number of context-coded bins for transform
coefficient coding
 CE on screen content coding (coding efficiency)
o JVET-M0278: Non-CE7: Residual rearrangement for transform skipped blocks
o JVET-M0279: Non-CE7: Sign coding for transform skip
Regarding JVET-M0198, JVET-M0469 and JVET-M0558, during the BoG discussion, the pros and cons
of the proposed approach vs the current design in VVC draft 3 were discussed. The approaches of JVET-
Page: 322 Date Saved: 2019-03-172019-03-14

M0198 and JVET-M0558 seemed to be more hardware friendly, whereas the current coefficient coding
method in VVC draft 3 seemed to be more software implementation friendly.
This was discussed in Track A when determining which CEs to conduct.
See section 6.7.
JVET-M0901 BoG report on quantization related contributions [Y. Ye]

This report was reviewed in Track A [get time from section2] (GJS).
There were 8 technical contributions in the quantization control category.
The first BoG session was held 2000–2330 on Jan 15 2019 in Olympia. The second BoG session was held
1300 – 1510 on Jan 16 2019 in Saba.
 M0188 (On quantization parameter signalling considering CU area) and M0113 (CE7-related:
Quantization Group size uniformity)
o These two proposals solved the same problem of incoherent quantization group (QG)
definition in VVC draft 3. They proposed essentially the same solution. However, the two
proposals had different ways of expressing their solution in terms of WD text change. The
proponents were encouraged to harmonize the suggested WD changes, and the final decision
on WD text change should be deferred to the editors. The difference between the two
descriptions is purely editorial. Further work was later done to harmonize the text.
Decision: Adopt (text in M0113).
 JVET-M0119 CE7-related: Modified dequantization scaling
o The second aspect of this proposal is recommended for adoption
o In VVC draft 3, a scaling factor is applied when a transform block is of rectangular shape.
This scaling factor should not be applied in the transform skip case. It was reported that in the
reference software VTM-3.0, the scaling factor is applied in the inverse quantization stage
and then removes it during the inverse transform stage. However, in VVC draft 3, the scaling
factor is applied but not removed, which causes a mismatch between the software and the
spec. This contribution removes the (unnecessary) application and removal of this scaling
factor for transform skip blocks in the reference software, and proposes a WD change that
fixes the mismatch between software and spec. Decision (bug fix): Adopt.
M0685
Prediction of QP value.
HEVC had a different QP prediction operation for when WPP is on and off. When WPP is off, any QP
change will propagate to all subsequently coded blocks in the slice.
In the current draft the QP is predicted as the average of the QP above and to the left. If either of those is
outside the CTU, the previous one in decoding order is used as the predictor.
This is a problem for parallel encoding, e.g., when encoding a CTU at the left edge, the QP predictor
(which is from the right edge) may not be known.
M0685 proposed storing the QP values of the bottom of the above CTU and considering those
“available”. If both are available, an average would be used; if one is unavailable, the other would be
used.
In the discussion of the contribution, another method was discussed, which was to only have the QP of
the above CTU available if the current CTU is the first CTU of the row.
Page: 323 Date Saved: 2019-03-172019-03-14

It was noted that the QP values of the neighbour are already stored for deblocking purposes, so they could
be used. Another person commented that the storage for deblocking may be in a different part of the
decoding pipeline that would not be readily available.
The left-edge-only idea was suggested to potentially be beneficial for rate control in avoiding “dilution”
of a delta QP.
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 (text in a revision of M0685).
The BoG recommended study in an AHG on quantization control. This was agreed to be established.
It was noted that MTS affects the concept of quantization matrices.See section 6.16.
JVET-M0902 BoG report on contributions related to complexity analysis and reduction

[B. Bross, A. Filippov]
Track A Wed 16 January 1515-1600 (GJS).
There are 10 technical contributions in the complexity related category. These contributions are classified
into the following 4 categories:
 Small block size restrictions
 Complexity analysis
 Block size restrictions for PDPC
 Complexity reduction of motion compensation and MV coding
BoG sessions were held 19:15–21:00 on 01/15 in Coliseum. Section 1 of this document summarizes the
BoG’s recommendations. Section 2 of this document contains detailed notes on BoG discussion.
The BoG recommended software adoption of M0864, which suggests an enhancement of the tool to
measure the memory bandwidth in VTM.
Decision (SW): Adopt M0864 memory bandwidth analysis method.
The BoG recommended further discussion of the following:
Summary of contributions on small block size restrictions

Contribution Coding performance Disallowed Intra prediction loop Other
(Y, Cb, Cr) block sizes (throughput)
JVET-M0169 AI: 0.04%, 0.23%, 0.31% None 16 sample granularity Unchanged
(can help both RA: 0.07%, 0.43%, 0.54%
single and LD: 0.07%, 0.38%, 0.27%
separate tree)
JVET-M0245 AI: 0.05%, 0.29%, 0.40% Separate tree: 16 sample granularity Coef. Group:
(does not help RA: 0.02%, 0.39%, 0.42% Chroma in separate tree case, 4 2x8/8x2 for
single tree case) LD: -0.01%, 0.33%, 0.50% 2x2/2x4/4x2 otherwise. width/height 2
chroma blocks.
JVET-M0065 Option 1 Option 1: Option 1: Option 1:
(not helpful for AI: 0.00%, 0.04%, 0.03% Separate tree: 8 sample granularity in Single tree: 2x2
single tree case in RA: 0.01%, 0.17%, 0.17% chroma 2x2 separate tree case, 4 intra use DC
hardware) LD: 0.03%, 0.27%, -0.11% otherwise. only.
Option 2 Option 2:
AI: 0.03%, 0.26%, 0.38% Separate tree: Option 2: Option 2:
RA: 0.09%, 0.63%, 0.84% chroma 16 sample granularity Single tree:
LD: 0.00%, 0.24%, -0.43 2x2/2x4/4x2 in separate tree case, 4 2x2/2x4/4x2
otherwise. intra use DC
only.
VTM-3.0 without AI: 0.03%, 0.26%, 0.38% Chroma: 16 sample granularity
Page: 324 Date Saved: 2019-03-172019-03-14

small intra CU RA: 0.33%, 0.55%, 0.78% 2x2,4x2,2x4
LD: 0.21%, 0.17%, 0.60% Luma:
4x4,4x8,8x4
It was commented that it may be undesirable to depend on requiring decoders to be able to use parallel
processing, since some (e.g., software) decoders may not be able to do that.
It was agreed to consider these approaches in CE3.
Summary of contributions on block size restrictions for PDPC

Contribution Test # Restriction Compression performance (Y/U/V)
width + height <= 8 AI: 0.05% / 0.02% / 0.03%
JVET-M0045
RA: 0.03% / 0.04% / 0.00%
1 3. width + height <= 8 AI: 0.03% / 0.04% / 0.02%
4. width + height > 64 RA: 0.03% / 0.03% / 0.07%
2 3. width + height <= 8 AI: 0.03% / 0.03% / 0.04%
4. width + height > 64 (applicable only RA: 0.02% / 0.06% / 0.05%
to blocks with worst-case intra-
prediction modes)
JVET-M0122
3 3. width + height <= 8 AI: 0.01% / -0.03% / 0.00%
4. width + height > 64 RA: 0.02% / 0.07% / 0.04%
Both restrictions are applied only to blocks
with worst-case intra-prediction modes
3a width + height <= 8 (applied only to blocks AI: 0.02% / -0.03% / -0.07%
with worst-case intra-prediction modes) RA: 0.01% / 0.01% / -0.04%
width + height > 64 AI: -0.01% / -0.02% / 0.02%
JVET-M0238
RA: 0.00% / 0.08% / 0.10%
1 width * height <= 16 AI: 0.05% / 0.01% / 0.03%
RA: 0.03% / -0.05% / -0.01%
2 3. width * height <= 16 AI: 0.06% / -0.08% / -0.08%
JVET-M0814 4. max(width, height) <=32 for luma, RA: 0.05% / -0.08% / -0.05%
max(width, height) <=16 for chroma
3 width * height <= 8 for chroma AI: 0.00% / 0.03% / 0.02%
RA: 0.00% / 0.06% /0.02%
It seemed unclear whether PDPC is particularly an issue for small blocks.

A participant indicated that it may be too early in the process, so that we shouldn’t optimize such aspects
until the design is more stable.
No action was taken on these proposals, and no CE for them was planned.
M0248 was reviewed in the context of CE2 rather than in this BoG.
M0265 was not reviewed in the BoG. See notes for that.
See section 7.
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 Jan. 1500-XXXX.
This contribution provides the report of the BoG on neural networks (NN) for video coding, especially for
neural network based loop filter. An information report (JVET-M0691) is discussed in this BoG, and then
the CE plan.
Page: 325 Date Saved: 2019-03-172019-03-14

The BoG recommends the following plan of CE:
 Divide the 6 NN based loop filter methods into two category and build two sub CE test.
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 are many test cases, only choose some cases to test, as defined below.
o For SubCE1:
case 1a : DBF + SAO + ALF + NN filter, which is the case currently subCE1 contributions
used.
case 2a : NN filter. (optional test)
o For SubCE2:
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.
Page: 326 Date Saved: 2019-03-172019-03-14

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 is however planned to proceed like this for
initial tests to identify configurations which then finally tested with entire sequence.
See section 6.18.
10.7 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
BD-R Y BD-R Y
In-loop filters
ALF Fix pcm_loop_filter_d 0.0% 0.0% JVET-M0277 Decision (BF/text): Include
isabled_flag for disabling ALF as a third loop
ALF filter when the
pcm_loop_filter_disabled_flag is
set, as suggested in JVET-
M0277
Deblocking Subjective quality Long deblocking 0.1% 0.0% JVET-M0471 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 review in track B Thu
1330), pending on confirmation
from the viewing, and the more
detailed report on complexity
impact
Deblocking Subjective quality Deblocking of JVET-M0908 combination of JVET-M0103
CIIP boundaries and JVET-M0294
Reconstruction Coding efficiency Picture -0.9% -1.3% JVET-M0427 Decision: Adopt (modified as
reconstructon with noted).
mapping
Intra
Prediction mode Coding efficiency Intra subpartitions -0.6% -0.3% JVET-M0102 Decision: Adopt 1.1.1 proposal,
pending the provision of text and
its review.
CCLM Coding efficiency Modified CCLM 0.0% 0.0% JVET-M0142 Decision: Adopt 2.4.c with a
(HDR) downsampling high-level flag to switch
filter between two chroma format type
optimizations (pending test
results for applying the type 2
scheme to type 0 content).
CCLM Simplification Table reduction in 0.0% 0.0% JVET-M0064 Decision: Adopted
CCLM modelling
Prediction Cleanup Harmonize the ref JVET-M0095 Editorial action item: Agreed
sample filtering
PDPC Simplification Simplified linear 0.0% 0.0% JVET-M0238 Decision: Adopted
interpolation
CPR Coding efficiency Reference sample JVET-M0407 Decision: Adopt JVET-M0407
(SCC) memory reuse (variant a)
Page: 327 Date Saved: 2019-03-172019-03-14

CPR Cleanup CPR signalling - JVET-M0483 Decision: Adopt JVET-M0483
interaction with (text in zip v4, “r1”, probably
inter tools needs some more update along
the lines above)
Transform
MTS Complexity Fast DST-7/DCT- 0.0% 0.0% JVET-M0497 Decision (complexity reduction):
reduction 8 Adopt CE6-2.3a.
MTS Complexity 32-length DST- 0.1% 0.0% JVET-M0297 Decision: Adopt JVET-M0297
reduction 7/DCT-8 using Test 2.
zero-out
MTS/TS Simplification + Unifed MTS/TS 0.0% 0.0% JVET-M0464 Decision: Adopt transform skip
coding efficiency syntax + TS up to up to 32x32, with associated
(SCC) 32x32 syntax approach in JVET-
M0464 using tu_mts_idx. And
enable TS in CTC for all test
sequences.
TU partitioning Coding efficiency Sub-block -0.5% JVET-M0140 Decision (coding efficiency):
Transform (SBT) Adopt CE6-4.1a (pending the
for inter blocks 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: JVET-M0002 Decision (BF editorial): The
Downsampling of downsampling of the DCT2
the DCT2 transform matrix should be
transform matrix separate horizontally and
should be separate vertically (not assumed square)
horizontally and for #135.
vertically (not
assumed square)
Quantization
QP Fix Bug fix for JVET-M0113 Decision: Adopt (text in JVET-
quantization group JVET-M0188 M0113).
QP signalling
QP Fix QP Prediction fix JVET-M0685 Decision: Initialize QP from the
for parallel bottom left CU of the above
encoding CTU row when decoding the
first CU of a CTU on the left
edge of a tile group
Scaling Fix Modified JVET-M0119 Decision (bug fix): Adopt.
dequantization
scaling for TS
CABAC
Contexts Complexity Reduce merge idx 0.0% JVET-M0381 Decision: Adopt JVET-M0381
reduction ctx coded bins Test 2.2.2a (reducing number of
context coded bins in affine
merge). Text is available with
the contribution.
Contexts Coding efficiency 1 additional -0.1% JVET-M0502 Decision: all the suggested
context for adoptions are confirmed by
pred_mode_flag trackB. (Method 2)
Engine Coding efficiency Probability -1.0% -1.0% JVET-M0453 Decision: adopt “5.1.13* +new
estimation init from 5.1.2”
Residual Coding Complexity rem_abs_gt3_flag -0.1% -0.1% JVET-M0173 Decision (complexity reduction):
reduction in first coding pass Adopt CE7.4.
Residual Coding Fix Limited EGk for 0.0% 0.0% JVET-M0470 Decision (BF): Adopt JVET-
abs_rem/ M0470.
dec_abs_level
Residual Coding Fix Last position JVET-M0251 Decision (BF): Adopt JVET-
coding for large JVET-M0257 M0251/JVET-M0257 (software
block-size from JVET-M0257).
transforms
Inter
SBTMVP Complexity Only using left 0.0% JVET-M0273 Decision: all the suggested
reduction neighbour for adoptions are confirmed by
Page: 328 Date Saved: 2019-03-172019-03-14

SbTMVP trackB.
Affine Coding efficiency AMVR for affine -0.2% JVET-M0246 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 0.0% JVET-M0145 Decision: all the suggested
MV clipping adoptions are confirmed by
trackB.
Affine merge Complexity Remove MV 0.0% JVET-M0166 Decision: all the suggested
reduction comparison adoptions are confirmed by
trackB. JVET-M0166 (change
2)/ JVET-M0228 (modification
1)/ JVET-M0477(change 2)
Merge Fix Fix for cu_cbf JVET-M0361 Decision: Agreed in Track A
when merge review – this was just an error in
drafting the text.
Merge Complexity Parallel processing 0.0% JVET-M0170 Decision: Adopt JVET-M0170
reduction for merge mode (type 2, draft text “…
type2sharing” of Jan. 12)
Merge Complexity Pairwise Average 0.0% JVET-M0193 Decision: all the suggested
reduction Candidate adoptions are confirmed by
Reduction trackB.
Merge/AMVP Complexity Rounding before 0.0% JVET-M0281 Decision: Adopt JVET-M0281
reduction any MV pruning (subtest 4.1.5a)
AMVP Complexity MVP candidate 0.0% JVET-M0117 Decision: all the suggested
reduction list generation for adoptions are confirmed by
AMVP trackB.
HMVP Cleanup Reduce HMVP 0.0% JVET-M0436 Decision: all the suggested
number from 6 to adoptions are confirmed by
5 trackB.
HMVP Complexity HMVP and 0.0% JVET-M0300 Decision: all the suggested
reduction parallel processing adoptions are confirmed by
with tiles trackB.
HMVP Cleanup GBi weight is also 0.0% JVET-M0264 Decision: all the suggested
stored in HMVP adoptions are confirmed by
trackB.
HMVP Simplification HMVP candidate 0.0% JVET-M0126 Decision: Adopt JVET-M0126
pruning version 4.1.2.4 (text is available,
but needs to be reduced reflect
that only this aspect is changed.
BDOF Complexity Integer positions 0.1% JVET-M0487 Decision: Adopt JVET-M0487
reduction in extended region (solution 9.1.1.b)
BDOF Fix Generalization of 0.0% JVET-M0063 Decision (BF): Adopt JVET-
BDOF bit-depth M0063.
MMVD Coding efficiency MMVD w/o -0.1% JVET-M0255 Adopt the approach of not
(SCC) Fractional signalling the triangular
Distances for SCC prediction mode flag in cases
where the combination is not
allowed (MMVD, CIIP) –
various contributions on that,
gives 0.07%.
MMVD Cleanup Harmonize MV 0.0% JVET-M0068 Decision: all the suggested
scaling adoptions are confirmed by
trackB.
MMVD Fixes/cleanup M0068+Forbid 0.0% JVET-M0171 Decision: all the suggested
4*4 bi + align SW adoptions are confirmed by
with WD trackB.
MVD Coding efficiency Symmetrical -0.3% JVET-M0444 Decision: all the suggested
MVD coding for adoptions are confirmed by
L0 to L1 trackB.
WP fixes/cleanup Disable GBI JVET-M0111 Decision: all the suggested
signalling when adoptions are confirmed by
WP is enabled trackB.
MV cleanup Clip MVs to 18 0.0% JVET-M0479 Decision: all the suggested
bits adoptions are confirmed by
Page: 329 Date Saved: 2019-03-172019-03-14

trackB.
MV Complexity TMVP Storage 0.0% JVET-M0512 Decision: Adopt JVET-M0512
reduction Reduction second aspect as described in
notes
MV Complexity Sub-block MV 0.0% JVET-M0192 Decision: all the suggested
reduction derivation for adoptions are confirmed by
chroma trackB.
DMVR Coding efficiency DMVR -1.1% JVET-M0147 Decision: Adopt JVET-M0147
with SAD cost function, and
without the MVD based early
termination check.
Triangular Simplification -0.1% JVET-M0118 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% JVET-M0328 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% JVET-M0883 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 0.1% JVET-M0905 Decision (cleanup/consistency):
to avoid JVET-M0888 Adopt inferred QT split to avoid
32x128/128x32 JVET-M0446 32x128/128x32 partitions at
partitions at picture boundaries (0.06%
picture boundaries penalty in RA configuration).
Cleanup Split-first JVET-M0421 Decision: adopt
signalling for
partitioning
High-level
syntax
Picture Simplification RPL-based JVET-M0128 Decision: Adopt with
referencing reference picture modifications as described in
management notes
JVET-M0101 Replace IRAP_NUT with 3 new
NAL unit types:
IDR_W_RADL, IDR_N_LP,
CRA_NUT
JVET-M0101 Add external means flag
HandleCraAsCvsStartFlag
JVET-M0101 Add a NUT value for STSA and
AUD
JVET-M0101 Add
sps_max_sub_layers_minus1
Page: 330 Date Saved: 2019-03-172019-03-14

syntax element to SPS, and
decoding process in 8.1.1, 8.1.2
and 8.1.3 of JVET-M0101
JVET-M0101 Add profile_tier_level( ) syntax
structure which includes sub
layer level idc
JVET-M0101 Add
general_non_packed_constraint_
flag with semantics as in JVET-
M0101
JVET-M0101 Add the temporal scalability
sub-bitstream extraction process
in JVET-M0101
JVET-M0415 Change the
sps_ref_wraparound_offset to
sps_ref_wraparound_offset_min
us1 and changing the units to be
MinCbSizeY, subject to review
by the 360° BoG
JVET-M0451 Add 7 new constraint flags
corresponding to VVC WD 3
tools as described in JVET-
M0451
JVET-M0128 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 JVET-M0853 Decision: Adopted, with
constraints as in notes
JVET-M0132 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 JVET-M0160 Decision: Adopted (confirmed
loop_filter_across Thursday morning plenary).
_tile_group_enabl
ed_flag to the PPS
Software & CTC
Intra prediction Fix Ticket #132: JVET-M0002 Decision (SW): A software fix
Mismatch between was needed for #132.
spec and software
in the order of
syntax elements
Motion search Coding efficiency Hash-based 0.0% 0.0% JVET-M0253 Decision (SW): Adopt JVET-
(SCC) Motion Search for M0253
SCC
Subblock merge Fix Mismatch between 0.0% 0.0% JVET-M0409 Decision (SW/BF): Adopt
Page: 331 Date Saved: 2019-03-172019-03-14

text specification JVET-M0409 (align software
and reference with text)
software on
ATMVP candidate
derivation when
CPR is enabled
MV Fix Clean-up on MV 0.0% 0.0% JVET-M0265 Decision (BF/consistency):
Rounding Adopt rounding away from zero
for MV averages.
MMVD Coding efficiency MMVD -0.1% JVET-M0823 Decision (SW): Adopt JVET-
improvement M0823, also CTC
PCM Coding SAO/ALF 0.0% 0.0% JVET-M0277 Decision (BF/SW): Disable
efficiency/fixes 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 0.0% 0.0% JVET-M0428 Decision (SW): Adopt JVET-
optimization for M0428, not for CTC (-0.6% -
RDO 0.7%)
Tiles Encoder motion JVET-M0445 Decision (SW): Adopted
constraints for
MCTSs
AMVR Affine motion -0.1% JVET-M0247 Decision: all the suggested
estimation for adoptions are confirmed by
affine trackB.
AMVR+C94
Affine merge Increasing the -0.1% JVET-M0839 Decision: all the suggested
amount of RD adoptions are confirmed by
checking for affine trackB.
merge mode
coding
Analysis Functionality Enhancement of JVET-M0864 Decision (SW): Adopt JVET-
the tool to measure M0864 memory bandwidth
the memory analysis method.
bandwidth in
VTM
Functionality VTM transcoding JVET-M0055 Decision (SW): adopt, usage
capabilities should be documented in VTM
SW package
Quantization Functionality Clean-up of JVET-M0091 Decision (SW): Adopt
perceptually
optimized QP
adaptation
Quantization Fix (CTC) Rebalance luma- -1.0% JVET-M0090 Decision (CTC): Adopt
vs.-chroma QP
setting
Rate control Functionality Bug fix for rate JVET-M0511 Decision (SW): Adopt
control
Functionality Quality JVET-M0600 Decision (SW): Adopt
dependency factor
based rate control
JVET-M0452 Adopt Hemisphere CMP and
Hemisphere EAC projection
formats (from JVET-M0452)
JVET-M0368 Modify chroma sample location
in blending process for PHEC
(from JVET-M0368) – basically
a bug fix
Overall (CTC) ex -2.4% -6.2%
Class F & SCC
Page: 332 Date Saved: 2019-03-172019-03-14

11 Project planning
11.1 Core experiment planning
…qq
11.2 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.
11.3 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.
11.4 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 were available
late, and some changes in the experimental setup (particularly in CE4) were not 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 tha 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.
Page: 333 Date Saved: 2019-03-172019-03-14

 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; the method for members to obtain
the credentials is TBA on the reflector).
 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.
 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 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 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 participate 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.
Page: 334 Date Saved: 2019-03-172019-03-14

 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). [Search/remove obsolete references to BMS.]
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 should not be considered for adoption.
Plans for the CEs to be conducted were established Thursday 18 January (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 will be available to all members.
Page: 335 Date Saved: 2019-03-172019-03-14

11.5 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.
12 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, N
G. J. Sullivan (co-chairs)
(jvet@lists.rwth-aachen.de)
 Coordinate overall JVET interim efforts.
 Supervise CE and AHG studies.
 Report on project status to JVET reflector.
 Provide a report to next meeting on project
coordination status.
Draft text and test model algorithm description B. Bross, J. Chen (co- N
editing (AHG2) chairs), J. Boyce,
S. Kim, S. Liu, Y. Ye
(vice-chairs)
 Produce and finalize JVET-M1001 VVC text
specification draft 4.
 Produce and finalize JVET-M1002 VVC Test Model
4 (VTM 4) Algorithm and Encoder Description.
 Gather and address comments for refinement of
these documents.
 Coordinate with test model software development
AhG to address issues relating to mismatches
between software and text.
Page: 336 Date Saved: 2019-03-172019-03-14

Test model software development (AHG3) F. Bossen, X. Li, N
A. Norkin, K. Sühring
(co-chairs)
 Coordinate development of test model (VTM)
software and associated configuration files.
 Produce documentation of software usage for
distribution with the software.
 Discuss and make recommendations on the software
development process.
 Propose improvements to the guideline document for
developments of the test model software.
 Perform tests of VTM 4 behaviour relative to HEVC
and VTM 3 using the VTM common test conditions
and the multi-resolution streaming test conditions
described in JVET-M0466.
 Coordinate with AHG on Draft text and test model
algorithm description editing (AHG2) to identify any
mismatches between software and text, and make
further updates and cleanups to the software as
appropriate.
 Coordinate with AHG6 for integration with 360lib
software.
Test material and visual assessment (AHG4) T. Suzuki (chair), N

V. Baroncini,
R. Chernyak,
 Maintain the video sequence test material database P. Hanhart, A. Norkin,
for development of the VVC standard. J. Ye (vice-chairs)
 Identify and recommend appropriate test materials

for use in the development of the VVC standard.
 Identify missing types of video material, solicit
contributions, collect, and make available a variety
of video sequence test material.
 Evaluate new test sequences, particularly including
the material recently submitted by the Blender
Foundation / Blender Animation Studio and Twitch.
 Propose a new structure for the test sequence
repository.
 Facilitate availability of viewing equipment and
facilities arrangements for the next meeting and pre-
meeting testing as feasible.
Page: 337 Date Saved: 2019-03-172019-03-14

Memory bandwidth consumption of coding tools R. Hashimoto (chair), N
(AHG5) T. Ikai, X. Li, D. Luo,
H. Yang, M. Zhou (vice-
chairs)
 Develop improved software tools for measuring both
average and worst case of memory bandwidth, and
provide information for usage of these tools.
 Study cache configurations for measuring decoder
memory bandwidth consumption.
 Identify coding tools in CEs and VTM with
significant memory bandwidth impact.
 Study the impact of memory bandwidth on specific
application cases.
360° video conversion software development (AHG6) Y. He, K. Choi (co- N

chairs)
 Prepare and deliver the 360Lib-9.0 software version
and common test condition configuration files
according to JVET-M1012.
 Generate CTC (PHEC) anchors and PERP results for
VTM according to JVET-M1012, and finalize the
reporting template for the common test conditions.
 Produce documentation of software usage for
distribution with the software.
Coding of HDR/WCG material (AHG7) A. Segall (chair), N

E. François, W. Husak,
D. Rusanovskyy (vice-
 Study and evaluate available HDR/WCG test chairs)
content.
 Study objective metrics for quality assessment of
HDR/WCG material, including investigation of the
correlation between subjective and objective results
of the CfP responses.
 Compare the performance of the VTM and HM for
HDR/WCG content.
 Prepare for expert viewing of HDR content at the
14th JVET meeting if feasible.
 Coordinate implementation of HDR anchor aspects
in the test model software with AHG3.
 Study additional aspects of coding HDR/WCG
content.
Page: 338 Date Saved: 2019-03-172019-03-14

360° video coding tools and test conditions (AHG8) J. Boyce (chair), N
K. Choi, P. Hanhart, J.-
L. Lin (vice-chairs)
 Study the effect on compression and subjective
quality of different projections formats, resolutions,
and packing layouts.
 Discuss refinements of common test conditions, test
sequences, and evaluation criteria.
 Solicit additional test sequences, and evaluate
suitability of test sequences on head-mounted
displays and normal 2D displays.
 Study coding tools dedicated to 360° video, their
impact on compression, and implications to the core
codec design.
 Study the effect of viewport resolution, field of view,
and viewport speed/direction on visual comfort.
 Study complexity of GPU rendering of projection
formats
 Study syntax for signalling of projection formats,
cubeface layouts, spherical rotations
Neural networks in video coding (AHG9) S. Liu (chair), B. Choi, N

K. Kawamura, Y. Li,
L. Wang, P. Wu,
 Investigate the benefit of using neural networks in H. Yang (vice-chairs)
video compression such as CNN loop filter, intra
prediction, re-sampling in adaptive resolution
coding, and encoder side partition mode decisions.
 Investigate the complexity impact of using neural
networks in video compression.
 Investigate the complexity measurement of neural
network coding tools.
 Investigate the impact of training materials on the
performance of neural network coding tools.
 Investigate the impact of the training process on
performance and complexity.
Page: 339 Date Saved: 2019-03-172019-03-14

Encoding algorithm optimization (AHG10) A. Duenas, A. Tourapis N
(co-chairs), C. Helmrich,
S. Ikonin, A. Norkin,
 Study the impact of using techniques such as GOP R. Sjöberg, T. Toma
structures and perceptually optimized adaptive (vice-chairs)
quantization for encoder optimization.
 Study the impact of adaptive quantization on
individual tools in the test model.
 Study the quantization adaptation tool in the test
model.
 Investigate the feasibility of adding a CTC test
category in which adaptive quantization is turned on.
 Study quality metrics for measuring subjective
quality using e.g. the CfP response MOS scores.
 Investigate other methods of improving objective
and/or subjective quality, including adaptive coding
structures, adaptive quantization without signalling,
and multi-pass encoding.
 Study methods of rate control and their impact on
performance, subjective and objective quality.
Screen content coding (AHG11) S. Liu (chair), J. Boyce, N

A. Filippov, Y.-C. Sun,
J. Xu, M. Zhou (vice-
 Investigate coding tools targeted at screen content in chairs)
terms of compression benefit and implementation
complexity.
 Identify test materials, discuss testing conditions for
screen content coding, and propose associated
updated common test conditions.
 Study the impact of loop filters on screen content
coding
Page: 340 Date Saved: 2019-03-172019-03-14

High-level parallelism and coded picture regions S. Deshpande (chair), N
(AHG12) M. M. Hannuksela,
R. Sjöberg, R. Skupin,
W. Wan, Y.-K. Wang
 Study wavefront processing including the S. Wenger (vice-chairs)
relationship with tiles and low delay characteristics.
 Study flexible loop filter control and tile size
restriction, including identifying implications on
coding tools and implementation.
 Study flexible tile partitioning (e.g. more flexible
than HEVC and tile boundaries not spanning a full
picture).
 Study support of independently coded picture
regions, including easy rewriting of such regions into
a conforming sub-bitstream.
 Prepare software and configurations for the test
model to facilitate parallel processing tests.
 Study the coding efficiency impact of parallel
processing and coded picture regions.
Tool reporting procedure (AHG13) W.-J. Chien, J. Boyce N

(co-chairs), Y.-W. Chen,
R. Chernyak, K. Choi,
 Prepare output document JVET-M1005, which R. Hashimoto, Y.-W.
describes the methodology of tool-off testing and a Huang, H. Jang, S. Liu,
list of tools to be tested by identified testers. D. Luo (vice-chairs)
 Provide configurations files, bitstreams, and results

of tool-on/tool-off testing.
 Use the tool usage counts and memory bandwidth
usage to study the decoder complexity of features in
on/off testing.
 Prepare a report with results of the tests.
Page: 341 Date Saved: 2019-03-172019-03-14

Progressive intra refresh (AHG14) J.-M. Thiesse (chair), N
A. Duenas, K. Kazui,
R. Sjöberg, A. Tourapis
 Define relevant test conditions for the study of (vice-chairs)
progressive intra refresh for random access without
intra frames
 Update the implementation of encoder-only intra
refresh in the VTM model in the AHG14 fork of the
software repository.
 Evaluate different ways to produce intra refresh
within VVC and characterize their coding efficiency
impact, subjective quality, and delay characteristics,
including encoder-only approaches and normative
approaches
 Consider the use of constrained intra prediction and
tile-based approaches
 Study recovery point handling, including practical
implementation issues and perfect-versus-
approximate decoded picture recovery.
 Consider the potential need for starting a coded
video sequence without an intra picture.
Bitstream decoding properties signalling (AHG15) J. Boyce (chair), N

J. Chen, S. Deshpande,
M. Karczewicz,
 Study syntax alternatives for interoperability point A. Tourapis, Y.-K.
signalling Wang, S. Wenger (vice-
chairs)
 Study selection of constraint flags to be included in
the VTM and their impact on syntax, semantics, and
decoding process
Implementation studies (AHG16) M. Zhou (chair), J. An, N

E. Chai, K. Choi,
S. Ethuraman, T. Hsieh,
 Study draft and proposed coding tools to identify X. Xiu (vice-chairs)
implementation issues relating to decoder pipelines,
decoder throughput, and other aspects of
implementation difficulty.
 Solicit hardware analysis of complex tools.
 Particularly consider intra reconstruction throughput
for small blocks.
 Provide feedback on potential solutions to address
identified issues.
Page: 342 Date Saved: 2019-03-172019-03-14

High-level syntax (AHG17) R. Sjöberg (chair), N
S. Deshpande,
M. M. Hannuksela,
 Study NAL unit header, sequence parameter set, R. Skupin, Y.-K. Wang,
picture parameter set, adaptation parameter set, and S. Wenger, H. Yu (vice-
tile group header syntax designs chairs)
 Study the proposed picture header designs and

alternatives
 Study reference picture buffering and list
construction
 Study random access signalling and random access
approaches, including approaches with reference
pictures provided by external means
 Assist in software development and text drafting for
the high-level syntax in the VVC design.
Quantization control (AHG18) R. Chernyak (chair), N

E. François,
C. Helmrich, A. Segall
 Identify methods for quantization step size control (vice-chairs)
for luma and chroma, including spatially and
frequency-adaptive approaches
 Develop methods for evaluating quantization step
size control operation
 Study the impact of MTS transforms on quantization
matrices and the need for default matrices
 Study the interaction between in-loop “reshaping”
and quantization step size control
 Develop testing conditions for evaluating QP
signalling improvements including rate control and
perceptual optimization strategies as appropriate
 Evaluate the performance of the current VVC QP
design using the two adaptive quantization control
techniques currently available in the VTM
Page: 343 Date Saved: 2019-03-172019-03-14

Layered coding and resolution adaptivity (AHG19) S. Wenger and A. Segall N
(co-chairs),
M. M. Hannuksela,
 Study adaptive-resolution coding approaches for Hendry, S. McCarthy,
real-time communication, adaptive streaming, and Y.-C. Sun (vice-chairs)
360-degree viewport-dependent streaming, including
filters for resampling, reference picture management,
and related scope and signalling
 Study approaches for temporal scalability to avoid
temporal judder when temporal scalability sub-
bitstream extraction is used for achieving lower
frame rate, and consider whether this should have a
normative impact.
 Identify related test conditions, test sequences, and
evaluation techniques (including subjective
assessment techniques)
 Study potential approaches for support of layered
coding scalability including spatial, temporal,
quality, and view scalability
13 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.
JVET-M1000 Meeting Report of the 13th JVET Meeting [G. J. Sullivan, J.-R. Ohm] (2019-
03-08, near next meeting)
Initial versions of the meeting notes (d0 … d8) were made available on a daily basis during the meeting.
JVET-M1001 Versatile Video Coding (Draft 4) [B. Bross, J. Chen, S. Liu] [WG 11 N 18274]
(2019-03-08)
(Initial version planned to be made available by 2019-02-01.)
See the list of elements under section Error: Reference source not found 10.7, as agreed by the Wed. 18
October plenary.
JVET-M1002 Algorithm description for Versatile Video Coding and Test Model 4 (VTM 4)
[J. Chen, Y. Ye, S. Kim] [WG 11 N 18725] (2019-03-08)
(Initial version planned to be made available by 2019-02-15.)
See the list of elements under section Error: Reference source not found 10.7, as agreed by the Wed. 18
October plenary.
Page: 344 Date Saved: 2019-03-172019-03-14

Remains valid – not updated: JVET-K1003 Guidelines for VVC reference software
development [K. Sühring] (2018-07-31)
New version?
JVET-M1004 Algorithm descriptions of projection format conversion and video quality

metrics in 360Lib (Version 9) [Y. Ye, J. Boyce] (2019-02-15)
Remains valid – not updated: JVET-L1005 Methodology and reporting template for coding
tool testing [W.-J. Chien and J. Boyce] (2018-10-26)
JVET-M1006 Methodology and reporting template for neural network coding tool testing
[Y. Li, S. Liu, K. Kawamura] (2019-02-01)
This output was produced to capture aspects specific to enable study of neural network techniques.
JVET-M1010 JVET common test conditions and software reference configurations for
SDR video [F. Bossen, J. Boyce, X. Li, V. Seregin, K. Sühring] (2019-02-01)
Update regarding CPR and hash search, used only for class F.
Enable inter MTS for lower-resoluitons? Perhaps in a CE, but not in CTC.
Remains valid – not updated: JVET-L1011 JVET common test conditions and evaluation
procedures for HDR/WCG video [A. Segall, E. François, S. Iwamura,
D. Rusanovskyy] (2018-10-26)
Remains valid – not updated: JVET-L1012 JVET common test conditions and evaluation
procedures for 360° video [P. Hanhart, J. Boyce, K. Choi, J.-L. Lin] (2018-
10-26)
JVET-M1021 Description of Core Experiment 1 (CE 1): Post-prediction and post-

reconstruction filtering [J. Ström, S. Ikonen, V. Seregin]
JVET-M1022 Description of Core Experiment 2 (CE2): Subblock motion compensation

[C.-C. Chen, Y. He, H. Liu]
JVET-M1023 Description of Core Experiment 3 (CE3): Intra prediction and mode coding
[G. Van der Auwera, L. Li, A. Filippov]
JVET-M1024 Description of Core Experiment 4 (CE4): Inter prediction and motion vector
coding [H. Yang, G. Li, K. Zhang]
Page: 345 Date Saved: 2019-03-172019-03-14

JVET-M1025 Description of Core Experiment 5 (CE5): Adaptive loop filtering [C.-Y.
Chen, V. Seregin]
JVET-M1026 Description of Core Experiment 6 (CE6): Transforms and transform

signalling [X. Zhao, H. E. Egilmez]
JVET-M1027 Description of Core Experiment 7 (CE 7): Quantization and coefficient

coding [H. Schwarz, M. Coban, C. Auyeung]
Coordination between CE7 and CE8 is desired for TS coefficient coding evaluation.
JVET-M1028 Description of Core Experiment 8 (CE8): Screen Content Coding Tools

[X. Xu, Y.-H. Chao, Y.-C. Sun, J. Xu]
Transform skip coefficient coding should be tested in CE8, and should be tested with low QP as well as
with CTC.
Coordination between CE7 and CE8 is desired for TS coefficient coding evaluation.
JVET-M1029 Description of Core Experiment 9 (CE9): Decoder Motion Vector Derivation

[S. Esenlik, X. Xiu]
JVET-M1030 Description of Core Experiment 10 (CE10): Combined intra/inter prediction

[C.-W. Hsu, M. Winken]
JVET-M1031 Description of Core Experiment 11 (CE11): Deblocking [A. Norkin,

A. M. Kotra]
JVET-M1032 Description of Core Experiment 12 (CE12): Tile set boundary motion

compensation handling [Hendry, R. Skupin, W. Wan]
JVET-M1033 Description of Core Experiment 13 (CE13): Neural-network based loop

filtering [Y. Li, S. Liu, K. Kawamura]
Potentially obsolete notes: New CEs which may fill gaps in above numbering:
Adaptive loop filter [V. Seregin, …]
Post prediction/reconstruction filtering (include BF, HF, LIC, DIF) [J. Ström, S. Ikonin, …]
Neural network based loop filters [Y. Li, …]
Page: 346 Date Saved: 2019-03-172019-03-14

14 Future meeting plans, expressions of thanks, and closing of the
meeting
Future meeting plans were established according to the following guidelines:
 Meeting under ITU-T SG 16 auspices when it meets (starting meetings on the Tuesday of the first
week and closing it on the Wednesday of the second week of the SG 16 meeting – a total of 9
meeting days), and
 Otherwise meeting under ISO/IEC JTC 1/SC 29/WG 11 auspices when it meets (starting
meetings on the Wednesday prior to such meetings and closing it at lunchtime on the last day of
the WG 11 meeting – a total of 9.5 meeting days).
In cases where an exceptionally high workload is expected for a meeting, an earlier starting date may be
defined.
Some specific future meeting plans (to be confirmed) were established as follows:
 Tue. 19 – Wed. 27 March 2019, 14th meeting under ITU-T auspices in Geneva, CH.
 Wed. 3 – Fri. 12 July 2019, 15th meeting under WG 11 auspices in Gothenburg, SE.
 Tue. 1 – Wed. 9 October 2019, 16th meeting under ITU-T auspices in Geneva, CH.
 Wed. 8 – Fri. 17 January 2020, 17th meeting under WG 11 auspices in Brussels, BE.
The agreed document deadline for the 14th JVET meeting was planned to be Tuesday 12 March 2019.
Plans for scheduling of agenda items within that meeting remained TBA.
WG 11, the local hosting organization Ecole Mohammadia d’Ingénieurs (EMI) – Mohammed V
University, Rabat, Morocco, and Abdellatif Benjelloun Touimi were thanked for the excellent hosting and
organization of the 13th meeting of the JVET.
GB Tech and Samsung were thanked for providing viewing equipment used during the 13th JVET
meeting. Vittorio Baroncini was thanked for designing and coordinating the subjective test efforts related
to CE11. The experts who helped in preparing and conducting the test, or participated in the role as test
subjects, were also thanked.
Christian Tulvan was thanked for his continuous support and maintenance with regard to the JVET
document repository.
The 13th JVET meeting was closed at approximately 1318 hours on Friday 18 January 2019.
Page: 347 Date Saved: 2019-03-172019-03-14

Annex A to JVET report:
List of documents
JVET-VC MPEG
Created First upload Last upload Title Authors
number number
2018-12-28 2019-01-09 2019-01-09 JVET AHG report: Project management
JVET-M0001 m45352 J.-R. Ohm, G. . J. . Sullivan
17:24:14 00:06:28 00:06:28 (AHG1)
JVET AHG report: Draft text and test B. . Bross, J. . Chen, J.
2019-01-01 2019-01-09 2019-01-10
JVET-M0002 m45400 model algorithm description editing . Boyce, S. . Kim, S. . Liu, Y.
03:28:59 09:23:09 10:58:16
(AHG2) . Ye
2019-01-01 2019-01-09 2019-01-12 JVET AHG report: Test model software F. . Bossen, X. . Li, K.
JVET-M0003 m45401
03:36:29 09:47:41 16:17:20 development (AHG3) . Sühring
T. . Suzuki, V. . Baroncini, R.
2018-12-28 2019-01-07 2019-01-07 JVET AHG report: Test material and visual
JVET-M0004 m45328 . Chernyak, P. . Hanhart, A.
06:58:26 15:13:49 15:13:49 assessment (AHG4)
. Norkin, J. . Ye
R. . Hashimoto, T. . Ikai, X.
2019-01-02 2019-01-09 2019-01-09 JVET AHG report: Memory bandwidth
JVET-M0005 m45684 . Li, D. . Luo, H. . Yang, M.
19:20:11 09:02:58 09:19:06 consumption of coding tools (AHG5)
. Zhou
2019-01-03 2019-01-07 2019-01-07 JVET AHG Report: 360 video conversion
JVET-M0006 m45742 Y. . He, K. . Choi
01:00:15 02:12:34 02:12:34 software development (AHG6)
2019-01-08 2019-01-09 2019-01-10 JVET AHG report: Coding of HDR/WCG A. . Segall, E. . François, D.
JVET-M0007 m46280
19:10:24 07:47:34 19:11:28 material (AHG7) . Rusanovskyy
2019-01-08 2019-01-08 2019-01-08 JVET AHG report: 360Â° video coding J. . Boyce, K. . Choi, P.
JVET-M0008 m46264
14:58:16 23:16:33 23:16:33 tools and test conditions (AHG8) . Hanhart, J.-L. Lin
S. . Liu, B. . Choi, K.
2019-01-07 2019-01-07 2019-01-07 JVET AHG report: Neural Networks in
JVET-M0009 m46196 . Kawamura, Y. . Li, L.
22:44:22 22:46:23 22:46:23 Video Coding (AHG9)
. Wang, P. . Wu, H. . Yang
A. . M. . Tourapis, A.
2019-01-09 2019-01-09 2019-01-09 JVET AHG report: Encoding algorithm . Duenas, C. . Helmrich, S.
JVET-M0010 m46297
08:31:12 08:31:36 08:31:36 optimizations (AHG10) . Ikonin, A. . Norkin, R.
. Sjöberg
S. . Liu, J. . Boyce, A.
2019-01-05 2019-01-07 2019-01-07 JVET AHG report: Screen Content Coding
JVET-M0011 m45915 . Filippov, Y.-C. Sun, J. Xu,
09:37:49 22:16:08 22:16:08 (AHG11)
M. Zhou
T. Ikai, M. M. Hannuksela, R.
2019-01-05 2019-01-09 2019-01-09 JVET AHG report: High-level parallelism
JVET-M0012 m45897 Sjöberg, R. Skupin, W. Wan,
02:37:00 08:24:15 12:59:56 and coded picture regions (AHG12)
Y.-K. Wang, S. Wenger
W.-J. Chien, J. Boyce, R.
2019-01-08 2019-01-08 2019-01-08 JVET AHG report: Tool reporting
JVET-M0013 m46281 Chernyak, R. Hashimoto, Y.-
20:39:28 20:47:52 20:47:52 procedure (AHG13)
W. Huang, S. Liu, D. Luo
2019-01-08 2019-01-08 2019-01-08 JVET AHG report: Progressive intra refresh J.-M. Thiesse, A. Duenas, K.
JVET-M0014 m46269
16:13:04 23:36:53 23:36:53 (AHG14) Kazui, A. Tourapis
J. Boyce, J. Chen, S.
2019-01-08 2019-01-13 2019-01-13 JVET AHG report: Bitstream decoding Deshpande, M. Karczewicz,
JVET-M0015 m46265
15:00:58 15:33:27 15:33:27 properties signalling (AHG15) A. Tourapis, Y.-K. Wang, S.
Wenger
M. Zhou, J. An, E. Chai, K.
2019-01-02 2019-01-07 2019-01-31 JVET AHG report: Implementation studies
JVET-M0016 m45673 Choi, S. Sethuraman, T.
18:37:14 03:02:57 05:35:36 (AHG16)
Hsieh, X. Xiu
R. Sjöberg, S. Deshpande, M.
2019-01-04 2019-01-09 2019-01-09 JVET AHG report: High-level syntax
JVET-M0017 m45872 M. Hannuksela, R. Skupin,
13:58:52 12:42:32 12:42:32 (AHG17)
Y.-K. Wang, S. Wenger
2019-01-04 2019-01-07 2019-01-10 J. Ma, F. Le Léannec, M. W.
JVET-M0021 m45873 CE1: Summary report on partitioning
14:00:45 07:17:44 09:11:34 Park
2019-01-04 2019-01-09 2019-01-09 CE2: Summary report on sub-block based Y. He, C.-Y. Chen, C.-C.
JVET-M0022 m45863
07:30:26 00:31:59 15:41:29 motion prediction Chen
2018-12-28 2019-01-06 2019-01-09 CE3: Summary report on intra prediction G. Van der Auwera, J. Heo,
JVET-M0023 m45355
18:55:18 04:12:23 15:38:42 and mode coding A. Filippov
2019-01-05 2019-01-08 2019-01-10 CE4: Summary report on inter prediction
JVET-M0024 m45900 H. Yang, S. Liu, K. Zhang
03:06:52 04:33:43 10:50:25 and motion vector coding
2019-01-04 2019-01-09 2019-01-10 CE5: Summary report on the Arithmetic
JVET-M0025 m45878 H. Kirchhoffer, A. Said
15:48:58 15:53:12 16:07:15 Coding Engine
2019-01-03 2019-01-09 2019-01-10 CE6: Summary Report on Transforms and
JVET-M0026 m45809 A. Said, X. Zhao
09:21:03 01:39:16 19:01:12 Transform Signalling
Page: 348 Date Saved: 2019-03-172019-03-14

2018-12-20 2019-01-06 2019-01-09 CE7: Summary report on quantization and H. Schwarz, M. Coban, C.
JVET-M0027 m45293
19:11:10 21:17:37 08:39:35 coefficient coding Auyeng
2019-01-03 2019-01-09 2019-01-10 CE8: Summary Report on Screen Content X. Xu, Y.-C. Chao, Y.-C. Sun,
JVET-M0028 m45782
04:31:32 11:53:45 16:53:54 Coding Tools J. Xu
2019-01-07 2019-01-09 2019-01-10 CE9: Summary report on decoder side
JVET-M0029 m46021 X. Xiu, S. Esenlik
11:23:36 12:28:58 17:03:33 motion vector derivation
2019-01-03 2019-01-09 2019-01-12 CE10: Summary report on combined and
JVET-M0030 m45822 C.-W. Hsu, M. Winken
16:45:45 08:52:21 09:37:57 multi-hypothesis prediction
2019-01-09 2019-01-10 2019-01-17
JVET-M0031 m46292 CE11: Summary Report on Deblocking A. Norkin, A. M. Kotra
02:47:37 23:46:27 18:10:08
2019-01-08 2019-01-08 2019-01-10 CE12: Summary report on mapping
JVET-M0032 m46249 E. Francois, P. Yin
10:50:26 10:50:53 10:37:03 functions
2019-01-06 2019-01-08 2019-01-09 CE13: Summary report on coding tools for P. Hanhart, J.-L. Lin, C.
JVET-M0033 m45972
20:25:36 18:57:24 13:36:28 360Â° omnidirectional video Pujara
2018-12-18
JVET-M0041 m45269 Withdrawn
09:43:00
J. Rasch, A. Henkel, J. Pfaff,
2018-12-18 2018-12-21 2019-01-17 CE10: Uniform Directional Diffusion
JVET-M0042 m45270 H. Schwarz, D. Marpe, T.
16:59:34 12:22:28 12:26:00 Filters For Video Coding
Wiegand (HHI)
J. Pfaff, B. Stallenberger, M.
2018-12-19 2019-01-02 2019-01-09 CE3: Affine linear weighted intra Schäfer, P. Merkle, P. Helle,
JVET-M0043 m45292
12:00:55 14:34:58 15:38:58 prediction (test 1.2.1, test 1.2.2) R. Rischke, H. Schwarz, D.
Marpe, T. Wiegand (HHI)
2018-12-21 2018-12-21 2018-12-21 Non-CE3: Alternative LM Chroma S. Keating, K. Sharman
JVET-M0044 m45296
17:09:27 17:16:57 17:16:57 Implementation (Sony)
2018-12-21 2018-12-21 2019-01-09 S. Keating, K. Sharman
JVET-M0045 m45297 Non-CE3: PDPC Restriction
17:11:18 17:20:04 10:46:26 (Sony)
2018-12-23 2018-12-24 2019-01-14
JVET-M0046 m45299 CE6-related: A study of primary transforms M. Zhou, Y. Hu (Broadcom)
18:19:35 00:03:51 07:03:58
Non-CE3: Intra Angular Prediction and
2018-12-24 2018-12-29 2018-12-29 D. Jiang, J. Lin, F. Zeng, C.
JVET-M0047 m45300 Modified PDPC Based on Two Reference
04:25:53 11:19:12 11:19:12 Fang (Dahua)
Lines
2018-12-24 2018-12-29 2018-12-29 F. Zeng, J. Lin, D. Jiang, C.
JVET-M0048 m45301 Non-CE3: Modified Chroma Derived Mode
04:35:11 11:19:57 11:19:57 Fang (Dahua)
2018-12-26 2018-12-28 2019-01-08 CE2-related: A restriction on memory
JVET-M0049 m45303 M. Zhou (Broadcom)
18:08:10 22:37:42 17:17:20 bandwidth consumption of affine mode
Y.-C. Sun, J. Lou (Alibaba),
2018-12-27 2019-01-02 2019-01-09 Y.-H. Chao, H. Wang, V.
JVET-M0050 m45304 CE8: Palette Mode in HEVC (test 8.2.1)
00:36:07 06:45:20 00:32:15 Seregin, M. Karczewicz
(Qualcomm)
2018-12-27 2019-01-02 2019-01-09 CE8: Palette Mode and Intra Mode
JVET-M0051 m45305 Y.-C. Sun, J. Lou (Alibaba)
00:36:23 06:47:02 00:43:45 Combination (test 8.2.2)
Y.-C. Sun, J. Lou (Alibaba),
Y.-H. Chao, H. Wang, V.
2018-12-27 2019-01-02 2019-01-09 CE8: Separate Palette Coding for Luma and
JVET-M0052 m45306 Seregin, M. Karczewicz
00:36:35 06:49:14 00:49:18 Chroma (test 8.2.5)
(Qualcomm), R. Chernyak, S.
Ikonin, J. Chen (Huawei)
2018-12-27 2018-12-30 2019-01-09 CE2: Size constrain for inherited affine H. Huang, W.-J. Chien, M.
JVET-M0053 m45307
05:39:32 05:18:21 21:05:32 motion prediction (test 2.4.7) Karczewicz (Qualcomm)
2018-12-27 2018-12-30 2019-01-02 CE2: Modified affine inheritance from H. Huang, W.-J Chien, M.
JVET-M0054 m45308
05:41:36 05:18:50 20:26:18 above CTU (test 2.4.6) Karczewicz (Qualcomm)
2018-12-27 2018-12-27 2019-01-17 AHG3: VTM transcoding capabilities for T. Hinz, A. Wieckowski
JVET-M0055 m45309
11:11:29 11:15:26 11:46:32 bit rate matching and debugging (HHI)
F. Henry, A. Mohsen
2018-12-27 2018-12-30 2019-01-10 CE8: BDPCM with LOCO-I and
JVET-M0056 m45310 (Orange), P. Philippe, G.
11:20:13 16:09:10 15:15:01 independently decodable areas (test 8.3.1a)
Clare (bcom)
CE8: BDPCM with horizontal/vertical
2018-12-27 2018-12-30 2019-01-10 F. Henry, M. Abdoli (Orange),
JVET-M0057 m45311 predictor and independently decodable
11:22:57 16:10:12 15:15:34 P. Philippe, G. Clare (bcom)
areas (test 8.3.1b)
2018-12-27 2018-12-30 2019-01-10 CE8: BDPCM with modified binarization F. Henry, M. Abdoli (Orange),
JVET-M0058 m45312
11:25:34 16:11:06 15:16:38 (test 8.3.2) G. Clare, P. Philippe (bcom)
2018-12-28 2018-12-28 2019-01-10
JVET-M0059 m45313 CE4: Non-scaling STMVP (Test 4.2.1) T. Zhou, T. Ikai (Sharp)
05:23:13 09:52:04 11:03:38
2018-12-28 2018-12-28 2018-12-28 CE4: Enhanced Merge with MVD (Test T. Hashimoto, E. Sasaki, T.
JVET-M0060 m45314
05:25:41 10:09:13 10:09:13 4.4.4) Ikai (Sharp)
JVET-M0061 m45315 2018-12-28 2018-12-28 2018-12-28 CE4: Combination of CE4.4.4.a and T. Hashimoto, E. Sasaki, T.
05:25:59 10:35:45 10:46:14 CE4.4.5.c (Test 4.4.4.e) Ikai (Sharp), J. Li, R.-L. Liao,
Page: 349 Date Saved: 2019-03-172019-03-14

C. S. Lim (Panasonic)
2018-12-28 2018-12-31 2018-12-31 CE9: An early termination of DMVR (Test
JVET-M0062 m45316 T. Chujoh, T. Ikai (Sharp)
05:26:19 04:04:22 04:04:22 9.2.5)
2018-12-28 2018-12-31 2019-01-12
JVET-M0063 m45317 Non-CE9: An improvement of BDOF T. Chujoh, T. Ikai (Sharp)
05:26:45 03:51:14 16:05:49
2018-12-28 2019-01-03 2019-01-03 Non-CE3: CCLM table reduction and bit Y. Yasugi, F. Bossen, E.
JVET-M0064 m45318
05:28:17 02:05:02 02:05:02 range control Sasaki (Sharp)
2018-12-28 2018-12-28 2019-01-16 Non-CE3: Intra chroma partitioning and
JVET-M0065 m45319 T. Zhou, T. Ikai (Sharp)
05:28:40 09:55:44 13:18:35 prediction restriction
2018-12-28 2018-12-28 2018-12-30
JVET-M0066 m45320 AHG12: Flexible Tile Partitioning Y. Yasugi, T. Ikai (Sharp)
05:28:56 09:44:30 11:23:54
Non-CE4: Weighted prediction with BDOF
2018-12-28 2019-01-02 2019-01-13 T. Hashimoto, T. Chujoh, T.
JVET-M0067 m45321 and bi-prediction with CU weights
05:29:29 10:41:57 18:52:05 Ikai, E. Sasaki (Sharp)
harmonization
2018-12-28 2018-12-28 2018-12-28
JVET-M0068 m45322 Non-CE4: MMVD scaling fix E. Sasaki, T. Ikai (Sharp)
05:29:55 08:15:24 08:15:24
2018-12-28 2018-12-28 2018-12-28 E. Sasaki, T. Chujoh, T. Ikai
JVET-M0069 m45323 Non-CE4: Syntax change of MMVD
05:30:12 08:16:37 08:16:37 (Sharp)
T. Ikai, S. Deshpande, T.
2018-12-28 2019-01-03 2019-01-03 AHG12: Wavefront processing in a tile
JVET-M0070 m45324 Chujoh, E. Sasaki, T. Aono
05:30:28 01:02:50 01:02:50 group
(Sharp)
2018-12-28 2018-12-28 2019-01-11 AHG12: Improved parallel processing Y. Fujimoto, M. Ikeda, T.
JVET-M0071 m45325
06:26:55 06:32:57 17:42:05 capability with WPP Suzuki (Sony)
2018-12-28 2018-12-28 2019-01-02 Non-CE6: On transform skip for lager T. Tsukuba, M. Ikeda, T.
JVET-M0072 m45326
06:51:12 07:06:19 09:49:16 block Suzuki (Sony)
2018-12-28 2018-12-28 2019-01-12 K. Kondo, M. Ikeda, T.
JVET-M0073 m45327 Non-CE9: On early termination for BDOF
06:52:35 09:17:21 10:10:48 Suzuki (Sony)
2018-12-28
08:44:21
2018-12-28 2019-01-02 2019-01-02 CE11: Extended Deblocking Filter (test K. Unno, K. Kawamura, S.
JVET-M0075 m45332
08:44:22 15:14:26 15:14:26 11.1.2) Naito (KDDI
2018-12-28 2019-01-02 2019-01-02 CE9: Block size restriction for DMVR (test K. Unno, K. Kawamura, S.
JVET-M0076 m45333
08:45:26 15:14:47 15:14:47 9.2.6) Naito (KDDI)
2018-12-28 2019-01-02 2019-01-12 CE9-related: Relaxation of block size K. Unno, K. Kawamura, S.
JVET-M0077 m45334
08:45:52 15:15:04 08:46:24 restriction for DMVR Naito (KDDI)
K. Unno, K. Kawamura, S.
2018-12-28 2019-01-02 2019-01-12 CE9-related: Combination of JVET-M0077
JVET-M0078 m45335 Naito (KDDI), T. Chujoh, T.
08:46:23 15:15:22 08:47:18 and CE9.2.5
Ikai (Sharp)
2018-12-28 2018-12-28 2019-01-04
JVET-M0079 m45336 CE6: MTS size restriction to 16 (test 3.7) P. Philippe (bcom Orange)
09:06:46 10:35:41 16:08:32
2018-12-28 2019-01-02 2019-01-04 CE6: MTS simplification with Transform
JVET-M0080 m45337 P. Philippe (bcom Orange)
09:13:08 18:17:44 16:16:09 Adjustment (TAF) (tests 1.5a-d)
2018-12-28 2018-12-28 2019-01-11 Non-CE4: Simplification of AMVP list Y. Kato, K. Abe, T. Toma
JVET-M0081 m45338
10:23:57 10:42:01 17:15:13 generation in AMVR (Panasonic)
2018-12-28 2018-12-28 2019-01-13 CE10-related: Simplification of Multi Y. Kato, K. Abe, T. Toma
JVET-M0082 m45339
10:28:42 10:45:41 16:12:09 hypothesis intra prediction (Panasonic)
2018-12-28 2018-12-28 2019-01-13
JVET-M0083 m45340 AHG10: Quantization matrices for MTS T. Toma, K. Abe (Panasonic)
11:05:29 11:19:35 13:01:18
K. Abe, T. Toma (Panasonic),
CE6: JVET-L0262: Replacing all DST-7 /
2018-12-28 2018-12-28 2019-01-06 M. Ikeda, T. Tsukuba (Sony),
JVET-M0084 m45341 DCT-8 by DST-4 / DCT-4 used in MTS
11:36:59 12:13:47 14:36:15 K. Naser, F. L. Leannec, E.
(test 6.1.1e)
Francois (Technicolor)
CE6-related: Fast algorithm for
2018-12-28 2019-01-02 2019-01-11 T. Toma, K. Abe (Panasonic),
JVET-M0085 m45342 DST-4/DCT-4 as alternative transforms for
11:40:33 06:43:19 11:45:32 M. Ikeda, T. Tsukuba (Sony)
MTS
2018-12-28 2018-12-29 2018-12-29
JVET-M0086 m45343 CE4: Non-sub-block ATMVP (test 2.5.4) K. Abe, T. Toma (Panasonic)
11:47:05 09:44:57 09:44:57
2018-12-28 2018-12-29 2019-01-04 CE10: Low pipeline latency LIC (test K. Abe, T. Toma, J. Li, C.-W.
JVET-M0087 m45344
11:49:06 10:17:13 09:12:06 10.5.2) Kuo, V. Drugeon (Panasonic)
2018-12-28 2019-01-02 2019-01-13 CE10-related: LIC restriction for pipeline K. Abe, T. Toma, J. Li, C.-W.
JVET-M0088 m45345
11:50:52 12:28:09 12:42:46 structure Kuo, V. Drugeon (Panasonic)
2018-12-28 2018-12-29 2019-01-14 Non-CE5: CABAC skip mode for super
JVET-M0089 m45346 K. Abe, T. Toma (Panasonic)
11:59:29 11:22:03 08:36:40 low delay
JVET-M0090 m45347 2018-12-28 2018-12-28 2018-12-28 On the use of chroma QP offsets in the C. Helmrich, H. Schwarz, D.
12:57:32 13:21:05 13:21:05 VVC common test conditions Marpe, T. Wiegand (HHI)
JVET-M0091 m45348 2018-12-28 2018-12-28 2018-12-28 AHG10: Clean-up and finalization of C. Helmrich, H. Schwarz, D.
Page: 350 Date Saved: 2019-03-172019-03-14

perceptually optimized QP adaptation
13:14:28 21:17:01 21:17:01 Marpe, T. Wiegand (HHI)
method in VTM
CE11: Very strong deblocking with C. Helmrich, B. Bross, H.
2018-12-28 2019-01-02 2019-01-02
JVET-M0092 m45349 conditional activation signalling (Test Schwarz, D. Marpe, T.
13:16:39 23:47:16 23:47:16
11.1.1) Wiegand (HHI)
Non-CE3: Improved robustness for
2018-12-28 2018-12-28 2018-12-28 C. Helmrich, H. Schwarz, D.
JVET-M0093 m45350 calculation of cross-component linear
13:19:22 13:32:01 13:32:01 Marpe, T. Wiegand (HHI)
model parameters
2018-12-28 2019-01-02 2019-01-03 CE3: Decoder-side Intra Mode Derivation E. Mora, A. Nasrallah, M.
JVET-M0094 m45351
13:59:47 10:42:57 18:07:21 (tests 3.1.1, 3.1.2, 3.1.3 and 3.1.4) Abdoli, M. Raulet (ATEME)
G. Van der Auwera, A. K.
2018-12-28 2019-01-03 2019-01-03 Ramasubramonian, V.
JVET-M0095 m45353 Non-CE3: Intra simplifications
(Qualcomm)
L. Pham Van, G. Van der
Auwera, A. K.
2018-12-28 2019-01-03 2019-01-10 CE10-related: Inter-intra prediction
JVET-M0096 m45354 Ramasubramonian, V.
18:46:05 04:44:43 18:25:53 combination
Seregin, M. Karczewicz
(Qualcomm)
A. K. Ramasubramonian, G.
2018-12-28 2019-01-03 2019-01-03 Van der Auwera, T. Hsieh, V.
JVET-M0097 m45356 CE3: On MMLM (Test 2.1)
(Qualcomm)
Van der Auwera, T. Hsieh, V.
2018-12-28 2019-01-03 2019-01-03
JVET-M0098 m45357 CE3: Joint test on MMLM (Test 2.2.1) Seregin, M. Karczewicz
19:32:27 07:04:06 07:04:06
(Qualcomm), H.-J. Jhu, Y.-J.
Chang (Foxconn)
2018-12-28 2019-01-03 2019-01-09 Non-CE3: Partial sorting for non-MPM Van der Auwera, T. Hsieh, V.
JVET-M0099 m45358
19:36:24 07:12:08 16:37:58 modes Seregin, M. Karczewicz
(Qualcomm)
2018-12-28 2018-12-31 2018-12-31 CE3-related: DM-dependent chroma intra G. Rath, F. Urban, F. Racapé
JVET-M0100 m45359
20:19:47 00:59:02 00:59:02 prediction modes (Technicolor)
R. Skupin, K. Sühring, Y.
Sanchez (HHI), M. M.
Hannuksela, K. Kammachi-
2018-12-28 2018-12-28 2019-01-12 Sreedhar (Nokia), Y.-K.
JVET-M0101 m45360 AHG17: On VVC HLS
21:13:08 21:23:03 12:25:23 Wang, Hendry (Huawei), S.
Wenger, B. Choi (Tencent), S.
Deshpande (Sharp), R.
Sjöberg (Ericsson)
S. De-Luxán-Hernández, V.
2018-12-29 2019-01-02 2019-01-17 CE3: Intra Sub-Partitions Coding Mode George, J. Ma, T. Nguyen, H.
JVET-M0102 m45361
00:34:53 18:26:35 00:00:10 (Tests 1.1.1 and 1.1.2) Schwarz, D. Marpe, T.
Wiegand (HHI)
K. Andersson, J. Enhorn, R.
2018-12-29 2018-12-29 2019-01-14 Deblocking for multi-hypothesis intra inter
JVET-M0103 m45362 Yu, Z. Zhang, R. Sjöberg
00:47:40 00:56:49 15:06:46 prediction
(Ericsson)
2018-12-29 2019-01-02 2019-01-09 CE2: Planar Motion Vector Prediction (test N. Zhang, X. Chen, J. Zheng,
JVET-M0104 m45363
09:00:28 16:00:02 01:26:28 2.3.1) Y. Lin (HiSilicon)
2018-12-29 2018-12-29 2019-01-13 R. Chernyak, S. Ikonin, J.
JVET-M0105 m45364 Non-CE7: Delta QP for Chroma CU
14:49:30 16:22:59 16:14:53 Chen (Huawei)
2018-12-29 2018-12-29 2019-01-09 F. Le Léannec, T. Poirier, F.
JVET-M0106 m45365 CE4: STMVP without scaling (tests 4.2.2)
15:23:00 15:51:02 13:17:30 Galpin (Technicolor)
2018-12-29 2018-12-29 2019-01-17 CE7-related: reduced local neighbourhood F. Le Léannec, Y. Chen
JVET-M0107 m45366
15:25:06 15:40:17 12:43:09 usage for transform coefficients coding (Technicolor)
CE3-related: Reducing the number of
2018-12-29 2019-01-02 2019-01-10 E. François, T. Poirier, F. Le
JVET-M0108 m45367 reference samples and table size in LM
16:31:24 18:00:14 15:11:53 Léannec (Technicolor)
Chroma process
2018-12-29 2019-01-02 2019-01-11 CE12-related: block-based in-loop E. François, C. Chevance, F.
JVET-M0109 m45368
16:33:37 18:01:19 17:49:05 reshaping Hiron (Technicolor)
CE2-related: Alignment of affine control- H. Huang, W.-J. Chien, V.
2018-12-29 2019-01-02 2019-01-07
JVET-M0110 m45369 point motion vector and subblock motion Seregin, H. Wang, M.
19:55:25 04:02:12 21:22:15
vector Karczewicz (Qualcomm)
JVET-M0111 m45370 2018-12-30 2018-12-30 2019-01-11 AHG13: On bi-prediction with weighted Y. Ye, J. Chen, M. Yang
14:54:26 15:09:31 12:10:35 averaging and weighted prediction (Alibaba), P. Bordes, E.
Francois (Technicolor)
JVET-M0112 m45371 2018-12-30 2018-12-30 2018-12-30 CE10: LIC confined within current CTU P. Bordes, T. Poirier, F. Le
Page: 351 Date Saved: 2019-03-172019-03-14

16:37:37 16:46:44 16:46:44 (test 10.5.3) Léannec (Technicolor)
2018-12-30 2018-12-30 2019-01-16 CE7-related: Quantization Group size P. de Lagrange, E. François,
JVET-M0113 m45373
23:29:06 23:54:22 16:29:23 uniformity P. Bordes (Technicolor)
2018-12-30 2018-12-30 2018-12-30 CE7-related: implicit QP-offset based on P. de Lagrange, E. François,
JVET-M0114 m45374
23:40:19 23:56:13 23:56:13 block size F. Le Léannec (Technicolor)
2018-12-30 2018-12-30 2019-01-10 CE10-related: pipeline reduction for LIC P. Bordes, F. Galpin, T.
JVET-M0115 m45375
23:42:28 23:51:39 13:14:34 and GBI Poirier (Technicolor)
2018-12-31 2018-12-31 2019-01-10 R. Yu, D. Liu, K. Andersson,
JVET-M0116 m45376 CE2-related: ATMVP simplification
09:11:43 09:20:40 19:06:58 R. Sjöberg (Ericsson)
R. Yu, D. Liu, K. Andersson,
2018-12-31 2018-12-31 2019-01-17 CE4-related: On MVP candidate list
JVET-M0117 m45377 P. Wennersten, J. Ström, R.
09:13:47 09:25:04 07:55:54 generation for AMVP
Sjöberg (Ericsson)
2018-12-31 2019-01-02 2019-01-11 CE10-related: A fix for merge triangle flag
JVET-M0118 m45378 R. Yu (Ericsson)
09:26:55 10:06:06 09:48:07 signalling
2018-12-31 2018-12-31 2019-01-18 CE7-related: Modified dequantization K. Sharman, S. Keating
JVET-M0119 m45379
12:33:22 12:40:29 11:14:32 scaling (Sony)
2018-12-31 2019-01-02 2019-01-02 AHG17: Proposed NAL Unit Header S. Wenger, B. Choi, S. Liu
JVET-M0120 m45380
16:22:57 20:29:15 20:29:15 Design Principles (Tencent)
2018-12-31 2018-12-31 2019-01-02 Y. He, A. Hamza
JVET-M0121 m45382 AHG12: On Rectangular Tile Group
20:01:00 20:15:33 21:57:59 (InterDigital)
2018-12-31 2019-01-03 2019-01-14 Non-CE3: On block size restrictions for A. Filippov, V. Rufitskiy, J.
JVET-M0122 m45381
18:16:33 00:36:46 19:10:50 PDPC Chen (Huawei)
2018-12-31 2018-12-31 2019-01-02 Y. He, A. Hamza
JVET-M0123 m45383 AHG12: On hierarchical tile design
20:02:56 20:19:10 21:58:30 (InterDigital)
CE4: Methods of Reducing Number of
2018-12-31 2019-01-02 2019-01-15
JVET-M0124 m45384 Pruning Checks of History Based Motion J. Zhao, S. Kim (LGE),
20:23:40 23:21:01 16:29:11
Vector Prediction (Test 4.1.1)
2018-12-31 2019-01-02 2019-01-02 CE2: History Based Affine Motion J. Zhao, S. Kim (LGE), G. Li,
JVET-M0125 m45385
20:56:09 23:23:13 23:23:13 Candidate (Test 2.2.3) X. Xu, X. Li, S. Liu (Tencent)
Y. Han, W.-J. Chien, C.-C.
2018-12-31 2018-12-31 2019-01-19 CE4: Modification on History-based Chen, H. Huang, C.-H. Hung,
JVET-M0126 m45387
23:16:29 23:51:06 00:53:18 Motion Vector Prediction Y. Zhang, M. Karczewicz
(Qualcomm)
Y. Han, W.-J. Chien, D.
Rusanovskyy, Y.-H. Chao, C.-
2018-12-31 2018-12-31 2019-01-04
JVET-M0127 m45388 CE4-related: Modification on Merge List C. Chen, H. Wang, H. Huang,
23:23:27 23:50:00 00:45:07
C.-H. Hung, Y. Zhang, M.
Karczewicz (Qualcomm)
Y.-K. Wang, Hendry
(Huawei), S. Deshpande
(Sharp), M. M. Hannusela
(Nokia), G. Ryu, W. Choi
(Samsung), X. Wang, Y.-W.
Chen (Kawi), L. Zhang
(Bytedance), P. Wu, M. Li
2019-01-01 2019-01-02 2019-01-02 AHG17: On reference picture management (ZTE), S.-H. Kim (LG), J.
JVET-M0128 m45390
01:55:41 20:41:03 20:41:03 for VVC Boyce (Intel), A. M. Tourapis,
D. Singer (Apple), E.
François, P. Andrivon
(Technicolor), Y.-W. Huang,
C.-W. Hsu, C.-Y. Chen, T.-D.
Chuang, L. Chen (MediaTek),
K. Kawamura (KDDI), Y.-C.
Sun, J. Lou (Alibaba)
2019-01-01 2019-01-02 2019-01-02 Y.-K. Wang, Hendry, M.
JVET-M0129 m45391 AHG12: On flexible tiling
01:56:27 20:26:37 20:26:37 Sychev (Huawei)
2019-01-01 2019-01-02 2019-01-02 Y.-K. Wang, Hendry, J. Chen,
JVET-M0130 m45392 AHG12: On tile grouping
01:56:46 20:26:56 20:26:56 M. Sychev (Huawei)
2019-01-01 2019-01-02 2019-01-02 AHG17: On NAL unit types for IRAP Y.-K. Wang, Hendry
JVET-M0131 m45393
01:57:50 20:28:14 20:28:14 pictures and leading pictures (Huawei)
2019-01-01 2019-01-02 2019-01-16 Y.-K. Wang, Hendry, J. Chen
JVET-M0132 m45394 AHG17: On header parameter set (HPS)
01:58:48 20:29:00 09:07:46 (Huawei)
2019-01-01 2019-01-02 2019-01-02 AHG17: On parsing dependency between Y.-K. Wang (Huawei), J.
JVET-M0133 m45395
01:59:07 20:24:41 20:24:41 parameter sets Boyce (Intel)
2019-01-01 2019-01-02 2019-01-02 Hendry, Y.-K. Wang, J. Chen,
JVET-M0134 m45396 AHG12: On explicit signalling of tile IDs
02:02:00 19:44:07 19:51:27 M. Sychev (Huawei)
JVET-M0135 m45397 2019-01-01 2019-01-02 2019-01-02 On adaptive resolution change (ARC) for Hendry, Y.-K Wang, J. Chen
02:10:07 19:52:10 19:52:10 VVC (Huawei), T. Davies, A.
Page: 352 Date Saved: 2019-03-172019-03-14

Fuldseth (Cisco), Y.-C Sun,
T.-S Chang, J. Lou (Alibaba)
2019-01-01 2019-01-02 2019-01-02 AHG12: Treating tile and tile group J. Chen, Y.-K. Wang, Hendry,
JVET-M0136 m45398
02:31:53 20:29:25 20:29:25 boundaries as picture boundaries M. Sychev (Huawei)
2019-01-01 2019-01-02 2019-01-02 M. Sychev, Hendry, Y.-K.
JVET-M0137 m45399 AHG12: On tile configuration signalling
02:32:49 21:33:30 21:33:30 Wang (Huawei)
2019-01-01 2019-01-01 2019-01-08 Non-CE3: Intra reference sample Z. Zhang, K. Andersson, R.
JVET-M0138 m45402
15:01:53 15:26:23 19:41:19 deblocking Sjöberg (Ericsson)
Z. Zhang, P. Wennersten, R.
2019-01-01 2019-01-01 2019-01-08 Non-CE3: History-based intra most
JVET-M0139 m45403 Yu, J. Ström, R. Sjöberg
15:06:26 17:38:08 19:38:30 probable modes derivation
(Ericsson)
2019-01-01 2019-01-02 2019-01-16 CE6: Sub-block transform for inter blocks Y. Zhao, H. Gao, H. Yang, J.
JVET-M0140 m45404
16:00:22 14:03:26 16:18:09 (Test 6.4.1) Chen (Huawei)
2019-01-01 2019-01-02 2019-01-11 CE6: RQT-like sub-block transform for Y. Zhao, H. Gao, H. Yang, J.
JVET-M0141 m45405
16:00:55 14:04:56 13:47:35 inter blocks (Test 6.4.4) Chen (Huawei)
2019-01-01 2019-01-01 2019-01-25 CE3: Modified CCLM downsampling filter P. Hanhart, Y. He
JVET-M0142 m45406
18:09:55 18:30:33 00:44:09 for â€œtype-2â€ content (Test 2.4) (InterDigital)
CE13: Face row based geometry padding
2019-01-01 2019-01-01 2019-01-01 P. Hanhart, Y. He
JVET-M0143 m45407 using projection with bilinear interpolation
18:09:57 18:46:15 18:46:15 (InterDigital)
based on test 1.1.a (Test 2.1.b)
2019-01-01 2019-01-01 2019-01-01 CE13: Adaptive frame packing based on P. Hanhart, Y. He
JVET-M0144 m45408
18:09:59 18:28:44 18:28:44 test 1.1.a (Test 4.1) (InterDigital)
2019-01-01 2019-01-01 2019-01-26 Non-CE2: Motion vector clipping in affine P. Hanhart, Y. He
JVET-M0145 m45409
18:10:02 18:29:27 00:33:30 sub-block motion vector derivation (InterDigital)
2019-01-01 2019-01-01 2019-01-10 P. Hanhart, Y. He
JVET-M0146 m45410 Non-CE3: MDLM template downsampling
18:10:03 18:27:54 18:26:44 (InterDigital)
2019-01-01 2019-01-02 2019-01-17 CE9: Results of DMVR related Tests
JVET-M0147 m45412 S. Sethuraman (Ittiam)
18:39:51 19:06:30 10:52:39 CE9.2.1 and CE9.2.2
2019-01-01 2019-01-02 2019-01-12 Non-CE9: Simplifications to DMVR search
18:41:26 19:07:04 10:23:23 pattern and interpolation for refinement
2019-01-01 2019-01-03 2019-01-11 Non-CE3: On simplification of PDPC basic A. Filippov, V. Rufitskiy, J.
JVET-M0149 m45411
18:22:45 01:46:18 15:51:21 equation Chen (Huawei)
L. Pham Van, W.-J. Chien, H.
2019-01-01 2019-01-01 2019-01-10 CE2.4.3: Affine restriction for worst-case
JVET-M0150 m45416 Huang, V. Seregin, M.
22:52:08 22:56:28 18:22:12 memory bandwidth reduction
L. Pham Van, T. Hsieh, W.-J.
2019-01-01 2019-01-01 2019-01-09 CE8-related: Virtual search area for current
JVET-M0151 m45417 Chien, V. Seregin, H. Wang,
23:04:31 23:11:24 20:58:16 picture referencing (CPR)
M. Karczewicz (Qualcomm)
2019-01-01 2019-01-03 2019-01-03 B. Choi, S. Wenger, S. Liu
JVET-M0152 m45418 AHG17: On random access point for VVC
23:39:09 06:36:37 06:36:37 (Tencent)
JVET-M0153 m45419 AHG17: On leading picture for VVC
23:42:00 06:37:08 06:37:08 (Tencent)
2019-01-01 2019-01-03 2019-01-09 AHG17: On decoded picture buffer B. Choi, S. Wenger, S. Liu
JVET-M0154 m45420
23:44:29 06:37:32 19:43:46 management for VVC (Tencent)
2019-01-01 2019-01-03 2019-01-03 AHG12: On tile group identification for B. Choi, S. Wenger, S. Liu
JVET-M0155 m45421
23:46:36 20:44:10 20:44:10 VVC (Tencent)
2019-01-01 2019-01-03 2019-01-03 AHG17: On component type indication for B. Choi, S. Wenger, S. Yea, S.
JVET-M0156 m45422
23:47:46 20:44:34 20:44:34 VVC Liu (Tencent)
JVET-M0157 m45423 AHG17: On picture order count for VVC
23:48:40 20:44:59 20:44:59 (Tencent)
2019-01-01 2019-01-03 2019-01-15 Non-CE3: LUT-free interpolation filters for A. Filippov, V. Rufitskiy, J.
JVET-M0158 m45424
23:52:43 02:18:43 00:54:41 intra prediction Chen (Huawei)
Y.-L. Hsiao, C.-Y. Chen, T.-
2019-01-02 2019-01-03 2019-01-09 AHG9: Convolutional neural network loop
JVET-M0159 m45425 D. Chuang, C.-W. Hsu, Y.-W.
00:37:14 05:43:08 15:46:30 filter
Huang, S.-M. Lei (MediaTek)
2019-01-02 2019-01-02 2019-01-06 L. Chen, T.-D. Chuang, Y.-W.
JVET-M0160 m45426 AHG17: Flexible tile grouping for VVC
00:37:42 22:28:14 13:35:10 Huang, S.-M. Lei (MediaTek)
2019-01-02 2019-01-02 2019-01-09 AHG17: Signalling random access L. Chen, C.-W. Hsu, Y.-W.
JVET-M0161 m45427
00:38:13 22:29:00 15:47:28 properties in the NAL unit header Huang, S.-M. Lei (MediaTek)
C.-Y. Chen, Z.-Y. Lin, C.-Y.
2019-01-02 2019-01-02 2019-01-12 Adaptive loop filter with a maximum
JVET-M0162 m45428 Lai, Y.-W. Huang, S.-M. Lei
00:38:33 21:39:41 11:06:28 number of luma filters per slice constraint
(MediaTek)
C.-Y. Chen, Z.-Y. Lin, C.-Y.
2019-01-02 2019-01-02 2019-01-12
JVET-M0163 m45429 Adaptive loop filter with history filters Lai, Y.-W. Huang, S.-M. Lei
00:38:52 21:40:41 11:07:06
(MediaTek)
JVET-M0164 m45430 2019-01-02 2019-01-02 2019-01-12 Adaptive loop filter with virtual boundary C.-Y. Chen, T.-D. Chuang, Z.-
Page: 353 Date Saved: 2019-03-172019-03-14

Y. Lin, C.-Y. Lai, Y.-W.
00:40:12 21:41:31 11:08:44 processing
2019-01-02 2019-01-02 2019-01-09 C.-C. Chen, C.-W. Hsu, Y.-W.
JVET-M0165 m45431 CE2.5.1: Simplification of SbTMVP
Z.-Y. Lin, T.-D. Chuang, C.-
2019-01-02 2019-01-03 2019-01-09 CE2-related: Simplification of constructed
JVET-M0166 m45432 Y. Chen, Y.-W. Huang, S.-M.
00:41:14 05:44:02 16:12:41 affine merging candidate derivation
Lei (MediaTek)
Y.-L. Hsiao, T.-D. Chuang,
CE2-related: Decoupling of SbTMVP and
2019-01-02 2019-01-02 2019-01-09 C.-W. Hsu, C.-Y. Chen, Y.-
JVET-M0167 m45433 affine merge candidate derivation in
00:41:46 21:43:04 16:14:46 W. Huang, S.-M. Lei
subblock merge mode
(MediaTek)
Y.-L. Hsiao, T.-D. Chuang,
2019-01-02 2019-01-02 2019-01-09 CE2-related: Simplifications for inherited C.-W. Hsu, C.-Y. Chen, Y.-
JVET-M0168 m45434
00:42:16 21:43:43 16:17:43 affine candidates W. Huang, S.-M. Lei
(MediaTek)
2019-01-02 2019-01-02 2019-01-16 CE3-related: Shared reference samples for
JVET-M0169 m45435 Y. Chen, Y.-W. Huang, S.-M.
00:42:42 21:44:38 11:31:12 multiple chroma intra CBs
Lei (MediaTek)
C.-C. Chen, Y.-C. Lin, M.-S.
2019-01-02 2019-01-02 2019-01-11 Chiang, C.-W. Hsu, T.-D.
JVET-M0170 m45436 CE4.3.1: Shared merging candidate list
00:43:08 21:45:26 22:32:19 Chuang, C.-Y. Chen, Y.-W.
C.-Y. Lai, T.-D. Chuang, Y.-
2019-01-02 2019-01-02 2019-01-17
JVET-M0171 m45437 CE4-related: MMVD cleanups L. Hsiao, C.-Y. Chen, Y.-W.
00:43:34 21:46:03 16:36:45
T.-D. Chuang, C.-Y. Chen,
2019-01-02 2019-01-02 2019-01-09 CE5.1.9: CABAC engine with simplified
JVET-M0172 m45438 Y.-W. Huang, S.-M. Lei
00:44:03 21:46:42 16:32:49 range sub-interval derivation
(MediaTek)
CE7 (Tests 7.1, 7.2, 7.3, and 7.4): T.-D. Chuang, S.-T. Hsiang,
2019-01-02 2019-01-02 2019-01-09
JVET-M0173 m45439 Constraints on context-coded bins for Z.-Y. Lin, C.-Y. Chen, Y.-W.
00:44:29 21:47:22 16:33:35
coefficient coding Huang, S.-M. Lei (MediaTek)
2019-01-02 2019-01-02 2019-01-10 CE8-related: Removal of subblock-based
JVET-M0174 m45440 L. Hsiao, C.-Y. Chen, Y.-W.
00:44:57 21:47:53 11:02:56 chroma MC in CPR
2019-01-02 2019-01-02 2019-01-09 CE8-related: Clarification on interaction
JVET-M0175 m45441 L. Hsiao, C.-Y. Chen, Y.-W.
00:45:26 21:48:29 16:37:38 between CPR and other inter coding tools
CE10.1.1: Multi-hypothesis prediction for M.-S. Chiang, C.-W. Hsu, Y.-
2019-01-02 2019-01-02 2019-01-10
JVET-M0176 m45442 improving non-skip & non-merge inter W. Huang, S.-M. Lei
00:45:58 21:49:10 12:26:05
mode and merge mode (MediaTek)
M.-S. Chiang, C.-W. Hsu, Y.-
2019-01-02 2019-01-02 2019-01-09 CE10.1.4: Simplification of combined inter
JVET-M0177 m45443 W. Huang, S.-M. Lei
00:46:25 21:49:55 18:07:06 and intra prediction
(MediaTek)
Y. Chen, C.-W. Hsu, C.-C.
2019-01-02 2019-01-02 2019-01-12 CE10.2.1: Uni-prediction-based CU-
JVET-M0178 m45444 Chen, Y.-C. Lin, Y.-W.
00:46:49 21:50:43 19:33:16 boundary-only OBMC
Huang, S.-M. Lei (MediaTek),
X. Xiu, Y. He (InterDigital)
2019-01-02 2019-01-02 2019-01-12 CE10.2.2: Integer-MV-based CU-
JVET-M0179 m45445 Chen, Y.-C. Lin, Y.-W.
00:47:12 22:04:56 19:33:53 boundary-only OBMC
Huang, S.-M. Lei (MediaTek),
X. Xiu, Y. He (InterDigital)
Y.-C. Lin, C.-C. Chen, C.-W.
2019-01-02 2019-01-02 2019-01-09 CE10.2.3: Subblock OBMC with uni- Hsu, Z.-Y. Lin, T.-D. Chuang,
JVET-M0180 m45446
00:47:36 22:17:56 18:04:24 prediction-based OBMC at CU boundaries C.-Y. Chen, Y.-W. Huang, S.-
M. Lei (MediaTek)
Y.-C. Lin, C.-C. Chen, C.-W.
2019-01-02 2019-01-02 2019-01-09 CE10.2.4: Subblock OBMC with integer- Hsu, Z.-Y. Lin, T.-D. Chuang,
JVET-M0181 m45447
00:48:02 22:20:50 18:04:59 MV-based OBMC at CU boundaries C.-Y. Chen, Y.-W. Huang, S.-
M. Lei (MediaTek)
C.-M. Tsai, C.-C. Chen, C.-
2019-01-02 2019-01-03 2019-01-09 CE10-related: Simplification of local
JVET-M0182 m45448 W. Hsu, Y.-W. Huang, S.-M.
00:48:28 00:42:07 18:05:37 illumination compensation
Lei (MediaTek)
JVET-M0183 m45449 2019-01-02 2019-01-03 2019-01-09 CE10-related: Simplification of MPM M.-S. Chiang, C.-W. Hsu, Y.-
00:48:52 03:17:28 18:08:52 generation for CIIP W. Huang, S.-M. Lei
(MediaTek)
JVET-M0184 m45450 2019-01-02 2019-01-02 2019-01-09 CE10-related: Simplification of triangle T.-D. Chuang, C.-Y. Chen,
00:49:18 22:22:00 18:09:30 merging candidate list derivation Y.-W. Huang, S.-M. Lei
Page: 354 Date Saved: 2019-03-172019-03-14

(MediaTek)
M.-S. Chiang, C.-W. Hsu, Y.-
2019-01-02 2019-01-02 2019-01-09 CE10-related: Syntax redundancy removal
JVET-M0185 m45451 W. Huang, S.-M. Lei
00:49:45 22:22:44 18:10:49 in triangle prediction
(MediaTek)
C.-M. Tsai, T.-D. Chuang, C.-
2019-01-02 2019-01-02 2019-01-09
JVET-M0186 m45452 CE11.1.3: Long deblocking filters W. Hsu, C.-Y. Chen, Y.-W.
00:50:09 22:23:41 16:41:11
CE11-related: Long deblocking filters with
2019-01-02 2019-01-02 2019-01-09 C.-M. Tsai, C.-W. Hsu, Y.-W.
JVET-M0187 m45453 reduced line buffer requirement and
enhanced parallel processing accessibility
O. Chubach, T.-D. Chuang,
2019-01-02 2019-01-02 2019-01-16 CE7-related: On quantization parameter C.-W. Hsu, C.-Y. Chen, Y.-
JVET-M0188 m45454
00:51:18 22:29:57 11:32:00 signalling considering CU area W. Huang, S.-M. Lei
(MediaTek)
2019-01-02 2019-01-02 2019-01-04 CE10: AMVP mode for triangle prediction Y. Ahn, D. Sim (Digital
JVET-M0189 m45455
02:18:16 17:51:46 03:31:59 (test 10.3.1) Insights)
2019-01-02 2019-01-02 2019-01-06 CE10-related: Redundant syntax reduction Y. Ahn, D. Sim (Digital
JVET-M0190 m45456
02:19:25 17:52:19 14:58:23 for triangle prediction Insights)
2019-01-02 2019-01-02 2019-01-06 CE3-related: Construction of non-MPM S. Cha, G. Lee, G. Kim, J.
JVET-M0191 m45457
02:27:46 09:26:15 19:03:28 mode list in intra prediction Han (Sejong Univ.)
2019-01-02 2019-01-03 2019-01-13 CE2-related: MV Derivation for Affine A. Tamse, M. W. Park, K.
JVET-M0192 m45458
02:31:19 02:35:20 17:06:34 Chroma Choi (Samsung)
2019-01-02 2019-01-03 2019-01-17 CE4-related: Pairwise Average Candidate A. Tamse, M. W. Park, K.
JVET-M0193 m45459
02:31:22 02:35:20 10:39:35 Reduction Choi (Samsung)
A. Tamse, M. W. Park, S.
2019-01-02 2019-01-03 2019-01-09 CE10-related: Triangle Prediction Mode
JVET-M0194 m45460 Jeong, M. Park, K. Choi
02:31:23 02:35:15 11:22:25 Harmonization
(Samsung)
2019-01-02 2019-01-03 2019-01-09 CE1-related: Non-Residual Block on A. Tamse, M. W. Park, M.
JVET-M0195 m45461
02:31:23 02:35:14 11:22:25 VPDU Boundary Park, K. Choi (Samsung)
2019-01-02 2019-01-02 2019-01-02 CE5-related : Counter-based multi-CABAC
JVET-M0196 m45462 Y. Piao, K. Choi (Samsung)
02:31:43 06:02:58 06:02:58 for partial context models
2019-01-02 2019-01-03 2019-01-06 AHG14: Software for ultra low-latency
JVET-M0197 m45463 K.Kazui (Fujitsu)
02:32:08 04:03:09 00:07:57 encoding
2019-01-02 2019-01-02 2019-01-02 CE7-related : Unified rice parameter
JVET-M0198 m45464 Y. Piao, K. Choi (Samsung)
02:32:43 06:40:12 06:40:12 derivation for coefficient level coding
2019-01-02 2019-01-02 2019-01-02 CE5: Counter-based probability estimation
JVET-M0199 m45465 K. Choi, Y. Piao (Samsung)
02:33:36 11:46:44 11:46:44 (CE5.1.8)
2019-01-02 2019-01-02 2019-01-02 CE6: Unified matrix for transform (Test 6- K. Choi, M. Park, M. W. Park,
JVET-M0200 m45466
02:33:50 11:52:06 11:52:06 1.2a) W. Choi (Samsung)
2019-01-02 2019-01-02 2019-01-02 CE6-related: Syntax clean-up related to K. Choi, M. Park, M. W. Park,
JVET-M0201 m45467
02:34:06 11:54:29 11:54:29 MTS W. Choi (Samsung)
K. Choi, M. Park, M. W. Park,
2019-01-02 2019-01-02 2019-01-04 CE6-related: Simplification related to MTS W. Choi (Samsung), M.
JVET-M0202 m45468
02:34:20 12:01:08 22:58:12 with reduced modes Salehifar, M. Koo, J. Lim, S.
Kim (LGE)
2019-01-02 2019-01-03 2019-01-17 CE3: DM-based chroma intra prediction N. Choi, M. W. Park, K. Choi
JVET-M0203 m45469
02:38:36 04:21:06 13:00:55 modes (Test 3.5) (Samsung)
M. Park, M. W. Park, S.
2019-01-02 2019-01-03 2019-01-05
JVET-M0204 m45470 CE2-related: Simplification of ATMVP Jeong, A. Tamse, K. Choi
02:43:31 04:04:35 05:47:52
(Samsung)
2019-01-02
02:57:37
2019-01-02 2019-01-03 2019-01-12 S. Jeong, M. W. Park, K. Choi
JVET-M0206 m45472 CE4-related: MMVD improvements
02:57:58 06:22:12 10:35:31 (Samsung)
CE10-related: Joint optimizations of S. Jeong, M. W. Park, A.
2019-01-02 2019-01-03 2019-01-13
JVET-M0207 m45473 Triangular prediction unit mode and Multi- Tamse, M. Park, K. Choi
02:58:21 06:24:12 17:31:52
Hypothesis prediction mode (Samsung)
2019-01-02 2019-01-03 2019-01-11 CE11: long-tap deblocking filter (Test
JVET-M0208 m45474 W. Choi, K. Choi (Samsung)
03:08:16 05:55:00 07:21:15 11.1.4)
2019-01-02 2019-01-03 2019-01-04 W. Choi, K. Choi, K. Choi
JVET-M0209 m45475 AHG12: On tile group configuration
03:20:39 06:17:58 03:45:13 (Samsung)
2019-01-02 2019-01-02 2019-01-11 Non-CE3: Intra prediction information J. Yao, J. Zhu, W. Cai, K.
JVET-M0210 m45476
03:23:35 11:03:05 12:40:20 coding Kazui (Fujitsu)
JVET-M0211 m45477 2019-01-02 2019-01-03 2019-01-10 CE3-related:Fixed Reference Samples J.-Y. Huo, X.-W. Li, X.-Y.
03:43:18 03:33:46 09:22:21 Design for CCLM Chai, J.-L. Wang, Y.-Z. Ma,
F.-Z. Yang (Xidian Univ.), S.
Wan (NPU), Y.-F. Yu, Y. Liu
Page: 355 Date Saved: 2019-03-172019-03-14

(Oppo)
S. Wan (NPU), Q.-H.Ran, X.-
2019-01-02 2019-01-03 2019-01-10 CE3-related:Improved reference samples W. Li, Y.-Z. Ma, J.-Y. Huo,
JVET-M0212 m45478
03:43:29 03:34:29 09:23:28 range for MDLM F.-Z. Yang (Xidian Univ.),
Y.-F. Yu, Y. Liu (Oppo)
Y.-Z. Ma, J.-L. Wang, X.-W.
Li, J.-Y. Huo, F.-Z. Yang
2019-01-02 2019-01-03 2019-01-10 CE3-related: Chroma intra candidates
JVET-M0213 m45479 (Xidian Univ.), S. Wan
03:43:41 03:37:39 10:43:07 modification based on directional DM
(NPU), Y.-F. Yu, Y. Liu
(Oppo)
Y.-Z. Ma, X.-W. Li, J.-L.
Wang, J.-Y. Huo, F.-Z. Yang
2019-01-02 2019-01-03 2019-01-11 CE3-related: Uniform chroma intra
03:43:50 03:39:12 07:46:09 candidates modification based on DM
(Oppo)
2019-01-02 2019-01-03 2019-01-15 AHG9-related: CNN-based lambda-domain Y. Li, D. Liu, Z. Chen
JVET-M0215 m45481
03:50:46 03:49:12 08:32:21 rate control for intra frames (USTC)
2019-01-02 2019-01-03 2019-01-13 CE10-related: syntax clean-up on triangle L. Li, J. Nam, N. Park, H.
JVET-M0216 m45482
03:52:14 03:31:55 20:21:45 prediction Jang, J. Lim, S. Kim (LGE)
2019-01-02 2019-01-03 2019-01-12 CE2-related: Constructed affine merge L. Li, J. Nam, N. Park, H.
JVET-M0217 m45483
04:00:17 04:14:59 20:42:40 candidate simplification Jang, J. Lim, S. Kim (LGE)
2019-01-02 2019-01-03 2019-01-03 CE3: Simplified MDMS (test 3.3.1 and test J. Choi, J. Heo, S. Yoo, L. Li,
JVET-M0218 m45484
04:07:39 05:30:45 05:30:45 3.3.2) J. Choi, J. Lim, S. Kim (LGE)
2019-01-02 2019-01-03 2019-01-11 CE3-related: Reduced number of reference J. Choi, J. Heo, S. Yoo, L. Li,
JVET-M0219 m45485
04:10:03 03:27:22 08:45:29 samples for CCLM parameter calculation J. Choi, J. Lim, S. Kim (LGE)
2019-01-02 2019-01-03 2019-01-03 Non-CE4: Subjective quality analysis of Y.-H Chao, W.-J Chien, M.
JVET-M0220 m45486
04:36:02 02:54:40 02:54:40 non-sub-block ATMVP Karczewicz (Qualcomm)
Y.-H. Chao, Y. Han, D.
2019-01-02 2019-01-03 2019-01-09
JVET-M0221 m45487 CE4: STMVP simplification (test 4.2.3a) Rusanovskyy, W.-J. Chien,
04:39:57 02:56:31 13:03:58
M. Karczewicz (Qualcomm)
Y.-H. Chao, A. Said, V.
2019-01-02 2019-01-03 2019-01-17
JVET-M0222 m45488 Context Reduction for CABAC in VVC Seregin, J. Dong, M.
04:41:54 02:57:00 16:01:06
2019-01-02 2019-01-02 2019-01-12 Non-CE9: Co-existence analysis for DMVR
05:19:15 19:07:45 10:24:07 with BDOF
2019-01-02 2019-01-03 2019-01-11 CE10-related: Local Illumination S. Bandyopadhyay, X. Xiu, Y.
JVET-M0224 m45490
05:19:46 07:30:26 18:05:16 compensation simplifications He (InterDigital)
2019-01-02 2019-01-04 2019-01-12 AHG8: On wrap around motion B. Choi, W. Feng, S. Liu
JVET-M0225 m45491
06:05:38 19:30:49 11:38:21 compensation (Tencent)
2019-01-02 2019-01-03 2019-01-09 CE2: Reducing worst-case memory Y.-W. Chen, X. Wang (Kwai
JVET-M0226 m45492
06:17:24 06:52:23 01:24:14 bandwidth of affine mode (test 2.4.1) Inc.)
2019-01-02 2019-01-03 2019-01-09 CE2: A second ATMVP candidate (test Y.-W. Chen, X. Wang (Kwai
JVET-M0227 m45493
06:17:41 06:52:44 01:27:53 2.5.2) Inc.)
2019-01-02 2019-01-03 2019-01-13 Y.-W. Chen, X. Wang (Kwai
JVET-M0228 m45494 CE2-related: Affine mode simplifications
06:17:53 06:53:44 13:28:17 Inc.)
JVET-M0229 m45495 CE3-related: Simplification of LM Mode
06:18:43 06:54:59 07:03:55 Inc.)
JVET-M0230 m45496 Non-CE4: Temporal MV buffer reduction
06:18:52 06:56:11 14:00:09 Inc.)
JVET-M0231 m45497 Non-CE4: Regular merge flag coding
06:19:01 08:37:03 01:40:57 Inc.)
2019-01-02 2019-01-03 2019-01-09 Non-CE10: Simplification of CIIP Intra Y.-W. Chen, X. Wang (Kwai
JVET-M0232 m45498
06:19:21 06:57:09 07:05:03 mode coding Inc.)
2019-01-02 2019-01-03 2019-01-12 Non-CE10: Triangle prediction merge list X. Wang, Y.-W. Chen (Kwai
JVET-M0233 m45499
06:19:30 08:52:14 09:47:34 construction Inc.)
2019-01-02 2019-01-03 2019-01-13 Non-CE10: Triangle prediction merge X. Wang, Y.-W. Chen (Kwai
JVET-M0234 m45500
06:19:39 10:12:31 20:23:23 index coding Inc.)
C. Pujara, A. Konda, A.
2019-01-02 2019-01-03 2019-01-13 CE13: HEC with Pre-rotation based on test
JVET-M0235 m45501 Singh, R. Gadde, W. Choi, K.
07:40:01 13:38:30 00:28:51 1.1a and 1.1b (Test 4.2)
Choi, K.P. Choi (Samsung)
2019-01-02 2019-01-02 2019-01-02 CE1: Transform tiling for pipelined C. Rosewarne, A. Dorrell
JVET-M0236 m45502
07:40:15 07:45:35 07:45:35 processing of CTUs (Test 1.2.1) (Canon)
CE1-related: Transform tiling with residual
2019-01-02 2019-01-02 2019-01-02 C. Rosewarne, A. Dorrell
JVET-M0237 m45503 reordering for pipelined processing of
07:50:56 08:30:42 08:30:42 (Canon)
CTUs
2019-01-02 2019-01-02 2019-01-18 J. Lee, H. Lee, S.-C. Lim, J.
JVET-M0238 m45504 Non-CE3: Modification of PDPC
08:09:32 10:14:04 11:05:24 Kang, H. Y. Kim (ETRI)
Page: 356 Date Saved: 2019-03-172019-03-14

2019-01-02 2019-01-02 2019-01-11 J. Lee, H. Lee, S.-C. Lim, J.
JVET-M0239 m45505 Non-CE3: Modification of MPM derivation
08:10:55 10:14:47 08:50:31 Kang, H. Y. Kim (ETRI)
2019-01-02 2019-01-02 2019-01-02 CE2-related: Simplification of subblock- H. Lee, S.-C. Lim, J. Lee, J.
JVET-M0240 m45506
08:14:10 11:15:35 11:15:35 based temporal merging candidates Kang, H. Y. Kim (ETRI)
2019-01-02 2019-01-02 2019-01-12 CE9-related: A simple gradient calculation H. Lee, J. Kang, S.-C. Lim, J.
JVET-M0241 m45507
08:15:46 12:56:01 08:55:56 at the CU boundaries for BDOF Lee, H. Y. Kim (ETRI)
Crosscheck of JVET-M0191 (CE3-related:
2019-01-02 2019-01-04 2019-01-04 J. Lee, H. Lee, S.-C. Lim, J.
JVET-M0242 m45508 Construction of non-MPM mode list in
08:17:07 08:54:45 08:54:45 Kang (ETRI)
intra prediction)
2019-01-02 2019-01-04 2019-01-04 Cross-check of JVET-M0429 (Coding tree S.-C. Lim, J. Kang, H. Lee, J.
JVET-M0243 m45509
08:30:39 02:53:36 02:53:36 block based adaptive loop filter) Lee (ETRI)
Y. Lin, J. Zheng, Q. Yu, N.
2019-01-02 2019-01-02 2019-01-10 CE6 : MTS using DST-4 and transposed
JVET-M0244 m45510 Zhang (HiSilicon), C. Zhu
08:52:00 17:15:41 07:57:30 DCT-2 (test 6-1.3)
(UESTC)
2019-01-02 2019-01-02 2019-01-09 AHG16-related: Chroma block coding and C. Rosewarne, A. Dorrell
JVET-M0245 m45511
08:52:17 08:58:26 10:48:53 size restriction (Canon)
H. Liu, K. Zhang, L. Zhang, J.
2019-01-02 2019-01-03 2019-01-09 CE2: Adaptive Motion Vector Resolution
JVET-M0246 m45512 Xu, Y. Wang, P. Zhao, D.
08:55:51 05:06:45 08:43:33 for Affine Inter Mode (Test 2.1.2)
Hong (Bytedance)
H. Liu, K. Zhang, L. Zhang, J.
2019-01-02 2019-01-03 2019-01-03 CE2-related: Joint test of AMVR for Affine
JVET-M0247 m45513 Xu (Bytedance), J. Luo, Y.
08:58:24 05:08:12 05:08:12 Inter mode (Test 2.1.1 and Test 2.1.2)
He, X. Xiu (InterDigital)
H. Liu, J. Chon, H.-C.
2019-01-02 2019-01-03 2019-01-03 AHG16: Motion compensation with padded
JVET-M0248 m45514 Chuang, L. Zhang, K. Zhang,
09:00:27 05:09:18 05:09:18 samples for small coding units
J. Xu (Bytedance)
H. Liu, L. Zhang, K. Zhang, J.
2019-01-02 2019-01-03 2019-01-12 Non-CE9: Modifications on Bi-Directional
09:02:45 05:10:10 09:28:31 Optical Flow
Hong (Bytedance)
J. Choi, J. Heo, S. Yoo, J.
2019-01-02 2019-01-02 2019-01-12 Non-CE7: Simplified CSBF coding for
JVET-M0250 m45516 Choi, L. Li, J. Lim, S. Kim
09:03:31 23:36:24 21:59:53 large block-size transforms
(LGE)
J. Choi, J. Heo, S. Yoo, J.
2019-01-02 2019-01-02 2019-01-16 Non-CE7: Last position coding for large
09:03:50 23:47:50 13:28:14 block-size transforms
(LGE)
CE3-1.3: Harmonization of Linear J. Heo, J. Choi, J. Choi, S.
2019-01-02 2019-01-02 2019-01-10
JVET-M0252 m45518 interpolation intra prediction (LIP) with Yoo, L. Li, J. Lim, S. Kim
09:04:00 09:27:21 11:03:40
Multiple reference line prediction (MRL) (LGE)
J. Xu, J. Li, K. Zhang, L.
2019-01-02 2019-01-03 2019-01-11
JVET-M0253 m45519 Non-CE8: Hash-based Motion Search Zhang (Bytedance), R. Xiong
09:05:45 06:04:37 17:28:21
(Peking Univ.)
J. Xu, K. Zhang, L. Zhang, H.
2019-01-02 2019-01-03 2019-01-03 Non-CE8: Subblock Operation Removal for
JVET-M0254 m45520 Liu, Y. Wang, P. Zhao, D.
09:06:35 06:01:58 06:01:58 Chroma CPR
Hong (Bytedance)
H. Liu, L. Zhang, K. Zhang, J.
2019-01-02 2019-01-03 2019-01-28 AHG11: MMVD without Fractional
09:06:48 05:35:25 05:57:40 Distances for SCC
Hong,
F. Galpin, A. Robert, F.
2019-01-02 2019-01-02 2019-01-02 CE2: Affine temporal constructed
JVET-M0256 m45522 Leleannec, T. Poirier
09:21:04 17:47:10 17:47:10 candidates (test 2.2.7)
(Technicolor)
CE7-related: coefficient scanning and last
2019-01-02 2019-01-03 2019-01-17 M. Coban, M. Karczewicz
JVET-M0257 m45523 position coding for TUs of greater than 32
09:32:06 04:39:33 14:59:34 (Qualcomm)
width or height
J.-Y. Huo, J.-L. Wang, X.-W.
Li, Y.-Z. Ma, F.-Z. Yang
2019-01-02 2019-01-03 2019-01-11 CE3-related: Chroma intra candidates
09:33:17 03:40:48 07:46:33 modification based on non-directional DM
(Oppo)
2019-01-02 2019-01-02 2019-01-13 Use cases and proposed design choices for M. M. Hannuksela, A.
JVET-M0259 m45525
09:33:46 21:18:13 09:28:11 adaptive resolution changing (ARC) Aminlou (Nokia)
2019-01-02 2019-01-02 2019-01-02 AHG17: Carriage of tile group header
JVET-M0260 m45526 M. M. Hannuksela (Nokia)
09:34:36 21:03:29 21:03:29 parameters in higher level structures
2019-01-02 2019-01-02 2019-01-02 M. M. Hannuksela, A.
JVET-M0261 m45527 AHG12: On grouping of tiles
09:35:23 21:18:49 21:18:49 Aminlou (Nokia)
K. Zhang, L. Zhang, H. Liu, J.
2019-01-02 2019-01-03 2019-01-09 CE2: Affine model inheritance from single-
09:36:17 05:50:05 16:43:09 line motion vectors (Test 2.4.8)
Hong(Bytedance)
JVET-M0263 m45529 2019-01-02 2019-01-03 2019-01-09 CE3: CCLM prediction with single-line K. Zhang, L. Zhang, H. Liu, J.
09:36:31 05:50:21 17:11:00 neighbouring luma samples (Test 2.6.1 and Xu, Y. Wang, P. Zhao, D.
Page: 357 Date Saved: 2019-03-172019-03-14

Test 2.6.2) Hong (Bytedance)
J. Li, S. Wang, W. Gao
(Peking Univ.), L. Zhang, K.
2019-01-02 2019-01-03 2019-01-14 Non-CE4: Harmonization between HMVP
JVET-M0264 m45530 Zhang, H. Liu, J. Xu
09:36:45 05:42:02 17:48:08 and GBi
(Bytedance), X. Xiu, J. Luo,
Y. He (InterDigital),
2019-01-02 2019-01-03 2019-01-16
JVET-M0265 m45531 AHG16: Clean-up on MV Rounding Xu, Y. Wang, P. Zhao, D.
09:36:57 05:51:51 15:58:04
Hong(Bytedance)
2019-01-02 2019-01-03 2019-01-03 CE2-related: History-based affine merge
09:37:11 05:53:13 05:53:13 candidates
Hong (Bytedance)
2019-01-02 2019-01-03 2019-01-12 Non-CE4: Harmonization of MMVD and
09:37:25 05:53:31 08:55:48 AMVR
Hong (Bytedance)
2019-01-02 2019-01-03 2019-01-15 Non-CE2: Interweaved Prediction for
09:37:38 05:53:49 10:29:12 Affine Motion Compensation
Hong (Bytedance)
S. Yoo, J. Choi, J. Heo, J.
2019-01-02 2019-01-02 2019-01-13 Non-CE6 : Extension of transform skip
09:37:44 11:23:56 16:19:29 block size to 8x8
(LGE)
2019-01-02 2019-01-03 2019-01-10 CE2-related: An alternative storing method
09:37:51 05:58:44 21:16:37 for affine inheritance
Hong(Bytedance)
L. Zhang, K. Zhang, H. Liu, J.
2019-01-02 2019-01-03 2019-01-03 CE10-related: Merge list construction
09:38:08 06:05:19 06:05:19 process for triangular prediction mode
Hong(Bytedance)
L. Zhang, K. Zhang, H. Liu, J.
2019-01-02 2019-01-03 2019-01-17 CE4-related: Restrictions on History-based
09:38:28 06:07:22 14:50:25 Motion Vector Prediction
Hong(Bytedance)
CE2-related: Early awareness of accessing L. Zhang, K. Zhang, H. Liu, J.
2019-01-02 2019-01-03 2019-01-03
JVET-M0273 m45539 temporal blocks in sub-block merge list Xu, Y. Wang, P. Zhao, D.
09:38:42 06:07:54 06:07:54
construction Hong(Bytedance)
M. Wang, K. Zhang, L.
2019-01-02 2019-01-03 2019-01-03 CE3-related: Modified linear model Zhang, H. Liu, J. Xu, S. Wang
JVET-M0274 m45540
09:38:54 06:37:08 06:37:08 derivation for CCLM modes (Bytedance), J. Li, S. Wang,
W. Gao (Peking Univ.),
2019-01-02 2019-01-02 2019-01-13
JVET-M0275 m45541 Non-CE6 : On transform skip conditions Choi, L. Li, J. Lim, S. Kim
09:39:03 11:58:24 16:21:26
(LGE)
J. Li, S. Wang, W. Gao
2019-01-02 2019-01-03 2019-01-06 CE10-related: MPM list alignment between (Peking Univ.), L. Zhang, K.
JVET-M0276 m45542
09:39:07 06:26:49 02:12:46 CIIP and intra mode Zhang, H. Liu, J. Xu
(Bytedance)
Non-CE: Fixes of enabling L. Zhang, K. Zhang, H. Liu, J.
2019-01-02 2019-01-03 2019-01-17
JVET-M0277 m45543 pcm_loop_filter_disabled_flag with PCM Xu, Y. Wang, P. Zhao, D.
09:39:20 06:08:38 09:46:58
mode signalling under dual tree partition Hong (Bytedance)
2019-01-02 2019-01-02 2019-01-12 Non-CE7 : Residual rearrangement for
09:39:32 13:05:55 18:02:34 transform skipped blocks
(LGE)
2019-01-02 2019-01-02 2019-01-12
JVET-M0279 m45545 Non-CE7 : Sign coding for transform skip Choi, L. Li, J. Lim, S. Kim
09:40:04 13:06:27 18:01:10
(LGE)
2019-01-02 2019-01-03 2019-01-09 CE6-related: Context selection for entropy S.-T. Hsiang, S.-M. Lei
JVET-M0280 m45546
10:45:49 00:38:51 16:43:14 coding the MTS flag (MediaTek)
A. Robert, F. Le Léannec, T.
2019-01-02 2019-01-02 2019-01-04 CE4: Inter motion predictor pruning (test
JVET-M0281 m45547 Poirier, F. Galpin
10:49:10 10:57:47 15:35:36 4.1.5)
(Technicolor)
2019-01-02 2019-01-02 2019-01-04 CE2: Affine motion predictor pruning (test
10:51:18 11:01:39 15:36:00 2.2.8)
(Technicolor)
2019-01-02 2019-01-02 2019-01-04 CE10-related: Reduction of motion
10:54:39 11:11:14 15:36:16 predictor pruning in Triangle Merge mode
(Technicolor)
2019-01-02 2019-01-02 2019-01-02 CE9-related: BDOF Modifications to H. Chen, X. Ma, S. Esenlik,
JVET-M0284 m45550
11:16:13 14:53:34 14:53:34 Enable 64x64 VPDU H. Yang, J. Chen (Huawei)
JVET-M0285 m45551 2019-01-02 2019-01-02 2019-01-02 CE1-related: Prediction Mode Restriction Y. Zhao, S. Esenlik, H. Yang,
11:20:19 14:54:14 14:54:14 and Implicit Transform Splitting to Enable J. Chen (Huawei)
Page: 358 Date Saved: 2019-03-172019-03-14

VPDU
2019-01-02 2019-01-03 2019-01-12 Non-CE4: Simplifications for triangular T. Solovyev, S. Esenlik, S.
JVET-M0286 m45552
11:24:09 03:36:38 18:01:23 prediction mode Ikonin, J. Chen (Huawei)
S. Esenlik, H. Gao, A. M.
2019-01-02 2019-01-02 2019-01-02
JVET-M0287 m45553 CE9: Integer DMVR (Test 9.2.7) Kotra, B. Wang, J. Chen
11:26:31 14:54:29 14:54:29
(Huawei)
2019-01-02 2019-01-02 2019-01-08 CE6: Fast DST-7/DCT-8 based on DFT M. Koo, M. Salehifar, J. Lim,
JVET-M0288 m45554
11:28:37 12:11:42 19:47:21 (test 6.2.1) S. Kim (LGE)
H. Gao, S. Esenlik, B. Wang,
2019-01-02 2019-01-02 2019-01-02 CE4: Parallel Merge Estimation for VVC
JVET-M0289 m45555 A. M. Kotra, J. Chen
11:28:58 16:55:08 16:55:08 (Test 4.3.2)
(Huawei)
2019-01-02 2019-01-02 2019-01-02 CE10: Simplification on Combined Inter- W. Xu, B. Wang, H. Yang, J.
JVET-M0290 m45556
11:31:02 21:56:49 21:56:49 Intra Prediction (Test 10.1.3) Chen (Huawei)
2019-01-02 2019-01-02 2019-01-10
JVET-M0291 m45557 CE4: Extension on MMVD (Test 4.2.5) X. Chen, J. Zheng (HiSilicon)
11:31:58 11:41:22 12:17:19
2019-01-02 2019-01-02 2019-01-12 CE6: Reduced Secondary Transform (RST) M. Koo, M. Salehifar, J. Lim,
JVET-M0292 m45558
11:32:40 13:17:11 23:37:18 (test 6.5.1) S. Kim (LGE)
W. Xu, B. Wang, H. Yang, J.
CE10: Simplification on Combined Inter-
2019-01-02 2019-01-02 2019-01-02 Chen (Huawei), M.-S. Chiang,
JVET-M0293 m45559 Intra Prediction with size restriction (Test
11:32:48 21:56:02 21:56:02 C.-W. Hsu, Y.-W. Huang, S.-
10.1.5)
M. Lei (MediaTek)
CE10-related: Modification for blocks B. Wang, A. M. Kotra, S.
2019-01-02 2019-01-02 2019-01-13
JVET-M0294 m45560 applied with Combined Inter-Intra Esenlik, H. Gao, J. Chen
11:33:53 21:37:26 22:08:05
prediction (Huawei)
B. Wang, S. Esenlik, A. M.
2019-01-02 2019-01-02 2019-01-11 CE3-related: Harmonization of MPM list
JVET-M0295 m45561 Kotra, H. Gao, J. Chen
11:34:25 17:46:57 09:54:05 construction
(Huawei)
B. Wang, S. Esenlik, A. M.
2019-01-02 2019-01-02 2019-01-13 CE10-related: Simplification on combined
JVET-M0296 m45562 Kotra, H. Gao, J. Chen
11:34:43 17:58:43 21:33:08 inter-intra mode prediction
(Huawei)
2019-01-02 2019-01-02 2019-01-14 CE6-related: 32 point MTS based on M. Koo, M. Salehifar, J. Lim,
JVET-M0297 m45563
11:35:12 13:43:11 13:18:31 skipping high frequency coefficients S. Kim (LGE)
A. M. Kotra, B. Wang, S.
2019-01-02 2019-01-02 2019-01-02 CE11: Longer tap deblocking filter (test
JVET-M0298 m45564 Esenlik, H. Gao, J. Chen
11:35:29 21:04:11 21:04:11 11.1.5)
(Huawei)
K. Andersson, Z.Zhang, R.
Sjöberg (Ericsson), A. M.
CE11: Deblocking for 4 x N, N x 4 blocks Kotra, J. Chen, S. Esenlik, B.
2019-01-02 2019-01-02 2019-01-10
JVET-M0299 m45565 and 8 x N, N x 8 blocks that are not aligned Wang, H. Gao (Huawei), C.-
11:35:47 21:05:12 14:18:49
with 8 x 8 sample grid (test 11.2.1) M. Tsai, C.-W. Hsu, T.-D.
Chuang, C.-Y. Chen, Y.-W.
A. M. Kotra, J. Chen, B.
2019-01-02 2019-01-03 2019-01-15 CE4-related: HMVP and parallel processing
JVET-M0300 m45566 Wang, S. Esenlik, H. Gao
11:36:13 08:53:09 12:58:05 with tiles and tile groups
(Huawei)
A. M. Kotra, S. Esenlik, B.
2019-01-02 2019-01-03 2019-01-13
JVET-M0301 m45567 Non-CE: Loop filter line buffer reduction Wang, H. Gao, J. Chen
11:36:45 08:53:34 11:30:36
(Huawei)
2019-01-02 2019-01-02 2019-01-02 CE2: Merge Mode with Regression-based R. Ghaznavi-Youvalari, A.
JVET-M0302 m45568
11:38:29 14:27:27 14:27:27 Motion Vector Field (Test 2.3.3) Aminlou, J. Lainema (Nokia)
2019-01-02 2019-01-02 2019-01-16 CE6: Shape adaptive transform selection
JVET-M0303 m45569 J. Lainema (Nokia)
11:40:07 13:47:17 11:47:02 (Test 3.1)
2019-01-02 2019-01-02 2019-01-12 CE6-related: 2-mode MTS with shape
11:40:39 13:47:52 10:40:28 adaptive transform selection
2019-01-02 2019-01-02 2019-01-16 CE7-related: Joint coding of chrominance
11:41:05 13:48:25 12:48:30 residuals
2019-01-02 2019-01-02 2019-01-06
JVET-M0306 m45572 CE9: DMVR Simplifications (Test 9.2.3) X. Chen, J. Zheng (HiSilicon)
11:43:06 11:45:51 16:03:29
2019-01-02 2019-01-03 2019-01-12 CE4-related : Candidates optimization on N. Park, H. Jang, J. Nam, J.
JVET-M0307 m45573
11:46:45 05:50:03 02:53:30 MMVD Lim, S. Kim (LGE)
2019-01-02 2019-01-02 2019-01-10
JVET-M0308 m45574 Non-CE4: MMVD simplification X. Chen, J. Zheng (HiSilicon)
11:48:31 11:50:47 21:08:21
2019-01-02 2019-01-02 2019-01-09 CE2: Memory bandwidth reduction for J. Li, R.-L. Liao, C. S. Lim
JVET-M0309 m45575
11:58:57 14:09:01 10:14:17 affine mode (test 2.4.2) (Panasonic)
2019-01-02 2019-01-02 2019-01-09 CE2-related: Using shorter-tap filter for 4x4 J. Li, R.-L. Liao, C. S. Lim
JVET-M0310 m45576
11:59:31 14:25:26 10:29:59 sized partition (Panasonic)
JVET-M0311 m45577 2019-01-02 2019-01-02 2019-01-09 CE2-related: Memory bandwidth reduction J. Li, R.-L. Liao, C. S. Lim
Page: 359 Date Saved: 2019-03-172019-03-14

11:59:55 14:26:35 10:19:42 for affine mode with less dependency (Panasonic)
2019-01-02 2019-01-02 2019-01-07 J. Li, R.-L. Liao, C. S. Lim
JVET-M0312 m45578 CE4: MMVD improvement (test 4.4.5)
12:00:49 14:34:55 06:58:16 (Panasonic)
CE4: Motion compensation constraints for
2019-01-02 2019-01-02 2019-01-08 R.-L. Liao, J. Li, C. S. Lim
JVET-M0313 m45579 complexity reduction (test 4.5.1 and test
12:01:37 12:32:48 07:59:31 (Panasonic)
4.5.2)
2019-01-02 2019-01-02 2019-01-09 CE4-related: MMVD improving with J. Li, R.-L. Liao, C. S. Lim
JVET-M0314 m45580
12:02:01 14:37:17 10:21:53 signalling distance table (Panasonic)
2019-01-02 2019-01-02 2019-01-09 J. Li, R.-L. Liao, C. S. Lim
JVET-M0315 m45581 Non-CE4: MMVD scaling simplification
12:02:20 14:40:19 19:16:39 (Panasonic)
2019-01-02 2019-01-02 2019-01-09 J. Li, R.-L. Liao, C. S. Lim
JVET-M0316 m45582 CE9-related: simplification of BDOF
12:02:43 14:02:31 10:24:01 (Panasonic)
2019-01-02 2019-01-02 2019-01-13 CE10-related: Simplification of triangular R.-L. Liao, J. Li, C. S. Lim
JVET-M0317 m45583
12:03:32 13:51:39 16:51:20 prediction unit mode (Panasonic)
2019-01-02 2019-01-02 2019-01-02 CE7-related: QP prediction and neighbour P. de Lagrange, P. Bordes
JVET-M0318 m45584
12:11:21 12:17:19 12:17:19 availability (Technicolor)
2019-01-02 2019-01-02 2019-01-10 J. Jung, D. Kim, G. Ko, J.
JVET-M0319 m45585 CE6: MTS for non-square CUs (test 6.3.3)
12:51:35 12:59:54 10:00:03 Son, J. Kwak (Wilus)
CE13: HEC with deblocking using
2019-01-02 2019-01-04 2019-01-04 spherical neighbours, SAO and ALF X. Huangfu, Y. Sun, L. Yu
JVET-M0320 m45586
13:01:19 09:35:00 09:35:00 disabled across face discontinuities (Test (Zhejiang Univ.)
1.4)
2019-01-02 2019-01-04 2019-01-04 CE13: Post-filtering of seam artefacts based X. Huangfu, Y. Sun, L. Yu
JVET-M0321 m45587
13:06:51 09:35:40 09:35:40 on test 1.1.a (Test 3.1) (Zhejiang Univ.)
CE13-related: In-loop filters disabled across
2019-01-02 2019-01-04 2019-01-13 Y. Sun, X. Huangfu, L. Yu
JVET-M0322 m45588 face discontinuities on PHEC with 2-pixel
13:09:44 09:48:15 09:50:14 (Zhejiang Univ.)
padding
2019-01-02 2019-01-05 2019-01-13 CE13-related: Adaptive QP to improve Y. Sun, X. Huangfu, L. Yu
JVET-M0323 m45589
13:14:53 03:38:11 09:50:45 subjective quality for PHEC (Zhejiang Univ.)
2019-01-02 2019-01-02 2019-01-02 CE3-related: Modified Chroma Intra Mode
JVET-M0324 m45590 J. Park, B. Jeon (SKKU)
13:16:35 19:43:42 19:43:42 Coding
2019-01-02
13:20:01
2019-01-02 2019-01-03 2019-01-09 CE8-related: Remove the redundancy of S. Ye, F. Chen, L. Wang
JVET-M0326 m45592
13:35:16 04:29:59 17:33:52 CPR-related syntax coding (Hikvision)
2019-01-02 2019-01-03 2019-01-13 S. Ye, F. Chen, L. Wang
JVET-M0327 m45593 CE8-related: A new CPR syntax scheme
13:38:26 04:30:14 11:10:06 (Hikvision)
2019-01-02 2019-01-03 2019-01-16 CE10-related: Simplified triangle prediction
JVET-M0328 m45594 F. Chen, L. Wang (Hikvision)
13:39:36 04:29:49 11:01:19 unit mode
2019-01-02 2019-01-03 2019-01-13 CE10-related: Modified enabling condition
13:40:00 04:05:22 18:09:24 for triangle prediction unit mode
2019-01-02 2019-01-03 2019-01-15 CE4-related: Simplification of candidate list L. Xu, F. Chen, L. Wang
JVET-M0330 m45596
13:49:38 03:14:37 10:32:37 derivation for MMVD mode (Hikvision)
CE10-related:A simplification of inter
2019-01-02 2019-01-03 2019-01-13 L. Xu, F. Chen, L. Wang
JVET-M0331 m45597 prediction information derivation for multi-
13:49:40 03:18:15 16:43:08 (Hikvision)
intra-inter mode
2019-01-02 2019-01-03 2019-01-09 CE8: Block vector prediction for CPR (test
JVET-M0332 m45598 J. Nam, J. Lim, S. Kim (LGE)
14:17:42 06:15:35 16:21:28 8.1.1a and test 8.1.1b)
2019-01-02 2019-01-03 2019-01-13 Non-CE8: Coding on block vector
14:18:06 06:16:22 16:09:23 difference
2019-01-02 2019-01-03 2019-01-09 Non-CE8: Removal of redundant syntax
14:18:21 06:17:02 19:55:15 between CPR and other inter coding tools
2019-01-02 2019-01-03 2019-01-11 Non-CE8: modification on SbTMVP H. Jang, J. Nam, S. Kim, J.
JVET-M0335 m45602
14:20:22 05:42:17 16:30:39 process regarding with CPR Lim (LGE)
2019-01-02 2019-01-03 2019-01-14 Non-CE11: Considering boundary strength H. Jang, J. Nam, S. Kim, J.
JVET-M0336 m45603
14:22:38 05:42:44 17:43:04 on CPR coded block boundary Lim (LGE)
2019-01-02 2019-01-03 2019-01-03 CE11: Test CE11.2.1 Parallel deblocking H. Jang, J. Nam, S. Kim, J.
JVET-M0337 m45604
14:23:26 05:43:13 05:43:13 filter Lim (LGE)
JVET-M0338 m45605 2019-01-02 2019-01-03 2019-01-03 Non-CE2 : Simplified neighbouring spatial H. Jang, J. Nam, S. Kim, J.
14:24:15 05:43:35 09:06:04 coding unit derivation for SbTMVP Lim (LGE)
2019-01-02 2019-01-03 2019-01-14 CE11-related: subblock boundary filter at H. Jang, J. Nam, S. Kim, J.
JVET-M0339 m45606
14:25:29 05:43:56 17:43:20 8x8 Grid Lim (LGE)
2019-01-02 2019-01-03 2019-01-11 CE6-relatedï¼šSimplification on MTS for X. Cao, F. Chen, L.Wang
JVET-M0340 m45607
14:26:16 04:31:14 23:05:12 intra residual coding (Hikvision)
2019-01-02 2019-01-03 2019-01-11 Non-CE8: MMVD harmonization with H. Jang, J. Nam, S. Kim, J.
JVET-M0341 m45608
14:26:32 05:44:18 18:09:16 CPR Lim (LGE)
Page: 360 Date Saved: 2019-03-172019-03-14

2019-01-02 2019-01-02 2019-01-02 Crosscheck of JVET-M0083 (AHG10:
JVET-M0342 m45609 M. Ikeda (Sony)
14:27:14 14:33:48 14:33:48 Quantization matrices for MTS)
2019-01-02 2019-01-03 2019-01-14 Non-CE2 : Simplified subblock motion H. Jang, J. Nam, S. Kim, J.
JVET-M0343 m45610
14:27:38 05:44:44 18:56:13 derivation for SbTMVP Lim (LGE)
2019-01-02 2019-01-03 2019-01-03 Crosscheck of JVET-M0089 (Non-CE5:
JVET-M0344 m45611 R. Hashimoto (Renesas)
14:29:26 00:54:29 01:45:45 CABAC skip mode for super low delay)
S.H. Wang (Peking
2019-01-02 2019-01-03 2019-01-17 CE4-related: Remove redundancy between
JVET-M0345 m45612 Univerisity), X. Zheng (DJI),
14:30:59 07:09:55 17:43:53 TMVP and ATMVP
S.S. Wang, S.W. Ma
S.H. Wang (Peking
2019-01-02 2019-01-03 2019-01-07 CE4-related: Non-square compression unit
JVET-M0346 m45613 Univerisity), X. Zheng (DJI),
14:31:03 07:14:06 15:19:24 for temporal motion data storage
S.S. Wang, S.W. Ma
2019-01-02 2019-01-03 2019-01-14 CE6-related: Simplification on MTS CU X. Cao, F. Chen, L. Wang
JVET-M0347 m45614
14:33:30 04:32:12 17:19:12 flag coding (Hikvision)
CE2/4-related: Further reducing VVC
X.W. Meng (Peking Univ.),
2019-01-02 2019-01-03 2019-01-19 memory bandwidth worst case by
JVET-M0348 m45615 X. Zheng (DJI), S.S. Wang,
14:33:54 07:42:28 23:07:46 combining 4x4/4x8/8x4 bi-prediction with
S.W. Ma
AMVR
X.W. Meng (Peking Univ.),
2019-01-02 2019-01-03 2019-01-15 CE10-related: Simplification of triangle
JVET-M0349 m45616 X. Zheng (DJI), S.S. Wang,
14:36:27 11:40:52 00:26:32 prediction merging candidate list derivation
S.W. Ma
T.L. Fu (Peking Univ.), X.
2019-01-02 2019-01-03 2019-01-07 CE4-related: CE4-related: Quadtree-based
JVET-M0350 m45617 Zheng (DJI), S.S Wang, S.W.
14:38:50 08:46:41 15:28:55 Merge Estimation Region for VVC
Ma
2019-01-02 2019-01-03 2019-01-05 AHG9: Convolutional Neural Network C. Lin, J. Yao, L. Wang
JVET-M0351 m45618
14:51:30 05:12:09 05:09:27 Filter (CNNF) for Intra Frame (Hikvision)
D. Park, Y. Yoon, J.-G. Kim
2019-01-02 2019-01-02 2019-01-12 CE10-related: Simplification of triangular
JVET-M0352 m45619 (KAU), J. Lee, J. Kang
14:57:40 15:01:34 09:23:33 partitions
(ETRI)
2019-01-02 2019-01-02 2019-01-11 No-CE: Simplification of ALF coefficients
JVET-M0353 m45620 M. Ikeda, T. Suzuki (Sony)
14:59:44 15:13:26 15:38:15 merge
2019-01-02 2019-01-03 2019-01-13 CE6-related: MTS with Haar transform for K. Naser, F. Galpin, T. Poirier
JVET-M0354 m45621
15:01:48 10:39:10 11:23:58 Screen Contents Coding (Technicolor)
2019-01-02 2019-01-02 2019-01-05
JVET-M0355 m45623 CE13: Results on CE13.2.2 and CE13.5.2 J. Sauer, M. Bläser
15:24:49 15:31:30 15:28:44
A. Filippov, X. Ma, V.
2019-01-02 2019-01-03 2019-01-10 CE3-related: simplified calculation for
JVET-M0356 m45622 Rufitskiy, H. Yang, J. Chen
15:03:50 01:59:27 09:06:40 CCLM parameters derivation
(Huawei)
CE10-related: Reduction of the worst-case
2019-01-02 2019-01-02 2019-01-13 Y. Kidani, K. Kawamura, K.
JVET-M0357 m45624 memory bandwidth and operation number
15:32:54 15:43:17 08:46:35 Unno, S. Naito (KDDI)
of OBMC
2019-01-02 2019-01-02 2019-01-15 CE3-related: disabling PDPC based on
JVET-M0358 m45625 V. Drugeon (Panasonic)
15:34:03 15:40:47 12:28:08 availability of reference samples
2019-01-02 2019-01-02 2019-01-11 Non-CE4: Modification of merge data G. Ko, D. Kim, J. Jung, J.
JVET-M0359 m45626
15:40:53 15:43:21 15:49:29 syntax Son, J. Kwak (Wilus)
H. Yu, X. Gao, Q. Yuan, X.
2019-01-02 2019-01-04 2019-01-14 Video coding based on cross RAP Lin, L. Yu (Zhejiang Univ.),
JVET-M0360 m45627
15:41:37 04:43:58 19:23:42 referencing (CRR) Y. Fan, Y. Zhao, H. Yang, Y.-
K. Wang, J. Chen (Huawei)
Non-CE6: Mismatch between text
2019-01-02 2019-01-02 2019-01-10 J. Jung, D. Kim, G. Ko, J.
JVET-M0361 m45628 specification and reference software on the
15:45:18 15:46:48 13:08:26 Son, J. Kwak (Wilus)
signalling root CBF
S.-Y. Lin, L. Liu, J.-L. Lin,
2019-01-02 2019-01-03 2019-01-09 CE13: In-loop filters disabled across face Y.-C. Chang, C.-C. Ju
JVET-M0362 m45630
15:51:05 03:20:15 21:33:53 discontinuities (Test 1.1.a and Test1.1.b) (MediaTek), P. Hanhart, Y.
He (InterDigital)
2019-01-02 2019-01-03 2019-01-03 CE13: HEC with in-loop filters using
JVET-M0363 m45632 Y.-C. Chang, C.-C. Ju
15:53:05 03:20:52 03:20:52 spherical neighbours (Test 1.3)
(MediaTek)
CE13: Test 1.1.a with face row based
2019-01-02 2019-01-03 2019-01-03 C.-H. Shih, J.-L. Lin, Y.-C.
JVET-M0364 m45633 geometry padding of reference pictures
15:54:40 03:24:20 03:24:20 Chang, C.-C. Ju (MediaTek)
(Test 2.1.a, Test 2.1.c and Test 2.1.d)
2019-01-02 2019-01-03 2019-01-08 Non-CE3: modified PDPC for horizontal A. Filippov, V. Rufitskiy, J.
JVET-M0365 m45634
15:55:51 01:41:21 00:52:43 and vertical modes Chen (Huawei)
C. Hollman, D. Saffar, P.
2019-01-02 2019-01-02 2019-01-15
JVET-M0366 m45635 CE-6 related: Transform Simplification Wennersten, J. Ström
15:56:49 17:55:45 17:05:19
(Ericsson)
Page: 361 Date Saved: 2019-03-172019-03-14

CE13: Face row based geometry padding of C.-H. Shih, S.-Y. Lin, L. Liu,
2019-01-02 2019-01-03 2019-01-03
JVET-M0367 m45636 reference pictures and in-loop filters using J.-L. Lin, Y.-C. Chang, C.-C.
15:57:06 03:46:57 03:46:57
spherical neighbours (Test 5.1) Ju (MediaTek)
C.-H. Shih, Y.-H. Lee, J.-L.
2019-01-02 2019-01-03 2019-01-03 AHG8: 360Lib support for chroma sample
JVET-M0368 m45637 Lin, Y.-C. Chang, C.-C. Ju
15:58:50 04:00:54 04:00:54 location in PHEC blending process
(MediaTek)
2019-01-02 2019-01-04 2019-01-11 Y. Ahn, D. Sim (Digital
JVET-M0369 m45638 CE4-related: Syntax changes of merge data
15:59:18 07:08:39 11:11:08 Insights)
2019-01-02
16:00:10
2019-01-02 2019-01-04 2019-01-04 Crosscheck of JVET-M0088 (CE10-related:
JVET-M0371 m45640 P. Bordes (Technicolor)
16:04:49 15:22:10 15:22:10 LIC restriction for pipeline structure)
2019-01-02 2019-01-02 2019-01-10 CE6: Fast DST-7/DCT-8 based on DFT and K. Naser, E. François, F. Le
JVET-M0372 m45642
16:24:08 18:57:35 15:55:42 matrix multiplication (test 6.2.2) Léannec (Technicolor)
2019-01-02 2019-01-03 2019-01-03 AHG12: Merge friendly tile group address R. Sjöberg, M. Damghanian,
JVET-M0373 m45643
16:25:20 08:12:04 08:12:04 signalling M. Pettersson (Ericsson)
2019-01-02 2019-01-03 2019-01-04 AHG12: Flexible tiles to support MCTS use R. Sjöberg, M. Damghanian,
JVET-M0374 m45644
16:25:23 08:30:14 13:25:23 cases M. Pettersson (Ericsson)
2019-01-02 2019-01-03 2019-01-03 M. Damghanian, R. Sjöberg,
JVET-M0375 m45645 AHG12: On uniform tile spacing
16:25:25 08:07:45 08:07:45 M. Pettersson (Ericsson)
2019-01-02 2019-01-03 2019-01-04 M. Damghanian, R. Sjöberg,
JVET-M0376 m45646 AHG12: On signalling of flexible tiles
2019-01-02 2019-01-03 2019-01-12 R. Sjöberg, M. Damghanian,
JVET-M0377 m45647 AHG17: Picture header NAL unit type
2019-01-02 2019-01-03 2019-01-03 R. Sjöberg, M. Damghanian,
JVET-M0378 m45648 AHG17: RPS for VVC
2019-01-02 2019-01-02 2019-01-10 CE6-related: Further Simplification on top K. Naser, E. François, F. Le
JVET-M0379 m45649
16:26:51 19:00:12 09:38:44 of CE6-2.2 Léannec (Technicolor)
2019-01-02 2019-01-02 2019-01-02 G. Laroche, C. Gisquet, P.
JVET-M0380 m45650 CE2: Affine Merge flag coding (Test 2.2.1)
16:32:57 17:33:23 17:33:23 Onno, J. Taquet (Canon)
2019-01-02 2019-01-02 2019-01-02 CE2: On Subblock Merge index coding G. Laroche, C. Gisquet, P.
JVET-M0381 m45651
16:33:08 17:14:54 17:14:54 (Test CE2.2.2) Onno, J. Taquet (Canon)
2019-01-02 2019-01-02 2019-01-02 CE2-related: Modification of Triangle and G. Laroche, C. Gisquet, P.
JVET-M0382 m45652
16:33:19 17:44:15 17:44:15 MMVD merge indexes coding Onno, J. Taquet (Canon)
2019-01-02 2019-01-02 2019-01-02 Non-CE3: Table size reduction and bit P. Onno, C. Gisquet, G.
JVET-M0383 m45653
16:33:29 18:51:41 18:51:41 width limitation for CCLM implementation. Laroche, J. Taquet (Canon)
2019-01-02 2019-01-02 2019-01-10 C. Gisquet, G. Laroche, P.
JVET-M0384 m45654 Non-CE3: LM in the middle
16:33:40 18:26:04 14:48:38 Onno, J. Taquet (Canon)
2019-01-02 2019-01-02 2019-01-12 J. Taquet, C. Gisquet, G.
JVET-M0385 m45655 Non-linear Adaptive Loop Filter
16:33:50 20:50:18 12:58:10 Laroche, P. Onno (Canon)
2019-01-02 2019-01-02 2019-01-02 K. Sühring, Y. Sanchez, R.
JVET-M0386 m45656 AHG17: On slice_type (tile_group_type)
16:37:28 19:20:16 19:20:16 Skupin (HHI)
2019-01-02 2019-01-11 2019-01-16 J.-M. Thiesse, D. Gommelet,
JVET-M0387 m45657 AHG14: Updates on Intra Refresh Proposal
16:44:27 14:50:37 14:46:45 D. Nicholson (VITEC)
2019-01-02 2019-01-02 2019-01-02 AHG12/AHG17: On merging of MCTSs
JVET-M0388 m45658 M. M. Hannuksela (Nokia)
17:26:20 21:19:34 21:19:34 for viewport-dependent streaming
H. Kirchhoffer, C. Bartnik, P.
CE5-related: Minor optimizations for Haase, T. Hinz, S. Matlage, B.
2019-01-02 2019-01-02 2019-01-10
JVET-M0389 m45659 increasing the throughput of CE5.1.5 and Stabernack, J. Stegemann, D.
17:27:57 17:38:24 13:06:05
CE5.1.6 Marpe, H. Schwarz, T.
Wiegand (HHI)
2019-01-02 2019-01-02 2019-01-10 CE-10: related multi-hypothesis with uni- T. Poirier, E. François, K.
JVET-M0390 m45661
17:29:49 18:10:29 12:45:18 directional inter prediction restriction Naser (Technicolor)
M. Abdoli, E. Mora, T.
2019-01-02 2019-01-02 2019-01-02 CE3-related: Improvements on the
JVET-M0391 m45662 Guionnet, M. Raulet
17:30:16 17:39:49 17:39:49 Decoder-side Intra Mode Derivation
(ATEME)
2019-01-02 2019-01-03 2019-01-03 Non-CE3: Extended Mode-Dependent Intra A. Filippov, V. Rufitskiy, J.
JVET-M0392 m45660
17:28:31 01:07:13 01:07:13 Smoothing Chen (Huawei)
2019-01-02 2019-01-02 2019-01-11 Non-CE8: chroma block vector T. Poirier, F. Le Léannec, F.
JVET-M0393 m45663
17:30:41 18:36:54 16:18:26 initialization for CPR in dual tree Galpin (Technicolor)
Crosscheck of JVET-M0067 (Non-CE4:
2019-01-02 2019-01-07 2019-01-11
JVET-M0394 m45664 Weighted prediction with BDOF and bi- P. Bordes (Technicolor)
17:48:46 12:15:47 10:44:30
prediction with CU weights harmonization)
CE5-related: Alternative implementation of P. Haase, H. Kirchhoffer, S.
2019-01-02 2019-01-02 2019-01-02
JVET-M0395 m45665 CABAC range sub-interval derivation for Matlage, H. Schwarz, D.
17:58:49 18:01:47 18:01:47
CE5.1.5, CE5.1.6 and CE5.1.7 Marpe, T. Wiegand (HHI)
Page: 362 Date Saved: 2019-03-172019-03-14

S. Shrestha, A. Kumar, B. Lee
2019-01-02 2019-01-03 2019-01-09 CE6-related: MTS kernel derivation for
JVET-M0396 m45666 (Chosun Univ), Y. Lee, J.
18:11:19 03:57:08 20:35:05 efficient memory usage
Park (Humax)
S. Shrestha, A. Kumar, B. Lee
2019-01-02 2019-01-03 2019-01-10 CE6-related: DST-3 based transform
JVET-M0397 m45667 (Chosun Univ., Y. Lee, J. Park
18:15:06 08:17:51 13:21:21 kernels derivation
(Humax)
2019-01-02 2019-01-02 2019-01-02 CE6-related Further simplification of CE6-
JVET-M0398 m45668 P. Philippe (bcom Orange)
18:15:57 18:51:02 18:51:02 1.5
H. Wang, W.-J. Chien, V.
2019-01-02 2019-01-03 2019-01-14 CE10-related: Modifications of Triangular Seregin, Y.-H. Chao, H.
JVET-M0399 m45671
18:20:54 04:31:20 01:05:27 PU Mode Huang, M. Karczewicz
(Qualcomm)
W.-J. Chien, L. Pham Van, H.
2019-01-02 2019-01-02 2019-01-11 CE2-related: Worst-case memory
JVET-M0400 m45672 Huang, V. Seregin, M.
18:35:07 19:14:48 09:00:02 bandwidth reduction for VVC
CE3: Classification-based mean value for X. Ma, A. Filippov, V.
2019-01-02 2019-01-03 2019-01-04
JVET-M0401 m45670 CCLM coefficients derivation (tests 2.5.1- Rufitskiy, H. Yang, J. Chen
18:20:38 00:39:52 14:00:38
2.5.4) (Huawei)
2019-01-02 2019-01-02 2019-01-04 Non-CE8: Comments on Current Picture B. Heng, M. Zhou, W. Wan
JVET-M0402 m45674
18:44:01 22:33:33 18:11:39 Referencing (Broadcom)
CE4: Generic Vector Coding of Motion
2019-01-02 2019-01-02 2019-01-04 S. Paluri, M. Salehifar, S. Kim
JVET-M0403 m45675 Vector Difference (Tests 4.4.1.a and
19:01:43 22:43:50 19:26:07 (LGE)
4.4.1.b)
2019-01-02 2019-01-03 2019-01-03 CE4: History based spatial-temporal MV
JVET-M0404 m45676 X. Xu, X. Li, S. Liu (Tencent)
19:16:12 05:21:15 05:21:15 prediction (Test 4.2.4)
2019-01-02 2019-01-03 2019-01-03 CE4-related: Simplified merge candidate
19:16:30 07:03:01 07:03:01 list for small blocks
2019-01-02 2019-01-03 2019-01-03 CE2/4-related: Unified merge list size for
19:16:42 07:04:13 07:04:13 block and sub-block merge modes
CE8: CPR reference memory reuse without
2019-01-02 2019-01-03 2019-01-17 X. Xu, X. Li, S. Liu
JVET-M0407 m45679 increasing memory requirement (CE8.1.2a
19:16:55 05:22:20 02:13:09 (Tencent), E. Chai (Ubilinx)
and CE8.1.2d)
CE8: CPR reference memory reuse with
2019-01-02 2019-01-03 2019-01-17 X. Xu, X. Li, S. Liu
JVET-M0408 m45680 reduced memory requirement (CE8.1.2b
19:17:07 05:23:34 02:15:05 (Tencent), E. Chai (Ubilinx)
and CE8.1.2c)
Non-CE8: Mismatch between text
X. Xu, X. Li, S. Liu
2019-01-02 2019-01-03 2019-01-11 specification and reference software on
JVET-M0409 m45681 (Tencent), W.-J. Chien, M.
19:17:25 07:05:27 16:37:10 ATMVP candidate derivation when CPR is
enabled
2019-01-02 2019-01-03 2019-01-11
JVET-M0410 m45682 Non-CE8: CPR flag signalling at slice level X. Xu, X. Li, S. Liu (Tencent)
19:17:41 07:06:32 16:37:50
Non-CE8: Inter mode related flag signalling
2019-01-02 2019-01-03 2019-01-11
JVET-M0411 m45683 when current picture is the only reference X. Xu, X. Li, S. Liu (Tencent)
19:17:54 07:07:52 16:38:09
picture
A. Said, J. Dong, H. Egilmez,
2019-01-02 2019-01-02 2019-01-10 CE5: Per-context CABAC initialization
JVET-M0412 m45685 Y.-H. Chao, M. Karczewicz,
19:21:44 19:44:45 19:12:49 with double windows (Test 5.1.3)
V. Seregin (Qualcomm)
A. Said, J. Dong, H. Egilmez,
2019-01-02 2019-01-02 2019-01-10 CE5: Per-context CABAC initialization
JVET-M0413 m45686 Y.-H. Chao, M. Karczewicz,
19:22:33 19:45:31 19:13:25 with single window (Test 5.1.4)
V. Seregin (Qualcomm)
2019-01-02
19:32:15
2019-01-02 2019-01-03 2019-01-03 AHG17: Comments on High-Level Syntax
JVET-M0415 m45688 S Deshpande (Sharp)
19:32:24 03:30:37 03:30:37 of VVC
2019-01-02 2019-01-03 2019-01-04
JVET-M0416 m45689 AHG12: On Tile Information Signalling S. Deshpande (Sharp)
19:33:34 03:28:16 07:38:12
2019-01-02 2019-01-03 2019-01-11 CE8-related: Combination test of CE8.2.2
19:53:06 04:18:31 19:25:23 and CE8.2.5
JVET-M0418 m45691 2019-01-02 2019-01-03 2019-01-12 CE8-related: Context modeling on Y.-C. Sun, J. Lou (Alibaba)
19:54:44 04:22:18 15:23:01 pred_mode_flag when current picture is the
only reference picture (CPR)
2019-01-02 2019-01-03 2019-01-03 CE8-related: Context modeling on palette
19:55:13 04:25:00 04:25:02 mode flag
2019-01-02 2019-01-03 2019-01-03 CE2: Adaptive precision for affine MVD J. Luo, Y. He, X. Xiu
JVET-M0420 m45693
19:55:18 06:10:01 06:10:01 coding (Test 2.1.1) (InterDigital)
JVET-M0421 m45694 2019-01-02 2019-01-02 2019-01-13 Non-CE1: Split-first signalling for A. Wieckowski, T. Nguyen,
20:04:10 20:08:16 09:04:49 partitioning H. Schwarz, D. Marpe, T.
Page: 363 Date Saved: 2019-03-172019-03-14

Wiegand (HHI
2019-01-02 2019-01-02 2019-01-02 X. Li, X. Xu, X. Zhao, S. Liu
JVET-M0422 m45695 CE4-related: Simplified MVD coding
20:18:46 20:28:02 20:28:02 (Tencent)
2019-01-02 2019-01-02 2019-01-02 Cross-check of JVET-M0066: AHG12:
JVET-M0423 m45696 A. Wieckowski (HHI)
20:22:06 20:24:14 20:24:14 Flexible Tile Partitioning
2019-01-02 2019-01-02 2019-01-12 CE10-related: On enhancement of 4-tap
JVET-M0424 m45697 M. Sychev, J. Chen (Huawei)
21:52:27 22:13:22 14:16:03 interpolation filters
2019-01-02 2019-01-03 2019-01-07 CE10: Multi-hypothesis inter prediction M. Winken, H. Schwarz, D.
JVET-M0425 m45698
21:57:04 09:41:52 18:25:27 (Test 10.1.2) Marpe, T. Wiegand (HHI)
S. De-Luxán-Hernández, V.
2019-01-02 2019-01-02 2019-01-02 CE3-related: Improvement on the Intra George, J. Ma, T. Nguyen, H.
JVET-M0426 m45699
21:58:52 22:03:56 22:03:56 Sub-Partitions Coding Mode Schwarz, D. Marpe, T.
Wiegand (HHI)
T. Lu, F. Pu, P. Yin, W.
2019-01-02 2019-01-03 2019-01-15 CE12: Mapping functions (test CE12-1 and
JVET-M0427 m45700 Husak, S. McCarthy, T. Chen
21:59:39 00:31:50 10:08:51 CE12-2)
(Dolby)
N. Hu, V. Seregin, W.-J.
2019-01-02 2019-01-02 2019-01-12
JVET-M0428 m45701 Encoder optimization with deblocking filter Chien, M. Karczewicz
22:08:59 22:14:53 15:20:52
(Qualcomm)
N. Hu, V. Seregin, H.
2019-01-02 2019-01-02 2019-01-13
JVET-M0429 m45702 Coding tree block based adaptive loop filter Egilmez, M. Karczewicz
22:09:04 22:18:10 13:52:54
(Qualcomm)
2019-01-02 2019-01-02 2019-01-02 R. Skupin, K. Sühring, Y.
JVET-M0430 m45703 AHG12: On Tiles and Tile Groups for VVC
22:12:06 22:13:44 22:13:44 Sanchez, T. Schierl (HHI)
2019-01-02 2019-01-02 2019-01-11 CE2: Affine merge with prediction offset G. Li, X. Xu, X. Li, S. Liu
JVET-M0431 m45704
22:14:35 22:59:52 18:55:50 (Test CE2.2.4) (Tencent)
CE2-related: Combination of CE2.2.3.d and G. Li, X. Xu, X. Li, S. Liu
2019-01-02 2019-01-02 2019-01-11
JVET-M0432 m45705 affine inheritance from motion data line (Tencent), J. Zhao, S. Kim
22:14:40 23:01:47 00:50:17
buffer (LGE)
2019-01-02 2019-01-02 2019-01-02 CE4-related: Constraint on GBi index G. Li, X. Xu, X. Li, S. Liu
JVET-M0433 m45706
22:14:43 23:02:22 23:02:22 inheritance in Merge Mode (Tencent)
2019-01-02 2019-01-02 2019-01-12 CE2-related: Constraint on constructed G. Li, X. Xu, X. Li, S. Liu
JVET-M0434 m45707
22:14:50 23:07:10 12:23:52 affine merge candidates (Tencent)
2019-01-02 2019-01-02 2019-01-12 G. Li, X. Xu, X. Li, S. Liu
JVET-M0435 m45708 CE4-related: MMVD offset table signalling
22:14:57 23:08:08 12:28:47 (Tencent)
2019-01-02 2019-01-02 2019-01-11
JVET-M0436 m45709 AHG2: Regarding HMVP Table Size J. Zhao, S. Kim (LGE)
22:20:12 23:11:09 00:48:40
2019-01-02 2019-01-02 2019-01-12
JVET-M0437 m45710 Non-CE4: Size constraint on MMVD J. Zhao, S. Kim (LGE)
22:22:37 23:16:12 10:29:52
2019-01-02 2019-01-02 2019-01-08 CE10-related: Size constraint on Triangular
JVET-M0438 m45711 J. Zhao, S. Kim (LGE)
22:23:42 23:37:54 02:39:56 Prediction
2019-01-02 2019-01-10 2019-01-10
JVET-M0439 m45712 DM-dependent chroma intra prediction H. Liu (Bytedance)
22:42:33 16:03:14 16:03:14
modes)
JVET-M0440 m45713 L. Zhang (Bytedance)
22:51:05 00:32:09 00:32:09 Simplified MVD coding)
2019-01-02 2019-01-05 2019-01-17
JVET-M0441 m45714 A restriction on memory bandwidth K. Zhang (Bytedance)
22:51:52 01:38:06 10:43:16
consumption of affine mode)
2019-01-02 2019-01-14 2019-01-14
JVET-M0442 m45715 Intra chroma partitioning and prediction K. Zhang (Bytedance)
22:52:22 19:33:57 19:33:57
restriction)
2019-01-02 2019-01-10 2019-01-10
JVET-M0443 m45716 History-based intra most probable modes J. Li, L. Zhang (Bytedance)
22:53:03 21:23:42 21:23:42
derivation)
2019-01-02 2019-01-03 2019-01-15 CE4-related: Simplified symmetric MVD
JVET-M0444 m45717 J. Luo, Y. He (InterDigital)
23:02:13 06:43:31 10:22:16 based on CE4.4.3
JVET-M0445 m45718 2019-01-02 2019-01-02 2019-01-13 AHG12: On motion constrained tiles for R. Skupin, V. George, K.
23:02:43 23:07:05 15:36:42 VVC Suehring, Y. Sanchez, T.
Schierl (HHI)
2019-01-02 2019-01-03 2019-01-12 CE1: Rectangular virtual pipeline data unit
JVET-M0446 m45719 M. Xu, X. Li, S. Liu (Tencent)
23:05:53 02:35:22 18:33:46 (test 1.1.1) and supplementary results
2019-01-02 2019-01-03 2019-01-03 CE9: Constrained intra prediction with
23:06:07 02:36:36 02:36:36 DMVR (test 9.2.4)
2019-01-02 2019-01-03 2019-01-03 CE4-related: Triangle merge index
23:06:20 02:37:46 02:37:46 signalling
Page: 364 Date Saved: 2019-03-172019-03-14

2019-01-02 2019-01-03 2019-01-03 CE8-related: BDPCM entropy coding with M. Xu, X. Li, X. Xu, M. Gao,
JVET-M0449 m45722
23:06:31 02:38:13 02:38:13 reduced number of context coded bins S. Liu (Tencent)
2019-01-02 2019-01-03 2019-01-14 CE10-related: LIC inheritance restrictions M. Xu, X. Li, X. Xu, S. Liu
JVET-M0450 m45723
23:06:43 02:38:55 20:26:43 and interaction with GBI (Tencent)
2019-01-02 2019-01-03 2019-01-03 AHG15: Update to interoperability point
JVET-M0451 m45724 J. Boyce (Intel)
23:07:19 01:16:22 01:16:22 syntax
2019-01-02 2019-01-03 2019-01-04 AHG8: Hemisphere cubemap projection J. Boyce, M. Dmytrychenko
JVET-M0452 m45725
23:07:21 23:12:56 23:03:47 format (Intel)
CE5 on arithmetic coding: experiments
2019-01-02 2019-01-03 2019-01-17 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6, 5.1.7,
JVET-M0453 m45726 F. Bossen (Sharp)
23:13:43 05:03:28 13:38:47 5.1.8, 5.1.10, 5.1.11, 5.1.12, 5.1.13, 5.2, and
more
2019-01-02 2019-01-02 2019-01-13 CE10-related: Multi-Hypothesis Intra with A. Seixas Dias, G. Kulupana,
JVET-M0454 m45727
23:18:47 23:30:35 16:58:42 Weighted Combination S. Blasi (BBC)
2019-01-02 2019-01-03 2019-01-08 CE8: Palette index map scan order J. Ye, X. Xu, M. Xu, X. Li, S.
JVET-M0455 m45728
23:20:24 02:56:53 08:45:18 constraints (Test 8.2.3) Liu (Tencent)
2019-01-02 2019-01-03 2019-01-08 CE8: palette mode when dual-tree is J. Ye, X. Xu, X. Li, S. Liu
JVET-M0456 m45729
23:20:31 02:57:37 08:46:05 enabled (Test 8.2.4) (Tencent)
2019-01-02 2019-01-03 2019-01-08 CE8: Palette predictor list enhancement J. Ye, X. Xu, M. Xu, X. Li, S.
JVET-M0457 m45730
23:20:36 02:58:07 08:46:41 (Test 8.2.6) Liu (Tencent)
2019-01-02 2019-01-02 2019-01-10 Non-CE3: Combined-Hypothesis Intra- G. Kulupana, A. Seixas Dias,
JVET-M0458 m45731
23:21:23 23:37:21 16:41:10 Prediction S. Blasi (BBC)
2019-01-02 2019-01-02 2019-01-12 R. Skupin, K. Sühring, Y.
JVET-M0459 m45732 AHG12: On tiles with partial CTUs
23:22:11 23:24:03 20:43:30 Sanchez, T. Schierl (HHI)
23:42:21 00:01:58 00:01:58 ATMVP simplification)
2019-01-02 2019-01-03 2019-01-08
JVET-M0461 m45735 Alternate ALF filter shapes for luma D. Socek, A. Puri (Intel)
23:50:01 07:00:49 23:07:20
CE2-related: 4x4 chroma affine motion L. Pham Van, W.-J. Chien, H.
2019-01-02 2019-01-03 2019-01-05
JVET-M0462 m45736 compensation and motion vector rounding Huang, V. Seregin, M.
23:51:12 04:50:07 23:04:41
unification Karczewicz (Qualcomm)
2019-01-03 2019-01-03 2019-01-03 CE5: Report of throughput analysis of CE5 J. Dong, A. Said, V. Seregin,
JVET-M0463 m45737
00:06:51 02:36:48 02:36:48 contributions (CE5.2) M. Karczewicz (Qualcomm)
Non-CE8: Unified Transform Type B. Bross, T. Nguyen, P.
2019-01-03 2019-01-03 2019-01-15
JVET-M0464 m45739 Signalling and Residual Coding for Keydel, H. Schwarz, D.
00:42:48 01:01:37 17:54:52
Transform Skip Marpe, T. Wiegand (HHI)
2019-01-03 2019-01-03 2019-01-03 Cross-check of JVET-M0046: CE6-related: S. Bandyopadhyay
JVET-M0465 m45740
00:42:53 07:29:36 07:29:36 A study of primary transforms (InterDigital)
M. Afonso, A. Norkin, A.
Aaron, J. Sole, K. Swanson
2019-01-03 2019-01-03 2019-01-14 Adaptive Streaming Test Conditions for (Netflix), Y. Ye, W. Jiang
JVET-M0466 m45741
00:54:22 03:24:22 21:19:33 VTM (Alibaba), J. Kim, K. Kolarov,
D. Singer, A. Tourapis
(Apple)
2019-01-03 2019-01-03 2019-01-12 CE2-related: Symmetric MVD for Affine
JVET-M0467 m45743 J. Luo, Y. He (InterDigital)
01:05:54 07:36:58 17:43:06 Bi-prediction Coding
2019-01-03 2019-01-03 2019-01-13 S. Ikonin, V. Stepin, J. Chen
JVET-M0468 m45744 Non-CE: Hadamard transform domain filter
01:08:51 01:34:42 15:37:12 (Huawei)
2019-01-03 2019-01-03 2019-01-14 CE7-related: unified Rice parameter M. Karczewicz, M. Coban
JVET-M0469 m45745
01:37:27 05:35:41 22:23:30 derivation for coefficient coding (Qualcomm)
CE7-related: Golomb-Rice/exponential
JVET-M0470 m45746 Golomb coding for abs_remainder and
01:39:27 04:51:48 22:32:41 (Qualcomm)
JVET-M0471 m45747 2019-01-03 2019-01-03 2019-01-18 CE11.1.6, CE11.1.7 and CE11.1.8: Joint M. Ikeda, T. Suzuki (Sony),
01:46:26 01:53:05 07:42:22 proposals for long deblocking from Sony, D. Rusanovskyy, M.
Qualcomm, Sharp, Ericsson Karczewicz (Qualcomm), W.
Zhu, K. Misra, P. Cowan, A.
Segall (Sharp Labs of
America), K. Andersson, J.
Enhorn, Z. Zhang, R. Sjöberg
(Ericsson)
2019-01-03 2019-01-03 2019-01-03 CE2: Affine sub-block size restrictions H. Chen, T. Solovyev, H.
JVET-M0472 m45748
01:51:09 03:33:14 03:33:14 (Test 2.4.4) Yang, J. Chen (Huawei)
2019-01-03 2019-01-03 2019-01-11
JVET-M0473 m45749 Simplified HMVP W. Zhu, A. Segall (Sharp)
02:01:36 02:10:25 17:00:09
JVET-M0474 m45750 2019-01-03 2019-01-03 2019-01-11 CE8.1.3: Extended CPR reference with 1 L. Pham Van, V. Seregin, W.-
02:05:32 03:33:28 16:34:38 buffer line J. Chien, T. Hsieh, M.
Page: 365 Date Saved: 2019-03-172019-03-14

2019-01-03 2019-01-03 2019-01-03 H.-J. Jhu, Y.-J. Chang
JVET-M0475 m45751 CE3: Multiple neighbour LM (Test 3.2.2)
02:07:17 02:37:53 02:37:53 (Foxconn)
2019-01-03 2019-01-03 2019-01-03 CE2: Control point MV offset for Affine Y.-C. Yang, Y.-J. Chang
JVET-M0476 m45752
02:09:26 02:50:26 02:50:26 merge mode (Test 2.2.5) (Foxconn)
CE2: Simplification of Affine constructed
2019-01-03 2019-01-03 2019-01-04 Y.-C. Yang, Y.-J. Chang
JVET-M0477 m45753 merge candidates (Test 2.2.6) and
02:10:57 02:51:10 11:04:57 (Foxconn)
supplementary results
G. Van der Auwera, A. K.
2019-01-03 2019-01-03 2019-01-11 Ramasubramonian, V.
JVET-M0478 m45754 Non-CE3: PDPC extension
(Qualcomm)
2019-01-03 2019-01-03 2019-01-11 Non-CE4: On clipping of scaled motion
JVET-M0479 m45755 K. Misra, F. Bossen (Sharp)
02:27:36 02:31:43 12:06:55 vectors
2019-01-03 2019-01-03 2019-01-10 CE6-related: Implicit transform selection S. Iwamura, S. Nemoto, A.
JVET-M0480 m45756
02:30:31 02:37:37 07:41:06 for Multi directional LM Ichigaya (NHK)
2019-01-03 2019-01-03 2019-01-06 H. Chen, T. Solovyev, H.
JVET-M0481 m45757 CE4: Symmetrical MVD mode (Test 4.4.3)
02:31:14 03:34:24 10:52:01 Yang, J. Chen (Huawei)
2019-01-03 2019-01-03 2019-01-13 CE6-related: Implicit transform selection S. Iwamura, S. Nemoto, A.
JVET-M0482 m45758
02:32:57 04:09:02 15:36:51 for Multi-hypothesis inter-intra mode Ichigaya (NHK)
W.-J. Chien, V. Seregin, M.
2019-01-03 2019-01-03 2019-01-17 CE8-related: CPR mode signalling and Karczewicz (Qualcomm), S.
JVET-M0483 m45759
02:40:11 05:09:38 00:27:03 interaction with inter coding tools Ye, F. Chen, L. Wang
(Hikvision),
T. Solovyev, H. Gao, S.
2019-01-03 2019-01-03 2019-01-03 Non-CE4: Line buffer size reduction
JVET-M0484 m45760 Esenlik, S. Ikonin, J.Chen
02:47:44 03:35:23 03:35:23 method for generalized bi prediction
(Huawei)
2019-01-03 2019-01-03 2019-01-08 CE2: Sub-block MV clip in planar motion M. Gao, X. Li, M. Xu, S. Liu
JVET-M0485 m45761
03:18:34 03:24:28 05:46:14 vector prediction (test 2.3.2) (Tencent)
Cross-check of JVET-M0284: CE9-related:
2019-01-03 2019-01-10 2019-01-10 S. Bandyopadhyay
JVET-M0486 m45762 BDOF Modifications to Enable 64x64
03:22:59 18:43:53 18:43:53 (InterDigital)
VPDU
X. Xiu, Y. He (InterDigital),
2019-01-03 2019-01-03 2019-01-13 CE9: Simplifications on bi-directional C.-Y. Lai, Y.-C. Su, T.-D.
JVET-M0487 m45763
03:26:12 03:36:07 10:34:44 optical flow (BDOF) (test 9.1.1) Chuang, C.-Y. Chen, Y.-W.
2019-01-03 2019-01-03 2019-01-04 CE2: Sub-block MV clip in affine M. Gao, X. Li, M. Xu, S.
JVET-M0488 m45764
03:27:07 03:29:26 10:19:14 prediction (test 2.4.5) Liu(Tencent)
2019-01-03 2019-01-03 2019-01-08 CE7-related: Reduced context models for M. Gao, X. Li, X. Zhao, S.
JVET-M0489 m45765
03:32:13 03:34:33 05:58:55 transform coefficients coding Liu (Tencent)
2019-01-03 2019-01-03 2019-01-03 CE2-related: Simplified context model for M. Gao, X. Li, S. Liu
JVET-M0490 m45766
03:36:30 03:39:15 03:39:15 triangular prediction mode (Tencent)
CE7-related: Reduced maximum number of
2019-01-03 2019-01-03 2019-01-09 M. Gao, X. Li, X. Zhao, S.
JVET-M0491 m45767 context-coded bins for transform coefficient
03:41:24 03:43:22 05:00:03 Liu (Tencent)
coding
2019-01-03 2019-01-03 2019-01-12 CE10-related: Simplified multi-hypothesis L. Zhao, X. Zhao, X. Li, S.
JVET-M0492 m45768
03:43:48 06:18:22 09:16:25 intra-inter mode Liu (Tencent)
2019-01-03 2019-01-03 2019-01-11 CE3-related: Simplified look-up table for L. Zhao, X. Zhao, X. Li, S.
JVET-M0493 m45769
03:46:46 06:26:05 02:55:21 CCLM mode Liu (Tencent)
2019-01-03 2019-01-03 2019-01-11 CE3-related: Modifications on MPM list L. Zhao, X. Zhao, X. Li, S.
JVET-M0494 m45770
03:48:11 05:58:55 02:16:26 generation Liu (Tencent)
2019-01-03 2019-01-03 2019-01-03 L. Zhao, X. Zhao, X. Li, S.
JVET-M0495 m45771 CE3: Intra mode coding (Test 3.2)
03:49:30 06:06:44 06:06:44 Liu (Tencent)
2019-01-03 2019-01-03 2019-01-06 CE6: Compound Orthonormal Transform X. Zhao, X. Li, S. Liu
JVET-M0496 m45772
03:51:32 04:13:15 06:38:27 (Test 6.1.1 a/b/c/d) (Tencent)
2019-01-03 2019-01-03 2019-01-03 CE6: Fast DST-7/DCT-8 with dual X. Zhao, X. Li, Y. Luo, S. Liu
JVET-M0497 m45773
03:52:42 04:24:15 04:24:15 implementation support (Test 6.2.3) (Tencent)
JVET-M0498 m45774 2019-01-03 2019-01-03 2019-01-04 CE6: MTS up to 16-length (Test 6.3.8) J. Jung, D. Kim, G. Ko, J.-H.
03:53:41 07:32:46 07:39:16 Son, J. S. Kwak (Wilus), X.
Zhao, X. Li, S. Liu (Tencent)
2019-01-03 2019-01-03 2019-01-03 CE6: RQT-like transform sub-block X. Zhao, X. Li, S. Liu
JVET-M0499 m45775
03:54:36 07:38:00 07:38:00 splitting (Test 6.4.3 (Tencent)
V. Seregin, W.-J. Chien, T.
2019-01-03 2019-01-03 2019-01-14 CE10-related: Unidirectional illumination
JVET-M0500 m45776 Hsieh, N. Hu, M. Karczewicz
03:55:20 05:42:22 15:37:19 compensation
(Qualcomm)
2019-01-03 2019-01-03 2019-01-05 CE6 related: Unification of Transform Skip X. Zhao, X. Li, S. Liu
JVET-M0501 m45777
03:55:29 07:31:41 07:56:31 mode and MTS (Tencent)
Page: 366 Date Saved: 2019-03-172019-03-14

2019-01-03 2019-01-03 2019-01-10 CE4-related: Improved context for X. Zhao, X. Li, S. Liu
JVET-M0502 m45778
03:56:37 06:45:13 11:48:21 prediction mode flag (Tencent)
2019-01-03 2019-01-03 2019-01-03 CE3: Chroma intra prediction simplification C.-H. Yau, C.-C. Lin, C.-L.
JVET-M0503 m45779
04:04:11 05:01:02 11:30:09 (Test 3.4.1 and 3.4.2) Lin (ITRI)
2019-01-03 2019-01-03 2019-01-08 CE3: adaptive multiple cross-component S.-P. Wang, C.-H. Yau, C.-C.
JVET-M0504 m45780
04:08:01 07:02:36 22:53:04 linear model(Test 3.2.3 ) Lin, C.-L. Lin (ITRI)
2019-01-03
04:30:48
2019-01-03 2019-01-10 2019-01-10
JVET-M0506 m45783 Simplifications to DMVR search pattern X. Chen (HiSilicon)
04:34:47 09:42:11 10:43:12
and interpolation for refinement)
H. Wang, V. Seregin, W.-J.
Chien, T. Hsieh, Y. Han, M.
Karczewicz (Qualcomm), C.-
2019-01-03 2019-01-03 2019-01-17 CE4-related: Hybrid Merge Estimation
JVET-M0507 m45784 C. Chen, Y.-C. Lin, M.-S.
04:35:23 05:05:11 16:30:57 Region
Chiang, C.-W. Hsu, T.-D.
Chuang, C.-Y. Chen, Y.-W.
AHG9: Test Results of Dense Residual Y. Wang, Z. Chen, Y. Li
2019-01-03 2019-01-03 2019-01-13
JVET-M0508 m45785 Convolutional Neural Network based In- (Wuhan Univ.), L. Zhao, S.
04:37:25 04:42:04 17:01:10
Loop Filter Liu, X. Li (Tencent)
JVET-M0509 m45786 X. Chen (HiSilicon)
04:39:44 09:51:31 10:45:40 MMVD scaling fix)
2019-01-03 2019-01-09 2019-01-14 AHG9: CNN-based in-loop filter proposed Y. Dai, D. Liu, Y. Li, F. Wu
JVET-M0510 m45787
04:43:08 09:14:45 14:25:12 by USTC (USTC)
2019-01-03 2019-01-03 2019-01-03 Y. Li, D. Liu, Z. Chen
JVET-M0511 m45788 Bug fix for rate control under all-intra
04:50:06 13:38:12 13:38:51 (USTC)
2019-01-03 2019-01-03 2019-01-17 Non-CE4: On Temporal Motion Buffer F. Bossen, K. Misra, A. Segall
JVET-M0512 m45789
04:50:31 04:55:36 10:17:15 Compression (Sharp Labs of America)
2019-01-03 2019-01-03 2019-01-18 CE7-related: Context modeling of Y. Zhao, S. Hong, H. Yang, J.
JVET-M0513 m45790
04:58:52 05:19:38 03:57:10 pred_mode_flag Chen (Huawei)
2019-01-03 2019-01-03 2019-01-14 Removal of CIP from Multi-hypothesis C.-C. Chen, W.-J. Chien, M.
JVET-M0514 m45791
05:21:48 05:30:39 19:15:09 Intra Prediction Karczewicz (Qualcomm)
C.-C. Chen, W.-J. Chien, Y.
2019-01-03 2019-01-03 2019-01-11 Non-CE2.5: ATMVP Collocated Block Zhang, C.-H. Hung, Y. Han,
JVET-M0515 m45792
05:21:55 05:31:09 09:39:46 Derivation from History-based Candidate H. Huang, M. Karczewicz
(Qualcomm)
Non-CE9.2.1.e: Non-local-mean-based
2019-01-03 2019-01-03 2019-01-13 C.-C. Chen, W.-J. Chien, M.
JVET-M0516 m45793 MRSAD and Row-subsampled Search
05:22:02 07:54:47 23:10:13 Karczewicz (Qualcomm)
Pattern for DMVR
2019-01-03 2019-01-03 2019-01-12 Non-CE9: Methods for BDOF complexity
05:22:55 07:03:41 10:26:11 reduction
CE4-related: Supplemental results on
D. Rusanovskyy, Y.-H. Chao,
2019-01-03 2019-01-03 2019-01-11 STMVP design of CE4.2.3.a and
JVET-M0518 m45795 Y. Han, W.-J. Chien, M.
05:28:35 09:29:09 03:13:44 combination with methods of JVET-M0127
Karczewicz
(CE4.1.2.a) and JVET-M0127.
2019-01-03 2019-01-03 2019-01-09 Non-CE: Context modeling for coding the S.-T. Hsiang, S.-M. Lei
JVET-M0519 m45796
05:33:54 05:45:31 17:57:21 prediction mode flag (MediaTek)
2019-01-03 2019-01-03 2019-01-03 AHG17: On NAL unit header design for
JVET-M0520 m45797 S. Wenger, B. Choi, S. Liu
06:07:22 06:14:32 06:14:32 VVC
H. Egilmez, V. Seregin, A.
2019-01-03 2019-01-03 2019-01-03 CE6: Replacement of 4-point DST7/DCT8
JVET-M0521 m45798 Said, T. Hsieh, M.
06:28:17 07:11:00 07:11:00 with DST4/DCT4 in MTS (Test 6.1.6)
H. Egilmez, V. Seregin, A.
2019-01-03 2019-01-03 2019-01-10 CE6: MTS support for large rectangular
JVET-M0522 m45799 Said, M. Karczewicz
06:30:43 07:13:20 09:56:44 blocks (Test 6.3.2)
(Qualcomm)
JVET-M0523 m45800 2019-01-03 2019-01-03 2019-01-03 CE6: RQT-like transform partitioning for H. Egilmez, V. Seregin, A.
06:32:31 07:18:30 07:18:30 inter blocks (Test 6.4.2) Said, M. Karczewicz
(Qualcomm)
CE3/6-related: Unification of RQT-like H. Egilmez, V. Seregin, A.
2019-01-03 2019-01-03 2019-01-10
JVET-M0524 m45801 transform partitioning for intra and inter Said, M. Karczewicz
06:34:41 07:25:03 08:24:11
blocks (Qualcomm)
2019-01-03 2019-01-03 2019-01-11 CE10-related: Simplification of intra P.-H. Lin, Y.-J. Chang
JVET-M0525 m45802
06:41:35 07:50:17 10:20:15 prediction in CIIP (Foxconn)
S.H. Wang (Peking Univ.), X.
2019-01-03 2019-01-03 2019-01-07 CE2-related: Further simplification of
JVET-M0526 m45803 Zheng (DJI), S.S. Wang, S.W.
07:05:48 10:25:03 15:03:16 ATMVP collocated block derivation
Ma
Page: 367 Date Saved: 2019-03-172019-03-14

W. Wan, M. Zhou, T.
2019-01-03 2019-01-03 2019-01-03 AHG12: Comments on Tiles and Flexible
JVET-M0527 m45804 Hellman, B. Heng, P. Chen
07:20:40 08:28:33 08:28:33 Tile Partitioning
(Broadcom)
2019-01-03 2019-01-03 2019-01-11 Non-CE3: A unified luma intra mode list F. Bossen, K. Misra (Sharp
JVET-M0528 m45805
07:54:33 07:58:32 18:20:51 construction process Labs of America)
2019-01-03 2019-01-03 2019-01-12 AHG14: Normative Recovery Point M. Pettersson, R. Sjöberg, M.
JVET-M0529 m45806
08:41:57 08:48:20 21:19:26 Indication Damghanian (Ericsson)
JVET-M0530 m45807 AHG12: On signalling of tiles
08:58:13 00:28:11 00:28:11 (Qualcomm)
2019-01-03 2019-01-12 2019-01-12
JVET-M0531 m45808 Early awareness of accessing temporal R. Yu (Ericsson)
09:08:42 08:24:58 08:24:58
blocks in sub-block merge list construction)
JVET-M0532 m45812 H. Dou, Z. Deng, L. Xu (Intel)
10:08:52 15:29:19 11:48:47 Modification on Merge List)
Crosscheck of JVET-M0331 (CE10-
2019-01-03 2019-01-10 2019-01-10 related:A simplification of inter prediction
10:17:25 11:10:13 11:10:13 information derivation for Multi-intra-inter
mode scheme)
C. Pujara, A. Konda, A.
2019-01-03 2019-01-03 2019-01-13 CE13-related: HEC with Pre-rotation +
JVET-M0534 m45814 Singh, R. Gadde, W. Choi, K.
11:01:42 13:37:50 00:29:32 Adaptive Frame Packing (Test 4.2.a+4.1)
Choi, K.P. Choi (Samsung)
Crosscheck of JVET-M0338 (Non-CE2 :
2019-01-03 2019-01-11 2019-01-11
JVET-M0535 m45815 Simplified neighbouring spatial coding unit R. Yu (Ericsson)
12:08:12 09:09:36 09:09:36
derivation for SbTMVP)
2019-01-03 2019-01-03 2019-01-03 AHG12: On picture-level tiles and
JVET-M0536 m45816 E. Thomas, A. Gabriel (TNO)
12:15:19 18:45:09 18:45:09 sequence-level tiles for VVC
AHG17: On signalling of tile group set with
2019-01-03 2019-01-03 2019-01-03
JVET-M0537 m45817 MCTS properties (NAL unit header and E. Thomas, A. Gabriel (TNO)
12:16:03 18:47:42 18:47:42
new parameter set)
A. Said, H.E. Egilmez, Y.-H.
2019-01-03 2019-01-03 2019-01-11 CE6: Efficient Implementations of MTS
JVET-M0538 m45818 Chao, V. Seregin, M.
12:29:04 12:46:37 09:17:42 with Transform Adjustments (tests 1.4a-d)
A. Said, H.E. Egilmez, Y.-H.
2019-01-03 2019-01-05 2019-01-12 CE6-related: Efficient computation of MTS
12:36:37 11:05:10 07:13:28 transform combinations
A. Said, H.E. Egilmez Y.H.
2019-01-03 2019-01-04 2019-01-12 CE6-related: Software tool for computing
12:39:30 07:08:04 07:14:04 transform throughput
Y. Li, Z. Chen (Wuhan
2019-01-03 2019-01-03 2019-01-12 Non-CE8: Combination of MMVD and
JVET-M0541 m45823 Univ.), X. Xu, S. Liu
17:27:53 18:33:50 20:12:31 CPR mode
(Tencent)
Y. Li, Z. Chen (Wuhan
2019-01-03 2019-01-03 2019-01-12 Non-CE8: Combination of Multi
JVET-M0542 m45824 Univ.), X. Xu, S. Liu
17:31:22 18:34:24 20:24:42 Hypothesis Intra and CPR mode
(Tencent)
2019-01-03 2019-01-05 2019-01-05 Crosscheck of JVET-M0474: CE8.1.3-
JVET-M0543 m45825 S.Paluri, S. Kim (LGE)
18:39:40 01:20:01 01:20:01 Extended CPR reference with 1 buffer line.
2019-01-03 2019-01-03 2019-01-11 Non-CE8: CPR with chroma 4x4 sub-block
19:03:27 19:12:01 16:38:52 size when dual-tree is on
2019-01-03 2019-01-06 2019-01-06
JVET-M0545 m45827 Counter-based multi-CABAC for partial J. Dong (Qualcomm)
20:00:41 20:20:31 20:20:31
context models)
2019-01-03 2019-01-17 2019-01-17
JVET-M0546 m45829 Constraint on constructed affine merge L. Zhang (Bytedance)
20:17:25 12:29:04 12:29:04
candidates)
2019-01-03 2019-01-03 2019-01-13
JVET-M0547 m45834 360Â° coding tools using uncoded areas J. Sauer, M. Bläser
22:14:00 22:20:03 10:11:17
JVET-M0548 m45838 2019-01-04 2019-01-09 2019-01-09 Crosscheck of JVET-M0064 (Non-CE3: C.-M. Tsai (MediaTek)
01:22:49 16:48:45 16:48:45 CCLM table reduction and bit range
control)
2019-01-04 2019-01-09 2019-01-09 Crosscheck of JVET-M0103 (Deblocking
JVET-M0549 m45839 C.-M. Tsai (MediaTek)
01:23:49 16:49:26 16:49:26 for multi-hypothesis intra inter prediction)
01:24:41 16:50:06 16:50:06 Intra reference sample deblocking)
JVET-M0551 m45841 S.-T. Hsiang (MediaTek)
01:25:27 10:51:05 10:51:05 Pairwise average candidate reduction)
JVET-M0552 m45842 M.-S. Chiang (MediaTek)
01:26:27 21:09:07 21:09:07 Simplification of CIIP intra mode coding)
Page: 368 Date Saved: 2019-03-172019-03-14

2019-01-04 2019-01-13 2019-01-13 Crosscheck of JVET-M0301 (Non-CE:
01:27:12 17:21:26 17:21:26 Loop filter line buffer reduction)
JVET-M0554 m45844 G. Li (Tencent)
01:48:16 09:35:27 09:35:27 Syntax change of MMVD)
01:48:22 00:58:27 00:58:27 Size constraint on MMVD)
JVET-M0556 m45846 C.-Y. Lai (MediaTek)
01:57:02 16:51:50 16:51:50 Combination test of CE8.2.2 and CE8.2.5)
JVET-M0557 m45847 C.-Y. Lai (MediaTek)
01:57:59 16:52:32 16:52:32 Context modeling on palette mode flag)
2019-01-04 2019-01-04 2019-01-12 CE7-related: Template based Rice M. Karczewicz, M. Coban
JVET-M0558 m45848
02:21:38 06:49:10 14:58:51 parameter derivation (Qualcomm)
2019-01-04 2019-01-09 2019-01-09 Crosscheck of JVET-M0231 (Non-CE4: H. Lee, S.-C. Lim, J. Lee, J.
JVET-M0559 m45849
02:36:09 20:48:55 20:48:55 Regular merge flag coding) Kang (ETRI)
2019-01-04 2019-01-09 2019-01-09 H. Lee, S.-C. Lim, J. Lee, J.
JVET-M0560 m45850 Modification of Triangle and MMVD
02:37:19 20:51:06 20:51:06 Kang (ETRI)
merge indexes coding)
2019-01-04 2019-01-04 2019-01-04 Crosscheck of JVET-M0045 (Non-CE3: J. Lee, H. Lee, S.-C. Lim, J.
JVET-M0561 m45851
02:42:22 16:28:37 16:28:37 PDPC Restriction) Kang (ETRI)
2019-01-04 2019-01-10 2019-01-10 Cross-check of JVET-M0436: AHG2: S. Bandyopadhyay
JVET-M0562 m45852
03:21:30 18:38:45 18:38:45 Regarding HMVP Table Size (InterDigital)
2019-01-04 2019-01-10 2019-01-10 Cross-check of JVET-M0265 (AHG16:
03:22:37 10:06:33 10:47:21 Clean-up on MV Rounding)
2019-01-04 2019-01-04 2019-01-04 Cross-check of JVET-M0189: CE10.3.1 J. Kim, T. Na (SK telecom), J.
JVET-M0564 m45854
03:47:05 05:49:27 05:49:27 AMVP mode for triangle prediction Shin, K. Ko (Pixtree)
2019-01-04
04:05:42
2019-01-04 2019-01-05 2019-01-13 Adaptive convolutional neural network loop H. Yin, R. Yang, X. Fang, S.
JVET-M0566 m45856
04:12:38 08:49:09 10:27:30 filter Ma, Y. Yu (Intel)
2019-01-04 2019-01-06 2019-01-06
JVET-M0567 m45857 Relaxation of block size restriction for T. Chujoh, T. Ikai (Sharp)
06:15:00 08:53:51 08:53:51
DMVR)
2019-01-04 2019-01-06 2019-01-06
JVET-M0568 m45858 A simple gradient calculation at the CU T. Chujoh, T. Ikai (Sharp)
06:15:40 04:39:42 04:39:42
boundaries for BDOF)
2019-01-04 2019-01-06 2019-01-06
JVET-M0569 m45859 Implicit transform selection for Multi- T. Chujoh, T. Ikai (Sharp)
06:18:25 11:48:00 11:48:00
hypothesis inter-intra mode)
06:39:15 08:37:14 08:37:14 pipeline reduction for LIC and GBI)
2019-01-04 2019-01-17 2019-01-17
JVET-M0571 m45861 Reducing the number of reference samples L. Zhang (Bytedance)
06:41:30 12:23:42 12:23:42
and table size in LM Chroma process)
2019-01-04 2019-01-09 2019-01-09
JVET-M0572 m45862 An alternative storing method for affine G. Li (Tencent)
07:18:59 09:54:21 10:20:12
inheritance)
2019-01-04 2019-01-09 2019-01-09
JVET-M0573 m45864 Implicit transform selection for Multi K. Kazui (Fujitsu)
07:33:07 09:53:18 09:53:18
directional LM)
2019-01-04 2019-01-07 2019-01-07 Crosscheck of JVET-M0264 ( Non-CE4:
JVET-M0574 m45865 J. Zhao (LGE)
07:48:00 20:53:44 20:53:44 Harmonization between HMVP and GBi )
2019-01-04 2019-01-10 2019-01-10
JVET-M0575 m45866 Simplification of constructed affine Y. He (InterDigital)
08:07:32 13:29:40 13:29:40
merging candidate derivation)
Crosscheck of JVET-M0406 (CE2/4-
2019-01-04 2019-01-09 2019-01-09
JVET-M0576 m45868 related: Unified merge list size for block C.-Y. Lai (MediaTek)
09:37:55 16:52:59 16:52:59
and sub-block merge modes)
Crosscheck of JVET-M0516 (Non-
2019-01-04 2019-01-08 2019-01-08 CE9.2.1.e: Non-local-mean-based MRSAD
JVET-M0577 m45869 S. Esenlik (Huawei)
10:17:33 11:27:14 11:27:14 and Row-subsampled Search Pattern for
DMVR)
JVET-M0578 m45870 M.-S. Chiang (MediaTek)
10:49:47 21:09:46 21:09:46 Simplification of intra prediction in CIIP)
A. Segall, S. Deshpande
2019-01-04 2019-01-04 2019-01-04 On Frame Rate Support and Extraction in
JVET-M0579 m45871 (Sharp Labs of America), M.
13:55:37 13:59:15 13:59:15 VVC
Hannuksela (Nokia)
JVET-M0580 m45876 2019-01-04 2019-01-04 2019-01-04 Crosscheck of JVET-M0109 (CE12-related: T. Lu, P. Yin (Dolby)
Page: 369 Date Saved: 2019-03-172019-03-14

15:45:39 15:56:51 15:56:51 block-based in-loop luma reshaping)
2019-01-04 2019-01-04 2019-01-12 CE10-related: Bi-directional motion vector M. Bläser, J. Sauer (RWTH
JVET-M0581 m45877
15:47:56 15:54:47 10:43:03 storage for triangular prediction Aachen Univ.)
Cross-check of JVET-M0185 (CE10-
2019-01-04 2019-01-09 2019-01-09 K. Andersson, R. Yu
JVET-M0582 m45879 related: Syntax redundancy removal in
15:56:08 20:31:20 20:31:20 (Ericsson)
triangle prediction)
2019-01-04 2019-01-10 2019-01-10
JVET-M0583 m45887 Quadtree-based Merge Estimation Region G. Li (Tencent)
22:04:35 09:28:36 09:28:36
for VVC)
Crosscheck of JVET-M0170 (CE4.3.1:
2019-01-04 2019-01-07 2019-01-15 Y. Han, H. Wang, C.-C. Chen,
JVET-M0584 m45891 Shared merging candidate list)
23:52:00 17:33:47 00:13:22 W.-J. Chien (Qualcomm)
Supplementary Tests
JVET-M0585 m45894 K. Zhang (Bytedance)
01:41:52 20:13:25 20:13:25 Syntax change of MMVD)
2019-01-05 2019-01-12 2019-01-12
JVET-M0586 m45895 Reduced number of reference samples for K. Zhang (Bytedance)
01:45:55 16:47:12 16:47:12
CCLM parameter calculation)
2019-01-05 2019-01-12 2019-01-12
JVET-M0587 m45896 Modification for blocks applied with K. Zhang (Bytedance)
01:49:51 17:29:51 17:29:51
Combined Inter-Intra prediction)
2019-01-05 2019-01-08 2019-01-13
JVET-M0588 m45898 Merge list construction process for H. Dou, Z. Deng, L. Xu (Intel)
02:38:46 15:29:45 02:39:45
triangular prediction mode)
2019-01-05 2019-01-08 2019-01-10
JVET-M0589 m45899 Simplified multi-hypothesis intra-inter H. Dou, Z. Deng, L. Xu (Intel)
02:41:32 15:30:17 08:22:59
mode)
2019-01-05 2019-01-10 2019-01-17
JVET-M0590 m45901 Simplification of candidate list derivation T. Hashimoto, T. Ikai (Sharp)
03:55:53 05:55:08 11:20:52
for MMVD mode)
03:56:07 11:05:56 11:05:56 Temporal MV buffer reduction)
JVET-M0592 m45903 T. Hashimoto, T. Ikai (Sharp)
03:56:20 13:49:28 13:49:28 MMVD simplification)
Crosscheck of JVET-M0071 (AHG12:
2019-01-05 2019-01-10 2019-01-10
JVET-M0593 m45904 Improved parallel processing capability Y. Yasugi, T. Ikai (Sharp)
03:56:32 21:12:12 21:12:12
with WPP)
03:56:41 07:06:21 06:45:38 Simplification of ATMVP)
03:56:50 21:28:48 21:28:48 MMVD improvements)
2019-01-05 2019-01-12 2019-01-16
JVET-M0596 m45907 Simplification of local illumination Y. Yasugi, T. Ikai (Sharp)
03:57:00 10:07:27 04:55:53
compensation)
2019-01-05 2019-01-10 2019-01-10
JVET-M0597 m45908 MMVD improving with signalling distance T. Hashimoto, T. Ikai (Sharp)
03:57:09 21:49:31 21:49:31
table)
2019-01-05 2019-01-10 2019-01-10
JVET-M0598 m45909 Alignment of affine control-point motion T. Zhou, T. Ikai (Sharp)
03:57:28 22:03:23 22:03:23
vector and subblock motion)
03:57:53 22:18:43 22:18:43 Harmonization of MMVD and AMVR)
JVET-M0600 m45911 2019-01-05 2019-01-05 2019-01-12 AHG10: Quality dependency factor based Z. Liu, Z. Chen, Y. Li (Wuhan
05:33:49 05:39:09 14:53:12 rate control for VVC Univ.), Y. Wu, S. Liu
(Tencent)
2019-01-05 2019-01-05 2019-01-05 Crosscheck of JVET-M0228 (CE2-related: T.-S. Chang, Y.-C. Sun, J.
JVET-M0601 m45912
06:33:43 08:20:55 08:20:55 Affine mode simplifications) Lou (Alibaba)
2019-01-05 2019-01-11 2019-01-11 S. Bandyopadhyay
JVET-M0602 m45913 Further simplification of ATMVP
06:38:13 17:44:13 17:44:13 (InterDigital)
collocated block derivation
07:10:19 10:14:54 10:14:54 MV Derivation for Affine Chroma)
2019-01-05 2019-01-11 2019-01-11 Long deblocking filters with reduced line
JVET-M0604 m45916 A. M. Kotra (Huawei)
17:16:04 16:25:36 16:25:36 buffer requirement and enhanced parallel
processing accessibility)
JVET-M0605 m45917 2019-01-05 2019-01-17 2019-01-18 Crosscheck of JVET-M0336 (Non-CE11: A. M. Kotra (Huawei)
17:24:10 20:53:17 08:19:01 Considering boundary strength on CPR
Page: 370 Date Saved: 2019-03-172019-03-14

coded block boundary)
JVET-M0606 m45918 A. M. Kotra (Huawei)
17:29:17 12:39:00 12:39:00 subblock boundary filter at 8x8 Grid)
2019-01-05
17:39:08
2019-01-05
17:40:31
JVET-M0609 m45921 B. Wang (Huawei)
17:48:41 17:02:38 17:02:38 Modification of MPM derivation)
2019-01-05 2019-01-13 2019-01-13
JVET-M0610 m45922 Multi-Hypothesis Intra with Weighted B. Wang (Huawei)
17:49:47 13:13:05 13:13:05
Combination)
Crosscheck of JVET-M0177 (CE10.1.4:
2019-01-05 2019-01-11 2019-01-11
JVET-M0611 m45923 Simplification of combined inter and intra B. Wang (Huawei)
18:02:01 19:23:14 19:23:14
prediction)
2019-01-05 2019-01-06 2019-01-06 Crosscheck of JVET-M0428 (Encoder
JVET-M0612 m45927 Y.-C. Sun (Alibaba)
21:24:36 02:16:37 02:16:37 optimization with deblocking filter)
2019-01-05 2019-01-06 2019-01-06 Crosscheck of JVET-M0458 (Non-CE3: S. De-Luxán-Hernández
JVET-M0613 m45928
21:50:12 23:16:30 23:16:30 Combined-Hypothesis Intra-Prediction) (HHI)
Crosscheck of JVET-M0277 (Non-CE:
2019-01-06 2019-01-09 2019-01-09 Fixes of enabling
02:18:11 15:48:58 15:48:58 pcm_loop_filter_disabled_flag with PCM
mode signalling under dual tree partition)
2019-01-06 2019-01-10 2019-01-10
JVET-M0615 m45931 Remove the redundancy of CPR-related Y.-C. Sun (Alibaba)
02:21:05 09:26:13 09:26:13
syntax coding)
02:23:20 09:34:16 09:34:16 A new CPR syntax scheme)
2019-01-06 2019-01-09 2019-01-09 Crosscheck of JVET-M0222 (Context
02:25:32 13:21:55 13:21:55 Reduction for CABAC in VVC)
Crosscheck of JVET-M0162 (Adaptive
2019-01-06 2019-01-09 2019-01-09
JVET-M0618 m45934 loop filter with a maximum number of luma Y.-W. Chen (Kwai Inc.)
02:46:30 17:47:00 17:47:00
filters per slice constraint)
2019-01-06 2019-01-09 2019-01-09 Crosscheck of JVET-M0163 (Adaptive
JVET-M0619 m45935 Y.-W. Chen (Kwai Inc.)
02:46:54 17:47:24 17:47:24 loop filter with history filters)
2019-01-06 2019-01-09 2019-01-09
JVET-M0620 m45936 Simplification of subblock-based temporal Y.-W. Chen (Kwai Inc.)
02:47:02 17:53:58 17:53:58
merging candidates)
2019-01-06 2019-01-09 2019-01-13 Crosscheck of JVET-M0307 (CE4-related :
02:47:10 18:13:43 09:01:54 Candidates optimization on MMVD)
2019-01-06 2019-01-09 2019-01-09
JVET-M0622 m45938 Memory bandwidth reduction for affine Y.-W. Chen (Kwai Inc.)
02:47:18 18:15:42 18:15:42
mode with less dependency)
02:47:33 18:17:17 18:17:17 MMVD offset table signalling)
02:47:42 13:03:21 13:03:21 Simplified look-up table for CCLM mode)
Supplemental results on STMVP design of
2019-01-06 2019-01-12 2019-01-12
JVET-M0625 m45941 CE4.2.3.a and combination with methods of Y.-W. Chen (Kwai Inc.)
02:47:49 13:03:59 13:03:59
JVET-M0127 (CE4.1.2.a) and JVET-
M0127)
JVET-M0626 m45949 2019-01-06 2019-01-10 2019-01-13 Crosscheck of JVET-M0528 (Non-CE3: A J. Yao (Fujitsu)
07:30:10 21:00:25 17:13:21 unified luma intra mode list construction
process)
Non-CE4: Supplementary results of H. Liu, K. Zhang, L. Zhang
2019-01-06 2019-01-07 2019-01-07
JVET-M0627 m45950 combined solution of JVET-M0255, JVET- (Bytedance), E. Sasaki, T.
08:50:49 06:29:41 06:29:41
M0267 and JVET-M0069 Chujoh, T. Ikai (Sharp)
2019-01-06 2019-01-12 2019-01-12
JVET-M0628 m45951 Prediction Mode Restriction and Implicit C. Rosewarne (Canon)
10:43:01 10:05:55 10:05:55
Transform Splitting to Enable VPDU)
2019-01-06 2019-01-09 2019-01-09
JVET-M0629 m45952 disabling PDPC based on availability of C. Rosewarne (Canon)
10:44:44 10:01:04 10:01:04
reference samples)
JVET-M0630 m45953 C. Rosewarne (Canon)
10:46:14 10:19:20 10:19:20 Non-Residual Block on VPDU Boundary)
JVET-M0631 m45955 2019-01-06 2019-01-10 2019-01-10 Crosscheck of JVET-M0118 (CE10-related: M.-S. Chiang (MediaTek)
Page: 371 Date Saved: 2019-03-172019-03-14

13:21:16 21:10:21 21:10:21 A fix for merge triangle flag signalling)
JVET-M0632 m45956 K. Abe (Panasonic)
13:31:35 08:30:36 08:30:36 Simplification of LM Mode)
2019-01-06 2019-01-13 2019-01-14
JVET-M0633 m45957 realated: Unidirectional illumination K. Abe (Panasonic)
13:32:29 00:25:16 14:40:22
compensation)
H.-Y. Han, S.-Q. Cao, J.
2019-01-06 2019-01-06 2019-01-14
JVET-M0634 m45958 Affine motion mode in intra coding Wang, F. Liang (SYSU), Y.-
13:45:50 13:55:10 08:17:59
F. Yu, Y. Liu (Oppo)
2019-01-06 2019-01-09 2019-01-09
JVET-M0635 m45959 Inter mode related flag signalling when C.-Y. Lai (MediaTek)
13:47:14 16:53:34 16:53:34
current picture is the only reference picture)
2019-01-06 2019-01-12 2019-01-12 Cross-check of JVET-M0078 (CE9-related: Y. Kato, K. Abe, T. Toma
JVET-M0636 m45960
13:53:05 09:24:32 09:24:32 Combination of JVET-M0077 and CE9.2.5) (Panasonic)
2019-01-06 2019-01-09 2019-01-09 Crosscheck of JVET-M0072 (Non-CE6: On
JVET-M0637 m45961 T. Toma, K. Abe (Panasonic)
14:09:08 10:41:17 10:41:17 transform skip for lager block)
2019-01-06 2019-01-11 2019-01-11
JVET-M0638 m45962 Further Simplification on top of tests CE6- T. Toma, K. Abe (Panasonic)
14:14:55 08:55:11 08:55:11
2.2)
2019-01-06 2019-01-21 2019-01-21
JVET-M0639 m45963 History-based intra most probable modes B. Wang (Huawei)
15:07:47 17:36:22 17:36:22
derivation)
2019-01-06 2019-01-07 2019-01-11 CE12-related: in-loop reshaping with
JVET-M0640 m45964 E. François (Technicolor)
15:25:29 17:58:24 18:21:14 approximate inverse mapping function
2019-01-06 2019-01-08 2019-01-08
JVET-M0641 m45965 Modified linear model derivation for E. François (Technicolor)
18:10:48 23:12:46 23:12:46
CCLM modes)
2019-01-06
20:21:03
2019-01-06 2019-01-09 2019-01-09
JVET-M0643 m45969 Reducing the number of reference samples P. Hanhart (InterDigital)
20:21:21 12:42:01 12:42:01
and table size in LM Chroma process)
2019-01-06 2019-01-09 2019-01-09
JVET-M0644 m45970 360Lib support for chroma sample location P. Hanhart (InterDigital)
20:21:23 12:51:21 12:51:21
in PHEC blending process)
2019-01-06 2019-01-09 2019-01-09
JVET-M0645 m45971 HEC with Pre-rotation + Adaptive Frame P. Hanhart (InterDigital)
20:21:25 13:04:46 13:04:46
Packing(Test 4.2.a+4.1))
2019-01-06 2019-01-16 2019-01-16
JVET-M0646 m45973 Last position coding for large block-size H. Schwarz (Fraunhofer HHI)
21:20:05 09:37:37 09:37:37
transforms)
2019-01-06 2019-01-11 2019-01-12
JVET-M0647 m45974 unified Rice parameter derivation for H. Schwarz (Fraunhofer HHI)
21:22:02 10:20:51 10:36:48
coefficient coding)
2019-01-06 2019-01-09 2019-01-09
JVET-M0648 m45975 BDPCM entropy coding with reduced F. Henry, G. Clare (Orange)
21:29:25 19:48:45 19:48:45
number of context coded bins)
2019-01-06 2019-01-08 2019-01-14 Crosscheck of JVET-M0279 (Non-CE7 :
JVET-M0649 m45976 F. Henry, G. Clare (Orange)
21:33:06 14:29:49 15:59:47 Sign coding for transform skip)
2019-01-06 2019-01-11 2019-01-11 Unified Transform Type Signalling and
JVET-M0650 m45977 F. Henry, G. Clare (Orange)
21:43:28 17:24:37 17:24:37 Residual Coding for Transform Skip, test
TSRC-CCB8)
2019-01-06 2019-01-07 2019-01-07
JVET-M0651 m45978 Improvements on the Decoder-side Intra F. Henry, G. Clare (Orange)
21:50:18 16:57:41 16:57:41
Mode Derivation)
2019-01-07 2019-01-10 2019-01-10 Crosscheck of JVET-M0063 (Non-CE9: An
JVET-M0652 m45980 K. Choi (Samsung)
01:04:16 10:25:19 10:25:19 improvement of BDOF)
Non-CE3: Harmonization of integer-slope
2019-01-06 2019-01-08 2019-01-08 A. Filippov, V. Rufitskiy, J.
JVET-M0653 m45979 directional modes without interpolation
21:53:20 00:43:21 00:43:21 Chen (Huawei)
filtering process
2019-01-07 2019-01-10 2019-01-10
JVET-M0654 m45981 relatedï¼šSimplification on MTS for intra K. Choi (Samsung)
01:04:47 10:59:40 10:59:40
residual coding)
01:04:58 11:02:29 11:02:29 Simplification on MTS CU flag coding)
JVET-M0656 m45983 2019-01-07 2019-01-10 2019-01-10 Crosscheck of JVET-M0501 (CE6 related: K. Choi (Samsung)
Page: 372 Date Saved: 2019-03-172019-03-14

Unification of Transform Skip mode and
01:05:08 11:05:37 11:05:37
MTS)
01:05:17 11:59:55 11:59:55 Improved context for prediction mode flag)
01:05:26 12:01:08 12:01:08 Partial sorting for non-MPM modes)
2019-01-07 2019-01-10 2019-01-10
JVET-M0659 m45986 Simplified merge candidate list for small K. Choi (Samsung)
01:05:35 12:03:00 12:03:00
blocks)
2019-01-07 2019-01-07 2019-01-10
JVET-M0660 m45989 Crosscheck of JVET-M0558 Y. Piao, K. Choi (Samsung)
02:59:24 03:01:55 10:10:12
2019-01-07 2019-01-07 2019-01-07
JVET-M0661 m45991 AhG-13: On Merge List Size X. Li, X. Xu, S. Liu (Tencent)
03:11:46 03:17:38 03:17:38
2019-01-07 2019-01-10 2019-01-10 Crosscheck of JVET-M0266 (CE2-related: R.-L. Liao, C. S. Lim
JVET-M0662 m45997
03:35:38 10:08:44 10:08:44 History-based affine merge candidates) (Panasonic)
Crosscheck of JVET-M0438Â (CE10-
2019-01-07 2019-01-09 2019-01-09 C.-W. Kuo, R.-L. Liao, C. S.
JVET-M0663 m45999 related: Size constraint on Triangular
03:36:38 09:46:39 09:46:39 Lim (Panasonic)
Prediction)
2019-01-07 2019-01-07 2019-01-07
JVET-M0664 m46000 Crosscheck of JVET-M0150 S. Jeong, K. Choi (Samsung)
03:38:42 07:03:11 07:03:11
2019-01-07 2019-01-09 2019-01-09
JVET-M0665 m46001 Crosscheck of JVET-M0400 S. Jeong, K. Choi (Samsung)
03:39:25 16:38:20 16:38:20
Crosscheck of JVET-M0328Â (CE10-
2019-01-07 2019-01-09 2019-01-12 R.-L. Liao, C. S. Lim
JVET-M0666 m46002 related: Simplified triangle prediction unit
04:03:45 10:26:51 12:27:22 (Panasonic)
mode)
2019-01-07 2019-01-07 2019-01-08 Crosscheck of JVET-M0514Â (Removal of
JVET-M0667 m46003 J. Li, C. S. Lim (Panasonic)
04:05:29 11:33:07 08:00:53 CIP from Multi-hypothesis Intra Prediction)
Crosscheck of JVET-M0198 (CE7-related :
2019-01-07 2019-01-10 2019-01-10
JVET-M0668 m46005 Unified rice parameter derivation for M. Coban (Qualcomm)
05:55:28 09:37:10 09:37:10
coefficient level coding)
2019-01-07 2019-01-10 2019-01-10
JVET-M0669 m46010 CPR with chroma 4x4 sub-block size when J. Nam (LGE)
06:38:23 08:37:03 08:37:03
dual-tree is on)
JVET-M0670 m46011 J. Nam (LGE)
06:39:01 08:37:47 08:37:47 CPR flag signalling at slice level)
JVET-M0671 m46012 X. Cao (Hikvision)
06:49:55 10:06:24 10:06:24 Syntax clean-up related to MTS)
2019-01-07 2019-01-10 2019-01-10
JVET-M0672 m46013 Simplification related to MTS with reduced X. Cao (Hikvision)
06:57:39 10:06:53 10:06:53
modes)
2019-01-07 2019-01-09 2019-01-09 Crosscheck of JVET-M0510: AHG9: CNN-
JVET-M0673 m46014 J. Yao, L. Wang (Hikvision)
10:59:18 03:31:39 03:31:39 based in-loop filter proposed by USTC
11:08:24 18:43:45 18:43:45 Triangle prediction merge list construction)
11:09:32 18:44:52 18:44:52 Triangle prediction merge index coding)
JVET-M0676 m46020 P. Merkle (HHI)
11:23:10 12:09:15 12:09:15 Intra simplifications)
JVET-M0677 m46022 F. Racapé (Technicolor)
11:27:00 12:20:51 12:20:51 simplification of PDPC basic equation)
JVET-M0678 m46023 S. Keating (Sony)
11:34:26 12:25:53 12:25:53 Modification of PDPC)
11:46:57 09:33:06 09:33:06 On CCLM simplification)
2019-01-07 2019-01-13 2019-01-13
JVET-M0680 m46025 LUT-free interpolation filters for intra F. Racapé (Technicolor)
11:51:11 16:27:44 16:27:44
prediction)
2019-01-07 2019-01-08 2019-01-12 Crosscheck of JVET-M0096 (CE10.1- F. Galpin, T. Poirier
JVET-M0681 m46027
11:56:01 08:54:53 16:42:50 related: Inter-intra prediction) (Technicolor)
11:57:12 10:03:42 10:03:42 PDPC extension)
Crosscheck of JVET-M0278 (Non-CE7 :
2019-01-07 2019-01-15 2019-01-15
JVET-M0683 m46032 Residual rearrangement for transform Y.-C. Lin (MediaTek)
12:08:07 13:19:10 13:19:10
skipped blocks)
JVET-M0684 m46033 2019-01-07 2019-01-14 2019-01-14 Crosscheck of JVET-M0491 (CE7-related: Y.-C. Lin (MediaTek)
12:09:42 17:45:53 17:45:53 Reduced maximum number of context-
Page: 373 Date Saved: 2019-03-172019-03-14

coded bins for transform coefficient coding)
2019-01-07 2019-01-07 2019-01-18 Non-CE7: On derivation of quantization K. Misra, A. Segall (Sharp
JVET-M0685 m46041
12:35:00 12:36:38 10:24:10 parameter predictor Labs of America)
2019-01-07 2019-01-07 2019-01-07 Crosscheck of JVET-M0291 L. Xu, F. Chen, L. Wang
JVET-M0686 m46051
13:00:52 13:07:24 13:07:24 (CE4.2.5:Extension on MMVD) (Hikvision)
Crosscheck of JVET-
2019-01-07 2019-01-07 2019-01-07 L. Xu, F. Chen, L. Wang
JVET-M0687 m46052 M0061(CE4.4.4e:Combination of
13:10:33 13:14:15 13:14:15 (Hikvision)
CE4.4.4.a and CE4.4.5.c)
Cross-check of JVET-M0305: "CE7-
2019-01-07 2019-01-10 2019-01-10
JVET-M0688 m46065 related: Joint coding of chrominance C. Gisquet (Canon)
14:47:24 14:49:43 14:49:43
residuals"
15:13:47 20:16:07 20:16:07 LM in the middle)
2019-01-07 2019-01-07 2019-01-07 K. Misra (Sharp Labs of
JVET-M0690 m46071 Cross check of JVET-M0343
15:37:09 15:40:36 15:40:36 America)
2019-01-07 2019-01-08 2019-01-16 AHG9: Complexity analysis about neural Y. Li, Z. Chen (Wuhan
JVET-M0691 m46082
16:49:54 16:30:06 14:14:21 network video coding tools Univ.), S. Liu (Tencent)
Crosscheck of JVET-M0329(CE10-related:
2019-01-07 2019-01-11 2019-01-12 S.H. Wang (Peking Univ.), X.
JVET-M0692 m46084 Modified enabling condition for triangle
16:55:01 12:34:09 20:51:17 Zheng, S.S. Wang, S.W. Ma
prediction unit mode)
2019-01-07 2019-01-13 2019-01-13 Z. Zhang, K. Andersson, R.
JVET-M0693 m46087 Simplification of MPM generation for
17:00:42 17:50:31 17:50:31 Sjöberg (Ericsson)
CIIP)
JVET-M0694 m46094 T. Poirier (Technicolor)
17:05:50 10:26:56 10:26:56 Modifications of Triangular PU Mode)
2019-01-07
17:07:28
2019-01-07 2019-01-11 2019-01-11
JVET-M0696 m46099 Combination of Multi Hypothesis Intra and T. Poirier (Technicolor)
17:08:05 11:28:32 11:28:32
CPR mode)
Cross-check of JVET-M0489 "CE7-related:
2019-01-07 2019-01-11 2019-01-11 Y. Chen, F. Le Léannec
JVET-M0697 m46125 Reduced context models for transform
19:31:09 08:53:55 08:53:55 (Technicolor)
coefficients coding"
Crosscheck of JVET-M0403: CE4: Generic
2019-01-07 2019-01-07 2019-01-07 L. Pham Van, W.-J. Chien, M.
JVET-M0698 m46134 Vector Coding of Motion Vector Difference
20:11:40 20:16:00 20:16:00 Karczewicz (Qualcomm)
(Tests 4.4.1.a and 4.4.1.b)
Crosscheck of JVET-M0256(CE2: Affine
2019-01-07 2019-01-07 2019-01-07
JVET-M0699 m46139 temporal constructed candidates (test H. Huang (Qualcomm)
20:17:44 20:39:51 20:39:51
2.2.7))
Cross-check of JVET-M0433 (CE4-related:
2019-01-07 2019-01-08 2019-01-08
JVET-M0700 m46140 Constraint on GBi index inheritance in J. Zhao (LGE)
20:18:38 02:28:11 02:28:11
Merge Mode
2019-01-07 2019-01-07 2019-01-07 Cross-check of JVET- M0316 (CE9-
JVET-M0701 m46145 J. Zhao (LGE)
20:22:00 20:50:48 20:50:48 related: simplification of BDOF)
2019-01-07 2019-01-07 2019-01-11 CE2-related: Adaptive sub-block MV clip X. Li, M. Gao, S. Liu
JVET-M0702 m46151
20:37:31 20:44:25 11:39:35 for affine blocks (Tencent)
JVET-M0703 m46179 2019-01-07 2019-01-08 2019-01-08 Crosscheck of JVET-M0640 (CE12-related: T. Lu, P. Yin (Dolby)
22:14:06 01:11:28 01:11:28 in-loop luma reshaping with approximate
inverse mapping function)
2019-01-08 2019-01-17 2019-01-17 crosscheck for JVET-M0253: Non-CE8:
JVET-M0704 m46222 X. Xu (Tencent)
01:04:05 11:29:16 11:29:16 Hash-based Motion Search
2019-01-08 2019-01-16 2019-01-16 crosscheck for JVET-M0333: Non-CE8:
01:05:44 12:58:56 12:58:56 Coding on block vector difference
crosscheck for JVET-M0335: Non-CE8:
2019-01-08 2019-01-14 2019-01-14
JVET-M0706 m46224 modification on SbTMVP process X. Xu (Tencent)
01:06:23 14:05:21 14:05:21
regarding with CPR
crosscheck for JVET-M0188: CE7-related:
2019-01-08 2019-01-16 2019-01-16
JVET-M0707 m46225 On quantization parameter signalling X. Xu (Tencent)
01:07:26 12:56:18 12:56:18
considering CU area
JVET-M0708 m46233 T. Tsukuba (Sony)
TS32Y/uniMTS)
2019-01-08 2019-01-08 2019-01-11
JVET-M0709 m46234 Extension of transform skip block size to T. Tsukuba (Sony)
02:29:47 07:03:43 16:42:29
8x8)
JVET-M0710 m46240 2019-01-08 2019-01-09 2019-01-09 Crosscheck of JVET-M0317 (CE10-related: F. Chen (Hikvision)
Page: 374 Date Saved: 2019-03-172019-03-14

Simplification of triangular prediction unit
07:35:50 23:30:14 23:30:14
mode)
2019-01-08 2019-01-10 2019-01-10 Context modeling on pred_mode_flag when
JVET-M0711 m46241 S. Ye (Hikvision)
07:47:44 10:49:43 10:49:43 current picture is the only reference picture
(CPR))
2019-01-08 2019-01-11 2019-01-11 Crosscheck of JVET-M0507(CE4-related:
08:03:34 12:56:17 12:56:17 Hybrid Merge Estimation Region)
2019-01-08 2019-01-08 2019-01-09 F. Le Léannec, A. Robert, T.
JVET-M0713 m46246 CE4-related: simplification of CE4.2.2
08:52:59 11:31:31 09:09:36 Poirier (Technicolor)
2019-01-08 2019-01-10 2019-01-10
JVET-M0714 m46247 Local Illumination compensation P. Bordes (Technicolor)
10:13:09 12:55:20 12:55:20
simplifications)
2019-01-08 2019-01-10 2019-01-10
JVET-M0715 m46251 Shared reference samples for multiple X. Ma (Huawei)
12:31:28 09:13:05 09:13:05
chroma intra CBs)
2019-01-08 2019-01-10 2019-01-10
JVET-M0716 m46252 related:Fixed Reference Samples Design for X. Ma (Huawei)
12:31:52 09:32:02 09:32:02
CCLM)
2019-01-08 2019-01-10 2019-01-10
JVET-M0717 m46253 related:Improved reference samples range X. Ma (Huawei)
12:32:28 09:33:59 09:33:59
for MDLM)
2019-01-08 2019-01-10 2019-01-10
JVET-M0718 m46254 Chroma intra candidates modification based X. Ma (Huawei)
12:32:50 10:53:06 10:53:06
on directional DM)
2019-01-08 2019-01-09 2019-01-09 H. Chen, T. Solovyev
JVET-M0719 m46270 Constructed affine merge candidate
16:20:46 03:41:00 03:41:00 (Huawei)
simplification)
2019-01-08 2019-01-09 2019-01-09 H. Chen, T. Solovyev
JVET-M0720 m46271 Simplifications for inherited affine
16:23:38 03:41:16 03:41:16 (Huawei)
candidates)
2019-01-08 2019-01-09 2019-01-09 H. Chen, T. Solovyev
JVET-M0721 m46272 Simplified symmetric MVD based on
16:24:31 03:41:20 03:41:20 (Huawei)
CE4.4.3)
JVET-M0722 m46273 G. Laroche (Canon)
16:48:08 14:46:13 14:46:13 Simplification of triangular partitions)
2019-01-08 2019-01-10 2019-01-10
JVET-M0723 m46275 simplified calculation for CCLM G. Laroche, P. Onno (Canon)
17:06:27 17:11:51 17:13:09
parameters derivation)
JVET-M0724 m46278 G. Laroche, J. Taquet (Canon)
17:23:13 17:26:28 17:26:28 Simplification of ALF coefficients merge)
J. Stegemann, H. Kirchhoffer,
2019-01-08 2019-01-08 2019-01-08
JVET-M0725 m46279 CE5: Results of tests CE5.1.1 and CE5.1.2 H. Schwarz, D. Marpe, T.
19:02:25 19:11:53 19:11:53
Wiegand (HHI)
Cross-check of JVET-M0255 (AHG11:
2019-01-08 2019-01-09 2019-01-13
JVET-M0726 m46282 MMVD without Fractional Distances for A. Karabutov (Huawei)
21:31:46 02:04:04 16:57:28
SCC)
H. Kirchhoffer, C. Bartnik, P.
2019-01-08 2019-01-08 2019-01-08 CE5: Results of tests CE5.1.5, CE5.1.6, and Haase, S. Matlage, J.
JVET-M0727 m46283
21:33:50 21:40:30 21:40:30 CE5.1.7 Stegemann, D. Marpe, H.
Schwarz, T. Wiegand (HHI)
2019-01-08 2019-01-11 2019-01-11
JVET-M0728 m46284 Simplification of ALF coefficients merge N. Hu (Qualcomm)
21:37:03 12:20:17 12:20:17
Variant 3)
2019-01-08 2019-01-13 2019-01-13
JVET-M0729 m46285 Simplification of triangle merging M. Winken (HHI)
22:18:40 10:19:24 10:19:24
candidate list derivation)
Crosscheck of JVET-M0164 (Adaptive
2019-01-08 2019-01-10 2019-01-10
JVET-M0730 m46286 loop filter with virtual boundary T.-H. Li, P.-H. Lin (Foxconn)
22:52:30 19:54:23 19:54:23
processing)
2019-01-08 2019-01-10 2019-01-12 T.-H. Li, Y.-C. Yang
JVET-M0731 m46287 Modifications on Bi-Directional Optical
22:55:06 19:55:06 10:12:24 (Foxconn)
Flow)
2019-01-08 2019-01-09 2019-01-11 Mismatch between text specification and T.-S. Chang, Y.-C. Sun, J.
JVET-M0732 m46288
23:06:34 06:53:57 11:53:26 reference software on ATMVP candidate Lou (Alibaba)
derivation when CPR is enabled)
JVET-M0733 m46289 2019-01-08 2019-01-08 2019-01-08 Crosscheck of JVET-M0146 (Non-CE3: C. Chevance (Technicolor)
Page: 375 Date Saved: 2019-03-172019-03-14

23:18:37 23:23:18 23:23:22 MDLM template downsampling)
2019-01-09 2019-01-11 2019-01-11
JVET-M0734 m46291 Simplification on combined inter-intra L. Zhao (Tencent)
01:14:07 01:44:03 01:44:03
mode prediction)
2019-01-09 2019-01-09 2019-01-09
JVET-M0735 m46295 Motion vector clipping in affine sub-block H. Chen (Huawei)
03:47:20 14:50:12 14:50:12
motion vector derivation)
2019-01-09 2019-01-09 2019-01-12 CE10-related: Triangular prediction with M. Bläser, J. Sauer (RWTH
JVET-M0736 m46296
08:16:29 08:22:35 10:43:46 MMVD Aachen Univ.)
2019-01-09 2019-01-11 2019-01-11
JVET-M0737 m46298 Alignment of affine control-point motion A. Tamse (Samsung)
09:08:18 17:28:54 17:28:54
vector and subblock motion vector)
2019-01-09 2019-01-11 2019-01-11
JVET-M0738 m46299 Context selection for entropy coding the A. Tamse (Samsung)
09:08:20 17:28:55 17:28:55
MTS flag)
2019-01-09 2019-01-11 2019-01-11
JVET-M0739 m46300 Context modeling for coding the prediction A. Tamse (Samsung)
09:08:20 17:28:55 17:28:55
mode flag)
2019-01-09 2019-01-11 2019-01-11
JVET-M0740 m46301 Combination of CE2.2.3.d and affine A. Tamse (Samsung)
09:08:22 17:28:57 17:28:57
inheritance from motion data line buffer)
2019-01-09 2019-01-11 2019-01-11 A. Filippov, V. Rufitskiy
JVET-M0741 m46302 Table size reduction and bit width
09:11:35 09:49:50 09:49:50 (Huawei)
limitation for CCLM implementation)
Crosscheck of JVET-M0390 (CE-10:
2019-01-09 2019-01-09 2019-01-11
JVET-M0742 m46303 related multi-hypothesis with uni- H. Wang (Qualcomm)
09:19:52 10:54:20 08:18:10
directional inter prediction restriction)
2019-01-09 2019-01-10 2019-01-10 Y. Dai, D. Liu, Y. Li, F. Wu
JVET-M0743 m46304 Convolutional Neural Network Filter
09:26:04 02:12:22 02:12:22 (USTC)
(CNNF) for Intra Frame)
2019-01-09 2019-01-17 2019-01-17
JVET-M0744 m46305 Interweaved Prediction for Affine Motion J. Luo (InterDigital)
09:26:43 15:05:12 15:05:12
Compensation)
JVET-M0745 m46306 J. Luo (InterDigital)
09:28:31 11:59:58 11:59:58 Modifications on MPM list generation)
Crosscheck of JVET-M0515 (Non-CE2.5:
2019-01-09 2019-01-10 2019-01-10
JVET-M0746 m46307 ATMVP Collocated Block Derivation from J. Luo (InterDigital)
09:30:02 10:01:05 10:01:05
History-based Candidate)
Crosscheck of JVET-M0110 Test 2 (CE2-
2019-01-09 2019-01-12 2019-01-12
JVET-M0747 m46308 related: Alignment of affine control-point J. Luo (InterDigital)
09:34:33 17:33:12 17:33:12
motion vector and subblock motion vector)
Crosscheck of JVET-M0072, in aspect of
2019-01-09 2019-01-09 2019-01-09
JVET-M0748 m46310 8x8 transform skip extension (Non-CE6: S. Yoo, J. Lim (LGE)
10:19:26 10:28:25 10:28:25
On transform skip for lager block)
Cross-check of JVET-M0190 (CE10-
2019-01-09 2019-01-11 2019-01-13 S.-C. Lim, H. Lee, J. Lee, J.
JVET-M0749 m46312 related: Redundant syntax reduction for
10:26:55 15:30:37 19:13:36 Kang (ETRI)
triangle prediction)
2019-01-09 2019-01-11 2019-01-13 Cross-check of JVET-M0369 (CE4-related: S.-C. Lim, H. Lee, J. Lee, J.
JVET-M0750 m46313
10:27:15 15:31:05 19:14:06 Syntax changes of merge data) Kang (ETRI)
2019-01-09
10:34:55
2019-01-09 2019-01-12 2019-01-12
JVET-M0752 m46315 Crosscheck of JVET-M0424 A. Henkel (HHI)
10:49:04 13:32:25 13:32:25
2019-01-09 2019-01-12 2019-01-14 R.-L. Liao, C. S. Lim
JVET-M0753 m46318 Simplified context model for triangular
11:12:32 09:08:42 15:49:44 (Panasonic)
prediction mode)
2019-01-09 2019-01-11 2019-01-11 S. Bandyopadhyay
JVET-M0754 m46321 Remove redundancy between TMVP and
11:47:14 17:36:19 17:36:19 (InterDigital)
ATMVP
2019-01-09 2019-01-12 2019-01-12
JVET-M0755 m46322 MPM list alignment between CIIP and intra Y.-W. Chen (Kwai Inc.)
11:50:23 15:30:53 15:30:53
mode)
F. Galpin, A. Robert, F.
2019-01-09 2019-01-09 2019-01-13 CE2.2.7 related: Affine temporal
JVET-M0756 m46323 Leleannec, T. Poirier
11:57:11 14:32:49 10:15:10 constructed candidates without pruning
(Technicolor)
2019-01-09 2019-01-10 2019-01-10 Cross-check of JVET-M0171 (CE4-related: B.-J. Fuh, C.-H. Yau, C.-C.
JVET-M0757 m46324
12:41:19 23:21:53 23:21:53 MMVD cleanups) Lin (ITRI)
Page: 376 Date Saved: 2019-03-172019-03-14

2019-01-09 2019-01-11 2019-01-11 Crosscheck of JVET-M0210 (Non-CE3: C.-C. Kuo, C.-H. Yau, C.-C.
JVET-M0758 m46325
12:45:43 00:06:48 00:06:48 Intra prediction information coding) Lin (ITRI)
2019-01-09 2019-01-09 2019-01-09 CE5: Report of subtest 3 on complexity and B. Stabernack (HHI), T. Hsieh
JVET-M0759 m46326
13:08:27 13:10:40 13:10:40 throughput aspects for hardware (Qualcomm)
2019-01-09 2019-01-10 2019-01-10
JVET-M0760 m46327 Simplified CSBF coding for large block- Z.-Y. Lin (MediaTek)
13:53:05 13:02:29 13:02:29
size transforms)
2019-01-09 2019-01-09 2019-01-09 coefficient scanning and last position
JVET-M0761 m46328 Z.-Y. Lin (MediaTek)
13:54:38 17:03:32 17:03:32 coding for TUs of greater than 32 width or
height)
H. Kirchhoffer, C. Bartnik, T.
Hinz, J. Stegemann, P. Haase,
2019-01-09 2019-01-09 2019-01-10 CE5: Report of software throughput
JVET-M0762 m46329 S. Matlage, B. Stabernack, H.
15:26:25 18:42:17 16:45:04 analysis for CE5.2 by HHI
Schwarz, D. Marpe, T.
Wiegand (HHI)
2019-01-09 2019-01-11 2019-01-11
JVET-M0763 m46330 cross-check of JVET-M0117 H.Jang (LGE)
15:52:04 08:55:56 08:55:56
2019-01-09 2019-01-11 2019-01-15
JVET-M0764 m46331 Cross-check of JVET-M0512 H.Jang (LGE)
15:52:59 08:59:15 22:57:26
CE8-related: Unified Screen Content and
2019-01-09 2019-01-09 2019-01-12 Jarosław Samelak, Marek
JVET-M0765 m46332 Multiview Video Coding - Experimental
15:55:28 18:07:46 21:22:34 Domański
results
2019-01-09 2019-01-11 2019-01-13 Crosscheck of JVET-M0385 (Non-linear
JVET-M0766 m46333 M. Ikeda (Sony)
16:10:10 15:28:44 15:25:24 Adaptive Loop Filter)
2019-01-09 2019-01-14 2019-01-14
JVET-M0767 m46334 Removal of redundant syntax between CPR X. Xu (Tencent)
16:27:37 14:04:19 14:04:19
and other inter coding tools)
16:28:52 14:04:40 14:04:40 MMVD harmonization with CPR)
2019-01-09 2019-01-11 2019-01-11 T.-S. Chang, Y.-C. Sun, J.
JVET-M0769 m46336 Removal of subblock-based chroma MC in
17:10:44 11:54:09 11:54:09 Lou (Alibaba)
CPR)
2019-01-09
17:11:26
2019-01-09 2019-01-11 2019-01-13 Crosscheck of JVET-M0159 (AHG9: H. Dou, Z. Deng, J. Boyce
JVET-M0771 m46338
17:29:03 13:23:36 02:51:42 Convolutional neural network loop filter) (Intel)
CE5-related: Clean up of the context model J. Stegemann, H. Kirchhoffer,
2019-01-09 2019-01-09 2019-01-09
JVET-M0772 m46339 initialization process for CE5.1.5 and D. Marpe, H. Schwarz, T.
17:36:30 17:39:53 17:39:53
CE5.1.6 Wiegand (HHI)
2019-01-09 2019-01-10 2019-01-10 J. Jung, D. Kim, G. Ko, J.
JVET-M0773 m46340 MTS kernel derivation for efficient memory
17:38:19 09:33:28 09:37:17 Son, J. Kwak (Wilus)
usage)
Y.-K. Wang (Huawei), M. M.
2019-01-09 2019-01-09 2019-01-10 AHG12: A summary of JVET-M
JVET-M0774 m46344 Hannuksela (Nokia), S.
18:36:26 18:43:39 07:58:32 contributions on picture partitioning
Deshpande (Sharp)
JVET-M0775 m46350 2019-01-09 2019-01-09 2019-01-09 Crosscheck of JVET-M0207: CE10-related: L. Pham Van, W.-J. Chien, M.
21:29:10 21:31:55 21:31:55 Joint optimizations of Triangular prediction Karczewicz (Qualcomm)
unit mode and Multi-Hypothesis prediction
mode
2019-01-10 2019-01-10 2019-01-10 AHG17&AHG15: A summary of JVET-M
JVET-M0776 m46366 Y.-K. Wang (Huawei)
00:06:08 00:14:55 08:00:50 contributions on general HLS
2019-01-10 2019-01-10 2019-01-12 Crosscheck of JVET-M0479: Non-CE4: On C.-H. Hung, W.-J. Chien
JVET-M0777 m46368
02:14:59 02:50:14 16:45:02 clipping of scaled motion vectors (Qualcomm)
2019-01-10 2019-01-10 2019-01-12 Crosscheck of JVET-M0473: Simplified C.-H. Hung, W.-J. Chien
JVET-M0778 m46369
02:20:33 03:06:58 16:45:37 HMVP (Qualcomm)
04:12:01 04:40:51 12:21:14 Candidates optimization on MMVD)
JVET-M0780 m46372 Y. Yasugi, T. Ikai (Sharp)
04:17:25 04:41:25 09:24:43 Split-first signalling for partitioning)
Cross-Check of JVET-M0107(CE7-related:
2019-01-10 2019-01-13 2019-01-18
JVET-M0781 m46375 reduced local neighbourhood usage for M. Gao (Tencent)
08:26:07 02:45:45 03:33:35
transform coefficients coding)
2019-01-10 2019-01-10 2019-01-14 Y.-K. Wang (Huawei), M. M.
JVET-M0782 m46377 Report of BoG on tiles and WPP
09:04:26 23:05:30 10:07:35 Hannuksela (Nokia)
JVET-M0783 m46378 2019-01-10 2019-01-10 2019-01-12 CE3-related: Modification of MPM list J. Heo, J. Choi, J. Choi, S.
09:46:08 10:11:23 08:46:17 order Yoo, L. Li, J. Lim, S. Kim
Page: 377 Date Saved: 2019-03-172019-03-14

(LGE)
2019-01-10
09:47:37
2019-01-10 2019-01-10 2019-01-10
JVET-M0785 m46380 Subblock Operation Removal for Chroma Y.-H. Chao (Qualcomm)
09:53:16 10:50:57 10:50:57
CPR)
JVET-M0786 m46381 Y.-H. Chao (Qualcomm)
09:57:14 23:44:01 23:44:01 simplification of CE4.2.2)
2019-01-10 2019-01-11 2019-01-12 Cross-check of JVET-M0468 (Non-CE:
JVET-M0787 m46382 J. Ström (Ericsson)
10:02:47 23:11:41 11:05:18 Hadamard transform domain filter)
2019-01-10
10:14:07
JVET-M0789 m46385 B. Lee (Chosun Univ.)
10:42:30 10:45:24 13:10:28 Modification of merge data syntax)
Cross-check of JVET-M0361 (Non-CE6:
2019-01-10 2019-01-10 2019-01-10 Mismatch between text specification and
JVET-M0790 m46386 B. Lee (Chosun Univ.)
10:46:22 10:54:05 10:54:05 reference software on the signalling root
CBF)
11:05:53 22:24:57 22:24:57 Combination test of CE8.2.2 and CE8.2.5)
Chen, Y.-C. Lin, Y.-W.
2019-01-10 2019-01-11 2019-01-13 CE10-related: Combined test of multi-
JVET-M0792 m46390 Huang, S.-M. Lei (MediaTek),
12:10:29 22:00:13 12:53:50 hypothesis inter prediction and OBMC
X. Xiu, Y. He (InterDigital),
M. Winken, H. Schwarz, D.
Marpe, T. Wiegand (HHI)
2019-01-10 2019-01-11 2019-01-11 C.-C. Chen, W.-J. Chien
JVET-M0793 m46391 Simplifications for Triangular Prediction
12:13:30 08:38:36 08:38:36 (Qualcomm)
Mode)
2019-01-10 2019-01-11 2019-01-11 Crosscheck of JVET-M0315 (Non-CE4: C.-C. Chen, W.-J. Chien
JVET-M0794 m46392
12:13:36 08:38:49 08:38:49 MMVD Scaling Simplification) (Qualcomm)
2019-01-10 2019-01-11 2019-01-11 C.-C. Chen, W.-J. Chien
JVET-M0795 m46393 Symmetric MVD for Affine Bi-prediction
12:13:45 08:39:31 08:39:31 (Qualcomm)
Coding)
2019-01-10 2019-01-12 2019-01-12 Crosscheck of JVET-M0517 (Non-CE9: C.-C. Chen, W.-J. Chien
JVET-M0796 m46394
12:13:49 07:49:04 07:49:04 Methods for BDOF Complexity Reduction) (Qualcomm)
2019-01-10 2019-01-13 2019-01-13 C.-C. Chen, W.-J. Chien
JVET-M0797 m46395 Co-existence Analysis for DMVR with
12:13:54 07:03:16 07:03:16 (Qualcomm)
BDOF)
Crosscheck of supplementary results of
2019-01-10 2019-01-10 2019-01-10 JVET-M0477 (CE2: Simplification of
JVET-M0798 m46398 H. Liu (Bytedance)
15:40:31 16:03:54 16:03:54 Affine constructed merge candidates (Test
2.2.6) and supplementary results)
2019-01-10 2019-01-10 2019-01-10 Bit-width reduction of multiplier in CCLM K. Kawamura, S. Naito
JVET-M0799 m46403
16:59:36 17:01:58 17:01:58 derivation and prediction (KDDI)
JVET-M0800 m46404 2019-01-10 2019-01-10 2019-01-10 Cross-check report of JVET-M0085 on Fast K. Naser (Technicolor)
17:18:35 17:24:28 17:24:28 algorithm for DST-4/DCT-4 as alternative
transforms for MTS (CE6-related)
Cross-check report of JVET-M0297 on 32
2019-01-10 2019-01-10 2019-01-10
JVET-M0801 m46405 point MTS based on skipping high K. Naser (Technicolor)
17:18:43 17:28:49 17:28:49
frequency coefficients (CE6-related)
Cross-check of contribution JVET-M0653
2019-01-10 2019-01-10 2019-01-13 (Non-CE3: Harmonization of integer-slope
JVET-M0802 m46406 M. Schäfer, J. Pfaff (HHI)
18:00:30 18:18:47 10:24:39 directional modes without interpolation
filtering process)
2019-01-10 2019-01-10 2019-01-13
JVET-M0803 m46407 (Non-CE3: Extended Mode-Dependent M. Schäfer, J. Pfaff (HHI)
18:03:57 18:21:18 10:25:52
Intra Smoothing)
2019-01-10 2019-01-10 2019-01-13
JVET-M0804 m46408 (Non-CE3: modified PDPC for horizontal M. Schäfer, J. Pfaff (HHI)
18:05:49 18:23:07 10:26:59
and vertical modes)
2019-01-10 2019-01-10 2019-01-13
JVET-M0805 m46409 (Non-CE3: LUT-free interpolation filters M. Schäfer, J. Pfaff (HHI)
18:08:33 18:25:50 10:28:27
for intra prediction)
2019-01-10 2019-01-10 2019-01-13
JVET-M0806 m46410 (Non-CE3: On block size restrictions for M. Schäfer, J. Pfaff (HHI)
18:12:06 18:30:02 10:30:30
PDPC)
Page: 378 Date Saved: 2019-03-172019-03-14

Cross-check result of JVET-M0081 (Non-
2019-01-10 2019-01-10 2019-01-10 K. Kawamura, S. Naito
JVET-M0807 m46411 CE4: Simplification of AMVP list
18:23:55 18:26:35 18:26:35 (KDDI)
generation in AMVR)
Cross-check result of JVET-M0082 (CE10-
2019-01-10 2019-01-10 2019-01-10 K. Kawamura, S. Naito
JVET-M0808 m46412 related: Simplification of Multi hypothesis
18:24:15 18:28:48 18:28:48 (KDDI)
intra prediction)
Crosscheck of JVET-M0348: CE4-related:
2019-01-10 2019-01-10 2019-01-10 Further reducing VVC memory bandwidth L. Pham Van, W.-J. Chien, M.
JVET-M0809 m46414
19:39:19 20:14:57 20:14:57 worst case by combining 4x4/4x8/8x4 bi- Karczewicz (Qualcomm)
prediction with AMVR
2019-01-10 2019-01-10 2019-01-10 In-loop filters disabled across face
JVET-M0810 m46415 P. Hanhart (InterDigital)
19:47:05 20:00:47 20:00:47 discontinuities on PHEC with 2-pixel
padding)
2019-01-10 2019-01-10 2019-01-10
JVET-M0811 m46416 Adaptive QP to improve subjective quality P. Hanhart (InterDigital)
19:47:09 20:01:00 20:01:00
for PHEC)
Crosscheck of JVET-M0756: CE2.2.7 L. Pham Van, G. Van der
2019-01-10 2019-01-10 2019-01-13
JVET-M0812 m46420 related: Affine temporal constructed Auwera, H. Huang, M.
20:28:44 20:30:55 11:58:01
candidates without pruning Karczewicz (Qualcomm)
2019-01-10 2019-01-11 2019-01-11 Cross-check of JVET-M0073: Non-CE9: S. Bandyopadhyay
JVET-M0813 m46422
22:15:11 17:13:22 17:13:22 On early termination for BDOF (InterDigital)
2019-01-10 2019-01-11 2019-01-16 L. Li, J. Heo, J. Choi, S. Yoo,
JVET-M0814 m46425 Non-CE3: block size restriction on PDPC
23:31:10 01:25:38 12:22:08 J. Choi, J. Lim, S. Kim (LGE)
2019-01-10 2019-01-11 2019-01-13 L. Li, J. Heo, J. Choi, S. Yoo,
JVET-M0815 m46426 CE3-related: Harmonization on MPM list
23:33:28 01:24:54 09:13:21 J. Choi, J. Lim, S. Kim (LGE)
2019-01-11 2019-01-11 2019-01-15
JVET-M0816 m46427 BoG report on high level syntax J. Boyce
00:00:02 22:40:03 20:20:36
Crosscheck of JVET-M0528 (Non-CE3: A
2019-01-11 2019-01-16 2019-01-16
JVET-M0817 m46428 unified luma intra mode list construction L. Zhao, X. Zhao (Tencent)
00:38:01 01:46:27 01:46:27
process)
09:09:01 12:12:26 12:12:26 Modified Chroma Intra Mode Coding)
2019-01-11 2019-01-11 2019-01-13
JVET-M0819 m46432 Line buffer size reduction method for A. Robert (Technicolor)
09:24:58 09:29:01 10:20:47
generalized bi prediction)
Crosscheck of JVET- M0518 (CE4-related:
Supplemental results on STMVP design of
2019-01-11 2019-01-11 2019-01-11
JVET-M0820 m46434 CE4.2.3.a and combination with methods of T. Y. Zhou, T. Ikai (Sharp)
09:34:07 10:38:17 10:38:17
JVET-M0127 (CE4.1.2.a) and JVET-
M0127)
Crosscheck of JVET-M0245 (AHG16-
2019-01-11 2019-01-11 2019-01-11
JVET-M0821 m46435 related: Chroma block coding and size T. Y. Zhou, T. Ikai (Sharp)
09:38:44 10:39:04 10:39:04
restriction)
H. Wang, Y.-H. Chao, V.
2019-01-11 2019-01-11 2019-01-12 Non-CE8: Encoder optimization for palette
JVET-M0822 m46436 Seregin, M. Karczewicz
10:10:58 10:17:30 18:48:53 mode
(Qualcomm)
2019-01-11 2019-01-11 2019-01-11 CE4-related: Encoder optimization of J. Li, R.-L. Liao, C. S. Lim
JVET-M0823 m46437
10:22:12 11:07:32 11:07:32 CE4.4.5 (Panasonic)
2019-01-11
10:22:18
2019-01-11
10:22:23
Crosscheck of JVET-M0126 supplemental
2019-01-11 2019-01-15 2019-01-15
JVET-M0826 m46440 data (CE4: Modification on history-based Y.-C. Lin (MediaTek)
10:56:35 13:18:32 13:18:32
motion vector prediction)
2019-01-11 2019-01-15 2019-01-15
JVET-M0827 m46441 Using shorter-tap filter for 4x4 sized Y.-C. Lin (MediaTek)
10:58:32 13:18:07 13:18:07
partition)
2019-01-11 2019-01-14 2019-01-14 Reduction of the worst-case memory
JVET-M0828 m46442 Y.-C. Lin (MediaTek)
11:00:09 17:43:33 17:43:33 bandwidth and operation number of
OBMC)
2019-01-11 2019-01-12 2019-01-12
JVET-M0829 m46443 Bi-directional motion vector storage for H. Gao (Huawei)
11:03:14 15:40:18 15:40:18
triangular prediction)
JVET-M0830 m46444 H. Gao (Huawei)
11:05:37 15:41:05 15:41:05 Triangular prediction with MMVD)
Page: 379 Date Saved: 2019-03-172019-03-14

2019-01-11 2019-01-11 2019-01-11 Golomb-Rice/exponential Golomb coding K. Sharman, S. Keating
JVET-M0831 m46445
11:05:44 12:20:20 12:20:20 for abs_remainder and dec_abs_level (Sony)
syntax elements)
Non-CE3: On block size restrictions for
A. Filippov, V. Rufitskiy, J.
2019-01-11 2019-01-11 2019-01-11 PDPC with disabled linear filtering for
JVET-M0832 m46446 Chen (Huawei), J. Lee, J.
11:13:47 11:25:56 11:25:56 PDPC in the case of skew non-diagonal
Kang (ETRI)
modes
2019-01-11 2019-01-16 2019-01-16 Crosscheck of JVET-M0823 (CE4-related: C.-C. Chen, W.-J. Chien
JVET-M0833 m46447
11:28:48 05:47:25 05:47:25 Encoder optimization of CE4.4.5) (Qualcomm)
JVET-M0834 m46448 S. Yoo, J. Lim (LGE)
TSRC-CCB3 and CCB2)
16:17:59 16:26:20 16:26:20 Encoder optimization for palette mode)
JVET-M0836 m46451 X. Wang (Kwai Inc.)
16:46:37 19:54:38 19:54:38 Triangle merge index signalling)
JVET-M0837 m46452 X. Wang (Kwai Inc.)
16:47:17 20:50:17 20:50:17 Hybrid Merge Estimation Region)
F. Galpin, T. Poirier, E.
François (Technicolor), L.
Pham Van, G. Van der
2019-01-11 2019-01-11 2019-01-13 CE 10 related: JVET-M0390 / JVET--
JVET-M0838 m46453 Auwera, A. K.
16:50:26 16:56:24 13:09:05 M0096 combination
Ramasubramonian, V.
Seregin, M. Karczewicz
(Qualcomm)
2019-01-11 2019-01-11 2019-01-13 CE2-related: On number of fast merge A. Robert, F. Le Léannec, F.
JVET-M0839 m46454
16:53:32 16:58:17 09:47:52 candidates for Affine Merge mode Galpin (Technicolor)
2019-01-11 2019-01-14 2019-01-14
JVET-M0840 m46458 Quality dependency factor based rate X. Wang (Kwai Inc.)
18:54:01 22:23:04 22:23:04
control for VVC)
2019-01-11
19:19:22
JVET-M0842 m46460 M. Salehifar (LGE)
20:26:48 20:31:44 20:31:44 Hadamard transform domain filter)
2019-01-12 2019-01-12 2019-01-15
JVET-M0843 m46470 BoG report on CE4 related contributions K. Zhang (Bytedance)
00:00:25 00:11:52 14:43:42
Crosscheck of JVET-M0799 (Bit-width
2019-01-12 2019-01-12 2019-01-12 Y. Kato, K. Abe, T. Toma
JVET-M0844 m46472 reduction of multiplier in CCLM derivation
08:56:07 09:21:55 09:21:55 (Panasonic)
and prediction)
09:08:55 09:12:37 05:03:13 Regular merge flag coding)
2019-01-12 2019-01-12 2019-01-12 Cross-check of JVET-M0275 (Non-CE6:
JVET-M0846 m46474 P. Keydel (HHI)
09:51:02 11:37:18 11:37:18 On transform skip conditions)
JVET-M0847 m46476 2019-01-12 2019-01-14 2019-01-14 Cross-check of JVET-M0524 (CE3/6- P. Philippe (bcom Orange)
10:02:12 13:23:28 13:23:28 related: Unification of RQT-like transform
partitioning for intra and inter blocks)
CE10 related Document: Speedups for J. Rasch, A. Henkel, J. Pfaff,
2019-01-12 2019-01-12 2019-01-12
JVET-M0848 m46477 Uniform Directional Diffusion Filters For H. Schwarz, D. Marpe, T.
10:04:31 11:21:18 11:21:18
Video Coding (JVET-M0042) Wiegand (HHI)
JVET-M0849 m46480 C. Rosewarne (Canon)
10:38:03 17:19:57 17:19:57 syntax clean-up on triangle prediction)
2019-01-12 2019-01-12 2019-01-12 Decoupling of SbTMVP and affine merge
10:52:47 10:56:02 10:56:02 candidate derivation in subblock merge
mode)
Seregin, Y.-H. Chao, H.
Huang, M. Karczewicz
(Qualcomm), X. Wang, Y.-W.
Chen (Kwai), T.-D. Chuang,
2019-01-12 2019-01-12 2019-01-14 CE10-related: Using inter merge list
JVET-M0851 m46485 C.-Y. Chen, Y.-W. Huang, S.-
11:47:58 12:12:16 18:30:40 derivation for triangle mode
M. Lei (MediaTek), A.
Tamse, M. W. Park, S. Jeong,
M. Park, K. Choi (Samsung),
X. Zheng (DJI), X.W. Meng
(Peking Univ.)
JVET-M0852 m46487 2019-01-12 2019-01-13 2019-01-13 Crosscheck of JVET-M0397 (CE6-related: J. Kim (SK Telecom), K. Ko
Page: 380 Date Saved: 2019-03-172019-03-14

11:54:27 11:59:36 11:59:36 DST-3 based transform kernels derivation) (Pixtree), J. Jung (Wilus)
S Deshpande (Sharp), Hendry,
Y.-K. Wang (Huawei), M. M.
Hannuksela (Nokia), Y. He
2019-01-12 2019-01-12 2019-01-12 (Interdigital), L. Chen
JVET-M0853 m46488 AHG12: On Tile Grouping
15:40:37 15:42:39 16:42:19 (MediaTek), W. I. Choi
(Samsung), B. D. Choi
(Tencent), R. Sjöberg
(Ericsson), R. Skupin (HHI)
T. Hashimoto, E. Sasaki, T.
2019-01-12 2019-01-12 2019-01-17 CE4-related: Combination of CE4.4.4a and
JVET-M0854 m46489 Ikai (Sharp), J. Li, R.-L. Liao,
15:47:35 19:45:08 17:46:06 CE4.4.5b
C. S. Lim (Panasonic)
2019-01-12 2019-01-14 2019-01-14 Crosscheck of JVET-M0360 (Video coding
JVET-M0855 m46490 H. Liu (Bytedance)
17:04:52 19:40:51 19:40:51 based on cross RAP referencing (CRR))
Cross-check of JVET-M0446: CE1:
2019-01-12 2019-01-12 2019-01-16
JVET-M0856 m46492 Rectangular virtual pipeline data unit (test A. Wieckowski (HHI)
18:50:40 18:53:01 15:09:02
1.1.1) and supplementary results
2019-01-12 2019-01-12 2019-01-13 BoG report on intra prediction and mode
JVET-M0857 m46493 G. Van der Auwera
19:40:50 19:53:17 18:27:32 coding (CE3-related)
2019-01-12 2019-01-12 2019-01-15
JVET-M0858 m46494 BoG report on CE9 related contributions S. Esenlik
21:22:55 21:44:48 15:21:14
Crosscheck of JVET-M0462: CE2-related:
2019-01-12 2019-01-17 2019-01-17
JVET-M0859 m46495 4x4 chroma affine motion compensation X. Zheng, Y. Wang (DJI)
21:34:04 10:37:46 15:17:54
and motion vector rounding unification
2019-01-12 2019-01-12 2019-01-18 K. Misra (Sharp Labs of
JVET-M0860 m46496 Cross check of JVET-M0483
22:02:08 22:04:56 09:00:26 America)
2019-01-12 2019-01-15 2019-01-15 Crosscheck of JVET-M0854: (CE4-related:
JVET-M0861 m46497 V. Seregin (Qualcomm)
22:29:58 12:06:21 12:06:21 Combination of CE4.4.4a and CE4.4.5b)
2019-01-13 2019-01-13 2019-01-15
JVET-M0862 m46498 BoG report on CE2 related contributions Y. He
06:57:52 07:07:20 01:30:52
Crosscheck of JVET-M0247 (CE2-related
2019-01-13 2019-01-13 2019-01-13
JVET-M0863 m46499 Joint Test of AMVR for Affine Inter Mode K. Choi (Samsung)
07:33:57 07:37:21 07:37:21
(Test 2.1.1 and Test 2.1.2))
2019-01-13 2019-01-13 2019-01-13 [AHG5] Enhancement of cache model by Ryoji Hashimoto, Seiji
JVET-M0864 m46501
09:21:09 09:22:43 09:22:43 adopting block-based format Mochizuki (Renesas)
JVET-M0865 m46502 L. Li (LGE)
10:05:03 16:10:13 16:10:13 Harmonization of MPM list construction)
Crosscheck of JVET-M0832 (Non-CE3: On
2019-01-13 2019-01-17 2019-01-17 block size restrictions for PDPC with
JVET-M0866 m46506 L. Li (LGE)
10:31:53 16:34:31 16:34:31 disabled linear filtering for PDPC in the
case of skew non-diagonal modes)
2019-01-13 2019-01-13 2019-01-14
JVET-M0867 m46507 Crosscheck of CE4.4.5* E. Sasaki, T. Ikai (Sharp)
10:46:55 11:43:26 10:27:15
2019-01-13 2019-01-13 2019-01-16 A. Filippov, V. Rufitskiy
JVET-M0868 m46516 Reduction of motion predictor pruning in
13:21:18 14:57:04 15:47:05 (Huawei)
Triangle Merge mode)
Cross-check report of JVET-M0354 (CE6-
2019-01-13 2019-01-13 2019-01-13
JVET-M0869 m46517 related: MTS with Haar transform for M. Koo (LGE)
13:57:43 17:01:53 17:01:53
Screen Contents Coding)
AHG12: Proposed JVET common test
2019-01-13 2019-01-13 2019-02-21 conditions and evaluation procedures for M. Coban (Qualcomm), R.
JVET-M0870 m46518
15:40:39 15:43:47 22:45:31 MCTS and sub-pictures with boundary Skupin (HHI)
padding
2019-01-13 2019-01-13 2019-01-13 AHG14: Performance Evaluation by CTU K. Kawamura, S. Naito
JVET-M0871 m46519
16:06:12 19:02:28 19:02:28 based Intra Refresh (KDDI)
2019-01-13 2019-01-13 2019-01-13 AHG9: A Result of Convolutional Neural K. Kawamura, S. Naito
JVET-M0872 m46520
16:06:43 16:10:24 16:10:24 Network Filter (KDDI)
2019-01-13 2019-01-14 2019-01-15
JVET-M0873 m46521 BoG report on CE10 related contributions C.-W. Hsu, M. Winken
17:07:12 12:49:52 09:31:04
2019-01-13 2019-01-13 2019-01-16 BoG report on CE13 and CE13 related
JVET-M0874 m46522 J. Boyce
17:18:37 21:40:11 17:58:45 360Â° video coding
JVET-M0875 m46524 2019-01-13 2019-01-13 2019-01-14 Request for flexible unit size tile with T. Ikai, Y. Yasugi (Sharp), G.
18:31:05 19:33:25 14:55:52 implementation friendly restriction Bang (ETRI), Y.-W. Chen, X.
Wang (Kwai Inc.), M. Coban
(Qualcomm), C.-C. Lin
(ITRI), P.-H. Lin (Foxconn),
A. Ichigaya (NHK), K.
Kawamura (KDDI), K. Kazui
Page: 381 Date Saved: 2019-03-172019-03-14

(Fujitsu), R. Sjöberg
(Ericsson), R. Skupin, K.
Sühring, Y. Sanchez, T.
Schierl (HHI), L. Zhang
(Bytedance)
2019-01-13 2019-01-14 2019-01-15 Crosscheck for JVET-M0366 (CE-6
JVET-M0876 m46525 J. Rasch (HHI)
19:58:19 09:15:19 19:14:13 related: Transform Simplification)
2019-01-13 2019-01-14 2019-01-15
JVET-M0877 m46526 BoG report on CE6 related contributions X. Zhao
21:58:21 00:00:38 13:08:51
L. Pham Van, T. Hsieh, V.
2019-01-13 2019-01-13 2019-01-14 CE8-Realted: A combination of Test
JVET-M0878 m46527 Seregin, W.-J. Chien, M.
22:15:00 22:17:53 00:46:05 CE8.1.3 and Test CE8.1.2d
Crosscheck of JVET-M0864 ([AHG5]
2019-01-13 2019-01-14 2019-01-14 T. Zhou, Y. Yasugi, T. Ikai
JVET-M0879 m46528 Enhancement of cache model by adopting
23:10:28 16:45:12 16:45:12 (Sharp)
block-based format)
Cross-check of contribution JVET-M0122,
2019-01-14 2019-01-15 2019-01-15
JVET-M0880 m46533 test 3.a (Non-CE3: On block size F. Racapé (Technicolor)
13:49:49 12:06:26 12:06:26
restrictions for PDPC)
2019-01-14 2019-01-15 2019-01-15 Crosscheck of JVET-M0814 (Non-CE3: A. Filippov, V. Rufitskiy
JVET-M0881 m46534
14:04:06 18:23:47 18:23:47 block size restriction on PDPC) (Huawei)
Cross check of CE7-related: Context
2019-01-14 2019-01-14 2019-01-17 M. W. Park, H. Yang
JVET-M0882 m46535 modeling of pred_mode_flag (JVET-
14:11:09 14:18:57 13:20:10 (Samsung)
M0513)
Seregin, Y.-H. Chao, H.
Huang, M. Karczewicz
2019-01-14 2019-01-14 2019-01-14 CE10-related: Using regular merge index (Qualcomm), X. Wang, Y.-W.
JVET-M0883 m46538
16:28:22 19:36:02 19:36:02 signalling for triangle mode Chen (Kwai), T. Solovyev, S.
Esenlik, S. Ikonin, J. Chen
(Huawei), M. Xu, X. Li, S.
Liu (Tencent)
2019-01-14 2019-01-14 2019-01-14
JVET-M0884 m46539 Combined test of multi-hypothesis inter Z. Deng (Intel)
16:41:15 16:48:25 16:48:26
prediction and OBMC)
2019-01-14 2019-01-14 2019-01-17 Non-CE: Reduced complexity bilateral
JVET-M0885 m46540 J. Ström (Ericsson)
17:23:14 17:29:40 09:40:46 filter
Ccrosscheck of JVET-M0883 (CE10-
2019-01-14 2019-01-14 2019-01-16
JVET-M0886 m46541 related: Using regular merge index H. Liu (Bytedance)
17:37:57 18:30:13 11:18:29
signalling for triangle mode)
Crosscheck of additional tests in JVET-
2019-01-14 2019-01-14 2019-01-14
JVET-M0887 m46542 M0147 (CE9: Results of DMVR related T. Chujoh, T. Ikai(Sharp)
18:03:58 18:08:42 18:08:42
Tests CE9.2.1 and CE9.2.2)
C.-M. Tsai, S.-T. Hsiang, C.-
2019-01-14 2019-01-14 2019-01-17 CE1-related: Picture boundary CU split W. Hsu, T.-D. Chuang, C.-Y.
JVET-M0888 m46544
19:27:44 20:24:49 15:19:30 satisfying the VPDU constraint Chen, Y.-W. Huang, S.-M.
Lei (MediaTek)
2019-01-14 2019-01-15 2019-01-15
JVET-M0889 m46545 On number of fast merge candidates for Y.-W. Chen (Kwai Inc.)
19:46:18 18:06:32 18:10:29
Affine Merge mode)
H. Chen, X. Ma, S. Esenlik,
2019-01-14 2019-01-15 2019-01-15 CE9-related: BDOF buffer reduction and H. Yang, J. Chen (Huawei),
JVET-M0890 m46546
19:59:03 10:52:26 18:58:19 enabling VPDU based application K. Kondo, M. Ikeda, T.
Suzuki (Sony)
2019-01-14 2019-01-14 2019-01-17
JVET-M0891 m46548 BoG report on CE7 related contributions Y. Ye
23:48:24 23:55:31 14:51:32
2019-01-14 2019-01-14 2019-01-16 CE-13 related: Loop filter disabled across Y.-C. Chang, C.-C. Ju
JVET-M0892 m46549
23:49:51 23:53:19 16:48:27 virtual boundaries (MediaTek), P. Hanhart, Y.
He (InterDigital)
Crosscheck of disabling early termination
2019-01-15 2019-01-15 2019-01-15 in JVET-M0890 (CE9-related: BDOF
12:12:05 15:59:32 15:59:32 buffer reduction and enabling VPDU based
application)
2019-01-15 2019-01-15 2019-01-17 Non-CE: Test on parametrizable bilateral
JVET-M0894 m46557 M. Karczewicz (Qualcomm)
12:48:38 12:55:03 11:11:14 filter from JVET-L0406 in VTM3.0
Cross-check result of JVET-M0627 (Non-
2019-01-15 2019-01-15 2019-01-15 CE4: Supplementary results of combined K. Kawamur, S. Naito
JVET-M0895 m46558
13:15:10 13:16:10 13:16:10 solution of JVET-M0255, JVET-M0267 (KDDI)
and JVET-M0069)
Page: 382 Date Saved: 2019-03-172019-03-14

2019-01-15 2019-01-16 2019-01-16
JVET-M0896 m46560 BDOF buffer reduction and enabling Y.-W. Chen (Kwai Inc.)
17:40:46 12:48:23 12:48:23
VPDU based application)
2019-01-15 2019-01-16 2019-01-16
JVET-M0897 m46561 Picture boundary handling with VPDU Y.-W. Chen (Kwai Inc.)
17:41:28 12:48:50 12:48:50
constraints)
2019-01-15 2019-01-15 2019-01-15 Crosscheck for JVET-M0885 (Reduced
JVET-M0898 m46562 J. Rasch (HHI)
17:43:18 19:16:16 19:16:16 complexity bilateral filtering)
Cross-check of JVET-M0894 (Non-CE:
2019-01-15 2019-01-17 2019-01-17 S.-C. Lim, H. Lee, J. Lee, J.
JVET-M0899 m46565 Test on parametrizable bilateral filter from
19:20:35 10:46:29 10:46:29 Kang (ETRI)
JVET-L0406 in VTM3.0) test 2
Cross-check of JVET-M0042: CE10:
2019-01-15 2019-01-17 2019-01-17
JVET-M0900 m46566 Uniform Directional Diffusion Filters For J. Ström (Ericsson)
19:21:54 13:01:42 13:01:42
Video Coding
2019-01-15 2019-01-15 2019-01-16 BoG report on quantization related
JVET-M0901 m46567 Y. Ye
23:41:12 23:42:45 15:40:31 contributions
2019-01-16 2019-01-16 2019-01-16 BoG report on contributions related to
JVET-M0902 m46568 B. Bross, A. Filippov
09:02:59 12:53:50 12:53:50 complexity analysis and reduction
2019-01-16
09:27:33
2019-01-16 2019-01-16 2019-01-16 BoG report on neural networks for video
JVET-M0904 m46577 Y. Li, S. Liu
15:18:33 16:41:51 16:41:51 coding
H. Gao, S. Esenlik, B. Wang,
2019-01-16 2019-01-16 2019-01-16 CE1-related: Picture Boundary Handling
JVET-M0905 m46582 A. M. Kotra, J. Chen
22:24:52 22:28:50 22:28:50 regarding to VPDU
(Huawei)
V. Baroncini, A. Norkin, A.
2019-01-17 2019-01-17 2019-01-18 Subjective assessment of CE11 M. Kotra, K. Andersson, K.
JVET-M0906 m46583
00:03:11 10:10:39 10:44:53 (Deblocking Filter) proposals Misra, H. Jang, C.M. Tsai, D.
Rusanovskyy
2019-01-17 2019-01-17 2019-01-17 Crosscheck of AHG9-related: CNN-based
JVET-M0907 m46591 X. Zheng, Y. Wang (DJI)
10:46:14 15:13:58 15:13:58 lambda-domain rate control for intra frames
K. Andersson, J. Enhorn, R.
CE11-related: Specification text for Yu, Z. Zhang, R. Sjöberg
2019-01-17 2019-01-17 2019-01-17
JVET-M0908 m46598 combination of JVET-M0103 and JVET- (Ericsson), B. Wang, A. M.
18:13:14 21:57:19 21:57:19
M0294 Kotra, S. Esenlik, H. Gao, J.
Chen (Huawei)
2019-01-18
09:30:17
2019-01-25 Meeting Report of the 13th JVET Meeting G. J. Sullivan, J.-R. Ohm
JVET-M1000 m46626 (this doc) (this doc)
16:32:27 (Marrakech, 9-18 January 2019) (chairs)
2019-01-25 2019-02-01 2019-03-09 B. Bross, J. Chen, S. Liu
JVET-M1001 m46627 Versatile Video Coding (Draft 4)
16:36:16 12:25:20 00:54:55 (editors)
JVET-M1002 m46628 2019-01-25 2019-02-16 2019-02-16 Algorithm description for Versatile Video J. Chen, Y. Ye, S. Kim
16:43:40 08:49:54 08:49:54 Coding and Test Model 4 (VTM 4) (editors)
Algorithm descriptions of projection format
2019-01-25 2019-02-17 2019-02-17
JVET-M1004 m46629 conversion and video quality metrics in Y. Ye, J. Boyce (editors)
16:47:27 16:33:54 16:33:54
360Lib (Version 9)
2019-01-30 2019-01-30 2019-01-30 Methodology and reporting template for W.-J. Chien, J. Boyce
JVET-M1005 m46632
19:24:49 19:29:03 19:29:03 tool testing (editors)
2019-01-25 2019-01-30 2019-01-30 Methodology and reporting template for Y. Li, S. Liu, K. Kawamura
JVET-M1006 m46630
16:51:13 18:58:07 18:58:07 neural network coding tool testing (editors)
2019-01-25 2019-02-07 2019-02-07 JVET common test conditions and software F. Bossen, J. Boyce, X. Li, V.
JVET-M1010 m46631
16:54:52 14:58:01 14:58:01 reference configurations for SDR video Seregin, K. Sühring (editors)
Description of Core Experiment 1 (CE1):
2019-01-18 2019-01-18 2019-02-09
JVET-M1021 m46615 Post-prediction and post-reconstruction J. Ström, S. Ikonin, V. Seregin
10:44:39 10:46:12 18:37:30
filtering
2019-01-18 2019-01-18 2019-02-18 Description of Core Experiment 2 (CE2):
JVET-M1022 m46600 C.-C. Chen, Y. He, H. Liu
07:34:27 10:54:32 10:55:23 Sub-block based motion prediction
2019-01-18 2019-01-18 2019-03-14 Description of Core Experiment 3 (CE3): G. Van der Auwera, L. Li A.
JVET-M1023 m46607
09:11:34 10:28:02 02:56:17 Intra Prediction and Mode Coding Filippov
JVET-M1024 m46613 H. Yang, G. Li, K. Zhang
10:00:58 10:01:57 02:36:50 Inter prediction and motion vector coding
JVET-M1025 m46604 C.-Y. Chen, V. Seregin
08:29:40 09:08:46 22:55:25 Adaptive loop filter
JVET-M1026 m46606 X. Zhao, H. E. Egilmez
09:10:45 09:20:36 21:16:50 Transforms and transform signalling
JVET-M1027 m46601 2019-01-18 2019-01-18 2019-02-08 Description of Core Experiment 7 (CE7): H. Schwarz, M. Coban, C.
Page: 383 Date Saved: 2019-03-172019-03-14

08:09:03 08:14:33 23:52:23 Quantization and coefficient coding Auyeung
2019-01-18 2019-01-18 2019-02-28 Description of Core Experiment 8 (CE8): X. Xu, Y.-H. Chao, Y.-C.
JVET-M1028 m46610
09:38:22 11:00:41 03:09:23 Screen Content Coding Tools Sun, J. Xu
JVET-M1029 m46612 S. Esenlik, X. Xiu
09:51:04 09:51:46 16:43:18 Decoder Motion Vector Derivation
JVET-M1030 m46602 C.-W. Hsu, M. Winken
08:21:14 08:38:00 04:40:13 Combined inter and intra prediction
JVET-M1031 m46616 A. Norkin, A. M. Kotra
10:53:00 10:54:48 02:42:36 Deblocking
JVET-M1032 m46603 Hendry, R. Skupin, W. Wan
08:23:04 08:26:40 13:06:59 Tile Set Boundary Handling
Description of Core Experiment 13 (CE13):
2019-01-18 2019-01-18 2019-02-11
JVET-M1033 m46617 Neural Network based Filter for Video Y. Li, S. Liu, K. Kawamura
11:02:45 11:04:33 08:21:51
Coding
Page: 384 Date Saved: 2019-03-172019-03-14

Annex B to JVET report:
List of meeting participants
The participants of the thirteenth meeting of the JVET, according to a sign-in sheet circulated during the
meeting sessions (approximately 268 people in total), were as follows:
1. Kiyofumi Abe (Panasonic) 47. Andrew Dorrell (CiSRA / Canon)

2. Mariana Afonso (Univ. Bristol) 48. Amith DSouza (Samsung)
3. Jaehoon Ahn (LG Electronics) 49. Alberto Duenas (ARM)
4. Thomas Amestoy (Thales/IETR) 50. Hilmi Egilmez (Qualcomm Tech.)
5. Kenneth Andersson (LM Ericsson) 51. Semih Esenlik (Huawei)
6. Ichiro Ando (Nikon) 52. Alexey Filippov (Huawei)
7. Saurav Bandyopadhyay (InterDigital 53. Edouard François (Technicolor)
Commun.) 54. Jiali Fu (Huawei)
8. Vittorio Baroncini (GBTech) 55. Shigeru Fukushima (JVC Kenwood)
9. Max Blaeser (RWTH Aachen Univ.) 56. Arild Fuldseth (Cisco Systems Norway)
10. Saverio Blasi (BBC) 57. Alexandre Gabriel (TNO)
11. Frank Bossen (Sharp) 58. Raj Narayanan Gadde (Samsung)
12. Jill Boyce (Intel) 59. Han Gao (Huawei)
13. Benjamin Bross (Fraunhofer HHI) 60. Wen Gao (Harmonic)
14. Sangguk Cha (Sejong Univ.) 61. Jaemin Ha (Sejong Univ.)
15. Eric (Chi W.) Chai (Ubilinx) 62. Haiyang Han (Sun Yat-Sen Univ.)
16. Tsui-Shan Chang (Alibaba Cloud) 63. Heeji Han (Hanbat Nat. Univ.)
17. Ching-Yeh Chen (MediaTek) 64. Soo-Chul Han (Vidyo)
18. Chun-Chi Chen (Qualcomm Tech.) 65. Philippe Hanhart (InterDigital Commun.)
19. Jianle Chen (Huawei) 66. Miska Hannuksela (Nokia)
20. Jie Chen (Alibaba) 67. Ryoji Hashimoto (Renesas)
21. Lulin Chen (MediaTek) 68. Yong He (InterDigital)
22. Peisong Chen (Broadcom) 69. Yuwen He (InterDigital Commun.)
23. Xu Chen (Huawei Tech.) 70. Christian Helmrich (Fraunhofer HHI)
24. Yi-Wen Chen (Kwai) 71. Hendry (Huawei)
25. Roman Chernyak (Huawei) 72. Félix Henry (Orange)
26. Man-Shu Chiang (MediaTek) 73. Tobias Hinz (Fraunhofer HHI)
27. Wei-Jung Chien (Qualcomm) 74. Christopher Hollman (Ericsson)
28. Byeongdoo Choi (Tencent) 75. Seungwook Hong (Huawei)
29. Haechul Choi (Hanbat Nat. Univ.) 76. Yuling Hsiao (MediaTek)
30. Jangwon Choi (LG Electronics) 77. Ted Hsieh (Qualcomm Tech.)
31. Jiun Choi (LG Electronics) 78. Chih-Wei Hsu (MediaTek)
32. Jungah Choi (LG Electronics) 79. Nan Hu (Qualcomm Tech.)
33. Kiho Choi (Samsung Electronics) 80. Yue Huang (Kwai)
34. Narae Choi (Samsung Electronics) 81. Yu-Wen Huang (MediaTek)
35. Woong Il Choi (Samsung) 82. Junyan Huo (Xidian Univ.)
36. Hsiao-Chiang Chuang (ByteDance) 83. Walt Husak (Dolby Labs)
37. Tzu-Der Chuang (MediaTek) 84. Atsuro Ichigaya (NHK (Japan Broadcasting
38. Takeshi Chujoh (Sharp) Corp.))
39. Muhammed Coban (Qualcomm) 85. Tomohiro Ikai (Sharp)
40. Philippe de Lagrange (Technicolor) 86. Masaru Ikeda (Sony)
41. Santiago De Luxán (Fraunhofer HHI) 87. Sergey Ikonin (Huawei)
42. Zhipin Deng (Intel) 88. Shunsuke Iwamura (NHK (Japan
43. Sachin Deshpande (Sharp) Broadcasting Corp.))
44. André Dias (BBC) 89. Hyeongmoon Jang (LG Electronics)
45. Jihoon Do (Korea Aerosp. Univ.) 90. Byeungwoo Jeon (Sungkyunkwan Univ.
46. Jie Dong (Qualcomm) (SKKU))
Page: 385 Date Saved: 2019-03-172019-03-14

91. Yongwook Jeon (LG Electronics) 144. Jian-Liang Lin (MediaTek)
92. Seungsoo Jeong (Samsung) 145. Po-Han Lin (Foxconn)
93. Wook Je Jeong (Chips & Media) 146. Yongbing Lin (Huawei Tech.)
94. Hong-Jheng Jhu (Foxconn) 147. Hongbin Liu (ByteDance)
95. Jaehong Jung (Gaudi Audio Lab) 148. Shan Liu (Tencent)
96. Jewon Kang (Ewha Univ.) 149. Yang Liu (Oppo)
97. Alexander Karabutov (Huawei) 150. Ye Liu (USTC)
98. Kei Kawamura (KDDI) 151. Zizheng Liu (Wuhan Univ.)
99. Kimihiko Kazui (Fujitsu Labs) 152. Jian Lou (Alibaba)
100. Steve Keating (Sony) 153. Jiancong Luo (InterDigital Commun.)
101. Michel Kerdranvat (Technicolor) 154. Ajay Luthra (Picsel Labs)
102. Paul Keydel (Fraunhofer HHI) 155. Jackie Ma (Fraunhofer HHI)
103. Abdellatif Khindouf (Amevia) 156. Yan Zhuo Ma (Xidian Univ.)
104. Yoshitaka Kidani (KDDI) 157. Detlev Marpe (Fraunhofer HHI)
105. Dae Yeon Kim (Chips & Media) 158. Ken McCann (Zetacast)
106. Dongcheol Kim (Wilus) 159. Sean McCarthy (Dolby)
107. Hyung Kim (Cisco) 160. Xuewei Meng (Peking Univ.)
108. Jae-Gon Kim (Korea Aerosp. Univ.) 161. Kiran Misra (Sharp)
109. Jaeil Kim (SK Telecom) 162. Elie Mora (Ateme)
110. Heiner Kirchhoffer (Fraunhofer HHI) 163. Karsten Müller (Fraunhofer HHI)
111. Geonjung Ko (Wilus) 164. Junghak Nam (LG Electronics)
112. Kyunghwan Ko (Pixtree) 165. Shimpei Nemoto (NHK)
113. Kenji Kondo (Sony) 166. Tung Nguyen (Fraunhofer HHI)
114. Konstantinos Konstantinides (Dolby Labs) 167. Didier Nicholson (Vitec)
115. Moonmo Koo (LG Electronics) 168. Jens-Rainer Ohm (RWTH Aachen Univ.)
116. Anand Meher Kotra (Huawei) 169. Patrice Onno (Canon Research Centre
117. Gosala Kulupana (BBC) France)
118. Jin Sam Kwak (Wilus) 170. Seethal Paluri (LG Electronics)
119. Jani Lainema (Nokia) 171. Dohyeon Park (Korea Aerosp. Univ.)
120. Fabrice Le Léannec (Technicolor) 172. Jee Yoon Park (Sungkyunkwan Univ.
121. Julien Le Tanou (Ericsson Mediakind) (SKKU))
122. Brian Lee (Dolby Labs) 173. Jun-Taek Park (Kwangwoon Univ.)
123. Bumshik Lee (Chosun Univ.) 174. Min Woo Park (Samsung Electronics)
124. Geonwon Lee (Sejong Univ.) 175. Minsoo Park (Samsung Electronics)
125. Hahyun Lee (Electronics and Telecom 176. Naeri Park (LG Electronics)
Research Institute (ETRI)) 177. Martin Pettersson (Ericsson)
126. Jinho Lee (Electronics and Telecom 178. Jonathan Pfaff (Fraunhofer HHI)
Research Institute (ETRI)) 179. Pierrick Philippe (Orange Labs)
127. Jong-Seok Lee (Kwangwoon Univ.) 180. Yinji Piao (Samsung)
128. Sangheon Lee (LG Electronics) 181. Chirag Pujara (Samsung)
129. Sunyoung Lee (Pixtree) 182. Fabien Racapé (Technicolor)
130. Ya-Hsuan Lee (MediaTek) 183. Adarsh Krishnan Ramasubramonian
131. Shawmin Lei (MediaTek) (Qualcomm Tech.)
132. Marc Leny (Ektacom) 184. Jennifer Rasch (Fraunhofer HHI)
133. Dotan Levi (Mellanox) 185. Justin Ridge (Nokia)
134. Guichun Li (Tencent) 186. Antoine Robert (Technicolor)
135. Ling Li (LG Electronics) 187. Christopher Rosewarne (CiSRA / Canon)
136. Ming Li (ZTE) 188. Vasily Rufitskiy (Huawei)
137. Tim Li (Foxconn) 189. Dmytro Rusanovskyy (Qualcomm)
138. Xiang Li (Tencent) 190. Yago Sanchez De La Fuente (Fraunhofer
139. Yiming Li (Wuhan Univ.) HHI)
140. Yue Li (Univ. Sci. & Tec. China) 191. Eiichi Sasaki (Sharp)
141. Chongsoon Lim (Panasonic) 192. Johannes Sauer (IENT)
142. Jaehyun Lim (LG Electronics) 193. Thomas Schierl (Fraunhofer HHI)
143. Ching-Chieh Lin (ITRI Intl.) 194. Heiko Schwarz (Fraunhofer HHI)
Page: 386 Date Saved: 2019-03-172019-03-14

195. Andrew Segall (Sharp) 250. Yan Ye (Alibaba)
196. Vadim Seregin (Qualcomm) 251. Peng Yin (Dolby Labs)
197. Sriram Sethuraman (Ittiam) 252. Sunmi Yoo (LG Electronics)
198. Masato Shima (Canon) 253. Yong-uk Yoon (Korea Aerosp. Univ.)
199. Sandeep Shreshtha (Chosun Univ.) 254. Hualong Yu (Zhejiang Univ.)
200. Donggyu Sim (Kwangwoon Univ.) 255. Lu Yu (Zhejiang Univ.)
201. Rickard Sjöberg (Ericsson) 256. Ruoyang Yu (Ericsson)
202. Robert Skupin (Fraunhofer HHI) 257. Yuangfang Yu (Oppo)
203. Yumi Sohn (Samsung) 258. Kai Zhang (ByteDance)
204. Timofey Solovyev (Huawei) 259. Li Zhang (ByteDance)
205. Juhyung Son (Wilus) 260. Wenhao Zhang (Hulu)
206. Sehoon Son (Pixtree) 261. Zhi Zhang (Ericsson)
207. Mukund Srinivasan (Ittiam) 262. Qun Zhao (Xiaomi)
208. Benno Stabernack (Fraunhofer HHI) 263. Xin Zhao (Tencent)
209. Jacob Ström (Ericsson) 264. Alexander Zheludkov (Beamr)
210. Shiori Sugimoto (NTT) 265. Xiaozhen Zheng (DJI)
211. Karsten Sühring (Fraunhofer HHI) 266. Yunfei Zheng (Kwai)
212. Gary Sullivan (Microsoft) 267. Minhua Zhou (Broadcom)
213. Yu-Chen Sun (Alibaba) 268. Jian Qing Zhu (Fujitsu R&D Center)
214. Yule Sun (Zhejiang Univ.)
215. Teruhiko Suzuki (Sony)
216. Yasser Syed (Comcast Cable)
217. Ali Tabatabai (Sony)
218. Masaya Takahashi (Nikon)
219. Anish Tamse (Samsung)
220. Jonathan Taquet (Canon Research)
221. Han Boon Teo (Panasonic)
222. Emmanuel Thomas (TNO)
223. Tadamasa Toma (Panasonic)
224. Pankaj Topiwala (FastVDO)
225. Alexandros Tourapis (Apple)
226. Chiaming Tsai (MediaTek)
227. Yi-Ting Tsai (ITRI)
228. Kyohei Unno (KDDI)
229. Geert Van der Auwera (Qualcomm)
230. Rahul Vanam (InterDigital Commun.)
231. Shuai Wan (NPU Univ.)
232. Wade Wan (Broadcom)
233. Biao Wang (Huawei)
234. Jiexi Wang (ByteDance)
235. Jun Wang (Sun Yat-Sen Univ.)
236. Li Wang (Hikvision)
237. Suhong Wang (Peking Univ.)
238. Xianglin Wang (Kwai)
239. Ye-Kui Wang (Huawei)
240. Stephan Wenger (Tencent)
241. Adam Wieckowski (Fraunhofer HHI)
242. Martin Winken (Fraunhofer HHI)
243. Dongjae Won (Sejong Univ.)
244. Ping Wu (ZTE UK)
245. Jizheng Xu (ByteDance)
246. Xiaozhong Xu (Tencent)
247. Jie Yao (Fujitsu R&D Center)
248. Yukinobu Yasugi (Sharp)
249. Chang-Hao Yau (ITRI international)
Page: 387 Date Saved: 2019-03-172019-03-14

JVET-M Notes DF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

JVET-M Notes DF

Uploaded by

Copyright:

Available Formats

Joint Video Experts Team (JVET)

Page: 1 Date Saved: 2019-03-172019-03-14

2.2 Meeting logistics

2.3 Primary goals

Page: 2 Date Saved: 2019-03-172019-03-14

2.4.2 Late and incomplete document considerations

Page: 3 Date Saved: 2019-03-172019-03-14

Page: 4 Date Saved: 2019-03-172019-03-14

Page: 5 Date Saved: 2019-03-172019-03-14

Page: 6 Date Saved: 2019-03-172019-03-14

Page: 7 Date Saved: 2019-03-172019-03-14

2.4.3 Outputs of the preceding meeting

2.7 IPR policy reminder

Page: 9 Date Saved: 2019-03-172019-03-14

2.8 Software copyright disclaimer header reminder

Page: 10 Date Saved: 2019-03-172019-03-14

2.9 Communication practices

Page: 11 Date Saved: 2019-03-172019-03-14

Page: 12 Date Saved: 2019-03-172019-03-14

Page: 13 Date Saved: 2019-03-172019-03-14

Page: 14 Date Saved: 2019-03-172019-03-14

Page: 15 Date Saved: 2019-03-172019-03-14

Page: 16 Date Saved: 2019-03-172019-03-14

2.11 Opening remarks

2.12 Scheduling of discussions

Page: 17 Date Saved: 2019-03-172019-03-14

Page: 18 Date Saved: 2019-03-172019-03-14

Page: 19 Date Saved: 2019-03-172019-03-14

2.13 Contribution topic overview

Page: 20 Date Saved: 2019-03-172019-03-14

3 AHG reports (17)

Page: 21 Date Saved: 2019-03-172019-03-14

Page: 22 Date Saved: 2019-03-172019-03-14

Page: 23 Date Saved: 2019-03-172019-03-14

Page: 24 Date Saved: 2019-03-172019-03-14

Page: 25 Date Saved: 2019-03-172019-03-14

The following shows VTM 3.0 performance over HM 16.19:

Page: 26 Date Saved: 2019-03-172019-03-14

Low delay B Main10

Low delay P Main10

The following table shows VTM 3.0 compared to VTM 2.1:

Page: 27 Date Saved: 2019-03-172019-03-14

Low delay B Main10

Low delay P Main10

Full results were attached to the AHG report as Excel files.

Page: 28 Date Saved: 2019-03-172019-03-14

Page: 29 Date Saved: 2019-03-172019-03-14

JVET-M0005 JVET AHG report: Memory bandwidth consumption of coding tools

Page: 30 Date Saved: 2019-03-172019-03-14

VTM-3.0 PHEC vs PERP (VTM-3.0 PERP as anchor)

Page: 31 Date Saved: 2019-03-172019-03-14

VTM-3.0 PERP vs HM-16.16 PERP (HM-16.16 PERP as anchor)

VTM-3.0 PHEC vs HM-16.16 CMP (HM-16.16 CMP as anchor)

JVET-M0007 JVET AHG report: Coding of HDR/WCG material (AHG7) [A. Segall,

Page: 32 Date Saved: 2019-03-172019-03-14

Page: 33 Date Saved: 2019-03-172019-03-14

Page: 34 Date Saved: 2019-03-172019-03-14

JVET-M0010 JVET AHG report: Encoding algorithm optimizations (AHG10)

Page: 35 Date Saved: 2019-03-172019-03-14

Page: 36 Date Saved: 2019-03-172019-03-14

Page: 37 Date Saved: 2019-03-172019-03-14

Page: 38 Date Saved: 2019-03-172019-03-14

Page: 39 Date Saved: 2019-03-172019-03-14