Managing coding tool combinations and limitations

Abstract

To provide a method and a device for coding or decoding, and compression or decompressing of a video that reaches a high compression efficiency.SOLUTION: In a method, an encoder inserts a construction into a vide bit stream, a decoder analyzes a bit stream, and a control is easily made for that which combination of tools are in valid, which combinations are not permitted, and which tools are activated against various components in a plurality of component bit streams, and a potential parallelization of a bit stream decoding is realized. A video code tool is controlled while containing the construction into the video bit stream. Thus, a video decoding resource can be more effectively utilized.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] At least one of the present embodiments generally relates to a method or apparatus for encoding or decoding, compressing or decompressing video. [Background technology]

[0002] To achieve high compression efficiency, image and video coding schemes typically employ prediction, including motion vector prediction, and transform to exploit spatial and temporal redundancy in video content. Generally, intra- or inter-prediction is used to exploit intra- or inter-frame correlation, and then the difference between the original and predicted image, often called the prediction error or prediction residual, is transformed, quantized, and entropy coded. To reconstruct the video, the compressed data is decoded by an inverse process corresponding to entropy coding, quantization, transformation, and prediction. Summary of the Invention

[0003] At least one of the present embodiments relates generally to a method or apparatus for video encoding or decoding, and more particularly to a method or apparatus for simplifying coding modes based on adjacent sample-dependent parametric models.

[0004] According to a first aspect, there is provided a method, comprising inserting into a video bitstream high-level syntax associated with at least one video coding tool, conditionally inserting into the bitstream one or more low-level controls for the one or more video coding tools based on the high-level syntax, activating one or more video coding tools corresponding to one or more video components based on the low-level controls, and encoding the video bitstream using the activated video coding tools.

[0005] According to a second aspect, there is provided a method, the method including parsing a video bitstream for a high-level syntax associated with at least one video coding tool, determining one or more low-level controls for the one or more video coding tools based on the high-level syntax, activating one or more video coding tools corresponding to one or more video components based on the determination, and decoding the video bitstream using the activated video coding tools.

[0006] According to another aspect, an apparatus is provided that includes a processor that can be configured to encode a block of video or decode a bitstream by performing any of the methods described above.

[0007] According to another general aspect of at least one embodiment, a device is provided that includes an apparatus according to any of the decoding embodiments and at least one of: (i) an antenna configured to receive a signal, the signal including the video block; (ii) a band limiter configured to limit the received signal to a frequency band including the video block; or (iii) a display configured to display an output representing the video block.

[0008] According to another general aspect of at least one embodiment, a non-transitory computer-readable medium is provided that includes data content generated in accordance with any of the described encoding embodiments or variations.

[0009] According to another general aspect of at least one embodiment, there is provided a signal including video data generated according to any of the described encoding embodiments or variations.

[0010] According to another general aspect of at least one embodiment, a bitstream is formatted to include data content generated according to any of the described encoding embodiments or variations.

[0011] According to another general aspect of at least one embodiment, a computer program product is provided that includes instructions that, when executed by a computer, cause the computer to perform any of the described decoding embodiments or variations.

[0012] These and other aspects, features and advantages of the general aspects will become apparent from the following detailed description of illustrative embodiments, which is to be read in connection with the accompanying drawings. [Brief explanation of the drawings]

[0013] [Figure 1] Indicates a standard, common video compression method. [Figure 2] This shows the standard, common video decompression method. [Figure 3] 1 illustrates a general decoding process according to one embodiment. [Figure 4] The general decoding process for Case 1 is shown below. [Figure 5] 1 shows the first proposed general decoding process for Case 2. [Figure 6] 2 shows the second proposed general decoding process for Case 2. [Figure 7] The general decoding process for Case 3 is shown below. [Figure 8] 1 illustrates an exemplary decoding process based on picture splitting restriction signaling. [Figure 9] 10 illustrates an alternative decoding process based on picture splitting restriction signaling. [Figure 10] 1 illustrates an exemplary decoding process based on multi-hypothesis prediction that enables flag signaling. [Figure 11] 1 illustrates an exemplary decoding process based on MTS (Multiple Transform Sets) that allows flag signaling. [Figure 12] 10 illustrates an exemplary alternative decoding process based on MTS that allows for flag signaling. [Figure 13] 10 illustrates an exemplary decoding process for dependent quantization and code data hiding that allows for flag signaling. [Figure 14] 1 illustrates the coding tree unit and coding tree concepts that represent a compressed HEVC picture. [Figure 15] 1 illustrates an example of dividing a coding tree unit into a coding unit, a prediction unit, and a transform unit. [Figure 16] 1 illustrates an exemplary quadtree plus binary tree (QTBT) CTU representation. [Figure 17] 1 illustrates a processor-based system for encoding / decoding under the general aspects described. [Figure 18] FIG. 2 shows a simplified block diagram of a decoding process according to a first embodiment. [Figure 19] 1 illustrates one embodiment of a method under the general aspects described. [Figure 20] 1 illustrates another embodiment of a method under the general aspects described. [Figure 21] 1 illustrates an exemplary device under the described aspects. DETAILED DESCRIPTION OF THE INVENTION

[0014]

[0001] The embodiments described herein are in the field of video compression and generally relate to video compression and video encoding and decoding. The general aspects described are aimed at providing a mechanism for manipulating restrictions in high-level video coding syntax or video coding semantics to constrain the set of possible tool combinations.

[0015] To achieve high compression efficiency, image and video coding schemes typically employ prediction, including motion vector prediction, and transform to exploit spatial and temporal redundancy in video content. Generally, intra- or inter-prediction is used to exploit intra- or inter-frame correlation, and then the difference between the original and predicted image, often called the prediction error or prediction residual, is transformed, quantized, and entropy coded. To reconstruct the video, the compressed data is decoded by an inverse process corresponding to entropy coding, quantization, transformation, and prediction.

[0016] In the HEVC (High Efficiency Video Coding, ISO / IEC 23008-2, ITU-TH.265) video compression standard, motion compensated temporal prediction is employed to exploit the redundancy that exists between successive pictures of a video.

[0017] To do so, a motion vector is associated with each prediction unit (PU). Each coding tree unit (CTU) is represented by a coding tree in the compressed domain, which is a quadtree decomposition of the CTU, where each leaf is called a coded unit (CU).

[0018] Each CU is then given some intra- or inter-prediction parameters (prediction information). To do this, it is spatially divided into one or more prediction units (PUs), and each PU is assigned some prediction information. An intra- or inter-coding mode is assigned at the CU level.

[0019] A new video compression standard, known as the Joint Exploration Model (JEM), proposed by the Joint Video Exploration Team (JVET), is proposed to adopt a quadtree-binary tree (QTBT) block partitioning structure due to its high compression performance. A binary tree (BT) block can be divided into two equal-sized sub-blocks by splitting it horizontally or vertically in the middle. As a result, BT blocks can have rectangular shapes with unequal width and height, unlike QT blocks, which are always square with the same height and width. In HEVC, the angular intra-prediction direction is defined from 45 degrees to -135 degrees across a 180-degree span and maintained within the JEM, allowing the definition of the angular direction to be independent of the shape of the target block.

[0020] To code these blocks, intra prediction is used to provide an estimated version of the block using previously reconstructed neighboring samples. The difference between the source block and the prediction is then coded. In the traditional codec mentioned above, a row of reference samples is used to the left and above the current block.

[0021] In HEVC (High Efficiency Video Coding, H.265), the encoding of frames of a video sequence is based on a quadtree (QT) block partitioning structure. A frame is divided into square coding tree units (CTUs), which are then further divided into multiple coding units (CUs) based on a rate-distortion (RD) criterion. Each CU can be intra-predicted, i.e., spatially predicted from causal neighboring CUs, or inter-predicted, i.e., temporally predicted from an already decoded reference frame. In I slices, all CUs are intra-predicted, while in P and B slices, CUs can be both intra-predicted and inter-predicted. For intra prediction, HEVC defines 35 prediction modes, including one planar mode (indexed as mode 0), one DC mode (indexed as mode 1), and 33 angular modes (indexed as modes 2 through 34). An angular mode is associated with a prediction direction ranging from 45 degrees to -135 degrees clockwise. HEVC supports a quadtree (QT) block partitioning structure, so all prediction units (PUs) are square. Therefore, the definition of prediction angles from 45 degrees to -135 degrees is justified in terms of PU (prediction unit) shape. For a target prediction unit of size NxN pixels, the top and left reference arrays are each of size 2N+1 samples, which is necessary to cover the aforementioned angle range for all target pixels. Given that the height and width of a PU are the same length, it also makes sense that the lengths of the two reference arrays are equal.

[0022] The present invention is in the field of video compression and aims to improve the dual prediction of inter-coded blocks compared to existing video compression systems. The present invention also proposes to separate the luma and chroma coding trees of inter-slices.

[0023] In the HEVC video compression standard, a picture is divided into so-called coding tree units (CTUs), whose size is typically 64x64, 128x128, or 256x256 pixels. Each CTU is represented by a coding tree in the compressed domain. This is a quadtree division of the CTU, where each leaf is called a coding unit (CU), see Figure 14.

