Constraint flag signaling technique for range expansion with coding for the last effective coefficient

Abstract

Aspects of the present disclosure provide a method and apparatus for processing video data. In some examples, the apparatus for processing video data includes a processing circuit. For example, the processing circuit determines a first syntax element for coding control in a first scope of video data coded in a bitstream. The first syntax element is associated with a coding tool for coding the position of the last effective coefficient during entropy coding of the transform coefficients. Then, in response to the first syntax element being a first value indicating the deactivation of the coding tool in the first scope, the processing circuit decodes the first scope of video data coded in the bitstream without calling the coding tool, and the first scope of the coded video data includes one or more second scopes of the coded video data.

Description

Technology Field

[0001] This application claims priority to U.S. Provisional Application No. 63 / 250,155, filed September 29, 2021, titled "Constraint Flag Signaling Technology for Range Extension by Reverse Last Effective Count," and to U.S. Application No. 17 / 710,748, filed March 31, 2022, titled "Constraint Flag Signaling Technology for Range Extension by Coding for Last Effective Count." The entire contents of the prior applications are incorporated herein by reference.

[0002] The present disclosure describes embodiments generally related to video coding. Background Technology

[0003] The background description provided herein is intended to generally present the context of the present disclosure. The work of the inventors currently named is not recognized as prior art to the extent described in this background section, and any aspects of the description that are not qualified as prior art at the time of this application are not recognized as prior art of the present disclosure, expressly or implied.

[0004] Video coding and decoding can be performed using inter-picture prediction along with motion compensation. Uncompressed digital video may contain a series of pictures, each having a spatial dimension of, for example, 1920×1080 luminance samples and associated chrominance samples. The series of pictures may have, for example, 60 pictures per second or a variable picture rate of 60Hz (informally also known as the frame rate). Uncompressed video has specific bitrate requirements. For example, 1080p60 4:2:0 video with 8 bits per sample (1920×1080 luminance samples at a 60Hz frame rate) requires a bandwidth close to 1.5 Gbit / s. One hour of such video requires more than 600GB of storage space.

[0005] One objective of video coding and decoding may be to reduce the redundancy of the input video signal through compression. Compression can help reduce the aforementioned bandwidth and / or storage requirements by more than twofold in some cases. Lossless and lossy compression, as well as combinations thereof, can be utilized. Lossless compression refers to a technique capable of reconstructing an exact copy of the original signal from the compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough to make the reconstructed signal useful for the intended application. For video, lossy compression is widely used. The amount of acceptable distortion varies depending on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. Achievable compression ratios reflect that higher allowable / acceptable distortion yields higher compression ratios.

[0006] Video encoders and decoders can utilize techniques from various broad categories, including, for example, motion compensation, transformation, quantization, and entropy coding.

[0007] Video codec technology may include a technique known as intra-coding. In intra-coding, sample values ​​are represented without reference to samples from a previously reconstructed reference picture or other data. In some video codecs, a picture is spatially subdivided into sample blocks. When all blocks of samples are coded in intra mode, the picture may be an intra-picture. Derivatives such as intra-pictures and independent decoder refresh pictures can be used to reset the decoder state, and thus can be used as the first picture of a coded video bitstream and video session, or as a still image. Samples in an intra-block may be exposed to a transform, and the transform coefficients may be quantized before entropy coding. Intra-prediction may be a technique that minimizes sample values ​​in the pre-transform domain. In some cases, the smaller the DC value after transform and the smaller the AC coefficients, the fewer bits are required at a given quantization step size to represent the block after entropy coding.

[0008] For example, traditional intra-coding, such as that known from MPEG-2 generative coding techniques, does not use intra-prediction. However, some newer video compression techniques include methods that attempt to use, for example, surrounding sample data and / or metadata acquired during the encoding / decoding of spatially adjacent and preceding data blocks in the decoding order. These techniques are hereinafter referred to as "intra-prediction" techniques. Note that, at least in some cases, intra-prediction uses only reference data from the current picture being reconstructed, rather than from the reference picture.

[0009] There may be various forms of intra-prediction. When one or more of these techniques can be used in a given video coding technique, the technique in use may be coded in an intra-prediction mode. In certain cases, a mode may have submodes and / or parameters, which may be coded individually or included in a mode codeword. Since the codeword used for a given mode / submode / parameter combination can affect the coding efficiency gain through intra-prediction, the same applies to the entropy coding technique used to convert codewords into bitstreams.

[0010] Specific modes of intra prediction were introduced in H.264, improved in H.265, and further enhanced in new coding techniques such as JEM (Joint Explosion Model), VVC (versatile video coding), and BMS (benchmark set). A predictor block can be formed using neighbor sample values ​​belonging to already available samples. Depending on the direction, the sample values ​​of neighbor samples are copied into the predictor block. When used, a reference to the direction can be encoded in the bitstream or predicted itself.

[0011] Referring to FIG. 1a, depicted in the lower right is a subset of nine known predictor directions from the 33 possible predictor directions of H.265 (corresponding to 33 angle modes out of 35 intra modes). The point (101) where the arrows converge indicates the predicted sample. The arrows indicate the direction in which the sample is predicted. For example, arrow (102) indicates that the sample (101) is predicted from the sample or samples in the upper right at an angle of 45 degrees from the horizontal. Similarly, arrow (103) indicates that the sample (101) is predicted from the sample or samples in the lower left of the sample (101) at an angle of 22.5 degrees from the horizontal.

[0012] Referring still to FIG. 1a, a square block (104) of 4×4 samples (indicated by a thick dashed line) is shown at the top left. The square block (104) contains 16 samples labeled "S," each representing a position in the Y dimension (e.g., row index) and a position in the X dimension (e.g., column index). For example, sample S21 is the second sample in the Y dimension (from the top) and the first sample in the X dimension (from the left). Similarly, sample S44 is the fourth sample of the block (104) in both the Y and X dimensions. Since the block size is 4×4 samples, S44 is located at the bottom right. A reference sample following a similar numbering scheme is additionally shown. The reference sample is labeled R for the block (104), its Y position (e.g., row index) and X position (column index). In both H.264 and H.265, the predicted samples are adjacent to the block during reconstruction; therefore, negative values ​​do not need to be used.

[0013] Intra-picture prediction can be performed by appropriately copying reference sample values ​​from neighboring samples based on the signaled prediction direction. For example, let us assume that the coded video bitstream includes signaling indicating a prediction direction corresponding to the arrow (102) for this block—that is, the samples are predicted from samples or prediction samples located at an upper right angle of 45 degrees from the horizontal. In this case, samples S41, S32, S23, and S14 are predicted from the same reference sample R05. Then, sample S44 is predicted from reference sample R08.

[0014] In certain cases, particularly when the direction is not divided evenly into 45 degrees; to calculate reference samples, the values ​​of multiple reference samples may be combined, for example, through interpolation.

[0015] As video coding technology develops, the number of possible directions is increasing. In H.264 (2003), nine different directions could be represented. In H.265 (2013), this increased to 33, and at the time of its release, JEM / VVC / BMS could support up to 65 directions. Experiments were conducted to identify the most likely direction, and specific techniques of entropy coding are used to represent these most likely directions with a small number of bits, accepting a specific bit penalty for less likely directions. Additionally, the direction itself can sometimes be predicted from neighboring directions used in already decoded neighboring blocks.

[0016] FIG. 1b illustrates a schematic diagram (180) depicting 65 intra-predicted directions according to JEM to illustrate the number of predicted directions increasing over time.

[0017] The mapping of intra-predicted direction bits in coded video bitstreams indicating direction can vary from video coding technique to video coding technique; for example, it can range from a simple direct mapping of the predicted direction to an intra-predicted mode, to complex adaptive schemes involving codewords and the most likely mode, and similar techniques. However, in all cases, there may be a specific direction that is statistically less likely to occur in video content than other specific directions. Since the goal of video compression is to reduce redundancy, in well-functioning video coding techniques, less likely directions may be represented by a greater number of bits than more likely directions.

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

[0019] In some video compression techniques, an applicable MV for a specific region of sample data can be related to other MVs, for example, other regions of sample data spatially adjacent to the region being reconstructed, and can be predicted from the MV that precedes it in the decoding order. Doing so can significantly reduce the total amount of data required to code the MV, thereby reducing redundancy and increasing compression efficiency. For example, when coding an input video signal derived from a camera (referred to as natural video), MV prediction can operate effectively because there is a statistical likelihood that a region larger than the applicable area of ​​a single MV will move in a similar direction, and consequently, in some cases, it can be predicted using similar motion vectors derived from the MVs of neighboring regions. As a result, the MV found for a given region becomes similar or identical to the MV predicted from surrounding MVs, and subsequently, after entropy coding, can be represented with fewer bits than would be used when directly coding the MV. 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 can be lossy, for example, because rounding errors occur when calculating the predictor from multiple surrounding MVs.

[0020] Various MV prediction mechanisms are described in H.265 / HEVC (ITU-T Rec. H.265, "High Efficiency Video Coding", December 2016). Among the many MV prediction mechanisms provided by H.265, the technique described here is referred to here as "spatial merge".

[0021] Referring to FIG. 2, the current block (201) contains samples discovered by the encoder during the motion search process so that they can be predicted from a previous block of the same size that is spatially shifted. Instead of directly coding the MV, the MV can be derived from metadata associated with one or more reference pictures, for example, from the most recent (in decoding order) reference picture, using the MV associated with one of five neighboring samples, denoted (denote) as A0, A1 and B0, B1, B2 (202 to 206, respectively). In H.265, the MV prediction can use the predictor of the same reference picture used by the neighboring block.

[0022] Aspects of the present disclosure provide a method and apparatus for processing video data. In some examples, the apparatus for processing video data includes a processing circuit. For example, the processing circuit determines a first syntax element for coding control in a first scope of video data coded in a bitstream. The first syntax element is associated with a coding tool for coding the position of the last significant coefficient during entropy coding of the transform coefficients. Then, in response to the first syntax element being a first value indicating the disabling of the coding tool in the first scope, the processing circuit decodes the first scope of video data coded in the bitstream without calling the coding tool, and the first scope of the coded video data includes one or more second scopes of the coded video data.

[0023] In some embodiments, the first syntax element generally contains general constraint information for coding control of a picture in the output layer set. The first value of the first syntax element indicates that the coding tool is disabled in each coded layer video sequence (CLVS) of the output layer set. The coding tool codes the position of the last effective coefficient in the transform block associated with the bottom right corner of the transform block. In some examples, the processing circuit constrains the second syntax element for coding control of the CLVS in the bitstream to have a value indicating that the coding tool is not invoked to decode the coded layer video sequence (CLVS). In one example, the value of the second syntax element indicates the nonexistence of the slice header flag associated with the coding tool in the slice header of the slice in the picture of the CLVS.

[0024] In some embodiments, in response to the first syntax element being a second value, the processing circuit determines the value of a second syntax element for coding control of a coded layer video sequence (CLVS) in the bitstream. The second syntax element indicates enabling / disabling a coding tool in the CLVS. Additionally, in some examples, in response to the value of the second syntax element indicating enabling a coding tool in the CLVS, the processing circuit decodes a slice header flag from the slice header of the slice, and the slice header flag indicates whether to use or not use a coding tool for coding the slice.

[0025] In some embodiments, to determine the value of a second syntax element, the processing circuit infers the value of a second syntax element that indicates the deactivation of a coding tool in the CLVS in response to the second syntax element not existing in the sequence parameter set (SPS) for the CLVS.

[0026] In some examples, to determine the value of the first syntax element, the processing circuit decodes the first syntax element from the syntax structure for general constraint information in response to the syntax element of the syntax structure indicating additional bits for general constraint information in the syntax structure.

[0027] An aspect of the present disclosure also provides a computer-readable non-transient medium that stores instructions that cause a computer to perform a method for video decoding when executed by a computer for video decoding. Brief explanation of the drawing

[0028] Additional features, characteristics, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and attached drawings: Figure 1a is a schematic diagram of an exemplary subset of intra-prediction modes. Figure 1b is an example of an exemplary intra-prediction direction. Figure 2 is a schematic diagram of the current block and its surrounding space merge candidates in one example. FIG. 3 is a schematic diagram of a simplified block diagram of a communication system (300) according to an embodiment. FIG. 4 is a schematic diagram of a simplified block diagram of a communication system (400) according to an embodiment. FIG. 5 is a schematic diagram of a simplified block diagram of a decoder according to an embodiment. FIG. 6 is a schematic diagram of a simplified block diagram of an encoder according to an embodiment. FIG. 7 illustrates a block diagram of an encoder according to another embodiment. FIG. 8 illustrates a block diagram of a decoder according to another embodiment. FIG. 9 illustrates an example for signaling an adaptive resolution change (ARC) parameter according to an embodiment of the present disclosure. FIG. 10 illustrates an example of a table (1000) for mapping upsampling or downsampling factors, codewords, and Ext-Golomb codes. FIG. 11 illustrates some examples of ARC parameter signaling according to some embodiments of the present disclosure. Figure 12 illustrates an example of the syntax structure of a set of PTL syntax elements in some examples. Figure 13 illustrates examples of the syntax structure of general constraint information in some examples. FIGS. 14a-14b illustrate examples of PTL information including a PTL syntax structure and a general pharmaceutical information syntax structure according to some embodiments of the present disclosure. FIGS. 15a-15b illustrate examples of general pharmaceutical information syntax structures according to embodiments of the present disclosure. FIG. 16 illustrates the syntax structure of general pharmaceutical information according to some embodiments of the present disclosure. FIG. 17 illustrates an example of a syntax structure for extending a sequence parameter set (SPS) range according to some embodiments of the present disclosure. FIG. 18 illustrates a flowchart schematically describing a process according to an embodiment of the present disclosure. FIG. 19 illustrates a flowchart schematically describing a process according to an embodiment of the present disclosure. FIG. 20 is a schematic diagram of a computer system according to an embodiment. Specific details for implementing the invention

