TWI838406B - Chroma mode intra coding - Google Patents

Abstract

Devices, systems and methods for digital video codecs, which includes chroma mode intra codecs, are described. In a representative aspect, a method for video processing includes determining, for a conversion between a current block of video data and a bitstream representation of the current block, a first codecmode for a chroma component of the current block based on at least one or more codecmodes of a block that is not adjacent to the current block. The method further includes performing, based on the first codecmode, the conversion between the bitstream representation and the current block.

Description

Chroma mode intra-frame encoding and decoding

This patent document relates to video encoding and decoding technology, equipment and system.

[Cross references to related applications]

This application is to timely claim the priority and benefits of the international patent application No. PCT/CN2018/107180 filed on September 24, 2018. The entire contents of the above patent application are incorporated by reference as part of the disclosure of this patent document.

Despite advances in video compression technology, digital video still accounts for the largest bandwidth usage on the Internet and other digital communications networks. As the number of connected user devices capable of receiving and displaying video increases, the demand for bandwidth used by digital video is expected to continue to grow.

Apparatus, systems and methods are described that are related to digital video coding, in particular intra-mode coding and chroma-mode coding of images and videos based on past (e.g., historical or statistical) information. The described methods can be applied to existing video codec standards (e.g., High Efficiency Video Coding (HEVC)) and future video codec standards (e.g., Versatile Video Coding (VVC)) or codecs.

In one representative aspect, the disclosed technology can be used to provide a method for video processing. The exemplary method includes: for a conversion between a current block of visual media data and a bitstream representation of the current block, selecting a first intra-frame prediction mode based on at least a first set of historical intra-frame encoding and decoding information including statistical information of a set of intra-frame prediction modes; and performing the conversion based on the first intra-frame prediction mode.

In another representative aspect, the disclosed technology can be used to provide a method for video processing. The example method includes: for a conversion between a current block of visual media data and a bitstream representation of the current block, selecting a first intra-frame prediction mode based at least on an intra-frame prediction mode associated with a non-neighbor of the current block. The method also includes performing the conversion based on the first intra-frame prediction mode.

In another representative aspect, the disclosed technology can be used to provide a method for video processing. The example method includes: for a conversion between a current block of visual media data and a bitstream representation of the current block, selecting an intra-frame prediction mode based on at least one of the spatially adjacent blocks of the current block; and performing the conversion based on the intra-frame prediction mode. At least one of the spatially adjacent blocks is different from a first block located to the left of a first column of the current block and a second block located above a first row of the current block.

In another representative aspect, the disclosed technology can be used to provide a method for video processing. The example method includes: generating a final prediction block for a conversion between a current block of visual media data and a bitstream representation of the current block; and performing the conversion based on the final prediction block. At least a portion of the final prediction block is generated based on a combination of a first prediction block and a second prediction block, wherein the first prediction block and the second prediction block are based on reconstructed samples from a picture segment including the current block.

In another representative aspect, the disclosed technology can be used to provide a method for video processing. The example method includes: during a conversion between a current block of visual media data and a bitstream representation of the current block, maintaining a first table of motion candidates; and determining motion information of the current block encoded and decoded using an intra-block copy (IBC) mode based at least on the first table of motion candidates, in which at least one motion vector points to a picture segment including the current block. The method also includes performing the conversion based on the motion information.

In one representative aspect, the disclosed technology can be used to provide a method for video processing. The example method for video processing includes: for a conversion between a current block of video data and a bitstream representation of the current block, determining a first codec mode for a chroma component of the current block based at least on one or more codec modes of blocks not adjacent to the current block. The method also includes performing the conversion between the bitstream representation and the current block based on the first codec mode.

In another representative aspect, the disclosed technology can be used to provide a method for video processing. The example method for video processing includes: for a bitstream representation of a chroma block and a conversion between the chroma block, determining an intra-frame encoding/decoding mode based on spatially adjacent blocks of a luminance block corresponding to the chroma block. The method also includes performing the conversion between the bitstream representation and the chroma block based on the intra-frame encoding/decoding mode.

In another representative aspect, the disclosed technology can be used to provide a method for video encoding and decoding. The example method for video encoding and decoding includes: for a bit stream representation of a current block of visual media data, selecting a first intra-frame prediction mode from an intra-frame prediction mode set based on a first set of past intra-frame encoding and decoding information; and processing the bit stream representation based on the first intra-frame prediction mode to generate the current block.

In another representative aspect, the disclosed technology can be used to provide a method for video encoding and decoding. The example method for video encoding and decoding includes: for a bit stream representation of a current block of visual media data, selecting an intra-frame prediction mode from at least one of spatially adjacent blocks that are adjacent or non-adjacent to the current block; and processing the bit stream representation based on the intra-frame prediction mode to generate the current block.

In another representative aspect, the disclosed technology can be used to provide a method for video encoding and decoding. The example method for video encoding and decoding includes: for a bitstream representation of a current block of visual media data, generating a first prediction block and a second prediction block based on reconstructed samples from a picture segment including the current block; generating at least a portion of a final prediction block based on a linear function of the first prediction block and the second prediction block; and processing the bitstream representation based on the final prediction block to generate the current block.

In another representative aspect, the disclosed technology can be used to provide a method for video encoding and decoding. The example method of video encoding and decoding includes: for a bit stream representation of a current block including a luminance component and a chrominance component, selecting a first encoding and decoding mode of the chrominance component; and performing conversion between the bit stream representation and the current block based on the first encoding and decoding mode.

In another representative aspect, the disclosed technology can be used to provide a method for video encoding and decoding. The example method of video encoding and decoding includes: for a bit stream representation of a current block including a luminance component and a chrominance component, selecting an intra-frame encoding and decoding mode from a spatially adjacent block of the luminance component; adding the intra-frame encoding and decoding mode to a chrominance intra-frame mode list; and performing conversion between the bit stream representation and the current block based on the intra-frame encoding and decoding mode.

In another representative aspect, the above method is embodied in the form of processor executable code and stored in a computer readable program medium.

In yet another representative aspect, a device configured or operable to perform the above method is disclosed. The device may include a processor programmed to implement the method.

In yet another representative aspect, a video decoder device may implement the method as described herein.

The above and other aspects and features of the disclosed technology are described in more detail in the accompanying drawings, the specification and the patent application scope.

1400, 1500, 1600, 1900, 2000, 2100, 2200, 2300, 2400, 2500, 2600, 2700: Methods

1910, 1920, 2010, 2020, 2110, 2120, 2310, 2320, 2330, 2610, 2620, 2710, 2720: Operation

1410, 1420, 1510, 1520, 1610, 1620, 1630, 2210, 2220, 2410, 2420, 2510, 2520, 2530: Steps

1700:Device

1702: Processor

1704: Storage

1706: Video processing hardware

1800:System

1802: Input

1804, 1806, 1808: Components

1810: Display interface

Figure 1 shows an example of 67 intra-frame prediction patterns.

Figure 2 shows an example of neighboring blocks used for intra-frame mode prediction.

Figures 3A and 3B show examples of reference samples for the wide-angle intra-frame prediction mode for non-square blocks.

Figure 4 shows an example of discontinuity when using wide-angle in-frame prediction.

Figures 5A-5D show examples of samples used by the Position-Dependent Intra Prediction Combination (PDPC) method.

Figure 6 shows an example of the locations of sample points used to derive the weights of the linear model.

Figure 7 shows an example of classifying adjacent sample points into two groups.

Figure 8A shows an example of chrominance samples and their corresponding luminance samples.

Figure 8B shows an example of down-filtering for the Cross-Component Linear Model (CCLM) in the Joint Exploration Model (JEM).

Figures 9A and 9B show examples of chrominance blocks and their corresponding luminance blocks.

Figure 10 shows an example of the in-frame prediction mode with the default mode.

Figures 11A and 11B show examples of corresponding sub-blocks of the chroma CB.

Figure 12 shows an example of block replication within a frame.

Figures 13A-13F show examples of different neighboring blocks that may be selected for intra-frame mode encoding and decoding.

FIG14 shows a flow chart of an example method for intra-frame mode encoding and decoding based on past information according to the disclosed technology.

FIG15 shows a flow chart of another example method for intra-frame mode encoding and decoding based on past information according to the disclosed technology.

FIG16 shows a flow chart of another example method for intra-frame mode encoding and decoding based on past information according to the disclosed technology.

FIG. 17 is a block diagram of an example of a hardware platform for implementing the visual media decoding or visual media encoding techniques described in this document.

FIG. 18 is a block diagram of an example video processing system in which the disclosed technology may be implemented.

FIG19 shows a flow chart of an example method for video processing according to the disclosed technology.

FIG20 shows a flow chart of another example method for video processing according to the disclosed technology.

FIG21 shows a flow chart of another example method for video processing according to the disclosed technology.

FIG22 shows a flow chart of another example method for video processing according to the disclosed technology.

FIG23 shows a flow chart of another example method for video processing according to the disclosed technology.

FIG24 shows a flow chart of an example method for chroma mode encoding and decoding based on past information.

FIG25 shows a flowchart of another example method of chroma mode encoding and decoding based on past information.

FIG26 shows a flow chart of an example method for video processing according to the disclosed technology.

FIG27 shows a flow chart of another example method for video processing according to the disclosed technology.

Video codecs and techniques are ubiquitous in modern technology due to the growing demand for higher resolution video. Video codecs typically consist of electronic circuits or software that compress or decompress digital video and are constantly being improved to provide greater codec efficiency. Video codecs convert uncompressed video to a compressed format and vice versa. There is a complex relationship between video quality, the amount of data used to represent the video (determined by the bit rate), the complexity of the encoding and decoding algorithms, the sensitivity to data loss and errors, the ease of editing, random access, and end-to-end delay (latency). The compression format typically conforms to a standard video compression specification, such as the High Efficiency Video Codec (HEVC) standard (also known as H.265 or MPEG-H Part 2), the upcoming Versatile Video Codec (VVC), or other current and/or future video codec standards.

