Method and apparatus of intra estimation region and intra extrapolated region for dip merge mode and EIP merge mode in video coding

Abstract

A method and apparatus for deriving a target intra prediction mode according to decoder-side derived inter-prediction mode derivation are disclosed. According to this method, 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, corresponding neighbouring information from a corresponding horizontal and / or vertical position of the neighbouring position of any block of said one or more blocks outside the intra region is 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 DIP MERGE MODE AND EIP 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, 206, 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 facilitate parallel processing for decoder-side derived intra-prediction mode derivation by avoiding or reducing multiple access of neighbouring reconstruction samples. 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] Extrapolation Filter-Based Intra Prediction (EIP) Mode

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

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

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

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

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

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

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

[0027] Spatial Adjacent and Non-Adjacent Candidates

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

[0029] Temporal and Shifted Temporal Candidates

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

[0031] History-based Candidates

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

[0033] Default Candidates

[0034] 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} } .

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

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

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

[0038] 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. 4, the predictor stage 410 and the rate-distortion optimization (RDO) stage 420 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.

[0039] In the present invention, techniques to facilitate parallel processing for decoder-side derived intra-prediction mode derivation by avoiding or reducing multiple access of neighbouring reconstruction samples are disclosed. BRIEF SUMMARY OF THE INVENTION

[0040] A method and apparatus for video coding 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, corresponding neighbouring information from a corresponding horizontal and / or vertical position of the neighbouring position of any block of said one or more blocks outside the intra region is used. A target block of said one or more blocks is encoded or decoded using coding information comprising said one or more intra lists.

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

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

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

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

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

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

[0047] 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

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

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

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

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

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

[0053] Fig. 5 illustrates an example of hardware encoder architecture.

[0054] Figs. 6A-B illustrate an example of neighbouring reconstruction usage in intra estimation region or the intra extrapolated region according to one embodiment of the present invention.

[0055] Fig. 7 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.

[0056] Fig. 8 illustrates a flowchart of an exemplary video coding system that uses a scheme to facilitate parallel processing for decoder-side derived inter-prediction mode derivation by avoiding or reducing multiple access of neighbouring reconstruction samples according to an embodiment of the present invention.DETAILED DESCRIPTION OF THE INVENTION

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

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

[0059] In this disclosure, several new methods related to decoder-side derived inter-prediction mode are disclosed.

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

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

[0062] 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. 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 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 change rarely, and parallel processing for deriving decoder-side derived intra-prediction mode is more feasible.

[0063] 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 the 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.

[0064] An example of IER is shown in Fig. 6A and Fig. 6B, where four blocks are inside the IER. When utilizing neighbouring reconstruction samples or neighbouring information for decoder-side derived inter-prediction mode, block A can use the reconstruction samples at AL1, A1, AR1, L1 and LB1 as shown in Fig. 6A. But block B can only use reconstruction samples located at AL2, AR2, L2 and LB2 as shown in Fig. 6B since A2 is located inside the intra estimation region. Fig. 7 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.

[0065] Intra Estimation Region (IER) for EIP Mode

[0066] An IER is pre-defined. The IER can be square or non-square, and there can be one or more blocks inside the IER. Inside the region, when computing EIP mode, the blocks cannot use the neighbouring information inside IER. The blocks may only use the neighbouring information outside the IER. In one embodiment, the design of the IER for EIP is unified with the design of the IER for other intra coding tools. The neighbouring information for EIP mode can be EIP filter shape, EIP reconstructed area, EIP filter coefficients, intra prediction mode derived by the DIMD process, transform set (e.g., LFNST, NSPT or MTS) used, template cost, sample value, coded CU information or other decoder-side required information. The neighbouring information is used as evaluation metrics for determining attributes of EIP mode (e.g., filter shape, reconstructed area, filter coefficients, derived intra prediction mode or transform set selected) , as indicators of attributes of EIP mode (e.g., filter shape, reconstructed area, filter coefficients, derived intra prediction mode or transform set selected) or as EIP mode candidate order. One or multiple intra lists will be generated inside IER. The generated intra list for EIP mode can be used directly as a list or as a basis list for other operations.

[0067] Example 1: IER and neighbouring information

