Signaling general constraints information for video coding

Abstract

In some embodiments, a video decoder decodes a video from a bitstream of the video. The video decoder extracts an additional bit count M from the bitstream of the video, where the additional bit count M indicates a number of additional general constraint information (GCI) bits contained in the bitstream of the video. The additional bits include flag bits respectively indicating that each of the additional coding tools is constrained for the video, and an expected value of the additional bit count is 0 or 6. In a case where it is determined that the extracted additional bit count M is greater than 6, the decoder extracts M-6 bits of the bitstream following the six flag bits. Further, the decoder decodes a remaining portion of the bitstream as the pictures without relying on the extracted M-6 bits and based at least in part on constraints specified for each of the additional coding tools by the six flag bits, respectively.

Description

[0001] Cross-referencing

[0002] This application claims priority to U.S. Provisional Application No. 63 / 266,615, filed January 10, 2022, entitled “Signaling Methods for General Constraints Information for Video Coding”; U.S. Provisional Application No. 63 / 266,616, filed January 10, 2022, entitled “Initialization Method for General Constraint Information Flags for Video Coding”; and U.S. Provisional Application No. 63 / 266,765, filed January 13, 2022, entitled “Signaling and Initialization Methods for General Constraints Information for Video Coding”. The entire contents of these applications are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to video processing. Specifically, this disclosure relates to the signaling and initialization of general constraint information for video encoding. Background Technology

[0004] Ubiquitous camera devices, such as smartphones, tablets, and computers, have made capturing video or images easier than ever before. However, even a short video can contain a large amount of data. Video encoding technologies (including encoding and decoding) allow video data to be compressed to smaller sizes, enabling the storage and transmission of various video formats. Video encoding is widely used in digital television broadcasting, internet and mobile network video transmission, real-time applications (such as video chat and video conferencing), DVDs, and Blu-ray discs. To reduce storage space used for storing video and / or network bandwidth consumption used for transmitting video, it is desirable to improve the efficiency of video encoding schemes. Summary of the Invention

[0005] Some embodiments involve the transmission and initialization of general constraint information for video coding. In one example, a video decoding method includes: extracting an additional bit count M from the video bitstream, wherein the additional bit count M indicates the number of additional general constraint information (GCI) bits contained in the video bitstream, the additional bits including flag bits indicating that each additional coding tool is constrained for the video, and the expected value of the additional bit count being 0 or 6; if it is determined that the extracted additional bit count M is greater than 6, extracting M-6 bits from the bitstream after the six flag bits; and decoding the remainder of the video bitstream into an image, independent of the extracted M-6 bits and at least partially based on the constraints specified by the six flag bits for each additional coding tool.

[0006] 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 an additional bit count M from a video bitstream, wherein the additional bit count M indicates the number of additional General Constraint Information (GCI) bits contained in the video bitstream, the additional bits including flag bits indicating that each additional coding tool is constrained for the video, and the expected value of the additional bit count being 0 or 6; if it is determined that the extracted additional bit count M is greater than 6, extracting M-6 bits from the bitstream after the six flag bits; and decoding the remainder of the video bitstream into an image, independent of the extracted M-6 bits and at least partially based on the constraints specified by the six flag bits for each additional coding tool.

[0007] In another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device. The processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform operations. The operations include: extracting an additional bit count M from a video bitstream, wherein the additional bit count M indicates the number of additional general constraint information (GCI) bits contained in the video bitstream, the additional bits including flag bits indicating that each additional coding tool is constrained for the video, and the expected value of the additional bit count being 0 or 6; if it is determined that the extracted additional bit count M is greater than 6, extracting M-6 bits from the bitstream after the six flag bits; and decoding the remainder of the video bitstream into an image, independent of the extracted M-6 bits and at least partially based on the constraints specified by the six flag bits for each additional coding tool.

[0008] These illustrative embodiments are mentioned not to limit or define this disclosure, but to provide examples to aid in understanding it. Other embodiments are also discussed and further described in the detailed description. Attached Figure Description

[0009] The features, embodiments, and advantages of this disclosure can be better understood by reading the following detailed description with reference to the accompanying drawings.

[0010] Figure 1 A block diagram illustrating an example of a video encoder for implementing the embodiments presented herein.

[0011] Figure 2 A block diagram illustrating an example of a video decoder for implementing the embodiments presented herein.

[0012] Figure 3 Examples of dividing images in a video into encoded tree units according to some embodiments of the present disclosure are described.

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

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

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

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

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

[0018] Various embodiments provide the transmission and initialization of general constraint information for video coding. As mentioned above, an increasing amount of video data is being generated, stored, and transmitted. This is beneficial for improving both the efficiency and stability of video coding techniques, enabling successful decoding of video signals at the decoder. Issues related to video decoding stability include incompatibility and inconsistency. With the development of video coding technology, newer video coding standards have emerged. One such standard is the Multifunction Video Coding Standard Version 1 (VVC Version 1), jointly published by the International Organization for Standardization (ISO) under the title "ISO / IEC 23090-3:2021 Information technology—Coded representation of immersive media—Part 3: Multifunction video coding" and by the International Telecommunication Union (ITU) under the title "ITU-T H.26 Recommendation (08 / 2020): Multifunction Video Coding". In this disclosure, the Multifunction Video Coding Standard Version 1 may be referred to as "VVC Version 1" or "VVCvl". Version 1 of VVC has been superseded by Version 2 of the Multifunction Video Coding Standard, which will be jointly published by ISO under the title "ISO / IEC 23090-3:2022 Information Technology—Coding Representation of Immersive Media—Part 3: Multifunction Video Coding" and by ITU under the title "ITU-TH.266 Recommendation (04 / 2022): Multifunction Video Coding". In this disclosure, Version 2 of the Multifunction Video Coding Standard may be referred to as "VVC Version 2" or "VVCv2". To ensure that video signals encoded using older versions of the video coding standard can be successfully decoded by video decoders using newer versions, video coding schemes should be designed to be backward compatible with older versions. However, the transmission of general constraint information used in the current draft of VVC Version 2 can lead to asynchronous video decoding, a serious incompatibility issue between different versions of the video coding standard. Furthermore, in the current draft of VVC Version 2, general constraint flags related to general constraint information may be undefined in some cases, resulting in ambiguous and inconsistent decoder implementations. The various embodiments described herein address these issues by introducing methods for transmitting and initializing general constraint information for video coding, thereby improving the stability of video coding.

