JVET-B0076 Report of BoG on selection of test material [T. Suzuki, J. Chen (BoG coordinators)]

The BoG selected some sequences for viewing.

We would like to select about 4 sequences per category, after viewing. A goal was to replace Class A at this meeting.

Selection focused on the application domain category. Categories are: Moving vehicle, surveillance, sports, TV/movie, people, high frame rate, and texture.

25 sequences were identified for viewing. It was agreed to put a priority on QP37, because of hard drive capacity limit in the viewing room equipment. Only 8 bit viewing was available with this equipment.

Due to contention for viewing room availability, it was agreed to look into moving the equipment to another room for the viewing session Tuesday afternoon.

New sequences were proposed for screen content coding. The JEM doesn’t include the SCC tools, so it was agreed to defer consideration of such sequences until the next meeting, since the priority for this meeting is replacing the Class A sequences.

Further discussed on Wednesday.

Two new class A categories with different characteristics were proposed.

• A1: People : Tango, Drums (100), CampfireParty, ToddlerFountain
• A2: Others : CatRobot, TrafficFlow, DaylightRoad, RollerCoaster

It was asked whether the number of frames should be reduced, and agreed to use 300 frames to encode, regardless of frame rate.

The suggested sequences are mostly 50 or 60 fps, but Drums is 100 fps, and CampfireParty and TrafficFlow are 30 fps.

Class A isn’t tested with LD in the current common test conditions.

All discussed candidate sequences are 4:2:0, 10 bit.

It was remarked that the Drums sequence is 100 fps and with the parallel encoding, it can only be split into 3 parallel segments.

For RollerCoaster, it was agreed to start 600 frames into the sequence. A new sequence will be created starting at the offset position and given a slightly different name.

Agreed on Wednesday was to replace the prior Class A sequences with 8 new sequences in 2 categories as listed above, 300 frames each.

Participants are encouraged to make recommendations at the next meeting to replace sequences in other categories, possibly by downsampling higher-resolution sequences.

BoG on Call for Test Material [A. Norkin (BoG coordinator)]

A BoG on on a Call for Test Material (coordinated by A. Norkin) was held Thu. morning. The result of this BoG activity, after its review and refinement at the meeting, is the output document JVET-B1002. The following types of content were initially identified as currently missing: HDR, Sports, Gaming, High/complex Motion, UGC, panoramic, VR, Nature, and 8K.

List of actions taken affecting the JEM2

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 JEM2 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.

• Encoder only
  • JVET-B0036
    • IRAP-level parallel encoding
    • AI subsampling
  • JVET-B0039
    • Cfg: GOP16
    • QP lambda change
  • JVET-B0041
    • Simplification #1a and #2
• Normative change (i.e., affecting the bitstream format or output of the decoding process)
  • JVET-B0038
    • Harmonization of AFFINE, OBMC and DBF
  • JVET-B0051
    • non-MPM mode coding
  • JVET-B0058
    • 1/16 pel motion vector storage accuracy

Project planning

JEM description drafting and software

The following agreement has been established: the editorial team has the discretion to not integrate recorded adoptions for which the available text is grossly inadequate (and cannot be fixed with a reasonable degree of effort), if such a situation hypothetically arises. In such an event, the text would record the intent expressed by the committee without including a full integration of the available inadequate text.

Plans for improved efficiency and contribution consideration

The group considered it important to have the full design of proposals documented to enable proper study.

Adoptions need to be based on properly drafted working draft text (on normative elements) and HM encoder algorithm descriptions – relative to the existing drafts. Proposal contributions should also provide a software implementation (or at least such software should be made available for study and testing by other participants at the meeting, and software must be made available to cross-checkers in CEs).

Suggestions for future meetings included the following generally-supported principles:

• No review of normative contributions without draft specification text
• JEM 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 Monday 16 May 2016.

As general guidance, it was suggested to avoid usage of company names in document titles, software modules etc., and not to describe a technology by using a company name.

General issues for Experiments

Group coordinated experiments have been planned. These may generally fall into one category:

• "Exploration experiments" (EEs) are the coordinated experiments on coding tools which are deemed to be interesting but require more investigation and could potentially become part of the main branch of JEM by the next meeting.
• 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. (E. Alshina will edit the document based on input from the proponents, review is performed in the plenary)
• Software for tools investigated in EE is provided in a separate branch of the software repository
• During the experiment, further improvements can be made
• By the next meeting it is expected that at least one independent party will report a detailed analysis about the tool, confirms that the implementation is correct, and gives reasons to include the tool in JEM
• As part of the experiment description, it should be captured whether performance relative to JEM as well as HM (with all other tools of JEM disabled) should be reported by the next meeting.

It is possible to define sub-experiments within particular EEs, for example designated as EEX.a, EEX.b, etc., where X is the basic EE number.

As a general rule, it was agreed that each EE should be run under the same testing conditions using one software codebase, which should be based on the JEM software codebase. An experiment is not to be established as a EE unless there is access given to the participants in (any part of) the TE 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-B1010.

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 company proponent perspective – e.g. 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 EE work should identify individuals in addition to company names.

EE descriptions should not contain excessively verbose descriptions of a technology (at least not unless the technology is not adequately documented elsewhere). Instead, the EE 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 referenced documents that are also available in the JVET document archive.

Any technology must have at least one cross-check partner to establish an EE – a single proponent is not enough. It is highly desirable have more than just one proponent and one cross-checker.

Some agreements relating to EE activities were established as follows:

• Only qualified JVET members can participate in an EE.
• Participation in an EE is possible without a commitment of submitting an input document to the next meeting.
• All software, results, documents produced in the EE should be announced and made available to all EE participants in a timely manner.

This was further discussed Tuesday AM, chaired by JRO and J. Boyce.

A separate branch under the experimental section will be created for each new tool include in the EE. The proponent of that tool is the gatekeeper for that separate software branch. (This differs from the main branch of the JEM, which is maintained by the software coordinators.)

New branches may be created which combine two or more tools included in the EE document or the JEM. Requests for new branches should be made to the software coordinators.

We don’t need to formally name cross-checkers in the EE document. To promote the tool to the JEM 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 trade-offs.

Timeline:

T1 = JEM2.0 SW release + 4 weeks: Integration of all tools into separate EE branch of JEM 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 T2

3^rd parties encouraged to study and make contributions to the next meeting with proposed changes

T2: JVET-C meeting start – 3 weeks: Any changes to the exploration branch software must be frozen, so the cross-checkers can know exactly what they are cross-checking. An SVN tag should be created at this time and announced on the JVET reflector.

This procedure was agreed on Tuesday.

Common test conditions:

• Intra-frame sub-sampling of 8
• Parallel encoding of RA
• Replacing Class A sequences (see notes for BoG report JVET-B0076). Maintaining other sequences for this meeting cycle.
• Tools not currently included in the main branch are QTBT and signal dependent transforms. A tool can be in the main branch without being enabled in the common test conditions.
• QTBT should be included as an EE. Not included in the common test conditions defined at this meeting.
• Signal dependent transforms usage is not enabled in the common test conditions defined at this meeting.

Above common test conditions characteristics were agreed on Tuesday.

Software development

Software coordinators will work out the detailed schedule with the proponents of adopted changes.

Any adopted proposals where software is not delivered by the scheduled date will be rejected.

The planned timeline for software releases was established as follows:

• JEM2 will be released within 2 weeks (2016-03-11)
• The results about coding performance will be reported by 2016-03-18

Output documents and AHGs

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.