International organisation for standardisation
Yüklə 9,08 Mb.
|
6.13Entropy coding6.13.1CAVLC6.13.1.1.1.1.1.1.1JCTVC-F286 Redundancy removal for Run-mode in CAVLC [J. Xu, A. Tabatabai (Sony)] This proposal removed the redundancy in Run-mode coding of CAVLC by replacing unary code with truncated unary code. Experimental results show that the BD-rate saving is 0.1% for Intra only, 0.1% for random access and 0.0% for low delay B under low complexity configuration. No support for adopting this. 6.13.1.1.1.1.1.1.2JCTVC-F676 Cross-check for Sony’s Proposal (JCTVC-F286) on Redundancy removal for Run-mode in CAVLC [Z. Zhou, S. Liu (MediaTek)] [late reg. 07-07, upload 07-07] 6.13.1.1.1.1.1.1.3JCTVC-F298 Run-level table reduction for CAVLC [L. Guo, X. Wang, M. Karczewicz (Qualcomm)] In current HM software, a run-level table of size 434 is used in the coding of Inter block coefficients (as well as Intra Chroma block coefficients). This contribution reduces the run-level related table sizes from 434 to 148. The Luma B-D rate changes for different cases are 0.00% AI, −0.14% RA, 0.03%LD, and 0.06% LDP. Question: Is the new table available as part of the contribution? Apparently not. JCTVC-F160, JCTVC-F407, JCTVC-F543 are similar. 6.13.1.1.1.1.1.1.4JCTVC-F406 Coefficient coding in CAVLC [S. Kim, J. Lee, K. Lim, S. Lee (Yonsei Univ.), J. Chen, J. Park (Samsung)] [late upload 07-12] 6.13.1.1.1.1.1.1.5JCTVC-F160 CAVLC table-size reduction for Inter/chroma run-level coding [T. Davies (Cisco)] A modification to the method for computing code numbers for run-level pairs in inter and chroma blocks is proposed. This reduces the size of the table used from 434 bytes to 104 bytes. For I_LC, RA_LC, LDB_LC and LDP_LC the BD-rate performance is reported to be 0.0%, 0.0%, 0.0% and 0.1%. There is no reported significant change to encoder or decoder simulation times. Very slightly worse than JCTVC-F298, but again a smaller table. Major differences: Lower “switching point”, and formula to compute cn is different. 6.13.1.1.1.1.1.1.6JCTVC-F313 Verification Results of run-level CAVLC table-size reduction (JCTVC-F160) [E. Maani (Sony)] [initial version rejected as placeholder; corrected version late upload 07-06] 6.13.1.1.1.1.1.1.7JCTVC-F407 Run-mode coding improvement with table reduction in CAVLC [J. Lee, S. Kim, K. Lim, D. Pak, S. Lee (Yonsei Univ.), J. Chen, J. Park (Samsung)] In this report, a scheme is proposed to determine code number, for inter block, without run-level table. From this approach, the memory size to storage table can reportedly be reduced from 870 bytes to 220 bytes. Simulation results show that coding gains are −0.01%, −0.19% and 0.04% for all intra, low delay and random access configurations respectively. Yet another approach with larger remaining table size, but slight advantage in terms of compression. 6.13.1.1.1.1.1.1.8JCTVC-F635 Crosscheck report for JCTVC-F407 on CAVLC run-mode coding from Yonsei Univ. and Samsung [X. Wang (Qualcomm)] [late reg. 07-04, upload 07-14 after opening] 6.13.1.1.1.1.1.1.9JCTVC-F543 Tableless run-length coding for transform coefficients in CAVLC [A. Hallapuro, J. Kang, J. Lainema, K. Ugur (Nokia)] The contribution proposes a tableless algorithm for run-length coding of transform coefficients in CAVLC. An equation is used for generating the run-length values with special emphasis on the longest run-length value. It is reported that up to 812 bytes of memory required by the HM3 design can be saved in both encoder and decoder. The contribution reports average BD bitrate impact of −0.1% for intra LC, −0.1% for random access LC and +0.1% for low delay LC configurations. No cross-check available by the time of presentation (it is said that TI is working on this). Some experts think that this is an even more elegant approach (table size zero); however the additional complexity of formula computation may be a concern (even though the formula could again be replaced by a table). It was agreed to establish a BoG to get common understanding (coordinated by Thomas Davies), come back with an agreed solution, otherwise establish a CE in CE5. 6.13.1.1.1.1.1.1.10JCTVC-F750 Cross-check of Nokia's proposal on Tableless run-length coding for transform coefficients in CAVLC (JCTVC-F543) [V. Sze, M. Budagavi (TI)] [late reg. 07-16, upload 07-17]
This contribution proposes CAVLC adaptation using a difference counter which does not require the normalization process used in the counter-based CAVLC method adopted in HM-3.0. The proposed method could reportedly also reduce the number of required counters while keeping coding gain achieved by the current counter based adaptation method. Further study (CE5). 6.13.1.1.1.1.1.1.12JCTVC-F428 Cross-check of JCTVC-F395 by Sharp [Y. Morigami, K. Sato (Sony)] [upload 07-11] 6.13.1.1.1.1.1.1.13JCTVC-F458 Improvement of CAVLC run- coding by prediction mode [C. Kim, Y. Park (Samsung)] In this contribution, a scheme is proposed to run-level coding according to prediction mode of block. The contributor reported that the scheme has −0.2%/−0.1%/0.0% coding impacts with intra, low delay and random access low complexity configuration, respectively. No additional complexity is reported for all tests. Question: How was the mapping from prediction mode to run-level coding determined? No definite answer. Contribution noted. 6.13.1.1.1.1.1.1.14JCTVC-F621 Crosscheck report for Samsung's JCTVC-F458 on CAVLC run coding [X. Wang (Qualcomm)] [upload 07-14 after opening]
In this contribution, a scheme is proposed to handle exception cases for codewords larger than 32 bits in CAVLC, which leads to an error. The modified VLC tables are mixed with fixed-length codes which reportedly eliminates the need for any loop in bitstream writing and errors. It allegedly does not generate any side effect such as performance change but cover the maximum level of quantized coefficients in CAVLC. Comment: It is agreed that this is an issue. This can also happen for other cases, such as run/level coding. A more general solution would be desirable. Put study on this under mandates of entropy coding AHG 6.13.1.1.1.1.1.1.16JCTVC-F622 Crosscheck report for Samsung's JCTVC-F466 on CAVLC long codeword handling [X. Wang (Qualcomm)] [upload 07-14 after opening] 6.13.1.1.1.1.1.1.17JCTVC-F467 Improvement of CAVLC table adaptation for coefficient coding [C. Kim, Y. Park (Samsung)] In this contribution, a scheme is proposed to switch VLC tables including the last level of run-coding. The contributor said that the scheme has −0.2%/−0.1%/−0.1% coding performance improvements with all-intra, low delay and random access low complexity configurations respectively. No additional complexity was reported for all tests. Decision: Adopt 6.13.1.1.1.1.1.1.18JCTVC-F623 Crosscheck report for Samsung's JCTVC-F467 on CAVLC table adaptation [X. Wang (Qualcomm)] 6.13.1.1.1.1.1.1.19JCTVC-F199 A further improvement of inter prediction direction and reference frame index combined coding in CAVLC [B. Li (USTC), J. Xu (Microsoft), H. Li (USTC)] This document presents proposed changes of “(a)” the combined coding of inter prediction direction and reference frame index in CAVLC. The contributor said that the BD-Rate difference is negligible under the default test configuration. But when the number of reference frames is reduced, about 0.2% bits saving were reportedly obtained on average. A second proposed aspect was “(b)”, to move the adaptive algorithm to decide using combined coding or not, from CU to PU to make the specification simpler. Changing the adaptation algorithm from CU to PU will reportedly not have much impact on the performance. Decision: Adopt (a) part only. 6.13.1.1.1.1.1.1.20JCTVC-F615 Cross-verification of Microsoft's JCTVC-F199 by Samsung [T. Lee, J. Chen (Samsung)] [late upload 07-05] 6.13.1.1.1.1.1.1.21JCTVC-F408 CE5: Run and level mode coding improvement in CAVLC [S. Kim, J. Lee, S. Lee (Yonsei Univ.), J. Chen, J. Park (Samsung)] In this contribution, some experimental results of CAVLC changes proposed in JCTVC-E446 are reported. Other modifications are also considered. The reported simulation results are −0.7%, 0.0%, −0.4% in all intra, low delay and random access configurations, with reducing 540 bytes. Further study (CE). 6.13.1.1.1.1.1.1.22JCTVC-F608 Removing chroma zonal coding in CAVLC [M. Karczewicz, X. Wang, W.-J. Chien, L. Guo (Qualcomm)] This contribution proposes removing the CAVLC zonal coding as currently applied to chroma blocks with a size of 16x16 or larger. Instead, code those chroma blocks normally with coefficients at every frequency location included. Several experts expressed the opinion that this is highly desirable and makes the design more consistent. Decision: Adopt. 6.13.1.1.1.1.1.1.23JCTVC-F723 Cross-verification of JCTVC-F608 and JCTVC-F296 by Nokia [K. Ugur, O. Bici (Nokia)] [late reg. 07-12, upload 07-15] See also section on JCTVC-F296. 6.13.1.1.1.1.1.1.24JCTVC-F612 Modifications to intra blocks coefficient coding with VLC [M. Karczewicz, Y. Zheng, L. Guo, X. Wang (Qualcomm)] Coding results after modifying the tables used in VLC coding are presented. It is further proposed to extend usage of horizontal and vertical scans to 16x16 and 32x32 blocks. In addition this contribution proposes to modify coefficient coding for 16x16 and 32x32 blocks. When all these 3 modifications are applied the average gain of 1.4%, 0.6%, and 0.3% was reported for all intra, low delay and random access configurations. Item 1 (tables) gives 0.5%/0.2% and 0.1% for AI/RA/LD. Several experts support item 1 (new VLC tables) – Decision: Adopt item 1. (There was however some concern expressed by the contributors of JCTVC-F408.) Other items are to be investigated in CE5. 6.13.1.1.1.1.1.1.25JCTVC-F667 Cross-check of JCTVC-F612 on CAVLC Intra coding. [Thomas Davies] [late reg. 07-06, upload 07-11] 6.13.1.1.1.1.1.1.26JCTVC-F465 Item 3 (Direct coding of Intra DC coefficient in CAVLC mode) of Experiments on tools in Working Daft (WD) and HEVC Test Mode (HM-3.0) [I.-K. Kim, E. Alshina, J. Chen, T. Lee, W.-J. Han, J. H. Park (Samsung), V. Sze, M. Budagavi, M. Zhou (TI)] Item 3: Direct coding of Intra DC coefficient in CAVLC mode The text doesn't actually describe the special-case behaviour that's in the software, which seems to provide no benefit as tested (even with many slices). Decision: Adopt the simplification (with a compile flag to revert). If no evidence of usefulness is provided, we'll consider using the prior behaviour. Text doesn’t have the complication anyway. 6.13.1.1.1.1.1.1.27JCTVC-F465 Item 7 (Adaptive switching on/off combined coding for CAVLC) of Experiments on tools in Working Daft (WD) and HEVC Test Mode (HM-3.0) [I.-K. Kim, E. Alshina, J. Chen, T. Lee, W.-J. Han, J. H. Park (Samsung), V. Sze, M. Budagavi, M. Zhou (TI)] Item 7: Adaptive switching on/off combined coding for CAVLC. Was adopted from JCTVC-F470. If some evidence of usefulness is later provided, we can re-enable it.
Yüklə 9,08 Mb. Dostları ilə paylaş:
|