[0024] Then, each CU is given some intra- or inter-prediction parameters (prediction information).To do this, it is spatially divided into one or more prediction units (PUs), and each PU is assigned some prediction information.The intra-coding mode or inter-coding mode is assigned at the CU level, see Figure 15.

[0025] Emerging video compression tools are proposed to include a coding tree unit representation in the compressed domain to represent picture data in a more flexible way in the compressed domain. The advantage of this more flexible coding tree representation is that it provides increased compression efficiency compared to the CU / PU / TU arrangement of the HEVC standard.

[0026] The quadtree plus binary tree (QTBT) coding tool provides this increased flexibility. It consists of a coding tree that can partition a coding unit in both a quadtree and binary tree manner. Such a coding tree representation of a coding tree unit is shown in Figure 16.

[0027] The partitioning of the coded units is determined at the encoder side by a rate-distortion optimization procedure, which consists of determining the QTBT representation of the CTU at the minimum rate-distortion cost.

[0028] In QTBT technology, the shape of a CU is square or rectangular. The size of a coding unit is always a power of 2, usually between 4 and 128.

[0029] In addition to this different rectangular shape of the coded unit, this new CTU representation has the following different properties compared to HEVC:

[0030] The QTBT decomposition of a CTU consists of two stages: first, the CTU is partitioned in a quadtree fashion, and then each quadtree leaf can be further partitioned in a binary tree fashion. This is shown on the right side of Figure 16, where the solid lines represent the quadtree decomposition phase and the dashed lines represent the binary decomposition spatially embedded in the quadtree leaves.

[0031] The general aspect described herein is the field of video compression. A video codec is a combination of multiple coding tools. A common approach is to standardize the decoder side (syntax and decoding process).

[0032] Contributions JVET-L0044, "AHG15: Proposed interoperability point syntax," and JVET-L0696, "Proposed starting point for interoperability point syntax," specify several high-level syntax elements (in the SPS or profile_tier_level part) intended to control the activation of coding tools in VVC decoders. The goal of this signaling mechanism is to enable bitstream interoperability points defined by parties other than MPEG or ITU, such as DVB, ATSC, or 3GPP. An example of the syntax is proposed in Table 1, which is inserted at the beginning of the SPS to indicate characteristics that must not be violated throughout the bitstream. JVET plans to extend this table for most coding tools added to the VVC specification. In principle, it is not JVET's responsibility to specify profiles or subprofiles based on these flags. JVET only defines the tools and their relationships to constraint flags / parameters. [Table 1]

[0033] If the constraint flag is set in an SPS (or similar) syntax construct, the decoder can safely assume that the tool is not used in the bitstream. If the constraint flag is set to 1, the tool may be activated in the associated bitstream.

[0034] Several contributions have also been proposed to specify similar signaling mechanisms, notably JVET-K0311, which provides an initial high-level tool signaling concept; JVET-L0042, which groups tools by category; and JVET-L0043, which proposes hierarchical signaling (which JVET considers may be too complex to analyze).

[0035] Since codecs have many coding tools, this results in a huge number of possible tool combinations, and current designs do not consider the impact of tool interactions. Also, in some cases, simply deactivating a tool may not work; some tools require a fallback mode. The present invention aims to address this issue by inserting a process that restricts the possible tool activation / deactivation at either the syntactic or semantic level.

[0036] As mentioned above, the approach taken by JVET to achieve high-level, granular control over coding tools leads to a vast number of tool combinations, some of which may be impractical in terms of coding efficiency or implementability.

[0037] Currently, the proposed syntax does not have any high-level tool combination restrictions. The main solutions offered in the prior art have been considered in the previous paragraph (contributions JVET-L0042 and JVET-L0043), but have not yet been considered in JVET.

[0038] In the described aspects, we propose to insert syntactic or semantic changes to specify tool combination restrictions, taking into account interaction issues that may arise when combining some tools while deactivating others.

[0039] Table 2 lists the tools included in VTM3 and some additional tools under investigation that could be added to VTM later. They are grouped by category. The estimated PSNR-YBD rate performance of the tools is provided. A negative number (-x) indicates an average bitrate saving of x%. Interdependencies with other tools are also shown.

[0040] Several SPSs can be signaled in the bitstream, which may include flags to control tools at the sequence or scalability level.

[0041] In addition to the SPS, a set of additional parameters at a lower level of the syntax can be specified (PPS, slice header, tile group header, tile header, etc.) which may contain additional flags to control tools at a level lower than the sequence level. In the following, syntax elements defined at the highest (SPS) level use the prefix "hl_". If the prefix "ll_" is used, this indicates that the syntax element is at a lower level than the SPS, for more local control of the tool. [Table 2-1] [Table 2-2]

[0042] From the analysis of the tool, the following characteristics are observed: -Case 1-Several tools are based on the same conceptual design, leading to their joint control. -Case 2 - Some tools are conditioned on other tools, either in terms of performance or in terms of technological dependency, which leads to controlling them based on the control of the conditioned tools. Case 3: Some are mutually exclusive and cannot be activated together. In the remainder of this document, the following definitions will be used: -Tools considered - This relates to the set of tools that will be controlled by the proposed process. -Main tools and dependent tools - If the tools under consideration are in the Case 2 category, they are divided into two sets: main tools and dependent tools, and the activation / deactivation of dependent tools depends on the activation / deactivation of main tools. - Exclusive Tools - If the tools under consideration are mutually exclusive (Case 3), they are grouped into "Exclusive Tools Set 1" and "Exclusive Tools Set 2", and when a tool from Set 1 is activated, a tool from Set 2 is deactivated, and vice versa. A general block diagram of the decoding process covering these three cases is provided in Figure 3. For simplicity, two tools are considered. This concept can be extended to three or more tools. The block diagram essentially consists of three branches, depending on the type of tool under consideration, which are checked in steps 901 and 902.

[0043] The branch corresponding to Case 1 consists of two main steps. In step 903, at least one high level syntax element HL_SE is decoded from the bitstream. In step 904, depending on the value of HL_SE, the low-level syntax element controlling the tool under consideration is: A given value is inferred, which usually results in the deactivation (or alternatively activation) of all the tools under consideration, Or decoded from the bitstream (allowing for independent control of each tool considered).

[0044] The branch corresponding to Case 3 consists of four main steps: In step 905, at least two high level syntax elements HL_SE1 and HL_SE2 relating to the control of exclusive tools 1 and 2 are decoded from the bitstream. In step 906, depending on the value of HL_SE1, at least one low-level syntax element LL_SE1 controlling exclusive tool 1 is Decoded from the bitstream, or o Or it is inferred to a given value and the exclusive tool 1 is normally deactivated. In step 907, depending on the values ​​of HL_SE2 and LL_SE1, at least one low-level syntax element LL_SE2 controlling exclusive tool 2 is Decoded from the bitstream, or o Or it is inferred to a given value and the exclusive tool 2 is normally deactivated.

[0045] Step 907 is as follows: 1) When exclusive tool 1 is enabled (from LL_SE1), the LL_SE2 value will disable exclusive tool 2, 2) When Exclusive Tool 1 is disabled (from LL_SE1), Exclusive Tool 2 can be enabled.

[0046] The branch corresponding to Case 2 consists of four main steps: In step 908, at least one high level syntax element HL_SE_main is decoded from the bitstream. In step 909, depending on the value of HL_SE_main, at least one high-level syntax element HL_SE_dependent that controls the dependent tool is Decoded from the bitstream, or Or it can be inferred to a given value, typically resulting in the dependent tool being deactivated.

[0047] In step 909, if the HL_SE_main value results in disabling the main tool, then the HL_SE_dependent value results in disabling the dependent tool. In step 910, depending on the value of HL_SE_main, at least one low-level syntax element LL_SE_main that controls the main tool is Decoded from the bitstream, or o Or it is inferred to a given value, which usually results in the main tool being deactivated. In step 911, depending on the values ​​of HL_SE_dependent and LL_SE_main, at least one low-level syntax element LL_SE_dependent that controls the dependent tool is Decoded from the bitstream, or Or it can be inferred to a given value, typically resulting in the dependent tool being deactivated.

[0048] In step 911, if HL_SE_dependent results in disabling the dependent tool, or if LL_SE_main results in disabling the main tool, then LL_SE_dependent results in disabling the dependent tool.

[0049] The final step 912 corresponds to the application of a decoder process, with the activation / deactivation of tools controlled by the low syntax elements derived from the previous steps.

[0050] The following sections correspond to various case embodiments of the considered tool.

[0051] General solution for Case 1 (Tools based on the same conceptual design) The solution for Case 1 is to define high-level syntax elements that control several tools. Additional low-level syntax elements related to the activation / deactivation of these tools are also defined. Depending on the values ​​of the high-level syntax elements, the additional low-level syntax elements are either set to given predefined values ​​or read from the bitstream. Then, a decoding process is performed, involving the activation or deactivation of these tools depending on the values ​​of the corresponding low-level syntax elements.

