Utilizing block vectors to derive merge candidates

Abstract

A method of implementing merge mode candidates using cascaded vectors is provided. A video coder derives one or more cascaded vectors by recursively tracing block vectors or motion vectors starting from a guiding vector that may be a vector provided by a prediction mode of the current block, or a vector provided by a previously coded block at a neighboring position relative to the current block. The video coder constructs a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors, each candidate providing inheritance information associated with the candidate's corresponding derived merge candidate position. The video coder selects a candidate from the merge candidate list. The video coder generates a predictor of the current block based on the inheritance information provided by the selected candidate and encodes or decodes the current block by using the generated predictor.

Description

UTILIZING BLOCK VECTORS TO DERIVE MERGE CANDIDATESCROSS REFERENCE TO RELATED PATENT APPLICATION (S)

[0001] The present disclosure is part of a non-provisional application that claims the priority benefit of U.S. Provisional Patent Application No. 63 / 747,404, filed on 21 January 2025. Contents of above-listed applications are herein incorporated by reference.TECHNICAL FIELD

[0002] The present disclosure relates generally to video coding. In particular, the present disclosure relates to methods of coding pixel blocks by using block vectors to perform prediction.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

[0004] High-Efficiency Video Coding (HEVC) is an international video coding standard developed by the Joint Collaborative Team on Video Coding (JCT-VC) . HEVC is based on the hybrid block-based motion-compensated DCT-like transform coding architecture. The basic unit for compression, termed coding unit (CU) , is a 2Nx2N square block of pixels, and each CU can be recursively split into four smaller CUs until the predefined minimum size is reached. Each CU contains one or multiple prediction units (PUs) .

[0005] Versatile video coding (VVC) is the latest international video coding standard developed by the Joint Video Expert Team (JVET) of ITU-T SG16 WP3 and ISO / IEC JTC1 / SC29 / WG11. The input video signal is predicted from the reconstructed signal, which is derived from the coded picture regions. The prediction residual signal is processed by a block transform. The transform coefficients are quantized and entropy coded together with other side information in the bitstream. The reconstructed signal is generated from the prediction signal and the reconstructed residual signal after inverse transform on the de-quantized transform coefficients. The reconstructed signal is further processed by in-loop filtering for removing coding artifacts. The decoded pictures are stored in the frame buffer for predicting the future pictures in the input video signal.

[0006] In VVC, a coded picture is partitioned into non-overlapped square block regions represented by the associated coding tree units (CTUs) . The leaf nodes of a coding tree correspond to the coding units (CUs) . A coded picture can be represented by a collection of slices, each comprising an integer number of CTUs.

[0007] Each CU contains one or more prediction units (PUs) . The prediction unit, together with the associated CU syntax, works as a basic unit for signaling the predictor information. The specified prediction process is employed to predict the values of the associated pixel samples inside the PU.

[0008] For each inter-predicted CU, motion parameters consisting of motion vectors, reference picture indices and reference picture list usage index, and additional information are used for inter-predicted sample generation. The motion parameter can be signalled in an explicit or implicit manner. When a CU is coded with skip mode, the CU is associated with one PU and has no significant residual coefficients, no coded motion vector delta or reference picture index. A merge mode is specified whereby the motion parameters for the current CU are obtained from neighbouring CUs, including spatial and temporal candidates, and additional schedules introduced in VVC. The merge mode can be applied to any inter-predicted CU. The alternative to merge mode is the explicit transmission of motion parameters, where motion vector, corresponding reference picture index for each reference picture list and reference picture list usage flag and other needed information are signalled explicitly per each CU.SUMMARY

[0009] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select and not all implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0010] Some embodiments of the disclosure provide methods of implementing merge mode candidates using cascaded vectors. A video coder derives one or more cascaded vectors by recursively tracing block vectors (BVs) or motion vectors (MVs) starting from a guiding vector. The video coder constructs a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors, each candidate providing inheritance information associated with the candidate’s corresponding derived merge candidate position. The video coder selects a candidate from the merge candidate list. The video coder generates a predictor of the current block based on the inheritance information provided by the selected candidate. The video coder encodes or decodes the current block by using the generated predictor.

[0011] In some embodiments, the guiding vector may be a block vector or motion vector provided by a prediction mode of the current block (e.g., IBC, IntraTMP, regular Inter, etc. ) and not retrieved from a merge candidate list. The guiding vector may be a block vector or a motion vector provided by a previously coded block at a neighboring position relative to the current block. The neighboring position may be a candidate in the merge candidate list.

[0012] In some embodiments, the merge candidate list may be used for any one of regular inter merge mode, intraTMP merge mode, intra block copy (IBC) merge mode, cross component prediction (CCP) merge mode, and extrapolated filter-based intra prediction (EIP) merge mode. The inheritance information provided by a candidate may include sample values of a reference block, or a cross-component model, or an extrapolated filter-based intra prediction model, or a block vector, a motion vector, an intra directional mode, a non-directional mode, a fusion weight, a set of reference lines, and a set of sample values.

[0013] In some embodiments, at least one target block vector among the recursively traced block vectors or motion vectors is derived from a target reference block located corresponding to the guiding vector or the one or more cascaded vectors. The target reference block located corresponding to the guiding vector may be coded in block vector guided extrapolated intra prediction (BVG-EIP) , block vector guided convolutional cross-component model (BVG-CCCM) , block vector guided decoder-side intra mode derivation (BVG-DIMD) , decoder-side intra mode derivation (DIMD) , spatial geometric partition mode (SGPM) , direct block vector (DBV) , intra block copy (IBC) , or intra template matching prediction (IntraTMP) . Prediction of the target reference block may be generated based on (i) coding information derived based on samples in one or more further reference blocks referenced by the target reference block based on the at least one target block vector, or (ii) sample values in one or more further reference blocks referenced by the target reference block based on the at least one target block vector.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are included to provide a further understanding of the present disclosure, and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.

[0015] FIG. 1 shows an example derivation of auto-relocated block vector prediction.

[0016] FIG. 2 illustrates five positions that are used to derive auto-relocated block vector prediction.

[0017] FIG. 3 illustrates using IntraTMP block vector for an IBC block.

[0018] FIG. 4 illustrates a defined type of filter shape having 15 inputs and generating one output for extrapolation intra prediction (EIP) .

[0019] FIG. 5 conceptually illustrates a diagonal order according to which an EIP filter is applied to generate a predictor for the current block.

[0020] FIG. 6 illustrates a reference area used in the block-vector guided EIP.

[0021] FIG. 7 conceptually illustrates a prediction using block vector guided DIMD.

[0022] FIG. 8 illustrates a spatial GPM candidates list.

[0023] FIG. 9 conceptually illustrates a current block that is coded according to a reference block located in the current picture by a block vector.

[0024] FIG. 10 illustrates a merge scheme in which a merge mode candidate list is constructed based on cascaded vectors that are recursively traced BVs or MVs starting from a guiding vector.

[0025] FIG. 11 conceptually illustrates a merge scheme in which a merge mode candidate list is constructed based on cascaded vectors starting from a guiding vector that is provided by a previously coded block at a predefined neighboring position.

[0026] FIG. 12 illustrates an example video encoder that may implement merge mode prediction.

[0027] FIG. 13 illustrates portions of the video encoder that implement merge mode prediction based on cascaded vectors.

[0028] FIG. 14 conceptually illustrates a process for encoding a pixel block by using merge candidate list constructed based on cascaded vectors.

[0029] FIG. 15 illustrates an example video decoder that may implement merge mode prediction.

[0030] FIG. 16 illustrates portions of the video decoder that implement merge mode prediction based on cascaded vectors.

[0031] FIG. 17 conceptually illustrates a process for decoding a pixel block by using merge candidate list constructed based on cascaded vectors.

[0032] FIG. 18 conceptually illustrates an electronic system with which some embodiments of the present disclosure are implemented.DETAILED DESCRIPTION

[0033] In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. Any variations, derivatives and / or extensions based on teachings described herein are within the protective scope of the present disclosure. In some instances, well-known methods, procedures, components, and / or circuitry pertaining to one or more example implementations disclosed herein may be described at a relatively high level without detail, in order to avoid unnecessarily obscuring aspects of teachings of the present disclosure. I. Block Vector Based Coding Tools

[0034] A. Intra Block Copy (IBC)

[0035] Intra block copy (IBC) is a block level coding mode, in which block matching (BM) is performed at the encoder to find the optimal block vector (or motion vector) for each CU. Here, a block vector is used to indicate the displacement from the current block to a reference block, which is already reconstructed inside the current picture. An IBC-coded CU is typically considered as the third prediction mode other than intra or inter prediction modes.

[0036] B. IBC Merge  / AMVP List Construction

