Signaling Generic Constraint Information for Video Coding

By introducing the signal transmission and initialization method of general constraint information in video encoding, the incompatibility problem between video encoding standard versions and the ambiguity in the decoder implementation are solved, and the stability and compatibility of video encoding are achieved.

CN119110096BActive Publication Date: 2025-07-01GUANGDONG OPPO MOBILE TELECOMMUNICATIONS CORP LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411136088.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2022-01-13
Filing Date
2022-11-08
Publication Date
2025-07-01
Estimated Expiration
2042-11-08

AI Technical Summary

Technical Problem

The existing video encoding standards have incompatibility problems between versions, resulting in the general constraint information sent by the signal, resulting in the loss of video decoding. In the draft VVC version 2, the definition of the general constraint flag is incomplete, resulting in blur and inconsistency in the decoder implementation.

Method used

By introducing a signal transmission and initialization method for general constraint information for video encoding, it specifically includes extracting general constraint information flags, extracting additional bits from the code stream, determining the constraints applied to the video based on these bits, and inferring the general constraint flags in the VVC version 2 decoder to ensure compatibility with the VVC version 1 decoder.

Benefits of technology

Improve the stability of video encoding, ensure compatibility between different versions of video encoding standards, avoid the problem of decoding loss, and eliminate the ambiguity of general constraint information decoding behavior.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119110096B_ABST
    Figure CN119110096B_ABST
Patent Text Reader

Abstract

In some embodiments, a video decoder decodes a video according to a bitstream of the video. The video decoder accesses the bitstream of the video and extracts a General Constraint Information (GCI) flag from the bitstream of the video. The decoder determines to impose one or more general constraints on the video based on the value of the GCI flag, and extracts a value indicating the number of additional bits included in the bitstream of the video. The additional bits include flag bits that indicate corresponding additional coding tools to be constrained for the video. If the value is greater than 5, the decoder extracts 6 flags from the bitstream of the video, and these 6 flag bits indicate the corresponding constraints on 6 additional coding tools. The decoder decodes the bitstream of the video into images based on the constraints on the 6 additional coding tools indicated by these 6 flags.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of PCT International Patent Application PCT / US2022 / 079494 with a filing date of November 8, 2022, entering the Chinese national phase, with Chinese Patent Application No. 202280081236.5 and the invention title of "Signaling General Constraint Information for Video Coding".

[0002] Cross - reference to related applications

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

[0004] The present disclosure generally relates to video processing. Specifically, the present disclosure relates to signaling and initializing general constraint information for video coding. Background art

[0005] Widely available camera - enabled devices, such as smartphones, tablets, and computers, have made it easier than ever to capture video or images. However, even short videos can have a very large amount of data. Video coding techniques (including video encoding and decoding) enable video data to be compressed into a smaller size, thereby enabling various videos to be stored and transmitted. Video coding has been widely applied to various applications, such as digital television broadcasting, video transmission over the Internet and mobile networks, real - time applications (such as video chat, video conferencing), DVDs, Blu - ray discs, etc. To reduce the storage space for storing videos and / or the network bandwidth consumption for transmitting videos, it is desirable to improve the efficiency of video coding schemes. Summary of the invention

[0006] Some embodiments relate to signaling and initializing general constraint information for video coding. In one example, a method for decoding a video includes: extracting a General Constraint Information (GCI) flag from a bitstream of the video; based on the value of the GCI flag, determining to impose one or more general constraints on the video; in response to determining to impose one or more general constraints on the video, extracting a value indicating the number of additional bits included in the bitstream of the video, the additional bits including flag bits that indicate corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; in response to determining that the value is greater than 5, extracting 6 flag bits representing 6 corresponding flags, the 6 corresponding flags indicating the corresponding constraints on 6 additional coding tools, and decoding the remaining portion of the bitstream of the video into an image at least partially based on the constraints on the 6 additional coding tools indicated by the 6 flags.

[0007] In another example, a non-transitory computer-readable medium stores program code that can be executed by one or more processing devices to perform operations. The operations include: extracting a General Constraint Information (GCI) flag from a bitstream of the video; based on the value of the GCI flag, determining to impose one or more general constraints on the video; in response to determining to impose one or more general constraints on the video, extracting a value indicating the number of additional bits included in the bitstream of the video, the additional bits including flag bits that indicate corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; in response to determining that the value is greater than 5, extracting 6 flag bits representing 6 corresponding flags, the 6 corresponding flags indicating the corresponding constraints on 6 additional coding tools, and decoding the remaining portion of the bitstream of the video into an image at least partially based on the constraints on the 6 additional coding tools indicated by the 6 flags.

[0008] In yet another example, a system includes a processing device and a non-transitory computer-readable medium communicatively coupled to the processing device. The processing device is configured to execute the program code stored in the non-transitory computer-readable medium to perform operations. The operations include: extracting a General Constraint Information (GCI) flag from a bitstream of the video; based on the value of the GCI flag, determining to impose one or more general constraints on the video; in response to determining to impose one or more general constraints on the video, extracting a value indicating the number of additional bits included in the bitstream of the video, the additional bits including flag bits that indicate corresponding additional coding tools to be constrained for the video; determining that the value is greater than 5; in response to determining that the value is greater than 5, extracting 6 flag bits representing 6 corresponding flags, the 6 corresponding flags indicating the corresponding constraints on 6 additional coding tools, and decoding the remaining portion of the bitstream of the video into an image at least partially based on the constraints on the 6 additional coding tools indicated by the 6 flags.

[0009] The mention of these illustrative embodiments is not intended to limit or define the present disclosure, but rather to provide examples to aid in understanding the present disclosure. Additional embodiments are discussed in the detailed description and further description is provided in the detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0013] Figure 3 depicts an example of the coding tree unit partitioning of an image in a video according to some embodiments of the present disclosure.

[0014] Figure 4 depicts an example of the coding unit partitioning of a coding tree unit according to some embodiments of the present disclosure.

[0015] Figure 5 depicts an example of a process for decoding a video according to some embodiments of the present disclosure.

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

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

[0018] Figure 8 depicts an example of a computing system that can be used to implement some embodiments of the present disclosure. DETAILED DESCRIPTION

[0019] Provided are various embodiments for signaling and initializing common constraint information for video coding. As discussed above, an increasing amount of video data is being generated, stored, and transmitted. Advantageously, not only the efficiency of video coding techniques is improved, but also the stability of video coding is improved such that a video signal can be successfully decoded at the decoder side. Issues related to the stability of video decoding include incompatibility and inconsistency issues. As video coding techniques have evolved, newer video coding standards have been developed. One such video coding standard is the Versatile Video Coding standard version 1, which was jointly released by the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU), where ISO relates to "ISO / IEC 23090-3:2021 Information technology - Coding representation of immersive media - Part 3: Versatile Video Coding", and ITU relates to "ITU-T Recommendation H.266 (August 2020): Versatile Video Coding". In the present disclosure, the Versatile Video Coding standard version 1 may be referred to as "VVC version 1" or "VVCv1". VVC version 1 has been superseded by the Versatile Video Coding standard version 2, which will be jointly released by ISO and ITU, where ISO relates to "ISO / IEC 23090-3:2022 Information technology - Coding representation of immersive media - Part 3: Versatile Video Coding", and ITU relates to "ITU-T Recommendation H.266 (April 2022): Versatile Video Coding". In the present disclosure, the Versatile Video Coding standard version 2 may be referred to as "VVC version 2" or "VVCv2". To enable a video decoder compliant with a newer version of the video coding standard to successfully decode a video signal encoded using a previous version of the video coding standard, the video coding scheme should be designed to be backward compatible with the previous version of the coding standard. However, signaling the common constraint information used in the current draft of VVC version 2 has led to a video decoding out-of-step, which is a serious incompatibility issue between different versions of the video coding standard. Additionally, in the current draft of VVC version 2, a common constraint flag related to the common constraint information may not be defined, leading to ambiguity and inconsistency in decoder implementation in some cases. The various embodiments described herein address these issues by introducing a method for signaling and initializing the common constraint information for video coding, thereby improving the stability of video coding.

[0020] In the VVC standard, the General Constraints Information (GCI) syntax structure general_constraints_info() is used to indicate specific constraint attributes of the bitstream. The GCI contains a list of constraint flags and non-flag syntax elements. The binary flag gci_present_flag is used to specify whether the GCI syntax elements are present. In some embodiments, if a VVC version 2 bitstream signals the general constraints information (i.e., the value of gci_present_flag is 1), and the VVC version 2 general constraints information consists of N additional coding tools that can be constrained, then the syntax element gci_num_additional_bits corresponding to the N additional coding tools can be set only to the value 0 or N. If gci_num_additional_bits is set to 0, the general constraint flags for the N additional coding tools are not signaled. If gci_num_additional_bits is set to N, the next N bits in the bitstream are used to signal the general constraint flags for the N additional coding tools. In one example, N is set to 6.

[0021] In some examples, for a VVC version 2 bitstream, it is not allowed to set gci_num_additional_bits to a value other than 0 or N. However, a VVC version 2 decoder can still process general constraints information with gci_num_additional_bits set to a value other than 0 or N. For example, gci_num_additional_bits can be set to a value M greater than 0 and less than N, or to a value greater than N. If M is greater than 0 and less than N, after decoding the gci_num_additional_bits syntax element, the decoder extracts M bits from the bitstream and discards these M bits. If M is greater than N, after decoding the gci_num_additional_bits syntax element, the decoder extracts N bits from the bitstream and interprets these N bits as the general constraint flags for the N additional coding tools. Then, the decoder also extracts (M - N) bits from the bitstream and discards these (M - N) bits. In other examples, a VVC version 2 decoder does not need to process general constraints information with gci_num_additional_bits set to a value greater than 0 but less than N. A legal VVC version 2 bitstream can only set gci_num_reserved_bits to the value 0 or N. Bitstreams of future versions of VVC will not be allowed to set gci_num_additional_bits to a value between 0 and N.

