Systems and methods for sending signals to notify image output resolution in video encoding

Abstract

This disclosure relates to video coding, and more specifically to techniques for sending signals to notify the image output resolution of encoded video. According to an aspect of the invention, a first tag syntax element is parsed to indicate whether a clipping window offset parameter exists in a set of sequence parameters, wherein the clipping window offset parameter specifies a clipping window applied to an image with a width equal to a maximum width and a height equal to a maximum height.

Description

Technical Field

[0001] This disclosure relates to video encoding, and more specifically to techniques for sending signals to notify the image output resolution of encoded video. Background Technology

[0002] Digital video functionality can be integrated into a wide variety of devices, including digital televisions, laptops or desktops, tablets, digital recording devices, digital media players, video game consoles, cellular phones (including so-called smartphones), medical imaging equipment, and more. Digital video can be encoded according to video coding standards. Video coding standards define the format for encapsulating and encoding video data into compatible bitstreams. A compatible bitstream is a data structure that can be received and decoded by video decoding devices to generate reconstructed video data. Video coding standards can be combined with video compression techniques. Examples of video coding standards include ISO / IEC MPEG-4 Visual and ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC) and High Efficiency Video Coding (HEVC). HEVC is described in the ITU-T H.265 Recommendation of December 2016, which is incorporated herein by reference and referred to herein as ITU-T H.265. Extensions and improvements to ITU-T H.265 are currently under consideration for developing next-generation video coding standards. For example, the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) (collectively referred to as the Joint Video Study Group (JVET)) are working to standardize video coding technologies with compression capabilities significantly exceeding the current HEVC standard. The Joint Exploratory Model 7 (JEM 7), the algorithm description of Joint Exploratory Test Model 7 (JEM 7), and the ISO / IEC JTC1 / SC29 / WG11 document: JVET-G1001 (July 2017, Turin, Italy), which are incorporated herein by reference, describe the coding features of the JVET under the Joint Test Model Study, a technology that represents a potential enhancement to video coding beyond the capabilities of ITU-T H.265. It should be noted that the coding features of JEM 7 are implemented in the JEM reference software. As used herein, the term JEM can refer collectively to the algorithms included in JEM 7 and the specific implementations in the JEM reference software. In addition, in response to the “Joint Call for Proposals on Video Compression with Capabilities beyond HEVC” jointly issued by VCEG and MPEG, various groups presented multiple descriptions of video coding tools at the 10th meeting of ISO / IEC JTC1 / SC29 / WG11 held in San Diego, CA, from April 16 to 20, 2018.Based on various descriptions of video coding tools, the final initial draft text of the video coding specification is described in "Versatile Video Coding (Draft 1)," also known as document JVET-J1001-v2, presented at the 10th meeting of ISO / IEC JTC1 / SC29 / WG11 held in San Diego, California, April 16-20, 2018. This document is incorporated herein by reference and referred to as JVET-J1001. Current development of the next-generation video coding standard for VCEG and MPEG is referred to as the Universal Video Coding (VVC) project. "Versatile Video Coding (Draft 7)" (document JVET-P2001-vE, which is incorporated herein by reference and referred to as JVET-P2001), presented at the 16th meeting of ISO / IEC JTC1 / SC29 / WG11 held in Geneva, Switzerland, October 1-11, 2019, represents the current iteration of the draft text of the video coding specification corresponding to the VVC project.

[0003] Video compression techniques reduce the data requirements for storing and transmitting video data. Video compression can reduce data requirements by utilizing the inherent redundancy in video sequences. It can further divide a video sequence into smaller, consecutive parts (i.e., a set of images within a video sequence, images within a set of images, regions within images, sub-regions within regions, etc.). Intra-frame predictive coding techniques (e.g., spatial prediction within images) and inter-frame prediction techniques (i.e., temporal techniques between images) can be used to generate the difference between the unit of video data to be encoded and a reference unit of the video data. This difference can be called residual data. The residual data can be encoded as quantized transform coefficients. Syntax elements can relate to the residual data and the reference coding unit (e.g., intra-frame predictive mode index and motion information). Entropy coding can be applied to the residual data and syntax elements. The entropy-coded residual data and syntax elements can be included in a data structure that forms a compatible bitstream. Summary of the Invention

[0004] In one example, a method for decoding video data is provided, the method comprising: receiving a sequence parameter set; parsing a maximum width syntax element specifying the maximum width of each decoded image referencing the sequence parameter set; parsing a maximum height syntax element specifying the maximum height of each decoded image referencing the sequence parameter set; and parsing a first marker syntax element indicating whether a clipping window offset parameter exists in the sequence parameter set, wherein the clipping window offset parameter specifies a clipping window applied to an image with a width equal to the maximum width and a height equal to the maximum height.

[0005] In one example, a method for encoding image data is provided, the method comprising: sending a signal to notify a sequence parameter set, wherein: the sequence parameter set includes: (i) a maximum width syntax element specifying the maximum width of each decoded image referencing the sequence parameter set, (ii) a maximum height syntax element specifying the maximum height of each decoded image referencing the sequence parameter set, and (iii) a first marker syntax element indicating whether a clipping window offset parameter exists in the sequence parameter set, wherein the clipping window offset parameter specifies a clipping window applied to an image whose width is equal to the maximum width and whose height is equal to the maximum height.

[0006] In one example, a device including one or more processors is provided, the one or more processors being configured to: receive a sequence parameter set; parse a maximum width syntax element specifying the maximum width of each decoded image referencing the sequence parameter set; parse a maximum height syntax element specifying the maximum height of each decoded image referencing the sequence parameter set; and parse a first marker syntax element indicating whether a clipping window offset parameter exists in the sequence parameter set, wherein the clipping window offset parameter specifies a clipping window applied to an image with a width equal to the maximum width and a height equal to the maximum height. Attached Figure Description

[0007] [ Figure 1 ] Figure 1 This is a block diagram illustrating an example of a system that can be configured to encode and decode video data according to one or more techniques of this disclosure.

[0008] [ Figure 2 ] Figure 2 This is a conceptual diagram illustrating coded video data and corresponding data structures according to one or more techniques of this disclosure.

[0009] [ Figure 3 ] Figure 3 This is a conceptual diagram illustrating a data structure for encapsulating and encoding video data and corresponding metadata according to one or more techniques disclosed herein.

[0010] [ Figure 4A ] Figure 4A This is a conceptual diagram illustrating coded video data and corresponding data structures according to one or more techniques of this disclosure.

[0011] [ Figure 4B ] Figure 4B This is a conceptual diagram illustrating coded video data and corresponding data structures according to one or more techniques of this disclosure.

[0012] [ Figure 4C ] Figure 4CThis is a conceptual diagram illustrating coded video data and corresponding data structures according to one or more techniques of this disclosure.

[0013] [ Figure 5 ] Figure 5 This is a conceptual diagram illustrating coded video data and corresponding data structures according to one or more techniques of this disclosure.

[0014] [ Figure 6 ] Figure 6 This is a conceptual diagram illustrating an example of a component that may be included in a specific implementation of a system that can be configured to encode and decode video data, according to one or more technologies of this disclosure.

[0015] [ Figure 7 ] Figure 7 This is a block diagram illustrating an example of a video encoder that can be configured to encode video data according to one or more techniques of this disclosure.

[0016] [ Figure 8 ] Figure 8 This is a block diagram illustrating an example of a video decoder that can be configured to decode video data according to one or more techniques of this disclosure. Detailed Implementation

[0017] Generally, this disclosure describes various techniques for encoding video data. Specifically, this disclosure describes techniques for transmitting signals to notify the picture output resolution of video data. It should be noted that although the techniques of this disclosure are described relative to ITU-T H.264, ITU-TH.265, JEM, and JVET-P2001, the techniques of this disclosure are generally applicable to video coding. For example, in addition to those techniques included in ITU-T H.265, JEM, and JVET-P2001, the coding techniques described herein can be incorporated into video coding systems (including video coding systems based on future video coding standards), including video block structures, intra-frame prediction techniques, inter-frame prediction techniques, transform techniques, filtering techniques, and / or other entropy coding techniques. Therefore, references to ITU-T H.264, ITU-TH.265, JEM, and / or JVET-P2001 are for descriptive purposes and should not be construed as limiting the scope of the techniques described herein. Furthermore, it should be noted that the inclusion of references in this paper by way of citation is for descriptive purposes and should not be construed as limiting or creating ambiguity regarding the terminology used herein. For example, where the definition of a term provided in an incorporated reference differs from that in another incorporated reference and / or as used herein, the term should be interpreted in a manner that broadly includes each corresponding definition and / or in a manner that includes each specific definition in an alternative context.

[0018] In one example, a method for signaling the output resolution of video data includes: sending a syntax element indicating the expected display width of each image in a reference parameter set, and sending a syntax element indicating the expected display height of each image in the reference parameter set.

[0019] In one example, a device includes one or more processors configured to: send signal notifications to syntax elements indicating the expected display width of each image in the reference parameter set, and send signal notifications to syntax elements indicating the expected display height of each image in the reference parameter set.

[0020] In one example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause one or more processors of the device to: send a signal indicating a syntax element indicating the expected display width of each image in the reference parameter set, and send a signal indicating a syntax element indicating the expected display height of each image in the reference parameter set.

[0021] In one example, an apparatus includes: means for sending a signal to notify a syntax element indicating the expected display width of each image in the reference parameter set; and means for sending a signal to notify a syntax element indicating the expected display height of each image in the reference parameter set.

[0022] In one example, a method for decoding video data includes parsing a syntax element that indicates the expected display width of each image in a reference parameter set, and parsing a syntax element that indicates the expected display height of each image in the reference parameter set.

[0023] In one example, a device includes one or more processors configured to: parse a syntax element indicating the expected display width of each image in the reference parameter set, and parse a syntax element indicating the expected display height of each image in the reference parameter set.

[0024] In one example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause one or more processors of the device to: parse a syntax element indicating the expected display width of each image in the reference parameter set, and parse a syntax element indicating the expected display height of each image in the reference parameter set.

[0025] In one example, an apparatus includes: means for parsing a syntax element indicating the expected display width of each image in a reference parameter set; and means for parsing a syntax element indicating the expected display height of each image in a reference parameter set.

[0026] Details of one or more examples are set forth in the following figures and description. Other features, objects, and advantages will become apparent from the description, figures, and claims.

[0027] Video content comprises a sequence of frames (or images). A series of frames may also be referred to as a group of pictures (GOP). Each video frame or image may be divided into one or more regions. A region may be defined according to a basic unit (e.g., a video block) and a set of rules defining the region. For example, a rule defining a region may be that the region must be an integer number of video blocks arranged in a rectangle. Furthermore, the video blocks within a region may be ordered according to a scanning mode (e.g., raster scan). As used herein, the term "video block" may generally refer to a region of an image, or more specifically, to the largest array of sample values ​​that can be predictably encoded, its sub-partitions, and / or corresponding structures. Additionally, the term "current video block" may refer to the region of an image that is being encoded or decoded. A video block may be defined as an array of sample values. It should be noted that in some cases, pixel values ​​may be described as sample values ​​comprising the corresponding components of the video data, which may also be referred to as color components (e.g., luminance (Y) and chrominance (Cb and Cr) components or red, green, and blue components). It should be noted that in some cases, the terms "pixel value" and "sample value" are used interchangeably. Furthermore, in some cases, a pixel or sample can be referred to as a pel. A video sampling format (also known as a chroma format) can be defined relative to the number of luminance samples included in a video block, thus defining the number of chroma samples included in the video block. For example, in a 4:2:0 sampling format, the luminance component is sampled at twice the rate of the chroma components in both the horizontal and vertical directions.

[0028] Video encoders perform predictive coding on video blocks and their sub-partitions. Video blocks and their sub-partitions can be referred to as nodes. ITU-T H.264 specifies macroblocks comprising 16×16 luma samples. That is, in ITU-T H.264, images are segmented into macroblocks. ITU-T H.265 specifies a similar coding tree unit (CTU) structure (which can be referred to as a maximum coding unit (LCU)). In ITU-T H.265, images are segmented into CTUs. In ITU-T H.265, for images, the CTU size can be set to include 16×16, 32×32, or 64×64 luma samples. In ITU-T H.265, a CTU consists of a corresponding coding tree block (CTB) for each component of the video data (e.g., luma (Y) and chrominance (Cb and Cr)). It should be noted that a video with one luma component and two corresponding chrominance components can be described as having two channels, namely, a luma channel and a chrominance channel. Furthermore, in ITU-T H.265, CTUs can be partitioned according to a quadtree (QT) partitioning structure, which allows the CTU's CTB to be divided into coded blocks (CBs). That is, in ITU-T H.265, a CTU can be divided into quadtree leaf nodes. According to ITU-T H.265, a luma CB, along with two corresponding chroma CBs and associated syntax elements, is called a coding unit (CU). In ITU-T H.265, the minimum permissible size of a CB can be signaled. In ITU-T H.265, the minimum permissible size of a luma CB is 8×8 luma samples. In ITU-T H.265, the decision to code a picture region using intra-frame prediction or inter-frame prediction is made at the CU level.

[0029] In ITU-T H.265, a CU (Prediction Unit) is associated with a prediction unit structure that has its root at the CU. In ITU-T H.265, the prediction unit structure allows the segmentation of the luma CB (Luminance Block) and chroma CB to generate corresponding reference samples. That is, in ITU-T H.265, the luma CB and chroma CB can be segmented into corresponding luma prediction blocks and chroma prediction blocks (PBs), where each PB comprises a block of sample values ​​to which the same prediction is applied. In ITU-T H.265, a CB can be divided into one, two, or four PBs. ITU-T H.265 supports PB sizes from 64×64 samples down to 4×4 samples. In ITU-T H.265, square PBs are supported for intra-frame prediction, where a CB can form a PB or can be segmented into four square PBs. In addition to square PBs, ITU-T H.265 also supports rectangular PBs for inter-frame prediction, where a CB can be halved vertically or horizontally to form a PB. Furthermore, it should be noted that in ITU-T H.265, for inter-frame prediction, four asymmetric PB partitions are supported, where the CB is divided into two PBs at one-quarter of the height (top or bottom) or width (left or right) of the CB. Intra-frame prediction data (e.g., intra-frame prediction mode syntax elements) or inter-frame prediction data (e.g., motion data syntax elements) corresponding to the PB are used to generate reference and / or prediction sample values ​​for the PB.

[0030] JEM specifies a CTU with a maximum size of 256×256 luminance samples. JEM specifies a Quadtree Plus Binary Tree (QTBT) block structure. In JEM, the QTBT structure allows the quadtree leaf nodes to be further divided by a binary tree (BT) structure. That is, in JEM, the binary tree structure allows the quadtree leaf nodes to be recursively divided vertically or horizontally. In JVET-P2001, CTUs are divided according to a Quadtree Plus Multi-Type Tree (QTMT or QT+MTT) structure. QTMT in JVET-P2001 is similar to QTBT in JEM. However, in JVET-P2001, in addition to indicating binary partitioning, the multi-type tree can also indicate so-called ternary (or ternary tree (TT)) partitioning. Ternary partitioning divides a block vertically or horizontally into three blocks. In the case of vertical TT division, the block is divided at one-quarter of its width from the left edge and at one-quarter of its width from the right edge, and in the case of horizontal TT division, the block is divided at one-quarter of its height from the top edge and at one-quarter of its height from the bottom edge.

[0031] As described above, each video frame or picture can be divided into one or more regions. For example, according to ITU-T H.265, each video frame or picture can be divided into one or more slices, and further divided into one or more tiles, wherein each slice includes a sequence of CTUs (e.g., arranged in raster scan order), and wherein a tile is a sequence of CTUs corresponding to a rectangular area of ​​the picture. It should be noted that, in ITU-T H.265, a slice is a sequence of one or more slice segments that begin with an independent slice segment and include all subsequent subordinate slice segments (if any) preceding the next independent slice segment (if any). A slice segment (such as a piece) is a sequence of CTUs. Therefore, in some cases, the terms "slice" and "slice segment" are used interchangeably to refer to a sequence of CTUs arranged in raster scan order. Furthermore, it should be noted that, in ITU-T H.265, a tile may consist of CTUs contained in more than one slice, and a slice may consist of CTUs contained in more than one tile. However, ITU-T H.265 specifies that one or both of the following conditions must be met: (1) all CTUs in a slice belong to the same tile; and (2) all CTUs in a tile belong to the same slice.

[0032] Regarding JVET-P2001, a tile must consist of an integer number of complete tiles or an integer number of consecutive complete CTU rows within a tile, not just an integer number of CTUs. It should be noted that in JVET-P2001, the tile design does not include tile segments (i.e., there are no independent / dependent tile fragments). Therefore, in JVET-P2001, an image can include a single tile contained within a single tile, or an image can include multiple tiles (or their CTU rows) contained within one or more tiles. In JVET-P2001, an image is divided into tiles by specifying the corresponding height of the tile rows and the corresponding width of the tile columns. Therefore, in JVET-P2001, a tile is a rectangular CTU region within a specific tile row and column position. Furthermore, it should be noted that JVET-P2001 specifies that an image can be divided into sub-images, where a sub-image is a rectangular CTU region within an image. The top-left CTU of a sub-image can be located at any CTU position within the image, where the sub-image is constrained to include one or more slices. Therefore, unlike tiles, sub-images are not limited to specific row and column positions. It should be noted that sub-images can be used to encapsulate regions of interest within an image, and the sub-bitstream extraction process can be used to decode and display only specific regions of interest. That is, as described further below, the bitstream of encoded video data comprises a sequence of Network Abstraction Layer (NAL) units, where NAL units encapsulate encoded video data (i.e., video data corresponding to image slices), or NAL units encapsulate metadata (e.g., parameter sets) used for decoding the video data, and the sub-bitstream extraction process forms a new bitstream by removing one or more NAL units from the bitstream.

[0033] Figure 2 This is a conceptual diagram illustrating examples of images within a group of images divided according to tiles, slices, and sub-images. It should be noted that the techniques described herein are applicable to tiles, slices, sub-images, their sub-regions, and / or their equivalent structures. That is, the techniques described herein are generally applicable regardless of how an image is divided into regions. For example, in some cases, the techniques described herein can be applied to situations where tiles can be divided into so-called bricks, where a brick is a rectangular CTU row region within a particular tile. Furthermore, for example, in some cases, the techniques described herein can be applied to situations where one or more tiles can be included in a so-called tile group, where the tile group comprises an integer number of adjacent tiles. Figure 2 In the example shown, Pic3 is depicted as comprising 16 tiles (i.e., tiles 0 to 16 tiles). 15 ) and three slices (i.e., slice 0 to slice 2). In Figure 2In the example shown, slice 0 includes four tiles (i.e., tiles 0 through 3), and slice 1 includes eight tiles (i.e., tiles 4 through 3). 11 ), and slice 2 includes four tiles (i.e., tiles 12 To the block 15 In addition, such as Figure 2 As shown in the example, Pic3 is illustrated as comprising two sub-pictures (i.e., sub-picture 0 and sub-picture 1), where sub-picture 0 includes slice 0 and slice 1, and where sub-picture 1 includes slice 2. As described above, sub-pictures can be used to encapsulate regions of interest within a picture, and the sub-bit extraction process stream can be used to selectively decode (and display) the regions of interest. For example, see Reference... Figure 2 Sub-image 0 may correspond to the action portion of a sports event presentation (e.g., a view of a field), and sub-image 1 may correspond to a scrolling banner displayed during the sports event presentation. By organizing images into sub-images in this way, viewers may be able to disable the display of the scrolling banner. That is, through the sub-bitstream extraction process, slice 2 NAL units can be removed from the bitstream (and therefore not decoded and / or displayed), while slice 0 NAL units and slice 1 NAL units can be decoded and displayed. The following describes in further detail how image slices are encapsulated into corresponding NAL unit data structures and how sub-bitstream extraction is performed.

[0034] For intra-frame predictive coding, the intra-frame prediction mode can specify the location of a reference sample within the image. In ITU-T H.265, the defined possible intra-frame prediction modes include planar (i.e., surface-fitting) prediction modes, DC (i.e., flat global average) prediction modes, and 33 angular prediction modes (predMode: 2-34). In JEM, the defined possible intra-frame prediction modes include planar prediction modes, DC prediction modes, and 65 angular prediction modes. It should be noted that planar prediction modes and DC prediction modes can be referred to as non-directional prediction modes, and angular prediction modes can be referred to as directional prediction modes. It should be noted that the techniques described herein are generally applicable regardless of the number of defined possible prediction modes.

[0035] For inter-frame predictive coding, a reference picture is determined, and motion vectors (MVs) identify samples in that reference picture used to generate predictions for the current video block. For example, reference sample values ​​located in one or more previously encoded pictures can be used to predict the current video block, and motion vectors are used to indicate the position of the reference block relative to the current video block. Motion vectors can describe, for example, the horizontal displacement component of the motion vector (i.e., MV). x ), the vertical displacement component of the motion vector (i.e., MV) yThe resolution of the motion vectors (e.g., quarter-pixel precision, half-pixel precision, one-pixel precision, two-pixel precision, four-pixel precision) is used. Previously decoded images (which may include images output before or after the current image) can be organized into one or more lists of reference images and identified using reference image index values. Furthermore, in inter-frame predictive coding, single prediction refers to generating a prediction using sample values ​​from a single reference image, while dual prediction refers to generating a prediction using corresponding sample values ​​from two reference images. That is, in single prediction, a single reference image and its corresponding motion vector are used to generate a prediction for the current video block, while in dual prediction, a first reference image and its corresponding first motion vector, and a second reference image and its corresponding second motion vector are used to generate a prediction for the current video block. In dual prediction, the corresponding sample values ​​are combined (e.g., added, rounded, and cropped, or averaged according to weights) to generate a prediction. Images and their regions can be classified based on which types of prediction patterns are available for encoding their video blocks. In other words, for regions of type B (e.g., B slices), dual prediction, single prediction, and intra-prediction modes can be used; for regions of type P (e.g., P slices), single prediction and intra-prediction modes can be used; and for regions of type I (e.g., I slices), only intra-prediction mode can be used. As described above, reference images are identified by reference indices. For example, for P slices, a single reference image list RefPicList0 can exist, and for B slices, in addition to RefPicList0, a second independent reference image list RefPicList1 can exist. It should be noted that for single prediction in B slices, either RefPicList0 or RefPicList1 can be used to generate the prediction. Furthermore, it should be noted that during the decoding process, at the start of decoding an image, a reference image list is generated from previously decoded images stored in the Decoding Image Buffer (DPB).

[0036] Furthermore, the coding standard supports various motion vector prediction modes. Motion vector prediction enables the derivation of motion vector values ​​for the current video block based on another motion vector. For example, a set of candidate blocks with associated motion information can be derived from the spatially and temporally adjacent blocks of the current video block. Additionally, the generated (or default) motion information can be used for motion vector prediction. Examples of motion vector prediction include Advanced Motion Vector Prediction (AMVP), Temporal Motion Vector Prediction (TMVP), the so-called "merge" mode, and "skip" and "direct" motion inference. Other examples of motion vector prediction include Advanced Temporal Motion Vector Prediction (ATMVP) and Spatial-Temporal Motion Vector Prediction (STMVP). For motion vector prediction, both the video encoder and video decoder perform the same process to derive a set of candidates. Therefore, for the current video block, the same set of candidates is generated during encoding and decoding.