[0029] FIG. 3 illustrates a simplified block diagram of a communication system (300) according to an embodiment of the present disclosure. The communication system (300) includes a plurality of terminal devices capable of communicating with each other, for example, through a network (350). For example, the communication system (300) includes a first pair of terminal devices (310, 320) interconnected through the network (350). In the example of FIG. 3, the first pair of terminal devices (310, 320) perform unidirectional transmission of data. For example, the terminal device (310) may encode video data (e.g., a stream of video pictures captured by the terminal device (310)) to be transmitted to another terminal device (320) through the network (350). The encoded video data may be transmitted in the form of one or more coded video bitstreams. The terminal device (320) receives coded video data from the network (350), decodes the coded video data to recover a video picture, and can display the video picture according to the recovered video data. Unidirectional data transmission may be common in media serving applications, etc.

[0030] In another example, the communication system (300) includes a second pair of terminal devices (330, 340) that perform bidirectional transmission of coded video data that may occur, for example, during a video conference. For bidirectional transmission of data, in one example, each of the terminal devices (330, 340) may code video data (e.g., a stream of video pictures captured by the terminal device) for transmission to another terminal device (330, 340) through a network (350). Each of the terminal devices (330, 340) may also receive coded video data transmitted from another terminal device (330, 340), decode the coded video data to restore the video, and display the video picture on an accessible display device according to the restored video data.

[0031] In the example of FIG. 3, the terminal devices (310, 320, 330, 340) may be exemplified as servers, personal computers, and smartphones, but the principles of the present disclosure are not limited thereto. Embodiments of the present disclosure find applications having desktop computers, laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. The network (350) represents any number of networks that transmit coded video data between terminal devices (310, 320, 330, 340), for example, including wired and / or wireless communication networks. The communication network (350) may exchange data over circuit-switched and / or packet-switched channels. Representative networks include telecommunication networks, local area networks, wide area networks, and / or the Internet. For the purposes of this discussion, the architecture and topology of the network (350) may not be important to the operation of the present disclosure unless described below.

[0032] FIG. 4 illustrates the arrangement of a video encoder and a video decoder in a streaming environment as an example of an application for the disclosed subject. The disclosed subject may be similarly applied to other video-enabled applications, such as storing compressed video on digital media including, for example, video conferencing, digital TV, CD, DVD, memory stick, etc.

[0033] A streaming system may include a capture subsystem (413) which may include a video source (401), such as a digital camera, that generates, for example, a stream (402) of uncompressed video pictures. In one example, the stream (402) of video pictures includes samples captured by the digital camera. The stream (402) of video pictures, illustrated in bold to emphasize the high data volume compared to encoded video data (404) (or coded video bitstream), may be processed by an electronic device (420) comprising a video encoder (403) coupled to the video source (401). The video encoder (403) may include hardware, software, or a combination thereof, and may enable or implement aspects of the disclosed subject matter as described in more detail below. The encoded video data (404) (or encoded video bitstream (404)), illustrated with thin lines to emphasize a lower data volume compared to the stream (402) of the video picture, may be stored in a streaming server (405) for future use. One or more streaming client subsystems, such as the client subsystems (406, 408) of FIG. 4, may access the streaming server (405) to retrieve copies (407, 409) of the encoded video data (404). The client subsystem (406) may include, for example, a video decoder (410) in an electronic device (430). The video decoder (410) decodes an incoming copy (407) of the encoded video data and generates an outgoing stream (411) of the video picture that can be rendered on a display (412) (e.g., a display screen) or another rendering device (not shown). In some streaming systems, encoded video data (404, 407, and 409) (e.g., video bitstream) may be encoded according to specific video coding / compression standards.An example of such a standard is the ITU-T recommendation H.265. In one example, a video coding standard under development is informally known as VVC (Versatile Video Coding). The disclosed topic may be used in the context of VVC.

[0034] Note that the electronic device (420, 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).

[0035] FIG. 5 illustrates a block diagram of a video decoder (510) according to an embodiment of the present disclosure. The video decoder (510) may be included 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 instead of the video decoder (410) of the example of FIG. 4.

[0036] The receiver (531) may receive one or more coded video sequences to be decoded by the video decoder (510); in the same or other embodiments, one coded video sequence at a time, and the decoding of each coded video sequence is independent of other coded video sequences. The coded video sequences may be received from a channel (501) which may be a hardware / software link to a storage device that stores the encoded video data. The receiver (531) may receive the encoded video data along with other data, such as encoded audio data and / or auxiliary data streams, which may be delivered to their respective use entries (not shown). The receiver (531) may separate the coded video sequences from the other data. To prevent network jitter, a buffer memory (515) may be combined between the receiver (531) and the entropy decoder / parser (520) (hereinafter "parser (520)"). In certain applications, the buffer memory (515) is part of the video decoder (510). Otherwise, it may be outside the video decoder (510) (not shown). Also, elsewhere, the buffer memory (not shown) may be outside the video decoder (510), for example, to prevent network jitter, and another buffer memory (515) may be inside the video decoder (510), for example, to handle playout timing. When the receiver (531) receives data from a storage / forwarding device or an isosynchronous network with sufficient bandwidth and controllability, the buffer memory (515) may not be needed or may be small.For use in a best-effort packet network such as the Internet, a buffer memory (515) may be required, and its size may be relatively large and may be implemented in an adaptive size and may be implemented at least partially in a similar element (not shown) outside of the operating system or video decoder (510).

[0037] The video decoder (510) may include a parser (520) to reconstruct symbols (521) from a coded video sequence. These categories of symbols include information used to manage the operation of the video decoder (510) and potential information for controlling a rendering device, such as a render device (512) (e.g., a display screen) that is not an essential part of the electronic device (530) but can be coupled to the electronic device (530) as illustrated in FIG. 5. The control information for the rendering device(s) may be in the form of a Supplemental Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). The parser (520) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow video coding techniques or standards and may follow various principles including variable-length coding, Huffman coding, and arithmetic coding with or without context sensitivity. The parser (520) may extract a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to a group. The subgroups may include Groups of Picture (GOP), picture, tile, slice, macroblock, Coding Unit (CU), block, Transform Unit (TU), Prediction Unit (PU), etc. The parser (520) may also extract information such as transform coefficients, quantizer parameter values, motion vectors, etc. from the coded video sequence.

[0038] The parser (520) can generate symbols (521) by performing entropy decoding / parsing operations on a video sequence received from the buffer memory (515).

[0039] The reconstruction of the symbol (521) may include a number of different units depending on the type of the coded video picture or part thereof (e.g., inter- and intra-picture, inter- and intra-block), and other factors. The units and methods involved may be controlled by subgroup control information parsed from the coded video sequence by the parser (520). The flow of this subgroup control information between the parser (520) and the number of units below is not illustrated for clarity.

[0040] Beyond the functional blocks already mentioned, the video decoder (510) can be conceptually subdivided into several functional units as described below. In actual implementations operating under commercial constraints, many of these units may interact closely with one another and be at least partially integrated. However, for the purpose of illustrating the disclosed subject, the conceptual subdivision into the functional units below is appropriate.

[0041] The first unit is a scaler / inverse transform unit (551). The scaler / inverse transform unit (551) receives control information from the parser (520) as symbol(s) (521), which includes information indicating the transform to be used, block size, quantization factor, quantization scaling matrix, as well as quantized transform coefficients. The scaler / inverse transform unit (551) can output a block containing sample values ​​that can be input to an aggregator (555).

[0042] In some cases, the output sample of the scaler / inverse transform (551) relates to an intra-coded block, that is, a block that does not use prediction information from a previously reconstructed picture but can use prediction information from a previously reconstructed part of the current picture. This prediction information may be provided by an intra-picture prediction unit (552). In some cases, the intra-picture prediction unit (552) uses already reconstructed surrounding information fetched from the current picture buffer (558) to generate a block having the same size and shape as the block being reconstructed. The current picture buffer (558) buffers, for example, a partially reconstructed current picture and / or a fully reconstructed current picture. In some implementations, 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 sample basis.

[0043] In other cases, the output samples of the scaler / inverse conversion unit (551) may be intercoded and potentially associated with a motion-compensated block. In such cases, the motion compensation prediction unit (553) may access the reference picture memory (557) to fetch samples used for prediction. After motion-compensating the fetched samples according to the symbol (521) associated with the block, these samples may be added to the output of the scaler / inverse conversion 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) where the motion compensation prediction unit (553) fetches the prediction samples may be controlled by a motion vector available to the motion compensation prediction unit (553), for example, in the form of a symbol (521) that may have X, Y, and a reference picture component. Motion compensation may also include interpolation of sample values ​​fetched from reference picture memory (557) when a sub-sample exact motion vector is in use, a motion vector prediction mechanism, etc.

[0044] The output sample of the aggregator (555) may be subject to various loop filtering techniques in the loop filter unit (556). The video compression technique may include an in-loop filter technique controlled by a parameter that is included in the coded video sequence (also referred to as the coded video bitstream) and made available to the loop filter unit (556) as a symbol (521) from the parser (520), but may also respond to meta-information obtained during the decoding of a previous (in the decoding order) part of the coded picture or coded video sequence, as well as to previously reconstructed and loop-filtered sample values.

[0045] The output of the loop filter unit (556) may be a sample stream that is not only output to the render device (512) but can also be stored in the reference picture memory (557) for future inter-picture prediction.

[0046] A specific coded picture that has been completely reconstructed can be used as a reference picture for future prediction. For example, if a coded picture corresponding to the current picture is completely reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) can become part of the reference picture memory (557), and the fresh current picture buffer can be reallocated before starting the reconstruction of the next coded picture.

[0047] A video decoder (510) can perform decoding operations according to a video compression technology predetermined in a standard such as ITU-T Rec. H.265. In the sense that the coded video sequence complies with both the syntax of the video compression technology or standard and the profile documented in the video compression technology or standard, the coded video sequence may follow the syntax specified by the video compression technology or standard in use. Specifically, the profile may select a specific tool as the only tool available in the corresponding profile from all tools available in the video compression technology or standard. Additionally, for compliance, it may be required that the complexity of the coded video sequence be within the range defined by the level of the video compression technology or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), 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 metadata for HRD buffer management signaled in the coded video sequence.

[0048] In one embodiment, the receiver (531) may receive additional (redundant) data along with the encoded video. The additional data may be included as part of the encoded video sequence(s). 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, for example, a time, spatial, or signal noise ratio (SNR) enhancement layer, redundant slice, redundant picture, forward error correction code, etc.

[0049] FIG. 6 illustrates a block diagram of a video encoder (603) according to one embodiment of the present disclosure. The video encoder (603) is included in an electronic device (620). The electronic device (620) includes a transmitter (640) (e.g., a transmitting circuit). The video encoder (603) may be used instead of the video encoder (403) in the example of FIG. 4.

[0050] The video encoder (603) can receive video samples from a video source (601) (which is not part of the electronic device (620) in the example of FIG. 6) capable of capturing video image(s) to be encoded by the video encoder (603). In another example, the video source (601) is part of the electronic device (620).

[0051] A video source (601) may provide a source video sequence to be encoded by a video encoder (603) in the form of a digital video sample stream, which may have any appropriate bit depth (e.g., 8-bit, 10-bit, 12-bit, …), any color space (e.g., BT.601 Y CrCB, RGB, …), and an appropriate sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media serving system, the video source (601) may be a storage device that stores a pre-prepared video. 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 individual pictures that impart motion when viewed in sequence. The picture itself may consist of a spatial array of pixels, where each pixel may contain one or more samples depending on the sampling structure, color space, etc. being used. Those skilled in the art can easily understand the relationship between pixels and samples. The description below focuses on samples.

[0052] According to one embodiment, the video encoder (603) can code and compress pictures of a source video sequence into a coded video sequence (643) in real time or under any other time constraint required by the application. Applying an appropriate coding speed is one of the functions of the controller (650). In some embodiments, the controller (650) controls other function units and is functionally coupled to other function units as described below. The coupling is not illustrated for clarity. Parameters set by the controller (650) may include rate control related parameters (picture skip, quantizer, lambda value of rate-distortion optimization technique, …), picture size, group of picture (GOP) layout, maximum motion vector search range, etc. The controller (650) may be configured to have other appropriate functions belonging to the video encoder (603) optimized for a specific system design.

[0053] In some embodiments, the video encoder (603) is configured to operate in a coding loop. For an oversimplified description, in one example, the coding loop includes a source coder (630) (which is responsible for generating symbols, such as a symbol stream, based on the input picture to be coded and reference picture(s)), and a (local) decoder (633) built into the video encoder (603). The decoder (633) reconstructs the symbols to generate sample data in a manner similar to that generated by the (remote) decoder (since any compression between the symbols and the coded video bitstream in the video compression techniques considered in the disclosed subject is lossless). The reconstructed sample stream (sample data) is input into the reference picture memory (634). Because the decoding of the symbol stream yields an accurate bit result regardless of the decoder location (local or remote), the content of the reference picture memory (634) is also bit-exact between the local encoder and the remote encoder. In other words, the encoder's prediction part "sees" the reference picture samples exactly the same sample values ​​that the decoder "sees" when using prediction during decoding. The fundamental principle of this reference picture synchronicity (for example, drift occurs if synchronization cannot be maintained due to channel errors) is also used in some related technologies.

[0054] The operation of the “local” decoder (633) may be the same as the operation of the “remote” decoder, such as the video decoder (510), which has already been described in detail above in relation to FIG. 5. Also, with brief reference to FIG. 5, however, since the symbols are available and the encoding / decoding of the symbols for the video sequence coded by the entropy coder (645) and the parser (520) may be lossless, the entropy decoding part of the decoder (510), including the buffer memory (515) and the parser (520), may not be fully implemented in the local decoder (633).

[0055] An observation that can be made at this point is that any decoder technique, excluding the parsing / entropy decoding present in the decoder, must also exist in the corresponding encoder in substantially the same functional form. For this reason, the disclosed subject focuses on decoder operation. The description of the encoder technique is therefore abbreviated as it is the opposite of the comprehensively described decoder technique. Further details are required only in specific areas and are provided below.

[0056] During operation, in some examples, the source coder (630) may perform motion-compensated predictive coding, which predictively codes the input picture by referencing one or more previously coded pictures from a video sequence designated as a "reference picture." In this way, the coding engine (632) codes the difference between a pixel block of the input picture and a pixel block of the reference picture(s) that can be selected as predictive reference(s) for the input picture.

