Encoding and decoding method and device

Abstract

The invention provides a coding and decoding method and device. The decoding method comprises, for a chrominance block of a picture within a single non-overlapping rectangular region, determining a luma non-overlapping rectangular region comprising a luma block co-located with a location of the chrominance block, determining a scaling factor based on an average value of reconstructed luma samples, the reconstructed luma sample belongs to a downstream and / or right column of luma samples belonging to an upper and / or left adjacent luma non-overlapping rectangular region including the luma non-overlapping rectangular region of the current chroma block, respectively, and scaling a chroma block residual according to the scaling factor.

Description

[0001] This application is a divisional application of the invention patent application with the application date of February 25, 2020, application number 202080017018.6, and invention name “Method and device for image encoding and decoding”. Technical Field

[0002] At least one of the present embodiments generally relates to a method and apparatus for picture encoding and decoding, and more specifically, to a method and apparatus for picture encoding and decoding using independent luma and chroma segmentation. Background Art

[0003] In order to achieve high compression efficiency, image and video coding schemes usually use prediction and transformation to exploit spatial and temporal redundancy in video content. Typically, intra-frame or inter-frame prediction is used to exploit intra-frame or inter-frame correlation, and then the difference between the original image block and the predicted image block (usually expressed as a prediction error or prediction residual) is transformed, quantized, and entropy encoded and decoded. During encoding, it is usually possible to segment / partition the original image block into sub-blocks using quadtree partitioning. In order to reconstruct the video, the compressed data is decoded by the inverse process corresponding to prediction, transformation, quantization, and entropy encoding and decoding. Summary of the invention

[0004] According to a general aspect of at least one embodiment, a decoding method is proposed, which, for a chrominance block of a picture within a single non-overlapping rectangular area, includes: determining a luminance non-overlapping rectangular area including a luminance block co-located with the chrominance block, determining a scaling factor based on an average value of reconstructed luminance samples, wherein the reconstructed luminance samples belong to the lower and / or right columns of luminance samples of luminance non-overlapping rectangular areas adjacent to the luminance non-overlapping rectangular area above and / or to the left of the luminance non-overlapping rectangular area containing the current chrominance block, and scaling the chrominance block residual according to the scaling factor.

[0005] According to a general aspect of at least one embodiment, a coding method is proposed, which, for a chrominance block of a picture within a single non-overlapping rectangular area, includes: determining a luminance non-overlapping rectangular area including a luminance block co-located with the chrominance block, determining a scaling factor based on an average value of reconstructed luminance samples, wherein the reconstructed luminance samples belong to the lower and / or right columns of luminance samples of luminance non-overlapping rectangular areas adjacent to the luminance non-overlapping rectangular area above and / or to the left of the luminance non-overlapping rectangular area containing the current chrominance block, and scaling the chrominance block residual according to the scaling factor.

[0006] According to a general aspect of at least one embodiment, a decoding device is proposed, comprising one or more processors, wherein the one or more processors are configured to: for a chrominance block of a picture within a single non-overlapping rectangular area: determine a luminance non-overlapping rectangular area including a luminance block co-located with the position of the chrominance block, determine a scaling factor based on an average value of reconstructed luminance samples, wherein the reconstructed luminance samples belong to a lower and / or right column of luminance samples of luminance non-overlapping rectangular areas adjacent to the luminance non-overlapping rectangular area above and / or to the left of the luminance non-overlapping rectangular area containing the current chrominance block, and scale the chrominance block residual according to the scaling factor.

[0007] According to a general aspect of at least one embodiment, a coding device is proposed, comprising one or more processors, which are configured to: for a chrominance block of a picture within a single non-overlapping rectangular area: determine a luminance non-overlapping rectangular area including a luminance block co-located with the position of the chrominance block, determine a scaling factor based on an average value of reconstructed luminance samples, wherein the reconstructed luminance samples belong to the lower and / or right columns of luminance samples of luminance non-overlapping rectangular areas adjacent to the luminance non-overlapping rectangular area above and / or to the left of the luminance non-overlapping rectangular area containing the current chrominance block, and scale the chrominance block residual according to the scaling factor.

[0008] According to a general aspect of at least one embodiment, a method for decoding video data is proposed, comprising:

[0009] - enabling cross-component correlation tools to be used for the chroma block of the picture in response to the size of the chroma block and the size of at least one luminance block co-located with the chroma block;

[0010] - In response to said enabling of said cross-component correlation tool, decoding said chroma block.

[0011] According to a general aspect of at least one embodiment, an apparatus for decoding video data is provided, comprising one or more processors, the one or more processors being configured to perform:

[0012] - enabling cross-component correlation tools to be used for chroma blocks of a picture in response to the size of the chroma block and the size of at least one luminance block co-located with the chroma block; and

[0013] - In response to said enabling of said cross-component correlation tool, decoding said chroma block.

[0014] According to another general aspect of at least one embodiment, a bitstream is formatted to include a signal generated according to the above-described encoding method.

[0015] According to a general aspect of at least one embodiment, a method for encoding video data is proposed, comprising:

[0016] - enabling cross-component correlation tools to be used for chroma blocks of a picture in response to a size of the chroma block and a size of at least one luminance block co-located with the chroma block;

[0017] - In response to said enabling of said cross-component correlation tool, encoding said chroma block.

[0018] According to a general aspect of at least one embodiment, an apparatus for encoding video data is provided, comprising one or more processors configured to perform:

[0019] - enabling cross-component correlation tools to be used for chroma blocks of a picture in response to the size of the chroma block and the size of at least one luminance block co-located with the chroma block; and

[0020] - In response to said enabling of said cross-component correlation tool, encoding said chroma block.

[0021] According to another general aspect of at least one embodiment, a bitstream is formatted to include a signal generated according to the above-described encoding method.

[0022] According to another general aspect, a method for decoding or encoding a video or an apparatus for decoding or encoding a video further comprises determining a position of a given sample position in a chroma block in a picture, determining a co-located luminance block, the co-located luminance block being a luminance block comprising luminance samples co-located with the position in the chroma block, determining neighboring luminance samples of the co-located luminance block, determining a luminance value from the determined neighboring luminance samples, determining a scaling factor based on the determined luminance value, and applying scaling of the chroma block residual according to the scaling factor.

[0023] One or more of the embodiments also provide a computer-readable storage medium on which instructions for encoding or decoding video data according to at least a portion of any of the above methods are stored. One or more embodiments also provide a computer-readable storage medium on which a bit stream generated according to the above encoding method is stored. One or more embodiments also provide a method and apparatus for sending or receiving a bit stream generated according to the above encoding method. One or more embodiments also provide a computer program product including instructions for executing at least a portion of any of the above methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 Depicts the Codec Tree Unit (CTU);

[0025] Figure 2 depicts a codec tree unit divided into a codec unit, a prediction unit, and a transform unit;

[0026] Figure 3 and Figure 4 depicts a CTU divided into codec units using a quadtree plus binary tree (QTBT);

[0027] Figure 5 The partitioning pattern of the codec unit defined by the quadtree plus binary tree codec tool is shown;

[0028] Figure 6 Additional partitioning modes of the codec unit are shown, for example, an asymmetric binary partitioning mode and a ternary tree partitioning mode;

[0029] Figure 7 depicts a flow chart of a method for enabling or disabling cross-component dependent codec tools according to one embodiment;

[0030] Fig. 8A , 8B , 8C, 8D show the Figure 7 Principles of enabling / disabling cross-component dependent codec tools of an embodiment;

[0031] Fig. 9 depicts a flow chart of a method for enabling or disabling cross-component dependent codec tools according to one embodiment;

[0032] Fig.10 shows a chroma block and its co-located luminance block according to an example;

[0033] Fig.11 Shown according to Fig. 9 Principles of enabling / disabling cross-component dependent codec tools of an embodiment;

[0034] Fig.11A A simplified block diagram of CCLM process activation is provided in;

[0035] Fig. 11B A simplified block diagram depicting an example of an index selection process from a history list;

[0036] Fig. 11C The process considering a luma ARA of size 32×32 and a chroma ARA of size 16×16 is shown;

[0037] Figure 11D-11G The case where the constraints are followed is shown;

[0038] Fig.12 depicts a flow chart of a method for enabling or disabling cross-component dependent codec tools according to one embodiment;

[0039] Fig.13 and Fig.14 Shown according to Fig.12Principles of enabling / disabling cross-component dependent codec tools of an embodiment;

[0040] Fig.15 depicts a flow chart of a method for enabling or disabling cross-component dependent codec tools according to one embodiment;

[0041] Fig.16 Shown according to Fig.15 Principles of enabling / disabling cross-component dependent codec tools of an embodiment;

[0042] Fig.17 depicts a flow chart of a method for obtaining a scaling factor or scaling factor index for a chroma block according to one embodiment;

[0043] Fig.18 Depicts the current chroma block and some neighboring chroma blocks;

[0044] Fig.19 , 20 and 21 show the principle of enabling / disabling cross-component dependent codec tools according to an embodiment;

[0045] Fig. 22 depicts a flow chart of a method for determining a scaling factor to be used in chroma residual scaling according to one embodiment;

[0046] Fig.23A , 23B , 23C and 23D depict chrominance blocks and co-located luminance blocks;

[0047] Fig.24A and 24B An example of the distance between the top left neighboring luma sample and the neighboring chroma sample is shown;

[0048] Fig.25 depicts a flow chart of a method for checking luma sample availability based on its co-located chroma samples and based on chroma samples of a current block;

[0049] Fig.25A The splitting of luma VDPU and chroma VDPU is shown;

[0050] Fig.26 shows a block diagram of a video encoder according to an embodiment;

[0051] Fig. 27 A block diagram of a video decoder according to an embodiment is shown; and

[0052] Fig.28 A block diagram is shown of an example of a system in which various aspects and embodiments may be implemented. DETAILED DESCRIPTION

[0053] In the HEVC codec, a picture is partitioned into CTUs of square shape with configurable sizes, usually 64×64, 128×128 or 256×256. A CTU is the root of a quadtree that is partitioned into 4 equally sized square codec units (CUs), i.e. Figure 1 Half the size of the parent block in the depicted width and height. A quadtree is a tree in which a parent node can be partitioned into four child nodes, each of which can become a parent node for another partition into four child nodes. In HEVC, a codec block (CB) is partitioned into one or more prediction blocks (PBs) and forms the root of a quadtree partitioned into transform blocks (TBs). Corresponding to the codec blocks, prediction blocks, and transform blocks, a codec unit (CU) includes a prediction unit (PU) and a tree-structured set of transform units (TUs), the PU includes prediction information (e.g., intra or inter prediction parameters) for all color components, and the TU includes a residual codec syntax structure for each color component, such as Figure 2 As depicted. Intra or inter coding mode is assigned to a CU. The sizes of CB, PB, and TB of the luma component are applicable to the corresponding CU, PU, ​​and TU.

[0054] In recent coding systems, CTU is the root of the codec tree that is divided into codec units (CUs). The codec tree is a tree in which a parent node (usually corresponding to a block) can be divided into child nodes (e.g., divided into 2, 3, or 4 child nodes), each of which can become a parent node for another division into child nodes. In addition to the quadtree partition mode, new partition modes (binary tree symmetric partition mode, binary tree asymmetric partition mode, and ternary tree partition mode) that increase the total number of possible partition modes are defined. The codec tree has a unique root node, such as CTU. The leaves of the codec tree are the termination nodes of the tree. Each node of the codec tree represents a block that can be further divided into smaller blocks also called sub-blocks. Once the partition of CTU to CU is determined, the CU corresponding to the leaf of the codec tree is encoded. The partition of CTU to CU and the encoding parameters for encoding each CU (corresponding to the leaf of the codec tree) can be determined on the encoder side by a rate-distortion optimization process.

[0055] Figure 3 Represents the partitioning of CTU into CU, where the codec unit can be divided according to both quadtree partitioning mode and symmetric binary tree partitioning mode. This type of partitioning is called QTBT (quadtree plus binary tree). Symmetric binary tree partitioning mode is defined to allow a CU to be partitioned horizontally or vertically into two codec units of equal size. Figure 3 , the solid line indicates a quadtree partition, and the dashed line indicates a binary partition of a CU into a symmetric CU. Figure 4 Represents the associated codec tree. Figure 4Above, solid lines represent quadtree partitions, and dashed lines represent binary partitions that are spatially embedded in the leaves of the quadtree. Figure 5 Depicted Figure 3 There are 4 split modes used in . Mode NO_SPLIT indicates that the CU is not further split. Mode QT_SPLIT indicates that the CU is divided into 4 quadrants according to the quadtree, and the quadrants are separated by two split lines. Mode HOR indicates that the CU is split horizontally into two CUs of equal size separated by one split line. VER indicates that the CU is split vertically into two CUs of equal size separated by one split line. The split line is Figure 5 The dotted line in .

[0056] In case of QTBT partitioning, the CU has a square or rectangular shape. The size of the codec unit is a power of 2 and usually varies from 4 to 128 in both directions (horizontally and vertically). QTBT has several differences from HEVC partitioning.

[0057] First, the QTBT partitioning of a CTU consists of two stages. First, the CTU is partitioned in a quadtree manner. Then, each quadtree leaf can be further partitioned in a binary manner. Figure 3 , where the solid line represents the quadtree decomposition stage and the dashed line represents the binary decomposition spatially embedded in the leaves of the quadtree.

[0058] Second, the luma and chroma block partitioning structures can be separated and determined independently, especially in intra slices.

