Signaling general constraint information for video coding

Abstract

In some embodiments, a video decoder decodes a video based on a video bitstream. The video decoder accesses the video bitstream and extracts a general constraint information (GCI) flag from the video bitstream. The decoder determines that one or more general constraints are imposed on the video based on a value of the GCI flag, and extracts a value from the video bitstream indicating a number of additional bits included in the video bitstream. The additional bits include flag bits, which indicate corresponding additional encoding tools constrained for the video. If the value is greater than 5, the decoder extracts six flags from the video bitstream, which indicate corresponding constraints of the six additional encoding tools. The decoder decodes the video bitstream into an image based on the constraints of the six additional encoding tools indicated by the six flags.

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 and entitled "Signaling Methods for General Constraints Information for Video Coding," U.S. Provisional Application No. 63 / 266,616, filed January 10, 2022 and entitled "Initialization Method for General Constraint Information Flags for Video Coding," and U.S. Provisional Application No. 63 / 266,765, filed January 13, 2022 and entitled "Signaling and Initialization Methods for General Constraints Information for Video Coding," the entire contents of which are incorporated herein by reference.

[0002] The present invention relates generally to video processing and, more particularly, to signaling and initializing general constraint information for video encoding. [Background technology]

[0003] The widespread use of camera-equipped devices such as smartphones, tablet computers, and computers has made it easier than ever to take videos or images. However, even a short video can 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 over 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 signaling and initializing general constraint information for video encoding. In one example, a video decoding method includes extracting a general constraint information (GCI) flag from a video bitstream, determining based on a value of the GCI flag that one or more general constraints are imposed on the video, extracting from the video bitstream a value indicating a number of additional bits included in the video bitstream in response to determining that one or more general constraints are imposed on the video, the additional bits including flag bits indicating corresponding additional encoding tools constrained for the video, determining that the value is greater than 5, extracting from the bitstream six flag bits representing six corresponding flags in response to determining that the value is greater than 5, the six corresponding flags indicating corresponding constraints of the six additional encoding tools, and decoding a remaining portion of the video bitstream into an image based at least in part on the constraints of the six additional encoding tools indicated by the six flags.

[0005] In another example, a non-transitory computer readable medium has program code stored thereon that can cause one or more processing devices to perform operations including: extracting a general constraint information (GCI) flag from a video bitstream; determining based on a value of the GCI flag that one or more general constraints are imposed on the video; in response to determining that one or more general constraints are imposed on the video, extracting from the video bitstream a value indicative of a number of additional bits included in the video bitstream, the additional bits including flag bits, the flag bits indicating corresponding additional encoding tools constrained to the video; determining that the value is greater than five; in response to determining that the value is greater than five, extracting from the bitstream six flag bits representing six corresponding flags, the six corresponding flags indicating corresponding constraints of the six additional encoding tools; and decoding a remaining portion of the video bitstream into an image based at least in part on the constraints of the six additional encoding tools indicated by the six flags.

[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 include extracting a general constraint information (GCI) flag from the video bitstream; determining based on a value of the GCI flag that one or more general constraints are imposed on the video; in response to determining that the one or more general constraints are imposed on the video, extracting from the video bitstream a value indicating a number of additional bits included in the video bitstream, the additional bits including flag bits, the flag bits indicating corresponding additional encoding tools constrained to the video; determining that the value is greater than five; in response to determining that the value is greater than five, extracting from the bitstream six flag bits representing six corresponding flags, the six corresponding flags indicating corresponding constraints of the six additional encoding tools; and decoding a remaining portion of the video bitstream into an image based at least in part on the constraints of the six additional encoding tools indicated by the six flags.

[0007] These illustrative examples are not intended to limit or define the invention, but rather to provide examples to aid in understanding the invention. 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 embodiments provided herein. [Diagram 2] FIG. 2 is a block diagram illustrating an example of a video decoder configured to implement embodiments provided herein. [Diagram 3] 4 illustrates an example of a coding tree unit partitioning of an image in a video, according to some embodiments of the present invention. [Figure 4] 4 illustrates an example of a coding unit split of a coding tree unit according to some embodiments of the present invention. [Diagram 5] 4 illustrates an example video decoding process according to some embodiments of the present invention. [Figure 6] 4 illustrates another example of a video decoding process according to some embodiments of the present invention. [Figure 7] 4 illustrates another example of a video decoding process according to some embodiments of the present invention. [Figure 8] 1 illustrates an example computing system for implementing some embodiments of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0010] Various embodiments of signaling and initialization of general constraint information for video coding are provided. As mentioned above, more and more video data are generated, stored, and transmitted. It is beneficial not only to increase the efficiency of video coding technology, but also to increase the stability of video coding so that the video signal can be successfully decoded at the decoder side. Problems regarding the stability of video decoding include incompatibility and inconsistency problems. With the development of video coding technology, updated video coding standards are developed. One such video coding standard is the Versatile Video Coding standard version 1, which is jointly published by the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU), where it is published by ISO as "ISO / IEC 23090-3:2021 Information Technology - Coding Representation of Immersive Media - Part 3: Versatile Video Coding" and by ITU as "ITU-T H.266 Recommendation (August 2020): Versatile Video Coding". In the present invention, version 1 of the versatile video coding standard is also referred to as "VVC version 1" or "VVCv1". VVC version 1 is replaced by version 2 of the versatile video coding standard, which is to be jointly published by ISO and ITU, where it is 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 (April 2022): Versatile video coding". In the present invention, version 2 of the versatile video coding standard is also referred to as "VVC version 2" or "VVCv2". In order for a video decoder conforming to a new version of the video coding standard to be able to successfully decode a video signal coded using an earlier version of the 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 signaling of general constraint information used in the current draft of VVC version 2 causes desynchronization in video decoding, which is a serious incompatibility issue between different versions of the video coding standard.Furthermore, in the current draft of VVC version 2, the general constraint flags associated with the general constraint information may not be defined, which may cause ambiguity and inconsistency in decoder implementations. Various embodiments described herein introduce a signaling and initialization method for general constraint information for video coding to address these issues, thereby improving the stability of video coding.

[0011] In the VVC standard, the General Constraints 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, if a VVC Version 2 bitstream signals general constraint information (i.e., the value of gci_present_flag is 1) and the VVC Version 2 general constraint information consists of N additional coding tools that may be constrained, the syntax element gci_num_additional_bits corresponding to the N additional coding tools can only be set to a value of 0 or N. If gci_num_additional_bits is set to 0, the general constraint flags for the N additional coding tools are not signaled. If gci_num_additional_bits is set to N, the next N bits of the bitstream are used to signal the general constraint flags for the 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 general 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 values ​​greater than 0 and less than N, or greater than N. If M is greater than 0 but less than N, after decoding the gci_num_additional_bits syntax element, the decoder extracts M bits from the bitstream and discards the M bits. 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 general constraint flags for N additional coding tools. The decoder then further extracts (MN) bits from the bitstream and discards these (MN) bits. In another example, a VVC version 2 decoder does not need to process general constraint information that sets gci_num_additional_bits to a value greater than 0 but less than N. A legal VVC version 2 bitstream can only set gci_num_reserved_bits to a value of 0 or N. Bitstreams for future versions of VVC will not allow gci_num_additional_bits to be set to a value between 0 and N.

[0013] In some embodiments, initializing the general constraints information flag is used to address the above-mentioned decoder implementation ambiguity and inconsistency problems. 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 impose any constraints on the encoding tool associated with the general constraints information flag. In the example where the flag has a value of 0 to indicate no constraints, the absence of the general constraints information flag infers that the flag has a value of 0.

[0014] The embodiments described in this invention provide the following methods, which can signal and infer general constraint flags for additional coding tools in VVC version 2. Unlike the prior art, the high-level syntax bitstream generated by the methods described in this invention is compatible with VVC version 1 decoders and can be decoded without desynchronization between the operations of VVC version 1 and VVC version 2 decoders. The inference rules described in this invention remove ambiguity in VVC version 2 decoding operations of VVC version 2 GCI syntax elements. These techniques can be effective coding tools in various video coding standards.