[0037] At CU level, IBC mode is signalled with a flag and it can be signaled as IBC AMVP mode or IBC skip / merge mode. To signal as IBC skip / merge mode, a merge candidate index is used to indicate which of the block vectors in the list from neighboring candidate IBC coded blocks is used to predict the current block. The merge list consists of spatial, HMVP, and pairwise candidates. To signal as IBC AMVP mode, block vector difference is coded in the same way as a motion vector difference. The block vector prediction method uses two candidates as predictors, one from left neighbor and one from above neighbor (if IBC coded) . When either neighbor is not available, a default block vector will be used as a predictor. A flag is signaled to indicate the block vector predictor index.

[0038] FIG. 1 shows an example derivation of auto-relocated block vector prediction (AR-BVP. ) As illustrated, a guiding block vector BV0, 1 (i.e., an existing BVP already in the candidate list) associated with the current block B0 points to a reference block B1. If B1 has a BV denoted as BV1, 2 pointing to a reference block B2, then BV0, 2, given by BV0, 2 = BV0, 1 +BV1, 2, is defined as the AR-BVP, guided by BV0, 1. When deriving BVn, n+1 guided by BV0, n, five positions of Bn are checked to find BVn, n+1.

[0039] FIG. 2 illustrates these five positions of Bn that are checked to find BVn, n+1, (with n set to 1) . As illustrated, the five positions include top-left ( “LT” ) , top-right ( “RT” ) , center ( “Ctr” ) , bottom-right ( “RB” ) , and bottom-left ( “LB” ) .

[0040] B2. Chained Motion Vector Prediction (CMVP)

[0041] In some embodiments, chained motion vector prediction (CMVP) candidates are inserted as one of merge candidates for regular merge or TM merge modes. The CMVP shares a similar idea with auto-relocated block vector prediction described in Section I. B, and CMVP candidates are derived as the accumulation of the recursively traced MVs and BVs based on the pre-derived MVs. In some embodiments, CMVP candidates can be derived for each merge index and each reference picture list. The traceable reference pictures are restricted to the reference pictures in the reference picture list.

[0042] C. Intra Template Matching (IntraTMP)

[0043] Intra template matching prediction (IntraTMP) is a special intra prediction mode that copies the best prediction block from the reconstructed part of the current frame, whose L-shaped template matches the current template. For a predefined search range, the encoder searches for the most similar template to the current template in a reconstructed part of the current frame and uses the corresponding block as a prediction block. The encoder then signals the usage of this mode, and the same prediction operation is performed at the decoder side.

[0044] The prediction signal is generated by matching the L-shaped, Top-only or Left-Only causal neighbor of the current block with another block in a predefined search area. IntraTMP employs an implicit merge mode, where merge candidates are considered without signaling a merge flag or index. Specifically, the reference positions pointed by the block vectors of all the adjacent and non-adjacent merge candidates (coded in IntraTMP or IBC mode) are used as additional candidates beyond the default search areas, up to 10 merge candidates are derived from the neighboring PUs and by prioritizing the candidates outside the IntraTMP search range. In addition, up to 20 auto-relocated block vector prediction (AR-BVP) candidates are constructed to get more reference positions. Finally, up to 20 AR-BVPs can be constructed and there are up to 30 merge candidates in total. If an AR-BVP candidate is selected for refinement, it would have a refinement range of 3x3.

[0045] The same template matching cost is used to compare the merge positions and the defaults ones. For bi-directional IBC merge candidate, two candidates are retained corresponding to each reference frame. Similarly, for IntraTMP, two candidates are considered corresponding to the best candidate by template search and the coded candidate. Sum of absolute differences (SAD) is used as a cost function for the search.

[0046] In some embodiments, one or more block vectors derived from the intra template matching prediction (IntraTMP) is / are used for intra block copy (IBC) . The stored IntraTMP BV of the neighboring blocks along with IBC BV are used as spatial BV candidates in IBC candidate list construction. IntraTMP block vector is stored in the IBC block vector buffer and, the current IBC block can use both IBC BV and IntraTMP BV of neighboring blocks as BV candidate for IBC BV candidate list.

[0047] FIG. 3 illustrates using IntraTMP block vector for an IBC block. In the figure, current block 310 is coded by IBC. An earlier coded neighboring block 320 is coded by IntraTMP, which uses template 325 of the block 320 to match with a template 335 of a reference block 330. A IntraTMP block vector 305 is used to locate the reference block 330. The Intra TMP block vector 305 is also stored for use by the subsequently IBC coded current block 310. IntraTMP block vectors are added to IBC block vector candidate list as spatial candidates. IntraTMP block vectors are stored in quarter-pel resolution for coding of IBC block vectors and HMVP.

[0048] D. Direct Block Vector (DBV) for chroma block

[0049] The direct block vector is used for chroma blocks. A flag is signaled to indicate whether a chroma block is coded using IBC mode. If one of the luma blocks in five specific locations is coded with IBC or intraTMP mode, the block vector of that luma block is scaled and is used as the block vector for the chroma block. Template matching may be used to perform block vector scaling.

[0050] E. Block Vector guided EIP

[0051] Extrapolation Intra Prediction (or EIP) is an intra prediction mode that applies a linear model or filter to generate an intra-prediction of the current block, where the EIP linear model or filter is derived by using reconstructed pixels in an extended template region neighboring the current block. The extended template region extends beyond the edges of the current block by predefined lengths (or a predefined number of pixel positions. )

[0052] FIG. 4 illustrates a defined type of filter shape having 15 inputs and generating one output for EIP. FIG. 5 conceptually illustrates a diagonal order according to which an EIP filter 505 is applied to generate a predictor for the current block. As illustrated, the EIP filter 505 traverses through the samples of the current block 510 to generate the predictor. The EIP filter 505 uses reconstructed samples in an extended template region 520 neighboring the current block 510 and predicted samples within the current block 510 as inputs to the EIP filter 505.

[0053] The block-vector guided EIP (BV-EIP) method uses a block vector to determine the reference area for calculating the EIP filter parameters instead of directly using the adjacent spatial reference area and is coded as a sub-mode of EIP. Then the current coding unit utilizes the calculated EIP filter parameters and neighboring reconstructed samples to create the prediction. FIG. 6 illustrates a reference area 630 used in the block-vector guided EIP (BV-EIP) method. One flag is signaled to indicate the usage of this sub-mode of EIP. The block vector 615 used in this method is derived from the rough searching process of the intraTMP. The reference area 630 includes the reference block 620 that is located by the block vector 615 and a template 625 neighboring the reference block 620.

[0054] In some embodiments, for a CU coded in the EIP mode, an EIP merge flag may be signaled 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 signaled 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.

[0055] F. DIMD and Block Vector guided DIMD

[0056] Decoder-Side Intra Mode Derivation (DIMD) is a technique in which one or more, for example, two, intra prediction modes such as angles or directions are derived from the reconstructed neighbor samples (template) of a block, and those two predictors are combined with the non-angular predictor such as planar mode predictor with the weights derived from the gradients. To implicitly derive the intra prediction modes of a block, a texture gradient analysis is performed at both encoder and decoder sides. This process starts with an empty Histogram of Gradient (HoG) having 65 entries, corresponding to the 65 angular / directional intra prediction modes. Amplitudes of these entries are determined during the texture gradient analysis.

[0057] In some embodiments, when DIMD is applied, up to five intra modes are derived from the reconstructed neighbor samples, and those five predictors are combined with the non-directional predictor (planar or block vector based predictor) with the weights derived from the histogram of gradients. The decision between for the non-directional modes is taken according to the template cost. Specifically, the block vectors of all adjacent and non-adjacent merge candidates (coded in IntraTMP or IBC) are compared to planar prediction on the reconstructed template. The template cost (SATD) is used to select the best predictor among them.

[0058] Another mode called block vector guided DIMD (BVG-DIMD) is conceptually illustrated in FIG. 7. In BVG-DIMD, directional predictors and non-directional predictor are combined to form a prediction block of the current block.

[0059] In some embodiments, the reference samples pointed or identified by the block vectors 715, instead of the neighboring samples, are used to build an HoG 730. The HoG 730 is then used to derive the five intra modes that are used to derive the directional prediction 740. Up to 5 block vectors 715 may be obtained by the same searching process as in intraTMP. With each block vector, a reference area in the current picture is determined and its samples are used to derive the intra modes and corresponding amplitudes. To reduce complexity, overlapping reference areas are clustered. All results are counted in constructing the HoG. Two intra modes with the highest amplitudes are selected from the HoG and the prediction of the current block is the blending of those 2 predictors and a non-directional predictor. The non-directional predictor is the blending of up to 5 BV-based predictors obtained using the block vectors.

