A technique for constraint flag signaling for range expansion by rice coding

Abstract

Aspects of the present disclosure provide methods and apparatuses 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 coded video data within a bitstream. The first syntax element is associated with a coding tool for slice-based rice coding for residual coding in transform skip mode. The coding tool provides rice parameters at the slice level for residual coding in transform skip mode. In response to the first syntax element being a first value indicating that the coding tool is disabled in the first scope, the processing circuit decodes the first scope of coded video data, which includes one or more second scopes of coded video data, without activating the coding tool.

Description

Technology Field

[0001] The present disclosure describes embodiments generally related to video coding.

[0002] delete

[0003] delete

[0004] delete Background Technology

[0005] The background description provided herein is intended to provide general context for the present disclosure. The research of the inventors currently named—insofar as such research is described in this background section—as well as modes of description that may not qualify as prior art at the time of filing, are not recognized as prior art to the present disclosure, either explicitly or implicitly.

[0006] Video coding and decoding can be performed using inter-picture prediction accompanied by motion compensation. Uncompressed digital video may contain a series of pictures, each having, for example, a spatial dimension of 1920x1080 luminance samples and associated chrominance samples. The series of pictures may have, for example, 60 pictures per second or a fixed or 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 at 8 bits per sample (1920x1080 luminance sample resolution at a 60Hz frame rate) requires a bandwidth close to 1.5 Gbit / s. One hour of such video requires more than 600 gigabytes of storage space.

[0007] One objective of video coding and decoding may be to reduce redundancy in the input video signal through compression. Compression can help reduce the aforementioned bandwidth and / or storage requirements by more than two orders of magnitude in some cases. Both lossless and lossy compression, as well as combinations thereof, may be adopted. Lossless compression refers to techniques where an exact copy of the original signal can be reconstructed 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 adopted. The amount of acceptable distortion depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio may reflect the fact that higher acceptable distortion can yield a higher compression ratio.

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

[0009] Video codec technologies may include techniques known as intra-coding. In intra-coding, sample values ​​are represented without referencing samples from previously reconstructed reference pictures or other data. In some video codecs, a picture is spatially subdivided into blocks of samples. When all blocks of samples are coded in intra mode, the picture may be an intra-picture. Intra-pictures and their derivatives, such as independent decoder refresh pictures, can be used to reset the decoder state and thus can be used as the first picture or as a still image in the coded video bitstream and video session. Samples of an intra-block can be exposed to transformation, and transformation coefficients can 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 transformation and the smaller the AC coefficients, the fewer bits are required at a given quantization step size to represent the block after entropy coding.

[0010] For example, traditional intra-coding, such as that known from MPEG-2 generation coding techniques, does not utilize intra-prediction. However, some newer video compression techniques include methods that attempt to utilize surrounding sample data and / or metadata acquired during the encoding / decoding of blocks of data that are spatially adjacent and precede in the decoding order, for example. These methods 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 reference pictures.

[0011] There may be many different forms of intra-prediction. When two or more of such 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, modes may have submodes and / or parameters, which may be coded individually or included in a mode codeword. Which codeword to use for a given mode / submode / parameter combination can affect the coding efficiency gain through intra-prediction and may therefore be an entropy coding technique used to convert codewords into a bitstream.

[0012] Specific intra-prediction modes were introduced in H.264, improved in H.265, and further enhanced in newer coding techniques such as JEM (joint exploration model), VVC (versatile video coding), and BMS (benchmark set). Predictor blocks can be formed using neighbor sample values ​​belonging to already available samples. The sample values ​​of neighbor samples are copied to form predictor blocks according to direction. A reference to the direction in use can be encoded in the bitstream or predicted itself.

[0013] Referring to FIG. 1a, a subset of 9 known predictor directions from the 33 possible predictor directions of H.265 (corresponding to 33 angle modes of 35 intra modes) is shown in the lower right. The point (101) where the arrows converge indicates the sample being predicted. The arrows indicate the direction in which the sample is predicted from there. For example, arrow (102) indicates that the sample (101) is predicted from the sample or samples to 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 to the lower left of the sample (101) at an angle of 22.5 degrees from the horizontal.

[0014] Referring still to FIG. 1a, a square block (104) of 4x4 samples (indicated by dashed, bold lines) is depicted in the upper left. The square block (104) contains 16 samples, each labeled "S," its position in the Y dimension (e.g., row index) and its position in the X dimension (e.g., column index). For example, sample S21 is the second sample in the Y dimension (from the top) and the first sample in the X dimension (from the left). Similarly, sample S44 is the fourth sample within the block (104) in both the Y and X dimensions. Since the size of the block is 4x4 samples, S44 is located in the lower right. Reference samples following a similar numbering scheme are additionally depicted. The reference samples are labeled R, their Y position (e.g., row index) and X position (column index) relative to the block (104). In both H.264 and H.265, the predicted samples are adjacent to the block being reconstructed; therefore, negative values ​​do not need to be used.

[0015] Intra-picture prediction can be performed by copying reference sample values ​​from neighboring samples as appropriate by the signaled prediction direction. For example, assume that the coded video bitstream contains signaling indicating a prediction direction corresponding to the arrow (102) for this block—that is, samples are predicted from the prediction sample or samples upward to the right, at a 45-degree angle from the horizontal. In that case, samples S41, S32, S23 and S14 are predicted from the same reference sample R05. Then, sample S44 is predicted from reference sample R08.

[0016] In certain cases, the values ​​of multiple reference samples can be combined, for example, through interpolation, to calculate a reference sample; particularly when the directions are not uniformly divisible by 45 degrees.

[0017] As video coding technology has advanced, the number of possible directions has increased. In H.264 (2003), nine different directions could be represented. This increased to 33 in H.265 (2013), and JEM / VVC / BMS could support up to 65 directions at the time of initiation. Experiments were conducted to identify the most likely directions, and specific techniques in entropy coding were used to represent such likely directions with a small number of bits, accepting specific penalties for less likely directions. Additionally, the directions themselves can sometimes be predicted from neighboring directions used in adjacent, already decoded blocks.

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

[0019] The mapping of intra-predicted direction bits in a coded video bitstream representing direction can vary depending on the video coding technique; and, for example, can range from simple direct mappings of the predicted direction to intra-predicted modes, codewords, complex adaptive methods involving the most likely mode, and similar techniques. However, in all cases, there may be certain directions that are statistically less likely to occur in the video content than other directions. Since the goal of video compression is to reduce redundancy, in a well-functioning video coding technique, such less likely directions will be represented by a larger number of bits than the more likely directions.

[0020] Motion compensation may be a lossy compression technique and may relate to a technique used for predicting 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) has been spatially shifted in the direction indicated by a motion vector (hereinafter MV). In some cases, the reference picture may be identical to the picture currently being reconstructed. MVs may have 2-dimensional X and Y, or 3 dimensions, with the third being an indication of the reference picture in use (the latter may, indirectly, be a time dimension).

[0021] In some video compression techniques, applicable MVs for a specific region of sample data can be predicted from other MVs, for example, from another region of sample data spatially adjacent to the region being reconstructed and preceding that MV in the decoding order. Doing so can substantially reduce the amount of data required to code the MVs, thereby eliminating redundancy and increasing compression. MV prediction can work effectively, for example, when coding an input video signal derived from a camera (known as natural video), because there is a statistical possibility that regions larger than the area where a single MV is applicable move in similar directions, and thus, in some cases, can be predicted using similar motion vectors derived from MVs of neighboring regions. This yields a result where the MV found for a given region is similar or identical to the MV predicted from surrounding MVs, and ultimately, it can be represented after entropy coding with fewer bits than would be used when directly coding the MVs. In some cases, MV prediction can be an example of lossless compression of signals (i.e., MVs) derived from the original signal (i.e., sample stream). In other cases, MV prediction itself can be lossy, for example, due to rounding errors when calculating the predictor from some surrounding MVs.

[0022] 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, a technique referred to as "spatial merge" below is described here.

[0023] Referring to FIG. 2, the current block (201) contains samples discovered by the encoder during the motion search process, which are predictable from a previous block of the same size that is spatially shifted. Instead of directly coding the MV, the MV may be derived from metadata associated with one or more reference pictures, for example, from the most recent reference picture (in decoding order), using an MV associated with any one of five surrounding samples denoted as A0, A1, and B0, B1, B2 (each, 202 to 206). In H.265, the MV prediction may use predictors from the same reference picture used by neighboring blocks. means of solving the problem

[0024] Aspects of the present disclosure provide methods and apparatuses 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 coded video data within a bitstream. The first syntax element is associated with a coding tool for slice-based rice coding for residual coding in transform skip mode. In some examples, the coding tool provides rice parameters at the slice level for residual coding in transform skip mode. In response to the first syntax element being a first value indicating disabling of the coding tool in the first scope, the processing circuit decodes the first scope of coded video data, which includes one or more second scopes of coded video data, without activating the coding tool.

[0025] In some embodiments, the first syntax element is in general constraint information for coding control of pictures within the output layer set. In some examples, the first value of the first syntax element indicates disabling the coding tool in each coded layer video sequence (CLVS) in the output layer set.

[0026] In some embodiments, in response to the first syntax element being a first value, the processing circuit constrains a second syntax element for coding control of the CLVS (coded layer video sequence) in the bitstream to have a value indicating that there is no activation of a coding tool for decoding the CLVS. In some examples, 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 the picture of the CLVS.

[0027] In some embodiments, in response to the first syntax element being a second value and the transform skip mode being enabled in the coded layer video sequence (CLVS), the processing circuit decodes the value of the second syntax element within the sequence parameter set (SPS) referenced by the CLVS. The second syntax element indicates the presentation / non-presentation of a slice-level syntax element indicating the selection of a rice parameter. In response to the value of the second syntax element indicating the presentation of the slice-level syntax element, in the example, the processing circuit decodes a third syntax element from the slice header of the slice, and the third syntax element indicates the selection of a rice parameter for residual coding of the slice in the transform skip mode.

[0028] In some embodiments, in response to the second syntax element not being presented in the SPS for the CLVS, the processing circuit infers the value of the second syntax element to indicate non-use of the coding tool in the CLVS.

[0029] In some embodiments, the processing circuit decodes a first syntax element from a syntax structure for general constraint information in response to a syntax element in a syntax structure representing additional bits for general constraint information in the syntax structure.

[0030] Aspects of the present disclosure also provide a non-transient computer-readable medium that stores instructions that cause a computer to perform methods for video decoding when executed by a computer for video decoding. Brief explanation of the drawing

[0031] Additional features, nature, and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings. Figure 1a is a schematic diagram of an exemplary subset of intra prediction modes. Figure 1b is an example of exemplary intra-predicted directions. Figure 2 is a schematic diagram of the current block and 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 examples for signaling adaptive resolution change (ARC) parameters according to embodiments 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 and FIGS. 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 and FIGS. 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 outlining a process according to an embodiment of the present disclosure. FIG. 19 illustrates a flowchart outlining 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