[0059] Additional types of partitioning may also be used. An asymmetric binary tree (ABT) partitioning mode is defined to allow a CU to be partitioned horizontally into two codec units with corresponding rectangular sizes (w, h / 4) and (w, 3h / 4), or vertically into two codec units with corresponding rectangular sizes (w / 4, h) and (3w / 4, h), such as Figure 6 The two codec units consist of Figure 6 The dashed line separates them.

[0060] Figure 6 A ternary tree partitioning mode is also shown, according to which the codec unit is divided into three codec units in the vertical and horizontal directions. In the horizontal direction, the CU is divided into three codec units of corresponding sizes (w, h / 4), (w, h / 2) and (w, h / 4). In the vertical direction, the CU is divided into three codec units of corresponding sizes (w / 4, h), (w / 2, h) and (w / 4, h).

[0061] The partitioning of the codec unit is decided at the encoder side by rate-distortion optimization, which consists in determining the representation of the CTU with the minimum rate-distortion cost.

[0062] In this application, the term "block" or "picture block" may be used to refer to any of CTU, CU, PU, ​​TU, CB, PB, and TB. In addition, the term "block" or "picture block" may be used to refer to macroblocks, partitions, and sub-blocks specified in H.264 / AVC or other video codec standards, and more generally to sample arrays of many sizes.

[0063] In this application, the terms "reconstruction" and "decoding" are used interchangeably, the terms "pixel" and "sample" are used interchangeably, and the terms "image", "slice", "tile (title)", "picture" and "frame" are used interchangeably. Usually, but not necessarily, the term "reconstruction" is used on the encoder side, and "decoding" is used on the decoder side.

[0064] Using these new topologies can significantly improve codec efficiency. Specifically, significant gains for chroma components are obtained. This gain comes from the separation / independence of the luma and chroma codec trees (or partitions).

[0065] However, this separation of luma and chroma codec trees at CTU level has some problems in terms of hardware implementation. The size of a CTU is typically 128×128 or 256×256. Completely separate codec trees for luma and chroma components means that these are also completely separated in the compressed domain and therefore also appear in the coded bitstream in a separate manner. This leads to some problems for decoder implementations, where one wants to ensure that the decoding pipeline can be implemented on a maximum decoding unit size that may be smaller than the CTU size. Typically, for some decoder implementations, a 64×64 based decoder pipeline is desired. For this reason, a maximum transform block size equal to 64×64 was chosen in the Generic Video Codec Test Model.

[0066] Combining the use of separate luma / chroma codec trees with codec tools involving interdependencies between chroma and its co-located samples (e.g. luma-dependent chroma residual scaling) can be problematic. Indeed, in order to process a chroma block, luma samples of the luma block co-located with the chroma block under consideration must be processed before the chroma blocks. If the luma blocks are of large size, this can result in high structural pipeline delays before the chroma blocks can be processed.

[0067] At least one embodiment applies constraints on the combined use of separate luma / chroma codec trees and codec tools involving interdependencies between chroma and its co-located luma samples (e.g., chroma residual scaling, cross-component linear model called CCLM) in response to the size of at least one luma codec block co-located with a chroma codec block.

[0068] At least one embodiment enables or disables component interdependence codec tools (e.g., luma-dependent chroma residual scaling of chroma codec blocks) in response to the size (or horizontal / vertical dimensions) of the chroma codec block and the size (or horizontal / vertical dimensions) of the luma codec block co-located with samples of the chroma codec block under consideration.

[0069] At least one embodiment provides a solution for chroma blocks in case chroma residual scaling is disabled due to the above-mentioned constraints on the combined use of separate luma / chroma codec trees and chroma residual scaling.

[0070] Luma-dependent chroma residual scaling is an example of a codec tool that involves interdependencies between chroma and its co-located luma samples. Luma-dependent chroma residual scaling is disclosed in JVET-M0427, entitled "CE12: Mapping functions (test CE12-1 and CE12-2)" by Lu et al. Luma-dependent chroma residual scaling involves the use of a scaling or inverse scaling table indexed by luma values. The table is either explicitly signaled in the stream or derived from a table encoded and decoded in the stream.

[0071] On the encoder side, the process works as follows. When encoding a chroma block, a luma value representing the co-located luma block is calculated. This is typically the average of the luma samples in the luma prediction (or reconstruction) block co-located with the chroma block in question. Based on the calculated luma value, a scaling value is picked from a scaling table. The scaling value is applied as a multiplication factor to the residual of the chroma prediction before applying the transform and then quantization to the chroma residual signal.

[0072] On the decoder side, the process works as follows. When decoding a chroma block, a luma value representing the luma block co-located with the chroma block in question is calculated. This is typically the average of the luma samples in the luma prediction (or reconstruction) block co-located with the chroma block in question. Based on the calculated luma value, an inverse scaling value is picked from an inverse scaling table signaled in the stream, or derived from data signaled in the stream. The inverse scaling value is applied to the residual of the chroma prediction, after inverse quantization and then inverse transform have been applied.

[0073] JVET-M0427 recommends disabling chroma residual scaling when using separate luma / chroma codec trees. This solution incurs a codec loss for the chroma components.

[0074] In various embodiments, separate luma / chroma tree partitioning is enabled, ie, luma and chroma partitioning can be achieved independently. The proposed embodiments improve the encoding and decoding efficiency, especially for chroma components.

[0075] In the following, the chroma format is considered to be 4:2:0, i.e. the dimension of the chroma component is half the dimension of the luma component. However, it should be understood that the present embodiment is not limited to this particular chroma format. Other chroma formats can be used by modifying the ratio between the luma dimension and the chroma dimension.

[0076] For simplicity and readability, in the following figures, the same resolution is depicted for luma and chroma components, even if the actual resolution is different, such as, for example, in the case of a 4:2:0 chroma format. In such cases, a simple scaling should be applied to the chroma pictures.

[0077] With separate luma / chroma tree partitioning enabled, a maximum horizontal / vertical dimension Wmax / Hmax is specified which constrains the use of luma-dependent chroma residual scaling for a given coded chroma block. The picture is partitioned into non-overlapping rectangular regions of size Wmax / Hmax for luma and size WmaxC / HmaxC for chroma (typically with size Wmax=Hmax=32 for luma or WmaxC=HmaxC=16 for chroma), hereinafter referred to as "Authorized Rectangular Areas" (ARA). In a number of variant embodiments, luma-dependent chroma residual scaling (hereinafter labeled LDCRS) activation is adjusted to the position and size of the chroma blocks and the position and size of the luma blocks co-located with the chroma blocks associated with the ARA grid.

[0078] Various embodiments refer to a luma block co-located with the chroma block under consideration. A luma block co-located with a chroma block may be defined as:

[0079] - Luma blocks contain pixels that are co-located with a given position in a chroma block, such as

[0080] o The center of the chroma block, for example, which is defined as the relative position in the chroma block ((x0+Wc) / 2, (y0+Hc) / 2), where (x0, y0) corresponds to the relative position in the chroma picture of the top left sample of the chroma block, and (Wc, Hc) are the horizontal / vertical dimensions of the chroma block

[0081] o The upper left position in the chroma block, which is defined as the relative position (x0, y0) in the chroma picture

[0082] o The lower right position in the chroma block, which is defined as the relative position in the chroma picture (x0+Wc-1, y0+Hc-1)

[0083] o The upper right position in the chroma block, which is defined as the relative position (x0+Wc-1, y0) in the chroma picture.

[0084] o The lower left position in the chroma block, which is defined as the relative position (x0, y0+Hc-1) in the chroma picture.

[0085] - Luma blocks co-located with a number of given positions in the chroma blocks, such as the luma blocks mentioned above; for example, consider a luma block co-located with the 4 chroma block positions of top left, top right, bottom left, and bottom right (see Fig.10 );or

[0086] - Luma blocks that are co-located with all chroma sample positions of the chroma block under consideration

[0087] Example 1 - Disabling LDCRS when chroma blocks cross ARA boundaries

[0088] In at least one embodiment, if the chroma block under consideration is not completely contained within a single chroma ARA, then LDCRS is disabled. This corresponds to the following equation:

[0089] If ((x0 / WmaxC)!=((x0+Wc-1) / WmaxC))||((y0 / HmaxC)!=((y0+Hc-1) / HmaxC)), then LDCRS is disabled.

[0090] Here, x||y is the Boolean logical "or" of x and y, and "!=" means "not equal to".

[0091] A simplified block diagram of the process is shown in Figure 7 Step 300 checks whether the chroma block is within a single chroma ARA. If the condition is true, then LDCRS is enabled (step 303). If the condition is false, then LDCRS is disabled (step 302).

[0092] Fig. 8A , 8B , 8C, 8D show some cases of chroma segmentation, where the gray blocks correspond to chroma blocks in which LDCRS is enabled, and the white blocks correspond to chroma blocks in which LDCRS is disabled. The chroma blocks are depicted by thick black lines. The grid defined by WmaxC and HmaxC is indicated by dotted lines.

[0093] -exist Fig. 8A In , 2 chroma blocks span several chroma ARAs; according to the current embodiment, LDCRS is disabled for both chroma blocks.

[0094] -exist Figure 8B In the example, two chroma blocks are within one chroma ARA; according to the current embodiment, LDCRS is enabled for both chroma blocks.

[0095] -exist Figure 8C , 1 rectangular vertical chroma block spans two chroma ARAs; according to the current embodiment, LDCRS is disabled for this chroma block. All other chroma blocks are within one chroma ARA, and therefore LDCRS can be enabled for those chroma blocks.

[0096] -exist Fig.8D In , one horizontal chroma block spans two chroma ARAs; according to the current embodiment, LDCRS is disabled for this chroma block. All other chroma blocks are within one chroma ARA, and therefore LDCRS can be enabled for those chroma blocks.

[0097] Embodiment 2 - In the case where a chroma block crosses a chroma ARA boundary or at least one of the co-located luminance blocks crosses a co-located Disable LDCRS in case of ARA boundary

[0098] In an embodiment, LDCRS is disabled if at least one of the following conditions is true:

[0099] • The chroma block under consideration is not fully contained in a single chroma ARA.

[0100] • At least one of the luma blocks co-located with the chroma block under consideration is not fully contained in the luma ARA co-located with the chroma ARA, ie crosses a co-located luma ARA boundary.

[0101] A simplified block diagram of the process is shown in Fig. 9 4. Step 400 checks if the chroma blocks are within a single chroma ARA. If the condition is false, then LDCRS is disabled (step 401). If the condition is true, then the luma blocks co-located with the chroma block in question are identified (step 402). Step 403 checks if all co-located luma blocks are within the luma ARA co-located with the chroma ARA. If the condition is false, then LDCRS is disabled (step 404). If the condition is true, then LDCRS is enabled (step 405).

[0102] Fig.11 Two examples of the current embodiment are provided. In the top of the figure, the chroma block is contained within a single chroma ARA (top left), and there are 3 co-located luma blocks (co-located luma blocks 1, 2, and 3, top right). Two of them (co-located luma blocks 1 and 2, in the dashed blocks) are within the co-located luma ARA, while the third (co-located luma block 3) is outside the co-located luma ARA. Because the third luma block is outside the co-located luma ARA, LDCRS is disabled according to the current embodiment.

[0103] In the lower part of the figure, the chroma block is contained within a single chroma ARA, and has 3 co-located luma blocks (co-located luma blocks 1, 2, and 3). Three of them are within the co-located luma ARA. LDCRS is enabled according to the current embodiment.

[0104] The current VVC specification supports three types of partitioning: quadtree (QT), binary tree (BT, horizontal or vertical) and ternary tree (TT, horizontal or vertical), such as Figure 5 and Figure 6As shown. In a variant, BT and TT partitioning is enabled from a given ARA dimension (e.g., 32×32 for luma and 16×16 for chroma when considering a 4:2:0 chroma format). Above this dimension, only QT partitioning is enabled or no partitioning is enabled. Therefore, except for the case of "no partitioning" for blocks larger than the luma ARA / chroma ARA dimension (e.g., no partitioning into 4 32×32 blocks for a luma block 64×64), the conditions presented in embodiments 1 and 2 are systematically met.

[0105] In at least one embodiment, BT and TT splitting is enabled only for luma block sizes less than or equal to 32×32 or chroma block sizes less than or equal to 16×16 (when using 4:2:0 chroma format). Above that size, only QT splitting is enabled (or no splitting is enabled). This constraint involves mode LDCRS or mode CCLM. The process is Fig. 11C As shown in FIG, a luma ARA of size 32×32 and a chroma ARA of size 16×16 are considered. At step 1300, it is checked whether the block under consideration is a luma block of size greater than or equal to 64×64 or a chroma block of size greater than or equal to 32×32. If the test is true, step 1301 disables BT and TT partitioning while enabling no partitioning and QT partitioning. If the test is false, step 1302 enables no partitioning, QT, BT, and TT partitioning.

[0106] In at least one embodiment, in order to reduce the delay in processing chroma in mode LDCRS or CCLM, when a square luma block larger than the luma ARA is not divided, the corresponding chroma block can be divided into 4 blocks only through QT division, and the 4 blocks can be further divided or not divided at all. For example, considering a luma ARA of size 32×32 and a chroma ARA of size 16×16, when a square luma block of size 64×64 is not divided, the corresponding chroma block (of size 32×32, in 4:2:0 format) can only be divided into 4 16×16 blocks through QT division, and the 4 16×16 blocks can be further divided (dashed lines in the figure) or not divided at all. The situation following these constraints is as follows Fig.11D shown.