[0015] Referring now to the drawings, Figure 1 is a block diagram illustrating an example of a video encoder 100 configured to implement embodiments provided herein. In the example illustrated in Figure 1, the video encoder 100 includes a partitioning module 112, a transform module 114, a quantization module 115, an inverse quantization 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 image buffer 130, and an entropy encoding module 116.

[0016] The input to the video encoder 100 is an input video 102 that includes a sequence of pictures (also called frames or images). In a block-based video encoder, for each image, the video encoder 100 divides the image into blocks 104 using a partition module 112, with each block including multiple pixels. The blocks may be macroblocks, coding tree units, coding units, prediction units, and / or prediction blocks. An image may include blocks of different sizes, and the block partitioning for different images of the video may be different. Each block may be coded using a different prediction (e.g., intra prediction, or inter prediction, or hybrid intra and inter prediction, etc.).

[0017] Typically, the first image of a video signal is an intra-coded image, which is coded using only intra-prediction. In the intra-prediction mode, a block of an image is predicted using only previously coded data from the same image. An intra-coded image can be decoded without information from other images. To perform intra-prediction, the video encoder 100 shown in FIG. 1 may employ 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 image. 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 applying a transform to 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 ​​are also called transform coefficients, which represent the residual block in the transform domain. In some examples, the residual block can be directly quantized without being transformed by the transform module 114. This 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 the samples by a quantization step size followed by rounding, and inverse quantization involves multiplying the quantized values ​​by the quantization step size. Such a quantization process is called scalar quantization. Quantization is used to reduce the dynamic range of video samples (transformed or untransformed) to reduce the number of bits used to represent the video samples.

[0020] Quantization of coefficients / samples within a block can be done independently, and this quantization method is used in some existing video compression standards (e.g., H.264, HEVC, etc.). For an N×M block, the 2D coefficients of the block can be converted to a 1-D array in some scan order for quantization and encoding of the coefficients. Quantization of coefficients within a block can use scan order information. For example, quantization of a given coefficient in a block can depend on the state of the previous quantized value along the scan order. To further increase the coding efficiency, multiple quantizers can be used. Which quantizer is used to quantize the current coefficient depends on the information preceding 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 applied 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 obtain and apply the quantization parameter for decoding.

[0022] The quantized samples are then encoded using an entropy encoding module 116 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 these binary bins into bits. Examples of binarization methods include, but are not limited to, a combination of truncated Rice (TR) and restricted k-th order Exponential-Golomb (EGk) binarization, k-th order Exp-Golomb (EGk) 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 explained above, the reconstructed block 136 from the neighboring blocks is used for intra prediction of the block of the image. 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 transformation 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 an 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 an inverse transform (such as an inverse DCT or an inverse DST) of the transform applied to the transform module 114 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. For blocks whose transform has been skipped, the inverse transform module 119 is not applied to these blocks. The dequantized samples are the reconstructed residual of the block.

[0024] Inter prediction or intra prediction can be used to encode blocks of subsequent images following an initial intra predicted image. In inter prediction, prediction of blocks in an image is performed based on one or more previously encoded video images. 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 compares the current block 104 of the current image with the decoded reference image 108 for motion estimation. The decoded reference image 108 is stored in the decoded image buffer 130. The motion estimation module 122 selects a reference block from the decoded reference image 108 that best matches the current block. The motion estimation module 122 further identifies an offset between the position (e.g., x, y coordinates) of the reference block and the position 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 for the current block are identified in multiple decoded reference images 108. Thus, multiple motion vectors are generated, and the motion vectors are 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 can identify a prediction block pointed to by the motion vector in a corresponding reference image based on the motion vector. When there are multiple prediction blocks, these prediction blocks are combined with some weights to generate a 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, reconstructed block 136 for an inter-predicted block is obtained by inverse quantizing, inverse transforming, and combining the residual with the corresponding predicted block 134.

[0028] To obtain the decoded image 108 used for motion estimation, the reconstruction block 136 is processed by an in-loop filter module 120. The in-loop filter module 120 is configured to smooth pixel transitions, 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 adaptive offset (SAO) filter, an adaptive loop filter (ALF), etc.

[0029] 2 illustrates an example of a video decoder 200 configured to implement embodiments provided herein. The video decoder 200 processes encoded video 202 in a bitstream to generate a decoded image 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 image buffer 230.

[0030] The entropy decoding module 216 is configured to perform entropy decoding of the encoded video 202. The entropy decoding module 216 decodes coding parameters, including quantized coefficients, intra-prediction parameters and inter-prediction parameters, and other information. In some examples, the entropy decoding module 216 decodes the bitstream of the encoded video 202 into a binary representation and then converts the binary representation into quantized levels of the coefficients. The entropy decoded coefficient levels are then inverse quantized by the inverse quantization module 218 and subsequently 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 in FIG. 1 above, respectively. The inverse transformed residual blocks can be added to the corresponding prediction blocks 234 to generate the reconstruction blocks 236. For blocks whose transforms have been skipped, the inverse transform module 219 is not applied to these blocks. 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 image can 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] As described above with respect to Figure 1, inter prediction involves one or more reference pictures. The video decoder 200 generates a decoded image 208 of the reference picture by applying an in-loop filter module 220 to a reconstructed block of the reference picture. The decoded image 208 is stored in a decoded picture buffer 230 for use by the inter prediction module 224 and for output.

[0033] Now, referring to FIG. 3, FIG. 3 illustrates an example of coding tree unit division of an image in a video according to some embodiments of the present invention. As described above with respect to FIG. 1 and FIG. 2, to code an image of a video, the image is divided into blocks, such as CTUs (coding tree units) 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 some order (e.g., the order shown in FIG. 3). In some examples, each CTU 302 in an image may be divided into one or more CUs (coding units) 402, as shown in FIG. 4, and the CUs 402 may be further divided into prediction units or transform units (TUs) for prediction and transformation. Depending on the coding 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 coded 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 obtained by dividing the root CTU 302 into blocks smaller than the root CTU 302, each of which is about 4x4 blocks in size. As shown in Fig. 4, methods for dividing a CTU 302 into CUs 402 in VVC include quad-tree division, binary tree division, and ternary tree division. In Fig. 4, the solid lines indicate quad-tree division, and the dashed lines indicate binary or ternary tree division.

[0034] General Restrictions Information for VVC Version 1 (VVCv1) In VVC version 1, the General 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. gci_present_flagf equal to 1 specifies that a GCI syntax element is present in the general_constraints_info() syntax structure. gci_present_flagf equal to 0 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 several contexts, the general constraint information can be signaled in a high-level syntax. For example, the GCI can be signaled in a network packet that contains only decoding capability information, such as a Network Abstraction Layer (NAL) packet that carries only decoding capability information and has its nal_unit_type set to 13 (i.e., the name of the nal_unit_type is set to DCI_NUT). Alternatively, the GCI can be signaled 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 regarding features required for decoding of a bitstream and to signal an interoperability point (IOP) that imposes restrictions other than those specified in the Profile, Tier and Level (PTL) 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 of decoder implementations that do not support all the features of a VVC profile but address the needs of a particular application. A decoder implementation can consult the GCI syntax elements to check if a bitstream avoids the use of certain features, to decide how to configure the decoding process, and to verify if the bitstream is decodable by the decoder. A decoder implementation that supports all the features of a VVC profile can ignore the GCI syntax element value, since such a decoder can decode all bitstreams that comply with the indicated PTL.

[0037] The general 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 the general constraints flag depends on the value of gci_present_flag: if the value of gci_present_flag is 1, the general constraints flag is present in the bitstream; if the value of gci_present_flag is 0, the general constraints flag is not present in the bitstream.

[0040] Besides the general constraint flags defined in VVCv1, additional general constraint flags can be provided by 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 signaled in the general 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 provision allows a VVCv1 decoder to be forward compatible with at least the high-level syntax part of bitstreams generated with later versions of VVC.

