Method, device and storage medium for video decoding in decoder

Abstract

Aspects of the present disclosure provide methods and apparatus for video data processing. In some examples, the apparatus for video data processing includes a processing circuit. For example, the processing circuit determines a first syntax element for encoding control in a first range of encoded video data in a bitstream. The first syntax element is associated with a continuous Rice adaptive encoding tool for statistical-based Rice parameter derivation in residual coding and defined in a range extension of a video standard. In response to the first syntax element being a first value indicating that the encoding tool is disabled in the first range, the processing circuit decodes the first range of the encoded video data including one or more second ranges of the encoded video data without invoking the encoding tool.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to U.S. Patent Application No. 17 / 710,786, filed on March 31, 2022, entitled “TECHNIQUESFOR CONSTRAINT FLAG SIGNALING FOR RANGE EXTENSION WITH PERSISTENT RICE ADAPTATION,” which claims the benefit of priority to U.S. Provisional Application No. 63 / 250,172, filed on September 29, 2021, entitled “TECHNIQUES FOR CONSTRAINT FLAG SIGNALING FOR RANGE EXTENSION WITH PERSISTENT RICE ADAPTATION.” The disclosures of both prior applications are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure describes embodiments generally related to video coding. Background Art

[0004] The background description provided herein is intended to present the background of the present disclosure as a whole. Certain works of the presently named inventors (i.e., works described in this background section) and the contents described in various aspects of this specification that have not become prior art before the filing date are never explicitly or implicitly admitted to be prior art of the present disclosure.

[0005] Video encoding and decoding is possible through inter-picture prediction with motion compensation. An uncompressed digital video may include a series of pictures, each picture having spatial dimensions of, for example, 1920x1080 luma samples and associated chroma samples. The series of pictures may have a fixed or variable picture rate (also informally referred to as a frame rate), such as 60 pictures per second or 60Hz. Uncompressed video has specific bitrate requirements. For example, 1080p60 4:2:0 video (1920x1080 luma sample resolution, 60Hz frame rate) with 8 bits per sample requires close to 1.5Gbit / s bandwidth. One hour of such video would require more than 600GB of storage space.

[0006] One goal of video encoding and decoding can be to reduce redundancy in the input video signal through compression. Compression can help reduce the bandwidth and / or storage space requirements mentioned above, in some cases by two or more orders of magnitude. Both lossless and lossy compression, and combinations of the two, can be used. Lossless compression refers to techniques that can reconstruct an exact replica of the original signal from the compressed original signal. When lossy compression is used, the reconstructed signal may not be exactly the same as the original signal, but the distortion between the original and the reconstructed signal is small enough that the reconstructed signal can be used for the intended application. Lossy compression is widely used for video. The amount of distortion allowed depends on the application. For example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio may reflect that higher allowed / tolerable distortion produces higher compression ratios.

[0007] Video encoders and decoders may utilize several broad categories of techniques including, for example: motion compensation, transforms, quantization, and entropy coding.

[0008] Video codec techniques may include known intra-coding techniques. In intra-coding, sample values ​​are represented without reference to samples or other data of previously reconstructed reference pictures. In some video codecs, pictures are spatially subdivided into blocks of samples. When all sample blocks are encoded in intra-frame mode, the picture may be an intra-picture. Intra-pictures and their derivatives (e.g., independent decoder refresh pictures) may be used to reset decoder states, and may therefore be used as the first picture in a coded video bitstream and video session, or as a still image. Samples of intra-blocks may be used for transformation, and transform coefficients may be quantized before entropy coding. Intra-prediction may be a technique for minimizing sample values ​​in a pre-transform domain. In some cases, the smaller the DC value after transformation, and the smaller the AC coefficient, the fewer bits are needed to represent the block after entropy coding at a given quantization step size.

[0009] Conventional intra-frame coding, as known from coding techniques such as MPEG-2, does not use intra-frame prediction. However, some newer video compression techniques include techniques that attempt to derive a block of data from, for example, surrounding sample data and / or metadata that is obtained during spatially adjacent encoding / decoding and prior to the decoding order. Such techniques have subsequently been referred to as "intra-frame prediction" techniques. It should be noted that, at least in some cases, intra-frame prediction uses only reference data of the current picture being reconstructed, and not reference data of reference pictures.

[0010] There can be many different forms of intra prediction. When more than one such technique can be used in a given video codec, the techniques used can be encoded as intra prediction modes. In some cases, a mode can have sub-modes and / or parameters, and these can be encoded separately or contained in a mode codeword. Which codeword is used for a given mode / sub-mode / parameter combination affects the codec efficiency gain through intra prediction, and therefore the entropy coding technique used to convert the codewords into the bitstream.

[0011] H.264 introduced an intra prediction mode, which was improved in H.265 and further improved in newer codecs such as the joint exploration model (JEM), versatile video coding (VVC), and benchmark set (BMS). A prediction block can be formed by using neighboring sample values ​​belonging to samples that are already available. The sample values ​​of neighboring samples are copied into the prediction block in a certain direction. A reference to the direction used can be encoded in the bitstream or can be predicted itself.

[0012] Referring to FIG. 1A , a subset of nine known prediction directions from the 33 possible prediction directions of H.265 (corresponding to the 33 angular modes in the 35 intra modes) is depicted at the bottom right. The point (101) where the arrows converge represents the sample being predicted. The arrows represent the direction in which the sample is being predicted. For example, arrow (102) indicates that sample (101) is predicted based on one or more samples at a 45 degree angle to the upper right and horizontal direction. Similarly, arrow (103) indicates that sample (101) is predicted based on one or more samples at a 22.5 degree angle to the lower left of sample (101) and horizontal direction.

[0013] Still referring to FIG. 1A , a square block (104) comprising 4×4 samples is shown at the upper left (indicated by the thick dashed line). The square block (104) comprises 16 samples, each of which is labeled with “S”, and its position in the Y dimension (e.g., row index) and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample in the Y dimension (starting from the top) and the first sample in the X dimension (starting from the left). Similarly, sample S44 is the fourth sample in the block (104) in both the X and Y dimensions. Since the block is a 4×4 size sample, S44 is located in the lower right corner. Reference samples following a similar numbering scheme are also shown. The reference samples are labeled with R, and their Y position (e.g., row index) and X position (column index) relative to the block (104). In H.264 and H.265, the prediction samples are adjacent to the block being reconstructed, so there is no need to use negative values.

[0014] Intra-picture prediction can be performed by copying reference sample values ​​from neighboring samples occupied by a signaled prediction direction. For example, assume that the encoded video bitstream includes signaling that, for this block, indicates a prediction direction consistent with arrow (102), i.e., the sample is predicted based on one or more prediction samples to the upper right at a 45 degree angle to the horizontal direction. In this case, samples S41, S32, S23, and S14 are predicted based on the same reference sample R05. Sample S44 is then predicted based on reference sample R08.

[0015] In some cases, for example by interpolation, the values ​​of multiple reference samples may be combined in order to calculate the reference sample, particularly when the direction is not divisible by 45 degrees.

[0016] As video codecs have evolved, the number of possible directions has increased. In H.264 (2003), nine different directions could be represented. This increased to 33 in H.265 (2013) and JEM / VVC / BMS, and at the time of this application, up to 65 directions can be supported. Experiments have been conducted to identify the most likely directions, and certain techniques in entropy coding are used to represent those possible directions using a small number of bits, accepting some penalty for less likely directions. Additionally, the direction itself can sometimes be predicted based on neighboring directions used in adjacent, already decoded blocks.

[0017] FIG. 1B shows a schematic diagram ( 180 ) depicting 65 intra prediction directions according to JEM to illustrate the increasing number of prediction directions over time.

[0018] The mapping of intra prediction direction bits in the coded video bitstream representing the direction may vary from one video codec to another, and may, for example, range from a simple direct mapping of the intra prediction mode to the prediction direction of the codeword, to complex adaptive schemes involving the most probable mode and similar techniques. However, in all cases, there may be certain directions in the video content that are statistically less likely to occur than other directions. Since the goal of video compression is to reduce redundancy, in a well-behaved video codec, those less likely directions will be represented using a larger number of bits than more likely directions.

[0019] Motion compensation may be a lossy compression technique and may involve a technique where a block of sample data from a previously reconstructed picture or part of a reconstructed picture (reference picture) is used for prediction of a newly reconstructed picture or part of a picture after being spatially shifted in the direction indicated by a motion vector (hereinafter MV). In some cases, the reference picture may be the same as the picture currently being reconstructed. The MV may have two dimensions, X and Y, or three dimensions, where the third dimension indicates the reference picture in use (the latter may indirectly be the temporal dimension).

[0020] In some video compression techniques, the MV applied to a region of sample data can be predicted based on other MVs, such as those associated with another region of sample data that is spatially adjacent to the region being reconstructed and that precedes the MV in decoding order. Doing so can significantly reduce the amount of data required to encode the MV, thereby eliminating redundant information and increasing the amount of compression. MV prediction can be done effectively, for example, when encoding an input video signal derived from a camera (called natural video), there is a statistical probability that regions larger than the region to which a single MV applies will move in a similar direction, so in some cases, similar motion vectors derived from MVs of neighboring regions can be used for prediction. This results in the MV found for a given region being similar or identical to the MV predicted from the surrounding MVs, and after entropy coding, it can be represented with fewer bits than the number of bits used when the MV is directly encoded. In some cases, MV prediction can be an example of lossless compression of a signal (i.e., MV) derived from the original signal (i.e., sample stream). In other cases, MV prediction itself may be lossy, for example due to rounding errors when calculating predicted values ​​based on several surrounding MVs.

[0021] H.265 / HEVC (ITU-T Rec. H.265, "High Efficiency Video Codec", December 2016) describes various MV prediction mechanisms. Among the various MV prediction mechanisms provided by H.265, this article describes a technique hereinafter referred to as "spatial merging".

[0022] 2, the current block (201) includes samples found by the encoder during motion search that can be predicted from a previous block that has been spatially shifted by the same amount. The MV is not encoded directly, but is derived from metadata associated with one or more reference pictures, such as the most recent (in decoding order) reference picture, using the MV associated with any of the five surrounding samples, represented by A0, A1 and B0, B1, B2 (202 to 206, respectively). In H.265, MV prediction can use the prediction value of the same reference picture being used by the neighboring blocks. Summary of the invention

[0023] Various aspects of the present disclosure provide methods and apparatus for video data processing. In some examples, the apparatus for video data processing includes a processing circuit. For example, the processing circuit determines a first syntax element for encoding control in a first range of encoded video data in a bitstream. The first syntax element is associated with a coding tool for statistically based Rice parameter derivation in residual coding and persistent Rice adaptation defined in a range extension of a video standard. In response to the first syntax element being a first value indicating that the coding tool is disabled in the first range, the processing circuit decodes the first range of encoded video data including one or more second ranges of encoded video data without calling the coding tool.

[0024] In some embodiments, the first syntax element is typically constraint information for coding control of a picture in an output layer set for a decoder. In some examples, the first value of the first syntax element indicates that the coding tool is disabled in each coded layer video sequence (CLVS) in the output layer set. In some examples, the processing circuit constrains a second syntax element for coding control of a coded layer video sequence (CLVS) in the bitstream to have a value indicating that the coding tool is not invoked to decode the CLVS.

[0025] In some embodiments, in response to the first syntax element being a second value, the processing circuit determines a value of a second syntax element for coding control of a coding layer video sequence (CLVS) in the bitstream. The second syntax element indicates use / non-use of the coding tool in the CLVS. In one example, in response to the second syntax element not being present in a sequence parameter set (SPS) for the CLVS, the processing circuit infers the value of the second syntax element for indicating non-use of the coding tool in the CLVS.

[0026] In some examples, in response to the value of the second syntax element indicating the use of the coding tool in the CLVS, the processing circuit determines statistics of coefficients decoded from one or more transform units before the current transform unit. The statistics are used to determine initial values ​​of Rice parameters for the current transform unit. Then, the coefficients of the current transform unit are decoded based on the Rice parameters.

[0027] In some embodiments, the processing circuit decodes the first syntax element from the syntax structure for generic constraint information in response to a syntax element in the syntax structure for generic constraint information indicating additional bits of generic constraint information in the syntax structure.

[0028] Aspects of the present disclosure also provide a non-transitory computer-readable medium storing instructions that, when executed by a computer for video decoding, cause the computer to perform a method for video decoding. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Other features, properties, and various advantages of the disclosed subject matter will become further apparent from the following detailed description and the accompanying drawings, in which:

[0030] FIG1A is a diagram illustrating an exemplary subset of intra prediction modes;

[0031] FIG1B is a schematic diagram of an exemplary intra prediction direction;

[0032] FIG2 is a schematic diagram of a current block and its surrounding spatial merging candidates in an example;

[0033] Figure 3 is a schematic diagram of a simplified block diagram of a communication system (300) according to an embodiment;

[0034] Figure 4 is a schematic diagram of a simplified block diagram of a communication system (400) according to an embodiment;

[0035] Figure 5 is a schematic diagram of a simplified block diagram of a decoder according to an embodiment;

[0036] Figure 6 is a schematic diagram of a simplified block diagram of an encoder according to an embodiment;

[0037] Figure 7 shows a block diagram of an encoder according to another embodiment;

[0038] Figure 8 shows a block diagram of a decoder according to another embodiment;

[0039] Fig. 9 An example of signaling adaptive resolution change (ARC) parameters according to some embodiments of the present disclosure is shown;

[0040] Fig.10 An example of a table (1000) for mapping upsampling or downsampling factors, codewords, and Ext-Golomb codes is shown.

[0041] Fig.11 Some examples of ARC parameter signaling according to some embodiments of the present disclosure are shown.

[0042] Fig.12 An example of the syntax structure of one PTL syntax element set in some examples is shown.

[0043] Fig.13 An example of the syntax structure of general constraint information in some examples is shown.

[0044] Figure 14A-14B An example of PTL information including a PTL syntax structure and a general constraint information syntax structure according to some embodiments of the present disclosure is shown.

[0045] Figure 15A-15B An example of a general constraint information syntax structure according to an embodiment of the present disclosure is shown.

[0046] Fig.16 The grammatical structure of general constraint information according to some embodiments of the present disclosure is shown.

[0047] Fig.17 An example of a syntax structure for a sequence parameter set (SPS) range extension according to some embodiments of the present disclosure is shown.

[0048] Fig.18 A flowchart of an overview process according to an embodiment of the present disclosure is shown.

[0049] Fig.19 A flowchart of an overview process according to an embodiment of the present disclosure is shown.

[0050] Fig. 20 is a schematic diagram of a computer system according to an embodiment. DETAILED DESCRIPTION

[0051] Figure 3 A simplified block diagram of a communication system (300) according to an embodiment of the present disclosure is illustrated. The communication system (300) includes a plurality of terminal devices that can communicate with each other via, for example, a network (350). For example, the communication system (300) includes a first pair of terminal devices, namely, a terminal device (310) and a terminal device (320), interconnected via the network (350). Figure 3 In the example of , a first pair of terminal devices, namely terminal device (310) and terminal device (320), perform unidirectional data transmission. For example, terminal device (310) can encode video data (such as a video picture stream collected by terminal device (310)) for transmission to another terminal device (320) via network (350). The encoded video data is transmitted in the form of one or more encoded video bitstreams (codestreams). Terminal device (320) can receive the encoded video data from network (350), decode the encoded video data to recover the video data, and display the video picture based on the recovered video data. Unidirectional data transmission is more common in applications such as media services.

[0052] In another example, the communication system (300) includes a second pair of terminal devices, namely a terminal device (330) and a terminal device (340), that perform bidirectional transmission of encoded video data, which bidirectional transmission may occur, for example, during a video conference. In one example, for bidirectional data transmission, each of the terminal devices (330) and the terminal device (340) may encode video data (e.g., a video picture stream captured by the terminal device) for transmission to the other terminal device (330) and the terminal device (340) via a network (350). Each of the terminal devices (330) and the terminal device (340) may also receive the encoded video data transmitted by the other terminal device (330) and the terminal device (340), and may decode the encoded video data to restore the video data, and may display the video picture on an accessible display device based on the restored video data.