[0037] As mentioned above, for inter-frame predictive coding, reference samples from previously encoded images are used to encode video blocks in the current image. The previously encoded image that can be used as a reference when encoding the current image is called the reference image. It should be noted that the decoding order does not necessarily correspond to the image output order, i.e., the temporal order of images in the video sequence. In ITU-T H.265, when an image is decoded, it is stored in a decoded image buffer (DPB) (which may be called a frame buffer, reference buffer, reference image buffer, etc.). In ITU-T H.265, images stored in the DPB are removed from the DPB when output and are no longer needed for encoding subsequent images. In ITU-T H.265, after decoding the slice header, i.e., at the start of image decoding, a determination is made once for each image whether it should be removed from the DPB. For example, the reference... Figure 2 Pic2 is shown with reference to Pic1. Similarly, Pic3 is shown with reference to Pic0. Regarding Figure 2Assuming the number of images corresponds to the decoding order, the DPB will be populated as follows: After decoding Pic0, the DPB will include {Pic0}; at the start of decoding Pic1, the DPB will include {Pic0}; after decoding Pic1, the DPB will include {Pic0, Pic1}; at the start of decoding Pic2, the DPB will include {Pic0, Pic1}. Then, Pic2 will be decoded with reference to Pic1, and after decoding Pic2, the DPB will include {Pic0, Pic1, Pic2}. At the start of decoding Pic3, images Pic0 and Pic1 will be marked for removal from the DPB because they are not required for decoding Pic3 (or any subsequent images, not shown), and assuming Pic1 and Pic2 have already been output, the DPB will be updated to include {Pic0}. Pic3 will then be decoded with reference to Pic0. The process of marking images to remove them from the DPB can be called Reference Picture Set (RPS) management.

[0038] As described above, intra-frame prediction data or inter-frame prediction data is used to generate reference sample values ​​for blocks of sample values. The difference between sample values ​​included in the current PB or another type of picture region structure and the associated reference samples (e.g., those generated using prediction) can be referred to as residual data. Residual data can include a corresponding array of differences corresponding to each component of the video data. The residual data may be in the pixel domain. Transformations such as Discrete Cosine Transform (DCT), Discrete Sine Transform (DST), integer transform, wavelet transform, or conceptually similar transforms can be applied to the array of differences to generate transform coefficients. It should be noted that in ITU-T H.265 and JVET-P2001, the CU is associated with a transform tree structure having its root at the CU level. The transform tree is divided into one or more transform units (TUs). That is, to generate transform coefficients, the array of differences can be partitioned (e.g., four 8×8 transforms can be applied to a 16×16 residual value array). For each component of the video data, such a subdivision of the differences can be referred to as a transform block (TB). It should be noted that in some cases, a core transform and a subsequent second transform can be applied (in a video encoder) to generate transform coefficients. For a video decoder, the order of the transforms is reversed.

[0039] Quantization can be performed directly on transform coefficients or residual sample values ​​(e.g., in the case of palette-encoded quantization). Quantization approximates transform coefficients by limiting the amplitude to a specified set of values. Quantization essentially scales the transform coefficients to change the amount of data needed to represent a set of transform coefficients. Quantization may include dividing the transform coefficient (or the value obtained by adding an offset value to the transform coefficient) by a quantization scaling factor and any associated rounding function (e.g., rounding to the nearest integer). The quantized transform coefficients may be referred to as coefficient bit values. Inverse quantization (or “dequantization”) may include multiplying the coefficient bit value by the quantization scaling factor, and any reciprocal rounding or offset addition operations. It should be noted that, as used herein, the term quantization process may refer in some cases to division by a scaling factor to generate a bit value, and in some cases to multiplication by a scaling factor to recover the transform coefficient. That is, quantization process may refer to quantization in some cases and inverse quantization in others. Furthermore, it should be noted that although some examples below describe quantization processes for arithmetic operations related to decimal notation, such descriptions are for illustrative purposes and should not be construed as limiting. For example, the techniques described herein can be implemented in devices using binary arithmetic, etc. For example, the multiplication and division operations described herein can be implemented using bit shifting operations, etc.

[0040] Entropy coding techniques can be used to entropy-encode quantized transform coefficients and syntax elements (e.g., syntax elements indicating the coding structure of video blocks). The entropy coding process involves encoding the syntax element values ​​using a lossless data compression algorithm. Examples of entropy coding techniques include Content Adaptive Variable Length Coding (CAVLC), Context Adaptive Binary Arithmetic Coding (CABAC), Probability Interval Partition Entropy Coding (PIPE), etc. The entropy-encoded quantized transform coefficients and the corresponding entropy-encoded syntax elements can form a compatible bitstream that can be used to reproduce video data at the video decoder. The entropy coding process, such as CABAC, may include binarizing the syntax elements. Binarization is the process of converting the values ​​of syntax elements into a sequence of one or more bits. These bits may be referred to as "bins". Binarization may include one or a combination of the following coding techniques: fixed-length coding, unary coding, truncated unary coding, truncated Rice coding, Golomb coding, k-order exponential Golomb coding, and Golomb-Rice coding. For example, binarization may include representing the integer value 5 of a syntax element as 00000101 using an 8-bit fixed-length binarization technique, or representing the integer value 5 as 11110 using a unary coding binarization technique. As used herein, each of the terms fixed-length coding, unary coding, truncated unary coding, truncated Rice coding, Golomb coding, k-order exponential Golomb coding, and Golomb-Rice coding may refer to a general implementation of these techniques and / or a more specific implementation of these coding techniques. For example, a Golomb-Rice coding implementation may be specifically defined according to a video coding standard. In the CABAC example, for a particular bin, the context provides the bin's maximum probability state (MPS) value (i.e., the bin's MPS is either 0 or 1), and the probability value that the bin is in either the MPS or minimum probability state (LPS). For example, the context may indicate that the bin's MPS is 0 and the probability that the bin is 1 is 0.3. It should be noted that the context may be determined based on the values ​​of bins in the previous encodings of the current syntax element and bins in the previously encoded syntax elements. For example, the value of a syntax element associated with an adjacent video block can be used to determine the context of the current bin.

[0041] The following arithmetic operators can be used for the formulas used in this article:

[0042] Addition

[0043] - Subtraction

[0044] Multiplication, including matrix multiplication

[0045] x y Exponentiation. Specifies x as a power of y. In other contexts, this symbol is used as a superscript rather than intended to be interpreted as exponentiation.

[0046] / is an integer division that truncates the result towards zero. For example, it truncates 7 / 4 and -7 / -4 to 1, and -7 / 4 and 7 / -4 to -1.

[0047] ÷ is used to represent division in mathematical formulas when it is not intended to truncate or round.

[0048] Used to represent division in mathematical formulas when not intended for truncation or rounding.

[0049] In addition, the following mathematical functions can be used:

[0050] Log2(x) is the base-2 logarithm of x;

[0051]

[0052]

[0053] Ceil(x) is the smallest integer greater than or equal to x.

[0054] Regarding the exemplary syntax used in this article, the following definitions of logical operators can be applied:

[0055] x&&y The Boolean logic "and" of x and y

[0056] The Boolean OR operation between x and y.

[0057] ! Boolean logic "No"

[0058] x? y:z If x is TRUE or not equal to 0, evaluate to y; otherwise, evaluate to z.

[0059] In addition, the following relational operators can be applied:

[0060] > Greater than

[0061] ≥ Greater than or equal to

[0062] < Less than

[0063] ≤ Less than or equal to

[0064] == equals

[0065] ! = Not equal to

[0066] Furthermore, it should be noted that the following descriptors can be applied among the grammatical descriptors used in this paper:

[0067] -b(8): Bytes (8 bits) with any bit string pattern. The parsing process for this descriptor is specified by the return value of the function read_bit(8).

[0068] -f(n): A fixed-pattern bit string written using n bits (from left to right), starting from the leftmost bit. The parsing process for this descriptor is specified by the return value of the function read_bit(n).

[0069] -se(v): Syntax element for signed integer zero-order Exp-Golomb encoding, starting from the leftmost bit.

[0070] -tb(v): Uses a truncated binary code with up to maxVal bits, where maxVal is defined in the semantics of the syntax element.

[0071] -tu(v): Uses a truncated unary code with up to maxVal bits, where maxVal is defined in the semantics of the syntax element.

[0072] -u(n): Uses an n-bit unsigned integer. When n is "v" in the syntax table, the number of bits varies depending on the values ​​of other syntax elements. The parsing process for this descriptor is specified by the return value of the function read_bits(n), which is interpreted as a binary representation of the unsigned integer, with the most significant bit written first.

[0073] -ue(v): Syntax element of unsigned integer 0-order Exp-Golomb encoding, starting from the leftmost bit.

[0074] As mentioned above, video content comprises a video sequence consisting of a series of images, and each image can be divided into one or more regions. In JVET-P2001, the coded representation of an image is called a coded image, and all CTUs of a coded image are encapsulated in one or more coded slice NAL units. That is, one or more corresponding coded slice NAL units encapsulate the coded representation of the image. For example, refer again... Figure 2The encoded representation of Pic3 is encapsulated in three coded slice NAL units (i.e., slice 0 NAL unit, slice 1 NAL unit, and slice 2 NAL unit). It should be noted that the term Video Coding Layer (VCL) NAL unit is used as a general term for coded slice NAL units; that is, VCL NAL is a general term encompassing all types of slice NAL units. As mentioned above, and further described in detail below, NAL units can encapsulate metadata used for decoding video data. NAL units encapsulating metadata used for decoding video sequences are generally referred to as non-VCL NAL units. Therefore, in JVET-P2001, NAL units can be either VCL NAL units or non-VCL NAL units. It should be noted that VCL NAL units include slice header data, which provides information for decoding a particular slice. Therefore, in JVET-P2001, the information used for decoding video data (which may be referred to as metadata in some cases) is not limited to being included in non-VCL NAL units. JVET-P2001 defines a Picture Unit (PU) as a set of NAL units containing all VCL NAL units of an encoded picture and their associated non-VCL NAL units, and an Access Unit (AU) as a set of NAL units that are associated with each other according to a specified classification rule, are consecutive in the decoding order, and each existing Picture Unit contains exactly one encoded picture. A PU consists of a Picture Header NAL unit, an encoded picture (which is composed of one or more VCL NAL units), and zero or more non-VCL NAL units. Therefore, in JVET-P2001, an Access Unit includes one or more encoded pictures. In some cases, an Access Unit may include pictures included in different video layers. Video layers are described in further detail below. Furthermore, in JVET-P2001, a coded video sequence (CVS) is an AU sequence, consisting of CVSS AUs arranged in decoding order and zero or more subsequent non-CVSS AUs (including all subsequent AUs up to the next (excluding) any subsequent AU that is a CVSS AU), wherein the coded video sequence start (CVSS) AU is the AU in which each layer of the CVS contains a picture unit, and the coded picture in each existing picture unit is the coded layer video sequence start (CLVSS) picture. In JVET-P2001, a coded layer video sequence (CLVS) is a PU sequence within the same layer, consisting of CLVSS PUs arranged in decoding order and zero or more subsequent non-CLVSS PUs (including all subsequent PUs up to the next (excluding) any subsequent PU that is a CLVSS PU).In other words, in JVET-P2001, a bitstream can be described as a sequence of NAL units that form a CVS, where the CVS includes AUs, and each AU may include a corresponding picture of each of the multiple layers used to encode the video.

[0075] Multilayer video coding enables video presentation to be decoded / displayed as a presentation corresponding to a base layer of video data, and to be decoded / displayed as one or more additional presentations corresponding to enhancement layers of video data. For example, a base layer can enable video presentation with a basic quality level (e.g., high-definition presentation and / or a 30Hz frame rate), and enhancement layers can enable video presentation with an enhanced quality level (e.g., ultra-high-definition rendering and / or a 60Hz frame rate). Enhancement layers can be encoded by referencing the base layer. That is, for example, images in the enhancement layer can be encoded by referencing one or more images (including scaled versions) in the base layer (e.g., using inter-layer prediction techniques). It should be noted that layers can also be encoded independently of each other. In this case, inter-layer prediction may not exist between two layers. Each NAL unit can include an identifier indicating the video data layer associated with the NAL unit. As described above, the sub-bitstream extraction process can be used to decode and display only specific regions of interest of the images. Furthermore, the sub-bitstream extraction process can be used to decode and display only specific video layers. Sub-bitstream extraction can refer to the process by which a device receiving a compliant or conforming bitstream forms a new compliant or conforming bitstream by discarding and / or modifying data in the received bitstream. For example, sub-bitstream extraction can be used to form a new compliant or conforming bitstream corresponding to a specific video representation (e.g., a high-quality representation).

[0076] In JVET-P2001, each of video sequences, GOPs, pictures, slices, and CTUs can be associated with metadata describing video coding attributes. Some types of metadata are encapsulated in non-VCL NAL units. JVET-P2001 defines parameter sets that can be used to describe video data and / or video coding attributes. Specifically, JVET-P2001 includes five parameter sets: Decoding Parameter Set (DPS), Video Parameter Set (VPS), Sequence Parameter Set (SPS), Picture Parameter Set (PPS), and Adaptive Parameter Set (APS), where SPS is applied to zero or more integer CVSs, PPS to zero or more integer integer coded pictures, and APS to zero or more slices, and DPS and VPS can optionally be referenced by SPS. PPS is applied to the single coded picture that references it. In JVET-P2001, parameter sets can be encapsulated in non-VCL NAL units and / or can be signaled using other means (e.g., out-of-band transmission). JVET-P2001 also includes a Picture Header (PH), which is encapsulated as a non-VCLNAL unit. In JVET-P2001, the Picture Header is applied to all slices of the encoded picture. Furthermore, JVET-P2001 enables the signaling of Supplemental Enhancement Information (SEI) messages. In JVET-P2001, SEI messages assist in processes related to decoding, display, or other purposes; however, SEI messages may not be needed to construct luminance or chrominance samples based on the decoding process. In JVET-P2001, SEI messages can be signaled in the bitstream using non-VCL NAL units. Moreover, SEI messages can be transmitted through some mechanism other than existing within the bitstream (i.e., signaled out-of-band).

[0077] Figure 3 An example of a bitstream comprising multiple CVSs is shown, where each CVS includes an AU, and each AU includes a picture unit. Figure 3 The example shown corresponds to encapsulation in a bitstream. Figure 2 The example shown is a slice of NAL cell. Figure 3 In the example shown, the corresponding image unit of Pic3 includes three VCL NAL-coded slice NAL units, namely slice 0 NAL unit, slice 1 NAL unit, and slice 2 NAL unit, and two non-VCL NAL units, namely PPS NAL unit and PH NAL unit. It should be noted that in... Figure 3 In this context, the header is a NAL unit header (i.e., not to be confused with the slice header). Furthermore, it should be noted that in... Figure 3Other non-VCL NAL units, not shown, may be included in the CVS, such as SPS NAL units, VPS NAL units, SEI message NAL units, etc. Furthermore, it should be noted that in other examples, the PPS NAL unit used for decoding Pic3 may be included elsewhere in the bitstream, for example, in the picture unit corresponding to Pic0, or may be provided by an external organization. However, it should be noted that in JVET-P2001, the picture header for each picture is required to be in the picture unit corresponding to that picture.

[0078] JVET-P2001 defines the NAL unit header semantics, which specifies the type of the raw byte sequence payload (RBSP) data structure included in the NAL unit. Table 1 shows the syntax of the NAL unit header provided in JVET-P2001.

[0079]

[0080] Table 1

[0081] JVET-P2001 provides the following definitions for the corresponding syntax elements shown in Table 1.

[0082] forbidden_zero_bit should be equal to 0.

[0083] The nuh_reserved_zero_bit should be equal to "0". In the future, the value of nuh_reserved_zero_bit may be specified as 1 by ITU-T|ISO / IEC. The decoder should ignore (i.e., remove and discard) NAL units where nuh_reserved_zero_bit is equal to "1".

[0084] The nuh_layer_id specifies the identifier of the layer to which a VCL NAL element belongs, or the identifier of the layer to which a non-VCL NAL element applies. The value of nuh_layer_id should be in the range of 0 to 55 (inclusive). Other values ​​for nuh_layer_id are reserved for future use by ITU-T|ISO / IEC.

[0085] The nuh_layer_id value should be the same for all VCL NAL units of the encoded image. The nuh_layer_id value of the encoded image or PU is the nuh_layer_id value of the VCL NAL unit of the encoded image or PU.

[0086] The nuh_layer_id value of non-VCL NAL units is constrained as follows:

[0087] - If nal_unit_type is equal to PPS_NUT, PREFIX_APS_NUT or SUFFIX_APS_NUT, then nuh_layer_id should be equal to the lowest nuh_layer_id value of the coded slice NAL unit of the reference NAL unit.

[0088] Otherwise, if nal_unit_type is equal to SPS_NUT, then nuh_layer_id should be equal to the lowest nuh_layer_id value of the PPS NAL unit of the reference SPS NAL unit.

[0089] - Otherwise, if nal_unit_type is equal to AUD_NUT, then nuh_layer_id should be equal to vps_layer_id[0].

[0090] Otherwise, when nal_unit_type is equal to PH_NUT, EOS_NUT or FD_NUT, nuh_layer_id should be equal to the nuh_layer_id of the associated VCL NAL unit.

[0091] Note—The value of nuh_layer_id for DPS, VPS, and EOB NAL units is unrestricted.

[0092] The value of nal_unit_type should be the same for all images in CVSS AU.

[0093] nuh_temporal_id_plus1 minus 1 specifies the time identifier of the NAL unit.

[0094] The value of nuh_temporal_id_plus1 should not be equal to 0.

[0095] The variable TemporalId is exported as follows:

[0096] TemporalId=nuh_temporal_id_plus1-1

[0097] When nal_unit_type is in the range IDR_W_RADL to RSV_IRAP_12 (inclusive), TemporalId should be equal to 0.

[0098] When nal_unit_type equals STSA_NUT, TemporalId should not be equal to 0.

[0099] The TemporalId value should be the same for all VCL NAL units in an AU. The TemporalId value of an encoded picture, PU, ​​or AU is the TemporalId value of the VCL NAL unit in that encoded picture, PU, ​​or AU. The TemporalId value of a sublayer representation is the maximum value of the TemporalId of all VCL NAL units in the sublayer representation.

[0100] The TemporalId value of non-VCL NAL units is constrained as follows:

[0101] - If nal_unit_type is equal to DPS_NUT, VPS_NUT, or SPS_NUT, then TemporalId should be equal to 0, and the TemporalId of the AU containing the NAL unit should be equal to 0.

[0102] Otherwise, if nal_unit_type is equal to PH_NUT, then TemporalId should be equal to the TemporalId of the PU containing the NAL unit.

[0103] Otherwise, if nal_unit_type is equal to EOS_NUT or EOB_NUT, then TemporalId should be equal to 0.

[0104] Otherwise, if nal_unit_type is equal to AUD_NUT, FD_NUT, PREFIX_SEI_NUT, or SUFFIX_SEI_NUT, then TemporalId should be equal to the TemporalId of the AU containing the NAL unit.

[0105] Otherwise, when nal_unit_type is equal to PPS_NUT, PREFIX_APS_NUT or SUFFIX_APS_NUT, TemporalId should be greater than or equal to the TemporalId of the PU containing the NAL unit.

[0106] Note—When the NAL unit is a non-VCL NAL unit, the TemporalId value is equal to the minimum TemporalId value of all AUs applied to the non-VCL NAL unit. When nal_unit_type is equal to PPS_NUT, PREFIX_APS_NUT, or SUFFIX_APS_NUT, the TemporalId can be greater than or equal to the TemporalId of the AU, because all PPS and APS can be included at the beginning of the bitstream (e.g., when they are delivered out of band and the receiver places them at the beginning of the bitstream), where the first coded picture has a TemporalId equal to 0.

[0107] nal_unit_type specifies the NAL unit type, that is, the type of RBSP data structure contained in the NAL unit as specified in Table 2.

[0108] NAL units with nal_unit_type (whose semantics are not specified) within the range of UNSPEC28…UNSPEC31 (inclusive) should not affect the decoding process specified in this specification.

[0109] Note—NAL unit types within the range of UNSPEC_28…UNSPEC_31 may be used as determined by the application. Decoding procedures for these values ​​of nal_unit_type are not specified in this specification. Because different applications may use these NAL unit types for different purposes, special care must be taken when designing encoders that generate NAL units with these nal_unit_type values, and when designing decoders that interpret the contents of NAL units with these nal_unit_type values. No management of these values ​​is defined in this specification. These nal_unit_type values ​​may only be used in contexts where “conflicts” (i.e., NAL unit contents with the same nal_unit_type value have different meanings) are not important, or are impossible or manageable, such as in control applications or transport specifications, or in environments that control the distribution of bitstreams.

[0110] For purposes other than determining the amount of data in the decoding unit of the bitstream, the decoder should ignore (remove and discard) the contents of all NAL units that use the reserved value of nal_unit_type.

[0111] Note—This requirement allows for future definitions of compatible extensions to this specification.

[0112]

[0113]

[0114] Table 2

[0115] Note—A Clean Random Access (CRA) picture may have an associated RASL or RADL picture that exists in the bitstream.

[0116] Note—An Instantaneous Decode Refresh (IDR) picture with a nal_unit_type equal to IDR_N_LP does not have an associated preamble picture present in the bitstream. An IDR picture with a nal_unit_type equal to IDR_W_RADL does not have an associated RASL picture present in the bitstream, but may have an associated RADL picture present in the bitstream.

[0117] For any specific image's VCL NAL unit, the following applies:

[0118] - If mixed_nalu_types_in_pic_flag equals 0, then the value of nal_unit_type should be the same for all coded slice NAL units of the picture. The picture or PU is referred to as having the same NAL unit type as the coded slice NAL unit of the picture or PU.

[0119] - Otherwise (mixed_nalu_types_in_pic_flag equals 1), one or more of the VCL NAL units should all have a specific value of nal_unit_type in the range of IDR_W_RADL to CRA_NUT (inclusive), and all other VCL NAL units should all have a specific value of nal_unit_type in the range of TRAIL_NUT to RSV_VCL_6 (inclusive) or equal to GRA_NUT.

[0120] For single-layer bitstreams, the following constraints apply:

[0121] - Each picture in the bitstream, except the first picture, arranged in decoding order, is considered to be associated with a previous IRAP picture arranged in decoding order.

[0122] - When the image is a leading image of an IRAP image, the image should be a RADL or RASL image.

[0123] - When the image is a trailing image of an IRAP image, it should not be a RADL or RASL image.

[0124] -RASL images should not exist in the bitstream; these RASL images are associated with IDR images.

[0125] - RADL images should not exist in the bitstream; these RADL images are associated with IDR images that have a nal_unit_type equal to IDR_N_LP.

[0126] Note—Random access at the location of the IRAP PU can be performed by discarding all PUs preceding the IRAP PU (and correctly decoding the IRAP picture and all subsequent non-RASL pictures in the decoding order), provided that each parameter set (either in the bitstream or via an external means not specified in this specification) is available when referenced.