[0060] G. Block Vector guided CCCM

[0061] Convolutional cross-component model (CCCM) may be applied to predict chroma samples from reconstructed luma samples. The reconstructed luma samples are down-sampled to match the lower resolution chroma grid when chroma sub-sampling is used. Top, left or top and left reference samples are used as templates for model derivation.

[0062] When the co-located luma prediction is coded with IBC or IntraTMP in Intra slices, the block vector guided CCCM (BVG-CCCM) mode can be used. In this mode, the block vectors of the co-located luma blocks, coded in IBC or intraTMP modes, are used to determine the reference area for calculating the CCCM parameters. The BVG-CCCM mode uses an 11-tap filter for cross-component prediction as below: predChromaVal = c0C + c1N + c2S + c3E + c4W + c5P (C) + c6P (N) + c7P (S) + c8P (W) +c9P (E) + c10B

[0063] The input to the spatial 5-tap component of the filter consists of a center (C) luma sample which is collocated with the chroma sample to be predicted and its above / north (N) , below / south (S) , left / west (W) and right / east (E) neighbors as illustrated CCCM. The nonlinear term P is represented as power of two of the corresponding luma sample and B is the bias term.

[0064] Similar to Direct Block Vector (DBV) mode, five locations in the collocated luma block area are scanned and the associated block vectors are then used for determining the reference area for parameter calculation in BVG-CCCM method.

[0065] H. Spatial Geometric Partitioning Mode (SGPM) with Block Vectors

[0066] Geometric Partitioning Mode (GPM) is a prediction mode in which a CU is split into at least two parts by a geometrically located straight line. The location of the splitting line is mathematically derived from the angle and offset parameters of a specific partition. Each GPM partitioning or GPM split is a partition mode characterized by a distance-angle pairing that defines a segmenting line.

[0067] Spatial GPM (SGPM) is an intra mode that resembles the inter coding tool of GPM, where the two prediction parts are generated from intra predicted process. In this mode, a candidate list is built with each entry comprising a combination of one partition split and two intra prediction modes. FIG. 8 illustrates a spatial GPM candidates list. 26 partition modes and 9 of intra prediction modes are used to form the combinations as the entries of the SGPM candidate list. The length of the candidate list is set equal to 16. The selected candidate index is signalled.

[0068] In some embodiments, for each partition mode, a list of intra prediction modes (IPM list) is derived for each partition using an intra-inter GPM list derivation that is the same as GPM. The list is further augmented with block-vector based prediction candidates obtained from the adjacent and non-adjacent merge candidates coded in IntraTMP or IBC mode. The final IPM list may contain up to 9 predictors that include 3 regular intra modes and up to 6 BV-based predictors. II. CCP merge mode (Non-Local CCCP)

[0069] For chroma coding, a CCP merge candidate list may be constructed from the spatial adjacent, temporal, spatial non-adjacent, history-based m or shifted temporal candidates. After including these candidates, default models are further included to fill the remaining empty positions in the merge list. Pruning operation is applied. After constructing the list, the CCP models in the list are reordered depending on the SAD costs, which are obtained using the neighbouring template of the current block. A flag is signaled to indicate whether the CCP merge mode is applied or not. If CCP merge mode is applied, an index is signaled to indicate which candidate model is used by the current block.

[0070] For spatial adjacent and non-adjacent candidates, the positions and inclusion order of the spatial adjacent and non-adjacent candidates are the same as those defined for regular inter merge prediction candidates.

[0071] For temporal and shifted temporal candidates, the temporal candidates are selected from the collocated picture. The position and inclusion order of the temporal candidates are the same as those defined 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 neighboring blocks.

[0072] For history-based candidates, 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.

[0073] For default candidates, 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} } .

[0074] In some embodiments, the cross-component prediction merge mode is extended to chroma inter coding. The CCP models including CCLM, MMLM, CCCM, GLM, chroma fusion, CCP merge modes, and inter CCCM are stored and inherited for the following coding chroma intra and inter blocks. Similar to the CCP merge for chroma intra blocks, a flag is signaled to indicate whether a chroma inter block is coded using this mode. If the CCP merge mode is used, a CCP merge list is constructed in a similar way as that for chroma intra blocks except that additional shifted temporal candidate and on-the-fly derived candidates are included in the CCP merge list. The additional shifted temporal candidates are derived from the collocated picture, and the position of these candidates are the same as those defined for regular inter merge prediction candidates with a shift obtained from the motion vector of the current block. The on-the-fly derived candidates are only used for low delay pictures and are obtained using the neighboring reconstructed samples of the current block. At most 1 on-the-fly derived candidates including single / multi-model CCCM and single / multi-model CCLM are added to the CCP merge list. After the CCP merge list is constructed, the candidate with the lowest template cost is selected for the chroma inter block. The chroma inter block is then predicted in the same way as that of inter CCCM. That is, the motion compensation predicted samples are blended with the cross-component predicted samples to form the final prediction. III. Referencing Block Vectors

[0075] Block-vector (BV) based coding tools can be adopted in video coding standards to improve coding efficiency. For some embodiments of the disclosure, two methods ( “first method” and “second method” ) of utilizing block vectors in coding tools are described as following:

[0076] (1) First method: Using one or more block vectors of the current block (i.e., not a vector of a neighboring position retrieved from a merge list) to encode or decode the current block. Such block vectors of the current block are referred to as “first target block vectors. ” FIG. 9 conceptually illustrates a current block 910 that is coded according to a reference block 930 located in the current picture 900 by a block vector 915 of the current block. For example, in some embodiments, the prediction of the current block (e.g., block 910) may be generated based on coding information derived based on samples in reference blocks (e.g., block 930) . The coding information may be an EIP model or intra modes. For another example, in some embodiments, the prediction of the current block is generated based on sample values in reference blocks. This first method will be further described in Section III. Abelow.

[0077] (2) Second method: Using one or more block vectors of a neighboring blocks to encode or decode the current block. Such block vectors of the neighboring block are referred to as “second target block vectors” . The second target block vectors may be available for coding the current block through a merge mode (e.g., regular inter merge mode, intraTMP merge mode, IBC merge mode, CCP merge mode, EIP merge mode, etc. ) . In some embodiments, the candidate list of the merge mode may be constructed to include candidates that are derived by cascading or accumulating recursively traced second target block vectors and / or MVs based on a guiding BV or MV. This second method will be further described in Section III. B below.

[0078] A. Deriving first target block vectors of the current block

[0079] In some embodiments, when coding the current block, one or more block vectors are derived or selected for the current block, and the current block is coded according to reference blocks located by the one or more block vectors of the current block. The one or more block vectors derived / selected for the current block can be the first target block vectors and can be referenced by subsequent blocks.

[0080] In some embodiments, when coding the current block, one or more block vectors are derived / selected for the current block. Coding information is derived based on samples in reference blocks located by one or more block vectors of the current block. The prediction of the current block is then generated based on the coding information. The coding information may be filter-based models, parameter models, cross-component models, or intra prediction modes. The one or more block vectors derived / selected for the current block can be the first target block vectors and can be referenced by subsequent blocks. The following are examples of the coding information derived based on samples in reference blocks located by one or more block vectors of the current block:

[0081] For a first example, in some embodiments, the coding information is EIP models derived based on samples in the reference blocks. The method of deriving parameters of EIP models is further described in Section I.E. One or more block vectors are derived / selected for the current block to locate the reference blocks, and the one or more block vectors are the first target block vectors and can be referenced by subsequent blocks.

[0082] For a second example, in some embodiments, the coding information is intra prediction modes derived based on samples in the reference blocks. The method of deriving intra modes can be a DIMD process computing HoG based on the samples in the reference block as described in Section I.F. One or more block vectors are derived / selected for the current block to locate the reference blocks, and the one or more block vectors are the first target block vectors and can be referenced by subsequent blocks.

[0083] For a third example, in some embodiments, the is cross-component models derived based on samples in the reference blocks. The cross-component model can be CCLM, GLM, multi-model cross-component model, CCCM and CCCM variants (such as with different filter shape, non-downsampled inputs, multiple downsampling filters, using location or gradient term as inputs) . If CCCM is to be derived, the method of deriving parameters of CCCM can be as described in Section I.G. One or more block vectors are derived / selected for the current block to locate the reference blocks, and the one or more block vectors are the first target block vectors and can be referenced by subsequent blocks.

[0084] In some embodiments, when coding the current block, one or more block vectors are derived / selected for the current block. BV-based predictors are generated based on sample values of the reference blocks located by the one or more block vectors of the current block, and the final predictor of the current block is a combination of BV-based predictors and other BV-based / non-BV-based predictors. The one or more block vectors derived / selected for the current block can be the first target block vectors and can be referenced by subsequent blocks. The following are examples of final predictor generated based on BV-based predictors:

