JVET-H0056 AHG8: An Update on RSP Projection [A. Abbas, D. Newman (GoPro)]

This contribution offers an modification of the previously proposed Rotated Sphere Projection (RSP) scheme. The proposed method draws inactive region on a 16x16 grid, resulting in better coding efficiency for block based coding. Additionally, a fix to WS-PSNR calculation method was proposed. Overall, a RA coding gain of 0.7% for Luma and 1.0% for Chroma is reportedly achieved over the RSP anchor (using WS-PSNR-E2E metric).

Compared to the previous RSP, the arc (circular shape) is drawn more precisely, which firstly increases the number of inactive pixels. As a second step, the arc is extended such that it is fully fitting into a 16x16 block (a kind of padding). This effectively increases the number of active pixels, but they are easier to code by a block based coder.

Decision (360lib): Replace the current RSP scheme by the method from JVET-H0056.

JVET-H0056 AHG8: An Update on RSP Projection [A. Abbas, D. Newman (GoPro)]

Decision (360lib): Replace the current RSP by the method from JVET-H0056.

General: It had been agreed by the 7th JVET meeting that the list of projection formats included in the CTC & 360Lib will not grow further, to avoid having so many that we can’t properly study them. If we want to add one, we need a decision to remove one. Anchors for projection formats are to be made available only with the HM and using ERP for the JEM. The outcome of this meeting is in line with this decision.

Project planning

Exploration Experiment planning

No EEs were established.

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 EEs).

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 Thursday 11 January 2018.

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 (as the focus in our work is on the technology rather than company business considerations).

General issues for Experiments

Note: This section was drafted during the second JVET meeting, and is kept here for information about the EE procedure. It may become relevant in the future again.

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

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.

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.

It is not necessary to formally name cross-checkers in the EE document. To promote the tool to the JEM at the next meeting, we would want to see comprehensive cross-checking done, with analysis that the description matches the software, and recommendation of the value of the tool given any relevant tradeoffs.

Software development and anchor generation

The planned timeline for software releases was established as follows:

JEM7.1 will be released by 2017-10-25.

Further versions may be released for additional bug fixing, as appropriate

Timeline of 360lib5.0: 2 weeks after the meeting (2017-11-10).

Further versions may be released as appropriate for bug fixing.

CfP anchors will be updated as necessary (assigning the same responsibilities as from the 7th meeting)

HDR: NHK/Sony will provide (and verify) HDR-A anchors (by November 10)

For SDR: HD/RA, HD/LD, UHD: Samsung/Qualcomm (no update necessary)

For 360°: InterDigital/Samsung (Nov. 10)

For HDR-B: Technicolor/Qualcomm (Nov. 10)

New HM anchors will be generated using HM 16.16. JEM anchors will be based on JEM 7.0.

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.