Method and apparatus of intra shared region for decoder-side derived intra prediction mode and CCP merge mode in video coding

Abstract

A method and apparatus for video coding using a shared information buffer for an intra shared region to reduce required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation are disclosed. According to this method, an intra shared region in the current picture is determined, wherein the intra shared region is partitioned into one or more blocks. Said one or more blocks of the intra shared region are encoded or decoded. Shared required information associated with at least one of said one or more blocks of the intra shared region in a shared information buffer for decoder-side-derived-intra-prediction mode is stored or updated, and wherein the shared required information associated with said at least one of said one or more blocks of the intra shared region for the decoder-side-derived-intra-prediction mode is used by one or more subsequent intra shared regions.

Description

METHOD AND APPARATUS OF INTRA SHARED REGION FOR DECODER-SIDE DERIVED INTRA PREDICTION MODE AND CCP MERGE MODE IN VIDEO CODINGCROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present invention is a non-Provisional Application of and claims priority to U.S. Provisional Patent Application No. 63 / 670,226, filed on July 12, 2024. The U.S. Provisional Patent Application is hereby incorporated by reference in its entirety.FIELD OF THE INVENTION

[0002] The present invention relates to video coding system. In particular, the present invention relates to schemes to reduce required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using a shared information buffer. BACKGROUND AND RELATED ART

[0003] Versatile video coding (VVC) is the latest international video coding standard developed by the Joint Video Experts Team (JVET) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) . The standard has been published as an ISO standard: ISO / IEC 23090-3: 2021, Information technology -Coded representation of immersive media -Part 3: Versatile video coding, published Feb. 2021. VVC is developed based on its predecessor HEVC (High Efficiency Video Coding) by adding more coding tools to improve coding efficiency and also to handle various types of video sources including 3-dimensional (3D) video signals.

[0004] Fig. 1A illustrates an exemplary adaptive Inter / Intra video encoding system incorporating loop processing. For Intra Prediction 110, the prediction data is derived based on previously encoded video data in the current picture. For Inter Prediction 112, Motion Estimation (ME) is performed at the encoder side and Motion Compensation (MC) is performed based on the result of ME to provide prediction data derived from other picture (s) and motion data. Switch 114 selects Intra Prediction 110 or Inter-Prediction 112 and the selected prediction data is supplied to Adder 116 to form prediction errors, also called residues. The prediction error is then processed by Transform (T) 118 followed by Quantization (Q) 120. The transformed and quantized residues are then coded by Entropy Encoder 122 to be included in a video bitstream corresponding to the compressed video data. The bitstream associated with the transform coefficients is then packed with side information such as motion and coding modes associated with Intra prediction and Inter prediction, and other information such as parameters associated with loop filters applied to underlying image area. The side information associated with Intra Prediction 110, Inter prediction 112 and in-loop filter 130, are provided to Entropy Encoder 122 as shown in Fig. 1A.When an Inter-prediction mode is used, a reference picture or pictures have to be reconstructed at the encoder end as well. Consequently, the transformed and quantized residues are processed by Inverse Quantization (IQ) 124 and Inverse Transformation (IT) 126 to recover the residues. The residues are then added back to prediction data 136 at Reconstruction (REC) 128 to reconstruct video data. The reconstructed video data may be stored in Reference Picture Buffer 134 and used for prediction of other frames.

[0005] As shown in Fig. 1A, incoming video data undergoes a series of processing in the encoding system. The reconstructed video data from REC 128 may be subject to various impairments due to a series of processing. Accordingly, in-loop filter 130 is often applied to the reconstructed video data before the reconstructed video data are stored in the Reference Picture Buffer 134 in order to improve video quality. For example, deblocking filter (DF) , Sample Adaptive Offset (SAO) and Adaptive Loop Filter (ALF) may be used. The loop filter information may need to be incorporated in the bitstream so that a decoder can properly recover the required information. Therefore, loop filter information is also provided to Entropy Encoder 122 for incorporation into the bitstream. In Fig. 1A, Loop filter 130 is applied to the reconstructed video before the reconstructed samples are stored in the reference picture buffer 134. The system in Fig. 1A is intended to illustrate an exemplary structure of a typical video encoder. It may correspond to the High Efficiency Video Coding (HEVC) system, VP8, VP9, H. 264 or VVC.

[0006] The decoder, as shown in Fig. 1B, can use some of the functional blocks as the encoder. For example, the decoder can reuse Inverse Quantization 124 and Inverse Transform 126; however, Transform 118 and Quantization 120 are not needed at the decoder. Instead of Entropy Encoder 122, the decoder uses an Entropy Decoder 140 to decode the video bitstream into quantized transform coefficients and needed coding information (e.g. ILPF information, Intra prediction information and Inter prediction information) . The Intra prediction 150 at the decoder side does not need to perform the mode search. Instead, the decoder only needs to generate Intra prediction according to Intra prediction information received from the Entropy Decoder 140. Furthermore, for Inter prediction, the decoder only needs to perform motion compensation (MC 152) according to Inter prediction information received from the Entropy Decoder 140 without the need for motion estimation.

[0007] Intra Mode Coding with 67 Intra Prediction Modes

[0008] To capture the arbitrary edge directions presented in natural video, the number of directional intra modes in VVC is extended from 33, as used in HEVC, to 65. The new directional modes not in HEVC are depicted as dotted arrows in Fig. 2, and the planar and DC modes remain the same. These denser directional intra prediction modes apply for all block sizes and for both luma and chroma intra predictions.

[0009] In VVC, several conventional angular intra prediction modes are adaptively replaced with wide-angle intra prediction modes for the non-square blocks.

[0010] In HEVC, every intra-coded block has a square shape and the length of each of its side is a power of 2. Thus, no division operations are required to generate an intra-predictor using DC mode. In VVC, blocks can have a rectangular shape that necessitates the use of a division operation per block in the general case. To avoid division operations for DC prediction, only the longer side is used to compute the average for non-square blocks.

[0011] Intra Prediction in Enhanced Compression Model (ECM)

[0012] Decoder-side Intra Mode Derivation (DIMD)