Embodiments of the disclosed technology can be applied to existing video codec standards (e.g., HEVC, H.265) and future standards to improve runtime performance. Section headings are used in this document to improve the readability of the description and do not in any way limit the discussion or embodiments (and/or implementation methods) to only the sections.

1 Example of intra-frame prediction in VVC

1.1 Intra-frame mode encoding and decoding with 67 intra-frame prediction modes

To capture arbitrary edge directions present in natural video, the number of directional intra modes is expanded from 33 as used in HEVC to 65. The additional directional modes are depicted as red dashed arrows in Figure 1, and the planar and DC modes remain unchanged. These denser directional intra prediction modes apply to all block sizes and to both luma intra prediction and chroma intra prediction.

As shown in Figure 1, the traditional angular intra-frame prediction direction is defined as from 45 degrees to -135 degrees in a clockwise direction. In VTM2, for non-square blocks, several traditional angular intra-frame prediction modes are adaptively replaced with wide-angle intra-frame prediction modes. The replaced modes are signaled using the original method and remapped to the index of the wide-angle mode after parsing. The total number of intra-frame prediction modes remains unchanged (e.g., 67), and the intra-frame mode encoding and decoding remains unchanged.

In HEVC, each intra-frame codec block has a square shape, and the length of each side is a power of 2. Therefore, no division operation is required to generate intra-frame prediction values using DC mode. In VTV2, blocks can have a rectangular shape, which generally requires a division operation for each block. To avoid division operations for DC prediction, only the longer side is used to calculate the average of non-square blocks.

1.2 Example of intra-frame mode encoding and decoding

In some embodiments, in order to keep the complexity of MPM list generation low, an intra-frame mode encoding and decoding method with 3 most probable modes (MPM) is used. The following three aspects are considered for the MPM list: -- neighboring intra-frame modes; -- derived intra-frame modes; and -- default intra-frame modes.

For adjacent intra-frame patterns (A and B), consider two adjacent blocks located on the left and top. The blocks on the left and top are those connected to the top left corner sample of the current block, as shown in Figure 2. An initial MPM list is formed by performing a pruning process on two adjacent intra-frame patterns. The pruning process is used to remove duplicate patterns so that only unique patterns can be included in the MPM list. If the two adjacent patterns are different from each other, one of the default patterns (e.g., PLANA (0), DC (1), ANGULAR50 (e.g., 50)) is added to the MPM list after pruning checks with the existing two MPMs. When the two adjacent patterns are the same, the default pattern or the derived pattern is added to the MPM list after pruning checks. The detailed generation process of the three MPM lists is derived as follows: If two adjacent candidate modes are the same (i.e., A==B), if A is less than 2, then candModeList[3]={0,1,50}.

Otherwise, candModeList[0]={A,2+((A+61)% 64),2+((A-1)% 64)}

Otherwise, if neither A nor B is equal to 0, candModeList[3]={A,B,0}.

Otherwise, if neither A nor B is equal to 1, candModeList[3]={A,B,1}.

Otherwise, candModeList[3]={A,B,50}.

An additional pruning process is used to remove duplicate patterns so that only unique patterns can be included in the MPM list. For entropy encoding and decoding of the 64 non-MPM patterns, a 6-bit Fixed Length Code (FLC) is used.

1.3 Wide-angle frame prediction for non-square blocks

In some embodiments, the traditional angular intra-frame prediction direction is defined as from 45 degrees to -135 degrees in a clockwise direction. In VTM2, for non-square blocks, several traditional angular intra-frame prediction modes are adaptively replaced with wide-angle intra-frame prediction modes. The replaced modes are signaled using the original method and remapped to the index of the wide-angle mode after parsing. The total number of intra-frame prediction modes for a block remains unchanged, for example 67, and the intra-frame mode encoding and decoding remains unchanged.

To support these prediction directions, an upper reference of length 2W+1 and a left reference of length 2H+1 are defined as shown in the examples in Figures 3A and 3B.

In some embodiments, the mode number of the replaced mode in the wide angle direction mode depends on the aspect ratio of the block. The replaced intra-frame prediction modes are shown in Table 1.

As shown in Figure 4, in the case of wide-angle intra-frame prediction, two vertically adjacent prediction samples can use two non-adjacent reference samples. Therefore, low-pass reference sample filtering and side smoothing are applied to wide-angle prediction to reduce the negative impact of the increased gap Δp _α .

1.4 Example of Position-Based Prediction Combination (PDPC)

In VTM2, the results of intra prediction for planar mode are further modified by the Position-Based Intra Prediction Combination (PDPC) method. PDPC is an intra prediction method that calls for a combination of unfiltered boundary reference samples and HEVC-style intra prediction with filtered boundary reference samples. PDPC is applied to the following intra modes without signaling: planar mode, DC mode, horizontal mode, vertical mode, bottom left angle mode and its eight neighboring angle modes, and top right angle mode and its eight neighboring angle modes.

The prediction sample pred(x,y) is predicted using the linear combination of the intra-frame prediction mode (DC, planar, angular) and the reference sample according to the following equation: pred(x,y)=(wL×R _-1,y +wT×R _x,-1 -wTL×R _-1,-1 +(64-wL-wT+wTL)×pred(x,y)+32)>>shift

Herein, R _x,-1 , R _-1,y represent reference samples located above and to the left of the current sample (x, y), respectively, and R _-1,-1 represents a reference sample located at the upper left corner of the current block.

In some embodiments, if PDPC is applied to DC mode, planar mode, horizontal mode, and vertical mode, no additional boundary filtering is required, such as DC mode boundary filtering or horizontal/vertical mode edge filtering required in the case of HEVC.

5A-5D show the definition of reference samples (R _x,-1 , R _-1,y and R _-1,-1 ) of PDPC applied on various prediction modes. The prediction sample pred(x',y') is located at (x',y') within the prediction block. The coordinate x of the reference sample R _x,-1 is given by x=x'+y'+1, and the coordinate y of the reference sample R _-1,y is similarly given by y=x'+y'+1.

In some embodiments, the PDPC weights depend on the prediction mode and are shown in Table 2, where S=shift.

1.5 Chroma encoding and decoding example

In HEVC chroma encoding and decoding, five modes are allowed for chroma blocks (including one direct mode (DM) and four default modes, where the direct mode is the intra-frame prediction mode from the corresponding luma block in the upper left corner). The two color components share the same intra-frame prediction mode.

In some embodiments, different from the design in HEVC, two new methods have been proposed, including: Cross-Component Linear Model (CCLM) prediction mode and multi-DM.

1.5.1 Example of Cross-Component Linear Model (CCLM)

In some embodiments, to reduce cross-component redundancy, a cross-component linear model (CCLM) prediction mode (also referred to as LM) is used in JEM, where CCLM predicts chrominance samples based on reconstructed luma samples of the same CU using the following linear model: pred _C (i, j) = α. rec _L ' (i, j) + β (1)

Here, pred _C (i, j) represents the predicted chroma samples in the CU, and for color format 4:2:0 or 4:2:2, rec _L ' (i, j) represents the downsampled reconstructed luma samples of the same CU, while for color format 4:4:4, rec _L ' (i, j) represents the reconstructed luma samples of the same CU. The CCLM parameters α and β are derived by minimizing the regression error between neighboring reconstructed luma and chroma samples around the current block as follows:

as well as

Here, L(n) represents the downsampled (for color format 4:2:0 or 4:2:2) or original (for color format 4:4:4) upper and left adjacent reconstructed luma samples, C(n) represents the upper and left adjacent reconstructed chroma samples, and the value of N is equal to twice the minimum of the width and height of the current chroma codec block.

In some embodiments, for a square-shaped codec block, the above two equations are directly applied. In other embodiments, for a non-square codec block, the adjacent samples of the longer boundary are first sub-sampled to have the same number of samples as the shorter boundary. Figure 6 shows the positions of the left and top reconstruction samples and the samples of the current block involved in the CCLM mode.

In some embodiments, the regression error minimization calculation is performed as part of the decoding process, rather than just as an encoder search operation, so no syntax is used to communicate the alpha and beta values.

In some embodiments, the CCLM prediction mode also includes prediction between two chrominance components, for example, predicting the Cr (red-difference) component from the Cb (blue-difference) component. Instead of using the reconstructed sample signal, CCLM Cb-to-Cr prediction is applied in the residue domain. This is implemented by adding the weighted reconstructed Cb residue to the original Cr intra-frame prediction to form the final Cr prediction:

Here, resi _Cb ' (i,j) represents the reconstructed Cb residual sample at position (i,j).

In some embodiments, the scaling factor α can be derived in a similar manner as in CCLM luma-to-chroma prediction. The only difference is that a regression cost is added relative to the default α value in the error function, so that the derived scaling factor is biased towards the default value of -0.5 as shown below:

Here, Cb(n) represents the adjacent reconstructed Cb sample point, Cr(n) represents the adjacent reconstructed Cr sample point, and λ is equal to Σ(Cb(n)．Cb(n))>>9.

In some embodiments, CCLM luma-to-chroma prediction mode is added as an additional chroma intra prediction mode. On the encoder side, one more RD cost check for chroma components is added for selecting the chroma intra prediction mode. When an intra prediction mode other than CCLM luma-to-chroma prediction mode is used for the chroma components of a CU, CCLM Cb-to-Cr prediction is used for Cr component prediction.

1.5.2 Example of multi-model CCLM

In JEM, there are two CCLM modes: Single Model CCLM Mode and Multiple Model CCLM Mode (MMLM). As the name indicates, for the entire CU, Single Model CCLM Mode uses a linear model to predict chrominance samples from luma samples, while in MMLM, there can be two models.