[0019] 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` specifies the presence of a GCI syntax element. In some embodiments, if the VVC version 2 bitstream transmits general constraint information (i.e., `gci_present_flag` is 1), and the VVC version 2 general constraint information consists of N additional coding tools that may be constrained, then the value of the syntax element `gci_num_additional_bits` corresponding to these N additional coding tools can only be set to 0 or N. If `gci_num_additional_bits` is set to 0, the general constraint flags for these N additional coding tools are not transmitted. If `gci_num_additional_bits` is set to N, the following N bits in the bitstream are used to transmit the general constraint flags for these N additional coding tools. In one example, N is set to 6.

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

[0021] In some embodiments, initializing the general constraint information flag addresses the aforementioned issues of ambiguity and inconsistency in decoder implementation. In these embodiments, 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 the general constraint information flag. In examples where a flag value of 0 indicates no constraints, the value of the general constraint information flag is inferred to be 0 when the flag is absent.

[0022] The embodiments described in this disclosure provide methods for transmitting and inferring general constraint flags for additional coding tools in VVC Version 2. Unlike prior art, the methods described in this disclosure produce high-level syntax bitstreams compatible with VVC Version 1 decoders and can be decoded without causing asynchrony between the behavior of VVC Version 1 and VVC Version 2 decoders. The inference rules described in this disclosure eliminate ambiguity in 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.

[0023] Referring now to the accompanying drawings, FIG1 is a block diagram illustrating an example of a video encoder 100 for implementing the embodiments presented herein. Figure 1 In the example shown, the video encoder 100 includes a segmentation 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.

[0024] The input to the video encoder 100 is an input video 102, which contains a series of pictures (also called frames or images). In a block-based video encoder, for each picture, the video encoder 100 uses a segmentation module 112 to segment the picture into blocks 104, each block containing multiple pixels. These blocks can be macroblocks, coding tree units, coding units, prediction units, and / or prediction blocks. A picture may contain blocks of different sizes, and the block segmentation of different pictures in the video may also be different. Each block can be encoded using different prediction methods, such as intra-frame prediction, inter-frame prediction, or a mixture of intra-frame and inter-frame prediction.

[0025] Typically, the first frame of a video signal is an intra-coded frame, encoded using only intra-frame prediction. In intra-frame prediction mode, blocks of the frame are predicted using only the data already encoded within the same frame. Intra-coded frames can be decoded without using information from other frames. To perform intra-frame prediction, Figure 1The video encoder 100 shown can use an intra-prediction module 126. The intra-prediction module 126 generates an intra-prediction block (prediction block 134) using reconstructed samples from reconstructed blocks 136 of adjacent blocks in the same image. Intra-prediction is performed according to the intra-prediction mode selected for this block. Afterwards, the video encoder 100 calculates the difference between block 104 and intra-prediction block 134. This difference is called residual block 106.

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

[0027] 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, thereby representing video samples with fewer bits.

[0028] Quantization of coefficients / samples within a block can be performed independently, a method employed in some existing video compression standards (such as H.264 and HEVC). For an N*M block, the two-dimensional coefficients of the block can be converted into a one-dimensional 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 the block may depend on the state of the previous quantized value 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.

[0029] The quantization level can be adjusted using the quantization step size. For example, for scalar quantization, different quantization step sizes can be used 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). The quantization parameter is provided in the encoded bitstream of the video, allowing the video decoder to access and apply the quantization parameter for decoding.

[0030] Subsequently, the entropy coding module 116 encodes the quantized samples to further reduce the size of the video signal. The entropy coding module 116 applies an entropy coding algorithm to the quantized samples. In some examples, the quantized samples are binarized into a binary container, and the coding algorithm further compresses this binary container into bits. Examples of binarization methods include, but are not limited to, truncated Ricean (TR) and Finite k-order Exponential Golomb (EGk) combined binarization, as well as k-order Exponential Golomb binarization. Examples of entropy coding algorithms include, but are not limited to, Variable Length Coding (VLC) schemes, Content Adaptive VLC (CAVLC) schemes, arithmetic coding schemes, binarization, Content Adaptive Binary Arithmetic Coding (CABAC), Syntax-Based Content Adaptive Binary Arithmetic Coding (SBAC), Probability Interval Split Entropy (PIPE) coding, or other entropy coding techniques. The entropy-coded data is added to the bitstream of the output encoded video 132.

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

[0032] Blocks in subsequent frames following the first intra-frame 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 used to perform motion compensation on blocks based on motion estimates provided by the motion estimation module 122.

[0033] The motion estimation module 122 compares the current block 104 of the current image with the decoded reference image 108 to perform 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), which, along with the selected reference block, is provided to the inter-frame prediction module 124. In some cases, multiple reference blocks may be identified for the current block in multiple decoded reference images 108. Therefore, multiple motion vectors are generated and provided to the inter-frame prediction module 124 along with the corresponding reference blocks.

[0034] 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 more than one prediction block exists, these prediction blocks are merged with certain weights to generate the prediction block 134 for the current block.

[0035] 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 way as the residual of the intra-frame prediction block. Similarly, the reconstructed inter-frame prediction block 136 can be obtained by inverse quantizing and inverse transforming the residual, and then combining it with the corresponding prediction block 134.

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

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

[0038] Entropy decoding module 216 is used to perform entropy decoding on 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 encoded video 202 into a binary representation, and then converts the binary representation into quantization levels of coefficients. The entropy-decoded coefficient levels are dequantized by dequantization module 218, and then inversely transformed to the pixel domain by inverse transform module 219. The functions of dequantization module 218 and inverse transform module 219 are similar to those described above relative to... Figure 1 The inverse quantization module 118 and inverse transform module 119 are described. The inverse-transformed residual block 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 is not applied. The dequantized samples generated by the inverse quantization module 118 are used to generate the reconstruction block 236.

[0039] The prediction block 234 for a specific block is generated based on the prediction mode of that block. If the encoding parameters of the block indicate that the block is intra-frame predicted, the reconstructed block 236 of the reference block in the same image can be input into the intra-frame prediction module 226 to generate the prediction block 234 for that block. If the encoding parameters of the block 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 inter-frame prediction module 124 are included.

[0040] As mentioned above, in contrast to Figure 1 The inter-frame prediction described herein 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 the reconstructed blocks 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 for output.

[0041] Now for reference Figure 3 , Figure 3 Examples of dividing images in a video into coding tree units according to some embodiments of this disclosure are described. As described above relative to... Figure 1 and Figure 2 As described above, in order to encode images in a video, the images are divided into blocks, such as... Figure 3 The CTU (Coding Tree Unit) 302 in the VVC shown. For example, CTU 302 can be a 128x128 pixel block. In order (e.g.) Figure 3 The CTU is processed in the order shown. In some examples, such as... Figure 4As shown, each CTU 302 in the image can be divided into one or more CUs (coding units) 402. CUs 402 can be further divided into prediction units or transform units (TUs) for prediction and transformation. Depending on the coding scheme, the CTU 302 can be divided into CUs 402 in different ways. For example, in VVC, 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 as large as its root CTU 302, or it can be a smaller subdivision of the root CTU 302, such as a 4x4 block. Figure 4 As shown, the partitioning from CTU 302 to CU 402 in VVC can be a quadtree partition, a binary tree partition, or a ternary tree partition. Figure 4 In the diagram, solid lines indicate quadtree partitioning, while dashed lines indicate binary or ternary tree partitioning.

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

[0043] In VVC version 1, 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` specifies whether a GCI syntax element exists. `gci_present_flag` equal to 1 indicates that a GCI syntax element exists in the `general_constraints_info()` syntax structure. `gci_present_flag` equal to 0 indicates that a GCI field does not exist in the `general_constraints_info()` syntax structure, and the `general_constraints_info()` syntax structure does not impose any constraints.

[0044] General constraint information can be transmitted in a variety of content using high-level syntax. For example, GCI can be transmitted in network packets containing only decoding capability information, such as a Network Abstraction Layer (NAL) packet with nal_unit_type set to 13 (i.e., DCI_NUT as the name of nal_unit_type), which carries only decoding capability information. Alternatively, GCI can be transmitted in video parameter sets or sequence parameter sets.

[0045] The purpose of the GCI syntax structure is to enable the discovery of configuration information related to the functionality required for decoding the bitstream and to allow the transmission of interoperability points. These interoperability points impose constraints beyond the specifications of the Configuration, Level, and Grade (PTL), with a granularity finer than that allowed by previous video coding standards. Similar to sub-configurations, the use of the GCI syntax structure allows for the definition of interoperability for decoder implementations that do not support all the functionality of the VVC configuration but meet specific application requirements. Decoder implementations can examine GCI syntax elements to check whether the bitstream avoids using specific functionality, thereby determining how to configure the decoding process and identifying whether the bitstream can be decoded by the decoder. Decoder implementations that support all the functionality of the VVC configuration can ignore GCI syntax element values ​​because such a decoder can decode any bitstream that conforms to the indicated PTL.

[0046] The general constraint information syntax structure defined in VVC version 1 is as follows.

[0047]

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

[0049] In addition to the general constraint flags defined by VVCvl, the syntax element `gci_num_reserved_bits` specifies additional general constraint flags. `gci_num_reserved_bits` is an 8-bit unsigned integer whose value indicates the number of additional bits transmitted in the general constraint syntax structure. In the VVC specification, these additional bits (called the syntax element `gci_reserved_zero_bit[i]`) are extracted from the bitstream and discarded. This specification allows the VVCvl decoder to be at least backward compatible with the high-level syntax portions of bitstreams produced by later versions of VVC.

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

[0051] The current draft of VVC version 2 (“VVC Operational Scope Extension (Draft 5)”, ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 Joint Video Experts Group document, JVET-X2005) proposes additional coding tools for constraints via general constraint flags. It is recommended that the 8-bit field called gc_num_reserved_bits in VVCv1 be renamed to gci_num_additional_bits. The proposed syntax adjustments for VVCv2 are as follows.

[0052]

[0053] There are six additional general constraint flags: gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, gci_no_persistent_rice_adaptation_constraint_flag, and gci_no_reverse_last_sig_coeff_constraint_flag. The suggested interpretation (“semantics”) of the gci_num_additional_bits syntax element is as follows.

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

[0055] It is recommended that if the VVCv2 bitstream transmits general constraint information, the syntax element gci_num_additional_bits should be set to 0 if the six VVCv2 general constraint flags are not transmitted, and gci_num_additional_bits should be set to 1 if the six VVCv2 general constraint flags are transmitted.

[0056] However, the VVCv2 general constraint syntax specification suggested above leads to incompatibility with the VVCv1 decoder. Specifically, when transmitting the additional general constraint flag, the suggested VVCv2 syntax transmits the flag by setting `gci_num_additional_bits` to 1. In the VVCv2 decoder, when transmitting general constraint information, the `gci_num_additional_bits` syntax element is decoded from the bitstream as an 8-bit unsigned integer. If the value of `gci_num_additional_bits` is decoded to 1, 6 additional bits are decoded from the bitstream. These 6 bits are interpreted as general constraint flags for additional decoding tools that may be constrained in VVCv2.

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

[0058] As mentioned above, asynchrony is a serious incompatibility issue between different versions of video coding standards. A VVCv1 decoder cannot decode the entirety of a VVCv2 stream because the VVCv2 stream can use encoding tools defined in the VVCv2 specification but unknown to the VVCv1 decoder. However, a VVCv1 decoder should ideally be able to decode at least the high-level syntax portion of the VVCv2 stream. By successfully decoding the high-level syntax, the video decoder can determine not only general constraint information but also configuration and hierarchical information. This information provides the decoder with hints about the capabilities required to decode the stream. For example, general constraint information indicates to the decoder which encoding tools are constrained by the stream. Configuration and hierarchical information indicates to the decoder the required uncompressed video data throughput (such as video data rate, frame rate, resolution, etc.).

[0059] 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 gracefully terminate the decoding process. Conversely, asynchrony during high-level grammar decoding means that the information provided in the high-level grammar cannot be decoded correctly. In the worst case, the decoder may decode completely incorrect grammar element values ​​after asynchrony occurs, leading to incorrect parameter settings and incorrect decoding of subsequent low-level grammar, resulting in decoding failure.

[0060] Furthermore, in the VVCv2 decoder, when transmitting general constraint information, the `gci_num_additional_bits` syntax element is decoded into an 8-bit unsigned integer from the bitstream. If the value of `gci_num_additional_bits` is decoded to 0, no further general constraint flags are transmitted. In this case, no inferred value is specified for the additional general constraint flags, and their values ​​are undefined. Therefore, it is unclear whether the encoding tools associated with the additional general constraint flags should be constrained or unconstrained, which may lead to inconsistencies in decoder implementations.

