Syntax interleaving method and apparatus for independent coding trees in video coding and decoding

Abstract

In one aspect, the present invention provides a method and apparatus for block segmentation in video encoding and decoding. According to one method, a current data unit is segmented into initial blocks using inferred segmentation without signaling a segmentation syntax. The initial blocks include a plurality of initial luminance blocks and a plurality of initial chrominance blocks, and the size of the initial luminance blocks is MxN, where M and N are positive integers, and the current data unit is larger than MxN for the luminance component. A segmentation structure is determined for dividing each initial luminance block and each initial chrominance block into one or more luminance coding units and one or more chrominance coding units, respectively. The luminance syntax and chrominance syntax associated with an initial block in the current data unit are sent or parsed, and then the luminance syntax and chrominance syntax associated with a next initial block in the current data unit are sent or parsed.

Description

[0001] Cross-application

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 664,387, filed April 30, 2018; U.S. Provisional Patent Application No. 62 / 666,177, filed May 3, 2018; U.S. Provisional Patent Application No. 62 / 676,330, filed May 25, 2018; U.S. Provisional Patent Application No. 62 / 692,855, filed July 1, 2018; U.S. Provisional Patent Application No. 62 / 700,265, filed July 18, 2018; and U.S. Provisional Patent Application No. 62 / 714,153, filed August 3, 2018. The aforementioned U.S. Provisional Patent Applications are incorporated herein by reference in their entirety. Technical Field

[0003] The present invention relates to block segmentation and syntax signaling in video coding. In particular, the present invention relates to interleaved luminance and chrominance syntax signaling and various derivations for deciding whether to use a shared coding tree or independent coding trees for luminance and chrominance blocks. Background Art

[0004] The High Efficiency Video Coding (HEVC) standard was developed under the Joint Video Project of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) standardization organizations, in particular in collaboration with the Joint Collaborative Team on Video Coding (JCT-VC). In HEVC, a slice is divided into multiple coding tree units (CTUs). In the main profile, the minimum and maximum sizes of a CTU are specified by syntax elements in the sequence parameter set (SPS). The allowed CTU sizes can be 8x8, 16x16, 32x32, or 64x64. For each slice, the CTUs within the slice are processed in raster scan order.

[0005] The CTU is further split into multiple coding units (CUs) to accommodate various local characteristics. A quadtree, represented as a coding tree, is used to split the CTU into multiple CUs. Let the CTU size be MxM, where M is one of the values ​​64, 32, or 16. The CTU can be a single CU (i.e., no splitting) or can be divided into four smaller units of equal size (i.e., each is M / 2xM / 2), which correspond to the nodes of the coding tree. If the unit is a leaf node of the coding tree, the unit becomes a CU. Otherwise, the quadtree splitting process can be iterated until the size of the node reaches the minimum allowed CU size specified in the Sequence Parameter Set (SPS). This representation produces Figure 1 The coding tree (also called partition tree structure) 120 in specifies the recursive structure. Figure 1 The CTU partition 110 is shown in FIG, where solid lines indicate CU boundaries. The decision to encode an image region using inter-picture (temporal) or intra-picture (spatial) prediction is made at the CU level. Since the smallest CU size can be 8x8, the minimum granularity for switching between different basic prediction types is 8x8.

[0006] In addition, according to HEVC, each CU can be divided into one or more prediction units (PUs). Coupled with the CU, the PU serves as a basic representative block for sharing prediction information. Within each PU, the same prediction process is applied, and relevant information is sent to the decoder based on the PU. Depending on the PU partition type, the CU can be divided into one, two, or four PUs. Figure 2 As shown in the figure, HEVC defines eight shapes for splitting a CU into PUs, including 2Nx2N, 2NxN, Nx2N, NxN, 2NxnU, 2NxnD, nLx2N, and nRx2N partition types. Unlike a CU, a PU can be partitioned only once according to HEVC. The partition shown in the second row corresponds to an asymmetric partition, in which the two partitions have different sizes.

[0007] After obtaining the residual block through the prediction process based on the PU partition type, the prediction residual of the CU can be divided into transform units (TUs) according to another quadtree structure. Figure 1 As shown, this quadtree structure is similar to the coding tree for a CU. Solid lines represent CU boundaries, and dashed lines represent TU boundaries. A TU is a basic representative block with residuals or transform coefficients for applying integer transforms and quantization. For each TU, an integer transform of the same size as the TU is applied to obtain residual coefficients. After quantization on a TU basis, these coefficients are sent to the decoder.

[0008] The terms coding tree block (CTB), coding block (CB), prediction block (PB), and transform block (TB) are defined to specify a 2-D sample array of one color component associated with a CTU, CU, PU, ​​and TU, respectively. Thus, a CTU consists of one luma CTB, two chroma CTBs, and associated syntax elements. Similar relationships are valid for CUs, PUs, and TUs. Tree partitioning generally applies to both luma and chroma, but there are exceptions when certain minimum sizes for chroma are reached.

[0009] Alternatively, a binary tree block partitioning structure is proposed in JCTVC-P1005 (D. Flynn, et al, “HEVC Range Extensions Draft 6”, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16WP 3 and ISO / IEC JTC1 / SC 29 / WG 11, 16th Meeting: San Jose, US, 9–17 January 2014, Document: JCTVC-P1005). In the proposed binary tree partitioning structure, the following can be used: Figure 3 The various types of binary splitting shown in , recursively split the block into two smaller blocks. The most efficient and simple is Figure 3 Symmetrical horizontal and vertical partitioning as shown in the first two partitions in . For a given block of size M×N, a flag is sent to indicate whether the given block is divided into two smaller blocks. If so, another syntax element is sent to indicate which partitioning type is used. If horizontal partitioning is used, the given block is divided into two blocks of size M×N / 2. If vertical partitioning is used, the given block is divided into two blocks of size M / 2×N. The binary tree partitioning process can be iterated until the size (width or height) of the partitioned blocks reaches the minimum allowed block size (width or height). The minimum allowed block size can be defined in a high-level syntax such as SPS. Since the binary tree has two partitioning types (i.e. horizontal and vertical), the minimum allowed block width and block height should be indicated. When the partitioning would result in a block height less than the indicated minimum value, a non-horizontal partitioning is implicitly implied. When the partitioning would result in a block width less than the indicated minimum value, a non-vertical partitioning is implicitly implied. Figure 4 An example of a block partition 410 and its corresponding binary tree 420 is shown. In each partition node (ie, non-leaf node) of the binary tree, a flag is used to indicate which partition type (horizontal or vertical) is used, where 0 indicates horizontal partitioning and 1 indicates vertical partitioning.

[0010] A binary tree structure can be used to partition an image region into multiple smaller blocks, such as partitioning a slice into CTUs, CTUs into CUs, CUs into PUs, or CUs into TUs, and so on. A binary tree can be used to partition a CTU into CUs, where the root node of the binary tree is the CTU and the leaf nodes of the binary tree are the CUs. The leaf nodes can be further processed through prediction and transform coding. For simplicity, there is no further partitioning from CU to PU or from CU to TU, meaning that CU equals PU and PU equals TU. So, in other words, the leaf nodes of the binary tree are the basic units used for prediction and transform coding.

[0011] QTBT structure

[0012] A binary tree structure is more flexible than a quadtree structure because it can support more partitioning shapes, which also improves coding efficiency. However, coding complexity also increases in order to select the optimal partitioning shape. To balance complexity and coding efficiency, a method combining quadtree and binary tree structures has been disclosed, also known as a quadtree plus binary tree (QTBT) structure. In the QTBT structure, the CTU (or CTB of an I slice) is the root node of the quadtree. The CTU is first partitioned using the quadtree. The quadtree partitioning of a node is iterated until the node reaches the minimum allowed quadtree leaf node size (i.e., MinQTSize). If the quadtree leaf node size is not greater than the maximum allowed binary tree root node size (i.e., MaxBTSize), it can be further partitioned using the binary tree. The binary tree partitioning of a node is iterated until the node reaches the minimum allowed binary tree leaf node size (i.e., MinBTSize) or the maximum allowed binary tree depth (i.e., MaxBTDepth). A binary tree leaf node, i.e., a CU (or CB for an I slice), will be used for prediction (e.g., intra-image or inter-image prediction) and transformed without any further partitioning. There are two types of partitioning in the binary tree partitioning: symmetric horizontal partitioning and symmetric vertical partitioning. In the QTBT structure, the minimum allowed quadtree leaf node size, the maximum allowed binary tree root node size, the minimum allowed binary tree leaf node width and height, and the maximum allowed binary tree depth can be indicated in a high-level syntax, such as in an SPS. Figure 5 An example of a block partition 510 and its corresponding QTBT 520 is shown. Solid lines represent quadtree partitions, and dashed lines represent binary tree partitions. In each partition node (i.e., non-leaf node) of the binary tree, a flag indicates which partition type (horizontal or vertical) is used, where 0 indicates horizontal partitioning and 1 indicates vertical partitioning.

[0013] The above-mentioned QTBT structure can be used to partition an image region (e.g., a slice, CTU, or CU) into multiple smaller blocks, such as partitioning a slice into CTUs, partitioning a CTU into CUs, partitioning a CU into PUs, or partitioning a CU into TUs. For example, QTBT can be used to partition a CTU into CUs, where the root node of the QTBT is the CTU, which is partitioned into multiple CUs through the QTBT structure, and the CU is further processed through prediction and transform codecs. For simplicity, there is no further partitioning from CU to PU or from CU to TU. This means that CU is equal to PU and PU is equal to TU. So, in other words, the leaf nodes of the QTBT structure are the basic units for prediction and transform.