[0032] 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 and 320) interconnected through the network (350). In the example of FIG. 3, the first pair of terminal devices (310 and 320) perform unidirectional transmission of data. For example, a terminal device (310) may encode video data (for example, a stream of video pictures captured by the terminal device (310)) for transmission 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 video pictures, and can display the video pictures according to the recovered video data. Unidirectional data transmission may be common in media serving applications and similar applications.

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

[0034] In the example of FIG. 3, the terminal devices (310, 320, 330, and 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 also apply to applications using laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. Network (350) represents any number of networks carrying coded video data between the terminal devices (310, 320, 330, and 340), including, for example, wireline (wired) and / or wireless communication networks. The communication network (350) may exchange data on 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 herein.

[0035] 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 equally applicable to other video-supporting applications, such as storing compressed video on digital media including, for example, video conferencing, digital TV, CD, DVD, memory stick, and similar devices.

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

[0037] Note that the electronic devices (420 and 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 likewise include a video encoder (not shown).

[0038] 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 within 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) in the example of FIG. 4.

[0039] A receiver (531) may receive one or more coded video sequences to be decoded by a video decoder (510); in the same or another embodiment, one coded video sequence at a time—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 storing encoded video data. The receiver (531) may receive the encoded video data along with other data, e.g., encoded audio data and / or auxiliary data streams, which may be forwarded to their respective use entities (not described). The receiver (531) may separate the coded video sequences from the other data. To counter 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). In others, it may be outside the video decoder (510) (not depicted). In others, for example, to counteract network jitter, the buffer memory may be outside the video decoder (510) (not depicted), and in addition, for example, to handle playback timing, another buffer memory (515) may be inside the video decoder (510). When the receiver (531) is receiving data from a storage / forward device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (515) may not be needed or may be small.For use on best effort packet networks such as the Internet, a buffer memory (515) may be required, may be relatively large, advantageously may be of adaptive size, and may be implemented at least partially in an operating system or similar elements (not described) outside the video decoder (510).

[0040] The video decoder (510) may include a parser (520) to reconstruct symbols (521) from a coded video sequence. Categories of such symbols include information used to manage the operation of the video decoder (510), and potentially, as illustrated in FIG. 5, information for controlling a rendering device (512) (e.g., a display screen) that is not an integral part of the electronic device (530) but can be coupled to the electronic device (530). The control information for the rendering device(s) may be in the form of SEI (Supplemental Enhancement Information) messages or VUI (Video Usability Information) parameter set fragments (not depicted). 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, arithmetic coding with or without context sensitivity, and so on. 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 Pictures (GOPs), pictures, tiles, slices, macroblocks, Coding Units (CUs), blocks, Transform Units (TUs), Prediction Units (PUs), and so on. The parser (520) may also extract information such as transform coefficients, quantizer parameter values, motion vectors, and so on from the coded video sequence.

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

[0042] The reconstruction of the symbols (521) may involve multiple different units depending on the type of the coded video picture or parts thereof (e.g., inter- and intra-picture, inter- and intra-block), and other factors. Which units are involved and how they are involved may be controlled by subgroup control information parsed from the coded video sequence by the parser (520). The flow of such subgroup control information between the parser (520) and the multiple units below is not described for clarity.

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

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

[0045] In some cases, the output samples of the scaler / inverse transform (551) may be related to an intra-coded block; that is: a block that can use prediction information from previously reconstructed parts of the current picture, rather than using prediction information from previously reconstructed pictures. Such prediction information may be provided by an intra-picture prediction unit (552). In some cases, the intra-picture prediction unit (552) generates a block of the same size and shape as the block being reconstructed by using surrounding already reconstructed information fetched from the current picture buffer (558). The current picture buffer (558) buffers, for example, a partially reconstructed current picture and / or a fully reconstructed current picture. In some cases, the aggregator (555) adds the prediction information generated by the intra-prediction unit (552) to the output sample information provided by the scaler / inverse transform unit (551) on a per-sample basis.

[0046] In other cases, the output samples of the scaler / inverse 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 symbols (521) associated with the block, these samples are added to the output of the scaler / inverse unit (551) by the aggregator (555) (in this case, called residual samples or residual signals) to generate output sample information. The addresses in the reference picture memory (557) from which the motion compensation prediction unit (553) fetches prediction samples may be controlled by motion vectors available to the motion compensation prediction unit (553) in the form of symbols (521) that may have, for example, X, Y, and reference picture components. Motion compensation may also include interpolation of sample values ​​fetched from reference picture memory (557) when subsample accurate motion vectors are in use, motion vector prediction mechanisms, etc.

[0047] Various loop filtering techniques within the loop filter unit (556) may be performed on the output samples of the aggregator (555). The video compression technique may include an in-loop filter technique that is controlled by parameters included in the coded video sequence (also referred to as the coded video bitstream) and made available to the loop filter unit (556) as symbols (521) from the parser (520), but which responds not only to meta-information obtained during the decoding of the previous (in decoding order) parts of the coded picture or coded video sequence, but also to previously reconstructed and loop-filtered sample values.

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

[0049] Certain coded pictures, once fully reconstructed, can be used as reference pictures for future predictions. For example, once the coded picture corresponding to the current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (520)), the current picture buffer (558) can become part of the reference picture memory (557), and a new current picture buffer can be reallocated before initiating the reconstruction of the next coded picture.

[0050] A video decoder (510) can perform decoding operations according to a predetermined video compression technique in a standard such as ITU-T Rec. H.265. In that the coded video sequence adheres to both the syntax of the video compression technique or standard and the profiles documented in the video compression technique or standard, the coded video sequence may comply with the syntax specified by the video compression technique or standard in use. Specifically, the profile may select specific tools from all tools available in the video compression technique or standard as the only tools available for use under that profile. Additionally, for compliance, the complexity of the coded video sequence may be within the boundaries defined by the levels of the video compression technique or standard. In some cases, the levels limit the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the levels may, in some cases, be further restricted through HRD (Hypothetical Reference Decoder) specifications and metadata for managing HRD buffers signaled in the coded video sequence.

[0051] In an 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 take the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0052] FIG. 6 illustrates a block diagram of a video encoder (603) according to an 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.

[0053] 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).

[0054] A video source (601) may provide a source video sequence to be coded by a video encoder (603) in the form of a digital video sample stream having any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 Y CrCB, RGB, ...), and any suitable sampling structure (e.g., Y CrCb 4:2:0, Y CrCb 4:4:4). In a media serving system, the video source (601) may be a storage device that stores previously 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 sequentially. The pictures themselves may be organized as a spatial array of pixels, where each pixel may contain one or more samples depending on the sampling structure, color space, etc. being used. A person skilled in the art can easily understand the relationship between pixels and samples. The following description focuses on the samples.

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

[0056] In some embodiments, the video encoder (603) is configured to operate in a coding loop. For the sake of oversimplification, in the example, the coding loop may include a source coder (630) (responsible for generating symbols, such as a symbol stream, based on, for example, the input picture to be coded and reference picture(s)), and a (local) decoder (633) embedded in the video encoder (603). The decoder (633) reconstructs the symbols to generate sample data in a manner similar to how the (remote) decoder also generates them (since any compression between the symbols and the coded video bitstream is lossless in the video compression techniques considered in the subject matter disclosed). The reconstructed sample stream (sample data) is input into the reference picture memory (634). Because the decoding of the symbol stream leads to bit-accurate results independently of the decoder location (local or remote), the content within the reference picture memory (634) is also bit-accurate between the local encoder and the remote encoder. In other words, the encoder's prediction part "sees" as reference picture samples the exact same sample values ​​that the decoder "sees" when using prediction during decoding. This fundamental principle of reference picture synchronization (and the resulting drift, e.g., when synchronization cannot be maintained due to channel errors) is also used in some related technologies.

[0057] The operation of the “local” decoder (633) may be the same as that of the “remote” decoder, such as the video decoder (510) already described in detail above in conjunction with FIG. 5. However, referring also briefly to FIG. 5, since symbols are available and the encoding / decoding of symbols into a coded video sequence by the entropy coder (645) and parser (520) may be lossless, the entropy decoding parts of the video decoder (510), including the buffer memory (515) and parser (520), may not be fully implemented in the local decoder (633).

[0058] 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 necessarily 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 may be abbreviated as it is the inverse of the comprehensively described decoder technique. Further details are required only in specific areas and are provided below.

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

[0060] The local video decoder (633) can decode the coded video data of pictures that may be designated as reference pictures based on the symbols generated by the source coder (630). The operations of the coding engine (632) may advantageously be lossy processes. When the coded video data can be decoded in a video decoder (not shown in FIG. 6), the reconstructed video sequence may typically be a copy of the source video sequence having some errors. The local video decoder (633) can replicate the decoding processes that can be performed by the video decoder on the reference pictures and cause the reconstructed reference pictures to be stored in the reference picture cache (634). In this way, the video encoder (603) can locally store copies of the reconstructed reference pictures having common content as the reconstructed reference pictures to be acquired by the far-end video decoder (without transmission errors).

[0061] The predictor (635) can perform predictive searches 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 specific metadata or sample data (as candidate reference pixel blocks), such as reference picture motion vectors, block shapes, etc., which can serve as appropriate predictive references for the new pictures. The predictor (635) can operate on a sample block-by-pixel 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 drawn from multiple reference pictures stored in the reference picture memory (634).

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

[0063] The outputs of all previously mentioned function units may undergo entropy coding 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.

[0064] The transmitter (640) may buffer the coded video sequence(s) generated by the entropy coder (645) to prepare for transmission over a communication channel (660), which may be a hardware / software link to a storage device for storing 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 auxiliary data streams (sources not shown).

[0065] 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 influence the coding techniques that can be applied to each picture. For example, pictures can often be assigned as one of the following picture types:

[0066] An intra-picture (I-picture) may be one that can be coded and decoded without using any other picture within the sequence as a source of prediction. Some video codecs allow different types of intra-pictures, including, for example, Independent Decoder Refresh (IDR) pictures. A person skilled in the art recognizes such variations of I-pictures and their respective applications and features.

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

[0068] A bidirectional prediction picture (Picture B) may be coded and decoded using intra-prediction or inter-prediction, using at most two motion vectors and reference indices to predict sample values ​​of each block. Similarly, multiple prediction pictures may use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0069] Source pictures are often spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples, respectively) and can be coded on a block-by-block basis. Blocks can be predictively coded by referencing other (already coded) blocks determined by the coding assignment applied to each of the blocks' pictures. For example, blocks of pictures I can be non-predictively coded, or they can be predictively coded by referencing already coded blocks of the same picture (spatial prediction or intra prediction). Pixel blocks of picture P can be predictively coded via spatial prediction or temporal prediction by referencing one previously coded reference picture. Blocks of pictures B can be predictively coded via spatial prediction or temporal prediction by referencing one or two previously coded reference pictures.