In MMLM, the neighboring luma samples and neighboring chroma samples of the current block are classified into two groups, and each group is used as a training set to derive a linear model (i.e., derive a specific α and β for a specific group). In addition, the samples of the current luma block are also classified based on the same rules for classifying neighboring luma samples.

FIG7 shows an example of classifying neighboring samples into two groups. Threshold is calculated as the average value of neighboring reconstructed brightness samples. Neighboring samples with Rec′ _L [x, y] <= Threshold are classified into group 1; and neighboring samples with Rec′ _L [x, y] > Threshold are classified into group 2.

Figures 8A and 8B show examples of chrominance samples and their corresponding luminance samples and an example of down-filtering of the cross-component linear model (CCLM) in the joint exploration model (JEM), respectively.

1.5.3 Example of chroma encoding and decoding in VVC

Regarding the existing implementation method, CCLM in JEM is adopted in VTM-2.0, but MM-CCLM in JEM is not adopted in VTM-2.0.

In some embodiments, for chroma intra-frame encoding and decoding, a candidate list of chroma intra-frame prediction modes can be first derived, and the candidate list can include three parts:

(1) A direct mode (DM) that is set to an intra-frame luminance prediction mode associated with the luminance CB at the collocated upper left corner position of the overlaying chrominance block. Examples are shown in Figures 9A and 9B, where the collocated position is indicated as "TL"

(2) A cross-component linear model (CCLM) model

(3) Four default modes (DC mode, planar mode, horizontal mode, and vertical mode, as highlighted in FIG1). In one example, if one of the four default modes is the same as the DM mode, it is replaced by the intra-frame prediction mode with the largest mode index (e.g., the intra-frame prediction mode indicated by the dotted line depicted in FIG10).

1.6 Syntax, semantics and decoding examples in VVC2

In some embodiments, the syntax and semantics of in-frame mode-related information may be specified as follows:

Example of codec unit semantics . In some embodiments, the syntax elements intra_luma_mpm_flag[x0][y0], intra_luma_mpm_idx[x0][y0], and intra_luma_mpm_remainder[x0][y0] specify the intra prediction mode for luma samples. The array indices x0, y0 specify the position (x0, y0) of the top-left luma sample of the prediction block under consideration relative to the top-left luma sample of the picture. When intra_luma_mpm_flag[x0][y0] is equal to 1, the intra prediction mode is inferred from the prediction unit of the adjacent intra prediction according to the specification (e.g., clause 8.2.2).

In some embodiments, intra_chroma_pred_mode[x0][y0] specifies the intra prediction mode for chroma samples. Array index x0, y0 specifies the position (x0, y0) of the top-left luma sample of the considered prediction block relative to the top-left luma sample of the picture.

Example of deriving luma intra prediction mode . In some embodiments, the input to this process is the luma position (xPb, yPb) which specifies the top left corner sample of the current luma prediction block relative to the top left corner luma sample of the current picture. In this process, the luma intra prediction mode IntraPredModeY[xPb][yPb] is derived. Table 4 specifies the values and associated names of the intra prediction modes.

In the context of Table 4, the intra-frame prediction mode INTRA_CCLM is applicable only to chrominance components, and IntraPredModeY[xPb][yPb] labeled 0..66 represents the direction of prediction as shown in Figure 1. In some embodiments, IntraPredModeY[xPb][yPb] is derived by the following sequential steps:

1. The adjacent positions (xNbA, yNbA) and (xNbB, yNbB) are set equal to (xPb-1, yPb) and (xPb, yPb-1) respectively.

2. For X replaced by A or B, the variable candIntraPredModeX is derived as follows:

- The availability derivation process of the call block is taken, where the position (xCurr, yCurr) is set equal to (xPb, yPb) and the adjacent position (xNbY, yNbY) is set equal to (xNbX, yNbX) as input, and the output is assigned to availableX.

- The candidate intra-frame prediction mode candIntraPredModeX is derived as follows:

- candIntraPredModeX is set equal to INTRA_DC if one or more of the following conditions are true.

- The variable availableX is equal to FALSE.

- CuPredMode[xNbX][yNbX] is not equal to MODE_INTRA.

- X is equal to B and yPb-1 is less than ((yPb>>CtbLog2SizeY)<<CtbLog2SizeY).

- Otherwise, candIntraPredModeX is set equal to IntraPredModeY[xNbX][yNbX].

3. candModeList[x], where x=0..2, is derived as follows:

- If candIntraPredModeB is equal to candIntraPredModeA, the following applies:

- If candIntraPredModeA is less than 2 (i.e. equal to INTRA_PLANAR or INTRA_DC), then candModeList[x], where x=0..2, is derived as follows: candModeList[0]=INTRA_PLANAR (8-1)

candModeList[1]=INTRA_DC (8-2)

candModeList[2]=INTRA_ANGULAR50 (8-3)

- Otherwise, candModeList[x], where x=0..2, is derived as follows: candModeList[0]=candIntraPredModeA(8-4)

candModeList[1]=2+((candIntraPredModeA+61)% 64)(8-5)

candModeList[2]=2+((candIntraPredModeA-1)% 64)(8-6)

- Otherwise (candIntraPredModeB is not equal to candIntraPredModeA), the following applies:

- candModeList[0] and candModeList[1] are derived as follows: candModeList[0]=candIntraPredModeA(8-7)

candModeList[1]=candIntraPredModeB(8-8)

- If both candModeList[0] and candModeList[1] are not equal to INTRA_PLANAR, candModeList[2] is set equal to INTRA_PLANAR,

- Otherwise, if both candModeList[0] and candModeList[1] are not equal to INTRA_DC, candModeList[2] is set equal to INTRA_DC,

- Otherwise, candModeList[2] is set equal to INTRA_ANGULAR50.

4. IntraPredModeY[xPb][yPb] is derived by applying the following process:

- If intra_luma_mpm_flag[xPb][yPb] is equal to 1, then IntraPredModeY[xPb][yPb] is set equal to candModeList[intra_luma_mpm_idx[xPb][yPb]].

- Otherwise, IntraPredModeY[xPb][yPb] is derived by applying the following sequence of steps:

1. The array candModeList[x], where x=0..2, is modified by the following sequence of steps:

i. When candModeList[0] is greater than candModeList[1], the two values are swapped as follows: (candModeList[0], candModeList[1])=Swap(candModeList[0], candModeList[1]) (8-9)

ii. When candModeList[0] is greater than candModeList[2], the two values are swapped as follows: (candModeList[0], candModeList[2])=Swap(candModeList[0], candModeList[2]) (8-10)

iii. When candModeList[1] is greater than candModeList[2], the two values are swapped as follows: (candModeList[1], candModeList[2]) = Swap(candModeList[1], candModeList[2]) (8-11)

2. IntraPredModeY[xPb][yPb] is derived through the following sequence of steps:

i. IntraPredModeY[xPb][yPb] is set equal to intra_luma_mpm_remainder[xPb][yPb].

ii. For i equal to 0 to 2 (inclusive), when IntraPredModeY[xPb][yPb] is greater than or equal to candModeList[i], the value of IntraPredModeY[xPb][yPb] is incremented by 1.

The variable IntraPredModeY[x][y], where x=xPb..xPb+cbWidth-1 and y=yPb..yPb+cbHeight-1, is set equal to IntraPredModeY[xPb][yPb].

Example of deriving chroma intra prediction mode . In some embodiments, the input to this process is the luma position (xPb, yPb) which specifies the top left corner sample of the current chroma prediction block relative to the top left corner luma sample of the current picture. In this process, the chroma intra prediction mode IntraPredModeC[xPb][yPb] is derived.

In some embodiments, the chroma intra-frame prediction mode IntraPredModeC[xPb][yPb] is derived using intra_chroma_pred_mode[xPb][yPb] and IntraPredModeY[xPb][yPb] as specified in Tables 5 and 6.

Table 5: Example specification for IntraPredModeC[xPb][yPb] with sps_cclm_enabled_flag=0

1.7 Example of multiple direct mode (DM)

Recently, JEM has adopted existing implementations (e.g., JVET-D0111). Due to the separate block partitioning structure of luma and chroma components in the I slice, one chroma CB can correspond to several luma CBs. Therefore, in order to further improve the coding efficiency, a Multiple Direct Modes (MDM) method for coding and decoding within chroma frames is proposed. In MDM, the list of chroma mode candidates includes the following three parts:

(1)CCLM mode

(2) Intra-frame prediction mode derived from five collocated luma CBs covering the current chroma block: The five positions to be checked in order are defined as: the center, top left, top right, bottom left, and bottom right 4x4 blocks within the corresponding luma block of the current chroma block for the I slice. For P and B slices, these five sub-blocks do not need to be checked because they will be within one CB. Examples of five collocated luma positions are shown in Figures 11A and 11B, which are represented by CR, TL, TR, BL, and BR, respectively.

(3) Chroma prediction models from spatially adjacent blocks used to unify the derivation process of luminance and chroma models (note removals and additions):

○ 5 chroma prediction modes from the left, top, bottom left, top right and top left spatial neighbors of the current block, and the positions of the 5 spatial blocks as in Merge mode (Planar and DC modes are removed)

○ Planar mode and DC mode added

○ Derived modes are added, these in-frame modes are obtained by adding -1 or +1 to the angle modes already included in the list

○Default modes are added in the following order: vertical (mode 18), horizontal (mode 50), mode 2, mode 34, mode 66, mode 10, mode 26 (mode 66, mode 10 and mode 26 are added)

○ Add the following rule: If any of the four default modes (planar, horizontal, vertical, and DC) is not included in the list, the missing default mode is used to replace the last candidate or candidates.

In some embodiments, the pruning process is applied every time a new chroma intra mode is added to the candidate list. In this contribution, the chroma intra mode candidate list size is always set to 10.

1.8 Example of copying blocks within a frame