[0107] In at least one embodiment, in order to reduce the delay in processing chroma in mode LDCRS or CCLM, when a square luminance block larger than the luminance ARA is divided into 4 blocks by QT division, the corresponding chroma block can be divided into 4 blocks only by QT division, and the 4 blocks can be further divided or not divided at all. For example, considering a luminance ARA of size 32×32 and a chroma ARA of size 16×16, when a square luminance block of size 64×64 is divided into 4 32×32 blocks, the corresponding chroma block (of size 32×32, in 4:2:0 format) can be divided into 4 16×16 blocks only by QT division, and the 4 16×16 blocks can be further divided (dashed lines in the figure) or not divided at all. The situation following these restrictions is as follows Fig.11E shown.

[0108] In at least one embodiment, in order to reduce the delay in processing chroma in mode LDCRS or CCLM, when a square luma block larger than the luma ARA is divided into 2 blocks by horizontal BT partitioning, the corresponding chroma block can only be divided into 2 blocks by horizontal BT partitioning, or divided into 4 blocks by QT partitioning. For example, considering a luma ARA of size 32×32 and a chroma ARA of size 16×16, when a square luma block of size 64×64 is divided into 2 blocks of 32 rows and 64 columns, the corresponding chroma block (of size 32×32 in 4:2:0 format) can only be divided into 2 blocks of 16 rows and 32 columns by horizontal BT partitioning, or divided into 4 16×16 blocks by QT partitioning. The case following these restrictions is as follows Fig.11F shown.

[0109] In at least one embodiment, in order to reduce the delay in processing chrominance in mode LDCRS or CCLM, when a square luminance block larger than the luminance ARA is not divided or is divided into 4 blocks by QT division or is divided into 2 blocks by horizontal QT division, the corresponding chrominance block cannot be divided into 2 blocks by vertical binary division, but can be divided into 4 blocks by QT division, or divided into 2 blocks by horizontal BT division, or not divided.

[0110] In at least one embodiment, in order to reduce the latency of processing chroma in the case of mode LDCRS or CCLM, when a square luma block larger than the luma ARA is divided into 2 blocks by vertical BT division, the corresponding chroma block can only be divided into 2 blocks by vertical BT division. For example, considering a luma ARA of size 32×32 and a chroma ARA of size 16×16, when a square luma block of size 64×64 is divided into 2 blocks of 64 rows and 32 columns, the corresponding chroma block can only be divided into 2 blocks of 32 rows and 16 columns. The case following these restrictions is as follows Fig.11Gshown.

[0111] Syntax example based on the VTM5.0 syntax described in document JVET-N1001 (version 9 - date 2019-06-25 13:45:21)

[0112] The following small print text corresponds to an example of syntax, which corresponds to an example implementation of the above-described embodiment, based on the syntax described in document JVET-N1001 version 9. The section numbers correspond to the numbers used in JVET-N1001 version 9.

[0113] Version that prohibits BT / TT partitioning for blocks larger than VDPU

[0114] The syntax description below corresponds to an embodiment of constrained partitioning as described above. Changes to the VTM5 v9 specification are highlighted in grey.

[0115] 6.4.2 Allowable binary partitioning processes

[0116] The inputs to this process are:

[0117] -Binary split mode btSplit,

[0118] - codec block width cbWidth in luma samples,

[0119] -cbHeight, the codec height in luma samples,

[0120] - the position (x0, y0) of the top-left luma sample of the considered codec block relative to the top-left luma sample of the picture,

[0121] -Multi-type tree depth mttDepth,

[0122] - maximum multi-type tree depth maxMttDepth with offset,

[0123] - Maximum binary tree size maxBtSize,

[0124] - Split index partIdx,

[0125] - The variable treeType specifies whether a single tree (SINGLE_TREE) or a dual tree is used to split the CTU, and when a dual tree is used, whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently being processed. The output of this process is the variable allowBtSplit.

[0126] Table 6-2 - Specification of parallelTtSplit and cbSize based on btSplit.

[0127] btSplit==SPLIT_BT_VER btSplit == SPLIT_BT_HOR parallelTtSplit SPLIT_TT_VER SPLIT_TT_HOR cbSize cbWidth cbHeight

[0128] The variables parallelTtSplit and cbSize are exported as specified in Table 6-2.

[0129] The variable allowBtSplit is exported as follows:

[0130] - allowBtSplit is set equal to false if one or more of the following conditions are true:

[0131] -cbSize is less than or equal to MinBtSizeY

[0132] -cbWidth is greater than maxBtSize

[0133] -cbHeight is greater than maxBtSize

[0134]

[0135] -mttDepth is greater than or equal to maxMttDepth

[0136] -treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16 [Ed.(SL):

[0137] Is "less than or" needed here?]

[0138] - Otherwise, if all of the following conditions are true, allowBtSplit is set equal to false

[0139] …

[0140] - Otherwise, allowBtSplit is set equal to true. 6.4.2 Allowed ternary splitting processes

[0141] The inputs to this process are:

[0142] - ternary split mode ttSplit,

[0143] - codec block width cbWidth in luma samples,

[0144] - codec block height cbHeight in luma samples,

[0145] - the position (x0, y0) of the top-left luma sample of the considered codec block relative to the top-left luma sample of the picture,

[0146] -Multi-type tree depth mttDepth,

[0147] - maximum multi-type tree depth maxMttDepth with offset,

[0148] -Maximum ternary tree size maxTtSize,

[0149] - The variable treeType specifies whether a single tree (SINGLE_TREE) or a dual tree is used to split the CTU, and when a dual tree is used, whether the luma component (DUAL_TREE_LUMA) or the chroma component (DUAL_TREE_CHROMA) is currently being processed. The output of this process is the variable allowTtSplit.

[0150] Table 6-3 - Specification of cbSize based on ttSplit.

[0151] ttSplit==SPLIT_TT_VER ttSplit==SPLIT_TT_HOR cbSize cbWidth cbHeight

[0152] The variable cbSize is exported as specified in Table 6-3.

[0153] The variable allowTtSplit is exported as follows:

[0154] - allowTtSplit is set equal to false if one or more of the following conditions are true:

[0155] -cbSize is less than or equal to 2*MinTtSizeY

[0156] -cbWidth is greater than Min(MaxTbSizeY,maxTtSize)

[0157] -cbHeight is greater than Min(MaxTbSizeY,maxTtSize)

[0158]

[0159] -mttDepth is greater than or equal to maxMttDepth

[0160] -x0+cbWidth is greater than pic_width_in_luma_samples

[0161] -y0+cbHeight is greater than pic_height_in_luma_samples

[0162] -treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0163] - Otherwise, allowTtSplit is set equal to true.

[0164] If VDPU is divided into BT or TT, the version of CCLM is prohibited

[0165] The following syntax description corresponds to an embodiment where CCLM (or CRS) is not enabled for segmentation without respecting the above segmentation constraints. For example, CCLM is disabled when the size of the chroma block is 32×16, 16×32, or when its co-located luma block is 64×32 or 32×64. For other cases, CCLM (or CRS) is enabled. Changes to the VTM5 v9 specification are highlighted in gray.

[0166] 1.1.1 Derivation process for chroma intra prediction mode

[0167] The inputs to this process are:

[0168] - luma position (xCb, yCb) which specifies the top left sample of the current chroma codec block relative to the top left luma sample of the current picture,

[0169] - the variable cbWidth, which specifies the width of the current codec block in luma samples,

[0170] - The variable cbHeight specifies the height of the current codec block in luma samples.

[0171]

[0172] During this process, the chroma intra prediction mode IntraPredModeC[xCb][yCb] is derived.

[0173] The corresponding luma intra prediction mode lumaIntraPredMode is derived as follows:

[0174] - If intra_mip_flag[xCb][yCb] is equal to 1, use IntraPredModeY[xCb+

[0175] lumaIntraPredMode is derived with sizeId set equal to MipSizeId[xCb][yCb] as specified in Table 8-4.

[0176] - Otherwise, lumaIntraPredMode is set equal to IntraPredModeY[xCb+

[0177] cbWidth / 2][yCb+cbHeight / 2].

[0178]

[0179] The chroma intra prediction mode IntraPredModeC[xCb][yCb] is derived using intra_chroma_pred_mode[xCb][yCb] and lumaIntraPredMode as specified in Table 8-5 and Table 8-6.

[0180] Table 8-5-When When it is equal to 0, it depends on

[0181] Specification of intra_chroma_pred_mode[xCb][yCb] and IntraPredModeC[xCb][yCb] of lumaIntraPredMode

[0182]

[0183] Table 8-6-When When it is equal to 1, it depends on

[0184] Specification of intra_chroma_pred_mode[xCb][yCb] and IntraPredModeC[xCb][yCb] of lumaIntraPredMode

[0185]

[0186] When chroma_format_idc is equal to 2, chroma intra prediction mode Y is derived using chroma intra prediction mode X in Tables 8-5 and 8-6 as specified in Table 8-7, and then chroma intra prediction mode X is set equal to chroma intra prediction mode Y.

[0187] Table 8-7 – Specification of the 4:2:2 mapping process from chroma intra prediction mode X to mode Y when chroma_format_idc is equal to 2

[0188]

[0189]

[0190] Example 2a - Variant using inference enable flag for luminance ARA; generalization to CCLM

[0191] The concepts described above may also be applied to other luma-to-chroma modes, such as CCLM.

[0192] In a variation of Embodiment 2, CCLM (or LDCRS) is disabled if at least one of the following conditions is true:

[0193] • The chroma block under consideration is not fully contained in a single chroma ARA.

[0194] • A luma ARA co-located with a chroma ARA contains at least one luma block that is not completely within the luma ARA, ie, one luma block that straddles the boundary of the co-located luma ARA.

[0195] This can be achieved by using an inferred flag, referred to below as luma_blocks_inside_flag, assigned to each luma ARA. For each luma ARA, the flag is inferred from the luma segmentation tree (selected in the encoder or parsed in the decoder). Once the luma segmentation tree is generated for a CTU (or VDPU), the flag for each luma ARA of the CTU (or VDPU) is inferred as follows. If all luma blocks of a given luma ARA are strictly included in the luma ARA, the flag is set to true. Otherwise, if at least one luma block crosses one or more of the luma ARA boundaries, the flag is set to false.

[0196] The flag can then be used as follows. Conditions (as above):

[0197] • A luma ARA co-located with a chroma ARA contains at least one luma block that is not completely within the luma ARA, ie, one luma block that straddles the boundary of the co-located luma ARA.

[0198] It can be equivalently expressed as follows:

[0199] The luma_blocks_inside_flag flag of the luma ARA co-located with the chroma ARA is false.

[0200] Example 2b - Enable LDCR or CCLM if it is within its co-located luminance block

[0201] In another variation, if a chroma block is not completely within its co-located luma block, the luma-dependent mode (LDCRS or CCLM) is disabled.

[0202] This can be expressed as follows. If one of the following conditions is false, then LDCRS or CCLM is disabled:

[0203] A luma block (at position (x0, y0) and of size (Wc, Hc)) co-located with the top left sample of the chroma block is within a 32x32 chroma block

[0204] xColocY<=2*x0

[0205] ·xClocY+wClocY–1>=2*(x0+Wc-1)

[0206] yColocY<=2*y0

[0207] ·yColocY+hColocY–1>=2*(y0+Hc-1)

[0208] (xColocY, yColocY) is the top left sample position of the luma block co-located with the top left sample of the chroma block, and (wColocY, hColocY) are the dimensions of this luma block.

[0209] Example 2c - Using fallback mode when LDCRS or CCLM is disabled

[0210] At least one embodiment relates to CCLM mode (and its variant MDLM). In this embodiment, it is considered that there is a regular CCLM mode, plus a fallback CCLM mode. When the regular CCLM mode is not enabled due to the constraints described in this application, the fallback CCLM can be used.

[0211] Fig.11A The block diagram in provides a simplified block diagram of CCLM process activation. At step 112, the conditions for activating the conventional CCLM mode for a given chroma block are checked (such conditions are described in various embodiments of the current application). If all enabling conditions are met for a given chroma block, the conventional CCLM mode is enabled and can be used by the encoder / decoder (113). If one of the enabling conditions is not met for a given chroma block, the conventional CCLM mode is disabled, and the fallback CCLM mode is enabled and can be used by the encoder / decoder (114).

[0212] In at least one embodiment, a conventional CCLM mode corresponds to a mode in which CCLM parameters are derived from luma and chroma samples in the immediate neighborhood of the chroma block under consideration (e.g., chroma samples belonging to one or two rows above the chroma block and their co-located luma samples, and / or chroma samples belonging to one or two columns to the left of the chroma block and their co-located chroma samples).

[0213] Possible fallback CCLM mode

[0214] In at least one embodiment, the fallback CCLM mode uses CCLM parameters derived from chrominance and luma samples adjacent to the current CTU, for example, one or two rows above the CTU and / or one or two columns to the left of the CTU.

[0215] In at least one embodiment, the fallback CCLM mode uses CCLM parameters derived from chrominance and luma samples adjacent to the current VDPU, such as using one or two rows above the VDPU and / or one or two columns to the left of the VDPU.

[0216] In at least one embodiment, the fallback CCLM mode uses CCLM parameters derived from chroma and luma samples adjacent to the current 16×16 chroma ARA and its 32×32 corresponding luma ARA. For example, one or two rows above the current 16×16 chroma ARA and its 32×32 corresponding luma ARA and / or one or two columns to the left of the current 16×16 chroma ARA and its 32×32 corresponding luma ARA are used.

[0217] In at least one embodiment, the fallback CCLM mode uses CCLM parameters derived from luma samples adjacent to a luma block co-located with an upper left sample of a chroma block, and from chroma samples co-located to these luma samples.

[0218] In at least one embodiment, the fallback CCLM mode uses the most recently used CCLM parameters.

[0219] Use of CCLM parameter history list

[0220] In at least one embodiment, the fallback CCLM mode uses CCLM parameters from a history list of CCLM parameters built at the encoder and decoder. A maximum size Nh is specified for the history list. The history list is filled with the most recently used CCLM parameters. If a chroma block uses CCLM mode, its CCLM parameters are added to the history list. If the history list is full, the oldest CCLM parameters are removed and new CCLM parameters are inserted into the history list.

[0221] In one variation, new CCLM parameters are added to the history list only if they are different from CCLM parameters already present in the history list.

[0222] In one variant, if the chroma block is encoded using the fallback CCLM mode, an index to a CCLM parameter from a CCLM parameter history list is encoded for the chroma block.

[0223] In one variant, the index of the CCLM parameters from the history list is inferred based on a similarity check of luma and / or chroma samples in or around the chroma block with luma and / or chroma samples that have been used to calculate the CCLM parameters of the list.

[0224] One possible implementation of the latter variant is as follows. When inserting CCLM parameters into the history list, the average values ​​of the luminance samples used to derive the parameters are calculated and stored in the list. They are labeled avg_Ref_Y[idx], idx being the index in the history list of CCLM parameters (idx=0 to Nh-1, Nh being the size of the history list).

[0225] When CCLM mode is used for chroma blocks, the average of the luma samples (considering only available luma samples) adjacent to the chroma block is calculated. They are recorded as avg_Cur_Y.

[0226] The CCLM parameter index idx0 in the list for performing CCLM prediction of the chroma block is identified as the index that minimizes the absolute value of the difference between avg_Ref_Y[i] and avg_Cur_Y:

[0227] idx0=argmin(|avg_Cur_Y-avg_Ref_Y[idx]|)

[0228] The similarity measure may alternatively be based on chrominance samples. When the CCLM parameters are inserted into the history list, the average of the chrominance samples used to derive the parameters is calculated and stored into the list. They are labeled avg_Ref_Cb[idx], avg_Ref_Cr[idx].

[0229] When CCLM mode is used for chroma blocks, the average values ​​of chroma samples adjacent to the chroma block are calculated. They are marked as avg_Cur_Cb and avg_Cur_Cr.

[0230] The CCLM parameter index idx0 in the list for performing CCLM prediction of the chroma block is identified as the index that minimizes the absolute value of the difference between avg_Ref_Cb[idx], avg_Ref_Cr[idx] and avg_Cur_Cb, avg_Cur_Cr:

[0231] idx0=argmin(|avg_Cur_Cb-avg_Ref_Cb[idx]|

[0232] +|avg_Cur_Cr-avg_Ref_Cr[idx]|)

[0233] Fig. 11BA simplified block diagram of an example of an index selection process from a history list is depicted. The inputs to the process are the luma and / or chroma samples adjacent to the chroma block under consideration, and a history list. For each index i, the history list contains CCLM parameters and reference values ​​(e.g., avg_Ref_Y[i], avg_Ref_Cb[i], avg_Ref_Cr[i]) associated with the luma or chroma samples used to derive the CCLM parameters. In step 1200, a local value is calculated from adjacent luma or chroma samples (e.g., avg_Cur_Y, avg_Cur_Cb, avg_Cur_Cr) adjacent to the chroma block. In step 1201, the parameter distMin is set to a large value. In step 1202, loop over index = 0 to Nh-1. In step 1203, the distortion "dist" between the local value calculated in step 1200 and the reference value for index i. Step 1204 checks whether dist is lower than minDist. If true, then in step 1205, idx0 and minDist values ​​are updated, and then the process goes to step 1206. Otherwise (dist is not less than minDist), the process goes to step 1206. Step 1206 checks whether the loop over the history list index is complete. If so, idx0 is the output index value. If not, the process returns to step 1202 to check the next index.

[0234] Embodiment 3 - If the chroma blocks do not cross ARA boundaries and if at least one of the co-located luminance blocks does not cross co-located luminance boundaries ARA boundary, LDCR is enabled

[0235] In one embodiment, LDCRS is enabled when all of the following conditions are true:

[0236] The chroma block under consideration is fully contained in a single chroma ARA

[0237] • At least one of the luma blocks co-located with the chroma block under consideration is fully contained in the luma ARA co-located with the chroma ARA. Such luma blocks are hereinafter named "co-located enabled luma blocks".

[0238] A simplified block diagram of the process is shown in Fig.12 . Step 500 checks whether the chroma blocks are within a single chroma ARA. If the condition is false, then LDCRS is disabled (step 501). If the condition is true, then the luma blocks co-located with the chroma block under consideration are identified (step 502). Step 503 checks whether at least one of the co-located luma blocks is within a luma ARA co-located with the chroma ARA. If the condition is false, then LDCRS is disabled (step 504). If the condition is true, then LDCRS is enabled (step 505).

[0239] refer to Fig.13 (It shows Fig.11), LDCRS is enabled because the chroma blocks are within a single chroma ARA, and the co-located luminance blocks 1 and 2 are within the co-located luminance ARA, i.e., at least one of the luminance blocks co-located with the chroma block under consideration is completely contained in the luminance ARA co-located with the chroma ARA.

[0240] refer to Fig.14 , LDCRS is disabled because the chroma block covers two chroma ARAs (the first chroma ARA and the second chroma ARA) even though two of its co-located luminance blocks (co-located luminance blocks 1 and 2) are within the luminance ARA co-located with the first chroma ARA.

[0241] Embodiment 4 - Enabling LDCR when at least one of the co-located luma blocks does not cross a co-located luma ARA boundary

[0242] In an embodiment, even if the chroma block under consideration is not fully contained in a single chroma ARA, LDCRS may be enabled if at least one of the luma blocks co-located with the chroma block under consideration is fully contained in a luma ARA co-located with the first chroma ARA of the chroma block under consideration. In this embodiment, the chroma block under consideration may be larger than a single chroma ARA.

[0243] A simplified block diagram of the process is shown in Fig.15 . The luma blocks co-located with the chroma block under consideration are identified (step 600). Step 601 checks whether at least one of the co-located luma blocks is within a luma ARA co-located with the first chroma ARA. If the condition is false, then LDCRS is disabled (step 602). If the condition is true, then LDCRS is enabled (step 603).

[0244] Fig.16 Shown with Fig.14 Same partitioning. LDCRS is enabled because even though the chroma block covers two chroma ARAs (first chroma ARA and second chroma ARA), some of its co-located luma blocks (blocks 1 and 2) are within the luma ARA co-located with the first chroma ARA of the chroma block.

[0245] In a variation of the current embodiment, where LDCRS is enabled and activated for a chroma block, the scaling factors used to scale the chroma residual are derived only from luma samples belonging to a co-located enabled luma block. All chroma samples use the same scaling factor derived from only a portion of the co-located luma samples.

[0246] For example, consider Fig.16 In the case of , the average of the luma samples from co-located luma blocks 1 and 2 is calculated. This average luma value is used to identify the scaling factor to be applied to the entire chroma block residual. Therefore, the luma samples of luma block 3 are not used.

[0247] Embodiment 5: Signaling scaling factors for chroma blocks with LDCRS disabled

[0248] In an embodiment, in case a chroma block does benefit from luma-based scaling of the chroma residual, the chroma scaling factor is signaled in the bitstream.If the chroma block consists of several transform units, the chroma scaling factor is applied to the residual of each TU.

[0249] A simplified block diagram of the process is shown in Fig.17 . Step 700 checks whether LDCRS is enabled for the chroma block under consideration. If the condition is false, a scaling factor or scaling factor index is encoded / decoded (step 701). If the condition is true, a scaling factor or scaling factor index is derived from the co-located luma block (step 702).

[0250] In an embodiment, the index of the chroma scaling factor is signaled. In an embodiment, the scaling factor or the index of the scaling factor is predicted from the scaling factor or scaling factor index of one or several neighboring chroma blocks previously encoded / decoded. For example, Fig.18 As shown in , the scaling factors or scaling factor indices from the chroma blocks including block A, then block B if block A is not available, then block C if block A and block B are not available, and then block D if block A, block B, and block C are not available are used as predictors. Otherwise, the scaling factors or scaling factor indices are not predicted.

[0251] In a variant, the scaling factor is inferred by a prediction process using processed neighboring chroma blocks. No additional signaling is used and only the inferred scaling value is used for the considered chroma block.

[0252] Embodiment 6: Signaling differential QP for chroma blocks with LDCRS disabled

[0253] In an embodiment, in case a chroma block does benefit from luma-based scaling of the chroma residual, the difference QP parameter signaled in the bitstream may be used for that chroma block.If the chroma block consists of several transform units, the difference QP parameter is applied to the residual of each TU.

[0254] In an embodiment, differential QP parameters are signaled for chroma blocks.

[0255] In an embodiment, a differential QP parameter is signaled for a quantization group containing a chroma block.

[0256] In an embodiment, differential QP parameters are signaled for CTUs containing chroma blocks.

[0257] In an embodiment, the chroma QP parameters are predicted based on the QP values ​​or scaling factors from one or several neighboring chroma blocks that were previously encoded / decoded. Fig.18As shown in , the QP value or scaling factor from the chroma block including block A, then including block B if block A is not available, then including block C if block A and block B are not available, and then including block D if block A, block B, and block C are not available is used as the predictor.

[0258] In the case where the predictor is a scaling factor sc, this scaling factor used to predict the chroma QP is first converted to a QP-like value, denoted QPpred, using the following equation:

[0259] QPpred = -6*Log2(Sc)

[0260] Here, Log2 is a logarithmic function with 2 as the base.

[0261] In the case where the predicted value is a QP value, the QP value is used as the predicted value QPpred.

[0262] In a variant, the QP value is inferred by a prediction process using processed neighboring chroma blocks. No additional signaling is used, and only the inferred QP value is used for the chroma block under consideration.

[0263] Embodiment 7: Extension of other luminance-related chrominance coding and decoding modes

[0264] Embodiments disclosed regarding luma-based chroma residual scaling may be used with other luma-related chroma codec modes, or more generally with codec tools involving cross-component dependencies, such as chroma from luma intra prediction (also known as CCLM or LM mode, and its variant Multi-Directional Linear Model, also known as MDLM).

[0265] In an additional embodiment, in case of luma blocks with dimensions WL and HL greater than WmaxL and HmaxL, CCLM may be enabled only if the luma blocks are split in transform units of maximum dimensions WmaxL and HmaxL.

[0266] In the same way, in case of luma blocks with dimensions WL and HL larger than WmaxL and HmaxL, chroma residual scaling can be enabled only if the luma block is split in transform units of maximum dimensions WmaxL and HmaxL.

[0267] In an additional embodiment, in case of luma blocks with dimensions WL and HL greater than WmaxL and HmaxL, the luma blocks are then systematically divided in transform units of maximum size WmaxL and HmaxL. In this way, chroma residual scaling and / or CCLM modes may be used in chroma components without suffering the structural delay implied by the need to reconstruct the availability of co-located luma blocks in order to process the chroma blocks.

[0268] In an additional variant, in case the chroma block has dimensions Wc and Hc greater than WmaxC and HmaxC, then the chroma block is systematically divided in transform units of maximum size WmaxC and HmaxC. In this way, chroma residual scaling and / or CCLM mode can be used in chroma components regardless of the size of the chroma codec unit.

[0269] exist Fig.19 The examples in FIG. 4 show a luminance block divided into 2 TUs (left side) or 4 TUs (right side).

[0270] Therefore, in a variation, if the chroma block has dimensions Wc and Hc larger than WmaxC and HmaxC, CCLM may be enabled only if the chroma block is split in a transform unit of maximum dimensions WmaxC and HmaxC.

[0271] In the same way, if the chroma block has dimensions Wc and Hc larger than WmaxC and HmaxC, chroma residual scaling can be enabled only if the chroma block is split in a transform unit of maximum dimensions WmaxC and HmaxC.

[0272] Example 8: Deactivation of CTU's separate brightness / Chroma Tree

[0273] The CCLM mode uses reference luma and chroma samples to determine parameters that are further used to predict chroma block samples from their co-located luma samples. The reference luma and chroma samples are typically located at:

[0274] On the upper row adjacent to the chroma / co-located luminance block,

[0275] On the left column adjacent to the chroma / co-located luminance block,

[0276] • Possibly in the upper left position adjacent to the chroma / co-located luminance block. Depending on the CCLM mode considered, a combination of these three positions may be used.

[0277] In an embodiment, chroma reference samples for CCLM mode are considered available if they belong to chroma blocks included in the above / left / top-right neighboring chroma ARAs of the chroma ARAs including the chroma block under consideration ( Fig. 20 ). If the chroma reference samples are not included in the above / left / top-right neighboring chroma ARAs, they are considered unavailable.

[0278] Fig.21The case where the upper reference chroma samples for the chroma blocks (in the diagonally shaded rectangles above the chroma blocks) belong to different luma blocks (blocks 1, 3, and 4) and some of these luma blocks (blocks 3 and 4) are not within the adjacent upper chroma ARA is shown. According to an embodiment, only the reference samples belonging to block 1 are considered available. The other reference samples from blocks 3 and 4 are not available for CCLM mode.

[0279] In a variation, if a given proportion (eg, 30%) of the chroma reference samples used for CCLM prediction are not included in the adjacent above / left / right chroma ARAs, then CCLM mode is disabled.

[0280] exist Fig.21 The number of available reference samples is equal to 25% of the total number of reference samples. Therefore, CCLM will be disabled.

[0281] In a variant, CCLM mode is disabled as soon as at least one chroma reference sample used for CCLM prediction is not included in the adjacent above / left / right chroma ARA.

[0282] refer to Fig.21 , since at least one reference sample is not available in this illustration, CCLM will be disabled.

[0283] Similarly, for luma reference samples for CCLM, the following embodiment is proposed. Luma reference samples for CCLM mode are considered available if they belong to a luma block included in a luma ARA that is co-located with an adjacent chroma ARA above / left / top right of the chroma ARA that includes the chroma block under consideration ( Fig. 20 ). If the luma reference sample is not included in the adjacent above / left / right luma ARA co-located with the adjacent above / left / right adjacent chroma ARA, it is considered unavailable.

[0284] In a variation, if a given proportion (eg, 30%) of luma reference samples are not included in an adjacent above / left / right luma ARA co-located with an adjacent above / left / right chroma ARA, then CCLM mode is disabled.

[0285] In a variation, if at least one luma reference sample is not included in an adjacent above / left / right luma ARA co-located with an adjacent above / left / right chroma ARA, then the CCLM mode is disabled.

[0286] Example 9: Using CCLM to activate separate luma / chroma trees for CTU

[0287] In an embodiment, in case at least one chroma block within a CTU uses CCLM (or LDCRS), separate luma / chroma trees are disabled and the chroma partitioning of the CTU is inferred from the luma partitioning.

[0288] In a variation, a flag is signaled at the CTU level to indicate whether CCLM (or LDCRS) is used in a CTU.

[0289] The concept can be generalized for block types other than CTUs (eg, video decoding processing units, also referred to as VDPUs).

[0290] Embodiment 10: Chroma residual scaling based on neighboring samples of a luma block co-located with the upper left corner of a chroma block

[0291] In another embodiment, potential hardware latency issues are further reduced by determining a scaling factor to be used for chroma residual scaling of a chroma block from predicted or reconstructed luma samples that have been processed in a neighborhood of a luma block that is co-located with a given position in the chroma block.

[0292] These samples are referred to below as "neighboring brightness samples".

[0293] Fig. 22 A flow chart of a method for determining a scaling factor to be used in chroma residual scaling of a chroma block is depicted.

[0294] In step 800, a location in a picture of a given sample location in a chroma block is identified. In step 801, a luma block including a luma sample co-located with the location in the chroma block is identified. In step 802, processed luma samples adjacent to the luma block are identified. In step 803, a luma value is determined from those identified adjacent luma samples, such as an average of the identified adjacent luma samples. In step 804, a scaling factor for the chroma block is determined based on the luma value. In step 805, the chroma block residual is scaled using the scaling factor.

[0295] In an embodiment, a given sample position in a chroma block is the upper left corner of the chroma block. Fig.23A . The chroma block (rectangle) is indicated by a thick line. The co-located luma block (square) of the upper left sample of the chroma block is a thin line. Its neighboring samples are indicated in gray. In a variant, a given sample position in a chroma block is the center of the chroma block.

[0296] In an embodiment, only one neighboring luma sample is used, and the one neighboring luma sample corresponds to the sample above or to the left of the top left sample of the co-located luma block. Fig. 23B In a variation, both the upper sample and the left sample are used.

[0297] In another embodiment, the adjacent luma samples consist of adjacent upper rows of size WL and adjacent left columns of size HL, where WL and HL are the horizontal and vertical dimensions of the luma block. Fig.23C Shown in.

[0298] In another embodiment, the neighboring brightness samples are composed of the neighboring upper row of size minS and the neighboring left column of size minS, where minS is the minimum value between WL and HL.

[0299] In another embodiment, the adjacent luma samples consist of adjacent upper rows of size Wc*2 and adjacent left columns of size Hc*2, Wc and Hc are the horizontal and vertical dimensions of the chroma block and the chroma format is considered to be 4:2:0.

[0300] In another embodiment, the neighboring luma samples are composed of the neighboring upper row of size minSC*2 and the neighboring left column of size minSC*2, where minSC is the minimum value of Wc and Hc.

[0301] In a variation, the adjacent top row of size minSC*2 starts at the same relative horizontal position as the upper left corner of the chroma, and the adjacent left column row of size minSC*2 starts at the same relative vertical position as the upper left corner of the chroma, as Fig.23D For example, if the upper left corner of the chroma block is at position (xc, yc) in the chroma picture, and the chroma format is 4:2:0, then the first sample in the upper row of adjacent luma samples is at horizontal position 2*xc, and the first sample in the left column of adjacent luma samples is at vertical position 2*yc.

[0302] According to a further variant, the neighboring samples used to determine the scaling factor to be applied to the residual current chroma block consist of one or more reconstructed luminance samples, which belong to the lower and / or right columns of luminance samples of the upper and left neighboring ARAs respectively containing the current chroma block.

[0303] In another embodiment, if a given ratio of neighboring luma samples are not available, no chroma block residual scaling is applied.

[0304] In another embodiment, if the neighboring luma samples are not in the same CTU as the chroma block, then the neighboring luma samples are considered unavailable.

[0305] In another embodiment, if the neighboring luma samples are not in the same VDPU as the chroma block, then the neighboring luma samples are considered unavailable.

[0306] In another embodiment, neighboring luma samples are considered unavailable if they are not in the same luma ARA co-located with the first chroma block ARA.

[0307] In another embodiment, if a given proportion of chroma samples in the considered neighborhood is not available, then no chroma block residual scaling is applied. This may occur if a neighboring chroma block is not yet available in its reconstruction state when the current chroma block is being processed.

[0308] In an embodiment, the neighboring luma samples used to derive the chroma residual scaling factor are samples used to predict the co-located luma block (also commonly referred to as intra-prediction reference samples). In the dual-tree case, for each given region (e.g., VDPU), the luma blocks of the given region are usually processed first, and then the chroma blocks of the given region are processed. When the current embodiment is applied, this means that it will be necessary to store its neighboring luma samples for each luma block of the given region, which requires additional memory storage and complicates the process because the number of reference samples varies depending on the block size. In order to reduce these negative effects, in one embodiment, only the luma values ​​derived from the neighboring luma samples in step 803 are stored for each luma block. In another embodiment, only the scaling factors derived from the luma values ​​derived from the neighboring luma samples in step 803 are stored for each luma block in step 804. This limits the storage to a single value for each luma block. This principle can be extended to other modes other than LMCS, such as CCLM, where instead of storing the luma and chroma samples for each block, only the minimum and maximum values ​​of the luma and chroma samples used to derive the CCLM parameters of the block are stored.

[0309] The concept of embodiment 10 can be extended to CCLM mode. In this case, the current embodiment is to determine the CCLM linear parameters to be used for the prediction of the chroma block from the predicted or reconstructed luma samples (neighboring luma samples) and the predicted or reconstructed chroma samples (neighboring chroma samples) processed in the neighborhood of the luma block co-located with a given position in the chroma block. Figures 23A to 23D The concept is illustrated. The rectangular area filled in grey corresponds to the neighboring samples (luminance and chrominance) of the luma block co-located with the top left sample of the current chroma block, which are potentially used for the derivation of CCLM parameters.

[0310] According to a variant, the luminance and / or chrominance neighboring samples used to determine the linear model to be used to perform CCLM prediction of the current chrominance block are composed of at least one reconstructed or predicted luminance and / or chrominance sample, which belongs to the lower row and / or right column of the luminance and / or chrominance samples, and the luminance and / or chrominance samples belong to the upper and / or left adjacent luminance and / or chrominance ARA of the ARA containing the current chrominance block, respectively. The concept can be extended to the lower row of the upper right adjacent luminance and / or chrominance ARA of the ARA containing the current chrominance block, and can be extended to the right column of the lower left adjacent luminance and / or chrominance ARA of the ARA containing the current chrominance block. The concept can be extended to the lower row of the upper right adjacent luminance and / or chrominance ARA of the ARA containing the current chrominance block, and can be extended to the right column of the lower left adjacent luminance and / or chrominance ARA of the ARA containing the current chrominance block.

[0311] Example 11: Luma sample availability check based on its position relative to chroma blocks

[0312] In another embodiment, a neighboring luma sample at position (xL, yL) is considered unavailable if the distance between the neighboring luma sample at position (xC, yC) and the position of the top left sample of the considered chroma block is higher than a given value. In other words, a neighboring luma sample is considered unavailable if the following conditions are true:

[0313] ((xC*2)-xL)>TH or ((yC*2)-yL)>TV

[0314] or equivalently

[0315] (xc-(xL / 2))>TH / 2 or (yC-(yL / 2))>TV / 2

[0316] Where TH and TV are values ​​predefined or signaled in the bitstream. Typically, TH = TC = 16. In a variant, TH and TC depend on the picture resolution. For example, TH and TH are defined according to the following conditions:

[0317] - If the picture resolution is less than or equal to 832×480 luminance samples, then TH=TC=8,

[0318] - Otherwise, if the picture resolution is less than or equal to 1920×1080 luma samples, then TH=TC=16,

[0319] -Otherwise, TH=TC=32.

[0320] Fig.24A and 24B An example of the distance between the top left neighboring luma sample and the neighboring chroma sample (scaled by 2 in the case of 4:2:0 chroma format) is shown. Fig.24AThe distance between the top left chroma sample and the top left neighboring chroma sample of the co-located luma block is shown. Fig. 24B The distance between the upper left chroma sample and the upper row or left column is shown.

[0321] In a variation, instead of strictly disabling samples that are too far from the top-left chroma sample, a weighting that depends on the distance between the neighboring chroma samples and the top-left chroma sample is applied to the considered reference sample.

[0322] In a variation, instead of strictly disabling samples that are too far from the top-left chroma sample, a weighting that depends on the distance between the neighboring chroma samples and the top-left chroma sample is applied to the considered reference sample.

[0323] Embodiment 12: Luma samples may be determined based on the values ​​of their co-located chroma samples relative to the values ​​of the chroma samples of the current block. Usability check

[0324] In another embodiment, the availability of the neighboring luma sample neighborY is based on the values ​​of its co-located Cb and Cr chroma samples, neighborCb, neighborCr, and the values ​​of the predicted Cb and Cr chroma samples of the current chroma block. For example, a neighboring luma sample neighbor is considered unavailable if the following conditions are true:

[0325] -If Abs(topLeftCb-neighborCb)>Th_Ch or

[0326] Abs(topLeftCr-neighborCr)>Th_Ch

[0327] Where Th_Ch is a value predefined or signaled in the bitstream, and Abs is the absolute value function. Th_Ch may depend on the bit depth of the chroma samples. Typically, for 10-bit content, Th_Ch=64, and for 8-bit content, Th_Ch=32.

[0328] In a variant, chroma residual scaling is only applied if the average Cb and Cr values ​​avgNeighCb, avgNeighCr of chroma samples co-located with neighboring luma samples are not too far away from the average Cb and Cr values ​​avgCurrCb, avgCurrCr of chroma samples of the current chroma block.

[0329] For example, a neighboring luma sample is considered unavailable if the following conditions are true:

[0330] - If Abs(avgCurrCb–avgNeighCb)>Th_Ch or

[0331] Abs(avgCurrCr–avgNeighCr)>Th_Ch

[0332] In a variation, instead of strictly disabling samples that are too different from the top-left chroma sample, a weighting that depends on the difference between the neighboring chroma samples and the top-left chroma sample is applied to the considered reference sample.

[0333] In a variation, instead of strictly disabling samples that are too different from the top-left chroma sample, a weighting that depends on the difference between the neighboring chroma samples and the top-left chroma sample is applied to the considered reference sample.

[0334] Fig.25 A flow chart of a method for checking the availability of luma samples based on their co-located chroma samples and based on the chroma samples of the current block is depicted. Steps 800 to 802 are similar to Fig. 22 Step 900 is inserted after step 802 to identify neighboring chroma samples co-located with neighboring luma samples. At step 901, the similarity of the neighboring chroma samples and the chroma samples of the current block is checked. If the chroma samples are similar, chroma residual scaling is enabled for the current chroma block (903). If the samples are deemed not similar, chroma residual scaling is disabled for the current chroma block (902).

[0335] Example 12a: Availability of reference samples for MDLM

[0336] The MDLM mode is a variation of the CCLM mode that uses the above neighboring luma and chroma samples (MDLM Above) or the left neighboring luma and chroma samples (MDLM Left) as reference samples for deriving linear parameters for predicting chroma samples from luma samples.

[0337] In at least one embodiment, when the partitioning process results in a partition of a luma VDPU comprising two upper square blocks having half the width / height of the VDPU width / height, or a partition of a chroma VDPU comprising two upper square blocks having half the width / height of the VDPU width / height chroma VDPU, the reference samples of the MDLM to the left of the second square block (at Fig.25A The samples marked as "2" in the figure are only the samples adjacent to the left border of block 2. The samples below those reference samples are considered unavailable. This advantageously limits the delay in processing block 2, because the blocks below block 2 are not needed to derive the MDLM parameters.

[0338] for Fig.25A This embodiment can also be generalized to the case where the luminance or chrominance block 1 is further divided into smaller partitions.

[0339] Embodiment 13: Low-level flag for activating or deactivating chroma residual scaling

[0340] In another embodiment, a low-level flag is inserted in the bitstream syntax to enable or disable the chroma residual scaling tool at a lower level than slice or tile group. This embodiment may only apply to the case of separate luma / chroma partitioning trees. It can also be extended to the case where separate luma / chroma partitioning trees are not used.

[0341] The following table shows an example of syntax changes (highlighted in grey) compared to the VTM specification of document JVET-N0220. In this table, signaling is done at the CTU level and only in case of separate luma / chroma partition trees (identified by the syntax element qtbtt_dual_tree_intra_flag).

[0342]

[0343] The following table shows another example of syntax changes (highlighted in grey) compared to the VTM specification of document JVET-N0220. In this table, signaling is done at the CTU level and whether or not any separate luma / chroma partitioning trees are used.

[0344]

[0345] According to these variants, the activation in a CTU of chroma residual scaling is regulated by the value of the flag ctu_chroma_residual_scale_flag.

[0346] Example of specification syntax adaptation according to embodiment 2

[0347] An example of syntax changes in the current VVC draft specification (see Benjamin Bross et al., "Versatile Video Codec (Draft 4)", JVET 13th Meeting: Marrakech, Morocco, January 9-18, 2019, JVET-M1001-v7) according to Example 2 is provided below. Changes compared to JVET-M1001 are highlighted in grey.

[0348] 8.4.3 Derivation Process for Chroma Intra Prediction Modes

[0349] The inputs to this process are:

[0350] - luma position (xCb, yCb) which specifies the top left sample of the current chroma codec block relative to the top left luma sample of the current picture,

[0351] - the variable cbWidth, which specifies the width of the current codec block in luma samples,

[0352] - The variable cbHeight specifies the height of the current codec block in luma samples.

[0353] In this process, the chroma intra prediction mode IntraPredModeC[xCb][yCb] is derived.

[0354] -The variable lmEnabled is set equal to sps_cclm_enabled_flag.

[0355] -lmEnabled is exported by calling the process cross-component chroma intra prediction mode check process when the following condition is true.

[0356] -lmEnabled is equal to 1,

[0357] - tile_group_type equals 2 (I tile group),

[0358] -qtbtt_dual_tree_intra_flag is equal to 1.

[0359] The chroma intra prediction mode IntraPredModeC[xCb][yCb] is derived using intra_chroma_pred_mode[xCb][yCb] and IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2] as specified in Table 8-2 and Table 8-3.

[0360] Table 8-2 - When lmEnabled is equal to 0, depending on

[0361] intra_chroma_pred_mode[xCb][yCb] and

[0362] Specification of IntraPredModeC[xCb][yCb] for IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2]

