Signaling generic constraint information for video coding

Abstract

In some embodiments, a video decoder decodes a video according to a bitstream of the video. A video decoder accesses a bitstream of a video and extracts a generic constraint information (GCI) flag from the bitstream of the video. The decoder determines, based on the value of the GCI flag, to apply one or more generic constraints to the video and extracts, from a bitstream of the video, a value indicating the number of additional bits included in the bitstream of the video. The additional bits include flag bits indicating respective additional coding tools to be constrained for the video. If the value is greater than 5, the decoder extracts six flags from the code stream of the video, the six flag bits indicating respective constraints on the six additional coding tools. The decoder decodes the code stream of the video into an image based on the constraints on the six additional coding tools indicated by the six flags.

Description

This application is a divisional application of Chinese patent application No. 202280081236.5, which has entered the Chinese national phase of PCT international patent application PCT / US2022 / 079494 with an application date of November 8, 2022 and an invention name of "Signaling general constraint information for video coding". CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63 / 266,615, filed on January 10, 2022, entitled “Signaling Methods for General Constraints Information for Video Coding,” U.S. Provisional Application No. 63 / 266,616, filed on January 10, 2022, entitled “Initialization Method for General Constraint Information Flags for Video Coding,” and U.S. Provisional Application No. 63 / 266,765, filed on January 13, 2022, entitled “Signaling and Initialization Methods for General Constraints Information for Video Coding,” all of which are incorporated herein by reference in their entirety. Technical Field

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

[0003] The ubiquity of camera-enabled devices, such as smartphones, tablets, and computers, makes it easier than ever to capture videos or images. However, even for short videos, the amount of data can be very large. Video coding technology (including video encoding and decoding) enables video data to be compressed into a smaller size, thereby enabling various videos to be stored and transmitted. Video coding has been widely used in various applications, such as digital television broadcasting, video transmission over the Internet and mobile networks, real-time applications (such as video chat, video conferencing), DVDs, Blu-ray discs, etc. In order to reduce the storage space used to store videos and / or the network bandwidth consumption used to transmit videos, it is hoped 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 method for decoding a video includes: extracting a general constraint information (GCI) flag from a bitstream of the video; 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 bitstream of the video a value indicating the number of additional bits included in the bitstream of the video, the additional bits including a flag bit, the flag bit indicating corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; in response to determining that the value is greater than 5, extracting from the bitstream 6 flag bits representing 6 corresponding flags, the 6 corresponding flags indicating corresponding constraints on the 6 additional coding tools, and decoding the remaining portion of the bitstream of the video into an image based at least in part on the constraints on the 6 additional coding tools indicated by the 6 flags.

[0005] In another example, a non-transitory computer-readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform operations. The operations include: extracting a general constraint information (GCI) flag from a bitstream of a video; 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 bitstream of the video a value indicating the number of additional bits included in the bitstream of the video, the additional bits including a flag bit, the flag bit indicating corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; in response to determining that the value is greater than 5, extracting from the bitstream 6 flag bits representing 6 corresponding flags, the 6 corresponding flags indicating corresponding constraints on the 6 additional coding tools, and decoding the remaining portion of the bitstream of the video into an image based at least in part on the constraints on the 6 additional coding tools indicated by the 6 flags.

[0006] In another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device. The processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform operations. The operations include: extracting a general constraint information (GCI) flag from a bitstream of a video; based on the value of the GCI flag, determining 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 bitstream of the video a value indicating the number of additional bits included in the bitstream of the video, the additional bits including a flag bit, the flag bit indicating corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; in response to determining that the value is greater than 5, extracting 6 flag bits representing 6 corresponding flags from the bitstream, the 6 corresponding flags indicating corresponding constraints on the 6 additional coding tools, and decoding the remaining portion of the bitstream of the video into an image based at least in part on the constraints on the 6 additional coding tools indicated by the 6 flags.

[0007] These illustrative embodiments are mentioned not to limit or define the present disclosure, but to provide examples to aid understanding of the present disclosure. Additional embodiments are discussed in the detailed description, and further description is provided in the detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The features, embodiments and advantages of the present disclosure will be better understood when the following detailed description is read with reference to the accompanying drawings.

[0009] Figure 1 is a block diagram illustrating an example of a video encoder configured to implement the embodiments presented herein.

[0010] Figure 2 is a block diagram illustrating an example of a video decoder configured to implement the embodiments presented herein.

[0011] Figure 3 Depicted are examples of coding tree unit partitioning of images in a video according to some embodiments of the present disclosure.

[0012] Figure 4 Depicted are examples of coding unit partitioning of coding tree units according to some embodiments of the present disclosure.

[0013] Figure 5 An example of a process for decoding a video according to some embodiments of the present disclosure is depicted.

[0014] Figure 6 Another example of a process for decoding a video according to some embodiments of the present disclosure is depicted.

[0015] Figure 7 Another example of a process for decoding a video according to some embodiments of the present disclosure is depicted.

[0016] Figure 8 An example of a computing system that can be used to implement some embodiments of the present disclosure is depicted. DETAILED DESCRIPTION

[0017] Various embodiments of signaling and initializing general constraint information for video coding are provided. As discussed above, more and more video data is generated, stored and transmitted. It is advantageous to improve not only the efficiency of video coding technology but also the stability of video coding so that the video signal can be successfully decoded on the decoder side. Problems related to the stability of video decoding include incompatibility and inconsistency issues. As video coding technology develops, newer video coding standards have been developed. One such video coding standard is the Versatile Video Coding standard version 1, which is jointly issued by the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU), where ISO refers to "ISO / IEC 23090-3:2021 Information technology - Coded representation of immersive media - Part 3: Versatile video coding" and ITU refers to "ITU-T H.266 Recommendation (August 2020): Versatile video coding". In the present disclosure, version 1 of the Versatile Video Coding standard may be referred to as "VVC version 1" or "VVCv1". VVC version 1 has been superseded by version 2 of the Versatile Video Coding standard, which will be published jointly by ISO and ITU, where ISO refers to "ISO / IEC 23090-3:2022 Information technology - Coded representation of immersive media - Part 3: Versatile video coding" and ITU refers to "Recommendation ITU-T H.266 (April 2022): Versatile video coding". In this disclosure, version 2 of the Versatile Video Coding standard may be referred to as "VVC version 2" or "VVCv2". In order to enable a video decoder compliant with a new version of the video coding standard to successfully decode a video signal encoded using a previous version of the video coding standard, the video coding scheme should be designed to be backward compatible with the previous version of the coding standard. However, signaling the common constraint information used in the current draft of VVC version 2 causes desynchronization of video decoding, which is a serious incompatibility issue between different versions of the video coding standard. In addition, in the current draft of VVC version 2, a common constraint flag related to the common constraint information may not be defined, resulting in ambiguity and inconsistency in decoder implementation in some cases. Various embodiments described herein address these issues by introducing a signaling and initialization method for general constraint information for video coding, thereby improving the stability of video coding.

[0018] In the VVC standard, the General Constraints Information (GCI) syntax structure general_constraints_info() is used to indicate specific constraint properties of a codestream. GCI contains a list of constraint flags and non-flag syntax elements. The binary flag gci_present_flag is used to specify whether the GCI syntax element exists. In some embodiments, if the VVC version 2 codestream 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 can 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 flag for the N additional coding tools will not be signaled. If gci_num_additional_bits is set to N, the next N bits in the codestream are used to signal the general constraint flag for the N additional coding tools. In one example, N is set to 6.

[0019] In some examples, for VVC version 2 codestreams, setting gci_num_additional_bits to a value other than 0 or N is not allowed. 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 a value M greater than 0 and less than N, or to a value greater than N. If M is greater than 0 and less than N, then after decoding the gci_num_additional_bits syntax element, the decoder extracts M bits from the codestream and discards the M bits. If M is greater than N, then after decoding the gci_num_additional_bits syntax element, the decoder extracts N bits from the codestream and interprets the N bits as a general constraint flag for N additional coding tools. Then, the decoder also extracts (MN) bits from the codestream and discards the (MN) bits. In other examples, a VVC version 2 decoder does not need to process the general constraint information that sets gci_num_additional_bits to a value greater than 0 but less than N. Legal VVC version 2 codestreams can only set gci_num_reserved_bits to a value of 0 or N. Codestreams of future versions of VVC will not be allowed to set gci_num_additional_bits to a value between 0 and N.

[0020] In some embodiments, the general constraint information flag is initialized to resolve the ambiguity and inconsistency of the decoder implementation discussed above. In these embodiments, when 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 the general constraint information flag. In examples where the value of the flag is 0 indicating no constraints, when the general constraint information flag is not present, the value of the flag is inferred to be equal to 0.

[0021] The embodiments described in the present disclosure provide a method by which a general constraint flag for additional coding tools in VVC version 2 can be signaled and inferred. Unlike the prior art, the high-level syntax codestream generated by the method described in the present disclosure is compatible with the VVC version 1 decoder and can be decoded in the case of a loss of synchronization between the behavior of the VVC version 1 decoder and the behavior of the VVC version 2 decoder. The inference rules described in the present disclosure eliminate the ambiguity of the VVC version 2 decoding behavior of the VVC version 2 GCI syntax elements. These techniques can become effective coding tools in various video coding standards.

[0022] Now referring to the accompanying drawings, Figure 1 is a block diagram illustrating an example of a video encoder 100 configured to implement the embodiments presented herein. Figure 1 In the example shown, the video encoder 100 includes a partition module 112, a transform module 114, a quantization module 115, an inverse quantization module 118, an inverse transform module 119, a loop filter module 120, an intra-frame prediction module 126, an inter-frame prediction module 124, a motion estimation module 122, a decoded image cache 130 and an entropy encoding module 116.

[0023] The input of the video encoder 100 is an input video 102 comprising a sequence of pictures (also referred to as frames or images). In a block-based video encoder, for each image, the video encoder 100 uses a partitioning module 112 to partition the image into blocks 104, each block comprising a plurality of pixels. Blocks may be macroblocks, coding tree units, coding units, prediction units and / or prediction blocks. An image may comprise blocks of different sizes, and the block partitioning may also be different for different images of the video. Each block may be encoded using a different prediction (e.g., intra prediction or inter prediction or a mixture of intra and inter prediction).

[0024] Typically, the first picture of a video signal is an intra-coded picture, which is coded using only intra-frame prediction. In intra-frame prediction mode, blocks of a picture are predicted using only coded data from the same picture. Intra-coded pictures can be decoded without the presence of information from other pictures. To perform intra-frame prediction, Figure 1The illustrated video encoder 100 may employ an intra prediction module 126. The intra prediction module 126 is configured to generate an intra prediction block (prediction block 134) using reconstructed samples in a reconstruction block 136 of a neighboring block of the same image. Intra prediction is performed according to the intra prediction mode selected for the block. The video encoder 100 then calculates the difference between the block 104 and the intra prediction block 134. The difference is referred to as a residual block 106.

