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 Apr.April XXXX–XXXX (chaired by XXX).

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]

~1310 (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 (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 is 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 continuity of neighbouring samples for areas outside of the reference picture boundaries. For HM-16.12 and 8K ERP sequences, average BD-rate reduction of 0.3% and 0.8% were previously reported for 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 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 JEM. More importantly, 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.
It is reported that for 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). It is 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 is reported that it did not fully remove the artefacts, and further caused rate increase.

Further, same as with geometry padding approaches proposed in context of other projection formats, the decoder would need to know where the boundary is, and it would need to know the 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, which could be supported in a decoder by padding with the maximum block width and modulo wrapping of block vectors.

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

Can be further studied in AHG on 360.

10Complexity analysis (41)

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

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

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

Information noted. It is remarked that memory usage may be dependent on the amount of tools that is implemented in a software package. There are no conclusions that can currently be drawn from here.

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

This contribution was p

Presented Thu 19 Aprilth 1120-1210.

This contribution shows comparison between the memory bandwidth in JEM7.1 and that in HM16.16. At 9th JVET meeting in Gwangju, JVET-I0033 [1] showeds the measurement results of memory bandwidth in JEM7.1. Based on comments to it, this contribution shows additional results. This method can be used to check memory bandwidth in the test model for next video standardization and provide comparison with HEVC.

The cComparison was based on CfP anchor bit streams.

The tool is capable of analysing 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.4x higher in RA, and 4.0x higher in LD, compared to the HM (for configuration B cache size 64 kbyte). One effect is observed that bywas a tendency for the bandwidth (both external and cache) is to be becoming higher in JEM towards lower bit rates, whereas HM shows by a tendency for the bandwidth to increase towards higher bit rates.

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

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

Question: How much is the decoder slowed down when using the tool? Approximately 2x;, it would be necessary to run the decoder again to measure the memory bandwidth.

It wais 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 wWould be desirable using to use it in the context of CEs starting from the next meeting.

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

It wais also commented that the bandwidth consumption of a tool is likely different when executing “tool on” (with the simple VTM not using other tools in parallel) and “tool off” (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] [miss]

confirmed The JEM results were confirmed.

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

confirmed The HM results were confirmed.