[0053] exist Figure 3 In the example of , terminal device (310), terminal device (320), terminal device (330) and terminal device (340) may be shown as a server, a personal computer and a smart phone, but the principles of the present disclosure may not be limited thereto. Embodiments of the present disclosure are applicable to laptop computers, tablet computers, media players and / or dedicated video conferencing equipment. Network (350) represents any number of networks that transmit encoded video data between terminal devices (310), terminal devices (320), terminal devices (330) and terminal devices (340), including, for example, wired (wired) and / or wireless communication networks. Communication network (350) may exchange data in circuit switching and / or packet switching channels. Representative networks may include telecommunication networks, local area networks, wide area networks and / or the Internet. For the purposes of this discussion, unless explained below, the architecture and topology of network (350) may be irrelevant to the operation of the present disclosure.

[0054] As an example of the application of the subject matter disclosed in this application, Figure 4 The video encoder and video decoder are shown in a streaming environment. The subject matter disclosed in this application is equally applicable to other video-enabled applications, including, for example, video conferencing, digital TV, storing compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0055] The streaming system may include an acquisition subsystem (413) that may include a video source (401) such as a digital camera that creates, for example, an uncompressed video picture stream (402). In one example, the video picture stream (402) includes samples captured by the digital camera. The video picture stream (402) is depicted as a thick line to emphasize its high data volume compared to the encoded video data (404) (or encoded video bitstream), and the video picture stream (402) may be processed by an electronic device (420) that includes a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination of hardware and software to implement or implement various aspects of the disclosed subject matter as described in more detail below. Compared to the video picture stream (402), the encoded video data (404) (or the encoded video bitstream (404)) is depicted as a thin line to emphasize its lower data volume, and the encoded video data 404 can be stored on the streaming server (405) for future use. One or more streaming client subsystems, such as Figure 4 The client subsystem (406) and the client subsystem (408) in the streaming server (405) can access the streaming server (405) to retrieve the copy (407) of the encoded video data (404) and the copy (409) of the encoded video data (404). The client subsystem (406) may include, for example, a video decoder (410) in the electronic device (430). The video decoder (410) decodes the incoming copy (407) of the encoded video data and generates an output video picture stream (411) that can be rendered / presented on a display (412) (e.g., a display screen) or another rendering device (not depicted). In some streaming systems, the encoded video data (404), the copy (407) of the encoded video data, and the copy (409) of the encoded video data (e.g., a video bitstream) can be encoded according to certain video codec / compression standards. Examples of these standards include ITU-T Recommendation H.265. In one example, the video codec standard under development is informally referred to as Versatile Video Coding (VVC). The disclosed subject matter may be used in the context of the VVC standard.

[0056] It should be noted that the electronic device (420) and the electronic device (430) may include other components (not shown). For example, the electronic device (420) may include a video decoder (not shown), and the electronic device (430) may also include a video encoder (not shown).

[0057] Figure 5is a block diagram of a video decoder (510) according to an embodiment of the present disclosure. The video decoder (510) may be provided in an electronic device (530). The electronic device (530) may include a receiver (531) (e.g., a receiving circuit). The video decoder (510) may be used to replace Figure 4 A video decoder (410) is shown in an example.

[0058] The receiver (531) may receive one or more encoded video sequences to be decoded by the video decoder (510); in the same or another embodiment, one encoded video sequence is received at a time, wherein the decoding of each encoded video sequence is independent of the other encoded video sequences. The encoded video sequence may be received from a channel (501), which may be a hardware / software link to a storage device storing the encoded video data. The receiver (531) may receive the encoded video data as well as other data, such as encoded audio data and / or auxiliary data streams that may be forwarded to their respective consuming entities (not shown). The receiver (531) may separate the encoded video sequence from the other data. To prevent network jitter, a buffer memory (515) may be coupled between the receiver (531) and the entropy decoder / parser (520) (hereinafter referred to as "parser (520)"). In some applications, the buffer memory (515) is part of the video decoder (510). In other cases, the buffer memory (515) may be provided external to the video decoder (510) (not shown). In other cases, a buffer memory (not shown) is provided outside the video decoder (510) to prevent network jitter, for example, and another buffer memory (515) may be configured inside the video decoder (510) to handle broadcast timing, for example. When the receiver (531) receives data from a storage / forward device with sufficient bandwidth and controllability or from an isochronous network, it may not be necessary to configure the buffer memory (515), or the buffer memory may be made smaller. Of course, in order to use on a service packet network such as the Internet, a buffer memory (515) may also be required, which may be relatively large and have an adaptive size, and may be at least partially implemented in an operating system or a similar element (not shown) outside the video decoder (510).

[0059] The video decoder (510) may include a parser (520) to reconstruct symbols (521) from the encoded video sequence. The categories of these symbols include information for managing the operation of the video decoder (510) and potential information for controlling a presentation device such as a presentation device (512) (e.g., a display screen) that is not part of the electronic device (530) but can be coupled to the electronic device (530), such as Figure 5As shown in . The control information for the presentation device may be a parameter set fragment (not indicated) of Supplemental Enhancement Information (SEI message) or Video Usability Information (VUI). The parser (520) may parse / entropy decode the received coded video sequence. The encoding of the coded video sequence may be performed according to a video coding technique or standard, and may follow various principles, including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, and the like. The parser (520) may extract a subgroup parameter set for at least one subgroup of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to the group. The subgroup may include a Group of Pictures (GOP), a picture, a tile, a slice, a macroblock, a Coding Unit (CU), a block, a Transform Unit (TU), a Prediction Unit (PU), and the like. The parser (520) may also extract information such as transform coefficients, quantizer parameter values, motion vectors, etc. from the encoded video sequence.

[0060] The parser (520) may perform entropy decoding / parsing operations on the video sequence received from the buffer memory (515), thereby creating symbols (521).

[0061] Depending on the type of coded video picture or portion of coded video picture (e.g., inter- and intra-pictures, inter- and intra-blocks) and other factors, the reconstruction of the symbol (521) may involve multiple different units. Which units are involved and how they are involved may be controlled by subgroup control information parsed by the parser (520) from the coded video sequence. For the sake of brevity, such subgroup control information flow between the parser (520) and the multiple units below is not described.

[0062] In addition to the functional blocks already mentioned, the video decoder (510) can be conceptually subdivided into several functional units as described below. In a practical implementation operating under commercial constraints, many of these units interact closely with each other and may be at least partially integrated with each other. However, for the purpose of describing the disclosed subject matter, the conceptual subdivision into the following functional units is appropriate.

[0063] The first unit is a sealer / inverse transform unit (551). The sealer / inverse transform unit (551) receives quantized transform coefficients as symbols (521) from the parser (520) and control information, including which transform method to use, block size, quantization factor, quantization scaling matrix, etc. The sealer / inverse transform unit (551) can output blocks including sample values, which can be input into the aggregator (555).

[0064] In some cases, the output samples of the scaler / inverse transform unit (551) may belong to an intra-coded block; that is, a block that does not use predictive information from a previously reconstructed picture, but may use predictive information from a previously reconstructed portion of the current picture. Such predictive information may be provided by an intra-picture prediction unit (552). In some cases, the intra-picture prediction unit (552) generates a block of the same size and shape as the block being reconstructed using surrounding reconstructed information extracted from a current picture buffer (558). For example, the current picture buffer (558) buffers a partially reconstructed current picture and / or a fully reconstructed current picture. In some cases, the aggregator (555) adds the prediction information generated by the intra-prediction unit (552) to the output sample information provided by the scaler / inverse transform unit (551) on a per-sample basis.

[0065] In other cases, the output samples of the scaler / inverse transform unit (551) may belong to an inter-frame coded and potentially motion compensated block. In this case, the motion compensated prediction unit (553) may access the reference picture memory (557) to extract samples for prediction. After the extracted samples are motion compensated according to the symbols (521) belonging to the block, these samples may be added to the output of the scaler / inverse transform unit (551) (in this case referred to as residual samples or residual signals) by the aggregator (555) to generate output sample information. The address in the reference picture memory (557) from which the motion compensated prediction unit (553) obtains the predicted samples may be controlled by a motion vector, and the motion vector is provided to the motion compensated prediction unit (553) in the form of a symbol (521), which may have, for example, an X component, a Y component, and a reference picture component. Motion compensation may also include interpolation of sample values ​​extracted from the reference picture memory (557) when using sub-sample accurate motion vectors, motion vector prediction mechanisms, and the like.

[0066] The output samples of the aggregator (555) may be employed by various loop filtering techniques in a loop filter unit (556). The video compression techniques may include in-loop filter techniques controlled by parameters included in the coded video sequence (also referred to as the coded video bitstream) and available to the loop filter unit (556) as symbols (521) from the parser (520). However, in other embodiments, the video compression techniques may also be responsive to meta-information obtained during decoding of a coded picture or a previous (in decoding order) portion of the coded video sequence, as well as to previously reconstructed and loop filtered sample values.

[0067] The output of the loop filter unit (556) may be a sample stream that may be output to a rendering device (512) and stored in a reference picture memory (557) for subsequent inter-picture prediction.

[0068] Once fully reconstructed, certain coded pictures may be used as reference pictures for future prediction. For example, once the coded picture corresponding to the current picture is fully reconstructed, and the coded picture is identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) may become part of the reference picture memory (557), and a new current picture buffer may be reallocated before starting to reconstruct a subsequent coded picture.

[0069] The video decoder (510) may perform decoding operations according to a predetermined video compression technique, such as in the ITU-T Recommendation H.265 standard. The coded video sequence may conform to the syntax specified by the video compression technique or standard used in the sense that the coded video sequence follows the syntax of the video compression technique or standard and the profile recorded in the video compression technique or standard. Specifically, the profile may select certain tools from all the tools available in the video compression technique or standard as the only tools available for use under the profile. For compliance, the complexity of the coded video sequence is also required to be within the range defined by the level of the video compression technique or standard. In some cases, the level limits the maximum picture size, the maximum frame rate, the maximum reconstruction sampling rate (measured in, for example, mega samples per second), the maximum reference picture size, etc. In some cases, the limits set by the level may be further limited by the Hypothetical Reference Decoder (HRD) specification and the metadata of the HRD buffer management signaled in the coded video sequence.

[0070] In an embodiment, the receiver (531) may receive additional (redundant) data along with the encoded video. The additional data may be part of the encoded video sequence. The additional data may be used by the video decoder (510) to properly decode the data and / or more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial or signal-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0071] Figure 6 6 is a block diagram of a video encoder (603) according to an embodiment of the present disclosure. The video encoder (603) is provided in an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmission circuit). The video encoder (603) can be used to replace Figure 4 The video encoder (403) in the example.

[0072] The video encoder (603) can be used to obtain the video source (601) (not Figure 6 In another example, the video source (601) is a part of the electronic device (620) to receive the video samples, and the video source can collect the video images to be encoded by the video encoder (603). In another example, the video source (601) is a part of the electronic device (620).

[0073] The video source (601) may provide a source video sequence in the form of a digital video sample stream to be encoded by the video encoder (603), which may have any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 Y CrCB, RGB, ...), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media service system, the video source (601) may be a storage device storing previously prepared videos. In a video conferencing system, the video source (601) may be a camera that captures local image information as a video sequence. The video data may be provided as a plurality of separate pictures that are given motion when viewed sequentially. The pictures themselves may be constructed as a spatial pixel array, where each pixel may include one or more samples depending on the sampling structure, color space, etc. used. The relationship between pixels and samples may be easily understood by those skilled in the art. The following description focuses on samples.

[0074] According to an embodiment, the video encoder (603) may encode and compress pictures of a source video sequence into an encoded video sequence (643) in real time or under any other time constraints required by the application. Implementing an appropriate encoding speed is a function of the controller (650). In some embodiments, the controller (650) controls other functional units as described below and is functionally coupled to these units. For the sake of simplicity, couplings are not shown in the figure. The parameters set by the controller (650) may include rate control related parameters (picture skip, quantizer, lambda value of rate distortion optimization technology, etc.), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. The controller (650) can be used to have other suitable functions that are related to the video encoder (603) optimized for a certain system design.

[0075] In some embodiments, the video encoder (603) operates in an encoding loop. As a simple description, in one example, the encoding loop may include a source encoder (630) (e.g., responsible for creating symbols, such as a symbol stream, based on an input picture to be encoded and a reference picture) and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to create sample data in a manner similar to that of the (remote) decoder to create sample data (because in the video compression techniques considered in this application, any compression between the symbols and the encoded video bitstream is lossless). The reconstructed sample stream (sample data) is input to a reference picture memory (634). Since the decoding of the symbol stream produces bit-accurate results that are independent of the decoder location (local or remote), the contents of the reference picture memory (634) are also bit-accurately corresponding between the local encoder and the remote encoder. In other words, the reference picture samples "seen" by the prediction part of the encoder are exactly the same as the sample values ​​that the decoder will "see" when using the prediction during decoding. This basic principle of reference picture synchronization (and the drift that occurs when synchronization cannot be maintained, eg due to channel errors) is also used in some related techniques.

[0076] The operation of the "local" decoder (633) can be combined with the above Figure 5 The "remote" decoder of the video decoder (510) described in detail is identical. However, additional brief reference is made to Figure 5 , when symbols are available and the entropy encoder (645) and parser (520) are capable of losslessly encoding / decoding the symbols into an encoded video sequence, the entropy decoding portion of the video decoder (510), including the buffer memory (515) and the parser (520), may not be fully implemented in the local decoder (633).

[0077] At this point, it can be observed that any decoder technology other than the parsing / entropy decoding present in the decoder must also be present in the corresponding encoder in substantially the same functional form. For this reason, the disclosed subject matter focuses on the decoder operation. The description of encoder technology can be simplified because encoder technology is mutually inverse to the decoder technology described comprehensively. A more detailed description is only needed in certain areas and is provided below.

[0078] During operation, in some examples, the source encoder (630) may perform motion compensated predictive coding. Motion compensated predictive coding predictively encodes an input picture with reference to one or more previously encoded pictures from a video sequence designated as "reference pictures." In this manner, the encoding engine (632) encodes the differences between pixel blocks of the input picture and pixel blocks of a reference picture that may be selected as a prediction reference for the input picture.

[0079] The local video decoder (633) may decode the encoded video data of the picture that may be designated as the reference picture based on the symbol created by the source encoder (630). The operation of the encoding engine (632) may be a lossy process. When the encoded video data is available at the video decoder ( Figure 6 When the video sequence is decoded at a remote location (not shown), the reconstructed video sequence may typically be a copy of the source video sequence with some errors. The local video decoder (633) replicates the decoding process that may be performed by the video decoder on the reference picture and may cause the reconstructed reference picture to be stored in the reference picture cache (634). In this way, the video encoder (603) may locally store a copy of the reconstructed reference picture that has common content (absent transmission errors) with the reconstructed reference picture that will be obtained by the remote video decoder.

[0080] The predictor (635) may perform a prediction search for the encoding engine (632). That is, for a new picture to be encoded, the predictor (635) may search the reference picture memory (634) for sample data (as candidate reference pixel blocks) or certain metadata, such as reference picture motion vectors, block shapes, etc., that may serve as appropriate prediction references for the new picture. The predictor (635) may operate pixel-by-pixel based on sample blocks to find a suitable prediction reference. In some cases, based on the search results obtained by the predictor (635), it may be determined that the input picture may have prediction references taken from a plurality of reference pictures stored in the reference picture memory (634).

[0081] The controller (650) may manage encoding operations of the source encoder (630), including, for example, setting parameters and subgroup parameters for encoding video data.

[0082] The outputs of all the above functional units may be entropy encoded in an entropy encoder (645). The entropy encoder (645) performs lossless compression on the symbols generated by the various functional units according to techniques such as Huffman coding, variable length coding, arithmetic coding, etc., thereby converting these symbols into a coded video sequence.

[0083] The transmitter (640) may buffer the encoded video sequence created by the entropy encoder (645) in preparation for transmission over a communication channel (660), which may be a hardware / software link to a storage device where the encoded video data will be stored. The transmitter (640) may combine the encoded video data from the video encoder (603) with other data to be transmitted, such as encoded audio data and / or ancillary data streams (source not shown).

[0084] The controller (650) may manage the operation of the video encoder (603). During encoding, the controller (650) may assign a certain coded picture type to each coded picture, but this may affect the coding techniques that can be applied to the corresponding picture. For example, a picture may generally be assigned to any of the following picture types:

[0085] An intra picture (I picture) may be a picture that can be encoded and decoded without using any other picture in the sequence as a prediction source. Some video codecs allow different types of intra pictures, including, for example, Independent Decoder Refresh ("IDR") pictures. Those skilled in the art are aware of the variations of I pictures and their corresponding applications and features.

[0086] A predictive picture (P picture) may be a picture that can be encoded and decoded using intra prediction or inter prediction, which uses at most one motion vector and a reference index to predict sample values ​​for each block.

[0087] Bidirectional predictive pictures (B pictures), which can be pictures that can be encoded and decoded using intra prediction or inter prediction, which uses up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predictive pictures can use more than two reference pictures and associated metadata for reconstructing a single block.

[0088] The source picture may typically be spatially subdivided into blocks of samples (e.g., blocks of 4×4, 8×8, 4×8, or 16×16 samples), and encoded block by block. These blocks may be predictively encoded with reference to other (already encoded) blocks, which may be determined by the coding allocation applied to the block's corresponding picture. For example, a block of an I picture may be non-predictively encoded, or the block may be predictively encoded (spatial prediction or intra-frame prediction) with reference to an already encoded block of the same picture. A block of a P picture may be predictively encoded by spatial prediction with reference to one previously encoded reference picture or by temporal prediction. A block of a B picture may be predictively encoded by spatial prediction with reference to one or two previously encoded reference pictures or by temporal prediction.

[0089] The video encoder (603) may perform encoding operations according to a predetermined video encoding technique or standard, such as ITU-T Recommendation H.265. In operation, the video encoder (603) may perform various compression operations, including predictive encoding operations that exploit temporal and spatial redundancy in an input video sequence. Thus, the encoded video data may conform to the syntax specified by the video encoding technique or standard used.

[0090] In one embodiment, the transmitter (640) may transmit additional data when transmitting the encoded video. The source encoder (630) may include such data as part of the encoded video sequence. The additional data may include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0091] The captured video may be taken as a plurality of source pictures (video pictures) in a temporal sequence. Intra-picture prediction (often simplified to intra-prediction) exploits spatial correlations in a given picture, while inter-picture prediction exploits (temporal or other) correlations between pictures. In one example, a particular picture being encoded / decoded is divided into blocks, and the particular picture being encoded / decoded is referred to as the current picture. When a block in the current picture is similar to a reference block in a reference picture that was previously encoded in the video and is still buffered, the block in the current picture may be encoded by a vector called a motion vector. The motion vector points to a reference block in a reference picture, and in the case where multiple reference pictures are used, the motion vector may have a third dimension that identifies the reference picture.