[0025] 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 may include, but are not limited to, discrete cosine transforms (DCT) or discrete sine transforms (DST). The transformed values ​​may be referred to as transform coefficients, which represent the residual block in the transform domain. In some examples, the residual block may be quantized directly without having to be transformed by the transform module 114. This is referred to as a transform skip mode.

[0026] The video encoder 100 may further quantize the transform coefficients using the quantization module 115 to obtain quantized coefficients. Quantization involves dividing the samples by the quantization step size followed by rounding, while inverse quantization involves multiplying the quantized values ​​by the quantization step size. This quantization process is called scalar quantization. Quantization is used to reduce the dynamic range of (transformed or untransformed) video samples so that fewer bits are used to represent the video samples.

[0027] The quantization of coefficients / samples within a block can be performed independently, and this quantization method is used in some existing video compression standards (such as H.264 and HEVC). For N times M blocks, a certain scanning order can be used to convert the 2D coefficients of the block into a 1-D array for coefficient quantization and encoding. The quantization of coefficients within a block can use scanning order information. For example, the quantization of a given coefficient in a block may depend on the state of the previous quantization value in the scanning order. In order to further improve the coding efficiency, multiple quantizers can be used. Which quantizer is used to quantize the current coefficient depends on the information before the current coefficient in the encoding / decoding scanning order. This quantization method is called dependent quantization.

[0028] The quantization step size can be used to adjust the degree of quantization. For example, for scalar quantization, different quantization step sizes can be applied to achieve finer or coarser quantization. A smaller quantization step size corresponds to finer quantization, while a larger quantization step size corresponds to coarser quantization. The quantization step size can be indicated by a quantization parameter (QP). The quantization parameter is provided in the encoded bitstream of the video so that the video decoder can obtain and apply the quantization parameter for decoding.

[0029] Then, the quantized samples are encoded by the entropy coding module 116 to further reduce the size of the video signal. The entropy coding module 116 is configured to apply an entropy coding algorithm to the quantized samples. In some examples, the quantized samples are binarized into binary bins, and the coding 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 finite k-order exponential Columbus (EGk) binarization, and k-order exponential Columbus binarization. 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), grammar-based context adaptive binary arithmetic coding (SBAC), probability interval segmentation entropy (PIPE) coding or other entropy coding techniques. Entropy coded data is added to the bitstream of the output coded video 132.

[0030] As discussed above, the reconstructed block 136 from the neighboring blocks is used in the intra prediction of the block of the image. The generation of the reconstructed block 136 of the block involves calculating the reconstructed residual of the block. The reconstructed residual can be determined by applying inverse quantization and inverse transform to the quantized residual of the block. The inverse quantization module 118 is configured to apply inverse quantization to the quantized samples to obtain dequantized coefficients. The inverse quantization module 118 applies the inverse scheme of the quantization scheme applied by the quantization module 115 by using the same quantization step size as the quantization module 115. The inverse transform module 119 is configured to apply the inverse transform of the transform applied by the transform module 114 to the dequantized samples, such as inverse DCT or inverse DST. The output of the inverse transform module 119 is the reconstructed residual of the block in the pixel domain. The reconstructed residual can be added to the prediction block 134 of the block to obtain the reconstructed block 136 in the pixel domain. For blocks that skip the transform, the inverse transform module 119 will not be applied to these blocks. The dequantized samples are the reconstructed residual of the block.

[0031] Blocks in subsequent images following a first intra-predicted image may be encoded using inter-prediction or intra-prediction. In inter-prediction, a prediction of a block in an image comes from one or more previously encoded video images. To perform inter-prediction, the video encoder 100 uses an inter-prediction module 124. The inter-prediction module 124 is configured to perform motion compensation on the block based on the motion estimate provided by the motion estimation module 122.

[0032] 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 cache 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-frame prediction module 124 along with the selected reference block. In some cases, multiple reference blocks are identified for the current block in multiple decoded reference images 108. Therefore, multiple motion vectors are generated and the motion vectors are provided to the inter-frame prediction module 124 along with the corresponding reference blocks.

[0033] The inter-frame prediction module 124 uses the motion vector and other inter-frame prediction parameters to perform motion compensation to generate a prediction of the current block, i.e., an inter-frame prediction block 134. For example, based on the motion vector, the inter-frame prediction module 124 can locate the prediction block pointed to by the motion vector in the corresponding reference image. If there are multiple prediction blocks, these prediction blocks are combined with some weights to generate the prediction block 134 of the current block.

[0034] For an inter-frame prediction block, the video encoder 100 can subtract the inter-frame prediction block 134 from the block 104 to generate a residual block 106. The residual block 106 can be transformed, quantized, and entropy encoded in the same manner as the residual of the intra-frame prediction block discussed above. Similarly, the reconstructed block 136 of the inter-frame prediction block can be obtained by inverse quantizing, inverse transforming, and then combining the residual with the corresponding prediction block 134.

[0035] To obtain a decoded image 108 for motion estimation, the reconstructed block 136 is processed by a loop filter module 120. The loop filter module 120 is configured to smooth pixel transitions, thereby improving video quality. The loop filter module 120 may be configured to implement one or more loop filters, such as a deblocking filter, a sample adaptive offset (SAO) filter, an adaptive loop filter (ALF), etc.

[0036] Figure 2 An example of a video decoder 200 configured to implement the embodiments presented herein is depicted. The video decoder 200 processes the encoded video 202 in the bitstream and generates a decoded image 208. Figure 2 In the example shown, the video decoder 200 includes an entropy decoding module 216 , an inverse quantization module 218 , an inverse transform module 219 , a loop filter module 220 , an intra prediction module 226 , an inter prediction module 224 , and a decoded picture buffer 230 .

[0037] The entropy decoding module 216 is configured to perform entropy decoding of the encoded video 202. The entropy decoding module 216 decodes quantized coefficients, encoding parameters including intra-frame prediction parameters and inter-frame 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 coefficients. The entropy decoded coefficient levels are then inverse quantized by the inverse quantization module 218, and then inversely 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 those described above for Figure 1 The inverse quantization module 118 and the inverse transform module 119 are described. The inverse transformed residual block can be added to the corresponding prediction block 234 to generate a reconstructed block 236. For blocks that skipped the transform, the inverse transform module 219 is not applied to these blocks. The dequantized samples generated by the inverse quantization module 218 are used to generate the reconstructed block 236.

[0038] The 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 may be fed into 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 inter-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 Figure 1 The intra-frame prediction module 126 and the inter-frame prediction module 124 are described below.

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

[0040] Reference now Figure 3 , Figure 3 Depicted is an example of coding tree unit partitioning of an image in a video according to some embodiments of the present disclosure. Figure 1 and Figure 2 As discussed, in order to encode an image of a video, the image is divided into blocks, such as CTU (Coding Tree Unit) 302 in VVC, as shown in FIG. Figure 3 For example, CTU 302 may be a block of 128×128 pixels. Figure 3 In some examples, each CTU 302 in the image may be divided into Figure 4One or more CUs (coding units) 402 are shown, and the CUs 402 can be further divided into prediction units or transform units (TUs) for prediction and transformation. Depending on the coding scheme, the CTU 302 can be divided into CUs 402 in different ways. For example, in VVC, the CU 402 can be rectangular or square and can be encoded without further division into prediction units or transform units. Each CU 402 can be as large as its root CTU 302, or can be a sub-partition of the root CTU 302 (as small as 4×4 blocks). Figure 4 As shown, in VVC, CTU 302 is divided into CU 402, which can be quadtree division, binary tree division or ternary tree division. Figure 4 In the figure, the solid line indicates a quadtree partition, and the dashed line indicates a binary or ternary tree partition.

[0041] General constraints in VVC version 1 (VVCv1)

[0042] In VVC version 1, the general constraint information (GCI) syntax structure general_constraints_info() is used to indicate specific constraint properties of a codestream. GCI contains a list of constraint flags and non-flag syntax elements. The binary flag gci_present_flag is used to specify whether a GCI syntax element is present. gci_present_flag equal to 1 specifies that the GCI syntax element is present in the general_constraints_info() syntax structure. gci_present_flag equal to 0 specifies that there is no GCI field in the general_constraints_info() syntax structure and that the general_constraint_info() syntax structure does not impose any constraints.

[0043] The general constraint information may be signaled in a high-level syntax in multiple contexts. For example, the GCI may be signaled in a network packet containing only decoding capability information, such as a Network Abstraction Layer (NAL) packet carrying only decoding capability information with its nal_unit_type set to 13 (i.e., DCI_NUT as the name of nal_unit_type). Alternatively, the GCI may be signaled in a video parameter set or in a sequence parameter set.

[0044] The purpose of the GCI syntax structure is to enable discovery of configuration information related to features required to decode a bitstream and to allow signaling of interoperability points that impose restrictions beyond those specified by profiles, tiers, and levels (PTLs) at a finer granularity than previous video coding standards allow. Similar to sub-profiles, the use of the GCI syntax structure allows interoperability to be defined for decoder implementations that do not support all features of the VVC profile but address the needs of specific applications. Decoder implementations can examine GCI syntax elements to check whether a bitstream avoids the use of specific features in order to determine how to configure the decoding process and confirm whether the bitstream can be decodable by the decoder. Decoder implementations that support all features of the VVC profile can ignore the GCI syntax element values, as such decoders will be able to decode any bitstream that conforms to the indicated PTL.

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

[0046] The presence of the general constraint flag depends on the value of gci_present_flag. When the value of gci_present_flag is 1, the general constraint flag is present in the bitstream. When the value of gci_present_flag is 0, the general constraint flag is not present in the bitstream.

[0047] In addition to the general constraint flags defined by VVCv1, additional general constraint flags can be provided through 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 signaled in the general constraint syntax structure. In the VVC specification, these additional bits are extracted and discarded from the bitstream (called the syntax element gci_reserved_zero_bit[i]). Such a provision enables the VVCv1 decoder to be forward compatible with at least the high-level syntax part of the bitstream generated by subsequent versions of VVC.

[0048] General constraints in VVC version 2 (VVCv2)

[0049] In the current draft of VVC version 2 ("VVC operating range extension (Draft 5)", a document published by the Joint Video Experts Group of ITU-T SG 16WP 3 and ISO / IEC JTC 1 / SC 29, JVET-X2005), it is proposed that multiple additional coding tools be constrained through a 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 adjusted syntax of the proposed VVCv2 is as follows:

[0050] There are a total of 6 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 proposed interpretation ("semantics") of the gci_num_additional_bits syntax element is as follows: gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to either 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T | ISO / IEC. Although values ​​of gci_num_additional_bits equal to either 0 or 1 are required in this version of this document, decoders conforming to this version of this 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 when gci_num_additional_bits is greater than 1. It is recommended that, if a VVCv2 codestream signals general constraints information, the syntax element gci_num_additional_bits should be set to 0 if the 6 VVCv2 general constraints flags are not signaled, and should be set to 1 if the 6 VVCv2 general constraints flags are signaled.