[0061] In the VVC specification, the name of the syntax element `gci_reserved_zero_bit[i]` misleadingly implies that the value of such a syntax element must be 0. Typically, when the encoder writes a reserved syntax element as a placeholder into the bitstream, a default value is embedded in the name of the reserved syntax element. However, the design of the generic constraint syntax structure means that the encoder will never write `gci_reserved_zero_bit[i]`. `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, there is no guarantee that the value of `gci_reserved_zero_bit[i]` will be 0. Some solutions to address this issue will be proposed below.

[0062] Transmit general constraint information

[0063] In one embodiment, general constraint information is transmitted to solve the above-mentioned out-of-sync problem. If the VVCv2 bitstream transmits general constraint information (i.e., the value of gci_present_flag is 1), and the VVCv2 general constraint information consists of N additional coding tools that may be constrained, the value of the syntax element gci_num_additional_bits can only be set to 0 or N. If gci_num_additional_bits is set to 0, the general constraint flags of these N additional coding tools are not transmitted. If gci_num_additional_bits is set to N, the subsequent N bits in the bitstream are used to transmit the general constraint flags of these N additional coding tools. In one example, N is set to 6.

[0064] The VVCv2 bitstream does not allow the value of gci_num_additional_bits to be set to a value other than 0 or N. However, the VVCv2 decoder can still process general constraint information with the value of gci_num_additional_bits set to a value other than 0 or N. For example, the value of gci_num_additional_bits can be set to a value greater than 0 and less than N, or greater than N. Let the decoded value of gci_num_additional_bits be 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 them. If M is greater than N (i.e., N < M), after decoding the gci_num_additional_bits syntax element, the decoder extracts N bits from the bitstream and interprets them as the general constraint flags of N additional coding tools. Then, the decoder extracts M - N bits from the bitstream as the gci_reserved_zero_bit[ i ] syntax element and discards them.

[0065] In other examples, the VVCv2 decoder does not need to process general constraint information with the value of gci_num_additional_bits set to a value greater than 0 but less than N. A legal VVCvl bitstream can only set the value of gci_num_reserved_bits to 0. A legal VVCv2 bitstream can only set the value of gci_num_reserved_bits to 0 or N. Future versions of the VVC bitstream will not allow the value of gci_num_additional_bits to be set to a value between 0 and N.

[0066] In one example of this embodiment, the general constraint information syntax of VVCv2 is modified to the six general constraint flags proposed by the current VVCv2 encoding tools. The modification is shown in Table 1 below (added parts are shown underlined, and deleted parts are shown with strikethrough), where "if(gci_num_additional_bits>0)" is replaced with "if(gci_num_additional_bits>5)".

[0067] Table 1

[0068]

[0069] In one example, if the encoding tools in VVCv2 have 6 additional general constraint flags, the corresponding semantics of gci_num_additional_bits are (the added part is shown underlined):

[0070] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 . Other than 0 and 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for this version should allow... Other than 0 and 6 The value of gci_num_additional_bits appears in the syntax and should be in gci_num_additional_bits Other than 0 and 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored.

[0071] In the example of gci_num_additional_bits semantics above, besides 0 or 6, gci_num_additional_bits also allows values ​​other than 0 or 6. In other words, the value of gci_num_additional_bits can be between 1 and 5. The value of gci_num_additional_bits can also be greater than 6. If the value of gci_num_additional_bits (denoted as M) is between 1 and 5, 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, assigning the value of "numAdditionalBitsUsed" to 0. Then, M bits are read and discarded in the "for" loop. This avoids synchronization problems. If the value of gci_num_additional_bits M is greater than 6, 6 additional general constraint flags will be extracted, and the remaining M-6 bits will be extracted and discarded.

[0072] In another example, if the encoding tools in VVCv2 have 6 additional general constraint flags, then the corresponding semantics of gci_num_additional_bits are (the added part is shown underlined):

[0073] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 Greater than 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for a version larger than [specific value]. 6 The value of gci_num_additional_bits appears in the syntax and should be greater than gci_num_additional_bits. 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored.

[0074] In another embodiment of transmitting general constraint information, if the VVCv2 bitstream transmits general constraint information (i.e., the value of gci_present_flag is 1), and the VVCv2 general constraint information consists of N potentially constrained additional coding tools, then the syntax element gci_num_additional_bits can be set to the value M. M ranges from 0 to N (inclusive) (0 ≤ M ≤ N). If gci_num_additional_bits is set to 0, the general constraint flags for these N additional coding tools are not transmitted. If gci_num_additional_bits is set to a non-zero value M, the following M bits in the bitstream are used to transmit the general constraint flags for M of these 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.

[0075] In one example of this embodiment, the general constraint information syntax of VVCv2 is modified to the six general constraint flags proposed by the current VVCv2 coding tools, as shown in the table below.

[0076]

[0077] In another example of this embodiment, equivalent behavior can be achieved with a more compact syntax table.

[0078]

[0079] By changing the order of the general constraint flags in the VVCv2 encoding tool, an alternative arrangement of this embodiment can be described in the general constraint information syntax.

[0080] If the encoding tools in VVCv2 have 6 additional general constraint flags, then the corresponding semantics of gci_num_additional_bits can be as follows.

[0081] gci_num_additional_bits specifies the general constraint information syntax structure, excluding gci_alignment_ The additional GCI bits beyond the zero_bit syntax element (if present). In a bitstream conforming to this version of this document, gci_ The value of `num_additional_bits` should be between 0 and 6 (inclusive). Values ​​of `gci_num_additional_bits` greater than 6 are also acceptable. Reserved by ITU-T | ISO / IEC for future use. Although this version of the document requires gci_num_additional_ The values ​​of bits are 0 to 6 (inclusive), but the decoder for this version of the document should allow values ​​greater than 6 for gci_num_. The additional_bits value appears in the syntax and should be ignored if gci_num_additional_bits is greater than 6. The value of the gci_reserved_zero_bit[i] syntax element.

[0082] In this embodiment, depending on the value of gci_num_additional_bits, some or all of the additional general constraint flags may not be transmitted. In one arrangement of this embodiment, when the VVCv2 bitstream transmits general constraint information (i.e., if the value of the gci_present_flag flag is 1), constraints are not imposed on the encoding tools corresponding to the untransmitted additional general constraint flags. This behavior can be described by modifying the semantics of gci_num_additional_bits as follows.

[0083] gci_num_additional_bits specifies the general constraint information syntax structure, excluding gci_alignment_ The additional GCI bits beyond the zero_bit syntax element (if present). In a bitstream conforming to this version of this document, gci_ The value of `num_additional_bits` should be between 0 and 6 (inclusive). Values ​​of `gci_num_additional_bits` greater than 6 are also acceptable. Reserved by ITU-T | ISO / IEC for future use. Although this version of the document requires gci_num_additional_ The values ​​of bits are 0 to 6 (inclusive), but the decoder for this version of the document should allow values ​​greater than 6 for gci_num_. The additional_bits value appears in the syntax and should be ignored if gci_num_additional_bits is greater than 6. The value of the syntax element `gci_reserved_zero_bit[i]`. Furthermore, when `gci_present_flag` equals 1, it is not correct in... The general_constraints_info() syntax does not have a corresponding constraint flag encoding tool to apply constraints.

[0084] In another arrangement of this embodiment, the corresponding tool is constrained when the VVCv2 stream transmits general constraint information (i.e., if the value of gci_present_flag is 1) and the additional general constraint flag is not transmitted. This behavior can be described by modifying the semantics of the additional general constraint flag, as follows.

[0085] gci_num_additional_bits specifies the general constraint information syntax structure, excluding gci_alignment_ The additional GCI bits beyond the zero_bit syntax element (if present). In a bitstream conforming to this version of this document, gci_ The value of `num_additional_bits` should be between 0 and 6 (inclusive). Values ​​of `gci_num_additional_bits` greater than 6 are also acceptable. Reserved by ITU-T | ISO / IEC for future use. Although this version of the document requires gci_num_additional_ The values ​​of bits are 0 to 6 (inclusive), but the decoder for this version of the document should allow values ​​greater than 6 for gci_num_. The additional_bits value appears in the syntax and should be ignored if gci_num_additional_bits is greater than 6. The value of the gci_reserved_zero_bit[i] syntax element.

[0086] A `gci_all_rap_pictures_constraint_flag` value of 1 specifies that all images in OlsInScope are either GDR images with `ph_recovery_poc_cnt` equal to 0, or IRAP images. A `gci_all_rap_pictures_constraint_flag` value of 0 does not impose this constraint. When gci_present_flag equals 1 and gci_all_rap_ When pictures_constraint_flag does not exist, the value of gci_all_rap_pictures_constraint_flag is pushed. The value is equal to 1.

[0087] A value of 1 for `gci_no_extended_precision_processing_constraint_flag` means that `sps_extended_precision_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_extended_precision_processing_constraint_flag` means that this constraint is not applied. When gci_present_flag When gci_no_extended_precision_processing_constraint_flag is equal to 1 and does not exist, gci_no_ The value of extended_precision_processing_constraint_flag is inferred to be equal to 1.

[0088] A value of 1 for `gci_no_ts_residual_coding_rice_constraint_flag` means that `sps_ts_residual_coding_rice_present_in_sh_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_ts_residual_coding_rice_constraint_flag` means that this constraint is not applied. When gci_present_flag When gci_no_ts_residual_coding_rice_constraint_flag is equal to 1 and does not exist, gci_no_ts_ The value of residual_coding_rice_constraint_flag is inferred to be equal to 1.

[0089] A value of 1 for `gci_no_rrc_rice_extension_constraint_flag` means that `sps_rrc_rice_extension_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_rrc_rice_extension_constraint_flag` means that this constraint is not applied. When gci_present_flag equals 1 and gci_no_rrc_ When rice_extension_constraint_flag is not present, gci_no_rrc_rice_extension_constraint_ The value of flag is inferred to be equal to 1.

[0090] A value of 1 for `gci_no_persistent_rice_adaptation_constraint_flag` means that `sps_persistent_rice_adaptation_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_persistent_rice_adaptation_constraint_flag` means that this constraint is not applied. When gci_ When present_flag equals 1 and gci_no_persistent_rice_adaptation_constraint_flag does not exist. The value of gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 1.

[0091] A value of 1 for `gci_no_reverse_last_sig_coeff_constraint_flag` means that `sps_reverse_last_sig_coeff_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_reverse_last_sig_coeff_constraint_flag` means that this constraint is not applied. When gci_present_flag equals 1 and gci_ When no_reverse_last_sig_coeff_constraint_flag does not exist, gci_no_reverse_last_sig_ The value of coeff_constraint_flag is inferred to be equal to 1.

[0092] Initialize general constraint information flags

[0093] This article describes an embodiment for initializing general constraint information flags to address the issues of ambiguity and inconsistency in the aforementioned decoder implementations. 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`.