[0092] In some embodiments, bidirectional prediction techniques may be used in inter-picture prediction. According to the bidirectional prediction technique, two reference pictures are used, for example, a first reference picture and a second reference picture that are both before the current picture in the video in decoding order (but may be in the past and future in display order, respectively). A block in the current picture may be encoded by a first motion vector pointing to a first reference block in the first reference picture and a second motion vector pointing to a second reference block in the second reference picture. The block may be predicted by a combination of the first reference block and the second reference block.

[0093] In addition, merge mode technology can be used in inter-picture prediction to improve encoding and decoding efficiency.

[0094] According to some embodiments of the present disclosure, predictions such as inter-picture prediction and intra-picture prediction are performed in units of blocks. For example, according to the HEVC standard, a picture in a video picture sequence is divided into coding tree units (CTUs) for compression, and the CTUs in the picture have the same size, such as 64×64 pixels, 32×32 pixels, or 16×16 pixels. In general, a CTU includes three coding tree blocks (CTBs), which are a luminance CTB and two chrominance CTBs. Each CTU can be recursively split into one or more coding units (CUs) using a quadtree. For example, a 64×64 pixel CTU can be split into a 64×64 pixel CU, or 4 32×32 pixel CUs, or 16 16×16 pixel CUs. In one example, each CU is analyzed to determine a prediction type for the CU, such as an inter-prediction type or an intra-prediction type. In addition, depending on temporal and / or spatial predictability, the CU is split into one or more prediction units (PUs). Typically, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, the prediction operation in the codec (encoding / decoding) is performed in units of prediction blocks. Taking the luma prediction block as an example, the prediction block includes a matrix of pixel values ​​(e.g., luma values), such as 8×8 pixels, 16×16 pixels, 8×16 pixels, 16×8 pixels, and the like.

[0095] Figure 7 1 is a diagram of a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) is configured to receive a processed block (e.g., a prediction block) of sample values ​​within a current video picture in a sequence of video pictures and encode the processed block into an encoded picture that is part of an encoded video sequence. In one example, the video encoder (703) is configured to replace Figure 4 The video encoder (403) in the example.

[0096] In the HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as a prediction block of 8×8 samples. The video encoder (703) uses, for example, rate-distortion (RD) optimization to determine whether to use intra mode, inter mode, or bidirectional prediction mode to best encode the processing block. When encoding the processing block in intra mode, the video encoder (703) may use intra prediction techniques to encode the processing block into an encoded picture; and when encoding the processing block in inter mode or bidirectional prediction mode, the video encoder (703) may use inter prediction or bidirectional prediction techniques to encode the processing block into an encoded picture, respectively. In some video codecs, the merge mode may be an inter-picture prediction submode, in which motion vectors are derived from one or more motion vector predictors without the aid of encoded motion vector components external to the predictor. In some other video codecs, there may be motion vector components applicable to the subject block. In one example, the video encoder (703) includes other components, such as a mode decision module (not shown) for determining the processing block mode.

[0097] exist Figure 7 In the example of FIG. 7 , the video encoder ( 703 ) includes Figure 7 Shown are an inter-frame encoder (730), an intra-frame encoder (722), a residual calculator (723), a switch (726), a residual encoder (724), a common controller (721), and an entropy encoder (725) coupled together.

[0098] The inter-frame encoder (730) is used to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks in a reference picture (e.g., blocks in a previous picture and a subsequent picture), generate inter-frame prediction information (e.g., redundant information description according to an inter-frame coding technique, motion vectors, merge mode information), and calculate an inter-frame prediction result (e.g., a predicted block) based on the inter-frame prediction information using any suitable technique. In some examples, the reference picture is a decoded reference picture decoded based on the encoded video information.

[0099] The intra-frame encoder (722) is used to receive samples of a current block (e.g., a processing block); in some cases, compare the block with an encoded block in the same picture; generate quantization coefficients after transformation; and in some cases also generate intra-frame prediction information (e.g., intra-frame prediction direction information according to one or more intra-frame coding techniques). In one example, the intra-frame encoder (722) also calculates an intra-frame prediction result (e.g., a predicted block) based on the intra-frame prediction information and a reference block in the same picture.

[0100] The general controller (721) is used to determine general control data and control other components of the video encoder (703) based on the general control data. In one example, the general controller (721) determines the mode of the block and provides a control signal to the switch (726) based on the mode. For example, when the mode is intra mode, the general controller (721) controls the switch (726) to select the intra mode result for use by the residual calculator (723) and controls the entropy encoder (725) to select intra prediction information and add the intra prediction information to the bitstream; and when the mode is inter mode, the general controller (721) controls the switch (726) to select the inter prediction result for use by the residual calculator (723) and controls the entropy encoder (725) to select the inter prediction information and add the inter prediction information to the bitstream.

[0101] The residual calculator (723) is used to calculate the difference (residual data) between the received block and the prediction result selected from the intra-frame encoder (722) or the inter-frame encoder (730). The residual encoder (724) is used to operate based on the residual data to encode the residual data to generate a transform coefficient. In one example, the residual encoder (724) is used to convert the residual data from the spatial domain to the frequency domain and generate a transform coefficient. The transform coefficient is then subjected to a quantization process to obtain a quantized transform coefficient. In various embodiments, the video encoder (703) also includes a residual decoder (728). The residual decoder (728) is used to perform an inverse transform and generate decoded residual data. The decoded residual data can be appropriately used by the intra-frame encoder (722) and the inter-frame encoder (730). For example, the inter-frame encoder (730) can generate a decoded block based on the decoded residual data and the inter-frame prediction information, and the intra-frame encoder (722) can generate a decoded block based on the decoded residual data and the intra-frame prediction information. The decoded blocks are processed appropriately to generate a decoded picture, and in some examples, the decoded picture may be buffered in a memory circuit (not shown) and used as a reference picture.

[0102] The entropy encoder (725) is used to format the bitstream to include the encoded blocks. The entropy encoder (725) is configured to include various information according to a suitable standard such as the HEVC standard. In one example, the entropy encoder (725) is used to include (write) general control data, selected prediction information (e.g., intra-frame prediction information or inter-frame prediction information), residual information, and other suitable information in the bitstream. It should be noted that according to the disclosed subject matter, when the block is encoded in the merge sub-mode of the inter-frame mode or the bidirectional prediction mode, there is no residual information.

[0103] Figure 8FIG. 8 is a diagram of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is used to receive an encoded picture as part of an encoded video sequence and decode the encoded picture to generate a reconstructed picture. In one example, the video decoder (810) is used to replace Figure 4 A video decoder (510) is shown in an example.

[0104] exist Figure 8 In the example of FIG. 8 , the video decoder ( 810 ) includes Figure 8 The entropy decoder (871), inter-frame decoder (880), residual decoder (873), reconstruction module (874) and intra-frame decoder (872) coupled together are shown in FIG.

[0105] The entropy decoder (871) can be used to reconstruct certain symbols from the encoded picture, which represent syntax elements that constitute the encoded picture. Such symbols may include, for example, a mode for encoding a block (e.g., intra-frame mode, inter-frame mode, bidirectional prediction mode, a merged sub-mode of the latter two, or another sub-mode), prediction information (e.g., intra-frame prediction information or inter-frame prediction information) that can identify certain samples or metadata for prediction by the intra-frame decoder (872) or the inter-frame decoder (880), respectively, residual information in the form of, for example, quantized transform coefficients, and the like. In one example, when the prediction mode is an inter-frame prediction mode or a bidirectional prediction mode, the inter-frame prediction information is provided to the inter-frame decoder (880); and when the prediction type is an intra-frame prediction type, the intra-frame prediction information is provided to the intra-frame decoder (872). The residual information may be subjected to inverse quantization and provided to the residual decoder (873).

[0106] The inter-frame decoder (880) is used to receive the inter-frame prediction information and generate an inter-frame prediction result based on the inter-frame prediction information.

[0107] The intra-frame decoder (872) is used to receive intra-frame prediction information and generate a prediction result based on the intra-frame prediction information.

[0108] The residual decoder (873) is used to perform inverse quantization to extract dequantized transform coefficients, and process the dequantized transform coefficients to convert the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require some control information (to obtain the quantizer parameter QP), and this information can be provided by the entropy decoder (871) (the data path is not indicated because this is only low-volume control information).

[0109] The reconstruction module (874) is used to combine the residual output by the residual decoder (873) with the prediction result (which can be output by the inter-frame prediction module or the intra-frame prediction module according to the specific situation) in the spatial domain to form a reconstructed block, which can be part of a reconstructed picture, which in turn can be part of a reconstructed video. It should be noted that other suitable operations such as deblocking operations can be performed to improve visual quality.

[0110] It should be noted that the video encoder (403), video encoder (603) and video encoder (703) and video decoder (410), video decoder (510) and video decoder (810) may be implemented using any suitable technology. In one embodiment, the video encoder (403), video encoder (603) and video encoder (703) and video decoder (410), video decoder (510) and video decoder (810) may be implemented using one or more integrated circuits. In another embodiment, the video encoder (403), video encoder (603) and video encoder (703) and video decoder (410), video decoder (510) and video decoder (810) may be implemented using one or more processors that execute software instructions.

[0111] Aspects of the present disclosure provide control techniques for encoding tools and functionality with constraint flags in encoded video streams.

[0112] According to one aspect of the present disclosure, the picture size in a bitstream may remain constant or may change. In some related examples, a video encoder and decoder may operate on a given picture size that is defined and kept constant for a coded video sequence (CVS), a group of pictures (GOP), or a similar multi-picture time frame. In one example, for example in MPEG-2, it is known that system designs may change the horizontal resolution (and thus the picture size) based on factors such as the activity of a scene, but only at I pictures, so the picture size is defined and usually kept constant for a GOP. For example, according to Annex P of ITU-T Recommendation H.263, resampling of reference pictures using different resolutions within a CVS is known. However, the picture size in the CVS does not change, only the reference pictures are resampled, which may result in only part of the picture canvas being used (e.g., in the case of downsampling), or only part of the scene being captured (e.g., in the case of upsampling). In some examples, for example in Annex Q of H.263, it is allowed to resample a single macroblock by a factor of 2 in each dimension (e.g., up or down). However, the picture size remains unchanged. When the size of the macroblock can be fixed as in H.263, there is no need to signal the size of the macroblock.

[0113] In some related examples, the picture size in the predicted picture can be changed. In examples such as VP9, ​​resampling of reference pictures and changing the resolution of the entire picture are allowed. In some examples (e.g., Hendry et al., "On adaptive resolution change (ARC) for VVC", Video Joint Working Group document JVET-M0135-v1, Jan9-19, 2019, (Hendry, et.al,"On adaptive resolution change (ARC) for VVC", Joint Video Team document JVET-M0l35-vl, Jan 9-l9, 20l9), the entire contents of which are included in this article), the entire reference picture is allowed to be resampled to a different resolution (e.g., higher resolution or lower resolution). Different candidate resolutions can be encoded in a sequence parameter set (SPS) and can be referenced by each picture syntax element in a picture parameter set (PPS).

[0114] According to one aspect of the present disclosure, a source video may be compressed by layered coding, which may encode a picture into a bitstream including one or more layers with different qualities (e.g., different resolutions). The bitstream may have syntax elements that specify which layers (or which layer set) may be output on the decoder side. The layer set to be output may be defined as an output layer set. For example, in a video codec that supports multiple layers and scalability, one or more output layer sets may be signaled in a video parameter set (VPS). Syntax elements that specify the profile, grade, and level (PTL) of the entire bitstream or one or more output layer sets may be signaled in messages such as VPS, decoder parameter sets (DPS), SPS, PPS, SEI messages, etc. In the PTL information, there may be general constraint information that can specify constraints on coding tools or functions. It is desirable to efficiently represent and signal constraint information for various coding tools and functions.

[0115] In some examples, the term "sub-picture" may be used to refer to a rectangular arrangement of entities (e.g., samples, blocks, macroblocks, coding units, or similar entities) that are semantically grouped and can be independently encoded at varying resolutions. One or more sub-pictures may form a picture. One or more encoded sub-pictures may form a coded picture. One or more sub-pictures may be combined into a picture, and one or more sub-pictures may be extracted from a picture. In some examples, one or more encoded sub-pictures may be combined into a coded picture in a compressed domain without transcoding them to a sampling level. In some examples, one or more encoded sub-pictures may be extracted from a coded picture in a compressed domain.

[0116] In some examples, a mechanism that allows the resolution of a picture or sub-picture in a CVS to be changed by, for example, resampling a reference picture may be referred to as adaptive resolution change (ARC). The control information used to perform adaptive resolution change may be referred to as ARC parameters. ARC parameters may include filter parameters, scaling factors, output resolution and / or resolution of reference pictures, various control flags, etc.

[0117] In some examples, ARC encoding / decoding is per picture, so a set of control information (ARC parameters) is used to encode / decode a single and semantically independent coded video picture. In some examples, ARC encoding / decoding is per sub-picture, so independent ARC parameters can be used to encode / decode multiple sub-pictures in a picture. It should be noted that various techniques can be used to signal ARC parameters.

[0118] Fig. 9 Examples (e.g., options) of techniques for signaling ARC parameters according to some embodiments of the present disclosure are shown. Coding efficiency, complexity, and architecture may vary from example to example. A video codec standard or technology may select one or more examples or other variants to signal ARC parameters. These examples may not be mutually exclusive and may be interchangeable based on application requirements, standard technology, selection of encoders, etc.

[0119] According to one aspect of the present disclosure, ARC parameters can be provided as categories of ARC parameters in various ways. In some examples, a class of ARC parameters includes upsampling factors and / or downsampling factors separated or combined in the X dimension and the Y dimension. In one example, one or more short syntax elements that can point to a table including upsampling factors and / or downsampling factors can be encoded.

[0120] In some examples, a class of ARC parameters includes an upsampling factor and / or a downsampling factor, and adds a time dimension to indicate a constant rate of zooming in and / or zooming out of a given number of pictures. In one example, one or more short syntax elements that can point to a table including an upsampling factor and / or a downsampling factor with an added time dimension can be encoded.