[0041] General Restrictions Information for VVC Version 2 (VVCv2) In 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), it is proposed that some additional coding tools be constrained by the general constraint flag. It is proposed to rename the 8-bit field called gc_num_reserved_bits in VVCv1 to gci_num_additional_bits. The proposed VVCv2 adjusted syntax is as follows:

[0042] [Table 2] There are a total of six additional general constraint flags: gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_rrs_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 proposed gci_num_additional_bits syntax element is as follows:

[0043] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be equal to 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or 1, decoders conforming to this version of the document shall allow values ​​of gci_num_additional_bits greater than 1 to appear 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.

[0044] If a VVCv2 bitstream signals general constraint information, it was proposed to set the syntax element gci_num_additional_bits to 0 if the six VVCv2 general constraint flags are not signaled, and to set gci_num_additional_bits to 1 if the six VVCv2 general constraint flags are signaled.

[0045] However, the VVCv2 specification of the proposed general constraint syntax above causes incompatibility with VVCv1 decoders. Specifically, when additional general constraint flags are signaled, the proposed VVCv2 syntax signals the general constraint flags by setting gci_num_additional_bits to 1. In a VVCv2 decoder, when general constraint information is signaled, the gci_num_additional_bits syntax element is decoded from the bitstream to an 8-bit unsigned integer. When 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 general constraint flags for additional decoding tools that may be constrained in VVCv2.

[0046] In a VVCv1 decoder, the same 8-bit field is interpreted as gci_num_reserved_bits. However, when that 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 desynchronization issues due to the presence of five additional bits in the bitstream that are not recognized by the VVCv1 specification.

[0047] As explained above, desynchronization is a significant incompatibility issue between different versions of video coding standards. A VVCv1 decoder may not be able to decode an entire VVCv2 bitstream because the VVCv2 bitstream may use coding tools that are defined in the VVCv2 specification but are unknown to the 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 not only the general constraint information but also the profile and tier information. Such information provides the decoder with hints on the capabilities required to decode the bitstream. For example, the general constraint information provides the decoder with an indication as to which coding tools are constrained by 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.

[0048] 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, if a desynchronization occurs during the decoding of a high-level syntax, the information provided in the high-level syntax may not be correctly decoded. In the worst case, the decoder may decode a completely incorrect value for the syntax element following the desynchronization event, which may lead to incorrect parameter settings and / or incorrect decoding of the subsequent lower-level syntax, causing the decoding to fail.

[0049] Furthermore, in a VVCv2 decoder, when general constraint information is signaled, the gci_num_additional_bits syntax element is decoded from the bitstream to an 8-bit unsigned integer. If gci_num_additional_bits is decoded to a value of 0, no further general constraint flags are signaled. In this case, no inferred value is specified for the additional general constraint flags, and the value of the additional general constraint flags is undefined. Thus, the behavior of constraining or not constraining the encoding tools associated with the additional general constraint flags is ambiguous, which may lead to inconsistent decoder implementations.

[0050] 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 a reserved syntax element is written as a placeholder into a bitstream by an encoder, a default value is embedded in the name of the reserved syntax element. However, due to the design of the general constraint syntax structure, gci_reserved_zero_bit[i] is never written by an encoder. gci_reserved_zero_bit[i] is only used 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 problems.

[0051] Regarding signaling of general constraint information In one example of signaling general constraint information to solve the above-mentioned asynchronization problem, if the VVCv2 bitstream signals general constraint information (i.e., the value of gci_present_flag is 1) and the VVCv2 general constraint information is composed of N additional coding tools that may be restricted, the syntax element gci_num_additional_bits can only be set to a value of 0 or N. When gci_num_additional_bits is set to 0, the general constraint flags of the N additional coding tools are not signaled. When gci_num_additional_bits is set to N, the next N bits in the bitstream are used to signal the general constraint flags of the N additional coding tools. In one example, N is set to 6.

[0052] In the VVCv2 bitstream, it is not allowed to set gci_num_additional_bits to a value other than 0 or N. However, the VVCv2 decoder can process general 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 a value greater than 0 but less than N, or a value greater than N. Let the decoded value of gci_num_additional_bits be M. And when M is greater than 0 but 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 these M bits. When M is greater than N (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 general constraint flags for 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 these (M - N) bits.

[0053] In another example, a VVCv2 decoder does not need to process general constraint information that sets gci_num_additional_bits to a value greater than 0 but less than N. A legal VVCv1 bitstream can only set gci_num_reserved_bits to a value of 0. A legal VVCv2 bitstream can only set gci_num_additional_bits to a value of 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.

[0054] In one example of such an embodiment, the changes to the VVCv2 general constraint information syntax using the six general constraint flags currently proposed for the VVCv2 encoding tool are 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)".

[0055] [Table 3]

[0056] In one example, if six additional general constraint flags for encoding tools are present in VVCv2, the corresponding semantics of gci_num_additional_bits are as follows (additional content is shown in underline and removed content is shown in strikethrough):

[0057] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6gci_num_additional_bits is greater than 1. Other than 0 or 6 Values ​​are 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 However, decoders conforming to this version of the document may not include the syntax Other than 0 or 6 Allow the value of gci_num_additional_bits to be displayed and gci_num_additional_bits is greater than 1 Not 0 or 6 If so, the values ​​of all gci_reserved_zero_bit[i] syntax elements should be ignored.

[0058] In the above example of the semantics of gci_num_additional_bits, in addition to the values ​​0 or 6 described above, gci_num_additional_bits is permitted to take values ​​other than 0 or 6. That is, gci_num_additional_bits can take values ​​from 1 to 5. gci_num_additional_bits is also permitted to take values ​​greater than 6. If gci_num_additional_bits has a value from 1 to 5, indicated by M, then, according to the syntax shown in Table 1 above, the decoder skips the step executed when the "if" condition is true and jumps to the "else" step, assigning the value of "numAdditionalBitsUsed" to 0. Then, M bits are read and discarded in a "for" loop. In this way, the desynchronization problem can be avoided. If the value M of gci_num_additional_bits is greater than 6, extract 6 additional general constraint flags and further extract and discard the remaining M-6 bits.

[0059] In another example, if six additional general constraint flags for encoding tools are present in VVCv2, the corresponding semantics of gci_num_additional_bits are as follows (additional content is shown in underline and removed content is shown in strikethrough):

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

[0061] In another embodiment of signaling general constraint information, if a VVCv2 bitstream signals general constraint information (i.e., the value of gci_present_flag is 1) and the VVCv2 general constraint information consists of N additional coding tools that may be constrained, the syntax element gci_num_additional_bits can be set to a value of M, where M ranges from 0 to N (inclusive), with 0≦M≦N. If gci_num_additional_bits is set to 0, no general constraint flags for the N additional coding tools are signaled. If gci_num_additional_bits is set to a non-zero value M, the next M bits of the bitstream are used to signal general constraint flags for M additional coding tools out of the N additional coding tools. Which M additional coding tools are constrained is determined by the order in which the general constraint flags appear in the general constraint information syntax table.

[0062] In one example of such an embodiment, the modification of the VVCv2 general constraint information syntax using the six general constraint flags currently proposed for the VVCv2 encoding tool may be as follows:

[0063] [Table 4]

[0064] In another example of the embodiment, the equivalent behavior can be achieved using a more compact syntax table.

[0065] [Table 5]

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

[0067] If the six additional general constraint flags for encoding tools are present in VVCv2, the corresponding semantics of gci_num_additional_bits may be as follows:

[0068] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the 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 for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be in the range 0 to 6, inclusive, decoders conforming to this version of the document shall allow values ​​of gci_num_additional_bits greater than 6 to appear 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.

[0069] In this embodiment, depending on the value of gci_num_additional_bits, some or all of the additional general constraint flags may not be signaled. In one arrangement of this embodiment, if the VVCv2 bitstream signals general constraint information (i.e., the value of gci_present_flag is 1), no constraints are imposed on the encoding tools that correspond to the additional general constraint flags that are not signaled. This behavior can be expressed by changing the semantics of gci_num_additional_bits as follows:

[0070] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the 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 for future use by ITU-T|ISO / IEC. Although this version of the document requires that the value of gci_num_additional_bits be in the range 0 to 6, inclusive, decoders conforming to this version of the document shall allow values ​​of gci_num_additional_bits greater than 6 to appear 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. Additionally, if gci_present_flag is equal to 1, then no constraints are imposed on any encoding tools that do not have a corresponding constraint flag in the syntax of general_constraints_info().

[0071] In another arrangement of this embodiment, if the VVCv2 bitstream signals general constraint information (i.e., the value of gci_present_flag is 1) and no additional general constraint flag is signaled, the corresponding tool is constrained. This behavior can be expressed by changing the semantics of the additional general constraint flag as follows:

[0072] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the 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 for future use by ITU-T|ISO / IEC. Although this version of the document requires that the value of gci_num_additional_bits be in the range 0 to 6, inclusive, decoders conforming to this version of the document shall allow values ​​of gci_num_additional_bits greater than 6 to appear 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.

[0073] When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all images in OlsInScope are IRAP images or GDR images with ph_recovery_poc_cnt 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.

[0074] When gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_extended_precision_flag 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.

[0075] When gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_ts_residual_coding_rice_present_in_sh_flag 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.

[0076] When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_rrc_rice_extension_flag 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.

[0077] Specifies that when gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, all images in OlsInScope have sps_persistent_rice_adaptation_enabled_flag 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.

[0078] When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_reverse_last_sig_coeff_enabled_flag equal to 0. When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, no such constraint is imposed. When gci_present_flag is equal to 1 and gci_no_reverse_last_sig_coeff_constraint_flag is not present, it infers the value of gci_no_reverse_last_sig_coeff_constraint_flag equal to 1.

[0079] Initialization of general constraint information flags To address the above-mentioned decoder implementation ambiguity and inconsistency issues, one embodiment for initializing the general 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 impose constraints on the coding tools associated with 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.

[0080] As an example, possible changes to the semantics of gci_num_additional_bits are shown below, based on the current version of the VVC version 2 specification (additions are underlined, deletions are strikethrough):

[0081] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be equal to 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or 1, decoders conforming to this version of the document shall allow values ​​of gci_num_additional_bits greater than 1 to appear 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() imposes no constraints on the coding tools associated with 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.

[0082] As another example, possible changes to the semantics of gci_num_additional_bits are as follows, which are made based on the current version of the VVC version 2 specification:

[0083] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6gci_num_additional_bits is greater than 1. Other than 0 or 6 Values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document may not include the syntax Other than 0 or 6 Allow the value of gci_num_additional_bits to be displayed and gci_num_additional_bits is greater than 1 Not 0 or 6 If so, 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() imposes no constraints on the coding tools associated with 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.

[0084] In the current version of the VVC version 2 specification, the semantics of gci_num_additional_bits are used only 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 semantics of gci_num_additional_bits above, "when gci_present_flag is equal to 1", is automatically satisfied. Furthermore, since the VVC version 2 specification does not allow gci_num_additional_bits to have values ​​from 1 to 5, "gci_num_additional_bits 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:

[0085] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the 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 or 6Values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document may not include the syntax Other than 0 or 6 Allow the value of gci_num_additional_bits to be displayed and gci_num_additional_bits is greater than 1 Not 0 or 6 If so, 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() imposes no constraints on the coding tools associated with 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.

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

[0087] When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all images in OlsInScope are IRAP images or GDR images with ph_recovery_poc_cnt 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.

[0088] When gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_extended_precision_flag 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.

[0089] When gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_ts_residual_coding_rice_present_in_sh_flag 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.

[0090] When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_rrc_rice_extension_flag 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.

[0091] Specifies that when gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, all images in OlsInScope have sps_persistent_rice_adaptation_enabled_flag equal to 0. When gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, no such constraint is imposed. If not present, it infers the value of gci_no_persistent_rice_adaptation_constraint_flag equal to 0.

[0092] When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_reverse_last_sig_coeff_enabled_flag 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.

[0093] In another example, the semantics() of the additional general constraint flag is changed as follows:

[0094] When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all images in OlsInScope are IRAP images or GDR images with ph_recovery_poc_cnt 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, the value of gci_all_rap_pictures_constraint_flag is inferred to be equal to 0.

[0095] When gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_extended_precision_flag 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, the value of gci_no_extended_precision_processing_constraint_flag is inferred to be equal to 0.

[0096] When gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_ts_residual_coding_rice_present_in_sh_flag 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, the value of gci_no_ts_residual_coding_rice_constraint_flag is inferred to be equal to 0.

[0097] When gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_rrc_rice_extension_flag 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, the value of gci_no_rrc_rice_extension_constraint_flag is inferred to be equal to 0.

[0098] Specifies that when gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, all images in OlsInScope have sps_persistent_rice_adaptation_enabled_flag 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, the value of gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 0.

[0099] When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_reverse_last_sig_coeff_enabled_flag 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, the value of gci_no_reverse_last_sig_coeff_constraint_flag is inferred to be equal to 0.

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

[0101] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits is equal to ≪1≫ 6 Higher values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6However, decoders conforming to this version of the document may not use the syntax ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than ≪1≫ to be displayed. 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.

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

[0103] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits is equal to ≪1≫ 6 Higher values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document may not use the syntax ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than ≪1≫ to be displayed. 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.

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

[0105] [Table 6]

[0106] [Table 7]

[0107] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6 gci_num_additional_bits is equal to ≪1≫ 6 Higher values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document may not use the syntax ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than ≪1≫ to be displayed. 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.

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

[0109] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be 0 or <<1>>. 6gci_num_additional_bits is equal to ≪1≫ 6 Higher values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document may not use the syntax ≪1≫ 6 Allow values ​​of gci_num_additional_bits greater than ≪1≫ to be displayed. 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.

[0110] In another embodiment of initializing the general 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 may always impose the corresponding constraints specified by each semantic of these flags. In other words, if the GCI flags are present and gci_num_additional_bits is equal to 0, then it is inferred that these six GCI flags are equal to 1.

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

[0112] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the document, the value of gci_num_additional_bits shall be equal to 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or 1, decoders conforming to this version of the document shall allow values ​​of gci_num_additional_bits greater than 1 to appear 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 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.

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

[0114] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure other than the gci_alignment_zero_bit syntax element, if present. In bitstreams conforming to this version of the 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 or 6Values ​​are reserved for future use by ITU-T|ISO / IEC. In this version of the document, gci_num_additional_bits may have a value of 0 or ≪1≫. 6 However, decoders conforming to this version of the document may not include the syntax Other than 0 or 6 Allow the value of gci_num_additional_bits to be displayed and gci_num_additional_bits is greater than 1 Not 0 or 6 If so, 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.

[0115] In addition to or as an 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:

[0116] [Table 8]

[0117] ≪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 not decode any ≪gci_reserved_zero_bit[i]≫ gci_reserved_bit[i] The value of the syntax element should be ignored.

[0118] 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:

[0119] [Table 9]

[0120] ≪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 not decode any ≪gci_reserved_zero_bit[i]≫ gci_reserved_bit[i] The value of the syntax element should be ignored.

[0121] About General Constraint Flags gci_all_rap_pictures_constraint_flag The gci_all_rap_pictures_constraint_flag is used to indicate that the image is restricted to being an IRAP or GDR image.

[0122] 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 for various 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.

[0123] [Table 10(1)] [Table 10(2)]

[0124] NAL units classified as video coding layer (VCL) contain low-level syntax elements, whereas NAL units classified as non-VCL contain high-level syntax elements. Pictures of a video sequence are decoded based on VCL NAL units. Different types of VCL categories help to 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 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 cause problems in cases where reference pictures are not available.