[0014] An example of a QTBT structure is shown below. For a CTU of size 128x128, the minimum allowed quadtree leaf node size is set to 16x16, the maximum allowed binary tree root node size is set to 64x64, the minimum allowed binary tree leaf node width and height are both set to 4, and the maximum allowed binary tree depth is set to 4. First, the CTU is partitioned using a quadtree structure, with leaf quadtree units having sizes ranging from 16x16 (i.e., the minimum allowed quadtree leaf node size) to 128x128 (equal to the CTU size, i.e., no partitioning). If a leaf quadtree unit is 128x128, it cannot be further split through the binary tree because the size exceeds the maximum allowed binary tree root node size of 64x64. Otherwise, the leaf quadtree unit can be further partitioned through the binary tree. A leaf quadtree unit is also a root binary tree unit, and its binary tree depth is 0. When the binary tree depth reaches 4 (i.e., the maximum allowed binary tree depth as indicated), no partitioning is implicitly implied. When the width of the block of the corresponding binary tree node is equal to 4, non-horizontal partitioning is implicitly implied. When the height of the block of the corresponding binary tree node is equal to 4, non-vertical partitioning is implicitly implied. The leaf nodes of the QTBT are further processed through prediction (intra-picture or inter-picture) and transform coding.

[0015] For I slices, the QTBT tree structure typically applies luma / chroma independent coding. For example, the QTBT tree structure is applied to the luma and chroma components of the I slice separately, and is applied to both luma and chroma for P and B slices (unless certain minimum sizes of chroma are reached). In other words, in an I slice, the luma CTB has a block partitioning of the QTBT structure, and the two chroma CTBs have another block partitioning of the QTBT structure. In another example, the two chroma CTBs can also have their own QTBT structure block partitioning.

[0016] Bilateral Template MV Refinement (also known as DMVR)

[0017] In some literature, bilateral template MV refinement (BTMVR) is also called decoder-side MV refinement (Xu Chen, et al., “Decoder-Side Motion Vector Refinement Based on Bilateral Template Matching”, Joint Video Exploration Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 4th Meeting: Chengdu, CN, 15–21 October 2016, Document: JVET-D0029), which discloses decoder-side motion vector refinement (DMVR) based on bilateral template matching. The process of BTMVR is as follows: Figure 6 As shown, where block 610 is the current block. Initial motion vectors MV0 620a and MV1 620b of the current block are determined. For example, the initial motion vectors can be derived from the merge candidates. The BTMVR process is applied to the dual-prediction block. In other words, MV0 points to the L0 reference image 670a and MV1 points to the L1 reference image 670b. The L0 reference block 630a in the L0 reference image 670a can be located at a corresponding position 610a of the current block in the L0 reference image 670a and MV0 620a. Similarly, the L1 reference block 630b in the L1 reference image 670b can be located at a corresponding position 610b of the current block in the L1 reference image 670b and MV1620b. The template 640 is generated by using dual prediction of the two reference blocks (630a and 630b) pointed to by MV0 620a and MV1620b, respectively, as shown in FIG. Figure 6 As shown. In one embodiment, the bilateral template 640 is calculated as the average of the L0 block 630a and the L1 block 630b, but not limited to this embodiment. In the next step, it uses the bilateral template to perform integer motion estimation (ME) and fractional ME search around the L0 reference block in the L0 reference image, with a search range of P pixels × Q pixels, and finds the position of minimum ME cost. The ME cost has many embodiments, one embodiment is the sum of absolute differences (SAD), but not limited to this embodiment. The final position of the minimum ME cost is assigned to the refined MV of L0. Similar steps are applied to locate the refined MV of L1. For example, as Figure 6As shown, the template is used as the new current block and motion estimation is performed to find better matching blocks (i.e., refined reference block 650a and refined reference block 650b) in L0 reference image 660a and L1 reference image 660b. The refined MVs are referred to as MV0'660a and MV1'660b, as shown in FIG. Figure 6 The refined MVs (MV0' and MV1') are then used to generate the final bidirectionally predicted prediction block of the current block.

[0018] Neighbouring-derived Prediction Offset (NPO)

[0019] Neighboring-derived prediction offsets (NPO) are a recently developed coding tool for improving motion-compensated predictors by adding prediction offsets. These offsets can account for varying lighting conditions between frames. These offsets are derived using neighboring reconstructed pixels (NRPs) and extended motion-compensated predictors (EMCPs).

[0020] Figure 7 An exemplary implementation of derived offsets is shown. The pattern selected for the NRP and EMCP is N columns (712 and 722) on the left and M columns (714 and 724) on the top of the current PU 710 and the reference block 720, respectively, where N and M are predetermined values. Although rectangular NRPs and EMCPs are shown in the example, the pattern can have any size and shape and can be determined based on any coding parameters, such as PU or CU size, as long as the same size and shape are used for both the NRP and EMCP. The offset is calculated as the average pixel value of the NRP minus the average pixel value of the EMCP. This derived offset will be applied to the entire PU as well as the motion compensated predictor.

[0021] Figure 8 Another exemplary implementation of deriving offsets is shown. First, for each neighboring position (i.e., the left edge of the current block 830 and the left pixel 810 and the top pixel 820 of the top edge), the individual offsets are calculated by subtracting the corresponding pixel in the NRP from the pixel in the EMCP. The exemplary offset values ​​of 6, 4, 2, and -2 for the neighboring positions 820 and 6, 6, 6, and 6 for the left neighboring position 810 are shown in FIG. Figure 8 Shown in.

[0022] After obtaining the offset values ​​for the neighboring positions, a derived offset is derived for each position in the current PU 830 as the average of the offsets from the left and above positions, as indicated by arrow 840. For example, at the first position at the top left corner 831 of the current PU 830, an offset of 6 is generated by averaging the offsets from the left and above (i.e., (6+6) / 2=6). For the next position 832 to the right, the offset is derived as 5 (i.e., (6+4) / 2=5). The offset values ​​for the remaining positions can be processed and generated accordingly in raster scan order. Since neighboring pixels have a higher correlation with boundary pixels, so too do the offsets. According to NPO, the offset can be adapted to the pixel position. The derived offset is adjusted across the PU and applied independently to each PU position along with the motion compensation predictor.

[0023] Local Illumination Compensation (LIC)

[0024] Local Illumination Compensation (LIC) is a method for performing inter-frame prediction using neighboring samples of the current block and reference blocks. It is based on a linear model using a scale factor a and an offset b. The method derives the scale factor a and the offset b by referring to the neighboring samples of the current block and the reference block. The neighboring samples of the current block and the reference block correspond to an L-shape, including the neighboring pixels to the left and the neighboring pixels above the current block and the reference block. After deriving the scale factor a and the offset b, the LIC-processed pixel l(x,y) is derived according to l(x,y) = a*r(x,y) + b, where r(x,y) corresponds to the reference data for motion compensation. In addition, the LIC process can be adaptively enabled or disabled for each CU.

[0025] More details about LIC can be found in JVET-C1001 (Xu Chen, et al., “Algorithm Description of Joint Exploration Test Model 3”, Joint Video Exploration Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 3rd Meeting: Geneva, CH, 26 May–1 June 2016, Document: JVET-C1001).

[0026] Traditional Sub-PU Temporal Motion Vector Prediction (Sub-PU TMVP)

[0027] In order to improve coding efficiency, the Sub-PU temporal motion vector prediction (Sub-PU TMVP) (Sub-PU temporal motion vector prediction, also known as Advanced Temporal Motion Vector Prediction (ATMVP)) mode is applied in the merge mode. That is, the Sub-PU TMVP is a merge candidate for the merge mode. Figure 9 As shown in the figure, unlike traditional temporal candidates, the Sub-PU TMVP mode splits the current PU into multiple Sub-PUs and finds all corresponding temporally collocated motion vectors for each Sub-PU. The current PU of size MxN has (M / P)×(N / Q) sub-PUs, and the size of each sub-PU is PxQ, where M is divisible by P and N is divisible by Q. Figure 9 This corresponds to the case where the current PU 910 is partitioned into 16 sub-PUs (ie, M / P=4 and N / Q=4). Sub-PU 0 (911) and sub-PU 1 (912) are indicated. The detailed algorithm of the sub-PU TMVP is described as follows.

[0028] In step 1, for the current PU 910, an "initial motion vector" denoted as vec_init is determined for the sub-PU TMVP mode. For example, vec_init can be the MV of the first available spatial neighboring block of the current PU 910. Alternatively, the MVs of other neighboring blocks can also be used as the initial motion vector. Conventionally, vec_init is the first available candidate among the spatial neighboring blocks. For example, if the first available spatial neighboring block has L0 and L1 MVs, and LX is the first list used to search for collocation information, vec_init uses the L0 MV when LX=L0, or uses L1 when LX=L1. The value of LX (L0 or L1) depends on which list (L0 or L1) is more suitable for collocation information. If L0 is better for collocation information (e.g., POC (Picture Order Count) distance is closer than L1), LX is equal to L0, and vice versa. LX allocation can be performed at the slice level, brick level, slice group level, or picture level.

[0029] Then the "collocated image search process" starts. The "collocated image search process" is to find the main collocated image for all sub-PUs in the Sub-PU TMVP mode. The main collocated image is denoted as main_colpic. Traditionally, it first searches the reference image selected by the first available spatial neighboring block. Then, in the B slice, it searches all reference images of the current image starting from L0 (or L1), reference index 0, then reference index 1, then reference index 2, and so on (increasing index order). If it finishes searching L0 (or L1), it searches another list. In the P slice, it first searches the reference image selected by the first available spatial neighboring block. Then, it searches all reference images of the current image of the list starting from reference index 0, then reference index 1, then search index 2, and so on (increasing index order).

