JVET-K0274 CE2 related: Reduced complexity bilateral filter [J. Ström, P. Wennersten, J. Enhorn, D. Liu, K. Andersson, R. Sjöberg (Ericsson)]

This contribution proposes a modified version of the bilateral filter from JVET-F0034, JVET-F0096 and JVET-J0021. The main modification is a reduction in the size of the look-up table (LUT) that is used to store the filter coefficients. The contribution claims to reduce the total size of the stored variables (including the LUT) from 2783 bytes in JVET-F0096 to 816 bytes, a reduction of 71%. The proposal states that this is achieved by approximating the 34 rows in the LUT (one row is used for every qp) by four rows plus shifting. The contribution further claims that the need for a division table is removed by using the approximation proposed in JVET-J0021. The non-local filtering for inter blocks proposed in JVET-J0021 is reportedly also used. The BD rate figures for an implementation in BMS 1.0 are reported to be −0.33% / −0.52% / −0.60% for AI/RA/LD respectively, and the VTM figures are reported to be 0.33% / −0.81% / −0.59% for AI/RA/LD respectively. The BMS decoder run times are reported to be 101% / 101% / 101% for AI/RA/LD and the VTM decoder run times are reported to be 104% / 103% / 103%.

The reduction in run time is due to re-using difference computations, at the same time increasing the difference computation window which gives small compression gain.

Additional results are also presented that demonstrate almost identical results (small loss for AI, small gain for LD) when the bilateral filter is not used for 4x4 blocks. Gain becomes larger when also 4x8 and 8x4 block are disabled.

Interesting LUT reduction and computation reduction. However, the problem remains that bilateral filter is at a critical path between inverse transform and intra prediction, which might introduce latency in pipelining

It is pointed out that in software implementation the LUT operations cannot be performed in parallel.

Further study (CE) of the aspect of block size restrictions, in terms of performance and whether this resolves the latency issue (e.g. when boundary samples needed for next prediction are filtered first after the inverse transform). How many additional cycles are needed between inverse transform and before the prediction can be started? An initial analysis was shown in Track B Monday afternoon, where it was shown that the processed edge samples could be available within 10 cycles after the inverse transform is done. Further consideration necessary if that would be acceptable implementation wise. Further results are shown that the loss by further reducing the number of LUTs to 16 is marginal.

This additional information was requested to be provided in an update of the document.