[0070] The video encoder (603) can perform coding operations according to a standard such as ITU-T Rec. H.265 or a predetermined video coding technique. During its operations, the video encoder (603) can perform various compression operations, including predictive coding operations that utilize temporal and spatial redundancy in the input video sequence. Thus, the coded video data can comply with the syntax specified by the video coding technique or standard in use.

[0071] In an embodiment, the transmitter (640) may transmit additional data along with the encoded video. The source coder (630) may include such 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.

[0072] Video can be captured as multiple source pictures (video pictures) in a time sequence. Intra-picture prediction (often abbreviated as intra prediction) uses spatial correlation within a given picture, while inter-picture prediction uses (temporal or other) correlation between pictures. In the example, a specific picture under encoding / decoding, referred to as the current picture, is partitioned into blocks. When a block within the current picture is similar to a reference block within a previously coded and still buffered reference picture in the video, the block within the current picture can be coded by a vector referred to as a motion vector. The motion vector points to the reference block within the reference picture and, if multiple reference pictures are in use, may have a third dimension that identifies the reference picture.

[0073] In some embodiments, a bi-prediction technique may be used in 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 precede the current picture in the video in the decoding order (however, in the display order, they may be in the past and future, respectively). A block in the current picture may be coded by a first motion vector pointing to a first reference block in the first reference picture, and a second motion vector pointing to a second reference block in the second reference picture. A block may be predicted by a combination of the first reference block and the second reference block.

[0074] In addition, merge mode techniques can be used in inter-picture prediction to improve coding efficiency.

[0075] According to some embodiments of the present disclosure, predictions such as inter-picture predictions and intra-picture predictions are performed on a block basis. For example, according to the HEVC standard, a picture within a sequence of video pictures is partitioned to become coding tree units (CTUs) for compression, and the CTUs within the picture have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, a CTU includes three CTBs, which are one luma CTB (coding tree block) and two chroma CTBs. Each CTU can be recursively quadtree split to become one or more coding units (CUs). For example, a CTU of 64x64 pixels can be split to become one CU of 64x64 pixels, four CUs of 32x32 pixels, or sixteen CUs of 16x16 pixels. In the 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 split into one or more prediction units (PUs) depending on temporal and / or spatial predictability. Typically, each PU includes a luminal prediction block (PB) and two chroma PBs. In the embodiment, the prediction operation in coding (encoding / decoding) is performed on a unit of prediction blocks. If a luminal prediction block is used as an example of a prediction block, the prediction block includes a matrix of values ​​(e.g., luminal values) for pixels such as 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.

[0076] FIG. 7 illustrates 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 a 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 the example, the video encoder (703) is used instead of the video encoder (403) in the example of FIG. 4.

[0077] In the HEVC example, the video encoder (703) receives a matrix of sample values ​​for a processing block, such as a prediction block of 8x8 samples. The video encoder (703) determines whether the processing block is best coded using, for example, intra-mode, inter-mode, or both prediction modes using rate distortion optimization. When the processing block is to be coded in intra-mode, the video encoder (703) may encode the processing block into a coded picture using an intra-prediction technique; and when the processing block is to be coded in inter-mode or both prediction modes, the video encoder (703) may encode the processing block into a coded picture using an inter-prediction technique or a both prediction technique, respectively. In certain video coding techniques, the merge mode may be an inter-picture prediction submode in which motion vectors are derived from one or more motion vector predictors without the benefit of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the target block. In the example, the video encoder (703) includes other components such as a mode determination module (not shown) for determining the mode of the processing blocks.

[0078] 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) combined together as shown in FIG. 7.

[0079] The inter-encoder (730) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks within reference pictures (e.g., blocks within previous and later pictures), generate inter-prediction information (e.g., description of redundancy information according to the inter-encoding technique, motion vectors, merge mode information), and calculate inter-prediction results (e.g., predicted blocks) based on the inter-prediction information using any suitable technique. In some examples, the reference pictures are decoded reference pictures that are decoded based on encoded video information.

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

[0081] The 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 the example, the general controller (721) determines the mode of the block and provides a control signal to the switch (726) based on the mode. For example, when the mode is intra mode, the general controller (721) controls the switch (726) to select an intra mode result for use by the residual calculator (723), and controls the entropy encoder (725) to select intra prediction information and include the intra prediction information in the bitstream; and when the mode is inter mode, the general controller (721) controls the switch (726) to select an inter prediction result for use by the residual calculator (723), and controls the entropy encoder (725) to select inter prediction information and include the inter prediction information in the bitstream.

[0082] The residual calculator (723) is configured to calculate the difference (residual data) between the received block and the prediction results selected from the intra-encoder (722) or the inter-encoder (730). The residual encoder (724) is configured to operate based on the residual data to encode the residual data and generate transformation coefficients. In the example, the residual encoder (724) is configured to convert the residual data from the spatial domain to the frequency domain and generate transformation coefficients. The transformation coefficients are then subjected to 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 transformation and generate decoded residual data. The decoded residual data can be suitably used by the intra-encoder (722) and the inter-encoder (730). For example, the inter encoder (730) can generate decoded blocks based on decoded residual data and inter prediction information, and the intra encoder (722) can generate decoded blocks based on decoded residual data and intra prediction information. The decoded blocks are appropriately processed to generate decoded pictures, and the decoded pictures are buffered in a memory circuit (not shown) and can be used as reference pictures in some examples.

[0083] 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 the 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. According to the subject matter disclosed, it is noted that when coding a block in an inter mode or a merged submode of both prediction modes, there is no residual information.

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

[0085] 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) combined together as shown in FIG. 8.

[0086] The entropy decoder (871) may be configured to reconstruct, from a coded picture, specific symbols representing the syntax elements that constitute the coded picture. These symbols may include, for example, the mode in which the block is coded (e.g., intra mode, inter mode, both prediction modes, the latter two in a merged submode or another submode), prediction information (e.g., intra prediction information or inter prediction information) capable of identifying specific samples or metadata used for prediction by the intra decoder (872) or inter decoder (880), respectively, residual information in the form of quantized transformation coefficients, and similar information. In the example, when the prediction mode is an inter or both 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). Residual information can undergo inverse quantization and is provided to a residual decoder (873).

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

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

[0089] The residual decoder (873) is configured to perform inverse quantization to extract dequantized transform coefficients and to process the dequantized 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 a Quantizer Parameter QP), and that information may be provided by the entropy decoder (871) (since this may only be low-capacity control information, the data path is not described).

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

[0091] 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 technique. In an 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 603) and video decoders (410, 510, and 810) can be implemented using one or more processors that execute software instructions.

[0092] Aspects of the present disclosure provide coding tool(s) having constraint flags in a coded video stream and control techniques for functionalities.

[0093] According to an aspect of the present disclosure, the picture size within a bitstream may be maintained or changed. In some relevant examples, video encoders and decoders may operate on 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) depending on factors such as activity in the scene, but only for I pictures, and thus the picture size is typically defined and maintained constant for the GOP. Resampling of reference pictures for the use of different resolutions within a CVS is known, for example, from Appendix P of ITU-T Rec. H.263. However, the picture size within the CVS does not change, and only the reference pictures are resampled, resulting in potentially only parts of the picture canvas being used (e.g., in the case of downsampling) or only parts of the scene being captured (e.g., in the case of upsampling). In some examples, such as in H.263 Appendix Q, resampling of individual macroblocks by a factor of two is allowed in each dimension (e.g., upward or downward). However, the picture size remains the same. If the size of the macroblock can be fixed, for example, in H.263, then the size of the macroblock does not need to be signaled.

[0094] In some relevant examples, the picture size in the predicted pictures may be changed. In examples such as VP9, ​​resampling of the reference picture and changes in the resolution of the entire picture are permitted. In some examples (e.g., Hendry et al., “On adaptive resolution change (ARC) for VVC”, Joint Video Team document JVET- M0135-v1, Jan 9-19, 2019 (the entirety of which is incorporated herein by reference)), resampling of 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 may be referenced by picture-specific syntax elements in the picture parameter set (PPS).

[0095] According to an embodiment of the present disclosure, a source video may be compressed by layered coding capable of encoding pictures into a bitstream comprising one or more layers having different qualities, such as different resolutions. The bitstream may have syntax elements that specify 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 an output layer set. For example, in a video codec that supports multiple layers and scalability, one or more output layer sets may be signaled in a video parameter set (VPS). Syntax elements specifying a profile tier level (PTL) for the entire bitstream or one or more output layer sets may be signaled in a VPS, a decoder parameter set (DPS) which may be referred to as decoder capability information (DCI) in some examples, an SPS, a PPS, an SEI message, or a similar one. The PTL information may contain general constraint information that can specify constraints on coding tools or capabilities. It is desirable to efficiently express and signal constraint information regarding various coding tools and functionalities.

[0096] 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 can be semantically grouped and 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 assembled to form a 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 to form a coded picture in the compression domain without transcoding to the sample level. In some examples, one or more coded sub-pictures may be extracted from a coded picture within the compression domain.

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

[0098] In some examples, ARC encoding / decoding is picture-level, and thus 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 sub-picture level, and thus multiple sub-pictures within a picture can be encoded / decoded with independent ARC parameters. Note that ARC parameters can be signaled using various techniques.

[0099] FIG. 9 illustrates examples (e.g., optional) of techniques for signaling ARC parameters according to some embodiments of the present disclosure. Coding efficiency, complexity, and architecture may vary between examples. Video coding standards or technologies may select one or more of the examples or other variations for signaling ARC parameters. The examples may not be mutually exclusive and may be interchangeable based on application requirements, standard technologies, choice of encoder, and / or similar factors.

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

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

[0102] In some examples, a class of ARC parameters includes resolutions in the X or Y dimension, either combined or individually, of input pictures, output pictures, reference pictures, samples of the coded picture, blocks, macroblocks, CUs, or any other suitable units of granularity. In some examples, there is more than one resolution 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 described in detail in further explanation.

[0103] In some examples, the class of ARC parameters includes warping coordinates similar to those used in H.263 Appendix P with suitable granularity as described above. H.263 Appendix 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 Appendix P may be replaced by appropriate-length binary coding, which can be derived from an offset of a certain value that allows warping outside the boundaries of the maximum picture size and the maximum picture size, where the length of the binary codeword is multiplied by a certain factor.