[0013] When DIMD is applied, up to five intra modes are derived from the reconstructed neighbour samples, and those five predictors are combined with the planar mode predictor with the weights derived from the histogram of gradients as described in JVET-O0449 (Mohsen Abdoli, et al., “Non-CE3: Decoder-side Intra Mode Derivation with Prediction Fusion Using Planar” , Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 15th Meeting: Gothenburg, SE, 3–12 July 2019, Document JVET-O0449) . The division operations in weight derivation are performed utilizing the same lookup table (LUT) based integerization scheme used by the CCLM. For example, the division operation in the orientation calculation, Orient=Gy / Gx is computed by the following LUT-based scheme: x = Floor (Log2 (Gx) ) normDiff = ( (Gx<< 4) >> x) &15 x += (3 + (normDiff ! = 0) ? 1 : 0) Orient = (Gy* (DivSigTable [normDiff ] | 8) + (1<< (x-1) ) ) >> x, where DivSigTable

[0016] = {0, 7, 6, 5 , 5, 4, 4, 3, 3, 2, 2, 1, 1, 1, 1, 0} .

[0014] For a block of size W×H, the weight for each of the five derived modes is modified if the above or left histogram magnitudes is twice larger than the other one. In this case, the weights are location dependent and computed as follows.

[0015] If the above histogram is twice the left, then:

[0016] If the left histogram is twice the above, then: where wDimdi is the unmodified uniform weight of the DIMD selected as in JVET-O0449, Δi is pre- defined and set to 10.

[0017] Derived intra modes are included into the primary list of intra most probable modes (MPM) , so the DIMD process is performed before the MPM list is constructed. The primary derived intra mode of a DIMD block is stored with a block and is used for MPM list construction of the neighbouring blocks.

[0018] Finally, note the region of neighbouring reconstructed samples used for computing the histogram of gradients is modified compared to JVET-O0449 method, depending on reconstructed samples availability. The region of decoded reference samples of current WxH luma CB is extended towards the above-right side if available, up to W additional columns. It is extended towards the bottom-left side if available, up to H additional rows.

[0019] JVET-AG0084 DIMD Merge Mode

[0020] DIMD merge mode includes a step of merging the HoG of neighbouring blocks to derive DIMD information. The DIMD information in the surroundings can be used to derive the merged HoG (MHoG) . The MHoG from up to 13 CUs is used to derive intra prediction modes and weights, as in conventional DIMD. The directional modes and the respective weights corresponding to the five highest amplitudes in the MHoG are selected, and the corresponding predictors are blended as in conventional DIMD. In JVET-AF012 (S. Blasi, I. Zupancic, J. Lainema, “EE2-2.1 DIMD merge, ” JVET-AF0120, October 2023) , a reduced storage version of the DIMD merge is proposed where the five highest amplitudes of the histograms are stored and averaged.

[0021] In JVET-AF0106 (J. Huo, J. Fan, Z. Zhang, Y. Ma, F. Yang, M. Li, “EE2-related: Non-adjacent spatial candidates for DIMD merge, ” JVET-AF0106, October 2023) , the DIMD merge mode is extended to include up to 31 surrounding CUs to derive the MHoG. Indeed, on top of the original 13 CUs, non-adjacent spatial candidates are considered as in Fig. 3.

[0022] A new flag is introduced and is signalled just after the DIMD flag if the DIMD merge mode is true.

[0023] DIMD Merge Mode List

[0024] This contribution proposes to create a DIMD merge list from neighbouring blocks’ DIMD information, which includes: ● DIMD information from spatial neighbours (as in Fig. 4) , ● DIMD information from non-adjacent neighbours (as in Fig. 3) , ● DIMD information derived from the MHoG.

[0025] Two redundancy checks (pruning stage) are applied: one comparing the DIMD merge candidates, and one comparing the DIMD information derived from the current block. Thus, a DIMD merge candidate is added to the DIMD merge list when the associated DIMD information is different from the existing information in DIMD merge candidates and the current block DIMD information.

[0026] Two additional flags are added conditionally to the DIMD flag, i.e., the DIMD Merge is considered as a sub-mode of DIMD. The two flags are: ● The DIMD merge mode flag ● The DIMD merge mode index representative of the DIMD merge candidate.

[0027] DIMD Merge Candidates’ Evaluation

[0028] DIMD merge is only available as an option if the current block has at least one neighbour coded with DIMD or DIMD merge modes using the same method as proposed in JVET-AE0071 (S. Blasi, I. Zupancic, J. Lainema, “AHG12 -Decoder-side Intra Mode Derivation Merge, ” JVET-AE0071, July 2023) . Besides, the neighbouring positions or neighbouring blocks are extended to include part of the non-adjacent candidates.

[0029] When the DIMD merge is available, the DIMD merge list candidate is derived both at the encoder and decoder sides. On the encoder side, each candidate is evaluated using an Hadamard pass, then in the RDO loop if the associated Hadamard-based cost is competitive.

[0030] A DIMD merge candidate may be discarded if the associated cost is not competitive compared to other modes.

[0031] Extrapolation Filter-Based Intra Prediction (EIP) Mode

[0032] In the EIP mode, the samples in a CU are predicted from the top-left position to the bottom-right position by applying an extrapolation filter to neighbouring reconstructed samples or predicted samples. The EIP mode uses a 15-tap filter for prediction as below: where pred (x, y) is the predicted value at (x, y) in the current block, ci is the ith coefficient of the selected  EIP filter, the index of the coefficients is from 0 to 14,  is a reconstructed or a predicted value used for the current position’s prediction. offsetXi and offsetYi are the position offsets to the current position along x and y directions, respectively.

[0033] The three EIP filter shapes are shown in Fig. 5, where the three filter shapes correspond to square 510, horizontal strip 520, and vertical strip 530. The three types of the reconstructed area are defined as shown in Fig. 6, where the three reconstructed areas correspond to Left-Above area (i.e., EIP_LT) (Fig. 6A) , Above area (i.e., EIP_T) (Fig. 6B) , and Left area (i.e., EIP_L) (Fig. 6C) . The size of the reconstructed area depends on the min (blockWidth, blockHeight) and the selected filter shape.

[0034] For a CU coded in the EIP mode, an EIP merge flag is signalled to indicate whether the EIP filter is inherited from previous blocks coded in EIP mode. When the EIP merge flag is true, an EIP merge list is constructed from the spatial adjacent, spatial non-adjacent, temporal and history candidates. The position and inclusion order of these candidates are the same as those used in CCP merge candidate list. An EIP merge index is further signalled to indicate which EIP merge candidate is selected. The filter shape and the filter coefficients of the selected candidate are then inherited to code the CU.