[0363]

[0364]

[0365] Table 8-3 - When lmEnabled is equal to 1, depending on

[0366] intra_chroma_pred_mode[xCb][yCb] and

[0367] Specification of IntraPredModeC[xCb][yCb] for IntraPredModeY[xCb+cbWidth / 2][yCb+cbHeight / 2]

[0368]

[0369] Cross-component chroma intra prediction mode check process

[0370] The inputs to this process are:

[0371] - luma position (xCb, yCb) which specifies the top left sample of the current chroma codec relative to the top left luma sample of the current picture,

[0372] - the variable cbWidth, which specifies the width of the current codec in luma samples,

[0373] - The variable cbHeight specifies the current codec's height in luma samples.

[0374] The output of this process is:

[0375] - Flag lmEnabled which specifies whether cross-component chroma intra prediction mode is enabled for the current chroma codec.

[0376] In the process, lmEnabled is exported as follows.

[0377] - If ((16+xCb) / 16) is not equal to ((16+xCb+cbWidth-1) / 16) or ((16+yCb) / 16) is not equal to ((16+yCb+cbHeight-1) / 16), then cclmEnabled is set equal to 0

[0378] - Otherwise, the following applies.

[0379] - For i=0, (CbHeight-1) and j=0...(cbWidth-1), the following applies.

