Transmission of common constraint information for video coding.

Abstract

In some embodiments, a video decoder decodes video from a video bitstream. The video decoder extracts a count M of additional bits from the video bitstream, where the count M of additional bits indicates a number of additional common constraint information (GCI) bits included in the video bitstream. The additional bits include a flag bit, where the flag bit indicates each additional encoding tool to be constrained for the video, and an expected value of the count of additional bits is 0 or 6. If it is determined that the count M of extracted additional bits is greater than 6, the decoder extracts M-6 bits after the 6 flag bits in the bitstream. Furthermore, the decoder decodes the remaining portion of the bitstream into a picture, independent of the extracted M-6 bits, and based at least in part on the constraints specified for each additional encoding tool, respectively, by the 6 flag bits.

Description

[Technical field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Application No. 63 / 266,615, filed January 10, 2022, entitled "Signaling Methods for General Constraints Information for Video Coding," U.S. Provisional Application No. 63 / 266,616, filed January 10, 2022, entitled "Initialization Method for General Constraint Information Flags for Video Coding," and U.S. Provisional Application No. 63 / 266,765, filed January 13, 2022, entitled "Signaling and Initialization Methods for General Constraints Information for Video Coding," the entire contents of which are incorporated herein by reference.

[0002] FIELD OF THE DISCLOSURE This disclosure relates generally to video processing and, more particularly, to transmission and initialization of common constraint information for video encoding. [Background technology]

[0003] With the widespread use of camera-equipped devices such as smartphones, tablet computers, and computers, taking videos or pictures has become easier than ever. However, even a short video may have a significant amount of data. Video coding techniques (including video encoding and video decoding) can compress video data into smaller sizes, allowing various videos to be stored and transmitted. Video coding has been widely applied to various applications, such as digital television broadcasting, video transmission on the Internet and mobile networks, real-time applications (e.g., video chat, video conferencing, etc.), DVDs, Blu-ray discs, etc. In order to reduce the consumption of storage capacity for storing videos and / or network bandwidth for transmitting videos, it is expected to improve the efficiency of video coding schemes. Summary of the Invention

[0004] Some embodiments relate to transmission and initialization of common constraint information for video coding. In one example, a video decoding method includes extracting a count M of additional bits from a video bitstream, the count M of additional bits indicating a number of additional common constraint information (GCI) bits included in the video bitstream, the additional bits including flag bits, the flag bits respectively indicating each additional coding tool constrained for the video, and an expected value of the count of additional bits is 0 or 6; if it is determined that the extracted count M of additional bits is greater than 6, extracting M-6 bits in the bitstream after the 6 flag bits; and decoding a remaining portion of the video bitstream into a picture based at least in part on the constraints specified for each additional coding tool by the 6 flag bits, independent of the extracted M-6 bits.

[0005] In another example, a non-transitory computer-readable medium has program code stored thereon, the program code operable to cause one or more processing devices to perform operations including: extracting a count M of additional bits from a video bitstream, the count M of additional bits indicating a number of additional common constraint information (GCI) bits included in the video bitstream, the additional bits including flag bits, the flag bits respectively indicating each additional encoding tool constrained for the video, and an expected value of the count of additional bits being 0 or 6; if it is determined that the extracted count M of additional bits is greater than 6, extracting M-6 bits after the 6 flag bits in the bitstream; and decoding a remaining portion of the video bitstream into a picture based at least in part on the constraints imposed on each additional encoding tool by the 6 flag bits, independent of the extracted M-6 bits.

[0006] In yet another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device, the processing device configured to perform operations by executing program code stored on the non-transitory computer-readable medium, the operations including: extracting a count M of additional bits from a video bitstream, the count M of additional bits indicating a number of additional common constraint information (GCI) bits included in the video bitstream, the additional bits including flag bits, the flag bits respectively indicating each additional encoding tool constrained for the video, and an expected value of the count of additional bits being 0 or 6; if it is determined that the extracted count M of additional bits is greater than 6, extracting M-6 bits in the bitstream after the 6 flag bits; and decoding a remaining portion of the video bitstream into a picture based at least in part on the constraints imposed on each additional encoding tool by the 6 flag bits, independent of the extracted M-6 bits.

[0007] These illustrative examples are not intended to limit or define the disclosure, but rather to provide examples to aid in understanding the disclosure. Additional examples are described in the detailed description and are described in more detail therein. [Brief description of the drawings]

[0008] [Figure 1] FIG. 2 is a block diagram illustrating an example of a video encoder configured to implement the embodiments provided herein. [Diagram 2] FIG. 2 is a block diagram illustrating an example of a video decoder configured to implement the embodiments provided herein. [Diagram 3] 1 illustrates an example of coding tree unit partitioning of a picture in a video, according to some embodiments of the present disclosure. [Figure 4] 1 illustrates an example of a coding unit split of a coding tree unit in accordance with some embodiments of the present disclosure. [Diagram 5] 1 illustrates an example of a video decoding process, according to some embodiments of the present disclosure. [Figure 6] 4 illustrates another example of a video decoding process, according to some embodiments of the present disclosure. [Figure 7] 4 illustrates another example of a video decoding process, according to some embodiments of the present disclosure. [Figure 8] 1 illustrates an example of a computing system for implementing some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The features, embodiments, and advantages of the present disclosure can be better understood by reading the following detailed description in conjunction with the drawings, in which:

[0010] Each embodiment provides the transmission and initialization of common constraint information for video coding. As mentioned above, more and more video data are generated, stored and transmitted. In addition to increasing the efficiency of video coding technology, it is also beneficial to increase the stability of video coding so that the video signal can be successfully decoded at the decoder side. Problems related to the stability of video decoding include incompatibility and inconsistency. With the development of video coding technology, new video coding standards have also emerged. Among them, one of the video coding standards is the Versatile Video Coding Standard Version 1, which is jointly issued by the International Organization for Standardization (ISO) as "ISO / IEC 23090-3:2021 Information Technology - Coding Representation of Immersive Media - Part 3: Versatile Video Coding" and by the International Telecommunication Union (ITU) as "ITU-T H.26 Recommendation (08 / 2020): Versatile Video Coding". In this disclosure, the Versatile Video Coding Standard Version 1 is also referred to as "VVC Version 1" or "VVCvl". VVC version 1 is superseded by version 2 of the versatile video coding standard, which is jointly published by ISO as "ISO / IEC 23090-3:2022 Information technology - Coding representation of immersive media - Part 3: Versatile video coding" and by ITU as "ITU-T H.266 Recommendation (04 / 2022): Versatile video coding". In this disclosure, version 2 of the versatile video coding standard is also referred to as "VVC version 2" or "VVCv2". In order to allow a video signal encoded using an earlier version of a video coding standard to be successfully decoded by a video decoder of a newer version of a video coding standard, the video coding scheme needs to be designed to be backward compatible with the earlier version of the coding standard. However, the transmission of common constraint information used in the current draft of VVC version 2 causes video decoding to be unable to synchronize, which is a severe incompatibility problem between different versions of the video coding standard. Furthermore, in the current draft of VVC Version 2, the common constraint flags associated with the common constraint information, if any, may be undefined, which may cause ambiguity and inconsistency in decoder implementations.Various embodiments described herein introduce a common constraint information transmission and initialization method for video encoding to solve these problems, thereby improving the stability of video encoding.

[0011] In the VVC standard, the common constraint information (GCI) syntax structure general_constraints_info() is used to indicate certain constraint properties of a bitstream. The GCI contains a list of constraint flags and non-flag syntax elements. A binary flag gci_present_flag is used to specify whether a GCI syntax element is present or not. In some embodiments, when common constraint information is transmitted in a VVC version 2 bitstream (i.e., the value of gci_present_flag is 1) and the VVC version 2 common constraint information consists of N additional coding tools that may be constrained, the value of the syntax element gci_num_additional_bits corresponding to these N additional coding tools can only be set to 0 or N. If gci_num_additional_bits is set to 0, the common constraint flags of these N additional coding tools are not transmitted. If gci_num_additional_bits is set to N, the next N bits of the bitstream are used to transmit the common constraint flags of these N additional coding tools. In one example, N is set to 6.

[0012] In some examples, for a VVC version 2 bitstream, setting gci_num_additional_bits to a value other than 0 or N is not permitted. However, a VVC version 2 decoder can still process common constraint information that sets gci_num_additional_bits to a value other than 0 or N. For example, gci_num_additional_bits can be set to M, where M is greater than 0 and less than N, or M is greater than N. If M is greater than 0 and less than N, after decoding the gci_num_additional_bits syntax element, the decoder extracts and discards M bits from the bitstream. If M is greater than N, after decoding the gci_num_additional_bits syntax element, the decoder extracts N bits from the bitstream and interprets these N bits as common constraint flags for the N additional encoding tools. The decoder then further extracts and discards (MN) bits from the bitstream. In another example, a VVC version 2 decoder does not need to process common constraint information that sets gci_num_additional_bits to a value greater than 0 and less than N. A legal VVC version 2 bitstream can only set the value of gci_num_reserved_bits to 0 or N. Bitstreams for future versions of VVC will not be allowed to set gci_num_additional_bits to a value between 0 and N.

[0013] In some embodiments, initializing the common constraint information flag is used to solve the above-mentioned problems of ambiguity and inconsistency in decoder implementations. In these embodiments, if gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, general_constraints_info() does not constrain the encoding tool associated with the common constraint information flag. In the example where the flag value is 0, indicating no constraint, the value of the common constraint information flag is inferred to be equal to 0 if the flag is not present.

[0014] The embodiments described in this disclosure provide a method for the propagation and inference of common constraint flags for additional coding tools in VVC Version 2. Unlike the prior art, the high-level syntax bitstreams generated by the methods described in this disclosure are compatible with VVC Version 1 decoders and can be decoded even in situations where the operation of a VVC Version 1 decoder cannot be synchronized with the operation of a VVC Version 2 decoder. The inference rules described in this disclosure remove any ambiguity in the VVC Version 2 decoding behavior of VVC Version 2 GCI syntax elements. These techniques can be effective coding tools in a variety of video coding standards.

[0015] Referring now to the drawings, Fig. 1 is a block diagram illustrating an example of a video encoder 100, which is configured to realize the embodiments presented herein. In the example shown in Fig. 1, the video encoder 100 includes a partition module 112, a transform module 114, a quantization module 115, a dequantization module 118, an inverse transform module 119, an in-loop filter module 120, an intra prediction module 126, an inter prediction module 124, a motion estimation module 122, a decoded picture buffer 130, and an entropy coding module 116.

[0016] The input to the video encoder 100 is an input video 102, which includes a sequence of pictures (also called frames or pictures). In a block-based video encoder, for each picture, the video encoder 100 employs a partition module 112 to partition the picture into blocks 104, each block including a number of pixels. These blocks may be macroblocks, coding tree units, coding units, prediction units, and / or prediction blocks. A picture may include blocks of different sizes, and the block partitioning for different pictures of a video may be different. Each block may be coded using different predictions, such as intra prediction or inter prediction or hybrid intra and inter prediction.

[0017] Typically, the first picture of a video signal is an intra-coded picture, which is coded using only intra-prediction. In the intra-prediction mode, blocks of the picture are predicted using only previously coded data of the same picture. An intra-coded picture can be decoded without using information from other pictures. To perform intra-prediction, the video encoder 100 shown in FIG. 1 can use an intra-prediction module 126. The intra-prediction module 126 is configured to generate an intra-predicted block (prediction block 134) using reconstructed samples in a reconstruction block 136 of a neighboring block of the same picture. The intra-prediction is performed according to the intra-prediction mode selected for the block. Then, the video encoder 100 calculates the difference between the block 104 and the intra-predicted block 134. This difference is called a residual block 106.

[0018] To further remove redundancy from the block, the transform module 114 transforms the residual block 106 into a transform domain by performing a transform on the samples in the block. Examples of transforms include, but are not limited to, a discrete cosine transform (DCT) or a discrete sine transform (DST). The transformed values, also called transform coefficients, represent the residual block in the transform domain. In some examples, the residual block can be quantized directly without going through the transform of the transform module 114. This mode is called a transform skip mode.

[0019] The video encoder 100 may further use a quantization module 115 to quantize the transform coefficients to obtain quantized coefficients. Quantization involves dividing a sample by a quantization step size followed by rounding, and inverse quantization is multiplying the quantized value by the quantization step size. Such a quantization process is called scalar quantization. Quantization is used to reduce the dynamic range of a video sample (transformed or untransformed) to reduce the number of bits used to represent the video sample.

[0020] Quantization of coefficients / samples within a block can be performed independently, and some existing video compression standards (e.g., H.264, HEVC, etc.) use this quantization method. For an N×M block, the 2D coefficients of the block can be converted into a 1-D array in some scan order for coefficient quantization and encoding. Quantization of coefficients within a block can utilize scan order information. For example, the quantization of a given coefficient within a block can be determined by the state of the quantization value of one previous one in the scan order. To further improve the coding efficiency, multiple quantizers can be used. Which quantizer is used to quantize the current coefficient depends on the previous information of the current coefficient in the encoding / decoding scan order. Such a quantization method is called dependent quantization.

[0021] The quantization step size can be used to adjust the degree of quantization. For example, in the case of scalar quantization, different quantization step sizes can be used to achieve finer or coarser quantization. The smaller the quantization step size, the finer the quantization, and the larger the quantization step size, the coarser the quantization. The quantization step size can be indicated by a quantization parameter (QP). Since the quantization parameter is provided in the encoded bitstream of the video, the video decoder can access and use the quantization parameter for decoding.

[0022] The entropy encoding module 116 then encodes the quantized samples to further reduce the size of the video signal. The entropy encoding module 116 is configured to apply an entropy encoding algorithm to the quantized samples. In some examples, the quantized samples are binarized into binary bins, and the encoding algorithm further compresses the binary bins into bits. Examples of binarization methods include, but are not limited to, a combination of Truncated Rice (TR) and Constrained kth Exponential-Golomb (EGk) binarization, kth Exponential-Golomb binarization, etc. Examples of entropy coding algorithms include, but are not limited to, variable length coding (VLC) schemes, context adaptive VLC schemes (CAVLC), arithmetic coding schemes, binarization, context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or other entropy coding techniques. The entropy coded data is added to a bitstream that outputs the coded video 132.

[0023] As mentioned above, the reconstructed block 136 from the neighboring blocks is used for intra prediction of the block of the picture. The generation of the reconstructed block 136 of a block requires the calculation of the reconstructed residual of the block. The reconstructed residual can be determined by applying inverse quantization and inverse transform to the quantized residual of the block. The inverse quantization module 118 is configured to apply inverse quantization to the quantized samples to obtain inverse quantized coefficients. The inverse quantization module 118 applies the inverse scheme of the quantization scheme applied to the quantization module 115 using the same quantization step size as the quantization module 115. The inverse transform module 119 is configured to apply the inverse transform of the transform applied to the transform module 114 (such as inverse DCT or inverse DST) to the inverse quantized samples. The output of the inverse transform module 119 is the reconstructed residual of the block in the pixel domain. The reconstructed block 136 in the pixel domain can be obtained by adding the reconstructed residual to the prediction block 134 of the block. The inverse transform module 119 is not applied to the blocks whose transform is skipped. The dequantized samples are the reconstructed residual of the block.

[0024] Blocks of subsequent pictures after the first intra-predicted picture can be coded using inter prediction or intra prediction. In inter prediction, prediction of blocks within a picture is based on one or more previously coded video pictures. To perform inter prediction, video encoder 100 uses inter prediction module 124. Inter prediction module 124 is configured to perform motion compensation on blocks based on motion estimates provided by motion estimation module 122.

[0025] The motion estimation module 122 performs motion estimation by comparing the current block 104 of the current picture with the decoded reference picture 108. The decoded reference picture 108 is stored in the decoded picture buffer 130. The motion estimation module 122 selects a reference block from the decoded reference picture 108 that best matches the current block. The motion estimation module 122 further identifies an offset between the location (e.g., x, y coordinates) of the reference block and the location of the current block. The offset is called a motion vector (MV) and is provided to the inter prediction module 124 together with the selected reference block. In some cases, multiple reference blocks are identified for the current block in multiple decoded reference pictures 108. Thus, multiple motion vectors are generated and provided to the inter prediction module 124 together with the corresponding reference blocks.

[0026] The inter prediction module 124 performs motion compensation using the motion vector and other inter prediction parameters to generate a prediction of the current block, i.e., an inter prediction block 134. For example, the inter prediction module 124 may identify a prediction block pointed to by the motion vector in a corresponding reference picture based on the motion vector. When there are multiple prediction blocks, these prediction blocks are combined with a certain weight to generate the prediction block 134 of the current block.

[0027] For an inter-predicted block, video encoder 100 may subtract inter-predicted block 134 from block 104 to generate residual block 106. Residual block 106 may be transformed, quantized, and entropy coded in the same manner as the residual for an intra-predicted block described above. Similarly, the residual may be inverse quantized, inverse transformed, and combined with the corresponding prediction block 134 to obtain a reconstructed block 136 for the inter-predicted block.

[0028] To obtain the decoded picture 108 used for motion estimation, the in-loop filter module 120 processes the reconstruction block 136. The in-loop filter module 120 is configured to smooth pixel transients, thereby improving video quality. The in-loop filter module 120 is configured to implement one or more in-loop filters, such as a deblocking filter, a sample self-adaptive offset (SAO) filter, a self-adaptive loop filter (ALF), etc.

[0029] 2 illustrates an example of a video decoder 200 configured to implement embodiments presented herein. The video decoder 200 processes encoded video 202 in a bitstream to generate decoded pictures 208. In the example illustrated in FIG. 2, the video decoder 200 includes an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, an in-loop filter module 220, an intra prediction module 226, an inter prediction module 224, and a decoded picture buffer 230.

[0030] The entropy decoding module 216 is configured to perform entropy decoding on the coded video 202. The entropy decoding module 216 decodes quantized coefficients, coding parameters (including intra-prediction parameters and inter-prediction parameters), and other information. In some examples, the entropy decoding module 216 decodes the bitstream of the coded video 202 into a binary representation, and then converts the binary representation into quantization levels of the coefficients. The entropy decoded coefficient levels are inverse quantized by the inverse quantization module 218 and then inverse transformed to the pixel domain by the inverse transform module 219. The functions of the inverse quantization module 218 and the inverse transform module 219 are similar to the inverse quantization module 118 and the inverse transform module 119 described with respect to FIG. 1 above, respectively. The inverse transformed residual blocks can be added to the corresponding prediction blocks 234 to generate the reconstruction blocks 236. The inverse transform module 219 is not applied to blocks whose transformations have been skipped. The dequantized samples generated by the dequantization module 118 are used to generate a reconstruction block 236 .

[0031] A prediction block 234 for a particular block is generated based on the prediction mode of the block. If the coding parameters of the block indicate that the block is intra predicted, a reconstructed block 236 of a reference block in the same picture may be input to the intra prediction module 226 to generate the prediction block 234 for the block. If the coding parameters of the block indicate that the block is intra predicted, the prediction block 234 is generated by the inter prediction module 224. The functions of the intra prediction module 226 and the inter prediction module 224 are similar to the intra prediction module 126 and the inter prediction module 124 of FIG. 1.

[0032] 1 above, inter prediction involves one or more reference pictures. The video decoder 200 generates a decoded picture 208 of the reference picture by applying an in-loop filter module 220 to a reconstructed block of the reference picture. The decoded picture 208 is stored in a decoded picture buffer 230 and provided to an inter prediction module 224 for output.

[0033] Now referring to FIG. 3, FIG. 3 illustrates an example of coding tree unit division of a picture in a video according to some embodiments of the present disclosure. As described with respect to FIG. 1 and FIG. 2, to encode a picture of a video, the picture is divided into blocks, such as coding tree units (CTUs) 302 in VVC, as shown in FIG. 3. For example, the CTUs 302 may be blocks of 128×128 pixels. The CTUs are processed according to an order (e.g., the order shown in FIG. 3). In some examples, as shown in FIG. 4, each CTU 302 in a picture may be divided into one or more coding units (CUs) 402, and the CUs 402 may be further divided into prediction units or transform units (TUs) for prediction and transformation. Depending on the encoding scheme, the CTUs 302 may be divided into CUs 402 in different manners. For example, in VVC, the CUs 402 may be rectangular or square, and may be encoded without further division into prediction units or transform units. Each CU 402 may be the same size as its root CTU 302, or may be a subdivision as small as a 4x4 block of the root CTU 302. As shown in Figure 4, methods for dividing a CTU 302 into CUs 402 in VVC include quadtree division, binary tree division, and ternary tree division. In Figure 4, solid lines indicate quadtree division, and dashed lines indicate binary or ternary tree division.

[0034] Common constraint information in VVC version 1 (VVCv1) In VVC version 1, the Common Constraints Information (GCI) syntax structure general_constraints_info() is used to indicate specific constraint properties of a bitstream. The GCI contains a list of constraint flags and non-flag syntax elements. A binary flag gci_present_flag is used to specify whether a GCI syntax element is present or not. When gci_present_flag is equal to 1, it specifies the presence of a GCI syntax element in the general_constraints_info() syntax structure. When gci_present_flag is equal to 0, it specifies that no GCI field is present in the general_constraints_info() syntax structure and that the general_constraint_info() syntax structure does not impose any constraints.

[0035] In multiple contexts, common constraint information can be transmitted in a high-level syntax. For example, GCI can be transmitted in a network packet that contains only decoding capability information, e.g., a Network Abstraction Layer (NAL) packet with nal_unit_type set to 13 (i.e., DCI_NUT as the name of the nal_unit_type), or in a video parameter set or a sequence parameter set.

[0036] The purpose of the GCI syntax structure is to enable discovery of configuration information about features required for decoding of a bitstream and to transmit an interoperability point (IOP) with restrictions that go beyond the profile, tier, and level (PTL) specifications and with a finer granularity than that allowed by previous video coding standards. Similar to sub-profiles, the use of the GCI syntax structure can enable the definition of interoperability for decoder implementations that do not support all the features of a VVC profile but meet the needs of a particular application. A decoder implementation can consult the GCI syntax elements to check if the bitstream avoids the use of certain features, to decide how to configure the decoding process, and to identify if the bitstream is decodable by the decoder. A decoder implementation that supports all the features of the VVC profile can ignore the GCI syntax element values ​​because such a decoder can decode all bitstreams that meet the indicated PTL.

[0037] The common constraint information syntax structure specified in VVC version 1 is defined as follows:

[0038] [Table 1(1)] [Table 1(2)] [Table 1(3)] [Table 1(4)]

[0039] The presence of a common constraint flag is determined by the value of gci_present_flag. If the value of gci_present_flag is 1, then the common constraint flag is present in the bitstream. If the value of gci_present_flag is 0, then the common constraint flag is not present in the bitstream.

[0040] Besides the common constraint flags defined in VVCv1, additional common constraint flags are further specified in the syntax element gci_num_reserved_bits. gci_num_reserved_bits is an 8-bit unsigned integer whose value indicates the number of additional bits to be transmitted in the common constraint syntax structure. In the VVC specification, these additional bits (called syntax element gci_reserved_zero_bit[i]) are extracted from the bitstream and discarded. Such a specification allows a decoder of VVCvl to be forward compatible with at least the high-level syntax part of bitstreams generated by later versions of VVC.

[0041] Common Constraint Information in VVC Version 2 (VVCv2) The current draft of VVC version 2 ("VVC Operating Range Extension (Draft 5)", a document of the Joint Video Experts Team of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, JVET-X2005) proposes some additional coding tools constrained by common constraint flags. It is proposed to rename the 8-bit field called gc_num_reserved_bits in VVCvl to gci_num_additional_bits. The syntax proposed to be adjusted in VVCv2 is as follows:

[0042] [Table 2]

[0043] There are six additional common constraint flags in total: gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, gci_no_persistent_rice_adaptation_constraint_flag, and gci_no_reverse_last_sig_coeff_constraint_flag. The interpretation ("semantics") of the gci_num_additional_bits syntax element is as follows:

[0044] gci_num_additional_bits specifies the number of additional GCI bits other than the gci_alignment_zero_bit syntax element (if present) in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits should be equal to 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved to ITU-T|ISO / IEC for future use. Although this version of this document requires that values ​​of gci_num_additional_bits be equal to 0 or 1, decoders conforming to this version of this document should allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax and should ignore the values ​​of all gci_reserved_zero_bit[i] syntax elements if gci_num_additional_bits is greater than 1.

[0045] It was proposed that when a VVCv2 bitstream carries common constraint information, if it does not carry six VVCv2 common constraint flags, the syntax element gci_num_additional_bits should be set to 0, and if it carries six VVCv2 common constraint flags, gci_num_additional_bits should be set to 1.

[0046] However, the above proposed specification of the common constraint syntax of VVCv2 causes incompatibility with the decoder of VVCvl. Specifically, when transmitting an additional common constraint flag, the proposed VVCv2 syntax transmits the flag by setting gci_num_additional_bits to 1. In the VVCv2 decoder, when transmitting common constraint information, the decoder decodes the gci_num_additional_bits syntax element from the bitstream into an 8-bit unsigned integer. If gci_num_additional_bits is decoded to a value of 1, six additional bits are decoded from the bitstream. These six bits are interpreted as the common constraint flag of the additional decoding tool that can be constrained in VVCv2.

[0047] A VVCv1 decoder interprets the same 8-bit field as gci_num_reserved_bits, except that if the syntax element is decoded to a value of 1, only one additional bit is decoded from the bitstream; that bit is discarded and not used. As a result, a VVCv1 decoder decoding a VVCv2 bitstream may encounter synchronization issues due to the presence of five additional bits in the bitstream that are not recognized by the VVCv1 specification.

[0048] As mentioned above, the lack of synchronization is a major incompatibility issue between different versions of video coding standards. A VVCv1 decoder cannot decode all the content of a VVCv2 bitstream because the VVCv2 bitstream uses coding tools that are defined in the VVCv2 specification but are unknown to a VVCv1 decoder. However, it is desirable for a VVCv1 decoder to be able to decode at least the high-level syntax portion of a VVCv2 bitstream. By successfully decoding the high-level syntax, a video decoder can determine profile and tier information as well as common constraint information. Such information provides the decoder with hints on the capabilities required to decode the bitstream. For example, the common constraint information provides the decoder with an indication as to which coding tools are constrained to the bitstream. The profile and tier information provides the decoder with an indication as to the uncompressed video data throughput (e.g., video data rate, frame rate, resolution, etc.) that needs to be supported.

[0049] If the high-level syntax is successfully decoded, the video decoder can determine whether it can decode the current bitstream, and if not, the decoder can successfully terminate the decoding process. In contrast, failure to synchronize with the decoding of the high-level syntax means that the information provided in the high-level syntax cannot be correctly decoded. In the worst case, the decoder may decode completely incorrect syntax element values ​​after the synchronization failure occurs, which may lead to incorrect parameter settings and even incorrect decoding of the subsequent low-level syntax, causing the decoding to fail.

[0050] Furthermore, when transmitting common constraint information, a VVCv2 decoder decodes the gci_num_additional_bits syntax element from the bitstream as an 8-bit unsigned integer. If the value of gci_num_additional_bits is decoded to 0, no further common constraint flags are transmitted. In this case, no guess is specified for the additional common constraint flags, and the value of the additional common constraint flags is undefined. Therefore, it is unclear whether the coding tools associated with the additional common constraint flags should be constrained or not constrained, which may lead to inconsistent decoder implementations.

[0051] In the VVC specification, the name of the syntax element gci_reserved_zero_bit[i] misleadingly suggests that the value of such a syntax element must be 0. Typically, when an encoder writes a reserved syntax element as a placeholder into a bitstream, it embeds a default value in the name of the reserved syntax element. However, the design of the common constraint syntax structure does not ensure that an encoder will never write gci_reserved_zero_bit[i]. gci_reserved_zero_bit[i] is used only when a particular version of a VVC decoder reads a higher version of a VVC bitstream. In this case, the value of gci_reserved_zero_bit[i] is not guaranteed to be 0. In the following, we propose some solutions to solve the above problem.

[0052] Regarding transmission of common constraint information flag In one embodiment, the problem of the above-mentioned non-synchronizability is solved by transmitting common constraint information. When the bitstream of VVCv2 transmits common constraint information (i.e., the value of gci_present_flag is 1) and the VVCv2 common constraint information is composed of N additional coding tools that may be constrained, the value of the syntax element gci_num_additional_bits can only be set to 0 or N. When gci_num_additional_bits is set to 0, the common constraint flags of these N additional coding tools are not transmitted. When gci_num_additional_bits is set to N, the subsequent N bits of the bitstream are used to transmit the common constraint flags of these N additional coding tools. In one example, N is set to 6.

[0053] In the bitstream of VVCv2, it is not permitted to set gci_num_additional_bits to a value other than 0 or N. However, the decoder of VVCv2 can process common constraint information with gci_num_additional_bits set to a value other than 0 or N. For example, gci_num_additional_bits can be set to a value greater than 0 and less than N, or a value greater than N. Let the decoded value of gci_num_additional_bits be M. Then, when M is greater than 0 and less than N (i.e., 0 < M < N), after decoding the gci_num_additional_bits syntax element, the decoder extracts M bits from the bitstream as the gci_reserved_zero_bit[i] syntax element and discards them. When M is greater than N (i.e., N < M), after decoding the gci_num_additional_bits syntax element, the decoder extracts N bits from the bitstream and interprets these N bits as the common constraint flags of the N additional coding tools. Next, the decoder further extracts (M - N) bits from the bitstream as the gci_reserved_zero_bit[i] syntax element and discards them.

[0054] In another example, a VVCv2 decoder does not need to process common constraint information that sets gci_num_additional_bits to a value greater than 0 and less than N. A legal VVCv1 bitstream can only set the value of gci_num_reserved_bits to 0. A legal VVCv2 bitstream can only set the value of gci_num_additional_bits to 0 or N. Future version VVC bitstreams will not be allowed to set gci_num_additional_bits to a value between 0 and N.

[0055] In one example of this embodiment, the VVCv2 common constraint information syntax is modified to the six common constraint flags currently proposed for the VVCv2 encoding tool, as shown in Table 1 below (additions are underlined and deletions are strikethrough), where "if (gci_num_additional_bits>0)" is replaced with "if (gci_num_additional_bits>5)".

[0056] [Table 3]

[0057] In one example, if six additional common constraint flags are present in a VVCv2 encoding tool, the corresponding semantics of gci_num_additional_bits are as follows (additions are underlined and deletions are strikethrough):

[0058] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits should be equal to ≪1≫. Other than 0 and 6 The value of gci_num_additional_bits is reserved for future use by ITU-T / ISO / IEC. In this version of the document, the value of gci_num_additional_bits is 0 or ≪1≫. 6 , but decoders conforming to this version of the document must be equal to ≪greater than 1≫ Other than 0 and 6 The value of gci_num_additional_bits is permitted to be present in the syntax and gci_num_additional_bits is greater than 1. Not 0 or 6 In this case, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored.

[0059] In the above example of the semantics of gci_num_additional_bits, in addition to the values ​​of 0 or 6 mentioned above, gci_num_additional_bits is allowed to take values ​​other than 0 or 6. That is, the value of gci_num_additional_bits may be between 1 and 5. gci_num_additional_bits is also allowed to take values ​​greater than 6. If the value of gci_num_additional_bits is between 1 and 5 (indicated by M), according to the syntax shown in Table 1 above, the decoder skips the step executed when the "if" condition is true and transitions to the "else" step, assigning the value of "numAdditionalBitsUsed" to 0. Then, in the "for" loop, it reads and discards M bits. In this way, the out-of-synchronization problem can be avoided. If the value M of gci_num_additional_bits is greater than 6, it extracts 6 additional common constraint flags and further extracts and discards the remaining M-6 bits.

[0060] In another example, if six additional common constraint flags are present in a VVCv2 encoding tool, the corresponding semantics of gci_num_additional_bits are as follows (additions are underlined and deletions are strikethrough):

[0061] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits should be equal to ≪1≫. 6Larger values ​​are reserved for future use by ITU-T / ISO / IEC. In this version of the document, gci_num_additional_bits must have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document must be equal to ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax, and gci_num_additional_bits is ≪1≫ 6 If it is greater, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored.

[0062] In another embodiment of transmitting common constraint information, if the VVCv2 bitstream transmits common constraint information (i.e., the value of gci_present_flag is 1) and the VVCv2 common constraint information consists of N potentially constrained additional coding tools, the value of the syntax element gci_num_additional_bits can be set to M. The range of M is from 0 to N inclusive (0≦M≦N). If gci_num_additional_bits is set to 0, the common constraint flags of these N additional coding tools are not transmitted. If gci_num_additional_bits is set to a non-zero value of M, the following M bits of the bitstream are used to transmit the common constraint flags of M of these N additional coding tools. Which M additional coding tools are constrained is determined by the order in which the common constraint flags appear in the common constraint information syntax table.

[0063] In one example of such an embodiment, the common constraint information syntax of VVCv2 is modified to the six common constraint flags currently proposed for encoding tools, which may be as follows:

[0064] [Table 4]

[0065] In another aspect of the embodiment, the equivalent behavior can be achieved with a more compact syntax table.

[0066] [Table 5]

[0067] The alternative arrangement of this embodiment can be expressed in the common constraint information syntax by changing the order of the common constraint flags in the VVCv2 encoding tool.

[0068] If a VVCv2 encoding tool has six additional common constraint flags, the corresponding semantics of gci_num_additional_bits may be as follows:

[0069] gci_num_additional_bits specifies the number of additional GCI bits other than the gci_alignment_zero_bit syntax element (if present) in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits should be in the range 0 to 6, inclusive. Values ​​of gci_num_additional_bits greater than 6 are reserved to ITU-T|ISO / IEC for future use. Although this version of this document requires that the value of gci_num_additional_bits be in the range 0 to 6, inclusive, decoders conforming to this version of this document shall permit values ​​of gci_num_additional_bits greater than 6 to be present in the syntax and shall ignore the values ​​of all gci_reserved_zero_bit[i] syntax elements if gci_num_additional_bits is greater than 6.

[0070] In this embodiment, some or all of the additional common constraint flags may not be transmitted based on the value of gci_num_additional_bits. In one arrangement of this embodiment, if the VVCv2 bitstream transmits common constraint information (i.e., the value of gci_present_flag is 1), the encoding tools corresponding to the additional common constraint flags that are not transmitted are not constrained. This behavior can be expressed by changing the semantics of gci_num_additional_bits, as described below.

[0071] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits should be in the range of 0 to 6, inclusive. Values ​​of gci_num_additional_bits greater than 6 are reserved to ITU-T|ISO / IEC for future use. Although this version of this document requires that the value of gci_num_additional_bits be in the range of 0 to 6, inclusive, decoders conforming to this version of this document should permit values ​​of gci_num_additional_bits greater than 6 to be present in the syntax and should ignore the values ​​of all gci_reserved_zero_bit[i] syntax elements if gci_num_additional_bits is greater than 6. Furthermore, if gci_present_flag is equal to 1, then any coding tools that do not have a corresponding constraint flag in the syntax of general_constraints_info() are not constrained.

[0072] In another arrangement of this embodiment, if the VVCv2 bitstream carries common constraint information (i.e., the value of gci_present_flag is 1) and no additional common constraint flags are carried, the corresponding tool is constrained. This behavior can be expressed by changing the semantics of the additional common constraint flags, as described below.

[0073] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits should be in the range 0 to 6, inclusive. Values ​​of gci_num_additional_bits greater than 6 are reserved by ITU-T|ISO / IEC for future use. Although this version of this document requires that the value range of gci_num_additional_bits be 0 to 6, inclusive, decoders conforming to this version of this document should permit values ​​of gci_num_additional_bits greater than 6 to be present in the syntax and should ignore the values ​​of all gci_reserved_zero_bit[i] syntax elements if gci_num_additional_bits is greater than 6.

[0074] When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are GDR pictures or IRAP pictures whose ph_recovery_poc_cnt is equal to 0. When gci_all_rap_pictures_constraint_flag is equal to 0, no such constraint is imposed. If gci_present_flag is equal to 1 and gci_all_rap_pictures_constraint_flag is not present, the value of gci_all_rap_pictures_constraint_flag is inferred to be equal to 1.

[0075] When gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that sps_extended_precision_flag of all pictures in OlsInScope should all be equal to 0. When gci_no_extended_precision_processing_constraint_flag is equal to 0, no such constraint is imposed. If gci_present_flag is equal to 1 and gci_no_extended_precision_processing_constraint_flag is not present, the value of gci_no_extended_precision_processing_constraint_flag is inferred to be equal to 1.

[0076] Specifies that when gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, sps_ts_residual_coding_rice_present_in_sh_flag of all pictures in OlsInScope should be equal to 0. When gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, no such constraint is imposed. If gci_present_flag is equal to 1 and gci_no_ts_residual_coding_rice_constraint_flag is not present, the value of gci_no_ts_residual_coding_rice_constraint_flag is inferred to be equal to 1.

[0077] When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that sps_rrc_rice_extension_flag of all pictures in OlsInScope should be equal to 0. When gci_no_rrc_rice_extension_constraint_flag is equal to 0, no such constraint is imposed. If gci_present_flag is equal to 1 and gci_no_rrc_rice_extension_constraint_flag is not present, the value of gci_no_rrc_rice_extension_constraint_flag is inferred to be equal to 1.

[0078] Specifies that when gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, sps_persistent_rice_adaptation_enabled_flag of all pictures in OlsInScope should be equal to 0. When gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, no such constraint is imposed. If gci_present_flag is equal to 1 and gci_no_persistent_rice_adaptation_constraint_flag is not present, the value of gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 1.

[0079] Specifies that when gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, sps_reverse_last_sig_coeff_enabled_flag of all pictures in OlsInScope should be equal to 0. When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, no such constraint is imposed. If gci_present_flag is equal to 1 and gci_no_reverse_last_sig_coeff_constraint_flag is not present, the value of gci_no_reverse_last_sig_coeff_constraint_flag is inferred to be equal to 1.

[0080] Initialization of common constraint information flags To solve the above-mentioned problem of ambiguity and inconsistency in decoder implementation, one embodiment of initializing the common constraint information flags is described below, in which, if gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, general_constraints_info() does not constrain the coding tools related to gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag.

[0081] As an example, possible semantic changes of gci_num_additional_bits are shown below, based on the current version defined in VVC version 2 (additions are underlined, deletions are strikethrough):

[0082] gci_num_additional_bits specifies the number of additional GCI bits other than the gci_alignment_zero_bit syntax element (if present) in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits should be equal to 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved to ITU-T|ISO / IEC for future use. Although this version of this document requires that values ​​of gci_num_additional_bits be equal to 0 or 1, decoders conforming to this version of this document shall allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax and shall ignore the values ​​of all gci_reserved_zero_bit[i] syntax elements if gci_num_additional_bits is greater than 1. If gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, then general_constraints_info() does not constrain the coding tools related to gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag.

[0083] As another example, possible changes to the semantics of gci_num_additional_bits are as follows, based on the current version defined in VVC version 2:

[0084] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits should be equal to ≪1≫. Other than 0 and 6 The value is reserved to ITU-T|ISO / IEC for future use. In this version of the document, the value of gci_num_additional_bits is 0 or ≪1≫. 6 , but decoders conforming to this version of the document must be equal to ≪greater than 1≫ Other than 0 and 6 The value of gci_num_additional_bits is permitted to be present in the syntax and gci_num_additional_bits is greater than 1. Not 0 or 6 In this case, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, then general_constraints_info() does not constrain the coding tools related to gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag.

[0085] In the current version defined in VVC version 2, the semantic of gci_num_additional_bits is only used when gci_present_flag is equal to 1. The scenario where gci_present_flag is equal to 0 is addressed in another section of the VVC version 2 specification. Therefore, the above semantic of gci_num_additional_bits "when gci_present_flag is equal to 1" is automatically satisfied. Furthermore, since the VVC version 2 specification does not permit the value of gci_num_additional_bits to be 1 to 5, "gci_num_additional_bits is equal to 0" is equivalent to "gci_num_additional_bits is less than or equal to 5" or "gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag are not present." Therefore, the above change to the semantics of gci_num_additional_bits is equivalent to the following:

[0086] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits is greater than 1. Other than 0 and 6 The value is reserved to ITU-T|ISO / IEC for future use. In this version of the document, the value of gci_num_additional_bits is 0 or ≪1≫. 6 , but decoders conforming to this version of the document must be equal to ≪greater than 1≫ Other than 0 and 6 The value of gci_num_additional_bits is permitted to be present in the syntax and gci_num_additional_bits is greater than 1. Not 0 or 6 In this case, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag are not present, _info() does not constrain the coding tools related to gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag.

[0087] Below are some examples where the inferred value of the additional common constraint flag can be set in a manner similar to the semantics above. For example, the semantics of the additional common constraint flag can be modified to include setting a guessed value as follows:

[0088] When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are GDR pictures or IRAP pictures whose ph_recovery_poc_cnt is equal to 0. When gci_all_rap_pictures_constraint_flag is equal to 0, no such constraint is imposed. If not present, the value of gci_all_rap_pictures_constraint_flag is inferred to be equal to 0.

[0089] Specifies that when gci_no_extended_precision_processing_constraint_flag is equal to 1, sps_extended_precision_flag of all pictures in OlsInScope should be equal to 0. When gci_no_extended_precision_processing_constraint_flag is equal to 0, no such constraint is imposed. If not present, the value of gci_no_extended_precision_processing_constraint_flag is inferred to be equal to 0.

[0090] Specifies that when gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, sps_ts_residual_coding_rice_present_in_sh_flag of all pictures in OlsInScope should be equal to 0. When gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, no such constraint is imposed. If not present, the value of gci_no_ts_residual_coding_rice_constraint_flag is inferred to be equal to 0.

[0091] When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that sps_rrc_rice_extension_flag of all pictures in OlsInScope should be equal to 0. When gci_no_rrc_rice_extension_constraint_flag is equal to 0, no such constraint is imposed. If not present, the value of gci_no_rrc_rice_extension_constraint_flag is inferred to be equal to 0.

[0092] Specifies that when gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, sps_persistent_rice_adaptation_enabled_flag of all pictures in OlsInScope should be equal to 0. When gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, no such constraint is imposed. If not present, the value of gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 0.

[0093] Specifies that when gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, sps_reverse_last_sig_coeff_enabled_flag of all pictures in OlsInScope should be equal to 0. When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, no such constraint is imposed. If not present, the value of gci_no_reverse_last_sig_coeff_constraint_flag is inferred to be equal to 0.

[0094] In another example, the semantics of the additional common constraint flag is modified as follows:

[0095] When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are GDR pictures or IRAP pictures whose ph_recovery_poc_cnt is equal to 0. When gci_all_rap_pictures_constraint_flag is equal to 0, no such constraint is imposed. If gci_all_rap_pictures_constraint_flag is not present, its value is inferred to be equal to 0.

[0096] Specifies that when gci_no_extended_precision_processing_constraint_flag is equal to 1, sps_extended_precision_flag of all pictures in OlsInScope should be equal to 0. When gci_no_extended_precision_processing_constraint_flag is equal to 0, no such constraint is imposed. If gci_no_extended_precision_processing_constraint_flag is not present, its value is inferred to be equal to 0.

[0097] Specifies that when gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, sps_ts_residual_coding_rice_present_in_sh_flag of all pictures in OlsInScope should be equal to 0. When gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, no such constraint is imposed. If gci_no_ts_residual_coding_rice_constraint_flag is not present, its value is inferred to be equal to 0.

[0098] When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that sps_rrc_rice_extension_flag of all pictures in OlsInScope should be equal to 0. When gci_no_rrc_rice_extension_constraint_flag is equal to 0, no such constraint is imposed. If gci_no_rrc_rice_extension_constraint_flag is not present, its value is inferred to be equal to 0.

[0099] Specifies that when gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, sps_persistent_rice_adaptation_enabled_flag of all pictures in OlsInScope should be equal to 0. When gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, no such constraint is imposed. If gci_no_persistent_rice_adaptation_constraint_flag is not present, its value is inferred to be equal to 0.

[0100] Specifies that when gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, sps_reverse_last_sig_coeff_enabled_flag of all pictures in OlsInScope should be equal to 0. When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, no such constraint is imposed. If gci_no_reverse_last_sig_coeff_constraint_flag is not present, its value is inferred to be equal to 0.

[0101] In another example, the semantics of gci_num_additional_bits is changed as follows:

[0102] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits should be equal to ≪1≫. 6 Larger values ​​are reserved for future use by ITU-T | ISO / IEC. In this version of the document, gci_num_additional_bits must have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document must be equal to ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax, and gci_num_additional_bits is ≪1≫ 6 If it is greater, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If gci_num_additional_bits is equal to 0, then all constraint flags specified by the additional GCI bits are inferred to be equal to 0.

[0103] In another example, the semantics of gci_num_additional_bits is changed as follows:

[0104] gci_num_additional_bits specifies the number of additional GCI bits other than the gci_alignment_zero_bit syntax element (if present) in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or <<1>> 6. Values ​​of gci_num_additional_bits greater than <<1>> 6 are reserved to ITU-T|ISO / IEC for future use. In this version of this document, the value of gci_num_additional_bits shall be equal to 0 or <<1>> 6. 6 However, decoders conforming to this version of the document must be equal to ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax, and gci_num_additional_bits is ≪1≫ 6 If it is greater, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If not present, all constraint flags specified by the additional GCI bits are inferred to be equal to 0.

[0105] In another example, the syntax and semantics of the common constraint information syntax element are modified as follows:

[0106] [Table 6]

[0107] [Table 7]

[0108] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6gci_num_additional_bits should be equal to ≪1≫. 6 Larger values ​​are reserved for future use by ITU-T | ISO / IEC. In this version of the document, gci_num_additional_bits must have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document must be equal to ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax, and gci_num_additional_bits is ≪1≫ 6 If it is greater, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If gci_num_additional_bits is equal to 0, the additional_general_constraints_info() syntax structure does not impose any constraints.

[0109] In another example, the semantics of the common constraint information syntax element is modified as follows:

[0110] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits should be equal to ≪1≫. 6 Larger values ​​are reserved for future use by ITU-T | ISO / IEC. In this version of the document, gci_num_additional_bits must have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document must be equal to ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax, and gci_num_additional_bits is ≪1≫ 6 If it is greater, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If not present, the additional_general_constraints_info() syntax construct does not impose any constraints.

[0111] In another embodiment of initializing the common constraint information flags, if gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, then gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag can always impose the corresponding constraints defined by their respective semantics. In other words, if the GCI flags are present and gci_num_additional_bits is equal to 0, then these six GCI flags are inferred to be equal to 1.

[0112] As an example, possible changes to the semantics of gci_num_additional_bits are as follows, based on the current new additions defined in VVC version 2:

[0113] gci_num_additional_bits specifies the number of additional GCI bits other than the gci_alignment_zero_bit syntax element (if present) in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits should be equal to 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved to ITU-T|ISO / IEC for future use. Although this version of this document requires that values ​​of gci_num_additional_bits be equal to 0 or 1, decoders conforming to this version of this document should allow values ​​of gci_num_additional_bits greater than 1 to be present in the syntax and should ignore the values ​​of all gci_reserved_zero_bit[i] syntax elements if gci_num_additional_bits is greater than 1. If gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, then gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag are all inferred to be equal to 1.

[0114] As another example, possible changes to the semantics of gci_num_additional_bits are as follows, based on the current new additions defined in VVC version 2:

[0115] gci_num_additional_bits specifies the number of additional GCI bits, other than the gci_alignment_zero_bit syntax element (if present), in the common constraint information syntax structure. In bitstreams conforming to this version of this document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits is greater than 1. Other than 0 and 6 The value is reserved to ITU-T|ISO / IEC for future use. In this version of the document, the value of gci_num_additional_bits is 0 or ≪1≫. 6 , but decoders conforming to this version of the document must be equal to ≪greater than 1≫ Other than 0 and 6 The value of gci_num_additional_bits is permitted to be present in the syntax and gci_num_additional_bits is greater than 1. Not 0 or 6 In this case, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored. If gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, then gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag are all inferred to be equal to 1.

[0116] In addition to, or as a complement or alternative to, the above embodiment, the misleading syntax element gci_reserved_zero_bit[i] can be renamed to gci_reserved_bit[i]. For example, the modified syntax and semantics may be as follows:

[0117] [Table 8]

[0118] ≪gci_reserved_zero_bit[i]≫ gci_reserved_bit[i] may have any value. Its presence and value have no effect on the decoding process specified in this version of the specification. A decoder conforming to this version of the specification shall ignore all ≪gci_reserved_zero_bit[i]≫ gci_reserved_bit[i] The value of the syntax element should be ignored.

[0119] In a further embodiment, the name of the syntax element gci_reserved_zero_bit[i] is changed to gci_reserved_bit[i]. For example, the modified syntax and semantics may be as follows:

[0120] [Table 9]

[0121] ≪gci_reserved_zero_bit[i]≫ gci_reserved_bit[i]may have any value. Its presence and value have no effect on the decoding process specified in this version of the specification. A decoder conforming to this version of the specification shall ignore all ≪gci_reserved_zero_bit[i]≫ gci_reserved_bit[i] The value of the syntax element should be ignored.

[0122] About common constraint flags About gci_all_rap_pictures_constraint_flag The gci_all_rap_pictures_constraint_flag is used to indicate whether to restrict the picture to an IRAP or GDR picture.

[0123] NAL (Network Abstraction Layer) is a system interface that organizes VVC syntax elements into "NAL units". This structure allows VVC to be easily and effectively customized to fit a variety of use cases, from real-time communication applications to file formats for storage applications. The complete list of NAL unit types in the VVC standard is shown in the following table.

[0124] [Table 10(1)] [Table 10(2)] [Table 10(3)]

[0125] NAL units classified as video coding layer (VCL) contain low-level syntax elements, and NAL units classified as non-VCL contain high-level syntax elements. Pictures of a video sequence are decoded from VCL NAL units. Different types of VCL categories indicate dependencies at a high level. For example, NAL units from TRAIL_NUT (0) to RSV_VCL_6 (6) can usually use inter-prediction tools, which depend on the availability of access to previously decoded (reference) pictures. Compared to pictures compressed using only intra-prediction tools, pictures coded using inter-prediction tools can be compressed more efficiently. However, such decoding dependencies can cause problems in cases where reference pictures cannot be obtained.

[0126] An Intra Random Access Point (IRAP) picture is a coded picture whose all VCL NAL units have the same value of nal_unit_type, in the range from IDR_W_RADL to CRA_NUT, inclusive. An IRAP picture may be a CRA picture or an IDR picture. An IRAP picture does not use inter prediction from reference pictures of the same layer in the decoding process. The first picture in the decoding order in the bitstream is an IRAP picture or a Gradual Decoding Refresh (GDR) picture. For a single layer bitstream, if the necessary parameter set can be obtained when it needs to be referenced, the IRAP picture and all subsequent non-RASL pictures arranged in the decoding order in the CLVS can be correctly decoded, and there is no need to perform the decoding process for any pictures whose decoding order precedes the IRAP picture. The value of pps_mixed_nalu_types_in_pic_flag for an IRAP picture is equal to 0. If a picture's pps_mixed_nalu_types_in_pic_flag is equal to 0 and the nal_unit_type of any slice of that picture is in the range from IDR_W_RADL to CRA_NUT (inclusive), then all other slices of that picture have the same nal_unit_type value and the picture is known to be an IRAP picture after receiving the first slice.

[0127] Therefore, IRAP pictures do not use inter prediction across the same layer. This restriction allows IRAP pictures to be used as error recovery points in streaming video applications or video search points in video-on-demand playback applications. However, the compression efficiency of IRAP pictures is usually lower than that of non-IRAP pictures.

[0128] Gradual Decoding Refresh (GDR) pictures were introduced in the VVC standard as a trade-off between non-IRAP and IRAP pictures. GDR pictures have "clean" parts that do not use inter prediction, while the rest of the picture is free to use inter prediction. By dividing the picture in this way, the "clean" parts can be decoded correctly even in the event of an error such as a packet loss. In successive GDR pictures, the spatial position of the "clean" parts is rotated, so that eventually the whole picture can recover from errors.

[0129] In video applications where streaming resilience of playback flexibility is important, it may be desirable to restrict all pictures to be IRAP or GDR pictures. In VVCv2, a GCI flag gci_all_rap_pictures_constraint_flag is introduced to indicate such a restriction at a high level. When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are GDR pictures with ph_recovery_poc_cnt equal to 0, or IRAP pictures. When gci_all_rap_pictures_constraint_flag is equal to 0, no such restriction is imposed. When gci_all_rap_pictures_constraint_flag is not present, its value is inferred to be equal to 0.

[0130] If the profile_tier_level() syntax structure is included in the VPS, OlsInScope is one or more output layer sets (OLS) specified by the VPS. If the profile_tier_level() syntax structure is included in the SPS, OlsInScope is an OLS that includes only the lowest layer among the layers that reference the SPS, and the lowest layer is an independent layer.

[0131] gci_no_extended_precision_processing_constraint_flag The GCI flag gci_no_extended_precision_processing_constraint_flag conveys at a high level whether the conversion precision extension VVCv2 tools are constrained or not. In the VVC standard, the pixels of a video signal are represented by integer values. All calculations and processing described in the VVC standard are expressed in integer arithmetic. This restriction is important due to complexity and interoperability considerations. First, the computational cost of integer arithmetic (addition, multiplication, division) is usually lower compared to the equivalent floating-point operation. Second, floating-point arithmetic is not deterministically standardized. Floating-point addition and multiplication cannot always satisfy the commutative law (e.g., (a+b)+c is not always equal to a+(b+c)), and the results of floating-point operations on different platforms are not guaranteed to be the same.

[0132] The bit depth of a video signal sample is an attribute of a video source and is denoted as BitDepth in the VVC standard. In a hybrid video coding system, the video samples are predicted by an inter-prediction tool or an intra-prediction tool. The difference between the original video sample and the predicted sample is called the residual. In the worst case, the bit depth of these residual coefficients may be expanded (e.g., BitDepth+1), but in the VVC standard, these residual coefficients are trimmed to maintain a bit depth of BitDepth. In practice, the worst case never occurs, because a real encoder would not select a prediction tool that generates a residual larger than the original video signal.

[0133] The residual coefficients are then analyzed to generate transform coefficients, typically by integer-scaled discrete cosine transform (DCT), which is a linear, invertible function and can be formally expressed as follows:

[0134]

number

number

number

[0135] In VVCv1, the bit depth of the transform coefficients is 16. That is, each transform coefficient is in the range [-2 15 ,2 15 Multiplying the video samples by the integerized DCT coefficients typically produces intermediate transform coefficients whose bit depth is greater than 16. To produce transform coefficients with the desired bit depth, the intermediate transform coefficients are bit-shifted to the right. Such an operation is inherently lossy.

[0136] In VVCv2, extended transform precision is enabled by setting the SPS flag sps_extended_precision_flag to 1. When extended transform precision is enabled, the bit depth of the transform coefficients increases to (Log2TransformRange+1). The exact bit depth of the transform coefficients depends on BitDepth. When sps_extended_precision_flag is equal to 1, it specifies that the scaling and transform process uses extended dynamic range for the transform coefficients and that the extended dynamic range is used for the binarization of the abs_remaining[] and dec_abs_level[] syntax elements. When sps_extended_precision_flag is equal to 0, it specifies that the scaling and transform process does not use extended dynamic range and that the extended dynamic range is not used for the binarization of the abs_remaining[] and dec_abs_level[] syntax elements. If not present, the value of sps_extended_precision_flag is inferred to be equal to 0. The variable Log2TransformRange is derived as follows:

[0137]

number

[0138] About gci_no_ts_residual_coding_rice_constraint_flag The GCI flag gci_no_ts_residual_coding_rice_constraint_flag is signaled at a high level to indicate whether the VVCv2 tools are constrained with explicit Rice parameters. In entropy coding, the value of each syntax element is coded into a bit sequence by an entropy coding process and inserted into the bitstream.

[0139] The two entropy coding processes used in VVC are Context-Adaptive Binary Arithmetic Coding (CABAC) and Rice coding. The CABAC engine is self-adaptive and can compress syntax elements to bit rates very close to the theoretical Shannon limit. However, arithmetic coding is complex. To encode non-binary syntax elements (e.g., syntax elements whose value range exceeds 0 or 1) using CABAC, the syntax elements are first binarized into a set of "bins". The table below shows two examples of binarization. The second example shows that in the case of variable-length binarization, some values ​​of the syntax elements do not have a corresponding bin.

[0140] [Table 11]

[0141] [Table 12]

[0142] Each bin of the binarization can be coded by a CABAC engine. However, to code a bin using CABAC, the engine needs to store and update an associated "context", which models the probability distribution of the bin. In a syntactic element binarization, each bin needs a separate context.

[0143] Syntax elements with a wide range of values ​​are not desirable to code simply using CABAC because such syntax elements require long binarization times, which would cause excessive overhead for storing and updating context. For example, residual coefficient values ​​are inconvenient to code simply using CABAC. In contrast to CABAC, Rice coding can model the probability distribution of non-binary values ​​using compact parameters.

[0144] Rice coding is also called Golomb coding or Rice-Golomb coding. Golomb coding is an entropy coder controlled by a single parameter M, which is restricted to be a positive integer. Rice coding is a subset of Golomb coding, where the entropy coder is controlled by a single Rice parameter R, where R is a non-negative integer. The Rice code with Rice parameter R is equivalent to the Golomb coder, where M=2 R It is.

[0145] A non-negative integer value x is binarized into a Rice code with Rice parameter R as follows. The quotient q and remainder r are calculated as follows:

[0146]

number

[0147] [Table 13]

[0148] Since the unary code is a truncated version, the Rice code is also truncated, which means that the range of values ​​of x that can be encoded is limited. In VVC, the truncated Rice code is

number

[0149] The length of the suffix code is the binarized fixed length code of r bits of R. For example, if R=3, the suffix code is

[0150] [Table 14]

[0151] In VVC, the residual coefficients are coded by a combination of CABAC, Rice coding and Exponential-Golomb coding. A few syntax element flags are defined, which are sufficient to transmit the values ​​of small magnitude residuals. For example, sig_coeff_flag indicates whether the magnitude of the residual is zero or not. If sig_coeff_flag is 1, further flags can be transmitted (usually named abs_level_gtx_flag), which indicate whether the magnitude of the residual is greater than 1, 2, 3, etc. These flags are context coded by the CABAC engine. Since most of the residual coefficients are small in magnitude, CABAC can efficiently code most of the residuals using a relatively small number of bins.

[0152] Any remaining magnitude of the residual coefficients that cannot be conveyed by the residual coefficient flags is conveyed in the syntax element abs_remainder. The value of abs_remainder is 6 × 2 R If it is less than or equal to 6×2, the syntax element is completely transmitted by the Rice code of abs_remainder. R If it is larger, the syntax element is 6×2 R Rice code and

number

[0153] Although Rice coding is simpler than CABAC, under the right conditions, Rice coding is also effective for low bitrate compression. If all the residual coefficients are small, Rice coding with a small Rice parameter is more efficient. Conversely, if some of the residual coefficients have large values, a larger Rice parameter may be more suitable. To adapt to the statistics of the residual coefficients, the Rice parameter is self-adaptively determined based on the locSumAbs value, which is calculated based on the magnitude of the neighboring residual coefficients.

[0154] [Table 15]

[0155] The self-adaptive Rice parameter determination is designed for residual coefficients in "Regular Residual Coding" (RRC), which are residual coefficients obtained by performing a Discrete Cosine Transform (DCT). However, in VVCv1, it is also applied to residual coefficients in "Transform Skip Residual Coding" (TSRC). In VVCv2, we realize that an alternative mechanism for determining the Rice parameter may be beneficial for transform skip coefficients.

[0156] An alternative mechanism in VVCv2 allows explicitly transmitting the Rice parameter via the slice-level syntax element sh_ts_residual_coding_rise_idx_minusl. When transmitting this syntax element, the Rice parameter is set to R=sh_ts_residual_coding_rise_idx_minusl+1. This value of the Rice parameter is retained for the duration of the slice.

[0157] [Table 16]

[0158] sh_ts_residual_coding_rice_idx_minusl+1 specifies the Rice parameter used for residual_ts_coding() syntax structures in the current slice. If not present, the value of sh_ts_residual_coding_rice_idx_minusl is inferred to be equal to 0.

[0159] Whether the fallback mechanism is enabled or not is controlled by the SPS-level flag sps_ts_residual_coding_rice_present_in_sh_flag. If this flag is set to 0, do not enable fallback Rice parameter transmission. The GCI flag gci_no_ts_residual_coding_rice_constraint_flag signals at a high level whether the VVCv2 tool of explicit Rice parameter transmission is constrained or not. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it specifies that sps_ts_residual_coding_rice_present_in_sh_flag is equal to 0 for all pictures in OlsInScope. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, do not impose such constraint. If gci_no_ts_residual_coding_rice_constraint_flag is not present, its value is inferred to be equal to 0.

[0160] gci_no_rrc_rice_extension_constraint_flag gci_no_rrc_rice_extension_constraint_flag specifies sps_rrc_rice_extension_flag of all pictures in OlsInScope. When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that sps_rrc_rice_extension_flag of all pictures in OlsInScope is equal to 0. When gci_no_rrc_rice_extension_constraint_flag is equal to 0, no such constraint is imposed.

[0161] In high bit depth and high bit rate applications, many large quantization levels exist at many positions in the RRC. In such applications, a large Rice parameter requires fewer bins to represent the remaining levels. The derivation scheme of the Rice parameters in VVCv1 may not be optimal for VVCv2 applications. Therefore, an alternative Rice parameter derivation can be adopted, which can be signaled by sps_rrc_rice_extension_flag. When sps_rrc_rice_extension_flag is equal to 1, it specifies that an alternative Rice parameter derivation is used for the binarization of abs_remaining[] and dec_abs_level[]. When sps_rrc_rice_extension_flag is equal to 0, it specifies that an alternative Rice parameter derivation is not used for the binarization of abs_remaining[] and dec_abs_level[]. If not present, the value of sps_rrc_rice_extension_flag is inferred to be equal to 0.

[0162] The following shows an example of determining Rice parameters using sps_rrc_rice_extension_flag in VVCv2. Given an array AbsLevel[x][y] of a transform block with component index cIdx and the luminance position (x0, y0) of the top-left corner, derive the variable locSumAbs according to the rules in the following pseudocode process (the underlined parts are the added contents of VVCv2 over VVCv1):

[0163]

number

[0164]

number

[0165]

number

[0166]

number

[0167]

number

[0168]

number

[0169] [Table 17]

[0170] From equation (1526X3), we can see that the cRiceParam used to binarize the remaining part of the absolute level in VVCv2 can be larger compared to VVCv1.

[0171] About gci_no_persistent_rice_adaptation_constraint_flag gci_no_persistent_rice_adaptation_constraint_flag conveys constraints on the derivation of Rice parameters for binarization using previous TU states. When gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it specifies that sps_persistent_rice_adaptation_enabled_flag is equal to 0 for all pictures in OlsInScope. When gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, no such constraint is imposed. When gci_no_persistent_rice_adaptation_constraint_flag is not present, its value is inferred to be equal to 0.

[0172] sps_persistent_rice_adaptation_enabled_flag equal to 1 specifies that at the beginning of each TU, the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is initialized using the statistical data accumulated from the previous TU. sps_persistent_rice_adaptation_enabled_flag equal to 0 specifies that the previous TU state is not used in the Rice parameter derivation. If not present, the value of sps_persistent_rice_adaptation_enabled_flag equal to 0 is inferred. Below is an example of determining Rice parameters using sps_persistent_rice_adaptation_enabled_flag in VVCv2 (the underlined parts are the additions of VVCv2 over VVCv1):

[0173] If the CTU is the first CTU in a slice or tile, invoke the context variable initialization process as specified in subclause 9.3.2.2, initialize the array PredictorPaletteSize[chType] (chType=0, 1) to 0, and initialize the array StatCoeff[i] (i=0..2) as follows:

[0174]

number

[0175] About gci_no_reverse_last_sig_coeff_constraint_flag If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope have sps_reverse_last_sig_coeff_enabled_flag equal to 0. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, no such constraint is imposed. If gci_no_reverse_last_sig_coeff_constraint_flag is not present, its value equal to 0 is inferred.

[0176] In regular residual coding (RRC), the position (x,y) of the last non-zero level in a TU is coded using up to four syntax elements: last_sig_coeff_x_prefix, last_sig_coeff_y_prefix, last_sig_coeff_x_suffix, and last_sig_coeff_y_suffix. In VVCv1, the difference between (x,y) of the current TU and (0,0) is used to code this position. This is reasonable for VVCv1 because there are many zero levels in a TU and most non-zero levels are located in the top left corner of the TU. However, for VVCv2 applications, this may not be the case and many non-zero levels are spread throughout the TU, so it may be more beneficial to code this position (x,y) relative to the bottom right corner instead of the top left corner (0,0). sh_reverse_last_sig_coeff_flag provides a tool to handle such applications.

[0177] If sh_reverse_last_sig_coeff_flag is equal to 1, it specifies that for each transform block of the current slice, the coordinates of the last significant coefficient are coded relative to ((Log2ZoTbWidth<<1)-1, (Log2ZoTbHeight<<1)-1). If sh_reverse_last_sig_coeff_flag is equal to 0, it specifies that for each transform block of the current slice, the coordinates of the last significant coefficient are coded relative to (0,0). If not present, the value of sh_reverse_last_sig_coeff_flag is inferred to be equal to 0.

[0178] In the slice header, sh_reverse_last_sig_coeff_flag is used to conditionally parse sps_reverse_last_sig_coeff_enabled_flag as follows:

[0179] -If last_sig_coeff_x_suffix does not exist,

number

number

[0180]

number

[0181]

number

[0182]

number

[0183]

number

[0184] VVCv2 slice header [Table 18]

[0185] FIG. 5 illustrates an example of a video decoding process 500 according to some embodiments of the present disclosure. One or more computing devices execute appropriate program code to implement the operations illustrated in FIG. 5. For example, a computing device implementing the video decoder 200 may execute the program code to implement the operations illustrated in FIG. 5. The computing device may include, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, an in-loop filter module 220, an inter prediction module 224, and an intra prediction module 226. For illustrative purposes, the process 500 will be described with reference to some examples illustrated in the figure. However, other implementations are possible.

[0186] In step 502, the process 500 includes accessing a bitstream of a video signal (e.g., the encoded video 202). In step 504, the process 500 includes extracting a common constraint information (GCI) flag from the bitstream of the video. As described above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. When gci_present_flag is equal to 1, it specifies that the GCI syntax element is present in the general_constraints_info() syntax structure and that the GCI syntax element is used to indicate constraints to be applied to additional encoding tools. When gci_present_flag is equal to 0, it specifies that the GCI syntax element is not present and that no common constraints are applied to the video. Depending on the encoder, the GCI flag can be extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

[0187] At step 506, process 500 includes determining whether the video is subject to one or more common constraints based on the value of the GCI flag. If so (i.e., the GCI flag is 1), then at step 508, process 500 includes extracting from the video bitstream a value M representing the number of additional bits included in the video bitstream. These additional bits include flag bits that respectively indicate that each additional encoding tool has been constrained for the video.

[0188] At step 510, the process 500 includes determining whether M is greater than 5. If so, at step 512, the process 500 extracts six flag bits from the bitstream, the six flag bits representing flags indicating constraints for each of the six additional coding tools: a flag gci_all_rap_pictures_constraint_flag indicating that pictures of the video are restricted to be Intra Random Access Point (IRAP) pictures or Gradual Decoded Refresh (GDR) pictures, a flag gci_no_extended_precision_processing_constraint_flag indicating whether extended transform precision is constrained, a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether explicit Rice parameter transmission is constrained, and a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether quantization of the video is constrained. The flags include a flag gci_no_rrc_rice_extension_constraint_flag indicating an alternative Rice parameter derivation to be used to binarize the residual, a flag gci_no_persistent_rice_adaptation_constraint_flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit, and a flag gci_no_reverse_last_sig_coeff_constraint_flag indicating whether to apply constraints to pictures in OlsInScope when decoding the position of the last non-zero level in the TU.

[0189] If M is greater than 6, then in step 513, the process 500 includes extracting and discarding the remaining M-6 bits from the bitstream, i.e., the video decoding is performed without relying on these M-6 bits.

[0190] At step 514, the process 500 includes decoding the remaining portion of the video bitstream into pictures based on the constraints indicated by the six flags for the six additional encoding tools. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder may determine that all pictures in the one or more output layer sets are GDR pictures or IRAP pictures with ph_recovery_poc_cnt equal to 0, and decode the GDR or IRAP pictures in the one or more output layer sets. If the flag gci_no_extended_precision_processing_constraint_flag is 1, the decoder may determine that the extended transform precision is constrained and decode the video by setting sps_extended_precision_flag of the pictures in OlsInScope to 0 to not use extended dynamic range. If the flag gci_no_ts_residual_coding_rice_constraint_flag is 1, the decoder may determine that explicit Rice parameter transmission is constrained and may decode the remainder of the video bitstream by disabling alternative Rice parameter transmission for pictures in OlsInScope. If the flag gci_no_rrc_rice_extension_constraint_flag is 1, the decoder may determine that alternative Rice parameter derivation used to binarize the quantized residual of the video is constrained and may decode the remainder of the video bitstream by disabling alternative Rice parameter transmission for pictures in OlsInScope. If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder may determine that initialization of Rice parameter derivation for binarization based on previous transform unit state is constrained and may decode the remainder of the video bitstream without initializing Rice parameters based on previous transform unit state for pictures in OlsInScope.If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder determines that sps_reverse_last_sig_coeff_enabled_flag of all pictures in OlsInScope is equal to 0 and that for each transform block of the current slice, the coordinates of the last significant coefficient are coded relative to the upper left corner (0,0), interprets the coordinates of the decoded last significant coefficient as being relative to the upper left corner (0,0) of each transform block of the current slice, and can decode the remainder of the video bitstream.

[0191] If it is determined in step 510 that M is less than or equal to 5, then in step 518, the process 500 includes extracting and discarding the M bits from the bitstream. That is, the decoding of the video is performed without relying on the M bits. In step 520, the decoder decodes the video without constraining the six additional encoding tools. If it is determined in step 506 that the GCI flag indicates that the video is not common constrained (i.e., the GCI flag is 0), then the process 500 includes decoding the video into pictures without common constraints. In some examples, the decoding is performed according to the process described above with respect to FIG. 2. The decoded video may be output for display.

[0192] FIG. 6 illustrates another example of a video decoding process 600 according to some embodiments of the present disclosure. One or more computing devices execute appropriate program code to implement the operations illustrated in FIG. 6. For example, a computing device implementing the video decoder 200 may execute the program code to implement the operations illustrated in FIG. 6. The computing device may include, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, an in-loop filter module 220, an inter prediction module 224, and an intra prediction module 226. For illustrative purposes, the process 600 will be described with reference to some examples illustrated in the figure. However, other implementations are possible.

[0193] In step 602, the process 600 includes accessing a bitstream of a video signal (e.g., the encoded video 202). In step 604, the process 600 includes extracting a common constraint information (GCI) flag from the bitstream of the video. As described above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. When gci_present_flag is equal to 1, it specifies that the GCI syntax element is present in the general_constraints_info() syntax structure and that the GCI syntax element is used to indicate constraints to be applied to additional encoding tools. When gci_present_flag is equal to 0, it specifies that the GCI syntax element is not present and that no common constraints are applied to the video. Depending on the encoder, the GCI flag can be extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

[0194] At step 606, process 600 includes determining whether the video is subject to one or more common constraints based on the value of the GCI flag. If so (i.e., the GCI flag is 1), then at step 608, process 600 includes extracting from the video bitstream a value M that represents the number of additional bits included in the video bitstream. These additional bits include flag bits that respectively indicate that each additional encoding tool has been constrained for the video.

[0195] At step 610, the process 600 includes determining whether M is greater than 6. If so, at step 612, the process 600 extracts six flag bits from the bitstream, the six flag bits representing flags indicating constraints for each of the six additional coding tools. The six flags are a flag gci_all_rap_pictures_constraint_flag indicating that pictures of the video are restricted to be Intra Random Access Point (IRAP) pictures or Gradual Decoded Refresh (GDR) pictures, a flag gci_no_extended_precision_processing_constraint_flag indicating whether extended transform precision is constrained, a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether explicit Rice parameter transmission is constrained, and a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether explicit Rice parameter transmission is constrained. The flags include a flag gci_no_rrc_rice_extension_constraint_flag indicating an alternative Rice parameter derivation to be used to binarize the residual, a flag gci_no_persistent_rice_adaptation_constraint_flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit, and a flag gci_no_reverse_last_sig_coeff_constraint_flag indicating whether to apply constraints to pictures in OlsInScope when decoding the position of the last non-zero level in the TU.

[0196] In step 614, the process 600 includes extracting the M-6 bits after the six flag bits from the bitstream and discarding the extracted M-6 bits. That is, the video decoding is performed without relying on the M-6 bits. In step 616, the process 600 includes decoding the remaining part of the video bitstream into pictures based on the constraints indicated by the six flags for the six additional encoding tools. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder can determine that all pictures in the one or more output layer sets are GDR pictures or IRAP pictures with ph_recovery_poc_cnt equal to 0, and decode the GDR pictures or IRAP pictures in the one or more output layer sets. If the flag gci_no_extended_precision_processing_constraint_flag is 1, the decoder may determine that the extended transform precision is constrained and may decode the video by setting sps_extended_precision_flag to 0 for pictures in OlsInScope to not use extended dynamic range. If the flag gci_no_ts_residual_coding_rice_constraint_flag is 1, the decoder may determine that the explicit Rice parameter transmission is constrained and may decode the remaining parts of the video bitstream by disabling alternative Rice parameter transmission for pictures in OlsInScope. If the flag gci_no_rrc_rice_extension_constraint_flag is 1, the decoder may determine that the alternative Rice parameter derivation used to binarize the quantized residual of the video is constrained and may decode the remaining parts of the video bitstream by disabling alternative Rice parameter transmission for pictures in OlsInScope.If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder determines that initialization of Rice parameter derivation for binarization based on previous transform unit state is constrained, and may decode the remaining part of the video bitstream without initializing Rice parameters based on previous transform unit state for pictures in OlsInScope. If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder determines that sps_reverse_last_sig_coeff_enabled_flag of all pictures in OlsInScope is equal to 0 and for each transform block of the current slice, the coordinates of the last significant coefficient are coded relative to the top-left corner (0,0), interprets the coordinates of the decoded last significant coefficient as being relative to the top-left corner (0,0) of each transform block of the current slice, and may decode the remaining part of the video bitstream.

[0197] If it is determined in step 610 that M is less than or equal to 6, then M is 0 or 6. If M is 6, then in step 620, the process 600 includes extracting the six flag bits as described above. In step 622, the decoder decodes the video based on the extracted flag bits by constraining the six additional encoding tools. If M is 0, then no flag bits are extracted. In step 624, the decoder decodes the video without constraining the six additional encoding tools because no flag bits have been extracted. If it is determined in step 606 that the GCI flag indicates that the video is not to be common-constrained (i.e., the GCI flag is 0), then in step 618, the process 600 includes decoding the video into pictures without common constraints. In some examples, the decoding is performed according to the process described above with respect to FIG. 2. The decoded video may be output for display.

[0198] FIG. 7 illustrates another example of a video decoding process 700 according to some embodiments of the present disclosure. One or more computing devices execute appropriate program code to implement the operations illustrated in FIG. 7. For example, a computing device implementing the video decoder 200 may execute the program code to implement the operations illustrated in FIG. 7. The computing device may include, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, an in-loop filter module 220, an inter prediction module 224, and an intra prediction module 226. For illustrative purposes, the process 700 will be described with reference to some examples illustrated in the figure. However, other implementations are possible.

[0199] At step 702, the process 700 includes accessing a bitstream of a video signal (e.g., the encoded video 202). At step 704, the process 700 includes extracting a common constraint information (GCI) flag from the bitstream of the video. As described above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. When gci_present_flag is equal to 1, it specifies that a GCI syntax element is present in the general_constraints_info() syntax structure and that the GCI syntax element is used to indicate constraints to be applied to additional encoding tools. When gci_present_flag is equal to 0, it specifies that the GCI syntax element is not present and that no common constraints are applied to the video. Depending on the encoder, the GCI flag can be extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

[0200] At step 706, process 700 includes determining whether the video is subject to one or more common constraints based on the value of the GCI flag. If so (i.e., the GCI flag is 1), then at step 708, process 700 includes extracting from the video bitstream a value M that represents the number of additional bits included in the video bitstream. These additional bits include flag bits that respectively indicate that each additional encoding tool has been constrained for the video.

[0201] In step 710, the process 700 includes determining whether M is greater than 5. If not, in step 712, the process 700 includes extracting M bits from the bitstream and discarding the M bits. In step 714, the process 700 includes decoding the remaining portion of the video bitstream into pictures without relying on the M bits. If in step 710, it is determined that M is less than or equal to 5, in step 718, the process 700 includes extracting the six flag bits described above. If M is greater than 6, in step 719, the process 700 includes extracting and discarding the remaining M-6 bits from the bitstream. That is, the video decoding is performed without relying on the M-6 bits. In step 720, the decoder decodes the video based on the extracted six flag bits by constraining the six additional coding tools, as described above.

[0202] If, at step 706, it is determined that the GCI flag indicates that the video is not to be commonly constrained (i.e., the GCI flag is 0), then process 700 includes decoding the video into pictures without common constraints. In some examples, the decoding is performed according to the process described above with respect to Figure 2. The decoded video may be output for display.

[0203] Example of a computing system for implementing transmission of common constraint information Any suitable computing system may be used to perform the operations described herein. For example, FIG. 8 illustrates an example of a computing device 800 that may implement the video encoder 100 of FIG. 1 or the video decoder 200 of FIG. 2. In some embodiments, the computing device 800 may include a processor 812 that is communicatively coupled to a memory 814 and that executes computer-executable program code and / or accesses information stored in the memory 814. The processor 812 may include a microprocessor, an application specific integrated circuit ("ASIC"), a state machine, or other processing device. The processor 812 may include any one of a number of processing devices. Such a processor may include or be in communication with a computer-readable medium that stores instructions that, when executed by the processor 812, cause the processor to perform the steps described herein.

[0204] The memory 814 may include any suitable non-transitory computer-readable medium. The computer-readable medium may include any electronic, optical, magnetic, or other storage device capable of providing computer-readable instructions or other program code to a processor. Non-limiting examples of computer-readable media include magnetic disks, memory chips, ROM, RAM, ASICs, configured processors, optical memory, magnetic tape or other magnetic storage, or any other medium from which a computer processor can read instructions. The instructions may include processor-specific instructions generated by a compiler and / or interpreter based on code written in any suitable computer programming language (including, for example, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, ActionScript, and the like).

[0205] The computing device 800 may further include a bus 816. The bus 816 may communicatively couple one or more components of the computing device 800. The computing device 800 may further include a number of external or internal devices, such as input or output devices, for example, the illustrated computing device 800 includes an input / output ("I / O") interface 818, which may receive input from one or more input devices 820 or provide output to one or more output devices 822. The one or more input devices 820 and the one or more output devices 822 may be communicatively coupled to the I / O interface 818. Such communicative coupling may be realized in any suitable manner (e.g., connection via a printed circuit board, connection via a cable, communication via wireless transmission, etc.). Non-limiting examples of input devices 820 include a touchscreen (e.g., one or more cameras for photographing the touched area, or a pressure sensor for detecting pressure changes caused by a touch), a mouse, a keyboard, or any other device for generating input events in response to physical movements of a user of the computing device. Non-limiting examples of output devices 822 include an LCD screen, an external monitor, speakers, or any other device for displaying or otherwise presenting output generated by the computing device.

[0206] The computing device 800 may execute program code that causes the processor 812 to perform one or more steps described above with respect to Figures 1-7. The program code may include the video encoder 100 or the video decoder 200. The program code may reside in the memory 814 or any suitable computer-readable medium and may be executed by the processor 812 or any other suitable processor.

[0207] The computing device 800 may further include at least one network interface device 824. The network interface devices 824 may include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks 828. Non-limiting examples of the network interface devices 824 include Ethernet network adapters, wireless modems, and / or similar devices. The computing device 800 may transmit messages via the network interface devices 824 as electronic or optical signals.

[0208] General Considerations Numerous details are described herein to provide a thorough understanding of the claimed subject matter. However, as will be understood by those skilled in the art, the claimed subject matter may be practiced without these details. In other instances, methods, apparatuses, or systems known to those skilled in the art have not been described in detail so as not to obscure the claimed subject matter.

[0209] Unless otherwise indicated, terms such as "processing," "computing," "calculating," "determining," "identifying," and the like are used herein to describe operations or processes of a computing device (e.g., one or more computers or similar electronic computing devices) that manipulate or transform data represented as physical electronic or magnetic quantities in the memory, registers, or other information storage, transmission, or display devices of the computing platform.

[0210] The systems described herein are not limited to any particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide results conditioned on one or more inputs. Suitable computing devices include general-purpose computer systems based on microprocessors that access stored software that programs or configures a computing system from a general-purpose computing device to a special-purpose computing device that implements one or more embodiments of the subject matter herein. Any suitable programming, scripting, or other type of language or combination of languages ​​can be used to implement the teachings contained herein in software that is configured to program or configure a computing device.

[0211] The method embodiments disclosed herein may be performed by operation of such a computing device. The order of steps shown in the above examples may be changed, e.g., steps may be reordered, combined, or divided into sub-steps. Some steps or processes may be performed in parallel.

[0212] As used herein, "applied to" or "configured to" is open and inclusive language and does not exclude equipment adapted or configured to perform additional tasks or steps. Additionally, the use of "based on" is open and inclusive because a process, step, calculation, or other operation "based on" one or more recited conditions or values ​​may in fact be based on additional conditions or values ​​beyond those recited. The headings, lists, and numbering contained herein are for ease of description only and are not intended to be limiting.

[0213] Although the subject matter herein has been described in detail with respect to specific embodiments thereof, it should be understood that those skilled in the art, after understanding the foregoing, may readily effect modifications, variations, and equivalents to such embodiments. It should therefore be understood that the present disclosure is presented for purposes of illustration and not limitation, and does not exclude the inclusion of such modifications, variations, and / or additions to the subject matter herein that may be readily effected by those skilled in the art.

Claims

1. 1. A video decoding method comprising: decoding a count M of extra bits from a video bitstream, the count M of extra bits indicating a number of extra common constraint information (GCI) bits included in the video bitstream, the extra bits including flag bits indicating each extra coding tool to be constrained for the video, and an expected value of the count M of extra bits being 0, 6, or greater than 6; in response to determining that the count M of decoded additional bits is greater than six, decoding M-6 bits in the bitstream after six flag bits; decoding the remainder of the video bitstream into pictures, independent of the decoded M-6 bits, and based at least in part on constraints specified for each additional encoding tool by the six flag bits.

2. The video decoding method includes: decoding, from the video bitstream, six flag bits respectively representing six flags, the six flags respectively indicating six additional coding tools constrained to the video, before decoding the M-6 bits; and decoding a remainder of the video bitstream into pictures based at least in part on constraints indicated by the six flags to the six additional encoding tools. The video decoding method of claim 1 .

3. The six flags are: a first flag indicating that pictures of the video are restricted to be Intra Random Access Point (IRAP) pictures or Gradual Decoding Refresh (GDR) pictures; a second flag indicating whether the extended conversion precision is constrained; a third flag indicating whether explicit Rice parameter transmission is constrained; a fourth flag indicating an alternative Rice parameter derivation for binarization of the quantized residual of the video; a fifth flag indicating whether to initialize Rice parameter derivation for binarization based on the previous transform unit; a sixth flag indicating whether to constrain pictures in the in-scope output layer set (OlsInScope) when decoding the position of the last non-zero level in the transform unit; The video decoding method of claim 2.

4. decoding a remainder of the video bitstream into pictures based at least in part on constraints indicated by the six flags to the six additional encoding tools; determining, based on the first flag being 1, that all pictures in one or more output layer sets are GDR pictures or IRAP pictures with ph_recovery_poc_cnt equal to 0, and decoding the GDR pictures or the IRAP pictures in the one or more output layer sets; determining that the extended transform precision is constrained based on the second flag being 1, and setting sps_extended_precision_flag of pictures in the in-scope output layer set (OlsInScope) to 0 so that extended dynamic range is not used, and decoding the remaining portion of the video bitstream; determining that explicit Rice parameter transmission is constrained based on the third flag being one, disabling alternative Rice parameter transmission for pictures in an output layer set (OlsInScope) within the scope, and decoding a remainder of the video bitstream; determining, based on the fourth flag being one, that alternative Rice parameter derivation for binarization of the quantized residual of the video is constrained, and disabling alternative Rice parameter transmission for pictures in an in-scope output layer set (OlsInScope) and decoding a remaining portion of the video bitstream; determining, based on determining that the fifth flag is one, that initialization of Rice parameter derivation for binarization based on a previous transform unit state is constrained, and decoding a remainder of the video bitstream without initializing Rice parameters based on a previous transform unit state for pictures in an output layer set (OlsInScope) within the scope; or determining, based on the sixth flag being 1, that the coordinates of the last significant coefficient are coded relative to the top-left corner of each transform block of the slice; and interpreting the decoded coordinates of the last significant coefficient as being relative to the top-left corner of each transform block of the slice, thereby decoding the remaining portion of the video bitstream. The video decoding method of claim 3.

5. The video decoding method includes: determining that the first flag is not present in the bitstream and inferring a value of the first flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the second flag is not present in the bitstream and inferring a value of the second flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the third flag is not present in the bitstream and inferring a value of the third flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the fourth flag is not present in the bitstream and inferring a value of the fourth flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the fifth flag is not present in the bitstream and inferring a value of the fifth flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the sixth flag is not present in the bitstream and inferring a value of the sixth flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool. The video decoding method of claim 3.

6. Before decoding the count M of additional bits, the video decoding method comprises: decoding a common constraint information (GCI) flag from the video bitstream; and determining, based on the value of the GCI flag, that the video is subject to one or more common constraints; The video decoding method of claim 1 .

7. the GCI flag is decoded from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video; The video decoding method of claim 6.

8. A video encoding method comprising: determining a count M of additional bits, the count M of additional bits indicating a number of additional common constraint information (GCI) bits included in a video bitstream, the additional bits including flag bits indicating each additional coding tool to be constrained for the video, and an expected value of the count M of additional bits being 0, 6, or greater than 6; encoding said additional bits and said additional bits into a bitstream; encoding the video based at least in part on constraints specified for each additional encoding tool by six flag bits; Video coding methods.

9. The six flags are: a first flag indicating that pictures of the video are restricted to be Intra Random Access Point (IRAP) pictures or Gradual Decoding Refresh (GDR) pictures; a second flag indicating whether the extended conversion precision is constrained; a third flag indicating whether explicit Rice parameter transmission is constrained; a fourth flag indicating an alternative Rice parameter derivation for binarization of the quantized residual of the video; a fifth flag indicating whether to initialize Rice parameter derivation for binarization based on the previous transform unit; a sixth flag indicating whether to constrain pictures in the in-scope output layer set (OlsInScope) when decoding the position of the last non-zero level in the transform unit; 9. The video encoding method of claim 8.

10. Encoding the video based at least in part on constraints specified for each additional encoding tool by the six flag bits, comprising: if determining that all pictures in one or more output layer sets are GDR pictures or IRAP pictures, setting the first flag to 1 and encoding the video; if determining to constrain the extended transform precision, setting the second flag to 1 and encoding the video; if determining to restrict explicit Rice parameter transmission, setting the third flag to 1 and encoding the video; if determining to constrain an alternative Rice parameter derivation for binarization of a quantized residual of the video, setting the fourth flag to 1 and encoding the video; if determining to constrain initialization of Rice parameter derivation for binarization based on a previous transform unit state, setting the fifth flag to 1 and encoding the video; if it is determined that the coordinates of the last significant coefficient are to be coded relative to the top-left corner of each transform block of a slice, setting the sixth flag to 1 and coding the video.

10. The video encoding method of claim 9.

11. The video encoding method according to claim 1 determining a common constraint information (GCI) flag and encoding the GCI flag, the GCI flag indicating that the video is subject to one or more common constraints; 9. The video encoding method of claim 8.

12. The encoding of the GCI flag: encoding the GCI flag into a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

12. The video encoding method of claim 11.

13. 13. A non-transitory computer readable medium storing program code and a bitstream, the program code causing one or more processing devices to perform the video encoding method of any one of claims 8 to 12 and to generate the bitstream.

14. 1. A system comprising: Processing equipment; and a non-transitory computer-readable medium communicatively coupled to the processing device, the processing device configured to perform operations by executing program code stored on the non-transitory computer-readable medium, the operations including: decoding a count M of extra bits from a video bitstream, the count M of extra bits indicating a number of extra common constraint information (GCI) bits included in the video bitstream, the extra bits including flag bits indicating each extra coding tool to be constrained for the video, and an expected value of the count M of extra bits being 0, 6, or greater than 6; in response to determining that the count M of decoded additional bits is greater than six, decoding M-6 bits in the bitstream after six flag bits; decoding the remaining portion of the video bitstream into pictures, independent of the decoded M-6 bits and based at least in part on constraints specified for each additional encoding tool by the six flag bits.

15. The operation is decoding, from the video bitstream, six flag bits respectively representing six flags, the six flags respectively indicating six additional coding tools constrained to the video, before decoding the M-6 bits; and decoding a remainder of the video bitstream into pictures based at least in part on constraints indicated by the six flags to the six additional encoding tools. The system of claim 14.

16. The six flags are: a first flag indicating that pictures of the video are restricted to be Intra Random Access Point (IRAP) pictures or Gradual Decoding Refresh (GDR) pictures; a second flag indicating whether the extended conversion precision is constrained; a third flag indicating whether explicit Rice parameter transmission is constrained; a fourth flag indicating an alternative Rice parameter derivation for binarization of the quantized residual of the video; a fifth flag indicating whether to initialize Rice parameter derivation for binarization based on the previous transform unit; a sixth flag indicating whether to constrain pictures in the in-scope output layer set (OlsInScope) when decoding the position of the last non-zero level in the transform unit; The system of claim 15.

17. decoding a remainder of the video bitstream into pictures based at least in part on constraints indicated by the six flags to the six additional encoding tools; determining, based on the first flag being 1, that all pictures in one or more output layer sets are GDR pictures or IRAP pictures with ph_recovery_poc_cnt equal to 0, and decoding the GDR pictures or the IRAP pictures in the one or more output layer sets; determining that the extended transform precision is constrained based on the second flag being 1, and setting sps_extended_precision_flag of pictures in the in-scope output layer set (OlsInScope) to 0 so that extended dynamic range is not used, and decoding the remaining portion of the video bitstream; determining that explicit Rice parameter transmission is constrained based on the third flag being one, disabling alternative Rice parameter transmission for pictures in an output layer set (OlsInScope) within the scope, and decoding a remainder of the video bitstream; determining, based on the fourth flag being one, that alternative Rice parameter derivation for binarization of the quantized residual of the video is constrained, and disabling alternative Rice parameter transmission for pictures in an in-scope output layer set (OlsInScope) and decoding a remaining portion of the video bitstream; determining, based on determining that the fifth flag is one, that initialization of Rice parameter derivation for binarization based on a previous transform unit state is constrained, and decoding a remainder of the video bitstream without initializing Rice parameters based on a previous transform unit state for pictures in an output layer set (OlsInScope) within the scope; or determining, based on the sixth flag being 1, that the coordinates of the last significant coefficient are coded relative to the top-left corner of each transform block of the slice; and interpreting the decoded coordinates of the last significant coefficient as being relative to the top-left corner of each transform block of the slice, thereby decoding the remaining portion of the video bitstream.

17. The system of claim 16.

18. The operation is determining that the first flag is not present in the bitstream and inferring a value of the first flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the second flag is not present in the bitstream and inferring a value of the second flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the third flag is not present in the bitstream and inferring a value of the third flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the fourth flag is not present in the bitstream and inferring a value of the fourth flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the fifth flag is not present in the bitstream and inferring a value of the fifth flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool; determining that the sixth flag is not present in the bitstream and inferring a value of the sixth flag to be 0, indicating that no constraint is imposed on the corresponding encoding tool.

17. The system of claim 16.

19. Before decoding the count M of additional bits, the operation comprises: decoding a common constraint information (GCI) flag from the bitstream of the video by decoding the GCI flag from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video; and determining, based on the value of the GCI flag, that the video is subject to one or more common constraints; The system of claim 14.

20. The common constraint information (GCI) flag is decoded from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

20. The system of claim 19.

Images