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

Abstract

A method and apparatus for video coding to avoid or reduce repeated access to neighbouring reconstruction samples for a decoder-side derived intra-prediction mode are disclosed. According to this method, an intra region from the current picture is determined, wherein the intra region is partitioned into one or more blocks. One or more intra lists are derived for a decoder-side derived intra-prediction mode for said one or more blocks inside the intra region based on neighbouring information outside the intra region, wherein when a neighbouring position of any block of said one or more blocks is inside the intra region, target neighbouring information associated with the neighbouring position of any block of said one or more blocks is not used. A target block of said one or more blocks is encoded or decoded using coding information comprising said one or more intra lists.

Description

METHOD AND APPARATUS OF INTRA ESTIMATION REGION AND INTRA EXTRAPOLATED 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,219, 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 in intra estimation region. 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. 6A-C, 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 schemes to reduce required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using an intra estimation region. BRIEF SUMMARY OF THE INVENTION

[0056] A method and apparatus for video coding to avoid or reduce repeated access to neighbouring reconstruction samples for a decoder-side derived intra-prediction mode are disclosed. According to this method, input data associated with a current block is received, wherein the input data comprise pixel data to be encoded at an encoder side or data associated with the current block to be decoded at a decoder side. An intra region from the current picture is determined, wherein the intra region is partitioned into one or more blocks. One or more intra lists are derived for a decoder-side derived intra-prediction mode for said one or more blocks inside the intra region based on neighbouring information outside the intra region, wherein when a neighbouring position of any block of said one or more blocks is inside the intra region, target neighbouring information associated with the neighbouring position of any block of said one or more blocks is not used. A target block of said one or more blocks is encoded or decoded using coding information comprising said one or more intra lists.

[0057] In one embodiment, the target neighbouring information associated with the neighbouring position of any block of said one or more blocks is determined according to a centre unit within the intra region and a horizontal distance and / or vertical distance, and wherein the horizontal distance corresponds to a total width of one or more selected blocks inside the intra region and the vertical distance corresponds to a total height of said one or more selected blocks inside the intra region.

[0058] In one embodiment, the neighbouring information associated with one or more selected blocks inside a current intra region is updated during encoding or decoding of said one or more selected blocks inside the intra region, and updated neighbouring information is used by one or more subsequent intra regions. In another embodiment, the neighbouring information for a current intra region is not updated during encoding or decoding of the intra region until the current intra region is fully encoded or decoded.

[0059] In one embodiment, said one or more intra lists are partially the same or totally different. In one embodiment, the decoder-side derived intra-prediction mode comprises DIMD (Decoder-side Intra Mode Derivation) mode, TIMD (Template-based Intra Mode Derivation) mode, MRL (Multiple Reference Lines) mode, EIP (Extrapolation Filter-Based Intra Prediction) merge mode, DIP (Decoder-derived Intra Prediction) merge mode, or CCP (Cross-Component Prediction) merge mode.

[0060] In one embodiment, the neighbouring information inherited from one or more previous intra regions is stored in a history buffer and used by a current intra region.

[0061] In one embodiment, when the decoder-side derived intra-prediction mode corresponds to the EIP mode, the neighbouring information for the EIP mode comprises EIP filter shape, EIP reconstructed area, EIP filter coefficients, intra prediction mode derived by a DIMD process, transform set used, template cost, sample value, coded CU information, or a combination thereof.

[0062] In one embodiment, when the decoder-side derived intra-prediction mode corresponds to the DIMD mode, the neighbouring information inherited comprises one or more histogram values for available DIMD intra prediction modes, N intra prediction modes suggested by histogram values, DIMD weighting information and / or whether fusion is used or not, reference line information and / or wide-angle conditions, or a combination thereof.

[0063] In one embodiment, when the decoder-side derived intra-prediction mode corresponds to the TIMD mode, the neighbouring information inherited comprises one or more TIMD cost values for available TIMD intra prediction mode, N intra prediction modes suggested by TIMD costs, TIMD weighting information and / or whether fusion is used or not, reference line information and / or wide-angle conditions, or a combination thereof.

[0064] In one embodiment, when the decoder-side derived intra-prediction mode corresponds to the MRL mode, the neighbouring information inherited comprises one or more reference lines jointly with intra prediction modes, N intra prediction modes suggested by TIMD costs, weighting information and / or whether fusion is used or not, reference line information and / or wide-angle conditions, or a combination thereof.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

[0071] 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.

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