[0051] However, the VVCv2 specification of the general constraint syntax proposed above results in incompatibility with the VVCv1 decoder. Specifically, when an additional general constraint flag is signaled, the proposed VVCv2 syntax signals the general constraint flag by setting gci_num_additional_bits to 1. In the VVCv2 decoder, when general constraint information is signaled, the gci_num_additional_bits syntax element is decoded from the bitstream as an 8-bit unsigned integer. If gci_num_additional_bits decodes to a value of 1, 6 additional bits will be decoded from the bitstream. These 6 bits are interpreted as general constraint flags for additional decoding tools that can be constrained in VVCv2.

[0052] In a VVCv1 decoder, the same 8-bit field is interpreted as gci_num_reserved_bits. However, if this syntax element decodes to a value of 1, only 1 additional bit is decoded from the bitstream. This bit is discarded and not used. Therefore, a VVCv1 decoder decoding a VVCv2 bitstream may experience desynchronization due to the presence of 5 additional bits in the bitstream that are not recognized by the VVCv1 specification.

[0053] As discussed above, desynchronization is a serious incompatibility issue between different versions of the video coding standard. A VVCv1 decoder may not be able to decode the entire VVCv2 codestream because the VVCv2 codestream may use coding tools that are defined in the VVCv2 specification but are unknown to the VVCv1 decoder. However, it is hoped that the VVCv1 decoder should be able to decode at least the high-level syntax portion of the VVCv2 codestream. By successfully decoding the high-level syntax, the video decoder can determine not only the general constraint information, but also the profile and layer information. Such information provides the decoder with hints about the capabilities required to decode the codestream. For example, the general constraint information provides the decoder with indications about which coding tools are constrained by the codestream. The profile and layer information provide the decoder with indications about the uncompressed video data throughput (e.g., video data rate, frame rate, resolution, etc.) that needs to be supported.

[0054] If the high-level syntax is decoded successfully, the video decoder can determine whether the current code stream can be decoded. If not, the decoder can terminate the decoding process normally. Conversely, a desynchronization during the high-level syntax decoding process means that the information provided in the high-level syntax may not be decoded correctly. In the worst case, the decoder may decode completely wrong syntax element values ​​after a desynchronization event, which can lead to incorrect parameter settings and subsequent incorrect decoding of low-level syntax, resulting in decoding failure.

[0055] Additionally, in the VVCv2 decoder, when generic constraint information is signaled, the gci_num_additional_bits syntax element is decoded from the bitstream as an 8-bit unsigned integer. If gci_num_additional_bits decodes to a value of 0, no further generic constraint flags are signaled. In this case, no inferred value is assigned to the additional generic constraint flag, and the value of the additional generic constraint flag is undefined. Therefore, the behavior of whether the coding tool associated with the additional generic constraint flag should be constrained or not is ambiguous, which can lead to inconsistent decoder implementations.

[0056] In the VVC specification, the name of the syntax element gci_reserved_zero_bit[i] is misleading, implying that the value of such syntax elements must be 0. Normally, when reserved syntax elements are written to the bitstream as placeholders by an encoder, the default value is embedded in the name of the reserved syntax element. However, the design of the generic constraint syntax structure means that gci_reserved_zero_bit[i] is never written by the encoder. gci_reserved_zero_bit[i] is only used when a specific version of the VVC decoder reads a higher version of the VVC bitstream. In this case, the value of gci_reserved_zero_bit[i] is not guaranteed to be 0. In the following, multiple solutions are proposed to solve the above problems.

[0057] Signaling General Constraint Information

[0058] In one embodiment of signaling general constraint information to address the out-of-sync issues discussed above, if the 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 can be constrained, the syntax element gci_num_additional_bits 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 in the bitstream are used to signal the general constraint flags for the N additional coding tools. In one example, N is set to 6.

[0059] For a 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 still process general constraint information with gci_num_additional_bits set to a value other than 0 or N. For example, gci_num_additional_bits can be set to a value greater than 0 and less than N, or set to a value greater than N. The decoded value of gci_num_additional_bits is denoted as M. Then, if 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. If 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. Then, the decoder also extracts (M - N) bits from the bitstream as the gci_reserved_zero_bit[i] syntax element and discards these (M - N) bits.

[0060] In other examples, the VVCv2 decoder does not need to process general constraint information with gci_num_additional_bits set 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. Future versions of VVC bitstreams will not be allowed to set gci_num_additional_bits to a value between 0 and N.

[0061] In an example of this embodiment, the general constraint information syntax of VVCv2 is modified using the 6 general constraint flags currently proposed for the VVCv2 encoding tool, as shown in Table 1 below (added content is underlined and deleted content is shown with strikethrough), where "if (gci_num_additional_bits>0)" is replaced with "if (gci_num_additional_bits>5)". Table 1

[0062] In one example, if there are 6 additional general constraint flags for coding tools in VVCv2, the corresponding semantics of gci_num_additional_bits are (additions are underlined, deletions are shown in strikethrough): gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 gci_num_additional_bits Apart from Other than 0 or 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits to appear in the grammar. Except 0 or 6 The value should be in gci_num_additional_bits Except 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when

[0063] In the example of the semantics of gci_num_additional_bits described above, in addition to the values ​​0 or 6 discussed above, gci_num_additional_bits is allowed to take values ​​other than 0 or 6. In other words, gci_num_additional_bits can take values ​​between 1 and 5. It is also allowed that gci_num_additional_bits takes values ​​greater than 6. If gci_num_additional_bits has a value between 1 and 5, which is denoted as M, then according to the syntax shown in Table 1 above, the decoder will skip the steps performed when the "if" condition is true and jump to the "else" step so that the value of "numAdditionalBitsUsed" is assigned to 0. Then, M bits will be read in the "for" loop and these M bits will be discarded. In this way, the problem of out-of-step can be avoided. If the value M of gci_num_additional_bits is greater than 6, 6 additional general constraint flags will be extracted, and the remaining M-6 bits will be further extracted and discarded.

[0064] In another example, if there are 6 additional general constraint flags for coding tools in VVCv2, the corresponding semantics of gci_num_additional_bits are (additions are underlined and deletions are shown in strikethrough): gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 . gci_num_additional_bits is greater than 1 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits greater than 1 to appear in the syntax. 6 The value of gci_num_additional_bits should be greater than 1 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when

[0065] In another embodiment of signaling general constraint information, if the VVCv2 codestream 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 may be set to a value of M. M is in the range of 0 to N (inclusive) (0≤M≤N). If gci_num_additional_bits is set to 0, the general constraint flag for the N additional coding tools is not signaled. If gci_num_additional_bits is set to a non-zero value M, the next M bits in the codestream are used to signal the general constraint flags for M 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.

[0066] In an example of this embodiment, the modification of the VVCv2 general constraint information syntax using the six general constraint flags currently proposed for the VVCv2 coding tool may be as follows:

[0067] In another example of this embodiment, a more compact syntax table may be used to achieve equivalent behavior:

[0068] An alternative arrangement of this embodiment may be expressed in the generic constraint information syntax by changing the order of the generic constraint flags for the VVCv2 coding tool.

[0069] If there are 6 additional general constraint flags for coding tools in VVCv2, the corresponding semantics of gci_num_additional_bits may be as follows: gci_num_additional_bits specifies the number of bits in the general constraint information syntax structure except gci_alignment_ The number of additional GCI bits beyond the zero_bit syntax element (when present). In the , the value of gci_num_additional_bits shall be in the range of 0 to 6, inclusive, for the endpoint. Values ​​of additional_bits greater than 6 are reserved for future use by ITU-T|ISO / IEC. This document requires that the value of gci_num_additional_bits be in the range of 0 to 6, inclusive, but conforming to this document This version of the decoder shall allow values ​​of gci_num_additional_bits greater than 6 to appear in the syntax and shall When gci_num_additional_bits is greater than 6, the values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored.

[0070] 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, when the VVCv2 codestream signals general constraint information (i.e., if the value of gci_present_flag is 1), no constraints are imposed on the coding tools corresponding to the additional general constraint flags that are not signaled. This behavior can be expressed by modifying the semantics of gci_num_additional_bits as follows: gci_num_additional_bits specifies the number of bits in the general constraint information syntax structure except gci_alignment_ The number of additional GCI bits beyond the zero_bit syntax element (when present). In the , the value of gci_num_additional_bits shall be in the range of 0 to 6, inclusive, for the endpoint. Values ​​of additional_bits greater than 6 are reserved for future use by ITU-T|ISO / IEC. This document requires that the value of gci_num_additional_bits be in the range of 0 to 6, inclusive, but conforming to this document This version of the decoder shall allow values ​​of gci_num_additional_bits greater than 6 to appear in the syntax and shall When gci_num_additional_bits is greater than 6, the value of all gci_reserved_zero_bit[i] syntax elements is ignored. In addition, when gci_present_flag is equal to 1, no The corresponding constraint flag imposes any constraints on the encoding tool.

[0071] In another arrangement of this embodiment, when the VVCv2 codestream signals general constraint information (i.e., if the value of gci_present_flag is 1), and does not signal the additional general constraint flag, the corresponding tool is constrained. This behavior can be expressed by modifying the semantics of the additional general constraint flag as follows: gci_num_additional_bits specifies the number of bits in the general constraint information syntax structure except gci_alignment_ The number of additional GCI bits beyond the zero_bit syntax element (when present). In the , the value of gci_num_additional_bits shall be in the range of 0 to 6, inclusive, for the endpoint. Values ​​of additional_bits greater than 6 are reserved for future use by ITU-T|ISO / IEC. This document requires that the value of gci_num_additional_bits be in the range of 0 to 6, inclusive, but conforming to this document This version of the decoder shall allow values ​​of gci_num_additional_bits greater than 6 to appear in the syntax and shall When gci_num_additional_bits is greater than 6, the values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. 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. gci_all_rap_pictures_constraint_flag equal to 0 does not impose such a constraint. When gci_present_flag is equal to 1 and there is no gci_ When all_rap_pictures_constraint_flag is set, gci_all_rap_pictures_constraint_flag is inferred The value is equal to 1. gci_no_extended_precision_processing_constraint_flag equal to 1 specifies that the sps_extended_precision_flag of all pictures in OlsInScope shall be equal to 0. gci_no_extended_precision_processing_constraint_flag equal to 0 does not impose such a constraint. When gci_present_ When flag is equal to 1 and gci_no_extended_precision_processing_constraint_flag is not present, inference The value of gci_no_extended_precision_processing_constraint_flag is equal to 1. gci_no_ts_residual_coding_rice_constraint_flag equal to 1 specifies that sps_ts_residual_coding_rice_present_in_sh_flag for all pictures in OlsInScope shall be equal to 0. gci_no_ts_residual_coding_rice_constraint_flag equal to 0 does not impose such a constraint. When gci_present_ When flag is 1 and gci_no_ts_residual_coding_rice_constraint_flag is not present, gci_no_ The value of ts_residual_coding_rice_constraint_flag is equal to 1. gci_no_rrc_rice_extension_constraint_flag equal to 1 specifies that the sps_rrc_rice_extension_flag of all pictures in OlsInScope shall be equal to 0. gci_no_rrc_rice_extension_constraint_flag equal to 0 does not impose such a constraint. When gci_present_flag is equal to 1 and gci_no_ When rrc_rice_extension_constraint_flag is set, gci_no_rrc_rice_extension_ The value of constraint_flag is equal to 1. gci_no_persistent_rice_adaptation_constraint_flag equal to 1 specifies that the sps_persistent_rice_adaptation_enabled_flag of all pictures in OlsInScope shall be equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to 0 does not impose such a constraint. When gci_ When present_flag is equal to 1 and gci_no_persistent_rice_adaptation_constraint_flag does not exist, The value of gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 1. gci_no_reverse_last_sig_coeff_constraint_flag equal to 1 specifies that sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope shall be equal to 0. gci_no_reverse_last_sig_coeff_constraint_flag equal to 0 does not impose such a constraint. When gci_present_flag is equal to 1 and gci_no_reverse_last_sig_coeff_constraint_flag is not present, the value of gci_no_reverse_last_sig_coeff_constraint_flag is inferred to be equal to 1.