[0104] In some examples, the class of ARC parameters includes upsampling and / or downsampling filter parameters. In an example, only a single filter exists for upsampling and / or downsampling. In another example, multiple filters may be used. In some examples, filter parameters may be signaled to allow more flexibility in filter design. Filter parameters may be selected by using an index within a list of possible filter designs. A filter may be fully specified (e.g., by specifying a list of filter coefficients using suitable entropy coding techniques), and a filter may be implicitly selected through upsampling or downsampling rates signaled according to any of the mechanisms described above, and similarly.

[0105] In the following description, a finite set of upsampling or downsampling factors (the same factors used in both the X and Y dimensions) is used to illustrate 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).

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

[0107] 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 by entropy coding mechanisms other than Ext-Golomb codes, for example, by using binary coding. In some examples, entropy coding mechanisms other than Ext-Golomb codes may have specific advantages when resampling factors are of interest outside of video processing engines (e.g., encoders and decoders), for example, by media-aware network elements (MANEs). In some examples, when no resolution change is required (e.g., when the original / target resolution is 1 in Table 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 codes, for example, in the most common cases.

[0108] According to an embodiment of the present disclosure, a mapping table such as Table 1 may be configurable. For example, the number of entries in Table 1 and the corresponding semantics may be configurable in whole or in part. In some examples, the basic outline of the mapping table is carried in a high-level parameter set 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, via SPS or DPS.

[0109] As previously mentioned, ARC information, such as coded upsampling or downsampling parameters, 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 upsampling or downsampling filters. In some examples, a relatively large amount of data is required for filters or other data structures.

[0110] Referring to FIG. 9, in an example (910) such as in H.263 Appendix P, the ARC information (912) may be in the form of four warping coordinates and is included in the picture header (911) 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, the overhead when using H.263-style signaling as illustrated in the example (910) may be high, and scaling factors may not be applicable between picture boundaries because the picture header may be of a transient nature.

[0111] 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 through 3). In the example, the table (926) is located within an SPS (927). Placing target resolutions in the table (926) within the SPS (927) may be justified by using the SPS as a point of interoperability negotiation during capability exchange. Resolutions may be changed from one picture to another by reference (e.g., ARC reference information (925)) in the appropriate PPS (924) within a limited set of values ​​(e.g., resolutions 1-3) in the table (926).

[0112] FIG. 9 can also be used to transmit ARC information in a video bitstream.

[0113] Examples (930), (940), and (950) show additional techniques. The techniques can be used individually or in appropriate combinations within the same video coding technique or standard.

[0114] Referring to FIG. 9, in example (930), ARC information (939), such as a resampling factor (or zoom factor), may be present in a header such as a slice header, a GOB header, a tile header, a tile group header, or a similar header. A tile group header (938) is illustrated in FIG. 9, for example. The technique illustrated by example (930) may be used when the ARC information (939) can be coded into a small number of bits, such as a single variable-length ue(v) or a fixed-length codeword of several bits.

[0115] According to an embodiment 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 applicable to a sub-picture represented by a corresponding tile group (or slice, tile) rather than, for example, the entire picture. In addition thereto, even if, in the example, a video compression technology or standard envisions only whole-picture adaptive resolution change (e.g., in contrast to tile group-based adaptive resolution change), the example (930) may have certain advantages over the example (910) in terms of error resilience.

[0116] 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 APS (adaptation parameter set), or something similar. An APS (941) is illustrated, for example, in FIG. 9. In some examples, the range of the parameter set (941) may not be larger than a picture, for example, a picture, a tile group, and something similar. 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, a PPS or equivalent may be appropriate.

[0117] Referring to FIG. 9, in example (950), 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. A tile group header (954) is illustrated in FIG. 9 as an example. ARC reference information (953) may refer to a subset of ARC information (955) available in a parameter set (956) having a range extending beyond a single picture, e.g., an SPS, a DPS, or a similar one. An SPS (956) is illustrated in FIG. 9 as an example.

[0118] 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 the examples, the notation of the syntax diagrams follows approximately C-style programming. Bold lines may represent syntax elements present in the bitstream, and non-bolded lines may represent control flow(s) or variable settings.

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

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

[0121] 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 the 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 video coding techniques or standards, specific limits on the value(s) 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 may be divisible by powers of 2), the aspect ratio of width resolution to height resolution (e.g., the ratio of width resolution to height resolution is 4:3 or 16:9), or similar. In the examples, the above limitations may be introduced to facilitate hardware implementations.

[0122] 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). 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), in the example.

[0123] Additionally, FIG. 11 illustrates a table of applicable decoding picture widths and heights. In the example, the number of entries in the table may be indicated by a table notation (e.g., the syntax element num_dec_pic_size_in_luma_samples_minus1) (1116). "minus1" may refer to the interpretation of the value of the syntax element (1116). For example, if the 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 syntax elements (1117).

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

[0125] According to an aspect of the present disclosure, certain video coding techniques or standards (e.g., VP9) can enable spatial scalability by implementing reference picture resampling of certain forms in conjunction with temporal scalability. In an embodiment, the reference picture is upsampled to a higher resolution using ARC-style techniques to form the base of a spatial enhancement layer. The upsampled picture can be refined using ordinary prediction mechanisms at high resolution (e.g., motion compensation prediction for inter-prediction from reference pictures) to add detail, for example.

[0126] In some examples, values ​​in the Network Abstraction Layer (NAL) unit header, such as the Time ID field, are used to indicate both temporal layer information and spatial layer information. Using values ​​in the NAL unit header to indicate both temporal and spatial layer information can enable the use of existing Selected Forwarding Units (SFUs) 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. Subsequently, 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 Time ID field in the NAL unit header.

[0127] According to an aspect of the present disclosure, some features of a coded bitstream may be specified using profile, tier, level, and general constraint information, including profile, tier, level, and general constraint information. In some examples, a profile defines a subset of features of the bitstream, such as color reproduction, resolution, additional video compression, and similar ones. A video codec may define various profiles, such as a baseline profile (e.g., a simple profile with low compression), a high profile (a complex profile with high compression), a main profile (e.g., a profile with an intermediate compression between the baseline profile and the high profile, which may be a default profile setting), and similar ones.

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

[0129] General constraint information may include constraint information regarding video source types, coding tools, and functionalities. 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), and / or similar elements 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).

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

[0131] In some examples, high-level syntax (HLS) is defined with respect to the block level. Block-level coding tools may be used to reconstruct a picture by decoding pixels or samples within the picture. Block-level coding tools may include any suitable 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 filter (ALF), deblocking filter (DBF), entropy coding, transformation, and similar tools.

[0132] High-level syntax (HLS) can specify information regarding functionality, system interfaces, picture-level control and buffer control of tools, and similar things. 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), reference picture resampling (RPR), scalability, and / or similar things. High-level syntax can be higher than block level.

[0133] 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, and / or similar. In some examples, PTL information is part of the control information and may be signaled as constraint flags in the HLS structure, and may indicate the control or constraint of tools within the range corresponding to the HLS structure. For example, constraint flags for PTL information may be provided as either sequence level control information or bitstream level control information. In an example, if specific tools are disabled by constraint flags within the HLS structure, the tools are not used, for example, to code blocks within the range corresponding to the HLS.

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

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

[0136] In FIG. 13, general constraint information may include multiple constraint flags. In the example, a constraint flag identical 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 within the slice header that specifies the coding type of the slice between types I, P, and B. A constraint flag identical 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 range of PTL information where other information (e.g., profile_idc) may allow non-intra-slices. In another example, a constraint flag equal to 1 (e.g., no_alf_constraint_flag) (1306) can indicate that sps_alf_enabled_flag is equal to 0 for all CVS within the range of PTL information, and thus adaptive loop filtering is not in use even though adaptive loop filtering is allowed, for example, based on profile_idc. A constraint flag equal to 0 (e.g., no_alf_constraint_flag) (1306) does not impose the above constraint.

[0137] 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 equal to 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 range of PTL information containing the constraint flag (1301). A constraint flag equal to 0 (e.g., no_lossless_coding_tool_constraint_flag) (1301) does not impose the constraint.

[0138] 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 equal to 1 (e.g., no_lossy_coding_tool_constraint_flag) (1302) may indicate that coding tool(s) related to lossy coding cannot be used within the scope of PTL information containing the constraint flag (1302). A constraint flag equal to 0 (e.g., no_lossy_coding_tool_constraint_flag) (1302) does not impose the constraint.

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

[0140] Multiple constraint flags within general constraint information may be sorted in specific orders. 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. The order may be referred to as a priority order. This order may be presented in the general constraint information syntax structure from high priority to low priority, where high priority indicates a high likelihood of the tool (or mechanism) being unused and low priority indicates a low likelihood of the tool (or mechanism) being unused. Additional factors influencing the order may include tools likely to be used only for specific use cases (e.g., tools for sub-pictures, scalability, and / or interlacing support), the impact of tools on encoder / decoder / implementation complexity, and similar factors.

[0141] FIGS. 14a and 14b illustrate examples of PTL information including a syntax structure example (1410) of a PTL syntax structure (also referred to as a PTL bracket) and a syntax example (1420) for a general constraint information syntax structure (also referred to as a general constraint information bracket) according to some embodiments of the present disclosure. In some examples, a syntax element indicating a number of constraint flags (e.g., num_available_constraint_flags) may be signaled. In an example, a syntax element indicating the number of constraint flags may be signaled in the PTL syntax structure, as shown as (1401) in the syntax example (1410) as 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 the general constraint information bracket, such as at 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, the 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 can be a non-negative integer.

[0142] In an 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 can be any positive integer. The value of the maximum number of constraint flags (e.g., MaxNumConstraintFlags) can be predefined to be 16, 32, 64, 128, or similar. When the value N (e.g., num_available_constraint_flags) is equal to 0, no constraint flags exist in the general constraint information syntax structure. The coding of the value N (e.g., num_available_constraint_flags) can be selected such that the value N and the corresponding entropy-coded representations for the constraint flags can be summed and divided by 8 to ensure byte alignment.

[0143] In some examples, constraint flags may be categorized to form one or more constraint information groups. Each constraint information group may contain 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) within the corresponding constraint information group may exist. In an example, the gate flag may be referred to as the constraint group presence flag. Generally, the gate flag is associated with the corresponding constraint information group and is associated with the constraint flag(s) within the corresponding constraint information group. In an embodiment, the gate flag gates whether the constraint flag(s) within 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 an example, if all gate flags are equal to 0, no constraint flags exist.

[0144] Constraint flags can have different ranges. For example, the range of constraint flags in DCI can be a coded video bitstream. The range of constraint flags in VPS can be CLVS with multiple layers. The range of constraint flags in SPS can be a single CLVS.