[0085] For a first example, in some embodiments, the final predictor can be a combination of intra directional mode predictors and BV-based predictor. The BV-based predictors are generated based on the sample values of reference blocks. One or more block vectors are derived / selected for the current block to locate the reference blocks, and the one or more block vectors are the first target block vectors and can be referenced by subsequent blocks. Take DIMD as example, as described in Section I.F, the final predictor is a combination of intra directional mode predictors and BV-based predictor, if a block vector candidate is selected as the non-directional mode.

[0086] For a second example, in some embodiments, the current block can be partitioned geometrically, and at least the final predictor of one of the partitions is a BV-based predictor. One or more block vectors are derived / selected for the partition with the BV-based predictor, and the one or more block vectors are the first target block vectors and can be referenced by subsequent blocks. Take SGPM as example, as described in Section I.H, the IPM list of each partition mode comprises block-vector candidates. The final predictor of a partition can be a BV-based predictor if a block vector candidate is selected from the IPM list.

[0087] In some embodiment, when coding the current block, one or more block vectors are derived / selected for the current block. Prediction of the current block is generated based on the sample values in reference blocks located by one or more block vectors of the current block. The one or more block vectors derived / selected for the current block can be the first target block vectors and can be referenced by subsequent blocks. For example, the current block may be a chroma block, and one or more block vectors are derived / selected for the current chroma block. The prediction of the current chroma block is generated based on the sample values of reference blocks located by the one or more block vector of the current chroma block. Method of generating the current prediction are further described in Section I.D. The one or more block vectors derived / selected for the current block can be the first target block vectors and can be referenced by subsequent blocks.

[0088] In some embodiments, the method of deriving / selecting one or more block vectors can be the same as IBC or IntraTMP, which are further described in Section I. A and Section I.C respectively. The one or more block vectors derived / selected for the current block can be the first target block vectors and can be referenced by subsequent blocks.

[0089] B. Deriving merge candidates based on cascaded vectors

[0090] Some embodiments of the disclosure provide methods of deriving merge candidates based on one or more second target block vectors. For some embodiments, a merge candidate list having inheritance information retrieved from previous coded blocks, located based on derived or pre-defined neighboring positions, is constructed for the current block. The inheritance information from one or more previous coded blocks may be selected from the merge candidate list. The prediction of the current block may then be generated based on the selected inheritance information.

[0091] In some embodiments, the inheritance information can be block vectors, motion vectors, intra directional / non-directional modes, cross-component models, extrapolated filter-based intra prediction model (e.g., EIP) , fusion weights, reference lines, sample values. The inheritance information may be associated with a coding mode. The prediction of the current block is then generated based on the inheritance information based on the coding mode. For example, for CCP merge mode, the inheritance information is the cross-component model. If the inheritance information is associated with CCCM mode, the prediction of the current block is generated based on the inherited cross-component model based on CCCM mode. For example, for IBC merge mode, the inheritance information is the block vectors. The prediction of the current block is generated based on the inherited block vectors based on IBC mode. For example, if the inheritance information is intra modes with fusion weights and block vectors, and the inheritance information is associated with DIMD / TIMD mode, the prediction of the current block is generated based on the inheritance information based on DIMD / TIMD mode. For another example, if the inheritance information is intra modes and reference line, and the inheritance information is associated with template-based multiple reference line intra prediction (TMRL) mode, the prediction of the current block is generated based on the inheritance information based on TMRL mode. For another example, if the inheritance information is EIP model associated with EIP mode, the prediction of the current block is generated based on the inheritance information based on EIP mode.

[0092] In some embodiments, the derived neighboring positions used to locate previous coded blocks and retrieve inheritance information are derived based on cascaded vectors. Cascaded vectors are derived as the sum of the recursively traced second target block vectors and / or motion vectors based on a guiding vector. A guiding vector can be a motion vector or a block vector. The inheritance information from blocks at the neighboring positions derived from the cascaded vectors are added into the merge candidate list.

[0093] FIG. 10 illustrates a merge scheme in which a merge mode candidate list is constructed based on cascaded vectors that are recursively traced BVs or MVs starting from a guiding vector. The guiding vector is a MV or BV. A merge candidate list 1050 is to be constructed for coding a current block 1010 based on cascaded vectors CV (0) , CV (1) , CV (2) , CV (3) , and CV (4) .

[0094] As illustrated, the first step of the recursion for the cascaded vectors starts (Step ‘A’ ) from a guiding vector 1005, which may be a BV of the current block 1010 and therefore a “first target block vector” of the current block. (The guiding vector may also be a MV of the current block 1010. ) For each recursion (i-th recursion) , the video coder locates (Step ‘B1’ ) a reference block based on a cascaded vector CV (i-1) and retrieves (Step ‘B2’ ) a vector from the reference block. This vector, denoted as V (i) , can be an L0 motion vector, an L1 motion vector, or a second target block vector. (For the initial or 0-th recursion, CV (0) is the guiding vector 1005. ) The video coder then derives (Step ‘B3’ ) one cascaded vector as CV (i) = CV (i-1) + V (i) = CV (0) + V (1) + V (2) + …+ V (i) . Steps B1-B3 are repeated for each recursion.

[0095] In the example of FIG. 10, for the first recursion, a BV of a reference block 1011 (ref blk A) is used as V (1) to created cascaded vector CV (1) =CV (0) +V (1) and locates a reference block 1012 (ref blk B) . For the third recursion, a MV of a reference block 1020 (ref blk C) is used as V (3) to create cascaded vector CV (3) =CV (2) +V (3) =CV (0) +V (1) +V (2) +V (3) and locates a reference block 1030 (ref blk D) .

[0096] When constructing the merge candidate list 1050 for the current block 1010, the cascaded vectors CV (0) , CV (1) , ..... are used to derive “neighboring positions” . The derived neighboring positions, used to locate previous coded blocks and retrieve inheritance information for the merge mode, are the sum of the current block position and cascaded vectors. Thus, the “derived neighboring positions” may not necessarily spatially neighbor the current block or be in the current picture. Rather, the “derived neighboring positions” refer to positions that are used to provide merge candidates, therefore may also be referred to as “derived merge candidate positions” . In the example of FIG. 10, the “derived neighboring positions” or the “derived merge candidate positions” for the merge candidate list 1050 correspond to positions identified by cascaded vectors CV (0) , CV (1) , CV (2) , CV (3) , and CV (4) . They are added to the merge candidate list 1050 as candidates and respectively used to retrieve samples of reference blocks A, B, C, D, and E as inheritance information.

[0097] When the reference block has a first target block vectors, the first target block vectors can be used as a second target block vectors. For example, the reference block 1011 has a BV as V (1) . V (1) can be considered as a “first target block vector” of the reference block 1011 and as a “second target block vector” of the current block 1010.

[0098] For example, in some embodiments, AR-BVP, derived based on cascaded vectors, may be used to provide merge candidates for IBC merge mode candidate list. The guiding vector CV (0) may be a BV already exists in the IBC merge candidate list. When creating AR-BVP candidates, a block vector retrieved from a reference block may be a second target block vector of the current block. Generally, when a reference block has its own “first target block vectors” , the first target block vectors may be used as the “second target block vectors” for the current block. The second target block vectors are recursively summed to derive cascaded vectors. The derived neighboring positions are the sum of the current block position and cascaded vectors (CV (0) , CV (1) , ..... ) . The cascaded vectors (i.e., AR-BVP) are added into the IBC merge candidate list. In other words, the inheritance information (sample values) of the further reference block (s) at the derived neighboring position (s) is / are added into the IBC merge candidate list in the form of AR-BVP.

[0099] For another example, in some embodiments, AR-BVP, derived based on cascaded vectors, may be used to provide merge candidates for IntraTMP mode merge list. The guiding vector CV (0) is a BV. When creating AR-BVP candidates in step B2, the vector retrieved from the reference block may be a second target block vector for the current block. When the reference block has its own “first target block vectors” , the first target block vectors can be used as the second target block vectors of the current block. The second target block vectors may be recursively summed to derive cascaded vectors. The derived neighboring positions are the sum of the current block position and cascaded vectors (CV (0) , CV (1) , ..... ) . The cascaded vectors (i.e., AR-BVP) are added into the IntraTMP merge candidate list. In other words, the inheritance information (sample values) of the further reference block (s) at the derived neighboring position (s) is / are added into the IntraTMP merge candidate list in the form of AR-BVP.