[0022] In some embodiments, the general constraint information flag is initialized to address the ambiguity and inconsistency in decoder implementation discussed above. 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 coding tools associated with the general constraint information flag. In an example where the value of the flag being 0 indicates no constraint, when the general constraint information flag does not exist, it is inferred that the value of the flag equals 0.

[0023] The embodiments described in this disclosure provide a method by which the general constraint flag for additional coding tools in VVC version 2 can be signaled and inferred. Different from the prior art, the high-level syntax bitstream generated by the method described in this disclosure is compatible with a VVC version 1 decoder and can be decoded in a situation where the behavior of the VVC version 1 decoder and the behavior of the VVC version 2 decoder are out of sync. The inference rules described in this disclosure eliminate the ambiguity in the VVC version 2 decoding behavior of the VVC version 2 GCI syntax element. These techniques can be effective coding tools in various video coding standards.

[0024] Now referring to the accompanying drawings, Figure 1 is a block diagram showing an example of a video encoder 100 configured to implement the embodiments proposed herein. In Figure 1 the example shown, the video encoder 100 includes a partitioning module 112, a transform module 114, a quantization module 115, an inverse quantization module 118, an inverse transform module 119, a loop filter module 120, an intra prediction module 126, an inter prediction module 124, a motion estimation module 122, a decoded picture buffer 130, and an entropy coding module 116.

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

[0026] Generally, the first image of a video signal is an intra-coded image that is encoded only using intra prediction. In the intra prediction mode, only the encoded data from the same image is used to predict the blocks of the image. The intra-coded image can be decoded in the absence of information from other images. To perform intra prediction, Figure 1The illustrated video encoder 100 may employ an intra prediction module 126. The intra prediction module 126 is configured to generate an intra prediction block (prediction block 134) using the reconstructed samples in the reconstructed blocks 136 of adjacent blocks of the same image. Intra prediction is performed according to the intra prediction mode selected for the block. Then, the video encoder 100 calculates the difference between block 104 and the intra prediction block 134. This difference is referred to as the residual block 106.

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

[0028] The video encoder 100 may further use a quantization module 115 to quantize the transform coefficients to obtain quantized coefficients. Quantization involves dividing the samples by a quantization step size and then rounding, while inverse quantization involves multiplying the quantized value by the quantization step size. This quantization process is referred to as scalar quantization. Quantization is used to reduce the dynamic range of the (transformed or untransformed) video samples so that fewer bits are used to represent the video samples.

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

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

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

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

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

[0034] The motion estimation module 122 compares the current block 104 of the current image with the decoded reference image 108 for motion estimation. The decoded reference image 108 is stored in the decoded image buffer 130. The motion estimation module 122 selects the reference block that best matches the current block from the decoded reference image 108. 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 the motion vector (MV) and is provided to the inter-frame prediction module 124 together with the selected reference block. In some cases, multiple reference blocks are identified for the current block in multiple decoded reference images 108. Therefore, multiple motion vectors are generated, and the motion vectors are provided to the inter-frame prediction module 124 together with the corresponding reference blocks.

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

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

[0037] 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 configured to smooth the pixel transitions, thereby improving the video quality. The loop filter module 120 can be configured to implement one or more loop filters, such as a deblocking filter, a sample adaptive offset (SAO) filter, an adaptive loop filter (ALF), etc.

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

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

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

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

[0042] Now referring to Figure 3 , Figure 3 illustrates an example of the coding tree unit partitioning of an image in a video according to some embodiments of the present disclosure. As discussed above for Figure 1 and Figure 2 To encode an image of a video, the image is partitioned into blocks, such as CTUs (Coding Tree Units) 302 in VVC, as shown in Figure 3 For example, the CTU 302 can be a block of 128×128 pixels. The CTUs are processed in a certain order (e.g., the order shown in Figure 3 ). In some examples, each CTU 302 in the image can be partitioned into as shown in Figure 4One or more CUs (Coding Units) 402 as shown. The CU 402 can be further divided into prediction units or transform units (TUs) for prediction and transformation. According to the coding scheme, the CTU 302 can be divided into CUs 402 in different ways. For example, in VVC, the CU 402 can be rectangular or square and can be encoded without further division into prediction units or transform units. Each CU 402 can be as large as its root CTU 302 or can be a sub-partition of the root CTU 302 (as small as a 4×4 block). As Figure 4 shown, dividing the CTU 302 into CUs 402 in VVC can be a quadtree division, a binary tree division, or a ternary tree division. In Figure 4 it, the solid lines indicate quadtree division and the dashed lines indicate binary tree or ternary tree division.

[0043] Common constraint information in Versatile Video Coding version 1 (VVCv1)

[0044] In the first version of VVC, the General Constraint Information (GCI) syntax structure general_constraints_info() is used to indicate specific constraint attributes of the bitstream. The GCI contains a list of constraint flags and non-flag syntax elements. The binary flag gci_present_flag is used to specify whether the GCI syntax elements are present. If gci_present_flag is equal to 1, it specifies that the GCI syntax elements are present in the general_constraints_info() syntax structure. If gci_present_flag is equal to 0, it specifies that there is no GCI field in the general_constraints_info() syntax structure and the general_constraint_info() syntax structure does not impose any constraints.

[0045] The general constraint information can be signaled in multiple contexts in high-level syntax. For example, the GCI can be signaled in a network packet that only contains decoding capability information, such as a Network Abstraction Layer (NAL) packet that only carries decoding capability information and has its nal_unit_type set to 13 (i.e., DCI_NUT as the name of nal_unit_type). Alternatively, the GCI can be signaled in the Video Parameter Set or in the Sequence Parameter Set.

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

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

[0048]

[0049]

[0050]

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

[0052] In addition to the general constraint flag defined by VVCv1, additional general constraint flags can be provided via the syntax element gci_num_reserved_bits. gci_num_reserved_bits is an 8-bit unsigned integer whose value indicates the number of additional bits signaled in the general constraint syntax structure. In the VVC specification, these additional bits (referred to as the syntax element gci_reserved_zero_bit[i]) are extracted from and discarded from the bitstream. Such a provision enables VVCv1 decoders to be at least forward-compatible with the high-level syntax portion of bitstreams generated by subsequent versions of VVC.

[0053] Common constraint information in Versatile Video Coding version 2 (VVCv2)

[0054] In the current draft of VVC Version 2 (“VVC Operational Range Extension (Draft 5)”, a document released by the Joint Video Team of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29, JVET-X2005), it is proposed that multiple additional coding tools be constrained by common constraint flags. It is proposed to rename the 8-bit field called gc_num_reserved_bits in VVC v1 to gci_num_additional_bits. The adjusted syntax of the proposed VVC v2 is as follows:

[0055]

[0056] There are a total of 6 additional common constraint flags: gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_rrs_rice_extension_constraint_flag, gci_no_persistent_rice_adaptation_constraint_flag, and gci_no_reverse_last_sig_coeff_constraint_flag. The interpretation (“semantics”) of the proposed gci_num_additional_bits syntax element is as follows:

[0057] gci_num_additional_bits specifies the number of additional GCI bits in the common constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. Values of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document, a decoder conforming to this version of this document shall allow values of gci_num_additional_bits greater than 1 to appear in the syntax and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 1.

[0058] It is recommended that if the VVCv2 bitstream signals general constraint information, then if the 6 VVCv2 general constraint flags are not signaled, the syntax element gci_num_additional_bits shall be set to 0, and if the 6 VVCv2 general constraint flags are signaled, gci_num_additional_bits shall be set to 1.

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

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

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

[0062] If the high-level syntax is successfully decoded, the video decoder can determine whether the current bitstream can be decoded. If not, the decoder can normally terminate the decoding process. On the contrary, an out-of-step in the high-level syntax decoding process means that the information provided in the high-level syntax may not be correctly decoded. In the worst case, the decoder may decode completely wrong syntax element values after an out-of-step event, which can lead to incorrect parameter settings and subsequent incorrect decoding of the low-level syntax, resulting in decoding failure.

[0063] In addition, in the VVC v2 decoder, when signaling general constraint information, the gci_num_additional_bits syntax element is decoded from the bitstream into an 8-bit unsigned integer. If gci_num_additional_bits is decoded to a value of 0, no further general constraint flags are signaled. In this case, no inferred value is assigned to the additional general constraint flags, and the value of the additional general constraint flags is undefined. Therefore, the behavior of whether the coding tools related to the additional general constraint flags should be constrained or not is ambiguous, which can lead to inconsistent decoder implementations.

[0064] In the VVC specification, the name of the syntax element gci_reserved_zero_bit[i] is misleading, suggesting that the value of such a syntax element must be 0. Generally, when a reserved syntax element is written into the bitstream by the encoder as a placeholder, the default value is embedded in the name of the reserved syntax element. However, the design of the general constraint syntax structure means that gci_reserved_zero_bit[i] is never written by the encoder. The gci_reserved_zero_bit[i] is only used when a particular version of the VVC decoder reads a higher version of the VVC bitstream. In this case, it is not guaranteed that the value of gci_reserved_zero_bit[i] is 0. In the following, multiple solutions are proposed to solve the above problems.

[0065] Signaling of common constraint information

[0066] In one embodiment of signaling general constraint information to address the out-of-sync issues discussed above, if the VVCv2 bitstream signals general constraint information (i.e., the value of gci_present_flag is 1), and the VVCv2 general constraint information consists of N additional coding tools that can be constrained, then the syntax element gci_num_additional_bits can only be set to a value of 0 or N. If gci_num_additional_bits is set to 0, the general constraint flags for the N additional coding tools are not signaled. If gci_num_additional_bits is set to N, the next N bits in the bitstream are used to signal the general constraint flags for the N additional coding tools. In one example, N is set to 6.