[0035] When the EIP merge flag is false, the EIP filter is derived from the neighbouring reconstructed samples and the relevant syntax element is signalled to indicate which one of the three types of reconstructed area and which one of the three filter shapes are used for the CU. The selected filter moves in the selected reconstructed area either horizontally or vertically with a one-pixel step to construct the auto-correlation matrix and the cross-correlation vector. The calculation of coefficients from the auto-correlation matrix and the cross-correlation vector is the same as that in CCCM.

[0036] After generating the prediction samples of the CU using the EIP filter, an intra prediction mode is derived by applying the DIMD process to the prediction samples. Specifically, a horizontal gradient and a vertical gradient are calculated for each predicted sample to build a histogram of gradient. Then the intra prediction mode corresponding to the largest histogram count is used to determine the LFNST, NSPT or MTS transform set.

[0037] Cross-Component Prediction (CCP) Merge Mode

[0038] For chroma coding, a flag is signalled to indicate whether CCP mode (including the CCLM, CCCM, GLM and their variants) or non-CCP mode (conventional chroma intra prediction mode, fusion of chroma intra prediction mode) is used. If the CCP mode is selected, one more flag is signalled to indicate how to derive the CCP type and parameters (i.e., either from a CCP merge list or signalled / derived on-the-fly) . A CCP merge candidate list is constructed from the spatial adjacent, temporal, spatial non-adjacent, history-based or shifted temporal candidates. After including these candidates, default models are further included to fill the remaining empty positions in the merge list. In order to remove redundant CCP models in the list, pruning operation is applied. After constructing the list, the CCP models in the list are reordered according to the SAD costs, which are obtained using the neighbouring template of the current block. More details are described below.

[0039] Spatial Adjacent and Non-Adjacent Candidates

[0040] The positions and inclusion order of the spatial adjacent and non-adjacent candidates are the same as those defined in ECM for regular inter merge prediction candidates.

[0041] Temporal and Shifted Temporal Candidates

[0042] Temporal candidates are selected from the collocated picture. The position and inclusion order of the temporal candidates are the same as those defined in ECM for regular inter merge prediction candidates. The shifted temporal candidates are also selected from the collocated picture. The position of temporal candidates is shifted by a selected motion vector which is derived from motion vectors of neighbouring blocks.

[0043] History-based Candidates

[0044] A history-based table is maintained to include the recently used CCP models, and the table is reset at the beginning of each CTU row. If the current list is not full after including spatial adjacent and non-adjacent candidates, the CCP models in the history-based table are added into the list.

[0045] Default Candidates

[0046] CCLM candidates with default scaling parameters are considered, only when the list is not full after including the spatial adjacent, spatial non-adjacent, or history-based candidates. If the current list has no candidates with the single model CCLM mode, the default scaling parameters are {0, 1 / 8, -1 / 8, 2 / 8, -2 / 8, 3 / 8, -3 / 8, 4 / 8, -4 / 8, 5 / 8, -5 / 8, 6 / 8} . Otherwise, the default scaling parameters are {0, the scaling parameter of the first CCLM candidate + {1 / 8, -1 / 8, 2 / 8, -2 / 8, 3 / 8, -3 / 8, 4 / 8, -4 / 8, 5 / 8, -5 / 8, 6 / 8} } .

[0047] A flag is signalled to indicate whether the CCP merge mode is applied or not. If CCP merge mode is applied, an index is signalled to indicate which candidate model is used by the current block. In addition, CCP merge mode is not allowed for the current chroma coding block when the current CU is coded by intra sub-partitions (ISP) with single tree, or the current chroma coding block size is less than or equal to 16.

[0048] JVET-Q0185 AHG16: On Merge Estimation Region for VVC

[0049] MER is included in HEVC. MERs are non-overlapping square regions, and MER is used at the encoder side to estimate costs of merging candidates in parallel for different CUs in one MER. When MER is applied, a spatial merging candidate can be added into merging candidate list only when the current CU and the neighbouring CU are in the different MERs. In low cost real-time HEVC encoders, MER is commonly applied in many practical products. Therefore, it is desirable to make the MER feature available in VVC with minor normative changes and proper encoder-only constraints. Details are described in the following sections.

[0050] In JVET-Q0185, it is proposed to directly apply square MER in HEVC to VVC. The operations and syntax of the proposed MER for VVC are basically the same as those in HEVC. When MER is applied, a spatial merging candidate can be added into merging candidate list only when the current CU and the neighbouring CU are in the different MERs. Moreover, MER for VVC is extended to not only consider spatial merging candidates but also subblock-based merging candidates including subblock-based temporal motion vector prediction (SbTMVP) merging candidate, luma affine control point motion vectors from a neighbouring block (a. k. a. inherited affine merging candidates) , and constructed affine control point motion vector merging candidates (a. k. a. constructed affine merging candidates) .

[0051] MER is an important feature for a commercial hardware encoder because it can effectively reduce bubble cycles. The bubble cycles are similar to the waiting time for RDO stage results of previous CUs needed before starting the predictor stage of the current CU in the merge mode. Accordingly, corresponding circuit has to wait for some neighbouring data in order to generate the current predictor, and the waiting time can be regarded as bubbles for this circuit since the input and the output of this circuit are considered garbage values and not useful. As shown in Fig. 7, the predictor stage 710 and the rate-distortion optimization (RDO) stage 720 in an encoder are shown. The predictor stage includes intra and inter prediction, the RDO stage includes the rate and distortion calculations and the final mode decision. If without MER, before starting the predictor stage of the current CU in merge mode, the predictor stage needs to wait for the RDO stage results of previous CUs, because the MVs of the previous CUs can be spatial neighbours of the current CU. By using MER, such waiting time can be eliminated inside MER. Accordingly, merge mode decision of all CUs inside the MER region can be performed at the same time without waiting for each other, so the bubble cycles can be saved. In one example, in a hardware encoder architecture for VVC, if without MER, the bubble cycles will be 2.38 times compared to the actual processing (non-bubble) cycles. If with 32x32 MER region, the bubble cycles will be largely reduced to only 0.27 times compared to the actual processing cycles. Moreover, MER is also a commonly used tool for a commercial real-time hardware encoder. In our survey on several HEVC hardware encoders from several major companies, MER is activated in most cases.