[0125] An Intra Random Access Point (IRAP) picture is a coded picture in which all VCL NAL units have the same nal_unit_type value in the range from IDR_W_RADL to CRA_NUT (end points included). 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 bitstream in decoding order is an IRAP picture or a Gradual decoder refresh (GDR) picture. For single-layer bitstreams, an IRAP picture and all subsequent non-RASL pictures arranged in decoding order in the CLVS can be correctly decoded without performing the decoding process for pictures preceding the IRAP picture in decoding order, if the necessary parameter sets are available when they need to be referenced. The value of pps_mixed_nalu_types_in_pic_flag for an IRAP picture is equal to 0. If the pps_mixed_nalu_types_in_pic_flag of an image is equal to 0 and the nal_unit_type of any slice of that image is in the range from IDR_W_RADL to CRA_NUT (inclusive), then all other slices of that image have the same nal_unit_type value and after receiving the first slice, the image is known to be an IRAP image.

[0126] Therefore, IRAP images do not use inter-prediction between the same layers. Due to this restriction, IRAP images can be used as error recovery points in streaming video applications or location search points in video-on-demand playback applications. However, the compression efficiency of IRAP images is usually lower than that of non-IRAP images.

[0127] Gradual decoder 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 are decoded correctly even in the case of error events such as packet loss. In successive GDR pictures, the spatial location of the "clean" parts is rotated, so that eventually the whole picture can recover from errors.

[0128] 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, the GCI flag gci_all_rap_pictures_constraint_flag is introduced to indicate such a restriction at a high level. gci_all_rap_pictures_constraint_flag equal to 1 specifies that all pictures in OlsInScope are IRAP pictures or GDR pictures with ph_recovery_poc_cnt equal to 0. If gci_all_rap_pictures_constraint_flag equals 0, no such constraint is imposed. If gci_all_rap_pictures_constraint_flag is not present, a value of gci_all_rap_pictures_constraint_flag equal to 0 is inferred.

[0129] 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.

[0130] gci_no_extended_precision_processing_constraint_flag The GCI flag gci_no_extended_precision_processing_constraint_flag signals at a high level whether VVCv2 tools are constrained for extended conversion precision. In the VVC standard, 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 for both complexity and interoperability reasons. First, integer arithmetic (addition, multiplication, division) is usually less computationally expensive compared to the equivalent floating-point operation. Second, floating-point arithmetic is not deterministically standardized. Floating-point addition and multiplication are not necessarily commutative (e.g., (a+b)+c is not necessarily equal to a+(b+c)), and evaluation of floating-point operations across different platforms is not guaranteed to be the same.

[0131] 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, 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, these residual coefficients may have an extended bit depth (e.g., BitDepth+1), but in the VVC standard, the residual coefficients are clipped to maintain the bit depth of BitDepth. In practice, a real encoder will not select a prediction tool that generates a residual with a magnitude larger than the original video signal, so the worst case never occurs.

[0132] The residual coefficients are then typically analyzed by an integer-scaled discrete cosine transform (DCT) to generate transform coefficients. The discrete cosine transform (DCT) is a linear, invertible function, formally expressed as:

[0133]

number

number

number

[0134] 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.

[0135] 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 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 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: Log2TransformRange=sps_extended_precision_flag?Max(15,Min(20,BitDepth+6)):15 CoeffMin=-(1<<(sps_extended_precision_flag?Max(15,Min(20,BitDepth+6)):15)) CoeffMax=(1<<(sps_extended_precision_flag?Max(15,Min(20,BitDepth+6)):15))-1 When gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that sps_extended_precision_flag is equal to 0 for all images in OlsInScope. OlsInScope is also called "in-scope output layer set". When the profile_tier_level() syntax structure is included in the VPS, OlsInScope is one or more OLSs specified by the VPS. When the profile_tier_level() syntax structure is included in the SPS, OlsInScope is an OLS that includes only the lowest layer of the layers that reference the SPS, and the lowest layer is an independent layer. When gci_no_extended_precision_processing_constraint_flag is equal to 0, no such constraint is imposed. When gci_no_extended_precision_processing_constraint_flag is not present, it is inferred that the value of gci_no_extended_precision_processing_constraint_flag is equal to 0.

[0136] gci_no_ts_residual_coding_rice_constraint_flag The GCI flag gci_no_ts_residual_coding_rice_constraint_flag signals at a high level whether the VVCv2 tools for explicit Rice parameter signaling are constrained or not. In entropy coding, the value of each syntax element is coded by an entropy coding process into a bit sequence that is inserted into the bitstream.

[0137] The two entropy coding processes used in VVC are Context-Adaptive Binary Arithmetic Coding (CABAC) and Rice coding. The CABAC engine is adaptive and can compress syntax elements to bit rates very close to the theoretical Shannon limit. However, arithmetic coding is complex. To code non-binary syntax elements (e.g., syntax elements with values ​​greater than 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 corresponding bins.

[0138] [Table 11]

[0139] [Table 12]

[0140] 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 the associated "context". The context models the probability distribution of the bin. In a syntactic element binarization, each bin needs a separate context.

[0141] Encoding syntax elements with a wide range of values ​​using CABAC alone is not ideal because such syntax elements require long binarization times, which would result in excessive overhead in terms of context storage and updates. For example, encoding residual coefficient values ​​using CABAC alone is inconvenient. In contrast to CABAC, Rice coding can model probability distributions of non-binary values ​​using compact parameters.

[0142] 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.

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

[0144]

number

[0145] [Table 13]

[0146] When a unary code is truncated, the Rice code is also truncated, which means that the range of values ​​of x that can be coded is finite. In VVC, the truncated Rice code is written in the range [0,6*2 R ] applies to values ​​of x in the range

[0147] The suffix code is a fixed-length code obtained by binarizing r and has R bits. For example, when R=3, the suffix code is as follows:

[0148] [Table 14]

[0149] In VVC, the residual coefficients are coded by a combination of CABAC, Rice coding and Exponential-Golomb coding. A small number of syntax element flags are defined that are sufficient to signal the value of the small magnitude residual. For example, sig_coeff_flag indicates whether the magnitude of the residual is zero or non-zero. If sig_coeff_flag is 1, a further flag can be signaled, usually named abs_level_gtx_flag, indicating 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, most of the residuals can be coded efficiently by CABAC using a relatively small number of bins.

[0150] Any remaining magnitude of the residual coefficients that cannot be signaled by the residual coefficient flags is signaled with the syntax element abs_remainder. The value of abs_remainder is 6*2 R The syntax element is fully signaled by the Rice code of abs_remainder if the value of abs_remainder is 6*2 R If it is greater than 6*2 R Rice code and (abs_remainder-6*2 R ) are signaled by the concatenation of the exponential-Golomb codes. Here, the exponential-Golomb coding process is not described.

[0151] 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 match the statistics of the residual coefficients, the Rice parameter is adaptively determined based on the locSumAbs value, which is calculated based on the magnitude of the neighboring residual coefficients.

[0152] [Table 15]

[0153] The 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, the adaptive Rice parameter determination is also applied to residual coefficients in "Transform-Skip Residual Coding" (TSRC). In VVCv2, it was recognized that an alternative mechanism for determining the Rice parameter could be beneficial for transform-skip coefficients.

[0154] An alternative mechanism in VVCv2" allows explicitly signaling the Rice parameter by the slice-level syntax element sh_ts_residual_coding_rise_idx_minusl. When this syntax element is signaled, the Rice parameter is set to R = "sh_ts_residual_coding_rise_idx_minusl" + 1. This value of the Rice parameter persists for the duration of the slice.

[0155] [Table 16]

[0156] sh_ts_residual_coding_rice_idx_minusl plus 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.

[0157] 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 said flag is set to 0, then fallback Rice parameter signaling is not enabled. The GCI flag gci_no_ts_residual_coding_rice_constraint_flag signals at a high level whether the VVCv2 tools of explicit Rice parameter signaling are constrained or not. When 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 images in OlsInScope. 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, the value of gci_no_ts_residual_coding_rice_constraint_flag is inferred to be equal to 0.

[0158] gci_no_rrc_rice_extension_constraint_flag gci_no_rrc_rice_extension_constraint_flag specifies sps_rrc_rice_extension_flag for all images in OlsInScope. If gci_no_rrc_rice_extension_constraint_flag is equal to 1, then all images in OlsInScope have sps_rrc_rice_extension_flag equal to 0. If gci_no_rrc_rice_extension_constraint_flag is equal to 0, then no such constraint is imposed.

[0159] In high bit depth and high bit rate applications, there are many large quantization levels for many positions in the RRC. In such applications, a larger Rice parameter reduces the number of bins required to represent the remaining levels. The Rice parameter derivation scheme 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. sps_rrc_rice_extension_flag equal to 1 specifies that the alternative Rice parameter derivation is used for the binarization of abs_remaining[] and dec_abs_level[]. sps_rrc_rice_extension_flag equal to 0 specifies that the 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 equal to 0 is inferred.

[0160] Below is an example of determining Rice parameters using sps_rrc_rice_extension_flag in VVCv2. Given an array AbsLevel[x][y] of transform blocks with component index cIdx and luminance position (x0,y0) of the top-left corner, the variable locSumAbs is derived as specified in the following pseudocode process (the underlined parts are the additions of VVCv2 over VVCv1):

[0161] locSumAbs=0 if(xC<(1<< AbsL ≪l≫og2TbWidth)-1){ locSumAbs+=AbsLevel[xC+1][yC] if(xC<(1<< AbsL ≪l≫og2TbWidth)-2) locSumAbs+=AbsLevel[xC+2][yC] else locSumAbs+=HistValue if(yC<(1<< AbsL ≪l≫og2TbHeight)-1) locSumAbs+=AbsLevel[xC+1][yC+1] (1517) else locSumAbs+=HistValue } else locSumAbs+=2*HistValue if(yC<(1<< AbsL ≪l≫og2TbHeight)-1){ locSumAbs+=AbsLevel[xC][yC+1] if(yC<(1<< AbsL ≪l≫og2TbHeight)-2) locSumAbs+=AbsLevel[xC][yC+2] else locSumAbs+=HistValue } else locSumAbs+=HistValue The lists Tx[] and Rx[] are specified as follows: Tx[]={32,128,512,2048} (1523) Rx[]={0,2,4,6,8} (1524) The value of the variable shiftVal is derived as follows: if(!sps_rrc_rice_extension_flag) shiftVal=0 (1526X1) else shiftVal=(localSumAbs <Tx[0])?Rx[0]:((localSumAbs<Tx[1])?Rx[1]: ((localSumAbs <Tx[2])?Rx[2]:((localSumAbs<Tx[3])?Rx[3]:Rx[4]))) The value of locSumAbs is updated as follows: locSumAbs=Clip3(0,31,(locSumAbs>>shiftVal)-baseLevel*5) (1526X2) Given the variable locSumAbs, the rice parameter cRiceParam is first Derived as specified in Table 128, Then, cRiceParam is updated as follows: cRiceParam=cRiceParam+shiftVal (1526X3) If baseLevel is equal to 0, the variable ZeroPos[n] is derived as follows: ZeroPos[n]=(Qstate<2?1:2)< <cRiceParam (1518)

[0162] [Table 17]

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

[0164] gci_no_persistent_rice_adaptation_constraint_flag gci_no_persistent_rice_adaptation_constraint_flag signals a constraint on the Rice parameter derivation for binarization using previous TU states. If 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 images in OlsInScope. If 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, it infers the value of gci_no_persistent_rice_adaptation_constraint_flag equal to 0.

[0165] 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 indicates 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):

