Signaling general constraint information for video encoding

Abstract

In some embodiments, a video decoder decodes a video according to a bitstream of the video. The video decoder accesses the bitstream of the video, and extracts a general constraint information (GCI) flag from the bitstream of the video. The decoder determines, based on a value of the GCI flag, that one or more general constraints are imposed on the video, and extracts, from the bitstream of the video, a value indicating a 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, from the bitstream of the video, 6 flags indicating respective constraints on 6 additional coding tools. The decoder decodes the bitstream of the video into pictures based on the constraints on the 6 additional coding tools indicated by the 6 flags.

Description

[0001] This application is a divisional application of Chinese patent application No. 202280081236.5, entitled "Transmitting General Constraint Information for Video Coding by Signal", which entered the Chinese national phase of PCT international patent application PCT / US2022 / 079494, filed on November 8, 2022.

[0002] Cross-references to related applications

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

[0004] This disclosure generally relates to video processing. Specifically, this disclosure relates to signaling and initializing general constraint information for video coding. Background Technology

[0005] The ubiquitous availability of camera-enabled devices, such as smartphones, tablets, and computers, has made capturing video or images easier than ever before. However, even short videos can have a very large data volume. Video encoding technologies (including video encoding and decoding) enable video data to be compressed into smaller sizes, allowing various types of video to be stored and transmitted. Video encoding has been widely used in various applications, such as digital television broadcasting, video transmission over the Internet and mobile networks, real-time applications (e.g., video chat, video conferencing), DVDs, Blu-ray discs, etc. To reduce the storage space used to store video and / or the network bandwidth consumption used to transmit video, it is desirable to improve the efficiency of video encoding schemes. Summary of the Invention

[0006] Some embodiments involve signaling and initializing general constraint information for video coding. In one example, a method for decoding video includes: extracting a general constraint information (GCI) flag from the video bitstream; determining, based on the value of the GCI flag, to impose one or more general constraints on the video; in response to determining that one or more general constraints are imposed on the video, extracting from the video bitstream a value indicating the number of additional bits included in the video bitstream, the additional bits including flag bits 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 six flag bits representing six corresponding flags indicating corresponding constraints on six additional coding tools from the bitstream, and decoding the remainder of the video bitstream into an image based at least in part on the constraints on the six additional coding tools indicated by the six flags.

[0007] In another example, a non-transitory computer-readable medium stores program code executable by one or more processing devices to perform operations. The operations include: extracting a General Constraint Information (GCI) flag from a video bitstream; determining, based on the value of the GCI flag, to impose one or more general constraints on the video; in response to determining that one or more general constraints are imposed on the video, extracting from the video bitstream a value indicating the number of additional bits included in the video bitstream, the additional bits including flag bits 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 six flag bits representing six corresponding flags indicating corresponding constraints on the six additional coding tools from the bitstream, and decoding the remainder of the video bitstream into an image based at least in part on the constraints on the six additional coding tools indicated by these six flags.

[0008] In yet another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device. The processing device 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 video bitstream; determining, based on the value of the GCI flag, to impose one or more general constraints on the video; in response to determining that one or more general constraints are imposed on the video, extracting from the video bitstream a value indicating the number of additional bits included in the video bitstream, the additional bits including flag bits 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 six flag bits representing six corresponding flags indicating corresponding constraints on six additional coding tools from the bitstream; and decoding the remainder of the video bitstream into an image, at least in part based on the constraints on the six additional coding tools indicated by the six flags.

[0009] These illustrative embodiments are mentioned not to limit or restrict this disclosure, but to provide examples to aid in understanding it. Additional embodiments are discussed in the detailed description, and further description is provided therein. Attached Figure Description

[0010] The features, embodiments, and advantages of this disclosure will be better understood when the following detailed description is read in conjunction with the accompanying drawings.

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

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

[0013] Figure 3 Examples of coded tree unit partitioning of images in a video according to some embodiments of the present disclosure are depicted.

[0014] Figure 4 Examples of coding unit partitioning of coding tree units according to some embodiments of the present disclosure are described.

[0015] Figure 5 Examples of processes for decoding video according to some embodiments of the present disclosure are described.

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

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

[0018] Figure 8 Examples of computing systems that can be used to implement some embodiments of this disclosure are described. Detailed Implementation

[0019] Various embodiments are provided for signaling and initializing general constraint information for video coding. As discussed above, an increasing amount of video data is being generated, stored, and transmitted. It is advantageous not only to improve the efficiency of video coding technology but also to enhance the stability of video coding, enabling successful decoding of video signals at the decoder side. Issues related to the stability of video decoding include incompatibility and inconsistency problems. With the development of video coding technology, newer video coding standards have been developed. One such video coding standard is Versatile Video Coding (VVC) version 1, jointly published by the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU), with ISO referring to "ISO / IEC 23090-3:2021 Information technology—Encoding representation of immersive media—Part 3: Versatile Video Coding," and ITU referring to "ITU-T Recommendation H.266 (August 2020): Versatile Video Coding." In this disclosure, Versatile Video Coding version 1 may be referred to as "VVC version 1" or "VVCv1." VVC version 1 has been superseded by version 2 of the Multifunctional Video Coding Standard, which will be jointly published by ISO and ITU. ISO's version is "ISO / IEC 23090-3:2022 Information Technology—Coding Representation of Immersive Media—Part 3: Multifunctional Video Coding," and ITU's version is "ITU-T Recommendation H.266 (April 2022): Multifunctional Video Coding." In this disclosure, version 2 of the Multifunctional Video Coding Standard may be referred to as "VVC version 2" or "VVCv2." For video decoders conforming to the new version of the video coding standard to successfully decode video signals encoded using previous versions, the video coding scheme should be designed to be backward compatible with previous versions. However, the general constraint information used in the current draft of VVC version 2 has led to a loss of synchronization in video decoding, a serious incompatibility issue between different versions of the video coding standard. Furthermore, the current draft of VVC version 2 may not define general constraint flags related to the general constraint information, leading to ambiguity and inconsistencies in decoder implementations in some cases. The various embodiments described herein address these issues by introducing signal transmission and initialization methods for general constraint information used in video coding, thereby improving the stability of video coding.

[0020] In the VVC standard, the General Constraints Information (GCI) syntax structure `general_constraints_info()` is used to indicate specific constraint attributes of the bitstream. The GCI contains a list of constraint flags and non-flag syntax elements. The binary flag `gci_present_flag` is used to specify the presence of a GCI syntax element. In some embodiments, if the VVC version 2 bitstream signals the GCI (i.e., `gci_present_flag` is 1), and the VVC version 2 GCI consists of N additional coding tools that can be constrained, then the syntax element `gci_num_additional_bits` corresponding to the N additional coding tools can be set to either 0 or N. If `gci_num_additional_bits` is set to 0, the GCI 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 GCI flags for the N additional coding tools. In one example, N is set to 6.

[0021] In some examples, for VVC version 2 bitstreams, setting `gci_num_additional_bits` to a value other than 0 or N is not allowed. However, the VVC version 2 decoder can still handle general constraint information where `gci_num_additional_bits` is set 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 a value greater than N. If M is greater than 0 and less than N, after decoding the `gci_num_additional_bits` syntax element, the decoder extracts M bits from the bitstream and discards these M bits. If M is greater than N, after decoding the `gci_num_additional_bits` syntax element, the decoder extracts N bits from the bitstream and interprets these N bits as general constraint flags for N additional coding tools. The decoder then also extracts (MN) bits from the bitstream and discards these (MN) bits. In other examples, the VVC version 2 decoder does not need to handle the general constraint information of setting gci_num_additional_bits to a value greater than 0 but less than N. A valid VVC version 2 bitstream can only have gci_num_reserved_bits set to either 0 or N. Future versions of VVC will not be allowed to set gci_num_additional_bits to a value between 0 and N.

[0022] In some embodiments, a general constraint information flag is initialized to address the ambiguity and inconsistency issues in the decoder implementation discussed above. In these embodiments, `general_constraints_info()` does not impose constraints on the encoding tools associated with the general constraint information flag when `gci_present_flag` equals 1 and `gci_num_additional_bits` equals 0. In the example where a flag value of 0 indicates no constraints, the value of the flag is inferred to be 0 when the general constraint information flag is absent.

[0023] The embodiments described in this disclosure provide a method for inferring general constraint flags for additional coding tools in VVC Version 2 using signal transmission. Unlike prior art, the high-level syntax bitstream generated by the method described in this disclosure is compatible with VVC Version 1 decoders and can be decoded even when there is a loss of synchronization between the behavior of VVC Version 1 and VVC Version 2 decoders. The inference rules described in this disclosure eliminate ambiguity regarding the VVC Version 2 decoding behavior of VVC Version 2 GCI syntax elements. These techniques can serve as effective coding tools in various video coding standards.

[0024] Now refer to the attached diagram, Figure 1 This 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 partitioning 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 buffer 130, and an entropy coding module 116.

[0025] The input to the video encoder 100 is an input video 102 containing a sequence of images (also referred to as frames or pictures). In a block-based video encoder, for each picture, the video encoder 100 uses a partitioning module 112 to divide the image into blocks 104, each block containing multiple pixels. A block can be a macroblock, a coding tree unit, a coding unit, a prediction unit, and / or a prediction block. A single picture can include blocks of different sizes, and the block partitions for different pictures in the video can also be different. Each block can be encoded using different prediction methods (e.g., intra-frame prediction, inter-frame prediction, or a mixture of intra-frame and inter-frame prediction).

[0026] Typically, the first frame of a video signal is an intra-coded frame, which is encoded using only intra-frame prediction. In intra-frame prediction mode, blocks of the frame are predicted using only the encoded data from the same frame. Intra-coded frames can be decoded without information from other frames. To perform intra-frame prediction, Figure 1The video encoder 100 shown 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 from reconstructed blocks 136 of adjacent blocks 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 block 104 and intra-prediction block 134. This difference is referred to as residual block 106.

[0027] To further remove redundancy from the block, transform module 114 transforms the residual block 106 into the transform domain by applying a transform to the samples in the block. Examples of transforms may include, but are not limited to, the Discrete Cosine Transform (DCT) or the Discrete Sine Transform (DST). The transformed values ​​are called transform coefficients, which represent the residual block in the transform domain. In some examples, the residual block can be directly quantized without transformation by transform module 114. This is called transform skip mode.

[0028] The video encoder 100 can further quantize the transform coefficients using the quantization module 115 to obtain quantized coefficients. Quantization involves dividing the sample by the quantization step size and then rounding it, while inverse quantization involves multiplying the quantized value 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, allowing fewer bits to be used to represent the video samples.