[0052] This process is summarized as follows (also shown in Figure 4): - Decode one high level syntax element high_level_SE from the bitstream (1001). - if high_level_SE is equal to a given value V1 (1002), Based on the value of high_level_SE, infer (1003) the low-level syntax elements (low_level_SE) related to tool activation / deactivation, - (1002) otherwise Decode from bitstream low_level_SE (1004). - Applying a decoding process (1005) with activation / deactivation of tools depending on the value of the low-level syntax element low_level_SE.

[0053] General solution for case 2 (tools that depend on other tools) The solution for Case 2 involves that the activation of some tools (we call them dependent tools) can be conditioned by the activation of other tools (we call them main tools).

[0054] As in Case 1, the tools can be controlled by a single high-level flag that controls the activation of both the main tool and the dependent tools. The low-level syntax elements of the dependent tools are then conditioned by the values ​​of the low-level syntax elements that control the main tool.

[0055] This process is summarized as follows (also shown in Figure 5): - Decode one high level syntax element high_level_SE from the bitstream (1101). If -high_level_SE is equal to a given value V1 (1102), Depending on the value of high_level_SE, infer the low-level syntax elements (low_level_main_SE and low_level_dependent_SE) related to the activation / deactivation of the main tool and dependent tools (1103). - Otherwise (1102), Decoding (1104) from the bitstream low level syntax elements (low_level_main_SE) related to the activation / deactivation of the main tool, If low_level_main_SE is equal to a given value V2 (1105), ● For the low-level syntax element low_level_main_SE related to the activation / deactivation of the main tool, depending on the value, infer the low-level syntax element (low_level_dependent_SE) related to the activation / deactivation of the dependent tool (1106); If not, (1105), ● Decode from the bitstream low level syntax elements (low_level_dependent_SE) related to activation / deactivation of dependent tools (1107). - Applying a decoding process (1108) with activation / deactivation of tools depending on the values ​​of the low-level syntax elements (low_level_main_SE and low_level_dependent_SE).

[0056] Alternatively, at least two high-level flags are used, one to control activation of the main tool and another to control activation of dependent tools, the second of which is conditioned by the value of the first flag.

[0057] This process is summarized as follows (also shown in Figure 6): - Decode one high level syntax element related to activation / deactivation of the main tool from the bitstream (1201). If the high-level syntax element related to the activation / deactivation of the main tool has a given value V1 (1202), Depending on the value of the high-level syntax element related to the activation / deactivation of the main tool, infer the high-level syntax element related to the activation / deactivation of the dependent tool (1203). - Otherwise (1202), Decode (1204) from the bitstream high level syntax elements related to activation / deactivation of dependent tools. - If the tool is a main or dependent tool (1205), the following applies: If a high-level syntax element has a given value V3 (which may be different for the main tool and the dependent tool) (1206), ● Depending on the value of the high-level syntax element, infer the low-level syntax element related to the activation / deactivation of the tool (1207); If not, (1206), • Decode (1208) from the bitstream low level syntax elements related to tool activation / deactivation. - Applying a decoding process (1209) with activation / deactivation of tools depending on the values ​​of low-level syntax elements.

[0058] General solution for Case 3 (mutually exclusive tools) The solution for Case 3 is to define at least one high-level syntax element that controls one first tool or one first toolset, and a parameter that controls one second tool or one second toolset that is mutually exclusive with the first tool or first toolset. This process is summarized as follows (also shown in Figure 7): - Decode 1301 from the bitstream two high level syntax elements high_level_SE1 and high_level_SE2 associated with one first toolset and one second toolset. If -high_level_SE1 is equal to a given value V1 (1302), Based on the value of high_level_SE1, infer the low-level syntax elements (low_level_SE1) associated with the first set of tool activation / deactivation (1303). - Otherwise (1302), o Decode low_level_SE1 from the bitstream (1304). - if high_level_SE2 is equal to a given value V2 and low_level_SE1 is equal to a given value V3 (1305), Based on the value of highLevelParam2, infer the low-level syntax elements (low_level_SE2) associated with the second set of tool activation / deactivation (1306). - Otherwise (1305), Decode low_level_SE2s from the bitstream (1307). - Applying a decoding process (1308) with activation / deactivation of tools depending on the values ​​of the low-level syntax elements low_level_SE1 and low_level_SE2.

[0059] Advantageously, the present invention allows to reduce the complexity of encoders and decoders by limiting the number of possible combinations of tools, and to reduce the risk of implementation problems due to the need to support tool combinations with the attendant additional complexity issues and additional cases of tool incompatibility, ultimately reducing interoperability problems that may arise due to too many possible tool combinations.

[0060] For these various cases, tool-specific embodiments are provided, as listed in Table 2 (the case is indicated in parentheses in the title of the embodiment).

[0061] Embodiment 1 - Coordinated control of division restrictions (Case 1) Main embodiment In one embodiment, the multiple partitioning restriction associated with partitioning (or coding structure) of a CTU or CU having at least one of the vertical or horizontal dimensions greater than a given restriction (typically 64) is controlled by one single high-level syntax element (e.g., hl_picture_partitioning_retrictions_flag) inserted in a high-level parameter set (e.g., SPS). [Table 3]

[0062] Furthermore, syntax elements related to specific partitioning restrictions are inserted into parameter sets at levels lower than the high-level parameter sets (eg, PPS, slice header, tile group header, tile header).

[0063] As an example, the specific splitting restrictions can be the following tools listed in Table 2: C_TT64, C_QT128, C_BT, which are controlled by the following low level flags, ll_split_tt128_restriction_flag, ll_split_qt128_restriction_flag, ll_split_bt128_restriction_flag, respectively.

[0064] As an example, the following specific syntax elements are inserted into the tile group header: [Table 4]

[0065] A simplified block diagram of the decoding process is shown in Figure 8. In step 301, the high-level partitioning restriction flag hl_picture_partitioning_retrictions_flag is decoded from the bitstream. Its value is checked in step 302. If hl_picture_partitioning_retrictions_flag is true, the specific low-level syntax element associated with the specific partitioning restriction is set to true (step 303). If the flag is false, the specific low-level syntax element associated with the specific partitioning restriction is decoded in step 304. In step 305, the decoding process for the CTU or CU is applied, using the specific partitioning restriction controlled by the low-level syntax element set in step 303 or decoded in step 304.

[0066] One example of the corresponding semantics is: If hl_picture_partitioning_retrictions_flag is 1, it specifies that the syntax elements ll_split_tt128_restriction_flag, ll_split_qt128_restriction_flag, and ll_split_bt128_restriction_flag are not present in the tile group header of the picture in CVS. If hl_picture_partitioning_retrictions_flag is 0, it specifies that the syntax elements ll_split_tt128_restriction_flag, ll_split_qt128_restriction_flag, and ll_split_bt128_restriction_flag are present in the tile group header of the picture in CVS.

[0067] If ll_split_tt128_restriction_flag is 1, it specifies that ternary tree splitting is disabled for CU sizes greater than 64x64. If ll_split_tt128_restriction_flag is 0, it specifies that ternary tree splitting is enabled for CU sizes greater than 64x64. If ll_split_tt128_restriction_flag is not present, it is set to 1.

[0068] If ll_split_qt128_restriction_flag is 1, it specifies that a CU of size 128x128 is forced to be split into four CUs of size 64x64. If ll_split_qt128_restriction_flag is 0, it specifies that a CU of size 128x128 is not forced to be split into four CUs of size 64x64. If ll_split_qt128_restriction_flag is not present, it is set to 1.

[0069] If ll_split_bt128_restriction_flag is 1, it specifies that a CU of size 64x128 is forced to be split into two CUs of size 64x64. If ll_split_bt128_restriction_flag is 0, it specifies that a CU of size 64x128 is not forced to be split into two CUs of size 64x64. If ll_split_bt128_restriction_flag is not present, it is set to 1.

[0070] Alternative 1 In the above solution, high level control of partitioning restrictions is advantageous for activating restrictions, since if hl_picture_partitioning_retrictions_flag is true, it implies that certain partitioning restriction flags are also set to true.

[0071] In the following embodiment, the approach is reversed: if hl_picture_partitioning_retrictions_flag is false, then the specific partition restriction flags are also set to false. Otherwise, these specific partition restriction flags are read from the bitstream. This is shown in Figure 9, where the condition on the value of the global flag hl_picture_partitioning_retrictions_flag is reversed compared to the above embodiment. In step 302a, it is checked whether hl_picture_partitioning_retrictiong_flag is false. If this condition is true, then in step 303a the specific low-level syntax elements related to the specific partition restrictions are set to false. The other steps are identical to the previous embodiment.

[0072] Embodiment 2 In one embodiment, as described below, multiple high-level partitioning restriction flags (N) are present in the syntax, and semantics allow for sequential control of them. In this example, the flags are collectively referred to as "hl_picture_partitioning_restrictionk_flag," where k is an integer value. Lower-level flags are also inserted additionally at lower levels of the syntax, e.g., at tile group headers named "ll_picture_partitioning_restrictionk_kk_flag," where k is an integer value. For a given restriction k, the high-level flag "hl_picture_partitioning_restrictionk_flag" controls Mk lower-level restrictions controlled by the flag "ll_picture_partitioning_restrictionk_kk_flag," where k runs from 1 to Mk. [Table 5]