[0057] The local video decoder (633) can decode the coded video data of a picture that can be designated as a reference picture based on symbols generated by the source coder (630). The operation of the coding engine (632) may advantageously be a lossy process. When the coded video data can be decoded by a video decoder (not shown in FIG. 6), the reconstructed video sequence may generally be a replica of the source video sequence with some errors. The local video decoder (633) can replicate the decoding process that can be performed by the video decoder on the reference picture and allow 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 having common content as the reconstructed reference picture to be acquired by the far-end video decoder (without transmission errors).

[0058] The predictor (635) can perform a predictive search for the coding engine (632). That is, for a new picture to be coded, the predictor (635) can search the reference picture memory (634) for sample data (as candidate reference pixel blocks) or specific metadata such as reference picture motion vectors, block shapes, etc., which can serve as appropriate predictive references for the new picture. The predictor (635) can operate on a sample block basis to find appropriate predictive references. In some cases, as determined by the search results obtained by the predictor (635), the input picture may have predictive references derived from multiple reference pictures stored in the reference picture memory (634).

[0059] The controller (650) can manage the coding operation of the source coder (630), including, for example, the settings of parameters and subgroup parameters used to encode video data.

[0060] The output of all the aforementioned function units can be entropy-coded in an entropy coder (645). The entropy coder (645) converts the symbols generated by the various function units into a coded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable-length coding, and arithmetic coding.

[0061] The transmitter (640) may buffer the coded video sequence(s) generated by the entropy coder (645) and prepare for transmission through a communication channel (660), which may be a hardware / software link to a storage device that stores the encoded video data. The transmitter (640) may merge the coded video data from the video coder (603) with other data to be transmitted, e.g., coded audio data and / or an auxiliary data stream (source not shown).

[0062] The controller (650) can manage the operation of the video encoder (603). During coding, the controller (650) can assign a specific coded picture type to each coded picture, which can affect the coding technique that can be applied to each picture. For example, a picture can often be assigned to one of the following picture types.

[0063] An Intra Picture (I Picture) may be one that can be coded and decoded without using other pictures in the sequence as a prediction source. Some video codecs allow various types of Intra Pictures, including, for example, Independent Decoder Refresh ("IDR") pictures. Those skilled in the art are aware of these variations of I Pictures and their respective applications and characteristics.

[0064] The predictive picture (P picture) may be coded and decoded using intra-prediction or inter-prediction, which uses at most one motion vector and reference index to predict the sample values ​​of each block.

[0065] A bi-directionally predictive picture (Picture B) may be coded and decoded using intra-prediction or inter-prediction that predicts sample values ​​of each block using up to two motion vectors and reference indices. Similarly, multiple predictive pictures may use two or more reference pictures and associated metadata for the reconstruction of a single block.

[0066] A source picture is typically spatially subdivided into multiple sample blocks (e.g., blocks of 4×4, 8×8, 4×8, or 16×16 samples, respectively) and can be coded on a block-by-block basis. Blocks can be predictively coded by referencing other (already coded) blocks as determined by the coding assignment applied to each picture in the block. For example, a block in picture I can be non-predictively coded or predictively coded by referencing an already coded block in the same picture (spatial prediction or intra prediction). A pixel block in picture P can be predictively coded via spatial prediction or temporal prediction by referencing one previously coded reference picture. A block in picture B can be predictively coded via spatial prediction or temporal prediction by referencing one or two previously coded reference pictures.

[0067] The video encoder (603) can perform coding operations according to a predetermined video coding technique or standard, such as ITU-T Rec. H.265. In the operation, the video encoder (603) can perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancy in the input video sequence. The coded video data can therefore follow the syntax specified by the video coding technique or standard used.

[0068] In one embodiment, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include this data as part of the encoded video sequence. The additional data may include other forms of redundant data such as time / space / SNR enhancement layers, redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0069] Video can be captured as multiple source pictures (video pictures) in a temporal sequence. Intra-picture prediction (often abbreviated as intra prediction) uses spatial correlations within a given picture, while inter-picture prediction uses (temporal or other) correlations between pictures. In one example, a specific picture being encoded / decoded, referred to as the current picture, is partitioned into blocks. When a block of the current picture is similar to a reference block of a reference picture that was previously encoded and is still buffered in the video, the block of the current picture can be encoded by a vector referred to as a motion vector. The motion vector points to a reference block within the reference picture and, if multiple reference pictures are in use, may have three dimensions that identify the reference picture.

[0070] In some embodiments, a bi-prediction technique may be used for inter-picture prediction. According to the bi-prediction technique, two reference pictures, such as a first reference picture and a second reference picture, are used, both of which are earlier in the decoding order (but may be earlier and future, respectively, in the display order) for the current picture of the video. A block of the current picture may be coded by a first motion vector pointing to a first reference block of the first reference picture and a second motion vector pointing to a second reference block of the second reference picture. A block may be predicted by a combination of the first reference block and the second reference block.

[0071] In addition, merge mode technology can be used for inter-picture prediction to improve coding efficiency.

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

[0073] FIG. 7 illustrates a diagram of a video encoder (703) according to another embodiment of the present disclosure. The video encoder (703) is configured to receive a processing block (e.g., a prediction block) of sample values ​​within the current video picture in a sequence of video pictures, and to encode the processing block into a coded picture that is part of a coded video sequence. In one example, the video encoder (703) is used instead of the video encoder (403) of the example of FIG. 4.

[0074] 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) determines whether the processing block is best coded using an intra-mode, inter-mode, or dual prediction mode, for example, using rate distortion optimization. When the processing block is coded in intra-mode, the video encoder (703) may use an intra-prediction technique to encode the processing block into a coded picture; when the processing block is coded in inter-mode or dual prediction mode, the video encoder (703) may use an inter-prediction or dual-prediction technique, respectively, to encode the processing block into a coded picture. In a specific video coding technique, a merge mode may be used as an inter-picture prediction submode in which motion vectors are derived from one or more motion vector predictors without the benefit of coded motion vector components outside the predictor. In a specific other video coding technique, there may be motion vector components applicable to the target block. In one example, the video encoder (703) includes other components, such as a mode determination module (not shown), to determine the mode of the processing block.

[0075] In the example of FIG. 7, the video encoder (703) includes an inter-encoder (730), an intra-encoder (722), a residual calculator (723), a switch (726), a residual encoder (724), a general controller (721), and an entropy encoder (725), which are combined together as shown in FIG. 7.

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

[0077] The intra-encoder (722) is configured to receive a sample of the current block (e.g., processing block), compare the block with an already coded block of the same picture in some cases, and generate quantized coefficients after conversion and, in some cases, also intra-prediction information (e.g., intra-prediction direction information according to one or more intra-encoding techniques). In one example, the intra-encoder (722) also calculates an intra-prediction result (e.g., predicted block) based on the intra-prediction information of the same picture and the reference block.

[0078] A general controller (721) is configured to determine general control data and to 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 this mode. For example, when the mode is intra mode, the general controller (721) controls the switch (726) to select an intra mode result to use in the residual calculator (723), controls the entropy encoder (725) to select intra prediction information and include the intra prediction information in the bitstream; when the mode is inter mode, the general controller (721) controls the switch (726) to select an inter prediction result to use in the residual calculator (723), controls the entropy encoder (725) to select inter prediction information and includes the inter prediction information in the bitstream.

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

[0080] The entropy encoder (725) is configured to format the bitstream to include the encoded block. The entropy encoder (725) is configured to include various information according to an appropriate standard, such as the HEVC standard. In one example, the entropy encoder (725) is configured to include general control data, selected prediction information (e.g., intra prediction information or inter prediction information), residual information, and other appropriate information in the bitstream. Note, according to the subject matter disclosed, that when coding a block in the inter mode or the merged submode of the dual prediction mode, there is no residual information.

[0081] FIG. 8 illustrates a diagram of a video decoder (810) according to another embodiment of the present disclosure. The video decoder (810) is configured to receive a coded picture that is part of a coded video sequence and to decode the coded picture to produce a reconstructed picture. In one example, the video decoder (810) is used instead of the video decoder (410) in the example of FIG. 4.

[0082] In the example of FIG. 8, the video decoder (810) includes an entropy decoder (871), an inter decoder (880), a residual decoder (873), a reconstruction module (874), and an intra decoder (872), which are combined together as shown in FIG. 8.

[0083] The entropy decoder (871) may be configured to reconstruct from the coded picture a specific symbol representing a syntax element constituting the coded picture. Such a symbol may include, for example, the mode in which the block is coded (e.g., intra mode, inter mode, dual prediction mode, merged submode, or the latter two in other submodes), prediction information (e.g., intra prediction information or inter prediction information) capable of identifying a specific sample or metadata used for prediction by the intra decoder (872) or inter decoder (880), respectively, and residual information in the form of quantized transformation coefficients, etc. In one example, when the prediction mode is an inter or dual prediction mode, the inter prediction information is provided to the inter decoder (880); and when the prediction type is an intra prediction type, the intra prediction information is provided to the intra decoder (872). The residual information may be inversely quantized and provided to the residual decoder (873).

[0084] The inter decoder (880) is configured to receive inter prediction information and generate an inter prediction result based on the inter prediction information.

[0085] The intra decoder (872) is configured to receive intra prediction information and generate a prediction result based on the intra prediction information.

[0086] The residual decoder (873) is configured to perform de-quantization to extract de-quantized transform coefficients and to process the de-quantized transform coefficients to convert the residual from the frequency domain to the spatial domain. The residual decoder (873) may also require specific control information (including Quantizer Parameters (QPs)), and this information may be provided by the entropy decoder (871) (the data path is not shown as it may be low-volume control information).

[0087] The reconstruction module (874) is configured to combine the residuals output by the residual decoder (873) and the prediction results (output by the inter or intra prediction module in some cases) in the spatial domain to form a reconstructed block that may be part of the reconstructed video and may also be part of the reconstructed video. Note that other appropriate operations, such as deblocking operations, may be performed to improve visual quality.

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

[0089] An aspect of the present disclosure provides a coding tool(s) having a constraint flag in a coded video stream and a control technique for a function.

[0090] According to one aspect of the present disclosure, the picture size in the bitstream may remain the same or change. In some related examples, video encoders and decoders may operate at a given picture size that is defined and maintained constant for a coded video sequence (CVS), a group of pictures (GOP), or a similar multi-picture timeframe. In examples such as MPEG-2, system designs are known to change the horizontal resolution (and thus the picture size) based on factors such as activity in the scene, but the picture size is defined for the GOP only in the picture and generally remains constant. Resampling of a reference picture to use different resolutions within a CVS is known, for example, from ITU-T Rec. H.263 Annex P. However, the picture size of the CVS is not changed and only the reference picture is resampled, potentially resulting in only a portion of the picture canvas being used (e.g., in the case of downsampling) or only a portion of the scene being captured (e.g., in the case of upsampling). In some examples, such as H.263 Annex Q, resampling of individual macroblocks is allowed by a factor of two in each dimension (e.g., up or down). However, the picture size remains the same. For example, when the size of a macroblock can be fixed in H.263, there is no need to signal the size of the macroblock.

[0091] In some related examples, the picture size of the predicted picture may be changed. In some examples, such as VP9, ​​resolution changes for the entire picture and resampling of the reference picture are permitted. In some examples (e.g., January 9-19, 2019, Joint Video Team document JVET-M0l35-v, “ARC (adaptive resolution change) for VVC” by Hendry et al., the full contents thereof are included herein), resampling the entire reference picture to a different resolution (e.g., a higher resolution or a lower resolution) is permitted. Different candidate resolutions may be coded in the sequence parameter set (SPS) and referenced as picture-specific syntax elements in the picture parameter set (PPS).

[0092] According to one aspect of the present disclosure, a source video may be compressed by layered coding, which encodes a picture into a bitstream comprising one or more layers having different qualities, such as different resolutions. The bitstream may have a syntax element that specifies which layer(s) (or sets of layers) can be output at the decoder side. The set of layers to be output may be defined as the output layer set. For example, in a video codec that supports multiple layers and scalability, one or more sets of output layers may be signaled in a video parameter set (VPS). A syntax element that specifies a profile tier level (PTL) for the entire bitstream or one or more sets of output layers may be signaled in a VPS, a decoder parameter set (DPS), which in some examples may be referred to as decoder capability information (DCI), an SPS, a PPS, an SEI message, etc. PTL information may contain general constraint information that can specify constraints on coding tools or functions. It is desirable to efficiently represent and signal constraint information regarding various coding tools and functions.

[0093] In some examples, the term "sub-picture" may be used to refer, for example, to samples, blocks, macroblocks, coding units, or a rectangular array of similar entities that are semantically grouped and can be coded independently at a changed resolution. One or more sub-pictures may form a picture. One or more coded sub-pictures may form a coded picture. One or more sub-pictures may be combined into a single picture, and one or more sub-pictures may be extracted from a picture. In some examples, one or more coded sub-pictures may be assembled into a coded picture in a compressed domain without transcoding at the sample level. In some examples, one or more coded sub-pictures may be extracted from a coded picture in a compressed domain.

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

[0095] In some examples, ARC encoding / decoding is performed on a picture-by-picture basis, so a set of control information (ARC parameters) is used to encode / decode a single, semantically independent coded video picture. In some examples, ARC encoding / decoding is performed on a subpicture-by-subpicture basis, so multiple subpictures within a picture can be encoded / decoded with independent ARC parameters. Note that ARC parameters can be signaled using various techniques.

[0096] FIG. 9 illustrates examples (e.g., options) of techniques for signaling ARC parameters according to some embodiments of the present disclosure. Coding efficiency, complexity, and architecture may vary from example to example. Video standards or techniques may select one or more examples or other variations for signaling ARC parameters. Examples may not be mutually exclusive and may be interchangeable based on application requirements, standard techniques, selection of encoders, etc.

[0097] According to one aspect of the present disclosure, ARC parameters may be provided as a class of ARC parameters in various ways. In some examples, a class of ARC parameters includes upsample and / or downsample factors separated or combined in the X and Y dimensions. In one example, one or more short syntax elements may be coded to point to a table containing upsample and / or downsample factors.

[0098] In some examples, the class of ARC parameters includes upsampling and / or downsampling factors, and a temporal dimension is added to indicate a constant rate of zoom in and / or zoom out for a given number of pictures. In one example, one or more short syntax elements may be coded to point to a table containing upsampling and / or downsampling factors with an added temporal dimension.