[0072] Initializes the general constraint information flag

[0073] An embodiment of initializing the general constraint information flags is described to resolve the ambiguity and inconsistency of decoder implementations discussed above. In this embodiment, when gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, general_constraints_info() does not impose constraints on coding tools related to the following: 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.

[0074] As an example, a possible change in the semantics of gci_num_additional_bits is shown below, based on the current version of the VVC version 2 specification (additions are underlined, deletions are shown in strikethrough). gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to either 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T | ISO / IEC. Although values ​​of gci_num_additional_bits equal to either 0 or 1 are required in this version of this document, decoders conforming to this version of this 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 when gci_num_additional_bits is greater than 1. When gci_present_flag is equal to 1 and gci_num_additional_ When bits is equal to 0, general_constraints_info() does not impose any constraints on the coding tools related to Constraints: 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.

[0075] As another example, a possible change in the semantics of gci_num_additional_bits is shown below, which is based on the current version of the VVC version 2 specification. gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 gci_num_additional_bits Apart from Other than 0 or 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits to appear in the grammar. Except 0 or 6 The value should be in gci_num_additional_bits Except 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When 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 tools related to: gci_all_rap_ pictures_constraint_flag, gci_no_extended_precision_processing_constraint_ flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_ coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag and gci_no_ persistent_rice_adaptation_constraint_flag.

[0076] In the current version of the VVC version 2 specification, the semantics of gci_num_additional_bits is used only when gci_present_flag is equal to 1. The scenario of gci_present_flag equal to 0 is addressed in a different section of the VVC version 2 specification. Therefore, the "when gci_present_flag is equal to 1" in the semantics of gci_num_additional_bits above is automatically satisfied. In addition, since the VVC version 2 specification does not allow gci_num_additional_bits to take values ​​between 1 and 5, "gci_num_additional_bits is equal to 0" is equivalent to "gci_num_additional_bits is less than or equal to 5" or "gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag and gci_no_persistent_rice_adaptation_constraint_flag are not present". Therefore, the above changes in the semantics of gci_num_additional_bits are equivalent to the following: gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 gci_num_additional_bits Apart from Other than 0 or 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits to appear in the grammar. Except 0 or 6The value should be in gci_num_additional_bits Except 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When 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_ general_ when constraint_flag and gci_no_persistent_rice_adaptation_constraint_flag constraints_info() does not impose any constraints on the encoding tools related to: gci_all_rap_ pictures_constraint_flag, gci_no_extended_precision_processing_constraint_ flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_ coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag and gci_no_ persistent_rice_adaptation_constraint_flag .

[0077] Below are several examples where the inferred value of the additional general constraint flag can be set in a similar manner to the semantics described above. For example, the semantics of the additional general constraint flag can be modified as follows to include the inferred value setting: 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. gci_all_rap_pictures_constraint_flag equal to 0 does not impose such a constraint. When not present, gci_all_rap_pictures_ is inferred The value of constraint_flag is equal to 0. gci_no_extended_precision_processing_constraint_flag equal to 1 specifies that the sps_extended_precision_flag of all pictures in OlsInScope shall be equal to 0. gci_no_extended_precision_processing_constraint_flag equal to 0 does not impose such a constraint. When not present, inference The value of gci_no_extended_precision_processing_constraint_flag is equal to 0. gci_no_ts_residual_coding_rice_constraint_flag equal to 1 specifies that sps_ts_residual_coding_rice_present_in_sh_flag for all pictures in OlsInScope shall be equal to 0. gci_no_ts_residual_coding_rice_constraint_flag equal to 0 does not impose such a constraint. When not present, inference The value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0. gci_no_rrc_rice_extension_constraint_flag equal to 1 specifies that the sps_rrc_rice_extension_flag of all pictures in OlsInScope shall be equal to 0. gci_no_rrc_rice_extension_constraint_flag equal to 0 does not impose such a constraint. When not present, gci_no_rrc_rice_ is inferred The value of extension_constraint_flag is equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to 1 specifies that the sps_persistent_rice_adaptation_enabled_flag of all pictures in OlsInScope shall be equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to 0 does not impose such a constraint. When there is no When gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 0. gci_no_reverse_last_sig_coeff_constraint_flag equal to 1 specifies that sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope shall be equal to 0. gci_no_reverse_last_sig_coeff_constraint_flag equal to 0 does not impose such a constraint. When not present, gci_no_ The value of reverse_last_sig_coeff_constraint_flag is equal to 0.

[0078] In another example, the semantics of the additional_general_constraints flags() is modified as follows: 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. gci_all_rap_pictures_constraint_flag equal to 0 does not impose such a constraint. When gci_all_rap_pictures_ does not exist When constraint_flag is set, the value of gci_all_rap_pictures_constraint_flag is inferred to be equal to 0. gci_no_extended_precision_processing_constraint_flag equal to 1 specifies that the sps_extended_precision_flag of all pictures in OlsInScope shall be equal to 0. gci_no_extended_precision_processing_constraint_flag equal to 0 does not impose such a constraint. When gci_no_ is not present extended_precision_processing_constraint_flag, infer gci_no_extended_ The value of precision_processing_constraint_flag is equal to 0. gci_no_ts_residual_coding_rice_constraint_flag equal to 1 specifies that sps_ts_residual_coding_rice_present_in_sh_flag for all pictures in OlsInScope shall be equal to 0. gci_no_ts_residual_coding_rice_constraint_flag equal to 0 does not impose such a constraint. When gci_no_ is not present When ts_residual_coding_rice_constraint_flag is set, infer gci_no_ts_residual_coding_rice_ The value of constraint_flag is equal to 0. gci_no_rrc_rice_extension_constraint_flag equal to 1 specifies that the sps_rrc_rice_extension_flag of all pictures in OlsInScope shall be equal to 0. gci_no_rrc_rice_extension_constraint_flag equal to 0 does not impose such a constraint. When gci_no_rrc_rice_extension_ is not present When constraint_flag is set, the value of gci_no_rrc_rice_extension_constraint_flag is inferred to be equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to 1 specifies that the sps_persistent_rice_adaptation_enabled_flag of all pictures in OlsInScope shall be equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to 0 does not impose such a constraint. When there is no gci_no_persistent_rice_adaptation_constraint_flag is set, inferring gci_no_persistent_ The value of rice_adaptation_constraint_flag is equal to 0. gci_no_reverse_last_sig_coeff_constraint_flag equal to 1 specifies that sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope shall be equal to 0. gci_no_reverse_last_sig_coeff_constraint_flag equal to 0 does not impose such a constraint. When gci_no_reverse_last_ is not present gci_no_reverse_last_sig_coeff_constraint_flag is inferred when sig_coeff_constraint_flag is set The value is equal to 0 .

[0079] In another example, the semantics of gci_num_additional_bits is modified as follows: gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 . gci_num_additional_bits is greater than 1 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits greater than 1 to appear in the syntax. 6 The value of gci_num_additional_bits should be greater than 1 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When gci_num_additional_bits is equal to 0 , it is inferred that all constraint flags specified by the additional GCI bits are equal to 0.

[0080] In another example, the semantics of gci_num_additional_bits is modified as follows: gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 . gci_num_additional_bits is greater than 1 6The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits greater than 1 to appear in the syntax. 6 The value of gci_num_additional_bits should be greater than 1 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When not present, it is inferred that the additional GCI bit is specified All constraint flags are equal to 0 .

[0081] In another example, the syntax and semantics of the general constraint information syntax element are modified as follows: gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 . gci_num_additional_bits is greater than 1 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits greater than or equal to 0 to appear in the syntax. 6 The value of gci_num_additional_bits should be greater than 1 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When gci_num_additional_bits is equal to 0 The additional_general_constraints_info() syntax structure does not impose any constraints.

[0082] In another example, the semantics of the general constraint information syntax element is modified as follows: gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 . gci_num_additional_bits is greater than 1 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits greater than 1 to appear in the syntax. 6 The value of gci_num_additional_bits should be greater than 1 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When not present, additional_general_ The constraints_info() syntax does not impose any constraints.

[0083] In another embodiment of initializing the general constraint information flags, when gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, 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 apply the corresponding constraints specified by the respective semantics of these flags. In other words, when the GCI flags are present and gci_num_additional_bits is equal to 0, these six GCI flags are inferred to be equal to 1.

[0084] As an example, a possible change in the semantics of gci_num_additional_bits is shown below, based on the currently added VVC version 2 specification. gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to either 0 or 1. Values ​​of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T | ISO / IEC. Although values ​​of gci_num_additional_bits equal to either 0 or 1 are required in this version of this document, decoders conforming to this version of this 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 when gci_num_additional_bits is greater than 1. When gci_present_flag is equal to 1 and gci_num_additional_ When bits is equal to 0, 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 is equal to 1.

[0085] As another example, a possible change in the semantics of gci_num_additional_bits is shown below, based on the currently added VVC version 2 specification. gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In codestreams conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 gci_num_additional_bits Apart from Other than 0 or 6 The value of gci_num_additional_bits is 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 equal to 0 or 1 6 , but decoders conforming to this version of this document shall allow gci_num_additional_bits to appear in the grammar. Except 0 or 6 The value should be in gci_num_additional_bits Except 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored when When gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, 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 is equal to 1.

[0086] In addition to or as an alternative to the embodiments discussed above, the misleading syntax element gci_reserved_zero_bit[i] may be renamed to gci_reserved_bit[i]. For example, the modified syntax and semantics may be as follows: gci_reserved_bit[i] May have any value. Its presence and value have no effect on the decoding process specified in this version of this specification. Decoders conforming to this version of this specification should ignore all gci_reserved_bit[i] The value of a syntax element.

[0087] In a further embodiment, the syntax element gci_reserved_zero_bit[i] is renamed to gci_reserved_bit[i]. For example, the modified syntax and semantics may be as follows: gci_reserved_bit[i] May have any value. Its presence and value have no effect on the decoding process specified in this version of this specification. Decoders conforming to this version of this specification should ignore all gci_reserved_bit[i] The value of the syntax element.