[0073] Figs. 8A-B illustrate an example of neighbouring reconstruction usage in inter estimation region or the inter shared region according to one embodiment of the present invention.

[0074] Fig. 9 illustrates an example of neighbouring positions adjacent to an IXR with several blocks inside an IXR, where positions L2 and L3 cannot be used since both are inside the IXR.

[0075] Fig. 10 illustrates an example of reconstruction sample or neighbouring information usage of inter shared region or inter estimation region.

[0076] Fig. 11 illustrates a flowchart of an exemplary video coding system that uses neighbouring reconstruction samples outside an intra estimation region for decoder-side derived intra-prediction mode derivation according to an embodiment of the present invention.DETAILED DESCRIPTION OF THE INVENTION

[0077] 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.

[0078] 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.

[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] Intra estimation region (IER) and intra extrapolated region (IXR) are proposed to benefit the parallel processing of decoder-side derived intra-prediction mode. When computing the decoder-derived intra-prediction mode, the blocks inside the current IER cannot use / reference the neighbouring information inside the current IER. Therefore, the neighbouring information for deriving decoder-side derived intra-prediction mode can remain unchanged or can be changed rarely, and parallel processing for deriving the decoder-side derived intra-prediction mode is more likely to be performed.

[0083] Furthermore, to efficiently utilize neighbouring information to derive intra prediction information of decoder-side derived intra-prediction mode, IXR is proposed to reference the corresponding non-adjacent neighbouring positions. Unlike IER which omits unavailable adjacent neighbouring positions, blocks inside IXR can use the corresponding horizontal or vertical non-adjacent neighbouring information outside the region when adjacent neighbouring information lies inside the region. Therefore, parallel processing inside an IXR is achievable and more adjacent and non-adjacent neighbouring information can be considered in derivation of decoder-side derived intra-prediction mode to enhance coding efficiency.

[0084] Intra Estimation Region (IER) for Decoder-Side Derived Intra-Prediction Mode

[0085] An IER is pre-defined. The IER can be square or non-square, and there can be one or more blocks inside an IER. Inside the region, when computing decoder-derived intra-prediction mode, the blocks cannot use the neighbouring information inside the current IER. The blocks may only use the neighbouring information outside the current IER. The neighbouring 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 neighbouring information is used as evaluation metrics of determining intra-prediction mode index, indicators of intra-prediction angular mode, or intra-prediction mode candidate order. One or multiple intra lists will be generated inside an IER. The generated intra list for decoder-side derived intra-prediction mode can be used directly as a list or as a basis list for other operations.

[0086] Example 1: IER and neighbouring information

[0087] In one embodiment, as shown in Fig. 8A and B, one or more blocks are inside an IER. When calculating neighbouring information for EIP mode, block A can use the neighbouring information located at AL1, A1, AR1, L1 and LB1 as shown in Fig. 8A. But block B can only use neighbouring information located at AL2, AR2, L2 and LB2 since A2 is located inside the IER as shown in Fig. 8B.

[0088] In another embodiment, as shown in Fig. 8A and B, IER as a centre unit for non-adjacent neighbouring positions is considered. For instance, 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.

[0089] In another embodiment, as shown in Fig. 8A and B, one or more blocks inside IER as a centre unit for non-adjacent neighbouring positions is considered. For instance, non-adjacent neighbouring positions may consider block A as a unit and use block width A and block height A to determine the non-adjacent horizontal and vertical locations.

[0090] Example 1-2: History buffer of the neighbouring information for decoder-side derived intra-prediction mode

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

[0092] In another embodiment, history buffer of neighbouring 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.

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

[0094] Example 1-3: Intra list generation for blocks inside IER

[0095] In another embodiment, one or multiple intra lists are generated inside an IER. The intra lists can be partially the same or totally different. The intra lists can be generated per block or per multiple blocks.

[0096] In another embodiment, an intra 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 IER, one or multiple intra lists are generated once and whenever decoder-side derived intra-prediction mode is needed, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0097] In another embodiment, an intra 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 IER, intra lists are generated and whenever decoder-side derived intra-prediction mode is needed, candidates in the intra lists can be regarded as basic candidates, and 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 IER.

[0098] Intra Extrapolated Region (IXR) for Decoder-Side Derived Intra-Prediction Mode

