Joint Video Experts Team (jvet) of itu-t sg 6 wp and iso/iec jtc 1/sc 29/wg 11

12.3Closing plenary sessions

Add notes for plenaries of Monday, Tuesday and Wednesday. Add notes about ILS from JPEG.

Information about the Call for Proposals for JPEG XL was conveyed in the incoming liaison statement TD207/Gen and corresponding WG 11 input document.

12.4Joint meetings

Add notes of 1645-1800 Joint meeting with parent bodies on project development

Notes are in file JointMeetingOnProjectDec.docx and the Q6 report.

12.5BoGs (105)

JVET-K0521 BoG Report on ALF [L. . Zhang]

This BoG report wWas presented Sat. 14^th 1900 in Track B (see notes under CE2.4).

JVET-K0527 BoG report on 360° video [J. . Boyce]

Thise BoG met July 13 in two sessions to review CE13 and other 360 Video related contributions identified in the AHG8 report. Informal subjective viewing was performed, and the observations from the viewing discussed in the BoG.

The BoG recommendeds the following:

• 
  Add the MCP projection format to 360Lib. Should add configuration options for flexible padding, including number of padding pixels, and which locations to apply padding (just between face rows vs. around the face rows including the picture edges.) (Note: the acronym MCP should be modified, better hybrid of something)
  
• 
  Use the MCP format with padding of 4 samples around face row with blending (PMCP) as in Test 5.2 for coding tool experiments in the CE and the CTC. Replace the ERP and CMP anchors with MCP. Will still ask AHG6 to provide PERP and CMP results for VTM and BMS.
  
• 
  Define a 360 video Core Experiment be defined to study removing subjective artefacts at face boundaries, and comparing normative decoding tools with non-normative pre- and post-processing (such as padding, cropping, blending, post-filtering). CE coordinators: P. Hanhart and J.-L. Lin.
  
  • 
    Include in CE: inter and intra prediction using spherical neighbours, deblocking filter disabling and using spherical neighbours, post-filtering, combinations with padding and with other coding tools. Different padding widths.
    

The BoG encourageds study of the following:

• 
  Signalling of projection format parameters, coding tools parameters, and post-filtering hints.
  
• 
  GPU complexity impact of rendering (including possible post-processing) of projection formats.
  

The BoG askeds the track for guidance on normative tool adoption for 360 video. What complexity impact could be acceptable to remove subjective artefacts that pre- and post-processing alone are unable to resolve?
For the CE on tools, it is necessary to specify a single projection format (“MCP” was agreed).

A reference method that prevents visibility of face boundaries (which is the main target of the CE) with non-normative elements such as geometry-corrected padding, blending, post-filtering needs to be defined. Such a method was also agreed in the BoG. It must however be further studied if a non-normative method can be further improved. (Note: In the informal viewing performed at this meeting it seemed that non-normative methods available so far could not fully resolve the boundary visibility problem).

Guidance is seekedwas sought regarding which amount of normative tools is acceptable:

• 
  Disabling tools at face boundaries might be simple to do, but concepts about how to specify that have not been proposed yet. (this applies to frame packed neighbours that are not spherical neighbours)
  
• 
  Tools requiring access from somewhere else (this applies to spherical neighbours that are not frame packed neighboured) in the same picture or a reference pictures appear to be more complicated, and no real concepts of how to specify this have been shown yet; assessment of additional operations, memory accesses or additional buffering should be done for these cases.
  

Only when knowing the compression benefit compared to the non-normative case, as well the complexity impact, and the simplicity level of specifying it, further decisions can be made.

JVET-K0528 BoG report on partitioning structures (CE1 SubCE1) [B. . Bross]

See section 7.1

JVET-K0539 BoG report on intra prediction and mode coding (CE3-related) [G. . Van der Auwera]
JVET-K0541 BoG report on common test conditions [J. . Boyce]

See section 4.3.[Add info from BoG report.]

Presented Wednesday 1130 (GJS & JRO).

It was remarked that there could be a distinction between gaming/animation content and what we ordinarily consider screen content.

It was remarked that 4:4:4 content is desirable, and we should try to get 4:4:4 versions of sequences that we currently have as 4:2:0 if feasible.

It was suggested to replace ChinaSpeed with Tencent_AOV5 in class F.

For future study, it was suggested to consider using some downsampled and higher-res sequences of the same source content and to consider having some content that is available in corresponding SDR and HDR versions.