[0088] General restriction signs

[0089] gci_all_rap_pictures_constraint_flag

[0090] gci_all_rap_pictures_constraint_flag is used to indicate the restriction of pictures to be IRAP or GDR pictures.

[0091] The Network Abstraction Layer (NAL) is a system interface that organizes VVC syntax elements into "NAL units". This structure allows VVC to be easily and efficiently customized for a wide variety of use cases, ranging 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:

[0092] NAL units classified as Video Coding Layer (VCL) contain low-level syntax elements, while NAL units classified as non-VCL contain high-level syntax elements. Images of a video sequence are decoded based on VCL NAL units. The different types of VCL categories are useful at a high level to indicate dependencies. For example, NAL units from TRAIL_NUT (0) to RSV_VCL_6 (6) typically can use inter-frame prediction tools, which rely on access to previously decoded (reference) images. Images encoded using inter-frame prediction tools can be compressed more efficiently than images compressed using only intra-frame prediction tools. However, this decoding dependency can introduce problems when reference images are not available.

[0093] An intra random access point (IRAP) picture is a coded picture whose all VCL NAL units have the same nal_unit_type value in the range of IDR_W_RADL to CRA_NUT (inclusive). An IRAP picture can be a CRA picture or an IDR picture. An IRAP picture does not use inter prediction from reference pictures in the same layer during its decoding. The first picture in the codestream in decoding order is an IRAP picture or a gradual decoding refresh (GDR) picture. For a single-layer codestream, if the necessary parameter sets are available when they are needed to be referenced, the IRAP picture and all subsequent non-RASL pictures arranged in the CLVS in decoding order can be correctly decoded without performing the decoding process on any pictures before the IRAP picture in the decoding order. The value of pps_mixed_nalu_types_in_pic_flag for an IRAP picture is equal to 0. When pps_mixed_nalu_types_in_pic_flag of a picture is equal to 0, and nal_unit_type of any slice of the picture is in the range of IDR_W_RADL to CRA_NUT (including endpoints), all other slices of the picture have the same nal_unit_type value, and after receiving the first slice, it is known that the picture is an IRAP picture.

[0094] Therefore, IRAP pictures do not use inter-frame prediction on the same layer. This limitation makes IRAP pictures useful as error recovery points in streaming video applications, or as seek points in video-on-demand playback applications. However, the compression efficiency of IRAP pictures is generally lower than that of non-IRAP pictures.

[0095] Gradual Decoding Refresh (GDR) pictures were introduced in the VVC standard as a trade-off between non-IRAP and IRAP pictures. GDR pictures have some "clean" parts that do not use inter-frame prediction, while the rest of the picture is free to use inter-frame prediction. By dividing the picture in this way, in the event of an error such as packet loss, the "clean" parts will still be decoded correctly. In consecutive GDR pictures, the spatial position of the "clean" parts rotates so that the entire picture can eventually be recovered from the error.

[0096] For video applications where streaming recovery with playback flexibility is important, it may be desirable to constrain all pictures to be either IRAP pictures or GDR pictures. In VVCv2, the GCI flag gci_all_rap_pictures_constraint_flag was introduced so that such a restriction can be indicated 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. gci_all_rap_pictures_constraint_flag equal to 0 does not impose such a constraint. When 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.

[0097] When the profile_tier_level() syntax structure is included in a VPS, OlsInScope is one or more output layer sets (OLS) specified by the VPS. When the profile_tier_level() syntax structure is included in an SPS, OlsInScope is an OLS that includes only the lowest layer of the layers referenced by the SPS, and the lowest layer is an independent layer.

[0098] gci_no_extended_precision_processing_constraint_flag

[0099] The GCI flag gci_no_extended_precision_processing_constraint_flag signals at a high level whether the VVCv2 tools for extended transform precision are constrained. 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 through integer operations. This restriction is important for reasons of complexity and interoperability. First, integer operations (addition, multiplication, division) are typically less computationally expensive than equivalent floating-point operations. Second, floating-point operations are not deterministically standardized. Floating-point addition and multiplication are not necessarily commutative (for example, (a+b)+c is not necessarily equal to a+(b+c)), and there is no guarantee that the evaluation of floating-point operations on different platforms is the same.

[0100] The bit depth of the video signal samples is a property of the video source, denoted as BitDepth in the VVC standard. In a hybrid video coding system, video samples are predicted by an inter-frame prediction tool or an intra-frame prediction tool. The difference between the original video sample and the predicted sample is called the residual. In the worst case, these residual coefficients can have an extended bit depth (e.g., BitDepth+1); however, in the VVC standard, the residual coefficients are pruned to maintain the bit depth of BitDepth. In practice, the worst case does not occur because a practical encoder will not select a prediction tool that produces a residual with a larger amplitude than the original video signal.

[0101] The residual coefficients are then typically analyzed by an integerized discrete cosine transform (DCT) to produce transform coefficients. The discrete cosine transform (DCT) is a linear reversible function that can be formally represented as: in Represents N-dimensional real number space. In the VVC standard, the integer approximation of DCT is used (i.e. ). Unlike prediction, some degree of expansion of the bit depth is usually allowed at the transform stage, since the accuracy of the transform affects the coding gain. The bit depth of the approximated DCT coefficients and the bit depth of the resulting transform coefficients are design decisions that balance hardware complexity and coding performance.

[0102] In VVCv1, the bit depth of the transform coefficients is 16. That is, each transform coefficient is in the range [-2 15 , 2 15 -1]. The video samples are multiplied by the integerized DCT coefficients, usually producing intermediate transform coefficients with a bit depth greater than 16. In order to produce transform coefficients with the desired bit depth, the intermediate transform coefficients are shifted to the right. Such an operation is inherently lossy.

[0103] In VVCv2, extended transform precision is enabled by setting the SPS flag sps_extended_precision_flag to 1. If extended transform precision is enabled, the bit depth of the transform coefficients is increased to (Log2TransformRange+1). The bit depth of the exact transform coefficients depends on BitDepth. sps_extended_precision_flag equal to 1 specifies that the extended dynamic range is used for the transform coefficients during scaling and transformation, and for the binarization of the abs_remaining[] and dec_abs_level[] syntax elements. sps_extended_precision_flag equal to 0 specifies that the extended dynamic range is not used during scaling and transformation, and that the extended dynamic range is not used for the binarization of the abs_remaining[] and dec_abs_level[] syntax elements. When 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

[0104] If gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that the sps_extended_precision_flag of all images in OlsInScope should be equal to 0. OlsInScope is also referred to as the "in-scope output layer set" herein. 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 the OLS that only includes the lowest layer of the layers referenced to the SPS, and the lowest layer is an independent layer. If gci_no_extended_precision_processing_constraint_flag is equal to 0, such constraints are not 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.

[0105] gci_no_ts_residual_coding_rice_constraint_flag

[0106] 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. In entropy coding, each syntax element value is encoded into a bit sequence inserted into the codestream by an entropy coding process.

[0107] 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 a bit rate very close to the theoretical Shannon limit. However, arithmetic coding is more complex. In order to encode non-binary syntax elements (such as syntax elements with a value range greater than 0 or 1) using CABAC, the syntax elements are first binarized into a set of "bins". The following table gives two examples of binarization. The second example shows that for variable-length binarization, there may be no corresponding bin for some values ​​of the syntax element. Table: Fixed-length binarization example Table: Variable-length binarization example value Binarization 0 0 1 10 2 110 3 1110 4 1111

[0108] Each bin in the binarization can be encoded by the CABAC engine. However, in order to encode a bin using CABAC, the engine must store and update the associated "context". The context models the probability distribution of the bin. In the binarization of syntax elements, each bin requires a separate context.

[0109] It is not ideal to encode syntax elements with a large value range using only CABAC, because such syntax elements will have long binarizations and thus cause excessive overhead in context storage and updating. For example, it is inconvenient to encode residual coefficient values ​​using only CABAC. In contrast to CABAC, Rice coding is able to model the probability distribution of non-binary values ​​using compact parameters.

[0110] Rice coding can also be called Golomb coding, or Rice-Golomb coding. Golomb coding is an entropy encoder controlled by a single parameter M, which is restricted to positive integers. Rice coding is a subset of Golomb coding, in which the entropy encoder is controlled by a single Rice parameter R, so that R is a non-negative integer. Rice coding with Rice parameter R is equivalent to Golomb coding, where M = 2 R .

[0111] The non-negative integer value x is binarized into a Rice code with Rice parameter R as shown below. The quotient q and remainder r are calculated as follows: r = x modulo 2 R

[0112] The Rice code of x is the concatenation of the prefix code and the suffix code. The prefix code is determined by the unary code of q. For example, the prefix code used in VVC is a truncated unary code: q Unary Code 0 0 1 10 2 110 3 1110 4 11110 5 111110 6 111111

[0113] Since the unary code is truncated, the Rice code must also be truncated, which means that the range of values ​​of x that can be encoded is limited. In VVC, the truncated Rice code is applied to the range [0, 6*2 R ] is the value of x in ].

[0114] The suffix code is the binary version of the fixed length code r, which has R bits. For example, if R = 3, the suffix code is: r Fixed length code 0 000 1 001 2 010 3 011 4 100 5 101 6 110 7 111

[0115] In VVC, the residual coefficients are encoded by a combination of CABAC, Rice coding, and Exponential Golomb coding. A small number of syntax element flags are defined, sufficient to signal the value of small-amplitude residuals. For example, sig_coeff_flag indicates whether the residual amplitude is zero or non-zero. If sig_coeff_flag is 1, a further flag can be signaled, which is usually named abs_level_gtx_flag, indicating whether the residual amplitude is greater than 1, 2, 3, etc. These flags are context-encoded by the CABAC engine. Since most residual coefficients have small amplitudes, most residuals can be efficiently encoded using a relatively small number of bins through CABAC.

[0116] Any remaining magnitude of the residual coefficient that cannot be signaled via the residual coefficient flag is signaled in the syntax element abs_remainder. If the value of abs_remainder is less than or equal to 6*2 R , then the syntax element is signaled entirely through the Rice coding of abs_remainder. If the value of abs_remainder is greater than 6*2 R , then through 6*2 R Rice coding and (abs_remainder-6*2 R ) to signal this syntax element. The Exponential Golomb coding process is not described here.

[0117] Although Rice coding is simpler than CABAC, under appropriate conditions, Rice coding can also be effectively compressed to a lower bit rate. For residual coefficients that are all small values, Rice coding with smaller Rice parameters is more efficient. On the contrary, when the values ​​of some residual coefficients are large, larger Rice parameters may be more appropriate. In order to adjust to the statistics of the residual coefficients, the Rice parameters are adaptively determined based on the locSumAbs value, which is calculated based on the amplitude of adjacent residual coefficients. locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

[0118] 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, adaptive Rice parameter determination is also applied to residual coefficients in "transform skip residual coding" (TSRC). In VVCv2, it is recognized that an alternative mechanism for determining Rice parameters may be beneficial for transform skip coefficients.

