Organisation internationale de normalisation

Discussion

All methods come with losses for screen content classes

AI: Test 2 around 1%, Test 3 around 2%, test 5.x 0% (does not affect AI)

RA: Test 2 around 0.9%, Test 3 >2%, test 5.1 around 3%, 5.2/5.3 around 0.5%, test 5.4 around 2%

LDB: Test 2 around 1%, Test 3 around 3%, test 5.1 4-5%, test 5.2/5.3 0.7%, test 5.4 around 2.5%

It was pointed out that the results have larger variation over different sequences.

Average memory access reduction is reported.

Worst case memory bandwidth saving by the different methods needs to be reported. It should also be reported what the absolute memory consumption of the different test sequence classes are: The average numbers indicate no saving for some classes where IBC is apparently not used, but in fact these may use biprediction more frequently and be worse in memory access than some of the screen content classes.

It was generally agreed in the initial review that 5.2/5.3 seem to come with a relative moderate loss, whereas only require a change at the slice level to enable/disable certain combinations of IBC/bipred/integer MC. Before making a decision, a precise number about the saved memory bandwidth should be available.

(Further consideration of this topic was chaired by JRO as Track B Monday 06-22 at 18:00.)

After reviewing the BoG report U0175, it was confirmed that the methods are not increasing the worst-case memory bandwidth for the 4:4:4 case. However, unlike the approach of 5.2/5.3, where the text specification globally disables the joint usage of IBC and 8x8 bi-pred at the sequence level, it would be more desirable to have a solution that disallows the joint usage per slice (which could be expressed differently, e.g., that 8x8 bi-pred shall not be used when the current picture is in the active reference picture list of the current slice).

It was generally agreed that this would be an appropriate solution (per a bitstream restriction expressed in a profile specification), which comes with small loss in compression efficiency while not increasing worst case memory bandwidth.

Text was requested to be provided for both solutions 5.2 and 5.3; the BoG U0175 provided further analysis for both 4:4:4 and 4:2:0 cases.

(Further consideration of this topic was chaired by JRO and GJS on Thursday 06-25, 09:00-10:00.)

Text was provided in U0078v2 (JCTVC-T1005_profile_restriction_text) and was presented in the plenary. Some more editorial improvements were made during that meeting. It was also pointed out that the restriction should apply for using IBC in both L0 and L1. These issues are editorial and it is up to the discretion of the editors to make further alignments and improvements.

Text was provided and reviewed. Variable naming was discussed (which may be refined by the editor), and it was confirmed that we will allow the current picture to be in list 1.

The constraint is intended as a slice-level constraint (not a picture-level constraint).

A participant suggested that it would be good to find a way to syntactically prohibit violation of the intended constraint rather than making it just a bitstream conformance requirement. However, no proposal on this existed and therefore no action could be taken on it. Another participant said that may be complicated to accomplish. Further study of that possibility was encouraged. It was also remarked that, depending on how this is done, it might harm the goal of harmonization with the ordinary inter prediction design.

It was remarked that 8x8 IBC bipred does not violate the worst-case memory bandwidth, but may be prohibited with the expressed constraint. This can also be further studied.

The 5.2 proposed approach prohibits the combination of 8x8 bipred with IBC. The 5.3 proposed approach only prohibits this if the MV/IBC displacement vectors are not integers.

Decision: Adopt U0078 solution 5.3 (the less restrictive form of the constraint, to be applied in all SCC profiles).

Further study was encouraged regarding whether the constraint should be released when using IBC 8x8 bipred (which is not currently supported by the encoder), and whether a restriction via syntax rather than a semantics constraint would be better.

1.1.1.1.1.1.1.1.52JCTVC-U0175 BoG report on worst case memory bandwidth assessment [K. Rapaka]

This BoG report was presented and discussed Monday 06-22 at 18:00 (chaired by JRO).

Both memory read and write are taken into account in the bandwidth calculation. For memory reading, bandwidth is calculated as number of reference samples fetched from the memory based on some memory patterns such as 4x2 etc. It is assumed that memory can be accessed and read based on the memory patterns, that the chroma storage is not interleaved and only integer number of blocks can be fetched.

The following analysis was performed in the BoG related to CE2:

1. 
   Analysis of increase in the memory bandwidth due to intra block copy – see table below.