[0073] One example of the corresponding semantics is as follows: If hl_picture_partitioning_restrictionk_flag is 1, it specifies that the syntax elements ll_picture_partitioning_restrictionka_flag and ll_picture_partitioning_restrictionkb_flag are not present in the tile group header of the CVS picture. If hl_picture_partitioning_restriction1_flag is 0, it specifies that the syntax elements ll_picture_partitioning_restriction1a_flag and ll_picture_partitioning_restriction1b_flag are present in the tile group header of the CVS picture.

[0074] In this embodiment, the same semantics apply to hl_picture_partitioning_restrictionk_flag for any k from 1 to N.

[0075] Specifies that picture partitioning restriction kx is enabled if ll_picture_partitioning_restrictionkx_flag is 1. Specifies that picture partitioning restriction kx is disabled if ll_picture_partitioning_restrictionkx_flag is 0. If ll_picture_partitioning_restrictionkx_flag is not present, it is set to 1.

[0076] In this embodiment, the same semantics apply to ll_picture_partitioning_restrictionkx_flag for any kk from 1 to Mk.

[0077] This may relate more specifically to the splitting restrictions identified in Table 2 as C_TT64, C_QT128, and C_BT.

[0078] Embodiment 3 - Collaborative control of other tools related to division (Case 1) The same approach can be applied to the following segmentation-related tools listed in Table 2: C_PR, C_FBP.

[0079] The detailed syntax and semantics can be seen above.

[0080] Embodiment 4 - Control of a multi-hypothesis forecasting tool (Case 1) Main embodiment In one embodiment, the multi-hypothesis prediction-based inter-prediction tool is controlled by one high-level single syntax element (e.g., hl_multi_hypothesis_enable_flag) inserted into a high-level parameter set (e.g., SPS). In this document, the multi-hypothesis prediction tool involves weighted mixing of samples obtained from several predictions with spatially varying weights. [Table 6]

[0081] Furthermore, syntax elements related to specific multi-hypothesis prediction tools are inserted in parameter sets at lower levels than the high-level parameter sets (eg, PPS, slice header, tile group header, tile header).

[0082] As an example, the specific multi-hypothesis prediction tools may be the following tools listed in Table 2: R_GBI, R_TRI, and R_MH, controlled by the following low-level flags: ll_generalized_bipred_enable_flag, ll_triangular_partition_enable_flag, and ll_multi_hypothesis_intra_inter_enable_flag, respectively. Additionally, R_OBMC may also be included in this set of tools and may be controlled by a specific flag, e.g., ll_obmc_enable_flag.

[0083] As an example, the following specific syntax elements can be inserted into the tile group header: [Table 7]

[0084] A simplified block diagram of the decoding process is shown in Figure 10. In step 401, the flag hl_multi_hypothesis_enable_flag is decoded from the bitstream. Its value is checked in step 402. If the flag is true, a specific syntax element associated with a specific multi-hypothesis prediction tool is set to true (step 403). If hl_multi_hypothesis_enable_flag is true, a specific low-level syntax element associated with a specific multi-hypothesis prediction tool is decoded in step 404. In step 405, the decoding process for the CTU or CU is applied using the specific multi-hypothesis prediction tool controlled by the low-level syntax element set in step 403 or decoded in step 404.

[0085] One example of the corresponding semantics is as follows: If hl_multi_hypothesis_enable_flag is 1, it specifies that the syntax elements ll_generalized_bipred_enable_flag, ll_triangular_partition_enable_flag, ll_multi_hypothesis_intra_inter_enable_flag, and ll_obmc_enable_flag are present in the tile group header of the picture in CVS. If hl_multi_hypothesis_enable_flag is 0, it specifies that the syntax elements ll_generalized_bipred_enable_flag, ll_triangular_partition_enable_flag, ll_multi_hypothesis_intra_inter_enable_flag, and ll_obmc_enable_flag are not present in the tile group header of the picture in CVS.

[0086] ll_generalized_bipred_enable_flag specifies that the generalized bi-prediction mode is enabled if it is 1. Specifies that the generalized bi-prediction mode is disabled if it is 0. If ll_generalized_bipred_enable_flag is not present, it is set to 0. Equivalent semantics apply to the syntax elements ll_triangular_partition_enable_flag, ll_multi_hypothesis_intra_inter_enable_flag, and ll_obmc_enable_flag.

[0087] alternative As in the previous section, in an alternative solution, there are flags in the syntax that enable multiple high-level multi-hypothesis predictions, and the semantics allow them to be controlled together. The detailed syntax and semantics can be followed as in the previous section.

[0088] Embodiment 5 - Intra and Inter Control of MTS (Case 2) In one embodiment, one or two flags are inserted at a high level to control the activation of MTS (Multiple Transform Sets), which are related to the following tools listed in Table 2: T_MTS_intra, T_MTS_inter. In some cases, T_ST can also be controlled by the same mechanism.

[0089] Solution 1 In the first embodiment, one single high-level flag, hl_mts_enable_flag, is added as shown in the table below. [Table 8]

[0090] Depending on the value of the flag hl_mts_enable_flag, one or two additional flags are inserted at the low level to control MTS activation for intra or inter regions such as slices, tile groups, tiles, etc., as shown in the table below. [Table 9]

[0091] The decoding process is conceptually similar to the process described for controlling a multi-hypothesis prediction tool.

[0092] The corresponding semantics are proposed.

[0093] If hl_mts_enable_flag is 1, it specifies that the syntax elements ll_mts_intra_enable_flag and ll_mts_inter_enable_flag are present in the tile group header of the picture in CVS. If hl_mts_enable_flag is 0, it specifies that the syntax elements ll_mts_intra_enable_flag and ll_mts_inter_enable_flag are not present in the tile group header of the picture in CVS.

[0094] If ll_mts_intra_enable_flag is 1, it specifies that the multiple transform set mode is enabled for CUs coded in intra mode. If ll_mts_intra_enable_flag is 0, it specifies that the multiple transform set mode is disabled for CUs coded in intra mode. If ll_mts_intra_enable_flag is not present, it is set to 0.

[0095] If ll_mts_inter_enable_flag is 1, it specifies that the multiple transform set mode is enabled for CUs coded in inter mode. If ll_mts_inter_enable_flag is 0, it specifies that the multiple transform set mode is disabled for CUs coded in inter mode. If ll_mts_inter_enable_flag is not present, it is set to 0.

[0096] Solution 2 The second embodiment is based on the first embodiment. In addition, the low-level flag that controls the activation of the inter MTS is conditioned on the activation of the intra MTS. This can be expressed as follows: [Table 10]

[0097] Alternatively, similar behavior can be achieved with two high-level flags, as shown in the table below. [Table 11]

[0098] One example of the corresponding semantics is as follows:

[0099] If hl_mts_intra_enable_flag is 1, it specifies that the syntax element ll_mts_intra_enable_flag is present in the tile group header of the picture in CVS. If hl_mts_intra_enable_flag is 0, it specifies that the syntax element ll_mts_intra_enable_flag is not present in the tile group header of the picture in CVS.

[0100] If hl_mts_inter_enable_flag is 1, it specifies that the syntax element ll_mts_inter_enable_flag is present in the tile group header of the CVS image. If hl_mts_inter_enable_flag is 0, it specifies that the syntax element ll_mts_inter_enable_flag is not present in the tile group header of the CVS image. If hl_mts_inter_enable_flag is not present, it is set to 0.

[0101] If ll_mts_intra_enable_flag is 1, it specifies that the multiple transform set mode is enabled for CUs coded in intra mode. If ll_mts_intra_enable_flag is 0, it specifies that the multiple transform set mode is disabled for CUs coded in intra mode. If ll_mts_intra_enable_flag is not present, it is set to 0.

[0102] If ll_mts_inter_enable_flag is 1, it specifies that the multiple transform set mode is enabled for CUs coded in inter mode. If ll_mts_inter_enable_flag is 0, it specifies that the multiple transform set mode is disabled for CUs coded in inter mode. If ll_mts_inter_enable_flag is not present, it is set to 0.

[0103] A block diagram of the corresponding decoding process is shown in FIG.

[0104] Secondary transformation activation dependent on MTS activation In one embodiment, activation of the secondary transformation mode (T_ST) is conditioned by activation of the MTS mode, which can be expressed as: [Table 12]

[0105] Similarly, activation of the recursive transformation tree mode (T_RTT) is conditioned by activation of the MTS mode.

[0106] Embodiment 6 - Control of A_MDLM based on A_CCLM activation (Case 2) In one embodiment, the mechanism described for the MTS case is applied to the case of tools A_CCLM and A_MDLM listed in Table 2, where activation / deactivation of A_MDLM is conditioned on activation / deactivation of A_CCLM. The detailed syntax and semantics can be seen above.

[0107] Embodiment 7 - Control of ATMVP based on ATMVP activation (Case 2) In one embodiment, the mechanism described for the MTS case is applied to the case of tools R_TMVP and R_ATMVP listed in Table 2, where activation / deactivation of R_ATMVP is conditioned on activation / deactivation of R_TMVP. The detailed syntax and semantics can be done as above.

