JVET-M0453 CE5 on arithmetic coding: experiments 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6, 5.1.7, 5.1.8, 5.1.10, 5.1.11, 5.1.12, 5.1.13, 5.2, and more [F. Bossen (Sharp)]

This report provides results for the following CE5 experiments: 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.1.6, 5.1.7, 5.1.8, 5.1.10, 5.1.11, 5.1.12, 5.1.13 and 5.2. Additional variants of these experiments are considered where constants, such as initial state values and shift amounts, are modified.

Version 2 of the document provides additional results for experiment 5.2 on throughput, as well as BD-rate results for a configuration that yields no encoder run time increase.

The following table reports the decoder throughput from an actual bin stream (first 10 million context-coded bins from ParkRunning, RA configuration, QP22). Three compilers have been tested: clang 10.0 (Apple LLVM version 10.0.0), gcc 7.4 (Homebrew GCC 7.4.0) and gcc 8.2 (Homebrew GCC 8.2.0). The test bed was configured with the macro NOBRANCH_MPS either on (left half of table) or off (right half of table). Results were obtained on an Intel Xeon W-2140B CPU @ 3.20GHz.

In almost all cases the combination of clang and NOBRANCH_MPS enabled yielded the highest throughput. This configuration is thus considered for comparing the various engines.

The rightmost column in the table below reports the decoder throughput for a different bin stream (first 10 million context-coded bins from BQTerrace, RA configuration, QP22, clang, NOBRANCH_MPS enabled).

Experiments were run a second time, where each test is done 7 times and the highest throughput value is recorded. While the numbers are slightly higher, the same trends persist.

It was agreed that the second table of throughput numbers had much lower probability of having outlier values in it.

The table below summarizes the performance of various arithmetic coding engines, classifying them in three groups:

• Two states, fixed window sizes
• Two states, variable (context-adaptive) window sizes
• Single state, variable (context-adaptive) window sizes

BD rate numbers are reported as combined YUV, where BD rate numbers for Y, U and V are weighted as 90%/5%/5% to obtain a single number. This is done to account for the fact that results for individual color components can sometimes diverge.

Also provided for each engine are encoder/decoder run times relative to VTM3, as well as SW throughput results from experiment 5.2.

Within each group and each test condition the best BD rate and throughput results are highlighted in green. The worst results are highlighted in red.

Experiment numbers with a star indicate a variant, where some constants are modified as described.

The table above was copied from JVET-M0453 and then updated in group discussion to form the modified table below. The each category in the table was reviewed and particular tests that provided the highest coding efficiency in each category with good throughput numbers were highlighted for further focused discussion. The properties, similarities and differences between the tested methods were discussed.

The following table was obtained by updating the table above as follows: 1) adding 5.1.9, 2) replacing throughput numbers with the second throughput number table, and 3) keeping only rows that pertain to the CE tests.

It was suggested to look at the hardware aspect of these different engines, which was provided as part of JVET-M0025 subtest 3.

It was agreed that no hardware problem had been identified for any of the CE tests, and that such a hardware problem could be fixed if/when it was identified.

When looking at different categories, it was remarked that the “1 state, variable window” category has the highest throughput (closest to HEVC engine), and the “2 state, variable window” category has the highest coding performance. Regarding the “2 state, fixed window” category, it was remarked that this category does not need custom window size parameters for different context models, but needs re-training of initialization parameters.

Regarding custom window size parameters, it was remarked that that does not seem to increase complexity to such a degree that it justifies going for a simpler solution (i.e. fixed window size).

It was remarked that some of the coding efficiency gain from the tests that use custom window size parameters may have come from training of custom window size parameters based on the test set.

It was remarked that the initialization parameters were also trained on the test set, which also may have provided some of the coding efficiency gain.

In terms of coding efficiency, the options “5.1.3 4x5 mult (config. 1)”, “5.1.13” and “5.1.13* +new init from 5.1.2” are the most attractive options. Between “5.1.3” and “5.1.13,” the latter has a slight advantage for hardware implementations due to needing to support fewer shift values. And the difference between “5.1.13” and “5.1.13* +new init from 5.1.2” is purely due to training of initialization parameters, with the new initialization parameters providing better coding efficiency.

Decision: Adopt “5.1.13* +new init from 5.1.2”.