In some embodiments, HEVC Screen Content Coding (SCC) is extended with a new codec tool, Intra-frame Block Copying (IBC), also known as Intra-frame Block Compensation or Current Picture Referencing (CPR), which is a very effective technique in improving codec performance. IBC is a block matching technique that predicts the current prediction block from a reference block located in an already reconstructed area of the same picture.

In IBC, a displacement vector (called a block vector or BV, or motion vector) is used to signal the relative displacement from the position of the current block to the position of a reference block. In addition, a previously reconstructed reference block within the same picture is added to the prediction error to form the reconstructed current block. In this technique, the reference samples correspond to the reconstructed samples of the current picture before the loop filtering operation. In HEVC, loop filtering refers to deblocking filtering and sample adaptive offset (SAO) filtering. An example of intra-frame block compensation is shown in Figure 12.

In some embodiments, the use of IBC mode is signaled at the sequence and picture level. When IBC mode is enabled at the Sequence Parameter Set (SPS), it can be enabled at the picture level. When IBC mode is enabled at the picture level, the current reconstructed picture is considered as a reference picture. Therefore, in HEVC SCC, no syntax changes at the block level are required to signal the use of IBC mode in addition to the existing HEVC inter-frame mode.

In some embodiments, the following is a list of features of IBC mode in HEVC SCC:

-- Support all prediction unit partitioning modes in HEVC inter-frame mode in IBC mode, such as 2N×2N or 2N×N or N×2N or N×N and asymmetrical motion partitioning (AMP) mode.

-- Merge and Skip modes are also available in IBC mode. The Merge candidate list construction is unified and contains Merge candidates from neighboring locations coded in IBC mode or in HEVC inter-frame mode. Depending on the selected Merge index, the current block in Merge or Skip mode can be merged into the neighbor coded in IBC mode or the neighbor coded in HEVC inter-frame mode.

-- The block vector prediction and coding scheme for IBC mode reuses the motion vector prediction and coding scheme used in HEVC inter-frame mode (AMVP and MVD codecs).

-- Residual transform, quantization and coefficient encoding and decoding are the same as in HEVC inter-frame mode.

In addition to the features listed above, some embodiments include additional features (or processes) for IBC mode, including:

-- IBC mode motion vectors, also called block vectors, are encoded and decoded with integer pixel precision, but are stored in registers with quarter pixel precision after decoding because the interpolation and deblocking stages require quarter pixel precision. When the stored vector prediction value is used for IBC mode motion vector prediction, the stored vector prediction value will be right shifted by 2.

-- A slice with enabled IBC mode will be treated as a P slice or a B slice, even if no other pictures are used as reference pictures except the current picture itself.

-- Disable weighted prediction for IBC mode as no significant compression benefit was observed.

2 Examples of shortcomings in existing implementations

Current intra-frame mode codec implementations in JEM or VTM exhibit at least the following issues:

●For luma codecs, only the prediction patterns of nearby spatially neighboring blocks are considered. The lack of statistical intra-frame prediction information of previously coded blocks results in limited codec performance improvements.

● In existing implementations, it is proposed to check more neighboring blocks to be added to the MPM list for better encoding and decoding of intra-frame prediction modes. The complexity is also increased due to multiple accesses of nearby spatial neighboring blocks.

●For chroma coding, multi-DM solution can bring additional coding gain at the cost of higher complexity, because adjacent chroma modes need to be stored, which is not required in HEVC.

●IBC can handle repeated patterns far from the current block, and intra-frame encoding and decoding mode can handle fewer spatial dependencies. However, either one is only beneficial in certain situations.

3 Example method of intra-frame mode encoding and decoding based on past information

Embodiments of the disclosed technology overcome the shortcomings of existing implementations, thereby providing video codecs with higher coding efficiency but lower computational complexity. Intra-frame mode coding based on past information, as described in this document, can enhance existing video codec standards and future video codec standards, as illustrated in the following examples described for various implementations. The examples of the disclosed technology provided below illustrate the general concepts and are not meant to be interpreted as limiting. In the examples, the various features described in these examples may be combined unless explicitly indicated otherwise.

Example of intra-frame mode encoding and decoding based on historical information

Example 1. In one example, a table with statistics of intra prediction mode (IPM) may be maintained during encoding/decoding to assist intra mode encoding and decoding.

(a) In one example, the table includes the occurrence and/or frequency of each IPM. Alternatively, the table may have entries for a partial set of allowed IPMs.

(b) Some of the IPMs listed in the table can be added to the MPM list as new MPMs.

(i) In one example, IPMs from spatially adjacent blocks are first added to the MPM list in order. Afterwards, some IPMs from that table may be added in order after pruning. If the list is not full, derived IPMs may also be added.

(ii) In one example, the MPM list size may be expanded. In this case, IPMs from spatially adjacent blocks and derived patterns may first be added to the MPM list in sequence. Afterwards, some IPMs from that table may be added in sequence after pruning.

(c) The IPMs included in the MPM list can be reordered based on this table.

(i) In one example, an MPM list is first constructed based on neighbor blocks and inferred patterns (e.g., as described in Section 1.2). Thereafter, the MPM list is reordered based on the descending order of the occurrence or frequency associated with the IPMs recorded in the table. Thus, the IPM with the highest occurrence or frequency in the MPM list will be adjusted to be at the first position in the MPM list.

Example 2. Different tables can be used for different color components.

(a) For example, one table is used for luma intra-mode coding and another table is used for chroma intra-mode coding.

(b) Alternatively, only one table is used for luma intra-mode encoding and decoding.

(c) Alternatively, whether multiple tables or one table is used depends on whether separate codec trees are used for luma and chroma.

Example 3. The frequency or occurrence of a mode M in the table is accumulated by K (e.g., K=1) after decoding a block with mode M.

(a) In one example, the occurrence of a pattern has a maximum value (e.g., 255).

(b) If at least one occurrence of the pattern reaches a maximum, a regularization (or normalization) process is applied.

(i) In one example, all occurrences of a number in a table are shifted right by one number, say 2.

(ii) In another example, all occurrences in the table are reduced by a number, such as the minimum occurrence in the table.

Example 4. Instead of using the IPM of adjacent neighboring blocks to encode and decode a block, the intra-frame prediction mode of non-adjacent neighboring blocks can be used.

(a) The IPM of a non-adjacent neighbor block may be added to the MPM list. Alternatively, pruning of the IPM may be applied. If the IPM of a non-adjacent neighbor block is different from any IPM in the MPM list, it may be added to the MPM list.

(b) In one example, the MPM list size may be expanded. In this case, IPMs from adjacent neighbor blocks and derived patterns may be first added to the MPM list in order. Afterwards, IPMs from non-adjacent neighbor blocks may be added in order after pruning.

(c) IPMs of non-adjacent neighboring blocks can be used to reorder non-MPM IPMs. In one example, those IPMs associated with non-adjacent neighboring blocks can be assigned a higher priority, for example, they can be encoded or decoded using fewer bits.

Example 5. The encoding and decoding of the IPM associated with the current block may depend on the table, the IPMs from adjacent spatially neighboring blocks, and the IPMs from non-adjacent spatially neighboring blocks.

Example of selection of adjacent neighbors

Example 6. Instead of using the top and left neighboring blocks relative to the top left corner position of the current block for intra mode encoding and decoding (such as using intra prediction mode of the top and left neighboring blocks to construct the MPM list), different positions can be used.

(a) In one example, the upper neighboring block relative to the upper left corner position of the current block is replaced by the upper neighboring block relative to the center position of the first column of the current block, as shown in FIG13A.

(b) In one example, the left neighboring block relative to the upper left corner position of the current block is replaced by the left neighboring block relative to the center position of the first row of the current block, as shown in FIG13D.

Example 7. Instead of utilizing fixed M relative neighbor blocks for all kinds of blocks, the selection of the M relative neighbor blocks may depend on the block shape and/or the block size.

(a) In one example, if the block is a square block, the intra prediction modes of the upper and left neighboring blocks relative to the upper left corner position of the current block for intra mode encoding and decoding may be used for encoding and decoding the intra prediction mode of the current block.

(b) In one example, if the block is a non-square block, the intra prediction mode of the upper and/or left adjacent blocks relative to the center position of the first column and/or first row of the current block used for intra mode encoding and decoding can be used to encode the intra prediction mode of the current block.

Example of multiple prediction blocks for a single frame codec block

Example 8. Reconstructed samples from the same slice/strip/picture containing the current block can be used to generate multiple prediction blocks.

(a) In one example, two prediction blocks may be first generated, and a final prediction block may be generated from the two prediction blocks. One of them is generated by intra prediction mode, and the other is generated by a motion vector pointing to the same slice/strip/picture containing the current block (e.g., intra block copy; and the motion vector is also referred to as a block vector).

(b) In one example, a linear function is applied to two prediction blocks to derive the final intra-frame prediction block.

(i) Alternatively, only a portion of the final prediction block is generated from multiple (e.g., two) prediction blocks, and the remainder is copied directly from one of the multiple prediction blocks.

(ii) In one example, the average of two prediction blocks (i.e., the two prediction blocks are equally weighted) is used as the final intra-frame prediction block.

(iii) In one example, different weights may be applied to different positions relative to a block, and/or different weights may be applied to different intra-frame prediction modes.

(iv) In one example, the weights may be signaled in SPS/PPS/VPS/picture or sequence or slice header/slice/CTU group/CTU/CU/PU/TU.

(v) The weights applied to the two prediction blocks can be predefined.

Example 9. The above method can be applied under certain conditions.

(a) It can be applied to certain color components, for example, only the brightness component.

(b) It can be applied to a certain block size/block shape etc.