[0052] In order to guarantee allowing parallel processing of merge modes inside MER, in addition to the HEVC-based MER, two encoder-only constraints are needed for VVC and described as follows.

[0053] Firstly, a general rule for MER is that any CU that is not smaller than MER size has to contain one or multiple complete MERs, and any CU that is smaller than MER size has to locate within one MER. To satisfy this rule, a new encoder-only constraint for binary tree (BT) split and ternary tree (TT) split is applied in inter slice. The following shows the detailed split constraint: ● When the current slice is an inter slice and when the current CU width is larger than the MER width  or the current CU height is larger than the MER height, the following applies. ○ When the CU height smaller than or equal to the MER height, disallow horizontal BT split ○ When the CU width smaller than or equal to the MER width, disallow the vertical BT split ○ When the CU height smaller than or equal to 2 times MER height, disallow the horizontal TT  split ○ When the CU width smaller than or equal to 2 times MER width, disallow the vertical TT split

[0054] Secondly, a new encoder-only constraint for history-based motion vector prediction (HMVP) merging candidates is applied. In this constraint, for any CU that is contained within one MER, the HMVP candidates and merging candidates after HMVP in the merging candidate list (i.e., pairwise average merging candidate and zero candidates) are not used. With the first encoder-only constraint, the second encoder-only constraint is equivalent to not using HMVP candidates and merging candidates after HMVP in the merging candidate list when the current CU width is smaller than the MER width or the current CU height is smaller than the MER height. The constraint is used to break the dependency caused by updating HMVP table between different CUs in one MER in order to allow parallel processing. The second constraint affects 4 merge modes including merge with motion vector difference (MMVD) mode, non-MMVD regular merge mode, combined inter / intra prediction (CIIP) mode, and triangular partitioning mode (TPM) .

[0055] In the present invention, techniques to reduce required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using a shared information buffer. BRIEF SUMMARY OF THE INVENTION

[0056] A method and apparatus for video coding are disclosed. According to this method, input data associated with a current picture is received, wherein the input data comprise pixel data to be encoded at an encoder side or data associated with the current picture to be decoded at a decoder side. An intra shared region in the current picture is determined, wherein the intra shared region is partitioned into one or more blocks. Said one or more blocks of the intra shared region are encoded or decoded. Shared required information associated with at least one of said one or more blocks of the intra shared region in a shared information buffer for decoder-side-derived-intra-prediction mode is stored or updated, and wherein the shared required information associated with said at least one of said one or more blocks of the intra shared region for the decoder-side-derived-intra-prediction mode is used by one or more subsequent intra shared regions.

[0057] In one embodiment, the shared required information comprises occurrence, histogram, template cost, sample value, coded CU information, or a combination thereof.

[0058] In one embodiment, the shared required information is used as evaluation metric of determining intra-prediction mode index, as indicator of intra-prediction angular mode, or as intra-prediction mode candidate order.

[0059] In one embodiment, said one or more blocks inside the intra shared region utilize the shared required information to derive an intra shared list for decoder-side derived intra-prediction mode.

[0060] In one embodiment, only the shared required information associated with first N blocks or last N blocks of said one or more blocks of the intra shared region in the shared information buffer is stored or updated, wherein N is an integer larger or equal to than 0. In one embodiment, only the shared required information associated with some specific blocks of said one or more blocks of the intra shared region in the shared information buffer is stored or updated. In one embodiment, said some specific blocks of said one or more blocks of the intra shared region comprise target blocks with a larger area or a frequently appeared block size inside the intra shared region.BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Fig. 1A illustrates an exemplary adaptive Inter / Intra video encoding system incorporating loop processing.

[0062] Fig. 1B illustrates a corresponding decoder for the encoder in Fig. 1A.

[0063] Fig. 2 shows the intra prediction modes as adopted by the VVC video coding standard.

[0064] Fig. 3 illustrates an example of non-adjacent neighbouring candidates for DIMD merge mode.

[0065] Fig. 4 illustrates an example of spatial neighbouring blocks for deriving DIMD information.

[0066] Fig. 5 illustrates three types of filter shapes with fifteen inputs and generate one output for EIP process.

[0067] Figs. 6A-C illustrate three types (Fig. 6A: Left-Above area, Fig. 6B: Above area, and Fig. 6C:Left area) of reconstructed areas used to derive filter coefficients for EIP.

[0068] Fig. 7 illustrates an example of hardware encoder architecture.

[0069] Fig. 8 illustrates an example of ISR with blocks A, B and C inside an ISR, and blocks D and E in another ISR.

[0070] Fig. 9 illustrates an example of neighbouring positions adjacent to an ISR with several blocks inside an ISR.

[0071] Fig. 10 illustrates an example of updating the first N blocks in ISR.

[0072] Fig. 11 illustrates an example of updating the last N blocks in ISR.

[0073] Fig. 12 illustrates an example of intra shared list generation in one ISR and its corresponding neighbouring positions.

[0074] Fig. 13 illustrates an example of reconstruction sample usage of the ISR and intra estimation region.

[0075] Fig. 14 illustrates a flowchart of an exemplary video coding system that uses a scheme to reduce required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using a shared information buffer for the intra shared region according to an embodiment of the present invention.DETAILED DESCRIPTION OF THE INVENTION

[0076] It will be readily understood that the components of the present invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the systems and methods of the present invention, as represented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. References throughout this specification to “one embodiment, ” “an embodiment, ” or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment.

[0077] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, etc. In other instances, well-known structures, or operations are not shown or described in detail to avoid obscuring aspects of the invention. The illustrated embodiments of the invention will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. The following description is intended only by way of example, and simply illustrates certain selected embodiments of apparatus and methods that are consistent with the invention as claimed herein.

[0078] In this disclosure methods related to decoder-side derived inter-prediction mode are disclosed.

[0079] Decoder-side Derived Intra-Prediction Mode, DIP Merge Mode, EIP Mode and CCP Merge Mode

[0080] Several new methods related to decoder-side derived intra-prediction mode, DIP merge mode, EIP mode, and CCP merge mode are disclosed.