[0127] - Any image that precedes the IRAP image in the decoding order should precede the TRAP image in the output order, and should precede any RADL image associated with the IRAP image in the output order.

[0128] - Any RASL images associated with a CRA image should be listed before any RADL images associated with a CRA image in the output order.

[0129] - Any RASL image associated with a CRA image should be in the output order after any IRAP image that precedes the CRA image in the decoding order.

[0130] - If field_seq_flag equals 0, and the current image is a preceding image associated with an IRAP image, then the current image should precede all non-preceding images associated with the same IRAP image in the decoding order. Otherwise, let picA and picB be the first and last preceding images associated with the IRAP image, respectively, in the decoding order. There should be at most one non-preceding image before picA in the decoding order, and there should be no non-preceding image between picA and picB in the decoding order.

[0131] It should be noted that, generally speaking, an Intra-Random Access Point (IRAP) picture is a picture that does not reference any other picture besides itself for prediction during its decoding process. In JVET-P2001, an IRAP picture can be a Clean Random Access (CRA) picture or an Instantaneous Decode Refresh (IDR) picture. In JVET-P2001, the first picture in the bitstream arranged in decoding order must be an IRAP picture or a Progressive Decode Refresh (GDR) picture. JVET-P2001 describes the concept of a preamble picture, which is a picture that precedes the associated IRAP picture in the output order. JVET-P2001 also describes the concept of a tail picture, which is a non-IRAP picture that follows the associated IRAP picture in the output order. Tail pictures associated with IRAP pictures also follow the IRAP picture in the decoding order. For IDR pictures, there are no tail pictures that need to reference pictures decoded before the IDR picture. JVET-P2001 specifies that CRA pictures can have preamble pictures that follow the CRA picture in the decoding order and contain inter-picture predictions referencing pictures decoded before the CRA picture. Therefore, when a CRA picture is used as a random access point, these preamble pictures may be undecodeable and identified as Random Access Skip Preamble (RASL) pictures. Another type of picture that can follow the IRAP picture in the decoding order and precede the IRAP picture in the output order is the Random Access Decodeable Preamble (RADL) picture, which cannot contain references to any picture preceding the IRAP picture in the decoding order. A GDR picture is a picture in which each VCL NAL unit has a nal_unit_type equal to GDR_NUT. If the current image is a GDR image associated with the image header of the signal notification syntax element recovery_poc_cnt, and there exists an image picA in CLVS that is after the current GDR image in the decoding order and has a PicOrderCntVal equal to the PicOrderCntVal of the current GDR image plus the value of recovery_poc_cnt, then image picA is called the recovery point image.

[0132] As shown in Table 2, the NAL unit may include a decoding parameter set syntax structure. Table 3 shows the syntax structure of the DPS provided in JVET-P2001.

[0133]

[0134] Table 2

[0135] Regarding Table 2, JVET-P2001 provides the following semantics:

[0136] Prior to being referenced, the DPS RBSP should be available for the decoding process, either included in at least one AU with a TemporalId equal to 0 or provided by external means.

[0137] Note—The DPS NAL unit must be available (in the bitstream or by external means) for the decoding process prior to its reference. However, the DPS RBSP contains information unnecessary for the operation of the decoding processes specified in Clauses 2 through 9 of this specification.

[0138] The `dps_decoding_parameter_set_id` identifier identifies the DPS for reference by other syntax elements. The value of `dps_decoding_parameter_set_id` should not be equal to 0.

[0139] The increment of 1 in dps_max_sublayers_minus1 specifies the maximum number of temporal sublayers that may exist in each CVS referencing the DPS. The value of dps_max_sublayers_minus1 should be in the range of 0 to 6 (inclusive).

[0140] In this version of the bitstream conforming to this specification, dps_reserved_zero_5bits should be equal to 0. Other values ​​for dps_reserved_zero_5bits are reserved for future use by ITU-T|ISO / IEC.

[0141] The increment of dps_num_ptls_minus1 by 1 specifies the number of profile_tier_level() syntax structures in the DPS.

[0142] When there is more than one profile_tier_level() syntax structure in the DPS, the bitstream conformance requirement is that each CVS in the bitstream conforms to at least one profile_tier_level() syntax structure.

[0143] A value of 0 for dps_extension_flag indicates that the dps_extension_data_flag syntax element does not exist in the DPS RBSP syntax structure. A value of 1 for dps_extension_flag indicates that the dps_extension_data_flag syntax element exists in the DPS RBSP syntax structure.

[0144] The `dps_extension_data_flag` parameter can have any value. Its presence and value do not affect the decoder's conformance to the specified configuration file. Decoders conforming to this specification for this version should ignore all `dps_extension_data_flag` syntax elements.

[0145] As shown in Table 2, NAL units can include sequence parameter set syntax structures. Table 4 shows the syntax structure of SPS provided in JVET-P2001.

[0146]

[0147]

[0148]

[0149]

[0150]

[0151]

[0152]

[0153] Table 4

[0154] Regarding Table 4, JVET-P2001 provides the following semantics:

[0155] Prior to being referenced, the SPS RBSP should be available for the decoding process, either included in at least one AU with a TemporalId equal to 0 or provided by external means.

[0156] All SPS NAL cells in CVS with a specific value of sps_seq_parameter_set_id should have the same content.

[0157] When `sps_decoding_parameter_set_id` is greater than 0, it specifies the value of `dps_decoding_parameter_set_id` of the DPS referenced by the SPS. When `sps_decoding_parameter_set_id` is equal to 0, the SPS does not reference the DPS, and the DPS is not referenced when decoding for each CLVS that references the SPS. The value of `sps_decoding_parameter_set_id` should be the same across all SPSs referenced by the encoded image in the bitstream.

[0158] When sps_video_parameter_set_id is greater than 0, it specifies the value of vps_video_parameter_set_id of the VPS referenced by SPS.

[0159] When sps_video_parameter_set_id equals 0, the following applies:

[0160] -SPS does not reference VPS.

[0161] - When decoding each CLVS that references the SPS, the VPS is not referenced.

[0162] - It is inferred that the value of vps_max_layers_minus1 is equal to 0.

[0163] - The CVS should contain only one layer (i.e., all VCL NAL units in the CVS should have the same nuh_layer_id value).

[0164] - It is inferred that the value of GeneralLayerIdx[nuh_layer_id] is equal to 0.

[0165] - It is inferred that the value of vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]] is equal to 1.

[0166] When vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]] equals 1, an SPS referenced by CLVS with a specific nuh_layer_id value nuhLayerId should have a nuh_layer_id equal to nuhLayerId.

[0167] Increasing `sps_max_sublayers_minus1` by 1 specifies the maximum number of time-limited sublayers that may exist in each CLVS referencing the SPS. The value of `sps_max_sublayers_minus1` should be in the range of 0 to `vps_max_sublayers_minus1` (inclusive).

[0168] In this version of the bitstream conforming to this specification, sps_reserved_zero_4bits should be equal to 0. Other values ​​for sps_reserved_zero_4bits are reserved for future use by ITU-T|ISO / IEC.

[0169] A value of 1 for `sps_ptl_dpb_hrd_params_present_flag` indicates that the `profile_tier_level()` and `dpb_parameters()` syntax structures exist in SPS, and that the `general_hrd_parameters()` and `ols_hrd_parameters()` syntax structures also exist in SPS. A value of 0 for `sps_ptl_dpb_hrd_params_present_flag` indicates that none of these syntax structures exist in SPS. The value of `sps_ptl_dpb_hrd_params_present_flag` should be equal to `vps_independent_layer_flag[nuh_layer_id]`.

[0170] If `vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]]` equals 1, then the variable `MaxDecPicBuffMinus1` is set to equal `max_dec_pic_buffering_minus1[sps_max_sublayers_minus1]` in the `dpb_parameters()` syntax structure in the SPS. Otherwise, `MaxDecPicBuffMinus1` is set to equal `max_dec_pic_buffering_minus1[sps_max_sublayers_minus1]` in the `layer_nonoutput_dpb_params_idx[GeneralLayerIdx[nuh_layer_id]]`-th `dpb_parameters()` syntax structure in the VPS.

[0171] A `gdr_enabled_flag` value of 1 indicates that GDR images may exist in CLVS that reference SPS. A `gdr_enabled_flag` value of 0 indicates that GDR images do not exist in CLVS that reference SPS.

[0172] sps_seq_parameter_set_id provides an identifier for SPS for reference by other syntax elements.

[0173] Regardless of the nuh_layer_id value, SPS NAL cells share the same value space of sps_seq_parameter_set_id.

[0174] As specified, chroma_format_idc specifies the chroma sampling relative to the luminance sampling.

[0175] `separate_colour_plane_flag` equal to 1 specifies that the three color components of the 4:4:4 chroma format are encoded separately. `separate_colour_plane_flag` equal to 0 specifies that the color components are not encoded separately. When `separate_colour_plane_flag` does not exist, it is inferred to be equal to 0. When `separate_colour_plane_flag` equals 1, the encoded image consists of three separate components, each composed of encoded samples of a color plane (Y, Cb, or Cr) using a monochrome encoding syntax. In this case, each color plane is associated with a specific `colour_plane_id` value.

[0176] Note—There is no correlation in the decoding process between color planes with different color_plane_id values. For example, the decoding process for a monochrome image with one color_plane_id value does not use any data from monochrome images with different color_plane_id values ​​for inter-frame prediction.

[0177] Based on the value of separate_colour_plane_flag, the value of the variable ChromaArrayType is specified as follows:

[0178] - If separate_colour_plane_flag equals 0, then ChromaArrayType is set to equal chroma_format_idc.

[0179] Otherwise (if separate_colour_plane_flag equals 1), ChromaArrayType is set to 0.

[0180] `ref_pic_resampling_enabled_flag` equal to 1 specifies that reference image resampling can be applied when decoding encoded images in CLVS that reference SPS. `ref_pic_resampling_enabled_flag` equal to 0 specifies that reference image resampling should not be applied when decoding encoded images in CLVS that reference SPS.

[0181] `pic_width_max_in_luma_samples` specifies the maximum width of each coded image referencing SPS, in luminance samples. `pic_width_max_in_luma_samples` should not be equal to 0 and should be an integer multiple of `Max(8, MinCbSizeY)`.

[0182] `pic_height_max_in_luma_samples` specifies the maximum height of each coded image referencing SPS, in luminance samples. `pic_height_max_in_luma_samples` should not be equal to 0 and should be an integer multiple of `Max(8, MinCbSizeY)`.

[0183] The value of sps_log2_ctu_size_minus5 plus 5 specifies the luminance coding tree block size for each CTU. Bitstream compliance requires that the value of sps_log2_ctu_size_minus5 be less than or equal to 2.

[0184] The variables CtbLog2SizeY and CtbSizeY are exported as follows:

[0185] CtbLog2SizeY=sps_log2_ctu_size_minus5+5

[0186] CtbSizeY = 1 <CtbLog2SizeY

[0187] A subpics_present_flag value of 1 indicates that the subpics parameter exists in the SPS RBSP syntax. A subpics_present_flag value of 0 indicates that the subpics parameter does not exist in the SPS RBSP syntax.

[0188] Note—When the bitstream is the result of a sub-bitstream extraction process and contains only a subset of subpics from the input bitstream of the sub-bitstream extraction process, it may be necessary to set the value of subpics_present_flag to 1 in the RBSP of the SPS.

[0189] Incrementing sps_num_subpics_minus1 by 1 specifies the number of subpicks. sps_num_subpics_minus1 should be in the range of 0 to 254. If it does not exist, the value of sps_num_subpics_minus1 is assumed to be 0.

[0190] `subpic_ctu_top_left_x[i]` specifies the horizontal position of the top-left CTU of the i-th subpicture, in units of `CtbSizeY`. The syntax element has a length of `Ceil(Log2(pic_width_max_in_luma_samples / CtbSizeY))` bits. If it does not exist, the value of `subpic_ctu_top_left_x[i]` is assumed to be 0.

[0191] `subpic_ctu_top_left_y[i]` specifies the vertical position of the top-left CTU of the i-th subpicture, in units of `CtbSizeY`. The length of this syntax element is `Ceil(Log2(pic_height_max_in_luma_samples / CtbSizeY))` bits. If it does not exist, the value of `subpic_ctu_top_left_y[i]` is assumed to be 0.

[0192] `subpic_width_minus1[i]` incremented by 1 specifies the width of the i-th sub-image, in units of `CtbSizeY`. The syntax element has a length of `Ceil(Log2(pic_width_max_in_luma_samples / CtbSizeY))` bits. If it does not exist, the value of `subpic_width_minus1[i]` is inferred to be equal to `Ceil(pic_width_max_in_luma_samples / CtbSizeY)` - 1.

[0193] `subpic_height_minus1[i]` incremented by 1 specifies the height of the i-th subpicture, in units of `CtbSizeY`. The length of the syntax element is `Ceil(Log2(pic_height_max_in_luma_samples / CtbSizeY))` bits. If it does not exist, the value of `subpic_height_minus1[i]` is inferred to be equal to `Ceil(pic_height_max_in_luma_samples / CtbSizeY)` - 1.

[0194] A subpic_treated_as_pic_flag[i] equal to 1 indicates that the i-th subpic of each encoded picture in CLVS is considered as a picture in the decoding process excluding filtering operations within loops. A subpic_treated_as_pic_flag[i] equal to 0 indicates that the i-th subpic of each encoded picture in CLVS is not considered as a picture in the decoding process excluding filtering operations within loops. When it does not exist, it is inferred that the value of subpic_treated_as_pic_flag[i] is equal to 0.

[0195] A loop filter_across_subpic_enabled_flag[i] equal to 1 indicates that loop filtering can be performed across the boundary of the i-th subpic of each encoded picture in CLVS. A loop filter_across_subpic_enabled_flag[i] equal to 0 indicates that loop filtering is not performed across the boundary of the i-th subpic of each encoded picture in CLVS. When it does not exist, the value of loop filter_across_subpic_enabled_pic_flag[i] is assumed to be 1.

[0196] The following constraints apply to bitstream compliance requirements:

[0197] - For any two subpics subpicA and subpicB, when the subpica index of subpicA is less than the subpica index of subpicB, any NAL units of the encoded slice of subpicA should be arranged in decoding order before any NAL units of the encoded slice of subpicB.

[0198] - The shape of the sub-images should be such that each sub-image, when decoded, should have its entire left boundary and entire top boundary, which are either composed of the image boundaries or the boundaries of the previously decoded sub-images.

[0199] A value of 1 for `sps_subpic_id_present_flag` indicates that a subpick ID mapping exists in the SPS. A value of 0 for `sps_subpic_id_present_flag` indicates that a subpick ID mapping does not exist in the SPS.

[0200] A value of 1 for `sps_subpic_id_signalling_present_flag` indicates that a signal is sent in the SPS to notify the subpic ID mapping. A value of 0 for `sps_subpic_id_signalling_present_flag` indicates that a signal is not sent in the SPS to notify the subpic ID mapping. If it does not exist, the value of `sps_subpic_id_signalling_present_flag` is assumed to be 0.

[0201] Increasing 1 by 1 in sps_subpic_id_len_minus1 specifies the number of bits used to represent the syntax element sps_subpic_id[i]. The value of sps_subpic_id_len_minus1 should be in the range of 0 to 15 (inclusive).

[0202] `sps_subpic_id[i]` specifies the subpick ID of the i-th subpick. The length of the `sps_subpic_id[i]` syntax element is `sps_subpic_id_len_minus1+1` bits. When it does not exist, and when `sps_subpic_id_present_flag` is equal to 0, for each `i` in the range from 0 to `sps_num_subpics_minus1` (inclusive), the value of `sps_subpic_id[i]` is inferred to be equal to `i`.

[0203] The bit_depth_minus8 parameter specifies the bit depth of the samples in the BitDepth and chromaticity arrays and the value of the offset QpBdOffset for the luminance and chromaticity quantization parameters:

[0204] BitDepth = 8 + bit_depth_minus8

[0205] QpBdOffset=6*bit_depth_minus8

[0206] bit_depth_minus8 should be in the range of 0 to 8 (inclusive).

[0207] The minimum allowed quantization parameters for the transition skip mode are specified as follows:

[0208] QpPrimeTsMin=4+min_qp_prime_ts_minus4

[0209] The value of min_qp_prime_ts_minus4 should be in the range of 0 to 48 (inclusive).

[0210] A value of 1 for `sps_weighted_pred_flag` indicates that weighted predictions can be applied to P-slices that reference SPS. A value of 0 for `sps_weighted_pred_flag` indicates that weighted predictions should not be applied to P-slices that reference SPS.

[0211] A value of 1 for `sps_weighted_bipred_flag` indicates that explicit weighted predictions can be applied to B-slices referencing SPS. A value of 0 for `sps_weighted_bipred_flag` indicates that explicit weighted predictions are not applied to B-slices referencing SPS.

[0212] The following specifies the value of the variable MaxPicOrderCntLsb used in the decoding process of image order counting:

[0213] MaxPicOrderCntLsb=2 (log2_max_pic_order_cnt_lsb_minus4+4)

[0214] The value of Iog2_max_pic_order_cnt_lsb_minus4 should be in the range of 0 to 12 (inclusive).

[0215] A value of 1 for sps_poc_msb_flag indicates that the ph_poc_msb_cycle_present_flag syntax element exists in the PH that references SPS. A value of 0 for sps_poc_msb_flag indicates that the ph_poc_msb_cycle_present_flag syntax element does not exist in the PH that references SPS.

[0216] Incrementing 1 to poc_msb_len_minus1 specifies the length of the syntax element, in bits, when a poc_msb_val syntax element exists in the PH referencing the SPS. The value of poc_msb_len_minus1 should be in the range of 0 to 32 - log2_max_pic_order_cnt_lsb_minus4-5 (inclusive).

[0217] `sps_sublayer_dpb_params_flag` controls the presence of the syntax elements `max_dec_pic_buffering_minus1[i]`, `max_num_reorder_pics[i]`, and `max_latency_increase_plus1[i]` in the `dpb_parameters()` syntax structure in SPS. If these elements are not present, the value of `sps_sub_dpb_params_info_present_flag` is inferred to be 0.

[0218] A long_term_ref_pics_flag value of 0 indicates that no LTRP is used for inter-frame prediction of any coded pictures in CLVS. A long_term_ref_pics_flag value of 1 indicates that LTRP can be used for inter-frame prediction of one or more coded pictures in CLVS.

[0219] `inter_layer_ref_pics_present_flag` equal to 0 indicates that no ILRP is used for inter-frame prediction of any coded pictures in CLVS. `inter_layer_ref_pics_flag` equal to 1 indicates that ILRP is available for inter-frame prediction of one or more coded pictures in CLVS. When `sps_video_parameter_set_id` equals 0, the value of `inter_layer_ref_pics_present_flag` is inferred to be 0. When `vps_independent_layer_flag[GeneralLayerIdx[nuh_layer_id]]` equals 1, the value of `inter_layer_ref_pics_present_flag` should be 0.

[0220] `sps_idr_rpl_present_flag` equal to 1 indicates that the slice header of the IDR image contains a reference image list syntax element. `sps_idr_rpl_present_flag` equal to 0 indicates that the slice header of the IDR image does not contain a reference image list syntax element.

[0221] The value of rpl1_same_as_rpl0_flag equal to 1 indicates that the syntax element num_ref_pic__lists_in_sps[1] and the syntax structure ref_pic_list_struct(1,rplsIdx) do not exist, and the following applies:

[0222] - It is inferred that the value of num_ref_pic_lists_in_sps[1] is equal to the value of num_ref_pic_lists_in_sps[0].

[0223] - Infer that the value of each syntax element in ref_pic_list_struct(1,rplsldx) is equal to the value of the corresponding syntax element in ref_pic_list_struct(0,rplsldx) for rplsIdx in the range 0 to num_ref_pic_lists_in_sps[0]-1.

[0224] num_ref_pic_lists_m_sps[i] represents the number of ref_pic_list_struct(listIdx,rplsIdx) syntax structures included in the SPS, where listIdx is equal to i. The value of num_ref_pic_lists_in_sps[i] should be in the range of 0 to 64 (inclusive).

[0225] Note—For each value of listIdx (equal to 0 or 1), the decoder should allocate memory for a total of num_ref_pic_list_struct(listIdx,rplsIdx) syntax structures, because there may be a ref_pic_list_struct(listIdx,rplsIdx) syntax structure in the slice header of the current image that directly sends a signal notification.

[0226] `qtbtt_dual_tree_intra_flag` equal to 1 specifies that, for I-slices, implicit quadtree partitioning is used to divide each CTU into coding units with 64×64 luma samples, and these coding units are the roots of two separate `coding_tree` syntax structures for luma and chroma. `qtbtt_dual_tree_intra_flag` equal to 0 specifies that separate `coding_tree` syntax structures are not used for I-slices. When `qtbtt_dual_tree_intra_flag` does not exist, it is inferred to be equal to 0.

[0227] The value of log2_min_luma_coding_block_size_minus2 plus 2 specifies the minimum luminance coding block size. The value of log2_min_luma_coding_block_size_minus2 should be in the range of 0 to log2_ctu_size_minus5+3 (inclusive).

[0228] The variables MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows:

[0229] MinCbLog2SizeY=log2_mm_luma_coding_block_size_minus2+2

[0230] MinCbSizeY=1< <MinCbLog2SizeY

[0231] IbcBufWidthY=256*128 / CtbSizeY

[0232] IbcBufWidthC=IbcBufWidthY / SubWidthC

[0233] VSize = Min(64, CtbSizeY)

[0234] The value of MinCbSizeY shall be less than or equal to VSize.

[0235] The variables CtbWidthC and CtbHeightC respectively specify the width and height of the array of each chroma CTB, and these two variables are derived as follows:

[0236] - If chroma_format_idc is equal to 0 (monochrome) or separate_colour_plane_flag is equal to 1, then both CtbWidthC and CtbHeightC are equal to 0.

[0237] - Otherwise, CtbWidthC and CtbHeightC are derived as follows:

[0238] CtbWidthC = CtbSizeY / SubWidthC

[0239] CtbHeightC = CtbSizeY / SubHeightC

[0240] For log2BlockWidth in the range from 0 to 4 and log2BlockHeight in the range from 0 to 4 (including the end values), the specified upper-right diagonal and raster scan order array initialization process is called with 1 << log2BlockWidth and 1 << log2BlockHeight as inputs, and the output is assigned to DiagScanOrder[log2BlockWidth][log2BlockHeight].

[0241] For log2BlockWidth in the range from 0 to 6 and log2BlockHeight in the range from 0 to 6 (including the end values), the specified horizontal and vertical traversal scan order array initialization process is called with 1 << log2BlockWidth and 1 << log2BlockHeight as inputs, and the output is assigned to HorTravScanOrder[log2BlockWidth][log2BlockHeight] and VerTravScanOrder[log2BlockWidth][log2BlockHeight].

[0242] A partition_constraints_override_enabled_flag value of 1 indicates that partition_constraints_override_flag exists in the PH referencing SPS. A partition_constraints_override_enabled_flag value of 0 indicates that partition_constraints_override_flag does not exist in the PH referencing SPS.