[0094] As an example, the semantics of gci_num_additional_bits may change as shown below, based on the current version of the VVC version 2 specification (added parts are shown underlined).

[0095] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of this document, the value of `gci_num_additional_bits` should be either 0 or 1. Values ​​of `gci_num_additional_bits` greater than 1 are reserved by ITU-T | ISO / IEC for future use. Although this version of this document requires the value of `gci_num_additional_bits` to be either 0 or 1, decoders conforming to this version of this document should allow values ​​of `gci_num_additional_bits` greater than 1 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_bits equals 0, general_ constraints_info() does not correspond to gci_all_rap_pictures_constraint_flag or 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_ The constraint_flag related coding tools apply constraints.

[0096] As another example, the semantics of gci_num_additional_bits may change as shown below, based on the current version of the VVC version 2 specification.

[0097] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 . Other than 0 and 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for this version should allow... Other than 0 and 6 The value of gci_num_additional_bits appears in the syntax and should be in gci_num_additional_bits Other than 0 and 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When gci_present_flag equals 1 and gci_num_additional_bits, etc. When the value is 0, general_constraints_info() does not apply to gci_all_rap_pictures_constraint_flag. gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_ coding_rice_constraint_flag、gci_no_reverse_last_sig_coeff_constraint_flag、 gci_no_rrc_rice_extension_constraint_flag and gci_no_persistent_rice_ The adaptation_constraint_flag related coding tools impose constraints.

[0098] 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 other sections of the VVC version 2 specification. Therefore, the "when `gci_present_flag` equals 1" condition in the above `gci_num_additional_bits` semantics is automatically satisfied. Furthermore, since the VVC version 2 specification does not allow the value of gci_num_additional_bits to be 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 modification to the semantics of gci_num_additional_bits is equivalent to the following.

[0099] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 . Other than 0 and 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for this version should allow... Other than 0 and 6 The value of gci_num_additional_bits appears in the syntax and should be in gci_num_additional_bits Other than 0 and 6The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When gci_all_rap_pictures_constraint_flag, gci_no_ extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_ constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_ rice_extension_constraint_flag and gci_no_persistent_rice_adaptation_ When constraint_flag does not exist, general_constraints_info() does not correspond to gci_all_rap_ pictures_constraint_flag, gci_no_extended_precision_processing_constraint_ flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_ coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag and gci_no_ The persistent_rice_adaptation_constraint_flag related coding tools impose constraints.

[0100] Below are a few examples where 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.

[0101] A `gci_all_rap_pictures_constraint_flag` value of 1 specifies that all images in OlsInScope are either GDR images with `ph_recovery_poc_cnt` equal to 0, or IRAP images. A `gci_all_rap_pictures_constraint_flag` value of 0 does not impose this constraint. When not present, gci_all_rap_pictures_ The value of constraint_flag is inferred to be equal to 0.

[0102] A value of 1 for `gci_no_extended_precision_processing_constraint_flag` means that `sps_extended_precision_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_extended_precision_processing_constraint_flag` means that this constraint is not applied. When it does not exist, gci_no_ The value of extended_precision_processing_constraint_flag is inferred to be equal to 0.

[0103] A value of 1 for `gci_no_ts_residual_coding_rice_constraint_flag` means that `sps_ts_residual_coding_rice_present_in_sh_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_ts_residual_coding_rice_constraint_flag` means that this constraint is not applied. When it does not exist, gci_no_ The value of ts_residual_coding_rice_constraint_flag is inferred to be equal to 0.

[0104] A value of 1 for `gci_no_rrc_rice_extension_constraint_flag` means that `sps_rrc_rice_extension_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_rrc_rice_extension_constraint_flag` means that this constraint is not applied. When it does not exist, gci_no_rrc_rice_extension_ The value of constraint_flag is inferred to be equal to 0.

[0105] A value of 1 for `gci_no_persistent_rice_adaptation_constraint_flag` means that `sps_persistent_rice_adaptation_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_persistent_rice_adaptation_constraint_flag` means that this constraint is not applied. When it does not exist The value of gci_no_persistent_rice_adaptation_constraint_flag is inferred to be equal to 0.

[0106] A value of 1 for `gci_no_reverse_last_sig_coeff_constraint_flag` means that `sps_reverse_last_sig_coeff_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_reverse_last_sig_coeff_constraint_flag` means that this constraint is not applied. When it does not exist, gci_no_reverse_ The value of last_sig_coeff_constraint_flag is inferred to be equal to 0.

[0107] In another example, the semantic modification of the appended general constraint flag is as follows.

[0108] A `gci_all_rap_pictures_constraint_flag` value of 1 specifies that all images in OlsInScope are either GDR images with `ph_recovery_poc_cnt` equal to 0, or IRAP images. A `gci_all_rap_pictures_constraint_flag` value of 0 does not impose this constraint. When gci_all_rap_pictures_constraint_flag is not When it exists, its value is inferred to be equal to 0.

[0109] A value of 1 for `gci_no_extended_precision_processing_constraint_flag` means that `sps_extended_precision_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_extended_precision_processing_constraint_flag` means that this constraint is not applied. When gci_no_extended_ When precision_processing_constraint_flag does not exist, its value is inferred to be equal to 0.

[0110] A value of 1 for `gci_no_ts_residual_coding_rice_constraint_flag` means that `sps_ts_residual_coding_rice_present_in_sh_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_ts_residual_coding_rice_constraint_flag` means that this constraint is not applied. When gci_no_ts_ When residual_coding_rice_constraint_flag does not exist, its value is inferred to be equal to 0.

[0111] A value of 1 for `gci_no_rrc_rice_extension_constraint_flag` means that `sps_rrc_rice_extension_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_rrc_rice_extension_constraint_flag` means that this constraint is not applied. When gci_no_rrc_rice_extension_constraint_ When flag does not exist, its value is inferred to be equal to 0.

[0112] A value of 1 for `gci_no_persistent_rice_adaptation_constraint_flag` means that `sps_persistent_rice_adaptation_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_persistent_rice_adaptation_constraint_flag` means that this constraint is not applied. When gci_no_ When persistent_rice_adaptation_constraint_flag does not exist, its value is inferred to be equal to 0.

[0113] A value of 1 for `gci_no_reverse_last_sig_coeff_constraint_flag` means that `sps_reverse_last_sig_coeff_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_reverse_last_sig_coeff_constraint_flag` means that this constraint is not applied. When gci_no_reverse_last_sig_ When coeff_constraint_flag does not exist, its value is inferred to be equal to 0.

[0114] In another example, the semantics of gci_num_additional_bits are modified as follows.

[0115] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 Greater than 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for a version larger than [specific value]. 6 The value of gci_num_additional_bits appears in the syntax 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, all constraint flags specified by the additional GCI bits are... The inference is that it equals 0.

[0116] In another example, the semantics of gci_num_additional_bits are modified as follows.

[0117] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 Greater than 6The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for a version larger than [specific value]. 6 The value of gci_num_additional_bits appears in the syntax 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 is not present, all constraint flags specified by the additional GCI bits are inferred to be equal to 0.

[0118] In another example, the syntax and semantic modifications of the general constraint information syntax element are as follows.

[0119]

[0120]

[0121] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 Greater than 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for a version larger than [specific value]. 6 The value of gci_num_additional_bits appears in the syntax 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, additional_general_constraints_ The info() syntax does not impose any constraints.

[0122] In another example, the semantic modification of the general constraint information syntax element is as follows.

[0123] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 Greater than 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for a version larger than [specific value]. 6 The value of gci_num_additional_bits appears in the syntax 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, the additional_general_constraints_info() syntax structure does not impose any constraints. What constraints?

[0124] 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 defined by the semantics of these flags. In other words, when a GCI flag exists and `gci_num_additional_bits` equals 0, these six GCI flags are inferred to be equal to 1.

[0125] As an example, the semantics of gci_num_additional_bits may change as shown below, based on the current additions to the VVC version 2 specification.

[0126] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of this document, the value of `gci_num_additional_bits` should be either 0 or 1. Values ​​of `gci_num_additional_bits` greater than 1 are reserved by ITU-T | ISO / IEC for future use. Although this version of this document requires the value of `gci_num_additional_bits` to be either 0 or 1, decoders conforming to this version of this document should allow values ​​of `gci_num_additional_bits` greater than 1 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_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_ The persistent_rice_adaptation_constraint_flag is inferred to be equal to 1.

[0127] As another example, the semantics of gci_num_additional_bits may change as shown below, based on the current additions to the VVC version 2 specification.