[0067] For a VVCv2 bitstream, it is not allowed to set gci_num_additional_bits to a value other than 0 or N. However, the VVCv2 decoder can still process general constraint information with gci_num_additional_bits set to a value other than 0 or N. For example, gci_num_additional_bits can be set to a value greater than 0 and less than N, or to a value greater than N. The decoded value of gci_num_additional_bits is denoted as M. Then, if M is greater than 0 but less than N (i.e., 0 < M < N), after decoding the gci_num_additional_bits syntax element, the decoder extracts M bits from the bitstream as the gci_reserved_zero_bit[i] syntax element and discards these M bits. If M is greater than N (N < M), after decoding the gci_num_additional_bits syntax element, the decoder extracts N bits from the bitstream and interprets these N bits as the general constraint flags for the N additional coding tools. Then, the decoder also extracts (M - N) bits from the bitstream as the gci_reserved_zero_bit[i] syntax element and discards these (M - N) bits.

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

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

[0070] Table 1

[0071]

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

[0073] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure except for the gci_alignment_zero_bit syntax element (when present). In the bitstream conforming to this version of this document, the value of gci_num_additional_bits should be equal to 0 or 1 6 . The Except for 0 or 6 value of gci_num_additional_bits is reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document 6 , the decoder conforming to this version of this document should allow the value of gci_num_additional_bits to appear in the syntax and should ignore the values of all gci_reserved_zero_bit[i] syntax elements when Except for 0 or 6 gci_num_additional_bits Except for 0 or 6 is present.

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

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

[0076] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure except for the gci_alignment_zero_bit syntax element (when it exists). In the bitstream conforming to this version of this document, the value of gci_num_additional_bits should be equal to 0 or 1 6 . Values of gci_num_additional_bits greater than 1 6 are reserved for future use by ITU-T|ISO / IEC. Although in this version of this document it is required that the value of gci_num_additional_bits be equal to 0 or 1 6 , the decoder conforming to this version of this document should allow values of gci_num_additional_bits greater than 1 6 to appear 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 6 .

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

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

[0079]

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

[0081]

[0082]

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

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

[0085] gci_num_additional_bits specifies the number of additional GCI bits in the common constraint information syntax structure, except for the gci_alignment_ zero_bit syntax element (when present). In a bitstream compliant with this version of this document , the value of gci_num_additional_bits shall be in the range of 0 to 6, inclusive of the endpoints. Values of gci_num_ additional_bits greater than 6 are reserved for future use by ITU-T|ISO / IEC. Although in this version of this document the value of gci_num_additional_bits is required to be in the range of 0 to 6, inclusive of the endpoints, a decoder compliant with this version of this document shall allow values of gci_num_additional_bits greater than 6 to appear in the syntax and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 6.

[0086] In this embodiment, depending on the value of gci_num_additional_bits, some or all of the additional common constraint flags may not be signaled. In one arrangement of this embodiment, when the VVC v2 bitstream signals common constraint information (i.e., if the value of gci_present_flag is 1), no constraints are imposed on the coding tools corresponding to the additional common constraint flags that are not signaled. This behavior can be expressed by modifying the semantics of gci_num_additional_bits as follows:

[0087] gci_num_additional_bits specifies the number of additional GCI bits in the common constraint information syntax structure, except for the gci_alignment_ zero_bit syntax element (when present). In a bitstream compliant with this version of this document , the value of gci_num_additional_bits shall be in the range of 0 to 6, inclusive of the endpoints. Values of gci_num_ additional_bits greater than 6 are reserved for future use by ITU-T|ISO / IEC. Although in this version of this document the value of gci_num_additional_bits is required to be in the range of 0 to 6, inclusive of the endpoints, a decoder compliant with this version of this document shall allow values of gci_num_additional_bits greater than 6 to appear in the syntax and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 6. Additionally, when gci_present_flag is equal to 1, no constraints are imposed on coding tools for which there is no corresponding constraint flag in the syntax of general_constraints_info(). gci_num_additional_bits specifies the number of additional GCI bits in the common constraint information syntax structure, except for the gci_alignment_

[0088] In another arrangement of this embodiment, when the VVC v2 bitstream signals common constraint information (i.e., if the value of gci_present_flag is 1) and the additional common constraint flags are not signaled, the corresponding tools are constrained. This behavior can be expressed by modifying the semantics of the additional common constraint flags as follows:

[0089] ​ The number of additional GCI bits beyond the zero_bit syntax element (when present). In the bitstream conforming to this version of this document the value of gci_num_additional_bits shall be in the range of 0 to 6 inclusive of the endpoints. Values of gci_num_ additional_bits greater than 6 are reserved for future use by ITU-T|ISO / IEC. Although in this version of this document the value of gci_num_additional_bits is required to be in the range of 0 to 6 inclusive of the endpoints, a decoder conforming to this version of this document shall allow values of gci_num_additional_bits greater than 6 to appear in the syntax and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 6.

[0090] If gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are IRAP pictures or GDR pictures with ph_recovery_poc_cnt equal to 0. If gci_all_rap_pictures_constraint_flag is equal to 0, no such constraint is imposed. When gci_present_flag is equal to 1 and gci_ all_rap_pictures_constraint_flag is not present, infer that the value of gci_all_rap_pictures_constraint_flag is equal to 1.

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

[0092] If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it is specified that sps_ts_residual_coding_rice_present_in_sh_flag for all pictures in OlsInScope should be equal to 0. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, such a constraint is not imposed. When gci_present_ flag is equal to 1 and gci_no_ts_residual_coding_rice_constraint_flag is not present, infer that gci_no_ ts_residual_coding_rice_constraint_flag has a value equal to 1.

[0093] If gci_no_rrc_rice_extension_constraint_flag is equal to 1, it is specified that sps_rrc_rice_extension_flag for all pictures in OlsInScope should be equal to 0. If gci_no_rrc_rice_extension_constraint_flag is equal to 0, such a constraint is not imposed. When gci_present_flag is equal to 1 and gci_no_ rrc_rice_extension_constraint_flag is not present, infer that the value of gci_no_rrc_rice_extension_ constraint_flag is equal to 1.

[0094] If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it is specified that sps_persistent_rice_adaptation_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, such a constraint is not imposed. When gci_ present_flag is equal to 1 and gci_no_persistent_rice_adaptation_constraint_flag is not present, infer that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 1.

[0095] If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it is specified that the sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, such a constraint is not imposed. When gci_present_flag is equal to 1 and there is no gci_no_reverse_last_sig_coeff_constraint_flag, it is inferred that the value of gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1.

[0096] Initialization of General Constraint Information Flag

[0097] An embodiment of initializing general constraint information flags is described to address the ambiguity and inconsistency in the decoder implementation discussed above. In this embodiment, when gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, general_constraints_info() does not impose constraints on the coding tools related to the following: gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag.

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