[0081] The decoder-side derived intra-prediction mode includes DIMD, TIMD (Template-based Intra Mode Derivation) , EIP merge, DIP merge, CCP merge, or an intra prediction mode that the required intra prediction information can be derived / determined at decoder side. The required intra prediction information includes, but not limited to, intra prediction angles, intra prediction blending weights, filter shape, interpolation filter coefficients, merge candidate index, model parameters, classification threshold, template cost. Since information required for constructing decoder-side derived intra-prediction mode is frequently accessed, it results in additional duplicated computation costs in some special situations, and the needed information for decoder-side derived intra-prediction mode may require extra buffer storage.

[0082] To save the computation cost and buffer storage, intra shared region (ISR) for decoder-side derived intra-prediction mode or EIP mode or DIP merge mode or CCP merge mode is proposed in this invention. Inside ISR, the shared required information for decoder-side derived intra-prediction mode or EIP mode or DIP merge mode or CCP merge mode is stored and used for one or more blocks. The shared required information is derived from neighbouring positions adjacent to ISR. Besides, list generation requires lots of cycles in the CU reconstruction stage. If one list is generated per block, cycle budget may not be enough and is not hardware friendly. Thus, intra shared list is also proposed to reduce the cycle issue. For an ISR, an intra shared list is generated once, and the intra shared list is used for one or more blocks inside ISR.

[0083] In existing design, to derive decoder-side derived intra-prediction mode for multiple intra blocks, it is less likely to process in parallel since neighbouring information will always be updated during encoding or decoding. To benefit parallel processing of decoder-side derived intra-prediction mode, intra estimation region is proposed in this invention. Inside the intra estimation region, when computing decoder-derived intra-prediction mode, the blocks cannot use the neighbouring information inside intra estimation region. The blocks may only use the neighbouring information outside the intra estimation region. Therefore, the neighbouring information for derive decoder-side derived intra-prediction mode can remain unchanged or can be changed less frequently. Thus, parallel processing for derive decoder-side derived intra-prediction mode is more likely to be performed.

[0084] To further utilize neighbouring information efficiently to derive decoder-side derived intra-prediction mode, corresponding non-adjacent neighbouring positions can be considered and intra extrapolated region is proposed in this invention. Unlike intra estimation region that omits unavailable adjacent neighbouring positions, blocks inside intra extrapolated region can use the corresponding horizontal or vertical non-adjacent neighbouring information outside the region when adjacent neighbouring information lies inside the extrapolated region. Therefore, parallel processing inside an intra extrapolated region is achievable, and more adjacent and non-adjacent neighbouring information can be considered in the derivation of decoder-side derived intra-prediction mode to enhance the coding efficiency.

[0085] ISR Shared Required Information and Intra Shared List for Decoder-Side Derived Intra-Prediction Mode

[0086] An ISR is pre-defined. Inside the region, the shared required information for decoder-side derived intra-prediction mode is pre-calculated and pre-stored. The ISR can be square or non-square, and there can be one or more blocks inside the ISR. The shared required information is derived from neighbouring positions adjacent to ISR. The shared required information for decoder-side derived intra-prediction mode can be occurrence, histogram, template cost, sample value, coded CU information or other decoder-side required information. The shared required information is used as evaluation metrics of determining intra-prediction mode index, as indicators of intra-prediction angular mode, or as intra-prediction mode candidate order. Blocks inside the ISR will utilize the shared required information to derive an intra shared list for decoder-side derived intra-prediction mode. The intra shared list for decoder-side derived intra-prediction mode is used for one or more blocks inside the ISR. The intra shared list for decoder-side derived intra-prediction mode can be used directly as a list or as a basis list for other operations.

[0087] Example 1: ISR and shared required information

[0088] In one embodiment, one or more blocks inside an ISR use the pre-calculated shared required information for decoder-side derived intra-prediction mode.

[0089] In another embodiment, an ISR can be consecutive N blocks, one CTU, N CTUs, or an A-by-B region, where N is an integer larger than or equal to 1, A and B are integers larger than or equal to 1, as shown in Fig. 8.

[0090] Example 1-1: Neighbouring positions of the first N blocks or the last N blocks inside the ISR are used to generate the shared required information for EIP mode, where N is an integer larger than or equal to 1.

[0091] In one embodiment, neighbouring positions of the first N blocks inside an ISR are considered when calculating the shared required information for decoder-side derived intra-prediction mode, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, neighbouring positions of block A and B are considered when calculating shared required information for decoder-side derived intra-prediction mode. That is, AL1, L1, LB1, A1 (or AL2) , AR1, A2, AR2, LB2 positions are considered. Besides, non-adjacent neighbouring positions may also be taken into consideration during the derivation.

[0092] In another embodiment, neighbouring positions of the last N blocks inside an ISR are considered when calculating the shared required information, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, neighbouring positions of block B and C are considered when calculating the shared required information for decoder-side derived intra-prediction mode. That is, AL2, LB2, A2 (or AL3) , LB3, AR2 and AR3 positions are considered. Besides, non-adjacent neighbouring positions may also be taken into consideration during derivation.

[0093] In another embodiment, neighbouring positions of one or more blocks inside an ISR are considered when calculating the shared required information, where N is an integer larger than or equal to 1.

[0094] In another embodiment, non-adjacent neighbouring positions of the first N blocks inside an ISR are considered when calculating the shared required information for decoder-side derived intra-prediction mode, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, non-adjacent neighbouring positions of block A and block B are considered when calculating the shared required information.

[0095] In another embodiment, non-adjacent neighbouring positions of the last N blocks inside an ISR are considered when calculating the shared required information for decoder-side derived intra-prediction mode, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, non-adjacent neighbouring positions of block B and block C are considered when calculating the shared required information.

[0096] In another embodiment, shared region as a centre unit for non-adjacent neighbouring positions is considered. For instance, non-adjacent neighbouring positions consider block A, B and C as a unit and use (block width A + block width B + block width C) and (block height A + block height B +block height C) to determine the non-adjacent horizontal and vertical locations.

[0097] In another embodiment, one or more blocks inside the shared region as a centre unit for non-adjacent neighbouring positions are considered. For instance, non-adjacent neighbouring positions consider block A as a unit and use block width A and block height A to determine the non-adjacent horizontal and vertical locations. For another example, non-adjacent neighbouring positions consider block A and B as a unit and use (block width A + block width B) and (block height A + block height B) to determine the non-adjacent horizontal and vertical locations.