[0099] An IXR is pre-defined. The IXR can be square or non-square, and there can be one or more blocks inside the IXR. Inside the region, when computing decoder-derived intra-prediction mode, the blocks cannot use the neighbouring information inside IXR, but may use the corresponding horizontal or vertical positions adjacent to region instead. The blocks may also use the neighbouring information outside the IXR. The neighbouring 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 neighbouring information is used as evaluation metrics of determining intra-prediction mode index or as indicators of intra-prediction angular mode or as intra-prediction mode candidate order. One or multiple intra lists will be generated inside the IXR. A generated intra list for decoder-side derived intra-prediction mode can be used directly as a list or as a basis list for other operations.

[0100] Example 1: IXR &neighbouring information

[0101] In one embodiment, as shown in Fig. 9, one or more blocks are inside an IXR. When calculating neighbouring information for decoder-side derived intra-prediction mode, block A can use the neighbouring information located at AL1, A1 (or AL2) , AR1, L1 and LB1. Block B can use neighbouring information located at AL2, A2, AR2, LB2. Block B may also use neighbouring information located at L1 since L2 is located inside the IXR and L1 is the corresponding horizontal location adjacent to IXR. Similarly, Block C can use neighbouring information located at AL3, A3, AR3, L1, LB3 since L3 is located inside the IXR and L1 is the corresponding horizontal location adjacent to IXR.

[0102] In another embodiment, as shown in Fig. 9, the IXR 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.

[0103] In another embodiment, as shown in Fig. 9, one or more blocks inside the IXR as a centre unit for non-adjacent neighbouring positions is considered. For example, non-adjacent neighbouring positions consider block B and C as a unit and use (block width B + block width C) and (block height B + block height C) to determine the non-adjacent horizontal and vertical locations. For another example, 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.

[0104] Example 1-1: Update of neighbouring information

[0105] In another embodiment, one or more blocks will update neighbouring information for decoder-side derived intra-prediction mode during encoding or decoding inside an IXR. The updated neighbouring information for decoder-side derived intra-prediction mode is used for following IXRs.

[0106] In another embodiment, only the first N blocks or the last M blocks will update neighbouring information for decoder-side derived intra-prediction mode during encoding or decoding inside an IXR, where N and M are integer larger than or equal to 0.

[0107] In another embodiment, only some specific blocks will update neighbouring information for decoder-side derived intra-prediction mode during encoding or decoding inside an IXR, for example, block with the largest area or the most frequently appeared block inside an IXR.

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

[0109] Example 1-2: History buffer of the neighbouring information for decoder-side derived intra-prediction mode

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

[0111] In another embodiment, history buffer of neighbouring 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.

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

[0113] Example 1-3: Intra list generation for blocks inside IXR

[0114] In another embodiment, one or multiple intra lists will be generated inside IXR. The intra lists can be partially the same or totally different. The intra list can be generated per block or per multiple blocks.

[0115] In another embodiment, an intra 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 IXR, one or multiple intra lists are generated once and whenever decoder-side derived intra-prediction mode is needed, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0116] In another embodiment, an intra 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 IXR, intra lists are generated and whenever decoder-side derived intra-prediction mode is needed, candidates in the intra lists can be regarded as basic candidates and 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 IXR.

[0117] Intra Estimation Region (IER) for CCP Merge Mode

[0118] An IER is pre-defined. The shape of IER can be square or non-square, and at least one or more blocks are inside an IER. When constructing a CCP merge list of a block inside the current IER, the candidates from the positions inside the current IER cannot be used or is invalid. In one embodiment, for example, if a candidate is at the position (x, y) , and (x, y) is inside the current IER, then, the candidate cannot be used in constructing the CCP merge list or generating the prediction of CCP merge mode. The information inherited from neighbouring positions are outside the current IER, where the to-be-inherited information 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) . In another embodiment, one or more CCP merge lists can be firstly generated for the blocks inside the current IER. Later, the list (s) can be directly used by a block inside the current IER, or the list (s) is treated as a basis list for constructing a CCP merge list of a block inside the current IER.

[0119] Example 1: IER and neighbouring information

[0120] In one embodiment, as shown in Fig. 8A and B, an IER contains one or more than one blocks. When getting neighbouring information for CCP merge mode, block A can use the neighbouring information at AL1, A1, AR1, L1 and LB1 positions as shown in Fig. 8A. Block B can use neighbouring information at AL2, AR2, LB2 positions as shown in Fig. 8B. Block B cannot use the neighbouring information at L2 due to L2 is inside the current IER.