[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 (when present). In a bitstream compliant with this version of the document, the value of gci_num_additional_bits shall be equal to 0 or 1. Values of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of the document, a decoder compliant with this version of the document shall allow values of gci_num_additional_bits greater than 1 to appear in the syntax and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 1. When gci_present_flag is equal to 1 and gci_num_additional_ When bits is equal to 0, general_constraints_info() does not impose any constraints on the coding tools related to the following: gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_ processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_ constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag.

[0100] As another example, a possible change in the semantics of gci_num_additional_bits is shown below, based on the current version 2 of the VVC specification.

[0101] gci_num_additional_bits specifies the number of additional GCI bits in the General Constraint Information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream compliant with this version of the document, the value of gci_num_additional_bits shall be equal to 0 or 1 6 。The value of gci_num_additional_bits Except for 0 or 6 is reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of the document 6 , a decoder compliant with this version of the document shall allow the value of gci_num_additional_bits Except for 0 or 6 to appear in the syntax and shall Except for 0 or 6 ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bitsWhen gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, general_ constraints_info() does not impose any constraints on the coding tools related to the following: gci_all_rap_ pictures_constraint_flag, gci_no_extended_precision_processing_constraint_ flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_ coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_ persistent_rice_adaptation_constraint_flag.

[0102] In the current version of the VVC version 2 specification, the semantics of gci_num_additional_bits are used only when gci_present_flag is equal to 1. The scenarios where gci_present_flag is equal to 0 are addressed in different sections of the VVC version 2 specification. Therefore, the "when gci_present_flag is equal to 1" in the semantics of gci_num_additional_bits is automatically satisfied. In addition, since the VVC version 2 specification does not allow gci_num_additional_bits to take values between 1 and 5, "gci_num_additional_bits is equal to 0" is equivalent to "gci_num_additional_bits is less than or equal to 5" or "there is no 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". Therefore, the above change in the semantics of gci_num_additional_bits is equivalent to the following:

[0103] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1 6 . The Except for 0 or 6 The values are reserved for future use by ITU-T | ISO / IEC. Although in this version of the document the value of gci_num_additional_bits is required to be equal to 0 or 1 6 , a decoder compliant with this version of the document shall allow the value of gci_num_additional_bits to appear in the syntax Except for 0 or 6 and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits Except for 0 or 6 is present. 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_ When constraint_flag and gci_no_persistent_rice_adaptation_constraint_flag exist, general_ constraints_info() does not impose any constraints on the coding tools related to the following: gci_all_rap_ pictures_constraint_flag, gci_no_extended_precision_processing_constraint_ flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_ coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_ persistent_rice_adaptation_constraint_flag .

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

[0105] If gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are IRAP pictures or GDR pictures with ph_recovery_poc_cnt equal to 0. If gci_all_rap_pictures_constraint_flag is equal to 0, no such constraint is imposed. When it does not exist, infer that the value of gci_all_rap_pictures_ constraint_flag is equal to 0.

[0106] If gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that sps_extended_precision_flag for all pictures in OlsInScope should be equal to 0. If gci_no_extended_precision_processing_constraint_flag is equal to 0, no such constraint is imposed. When it does not exist, infer that the value of gci_no_extended_precision_processing_constraint_flag is equal to 0.

[0107] If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it specifies that sps_ts_residual_coding_rice_present_in_sh_flag for all pictures in OlsInScope should be equal to 0. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, such a constraint is not imposed. When it does not exist, infer that the value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0.

[0108] If gci_no_rrc_rice_extension_constraint_flag is equal to 1, it specifies that sps_rrc_rice_extension_flag for all pictures in OlsInScope should be equal to 0. If gci_no_rrc_rice_extension_constraint_flag is equal to 0, such a constraint is not imposed. When it does not exist, infer that the value of gci_no_rrc_rice_ extension_constraint_flag is equal to 0.

[0109] If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it specifies that sps_persistent_rice_adaptation_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, such a constraint is not imposed. When it does not exist infer that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 0.

[0110] If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, such a constraint is not imposed. When it does not exist, infer that gci_no_ reverse_last_sig_coeff_constraint_flag is equal to 0.

[0111] In another example, the semantics of the additional common constraint flag are modified as follows ():

[0112] If gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are IRAP pictures or GDR pictures with ph_recovery_poc_cnt equal to 0. If gci_all_rap_pictures_constraint_flag is equal to 0, such a constraint is not imposed. When gci_all_rap_pictures_ constraint_flag does not exist, infer that the value of gci_all_rap_pictures_constraint_flag is equal to 0.

[0113] If gci_no_extended_precision_processing_constraint_flag is equal to 1, it specifies that the sps_extended_precision_flag of all pictures in OlsInScope should be equal to 0. If gci_no_extended_precision_processing_constraint_flag is equal to 0, such a constraint is not imposed. When gci_no_ extended_precision_processing_constraint_flag does not exist, infer that the value of gci_no_extended_ precision_processing_constraint_flag is equal to 0.

[0114] If gci_no_ts_residual_coding_rice_constraint_flag is equal to 1, it specifies that the sps_ts_residual_coding_rice_present_in_sh_flag of all pictures in OlsInScope should be equal to 0. If gci_no_ts_residual_coding_rice_constraint_flag is equal to 0, such a constraint is not imposed. When gci_no_ When ts_residual_coding_rice_constraint_flag is present, it is inferred that the value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0. When gci_no_ts_residual_coding_rice_constraint_flag is present, it is inferred that the value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0.

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

[0116] If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it specifies that the sps_persistent_rice_adaptation_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, such a constraint is not imposed. When gci_no_persistent_rice_adaptation_constraint_flag is not present, it is inferred that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 0. When gci_no_persistent_rice_adaptation_constraint_flag is not present, it is inferred that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 0. When gci_no_persistent_rice_adaptation_constraint_flag is not present, it is inferred that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 0.

[0117] If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that the sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, such a constraint is not imposed. When gci_no_reverse_last_sig_coeff_constraint_flag is not present, it is inferred that the value of gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0. When gci_no_reverse_last_sig_coeff_constraint_flag is not present, it is inferred that the value of gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0. is equal to 0. 。

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

[0119] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream compliant with this version of this document, the value of gci_num_additional_bits should be equal to 0 or 1 6 。gci_num_additional_bits greater than 1 6 The value is reserved for future use by ITU-T|ISO / IEC. Although in this version of this document it is required that the value of gci_num_additional_bits be equal to 0 or 1 6 However, a decoder compliant with this version of this document should allow the value of gci_num_additional_bits greater than 1 to appear 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 6 when 6 。 When gci_num_additional_bits is equal to 0, it is inferred that all constraint flags specified by the additional GCI bits are equal to 0.

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

[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 (when present). In a bitstream compliant with this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1 6 . Values of gci_num_additional_bits greater than 1 6 are reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document 6 , a decoder compliant with this version of this document shall allow values of gci_num_additional_bits greater than 1 to appear in the syntax, and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 1 6 6 . When it is not present, it is inferred that all constraint flags specified by the additional GCI bits are equal to 0. .

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

[0123]

[0124]

[0125] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream compliant with this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1 6 . Values of gci_num_additional_bits greater than 1 6 are reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document 6 , a decoder compliant with this version of this document shall allow values of gci_num_additional_bits greater than ​6 The value, and shall ignore the value of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 1 6 When gci_num_additional_bits is equal to 0, the additional_general_constraints_info() syntax structure imposes no constraints.

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

[0127] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In the bitstream conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1 6 。Values of gci_num_additional_bits greater than 1 6 are reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document 6 , a decoder conforming to this version of this document shall allow the presence of values of gci_num_additional_bits greater than 1 in the syntax, and shall ignore the value of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 1 6 6 When it is not present, the additional_general_ constraints_info() syntax structure imposes no constraints.

[0128] ​​​In another embodiment of initializing the general constraint information flag, when gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, the gci_all_rap_pictures_constraint_flag, gci_no_extended_precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_flag can always impose the corresponding constraints specified by the respective semantics of these flags. In other words, when the GCI flag is present and gci_num_additional_bits is equal to 0, it is inferred that these six GCI flags are equal to 1.

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

[0130] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream conforming to this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. Values of gci_num_additional_bits greater than 1 are reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document, a decoder conforming to this version of this document shall allow values of gci_num_additional_bits greater than 1 to appear in the syntax and shall ignore the values of all gci_reserved_zero_bit[i] syntax elements when gci_num_additional_bits is greater than 1. When gci_present_flag is equal to 1 and gci_num_additional_ bits is equal to 0, it is inferred that gci_all_rap_pictures_constraint_flag, gci_no_extended_ precision_processing_constraint_flag, gci_no_ts_residual_coding_rice_ constraint_flag, gci_no_reverse_last_sig_coeff_constraint_flag, gci_no_rrc_ rice_extension_constraint_flag, and gci_no_persistent_rice_adaptation_constraint_ flag are all equal to 1.

[0131] As another example, a possible change in the semantics of gci_num_additional_bits is as follows, which is based on the current VVC Version 2 specification being added.

[0132] gci_num_additional_bits specifies the number of additional GCI bits in the general constraint information syntax structure, excluding the gci_alignment_zero_bit syntax element (when present). In a bitstream compliant with this version of this document, the value of gci_num_additional_bits shall be equal to 0 or 1. 6 。The value of gci_num_additional_bits Except for 0 or 6 is reserved for future use by ITU-T|ISO / IEC. Although the value of gci_num_additional_bits is required to be equal to 0 or 1 in this version of this document, 6 a decoder compliant with this version of this document shall allow the value of gci_num_additional_bits to appear in the syntax and shall ignore the values of all Except for 0 or 6 when gci_num_additional_bits Except for 0 or 6 gci_reserved_zero_bit[i] syntax elements. When gci_present_flag is equal to 1 and gci_num_additional_bits is equal to 0, infer that gci_all_rap_ pictures_constraint_flag, gci_no_extended_precision_processing_constraint_ flag, gci_no_ts_residual_coding_rice_constraint_flag, gci_no_reverse_last_sig_ coeff_constraint_flag, gci_no_rrc_rice_extension_constraint_flag, and gci_no_ persistent_rice_adaptation_constraint_flag are all equal to 1.

[0133] In addition to or as an alternative to the embodiments discussed above, the misleading syntax element gci_reserved_zero_bit[i] may be renamed gci_reserved_bit[i]. For example, the modified syntax and semantics may be as follows:

[0134]

[0135] gci_reserved_bit[i] may have any value. Its presence and value do not affect the decoding process specified in this version of this specification. A decoder compliant with this version of this specification shall ignore all gci_reserved_bit[i] syntax element values.

[0136] In a further embodiment, the syntax element gci_reserved_zero_bit[i] is renamed gci_reserved_bit[i]. For example, the modified syntax and semantics can be as follows:

[0137]

[0138]

[0139] gci_reserved_bit[i] May have any value. Its presence and value do not affect the decoding process specified in this version of the specification. A decoder compliant with this version of the specification shall ignore all gci_reserved_bit[i] values of the syntax elements.

[0140] General constraint flag

[0141] gci_all_rap_pictures_constraint_flag

[0142] gci_all_rap_pictures_constraint_flag is used to indicate that the restriction on the picture is an IRAP or GDR picture.

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

[0144]

[0145]

[0146] 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. The pictures of a video sequence are decoded based on the VCL NAL units. Different types of VCL categories are useful at a higher level to indicate dependencies. For example, NAL units from TRAIL_NUT(0) to RSV_VCL_6(6) typically use inter prediction tools that rely on accessing previously decoded (reference) pictures. Pictures encoded using inter prediction tools can be compressed more efficiently compared to pictures compressed using only intra prediction tools. However, this decoding dependency introduces problems in cases where the reference pictures are not available.

[0147] An Intra Random Access Point (IRAP) picture is a coded picture in which all VCL NAL units have the same nal_unit_type value in the range from IDR_W_RADL to CRA_NUT (including the endpoints). An IRAP picture can be a CRA picture or an IDR picture. An IRAP picture does not use inter prediction from reference pictures in the same layer during its decoding process. The first picture in the bitstream in decoding order is an IRAP picture or a Gradual Decoding Refresh (GDR) picture. For a single-layer bitstream, if the necessary parameter sets are available when needed to reference them, IRAP pictures and all subsequent non-RASL pictures in decoding order in the CLVS can be decoded correctly without performing the decoding process for any picture before the IRAP picture in decoding order. The value of pps_mixed_nalu_types_in_pic_flag for an IRAP picture is equal to 0. When the pps_mixed_nalu_types_in_pic_flag of a picture is equal to 0 and the nal_unit_type of any slice of the picture is in the range from IDR_W_RADL to CRA_NUT (including the endpoints), all other slices of the picture have the same nal_unit_type value, and after receiving the first slice, it is known that the picture is an IRAP picture.

[0148] Therefore, IRAP pictures do not use inter prediction on the same layer. This limitation makes IRAP pictures a point of error recovery in streaming video applications or a point for seeking positions in video-on-demand playback applications. However, the compression efficiency of IRAP pictures is generally lower than that of non-IRAP pictures.

[0149] Gradual Decoding Refresh (GDR) pictures are introduced in the VVC standard as a trade-off between non-IRAP pictures and IRAP pictures. A GDR picture has some "clean" parts that do not use inter prediction, while the remaining parts of the picture can freely use inter prediction. By dividing the picture in this way, in the case of an error event such as packet loss, the "clean" parts will still be decoded correctly. In consecutive GDR pictures, the spatial positions of the "clean" parts are rotated so that the entire picture can eventually be recovered from the error.

[0150] For video applications that are important for streaming recovery of playback flexibility, it may be desirable to limit all pictures to IRAP pictures or GDR pictures. In VVC v2, the GCI flag gci_all_rap_pictures_constraint_flag is introduced, which enables such a limitation to be indicated elsewhere at a high level. When gci_all_rap_pictures_constraint_flag is equal to 1, it specifies that all pictures in OlsInScope are IRAP pictures or GDR pictures with ph_recovery_poc_cnt equal to 0. When gci_all_rap_pictures_constraint_flag is equal to 0, such a constraint is not imposed. When the gci_all_rap_pictures_constraint_flag does not exist, it is inferred that the value of gci_all_rap_pictures_constraint_flag is equal to 0.

[0151] When the profile_tier_level() syntax structure is included in the VPS, OlsInScope is the set of one or more output layers (OLSs) specified for the VPS. When the profile_tier_level() syntax structure is included in the SPS, OlsInScope is the OLS that includes only the lowest layer among the layers that reference the SPS, and the lowest layer is an independent layer.

[0152] gci_no_extended_precision_processing_constraint_flag

[0153] The GCI flag gci_no_extended_precision_processing_constraint_flag signals at a high level whether the VVC v2 tool for extended transform precision is constrained. In the VVC standard, the pixels of a video signal are represented by integer values. All calculations and processing described in the VVC standard are expressed through integer arithmetic. This limitation is important for reasons of complexity and interoperability. First, the computational cost of integer arithmetic (addition, multiplication, division) is generally lower compared to equivalent floating-point arithmetic. Second, floating-point arithmetic does not have deterministic normalization. Floating-point addition and multiplication are not necessarily commutative (e.g., (a + b) + c is not necessarily equal to a + (b + c)), and it cannot be guaranteed that the evaluation of floating-point arithmetic on different platforms is the same.

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

[0155] Then, the residual coefficients are typically analyzed by an integerized discrete cosine transform (DCT) to produce transform coefficients. The discrete cosine transform (DCT) is a linear invertible function that can be formally expressed as:

[0156]

[0157] where represents the N-dimensional real space. In the VVC standard, an integerized approximation of the DCT is used (i.e., ). Unlike prediction, since the accuracy of the transform affects the coding gain, a certain degree of bit depth extension is typically allowed during the transform stage. The bit depth of the approximated DCT coefficients and the resulting transform coefficients is a design decision that trades off hardware complexity and coding performance.

[0158] In VVC v1, the bit depth of the transform coefficients is 16. That is, each transform coefficient takes a value in the range [-2 15 , 2 15 -1]. The video samples are multiplied by the integerized DCT coefficients, typically producing intermediate transform coefficients with a bit depth greater than 16. To produce transform coefficients with the desired bit depth, the intermediate transform coefficients are right-shifted. Such an operation is inherently lossy.

[0159] In VVC v2, extended transform precision is enabled by setting the SPS flag sps_extended_precision_flag to 1. If extended transform precision is enabled, the bit depth of the transform coefficients is increased to (Log2TransformRange + 1). The bit depth of the exact transform coefficients depends on BitDepth. sps_extended_precision_flag being equal to 1 specifies the use of an extended dynamic range for the transform coefficients during scaling and transformation, and for the binarization of the abs_remaining[] and dec_abs_level[] syntax elements. sps_extended_precision_flag being equal to 0 specifies the non-use of an extended dynamic range during scaling and transformation, and the non-use of an extended dynamic range for the binarization of the abs_remaining[] and dec_abs_level[] syntax elements. When absent, the value of sps_extended_precision_flag is inferred to be equal to 0. The variable Log2TransformRange is derived as follows:

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

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

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

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

[0164] gci_no_ts_residual_coding_rice_constraint_flag

[0165] The GCI flag gci_no_ts_residual_coding_rice_constraint_flag signals whether the VVC v2 tool for explicit Rice parameter signaling at a higher level is constrained. In entropy coding, each syntax element value is encoded into a sequence of bits inserted into the bitstream through an entropy coding process.

[0166] The two entropy coding processes used in VVC are context-adaptive binary arithmetic coding (CABAC) and Rice coding. The CABAC engine is adaptive and can compress syntax elements to a bitrate very close to the theoretical Shannon limit. However, arithmetic coding is more complex. To encode non-binary syntax elements (such as syntax elements with a value range greater than 0 or 1) using CABAC, the syntax elements are first binaryized into a "bin" set. The following table gives two examples of binaryization. The second example shows that for variable-length binaryization, there may be no corresponding bin for some values of the syntax element.

[0167] Table: Examples of fixed-length binaryization

[0168]

[0169]

[0170] Table: Variable - length Binarization Example

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

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

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

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

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

[0176]

[0177] r = x modulo 2 R

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

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

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

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

[0182] r Fixed-length code 0 000 1 001 2 010 3 011 4 100 5 101 6 110 7 111

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

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

[0185] Although Rice coding is simpler than CABAC, under appropriate conditions, Rice coding can also be effectively compressed to a lower bitrate. For residual coefficients that are all small values, Rice coding with a small Rice parameter is more efficient. On the contrary, when some of the residual coefficient values are large, a larger Rice parameter may be more appropriate. To adapt to the statistics of the residual coefficients, the Rice parameter is adaptively determined according to the locSumAbs value, which is calculated based on the amplitudes of adjacent residual coefficients.

[0186] locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

[0187] Adaptive Rice parameter determination is designed for the residual coefficients in "Regular Residual Coding" (RRC), where the residual coefficients are obtained by performing a Discrete Cosine Transform (DCT). However, in VVC v1, adaptive Rice parameter determination is also applied to the residual coefficients in "Transform Skip Residual Coding" (TSRC). In VVC v2, it is realized that an alternative mechanism for determining the Rice parameter may be beneficial for transform skip coefficients.

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

[0189]

[0190] sh_ts_residual_coding_rice_idx_minusl plus 1 specifies the Rice parameter for the residual_ts_coding() syntax structure in the current slice. When absent, the value of sh_ts_residual_coding_rice_idx_minusl is inferred to be equal to 0.

[0191] Whether to enable the alternative mechanism is controlled by the SPS-level flag sps_ts_residual_coding_rice_present_in_sh_flag. If this flag is set to 0, the alternative Rice parameter signaling is not enabled. The GCI flag gci_no_ts_residual_coding_rice_constraint_flag signals whether the VVC v2 tool that explicitly signals the Rice parameter is constrained elsewhere. gci_no_ts_residual_coding_rice_constraint_flag being equal to 1 specifies that sps_ts_residual_coding_rice_present_in_sh_flag for all pictures in OlsInScope should be equal to 0. gci_no_ts_residual_coding_rice_constraint_flag being equal to 0 does not impose such a constraint. When gci_no_ts_residual_coding_rice_constraint_flag does not exist, it is inferred that the value of gci_no_ts_residual_coding_rice_constraint_flag is equal to 0.

[0192] gci_no_rrc_rice_extension_constraint_flag

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

[0194] For high-bit-depth and high-bitrate applications, there are many large quantization levels at many positions in the RRC. For such applications, a larger Rice parameter will result in fewer bins required to represent the remaining levels. The way the Rice parameter is derived in VVC v1 may not be optimal for VVC v2 applications. Therefore, an alternative Rice parameter derivation can be adopted, and the alternative Rice parameter derivation can be signaled by sps_rrc_rice_extension_flag. When sps_rrc_rice_extension_flag is equal to 1, it specifies the use of the alternative Rice parameter derivation for the binarization of abs_remaining[] and dec_abs_level[]. When sps_rrc_rice_extension_flag is equal to 0, it specifies not to use the alternative Rice parameter derivation for the binarization of abs_remaining[] and dec_abs_level[]. When it is not present, it is inferred that the value of sps_rrc_rice_extension_flag is equal to 0.

[0195] An example of determining the Rice parameter using sps_rrc_rice_extension_flag in VVC v2 is shown below. Given an array AbsLevel[x][y] of transform blocks with component index cIdx and top-left luminance position (x0, y0), the variable locSumAbs is derived as specified in the following pseudocode procedure (the underlines are the additions in VVC v2 over VVC v1):

[0196] locSumAbs = 0

[0197] if (xC < (1 << AbsL log2TbWidth) - 1) {

[0198] locSumAbs += AbsLevel[xC + 1][yC]

[0199] if (xC < (1 << AbsL log2TbWidth) - 2)

[0200] locSumAbs += AbsLevel[xC + 2][yC]

[0201] else

[0202] locSumAbs += HistValue

[0203] if (yC < (1 << AbsL log2TbHeight) - 1)

[0204] locSumAbs += AbsLevel[xC + 1][yC + 1] (1517)

[0205] else

[0206] locSumAbs += HistValue

[0207] } else

[0208] locSumAbs += 2 * HistValue

[0209] if(yC < (1 << AbsL log2TbHeight) - 1){

[0210] locSumAbs += AbsLevel[xC][yC + 1]

[0211] if(yC < (1 << AbsL log2TbHeight) - 2)

[0212] locSumAbs += AbsLevel[xC][yC + 2]

[0213] else

[0214] locSumAbs += HistValue

[0215] } else

[0216] locSumAbs += HistValue

[0217] The specifications of the lists Tx[] and Rx[] are as follows:

[0218] Tx[] = {32, 128, 512, 2048}(1523)

[0219] Rx[] = {0, 2, 4, 6, 8}(1524)

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

[0221] if (!sps_rrc_rice_extension_flag)

[0222] shiftVal = 0(1526X1)

[0223] else

[0224] shiftVal = (localSumAbs < Tx[0])? Rx[0] : ((localSumAbs < Tx[1])? Rx[1] :

[0225] ((localSumAbs < Tx[2])? Rx[2] : ((localSumAbs < Tx[3])? Rx[3] : Rx[4])))

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

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

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

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

[0230] When baseLevel is equal to 0, the variable ZeroPos[n] is derived as follows:

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

[0232] Table 128 - Description of cRiceParam based on locSumAbs

[0233] locSumAbs 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cRiceParam 0 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 locSumAbs 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 cRiceParam 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3

[0234] From (1526X3), we can see that compared with VVCv1, cRiceParam for binarizing the residue of the absolute level may be larger in VVCv2.

[0235] gci_no_persistent_rice_adaptation_constraint_flag

[0236] The gci_no_persistent_rice_adaptation_constraint_flag signals a constraint on the Rice parameter derivation that uses the previous TU state for binarization. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 1, it specifies that the sps_persistent_rice_adaptation_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_persistent_rice_adaptation_constraint_flag is equal to 0, such a constraint is not imposed. When the gci_no_persistent_rice_adaptation_constraint_flag does not exist, it is inferred that the value of gci_no_persistent_rice_adaptation_constraint_flag is equal to 0.

[0237] If sps_persistent_rice_adaptation_enabled_flag is equal to 1, it specifies that at the start of each TU, the statistical data accumulated from the previous TU is used to initialize the Rice parameter derivation for the binarization of abs_remainder[] and dec_abs_level[]. If sps_persistent_rice_adaptation_enabled_flag is equal to 0, it specifies that the previous TU state is not used in the Rice parameter derivation. When it does not exist, it is inferred that the value of sps_persistent_rice_adaptation_enabled_flag is equal to 0. An example of determining the Rice parameter using sps_persistent_rice_adaptation_enabled_flag in VVCv2 is shown below (the underlined content is added by VVCv2 on VVCv1).

[0238] If the CTU is the first CTU in a slice or tile, the initialization process of the context variables is called, as specified in Subclause 9.3.2.2. The array PredictorPaletteSize[chType] (where chType = 0, 1) is initialized to 0, and the array StatCoeff[i] (where i = 0..2) is initialized as follows:

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

[0240] (1513X3)

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

[0242] gci_no_reverse_last_sig_coeff_constraint_flag

[0243] If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 1, it specifies that the sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope should be equal to 0. If gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0, such a constraint is not imposed. When there is no gci_no_reverse_last_sig_coeff_constraint_flag, it is inferred that the value of gci_no_reverse_last_sig_coeff_constraint_flag is equal to 0.

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

[0245] If sh_reverse_last_sig_coeff_flag is equal to 1, the coordinates of the last significant coefficient are specified relative to ((Log2ZoTbWidth<<1)-1, (Log2ZoTbHeight<<1)-1) of each transform block of the current slice. If sh_reverse_last_sig_coeff_flag is equal to 0, the coordinates of the last significant coefficient are specified relative to (0, 0) of each transform block of the current slice. When it does not exist, it is inferred that the value of sh_reverse_last_sig_coeff_flag is equal to 0.

[0246] The sh_reverse_last_sig_coeff_flag is conditionally parsed using sps_reverse_last_sig_coeff_enabled_flag in the slice header as follows.

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

[0248] LastSignificantCoeffX = last_sig_coeff_x_prefix (193)

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

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

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

[0252] When sh_reverse_last_sig_coeff_flag is equal to 1, the value of LastSignificantCoeffX is modified as follows:

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

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

[0255] LastSignificantCoeffY = last_sig_coeff_y_prefix (196)

[0256] - Otherwise (if there is a last_sig_coeff_y_suffix), the following applies:

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

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

[0259] When sh_reverse_last_sig_coeff_flag is equal to 1, the value of LastSignificantCoeffY is modified as follows:

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

[0261] VVCv2 slice header

[0262]

[0263] Figure 5 An example of a process 500 for decoding video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the Figure 5 operations depicted therein. For example, a computing device implementing the video decoder 200 can implement the Figure 5 operations depicted therein, which 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 prediction module 224, and an intra prediction module 226. For illustrative purposes, the process 500 is described with reference to some examples depicted in the figures. However, there may be other implementations.

[0264] At block 502, process 500 involves accessing a bitstream of a video signal (e.g., encoded video 202). At block 504, process 500 involves extracting a General Constraint Information (GCI) flag from the bitstream of the video. As discussed above, the binary flag gci_present_flag is used to specify whether a GCI syntax element is present. A gci_present_flag equal to 1 specifies that the GCI syntax element is present in the general_constraints_info() syntax structure and is used to indicate constraints imposed on additional coding tools. A gci_present_flag equal to 0 specifies that the GCI syntax element is not present and no general constraints are imposed on the video. Depending on the encoder, the GCI flag can be extracted from the video's network packets, the video's Video Parameter Set, or the video's Sequence Parameter Set.

[0265] At block 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), then at block 508, process 500 involves extracting a value M representing the number of additional bits included in the bitstream of the video from the bitstream of the video. These additional bits include a plurality of flag bits that indicate respective additional coding tools to be constrained for the video.

[0266] At block 510, process 500 involves determining whether M > 5. If so, at block 512, process 500 involves extracting six flag bits from the bitstream, the six flag bits representing respective flags that indicate respective constraints on six additional coding tools. The six flags include: the flag gci_all_rap_pictures_constraint_flag, which indicates that the pictures of the video are restricted to intra random access point (IRAP) pictures or gradual decoding refresh (GDR) pictures; the flag gci_no_extended_precision_processing_constraint_flag, which indicates whether extended transform precision is constrained; the flag gci_no_ts_residual_coding_rice_constraint_flag, which indicates whether explicit Rice parameter signaling is constrained; the flag gci_no_rrc_rice_extension_constraint_flag, which indicates an alternative Rice parameter derivation for binarizing the quantization residuals of the video; the flag gci_no_persistent_rice_adaptation_constraint_flag, which indicates whether to initialize the Rice parameter derivation for binarization based on a previous transform unit; and the flag gci_no_reverse_last_sig_coeff_constraint_flag, which indicates whether to impose a constraint on the pictures in OlsInScope when decoding the position of the last non-zero level in the TU.

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

[0268] At block 514, process 500 involves decoding the remaining portion of the bitstream of the video into pictures in accordance with constraints on six additional coding tools indicated by these six flags. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder may determine that all pictures in one or more output layer sets are IRAP pictures or GDR pictures with ph_recovery_poc_cnt equal to 0, and decode the GDR pictures or IRAP pictures in one or more output layer sets. If the flag gci_no_extended_precision_processing_constraint_flag is 1, the decoder may determine that extended transform precision is constrained and decode the video by setting sps_extended_precision_flag for pictures in OlsInScope equal to 0 such that extended dynamic range is not used. If the flag gci_no_ts_residual_coding_rice_constraint_flag is 1, the decoder may determine that explicit Rice parameter signaling is constrained and decode the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for pictures in OlsInScope. If the flag gci_no_rrc_rice_extension_constraint_flag is 1, the decoder may determine that alternative Rice parameter derivation for binarizing the quantized residuals of the video is constrained and decode the remaining portion of the bitstream of the video by disabling alternative Rice parameter signaling for pictures in OlsInScope. If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder may determine that the initialization of Rice parameter derivation for binarization based on the previous transform unit state is constrained and decode the remaining portion of the bitstream of the video without initializing the Rice parameter based on the previous transform unit state for pictures in OlsInScope. If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder may determine that sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope is equal to 0 and determine that the coordinates of the last significant coefficient are encoded relative to the top left corner (0, 0) of each transform block of the current slice, and decode the remaining portion of the bitstream of the video by interpreting the decoded coordinates of the last significant coefficient as being relative to the top left corner (0, 0) of each transform block of the current slice.

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

[0270] Figure 6 Another example of a process 600 for decoding video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the Figure 6 operations depicted in. For example, a computing device implementing video decoder 200 can implement the Figure 6 operations depicted in, and 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 prediction module 224, and an intra prediction module 226. For illustrative purposes, process 600 is described with reference to some examples depicted in the figures. However, there may be other implementations.

[0271] At block 602, process 600 involves accessing the bitstream of a video signal (e.g., encoded video 202). At block 604, process 600 involves extracting a General Constraint Information (GCI) flag from the bitstream of the video. As discussed above, this binary flag gci_present_flag is used to specify whether GCI syntax elements are present. gci_present_flag being equal to 1 specifies that GCI syntax elements are present in the general_constraints_info() syntax structure and is used to indicate the constraints imposed on the additional coding tools. gci_present_flag being equal to 0 specifies that GCI syntax elements are not present and no general constraints are imposed on the video. Depending on the encoder, the GCI flag can be extracted from the network packets of the video, the video parameter set of the video, or the sequence parameter set of the video.

[0272] At block 606, process 600 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), then at block 608, process 600 involves extracting a value M representing the number of additional bits included in the bitstream of the video from the bitstream of the video. These additional bits include flag bits that indicate the corresponding additional coding tools to be constrained for the video.