[0121] In some examples, a class of ARC parameters includes a resolution in a combined or separate X or Y dimension in an input picture, an output picture, a reference picture, an encoded picture, in units of samples, blocks, macroblocks, CUs, or any other suitable granularity. In some examples, more than one resolution is used in a video codec (e.g., one for an input picture and another for a reference picture), and another set of values ​​(corresponding to another resolution) can be inferred from one set of values ​​(corresponding to one resolution). For example, the determination of a value can be gated based on the use of a flag. The use of a flag for gating will be described in detail in the further description.

[0122] In some examples, a class of ARC parameters includes warping coordinates similar to those used in Annex P of H.263, and having an appropriate granularity as described above. H.263 Annex P defines an efficient method for encoding warping coordinates. Other efficient methods may also be designed. For example, the variable-length reversible Huffman encoding of the warping coordinates in Annex P may be replaced with an appropriate-length binary encoding, where the length of the binary codeword can be derived from the maximum picture size: the maximum picture size is multiplied by a factor and offset by a value to allow warping outside the boundaries of the maximum picture size.

[0123] In some examples, a class of ARC parameters includes up-sampling and / or down-sampling filter parameters. In one example, there is only a single filter for up-sampling and / or down-sampling. In another example, multiple filters can be used. In some examples, filter parameters can be sent with a signal to allow greater flexibility in filter design. Filter parameters can be selected by using an index in a list of possible filter designs. The filter can be completely specified (e.g., by specifying a list of filter coefficients using appropriate entropy coding techniques), the filter can be implicitly selected by using an up-sampling ratio or a down-sampling ratio sent by a signal according to any of the above mechanisms, etc.

[0124] In the following description, a finite set of upsampling factors or downsampling factors (using the same factors in both the X and Y dimensions) is used to illustrate signaling ARC parameters via codewords. In some examples, the codewords may be variable length coded, for example, using Ext-Golomb codes of certain syntax elements in video codec specifications (e.g., H.264 and H.265).

[0125] Fig.10 An example of a table (1000) for mapping up-sampling factors or down-sampling factors, codewords, and Ext-Golomb codes is shown.

[0126] It should be noted that other similar mappings can be designed based on the application and capabilities of the upscaling and downscaling mechanisms available in the video compression technology or standard. In some examples, Table 1 can be appropriately extended to additional values. It should be noted that the values ​​can be represented by entropy coding mechanisms other than Ext-Golomb codes, for example, by using binary encoding. In one example, when, for example, a media-aware network element (MANE) is interested in the resampling factor outside the video processing engine (e.g., encoder and decoder), entropy coding mechanisms other than Ext-Golomb codes can have certain advantages. In some examples, when no resolution change is required (e.g., the original / target resolution in Table 1 is 1), a short Ext-Golomb code (e.g., only a single bit as shown in Table 1) can be selected, which can have a codec efficiency advantage compared to, for example, the most common use of binary codes.

[0127] According to one aspect of the present disclosure, a mapping table (e.g., Table 1) may be configurable. For example, the number of entries in Table 1 and the corresponding semantics may be fully or partially configurable. In some examples, the basic outline of the mapping table is transmitted in a high-level parameter set such as an SPS or DPS. Alternatively or additionally, in some examples, one or more tables similar to Table 1 may be defined in a video coding technique or standard, and one of the tables may be selected, for example, by an SPS or a DPS.

[0128] ARC information such as the upsampling factor or downsampling factor encoded as described above may be included in the video codec technique or standard syntax. It should be noted that one or more codewords may be used to control other categories of ARC information, such as upsampling filters or downsampling filters. In some examples, filters or other data structures require relatively large amounts of data.

[0129] refer to Fig. 9 In example (910), for example, in Annex P of H.263, the ARC information (912) may be in the form of four warp coordinates and included in a picture header (911), for example, in an H.263PLUSPTYPE (913) header extension. Example (910) may be applied when i) a picture header is available, and ii) the ARC information is expected to change frequently. However, as shown in example (910), when H.263-style signaling is used, the overhead may be high and the scaling factor may not be applicable across picture boundaries because the picture header may have a transient nature.

[0130] refer to Fig. 9In example (920), such as in JVCET-M135-v1, ARC reference information (925) (e.g., an index) may be placed in a PPS (924) and may point to a table (or target resolution table) (926) that includes target resolutions (e.g., resolutions 1-3). In one example, the table (926) is located inside an SPS (927). By using the SPS as an interoperability negotiation point during performance exchange, it may be justified to place the target resolution in the table (926) in the SPS (927). By reference (e.g., ARC reference information (925)) in the appropriate PPS (924), the resolution may be changed from one picture to another within a limited set of values ​​(e.g., resolutions 1-3) in the table (926).

[0131] Fig. 9 Additional techniques that can be used to transmit ARC information in a video bitstream are also shown, such as example (930), example (940), and example (950). These techniques can be used alone or in appropriate combinations in the same video codec technology or standard.

[0132] refer to Fig. 9 In the example (930), ARC information (939), such as a resampling factor (or scaling factor), may be present in a header such as a slice header, a GOB header, a block header, a block group header, etc. For example, Fig. 9 The tile group header (938) is illustrated in the example. The technique illustrated in the example (930) can be used when the ARC information (939) can be encoded with a small number of bits (e.g., a single variable length ue(v) or a fixed length codeword of a few bits).