[0030] During the search, a process called "availability check" is performed for each searched image. The "availability check" process checks the collocated sub-PUs around the center position of the current PU pointed to by vec_init_scaled, where vec_init_scaled is the MV with the appropriate MV scaling from vec_init. Various methods can be used to determine "around the center position." "Around the center position" can correspond to the center pixel. For example, if the PU size is M*N, the center is equal to the position (M / 2, N / 2). "Around the center position" can also correspond to the center pixel of the center sub-PU. "Around the center position" can be a hybrid of the two methods mentioned above depending on the shape of the current PU. In the "availability check", if the check result is Inter mode, availability is true; otherwise (the check result is Intra mode), availability is false. After the "availability check", if availability is true, the currently searched image is marked as the main collocated image and the search process ends. If availability is true, the MV of "around the center position" is used and scaled for the current block to derive the "default MV". If availability is false, it will search for the next reference image.

[0031] During the "collocated image search process," MV scaling is required when the reference image in vec_init is not equal to the original reference image. The MV scaling process uses a scaled version of the motion vector. The MV is scaled based on the temporal distance between the current image and the reference image in vec_init, the current image, and the searched reference image. After MV scaling, the scaled MV is denoted as vec_init_scaled.

[0032] In step 2, for each sub-PU, it further finds the collocation position in main_colpic. Assuming that the current Sub-PU is Sub-PU i, the collocation position is calculated as follows:

[0033] collocated location x=Sub-PU_i_x+vec_init_scaled_i_x(integer part)+shift_x,

[0034] collocated location y=Sub-PU_i_y+vec_init_scaled_i_y(integer part)+shift_y.

[0035] In the above equation, Sub-PU_i_x represents the horizontal upper left position (integer position) of sub-PU i within the current image, Sub-PU_i_y represents the vertical upper left position (integer position) of sub-PU i within the current image, vec_init_scaled_i_x represents the horizontal part of vec_init_scaled_i, which has an integer part and a fractional part, and we only use the integer part in the calculation, and vec_init_scaled_i_y represents the vertical part of vec_init_scaled_i, which has an integer part and a fractional part, and we only use the integer part in the calculation. shift_x represents the shift value. shift_x can be half the width of the sub-PU. shift_y represents the shift value. In one example, shift_y can be half the height of the sub-PU, but other methods can also be used.

[0036] Finally, in step 3, it finds the motion information temporal predictor for each sub-PU, which is denoted as SubPU_MI_i. SubPU_MI_i is the motion information (MI) from collocated_picture_i_L0 and collocated_picture_i_L1 at collocated position x and collocated position y. Here MI is defined as a set of {MV_x, MV_y, reference list, reference index and other merge mode sensitive information (such as local illumination compensation flag)}. In addition, in one example, MV_x and MV_y can be scaled according to the temporal distance relationship between the collocated MVs of the collocated picture, the current picture and the reference picture. If MI is not available for some Sub-PUs, the MI of the Sub-PUs around the center position will be used (in other words, the default MV is used).

[0037] Traditionally, there is only one Sub-PU TMVP candidate in the candidate list.

[0038] Spatial-Temporal Motion Vector Prediction (STMVP)

[0039] In JEM-3.0 (Chen et al., "Algorithm Description of Joint Exploration Test Model 3", Joint Video Exploration Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 3rd Meeting: Geneva, CH, 26 May–1 June 2016, Document: JVET-C1001), spatio-temporal motion vector prediction (STMVP) is also included in merge mode coding. In STMVP, the motion vector of the sub-CU is recursively derived following raster scan order by using a temporal motion vector predictor and spatial neighboring motion vectors. Figure 10 The concept of STMVP is illustrated. Let us consider an 8×8 CU 1010 containing four 4×4 sub-CUs, A, B, C and D. The adjacent N×N blocks in the current frame are labeled a, b, c and d. The motion derivation of sub-CU A starts by identifying its two spatial neighbors. The first neighbor is the NxN block above sub-CU A (block c). If block c is not available or is intra-coded, the other N×N blocks above sub-CU A are checked (from left to right, starting from block c). The second neighbor is the block to the left of sub-CU A (block b). If block b is not available or is intra-coded, the other blocks to the left of sub-CU A are checked (from top to bottom, starting from block b). The motion information obtained from the neighboring blocks of each list is scaled to the first reference frame of the given list. Next, the temporal motion vector predictor (TMVP) of sub-block A is derived by following the same process as the TMVP derivation specified in HEVC. The motion information of the co-located block at position D is obtained and scaled accordingly. Finally, after retrieving and scaling the motion information, all available motion vectors (up to 3) are averaged for each reference list separately. The average motion vector is assigned as the motion vector of the current sub-CU.

[0040] PMVD mode or FRUC mode

[0041] The PMVD mode (also known as PMMVD or FRUC (Frame Rate Up Conversion) mode) is a coding tool that can use an L-shaped template or a double-sided template to refine the MV of the merge mode and save bit MVD. The details of FRUC are in JETM3 ("Algorithm Description of Joint Exploration Test Model 3", in Joint Video Exploration Team (JVET) of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11:3rd Meeting: Geneva, CH, 26 May–1 June 2016). The specific section related to FRFUC is Section 2.3.7: Motion Vector Derivation for Pattern Matching.

[0042] The PMVD modes are not limited to those described in the JVET document; any inter-picture mode tool that uses pattern-based refinement as PMVD behavior can also be expressed as a PMVD or FRUC mode.

[0043] LM color mode

[0044] Intra-picture predictors are typically designed to exploit spatial features in images, such as smooth regions (DC mode), vertical lines or edges, horizontal lines or edges, and diagonal lines or edges. In addition, there is often spatial correlation between luminance and chrominance components. Therefore, reconstructed luminance pixels can be used to derive intra-picture chrominance predictions. In the emerging High Efficiency Video Coding (HEVC), a chrominance intra-picture prediction mode based on the reconstructed luminance signal has been considered. This type of chrominance intra-picture prediction is called linear model (LM) prediction. Figure 11 The intra-frame prediction derivation of the LM mode is marked. First, use Figure 11 The adjacent reconstructed pixels (represented by circles) of the juxtaposed luma blocks (i.e., Y blocks) and the adjacent reconstructed pixels (represented by circles) of the chroma blocks (i.e., U or V blocks) in are used to derive the linear model parameters between the blocks. The predicted pixels of the chroma blocks are generated using the parameters and reconstructed pixels of the luma blocks. In the parameter derivation, the top reconstructed pixel column adjacent to the top block boundary of the current luma block and the left reconstructed pixel row adjacent to the left block boundary of the current luma block are used. Note that the second left reconstructed pixel row from the left boundary is used instead of the left row immediately adjacent to the left boundary to match the sampling positions of the chroma pixels. Specific columns and rows of the luma blocks are used to match the 4:2:0 sampling format of the chroma components. Although Figure 11 An example of the LM chroma mode for a 4:2:0 sampling format is shown, but LM chroma modes for other chroma sampling formats can be derived similarly.

[0045] According to the LM prediction mode, chroma values ​​are predicted from the reconstructed luma values ​​of the co-located block. The chroma components can have a lower spatial resolution than the luma components. In order to use the luma signal for chroma intra-picture prediction, the resolution of the luma signal may have to be reduced to match the resolution of the chroma components. For example, with a 4:2:0 sampling format, the U and V components have only half the number of samples in the vertical and horizontal directions as the luma components. Therefore, a 2:1 resolution reduction in the vertical and horizontal directions must be applied to the reconstructed luma samples. This resolution reduction can be achieved through a downsampling process or a subsampling process.

[0046] In LM chroma mode, for a chroma sample V to be predicted with its collocated reconstructed luma sample Vcol, the linear model formula for generating the LM prediction value P is as follows:

[0047] P=a·V col +b

[0048] In the above equation, a and b are called LM parameters. The LM parameters can be derived from the adjacent reconstructed luma and chroma samples around the current block, so that the parameters do not need to be encoded in the bitstream. After deriving the LM parameters, the chroma prediction values ​​can be generated from the collocated reconstructed luma samples in the current block according to the linear model. For example, Figure 11 As shown, if the video format is YUV420, each 8×8 coding unit has one 8×8 luminance block (1110) and two 4×4 chrominance blocks (1120 and 1130). Figure 11 In , each small square corresponds to a pixel being coded in the current coding unit (2Nx2N for luma and NxN for chroma). First, LM parameters are derived based on the neighboring reconstructed samples of the current coding unit, which are Figure 11 Indicated as circles in the image. Due to the YUV420 sampling format, the collocated chroma position is located between two corresponding vertical luma samples. The average value between the two corresponding vertical luma samples is used to derive the LM parameters. For adjacent pixels above the top block boundary, the average value is replaced by the nearest sample in the vertical direction in order to reduce the line buffer requirements. Figure 11 As shown, the neighboring pixels (circled) of the current luma (Y) and chroma (U or V) coding units are used to derive the LM parameters for each chroma component. After the LM parameters are derived, the chroma prediction values ​​are generated based on the linear model and the concatenated luma reconstructed samples. Depending on the video format, the average luma value may be used instead of the corresponding luma sample.

[0049] While QBQT provides flexible segmentation and results in improved encoding performance, it also increases computational complexity. Furthermore, the trend toward using higher-resolution video content also results in increased computational complexity and high buffering requirements. It would be desirable to develop block segmentation and syntax signaling techniques for color video to reduce computational complexity and / or buffering requirements. Summary of the Invention