[0243] `sps_log2_diff_min_qt_min_cb_intra_slice_luma` specifies the default difference between the base-2 logarithm of the smallest size of the luminance samples in the luminance blade block generated by quadtree segmentation of the CTU and the base-2 logarithm of the smallest coded block size in the luminance samples of the luminance CU in a slice with slice_type equal to 2(I) referencing the SPS. This default difference can be overridden by `pic_log2_diff_min_qt_min_cb_luma` existing in the PH referencing the SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_min_qt_min_cb_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). The base-2 logarithm of the smallest size of the luminance samples in the luminance blade block generated by quadtree segmentation of the CTU is derived as follows:

[0244] MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma+MinCbLog2SizeY

[0245] `sps_log2_diff_min_qt_min_cb_inter_slice` specifies the default difference between the base-2 logarithm of the smallest size of the luminance samples in the luminance blade block generated by quadtree segmentation of the CTU and the base-2 logarithm of the smallest luminance coding block size in the luminance samples of the luminance CU in the slice with slice_type equal to 0 (B) or 1 (P) referencing the SPS. This default difference can be overridden by `pic_log2_diff_min_qt_min_cb_luma` existing in the PH referencing the SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_min_qt_min_cb_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). The base-2 logarithm of the smallest size of the luminance samples in the luminance blade block generated by quadtree segmentation of the CTU is derived as follows:

[0246] MinQtLog2SizeInterY=sps_log2_diff_min_qt_min_cb_inter_slice+MinCbLog2SizeY

[0247] `sps_max_mtt_hierarchy_depth_inter_slice` specifies the default maximum hierarchical depth of coding units generated by multi-type tree splitting of quadtree leaves in slices referencing the SPS with slice_type equal to 0 (B) or 1 (P). When `partition_constraints_override_enabled_flag` is equal to 1, the default maximum hierarchical depth can be overridden by `pic_max_mtt_hierarchy_depth_inter_slice` existing in the PH of the referencing SPS. The value of `sps_max_mtt_hierarchy_depth_inter_slice` should be in the range of 0 to 2*(CtbLog2SizeY - MinCbLog2SizeY) (inclusive).

[0248] `sps_max_mtt_hierarchy_depth_intra_slice_luma` specifies the default maximum hierarchical depth of the coding units generated by multi-type tree splitting of quadtree leaves in slices referencing SPS with slice_type equal to 2(I). When `partition_constraints_override_enabled_flag` equals 1, the default maximum hierarchical depth can be overridden by `pic_max_mtt_hierarchy_depth_intra_slice_luma` existing in the PH of the referenced SPS. The values ​​of `sps_max_mtt_hierarchy_depth_intra` and `slice_luma` should be in the range of 0 to 2*(CtbLog2SizeY - MinCbLog2SizeY) (inclusive).

[0249] `sps_log2_diff_max_bt_min_qt_intra_slice_luma` specifies the base-2 logarithm of the maximum size (width or height) of the luminance samples in a luminance coded block that can be binary-partitioned, and the base-2 logarithm of the minimum size (width or height) of the luminance blade block resulting from quadtree partitioning of the CTU in a slice with slice_type equal to 2(I) referencing the SPS. This default difference can be overridden by `pic_log2_diff_max_bt_min_qt_luma` existing in the PH of the referencing SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_max_bt_min_qt_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeIntraY` (inclusive). If sps_log2_diff_max_bt_min_qt_intra_slice_luma does not exist, it is inferred that the value of sps_log2_diff_max_bt_min_qt_intra_slice_luma is equal to 0.

[0250] `sps_log2_diff_max_tt_min_qt_intra_slice_luma` specifies the base-2 logarithm of the maximum size (width or height) of the luminance samples in a luminance coding block that can be partitioned using ternary segmentation, and the base-2 logarithm of the minimum size (width or height) of the luminance blade block resulting from quadtree partitioning of the CTU in a slice with slice_type equal to 2(I) referencing the SPS. This default difference can be overridden by `pic_log2_diff_max_tt_min_qt_luma` existing in the PH of the referencing SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_max_tt_min_qt_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeIntraY` (inclusive). When sps_log2_diff_max_tt_min_qt_intra_slice_luma does not exist, it is inferred that the value of sps_log2_diff_max_tt_min_qt_intra_slice_luma is equal to 0.

[0251] `sps_log2_diff_max_bt_min_qt_inter_slice` specifies the base-2 logarithm of the maximum size (width or height) of the luminance samples in a luminance coded block that can be binary-segmented, and the base-2 logarithm of the minimum size (width or height) of the luminance samples in a luminance blade block resulting from quadtree segmentation of the CTU in a slice with a slice_type equal to 0 (B) or 1 (P) referencing the SPS. This default difference can be overridden by `pic_log2_diff_max_bt_min_qt_luma` existing in the PH of the referencing SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_max_bt_min_qt_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeInterY` (inclusive). If sps_log2_diff_max_bt_min_qt_inter_slice does not exist, it is inferred that the value of sps_log2_diff_max_bt_min_qt_inter_slice is equal to 0.

[0252] `sps_log2_diff_max_tt_min_qt_inter_slice` specifies the base-2 logarithm of the maximum size (width or height) of the luminance samples in a luminance coding block that can be segmented using ternary partitioning, and the base-2 logarithm of the minimum size (width or height) of the luminance blade block resulting from quadtree partitioning of the CTU in a slice with slice_type equal to 0 (B) or 1 (P) referencing the SPS. This default difference can be overridden by `pic_log2_diff_max_tt_min_qt_luma` existing in the PH of the referenced SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_max_tt_min_qt_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeInterY` (inclusive). If sps_log2_diff_max_tt_min_qt_inter_slice does not exist, it is inferred that the value of sps_log2_diff_max_tt_min_qt_inter_slice is equal to 0.

[0253] `sps_log2_diff_min_qt_min_cb_intra_slice_chroma` specifies the default difference between the logarithm (base 2) of the smallest size of the luminance samples in the chroma leaf blocks resulting from quadtree partitioning of the chroma CTU with `treeType` equal to `DUAL_TREE_CHROMA`, and the logarithm (base 2) of the smallest code block size in the luminance samples of the chroma CU with `treeType` equal to `DUAL_TREE_CHROMA` in a slice with `slice_type` equal to 2(I) referencing the SPS. This default difference can be overridden by `pic_log2_diff_min_qt_min_cb_chroma` existing in the PH referencing the SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_min_qt_min_cb_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). When it does not exist, the value of `sps_log2_diff_min_qt_min_cb_intra_slice_chroma` is inferred to be 0. The base-2 logarithm of the smallest size of the chroma leaf block luminance sample generated by quadtree segmentation of a CTU with `treeType` equal to `DUAL_TREE_CHROMA` is derived as follows:

[0254] MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma+MinCbLog2SizeY

[0255] `Sps_max_mtt_hierarchy_depth_intra_slice_chroma` specifies the default maximum hierarchical depth of chroma coding units generated by multi-type tree segmentation of chroma quadtree leaves with `treeType` equal to `DUAL_TREE_CHROMA` in slices referencing `SPS` with `slice_type` equal to 2(I). When `partition_constraints_override_enabled_flag` equals 1, the default maximum hierarchical depth can be overridden by `pic_max_mtt_hierarchy_depth_chroma` existing in the `PH` of the referencing `SPS`. The value of `sps_max_mtt_hierarchy_depth_intra_slice_chroma` should be in the range of 0 to 2*(CtbLog2SizeY - MinCbLog2SizeY) (inclusive). If it does not exist, the value of `sps_max_mtt_hierarchy_depth_intra_slice_chroma` is inferred to be 0.

[0256] `sps_log2_diff_max_bt_min_qt_intra_slice_chroma` specifies the base-2 logarithm of the maximum size (width or height) of the luminance samples of a chroma-coded block that can be binary-partitioned, and the base-2 logarithm of the minimum size (width or height) of the luminance samples of a chroma CTU with `treeType` equal to `DUAL_TREE_CHROMA` in a slice with `slice_type` equal to 2(I) referencing the SPS. This default difference can be overridden by `pic_log2_diff_max_bt_min_qt_chroma` existing in the PH of the referencing SPS when `partition_constraints_override_enabled_flag` is equal to 1. The value of `sps_log2_diff_max_bt_min_qt_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeIntraC` (inclusive). When sps_log2_diff_max_bt_min_qt_intra_slice_chroma does not exist, it is inferred that the value of sps_log2_diff_max_bt_min_qt_intra_slice_chroma is equal to 0.

[0257] `sps_log2_diff_max_tt_min_qt_intra_slice_chroma` specifies the base-2 logarithm of the maximum size (width or height) of the luminance samples in a chroma-coded block that can be partitioned using ternary partitioning, and the base-2 logarithm of the minimum size (width or height) of the luminance samples in a chroma CTU with `treeType` equal to `DUAL_TREE_CHROMA` in a slice with `slice_type` equal to 2(I) referencing the SPS. This default difference can be overridden by `pic_log2_diff_max_tt_min_qt_chroma` existing in the PH of the referenced SPS when `partition_constraints_override_enabled_flag` equals 1. The value of `sps_log2_diff_max_tt_min_qt_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeIntraC` (inclusive). If sps_log2_diff_max_tt_min_qt_intra_slice_chroma does not exist, it is inferred that the value of sps_log2_diff_max_tt_min_qt_intra_slice_chroma is equal to 0.

[0258] `sps_max_luma_transform_size_64_flag` equal to 1 specifies that the maximum transformation size in the luminance sample is 64. `sps_max_luma_transform_size_64_flag` equal to 0 specifies that the maximum transformation size in the luminance sample is 32. When `CtbSizeY` is less than 64, the value of `sps_max_luma_transform_size_64_flag` should be 0.

[0259] The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, and MaxTbSizeY are derived as follows:

[0260] MinTbLog2SizeY=2

[0261] MaxTbLog2SizeY=sps_max_luma_transfonn_size_64_flag? 6:5

[0262] MinTbSizeY=1< <MinTbLog2SizeY

[0263] MaxTbSizeY = 1 <MaxTbLog2SizeY

[0264] A value of 0 for `sps_joint_cbcr_enabled_flag` indicates that joint encoding of chroma residuals is disabled. A value of 1 for `sps_joint_cbcr_enabled_flag` indicates that joint encoding of chroma residuals is enabled.

[0265] `same_qp_table_for_chroma` equal to 1 specifies that when `sps_joint_cbcr_enabled_flag` equals 1, a signal is sent indicating only one chroma QP map table, applicable to both Cb and Cr residuals, and additionally applicable to the joint Cb-Cr residual. `same_qp_table_for_chroma` equal to 0 specifies that when `sps_joint_cbcr_enabled_flag` equals 1, a signal is sent in SPS indicating two chroma QP maps for Cb and Cr, and another for the joint Cb-Cr. When `same_qp_table_for_chroma` is not present in the bitstream, it is inferred that `same_qp_table_for_chroma` is equal to 1.

[0266] The increment 26 in `qp_table_start_minus26[i]` specifies the starting luminance and chrominance QP used to describe the i-th chrominance QP mapping table. The value of `qp_table_start_minus26[i]` should be in the range of -26 - QpBdOffset to 36 (inclusive). If `qp_table_start_minus26[i]` is not present in the bitstream, it is inferred that the value of `qp_table_start_minus26[i]` is equal to 0.

[0267] The increment of 1 in num_points_in_qp_table_minus1[i] specifies the number of points used to describe the i-th chroma QP map. The value of num_points_in_qp_table_minus1[i] should be in the range of 0 to 63+QpBdOffset (inclusive). If num_points_in_qp_table_minus1[0] does not exist in the bitstream, it is inferred that the value of num_points_in_qp_table_minus1[0] is equal to 0.

[0268] delta_qp_in_val_minus1[i][j] specifies the increment value of the input coordinates used to derive the j-th pivot point of the i-th chroma QP map. When delta_qp_in_val_minus1[0][j] does not exist in the bitstream, it is inferred that the value of delta_qp_in_val_minus1[0][j] is equal to 0.

[0269] delta_qp_diff_val[i][j] specifies the incremental value used to derive the output coordinates of the j-th pivot point of the i-th chromaticity QP mapping table.

[0270] The i-th chroma QP mapping table ChromaQpTable[i] is derived as follows, where i = 0..numQpTables-1:

[0271]

[0272] When same_qp_table_for_chroma equals 1, ChromaQpTable[1][k] and ChromaQpTable[2][k] are set to equal ChromaQpTable[0][k], where k = -QpBdOffset..63.

[0273] For bitstream compliance requirements, the values ​​of qpInVal[i][j] and qpOutVal[i][j] should be in the range of -QpBdOffset to 63 (inclusive), where i = 0..numQpTables-1 and j = 0..num_points_in_qp_table_minus1[i]+1.

[0274] `sps_sao_enabled_flag` equal to 1 specifies that the sample adaptive offset process is applied to the reconstructed image after the unblocking filter process. `sps_sao_enabled_flag` equal to 0 specifies that the sample adaptive offset process is not applied to the reconstructed image after the unblocking filter process.

[0275] A value of 0 for sps_alf_enabled_flag disables the adaptive loop filter. A value of 1 for sps_alf_cnablcd_flag enables the adaptive loop filter.

[0276] A value of 1 for `sps_transform_skip_enabled_flag` indicates that the `transform_skip_flag` is allowed in the transformation unit syntax. A value of 0 for `sps_transform_skip_enabled_flag` indicates that the `transform_skip_flag` is not allowed in the transformation unit syntax.

[0277] A value of 1 for `sps_bdpcm_enabled_flag` indicates that the `intra_bdpcm_luma_flag` may exist in the coding unit syntax for intra coding units. A value of 0 for `sps_bdpcm_enabled_flag` indicates that the `intra_bdpcm_luma_flag` does not exist in the coding unit syntax for intra coding units. When it does not exist, the value of `sps_bdpcm_enabled_flag` is presumed to be 0.

[0278] A value of 1 for `sps_bdpcm_chroma_enabled_flag` indicates that `intra_bdpcm_chroma_flag` may exist in the coding unit syntax for intra coding units. A value of 0 for `sps_bdpcm_chroma_enabled_flag` indicates that `intra_bdpcm_chroma_flag` does not exist in the coding unit syntax for intra coding units. When it does not exist, the value of `sps_bdpcm_chroma_enabled_flag` is presumed to be 0.

[0279] `sps_ref_wraparound_enabled_flag` equal to 1 specifies that horizontal wraparound motion compensation is applied in inter-frame prediction. `sps_ref_wraparound_enabled_flag` equal to 0 specifies that horizontal wraparound motion compensation is not applied. When the value of (CtbSizeY / MinCbSizeY+1) is less than or equal to (pic_width_in_luma_samples / MinCbSizeY-1), where pic_width_in_luma_samples is the value of pic_width_in_luma_samples in any PPS referencing SPS, the value of `sps_ref_wraparound_enabled_flag` should be equal to 0.

[0280] The increment of 1 in `sps_ref_wraparound_offset_minus1` specifies the offset used to calculate the horizontal wraparound position, in MinCbSizeY luminance samples. The value of `ref_wraparound_offset_minus1` should be in the range of (CtbSizeY / MinCbSizeY)+1 to (pic_width_in_luma_samples / MinCbSizeY)-1 (inclusive), where `pic_width_in_luma_samples` is the value of `pic_width_in_luma_samples` in any PPS referencing SPS.

[0281] A value of 1 for `sps_temporal_mvp_enabled_flag` indicates that the temporal motion vector predictor can be used in CLVS. A value of 0 for `sps_temporal_mvp_enabled_flag` indicates that the temporal motion vector predictor is not used in CLVS.

[0282] `sps_sbtmvp_enabled_flag` equal to 1 specifies that a sub-block-based temporal motion vector predictor can be used in CLVS for image decoding, where all slices have a `slice_type` not equal to 1. `sps_sbtmvp_enabled_flag` equal to 0 specifies that the sub-block-based temporal motion vector predictor is not used in CLVS. If `sps_sbtmvp_enabled_flag` does not exist, it is inferred to be equal to 0.

[0283] A value of 1 for sps_amvr_enabled_flag specifies that adaptive motion vector differential resolution is used in motion vector coding. A value of 0 for amvr_enabled_flag specifies that adaptive motion vector differential resolution is not used in motion vector coding.

[0284] A value of 0 for sps_bdof_enabled_flag indicates that bidirectional optical flow inter-frame prediction is disabled. A value of 1 for sps_bdof_enabled_flag indicates that bidirectional optical flow inter-frame prediction is enabled.

[0285] `sps_bdof_pic_present_flag` equal to 1 indicates that `pic_disable_bdof_flag` exists in the PH referencing SPS. `sps_bdof_pic_present_flag` equal to 0 indicates that `pic_disable_bdof_flag` does not exist in the PH referencing SPS. When `sps_bdof_pic_present_flag` does not exist, it is inferred that the value of `sps_bdof_pic_present_flag` is equal to 0.

[0286] A value of 1 for sps_smvd_enabled_flag indicates that symmetric motion vector difference can be used in motion vector decoding. A value of 0 for sps_smvd_enabled_flag indicates that symmetric motion vector difference is not used in motion vector encoding.

[0287] A value of 1 for sps_dmvr_enabled_flag indicates that inter-frame dual prediction based on decoder motion vector correction is enabled. A value of 0 for sps_dmvr_enabled_flag indicates that inter-frame dual prediction based on decoder motion vector correction is disabled.

[0288] `sps_dmvr_pic_present_flag` equal to 1 indicates that `pic_disable_dmvr_flag` exists in the PH referencing SPS. `sps_dmvr_pic_present_flag` equal to 0 indicates that `pic_disable_dmvr_flag` does not exist in the PH referencing SPS. When `sps_dmvr_pic_present_flag` does not exist, it is inferred that the value of `sps_dmvr_pic_present_flag` is equal to 0.

[0289] A value of 1 for sps_mmvd_enabled_flag indicates that the merge mode with motion vector difference is enabled. A value of 0 for sps_mmvd_enabled_flag indicates that the merge mode with motion vector difference is disabled.

[0290] A value of 1 for sps_isp_enabled_flag indicates that intra-prediction with sub-partitions is enabled. A value of 0 for sps_isp_enabled_flag indicates that intra-prediction with sub-partitions is disabled.

[0291] A value of 1 for sps_mrl_enabled_flag indicates that intra-prediction with multiple reference lines is enabled. A value of 0 for sps_mrl_enabled_flag indicates that intra-prediction with multiple reference lines is disabled.

[0292] A value of 1 for sps_mip_enabled_flag indicates that matrix-based intra-prediction is enabled. A value of 0 for sps_mip_enabled_flag indicates that matrix-based intra-prediction is disabled.

[0293] A value of 0 for `sps_cclm_enabled_flag` disables intra-frame prediction using the cross-component linear model from the luma component to the chroma component. A value of 1 for `sps_cclm_enabled_flag` enables intra-frame prediction using the cross-component linear model from the luma component to the chroma component. If `sps_cclm_enabled_flag` does not exist, it is inferred to be equal to 0.

[0294] `sps_chroma_horizontal_collocated_flag` equal to 1 specifies that the prediction process is designed to operate for chroma sample positions that are not horizontally shifted relative to the corresponding luminance sample positions. `sps_chroma_horizontal_collocated_flag` equal to 0 specifies that the prediction process is designed to operate for chroma sample positions that are shifted 0.5 luminance sample units to the right relative to the corresponding luminance sample positions. When `sps_chroma_horizontal_collocated_flag` does not exist, it is inferred to be equal to 1.

[0295] `sps_chroma_vertical_collocated_flag` equal to 1 specifies that the prediction process is designed to operate for chroma sample positions that are not vertically shifted relative to the corresponding luminance sample position. `sps_chroma_vertical_collocated_flag` equal to 0 specifies that the prediction process is designed to operate for chroma sample positions that are shifted downwards by 0.5 luminance sample units relative to the corresponding luminance sample position. When `sps_chroma_vertical_collocated_flag` does not exist, it is inferred to be equal to 1.

[0296] `sps_mts_enabled_flag` equal to 1 indicates that both `sps_explicit_mts_intra_enabled_flag` and `sps_explicit_mts_inter_enabled_flag` exist in the sequence parameter set RBSP syntax. `sps_mts_enabled_flag` equal to 0 indicates that neither `sps_explicit_mts_intra_enabled_flag` nor `sps_explicit_mts_inter_enabled_flag` exist in the sequence parameter set RBSP syntax.

[0297] `sps_explicit_mts_intra_enabled_flag` equal to 1 indicates that `mts_idx` may exist in the intra-coding unit syntax. `sps_explicit_mts_mtra_enabled_flag` equal to 0 indicates that `mts_idx` does not exist in the intra-coding unit syntax. When it does not exist, it is inferred that the value of `sps_explicit_mts_intra_enabled_flag` is equal to 0.

[0298] A value of 1 for `sps_explicit_mts_inter_enabled_flag` indicates that `mts_idx` may exist in the inter-frame coding unit syntax. A value of 0 for `sps_explicit_mts_inter_enabled_flag` indicates that `mts_idx` does not exist in the inter-frame coding unit syntax. When `mts_idx` does not exist, it is inferred that the value of `sps_explicit_mts_inter_enabled_flag` is equal to 0.

[0299] A value of 0 for sps_sbt_enabled_flag disables subblock transforms for inter-frame prediction CUs. A value of 1 for sps_sbt_enabled_flag enables subblock transforms for inter-frame prediction CUs.

[0300] `sps_affine_enabled_flag` specifies whether affine-based motion compensation can be used for inter-frame prediction. If `sps_affine_enabled_flag` equals 0, the syntax should be constrained so that affine-based motion compensation is not used in CLVS, and `inter_affine_flag` and `cu_affine_type_flag` are not present in the CLVS coding unit syntax. Otherwise (`sps_affine_enabled_flag` equals 1), affine-based motion compensation can be used in CLVS.

[0301] `sps_affine_type_flag` specifies whether motion compensation based on a 6-parameter affine model can be used for inter-frame prediction. If `sps_affine_type_flag` equals 0, the syntax should be constrained so that motion compensation based on a 6-parameter affine model is not used in CLVS, and `cu_affine_type_flag` does not exist in the coding unit syntax of CLVS. Otherwise (`sps_affine_type_flag` equals 1), motion compensation based on a 6-parameter affine model can be used in CLVS. When it does not exist, the value of `sps_affine_type_flag` is inferred to be 0.

[0302] A value of 1 for `sps_affine_amvr_enabled_flag` specifies that adaptive motion vector difference resolution is used in motion vector coding in affine inter-frame mode. A value of 0 for `sps_affine_amvr_enabled_flag` specifies that adaptive motion vector difference resolution is not used in motion vector coding in affine inter-frame mode. If it does not exist, the value of `sps_affine_amvr_enabled_flag` is assumed to be 0.

[0303] `sps_affine_prof_enabled_flag` specifies whether prediction corrections using optical flow can be used for affine motion compensation. If `sps_affine_prof_enabled_flag` equals 0, optical flow is not applied to correct affine motion compensation. Otherwise (if `sps_affine_prof_enabled_flag` equals 1), optical flow can be applied to correct affine motion compensation. If it does not exist, it is assumed that the value of `sps_affine_prof_enabled_flag` is 0.