[0029] Quantization of coefficients / samples within a block can be performed independently; this quantization method is used in some existing video compression standards (such as H.264 and HEVC). For an N x M block, the 2D coefficients of the block can be converted into a 1-D array using a certain scan order for coefficient quantization and encoding. Quantization of coefficients within a block can utilize scan order information. For example, the quantization of a given coefficient in a block can depend on the state of previous quantized values ​​in the scan order. To further improve coding efficiency, multiple quantizers can be used. Which quantizer is used to quantize the current coefficient depends on information preceding the current coefficient in the encoding / decoding scan order. This quantization method is called dependent quantization.

[0030] The degree of quantization can be adjusted using the quantization step size. For example, for scalar quantization, different quantization step sizes can be applied to achieve finer or coarser quantization. Smaller quantization step sizes correspond to finer quantization, while larger quantization step sizes correspond to coarser quantization. The quantization step size can be indicated by the quantization parameter (QP). Providing the quantization parameter in the encoded bitstream of the video allows the video decoder to acquire and apply the quantization parameter for decoding.

[0031] The quantized samples are then 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 binaries, and the coding algorithm further compresses these binary binaries into bits. Examples of binarization methods include, but are not limited to, combinations of truncated Rice (TR) and finite k-order exponential Golomb (EGk) binarization, and k-order exponential Golomb 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), syntax-based context-adaptive binary arithmetic coding (SBAC), probabilistic interval segmented entropy (PIPE) coding, or other entropy coding techniques. The entropy-coded data is added to the bitstream of the output encoded video 132.

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

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

[0034] The motion estimation module 122 compares the current block 104 of the current image with the decoded reference image 108 for motion estimation. The decoded reference image 108 is stored in the decoded image buffer 130. The motion estimation module 122 selects the reference block from the decoded reference image 108 that best matches the current block. The motion estimation module 122 further identifies the offset between the position of the reference block (e.g., x, y coordinates) and the position of the current block. This 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.

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

[0036] For an inter-frame prediction block, the video encoder 100 can subtract the inter-frame prediction block 134 from block 104 to generate a residual block 106. The residual block 106 can be transformed, quantized, and entropy-coded 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 and inverse transforming the residual, and then combining it with the corresponding prediction block 134.

[0037] To obtain the 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 can 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.

[0038] Figure 2 An example of a video decoder 200 configured to implement the embodiments presented herein is depicted. The video decoder 200 processes encoded video 202 in a 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-frame prediction module 226, an inter-frame prediction module 224, and a decoded image buffer 230.

[0039] Entropy decoding module 216 is configured to perform entropy decoding of the encoded video 202. Entropy decoding module 216 decodes quantization coefficients, encoding parameters including intra-frame prediction parameters and inter-frame prediction parameters, and other information. In some examples, entropy decoding module 216 decodes the bitstream of the encoded video 202 into a binary representation, and then converts the binary representation into quantization levels of coefficients. Then, the entropy-decoded coefficient levels are inversely quantized by inverse quantization module 218, and subsequently inversely transformed to the pixel domain by inverse transform module 219. The functions of inverse quantization module 218 and inverse transform module 219 are similar to those described above for... Figure 1 The inverse quantization module 118 and inverse transform module 119 are described. The residual block of the inverse transform can be added to the corresponding prediction block 234 to generate the reconstruction block 236. For blocks that skip the transform, the inverse transform module 219 will not be applied to these blocks. The dequantized samples generated by the inverse quantization module 118 are used to generate the reconstruction block 236.

[0040] The prediction block 234 for a specific block is generated based on the block's prediction mode. If the block's encoding parameters indicate that the block is intra-frame predicted, the reconstructed block 236 of the reference block in the same image can be fed into the intra-frame prediction module 226 to generate the block's prediction block 234. If the block's encoding parameters indicate that the block is inter-frame predicted, the prediction block 234 is generated by the inter-frame prediction module 224. The functions of the intra-frame prediction module 226 and the inter-frame prediction module 224 are respectively similar to... Figure 1 The intra-frame prediction module 126 and the inter-frame prediction module 124.

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

[0042] Now for reference Figure 3 , Figure 3 Examples of coding tree unit partitioning of images in a video according to some embodiments of the present disclosure are described. As described above for... Figure 1 and Figure 2 The discussion focuses on dividing images into blocks for encoding video, such as the CTU (Coding Tree Unit) 302 in VVC. Figure 3 As shown. For example, CTU 302 can be a block of 128×128 pixels. In a certain order (e.g.) Figure 3 The CTUs are processed in the order shown. In some examples, each CTU302 in the image can be divided into, as shown... Figure 4The diagram shows one or more CUs (coding units) 402, which 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 CUs 402 can be rectangular or square and can be coded without further division into prediction units or transform units. Each CU 402 can be the same size as its root CTU 302, or it can be a sub-partition (as small as a 4×4 block) of the root CTU 302. Figure 4 As shown, in VVC, CTU 302 can be partitioned into CU 402, which can be done using a quadtree, a binary tree, or a ternary tree. Figure 4 In the diagram, solid lines indicate quadtree partitioning, while dashed lines indicate binary or ternary tree partitioning.

[0043] General constraint information in VVC version 1 (VVCv1)

[0044] In VVC version 1, the General Constraint Information (GCI) syntax structure `general_constraints_info()` is used to indicate specific constraint attributes of the bitstream. The GCI contains a list of constraint flags and non-flag syntax elements. The binary flag `gci_present_flag` specifies whether a GCI syntax element exists. `gci_present_flag` equals 1, indicating that the GCI syntax element exists in the `general_constraints_info()` syntax structure. `gci_present_flag` equals 0, indicating that the `general_constraints_info()` syntax structure does not contain a GCI field and does not impose any constraints.

[0045] General constraint information can be signaled using high-level syntax in multiple contexts. For example, GCI can be signaled in network packets containing only decoding capability information, such as Network Abstraction Layer (NAL) packets carrying only decoding capability information with its nal_unit_type set to 13 (i.e., DCI_NUT, which is the name of nal_unit_type). Alternatively, GCI can be signaled in the video parameter set or the sequence parameter set.

[0046] The purpose of the GCI syntax structure is to discover configuration information related to the features required for decoding the bitstream and to allow signaling interoperability points. These interoperability points impose restrictions beyond those specified by Profile, Tier, and Level (PTL), with a finer granularity than previous video coding standards. Similar to sub-profiles, the use of the GCI syntax structure allows for defining interoperability for decoder implementations that do not support all features of the VVC profile but address application-specific needs. Decoder implementations can examine GCI syntax elements to check if the bitstream avoids using specific features, in order to determine how to configure the decoding process and confirm whether the bitstream can be decoded by the decoder. Decoder implementations that support all features of the VVC profile can ignore GCI syntax element values, as such a decoder will be able to decode any bitstream conforming to the indicated PTL.

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

[0048]

[0049]

[0050]

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

[0052] In addition to the general constraint flags defined by VVCv1, additional general constraint flags can be provided via 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 from the bitstream and discarded (called the syntax element `gci_reserved_zero_bit[i]`). This specification ensures that the VVCv1 decoder is backward compatible, at least with the high-level syntax portions of bitstreams generated by later versions of VVC.

[0053] General constraint information in VVC version 2 (VVCv2)