[0098] Example 1-2: Update of shared required information

[0099] In another embodiment, one or more blocks will update the shared required information for decoder-side derived intra-prediction mode during encoding or decoding inside an ISR. The updated shared required information for decoder-side derived intra-prediction mode is used for following ISRs.

[0100] In another embodiment, only the first N blocks will update shared required information for decoder-side derived intra-prediction mode during encoding or decoding inside an ISR, where N is an integer larger than or equal to 0. For instance, as shown in Fig. 10, block A and block B will update the shared required information for decoder-side derived intra-prediction mode after encoding or decoding. The updated shared required information for decoder-side derived intra-prediction mode is used for following ISRs.

[0101] In another embodiment, only the last N blocks will update shared required information for decoder-side derived intra-prediction mode during encoding or decoding inside an ISR, where N is an integer larger than or equal to 0. For instance, as shown in Fig. 11, block F will update the shared required information for decoder-side derived intra-prediction mode after encoding or decoding. The updated shared required information for decoder-side derived intra-prediction mode is used for following ISRs.

[0102] In another embodiment, only some specific blocks will update the shared required information for decoder-side derived intra-prediction mode during encoding or decoding inside an ISR, such as the block with the largest area or the most frequently appeared block size inside an ISR.

[0103] In another embodiment, the shared required information for decoder-side derived intra-prediction mode is not updated in the current ISR during encoding or decoding. The shared required information is updated after the current ISR is encoded or decoded.

[0104] Example 1-3: History buffer of the shared required information for decoder-side derived intra-prediction mode

[0105] In another embodiment, the shared required information for decoder-side derived intra-prediction mode for one or more ISRs is stored into a history buffer. During encoding and decoding, the history buffer is also used in an ISR to derive the shared required information for decoder-side derived intra-prediction mode. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0106] In another embodiment, the history buffer of shared required information for decoder-side derived intra-prediction mode is reset per region, per CTU, per multiple CTUs, per slice, per multiple slices, or per frame.

[0107] In another embodiment, the history buffer of the shared required information for decoder-side derived intra-prediction mode is not updated in the current ISR during encoding or decoding. The history buffer is updated after the current ISR is encoded or decoded.

[0108] Example 2: Intra shared list for decoder-side derived intra-prediction mode for one or more blocks inside ISR

[0109] In one embodiment, an intra shared list is generated per ISR and the intra shared list is used for one or more blocks inside an ISR. As shown in Fig. 12, for an ISR containing block A and block B, an intra shared list is generated using the shared required information for decoder-side derived intra-prediction mode from the neighbouring positions AL, L, LB, A and AR or outside from the non-adjacent neighbouring positions.

[0110] Example 2-1: Intra shared list for decoder-side derived intra-prediction mode as a list

[0111] In another embodiment, an intra shared list for decoder-side derived intra-prediction mode is regarded as a list of decoder-side derived intra-prediction mode. For one or more blocks inside an ISR, an intra shared list is generated once and whenever decoder-side derived intra-prediction mode is needed, candidates in the intra shared list can be directly used or the whole intra shared list can be used. For instance, candidates in the intra shared list can be added into the MPM candidate lists of blocks inside ISR.

[0112] Example 2-2: Intra shared list for decoder-side derived intra-prediction mode as a basis list

[0113] In another embodiment, the intra shared list for decoder-side derived intra-prediction mode is regarded as a basis list of decoder-side derived intra-prediction mode. For one or more blocks inside an ISR, an intra shared list is generated once and whenever decoder-side derived intra-prediction mode is needed, candidates in the intra shared list can be regarded as basic candidates. Derived modes based on basic candidates can be utilized. For instance, the derived modes based on basic candidates can be Modebasic candidate-1, Modebasic candidate+1, Modebasic candidate-2, Modebasic candidate+2, and so on. For instance, the derived modes based on basic candidates can be added into MPM lists of blocks inside ISR.

[0114] ISR Shared Required Information and Intra Shared List for CCP Merge Mode

[0115] An ISR is pre-defined. Inside the region, the shared required information for CCP merge mode is pre-calculated and pre-stored. The ISR can be square or non-square, and there can be one or more blocks inside the ISR. The shared required information is derived from neighbouring positions adjacent to the ISR. In one embodiment, the design of the ISR for CCP merge mode is unified with the design of the ISR for other intra coding tools. The shared required information for CCP merge mode includes, but not limited to, the prediction model type (e.g. CCLM, MMLM, CCCM, GL-CCCM, GLM, NS-CCCM) , GLM pattern index, model parameters, prediction blending weights, classification threshold, lumaOffset, or transform set (e.g. LFNST, NSPT or MTS) . The shared required information is used as evaluation metrics of determining attributes of CCP merge mode, as indicators of attributes of CCP merge mode, or as CCP merge candidate order. Blocks inside the ISR will utilize the shared required information to derive an intra shared list for CCP merge mode. The intra shared list for CCP merge mode is used for one or more blocks inside the ISR. The intra shared list for CCP merge mode can be used directly as a list or as a basis list for other operations.

[0116] Example 1: ISR and shared required information

[0117] In one embodiment, one or more blocks inside an ISR use the pre-calculated shared required information for CCP merge mode.

[0118] In another embodiment, an ISR can be consecutive N blocks or 1 CTU or N CTUs or an A-by-B region, where N is an integer larger than or equal to 1, A and B are integers larger than or equal to 1, as shown in Fig. 8.

[0119] Example 1-1: Neighbouring positions of the first N blocks or the last N blocks inside the ISR are used to generate the shared required information for CCP merge mode, where N is an integer larger than or equal to 1.

[0120] In one embodiment, neighbouring positions of the first N blocks inside an ISR are considered when calculating the shared required information for CCP merge mode, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, neighbouring positions of block A and B are considered when calculating the shared required information for CCP merge mode. That is, AL1, L1, LB1, A1 (or AL2) , AR1, A2, AR2, and LB2 positions are considered. Besides, non-adjacent neighbouring positions may also be taken into consideration during the derivation.