[0121] In another embodiment, as shown in Fig. 8A and B, the size and the location of the current IER is used to determine the non-adjacent neighbouring positions. The size of the current IER can be defined by the width and height of all blocks inside the current IER. For example, the width of the current IER is the summation of width of blocks A and B. Similarly, the height of the current IER is the summation of height of blocks A and B. Besides, the location of the current IER can be the left-top, right-top, left-bottom, right bottom, or the centre position of the current IER.

[0122] In another embodiment, as shown in Fig. 8A and B, partial blocks inside the current IER are jointly used to determine the non-adjacent neighbouring positions. For example, the size and location of block A is used to determine the non-adjacent neighbouring positions. Besides, the location can be the left-top, right-top, left-bottom, right bottom, or the centre position of partial blocks inside the current IER.

[0123] Example 1-1: Update of CCP information inside an IER

[0124] In another embodiment, partial blocks inside the current IER can update their CCP information to the later encoding or decoding blocks inside the current IER.

[0125] In another embodiment, only the first N blocks or the last M blocks can update the CCP information to the later encoding or decoding blocks inside the current IER, where N and M are integer larger than or equal to 0.

[0126] In another embodiment, only some selected blocks can update CCP information to the later encoding or decoding blocks inside the current IER. For example, the selected blocks can be the block having the largest area inside the current IER.

[0127] In another embodiment, the CCP information of the blocks inside the current IER is not updated to other blocks inside the current IER. The to the later encoding or decoding blocks inside the current IER is updated to another IER or the later encoding or decoding blocks outside the current IER.

[0128] Example 1-2: History buffer of the neighbouring information for CCP merge mode

[0129] In another embodiment, recent CCP information is stored in a history buffer for reference by the blocks predicted with CCP merge mode inside an IER. During encoding and decoding, the history buffer is also used inside an IER to record the recent CCP information. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0130] In another embodiment, the history buffer for storing CCP information is reset before encoding / decoding an IER, a CTU, multiple CTUs, a slice, multiple slices, or a frame.

[0131] In another embodiment, the history buffer for storing CCP information is reset after encoding / decoding an IER, a CTU, multiple CTUs, a slice, multiple slices, or a frame.

[0132] In another embodiment, history buffer for storing CCP information is not updated in the current IER during encoding or decoding. The history buffer is updated after the current IER is encoded or decoded.

[0133] Example 1-3: Intra list generation for blocks inside IER

[0134] In another embodiment, one or multiple intra lists can be generated inside an IER. The intra lists can be partially the same or totally different. An intra list can be generated depends on a block or multiple blocks inside an IER.

[0135] In another embodiment, an intra list for CCP merge mode is regarded as a list of CCP merge mode. For one or more blocks inside an IER, one or multiple intra lists are generated when CCP merge mode are used to predict the content of an IER. Besides, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0136] In another embodiment, an intra list for CCP merge mode is regarded as a basis list of CCP merge mode. For one or more blocks inside an IER, intra lists are generated when CCP merge mode is used to predict the content of an IER. Besides, candidates in the intra lists can be the basic candidates and used to derived other candidates. For instance, a derived candidate 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 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 lists of blocks inside an IER.

[0137] Intra Extrapolated Region (IXR) for CCP Mode

[0138] An IXR is pre-defined. The shape of IXR can be square or non-square, and at least one or more blocks are inside an IXR. When constructing a CCP merge list of a block inside the current IXR, the candidates from the positions inside the current IXR is replaced by the corresponding horizontal or vertical positions outside and adjacent to the current IXR. In one embodiment, for example, if a candidate is at the position (x, y) , and (x, y) is inside the current IXR, then, the position is changed to (x’ , y) or (x, y’) where x’ is the horizontal position outside and adjacent to the current IXR, and y’ is the vertical position outside and adjacent to the current IXR. The information inherited from neighbouring positions is outside the current IXR, where the to-be-inherited information 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) . In another embodiment, one or more CCP merge lists can be firstly generated for the blocks inside the current IXR. Later, the list (s) can be directly used by a block inside the current IXR, or the list (s) is treated as a basis list for constructing a CCP merge list of a block inside the current IXR.

[0139] Example 1: IXR and neighbouring information

[0140] In one embodiment, as shown in Fig. 9, an IXR contains one or more than one blocks. When getting neighbouring information for CCP merge mode, block A can use the neighbouring information at AL1, A1 (or AL2) , AR1, L1 and LB1 positions. Block B can use neighbouring information at AL2, A2, AR2, LB2 positions. Block B may also use neighbouring information at L1 (since L2 is inside the current IXR and replaced by the L1 position corresponding horizontal location adjacent to the current IXR) . Similarly, Block C can use neighbouring information located at AL3, A3, AR3, L1, and LB3 positions (since L3 is inside the current IXR and replaced by the L1 position corresponding to the horizontal location adjacent to the current IXR) .