[0128] `gci_num_additional_bits` specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the `gci_alignment_zero_bit` syntax element (if present). In bitstreams conforming to this version of the document, the value of `gci_num_additional_bits` should be equal to 0 or... 6 . Other than 0 and 6 The value of gci_num_additional_bits is reserved by ITU-T | ISO / IEC for future use. 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 for this version should allow... Other than 0 and 6 The value of gci_num_additional_bits appears in the syntax and should be in gci_num_additional_bits Other than 0 and 6 The values ​​of all gci_reserved_zero_bit[i] syntax elements are ignored. When gci_present_flag equals 1 and gci_num_additional_bits, etc. At 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 were inferred as It equals 1.

[0129] As a supplement or alternative to the above embodiments, the misleading syntax element gci_reserved_zero_bit[i] can be renamed to gci_reserved_bit[i]. For example, the modified syntax and semantics can be as follows.

[0130]

[0131] gci_reserved_bit[i] It can have any value. Its existence and value will 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.

[0132] In another 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.

[0133]

[0134] gci_reserved_bit[i] It can have any value. Its existence and value will 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.

[0135] General constraint mark

[0136] gci_all_rap_pictures_constraint_flag

[0137] The `gci_all_rap_pictures_constraint_flag` flag is used to indicate that images should be restricted to IRAP or GDR images.

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

[0139]

[0140] 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 from VCL NAL units. Different VCL categories can be used at a high level to indicate dependencies. For example, NAL units from TRAIL_NUT (0) to RSV_VCL_6 (6) can typically use inter-frame prediction tools, depending on whether a previously decoded (reference) image is available. Images encoded using inter-frame prediction tools are more compressed than images compressed using only intra-frame prediction tools. However, this decoding dependency can be problematic when a reference image is unavailable.

[0141] Intra-Random Access Point (IRAP) pictures are coded pictures in which all VCL NAL units have the same `nal_unit_type` value, falling within the range of `IDR_W_RADL` to `CRA_NUT` (inclusive). IRAP pictures can be either CRA or IDR pictures. During decoding, IRAP pictures do not use inter-frame prediction from the same-layer reference picture. The first picture in the bitstream arranged in decoding order is either an IRAP picture or a Progressive Decode Refresh (GDR) picture. For a single-layer bitstream, as long as the necessary parameter set is available when a reference is needed, the IRAP picture and all subsequent non-RASL pictures in the CLVS arranged in decoding order can be correctly decoded without performing decoding on any pictures whose decoding order precedes the IRAP picture. The `pps_mixed_nalu_types_in_pic_flag` value for IRAP pictures is equal to 0. When an image has pps_mixed_nalu_types_in_pic_flag equal to 0, and any slice of that image has nal_unit_type in the range IDR_W_RADL to CRA_NUT (inclusive), all other slices of that image have the same nal_unit_type value, and the image is known to be an IRAP image after the first slice is received.

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

[0143] The VVC standard introduced Progressive Decode 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 can freely use inter-frame prediction. By segmenting the image in this way, the "clean" portions can still be correctly decoded in the event of errors such as packet loss. In successive GDR images, the spatial positions of the "clean" portions are rotated, thus allowing the entire image to eventually be recovered from errors.

[0144] For video applications where playback flexibility and streaming recovery capabilities are critical, restricting all images to IRAP or GDR images may be desirable. In VVCv2, the GCI flag `gci_all_rap_pictures_constraint_flag` was introduced to indicate this constraint at a high level. `gci_all_rap_pictures_constraint_flag` equal to 1 specifies that all images in OlsInScope are either GDR images with `ph_recovery_poc_cnt` equal to 0, or IRAP images. `gci_all_rap_pictures_constraint_flag` equal to 0 does not impose this constraint. When `gci_all_rap_pictures_constraint_flag` does not exist, its value is inferred to be 0.

[0145] When the profile_tier_level() syntax structure is included in a VPS, OlsInScope is one or more output tier sets (OLS) defined by the VPS. When the profile_tier_level() syntax structure is included in an SPS, OlsInScope is only the OLS that includes the lowest tier among the tiers referencing the SPS, and that lowest tier is an independent tier.

[0146] gci_no_extended_precision_processing_constraint_flag

[0147] The GCI flag `gci_no_extended_precision_processing_constraint_flag` indicates at a higher level whether VVCv2 tools with extended transform precision are subject to constraints. In the VVC standard, pixels in a video signal are represented by integer values. All computations and processing described in the VVC standard are represented through integer operations. This constraint is important for complexity and interoperability. First, the computational cost of performing integer operations (addition, multiplication, division) is generally lower than the equivalent floating-point operations. Second, floating-point operations are not deterministically standardized. Floating-point addition and multiplication are not necessarily commutative (e.g., (a+b)+c is not necessarily equal to a+(b+c)), and the values ​​of floating-point operations on different platforms are not guaranteed to be exactly the same.

[0148] 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 inter-frame prediction or intra-frame prediction tools. The difference between the original video sample and the predicted sample is called the residual. In the worst case, the bit depth of these residual coefficients might increase (e.g., BitDepth + 1); however, in the VVC standard, these residual coefficients are clipped to maintain the bit depth BitDepth. In practice, the worst-case scenario will not occur because a real encoder will not choose a prediction tool that produces a residual with a larger amplitude than the original video signal.

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

[0150]