[0145] FIGS. 15a and FIGS. 15b illustrate examples of a general pharmaceutical information syntax structure (1500) according to an embodiment of the present disclosure. The general pharmaceutical information syntax structure (1500) includes flags representing general pharmaceutical information. Specifically, the general constraint information syntax structure (1500) includes one or more gates such as the gate flag (e.g., general_frame_structure_constraint_group_flag) (1501), gate flag (e.g., high_level_functionality_constraint_group_flag) (1502), gate flag (e.g., scalability_constraint_group_flag) (1503), gate flag (e.g., partitioning_constraint_group_flag) (1504), gate flag (e.g., intra_coding_tool_constraint_group_flag) (1505), gate flag (e.g., inter_coding_tool_constraint_group_flag) (1506), gate flag (e.g., transform_constraint_group_flag) (1507), and gate flag (e.g., inloop_filtering_constraint_group_flag) (1508) of FIG. 15a. Includes flags. 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 illustrated in FIG. 15a.

[0146] 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 identical to 1 (e.g., general_frame_structure_constraint_group_flag (1501)) can indicate that constraint flags (1511-1514) in the constraint information group (1510) may exist.

[0147] The constraint information group (1510) (or constraint flags (1511-1514)) may be related to the input source and frame packing (e.g., packed 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 equal to 0 (e.g., general_frame_structure_constraint_group_flag(1501)) can indicate that the constraint flags (1511-1514) in the constraint information group (1510) may not exist in the general constraint information syntax structure (1500).

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

[0149] Referring again to FIG. 15a, a gate flag identical to 1 (e.g., scalability_constraint_group_flag) (1503) can specify that there may be constraint flag(s) related to scalability (e.g., inter-layer prediction). Otherwise, there may not be constraint flag(s) related to scalability in the general constraint information syntax structure (1500).

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

[0151] A gate flag identical to 1 (e.g., intra_coding_tool_constraint_group_flag) (1505) can 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).

[0152] A gate flag identical to 1 (e.g., inter_coding_tool_constraint_group_flag) (1506) can specify that there may be constraint flag(s) related to intercoding (e.g., motion compensation for inter-picture prediction). Otherwise, the constraint flags related to intercoding may not exist in the general constraint information syntax structure (1500).

[0153] A gate flag identical to 1 (e.g., transform_constraint_group_flag) (1507) can specify that there may be constraint flag(s) related to transformation coding (e.g., multiple transformation matrices). Otherwise, constraint flags related to transformation coding may not exist in the general constraint information syntax structure (1500).

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

[0155] According to embodiments of the present disclosure, a syntax may be designed such that control information including gate flags (e.g., gate flags (1501-1508)), associated constraint flags (e.g., constraint flags (1511-1512) and constraint flags within the constraint information group (1520)), additional control information, and / or similar can be byte-aligned, for example, such that the number of flags can be divided by 8 to preserve byte alignment. In the example, the number of gate flags and constraint flags within the constraint information (e.g., general constraint information syntax structure (1500)) can be divided by 8. A byte alignment mechanism may be used to achieve byte alignment of the control information. Referring to FIG. 15b, a syntax (e.g., a while loop) (1530) may be used for byte alignment.

[0156] In some embodiments, offset information, such as an offset (using the syntax element constraint_info_offset[]), and length information, such as a length (using the syntax element constraint_info_length[]), are present in the constraint information (e.g., at the beginning of a general constraint information syntax structure) to help present the constraint flag(s) in their respective constraint information group(s) associated with the gate flag(s) within the constraint information. In an embodiment, at least one of the constraint information groups is present in the coded video bitstream. For the constraint information group, the offset and length may be present in the constraint information for the constraint information group. The offset may indicate the offset for the first constraint flag within the constraint information group, and the length may indicate the number of constraint flags within 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_constaint_info_set may be an integer greater than or equal to 0. When the value of num_constaint_info_set is 0, constraint_info_offset[], constraint_info_length[] and constraint flags do not exist in the general constraint information syntax structure.

[0157] In an example, 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]) can help present constraint flags for constraint information group i (i is a positive integer) within the constraint information (e.g., a general constraint information syntax structure). In an 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 5th, 6th, and 7th constraint flags are associated with constraint information group i and exist in the constraint information (e.g., a general constraint information syntax structure).

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

[0159] In the embodiments, run coding may be used in which constraint flags are specified in a predetermined order (or a given order). Instead of directly coding the constraint flags, a properly coded list of "skip" values ​​may represent constraint flags equal to 0, and subsequent constraint flags are implied to be equal to 1. The aforementioned run coding may be particularly efficient when (i) the number of constraint flags is large and (ii) a small percentage of the constraint flags is equal to 1.

[0160] In an embodiment, at least one of the constraint information groups is present in the coded video bitstream. Multiple constraint flags in at least one of the constraint information groups are signaled according to a predetermined order. Thus, the multiple 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 multiple constraint flags.

[0161] In an embodiment, at least one constraint flag in the 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).

[0162] In the embodiments, the complete list of constraint flags may be specified in a video coding standard (e.g., VVC specification), an external table, or something similar. In the examples, only the available constraint flag(s) are indicated, for example, by 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, or something similar is present in the coded video stream.

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

[0164] In the example, the first constraint information offset (e.g., syntax element constraint_info_offset[0]) and the first constraint information length (e.g., syntax element constraint_info_length[0]) are signaled. The second constraint information offset (e.g., syntax element constraint_info_offset[1]) and the second constraint information length (e.g., syntax element constraint_info_length[1]) are signaled. For example, the syntax element constraint_info_offset[0] is 15 and the syntax element constraint_info_length[0] is 3, the syntax element constraint_info_offset[1] is 82 and the syntax element constraint_info_length[1] is 7, thus indicating that the 15th through 17th constraint flags and the 82nd through 88th constraint flags within the entire list (e.g., 100 constraint flags) are available or present in the constraint information.

[0165] In the embodiments, any 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 an appropriate 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 binary coding may be adopted.

[0166] The maximum number of constraint flags (e.g., MaxNumConstraintFlags) can be predefined to be 16, 32, 64, 128, or similar.

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

[0168] In the 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 such as general_profile_idc or general_sub_profile_idc, or codec version information, so that the value of num_available_constraint_flags can be determined without explicitly signaling.

[0169] 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 the example, the reserved constraint bytes are intended to signal additional flags (e.g., additional constraint flags). The flag gci_reserved_byte[ ] may have any suitable value.

[0170] In an embodiment, the value of gci_num_reserved_bytes may be limited or determined by profile information such as general_profile_idc or general_sub_profile_idc, or codec version information. For a basic profile (or main profile), the value of the flag gci_num_reserved_bytes may be 0. For an extended profile (or advanced profile), the value of gci_num_reserved_bytes may be greater than 0.

[0171] In some embodiments, a field sequence flag may be signaled in the coded video bitstream. The field sequence flag may indicate whether pictures at the output layer are 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 an embodiment, the flag sps_field_seq_flag may be present in the SPS. A flag sps_field_seq_flag equal to 1 may indicate that the CLVS carries pictures representing fields. A flag sps_field_seq_flag equal to 0 may indicate that the CLVS carries pictures representing frames.

[0172] 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 equal to 1 may specify that the range for an output layer set (e.g., OlsInScope) carries pictures representing frames. A flag general_frame_only_constraint_flag equal to 0 may specify that the range for an output layer set (e.g., OlsInScope) carries pictures that may or may not represent frames. In an embodiment, the flag general_frame_only_constraint_flag indicates whether pictures within the output layer set are coded by field coding. The 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) indicating that a subset of pictures is not coded by field coding. A subset of pictures can be in one of the output layer sets.

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

[0174] In an example, the flag pps_mixed_nalu_types_in_pic_flag may exist in the PPS. The flag pps_mixed_nalu_types_in_pic_flag, which is equal to 1, can specify that each picture referencing the PPS has more than one VCL NAL unit and that the VCL NAL units do not have the same value of nal_unit_type. The flag pps_mixed_nalu_types_in_pic_flag, which is equal to 0, can 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 the same value of nal_unit_type. 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 equal to 1, can specify that the value of pps_mixed_nalu_types_in_pic_flag will be equal to 0. The flag no_mixed_nalu_types_in_pic_constraint_flag, which is equal to 0, does not impose these constraints.

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

[0176] In an example, the flag single_layer_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. A flag single_layer_constraint_flag equal to 1 may indicate that sps_video_parameter_set_id will 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 is equal to 1, the value of the flag single_layer_constraint_flag may be equal to 1.

[0177] In an embodiment, the flag all_layers_independent_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. Flag all_layers_independent_constraint_flag equal to 1 may indicate that flag vps_all_independent_layers_flag may be equal to 1. Flag all_layers_independent_constraint_flag equal to 0 does not impose such constraints. When flag single_layer_constraint_flag is equal to 1, the value of flag all_layers_independent_constraint_flag may be equal to 1.

[0178] In an example, the flag no_res_change_in_clvs_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. Flag no_res_change_in_clvs_constraint_flag, which is equal to 1, may indicate that the flag sps_res_change_in_clvs_allowed_flag may be equal to 0. Flag no_res_change_in_clvs_constraint_flag, which is equal to 0, does not impose such constraints. When the flag no_ref_pic_resampling_constraint_flag is 1, the value of flag no_res_change_in_clvs_constraint_flag may be 1.

[0179] In an example, the flag no_mixed_nalu_types_in_pic_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. Flag no_mixed_nalu_types_in_pic_constraint_flag, which is equal to 1, specifies that the value of flag pps_mixed_nalu_types_in_pic_flag may be equal to 0. Flag no_mixed_nalu_types_in_pic_constraint_flag, which is equal to 0, does not impose such a constraint. When flag one_subpic_per_pic_constraint_flag is equal to 1, the value of flag no_mixed_nalu_types_in_pic_constraint_flag may be equal to 1.

[0180] In an example, the flag no_trail_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. The flag no_trail_constraint_flag, which is equal to 1, may indicate that there may be no NAL unit having the same nuh_unit_type as TRAIL_NUT existing in OlsInScope (OlsInScope is a set of output layers containing all layers within the entire bitstream referencing DPS). The flag no_trail_constraint_flag, which is equal to 0, does not impose such a constraint. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_trail_constraint_flag may be equal to 1.

[0181] In an example, the flag no_stsa_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. Flag no_stsa_constraint_flag, which is equal to 1, may indicate that there may be no NAL units having the same nuh_unit_type as STSA_NUT existing in OlsInScope. Flag no_stsa_constraint_flag, which is equal to 0, does not impose such a constraint. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_stsa_constraint_flag may be equal to 1.

[0182] In an example, the flag no_trail_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. The flag no_trail_constraint_flag, which is equal to 1, may indicate that there may be no NAL units having the same nuh_unit_type as TRAIL_NUT existing in OlsInScope. The flag no_trail_constraint_flag, which is equal to 0, does not impose such a constraint. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_trail_constraint_flag may be equal to 1.