[0133] According to one aspect of the present disclosure, in a header (e.g., Fig. 9 Having ARC information (939) directly in a tile group header (938), slice header, or tile header in the video may have additional advantages because the ARC information (939) may apply to, for example, a sub-picture represented by the corresponding tile group (or slice, tile), rather than the entire picture. In addition, in an example, even if the video compression technology or standard only envisions adaptive resolution changes for the entire picture / picture (as opposed to, for example, adaptive resolution changes based on tile groups), example (930) may have certain advantages over example (910) from an error recovery (tolerance) perspective.

[0134] refer to Fig. 9In the example (940), the ARC information (942) may be present in a parameter set (941), such as a PPS, a header parameter set, a block parameter set, an adaptation parameter set (APS), etc. For example, Fig. 9 APS (941) is illustrated in FIG. In some examples, the scope of parameter set (941) may not be larger than a picture, for example, it may be a picture, a partition group, etc. The use of ARC information (e.g., ARC information (942)) may be implied by activating the relevant parameter set (e.g., APS (941)). For example, when the video codec technology or standard only considers picture-based ARC, PPS or equivalent may be appropriate.

[0135] refer to Fig. 9 In the example (950), the ARC reference information (953) may be presented in a partition group header (954) or a similar data structure (eg, a picture header, a slice header, a partition header, or a GOP header) as described above. Fig. 9 The partition group header (954) is illustrated as an example in ARC reference information (953) may refer to a subset of ARC information (955) available in a parameter set (956) having a scope beyond a single picture, such as SPS, DPS, etc. Fig. 9 SPS (956) is illustrated in FIG. 9 as an example.

[0136] Fig.11 Some examples of ARC parameter signaling according to some embodiments of the present disclosure are shown. Fig.11 An example of a syntax diagram used in a video codec standard is shown. In one example, the notation of the syntax diagram roughly follows C-style programming. Bold lines may indicate syntax elements present in the bitstream, while non-bold lines may indicate control flow or variable settings.

[0137] refer to Fig.11, the tile group header (1101) includes a syntax structure of a header that is applicable to a partial picture (e.g., a rectangular portion). In one example, the tile group header (1101) may conditionally include a variable length Exp-Golomb coded syntax element dec_pic_size_idx (1102) (depicted in bold). The presence of a syntax element (e.g., dec_pic_size_idx (1102)) in the tile group header (1101) may be enabled based on, for example, an adaptive resolution represented by a flag (e.g., adaptive_pic_resolution_change_flag) (1103). The value of the flag (e.g., adaptive_pic_resolution_change_flag) (1103) is not delineated in bold, so the flag is presented in the bitstream at the point where the flag appears in the syntax diagram. Whether adaptive resolution is used for a picture or a partial picture may be determined in a high-level syntax structure (e.g., internal or external to the bitstream). Fig.11 The SPS (1110) is notified by signal.

[0138] refer to Fig.11 , shows an excerpt about an SPS (1110). The SPS (1110) includes a first syntax element (1111), which is a flag (1111) (e.g., adaptive_pic_resolution_change_flag). When the flag (1111) is true, the flag (1111) may indicate the use of adaptive resolution, which may require specific control information. In one example, the specific control information is conditionally present based on the value of the flag (1111) shown by the conditional statement (1112) in the SPS (1110) and the tile group header (1101).

[0139] When using adaptive resolution, e.g. Fig.11As shown in the example in , the output resolution (or the resolution of the output picture) (1113) in units of samples can be encoded. In one example, the output resolution (1113) is encoded based on the width resolution (e.g., output_pic_width_in_luma_samples) and the height resolution (e.g., output_pic_height_in_luma_samples). In the video codec technology or standard, certain restrictions on the value of the output resolution (1113) can be defined. For example, the level definition can limit the number of total output samples (e.g., the product of output_pic_width_in_luma_samples and output_pic_height_in_luma_samples). In some examples, the video codec technology or standard, or an external technology or standard (e.g., a system standard) can limit the numerical range of the width resolution and / or the height resolution (e.g., the width resolution and / or the height resolution can be divided by a power of 2), the aspect ratio of the width resolution to the height resolution (e.g., the ratio of the width resolution to the height resolution is 4:3 or 16:9), etc. In one example, the above restrictions may be introduced to facilitate hardware implementation.

[0140] In some applications, the encoder can instruct the decoder to use a specific reference picture size, rather than implicitly assuming the size as the output picture size. For example, a syntax element (e.g., reference_pic_size_present_flag) (1114) gates conditional presentation of reference picture dimensions (1115). In one example, the reference picture dimensions (1115) can include width (e.g., reference_pic_width_in_luma_samples) and height (e.g., reference_pic_height_in_luma_samples).

[0141] Also in Fig.11 , a table of applicable decoded picture widths and heights is shown. In one example, the number of entries in the table may be indicated by a table indication (e.g., a syntax element num_dec_pic_size_in_luma_samples_minus1) (1116). "Minus1" may refer to the interpretation of the value of the syntax element (1116). For example, if the encoded value is zero, one table entry is present. If the encoded value is 5, six table entries are present. For each entry in the table, a syntax element (1117) includes the decoded picture width and height.

[0142] The syntax element dec_pic_size_idx (1102) in the partition group header (1101) may be used to index the table entry represented by the syntax element (1117), thereby allowing each partition group to have a different decoding size and scaling factor.

[0143] According to one aspect of the present disclosure, certain video codecs or standards (e.g., VP9) may enable spatial scalability by implementing certain forms of reference picture resampling in conjunction with temporal scalability. In one embodiment, reference pictures are upsampled to a higher resolution using ARC-style techniques to form a basis for a spatial enhancement layer. Normal prediction mechanisms at high resolution (e.g., motion compensated prediction for inter-frame prediction based on reference pictures) may be used to modify the upsampled pictures, such as to add details.

[0144] In some examples, values ​​in a network abstraction layer (NAL) unit header, such as a time ID field, are used to indicate time layer information as well as spatial layer information. Using values ​​in the NAL unit header to indicate time layer information and spatial layer information can enable an existing selected forwarding unit (SFU) to be used in a scalable environment without modification. For example, an existing SFU can be created and optimized for forwarding selected for a time layer based on the NAL unit header time ID value. Then, in some examples, the existing SFU can be used for spatial scalability (e.g., selection of a spatial layer) without modification. In some examples, a mapping can be provided between a coded picture size and a time layer indicated by a time ID field in a NAL unit header.

[0145] According to one aspect of the present disclosure, profile, level, and general constraint information including profile, grade, level (PTL) combination information can be used to specify some characteristics of the encoded bitstream. In some examples, the profile defines a subset of characteristics of the bitstream, such as color reproduction, resolution, additional video compression, etc. The video codec can define various profiles, such as a baseline profile (e.g., a simple profile with a low compression ratio), a high profile (a complex profile with a high compression ratio), a main profile (e.g., a profile with a medium compression ratio between the baseline profile and the high profile, which can be a default profile setting), etc.

[0146] In addition, grades and levels can be used to specify specific constraints that define a bitstream in terms of maximum bitrate, maximum brightness sampling rate, maximum brightness picture size, minimum compression ratio, maximum number of slices allowed, maximum number of blocks allowed, etc. Lower grades are more constrained than higher grades, and lower levels are more constrained than higher levels. In one example, a standard can define two grades: main grade and high grade. The main grade is a lower grade than the high grade. These grades are used to handle applications that differ in maximum bitrate. In one example, the main grade is designed for most applications, while the high grade is designed for applications with very high requirements. A standard can define multiple levels. A level is a set of constraints for a bitstream. In one example, for levels below level 4, only the main grade is allowed. In some examples, a decoder that is required to conform to a given grade / level is able to decode all bitstreams encoded for that grade / level and for all lower grades / levels.

[0147] The general constraint information may include constraint information about video source types, coding tools, and functions. For example, the constraint flag may indicate whether inter-frame coding tools, intra-frame coding tools, deblocking filters (DBF), entropy coding, transforms, partitions (e.g., blocks, slices), buffer management, random access (e.g., IDR), parameter sets (e.g., SPS, PPS), etc. are present or used in the encoded video bitstream. The constraint information may be signaled in a parameter set (e.g., SPS, VPS, or DCI). The constraint flag may be signaled in a high-level syntax structure (e.g., SPS, VPS, DCI).

[0148] According to some aspects of the present disclosure, PTL information may be associated with a range (e.g., a portion of the encoded video data in a bitstream). In some examples, PTL information may be specified for, for example, the entire bitstream, the CVS of the bitstream, each output layer set (OLS) in the bitstream, etc., and may be signaled in a high-level syntax (HLS) structure (e.g., VPS, DPS, DCI, SPS, PPS, APS, GOP, sequence, header, SEI message, etc.).

[0149] In some examples, the high-level syntax (HLS) is defined with respect to a block level. Block-level coding tools may be used to decode pixels or samples within a picture to reconstruct the picture. Block-level coding tools may include any suitable coding tools used in the reconstruction of a coding block, such as coding tools for inter-frame prediction (or inter-frame coding tools), coding tools for intra-frame prediction (or intra-frame coding tools), adaptive loop filters (ALF), deblocking filters (DBF), entropy coding, transforms, and the like.

[0150] The high-level syntax (HLS) may specify information about functionality, system interfaces, picture-level control of tools, buffer control, etc. For example, HLS may specify partitioning (e.g., tiles, slices, sub-pictures), buffer management, random access (e.g., IDR, clean random access (CRA)), parameter sets (e.g., VPS, SPS, PPS, APS), reference picture resampling (RPR), scalability, etc. The high-level syntax may be above the block level.

[0151] The control information may have a suitable level, such as SPS-level tool control information, PPS-level tool control information, sequence-level control information, bitstream-level control information, etc. In some examples, the PTL information is partial control information, which may be signaled as a constraint flag in the HLS structure, and may indicate control or constraint of a tool in a scope corresponding to the HLS structure. For example, a constraint flag of the PTL information may be provided in one of the sequence-level control information and the bitstream-level control information. In an example, if certain tools are disabled by a constraint flag in the HLS structure, then these tools are not used for coding blocks in, for example, a scope corresponding to the HLS.

[0152] Fig.12 and Fig.13 An example of PTL information according to some embodiments of the present disclosure is shown. Fig.12 An example of the syntax structure of a PTL syntax element set (1200) is shown, and Fig.13 An example of the syntax structure of general constraint information is shown (1300).

[0153] exist Fig.12In, the PTL syntax element set may include general_profile_idc, general_tier_flag, general_level_idc, num_sub_profiles, general_sub_profile_idc, sublayer_level_present_flag, ptl_alignment_zero_bit and sublayer_level_idc.

[0154] exist Fig.13 In the embodiment, the general constraint information may include multiple constraint flags. In one example, a constraint flag (e.g., intra_only_constraint_flag) (1305) equal to 1 can indicate that the parameter sh_slice_type should be I (i.e., the slice is an intra slice). The parameter sh_slice_type is a parameter in the slice header that specifies the encoding type of a slice between types I, P, and B. A constraint flag (e.g., intra_only_constraint_flag) (1305) equal to 0 does not impose a constraint (e.g., sh_slice_type should be I) on all coded pictures within the PTL information range, where other information (e.g., profile_idc) may allow non-intra slices. In another example, a constraint flag (e.g., no_alf_constraint_flag) (1306) equal to 1 can indicate that for all CVSs within the PTL information range, sps_alf_enabled_flag is equal to 0, and therefore adaptive loop filtering is not used even if adaptive loop filtering is allowed based on, for example, profile_idc. A constraint flag (eg, no_alf_constraint_flag) (1306) equal to 0 does not impose the above constraints.

[0155] In another example, Fig.13 As shown, a constraint flag (e.g., no_lossless_coding_tool_constraint_flag) (1301) may be signaled in the general constraint information. A constraint flag (e.g., no_lossless_coding_tool_constraint_flag) (1301) equal to 1 may indicate that coding tools related to lossless coding cannot be used within the PTL information scope including the constraint flag (1301). A constraint flag (e.g., no_lossless_coding_tool_constraint_flag) (1301) equal to 0 does not impose the above constraints.

[0156] In another example, Fig.13 As shown, a constraint flag (e.g., no_lossy_coding_tool_constraint_flag) (1302) can be signaled in the general constraint information. The constraint flag (e.g., no_lossy_coding_tool_constraint_flag) (1302) equal to 1 can indicate that coding tools related to lossy coding cannot be used within the PTL information scope including the constraint flag (1302). The constraint flag (e.g., no_lossy_coding_tool_constraint_flag) (1302) equal to 0 does not impose the above constraints.

[0157] In one embodiment, when the constraint flag (e.g., no_lossy_coding_tool_constraint_flag) (1302) is equal to 1, the constraint flag (e.g., no_lossless_coding_tool_constraint_flag) (1301) may not be equal to 1. Alternatively, when the constraint flag (e.g., no_lossless_coding_tool_constraint_flag) (1301) is equal to 1, the constraint flag (e.g., no_lossy_coding_tool_constraint_flag) (1302) may not be equal to 1.

[0158] Multiple constraint flags in the general constraint information can be sorted in a specific order. For example, the order can be set based on the possibility of not using each mechanism and / or tool within the scope of the PTL. This order can be called a priority order. This order can be presented from high priority to low priority in the general constraint information syntax structure, where the high priority indicates that the possibility of not using the tool (or mechanism) is high, and the low priority indicates that the possibility of not using the tool (or mechanism) is low. Additional factors that affect the order may include tools that may only be used for specific use cases (e.g., tools for sub-pictures, scalability, and / or interlaced (interlaced) support), the impact of the tool on encoder / decoder / implementation complexity, etc.

[0159] Figure 14A-14BAn example of PTL information including a syntax structure example (1410) of a PTL syntax structure (also referred to as a PTL bracket) and a syntax example (1420) of a general constraint information syntax structure (also referred to as a general constraint information bracket) according to some embodiments of the present disclosure is shown. In some examples, a syntax element indicating the number of constraint flags (e.g., num_available_constraint_flags) can be signaled. In one example, a syntax element indicating the number of constraint flags can be signaled in the PTL syntax structure (e.g., by Fig.14A , which may be outside of the syntax example (1420) for the general constraint information frame. Alternatively, a syntax element indicating the number of constraint flags may be signaled at the beginning of the general constraint information frame, such as the beginning of the syntax example (1420). When a syntax element (e.g., num_available_constraint_flags) is present and the value of the syntax element (e.g., num_availale_constraint_flags) is equal to N, the first N constraint flags may be present in the general constraint information syntax structure. Additionally, other constraint flags may not be present and may be inferred to be equal to a particular value. N may be a non-negative integer.

[0160] In one embodiment, the value N (e.g., num_available_constraint_flags) is in the range of 0 to the maximum number of constraint flags (e.g., the value of the parameter MaxNumConstraintFlags). The maximum number of constraint flags may be any positive integer. The value of the maximum number of constraint flags (e.g., MaxNumConstraintFlags) may be predefined as 16, 32, 64, or 128, etc. When the value N (e.g., num_available_constraint_flags) is equal to 0, the constraint flags are not present in the general constraint information syntax structure. The encoding of the value N (e.g., num_available_constraint_flags) may be selected so that the corresponding entropy coded representation of the value N and the constraint flags may add up to a number divisible by 8 to ensure byte alignment.

[0161] In some examples, the constraint flag can be classified into one or more constraint information groups. Each constraint information group may include one or more constraint flags and may have a corresponding gate flag. The gate flag of the corresponding constraint information group may indicate whether the constraint flag in the corresponding constraint information group can be presented. In one example, the gate flag may be referred to as a constraint group presentation flag. Typically, the gate flag is associated with the corresponding constraint information group and is associated with the constraint flag in the corresponding constraint information group. In one embodiment, the gate flag is gated for whether the constraint flag in the corresponding constraint information group is presented in the constraint information (or sent with a signal in the constraint information). For example, if the gate flag of the corresponding constraint information group is equal to 1, the constraint flag corresponding to the constraint information group may be presented in, for example, general constraint information. If the gate flag of the corresponding constraint information group is equal to 0, the constraint flag corresponding to the constraint information group is not presented in, for example, general constraint information. In one example, if all gate flags are equal to 0, the constraint flag is not presented.

[0162] The constraint flags may have different scopes. For example, the scope of the constraint flag in the DCI may be the coded video bitstream. The scope of the constraint flag in the VPS may be a CLVS with multiple layers. The scope of the constraint flag in the SPS may be a single CLVS.

[0163] Figure 15A-15B An example of a general constraint information syntax structure (1500) according to an embodiment of the present disclosure is shown. The general constraint information syntax structure (1500) includes a flag indicating the general constraint information. Specifically, the general constraint information syntax structure (1500) includes one or more gating flags, such as Fig.15AThe selection flag (e.g., general_frame_structure_constraint_group_flag) (1501), the selection flag (e.g., high_level_functionality_constraint_group_flag) (1502), the selection flag (e.g., scalability_constraint_group_flag) (1503), the selection flag (e.g., partitioning_constraint_group_flag) (1504), the selection flag (e.g., intra_coding_tool_constraint_group_flag) (1505), the selection flag (e.g., inter_coding_tool_constraint_group_flag) (1506), the selection flag (e.g., transfom_contraint_group_flag) (1507) and the selection flag (e.g., inloop_filtering_constraint_group_flag) (1508). Fig.15A As shown, one or more gating flags (eg, gating flag (1501) to gating flag (1508)) may be present at the beginning of the general constraint information syntax structure (1500).

[0164] The selection flag (e.g., general_frame_structure_constraint_group_flag) (1501) is associated with the constraint information group (1510) and is associated with the constraint flags (1511)-(1514) in the constraint information group (1510). The selection flag (e.g., general_frame_structure_constraint_group_flag) (1501) equal to 1 can specify that the constraint flags (1511)-(1514) in the constraint information group (1510) can be present.

[0165] The constraint information group (1510) (or constraint flags (1511)-(1514)) may be related to input sources and frame packing (eg, packing frames or projected frames). Fig.15A, the constraint flags (1511)-(1514) correspond to general_non_packed_constraint_flag (1511), general_frame_only_constraint_flag (1512), general_non_projected_constraint_flag (1513) and general_one_picture_only_constraint_flag (1514). Otherwise, a selection flag (e.g., general_frame_structure_constraint_group_flag) (1501) equal to 0 may specify that the constraint flags (1511)-(1514) in the constraint information group (1510) may not be present in the general constraint information syntax structure (1500).

[0166] Additionally, in some examples, a select flag (e.g., high_level_functionality_constraint_group_flag) (1502) equal to 1 may specify that a constraint flag in a constraint information group (1520) related to high-level functionality (e.g., reference picture resampling) may be present, such as Fig. 15B Otherwise, a gating flag (eg, high_level_functionality_constraint_group_flag) (1502) equal to 0 may specify that the constraint flags in the constraint information group (1520) may not be present in the general constraint information syntax structure (1500).

[0167] Return to reference Fig.15A , a selection flag (e.g., scalability_constraint_group_flag) (1503) equal to 1 may specify that constraint flags related to scalability (e.g., inter-layer prediction) may be present. Otherwise, constraint flags related to scalability may not be present in the general constraint information syntax structure (1500).

[0168] A selection flag (eg, partitioning_constraint_group_flag) (1504) equal to 1 may specify that constraint flags related to higher-level partitioning (eg, sub-picture or partition) may be present. Otherwise, constraint flags related to higher-level partitioning may not be present in the general constraint information syntax structure (1500).

[0169] A gating flag (eg, intra_coding_tool_constraint_group_flag) (1505) equal to 1 may specify that constraint flags related to intra-coding (eg, intra-prediction) may be present. Otherwise, constraint flags related to intra-coding may not be present in the general constraint information syntax structure (1500).

[0170] A selection flag (e.g., inter_coding_tool_constraint_group_flag) (1506) equal to 1 may specify that constraint flags related to inter-coding (e.g., motion compensation for inter-picture prediction) may be present. Otherwise, constraint flags related to inter-coding may not be present in the general constraint information syntax structure (1500).

[0171] A selection flag (eg, transform_contraint_group_flag) (1507) equal to 1 may specify that constraint flags related to transform coding (eg, multiple transform matrices) may be present. Otherwise, constraint flags related to transform coding may not be present in the general constraint information syntax structure (1500).

[0172] In one embodiment, when all strobe flags (e.g., Fig.15A When the selection flags (1501)-(1508)) in are all equal to 0, the constraint flag is not presented in the general constraint information syntax structure (for example, the general constraint information syntax structure (1500)).

[0173] According to aspects of the present disclosure, a syntax may be designed such that control information, additional control information, and / or the like including select flags (e.g., select flags (1501)-(1508)) and associated constraint flags (e.g., constraint flags (1511)-(1512) and constraint flags in control information group (1520)) may be byte aligned, e.g., the number of flags may be divisible by 8 to maintain byte alignment. In one example, the number of select flags and constraint flags in constraint information (e.g., general constraint information syntax structure (1500)) may be divisible by 8. A byte alignment mechanism may be used to achieve byte alignment of control information. Reference Fig. 15B , syntax (e.g., while-type loop) (1530) can be used for byte alignment.

[0174] In some embodiments, offset information such as an offset (e.g., using a syntax element constraint_info_offset[]) and length information such as a length (e.g., using a syntax element constraint_info_length[]) are presented in the constraint information (e.g., at the beginning of a general constraint information syntax structure) to facilitate presentation of constraint flags in respective constraint information groups associated with gating flags in the constraint information. In one embodiment, one or more constraint information groups of at least one constraint information group are presented in the coded video bitstream. For a constraint information group, an offset and a length may be presented in the constraint information of the constraint information group. The offset may indicate an offset to the first constraint flag in the constraint information group, and the length may indicate the number of constraint flags in the constraint information group. In some examples, the number of constraint information groups may be explicitly indicated, for example, by a syntax element num_constraint_info_set. The value of num_constaint_info_set may be an integer greater than or equal to 0. When the value of num_constaint_info_set is 0, constraint_info_offset[], constraint_info_length[], and constraint flags are not presented in the general constraint information syntax structure.

[0175] In one embodiment, a constraint information offset (e.g., syntax element constraint_info_offset[i]) and a constraint information length (e.g., syntax element constraint_info_length[i]) may help present constraint flags for constraint information group i (i is a positive integer) in constraint information (e.g., a general constraint information syntax structure). In one example, when the value of the constraint information offset (e.g., syntax element constraint_info_offset[i]) is equal to 5 and the value of the constraint information length (e.g., syntax element constraint_info_length[i]) is equal to 3, the fifth, sixth, and seventh constraint flags are associated with constraint information group i and are presented in the constraint information (e.g., a general constraint information syntax structure).

[0176] In one example, run-length coding may be used to encode the constraint flags specified in a predetermined order (or a given order).

[0177] In one embodiment, run-coding may be used when the constraint flags are specified in a predetermined order (or a given order). Rather than encoding the constraint flags directly, a suitably encoded list of "skip" values ​​may indicate a constraint flag equal to zero, and subsequent constraint flags are implicitly equal to 1. This may be particularly effective if (i) the number of constraint flags is large and (ii) a small fraction of the constraint flags are equal to 1.

[0178] In one embodiment, one or more of the at least one constraint information group are present in the coded video bitstream. A plurality of constraint flags in one or more of the at least one constraint information group are signaled according to a predetermined order. Thus, the plurality of constraint flags may be run-encoded (e.g., run-encoded or run-decoded). Furthermore, prediction information for a subset of the coding blocks may be determined based on the plurality of constraint flags.

[0179] In one embodiment, at least one constraint flag in the constraint information group of the strobe flag includes a plurality of constraint flags signaled according to a predetermined order. Thus, the plurality of constraint flags may be variable length encoded (eg, variable length encoded or variable length decoded).

[0180] In one embodiment, the complete list of constraint flags may be specified in a video coding standard (e.g., VVC specification), an external table, etc. In one example, only available constraint flags in the constraint flags are indicated by, for example, one or more of the following: the number of available constraint flags (e.g., num_available_constraint_flags), a gating flag (or constraint group presentation flag), constraint information offset information, and constraint information length information, etc., are presented in the coded video stream.

[0181] In one example, a complete list of constraint flags is specified, and it can be used for encoders and decoders. The complete list of constraint flags can be stored at the decoder. The complete list of constraint flags may include 100 constraint flags. 10 constraint flags in the 100 constraint flags are presented in the constraint information of CLVS, and thus can be used for a subset of the coding block in CLVS. 10 constraint flags in the 100 constraint flags are referred to as 10 available constraint flags. In one example, the number of available constraint flags (e.g., 10) is sent with a signal. In one example, the 10 available constraint flags are in two constraint information groups and are gated by a first gating flag and a second gating flag. Therefore, a first gating flag and a second gating flag can be sent with a signal to indicate 10 available constraint flags.

[0182] In one example, a first constraint information offset (e.g., syntax element constraint_info_offset[0]) and a first constraint information length (e.g., syntax element constraint_info_length[0]) are signaled. A second constraint information offset (e.g., syntax element constraint_info_offset[1]) and a second constraint information length (e.g., syntax element constraint_info_length[1]) are signaled. For example, the syntax element constraint_info_offset[0] is 15, the syntax element constaint_info_length[0] is 3, the syntax element constraint_info_offset[1] is 82, and the syntax element constraint_info_length[1] is 7, indicating that the 15th to 17th constraint flags and the 82nd to 88th constraint flags in the complete list (e.g., 100 constraint flags) are available or present in the constraint information.

[0183] In one embodiment, any of the various techniques (or methods, embodiments, examples) for efficient encoding of constraint flags may be combined with appropriate control information. The combination may be an appropriate combination of two or more such techniques. Alternatively, one of the various techniques (or methods, embodiments, examples) may be used independently. Constraint flags may be grouped. Some groups may use run-coding, and other groups may use direct binary encoding.

[0184] The value of the maximum number of constraint flags (eg, MaxNumConstraintFlags) may be predefined as 16, 32, 64, or 128, etc.

[0185] The value of the maximum number of constraint flags (e.g., MaxNumConstraintFlags) may be determined by profile information (e.g., general_profile_idc or general_sub_profile_idc) or codec version information, so that the number range of constraint flags (e.g., num_available_constraint_flags(1401)) may be limited by the profile information or version information. For example, the number value of constraint flags (e.g., num_available_constraint_flags(1401)) in the main profile (e.g., where MaxNumConstraintFlags=64) may be in the range of 0 to 64, and the number value of constraint flags (e.g., num_available_constraint_flags(1401)) in the advanced profile (e.g., where MaxNumConstraintFlags=128) may be in the range of 0 to 128.

[0186] In one embodiment, the value of the number of constraint flags (eg, num_available_constraint_flags) may be inferred to be equal to a value predefined by profile information (eg, general_profile_idc or general_sub_profile_idc) or codec version information, so that the value of num_available_constraint_flags may be determined without explicit signaling.

[0187] In some embodiments, the reserved byte information may be presented in a general constraint information syntax structure. Fig.13 As shown, the flags gci_num_reserved_bytes (1303) and gci_reserved_bytes[] (1304) may be present in the general constraint information syntax structure for extending the general constraint information syntax structure. The flag gci_num_reserved_bytes may specify the number of reserved constraint bytes. In one example, the reserved constraint bytes are used to signal additional flags (e.g., additional constraint flags). The flag gci_reserved_byte[] may have any suitable value.

[0188] In one embodiment, the value of gci_num_reserved_bytes may be limited or determined by profile information (e.g., general_profile_idc or general_sub_profile_idc) or codec version information. For the base profile (or main profile), the value of the flag gci_num_reserved_bytes may be 0. For the extended profile (or advanced profile), the value of gci_num_reserved_bytes may be greater than 0.

[0189] In some embodiments, a field sequence flag may be signaled in the coded video bitstream. The field sequence flag may indicate whether the picture in the output layer is coded with field coding. In some examples, the field sequence flag may be signaled in the SPS using the syntax element sps_field_seq_flag. In one embodiment, the flag sps_field_seq_flag may be present in the SPS. The flag sps_field_seq_flag equal to 1 may indicate that the CLVS transmits pictures representing fields. The flag sps_field_seq_flag equal to 0 may indicate that the CLVS transmits pictures representing frames.

[0190] exist Fig.13 In the general constraint information syntax structure in , the flag general_frame_only_constraint_flag may be present. The flag general_frame_only_constraint_flag being equal to 1 may specify that the output layer set (e.g., OlsInScope) transmits a range of pictures representing frames. The flag general_frame_only_constraint_flag being equal to 0 specifies that the output layer set (e.g., OlsInScope) transmits a range of pictures that may or may not represent frames. In one embodiment, the flag general_frame_only_constraint_flag indicates whether the pictures in the output layer set are encoded in field coding. The output layer set may include a subset of coding blocks. Based on the flag general_frame_only_constraint_flag (e.g., being 1) indicating that the subset of pictures is not encoded in field coding, the flag sps_field_seq_flag may be determined to be false. The subset of pictures may be in one layer of the output layer set.

[0191] When the flag general_frame_only_constraint_flag is equal to 1, the value of the flag sps_field_seq_flag may be equal to 0.

[0192] In one embodiment, the flag pps_mixed_nalu_types_in_pic_flag may be present in the PPS. The flag pps_mixed_nalu_types_in_pic_flag equal to 1 may specify that each picture involved in the PPS has more than one VCL NAL unit, and the multiple VCL NAL units do not have the same nal_unit_type value. The flag pps_mixed_nalu_types_in_pic_flag equal to 0 may specify that each picture involved in the PPS has one or more VCL NAL units, and the multiple VCL NAL units of each picture involved in the PPS have the same nal_unit_type value. Fig.13 In the general constraint information syntax structure in , the flag no_mixed_nalu_types_in_pic_constraint_flag may be present. The flag no_mixed_nalu_types_in_pic_constraint_flag equal to 1 may specify that the value of pps_mixed_nalu_types_in_pic_flag shall be equal to 0. The flag no_mixed_nalu_types_in_pic_constraint_flag equal to 0 does not impose such a constraint.

[0193] In one embodiment, the flag general_one_picture_only_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13 general_one_picture_only_constraint_flag equal to 1 can specify that there is only one coded picture in the bitstream. The flag general_one_picture_only_constraint_flag equal to 0 does not impose such a constraint.

[0194] In one embodiment, the flag single_layer_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13The flag single_layer_constraint_flag equal to 1 may specify that sps_video_parameter_set_id should be equal to 0. The flag single_layer_constraint_flag equal to 0 does not impose such a constraint. When the flag general_one_picture_only_constraint_flag is equal to 1, the value of the flag single_layer_constraint_flag may be equal to 1.

[0195] In one embodiment, the flag all_layers_independent_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13 As shown. The flag all_layers_independent_constraint_flag equal to 1 may specify that the flag vps_all_independent_layers_flag may be equal to 1. The flag all_layers_independent_constraint_flag equal to 0 does not impose such a constraint. When the flag single_layer_constraint_flag is equal to 1, the value of the flag all_layers_independent_constraint_flag may be equal to 1.

[0196] In one embodiment, the flag no_res_change_in_clvs_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13 As shown. The flag no_res_change_in_clvs_constraint_flag equal to 1 may specify that the flag sps_res_change_in_clvs_allowed_flag may be equal to 0. The flag no_res_change_in_clvs_constraint_flag equal to 0 does not impose such a constraint. When the flag no_ref_pic_resampling_constraint_flag is 1, the value of the flag no_res_change_in_clvs_constraint_flag may be equal to 1.

[0197] In one embodiment, the flag no_mixed_nalu_types_in_pic_constraint_flag may be present in Fig.13The flag no_mixed_nalu_types_in_pic_constraint_flag is equal to 1 and specifies that the value of the flag pps_mixed_nalu_types_in_pic_flag may be equal to 0. The flag no_mixed_nalu_types_in_pic_constraint_flag is equal to 0 and does not impose such a constraint. When the flag one_subpic_per_pic_constraint_flag is equal to 1, the value of the flag no_mixed_nalu_types_in_pic_constraint_flag may be equal to 1.

[0198] In one embodiment, the flag no_trail_constraint_flag may be present in Fig.13 The flag no_trail_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to TRAIL_NUT may not be presented in OlsInScope (OlsInScope is the output layer set that includes all layers in the entire bitstream involved in the DPS). The flag no_trail_constraint_flag equal to 0 does not impose such a constraint. The flag no_trail_constraint_flag may be equal to 1 when the flag general_one_picture_only_constraint_flag is equal to 1.

[0199] In one embodiment, the flag no_stsa_constraint_flag may be present in Fig.13 The flag no_stsa_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to STSA_NUT may not be presented in OlsInScope. The flag no_stsa_constraint_flag equal to 0 does not impose such a constraint. The flag no_stsa_constraint_flag may be equal to 1 when the flag general_one_picture_only_constraint_flag is equal to 1.

[0200] In one embodiment, the flag no_trail_constraint_flag may be present in Fig.13The flag no_trail_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to TRAIL_NUT may not be presented in OlsInScope. The flag no_trail_constraint_flag equal to 0 does not impose such a constraint. The flag no_trail_constraint_flag may be equal to 1 when the flag general_one_picture_only_constraint_flag is equal to 1.

[0201] In one embodiment, the flag no_stsa_constraint_flag may be present in Fig.13 The flag no_stsa_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to STSA_NUT may not be presented in OlsInScope. The flag no_stsa_constraint_flag equal to 0 does not impose such a constraint. The flag no_stsa_constraint_flag may be equal to 1 when the flag general_one_picture_only_constraint_flag is equal to 1.

[0202] In one embodiment, the flag no_idr_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13 no_idr_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to IDR_W_RADL or IDR_N_LP may not be present in OlsInScope. The flag no_idr_constraint_flag equal to 0 does not impose such a constraint.

[0203] In one embodiment, the flag no_cra_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13 The flag no_cra_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to CRA_NUT may not be present in OlsInScope. The flag no_cra_constraint_flag equal to 0 does not impose such a constraint.

[0204] In one embodiment, the flag no_rasl_constraint_flag may be present in Fig.13The flag no_rasl_constraint_flag is not shown in the general constraint information syntax structure in OlsInScope. The flag no_rasl_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to RASL_NUT may not be presented in OlsInScope. The flag no_rasl_constraint_flag equal to 0 does not impose such a constraint. When the flag no_rasl_constraint_flag is equal to 1, the value of the flag no_rasl_constraint_flag may be equal to 1.

[0205] In one embodiment, the flag no_radl_constraint_flag may be present in the general constraint information syntax structure, such as Fig.13 As shown. The flag no_radl_constraint_flag equal to 1 may specify that NAL units with nuh_unit_type equal to RADL_NUT may not be presented in OlsInScope. The flag no_radl_constraint_flag equal to 0 does not impose such a constraint. When the flag no_idr_constraint_flag is equal to 1 and the flag no_cra_constraint_flag is equal to 1, the value of the flag no_rasl_constraint_flag may be equal to 1.

[0206] Some aspects of the present disclosure provide techniques for constraint flag signaling for range extension, such as range extension with persistent Rice adaptation (eg, range extension including coding tools for statistics-based Rice parameter derivation in residual coding).

[0207] According to one aspect of the present disclosure, residual coding can be performed based on Rice coding. Rice coding uses an adjustable parameter to divide an input value into two parts, and then encodes the two parts using different encoding techniques. In some examples, the adjustable parameter is called a Rice parameter. The Rice parameter affects the coding efficiency of Rice coding. Techniques can be used to determine the Rice parameter for a specific application to improve the coding efficiency of the specific application. Some techniques for determining the Rice parameter can be included in the range extension of the video standard.

[0208] According to one aspect of the present disclosure, some standards may be initially developed for specific applications. To adapt the standard to other applications, tools are used to develop range extensions to support other applications. For example, HEVC was initially targeted at applications with a 4:2:0 chroma format of 8-10 bits per sample. To adapt the HEVC standard to formats and bit depths other than a specific chroma format and a specific bit depth, range extensions may be developed to support applications using other chroma formats and / or higher bit depths.

[0209] In order to limit the feature set to the range required by a specific application group, the video codec standard defines profiles, which may include a defined decoder feature set that supports the defined decoder feature set to achieve interoperability with encoders using these features. For example, a profile may define a set of coding tools or algorithms that can be used to generate a consistent bitstream. In addition to profiles, some standards (such as VVC, HEVC, etc.) also define levels and tiers. The level imposes restrictions on the bitstream related to spatial resolution, pixel rate, bitrate value, and changes that may correspond to decoder processing load and memory capabilities. Horizontal restrictions can be expressed in terms of maximum sample rate, maximum picture size, maximum bitrate, minimum compression ratio, performance of the encoded picture buffer, etc. Higher horizontal values ​​can correspond to higher complexity limits. The level modifies the bitrate value and change limit of each level. For example, the main level is used for most applications, while the high level is intended to handle more demanding video delivery applications, such as those with much higher bitrate values ​​than video distribution applications. Each of the profiles, levels, and levels affects the complexity of implementation and decoding, and the combination of the three specifies the interoperability point of the bitstream and the decoder.

[0210] In some examples, a decoder conforming to a particular grade and level needs to be able to decode all bitstreams conforming to the same grade, a lower grade of that level, or any level below that level, and a decoder conforming to a particular profile may support all features in that profile. In some examples, an encoder does not need to utilize any particular set of features supported in a profile, but rather needs to produce a conforming bitstream, i.e., a bitstream that obeys the specified constraints and can be decoded by a conforming decoder.

[0211] In addition to the PTL information, the PTL syntax structure may also include a general constraints information (GCI) syntax structure, which includes a list of constraint flags and non-flag syntax elements for indicating specific constraint properties of the bitstream.

[0212] In one example, HEVC originally included three profiles, which are called Main profile, Main 10 profile, and Main Still Picture profile. These three profiles have some limitations, such as supporting only 4:2:0 chroma samples. In Main profile and Main Still Picture profile, only 8 bits of video precision per sample are supported, while Main 10 profile supports up to 10 bits of video precision per sample. In Main Still Picture profile, the entire bitstream includes only one coded picture.

[0213] In some examples, HEVC with range extension may support additional profiles. In one example, the following profiles are collectively referred to as range extension profiles: monochrome profile, monochrome 10 profile, monochrome 12 profile, monochrome 16 profile, main 12 profile, main 4:2:2 10 profile, main 4:2:2 12 profile, main 4:4:4 profile, main 4:4:4 10 profile, main 4:4:4 12 profile, main intra profile, main intra profile 10, main intra profile 12, main 4:2:2 10 profile, main 4:2:2 12 profile, main 4:4:4 intra profile, main 4:4:4 10 profile, main 4:4:4 12 profile, main 4:4:4 still picture profile, and main 4:4:4 16 still picture profile.

[0214] Some range extension profiles may support higher bit depths and may be referred to as operating range extension profiles with high bit depths. In some examples, operating range extension profiles with high bit depths include profiles supporting more than 10 bits per sample, such as Main 12 profile, Main 12 4:4:4 profile, Main 16 4:4:4 profile, Main 12 intra profile, Main 12 4:4:4 intra profile, Main 16 4:4:4 intra profile, Main 12 still picture profile, Main 12 4:4:4 still picture profile, Main 16 4:4:4 still picture profile, etc.

[0215] Specifically, the Main 12 profile allows bit depths from 8 bits to 12 bits per sample, supports 4:0:0 and 4:2:0 chroma sampling, and intra and inter prediction modes. In some examples, a decoder compliant with the Main 12 profile is able to decode bitstreams of the following profiles: Monochrome, Monochrome 12, Main, Main 10, and Main 12.

[0216] The Main 12 4:4:4 profile allows bit depths from 8 bits to 12 bits per sample, supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, and intra and inter prediction modes. In some examples, a decoder compliant with the Main 12 4:4:4 profile is capable of decoding bitstreams of the following profiles: Monochrome, Main, Main 10, Main 12, Main 10 4:2:2, Main 12 4:2:2, Main 4:4:4, Main 10 4:4:4, Main 12 4:4:4, and Monochrome 12.

[0217] The Main 16 4:4:4 profile allows bit depths from 8 to 16 bits per sample, supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, and supports intra- and inter-prediction modes.

[0218] The main 12-intra profile allows bit depths from 8 to 12 bits per sample and supports 4:0:0 and 4:2:0 chroma sampling as well as intra prediction modes.

[0219] The Main 12 4:4:4 Intra profile allows bit depths from 8 to 12 bits per sample and supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and Intra prediction modes.

[0220] The Main 16 4:4:4 Intra profile allows bit depths from 8 to 16 bits per sample and supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and Intra prediction modes.

[0221] The Main 12 still picture profile allows bit depths from 8 bits to 12 bits per sample and supports 4:0:0 and 4:2:0 chroma sampling. In the Main 12 still picture profile, the entire bitstream includes only one coded picture.

[0222] The Main 12 4:4:4 still picture profile allows bit depths from 8 bits to 12 bits per sample and supports chroma sampling of 4:0:0, 4:2:0, 4:2:2, and 4:4:4. In the Main 12 4:4:4 still picture profile, the entire bitstream includes only one coded picture.

[0223] The Main 16 4:4:4 still picture profile allows bit depths from 8 bits to 16 bits per sample and supports chroma sampling of 4:0:0, 4:2:0, 4:2:2, and 4:4:4. In the Main 16 4:4:4 still picture profile, the entire bitstream includes only one coded picture.

[0224] According to some aspects of the present disclosure, coding tool control may be performed in various scopes (e.g., portions of coded video data encoded using persistence of instances of syntax elements for coding tool control), such as scope of a bitstream, scope of a coded layer video sequence (CLVS), a picture, a slice of a picture, etc. In some examples, coding tool control may be provided in a general constraint information (GCI) syntax structure, which generally includes constraint information for a bitstream that carries an output layer set to a decoder. In some examples, coding tool control may be provided in a sequence parameter set (SPS) associated with a CLVS, which generally includes information for the CLVS. In some examples, coding tool control may be provided in a picture header of a picture, which generally includes information for the picture. In some examples, coding tool control may be provided in a slice header of a slice, which generally includes information for the slice.

[0225] According to one aspect of the present disclosure, control information for coding tools in range extension may be provided in various ranges. In some examples, using a larger range of syntax elements may improve coding efficiency. For example, a GCI syntax element value greater than 0 indicates that the bitstream is constrained in a particular manner, generally indicating that a particular coding tool is not used in the bitstream. In addition, a GCI syntax element value equal to a value of 0 indicates that the associated constraint may not apply, allowing (but not requiring) the use of the associated coding tool in the bitstream (if its use is supported in the indicated profile).

[0226] According to another aspect of the present disclosure, when a coding tool is not used in the encoding of video data in a bitstream, it is indicated in, for example, PTL information and / or general constraint information that the coding tool is not used, and a video decoder that does not support the coding tool can determine that the video decoder is capable of decoding the bitstream based on signaling in the PTL information and / or general constraint information, and the functionality of the video decoder can be extended.

[0227] In some embodiments, an encoder may generate a bitstream that complies with a video standard with a range extension, but does not use one or more features supported in the range extension. In some examples, knowing that one or more features in the range extension are not used, a decoder that complies with the video standard but does not support one or more features in the range extension may determine that the decoder is able to decode the bitstream and may accept the bitstream for decoding rather than rejecting the bitstream.

[0228] Fig.16 The syntax structure (1600) of general constraint information according to some embodiments of the present disclosure is shown. In some examples, the syntax structure (1600) includes constraints to be applied to a bitstream, for example, including a bitstream set to an output layer of a decoder. Fig.16In the example of , the syntax element denoted by gci_num_additional_bits in the syntax structure (1600) is used to specify the number of additional general constraint information (GCI) bits in the general constraint information syntax structure (1600) in addition to the aligned zero bit syntax elements (when present). In some standards, the value of gci_num_additional_bits is required to be equal to 0 or 1. In some standards, the decoder may allow a value of gci_num_additional_bits greater than 1 to appear in the syntax structure.

[0229] exist Fig.16 In some examples, the syntax structure (1600) includes 5 additional GCI bits (syntax elements) (1601)-(1605), which are represented by: general_no_extended_precision_constraint_flag, general_no_ts_residual_coding_rice_present_in_sh_constraint_flag, general_no_rrc_rice_extension_constraint_flag, general_no_persistent_rice_adaptation_constraint_flag, and general_no_reverse_last_sig_coeff_constraint_flag. In some examples, the 5 additional GCI bits (1601)-(1605) provide coding control information for coding tools within the scope of the bitstream of the output layer set, respectively.

[0230] Fig.17An example of a syntax structure (1700) for sequence parameter set (SPS) range extension according to some embodiments of the present disclosure is shown. The syntax structure (1700) can be added to an SPS for CLVS to provide control of coding tools for range extension of CLVS. The syntax structure (1700) includes five syntax elements (1701)-(1705), which are represented by: sps_extended_precision_flag, sps_ts_residual_coding_rice_present_in_sh_flag, sps_rrc_rice_extension_flag, sps_persistent_rice_adaptation_enabled_flag, and sps_reverse_last_sig_coeff_enabled_flag. In some examples, the five syntax elements (1701)-(1705) provide coding control information for coding tools within the scope of CLVS.

[0231] Specifically, in one embodiment, the GCI bits (1601) and syntax elements (1701) are used to provide control over the use of extended precision in different scopes, such as control over coding tools for extended dynamic range of transform coefficients in scaling and transform processes, and control over binarization of some syntax elements (such as abs_remainder[] and dec_abs_level[], etc.).

[0232] The syntax element (1701) equal to 1 specifies that the extended dynamic range is used for the transform coefficients in the scaling and transform process and for the binarization of some syntax elements such as abs_remainder[] and dec_abs_level[]. The syntax element abs_remainder[scan position n] is the remaining absolute value of the transform coefficient level encoded with the Golomb-Rice code at scan position n. When abs_remainder[] is not present, it is inferred to be equal to 0. The syntax element dec_abs_level[scan position n] may correspond to an intermediate value encoded with the Golomb-Rice code at scan position n, which is used to determine the level of the transform coefficient at scan position n. The syntax element (1701) equal to 0 specifies that the extended dynamic range is not used for the scaling and transform process and is not used for binarization such as the syntax elements abs_remainder[] and dec_abs_level[]. When not present, the value of the syntax element (1701) is inferred to be equal to 0.

[0233] In one example, a variable represented by Log2TransformRange is used to determine the dynamic range of binarization of transform coefficients and certain syntax elements during scaling and transformation. For example, the variable Log2TransformRange can be the number of bits used to represent the transform coefficients during scaling and transformation and for binarization of certain syntax elements. The dynamic range can be the difference between the maximum number and the minimum number represented using the number of bits. In one example, the variable Log2TransformRange is derived from the syntax element (1701) sps_extended_precision_flag, for example using equation (1):

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

[0235] The dynamic range of the binarization of transform coefficients and certain syntax elements in the scaling and transformation process can be determined based on the variable Log2TransformRange. In some examples, when the value of the flag sps_extended_precision_flag is 0, the extended dynamic range feature (e.g., the coding tool of the extended dynamic range) is not used, and the dynamic range of the transform coefficient is based on a fixed number of bits, such as 15 bits. When the value of the flag sps_extended_precision_flag is 1, the extended dynamic range feature is enabled, and the number of bits representing the transform coefficients in the scaling and transformation process can be one of 15 bits, 16 bits, 17 bits, 18 bits, 19 bits, and 20 bits based on the bit depth BitDepth in the example of equation (1). The dynamic range of the transform coefficient can be determined based on the number of bits.

[0236] According to one aspect of the present disclosure, a syntax element (e.g., represented by sps_bitdepth_minus8) may be used to signal the bit depth of samples of the luma and chroma arrays (e.g., represented by BitDepth), and the values ​​of the luma and chroma quantization parameter range offsets (e.g., represented by QpBdOffset). In one example, the bit depth BitDepth may be calculated according to equation (2), and the QP range offset QpBdOffset may be calculated according to equation (3):

[0237] BitDepth = 8 + sps_bitdepth_minus8 Equation (2)

[0238] QpBdOffset = 6 × sps_bitdepth_minus8 Equation (3)

[0239] In some examples, the GCI bit (1601) equal to 1 specifies that the syntax element (1701) of all pictures in the scope of the output layer set (OlsInScope) can be equal to 0. The GCI bit (1601) equal to 0 does not impose such a constraint. Therefore, the GCI bit (1601) equal to 1 can specify that the extended dynamic range coding tool is not used in the encoding of the bitstream.

[0240] In some embodiments, the GCI bits (1602) and syntax elements (1702) are used to provide control of coding tools for slice based Rice coding for residual coding in transform skip mode in different scopes, such as slice based Rice parameter selection for residual coding in transform skip mode.

[0241] According to one aspect of the present disclosure, slice-based selection of Rice parameters for transform skip residual coding can be included in a range extension of a video standard. In some examples, when transform skip mode is enabled (e.g., syntax element sps_tranform_skip_enabled_flag is true), a control flag (e.g., represented by sps_ts_residual_coding_rice_present_in_sh_flag, syntax element (1702)) is signaled in a sequence parameter set (SPS) to indicate that signaling of Rice parameters for transform skip slices is enabled or disabled, e.g. Fig.17 shown.

[0242] When the control flag is signaled as enabled (e.g., equal to "1"), for example, in a slice header, a syntax element (e.g., represented by sh_ts_residual_coding_rice_idx_minus1) is further signaled for each transform skip slice to indicate the selection of Rice parameters for the transform skip slice. When the control flag is signaled as disabled (e.g., equal to "0"), in one example, no further syntax elements are signaled at the slice level (e.g., slice header) to indicate the selection of Rice parameters for the transform skip slice, and default Rice parameters may be used for all transform skip slices in the coded video data related to the SPS.

[0243] For example, the syntax element (1702) in the SPS being equal to 1 specifies that the slice header flag indicated by sh_ts_residual_coding_rice_idx_minus1 may be present in the slice header (e.g., slice_header()) syntax structure of the slices related to the SPS. The syntax element (1702) in the SPS being equal to 0 specifies that the slice header flag sh_ts_residual_coding_rice_idx_minus1 is not present in the slice_header() syntax structure of the slices related to the SPS. When not present, in some examples, the value of sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be equal to 0.

[0244] In some examples, a syntax element may be included in the general constraint information to control the use of a coding tool for slice-based Rice coding for residual coding in transform skip mode within the scope of an output layer set. For example, a syntax element (1602) equal to 1 specifies that a syntax element (1702) for all pictures in the scope of the output layer set (OlsInScope) may be equal to 0. A syntax element (1602) equal to 0 does not impose such a constraint. Thus, in some examples, a GCI bit (1602) in a bitstream equal to 1 may specify that slice-based Rice parameter selection is not used for transform skip residual coding of the encoded bitstream.

[0245] In some embodiments, the GCI bit (1603) and the syntax element (1703) are used to provide control of one or more coding tools for Rice parameter derivation in different ranges, which Rice parameter derivation is used to binarize some syntax elements (e.g., abs_remainder[] and dec_abs_level[] in regular residual coding (RRC), etc.). In some examples, regular residual coding (RRC) refers to some techniques for encoding blocks obtained by transform and quantization. In some examples, RRC can be modified for blocks obtained only by quantization. In some examples, transform skip residual coding (TSRC) refers to some techniques dedicated to encoding blocks obtained by bypassing transform (also known as transform skip).

[0246] In some examples, a video codec standard may include one or more coding tools for deriving Rice parameters for binarizing some syntax elements (e.g., abs_remainder[] and dec_abs_level[]), and a range extension of the video codec standard may include one or more alternative coding tools for deriving Rice parameters for binarizing some syntax elements (e.g., abs_remainder[] and dec_abs_level[]).

[0247] In some examples, the video standard uses a local template-based technique for Rice parameter derivation. For example, a template comprising one or more (e.g., 5 in one example) adjacent coefficient levels is used for Rice parameter derivation. For example, the sum of the absolute coefficient values ​​within the template can be calculated and then the Rice parameters can be determined based on the sum. In one example, a lookup table can be used to determine the Rice parameters based on the sum.

[0248] It is noteworthy that the Rice parameters can be determined by other suitable coding tools. In one example, the Rice parameters can be determined based on the sum using an equation. In another example, context modeling can be used to determine the Rice parameters based on statistics of adjacent coefficient levels. In some examples, the range extension of the video standard can specify one or more alternative coding tools for Rice parameter derivation.

[0249] In some examples, the range extension of the video standard may include modifications to the RRC for use in other scenarios. In one example, the range extension may include different context modeling tools and residual signal rotation tools for residual coding in transform skip mode.

[0250] In some examples, a syntax element (1703) equal to 1 in the SPS specifies that an alternative Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] (e.g., an alternative coding tool for Rice parameter derivation in range extension) is used to encode the CLVS involving the SPS. A syntax element (1703) equal to 0 specifies that an alternative Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is not used to encode the CLVS involving the SPS. When not present, the value of the syntax element (1703) is inferred to be equal to 0.

[0251] In some examples, syntax element (1603) equal to 1 specifies that syntax element (1703) of all pictures in the scope of the output layer set (OlsInScope) may be equal to 0. Syntax element (1603) equal to 0 does not impose such a constraint. Thus, in some examples, GCI bit (1603) equal to 1 may specify that an alternative Rice parameter derivation (e.g., an alternative coding tool for Rice parameter derivation specified in a specified scope extension) is not used for binarization of abs_remainder[] and dec_abs_level[] to encode the bitstream.

[0252] In some embodiments, the GCI bits (1604) and syntax elements (1704) are used to provide control over the statistical based derivation of Rice parameters in different ranges for binarization of abs_remainder[] and dec_abs_level[].

[0253] According to one aspect of the present disclosure, the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] may be initialized at the beginning of each transform unit (TU) using statistics accumulated from previous TUs. In some examples, the statistics-based Rice parameter derivation may be included in the range extension of the video standard.