[0151] in, An N-dimensional space representing real numbers. The VVC standard uses an integer approximation of DCT (i.e., Unlike prediction, the bit depth is typically extended 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 are design decisions that balance hardware complexity and coding performance.

[0152] In VVCvl, the bit depth of the transform coefficients is 16. That is, the range of values ​​for each transform coefficient is... Multiplying video samples by integerized DCT coefficients typically produces intermediate transform coefficients with a bit depth greater than 16. To generate transform coefficients with the desired bit depth, these intermediate transform coefficients are shifted to the right. This operation is inherently lossy.

[0153] In VVCv2, extended transform precision can be 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 accurate bit depth of the 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 binarizing 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 is not used for binarizing the `abs_remaining[]` and `dec_abs_level[]` syntax elements. When it is not present, the value of `sps_extended_precision_flag` is inferred to be 0. The derivation of the variable `Log2TransformRange` is as follows.

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

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

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

[0157] A `gci_no_extended_precision_processing_constraint_flag` value of 1 specifies that `sps_extended_precision_flag` should be 0 for all images within the OlsInScope. In this document, OlsInScope is also referred to as the "Output Layer Set within the Scope". When the `profile_tier_level()` syntax is included in a VPS, OlsInScope is one or more Output Layer Sets (OLS) defined by the VPS. When the `profile_tier_level()` syntax is included in an SPS, OlsInScope is an OLS that includes only the lowest layer among the layers referencing the SPS, and this lowest layer is an independent layer. A `gci_no_extended_precision_processing_constraint_flag` value of 0 does not impose this constraint. When `gci_no_extended_precision_processing_constraint_flag` does not exist, its value is inferred to be 0.

[0158] gci_no_ts_residual_coding_rice_constraint_flag

[0159] The GCI flag `gci_no_ts_residual_coding_rice_constraint_flag` indicates whether the VVCv2 tool, which transmits explicit Rice parameters, is constrained at a high level. During entropy coding, the entropy coding process encodes each syntax element value into a bit sequence and inserts it into the bitstream.

[0160] The two entropy coding processes used in VVC are Content 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 quite complex. To encode non-binary syntax elements (e.g., syntax elements with values ​​beyond 0 or 1) using CABAC, the syntax elements must first be binarized into a set of "containers." The table below provides two examples of binarization. The second example shows that for variable-length binarization, some values ​​of the syntax elements may not exist within a container.

[0161] Table: Fixed-Length Binarization Example

[0162]

[0163] Table: Examples of Variable-Length Binarization

[0164]

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

[0166] Syntax elements with a large value range are not suitable for simple CABAC encoding because their binarization is lengthy, resulting in excessive overhead in content storage and updates. For example, residual coefficient values ​​are not easily encoded using simple CABAC. Compared to CABAC, Ricean encoding can model the probability distribution of non-binary values ​​with compact parameters.

[0167] 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 positive integers. Rice coding is a subset of Columbus coding, where the entropy encoder is controlled by a single Rice parameter R, which is a non-negative integer. Rice coding with the Rice parameter R is equivalent to Columbus coding, where... .

[0168] The following describes how to binarize a non-negative integer value x into a Ricean code with Ricean parameters R. The formulas for calculating the quotient q and remainder r are:

[0169]

[0170]

[0171] The Rice code for x is a combination of prefix and suffix codes. The prefix code is determined by the unary code for q. For example, the prefix code used in VVC is a truncated unary code:

[0172]

[0173] Because the unary code is truncated, the Rice code is also truncated, meaning that the range of values ​​that x can encode is limited. In VVC, truncated Rice codes are applied to ranges of... The x-value.

[0174] Suffix encoding is a binarization of a fixed-length code of length R bits, denoted as r. For example, if R=3, the suffix code is:

[0175]

[0176] In VVC, residual coefficients are encoded using a combination of CABAC, Rice coding, and exponential Golomb coding. A small number of syntax element flags are defined, sufficient to transmit small residual values. For example, `sig_coeff_flag` indicates whether the residual magnitude is zero. If `sig_coeff_flag` is 1, more flags (usually named `abs_level_gtx_flag`) can be transmitted, indicating whether the residual magnitude is greater than 1, 2, 3, etc. These flags are content-encoded by the CABAC engine. Since most residual coefficients have small magnitudes, CABAC can efficiently encode most residuals using relatively few containers.

[0177] Any remaining magnitude of residual coefficients that cannot be transmitted via the residual coefficient flag is transmitted in the syntax element `abs_remainder`. If the value of `abs_remainder` is less than or equal to... If the syntax element is greater than 0, then the entire syntax element is transmitted using Rice encoding of abs_remainder. Then the syntax element is passed Rice code and The associated transmission of the exponential Golomb encoding. The exponential Golomb encoding process is not described here.

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

[0179]

[0180] Adaptive Rice parameter determination was designed for residual coefficients in "Regular Residual Coding" (RRC), which are residual coefficients obtained by performing a Discrete Cosine Transform (DCT). However, in VVCv1, it also applies to residual coefficients in "Transform Skip Residual Coding" (TSRC). In VVCv2, it was recognized that alternative mechanisms for Rice parameter determination might be advantageous for transform-skip coefficients.

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

[0182]

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

[0184] Whether the alternative mechanism is enabled is controlled by the SPS-level flag `sps_ts_residual_coding_rice_present_in_sh_flag`. If this flag is set to 0, alternative Rice parameter transmission is not enabled. The GCI flag `gci_no_ts_residual_coding_rice_constraint_flag` determines whether the VVCv2 tools that transmit explicit Rice parameter transmission at a higher level are constrained. `gci_no_ts_residual_coding_rice_constraint_flag` equal to 1 specifies that `sps_ts_residual_coding_rice_present_in_sh_flag` should be equal to 0 for all images in OlsInScope. If `gci_no_ts_residual_coding_rice_constraint_flag` is equal to 0, this constraint is not imposed. When `gci_no_ts_residual_coding_rice_constraint_flag` is absent, its value is inferred to be 0.

[0185] gci_no_rrc_rice_extension_constraint_flag

[0186] `gci_no_rrc_rice_extension_constraint_flag` specifies the `sps_rrc_rice_extension_flag` for all images in OlsInScope. A `gci_no_rrc_rice_extension_constraint_flag` value of 1 means that `sps_rrc_rice_extension_flag` for all images in OlsInScope should be equal to 0. A `gci_no_rrc_rice_extension_constraint_flag` value of 0 means that this constraint is not applied.

[0187] For high bit depth and high bit rate applications, there are many quantization levels at many locations in the RRC. For such applications, a larger Rice parameter will result in a reduced number of containers required to represent the remaining levels. The method of deriving the Rice parameter in VVCv1 may not be optimal for VVCv2 applications. Therefore, an alternative Rice parameter derivation can be used, which can be transmitted via `sps_rrc_rice_extension_flag`. `sps_rrc_rice_extension_flag` equal to 1 indicates that the alternative Rice parameter derivation is used for binarization of `abs_remaining[]` and `dec_abs_level[]`. `sps_rrc_rice_extension_flag` equal to 0 indicates that the alternative Rice parameter derivation is not used for binarization of `abs_remaining[]` and `dec_abs_level[]`. When it does not exist, the value of `sps_rrc_rice_extension_flag` is inferred to be equal to 0.

[0188] The following is an example of using sps_rrc_rice_extension_flag to determine Rice parameters in VVCv2. Given an array AbsLevel[x][y] of transform blocks with component indices cIdx and the top-left luminance position (x0, y0), derive the variable locSumAbs according to the following pseudocode procedure (the underlined part is the addition in VVCv2 compared to VVCvl).

[0189]

[0190]

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

[0192] Given the variable locSumAbs, first The Rice parameter cRiceParam is derived according to the specifications in Table 128. Then more New as follows :

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

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

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

[0196] Table 128 - cRiceParam Specification Based on locSumAbs

[0197]

[0198] As can be seen from equation (1526X3), compared with VVCvl, cRiceParam, which is used to binarize the remaining part of the absolute level in VVCv2, can be larger.

[0199] gci_no_persistent_rice_adaptation_constraint_flag

[0200] `gci_no_persistent_rice_adaptation_constraint_flag` transmits the constraint on the Rice parameter derivation, which is for binarization using the previous TU state. `gci_no_persistent_rice_adaptation_constraint_flag` equal to 1 specifies that `sps_persistent_rice_adaptation_enabled_flag` should be equal to 0 for all images in OlsInScope. `gci_no_persistent_rice_adaptation_constraint_flag` equal to 0 does not impose this constraint. When `gci_no_persistent_rice_adaptation_constraint_flag` does not exist, its value is deduced to be 0.

[0201] A value of 1 for `sps_persistent_rice_adaptation_enabled_flag` specifies that at the start of each TU, the Rice parameter derivation used for binarizing `abs_remainder[]` and `dec_abs_level[]` is initialized using the statistics accumulated from previous TUs. A value of 0 for `sps_persistent_rice_adaptation_enabled_flag` 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 inferred to be 0. The following is an example of using `sps_persistent_rice_adaptation_enabled_flag` to determine Rice parameters in VVCv2 (the underlined parts are additions in VVCv2 compared to VVCvl).

[0202] If the CTU is the first CTU in a slice or tile, then the array PredictorPaletteSize[chType] (chType = 0, 1) is initialized to 0, and the array StatCoeff[i] (i = 0...2) is initialized as follows, in accordance with the initialization procedure for the calling content variable specified in sub-clause 9.3.2.2:

[0203] StatCoeff[i] = sps_persistent_rice_adaptation_enabled_flag ? 2 * Floor(Log2(BitDepth) 10 ) : 0 (1513X3)

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

[0205] gci_no_reverse_last_sig_coeff_constraint_flag

[0206] A value of 1 for `gci_no_reverse_last_sig_coeff_constraint_flag` indicates that `sps_reverse_last_sig_coeff_enabled_flag` should be 0 for all images in OlsInScope. A value of 0 for `gci_no_reverse_last_sig_coeff_constraint_flag` disables this constraint. When `gci_no_reverse_last_sig_coeff_constraint_flag` is absent, its value is inferred to be 0.

[0207] In conventional Residual Coding (RRC), the position (x, y) of the final non-zero level in the TU is encoded by up to four syntax elements: last_sig_coeffx_x_prefix, last_sig_coeff_y_prefix, last_sig_coeff_x_suffix, and last_sig_coeff_y_suffix. This position is encoded using the difference between (x, y) and (0, 0) in the current TU in VVCvl. This is reasonable for VVCvl because there are many zero levels within a TU, and most non-zero levels are located in the top-left corner of the TU. However, this may not be the case for VVCv2 applications, where many non-zero levels are distributed throughout the TU. Therefore, it may be 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.

[0208] The value of sh_reverse_last_sig_coeff_flag being 1 specifies that for each transform block of the current slice, the value relative to ((Log2ZoTbWidth << 1)) is 1. 1, (Log2ZoTbHeight << 1) 1) Encode the coordinates of the final significance coefficient. `sh_reverse_last_sig_coeff_flag` equal to 0 specifies that for each transform block of the current slice, the coordinates of the final significance coefficient are encoded relative to (0, 0). If it does not exist, the value of `sh_reverse_last_sig_coeff_flag` is inferred to be equal to 0.

[0209]

[0210] VVCv2 slice header

[0211]

[0212] Figure 5 An example of a video decoding process 500 according to some embodiments of the present disclosure is described. One or more computing devices implement this by executing appropriate 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 are described. The computing device includes, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter-frame prediction module 224, and an intra-frame prediction module 226. For illustrative purposes, process 500 is described with reference to some examples depicted in the figures. However, other implementations are also possible.

[0213] In step 502, process 500 involves accessing the bitstream of a video signal, such as encoding video 202. In step 504, process 500 involves extracting the General Constraints Information (GCI) flag from the video bitstream. As described above, the binary flag `gci_present_flag` is used to indicate the presence of a GCI syntax element. `gci_present_flag` equal to 1 indicates the presence of a GCI syntax element in the `general_constraints_info()` syntax structure, and that the GCI syntax element is used to indicate constraints imposed on additional encoding tools. `gci_present_flag` equal to 0 indicates the absence of a GCI syntax element, and that 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 of the video, or the sequence parameter set of the video.

[0214] In step 506, process 500 involves determining, based on the value of the GCI flag, whether one or more general constraints are imposed on the video. If so (i.e., the GCI flag is 1), in step 508, process 500 involves extracting a value M from the video bitstream representing the number of additional bits contained in the video bitstream. These additional bits include flag bits that indicate, respectively, that each additional coding tool is constrained for the video.

[0215] In step 510, process 500 involves determining whether M is greater than 5. If so, in step 512, process 500 involves extracting six flag bits from the bitstream, each of which represents a flag indicating a respective constraint of one of the six additional encoding tools. These six flags include: the flag `gci_all_rap_pictures_constraint_flag`, which indicates that the video pictures are restricted to intra-frame random access point (IRAP) pictures or progressively decoded refreshed GDR pictures; the flag `gci_no_extended_precision_processing_constraint_flag`, which indicates whether to constrain extended transform precision; the flag `gci_no_ts_residual_coding_rice_constraint_flag`, which indicates whether to constrain explicit Rice parameter transmission; the flag `gci_no_rrc_rice_extension_constraint_flag`, which indicates alternative Rice parameter derivation for binarization of quantization residuals in the video; the flag `gci_no_persistent_rice_adaptation_constraint_flag`, which indicates whether to initialize Rice parameter derivation for binarization based on previous transform units; and the flag `gci_no_reverse_last_sig_coeff_constraint_flag`, which indicates whether to impose constraints on the pictures in OlsInScope when decoding the final non-zero level positions in the TU.

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

