This proposal reports on a technique to remove the look-up tables within the CABAC engine, replacing them with arithmetic operations. Claims are made that this could potentially reduce hardware size and complexity even if the Context Variables used are all increased from 7 to 8-bit. Results are reported for two different variants of the system, showing average {Y, U, V} BD-rate changes of {0.0%, 1.1%, 1.1%}
and {0.0%, -0.9%, and -1.0%} respectively; encoder and decoder processing times were 101% and 100%
respectively for both systems.
Two methods: One multiplier-based, one adder-based.
Increase of complexity of CABAC only? Some runtime numbers are given, but in software, the update is still implemented as table.
General hint: Whenever a change is made to the core of the CABAC engine, a more in-depth study should be performed on complexity impact (software, hardware).
JCTVC-G504 CABAC with Combined Context Variables [K. Sharman, J. Gamei, N.
Saunders, P. Silcock (Sony)]
This proposal presents an adaption of the CABAC entropy coder that is claimed to be able to decode multiple coefficients per clock and therefore capable of decoding even the sustained worst case for 4:4:4 data.
The reported method encodes or decodes all of the required CABAC context variables (CV) for each coefficient in a single cycle using a quaternary arithmetic coding function; the bypass (sign and escape codes) are not explicitly discussed in this report, although a method whereby the bypass data can be decoded in parallel to the CV CABAC data is assumed, such as claimed in JCTVC-G494 “CABAC Packet-based Stream”.
The reported method encodes or decodes coefficients in a single pass of the data. Problems regarding the speculation required to maintain the throughput are discussed, and it is indicated that with changes to the CV selection system, speculation for large blocks (16x16, 32x32) can be completely removed. For small blocks (4x4 and 8x8), two methods of CV selection are presented that reduce speculation to 2 levels and 3 levels respectively (that is, a system with 2 levels of speculation would prepare 2 possible values per coefficient, requiring less than 2x the amount of logic than that of a system with no speculation). Results are presented that indicate average BD-rate changes of +0.1%, -1.1% and -1.2% for Y, U and V respectively for the 3x speculation system, and average BD-rate changes of +0.2%, -1.0% and -1.1% for Y, U and V respectively for the 2x speculation system. In both systems, the context variables have not been re-optimized/adjusted from the values in HM4.0.
In addition, results are presented for an unoptimized packet-based system with 2 levels of speculation that indicates average BD-rate changes of 0.2%, -1.0% and -1.1% for Y, U and V respectively; the software times have increased by 3% and 0.5% for the encoder and decoder, with increases believed to be caused by the deferred ACV update mechanism and the neighbourhood-based method to select context variables ACV1 and ACV2, both designed to reduce the speculation requirements in hardware.
Further Study in AHG on throughput of coefficient entropy coding (still to be decided whether we will have this)?.
JCTVC-G934 Non CE1: cross-check for CABAC probability up-date modification from Sony (G501, 504) by Samsung [A. Alshin, E. Alshina, J.H. Park (Samsung)]
[late]
JCTVC-G570 Byte alignment overhead reduction [S. Esenlik, M. Narroschke, T. Wedi (Panasonic)]
In the current HM4.0 byte alignment is used in various places in order to facilitate several purposes such as Emulation Prevention Byte (EPB) insertion and alignment of the bitstream in the encoder and decoder.
The proposal introduces a coding method for the coding of syntax elements such that byte alignment condition is achieved automatically and the need for an explicit byte alignment function is eliminated. As a result the 0.1% bit rate reduction is achieved on average.
No support for adoption.
JCTVC-G972 Cross-verification of Panasonic’s proposal JCTVC-G570 on byte alignment overhead reduction [O. Bici, J. Lainema, K. Ugur (Nokia)] [late]
Cross checker could see some advantage, but is neutral in terms of adoption
JCTVC-G716 On CABAC Init IDC [K. Misra, A. Segall (Sharp)] [late]
This contribution proposes modification of the cabac_init_idc indicator that is associated with CABAC initialization. In HEVC, cabac_init_idc is carried over from the H.264/AVC design but not well defined.
Specifically, the indicator appears in the HEVC WD but not in the HM software. This document proposes to define the meaning of this indicator. Compared to H.264/AVC, the proposed approach results in fewer tables available for CABAC initialization (reduced from seven to three). Additionally, the proposed approach allows different slice types to use the same table. Results show that the method provides improvements in coding efficiency. It is asserted that the proposal provides clarification to the HEVC design, simplification relative to H.264/AVC and coding efficiency improvement.
Definitely needs cleanup
Include in side activity on 8-bit initialization.
JCTVC-G983 Cross-check Sharp's contribution On CABAC Init IDC (JCTVC-G716) by Qualcomm [L. Guo] [late]
JCTVC-G837 Non-CE1: 8-bit Initialization for CABAC [L. Guo, R. Joshi, J. Sole, X.
Wang, M. Karczewicz (Qualcomm)]
This contribution describes an 8-bit initialization method for CABAC. The 8-bit m (slope) and 8-bit n (intersection) are replaced by a single 8-bit InitIdx for each context. SlopeTable (16 elements) and IntersecTable (16 elements) are introduced to convert the 8-bit InitIdx to a CABAC probability state in the initialization stage. Two sets of table values are presented in this contribution. For both of these two sets, the table look-up operations can be implemented using formula calculation and thus the table storage
is not necessary. The average BD-rate reduction is 0.0%/0.3%/0.5% /0.3% for AI/RA/LD/LDP (HE) for the first set of tables, and 0.0%/0.2%/0.4% /0.3% for AI/RA/LD/LDP (HE) for the second set of tables.
Current method of initialization is certainly not good (e.g. range of n values useless) Training was performed on class D (where the gain is a little bit larger)
8 bit initialization is seen as relevant
Another method was used in CE1 where the mapping is not linear (more staircase)
JCTVC-G913 Cross-check for Qualcomm’s proposal on 8-bit initialization for CABAC (JCTVC-G837) [Y. Piao, J. Min, J.H. Park (Samsung)] [late]
JCTVC-G155 Non-CE1: On CABAC context initialization [C. Yeo, Y. H. Tan, Z. Li (I2R)]
This contribution presents an implementation of the 8-bit CABAC context initialization proposed by HHI in JCTVC-F268. In this proposal, the initial CABAC context variable is directly computed using an 8 bit initialization value instead of first computing a PIPE index and its internal sub-state before converting that to a CABAC state. Coding results on HM-4.0 reportedly show an average Luma BD-Rate of 0.0% for each of the AI-HE, RA-HE and LB-HE configurations.
The presentation deck also contains (slide 7) some issues observed with unused contexts in WD (editors to check)
Conclusions:
Further investigate / continue CE?
8-bit context initialization is something we definitely will have in the CD, and should have it already in the next WD
Proper initialization could also be relevant in context of other decisions such as context reduction and probability.
Side activity (B. Bross, proponents of G837, G155, G716): Report back with a proposal on a reasonable method for 8-bit initialization (representation and init values)
- No consensus
- Both methods (G633 and G837/G155) would fulfill the purpose
- In the CE (G633), a piecewise linear approximation was tested. This method has been available for study for sufficient amount of time, whereas the other is a new contribution
- The method investigated in the CE was originally designed to support both PIPE and CABAC, the original code is not in best shape; now a cleaned-up version exists which has not yet been inspected.
- Conclusion: The cleaned-up version of G633 will be inspected by the proponents of G837/G155. If it is bit-wise exact, it will adopted, other the method of G837/G155 will be adopted. The CE will be continued to further improve or replace the adopted method; in the context of the CE, the algorithms for training of the respective representations(including the method of WD/HM) will be exchanged.
- Topic of G716 shall stay part of this effort.
It was confirmed (Mon 28 morning) that the cleaned-up version exactly reproduces the results that were reported in G633 in CE1c.
Decision: Adopt the cleaned-up version of G633, still to be done: Cleanup of WD text, to be checked by the investigators of software. Will be uploaded as revision of G633.
Investigation on improvement of 8-bit initialization will continue in CE1. In that context, inclusion of G716 will also be investigated.
JCTVC-G867 Non-CE1: Crosscheck of I2R's CABAC Context Initialization (JCTVC-G155) by Qualcomm [L. Guo (Qualcomm)] [late]
5.12.3 Other
JCTVC-G064 Results of the PA-Coder [H. Zhu]
The proposal reports the design, fast decoding algorithm, probability estimation and coding results of the arithmetic coder based on the probability aggregation.
Presentation not uploaded.
Word file hardly allows to understand the method and has some void chapters.
0.2% Y bit rate increase for all HE test cases.
Contribution noted.