[0304] `sps_prof_pic_present_flag` equal to 1 indicates that `pic_disable_prof_flag` exists in the PH referencing SPS. `sps_prof_pic_present_flag` equal to 0 indicates that `pic_disable_prof_flag` does not exist in the PH referencing SPS. When `sps_prof_pic_present_flag` does not exist, it is inferred that the value of `sps_prof_pic_present_flag` is equal to 0.

[0305] `sps_palette_enabled_flag` equal to 1 indicates that the `pred_mode_plt_flag` may exist in the code unit syntax. `sps_palette_enabled_flag` equal to 0 indicates that the `pred_mode_plt_flag` does not exist in the code unit syntax. When `sps_palette_enabled_flag` does not exist, it is inferred that it is equal to 0.

[0306] A value of 1 for `sps_act_enabled_flag` indicates that adaptive color transformation can be used, and `cu_act_enabled_flag` may exist in the encoding unit syntax. A value of 0 for `sps_act_enabled_flag` indicates that adaptive color transformation is not used, and `cu_act_enabled_flag` does not exist in the encoding unit syntax. When `sps_act_enabled_flag` does not exist, it is inferred that it is equal to 0.

[0307] `sps_bcw_enabled_flag` specifies whether double prediction with CU weights can be used for inter-frame prediction. If `sps_bcw_enabled_flag` equals 0, the syntax should be constrained so that double prediction with CU weights is not used in CLVS, and `bcw_idx` does not exist in the CLVS coding unit syntax. Otherwise (`sps_bcw_enabled_flag` equals 1), double prediction with CU weights can be used in CLVS.

[0308] `sps_ibc_enabled_flag` equal to 1 indicates that IBC prediction mode can be used in CLVS for image decoding. `sps_ibc_enabled_flag` equal to 0 indicates that IBC prediction mode is not used in CLVS. When `sps_ibc_enabled_flag` does not exist, it is inferred that it is equal to 0.

[0309] `sps_ciip_enabled_flag` specifies that the ciip_flag may exist in the coding unit syntax used for inter-frame coding units. `sps_ciip_enabled_flag` equal to 0 indicates that the ciip_flag does not exist in the coding unit syntax used for inter-frame coding units.

[0310] `sps_fpel_mmvd_enabled_flag` equal to 1 indicates that the merge mode with motion vector difference is using integer sample precision. `sps_fpel_mmvd_enabled_flag` equal to 0 indicates that the merge mode with motion vector difference can use fractional sample precision.

[0311] `sps_triangle_enabled_flag` specifies whether triangle-based motion compensation can be used for inter-frame prediction. `sps_triangle_enabled_flag` equal to 0 specifies that the syntax should be constrained so that triangle-based motion compensation is not used in CLVS, and that `merge_triangle_split_dir`, `merge_triangle_idx0`, and `merge_triangle_idx1` are not present in the CLVS coding unit syntax. `sps_triangle_enabled_flag` equal to 1 specifies that triangle-based motion compensation can be used in CLVS.

[0312] A value of 1 for sps_lmcs_enabled_flag specifies that a luma map with chroma scaling is used in CLVS. A value of 0 for sps_lmcs_enabled_flag specifies that a luma map with chroma scaling is not used in CLVS.

[0313] A value of 1 for sps_lfnst_enabled_flag indicates that lfnst_idx may exist in the intra-coding unit syntax. A value of 0 for sps_lfnst_enabled_flag indicates that lfnst_idx does not exist in the intra-coding unit syntax.

[0314] sps_ladf_enabled_flag equal to 1 indicates that sps_num_ladf_intervals_minus2, sps_ladf_lowest_interval_qp_offset, sps_ladf_qp_offset[i] and sps_ladf_delta_threshold_minus1[i] exist in SPS.

[0315] Increasing 1 to sps_num_ladf_intervals_minus2 specifies the number of sps_ladf_delta_threshold_minus1[i] and sps_ladf_qp_offset[i] syntax elements present in SPS. The value of sps_num_ladf_intervals_minus2 should be in the range of 0 to 3 (inclusive).

[0316] sps_ladf_lowest_interval_qp_offset specifies the offset used to derive the specified variable qP. The value of sps_ladf_lowest_interval_qp_offset should be in the range of -63 to 63 (inclusive).

[0317] sps_ladf_qp_offset[i] specifies the offset array used to derive the specified variable qP. The value of sps_ladf_qp_offset[i] should be in the range of -63 to 63 (inclusive).

[0318] `sps_ladf_delta_threshold_minus1[i]` is used to calculate the value of `SpsLadflntervalLowerBound[i]`, which specifies the lower bound of the i-th luminance intensity level interval. The value of `sps_ladf_delta_threshold_minus1[i]` should be between 0 and 2. BitDepth The range is -3 (inclusive).

[0319] Set the value of SpsLadflntervalLowerBound[0] to 0.

[0320] For each value of i in the range of 0 to sps_num_ladf_intervals_minus2 (inclusive), the variable SpsLadflntervalLowerBound[i+1] is derived as follows:

[0321] SpsLadflntervalLowerBound[i+1]=SpsLadflntervalLowerBound[i]+sps_ladf_delta_threshold__minus 1[i]+1

[0322] A value of 1 for `sps_scaling_list_enabled_flag` specifies that the scaling list is used in the scaling process for transform coefficients. A value of 0 for `sps_scaling_list_enabled_flag` specifies that the scaling list is not used in the scaling process for transform coefficients.

[0323] `sps_loop_filter_across_virtual_boundaries_disabled_present_flag` equal to 1 specifies that in-loop filtering operations are disabled on virtual boundaries in images referencing SPS. `sps_loop_filter_across_virtual_boundaries_disabled_present_flag` equal to 0 specifies that this type of disabling of in-loop filtering operations is not applied in images referencing SPS. In-loop filtering operations include unblocking filters, sample adaptive offset filters, and adaptive loop filter operations.

[0324] sps_num_ver_virtual_boundaries specifies the number of sps_virtual_boundaries_pos_x[i] syntax elements that exist in SPS. If sps_num_ver_virtual_boundaries does not exist, it is inferred to be equal to 0.

[0325] sps_virtual_boundaries_pos_x[i] is used to calculate the value of VirtualBoundariesPosX[i], which specifies the position of the i-th vertical virtual boundary in luminance samples. The value of sps_virtual_boundaries_pos_x[i] should be in the range of 1 to Ceil(pic_width_in_luma_samples÷8)-1 (inclusive).

[0326] sps_num_hor_virtual_boundaries specifies the number of sps_virtual_boundaries_pos_y[i] syntax elements that exist in SPS. When sps_num_hor_virtual_boundaries does not exist, it is inferred to be equal to 0.

[0327] sps_virtual_boundaries_pos_y[i] is used to calculate the value of VirtualBoundariesPosY[i], which specifies the position of the i-th horizontal virtual boundary in luminance samples. The value of sps_virtual_boundaries_pos_y[i] should be in the range of 1 to Ceil(pic_height_in_luma_samples÷8)-1 (inclusive).

[0328] A value of 1 for `sps_general_hrd_params_present_flag` indicates that the syntax structure `general_hrd_parameters()` exists within the SPS RBSP syntax structure. A value of 0 for `sps_general_hrd_params_present_flag` indicates that the syntax structure `general_hrd_parameters()` does not exist within the SPS RBSP syntax structure.

[0329] A value of 1 for `sps_sublayer_cpb_params_present_flag` indicates that the syntax structure `old_hrd_parameters()` in the SPS RBSP includes HRD parameters for the sublayer representation with a TemporalId in the range of 0 to `sps_max_sublayers_minus1` (inclusive). A value of 0 for `sps_sublayer_cpb_params_present_flag` indicates that the syntax structure `ols_hrd_parameters()` in the SPS RBSP includes HRD parameters for the sublayer representation with a TemporalId equal to only `sps_max_sublayers_minus1`. When `sps_max_sublayers_minus1` is equal to 0, the value of `sps_sublayer_cpb_params_present_flag` is inferred to be 0.

[0330] When `sps_sublayer_cpb_params_present_flag` equals 0, the HRD parameters of a sublayer representation with a TemporalId in the range of 0 to `sps_max_sublayers_minus1-1` (inclusive) are inferred to be the same as the HRD parameters of a sublayer representation with a TemporalId equal to `sps_max_sublayers_minus1`. These parameters include the HRD parameters from the `fixed_pic_rate_general_flag[i]` syntax element up to the `sublayer_hrd_parameters(i)` syntax structure under the condition "if(general_vcl_hrd_params_present_flag)" immediately following the `ols_hrd_parameters` syntax structure.

[0331] A field_seq_flag value of 1 indicates that CLVS transmits an image representing a field. A field_seq_flag value of 0 indicates that CLVS transmits an image representing a frame. When general_frame_only_constraint_flag is 1, the value of field_seq_flag should be 0.

[0332] When field_seq_flag equals 1, a Frame Field Information (SEI) message should exist for each encoded image in CLVS.

[0333] Note—The decoding process does not treat the images representing fields or frames differently. Therefore, the sequence of images representing fields will be encoded using the image size of a single field. For example, an image representing a 1080i field typically has a cropped output size of 1920×540, and the sequence image rate typically indicates the frequency of the source field (usually between 50Hz and 60Hz), rather than the source frame frequency (usually between 25Hz and 30Hz).

[0334] A value of 1 for `vui_parameters_present_flag` indicates that the syntax structure `vui_parameters()` exists within the SPS RBSP syntax structure. A value of 0 for `vui_parameters_present_flag` indicates that the syntax structure `vui_parameters()` does not exist within the SPS RBSP syntax structure.

[0335] A value of 0 for sps_extension_flag indicates that the sps_extension_data_flag syntax structure does not exist in the SPS RBSP syntax structure. A value of 1 for sps_extension_flag indicates that the sps_extension_data_flag syntax structure exists in the SPS RBSP syntax structure.

[0336] The `sps_extension_data_flag` flag can have any value. Its presence and value do not affect the decoder conforming to the configuration file specified in this version of the specification. Decoders conforming to this version of the specification should ignore all `sps_extension_data_flag` syntax elements.

[0337] As shown in Table 2, NAL units can include sequence parameter set syntax structures. Table 5 shows the syntax structure of PPS provided in JVET-P2001.

[0338]

[0339]

[0340]

[0341]

[0342] Table 5

[0343] Regarding Table 5, JVET-P2001 provides the following semantics:

[0344] The PPS RBSP should be available for the decoding process before being referenced, and should be included in at least one AU of the TemporalId which is less than or equal to the PPSNAL unit, or provided by external means.

[0345] All PPS NAL cells within the PU that have a specific value of pps_pic_parameter_set_id should have the same content.

[0346] The `pps_pic_parameter_set_id` identifier is used by other syntax elements for reference. The value of `pps_pic_parameter_set_id` should be in the range of 0 to 63 (inclusive).

[0347] Regardless of the nuh_layer_id value, PPS NAL cells share the same value space of pps_pic_parameter_set_id.

[0348] `pps_seq_parameter_set_id` specifies the value of `sps_seq_parameter_set_id` for the SPS. The value of `pps_seq_parameter_set_id` should be in the range of 0 to 15 (inclusive). The value of `pps_seq_parameter_set_id` should be the same across all PPSs referenced by encoded images in CLVS.

[0349] `pic_width_in_luma_samples` specifies the width of each decoded image referenced by PPS, in luminance samples. `pic_width_in_luma_samples` should not be equal to 0, should be an integer multiple of `Max(8, MinCbSizeY)`, and should be less than or equal to `pic_width_max_in_luma_samples`.

[0350] When subpics_present_flag equals 1 or ref_pic_resampling_enabled_flag equals 0, the value of pic_width_in_luma_samples should be equal to pic_width_max_in_luma_samples.

[0351] `pic_height_in_luma_samples` specifies the height of each decoded image referenced by the PPS, in luminance samples. `pic_height_in_luma_samples` should not be equal to 0 and should be an integer multiple of `Max(8,MinCbSizeY)`, and should be greater than or equal to `pic_height_max_in_luma_samples`.

[0352] When subpics_present_flag equals 1 or ref_pic_resampling_enabled_flag equals 0, the value of pic_height_in_luma_samples should be equal to pic_height_max_in_luma_samples.

[0353] Let refPicWidthInLumaSamples and refPicHeightInLumaSamples be the pic_width_in_luma_samples and pic_height_in_luma_samples of the reference images that reference the current image of this PPS, respectively. The bitstream compliance requirement must satisfy all of the following conditions:

[0354] -pic_width_in_luma_samples*2 should be greater than or equal to refPicWidthInLumaSamples.

[0355] -pic_height_in_luma_samples*2 should be greater than or equal to refPicHeightInLumaSamples.

[0356] -pic_width_in_luma_samples should be greater than or equal to refPicWidthInLumaSamples*8.

[0357] -pic_height_in_luma_samples should be greater than or equal to refPicHeightInLumaSamples*8.

[0358] The variables PicWidthInCtbsY, PicHeightInCtbsY, PicSizeInCtbsY, PicWidthInMinCbsY, PicHeightInMinCbsY, PicSizeInMinCbsY, PicSizeInSamplesY, PicWidthInSamplesC, and PicHeightInSamplesC are derived as follows:

[0359] PicWidthInCtbsY=Ceil(pic_width_in_luma_samples÷CtbSizeY)

[0360] PicHeightInCtbsY=Ceil(pic_height_in_luma_samples÷CtbSizeY)

[0361] PicSizeInCtbsY=PicWidthInCtbsY*PicHeightInCtbsY

[0362] PicWidthInMinCbsY=pic_width_in_luma_samples / MinCbSizeY

[0363] PicHeightInMinCbsY=pic_hcight_in_luma_samples / MinCbSizeY

[0364] PicSizeInMinCbsY=PicWidthInMinCbsY*PicHeightInMinCbsY

[0365] PicSizeInSamplesY=pic_width_in_luma_samples*pic_height_in_luma_samples

[0366] PicWidthInSamplesC=pic_width_in_luma_samples / SubWidthC

[0367] PicHeightInSamplesC=pic_height_in_luma_samples / SubHeightC

[0368] A conformance_window_flag value of 1 indicates that the conformance clipping window offset parameter is immediately following the window in PPS. A conformance_window_flag value of 0 indicates that the conformance clipping window offset parameter is not present.

[0369] `conf_win_left_offset`, `conf_wm_right_offset`, `conf_wm_top_offset`, and `conf_win_bottom_offset` specify the sample of the image output from the decoding process in CLVS, based on the rectangular region specified in the coordinates of the image to be output. When `conformance_window_flag` equals 0, it is inferred that the values ​​of `conf_win_left_offset`, `conf_win_right_offset`, `conf_win_top_offset`, and `conf_win_bottom_offset` are equal to 0.

[0370] The snap-fit ​​cropping window contains brightness samples with horizontal image coordinates from SubWidthC*conf_win_left_offset to pic_width_in_luma_samples-(SubWidthC*conf_win_right_offset+1) and vertical image coordinates from SubHeightC*conf_win_top_offset to pic_height_in_luma_samples-(SubHeightC*conf_win_bottom_offset+1) (inclusive of end values).

[0371] The value of SubWidthC*(conf_winjeft_offset+conf win_right_offset) should be less than pic_width_in_luma_samples, and the value of SubHeightC*(conf_win_top_offset+conf_win_bottom_offset) should be less than pic_height_in_luma_samples.

[0372] When ChromaArrayType is not equal to 0, the corresponding specified sample of the two chroma matrices is a sample with image coordinates (x / SubWidthC, y / SubHeightC), where (x, y) are the image coordinates of the specified luminance sample.

[0373] Note—The fit-to-crop-window offset parameter is only applied during output. All internal decoding processes are applied to the uncropped image size.

[0374] Let ppsA and ppsB be any two PPSs referencing the same SPS. For bitstream compliance, when ppsA and ppsB have the same values ​​for pic_width_in_luma_samples and pic_height_in_luma_samples respectively, ppsA and ppsB should also have the same values ​​for conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset respectively.

[0375] A scaling_window_flag value of 1 indicates that a scaling window offset parameter exists in PPS. A scaling_window_flag value of 0 indicates that a scaling window offset parameter does not exist in PPS. When ref_pic_resampling_enabled_flag is equal to 0, the value of scaling_window_flag should be equal to 0.

[0376] `scaling_win_left_offset`, `scaling_win_right_offset`, `scaling_win_top_offset`, and `scaling_win_bottom_offset` specify the offsets applied to the image size for scaling calculations, in units of brightness samples. When `scaling_window_flag` equals 0, it is inferred that the values ​​of `scaling_win_left_offset`, `scaling_win_right_offset`, `scaling_win_top_offset`, and `scaling_win_bottom_offset` are equal to 0.

[0377] The values ​​of scaling_win_left_offset + scaling_win_right_offset should be less than pic_width_in_luma_samples, and the values ​​of scaling_win_top_offset + scaling_win_bottom_offset should be less than pic_height_in_luma_samples.

[0378] The variables PicOutputWidthL and PicOutputHeightL are derived as follows:

[0379] PicOutputWidthL=pic_width_in_luma_samples-(scaling_win_right_offset+scaling_win_left_offset)

[0380] PicOutputHeightL=pic_height_in_luma_samples-(scaling_win_bottom_offset+scaling_win_top_offset)

[0381] A value of 1 for `output_flag_present_flag` indicates that the `pic_output_flag` syntax element exists in the slice header referencing PPS. A value of 0 for `output_flag_present_flag` indicates that the `pic_output_flag` syntax element does not exist in the slice header referencing PPS.

[0382] A mixed_nalu_types_in_pic_flag value of 1 indicates that each picture referencing PPS has more than one VCLNAL unit, and the VCL NAL units do not have the same nal_unit_type value, and the picture is not an IRAP picture. A mixed_nalu_types_in_pic_flag value of 0 indicates that each picture referencing PPS has one or more VCL NAL units, and the VCL NAL units of each picture referencing PPS have the same nal_unit_type value.

[0383] When no_mixed_nalu_types_in_pic_constraint_flag equals 1, the value of mixed_nalu_types_in_pic_flag should be equal to 0.

[0384] For each slice with a nal_unit_type value nalUnitTypeA from IDR_W_RADL to CRA_NUT (inclusive), in a picture picA that also contains one or more slices with another nal_unit_type value (i.e., the value of mixed_nalu_types_in_pic_flag of picture picA is equal to 1), the following applies:

[0385] - The slice should belong to the subpic A, and the corresponding subpic_treated_as_pic_flag[i] value is equal to 1.

[0386] - The slice should not belong to a sub-picture picA that contains a VCL NAL unit with a nal_unit_type that is not equal to nalUnitTypeA.

[0387] - For all the following PUs in CLVS arranged in decoding order, neither RefPicList[0] nor RefPicList[1] of the slices in subpicA should include any pictures preceding the picA arranged in decoding order in the active entry.

[0388] `pps_subpic_id_signalling_present_flag` equal to 1 specifies that a signal should be sent in PPS to notify the subpicture ID mapping. `pps_subpic_id_signalling_present_flag` equal to 0 specifies that a signal should not be sent in PPS to notify the subpicture ID mapping. When `sps_subpic_id_present_flag` is 0 or `sps_subpic_id_signalling_present_flag` is 1, `pps_subpic_id_signalling_present_flag` should be equal to 0.

[0389] The increment 1 in pps_num_subpics_minus1 specifies the number of subpicks in the encoded image that references PPS.

[0390] The bitstream compliance requirement is that the value of pps_num_subpic_minus1 should be equal to that of sps_num_subpics_minus1.

[0391] The increment of 1 in pps_subpic_id_len_minus1 specifies the number of bits used to represent the syntax element pps_subpic_id[i]. The value of pps_subpic_id_len_minus1 should be in the range of 0 to 15 (inclusive).

[0392] For bitstream compliance requirements, the value of pps_subpic_id_len_minus1 should be the same for all PPS referenced by encoded pictures within CLVS.

[0393] pps_subpic_id[i] specifies the subpick ID of the i-th subpick. The length of the pps_subpic_id[i] syntax element is pps_subpic_id_len_minus1+1 bits.

[0394] `no_pic_partition_flag` equal to 1 specifies that image partitioning should not be applied to each image referencing PPS. `no_pic_partition_flag` equal to 0 specifies that each image referencing PPS can be divided into more than one tile or slice.

[0395] For bitstream compliance requirements, the value of no_pic_partition_flag should be the same for all PPSs referenced by encoded images within CLVS.

[0396] When the value of sps_num_subpics_minus1+1 is greater than 1, the value of the bitstream compliance requirement no_pic_partition_flag should not be equal to 1.

[0397] Adding 5 to pps_log2_ctu_size_minus5 specifies the luminance coding tree block size for each CTU. pps_log2_ctu_size_minus5 should be equal to sps_log2_ctu_size_minus5.

[0398] Increasing 1 to `num_exp_tile_columns_minus1` specifies the number of explicitly provided tile column widths. The value of `num_exp_tile_columns_minus1` should be in the range of 0 to `PicWidthInCtbsY-1` (inclusive). When `no_pic_partition_flag` equals 1, it is inferred that the value of `num_exp_tile_columns_minus1` is equal to 0.

[0399] Increasing 1 to num_exp_tile_rows_minus1 specifies the number of explicitly provided tile row heights. The value of num_exp_tile_rows_minus1 should be in the range of 0 to PicHeightInCtbsY-1 (inclusive). When no_pic_partition_flag equals 1, the value of num_tile_rows_minus1 is inferred to be 0.

[0400] `tile_column_width_minus1[i]` incremented by 1 specifies the width of the i-th tile column in CTB, where i is in the range of 0 to `num_exp_tile_columns_minus1-1` (inclusive). `tile_column_width_minus1[num_exp_tile_columns_minus1]` is used to derive the width of tile columns whose index is greater than or equal to the specified `num_exp_tile_columns_minus1`. If it does not exist, the value of `tile_column_width_minus1[0]` is inferred to be equal to `PicWidthInCtbsY-1`.

[0401] `tile_row_height_minus1[i]` incremented by 1 specifies the height of the i-th tile row in CTB, where i is in the range of 0 to `num_exp_tile_rows_minus1-1` (inclusive). `tile_row_height_minus1[num_exp_tile_rows_minus1]` is used to derive the height of tile rows whose index is greater than or equal to the specified `num_exp_tile_rows_minus1`. If it does not exist, the value of `tile_row_height_minus1[0]` is inferred to be equal to `PicHeightInCtbsY-1`.

[0402] A `rect_slice_flag` value of 0 indicates that the tiles within each slice are in the raster scan order and no slice information is signaled in the PPS. A `rect_slice_flag` value of 1 indicates that the tiles within each slice cover a rectangular area of ​​the image and a slice information is signaled in the PPS. If it does not exist, `rect_slice_flag` is presumed to be 1. When `subpics_present_flag` is 1, the value of `rect_slice_flag` should be 1.