It was commented that to avoid disrupting our ability to measure gain across meeting cycles. Others commented that since Class F has been optional and was not previously as emphasized, so a change to Class F should not be disruptive.

Decision (CTC): The replacement of ChinaSpeed in Class F was agreed.

[Post-meeting discussion:

Person 1: My recollection is that in the final JVET plenary we decided to add one sequence to class F, and also make class F mandatory (but not include it in the BD rate averages).

Person 2: I believe 1) ChinaSpeed was replaced (the number of sequences was not increased) and Yes, I believe class F was made mandatory.]

JVET-K0546 BoG report on CE4 related contributions [H. . Yang]

Was presented Sun 15^th 1220.

The BoG reviewed documents from the following categories:

• 
  Affine motion compensation (12)
  
  • 
    BMS affine bugfix
    
  • 
    Motion compensation
    
  • 
    Merge & AMVP
    
  • 
    MVD coding
    
  • 
    4/6-param model switching
    
  • 
    Triangle partition based affine MC
    
• 
  Merge mode enhancement (14)
  
  • 
    ATMVP modifications
    
  • 
    Modified merge candidates
    
  • 
    List construction
    
  • 
    Buffer reduction
    
• 
  Motion vector coding (1)
  
• 
  Reference picture boundary padding (1)
  

For specific notes on documents reviewed in the BoG, see under CE4 related section.

The following aspects were recommended (see for adoptions/decisions in CE4 related section):

• 
  Recommendations on BMS
  
  • 
    BMS affine bugfix on inheriting 4-param affine model
    
  • 
    BMS affine bugfix on CU size restriction for affine merge mode (w&h >= 8)
    
  • 
    SIMD implementation into BMS affine
    
  • 
    Simplified ATMVP
    
    • 
      One fixed collocated picture is used to derive temporal motion information.
      
    • 
      Slice level adaptive sub-block switching, 8x8 or 4x4.
      
    • 
      Constrain the region from where ATMVP motion is derived to the collocated CTU plus one 4x4 block column outside the collocated CTU at the right hand side, the same region for HEVC TMVP.
      
• 
  Recommended tests in next round of CE4
  
  • 
    Affine MC: 6
    
  • 
    Merge enhancement: 9
    
  • 
    Motion vector coding: 1
    
  • 
    Reference picture boundary padding: 1
    

JVET-K0547 BoG report on complexity analysis of long distance merge candidates and combined merge candidates [X. . Li]

This contribution is the BoG report on complexity analysis of long distance merge candidates and combined merge candidates. The BoG meeting was held Saturday 14 July from 8:30pm to 10:20pm.

Complexity Analysis of long distance merge candidates

The analysis on line buffer is based on the following conditions

1. 
   MV information stored in the current CTU is regarded as local and is not counted in line buffer calculation
   
2. 
   The last MV row (4x4 luma pixel level) above the current CTU is considered as in the current architecture, and is not counted in line buffer calculation
   
3. 
   Left CTU is not counted in line buffer calculation
   

MV information stored in the current CTU is regarded as local and is not counted in line buffer calculation

The last MV row (4x4 luma pixel level) above the current CTU is considered as in the current architecture, and is not counted in line buffer calculation

Left CTU is not counted in line buffer calculation

The BoG had consensus on conditions 1 & 2, while but no consensus on condition 3.

It was agreed in the discussion in track B that this memory should be counted, but not as part of a “line buffer”, but it is definitely an additional buffering that is needed.

The complexity analysis of long distance merge candidates wais summarized in the an attachment data file.

The data weare included in the an attached Excel sheet.

The analysis unveils indicated that the proposals that perform more operations and have more additional buffer requirements provide better results.

For the next round of CE, a limit should be imposed on

• 
  Max additional line buffer (may be 0?)
  
• 
  Max number of potential additional candidates
  
• 
  Max number of operations/comparisons/conditions in the pruning
  
• 
  Max merge candidates in the list (list size shall be constant)
  

The same basically applies to the other category below, which already has much more limited complexity; in the next CE, all proposals suggesting modifications on merge should be compared against each other and with data on the complexity increase that they impose. H. Yang should take over the overall coordination with help by others for sub-CEs.
Complexity Analysis of combined merge candidates

There are two proposals studied in this category. The analysis is summarized in the following table.

	size of merge list	Newly introduced complexity in worst case