[0166] If the CTU is the first CTU in a slice or tile, the context variables initialization process as specified in subclause 9.3.2.2 is invoked, the array PredictorPaletteSize[chType] (where chType=0,1) is initialized to 0 and the array StatCoeff[i] (where i=0..2) is initialized as follows: StatCoeff[i] = sps_persistent_rice_adaptation_enabled_flag?2*Floor(Log2(BitDepth-10) :0 (1513X3) StatCoeff[i] is used to calculate HisValue, which is used to calculate locSumAbs in (1517), which can be updated once per TU. The derivation of the Rice parameters for those positions that are on block boundaries can have accurate values ​​with the help of HisValue.

[0167] gci_no_reverse_last_sig_coeff_constraint_flag When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that all images in OlsInScope have sps_reverse_last_sig_coeff_enabled_flag equal to 0. When gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, no such constraint is imposed. When gci_no_reverse_last_sig_coeff_constraint_flag is not present, it infers the value of gci_no_reverse_last_sig_coeff_constraint_flag equal to 0.

[0168] 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, last_sig_coeff_y_suffix. This position is coded in VVCv1 using the difference between (x,y) of the current TU and (0,0). 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, this may not be the case for VVCv2 applications, where many non-zero levels are spread throughout the TU and 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.

[0169] 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 based on ((Log2ZoTbWidth<<1)-1, (Log2ZoTbHeight<<1)-1). If sh_reverse_last_sig_coeff_flag is equal to 0, it specifies that the coordinates of the last significant coefficient are coded based on (0,0) for each transform block of the current slice. If not present, the value of sh_reverse_last_sig_coeff_flag is inferred to be equal to 0.

[0170] sh_reverse_last_sig_coeff_flag is parsed conditionally with sps_reverse_last_sig_coeff_enabled_flag in the slice header as follows:

[0171] If -last_sig_coeff_x_suffix is ​​not present, the following applies: LastSignificantCoeffX=last_sig_coeff_x_prefix (193) - Otherwise (last_sig_coeff_x_suffix is ​​present), the following applies: LastSignificantCoeffX=(1<<((last_sig_coeff_x_prefix>>1)-1))* (194) (2+(last_sig_coeff_x_prefix&1))+last_sig_coeff_x_suffix If sh_reverse_last_sig_coeff_flag is equal to 1, the value of LastSignificantCoeffX is modified as follows: LastSignificantCoeffX=(1< <Log2ZoTbWidth)-1-LastSignificantCoeffX (195) If -last_sig_coeff_y_suffix is ​​not present, the following applies: LastSignificantCoeffY=last_sig_coeff_y_prefix (196) - Otherwise (last_sig_coeff_y_suffix is ​​present), the following applies: LastSignificantCoeffY=(1<<((last_sig_coeff_y_prefix>>1)-1))* (197) (2+(last_sig_coeff_y_prefix&1))+last_sig_coeff_y_suffix If sh_reverse_last_sig_coeff_flag is equal to 1, the value of LastSignificantCoeffY is modified as follows: LastSignificantCoeffY=(1< <Log2ZoTbHeight)-1-LastSignificantCoeffY (198)

[0172] VVCv2 slice header [Table 18]

[0173] FIG. 5 illustrates an example of a video decoding process 500 according to some embodiments of the present invention. One or more computing devices may 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, and 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 shown in the figure. However, other implementations are possible.

[0174] At block 502, the process 500 includes accessing a bitstream of a video signal (e.g., the encoded video 202). At block 504, the process 500 includes extracting a general constraint information (GCI) flag from the video bitstream. As previously described, 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 is used to indicate constraints imposed on additional encoding tools. When gci_present_flag is equal to 0, it specifies that a GCI syntax element is not present and no general constraints are imposed on 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.

[0175] At block 506, process 500 includes determining whether one or more general constraints are imposed on the video based on the value of the GCI flag. If so (i.e., the GCI flag is 1), at block 508, process 500 includes extracting from the video bitstream a value M representing a number of additional bits included in the video bitstream. These additional bits include a number of flag bits indicating corresponding additional encoding tools that are constrained for the video.

[0176] At block 510, the process 500 includes determining whether M>5. If so, at block 512, the process 500 extracts six flag bits from the bitstream, the six flag bits representing corresponding flags that indicate corresponding constraints of the six additional coding tools. The six flags include a flag gci_all_rap_pictures_constraint_flag indicating that pictures of the video are restricted to 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 signaling is constrained, and a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether quantization residual 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 for binarizing the difference, 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 impose constraints on images in OlsInScope when decoding the position of the last non-zero level in the TU.

[0177] If M is greater than 6, then in block 513, the process 500 includes extracting the remaining M-6 bits from the bitstream and discarding the M-6 bits, i.e., the video decoding is performed independently of the M-6 bits.

[0178] At block 514, the process 500 includes decoding the remaining portion of the video bitstream into pictures based on the constraints of the six additional encoding tools indicated by the six flags. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder may determine that all pictures in one or more output layer sets are IRAP pictures or GDR 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 so that extended dynamic range is not used. If the flag gci_no_ts_residual_coding_rice_constraint_flag is 1, the decoder may determine that the explicit Rice parameter signaling is constrained and may decode the remaining portion of the video bitstream by disabling alternative Rice parameter signaling 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 portion of the video bitstream by disabling alternative Rice parameter signaling for pictures in OlsInScope. If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder may determine that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained and may decode the remaining portion of the video bitstream without initializing the Rice parameters based on the 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 images in OlsInScope is equal to 0 and the coordinates of the last significant coefficient are encoded 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 by interpreting the coordinates of the decoded last significant coefficient as relative to the upper-left corner (0,0) of each transform block of the current slice.

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

[0180] FIG. 6 illustrates another example of a video decoding process 600 according to some embodiments of the present invention. One or more computing devices may execute appropriate program code to implement the operations illustrated in FIG. 6. For example, a computing device implementing a video decoder 200 may execute program code to implement the operations illustrated in FIG. 6, and 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.

[0181] At block 602, the process 600 includes accessing a bitstream of a video signal (e.g., the encoded video 202). At block 604, the process 600 includes extracting a general constraint information (GCI) flag from the bitstream of the video. As explained 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 is used to indicate constraints imposed on additional encoding tools. When gci_present_flag is equal to 0, it specifies that a GCI syntax element is not present and no general constraints are imposed on 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.

[0182] At block 606, process 600 includes determining whether one or more general constraints are imposed on the video based on the value of the GCI flag. If so (i.e., the GCI flag is 1), at block 608, process 600 includes extracting from the video's bitstream a value M that represents a number of additional bits included in the video's bitstream. These additional bits include flag bits that indicate corresponding additional encoding tools that are constrained for the video.

[0183] At block 610, the process 600 includes determining whether M is greater than 6. If so, at block 612, the process 600 includes extracting six flag bits from the bitstream, the six flag bits representing corresponding flags indicating corresponding constraints of the six additional coding tools. The six flags include a flag gci_all_rap_pictures_constraint_flag indicating that pictures of the video are restricted to 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 signaling is constrained, and a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether quantization residual 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 for binarizing the difference, 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 impose constraints on images in OlsInScope when decoding the position of the last non-zero level in the TU.

[0184] At block 614, the process 600 includes extracting the M-6 bits following the six flag bits from the bitstream and discarding the extracted M-6 bits. That is, the video decoding is performed independently of the M-6 bits. At block 616, the process 600 includes decoding the remaining portion of the video bitstream into pictures based on the constraints of the six additional encoding tools indicated by the six flags. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder may determine that all pictures in one or more output layer sets are IRAP pictures or GDR 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 decode the video by setting sps_extended_precision_flag to 0 for the pictures in OlsInScope so that the extended dynamic range is not used. If the flag gci_no_ts_residual_coding_rice_constraint_flag is 1, the decoder may determine that the explicit Rice parameter signaling is constrained and decode the remaining parts of the video bitstream by disabling the alternative Rice parameter signaling for the 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 decode the remaining parts of the video bitstream by disabling the alternative Rice parameter signaling for the pictures in OlsInScope.If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder determines that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained, and may decode the remaining part of the video bitstream without initializing the Rice parameters based on the previous transform unit state of the pictures in OlsInScope. If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder may decode the remaining part of the video bitstream by determining that sps_reverse_last_sig_coeff_enabled_flag of all pictures in OlsInScope is equal to 0, determining that the coordinates of the last significant coefficient are coded with respect to the top-left corner (0,0) of each transform block of the current slice, and interpreting the coordinates of the decoded last significant coefficient as being with respect to the top-left corner (0,0) of each transform block of the current slice.

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

[0186] FIG. 7 illustrates another example of a video decoding process 700 according to some embodiments of the present invention. One or more computing devices may execute appropriate program code to implement the operations illustrated in FIG. 7. For example, a computing device implementing a video decoder 200 may execute program code to implement the operations illustrated in FIG. 7, and 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 shown in the figure. However, other implementations are possible.

[0187] At block 702, the process 700 includes accessing a bitstream of a video signal (e.g., the encoded video 202). At block 704, the process 700 includes extracting a general constraint information (GCI) flag from the bitstream of the video. As explained above, the binary flag gci_present_flag is used to specify whether or not 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 is used to indicate constraints imposed on additional encoding tools. When gci_present_flag is equal to 0, it specifies that the GCI syntax element is not present and no general constraints are imposed on 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.

[0188] At block 706, the process 700 includes determining whether one or more general constraints are imposed on the video based on the value of the GCI flag. If so (i.e., the GCI flag is 1), at block 708, the process 700 includes extracting from the video bitstream a value M representing a number of additional bits included in the video bitstream. These additional bits include a number of flag bits indicating corresponding additional encoding tools that are constrained for the video.

[0189] At block 710, the process 700 includes determining whether M is greater than 5. If not, at block 712, the process 700 includes extracting M bits from the bitstream and discarding the M bits. At block 714, the process 700 includes decoding the remaining portion of the video bitstream into an image independent of the M bits. If at block 710, it is determined that M is less than or equal to 5, at block 718, the process 700 includes extracting the six flag bits, as described above. If M is greater than 6, at block 719, the process 700 includes extracting the remaining M-6 bits from the bitstream and discarding the M-6 bits. That is, the video decoding is performed independent of the M-6 bits. At block 720, the decoder decodes the video by imposing constraints on six additional coding tools based on the extracted six flag bits, as described above.

[0190] If, at block 706, it is determined that the GCI flag indicates that the video is not generically constrained (i.e., the GCI flag is 0), then process 700 includes decoding the video into an image without generic 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.

[0191] Example of a Computing System for Implementing Signaling of General 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 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 plurality of processing devices (including one processing device). Such a processor may include or be in communication with a computer readable medium that stores instructions, which when executed by the processor 812, cause the processor to perform the operations described herein.

[0192] 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 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, and ActionScript.

[0193] The computing device 800 may further include a bus 816. The bus 816 communicatively couples 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, e.g., the computing device 800 is shown to include 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. The 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.

[0194] The computing device 800 may execute program code that causes the processor 812 to perform one or more of the operations 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.

[0195] 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, etc. The computing device 800 may transmit messages via the network interface devices 824 as electronic or optical signals.

[0196] General Considerations Numerous specific 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 specific details. In other instances, methods, devices, or systems known to those skilled in the art have not been described in detail so as not to obscure the claimed subject matter.

[0197] Unless otherwise noted, terms such as "processing," "computing," "calculating," "determining," "identifying," and the like are used throughout this specification to describe operations or processes of a computing device (e.g., one or more computers or similar electronic computing device(s)) 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.

[0198] The system or 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 microprocessor-based computer systems that access stored software that programs or configures the computing system, thereby changing the computing system from a general purpose computing device to a special purpose computing device to implement 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 configured to program or configure a computing device.

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

[0200] As used herein, "applied to" or "configured to" is intended to be 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 intended to be open and inclusive, as 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. Headings, lists, and numbering contained herein are for ease of description only and are not intended to be limiting.

[0201] 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 invention is presented for purposes of illustration and not limitation, and does not exclude 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: Extracting general constraint information (GCI) flags from a video bitstream; determining, based on the value of the GCI flag, that one or more general constraints are imposed on the video; responsive to determining that the one or more general constraints are imposed on the video, extracting from the bitstream of the video a value indicative of a number of additional bits included in the bitstream of the video, the additional bits including flag bits, the flag bits indicating corresponding additional encoding tools constrained for the video; determining that the value is greater than 5; and in response to determining that the value is greater than 5, extracting six flag bits from the bitstream, the six corresponding flags representing six corresponding flags indicating corresponding constraints of six additional encoding tools; and decoding a remaining portion of the video bitstream into an image based at least in part on constraints of the six additional encoding tools indicated by the six flags.

2. The six flags are: a first flag indicating that the images of the video are restricted to Intra Random Access Point (IRAP) images or Gradual Decoding Refresh (GDR) images; a second flag indicating whether the extended conversion precision is constrained; a third flag indicating whether explicit Rice parameter signaling is constrained; and a fourth flag indicating an alternative Rice parameter derivation for binarization of the quantization residual of the video; a fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit; a sixth flag indicating whether to impose a constraint on images 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 1.

3. 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 a 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 constraints are 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 a 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 a 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 constraints are imposed on the corresponding encoding tool; or 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 constraints are imposed on the corresponding encoding tool. The video decoding method of claim 2.

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

5. The GCI flag is extracted 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 1.

6. The video decoding method includes: in response to determining that the value is greater than five, setting a value indicative of extracted additional bits, numAdditionalBitsUsed, to six; and extracting a set of bits from said bitstream, the number of bits in said set of bits being equal to gci_num_additional_bits-numAdditionalBitsUsed, where gci_num_additional_bits represents said value; and decoding a remaining portion of the video bitstream into an image independent of the set of bits. The video decoding method of claim 1.

7. The video decoding method includes: in response to determining that the value is less than or equal to 5, setting a value numAdditionalBitsUsed indicative of extracted additional bits to 0; extracting a set of bits from said bitstream, the number of bits in said set of bits being equal to gci_num_additional_bits-numAdditionalBitsUsed, where gci_num_additional_bits represents said value; and decoding a remaining portion of the video bitstream into an image independent of the extracted set of bits. The video decoding method of claim 1.

8. A non-transitory computer readable medium having program code stored thereon, the program code causing one or more processing devices to perform operations, the operations including: Extracting general constraint information (GCI) flags from a video bitstream; determining, based on the value of the GCI flag, that one or more general constraints are imposed on the video; responsive to determining that the one or more general constraints are imposed on the video, extracting from the bitstream of the video a value indicative of a number of additional bits included in the bitstream of the video, the additional bits including flag bits, the flag bits indicating corresponding additional encoding tools constrained for the video; determining that the value is greater than 5; and in response to determining that the value is greater than 5, extracting six flag bits from the bitstream, the six corresponding flags representing six corresponding flags indicating corresponding constraints of six additional encoding tools; and decoding a remaining portion of the video bitstream into an image based at least in part on constraints of the six additional encoding tools indicated by the six flags.

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

10. The operation 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 a 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 constraints are 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 a 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 a 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 constraints are imposed on the corresponding encoding tool; or 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 constraints are imposed on the corresponding encoding tool.

10. The non-transitory computer readable medium of claim 9.

11. decoding a remaining portion of the video bitstream into an image based at least in part on constraints of the six additional encoding tools indicated by the six flags; determining, based on the first flag being 1, that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and decoding the GDR images or IRAP images in the one or more output layer sets; determining that extended transform precision is constrained based on the second flag being 1, and setting sps_extended_precision_flag of images in an in-scope output layer set (OlsInScope) to 0 such that extended dynamic range is not used, and decoding a remaining portion of the video bitstream; determining that explicit Rice parameter signaling is constrained based on the third flag being one, and decoding a remainder of the video bitstream by disabling alternative Rice parameter signaling for images in the in-scope output layer set (OlsInScope); determining, based on the third flag being one, that an alternative Rice parameter derivation for binarizing a quantized residual of the video is constrained, and decoding a remaining portion of the video bitstream by disabling alternative Rice parameter signaling for images in the in-scope output layer set (OlsInScope); 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 remaining portion of the video bitstream without initializing Rice parameters based on a previous transform unit state of an image in the in-scope output layer set (OlsInScope); or determining, based on the sixth flag being 1, that a coordinate of a last significant coefficient is coded with respect to a top-left corner of each transform block of a slice; and decoding a remaining portion of the video bitstream by interpreting the decoded coordinate of the last significant coefficient as being with respect to the top-left corner of each transform block of the slice.

10. The non-transitory computer readable medium of claim 9.

12. The GCI flag is extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video. The non-transitory computer-readable medium of claim 8.

13. The operation includes: in response to determining that the value is greater than five, setting a value indicative of extracted additional bits, numAdditionalBitsUsed, to six; and extracting a set of bits from said bitstream, the number of bits in said set of bits being equal to gci_num_additional_bits-numAdditionalBitsUsed, where gci_num_additional_bits represents said value; and decoding a remaining portion of the video bitstream into an image independent of the set of bits. The non-transitory computer-readable medium of claim 8.

14. The operation includes: in response to determining that the value is less than or equal to 5, setting a value numAdditionalBitsUsed indicative of extracted additional bits to 0; extracting a set of bits from said bitstream, the number of bits in said set of bits being equal to gci_num_additional_bits-numAdditionalBitsUsed, where gci_num_additional_bits represents said value; and decoding a remaining portion of the video bitstream into an image independent of the extracted set of bits. The non-transitory computer-readable medium of claim 8.

15. 1. A system comprising: 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 general constraint information (GCI) flags from a video bitstream; determining, based on the value of the GCI flag, that one or more general constraints are imposed on the video; responsive to determining that the one or more general constraints are imposed on the video, extracting from the bitstream of the video a value indicative of a number of additional bits included in the bitstream of the video, the additional bits including flag bits, the flag bits indicating corresponding additional encoding tools constrained for the video; determining that the value is greater than 5; and in response to determining that the value is greater than 5, extracting six flag bits from the bitstream, the six corresponding flags representing six corresponding flags indicating corresponding constraints of six additional encoding tools; and decoding a remaining portion of the video bitstream into an image based at least in part on constraints of the six additional encoding tools indicated by the six flags.

16. The six flags are: a first flag indicating that the images of the video are restricted to Intra Random Access Point (IRAP) images or Gradual Decoding Refresh (GDR) images; a second flag indicating whether the extended conversion precision is constrained; a third flag indicating whether explicit Rice parameter signaling is constrained; and a fourth flag indicating an alternative Rice parameter derivation for binarization of the quantization residual of the video; a fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit; a sixth flag indicating whether to impose a constraint on images 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. The operation 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 a 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 constraints are 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 a 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 a 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 constraints are imposed on the corresponding encoding tool; or 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 constraints are imposed on the corresponding encoding tool.

17. The system of claim 16.

18. decoding a remaining portion of the video bitstream into an image based at least in part on constraints of the six additional encoding tools indicated by the six flags; determining, based on the first flag being 1, that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and decoding the GDR images or IRAP images in the one or more output layer sets; determining that extended transform precision is constrained based on the second flag being 1, and setting sps_extended_precision_flag of images in an in-scope output layer set (OlsInScope) to 0 such that extended dynamic range is not used, and decoding the remaining portion of the bitstream of the video; determining that explicit Rice parameter signaling is constrained based on the third flag being one, and decoding a remainder of the video bitstream by disabling alternative Rice parameter signaling for images in the in-scope output layer set (OlsInScope); determining, based on the third flag being one, that an alternative Rice parameter derivation for binarizing a quantized residual of the video is constrained, and decoding a remaining portion of the video bitstream by disabling alternative Rice parameter signaling for images in the in-scope output layer set (OlsInScope); 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 remaining portion of the video bitstream without initializing Rice parameters based on a previous transform unit state of an image in the in-scope output layer set (OlsInScope); or determining, based on the sixth flag being 1, that a coordinate of a last significant coefficient is coded with respect to a top-left corner of each transform block of a slice; and decoding a remaining portion of the video bitstream by interpreting the decoded coordinate of the last significant coefficient as being with respect to the top-left corner of each transform block of the slice.

17. The system of claim 16.

19. The GCI flag is extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video. The system of claim 15.

20. The operation includes: in response to determining that the value is greater than five, setting a value indicative of extracted additional bits, numAdditionalBitsUsed, to six; and extracting a set of bits from said bitstream, the number of bits in said set of bits being equal to gci_num_additional_bits-numAdditionalBitsUsed, where gci_num_additional_bits represents said value; and decoding a remaining portion of the video bitstream into an image independent of the set of bits. The system of claim 15.

Images