[0050] According to an embodiment of the present invention, a method and apparatus for block segmentation in video encoding and decoding are disclosed. According to a method of the present invention, input data associated with a current data unit in a current image is received, wherein the input data associated with the current data unit corresponds to pixel data of the current data unit. The current data unit includes a luma component and one or more chroma components, and the current data unit includes a luma data unit and a chroma data unit, or the current data unit includes a luma component block and one or more chroma component blocks. The current data unit is segmented into a plurality of initial blocks using inferred segmentation without segmentation syntax signaling, wherein the plurality of initial blocks include a plurality of initial luma blocks and a plurality of initial chroma blocks, and wherein the size of the initial luma block is MxN, M and N are positive integers, and the current data unit is larger than MxN for the luma component. A segmentation structure is determined for segmenting an initial luma block and one or more initial chroma blocks of the initial block into one or more luma coding units (CUs) and one or more chroma CUs, respectively. One or more luma syntaxes and one or more chroma syntaxes associated with an initial block in the current data unit are sent or parsed, and then one or more luma syntaxes and one or more chroma syntaxes associated with a next initial block in the current data unit are sent or parsed. The current data unit may correspond to a CTU (coding tree unit). In addition, for the luma component, the CTU may have a block size corresponding to 128×128 or 256×256, and M and N are equal to 64. In one embodiment, if there is more than one chroma component, the chroma component data shares the same coding tree partitioning. In one embodiment, the inferred partitioning is applied when the current slice is an I slice or when the current slice is an I slice and non-coding tree sharing is enabled.

[0051] The partitioning structure may include an independent coding tree for each initial block to partition the luminance block and one or more initial chrominance blocks in each initial block. A quadtree (QT) may be used to partition the current data unit into multiple initial luminance blocks with a block size equal to M×N.

[0052] In one embodiment, one or more luma syntaxes associated with an initial block in the current data unit are sent or parsed before one or more chroma syntaxes associated with an initial block in the current data unit.

[0053] In one embodiment, MxN corresponds to a predefined or derived block size, or a maximum transform unit (TU) size, or a size related to a maximum TU size or a minimum TU size. Information related to M and N may be sent at a sequence level, a picture level, a slice level, a tile level, a tile group level, or a tile level.

[0054] In one embodiment, one or more shared or independent syntaxes are sent or parsed for the current data unit to indicate whether the current data unit uses coding tree sharing or non-coding tree sharing. If the one or more shared or independent syntaxes indicate that the current data unit uses coding tree sharing, all coding units within the current data unit use coding tree sharing. If the one or more shared or independent syntaxes indicate that the current data unit uses non-coding tree sharing, all coding units within the current data unit use non-coding tree sharing.

[0055] In one embodiment, one or more shared or independent syntaxes are sent or parsed for a current data unit to indicate whether the current data unit uses coding tree sharing or non-coding tree sharing. If the one or more shared or independent syntaxes indicate that the current data unit uses coding tree sharing, all coding units within the current data unit use coding tree sharing. If the one or more shared or independent syntaxes indicate that the current data unit uses non-coding tree sharing, when the current data unit is larger than MxN for luma components, the current data unit is partitioned into multiple initial blocks using inferred partitioning without using partitioning syntax signaling; a partitioning structure is determined for partitioning an initial luma block and one or more initial chroma blocks of the initial block into one or more luma CUs and one or more chroma CUs, respectively.

[0056] According to another method, a shared tree is used to split the luma data unit and the chroma data unit until the luma data unit and the chroma data unit reach a stop node. If the stop node is larger than MxN for the luma component, the stop node is encoded or decoded as a leaf coding unit, where M and N are positive integers. If the stop node is smaller than or equal to MxN for the luma component, the prediction mode is sent or parsed for the stop node.

[0057] In one embodiment, if the prediction mode of the stop node corresponds to intra-picture mode, one or more first grammars are sent or parsed to indicate whether the stop node uses coding tree sharing or non-coding tree sharing. If the one or more first grammars indicate that the stop node uses coding tree sharing, the stop node is designated as a leaf node. In addition, if the one or more first grammars indicate that the stop node uses non-coding tree sharing, the stop node is further split. One or more luma grammars associated with the stop node may be sent or parsed before one or more chroma grammars associated with the stop node. In another embodiment, if the prediction mode of the stop node corresponds to intra-picture mode or non-inter-picture mode, the stop node is further encoded using non-coding tree sharing.

[0058] In another embodiment, if the stopping node is larger than the MxN for the luma component, the prediction mode of the stopping node corresponds to intra-picture mode and the stopping node uses coding tree sharing. In yet another embodiment, if the stopping node is larger than the MxN for the luma component, then in residual coding of the stopping node, it is inferred that the stopping node is split into multiple transform units. In yet another embodiment, if the stopping node is larger than the MxN for the luma component, the prediction mode of the stopping node is inferred to be inter-picture mode or is not allowed to be intra-picture mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 An example of block partitioning of a coding tree unit (CTU) into coding units (CUs) using a quadtree structure is marked.

[0060] Figure 2 Asymmetric motion partitioning (AMP) according to High Efficiency Video Coding (HEVC) is marked, where AMP defines eight shapes for partitioning a CU into PUs.

[0061] Figure 3 Examples of various binary split types used by a binary tree split structure are shown, where a split type can be used to recursively split a block into two smaller blocks.

[0062] Figure 4 An example of block partitioning and its corresponding binary tree is shown, where in each partition node (i.e., non-leaf node) of the binary tree, a syntax is used to indicate which partition type (horizontal or vertical) is used, where 0 indicates horizontal partitioning and 1 indicates vertical partitioning.

[0063] Figure 5 An example of block partitioning and its corresponding quadtree plus binary tree structure (QTBT) is shown, where solid lines indicate quadtree partitioning and dashed lines indicate binary tree partitioning.

[0064] Figure 6An example of a bilateral template MV refinement (BTMVR) process, also referred to in some literature as decoder-side MV refinement (DMVR), is shown.

[0065] Figure 7 An exemplary implementation of deriving an offset according to a Neighbouring-derived Prediction Offset (NPO) process is shown.

[0066] Figure 8 Another exemplary implementation of deriving offsets according to a neighborhood derived prediction offset (NPO) procedure is shown.

[0067] Figure 9 An example of sub-PU TMVP mode is shown for partitioning the current PU into multiple sub-PUs, and finding all corresponding temporally collocated motion vectors for each sub-PU.

[0068] Figure 10 The concept of spatio-temporal motion vector prediction (STMVP) is shown.

[0069] Figure 11 An example of intra-picture prediction derivation for LM mode is marked.

[0070] Figure 12 A flow chart of an exemplary encoding and decoding system with block partitioning according to an embodiment of the present invention is shown.

[0071] Figure 13 FIG. 4 is a flowchart of another exemplary encoding and decoding system with block partitioning according to an embodiment of the present invention. DETAILED DESCRIPTION

[0072] The following description is a best mode for implementing the present invention. This description is intended to illustrate the general principles of the present invention and should not be considered as limiting. The scope of the present invention can be best determined by reference to the appended claims.

[0073] The use of higher resolution video formats is becoming a trend in various applications. Therefore, video compression for higher resolution video formats becomes more important. In the next generation of video coding, the CTU size and the maximum TU size are larger than 64x64 and 32x32, respectively. For example, the CTU size can be 128x128 or 256x256, and the maximum TU size can be 64x64 or 128x128 for luma and 32x32 or 64x64 for chroma components. However, if we want to reuse the HEVC decoder structure (e.g., 32x32 or 64x64 decoder pipeline), some syntax designs or encoding / decoding algorithms may have to be modified to support larger CTUs and larger TUs.

[0074] In the video coding system design for large CTUs, if the CTU size is larger than the maximum TU size, there are two partitioning methods. One is to implicitly divide the CTU into CUs of a size equal to the maximum TU size, or a predefined, derived, or signaled size, and then explicitly send the CU partitioning syntax. The other is to explicitly send the CU partitioning syntax even when the CU size is larger than the maximum TU size. If the leaf CU size is larger than the maximum TU size, in residual coding, it is inferred that the current CU is divided into multiple TUs of a size equal to the maximum TU size, or a predefined, derived, or signaled size.

[0075] In luma / chroma independent coding, the luma CTB is encoded first, and then the chroma CTBs are encoded (i.e., Cb and CrCTBs). If the luma CTB size is 128x128 or 256x256 and the chroma CTB size is 64x64 or 128x128, then a traditional 64x64 pipeline decoder architecture with the ability to process a 64x64 luma texture / residual buffer and / or two 32x32 chroma texture residual buffers in each pipeline stage or in each pipeline buffer is not suitable. For example, a 128x128 luma CU can be implicitly split into four 64x64 CUs, and a 64x64 chroma CU can also be implicitly split into four 32x32 CUs. However, in the bitstream, the four luma CUs are signaled sequentially. At the decoder, it cannot receive the 64x64 luma texture / residual and the corresponding 32x32 chroma texture / residual together because the 32x32 chroma texture / residual is sent after four 64x64 luma texture / residual blocks. Therefore, the traditional 64x64 pipeline decoder architecture is not suitable for or needs to be modified for independent luma / chroma coding with large CTUs. A CTU is an example of a "data unit" used in the encoding process. Other terms may also be used as data units in other video coding systems.

[0076] In order to reuse the traditional 64×64 (or smaller) pipeline decoder architecture, a technique for reordering the syntax related to the luma / chroma components (e.g., residual, quantization level, prediction mode, coding parameters) interleaved with MxN blocks is disclosed when applying luma / chroma independent coding. The MxN block can be a predefined or derived block size (64×64 block in luma sample resolution), a maximum TU size, a size related to the maximum / minimum TU size, or a block with an area equal to MxN. MxN can also be sent at the SPS, PPS, slice level, brick level, tile group level, or tile level. For convenience, the MxN block is also referred to as a "working block" in this disclosure. It will be understood that the size of the luma component of the working block is M×N. The size of the chroma component of the working block depends on the color format. For example, for the YUV420 format, the size of the chroma (i.e., U or V) block is M / 2×N / 2. First, the luma syntax within the MxN block is encoded, and then the chroma syntax associated with the M×N block is encoded. Within an M×N block, the luma and chroma components may have different coding trees (e.g., different block partitioning). In this case, the CTU is also referred to as "non-coding tree sharing" in this disclosure. In one embodiment, when independent coding trees are applied, the CTU is inferred to be split into multiple CUs, and each CU has multiple M×N blocks. In one example, quadtree partitioning is used for the inferred partitioning. For each M×N block, first, the luma component coding tree is sent, and then the chroma component coding is sent.