[0119] An alternative mechanism in VVCv2 allows the Rice parameter to be signaled explicitly through the slice-level syntax element sh_ts_residual_coding_rise_idx_minus1. When this syntax element is signaled, the Rice parameter is set to R=sh_ts_residual_coding_rise_idx_minus1+1. This value of the Rice parameter persists for the duration of the slice. sh_ts_residual_coding_rice_idx_minusl plus 1 specifies the Rice parameter used for the residual_ts_coding() syntax structure in the current slice. When not present, the value of sh_ts_residual_coding_rice_idx_minusl is inferred to be equal to 0.

[0120] Whether the alternative mechanism is enabled is controlled by the SPS level flag sps_ts_residual_coding_rice_present_in_sh_flag. If this flag is set to 0, alternative 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 for explicit Rice parameter signaling are constrained. gci_no_ts_residual_coding_rice_constraint_flag equal to 1 specifies that sps_ts_residual_coding_rice_present_in_sh_flag should be equal to 0 for all pictures in OlsInScope. gci_no_ts_residual_coding_rice_constraint_flag equal to 0 does not impose such constraints. When 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.

[0121] gci_no_rrc_rice_extension_constraint_flag

[0122] gci_no_rrc_rice_extension_constraint_flag specifies the sps_rrc_rice_extension_flag for all pictures in OlsInScope. gci_no_rrc_rice_extension_constraint_flag equal to 1 specifies that the sps_rrc_rice_extension_flag for all pictures in OlsInScope shall be equal to 0. gci_no_rrc_rice_extension_constraint_flag equal to 0 does not impose such a constraint.

[0123] For high bit depth and high bit rate applications, there are many larger quantization levels in many locations in the RRC. For such applications, larger Rice parameters will result in fewer bins required to represent the remaining levels. The way Rice parameters are derived in VVCv1 may not be optimal for VVCv2 applications. Therefore, alternative Rice parameter derivation can be used, which can be signaled via sps_rrc_rice_extension_flag. sps_rrc_rice_extension_flag equals 1 to specify the use of alternative Rice parameter derivation for binarization of abs_remaining[] and dec_abs_level[]. sps_rrc_rice_extension_flag equals 0 to specify that alternative Rice parameter derivation for binarization of abs_remaining[] and dec_abs_level[] is not used. When not present, the value of sps_rrc_rice_extension_flag is inferred to be equal to 0.

[0124] The following shows an example of determining Rice parameters using sps_rrc_rice_extension_flag in VVCv2. Given an array AbsLevel[x][y] of a transform block with component index cIdx and top left luminance position (x0, y0), derive the variable locSumAbs as specified by the following pseudo code process (underlined is what VVCv2 adds to VVCv1): locSumAbs=0 if(xC<(1<< ikB log2TbWidth)-1){ locSumAbs+=AbsLevel[xC+1][yC] if(xC<(1<< ikB log2TbWidth)-2) locSumAbs+=AbsLevel[xC+2][yC] else locSumAbs+=HistValue if(yC<(1<< ikB log2TbHeight)-1) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ] (1517) else locSumAbs+=HistValue } else locSumAbs+=2*HistValue if(yC<(1<< ikB log2TbHeight)-1){ locSumAbs+=AbsLevel[xC][yC+1] if(yC<(1<< ikB log2TbHeight)-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, first Derived Rice parameter cRiceParam, as specified in Table 128, Then update cRiceParam is as follows: cRiceParam=cRiceParam+shiftVal (1526X3) When baseLevel is equal to 0, the variable ZeroPos[n] is derived as follows: ZeroPos[ n ] = ( QState < 2 ? 1 : 2 ) << cRiceParam (1518) Table 128 - Description of cRiceParam based on locSumAbs locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

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

[0126] gci_no_persistent_rice_adaptation_constraint_flag

[0127] gci_no_persistent_rice_adaptation_constraint_flag signals a constraint on the derivation of Rice parameters binarized using the previous TU state. gci_no_persistent_rice_adaptation_constraint_flag equal to 1 specifies that sps_persistent_rice_adaptation_enabled_flag for all pictures in OlsInScope should be equal to 0. gci_no_persistent_rice_adaptation_constraint_flag equal to 0 does not impose such a constraint. When 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.

[0128] sps_persistent_rice_adaptation_enabled_flag equal to 1 specifies that at the beginning of each TU, the statistical data accumulated from the previous TU is used to initialize the Rice parameter derivation for the binarization of abs_remainder[] and dec_abs_level[]. sps_persistent_rice_adaptation_enabled_flag equal to 0 specifies that the previous TU state is not used in the Rice parameter derivation. When not present, the value of sps_persistent_rice_adaptation_enabled_flag is inferred to be equal to 0. The following shows an example of using sps_persistent_rice_adaptation_enabled_flag in VVCv2 to determine Rice parameters (the underline is what VVCv2 adds on VVCv1). If the CTU is the first CTU in a slice or tile, the context variable initialization procedure is called, as specified in subclause 9.3.2.2, 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)

[0129] StatCoeff[i] is used to calculate HisValue, which is used to calculate locSumAbs in (1517) and can be updated once per TU. With the help of HisValue, the derivation of Rice parameters at those locations at the block boundaries can have more accurate values.

[0130] gci_no_reverse_last_sig_coeff_constraint_flag

[0131] gci_no_reverse_last_sig_coeff_constraint_flag equal to 1 specifies that sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope shall be equal to 0. gci_no_reverse_last_sig_coeff_constraint_flag equal to 0 does not impose such a constraint. When 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.

[0132] In conventional residual coding (RRC), the position (x, y) of the last non-zero level in a TU is encoded using up to four syntax elements, last_sig_coeff_x_prefix, last_sig_coeff_y_prefix, last_sig_coeff_x_suffix, and last_sig_coeff_y_suffix. This position is encoded in VVCv1 using the difference between (x, y) and (0, 0) of the current TU. This is reasonable for VVCv1 because there are many zero levels within a TU and most of the non-zero levels are located in the upper left corner of the TU. However, for VVCv2 applications, this may not be the case, and many non-zero levels are scattered throughout the TU. It may be more beneficial to encode the position (x, y) relative to the lower right corner (rather than the upper left corner (0, 0)). sh_reverse_last_sig_coeff_flag provides such a tool to handle such applications.

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

[0134] The sh_reverse_last_sig_coeff_flag is conditionally parsed using the sps_reverse_last_sig_coeff_enabled_flag in the slice header as follows. - 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 exists), 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 When 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 exists), 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 When sh_reverse_last_sig_coeff_flag is equal to 1, the value of LastSignificantCoeffY is modified as follows: LastSignificantCoeffY = ( 1 << Log2ZoTbHeight ) - 1 -LastSignificantCoeffY (198) VVCv2 slice header

[0135] Figure 5 An example of a process 500 for decoding a video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the process 500 by executing appropriate program code. Figure 5 For example, a computing device implementing the video decoder 200 may implement the operations described in Figure 5 The operations depicted in the figure, the computing device includes, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter-frame prediction module 224, and an intra-frame prediction module 226. For the purpose of illustration, the process 500 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0136] At block 502, process 500 involves accessing a bitstream of a video signal (e.g., encoded video 202). At block 504, process 500 involves extracting a general constraint information (GCI) flag from the bitstream of the video. As discussed above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. gci_present_flag equals 1 to specify that the GCI syntax element is present in the general_constraints_info() syntax structure and is used to indicate constraints imposed on additional coding tools. gci_present_flag equals 0 to specify that the GCI syntax element is not present and no general constraints are imposed on the video. Depending on the encoder, the GCI flag may be extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

[0137] At block 506, process 500 involves determining whether one or more general constraints are applied to the video based on the value of the GCI flag. If yes (i.e., the GCI flag is 1), then at block 508, process 500 involves extracting a value M representing the number of additional bits included in the bitstream of the video from the bitstream of the video. The additional bits include a plurality of flag bits indicating corresponding additional coding tools to be constrained for the video.

[0138] At block 510, process 500 involves determining whether M>5. If so, then at block 512, process 500 involves extracting 6 flag bits from the bitstream, the 6 flag bits representing corresponding flags that indicate corresponding constraints on 6 additional coding tools. The 6 flags include: a flag gci_all_rap_pictures_constraint_flag indicating that the picture of the video is restricted to an intra random access point (IRAP) picture or a gradual decoding refresh (GDR) picture; a flag gci_no_extended_precision_processing_constraint_flag indicating whether the extended transform precision is constrained; a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether explicit Rice parameter signaling is constrained; a flag gci_no_rr c_rice_extension_constraint_flag, indicating an alternative Rice parameter derivation for binarizing the quantized residual of the video; the 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 the flag gci_no_reverse_last_sig_coeff_constraint_flag, indicating whether to impose constraints on the image in OlsInScope when decoding the last non-zero level position in the TU.

[0139] If M is greater than 6, process 500 involves extracting the remaining M-6 bits from the code stream and discarding the M-6 bits at block 513. In other words, decoding of the video will be performed independently of the M-6 bits.

[0140] At block 514, process 500 involves decoding the remainder of the codestream of the video into pictures according to the constraints on the six additional coding 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 the sps_extended_precision_flag for the pictures in OlsInScope to 0 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 explicit Rice parameter signaling is constrained and decode the remaining portion of the video bitstream by disabling alternative Rice parameter signaling for images in OlsInScope. If the flag gci_no_rrc_rice_extension_constraint_flag is 1, the decoder may determine that alternative Rice parameter derivation for binarizing the quantized residual of the video is constrained and decode the remaining portion of the video bitstream by disabling alternative Rice parameter signaling for images in OlsInScope. If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder may determine that initialization of Rice parameter derivation for binarization based on the previous transform unit state is constrained and decode the remaining portion of the video bitstream without initializing Rice parameters based on the previous transform unit state for images in OlsInScope. If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder can determine that the sps_reverse_last_sig_coeff_enabled_flag for all images in OlsInScope is equal to 0, and determine that 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 decode the remaining part of the video code stream by interpreting the coordinates of the decoded last significant coefficient as being relative to the upper left corner (0, 0) of each transform block of the current slice.

[0141] If it is determined at block 510 that M is not greater than 5, process 500 involves, at block 518, extracting M bits from the bitstream and discarding the M bits. In other words, decoding of the video is performed independently of the M bits. At block 520, the decoder decodes the video without applying constraints to the 6 additional coding tools. If it is determined at block 506 that the GCI flag indicates that no general constraints are applied to the video (i.e., the GCI flag is 0), process 500 involves decoding the video into an image without general constraints. In some examples, according to the above description of Figure 2 The described process performs decoding. The decoded video can be output for display.

