Enabling conditions for unified intra merge mode

Abstract

A method for using unified intra merge prediction (UIMP) mode to encode or decode pixel blocks in video pictures is provided. A video coder receives data to be encoded or decoded as a current block of pixels of a current picture of a video. The video coder checks whether to enable UIMP mode for the current block based on prediction mode information at one or more candidate positions relative to the current block. The video coder generates a predictor of the current block. When UIMP mode is enabled and when the current block is signaled to be coded by UIMP, the predictor is generated based on a unified merge candidate that is selected from a merge candidate list having one or more unified merge candidates, each unified merge candidate having luma intra prediction information and chroma intra prediction information. The video coder encodes or decodes the current block by using the generated predictor.

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,609, 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.

[0007] A CTU can be partitioned into one or multiple non-overlapped coding units (CUs) using the quadtree (QT) with nested multi-type-tree (MTT) structure to adapt to various local motion and texture characteristics. A CU can be further split into smaller CUs using one of the five split types: quad-tree partitioning, vertical binary tree partitioning, horizontal binary tree partitioning, vertical center-side triple-tree partitioning, horizontal center-side triple-tree partitioning.

[0008] 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. A transform unit (TU) is comprised of a transform block (TB) of luma samples and two corresponding transform blocks of chroma samples and each TB correspond to one residual block of samples from one color component. An integer transform is applied to a transform block. The level values of quantized coefficients together with other side information are entropy coded in the bitstream. The terms coding tree block (CTB) , coding block (CB) , prediction block (PB) , and transform block (TB) are defined to specify the 2-D sample array of one-color component associated with CTU, CU, PU, and TU, respectively. Thus, a CTU consists of one luma CTB, two chroma CTBs, and associated syntax elements. A similar relationship is valid for CU, PU, and TU.

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

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

[0011] Some embodiments of the disclosure provide a method for using unified intra merge prediction (UIMP) mode to encode or decode pixel blocks in video pictures. A video coder receives data to be encoded or decoded as a current block of pixels of a current picture of a video. The video coder checks whether to enable UIMP mode for the current block based on prediction mode information at one or more candidate positions relative to the current block. The video coder generates a predictor of the current block. When UIMP mode is enabled and when the current block is signaled to be coded by UIMP, the predictor is generated based on a unified merge candidate that is selected from a merge candidate list having one or more unified merge candidates, each unified merge candidate having luma intra prediction information and chroma intra prediction information. The video coder encodes or decodes the current block by using the generated predictor.

[0012] In some embodiments, the enabling condition for UIMP is checked based on prediction mode information at one or more candidate positions relative to the current block, by determining e.g., whether M out of N candidate positions are coded in at least one mode of a set of target modes. The set of target modes may include a union of all or a subset of luma prediction modes that are supported in UIMP mode, all or a subset of chroma prediction modes that are supported in UIMP mode, and UIMP. The one or more candidate positions relative to the current block may include positions adjacent to the current block or positions of one or more neighboring blocks of the current block. In some embodiments, the one or more candidate positions may also include positions that are not adjacent to the current block.

[0013] In some embodiments, whether to enable UIMP for current slice or picture is determined based on a high-level syntax in a bitstream, or based on a percentage of blocks or areas coded in a mode that is among the set of target modes in a previously coded slice or picture. In some embodiments, when the percentage is lower than a threshold and the previously coded picture is the first picture in a temporal layer as the current picture, UIMP is disabled for all pictures in the temporal layer. In some embodiments, when the percentage is lower than a threshold, mode information of neighboring blocks are checked to determine whether UIMP is enabled for the current block.

[0014] In some embodiment, the previously coded slice or picture is the slice or picture that is in the same temporal layer as the current slice or picture and is coded right before the current slice or picture and whether to enable UIMP mode is checked picture-by-picture or slice-by-slice.

[0015] In some embodiments, the decoder determines whether to check the enabling conditions for UIMP. The determination may be based on high-level syntax elements defined in SPS, PPS, PH, or SH, or current picture / slice type, current temporal identifier of current picture  / slice, or NAL unit type of the current picture / slice, based on whether these syntax elements equal to a target value.

[0016] In some embodiments, when luma and chroma prediction information associated with a neighboring block at a candidate position specifies luma and chroma prediction modes that are supported in UIMP mode, the luma and chroma intra prediction information are allowed or eligible to be added to the merge candidate list as a unified merge candidate.