[0054] In the current draft of VVC version 2 (“VVC Operational Scope 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 recommended that multiple additional coding tools be constrained through a common constraint flag. It is also recommended that the 8-bit field called gc_num_reserved_bits in VVCv1 be renamed to gci_num_additional_bits. The proposed adjusted syntax for VVCv2 is as follows:

[0055]

[0056] 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 elements is as follows:

[0057] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure besides the `gci_alignment_zero_bit` syntax element (if present). In a bitstream conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or 1. Values ​​greater than 1 for `gci_num_additional_bits` are reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of `gci_num_additional_bits` to be equal to 0 or 1, decoders conforming to this version of the document should allow values ​​greater than 1 for `gci_num_additional_bits` in the syntax and should ignore the values ​​of all `gci_reserved_zero_bit[i]` syntax elements when `gci_num_additional_bits` is greater than 1.

[0058] It is recommended that if the VVCv2 bitstream uses signals to send general constraint information, then if the six VVCv2 general constraint flags are not sent using signals, the syntax element gci_num_additional_bits should be set to 0, and if the six VVCv2 general constraint flags are sent using signals, then gci_num_additional_bits should be set to 1.

[0059] However, the VVCv2 specification for the general constraint syntax suggested above results in incompatibility with the VVCv1 decoder. Specifically, when signaling additional general constraint flags, the suggested VVCv2 syntax signals the general constraint flags by setting `gci_num_additional_bits` to 1. In the VVCv2 decoder, when signaling general constraint information, the `gci_num_additional_bits` syntax element is decoded from the bitstream as an 8-bit unsigned integer. If `gci_num_additional_bits` is decoded to a value of 1, 6 additional bits are decoded from the bitstream. These 6 bits are interpreted as the general constraint flags for additional decoding tools that are constrainable in VVCv2.

[0060] In a VVCv1 decoder, the same 8-bit field is interpreted as `gci_num_reserved_bits`. However, if this syntax element is decoded to a value of 1, only one additional bit is decoded from the bitstream. This bit is discarded and not used. Therefore, a VVCv1 decoder decoding a VVCv2 bitstream may encounter a synchronization problem due to the presence of 5 additional bits in the bitstream that the VVCv1 specification cannot recognize.

[0061] As discussed above, asynchrony is a serious incompatibility issue between different versions of video coding standards. A VVCv1 decoder may be unable to decode an entire VVCv2 bitstream because the VVCv2 bitstream may use encoding tools defined in the VVCv2 specification but unknown to the VVCv1 decoder. However, it is desirable for the VVCv1 decoder to be able to decode at least the high-level syntax portion of the VVCv2 bitstream. By successfully decoding the high-level syntax, the video decoder can determine not only general constraint information but also grade and layer information. This information provides the decoder with hints about the capabilities required to decode the bitstream. For example, general constraint information provides the decoder with indications related to which encoding tools are constrained by the bitstream. Grade and layer information provides the decoder with indications related to the uncompressed video data throughput (e.g., video data rate, frame rate, resolution, etc.) that needs to be supported.

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

[0063] Furthermore, in the VVCv2 decoder, when general constraint information is signaled, the `gci_num_additional_bits` syntax element is decoded from the bitstream into an 8-bit unsigned integer. If `gci_num_additional_bits` decodes to a value of 0, no further general constraint flag signaling is sent. In this case, no inferred value is specified for the additional general constraint flag, and the value of the additional general constraint flag is undefined. Therefore, the behavior of the encoding tools associated with the additional general constraint flag—whether they should be constrained or not—is ambiguous, which can lead to inconsistencies in decoder implementations.

[0064] In the VVC specification, the name of the syntax element `gci_reserved_zero_bit[i]` is misleading, implying that the value of such a syntax element must be 0. Typically, when a reserved syntax element is written into the bitstream as a placeholder by the encoder, a 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]` cannot be guaranteed to be 0. Several solutions to address this issue are proposed below.

[0065] Send general constraint information using signals

[0066] In one embodiment of signaling general constraint information to solve the out-of-sync problem 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, then 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 of 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 of the N additional coding tools. In one example, N is set to 6.

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

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

[0069] In one example of this embodiment, the general constraint information syntax of VVCv2 is modified using the six general constraint flags currently proposed for VVCv2 encoding tools, 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)".

[0070] Table 1

[0071]

[0072] In one example, if there are 6 additional general constraint flags for encoding tools in VVCv2, the corresponding semantics of gci_num_additional_bits are (added content is underlined, deleted content is indicated by strikethrough):

[0073] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 gci_num_additional_bits Apart from Other than 0 or 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow `gci_num_additional_bits` to appear in the syntax. Besides 0 or 6 The value, and should be in gci_num_additional_bits Besides 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored.

[0074] In the semantics example of `gci_num_additional_bits` above, `gci_num_additional_bits` is allowed to take values ​​other than 0 or 6, in addition to the values ​​0 or 6 discussed above. In other words, `gci_num_additional_bits` can take values ​​between 1 and 5. Values ​​greater than 6 are also allowed. If `gci_num_additional_bits` has a value between 1 and 5, denoted as M, then according to the syntax shown in Table 1 above, the decoder will skip the steps executed when the "if" condition is true and jump to the "else" step to set the value of "numAdditionalBitsUsed" to 0. Then, M bits will be read and discarded in the "for" loop. In this way, the problem of missing synchronization is avoided. If the value M of `gci_num_additional_bits` is greater than 6, then 6 additional general constraint flags will be extracted, and the remaining M-6 bits will be extracted and discarded.

[0075] In another example, if there are 6 additional general constraint flags for encoding tools in VVCv2, the corresponding semantics of gci_num_additional_bits are (added content is underlined, deleted content is shown with strikethrough):

[0076] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or 1. 6 gci_num_additional_bits is greater than 1 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or 1. 6 However, a decoder conforming to this document should allow gci_num_additional_bits greater than 1 in the syntax. 6 The value should be greater than 1 in gci_num_additional_bits. 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored.

[0077] In another embodiment where general constraint information is signaled, if the VVCv2 bitstream signals general constraint information (i.e., gci_present_flag is 1), and the VVCv2 general constraint information consists of N additional coding tools that can be constrained, then the syntax element gci_num_additional_bits can 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 will not be signaled. If gci_num_additional_bits is set to a non-zero value M, then the next M bits in the bitstream are used to signal the general constraint flag 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.

[0078] In one example of this embodiment, the modification to the general constraint information syntax of VVCv2 using the six general constraint flags currently proposed for VVCv2 coding tools can be as follows:

[0079]

[0080] In another example of this embodiment, equivalent behavior can be achieved using a more compact syntax table:

[0081]

[0082] An alternative arrangement of this embodiment can be expressed in the general constraint information syntax by changing the order of the general constraint flags used for VVCv2 encoding tools.

[0083] If there are 6 additional general constraint flags for encoding tools in VVCv2, then the semantics of gci_num_additional_bits can be as follows:

[0084] gci_num_additional_bits specifies the general constraint information syntax structure, in addition to gci_alignment_ The number of additional GCI bits beyond the zero_bit syntax element (if present). In this version of the bitstream conforming to this document. In this context, the value of `gci_num_additional_bits` should be in the range of 0 to 6, including the endpoints. Values ​​greater than 6 in the additional_bits are reserved for ITU-T|

[0085] ISO / IEC will use this in the future. Although this version of the document requires a value for gci_num_additional_bits. Located in the range of 0 to 6 including endpoints, but a decoder conforming to this version of the document should allow it to appear in the syntax. Values ​​greater than 6 in gci_num_additional_bits should be ignored when gci_num_additional_bits is greater than 6. It has the value of the gci_reserved_zero_bit[i] syntax element.

[0086] 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 bitstream signals general constraint information (i.e., if the value of gci_present_flag is 1), no constraints are imposed on the encoding 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:

[0087] gci_num_additional_bits specifies the general constraint information syntax structure, in addition to gci_alignment_ The number of additional GCI bits beyond the zero_bit syntax element (if present). In this version of the bitstream conforming to this document. In this context, the value of `gci_num_additional_bits` should be in the range of 0 to 6, including the endpoints. Values ​​greater than 6 for additional_bits are reserved for future use by ITU-T|ISO / IEC. (Although this version of the document...) This document requires the value of gci_num_additional_bits to be in the range of 0 to 6, including the endpoints, but this conforms to the documentation. This version of the decoder should allow values ​​greater than 6 for gci_num_additional_bits in the syntax, and should be in When gci_num_additional_bits is greater than 6, the values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. Additionally, when gci_present_flag equals 1, it does not apply to syntaxes that do not contain elements related to general_constraints_info(). The coding tool for the corresponding constraint flag applies any constraint.

[0088] In another arrangement of this embodiment, the corresponding tool is constrained when the VVCv2 bitstream sends general constraint information via signaling (i.e., if the value of gci_present_flag is 1) and does not send additional general constraint flags via signaling. This behavior can be expressed by modifying the semantics of the additional general constraint flags, as follows:

[0089] gci_num_additional_bits specifies the general constraint information syntax structure, in addition to gci_alignment_ The number of additional GCI bits beyond the zero_bit syntax element (if present). In this version of the bitstream conforming to this document. In this context, the value of `gci_num_additional_bits` should be in the range of 0 to 6, including the endpoints. Values ​​greater than 6 in the additional_bits are reserved for ITU-T|

[0090] ISO / IEC will use this in the future. Although this version of the document requires a value for gci_num_additional_bits. Located in the range of 0 to 6 including endpoints, but a decoder conforming to this version of the document should allow it to appear in the syntax. Values ​​greater than 6 in gci_num_additional_bits should be ignored when gci_num_additional_bits is greater than 6. It has the value of the gci_reserved_zero_bit[i] syntax element.

[0091] If `gci_all_rap_pictures_constraint_flag` is equal to 1, then all images in OlsInScope are specified as either IRAP images or GDR images with `ph_recovery_poc_cnt` equal to 0. If `gci_all_rap_pictures_constraint_flag` is equal to 0, then no such constraint is imposed. When gci_present_flag equals 1 and gci_ does not exist When inferring `all_rap_pictures_constraint_flag`, the inference value of `gci_all_rap_pictures_constraint_flag` is... The value is 1.

[0092] If gci_no_extended_precision_processing_constraint_flag is equal to 1, it means that sps_extended_precision_flag should be equal to 0 for all images in OlsInScope. If gci_no_extended_precision_processing_constraint_flag is equal to 0, then this constraint is not imposed. When gci_present_ When flag equals 1 and gci_no_extended_precision_processing_constraint_flag does not exist, inference The value of gci_no_extended_precision_processing_constraint_flag is equal to 1.

[0093] If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it means that sps_ts_residual_coding_rice_present_in_sh_flag should be equal to 0 for all images in OlsInScope. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, then this constraint is not imposed. When gci_present_ When flag equals 1 and gci_no_ts_residual_coding_rice_constraint_flag does not exist, infer gci_no_ The value of ts_residual_coding_rice_constraint_flag is equal to 1.

[0094] If gci_no_rrc_rice_extension_constraint_flag is equal to 1, it means that sps_rrc_rice_extension_flag should be equal to 0 for all images in OlsInScope. If gci_no_rrc_rice_extension_constraint_flag is equal to 0, then this constraint is not applied. When gci_present_flag equals 1 and gci_no_ does not exist. When inferring `rrc_rice_extension_constraint_flag`, `gci_no_rrc_rice_extension_` is used. The value of constraint_flag is equal to 1.

[0095] If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it means that sps_persistent_rice_adaptation_enabled_flag should be equal to 0 for all images in OlsInScope. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, then this constraint is not applied. When gci_ When present_flag equals 1 and gci_no_persistent_rice_adaptation_constraint_flag does not exist. It can be inferred that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 1.

[0096] If `gci_no_reverse_last_sig_coeff_constraint_flag` is equal to 1, it specifies that `sps_reverse_last_sig_coeff_enabled_flag` should be equal to 0 for all images in OlsInScope. If `gci_no_reverse_last_sig_coeff_constraint_flag` is equal to 0, then no such constraint is imposed. When `gci_present_flag` is equal to 1 and `gci_no_reverse_last_sig_coeff_constraint_flag` does not exist, it is inferred that the value of `gci_no_reverse_last_sig_coeff_constraint_flag` is equal to 1.

[0097] Initialize general constraint information flags

[0098] An embodiment for initializing general constraint information flags is described to address the ambiguity and inconsistency issues in the decoder implementation discussed above. In this embodiment, when `gci_present_flag` equals 1 and `gci_num_additional_bits` equals 0, `general_constraints_info()` does not impose constraints on the encoding tools associated with: `gci_all_rap_pictures_constraint_flag`, `gci_no_extended_precision_processing_constraint_flag`, `gci_no_ts_residual_coding_rice_constraint_flag`, `gci_no_reverse_last_sig_coeff_constraint_flag`, `gci_no_rrc_rice_extension_constraint_flag`, and `gci_no_persistent_rice_adaptation_constraint_flag`.

[0099] As an example, possible changes to the semantics of gci_num_additional_bits are shown below, based on the current version of the VVC version 2 specification (added content is underlined, and deleted content is shown with strikethrough).

[0100] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure besides the `gci_alignment_zero_bit` syntax element (if present). In a bitstream conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or 1. Values ​​greater than 1 for `gci_num_additional_bits` are reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of `gci_num_additional_bits` to be equal to 0 or 1, decoders conforming to this version of the document should allow values ​​greater than 1 for `gci_num_additional_bits` in the syntax and should 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 equals 1 and gci_num_additional_ When bits equals 0, general_constraints_info() will not impose any constraints on encoding tools associated with the following: 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.

[0101] As another example, the possible changes to the semantics of gci_num_additional_bits are shown below, based on the current version of the VVC version 2 specification.

[0102] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 gci_num_additional_bits Apart from Other than 0 or 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow `gci_num_additional_bits` to appear in the syntax. Besides 0 or 6 The value, and should be in gci_num_additional_bits Besides 0 or 6The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When gci_ When present_flag equals 1 and gci_num_additional_bits equals 0, general_constraints_info() No constraints will be imposed on the encoding tools associated with 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.

[0103] In the current version of the VVC version 2 specification, the semantics of gci_num_additional_bits are only used when gci_present_flag equals 1. The scenario where gci_present_flag equals 0 is addressed in different sections of the VVC version 2 specification. Therefore, the semantics of gci_num_additional_bits above, specifically "when gci_present_flag equals 1", are automatically satisfied. Furthermore, since the VVC version 2 specification does not allow gci_num_additional_bits to take values ​​between 1 and 5, "gci_num_additional_bits equals 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" do not exist. Therefore, the above changes to the semantics of gci_num_additional_bits are equivalent to the following:

[0104] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 gci_num_additional_bits Apart from Other than 0 or 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow `gci_num_additional_bits` to appear in the syntax. Besides 0 or 6 The value, and should be in gci_num_additional_bits Besides 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When it does not exist 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_ When using flag and gci_no_persistent_rice_adaptation_constraint_flag, general_ constraints_info() does not impose any constraints on the coding tools associated with 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 .

[0105] The following are several examples in which the inferred values ​​of the additional general constraint flags can be set in a manner similar to the semantics described above. For example, the semantics of the additional general constraint flags can be modified as follows to include inferred value settings:

[0106] If `gci_all_rap_pictures_constraint_flag` is equal to 1, then all images in OlsInScope are specified as either IRAP images or GDR images with `ph_recovery_poc_cnt` equal to 0. If `gci_all_rap_pictures_constraint_flag` is equal to 0, then no such constraint is imposed. If it does not exist, infer gci_all_rap_pictures_ The value of constraint_flag is equal to 0.

[0107] If gci_no_extended_precision_processing_constraint_flag is equal to 1, it means that sps_extended_precision_flag should be equal to 0 for all images in OlsInScope. If gci_no_extended_precision_processing_constraint_flag is equal to 0, then this constraint is not imposed. Inference when it does not exist The value of gci_no_extended_precision_processing_constraint_flag is equal to 0.

[0108] If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it means that sps_ts_residual_coding_rice_present_in_sh_flag should be equal to 0 for all images in OlsInScope. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, then this constraint is not imposed. Inference when it does not exist The value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0.

[0109] If gci_no_rrc_rice_extension_constraint_flag is equal to 1, it means that sps_rrc_rice_extension_flag should be equal to 0 for all images in OlsInScope. If gci_no_rrc_rice_extension_constraint_flag is equal to 0, then this constraint is not applied. If it does not exist, infer gci_no_rrc_rice_ The value of extension_constraint_flag is equal to 0.

[0110] If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it means that sps_persistent_rice_adaptation_enabled_flag should be equal to 0 for all images in OlsInScope. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, then this constraint is not applied. When it does not exist At that time, it is inferred that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 0.

[0111] If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it means that sps_reverse_last_sig_coeff_enabled_flag should be equal to 0 for all images in OlsInScope. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, then this constraint is not applied. If it does not exist, infer gci_no_ The value of reverse_last_sig_coeff_constraint_flag is equal to 0.

[0112] In another example, the semantics of the additional general constraint flag are modified as follows:

[0113] If `gci_all_rap_pictures_constraint_flag` is equal to 1, then all images in OlsInScope are specified as either IRAP images or GDR images with `ph_recovery_poc_cnt` equal to 0. If `gci_all_rap_pictures_constraint_flag` is equal to 0, then no such constraint is imposed. When gci_all_rap_pictures_ does not exist When setting constraint_flag, it is inferred that the value of gci_all_rap_pictures_constraint_flag is equal to 0.

[0114] If gci_no_extended_precision_processing_constraint_flag is equal to 1, it means that sps_extended_precision_flag should be equal to 0 for all images in OlsInScope. If gci_no_extended_precision_processing_constraint_flag is equal to 0, then this constraint is not imposed. When gci_no_ does not exist extended_precision_processing_constraint_flag, infer gci_no_extended_ The value of precision_processing_constraint_flag is equal to 0.

[0115] If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it means that sps_ts_residual_coding_rice_present_in_sh_flag should be equal to 0 for all images in OlsInScope. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, then this constraint is not imposed. When gci_no_ does not exist 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.

[0116] If gci_no_rrc_rice_extension_constraint_flag is equal to 1, it means that sps_rrc_rice_extension_flag should be equal to 0 for all images in OlsInScope. If gci_no_rrc_rice_extension_constraint_flag is equal to 0, then this constraint is not applied. When gci_no_rrc_rice_extension_ does not exist When checking constraint_flag, it is inferred that the value of gci_no_rrc_rice_extension_constraint_flag is equal to 0.

[0117] If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it means that sps_persistent_rice_adaptation_enabled_flag should be equal to 0 for all images in OlsInScope. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, then this constraint is not applied. When it does not exist When inferring gci_no_persistent_rice_adaptation_constraint_flag, the function gci_no_persistent_... The value of rice_adaptation_constraint_flag is equal to 0.

[0118] If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it means that sps_reverse_last_sig_coeff_enabled_flag should be equal to 0 for all images in OlsInScope. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, then this constraint is not applied. When gci_no_reverse_last_ does not exist When inferring sig_coeff_constraint_flag, infer gci_no_reverse_last_sig_coeff_constraint_flag. The value is equal to 0 .

[0119] In another example, the semantics of gci_num_additional_bits are modified as follows:

[0120] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 The value of gci_num_additional_bits is greater than... 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow gci_num_additional_bits greater than a certain value in the syntax. 6 The value, and should be greater than gci_num_additional_bits. 6When ignoring the values ​​of all gci_reserved_zero_bit[i] syntax elements. When gci_num_additional_bits equals 0 It is inferred that all constraint flags specified by the additional GCI bits are equal to 0.

[0121] In another example, the semantics of gci_num_additional_bits are modified as follows:

[0122] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 The value of gci_num_additional_bits is greater than... 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow gci_num_additional_bits greater than a certain value in the syntax. 6 The value, and should be greater than gci_num_additional_bits. 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. If it does not exist, infer the value specified by the additional GCI bits. All constraint flags are equal to 0. .

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

[0124]

[0125]

[0126] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 The value of gci_num_additional_bits is greater than... 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow gci_num_additional_bits greater than a certain value in the syntax. 6 The value, and should be greater than gci_num_additional_bits. 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When gci_num_additional_bits equals 0 The additional_general_constraints_info() syntax does not impose any constraints.

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

[0128] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 The value of gci_num_additional_bits is greater than... 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow gci_num_additional_bits greater than a certain value in the syntax. 6 The value, and should be greater than gci_num_additional_bits. 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When it does not exist, additional_general_ The constraints_info() syntax does not impose any constraints.

[0129] In another embodiment of initializing the general constraint information flags, when `gci_present_flag` equals 1 and `gci_num_additional_bits` equals 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` can always impose the corresponding constraints specified by the respective semantics of these flags. In other words, when a GCI flag exists and `gci_num_additional_bits` equals 0, it is inferred that these six GCI flags are equal to 1.