[0217] In step 514, process 500 involves decoding the remainder of the video bitstream into images according to constraints indicated by six flags for six additional coding tools. For example, if the flag `gci_all_rap_pictures_constraint_flag` is 1, the decoder can determine that all pictures in one or more output layer sets are either GDR pictures or IRAP pictures with `ph_recovery_poc_cnt` equal to 0, and decode the GDR or IRAP pictures in one or more output layer sets. If the flag `gci_no_extended_precision_processing_constraint_flag` is 1, the decoder can determine that extended transform precision is constrained and decode the video by setting `sps_extended_precision_flag` of the pictures in OlsInScope to 0 to avoid using extended dynamic range. If the flag `gci_no_ts_residual_coding_rice_constraint_flag` is 1, the decoder can determine that explicit Rice parameter transmission is constrained and decode the remainder of the video bitstream by disabling alternative Rice parameter transmission for the pictures in OlsInScope. If the flag `gci_no_rrc_rice_extension_constraint_flag` is 1, the decoder can determine that the alternative Rice parameter derivation used for quantization residual binarization of the video is constrained, and decodes the remainder of the video bitstream by disabling the transmission of alternative Rice parameters 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 used for binarization based on previous transform unit states is constrained, and decodes the remainder of the video bitstream without initializing the Rice parameters for images in OlsInScope based on previous transform unit states. If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder can determine that the sps_reverse_last_sig_coeff_enabled_flag of all images in OlsInScope is equal to 0, and that for each transform block of the current slice, the coordinates of the final saliency coefficients are encoded relative to the top left corner (0, 0); and decode the remaining part of the video bitstream by interpreting the decoded coordinates of the final saliency coefficients as relative to the top left corner (0, 0) of each transform block of the current slice.

[0218] If it is determined in step 510 that M is not greater than 5, then in step 518, process 500 involves extracting M bits from the bitstream and discarding them. In other words, video decoding will be performed independently of these M bits. In step 520, the decoder decodes the video without imposing constraints on the six additional encoding tools. If it is determined in step 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 relative to Figure 2 The above process performs decoding. The decoded video can then be output for display.

[0219] Figure 6 Another example of a video decoding process 600 according to some embodiments of the present disclosure is described. One or more computing devices implement this by executing appropriate 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 is depicted in the figure. The computing device includes, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter-frame prediction module 224, and an intra-frame prediction module 226. For illustrative purposes, process 600 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0220] In step 602, process 600 involves accessing the bitstream of a video signal, such as encoding video 202. In step 604, process 600 involves extracting the General Constraints Information (GCI) flag from the video bitstream. As described above, the binary flag `gci_present_flag` is used to indicate the presence of a GCI syntax element. `gci_present_flag` equal to 1 indicates the presence of a GCI syntax element in the `general_constraints_info()` syntax structure, and that the GCI syntax element is used to indicate constraints imposed on additional encoding tools. `gci_present_flag` equal to 0 indicates the absence of a GCI syntax element, and that 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 of the video, or the sequence parameter set of the video.

[0221] In step 606, process 600 involves determining, based on the value of the GCI flag, whether one or more general constraints have been imposed on the video. If so (i.e., the GCI flag is 1), in step 608, process 600 involves extracting a value M from the video bitstream representing the number of additional bits contained in the video bitstream. These additional bits include flag bits that indicate, respectively, that each additional coding tool is constrained for the video.

[0222] In step 610, process 600 involves determining whether M is greater than 6. If so, in step 612, process 600 involves extracting six flag bits from the bitstream, each of which represents a flag indicating a respective constraint of one of the six additional encoding tools. These six flags include: the flag `gci_all_rap_pictures_constraint_flag`, which indicates that the video pictures are restricted to intra-frame random access point (IRAP) pictures or progressively decoded refreshed GDR pictures; the flag `gci_no_extended_precision_processing_constraint_flag`, which indicates whether to constrain extended transform precision; the flag `gci_no_ts_residual_coding_rice_constraint_flag`, which indicates whether to constrain explicit Rice parameter transmission; the flag `gci_no_rrc_rice_extension_constraint_flag`, which indicates alternative Rice parameter derivation for binarization of quantization residuals in the video; the flag `gci_no_persistent_rice_adaptation_constraint_flag`, which indicates whether to initialize Rice parameter derivation for binarization based on previous transform units; and the flag `gci_no_reverse_last_sig_coeff_constraint_flag`, which indicates whether to impose constraints on the pictures in OlsInScope when decoding the final non-zero level positions in the TU.

[0223] In step 614, process 600 involves extracting M-6 bits from the bitstream after the six flag bits and discarding the extracted M-6 bits. In other words, video decoding will be performed independently of these M-6 bits. In step 616, process 600 involves decoding the remainder of the video bitstream into images according to the constraints indicated by the six flags for six additional encoding tools. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder can determine that all pictures in one or more output layer sets are GDR pictures or IRAP pictures with ph_recovery_poc_cnt equal to 0, and decode the GDR or IRAP pictures in 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 by setting the sps_extended_precision_flag of the pictures in OlsInScope to equal 0 to avoid using extended dynamic range. If the flag `gci_no_ts_residual_coding_rice_constraint_flag` is 1, the decoder can determine that explicit Rice parameter transmission is constrained and decodes the remainder of the video bitstream by disabling alternative Rice parameter transmission 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 quantization residual binarization of the video is constrained and decodes the remainder of the video bitstream by disabling alternative Rice parameter transmission for images in OlsInScope. If the flag `gci_no_persistent_rice_adaptation_constraint_flag` is 1, the decoder can determine that the initialization for Rice parameter derivation for binarization based on previous transform unit states is constrained and decodes the remainder of the video bitstream without initializing the Rice parameters for images in OlsInScope based on previous transform unit states.If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder can determine that the sps_reverse_last_sig_coeff_enabled_flag of all images in OlsInScope is equal to 0, and that for each transform block of the current slice, the coordinates of the final saliency coefficients are encoded relative to the top left corner (0, 0); and decode the remaining part of the video bitstream by interpreting the decoded coordinates of the final saliency coefficients as relative to the top left corner (0, 0) of each transform block of the current slice.

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

[0225] Figure 7 Another example of a video decoding process 700 according to some embodiments of the present disclosure is described. One or more computing devices implement this by executing appropriate 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 is depicted in the figure. The computing device includes, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter-frame prediction module 224, and an intra-frame prediction module 226. For illustrative purposes, process 700 is described with reference to some examples depicted in the figure. However, other implementations are also possible.

[0226] In step 702, process 700 involves accessing the bitstream of a video signal, such as encoding video 202. In step 704, process 700 involves extracting the General Constraints Information (GCI) flag from the video bitstream. As described above, the binary flag gci_present_flag is used to indicate the presence of a GCI syntax element. gci_present_flag equal to 1 indicates the presence of a GCI syntax element in the general_constraints_info() syntax structure, and the GCI syntax element is used to indicate constraints imposed on additional encoding tools. gci_present_flag equal to 0 indicates the absence of a GCI syntax element, 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 of the video, or the sequence parameter set of the video.

[0227] In step 706, process 700 involves determining, based on the value of the GCI flag, whether one or more general constraints are imposed on the video. If so (i.e., the GCI flag is 1), in step 708, process 700 involves extracting a value M from the video bitstream representing the number of additional bits contained in the video bitstream. These additional bits include flag bits that indicate, respectively, that each additional coding tool is constrained for the video.

[0228] In step 710, process 700 involves determining whether M is greater than 5. If not, in step 712, process 700 involves extracting M bits from the bitstream and discarding these M bits. In step 714, process 700 involves decoding the remaining portion of the video bitstream into an image independently of these M bits. If it is determined in step 710 that M is not greater than 5, in step 718, process 700 involves extracting the aforementioned six flag bits. If M is greater than 6, in step 719, process 700 involves extracting the remaining M-6 bits from the bitstream and discarding them. In other words, video decoding will be performed independently of these M-6 bits. In step 720, as described above, the decoder decodes the video based on the extracted six flag bits by imposing constraints on six additional encoding tools.

[0229] If it is determined in step 706 that the GCI flag indicates no general constraint is imposed on the video (i.e., the GCI flag is 0), then process 700 involves decoding the video into an image without general constraints. In some examples, according to relative to Figure 2 The above process performs decoding. The decoded video can then be output for display.

[0230] Example of a computing system for transmitting general constraint information

[0231] Any suitable computing system can be used to perform the operations described herein. For example, Figure 8It 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 one or more of a variety of processing devices. Such a processor may include, or be able to communicate with, a computer-readable medium storing instructions that, when executed by processor 812, cause the processor to perform the steps described herein.

[0232] Memory 814 may include any suitable non-transitory computer-readable medium. Computer-readable media 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, processor-configured storage, optical storage, magnetic tape or other magnetic storage, or any other medium from which a computer processor can read instructions. These instructions may include processor-specific instructions generated by a compiler and / or interpreter from code written in any suitable computer programming language, including C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, and ActionScript.

[0233] The computing device 800 may also include a bus 816. The bus 816 may be communicatively coupled to 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 illustrated computing device 800 has an input / output (“I / O”) interface 818 capable of receiving input from one or more input devices 820 or providing 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. This communicative 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 a pressure sensor for detecting pressure changes caused by a touch), mice, keyboards, or any other device that may be used to generate input events in response to physical actions by a user of the computing device. Non-limiting examples of output devices 822 include LCD screens, external displays, speakers, or any other device that may be used to display or otherwise present output generated by the computing device.

[0234] The computing device 800 can execute program code that configures the processor 812 to perform the above-mentioned functions. Figure 1-7 One or more steps. 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.

[0235] 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, and / or similar devices. The computing device 800 may transmit messages in the form of electronic or optical signals via the network interface device 824.

[0236] General considerations