[0141] In another embodiment, as shown in Fig. 9, the size and the location of the current IXR is used to determine the non-adjacent neighbouring positions. The size of the current IXR can be defined by the width and height of all blocks inside the current IXR. For example, the width of the current IXR is the summation of width of blocks A, B, and C. Similarly, the height of the current IXR is the summation of height of blocks A, B, and C. Besides, the location of the current IXR can be the left-top, right-top, left-bottom, right bottom, or the centre position of the current IXR.

[0142] In another embodiment, as shown in Fig. 9, partial blocks inside the current IXR are jointly used to determine the non-adjacent neighbouring positions. For example, the size and location of block A is used to determine the non-adjacent neighbouring positions. For another example, the size and location of block A and block B are used to determine the non-adjacent neighbouring positions. The size can be defined by the width and height of partial blocks inside the current IXR. For example, the width is the summation of width of partial blocks A and B. Similarly, the height is the summation of height of blocks A and B. Besides, the location can be the left-top, right-top, left-bottom, right bottom, or the centre position of partial blocks inside the current IXR.

[0143] Example 1-1: Update of CCP information inside an IXR

[0144] In another embodiment, partial blocks inside the current IXR can update their CCP information to the later encoding or decoding blocks inside the current IXR.

[0145] In another embodiment, only the first N blocks or the last M blocks can update CCP information to the later encoding or decoding blocks inside the current IXR, where N and M are integer larger than or equal to 0.

[0146] In another embodiment, only some selected blocks can update CCP information to the later encoding or decoding blocks inside the current IXR. For example, the selected blocks can be the block has the largest area inside the current IXR.

[0147] In another embodiment, CCP information of the blocks inside the current IXR is not updated to other blocks inside the current IXR. The CCP information to the later encoding or decoding blocks inside the current IXR is updated to another IXR or the later encoding or decoding blocks outside the current IXR.

[0148] Example 1-2: History buffer of the neighbouring information for CCP merge mode

[0149] In another embodiment, recent CCP information is stored in a history buffer for referenced by the blocks predicted with CCP merge mode inside an IXR. During encoding and decoding, the history buffer is also used inside an IXR to record the recent CCP information. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0150] In another embodiment, the history buffer for storing CCP information is reset before encoding / decoding an IXR, a CTU, multiple CTUs, a slice, multiple slices, or a frame.

[0151] In another embodiment, the history buffer for storing CCP information is reset after encoding / decoding an IXR, a CTU, multiple CTUs, a slice, multiple slices, or a frame.

[0152] In another embodiment, history buffer for storing CCP information is not updated in current IXR during encoding or decoding. The history buffer is updated after the current IXR is encoded or decoded.

[0153] Example 1-3: Intra list generation for blocks inside IXR

[0154] In another embodiment, one or multiple intra lists can be generated inside an IXR. The intra lists can be partially the same or totally different. The intra list can be generated depends on a block or multiple blocks inside an IXR.

[0155] In another embodiment, an intra list for CCP merge mode is regarded as a list of CCP merge mode. For one or more blocks inside an IXR, one or multiple intra lists are generated when CCP merge mode is used to predict the content of an IXR. Besides, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0156] In another embodiment, an intra list for CCP merge mode is regarded as a basis list of CCP merge mode. For one or more blocks inside an IXR, intra lists are generated when CCP merge mode is used to predict the content of an IXR. Besides, candidates in the intra lists can be the basic candidates and used to derived other candidates. For instance, a derived candidate 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 generated as a combination of the two hypotheses. For instance, the derived mode can be a multi-model CCP 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 lists of blocks inside an IXR.

[0157] Reconstruction Sample Usage of IER and IXR

[0158] In one embodiment, partial or whole reconstruction samples adjacent to IER or IXR are used, for instance, template cost calculation. As shown in Fig. 10, 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.

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

[0160] 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 an intra estimation region 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.

[0161] The proposed methods of reducing required information access associated with neighbouring reconstruction samples for decoder-side derived intra-prediction mode derivation by using an intra estimation region as described above can be implemented in an encoder side or a decoder side. For example, 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) ) .