[0017] In some embodiments, the supported luma prediction modes for the current block comprise intra prediction modes that uses reference samples in the current picture to generate intra prediction for the luma samples of the current block, modes such as angular intra prediction modes, DIMD, TIMD, TMRL, EIP, etc. The supported chroma prediction modes for the current bock may include cross-component prediction modes such as CCCM, CCLM, MMLM, GLM, etc. The luma intra prediction information may include at least one of luma mode, intra prediction angular modes, combination weight, reference line, EIP filter shape, EIP filter coefficients, etc. The chroma intra prediction information may include at least one of cross-component prediction mode, model coefficients, and multi-model flag.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0019] FIG. 1 illustrates 67 intra predictions modes, including 65 directional or angular intra prediction modes.

[0020] FIG. 2 shows the template area and the reference lines for the template-based multiple reference line intra prediction.

[0021] FIG. 3 illustrates the candidate positions of spatial merge candidates neighboring a current block.

[0022] FIG. 4 illustrates a scaled motion vector for temporal merge candidate.

[0023] FIG. 5 illustrates candidate positions for temporal merge candidate.

[0024] FIG. 6 illustrates spatial neighboring blocks that are used to derive spatial merge candidates.

[0025] FIG. 7 illustrates neighboring positions that are used to determine whether to enable unified intra merge prediction (UIMP) mode.

[0026] FIG. 8 illustrates an example video encoder that may UIMP mode.

[0027] FIG. 9 illustrates portions of the video encoder that implement UIMP.

[0028] FIG. 10 conceptually illustrates a process that uses UIMP to encode a block of pixels.

[0029] FIG. 11 illustrates an example video decoder that may implement UIMP.

[0030] FIG. 12 illustrates portions of the video decoder that implement UIMP.

[0031] FIG. 13 conceptually illustrates a process that uses UIMP to decode a block of pixels.

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

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

[0034] A. Directional Modes

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

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

[0037] B. Decoder Side Intra Mode Derivation (DIMD)

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

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

[0040] C. Template-based Intra Mode Derivation (TIMD)

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

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

[0043] D. Extrapolation Filter-based Intra Prediction (EIP) mode

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

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

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

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

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

[0049] E. Template-based Multiple Reference Line Intra Prediction (TMRL)

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

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

[0052] A. Cross-Component Linear Model Prediction (CCLM)

[0053] 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) + β

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

[0055] B. Multiple Model CCLM

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

[0057] C. Convolutional Cross-Component Model (CCCM)

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

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

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

[0061] That is, for 10-bit content it is calculated as: P = (C*C + 512) >> 10

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

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

[0064] D. Gradient Linear Model (GLM)

[0065] 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 + β

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

[0067] The following sections describes candidate positions relative to the current block for generating merge mode candidates.

[0068] A. Spatial Candidates Derivation

[0069] FIG. 3 illustrates the candidate positions of spatial merge candidates neighboring a current block 300, specifically A0, A1, B2, B0, and B1.

[0070] B. Temporal Candidates Derivation

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

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

[0073] C. Non-Adjacent Spatial Candidate

[0074] 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)

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

[0076] 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) .

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

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

[0079] A. Position / Block Settings of Candidates for UIMP

[0080] Spatial Candidates

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

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

[0083] Temporal candidates

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

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

[0086] B. Retrieving Joint Intra prediction information from candidates

[0087] In one embodiment, 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.

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

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

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

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

[0092] C. Reordering the Merge List for UIMP

[0093] 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 is a difference metric between reconstruction samples and prediction samples in the neighboring templates of the current block. The prediction samples are generated by utilizing the jointIntraInfo of a 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.

[0094] 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, the reordering is only based on the luma template cost. In some embodiments, the reordering is only based on the chroma template cost.

[0095] D. Syntax Setting for UIMP

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

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

[0098] E. Enabling Conditions of UIMP

[0099] In some embodiments, whether to enable UIMP for the current block is determined based on the prediction mode information (e.g., jointIntraInfo) of neighboring blocks, or neighboring adjacent positions, or non-adjacent positions.

[0100] In some embodiments, for a set of N positions defined with respect to the current block, if M out of N positions are coded in a mode that is among a set of target modes, UIMP is enabled to be used for the current block. And the syntax indicating whether the current block is coded in unified intra merge mode and related syntax are signaled. Otherwise, if the unified intra merge mode is disabled for the current block, no syntax needs to be signaled to indicate whether the current block is coded in unified intra merge mode. In some embodiments, N can be 1, 2, 3, 4, ..., M can be 1, 2, 3, 4, …, and M ≦ N, e.g., (M, N) = (1, 2) , (M, N) = (1, 4) , etc. For example, when (M, N) = (2, 4) , then if at least 2 of the 4 designated or specific neighboring positions is coded in a mode among the set of target modes, UIMP is enabled for the current block.