[0099] In some examples, the class of ARC parameters includes resolution in units of samples, blocks, macroblocks, CUs, or input pictures, output pictures, reference pictures, coded pictures, combined or individual any other suitable granularity in the X or Y dimension. In some examples, there is one or more resolutions used in video coding (e.g., one resolution for the input picture, another for the reference picture), and a set of values ​​(corresponding to one of the resolutions) can be inferred from another set of values ​​(corresponding to another of the resolutions). The determination of values ​​can be gated, for example, based on the use of flags. The use of flags for gating will be explained in detail in further explanation.

[0100] In some examples, the class of ARC parameters includes warping coordinates similar to those used in H.263 Annex P at appropriate granularity as described above. H.263 Annex P defines an efficient method for coding warping coordinates. Other efficient methods may be devised. For example, the variable-length reversible, Huffman-style coding of warping coordinates in Annex P may be replaced with binary coding of appropriate length, where the length of the binary codeword may be derived from the maximum picture size, offset by a value to allow warping that extends beyond the boundaries of the maximum picture size and multiplied by a factor.

[0101] In some examples, the class of ARC parameters includes upsampling and / or downsampling filter parameters. In one example, there is only a single filter for upsampling and / or downsampling. In other examples, multiple filters may be used. In some examples, filter parameters may be signaled to allow for more flexibility in filter design. Filter parameters can be selected using an index from a list of possible filter designs. Filters can be fully specified (e.g., by specifying a list of filter coefficients using an appropriate entropy coding technique), or filters can be implicitly selected through upsampling or downsampling rates signaled according to any mechanism and / or etc. described above.

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

[0103] FIG. 10 illustrates an example of a table (1000) for mapping upsampling or downsampling factors, codewords, and Ext-Golomb codes.

[0104] Note that other similar mappings may be devised depending on the application and capabilities of the upscale and downscale mechanisms available in video compression technologies or standards. In some examples, Table 1 may be appropriately extended with additional values. Note that values ​​may be represented using entropy coding mechanisms other than Ext-Golomb code, such as binary coding. In one example, entropy coding mechanisms other than Ext-Golomb code may have specific advantages when the resampling factor is of interest outside of the video processing engine (e.g., encoder and decoder), for example, by media-aware network elements (MANEs). 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 the single bit shown in Table 1) may be selected, which may have coding efficiency advantages over using binary code, for example, in the most common cases.

[0105] According to one aspect of the present disclosure, a mapping table such as Table 1 may be constructed. For example, the number of entries in Table 1 and the corresponding semantics may be constructed in whole or in part. In some examples, a basic overview of the mapping table is conveyed from a high-level set of parameters such as SPS or DPS. Alternatively, or additionally, in some examples, one or more tables similar to Table 1 may be defined in video coding techniques or standards, and one of the tables may be selected, for example, through SPS or DPS.

[0106] As described above, ARC information, such as coded upsample or downsample factors, may be included in video coding techniques or standard syntax. Note that one or more codewords may be used to control other classes of ARC information, such as upsample or downsample filters. In some examples, filters or other data structures require a relatively large amount of data.

[0107] Referring to FIG. 9, in an example (910) such as H.263 Annex P, the ARC information (912) may be in the form of four warping coordinates and is included in a picture header (911) such as in the H.263 PLUSPTYPE (913) header extension. The example (910) may be applied when i) the picture header is available and ii) frequent changes to the ARC information are expected. However, as illustrated in the example (910), the overhead when using H.263-style signaling may be high, and since the picture header may be transient, a scaling factor may not be applied between picture boundaries.

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

[0109] FIG. 9 also illustrates additional techniques, such as examples (930, 940, and 950), that can be used to convey ARC information in a video bitstream. These techniques may be used individually or in appropriate combinations within the same video coding techniques or standards.

[0110] Referring to FIG. 9, in example (930), ARC information (939), such as a resampling factor (or zoom factor), may exist in headers such as a slice header, a GOB header, a tile header, and a tile group header. A tile group header (938) is illustrated in FIG. 9 as an example. The technique illustrated in example (930) may be used when the ARC information (939) can be coded with a small number of bits, such as a single variable-length ue(v) or a fixed-length codeword of a few bits.

[0111] According to one aspect of the present disclosure, having ARC information (939) directly in a header (e.g., tile group header (938), slice header, or tile header of FIG. 9) may have additional advantages in that the ARC information (939) may be applied to a subpicture represented by, for example, a corresponding tile group (or slice, tile), rather than to the entire picture. Additionally, in one example, even if a video compression technology or standard envisions only full-picture adaptive resolution change (e.g., in contrast to tile group-based adaptive resolution change), example (930) may have certain advantages over example (910) in terms of error resilience.

[0112] Referring to FIG. 9, in example (940), ARC information (942) may exist in a parameter set (941), such as a PPS, a header parameter set, a tile parameter set, an adaptation parameter set (APS), etc. The APS (941) is illustrated in FIG. 9 as an example. In some examples, the scope of the parameter set (941) may not be larger than the picture, and may be, for example, a picture, a tile group, etc. The use of ARC information (e.g., ARC information (942)) may be implicit through the activation of the associated parameter set (e.g., APS (941)). For example, when a video coding technology or standard considers only picture-based ARC, the PPS or equivalent may be appropriate.

[0113] Referring to FIG. 9, in example (950), the ARC reference information (953) may exist in a tile group header (954) or a similar data structure (e.g., picture header, slice header, tile header, or GOP header) as described above. The tile group header (954) is illustrated in FIG. 9 as an example. The ARC reference information (953) may refer to a subset of the ARC information (955) available in a parameter set (956) having more than one picture scope, such as SPS, DPS, etc. SPS (956) is illustrated in FIG. 9 as an example.

[0114] FIG. 11 illustrates some examples of ARC parameter signaling according to some embodiments of the present disclosure. FIG. 11 illustrates examples of syntax diagrams used in video coding standards. In one example, the notation of the syntax diagram follows approximately C-style programming. Bold lines may indicate syntax elements present in the bitstream, and non-bolded lines may indicate control flow(s) or variable settings.

[0115] Referring to FIG. 11, a tile group header (1101) contains a syntax structure of a header applicable to a portion of a picture (e.g., a rectangular portion). In one example, the tile group header (1101) may conditionally contain a variable-length, Exp-Golomb-coded syntax element dec_pic_size_idx (1102) (indicated in bold). The presence of the syntax element (e.g., dec_pic_size_idx (1102)) within the tile group header (1101) may be gated based on the adaptive resolution, for example, represented by a flag (e.g., adaptive_pic_resolution_change_flag) (1103). Since the value of the flag (e.g., adaptive_pic_resolution_change_flag) (1103) is not indicated in bold, the flag is present in the bitstream at the point where the flag occurs in the syntax diagram. Whether adaptive resolution is used for a picture or a part of a picture can be signaled by a high-level syntax structure (e.g., SPS (1110) in FIG. 11) inside or outside the bitstream.

[0116] Referring to FIG. 11, an excerpt of an SPS (1110) is shown. 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 an adaptive resolution that may require specific control information. In one example, specific control information is conditionally present based on the value of the flag (1111), as illustrated by the if() statement (1112) of the SPS (1110) and the tile group header (1101).

[0117] As illustrated in the example of FIG. 11, when adaptive resolution is in use, the output resolution (or resolution of the output picture) (1113) in samples can be coded. In one example, the output resolution (1113) is coded based on width resolution (e.g., output_pic_width_in_luma_samples) and height resolution (e.g., output_pic_height_in_luma_samples). In a video coding technique or standard, specific limits on the value of the output resolution (1113) may be defined. For example, a level definition may limit the total number of output samples (e.g., the product of output_pic_width_in_luma_samples and output_pic_height_in_luma_samples). In some examples, video coding technology or standards, or external technology or standards (e.g., system standards) may limit the numbering range for width resolution and / or height resolution (e.g., width resolution and / or height resolution are divisible by powers of 2), aspect ratio of width resolution to height resolution (e.g., the ratio of width resolution to height resolution is 4:3 or 16:9), etc. In one example, the above limitations may be introduced to facilitate hardware implementation.

[0118] In certain applications, the encoder may instruct the decoder to use a specific reference picture size rather than implicitly assuming that the size is the output picture size. For example, a syntax element (e.g., reference_pic_size_present_flag) (1114) gates the conditional existence of reference picture dimensions (1115). In one example, the reference picture dimensions (1115) may include both width (e.g., reference_pic_width_in_luma_samples) and height (e.g., reference_pic_height_in_luma_samples).

[0119] Additionally, in FIG. 11, a table of applicable decoding picture widths and heights is illustrated. In one example, the number of entries in the table may be indicated by a table indicator (e.g., the syntax element num_dec_pic_size_in_luma_samples_minus1) (1116). "minus1" may indicate the value interpretation of the syntax element (1116). For example, if the coded value is 0, there is one table entry. If the coded value is 5, there are six table entries. For each entry in the table, the decoded picture width and height are included as a syntax element (1117).

[0120] Table entries represented by the syntax element (1117) can be indexed using the syntax element dec_pic_size_idx (1102) of the tile group header (1101), thus allowing different decoded sizes and zoom factors for each tile group.

[0121] According to one aspect of the present disclosure, a specific video coding technique or standard (e.g., VP9) may enable spatial scalability by implementing a specific form of reference picture resampling along with temporal scalability. In one embodiment, the reference picture is upsampled to a higher resolution using an ARC-style technique to form the basis of a spatial enhancement layer. The upsampled picture may be refined using a general prediction mechanism at high resolution (e.g., motion-compensated prediction for inter-prediction from the reference picture) to add details, for example.

[0122] In some examples, the value of the time ID field in the network abstraction layer (NAL) unit header is used to indicate both temporal layer information and spatial layer information. By using the NAL unit header value to indicate both temporal and spatial layer information, existing selected forwarding units (SFUs) can be used for scalable environments without modification. For example, existing SFUs can be generated and optimized for temporal layer selected forwarding based on the NAL unit header time ID value. Then, existing SFUs can be used for spatial scalability (e.g., selection of spatial layers) without modification in some examples. In some examples, a mapping can be provided between the coded picture size and the temporal layer indicated by the temporal ID field within the NAL unit header.

[0123] According to one aspect of the present disclosure, some features of a coded bitstream may be specified using profile, tier and level combination (PTL) information, which includes profile, tier, level, and general constraint information. In some examples, the profile defines a subset of bitstream features such as color reproduction, resolution, and additional video compression. A video codec may 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), and a main profile (e.g., a profile with an intermediate compression ratio between the baseline profile and the high profile, which may be the default profile setting).

[0124] Additionally, tiers and levels can be used to specify particular constraints defining a bitstream regarding the maximum bit rate, maximum luma sample rate, maximum luma picture size, minimum compression ratio, maximum number of allowed slices, and maximum number of allowed tiles. Lower tiers are more restrictive than higher tiers, and lower levels are more restrictive than higher levels. In one example, the standard may define two tiers: Main and High. The Main tier is lower than the High tier. Tiers are designed to handle applications with different maximum bit rates. The Main tier is designed for most applications, while the High tier is designed for, for example, very demanding applications. The standard may define multiple levels. A level is a set of constraints for a bitstream. In one example, for levels below level 4, only the Main tier is allowed. In some examples, a decoder compliant with a given tier / level must be able to decode all bitstreams encoded for that tier / level and all lower tiers / levels.

[0125] General constraint information may include constraint information regarding video source types, coding tools, and functions. For example, constraint flags may indicate whether intercoding tools, intracoding tools, DBF, entropy coding, transformations, partitioning (e.g., tile, slice), buffer management, random access (e.g., IDR), parameter sets (e.g., SPS, PPS), etc., are present or used in the coded video bitstream. Constraint information may be signaled in parameter sets (e.g., SPS, VPS, or DCI). Constraint flags may be signaled in high-level syntax structures (e.g., SPS, VPS, DCI).

[0126] According to some aspects of the present disclosure, PTL information may be associated with a scope (e.g., a portion of video data encoded 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) of the bitstream, etc., and may be signaled in high-level syntax (HLS) structures such as VPS, DPS, DCI, SPS, PPS, APS, GOP, sequence, header, SEI message, etc.

[0127] In some examples, high-level syntax (HLS) is defined for the block level. Block-level coding tools can be used to decode pixels or samples within a picture to reconstruct the picture. Block-level coding tools may include any appropriate coding tools used for the reconstruction of coding blocks, such as coding tools for inter-prediction (or inter-coding tools), coding tool(s) for intra-prediction (or intra-coding tools), adaptive loop filters (ALF), deblocking filters (DBF), entropy coding, transformations, etc.

[0128] High-level syntax (HLS) can specify information regarding functions, system interfaces, picture-level control of tools, and buffer control. For example, HLS can specify partitions (e.g., tiles, slices, subpictures), buffer management, random access (e.g., IDR, CRA (clean random access)), parameter set(s) (e.g., VPS, SPS, PPS, APS), RPR (reference picture resampling), scalability, etc. High-level syntax can be above the block level.

[0129] Control information may have appropriate levels, such as SPS level tool control information, PPS level tool control information, sequence level control information, bitstream level control information, etc. In some examples, PTL information is part of the control information and may be signaled as a constraint flag in the HLS structure, and may indicate the control or constraint of the tool in the scope corresponding to the HLS structure. For example, the constraint flag for the PTL information may be provided as either sequence level control information or bitstream level control information. In one example, if a specific tool is disabled by a constraint flag in the HLS structure, the tool is not used, for example, for a coding block of the scope corresponding to the HLS.

[0130] FIGS. 12 and FIGS. 13 illustrate examples of PTL information according to some embodiments of the present disclosure. FIG. 12 illustrates an example of a syntax structure (1200) of a set of PTL syntax elements, and FIG. 13 illustrates an example of a syntax structure (1300) of general pharmaceutical information.

[0131] In FIG. 12, the set of PTL syntax elements 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.