[0077] In one example, if the luma CTB size is 128x128 and the chroma CTB size is 64x64, and the maximum TU size is 64x64 for luma and 32x32 for chroma, then the CTU is inferred to be split into four CUs. Four 64x64 luma CUs and four 32x32 chroma CUs are transmitted in an interleaved manner. For example, the 64x64 luma CU is followed by a 32x32 chroma CU (including one 32x32 Cb CU and one 32x32 Cr CU), and then three pairs of {64x64 luma CU, 32x32 chroma CU} are encoded. The 64x64 luma CU and 32x32 chroma CU can be further divided into sub-CUs. In one embodiment, the concept of independent luma / chroma coding can still be applied. The 64x64 luma CU and the 32x32 chroma CU can have different coding trees. In other words, according to embodiments of the present invention, independent tree partitioning can start from the 64x64-luma / 32x32-chroma unit instead of starting from the CTU. For the chroma coding tree, the Cb and Cr component data share the same partitioning tree. For example, each intra-slice (I-slice) CTU is first implicitly split into a 64x64 luma unit and a 32x32-chroma unit. Then, the coding tree for each 64x64 luma and 32x32 chroma unit is separate, and the luma syntax is sent before the chroma syntax within each 64x64 luma unit and 32x32 chroma unit. In one embodiment, in the independent chroma coding tree, the minimum chroma CU is 4x4 or the minimum chroma CU size / area is 16. 2x2, 4x2, 2x4 chroma CUs are disabled. In one embodiment, the method proposed above is only applied to I-slices, where independent coding trees are applied. For inter-slices, the proposed method is not applied.

[0078] In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether the shared coding tree applies to the entire CTU. If so, all CUs within the CTU use the shared coding tree. This CTU-level flag can also be applied to inter-picture slices. If independent trees are selected, the CTU is an intra-picture CTU with independent tree coding. All CUs in the CTU are intra-picture CUs and are coded using independent trees. In another embodiment, if independent trees are selected, the above method is applied. For example, the CTU is inferred to be partitioned into MxN blocks. Independent tree coding is applied to each MxN block.

[0079] In another embodiment, a large CU (CU with size greater than MxN) can be selected. The CTU does not have to be inferred to be divided into multiple MxN blocks. The size of the MxN block can be a predefined or derived block size, equal to the maximum TU size, a size related to the maximum / minimum TU size, or a block with area equal to MxN. MxN can also be sent in SPS, PPS, slice level, brick level, tile group level or tile level. In this embodiment, the CU partitioning syntax is sent in the CTU level. If the CU size is greater than MxN, a shared coding tree is used. If the CU size is equal to the MxN block, an independent coding tree is applied. In one example, the luma CTB size is 128x128 and the chroma CTB size is 64x64, and the maximum TU size for luma is 64x64 and for chroma is 32x32. The CU partitioning syntax is sent at the CTU level. If a leaf CU is larger than 64x64 (e.g., a 128x128 CU), the CU is divided into several TUs based on the inferred partitioning or the sent TU partitioning syntax for residual coding. The TU size shall be equal to or smaller than the maximum TU size. For each TU, the luma coefficient is sent first, followed by the chroma coefficients.

[0080] If the CU size is larger than 64×64, a shared coding tree is applied. For example, in a 128×128 CU, if the split flag is true or the split syntax indicates that the CU is split, the luma CU and chroma CU are split simultaneously using the same split method. In other words, the luma CU and chroma CU share the same coding tree. It is also called CU using "shared coding tree" or CU using "coding tree sharing". When the CU size is equal to 64x64, an independent coding tree is applied. For a 64x64 block, a 64x64 luma CU and a 32x32 chroma CU can have different coding trees. In other words, according to this embodiment, independent tree splitting can start from the 64×64-luma / 32×32-chroma unit instead of starting from the CTU. For blocks larger than 64x64, a shared coding tree is applied.

[0081] In one embodiment, in an independent chroma coding tree, the smallest chroma CU is 4×4 or the smallest chroma CU size / region is 16. 2x2, 4x2, and 2x4 chroma CUs are disabled. In one embodiment, the above-mentioned method is applied only to I slices, where independent coding trees are applied. For inter-picture slices, the above-mentioned method is not applied. In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether coding tree sharing applies to the entire CTU. If so, all CUs within the CTU use a shared coding tree. In other words, the luma and chroma components within each CU of the CTU share a coding tree.

[0082] In another embodiment, for I slice coding, a shared coding tree is applied as the default value. The partitioning syntax starts to be signaled at the CTU level. When the CU size is larger than M×N, the shared coding tree is applied. If the CU size is equal to MxN, one or more shared / independent coding tree syntaxes (also called shared or independent syntax) are sent. The MxN block can be a predefined or derived block size that is equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be sent in SPS, PPS, slice level, brick level, tile group level or tile level. If coding tree sharing is selected, the luminance and chrominance CU partitioning within this MxN uses a shared coding tree. If non-coding tree sharing is applied, the luminance and chrominance CU partitioning within this MxN uses independent coding trees. Otherwise, the shared tree is used for this MxN area. MxN cannot be larger than the maximum TU size.

[0083] In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether coding tree sharing applies to the entire CTU. If so, all CUs within the CTU use coding tree sharing. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions of the CTU use coding tree sharing. If so, all intra-picture regions within the CTU use a shared coding tree. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions within an MxN sized CTU use coding tree sharing. If so, all intra-picture regions within the MxN size within the CTU use coding tree sharing. In this case, the luma and chroma components in each region share a coding tree. Otherwise, all intra-picture regions within the MxN size within the CTU use non-coding tree sharing. In one embodiment, in an independent chroma coding tree, the smallest chroma CU is 4×4.

[0084] In another embodiment, for I-slice coding, a shared coding tree is applied as the default. Split syntax is sent at the CTU level. If CU splitting stops and the CU size is equal to or less than MxN, one or more shared / independent coding tree syntaxes (also called shared or independent syntax) are sent in each leaf CU. The size of the MxN block can be a predefined or derived block size, or equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be sent in the SPS, PPS, slice level, brick level, tile group level, or tile level. In this embodiment, CU split syntax is sent at the CTU level. When a shared coding tree is selected, it implies intra-picture CUs. If independent coding trees are applied, split syntax and independent luma / chroma CU coding are sent after one or more shared / independent coding tree syntaxes. In one example, if an independent coding tree is selected (i.e., non-coding tree sharing), the first luma CU is inferred to be split. In this case, only the split mode is sent. In another example, if the luma CU is not split, the chroma CU is inferred to be split. In this case, only the split mode is sent. In one embodiment, if the CU size is equal to or less than OxP, independent coding tree syntax is not sent. It is inferred that a shared coding tree applies. OxP can be predefined or sent in SPS, PPS, slice level, brick level, tile group level or tile level. For leaf CU sizes greater than M×N, a shared coding tree is applied. The proposed method can also be applied to inter-picture slice coding. In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether the shared coding tree applies to the entire CTU. If so, all CUs within the CTU use the shared coding tree. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions of the CTU use the shared coding tree. If so, all intra-picture regions within the CTU use the shared coding tree (i.e., coding tree sharing). In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions within the MxN size of the CTU use the shared coding tree (i.e., coding tree sharing). If yes, all intra-picture regions within the MxN size within the CTU use independent coding trees (i.e., non-coding tree sharing). In one embodiment, in a separate chroma coding tree, the smallest chroma CU is 4x4 or the smallest chroma CU size / region is 16 samples.

[0085] In another embodiment, the CTU size of an I slice with an independent coding tree is constrained to be no larger than MxN. MxN can be a predefined or derived block size, equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be signaled in the SPS, PPS, slice level, brick level, tile group level, or tile level. For inter-layer slices, the CTU size can be unconstrained to be less than or equal to MxN. For example, the CTU size can be larger than MxN for inter-picture slices.

[0086] In the present invention, independent coding trees can also be applied to inter-picture slices. Independent coding trees are applied to intra-picture coded CUs, which are equal to or less than M×N in size. The MxN block can be a predefined or derived block size, equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be sent at the SPS, PPS, slice level, brick level, tile group level or tile level. When the CU is larger than MxN, a shared coding tree is applied. If the split flag is true or the split syntax indicates that the CU is split, the luminance CU and chrominance CU are split at the same time using the same partitioning.

[0087] When a CU is equal to M×N, syntax is sent to indicate whether an independent coding tree (i.e., non-coding tree sharing) is applied to the M×N block. In one example, independent coding trees are only used for intra-picture CUs. If an M×N block chooses to use an independent coding tree, the prediction mode of the CU within the M×N is inferred as intra-picture mode. In another example, an independent coding tree is applied to the intra-picture region within the M×N region. If an M×N block chooses to use an independent coding tree, an independent coding tree is used, and the intra-picture coding blocks within the M×N region are inferred. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions of the CTU use a shared coding tree. If so, all intra-picture regions within the CTU use a shared coding tree. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions within the M×N size of the CTU use a shared coding tree. If so, all intra-picture regions within the M×N size of the CTU use independent coding trees. In another embodiment, one or more syntax elements are sent at the CTU level to indicate whether all intra-picture regions within the MxN size of the CTU are coded using intra-picture mode and independent tree coding. If so, all CUs within the CTU are coded using intra-picture mode, and independent tree coding is applied within each MxN block. In one example, the selection of independent tree coding is inferred for the CTU to be split into multiple MxN blocks. QT partitioning may be used. In one embodiment, for independent chroma coding trees, the smallest chroma CU is 4x4.

