International organisation for standardisation organisation internationale de normalisation
Yüklə 8,24 Mb.
|
5.15Entropy coding5.15.1CABAC improvement5.15.1.1.1.1.1.1.1JCTVC-H0113 Non-CE1: Accurate initialization and conditional probability for CABAC performance improvement [E. Alshina, A. Alshin, J. H. Park (Samsung)] Two possible ways to achieve CABAC performance improvement are studied in this contribution. The first takes into account conditional probability while updating the entropy code state. The second changes probability initialization taking into account a hierarchical encoding structure. Both algorithms were implemented on top of multi-parameter probability up-date, as studied in CE1, and were reported to provide additionally 0.2% BD bit rate. First part: Extension to multi-parameter probability update model (for information). Second part: More accurate initialization of CABAC: the slope and intersection would be different for the hierarchies in B slices. The contribution reports that implicitly deriving the initialization table from the slice type would be an option instead of explicit signalling (as e.g. suggested by Sharp, see CE1). One expert suggested that there could be various structures other than the ones in common test conditions and such that implicit signalling may not always be a good solution. The gain could be higher for small slices. Further study (in an AHG) was encouraged. 5.15.1.1.1.1.1.1.2JCTVC-H0265 Non-CE1: Dimension reduced rangeTabLPS table for the interval subdivision of the arithmetic coding engine [J. Stegemann, H. Kirchhoffer, D. Marpe, T. Wiegand (Fraunhofer HHI)] This contribution presented a dimension-reduced rangeTabLPS table for the "M Coder" of HEVC. The table containing the precalculated values for the interval subdivision in the binary arithmetic coding engine was condensed from 64x4 = 256 to 16x8 =128 elements. The proposed idea is identical to the rangeTabLPS table which has been tested in CE1 subtest c3. In contrast to CE1, this proposal discusses the performance of the reduced table in combination with the probability estimator of the M Coder. The size of table was proposed to be reduced by half, with no significant change in compression. It was commented that, depending on implementation, it could be that the number of operations (in software) might be more important. Even though this may be a good idea, we should be careful about making changes at this stage that may have implications that are not well understood. No action was taken on this. 5.15.1.1.1.1.1.1.3JCTVC-H0590 Non-CE1: Cross-check of proposal H0265 on rLPSTable [V. Sze (TI)] [late 02-04]
This contribution reported a difference between the HM software and the WD text on CABAC context derivation for partition mode information. In order to improve the situation, it was proposed to apply bypass mode for the 3rd and 4th bins of the syntax part_mode. The proposed modification was reported to cause no impact on coding efficiency. The proposal was to remove the context in binIdx 2 and 3, replacing by bypass coding. Related contributions were noted to include H0545 and H0327. 5.15.1.1.1.1.1.1.5JCTVC-H0545 Context modeling for asymmetric partitioning on partition mode [W. -J. Chien, X. Wang, M. Karczewicz (Qualcomm)] [late] This contribution proposed reducing the number of contexts for partition mode for asymmetric partitioning. The number was proposed to be reduced by 3 contexts. Experimental results reportedly showed no BD bit rate changes in random access and low-delay test conditions. The proposal was similar to H0099, but different for the third bin. The rationale is that if an encoder is not using AMP, the solution of H0099 would lose 0.2% in compression performance. Decision: Adopt the solution of H0545 (which was agreed by contributors of H0099 and H0327). 5.15.1.1.1.1.1.1.6JCTVC-H0581 Crosscheck of context modeling for parition mode (JCTVC-H0545) [T. Yamamoto (Sharp)] [late]
This contribution proposed to use bypass coding of the bin for MVP index and the bins for AMP mode info. The two simplifications reportedly showed 0.0% BD bit rate change on average. The first part was identical with H0099. The second part proposed bypass coding for the MVP index. There was no support from other experts – and no action was taken on this. 5.15.1.1.1.1.1.1.8JCTVC-H0121 Cross Check for Huawei's CABAC simplification (JCTVC-H0327) [Y. Shibahara, T. Nishi (Panasonic)]
This document proposed a clean-up of the CABAC usage in the HM5.1 reference software and in Working Draft 5 to remove a redundant invocation of CABAC state storage. Some CABAC storage is redundant in the case of wavefront processing It was commented that, as discussed in a breakout group, dependent tiles will most likely not be supported, and wavefront and tiles will not be used together. This is most likely an implementation issue, and no action was taken on it, as the tiles/wavefront design is still undergoing changes and the associated text will probably need to be cleaned up in other ways anyway. 5.15.1.1.1.1.1.1.11JCTVC-H0271 AHG9: CABAC with constrained outstanding bits [T.-D. Chuang, C.-Y. Chen, Y.-W. Huang, S. Lei (MediaTek)] This proposal was (at lesat partly) presented previously in JCTVC-F059. In the HM, there is no constraint on the number of pending bits to be produced in CABAC encoding. Theoretically, the number of outstanding bits could be very large. Practically, the number was up to 189 in the presented analysis. When a lot of outstanding bits are accumulated, a sudden increase of output bits will occur, which was asserted to complicate hardware design significantly. In this contribution, two coding interval adjustment procedures were proposed to constrain the number of continuous outstanding bits. One was to divide the coding interval into two parts at 512. The other one was to code a bypass bin. It was reported that the proposed methods cause no differences in coding efficiency and have roughly the same run time, while reducing the number of pending bits to at most 18 bits. Up to 189 outstanding bits were reportedly observed under common test conditions. By adjusting code intervals, it was reported that this can be constrained to 18 bits. Two methods were proposed, one of which was previously proposed in the 6th meeting, where the assessment was that this is not a problem and can be solved by implementation-specific methods. The new method is said to be less complex, but still adds obvious complexity. There was no support for this by other experts, and no action was taken on this. 5.15.1.1.1.1.1.1.12JCTVC-H0648 AHG9: Cross-check result of MediaTek CABAC with constrained outstanding bits (JCTVC-H0271) [K. Kazui (Fujitsu)] [late]
In HM5.0, there are 4 contexts for split_transform_flag. This contribution proposed to reduce the number of contexts for split_transform_flag from 4 to 1, which would means that all contexts would share one single context. Experimental results reportedly showed that BD bit rate changes are 0.0% for AI HE, 0.0% for AI LC, 0.0% for RA HE, 0.0% for RA LC, 0.1% for LD HE, 0.0% for LD LC, and 0.1% for RA HE10. The split transform flag of RQT has 4 contexts in WD5, but space for 10 is reserved in the HM5 software (most likely only 4 are used). It was suggested that reducing this to only one context (used for all sizes) can be done with a slight reduction of compression (0.14% in LB, less in other cases). No action was taken on this. 5.15.1.1.1.1.1.1.14JCTVC-H0626 Cross-check of Sony proposal on context reduction of split_transform_flag in CABAC (JCTVC-H0397) [H. Yang, H. Yu (Huawei)] [late]
In the current HEVC software/WD, each slice type (I/P/B) has its own initialization value set. This contribution proposes to share the initialization values for contexts from different slice types to reduce the storage. Two methods were described. In the first method, P slices and B slices share the same initialization set. In the second method, for a subset of contexts, the same initialization values are shared for all three slice types. Experimental results under common test condition and common test condition with 1500 bytes slices were provided. A subset of contexts was defined which has common initialization over all slice types. Two methods were described, with the number of initialization values reduced from approximately 600 to 400, and even less when the full combination is used. No significant loss in compression performance was reported (for one slice per picture and 1500 byte slices). 5.15.1.1.1.1.1.1.16JCTVC-H0671 Cross-check for Qualcomm CABAC Initialization in JCTVC-H0561 [X. Guo (MediaTek)] [late] 5.15.1.1.1.1.1.1.17JCTVC-H0646 Reduction of initialization tables for CABAC contexts [K. Sugimoto, A. Minezawa, S. Sekiguchi, K. Asai, T. Murakami (Mitsubishi)] [late] This contribution proposed reducing the initialization tables for CABAC contexts. The proposed method uses only one initialization table with 253 entries instead of three tables as in HM5. Simulation results reportedly show that performance loss is 0.4%, 0.3%, 0.1%, 0.1%, 0.1%, 0.0%, and 0.0% for AI-HE, AI-LC, RA-HE, RA-LC, RA-HE10, LB-HE and LB-LC settings, respectively, using HM-5.1 in multiple 1500 byte slice mode. It was also reported that under common test conditions using HM-5.0, the loss is 0.0% for all mandatory common test conditions. The proposal is to use only one initialization table (the third table of the current HM) for all slice types. No significant loss was reported for one slice per picture usage, with a slight loss (up to 0.4% for intra only) in case of 1500 byte slices. Further study (in an AHG) was encouraged. Giving up flexibility in initialization may not be desirable if we are not sure what we are doing, and we need to consider whether possibly some of the current initialization is already tuned towards the test set. 5.15.1.1.1.1.1.1.18JCTVC-H0251Context reduction for merge index coding [O. Bici, J. Lainema, K. Ugur (Nokia)] In this contribution, it is proposed to use a single context for merge index coding by CABAC. The merge index consists of four bins, and HM5 assigns one context for each bin, totalling 4 contexts. In the proposed method, one context is used for the first bin and the remaining three bins are coded in bypass mode. The reported compression efficiency impact in terms of BD bit rate is 0.0% for all the RA HE, RA LC, RA HE_10, LB HE and LB LC configurations. The current HM uses 4 contexts (1 per bin) but there is a deviation between the SW and WD. It is suggested to assign 1 context for the first bin and bypass coding for the remaining three bins. Decision: Adopt. 5.15.1.1.1.1.1.1.19JCTVC-H0367 Cross-check of context reduction for merge index coding (JCTVC-H0251) [J. Xu (Microsoft)] Yüklə 8,24 Mb. Dostları ilə paylaş:
|