[0132] In FIG. 13, general constraint information may include multiple constraint flags. In one example, a constraint flag equal to 1 (e.g., intra_only_constraint_flag) (1305) may indicate that the parameter sh_slice_type must be I (i.e., the slice is an intra-slice). The parameter sh_slice_type is a parameter of the slice header that specifies the coding type of the slice between types I, P, and B. A constraint flag equal to 0 (e.g., intra_only_constraint_flag) (1305) does not impose a constraint (e.g., sh_slice_type must be I) on all coded pictures within the scope of the PTL information, where other information (e.g., profile_idc) may allow non-intra-slices. In another example, a constraint flag such as 1 (e.g., no_alf_constraint_flag) (1306) may indicate that sps_alf_enabled_flag is equal to 0 for all CVS within the scope of PTL information, and thus adaptive loop filtering is not used even if adaptive loop filtering is allowed, for example, based on profile_idc. A constraint flag such as 0 (e.g., no_alf_constraint_flag) (1306) does not impose the above constraint.

[0133] In another example, a constraint flag (e.g., no_lossless_coding_tool_constraint_flag) (1301) may be signaled in general constraint information as illustrated in FIG. 13. A constraint flag such as 1 (e.g., no_lossless_coding_tool_constraint_flag) (1301) may indicate that coding tool(s) related to lossless coding cannot be used within the scope of PTL information containing the constraint flag (1301). A constraint flag such as 0 (e.g., no_lossless_coding_tool_constraint_flag) (1301) does not impose the above constraint.

[0134] In another example, a constraint flag (e.g., no_lossy_coding_tool_constraint_flag) (1302) may be signaled in general constraint information as illustrated in FIG. 13. A constraint flag such as 1 (e.g., no_lossy_coding_tool_constraint_flag) (1302) may indicate that the coding tool(s) associated with lossy coding cannot be used within the scope of the PTL information containing the constraint flag (1302). A constraint flag such as 0 (e.g., no_lossy_coding_tool_constraint_flag) (1302) does not impose the above constraint.

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

[0136] Multiple constraint flags in general constraint information can be arranged in a specific order. The order may be established, for example, based on the likelihood that each mechanism and / or tool will not be used within the scope of the PTL. This order can be referred to as priority. The order may be presented in the general constraint information syntax structure from high priority to low priority, where high priority indicates a high probability that the tool (or mechanism) will not be used, and low priority indicates a low probability that the tool (or mechanism) will not be used. Additional factors influencing the order may include tools used only for specific use cases (e.g., tools for subpictures, scalability, and / or interlacing support), and the impact of the tool on encoder / decoder / implementation complexity.

[0137] FIGS. 14a and 14b illustrate examples of PTL information including a syntax structure example (1410) of a PTL syntax structure (also called a PTL bracket) and a syntax example (1420) for a general constraint information syntax structure (also called a general constraint information bracket) according to some embodiments of the present disclosure. In some examples, a syntax element (e.g., num_available_constraint_flags) indicating the number of constraint flags may be signaled. In one example, the syntax element indicating the number of constraint flags may be signaled to the PTL syntax structure, as shown as (1401) in the syntax example (1410) illustrated in FIG. 14a, which may be outside the syntax example (1420) for the general constraint information bracket. Alternatively, a syntax element indicating the number of constraint flags may be signaled at the beginning of a general constraint information bracket, such as the beginning of the syntax example (1420). When a syntax element (e.g., num_available_constraint_flags) exists and the value of the syntax element (e.g., num_available_constraint_flags) is equal to N, a first N constraint flags may exist in the general constraint information syntax structure. Additionally, other constraint flags may not exist and may be inferred to be equal to a specific value. N may be a non-negative integer.

[0138] In one embodiment, the value N (e.g., num_available_constraint_flags) is in the range from 0 to the maximum number of constraint flags (e.g., the value of the parameter MaxNumConstraintFlags). The maximum number of constraint flags may be a positive integer. The value of the maximum number of constraint flags (e.g., MaxNumConstraintFlags) may be predefined as 16, 32, 64, 128, etc. When the value N (e.g., num_available_constraint_flags) is equal to 0, there are no constraint flags in the general constraint information syntax structure. The coding of the value N (e.g., num_available_constraint_flags) may be selected such that the corresponding entropy-coded representation for the value N and the constraint flags can be added up to a number divisible by 8 to ensure byte alignment.

[0139] In some examples, a constraint flag may 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 a corresponding constraint information group may indicate whether the constraint flag(s) of the corresponding constraint information group may exist. In one example, the gate flag may be referred to as a constraint group presence flag. Generally, the gate flag is associated with the corresponding constraint information group and is associated with the constraint flag(s) of the corresponding constraint information group. In one embodiment, the gate flag gates whether the constraint flag(s) of the corresponding constraint information group exist (or are signaled) in the constraint information. For example, if the gate flag of the corresponding constraint information group is equal to 1, the constraint flag(s) corresponding to the constraint information group may exist, for example, in general constraint information. If the gate flag of the corresponding constraint information group is equal to 0, the constraint flag(s) corresponding to the constraint information group may not exist, for example, in general constraint information. In one example, if all gate flags are equal to 0, the constraint flag does not exist.

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

[0141] FIGS. 15a–15b illustrate an example of a general pharmaceutical information syntax structure (1500) according to an embodiment of the present disclosure. The general pharmaceutical information syntax structure (1500) includes a flag representing general pharmaceutical information. Specifically, the general constraint information syntax structure (1500) in FIG. 15a includes a gate flag (e.g., general_frame_structure_constraint_group_flag) (1501), a gate flag (e.g., high_level_functionality_constraint_group_flag) (1502), a gate flag (e.g., scalability_constraint_group_flag) (1503), a gate flag (e.g., partitioning_constraint_group_flag) (1504), a gate flag (e.g., intra_coding_tool_constraint_group_flag) (1505), a gate flag (e.g., inter_coding_tool_constraint_group_flag) (1506), a gate flag (e.g., transfom_constraint_group_flag) (1507), and a gate flag (e.g., inloop_filtering_constraint_group_flag) (1508). One or more gate flags (e.g., gate flags (1501)-(1508)) may be present at the beginning of the general constraint information syntax structure (1500) as shown in FIG. 15a.

[0142] A gate flag (e.g., general_frame_structure_constraint_group_flag) (1501) is associated with a constraint information group (1510) and with constraint flags (1511)-(1514) in the constraint information group (1510). A gate flag (e.g., general_frame_structure_constraint_group_flag) (1501) such as 1 may specify that constraint flags (1511)-(1514) in the constraint information group (1510) may exist.

[0143] The constraint information group (1510) (or constraint flags (1511)-(1514)) may be related to the input source and frame packing (e.g., packed frame or projected frame). Referring to 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 gate flag such as 0 (e.g., general_frame_structure_constraint_group_flag) (1501) may specify that the constraint flags (1511)-(1514) in the constraint information group (1510) may not exist in the general constraint information syntax structure (1500).

[0144] Additionally, in some examples, a gate flag such as 1 (e.g., high_level_functionality_constraint_group_flag) (1502) may specify that a constraint flag related to a high-level function (e.g., reference picture resampling) in the constraint information group (1520) may exist as illustrated in FIG. 15b. Otherwise, a gate flag such as 0 (e.g., high_level_functionality_constraint_group_flag) (1502) may specify that a constraint flag in the constraint information group (1520) may not exist in the general constraint information syntax structure (1500).

[0145] Referring again to FIG. 15a, a gate flag such as 1 (e.g., scalability_constraint_group_flag) (1503) may specify that scalability-related constraint flag(s) (e.g., inferlayer prediction) may exist. Otherwise, scalability-related constraint flag(s) may not exist in the general constraint information syntax structure (1500).

[0146] A gate flag such as 1 (e.g., partitioning_constraint_group_flag) (1504) may specify that there may be constraint flag(s) related to high-level partitioning (e.g., subpicture or tile). Otherwise, there may not be constraint flags related to high-level partitioning in the general constraint information syntax structure (1500).

[0147] A gate flag such as 1 (e.g., intra_coding_tool_constraint_group_flag) (1505) may specify that there may be constraint flag(s) related to intra-coding (e.g., intra-prediction). Otherwise, the constraint flag(s) related to intra-coding may not exist in the general constraint information syntax structure (1500).

[0148] A gate flag such as 1 (e.g., inter_coding_tool_constraint_group_flag) (1506) may specify that there may be constraint flag(s) related to intercoding (e.g., motion compensation for interpicture prediction). Otherwise, the constraint flags related to intercoding may not exist in the general constraint information syntax structure (1500).

[0149] A gate flag such as 1 (e.g., transform_constraint_group_flag) (1507) may specify that there may be constraint flag(s) associated with transformation coding (e.g., multiple transformation matrices). Otherwise, constraint flags associated with transformation coding may not exist in the general constraint information syntax structure (1500).

[0150] In one embodiment, when all gate flags (e.g., gate flags (1501)-(1508) of FIG. 15a) are equal to 0, the constraint flag does not exist in the general constraint information syntax structure (e.g., general constraint information syntax structure (1500)).

[0151] According to aspects of the present disclosure, the syntax may be byte-aligned, for example, the number of flags may be divided by 8 to maintain byte alignment. In one example, the number of gate flags and constraint flags of the constraint information structure (1501)-(1508)), associated constraint flags (e.g., constraint flags (1511)-(1512) and constraint flags of the constraint information group (1520), additional control information, etc. Referring to FIG. 15b, a syntax (e.g., a while loop) (1530) may be used for byte alignment.

[0152] In some embodiments, offset information, such as an offset (e.g., using the syntax element constraint_info_offset[]), and length information, such as a length (e.g., using the syntax element constraint_info_length[]), exist in the constraint information (e.g., at the beginning of a general constraint information syntax structure) to assist in presenting the constraint flag(s) in each constraint information group(s) associated with the gate flag(s) of the constraint information. In one embodiment, at least one of the constraint information groups exists in the coded video bitstream. For the constraint information group, an offset and a length may exist in the constraint information for the constraint information group. The offset may indicate the offset for 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 the syntax element num_constraint_info_set. The value of num_constraint_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 do not exist in the general constraint information syntax structure.

[0153] In one embodiment, the constraint information offset (e.g., syntax element constraint_info_offset[i]) and the constraint information length (e.g., syntax element constraint_info_length[i]) support presenting constraint flags for constraint information group i (i is a positive integer) in the 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 constraint flag, the sixth constraint flag, and the seventh constraint flag are associated with constraint information group i and exist in the constraint information (e.g., a general constraint information syntax structure).

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

[0155] In one embodiment, run-coding in which constraint flags are assigned in a predetermined order (or a given order) may be used. Instead of directly coding the constraint flags, a list of appropriately coded "skip" values ​​may indicate a constraint flag such as 0, and the next constraint flag is implied to be such as 1. The run-coding described above may be particularly efficient if (i) the number of constraint flags is large and (ii) a small percentage of the constraint flags is equal to 1.

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

[0157] In one embodiment, at least one constraint flag within a constraint information group of gate flags includes a plurality of constraint flags that are signaled according to a predetermined order. Accordingly, the plurality of constraint flags can be run-coded (e.g., run-encoded or run-decoded).

[0158] In one embodiment, the entire list of constraint flags may be specified in a video coding standard (e.g., VVC specification), an external table, etc. In one example, only the available constraint flag(s) among 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), gate flag(s) (or constraint group presence flag(s)), constraint information offset information and constraint information length information, etc., are present in the coded video stream.

[0159] In one example, a complete list of constraint flags is specified and is available to the encoder and decoder. The complete list of constraint flags may be stored in the decoder. The complete list of constraint flags may contain 100 constraint flags. Ten of the 100 constraint flags exist in the constraint information for CLVS and are therefore available to a subset of coding blocks of CLVS. The ten of the 100 constraint flags are referred to as the 10 available constraint flags. In one example, the number of available constraint flags (e.g., 10) is signaled. In one example, the 10 available constraint flags are in two groups of constraint information and are gated by a first gate flag and a second gate flag. Thus, the first gate flag and the second gate flag may be signaled to indicate the 10 available constraint flags.

[0160] 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, since syntax element constraint_info_offset[0] is 15 and syntax element constraint_info_length[0] is 3, and syntax element constraint_info_offset[1] is 82 and syntax element constraint_info_length[1] is 7, it indicates that the 15th through 17th constraint flags and the 82nd through 88th constraint flags (e.g., 100 constraint flags) are available or exist in the constraint information.

[0161] In one embodiment, any one of the various techniques (or methods, embodiments, examples) for efficient coding of constraint flags may be combined using appropriate control information. The combination may be a suitable combination of two or more of these techniques. Alternatively, one of the various techniques (or methods, embodiments, examples) may be used independently. Constraint flags may be grouped. In certain group(s), run-coding may be used, while in other group(s), simple (straightforward) binary coding may be used.

[0162] The maximum number of constraint flags (e.g., MaxNumConstraintFlags) can be predefined as 16, 32, 64, 128, etc.

[0163] Since the value of the maximum number of constraint flags (e.g., MaxNumConstraintFlags) can be determined by profile information or codec version information such as general_profile_idc or general_sub_profile_idc, the range of the number of constraint flags (e.g., num_available_constraint_flags(1401)) can be limited by profile information or version information. For example, in the main profile (e.g., where MaxNumConstraintFlags = 64), the value of the number of constraint flags (e.g., num_available_constraint_flags(1401)) can be in the range from 0 to 64, whereas in the enhanced profile (e.g., where MaxNumConstraintFlags = 128), the value of the number of constraint flags (e.g., num_available_constraint_flags(1401)) can be in the range from 0 to 128.

[0164] In one embodiment, the value of the number of constraint flags (e.g., num_available_constraint_flags) can be inferred to be the same as a value predefined by profile information or codec version information such as general_profile_idc or general_sub_profile_idc, so the value of num_available_constraint_flags can be determined without explicitly signaling.

[0165] In some embodiments, reserved byte information may exist in the general constraint information syntax structure. For example, as illustrated in FIG. 13, flags gci_num_reserved_bytes (1303) and gci_reserved_bytes[] (1304) may exist in the general constraint information syntax structure for extension of 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 intended to signal additional flags (e.g., additional constraint flags). The flag gci_reserved_byte[] may have appropriate values.

[0166] In one embodiment, the value of gci_num_reserved_bytes may be limited or determined by profile information or codec version information, such as general_profile_idc or general_sub_profile_idc. When using the base profile (or main profile), the value of the flag gci_num_reserved_bytes may be 0. When using the extended profile (or enhanced profile), the value of gci_num_reserved_bytes may be greater than 0.