[0183] In an example, the flag no_stsa_constraint_flag may exist in the general constraint information syntax structure of FIG. 13. Flag no_stsa_constraint_flag, which is equal to 1, may indicate that there may be no NAL units having the same nuh_unit_type as STSA_NUT existing in OlsInScope. Flag no_stsa_constraint_flag, which is equal to 0, does not impose such a constraint. When the flag general_one_picture_only_constraint_flag is equal to 1, the flag no_stsa_constraint_flag may be equal to 1.

[0184] In an embodiment, the flag no_idr_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. The no_idr_constraint_flag equal to 1 may indicate that there may be no NAL units having the same nuh_unit_type as IDR_W_RADL or IDR_N_LP present in OlsInScope. The no_idr_constraint_flag equal to 0 does not impose such constraints.

[0185] In an example, the flag no_cra_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. The flag no_cra_constraint_flag, which is equal to 1, may indicate that there may be no NAL units having the same nuh_unit_type as CRA_NUT existing in OlsInScope. The flag no_cra_constraint_flag, which is equal to 0, does not impose such a constraint.

[0186] In an example, 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). The flag no_rasl_constraint_flag, which is equal to 1, may indicate that there may be no NAL units having the same nuh_unit_type as RASL_NUT existing in OlsInScope. The flag no_rasl_constraint_flag, which is equal to 0, does not impose such a constraint. 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.

[0187] In an example, the flag no_radl_constraint_flag may exist in a general constraint information syntax structure as illustrated in FIG. 13. The flag no_radl_constraint_flag, which is equal to 1, may indicate that there may be no NAL units having the same nuh_unit_type as RADL_NUT existing in OlsInScope. The flag no_radl_constraint_flag, which is equal to 0, does not impose such a constraint. When the flag no_idr_constraint_flag is equal to 1 and the flag no_cra_constraint_flag is equal to 1, the value of the flag no_rasl_constraint_flag may be equal to 1.

[0188] Some aspects of the present disclosure provide techniques for signaling constraint flags for range extensions, such as residual rice coding in transform skip mode, rice coding in normalized residual coding, and range extension by similar means.

[0189] In transform skip mode, transform and inverse transform processes are skipped. For example, in a video encoder, pixel domain residual data can be quantized and entropy-encoded without being transformed into the transform domain. In a video decoder, the encoded data is entropy-decoded and dequantized to become pixel domain residual data without an inverse transform operation.

[0190] According to an embodiment of the present disclosure, residual coding may be performed based on rice coding. Rice coding uses tunable parameters to divide an input value into two parts, and then uses different coding techniques to code the two parts. Tunable parameters are referred to as rice parameters. Rice parameters may affect the coding efficiency of rice coding. Techniques for determining rice parameters for specific applications may be used to improve coding efficiency for specific applications. Some techniques for determining rice parameters may be included in the scope extension of video standards.

[0191] According to an aspect of the present disclosure, certain standards may be originally developed for specific applications. To make a standard applicable to other applications, range extension(s) are developed as tools to support other applications. For example, HEVC originally targets applications with a 4:2:0 chroma format at 8-10 bits per sample. To make the HEVC standard applicable to formats and bit depths other than specific chroma formats and bit depths, range extensions may be developed to support applications using other chroma formats and / or higher bit depths.

[0192] To restrict feature sets to those required for specific groups of applications, video coding standards define profiles, which may include defined decoder feature sets to be 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 compatible bitstream. In addition to profiles, some standards (e.g., VVC, HEVC, and similar ones) also define levels and tiers. Levels impose limits on bitstreams related to spatial resolution, pixel rate, bitrate values, and variations that correspond to decoder processing load and memory capabilities. Level limits can be expressed in terms of maximum sample rate, maximum picture size, maximum bitrate, minimum compression ratio, coded picture buffer capacity, and similar factors. Higher values ​​of levels may correspond to higher complexity limits. Tiers modify bitrate values ​​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 significantly higher bit rate values ​​than video distribution applications. Each profile, tier, and level affects implementation and decoding complexity, and the combination of these three specifies the interoperability points for bitstreams and decoders.

[0193] In some examples, decoders following a specific tier and level are required to be able to decode all bitstreams following that level or any level below that level of the same tier or lower tier, and decoders following a specific profile may support all features within that profile. In some examples, encoders are not required to utilize any specific set of features supported in the profile, but are required to produce conforming bitstreams, that is, bitstreams that comply with specific constraints that enable them to be decoded by conforming decoders.

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

[0195] In the example, HEVC includes three profiles originally referred to as the Main Profile, Main 10 Profile, and Main Still Picture Profile. The three profiles have certain 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 is 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.

[0196] In some examples, HEVC with range extensions can support additional profiles. In the example, the following profiles are collectively referred to as range-extended 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 Intra profile, Main 4:4:4 10 Intra profile, Main 4:4:4 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.

[0197] Some of the range extension profiles may support higher bit depths and may be referred to 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, and similar ones.

[0198] Specifically, the Main 12 profile supports 4:0:0 and 4:2:0 chroma sampling, both intra-prediction and inter-prediction modes, and allows bit depths of 8 to 12 bits per sample. In some examples, a decoder following the Main 12 profile can decode bitstreams consisting of the following profiles: Monochrome, Monochrome 12, Main, Main 10, and Main 12.

[0199] The Main 12 4:4:4 profile has support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, and both intra-prediction and inter-prediction modes, and allows bit depths of 8 to 12 bits per sample. In some examples, a decoder following the Main 12 4:4:4 profile can decode bitstreams consisting of the following profiles: Monochrome, Main, Main 10, Main 12, Main 10 4:2:2, Main 12 4:2:2, Main 4:4:4, Main 10 4:4:4, Main 12 4:4:4, and Monochrome 12.

[0200] The main 16 4:4:4 profile has support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling, and both intra-prediction and inter-prediction modes, and allows bit depths of 8 to 16 bits per sample.

[0201] The main 12 intra profile has support for 4:0:0 and 4:2:0 chroma sampling and intra prediction mode, and allows bit depths of 8 to 12 bits per sample.

[0202] The main 12 4:4:4 intra profile has support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and intra prediction modes, and allows bit depths of 8 to 12 bits per sample.

[0203] The main 16 4:4:4 intra profile has support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and intra prediction modes, and allows bit depths of 8 to 16 bits per sample.

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

[0205] The main 12 4:4:4 still picture profile has support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and allows 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.

[0206] The main 16 4:4:4 still picture profile has support for 4:0:0, 4:2:0, 4:2:2, and 4:4:4 chroma sampling and allows 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.

[0207] According to some aspects of the present disclosure, coding tool control may be performed in various ranges, such as a range of bitstreams, a range of coded layer video sequences (CLVs), a picture, a slice of a picture, and similar items (e.g., a portion 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 a bitstream carrying an output layer set to a decoder. In some examples, coding tool control may be provided in a sequence parameter set (SPS) associated with a CLVS, and the SPS generally contains information for the CLVS. In some examples, coding tool control may be provided in a picture header for a picture, and the picture header generally contains information for the picture. In some examples, coding tool control may be provided in a slice header for a slice, and the slice header generally contains information for the slice.

[0208] According to an aspect of the present disclosure, control information for coding tools in range extension may be provided in various scopes. In some examples, using a larger range of syntax elements can improve coding efficiency. For example, a GCI syntax element value greater than 0 indicates that the bitstream is constrained in a specific way, typically to indicate that a particular coding tool is not used in the bitstream. Additionally, a GCI syntax element value equal to 0 signals that the associated constraint may not be applied, so that the associated coding tool is allowed (but not required) to be used in the bitstream (if its use is supported in the indicated profile).

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

[0210] In some embodiments, the encoder may produce a bitstream that conforms to a video standard having range extension, but does not utilize one or more features supported in the range extension. In some examples, a decoder that conforms to a video standard but does not support one or more features in the range extension, having knowledge that there is no use of one or more features 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.

[0211] 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 elements indicated by gci_num_additional_bits in the syntax structure (1600) are used to specify a number of additional GCI (general constraint information) bits in the general constraint information syntax structure (1600) other than the aligned zero-bit syntax elements (if present). In some standards, the value of gci_num_additional_bits is required to be equal to 0 or 1. In some standards, decoders may allow values ​​of gci_num_additional_bits greater than 1 to appear in the syntax structure.

[0212] 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. The five additional GCI bits (1601-1605) each provide coding control information for coding tools within a range of bitstreams of the output layer set in some examples.

[0213] 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 within the SPS for the CLVS to provide control of coding tools for the range extension for the CLVS. The syntax structure (1700) includes five syntax elements (1701-1705) indicated by sps_extended_precision_flag, sps_ts_residual_coding_rice_present_in_sh_flag, sps_rrc_rice_extension_flag, sps_persistent_rice_adaptation_enabled_flag, and sps_reverse_last_sig_coeff_enabled_flag. In some examples, the five syntax elements (1701-1705) provide coding control information for coding tools within the range of the CLVS.

[0214] Specifically, in the embodiment, the GCI bit (1601) and the syntax element (1701) are used to provide control using extended precision, such as control of an extended dynamic range coding tool for transformation coefficients in scaling and transformation processes in different ranges, and for binarization of some syntax elements such as abs_remainder[ ] and dec_abs_level[ ] and similar ones.

[0215] A syntax element (1701) identical to 1 specifies that an extended dynamic range is used for transformation factors in scaling and transformation processes and for the binarization of some syntax elements such as abs_remainder[ ] and dec_abs_level[ ] and similar ones. The syntax element abs_remainder[scanning position n] is the absolute remainder 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) equal to 0 indicates that the extended dynamic range is not used in scaling and transformation processes and, for example, is not used for binarization of syntax elements abs_remainder[ ] and dec_abs_level[ ] and similar ones. When not present, the value of the syntax element (1701) is inferred to be equal to 0.

[0216] In the example, the variable represented by Log2TransformRange is used to determine the dynamic range for the transformation coefficients in the scaling and transformation processes and for the binarization of specific syntax elements. For example, the variable Log2TransformRange may be a predetermined number of bits for representing the transformation coefficients in the scaling and transformation processes and for the binarization of specific syntax elements. The dynamic range may be the difference between the largest and smallest numbers represented using a predetermined number of bits. In the example, the variable Log2TransformRange is derived according to the syntax element (1701) sps_extended_precision_flag, as in using Equation 1.

[0217] [Mathematical Formula 1]

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

[0219] The dynamic range for transformation factors in scaling and transformation processes and for the binarization of specific syntax elements 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 extended dynamic range coding tool) is not used, and the dynamic range of the transformation factors is based on a fixed number of bits, such as 15 bits. When the flag sps_extended_precision_flag has a value of 1, the extended dynamic range feature is enabled, and the number of bits for representing transformation factors in scaling and transformation processes can be one of 15 bits, 16 bits, 17 bits, 18 bits, 19 bits, and 20 bits based on the bit depth in the example of Equation 1. The dynamic range of the transformation factors can be determined based on the number of bits.