[0100] For another example, in some embodiments, CMVP, derived based on cascaded vectors, may be used to provide merge candidates for regular inter merge mode. The guiding vector CV (0) is a MV that exists in the inter merge candidate list. When creating CMVP candidates in step B2, the vector retrieved from the reference block may be an L0 / L1 motion vector or a second target block vector. When the reference block has its own “first target block vectors” , the first target block vectors can be used as “second target block vectors” of the current block. The second target block vectors may be recursively summed with L0 / L1 motion vectors to derive cascaded vectors. The derived neighboring positions are the sum of the current block position and cascaded vectors (CV (0) , CV (1) , …) . The cascaded vectors (i.e., CMVP) are added into the inter merge candidate list. In other words, the inheritance information (sample values) of the further reference block (s) at the derived neighboring position (s) is / are added into the inter merge candidate list in the form of CMVP.

[0101] In some embodiments, a previously coded block at a pre-defined neighboring position may be referenced from a merge candidate list to retrieve inheritance information for merge candidate list construction. Specifically, if the previously coded block has a “first target block vector” , then cascaded vectors (CV (0) , CV (1) , ..... ) can be derived based on the “first target block vector” as the guiding vector to locate derived neighboring positions or derived merge candidate positions. The inheritance information from blocks at the derived neighboring positions located by the cascaded vectors may be added to the merge candidate list.

[0102] FIG. 11 conceptually illustrates a merge scheme in which a merge mode candidate list is constructed based on cascaded vectors starting from a guiding vector that is provided by a previously coded block at a predefined neighboring position. A merge candidate list 1150 is to be constructed for coding a current block 1110 based on cascaded vectors CV (0) , CV (1) , CV (2) , and CV (3) . The cascaded vectors are recursively traced BVs or MVs starting from a guiding vector 1105, which may be a “first target block vector” or a MV of a previously coded block 1111 at a predefined neighboring position of the current block 1110. The pre-defined position can be a spatial candidate, temporal candidate or history candidate of the current block 1110 in the merge candidate list 1150.

[0103] As illustrated, the first step of the recursion for the cascaded vectors starts (Step ‘A’ ) from a guiding vector 1105, which is a BV of the previously coded block 1111 and therefore a “second target block vector” of the current block 1110. (The guiding vector may also be a MV of the previously coded block 1111. ) For each recursion (i-th recursion) , the video coder locates (Step ‘B1’ ) a reference block based on a cascaded vector CV (i-1) and retrieves (Step ‘B2’ ) a vector V (i) from the reference block. For the initial or 0-th recursion, CV (0) is the guiding vector 1105. The video coder then derives (Step ‘B3’ ) one cascaded vector as CV (i) = CV (i-1) + V (i) = CV (0) + V (1) + V (2) + …+ V (i) . Steps B1-B3 are repeated for each recursion. In the example of FIG. 11, for the first recursion, a MV of a reference block 1112 (ref blk B) is used as V (1) to created cascaded vector CV (1) =CV (0) +V (1) and locates a reference block 1113 (ref blk C) . For the third recursion, a BV of a reference block 1130 (ref blk D) is used as V (3) to create cascaded vector CV (3) =CV (2) +V (3) =CV (0) +V (1) +V (2) +V (3) and locates a reference block 1131 (ref blk E) .

[0104] When constructing the merge candidate list 1150 for the current block 1110, the cascaded vectors CV (0) , CV (1) , ..... are used to determine the “derived neighboring positions” or the “derived merge candidate positions” . The derived neighboring positions, used to locate previous coded blocks and retrieve inheritance information for the merge mode, are the sum of the current block position and cascaded vectors. In the example of FIG. 11, the “derived neighboring positions” or the “derived merge candidate positions” correspond to positions identified by cascaded vectors CV (0) , CV (1) , CV (2) , and CV (3) . They are added to the merge candidate list 1150 as candidates and respectively used to retrieve samples of the reference blocks B, C, D, and E as inheritance information. The samples of the previously coded block 1111 at the predefined position is already in the merge candidate list 1150.

[0105] For example, in some embodiments, when using CCP merge mode for coding the current block (that may be coded by intra / inter / IBC) , a previously coded block at a pre-defined neighboring position may be referenced from the merge list to retrieve cross-component model information and for merge candidate list construction. Specifically, if the previously coded block has its own “first target block vector” , cascaded vectors can be derived using that first target block vector as the guiding vector. The cross-component model information from blocks at the derived neighboring positions (based on the derived cascaded vectors) may be added into the merge candidate list. When deriving the cascaded vectors in step B2, the vector retrieved from the reference block may be an L0 / L1 motion vector or a second target block vector. The cross-component model of the further reference blocks located at the derived neighboring positions can be propagated to and stored in the previous coded block. The cascaded vectors include CV (0) , which is the “first target block vector” of the previously coded block. The previously coded block may be the collocated luma block of the current block, hence CV (0) is the motion vector or the BV of the collocated luma block.

[0106] For another example, in some embodiments, when using EIP merge mode for coding the current block, a previously coded block at a pre-defined neighboring position may be referenced from the merge list to retrieve EIP information and for merge candidate list construction. Specifically, if the previously coded block has a first target block vector, cascaded vectors can be derived using the first target block vector as the guiding vector. The EIP information from blocks at the derived neighboring positions (based on the derived cascaded vectors) may be added to the merge candidate list. When deriving cascaded vectors, in step B2, the vector retrieved from the reference block be an L0 / L1 motion vector or a second target block vector. The EIP model of the further reference blocks located at the derived neighboring positions can be propagated to and stored in the previous coded block. The EIP models of the further reference blocks located at the derived neighboring positions can be added to the EIP merge candidate list of the current block. The cascaded vectors may include CV (0) , which is the first target block vector of the previously coded block.

[0107] For another example, in some embodiments, the current block may be coded by using a merge scheme, and the inheritance information may be intra directional / non-directional modes, fusion weight, reference lines, and the coding mode may be DIMD, TIMD or MRL. If the previously coded block (referenced from the merge candidate list) has a first target block vector, cascaded vectors can be derived using the first target block vector as the guiding vector. The inheritance information from blocks at the derived neighboring positions (derived from the cascaded vectors) can be added into the merge candidate list. When deriving the cascaded vectors, in step B2, the vector retrieved from the reference block may be an L0 / L1 motion vector or a second target block vector. The inheritance information of the further reference blocks located at the derived neighboring positions may be propagated to and stored in the previous coded block. The inheritance information of the further reference blocks located at the derived neighboring positions can be added into the merge candidate list of the current block. The cascaded vectors may include CV (0) , which is the first target block vector of the previously coded block (referenced from the merge candidate list. )

[0108] The term “block” in this disclosure may refer to TU / TB, CU / CB, PU / PB, pre-defined region, or CTU / CTB. Any combination of the proposed methods in this invention can be applied. Any of the foregoing proposed methods can be implemented in encoders and / or decoders. For example, any of the proposed methods can be implemented in an inter / intra / IBC / prediction / transform module of an encoder, and / or an inter / intra / IBC / prediction / transform module of a decoder. Alternatively, any of the proposed methods can be implemented as a circuit coupled to the inter / intra / IBC / prediction / transform module of the encoder and / or the inter / intra / IBC / prediction / transform module of the decoder, so to provide the information needed by the inter / intra / IBC / prediction / transform module. IV. Example Video Encoder

[0109] FIG. 12 illustrates an example video encoder 1200 that may implement merge mode prediction. As illustrated, the video encoder 1200 receives input video signal from a video source 1205 and encodes the signal into bitstream 1295. The video encoder 1200 has several components or modules for encoding the signal from the video source 1205, at least including some components selected from a transform module 1210, a quantization module 1211, an inverse quantization module 1214, an inverse transform module 1215, an intra estimation module 1224, an intra prediction module 1225, a motion compensation module 1230, a motion estimation module 1235, an in-loop filter 1245, a reconstructed picture buffer 1250, a MV buffer 1265, and a MV prediction module 1275, and an entropy encoder 1290. The motion compensation module 1230 and the motion estimation module 1235 are part of an inter-prediction module 1240. The intra-prediction module 1225 and the intra-estimation module 1224 are part of a current picture prediction module 1220, which uses current picture reconstructed samples as reference samples for prediction of the current block.

[0110] In some embodiments, the modules 1210 –1290 are modules of software instructions being executed by one or more processing units (e.g., a processor) of a computing device or electronic apparatus. In some embodiments, the modules 1210 –1290 are modules of hardware circuits implemented by one or more integrated circuits (ICs) of an electronic apparatus. Though the modules 1210 –1290 are illustrated as being separate modules, some of the modules can be combined into a single module.