[0108] Embodiment 8 - Inter-tool control based on high precision MV coded activation (Case 2) In one embodiment, activation / deactivation of R_AFF is conditioned on activation / deactivation of R_HPMV, and the implementation is similar to that described for the MTS case.

[0109] The detailed syntax and semantics can be seen above.

[0110] In another embodiment, the activation / deactivation of R_MMVD, R_DMVR is conditioned on the activation / deactivation of R_HPMV, and the implementation is similar to that described for the MTS case.

[0111] The detailed syntax and semantics can be seen above.

[0112] In another embodiment, the activation / deactivation of R_PAMC is conditioned on the activation / deactivation of R_HPMV, and the implementation is similar to that described for the MTS case. The detailed syntax and semantics can be as described above.

[0113] Embodiment 9 - Palette Mode and Current Picture Reference Dependency on Separate Luma / Chroma Tree Activation (Case 2) It turns out that palette modes benefit greatly from activating the use of separate luma / chroma trees.

[0114] In one embodiment, the activation / deactivation of A_PM and A_CPR is conditioned on the activation / deactivation of C_CST, and the implementation is similar to that described for the MTS case. The detailed syntax and semantics can be as described above.

[0115] Embodiment 10 - Mutual Control of Dependent Quantization and Sign Data Hiding Tools (Case 3) It has proven difficult to make tool-dependent quantization (Q_DQ) and code data hiding (C_SDH) work together.

[0116] In one embodiment, the high-level syntax controls for Q_DQ and C_SDH are designed to prevent the mutual use of these two tools.

[0117] Two high-level flags are added: hl_dependent_quant_enable_flag and hl_sign_data_hiding_flag, as shown in the table below. [Table 13]

[0118] The low-level activation syntax elements associated with the two tools are then set based on the values ​​of hl_dependent_quant_enable_flag and hl_sign_data_hiding_flag, except that one of the flags controlling a given tool is read only if the other flag indicates that the other tool is deactivated. This is shown in the table below. [Table 14]

[0119] One example of the corresponding semantics is:

[0120] If hl_dependent_quant_enable_flag is 1, it specifies that the syntax element ll_dependent_quant_enable_flag is present in the tile group header of the picture in CVS. If hl_dependent_quant_enable_flag is 0, it specifies that the syntax element ll_dependent_quant_enable_flag is not present in the tile group header of the picture in CVS.

[0121] Similar semantics are used for hl_sign_data_hiding_flag.

[0122] ll_dependent_quant_enable_flag specifies that dependent quantization mode is enabled if it is 1. Specifies that dependent quantization mode is disabled if it is 0. If ll_dependent_quant_enable_flag is not present, it is set to 0.

[0123] Specifies that sign data hiding mode is enabled if ll_sign_data_hiding_enable_flag is 1. Specifies that sign data hiding mode is disabled if ll_sign_data_hiding_enable_flag is 0. If ll_sign_data_hiding_enable_flag is not present, it is set to 0.

[0124] A simplified block diagram of the decoding process is shown in FIG.

[0125] Embodiment 11 - Mutual control of separate luma / chroma trees and cross-component linear models / multi-directional LM tools (Case 3) In one embodiment, the high-level syntactic control of C_CST, A_CCLM, and A_DMLM is such that activation of C_CST requires deactivation of A_CCLM and A_DMLM, and conversely, deactivation of C_CST requires activation of A_CCLM and A_DMLM. A similar design to that described in the above subsection can be used. The detailed syntax and semantics can be seen above.

[0126] Tool Classification Summary In this section, we summarize the classification of tools among the three cases considered. Case 1 o C_TT64, C_QT128, and C_BT can be grouped into one single flag related to the segmentation constraint to accommodate segmented VPDUs. C_PR and C_FBP can be grouped together as tools related to split control. R_GBI, R_TRI, and R_MH can be grouped as tools based on the same multi-hypothesis concept by weighting samples obtained from two predictions, and logically should be activated / deactivated together. R_OBMC can also be conceptually considered to be in the same set as multi-hypothesis by weighting samples. Case 2 o A_CCLM being deactivated implies that A_MDLM is also deactivated. o R_TMVP being deactivated implies that R_ATMVP is also deactivated. o T_MTS_intra being deactivated means T_MTS_inter being deactivated. o Since the performance of T_RTT may depend on T_MTS, deactivating T_MTS means that T_RTT is also deactivated. Disabling R_HPMV may affect the coding efficiency of R_AFF, R_MMVD, R_DMVR, and R_PAMC, so deactivating it means that some or all of the tools R_AFF, R_MMVD, R_DMVR, and R_PAMC are also deactivated. C_CST can have a strong impact on A_PM for screen content, as palette modes lend themselves to many uses of separate luma / chroma trees, so deactivating it means A_PM is also deactivated. o Deactivation of C_CST means deactivation of A_CPR. 〇 Case 3 o If C_SDH is activated, Q_DQ should be deactivated and vice versa. If A_CCLM and A_MDLM are activated, C_CST should be deactivated and vice versa.

[0127] The described aspects and embodiments can provide coding gain, i.e. increased quality for the same bit rate or reduced bit rate for the same quality, and can greatly facilitate the implementation of codecs by limiting the possible combinations of tools, which is an essential point for interoperability.