[0220] According to an embodiment of the present disclosure, a syntax element (e.g., denoted as sps_bitdepth_minus8) may be used to signal the bit depth of samples of luminance and chroma arrays (e.g., denoted as BitDepth), and the value of the luminance and chroma quantization parameter range offset (e.g., denoted as QpBdOffset). In the example, the bit depth BitDepth may be calculated according to Equation 2, and the Qp range offset QpBdOffset may be calculated according to Equation 3:

[0221] [Mathematical Formula 2]

[0222] BitDepth = 8 + sps_bitdepth_minus8

[0223] [Mathematical Formula 3]

[0224] QpBdOffset = 6 × sps_bitdepth_minus8

[0225] In some examples, a GCI bit (1601) equal to 1 specifies that the syntax element (1701) for all pictures within the range for the output layer set (OlsInScope) may be equal to 0. A GCI bit (1601) equal to 0 does not impose this constraint. Thus, a GCI bit (1601) equal to 1 may specify the non-use of extended dynamic range coding tools in the coding of the bitstream.

[0226] 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, at different ranges.

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

[0228] When the control flag is signaled as enabled (e.g., equivalent to "1"), one syntax element (e.g., indicated by sh_ts_residual_coding_rice_idx_minus1) is additionally signaled for each transform skip slice, e.g., at 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., equivalent to "0"), no additional syntax element is signaled at the slice level (e.g., at the slice header) to indicate the selection of the rice parameter for the transform skip slice, and the default rice parameter may be used for all transform skip slices within the coded video data that references the SPS in the example.

[0229] For example, a syntax element (1702) equal to 1 in the SPS indicates that the slice header flag indicated by sh_ts_residual_coding_rice_idx_minus1 may exist in the slice header (e.g., slice_header()) syntax structures of the slices referencing the SPS. A syntax element (1702) equal to 0 in the SPS indicates that the slice header flag sh_ts_residual_coding_rice_idx_minus1 does not exist in the slice_header() syntax structures of the slices referencing the SPS. When it does not exist, the value of sps_ts_residual_coding_rice_present_in_sh_flag is inferred to be equal to 0 in some examples.

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

[0231] 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 binarizing some syntax elements, such as abs_remainder[ ] and dec_abs_level[ ] and similar ones, in regular residual coding (RRC) at different ranges. 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).

[0232] In some examples, the video coding standard may include one or more coding tools for deriving rice parameters for binarizing 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 binarizing some syntax elements such as abs_remainder[ ] and dec_abs_level[ ].

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

[0234] It should be noted that the Rhys parameter can be determined by other suitable coding tools. In one example, a mathematical formula can be used to determine the Rhys parameter based on a sum. In another example, context modeling can be used to determine the Rhys parameter based on the statistics of neighboring coefficient levels. In some examples, the expansion of the scope of video standards may specify one or more alternative coding tools for deriving the Rhys parameter.

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

[0236] In some examples, a syntax element (1703) within the SPS equal to 1 specifies that alternative rice parameter derivations for binarization of abs_remainder[ ] and dec_abs_level[ ] (e.g., alternative coding tools for deriving rice parameters in range expansion) are used to code the CLVS that reference the SPS. A syntax element (1703) equal to 0 specifies that alternative rice parameter derivations for binarization of abs_remainder[ ] and dec_abs_level[ ] are 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.

[0237] In some examples, a syntax element (1603) equal to 1 specifies that the syntax element (1703) for all pictures within the range of the output layer set (OlsInScope) may be equal to 0. A syntax element (1603) equal to 0 does not impose this constraint. Thus, in some examples, a GCI bit (1603) equal to 1 may specify the non-use of alternative rice parameter derivation (e.g., alternative coding tools for deriving specific rice parameters in specific range extensions) for binarization of abs_remainder[ ] and dec_abs_level[ ] for coding the bitstream.

[0238] 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 ranges.

[0239] According to an 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 (TUs). In some examples, statistics-based rice parameter derivation may be included in the scope extension of the video standard.

[0240] In some examples, a control flag indicated by sps_persistent_rice_adaptation_enabled_flag in the SPS, e.g., a syntax element (1704), is used to control the derivation of rice parameters based on statistics. For example, a syntax element (1704) equal to 1 in the SPS specifies that the derivation of rice parameters for the binary adaptation of abs_remainder[ ] and dec_abs_level[ ] is initialized at the beginning of each TU using statistics accumulated from previous TUs. A syntax element (1704) equal to 0 specifies that no previous TU state is used in the derivation of rice parameters for the current TU. When not present, the value of the syntax (1704) is inferred to be equal to 0.

[0241] Additionally, in the embodiments, a syntax element (1604) equal to 1 specifies that the syntax element (1704) for all pictures within the range for the output layer set (OlsInScope) may be equal to 0. A syntax element (1604) equal to 0 does not impose this restriction. Thus, in some examples, a GCI bit (1604) equal to 1 may specify the non-use of statistical-based rice parameter derivation for coding the bitstream.

[0242] 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 ranges. In the example, the location of the last significant coefficient may be coded by different coding tools. For example, the 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 indicated by the LastSignificantCoeffX and LastSignificantCoeffY variables; and an extension of the video standard range 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 referring to the bottom right corner of the zero-out transform block in the example.

[0243] In some examples, a syntax element (1705) equal to 1 in the SPS specifies that the slice header flag (slice range) indicated by sh_reverse_last_sig_coeff_flag exists in the slice header syntax structures (e.g., slice_header() in some examples) referencing the SPS. A syntax element (1705) equal to 0 in the SPS specifies that the slice header flag sh_reverse_last_sig_coeff_flag does not exist in the slice header syntax structures referencing the SPS, and the slice header flag sh_reverse_last_sig_coeff_flag can be inferred to be zero. When it does not exist, the value of the syntax element (1705) is inferred to be equal to 0.

[0244] 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 within the transformation coefficients during the scaling and transformation processes in the coding of the slice. In an example, when sh_reverse_last_sig_coeff_flag is equal to 1, the location of the last effective coefficient is coded by an alternative coding tool within the range extension of the video standard, such as a second coding tool; otherwise, the current coordinates for the location of the last effective coefficient are coded by a first coding tool.

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

[0246] FIG. 18 illustrates a flowchart outlining 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 within terminal devices (310, 320, 330, and 340), a processing circuit that performs the functions of a video decoder (410), a processing circuit that performs the functions of a video decoder (510), and a processing circuit similar to the same. In some embodiments, the process (1800) is implemented by software instructions, and thus, when the processing circuit executes the software instructions, the processing circuit performs the process (1800). The process starts at (S1801) and proceeds to (S1810).

[0247] In (S1810), the value of a first syntax element (e.g., general_no_ts_residual_coding_rice_present_in_sh_constraint_flag) for coding control in a first range of coded video data within the bitstream (e.g., output layer set) is determined. The first syntax element is associated with a coding tool for slice-based rice coding for residual coding in transform skip mode. In some examples, the coding tool provides a rice parameter at the slice level for residual coding in transform skip mode.

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

[0249] In some examples, coding tools are defined within the standard's range extension. In one example, the video decoder may support the standard but may not support the coding tools within the standard's range extension. In another example, the video decoder supports the standard's range extension.

[0250] In (S1820), when the value of the first syntax element is the first value, the process proceeds to (1830); otherwise, the process proceeds to (S1840). The first value indicates non-use (e.g., disabling) of a coding tool in the coding of the first range of coded video data within a bitstream containing one or more second ranges of coded video data (e.g., one or more CLVS within an output layer set).

[0251] In some examples, the first syntax element is in general constraint information for controlling the coding of pictures within the output layer set output from the decoder. In an example, the first value of the first syntax element indicates the non-use of a coding tool in each CLVS (coded layer video sequence) within the output layer set.

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

[0253] In some examples, a second syntax element for controlling the coding of CLVS (coded layer video sequence) within the bitstream (e.g., sps_ts_residual_coding_rice_present_in_sh_flag) is constrained to have a value indicating no invoking of the coding tool for decoding the CLVS.

[0254] In (S1840), in response to the first syntax element being a second value, the value of a second syntax element (e.g., sps_ts_residual_coding_rice_present_in_sh_flag) for coding control of a second range of coded video data, such as CLVS (coded layer video sequence), in the bitstream is determined for decoding the coded video data in the second range. Then, the second range of coded video data is decoded accordingly.

[0255] In some examples, the value of the second syntax element is determined in response to the first syntax element being the second value and the transform skip mode being enabled in the coded layer video sequence (CLVS). In the example, the second syntax element is decoded from the sequence parameter set (SPS) referenced by the CLVS. The value of the second syntax element indicates the presentation / non-presentation of the slice-level syntax element, which indicates the selection of the rice parameter. In response to the value of the second syntax element indicating the presentation of the slice-level syntax element, in the example, the third syntax element is decoded from the slice header of the slice. The third syntax element indicates the selection of the rice parameter for residual coding of the slice in transform skip mode.

[0256] In the example, the second syntax element is not presented in the sequence parameter set (SPS) for the CLVS, and the value of the second syntax element is inferred to indicate the absence of presentation of the slice-level syntax element, which represents the selection of slice parameters for residual coding of slices in the non-use of coding tools or in transform skip mode in the CLVS.

[0257] The process (1800) can be adapted as appropriate. Step(s) in the process (1800) can be modified and / or omitted. Additional step(s) can be added. Any suitable order of implementation can be used.

[0258] FIG. 19 shows a flowchart outlining 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 within terminal devices (310, 320, 330, and 340), a processing circuit that performs the functions of a video encoder (403), a processing circuit that performs the functions of a video encoder (603), a processing circuit that performs the functions of a video encoder (703), and a processing circuit similar to the same. In some embodiments, the process (1900) is implemented by software instructions, and thus, when the processing circuit executes the software instructions, the processing circuit performs the process (1900). The process starts at (S1901) and proceeds to (S1910).

[0259] In (S1910), the processing circuit determines whether a coding tool for slice-based rice coding for residual coding in transform skip mode is used during encoding of a first range of coded video data (e.g., output layer set) within the bitstream. The first range of coded video data includes one or more second ranges of coded video data (e.g., CLVSs). In some examples, the coding tool provides rice parameters at the slice level for residual coding in transform skip mode.

[0260] In some examples, the processing circuit can determine whether a coding tool is used for coding control of CLVS (coded layer video sequences) within a bitstream based on second syntax elements (e.g., sps_ts_residual_coding_rice_present_in_sh_flag).

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

[0262] In (S1930), a first syntax element having a first value (e.g., general_no_persistent_rice_adaptation_constraint_flag) is encoded in the bitstream. The first syntax element is for coding control in a first range of coded video data in the bitstream (e.g., output layer set). The first syntax element is associated with a coding tool for slice-based rice coding for residual coding in transform skip mode. The first value indicates non-use of the coding tool in the coding of the first range of coded video data.