[0111] The video source 1205 provides a raw video signal that presents pixel data of each video frame without compression. A subtractor 1208 computes the difference between the raw video pixel data of the video source 1205 and the predicted pixel data 1213 from the motion compensation module 1230 or intra-prediction module 1225 as prediction residual 1209. The transform module 1210 converts the difference (or the residual pixel data or residual signal 1208) into transform coefficients (e.g., by performing Discrete Cosine Transform, or DCT) . The quantization module 1211 quantizes the transform coefficients into quantized data (or quantized coefficients) 1212, which is encoded into the bitstream 1295 by the entropy encoder 1290.

[0112] The inverse quantization module 1214 de-quantizes the quantized data (or quantized coefficients) 1212 to obtain transform coefficients 1218, and the inverse transform module 1215 performs inverse transform on the transform coefficients 1218 to produce reconstructed residual 1219. The reconstructed residual 1219 is added with the predicted pixel data 1213 to produce reconstructed pixel data 1217. In some embodiments, the reconstructed pixel data 1217 is temporarily stored in a line buffer 1227 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction. The reconstructed pixels are filtered by the in-loop filter 1245 and stored in the reconstructed picture buffer 1250. In some embodiments, the reconstructed picture buffer 1250 is a storage external to the video encoder 1200. In some embodiments, the reconstructed picture buffer 1250 is a storage internal to the video encoder 1200.

[0113] The intra estimation module 1224 derives intra-prediction data (e.g., intra prediction modes) based on the reconstructed pixel data 1217 (stored in the line buffer 1227) . The intra-prediction data is provided to the entropy encoder 1290 to be encoded into bitstream 1295. The intra-prediction data is also used by the intra-prediction module 1225 to produce the predicted pixel data 1213.

[0114] The motion estimation module 1235 performs inter-prediction by producing MVs to reference pixel data of previously decoded frames stored in the reconstructed picture buffer 1250. These MVs are provided to the motion compensation module 1230 to produce predicted pixel data.

[0115] Instead of encoding the complete actual MVs in the bitstream, the video encoder 1200 uses MV prediction to generate predicted MVs, and the difference between the MVs used for motion compensation and the predicted MVs is encoded as residual motion data and stored in the bitstream 1295.

[0116] The MV prediction module 1275 generates the predicted MVs based on reference MVs that were generated for encoding previously video frames, i.e., the motion compensation MVs that were used to perform motion compensation. The MV prediction module 1275 retrieves reference MVs from previous video frames from the MV buffer 1265. The video encoder 1200 stores the MVs generated for the current video frame in the MV buffer 1265 as reference MVs for generating predicted MVs.

[0117] The MV prediction module 1275 uses the reference MVs to create the predicted MVs. The predicted MVs can be computed by spatial MV prediction or temporal MV prediction. The difference between the predicted MVs and the motion compensation MVs (MC MVs) of the current frame (residual motion data) are encoded into the bitstream 1295 by the entropy encoder 1290.

[0118] The entropy encoder 1290 encodes various parameters and data into the bitstream 1295 by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding. The entropy encoder 1290 encodes various header elements, flags, along with the quantized transform coefficients 1212, and the residual motion data as syntax elements into the bitstream 1295. The bitstream 1295 is in turn stored in a storage device or transmitted to a decoder over a communications medium such as a network.

[0119] The in-loop filter 1245 performs filtering or smoothing operations on the reconstructed pixel data 1217 to reduce the artifacts of coding, particularly at boundaries of pixel blocks. In some embodiments, the filtering or smoothing operations performed by the in-loop filter 1245 include deblock filter (DBF) , sample adaptive offset (SAO) , and / or adaptive loop filter (ALF) . In some embodiments, luma mapping chroma scaling (LMCS) is performed before the loop filters.

[0120] FIG. 13 illustrates portions of the video encoder 1200 that implement merge mode prediction based on cascaded vectors. As illustrated, a vector cascading module 1310 may receive a BV or MV as guiding vector 1315 or CV (0) from the current picture prediction module 1220 or the inter prediction module 1240. The guiding vector 1315 may also be provided by an existing candidate associated with a predefined position for the current block in a merge candidate list 1320. Such a candidate may provide inheritance information of a previously coded block at the predefined neighboring position. Based on the guiding vector 1315, the vector cascading module 1310 may create cascaded vectors CV (1) , CV (2) , CV (3) , …by accumulation of recursively traced MVs and / or BVs that are retrieved from the MV buffer 1265 or a BV buffer 1365. Each recursively traced MV or BV indicates a reference block, which provide MVs or BVs to be further recursively traced and cascaded. Cascaded vectors are described by reference to FIGS. 10 and 11 in Section III. B above.

[0121] The cascaded vectors created by the vector cascading module 1310 are provided to the merge candidate list 1320 for adding candidates to the list. Each cascaded vector is used to derive a neighboring position or a merge candidate position for the merge candidate list 1320. The reference block located at each merge candidate position is used to provide the inheritance information of that merge candidate. The inheritance information may include any of the following: block vectors, motion vectors, intra directional modes, non-directional modes, cross-component models, extrapolated filter-based intra prediction models, fusion weights, reference lines, or sample values of pixels. Sample values of pixels may be provided by the reconstructed picture buffer 1250 or the line buffer 1227. A merge candidate selection module 1330 selects a merge candidate 1335 from the merge candidate list 1320 according to a merge index. The merge index may be signaled by the entropy encoder 1290. (The merge candidate 1335 may also be selected implicitly) The inheritance information of the selected candidate 1335 is retrieved from an inheritance information storage 1325.

[0122] A prediction generator module 1340 uses the inheritance information of the selected candidate 1335 to generate a predictor 1345 of the current block. The predictor is to provide the predicted pixel data 1213. The predictor generator module 1340 may also use newly derived information 1355 for the current block to generate the predictor 1345. The newly derived information may be prediction models 1350 (e.g., CCP, EIP, LIC, etc. ) , MVs and / or BVs used for encoding the current block, or other prediction information such as intra prediction modes and fusion weights generated for other coding tools such as DIMD or TIMD. The newly derived information 1355 that are used for the current block are then stored in the inheritance information storage 1325 to be used as inheritance information for subsequent blocks.

[0123] FIG. 14 conceptually illustrates a process 1400 for encoding a pixel block by using merge candidate list constructed based on cascaded vectors. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the encoder 1200 performs the process 1400 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the encoder 1200 performs the process 1400.

[0124] The encoder receives (at block 1410) data to be encoded as a current block of pixels in a current picture. The encoder derives (at block 1420) one or more cascaded vectors by recursively tracing block vectors or motion vectors starting from a guiding vector. The guiding vector may be a block vector or motion vector provided by a prediction mode of the current block (e.g., IBC, IntraTMP, regular Inter, etc. ) . The guiding vector may be a block vector or a motion vector provided by a previously coded block at a neighboring position relative to the current block. The neighboring position may be a candidate in the merge candidate list.

[0125] In some embodiments, at least one target block vector among the recursively traced block vectors or motion vectors is derived from a target reference block located corresponding to the guiding vector or the one or more cascaded vectors. The target reference block located corresponding to the guiding vector may be coded in block vector guided extrapolated intra prediction (BVG-EIP) , block vector guided convolutional cross-component model (BVG-CCCM) , block vector guided decoder-side intra mode derivation (BVG-DIMD) , decoder-side intra mode derivation (DIMD) , spatial geometric partition mode (SGPM) , direct block vector (DBV) , intra block copy (IBC) , or intra template matching prediction (IntraTMP) . The block vector provided by a prediction mode of the target reference block may be referred to as a “first target block vector” of the target reference block, and used as the “second target block vector” of the current block in cascaded vector derivation.

[0126] Prediction of the target reference block may be generated based on (i) coding information derived based on samples in one or more further reference blocks referenced by the target reference block based on the at least one target block vector, or (ii) sample values in one or more further reference blocks referenced by the target reference block based on the at least one target block vector.

[0127] The encoder constructs (at block 1430) a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors. Each candidate providing inheritance information associated with a reference block located at the candidate’s corresponding derived merge candidate position. The merge candidate list may be used for any one of regular inter merge mode, intraTMP merge mode, IBC merge mode, CCP merge mode, and EIP merge mode. The inheritance information provided by a candidate may include sample values of a reference block, or a cross-component model, or an extrapolated filter-based intra prediction model, or a block vector, a motion vector, an intra directional mode, a non-directional mode, a fusion weight, a set of reference lines, and a set of sample values. Using cascaded vectors to construct merge mode candidate list is described by reference to FIGS. 10 and 11 in Section III. B above.

[0128] The encoder selects (at block 1440) a candidate from the merge candidate list. The encoder generates (at block 1450) a predictor of the current block based on the inheritance information provided by the selected candidate. The encoder encodes (at block 1460) the current block by using the generated predictor to produce prediction residuals. V. Example Video Decoder

