Of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11
SCE2: Combination of inter-layer syntax prediction and motion data compression
Yüklə 2,1 Mb.
|
- Bu səhifədəki naviqasiya:
- 4.2.2SCE2 primary contributions
- 4.2.3SCE2 cross checks
4.2SCE2: Combination of inter-layer syntax prediction and motion data compression4.2.1SCE2 summary and general discussion(Reviewed in Track B Fri 26th (JRO).) JCTVC-N0032 SCE2: Summary report of SHVC core experiment on combination of inter-layer syntax prediction and motion data compression [Christophe Gisquet, Kazushi Sato]
Basic three methods investigated as follows: 2.1: Use alternative positions of collocated bL MV The collocated position of the base layer is calculated as; xRL = ( ( xRL + R ) >> S ) << S yRL = ( ( yRL + R ) >> S ) << S where originally R=4, S=4 , subsampling is 4:1
Gives gain mostly for 2X scalability, overall the gain is marginal In terms of complexity impact, 2.1 should be roughly identical to SHM (two additional additions), no additional memory accesses or usage. It is just re-defining the position from the BL MV memory that is used to generate the motion field mapping. The question was raised whether it could happen that an MV is accessed which is outside of the BL MV memory. It is confirmed that the specification text includes a clipping operation preventing this.
2.2 would require additional memory. In the analysis made by the last meeting the additional MV memory was assessed to be increased by 40% (SNR scalability), 10-15% (spatial scalability). Analysis for on-the-fly computation (as suggested by AHG17 and confirmed by JCT-VC to be the common ground for complexity analysis) is not available yet, but likely lower. Provide analysis for on-the-fly computation. Further analysis was provided and discussion on this issue was performed in Track B on Sunday afternoon (JRO). “On-the-fly” computation in the case of MV would mean that the MV memory corresponding to the EL’s BL reference is written by the time when the base layer MV is decoded. This would in worst case require an additional memory for MV at the EL resolution, regardless whether uncompressed or compressed BL MV are used. However, in a “HLS only implementation” concept, a bigger problem could arise that uncompressed BL MV are only available on the chip and are not accessible. This was discussed in plenary on Mon. 29th. Estimated benefit of accessing internal MV memory is 0.7% for 2x scalability; less for 1.5x scalability, nothing for SNR scalability. Several experts expressed the opinion that it is undesirable to require access to the uncompressed MV memory, as this would require alteration of the BL decoder . Agreed not to access the finer granularity motion vectors. No action or further investigation on 2.2. It was also noted that the memory for MV compression is not counted (and there is no specification about limits) in the DPB, as it is usually around 3%. Therefore, several experts suggested whether it would be reasonable to re-consider the uncompressed MV field (see JCTVC-M0142 et al.). Analysis for memory consumption assuming on-the-fly computation should also be provided for that case. It was also asked whether the two-stage compression (2:1->4:1) provides the same 4:1 compressed MV field as the base spec. It was later confirmed that this is the case. Gives gain mostly for 2X scalability, overall the gain is marginal For frame-based implementation and worst-case SNR scalability, the MV memory [?] 2.3: For the motion field mapped from the base layer the motion information is replaced with motion information from a candidate enhancement layer motion field, if the candidate enhancement layer motion information is valid and does not reference its own base layer. In particular, the motion information includes - prediction mode, motion vector, reference picture POC, reference picture used as long term status. The replacement process is controlled at the sequence and slice level using syntax elements sps_override_mfm_flag and el_collocated_enabled_flag respectively. The candidate enhancement layer motion field is identified using slice level syntax elements el_collocated_from_flag and el_collocated_ref_idx. To be provided: Analysis about worst-case computation and memory accesses. JCTVC-N0233 is an extension of the (N0252) method which is said to be simpler, should also be included in this analysis. Further A high-level analysis was shown in Track B on Sunday afternoon, which showed that different items need to be checked (some at picture level, some at 16x16 block level), but did not contain sufficient detail to understand the worst-case complexity of additional comparisons. Gives gain for 2X and 1.5X cases (a bit less for the latter) (redundant with notes at the very end of this section) Further worst case complexity analysis presented Thursday evening: 2 checks at slice level 4 checks at block level, each for L0 and L1 Checking for POC difference over whole ref pic list could be time consuming at block level, but could be shifted to slice level (15 checks then) and lookup at block level No gain for AI and LD cases, however a smart encoder could potentially switch the tool off for these cases. Currently we do not use joint optimization of base and enhancement layer – how would the tool perform in that case? Further study – would be desirable to also achieve gain in LD case. Specification text for 2.2 and 2.3 was not available initially. It was presented in Track B Sunday afternoon for both proposals. The text change for 2.2 is minimum (change in 2 shift operations when determining the collocated MV), whereas the text change for 2.3 reflects the additional checks that are necessary on various syntax elements. As a general remark, 2.2 and 2.3 provide interesting gains, which should be considered against the additional complexity with the additional information requested Results:
Average, also including optional LD P:
Further discussion N0252 / N0233 Thu p.m. (GS): Blending of EL & BL motion data 0.5% improvement reported on RA2x. Complexity analysis presented in revision of N0252. Four checks for each list at 16×16 block level, more checks (~15) at slice level. Negligible runtime perf impact. Gain is only in RA. The feature was actually disabled in the LD case, as it was not useful there. It was commented that this requires an extra motion field buffer in the SNR scalabiity case. For further study. 4.2.2SCE2 primary contributionsJCTVC-N0139 SCE2: Results on test 2.1 [C. Gisquet, P. Onno, E. François, G. Laroche (Canon)] JCTVC-N0239 SCE2: Result of Test 1.1 [C. Gisquet (Canon), K. Sato, J. Xu (Sony)] JCTVC-N0241 SCE2: Result of Test 1.4 [C. Gisquet (Canon), K. Sato, J. Xu (Sony), K. Misra (Sharp)] JCTVC-N0245 SCE2: Result of Test 2.2 [K. Sato, J. Xu (Sony)] JCTVC-N0252 SCE2 test 2.3 motion buffer modification results [K. Misra, A. Segall, J. Zhao (Sharp)] JCTVC-N0255 SCE2 test 1.3 results [K. Misra, A. Segall (Sharp), K. Sato, J. Xu (Sony)] JCTVC-N0302 SCE2: Results on combination test 1.2 [C. Gisquet, K. Misra, A. Segall (Sharp)] [late] 4.2.3SCE2 cross checksJCTVC-N0122 SCE2: Cross-check of test2.3 on motion field buffer update [J. Lee, H. Lee, J. W. Kang (ETRI)] JCTVC-N0240 SCE2: Crosscheck Result of Test 1.2 [K. Sato (Sony)] JCTVC-N0243 SCE2: Crosscheck Result of Test 2.1 [K. Sato (Sony)] JCTVC-N0257 SCE2 Cross check report of test 1.1 [K. Misra, A. Segall (Sharp)] [late] JCTVC-N0259 SCE2 Cross check report of test 2.2 [K. Misra, A. Segall (Sharp)] [late] JCTVC-N0300 Crosscheck of SCE 2 test 1.4 [C. Kim, B. Jeon (LGE)] [late] JCTVC-N0301 Crosscheck of SCE 2 test 1.3 [C. Kim, B. Jeon (LGE)] [late] Yüklə 2,1 Mb. Dostları ilə paylaş:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||