[0128] Another aspect of tool combinations relates to the syntax of multi-component video. One of the issues that arises with the new tools in VVC is that some of these tools may interact in a way that adversely affects performance, or may simply not be properly designed to work together when applied to individual components of a multi-component picture. A common example is the way chroma separation trees are processed. In a typical approach, a coded picture may contain a luma component (e.g., Y') and two chroma components (usually Cb, Cr) or three components (e.g., R, G, B). In the case of separate CU trees, the luma component and the two chroma components are coded independently. When dealing with multiple components coded separately in this way, the possible relationships between the components are undefined. [Table 15]

[0129] The advantage of coding independent (separate) components in the same bitstream is that the GOP structure of all components is the same, i.e., the reference frames, IDR frames, etc. Another advantage is parallelization (component-level encoding and decoding pipes).

[0130] The general aspects described below are aimed at setting up tool interactions between components in a multi-channel format.

[0131] The syntax and behavior between coded components needs to be created for the candidate tools proposed in VVC, which introduces dependencies between components.

[0132] This issue has not yet been addressed in JVET when multi-channel formats are employed. Note that the same issue must be addressed for RGB formats or other image formats (such as image + depth or auxiliary pictures) without using multi-channel formats.

[0133] The general aspects described below propose to provide a process for specifying the interaction of tools between channels. This can be done thanks to the introduction of syntactic changes and / or semantic changes. The invention describes several variants according to the relationships between the components.

[0134] List of tools to consider Table 2 lists the tools included in VTM3 and some additional tools under investigation that could be added to VTM later. These are grouped by category. [Table 16-1] [Table 16-2]

[0135] Several SPSs can be signaled in the bitstream. These can include flags to control tools at the sequence level.

[0136] In addition to the SPS, a set of additional parameters can be specified at a lower level in the syntax (PPS, slice header, tile group header, tile header, etc.) which may contain additional flags to control tools at a level lower than the sequence level.

[0137] Some terms and concepts that are useful in understanding the present invention are as follows: Components: Same definition as defined in the H.26x standard (e.g., Section 3.37 of HEVC, February 2018 version) Primary Component: A component on which a secondary component depends. Typically, a primary component does not depend on other components during the decoding process.

[0138] NOTE 1: The primary component may have dependencies on entropy coding (e.g., CABAC). Note 2: Typically, the primary component is the luma component of a video signal, which consists of a luma channel and two chroma channels. Secondary Component: A component that depends on a primary component during the decoding process.

[0139] NOTE 3: Typically, the secondary components are the luma and chroma channels of a two-channel video signal.

[0140] (Non) distinct components: Components that have a (non) dependent relationship during the decoding process.

[0141] Component Set: A group of non-distinct components.

[0142] NOTE 4: A component set typically includes non-distinct primary and secondary components.

[0143] NOTE 5: One example of two component sets is a first component set including Y' (primary component), Cb (secondary component), and Cr (secondary component) components, and a second component set including a mask (primary component) channel and a depth (secondary component) channel.

[0144] Note 6: Components are sometimes called "color planes."

[0145] Embodiment 12: Signaling and logic in the case of separate components In one embodiment, components are signaled as separate or non-separate components. Thanks to the analysis of the structure sps_active_tools_set, a method is applied to describe the state of activated tools related to the coding of separate or non-separate components.

[0146] One advantage of the described method is that some coding tools can be deactivated if they are known to be inefficient for a given component type (e.g., this can be constrained by a profile). An example of syntax is provided in the following table, with syntax changes highlighted in gray: [Table 17]

[0147] By design, if a non-primary component is not marked as separate, it is a secondary component (e.g., Y). The activated toolsets for the primary and secondary components are indicated by the first occurrence of sps_active_tools_set() as described above. A common example is a "Y'CbCr+depth" video signal, where the Y', Cb, and Cr components are non-separate components, but the depth component is a separate component.

[0148] A simplified block diagram of the decoding process according to this embodiment is shown in Figure 18. In step 1001, syntax elements related to tool activation are decoded. These are applied to at least the primary component. In step 1002, a loop is performed over the remaining components (indexed by i, greater than 1, with i = 0 corresponding to the primary component). In step 1003, a flag separate_cmp_flag[i] is decoded. The value of the flag is checked in step 1004. If the flag is true, step 1005 is applied. In step 1005, decoding of syntax elements related to tool activation of component i is performed. If the flag is false, the syntax elements related to tool activation decoded in step 1001 are applied to component i. The final step 1006 corresponds to the decoding process, involving tool activation or deactivation based on the decoded syntax elements, and possibly additional low-level syntax elements controlling tools at a level below the sequence level. [Table 18]

[0149] Note that the syntax elements shown in the table above can be indexed by a component index.

[0150] There are certain tools that involve inter-component dependencies, meaning that the decoding process of at least one component involves access to samples from other components. One example is the Cross-Component Linear Model (CCLM) tool, which is used to predict chroma samples from luma samples.

[0151] Embodiment 13: Signaling and logic for related components If some components are non-distinct, the corresponding high-level syntax elements (e.g., present in SPS, PPS, etc.) for controlling tool activation / deactivation may be grouped into only one set.

[0152] The primary and secondary components have dependencies during the decoding process. For example, In the case of inter-slice or inter-CTU, all components are considered as non-distinct (e.g., motion compensation is signaled and performed during the same stage for all components).

[0153] -For intra slices, components are considered non-distinct if C_CST (Chroma Separation Tree) or any other inter-component tool is disabled, or components are considered distinct if C_CST or any other inter-component tool is enabled (still with some relationship from Y component to UV component). This is especially true for tools that use prediction of chroma data derived from co-located luma data.

[0154] To describe these relationships, the following syntax is proposed: [Table 19]

[0155] If the value primary_cmp_id_plus1[i] is 0, the component at index i is considered the primary component. By default, the first component (index 0) is the primary component. A non-zero value indicates the primary component used by this secondary component. Syntax elements signaling the activation state of the coding tools for a component are stored in sps_active_tools_set(). Tools related to inter-component relationships are parsed using decode_inter_components_tools_flags(i), if necessary.

[0156] A common example is the YUV format, where Y is the primary component and UV is the secondary component.

[0157] number_of_components_group_minus[i] specifies the number of components in the component set to which primary component i belongs. If the group of related components has more than one component, the inter-component tool related flag is decoded.

[0158] For example, for a 4:2:0 (non-discrete) YUV format, the following values ​​are obtained for the syntax elements considered: [Table 20]

[0159] Another example of values ​​for a multi-channel bitstream including YUV+Depth is shown below. [Table 21]

[0160] An example of the decode_inter_components_tools_flags syntax is shown in the following table. [Table 22]

[0161] The flags in decode_inter_components_tools_flags enable or disable the mode that utilizes data from the primary component.

[0162] For example, lm_chroma_mode allows predicting components from primary components using CCLM tools. The flag separate_chrome_tree allows having a separate tree in the intraslice to code the current component. If the flag separate_chrome_tree is true, all components other than the main component are considered grouped (i.e., share the same tree). Otherwise, secondary components use the same signaling as the primary component.

[0163] Additional Secondary Component Syntax [Table 23]

[0164] In a variant, the syntax listed in Table 4 is added to the syntax.

[0165] The first flag, CABAC_dependency, signals if the primary and secondary components share some dependency during the CABAC entropy decoding process, otherwise it means that the entire primary component can be parsed independently from the secondary component.

[0166] The flag chroma_separate_tree_inter signals if the inter slice / CTU uses a separate tree similar to the chroma_separate_tree currently used for the intra slice / CTU. If this flag is true, an additional flag inter_direct_mode indicates whether the secondary component can derive some inter data (usually collocated motion information) from the primary component.

[0167] The flag reduce_tools_set_chrome indicates whether the secondary component uses a reduced toolset, which in the current version includes, for example: - Fewer intra-directions - Fewer possible conversion types (MTS) - etc.

[0168] Embodiment 14: Finer control of secondary component tools Within a component set, the relationship between component and tool state may need to be described more precisely and / or may be component dependent. In this case, an additional flag, separate_tools_flag, assigned to each secondary component is read. This flag indicates whether a particular tool control syntax element has been inserted in this secondary component. If the flag is true, the tool enable / disable flags are parsed for this secondary component (using a call to decode_tools_flags()).

[0169] The relevant syntax is shown below: [Table 24] In this case, the secondary components are grouped together and share the same flag in the inter-component tool.

[0170] Secondary Component Relationships A more general approach is to fully describe the inter-component relationships of a tool. The advantage of this is that it allows having a group of non-distinct components, where the state (activation / deactivation) of both regular (non-inter-component) tools and inter-component tools is customized per component. An example of the relevant syntax is shown below: [Table 25]

[0171] In this variant, the decoding of component 0 parameters is placed inside the component loop for simplicity.

[0172] For a given component, if separate_tools_flag is true, then the inter-component tool syntax elements specific to the component are decoded (call decode_inter_components_tools_flags_2(i)). Additionally, if the flag custom_decode_flag is true, it is possible to have specific syntax elements that control the non-inter-component tools of this component.

[0173] The decode_inter_components_tools_flags_2 flag is implemented as follows: [Table 26]

[0174] In the case of separate components, when an intertool component is activated, the component it inherits from is read in the bitstream (syntax element component_to_inherit_from). Component inheritance means: If -chroma_separate_tree is false, the component's tree is shared with the component specified by component_to_inherit_from. -For other tools (CPR, LM, etc.), if the flag associated with the mode is true, the data (motion vector predictor, pixel samples, etc.) is inherited from the component specified by component_to_inherit_from.

[0175] Inter-component tools is set to true if separate_tools_flag is false, unless separatechroma_separate_tree is set to false.

[0176] To determine if a component can customize each tool individually, an additional flag for customizing non-intercomponent tools is read. If the flag is false, the flag of the associated main component is used.

[0177] The present invention allows for an accurate description of the relationships between components of the same temporal data, and therefore can provide coding gain, i.e., increased quality for the same bit rate, or reduced bit rate for the same quality.

[0178] One embodiment of a method 1900 under general aspects described herein is shown in Figure 19. The method begins at start block 1901, with control passing to block 1910, which inserts syntax associated with at least one coding tool into a video bitstream. Control passes from block 1910 to block 1920, which conditionally inserts one or more controls for the coding tool into the bitstream based on the high-level syntax inserted into the bitstream. Control passes from block 1920 to block 1930, which activates one or more coding tools corresponding to the video component based on the one or more controls. Control passes from block 1930 to block 1940, which encodes the video bitstream using the activated coding tools.

[0179] One embodiment of a method 2000 under general aspects described herein is shown in Figure 20. The method begins at start block 2001, where control passes to block 2010, where a video bitstream is parsed for syntax associated with at least one video coding tool. Control passes from block 2010 to block 2020, where one or more controls of the coding tools are determined based on the video bitstream syntax. Control passes from block 2020 to block 2030, where one or more coding tools corresponding to the video component are activated based on the control determination. Control passes from block 2030 to block 2040, where the activated coding tools are used to decode the video bitstream.

[0180] 21 illustrates an embodiment of an apparatus 2100 for encoding, decoding, compressing, or decompressing video data using a simplified coding mode based on a parametric model of adjacent sample dependency. The apparatus comprises a processor 2110 and may be interconnected to a memory 2120 via at least one port. Both the processor 2110 and the memory 2120 may have one or more additional interconnections to external connections.

[0181] The processor 2110 is configured to insert or receive information into the bitstream and compress, encode, or decode using any of the described aspects.

[0182] This application describes various aspects, including tools, features, embodiments, models, approaches, and the like. Many of these aspects are described for the purpose of specificity, or at least individual characteristics, and are often described in a manner that may sound limiting. However, this is for clarity of description and does not limit the applicability or scope of these aspects. In fact, all of the various aspects can be combined or interchanged to provide additional aspects. Additionally, these aspects can also be combined or interchanged with aspects described in previous applications.

[0183] Aspects described and contemplated in this application can be implemented in many different forms. While Figures 1, 2, and 17 provide some embodiments, other embodiments are contemplated, and discussion of Figures 1, 2, and 17 does not limit the scope of implementations. At least one of these aspects generally relates to video encoding and decoding, and at least one other aspect generally relates to transmitting a generated or encoded bitstream. These and other aspects can be implemented as a method, an apparatus, a computer-readable storage medium having stored thereon instructions for encoding or decoding video data according to any of the described methods, and / or a computer-readable storage medium having stored thereon a bitstream generated according to any of the described methods.

[0184] In this application, the terms "reconstructed" and "decoded" may be used interchangeably, the terms "pixel" and "sample" may be used interchangeably, and the terms "image," "picture," and "frame" may be used interchangeably. Typically, but not necessarily, the term "reconstructed" is used on the encoder side while "decoded" is used on the decoder side.

[0185] Various methods are described herein, each of which includes one or more steps or actions for achieving the described method. Unless a specific order of steps or actions is required for the correct operation of the method, the order and / or use of specific steps and / or actions may be varied or combined.

[0186] Various methods and other aspects described in this application can be used to modify modules of video encoder 100 and decoder 200, e.g., intra-prediction, entropy coding, and / or decoding modules (160, 360, 145, 330), as shown in Figures 1 and 2. Furthermore, the aspects are not limited to VVC or HEVC, but can be applied, for example, to other standards and recommendations, whether existing or developed in the future, and extensions of any such standards and recommendations (including VVC and HEVC). Unless otherwise indicated or technically excluded, the aspects described in this application can be used individually or in combination.

[0187] Various numerical values ​​are used in this application. The particular values ​​are for illustrative purposes and the described aspects are not limited to these particular values.

[0188] 1 shows an encoder 100. Although variations of this encoder 100 are contemplated, the encoder 100 is described below for clarity without describing all possible variations.

[0189] Before being encoded, the video sequence may undergo a pre-encoding process (101), such as applying a color transformation to the input color picture (e.g., from RGB 4:4:4 to YCbCr 4:2:0) or performing a remapping of the input picture components to obtain a signal distribution that is more resilient to compression (e.g., using histogram equalization of one of the color components). Metadata associated with the pre-processing can be attached to the bitstream.

[0190] In encoder 100, a picture is coded by encoder elements as described below. The picture to be coded is divided (102) and processed, for example, in units of CUs. Each unit is coded, for example, using either intra mode or inter mode. When a unit is coded in intra mode, intra prediction is performed (160). In inter mode, motion estimation (175) and motion compensation (170) are performed. The encoder determines (105) whether intra mode or inter mode is used to code the unit, and indicates the intra / inter decision, for example, by a prediction mode flag. A prediction residual is calculated, for example, by subtracting (110) the predicted block from the original image block.

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

[0192] The encoder decodes the coded block to provide a reference for further prediction. The quantized transform coefficients are dequantized (140) and inverse transformed (150), and the prediction residual is decoded. The decoded prediction residual is combined (155) with the predicted block to reconstruct an image block. An in-loop filter (165) is applied to the reconstructed picture, for example, to perform deblocking / sample adaptive offset (SAO) filtering to reduce coding artifacts. The filtered image is stored in a reference picture buffer (180).

[0193] Figure 2 shows a block diagram of a video decoder 200. In the decoder 200, the bitstream is decoded by decoder elements as described below. The video decoder 200 generally performs a decoding pass that is the inverse of the encoding pass, as described in Figure 1. The encoder 100 also generally performs video decoding as part of encoding the video data.

[0194] In particular, the decoder's input includes a video bitstream, such as may be generated by video encoder 100. First, the bitstream is entropy decoded (230) to obtain transform coefficients, motion vectors, and other coded information. Picture partition information indicates how the picture is divided. Thus, the decoder can partition the picture according to the decoded picture partition information (235). The transform coefficients are dequantized (240) and inverse transformed (250), and the prediction residual is decoded. The decoded prediction residual is combined with a predicted block (255) to reconstruct an image block. The predicted block may be obtained from intra prediction (260) or motion-compensated prediction (i.e., inter prediction) (275) (270). An in-loop filter (265) is applied to the reconstructed image. The filtered image is stored in a reference picture buffer (280).

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

[0196] FIG. 17 shows a block diagram of an example system in which various aspects and embodiments may be implemented. System 1000 may be embodied as a device including various components described below and configured to perform one or more of the aspects described herein. Examples of such devices include, but are not limited to, various electronic devices, such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers. The elements of system 1000, either singly or in combination, may be embodied in a single integrated circuit, multiple ICs, and / or separate components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 1000 are distributed across multiple ICs and / or separate components. In various embodiments, system 1000 is communicatively coupled to one or more other systems or other electronic devices, for example, via a communication bus or through dedicated input and / or output ports. In various embodiments, system 1000 is configured to implement one or more of the aspects described herein.

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

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

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

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

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

[0202] In various embodiments, the input devices of block 1130 have associated respective input processing elements as known in the art. For example, the RF section may be associated with elements suitable for (i) selecting a desired frequency (also referred to as selecting a signal or band-limiting a signal to a frequency band), (ii) downconverting the selected signal, (iii) band-limiting again to a narrower frequency band to select a signal frequency band, which in certain embodiments may be referred to as a channel (for example), (iv) demodulating the downconverted, band-limited signal, (v) performing error correction, and (vi) demultiplexing to select a desired data packet stream. The RF section of various embodiments includes one or more elements that perform these functions, e.g., a frequency selector, a signal selector, a band limiter, a channel selector, a filter, a downconverter, a demodulator, an error corrector, and a demultiplexer. The RF section may include, for example, a tuner that performs a variety of these functions, including downconverting a received signal to a lower frequency (e.g., an intermediate frequency or a frequency near baseband) or to baseband. In one set-top box embodiment, the RF section and its associated input processing elements perform frequency selection by receiving, filtering, downconverting, and filtering again to the desired frequency band an RF signal transmitted over a wired (e.g., cable) medium. In various embodiments, the order of the above (and other) elements is rearranged, some of these elements are removed, and / or other elements that perform similar or different functions are added. Adding elements may include inserting elements between existing elements, such as inserting amplifiers and analog-to-digital converters. In various embodiments, the RF section includes an antenna.

[0203] Additionally, the USB and / or HDMI terminals may include respective interface processors for connecting system 1000 to other electronic devices over USB and / or HDMI connections. It should be understood that various aspects of the input processing, e.g., Reed-Solomon error correction, may be implemented, for example, within a separate input processing IC or within processor 1010, as desired. Similarly, aspects of the USB or HDMI interface processing may be implemented, as desired, within a separate interface IC or within processor 1010. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 1010 and an encoder / decoder 1030, which operates in combination with memory and storage elements to process the data stream as desired for display on an output device.

[0204] The various elements of system 1000 may be provided within an integrated housing in which the various elements are interconnected and capable of transmitting data therebetween using suitable connection configurations, e.g., internal buses as are known in the art, including the Inter-IC (I2C) bus, wiring, and printed circuit boards.

[0205] The system 1000 includes a communication interface 1050 that enables communication with other devices over a communication channel 1060. The communication interface 1050 may include, but is not limited to, a transceiver configured to transmit and receive data over the communication channel 1060. The communication interface 1050 may include, but is not limited to, a modem or a network card, and the communication channel 1060 may be implemented in a wired and / or wireless medium, for example.

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

[0207] System 1000 can provide output signals to various output devices, including a display 1100, speakers 1110, and other peripheral devices 1120. Display 1100 in various embodiments includes, for example, one or more of a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. Display 1100 may be for a television, a tablet, a laptop, a mobile phone, or other device. Display 1100 may also be integrated with other components (e.g., as in a smartphone) or may be separate (e.g., an external monitor for a laptop). Other peripheral devices 1120, in various example embodiments, include one or more of a standalone digital video disc (or digital versatile disc) (both terms DVR), a disc player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices 1120 that provide functionality based on the output of system 1000. For example, a disc player performs the function of playing the output of system 1000.

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

[0209] Alternatively, display 1100 and speakers 1110 may be separate from one or more of the other components, for example, if the RF portion of input 1130 is part of a separate set-top box. In various embodiments in which display 1100 and speakers 1110 are external components, the output signal may be provided via a dedicated output connection including, for example, an HDMI port, a USB port, or a COMP output.

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

[0211] Various implementations involve decoding. As used herein, "decoding" can encompass all or some of the processes performed on a received encoded sequence to generate a final output suitable for display, for example. In various embodiments, such processes include one or more of the processes typically performed by a decoder, such as entropy decoding, inverse quantization, inverse transform, and differential decoding. In various embodiments, such processes also or alternatively include processes performed by decoders in various implementations described herein.

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

[0213] Various implementations involve encoding. In a manner similar to the above discussion of "decoding," "encoding," as used herein, can encompass all or part of the processes performed on an input video sequence to, for example, generate an encoded bitstream. In various embodiments, such processes include one or more processes typically performed by an encoder, such as segmentation, differential encoding, transform, quantization, and entropy coding. In various embodiments, such processes also, or alternatively, include processes performed by the encoders of the various implementations described herein.

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

[0215] It should be noted that the syntax elements used herein are descriptive terms, and therefore they do not preclude the use of other syntax element names.

[0216] Where a figure is presented as a flow diagram, it should be understood that it also provides a block diagram of the corresponding apparatus. Similarly, where a figure is presented as a block diagram, it should be understood that it also provides a flow diagram of the corresponding method / process.

[0217] Various embodiments may refer to parametric models or rate-distortion optimization. In particular, during the encoding process, a balance or trade-off between rate and distortion is typically considered, often given computational complexity constraints. This may be measured through a rate-distortion optimization (RDO) metric or through least mean squares (LMS), mean absolute error (MAE), or other such measures. Rate-distortion optimization is typically formulated as minimizing a rate-distortion function, which is a weighted sum of rate and distortion. There are various approaches to solving the rate-distortion optimization problem. For example, approaches are based on extensive testing of all encoding options, including all modes or coding parameter values ​​considered, and can fully evaluate the coding cost and associated distortion of the reconstructed signal after coding and decoding. In particular, faster approaches can be used to reduce encoding complexity by calculating approximate distortion based on a prediction or prediction residual signal rather than the reconstructed signal. These two approaches can also be used in combination, such as by using approximate distortion for only some of the possible encoding options and full distortion for others. Other approaches evaluate only a subset of the possible encoding options. More generally, many approaches employ any of a variety of techniques for performing optimization, but the optimization is not necessarily a complete assessment of both the coding cost and the associated distortion.

[0218] The implementations and aspects described herein may be implemented in, for example, a method or process, an apparatus, a software program, a data stream, or a signal. Even if discussed in the context of only a single implementation (e.g., discussed only as a method), the implementation of the discussed features may also be implemented in other forms (e.g., an apparatus or a program). An apparatus may be implemented in, for example, appropriate hardware, software, and firmware. The methods may be implemented in, for example, a processor, which refers generally to processing devices including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, for example, computers, mobile phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end users.

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

[0220] Additionally, the application may refer to "determining" various portions of information. Determining information may include, for example, one or more of evaluating information, calculating information, predicting information, or retrieving information from memory.

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

[0222] Additionally, the application may refer to "receiving" various portions of information. Receiving, like "accessing," is intended to be a broad term. Receiving information may include, for example, one or more of accessing information or retrieving information (e.g., from a memory). Furthermore, "receiving" typically involves in some manner, for example, storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, judging information, predicting information, or evaluating information.

[0223] For example, in the case of "A / B," "A and / or B," and "at least one of A and B," it should be understood that the use of any of the following " / ," "and / or," and "at least one of" is intended to encompass the selection of only the first listed alternative (A), or the selection of only the second listed alternative (B), or the selection of both alternatives (A and B). As a further example, in the case of "A, B, and / or C" and "at least one of A, B, and C," such language is intended to encompass the selection of only the first listed alternative (A), or the selection of only the second listed alternative (B), or the selection of only the third listed alternative (C), or the selection of only the first and second listed alternatives (A and B), or the selection of only the first and third listed alternatives (A and C), or the selection of only the second and third listed alternatives (B and C), or the selection of all three alternatives (A, B, and C). This can be expanded as many times as there are items listed, as would be apparent to one of ordinary skill in the art.

[0224] Also, as used herein, the word "signal" refers, among other things, to instructing a corresponding decoder. For example, in certain embodiments, an encoder signals a specific one of multiple transforms, coding modes, or flags. Thus, in one embodiment, the same transform, parameter, or mode is used on both the encoder and decoder sides. Thus, for example, the encoder can transmit specific parameters to the decoder (explicit signaling), so that the decoder can use the same specific parameters. Conversely, if the decoder already has specific parameters as well as other parameters, signaling can be used without transmission (implicit signaling) to enable the decoder to easily recognize and select the specific parameters. By avoiding the transmission of any actual functions, bit savings are realized in various embodiments. It should be appreciated that signaling can be achieved in various ways. For example, one or more syntax elements, flags, etc. are used to signal information to a corresponding decoder in various embodiments. Although the above relates to the verb form of the word "signal," the word "signaling" can also be used as a noun herein.

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

[0226] Several embodiments are described across various claim categories and types. Features of these embodiments may be provided alone or in any combination. Furthermore, embodiments may include one or more of the following features, devices, or aspects across various claim categories and types, alone or in any combination: • A process or device that restricts the activation or deactivation of a tool in an encoder or decoder. • A process or device that manipulates high-level syntactic or semantic restrictions that constrain the set of possible tool combinations in an encoder or decoder. • A process or device that includes syntax or semantics that specify restrictions on tool combinations. - The use of syntax in the encoder or decoder or the insertion into the bitstream to control the segmentation process. - The use of syntax or insertion into the bitstream to control segmentation-related processes at the encoder or decoder. - The use of syntax or insertion into the bitstream to control multi-hypothesis prediction tools in the encoder or decoder. • The use of syntax or insertion into the bitstream to control the MTS (multiple core transform) process in the encoder or decoder. - Use of syntax or insertion into the bitstream to control secondary transform modes in the encoder or decoder. - Use of syntax or insertion into the bitstream to control the recursive transformation tree mode at the encoder or decoder. ● Use of syntax or insertion into the bitstream to control cross-component linear model or multi-way linear model mode at the encoder or decoder. - Use of syntax or insertion into the bitstream to control ATMVP (Alternative Temporal Motion Vector Prediction) mode at the encoder or decoder. Use of syntax or insertion into the bitstream to control high precision motion vector coding tools in the encoder or decoder. ● The use of syntax in the encoder or decoder or the insertion into the bitstream to control palette mode, current picture reference, or separate luma / chroma trees. - Use of syntax or insertion into the bitstream to control dependent quantization or code data hiding tools in the encoder or decoder. ●Using syntax or inserting it into the bitstream to control the separate luma / chroma trees and cross-component linear models / multi-way linear models relative to each other at the encoder or decoder. • A bitstream or signal containing one or more of the described syntax elements, or variations thereof. A bitstream or signal including syntax conveying information generated according to any of the described embodiments. - Creating and / or transmitting and / or receiving and / or decoding according to any of the described embodiments. - A method, process, apparatus, medium-stored instructions, medium-stored data, or signal according to any of the described embodiments. • Insertion of signaling syntax elements that allow the decoder to distinguish between tools in a way that corresponds to the way the encoder uses them. • Creating and / or transmitting and / or receiving and / or decoding a bitstream or signal containing one or more of the described syntax elements, or variations thereof. ● A television, set-top box, mobile phone, tablet, or other electronic device that performs the conversion method(s) according to any of the described embodiments. ●A television, set-top box, mobile phone, tablet, or other electronic device that performs the determination of the conversion method(s) according to any of the described embodiments and displays the resulting image (e.g., using a monitor, screen, or other type of display). ●A television, set-top box, mobile phone, tablet, or other electronic device that selects, band-limits, or adjusts (e.g., using a tuner) a channel that receives a signal containing an encoded image and performs one or more conversion methods according to any of the described embodiments. • A television, set-top box, mobile phone, tablet, or other electronic device that receives a signal containing the encoded image wirelessly (e.g., using an antenna) and performs the conversion method(s).

Claims

1. Parsing a video bitstream including at least one block for a single high-level syntax element in a first syntax structure; determining whether to parse or infer one or more low-level syntax elements and at least one segmentation restriction that control a decoding tool based on the value of the high-level syntax element; if the high-level syntax element indicates the low-level syntax element is present, parsing the video bitstream for at least one syntax element associated with the at least one segmentation restriction in a second syntax structure at a lower hierarchical level than the first syntax structure; if the high-level syntax element indicates that the low-level syntax element is not present, inferring a value of the low-level syntax element that controls the at least one splitting limit; and decoding the video bitstream using the at least one segmentation restriction determined from the parsed or inferred low-level syntax elements.

2. 1. A processor, comprising: Parsing a video bitstream including at least one block for a single high-level syntax element in a first syntax structure; determining whether to parse or infer one or more low-level syntax elements and at least one segmentation restriction that control a decoding tool based on the value of the high-level syntax element; parsing the video bitstream for at least one syntax element in a second syntax structure at a lower hierarchical level than the first syntax structure, if the high-level syntax element indicates that the low-level syntax element is present, that is associated with the at least one partitioning restriction; and inferring a value of the low-level syntax element that controls the at least one partitioning restriction, if the high-level syntax element indicates that the low-level syntax element is not present; 11. An apparatus, comprising: a processor configured to decode the video bitstream using the at least one segmentation restriction determined from the parsed or inferred low-level syntax elements.

3. The method described in claim 1, wherein at least one syntax element associated with the at least one splitting constraint indicates a prediction mode of an intra-mode coded region of the at least one block.

4. The method described in claim 1, wherein at least one syntax element associated with the at least one splitting constraint indicates the number of regions included in the at least one block.

5. The method described in claim 1, wherein the at least one block is predicted from at least one row of pixels above the block or at least one column of pixels to the left of the block.

6. 3. The apparatus of claim 2, wherein the processor is further configured to partition the at least one block into a plurality of regions based on at least one syntax element associated with the at least one partitioning restriction.

7. The device described in claim 6, wherein the multiple regions do not overlap.

8. The device described in claim 2, wherein at least one syntax element associated with the at least one splitting constraint indicates the number of regions included in the at least one block.

9. An apparatus according to claim 2; 1. A device comprising: (i) an antenna configured to receive a signal, the signal including a video block; (ii) a band limiter configured to limit the received signal to a frequency band including the video block; and (iii) a display configured to display an output representing the video block.

10. The device described in claim 2, wherein at least one syntax element associated with the at least one splitting constraint indicates a prediction mode of an intra-mode coded region of the at least one block.

11. The device described in claim 2, wherein the at least one block is predicted from at least one row of pixels above the block or at least one column of pixels to the left of the block.

12. The method of claim 1, further comprising dividing at least one block into multiple regions based on at least one syntax element associated with the at least one division constraint.

13. The method of claim 12, wherein the multiple regions do not overlap.

Images