[0254] In some examples, a control flag, such as the syntax element (1704) represented by sps_persistent_rice_adaptation_enabled_flag in the SPS, is used to control the statistics-based Rice parameter derivation. For example, the syntax element (1704) equal to 1 in the SPS specifies that the Rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is initialized at the beginning of each TU using the statistics accumulated from the previous TU. The syntax element (1704) equal to 0 specifies that the previous TU state is not used in the Rice parameter derivation of the current TU. When not present, the value of the syntax (1704) is inferred to be equal to 0.

[0255] Furthermore, in one embodiment, the syntax element (1604) equal to 1 specifies that the syntax element (1704) for all pictures in the scope of the output layer set (OlsInScope) may be equal to 0. The syntax element (1604) equal to 0 does not impose such a constraint. Thus, in some examples, the GCI bit (1604) equal to 1 may specify that statistics-based Rice parameter derivation is not used to encode the bitstream.

[0256] In some embodiments, the GCI bits (1605) and syntax elements (1705) are used to provide control of coding tools for encoding the position of the last significant coefficient during entropy coding of transform coefficients in different scopes. In one example, the position of the last significant coefficient can be encoded by different coding tools. For example, a video standard can specify a first coding tool that can determine the position of the last significant coefficient by encoding two coordinates of the position represented by LastSignificantCoeffX and LastSignificantCoeffY variables; and a range extension of the video standard can specify an alternative coding tool, such as a second coding tool that can determine the position of the last significant coefficient by encoding the relative coordinates of the last significant coefficient with reference to the lower right corner of a zero-out transform block in one example.