[0167] In some embodiments, a field sequence flag may be signaled in the coded video bitstream. The field sequence flag may indicate whether a picture of 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. A flag sps_field_seq_flag such as 1 may indicate that the CLVS is delivering a picture representing a field. A flag sps_field_seq_flag such as 0 may indicate that the CLVS is delivering a picture representing a frame.

[0168] In the general constraint information syntax structure of FIG. 13, a flag general_frame_only_constraint_flag may exist. A flag general_frame_only_constraint_flag, such as 1, may specify that a scope (e.g., OlsInScope) for an output layer set delivers a picture representing a frame. A flag general_frame_only_constraint_flag, such as 0, may specify that a scope (e.g., OlsInScope) for an output layer set delivers a picture that may or may not represent a frame. In one embodiment, the flag general_frame_only_constraint_flag indicates whether the picture in the output layer set is coded by field coding. An output layer set may contain a subset of coding blocks. The flag sps_field_seq_flag may be false based on the flag general_frame_only_constraint_flag (e.g., 1), which indicates that a subset of the picture is not coded by field coding. A subset of the picture can be on one layer of the output layer set.

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

[0170] In one embodiment, the flag pps_mixed_nalu_types_in_pic_flag may exist in the PPS. A flag such as 1 pps_mixed_nalu_types_in_pic_flag may specify that each picture referencing the PPS has one or more VCL NAL units and that the VCL NAL units do not have nal_unit_type of the same value. A flag such as 0 pps_mixed_nalu_types_in_pic_flag may specify that each picture referencing the PPS has one or more VCL NAL units and that the VCL NAL units of each picture referencing the PPS have nal_unit_type of the same value. In the general constraint information syntax structure of FIG. 13, the flag no_mixed_nalu_types_in_pic_constraint_flag may exist. The flag no_mixed_nalu_types_in_pic_constraint_flag, which is 1, can specify that the value of pps_mixed_nalu_types_in_pic_flag must be equal to 0. The flag no_mixed_nalu_types_in_pic_constraint_flag, which is 0, does not impose these constraints.

[0171] In one embodiment, the flag general_one_picture_only_constraint_flag may exist in the general constraint information syntax structure as illustrated in FIG. 13. A general_one_picture_only_constraint_flag such as 1 may specify that there is only one coded picture in the bitstream. A flag general_one_picture_only_constraint_flag such as 0 does not impose such a constraint.

[0172] In one embodiment, the flag single_layer_constraint_flag may exist in the general constraint information syntax structure as illustrated in FIG. 13. A flag single_layer_constraint_flag equal to 1 may specify that sps_video_parameter_set_id must be equal to 0. A flag single_layer_constraint_flag equal to 0 does not impose this constraint. When the flag general_one_picture_only_constraint_flag equals 1, the value of the flag single_layer_constraint_flag may be equal to 1.

[0173] In one embodiment, the flag all_layers_independent_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. A flag all_layers_independent_constraint_flag such as 1 may specify that the flag vps_all_independent_layers_flag may be equal to 1. A flag all_layers_independent_constraint_flag such as 0 does not impose these constraints. 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.

[0174] In one embodiment, the flag no_res_change_in_clvs_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. A flag no_res_change_in_clvs_constraint_flag, such as 1, may specify that the flag sps_res_change_in_clvs_allowed_flag may be equal to 0. When the flag no_res_change_in_clvs_constraint_flag is equal to 0, these constraints are not imposed. When the flag no_ref_pic_resampling_constraint_flag is equal to 1, the value of the flag no_res_change_in_clvs_constraint_flag may be equal to 1.

[0175] In one embodiment, the flag no_mixed_nalu_types_in_pic_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. A flag no_mixed_nalu_types_in_pic_constraint_flag such as 1 specifies that the value of the flag pps_mixed_nalu_types_in_pic_flag may be equal to 0. A flag no_mixed_nalu_types_in_pic_constraint_flag such as 0 does not impose such constraints. 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.

[0176] In one embodiment, the flag no_trail_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. A flag no_trail_constraint_flag such as 1 may specify that there may be no NAL units having nuh_unit_type, such as TRAIL_NUT, present in OlsInScope (OlsInScope is a set of output layers containing all layers of the entire bitstream referencing DPS). A flag no_trail_constraint_flag such as 0 does not impose such constraints. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_trail_constraint_flag may be equal to 1.

[0177] In one embodiment, the flag no_stsa_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. A flag no_stsa_constraint_flag such as 1 may specify that there may be no NAL units having a nuh_unit_type such as STSA_NUT present in OlsInScope. A flag no_stsa_constraint_flag such as 0 does not impose such constraints. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_stsa_constraint_flag may be equal to 1.

[0178] In one embodiment, the flag no_trail_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. A flag no_trail_constraint_flag such as 1 may specify that there may be no NAL units having a nuh_unit_type such as TRAIL_NUT present in OlsInScope. A flag no_trail_constraint_flag such as 0 does not impose such constraints. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_trail_constraint_flag may be equal to 1.

[0179] In one embodiment, the flag no_stsa_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. A flag no_stsa_constraint_flag such as 1 may specify that there may be no NAL units having a nuh_unit_type such as STSA_NUT present in OlsInScope. A flag no_stsa_constraint_flag such as 0 does not impose such constraints. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_stsa_constraint_flag may be equal to 1.

[0180] In one embodiment, the flag no_idr_constraint_flag may exist in the general constraint information syntax structure as illustrated in FIG. 13. A no_idr_constraint_flag such as 1 may specify that there may be no NAL units having nuh_unit_type, such as IDR_W_RADL or IDR_N_LP, present in OlsInScope. A flag no_idr_constraint_flag such as 0 does not impose such constraints.

[0181] In one embodiment, the flag no_cra_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. A flag no_cra_constraint_flag such as 1 may specify that there may be no NAL units having nuh_unit_type, such as CRA_NUT, present in OlsInScope. If the flag no_cra_constraint_flag is equal to 0, such as 0, these constraints are not imposed.

[0182] In one embodiment, the flag no_rasl_constraint_flag may exist in the general constraint information syntax structure of FIG. 13 (the flag no_rasl_constraint_flag is not shown). A flag no_rasl_constraint_flag such as 1 may specify that there may be no NAL units having a nuh_unit_type such as RASL_NUT present in OlsInScope. A flag no_rasl_constraint_flag such as 0 does not impose such constraints. When the flag no_cra_constraint_flag is equal to 1, the value of the flag no_rasl_constraint_flag may be equal to 1.

[0183] In one embodiment, the flag no_radl_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. A flag no_radl_constraint_flag such as 1 may specify that there may be no NAL units having a nuh_unit_type such as RADL_NUT present in OlsInScope. A flag no_radl_constraint_flag such as 0 does not impose such constraints. 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.

[0184] Some aspects of the present disclosure provide a technique for signaling a constraint flag for range expansion, such as range expansion to position coding for the last effective coefficient in residual coding.

[0185] According to one aspect of the present disclosure, some standards may originally be developed for specific applications having a specific chroma format and a specific bit depth (bits per sample). For example, HEVC originally targets applications with a 4:2:0 chroma format at 8-10 bits per sample. To enable the standard to be applied to other formats and bit depths other than the specific chroma format and bit depth, a scope extension is developed to support applications using other chroma formats and / or higher bit depths.

[0186] To restrict feature sets to those required by a specific group of applications, video coding standards define profiles that may include a defined set of decoder features supported for 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 conforming bitstream. In addition to profiles, some standards (e.g., VVC, HEVC, etc.) also define levels and tiers. Levels impose limits on bitstreams related to spatial resolution, pixel rate, bitrate values, and variations to accommodate decoder processing load and memory capabilities. Level limits can be expressed as maximum sample rate, maximum picture size, maximum bitrate, minimum compression ratio, or the capacity of the coded picture buffer. Higher level values ​​may indicate higher complexity limits. Tiers modify the bitrate value and variation limits for each level. For example, the main tier is intended for most applications, while the high tier is designed to handle more demanding video contribution applications, such as those with much higher bitrate values ​​than video distribution applications. Each of the profile, tier, and level affects implementation and decoding complexity, and combinations of the three specify interoperability points for bitstreams and decoders.

[0187] In some examples, a decoder compliant with a specific tier and level must be able to decode any bitstream compliant with the same tier, a tier below that level, or any level lower than that, and a decoder compliant with a specific profile may support all features of that profile. In some examples, the encoder does not need to use any specific set of features supported by the profile, but must generate a compliant bitstream—that is, a bitstream compliant with specified constraints that allow it to be decoded by a compliant decoder.

[0188] In addition to PTL information, the PTL syntax structure may also include a general constraints information (GCI) syntax structure that includes a non-flag syntax element indicating specific constraint attributes of the bitstream and a list of constraint flags.

[0189] In one example, HEVC includes three profiles originally referred to as the Main Profile, Main 10 Profile, and Main Still Picture Profile. The three profiles have several limitations, such as supporting only 4:2:0 chroma sampling. In the Main and Main Still Picture Profiles, only 8 bits of video precision per sample are supported, whereas the Main 10 Profile supports up to 10 bits per sample. In the Main Still Picture Profile, the entire bitstream contains only one coded picture.

[0190] In some examples, HEVC with range extension may support additional profiles. In one example, the following 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 10 Intra profile, Main 12 Intra profile, Main 4:2:2 10 Intra profile, Main 4:2:2 12 Intra profile, Main 4:4:4 16 Intra profile, Main 4:4:4 Still Picture profile and Main 4:4:4 16 Still Picture profile are collectively referred to as range extension profiles.

[0191] Some of the range extension profiles can support higher bit depths and can be described as profiles for operating range extension with high bit depths. In some examples, profiles for operating range extension with high bit depths include profiles that support more than 10 bits per sample, such as the 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.

[0192] Specifically, the main 12 profile supports 4:0:0 and 4:2:0 chroma sampling in both intra-prediction mode and inter-prediction mode, allowing bit depths of 8 to 12 bits per sample. In some examples, a decoder compliant with the main 12 profile can decode bitstreams made of the following profiles: monochrome, monochrome 12, main, main 10, and main 12.

[0193] The main 12 4:4:4 profile supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, intra-prediction mode, and inter-prediction mode, allowing bit depths of 8 to 12 bits per sample. In some examples, a decoder compliant with the main 12 4:4:4 profile can decode bitstreams made with 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, monochrome 12.

[0194] The main 16 4:4:4 profile supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, intra-prediction mode, and inter-prediction mode, allowing bit depths of 8 to 16 bits per sample.

[0195] The main 12 intra profile allows a bit depth of 8 to 12 bits per sample, supporting 4:0:0 and 4:2:0 chroma sampling and intra prediction modes.

[0196] The main 12 4:4:4 intra profile supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and intra prediction modes, allowing bit depths of 8 to 12 bits per sample.

[0197] The main 16 4:4:4 intra profile supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and intra prediction modes, allowing bit depths of 8 to 16 bits per sample.

[0198] The main 12 Still Picture Profile supports 4:0:0 and 4:2:0 chroma sampling, allowing bit depths of 8 to 12 bits per sample. In the main 12 Still Picture Profile, the entire bitstream contains only one coded picture.

[0199] The main 12 4:4:4 still picture profile supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, allowing bit depths of 8 to 12 bits per sample. In the main 12 4:4:4 still picture profile, the entire bitstream contains only one coded picture.

[0200] The main 16 4:4:4 still picture profile supports 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, allowing bit depths of 8 to 16 bits per sample. In the main 16 4:4:4 still picture profile, the entire bitstream contains only one coded picture.

[0201] According to some aspects of the present disclosure, coding tool control may be performed in various scopes, such as a bitstream scope, a coded layer video sequence (CLVS) scope, a picture, a slice of a picture, etc. (e.g., a part of coded video data coded by persistence of instances of syntax elements for coding tool control). In some examples, coding tool control may be provided in a general constraint information (GCI) syntax structure that generally contains constraint information for the bitstream. In some examples, coding tool control may be provided in a sequence parameter set (SPS) associated with the CLVS, and the SPS generally contains information about the CLVS. In some examples, coding tool control may be provided in a slice header of a slice, and the slice header generally contains information about the slice.

[0202] According to one aspect of the present disclosure, control information for a coding tool in a scope extension may be provided in various scopes. In some examples, using syntax elements of a larger scope may improve coding efficiency. For example, a GCI syntax element value greater than 0 generally indicates that the bitstream is restricted in a specific way to indicate that a specific coding tool is not used in the bitstream. Additionally, a GCI syntax element value such as 0 signals that the associated constraint may not apply, thereby allowing the associated coding tool to be used in the bitstream (if its use is supported in the indicated profile) (though not mandatory).

[0203] According to another aspect of the present disclosure, when a coding tool is not used for coding video data in a bitstream, for example, when PTL information and / or general constraint information indicates that a coding tool is not used, the video decoder without the support of a coding tool can determine that the video decoder can decode the bitstream based on the signaling of PTL information and / or general constraint information and that the capabilities of the video decoder can be extended.

[0204] In some embodiments, the encoder may generate a bitstream compliant with the video standard having range extension, but does not use one or more features supported by the range extension. In some examples, a decoder compliant with the video standard but not supporting one or more features in the range extension, with the knowledge that one or more features are not used in the range extension, may determine that the decoder can decode the bitstream and may accept the bitstream for decoding instead of rejecting the bitstream.

[0205] FIG. 16 illustrates a syntax structure (1600) of general constraint information according to some embodiments of the present disclosure. In some examples, the syntax structure (1600) includes constraints to be applied to a bitstream, such as a bitstream containing a set of output layers for a decoder. In the example of FIG. 16, 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 (GUI) in the general constraint information syntax structure (1600), other than the alignment zero-bit syntax element (when present). Some standards require that the value of gci_num_additional_bits be 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.

[0206] In the example of FIG. 16, the syntax structure (1600) includes five additional GCI bits (syntax elements) (1601)–(1605) indicated 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. Each of the five additional GCI bits (1601)–(1605) provides coding control information of a coding tool in the scope of a bitstream of an output layer set in some examples.

[0207] FIG. 17 illustrates an example of a syntax structure (1700) for a sequence parameter set (SPS) range extension according to some embodiments of the present disclosure. The syntax structure (1700) may be added to the SPS for CLVS to provide control of the coding tool for the range extension for CLVS. The syntax structure (1700) includes five syntax elements (1701)-(1705) 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. The five syntax elements (1701)-(1705) provide coding control information for the coding tool in the scope of the CLVS in some examples.