[0068] In one embodiment, as shown in Fig. 6A and Fig. 6B, 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. 6A. 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. 6B.

[0069] In another embodiment, as shown in Fig. 6A and Fig. 6B, 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.

[0070] In another embodiment, as shown in Fig. 6A and Fig. 6B, 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.

[0071] Example 1-1: The update of neighbouring information

[0072] In another embodiment, one or more blocks will update neighbouring information for EIP mode during encoding or decoding inside an IER. The updated neighbouring information for EIP mode is used for following IERs.

[0073] In another embodiment, only the first N blocks or the last M blocks will update neighbouring information for EIP mode during encoding or decoding inside an IER, where N and M are integers larger than or equal to 0.

[0074] In another embodiment, only some specific blocks will update neighbouring information for EIP mode during encoding or decoding inside an IER, for example, block with the largest area or the most frequently appeared block inside an IER.

[0075] In another embodiment, neighbouring information for EIP mode is not updated in the current IER during encoding or decoding. The neighbouring information is updated after the current IER is encoded or decoded.

[0076] Example 1-2: History buffer of the neighbouring information for EIP mode

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

[0078] In another embodiment, history buffer of neighbouring information for EIP mode is reset per region, per CTU, per multiple CTUs, per slice, per multiple slices, or per frame.

[0079] In another embodiment, history buffer of the neighbouring information for EIP mode is not updated in the current IER during encoding or decoding. The history buffer is updated after the current IER is encoded or decoded.

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

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

[0082] In another embodiment, an intra list for EIP mode is regarded as a list of EIP mode. For one or more blocks inside an IER, one or more intra lists are generated only once and whenever EIP mode is needed, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0083] In another embodiment, an intra list for EIP mode is regarded as a basis list of EIP mode. For one or more blocks inside an IER, intra lists are generated and whenever EIP 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 filter coefficients of a target mode can be derived by averaging (or weighted averaging) of the filter coefficients of the basic candidates. For instance, a target 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 target mode can be a multi-model EIP 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 EIP merge candidate lists of blocks inside IER.

[0084] Intra Estimation Region (IER) for DIP Merge Mode

[0085] Decoder-derived intra prediction (DIP) merge mode

[0086] Decoder-derived intra prediction (DIP) merge mode is an intra merge scheme. The concept of DIP merge mode is to inherit (or reference) the information from previous coded blocks and to use the inheritance information to predict the current block. When generating the prediction of the current block, one or more inheritance blocks are selected from the DIP merge candidate list. The inheritance information is related to a target mode. Then, the inheritance information from the inheritance blocks is used to generate the prediction according to the target mode. In some embodiments, the inheritance information of each DIP merge candidate can be related to different target modes. For example, the inheritance information can be related to DIMD, TIMD, MRL (Multiple Reference Lines) , EIP mode, or a combination thereof. One DIP merge list can contain the merge candidates with different target modes. The current block can be predicted following DIMD, TIMD, MRL, or EIP depending on which merge candidate is used. In some embodiment, the inheritance information of all DIP merge candidates is related to the same target mode. The DIP merge list contains merge candidates with the same target mode. For example, the inheritance information of all DIP merge candidates is related to DIMD, TIMD, MRL, or EIP mode. In one embodiment, the DIP merge list may include one or more spatial adjacent and / or non-adjacent candidates that reference the information from the spatial adjacent and / or non-adjacent neighbouring coded blocks, one or more temporal candidates which reference the information from the coded blocks in the previous coded picture, one or more history candidates which reference the information from a history buffer, one or more default candidates which derive the information using the existing candidates in the DIP merge list or using any pre-defined method for the current block, or any subset or extension of the above-mentioned candidates.

[0087] Example 0-1: Inheritance information for DIMD

[0088] When the target mode is DIMD, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) one or more histogram (bar) values for the available DIMD intra prediction modes (e.g. DC,  planar, and / or directional prediction modes) (b) the N intra prediction modes (with the highest N histogram bars) suggested by the histogram  values (c) DIMD weighting information and / or fusion or not (d) reference line information and / or wide-angle conditions.

[0089] Example 0-2: Inheritance information for TIMD