[0273] At block 610, process 600 involves determining whether M is greater than 6. If so, at block 612, process 600 involves extracting six flag bits from the bitstream, the six flag bits representing respective flags that indicate respective constraints on six additional coding tools. The six flags include: the flag gci_all_rap_pictures_constraint_flag, which indicates that the pictures of the video are restricted to intra random access point (IRAP) pictures or gradual decoding refresh (GDR) pictures; the flag gci_no_extended_precision_processing_constraint_flag, which indicates whether extended transform precision is constrained; the flag gci_no_ts_residual_coding_rice_constraint_flag, which indicates whether explicit Rice parameter signaling is constrained; the flag gci_no_rrc_rice_extension_constraint_flag, which indicates an alternative Rice parameter derivation for binarizing the quantization residuals of the video; the flag gci_no_persistent_rice_adaptation_constraint_flag, which indicates whether to initialize the Rice parameter derivation for binarization based on a previous transform unit; and the flag gci_no_reverse_last_sig_coeff_constraint_flag, which indicates whether to impose a constraint on the pictures in OlsInScope when decoding the position of the last non-zero level in a TU.

[0274] At block 614, process 600 involves extracting M - 6 bits following the 6 flag bits from the bitstream and discarding the extracted M - 6 bits. In other words, the decoding of the video will be performed independently of these M - 6 bits. At block 616, process 600 involves decoding the remaining portion of the video bitstream into images according to the constraints on the 6 additional coding tools indicated by the 6 flags. For example, if the flag gci_all_rap_pictures_constraint_flag is 1, the decoder may determine that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and decode the GDR images or IRAP images in one or more output layer sets. If the flag gci_no_extended_precision_processing_constraint_flag is 1, the decoder may determine that the extended transform precision is constrained and decode the video by setting sps_extended_precision_flag for the images in OlsInScope equal to 0, such that the extended dynamic range is not used. If the flag gci_no_ts_residual_coding_rice_constraint_flag is 1, the decoder may determine that the explicit Rice parameter signaling is constrained and decode the remaining portion of the video bitstream by disabling the alternative Rice parameter signaling for the images in OlsInScope. If the flag gci_no_rrc_rice_extension_constraint_flag is 1, the decoder may determine that the alternative Rice parameter derivation for binarizing the quantized residuals of the video is constrained and decode the remaining portion of the video bitstream by disabling the alternative Rice parameter signaling for the images in OlsInScope. If the flag gci_no_persistent_rice_adaptation_constraint_flag is 1, the decoder may determine that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained and decode the remaining portion of the video bitstream without initializing the Rice parameter based on the previous transform unit state for the images in OlsInScope.If the flag gci_no_reverse_last_sig_coeff_constraint_flag is 1, the decoder may determine that the sps_reverse_last_sig_coeff_enabled_flag for all pictures in OlsInScope is equal to 0, and determine to encode the coordinates of the last significant coefficient relative to the top-left corner (0, 0) of each transform block of the current slice, and decode the remaining part of the video bitstream by interpreting the decoded coordinates of the last significant coefficient as being relative to the top-left corner (0, 0) of each transform block of the current slice.

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