[0142] Figure 6 Another example of a process 600 for decoding a video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the process 600 by executing appropriate program code. Figure 6 For example, a computing device implementing the video decoder 200 may implement the operations described in Figure 6 The operations depicted in the figure, the computing device includes, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter-frame prediction module 224, and an intra-frame prediction module 226. For the purpose of illustration, the process 600 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0143] At block 602, process 600 involves accessing a bitstream of a video signal (e.g., encoded video 202). At block 604, process 600 involves extracting a general constraint information (GCI) flag from the bitstream of the video. As discussed above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. gci_present_flag equals 1 to specify that the GCI syntax element is present in the general_constraints_info() syntax structure and is used to indicate constraints imposed on additional coding tools. gci_present_flag equals 0 to specify that the GCI syntax element is not present and no general constraints are imposed on the video. Depending on the encoder, the GCI flag may be extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

[0144] At block 606, process 600 involves determining whether one or more general constraints are applied to the video based on the value of the GCI flag. If yes (i.e., the GCI flag is 1), then at block 608, process 600 involves extracting a value M representing the number of additional bits included in the bitstream of the video from the bitstream of the video. The additional bits include a flag bit that indicates the corresponding additional coding tools to be constrained for the video.

[0145] At block 610, process 600 involves determining whether M is greater than 6. If so, then at block 612, process 600 involves extracting 6 flag bits from the codestream, the 6 flag bits representing corresponding flags indicating corresponding constraints on 6 additional coding tools. The 6 flags include: a flag gci_all_rap_pictures_constraint_flag indicating that the picture of the video is restricted to an intra random access point (IRAP) picture or a gradual decoding refresh (GDR) picture; a flag gci_no_extended_precision_processing_constraint_flag indicating whether the extended transform precision is constrained; a flag gci_no_ts_residual_coding_rice_constraint_flag indicating whether explicit Rice parameter signaling is constrained; a flag gci_no_rr c_rice_extension_constraint_flag, indicating an alternative Rice parameter derivation for binarizing the quantized residual of the video; the 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 the flag gci_no_reverse_last_sig_coeff_constraint_flag, indicating whether to impose constraints on the image in OlsInScope when decoding the last non-zero level position in the TU.

[0146] At block 614, process 600 involves extracting M-6 bits following the 6 flag bits from the bitstream and discarding the extracted M-6 bits. In other words, decoding of the video is performed independently of the M-6 bits. At block 616, process 600 involves decoding the remainder of the bitstream of the video into images according to the constraints on the 6 additional coding tools indicated by the 6 flags. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder may determine 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 decode the GDR images or IRAP images 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 the sps_extended_precision_flag for the images in OlsInScope to equal 0 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 explicit Rice parameter signaling is constrained and decode the remaining portion of the video bitstream by disabling alternative Rice parameter signaling for images in OlsInScope. If the flag gci_no_rrc_rice_extension_constraint_flag is 1, the decoder may determine that alternative Rice parameter derivation for binarizing the quantized residual of the video is constrained and decode the remaining portion of the video bitstream by disabling alternative Rice parameter signaling for images in OlsInScope. If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder may determine that initialization of Rice parameter derivation for binarization based on the previous transform unit state is constrained and decode the remaining portion of the video bitstream without initializing Rice parameters based on the previous transform unit state for images in OlsInScope.If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder can determine that the sps_reverse_last_sig_coeff_enabled_flag for all images in OlsInScope is equal to 0, and determine that 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 decode the remaining part of the video code stream by interpreting the coordinates of the decoded last significant coefficient as being relative to the upper left corner (0, 0) of each transform block of the current slice.

[0147] If it is determined at box 610 that M is not greater than 6, then M is 0 or 6. If M is 6, process 600 involves, at box 620, extracting 6 flag bits, as discussed above. At box 622, the decoder decodes the video by imposing constraints on 6 additional coding tools based on the extracted flag bits. If M is 0, no flag bits are extracted. At box 624, the decoder decodes the video by not imposing constraints on the 6 additional coding tools (because no flag bits are extracted). If it is determined at box 606 that the GCI flag indicates that no general constraints are imposed on the video (i.e., the GCI flag is 0), process 600 involves, at box 618, decoding the video into an image without general constraints. In some examples, according to the above for Figure 2 The described process performs decoding. The decoded video can be output for display.

[0148] Figure 7 Another example of a process 700 for decoding a video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the process 700 by executing appropriate program code. Figure 7 For example, a computing device implementing the video decoder 200 may implement the operations described in Figure 7 The operations depicted in the figure, the computing device includes, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter-frame prediction module 224, and an intra-frame prediction module 226. For the purpose of illustration, the process 700 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0149] At block 702, process 700 involves accessing a bitstream of a video signal (e.g., encoded video 202). At block 704, process 700 involves extracting a general constraint information (GCI) flag from the bitstream of the video. As discussed above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. gci_present_flag equals 1 to specify that the GCI syntax element is present in the general_constraints_info() syntax structure and is used to indicate constraints imposed on additional coding tools. gci_present_flag equals 0 to specify that the GCI syntax element is not present and no general constraints are imposed on the video. Depending on the encoder, the GCI flag may be extracted from a network packet of the video, a video parameter set of the video, or a sequence parameter set of the video.

[0150] At block 706, process 700 involves determining whether one or more general constraints are applied to the video based on the value of the GCI flag. If yes (i.e., the GCI flag is 1), then at block 708, process 700 involves extracting a value M representing the number of additional bits included in the bitstream of the video from the bitstream of the video. The additional bits include a plurality of flag bits indicating corresponding additional coding tools to be constrained for the video.

[0151] At box 710, process 700 involves determining whether M is greater than 5. If not, at box 712, process 700 involves extracting M bits from the code stream and discarding the M bits. At box 714, process 700 involves decoding the remaining portion of the code stream of the video into an image independently of the M bits. If it is determined at box 710 that M is not greater than 5, process 700 involves extracting 6 flag bits at box 718, as discussed above. If M is greater than 6, process 700 involves extracting the remaining M-6 bits from the code stream and discarding the M-6 bits at box 719. In other words, decoding of the video will be performed independently of the M-6 bits. At box 720, the decoder decodes the video by imposing constraints on 6 additional coding tools based on the extracted 6 flag bits, as discussed above.

[0152] If it is determined at block 706 that the GCI flag indicates that no general constraints are imposed on the video (i.e., the GCI flag is 0), process 700 involves decoding the video into an image without general constraints. Figure 2 The described process performs decoding. The decoded video can be output for display.

[0153] Example of a computing system for implementing signaling of general constraint information

[0154] Any suitable computing system may be used to perform the operations described herein. For example, Figure 8 Describes the achievable Figure 1 The video encoder 100 or Figure 2 An example of a computing device 800 for a video decoder 200 of the present invention is provided. 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 of a plurality of processing devices (including one processing device). Such a processor may include a computer readable medium storing instructions, or may communicate with a computer readable medium storing instructions that, when executed by the processor 812, cause the processor to perform the operations described herein.

[0155] 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 codes to the processor. Non-limiting examples of computer-readable media include disks, memory chips, ROM, RAM, ASICs, configured processors, optical storage, tapes or other magnetic storage, or any other medium from which a computer processor can read instructions. The instructions may include processor-specific instructions generated by a compiler and / or interpreter from code written in any suitable computer programming language, including, for example, C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, and ActionScript.

[0156] The computing device 800 may also include a bus 816. The bus 816 may communicatively couple one or more components of the computing device 800. The computing device 800 may also include multiple external or internal devices, such as input or output devices. For example, the computing device 800 is shown as having 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. One or more input devices 820 and one or more output devices 822 may be communicatively coupled to the I / O interface 818. The communication coupling may be implemented in any suitable manner (e.g., via a printed circuit board connection, via a cable connection, via wireless transmission communication, etc.). Non-limiting examples of the input device 820 include a touch screen (e.g., one or more cameras for imaging a touch area, or a pressure sensor for detecting pressure changes caused by a touch), a mouse, a keyboard, or any other device that can be used to generate input events in response to physical actions of a user of the computing device. Non-limiting examples of output device 822 include an LCD screen, an external monitor, speakers, or any other device that can be used to display or otherwise present output generated by the computing device.

[0157] The computing device 800 can execute program code, which configures the processor 812 to perform the above Figures 1 to 7 The program code may include one or more of the operations described. 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.

[0158] The computing device 800 may also include at least one network interface device 824. The network interface device 824 may include any device or group of devices suitable for establishing a wired or wireless data connection with one or more data networks 828. Non-limiting examples of the network interface device 824 include an Ethernet network adapter, a modem, etc. The computing device 800 may transmit messages as electronic or optical signals via the network interface device 824.

[0159] General considerations

[0160] Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, it will be understood by those skilled in the art that the claimed subject matter may be practiced without these specific details. In other cases, methods, devices, or systems known to those of ordinary skill in the art are not described in detail in order to avoid obscuring the claimed subject matter.

[0161] Unless otherwise specifically noted, it should be appreciated that terms such as "processing," "computing," "calculating," "determining," "identifying," and the like are used throughout the discussion of this specification to refer to actions or processes of a computing device (e.g., one or more computers or similar electronic computing devices) that manipulate or transform data represented as physical electronic or magnetic quantities within a memory, register, or other information storage device, transmission device, or display device of a computing platform.

[0162] The one or more systems discussed herein are not limited to any particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide a result conditioned on one or more inputs. Suitable computing devices include a multi-purpose microprocessor-based computer system that accesses stored software, and the stored software programs or configures the computing system to change it from a general-purpose computing device to a special-purpose computing device, thereby implementing one or more embodiments of the subject matter of this article. Any suitable programming, scripting, or other type of language or combination of languages ​​can be used to implement the teachings contained herein in software for programming or configuring a computing device.

[0163] Embodiments of the methods disclosed herein may be performed in the operation of such a computing device. The order of the blocks presented in the above examples may be changed—for example, the blocks may be reordered, combined, and / or decomposed into sub-blocks. Some blocks or processes may be performed in parallel.

[0164] As used herein, "suitable for" or "configured to" is meant to be open and inclusive language that does not exclude devices that are suitable or configured to perform additional tasks or steps. In addition, the use of "based on" is meant to be open and inclusive, as a process, step, calculation, or other action "based on" one or more listed conditions or values ​​may actually be based on additional conditions or values ​​beyond those listed. The headings, lists, and numbers included herein are for ease of explanation only and are not meant to be limiting.

[0165] Although the subject matter of this article has been described in detail with respect to the specific embodiments of the subject matter of this article, it should be appreciated that those skilled in the art, after understanding the foregoing, can easily make changes, variations and equivalents to such embodiments. Therefore, it should be understood that the present disclosure is provided for the purpose of illustration rather than limitation, and does not exclude such modifications, variations and / or additions to the subject matter of this article that are obvious to those of ordinary skill in the art.

Claims

1. A method for decoding a video, the method include: Extracting a general constraint information GCI flag from the bit stream of the video; Determining, based on the value of the GCI flag, to apply one or more general constraints to the video; In response to determining that the one or more general constraints are applied to the video, extracting from a bitstream of the video a value indicating a number of additional bits included in the bitstream of the video, the additional bits comprising a flag bit indicating corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; as well as In response to determining that the value is greater than 5, extracting from the codestream 6 flag bits representing 6 corresponding flags indicating corresponding constraints on 6 additional coding tools, and Based at least in part on the constraints on the six additional coding tools indicated by the six flags, a remaining portion of the codestream of the video is decoded into images.