[0208] Specifically, in one embodiment, the GCI bit (1601) and the syntax element (1701) are used to provide control using extended precision in different scopes, such as control of an extended dynamic range coding tool, for the binarization of some syntax elements, such as abs_remainder[] and dec_abs_level[], and for the conversion coefficients of the scaling and conversion process.

[0209] A syntax element (1701) such as 1 specifies that an extended dynamic range is used for the transformation factor of the scaling and transformation process and for the binarization of some syntax elements such as abs_remainder[] and dec_abs_level[]. The syntax element abs_remainder[scanning position n] is the remainder absolute value of the transformation factor level coded in Golomb-Rice code at scanning position n. When abs_remainder[] does not exist, it is inferred to be equal to 0. The syntax element dec_abs_level[scanning position n] may correspond to an intermediate value coded in Golomb-Rice code at scanning position n and used to determine the level of the transformation factor at scanning position n. A syntax element (1701) such as 0 specifies that the extended dynamic range is not used in the scaling and transformation process and is not used for binarization, for example, syntax elements abs_remainder[] and dec_abs_level[]. When it does not exist, the value of the syntax element (1701) is inferred to be equal to 0.

[0210] In one example, the variable denoted as Log2TransformRange is used to determine the dynamic range for the transformation factor of the scaling and transformation process and for the binarization of a specific syntax element. For example, the variable Log2TransformRange may be the number of bits to represent the transformation factor in the scaling and transformation process and for the binarization of a specific syntax element. The dynamic range may be the difference between the largest and smallest number expressed in bits. In one example, the variable Log2TransformRange is derived according to the syntax element (1701) sps_extended_precision_flag, as using formula (1):

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

[0212] The dynamic range for the transformation factor and the binarization of specific syntax elements in the scaling and transformation process can be determined based on the variable Log2TransformRange. In some examples, when the flag sps_extended_precision_flag has a value of 0, the extended dynamic range feature (e.g., the coding tool for the extended dynamic range) is not used, and the dynamic range of the transformation factor is based on a fixed number of bits, e.g., 15 bits. When the value of the flag sps_extended_precision_flag is equal to 1, the extended dynamic range feature is enabled, and the number of bits representing the transformation factor 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 of the example in Equation (1). The dynamic range of the transformation factor can be determined based on the number of bits.

[0213] According to one aspect of the present disclosure, a syntax element (e.g., denoted as sps_bitdepth_minus8) may be used to signal the values ​​of the bit depth (e.g., denoted as BitDepth) and the range offset of the luminance and chroma quantization parameters (e.g., denoted as QpBdOffset) of samples of the luminance and chroma arrays. In one example, the bit depth BitDepth may be calculated according to Equation (2), and the QpBdOffset may be calculated according to Equation (3):

[0214] BitDepth = 8 + sps_bitdepth_minus8 Formula (2)

[0215] QpBdOffset = 6 × sps_bitdepth_minus8 Formula (3)

[0216] In some examples, a GCI bit (1601) such as 1 specifies that the syntax element (1701) for all pictures within the scope (OhlsInScope) for the output layer set may be equal to 0. A GCI bit (1601) such as 0 does not impose this restriction. Thus, a GCI bit (1601) such as 1 may specify that the extended dynamic range coding tool is not used in the coding of the bitstream.

[0217] In some embodiments, the GCI bit (1602) and the syntax element (1702) are used to provide control of a coding tool for slice-based rice coding for residual coding in transform skip mode, such as slice-based rice parameter selection for residual coding in transform skip mode, in different scopes.

[0218] According to one aspect of the present disclosure, slice-based rice parameter selection for transform skip residual coding may be included in the scope extension of the video standard. In some examples, a control flag (e.g., indicated by the syntax element (1702), sps_ts_residual_coding_rice_present_in_sh_flag) is signaled in the sequence parameter set (SPS) when the transform skip mode is enabled (e.g., when the syntax element sps_tranform_skip_enabled_flag is true) to indicate that the signaling of rice parameters for the transform skip slice is enabled or disabled, as illustrated in FIG. 17.

[0219] When the control flag is signaled as enabled (e.g., "1"), a single syntax element (e.g., indicated as sh_ts_residual_coding_rice_idx_minus1) is additionally signaled for each transform skip slice, for example in the slice header, to indicate the selection of the rice parameter for that transform skip slice. When the control flag is signaled as disabled (e.g., "0"), no additional syntax element is signaled at the slice level (e.g., slice header) to indicate the selection of the rice parameter for the transform skip slice, and in one example, the default rice parameter may be used for all transform skip slices of coded video data referencing the SPS.

[0220] For example, a syntax element (1702) such as 1 in SPS specifies that a slice header flag, denoted as sh_ts_residual_coding_rice_idx_minus1, may exist in the syntax structure of the slice header (e.g., slice_header()) of the slice referencing SPS. A syntax element (1702) such as 0 in SPS specifies that the slice header flag sh_ts_residual_coding_rice_idx_minus1 does not exist in the syntax structure of the slice_header() of the slice referencing SPS. When it does not exist, in some examples, the value of sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be equal to 0.

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

[0222] In some embodiments, the GCI bit (1603) and the syntax element (1703) are used to provide control of one or more coding tools for deriving rice parameters for binarization of some syntax elements, such as abs_remainder[] and dec_abs_level[] in regular residual coding (RRC), in different scopes. In some examples, regular residual coding (RRC) refers to some techniques for coding blocks obtained by transform and quantization. In some examples, RRC may be modified for blocks obtained only by quantization. In some examples, transform skip residual coding (TSRC) refers to some techniques dedicated to coding blocks obtained by bypassing the transform (also referred to as transform skip).

[0223] In some examples, the video coding standard may include one or more coding tools for deriving rice parameters for binarization of some syntax elements such as abs_remainder[] and dec_abs_level[], and the scope extension of the video coding standard may include one or more alternative coding tools for deriving rice parameters for binarization of some syntax elements such as abs_remainder[] and dec_abs_level[].

[0224] In some examples, video standards use local template-based techniques for deriving lice parameters. For example, a template containing one or more (e.g., five in one example) neighboring coefficient levels is used to derive lice parameters. For example, the sum of absolute coefficient values ​​within the template can be calculated, and the lice parameters are determined based on that sum. In one example, a lookup table can be used to determine the lice parameters based on the sum.

[0225] It should be noted that the Rhys parameter can be determined by other appropriate coding tools. In one example, the Rhys parameter can be determined based on the sum using a formula. In another example, the Rhys parameter can be determined based on statistics of neighbor coefficient levels using context modeling. In some examples, the scope extension of the video standard may specify one or more alternative coding tools for deriving the Rhys parameter.

[0226] In some examples, the range extension of the video standard may include modifications to RRC for use in different 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.

[0227] In some examples, a syntax element (1703) of the SPS, such as 1, specifies that alternative rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] (e.g., alternative coding tool for deriving rice parameters in range expansion) is used to code the CLVS that reference the SPS. A syntax element (1703), such as 0, specifies that alternative rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is not used to code the CLVS that reference the SPS. When not present, the value of the syntax element (1703) is inferred to be equal to 0.

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

[0229] In some embodiments, the GCI bit (1604) and the syntax element (1704) are used to provide control of the derivation of statistical-based rice parameters for the binarization of abs_remainder[] and dec_abs_level[] in different scopes.

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

[0231] In some examples, a syntax element (1704), represented by a control flag, e.g. sps_persistent_rice_adaptation_enabled_flag in SPS, is used to control statistics-based rice parameter derivation. For example, a syntax element (1704), such as 1 in SPS, specifies that rice parameter derivation for binarization of abs_remainder[] and dec_abs_level[] is initialized at the beginning of each TU using statistics accumulated from the previous TU. A syntax element (1704), such as 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 0.

[0232] Additionally, in one embodiment, a syntax element (1604) such as 1 specifies that the syntax element (1704) for all pictures in the scope (OlsInScope) of the output layer set may be equal to 0. A syntax element such as 0 (1604) does not impose this constraint. Thus, in some examples, a GCI bit such as 1 (1604) may specify that statistical-based rice parameter derivation for coding the bitstream is not used.

[0233] In some embodiments, the GCI bit (1605) and the syntax element (1705) are used to provide control of the coding tool used to code the location of the last significant coefficient during entropy coding of the transform coefficients in different scopes. In one example, the location of the last significant coefficient may be coded by different coding tools. For example, a video standard may specify a first coding tool capable of determining the location of the last significant coefficient by coding two coordinates of the location represented by the LastSignificantCoeffX and LastSignificantCoeffY variables (e.g., coded relative to (0,0) for each transform block); and an extension of the video standard may specify an alternative coding tool, such as a second coding tool capable of determining the location of the last significant coefficient by coding the relative coordinates of the last significant coefficient by referencing the bottom-right corner of the transform block in one example.

[0234] In some examples, a syntax element (1705) such as 1 in the SPS specifies that a slice header flag (slice scope) represented by sh_reverse_last_sig_coeff_flag exists in the slice header syntax structure (e.g., slice_header() in some examples) that references the SPS. A syntax element (1705) such as 0 in the SPS specifies that the slice header flag sh_reverse_last_sig_coeff_flag does not exist in the slice header syntax structure that references the SPS, and the slice header flag sh_reverse_last_sig_coeff_flag can be inferred to be equal to 0. When it does not exist, the value of the syntax element (1705) is inferred to be equal to 0.

[0235] In some examples, the value of the slice header flag sh_reverse_last_sig_coeff_flag of a slice is used to determine the location of the last effective coefficient of the transformation coefficients during the scaling and transformation process in the coding of the slice. In one example, when sh_reverse_last_sig_coeff_flag is equal to 1 for a slice, the location of the last effective coefficient in the slice can be coded by an alternative coding tool in the range extension of the video standard, such as a second coding tool, which can determine the location of the last effective coefficient by coding the relative coordinates of the last effective coefficient with reference to the bottom-right corner of the transformation block in one example. Otherwise (e.g., when sh_reverse_last_sig_coeff_flag is equal to 0 for a slice), the current coordinates for the location of the last effective coefficient in the slice (e.g., coded relative to (0, 0) for each transformation block) are coded by the first coding tool.

[0236] In some examples, a GCI bit (1605) such as 1 specifies that the syntax element (1705) for all pictures in the scope (OlsInScope) of the output layer set may be equal to 0. A GCI bit (1605) such as 0 does not impose this restriction. Thus, a GCI bit (1605) such as 1 may specify that the second coding tool is not used in deriving the position of the last valid count for the scope of the bitstream.

[0237] FIG. 18 illustrates a flowchart schematically illustrating a process (1800) according to an embodiment of the present disclosure. The process (1800) may be used in a video decoder. In various embodiments, the process (1800) is executed by a processing circuit such as a processing circuit of a terminal device (310, 320, 330, 340), a processing circuit that performs the function of a video decoder (410), a processing circuit that performs the function of a video decoder (510), etc. In some embodiments, the process (1800) is implemented as a software instruction, and thus, when the processing circuit executes the software instruction, the processing circuit performs the process (1800). The process starts at (S1801) and proceeds to (S1810).

[0238] In (S1810), the value of a first syntax element (e.g., general_no_reverse_last_sig_coeff_constraint_flag) for coding control in a first scope of video data (e.g., output layer set) coded in a bitstream is determined. The first syntax element is associated with a coding tool for coding the position of the last effective coefficient during entropy coding of the transform coefficients, such as an alternative tool in range expansion (e.g., a second coding tool that can determine the position of the last effective coefficient by coding the relative coordinates of the last effective coefficient by referencing the bottom-right corner of the transform block in one example).

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

[0240] In (S1820), when the value of the first syntax element is the first value, the process proceeds to (1830); otherwise, it proceeds to (S1840). The first value indicates the deactivation of the coding tool in the coding of the first scope of the video data coded in the bitstream, and the first scope of the coded video data includes one or more second scopes of the coded video data (e.g., one or more CLVS within the output layer set).

[0241] In some examples, the first syntax element contains general constraint information for controlling the coding of pictures within the output layer set output from the decoder. In one example, the first value of the first syntax element indicates the disabling of the coding tool in the coding of each coded layer video sequence (CLVS) in the output layer set.

[0242] In (S1830), in response to the first syntax element being the first value, the first scope of video data coded in the bitstream is decoded without calling a coding tool.

[0243] In some examples, a second syntax element for coding control of a coded layer video sequence (CLVS) in a bitstream (e.g., sps_reverse_last_sig_coeff_enabled_flag) is constrained to have a value indicating that a coding tool for decoding the CLVS is not invoked. In one example, the value of the second syntax element indicates the absence of a slice header flag associated with a coding tool in the slice header of a slice in a picture of the CLVS.

[0244] In (S1840), in response to the first syntax element being a second value, the value of a second syntax element (e.g., sps_reverse_last_sig_coeff_enabled_flag) for coding control of a second scope of coded video data, such as a layer video sequence (CLVS) coded in a bitstream, is determined for decoding the coded video data in the second scope. The second syntax element indicates the enabling / disabling of the coding tool in the CLVS. In one example, the second syntax element does not exist in the sequence parameter set (SPS) for the CLVS, and the value of the second syntax element is inferred to indicate the disabling of the coding tool in the CLVS.

[0245] In some examples, in response to the value of a syntax element indicating the activation of a coding tool in CLVS, a slice header flag (e.g., sh_reverse_last_sig_coeff_flag) is determined from the slice header of a slice and, for example, is decoded from the slice header. The slice header flag indicates whether or not to use a coding tool to code the slice.

[0246] The process (1800) can be appropriately adapted. The step(s) of the process (1800) can be modified and / or omitted. Additional steps can be added. Any suitable order of implementation can be used.

[0247] FIG. 19 illustrates a flowchart schematically illustrating a process (1900) according to an embodiment of the present disclosure. The process (1900) may be used in a video encoder. In various embodiments, the process (1900) is executed by a processing circuit such as a processing circuit of a terminal device (310, 320, 330, 340), a processing circuit that performs the function of a video encoder (403), a processing circuit that performs the function of a video encoder (603), a processing circuit that performs the function of a video encoder (703), etc. In some embodiments, the process (1900) is implemented as a software instruction, and thus, when the processing circuit executes the software instruction, the processing circuit performs the process (1900). The process starts at (S1901) and proceeds to (S1910).