[0276] Figure 7 Another example of a process 700 for decoding video according to some embodiments of the present disclosure is depicted. One or more computing devices implement the Figure 7 operations depicted in. For example, a computing device implementing the video decoder 200 may implement the Figure 7 operations depicted in, the computing device including, for example, an entropy decoding module 216, an inverse quantization module 218, an inverse transform module 219, a loop filter module 220, an inter prediction module 224, and an intra prediction module 226. For illustrative purposes, process 700 is described with reference to some examples depicted in the figures. However, there may be other implementations.

[0277] At block 702, process 700 involves accessing a bitstream of a video signal (such as encoded video 202). At block 704, process 700 involves extracting a General Constraint Information (GCI) flag from the bitstream of the video. As discussed above, the binary flag gci_present_flag is used to specify whether GCI syntax elements are present. A gci_present_flag equal to 1 specifies that GCI syntax elements are present in the general_constraints_info() syntax structure and are used to indicate constraints imposed on additional coding tools. A gci_present_flag equal to 0 specifies that GCI syntax elements are not present 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's Video Parameter Set, or the video's Sequence Parameter Set.

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

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

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

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

[0282] Any suitable computing system can be used to perform the operations described herein. For example,Figure 8 depicts an example of a computing device 800 that can implement Figure 1 a video encoder 100 or Figure 2 a video decoder 200. In some embodiments, the computing device 800 may include a processor 812 that is communicatively coupled to a memory 814 and executes computer-executable program code stored in the memory 814 and / or accesses information. The processor 812 may include a microprocessor, an application specific integrated circuit (“ASIC”), a state machine, or other processing device. The processor 812 may include any one of a plurality of processing devices (including one processing device). Such a processor may include a computer-readable medium storing instructions, or may be communicatively coupled to a computer-readable medium storing instructions, which when executed by the processor 812, cause the processor to perform the operations described herein.

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