[0088] In another embodiment, when the CU is larger than M×N, a shared coding tree is applied. If the leaf CU is larger than M×N, an independent coding tree (e.g., a shared coding tree) is not applied. In residual coding, it is inferred that the CU is divided into TUs. In one example, when the CU is not further partitioned, the prediction mode is sent. If the intra-screen mode is selected and the CU size is equal to or less than M×N, one or more other independent syntaxes are sent. If the CU is further partitioned, an independent coding tree is applied. In one example, the partitioning syntax that has been sent is for the luma component. If the CU is not further partitioned, it is an intra-screen leaf CU. In another example, when the CU is not further partitioned, the prediction mode is sent. If the intra-screen mode is selected and the CU size is equal to or less than M×N, one or more independent coding tree syntaxes (also called shared or independent syntaxes) are sent to indicate whether the CU uses an independent coding tree. If not, it is an intra-screen leaf CU. If yes, an independent coding tree is applied. For a CU, the luma component and the chroma component can have different coding trees. The luma component syntax is sent before the chroma component syntax. All sub-CUs within the CU are inferred to be in intra mode or non-inter mode. When the CU size is greater than MxN or the prediction mode is inter mode (or intra block copy mode), independent coding tree syntax (e.g., a flag indicating whether independent coding is applied) is not sent and is inferred to be not applied. In one example, if an independent coding tree is selected, the first luma CU is inferred to be partitioned. In this case, only the partition mode is sent. In another example, if the luma CU is not partitioned, the chroma CU is inferred to be partitioned. In this case, only the partition mode is sent. In another example, when intra mode is selected and the CU size is equal to or less than MxN, an independent coding tree is always applied. In this CU, partition syntax is always sent except when the CU is the smallest CU. If the leaf CU size is greater than MxN and is intra coded, for residual coding, the CU is split into multiple TUs (e.g., via inferred partitioning or sent TU partitioning syntax) such that the TU size should be equal to or less than the maximum TU size. For each TU, the luma coefficient is sent, followed by the chroma coefficients.

[0089] In one embodiment, if the CU size is equal to or less than OxP, independent coding tree syntax (also known as shared or independent syntax) is not sent. A shared coding tree is inferred to apply. OxP can be predefined or sent in the SPS, PPS, slice level, brick level, tile group level, or tile level. In one embodiment, in an independent chroma coding tree, the smallest chroma CU is 4×4. In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether the shared coding tree applies to the entire CTU. If so, all CUs within the CTU use the shared coding tree. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions of the CTU use the shared coding tree. If so, all intra-picture regions within the CTU use independent coding trees. In another embodiment, one or more syntaxes are sent at the CTU level to indicate whether all intra-picture regions within the MxN size of the CTU use the shared coding tree. If so, all intra-picture regions within the CTU (e.g., leaf CUs with a size less than or equal to MxN and with intra-picture mode) within the MxN size of the CTU use independent coding trees (i.e., non-coding tree sharing). In another embodiment, one or more syntax elements are sent at the CTU level to indicate whether the CTU is an intra-picture CTU with independent tree coding. If so, all CUs in the CTU are intra-picture CUs and are coded with independent trees.

[0090] In another embodiment, when the CU is larger than M×N, a shared coding tree is applied. The CU partitioning syntax is sent in a signal format at the CTU level. If the CU is not further partitioned and the leaf CU is larger than MxN, the prediction mode is inferred to be inter-screen mode, or intra-screen mode cannot be selected (for example, bitstream consistency prevents the selection of intra-screen mode). If the CU stops being partitioned and the leaf CU is equal to or smaller than MxN, the prediction mode is sent or derived. If the intra-screen mode is selected and the CU size is equal to or smaller than M×N, one or more independent coding tree syntaxes (also called shared or independent syntaxes) are sent to indicate whether the intra-screen CU uses an independent coding tree. If not, the CU is designated as an intra-screen leaf CU (i.e., no further partitioning). If yes, an independent coding tree (i.e., non-coding tree sharing) is applied. For this CU, the luminance component and the chrominance component can have different coding trees. The luminance component syntax is sent before the chrominance component syntax. All sub-CUs within the CU are inferred to be in intra-screen mode. When the CU size is larger than M×N or the prediction mode is inter mode, independent coding tree syntax (eg, a flag indicating whether independent coding is applied) is not sent and is inferred to be not applied.

[0091] In one instance, if an independent coding tree is selected, the first luma CU is inferred to be split. In this case, only the split mode is sent. In another example, if the luma CU is not split, the chroma CU is inferred to be split. Only the split mode is sent. In another example, when intra mode is selected and the CU size is equal to or less than M×N, an independent coding tree (i.e., non-coding tree sharing) is always applied. In this CU, the split syntax is always sent except when the CU is the smallest CU. In one embodiment, if the CU size is equal to or less than 0xP, the independent coding tree syntax (also called shared or independent syntax) is not sent. A shared coding tree is inferred to be applied. OxP can be predefined or sent in SPS, PPS, slice level, brick level, tile group level, or tile level. In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether the shared coding tree applies to the entire CTU. If so, all CUs within the CTU use the shared coding tree. In one embodiment, in the independent chroma coding tree, the smallest chroma CU is 4×4. In another embodiment, one or more syntax elements are sent at the CTU level to indicate whether all intra-picture regions of the CTU use a shared coding tree. If so, all intra-picture regions within the CTU use independent coding trees. In another embodiment, one or more syntax elements are sent at the CTU level to indicate whether all intra-picture regions within the MxN size of the CTU use a shared coding tree. If so, all intra-picture regions within the MxN size of the CTU use independent coding trees. In one embodiment, in independent chroma coding trees, the smallest chroma CU is 4×4.

[0092] In yet another embodiment, for inter-layer coding, one or more independent tree syntaxes are sent at the MxN block level. The MxN block can be a predefined or derived block size, equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be sent at the SPS, PPS, slice level, brick level, tile group level, or tile level. If shared tree coding is selected, all CUs in the MxN region use shared tree coding. If independent tree coding is selected, intra-screen CUs within the MxN region use independent tree coding. For example, within the MxN region, if the CU stops being split, the inter / intra mode is sent. If the CU is in intra mode and independent tree coding is applied, further splitting syntax for luma and chroma components is sent. Note that QT / BTT constraints can still be applied. If the intra CU is split using BT or TT splitting, the luma and chroma coding trees can only be further split using BT and / or TT splitting. In another example, if the intra-frame CU is split using BT or TT partitioning, the luma and chroma coding trees can be further partitioned using QT, BT and / or TT partitioning. If independent tree coding is selected, the smallest chroma CU in the independent chroma coding tree is 4×4.

[0093] In yet another embodiment, for inter-layer coding, one or more independent tree syntaxes are sent at the CTU level. If a shared coding tree is selected, all CUs are encoded using shared tree coding. If independent tree coding (i.e., non-coding tree sharing) is selected, the intra-screen CUs in the CTU are coded using independent trees. In another example, if independent tree coding is selected, the intra-screen CUs within the CTU are coded using independent trees, except for the intra-screen CUs with a size greater than M×N. For example, when an intra-screen CU with a size greater than M×N is coded using a shared coding tree, the intra-screen CU is actually a leaf intra-screen CU. The intra-screen CU is divided into one or more TUs. The size of the TU should be less than MxN. The MxN block can be a predefined or derived block size, or equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be sent in the SPS, PPS, slice level, brick level, tile group level, or tile level. For example, if the CU stops being split, the inter / intra mode is signaled. If the CU is an inter-coded CU or an intra-coded CU and has a size greater than MxN, it uses shared tree coding (i.e., coding tree sharing). If the CU is an intra-coded CU and has a size less than or equal to M×N and independent tree coding is selected for the CTU, further partitioning syntax for luma and chroma components is sent. Note that QT / BTT constraints may still apply. If the intra-CU is partitioned via BT or TT partitioning, the luma and chroma coding trees can only be further partitioned using BT and / or TT partitioning. In another example, if the intra-CU is partitioned via BT or TT partitioning, the luma and chroma coding trees may be further partitioned using QT, BT, and / or TT partitioning. If independent tree coding is selected, the smallest chroma CU in the independent chroma coding tree is 4×4.

[0094] In another embodiment, in I-slice coding, if the luma CTB size is 128x128 and the chroma CTB size is 64x64, and the maximum TU size is 64x64 for luma and 32x32 for chroma, then even when the CU size is larger than the maximum TU size, the CU partitioning is explicitly signaled (e.g., a split flag is signaled in a 128x128 luma CU and a 64x64 chroma CU). If the 128x128 luma CU is split into four 64x64 CUs, the chroma components are encoded / decoded after the first 64x64 CU is encoded. The first 64x64 CU can be further split into sub-CUs. If the 64x64 chroma CU is also split into four 32x32 CUs, the first 32x32 chroma CU is encoded / decoded. The first 32x32 chroma CU can also be further split into sub-CUs. After encoding / decoding the first 32x32 chroma CU, the second 64x64 luma CU is encoded / decoded, and the second 32x32 chroma CU is encoded / decoded, and so on. If the 128x128 luma CU is split into four 64x64 CUs but the 64x64 chroma is not split into sub-CUs (the chroma TU is inferred to be four 32×32 TUs), embodiments of the present invention encode / decode the first 64x64 luma CU and then encode / decode the mode information of the 64x64 chroma CU and the first 32x32 chroma TU. After encoding / decoding the first 32x32 chroma TU, the second 64x64 luma CU is encoded / decoded, and the second 32x32 chroma TU is encoded / decoded, and so on.

