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

8Extended colour volume coding (0)

Contributions in this category were discussed XXday XX April XXXX–XXXX (chaired by XXX)No contributions were noted in this category.

9Coding of 360° video projection formats (1)

Contributions in this category were discussed Thursday 19 April 1300–XXXX (chaired by JRO and GJS).

JVET-J0044 AHG8: Geometry padding for PERP [P. Hanhart, Y. He, Y. Ye (InterDigital)] [late]

This contribution was discussed Thursday 19 April ~at about 1310 (GJS(chaired by GJS & JRO).

The padded ERP (PERP) format was shown to effectively reduce the seam artefacts in reconstructed viewports that encompass the left and right boundaries of the ERP picture (see JVET-G0098). Therefore, the PERP format was selected as the format used for the HM and JEM anchors for the 360° category in the joint CfP (JVET-H1002). However, padding and blending may not be sufficient to completely resolve the seam issue, as a seam artefact is still visible in the HM and JEM anchors for the Chairlift sequence. It wais reported that the seam artefact in the Chairlift test sequence is particularly visible during video playback, as the video appears to flicker where face seams occur.

Geometry padding of the reference pictures was previously proposed for motion compensated prediction (JVET-D0075). Compared to the repetitive padding method used in HEVC, geometry padding can provide meaningful samples and improve the continuity of neighbouring samples for areas outside of the reference picture boundaries. For HM-16.12 and 8K ERP sequences, average BD-rate reductions of 0.3% and 0.8% were previously reported for the ERP and cubemap formats, respectively.

This proposal investigates the performance of geometry padding for motion compensated prediction when encoding in the PERP format. The simulation results using the CfP settings reportedly show that geometry padding achieves average BD-rate reduction of 0.23%, with up to 0.98% savings for Chairlift, at a similar complexity as the JEM. More importantlysignificantly, it is reported that geometry padding combined with the PERP format completely solves the seam artefact problem. It was reported that no seam artefact was visible in the contributor's expert viewing for the reconstructed viewports located near the PERP boundaries when the geometry padding was used.
It wais reported that for 360 360° sequences with fast- moving camera, the boundary is still visible. Geometry padding can resolve this (used in addition to padding of 8 samples at each side) can reportedly resolve this. It wais reported that this combination (plus blending) helped to remove this effect.

It had also been suggested by other experts prior to the presentation that extending the padding area in conventional padding could help, but it wais reported that it this did not fully remove the artefacts, and further caused bit rate increase.

Further, the same as with geometry padding approaches proposed in the context of other projection formats, the decoder would need to know where the boundary is, and it would need to know the manner of continuation at the other side.
The anchor used in the CfP used 8-sample padding with linear blending across the boundary. The contributor said that using a wider band, 32 samples, seems to largely eliminate the seam artefact, but produces some reduced or blurred appearance in the blended region and has a bit rate overhead of about 1%. Using a padding of 16 samples produces something in between, with perhaps a 0.3% bit rate penalty.

The proponent said they could show the effect on viewing equipment available at the meeting.

It was commented that the standard could specify modulo wrapping by the picture size for picture location referencing for the ERP projection mapping, which could be supported in a decoder by padding with the maximum block width and modulo wrapping of the block vectors.

For other projection formats, there would be more complicated implications of this sort of wrapping.

Can beIt was recommended for this to be further studied in an AHG on 360° video coding.

10Complexity analysis (4)

JVET-J0083 Memory usage analysis in available software packages of the responses [K. Kawamura, S. Naito (KDDI)] [late]

This contribution was discussed Sunday 15 April 1710–1715 (chaired by JRO).

This contribution presents a memory usage analysis in available software packages that were available during the first week of the meeting. Some parameters like QP and resolution are variedying to confirm the dependency to on them. The memory usage of both the encoder and decoder is one of the point elements of such a complexity analysis. In general case, the memory usage of the encoder is larger than that of the decoder. When an the encoder memory usage is small, such the encoder can be tested simultaneously with multiple conditions under athe given amount of memory.

The iInformation provided in the contribution was noted. It wais remarked that memory usage may be dependent on the amount of tools that is are implemented in a software package. There weare no conclusions that can could currently be drawn from herethis.

JVET-J0090 AHG5: Measurement result of memory bandwidth comparison with JEM and HM [R. Hashimoto, S. Mochizuki (Renesas)] [late]

This contribution was presented Thu 19 April 1120-1210.

This contribution shows a comparison between the memory bandwidth in JEM7.1 and that in HM16.16. At the 9th JVET meeting in Gwangju, JVET-I0033 showed the measurement results of memory bandwidth in JEM7.1. Based on comments to about that analysisit, this contribution shows additional results. This method can be used to check memory bandwidth in the test model for the next video standardization work and be evaluated inprovide comparison with HEVC.

The comparison was based on CfP anchor bit streams.

The tool is capable of analysing the external memory bandwidth and cache memory bandwidth of a decoder, and is configurable for different cache configurations.

The results indicate that the average external memory bandwidth of the JEM is 6.4×x higher in RA, and 4.0×x higher in LD when, compared to the HM (for the configuration B cache size of 64 kbytes). One effect observed was a tendency for the bandwidth (both external and cache) to be becoming higher in the JEM towards lower bit rates, whereas the HM shows a tendency for the bandwidth to increase towards higher bit rates.

It would require more analysis, with switching tools on or off, to get information which tools are requiring which amount of memory bandwidth.

The tool is only capable ofto computing thee average decoder memory bandwidth for a given set of test sequences. For analysing worst cases, special bitstreams would be necessary.

Question: HowIt was asked how much is the decoder slowed down when using the tool.? This was aApproximately 2x; it would be necessary to run the decoder again to measure the memory bandwidth.

It was commented that still the precise amount of memory bandwidth would be dependent on a given hardware platform. Nevertheless, the information that can be provided by the tool is very interesting to identify possible memory bandwidth problems of tools (and of an overall algorithm).

Decision (SW): Implement the tool in the test model software. It would be desirable to use it in the context of CEs starting from the next meeting.

Further development of the model (e.g. with other cache block sizes) is to be discussed in an AHG.

It was also commented that the bandwidth consumption of a tool is likely different when executing a “tool on” test (with the simple VTM not using other tools in parallel) and a “tool off” test (in BMS configuration). This aspect needs further study.

JVET-J0091 Cross-check of JVET-J0090 Measurement result of memory bandwidth on JEM [G. Li] [late]

The JEM results were confirmed.

JVET-J0092 Cross-check of JVET-J0090 Measurement result of memory bandwidth on HM [T. Zhou, T. Ikai (Sharp)]

The HM results were confirmed.