[0257] In some examples, the syntax element (1705) equal to 1 in the SPS specifies that the slice header flag (slice range) represented by sh_reverse_last_sig_coeff_flag is present in the slice header syntax structure related to the SPS (e.g., slice_header() in some examples). The syntax element (1705) equal to 0 in the SPS specifies that the slice header flag sh_reverse_last_sig_coeff_flag is not present in the slice header syntax structure related to the SPS, and the slice header flag sh_reverse_last_sig_coeff_flag can be inferred to be zero. When not present, the value of the syntax element (1705) is inferred to be equal to 0.

[0258] In some examples, the value of the slice header flag sh_reverse_last_sig_coeff_flag of the slice is used to determine the position derivation of the last significant coefficient in the transform coefficients in the scaling and transform process in the encoding of the slice. In one example, when sh_reverse_last_sig_coeff_flag is equal to 1, the last significant coefficient position is encoded by an alternative coding tool (e.g., a second coding tool) in the range extension of the video standard; otherwise, the current coordinates of the last significant coefficient position are encoded by the first coding tool.

[0259] In some examples, the GCI bit (1605) equal to 1 specifies that the syntax element (1705) of all pictures in the scope of the output layer set (OlsInScope) can be equal to 0. The GCI bit (1605) equal to 0 does not impose such a constraint. Therefore, the GCI bit (1605) equal to 1 can specify that the second coding tool is not used in the derivation of the position of the last significant coefficient of the scope of the bitstream.

[0260] Fig.18 A flow chart of an overview process (1800) according to an embodiment of the present disclosure is shown. The process (1800) can be used in a video decoder. In various embodiments, the process (1800) is performed by a processing circuit, such as a processing circuit in a terminal device (310), a terminal device (320), a terminal device (330), and a terminal device (340), a processing circuit that performs the functions of a video decoder (410), and a processing circuit that performs the functions of a video decoder (510), etc. In some embodiments, the process (1800) is implemented as software instructions, so when the processing circuit executes the software instructions, the processing circuit performs the process (1800). The process starts at (S1801) and proceeds to (S1810).

[0261] At (S1810), a value of a first syntax element (e.g., general_no_persistent_rice_adaptation_constraint_flag) for coding control in a first scope (e.g., output layer set) of coded video data in a bitstream is determined. The first syntax element is associated with a coding tool for statistical-based Rice parameter derivation in residual coding, such as a coding tool for statistical-based Rice parameter derivation in residual coding and persistent Rice adaptation defined in a range extension of a video standard.

[0262] In one example, in response to a syntax element (eg, gci_num_additional_bits) in the syntax structure indicating additional bits for the generic constraint information in the syntax structure, a first syntax element is decoded from the syntax structure for the generic constraint information.

[0263] In some examples, the coding tool is defined in a range extension of a standard. In one example, a video decoder may support the standard but may not support the coding tool in the range extension of the standard. In another example, a video decoder supports the range extension of the standard.

[0264] At (S1820), when the value of the first syntax element is a first value, the process proceeds to (1830); otherwise, the process proceeds to (S1840). The first value indicates that no encoding tool is used in encoding of a first range of encoded video data in a bitstream including one or more second ranges of encoded video data (e.g., one or more CLVS in an output layer set).

[0265] In some examples, the first syntax element is typically constraint information for controlling the encoding of pictures in the output layer set output by the decoder. In one example, the first value of the first syntax element indicates that no encoding tool is used when encoding each coded layer video sequence (CLVS) in the output layer set.

[0266] At (S1830), in response to the first syntax element being a first value, a first range of encoded video data in a bitstream is decoded without invoking an encoding tool.

[0267] In some examples, a second syntax element (eg, sps_persistent_rice_adaptation_enabled_flag) for encoding control of a coded layer video sequence (CLVS) in a bitstream is constrained to have a value indicating that the encoding tool is not invoked to decode the CLVS.

[0268] At (S1840), in response to the first syntax element being a second value, determining a value of a second syntax element (e.g., sps_extended_precision_flag) of encoding control for a second range of coded video data in the bitstream (e.g., a coded layer video sequence (CLVS)) for decoding the coded video data in the second range. The second syntax element indicates use / non-use of a coding tool in the CLVS. In an example, the second syntax element is not present in a sequence parameter set (SPS) for the CLVS, and the value of the second syntax element is inferred to indicate that the coding tool is not used in the CLVS.

[0269] A second range of the encoded video data is then decoded (e.g., an encoding tool is invoked or not invoked) according to the value of the second syntax element. In some examples, the encoding tool is invoked in the second range during decoding of the video data in response to the value of the syntax element indicating the use of the encoding tool in the CLVS. For example, statistics of coefficients decoded from one or more transform units before the current transform unit may be determined. Initial values ​​of Rice parameters for the current transform unit are determined based on the statistics. Then, coefficients of the current transform unit may be decoded based on the Rice parameters.