[0095] A similar concept can be applied when the 128x128 luma CU is not split but the 64x64 chroma CU is split. It first encodes / decodes the mode information of the 128x128 luma CU and the first 64x64 luma TU, and then encodes / decodes the partition syntax of the 64x64 chroma CU and the first 32x32 chroma CU. After encoding / decoding the first 32x32 chroma CU, the second 64x64 luma TU is encoded / decoded, and the second 32x32 chroma CU is encoded / decoded, and so on. In another example, if the 128x128 luma CU and the 64x64 chroma CU are not split, the partition syntax and mode information of the 128x128 luma CU are first encoded / decoded, and then the first 64x64 luma TU is encoded / decoded. Then, the partition syntax and mode information of the 64x64 chroma CU and the first 32x32 chroma CU are encoded / decoded. After encoding / decoding the first 32x32 chroma TU, the second 64x64 luma TU is encoded / decoded, the second 32x32 chroma TU is encoded / decoded, and so on. The methods proposed in this paragraph and the previous paragraph can also be applied to Inter-slice. In inter-slice coding and decoding, for each CU (not limited to leaf CUs), one or more independent coding tree syntaxes are sent at the CTU level. If independent coding trees are applied, the methods proposed in this paragraph and the previous paragraph are applied. All sub-CUs in the CU can be inferred to be intra-screen mode. In one embodiment, one or more syntaxes are sent at the CTU level to indicate whether the shared coding tree applies to the entire CTU. If so, all CUs within the CTU use it (i.e., the coding tree is shared).

[0096] In another embodiment, for inter-picture coding, whether to use independent trees is determined at the MxN block level. The MxN block can be a predefined or derived block size, or equal to the maximum TU size, or a size related to the maximum / minimum TU size, or equal to the CTU size. MxN can also be sent in the SPS, PPS, slice level, brick level, tile group level, or tile level. When encoding / decoding CU partitioning from the CTU level, one or more independent tree syntaxes are sent when encoding an intra-picture coded leaf CU with a CU size (area, width, or height) equal to or greater than MxN. If an independent tree is selected, the area of ​​the intra-picture CU is coded using an independent tree. Further luma / chroma independent syntax is sent. When the CU partition reaches an MxN area, the syntax corresponding to using independent trees is set to false. When encoding an intra-picture coded leaf CU with a CU size (e.g., area, width, or height) less than MxN and the syntax indicating the use of independent trees is equal to false, one or more independent tree syntaxes are sent. If independent tree is selected, intra-view CUs in the MxN region are coded using independent trees. For intra-view CUs, additional luma / chroma independent syntax is sent, and the syntax indicating the use of independent trees is set to true. In this MxN region, additional independent tree syntax cannot be sent. In other words, independent tree syntax in an MxN region can only be sent once. The sent syntax is shared by all CUs in the MxN region. If shared tree coding is selected, all CUs in the MxN region are coded using the shared tree. If independent tree coding is selected, intra-view CUs in the MxN region are coded using independent trees. Note that QT / BTT constraints may still apply. If the intra-view CU is split using BT or TT partitioning, further partitioning of the luma and chroma coding trees can only use BT and / or TT partitioning. In another example, if the intra-view CU is split using BT or TT partitioning, further partitioning of the luma and chroma coding trees can use QT, BT, and / or TT partitioning. If independent tree coding is selected, the smallest chroma CU in the independent chroma coding tree is 4×4.

[0097] In one embodiment, independent coding trees cannot be applied to blocks with block sizes larger than M×N. MxN blocks can be of a predefined or derived block size, equal to the maximum TU size, or a size related to the maximum / minimum TU size. Size information related to MxN can also be signaled in the SPS, PPS, slice level, brick level, tile group level, or tile level. In another embodiment, independent coding trees can only be applied to blocks with block sizes equal to or smaller than M×N. MxN blocks can be of a predefined or derived block size, equal to the maximum TU size, or a size related to the maximum / minimum TU size. MxN can also be signaled in the SPS, PPS, slice level, brick level, tile group level, or tile level. When the CU size is larger than M×N, a shared coding tree partitioning is applied. In the original design for independent partitioning of luma and chroma, the shapes of luma and chroma blocks can be different, so a luma block can span different chroma blocks, and vice versa. One consequence is that luma and chroma blocks must be processed independently, and buffered samples used for prediction and reconstruction may need to be kept in memory until the entire unit is processed. On the other hand, for example, if all luma blocks do not extend across different chroma blocks (i.e., each luma block is completely within a chroma block), then after processing a particular chroma block and the luma blocks within it, the buffered samples used to process that block can be discarded. To achieve this, the same split can be applied multiple times to luma and chroma, and then further splitting can be disabled for one of the components. Whether to disable further splitting can be explicitly signaled or implicitly derived from the size or depth of the current block.

[0098] In one embodiment, before or after each luma split flag, a flag chroma_split_end is sent, indicating whether the chroma split is terminated at this point and that subsequent splits will only apply to the luma component. Before chroma_split_end is true, the chroma split is the same as the luma split. The flag chroma_split_end can be used to indicate that the corresponding split flag represents the last split applied to the chroma component, or that the corresponding split flag and subsequent split flags are not applicable to the chroma component. In one example, when the luma leaf CU is reached and the chroma split is not terminated (e.g., chroma_split_end is all false), chroma_split_end is inferred to be true, which means that the chroma component is no longer split. In another example, when the luma split reaches the luma leaf CU and the chroma split is not terminated, the chroma_split syntax is applied. The chroma component can be further split into smaller CUs. When the luma component is coded quadtree split, binary tree split, or ternary tree split, chroma_split_end can be sent or inferred. In one example, when the luma component is coding a quadtree split, chroma_split_end can be sent or inferred. If the QT split precedes the BT and / or TT split, this means that when the luma component is QT split, the chroma components must follow the QT split or stop splitting. When the luma component is BT / TT split, the chroma components are free to use BT / TT splits. In another example, the chroma QT split can be stopped before the luma QT leaf CU, and the chroma QT leaf CU can be further split by using BT / TT splits.

[0099] In another embodiment, before or after each split flag, a flag luma_split_end is sent to indicate whether the luma split is terminated at this time. Subsequent splits will only be applied to chroma components. The luma_split_end flag can be used to indicate that the corresponding split flag represents the last split applied to the luma component, or that the corresponding split flag and subsequent split flags are not applicable to the luma component. In one example, when the chroma leaf CU is reached and the luma split is not terminated (for example, luma_split_end is all false), luma_split_end is inferred to be true, which means that the luma component is no longer split. In another example, when the chroma split reaches the chroma leaf CU and the luma split is not terminated, the luma_split syntax is applied. The luma component can be further split into smaller CUs. In some embodiments, the aforementioned chroma_split_end and luma_split_end flags may also be used.

[0100] The concepts of QT depth and BT / TT depth can be used. When a CU is split using QT / BT / TT partitioning, the QT depth / BT depth / TT depth increases by 1. BT depth and TT depth can be combined into CT depth (coding tree depth). For example, when a CU is split using BT or TT partitioning, the CT depth increases by 1. In one embodiment, the chroma QT depth cannot be greater than the luma QT depth plus a threshold. The threshold can be zero, positive, or negative. In the example where the threshold is zero, if the QT depth of its corresponding luma block is 2, the maximum QT depth of the chroma CU cannot be greater than 2. Constraints can be applied through syntax constraints, such as no QT split syntax when the chroma QT depth reaches the maximum QT depth, or through encoder constraints, such as bitstream conformance requiring that the chroma QT depth should not be greater than the maximum QT depth. Similar constraints can be applied to BT depth / TT depth / CT depth or total depth. For example, the chroma QT depth + CT depth cannot be greater than the QT depth + CT depth of its corresponding luma block plus a threshold. In one example, only the chroma QT depth is constrained. The chroma BT / TT / CT depth is independent of its corresponding luma CU.

[0101] In another embodiment, a similar concept using the syntax chroma_split_end can be implemented by using another syntax design. For example, the luma coding tree is encoded or decoded first. When encoding the luma leaf CU or after encoding the luma leaf CU, the syntax is encoded / parsed to indicate the chroma leaf CU size. The syntax can be related to the split depth (e.g., QT depth, BT depth, TT depth, CT depth and / or total depth). For example, the syntax chroma_depth_above can be used. If chroma_depth_above is equal to 0, it means that the chroma CU and luma CU are split in the same way and have the same CU size. For the 4:2:0 format, the same CU size means that the actual chroma CU size is 1 / 4 of the actual luma CU size. If chroma_depth_above is greater than 0 (e.g., K, K>0), it means that the chroma CU splitting is stopped before depth K. For example, if the luma leaf CU has a QT depth of 3 and a CT depth of 0, the maximum CTU size is 128, and the size of the luma leaf CU is 16x16. If chroma_depth_above is equal to 1, it means that the chroma CU size is 32x32. The QT depth of the chroma CU is 2. In this example, if chroma_depth_above is sent in this 32×32 region, the chroma_depth_above syntax is not sent for the subsequent luma leaf CU. For example, for the next 3 luma QT CUs of size equal to 16×16 (not necessarily leaf CUs), the syntax chroma_depth_above is not sent. For the first luma leaf CU in the next 32x32 region, the syntax chroma_depth_above is not sent. The chroma CU syntax may be sent after the first luma leaf CU or after the 32×32 region (the 32x32 region is an example based on the above example chroma_depth_above value).

[0102] In another embodiment, consider the chroma LM mode. Since the LM mode is a powerful coding tool for compressing chroma component data, the LM mode syntax shortcut can be applied using the method described above. For example, when chroma_split_end is equal to 1 or chroma_depth_above is sent, the LM syntax can be applied.

[0103] In another embodiment, adaptive chroma mode syntax is proposed. The chroma mode syntax can be intra-picture prediction mode related syntax, motion information or transform / residual related syntax. When the chroma CU size or depth is smaller than, equal to or greater than the corresponding luma CU size or depth, the chroma syntax order / codeword can be different. For example, if the chroma CU size is smaller than the corresponding luma CU size or if the chroma CU depth is greater than the corresponding luma CU depth, the DM mode syntax is moved backward. For example, the DM mode candidate is moved backward in the most probable mode list, or the DM mode syntax is moved after the normal syntax position.