[0403] `single_slice_per_subpic_flag` equal to 1 indicates that each subpick consists of one and only one rectangular slice. `single_slice_per_subpic_flag` equal to 0 indicates that each subpick can consist of one or more rectangular slices. When `subpics_present_flag` equals 0, `single_slice_per_subpic_flag` should also equal 0. When `single_slice_per_subpic_flag` equals 1, it is inferred that `num_slices_in_pic_minus1` equals `sps_num_subpics_minus1`.

[0404] `num_slices_in_pic_minus1` incremented by 1 specifies the number of rectangular slices in each picture referenced by PPS. The value of `num_slices_in_pic_minus1` should be in the range of 0 to `MaxSlicesPerPicture - 1` (inclusive), where `MaxSlicesPerPicture` is specified. When `no_pic_partition_flag` equals 1, it is inferred that the value of `num_slices_in_pic_minus1` is equal to 0.

[0405] A tile_idx_delta_present_flag value of 0 indicates that a tile_idx_delta value does not exist in the PPS, and all rectangular tiles in images referencing the PPS are specified to be arranged in raster order according to the procedure defined below. A tile_idx_delta_present_flag value of 1 indicates that a tile_idx_delta value may exist in the PPS, and all rectangular tiles in images referencing the PPS are specified to be arranged in the order indicated by the tile_idx_delta value.

[0406] `slice_width_in_tiles_minus1[i]` incremented by 1 specifies the width of the i-th rectangular slice, in tile columns. The value of `slice_width_in_tiles_minus1[i]` should be in the range of 0 to `NumTileColumns-1` (inclusive). If it does not exist, the value of `slice_width_in_tiles_minus1[i]` is inferred as follows.

[0407] `slice_height_in_tiles_minus1[i]` incremented by 1 specifies the height of the i-th rectangular slice, in tile rows. The value of `slice_height_in_tiles_minus1[i]` should be in the range of 0 to NumTileRows-1 (inclusive). If it does not exist, the value of `slice_height_in_tiles_minus1[i]` is inferred as follows.

[0408] `num_slices_in_tile_minus1[i]` incremented by 1 specifies the number of slices in the current tile if the i-th slice contains a subset of CTU rows from a single tile. The value of `num_slices_in_tile_minus1[i]` should be in the range of 0 to `RowHeight[tileY] - 1` (inclusive), where `tileY` is the tile row index containing the i-th slice. If it does not exist, the value of `num_slices_in_tile_minus1[i]` is inferred to be 0.

[0409] The increment of 1 in slice_height_in_ctu_minus1[i] specifies the height of the i-th rectangular slice, in CTU rows, if the i-th slice contains a subset of CTU rows from a single tile. The value of slice_height_in_ctu_minus1[i] should be in the range of 0 to RowHeight[tileY]-1 (inclusive), where tileY is the tile row index containing the i-th slice.

[0410] `tile_idx_delta[i]` specifies the tile index difference between the i-th rectangular tile and the (i+1)-th rectangular tile. The value of `tile_idx_delta[i]` should be in the range of -NumTilesInPic+1 to NumTilesInPic-1 (inclusive). If it does not exist, the value of `tile_idx_delta[i]` is presumed to be 0. In all other cases, the value of `tile_idx_delta[i]` should not be equal to 0.

[0411] A `loop_filter_across_tiles_enabled_flag` value of 1 indicates that loop filtering can be performed across tile boundaries in images referencing PPS. A `loop_filter_across_tiles_enabled_flag` value of 0 indicates that loop filtering cannot be performed across tile boundaries in images referencing PPS. Loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filter operations. When not present, the inferred value of `loop_filter_across_tiles_enabled_flag` is 1.

[0412] A `loop_filter_across_slices_enabled_flag` value of 1 specifies that loop filtering can be performed across slice boundaries in an image that spans the reference PPS. A `loop_filter_across_slice_enabled_flag` value of 0 specifies that loop filtering can be performed across slice boundaries in an image that does not span the reference PPS. Loop filtering operations include unblocking filters, sample adaptive offset filters, and adaptive loop filter operations. When not present, the value of `loop_filter_across_slices_enabled_flag` is inferred to be 0.

[0413] `entropy_coding_sync_enabled_flag` equal to 1 specifies that a specific synchronization procedure of the context variable is called before the CTU of the first CTB in the CTB row of each tile in each picture including the referenced PPS is decoded, and a specific stored procedure of the context variable is called after the CTU of the first CTB in the CTB row of each tile in each picture including the referenced PPS is decoded. `entropy_coding_sync_enabled_flag` equal to 0 specifies that the specific synchronization procedure of the context variable does not need to be called before the CTU of the first CTB in the CTB row of each tile in each picture including the referenced PPS is decoded, and a specific stored procedure of the context variable does not need to be called after the CTU of the first CTB in the CTB row of each tile in each picture including the referenced PPS is decoded.

[0414] For bitstream compliance requirements, the value of `entropy_coding_sync_enabled_flag` should be the same for all PPS referenced by encoded images within CLVS.

[0415] When entry_point_offsets_present_flag equals 1, the variable NumEntryPoints, which specifies the number of entry points in the current slice, is exported as follows:

[0416]

[0417] A cabac_init_present_flag value of 1 indicates that the cabac_init_flag exists in the slice header referencing PPS. A cabac_init_present_flag value of 0 indicates that the cabac_init_flag does not exist in the slice header referencing PPS.

[0418] Increment 1 by num_ref_idx_default_active_minus1[i]. When i equals 0, specify the inferred value of the variable NumRefIdxActive[0] for slice P or slice B, where num_ref_idx_active_override_flag equals 0. When i equals 1, specify the inferred value of NumRefIdxActive[1] for slice B, where num_ref_idx_active_override_flag equals 0. The value of num_ref_idx_default_active_minus1[i] should be in the range of 0 to 14 (inclusive).

[0419] A value of 0 for rpl1_idx_present_flag indicates that ref_pic_list_sps_flag[1] and ref_pic_list_idx[1] do not exist in the slice header. A value of 1 for rpl1_idx_present_flag indicates that ref_pic_list_sps_flag[1] and ref_pic_list_idx[1] may exist in the slice header.

[0420] `init_qp_minus26` plus 26 specifies that each slice of PPS is referenced by `SliceQp`. Y The initial value. When slice_qp_delta is decoded to a non-zero value, modify SliceQp at the slice layer. Y The initial value of init_qp_minus26 should be in the range of -(26+QpBdOffset) to +37 (inclusive).

[0421] log2_transform_skip_max_size_minus2 specifies the maximum block size to be skipped during transformation and should be in the range of 0 to 3 (inclusive).

[0422] The variable MaxTsSize is set to equal to 1 << (log2_transform_skip_max_size_minus2+2).

[0423] A value of 1 for `cu_qp_delta_enabled_flag` indicates that the referenced PPS PH contains the syntax elements `pic_cu_qp_delta_subdiv_intra_slice` and `pic_cu_qp_delta_subdiv_inter_slice`, and that `cu_qp_delta_abs` may exist in the transformation unit syntax. A value of 0 for `cu_qp_delta_enabled_flag` indicates that the referenced PPS PH does not contain the syntax elements `pic_cu_qp_delta_subdiv_intra_slice` and `pic_cu_qp_delta_subdiv_inter_slice`, and that `cu_qp_delta_abs` does not exist in the transformation unit syntax.

[0424] pps_cb_qp_offset and pps_cr_qp_offset specify the values ​​used for exporting Qp. Cb and Qp' Cr Brightness quantization parameter Qp' Y The offset. The values ​​of pps_cb_qp_offset and pps_cr_qp_offset should be in the range of -12 to +12 (inclusive). When ChromaArrayType equals 0, pps_cb_qp_offset and pps_cr_qp_offset are not used during decoding, and the decoder should ignore their values.

[0425] A value of 1 for `pps_joint_cbcr_qp_offset_present_flag` indicates that `pps_joint_cbcr_qp_offset_value` and `joint_cbcr_qp_offset_list[i]` exist in the PPS RBSP syntax structure. A value of 0 for `pps_joint_cbcr_qp_offset_present_flag` indicates that `pps_joint_cbcr_qp_offset_value` and `joint_cbcr_qp_offset_list[i]` do not exist in the PPS RBSP syntax structure. When `ChromaArrayType` is equal to 0 or `sps_joint_cbcr_enabled_flag` is equal to 0, the value of `pps_joint_cbcr_qp_offset_present_flag` should be equal to 0.

[0426] pps_joint_cbcr_qp_offset_value specifies the value used for exporting Qp. CbCr Brightness quantization parameter Qp' Y The offset. The value of pps_joint_cbcr_qp_offset_value should be in the range of -12 to +12 (inclusive). When ChromaArrayType equals 0 or sps_joint_cbcr_enabled_flag equals 0, pps_joint_cbcr_qp_offset_value is not used during decoding, and the decoder should ignore its value. When pps_joint_cbcr_qp_offset_present_flag equals 0, pps_joint_cbcr_qp_offset_value does not exist and is inferred to be equal to 0.

[0427] A value of 1 for `pps_slice_chroma_qp_offsets_present_flag` indicates the presence of the `slice_cb_qp_offset` and `slice_cr_qp_offset` syntax elements in the associated slice header. A value of 0 for `pps_slice_chroma_qp_offsets_present_flag` indicates the absence of these syntax elements in the associated slice header. When `ChromaArrayType` is 0, `pps_slice_chroma_qp_offsets_present_flag` should be 0.

[0428] A value of 1 for `pps_cu_chroma_qp_offeet_list_enabled_flag` indicates that the referenced PPS PH contains the syntax elements `pic_cu_chroma_qp_offset_subdiv_intra_slice` and `pic_cu_chroma_qp_offset_subdiv_inter_slice`, and that `cu_chroma_qp_offset_flag` may also be present in the transform unit syntax and palette encoding syntax. A value of 0 for `pps_cu_chroma_qp_offset_list_enabled_flag` indicates that the referenced PPS PH does not contain the syntax elements `pic_cu_chroma_qp_offset_subdiv_intra_slice` and `pic_cu_chroma_qp_offset_subdiv_inter_slice`, and that `cu_chroma_qp_offset_flag` is not present in the transform unit syntax and palette encoding syntax. When ChromaArrayType equals 0, the bitstream compliance requirement pps_cu_chroma_qp_offset_list_enabled_flag should have a value of 0.

[0429] The increment of 1 in `chroma_qp_offset_list_len_minus1` specifies the number of `cb_qp_offset_list[i]`, `cr_qp_offset_list[i]`, and `joint_cbcr_qp_offset_list[i]` syntax elements present in the PPS RBSP syntax structure. The value of `chroma_qp_offset_list_len_minus1` should be in the range of 0 to 5 (inclusive).

[0430] cb_qp_offset_list[i], cr_qp_offset_list[i], and joint_cbcr_qp_offset_list[i] specify the offsets in Qp', respectively. Cb Qp' Cr and Qp' CbCrThe offsets used in the derivation. The values ​​of cb_qp_offset_list[i], cr_qp_offset_list[i], and joint_cbcr_qp_offset_list[i] should be in the range of -12 to +12 (inclusive). When pps_joint_cbcr_qp_offset_present_flag equals 0, joint_cbcr_qp_offset_list[i] does not exist and is inferred to be equal to 0.

[0431] A value of 0 for pps_weighted_pred_flag indicates that weighted predictions are not applied to P-slices that reference PPS. A value of 1 for pps_weighted_pred_flag indicates that weighted predictions are applied to P-slices that reference PPS. When pps_weighted_pred_flag is 0, the value of pps_weighted_pred_flag should be 0.

[0432] A value of 0 for `pps_weighted_bipred_flag` specifies that explicit weighted predictions should not be applied to B-slices referencing PPS. A value of 1 for `pps_weighted_bipred_flag` specifies that explicit weighted predictions should be applied to B-slices referencing PPS. When `sps_weighted_bipred_flag` is 0, the value of `pps_weighted_bipred_flag` should also be 0.

[0433] A deblocking filter control present flag of 1 indicates that the deblocking filter control syntax element exists in the PPS. A deblocking filter control present flag of 0 indicates that the deblocking filter control syntax element does not exist in the PPS.

[0434] A `deblocking_filter_override_enabled_flag` value of 1 indicates that either `pic_deblocking_filter_override_flag` exists in the PH referencing PPS, or `slice_deblocking_filter_override_flag` exists in the slice header referencing PPS. A `deblocking_filter_override_enabled_flag` value of 0 indicates that either `pic_deblocking_filter_override_flag` does not exist in the PH referencing PPS, or `slice_deblocking_filter_override_flag` does not exist in the slice header referencing PPS. If neither exists, it is assumed that the value of `deblocking_filter_override_enabled_flag` is 0.

[0435] A value of 1 for `pps_deblocking_filter_disabled_flag` specifies that the deblocking filter operation should not be applied to slices of PPS where `slice_deblocking_filter_disabled_flag` is not present. A value of 0 for `pps_deblocking_filter_disabled_flag` specifies that the deblocking filter operation should be applied to slices of PPS where `slice_deblocking_filter_disabled_flag` is not present. When it is not present, the value of `pps_deblocking_filter_disabled_flag` is assumed to be 0.

[0436] `pps_beta_offset_div2` and `pps_tc_offset_div2` specify the default unblocking parameter offsets (divided by 2) applied to slices referencing PPS, unless the default unblocking parameter offsets are overridden by unblocking parameter offsets present in the slice header of the slice referencing PPS. The values ​​of `pps_beta_offset_div2` and `pps_tc_offset_div2` should both be in the range of -6 to 6 (inclusive). If they do not exist, the values ​​of `pps_beta_offset_div2` and `pps_tc_offset_div2` are presumed to be 0.

[0437] A constant_slice_header_params_enabled_flag equal to 0 indicates that pps_dep_quant_enabled_idc, pps_ref_pic_list_sps_idc[i], pps_mvd_l1_zero_idc, pps_collocatcd_from_l0_idc, pps_six_minus_max_num_merge_cand_plus1, and pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 are all equal to 0. A constant_slice_header_params_enabled_flag equal to 1 indicates that these syntax elements exist in PPS.

[0438] A value of 0 for pps_dep_quant_enabled_idc indicates that the syntax element pic_dep_quant_enabled_flag exists in the PH referencing PPS. A value of 1 or 2 for pps_dep_quant_enabled_idc indicates that the syntax element pic_dep_quant_enabled_flag does not exist in the PH referencing PPS. A value of 3 for pps_dep_quant_enabled_idc is reserved for future use by ITU-T|ISO / IEC.

[0439] A value of 0 for pps_ref_pic_list_sps_idc[i] indicates that the syntax element pic_rpl_sps_flag[i] exists in the PH referencing the PPS, or that slice_rpl_sps_flag[i] exists in the slice header referencing the PPS. A value of 1 or 2 for pps_ref_pic_list_sps_idc[i] indicates that the syntax element pic_rpl_sps_flag[i] does not exist in the PH referencing the PPS, and slice_rpl_sps_flag[i] does not exist in the slice header referencing the PPS. A value of 3 for pps_ref_pic_list_sps_idc[i] is reserved for future use by ITU-T|ISO / IEC.

[0440] A value of 0 for pps_mvd_l1_zero_idc indicates that the PH referencing PPS contains the syntax element mvd_l1_zero_flag. A value of 1 or 2 for pps_mvd_l1_zero_idc indicates that the PH referencing PPS does not contain mvd_l1_zero_flag. A value of 3 for pps_mvd_l1_zero_idc is reserved for future use by ITU-T|ISO / IEC.

[0441] A value of 0 for pps_collocated_from_l0_idc indicates that the slice header referencing a PPS slice contains the syntax element collocated_from_l0_flag. A value of 1 or 2 for pps_collocated_from_l0_idc indicates that the slice header referencing a PPS slice does not contain the syntax element collocated_from_l0_flag. A value of 3 for pps_collocated_from_l0_idc is reserved for future use by ITU-T|ISO / IEC.

[0442] A value of 0 for pps_six_minus_max_num_merge_cand_plus1 indicates that pic_six_minus_max_num_merge_cand exists in the referenced PPS PH. A value greater than 0 indicates that pic_six_minus_max_num_merge_cand does not exist in the referenced PPS PH. The value of pps_six_minus_max_num_merge_cand_plus1 should be in the range of 0 to 6 (inclusive).

[0443] A value of 0 for pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 indicates that pic_max_num_merge_cand_minus_max_num_triangle_cand exists in the pH of the slice referencing PPS. A value greater than 0 indicates that pic_max_num_merge_cand_minus_max_num_triangle_cand does not exist in the pH of the slice referencing PPS. The value of pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1 should be in the range of 0 to MaxNumMergeCand-1 (inclusive).

[0444] A picture_header_extension_present_flag value of 0 indicates that the PH extension syntax element does not exist in the PH referencing the PPS. A picture_header_extension_present_flag value of 1 indicates that the PH extension syntax element exists in the PH referencing the PPS. In bitstreams conforming to this version of the specification, picture_header_extension_present_flag should be equal to 0.

[0445] A slice_header_extension_present_flag value of 0 indicates that the slice header extension syntax element does not exist in the slice header of the encoded image referencing PPS. A slice_header_extension_present_flag value of 1 indicates that the slice header extension syntax element exists in the slice header of the encoded image referencing PPS. In bitstreams conforming to this version of the specification, slice_header_extension_present_flag should be equal to 0.

[0446] A value of 0 for pps_extension_flag indicates that the pps_extension_data_flag syntax element does not exist in the PPS RBSP syntax structure. A value of 1 for pps_extension_flag indicates that the pps_extension_data_flag syntax element exists in the PPS RBSP syntax structure.

[0447] The `pps_extension_data_flag` flag can have any value. Its presence and value do not affect the decoder's configuration file as specified in this version of the specification. Decoders conforming to this version of the specification should ignore all `pps_extension_data_flag` syntax elements.

[0448] As mentioned above, in JVET-P2001, the SPS includes the syntax element `ref_pic_resampling_enabled_flag`, which specifies whether reference picture resampling can be applied, and the syntax elements `pic_width_max_in_luma_samples` and `pic_height_max_in_luma_samples`, which specify the maximum width and maximum height of each decoded picture referencing the SPS, respectively. Furthermore, in JVET-P2001, the PPS includes the syntax elements `pic_width_in_luma_samples` and `pic_height_in_luma_samples`, which specify the width and height of each decoded picture referencing the PPS, respectively. Therefore, in JVET-P2001, since the decoded pictures in the SPS can refer to different PPSs, the output resolution of the decoded pictures within the CVS can be changed. That is, JVET-P2001 supports so-called reference picture resampling (RPS).

[0449] It should be noted that ITU-T H.264 and ITU-T H.265 allow for changing the output resolution of the decoded image at the start of a new CVS using an IDR image that refreshes the DPB (or, in some cases, another type of IRAP image that refreshes the DPB when starting a new CVS). In JVET-P2001, the output resolution of the decoded image can be changed at any image in the CVS, and multiple images of different resolutions can coexist in the DPB simultaneously. Furthermore, it should be noted that, generally, the output image will still be intended to be displayed at the same resolution, regardless of the simultaneous presence of multiple images of different resolutions in the DPB. Moreover, the output resolution does not need to be the same as the source resolution; for example, a 1080p video might be decoded and displayed on a 4K screen.

[0450] It is expected that video rendering devices will support (at the IDR image) resolution conversion from one resolution to another in existing video coding standards. However, some receivers and players struggle to support resolution conversion without introducing visual artifacts. For example, a small number of black frames may be inserted during conversion, or frames with incorrect scaling or aspect ratios may appear during conversion.

[0451] It should be noted that, regarding resolution conversion, ITU-T H.264 only provides the following:

[0452] When the IDR image is not the first IDR image to be decoded and the values ​​of PicWidthInMbs, FrameHeightInMbs, or max_dec_frame_buffering derived from the active sequence parameter set are different from the values ​​of PicWidthInMbs, FrameHeightInMbs, or max_dec_frame_buffering derived from the sequence parameter set active for the previous image, no_output_of_prior_pics_flag is inferred to be equal to 1 through HRD, regardless of the actual value of no_output_of_prior_pics_flag.

[0453] Note—The decoder implementation should attempt to handle changes to the values ​​of PicWidthInMbs, FrameHeightInMbs, or max_dec_frame_buffering more finely than the HRD.

[0454] Therefore, decoders compliant with ITU-T H.264 (and similarly, decoders compliant with ITU-T H.265) do not need to handle resolution switching meticulously. That is, in a way that, for example, does not introduce visual artifacts.

[0455] It should be noted that in many video applications and processing stages, video with active content at 1920×1080 is stored and processed at 1920×1088, while in other applications and processing stages, video is stored and processed at 1920×1080. Therefore, video coding standards should support both operating modes simultaneously, rather than assuming that only one mode is always used. Furthermore, to properly configure memory allocation, rescaling and cropping, and display areas, it is important for the video decoder to determine the expected display resolution (or switch resolution) when it begins decoding the bitstream (i.e., before decoding any VCLNAL unit of any picture in the bitstream). However, in JVET-P2001, since the output resolution of decoded pictures is in the PPS and can be changed between pictures, the video decoder can determine the expected display resolution for each picture referencing a PPS at most after decoding the corresponding PPS. It should be noted that in ITU-T H.265, the Video Availability Information (VUI) parameter vui_parameters() includes a default display window parameter syntax element, which identifies the area within the fit-and-clip window and is suggested to be displayed in the absence of any alternative indication of preferred display characteristics (provided within the bitstream or by an external means not specified in this specification). As described in further detail below, using the default display window parameter syntax element to indicate the default display window may not be ideal.

[0456] In one example, according to JVET-P2001, the bitstream can be encoded with SPS indicating that pic_width_max_in_luma_samples equals 1920 and pic_height_max_in_luma_samples equals 1088. A first PPS can indicate that the first images in the bitstream (e.g., Pic0 and Pic1) have pic_width_in_luma_samples equal to 1280 and pic_height_max_in_luma_samples equal to 720. The bitstream can also include a second PPS indicating the resolution of subsequent images (e.g., Pic2 and Pic3). Figure 4A An example of a NAL cell stream corresponding to the bitstream in this example is shown. Figures 4B to 4C As shown, in this case, the video decoder cannot determine the expected display resolution of Pic2 and Pic3 before parsing the second PPS. That is, for example, even for... Figure 4B and Figure 4CIn the two examples, the pic_height_in_luma_samples in the second PPS is equal to 1088. Depending on whether a clipping window exists, the expected display resolution of Pic2 and Pic3 could be either 1920×1080 or 1920×1088. Therefore, the decoder cannot determine that bitstream A and bitstream B have different expected display resolutions before parsing the fit-the-window syntax elements in the second PPS. Figure 5 The time required for the decoder to determine the expected output resolution is also shown. That is, Figure 5 An example is provided where both a 1080-pixel image and a 1088-pixel image exist in the same CVS.

[0457] Therefore, in JVET-P2001, a signal is sent to indicate that the image resolution is not ideal. Specifically, according to JVET-P2001, a conforming bitstream can be generated in a manner that allows the video decoder to perform resolution conversion without introducing visual artifacts or minimizing them; this bitstream does not indicate the intended display resolution.