[0380] -(xTL,yTL) is set equal to the co-located luma codec block

[0381] The upper left sample position of the upper left luminance sample of the current picture of ColLumaBlock, the co-located luminance codec block ColLumaBlock is covered by

[0382] The position given by ((xCb+j)<<1,(yCb+i)<<1)).

[0383] -wColoc and hColoc are set equal to the width and height of ColLumaBlock.

[0384] -If one of the following conditions is false, cclmEnabled is set equal to 0 and the loop over i and j is stopped.

[0385] -((32+xTL) / 32) is equal to ((32+xTL+wCloc-1) / 32)

[0386] -((32+yTL) / 32) is equal to ((32+yTL+hColoc-1) / 32)

[0387] - When cclmEnabled is equal to 1, the following applies for i = 1...(cbHeight-2) and

[0388] j=0…(cbWidth-1).

[0389] -(xTL,yTL) is set equal to the co-located luma codec block

[0390] The upper left sample position of the upper left luminance sample of the current picture of ColLumaBlock, the co-located luminance codec block ColLumaBlock is covered by

[0391] The position given by ((xCb+j)<<1,(yCb+i)<<1)).

[0392] -wColoc and hColoc are set equal to the width and height of ColLumaBlock.

[0393] -If one of the following conditions is false, cclmEnabled is set equal to 0 and the loop over i and j is stopped.

[0394] -((32+xTL) / 32) is equal to ((32+xTL+wCloc-1) / 32)

[0395] -((32+yTL) / 32) is equal to ((32+yTL+hColoc-1) / 32)

[0396] Example of specification syntax adaptation according to embodiment 10

[0397] An example of syntax included in the current VVC draft specification (eg, document JVET-M1001) according to Embodiment 10 is provided below.

[0398] Image reconstruction with mapping process for chroma sample values

[0399] The inputs to this process are:

[0400] - (nCurrSwx2)x(nCurrShx2) array of mapped predMapSamples, which specifies the mapped luma prediction samples for the current block,

[0401] - when tile_group_type is equal to 2 (I tile group) and qtbtt_dual_tree_intra_flag is equal to 1, the array recSamples that specifies the reconstructed luma of the current picture,

[0402] - (nCurrSw)x(nCurrSh) array predSamples, which specifies the chroma prediction samples for the current block,

[0403] - (nCurrSw)x(nCurrSh) array resSamples that specifies the chroma residual samples for the current block.

[0404] - The arrays InputPivot[i] and ReshapePivot[i] derived in 7.4.4.1, where i is in the range 0 to MaxBinIdx+1 (inclusive).

[0405] - The arrays InvScaleCoeff[i] and ChromaScaleCoef[i] derived in 7.4.4.1, where i is in the range 0 to MaxBinIdx (inclusive).

[0406] The output of this process is the array of reconstructed chroma samples recSamples.

[0407] recSamples is exported as follows:

[0408] -if(!tile_group_reshaper_chroma_residual_scale_flag||

[0409] ((nCurrSw)x(nCurrSh)<=4))

[0410] recSamples[xCurr+i][yCurr+j]=Clip1 c (predSamples[i][j]+

[0411] resSamples[i][j])

[0412] Where i = 0...nCurrSw-1, j = 0...nCurrsh-1

[0413] -else(tile_group_reshaper_chroma_residual_scale_flag&&

[0414] ((nCurrSw)x(nCurrSh)>4)), the following applies:

[0415] The variable varScale is exported as follows:

[0416] -invAvgLuma is exported as follows:

[0417] - If tile_group_type is equal to 2 (I tile group) and qtbtt_dual_tree_intra_flag is equal to 1, the following applies.

[0418] - Identifies the chroma position (xCh, yCh) of the top left chroma sample of the chroma current block relative to the top left chroma sample of the current picture.

[0419] - Luma position (xTL, yTL) is set equal to the co-located luma codec block

[0420] The upper left sample position of ColLumaBlock, the co-located luma codec block

[0421] ColLumaBlock covers the top-left luminance sample relative to the current image by

[0422] (xCh<<1, yCh<<1) given position, and wColoc and hColoc are set equal to the width and height of ColLumaBlock.

[0423] - If ((32+yCh) / 32) equals ((64+yTL-1) / 64), then invAvgLuma is set equal to recSamples[yTL-1][xTL]

[0424] - Otherwise, if ((32+xCh) / 32) equals ((64+xTL-1) / 64), then invAvgLuma is set equal to recSamples[yTL][xTL-1]

[0425] - Otherwise invAvgLuma is set equal to -1.

[0426] - Otherwise, the following applies:

[0427] invAvgLuma=Clip1 Y ((Σ i ∑ j

[0428] predMapSamples[i][j]+nCurrSw*nCurrSh*2) / (nCurrSw*nCurrSh* 4))

[0430] - If invAvgLuma is not equal to -1, the following applies:

[0431] - The variable idxYInv is derived by involving the input of the sample value invAvgLuma to identify the piecewise function index as specified in clause 8.5.6.2.

[0432] -varScale is set equal to ChromaScaleCoef[idxYInv]

[0433] - Otherwise varScale is set equal to (1 < <shiftC)

[0434] recSamples is exported as follows:

[0435] - If tu_cbf_cIdx[xCurr][yCurr] is equal to 1, the following applies:

[0436] shiftC=11

[0437] recSamples[xCurr+i][yCurr+j]=ClipCidx1

[0438] (predSamples[i][j]+Sign(resSamples[i][j])

[0439] *((Abs(resSamples[i][j])*varScale+(1<<(ShiftC-1)))>>shiftC))

[0440] Where i = 0...nCurrSw-1, j = 0...nCurrSh-1

[0441] - Otherwise (tu_cbf_cIdx[xCurr][yCurr] is equal to 0)

[0442] recSamples[xCurr+i][yCurr+j]=ClipCidx1(predSamples[i][j])

[0443] Where i = 0...nCurrw-1, j = 0...nCurrSh-1

[0444] The present application describes various aspects, including tools, features, embodiments, models, methods, etc. Many of these aspects are specifically described, and at least in order to illustrate each characteristic, are usually described in a manner that may sound restrictive. However, this is for the purpose of describing clearly, and does not limit the application or scope of those aspects. In fact, all different aspects can be combined and interchanged to provide additional aspects. In addition, these aspects can also be combined and interchanged with the aspects described in the previous application.

[0445] The aspects described and contemplated in this application can be implemented in many different forms. Fig.26 , Fig. 27 and Fig.28 Some embodiments are provided, but other embodiments are contemplated, and Fig.26 , Fig. 27 and Fig.28 The discussion does not limit the breadth of implementations. At least one of the aspects generally relates to video encoding and decoding, and at least one other aspect generally relates to sending a generated or encoded bitstream. These and other aspects can be implemented as methods, apparatus, a computer-readable storage medium having stored thereon instructions for encoding or decoding video data according to any of the described methods, and / or a computer-readable storage medium having stored thereon a bitstream generated according to any of the described methods.

[0446] Various methods are described herein, and each method includes one or more steps or actions for implementing the described method. Unless a specific order of steps or actions is required for proper operation of the method, the order and / or use of specific steps and / or actions may be modified or combined.

[0447] Various methods and other aspects described in this application can be used to modify modules, such as Fig.26 and Fig. 27 The image segmentation and scaling modules (102, 151, 235 and 251) of the video encoder 100 and decoder 200 are shown. In addition, the present aspects are not limited to VVC or HEVC, and can be applied to (for example) other standards and recommendations (whether pre-existing or developed in the future), as well as extensions of any such standards and recommendations (including VVC and HEVC). Unless otherwise indicated or technically excluded, the aspects described in this application can be used alone or in combination.

[0448] Various numerical values ​​are used in this application, such as Wmax, Hmax, WmaxC, and HmaxC. The specific values ​​are for example purposes, and the described aspects are not limited to these specific values.

[0449] Fig.26An encoder 100 is shown. Variations of the encoder 100 are contemplated, but for clarity, the encoder 100 is described below without describing all contemplated variations.