[0121] In another embodiment, neighbouring positions of the last N blocks inside an ISR are considered when calculating the shared required information, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, neighbouring positions of block B and C are considered when calculating the shared required information for CCP merge mode. That is, AL2, LB2, A2 (or AL3) , LB3, AR2 and AR3 positions are considered. Besides, non-adjacent neighbouring positions may also be taken into consideration during the derivation.

[0122] In another embodiment, neighbouring positions of one or more blocks inside an ISR are considered when calculating the shared required information, where N is an integer larger than or equal to 1.

[0123] In another embodiment, non-adjacent neighbouring positions of the first N blocks inside an ISR are considered when calculating the shared required information for CCP merge mode, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, non-adjacent neighbouring positions of block A and block B are considered when calculating the shared required information.

[0124] In another embodiment, non-adjacent neighbouring positions of the last N blocks inside an ISR are considered when calculating the shared required information for CCP merge mode, where N is an integer larger than or equal to 1. For instance, as shown in Fig. 9, non-adjacent neighbouring positions of block B and block C are considered when calculating the shared required information.

[0125] In another embodiment, shared region as a centre unit for non-adjacent neighbouring positions is considered. For instance, non-adjacent neighbouring positions consider block A, B and C as a unit and use (block width A + block width B + block width C) and (block height A + block height B +block height C) to determine the non-adjacent horizontal and vertical locations.

[0126] In another embodiment, one or more blocks inside an ISR as a centre unit for non-adjacent neighbouring positions are considered. For instance, non-adjacent neighbouring positions consider block A as a unit and use block width A and block height A to determine the non-adjacent horizontal and vertical locations. For another example, non-adjacent neighbouring positions consider block A and B as a unit and use (block width A + block width B) and (block height A + block height B) to determine the non-adjacent horizontal and vertical locations.

[0127] In another embodiment, the meaning of “calculating shared required information for CCP merge mode” in the earlier embodiments can be referred to (1) use the shared information to construct CCP merge list, (2) calculate the template cost for CCP merge list reordering, or (3) generate the prediction of CCP merge mode.

[0128] Example 1-2: Update of shared required information

[0129] In another embodiment, one or more blocks will update the shared required information for CCP merge mode during encoding or decoding inside an ISR. The updated shared required information for CCP merge mode is used for following ISRs.

[0130] In another embodiment, only the first N blocks will update the shared required information for CCP merge mode during encoding or decoding inside an ISR, where N is an integer larger than or equal to 0. For instance, as shown in Fig. 10, block A and block B will update the shared required information for CCP merge mode after encoding or decoding. The updated shared required information for CCP merge mode is used for following ISRs.

[0131] In another embodiment, only the last N blocks will update the shared required information for CCP merge mode during encoding or decoding inside an ISR, where N is an integer larger than or equal to 0. For instance, as shown in Fig. 11, block F will update the shared required information for CCP merge mode after encoding or decoding. The updated shared required information for CCP merge mode is used for following ISRs.

[0132] In another embodiment, only some specific blocks will update the shared required information for CCP merge mode during encoding or decoding inside an ISR, such as block with the largest area or the most frequently appeared block size inside an ISR.

[0133] In another embodiment, the shared required information for CCP merge mode is not updated in the current ISR during encoding or decoding. The shared required information is updated after the current ISR is encoded or decoded.

[0134] Example 1-3: History buffer of the shared required information for CCP merge mode

[0135] In another embodiment, the shared required information for CCP merge mode for one or more ISRs is stored into a history buffer. During encoding and decoding, the history buffer is also used in an ISR to derive the shared required information for CCP merge mode. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0136] In another embodiment, the history buffer containing the shared required information for the CCP merge mode is reset on a per region, per CTU, per multiple CTUs, per slice, per multiple slices, or per frame basis.

[0137] In another embodiment, the history buffer of the shared required information for CCP merge mode is not updated in the current ISR during encoding or decoding. The history buffer is updated after the current ISR is encoded or decoded.

[0138] Example 2: Intra shared list for CCP merge mode for one or more blocks inside ISR

[0139] In one embodiment, an intra shared list is generated per ISR and the intra shared list is used for one or more blocks inside an ISR. As shown in Fig. 12, for an ISR containing block A and block B, an intra shared list is generated using the shared required information for CCP merge mode from the neighbouring positions AL, L, LB, A and AR or outside from the non-adjacent neighbouring positions.

[0140] Example 2-1: Intra shared list for CCP merge mode as a list

[0141] In another embodiment, an intra shared list for CCP merge mode is regarded as a list of CCP merge mode. For one or more blocks inside an ISR, an intra shared list is generated once and whenever CCP merge mode is needed, candidates in the intra shared list can be directly used or the whole intra shared list can be used. For instance, candidates in the intra shared list can be added into the CCP merge mode candidate lists of blocks inside ISR.

[0142] Example 2-2: Intra shared list for CCP merge mode as a basis list

[0143] In another embodiment, intra shared list for CCP merge mode is regarded as a basis list of CCP merge mode. For one or more blocks inside an ISR, an intra shared list is generated once and whenever CCP merge mode is needed, candidates in the intra shared list can be regarded as basic candidates, and derived modes based on basic candidates can be utilized. For instance, the filter coefficients of a derived mode can be derived by averaging (or weighted averaging) of the filter coefficients of the basic candidates. For instance, a derived mode can be a two-hypothesis mode in which the first hypothesis is generated by one basic candidate and the second hypothesis is generated by another basic candidate. The final hypothesis is a combination of the two hypotheses. For instance, the derived mode can be a multi-model CCP merge mode in which the first model is one basic candidate and the second model is another basic candidate. A threshold is used to determine which model is applied. For instance, the derived modes based on basic candidates can be added into CCP merge candidate lists of blocks inside ISR.

[0144] Reconstruction sample usage of ISR

[0145] In one embodiment, partial or whole reconstruction samples adjacent to the ISR is used. For instance, the partial or whole reconstruction samples can be used for template cost calculation. As shown in Fig. 13, reconstruction samples (a) , (b) , (c) and (d) can be used for block A. In another example, for block B, only reconstruction samples (b) and (c) are used.

[0146] In another embodiment, different weightings for reconstruction samples adjacent to the ISR are considered. For example, the reconstruction lines closer to the region boundary use larger weightings.