[0284] The computing device 800 may further include a bus 816. The bus 816 may communicatively couple one or more components of the computing device 800. The computing device 800 may further include a plurality of external or internal devices, such as input or output devices. For example, the computing device 800 is shown as having an input / output (“I / O”) interface 818, and the I / O interface 818 may receive input from one or more input devices 820 or provide output to one or more output devices 822. One or more input devices 820 and one or more output devices 822 may be communicatively coupled to the I / O interface 818. The communicative coupling may be achieved in any suitable manner (e.g., via printed circuit board connections, via cable connections, via wireless transmission communication, etc.). Non-limiting examples of the input device 820 include a touch screen (e.g., one or more cameras for imaging a touch area, or a pressure sensor for detecting pressure changes caused by a touch), a mouse, a keyboard, or any other device that may be used to generate an input event in response to a physical action of a user of the computing device. Non-limiting examples of the output device 822 include an LCD screen, an external monitor, a speaker, or any other device that may be used to display or otherwise present the output generated by the computing device.

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

[0286] The computing device 800 may further 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 an Ethernet network adapter, a modem, etc. The computing device 800 may transmit messages as electrical or optical signals via the network interface device 824.

[0287] General considerations

[0288] Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter may be practiced without these specific details. In other instances, methods, devices, 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.

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

[0290] One or more systems discussed herein are not limited to any particular hardware architecture or configuration. A computing device can include any suitable arrangement of components that provide results conditioned on one or more inputs. Suitable computing devices include computer systems based on a general-purpose microprocessor that access stored software, which programs or configures the computing system to transform from a general-purpose computing device into a special-purpose computing device, thereby implementing one or more embodiments of the subject matter herein. Any suitable programming, scripting, or other type of language or combination of languages can be used to implement the teachings contained herein in the software for programming or configuring a computing device.

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

[0292] As used herein, "adapted to" or "configured to" means open and inclusive language that does not exclude a device adapted to or configured to perform additional tasks or steps. Additionally, the use of "based on" is open and inclusive because a process, step, calculation, or other action "based on" one or more recited conditions or values can actually be based on additional conditions or values beyond those recited. The headings, lists, and numbers included herein are for ease of explanation only and are not meant to be limiting.

[0293] Although the subject matter herein has been described in detail with respect to specific embodiments of the subject matter, it should be appreciated that those skilled in the art, upon understanding the foregoing, can readily make alterations, variations, and equivalents to such embodiments. Accordingly, it is to be understood that this disclosure is presented for purposes of illustration and not limitation, and does not exclude such modifications, variations, and / or additions to the subject matter herein that would be apparent to a person of ordinary skill in the art.

Claims

1. A method for decoding a video, the method comprising: extracting a General Constraint Information (GCI) flag from a bitstream; determining, based on the value of the GCI flag, to impose one or more general constraints on decoding the bitstream; in response to determining to impose the one or more general constraints on decoding the bitstream, extracting a value indicating the number of additional bits included in the bitstream, the additional bits including flag bits that indicate respective additional coding configurations to be constrained for the video; determining whether the value is greater than 5; and in response to determining that the value is greater than 5, extracting 6 flag bits representing 6 respective flags from the bitstream, the 6 respective flags indicating respective constraints on 6 additional coding configurations, and decoding the remainder of the bitstream at least in part based on the respective constraints on the 6 additional coding configurations indicated by the 6 flags.

2. The method according to claim 1, wherein The 6 flags include: a first flag indicating that the limitation on an image of the video is an Intra Random Access Point (IRAP) image or a Gradual Decoding Refresh (GDR) image; a second flag indicating whether the extended transform precision is constrained; a third flag indicating whether the explicit Rice parameter signaling is constrained; a fourth flag indicating an alternative Rice parameter derivation for the binarization of the quantization residuals for the video; a fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on a previous transform unit; and a sixth flag indicating whether to impose a constraint on an image in the set of output layers in scope (OlsInScope) when decoding the position of the last non-zero level in a transform unit.

3. The method according to claim 2, further comprising one or more of the following: determining that the first flag does not exist in the bitstream and inferring that the value of the first flag is 0 for indicating that no constraint is imposed on the corresponding decoding; determining that the second flag does not exist in the bitstream and inferring that the value of the second flag is 0 for indicating that no constraint is imposed on the corresponding decoding; determining that the third flag does not exist in the bitstream and inferring that the value of the third flag is 0 for indicating that no constraint is imposed on the corresponding decoding; determining that the fourth flag does not exist in the bitstream and inferring that the value of the fourth flag is 0 for indicating that no constraint is imposed on the corresponding decoding; determining that the fifth flag does not exist in the bitstream and inferring that the value of the fifth flag is 0 for indicating that no constraint is imposed on the corresponding decoding; or determining that the sixth flag does not exist in the bitstream and inferring that the value of the sixth flag is 0 for indicating that no constraint is imposed on the corresponding decoding.