[0270] The process (1800) may be appropriately adjusted. Steps in the process (1800) may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0271] Fig.19 A flow chart of an overview process (1900) according to an embodiment of the present disclosure is shown. The process (1900) can be used in a video encoder. In various embodiments, the process (1900) is performed by a processing circuit, such as a processing circuit in a terminal device (310), a terminal device (320), a terminal device (330), and a terminal device (340), a processing circuit that performs the functions of a video encoder (403), a processing circuit that performs the functions of a video encoder (603), and the like. In some embodiments, the process (1900) is implemented as software instructions, so when the processing circuit executes the software instructions, the processing circuit performs the process (1900). The process starts at (S1901) and proceeds to (S1910).

[0272] In (S1910), the processing circuit determines whether a coding tool for statistical-based Rice parameter derivation in residual coding (e.g., a coding tool for statistical-based Rice parameter derivation in residual coding and continuous Rice adaptation defined in a range extension of a video standard) is used during encoding of a first range of encoded video data in a bitstream (e.g., an output layer set). The first range of encoded video data includes one or more second ranges of encoded video data (e.g., CLVS).

[0273] In some examples, the processing circuit may determine whether a coding tool is used for coding control of a coded layer video sequence (CLVS) in a bitstream based on a second syntax element (eg, sps_persistent_rice_adaptation_enabled_flag).

[0274] At (S1920), when the encoding tool is not used in the encoding of the first range of the encoded video data, the process proceeds to (S1930); otherwise, the process proceeds to (S1940).

[0275] At (S1930), a first syntax element (e.g., general_no_persistent_rice_adaptation_constraint_flag) having a first value is encoded in a bitstream. The first syntax element is used for encoding control of a first range (e.g., an output layer set) of encoded video data in a bitstream. The first syntax element is associated with a coding tool for statistical-based Rice parameter derivation in residual coding. The first value indicates that the coding tool is not used in encoding the first range of the encoded video data.

[0276] In one example, the first syntax element is encoded in a syntax structure for generic constraint information, and one syntax element (eg, gci_num_additional_bits) in the syntax structure is adjusted to indicate additional bits in the syntax structure for generic constraint information.

[0277] At (S1940), the first syntax element having the second value is encoded in the bitstream. In some examples, the first syntax element is not encoded in the bitstream, for example, where the second value is a default value for the first syntax element, if the first syntax element is not present, the first syntax element can be inferred and then can be skipped (S1940).

[0278] The process (1900) may be appropriately adjusted. Steps in the process (1900) may be modified and / or omitted. Additional steps may be added. Any suitable order of implementation may be used.

[0279] The above techniques (e.g., techniques for signaling constraint flags, adaptive resolution parameters, etc.) can be implemented as computer software via computer-readable instructions and physically stored in one or more computer-readable media. Fig. 20 A computer system (2000) is shown that is suitable for implementing certain embodiments of the disclosed subject matter.

[0280] Computer software may be encoded in any suitable machine code or computer language, and may be assembled, compiled, linked, or otherwise used to create code comprising instructions that may be directly executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., or executed through decoding, microcode, or the like.

[0281] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablets, servers, smartphones, gaming devices, IoT devices, and the like.

[0282] Fig. 20 The components shown for the computer system (2000) are exemplary in nature and are not intended to impose any limitation on the scope of use or functionality of computer software implementing embodiments of the present disclosure. Nor should the configuration of components be interpreted as having any dependency or requirement on any one or combination of components shown in the exemplary embodiment of the computer system (2000).

[0283] The computer system (2000) may include certain human-computer interface input devices. Such human-computer interface input devices may respond to input from one or more human users through tactile input (e.g., keyboard input, sliding, data glove movement), audio input (e.g., sound, applause), visual input (e.g., gestures), and olfactory input (not shown). The human-computer interface device may also be used to capture certain media that are not necessarily directly related to human conscious input, such as audio (e.g., speech, music, ambient sound), images (e.g., scanned images, photographic images obtained from a still image camera), and videos (e.g., two-dimensional video, three-dimensional video including stereoscopic video).

[0284] The human-computer interface input device may include one or more of the following (only one of which is drawn): keyboard (2001), mouse (2002), touch pad (2003), touch screen (2010), data gloves (not shown), joystick (2005), microphone (2006), scanner (2007), camera (2008).

[0285] The computer system (2000) may also include certain human-computer interface output devices. Such human-computer interface output devices may stimulate one or more human user senses through, for example, tactile output, sound, light, and smell / taste. Such human-computer interface output devices may include tactile output devices (e.g., tactile feedback through a touch screen (2010), a data glove (not shown), or a joystick (2005), but there may also be tactile feedback devices that are not used as input devices), audio output devices (e.g., speakers (2009), headphones (not shown)), visual output devices (e.g., screens (2010) including cathode ray tube (CRT) screens, liquid crystal (LCD) screens, plasma screens, organic light emitting diode (OLED) screens, each of which has or does not have a touch screen input function, each of which has or does not have a tactile feedback function - some of which may output two-dimensional visual output or output of more than three dimensions through means such as stereoscopic picture output; virtual reality glasses (not shown), holographic displays, and smoke boxes (not shown)) and printers (not shown).

[0286] The computer system (2000) may also include human-accessible storage devices and their associated media, such as optical media including high-density read-only / rewritable optical disks (CD / DVD ROM / RW) (2020) with CD / DVD or similar media (2021), thumb drives (2022), removable hard disk drives or solid state drives (2023), traditional magnetic media such as tapes and floppy disks (not shown), special-purpose ROM / ASIC / PLD-based devices such as security software protectors (not shown), and the like.

[0287] Those skilled in the art should also understand that the term "computer-readable media" used in connection with the disclosed subject matter does not include transmission media, carrier waves, or other transient signals.

[0288] The computer system (2000) may also include an interface (2054) to one or more communication networks (2055). For example, the network may be wireless, wired, or optical. The network may also be a local area network, a wide area network, a metropolitan area network, an in-vehicle network, an industrial network, a real-time network, a delay-tolerant network, and the like. The network also includes local area networks such as Ethernet, wireless local area networks, cellular networks (GSM, 3G, 4G, 5G, LTE, etc.), television wired or wireless wide area digital networks (including cable television, satellite television, and terrestrial broadcast television), in-vehicle and industrial networks (including CANBus), and the like. Some networks typically require an external network interface adapter for connecting to some universal data ports or peripheral buses (2049) (e.g., a USB port of the computer system (2000)); other networks are typically integrated into the kernel of the computer system (2000) by connecting to a system bus as described below (e.g., an Ethernet interface integrated into a PC computer system or a cellular network interface integrated into a smart phone computer system). By using any of these networks, the computer system (2000) can communicate with other entities. The communication can be one-way, for receiving only (e.g., wireless television), one-way for sending only (e.g., CAN bus to certain CAN bus devices), or two-way, such as to other computer systems via a local or wide area digital network. Each of the above networks and network interfaces can use certain protocols and protocol stacks.

[0289] The above-mentioned human-machine interface device, human-accessible storage device and network interface can be connected to the kernel (2040) of the computer system (2000).

[0290] The core (2040) may include one or more central processing units (CPUs) (2041), graphics processing units (GPUs) (2042), dedicated programmable processing units in the form of field programmable gate arrays (FPGAs) (2043), hardware accelerators for specific tasks (2044), graphics adapters (2050), etc. These devices, as well as read-only memory (ROM) (2045), random access memory (2046), internal mass storage (e.g., internal non-user accessible hard disk drives, solid-state drives (SSDs)), etc.) (2047), etc., may be connected via a system bus (2048). In some computer systems, the system bus (2048) may be accessed in the form of one or more physical plugs so that it may be expanded by additional central processing units, graphics processing units, etc. Peripheral devices may be directly attached to the core's system bus (2048), or connected via a peripheral bus (2049). In one example, a screen (2010) may be connected to a graphics adapter (2050). The architecture of the peripheral bus includes a peripheral controller interface PCI, a universal serial bus USB, etc.

[0291] The CPU (2041), GPU (2042), FPGA (2043) and accelerator (2044) can execute certain instructions, which can be combined to form the above-mentioned computer code. The computer code can be stored in ROM (2045) or RAM (2046). Transition data can also be stored in RAM (2046), while permanent data can be stored in, for example, internal mass storage (2047). Fast storage and retrieval of any memory device can be achieved by using a cache memory, which can be closely associated with one or more CPUs (2041), GPUs (2042), mass storage (2047), ROM (2045), RAM (2046), etc.

[0292] The computer readable medium may have computer code thereon for performing various computer-implemented operations. The medium and computer code may be specially designed and constructed for the purpose of this application, or may be medium and code well known and available to those skilled in the art of computer software.

[0293] As an example and not limitation, a computer system having an architecture (2000), in particular a kernel (2040), can provide the function of executing software contained in one or more tangible computer-readable media as a processor (including a CPU, a GPU, an FPGA, an accelerator, etc.). Such a computer-readable medium can be a medium associated with the above-mentioned user-accessible mass storage, and a specific memory of the kernel (2040) having non-volatility, such as a kernel internal mass storage (2047) or a ROM (2045). Software implementing various embodiments of the present application can be stored in such a device and executed by the kernel (2040). Depending on specific needs, the computer-readable medium may include one or more storage devices or chips. The software can cause the kernel (2040), in particular the processor therein (including a CPU, a GPU, an FPGA, etc.), to perform a specific process or a specific part of a specific process described herein, including defining a data structure stored in the RAM (2046) and modifying such a data structure according to a software-defined process. Additionally or alternatively, the computer system may provide functionality hardwired in logic or otherwise contained in circuitry (e.g., accelerator (2044)) that may operate in place of or in conjunction with software to perform a particular process or a particular portion of a particular process described herein. Where appropriate, references to software may include logic and vice versa. Where appropriate, references to computer-readable media may include circuitry (e.g., an integrated circuit (IC)) storing execution software, circuitry containing execution logic, or both. The present application includes any suitable combination of hardware and software.

[0294] Appendix A: Acronyms

[0295] JEM: Joint Exploration Model

[0296] VVC: universal video coding

[0297] BMS: Benchmark set

[0298] MV: Motion Vector

[0299] HEVC: High Efficiency Video Coding SEI: Supplementary Enhancement Information VUI: Video Usability Information

[0300] GOPs: Groups of Pictures

[0301] TUs: Transform Units

[0302] PUs: Prediction Units

[0303] CTUs: Coding Tree Units

[0304] CTBs: Coding Tree Blocks

[0305] PBs: Prediction Blocks

[0306] HRD: Hypothetical Reference Decoder SNR: Signal-Noise Ratio

[0307] CPUs: Central Processing Units

[0308] GPUs: Graphics Processing Units

[0309] CRT: Cathode Ray Tube

[0310] LCD: Liquid-Crystal Display

[0311] OLED: Organic Light-Emitting Diode CD: Compact Disc

[0312] DVD: Digital Video Disc

[0313] ROM: Read-Only Memory

[0314] RAM: Random Access Memory

[0315] ASIC: Application-Specific Integrated Circuit

[0316] PLD: Programmable Logic Device

[0317] LAN: Local Area Network

[0318] GSM: Global System for Mobile communications

[0319] LTE: Long-Term Evolution

[0320] CANBus: Controller Area Network Bus

[0321] USB: Universal Serial Bus

[0322] PCI: Peripheral Component Interconnect

[0323] FPGA: Field Programmable Gate Areas

[0324] SSD: solid-state drive

[0325] IC:Integrated Circuit

[0326] CU: Coding Unit

[0327] Although the present application has described a number of exemplary embodiments, various changes, arrangements and various equivalent substitutions of the embodiments are within the scope of the present application. Therefore, it should be understood that those skilled in the art can design a variety of systems and methods, which, although not explicitly shown or described herein, embody the principles of the present application and are therefore within the spirit and scope of the present application.

Claims

1. A method for video decoding in a decoder, characterized in that: The method comprises: determining a first syntax element for coding control in a first range of coded video data in a bitstream, the first syntax element being associated with a coding tool for continuous Rice adaptation for statistical-based Rice parameter derivation in residual coding and defined in a range extension of a video standard; and In response to the first syntax element being a first value indicating that the encoding tool is disabled in the first range, decoding a first range of the encoded video data including one or more second ranges of encoded video data without calling the encoding tool, the first range being a bitstream range of a video output layer set, the second range being a coding layer video sequence CLVS range, and the first syntax element being located in general constraint information.

2. The method according to claim 1, characterized in that The first syntax element is used for constraint information of coding control of pictures in an output layer set of the decoder.

3. The method according to claim 2, characterized in that The first value of the first syntax element indicates that the coding tool is disabled in each coding layer video sequence CLVS in the output layer set.

4. The method according to claim 2, characterized in that: The method further comprises: A second syntax element of coding control for a coding layer video sequence CLVS in the bitstream is constrained to have a value indicating that the encoding tool is not to be invoked to decode the CLVS.

5. The method according to claim 3, characterized in that: The method further comprises: In response to the first syntax element being a second value, determining a value of a second syntax element for encoding control of a coding layer video sequence CLVS in the bitstream, wherein the second syntax element indicates use / non-use of the coding tool in the CLVS, and the second value is different from the first value.

6. The method according to claim 5, characterized in that The determining the value of the second syntax element further comprises: In response to the second syntax element not being present in a sequence parameter set (SPS) for the CLVS, the value of the second syntax element for indicating that the coding tool is not used in the CLVS is inferred.

7. The method according to claim 5, characterized in that The method further comprises: In response to the value of the second syntax element indicating use of the coding tool in the CLVS, determining statistics of coefficients decoded from one or more transform units preceding a current transform unit; determining initial values ​​of Rice parameters for the current transform unit based on the statistics; and Coefficients of the current transform unit are decoded based on the Rice parameters.

8. The method according to claim 1, characterized in that The determining the first syntax element further comprises: In response to a syntax element in a syntax structure for generic constraint information indicating additional bits for the generic constraint information in the syntax structure, the first syntax element is decoded from the syntax structure for generic constraint information.

9. A device for video decoding, characterized in that: The apparatus comprises a processing circuit configured to: determining a first syntax element for coding control in a first range of coded video data in a bitstream, the first syntax element being associated with a coding tool for continuous Rice adaptation for statistical-based Rice parameter derivation in residual coding and defined in a range extension of a video standard; and In response to the first syntax element being a first value indicating that the encoding tool is disabled in the first range, decoding a first range of the encoded video data including one or more second ranges of encoded video data without calling the encoding tool, the first range being a bitstream range of a video output layer set, the second range being a coding layer video sequence CLVS range, and the first syntax element being located in general constraint information.

10. The device according to claim 9, characterized in that The first syntax element is used to output constraint information of coding control of pictures in a layer set.

11. The device according to claim 10, characterized in that The first value of the first syntax element indicates that the coding tool is disabled in each coding layer video sequence CLVS in the output layer set.

12. The device according to claim 10, characterized in that The processing circuit is configured to: A second syntax element of coding control for a coding layer video sequence CLVS in the bitstream is constrained to have a value indicating that the encoding tool is not to be invoked to decode the CLVS.

13. The device according to claim 11, characterized in that The processing circuit is configured to: In response to the first syntax element being a second value, determining a value of a second syntax element for encoding control of a coding layer video sequence CLVS in the bitstream, wherein the second syntax element indicates use / non-use of the coding tool in the CLVS, and the second value is different from the first value.

14. The device according to claim 13, characterized in that The processing circuit is configured to: In response to the second syntax element not being present in a sequence parameter set (SPS) for the CLVS, the value of the second syntax element for indicating that the coding tool is not used in the CLVS is inferred.

15. The device according to claim 13, characterized in that The processing circuit is configured to: In response to the value of the second syntax element indicating use of the coding tool in the CLVS, determining statistics of coefficients decoded from one or more transform units preceding a current transform unit; determining an initial value of a Rice parameter for the current transform unit based on the statistics; as well as Coefficients of the current transform unit are decoded based on the Rice parameters.

16. The device according to claim 9, characterized in that The processing circuit is configured to: In response to a syntax element in a syntax structure for generic constraint information indicating additional bits for the generic constraint information in the syntax structure, the first syntax element is decoded from the syntax structure for generic constraint information.

17. A non-transitory computer-readable storage medium, characterized in that The device stores instructions which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 8.

18. A method for processing a bit stream, characterized in that: The bit stream is decoded based on the video decoding method according to any one of claims 1 to 8.

Images