[0101] FIG. 7 illustrates neighboring positions that are used to determine whether to enable UIMP mode. The figure illustrates several neighboring positions, including A1, A2, A3, B1, B2, and B3, of a current block 700. For example, if (M, N) = (1, 2) , the designated four neighboring positions may be {A1, B1} or {A3, B3} , etc. For example, if (M, N) = (1, 4) , the designated four neighboring positions may be {A2, A3, B2, B3} or {A1, A3, B1, B3} , and if at least one position out of the four designated neighboring position is coded in a mode among the set of target modes, then UIMP is enabled for the current block 700. For another example, if (M, N) = (2, 4) , and if the designated four neighboring positions of the current block are {A1, A2, A3, B1} , and if at least two positions out of the four designated positions are coded in a mode among the set of target modes, then UIMP is enabled for the current block 700.

[0102] In some embodiments, the set of target modes can be the same as the union of the allowed or supported intra luma prediction modes, allowed or supported intra chroma prediction modes, and unified intra merge mode. In some embodiments, the set of target modes can be the same as the union of the allowed or supported intra luma prediction modes and unified intra merge mode. In some embodiments, the set of target modes can be the same as the union of allowed or supported intra chroma prediction modes, and unified intra merge mode. In some embodiments, the set of target modes can be the union of a subset of the allowed or supported intra luma prediction modes, a subset of the allowed or supported intra chroma prediction modes, and unified intra merge mode.

[0103] In some embodiments, whether to enable unified intra merge mode for the current slice / picture is determined based on a high-level syntax. A syntax can be signaled in SPS, PPS, PH, or SH to indicate whether unified intra merge mode is enabled for the current slice / picture. For example, if the syntax is equal to a target value (e.g., true or false) , the unified intra merge mode is not allowed for the current picture / slice. When the syntax is not present, the unified intra merge mode is not allowed.

[0104] In some embodiments, whether to enable unified intra merge mode for the current slice / picture is determined based on the percentage (for example, in format of %, ratio, or any other type of percentage) of blocks or areas coded in a mode among the set of target modes in a previously coded slice / picture. If the percentage is higher than a threshold, unified intra merge mode is enabled for the current slice / picture. Otherwise, the unified intra merge mode is disabled.

[0105] In some embodiments, the previously coded picture is the first coded picture in the same temporal layer as the current slice / picture. Hence, if the percentage of blocks or areas coded in a mode among the set of target modes in the first picture in a temporal layer is smaller than a threshold, unified intra merge mode is disabled for all pictures in that temporal layer.

[0106] In some embodiments, the previously coded slice / picture is the slice / picture that is in the same temporal layer as the current slice / picture and is coded right before the current slice / picture. Hence, the decision of enabling or disabling unified intra merge mode is determine picture by picture (or slice by slice) . In some embodiments, if the percentage of blocks or areas coded in a mode among the set of target modes in a previously coded slice / picture is lower than a threshold, the mode information (e.g., jointIntraInfo) of neighboring blocks is checked to determine whether to enable unified intra merge mode for the current block.

[0107] In some embodiments, whether to check the enabling conditions of unified intra merge mode is based on a high-level syntax defined in SPS, PPS, PH, or SH. For example, if the syntax is equal to a target value (e.g., true or false) , the enabling conditions of unified intra merge mode is checked. Otherwise, the enabling conditions of unified intra merge mode is not checked.

[0108] In some embodiments, whether to check the enabling conditions of unified intra merge mode can depend on the current picture / slice type, the current temporal identifier of the current picture / slice, or the NAL unit type of the current picture / slice. For example, if the current temporal identifier is greater than or equal to a threshold, the enabling conditions of unified intra merge mode is checked or not checked. For another example, if the NAL unit type of the current picture / slice is equal to a target value (e.g., TRAIL, STSA, RADL, or RASL unit type as defined in HEVC / VVC standard) , the enabling conditions of unified intra merge mode is checked or not checked. For another example, if the current temporal identifier is equal to a first target value and the NAL unit type of the current picture / slice is equal to a second target value, the enabling conditions of unified intra merge mode is checked or not checked.

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

[0110] FIG. 8 illustrates an example video encoder 800 that may implement unified intra merge mode prediction (UIMP) . As illustrated, the video encoder 800 receives input video signal from a video source 805 and encodes the signal into bitstream 895. The video encoder 800 has several components or modules for encoding the signal from the video source 805, at least including some components selected from a transform module 810, a quantization module 811, an inverse quantization module 814, an inverse transform module 815, an intra estimation module 824, an intra prediction module 825, a motion compensation module 830, a motion estimation module 835, an in-loop filter 845, a reconstructed picture buffer 850, a MV buffer 865, and a MV prediction module 875, and an entropy encoder 890. The motion compensation module 830 and the motion estimation module 835 are part of an inter-prediction module 840. The intra-prediction module 825 and the intra-estimation module 824 are part of a current picture prediction module 820, which uses current picture reconstructed samples as reference samples for prediction of the current block.