4. The method according to claim 2, wherein Decoding the remainder of the bitstream at least in part based on the respective constraints on the 6 additional coding configurations indicated by the 6 flags includes one or more of the following: based on the first flag being 1, determining that all images in one or more sets of output layers are IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and decoding the GDR images or IRAP images in the one or more sets of output layers; Based on the second flag being 1, determine that the extended transform precision is constrained, and decode the remaining part of the bitstream by setting sps_extended_precision_flag for the images in the output layer set OlsInScope within the range to be equal to 0, such that the extended dynamic range is not used; Based on the third flag being 1, determine that the explicit Rice parameter signaling is constrained, and decode the remaining part of the bitstream by disabling the alternative Rice parameter signaling for the images in the output layer set OlsInScope within the range; Based on the fourth flag being 1, determine that the alternative Rice parameter derivation for binarizing the quantization residuals of the video is constrained, and decode the remaining part of the bitstream by disabling the alternative Rice parameter signaling for the images in the output layer set OlsInScope within the range; Based on determining that the fifth flag is 1, determine that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained, and decode the remaining part of the bitstream without initializing the Rice parameter based on the previous transform unit state for the images in the output layer set OlsInScope within the range; or Based on the sixth flag being 1, determine that the coordinates of the last significant coefficient are encoded relative to the top left corner of each transform block of the slice, and decode the remaining part of the bitstream by interpreting the decoded coordinates of the last significant coefficient as being relative to the top left corner of each transform block of the slice.

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

6. The method according to claim 1, further comprising: In response to determining that the value is greater than 5, set the value numAdditionalBitsUsed indicating the extracted additional bits to 6; Extract a set of bits from the bitstream, where the number of bits in the set of bits is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Decode the remaining part of the bitstream independently of the set of bits.

7. The method according to claim 1, further comprising: In response to determining that the value is not greater than 5, set the value numAdditionalBitsUsed indicating the extracted additional bits to 0; Extract a set of bits from the bitstream, where the number of bits in the set of bits is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Decode the remaining part of the bitstream independently of the extracted set of bits.

8. A non - transitory computer - readable medium having program code stored thereon, the program code being executable by one or more processing devices to perform operations, the operations including: Extracting a General Constraint Information (GCI) flag from a bitstream; Based on the value of the GCI flag, determining one or more general constraints imposed on decoding the bitstream; In response to determining that the one or more general constraints are imposed on decoding the bitstream, extracting a value indicating the number of additional bits included in the bitstream, the additional bits including flag bits that indicate corresponding additional coding configurations to be constrained for a video; Determining whether the value is greater than 5; And In response to determining that the value is greater than 5, Extracting 6 flag bits representing 6 corresponding flags from the bitstream, the 6 corresponding flags indicating corresponding constraints on 6 additional coding configurations, and Decoding the remaining part of the bitstream at least in part based on the corresponding constraints on the 6 additional coding configurations indicated by the 6 flags.

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

10. The non-transitory computer-readable medium according to claim 9, wherein, The operations further include one or more of the following: Determining that the first flag does not exist in the bitstream and inferring that the value of the first flag is 0, for indicating that no corresponding constraint is imposed on decoding; Determining that the second flag does not exist in the bitstream and inferring that the value of the second flag is 0, for indicating that no corresponding constraint is imposed on decoding; Determining that the third flag does not exist in the bitstream and inferring that the value of the third flag is 0, for indicating that no corresponding constraint is imposed on decoding; Determining that the fourth flag does not exist in the bitstream and inferring that the value of the fourth flag is 0, for indicating that no corresponding constraint is imposed on decoding; Determining that the fifth flag does not exist in the bitstream and inferring that the value of the fifth flag is 0, for indicating that no corresponding constraint is imposed on decoding; Or Determining that the sixth flag does not exist in the bitstream and inferring that the value of the sixth flag is 0, for indicating that no corresponding constraint is imposed on decoding.

11. The non-transitory computer-readable medium according to claim 9, wherein, Decoding the remaining part of the bitstream at least in part based on the corresponding constraints on the 6 additional coding configurations indicated by the 6 flags includes one or more of the following: Based on the first flag being 1, determine that all images in one or more output layer sets are IRAP images or GDR images with ph_recovery_poc_cnt equal to 0, and decode the GDR images or IRAP images in the one or more output layer sets; Based on the second flag being 1, determine that the extended transform precision is constrained, and decode the remaining part of the bitstream by setting the sps_extended_precision_flag for the images in the output layer set OlsInScope within the range to be equal to 0, such that the extended dynamic range is not used; Based on the third flag being 1, determine that the explicit Rice parameter signaling is constrained, and decode the remaining part of the bitstream by disabling the alternative Rice parameter signaling for the images in the output layer set OlsInScope within the range; Based on the fourth flag being 1, determine that the alternative Rice parameter derivation for binarizing the quantization residuals of the video is constrained, and decode the remaining part of the bitstream by disabling the alternative Rice parameter signaling for the images in the output layer set OlsInScope within the range; Based on determining that the fifth flag is 1, determine that the initialization of the Rice parameter derivation for binarization based on the previous transform unit state is constrained, and decode the remaining part of the bitstream without initializing the Rice parameter based on the previous transform unit state for the images in the output layer set OlsInScope within the range; or Based on the sixth flag being 1, determine that the coordinates of the last significant coefficient are encoded relative to the upper left corner of each transform block of the slice, and decode the remaining part of the bitstream by interpreting the decoded coordinates of the last significant coefficient as being relative to the upper left corner of each transform block of the slice.

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

13. The non-transitory computer-readable medium according to claim 8, wherein, The operation further includes: In response to determining that the value is greater than 5, set the value numAdditionalBitsUsed indicating the extracted additional bits to 6; Extract a set of bits from the bitstream, where the number of bits in the set of bits is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Decode the remaining part of the bitstream independently of the set of bits.

14. The non-transitory computer-readable medium according to claim 8, wherein, The operation further includes: In response to determining that the value is not greater than 5, set the value numAdditionalBitsUsed indicating the extracted additional bits to 0; Extract a set of bits from the bitstream, where the number of bits in the set of bits is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Decode the remaining part of the bitstream independently of the extracted set of bits.

15. A system for decoding video, comprising: A processing device; And A non-transitory computer-readable medium communicatively coupled to the processing device, wherein the processing device is configured to execute program code stored in the non-transitory computer-readable medium to perform operations, the operations including: Extract a General Constraint Information (GCI) flag from the bitstream; Based on the value of the GCI flag, determine one or more general constraints imposed on decoding the bitstream; In response to determining that the one or more general constraints are imposed on decoding the bitstream, extract a value indicating the number of additional bits included in the bitstream from the bitstream, the additional bits including flag bits that indicate corresponding additional coding configurations to be constrained for the video; Determine whether the value is greater than 5; and In response to determining that the value is greater than 5, Extract 6 flag bits representing 6 corresponding flags from the bitstream, the 6 corresponding flags indicating corresponding constraints on 6 additional coding configurations, and Decode the remaining part of the bitstream at least partially based on the corresponding constraints on the 6 additional coding configurations indicated by the 6 flags.

16. The system according to claim 15, wherein, The 6 flags include: A first flag indicating that the limitation of the image of the video is an Intra Random Access Point (IRAP) image or a Gradual Decoding Refresh (GDR) image; A second flag indicating whether the extended transform precision is constrained; A third flag indicating whether the explicit Rice parameter signaling is constrained; A fourth flag indicating an alternative Rice parameter derivation for the binarization of the quantization residuals of the video; A fifth flag indicating whether to initialize the Rice parameter derivation for binarization based on a previous transform unit; and A sixth flag indicating whether to impose a constraint on the image in the set of output layers in scope (OlsInScope) when decoding the position of the last non-zero level in the transform unit.

17. The system according to claim 16, wherein, The operations further include one or more of the following: Determine that the first flag does not exist in the bitstream and infer that the value of the first flag is 0, for indicating that no constraint is imposed on the corresponding decoding; Determine that the second flag does not exist in the bitstream and infer that the value of the second flag is 0, for indicating that no constraint is imposed on the corresponding decoding; Determine that the third flag does not exist in the bitstream and infer that the value of the third flag is 0, for indicating that no constraint is imposed on the corresponding decoding; Determine that the fourth flag does not exist in the bitstream and infer that the value of the fourth flag is 0, for indicating that no constraint is imposed on the corresponding decoding; Determine that the fifth flag does not exist in the bitstream and infer that the value of the fifth flag is 0, for indicating that no constraint is imposed on the corresponding decoding; Or Determine that the sixth flag does not exist in the bitstream and infer that the value of the sixth flag is 0, which is used to indicate that no constraints are imposed on the corresponding decoding.

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

19. The system according to claim 15, wherein, The GCI flag is extracted from the network packets of the video, the video parameter set of the video, or the sequence parameter set of the video.

20. The system according to claim 15, wherein The operation further includes: In response to determining that the value is greater than 5, set the value numAdditionalBitsUsed indicating the extracted additional bits to 6; Extract a set of bits from the bitstream, where the number of bits in the set of bits is equal to gci_num_additional_bits - numAdditionalBitsUsed, and gci_num_additional_bits represents the value; and Decode the remaining part of the bitstream independently of the set of bits.

Citation Information

Patent Citations

  • Systems and methods for signaling general constraint information in video coding

    US20210368208A1

  • Method and apparatus for video coding

    WO2021207023A1