[0129] In some embodiments, an encoder may signal (or generate) one or more syntax element in a bitstream, such that a decoder may parse said one or more syntax element from the bitstream.

[0130] FIG. 15 illustrates an example video decoder 1500 that may implement merge mode prediction. As illustrated, the video decoder 1500 is an image-decoding or video-decoding circuit that receives a bitstream 1595 and decodes the content of the bitstream into pixel data of video frames for display. The video decoder 1500 has several components or modules for decoding the bitstream 1595, including some components selected from an inverse quantization module 1514, an inverse transform module 1515, an intra-prediction module 1525, a motion compensation module 1530, an in-loop filter 1545, a decoded picture buffer 1550, a MV buffer 1565, a MV prediction module 1575, and a parser 1590. The motion compensation module 1530 is part of an inter-prediction module 1540. The intra-prediction module 1525 is part of a current picture prediction module 1520, which uses current picture reconstructed samples as reference samples for prediction of the current block.

[0131] In some embodiments, the modules 1514 –1590 are modules of software instructions being executed by one or more processing units (e.g., a processor) of a computing device. In some embodiments, the modules 1514 –1590 are modules of hardware circuits implemented by one or more ICs of an electronic apparatus. Though the modules 1514 –1590 are illustrated as being separate modules, some of the modules can be combined into a single module.

[0132] The parser 1590 (or entropy decoder) receives the bitstream 1595 and performs initial parsing according to the syntax defined by a video-coding or image-coding standard. The parsed syntax element includes various header elements, flags, as well as quantized data (or quantized coefficients) 1512. The parser 1590 parses out the various syntax elements by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding.

[0133] The inverse quantization module 1514 de-quantizes the quantized data (or quantized coefficients) 1512 to obtain transform coefficients, and the inverse transform module 1515 performs inverse transform on the transform coefficients 1518 to produce reconstructed residual signal 1519. The reconstructed residual signal 1519 is added with predicted pixel data 1513 from the intra-prediction module 1525 or the motion compensation module 1530 to produce decoded pixel data 1517. The decoded pixels data are filtered by the in-loop filter 1545 and stored in the decoded picture buffer 1550. In some embodiments, the decoded picture buffer 1550 is a storage external to the video decoder 1500. In some embodiments, the decoded picture buffer 1550 is a storage internal to the video decoder 1500.

[0134] The intra-prediction module 1525 receives intra-prediction data from bitstream 1595 and according to which, produces the predicted pixel data 1513 from the decoded pixel data 1517 stored in the decoded picture buffer 1550. In some embodiments, the decoded pixel data 1517 is also stored in a line buffer 1527 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction.

[0135] In some embodiments, the content of the decoded picture buffer 1550 is used for display. A display device 1505 either retrieves the content of the decoded picture buffer 1550 for display directly, or retrieves the content of the decoded picture buffer to a display buffer. In some embodiments, the display device receives pixel values from the decoded picture buffer 1550 through a pixel transport.

[0136] The motion compensation module 1530 produces predicted pixel data 1513 from the decoded pixel data 1517 stored in the decoded picture buffer 1550 according to motion compensation MVs (MC MVs) . These motion compensation MVs are decoded by adding the residual motion data received from the bitstream 1595 with predicted MVs received from the MV prediction module 1575.

[0137] The MV prediction module 1575 generates the predicted MVs based on reference MVs that were generated for decoding previous video frames, e.g., the motion compensation MVs that were used to perform motion compensation. The MV prediction module 1575 retrieves the reference MVs of previous video frames from the MV buffer 1565. The video decoder 1500 stores the motion compensation MVs generated for decoding the current video frame in the MV buffer 1565 as reference MVs for producing predicted MVs.

[0138] The in-loop filter 1545 performs filtering or smoothing operations on the decoded pixel data 1517 to reduce the artifacts of coding, particularly at boundaries of pixel blocks. In some embodiments, the filtering or smoothing operations performed by the in-loop filter 1545 include deblock filter (DBF) , sample adaptive offset (SAO) , and / or adaptive loop filter (ALF) . In some embodiments, luma mapping chroma scaling (LMCS) is performed before the loop filters.

[0139] FIG. 16 illustrates portions of the video decoder 1500 that implement merge mode prediction based on cascaded vectors. As illustrated, a vector cascading module 1610 may receive a BV or MV as guiding vector 1615 or CV (0) from the entropy decoder 1590. The guiding vector 1615 may also be provided by an existing candidate associated with a predefined position for the current block in a merge candidate list 1620. Such a candidate may provide inheritance information of a previously coded block at the predefined neighboring position. Based on the guiding vector 1615, the vector cascading module 1610 may create cascaded vectors CV (1) , CV (2) , CV (3) , …by accumulation of recursively traced MVs and / or BVs that are retrieved from the MV buffer 1565 or a BV buffer 1665. Each recursively traced MV or BV indicates a reference block, which provide MVs or BVs to be further recursively traced and cascaded. Cascaded vectors are described by reference to FIGS. 10 and 11 in Section III. B above.

[0140] The cascaded vectors created by the vector cascading module 1610 are provided to the merge candidate list 1620 for adding candidates to the list. Each cascaded vector is used to derive a neighboring position or a merge candidate position for the merge candidate list 1620. The reference block located at each merge candidate position is used to provide the inheritance information of that merge candidate. The inheritance information may include any of the following: block vectors, motion vectors, intra directional modes, non-directional modes, cross-component models, extrapolated filter-based intra prediction models, fusion weights, reference lines, or sample values of pixels. Sample values of pixels may be provided by the decoded picture buffer 1550 or the line buffer 1527. A merge candidate selection module 1630 selects a merge candidate 1635 from the merge candidate list 1620 according to a merge index. The merge index may be provided by the entropy decoder 1590 from the bitstream 1595 (The merge index may also be determined implicitly) . The inheritance information of the selected candidate 1635 is retrieved from an inheritance information storage 1625.

[0141] A prediction generator module 1640 uses the inheritance information of the selected candidate 1635 to generate a predictor 1645 of the current block. The predictor is to provide the predicted pixel data 1513. The predictor generator module 1640 may also use newly derived information 1655 for the current block to generate the predictor 1645. The newly derived information may be prediction models 1650 (e.g., CCP, EIP, LIC, etc. ) , MVs and / or BVs used for decoding the current block, or other prediction information such as intra prediction modes and fusion weights generated for other coding tools such as DIMD or TIMD. The newly derived information 1655 that are used for the current block are then stored in the inheritance information storage 1625 to be used as inheritance information for subsequent blocks.

[0142] FIG. 17 conceptually illustrates a process 1700 for decoding a pixel block by using merge candidate list constructed based on cascaded vectors. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the decoder 1500 performs the process 1700 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the decoder 1500 performs the process 1700.

[0143] The decoder receives (at block 1710) data to be decoded as a current block of pixels in a current picture. The decoder derives (at block 1720) one or more cascaded vectors by recursively tracing block vectors or motion vectors starting from a guiding vector. The guiding vector may be a block vector or motion vector provided by a prediction mode of the current block (e.g., IBC, IntraTMP, regular Inter, etc. ) . The guiding vector may be a block vector or a motion vector provided by a previously coded block at a neighboring position relative to the current block. The neighboring position may be a candidate in the merge candidate list.

[0144] In some embodiments, at least one target block vector among the recursively traced block vectors or motion vectors is derived from a target reference block located corresponding to the guiding vector or the one or more cascaded vectors. The target reference block located corresponding to the guiding vector may be coded in block vector guided extrapolated intra prediction (BVG-EIP) , block vector guided convolutional cross-component model (BVG-CCCM) , block vector guided decoder-side intra mode derivation (BVG-DIMD) , decoder-side intra mode derivation (DIMD) , spatial geometric partition mode (SGPM) , direct block vector (DBV) , intra block copy (IBC) , or intra template matching prediction (IntraTMP) . The block vector provided by a prediction mode of the target reference block may be referred to as a “first target block vector” of the target reference block, and used as the “second target block vector” of the current block in cascaded vector derivation.

[0145] Prediction of the target reference block may be generated based on (i) coding information derived based on samples in one or more further reference blocks referenced by the target reference block based on the at least one target block vector, or (ii) sample values in one or more further reference blocks referenced by the target reference block based on the at least one target block vector.

[0146] The decoder constructs (at block 1730) a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors. Each candidate providing inheritance information associated with a reference block located at the candidate’s corresponding derived merge candidate position. The merge candidate list may be used for any one of regular inter merge mode, intraTMP merge mode, IBC merge mode, CCP merge mode, and EIP merge mode. The inheritance information provided by a candidate may include sample values of a reference block, or a cross-component model, or an extrapolated filter-based intra prediction model, or a block vector, a motion vector, an intra directional mode, a non-directional mode, a fusion weight, a set of reference lines, and a set of sample values. Using cascaded vectors to construct merge mode candidate list is described by reference to FIGS. 10 and 11 in Section III. B above.