Example 10. When IBC is considered as an inter-frame mode (i.e., having at least one motion vector used to derive a predicted block), a history-based motion vector prediction (HMVP) method can be used, which utilizes motion information from previous codecs for motion information prediction. The HMVP method allows the encoding/decoding process to be performed based on historical data (e.g., blocks that have already been processed). During the encoding/decoding process, one or more tables with motion information from previously encoded and decoded blocks are maintained. Each table can be associated with a counter to track the number of motion candidates stored in the table. During the encoding/decoding of a block, the associated motion information in the table can be used depending on the codec characteristics of the block (e.g., whether the block is an IBC codec) (e.g., by adding to a motion candidate list). After encoding/decoding a block, the table may be updated based on the codec characteristics of the block. That is, the table is updated based on the encoding/decoding order. In some embodiments, the table may be reset (e.g., removing the stored candidates and setting the associated counters to 0) before processing a new slice, a new Largest Coding Unit (LCU) row, or a new slice.

(a) In one example, the lookup table can be updated with motion information from an IBC codec block.

(b) Alternatively, do not allow the lookup table to be updated with motion information from IBC codec blocks.

(c) In one example, for IBC mode, motion information from previous codec blocks is not allowed to predict motion information of an IBC codec block.

(d) In one example, only motion information from a previous IBC codec block can be used to predict motion information for a current IBC codec block. A lookup table is used to include only motion information from an IBC codec block, and such a lookup table is used only for IBC codec blocks.

(e) Alternatively, for IBC mode, motion information from previous codec blocks is allowed to predict motion information for the IBC codec block.

(i) In one example, the lookup table may include motion information from IBC codec blocks and other types of inter-frame codec blocks. For example, if a motion candidate in the lookup table is derived from an IBC codec block, it can be used to encode/decode the current IBC codec block.

(ii) Alternatively, multiple lookup tables may be required, and at least one of them includes only motion information from IBC-coded blocks, and one of them includes only motion information from other types of inter-frame coded blocks. For example, a first lookup table may include motion information for IBC-coded blocks. A different second lookup table may include motion information for blocks that are not IBC-coded (e.g., blocks that may be coded in inter-frame mode). The first lookup update table and the second lookup update table may be updated after the corresponding conversions are completed. In some embodiments, the updated first lookup table may be used to perform a first subsequent conversion of the IBC-coded block, and the updated second lookup table may be used to perform a second subsequent conversion of the inter-frame coded block.

In some embodiments, pruning can be applied before updating the lookup table as described in Example 10 by adding motion candidates obtained from the codec block.

(a) In one example, new motion candidates to be added need to be pruned against all existing motion candidates in the selected table. That is, the new motion candidates can be compared with all existing motion candidates in the selected table to ensure that there are no duplicate candidates.

(b) Alternatively, a new motion candidate may be pruned only against a certain number of existing motion candidates. For example, it may be compared against the last m motion candidates (m being an integer) in the lookup table before optionally adding it as the last entry in the LUT.

(c) In some embodiments, the selected table is used to construct a motion candidate list from which motion candidates are obtained for a codec block. In some embodiments, the motion candidates can be used to update some or all of the available lookup tables.

In some embodiments, when a block is encoded or decoded using the Merge or AMVP mode, a lookup table as described in Example 10 may be used. That is, the current block may be encoded or decoded using the IBC Merge mode or the IBC AMVP mode.

In some embodiments, in addition to neighboring candidates, non-neighboring candidates (e.g., Merge candidates or AMVP candidates) can be combined in the lookup table.

(a) In one example, m candidates (non-neighbor and/or neighbor candidates) and n motion candidates from the lookup table can be added (e.g., when the list is not full). Both m and n are positive integers (>0).

(b) In one example, m candidates (non-neighboring and/or neighboring candidates) may be checked and/or n motion candidates from a lookup table may be checked. When the list is not full, checked candidates may be added.

(c) In one example, neighboring or non-neighboring candidates and motion candidates from a lookup table may be added in an interleaved manner.

(i) The order of checking neighbor or non-neighbor candidates remains unchanged. A candidate is checked, followed by the moving candidate from the lookup table.

(ii) The order in which non-neighboring blocks are checked remains unchanged. However, if a non-neighboring block is outside a certain range (e.g., outside the current LCU row), it will be replaced by a motion candidate in the lookup table.

(iii) In one example, the order in which non-adjacent blocks are checked remains unchanged. However, if a neighboring or non-adjacent block is encoded or decoded using intra mode or intra block copy mode, it will be replaced by the motion candidate in the lookup table (e.g., upon determining that the motion candidate in the lookup table is different from the neighboring or non-adjacent block).

(d) In one example, non-neighboring candidates are given higher priority than motion candidates from a lookup table.

(i) In this case, all non-neighboring blocks are checked first. If the total number of candidates is still less than the maximum allowed number, further motion candidates from the lookup table are checked.

(ii) Alternatively, motion candidates from the lookup table have higher priority than non-neighboring motion candidates. The motion candidates from the lookup table are checked first. If the total number of candidates is still less than the maximum allowed number, the non-neighboring blocks are checked to add the non-neighboring candidates to the Merge candidate list.

(iii) Similarly, when both non-neighboring methods and lookup table based methods are allowed in the Advanced Motion Vector Prediction (AMVP) encoding and decoding process, the priority can be handled in a similar manner to that described in the above example.

In some embodiments, similar to using a lookup table with motion candidates for motion vector prediction, it is proposed that one or more lookup tables can be constructed and/or updated to store intra-frame prediction patterns from previously coded blocks, and the lookup tables can be used to encode/decode intra-frame coded blocks.

(a) Each LUT has the same number of entries, e.g., equal to the total number of allowed intra-frame predictions.

(b) A variable (i.e., cnt) can also be assigned to each intra-frame prediction mode to record how many times the intra-frame prediction mode has been used in the previous coded code block.

(c) When the lookup table is updated with the selected intra-frame prediction mode, the associated cnt can be modified, for example by increasing it by 1.

In some embodiments, the intra-frame prediction mode of a non-neighboring block may be used as an intra-frame prediction mode prediction value for encoding and decoding an intra-frame coded block.

In some embodiments, the lookup table based method and the non-neighboring based method can be used jointly. In one example, the intra-frame prediction mode in the lookup table or the non-neighboring block can be used in the MPM list construction process. Alternatively, the non-MPM intra-frame prediction mode can be reordered using the lookup table or the intra-frame prediction mode in the non-neighboring block.

In some embodiments, the motion candidate list for an IBC codec block can be constructed as follows:

(a) If there are unique block vectors (also called displacement vectors or motion vectors as discussed above) associated with the two spatially adjacent blocks of the current block, add them to the list.

(b) The last available motion candidate in the list (i.e., the latest candidate) is checked. If there are no duplicate candidates in the list, then the last available motion candidate is added to the list.

(c) If the list is not full, add the remaining motion candidates in the lookup table.

Chroma mode encoding and decoding example

Example 11. In one example, it is proposed that for chroma mode encoding and decoding, the default mode (e.g., DC/Planar/HOR/VER in HEVC and VVC) can be replaced by a mode derived from a lookup table or non-adjacent chroma blocks.

(a) Alternatively, after checking those modes from the lookup table or non-neighboring chroma blocks, the default mode can still be added to the chroma mode list if the chroma mode list is not full.

Example 12. In one example, it is proposed that for chroma mode encoding and decoding, the default mode (e.g., DC/Planar/HOR/VER in HEVC and VVC) can be replaced by a mode derived from a non-neighboring luma block (e.g., a luma block that is not the corresponding luma block of a chroma block).

(a) Alternatively, after checking those modes from non-neighboring luma blocks, the default mode may still be added to the chroma mode list if the chroma mode list is not full.

Example 13. In one example, it is proposed that the intra-frame mode of the spatially neighboring blocks corresponding to the luma block can also be added to the chroma intra-frame mode list.

(a) Check the left and/or upper neighboring blocks located at the upper left corner sample of the corresponding luminance block, and its intra-frame mode may be used. For example, the left and/or upper neighboring blocks of "TL" shown in FIG. 11A may be checked.

(b) The examples shown in FIG. 13A-FIG. 13F may be used, where the current luma block is the corresponding luma block of the chroma block. Alternatively, the neighboring luma intra-frame mode may be added to the chroma mode list. That is, the intra-frame mode of the neighboring luma block of the current luma block may be added to the chroma mode list.

The above examples may be incorporated into the context of the methods described below, such as methods 1400, 1500, and 1600, which may be implemented at a video encoder and/or decoder.

FIG. 14 shows a flow chart of an example method for cross-component prediction. The method 1400 includes, at step 1410, for a bitstream representation of a current block of visual media data, selecting a first intra-frame prediction mode from a set of intra-frame prediction modes based on a first set of past intra-frame coding and decoding information. In some embodiments, the first set of past intra-frame coding and decoding information includes historical intra-frame coding and decoding information.

In some embodiments, and in the context of Example 1, the first set of past intraframe coding and decoding information includes statistical intraframe coding and decoding information. In one example, the statistical intraframe coding and decoding information includes the number of occurrences of each intraframe prediction mode in the set of intraframe prediction modes within the duration, and the method 1400 further includes the steps of constructing a most probable mode (MPM) list based on neighboring blocks of the current block, and reordering the MPM list based on the number of occurrences.

Method 1400 includes, at step 1420, processing the bitstream representation based on the first intra-frame prediction mode to generate a current block.

In some embodiments, and in the context of Example 2, the current block includes a luma component and a chroma component, a first set of past intra-frame coding and decoding information is used to perform intra-frame mode coding and decoding on the luma component, and a second set of past intra-frame coding and decoding information is used to perform intra-frame mode coding and decoding on the chroma component. In the example, the luma component is based on a first coding tree and the chroma components are based on a different second coding tree.

In some embodiments, and in the context of Example 3, for the intra-frame prediction mode in the set of intra-frame prediction modes corresponding to the first intra-frame prediction mode, the number of occurrences is incremented. Then, method 1400 further includes the following steps: determining that at least one of the number of occurrences is equal to a maximum number of occurrences. In one example, the method further includes right-shifting each of the number of occurrences by a predetermined number. In another example, the method further includes subtracting the minimum number of occurrences from each of the number of occurrences.