[0090] When the target mode is TIMD, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) one or more TIMD cost values for the available TIMD intra prediction modes (e.g. DC, planar,  and / or directional prediction modes) (b) the N intra prediction modes (with the smallest N TIMD costs) suggested by the TIMD costs (c) TIMD weighting information and / or fusion or not (d) reference line information and / or wide-angle conditions.

[0091] Example 0-3: Inheritance information for MRL

[0092] When the target mode is MRL, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) one or more reference lines jointly with intra prediction modes (e.g. DC, planar, and / or  directional prediction modes) (b) the N intra prediction modes (with the smallest N TIMD costs) suggested by the TIMD costs (c) weighting information and / or fusion or not (d) reference line information and / or wide-angle conditions.

[0093] Example 0-4: Inheritance information for EIP

[0094] When the target mode is EIP, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) the filter shape (b) all or parts of the filter coefficients (c) the template used to derive the filter coefficients (d) the derived intra prediction mode and / or the transform set selected and / or the transform flag  selected.

[0095] Example 0-5: Inheritance information for mixed modes

[0096] When the target mode can be mixed mode (e.g. the DIP merge list may contain the merge candidates with different target modes) , the inheritance information includes the following lists or a combination thereof (i) (a) and / or (b) and / or (c) and / or (d) in Example 0-1 (ii) (a) and / or (b) and / or (c) and / or (d) in Example 0-2 (iii) (a) and / or (b) and / or (c) and / or (d) in Example 0-3 (iv) (a) and / or (b) and / or (c) and / or (d) in Example 0-4 (v) coding mode (e.g. the target mode) , and / or corresponding information of the coding mode. For  example, the coding mode can be DIMD-related mode or not, TIMD-related mode or not, MRL-related mode or not, SGPM-related mode or not, ISP-related mode or not, intraTMP-related mode or not, MPM-related mode or not, MIP-related mode or not, EIP-related mode or not, and / or any mode related to a pre-defined intra mode.

[0097] Intra Estimation Region (IER)

[0098] An IER is pre-defined. The IER can be square or non-square, and there can be one or more blocks inside the IER. Inside the region, when computing DIP merge mode, the blocks cannot use the neighbouring information inside IER. The blocks may only use the neighbouring information outside the IER. In one embodiment, the design of the IER for DIP merge mode is unified with the design of the IER for other intra coding tools. The neighbouring information for DIP merge mode can be inheritance information described in Examples 0-1, 0-2, 0-3, 0-4, and 0-5, template cost, sample value, coded CU information or other DIP merge mode required information. The shared required information is used as evaluation metrics for determining attributes of DIP merge mode (e.g. inheritance information described in Examples 0-1, 0-2, 0-3, 0-4, and 0-5) or as indicators of attributes of DIP merge mode (e.g. inheritance information described in Examples 0-1, 0-2, 0-3, 0-4, and 0-5) or as DIP merge candidate order. One or multiple intra lists will be generated inside IER. The generated intra list for DIP merge mode can be used directly as a list or as a basis list for other operations.

[0099] Example 1: IER and neighbouring information

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

[0101] In another embodiment, as shown in Fig. 6A and Fig. 6B, 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.

[0102] In another embodiment, as shown in Fig. 6A and Fig. 6B, 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.

[0103] Example 1-1: The update of neighbouring information

[0104] In another embodiment, one or more blocks will update neighbouring information for DIP merge mode during encoding or decoding inside an IER. The updated neighbouring information for DIP merge mode is used for following IERs.

[0105] In another embodiment, only the first N blocks or the last M blocks will update neighbouring information for DIP merge mode during encoding or decoding inside an IER, where N and M are integers larger than or equal to 0.

[0106] In another embodiment, only some specific blocks will update neighbouring information for DIP merge mode during encoding or decoding inside an IER, such as block with the largest area or the most frequently appeared block inside an IER.

[0107] In another embodiment, neighbouring information for DIP merge mode is not updated in the current IER during encoding or decoding. The neighbouring information is updated after the current IER is encoded or decoded.

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

[0109] In another embodiment, neighbouring information for DIP merge mode for one or more IERs is stored into a history buffer. During encoding and decoding, the history buffer is also used in an IER to derive the neighbouring information for DIP merge mode. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0110] In another embodiment, history buffer of neighbouring information for DIP merge mode is reset per region, per CTU, per multiple CTUs, per slice, per multiple slices, or per frame.