[0111] In some embodiments, the modules 810 –890 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 810 –890 are modules of hardware circuits implemented by one or more integrated circuits (ICs) of an electronic apparatus. Though the modules 810 –890 are illustrated as being separate modules, some of the modules can be combined into a single module.

[0112] The video source 805 provides a raw video signal that presents pixel data of each video frame without compression. A subtractor 808 computes the difference between the raw video pixel data of the video source 805 and the predicted pixel data 813 from the motion compensation module 830 or intra-prediction module 825 as prediction residual 809. The transform module 810 converts the difference (or the residual pixel data or residual signal 808) into transform coefficients (e.g., by performing Discrete Cosine Transform, or DCT) . The quantization module 811 quantizes the transform coefficients into quantized data (or quantized coefficients) 812, which is encoded into the bitstream 895 by the entropy encoder 890.

[0113] The inverse quantization module 814 de-quantizes the quantized data (or quantized coefficients) 812 to obtain transform coefficients 818, and the inverse transform module 815 performs inverse transform on the transform coefficients 818 to produce reconstructed residual 819. The reconstructed residual 819 is added with the predicted pixel data 813 to produce reconstructed pixel data 817. In some embodiments, the reconstructed pixel data 817 is temporarily stored in a line buffer 827 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction. The reconstructed pixels are filtered by the in-loop filter 845 and stored in the reconstructed picture buffer 850. In some embodiments, the reconstructed picture buffer 850 is a storage external to the video encoder 800. In some embodiments, the reconstructed picture buffer 850 is a storage internal to the video encoder 800.

[0114] The intra estimation module 824 derives intra-prediction data (e.g., intra prediction modes) based on the reconstructed pixel data 817 (stored in the line buffer 827) . The intra-prediction data is provided to the entropy encoder 890 to be encoded into bitstream 895. The intra-prediction data is also used by the intra-prediction module 825 to produce the predicted pixel data 813.

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

[0116] Instead of encoding the complete actual MVs in the bitstream, the video encoder 800 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 895.

[0117] The MV prediction module 875 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 875 retrieves reference MVs from previous video frames from the MV buffer 865. The video encoder 800 stores the MVs generated for the current video frame in the MV buffer 865 as reference MVs for generating predicted MVs.

[0118] The MV prediction module 875 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 895 by the entropy encoder 890.

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

[0120] The in-loop filter 845 performs filtering or smoothing operations on the reconstructed pixel data 817 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 845 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.

[0121] FIG. 9 illustrates portions of the video encoder 800 that implement unified intra merge mode prediction (UIMP) . In some embodiments, the UIMP predictor for the current block is generated by the intra prediction module 825, while several other components of the video encoder 800 provide the UIMP merge candidates and determine the enabling conditions for UIMP.

[0122] As illustrated, a prediction history storage 910 stores prediction history of coded blocks. The prediction history storage 910 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…)

[0123] A merge candidate generation module 920 generates one or more merge candidate list for the current block based on information stored in the prediction history storage 910 for candidate positions relative to the current block, including neighboring blocks, adjacent positions, and some non-adjacent positions.

[0124] A UIMP enable module 925 determines whether UIMP is enabled for the current block, slice, or picture based on the prediction mode information at one or more candidate positions relative to the current block. Section IV. E above describes various conditions for enabling UIMP mode in some embodiments, such by determining whether M out of N candidate positions are coded in at least one mode of a set of target modes. Whether UIMP mode is enabled and whether to check UIMP enabling conditions may be determined by syntax elements coded in the bitstream 895.

[0125] When UIMP is enabled, further signaling (from e.g., entropy encoder 890) would determine whether the current block is to be encoded using UIMP. (In some embodiments, UIMP related signaling would not be signaled if UIMP is not enabled) . If UIMP is used to encode the current block, the merge candidate generation module 920 generates one or more UIMP candidates to be included in or into a merge list 930 or a UIMP merge list 935, based on chroma and luma intra prediction information stored in the storage 910 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 927 only when the luma and chroma prediction information specifies luma and chroma prediction modes that are supported in UIMP mode.

[0126] The intra prediction module 825 generates a predictor 950 for the current block based on a merge candidate 940 selected from the merge list 930 or 935. The intra prediction module 825 may receive the selection of a merge candidate from the intra estimation module 824, which may provide the selection to the entropy encoder to be included in the bitstream 895 as syntax elements. The intra prediction module 825 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 827 and the reconstructed picture buffer 850. 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 940. The prediction is used to generate the predictor 950, which is provided to the video encoder as the predicted pixel data 813.