In some embodiments, and in the context of Example 4, method 1400 further includes the step of adding a first subset of the set of intra-frame prediction modes to a most probable mode (MPM) list. In other embodiments, method 1400 may further include increasing the size of the MPM list, and adding a first subset of the set of intra-frame prediction modes to the MPM list, wherein the first subset of intra-frame prediction modes corresponds to blocks that are spatial neighbors of the current block. In these cases, method 1400 may further include pruning the MPM list, and adding a second subset of the set of intra-frame prediction modes to the MPM list, wherein the ordering of the intra-frame prediction modes in the second subset is maintained in the MPM list.

FIG15 shows a flow chart of another example method for cross-component prediction. Method 1500 includes, at step 1510, for a bitstream representation of a current block of visual media data, selecting an intra-frame prediction mode from at least one of spatially adjacent blocks that are adjacent or non-adjacent to the current block.

In some embodiments, and in the context of Example 6, at least one of the adjacent spatially adjacent blocks is an upper adjacent block relative to the upper left corner position of the current block, or an upper adjacent block relative to the center position of the first column of the current block, or an upper adjacent block relative to the upper right corner position of the current block, or a left adjacent block relative to the upper left corner position of the current block, or a left adjacent block relative to the center position of the first row of the current block, or a left adjacent block relative to the lower left corner position of the current block.

Method 1500 includes, at step 1520, processing the bitstream representation based on the intra-frame prediction mode to generate the current block.

FIG16 shows a flow chart of another example method for cross-component prediction. Method 1600 includes, at step 1610, for a bitstream representation of a current block of visual media data, generating a first prediction block and a second prediction block based on reconstructed samples from a picture segment including the current block.

Method 1600 includes, at step 1620, generating at least a portion of a final prediction block based on a linear function of the first prediction block and the second prediction block. In some embodiments, the final prediction block is an average of the first prediction block and the second prediction block.

In some embodiments, and in the context of Example 8, a portion of the final prediction block is based on a linear function of the first prediction block and the second prediction block, and the remainder is directly copied from the first prediction block or the second prediction block. In some embodiments, the weight of the linear function is signaled in a sequence parameter set (SPS), a picture parameter set (PPS), a video parameter set (VPS), a slice header, a slice header, a coding tree unit (CTU) group, a coding unit (CU), a prediction unit (PU), or a transform unit (TU).

Method 1600 includes, at step 1630, processing the bitstream representation based on the final prediction block to generate a current block.

FIG24 shows a flow chart of an example method for chroma mode encoding and decoding based on past information. Method 2400 includes, at step 2410, for a bit stream representation of a current block including a luminance component and a chroma component, selecting a first encoding and decoding mode for the chroma component.

Method 2400 includes, at step 2420, performing a conversion between a bitstream representation and a current block based on a first encoding/decoding mode. In some embodiments, the conversion generates the current block from the bitstream representation (e.g., as may be implemented in a video decoder). In other embodiments, the conversion generates the bitstream representation from the current block (e.g., as may be implemented in a video encoder).

In some embodiments, and in the context of Example 11, the first encoding/decoding mode of the chrominance component is a default mode, which can be a DC mode, a planar mode, a vertical mode, or a horizontal mode.

In some embodiments, method 2400 may further include the step of replacing the default mode with a second codec mode derived from a lookup table or a non-neighboring chroma block. In the example, and in the context of Example 11, upon determining that the chroma mode list includes a second codec mode from a non-neighboring chroma block and is not full, the default mode is added to the chroma mode list.

In some embodiments, method 2400 may further include the step of replacing the default mode with a second codec mode derived from a non-neighboring luma block. In the example, and in the context of Example 12, upon determining that the chroma mode list includes a second codec mode from a non-neighboring luma block and is not full, the default mode is added to the chroma mode list.

FIG25 shows a flowchart of another example method for chroma mode encoding and decoding based on past information. Method 2500 includes, at step 2510, for a bit stream representation of a current block including a luminance component and a chrominance component, selecting an intra-frame encoding and decoding mode from a spatially adjacent block of the luminance component.

Method 2500 includes, at step 2520, adding the intra-frame encoding/decoding mode to the chroma intra-frame mode list.

Method 2500 includes, at step 2530, performing conversion between the bitstream representation and the current block based on the intra-frame encoding/decoding mode.

In some embodiments, and in the context of Examples 6 and 13, the spatial domain adjacent block may be an upper adjacent block relative to the upper left corner position of the current block, an upper adjacent block relative to the center position of the first column of the current block, an upper adjacent block relative to the upper right corner position of the current block, a left adjacent block relative to the center position of the first row of the current block, or a left adjacent block relative to the lower left corner position of the current block.

5 Example implementations of the disclosed technology

FIG. 17 is a block diagram of a video processing device 1700. Device 1700 may be used to implement one or more of the methods described herein. Device 1700 may be embodied in a smart phone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. Device 1700 may include one or more processors 1702, one or more memories 1704, and video processing hardware 1706. Processor(s) 1702 may be configured to implement one or more methods described in this document (including but not limited to methods 1400, 1500, and 1600). Memory(s) 1704 may be used to store data and code for implementing the methods and techniques described herein. Video processing hardware 1706 may be used to implement some of the techniques described in this document in hardware circuits.

In some embodiments, the video encoding and decoding method can be implemented using a device implemented on a hardware platform as described with reference to FIG. 17 .

FIG. 18 is a block diagram illustrating an example video processing system 1800 in which various techniques disclosed herein may be implemented. Various implementations may include some or all components of system 1800. System 1800 may include an input 1802 for receiving video content. The video content may be received in a raw or uncompressed format (e.g., 8 or 10-bit multi-component pixel values), or may be in a compressed or encoded format. Input 1802 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces such as Ethernet, Passive Optical Network (PON), and wireless interfaces such as Wi-Fi or cellular interfaces.

System 1800 may include a codec component 1804 that may implement the various encoding or decoding methods described in this document. Codec component 1804 may reduce the average bit rate of the video from input 1802 to the output of codec component 1804 to produce a codec representation of the video. Codec techniques are therefore sometimes referred to as video compression or video transcoding techniques. The output of codec component 1804 may be stored or sent via a communication connection such as represented by component 1806. The stored or communicated bitstream (or codec) representation of the video received at input 1802 may be used by component 1808 to generate pixel values or be sent to a displayable video of display interface 1810. The process of generating user-viewable video from a bitstream representation is sometimes referred to as video decompression. Furthermore, although certain video processing operations are referred to as "encoding" operations or tools, it will be understood that the encoding tools or operations are used at the encoder and that the corresponding decoding tools or operations that reverse the encoding and decoding results will be performed by the decoder.

Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), or Displayport, etc. Examples of storage interfaces include SATA (Serial Advanced Technology Attachment), PCI, IDE interfaces, etc. The technology described in this document may be embodied in various electronic devices such as mobile phones, laptops, smart phones, or other devices capable of performing digital data processing and/or video display.

FIG. 19 shows a flow chart of an example method 1900 for video encoding and decoding according to the disclosed technology. The method 1900 includes, at operation 1910, for conversion between a current block of visual media data and a bitstream representation of the current block, selecting a first intra-frame prediction mode based on at least a first set of historical intra-frame encoding and decoding information including statistical information of a set of intra-frame prediction modes. The method 1900 also includes, at operation 1920, performing the conversion based on the first intra-frame prediction mode.

In some embodiments, the conversion includes encoding the current block to generate a bitstream representation. In some embodiments, the conversion includes decoding the bitstream representation to generate the current block. In some embodiments, the statistical intra-frame encoding and decoding information includes the number of occurrences of each intra-frame prediction mode in a set of intra-frame prediction modes within a duration. In some embodiments, the statistical intra-frame encoding and decoding information includes the number of occurrences of a portion of the intra-frame prediction modes in the set of intra-frame prediction modes within a duration.

In some embodiments, the method further includes, after performing the conversion, updating the set of historical intraframe codec information. In some embodiments, the updating includes accumulating the number of occurrences of the first intraframe prediction mode in the first set of historical intraframe codec information by k, where k is a positive integer. In some embodiments, subsequent blocks of the current block are processed based on the updated historical intraframe codec information.

In some embodiments, each intra-frame prediction mode in the first set of historical intra-frame coding and decoding information is associated with a limit of the number of occurrences. In some embodiments, the method includes, after the number of occurrences reaches the limit, reducing the number of occurrences based on a predefined rule. In some embodiments, the predefined rule includes dividing the number of occurrences by a first predefined value, or subtracting a second predefined value from the number of occurrences.

In some embodiments, the method includes constructing a most probable mode (MPM) list based at least on a set of intra-frame prediction modes. In some embodiments, the method includes adding a subset of the set of intra-frame prediction modes to the MPM list. In some embodiments, the method includes: adding intra-frame prediction modes associated with spatial neighbors of a current block to the MPM list; adding a subset of the set of intra-frame prediction modes to the MPM list; and pruning the MPM list. In some embodiments, the method includes adding a derived intra-frame prediction mode to the MPM list. In some embodiments, the method includes increasing the size of the MPM list. In some embodiments, the method includes reordering the MPM list based on a set of historical intra-frame encoding and decoding information. In some embodiments, the MPM list is reordered in descending order based on statistical information of the set of intra-frame prediction modes.

In some embodiments, the current block includes a luma component and a chroma component. A first set of historical intra-frame coding and decoding information is used to perform intra-frame mode coding and decoding on the luma component. In some embodiments, a second set of historical intra-frame coding and decoding information is used to perform intra-frame mode coding and decoding on the chroma component. In some embodiments, the luma component is based on a first coding and decoding tree, and the chroma component is based on a second coding and decoding tree different from the first coding and decoding tree.