[0458] Figure 1 This is a block diagram illustrating an example of a system that can be configured to encode (e.g., encode and / or decode) video data according to one or more techniques of this disclosure. System 100 represents an example of a system that can encapsulate video data according to one or more techniques of this disclosure. Figure 1 As shown, system 100 includes source device 102, communication medium 110, and target device 120. Figure 1 In the example shown, source device 102 may include any device configured to encode video data and transmit the encoded video data to communication medium 110. Target device 120 may include any device configured to receive and decode the encoded video data via communication medium 110. Source device 102 and / or target device 120 may include computing devices equipped for wired and / or wireless communication, and may include, for example, set-top boxes, digital video recorders, televisions, desktop computers, laptops or tablets, game consoles, medical imaging equipment, and mobile devices (including, for example, smartphones, cellular phones, and personal gaming devices).

[0459] Communication medium 110 may include any combination of wireless and wired communication media and / or storage devices. Communication medium 110 may include coaxial cable, fiber optic cable, twisted-pair cable, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other device that can be used to facilitate communication between various devices and sites. Communication medium 110 may include one or more networks. For example, communication medium 110 may include a network configured to allow access to the World Wide Web, such as the Internet. The network may operate according to a combination of one or more telecommunications protocols. Telecommunication protocols may include proprietary aspects and / or may include standardized telecommunications protocols. Examples of standardized telecommunications protocols include the Digital Video Broadcasting (DVB) standard, the Advanced Television Systems Committee (ATSC) standard, the Integrated Services Digital Broadcasting (ISDB) standard, the Cable Data Services Interface Specification (DOCSIS) standard, the Global System for Mobile Communications (GSM) standard, the Code Division Multiple Access (CDMA) standard, the 3rd Generation Partnership Project (3GPP) standard, the European Telecommunications Standards Institute (ETSI) standard, the Internet Protocol (IP) standard, the Wireless Application Protocol (WAP) standard, and the Institute of Electrical and Electronics Engineers (IEEE) standard.

[0460] Storage devices can include any type of device or storage medium capable of storing data. Storage media can include tangible or non-transitory computer-readable media. Computer-readable media can include optical discs, flash memory, magnetic storage, or any other suitable digital storage medium. In some examples, a memory device or a portion thereof may be described as non-volatile memory, and in other examples, a portion of a memory device may be described as volatile memory. Examples of volatile memory can include random access memory (RAM), dynamic random access memory (DRAM), and static random access memory (SRAM). Examples of non-volatile memory can include magnetic hard disks, optical discs, floppy disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. Storage devices can include memory cards (e.g., secure digital (SD) memory cards), internal / external hard disk drives, and / or internal / external solid-state drives. Data can be stored on the storage device according to defined file formats.

[0461] Figure 6 This is a conceptual diagram illustrating examples of components that can be included in a specific implementation of system 100. Figure 6 In the exemplary embodiment shown, system 100 includes one or more computing devices 402A to 402N, a television service network 404, a television service provider site 406, a wide area network 408, a local area network 410, and one or more content provider sites 412A to 412N. Figure 6The specific implementation shown is an example of a system that can be configured to allow digital media content (such as movies, live sporting events, etc.) and its associated data and applications, as well as media presentation, to be distributed to and accessed by multiple computing devices (such as computing devices 402A to 402N). Figure 6 In the example shown, computing devices 402A to 402N may include any device configured to receive data from one or more of a television service network 404, a wide area network 408, and / or a local area network 410. For example, computing devices 402A to 402N may be equipped with wired and / or wireless communication capabilities and may be configured to receive services through one or more data channels, and may include televisions, including so-called smart TVs, set-top boxes, and digital video recorders. Furthermore, computing devices 402A to 402N may include desktop computers, laptop or tablet computers, game consoles, and mobile devices (including, for example, "smart" phones, cellular phones, and personal gaming devices).

[0462] Television service network 404 is an example of a network configured to enable the distribution of digital media content that may include television services. For example, television service network 404 may include a public over-the-air television network, a network of public or subscription-based satellite television service providers, and a network of public or subscription-based cable television service providers and / or cloud or internet service providers. It should be noted that while in some examples television service network 404 may primarily be used to allow the provision of television services, television service network 404 may also allow the provision of other types of data and services according to any combination of the telecommunications protocols described herein. Furthermore, it should be noted that in some examples, television service network 404 may allow bidirectional communication between television service provider site 406 and one or more of computing devices 402A to 402N. Television service network 404 may include any combination of wireless and / or wired communication media. Television service network 404 may include coaxial cable, fiber optic cable, twisted-pair cable, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that can be used to facilitate communication between various devices and sites. Television service network 404 may operate according to a combination of one or more telecommunications protocols. Telecommunications protocols may include proprietary aspects and / or may include standardized telecommunications protocols. Examples of standardized telecommunications protocols include the DVB standard, ATSC standard, ISDB standard, DTMB standard, DMB standard, Cable Data Service Interface Specification (DOCSIS) standard, HbbTV standard, W3C standard, and UPnP standard.

[0463] Refer again Figure 6Television service provider site 406 can be configured to distribute television services via television service network 404. For example, television service provider site 406 may include one or more broadcasting stations, cable television providers, satellite television providers, or internet-based television providers. For example, television service provider site 406 can be configured to receive transmissions (including television programs) via satellite uplink / downlink. Furthermore, as... Figure 6 As shown, television service provider site 406 can communicate with wide area network 408 and can be configured to receive data from content provider sites 412A to 412N. It should be noted that in some examples, television service provider site 406 may include a television studio, and content may originate from that television studio.

[0464] Wide area network 408 may include a packet-based network and operate according to a combination of one or more telecommunications protocols. The telecommunications protocols may include proprietary aspects and / or may include standardized telecommunications protocols. Examples of standardized telecommunications protocols include Global System for Mobile Communications (GSM) standards, Code Division Multiple Access (CDMA) standards, 3rd Generation Partnership Project (3GPP) standards, European Telecommunications Standards Institute (ETSI) standards, European Standards (EN) standards, IP standards, Wireless Application Protocol (WAP) standards, and Institute of Electrical and Electronics Engineers (IEEE) standards, such as one or more IEEE 802 standards (e.g., Wi-Fi). Wide area network 408 may include any combination of wireless and / or wired communication media. Wide area network 408 may include coaxial cable, fiber optic cable, twisted-pair cable, Ethernet cable, wireless transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that can be used to facilitate communication between various devices and sites. In one example, wide area network 408 may include the Internet. Local area network 410 may include a packet-based network and operate according to a combination of one or more telecommunications protocols. Local area network 410 can be distinguished from wide area network 408 based on access levels and / or physical infrastructure. For example, local area network 410 may include a secure home network.

[0465] Refer again Figure 6Content provider sites 412A to 412N represent examples of sites that can provide multimedia content to television service provider sites 406 and / or computing devices 402A to 402N. For example, a content provider site may include a studio with one or more studio content servers configured to provide multimedia files and / or streams to television service provider site 406. In one example, content provider sites 412A to 412N may be configured to provide multimedia content using an IP suite. For example, a content provider site may be configured to provide multimedia content to a receiver device according to Real-Time Streaming Protocol (RTSP), HTTP, etc. Furthermore, content provider sites 412A to 412N may be configured to provide data, including hypertext-based content, to receiver devices 402A to 402N and / or one or more television service provider sites 406 via a wide area network 408. Content provider sites 412A to 412N may include one or more web servers. The data provided by content provider sites 412A to 412N can be defined according to the data format.

[0466] Refer again Figure 1 Source device 102 includes a video source 104, a video encoder 106, a data encapsulator 107, and an interface 108. Video source 104 may include any device configured to capture and / or store video data. For example, video source 104 may include a camera and a storage device operatively coupled thereto. Video encoder 106 may include any device configured to receive video data and generate a compatible bitstream representing the video data. A compatible bitstream can refer to a bitstream from which a video decoder can receive and reproduce video data. Aspects of a compatible bitstream may be defined according to a video coding standard. When generating a compatible bitstream, video encoder 106 may compress the video data. Compression may be lossy (perceptible to an observer) or lossless. Figure 7 This is a block diagram illustrating an example of a video encoder 500 that can implement the techniques described herein for encoding video data. It should be noted that although the exemplary video encoder 500 is shown as having different functional blocks, such illustrations are intended for descriptive purposes and do not limit the video encoder 500 and / or its sub-components to a particular hardware or software architecture. The functionality of the video encoder 500 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0467] The video encoder 500 can perform intra-frame predictive coding and inter-frame predictive coding of image regions, and therefore can be called a hybrid video encoder. Figure 7In the example shown, video encoder 500 receives a source video block. In some examples, the source video block may include picture regions that have been partitioned according to the coding structure. For example, source video data may include macroblocks, CTUs, CBs, their sub-partitions, and / or another equivalent coding unit. In some examples, video encoder 500 may be configured to perform additional subdivision of the source video block. It should be noted that the techniques described herein are generally applicable to video coding, regardless of how the source video data is partitioned before and / or during coding. Figure 7 In the example shown, the video encoder 500 includes an adder 502, a transform coefficient generator 504, a coefficient quantization unit 506, an inverse quantization and transform coefficient processing unit 508, an adder 510, an intra-frame prediction processing unit 512, an inter-frame prediction processing unit 514, a filter unit 516, and an entropy coding unit 518. Figure 7 As shown, the video encoder 500 receives source video blocks and outputs a bitstream.

[0468] exist Figure 7 In the example shown, the video encoder 500 generates residual data by subtracting a predicted video block from a source video block. The selection of the predicted video block is described in detail below. The summer 502 represents the component configured to perform this subtraction operation. In one example, the subtracted video block appears in the pixel domain. The transform coefficient generator 504 applies a transform such as the Discrete Cosine Transform (DCT), Discrete Sine Transform (DST), or a conceptually similar transform (e.g., four 8×8 transforms can be applied to a 16×16 array of residual values) to the residual block or its sub-partitions to produce a set of residual transform coefficients. The transform coefficient generator 504 can be configured to perform any and all combinations of transforms included in the discrete trigonometric transform family, including their approximations. The transform coefficient generator 504 can output the transform coefficients to the coefficient quantization unit 506. The coefficient quantization unit 506 can be configured to perform quantization of the transform coefficients. The quantization process can reduce the bit depth associated with some or all of the coefficients. The degree of quantization can change the rate distortion (i.e., the relationship between bit rate and video quality) of the encoded video data. The degree of quantization can be modified by adjusting the quantization parameter (QP). The quantization parameter can be determined based on the slice bit level and / or CU bit level (e.g., CU increment QP value). QP data can include any data used to determine the QP used for quantizing a particular set of transform coefficients. Figure 7 As shown, the quantized transform coefficients (which may be referred to as bit values) are output to the inverse quantization and transform coefficient processing unit 508. The inverse quantization and transform coefficient processing unit 508 can be configured to apply inverse quantization and inverse transform to generate reconstructed residual data. Figure 5As shown, at adder 510, the reconstructed residual data can be added to the predicted video block. This allows for the reconstruction of the encoded video block, and the resulting reconstructed video block can be used to evaluate the coding quality of a given prediction, transform, and / or quantization. The video encoder 500 can be configured to perform multiple coding rounds (e.g., coding while changing one or more of the prediction, transform, and quantization parameters). The rate distortion or other system parameters of the bitstream can be optimized based on the evaluation of the reconstructed video block. Furthermore, the reconstructed video block can be stored and used as a reference for predicting subsequent blocks.

[0469] Refer again Figure 7 The intra-prediction processing unit 512 can be configured to select an intra-prediction mode for a video block to be encoded. The intra-prediction processing unit 512 can be configured to evaluate frames and determine the intra-prediction mode used to encode the current block. As described above, possible intra-prediction modes may include a planar prediction mode, a DC prediction mode, and an angular prediction mode. Furthermore, it should be noted that in some examples, the prediction mode of the chrominance component can be inferred from the prediction mode of the luma prediction mode. The intra-prediction processing unit 512 can select an intra-prediction mode after performing one or more encoding rounds. Additionally, in one example, the intra-prediction processing unit 512 can select the prediction mode based on rate-distortion analysis. Figure 7 As shown, the intra-frame prediction processing unit 512 outputs intra-frame prediction data (e.g., syntax elements) to the entropy coding unit 518 and the transform coefficient generator 504. As described above, the transform performed on the residual data can be mode-dependent (e.g., the quadratic transform matrix can be determined based on the prediction mode).

[0470] Refer again Figure 7 Inter-frame prediction processing unit 514 can be configured to perform inter-frame prediction coding for the current video block. Inter-frame prediction processing unit 514 can be configured to receive a source video block and calculate the motion vector of the PU of the video block. The motion vector can indicate the displacement of the prediction unit of the video block within the current video frame relative to the prediction block within a reference frame. Inter-frame prediction coding can use one or more reference images. Furthermore, motion prediction can be unidirectional prediction (using one motion vector) or bidirectional prediction (using two motion vectors). Inter-frame prediction processing unit 514 can be configured to select a prediction block by calculating pixel differences determined by, for example, sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. As described above, motion vectors can be determined and specified based on motion vector prediction. As described above, inter-frame prediction processing unit 514 can be configured to perform motion vector prediction. Inter-frame prediction processing unit 514 can be configured to generate a prediction block using motion prediction data. For example, inter-frame prediction processing unit 514 can locate the prediction video block within the frame buffer (…). Figure 7(Not shown in the image). It should be noted that the inter-frame prediction processing unit 514 can be further configured to apply one or more interpolation filters to the reconstructed residual block to compute sub-integer pixel values ​​for motion estimation. The inter-frame prediction processing unit 514 can output the motion prediction data of the computed motion vectors to the entropy coding unit 518.

[0471] like Figure 7 As shown, filter unit 516 receives reconstructed video blocks and coding parameters, and outputs modified reconstructed video data. Filter unit 516 can be configured to perform deblocking and / or Sample Adaptive Offset (SAO) filtering. SAO filtering is a nonlinear amplitude mapping that can be used to improve the reconstruction by adding an offset to the reconstructed video data. It should be noted that, as Figure 7 As shown, the intra-frame prediction processing unit 512 and the inter-frame prediction processing unit 514 can receive modified reconstructed video blocks via the filter unit 216. The entropy coding unit 518 receives quantized transform coefficients and prediction syntax data (i.e., intra-frame prediction data and motion prediction data). It should be noted that in some examples, the coefficient quantization unit 506 can perform a scan of the matrix including the quantized transform coefficients before outputting the coefficients to the entropy coding unit 518. In other examples, the entropy coding unit 518 can perform a scan. The entropy coding unit 518 can be configured to perform entropy coding according to one or more of the techniques described herein. Thus, the video encoder 500 represents an example of a device configured to generate encoded video data according to one or more techniques of this disclosure.

[0472] Refer again Figure 1 The data encapsulator 107 can receive encoded video data and generate a compatible bitstream according to a defined data structure, such as a NAL unit sequence. A device receiving the compatible bitstream can reproduce the video data from it. Furthermore, as mentioned above, sub-bitstream extraction can refer to the process by which a device receiving an ITU-T H.265 compliant bitstream forms a new ITU-T H.265 compliant bitstream by discarding and / or modifying data in the received bitstream. It should be noted that the term compliant bitstream can be used instead of compatible bitstream. In one example, the data encapsulator 107 can be configured to generate a syntax according to one or more techniques described herein. It should be noted that the data encapsulator 107 does not necessarily need to be located in the same physical device as the video encoder 106. For example, functions described as being performed by the video encoder 106 and the data encapsulator 107 can be distributed across... Figure 6 In the device shown.

[0473] As mentioned above, in JVET-P2001, a signal is sent indicating that the image resolution is not ideal. As further described above, a bitstream can consist of several CVSs, some with a resolution of, for example, 1920×1080 and others with a resolution of 1280×720. When preparing CVSs for encoding, it is typically (and sometimes necessary) to set a level indicator and `pic_width_max_in_luma_samples` and `pic_height_max_in_luma_samples` for the actual values ​​of the encoding resolution. For example, a bitstream might be encoded at different resolutions for delivery via an adaptive bitrate (ABR) streaming technology, such as Dynamic Adaptive Streaming (DASH) over HTTP. In this case, several versions of the same segment are encoded at different resolutions, and each resolution is indicated with a different level, even though all versions are intended to be displayed at the same resolution. When these CVSs are concatenated together in the same bitstream, it is desirable to indicate that all images are intended to be displayed at the same resolution, for example, 1920×1080 resolution in the case above. That is, this prevents re-initialization of the display area or a change in the actual display area at the CVS boundaries.

[0474] In one example, according to the techniques described herein, the parameters for the expected display resolution can be included in the DPS. It should be noted that in some cases, it can be assumed that within the same bitstream, even if the encoding resolution changes between CVSs or changes within a CVS (with RPR), the expected display resolution will not change. Table 6 shows an example of a syntax structure for the decoding parameter set indicating the expected display resolution according to the techniques described herein.

[0475]

[0476] Table 6

[0477] Regarding Table 6, the semantics can be based on the semantics provided above for the syntax elements intended_display_width_in_luma_samples and intended_display_height_in_lurna_samples in Table 3. In one example, the following semantics can be used:

[0478] The intended_display_width_in_luma_samples parameter specifies the intended display width in luminance samples for each cropped decoded image referenced by the DPS.

[0479] The intended_display_height_in_luma_samples parameter specifies the intended display height in luminance samples for each cropped decoded image that references the DPS.

[0480] Note—Expected display width and expected display height provide guidance for width, height, and aspect ratio. The cropped decoded image is intended to be mapped to these dimensions. When the expected display width and height differ from the encoded display width and height, a resampling process can be applied to the cropped decoded image, but no specific resampling method is mandated or recommended. Expected display width and expected display height do not impose any constraints on the encoded image width and height, as expressed by pic_width_in_luma_samples and pic_height_in_luma_samples, respectively.

[0481] In one example, variable-length encoding (e.g., ue(v)) can be used instead of fixed-length encoding to signal the syntax elements `intended_display_width_in_luma_samples` and `intended_display_height_in_luma_samples`. In another example, the signaling of `intended_display_width_in_luma_samples` and `intended_display_height_in_luma_samples` can be sent alternatively in the SPS, the VUI, or the SEI message. As mentioned above, in ITU-T H.265, `vui_parameter()` includes a default display window parameter syntax element that identifies the area within the fitted clipping window and is suggested to be displayed in the absence of any alternative indication of preferred display characteristics. It should be noted that in ITU-T H.265, the default display window parameter syntax elements def_disp_win_left_offset, def_disp_win_right_offset, def_disp_win_top_offset, and def_disp_win_bottom_offset will identify the region within the snap-fit ​​clipping window as an offset relative to the values ​​provided by def_disp_win_left_offset, def_disp_win_right_offset, def_disp_win_top_offset, and def_disp_win_bottom_offset. Therefore, in vui_parameters() in ITU-T H.265, the default display window parameter syntax elements indirectly identify the default display window. In other words, in order to determine the conditionally existing default display window syntax elements conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset, it is necessary to parse def_disp_win_left_offset, def_disp_win_right_offset, def_disp_win_top_offset, and def_disp_win_bottom_offset.When signaling intended_display_width_in_luma_samples and intended_display_height_in_luma_samples in SPS, VUI, or SEI messages, these two syntax elements provide the expected display size separately, which may be more efficient.

[0482] In one example, according to the techniques described herein, a signal can be sent in the SPS to indicate whether the expected display width and height are equal to the width and height specified by pic_width_max_in_luma_samples, respectively. Tables 7A to 7C illustrate examples of the techniques described herein, wherein a signal is sent in the SPS to indicate whether the expected display width and height are equal to the width and height specified by pic_width_max_in_luma_samples, respectively.

[0483]

[0484] Table 7A

[0485]

[0486] Table 7B

[0487]

[0488] Table 7C

[0489] Regarding Tables 7A to 7C, the semantics can be based on the semantics provided above, where the following semantics are provided for the syntax elements intended_display_equal_max_display_flag, intended_display_width_offset, and intended_display_height_offset:

[0490] The `intended_display_equal_max_diaplay_flag` being equal to 1 indicates that the expected display width is equal to the width specified by `pic_width_max_in_luma_samples` in luminance samples, and the expected display height is equal to the height specified by `pic_height_max_in_luma_samples` in luminance samples.

[0491] The intended_display_width specifies the expected display width of each cropped decoded image that references SPS, in luminance samples.

[0492] The intended_display_height specifies the intended display height for each cropped decoded image that references SPS, in luminance samples.

[0493] Note—Expected display width and expected display height provide guidance for width, height, and aspect ratio. The cropped decoded image is intended to be mapped to these dimensions. When the expected display width and height differ from the encoded display width and height, a resampling process can be applied to the cropped decoded image, but no specific resampling method is mandated or recommended. Expected display width and expected display height do not impose any constraints on the encoded image width and height, as expressed by pic_width_in_luma_samples and pic_height_in_luma_samples, respectively.

[0494] It should be noted that, relative to the examples provided in Table 7C, the expected display width and expected display height can be provided in another syntax structure (e.g., DPS).

[0495] Furthermore, it should be noted that in one example, the syntax elements `intended_display_width` and `intended_display_height` can be replaced with `intended_display_width_offset` and `intended_display_height_offset`, where these syntax elements have semantics based on the following:

[0496] The intended_display_width_offset specifies the intended display width for each cropped decoded image that references SPS, in luminance samples.

[0497] intended_display_width_in_luma_samples=pic_width_max_in_luma_samples-intended_display_width_offset.

[0498] The intended_display_height_offset specifies the intended display height for each cropped decoded image that references SPS, in luminance samples.

[0499] intended_display_height_in_luma_samples=pic_height_max_in_luma_samples-intended_display_height_offset.

[0500] Table 8 shows another example of a syntax structure for a set of decoding parameters used to indicate the expected display resolution, according to the techniques described herein. It should be noted that in Table 8, the syntax elements `intended_display_width_in_luma_samples` and `intended_display_height_in_luma_samples` are conditionally signaled based on flags.

[0501]

[0502] Table 8

[0503] Regarding Table 8, the semantics can be based on the semantics provided above for the syntax elements intended_display_info_present_flag, intended_display_width_in_luma_samples, and intended_display_height_inluma_samples in Table 3. In one example, the following semantics can be used:

[0504] A value of 1 for `intended_display_info_present_flag` indicates that the expected display width (`intended_display_width_in_luma_samples`) and expected display height (`intended_display_height_in_luma_samples`) syntax elements exist in the DPS. A value of 0 for `intended_display_info_present_flag` indicates that the expected display width (`intended_display_width_in_luma_samples`) and expected display height (`intended_display_height_in_luma_samples`) syntax elements do not exist in the DPS.

[0505] The intended_display_width_in_luma_samples parameter specifies the intended display width in luminance samples for each cropped decoded image referenced by the DPS.

[0506] The intended_display_height_in_luma_samples parameter specifies the intended display height in luminance samples for each cropped decoded image that references the DPS.

[0507] Note—Expected display width and expected display height provide guidance for width, height, and aspect ratio; the output image is intended to be mapped to these dimensions. Expected display width and expected display height do not impose any constraints on the encoded image width and encoded image height as expressed by pic_width_in_luma_samples and pic_height_in_luma_samples, respectively.

[0508] In the example, the term "cropped decoded image" can be replaced with either the term "cropped image" or the term "decoded image".