[0111] In another embodiment, history buffer of the neighbouring information for DIP merge mode is not updated in the current IER during encoding or decoding. The history buffer is updated after the current IER is encoded or decoded.

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

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

[0114] In another embodiment, an intra list for DIP merge mode is regarded as a list of intra prediction modes that can be a target mode in DIP merge mode. For one or more blocks inside an IER, one or multiple intra lists are generated once and whenever DIP merge mode is needed, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0115] In another embodiment, an intra list for DIP merge mode is regarded as a basis list of DIP merge mode. For one or more blocks inside an IER, intra lists are generated and whenever DIP merge 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, a target 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. And the final hypothesis is a combination of the two hypotheses. For instance, the target mode can be a multi-model 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, if the basic candidate is in DIMD, TIMD, MRL mode, the derived mode can be derived by changing the reference line, modifying the blending weight or offsetting the intra prediction mode (±1, ±2) of the basic candidate. For instance, the derived modes based on basic candidates can be added into DIP merge candidate lists of blocks inside IER.

[0116] Intra Extrapolated Region (IXR) for EIP Mode

[0117] 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 EIP 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 EIP mode can be EIP filter shape, EIP reconstructed area, EIP filter coefficients, intra prediction mode derived by the DIMD process, transform set (e.g. LFNST, NSPT or MTS) used, template cost, sample value, coded CU information or other decoder-side required information. The neighbouring information is used as evaluation metrics for determining attributes of EIP mode (e.g. filter shape, reconstructed area, filter coefficients, derived intra prediction mode or transform set selected) , as indicators of attributes of EIP mode (e.g. filter shape, reconstructed area, filter coefficients, derived intra prediction mode or transform set selected) , or as EIP mode candidate order. One or more intra lists will be generated inside the IXR. The generated intra list for EIP mode can be used directly as a list or as a basis list for other operations.

[0118] Example 1: IXR &neighbouring information

[0119] In one embodiment, as shown in Fig. 7, one or more blocks are inside an IXR. When calculating neighbouring information for EIP 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.

[0120] In another embodiment, as shown in Fig. 7, 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.

[0121] In another embodiment, as shown in Fig. 7, 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.

[0122] Example 1-1: The update of neighbouring information

[0123] In another embodiment, one or more blocks will update neighbouring information for EIP mode during encoding or decoding inside an IXR. The updated neighbouring information for EIP mode is used for following IXRs.

[0124] In another embodiment, only the first N blocks or the last M blocks will update neighbouring information for EIP mode during encoding or decoding inside an IXR, where N and M are integers larger than or equal to 0.

[0125] In another embodiment, only some specific blocks will update neighbouring information for EIP mode during encoding or decoding inside an IXR, for example, block with the largest area or the most frequently appeared block inside an IXR.

[0126] In another embodiment, neighbouring information for EIP 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.

[0127] Example 1-2: History buffer of the neighbouring information for EIP mode

[0128] In another embodiment, neighbouring information for EIP 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 EIP mode. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0129] In another embodiment, the history buffer of neighbouring information for EIP mode is reset per region, per CTU, per multiple CTUs, per slice, per multiple slices, or per frame.

[0130] In another embodiment, the history buffer of the neighbouring information for EIP 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.

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

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

[0133] In another embodiment, an intra list for EIP mode is regarded as a list of EIP mode. For one or more blocks inside an IXR, one or multiple intra lists are generated once and whenever EIP mode is needed, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0134] In another embodiment, an intra list for EIP mode is regarded as a basis list of EIP mode. For one or more blocks inside an IXR, intra lists are generated and whenever EIP 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 filter coefficients of a target mode can be derived by averaging (or weighted averaging) of the filter coefficients of the basic candidates. For instance, a target 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. And the final hypothesis is a combination of the two hypotheses. For instance, the target mode can be a multi-model EIP 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 EIP merge candidate lists of blocks inside the IXR.

[0135] Intra Extrapolated Region (IXR) for DIP Merge Mode

[0136] Decoder-derived intra prediction (DIP) merge mode