[0147] The decoder selects (at block 1740) a candidate from the merge candidate list. The decoder generates (at block 1750) a predictor of the current block based on the inheritance information provided by the selected candidate. The decoder reconstructs (at block 1760) the current block by using the generated predictor to produce prediction residuals. The reconstructed current block may then be outputted or displayed as part of the reconstructed current picture. VI. Example Electronic System

[0148] Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium) . When these instructions are executed by one or more computational or processing unit (s) (e.g., one or more processors, cores of processors, or other processing units) , they cause the processing unit (s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, random-access memory (RAM) chips, hard drives, erasable programmable read only memories (EPROMs) , electrically erasable programmable read-only memories (EEPROMs) , etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0149] In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the present disclosure. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

[0150] FIG. 18 conceptually illustrates an electronic system 1800 with which some embodiments of the present disclosure are implemented. The electronic system 1800 may be a computer (e.g., a desktop computer, personal computer, tablet computer, etc. ) , phone, PDA, or any other sort of electronic device. Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media. Electronic system 1800 includes a bus 1805, processing unit (s) 1810, a graphics-processing unit (GPU) 1815, a system memory 1820, a network 1825, a read-only memory 1830, a permanent storage device 1835, input devices 1840, and output devices 1845.

[0151] The bus 1805 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 1800. For instance, the bus 1805 communicatively connects the processing unit (s) 1810 with the GPU 1815, the read-only memory 1830, the system memory 1820, and the permanent storage device 1835.

[0152] From these various memory units, the processing unit (s) 1810 retrieves instructions to execute and data to process in order to execute the processes of the present disclosure. The processing unit (s) may be a single processor or a multi-core processor in different embodiments. Some instructions are passed to and executed by the GPU 1815. The GPU 1815 can offload various computations or complement the image processing provided by the processing unit (s) 1810.

[0153] The read-only-memory (ROM) 1830 stores static data and instructions that are used by the processing unit (s) 1810 and other modules of the electronic system. The permanent storage device 1835, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 1800 is off. Some embodiments of the present disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1835.

[0154] Other embodiments use a removable storage device (such as a floppy disk, flash memory device, etc., and its corresponding disk drive) as the permanent storage device. Like the permanent storage device 1835, the system memory 1820 is a read-and-write memory device. However, unlike storage device 1835, the system memory 1820 is a volatile read-and-write memory, such a random access memory. The system memory 1820 stores some of the instructions and data that the processor uses at runtime. In some embodiments, processes in accordance with the present disclosure are stored in the system memory 1820, the permanent storage device 1835, and / or the read-only memory 1830. For example, the various memory units include instructions for processing multimedia clips in accordance with some embodiments. From these various memory units, the processing unit (s) 1810 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[0155] The bus 1805 also connects to the input and output devices 1840 and 1845. The input devices 1840 enable the user to communicate information and select commands to the electronic system. The input devices 1840 include alphanumeric keyboards and pointing devices (also called “cursor control devices” ) , cameras (e.g., webcams) , microphones or similar devices for receiving voice commands, etc. The output devices 1845 display images generated by the electronic system or otherwise output data. The output devices 1845 include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD) , as well as speakers or similar audio output devices. Some embodiments include devices such as a touchscreen that function as both input and output devices.

[0156] Finally, as shown in FIG. 18, bus 1805 also couples electronic system 1800 to a network 1825 through a network adapter (not shown) . In this manner, the computer can be a part of a network of computers (such as a local area network ( “LAN” ) , a wide area network (“WAN” ) , or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system 1800 may be used in conjunction with the present disclosure.

[0157] Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media) . Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM) , recordable compact discs (CD-R) , rewritable compact discs (CD-RW) , read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM) , a variety of recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc. ) , flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc. ) , magnetic and / or solid state hard drives, read-only and recordable discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0158] While the above discussion primarily refers to microprocessor or multi-core processors that execute software, many of the above-described features and applications are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) . In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself. In addition, some embodiments execute software stored in programmable logic devices (PLDs) , ROM, or RAM devices.

[0159] As used in this specification and any claims of this application, the terms “computer” , “server” , “processor” , and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium, ” “computer readable media, ” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0160] While the present disclosure has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the present disclosure can be embodied in other specific forms without departing from the spirit of the present disclosure. In addition, a number of the figures (including FIG. 14 and FIG. 17) conceptually illustrate processes. The specific operations of these processes may not be performed in the exact order shown and described. The specific operations may not be performed in one continuous series of operations, and different specific operations may be performed in different embodiments. Furthermore, the process could be implemented using several sub-processes, or as part of a larger macro process. Thus, one of ordinary skill in the art would understand that the present disclosure is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims. Additional Notes

[0161] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0162] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0163] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”

[0164] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1.A video coding method comprising:receiving data to be encoded or decoded as a current block of pixels of a current picture of a video;deriving one or more cascaded vectors by recursively tracing block vectors or motion vectors starting from a guiding vector;constructing a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors, each candidate providing inheritance information associated with a reference block located at the candidate’s corresponding derived merge candidate position;selecting a candidate from the merge candidate list;generating a predictor of the current block based on the inheritance information provided by the selected candidate; andencoding or decoding the current block by using the generated predictor.2.The video coding method of claim 1, wherein the guiding vector is a block vector or motion vector provided by a prediction mode of the current block and not retrieved from a merge candidate list.3.The video coding method of claim 1, wherein the guiding vector is a block vector or a motion vector provided by a previously coded block at a neighboring position relative to the current block.4.The video coding method of claim 3, wherein the neighboring position is where a candidate in the merge candidate list is from.5.The video coding method of claim 1, wherein the merge candidate list is used for any one of regular inter merge mode, intraTMP merge mode, IBC merge mode, CCP merge mode, and EIP merge mode.6.The video coding method of claim 1, wherein the inheritance information provided by a candidate comprises samples of a reference block at the derived merge candidate position of the candidate.7.The video coding method of claim 1, wherein the inheritance information provided by a candidate comprises a cross-component model associated with the derived merge candidate position of the candidate.8.The video coding method of claim 1, wherein the inheritance information provided by a candidate comprises an intra mode with fusion weights and block vectors associated with the derived merge candidate position of the candidate.9.The video coding method of claim 1, wherein the inheritance information provided by a candidate comprises any of a block vector, a motion vector, an intra directional mode, a non-directional mode, a cross-component model, an extrapolated filter-based intra prediction model, a fusion weight, a set of reference lines, and a set of sample values.10.The video coding method of claim 1, wherein at least one target block vector among the recursively traced block vectors or motion vectors is derived from a target reference block located corresponding to the guiding vector or the one or more cascaded vectors.11.The method of claim 10, wherein the target reference block located corresponding to the guiding vector is coded in block vector guided extrapolated intra prediction (BVG-EIP) , block vector guided convolutional cross-component model (BVG-CCCM) , block vector guided decoder-side intra mode derivation (BVG-DIMD) , decoder-side intra mode derivation (DIMD) , spatial geometric partition mode (SGPM) , direct block vector (DBV) , intra block copy (IBC) , or intra template matching prediction (IntraTMP) .12.The method of claim 10, wherein prediction of the target reference block is generated based on coding information derived based on samples in one or more further reference blocks referenced by the target reference block based on the at least one target block vector.13.The method of claim 10, wherein prediction of the target reference block is generated based on sample values in one or more further reference blocks referenced by the target reference block based on the at least one target block vector.14.An electronic apparatus comprising:a video coder circuit configured to perform operations comprising:receiving data to be encoded or decoded as a current block of pixels of a current picture of a video;deriving one or more cascaded vectors by recursively tracing block vectors or motion vectors starting from a guiding vector;constructing a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors, each candidate providing inheritance information associated with a reference block located at the candidate’s corresponding derived merge candidate position;selecting a candidate from the merge candidate list;generating a predictor of the current block based on the inheritance information provided by the selected candidate; andencoding or decoding the current block by using the generated predictor.15.A video decoding method comprising:receiving data to be decoded as a current block of pixels of a current picture of a video;deriving one or more cascaded vectors by recursively tracing block vectors or motion vectors starting from a guiding vector;constructing a merge candidate list having candidates that correspond to merge candidate positions that are derived based on the one or more cascaded vectors, each candidate providing inheritance information associated with a reference block located at the candidate’s corresponding derived merge candidate position;selecting a candidate from the merge candidate list;generating a predictor of the current block based on the inheritance information provided by the selected candidate; andreconstructing the current block by using the generated predictor.

Images