[0263] In the example, the first syntax element is encoded within the syntax structure for general constraint information, and the syntax element within the syntax structure (e.g., gci_num_additional_bits) is adjusted to represent additional bits for the general constraint information within the syntax structure.

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

[0265] The process (1900) can be adapted as appropriate. Step(s) in the process (1900) can be modified and / or omitted. Additional step(s) can be added. Any suitable order of implementation can be used.

[0266] The aforementioned techniques (e.g., techniques for signaling constraint flags, adaptive resolution parameters, and / or similar things) may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, FIG. 20 illustrates a computer system (2000) suitable for implementing specific embodiments of the disclosed subject matter.

[0267] Computer software may be coded using any suitable machine code or computer language that may undergo assembly, compilation, linking, or similar mechanisms to generate code comprising instructions that can be executed directly or through interpretation, micro-code execution, and similar methods by one or more computer central processing units (CPUs), graphics processing units (GPUs), and similar devices.

[0268] The commands can be executed on various types of computers or their components, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, Internet of Things devices, and similar ones.

[0269] The components illustrated in FIG. 20 for the computer system (2000) are exemplary in nature and are not intended to imply any limitation on the scope of use or functionality 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 with respect to any one or any combination thereof of the components illustrated in the exemplary embodiments of the computer system (2000).

[0270] The computer system (2000) may include specific human interface input devices. Such human interface input devices 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 described). Human interface devices may also be used to capture specific media that are not necessarily directly related to conscious input by humans, such as audio (e.g., voice, music, ambient sound), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., 2D video, 3D video including stereoscopic video).

[0271] Input human interface devices 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 is depicted).

[0272] The computer system (2000) may also include specific human interface output devices. These human interface output devices may stimulate the senses of one or more human users, for example, through tactile output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., touch-screen (2010), data gloves (not shown), or haptic feedback via a joystick (2005), but there may also be haptic feedback devices that do not function as input devices), audio output devices (e.g., speakers (2009), headphones (not depicted)), visual output devices (e.g., screens (2010) including CRT screens, LCD screens, plasma screens, OLED screens, each having or not having touch-screen input capability, each having or not having haptic feedback capability - some of these may output two-dimensional visual output or output of three or more dimensions through means such as stereographic output; may include virtual reality glasses (not shown), holographic displays and smoke tanks (not shown), and printers (not shown).

[0273] The computer system (2000) may also include human-accessible storage devices and media associated therewith, such as optical media including a CD / DVD ROM / RW (2020) having a media (2021) such as a CD / DVD, a thumb drive (2022), a removable hard drive or solid-state drive (2023), legacy magnetic media such as tapes and floppy disks (not described), specialized ROM / ASIC / PLD-based devices such as security dongles (not described), and similar ones.

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

[0275] The computer system (2000) may also include an interface (2054) to one or more communication networks (2055). The networks may be, for example, wireless, wired, optical. The networks may also be local, wide area, metropolitan, automotive and industrial, real-time, latency-tolerant, etc. Examples of networks include local area networks such as Ethernet and wireless LANs, 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 including CANBus, etc. Certain networks often require external network interface adapters attached to specific general-purpose data ports or peripheral buses (2049) (e.g., USB ports of the computer system (2000), etc.); others are often integrated into the core of the computer system (2000) by attachment to a system bus as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system). By 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., CANbus for specific CANbus devices), or bidirectional to other computer systems using, for example, local or wide-area digital networks. Specific protocols and protocol stacks may be used on each of the aforementioned networks and network interfaces.

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

[0277] The core (2040) may include one or more central processing units (CPUs) (2041), graphics processing units (GPUs) (2042), specialized programmable processing units in the form of field programmable gate areas (FPGAs) (2043), hardware accelerators (2044) for specific tasks, graphics adapters (2050), etc. These devices may be connected via a system bus (2048), along with internal mass storage such as read-only memory (ROM) (2045), random access memory (2046), internal non-user accessible hard drives, SSDs, and similar devices (2047). In some computer systems, the system bus (2048) may be accessible in the form of one or more physical plugs to enable expansion by additional CPUs, GPUs, and similar devices. Peripheral devices may be attached directly to the core's system bus (2048) or via a peripheral bus (2049). In the example, the screen (2010) can be connected to a graphics adapter (2050). Architectures for peripheral buses include PCI, USB, and similar ones.

[0278] CPUs (2041), GPUs (2042), FPGAs (2043), and accelerators (2044) can be combined to execute specific instructions that can constitute the aforementioned computer code. The computer code may be stored in ROM (2045) or RAM (2046). Transient data may also be stored in RAM (2046), while persistent data may be stored, for example, in internal mass storage (2047). High-speed storage and retrieval of any of the memory devices may be made possible through the use of cache memory that may be closely associated with one or more CPUs (2041), GPUs (2042), mass storage (2047), ROM (2045), RAM (2046), and similar devices.

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

[0280] As an example rather than a limitation, a computer system (2000) having an architecture, and specifically a core (2040), may provide functionality as a result of processor(s) (including CPUs, GPUs, FPGAs, accelerators, etc.) executing software embodied on one or more types of tangible computer-readable media. Such computer-readable media may be media associated with specific storage of the core (2040) that is of a non-transient nature, such as a user-accessible mass storage as described above, as well as a core internal mass storage (2047) or ROM (2045). Software implementing various embodiments of the present disclosure may be stored on these devices and executed by the core (2040). The computer-readable media may include one or more memory devices or chips as needed. Software may cause the core (2040) and, specifically, the processors within it (including a CPU, GPU, FPGA, etc.) to execute certain processes or certain parts of certain processes described herein, including defining data structures stored in RAM (2046) and modifying such data structures according to processes defined by the software. Additionally or alternatively, the computer system may provide functionality as a result of logic hardwired or otherwise embodied in a circuit (e.g., accelerator (2044)) that can operate instead of or with the software to execute certain processes or certain parts of certain processes described herein. Reference to software may include logic, where appropriate, and vice versa. Reference to computer-readable medium may, where appropriate, include circuits that store software for execution (such as an integrated circuit (IC)), circuits that embody logic for execution, or both. The present disclosure covers any suitable combination of hardware and software.

[0281] 부록 A: 두문자어들

[0282] JEM: joint exploration model

[0283] VVC: versatile video coding

[0284] BMS: benchmark set

[0285] MV: Motion Vector

[0286] HEVC: High Efficiency Video Coding

[0287] SEI: Supplementary Enhancement Information

[0288] VUI: Video Usability Information

[0289] GOPs: Groups of Pictures

[0290] TUs: Transform Units,

[0291] PUs: Prediction Units

[0292] CTUs: Coding Tree Units

[0293] CTBs: Coding Tree Blocks

[0294] PBs: Prediction Blocks

[0295] HRD: Hypothetical Reference Decoder

[0296] SNR: Signal Noise Ratio

[0297] CPUs: Central Processing Units

[0298] GPUs: Graphics Processing Units

[0299] CRT: Cathode Ray Tube

[0300] LCD: Liquid-Crystal Display

[0301] OLED: Organic Light-Emitting Diode

[0302] CD: Compact Disc

[0303] DVD: Digital Video Disc

[0304] ROM: Read-Only Memory

[0305] RAM: Random Access Memory

[0306] ASIC: Application-Specific Integrated Circuit

[0307] PLD: Programmable Logic Device

[0308] LAN: Local Area Network

[0309] GSM: Global System for Mobile communications

[0310] LTE: Long-Term Evolution

[0311] CANBus: Controller Area Network Bus

[0312] USB: Universal Serial Bus

[0313] PCI: Peripheral Component Interconnect

[0314] FPGA: Field Programmable Gate Areas

[0315] SSD: solid-state drive

[0316] IC: Integrated Circuit

[0317] CU: Coding Unit

[0318] Although the present disclosure describes some exemplary embodiments, there are modifications, substitutions, and various alternative equivalents that fall within the scope of the present 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 fall within the spirit and scope thereof, even though they are not explicitly shown or described in this specification.

Claims

Claim 1 As a method for video decoding in a decoder: acquiring a video bitstream; determining that the video bitstream includes a first syntax element corresponding to a general constraint information (GCI) syntax structure for coding control of pictures within an output layer set of the decoder, wherein the first syntax element indicates the number of additional bits within the GCI syntax structure; and decoding a second syntax element for coding control in a first range of coded video data within the video bitstream from the GCI syntax structure, in accordance with the determination that the first syntax element indicates that there is at least one additional bit, wherein the second syntax element is associated with a coding tool for slice-based rice coding for residual coding in a transform skip mode, and the coding tool provides a rice parameter at the slice level for residual coding in the transform skip mode. A method comprising the step of decoding a first range of coded video data including one or more second ranges of coded video data without activating the coding tool, in response to the second syntax element being a first value indicating that the coding tool is disabled in the first range. Claim 2 In claim 1, the method wherein the second syntax element is represented by the general_no_ts_residual_coding_rice_present_in_sh_constraint_flag in the GCI syntax structure. Claim 3 In paragraph 2, the first value of the first syntax element indicates a method of disabling the coding tool in each CLVS (coded layer video sequence) within the output layer set. Claim 4 A method according to claim 2, further comprising the step of constraining a third syntax element for coding control of the CLVS (coded layer video sequence) within the video bitstream to have a value indicating that there is no activation of a coding tool for decoding the CLVS in response to the second syntax element being the first value. Claim 5 In paragraph 4, the value of the third syntax element indicates the absence of a slice header flag associated with the coding tool in the slice header of a slice within the picture of the CLVS. Claim 6 A method according to claim 2 further comprising the step of determining the value of a third syntax element in a sequence parameter set (SPS) referenced by the CLVS in response to the second syntax element being a second value and the conversion skip mode being enabled in the CLVS (coded layer video sequence)—the third syntax element representing the presentation / non-presentation of a slice level syntax element representing the selection of a slice parameter. Claim 7 A method according to claim 6 further comprising the step of decoding a fourth syntax element from a slice header of a slice in response to the value of the third syntax element indicating the presentation of the slice level syntax element, wherein the fourth syntax element indicates the selection of a slice parameter for residual coding of the slice in the transform skip mode. Claim 8 In claim 6, the step of determining the value of the third syntax element further comprises the step of inferring the value of the third syntax element to indicate non-use of the coding tool in the CLVS in response to the third syntax element not being presented in the SPS for the CLVS. Claim 9 A device for video decoding comprising a processing circuit configured to perform a method according to any one of claims 1 to 8. Claim 10 A non-transient computer-readable storage medium for storing instructions, wherein the instructions, when executed by at least one processor, cause the at least one processor to perform a method according to any one of claims 1 to 8. Claim 11 delete Claim 12 delete 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