[0137] Decoder-derived intra prediction (DIP) merge mode is an intra merge scheme. The concept of DIP merge mode is to inherit (or reference) the information from previous coded blocks and to use the inheritance information to predict the current block. When generating the prediction of the current block, one or more inheritance blocks are selected from a DIP merge candidate list. The inheritance information is related to a target mode. Then, the inheritance information from the inheritance blocks is used to generate the prediction according to the target mode. In some embodiments, the inheritance information of each DIP merge candidate can be related to different target modes. For example, the inheritance information can be related to DIMD, TIMD, MRL, EIP mode, or a combination thereof. One DIP merge list can contain the merge candidates with different target modes. The current block can be predicted following DIMD, TIMD, MRL, or EIP depending on which merge candidate is used. In some embodiment, the inheritance information of all DIP merge candidates is related to the same target mode. The DIP merge list contains merge candidates with the same target mode. For example, the inheritance information of all DIP merge candidates is related to DIMD, TIMD, MRL, or EIP mode.

[0138] Example 0-1 Inheritance information for DIMD

[0139] When the target mode is DIMD, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) one or more histogram (bar) values for the available DIMD intra prediction modes (e.g. DC,  planar, and / or directional prediction modes) (b) the N intra prediction modes (with the highest N histogram bars) suggested by the histogram  values (c) DIMD weighting information and / or fusion or not (d) reference line information and / or wide-angle conditions.

[0140] Example 0-2 Inheritance information for TIMD

[0141] When the target mode is TIMD, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) one or more TIMD cost values for the available TIMD intra prediction modes (such as DC,  planar, and / or directional prediction modes) (b) the N intra prediction modes (with the smallest N TIMD costs) suggested by the TIMD costs (c) TIMD weighting information and / or fusion or not (d) reference line information and / or wide-angle conditions.

[0142] Example 0-3: Inheritance information for MRL

[0143] When the target mode is MRL, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) one or more reference lines jointly with intra prediction modes (e.g. DC, planar, and / or directional  prediction modes) (b) the N intra prediction modes (with the smallest N TIMD costs) suggested by the TIMD costs (c) weighting information and / or fusion or not (d) reference line information and / or wide-angle conditions.

[0144] Example 0-4: Inheritance information for EIP

[0145] When the target mode is EIP, the inheritance information includes items (a) , (b) , (c) , (d) , or a combination thereof. (a) the filter shape (b) all or parts of the filter coefficients (c) the template used to derive the filter coefficients (d) the derived intra prediction mode and / or the transform set selected and / or the transform flag  selected.

[0146] Example 0-5: Inheritance information for mixed modes

[0147] When the target mode can be mixed mode (i.e., the DIP merge list may contain the merge candidates with different target modes) , the inheritance information includes the following lists or a combination thereof. (i) (a) and / or (b) and / or (c) and / or (d) in Example 0-1 (ii) (a) and / or (b) and / or (c) and / or (d) in Example 0-2 (iii) (a) and / or (b) and / or (c) and / or (d) in Example 0-3 (iv) (a) and / or (b) and / or (c) and / or (d) in Example 0-4 (v) coding mode (i.e. the target mode) , and / or corresponding information of the coding mode. For  example, the coding mode can be DIMD-related mode or not, TIMD-related mode or not, MRL-related mode or not, SGPM-related mode or not, ISP-related mode or not, intraTMP-related mode or not, MPM-related mode or not, MIP-related mode or not, EIP-related mode or not, and / or any mode related to a pre-defined intra mode.

[0148] Intra Extrapolated Region (IXR)

[0149] 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 DIP merge 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 DIP merge mode can be inheritance information described in Examples 0-1, 0-2, 0-3, 0-4, 0-5, template cost, sample value, coded CU information or other DIP merge mode required information. The shared required information is used as evaluation metrics for determining attributes of DIP merge mode (e.g. inheritance information described in Examples 0-1, 0-2, 0-3, 0-4, and 0-5) or as indicators of attributes of DIP merge mode (e.g. inheritance information described in Examples 0-1, 0-2, 0-3, 0-4, and 0-5) or as DIP merge candidate order. One or multiple intra lists will be generated inside IXR. The generated intra list for DIP merge mode can be used directly as a list or as a basis list for other operations.