[0130] As an example, the possible changes to the semantics of gci_num_additional_bits are shown below, based on the currently added VVC version 2 specification.

[0131] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure besides the `gci_alignment_zero_bit` syntax element (if present). In a bitstream conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or 1. Values ​​greater than 1 for `gci_num_additional_bits` are reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of `gci_num_additional_bits` to be equal to 0 or 1, decoders conforming to this version of the document should allow values ​​greater than 1 for `gci_num_additional_bits` in the syntax and should 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 equals 1 and gci_num_additional_ When bits equals 0, infer gci_all_rap_pictures_constraint_flag and 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_ All flags are equal to 1.

[0132] As another example, the possible changes to the semantics of gci_num_additional_bits are shown below, based on the currently added VVC version 2 specification.

[0133] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, in addition to the `gci_alignment_zero_bit` syntax element (if present). In this version of the bitstream conforming to this document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 gci_num_additional_bits Apart from Other than 0 or 6 The value is reserved for future use by ITU-T|ISO / IEC. Although this version of the document requires the value of gci_num_additional_bits to be equal to 0 or... 6 However, decoders conforming to this document should allow `gci_num_additional_bits` to appear in the syntax. Besides 0 or 6 The value, and should be in gci_num_additional_bits Besides 0 or 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When gci_ When present_flag equals 1 and gci_num_additional_bits equals 0, infer gci_all_rap_pictures_ constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_ constraint_flag, gci_no_rrc_rice_extension_constraint_flag and gci_no_persistent_ rice_adaptation_constraint_flag are all equal to 1.

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

[0135]

[0136] gci_reserved_bit[i] It can have any value. Its existence and value do not affect the decoding process specified in this version of the specification. Decoders conforming to this version of the specification should ignore all... gci_reserved_bit[i] The value of the syntax element.

[0137] 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 can be as follows:

[0138]

[0139]

[0140] gci_reserved_bit[i] It can have any value. Its existence and value do not affect the decoding process specified in this version of the specification. Decoders conforming to this version of the specification should ignore all... gci_reserved_bit[i] The value of the syntax element.

[0141] General constraint mark

[0142] gci_all_rap_pictures_constraint_flag

[0143] The `gci_all_rap_pictures_constraint_flag` flag is used to indicate whether the images are restricted to IRAP or GDR images.

[0144] The Network Abstraction Layer (NAL) is a system interface that organizes VVC syntax elements into "NAL units." This structure allows for simple and efficient customization of VVC for a wide variety of use cases, ranging from real-time communication applications to file formats used in storage applications. A complete list of NAL unit types in the VVC standard is shown in the table below:

[0145]

[0146]

[0147] 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 according to VCL NAL units. Different VCL categories are useful at higher levels to indicate dependencies. For example, NAL units from TRAIL_NUT(0) to RSV_VCL_6(6) typically utilize inter-frame prediction tools that rely on access to a previously decoded (reference) image. 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 introduces problems when a reference image is unavailable.

[0148] An Intra-Random Access Point (IRAP) image is a coded image in which all VCL NAL units have the same nal_unit_type value in the range IDR_W_RADL to CRA_NUT (inclusive). An IRAP image can be either a CRA image or an IDR image. IRAP images do not use inter-frame predictions from reference images in the same layer during their decoding process. The first image in the bitstream in the decoding order is either an IRAP image or a Gradual Decode Refresh (GDR) image. For a single-layer bitstream, if the necessary parameter set is available when required, the IRAP image and all subsequent non-RASL images in the CLVS in decoding order can be correctly decoded without performing a decoding process on any image preceding the IRAP image in the decoding order. The value of pps_mixed_nalu_types_in_pic_flag for the IRAP image is equal to 0. When the pps_mixed_nalu_types_in_pic_flag of an image is equal to 0, and the nal_unit_type of any slice of the image is within the range of IDR_W_RADL to CRA_NUT (inclusive), all other slices of the image have the same nal_unit_type value, and after receiving the first slice, it is known that the image is an IRAP image.