[0104] In another embodiment, a maximum segmentation depth or minimum block size that allows unified segmentation of luma and chroma can be specified in a high-level syntax such as an SPS, PPS, VPS, or slice header. Once the segmentation depth exceeds the maximum depth, or the block size becomes smaller than the minimum size, only further segmentation of one of the luma and chroma components is allowed. In another embodiment, if the segmentation depth is less than the maximum segmentation depth or the block size is greater than the minimum block size, unified segmentation of luma and chroma is applied. Once the segmentation depth exceeds the maximum depth, or the block size becomes smaller than the minimum size, independent luma / chroma coding trees are applied.

[0105] In another embodiment, the luma CU structure and the chroma CU structure should have some correlation in terms of coding unit partitioning. In order to reduce encoding runtime and improve encoding efficiency, the chroma CU partitioning should follow the luma CU partitioning, but the chroma CU partitioning can be terminated early or can be further partitioned. For example, if the corresponding luma CU is using QT partitioning / BT vertical partitioning / BT horizontal partitioning, the chroma CU has two options. One is to follow the luma partitioning type and the other is not to partition. If the corresponding luma CU is not partitioned, the chroma CU can be further partitioned, or in one embodiment, the partitioned chroma CU cannot be partitioned. The early termination flag or the following partition flag can be inferred under certain constraints. For one example, the first K layers, the chroma CU partitioning always follows the luma CU partitioning. In another instance, when the CU size is larger than MxN, the chroma CU partitioning always follows the luma CU partitioning. In another example, the chroma QT partitioning always follows the luma QT partitioning. The early stop flag is only applicable to BT partitioning.

[0106] The constraints can be adaptive. For example, K, M, and N can be derived from the decoded CU or neighboring CUs.

[0107] In another embodiment, the proposed guided CU partitioning is applied only when the chroma CU and luma CU have the same QT depth, which means that the chroma BT partitioning follows the luma BT partitioning if their QT leaf CUs have the same size.

[0108] In another example, the chroma QT segmentation always follows the luma QT segmentation (ie, share the same QT segmentation), but there is no constraint on the BT segmentation.

[0109] Note that in this invention, the 4:2:0 chroma format is used. Therefore, for a 64x64 luma block, the corresponding chroma block is 32x32. All descriptions are based on this chroma format. The proposed method can also be applied to different chroma formats, such as 4:4:4, 4:2:2, and 4:0:0. In this invention, one or more methods can be applied together.

[0110] Any of the aforementioned proposed methods may be implemented in an encoder and / or a decoder. For example, any of the proposed methods may be implemented in an entropy coding module or a block segmentation module in an encoder, and / or in an entropy parser module or a block segmentation module in a decoder. Alternatively, any of the proposed methods may be implemented as a circuit coupled to an entropy coding module or a block segmentation module in an encoder, and / or an entropy parser module or a block segmentation module in a decoder, so as to provide information required by the entropy parser module or the block segmentation module.

[0111] Figure 12 A flowchart of an exemplary encoding and decoding system with block partitioning according to an embodiment of the present invention is shown. The steps shown in the flowchart and other subsequent flowcharts in this disclosure can be implemented as program code executable on one or more processors (e.g., one or more CPUs) on the encoder side and / or the decoder side. The steps shown in the flowchart can also be implemented based on hardware, such as one or more electronic devices or processors arranged to perform the steps in the flowchart. According to the method, in step 1210, input data associated with a current data unit in a current image is received, wherein the input data associated with the current data unit includes a luma component and a chroma component. In step 1220, when the current data unit is larger than MxN for the luma component, the current data unit is partitioned into a plurality of initial blocks using inferred partitioning without using partitioning syntax signaling, wherein each of the plurality of initial blocks includes an initial luma block and an initial chroma block, where M and N are positive integers. In step 1230, a partitioning structure is determined for partitioning each initial luma block and each initial chroma block into one or more luma CUs (coding units) and one or more chroma CUs, respectively. In step 1240, one or more luma syntaxes and one or more chroma syntaxes associated with an initial block in the current data unit are sent or parsed, and then one or more luma syntaxes or one or more chroma syntaxes associated with the next initial block in the current data unit are sent or parsed.

[0112] Figure 13A flowchart of another exemplary encoding system with block partitioning according to an embodiment of the present invention is shown. According to the method, in step 1310, input data associated with a current data unit in a current image is received, wherein the input data associated with the current data unit corresponds to pixel data of the current data unit at the encoder side, or the input data associated with the current data unit corresponds to encoded pixel data of the current data unit at the decoder side, and wherein the current data unit includes a luma component and a chroma component, and the current data unit includes a luma data unit and a chroma data unit. In step 1320, a shared tree is used to partition the luma data unit and the chroma data unit until the luma data unit and the chroma data unit reach a stop node. In step 1330, if the stop node is greater than MxN for the luma component, the stop node is encoded or decoded as a leaf CU (coding unit), where M and N are positive integers. In step 1340, if the stop node is less than or equal to MxN for the luma component, a prediction mode is sent or parsed for the stop node.

[0113] The flowchart shown is intended to illustrate an example of video encoding according to the present invention. Without departing from the spirit of the present invention, one skilled in the art may modify each step, rearrange the steps, split the steps, or combine the steps to implement the present invention. In this disclosure, specific syntax and semantics have been used to illustrate examples for implementing embodiments of the present invention. One skilled in the art may practice the present invention by replacing the syntax and semantics with equivalent syntax and semantics without departing from the spirit of the present invention.

[0114] The above description is presented to enable one skilled in the art to practice the present invention provided in the context of a specific application and its requirements. Various modifications to the described embodiments will be apparent to one skilled in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not limited to the specific embodiments shown and described, but is consistent with the widest range consistent with the principles and novel features disclosed herein. In the above detailed description, various specific details are shown to provide a thorough understanding of the present invention. However, one skilled in the art will appreciate that the present invention may be implemented.

[0115] The embodiments of the present invention described above can be implemented in various hardware, software code, or a combination of both. For example, embodiments of the present invention can be implemented as one or more circuits integrated into a video compression chip or as program code integrated into video compression software to perform the processing described herein. Embodiments of the present invention can also be implemented as program code to be executed on a digital signal processor (DSP) to perform the processing described herein. The present invention can also involve many functions performed by computer processors, digital signal processors, microprocessors, or field programmable gate arrays (FPGAs). These processors can be configured to perform specific tasks according to the present invention by executing machine-readable software code or firmware code that defines the specific methods embodied by the present invention. The software code or firmware code can be developed in different programming languages ​​and in different formats or styles. The software code can also be compiled for different target platforms. However, different code formats, styles, and languages ​​for the software code, as well as other means of configuring the code to perform the tasks according to the present invention, do not depart from the spirit and scope of the present invention.

[0116] The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics of the present invention. The examples described are to be considered in all respects as illustrative only and not restrictive. The scope of the present invention is therefore indicated by the appended claims rather than the foregoing description. All variations that come within the meaning and range of equivalence of the claims are intended to be included within their scope.

Claims

1. A video encoding and decoding method, used by a video encoding and decoding system, the method comprising: receiving input data associated with a current data unit in a current image, wherein the input data associated with the current data unit corresponds to pixel data of the current data unit, and wherein the current data unit includes a luma component and a chroma component, and the current data unit includes a luma data unit and a chroma data unit; Splitting the luma data unit and the chroma data unit using a shared tree until the luma data unit and the chroma data unit reach a stop node; If the stop node is larger than MxN for the luma component, the stop node is encoded or decoded as a leaf coding unit, where M and N are positive integers; as well as If the stopping node is less than or equal to MxN for the chroma component, the prediction mode of the stopping node is sent or parsed.

2. The video encoding and decoding method according to claim 1, wherein: If the prediction mode of the stopping node corresponds to intra mode or non-inter mode, one or more first syntax elements are sent or parsed to indicate whether the stopping node uses coding tree sharing or non-coding tree sharing.

3. The video encoding and decoding method according to claim 2, wherein: If the one or more first syntaxes indicate that the stopping node uses the coding tree share, then the stopping node is designated as a leaf node.

4. The video encoding and decoding method according to claim 2, wherein: If the one or more first syntaxes indicate that the stopping node uses the non-coding tree share, the stopping node is further split.

5. The video encoding and decoding method according to claim 4, wherein: The one or more luma syntaxes associated with the stop node are sent or parsed before the one or more chroma syntaxes associated with the stop node.

6. The video encoding and decoding method according to claim 1, wherein: If the stopping node is larger than MxN for the luma component, the prediction mode of the stopping node corresponds to intra mode and the stopping node uses coding tree sharing.

7. The video encoding and decoding method according to claim 1, wherein: If the prediction mode of the stopping node corresponds to intra mode or non-inter mode, the stopping node is further encoded using non-coding tree sharing.

8. The video encoding and decoding method according to claim 1, wherein: If the stopping node is larger than MxN for the luma component, then in the residual coding of the stopping node, the stopping node is inferred to be split into multiple transform units.

9. The video encoding and decoding method according to claim 1, wherein: If the stopping node is larger than MxN for the luma component, the prediction mode of the stopping node is inferred to be inter mode or intra mode is not allowed.

10. A video encoding and decoding device, used in a video encoding system and a video decoding system, respectively, the device comprising one or more electronic circuits or processors for: receiving input data associated with a current data unit in a current image, wherein the input data associated with the current data unit corresponds to pixel data of the current data unit, and wherein the current data unit includes a luma component and a chroma component, and the current data unit includes a luma data unit and a chroma data unit; Splitting the luma data unit and the chroma data unit using a shared tree until the luma data unit and the chroma data unit reach a stop node; If the stop node is larger than MxN for the luma component, the stop node is encoded or decoded as a leaf coding unit, where M and N are positive integers; as well as If the stopping node is less than or equal to MxN for the chroma component, the prediction mode of the stopping node is sent or parsed.

Images