[0150] Example 1: IXR and neighbouring information

[0151] In one embodiment, as shown in Fig. 7, one or more blocks are inside an IXR. When calculating neighbouring information for DIP merge 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.

[0152] In another embodiment, as shown in Fig. 7, 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.

[0153] In another embodiment, as shown in Fig. 7, one or more blocks inside 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.

[0154] Example 1-1: The update of neighbouring information

[0155] In another embodiment, one or more blocks will update neighbouring information for DIP merge mode during encoding or decoding inside an IXR. The updated neighbouring information for DIP merge mode is used for following IXRs.

[0156] In another embodiment, only the first N blocks or the last M blocks will update neighbouring information for DIP merge mode during encoding or decoding inside an IXR, where N and M are integers larger than or equal to 0.

[0157] In another embodiment, only some specific blocks will update neighbouring information for DIP merge mode during encoding or decoding inside an IXR, for example, block with the largest area or the most frequently appeared block inside an IXR.

[0158] In another embodiment, neighbouring information for DIP merge 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.

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

[0160] In another embodiment, neighbouring information for DIP merge mode for one or more IXRs is stored into a history buffer. During encoding and decoding, the history buffer is also used in an IXR to derive the neighbouring information for DIP merge mode. The history buffer can be a first-in-first-out or last-in-first-out buffer.

[0161] In another embodiment, history buffer of neighbouring information for DIP merge mode is reset per region, per CTU, per multiple CTUs, per slice, per multiple slices, or per frame.

[0162] In another embodiment, history buffer of the neighbouring information for DIP merge 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.

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

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

[0165] In another embodiment, an intra list for DIP merge mode is regarded as a list of intra prediction modes that can be a target mode in DIP merge mode. For one or more blocks inside an IXR, one or more intra lists are generated once and whenever DIP merge mode is needed, candidates in the intra lists can be directly used or the whole intra lists can be used.

[0166] In another embodiment, an intra list for DIP merge mode is regarded as a basis list of DIP merge mode. For one or more blocks inside an IXR, intra lists are generated and whenever DIP merge 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, a target 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. And the final hypothesis is a combination of the two hypotheses. For instance, the target mode can be a multi-model 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, if the basic candidate is in DIMD, TIMD, or MRL mode, the derived mode can be derived by changing the reference line, modifying the blending weight or offsetting the intra prediction mode (± 1, ± 2) of the basic candidate. For instance, the derived modes based on basic candidates can be added into DIP merge candidate lists of blocks inside IXR.

[0167] Any of the foregoing proposed methods of target intra prediction mode derivation according to decoder-side derived intra-prediction mode derivation using an intra estimation region or an intra extrapolated 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.

[0168] The proposed methods of target intra prediction mode derivation according to decoder-side derived intra-prediction mode derivation using an intra estimation region or an intra extrapolated 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) ) .

[0169] Fig. 8 illustrates a flowchart of an exemplary video coding system that uses a scheme to facilitate parallel processing for decoder-side derived inter-prediction mode derivation by avoiding or reducing multiple access of neighbouring reconstruction samples 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 block are received in step 810, 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 in step 820, wherein the intra region is partitioned into one or more blocks. One or more intra lists for a decoder-side derived intra-prediction mode for said one or more blocks inside the intra region are derived based on neighbouring information outside the intra region in step 830, wherein when a neighbouring position of any block of said one or more blocks is inside the intra region, corresponding neighbouring information from a corresponding horizontal and / or vertical position of the neighbouring position of any block of said one or more blocks outside the intra region is 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 840.

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

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

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

[0173] 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, corresponding neighbouring information from a corresponding horizontal and / or vertical position of the neighbouring position of any block of said one or more blocks outside the intra region is 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 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.3.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.4.The method of Claim 1, wherein said one or more intra lists are partially the same or totally different.5.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.6.The method of Claim 5, 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.7.The method of Claim 6, 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.8.The method of Claim 6, 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.9.The method of Claim 6, 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.10.The method of Claim 6, 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.11.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, corresponding neighbouring information from a corresponding horizontal and / or vertical position of the neighbouring position of any block of said one or more blocks outside the intra region is used;encode or decode a target block of said one or more blocks using coding information comprising said one or more intra lists.

Images