2. The method according to claim 1, in, The six signs include: A first flag indicating that the image of the video is limited to an intra-frame random access point IRAP image or a gradual decoding refresh GDR image; A second flag indicating whether the extended transform precision is constrained; A third flag indicating whether explicit Rice parameter signaling is constrained; a fourth flag indicating an alternative Rice parameter derivation for binarization of a quantized residual of the video; A fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit; and The sixth flag indicates whether to impose constraints on images in the range output layer set OlsInScope when decoding the position of the last non-zero level in the transform unit.

3. The method according to claim 2, further comprising one or more of the following: Determining that the first flag does not exist in the code stream, and inferring that the value of the first flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the second flag does not exist in the code stream, and inferring that the value of the second flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the third flag does not exist in the code stream, and inferring that the value of the third flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the fourth flag does not exist in the code stream, and inferring that the value of the fourth flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the fifth flag does not exist in the code stream, and inferring that the value of the fifth flag is 0, which indicates that no constraint is imposed on the corresponding coding tool; or It is determined that the sixth flag does not exist in the code stream, and it is inferred that the value of the sixth flag is 0, which is used to indicate that no constraint is imposed on the corresponding encoding tool.

4. The method according to claim 2, in, Based at least in part on the constraints on the six additional coding tools indicated by the six flags, decoding a remaining portion of the codestream of the video into images comprises one or more of: Based on the first flag being 1, determining that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt being equal to 0, and decoding the GDR images or IRAP images in the one or more output layer sets; Based on the second flag being 1, determining that the extended transform precision is constrained, and decoding the remaining portion of the bitstream of the video by setting the sps_extended_precision_flag for the images in the in-scope output layer set OlsInScope to 0 so that the extended dynamic range is not used; Based on the third flag being 1, determining that explicit Rice parameter signaling is constrained, and decoding the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for images in the output layer set OlsInScope within the range; Based on the fourth flag being 1, determining that the derivation of alternative Rice parameters for binarizing the quantized residual of the video is constrained, and decoding the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for images in the output layer set OlsInScope within the range; Based on determining that the fifth flag is 1, it is determined that the initialization of the derivation of the Rice parameters for binarization based on the previous transform unit state is constrained, and the remaining part of the bitstream of the video is decoded without initializing the Rice parameters based on the previous transform unit state for the images in the output layer set OlsInScope within the range; or Based on the sixth flag being 1, determine that the coordinates of the last significant coefficient are encoded relative to the upper left corner of each transform block of the slice, and decode the remaining part of the code stream of the video by interpreting the decoded coordinates of the last significant coefficient as being relative to the upper left corner of each transform block of the slice.

5. The method according to claim 1, in, 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.

6. The method according to claim 1, further comprising: include: In response to determining that the value is greater than 5, setting the value numAdditionalBitsUsed indicating the extracted additional bits to 6; Extracting a bit set from the code stream, wherein the number of bits in the bit set is equal to gci_num_additional_bits-numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Independent of the bit set, a remainder of the code stream of the video is decoded into pictures.

7. The method according to claim 1, further comprising: include: In response to determining that the value is not greater than 5, setting the value numAdditionalBitsUsed indicating the extracted additional bits to 0; Extracting a bit set from the code stream, wherein the number of bits in the bit set is equal to gci_num_additional_bits-numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Independent of the extracted set of bits, the remainder of the codestream of the video is decoded into pictures.

8. A non-transitory computer readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform operations, the operations include: Extract the general constraint information GCI flag from the video bitstream; Determining, based on the value of the GCI flag, to apply one or more general constraints to the video; In response to determining that the one or more general constraints are applied to the video, extracting from a bitstream of the video a value indicating a number of additional bits included in the bitstream of the video, the additional bits comprising a flag bit indicating corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; as well as In response to determining that the value is greater than 5, extracting from the codestream 6 flag bits representing 6 corresponding flags indicating corresponding constraints on 6 additional coding tools, and Based at least in part on the constraints on the six additional coding tools indicated by the six flags, a remaining portion of the codestream of the video is decoded into images.

9. The non-transitory computer readable medium of claim 8, in, The six signs include: A first flag indicating that the image of the video is limited to an intra random access point (IRAP) image or a gradual decoding refresh (GDR) image; A second flag indicating whether the extended transform precision is constrained; A third flag indicating whether explicit Rice parameter signaling is constrained; a fourth flag indicating an alternative Rice parameter derivation for binarization of a quantized residual of the video; A fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit; and The sixth flag indicates whether to impose constraints on images in the range output layer set OlsInScope when decoding the position of the last non-zero level in the transform unit.

10. The non-transitory computer readable medium of claim 9, in, The operations may also include one or more of the following: Determining that the first flag does not exist in the code stream, and inferring that the value of the first flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the second flag does not exist in the code stream, and inferring that the value of the second flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the third flag does not exist in the code stream, and inferring that the value of the third flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the fourth flag does not exist in the code stream, and inferring that the value of the fourth flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the fifth flag does not exist in the code stream, and inferring that the value of the fifth flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; or It is determined that the sixth flag does not exist in the code stream, and it is inferred that the value of the sixth flag is 0, which is used to indicate that no constraint is imposed on the corresponding encoding tool.

11. The non-transitory computer readable medium of claim 9, in, Based at least in part on the constraints on the six additional coding tools indicated by the six flags, decoding a remaining portion of the codestream of the video into images comprises one or more of: Based on the first flag being 1, determining that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt being equal to 0, and decoding the GDR images or IRAP images in the one or more output layer sets; Based on the second flag being 1, determining that the extended transform precision is constrained, and decoding the remaining portion of the bitstream of the video by setting the sps_extended_precision_flag for the images in the in-scope output layer set OlsInScope to 0 so that the extended dynamic range is not used; Based on the third flag being 1, determining that explicit Rice parameter signaling is constrained, and decoding the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for images in the output layer set OlsInScope within the range; Based on the fourth flag being 1, determining that the derivation of alternative Rice parameters for binarizing the quantized residual of the video is constrained, and decoding the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for images in the output layer set OlsInScope within the range; Based on determining that the fifth flag is 1, it is determined that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained, and the remaining part of the bitstream of the video is decoded without initializing the Rice parameters based on the previous transform unit state for the images in the output layer set OlsInScope within the range; or Based on the sixth flag being 1, determine that the coordinates of the last significant coefficient are encoded relative to the upper left corner of each transform block of the slice, and decode the remaining part of the code stream of the video by interpreting the decoded coordinates of the last significant coefficient as being relative to the upper left corner of each transform block of the slice.

12. The non-transitory computer readable medium of claim 8, in, 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.

13. The non-transitory computer readable medium of claim 8, in, The operations also include: In response to determining that the value is greater than 5, setting the value numAdditionalBitsUsed indicating the extracted additional bits to 6; Extracting a bit set from the code stream, wherein the number of bits in the bit set is equal to gci_num_additional_bits-numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Independent of the bit set, a remainder of the code stream of the video is decoded into pictures.

14. The non-transitory computer readable medium of claim 8, in, The operations also include: In response to determining that the value is not greater than 5, setting the value numAdditionalBitsUsed indicating the extracted additional bits to 0; Extracting a bit set from the code stream, wherein the number of bits in the bit set is equal to gci_num_additional_bits-numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Independent of the extracted set of bits, the remainder of the codestream of the video is decoded into pictures.

15. A system, include: Processing equipment; as well as a non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform operations comprising: Extract the general constraint information GCI flag from the video bitstream; Determining, based on the value of the GCI flag, to apply one or more general constraints to the video; In response to determining that the one or more general constraints are applied to the video, extracting from a bitstream of the video a value indicating a number of additional bits included in the bitstream of the video, the additional bits comprising a flag bit indicating corresponding additional coding tools to be 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 from the codestream 6 flag bits representing 6 corresponding flags indicating corresponding constraints on 6 additional coding tools, and Based at least in part on the constraints on the six additional coding tools indicated by the six flags, a remaining portion of the codestream of the video is decoded into images.

16. The system according to claim 15, in, The six signs include: A first flag indicating that the image of the video is limited to an intra-frame random access point IRAP image or a gradual decoding refresh GDR image; A second flag indicating whether the extended transform precision is constrained; A third flag indicating whether explicit Rice parameter signaling is constrained; a fourth flag indicating an alternative Rice parameter derivation for binarization of a quantized residual of the video; A fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on the previous transform unit; and The sixth flag indicates whether to impose constraints on images in the range output layer set OlsInScope when decoding the position of the last non-zero level in the transform unit.

17. The system according to claim 16, in, The operations may also include one or more of the following: Determining that the first flag does not exist in the code stream, and inferring that the value of the first flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the second flag does not exist in the code stream, and inferring that the value of the second flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the third flag does not exist in the code stream, and inferring that the value of the third flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the fourth flag does not exist in the code stream, and inferring that the value of the fourth flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; Determining that the fifth flag does not exist in the code stream, and inferring that the value of the fifth flag is 0, which is used to indicate that no constraint is imposed on the corresponding coding tool; or It is determined that the sixth flag does not exist in the code stream, and it is inferred that the value of the sixth flag is 0, which is used to indicate that no constraint is imposed on the corresponding encoding tool.

18. The system according to claim 16, in, Based at least in part on the constraints on the six additional coding tools indicated by the six flags, decoding a remaining portion of the codestream of the video into images comprises one or more of: Based on the first flag being 1, determining that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt being equal to 0, and decoding the GDR images or IRAP images in the one or more output layer sets; Based on the second flag being 1, determining that the extended transform precision is constrained, and decoding the remaining portion of the bitstream of the video by setting sps_extended_precision_flag for the images in the in-scope output layer set OlsInScope to be equal to 0 so that the extended dynamic range is not used; Based on the third flag being 1, determining that explicit Rice parameter signaling is constrained, and decoding the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for images in the output layer set OlsInScope within the range; Based on the fourth flag being 1, determining that the derivation of alternative Rice parameters for binarizing the quantized residual of the video is constrained, and decoding the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for images in the output layer set OlsInScope within the range; Based on determining that the fifth flag is 1, it is determined that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained, and the remaining part of the bitstream of the video is decoded without initializing the Rice parameters based on the previous transform unit state for the images in the output layer set OlsInScope within the range; or Based on the sixth flag being 1, determine that the coordinates of the last significant coefficient are encoded relative to the upper left corner of each transform block of the slice, and decode the remaining part of the code stream of the video by interpreting the decoded coordinates of the last significant coefficient as being relative to the upper left corner of each transform block of the slice.

19. The system according to claim 15, in, 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.

20. The system according to claim 15, in, The operations also include: In response to determining that the value is greater than 5, setting the value numAdditionalBitsUsed indicating the extracted additional bits to 6; Extracting a bit set from the code stream, wherein the number of bits in the bit set is equal to gci_num_additional_bits-numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Independent of the bit set, a remainder of the code stream of the video is decoded into pictures.

Images