[0450] Before being encoded, the video sequence may undergo a pre-encoding process (101), for example, applying a color transform to an input color picture (e.g., conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing a remapping of input picture components in order to obtain a signal distribution that is more resilient to compression (e.g., using histogram equalization of one of the color components). Metadata may be associated with the pre-processing and appended to the bitstream.

[0451] At encoder 100, as described below, a picture is encoded by encoder elements. The picture to be encoded is segmented (102) and processed in units of, for example, CUs. Each unit is encoded using, for example, intra or inter mode. When the unit is encoded in intra mode, it performs intra prediction (160). In inter mode, motion estimation (175) and compensation (170) are performed. The encoder decides (105) which of intra mode or inter mode to use to encode the unit, and indicates the intra / inter decision by, for example, a prediction mode flag. The encoder may perform forward mapping (191) applied to luma samples to obtain a predicted luma block. For chroma samples, forward mapping will not be applied. For example, a prediction residual is calculated by subtracting (110) the predicted block from the original image block. For chroma samples, chroma residual scaling may be applied to the chroma residual (111).

[0452] The prediction residual is then transformed (125) and quantized (130). The quantized transform coefficients, along with motion vectors and other syntax elements, are entropy encoded (145) to output a bitstream. The encoder may skip the transform and apply quantization directly to the untransformed residual signal. The encoder may bypass both the transform and quantization, i.e., encode and decode the residual directly without applying the transform or quantization process.

[0453] The encoder decodes the coded block to provide a reference for further prediction. The quantized transform coefficients are dequantized (140) and inverse transformed (150) to decode the prediction residual. The chrominance residual is then processed by inverse scaling (151) which is the inverse of the scaling process (111). The decoded prediction residual and the prediction block are combined (155) to reconstruct the image block. For luma samples, an inverse mapping (190) can be applied, which is the inverse of the forward mapping step (191). A loop filter (165) is applied to the reconstructed picture to perform, for example, deblocking / SAO (sample adaptive offset), adaptive loop filter (ALF) filtering to reduce encoding artifacts. The filtered image is stored in a reference picture buffer (180).

[0454] Fig. 27 2 shows a block diagram of a video decoder 200. In the decoder 200, the bitstream is decoded by the decoder elements as described below. The video decoder 200 generally performs the same operations as described above. Fig.26 The encoding pass is the inverse of the decoding pass. The encoder 100 also typically performs video decoding as part of encoding the video data.

[0455] Specifically, the input to the decoder includes a video bitstream that may be generated by the video encoder 100. The bitstream is first entropy decoded (230) to obtain transform coefficients, motion vectors, and other codec information. Picture segmentation information indicates how the picture is segmented. Therefore, the decoder can divide (235) the picture according to the decoded picture segmentation information. The transform coefficients are dequantized (240) and inverse transformed (250) to decode the prediction residual. For chroma samples, the chroma residual is processed by inverse scaling (251) similar to the inverse scaling (151) of the encoder. The decoded prediction residual and the prediction block are combined (255) to reconstruct the image block. The prediction block can be obtained (270) from intra-frame prediction (260) or motion compensated prediction (i.e., inter-frame prediction) (275). Forward mapping (295) can be applied to luma samples after prediction. Similar to the inverse mapping (190) of the encoder, inverse mapping (296) can be applied to reconstruct the luma samples. Then, a loop filter (265) is applied to the reconstructed image. The filtered image is stored at the reference picture buffer (280).

[0456] The decoded picture may further undergo post-decoding processing (285), such as an inverse color transform (e.g., conversion from YCbCr 4:2:0 to RGB 4:4:4) or inverse remapping that performs the inverse of the remapping process performed in the pre-encoding process (101). The post-decoding process may use metadata derived in the pre-encoding process and signaled in the bitstream.

[0457] Fig.28A block diagram of an example of a system in which various aspects and embodiments are implemented is shown. System 1000 may be embodied as a device including various components described below and configured to perform one or more aspects described in this document. Examples of such devices include, but are not limited to, various electronic devices, such as personal computers, laptop computers, smart phones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected home appliances and servers. The elements of system 1000 may be embodied in a single integrated circuit (IC), multiple ICs and / or discrete components individually or in combination. For example, in at least one embodiment, the processing and encoder / decoder elements of system 1000 are distributed over multiple ICs and / or discrete components. In various embodiments, system 1000 is coupled to one or more other systems or other electronic devices via, for example, a communication bus or by a dedicated input and / or output port communication. In various embodiments, system 1000 is configured to implement one or more aspects of the aspects described in this document.

[0458] The system 1000 includes at least one processor 1010 configured to execute instructions loaded therein for implementing, for example, various aspects described in this document. The processor 1010 may include embedded memory, input-output interfaces, and various other circuits known in the art. The system 1000 includes at least one memory 1020 (e.g., a volatile memory device and / or a non-volatile memory device). The system 1000 includes a storage device 1040, which may include a non-volatile memory and / or a volatile memory, including but not limited to an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a programmable read-only memory (PROM), a random access memory (RAM), a dynamic random access memory (DRAM), a static random access memory (SRAM), a flash memory, a magnetic disk drive, and / or an optical disk drive. As a non-limiting example, the storage device 1040 may include an internal storage device, an attached storage device (including a removable and non-removable storage device), and / or a network accessible storage device.

[0459] The system 1000 includes an encoder / decoder module 1030, which is configured to, for example, process data to provide encoded video or decoded video, and the encoder / decoder module 1030 may include its own processor and memory. The encoder / decoder module 1030 represents a module that may be included in a device to perform encoding and / or decoding functions. As is well known, a device may include one or both of the encoding and decoding modules. In addition, the encoder / decoder module 1030 may be implemented as a separate element of the system 1000, or may be incorporated into the processor 1010 as a combination of hardware and software known to those skilled in the art.

[0460] Program code to be loaded onto the processor 1010 or the encoder / decoder 1030 to perform various aspects described in this document may be stored in the storage device 1040 and subsequently loaded onto the memory 1020 for execution by the processor 1010. According to various embodiments, one or more of the processor 1010, the memory 1020, the storage device 1040, and the encoder / decoder module 1030 may store one or more of various items during the execution of the processes described in this document. Such stored items may include, but are not limited to, input video, decoded video or portions of decoded video, bitstreams, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.

[0461] In some embodiments, memory internal to the processor 1010 and / or encoder / decoder module 1030 is used to store instructions and provide working memory for processing required during encoding or decoding. However, in other embodiments, memory external to the processing device (e.g., the processing device may be the processor 1010 or the encoder / decoder module 1030) is used for one or more of these functions. The external memory may be memory 1020 and / or storage device 1040, such as dynamic volatile memory and / or non-volatile flash memory. In several embodiments, the external non-volatile flash memory is used to store, for example, an operating system for a television. In at least one embodiment, fast external dynamic volatile memory such as RAM is used as working memory for video encoding and decoding operations, such as for MPEG-2 (MPEG refers to Moving Picture Experts Group, MPEG-2 is also known as ISO / IEC 13818, and 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC (HEVC refers to High Efficiency Video Codec, also known as H.265 and MPEG-H Part 2), or VVC (Versatile Video Codec, a new standard developed by the Joint Video Experts Group JVET).

[0462] Input to the elements of system 1000 may be provided through various input devices, as shown at block 1130. Such input devices include, but are not limited to: (i) a radio frequency (RF) section that receives an RF signal transmitted, for example, over the air by a broadcaster, (ii) a component (COMP) input terminal (or a set of COMP input terminals), (iii) a universal serial bus (USB) input terminal, and / or (iv) a high-definition multimedia interface (HDMI) input terminal. Fig.28 Other examples not shown include composite video.

[0463] In various embodiments, the input device of block 1130 has associated corresponding input processing elements as known in the art. For example, the RF portion may be associated with elements suitable for: (i) selecting a desired frequency (also referred to as selecting a signal, or band limiting a signal to a frequency band), (ii) down-converting the selected signal, (iii) again band-limiting to a narrower frequency band to select a signal frequency band that may be referred to as a channel in some embodiments, (iv) demodulating the down-converted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired data packet stream. The RF portion of various embodiments includes one or more elements for performing these functions, such as a frequency selector, a signal selector, a frequency band limiter, a channel selector, a filter, a down-converter, a demodulator, an error corrector, and a demultiplexer. The RF portion may include a tuner that performs various of these functions, including, for example, down-converting a received signal to a lower frequency (e.g., an intermediate frequency or a near-baseband frequency) or baseband. In a set-top box embodiment, the RF part and its associated input processing element receive the RF signal transmitted on wired (for example, cable) medium, and filter to the desired frequency band to perform frequency selection by filtering, down-conversion and filtering again. Various embodiments rearrange the order of above-mentioned (and other) elements, remove some in these elements, and / or add other elements that perform similar or different functions. Adding element can include inserting element between existing element, such as, for example inserting amplifier and analog-to-digital converter. In various embodiments, the RF part comprises antenna.

[0464] In addition, the USB and / or HDMI terminals may include corresponding interface processors for connecting the system 1000 to other electronic devices via USB and / or HDMI connections. It should be understood that various aspects of input processing, such as Reed-Solomon error correction, can be implemented as needed, for example, in a separate input processing IC or in the processor 1010. Similarly, various aspects of USB or HDMI interface processing can be implemented as needed in a separate interface IC or in the processor 1010. The demodulated, error-corrected, and demultiplexed streams are provided to various processing elements, including, for example, the processor 1010 and the encoder / decoder 1030, which operate in combination with memory and storage elements to process the data streams as needed for presentation on an output device.

[0465] The various elements of system 1000 may be disposed within an integrated housing. Within the integrated housing, the various elements may be interconnected and data may be transmitted between them using a suitable connection arrangement 1140 (e.g., an internal bus known in the art, including an inter-IC (I2C) bus, wiring, and a printed circuit board).

[0466] The system 1000 includes a communication interface 1050 capable of communicating with other devices via a communication channel 1060. The communication interface 1050 may include, but is not limited to, a transceiver configured to send and receive data through the communication channel 1060. The communication interface 1050 may include, but is not limited to, a modem or a network card, and the communication channel 1060 may be implemented, for example, within a wired and / or wireless medium.

[0467] In various embodiments, data is streamed or otherwise provided to the system 1000 using a wireless network such as a Wi-Fi network (e.g., IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers)). The Wi-Fi signal of these embodiments is received through a communication channel 1060 and a communication interface 1050 suitable for Wi-Fi communication. The communication channel 1060 of these embodiments is typically connected to an access point or router that provides access to an external network including the Internet to allow streaming applications and other over-the-top communications. Other embodiments use a set-top box that delivers data through an HDMI connection of the input box 1130 to provide streaming data to the system 1000. Still other embodiments use an RF connection of the input box 1130 to provide streaming data to the system 1000. As shown above, various embodiments provide data in a non-streaming manner. In addition, various embodiments use a wireless network other than Wi-Fi, such as a cellular network or a Bluetooth network.

[0468] The system 1000 can provide output signals to various output devices, including a display 1100, a speaker 1110, and other peripherals 1120. The display 1100 of various embodiments includes, for example, one or more of a touch screen display, an organic light emitting diode (OLED) display, a curved display, and / or a foldable display. The display 1100 can be used for a television, a tablet computer, a laptop computer, a cellular phone (mobile phone), or other devices. The display 1100 can also be integrated with other components (e.g., as in a smart phone), or be separate (e.g., an external monitor for a laptop computer). In various examples of embodiments, other peripherals 1120 include one or more of a stand-alone digital video disk (or digital versatile disk) (DVR, for both terms), a disk player, a stereo system, and / or a lighting system. Various embodiments use one or more peripherals 1120 that provide functions based on the output of the system 1000. For example, a disk player performs the function of playing the output of the system 1000.

[0469] In various embodiments, control signals are communicated between the system 1000 and the display 1100, speaker 1110, or other peripheral device 1120 using signaling such as AV.Link, consumer electronics control (CEC), or other communication protocols that enable device-to-device control with or without user intervention. Output devices can be communicatively coupled to the system 1000 via dedicated connections through respective interfaces 1070, 1080, and 1090. Alternatively, the output devices can be connected to the system 1000 using a communication channel 1060 via a communication interface 1050. The display 1100 and speaker 1110 can be integrated into a single unit with other components of the system 1000 in an electronic device such as, for example, a television. In various embodiments, the display interface 1070 includes a display driver, such as, for example, a timing controller (T Con) chip.

[0470] For example, if the RF portion of input 1130 is part of a separate set-top box, the display 1100 and speaker 1110 may alternatively be separate from one or more of the other components. In various embodiments where the display 1100 and speaker 1110 are external components, the output signals may be provided via dedicated output connections including, for example, an HDMI port, a USB port, or a COMP output.

[0471] The embodiments may be performed by computer software implemented by the processor 1010 or by hardware or by a combination of hardware and software. As a non-limiting example, the embodiments may be implemented by one or more integrated circuits. As a non-limiting example, the memory 1020 may be of any type suitable for the technical environment and may be implemented using any appropriate data storage technology, such as optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory, and removable memory. As a non-limiting example, the processor 1010 may be of any type suitable for the technical environment and may include one or more of a microprocessor, a general-purpose computer, a special-purpose computer, and a processor based on a multi-core architecture.

[0472] Various implementations involve decoding. "Decoding" as used in this application may include, for example, all or part of a process performed on a received coded sequence to produce a final output suitable for display. In various embodiments, such a process includes one or more of the processes typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. In various embodiments, such a process also or alternatively includes a process performed by a decoder of the various implementations described in this application, for example, enabling cross-component correlation tools to be used for chroma blocks in response to the size of the chroma block and in response to the size of at least one luminance block co-located with at least one sample of the chroma block.

[0473] As a further example, in one embodiment, "decoding" refers only to entropy decoding, in another embodiment, "decoding" refers only to differential decoding, and in another embodiment, "decoding" refers to a combination of entropy decoding and differential decoding. Whether the phrase "decoding process" is intended to refer specifically to a subset of operations or generally to a broader decoding process will be clear based on the context of the particular description and is considered to be well understood by those skilled in the art.

[0474] Various implementations involve encoding. In a manner similar to the discussion above regarding "decoding", "encoding" as used in this application may include, for example, all or part of a process performed on an input video sequence to produce an encoded bitstream. In various embodiments, such a process includes one or more of the processes typically performed by an encoder, such as segmentation, differential encoding, transforms, quantization, and entropy encoding. In various embodiments, such a process also or alternatively includes a process performed by an encoder of the various implementations described in this application, for example, enabling cross-component correlation tools to be used for chroma blocks in response to the size of the chroma block and in response to the size of at least one luminance block co-located with at least one sample of the chroma block.

[0475] As a further example, in one embodiment, "encoding" refers only to entropy encoding, in another embodiment, "encoding" refers only to differential encoding, and in another embodiment, "encoding" refers to a combination of differential encoding and entropy encoding. Whether the phrase "encoding process" is intended to refer specifically to a subset of operations or generally to a broader encoding process will be clear based on the context of the particular description and is considered to be well understood by those skilled in the art.

[0476] Note that the syntax elements (e.g., index of a chroma scaling factor) as used herein are descriptive terms. Therefore, they do not exclude the use of other syntax element names.

[0477] When the figure is presented as a flow chart, it should be understood that it also provides a block diagram of the corresponding apparatus. Similarly, when the figure is presented as a block diagram, it should be understood that it also provides a flow chart of the corresponding method / process.

[0478] Various embodiments refer to rate-distortion optimization. Specifically, during the encoding process, the balance or trade-off between rate and distortion is usually considered, taking into account the constraints of computational complexity. Rate-distortion optimization is usually formulated as minimizing a rate-distortion function, which is a weighted sum of rate and distortion. There are different methods to solve the rate-distortion optimization problem. For example, these methods can be based on extensive testing of all coding options, including all considered modes or codec parameter values, and a complete evaluation of the coding and decoding costs and the associated distortion of the reconstructed signal after encoding and decoding. Faster methods can also be used to save coding complexity, especially to calculate approximate distortion based on prediction or prediction residual signals rather than reconstructed prediction or prediction residual signals. A mixture of these two methods can also be used, such as by using approximate distortion only for some possible coding options and using full distortion for other coding options. Other methods only evaluate a subset of possible coding options. More generally, many methods use any of a variety of techniques to perform optimization, but optimization is not necessarily a complete evaluation of both coding costs and associated distortions.

[0479] The implementations and aspects described herein can be implemented in, for example, methods or processes, devices, software programs, data streams, or signals. Even if only discussed in the context of a single implementation (e.g., discussed only as a method), the implementations of the features discussed can also be implemented in other forms (e.g., devices or programs). The device can be implemented in, for example, appropriate hardware, software, and firmware. The method can be implemented in, for example, a processor, which generally refers to a processing device, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. The processor also includes communication devices, such as, for example, computers, cellular phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate information communication between end users.

[0480] References to "one embodiment" or "an embodiment" or "an implementation" or "an implementation" and other variations thereof indicate that a particular feature, structure, characteristic, etc. described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" or "in one implementation" or "in an implementation" and any other variations appearing in various places throughout this application are not necessarily all referring to the same embodiment.

[0481] Additionally, this application may refer to "determining" various information. Determining information may include, for example, one or more of estimating information, calculating information, predicting information, or retrieving information from a memory.

[0482] Additionally, the present application may refer to "accessing" various information. Accessing information may include, for example, one or more of receiving information, retrieving information (e.g., from a memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information.

[0483] Additionally, the present application may refer to "receiving" various information. Like "accessing," receiving is intended to be a broad term. Receiving information may include, for example, one or more of accessing information or retrieving information (e.g., from a memory). Furthermore, during operations such as, for example, storing information, processing information, sending information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information, "receiving" is generally involved in one way or another.

[0484] It should be understood that, for example, in the case of "A / B," "A and / or B," and "at least one of A and B," use of any of the following " / ," "and / or," and "at least one of" is intended to include selecting only the first listed option (A), or only the second listed option (B), or both options (A and B). As a further example, in the case of "A, B, and / or C" and "at least one of A, B, and C," such phrases are intended to include selecting only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or all three options (A and B and C). As will be apparent to one of ordinary skill in this and related arts, this can be extended to as many items as listed.

[0485] In addition, as used herein, the word "signal" refers in particular to a corresponding decoder indicating something. For example, in some embodiments, the encoder signals a specific one of the chroma scaling factor indices. In this way, in an embodiment, the same parameters are used on both the encoder side and the decoder side. Thus, for example, the encoder can send (explicitly signal) specific parameters to the decoder so that the decoder can use the same specific parameters. On the contrary, if the decoder already has specific parameters as well as other parameters, signaling can be used without sending (implicitly signaling) to simply allow the decoder to know and select specific parameters. By avoiding the transmission of any actual function, bit savings are achieved in various embodiments. It should be understood that signaling can be implemented in various ways. For example, in various embodiments, one or more syntax elements, flags, etc. are used to signal information to the corresponding decoder. Although the verb form of the word "signal" is mentioned above, the word "signal" can also be used as a noun in this article.

[0486] It will be apparent to one of ordinary skill in the art that implementations may generate various signals formatted to carry information that may, for example, be stored or transmitted. The information may include, for example, instructions for executing the method or data generated by one of the described implementations. For example, a signal may be formatted to carry a bitstream of the described embodiments. Such a signal may be formatted as, for example, an electromagnetic wave (e.g., using a radio frequency portion of a spectrum) or a baseband signal. Formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream. The information carried by the signal may be, for example, analog or digital information. As is known, the signal may be sent via a variety of different wired or wireless links. The signal may be stored on a processor readable medium.

[0487] We have described a number of embodiments. Features of these embodiments may be provided individually or in any combination across various claim categories and types. In addition, embodiments may include one or more of the following features, devices, or aspects, individually or in any combination across various claim categories and types:

[0488] • Enabling cross-component correlation tools in response to the size of the chroma block and possibly in response to the size of at least one luma block co-located with the chroma block.

[0489] Enable cross-component correlation tools in the case where the chroma block is within a single chroma rectangular region defined by partitioning the chroma components of the picture into non-overlapping rectangular regions;

[0490] enabling a cross-component correlation tool if at least one co-located luma block is within a luma rectangular region co-located with a first chroma rectangular region, the luma rectangular region being defined by partitioning the luma of the picture into non-overlapping rectangular regions;

[0491] • A bitstream or signal comprising one or more of the described syntax elements, or variations thereof.

[0492] • A bitstream or signal including syntax conveying information generated according to any of the described embodiments.

[0493] • Inserting syntax elements in the signaling that enable the decoder to enable / disable cross-component correlation tools in a manner corresponding to that used by the encoder.

[0494] • Creating and / or sending and / or receiving and / or decoding a bitstream or signal comprising one or more of the described syntax elements or variations thereof.

[0495] • Creating and / or sending and / or receiving and / or decoding according to any of the described embodiments.

[0496] • A method, process, apparatus, medium storing instructions, medium storing data, or signal according to any of the described embodiments.

[0497] • A TV, set-top box, cell phone, tablet or other electronic device that performs enabling / disabling of cross-component correlation tools according to any of the described embodiments.

[0498] A TV, set-top box, cell phone, tablet or other electronic device that executes the enable / disable cross-component correlation tool according to any of the described embodiments and displays (e.g.,

[0499] An image obtained using a monitor, screen, or other type of display.

[0500] • A TV, set-top box, cell phone, tablet or other electronic device that selects (eg, using a tuner) a channel to receive a signal including an encoded image and performs enabling / disabling cross-component correlation tools according to any of the described embodiments.

[0501] • A TV, set-top box, cell phone, tablet or other electronic device that receives over the air (eg, using an antenna) a signal including an encoded image and executes the enable / disable cross-component correlation tool according to any of the described embodiments.

[0502] Furthermore, embodiments may include one or more of the following features, devices, or aspects, alone or in any combination across various claim categories and types.

[0503] According to a general aspect of at least one embodiment, a decoding method is proposed, comprising:

[0504] - enabling cross-component correlation tools to be used for chroma blocks of the picture in response to the size of the chroma blocks and the size of at least one luminance block co-located with the chroma blocks;

[0505] - In response to said enabling of said cross-component correlation tool, decoding said chroma block.

[0506] According to a general aspect of at least one embodiment, a decoding device is provided, comprising one or more processors configured to execute:

[0507] - enabling cross-component correlation tools to be used for chroma blocks of the picture in response to the size of the chroma block and the size of at least one luminance block co-located with the chroma block; and

[0508] - In response to said enabling of said cross-component correlation tool, decoding said chroma block.

[0509] According to a general aspect of at least one embodiment, a coding method is proposed, comprising:

[0510] - enabling cross-component correlation tools to be used for chroma blocks of the picture in response to the size of the chroma blocks and the size of at least one luminance block co-located with the chroma blocks;

[0511] - In response to said enabling of said cross-component correlation tool, encoding said chroma block.

[0512] According to a general aspect of at least one embodiment, a coding apparatus is provided, the coding apparatus comprising one or more processors configured to execute:

[0513] - enabling cross-component correlation tools for chroma blocks of a picture in response to the size of the chroma block and the size of at least one luminance block co-located with the chroma block; and

[0514] - In response to said enabling of said cross-component correlation tool, encoding said chroma block.

[0515] One or more of the embodiments also provide a computer-readable storage medium on which instructions for encoding or decoding video data according to at least a portion of any of the above methods are stored. One or more embodiments also provide a computer-readable storage medium on which a bit stream generated according to the above encoding method is stored. One or more embodiments also provide a method and apparatus for sending or receiving a bit stream generated according to the above encoding method. One or more embodiments also provide a computer program product including instructions for executing at least a portion of any of the above methods.

[0516] In one embodiment, the cross-component correlation tool is luma-dependent chroma residual scaling.

[0517] In one embodiment, enabling the luma-related chroma residual scaling to be used for a chroma block of a picture in response to a size of the chroma block and a size of at least one luma block co-located with the chroma block comprises:

[0518] - Enable the luma-dependent chroma residual scaling described below:

[0519] The chrominance block is within a single chrominance rectangular region, the chrominance rectangular region being defined by partitioning the chrominance components of the picture into non-overlapping rectangular regions; and

[0520] at least one luma block co-located with a chroma block is within a single luma rectangular region co-located with the chroma rectangular region, the luma rectangular region being defined by partitioning the luma of the picture into non-overlapping rectangular regions; and

[0521] - Otherwise disable the luma-dependent chroma residual scaling.

[0522] In one embodiment, enabling the luma-related chroma residual scaling to be used for a chroma block of a picture in response to a size of the chroma block and a size of at least one luma block co-located with the chroma block comprises:

[0523] - Enable the luma-dependent chroma residual scaling described below:

[0524] The chrominance block is within a single chrominance rectangular region, the chrominance rectangular region being defined by partitioning the chrominance components of the picture into non-overlapping rectangular regions; and

[0525] All luma blocks co-located with chroma blocks are within a single luma rectangular region co-located with the chroma rectangular region, the luma rectangular region being defined by partitioning the luma of the picture into non-overlapping rectangular regions; and

[0526] - Otherwise disable the luma-dependent chroma residual scaling.

[0527] In one embodiment, enabling the luma-related chroma residual scaling to be used for a chroma block of a picture in response to a size of the chroma block and a size of at least one luma block co-located with the chroma block comprises:

[0528] - enabling luma-dependent chroma residual scaling in case at least one luma block co-located with a chroma block is within a single luma rectangular area co-located with a first chroma rectangular area, the chroma rectangular area being defined by partitioning the chroma components of the picture into non-overlapping rectangular areas, and the luma rectangular area being defined by partitioning the luma components of the picture into non-overlapping rectangular areas; and

[0529] - Otherwise disable the luma-dependent chroma residual scaling.

[0530] In one embodiment, in case said luma-dependent chroma residual scaling is disabled, a scaling factor is determined for said chroma block by prediction from the chroma scaling factor or from an index identifying a chroma scaling factor associated with at least one decoded (respectively encoded) chroma block adjacent to said chroma block.

[0531] In one embodiment, difference quantization parameters are decoded from the bitstream (respectively encoded in the bitstream) for said chroma blocks in case said luma-dependent chroma residual scaling is disabled.

[0532] In another embodiment, the cross-component correlation tool is a cross-component linear model prediction.

Claims

1. A decoding method, for a chrominance block of a picture within a single non-overlapping rectangular area, comprising: determining a luminance non-overlapping rectangular region including a luminance block co-located with the position of the chrominance block, determining the scaling factor based on an average value of reconstructed luma samples belonging to a lower and / or right column of luma samples belonging to upper and / or left adjacent luma non-overlapping rectangular regions, respectively, of the luma non-overlapping rectangular region containing the current chroma block, and The chroma block residual is scaled according to the scaling factor.

2. The method according to claim 1, wherein: A chroma residual scaling tool is enabled in response to size and position constraints of co-located chroma and luma blocks.

3. The method according to claim 2, wherein: A size constraint of the chroma block is 32×32 pixels, and a size constraint of at least one luma block co-located with the chroma block is 64×64 pixels.

4. A method for encoding a chrominance block of a picture within a single non-overlapping rectangular area, comprising: determining a luminance non-overlapping rectangular region including a luminance block co-located with the position of the chrominance block, determining the scaling factor based on an average value of reconstructed luma samples belonging to a lower and / or right column of luma samples belonging to upper and / or left adjacent luma non-overlapping rectangular regions, respectively, of the luma non-overlapping rectangular region containing the current chroma block, and The chroma block residual is scaled according to the scaling factor.

5. The method according to claim 4, wherein: A chroma residual scaling tool is enabled in response to size and position constraints of co-located chroma and luma blocks.

6. The method according to claim 5, wherein: A size constraint of the chroma block is 32×32 pixels, and a size constraint of at least one luma block co-located with the chroma block is 64×64 pixels.

7. A decoding apparatus, comprising one or more processors, wherein the one or more processors are configured to, for a chrominance block of a picture within a single non-overlapping rectangular area: determining a luminance non-overlapping rectangular region including a luminance block co-located with the position of the chrominance block, determining the scaling factor based on an average value of reconstructed luma samples belonging to a lower and / or right column of luma samples belonging to upper and / or left adjacent luma non-overlapping rectangular regions, respectively, of the luma non-overlapping rectangular region containing the current chroma block, and The chroma block residual is scaled according to the scaling factor.

8. The device according to claim 7, wherein: A chroma residual scaling tool is enabled in response to size and position constraints of co-located chroma and luma blocks.

9. The device according to claim 8, wherein: A size constraint of the chroma block is 32×32 pixels, and a size constraint of at least one luma block co-located with the chroma block is 64×64 pixels.

10. An encoding apparatus, comprising one or more processors, wherein the one or more processors are configured to, for a chroma block of a picture within a single non-overlapping rectangular area: determining a luminance non-overlapping rectangular region including a luminance block co-located with the position of the chrominance block, determining the scaling factor based on an average value of reconstructed luma samples belonging to a lower and / or right column of luma samples belonging to upper and / or left adjacent luma non-overlapping rectangular regions, respectively, of the luma non-overlapping rectangular region containing the current chroma block, and The chroma block residual is scaled according to the scaling factor.

11. The device according to claim 10, wherein: A chroma residual scaling tool is enabled in response to size and position constraints of co-located chroma and luma blocks.

12. The device according to claim 11, wherein A size constraint of the chroma block is 32×32 pixels, and a size constraint of at least one luma block co-located with the chroma block is 64×64 pixels.

Images