[0248] In (S1910), the processing circuit determines whether a coding tool is used during the encoding of a first scope (e.g., a set of output layers) of video data coded in the bitstream. The coding tool is associated with coding the location of the last effective coefficient during the entropy coding of the transform coefficients. For example, the coding tool is an alternative tool in the scope extension, such as a second coding tool capable of deriving the location of the last effective coefficient in the transform block by coding the relative coordinates of the last effective coefficient with reference to the bottom-right corner of the transform block. The first scope of the coded video data includes one or more second scopes (e.g., CLVS) of the coded video data.

[0249] In some examples, the processing circuit may determine whether a coding tool is used based on a second syntax element (e.g., sps_reverse_last_sig_coeff_enabled_flag) for coding control of a coded layer video sequence (CLVS) in the bitstream. In some examples, the processing circuit may determine whether a coding tool is used based on a slice header flag (e.g., sh_reverse_last_sig_coeff_flag) in the slice header of the slice being encoded. The slice header flag of the slice (e.g., sh_reverse_last_sig_coeff_flag) indicates whether a coding tool is used or not for coding the slice.

[0250] In (S1920), when a coding tool is not used for coding the first scope of the coded video data, the process proceeds to (S1930); otherwise, it proceeds to (S1940).

[0251] In (S1930), a first syntax element having a first value (e.g., general_no_reverse_last_sig_coeff_constraint_flag) is encoded into the bitstream. The first syntax element is for coding control in the first scope (e.g., output layer set) of the video data coded in the bitstream. The first syntax element is associated with a coding tool for coding the position of the last effective coefficient during entropy coding of the transform coefficients. The first value indicates that the coding tool is not used in the coding of the first scope of the video data coded.

[0252] In one example, the first syntax element is encoded as a syntax structure for general constraint information, and the syntax element of the syntax structure (e.g., gci_num_additional_bits) is adjusted to indicate additional bits for general constraint information in the syntax structure.

[0253] In (S1940), a first syntax element having a second value is encoded into the bitstream. In some examples, for instance, if the second value is a default value for the first syntax element, the first syntax element is not encoded into the bitstream, and then (S1940) can be skipped.

[0254] The process (1900) can be appropriately adapted. The step(s) of the process (1900) can be modified and / or omitted. Additional steps can be added. Any suitable order of implementation can be used.

[0255] The aforementioned technology (e.g., technology for signaling constraint flags, adaptive resolution parameters, etc.) is implemented in computer software using computer-readable instructions and may be physically stored on one or more computer-readable media. For example, FIG. 20 illustrates a computer system (2000) suitable for implementing a specific embodiment of the disclosed subject matter.

[0256] Computer software may be coded using any suitable machine code or computer language, and may be subject to assembly, compilation, linking, or similar mechanisms to generate code containing instructions that can be executed by processing circuits such as a computer central processing unit (CPU), graphics processing unit (GPU), etc., either directly or through interpretation, microcode execution, etc.

[0257] The command can be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, game devices, Internet of Things devices, etc.

[0258] The components illustrated in FIG. 20 for the computer system (2000) are essentially exemplary and are not intended to suggest any limitations on the scope of use or function of the computer software implementing the embodiments of the present disclosure. The configuration of the components should not be interpreted as having any dependency or requirement related to any one or combination of the components illustrated in the exemplary embodiments of the computer system (2000).

[0259] The computer system (2000) may include a specific human interface input device. This human interface input device may respond to input by one or more human users through, for example, tactile input (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, applause), visual input (e.g., gestures), and olfactory input (not shown). The human interface device may also be used to capture specific media that are not directly related to conscious human input, such as audio (e.g., voice, music, ambient sounds), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., 2D video, 3D video including stereoscopic video).

[0260] The input human interface device may include one or more of a keyboard (2001), a mouse (2002), a trackpad (2003), a touch screen (2010), a data glove (not shown), a joystick (2005), a microphone (2006), a scanner (2007), and a camera (2008) (only one of each shown).

[0261] The computer system (2000) may also include a specific human interface output device. This human interface output device may stimulate the senses of one or more human users, for example, through tactile output, sound, light and smell / taste. These human interface output devices may include a tactile output device (e.g., a touch screen (2010), a data glove (not shown), or a tactile feedback device that does not function as an input device, but includes tactile feedback via a joystick (2005)), an audio output device (e.g., a speaker (2009), headphones (not shown)), a visual output device (e.g., a screen (2010) including a CRT screen, an LCD screen, a plasma screen, or an OLED screen, each of which may or may not have touch screen input capability, each of which may or may not have tactile feedback capability, some of which may or may not have two-dimensional visual output or three-dimensional output via stereographic output means such as virtual reality glasses (not shown), a holographic display and a smoke tank (not shown)), and a printer (not shown).

[0262] The computer system (2000) also includes human-accessible storage devices and associated media, such as optical media including a CD / DVD ROM / RW (2020) or similar media (2021) having a CD / DVD, a thumb drive (2022), a removable hard drive or solid-state drive (2023), legacy magnetic media such as tape and floppy disk (not shown), and specialized ROM / ASIC / PLD-based devices such as a security dongle (not shown).

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

[0264] The computer system (2000) may also include a network interface (2054) for one or more communication networks (2055). The networks may be, for example, wireless, wired, or optical. The networks may also be local, wide-area, metropolitan, automotive and industrial, real-time, latency-tolerant, etc. Examples of communication networks include local area networks such as Ethernet, wireless LAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., TV wired or wireless wide-area digital networks including cable TV, satellite TV and terrestrial broadcast TV, automotive and industrial networks including CAN buses, etc. Certain networks generally require an external network interface adapter attached to a specific general-purpose data port or peripheral bus (2049) (for example, a USB port of the computer system (2000)); others are integrated into the core of the computer system (2000) by being attached to a system bus (for example, an Ethernet interface for a PC computer system or a cellular network interface for a smartphone computer system), as described below. Using any of these networks, the computer system (2000) can communicate with other entities. This communication may be unidirectional, receive-only (e.g., broadcast TV), unidirectional transmit-only (e.g., from a CANbus to a specific CANbus device), or bidirectional, to another computer system using a local or wide-area digital network, for example. Specific protocols and protocol stacks may be used in each of the networks and network interfaces as described above.

[0265] The aforementioned human interface device, human-accessible storage device, and network interface can be attached to the core (2040) of the computer system (2000).

[0266] The core (2040) may include one or more Central Processing Units (CPUs) (2041), Graphics Processing Units (GPUs) (2042), special programmable processing units in the form of Field Programmable Gate Areas (FPGAs) (2043), hardware accelerators for specific tasks (2044), graphics adapters (2050), etc. Along with Read-only Memory (ROM) (2045), Random Access Memory (2046), and internal mass storage (2047) such as internal non-user accessible hard drives, SSDs, etc., these devices 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 to enable expansion by additional CPUs, GPUs, etc. Peripheral devices may be attached to the core's system bus (2048) directly or via a peripheral bus (2049). In one example, a screen (2010) can be connected to a graphics adapter (2050). The architecture of the peripheral buses includes PCI, USB, etc.

[0267] The CPU (2041), GPU (2042), FPGA (2043), and accelerator (2044) can be combined to execute specific instructions that can construct the aforementioned computer code. This computer code may be stored in ROM (2045) or RAM (2046). Transitional data may be stored in RAM (2046), but permanent data may be stored, for example, in internal mass storage (2047). Fast storage and retrieval of any memory device may be enabled through the use of a cache memory that may be closely associated with one or more CPUs (2041), GPUs (2042), mass storage (2047), ROM (2045), RAM (2046), etc.

[0268] A computer-readable medium may have computer code for performing various computer-implemented operations. The medium and the computer code may be specifically designed and configured for the purposes of this disclosure, or they may be of a type well known and available to those skilled in the field of computer software.

[0269] As a non-limiting example, a computer system having an architecture (2000), in particular a core (2040), may provide functionality as a result of processor(s) (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software implemented on one or more types of computer-readable media. Such computer-readable media may be media associated with specific storage of the core (2040) having non-transient characteristics, such as the user-accessible mass storage or internal mass storage (2047) or ROM (2045) introduced above. Software implementing various embodiments of the present disclosure may be stored on such devices and executed by the core (2040). The computer-readable media may include one or more memory devices or chips depending on specific needs. Software may enable the core (2040) and, in particular, the processor within it (including a CPU, GPU, FPGA, etc.) to execute a specific process or part of a specific process described herein, including defining data structures stored in RAM (2046) and modifying such data structures according to a process defined in the software. Additionally or alternatively, the computer system may provide functionality as a result of logic that is hardwired or implemented in a circuit (e.g., an accelerator (2044)) capable of working instead of or with the software to execute a specific process or part of a specific process described herein. References to software may include logic, and where appropriate, vice versa. References to computer-readable media may include circuits that store software for execution (e.g., an integrated circuit (IC)), circuits that implement logic for execution, or, where appropriate, both. The present disclosure covers any suitable combination of hardware and software.

[0270] Appendix A: Abbreviations

[0271] JEM: joint exploration model

[0272] VVC: versatile video coding

[0273] BMS: benchmark set

[0274] MV: Motion Vector

[0275] HEVC: High Efficiency Video Coding

[0276] SEI: Supplementary Enhancement Information

[0277] VUI: Video Usability Information

[0278] GOPs: Groups of Pictures

[0279] TUs: Transform Units,

[0280] PUs: Prediction Units

[0281] CTUs: Coding Tree Units

[0282] CTBs: Coding Tree Blocks

[0283] PBs: Prediction Blocks

[0284] HRD: Hypothetical Reference Decoder

[0285] SNR: Signal Noise Ratio

[0286] CPUs: Central Processing Units

[0287] GPUs: Graphics Processing Units

[0288] CRT: Cathode Ray Tube

[0289] LCD: Liquid-Crystal Display

[0290] OLED: Organic Light-Emitting Diode

[0291] CD: Compact Disc

[0292] DVD: Digital Video Disc

[0293] ROM: Read-Only Memory

[0294] RAM: Random Access Memory

[0295] ASIC: Application-Specific Integrated Circuit

[0296] PLD: Programmable Logic Device

[0297] LAN: Local Area Network

[0298] GSM: Global System for Mobile communications

[0299] LTE: Long-Term Evolution

[0300] CANBus: Controller Area Network Bus

[0301] USB: Universal Serial Bus

[0302] PCI: Peripheral Component Interconnect

[0303] FPGA: Field Programmable Gate Areas

[0304] SSD: solid-state drive

[0305] IC: Integrated Circuit

[0306] CU: Coding Unit

[0307] Although the present disclosure describes some exemplary embodiments, there are modifications, permutations, and various alternative equivalents that fall within the scope of the disclosure. Accordingly, those skilled in the art will understand that numerous systems and methods can be devised that embody the principles of the present disclosure and thus fall within the spirit and scope of the present disclosure, even though they are not explicitly shown or described herein.

Claims

Claim 1 A method for video decoding in a decoder, wherein a processor determines a first syntax element general_no_reverse_last_sig_coeff_constraint_flag in general constraint information (GCI) for coding control in all pictures included in an output layer set of video data coded in a bitstream - determining the first syntax element is based on a syntax element of the GCI indicating that there is an additional bit containing the first syntax element in the GCI, the output layer set includes a plurality of coded layer video sequences (CLVSs), and the first syntax element is associated with a coding tool using an alternate reference coordinate for coding the position of the last effective coefficient during entropy coding of the transform coefficients - ; A video decoding method comprising the step of the processor decoding all pictures of the output layer set of the coded video data in the bitstream without calling the coding tool in response to the first syntax element being a first value indicating the deactivation of the coding tool in the output layer set, wherein the number of the additional bits of the GCI is 5, and the GCI further comprises a syntax element used to control the use of an extended dynamic range for the transformation factor of the scaling and transformation process in the output layer set. Claim 2 A video decoding method according to claim 1, wherein the coding tool codes the position of the last effective coefficient in the transformation block related to the right bottom corner of the transformation block. Claim 3 A video decoding method according to paragraph 2, wherein the first value of the first syntax element indicates that the coding tool is disabled for all pictures in each of the plurality of CLVS of the output layer set. Claim 4 A video decoding method according to claim 2, further comprising the step of determining the value of a second syntax element sps_reverse_last_sig_coeff_enabled_flag for coding control of one of a plurality of CLVS in the bitstream in response to the first syntax element being a second value different from the first value, wherein the second syntax element indicates the activation / deactivation of the coding tool in the CLVS. Claim 5 A video decoding method according to claim 4, further comprising the step of decoding a slice header flag in the slice header of a slice in response to the value of the second syntax element indicating the activation of the coding tool in the CLVS, wherein the slice header flag indicates the use or non-use of the coding tool for coding the slice. Claim 6 A video decoding method according to claim 4, wherein the step of determining the value of the second syntax element further comprises the step of inferring that the value of the second syntax element indicates the deactivation of the coding tool in the CLVS in response to the fact that the second syntax element does not exist in the sequence parameter set (SPS) for the CLVS. Claim 7 A video decoding method according to claim 4, wherein the value of the second syntax element sps_reverse_last_sig_coeff_enabled_flag indicates disabling a coding tool for decoding the CLVS. Claim 8 A video decoding method according to claim 7, wherein the value of the second syntax element indicates that there is no slice header flag associated with the coding tool in the slice header of the slice in the picture of the CLVS. Claim 9 A video decoding method according to claim 1, wherein the step of determining the first syntax element further comprises the step of decoding the first syntax element from the syntax structure of the GCI based on a syntax element of the syntax structure indicating that the additional bit containing the first syntax element exists in the syntax structure of the GCI. Claim 10 A video decoding method according to claim 9, wherein the syntax element is denoted by gci_num_additional_bits; and the first syntax element and the syntax element exist in the syntax structure of the GCI for coding control in all pictures of the output layer set of video data coded in the bitstream. Claim 11 A video decoding device comprising a processing circuit configured to perform the method of any one of claims 1 to 10. Claim 12 A computer-readable non-transient storage medium for storing instructions, wherein when the instructions are executed by at least one processor, the at least one processor performs the method of any one of claims 1 to 10. Claim 13 delete Claim 14 delete Claim 15 delete Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 delete Claim 20 delete

Images