JVET-K0198	5	6 scaling, 6 x 2 comparisons on refIdx
JVET-K0245 (CE 4.2.8.c)	10	6 x (4 comparisons on refIdx, 2 MV scaling, 4 average) 4+5+6+7+8+9=39 comparisons on MV candidates

JVET-K0552 BoG report on HDR-related contributions [A. . Segall]

Reviewed in track B Tues 17 July 1020 (chaired by JRO)

The BoG met July 15 to review CE12 and other HDR video related contributions and topics identified in the AHG-7 report.

The BoG recommends the following:

• 
  reconducting the CE on HDR mapping, to further investigate the out-of-loop and in-loop mapping and the luma/chroma rate allocation and balance
  
• 
  creating a CE for investigating mapping for SDR content (based on JVET-K0309, JVET-K0468)
  
• 
  updating the HDR CTCs as follows:
  
  • 
    For tests not requiring visual assessment (fixed QP case), consider the first 300 frames of the following HLG content: DayStreet, PeopleInShoppingCenter, SunsetBeach, the initial version of FlyingBirds sequence provided by NHK
    
  • 
    For tests requiring visual assessment (fixed bitrate case), consider the full 600 frames of the following HLG content: DayStreet, PeopleInShoppingCenter, SunsetBeach
    
  • 
    Mandating usage of HDRTools to report HDR metrics (including wPSNR)
    
  • 
    Macro WCG_EXT should be enabled
    
• 
  reporting performance comparisons of VTM and BMS against the HM for HDR content, as done for the SDR case
  

The recommendations above were approved in track B, however the investigations of benefits of in-loop reshaping and chroma refinement for SDR shall be included in CE12 (not separate CE), to be renamed as “mapping function”

It is noted that for the next meeting it should planned to have appropriate viewing equipment both for HDR and SDR.

JVET-K0559 Report of BoG on Picture Boundary Partitioning [K. . Misra]
JVET-K0562 Report of BoG on Software development and CTC [F. . Bossen]

Reviewed in track B Tues 17 July 1020 (chaired by JRO)

The BoG on Software development and CTC met on Monday July 16 2018 from 9:15 to 13:15 in room Povodni Moz 2. It reviewed input contributions related to software development and CTC, and encoder optimizations. Recommendations from the BoG include:

• 
  JVET-K0054: adopt unified PSNR calculation with runtime configurability (default off). Usage should be described in CTC document
  
• 
  JVET-K0149: enhance dtrace to be able to produce additional proposed statistics. Add reference to external viewer in SW manual (with proper disclaimer).
  
• 
  JVET-K0154: enable FULL_NBIT macro by default, mainly effective to increase chroma gain for HDR (pending SIMD code review)
  
• 
  JVET-K0261: adopt proposed SW cleanup changes (change macro values if needed and remove disabled code) – JEM compatibility no longer practical
  
• 
  JVET-K0312: add tool usage metrics to SW. SW coordinators to determine best implementation (e.g., with or without dtrace). Encourage CU-level tool proponents to add and report such metrics (proportion of samples affected by tool) – this would be highly beneficial to further assess compression benefit and complexity impact of a tool, as well as its usage in terms of sequence characteristics.
  
• 
  JVET-K0349: migrate from svn to git (GitLab) (this was previously recommended in AHG3 report)
  
• 
  JVET-K0410: add fields in Excel reporting template to capture information such as processor, SIMD settings, compiler, compiler options, decoder options
  
• 
  JVET-K0461: adopt guidelines for VVC SW development, add paragraphs on “const” variables and preference for shorter functions
  
• 
  JVET-K0390: adopt proposed rate control method and bug fixes (pending code review)
  
• 
  JVET-K0206: adopt changes into VTM (remains disabled by default). SW AHG to decide whether to enable corresponding macro (command line parameter would still disable the feature by default)
  

All recommendations of the BoG were approved in track B

The item of accessibility of CE software was discussed in JVET plenary Wednesday 18th 1445 (this issue had been mentioned in the context of discussing the BoG report). It is agreed that the CE software should only be available to JVET members of the respective period, not openly; however there is no mechanism that anybody who registers as a user for GitLab is a JVET member.

As a solution, it was concluded that CE coordinators shall control the read/write access for their own CE. It is expected that individuals subscribed to a CE are JVET members. If possible, the SW coordinators should then generate a larger group of users which would contain all participants from all CEs, who would then be given read access to all other CEs as well.

Copy the detailed dispositions about individual proposals from the 360, HDR and software BoG reports to the respective sections.