Enabling conditions for unified intra merge mode
The use of reordered merge lists with unified merge candidates and cross-component prediction filters addresses inefficiencies in predicting pixel blocks, enhancing video coding efficiency and quality by optimizing template cost calculation.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- MEDIATEK INC
- Filing Date
- 2025-10-30
- Publication Date
- 2026-05-07
AI Technical Summary
Existing video coding standards face inefficiencies in predicting pixel blocks, particularly in handling luma and chroma components, leading to suboptimal compression and decoding performance.
A method is introduced that uses reordered merge lists with unified merge candidates, incorporating luma and chroma intra prediction information from neighboring blocks, and employs cross-component prediction filters to generate predictors, optimizing the template cost calculation for improved encoding and decoding efficiency.
This approach enhances the encoding and decoding processes by reducing syntax overhead and improving prediction accuracy, resulting in more efficient video compression and better picture quality.
Smart Images

Figure CN2025131374_07052026_PF_FP_ABST
Abstract
Description
ENABLING CONDITIONS FOR UNIFIED INTRA MERGE MODECROSS 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 / 713,607, filed on 30 October 2024. Content of above-listed application is 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 intra prediction and cross-component 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. The individual CTUs in a slice are processed in raster-scan order. A bi-predictive (B) slice may be decoded using intra prediction or inter prediction with at most two motion vectors (MVs) and reference indices to predict the sample values of each block. A predictive (P) slice is decoded using intra prediction or inter prediction with at most one motion vector and reference index to predict the sample values of each block. An intra (I) slice is decoded using intra prediction only.
[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. Each CU may contain one or more transform units (TUs) for representing the prediction residual blocks.
[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 a method for using reordered merge list with unified merge candidates to encode or decode pixel blocks of video pictures. A video coder generates a merge candidate list having one or more unified merge candidates. Each unified merge candidate comprises luma intra prediction information and chroma intra prediction information. The video coder (re) orders the candidates according to template costs of the candidates that are calculated based on at least one neighboring template that is not immediately adjacent to the current block. The template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information. The video coder selects a unified merge candidate from the merge candidate list using the determined ordering. The video coder encodes or decodes the current block by using the selected merge candidate to generate a predictor.
[0011] The merge candidates may be identified based on the one or more candidate positions relative to the current block. The luma intra prediction information may include luma mode, intra prediction angular modes, combination weight, reference line, filter shape, or filter coefficients. The chroma intra prediction information may include cross-component prediction mode, model coefficients, and multi-model flag.
[0012] The at least one neighboring template may include a top template and a left template. In some embodiments, the ordering of the merge candidates is not performed when the top template or the left template is not available.
[0013] In some embodiments, the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information. In some embodiments, the reconstructed samples and the predicted samples of the template used to calculate the template cost are taken from a selected subset of sample positions of the template (e.g., by subsampling. ) The template cost may be calculated based on a difference metric that is selected from a plurality of difference metrics (e.g., SATD, SAD, MR-SAD) . The selection may be explicitly signaled, or implicitly determined based on a geometric property of the current block (e.g., block size, block height, block width) or a statistical property of the samples in the template (e.g., sum, mean, median, gradient, or variance of the samples in the template) .
[0014] In some embodiments, the template cost is a combination of luma template cost and chroma template cost. The luma template cost is a difference value between luma reconstruction samples and luma prediction samples of the template, and the chroma template cost is a difference value between chroma reconstruction samples and chroma prediction samples of the template. The template cost may be determined based a weighted sum of the luma template cost and the chroma template cost. In some other embodiments, the template cost is only based on luma template cost or only the chroma template cost.
[0015] In some embodiments, the luma and chroma template costs are computed based on luma and chroma neighboring templates having lines immediately adjacent to the current block. In some embodiments, the luma and chroma template costs are computed based on luma and chroma neighboring templates comprising lines close to the current block but no line immediately adjacent to the current block. In some embodiments, the luma and chroma template costs are computed based on a luma neighboring template comprising lines immediately adjacent to the current block and a chroma neighboring template comprising lines that are close to the current block but no line immediately adjacent to the current block.
[0016] In some embodiments, the predicted samples of the template includes predicted chroma samples that are generated by applying a cross-component filter (e.g., CCCM) to luma samples in the template. When the cross-component filter overlaps positions within the current block (such that the cross-component filter requires luma samples of the current block that are not yet available) , the video coder may provide reconstructed luma samples outside the current block as padding samples for the cross-component filter, or the video coder may provide predicted luma samples inside the current block as padding samples for the cross-component filter, with the predicted luma samples generated using the luma intra prediction information of the merge candidate.BRIEF DESCRIPTION OF THE DRAWINGS
[0017] 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.
[0018] FIG. 1 illustrates 67 intra predictions modes, including 65 directional or angular intra prediction modes.
[0019] FIG. 2 shows the template area and the reference lines for the template-based multiple reference line intra prediction.
[0020] FIG. 3 illustrates the candidate positions of spatial merge candidates neighboring a current block.
[0021] FIG. 4 illustrates a scaled motion vector for temporal merge candidate.
[0022] FIG. 5 illustrates candidate positions for temporal merge candidate.
[0023] FIG. 6 illustrates spatial neighboring blocks that are used to derive spatial merge candidates.
[0024] FIG. 7 illustrates template regions immediately adjacent to the current block.
[0025] FIG. 8 illustrates template regions that are not immediately adjacent to the current block.
[0026] FIGS. 9A-9B illustrate applying a cross-component prediction filter to samples in a template of the current block.
[0027] FIGS. 10A-10B illustrate using padding luma samples to generate chroma prediction samples in a template when the cross-component filter requires unavailable luma samples in the current block.
[0028] FIG. 11 illustrates an example video encoder that may implement unified intra merge mode prediction (UIMP) .
[0029] FIG. 12 illustrates portions of the video encoder that implement UIMP with reordering of candidates.
[0030] FIG. 13 conceptually illustrates a process that uses UIMP with reordering of candidates to encode pixel blocks.
[0031] FIG. 14 illustrates an example video decoder that may implement UIMP.
[0032] FIG. 15 illustrates portions of the video decoder that implement UIMP with reordering of candidates.
[0033] FIG. 16 conceptually illustrates a process that uses UIMP with reordering of candidates to decode a block of pixels.
[0034] FIG. 17 conceptually illustrates an electronic system with which some embodiments of the present disclosure are implemented.DETAILED DESCRIPTION
[0035] 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. Intra Prediction
[0036] A. Directional Modes
[0037] Intra-prediction method exploits one or more reference lines adjacent to the current prediction unit (PU) and one of the intra-prediction modes to generate the predictors for the current PU. The Intra-prediction direction can be chosen among a mode set containing multiple prediction directions, DC mode, and Planar mode. The intra prediction mode may also refer to any intra mode which determines the predictor of the current block using the spatially reconstructed samples. The number of directional intra modes may be 33 or extended to 65 direction modes. By including DC and Planar modes, the number of intra-prediction mode is 35 or extended to 67. FIG. 1 illustrates 67 intra predictions modes, including 65 directional or angular intra prediction modes (from 2 to 66) .
[0038] Some intra-prediction modes (e.g., 3 or 5) are identified as a set of most probable modes (MPM) for intra-prediction in current prediction block so an index may be signaled to select one of the MPMs.
[0039] B. Decoder Side Intra Mode Derivation (DIMD)
[0040] 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. The DIMD mode is used as an alternative prediction mode and / or is always checked in high-complexity RDO mode. 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.
[0041] 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 planar mode predictor with the weights derived from the histogram of gradients.
[0042] C. Template-based Intra Mode Derivation (TIMD)
[0043] For mode selection, template matching method can be applied by computing the cost between reconstructed samples and predicting samples. One of the examples is template-based intra mode derivation (TIMD) . TIMD is a coding method in which the intra prediction mode of a CU is implicitly derived by using a neighboring template at both encoder and decoder, instead of the encoder signaling the exact intra prediction mode to the decoder.
[0044] For each intra prediction mode in MPMs, as well as the wide-angle modes if the above-right and / or bottom-left reference samples are available, SATD between the prediction and reconstruction samples of the template is calculated as cost. First two intra prediction modes with the minimum SATD are selected as the TIMD modes. These two TIMD modes are fused with the weights after applying PDPC process, and such weighted intra prediction is used to code the current CU. Position dependent intra prediction combination (PDPC) is included in the derivation of the TIMD modes.
[0045] D. Extrapolation Filter-based Intra Prediction (EIP) mode
[0046] Extrapolation Intra Prediction, or EIP, is a process for generating the predictor for each sample in one block. It is therefore also called multiple source sample-based prediction (MSSBP) . In some applications, EIP is restricted to the block size not greater than 32x32 and intra slice only.
[0047] In the EIP mode, the samples in a CU are predicted from the top-left position to the bottom-right position by applying an extrapolation filter to neighboring reconstructed samples or predicted samples. The EIP mode uses a 15-tap filter for prediction as:
[0048] where pred (x, y) is the predicted value at position (x, y) in the CU, ci is the filter coefficient, and the are the reconstructed samples or predicted samples. The EIP filter can be derived from the neighboring reconstructed samples or be inherited from the previous EIP coded blocks. There are three EIP filter shapes and three types of reconstructed area.
[0049] For a CU coded in the EIP mode, an EIP merge flag is 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.
[0050] When the EIP merge flag is false, the EIP filter is derived from the neighboring reconstructed samples and the relevant syntax element is signaled to indicate which one of the three types of reconstructed area and which one of the three filter shapes are used for the CU.
[0051] E. Template-based Multiple Reference Line Intra Prediction (TMRL)
[0052] Template-based multiple reference line intra prediction (TMRL) mode combines reference line and prediction mode together and uses a template matching method to construct a list of candidate combinations. An index to the candidate combination list is signalled.
[0053] FIG. 2 shows the template area and the reference lines for the template-based multiple reference line intra prediction. The figure shows a current block 200 and its top template region 210 and left template region 220. The figure also illustrates reference lines 230-232. The reference line 230 is reference line 0, which is used for template matching. Multiple reference lines 231-232 (reference lines 1 and 2) are the extended reference lines. The SAD costs (TMRL costs) over the template area are calculated between the predictions (generated by 50 combinations) and the reconstructions. The 20 combinations with the least SAD cost are selected in an ascending order to form a TMRL candidate list. II. Cross-Component Prediction
[0054] A. Cross-Component Linear Model Prediction (CCLM)
[0055] To reduce the cross-component redundancy, a cross-component linear model (CCLM) prediction mode may be used in video coding, for which the chroma samples are predicted based on the reconstructed luma samples of the same CU by using a linear model as follows: predC (i, j) = α·recL′ (i, j) + β
[0056] where α and β are parameters of the linear model, predC (i, j) represents the predicted chroma samples in a CU, and recL′ (i, j) represents the downsampled reconstructed luma samples of the same CU.
[0057] B. Multiple Model CCLM
[0058] Multiple model CCLM mode (MMLM) is for using two linear models to predict the chroma samples from the luma samples for the whole CU. In MMLM, neighbouring luma samples and neighbouring chroma samples of the current block are classified into two groups, each group is used as a training set to derive a linear model (i.e., a particular α and β are derived for a particular group) . Furthermore, the samples of the current luma block are also classified based on the same rule for the classification of neighbouring luma samples.
[0059] C. Convolutional Cross-Component Model (CCCM)
[0060] Convolutional cross-component model (CCCM) may be applied to predict chroma samples from reconstructed luma samples in a similar manner as CCLM. As with CCLM, the reconstructed luma samples are down-sampled to match the lower resolution chroma grid when chroma sub-sampling is used. Similar to CCLM top, left or top and left reference samples are used as templates for model derivation.
[0061] A convolutional 7-tap filter for CCCM has a 5-tap plus sign shape spatial component, a nonlinear term and a bias term. 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) neighboring samples.
[0062] The nonlinear term P is represented as power of two of the center luma sample C and scaled to the sample value range of the content: P = (C*C + midVal ) >> bitDepth
[0063] That is, for 10-bit content it is calculated as: P = (C*C + 512 ) >> 10
[0064] Output of the filter is calculated as a convolution between the filter coefficients ci and the input values and clipped to the range of valid chroma samples: predChromaVal = c0C + c1N + c2S + c3E + c4W + c5P + c6B
[0065] The bias term B represents a scalar offset between the input and output (similarly to the offset term in CCLM) and is set to middle chroma value (512 for 10-bit content) . The filter coefficients ci are calculated by minimising MSE between predicted and reconstructed chroma samples in the reference area.
[0066] D. Gradient Linear Model (GLM)
[0067] For YUV 4: 2: 0 color format, a gradient linear model (GLM) method can be used to predict the chroma samples from luma sample gradients. Two modes are supported: a two-parameter GLM mode and a three-parameter GLM mode. Compared with the CCLM, instead of down-sampled luma values, the two-parameter GLM utilizes luma sample gradients to derive the linear model. Specifically, when the two-parameter GLM is applied, the input to the CCLM process, i.e., the down-sampled luma samples L, are replaced by luma sample gradients G. The other parts of the CCLM (e.g., parameter derivation, prediction sample linear transform) are kept unchanged. C = α ·G + β
[0068] In the three-parameter GLM, a chroma sample can be predicted based on both the luma sample gradients and down-sampled luma values with different parameters. The model parameters of the three-parameter GLM are derived from 6 rows and columns adjacent samples by the LDL decomposition based MSE minimization method as used in the CCCM. C = α0 ·G + α1 ·L + α2 ·β III. Merge Candidate Positions
[0069] The following sections describes candidate positions relative to the current block for generating merge mode candidates.
[0070] A. Spatial Candidates Derivation
[0071] FIG. 3 illustrates the candidate positions of spatial merge candidates neighboring a current block 300, specifically A0, A1, B2, B0, and B1.
[0072] B. Temporal Candidates Derivation
[0073] For a temporal merge candidate, a scaled motion vector is derived based on co-located CU belonging to the collocated reference picture. The reference picture list and the reference index to be used for derivation of the co-located CU is explicitly signaled in the slice header. FIG. 4 illustrates a scaled motion vector for temporal merge candidate. The dotted line illustrates the temporal merge candidate, which is scaled from the motion vector of the co-located CU using the picture order count (POC) distances, tb and td, where tb is defined to be the POC difference between the reference picture of the current picture and the current picture and td is defined to be the POC difference between the reference picture of the co-located picture and the co-located picture. The reference picture index of temporal merge candidate is set equal to zero.
[0074] FIG. 5 illustrates candidate positions for temporal merge candidates, specifically C0 and C1. The position for the temporal candidate is selected between candidates C0 and C1.
[0075] C. Non-Adjacent Spatial Candidate
[0076] Non-adjacent spatial merge candidates are candidate positions that may not be adjacent to the current block. FIG. 6 illustrates spatial neighboring blocks that are used to derive spatial merge candidates, including spatial neighboring blocks at adjacent and non-adjacent positions relative to the current block 600. In the figure, candidate positions “1” through “5” are adjacent positions, while candidate positions “6” through “23” are non-adjacent positions. The distances between non-adjacent spatial candidates and the current coding block may be based on the width and height of current coding block. IV. Unified Intra Merge Prediction (UIMP)
[0077] In some embodiments, a unified intra merge prediction (UIMP) mode or unified intra merge mode prediction is used to jointly inherit the luma and chroma intra prediction information from neighboring positions / blocks to the current block. Specifically, first, one or more merge lists are created by including candidates associated with both luma and chroma intra prediction information (or “luma-chroma joint intra prediction information” , abbreviated as jointIntraInfo) from neighboring reference positions / blocks. At least one of the candidates in the merge list is selected, and jointIntraInfo associated with the selected candidates are inherited by the current block. The current block generates the prediction of the current block and performs the coding process based on the inherited jointIntraInfo.
[0078] In some embodiments, the inherited luma intra prediction information may include but not limited to intra luma prediction mode (e.g., DIMD, TIMD, TMRL, EIP, matrix based intra prediction (MIP) , spatial geometric partitioning mode (SGPM) , intra template matching prediction (IntraTMP) , matrix based position dependent intra prediction (PDP) , sub-mode flags (e.g., a flag is signaled depending on if a prediction mode flag is true) , intra prediction directions, intra prediction blending weights, intra prediction blending modes, intra interpolation filter shape, intra interpolation filter parameters, multiple reference line indices, classification threshold, and / or transform kernel types (e.g., DCT2, DST7, DCT8) .
[0079] In some embodiments, the inherited chroma intra prediction information includes but not limited to intra chroma prediction mode (e.g., CCLM, MMLM, CCCM, variants of CCCM or CCLM, chroma DIMD) , GLM pattern index, model parameters, prediction fusion modes, prediction fusion weights, or classification threshold. In some embodiments, a candidate’s luma and chroma intra prediction information comes (are inherited) from the same neighboring positions / block. In some embodiments, intra luma and chroma prediction modes are specified in each candidate. The prediction of the current block is generated based on the specified prediction modes. The coding process of the current block also follows the specified prediction modes.
[0080] In some embodiments, a merge list is constructed by including candidates in a pre-defined order until the maximum candidate number is reached. At least some of the candidates are described in Section III.
[0081] A. Position / Block Settings of Candidates for UIMP
[0082] Spatial Candidates
[0083] The spatial adjacent candidates are from the adjacent neighboring blocks of the current block. The inclusion order and the positions of the adjacent neighboring blocks can be the same as those of spatial candidates of regular inter merge mode as described in Section III above. The positions of the adjacent neighboring blocks can be any subset of the adjacent neighboring blocks of the current block.
[0084] The spatial non-adjacent candidates are from a search range around (but not adjacent to) the current block. The search range can be the same as or different from the search range of non-adjacent candidates of regular inter merge mode. The inclusion order and the positions of spatial non-adjacent candidates can be the same as those of spatial non-adjacent candidates of regular inter merge mode.
[0085] Temporal candidates
[0086] In some embodiments, if the current slice / picture is a non-intra slice / picture, the jointIntraInfo can be from blocks at pre-defined positions in previously coded slices / pictures. In some embodiments, the rules to determine the previous coded slices / pictures from which the jointIntraInfo is retrieved can be the same as those of regular inter merge mode. In some embodiments, the previous coded slices / pictures from which the jointIntraInfo is retrieved are signaled in in sequence parameter set (SPS) , picture parameter set (PPS) , picture header (PH) or slice header (SH) . In some embodiments, the inclusion order and the pre-defined position from which the jointIntraInfo is retrieved can be the same as those of regular inter merge mode.
[0087] In one embodiment, if the current block position is at (x, y) and the block size is w×h, the pre-defined positions are inside the corresponding area of the current block. For example, the inherited jointIntraInfo can be from the block at position (x, y) , (x, y + h / 2) , (x + w / 2, y) , (x + w / 2, y + h / 2) , (x + w, y) , (x, y + h) , or (x + w, y + h) of the previous coded slices / picture.
[0088] B. Retrieving Joint Intra prediction information from candidates
[0089] In some embodiments, if the prediction modes of both the luma and chroma intra prediction information (or luma-chroma joint intra prediction information, or “jointIntraInfo” ) associated with a neighboring block at a candidate position are in the allowed or supported intra luma and chroma prediction modes respectively, the neighboring block (i.e., the luma and chroma intra prediction information of this neighboring block) is allowed to be added into the merge list of the current block as a candidate.
[0090] In some embodiments, the allowed or supported intra luma prediction modes include DIMD, TIMD, TMRL, and EIP. The allowed or supported chroma intra prediction modes include cross-component prediction modes (e.g., CCLM, MMLM, CCCM, variants of CCCM and CCLM, interCCCM, and / or cross-component merge mode (including intra cross-component merge mode and / or inter cross-component merge mode) ) , and / or chroma DIMD mode.
[0091] In some embodiments, for all blocks in the coding process, after finishing coding a block, if the luma component of a block is coded in allowed or supported intra luma prediction modes, the luma intra prediction information is stored in a buffer associated with this block. Later, if this block is at a candidate position of the current block, the associated luma intra prediction information can be added into the merge list as a part of jointIntraInfo.
[0092] In some embodiments, for all blocks in the coding process, after finishing coding a block, if the chroma component of a block is coded in allowed or supported intra chroma prediction modes, the chroma intra prediction information is stored in a buffer associated with this block. Later, if this block is at a candidate position of the current block, the associated chroma intra prediction information can be added into the merge list as a part of jointIntraInfo.
[0093] In some embodiments, for all blocks in the coding process, after finishing coding a block, only if both the luma and chroma components of a block are coded in allowed or supported intra luma and chroma prediction modes respectively, both the luma and chroma intra prediction information is stored in a buffer associated with this block. Later, if this block is at a candidate position of the current block, the associated luma and chroma intra prediction information can be added into the merge list.
[0094] C. Reordering the Merge List for UIMP
[0095] In some embodiments, the candidates in the merge list can be reordered to reduce the syntax overhead when signaling the index of the selected candidate. In some embodiments, the reordering rule is based on the template cost of each candidate. The candidates are reordered according to their template cost in ascending order. The template cost of a candidate is a difference metric between reconstruction samples and prediction samples of the neighboring templates of the current block. The prediction samples are generated by utilizing the jointIntraInfo of the candidate on the neighboring templates of the current block. The template cost can be computed based on the sum of differences between reconstruction samples and prediction samples. For example, the template cost can be SAD (sum of absolute differences) , SATD (sum of absolute transformed differences) or MR-SAD (mean-removed SAD) . The luma template cost is computed using only the luma samples in the neighboring templates. In other words, the luma template cost is the differences between the luma reconstruction samples and luma prediction samples. The chroma template cost is computed using only the chroma samples in the neighboring templates. In other words, the chroma template cost is the differences between the chroma reconstruction samples and chroma prediction samples.
[0096] In some embodiments, the template cost which the reordering is based on is a combination of luma template cost and chroma template cost. In some embodiments, equal weighting is used to combine luma template cost and chroma template cost. In some embodiments, template cost is a*luma template cost + b*chroma template cost, where a and b are both positive, and a > b. For example, a = 6 and b = 2. In some embodiments, template cost is a*luma template cost +b*chroma template cost, where a and b are both positive, and a < b. For example, a = 2 and b = 6. In some embodiments, the reordering is only based on the luma template cost. In some embodiments, the reordering is only based on the chroma template cost.
[0097] In some embodiments, the reordering is not performed when the left or above neighboring samples of the current block are not available. In some embodiments, the reordering is performed when both the left and above neighboring samples of the current block are available. In some embodiments, the reordering is performed when number of neighboring samples of the current block is greater than or equal to a threshold.
[0098] In some embodiments, the luma and / or chroma neighboring templates are / include the lines immediately adjacent to the current block. FIG. 7 illustrates template regions immediately adjacent to the current block. In the figure, the size of the top neighboring template 710 of the current block 700 is wt × ht, the size of the left neighboring template 720 of the current block is wl × hl. For example, if the block width and height of the current block is w and h respectively, wt = w, and hl = h. ht and wl can be any positive integer (e.g., ht and wl being 1 or 2) .
[0099] In some embodiments, the luma and / or chroma neighboring templates are / include the lines close to the current block but not immediately adjacent to the current block. FIG. 8 illustrates template regions that are not immediately adjacent to the current block. In the figure, top template 810 and the left template 820 are separated from the current block 800 by nt pixels and nl pixels, respectively, nt and nl being positive integers (e.g., nt and nl equal to one. )
[0100] In some embodiments, the luma neighboring templates are the lines immediately adjacent to the current block, and the chroma neighboring templates are / include the lines close to the current block but not immediately adjacent to the current block. For example, the luma neighboring templates may be as depicted in FIG. 7, with ht and wl equal to 1, while the chroma neighboring templates are as depicted in FIG. 8, with ht, wl, nt, and nl equal to 1.
[0101] In some embodiments, selected positions in top or left neighboring templates (i.e., partial positions in top or left neighboring templates) are used to calculate the template cost. For examples, number of selected positions in top or left neighboring templates based on the short side length of the current block. Suppose the short side length of the current block is n, then n × wl positions in left template and n × ht positions in above template are selected to calculate template cost. Number of positions selected from the left template may the same as that of the above template. The selected positions from the above or left template can be further subsampled. For example, one position out of every x samples at the above or left template are selected. For another example, the first y samples at the above or left template are selected.
[0102] In some embodiments, when generating chroma prediction samples in templates for a candidate, the shape of the cross-component prediction filter may require luma samples within the current block. Since luma reconstruction is not available at the time of coding, these luma samples within the current block are generated based on the luma reconstruction samples at the outer boundary of the current block.
[0103] FIGS. 9A-9B illustrate applying a cross-component prediction filter to samples in a neighboring template of the current block 900. As illustrated, if a cross-shape filter 950 (e.g., CCCM filter) is used, some filter terms may not be available because the filter requires samples in the current block 900 (because the filter shape overlaps positions in the current block) , which is not yet reconstructed. For example, when generating the chroma prediction samples in the top neighboring template 910, the “S” luma term is not available, and when generating chroma prediction samples in the left neighboring template 920, the “E” luma term is not available.
[0104] In some embodiments, the luma samples within the current block are generated by padding. For example, if the position of the top-left corner of the current block is denoted as (0, 0) , the sample at (x, n) may be generated by copying the sample at (x, -1) , and the samples at (n, y) can be generated by copying the sample at (-1, y) , where n is a non-negative integer (e.g., n = 0) . In the example of FIG. 9A, the “S” luma term may be generated by copying “C” luma term when generating chroma prediction samples for the top neighboring template 910. In the example of FIG. 9B, the “E” luma term may be generated by copying “C” luma term when generating chroma prediction samples for the left neighboring template 920.
[0105] FIGS. 10A-10B illustrate using padding luma samples to generate chroma prediction samples when the cross-component filter requires unavailable luma samples in the current block, even when the neighboring template regions are not immediately adjacent to the current block. In the figure, neighboring templates 1010 and 1020 are used to calculate template cost for reordering the candidates of the merge list for generating a predictor for the current block 1000. The neighboring templates 1010 and 1020 are not immediately adjacent to the current block 1000. Examples of templates with respect to the current block are described by reference to FIGS. 7-8 above.
[0106] As illustrate, a cross-component filter 1050 is used to generate the chroma prediction samples of the templates 1010 and 1020. The filter 1050 has a filter shape that may extend into the current block 1000, even though the templates 1010 and / or 1020 are not immediately adjacent to the current block 1000. Since the reconstructed luma samples of the current block 1000 may not be available, reconstructed luma samples immediate adjacent to the current block are used as padding samples. FIG. 10A illustrates samples at (x, -1) being used as padding luma samples for the top template 1010 when the filter shape 1050 extends into the current block 1000. FIG. 10B illustrates samples at (-1, y) being used as padding luma samples for the left template 1020 when the filter shape 1050 extends into the current block 1000.
[0107] In some embodiments, the sample at the top-left corner of the current block can be the average of the sample above and the sample left to itself. The sample at (0, 0) can be the average of the sample at (0, -1) and (-1, 0) . In some embodiments, the luma samples within the current block are generated based on the luma intra prediction information of the candidate. The luma samples within the current block are generated following the method of generating the prediction samples based on the luma intra prediction information of the candidate.
[0108] In some embodiments, multiple difference metrics can be used, and the choice among the difference metric is determined by signaling. For example, if one difference metric is to be chosen from two difference metrics (e.g., SAD and MR-SAD, or SAD and SATD) , a flag can be signaled as syntax element to indicate which difference metric is chosen to be used. In some embodiments, the choice among the multiple difference metrics is determined by implicit rules. The rules may be based on block size, block width, block height, or other characteristics of the current block. The rules may be based on sum, mean, median, gradient, or variance of samples in the neighboring templates.
[0109] D. Syntax Setting for UIMP
[0110] In some embodiments, a flag is signaled to indicate whether the current block inherits the luma and chroma intra prediction information jointly from previously coded blocks. The flag can be signaled per CU / CB, per PU, per TU / TB, or per color component, or per chroma color component.
[0111] In some embodiments, a high-level syntax can be signaled in SPS, PPS, PH or SH to indicate whether the Unified Intra Merge Mode (UIMP) as described in Section IV are allowed for the current sequence, picture, or slice. In some embodiments, if the current block inherits the luma and chroma intra prediction information jointly from neighboring blocks, the index of the inherited / selected candidate is signaled to indicate the position of the inherited / selected candidate in the merge list. In some embodiments, when signaling intra prediction mode of the current block, a syntax is firstly signaled to indicate whether the current block is predicted by the UIMP as described in Section IV. If the syntax indicates that the current block is predicted by the UIMP, syntax indicating the selected candidate in the merge list follows, and syntax related to chroma intra prediction is not signaled. Otherwise, the luma and chroma intra prediction modes of the current block are indicated / signaled.
[0112] 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 / prediction module of an encoder, and / or an inter / intra / prediction module of a decoder. Alternatively, any of the proposed methods can be implemented as a circuit coupled to the inter / intra / prediction module of the encoder and / or the inter / intra / prediction module of the decoder, so as to provide the information needed by the inter / intra / prediction module . V. Example Video Encoder
[0113] FIG. 11 illustrates an example video encoder that may implement unified intra merge mode prediction (UIMP) . As illustrated, the video encoder 1100 receives input video signal from a video source 1105 and encodes the signal into bitstream 1195. The video encoder 1100 has several components or modules for encoding the signal from the video source 1105, at least including some components selected from a transform module 1110, a quantization module 1111, an inverse quantization module 1114, an inverse transform module 1115, an intra estimation module 1124, an intra prediction module 1125, a motion compensation module 1130, a motion estimation module 1135, an in-loop filter 1145, a reconstructed picture buffer 1150, a MV buffer 1165, and a MV prediction module 1175, and an entropy encoder 1190. The motion compensation module 1130 and the motion estimation module 1135 are part of an inter-prediction module 1140. The intra-prediction module 1125 and the intra-estimation module 1124 are part of a current picture prediction module 1120, which uses current picture reconstructed samples as reference samples for prediction of the current block.
[0114] In some embodiments, the modules 1110 –1190 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 1110 –1190 are modules of hardware circuits implemented by one or more integrated circuits (ICs) of an electronic apparatus. Though the modules 1110 –1190 are illustrated as being separate modules, some of the modules can be combined into a single module.
[0115] The video source 1105 provides a raw video signal that presents pixel data of each video frame without compression. A subtractor 1108 computes the difference between the raw video pixel data of the video source 1105 and the predicted pixel data 1113 from the motion compensation module 1130 or intra-prediction module 1125 as prediction residual 1109. The transform module 1110 converts the difference (or the residual pixel data or residual signal 1108) into transform coefficients (e.g., by performing Discrete Cosine Transform, or DCT) . The quantization module 1111 quantizes the transform coefficients into quantized data (or quantized coefficients) 1112, which is encoded into the bitstream 1195 by the entropy encoder 1190.
[0116] The inverse quantization module 1114 de-quantizes the quantized data (or quantized coefficients) 1112 to obtain transform coefficients 1118, and the inverse transform module 1115 performs inverse transform on the transform coefficients 1118 to produce reconstructed residual 1119. The reconstructed residual 1119 is added with the predicted pixel data 1113 to produce reconstructed pixel data 1117. In some embodiments, the reconstructed pixel data 1117 is temporarily stored in a line buffer 1127 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction. The reconstructed pixels are filtered by the in-loop filter 1145 and stored in the reconstructed picture buffer 1150. In some embodiments, the reconstructed picture buffer 1150 is a storage external to the video encoder 1100. In some embodiments, the reconstructed picture buffer 1150 is a storage internal to the video encoder 1100.
[0117] The intra estimation module 1124 derives intra-prediction data (e.g., intra prediction modes) based on the reconstructed pixel data 1117 (stored in the line buffer 1127) . The intra-prediction data is provided to the entropy encoder 1190 to be encoded into bitstream 1195. The intra-prediction data is also used by the intra-prediction module 1125 to produce the predicted pixel data 1113.
[0118] The motion estimation module 1135 performs inter-prediction by producing MVs to reference pixel data of previously decoded frames stored in the reconstructed picture buffer 1150. These MVs are provided to the motion compensation module 1130 to produce predicted pixel data.
[0119] Instead of encoding the complete actual MVs in the bitstream, the video encoder 1100 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 1195.
[0120] The MV prediction module 1175 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 1175 retrieves reference MVs from previous video frames from the MV buffer 1165. The video encoder 1100 stores the MVs generated for the current video frame in the MV buffer 1165 as reference MVs for generating predicted MVs.
[0121] The MV prediction module 1175 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 1195 by the entropy encoder 1190.
[0122] The entropy encoder 1190 encodes various parameters and data into the bitstream 1195 by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding. The entropy encoder 1190 encodes various header elements, flags, along with the quantized transform coefficients 1112, and the residual motion data as syntax elements into the bitstream 1195. The bitstream 1195 is in turn stored in a storage device or transmitted to a decoder over a communications medium such as a network.
[0123] The in-loop filter 1145 performs filtering or smoothing operations on the reconstructed pixel data 1117 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 1145 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.
[0124] FIG. 12 illustrates portions of the video encoder that implement UIMP with reordering of candidates. In some embodiments, the UIMP predictor for the current block is generated by the intra prediction module 1125, while several other components of the video encoder 1100 provide the UIMP merge candidates and reorders the merge candidate list.
[0125] As illustrated, a prediction history storage 1210 stores prediction history of coded blocks. The prediction history storage 1210 is used to provide a record of the luma and chroma intra prediction information, including intra prediction modes and cross-component prediction modes, of the previously coded blocks or positions. Luma intra prediction information may specify the intra prediction mode used, such as angular intra, DIMD, TIMD, TMRL, EIP, etc. and their corresponding parameters (e.g., intra prediction angular modes, combination weight, reference line, EIP filter shape, EIP filter coefficients) . Chroma intra prediction information may specify cross-component prediction mode used, such as CCLM, CCCM, MMLM, etc. and their corresponding parameters (e.g., model coefficients, multi-model flag, GLM pattern index, model parameters, prediction fusion modes, prediction fusion weights, or classification threshold…)
[0126] A merge candidate generation module 1220 generates one or more merge candidate list for the current block based on information stored in the prediction history storage 1210 for candidate positions relative to the current block, including neighboring blocks, adjacent positions, and some non-adjacent positions.
[0127] If UIMP is enabled for the current block, the merge candidate generation module 1220 generates one or more UIMP candidates to be included in or into a merge list 1230 or a UIMP merge list 1235, based on chroma and luma intra prediction information stored in the storage 1210 for candidate positions relative to the current block. In some embodiments, each UIMP candidate may specify joint luma-chroma intra prediction information (jointIntraInfo. ) In some embodiments, the luma and chroma intra prediction information of a candidate position are allowed to be added to the merge candidate list as a unified merge candidate 1227 only when the luma and chroma prediction information specifies luma and chroma prediction modes that are supported for the current block.
[0128] A candidate reordering module 1260 performs reordering of the candidates in the merge candidate list 1230 or the UIMP merge list 1235. The reordering is according to template costs of the candidates that are calculated based on one or more neighboring templates. The templates may or may not be immediately adjacent to the current block.
[0129] A template cost module 1265 calculates the template costs of the merge candidates. The template cost of each merge candidate is calculated based on a difference between reconstructed samples of the template and predicted samples of the template. The reconstructed samples may be retrieved from the line buffer 1127 or the reconstructed picture buffer 1150. The predicted samples are generated using the merge candidate’s intra prediction information, which may include luma intra prediction information and chroma intra prediction information. In some embodiments, the template cost module 1265 may perform non-cross-component intra prediction for the luma samples and cross-component intra prediction for chroma samples to obtain the template cost. In some embodiments, when applying a cross-component filter to generate prediction for chroma prediction samples, reconstructed luma samples outside the current block are provided as padding samples for the cross-component filter when the cross-component filter overlaps positions within the current block.
[0130] In some embodiments, the template cost is a combination of luma template cost and chroma template cost, with the luma template cost being a difference value between luma reconstruction samples and luma prediction samples of the template, and the chroma template cost being a difference value between chroma reconstruction samples and chroma prediction samples of the template. In some embodiments, the template cost is calculated based on a difference metric that is selected from a plurality of possible metrics (e.g., SATD, SAD, MR-SAD) and the selection will be explicitly signaled in the bitstream 1195. In some embodiments, the selection of the difference metric is based on a geometric property of the current block (e.g., block size, block height, block width) or a statistical property of the samples in the template (e.g., sum, mean, median, gradient, or variance of samples in the template) .
[0131] The intra prediction module 1125 generates a predictor 1250 for the current block based on a merge candidate 1240 selected from the merge list 1230 or 1235. The intra prediction module 1125 may receive the selection of a merge candidate from the intra estimation module 1124, which may provide the selection to the entropy encoder to be included in the bitstream 1195 as syntax elements. The intra prediction module 1125 may perform cross-component prediction for chroma component and non-cross-component intra-prediction for luma component based on pixel data stored in the line buffer 1127 and the reconstructed picture buffer 1150. The cross-component prediction and the non-cross-component intra-prediction are performed according to the mode and the associated parameters provided by the selected merge candidate 1240. The prediction is used to generate the predictor 1250, which is provided to the video encoder 1100 as the predicted pixel data 1113.
[0132] FIG. 13 conceptually illustrates a process that uses UIMP with reordering of candidates to encode pixel blocks. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the encoder 1100 performs the process 1300 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the encoder 1100 performs the process 1300.
[0133] The encoder receives (at block 1310) data to be encoded as a current block of pixels of a current picture of a video. The encoder generates (at block 1320) a merge candidate list having one or more unified merge candidates. Each unified merge candidate has luma intra prediction information and chroma intra prediction information. The merge candidates may be identified based on the one or more candidate positions relative to the current block. The luma intra prediction information may include luma mode, intra prediction angular modes, combination weight, reference line, filter shape, or filter coefficients. The chroma intra prediction information may include cross-component prediction mode, model coefficients, and multi-model flag.
[0134] The encoder orders (or reorders) (at block 1330) the candidates according to template costs of the candidates that are calculated using at least one neighboring template. The template may or may not be immediately adjacent to the current block. The at least one neighboring template may include a top template and a left template. In some embodiments, the ordering of the merge candidates is not performed when the top template or the left template is not available.
[0135] In some embodiments, the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information. In some embodiments, the reconstructed samples and the predicted samples of the template used to calculate the template cost are taken from a selected subset of sample positions of the template (e.g., by subsampling. ) The template cost may be calculated based on a difference metric that is selected from a plurality of difference metrics (e.g., SATD, SAD, MR-SAD) . The selection may be explicitly signaled, or implicitly determined based on a geometric property of the current block (e.g., block size, block height, block width) or a statistical property of the samples in the template (e.g., sum, mean, median, gradient, or variance of the samples in the template) .
[0136] In some embodiments, the template cost is a combination of luma template cost and chroma template cost. The luma template cost is a difference value between luma reconstruction samples and luma prediction samples of the template, and the chroma template cost is a difference value between chroma reconstruction samples and chroma prediction samples of the template. The template cost may be determined based a weighted sum of the luma template cost and the chroma template cost. In some other embodiments, the template cost is only based on luma template cost or only the chroma template cost. In some embodiments, the luma and chroma template costs are computed based on luma and chroma neighboring templates having lines immediately adjacent to the current block. In some embodiments, the luma and chroma template costs are computed based on luma and chroma neighboring templates comprising lines close to the current block but no line immediately adjacent to the current block. In some embodiments, the luma and chroma template costs are computed based on a luma neighboring template comprising lines immediately adjacent to the current block and a chroma neighboring template comprising lines that are close to the current block but no line immediately adjacent to the current block.
[0137] In some embodiments, the predicted samples of the template includes predicted chroma samples that are generated by applying a cross-component filter (e.g., CCCM) to luma samples in the template. When the cross-component filter overlaps positions within the current block (such that the cross-component filter requires luma samples of the current block that are not yet available) , the encoder may provide reconstructed luma samples outside the current block as padding samples for the cross-component filter, or the encoder may provide predicted luma samples inside the current block as padding samples for the cross-component filter, with the predicted luma samples generated using the luma intra prediction information of the merge candidate. Using padding samples for the cross-component filter is described by reference to e.g., FIGS 9-10 above.
[0138] The encoder selects (at block 1340) a unified merge candidate from the merge candidate list using the determined order based on the template costs. The encoder generates (at block 1350) a predictor of the current block based on the selected unified merge candidate. The encoder encodes (at block 1360) the current block by using the generated predictor to produce the prediction residuals and to reconstruct the current block. VI. Example Video Decoder
[0139] 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.
[0140] FIG. 14 illustrates an example video decoder 1400 that may implement unified intra merge mode prediction (UIMP) . As illustrated, the video decoder 1400 is an image-decoding or video-decoding circuit that receives a bitstream 1495 and decodes the content of the bitstream into pixel data of video frames for display. The video decoder 1400 has several components or modules for decoding the bitstream 1495, including some components selected from an inverse quantization module 1414, an inverse transform module 1415, an intra-prediction module 1425, a motion compensation module 1430, an in-loop filter 1445, a decoded picture buffer 1450, a MV buffer 1465, a MV prediction module 1475, and a parser 1490. The motion compensation module 1430 is part of an inter-prediction module 1440. The intra-prediction module 1425 is part of a current picture prediction module 1420, which uses current picture reconstructed samples as reference samples for prediction of the current block.
[0141] In some embodiments, the modules 1414 –1490 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 1414 –1490 are modules of hardware circuits implemented by one or more ICs of an electronic apparatus. Though the modules 1414 –1490 are illustrated as being separate modules, some of the modules can be combined into a single module.
[0142] The parser 1490 (or entropy decoder) receives the bitstream 1495 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) 1412. The parser 1490 parses out the various syntax elements by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding.
[0143] The inverse quantization module 1414 de-quantizes the quantized data (or quantized coefficients) 1412 to obtain transform coefficients, and the inverse transform module 1415 performs inverse transform on the transform coefficients 1418 to produce reconstructed residual signal 1419. The reconstructed residual signal 1419 is added with predicted pixel data 1413 from the intra-prediction module 1425 or the motion compensation module 1430 to produce decoded pixel data 1417. The decoded pixels data are filtered by the in-loop filter 1445 and stored in the decoded picture buffer 1450. In some embodiments, the decoded picture buffer 1450 is a storage external to the video decoder 1400. In some embodiments, the decoded picture buffer 1450 is a storage internal to the video decoder 1400.
[0144] The intra-prediction module 1425 receives intra-prediction data from bitstream 1495 and according to which, produces the predicted pixel data 1413 from the decoded pixel data 1417 stored in the decoded picture buffer 1450. In some embodiments, the decoded pixel data 1417 is also stored in a line buffer 1427 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction.
[0145] In some embodiments, the content of the decoded picture buffer 1450 is used for display. A display device 1405 either retrieves the content of the decoded picture buffer 1450 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 1450 through a pixel transport.
[0146] The motion compensation module 1430 produces predicted pixel data 1413 from the decoded pixel data 1417 stored in the decoded picture buffer 1450 according to motion compensation MVs (MC MVs) . These motion compensation MVs are decoded by adding the residual motion data received from the bitstream 1495 with predicted MVs received from the MV prediction module 1475.
[0147] The MV prediction module 1475 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 1475 retrieves the reference MVs of previous video frames from the MV buffer 1465. The video decoder 1400 stores the motion compensation MVs generated for decoding the current video frame in the MV buffer 1465 as reference MVs for producing predicted MVs.
[0148] The in-loop filter 1445 performs filtering or smoothing operations on the decoded pixel data 1417 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 1445 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.
[0149] FIG. 15 illustrates portions of the video decoder that implement UIMP with reordering of candidates. In some embodiments, the UIMP predictor for the current block is generated by the intra prediction module 1425, while several other components of the video decoder 1400 provide the UIMP merge candidates and reorders the merge candidate list.
[0150] As illustrated, a prediction history storage 1510 stores prediction history of coded blocks. The prediction history storage 1510 is used to provide a record of the luma and chroma intra prediction information, including intra prediction modes and cross-component prediction modes, of the previously coded blocks or positions. Luma intra prediction information may specify the intra prediction mode used, such as angular intra, DIMD, TIMD, TMRL, EIP, etc. and their corresponding parameters (e.g., intra prediction angular modes, combination weight, reference line, EIP filter shape, EIP filter coefficients) . Chroma intra prediction information may specify cross-component prediction mode used, such as CCLM, CCCM, MMLM, etc. and their corresponding parameters (e.g., model coefficients, multi-model flag, GLM pattern index, model parameters, prediction fusion modes, prediction fusion weights, or classification threshold…)
[0151] A merge candidate generation module 1520 generates one or more merge candidate list for the current block based on information stored in the prediction history storage 1510 for candidate positions relative to the current block, including neighboring blocks, adjacent positions, and some non-adjacent positions.
[0152] If UIMP is enabled for the current block, the merge candidate generation module 1520 generates one or more UIMP candidates to be included in or into a merge list 1530 or a UIMP merge list 1535, based on chroma and luma intra prediction information stored in the storage 1510 for candidate positions relative to the current block. In some embodiments, each UIMP candidate may specify joint luma-chroma intra prediction information (jointIntraInfo. ) In some embodiments, the luma and chroma intra prediction information of a candidate position are allowed to be added to the merge candidate list as a unified merge candidate 1527 only when the luma and chroma prediction information specifies luma and chroma prediction modes that are supported for the current block.
[0153] A candidate reordering module 1560 performs reordering of the candidates in the merge candidate list 1530 or the UIMP merge list 1535. The reordering is according to template costs of the candidates that are calculated based on one or more neighboring templates. The templates may or may not be immediately adjacent to the current block.
[0154] A template cost module 1565 calculates the template costs of the merge candidates. The template cost of each merge candidate is calculated based on a difference between reconstructed samples of the template and predicted samples of the template. The reconstructed samples may be retrieved from the line buffer 1427 or the decoded picture buffer 1450. The predicted samples are generated using the merge candidate’s intra prediction information, which may include luma intra prediction information and chroma intra prediction information. In some embodiments, the template cost module 1565 may perform non-cross-component intra prediction for the luma samples and cross-component intra prediction for chroma samples to obtain the template cost. In some embodiments, when applying a cross-component filter to generate prediction for chroma prediction samples, reconstructed luma samples outside the current block are provided as padding samples for the cross-component filter when the cross-component filter overlaps positions within the current block.
[0155] In some embodiments, the template cost is a combination of luma template cost and chroma template cost, with the luma template cost being a difference value between luma reconstruction samples and luma prediction samples of the template, and the chroma template cost being a difference value between chroma reconstruction samples and chroma prediction samples of the template. In some embodiments, the template cost is calculated based on a difference metric that is selected from a plurality of possible metrics (e.g., SATD, SAD, MR-SAD) based on explicit signaling in the bitstream 1495. In some embodiments, the selection of the difference metric is based on a geometric property of the current block (e.g., block size, block height, block width) or a statistical property of the samples in the template (e.g., sum, mean, median, gradient, or variance of samples in the template) .
[0156] The intra prediction module 1425 generates a predictor 1550 for the current block based on a merge candidate 1540 selected from the merge list 1530 or 1535. The intra prediction module 1425 may receive the selection of a merge candidate from the entropy decoder 1490, which parses the bitstream 1495 for syntax elements to provide the selection. The intra prediction module 1425 may perform cross-component prediction for chroma component and non-cross-component intra-prediction for luma component based on pixel data stored in the line buffer 1427 and the decoded picture buffer 1450. The cross-component prediction and the non-cross-component intra-prediction are performed according to the mode and the associated parameters provided by the selected merge candidate 1540. The prediction is used to generate the predictor 1550, which is provided to the video decoder 1400 as the predicted pixel data 1413.
[0157] FIG. 16 conceptually illustrates a process that uses UIMP with reordering of candidates to decode pixel blocks. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the decoder 1400 performs the process 1600 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the decoder 1400 performs the process 1600.
[0158] The decoder receives (at block 1610) data to be decoded as a current block of pixels of a current picture of a video. The decoder generates (at block 1620) a merge candidate list having one or more unified merge candidates. Each unified merge candidate has luma intra prediction information and chroma intra prediction information. The merge candidates may be identified based on the one or more candidate positions relative to the current block. The luma intra prediction information may include luma mode, intra prediction angular modes, combination weight, reference line, filter shape, or filter coefficients. The chroma intra prediction information may include cross-component prediction mode, model coefficients, and multi-model flag.
[0159] The decoder orders (or reorders) (at block 1630) the candidates according to template costs of the candidates that are calculated using at least one neighboring template. The template may or may not be immediately adjacent to the current block. The at least one neighboring template may include a top template and a left template. In some embodiments, the ordering of the merge candidates is not performed when the top template or the left template is not available.
[0160] In some embodiments, the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information. In some embodiments, the reconstructed samples and the predicted samples of the template used to calculate the template cost are taken from a selected subset of sample positions of the template (e.g., by subsampling. ) The template cost may be calculated based on a difference metric that is selected from a plurality of difference metrics (e.g., SATD, SAD, MR-SAD) . The selection may be explicitly signaled, or implicitly determined based on a geometric property of the current block (e.g., block size, block height, block width) or a statistical property of the samples in the template (e.g., sum, mean, median, gradient, or variance of the samples in the template) .
[0161] In some embodiments, the template cost is a combination of luma template cost and chroma template cost. The luma template cost is a difference value between luma reconstruction samples and luma prediction samples of the template, and the chroma template cost is a difference value between chroma reconstruction samples and chroma prediction samples of the template. The template cost may be determined based a weighted sum of the luma template cost and the chroma template cost. In some other embodiments, the template cost is only based on luma template cost or only the chroma template cost.
[0162] In some embodiments, the luma and chroma template costs are computed based on luma and chroma neighboring templates having lines immediately adjacent to the current block. In some embodiments, the luma and chroma template costs are computed based on luma and chroma neighboring templates comprising lines close to the current block but no line immediately adjacent to the current block. In some embodiments, the luma and chroma template costs are computed based on a luma neighboring template comprising lines immediately adjacent to the current block and a chroma neighboring template comprising lines that are close to the current block but no line immediately adjacent to the current block.
[0163] In some embodiments, the predicted samples of the template includes predicted chroma samples that are generated by applying a cross-component filter (e.g., CCCM) to luma samples in the template. When the cross-component filter overlaps positions within the current block (such that the cross-component filter requires luma samples of the current block that are not yet available) , the decoder may provide reconstructed luma samples outside the current block as padding samples for the cross-component filter, or the decoder may provide predicted luma samples inside the current block as padding samples for the cross-component filter, with the predicted luma samples generated using the luma intra prediction information of the merge candidate. Using padding samples for the cross-component filter is described by reference to e.g., FIGS 9-10 above.
[0164] The decoder selects (at block 1640) a unified merge candidate from the merge candidate list using the determined order based on the template costs. The decoder generates (at block 1650) a predictor of the current block based on the selected unified merge candidate. The decoder reconstructs (at block 1660) the current block by combining the generated predictor with prediction residuals. The decoder may then provide the reconstructed current block for output or display as part of the reconstructed current picture. VII. Example Electronic System
[0165] 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.
[0166] 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.
[0167] FIG. 17 conceptually illustrates an electronic system 1700 with which some embodiments of the present disclosure are implemented. The electronic system 1700 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 1700 includes a bus 1705, processing unit (s) 1710, a graphics-processing unit (GPU) 1715, a system memory 1720, a network 1725, a read-only memory 1730, a permanent storage device 1735, input devices 1740, and output devices 1745.
[0168] The bus 1705 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 1700. For instance, the bus 1705 communicatively connects the processing unit (s) 1710 with the GPU 1715, the read-only memory 1730, the system memory 1720, and the permanent storage device 1735.
[0169] From these various memory units, the processing unit (s) 1710 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 1715. The GPU 1715 can offload various computations or complement the image processing provided by the processing unit (s) 1710.
[0170] The read-only-memory (ROM) 1730 stores static data and instructions that are used by the processing unit (s) 1710 and other modules of the electronic system. The permanent storage device 1735, 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 1700 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 1735.
[0171] 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 1735, the system memory 1720 is a read-and-write memory device. However, unlike storage device 1735, the system memory 1720 is a volatile read-and-write memory, such a random access memory. The system memory 1720 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 1720, the permanent storage device 1735, and / or the read-only memory 1730. 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) 1710 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.
[0172] The bus 1705 also connects to the input and output devices 1740 and 1745. The input devices 1740 enable the user to communicate information and select commands to the electronic system. The input devices 1740 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 1745 display images generated by the electronic system or otherwise output data. The output devices 1745 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.
[0173] Finally, as shown in FIG. 17, bus 1705 also couples electronic system 1700 to a network 1725 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 1700 may be used in conjunction with the present disclosure.
[0174] 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.
[0175] 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.
[0176] 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.
[0177] 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. 13 and FIG. 16) 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
[0178] 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.
[0179] 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.
[0180] 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. ”
[0181] 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
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;generating a merge candidate list having one or more unified merge candidates, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information;ordering the candidates according to template costs of the candidates that are calculated based on at least one neighboring template that is not immediately adjacent to the current block, wherein the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information;selecting a unified merge candidate from the merge candidate list using the determined ordering;generating a predictor of the current block based on the selected unified merge candidate; andencoding or decoding the current block by using the generated predictor.The method of claim 1, wherein the merge candidates are identified based on the one or more candidate positions relative to the current block.The method of claim 1, wherein:the luma intra prediction information comprises at least one of luma mode, intra prediction angular modes, combination weight, reference line, filter shape, and filter coefficients;the chroma intra prediction information comprises at least one of cross-component prediction mode, model coefficients, and multi-model flag.The method of claim 1, wherein the template cost is a combination of luma template cost and chroma template cost, wherein the luma template cost is a difference value between luma reconstruction samples and luma prediction samples of the template, wherein the chroma template cost is a difference value between chroma reconstruction samples and chroma prediction samples of the template.The method of claim 4, wherein the template cost is based on a weighted sum of the luma template cost and the chroma template cost.The method of claim 4, wherein the luma and chroma template costs are computed based on luma and chroma neighboring templates comprising lines immediately adjacent to the current block.The method of claim 4, wherein the luma and chroma template costs are computed based on luma and chroma neighboring templates comprising lines close to the current block but no line immediately adjacent to the current block.The method of claim 4, wherein the luma and chroma template costs are computed based on a luma neighboring template comprising lines immediately adjacent to the current block and a chroma neighboring template comprising lines that are close to the current block but no line immediately adjacent to the current block.The method of claim of claim 1, wherein the predicted samples of the template comprises predicted chroma samples that are generated by applying a cross-component filter to luma samples in the template.The method of claim 9, further comprising providing reconstructed luma samples outside the current block as padding samples for the cross-component filter when the cross-component filter overlaps positions within the current block.The method of claim 9, further comprising providing predicted luma samples inside the current block as padding samples for the cross-component filter when the cross-component filter overlaps positions within the current block, wherein the predicted luma samples are generated using the luma intra prediction information of the merge candidate.The method of claim 1, wherein the at least one template comprises a top template and a left template, wherein the ordering of the merge candidates is not performed when the top template or the left template is not available.The method of claim 1, wherein the reconstructed samples and the predicted samples of the template used to calculate the template cost are taken from a selected subset of sample positions of the template.The method of claim 1, wherein the template cost is calculated based on a difference metric that is selected from a plurality of difference metrics based on explicit signaling.The method of claim 1, wherein the template cost is calculated based on a difference metric that is selected from a plurality of difference metrics based on a geometric property of the current block or a statistical property of the samples in the template.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;generating a merge candidate list having one or more unified merge candidates, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information;ordering the candidates according to template costs of the candidates that are calculated based on at least one neighboring template that is not immediately adjacent to the current block, wherein the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information;selecting a unified merge candidate from the merge candidate list using the determined ordering;generating a predictor of the current block based on the selected unified merge candidate; andencoding or decoding the current block by using the generated predictor.A video decoding method comprising:receiving data to be decoded as a current block of pixels of a current picture of a video;generating a merge candidate list having one or more unified merge candidates, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information;ordering the candidates according to template costs of the candidates that are calculated based on at least one neighboring template that is not immediately adjacent to the current block, wherein the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information;selecting a unified merge candidate from the merge candidate list using the determined ordering;generating a predictor of the current block based on the selected unified merge candidate; andreconstructing the current block by using the generated predictor; andoutputting the reconstructed current block.A video encoding method comprising:receiving data to be encoded as a current block of pixels of a current picture of a video;generating a merge candidate list having one or more unified merge candidates, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information;ordering the candidates according to template costs of the candidates that are calculated based on at least one neighboring template that is not immediately adjacent to the current block, wherein the template cost of each merge candidate is determined based on a difference between reconstructed samples of the template and predicted samples of the template generated using the merge candidate’s intra prediction information;selecting a unified merge candidate from the merge candidate list using the determined ordering;generating a predictor of the current block based on the selected unified merge candidate; andencoding the current block by using the generated predictor.
Citation Information
Patent Citations
Method and apparatus for generating merge candidate list and nonvolatile computer readable storage medium
CN110784723A
Video encoding method and device, and video decoding method and device
CN115086678A
Intra Block Copy Merge List Simplification
US20200275093A1