[0147] Any of the foregoing proposed methods of reducing required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using a shared information buffer to store shared required information can be implemented in encoders and / or decoders. For example, any of the proposed methods can be implemented in predictor derivation module of an encoder, and / or a predictor derivation module of a decoder. Alternatively, any of the proposed methods can be implemented as a circuit coupled to the predictor derivation module of the encoder and / or the predictor derivation module of the decoder, so as to provide the information needed by the predictor derivation module. With reference to the exemplary video encoder and decoder in Fig. 1A and Fig. 1B, any of the proposed methods can be implemented in an Intra prediction module (e.g. Intra Pred. 150 in Fig. 1B) in a decoder or an Intra prediction module in an encoder (e.g. Intra Pred. 110 in Fig. 1A) . Any of the proposed methods can also be implemented as a circuit coupled to the intra coding module at the decoder or the encoder. However, the decoder or encoder may also use additional processing unit to implement the required processing. While the Intra prediction units (e.g. unit 110 in Fig. 1A and unit 150 in Fig. 1B) are shown as individual processing units, they may correspond to executable software or firmware codes stored on a media, such as hard disk or flash memory, for a CPU (Central Processing Unit) or programmable devices (e.g. DSP (Digital Signal Processor) or FPGA (Field Programmable Gate Array) ) .

[0148] Fig. 14 illustrates a flowchart of an exemplary video coding system that uses a scheme to reduce required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using a shared information buffer for the intra shared region according to an embodiment of the present invention. The steps shown in the flowchart may be implemented as program codes executable on one or more processors (e.g., one or more CPUs) at the encoder side. The steps shown in the flowchart may also be implemented based hardware such as one or more electronic devices or processors arranged to perform the steps in the flowchart. According to this method, input data associated with a current picture is received in step 1410, wherein the input data comprise pixel data to be encoded at an encoder side or data associated with the current picture to be decoded at a decoder side. An intra shared region in the current picture is determined in step 1420, wherein the intra shared region is partitioned into one or more blocks. Said one or more blocks of the intra shared region are encoded or decoded in step 1430. Shared required information associated with at least one of said one or more blocks of the intra shared region in a shared information buffer for decoder-side-derived-intra-prediction mode is stored or updated in step 1440, and wherein the shared required information associated with said at least one of said one or more blocks of the intra shared region for the decoder-side-derived-intra-prediction mode is used by one or more subsequent intra shared regions.

[0149] The flowchart shown is intended to illustrate an example of video coding according to the present invention. A person skilled in the art may modify each step, re-arranges the steps, split a step, or combine steps to practice the present invention without departing from the spirit of the present invention. In the disclosure, specific syntax and semantics have been used to illustrate examples to implement embodiments of the present invention. A skilled person may practice the present invention by substituting the syntax and semantics with equivalent syntax and semantics without departing from the spirit of the present invention.

[0150] The above description is presented to enable a person of ordinary skill in the art to practice the present invention as provided in the context of a particular application and its requirement. Various modifications to the described embodiments will be apparent to those with skill in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed. In the above detailed description, various specific details are illustrated in order to provide a thorough understanding of the present invention. Nevertheless, it will be understood by those skilled in the art that the present invention may be practiced.

[0151] Embodiment of the present invention as described above may be implemented in various hardware, software codes, or a combination of both. For example, an embodiment of the present invention can be one or more circuit circuits integrated into a video compression chip or program code integrated into video compression software to perform the processing described herein. An embodiment of the present invention may also be program code to be executed on a Digital Signal Processor (DSP) to perform the processing described herein. The invention may also involve a number of functions to be performed by a computer processor, a digital signal processor, a microprocessor, or field programmable gate array (FPGA) . These processors can be configured to perform particular tasks according to the invention, by executing machine-readable software code or firmware code that defines the particular methods embodied by the invention. The software code or firmware code may be developed in different programming languages and different formats or styles. The software code may also be compiled for different target platforms. However, different code formats, styles and languages of software codes and other means of configuring code to perform the tasks in accordance with the invention will not depart from the spirit and scope of the invention.

[0152] The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described examples are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1.A method of video coding, the method comprising:receiving input data associated with a current picture, wherein the input data comprise pixel data to be encoded at an encoder side or data associated with the current picture to be decoded at a decoder side;determining an intra shared region in the current picture, wherein the intra shared region is partitioned into one or more blocks;encoding or decoding said one or more blocks of the intra shared region; andstoring or updating shared required information associated with at least one of said one or more blocks of the intra shared region in a shared information buffer for decoder-side-derived-intra-prediction mode, and wherein the shared required information associated with said at least one of said one or more blocks of the intra shared region for the decoder-side-derived-intra-prediction mode is used by one or more subsequent intra shared regions.2.The method of Claim 1, wherein the shared required information comprises occurrence, histogram, template cost, sample value, coded CU information, or a combination thereof.3.The method of Claim 1, wherein the shared required information is used as evaluation metric of determining intra-prediction mode index, as indicator of intra-prediction angular mode, or as intra-prediction mode candidate order.4.The method of Claim 1, wherein said one or more blocks inside the intra shared region utilize the shared required information to derive an intra shared list for decoder-side derived intra-prediction mode.5.The method of Claim 1, wherein only the shared required information associated with first N blocks or last N blocks of said one or more blocks of the intra shared region in the shared information buffer is stored or updated, wherein N is an integer larger than or equal to 0.6.The method of Claim 1, wherein only the shared required information associated with some specific blocks of said one or more blocks of the intra shared region in the shared information buffer is stored or updated.7.The method of Claim 6, wherein said some specific blocks of said one or more blocks of the intra shared region comprise target blocks with a larger area or a frequently appeared block size inside the intra shared region.8.An apparatus for video coding, the apparatus comprising one or more electronics or processors arranged to:receive input data associated with a current picture, wherein the input data comprise pixel data to be encoded at an encoder side or data associated with the current picture to be decoded at a decoder side;determine an intra shared region in the current picture, wherein the intra shared region is partitioned into one or more blocks;encode or decode said one or more blocks of the intra shared region; andstore or update shared required information associated with at least one of said one or more blocks of the intra shared region in a shared information buffer for decoder-side-derived-intra-prediction mode, and wherein the shared required information associated with said at least one of said one or more blocks of the intra shared region for the decoder-side-derived-intra-prediction mode is used by one or more subsequent intra shared regions.

Images