[0149] Therefore, IRAP images do not use inter-frame prediction on the same layer. This limitation makes IRAP images error recovery points in streaming video applications or points for finding locations in video-on-demand playback applications. However, IRAP images are generally less efficient at compression than non-IRAP images.

[0150] The VVC standard introduces Gradual Decoding Refresh (GDR) images as a trade-off between non-IRAP and IRAP images. GDR images have "clean" portions that do not use inter-frame prediction, while the rest of the image is free to use inter-frame prediction. By dividing the image in this way, the "clean" portions will still be correctly decoded in the event of error events such as packet loss. The spatial location of the "clean" portions is rotated within successive GDR images, allowing the entire image to eventually be recovered from errors.

[0151] For streaming recovery video applications where playback flexibility is crucial, it may be desirable to restrict all images to either IRAP or GDR images. In VVCv2, the GCI flag `gci_all_rap_pictures_constraint_flag` is introduced, allowing such a constraint to be indicated at a high level. `gci_all_rap_pictures_constraint_flag` equal to 1 specifies that all images in OlsInScope are either IRAP images or GDR images with `ph_recovery_poc_cnt` equal to 0. `gci_all_rap_pictures_constraint_flag` equal to 0 imposes no such constraint. When `gci_all_rap_pictures_constraint_flag` is not present, its value is inferred to be 0.

[0152] When the profile_tier_level() syntax structure is included in a VPS, OlsInScope specifies one or more output tier sets (OLS) for the VPS. When the profile_tier_level() syntax structure is included in an SPS, OlsInScope only includes the lowest-level OLS among the tiers that reference the SPS, and that lowest-level OLS is an independent tier.

[0153] gci_no_extended_precision_processing_constraint_flag

[0154] The GCI flag `gci_no_extended_precision_processing_constraint_flag` indicates whether VVCv2 tools with extended transform precision are constrained at a higher level using signaling. In the VVC standard, video signal pixels are represented by integer values. All computations and processing described in the VVC standard are expressed using integer arithmetic. This constraint is significant for reasons of complexity and interoperability. First, integer arithmetic (addition, multiplication, division) is generally less computationally expensive than equivalent floating-point arithmetic. Second, floating-point arithmetic lacks deterministic standardization. Floating-point addition and multiplication are not necessarily commutative (e.g., (a+b)+c is not necessarily equal to a+(b+c)), and there is no guarantee that floating-point evaluations will be identical across different platforms.

[0155] The bit depth of a video signal sample is an attribute of the video source, denoted as BitDepth in the VVC standard. In hybrid video coding systems, video samples are predicted using either inter-frame prediction tools or intra-frame prediction tools. The difference between the original video sample and the predicted sample is called the residual. In the worst case, these residual coefficients could have an extended bit depth (e.g., BitDepth+1); however, in the VVC standard, the residual coefficients are pruned to maintain the BitDepth bit depth. In practice, the worst case will not occur because a real encoder will not choose a prediction tool that produces a residual larger than the original video signal.

[0156] The residual coefficients are then typically analyzed using the integerized discrete cosine transform (DCT) to generate the transform coefficients. The discrete cosine transform (DCT) is a linearly invertible function, which can be formally expressed as:

[0157]

[0158] in Represents an N-dimensional real space. The VVC standard uses the integer approximation of DCT (i.e., Unlike prediction, the bit depth is typically extended to some extent during the transform stage because the accuracy of the transform affects the coding gain. The bit depth of the approximate DCT coefficients and the bit depth of the resulting transform coefficients represent a design decision that balances hardware complexity and coding performance.

[0159] In VVCv1, the bit depth of the transform coefficients is 16. That is, each transform coefficient takes a position in [-2^36]. 15 ,2 15 Values ​​within the range of [-1]. Video samples are multiplied by integerized DCT coefficients, typically producing intermediate transform coefficients with a bit depth greater than 16. To produce transform coefficients with the desired bit depth, the intermediate transform coefficients are shifted to the right. This operation is inherently lossy.

[0160] 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 increases to (Log2TransformRange + 1). The bit depth of the precise transform coefficients depends on `BitDepth`. `sps_extended_precision_flag` equal to 1 specifies that extended dynamic range is used for transform coefficients during scaling and transforming, and for binarization of the `abs_remaining[]` and `dec_abs_level[]` syntax elements. `sps_extended_precision_flag` equal to 0 specifies that extended dynamic range is not used during scaling and transforming, and for binarization of the `abs_remaining[]` and `dec_abs_level[]` syntax elements. When it does not exist, the value of `sps_extended_precision_flag` is inferred to be 0. The variable `Log2TransformRange` is deduced as follows:

[0161] Log2TransformRange=sps_extended_precision_flag? Max(15,Min(20,BitDepth+6)):15

[0162] CoeffMin=-(1<<(sps_extended_precision_flag?Max(15,Min(20,BitDepth+6)):15))

[0163] CoeffMax=(1<<(sps_extended_precision_flag?Max(15,Min(20,BitDepth+6)):15))-1

[0164] If `gci_no_extended_precision_processing_constraint_flag` equals 1, it specifies that `sps_extended_precision_flag` should be equal to 0 for all images in OlsInScope. OlsInScope is also referred to here as the "set of output layers within the scope". When the `profile_tier_level()` syntax structure is included in a VPS, OlsInScope specifies one or more OLSs for the VPS. When the `profile_tier_level()` syntax structure is included in an SPS, OlsInScope is an OLS that includes only the lowest layer among the layers referenced by the SPS, and that lowest layer is an independent layer. If `gci_no_extended_precision_processing_constraint_flag` equals 0, no such constraint is imposed. When `gci_no_extended_precision_processing_constraint_flag` does not exist, it is inferred that the value of `gci_no_extended_precision_processing_constraint_flag` is equal to 0.

[0165] gci_no_ts_residual_coding_rice_constraint_flag

[0166] The GCI flag `gci_no_ts_residual_coding_rice_constraint_flag` indicates whether the VVCv2 tool, which sends explicit Rice parameter signaling at a higher level, is constrained. In entropy coding, each syntax element value is encoded into a bit sequence inserted into the bitstream through an entropy coding process.

[0167] The two entropy encoding processes used in VVC are Context Adaptive Binary Arithmetic Coding (CABAC) and Rice coding. The CABAC engine is adaptive, capable of compressing syntax elements to bit rates very close to the theoretical Shannon limit. However, arithmetic coding is more complex. To encode non-binary syntax elements (e.g., syntax elements with values ​​greater than 0 or 1) using CABAC, the syntax elements are first binary-coded into a set of "bins". The table below provides two examples of binarization. The second example illustrates that for variable-length binarization, some values ​​of syntax elements may not have corresponding bins.

[0168] Table: Fixed-Length Binarization Example

[0169] 0 00 1 01 2 10 3 11

[0170] Table: Examples of Variable-Length Binarization

[0171] 0 0 1 10 2 110 3 1110 4 1111

[0172] Each bin in the binarization can be encoded using the CABAC engine. However, in order to encode bins 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.

[0173] Encoding syntax elements with a large value range using only CABAC is undesirable because such elements would have long binarization times, resulting in excessive overhead in context storage and updates. For example, encoding residual coefficient values ​​using only CABAC is inconvenient. In contrast to CABAC, Rice coding can model the probability distribution of non-binary values ​​using compact parameters.

[0174] Rice coding, also known as Columbus coding or Rice-Columbus coding, is an entropy encoder controlled by a single parameter M, which is restricted to a positive integer. Rice coding is a subset of Columbus coding, where the entropy encoder is controlled by a single Rice parameter R, such that R is a non-negative integer. Rice code with the Rice parameter R is equivalent to the Columbus encoder, where M = 2. R .

[0175] The non-negative integer value x is binarized into a Ricean code with a Ricean parameter R, as shown below. The quotient q and remainder r are calculated as follows:

[0176]

[0177] r = x modulo 2 R

[0178] The Rice code for x is a 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:

[0179] 0 0 1 10 2 110 3 1110 4 11110 5 111110 6 111111

[0180] Because the unary code is truncated, the Rice code must also be truncated, meaning the range of values ​​that can be encoded for x is limited. In VVC, truncated Rice codes are applied to the range [0, 6*2]. R The value of x within ] .

[0181] The suffix code is a fixed-length code binarization of r bits, containing R bits. For example, if R = 3, the suffix code is:

[0182] 0 000 1 001 2 010 3 011 4 100 5 101 6 110 7 111

[0183] In VVC, residual coefficients are encoded using a combination of CABAC, Ricean coding, and exponential Golomb coding. A small number of syntax element flags are defined, sufficient to signal the values ​​of small residuals. For example, `sig_coeff_flag` indicates whether the residual amplitude is zero or non-zero. If `sig_coeff_flag` is 1, further flags can be signaled, typically 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 via CABAC.

[0184] Any residual amplitude of the residual coefficients 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 The syntax element is then sent entirely via signals using Rice encoding of `abs_remainder`. If the value of `abs_remainder` is greater than 6*2... R Then through 6*2 R Rice encoding and (abs_remainder-6*2) R The exponential Golomb coding is cascaded to send the syntax element using signals. The exponential Golomb coding process is not described here.

[0185] Although Rice coding is simpler than CABAC, it can still effectively compress to lower bit rates under appropriate conditions. For residual coefficients that are all small values, Rice coding with a smaller Rice parameter is more efficient. Conversely, when some residual coefficients are large, a larger Rice parameter may be more suitable. To adjust to the statistical data of the residual coefficients, the Rice parameter is adaptively determined based on the locSumAbs value, which is calculated based on the magnitude of adjacent residual coefficients.

[0186] 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

[0187] Adaptive Rice parameter determination is designed for residual coefficients in Regular Residual Coding (RRC), which are obtained by performing a Discrete Cosine Transform (DCT). However, in VVCv1, adaptive Rice parameter determination was also applied to residual coefficients in Transform Skip Residual Coding (TSRC). In VVCv2, it was recognized that alternative mechanisms for determining Rice parameters might be beneficial for transform skip coefficients.