[0127] FIG. 10 conceptually illustrates a process 1000 that uses UIMP to encode a block of pixels. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the encoder 800 performs the process 1000 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the encoder 800 performs the process 1000.

[0128] The encoder receives (at block 1010) data to be encoded as a current block of pixels in a current picture. The encoder checks (at block 1020) the enabling condition for unified intra merge mode prediction (UIMP) for the current block. If UIMP is enabled, the process proceeds to block 1025. If UIMP is not enabled, the process proceeds to block 1035 to be coded without using UIMP.

[0129] In some embodiments, the enabling condition for UIMP is checked based on prediction mode information at one or more candidate positions relative to the current block, by determining e.g., whether M out of N candidate positions are coded in at least one mode of a set of target modes. The set of target modes may include a union of all or a subset of luma prediction modes that are supported in UIMP mode, all or a subset of chroma prediction modes that are supported in UIMP mode, and UIMP. The one or more candidate positions relative to the current block may include positions adjacent to the current block or positions of one or more neighboring blocks of the current block. In some embodiments, the one or more candidate positions may also include positions that are not adjacent to the current block. Examples of the candidate positions for the merge mode are described in Section III above.

[0130] In some embodiments, whether to enable UIMP for current slice or picture is determined based on a high-level syntax in a bitstream, or based on a percentage of blocks or areas coded in a mode that is among the set of target modes in a previously coded slice or picture. The previously coded slice or picture may be the slice or picture that is in the same temporal layer as the current slice or picture and may be coded right before the current slice or picture. Hence, the decision of enabling or disabling UIMP mode may be determine picture by picture (or slice by slice) .

[0131] In some embodiments, when the percentage is lower than a threshold and the previously coded picture is the first picture in a temporal layer as the current picture, UIMP is disabled for all pictures in the temporal layer. In some embodiments, when the percentage is lower than a threshold, mode information of neighboring blocks are checked to determine whether UIMP is enabled for the current block.

[0132] In some embodiments, the encoder determines whether to check the enabling conditions for UIMP. The determination may be based on high-level syntax elements defined in SPS, PPS, PH, or SH, or current picture / slice type, current temporal identifier of current picture  / slice, or NAL unit type of the current picture / slice, based on whether these syntax elements equal to a target value.

[0133] The encoder determines (at block 1025) whether the current block is coded using UIMP. With UIMP enabled and allowed to be used for coding, whether the current block is coded in UIMP may be determined based on syntax elements signaled in the bitstream, which may be determined by rate distortion considerations. (In some embodiments, UIMP related signaling would not be signaled if UIMP is or is not enabled based on a predefined rule) . If the current block is coded using UIMP, the process proceeds to 1030. Otherwise, the process proceeds to 1035 to be encoded without using UIMP.

[0134] The encoder generates (at block 1030) a predictor of the current block based on a unified merge candidate that is selected from a merge candidate list. The merge candidate list may include one or more unified merge candidates, with each unified merge candidate having luma intra prediction information and chroma intra prediction information. In some embodiments, when luma and chroma prediction information associated with a neighboring block at a candidate position specifies luma and chroma prediction modes that are supported in UIMP mode, the luma and chroma intra prediction information are allowed or eligible to be added to the merge candidate list as a unified merge candidate.

[0135] In some embodiments, the supported luma prediction modes for the current block comprise intra prediction modes that uses reference samples in the current picture to generate intra prediction for the luma samples of the current block, modes such as angular intra prediction modes, DIMD, TIMD, TMRL, EIP, etc. The supported chroma prediction modes for the current bock may include cross-component prediction modes such as CCCM, CCLM, MMLM, GLM, etc. The luma intra prediction information may include at least one of luma mode, intra prediction angular modes, combination weight, reference line, EIP filter shape, EIP filter coefficients, etc. The chroma intra prediction information may include at least one of cross-component prediction mode, model coefficients, and multi-model flag.

[0136] At block 1035, the encoder generates a predictor of the current block without using UIMP and then proceeds to block 1040.

[0137] At block 1040, the encoder encodes the current block by using the generated predictor to produce prediction residuals and to reconstruct the current block. VI. Example Video Decoder

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