[0237] This document sets forth numerous 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 without these details. In other instances, methods, apparatus, or systems known to those of ordinary skill in the art have not been described in detail so as not to obscure the claimed subject matter.

[0238] Unless otherwise specifically stated, it is understood that in this specification, discussions using terms such as “processing,” “computing,” “determining,” “identifying,” or similar terms refer to the operation or process of computing devices (such as one or more computers, or similar electronic computing devices) that operate or convert data represented as physical electronic or magnetic quantities in the memory, registers, or other information storage, transmission, or display devices of a computing platform.

[0239] The systems discussed herein are not limited to any particular hardware architecture or configuration. Computing devices can include any suitable arrangement of components that provides results conditioned on one or more inputs. Suitable computing devices include microprocessor-based multipurpose computer systems that access stored software that programs or configures the computing system from a general-purpose computing device to a dedicated computing device that implements one or more embodiments of this subject matter. In the software used to program or configure the computing device, any suitable programming language, scripting language, or other type of language or combination of languages ​​can be used to implement the teachings contained herein.

[0240] The method embodiments disclosed herein can be performed in the operation of such computing devices. The order of the steps presented in the examples above can be changed—for example, the steps can be reordered, combined, and / or broken down into sub-steps. Some steps or processes can be performed in parallel.

[0241] The terms "applies to" or "configured to" as used herein are open-ended and inclusive language and do not exclude devices that are suitable or configured to perform additional tasks or steps. Furthermore, the use of the term "based on" is also open-ended and inclusive, as a process, step, calculation, or other operation "based on" one or more stated conditions or values ​​may actually be based on other conditions or values ​​besides those stated. The headings, lists, and numbering included herein are for illustrative purposes only and are not intended to be limiting.

[0242] While the subject matter has been described in detail with respect to specific embodiments, it will be understood that those skilled in the art, upon understanding the foregoing, will readily make changes, modifications, and equivalents to these embodiments. Therefore, it should be understood that this disclosure is for illustrative purposes and not for limiting purposes, and does not exclude such changes, modifications, and / or additions to the subject matter that would be obvious to those skilled in the art.

Claims

1. A video decoding method, comprising: Decode an additional bit count M from the video bitstream, wherein the additional bit count M indicates the number of additional general constraint information (GCI) bits contained in the video bitstream, the additional bits including flag bits indicating the various additional decoding configurations to be constrained for the video, and wherein the expected value of the additional bit count is 0 or 6. In response to determining that the additional bit count M for decoding equals 6, six flag bits are decoded from the video bitstream, each flag indicating one of six additional decoding configurations to be constrained for the video; and The remaining portion of the video stream is decoded, at least in part, based on constraints for six additional decoding configurations indicated by the six flags.

2. The method according to claim 1, wherein, The six marks include: The first flag indicates that the images in the video are restricted to intra-frame random access point (IRAP) images or progressively decoded refreshed GDR images; The second indicator shows whether the accuracy of the extended transform is constrained. The third flag indicates whether explicit Rice parameter transmission is constrained; The fourth indicator indicates the alternative Rice parameter derivation used for the binarization of the quantization residuals of the video; The fifth flag indicates whether to initialize the Rice parameter derivation used for binarization based on the previous transformation unit; and The sixth flag indicates whether constraints are imposed on the images in the output layer set OlsInScope when decoding the final non-zero level position in the transform unit.

3. The method according to claim 2, wherein, Decoding the remaining portion of the video bitstream into an image, based at least in part on constraints provided by the six flags as indications of the six additional decoding configurations, includes one or more of the following steps: Based on the first flag being 1, it is determined that all images in one or more output layer sets are either GDR images or IRAP 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 video bitstream is decoded by setting the sps_extended_precision_flag of the images in the output layer set OlsInScope within the range to be equal to 0 so as not to use the extended dynamic range. Based on the third flag being 1, it is determined that explicit Rice parameter transmission is constrained, and the remaining portion of the video stream is decoded by disabling alternative Rice parameter transmission for images in the output layer set OlsInScope within the range. Based on the fourth flag being 1, it is determined that the alternative Rice parameter derivation for the quantization residual binarization of the video is constrained, and the remaining part of the video bitstream is decoded by disabling the transmission of alternative Rice parameters 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 for the derivation of the Rice parameters for binarization based on the previous transform unit state is constrained, and the remaining portion of the video bitstream is decoded without initializing the Rice parameters for the images in the output layer set OlsInScope within the range based on the previous transform unit state; or Based on the sixth flag being 1, the coordinates of the final saliency coefficients are determined to be encoded relative to the top left corner of each transform block of the slice, and the remaining part of the video bitstream is decoded by interpreting the decoded coordinates of the final saliency coefficients as relative to the top left corner of each transform block of the slice.

4. The method of claim 2, further comprising one or more of the following steps: Determine that the first flag does not exist in the bitstream, and infer that the value of the first flag is 0, indicating that no constraint has been imposed on the corresponding encoding tool; Determine that the second flag does not exist in the bitstream, and infer that the value of the second flag is 0, indicating that no constraint has been imposed on the corresponding encoding tool; It is determined that the third flag does not exist in the bitstream, and the value of the third flag is inferred to be 0, indicating that no constraint is imposed on the corresponding encoding tool; It is determined that the fourth flag does not exist in the bitstream, and the value of the fourth flag is inferred to be 0, indicating that no constraint is imposed on the corresponding encoding tool; It is determined that the fifth flag is absent in the bitstream, and the value of the fifth flag is inferred to be 0, indicating that no constraint has been imposed on the corresponding encoding tool; or It is determined that the sixth flag does not exist in the bitstream, and the value of the sixth flag is inferred to be 0, indicating that no constraint is imposed on the corresponding encoding tool.

5. The method according to claim 1, wherein, Before decoding the additional bit count M, the method further includes: Decode the General Constraint Information (GCI) flag from the video stream; and Based on the value of the GCI flag, it is determined that one or more general constraints have been applied to the video.

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

7. 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, implementing the video decoding method of any one of claims 1 to 6 to decode the bitstream to generate video.

8. A video encoding method, comprising: Determine the additional bit count M, wherein the additional bit count M indicates the number of additional general constraint information (GCI) bits, the additional bits including flag bits indicating the various additional decoding configurations to be constrained for the video, and wherein the expected value of the additional bit count is 0 or 6. The additional bit count M and the flag bits are encoded into the video bitstream; In response to determining that the additional bit count M equals 6, six flag bits are determined and encoded into the bitstream of the video, the six flags respectively indicating six additional decoding configurations to be constrained for the video.

9. The video encoding method according to claim 8, wherein, The six marks include: The first flag indicates that the images in the video are restricted to intra-frame random access point (IRAP) images or progressively decoded refreshed GDR images; The second indicator shows whether the accuracy of the extended transform is constrained. The third flag indicates whether explicit Rice parameter transmission is constrained; The fourth indicator indicates the alternative Rice parameter derivation used for the binarization of the quantization residuals of the video; The fifth flag indicates whether to initialize the Rice parameter derivation used for binarization based on the previous transformation unit; and The sixth flag indicates whether constraints are imposed on the images in the OlsInScope output layer set within the range when determining the position of the final non-zero level in the transform unit.

10. The video encoding method according to claim 9, further comprising: Based on the first flag being 1, it is determined that all images in one or more output layer sets are either GDR images or IRAP 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 encoded. Based on the second flag being 1, it is determined that the extended transform precision is constrained, and the remaining part of the video bitstream is encoded by setting the sps_extended_precision_flag of the images in the output layer set OlsInScope within the range to be equal to 0 so as not to use the extended dynamic range. Based on the third flag being 1, it is determined that explicit Rice parameter transmission is constrained, and the remaining portion of the video stream is encoded by disabling alternative Rice parameter transmission for images in the output layer set OlsInScope within the range. Based on the fourth flag being 1, it is determined that the alternative Rice parameter derivation for the quantization residual binarization of the video is constrained, and the remaining portion of the video bitstream is encoded by disabling the transmission of alternative Rice parameters 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 for the derivation of the Rice parameters for binarization based on the previous transform unit state is constrained, and the remaining portion of the video bitstream is encoded without initializing the Rice parameters for the images in the output layer set OlsInScope within the range based on the previous transform unit state; or Based on the sixth flag being 1, the coordinates of the final saliency coefficients are determined to be encoded relative to the top-left corner of each transform block of the slice, and the remaining portion of the video bitstream is encoded by interpreting the coordinates of the final saliency coefficients as relative to the top-left corner of each transform block of the slice.

11. The video encoding method according to claim 9, wherein, It also includes one or more of the following: In response to the lack of constraints imposed on the corresponding encoding tools, the first flag is not encoded into the bitstream; In response to the lack of constraints imposed on the corresponding encoding tools, the second flag is not encoded into the bitstream; In response to the lack of constraints imposed on the corresponding encoding tools, the third flag is not encoded into the bitstream; In response to the lack of constraints imposed on the corresponding encoding tools, the fourth flag is not encoded in the bitstream; In response to the lack of constraints imposed on the corresponding encoding tools, the fifth flag is not encoded into the bitstream; or In response to the lack of constraints imposed on the corresponding encoding tools, the sixth flag is not encoded into the bitstream.

12. The video encoding method according to claim 8, wherein, Before encoding the additional bit count M into the video bitstream, the video encoding method further includes: The GCI flag is encoded into the bitstream of the video by encoding a General Constraint Information (GCI) flag into the network data packets of the video, the video parameter set of the video, or the sequence parameter set of the video, wherein one or more general constraints are determined to be applied to the video based on the value of the GCI flag.

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, implementing the video encoding method of any one of claims 7 to 12 to generate the bitstream.

Images