[0188] The alternative mechanism in VVCv2 allows the Rice parameter to be explicitly signaled via the slice-level syntax element `sh_ts_residual_coding_rise_idx_minusl`. When this syntax element is signaled, the Rice parameter is set to `R = sh_ts_residual_coding_rise_idx_minusl + 1`. This value of the Rice parameter persists for the duration of the slice.

[0189]

[0190] Incrementing 1 to sh_ts_residual_coding_rice_idx_minusl specifies the Rice parameter used in the residual_ts_coding() syntax structure for the current slice. If it does not exist, the value of sh_ts_residual_coding_rice_idx_minusl is inferred to be 0.

[0191] Whether the substitution 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, substitution of Rice parameter signaling is not enabled. The GCI flag `gci_no_ts_residual_coding_rice_constraint_flag` determines whether VVCv2 tools that send explicit Rice parameter signaling by signaling at higher levels are constrained. If `gci_no_ts_residual_coding_rice_constraint_flag` is equal to 1, it specifies that `sps_ts_residual_coding_rice_present_in_sh_flag` should be equal to 0 for all images in OlsInScope. If `gci_no_ts_residual_coding_rice_constraint_flag` is equal to 0, such a constraint is not imposed. If gci_no_ts_residual_coding_rice_constraint_flag does not exist, it is inferred that the value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0.

[0192] gci_no_rrc_rice_extension_constraint_flag

[0193] `gci_no_rrc_rice_extension_constraint_flag` specifies the `sps_rrc_rice_extension_flag` for all images in OlsInScope. If `gci_no_rrc_rice_extension_constraint_flag` is equal to 1, then `sps_rrc_rice_extension_flag` for all images in OlsInScope should be equal to 0. If `gci_no_rrc_rice_extension_constraint_flag` is equal to 0, then this constraint is not applied.

[0194] For high-bit-depth and high-bit-rate applications, there are many large quantization levels at many locations in the RRC. For such applications, a large Rice parameter will result in fewer bins required to represent the remaining levels. The way the Rice parameter is derived in VVCv1 may not be optimal for VVCv2 applications. Therefore, an alternative Rice parameter derivation can be used, which can be signaled via `sps_rrc_rice_extension_flag`. `sps_rrc_rice_extension_flag` equal to 1 specifies the use of the alternative Rice parameter derivation with binarization for `abs_remaining[]` and `dec_abs_level[]`. `sps_rrc_rice_extension_flag` equal to 0 specifies that the alternative Rice parameter derivation with binarization for `abs_remaining[]` and `dec_abs_level[]` is not used. When it does not exist, the value of `sps_rrc_rice_extension_flag` is inferred to be 0.

[0195] The following example illustrates how to determine the Rice parameter using the sps_rrc_rice_extension_flag in VVCv2. Given an array AbsLevel[x][y] of transform blocks with component indices cIdx and top-left luminance positions (x0, y0), derive the variable locSumAbs as specified in the following pseudocode procedure (the underscores are added by VVCv2 over VVCv1):

[0196]

[0197]

[0198] The lists Tx[] and Rx[] are specified as follows:

[0199] Tx[ ]＝{32,128,512,2048} (1523)

[0200] Rx[ ]＝{0,2,4,6,8} (1524)

[0201] The value of the variable shiftVal is derived as follows:

[0202]

[0203] The value of locSumAbs is updated as follows:

[0204] locSumAbs=Clip3(0,31,(locSumAbs>>shiftVal)-baseLevel*5) (1526X2)

[0205] Given the variable locSumAbs, first Derive the Rice parameter cRiceParam as specified in Table 128. Then update cRiceParam, as follows:

[0206] cRiceParam=cRiceParam+shiftVal (1526X3)

[0207] When baseLevel equals 0, the derivation of the variable ZeroPos[n] is as follows:

[0208] ZeroPos[n]=(QState<2?1:2)< <cRiceParam (1518)

[0209] Table 128 - Explanation of cRiceParam based on locSumAbs

[0210] 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

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

[0212] gci_no_persistent_rice_adaptation_constraint_flag

[0213] `gci_no_persistent_rice_adaptation_constraint_flag` signals constraints on Rice parameter derivation using binarization from previous TU states. If `gci_no_persistent_rice_adaptation_constraint_flag` equals 1, it specifies that `sps_persistent_rice_adaptation_enabled_flag` should be equal to 0 for all images in OlsInScope. If `gci_no_persistent_rice_adaptation_constraint_flag` equals 0, no such constraint is imposed. When `gci_no_persistent_rice_adaptation_constraint_flag` is not present, it is inferred that the value of `gci_no_persistent_rice_adaptation_constraint_flag` is 0.

[0214] A `sps_persistent_rice_adaptation_enabled_flag` value of 1 specifies that at the beginning of each TU, the binarized Rice parameter derivation for `abs_remainder[]` and `dec_abs_level[]` is initialized using statistics accumulated from previous TUs. A `sps_persistent_rice_adaptation_enabled_flag` value of 0 specifies that previous TU states are not used in the Rice parameter derivation. When it does not exist, the value of `sps_persistent_rice_adaptation_enabled_flag` is deduced to be 0. The following example shows how `sps_persistent_rice_adaptation_enabled_flag` is used to determine Rice parameters in VVCv2 (the underscores are added by VVCv2 over VVCv1).

[0215] If the CTU is the first CTU in a slice or tile, the initialization procedure for the context variables is invoked as specified in sub-clause 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:

[0216] StatCoeff[i] = sps_persistent_rice_adaptation_enabled_flag? 2*Floor (Log2(BitDepth-10) :0

[0217] (1513X3)

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

[0219] gci_no_reverse_last_sig_coeff_constraint_flag

[0220] If `gci_no_reverse_last_sig_coeff_constraint_flag` is equal to 1, it specifies that `sps_reverse_last_sig_coeff_enabled_flag` should be equal to 0 for all images in OlsInScope. If `gci_no_reverse_last_sig_coeff_constraint_flag` is equal to 0, then this constraint is not imposed. When `gci_no_reverse_last_sig_coeff_constraint_flag` does not exist, it is inferred that the value of `gci_no_reverse_last_sig_coeff_constraint_flag` is equal to 0.

[0221] In standard Residual Coding (RRC), 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—are used to encode the position (x, y) of the last non-zero level in the TU. This position is encoded in VVCv1 using the difference between (x, y) and (0, 0) in the current TU. This is reasonable for VVCv1 because there are many zero levels within a TU, while most non-zero levels are located in the top-left corner of the TU. However, this may not be the case for VVCv2 applications, where many non-zero levels are scattered throughout the TU, and it may be more beneficial to encode the position (x, y) relative to the bottom-right corner (rather than the top-left corner (0, 0)). `sh_reverse_last_sig_coeff_flag` provides a tool for handling such applications.

[0222] If `sh_reverse_last_sig_coeff_flag` is equal to 1, it specifies that the coordinates of the last valid coefficient are encoded using ((Log2ZoTbWidth<<1)-1, (Log2ZoTbHeight<<1)-1) relative to each transform block of the current slice. If `sh_reverse_last_sig_coeff_flag` is equal to 0, it specifies that the coordinates of the last valid coefficient are encoded using (0,0) relative to each transform block of the current slice. If it does not exist, the value of `sh_reverse_last_sig_coeff_flag` is inferred to be 0.

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

[0224] - If last_sig_coeff_x_suffix does not exist, the following applies:

[0225] LastSignificantCoeffX=last_sig_coeff_x_prefix (193)

[0226] - Otherwise (if last_sig_coeff_x_suffix exists), the following applies:

[0227] LastSignificantCoeffX=(1<<((last_sig_coeff_x_prefix>>1)-1))*(194)

[0228] (2+(last_sig_coeff_x_prefix&1))+last_sig_coeff_x_suffix

[0229] When sh_reverse_last_sig_coeff_flag equals 1, the value of LastSignificantCoeffX is modified as follows:

[0230] LastSignificantCoeffX=(1< <Log2ZoTbWidth)-1-LastSignificantCoeffX(195)

[0231] - If last_sig_coeff_y_suffix does not exist, the following applies:

[0232] LastSignificantCoeffY=last_sig_coeff_y_prefix (196)

[0233] - Otherwise (if last_sig_coeff_y_suffix exists), the following applies:

[0234] LastSignificantCoeffY=(1<<((last_sig_coeff_y_prefix>>1)-1))*(197)

[0235] (2+(last_sig_coeff_y_prefix&1))+last_sig_coeff_y_suffix

[0236] When sh_reverse_last_sig_coeff_flag equals 1, the value of LastSignificantCoeffY is modified as follows:

[0237] LastSignificantCoeffY=(1< <Log2ZoTbHeight)-1-LastSignificantCoeffY(198)

[0238] VVCv2 slice header

[0239]

[0240] Figure 5 Examples of a process 500 for decoding video according to some embodiments of the present disclosure are described. One or more computing devices implement this by executing suitable program code. Figure 5 The operations described herein. For example, a computing device implementing the video decoder 200 can achieve this by executing program code. Figure 5 The operations depicted in the figure include, 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 illustrative purposes, the process 500 is described with reference to some examples depicted in the figures. However, other implementations are also possible.

[0241] At box 502, procedure 500 involves accessing the bitstream of a video signal (e.g., encoded video 202). At box 504, procedure 500 involves extracting the General Constraints Information (GCI) flag from the video bitstream. As discussed above, this binary flag, `gci_present_flag`, specifies whether a GCI syntax element exists. `gci_present_flag` equals 1, indicating that the GCI syntax element exists in the `general_constraints_info()` syntax structure and is used to indicate constraints imposed on additional encoding tools. `gci_present_flag` equals 0, indicating that the GCI syntax element does not exist and no general constraints are imposed on the video. Depending on the encoder, the GCI flag can be extracted from the video's network packets, the video parameter set, or the sequence parameter set.

[0242] At box 506, process 500 involves determining, based on the value of the GCI flag, whether to impose one or more general constraints on the video. If so (i.e., the GCI flag is 1), then at box 508, process 500 involves extracting a value M from the video bitstream representing the number of additional bits included in the video bitstream. These additional bits include multiple flag bits that indicate the corresponding additional coding tools to be constrained for the video.

[0243] At box 510, process 500 involves determining whether M > 5. If so, at box 512, process 500 involves extracting 6 flag bits from the bitstream. These 6 flag bits represent corresponding flags that indicate corresponding constraints on 6 additional coding tools. These 6 flags include: the flag gci_all_rap_pictures_constraint_flag, indicating that the images for the video are restricted to Intra-Frame Random Access Point (IRAP) images or Gradual Decoding Refresh (GDR) images; the flag gci_no_extended_precision_processing_constraint_flag, indicating whether the extended transform precision is constrained; the flag gci_no_ts_residual_coding_rice_constraint_flag, indicating whether the explicit Rice parameter signaling is constrained; and the flag gci_no_rr c_rice_extension_constraint_flag indicates the alternative Rice parameter derivation used for binarizing the quantization residuals of the video; gci_no_persistent_rice_adaptation_constraint_flag indicates whether to initialize the Rice parameter derivation used for binarization based on the previous transform unit; and gci_no_reverse_last_sig_coeff_constraint_flag indicates whether to impose constraints on the image in OlsInScope when decoding the last non-zero level position in the TU.

[0244] If M is greater than 6, then process 500 involves extracting the remaining M-6 bits from the bitstream at box 513 and discarding these M-6 bits. In other words, video decoding will be performed independently of these M-6 bits.

[0245] At box 514, process 500 involves decoding the remainder of the video bitstream into images based on constraints on six additional coding tools indicated by these six flags. For example, if the flag `gci_all_rap_pictures_constraint_flag` is 1, the decoder can determine that all images in one or more output layer sets are either IRAP images or GDR images with `ph_recovery_poc_cnt` equal to 0, and decode the GDR or IRAP images in one or more output layer sets. If the flag `gci_no_extended_precision_processing_constraint_flag` is 1, the decoder can determine that the extended transform precision is constrained and decode the video without using extended dynamic range by setting `sps_extended_precision_flag` to 0 for images in OlsInScope. If the flag `gci_no_ts_residual_coding_rice_constraint_flag` is 1, the decoder can determine that explicit Rice parameter signaling is constrained and decodes the remainder 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 can determine that alternative Rice parameter derivation for binarizing the quantization residuals of the video is constrained and decodes the remainder 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 can determine that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained and decodes the remainder of the video bitstream without initializing the Rice parameters for images in OlsInScope based on the previous transform unit state. If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder can determine that sps_reverse_last_sig_coeff_enabled_flag is equal to 0 for all images in OlsInScope, and determine that the coordinates of the last valid coefficient are encoded relative to the top-left corner (0,0) of each transform block of the current slice, and decode the remainder of the video bitstream by interpreting the coordinates of the decoded last valid coefficient as relative to the top-left corner (0,0) of each transform block of the current slice.

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

[0247] Figure 6 Another example of a process 600 for decoding video according to some embodiments of the present disclosure is described. One or more computing devices implement this by executing suitable program code. Figure 6 The operations described herein. For example, a computing device implementing the video decoder 200 can achieve this by executing program code. Figure 6 The operation depicted in the figure 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 illustrative purposes, the process 600 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0248] At box 602, procedure 600 involves accessing the bitstream of a video signal (e.g., encoded video 202). At box 604, procedure 600 involves extracting the General Constraints Information (GCI) flag from the video bitstream. As discussed above, this binary flag, `gci_present_flag`, specifies whether a GCI syntax element exists. `gci_present_flag` equals 1, indicating that the GCI syntax element exists in the `general_constraints_info()` syntax structure and is used to indicate constraints imposed on additional encoding tools. `gci_present_flag` equals 0, indicating that the GCI syntax element does not exist and no general constraints are imposed on the video. Depending on the encoder, the GCI flag can be extracted from the video's network packets, the video parameter set, or the sequence parameter set.