[0139] FIG. 11 illustrates an example video decoder 1100 that may implement unified intra merge mode prediction (UIMP) . As illustrated, the video decoder 1100 is an image-decoding or video-decoding circuit that receives a bitstream 1195 and decodes the content of the bitstream into pixel data of video frames for display. The video decoder 1100 has several components or modules for decoding the bitstream 1195, including some components selected from an inverse quantization module 1114, an inverse transform module 1115, an intra-prediction module 1125, a motion compensation module 1130, an in-loop filter 1145, a decoded picture buffer 1150, a MV buffer 1165, a MV prediction module 1175, and a parser 1190. The motion compensation module 1130 is part of an inter-prediction module 1140. The intra-prediction module 1125 is part of a current picture prediction module 1120, which uses current picture reconstructed samples as reference samples for prediction of the current block.

[0140] In some embodiments, the modules 1114 –1190 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 1114 –1190 are modules of hardware circuits implemented by one or more ICs of an electronic apparatus. Though the modules 1114 –1190 are illustrated as being separate modules, some of the modules can be combined into a single module.

[0141] The parser 1190 (or entropy decoder) receives the bitstream 1195 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) 1112. The parser 1190 parses out the various syntax elements by using entropy-coding techniques such as context-adaptive binary arithmetic coding (CABAC) or Huffman encoding.

[0142] The inverse quantization module 1114 de-quantizes the quantized data (or quantized coefficients) 1112 to obtain transform coefficients, and the inverse transform module 1115 performs inverse transform on the transform coefficients 1118 to produce reconstructed residual signal 1119. The reconstructed residual signal 1119 is added with predicted pixel data 1113 from the intra-prediction module 1125 or the motion compensation module 1130 to produce decoded pixel data 1117. The decoded pixels data are filtered by the in-loop filter 1145 and stored in the decoded picture buffer 1150. In some embodiments, the decoded picture buffer 1150 is a storage external to the video decoder 1100. In some embodiments, the decoded picture buffer 1150 is a storage internal to the video decoder 1100.

[0143] The intra-prediction module 1125 receives intra-prediction data from bitstream 1195 and according to which, produces the predicted pixel data 1113 from the decoded pixel data 1117 stored in the decoded picture buffer 1150. In some embodiments, the decoded pixel data 1117 is also stored in a line buffer 1127 (or intra prediction buffer) for intra-picture prediction and spatial MV prediction.

[0144] In some embodiments, the content of the decoded picture buffer 1150 is used for display. A display device 1105 either retrieves the content of the decoded picture buffer 1150 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 1150 through a pixel transport.

[0145] The motion compensation module 1130 produces predicted pixel data 1113 from the decoded pixel data 1117 stored in the decoded picture buffer 1150 according to motion compensation MVs (MC MVs) . These motion compensation MVs are decoded by adding the residual motion data received from the bitstream 1195 with predicted MVs received from the MV prediction module 1175.

[0146] The MV prediction module 1175 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 1175 retrieves the reference MVs of previous video frames from the MV buffer 1165. The video decoder 1100 stores the motion compensation MVs generated for decoding the current video frame in the MV buffer 1165 as reference MVs for producing predicted MVs.

[0147] The in-loop filter 1145 performs filtering or smoothing operations on the decoded 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.

[0148] FIG. 12 illustrates portions of the video decoder 1100 that implement unified intra merge mode prediction (UIMP) . 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 decoder 1100 provide the UIMP merge candidates and determine the enabling conditions for UIMP.

[0149] 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…)

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

[0151] A UIMP enable module 1225 determines whether UIMP is enabled for the current block, slice, or picture based on the prediction mode information at one or more candidate positions relative to the current block. Section IV. E above describes various conditions for enabling UIMP mode in some embodiments, such by determining whether M out of N candidate positions are coded in at least one mode of a set of target modes. Whether UIMP mode is enabled and whether to check UIMP enabling conditions may be determined by syntax elements coded in the bitstream 1195.

[0152] When UIMP is enabled, further signaling (from e.g., entropy decoder 1190 parsing the bitstream 1195) would indicate whether the current block is coded using UIMP. (In some embodiments, UIMP related signaling would not be signaled if UIMP is or is not enabled based on a predefined rule) . If the current block is coded by UIMP, 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 in UIMP mode.

[0153] 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 decoder 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 decoder as the predicted pixel data 1113.

[0154] FIG. 13 conceptually illustrates a process 1300 that uses UIMP to decode a block of pixels. In some embodiments, one or more processing units (e.g., a processor) of a computing device implementing the decoder 1100 performs the process 1300 by executing instructions stored in a computer readable medium. In some embodiments, an electronic apparatus implementing the decoder 1100 performs the process 1300.

[0155] The decoder receives (at block 1310) data to be decoded as a current block of pixels in a current picture. The decoder checks (at block 1320) the enabling condition for unified intra merge mode prediction (UIMP) for the current block. If UIMP is enabled, the process proceeds to block 1325. If UIMP is not enabled, the process proceeds to block 1335 to be coded without using UIMP.