[0162] Fig. 11 illustrates a flowchart of an exemplary video coding system that uses neighbouring reconstruction samples outside an intra estimation region for decoder-side derived intra-prediction mode derivation 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 1110, 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 region from the current picture is determined in step 1120, wherein the intra region is partitioned into one or more blocks. One or more intra lists are derived for a decoder-side derived intra-prediction mode for said one or more blocks inside the intra region based on neighbouring information outside the intra region in step 1130, wherein when a neighbouring position of any block of said one or more blocks is inside the intra region, target neighbouring information associated with the neighbouring position of any block of said one or more blocks is not used. A target block of said one or more blocks is encoded or decoded using coding information comprising said one or more intra lists in step 1140.

[0163] 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.

[0164] 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.

[0165] 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.

[0166] 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 region from the current picture, wherein the intra region is partitioned into one or more blocks;deriving one or more intra lists for a decoder-side derived intra-prediction mode for said one or more blocks inside the intra region based on neighbouring information outside the intra region, wherein when a neighbouring position of any block of said one or more blocks is inside the intra region, target neighbouring information associated with the neighbouring position of any block of said one or more blocks is not used;encoding or decoding a target block of said one or more blocks using coding information comprising said one or more intra lists.2.The method of Claim 1, wherein the target neighbouring information associated with the neighbouring position of any block of said one or more blocks is determined according to a centre unit within the intra region and a horizontal distance and / or vertical distance, and wherein the horizontal distance corresponds to a total width of one or more selected blocks inside the intra region and the vertical distance corresponds to a total height of said one or more selected blocks inside the intra region.3.The method of Claim 1, wherein the neighbouring information associated with one or more selected blocks inside a current intra region is updated during encoding or decoding of said one or more selected blocks inside the intra region, and updated neighbouring information is used by one or more subsequent intra regions.4.The method of Claim 1, wherein the neighbouring information for a current intra region is not updated during encoding or decoding of the intra region until the current intra region is fully encoded or decoded.5.The method of Claim 1, wherein said one or more intra lists are partially the same or totally different.6.The method of Claim 1, wherein the decoder-side derived intra-prediction mode comprises DIMD (Decoder-side Intra Mode Derivation) mode, TIMD (Template-based Intra Mode Derivation) mode, MRL (Multiple Reference Lines) mode, EIP (Extrapolation Filter-Based Intra Prediction) merge mode, DIP (Decoder-derived Intra Prediction) merge mode, or CCP (Cross-Component Prediction) merge mode.7.The method of Claim 6, wherein the neighbouring information inherited from one or more previous intra regions is stored in a history buffer and used by a current intra region.8.The method of Claim 7, wherein when the decoder-side derived intra-prediction mode corresponds to the EIP mode, the neighbouring information for the EIP mode comprises EIP filter shape, EIP reconstructed area, EIP filter coefficients, intra prediction mode derived by a DIMD process, transform set used, template cost, sample value, coded CU information, or a combination thereof.9.The method of Claim 7, wherein when the decoder-side derived intra-prediction mode corresponds to the DIMD mode, the neighbouring information inherited comprises one or more histogram values for available DIMD intra prediction modes, N intra prediction modes suggested by histogram values, DIMD weighting information and / or whether fusion is used or not, reference line information and / or wide-angle conditions, or a combination thereof.10.The method of Claim 7, wherein when the decoder-side derived intra-prediction mode corresponds to the TIMD mode, the neighbouring information inherited comprises one or more TIMD cost values for available TIMD intra prediction mode, N intra prediction modes suggested by TIMD costs, TIMD weighting information and / or whether fusion is used or not, reference line information and / or wide-angle conditions, or a combination thereof.11.The method of Claim 7, wherein when the decoder-side derived intra-prediction mode corresponds to the MRL mode, the neighbouring information inherited comprises one or more reference lines jointly with intra prediction modes, N intra prediction modes suggested by TIMD costs, weighting information and / or whether fusion is used or not, reference line information and / or wide-angle conditions, or a combination thereof.12.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 region from the current picture, wherein the intra region is partitioned into one or more blocks;derive one or more intra lists for a decoder-side derived intra-prediction mode for said one or more blocks inside the intra region based on neighbouring information outside the intra region, wherein when a neighbouring position of any block of said one or more blocks is inside the intra region, target neighbouring information associated with the neighbouring position of any block of said one or more blocks is not used;encode or decode a target block of said one or more blocks using coding information comprising said one or more intra lists.

Images