[0249] At box 606, process 600 involves determining, based on the value of the GCI flag, whether to impose one or more general constraints on the video. If so (i.e., the GCI flag is 1), then at box 608, process 600 involves extracting a value M from the video bitstream representing the number of additional bits included in the video bitstream. These additional bits include flag bits that indicate the corresponding additional coding tools to be constrained for the video.

[0250] At box 610, process 600 involves determining whether M is greater than 6. If so, at box 612, process 600 involves extracting 6 flag bits from the bitstream. These 6 flag bits represent corresponding flags that indicate corresponding constraints on 6 additional coding tools. These 6 flags include: the flag gci_all_rap_pictures_constraint_flag, indicating that the images for the video are restricted to Intra-Frame Random Access Point (IRAP) images or Gradual Decoding Refresh (GDR) images; the flag gci_no_extended_precision_processing_constraint_flag, indicating whether the extended transform precision is constrained; the flag gci_no_ts_residual_coding_rice_constraint_flag, indicating whether the explicit Rice parameter signaling is constrained; and the flag gci_no_rr c_rice_extension_constraint_flag indicates the alternative Rice parameter derivation used for binarizing the quantization residuals of the video; gci_no_persistent_rice_adaptation_constraint_flag indicates whether to initialize the Rice parameter derivation used for binarization based on the previous transform unit; and gci_no_reverse_last_sig_coeff_constraint_flag indicates whether to impose constraints on the image in OlsInScope when decoding the last non-zero level position in the TU.

[0251] At box 614, process 600 involves extracting M-6 bits following these 6 flag bits from the bitstream and discarding the extracted M-6 bits. In other words, video decoding is performed independently of these M-6 bits. At box 616, process 600 involves decoding the remainder of the video bitstream into images according to the constraints on 6 additional coding tools indicated by these 6 flags. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder can determine that all images in one or more output layer sets are either IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and decode the GDR or IRAP images in one or more output layer sets. If the flag gci_no_extended_precision_processing_constraint_flag is 1, the decoder can determine that the extended transform precision is constrained and decode the video without using extended dynamic range by setting sps_extended_precision_flag to 0 for images in OlsInScope. If the flag `gci_no_ts_residual_coding_rice_constraint_flag` is 1, the decoder can determine that explicit Rice parameter signaling is constrained and decodes the remainder 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 can determine that alternative Rice parameter derivation for binarizing the quantization residuals of the video is constrained and decodes the remainder 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 can determine that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained and decodes the remainder of the video bitstream without initializing the Rice parameters for images in OlsInScope based on the previous transform unit state.If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder can determine that sps_reverse_last_sig_coeff_enabled_flag is equal to 0 for all images in OlsInScope, and determine that the coordinates of the last valid coefficient are encoded relative to the top-left corner (0,0) of each transform block of the current slice, and decode the remainder of the video bitstream by interpreting the coordinates of the decoded last valid coefficient as relative to the top-left corner (0,0) of each transform block of the current slice.

[0252] If it is determined at box 610 that M is not greater than 6, then M is 0 or 6. If M is 6, then process 600 involves extracting 6 flag bits at box 620, 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 no general constraints are imposed on the video (i.e., the GCI flag is 0), then process 600 involves decoding the video into an image without general constraints at box 618. In some examples, according to the above description... Figure 2 The described process performs decoding. The decoded video can be output for display.

[0253] Figure 7 Another example of a process 700 for decoding video according to some embodiments of the present disclosure is described. One or more computing devices implement this by executing suitable program code. Figure 7 The operations described herein. For example, a computing device implementing the video decoder 200 can achieve this by executing program code. Figure 7 The operation depicted in the figure 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 illustrative purposes, the process 700 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0254] At box 702, procedure 700 involves accessing the bitstream of a video signal (e.g., encoded video 202). At box 704, procedure 700 involves extracting the General Constraints Information (GCI) flag from the video bitstream. As discussed above, this binary flag, `gci_present_flag`, specifies whether a GCI syntax element exists. `gci_present_flag` equals 1, indicating that the GCI syntax element exists in the `general_constraints_info()` syntax structure and is used to indicate constraints imposed on additional encoding tools. `gci_present_flag` equals 0, indicating that the GCI syntax element does not exist and no general constraints are imposed on the video. Depending on the encoder, the GCI flag can be extracted from the video's network packets, the video parameter set, or the sequence parameter set.

[0255] At box 706, process 700 involves determining, based on the value of the GCI flag, whether to impose one or more general constraints on the video. If so (i.e., the GCI flag is 1), then at box 708, process 700 involves extracting a value M from the video bitstream representing the number of additional bits included in the video bitstream. These additional bits include multiple flag bits that indicate the corresponding additional coding tools to be constrained for the video.

[0256] At box 710, process 700 involves determining whether M is greater than 5. If not, then at box 712, process 700 involves extracting M bits from the bitstream and discarding these M bits. At box 714, process 700 involves decoding the remaining portion of the video bitstream into an image independently of these M bits. If it is determined at box 710 that M is not greater than 5, then process 700 involves extracting 6 flag bits at box 718, as discussed above. If M is greater than 6, then process 700 involves extracting the remaining M-6 bits from the bitstream at box 719 and discarding these M-6 bits. In other words, video decoding will be performed independently of these 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.

[0257] If it is determined at box 706 that the GCI flag indicates no universal constraints are imposed on the video (i.e., the GCI flag is 0), then process 700 involves decoding the video into an image without universal constraints. In some examples, according to the above description... Figure 2 The described process performs decoding. The decoded video can be output for display.

[0258] Example of a computational system for implementing the transmission of general constraint information via signals.

[0259] Any suitable computing system can be used to perform the operations described herein. For example, Figure 8 Describes what can be achieved Figure 1 Video encoder 100 or Figure 2 Examples of computing devices 800 for video decoder 200. In some embodiments, computing device 800 may include processor 812, which is communicatively coupled to memory 814 and executes computer-executable program code and / or accesses information stored in memory 814. Processor 812 may include a microprocessor, application-specific integrated circuit (“ASIC”), state machine, or other processing device. 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 be communicative to a computer-readable medium storing instructions, which, when executed by processor 812, cause the processor to perform the operations described herein.

[0260] Memory 814 may include any suitable non-transitory computer-readable medium. Computer-readable medium may include any electronic, optical, magnetic, or other storage device capable of providing computer-readable instructions or other program code to a processor. Non-limiting examples of computer-readable media include disks, memory chips, ROM, RAM, ASICs, configured processors, optical memory, magnetic tape or other magnetic memory, or any other medium from which a computer processor may read instructions. 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.

[0261] 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 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 printed circuit board connection, via cable connection, via wireless communication, etc.). Non-limiting examples of input devices 820 include touchscreens (e.g., one or more cameras for imaging a touch area, or pressure sensors for detecting pressure changes caused by touch), mice, keyboards, or any other devices that may 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, a speaker, or any other device that can be used to display or otherwise present the output generated by the computing device.

[0262] The computing device 800 can execute program code, which configures the processor 812 to execute the code described above. Figures 1 to 7 One or more of the operations described. The program code may include video encoder 100 or video decoder 200. The program code may reside in memory 814 or any suitable computer-readable medium and may be executed by processor 812 or any other suitable processor.

[0263] 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 to one or more data networks 828. Non-limiting examples of the network interface device 824 include Ethernet network adapters, modems, etc. The computing device 800 may transmit messages as electronic or optical signals via the network interface device 824.