[0156] In some embodiments, the enabling condition for UIMP is checked based on prediction mode information at one or more candidate positions relative to the current block, by determining e.g., whether M out of N candidate positions are coded in at least one mode of a set of target modes. The set of target modes may include a union of all or a subset of luma prediction modes that are supported in UIMP mode, all or a subset of chroma prediction modes that are supported in UIMP mode, and UIMP. The one or more candidate positions relative to the current block may include positions adjacent to the current block or positions of one or more neighboring blocks of the current block. In some embodiments, the one or more candidate positions may also include positions that are not adjacent to the current block. Examples of the candidate positions for the merge mode are described in Section III above.

[0157] In some embodiments, whether to enable UIMP for current slice or picture is determined based on a high-level syntax in a bitstream, or based on a percentage of blocks or areas coded in a mode that is among the set of target modes in a previously coded slice or picture. The previously coded slice or picture may be the slice or picture that is in the same temporal layer as the current slice or picture and may be coded right before the current slice or picture. Hence, the decision of enabling or disabling UIMP mode may be determine picture by picture (or slice by slice) .

[0158] In some embodiments, when the percentage is lower than a threshold and the previously coded picture is the first picture in a temporal layer as the current picture, UIMP is disabled for all pictures in the temporal layer. In some embodiments, when the percentage is lower than a threshold, mode information of neighboring blocks are checked to determine whether UIMP is enabled for the current block.

[0159] In some embodiments, the decoder determines whether to check the enabling conditions for UIMP. The determination may be based on high-level syntax elements defined in SPS, PPS, PH, or SH, or current picture / slice type, current temporal identifier of current picture  / slice, or NAL unit type of the current picture / slice, based on whether these syntax elements equal to a target value.

[0160] The decoder determines (at block 1325) whether the current block is coded using UIMP. With UIMP enabled and allowed to be used for coding, whether the current block is coded in UIMP may be determined based on syntax elements signaled in the bitstream. (In some embodiments, UIMP related signaling would not be signaled if UIMP is not enabled) . If the current block is coded using UIMP, the process proceeds to 1330. Otherwise, the process proceeds to 1335 to be decoded without using UIMP.

[0161] The decoder generates (at block 1330) a predictor of the current block based on a unified merge candidate that is selected from a merge candidate list. The merge candidate list may include one or more unified merge candidates, with each unified merge candidate having luma intra prediction information and chroma intra prediction information. In some embodiments, when luma and chroma prediction information associated with a neighboring block at a candidate position specifies luma and chroma prediction modes that are supported in UIMP mode, the luma and chroma intra prediction information are allowed or eligible to be added to the merge candidate list as a unified merge candidate.

[0162] In some embodiments, the supported luma prediction modes for the current block comprise intra prediction modes that uses reference samples in the current picture to generate intra prediction for the luma samples of the current block, modes such as angular intra prediction modes, DIMD, TIMD, TMRL, EIP, etc. The supported chroma prediction modes for the current bock may include cross-component prediction modes such as CCCM, CCLM, MMLM, GLM, etc. The luma intra prediction information may include at least one of luma mode, intra prediction angular modes, combination weight, reference line, EIP filter shape, EIP filter coefficients, etc. The chroma intra prediction information may include at least one of cross-component prediction mode, model coefficients, and multi-model flag.

[0163] At block 1335, the decoder generates a predictor of the current block without using UIMP and then proceeds to block 1340.

[0164] At block 1340, the decoder reconstructs (at block 1340) the current block by using the generated predictor with the prediction residuals of the current block. 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. 14 conceptually illustrates an electronic system 1400 with which some embodiments of the present disclosure are implemented. The electronic system 1400 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 1400 includes a bus 1405, processing unit (s) 1410, a graphics-processing unit (GPU) 1415, a system memory 1420, a network 1425, a read-only memory 1430, a permanent storage device 1435, input devices 1440, and output devices 1445.

[0168] The bus 1405 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 1400. For instance, the bus 1405 communicatively connects the processing unit (s) 1410 with the GPU 1415, the read-only memory 1430, the system memory 1420, and the permanent storage device 1435.

[0169] From these various memory units, the processing unit (s) 1410 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 1415. The GPU 1415 can offload various computations or complement the image processing provided by the processing unit (s) 1410.

[0170] The read-only-memory (ROM) 1430 stores static data and instructions that are used by the processing unit (s) 1410 and other modules of the electronic system. The permanent storage device 1435, 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 1400 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 1435.