[0509] In another example, according to the techniques described herein, the clipping window parameters for the expected display resolution can be included in the SPS. Table 9 shows examples of relevant portions of the sequence parameter set syntax structure for indicating the expected display resolution according to the techniques described herein.

[0510]

[0511] Table 9

[0512] Regarding Table 9, the semantics can be based on the semantics provided above for the syntax elements sps_conformance_window_flag, sps_conf_win_left_offset, sps_conf_win_right_offset, sps_conf_win_top_offset, and sps_conf_win_bottom_offset in Table 4. In one example, the following semantics can be used:

[0513] A `sps_conformance_window_flag` value of 1 indicates that the clipping window offset parameter is immediately following the `conformance_window_flag` in SPS. A `conformance_window_flag` value of 0 indicates that the clipping window offset parameter is not present.

[0514] `sps_conf_win_left_offset`, `sps_conf_win_right_offset`, `sps_conf_win_top_offset`, and `sps_conf_win_bottom_offset` specify the cropping window applied to an image with `pic_width_in_luma_samples` equal to `pic_width_max_in_luma_samples` and `pic_height_in_luma_samples` equal to `pic_height_max_in_luma_samples`. When `conformance_window_flag` equals 0, it is inferred that the values ​​of `sps_conf_win_left_offset`, `sps_conf_win_right_offset`, `sps_conf_win_top_offset`, and `sps_conf_win_bottom_offset` are equal to 0.

[0515] It should be noted that when `sps_conformance_window_flag`, `sps_conf_wm_left_offset`, `sps_conf_win_right_offset`, `sps_conf_win_top_offset`, and `sps_conf_win_bottom_offset` are included in SPS, the corresponding syntax elements `conformance_window_flag`, `conf_win_left_offset`, `conf_win_right_offset`, `conf_win_top_offset`, and `conf_win_bottom_offset` in PPS can be renamed as follows: `pps_conformance_window_flag`, `pps_conf_win_left_offset`, `pps_conf_win_right_offset`, `pps_conf_win_top_offset`, and `pps_conf_win_bottom_offset`. Furthermore, the following can be added to the semantics of PPS:

[0516] When pic_width_in_luma_samples equals pic_width_max_in_luma_samples and pic_height_in_luma_sample equals pic_height_max_in_luma_samples, the bitstream meets the requirements that pps_conf_win_left_offset, pps_conf_win_right_offset, pps_conf_win_top_offset, and pps_conf_win_bottom_offset are equal to sps_conf_win_left__offset, sps_conf_win_right_offset, sps_conf_win_top_offset, and sps_conf_win_bottom_offset, respectively.

[0517] As stated above, video coding standards should provide mechanisms that can handle resolution changes in a manner that minimizes (or eliminates) the introduction of artifacts, regardless of whether the resolution change occurs at the beginning of a new CVS or in the middle of a CVS. However, it should be noted that video decoders should not be expected to handle extreme fluctuations in encoded resolution (e.g., resolution changes at every frame) without introducing some artifacts. In one example, according to the techniques described herein, constraints can be introduced to prevent frequent resolution changes. In one example, the following constraints can be introduced, for example, as a profile limitation: In the output, the distance between output format changes should be at least one second (or half a second), which can be expressed in the format as:

[0518] When the output format of image n is different from the output format of the previous image arranged in the output order, for all m in which DpbOutputTime[m]-DpbOutputTime[n] is less than one second, the output format of image m should be the same as the output format of image n.

[0519] Where DpbOutputTime is the output time of the decoded image buffer.

[0520] It should be noted that different time limits can be selected, such as 1.5 seconds or 250 milliseconds. The limit can also be alternatively expressed in terms of the number of images, such as:

[0521] When the output format of image n is different from the output format of the preceding image arranged in output order, the output format of image m should be the same as that of image n for the subsequent X images arranged in output order after image n.

[0522] Where X is a specific value, such as 15 or 31.

[0523] It should be noted that JVET-P2001 provides the following for the maximum DPB size:

[0524] When the specified level is not level 8.5, the value of max_dec_pic_buffering_minus1[Htid]+1 should be less than or equal to MaxDpbSize, which is derived as follows:

[0525]

[0526] MaxLumaPs is specified in Table 10, and maxDpbPicBuf is equal to 8.

[0527]

[0528]

[0529] Table 10

[0530] In one example, according to the techniques described in this article, to ensure that the number of DPB slots available for decoding the image does not increase when pic_width_in_luma_samples and / or pic_height_in_luma_samples are less than pic_width_max_in_luma_samples and pic_height_max_in_luma_samples respectively, MaxDpbSize can be derived using the following procedure:

[0531] PicSizeMaxInSamplesY=pic_width_max_in_luma_samples*pic_height_max_in_luma_samples

[0532] When the specified level is not level 8.5, the value of max_dec_pic_buffering_minus1[Htid]+1 should be less than or equal to MaxDpbSize, which is derived as follows:

[0533]

[0534] In another example, PicSizeMaxInSamplesY can be exported as provided below. This ensures that even when converting from one CVS to another, the number of images in the DPB will not exceed the maximum allowed under the assumption that all images are encoded at the intended display resolution.

[0535] PicSizeMaxInSamplesY=Max(pic_width_max_in_luma_samples*pic_height_max_in_luma_samples,intended_display_width_in_luma_samples*intended_display_height_in_luma,,samples)

[0536] JVET-P2001 includes limitations on the height and width of an image relative to the height and width of a reference image. In some cases, it may be desirable to impose limitations on the width and height after a scaling window has been applied to ensure that the stride between referenced samples is not too large. In one example, according to the techniques described herein, the following limitations can be applied to the width and height:

[0537] Let refPicOutputWidthL and refPicOutputHeightL be the PicOutputWidthL and PicOutputHeightL of the reference image that references the current image of this PPS, respectively. The bitstream compliance requirement must satisfy all of the following conditions:

[0538] -PicOutputWidthL*2 should be greater than or equal to refPicOutputWidthL.

[0539] -PicOutputHeightL*2 should be greater than or equal to refPicOutputHeightL.

[0540] -PicOutputWidthL should be greater than or equal to refPicOutputWidthL*8.

[0541] -PicOutputHeightL should be greater than or equal to refPicOutputHeightL*8.

[0542] The variables PicOutputWidthL and PicOutputHeightL are derived as follows:

[0543]

[0544] It should be noted that in one or more of the examples described herein, the output format can be defined by the variables PicOutputWidthL and PicOutputHeightL. Furthermore, the output format can be defined by PicOutputWidthL, PicOutputHeightL, chroma_format_idc, separate_colour_plane_flag, and bit_depth_minus8. Alternatively, the terms "resolution" or "width and height" can be used instead of "format".

[0545] As mentioned above, JVET-P2001 includes the syntax element `ref_pic_resampling_enabled_flag`, which specifies whether reference image resampling can be used in CVS. The constraints on expressions related to `ref_pic_resampling_enabled_flag` can be unnecessarily strict and prohibit some use cases where reference image resampling is not used, such as situations where the resolution changes within CVS but no prediction is performed between images with different resolutions. An improved way to express constraints related to `ref_pic_resampling_enabled_flag` is as follows:

[0546] When ref_pic_resampling_enabled_flag equals 0, the bitstream compliance requirements are met: PicOutputWidthL equals refPicOutputWidthL, and PicOutputHeightL equals refPicOutputHeightL.

[0547] In this way, source device 102 represents an example of a device configured to: send a signal indicating a syntax element indicating the expected display width of each image in the reference parameter set, and send a signal indicating a syntax element indicating the expected display height of each image in the reference parameter set.

[0548] Refer again Figure 1 Interface 108 may include any device configured to receive data generated by data encapsulator 107 and transmit and / or store data to a communication medium. Interface 108 may include a network interface card such as an Ethernet card, and may include an optical transceiver, an RF transceiver, or any other type of device capable of transmitting and / or receiving information. Furthermore, interface 108 may include a computer system interface that enables files to be stored on a storage device. For example, interface 108 may include protocols supporting Peripheral Component Interconnect (PCI) and High Speed ​​Peripheral Component Interconnect (PCIe) bus protocols, proprietary bus protocols, Universal Serial Bus (USB) protocols, and I / O protocols.2 C's chipset, or any other logical and physical structure that can be used to interconnect peer devices.

[0549] Refer again Figure 1 The target device 120 includes an interface 122, a data decapsulator 123, a video decoder 124, and a display 126. Interface 122 may include any device configured to receive data from a communication medium. Interface 122 may include a network interface card such as an Ethernet card, and may include an optical transceiver, an RF transceiver, or any other type of device capable of receiving and / or transmitting information. Furthermore, interface 122 may include a computer system interface that allows retrieval of compatible video bitstreams from storage devices. For example, interface 122 may include protocols supporting PCI and PCIe bus protocols, dedicated bus protocols, USB protocols, and I / O protocols. 2 C's chipset or any other logical and physical structure that can be used to interconnect peer devices. Data decapsulator 123 can be configured to receive and parse any of the example syntax structures described herein.

[0550] Video decoder 124 may include any device configured to receive bitstreams (e.g., sub-bitstream extraction) and / or acceptable variations thereof and reproduce video data therefrom. Display 126 may include any device configured to display video data. Display 126 may include one of a variety of display devices such as a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, or another type of display. Display 126 may include a high-definition display or an ultra-high-definition display. It should be noted that, although in Figure 1 In the example shown, video decoder 124 is described as outputting data to display 126, but video decoder 124 can be configured to output video data to various types of devices and / or their sub-components. For example, video decoder 124 can be configured to output video data to any communication medium, as described herein.

[0551] Figure 8 This is a block diagram illustrating an example of a video decoder configured to decode video data according to one or more techniques of this disclosure (e.g., a decoding process used for constructing the reference picture list described above). In one example, video decoder 600 may be configured to decode transform data and reconstruct residual data from transform coefficients based on the decoded transform data. Video decoder 600 may be configured to perform intra-frame prediction decoding and inter-frame prediction decoding, and may therefore be referred to as a hybrid decoder. Video decoder 600 may be configured to parse any combination of the syntax elements described above in Tables 1 to 10. Video decoder 600 may decode pictures based on or according to the above process and also based on the parsed values ​​in Tables 1 to 10.

[0552] exist Figure 8 In the example shown, the video decoder 600 includes an entropy decoding unit 602, an inverse quantization unit 604, an inverse transform coefficient processing unit 606, an intra-frame prediction processing unit 608, an inter-frame prediction processing unit 610, a summer 612, a post-filter unit 614, and a reference buffer 616. The video decoder 600 can be configured to decode video data in a manner consistent with video coding systems. It should be noted that although the exemplary video decoder 600 shown has different functional blocks, such illustrations are intended for descriptive purposes and do not limit the video decoder 600 and / or its sub-components to a particular hardware or software architecture. The functionality of the video decoder 600 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0553] like Figure 8 As shown, the entropy decoding unit 602 receives an entropy-encoded bitstream. The entropy decoding unit 602 can be configured to decode syntax elements and quantization coefficients from the bitstream according to a process that is the inverse of the entropy encoding process. The entropy decoding unit 602 can be configured to perform entropy decoding according to any of the entropy encoding techniques described above. The entropy decoding unit 602 can determine the values ​​of syntax elements in the encoded bitstream in a manner consistent with video coding standards. Figure 8 As shown, the entropy decoding unit 602 can determine the quantization parameters, quantization coefficient values, transformed data, and predicted data from the bitstream. In this example, as... Figure 8 As shown, the inverse quantization unit 604 and the inverse transform coefficient processing unit 606 receive quantization parameters, quantization coefficient values, transform data and prediction data from the entropy decoding unit 602, and output reconstructed residual data.

[0554] See you again Figure 8The reconstructed residual data can be provided to the summer 612. The summer 612 can add the reconstructed residual data to the predicted video block and generate reconstructed video data. The predicted video block can be determined according to the predicted video technique (i.e., intra-frame prediction and inter-frame prediction). The intra-frame prediction processing unit 608 can be configured to receive intra-frame prediction syntax elements and retrieve the predicted video block from the reference buffer 616. The reference buffer 616 may include a memory device configured to store one or more video data frames. The intra-frame prediction syntax elements can identify intra-frame prediction modes, such as those described above. The inter-frame prediction processing unit 610 can receive inter-frame prediction syntax elements and generate motion vectors to identify the predicted block in one or more reference frames stored in the reference buffer 616. The inter-frame prediction processing unit 610 can generate motion-compensated blocks, possibly performing interpolation based on an interpolation filter. Identifiers for the interpolation filter used for motion estimation with sub-pixel accuracy can be included in the syntax elements. The inter-frame prediction processing unit 610 can use the interpolation filter to compute interpolated values ​​for sub-integer pixels of the reference block. The post-filter unit 614 can be configured to perform filtering on the reconstructed video data. For example, the post-filter unit 614 can be configured to perform deblocking and / or sample adaptive offset (SAO) filtering, for example based on parameters specified in the bitstream. Furthermore, it should be noted that in some examples, the post-filter unit 614 can be configured to perform dedicated arbitrary filtering (e.g., visual enhancement, such as mosquito noise cancellation). Figure 8 As shown, the video decoder 600 can output reconstructed video blocks. In this way, the video decoder 600 represents an example of a device configured to: parse syntax elements indicating whether to derive a list of reference images associated with an image header based on a list of reference images included in a sequence parameter set, and conditionally parse syntax elements indicating the index values ​​associated with the list of reference images included in the sequence parameter set based on the value of the syntax element indicating whether to derive the list of reference images associated with an image header based on a list of reference images included in a sequence parameter set.

[0555] In one or more examples, the functionality may be implemented by hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on or transmitted over a computer-readable medium and executed by a hardware-based processing unit. A computer-readable medium may include a computer-readable storage medium corresponding to a tangible medium such as a data storage medium, or a propagation medium that includes, for example, any medium facilitating the transfer of a computer program from one place to another according to a communication protocol. Thus, a computer-readable medium may generally correspond to: (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementing the techniques described in this disclosure. Computer program products may include computer-readable media.

[0556] By way of example, and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium that can be used to store required program code in the form of instructions or data structures and that is accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but rather refer to non-transient tangible storage media. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, where disks typically copy data magnetically, while optical discs use lasers to copy data optically. Combinations of the above should also be included within the scope of computer-readable media.

[0557] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into combined codecs. Moreover, these techniques can be implemented entirely within one or more circuit or logic elements.

[0558] The techniques disclosed herein can be implemented in various devices or apparatuses, including wireless mobile phones, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but they do not necessarily need to be implemented through different hardware units. Rather, as described above, various units can be combined in a codec hardware unit, or provided through an interoperable hardware unit comprising a collection of one or more processors as described above, combined with suitable software and / or firmware.

[0559] Furthermore, each functional block or feature of the base station equipment and terminal equipment used in each of the above embodiments can be implemented or executed by circuitry (typically one or more integrated circuits). Circuitry designed to perform the functions described in this specification may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, or combinations thereof. The general-purpose processor may be a microprocessor, or alternatively, it may be a conventional processor, a controller, a microcontroller, or a state machine. The general-purpose processor or each of the above circuitry can be configured by digital circuitry or by analog circuitry. Furthermore, when advancements in semiconductor technology lead to the development of technologies for manufacturing integrated circuits that replace current integrated circuits, integrated circuits produced using such technologies can also be used.

[0560] Various examples have been described. These and other examples are within the scope of the following claims.

[0561] <Summary of the Invention>

[0562] In one example, a method is provided for sending a signal to notify the output resolution of video data, the method comprising: sending a signal to notify a syntax element indicating the expected display width of each image in a reference parameter set; and sending a signal to notify a syntax element indicating the expected display height of each image in the reference parameter set.

[0563] In one example, a method for decoding video data is provided, the method comprising: parsing a syntax element indicating the expected display width of each image in a reference parameter set; and parsing a syntax element indicating the expected display height of each image in the reference parameter set.

[0564] In one example, the method is provided, wherein the syntax elements are included in the sequence parameter set.

[0565] In one example, the method is provided, wherein the syntax elements are conditionally present in the parameter set based on the value of the tag.

[0566] In one example, a device is provided that includes one or more processors configured to perform any and all combinations of steps.

[0567] In one example, the device is provided, wherein the device includes a video encoder.

[0568] In one example, the device is provided, wherein the device includes a video decoder.

[0569] In one example, a system includes: a device comprising a video encoder; and the device comprising a video decoder.

[0570] In one example, an apparatus is provided that includes means for performing any and all combinations of the steps.

[0571] In one example, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium including instructions stored thereon, the instructions, when executed, cause one or more processors of the device to perform any and all combinations of the steps.

[0572] In one example, a method for decoding video data is provided, the method comprising: receiving a sequence parameter set; parsing a maximum width syntax element specifying the maximum width of each decoded image referencing the sequence parameter set; parsing a maximum height syntax element specifying the maximum height of each decoded image referencing the sequence parameter set; and parsing a first marker syntax element indicating whether a clipping window offset parameter exists in the sequence parameter set, wherein the clipping window offset parameter specifies a clipping window applied to an image with a width equal to the maximum width and a height equal to the maximum height.

[0573] In one example, the method further includes: receiving an image parameter set; parsing a width syntax element specifying the width of a decoded image referencing the image parameter set; and parsing a height syntax element specifying the height of each decoded image referencing the image parameter set, wherein if the width specified by the width syntax element is equal to the maximum width and the height specified by the height syntax element is equal to the maximum height, the value of the fit-crop window offset parameter in the image parameter set is inferred to be equal to the value of the fit-crop window offset parameter in the sequence parameter set.

[0574] In one example, the method further includes: parsing a second tag syntax element specifying whether the snap-crop window offset parameter exists in the image parameter set, wherein if the value of the second tag syntax element is equal to 0, it is inferred that the value of the snap-crop window offset parameter in the image parameter set is equal to 0.

[0575] In one example, the method further includes: parsing the fitting cropping window offset parameter of a sample of an image output from the decoding process in CLVS, specified in the image parameter set.

[0576] In one example, a method for encoding image data is provided, the method comprising: sending a signal to notify a sequence parameter set, wherein: the sequence parameter set includes: (i) a maximum width syntax element specifying the maximum width of each decoded image referencing the sequence parameter set, (ii) a maximum height syntax element specifying the maximum height of each decoded image referencing the sequence parameter set, and (iii) a first marker syntax element indicating whether a clipping window offset parameter exists in the sequence parameter set, wherein the clipping window offset parameter specifies a clipping window applied to an image whose width is equal to the maximum width and whose height is equal to the maximum height.

[0577] In one example, a device including one or more processors is provided, the one or more processors being configured to: receive a sequence parameter set; parse a maximum width syntax element specifying the maximum width of each decoded image referencing the sequence parameter set; parse a maximum height syntax element specifying the maximum height of each decoded image referencing the sequence parameter set; and parse a first marker syntax element indicating whether a clipping window offset parameter exists in the sequence parameter set, wherein the clipping window offset parameter specifies a clipping window applied to an image with a width equal to the maximum width and a height equal to the maximum height.

[0578] <Cross-reference>

[0579] This non-provisional application claims priority to provisional application 62 / 949,864, filed December 18, 2019, pursuant to section 119 of title 35 of the United States Code, the entire contents of which are incorporated herein by reference.

Claims

1. A method of decoding video data, the method comprising: receiving a sequence parameter set; parsing a maximum width syntax element specifying a maximum width of each decoded picture referring to the sequence parameter set; parsing a maximum height syntax element specifying a maximum height of each decoded picture referring to the sequence parameter set; parsing a first flag syntax element having a value indicating that a sequence parameter set fit cropping window offset syntax element follows in the sequence parameter set; wherein the first flag syntax element is one bit, unconditionally present, and follows the maximum height syntax element in the sequence parameter set; parsing the sequence parameter set fit cropping window offset syntax element, wherein the sequence parameter set fit cropping window offset syntax element specifies a cropping window applied to pictures having a width equal to the maximum width and a height equal to the maximum height, and follows the first flag syntax element in the sequence parameter set; receiving a picture parameter set; parsing a width syntax element specifying a width of each decoded picture referring to the picture parameter set; parsing a height syntax element specifying a height of each decoded picture referring to the picture parameter set; parsing a second flag syntax element having a value indicating that a picture parameter set fit cropping window offset syntax element follows in the picture parameter set, wherein the second flag syntax element is unconditionally present in the picture parameter set; and parsing the picture parameter set fit cropping window offset syntax element, wherein the picture parameter set fit cropping window offset syntax element specifies a cropping window applied to pictures not satisfying the condition that the width is equal to the maximum width and the height is equal to the maximum height.

2. A method of encoding image data, the method comprising: signaling a sequence parameter set, wherein: the sequence parameter set comprises: (i) a maximum width syntax element specifying a maximum width of each decoded picture referring to the sequence parameter set, (ii) a maximum height syntax element specifying a maximum height of each decoded picture referring to the sequence parameter set; (iii) a first flag syntax element having a value indicating that a sequence parameter set fit cropping window offset syntax element follows in the sequence parameter set; wherein the first flag syntax element is one bit, unconditionally present, and follows the maximum height syntax element in the sequence parameter set; and (iv) the sequence parameter set fit cropping window offset syntax element, wherein the sequence parameter set fit cropping window offset syntax element specifies a cropping window applied to pictures having a width equal to the maximum width and a height equal to the maximum height, signaling a picture parameter set, wherein the picture parameter set comprises: (v) a width syntax element specifying the width of each decoded picture referring to the picture parameter set; (vi) a height syntax element specifying the height of each decoded picture referring to the picture parameter set; (vii) a second flag syntax element having a value indicative of a picture parameter set in-picture cropping window offset syntax element following it in the picture parameter set, wherein the second flag syntax element is unconditionally present in the picture parameter set; and (viii) a cropping window to which pictures that do not satisfy the width equal to the maximum width and the height equal to the maximum height condition are applied is specified.

3. An apparatus comprising one or more processors configured to: receive a sequence parameter set; parse a maximum width syntax element specifying a maximum width of each decoded picture referring to the sequence parameter set; parse a maximum height syntax element specifying a maximum height of each decoded picture referring to the sequence parameter set; parse a first flag syntax element having a value indicative of a sequence parameter set in-picture cropping window offset syntax element following it in the sequence parameter set; wherein the first flag syntax element is one bit, unconditionally present, and immediately follows the maximum height syntax element in the sequence parameter set; parse the sequence parameter set in-picture cropping window offset syntax element, wherein the sequence parameter set in-picture cropping window offset syntax element specifies a cropping window to which pictures having a width equal to the maximum width and a height equal to the maximum height are applied, and immediately follows the first flag syntax element in the sequence parameter set; receive a picture parameter set; parse a width syntax element specifying a width of each decoded picture referring to the picture parameter set; parse a height syntax element specifying a height of each decoded picture referring to the picture parameter set; parse a second flag syntax element having a value indicative of a picture parameter set in-picture cropping window offset syntax element following it in the picture parameter set, wherein the second flag syntax element is unconditionally present in the picture parameter set; and parse the picture parameter set in-picture cropping window offset syntax element, wherein the picture parameter set in-picture cropping window offset syntax element specifies a cropping window to which pictures that do not satisfy the width equal to the maximum width and the height equal to the maximum height condition are applied.

Images