In some embodiments, selecting the first intra-frame prediction mode is further based on the intra-frame prediction mode of the spatial neighbors of the current block or the intra-frame prediction mode of the non-neighboring neighbors of the current block. In some embodiments, the historical intra-frame encoding and decoding information is stored in a table.

FIG. 20 shows a flow chart of another example method 2000 for video processing according to the disclosed technology. The method 2000 includes, at operation 2010, for converting between a current block of visual media data and a bitstream representation of the current block, selecting a first intra-frame prediction mode based at least on an intra-frame prediction mode associated with a non-neighboring neighbor of the current block. The method 2000 also includes, at operation 2020, performing the conversion based on the first intra-frame prediction mode.

In some embodiments, the conversion includes encoding the current block to generate a bitstream representation. In some embodiments, the conversion includes decoding the bitstream representation to generate the current block.

In some embodiments, the method further includes, for a conversion between a current block and a bitstream representation of the current block, constructing a most probable mode (MPM) list based on intra-frame prediction modes associated with non-neighboring neighbors of the current block. The conversion is further performed based on the MPM list. In some embodiments, constructing the MPM list includes adding intra-frame prediction modes associated with spatial neighbors of the current block to the MPM list and pruning the MPM list. In some embodiments, constructing the MPM list includes adding derived intra-frame prediction modes to the MPM list. In some embodiments, the method includes increasing the size of the MPM list.

In some embodiments, the method includes reordering intra-frame prediction modes that are not in the MPM list according to intra-frame prediction modes associated with non-neighboring neighbors of the current block. In some embodiments, for the reordering, intra-frame prediction modes associated with non-neighboring neighbors of the current block are associated with a higher priority.

FIG. 21 shows a flow chart of an example method 2100 for video processing according to the disclosed technology. The method 2100 includes, at operation 2110, for a conversion between a current block of visual media data and a bitstream representation of the current block, selecting an intra-frame prediction mode based on at least one of the spatially adjacent blocks of the current block. At least one of the spatially adjacent blocks is different from a first block located to the left of a first column of the current block and a second block located above a first row of the current block. The method 2100 also includes, at operation 2110, performing the conversion based on the intra-frame prediction mode.

In some embodiments, the conversion includes encoding the current block to generate a bitstream representation. In some embodiments, the conversion includes decoding the bitstream representation to generate the current block.

In some embodiments, at least one of the spatially adjacent blocks includes a block adjacent to the current block. In some embodiments, at least one of the spatially adjacent blocks includes a block that is not adjacent to the current block. In some embodiments, at least one of the adjacent spatially adjacent blocks includes a block adjacent to the upper left corner position of the current block. In some embodiments, at least one of the adjacent spatially adjacent blocks includes a block adjacent to the center position of the first column of the current block. In some embodiments, at least one of the adjacent spatially adjacent blocks includes a block adjacent to the center position of the first row of the current block.

In some embodiments, at least one of the spatially neighboring blocks is selected based on one or more dimensions of the current block. In some embodiments, the current block has a square shape, and at least one of the neighboring spatially neighboring blocks includes a block that is adjacent to the upper left corner position of the current block. The selected intra-frame prediction mode can be added to the most likely mode list of the current block.

In some embodiments, the current block has a non-square shape, and at least one of the spatially adjacent blocks includes a block adjacent to a center position of a first column of the current block or a block adjacent to a center position of a first row of the current block.

FIG. 22 shows a flow chart of an example method 2200 for video processing according to the disclosed technology. The method 2200 includes, at operation 2210, generating a final prediction block for a conversion between a current block of visual media data and a bitstream representation of the current block. The method 2200 includes, at operation 2220, performing the conversion based on the final prediction block. At least a portion of the final prediction block is generated based on a combination of a first prediction block and a second prediction block, wherein the first prediction block and the second prediction block are based on reconstructed samples from an image segment including the current block. In some embodiments, the conversion includes encoding the current block to generate a bitstream representation. In some embodiments, the conversion includes decoding the bitstream representation to generate the current block.

In some embodiments, the first prediction block is generated according to an intra-frame prediction mode. In some embodiments, the second prediction block is generated based on a motion vector pointing to an image segment. In some embodiments, the second prediction block is generated based on an intra-frame block copy technique in which the reconstructed samples pointed to by the motion vector are copied. In some embodiments, the second prediction block is generated based on an intra-frame block copy technique in which motion compensation is applied to the reconstructed samples pointed to by the motion vector before applying a loop filtering operation.

In some embodiments, the reconstructed samples are generated before the loop filtering operation is applied. In some embodiments, the remainder of the final prediction block is copied directly from the first prediction block or the second prediction block. In some embodiments, the combination of the first prediction block and the second prediction block includes a linear function of the first prediction block and the second prediction block. In some embodiments, the linear function includes an average of the first prediction block and the second prediction block. In some embodiments, the linear function includes a weighted linear function of the first prediction block and the second prediction block. In some embodiments, different weights are applied for different positions relative to the first prediction block or the second prediction block. In some embodiments, different weights are applied for different intra-frame prediction modes. In some embodiments, the weights of the weighted linear function are signaled in a sequence parameter set (SPS), a picture parameter set (PPS), a video parameter set (VPS), a slice header, a slice header, a codec tree unit (CTU) group, a codec unit (CU), a prediction unit (PU), or a transform unit (TU). In some embodiments, the weights of the weighted linear function are predefined.

In some embodiments, the image segment includes a picture, a strip, or a slice. In some embodiments, the first prediction block and the second prediction block are generated for a selected color component of the current block. In some embodiments, the selected color component includes a luminance color component. In some embodiments, the first prediction block and the second prediction block are generated when it is determined that the size or shape of the current block meets a predefined criterion.

FIG. 23 shows a flow chart of an example method 2300 for video processing according to the disclosed technology. The method 2300 includes, at operation 2310, maintaining a first table of motion candidates during a conversion between a current block of visual media data and a bitstream representation of the current block. The method 2300 includes, at operation 2320, determining motion information of the current block encoded and decoded using an intra-frame block copy (IBC) mode based at least on the first table of motion candidates, in which at least one motion vector points to a picture segment including the current block. The method 2300 also includes, at operation 2330, performing the conversion based on the motion information. In some embodiments, the conversion includes encoding the current block to generate a bitstream representation. In some embodiments, the conversion includes decoding the bitstream representation to generate the current block.

In some embodiments, the method includes selectively updating the first table of motion candidates using the motion information used for the transformation based on a rule. In some embodiments, the rule specifies adding the motion information to the first table of motion candidates. In some embodiments, the rule specifies excluding the motion information from the first table of motion candidates.

In some embodiments, the method includes, after the conversion, updating the first table of motion candidates based on the motion information of the current block. In some embodiments, the method includes using the updated first table of motion candidates to perform a second conversion between a second block of visual media data and a bitstream representation of the second block. The second block may be encoded or decoded using an intra-frame block copy mode. In some embodiments, the first table of motion candidates includes only motion information from blocks encoded or decoded using the intra-frame block copy mode. In some embodiments, the first table of motion candidates is used only to process blocks encoded or decoded using the intra-frame block copy mode. In some embodiments, the first table of motion candidates includes motion information from blocks encoded using the intra-frame block copy mode and excludes motion information from blocks encoded using other techniques. In some embodiments, the first table of motion candidates includes motion information from blocks encoded using the intra-frame block copy mode and motion information from blocks encoded using other techniques. In some embodiments, the second transformation is performed using motion candidates associated with IBC-coded blocks in the updated first table of motion candidates.

In some embodiments, the method includes: maintaining a second table of motion candidates for a third transformation between a third block of visual media data and a bitstream representation of the third block; and performing the third transformation between the third block and the bitstream representation of the third block based on the second table of motion candidates. In some embodiments, the third transformation is performed without using the updated first table of motion candidates. In some embodiments, the second table includes motion information from blocks encoded using other techniques other than IBC mode. In some embodiments, the third block is encoded and decoded using a technique other than IBC mode. In some embodiments, the technique includes an inter-frame mode. In some embodiments, the method includes updating the second table of motion candidates using the motion information used for the third transformation. In some embodiments, the method includes performing a fourth conversion between IBC codec blocks based on the updated first table, and performing a fifth conversion between inter-frame codec blocks based on the updated second table.

In some embodiments, the method includes comparing a motion candidate associated with the current block to a plurality of entries in a first table. The first table is updated based on the comparison. In some embodiments, the plurality of entries corresponds to all entries in the first table. In some embodiments, the number of entries is m, m is an integer, and the m entries are the last m entries in the first table. In some embodiments, updating the first table includes adding the motion candidate to the first table. In some embodiments, the first table does not include duplicate entries.

In some embodiments, the method includes determining that the current block is further encoded or decoded using an IBC Merge mode or an IBC Advanced Motion Vector Prediction (AMVP) mode. In some embodiments, the method includes determining a list of motion candidates for the current block by combining a first table of motion candidates and a neighboring or non-neighboring candidate set for the current block, and performing the conversion based on the list. In some embodiments, the combining includes checking m candidates from the neighboring or non-neighboring candidate set, and checking n motion candidates from the first table of motion candidates, where m and n are positive integers. In some embodiments, the method includes, when determining that the list of motion candidates is not full, adding at least one of the m candidates from the neighboring or non-neighboring candidate set to the list of motion candidates. In some embodiments, the method includes, upon determining that the list of motion candidates is not full, adding at least one of the n motion candidates from the first table of motion candidates to the list of motion candidates.