[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 1435, the system memory 1420 is a read-and-write memory device. However, unlike storage device 1435, the system memory 1420 is a volatile read-and-write memory, such a random access memory. The system memory 1420 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 1420, the permanent storage device 1435, and / or the read-only memory 1430. 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) 1410 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[0172] The bus 1405 also connects to the input and output devices 1440 and 1445. The input devices 1440 enable the user to communicate information and select commands to the electronic system. The input devices 1440 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 1445 display images generated by the electronic system or otherwise output data. The output devices 1445 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. 14, bus 1405 also couples electronic system 1400 to a network 1425 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 1400 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. 10 and FIG. 13) 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

1.A video coding method comprising:receiving data to be encoded or decoded as a current block of pixels of a current picture of a video;checking whether to enable unified intra merge prediction (UIMP) mode for the current block based on prediction mode information at one or more candidate positions relative to the current block;generating a predictor of the current block, wherein the predictor is generated based on a unified merge candidate that is selected from a merge candidate list having one or more unified merge candidates when UIMP mode is enabled, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information; andencoding or decoding the current block by using the generated predictor.2.The method of claim 1, wherein the one or more candidate positions relative to the current block comprises positions adjacent to the current block or positions of one or more neighboring blocks of the current block.3.The method of claim 1, wherein when luma and chroma prediction information associated with a neighboring block at a candidate position specifies luma and chroma prediction modes that are supported in UIMP mode, the luma and chroma intra prediction information are allowed to be added to the merge candidate list as a unified merge candidate.4.The method of claim 3, wherein the supported luma prediction modes in UIMP mode comprise intra prediction modes that uses reference samples in the current picture to generate intra prediction for the luma samples of the current block.5.The method of claim 3, wherein the supported chroma prediction modes in UIMP mode comprise cross-component prediction modes.6.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.7.The method of claim 1, wherein the chroma intra prediction information comprises at least one of cross-component prediction mode, model coefficients, and multi-model flag.8.The method of claim 1, wherein determining whether to enable UIMP mode comprises determining whether M out of N candidate positions are coded in at least one mode of a set of target modes.9.The method of claim 8, wherein the set of target modes comprise a union of all or a subset of luma prediction modes that are supported in UIMP mode, all or a subset of chroma prediction modes that are supported in UIMP mode, and UIMP.10.The method of claim 1, wherein whether to enable UIMP mode for current slice or picture is determined based on a high-level syntax in a bitstream.11.The method of claim 1, wherein whether to enable UIMP mode for the current slice or picture is determined based on a percentage of blocks or areas coded in a mode that is among a set of target modes in a previously coded slice or picture.12.The method of claim 11, wherein when the percentage is lower than a threshold and the previously coded slice or picture is the first slice or picture in a temporal layer as the current slice or picture, UIMP mode is disabled for all pictures or slices in the temporal layer.13.The method of claim 12, wherein the previously coded slice or picture is the slice or picture that is in the same temporal layer as the current slice or picture and is coded right before the current slice or picture.14.The method of claim 13, wherein whether to enable UIMP mode is checked picture-by-picture or slice-by-slice.15.The method of claim 11, wherein when the percentage is lower than a threshold, mode information of neighboring blocks are checked to determine whether UIMP mode is enabled for the current block.16.The method of claim 1, further comprising determining whether to check enabling conditions for UIMP mode.17.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;checking whether to enable unified intra merge prediction (UIMP) mode for the current block based on prediction mode information at one or more candidate positions relative to the current block;generating a predictor of the current block, wherein the predictor is generated based on a unified merge candidate that is selected from a merge candidate list having one or more unified merge candidates when UIMP mode is enabled, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information; andencoding or decoding the current block by using the generated predictor.18.A video decoding method comprising:receiving data to be decoded as a current block of pixels of a current picture of a video;checking whether to enable unified intra merge prediction (UIMP) mode for the current block based on prediction mode information at one or more candidate positions relative to the current block;generating a predictor of the current block, wherein the predictor is generated based on a unified merge candidate that is selected from a merge candidate list having one or more unified merge candidates when UIMP mode is enabled, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information;reconstructing the current block by using the generated predictor; andoutputting the reconstructed current block.19.A video encoding method comprising:receiving data to be encoded as a current block of pixels of a current picture of a video;checking whether to enable unified intra merge prediction (UIMP) mode for the current block based on prediction mode information at one or more candidate positions relative to the current block;generating a predictor of the current block, wherein the predictor is generated based on a unified merge candidate that is selected from a merge candidate list having one or more unified merge candidates when UIMP mode is enabled, wherein each unified merge candidate comprises luma intra prediction information and chroma intra prediction information; andencoding the current block by using the generated predictor.

Images