[0264] Overall considerations

[0265] This document sets forth numerous specific details to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter can be practiced even without these specific details. In other instances, methods, apparatus, or systems known to a person of ordinary skill have not been described in detail so as not to obscure the claimed subject matter.

[0266] Unless otherwise specifically stated, it should be understood that throughout the discussion in this specification, terms such as “processing,” “computing,” “calculating,” “determining,” and “identifying” are used to refer to actions or processes of computing devices (such as one or more computers or similar electronic computing devices) that manipulate or convert data represented as physical electronic or magnetic quantities within the memory, registers, or other information storage, transmission, or display devices of a computing platform.

[0267] 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 multi-purpose microprocessor-based computer systems that access stored software that programs or configures the computing system from a general-purpose computing device to a special-purpose computing device, thereby implementing one or more embodiments of the subject matter herein. Any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the teachings contained herein in software used for programming or configuring the computing device.

[0268] Embodiments of the methods disclosed herein can be executed in the operation of such a computing device. The order of the boxes appearing in the above examples can be changed—for example, the boxes can be reordered, combined, and / or broken down into sub-blocks. Some boxes or processes can be executed in parallel.

[0269] The use of “suitable for” or “configured to” in this document implies open-ended and inclusive language, which does not exclude devices suitable for or configured to perform additional tasks or steps. Furthermore, the use of “based on” implies open-endedness and inclusiveness, because processes, steps, calculations, or other actions “based on” one or more of the listed conditions or values ​​may actually be based on additional conditions or values ​​beyond those listed. The headings, lists, and numbering included in this document are for illustrative purposes only and are not intended to be limiting.

[0270] While the subject matter of this document has been described in detail with reference to specific embodiments thereof, it should be understood that those skilled in the art, upon understanding the foregoing, will readily make changes, variations, and equivalents to such embodiments. Therefore, it should be understood that this disclosure is presented for illustrative purposes rather than for limitation, and does not exclude such modifications, variations, and / or additions to the subject matter that would be obvious to those skilled in the art.

Claims

1. A method for decoding video, the method comprising: Extract the General Constraint Information (GCI) flag from the bitstream; Based on the value of the GCI flag, determine one or more general constraints to be applied to the decoding of the bitstream; In response to determining that one or more general constraints are imposed on the decoded bitstream, a value indicating the number of additional bits included in the bitstream is extracted from the bitstream, the additional bits including a flag bit indicating a corresponding additional coding configuration to be constrained for the video; Determine whether the value is greater than 5; as well as In response to determining that the value is greater than 5, Extract six flag bits representing six corresponding flags from the bitstream. These six flags indicate corresponding constraints on six additional coding configurations. The remaining portion of the bitstream is decoded into an image.

2. The method according to claim 1, wherein, The six markers include: The first flag indicates that the image of the video is limited to an intra-frame random access point (IRAP) image or a progressive decode refresh (GDR) image; The second indicator shows whether the accuracy of the extended transformation is constrained. The third flag indicates whether the explicit Rice parameter signaling is constrained; The fourth flag indicates the derivation of the alternative Rice parameter for binarization of the quantization residuals used in the video; The fifth flag indicates whether the Ricean parameter derivation for binarization is initialized based on the previous transformation unit; and The sixth flag indicates whether constraints are imposed on the image in the OlsInScope set of output layers within the range when decoding the last non-zero level position of the transform unit.

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

4. The method according to claim 2, wherein, Decoding the remaining portion of the bitstream into the image includes one or more of the following: Based on the first flag being 1, it is determined that all images in one or more output layer sets are either IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and the GDR images or IRAP images in the one or more output layer sets are decoded. Based on the second flag being 1, it is determined that the extended transform precision is constrained, and the remaining part of the bitstream is decoded by setting sps_extended_precision_flag for the images in the OlsInScope output layer set within the range to 0, so that the extended dynamic range is not used. Based on the third flag being 1, it is determined that the explicit Rice parameter signaling is constrained, and the remaining part of the bitstream is decoded by disabling the alternative Rice parameter signaling for images in the output layer set OlsInScope within the range. Based on the fourth flag being 1, it is determined that the derivation of the alternative Rice parameter used to binarize the quantization residual of the video is constrained, and the remaining part of the bitstream is decoded by disabling the alternative Rice parameter signaling for images in the output layer set OlsInScope within the range. Based on the determination 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 portion of the bitstream is decoded without initializing the Rice parameters based on the previous transform unit state for images in the output layer set OlsInScope within the range; or Based on the sixth flag being 1, the coordinates of the last effective coefficient relative to the top left corner of each transform block of the slice are encoded, and the remaining part of the bitstream is decoded by interpreting the coordinates of the decoded last effective coefficient as relative to the top left corner of each transform block of the slice.

5. The method according to claim 1, wherein, The GCI flag is extracted from the network packets of the video, the video parameter set of the video, or the sequence parameter set of the video.

6. The method according to claim 1, further comprising: In response to determining that the value is greater than 5, the value numAdditionalBitsUsed, which indicates the extracted additional bits, is set to 6; Extract a set of bits from the bitstream, wherein the number of bits in the set is equal to gci_num_additional_bits - numAdditionalBitsUsed, where gci_num_additional_bits represents the number of additional bits included in the bitstream; and Independent of the bit set, the remaining portion of the bitstream is decoded into the image.

7. The method according to claim 1, further comprising: In response to determining that the value is not greater than 5, the value numAdditionalBitsUsed, which indicates the extracted additional bits, is set to 0; Extract a set of bits from the bitstream, wherein the number of bits in the set is equal to gci_num_additional_bits - numAdditionalBitsUsed, where gci_num_additional_bits represents the number of additional bits included in the bitstream; and Independent of the bit set, the remaining portion of the bitstream is decoded into an image.

8. A method for encoding video, the method comprising: Determine the value of the General Constraint Information (GCI) flag, the value of which indicates one or more general constraints to be imposed on encoding the video; and encode the GCI flag into the bitstream; In response to applying the one or more general constraints to the encoded video, a value is determined indicating the number of additional bits included in the bitstream, the additional bits including flag bits indicating the corresponding additional encoding configuration to be constrained for the video; Determine whether the value is greater than 5; and In response to determining that the value is greater than 5, Determine six flag bits representing six corresponding flags, the six corresponding flags indicating corresponding constraints on six additional coding configurations, and encode the six flag bits into the bitstream; and The video is encoded into the remainder of the bitstream.

9. The method according to claim 8, wherein, The six markers include: The first flag indicates that the image of the video is limited to an intra-frame random access point (IRAP) image or a progressive decode refresh (GDR) image; The second indicator shows whether the accuracy of the extended transformation is constrained. The third flag indicates whether the explicit Rice parameter signaling is constrained; The fourth flag indicates the derivation of the alternative Rice parameter for binarization of the quantization residuals used in the video; The fifth flag indicates whether the Ricean parameter derivation for binarization is initialized based on the previous transformation unit; and The sixth flag indicates whether constraints are imposed on the image in the OlsInScope set of output layers within the range when decoding the last non-zero level position of the transform unit.

10. The method according to claim 8, wherein, The GCI flag is encoded into the network packets of the video, the video parameter set of the video, or the sequence parameter set of the video.

11. The method of claim 8, further comprising: In response to determining that the value is greater than 5, the value numAdditionalBitsUsed, which indicates the extracted additional bits, is set to 6; Determine the number of bits in the bit set, wherein the number of bits in the bit set is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the number of additional bits included in the bitstream; and encode the bit set into the bitstream; and Independent of the bit set, the images of the video are encoded into the remainder of the bitstream.

12. The method according to claim 8, further comprising: In response to determining that the value is not greater than 5, the value numAdditionalBitsUsed, which indicates the extracted additional bits, is set to 0; Determine the number of bits in the bit set, wherein the number of bits in the bit set is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the number of additional bits included in the bitstream; and encode the bit set into the bitstream; and Independent of the bit set, the images of the video are encoded into the remainder of the bitstream.

13. A non-transitory computer-readable medium having stored thereon program code and a bitstream, the program code, when executed by one or more processing devices, causing the one or more processing devices to perform the steps of the method for encoding video according to any one of claims 8 to 12 to generate the bitstream.

14. A system for decoding video, comprising: 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 including: Extract the General Constraint Information (GCI) flag from the bitstream; Based on the value of the GCI flag, determine one or more general constraints to be applied to the decoding of the bitstream; In response to determining that one or more general constraints are imposed on the decoded bitstream, a value indicating the number of additional bits included in the bitstream is extracted from the bitstream, the additional bits including a flag bit indicating a corresponding additional coding configuration to be constrained for the video; Determine whether the value is greater than 5; and In response to determining that the value is greater than 5, Extract six flag bits representing six corresponding flags from the bitstream. These six flags indicate corresponding constraints on six additional coding configurations. The remaining portion of the bitstream is decoded into an image.

15. The system according to claim 14, wherein, The six markers include: The first flag indicates that the image of the video is limited to an intra-frame random access point (IRAP) image or a progressive decode refresh (GDR) image; The second indicator shows whether the accuracy of the extended transformation is constrained. The third flag indicates whether the explicit Rice parameter signaling is constrained; The fourth flag indicates the derivation of the alternative Rice parameter for binarization of the quantization residuals used in the video; The fifth flag indicates whether the Ricean parameter derivation for binarization is initialized based on the previous transformation unit; and The sixth flag indicates whether constraints are imposed on the image in the OlsInScope set of output layers within the range when decoding the last non-zero level position of the transform unit.

16. The system according to claim 15, wherein, The operation also includes one or more of the following: It is determined that the first flag does not exist in the bitstream, and it is inferred that the value of the first flag is 0, which is used to indicate that no constraint is imposed on the corresponding decoding; It is determined that the second flag does not exist in the bitstream, and it is inferred that the value of the second flag is 0, which is used to indicate that no constraint is imposed on the corresponding decoding; It is determined that the third flag does not exist in the bitstream, and it is inferred that the value of the third flag is 0, which indicates that no constraint is imposed on the corresponding decoding; It is determined that the fourth flag does not exist in the bitstream, and it is inferred that the value of the fourth flag is 0, which is used to indicate that no constraint is imposed on the corresponding decoding; It is determined that the fifth flag does not exist in the bitstream, and it is inferred that the value of the fifth flag is 0, which is used to indicate that no constraint is imposed on the corresponding decoding; or It is determined that the sixth flag does not exist in the bitstream, and it is inferred that the value of the sixth flag is 0, which indicates that no constraint is imposed on the corresponding decoding.

Images