In some embodiments, the combining includes checking candidates from the first list of neighboring or non-neighboring candidate sets and motion candidates in an interleaved manner. In some embodiments, the method includes checking candidates from the neighboring or non-neighboring candidate set before checking the motion candidate from the first list. In some embodiments, the checking includes checking a candidate from the neighboring or non-neighboring candidate set and replacing the candidate with a motion candidate from the first list of motion candidates based on a codec characteristic of a neighboring or non-neighboring block associated with the neighboring or non-neighboring candidate. In some embodiments, the codec characteristic of the neighboring or non-neighboring block indicates that the neighboring or non-neighboring block is outside a predefined range. In some embodiments, the coding characteristic of the neighboring or non-neighboring block indicates that the neighboring or non-neighboring block is intra-coded. In some embodiments, adding the motion candidate further includes adding the motion candidate to the list upon determining that the motion candidate from the first list of motion candidates is different from at least one candidate from the neighboring or non-neighboring candidate set. In some embodiments, the neighboring or non-neighboring candidate set has a higher priority than the first list of motion candidates.

In some embodiments, the list of motion candidates includes multiple Merge candidates for IBC Merge codec blocks. In some embodiments, the list of motion candidates includes multiple AMVP candidates for IBC AMVP codec blocks. In some embodiments, the list of motion candidates includes an intra-frame prediction mode for intra-frame codec blocks. In some embodiments, the size of the first table is predefined or signaled in the bitstream representation. In some embodiments, the first table is associated with a counter indicating the number of available motion candidates in the first table.

In some embodiments, the method includes resetting the first table before processing a new stripe, a new LCU row, or a new slice. In some embodiments, the counter is set to zero before processing a new stripe, a new LCU row, or a new slice.

FIG. 26 shows a flow chart of an example method 2600 for video processing according to the disclosed technology. The method 2600 includes, at operation 2610, for a conversion between a current block of video data and a bitstream representation of the current block, determining a first codec mode for a chroma component of the current block based at least on one or more codec modes of blocks not adjacent to the current block. The method 2600 also includes, at operation 2620, performing the conversion between the bitstream representation and the current block based on the first codec mode.

In some embodiments, the transform generates the current block from a bitstream representation. In some embodiments, the transform generates the bitstream representation from the current block.

In some embodiments, the first codec mode is derived from a table of motion candidates or a non-adjacent chroma block. In some embodiments, the first codec mode is derived from a luma block that is different from a corresponding luma block of a chroma component. In some embodiments, the first codec mode is derived from a luma block that is non-adjacent to a corresponding luma block of a chroma component. In some embodiments, the first codec mode is determined as a first default codec mode.

In some embodiments, the method includes adding a first default codec mode to a chroma mode candidate list for the current block. In some embodiments, the method further includes determining a second default codec mode including one of a DC mode, a planar mode, a vertical mode, or a horizontal mode. In some embodiments, when it is determined that the chroma mode list is not full after checking the first default mode, the second default codec mode is added to the chroma mode list.

In some embodiments, the motion candidates in the table of motion candidates correspond to intra-frame prediction modes of previously encoded code blocks. In some embodiments, the method includes updating the table of motion candidates after the conversion. In some embodiments, the method includes performing a second conversion between a subsequent block of video data and a bitstream representation of the subsequent block based on the updated table.

FIG. 27 shows a flow chart of an example method 2700 for video processing according to the disclosed technology. The method 2700 includes, at operation 2710, for a conversion between a bitstream representation of a chroma block and the chroma block, determining an intra-frame encoding/decoding mode based on spatially adjacent blocks of a luminance block corresponding to the chroma block. The method 2700 also includes, at operation 2720, performing the conversion between the bitstream representation and the chroma block based on the intra-frame encoding/decoding mode.

In some embodiments, the transform generates a chroma block from a bitstream representation. In some embodiments, the transform generates a bitstream representation from a chroma block. In some embodiments, the method includes adding the intra-frame encoding/decoding mode to a chroma intra-frame mode list of the chroma block.

In some embodiments, the spatially adjacent block includes an upper adjacent block relative to the upper left corner position of the chroma block. In some embodiments, the spatially adjacent block includes a left adjacent block relative to the upper left corner position of the chroma block. In some embodiments, the spatially adjacent block includes an upper adjacent block relative to the upper right corner position of the chroma block. In some embodiments, the spatially adjacent block includes a left adjacent block relative to the lower left corner position of the chroma block. In some embodiments, the spatially adjacent block includes a block adjacent to the center position of the first column of the chroma block. In some embodiments, the spatially adjacent block is a block adjacent to the center position of the first row of the chroma block.

Based on the foregoing, it can be understood that this article has described the specific implementation of the disclosed technology for the purpose of illustration, but various modifications can be made without departing from the scope of the invention. Therefore, the disclosed technology is not limited except to the scope of the attached patent application.

The implementation of the subject matter and functional operations described in this patent document can be implemented in various systems, digital electronic circuits or computer software, firmware or hardware (including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them). The implementation of the subject matter described in this specification can be implemented as one or more computer program products, that is, one or more modules of computer program instructions encoded on a tangible and non-transitory computer-readable medium, which are used to be run by a data processing device or control the operation of the data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a storage device, a combination of substances that affect machine-readable propagated signals, or a combination of one or more of them. The term "data processing unit" or "data processing apparatus" encompasses all devices, equipment and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus may also include code that creates an operating environment for the computer program in question, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language (including compiled or interpreted languages), and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language file), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that hold one or more modules, subroutines, or portions of code). A computer program may be deployed to run on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

The processes and logic flows described in this specification may be performed by one or more programmable processors running one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by dedicated logic circuits, and the apparatus may also be implemented as dedicated logic circuits, such as FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits).

Processors suitable for running computer programs include, for example, general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from read-only memory or random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operatively coupled to receive data from or transfer data to the one or more mass storage devices, or to receive data from and transfer data to the one or more mass storage devices. However, a computer does not require such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices such as EPROM, EEPROM, and flash memory. The processor and memory may be supplemented by or incorporated in dedicated logic circuitry.

The specification, together with the drawings, are intended to be regarded as exemplary, where exemplary means example. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. In addition, the use of "or" is intended to include "and/or" unless the context clearly indicates otherwise.

Although this patent document contains many details, these details should not be construed as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed as such, in some cases one or more features from a claimed combination may be excluded from the combination, and a claimed combination may be directed to a subcombination or variations of a subcombination.

Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all of the operations shown be performed to achieve the desired results. In addition, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

Only some implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and shown in this patent document.

2600:Methods

2610, 2620: Operation

Claims (24)

A method for video processing, comprising: for a conversion between a current block of video data and a bitstream of the current block, determining a first codec mode for a chrominance component of the current block based at least on one or more codec modes of a block not adjacent to the current block; and performing the conversion between the bitstream and the current block based on the first codec mode, wherein the first codec mode is derived from a luminance block not adjacent to a corresponding luminance block of the chrominance component. A method as claimed in claim 1, wherein the conversion generates a current block from a bit stream. A method as claimed in claim 1, wherein the conversion generates a bit stream from the current block. A method as claimed in any one of claims 1 to 3, wherein the first encoding/decoding mode is derived from a table of motion candidates or a non-adjacent chrominance block. A method as claimed in any one of claims 1 to 3, wherein the first coding mode is derived from a luminance block different from a corresponding luminance block of a chrominance component. A method as described in any one of items 1 to 3 of the patent application scope, wherein the first encoding and decoding mode is determined to be a first default encoding and decoding mode. The method described in item 6 of the patent application scope further includes: adding the first default encoding and decoding mode to the chroma mode candidate list of the current block. The method described in item 6 of the patent application scope further includes: determining a second default encoding and decoding mode including one of a DC mode, a planar mode, a vertical mode or a horizontal mode. As described in claim 8, when it is determined that the chroma mode list is not full after checking the first default mode, the second default codec mode is added to the chroma mode list. A method as described in any one of items 1 to 3 of the patent application scope, wherein the motion candidates in the motion candidate table correspond to the intra-frame prediction mode of the previously encoded and decoded code block. A method as described in any one of items 1 to 3 of the patent application scope, comprising: updating the table of motion candidates after the conversion. The method as described in claim 11 includes: performing a second conversion between a subsequent block of video data and a bit stream of the subsequent block based on the updated table. The method as described in claim 1 further includes: for the conversion between the bit stream of the chroma block and the chroma block, determining the intra-frame coding/decoding mode based on the spatially adjacent blocks of the luminance block corresponding to the chroma block; and performing the conversion between the bit stream and the chroma block based on the intra-frame coding/decoding mode. A method as claimed in claim 13, wherein the conversion generates chroma blocks from a bitstream. A method as claimed in claim 13, wherein the conversion generates a bit stream from chroma blocks. The method as described in any one of items 13 to 15 of the patent application scope includes: adding the intra-frame encoding and decoding mode to the chroma intra-frame mode list of the chroma block. As described in any one of items 13 to 15 of the patent application scope, wherein the spatially adjacent block includes an upper adjacent block relative to the upper left corner position of the chrominance block. As described in any one of items 13 to 15 of the patent application scope, wherein the spatial domain adjacent block includes a left adjacent block relative to the upper left corner position of the chrominance block. As described in any one of items 13 to 15 of the patent application scope, wherein the spatial domain adjacent block includes an upper adjacent block relative to the upper right corner position of the chrominance block. As described in any one of items 13 to 15 of the patent application scope, wherein the spatial domain adjacent block includes a left adjacent block relative to the lower left corner position of the chrominance block. As described in any one of items 13 to 15 of the patent application scope, wherein the spatially adjacent blocks include blocks adjacent to the center position of the first column of the chrominance block. As described in any one of items 13 to 15 of the patent application scope, wherein the spatially adjacent block is a block adjacent to the center position of the first row of the chrominance block. A device in a video system, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to implement a method as described in any one of items 1 to 22 of the patent application scope. A non-transitory computer-readable medium having computer program instructions stored thereon, wherein the computer program instructions, when executed by a processor, implement a method as described in any one of items 1 to 22 of the patent application scope.