System and method for signaling picture information in video coding

Abstract

The present disclosure relates to video encoding and, more particularly, to techniques for signaling picture information of an encoded video. According to one aspect of the present disclosure, in the event that both (a) a first flag indicating whether a temporal motion vector predictor can be enabled for a picture associated with a picture header and (b) a second flag indicating information associated with a reference picture list are equal to 1, a first syntax element is parsed from the picture header, the first syntax element specifies an index corresponding to a collocated picture for temporal motion vector prediction.

Description

Technical Field

[0001] This disclosure relates to video encoding, and more specifically to techniques for sending signals to notify image information 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 compatible bitstreams of video data. 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 the development of 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 (JEM7), 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 released 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.

[0003] 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-v9, 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.

[0004] 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

[0005] In one example, a method for decoding video data includes: receiving an image header; and parsing a first syntax element from the image header, wherein the first syntax element specifies an index corresponding to a juxtaposed image for time motion vector prediction, provided that both (a) a first flag indicating whether a time motion vector predictor can be enabled for an image associated with the image header and (b) a second flag indicating information associated with a list of reference images are equal to 1.

[0006] In one example, a device including one or more processors is configured to: receive an image header; and, if both (a) a first flag indicating whether a time motion vector predictor can be enabled for an image associated with the image header and (b) a second flag indicating information associated with a list of reference images are equal to 1, parse a first syntax element from the image header, the first syntax element specifying an index corresponding to a juxtaposed image for time motion vector prediction.

[0007] 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. Attached Figure Description

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

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

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

[0011] [ Figure 4 ] Figure 4 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.

[0012] [ Figure 5 ] Figure 5 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.

[0013] [ Figure 6 ] Figure 6 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

[0014] Generally, this disclosure describes various techniques for encoding video data. Specifically, this disclosure describes techniques for transmitting signals to notify image information of encoded video data. That is, for example, image information may include information indicating whether one or more video coding tools (e.g., prediction techniques, filtering techniques, etc.) can be enabled for an image and / or portions thereof. It should be noted that although the techniques of this disclosure are described relative to ITU-T H.264, ITU-T H.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-T H.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 references incorporated herein by way of citation are for descriptive purposes and should not be construed as limiting or creating ambiguity regarding the terminology used herein. For example, where a definition of a term provided in one 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 alternatives.

[0015] 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. Regions may be defined based on basic units (e.g., video blocks) and a set of rules defining regions. For example, a rule defining a region may be that a region must be an integer number of video blocks arranged in a rectangle. Furthermore, 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 by the number of chroma samples included in a video block, relative to the number of luminance 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.

[0016] 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, pictures are segmented into macroblocks. ITU-T H.265 specifies a similar Code Tree Unit (CTU) structure (which may be referred to as a Maximum Code Unit (LCU)). In ITU-T H.265, pictures are segmented into CTUs. In ITU-T H.265, for pictures, 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 Code 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.

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

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

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

[0020] 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 complete 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, where the single tile is contained within a single tile, or an image can include multiple tiles, where these multiple tiles (or their CTU rows) can be contained within one or more tiles. In JVET-P2001, how an image is divided into tiles is specified 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 area within a specific tile row and a specific tile column location. 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 area 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 necessarily restricted 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) 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.

[0021] 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 O This can correspond to the action portion of a sports event presentation (e.g., a view of a field), and sub-image 1 can 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 2NAL units can be removed from the bitstream (and therefore not decoded), while slice 0NAL units and slice 1NAL 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.

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

[0023] 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, clipped, or averaged according to weights) to generate a prediction. Images and their regions can be classified based on which types of prediction modes 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).

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

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

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

[0027] 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 coefficients. 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.

[0028] 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 either the MPS or the 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.

[0029] The following arithmetic operators can be used for the formulas used in this article: In addition, the following mathematical functions can be used: Log2(x) is the base-2 logarithm of x; Ceil(x) is the smallest integer greater than or equal to x.

[0030] Regarding the exemplary syntax used in this article, the following definitions of logical operators can be applied: x&&y The Boolean logic "and" of x and y The Boolean OR operation between x and y. !Boolean logic "No" x?y:z If x is TRUE or not equal to 0, evaluate to y; otherwise, evaluate to z.

[0031] In addition, the following relational operators can be applied: Furthermore, it should be noted that the following descriptors can be applied among the grammatical descriptors used in this paper: - b(8): A byte (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).

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

[0033] - se(v): Syntax element of signed integer 0-order Exp-Golomb encoding, starting from the leftmost bit.

[0034] - tb(v): A truncated binary code using at most maxVal bits, where maxVal is defined in the semantics of the syntax element.

[0035] - tu(v): A truncated unary code using at most maxVal bits, where maxVal is defined in the semantics of the syntax element.

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

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

[0038] 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 within 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 encompasses all types of slice NAL units. As described 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 specific 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 AUs that are not 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 PUs that are not 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.

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

[0040] In JVET-P2001, each of video sequences, GOPs, pictures, slices, and CTUs can be associated with metadata describing video coding attributes, and 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). An SPS is applied to zero or more integer CVSs, a PPS to zero or more integer integer coded pictures, and an APS to zero or more slices. DPS and VPS can optionally be referenced by an SPS. A PPS is applied to the single coded picture that references it. In JVET-P2001, parameter sets can be encapsulated as non-VCL NAL units and / or can be signaled as messages. JVET-P2001 also includes a Picture Header (PH), which is encapsulated as a non-VCL NAL 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).

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

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

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

[0044] forbidden_zero_bit should be equal to 0.

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

[0046] `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 56 (inclusive). Other values ​​for `nuh_layer_id` are reserved for future use by ITU-T | ISO / IEC.

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

[0048] The nuh_layer_id value of non-VCL NAL units is constrained as follows: - 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.

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

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

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

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

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

[0054] The value of nuh_temporal_id_plusl should not be equal to 0.

[0055] The variable TemporalId is exported as follows: TemporalId=nuh_temporal_id_plus1-1 When nal_unit_type is in the range IDR_W_RADL to RSV_IRAP_12 (inclusive), TemporalId should be equal to 0.

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

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

[0058] The TemporalId value of non-VCL NAL units is constrained as follows: - 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.

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

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

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

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

[0063] 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 PPSNUT, PREFIXAPSNUT, 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.

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

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

[0066] Note—NAL unit types within the scope of UNSPEC28 to UNSPEC31 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.

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

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

[0069] Table 2 Note—Clean Random Access (CRA) pictures may have associated RASL or RADL pictures present in the bitstream. Note—Instantaneous Decode Refresh (IDR) pictures with a nal_unit_type equal to IDR_N_LP do not have associated preamble pictures present in the bitstream. IDR pictures with a nal_unit_type equal to IDR_W_RADL do not have associated RASL pictures present in the bitstream, but may have associated RADL pictures present in the bitstream.

[0070] For any specific image's VCL NAL unit, the following applies: - 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 units of the picture or PU.

[0071] - 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 from IDR W RADL to CRA NUT (inclusive of end values), and all other VCL NAL units should all have a specific value of nal_unit_type in the range from TRAIL NUT to RSV_VCL_6 (inclusive of end values) or equal to GRA_NUT.

[0072] For single-layer bitstreams, the following constraints apply: - 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.

[0073] - When the image is the leading image of a TRAP image, the image should be a RADL or RASL image.

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

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

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

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

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

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

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

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

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

[0083] As provided in Table 2, the NAL unit may include a sequence parameter set syntax structure. Table 3 shows the sequence parameter set syntax structures provided in JVET-P2001.

[0084] Table 3 Regarding Table 3, JVET-P2001 provides the following semantics: 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.

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

[0086] `sps_decoding_parameter_set_id` specifies the value of `dps_decoding_parameter_set_id` for the DPS referenced by the SPS when `sps_decoding_parameter_set_id` is greater than 0. When `sps_decoding_parameter_set_id` equals 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.

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

[0088] When sps_video_parameter_set_id equals 0, the following applies: - SPS does not reference VPS.

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

[0090] - It is inferred that the value of vpsmaxlayersminus1 is equal to 0.

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

[0092] - It is inferred that the value of GeneralLayerIdx[nuh layer id] is equal to 0.

[0093] - It is inferred that the value of vps_indcpcndcnt_layer_nag|GcncralLayerIdx[nuh_layer_id] is equal to 1.

[0094] 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 nuhlayerid equal to nuhLayerId.

[0095] Increasing 1 to sps_max_sub_layers_minus1 specifies the maximum number of time sublayers that may exist in each CLVS referencing SPS. The value of sps_max_sub_layers_minus1 should be in the range of 0 to vps_max_sub_layers_minus 1 (inclusive).

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

[0097] 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 `generalhrdparameters()` 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]`.

[0098] 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_sub layers minus1]` in the `dpb_parameters()` syntax structure in the SPS. Otherwise, `MaxDecPicBuffMinus1` is set to equal `max_dec_pic_buffering_minus1[sps_max_sub_layers_minus1]` in the `layer_nonoutput_dpb_params_idx[GeneralLayerIdx[nuh_layer_id]]`-th `dpb_parameters()` syntax structure in the VPS.

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

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

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

[0102] chroma_format_idc specifies the chroma sampling relative to the luminance sampling.

[0103] A `separate_colour_plane_flag` value of 1 indicates that the three color components of the 4:4:4 chroma format are encoded separately. A `separate_colour_plane_flag` value of 0 indicates that the color components are not encoded separately. If `separate_colour_plane_flag` does not exist, it is inferred to be 0. When `separate_colour_plane_flag` is 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.

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

[0105] Based on the value of separate_colour_plane_flag, the value of the variable ChromaArrayType is specified as follows: - If separate_colour_plane_flag equals 0, then ChromaArrayType is set to equal chroma format ide.

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

[0107] `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.

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

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

[0110] 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_sizc_minus5 be less than or equal to 2.

[0111] The variables CtbLog2SizeY and CtbSizeY are exported as follows: CtbLog2SizeY = sps_log2_ctu_size_minus5 + 5 CtbSizeY = 1 < <CtbLog2SizeY 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.

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

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

[0114] `subpic_ctu_top_left_x[i]` specifies the horizontal position of the top-left CTU of the i-th subpicture, in CtbSizeY. The length of the syntax element is 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.

[0115] `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.

[0116] `subpic_width_minus1[i]` incremented by 1 specifies the width of the i-th sub-image, in units of `CtbSizeY`. The length of the syntax element is `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`.

[0117] `subpic_height_minus1[i]` incremented by 1 specifies the height of the i-th subpicture, in CtbSizeY units. 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.

[0118] 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 in 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 in loops. When it does not exist, it is inferred that the value of subpic_treated_as_pic_flag[i] is equal to 0.

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

[0120] The following constraints apply to bitstream compliance requirements: - For any two subpics subpicA and subpicB, when the index of subpicA is less than the index of subpicB, any encoded NAL unit of subpicA should be appended to any encoded NAL unit of subpicB in the decoding order.

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

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

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

[0124] Increasing 1 to 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).

[0125] `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. 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: BitDepth = 8 + bit_dcpth_minus8 QpBdOffset = 6 * bit_depth_minus8 bit_depth_minus8 should be in the range of 0 to 8 (inclusive).

[0126] The minimum allowed quantization parameters for the transition skip mode are specified as follows: QpPrimeTsMin = 4 + min_qp_prime_ts_ minus4 The value of min_qp_prime_ts_minus4 should be in the range of 0 to 48 (inclusive).

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

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

[0129] The following specifies the value of the variable MaxPicOrderCntLsb used in the decoding process of image order counting: MaxPicOrderCntLsb = 2 (log2_max_pic_order_ent_lsb_minus4+4) The value of log2_max_pic_order_cnt_lsb_minus4 should be in the range of 0 to 12 (inclusive).

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

[0131] Incrementing 1 by 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).

[0132] `sps_sub_layer_dpb_params_flag` controls the presence of the syntax elements `max_dec_pic_buffering_minus1[i]`, `max_num_rcordcr_pics[i]`, and `max_latency_increase_plus1[i]` in the `dpb_paramcters()` syntax structure in SPS. If they do not exist, the value of `sps_sub_dpb_params_info_present_flag` is inferred to be 0.

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

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

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

[0136] The fact that rpl1_same_as_rpl0_flag equals 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 is as follows: - 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].

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

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

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

[0140] `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.

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

[0142] The variables MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are derived as follows: MinCbLog2SizeY = Log2_min_luma_coding_block_size_minus2 + 2 MinCbSizeY = 1< <MinCbLog2SizeY IbcBufWidthY = 256 * 128 / CtbSizeY IbcBufWidthC = IbcBufWidthY / SubWidthC VSize = Min(64, CtbSizeY) The value of MinCbSizeY should be less than or equal to VSize.

[0143] The variables CtbWidthC and CtbHeightC specify the width and height of the array for each chroma CTB, respectively. These two variables are derived as follows: - If chroma_format_idc equals 0 (monochrome) or separate_colour_plane_flag equals 1, then CtbWidthC and CtbHeightC both equal 0.

[0144] - Otherwise, CtbWidthC and CtbHeightC are exported as follows: CtbWidthC = CtbSizeY / SubWidthC CtbHeightC = CtbSizeY / SubHeightC For log2BlockWidth in the range of 0 to 4 and log2BlockHeight in the range of 0 to 4 (including the end values), call the specified right upper diagonal and raster scan order array initialization process with 1 << log2BlockWidth and 1 << log2BlockHeight as inputs, and assign the output to DiagScanOrder[log2BlockWidth ][log2BlockHeight ] and Raster2DiagScanPos[ log2BlockWidth ][log2BlockHeight ].

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

[0146] The partition_constraints_override_enabled_flag being equal to 1 specifies the presence of the partition_constraints_override_flag in the PH that references the SPS. The partition_constraints_override_enabled_flag being equal to 0 means that the partition_constraints_override_flag does not exist in the PH that references the SPS.

[0147] `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 partitioning 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 partitioning of the CTU is derived as follows: MinQtLog2SizentraY = sps_log2_diff_min_qt_min_cb_intra_slice_luma +MinCbLog2SizeY `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 sample in the luminance blade block generated by quadtree segmentation of the CTU and the base-2 logarithm of the smallest luminance coded block size in the luminance sample of the luminance CU in the slice with slice_type equal to 0 (B) or 1 (P) referencing the SPS. When `partition_constraints_override_enabled_flag` equals 1, the default difference can be overridden by `pic_og2_diff_min_qt_min_cb_luma` existing in the PH referencing the SPS. 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 sample in the luminance blade block generated by quadtree segmentation of the CTU is derived as follows: MinQtLog2SizeInterY = sps_log2_diff_min_qt_min_cb_inter_slice +MinCbLog2SizeY `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 `CtbLog2SizeY - MinCbLog2SizeY` (inclusive).

[0148] `sps_max_mtt_hierarchy_depth_intra_slice_luma` specifies the default maximum hierarchical depth of 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 referencing SPS. The value of `sps_max_mtt_hierarchy_depth_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive).

[0149] `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 `CtbLog2SizcY - MinQtLog2SizcIntraY` (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.

[0150] `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 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_lmna does not exist, it is inferred that the value of sps_log2_diff_max_tt_min_qt_intra_slice_luma is equal to 0.

[0151] `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 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 referenced 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 `ClbLog2SizeY - 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_bt_min_qt_inter_slice is equal to 0.

[0152] `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 - MinQtLog2SizelnterY` (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.

[0153] `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 coding 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: MinQtLog2SizentraC = sps_log2_diff_min_qt_min_cb_intra_slice_chroma+ MinCbLog2SizeY `Sps_max_mtt_hierarchy_depth_intra_slice_chroma` specifies the default maximum hierarchical depth of the chroma coding unit generated by multi-type tree segmentation of chroma quadtree leaves with `treeType` equal to `DUAL_TREE_CHROMA` in slices with `slice_type` equal to 2 (I) of the referenced SPS. 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 referenced SPS. The value of `sps_max_nitt_hierarchy_depth_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). When it does not exist, the value of `sps_max_mtt_hiearchy_depth_intra_slice_chroma` is inferred to be 0.

[0154] `sps_log2_diff_max_ht_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.

[0155] `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 segmentation, 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.

[0156] `sps_max_luma_transform_sizc_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.

[0157] When CtbSizeY is less than 64, the value of sps_max_luma_transform_size_64_flag should be equal to 0.

[0158] The variables MinTbLog2SizeY, MaxTbLog2SizeY, MinTbSizeY, and MaxTbSizeY are derived as follows: MinTbLog2SizeY = 2 MaxTbLog2SizeY = sps_max_luma_transform_size_64_flag ? 6 : 5 MinTbSizeY = 1 < <MinTbLog2SizeY MaxTbSizeY = 1< <MaxTbLog2SizeY A value of 0 for sps_joint_cbcr_enabled_flag disables joint encoding of chroma residuals. A value of 1 for sps_joint_cbcr_enabled_flag enables joint encoding of chroma residuals.

[0159] `same_qp_table_for_chroma` equal to 1 specifies that only one chroma QP map table is signaled, and this table applies to Cb and Cr residuals as well as joint Cb-Cr residuals. `same_qp_table_for_chroma` equal to 0 specifies that three chroma QP maps are signaled in the SPS. When `same_qp_table_for_chroma` is not present in the bitstream, it is inferred that the value of `same_qp_table_for_chroma` is equal to 1.

[0160] `qp_table_start_minus26[i]` plus 26 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 - QpBdOffsetC 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.

[0161] The increment of 1 in num_points_in_qp_table_minus1[i] specifies the number of points used to describe the i-th chromaticity QP mapping table. The value of nmn_points_in_qp_tablc_minus1[i] should be in the range of 0 to 63 + QpBdOffset (inclusive). When 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.

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

[0163] delta_qp_diff_val[i][j] specifies the increment value used to derive the output coordinates of the j-th pivot point of the i-th chroma QP map. When delta_qp_out_val[0][j] does not exist in the bitstream, the value of delta_qp_out_val[0][j] is inferred to be 0.

[0164] The i-th chroma QP mapping table ChromaQpTable[i] is derived as follows, where i = 0..same_qp_table_for_chroma? 0 : 2: 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.

[0165] 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..same_qp_table_for_chroma ? 0:2 and j = 0..num_points_in_qp_table_minus1[i]+1.

[0166] `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.

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

[0168] `sps_trans_form_skip_enabled_flag` equal to 1 indicates that the `transform_skip_flag` is allowed in the transformation unit syntax, while `sps_transform_skip_enabled_flag` equal to 0 indicates that the `transform_skip_flag` is not allowed in the transformation unit syntax. 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.

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

[0170] `sps_ref_wraparound_enablcd_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.

[0171] 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_samplcs / MinCbSizeY) - 1 (inclusive), where `pic_width_in_luma_samples` is the value of `pic_width_in_luma_samples` in any PPS referencing SPS.

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

[0173] `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.

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

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

[0176] `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.

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

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

[0179] `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.

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

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

[0182] 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_inrl_enabled_flag indicates that intra-prediction with multiple reference lines is disabled.

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

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

[0185] `sps_cclm_colocated_chroma_flag` equal to 1 specifies that the left and top-left sampled luminance samples in the intra-frame prediction of the cross-component linear model are co-located with the top-left luminance sample. `sps_cclm_colocatcd_chroma_flag` equal to 0 specifies that the left and top-left sampled luminance samples in the intra-frame prediction of the cross-component linear model are horizontally co-located with the top-left luminance sample, but vertically shifted by 0.5 luminance sample units relative to the top-left luminance sample.

[0186] `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.

[0187] A value of 1 for `sps_explicit_mts_intra_enabled_flag` indicates that `mtsidx` may exist in the intra-coding unit syntax, while a value of 0 for `sps_explicit_mts_intra_enabled_flag` indicates that `mts idx` does not exist in the intra-coding unit syntax. If it does not exist, the value of `sps_explicit_mts_intra_enabled_flag` is presumed to be 0.

[0188] A value of 1 for `sps_explicit_mts_inter_enabled_flag` indicates that `mts_idx` may exist in the inter-frame coding unit syntax, while 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. If `mts_idx` does not exist, it is assumed that the value of `sps_explicit_mts_inter_enabled_flag` is 0.

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

[0190] `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.

[0191] `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.

[0192] `sps_affine_amvr_enabled_flag` equal to 1 specifies that adaptive motion vector difference resolution is used in motion vector coding in affine inter-frame mode. `sps_affinc_amvr_enabled_flag` equal to 0 specifies that adaptive motion vector difference resolution is not used in motion vector coding in affine inter-frame mode.

[0193] `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 (`sps_affine_prof_enabled_flag` equals 1), optical flow can be applied to correct affine motion compensation. When it does not exist, it is assumed that the value of `sps_affine_prof_enabled_flag` is 0.

[0194] `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.

[0195] `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.

[0196] `sps_act_enabled_flag` specifies whether adaptive color transformation is enabled. If `sps_act_enabled_flag` equals 1, adaptive color transformation can be used, and the flag `cu_act_enabled_flag` can exist in the coding unit syntax. If `sps_act_enabled_flag` equals 0, adaptive color transformation is not used, and `cu_act_enabled_flag` does not exist in the coding unit syntax. When `sps_act_enabled_flag` does not exist, it is inferred that it is equal to 0.

[0197] `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.

[0198] `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.

[0199] `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.

[0200] `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.

[0201] `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.

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

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

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

[0205] Increasing 1 to sps_rium_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).

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

[0207] 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 0 to 63 (inclusive).

[0208] `sps_ladf_delta_threshold_minus1[i]` is used to calculate the value of `SpsLadfIntervalLowerBound[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. BitDep,h - Within the range of 3 (inclusive).

[0209] Set the value of SpsLadfIntervalLowerBound[0] to 0.

[0210] For each value of i in the range of 0 to sps_num_ladf_intervals_minus2 (inclusive), the variable SpsLadfIntervalLowerBound[i ​​+ 1] is derived as follows: SpsLadfIntervalLowerBound[ i + 1 ] = SpsLadfIntcivalLowcrBound[ i ]+sps_ladf_delta_threshold_minus1 [ i] + 1 A value of 1 for `sps_scalirig_list_enabled_flag` specifies that the scaling list is used in the scaling process of the transform coefficients. A value of 0 for `sps_scaling_list_enabled_flag` specifies that the scaling list is not used in the scaling process of the transform coefficients.

[0211] `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.

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

[0213] 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. sps_virtual_boundaries_pos_x[i] should be in the range of 1 to Ceil(pic_width_in_luma_samples ÷ 8) - 1 (inclusive).

[0214] sps_num_hor_virtual_boundaries specifies the number of sps_virtual_boundarics_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.

[0215] 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. sps_virtual_boundarics_pos_y[i] should be in the range of 1 to Ceil(pic_height_in_luma_samples ÷ 8) - 1 (inclusive).

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

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

[0218] When `sps_sub_layer_cpb_params_present_flag` equals 0, the HRD parameters for sublayer representations with TemporalId in the range of 0 to `sps_max_sub_layers_minus1 - 1` (inclusive) are inferred to be the same as the HRD parameters for sublayer representations with TemporalId equal to `sps_max_sub_layers_minus1`. These parameters include the HRD parameters from the `fixed_pic_rate_gencral_flag[i]` syntax element up to the `sub_layer_hrd_parameters(i)` syntax structure under the condition "if(general_vcl_hrd_params_present_flag)" immediately following the `ols_hrd_parameters` syntax structure.

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

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

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

[0222] As shown in Table 2, the NAL unit may include a picture parameter set syntax structure. Table 4 shows the picture parameter set syntax structure provided in JVET-P2001.

[0223] Table 4 Regarding Table 4, JVET-P2001 provides the following semantics: 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.

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

[0225] The pps_pic_parameter_set_id identifies PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id should be in the range of 0 to 63 (inclusive).

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

[0227] `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.

[0228] `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`.

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

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

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

[0232] Let refPicWidthlnLumaSamples and refPicHeightlnLumaSamples 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: - pic_width_in_luma_samples*2 should be greater than or equal to refPicWidthlnLumaSamples.

[0233] - pic_height_in_luma_samples*2 should be greater than or equal to refPicHeightlnLumaSamples.

[0234] - pic_width_in_luma_samples should be less than or equal to refPicWidthlnLumaSamples*8.

[0235] - pic_height_in_luma_samples should be less than or equal to refPicHeightlnLumaSamples*8.

[0236] The variables PicWidthlnCtbsY, PicHeightlnCtbsY, PicSizelnCtbsY, PicWidthlnMinCbsY, PicHeightlnMinCbsY, PicSizelnMinCbsY, PicSizelnSamplesY, PicWidthlnSamplesC, and PicHeightlnSamplesC are derived as follows: PicWidthlnCtbsY = Ceil(pic_width_in_luma_samples + CtbSizeY) PicHeightlnCtbsY = Ceil(pic_height_in_luma_samples CtbSizeY) PicSizelnCtbsY = PicWidthlnCtbsY * PicHeightlnCtbsY PicWidthlnMinCbsY = pic_width_in_luma_samples / MinCbSizeY PicHeightlnMinCbsY = pic_height_in_luma_samplcs / MinCbSizeY PicSizelnMinCbsY = PicWidthlnMinCbsY * PicHeightlnMinCbsY PicSizelnSamplesY = pic_width_in_luma_samples * pic_height_in_luma_samples PicWidthlnSamplesC = pic_width_in_luma_samples / SubWidthC PicHeightlnSamplesC = pic_height_in_luma_samples / SubHeightC A conformance_window_flag value of 1 indicates that the clipping window offset parameter is immediately following the conformance_window_flag value in SPS. A conformance_window_flag value of 0 indicates that the clipping window offset parameter is not present.

[0237] `conf_win_left_offset`, `conf_win_right_offset`, `conf_win_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.

[0238] The fit-to-crop 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 (including end values) from SubHeightC * conf_win_top_offset to pic_height_in_luma_samples - (SubHeightC * conf_win_bottom_offset + 1).

[0239] The value of SubWidthC * (conf_win_left_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.

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

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

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

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

[0244] `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 luminance 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.

[0245] The value of SubWidthC * (scaling_win_left_offset + scaling_win_right_offset) should be less than pic_width_in_luma_samples, and the value of SubHeightC * (scaling vvin top offset + scaling vvin bottom offset) should be less than pic_height_inluma_samples.

[0246] The variables PicOutputWidthL and PicOutputHeightL are derived as follows: PicOutputWidthL = pic_width_in_luma_samples - SubWidthC * (scaling_win_right_offset + scaling_win_left_offset) PicOutputHeightL = pic_height_in_pic_size_units - SubHeightC * (scaling_win_bottom_offset + scaling_win_top_offset) output_fla g _ p A `resent_flag` value of 1 indicates that the `pic_output_flag` syntax element exists in the slice header referencing PPS. A `output_flag_present_flag` value of 0 indicates that the `pic_output_flag` syntax element does not exist in the slice header referencing PPS.

[0247] A mixed_nalu_types_in_pic_flag value of 1 indicates that each picture referencing PPS has more than one VCLNAL unit, and the VCLNAL 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 VCLNAL units, and the VCLNAL units of each picture referencing PPS have the same nal_unit_type value.

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

[0249] For each slice with a nal_unit_type value nalUnitTypeA from IDR_W_RADL to CRA_NUT (inclusive of end values), 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: - The slice should belong to the subpic A, and the corresponding sub_pic_treated_as_pic_flag[i] value is equal to I.

[0250] - A slice should not belong to a subpicture of a picA that contains a VCL NAL unit with a nal_unit_type that is not equal to nalUnitTypeA.

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

[0252] `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.

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

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

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

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

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

[0258] `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.

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

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

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

[0262] 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 `PicWidthlnCtbsY-1` (inclusive). When `no_pic_partition_flag` equals 1, it is inferred that the value of `num_exp_tile_columns_minus1` is 0.

[0263] 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 PicHeightlnCtbsY-1 (inclusive). When no_pic_partition_flag equals 1, the value of num_tile_rows_minus1 is inferred to be 0.

[0264] `tile_column_width_minus1[i]` plus 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 minus 1[0]` is inferred to be equal to `PicWidthlnCtbsY-1`.

[0265] `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 minus 1[num_exp_tile_rows_minus 1]` is used to derive the height of tile rows whose index is greater than or equal to `num_cxp_tile_rows_minus1` as specified. If it does not exist, the value of `tile row_height_minus1[0]` is inferred to be equal to `PicHeightlnCtbsY-1`.

[0266] 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 sent 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 sent in the PPS. If it does not exist, it is inferred that `rect_slice_flag` is equal to 1.

[0267] `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 be equal to 0. When `single_slice_per_subpice_flag` equals 1, it is inferred that `nnum_slices_in_pic_minus1` equals `sps_num_subpics_minus1`.

[0268] `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 in Annex A. When `no_pic_partition_flag` equals 1, it is inferred that the value of `num_slices_in_pic_minus1` is equal to 0.

[0269] A tile_idx_delta_present_flag value of 0 indicates that tile idx delta values ​​do not exist in the PPS, and all rectangular tiles in the image referencing the PPS are specified in raster order according to the defined process. A tile_idx_delta_present_flag value of 1 indicates that tile idx delta values ​​may exist in the PPS, and all rectangular tiles in the image referencing the PPS are specified in the order indicated by the tile_idx_delta values.

[0270] `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 specified.

[0271] `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 specified.

[0272] `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.

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

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

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

[0276] A `loop_filter_across_slices_enabled_flag` value of 1 indicates that in-loop filtering can be performed across slice boundaries in images referencing PPS. A `loop_filter_across_slice_enabled_flag` value of 0 indicates that in-loop filtering cannot be performed across slice boundaries in images referencing PPS. In-loop filtering operations include deblocking 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.

[0277] `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.

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

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

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

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

[0282] `init_qp_minus26` plus 26 specifies that for each slice `SliceQp` referencing `PPS`, the minimum value should be 26. Y The initial value. When decoding a non-zero value of slice_qp_delta, SliceQp Y The initial value is modified at the slice layer. The value of init_qp_minus26 should be in the range of -(26 + QpBdOffset) to +37 (inclusive).

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

[0284] If it does not exist, it is inferred that the value of Log2_transform_skip_max_size_minus2 is equal to 0.

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

[0286] cu _ qp _ delta _ enabled _ A flag of 1 indicates that the syntax elements pic_cu_qp_delta_subdiv_intra_slice and pic_cu_qp_delta_subdiv_inter_slice exist in the PH referencing PPS, and cu_qp_delta_abs can exist in the transformation unit syntax. A flag of cu_qp_delta_enabled_flag of 0 indicates that the syntax elements pic_cu_qp_delta_subdiv_intra_slice and pic_cu_qp_delta_subdiv_inter_slice do not exist in the PH referencing PPS, and cu_qp_delta_abs does not exist in the transformation unit syntax.

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

[0288] pps _ joint _ cbcr _ qp _ offset _ present _ A flag equal to 1 indicates that pps_joint_cbcr_qp_offset_value and joint_cbcr_qp_offset_list[i] exist in the PPS RBSP syntax structure. A flag equal to 0 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 equals 0 or sps_joint_cbcr_enabled_flag equals 0, pps _ The value of joint_cbcr_qp_offset_present_flag should be equal to 0.

[0289] pps _ joint _ cbcr _ qp _ offset _ The value specifies the value used to export 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 is not used during decoding. _ joint _ cbcr_ qp _ offset _ The value should be ignored by the decoder. When pps _ When 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.

[0290] pps _ slice _ chroma _ qp _ offsets _ present _ A flag of 1 indicates the presence of the `slice_cb_qp_offset` and `slice_cr_qp_offset` syntax elements in the associated slice header. A flag of 0 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.

[0291] cu _ chroma _ qp _ offset _ enabled _ A flag value of 1 indicates that `pic_cu_chroma_qp_offset_flag_intra_slice` and `pic_cu_chroma_qp_offset_flag_inter_slice` are allowed in the transform unit syntax; a flag value of 0 indicates that `pic_cu_chroma_qp_offset_flag_intra_slice` and `pic_cu_chroma_qp_offset_flag_inter_slice` are not allowed in the transform unit syntax. When `ChromaArrayType` is equal to 0, the bitstream compliance requirement is that the value of `cu_chroma_qp_offset_enabled_flag` should be 0.

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

[0293] cb _ qp _ offset _ list[i], cr_qp_offset_list[i], and joint_cbcr_qp_offset_list[i] respectively specify Qp' Cb Qp' Cr and Qp' CbCr The 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.

[0294] 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 sps_weighted_pred_flag is 0, the value of pps_weighted_pred_flag should be 0.

[0295] pps _ weighted _ bipred _ A flag of 0 specifies that no explicit weighted prediction is applied to B slices referencing PPS. _ weighted _ bipred _ A flag of 1 specifies that explicit weighted predictions are applied to B-slices referencing PPS. When sps_weighted_bipred_flag equals 0, PPS... _ weighted _bipred _ The value of flag should be equal to 0.

[0296] deblocking _ tllter _ control _ present _ A flag value of 1 indicates that a deblocking filter control syntax element exists in the PPS. A flag value of 0 indicates that a deblocking filter control syntax element does not exist in the PPS.

[0297] deblocking _ filter _ override _ enabled _ A flag value of 1 indicates that either the `pic_deblocking_filter_override_flag` exists in the PH (Program File Object) referencing PPS, or the `slice_deblocking_filter_override_flag` exists in the slice header referencing PPS. A flag value of 0 indicates that either the `pic_deblocking_filter_override_flag` does not exist in the PH referencing PPS, or the `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.

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

[0299] `pps_beta_offset_div2` and `pps_tc_offset_div2` specify the default unblocking parameter offsets (divided by 2) applied to the slice of the reference PPS, unless the default unblocking parameter offsets are overridden by unblocking parameter offsets present in the slice header of the slice of the reference 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 assumed to be equal to 0.

[0300] A constant_slice_header_params_enabled_flag value of 0 specifies that PPS should be inferred. _ dep _ quant _ enabled _ idc, pps_ref_pic_list_sps_idc[ i ], pps _ mvd _ l1 _ zero _ IDC, PPS _ collocated _ from_l0 _ idc, pps_six_minus_max_num_merge_cand_plus1 and pps _ max _ num _ merge _ cand_minus _ max _ num _ triangle _ cand _ plus1 equals 0. constant_slice_header_params _ enabled _ A flag value of 1 indicates that these syntax elements exist in PPS.

[0301] A value of 0 for pps_dep_quant_enabled_idc indicates that the syntax element pic_dep_quant_enabled_flag exists in the PH of PPS. _ dep _ quant _ enabled _An idc value of 1 or 2 indicates that the pic_dep_quant_enabled flag does not exist in the PH of the PPS reference. A PPS value of 3 is reserved. _ dep _ quant _ enabled _ IDC is intended for future use by ITU-T | ISO / IEC.

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

[0303] pps _ mvd_l1 _ zero _ An IDE value of 0 indicates that the PH reference to PPS contains the syntax element `mvd_l1_zero_flag`. _ mvd _ l1 _ A zero ide value of 1 or 2 indicates that the mvd_l1_zero_flag does not exist in the PH of the PPS reference. A value of 3, pps_mvd_l1_zero_idc, is reserved for future use by ITU-T | ISO / IEC.

[0304] A value of 0 for pps_collocated_from_10_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.

[0305] 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 for pps_six_minus_max_num_merge_cand_plus1 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).

[0306] 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 for `pps_max_num_merge_cand_minus_max_num_triangle_cand_plus1` 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).

[0307] picture _ header _ extension _ present _ A 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.

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

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

[0310] The `pps_cxtension_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 `pps_extension_data_flag` syntax elements.

[0311] As shown in Table 2, the NAL unit may include an image header syntax structure. Table 5 shows the image header syntax structure provided in JVET-P2001.

[0312] Table 5 Regarding Table 5, JVET-P2001 provides the following semantics: PH contains common information shared by all slices of the coded image associated with PH.

[0313] non _ reference _ picture _ A flag value of 1 indicates that a picture associated with a pH must never be used as a reference picture. A non_reference_picture_flag value of 0 indicates that a picture associated with a pH may or may not be used as a reference picture.

[0314] A gdr_pic_flag value of 1 indicates that the image associated with the PH is a GDR image. A gdr_pic_flag value of 0 indicates that the image associated with the PH is not a GDR image.

[0315] The `no_output_of_prior_pics_flag` flag affects the output of previously decoded images in the decoded image buffer that are not the first images in the bitstream and are subsequently decoded by CLVSS.

[0316] `recovery_poc_cnt` specifies the recovery point of the decoded images in the output order. If the current image is a GDR image associated with the PH, and there exists an image `picA` in CLVS that follows the current GDR image in the decoding order and has a `PicOrderCntVal` equal to the current GDR image's `PicOrderCntVal` plus the value of `recovery_point`, then image `picA` is called the recovery point image. Otherwise, the first image in the output order with a `PicOrderCntVal` greater than the current image's `PicOrderCntVal` plus `recovery_point` is called the recovery point image. The recovery point image should not precede the current GDR image in the decoding order. The value of `recovery_poc_cnt` should be in the range of 0 to `MaxPicOrderCntLsb - 1` (inclusive).

[0317] Note—When the gdr enabled flag is equal to 1 and the PicOrderCntVal of the current image is greater than or equal to the RpPicOrderCntVal of the associated GDR image, the current and subsequent decoded images arranged in output order are exactly matched with the corresponding images generated by starting the decoding process from the previous IRAP image (if present) before the associated GDR image arranged in decoding order.

[0318] ph _ pic _ parameter _ set _ The `id` field specifies the value of `pps_pic_parameter_set_id` for the PPS being used. The value of `ph_pic_parameter_set_id` should be in the range of 0 to 63 (inclusive).

[0319] The bitstream compliance requirement is that the TemporalId value of PH should be greater than or equal to the TemporalId value of PPS, which has a pps_pic_parameter_set_id equal to ph_pic_parameter_set_id.

[0320] `ph_poc_msb_present_flag` equal to 1 indicates that the syntax element `poc_msb_val` exists in the PH. `ph_poc_msb_present_flag` equal to 0 indicates that the syntax element `poc_msb_val` does not exist in the PH. The value of `ph_poc_msb_present_flag` should be 0 when `vps_indcpciidcnt_laver_flag[GeneralLayerIdx[ nuh layer id ] ]` equals 0 and an image from the current AU exists in the reference layer of the current layer.

[0321] poc_msb_val specifies the POC MSB value of the current image. The length of the syntax element poc_msb_val is poc_msb_len_minus1 + 1 bits.

[0322] ph _ subpic _ id _ signalling _ present _ A flag of 1 indicates that a signal is sent in the PH to notify the subpic ID mapping. A flag of 0 indicates that a signal is not sent in the PH to notify the subpic ID mapping.

[0323] The increment of 1 in ph_subpic_id_len_minus1 specifies the number of bits used to represent the syntax element ph_subpic_id[i]. The value of pic_subpic_id_len_minus1 should be in the range of 0 to 15 (inclusive).

[0324] For bitstream compliance requirements, the value of ph_subpic_id_len_minus1 should be the same for all PHs referenced by encoded pictures within CLVS.

[0325] `ph_subpic_id[i]` specifies the subpick ID of the i-th subpick. The length of the `ph_subpic_id[i]` syntax element is the number of pics. _ subpicid _ len _ minus1 + 1 bit.

[0326] The list SubpicldList[i] is exported as follows: `ph_loop_filter_across_virtual_boundaries_disabled_present_flag` equal to 1 specifies that in-loop filtering operations are disabled on virtual boundaries in the image associated with `PH`. `ph_loop_filter_across_virtual_boundarics_disabled_present_flag` equal to 0 specifies that this type of disabling of in-loop filtering operations is not applied in the image associated with `PH`. In-loop filtering operations include unblocking filters, sample adaptive offset filters, and adaptive loop filter operations. When not present, it is inferred that the value of `ph_loop_filter_across_virtual_boundaries_disabled_present_flag` is equal to 0.

[0327] The parameter VirtualBoundariesDisabledFlag is exported as follows: ph_num_ver_virtual_boundaries specifies the number of ph_virtual_boundaries_pos_x[i] syntax elements present in PH. If ph_num_ver_virtual_boundaries does not exist, it is inferred to be equal to 0.

[0328] The parameter VirtualBoundariesNumVer is exported as follows: ph_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. ph_virtual_boundaries_pos_x[i] should be in the range of 1 to Ceil(pic_width_in_luma_samples ÷ 8) - 1 (inclusive).

[0329] The position of the vertical virtual boundary, VirtualBoundariesPosX[i], is derived as follows: The distance between any two vertical virtual boundaries should be greater than or equal to CtbSizeY luminance samples.

[0330] ph _ num _ ver _virtual _ The boundaries specify the number of ph_virtual_boundaries_pos_y[i] syntax elements present in PH. When ph_num_hor_virtual_boundaries does not exist, it is inferred to be equal to 0.

[0331] The parameter VirtualBoundariesNumHor is exported as follows: ph_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. ph_virtual_boundaries_pos_y[i] should be in the range of 1 to Ceil(pic_height_in_luma_samples ÷ 8) - 1 (inclusive).

[0332] The position of the horizontal virtual boundary, VirtualBoundariesPosY[i], is derived as follows: The distance between any two horizontal virtual boundaries should be greater than or equal to CtbSizeY luminance samples.

[0333] When separate_colour_plane_flag equals 1, colour_plane_id specifies the color plane associated with the slice associated with PH. The value of colour_plane_id should be in the range of 0 to 2 (inclusive). colour_plane_id values ​​0, 1, and 2 correspond to the Y, Cb, and Cr planes, respectively.

[0334] Note—There is no correlation between the decoding processes of images with different colour_plane_id values.

[0335] The `pic_output_flag` flag influences the decoded image output and removal process. If `pic_output_flag` does not exist, it is assumed to be equal to 1.

[0336] A value of 1 for `pic_rpl_present_flag` indicates that a reference picture list signaling exists in the PH. A value of 0 for `pic_rpl_present_flag` indicates that a reference picture list signaling does not exist in the PH, and that the reference picture list signaling may exist in the slice header of a slice of the picture.

[0337] For bitstream compliance requirements, the value of pic_rpl_present_flag should be equal to 0 when sps_id_rpl_present_flag is equal to 0 and the image associated with PH is an IDR image.

[0338] `pic_rpl_sps_flag[i]` equal to 1 specifies that a list of reference images `i` is derived from one of the `ref_pic_list_struct(listIdx, rplsIdx)` syntax structures in SPS (where `listIdx` equals `i`). `ref_pic_list_sps_flag[i]` equal to 0 specifies that a list of reference images `i` is derived from the `ref_pic_list_struct(listIdx, rplsIdx)` syntax structure directly included in the PH (where `listIdx` equals `i`).

[0339] The following applies when pic_rpl_sps_flag[i] does not exist: - If num_ref_pic_lists_in_sps[i] equals 0, it is inferred that the value of pic_rpl_sps_flag[i] is equal to 0.

[0340] - Otherwise, if num_ref_pic_lists_in_sps[i] is greater than 0 and rpll_idx_present_flag is equal to 0, it is inferred that the value of pic_rpl_sps_flag[1] is equal to pic_rpl_sps_flag[0].

[0341] - Otherwise, infer that the value of pic_rpl_sps_flag[i] is equal to pps_ref_pic_list_sps_idc[i]-1.

[0342] `pic_rpl_idx[i]` specifies the index of the list of `ref_pic_list_struct(listIdx, rplsIdx)` syntax structures (where `listIdx` equals `i`) included in the SPS for the reference image list `i` used to derive the current image. The syntax element `pic_rpl_idx[i]` is represented by the `Ceil(Log2(num_ref_pic_lists_in_sps[i]))` bits. If it does not exist, the value of `pic_rpl_idx[i]` is inferred to be 0. The value of `pic_rpl_idx[i]` should be in the range of 0 to `num_ref_pic_lists_in_sps[i] - 1` (inclusive). When pic_rpl_sps_flag[i] equals 1 and num_ref_pic_lists_in_sps[i] equals 1, it is inferred that the value of pic_rpl_idx[i] is 0. When pic_rpl_sps_flag[i] equals 1 and rpl1_idx_present_flag equals 0, it is inferred that the value of pic_rpl_idx[1] is pic_rpl_idx[0].

[0343] The variable PicRplsIdx[i] is derived as follows: PicRplsIdx[ i ] = pic_rpl_sps_flag[ i ]? pic_rpl_idx[ i ] : num_ref_pic_lists_in_sps[ i ] pic_poc_lsb_lt[i][j] specifies the picture order count modulo MaxPicOrderCntLsb of the j-th LTRP entry in the i-th reference picture list associated with the PH. The length of the pic_poc_lsb_lt[i][j] syntax element is Log2_max_pic_order_ent_Isb minus4 + 4 bits.

[0344] The variable PicPocLsbLt[i][j] is derived as follows: The flag[i][j] equal to 1 indicates the existence of pic_delta_poc_msb cycle It[i][j]. The flag[i][j] equal to 0 indicates the non-existence of pic_delta_poc_msb_cyclc_lt[i][j].

[0345] Let `prevTidOPic` be the previous image in the decoding order, which has the same `nuh_layer_id` as `PH`, a `TemporalId` equal to 0, and is not a RASL or RADL image. Let `setOfPrevPocVals` be a set consisting of the following: - prevTidOPic of PicOrderCntVal - The PicOrderCntVal of each image referenced by an entry in RefPicList[0] or RefPicList[1] of prevTid0Pic and having the same nuh_layer_id as the current image. - The PicOrderCntVal of each image that follows prevTidOPic in the decoding order, has the same nuh_layer_id as the current image, and precedes the current image in the decoding order.

[0346] When there is more than one value in setOfPrevPocVals, the modulus of that value MaxPicOrderCntLsb is equal to PicPocLsbLt[i][j], and the value of pic_delta_poc_msb_present_flag[i][j] should be equal to 1.

[0347] pic_delta_poc_msb_cycle_lt[i][j] specifies the value of PicFullPocLt[i][j] as follows: The value of pic_delta_poc_msb_cycle_lt[i][j] should be between 0 and 2. (32 -log2_max_pic_order_cnt_lsb_minus4-4) Within the range (including the end value). When it does not exist, the value of pic_delta_poc_msb_cycle_lt[i][j] is inferred to be equal to 0.

[0348] A partition_constraints_override_flag value of 1 indicates that partition constraint parameters exist in the partition property (PH). A partition_constraints_override_flag value of 0 indicates that partition constraint parameters do not exist in the PH. When they do not exist, it is inferred that the value of partition_constraints_override_flag is equal to 0.

[0349] `pic_log2_diff_min_qt_min_cb_intra_slice_luma` specifies the base-2 logarithm of the smallest size in the luminance samples of 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) associated with PH. The value of `pic_Log2_diff_min_qt_min_cb_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). If it does not exist, it is inferred that the value of `pic_log2_diff_min_qt_min_cb_luma` is equal to `sps_Log2_diff_min_qt_min_cb_intra_slice_luma`.

[0350] `pic_log2_diff_min_qt_min_cb_inter_slice` specifies the base-2 logarithm of the smallest size of the luminance sample in the luminance blade block generated by quadtree segmentation of the CTU, and the base-2 logarithm of the smallest luminance coded block size in the luminance sample of the luminance CU in the slice with slice_type equal to 0 (B) or 1 (P) associated with PH. The value of `pic_log2_diff_min_qt_min_cb_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). When it does not exist, it is inferred that the value of `pic_log2_diff_min_qt_min_cb_luma` is equal to `sps_log2_diff_min_qt_min_cb_inter_slice`.

[0351] `pic_max_mtt_hierarchy_deptli_inter_slice` specifies the maximum hierarchical depth of coding units produced by multi-type tree segmentation of quadrangular leaves in slices with a slice_type of 0 (B) or 1 (P) associated with PH. The value of `pic_max_mtt_hierarchy_depth_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). If it does not exist, it is inferred that the value of `pic_max_mtt_hierarchy_depth_inter_slice` is equal to `sps_max_mtt_hierarchy_depth_inter_slice`.

[0352] `pic_max_mtt_hierarchy_depth_intra_slice_luma` specifies the maximum hierarchical depth of coding units resulting from multi-type tree segmentation of quadrangular leaves in slices with a slice_type of 2 (I) associated with PH. The value of `pic_max_mtt_hierarchy_depth_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). If it does not exist, the value of `pic_max_mtt_hierarchy_depth_intra_slice_luma` is inferred to be equal to `sps_max_mtt_hierarchy_depth_intra_slice_luma`.

[0353] `pic_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-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 `slice_type` equal to 2(I) associated with `PH`. The value of `pic_Log2_diff_max_bt_min_qt_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeTntraY` (inclusive). If it does not exist, the value of `pic_log2_diff_max_bt_min_qt_intra_slice_luma` is inferred to be equal to `sps_log2_diff_max_bt_min_qt_intra_slice_luma`.

[0354] `pic_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 the 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 2(I) associated with `PH`. The value of `pic_log2_diff_max_tt_min_qt_intra_slice_luma` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeIntraY` (inclusive).

[0355] If it does not exist, it is inferred that the value of pic_log2_diff_max_tt_min_qt_intra_slice_luma is equal to that of sps_log2_diff_max_tt_min_qt_intra_slice_luma.

[0356] `pic_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 of 0 (B) or 1 (P) associated with PH. The value of `pic_log2_diff_max_bt_min_qt_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeInterY` (inclusive). If it does not exist, it is inferred that the value of `pic_log2_diff_max_bt_min_qt_inter_slice` is equal to `sps_log2_diff_max_bt_min_qt_inter_slice`.

[0357] `pic_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 samples in a luminance blade block resulting from quadtree partitioning of the CTU in a slice with a slice_type of 0 (B) or 1 (P) associated with PH. The value of `pic_log2_diff_max_tt_min_qt_inter_slice` should be in the range of 0 to `CtbLog2SizeY - MinQtLog2SizeInterY` (inclusive). If it does not exist, it is inferred that the value of `pic_log2_diff_max_tt_min_qt_inter_slice` is equal to `sps_log2_diff_max_tt_min_qt_inter_slice`.

[0358] `pic_log2_diff_min_qt_min_cb_intra_slice_chroma` specifies the base-2 logarithm 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 `DUALTREE_CHROMA`, and the base-2 logarithm of the smallest code block size in the luminance samples of the chroma CU with `treeType` equal to `DUAL_TREE_CHROMA` in slices with `slice type` equal to 2(I) associated with `PH`. The value of `pic_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, it is inferred that the value of `pic_log2_diff_min_qt_min_cb_intra_slice_chroma` is equal to `sps_log2_diff_min_qt_min_cb_intra_slice_chroma`.

[0359] `pic_max_mtt_hierarchy_depth_intra_slice_chroma` specifies the maximum hierarchical depth of chroma coding units produced by multi-type tree segmentation of chroma quadtree leaves with `treeType` equal to `DUAL TREE CHROMA` in slices with `slice_type` equal to 2 (I) associated with `PH`. The value of `pic_max_mtt_hierarchy_depth_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizeY - MinCbLog2SizeY` (inclusive). If it does not exist, the value of `pic_max_mtt_hierarchy_depth_intra_slice_chroma` is inferred to be equal to `sps_max_mtt_hierarchy_depth_intra_slice_chroma`.

[0360] `pic_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-divided, and the base-2 logarithm of the minimum size (width or height) of the luminance samples of a chroma leaf block resulting from quadtree partitioning of a chroma CTU with `slice_type` equal to 2(I) associated with `PH`. The value of `pic_log2_diff_max_bt_min_qt_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizeY -MinQtLog2SizeTntraC` (inclusive). When it does not exist, it is inferred that the value of pic_log2_diff_max_bt_min_qt_intra_slice_chroma is equal to that of sps_log2_diff_max_bt_min_qt_intra_slice_chroma.

[0361] `pic_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 of a chroma-coded block that can be segmented using ternary partitioning, and the base-2 logarithm of the minimum size (width or height) of the luminance samples of a chroma leaf block resulting from quadtree partitioning of a chroma CTU with `treeType` equal to `DUAL_TREE_CHROMA` in a slice with `slice_type` equal to 2(I) associated with `PH`. The value of `pic_log2_diff_max_tt_min_qt_intra_slice_chroma` should be in the range of 0 to `CtbLog2SizcY -MinQtLog2SizcIntraC` (inclusive). When it does not exist, it is inferred that the value of pic_log2_diff_max_tt_min_qt intra_slice_chroma is equal to that of sps_log2_diff_max_tt_min_qt_intra_slice_chroma. `pic_cu_qp_delta_subdiv_intra_slice` specifies the maximum `cbSubdiv` value of the coding unit for the intra-slice that transmits `cu_qp_delta_abs` and `cu_qp_delta_sign_flag`. The value of `pic_cu_qp_delta_subdiv_intra_slice` should be in the range of 0 to 2 * (QbLog2SizeY - MinQtLog2SizeIntraY + pic_max_mtt_hierarchy_depth_intra_slice_luma) (inclusive).

[0362] If it does not exist, it is inferred that the value of pic_cu_qp_delta_subdiv_intra_slice is equal to 0.

[0363] `pic_cu_qp_delta_subdiv_inter_slice` specifies the maximum `cbSubdiv` value of the coding unit in the inter-slice that transmits `cu_qp_delta_abs` and `cu_qp_delta_sign_flag`. The value of `pic_cu_qp_delta_subdiv_inter_slice` should be in the range of 0 to 2 * (CtbLog2SizeY - MinQtLog2SizeInterY + pic_max_mtt_hierarchy_depth_inter_slice) (inclusive).

[0364] If it does not exist, it is inferred that the value of pic_cu_qp_delta_subdiv_inter_slice is equal to 0.

[0365] `pic_cu_chroma_qp_offset_subdiv_intra_slice` specifies the maximum `cbSubdiv` value for the coding unit of the intra-slice that transmits `cu_cliroma_qp_offset_flag`. The value of `pic_cu_chroma_qp_offset_subdiv_intra_slice` should be in the range of 0 to 2 * (CtbLog2SizeY - MinQtLog2SizelntraY + pic_max_mtt_hierarchy_depth_intra_slice_luma) (inclusive).

[0366] If it does not exist, it is inferred that the value of pic_cu_chroma_qp_offset_subdiv_intra_slice is equal to 0.

[0367] `pic_cu_chroma_qp_offset_subdiv_inter_slice` specifies the maximum `cbSubdiv` value for the coded unit in the inter-slice that transmits the `cu chroma qp offset flag`. The value of `pic_cu_chroma_qp_offset_subdiv_inter_slice` should be in the range of 0 to 2 * (CtbLog2SizeY - MinQtLog2SizeInterY + pic_max_mtt_hierarchy_depth_inter_slice) (inclusive).

[0368] If it does not exist, it is inferred that the value of pic_cu_chroma_qp_offset_subdiv_inter_slice is equal to 0.

[0369] `pic_temporal_mvp_enabled_flag` specifies whether the temporal motion vector predictor can be used for inter-frame prediction of slices associated with the PH. If `pic_temporal_mvp_enabled_flag` equals 0, the syntax elements of the slices associated with the PH should be constrained so that the temporal motion vector predictor is not used in the decoding of the slices. Otherwise (if `pic_temporal_mvp_enabled_flag` equals 1), the temporal motion vector predictor can be used in the decoding of slices associated with the PH. When it does not exist, the value of `pic_temporal_mvp_enabled_flag` is assumed to be 0.

[0370] A value of 1 for `mvd_l1_zero_flag` indicates that the `mvd_coding(x0, y0, 1)` syntax structure was not parsed, and for `compIdx = 0.. 1` and `cpIdx = 0.. 2`, `MvdL1[x0][y0][compIdx]` and `MvdL1[x0][y0][cpIdx][compIdx]` are set to 0. A value of 0 for `mvd_l1_zero_flag` indicates that the `tliemvd_coding(xO, yO, 1)` syntax structure has been parsed. When it does not exist, the value of `mvd_l1_zero_flag` is inferred to be equal to `pps_mvdl1_zero_ide-1`.

[0371] `pic_six_minus_max_num_merge_cand` specifies the maximum number of merged motion vector prediction (MVP) candidates supported from the slices associated with the PH, subtracted from 6. The maximum number of merged MVP candidates, `MaxNumMergeCand`, is derived as follows: MaxNumMergeCand = 6 - picsix_minus_max_num_merge_cand The value of MaxNumMergeCand should be in the range of 1 to 6 (inclusive). If it does not exist, the value of pic_six_minus_max_num_merge_cand is inferred to be equal to pps_six_minus_max_num_merge_cand_plus1 - 1.

[0372] `pic_five_minus_max_num_subblock_merge_cand` specifies the maximum number of subblock-based merged motion vector prediction (MVP) candidates supported in the slice, minus 5. If it does not exist, the inferred value of `pic_five_minus_max_num_subblock_merge_cand` is equal to 5 - (sps_sbtmvp_enabled_flag && pic_temporal_mvp_enabled_flag).

[0373] The maximum number of MVP candidates based on sub-blocks, MaxNumSubblockMergeCand, is derived as follows: MaxNumSubblockMergeCand = 5 - pic_five_minus_max_num_subblock_merge_cand The value of MaxNumSubblockMergeCand should be in the range of 0 to 5 (inclusive).

[0374] `pic_fpel_mmvd_enabled_flag` equal to 1 specifies that the merge mode with motion vector differences in slices associated with PH uses integer sample precision. `pic_fpel_mmvd_enabled_flag` equal to 0 specifies that the merge mode with motion vector differences in slices associated with PH can use fractional sample precision. When it does not exist, the value of `pic_fpel_mmvd_enabled_flag` is inferred to be 0.

[0375] `pic_disable_bdof_flag` equal to 1 specifies that inter-frame dual prediction based on bidirectional optical flow inter-frame prediction is disabled in slices associated with PH. `pic_disable_bdofflag` equal to 0 specifies that inter-frame dual prediction based on bidirectional optical flow inter-frame prediction may or may not be enabled in slices associated with PH.

[0376] The following applies when pic_disable_bdof_flag does not exist: - If sps_bdof_enabled_flag equals 1, then it is inferred that pic_disable_bdof_flag equals 0.

[0377] - Otherwise (sps_bdof_enabled_flag equals 0), infer that the value of pic_disable_bdof_flag is equal to 1.

[0378] `pic_disable_dmvr_flag` equal to 1 specifies that inter-frame double prediction based on decoder motion vector correction is disabled in the slice associated with the PH. `pic_disabled_mvr_flag` equal to 0 specifies that inter-frame double prediction based on decoder motion vector correction may or may not be enabled in the slice associated with the PH. When it does not exist, the value of `pic_disable_dmvr_flag` is inferred to be 1.

[0379] The following applies when pic_disable_dmvr_flag is not present: - If sps_dmvr_enabled_flag equals 1, it is inferred that the value of pic_disable_dmvr_flag is equal to 0.

[0380] - Otherwise, if (sps_dmvr_enabled_flag) is equal to 0, it is inferred that the value of pic_disable_dmvr_flag is equal to 1.

[0381] A `pic_disable_prof_flag` value of 1 indicates that prediction corrections using optical flow are disabled in slices associated with pH. A `pic_disable_prof_flag` value of 0 indicates that prediction corrections using optical flow may or may not be enabled in slices associated with pH. When it does not exist, the value of `pic_disable_prof_flag` is assumed to be 1.

[0382] The following applies when pic_disable_prof_flag is not present: - If sps_affme_prof_enabled_flag equals 1, it is inferred that the value of pic_disable_prof_flag is equal to 0.

[0383] - Otherwise (sps_affine_prof_enabled_flag equals 0), infer that the value of pic_disable_prof_flag is equal to 1.

[0384] pic_max_num_merge_cand_minus_max_num_triangle_cand specifies the maximum number of supported triangle merge pattern candidates from the slice associated with the image header, minus MaxNumMergeCand.

[0385] When pic_max_num_merge_cand_minus_max_num_triangle_cand does not exist, and sps_triangle_enabled_flag is equal to 1 and MaxNumMergeCand is greater than or equal to 2, it is inferred that pic_max_num_merge_cand_minus_max_num_triangle_cand is equal to pps_max_num_merge_cand_minus_max_num_triangle_cand plus 1 - 1.

[0386] The maximum number of candidate triangle merge patterns, MaxNumTriangleMergeCand, is derived as follows: When pic_max_num_merge_cand_minus_max_num_triangle_cand exists, the value of MaxNumTriangleMergeCand should be in the range of 2 to MaxNumMergeCand (inclusive).

[0387] MaxNumTriangleMergeCand is set to 0 when pic_max_num_merge_cand_minus_max_num_triangle_cand does not exist and (sps_triangle_enabled_flag is equal to 0 or MaxNumMergeCand is less than 2).

[0388] When MaxNumTriangleMergeCand equals 0, slices associated with PH are not allowed to use the triangular merge mode.

[0389] `pic_six_minus_max_num_ibc_merge_cand` specifies the maximum number of IBC merge block vector prediction (BVP) candidates supported from the slices associated with the PH, subtracted from 6. The maximum number of IBC merge BVP candidates, `MaxNumlbcMergeCand`, is derived as follows: MaxNumIbcMergeCand = 6 - pic_six_minus_max_num_ibc_merge_cand The value of MaxNumlbcMergeCand should be in the range of 1 to 6 (inclusive).

[0390] `pic_joint_cbcr_fagn_flag` specifies whether the co-position residual samples of the two chromaticity components have inverse signs in a transform unit with a `tuJointcbcrresidual flag[x0][y0]` equal to 1. When the transform unit's `tujoint_cbcr_residual_flag[x0][y0]` equals 1, `picjoint_cbcr_sign_flag` equals 0, indicating that the sign of each residual sample of the Cr (or Cb) component is the same as the sign of the co-position Cb (or Cr) residual sample, and `picjoint cbcr sign_flag` equals 1, indicating that the sign of each residual sample of the Cr (or Cb) component is the inverse sign of the co-position Cb (or Cr) residual sample.

[0391] A value of 1 for `pic_sao_enabled_present_flag` indicates that `pic_sao_luma_flag` and `pic_sao_chroma_flag` exist in `PH`. A value of 0 for `pic_sao_enabled_present_flag` indicates that `pic_sao_luma_flag` and `pic_sao_chroma_flag` do not exist in `PH`. When `pic_sao_enabled_present_flag` does not exist, it is inferred that its value is 0.

[0392] A value of 1 for `pic_sao_luma_flag` enables SAO for the luminance components in all slices associated with PH; a value of 0 for `pic_sao_luma_flag` disables SAO for the luminance components of one or more slices associated with PH. If `pic_sao_luma_flag` does not exist, it is assumed to be equal to 0.

[0393] A pic_sao_chroma_flag value of 1 indicates that SAO is enabled for the chromaticity components of all slices associated with PH; a pic_sao_chroma_flag value of 0 indicates that SAO is disabled for the chromaticity components of one or more slices associated with PH. If pic_sao_chroma_flag does not exist, it is inferred to be equal to 0.

[0394] A value of 1 for `pic_alf_enabled_present_flag` indicates that `pic_alf_enabled_flag`, `pic_num_alf_apsids_luma`, `pic_alf_aps_id_luma[i]`, `pic_alf_chroma_idc`, and `pic_alf_aps_id_chroma` exist in `PH`. A value of 0 for `pic_alf_enabled_present_flag` indicates that `pic_alf_enabled_flag`, `pic_num_alf_aps_ids_luma`, `pic_alf_aps_id_luma[i]`, `pic_alf_chroma_idc`, and `pic_alf_aps_id_chroma` do not exist in `PH`. If `pic_alf_enabled_present_flag` does not exist, it is inferred that it is equal to 0.

[0395] A `pic_alf_enabled_flag` value of 1 indicates that the adaptive loop filter is enabled for all slices associated with `PH`, and the adaptive loop filter can be applied to the Y, Cb, or Cr color components in the slice. A `pic_alf_enabled_flag` value of 0 indicates that the adaptive loop filter can be disabled for one or more or all slices associated with `PH`. If it does not exist, `pic_alf_enabled_flag` is presumed to be 0.

[0396] pic_num_alf_aps_ids_luma specifies the number of ALF APSs referenced by the slice associated with the PH.

[0397] pic_alf_aps_id_luma[i] specifies the adaptation_parameter_set_id of the i-th ALFAPS referenced by the luminance component of the slice associated with PH.

[0398] The value of the alf luma filter signal flag of the APS NAL unit, which has aps_params_type equal to ALF APS and adaptation_parameter_set_id equal to pic_alf_aps_id_luma[i], should be equal to 1.

[0399] A value of 0 for `pic_alf_chroma_idc` indicates that the adaptive loop filter is not applied to the Cb and Cr color components. A value of 1 for `pic_alf_chroma_idc` indicates that the adaptive loop filter is applied to the Cb color component. A value of 2 for `pic_alf_chroma_idc` indicates that the adaptive loop filter is applied to the Cr color component. A value of 3 for `pic_alf_chroma_idc` indicates that the adaptive loop filter is applied to both the Cb and Cr color components. If `pic_alf_chroma_idc` does not exist, it is inferred to be equal to 0.

[0400] pic_alf_aps_id_chroma specifies the adaptation_parameter_set_id of the ALF APS that the chromaticity component of the slice associated with PH is referenced.

[0401] The value of alf_chroma_filter_signal_flag for an APS NAL cell that has aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to pic_alf_aps_id_chroma should be equal to 1.

[0402] A value of 0 for `pic_dep_quant_enabled_flag` disables dependency quantization for slices associated with `PH`. A value of 1 for `pic_dep_quant_enabled_flag` enables dependency quantization for slices associated with `PH`. If `pic_dep_quant_enabled_flag` does not exist, the value of `pic_dep_quant_enabled_flag` is inferred to be equal to `pps_dep_quant_enable_idc` - 1.

[0403] A sign_data_hiding_enabled_flag value of 0 indicates that sign bit hiding is disabled. A sign_data_hiding_enabled_flag value of 1 indicates that sign bit hiding is enabled. If sign_data_hiding_enabled_flag does not exist, it is inferred that it is equal to 0.

[0404] A value of 1 for `pic_deblocking_filter_override_present_flag` indicates that `pic_deblocking_filter_override_flag` exists in the PH (Profile Environment). A value of 0 for `sps_subpic_id_present_flag` indicates that `pic_deblocking_filter_override_flag` does not exist in the PH. When `pic_dcblocking_filter_override_present_flag` does not exist, it is inferred that its value is 0.

[0405] A value of 1 for `pic_deblocking_filter_override_flag` indicates the presence of unblocking parameters in the PH (Problem Detector). A value of 0 for `deblocking_filter_override_flag` indicates the absence of unblocking parameters in the PH. When the parameters are absent, it is assumed that the value of `pic_pic_deblocking_filter_override_flag` is 0.

[0406] A value of 1 for `pic_deblocking_filter_disabled_flag` indicates that the unblocking filter operation should not be applied to slices associated with the PH. A value of 0 for `pic_deblocking_filter_disabled_flag` indicates that the unblocking filter operation should be applied to slices associated with the PH. When `pic_deblocking_filter_disabled_flag` does not exist, it is inferred that it is equal to `pps_deblocking_filter_disabled_flag`.

[0407] `pic_beta_offset_div2` and `pic_tc_offset_div2` specify the unblocking parameter offsets (divided by 2) for the β and tC of the slice associated with PH. The values ​​of `pic_beta_offset_div2` and `pic_tc_offset_div2` should both be in the range of -6 to 6 (inclusive). When not present, the inferred values ​​of `pic_beta_offset_div2` and `pic_tc_offset_div2` are equal to `pps_beta_offset_div2` and `pps_tc_offset_div2`, respectively.

[0408] `pic_lmcs_enablcd_flag` equal to 1 specifies that luma mapping with chroma scaling is enabled for all slices associated with PH. `pic_lmcs_enabled_flag` equal to 0 specifies that luma mapping with chroma scaling can be disabled for one or more or all slices associated with PH. If it does not exist, the value of `pic_lmcs_enabled_flag` is inferred to be 0.

[0409] pic_lmcs_aps_id specifies the adaptation_parameter_set_id of the LMCS APS referenced by the slice associated with the PH. The TemporalId of the APS NAL cell with an APS params type equal to the LMCS APS and an adaptation_parameter_set_id equal to pic_hues_aps_id should be less than or equal to the TemporalId of the picture associated with the PH.

[0410] A pic_chroma_residual_scale_flag value of 1 indicates that chroma residual scaling is enabled for all slices associated with PH. A pic_chroma_residual_scale_flag value of 0 indicates that chroma residual scaling can be disabled for one or more or all slices associated with PH. If pic_chroma_residual_scale_flag does not exist, it is inferred to be equal to 0.

[0411] `pic_scaling_list_present_flag` equal to 1 specifies that the scaling list data for slices associated with the PH is derived based on the scaling list data contained in the reference scaling list APS. `pic_scaling_list_present_flag` equal to 0 specifies that the scaling list data for slices associated with the PH is the default scaling list data to be exported. When it does not exist, the value of `pic_scaling_list_present_flag` is presumed to be 0.

[0412] Pics_caling_list_apsid specifies the adaptation_parameter_set_id of the scaling list APS. The TemporalId of the APS NAL cell with an aps_params type equal to the SCALING APS and an adaptation_parameter_set_id equal to pic_scaling_list_aps_id should be less than or equal to the TemporalId of the picture associated with the PH.

[0413] `ph_extension_length` specifies the length of the ph extension data in bytes, excluding the bits used to signal the ph_extension_length itself. The value of `ph extension length` should be in the range of 0 to 256 (inclusive). If it does not exist, the value of `ph extension length` is assumed to be 0.

[0414] The `ph_extension_data_byte` parameter can have any value. Decoders conforming to this version of the specification should ignore the value of `phextensiondatabyte`. Its value does not affect the configuration file specified in this version of the specification for decoders conforming to this specification.

[0415] As shown in Table 2, a NAL unit can include coded slices of an image. The slice syntax structure includes the slice_header() syntax structure and the slice_data() syntax structure. Table 6 shows the syntax of the slice header provided in JVET-P2001.

[0416] Table 6 Regarding Table 6, JVET-P2001 provides the following semantics: When present, the value of the slice header syntax element slice_pic_order_cnt_lsb should be the same in all slice headers of the encoded image.

[0417] The variable CuQpDeltaVal, which specifies the difference between the luminance quantization parameter of the coding unit containing cu_qp_delta_abs and its prediction, is set to 0. This specifies the value of Qp' when determining the luminance quantization parameter of the coding unit containing cu_chroma_qp_offset_flag. Cb Qp' Cr and Qp' CbCr The variable CuQpOffset is used to determine the value of the quantized parameter. Cb CuQpOffset Cr and CuQpOffset CbCr All were set to 0.

[0418] `slice_pic_order_cnt_lsb` represents the image order count of the current image modulo `MaxPicOrderCntLsb`. The length of the `slice_pic_order_ent_lsb` syntax element is `log2_max_pic_order_ent_lsb_minus4 + 4 bits`. The value of `slice_pic_ordcr_cnt_lsb` should be in the range of 0 to `MaxPicOrderCntLsb-1` (inclusive).

[0419] When the current image is a GDR image, the variable RpPicOrderCntVal is exported as follows: RpPicOrderCntVal = PicOrderCntVal + recoverv_poc_cnt `slice_subpic_id` specifies the subpick identifier containing the slice's subpick. If `slicesubpic_id` exists, the value of the variable `SubPicIdx` is exported such that `SubpicIdList[SubPicIdx]` equals `slice_subpic_id`. Otherwise (if `slice_subpic_id` does not exist), the exported variable `SubPicIdx` equals 0. The length of `slice_subpic_id` (in bits) is exported as follows: - If the sps_subpic_id signalling present flag is equal to 1, then the length of slice_subpic_id is equal to sps_subpic_id_len_minus1 + 1.

[0420] - Otherwise, if ph_subpic_id_signalling_present_flag equals 1, the length of slice_subpic_id is equal to ph_subpic_id_len_minus1 + 1.

[0421] - Otherwise, if ph_subpic_id_signalling_present_flag equals 1, the length of slice_subpic_id is equal to pps_sub_pic_id_len_minus1 + 1.

[0422] - Otherwise, the length of slice_subpic_id is equal to Ceil(Log2 (sps_num_subpics_minus1 +1)).

[0423] The slice address specifies the address of the slice. If it does not exist, the value of the slice address is assumed to be 0.

[0424] If rect_slice_flag equals 0, then the following applies: - The slice address is the raster scan tile index.

[0425] - The length of the slice address is Ceil(Log2 (NumTilesInPic)) bits.

[0426] The value of slice_address should be in the range of 0 to NumTilesInPic-1 (inclusive).

[0427] Otherwise (rect_slice_flag equals 1), the following applies: - slice_address is the slice index of the slice within the SubPicIdx subgraph.

[0428] - The length of slice_address is Ceil(Log2(NumSlicesInSubpic[ SubPicIdx ])) bits.

[0429] - The value of slice_address should be in the range of 0 to NumSlicesInSubpic[ SubPicIdx ]-1 (inclusive).

[0430] The following constraints apply to bitstream compliance requirements: - If the rect slice flag is equal to 0 or the subpics_present_flag is equal to 0, then the slice address value should not be equal to the slice address value of any other coded slice NAL unit of the same coded picture.

[0431] Otherwise, the paired slice_subpic_id and slice_address values ​​should not be equal to the paired slice_subpic_id and slice_address values ​​of any other coded slice NAL unit of the same coded picture.

[0432] - When rect slice_flag equals 0, the slices of the image should be in ascending order of their slice address values.

[0433] - The shape of the slices of the image should be such that each CTU, 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 CTUs.

[0434] - For any two subpics subpicA and subpicB, when the index of subpicA is less than the index of subpicB, any encoded NAL unit of subpicA should be appended to any encoded NAL unit of subpicB in the decoding order.

[0435] - The shape of the sub-images of an image 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 boundary or the boundaries of the previously decoded sub-images.

[0436] Incrementing Num_tiles_in_slice_minus1 by 1, if present, specifies the number of tiles in the slice. The value of num tilesin slice minus1 should be in the range of 0 to NumTilesInPic-1 (inclusive).

[0437] The variable NumCtuInCurrSlice specifies the number of CTUs in the current slice, and the list CtbAddrInCurrSlice[i], where i is in the range of 0 to NumCtuInCurrSlice-1 (inclusive), specifies the raster scan address of the i-th CTB within the slice. These two are derived as follows: The variables SubPicLeftBoundaryPos, SubPicTopBoundaryPos, SubPicRightBoundaryPos, and SubPicBotBoundaryPos are derived as follows: slice_type specifies the encoding type of the slice according to Table 7.

[0438] Table 7 When nal_unit_type is a value in the range IDR_W_RADL to CRA_NUT (inclusive), and the current image is the first image in the accessed unit, slice_type should be equal to 2.

[0439] The variables MinQtLog2SizeY, MinQtLog2SizeC, MinQtSizeY, MinQtSizeC, MaxBtSizeY, MaxBtSizeC, MinBtSizeY, MaxTtSizeY, MaxTtSizeC, MinTtSizeY, MaxMttDepthY, and MaxMttDepthC are derived as follows: MinQtSizeY = 1<<MinQtLog2SizeY MinQtSizeC = 1<<MinQtLog2SizcC MinBtSizeY = 1<<MinCbLog2SizeY MinTtSizeY = 1<<MinCbLog2SizeY If slice_type is equal to 2 (I), MinQtLog2SizeY = MinCbLog2SizeY + pic_log2_diff_min_qt_min_cb_intra_slice_luma MinQtLog2SizcC = MinCbLog2SizcC + pic_log2_diff_min_qt_min_cb_intra_slice_chroma MaxBtSizeY = 1<<(MinQtLog2SizeY + pic_log2_diff_max_bt_min_qt_intra_slice_luma) MaxBtSizeC = 1<<(MinQtLog2SizeC + pic_log2_diff_max_bt_min_qt_intra_slice_chroma) MaxTtSizeY = 1<<(MinQfLog2SizeY + pic_log2_diff_max tt min qt intraslice luma) MaxTtSizeC = 1<<(MinQtLog2SizeC + pic_log2_diff_max_tt_min_qt_intra_slice_chroma) MaxMttDepthY = pic_max_mtt_hierarchy_depth_intra_slice_luma MaxMttDepthC = pic_max_mtt_hierarchy_depth_intra_slice_chroma CuQpDeltaSubdiv = pic_cu_qp_delta_subdivi_intra_slice CuChromaQpOffsetSubdiv = pic_cu_chroma_qp_offset_subdiv_intra_slice Otherwise (slice_type equals 0 (B) or 1 (P)), MinQtLog2SizeY = MinCbLog2SizeY + pic_log2_diff_min_qt_min_cb_inter_slice MinQtLog2SizeC = MinCbLog2SizeC + pic_log2_diff_min_qt_min_cb_inter_slice MaxBtSizeY = 1<<(MinQtLog2SizeY + pic_log2_diff_max_bt_min_qt_inter_slice) MaxBtSizeC = 1<<(MinQtLog2SizeC + pic_log2_diff_max_bt_min_qt_inter_slice) MaxTtSizeY = 1<<(MinQtLog2SizeY + pic_log2_diff_max_tt_min_qt_inter_slice) MaxTtSizeC = 1<<(MinQtLog2SizeC + pic_log2_diff_max_tt_min_qt_inter_slice) MaxMttDepthY = pic_max_mtt_hierarchy_depth_inter_slice MaxMttDepthC = pic_max_mtt_hierarchy_depth_inter_slice CuQpDeltaSubdiv = pic_cu_qp_delta_subdiv_inter_slice CuChromaQpOffsetSubdiv = pic_cu_chroma_qp_offset_subdiv_inter_slice `slice_rpl_sps_flag[i]` equal to 1 specifies that the list of reference pictures `i` for the current slice is derived based on one of the `ref_pic_list_struct(listIdx, rplsIdx)` syntax structures in SPS (where `listIdx` equals `i`). `slice_rpl_sps_flag[i]` equal to 0 specifies that the list of reference pictures `i` for the current slice is derived based on the `ref_pic_list_struct(listIdx, rplsIdx)` syntax structure (where `listIdx` equals `i`) directly included in the slice header of the current picture.

[0440] The following applies when slice_rpl_sps_flag[i] does not exist: - If pic_rpl_present_flag is equal to 1, it is inferred that the value of slice_rpl_sps_flag[i] is equal to pic_rpl_sps_flag[i].

[0441] - Otherwise, if num_ref_pic_lists_in_sps[i] equals 0, it is inferred that the value of ref_pic_list_sps_flag[i] is equal to 0.

[0442] - Otherwise, if num_ref_pic_lists_in_sps[i] is greater than 0 and rpl1_idx_present_flag is equal to 0, it is inferred that the value of slice_rpl_sps_flag[1] is equal to slice_rpl_sps_flag[0].

[0443] `slice_rpl_idx[i]` specifies the index of the list of `ref_pic_list_struct(listIdx, rplsIdx)` syntax structures (where `listIdx` equals `i`) included in the SPS for the reference picture list `i` used to derive the current picture. The syntax element `slice_rpl_idx[i]` is represented by the `Ceil(Log2(num_ref_pic_lists_in_sps[i]))` bits. If it does not exist, the value of `slice_rpl_idx[i]` is inferred to be 0. The value of `slice_rpl_idx[i]` should be in the range of 0 to `num_ref_pic_lists in sps[i] - 1` (inclusive). When slice_rpl_sps_flag[i] equals 1 and num_ref_pic_lists_in_sps[i] equals 1, it is inferred that the value of slice_rpl_idx[i] is 0. When slice_rpl_sps_flag[i] equals 1 and rpll_idx_present_flag equals 0, it is inferred that the value of slice_rpl_idx[1] is equal to slice_rpl_idx[0].

[0444] The variable RplsIdx[i] is derived as follows: if(pic_rpl_present_flag) RplsIdx[ i ] = PicRplsIdx[ i ] else RplsIdx[ i ] = slice_rpl_sps_flag[ i ]? slice_rpl_idx[ i ] : num_ref_pic_lists_in_sps[ i ] `sliee_poc_lsb_lt[i][j]` specifies the image order count modulo `MaxPicOrderCntLsb` for the j-th LTRP entry in the i-th reference image list. The length of the `slice_poc_lsb_lt[i][j]` syntax element is `Log2_max_pic_order_cnt_lsb_mmus4 + 4` bits.

[0445] The variable PocLsbLt[i][j] is derived as follows: if(pic_rpl_present_flag) PocLsbLt[ i ][j ] = PocLsbLt[ i ][j ] else PocLsbLt[ i ][j ]= Itrp in slice header flag[ i ][Rplsldx[i]]? slice_poc_lsb_lt[ i ][ j ]: rpls_poc_lsb_lt[ listIdx ][ RplsIdx[ i]][j ] A value of 1 for slice_delta_pocmsb_present_flag[i][j] indicates that slice_delta_poc_msb_cycle_lt[i][j] exists.

[0446] If slice_delta_poc_msb_present_flag[i][j] is equal to 0, it means that slice_delta_poc_msb_cycle_lt[i][j] does not exist.

[0447] Let `prevTid0Pic` be the previous image in the decoding order, which has the same `nuh_layer_id` as the current image, has a `TemporalId` equal to 0, and is not a RASL or RADL image. Let `setOfPrevPocVals` be a set consisting of the following: - prevTidOPic of PicOrderCntVal - The PicOrderCntVal of each image referenced by an entry in RefPicList[0] or RefPicList[1] of prevTid0Pic and having the same nuh_layer_id as the current image. - The PicOrderCntVal of each image that follows prevTid0Pic in the decoding order, has the same nuh_layer_id as the current image, and precedes the current image in the decoding order.

[0448] When pic_rpl_present_flag equals 0 and there is more than one value in setOfPrevPocVals, the modulus of this value MaxPicOrderCntLsb equals PocLsbLt[i][j], and the value of slice_delta_poe_msb_presentflag[i][j] should be equal to 1.

[0449] slice_delta_poc_msb_cycle_lt[i][j] specifies the value of FullPocLt[i][j] as follows: The value of slice_delta_poc_msb_cycle_lt[i][j] should be between 0 and 2. (32 -log2 max pic order cnl lsb minus4-4) Within the range (including the end value). When it does not exist, it is inferred that the value of slice_delta_poc_msb_cycle_lt[i][j] is equal to 0.

[0450] A value of 1 for Num_ref_idx_active_override_flag indicates that the syntax element num_ref_idx_active_minus1[0] exists for slices P and B, and that the syntax element num_ref_idx_active_minus1[1] exists for slice B. A value of 0 for num_ref_idx_active_override_flag indicates that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] do not exist. When they do not exist, it is inferred that the value of num_ref_idx_active_override_flag is equal to 1.

[0451] num_ref_idx_active_minus1[i] is used to derive the variable NumRefIdx Active[i], as specified in Equations 7 through 122. The value of num_ref_idx_active_minus1[i] should be in the range of 0 to 14 (inclusive).

[0452] For i equal to 0 or 1, if the current slice is slice B, num_ref_idx_active_override_flag equals 1 and num_ref_idx_active_minus1[i] does not exist, it is inferred that num_ref_idx_active_minus1[i] equals 0.

[0453] When the current slice is slice P, num_ref_idx_active_override_flag is equal to 1 and num_ref_idx_active_minus1[0] does not exist, it is inferred that num_ref_idx_active_minus1[0] is equal to 0.

[0454] The variable NumRefIdxActive[i] is derived as follows: The value of NumRefIdxActive[i]-1 specifies the maximum reference index of the reference image list i that can be used to decode the slice. When the value of NumRefIdxActive[i] is equal to 0, the reference index of the reference image list i cannot be used to decode the slice.

[0455] When the current slice is a P slice, the value of NumRefIdxActive[0] should be greater than 0.

[0456] When the current slice is slice B, both NumRefIdxActive[0] and NumRefIdxActive[1] should be greater than 0.

[0457] Cabac_init_flag specifies the method for determining the initialization table used during the initialization of context variables. If cabac_init_flag does not exist, it is inferred to be equal to 0.

[0458] A collocated_from_l0_flag value of 1 specifies that the juxtaposed images used for time motion vector prediction are sourced from reference image list 0. A collocated_from_l0_flag value of 0 specifies that the juxtaposed images used for time motion vector prediction are sourced from reference image list 1.

[0459] The following applies when collocated_from_l0_flag is not present: - If slice_type is not equal to B, then it is inferred that the value of collocated_from_l0_flag is equal to 1.

[0460] - Otherwise (slice_type equals B), infer that the value of collocated_from_l0_flag is equal to pps_collocated_from_l0_idc - 1.

[0461] collocated_ref_idx specifies the reference index of the juxtaposed images used for temporal motion vector prediction. When slice_type is equal to P or when slice_type is equal to B and collocated_from_l0_flag is equal to 1, collocated_ref_idx refers to the image in list 0, and the value of collocated_ref_idx should be in the range of 0 to NumRefIdxActive[0] - 1 (inclusive).

[0462] When slice_type equals B and collocated_from_10_flag equals 0, collocated_ref_idx refers to the image in list 1, and the value of collocated_ref_idx should be in the range of 0 to NumRefIdxActive[1]-1 (inclusive).

[0463] If collocated_ref_idx does not exist, it is inferred that the value of collocated_ref_idx is equal to 0.

[0464] Bitstream compliance requirements: for all slices of an encoded image, the image referenced by collocated_ref_idx should be the same.

[0465] For bitstream compliance requirements, the reference image referenced by collocated_ref_idx and the current image should have the same resolution, and RefPicIsScaled[ collocated_from_l0_flag? 0 : 1 ][ collocated_ref_idx] should be equal to 0.

[0466] slice_qp_delta specifies the Qp to be used for the coded blocks in the slice. Y The initial value of the slice, until modified by the value of CuQpDeltaVal in the coding unit layer. Y Initial value of quantization parameter SliceQp Y Export as follows: SliceQp Y = 26 + init_qp_minus26 + slice_qp_delta SliceQp Y The value should be in the range of -QpBdOffset to +63 (inclusive).

[0467] When Qp' is determined CbWhen quantizing the parameter value, `slice_cb_qp_offset` specifies the difference to be added to `pps_cb_qp_offset`. The value of `slice_cb_qp_offset` should be in the range of -12 to +12 (inclusive). If `slice_cb_qp_offset` does not exist, it is inferred to be equal to 0. The value of `pps_cb_qp_offset + slice_cb_qp_offset` should be in the range of -12 to +12 (inclusive).

[0468] When Qp is determined ' Cr When quantizing the parameter value, `slice_cr_qp_offset` specifies the difference to be added to `pps_cr_qp_offset`. The value of `slice_cr_qp_offset` should be in the range of -12 to +12 (inclusive). If `slice_cr_qp_offset` does not exist, it is inferred to be equal to 0. The value of `pps_cr_qp_offset + slice_cr_qp_offset` should also be in the range of -12 to +12 (inclusive).

[0469] slice_joint_cbcr_qp_offset specifies the offset when Qp is determined. ' CbCr When adding the value of slice_joint_cb_cr_qp_offset_value, add the difference to the value of slice_joint_cb_cr_qp_offset. The value of slice_joint_cbcr_qp_offset should be in the range of -12 to +12 (inclusive). If slice_joint_cbcr_qp_offset does not exist, it is inferred to be equal to 0. The value of slice_joint_cbcr_qp_offset_value + slice_joint_cbcr_qp_offset should be in the range of -12 to +12 (inclusive).

[0470] A slice_sao_luma_flag value of 1 indicates that SAO is enabled for the luma component in the current slice; a slice_sao_luma_flag value of 0 indicates that SAO is disabled for the luma component in the current slice; when the slice_sao_luma_flag does not exist, it is inferred that it is equal to pic_sao_luma_enabled_flag.

[0471] A slice_sao_chroma_flag value of 1 indicates that SAO is enabled for the chroma components in the current slice; a slice_sao_chroma_flag value of 0 indicates that SAO is disabled for the chroma components in the current slice. If slice_sao_chroma_flag does not exist, it is inferred that it is equal to pic_sao_chroma_enabled_flag.

[0472] A slice_alf_enabled_flag value of 1 indicates that the adaptive loop filter is enabled in the slice and can be applied to the Y, Cb, or Cr color components. A slice_alf_enabled_flag value of 0 indicates that the adaptive loop filter is disabled for all color components in the slice. When it does not exist, the value of slice_alf_enabled_flag is inferred to be equal to pic_alf_enabled_flag.

[0473] `slice_num_alf_aps_ids_luma` specifies the number of ALF APSs referenced by the slice. When `slice_alf_enabled_flag` equals 1 and `slice_num_alf_aps_ids_luma` does not exist, it is inferred that the value of `slice_num_alf_aps_ids_luma` is equal to the value of `pic_num_alf_aps_ids_luma`.

[0474] `slice_alf_aps_id_luma[i]` specifies the `adaptation_parameter_set_id` of the i-th ALF APS referenced by the luma component of the slice. The `TemporalId` of the APS NAL cell with `aps_params_type` equal to `ALF_APS` and `adaptation_parameter_set_id` equal to `slice_alf_aps_id_luma[i]` should be less than or equal to the `TemporalId` of the encoded slice NAL cell. When `slice_alf_enabled_flag` is equal to 1 and `slice_alf_aps_id_luma[i]` does not exist, it is inferred that the value of `slice_alf_aps_id_luma[i]` is equal to the value of `pic_alf_aps_id_luma[i]`.

[0475] The value of alf_luma_filter_signal_flag of the APS NAL cell with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_luma[i] should be equal to 1.

[0476] A slice_alf_chroma_idc equal to 0 indicates that the adaptive loop filter is not applied to the Cb and Cr color components. A slice_alf_chroma_idc equal to 1 indicates that the adaptive loop filter is applied to the Cb color component. A slice_alf_chroma_idc equal to 2 indicates that the adaptive loop filter is applied to the Cr color component. A slice_alf_chroma_idc equal to 3 indicates that the adaptive loop filter is applied to both the Cb and Cr color components. When slice_alf_chroma_idc does not exist, it is inferred to be equal to pic_alf_chroma_idc.

[0477] `slice_alf_aps_id_chroma` specifies the `adaptation_parameter_set_id` of the ALF APS referenced by the chroma components of the slice. The `TemporalId` of the APS NAL cell, which has `aps_params_type` equal to `ALF_APS` and `adaptation_parameter_set_id` equal to `slice_alf_aps_id_chroma`, should be less than or equal to the `TemporalId` of the encoded slice NAL cell. When `slice_alf_enabled_flag` is equal to 1 and `slice_alf_aps_id_chroma` does not exist, it is inferred that the value of `slice_alf_aps_id_chroma` is equal to the value of `pic_alf_aps_id_chroma`.

[0478] The value of alf_chroma_filter_signal_flag for an APS NAL cell that has aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_chroma should be equal to 1.

[0479] A slice_deblocking_filter_override_flag value of 1 indicates that unblocking parameters exist in the slice header. A slice_deblocking_filter_override_flag value of 0 indicates that unblocking parameters do not exist in the slice header. When they do not exist, it is inferred that the value of slice_deblocking_filter_override_flag is equal to pic_deblocking_filter_override_flag.

[0480] A slice_deblocking_filter_disabled_flag value of 1 indicates that the deblocking filter operation should not be applied to the current slice. A slice_deblocking_filter_disabled_flag value of 0 indicates that the deblocking filter operation should be applied to the current slice. When slice_deblocking_filter_disabled_flag does not exist, it is inferred to be equal to pic_deblocking_biter_disabled_flag.

[0481] `slice_beta_offset_div2` and `slice_tc_offset_div2` specify the unblocking parameter offsets (divided by 2) for the current slice's β and tC. The values ​​of `slice beta_offset_div2` and `slice tc_offset_div2` should both be in the range of -6 to 6 (inclusive). If they do not exist, it is assumed that the values ​​of `slice_beta_offset_div2` and `slice_tc_offset_div2` are equal to `pic_beta_offset_div2` and `pic_tc_offset_div2`, respectively.

[0482] 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: Increasing offset_len_minus1 by 1 specifies the length of the entry_point_offset_minus1[i] syntax element in bits. The value of offset_len_minus1 should be in the range of 0 to 31 (inclusive).

[0483] The entry_point_offset_minus1[i] plus 1 specifies the offset of the i-th entry point (in bytes), and is represented by offset_len_minus1 plus 1 bit. The slice data following the slice header consists of NumEntryPoints + 1 subsets, where the subset index values ​​range from 0 to NumEntryPoints (inclusive). The first byte of the slice data is considered to be byte 0. When present, for subset identification purposes, anti-competition bytes appearing in the slice data portion of the encoded slice NAL unit are counted as part of the slice data. Subset 0 consists of bytes 0 to entry_point_offset_minus1[0] (inclusive) of the encoded slice data, and subset k (where k is in the range of 1 to NumEntryPoints - 1 (inclusive)) consists of bytes firstByte[k] to lastByte[k] (inclusive) of the encoded slice data, where firstByte[k] and lastByte[k] are defined as: firstByte[k] = (entry _point_offset_minus1[ n - 1 ] + 1) lastByte[ k ] = firstByte[ k ]+ entry_point_offset_minus1[ k ] The last subset (where the subset index equals NumEntryPoints) consists of the remaining bytes of the encoded slice data.

[0484] When entropy_coding_sync_enabled_flag equals 0 and the slice contains one or more complete tiles, each subset should consist of all the coded bits of all CTUs within the same tile in the slice, and the number of subsets (i.e., the value of NumEntryPoints + 1) should be equal to the number of tiles in the slice.

[0485] When `entropy_coding_sync_enabled_flag` equals 0 and the slice contains a subset of CTU rows from a single tile, `NumEntryPoints` should be 0, and the number of subsets should be 1. This subset should consist of all coded bits of all CTUs in the slice. When `entropy_coding_sync_enabled_flag` equals 1, each subset `k` (where `k` is in the range 0 to `NumEntryPoints`, inclusive) should consist of all coded bits of all CTUs in the CTU rows within the tile, and the number of subsets (i.e., the value of `NumEntryPoints + 1`) should equal the total number of tile-specific CTU rows in the slice.

[0486] `slice_header_extension_length` specifies the length (in bytes) of the slice header extension data, excluding the bits used to signal the `slice_header_extension_length` itself. The value of `slice_header_extension_length` should be in the range of 0 to 256 (inclusive). If it does not exist, the value of `slice_header_extension_length` is assumed to be 0.

[0487] The slice_header_extension_data_byte[i] can have any value. Decoders conforming to this version of the specification should ignore the values ​​of all slice_header_extension_data_byte[i] syntax elements. Their values ​​do not affect the configuration file specified in this version of the specification for decoders conforming to this specification.

[0488] As provided in Table 2, NAL units may include adaptive parameter set syntax structures. Table 8 shows the adaptive parameter set syntax structures provided in JVET-P2001.

[0489] Table 8 Regarding Table 8, JVET-P2001 provides the following semantics: Each APS RBSP should be available for the decoding process before being referenced, including in at least one AU in which the TemporalId is less than or equal to the TemporalId of the coded slice NAL unit that references it or is provided externally.

[0490] All APS NAL cells within a PU that have specific values ​​for adaptation_parameter_set_id and aps_params_type should have the same content, regardless of whether they are prefix APS NAL cells or suffix APS NAL cells.

[0491] The adaptation_parameter_set_id provides an identifier for the APS for reference by other syntax elements.

[0492] When aps_params_type is equal to ALF_APS or SCALING_APS, the value of adaptation_parameter_set_id should be in the range of 0 to 7 (inclusive).

[0493] When aps_params_type equals LMCS_APS, the value of adaptation_parameter_set_id should be in the range of 0 to 3 (inclusive).

[0494] aps_params_type specifies the type of APS parameters carried in the APS as specified in Table 9. When aps_params_type equals 1 (LMCS APS), the value of adaptation_parameter_set_id should be in the range of 0 to 3 (inclusive).

[0495] Table 9 Note—Each type of APS uses a separate value space for adaptation_parameter_set_id.

[0496] Note that APS NAL units (with specific values ​​for adaptation_parameter_set_id and aps_params_type) can be shared across images, and different slices within an image can refer to different ALF APSs.

[0497] Note—The suffix APS NAL unit associated with a specific VCL NAL unit (which is listed before the suffix APS NAL unit in decoding order) is not used by the specific VCL NAL unit, but is used by the VCL NAL units listed after the suffix APS NAL unit in decoding order.

[0498] An aps_extension_flag value of 0 indicates that the aps_extension_data_flag syntax element does not exist in the APS RBSP syntax structure. An aps_extension_flag value of 1 indicates that the aps_extension_data_flag syntax element exists in the APS RBSP syntax structure.

[0499] The `aps_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 `aps_extension_data_flag` syntax elements. As shown in Table 5 above, the image header syntax structure provided in JVET-P2001 includes the syntax element `pic_lmcs_enabled_flag`, which specifies that luminance mapping with chroma scaling (LMCS) is enabled for all slices associated with the image (PH), and the syntax element `pic_lmcs_aps_id`, which specifies the `adaptation_parameter_sct_id` of the LMCS APS for the slices associated with the PH. Therefore, according to JVET-P2001, if `pic_lmcs_enabled_flag` equals 1, luminance mapping with chroma scaling is applied to all slices associated with the PH. In other words, in JVET-P2001, if LMCS is enabled for an image, LMCS cannot be turned on or off on a per-slice basis. Similarly, the picture header syntax structure provided in JVET-P2001 includes the syntax element `pic_scaling_list_present_flag`, which specifies the scaling list data for slices associated with the PH to be derived based on the scaling list data contained in the reference scaling list APS, and `pic_scaling_list_aps_id` specifies the `adaptation_parameter_set_id` of the scaling list APS. Therefore, according to JVET-P2001, if `pie sealing_list_present_flag` equals 1, the scaling list is applied to all slices associated with the PH. That is, in JVET-P2001, it is not possible to select a scaling list based on each slice. This may be less than ideal.

[0500] As mentioned above, in some cases, an image may have a single slice. According to the image header syntax structure and slice header syntax structure provided in JVET-P2001, when an image has a single slice, the syntax elements in the image header that specify syntax that may exist at the image header or slice header level are redundant. Due to its impact on compression efficiency, it is not an ideal design for signaling redundant syntax elements at the image header level.

[0501] As provided in Tables 3 and 5 above, the SPS syntax structure in JVET-P2001 includes the syntax element `sps_subpic_id_len_minus1`, which specifies the number of bits used to represent the syntax element `sps_subpic_id[i]`. The length of the subpicture ID syntax element is also signaled in the picture header when a signal is sent to indicate the subpicture ID. In other words, the picture header in JVET-P2001 includes the syntax element `ph_subpic_id_len_minus1`, which specifies the number of bits used to represent the syntax element `ph_subpic_id[i]`. Since the length of the subpicture ID syntax element is one of the features identified as aligning between different picture codes within a sequence, repeating this length in each picture header is inefficient.

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

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

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

[0505] Figure 4 This is a conceptual diagram illustrating examples of components that can be included in a specific implementation of system 100. Figure 4 In the specific implementation shown in the example, 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 4The 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 4 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 communications 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).

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

[0507] Refer again Figure 4Television 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 4 As shown, the television service provider site 406 can communicate with the 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, the television service provider site 406 may include a television studio, and the content may originate from that television studio.

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

[0509] Refer again Figure 4Content 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.

[0510] 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 5 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.

[0511] 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 5In 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 5 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 5 As shown, the video encoder 500 receives source video blocks and outputs a bitstream.

[0512] exist Figure 5 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 transforms such as the Discrete Cosine Transform (DCT), Discrete Sine Transform (DST), or conceptually similar transforms (e.g., four 8×8 transforms can be applied to a 16×16 residual value array) 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 slice bit values ​​and / or CU bit values ​​(e.g., CU increment QP values). QP data can include any data used to determine the QP used for quantizing a particular set of transform coefficients. Figure 5 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. For example... 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, which can then 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.

[0513] Refer again Figure 5 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 5 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).

[0514] Refer again Figure 5 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 5(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.

[0515] like Figure 5 As shown, filter unit 516 receives reconstructed video blocks and encoding 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 5 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.

[0516] 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 4 In the device shown.

[0517] As mentioned above, sending signals to notify metadata describing the video encoding attributes provided in JVET-P2001 is less than ideal. Specifically, as stated above, in JVET-P2001, if LMCS is enabled for a picture, LMCS cannot be turned on or off on a per-slice basis, and the scaling list cannot be selected based on a per-slice basis. In one example, according to the techniques described herein, if LMCS is enabled for a picture, LMCS is allowed to be turned on or off on a per-slice basis and / or the scaling list can be selected based on a per-slice basis. That is, in one example, according to the techniques described herein, the relevant syntax of the slice header syntax structure used in conjunction with the picture header (e.g., a picture header based on the picture headers shown in Table 5) can be based on the syntax provided in Table 10.

[0518] Table 10 Regarding Table 10, the semantics of the syntax elements can be based on the semantics provided above relative to Table 6, where the semantics of the syntax elements slice_lmcs_enabled_flag and slice_scaling_list_present_flag are based on the following: A slice_lmcs_enabled_flag value of 1 indicates that luma mapping with chroma scaling is enabled for the current slice. A slice_lmcs_enabled_flag value of 0 indicates that luma mapping with chroma scaling is disabled for the current slice. If the slice lines enabled flag does not exist, it is inferred to be equal to 0.

[0519] `slice_scaling_list_present_flag` equal to 1 specifies that the scaling list data for the current slice is derived based on the scaling list data contained in the reference scaling list APS, which has an `aps_params_type` equal to `SCALING APS` and an `adaptation parameter set id` equal to `pic_scaling_list_aps_id`. `slice_scaling_list_present_flag` equal to 0 specifies that the scaling list data for the current image is the default scaling list data to be derived. When it does not exist, the value of `slice_scaling_list_present_flag` is assumed to be 0.

[0520] As described above, in JVET-P2001, when an image has a single slice, the syntax elements in the image header that specify the syntax that may exist at the image header or slice header level are redundant. In one example, according to the techniques described herein, a signal notification flag can be sent in the SPS, and the flag can be used in the image header to control the presence of syntax in the image header, such as RPL, SAO, ALF, and / or deblocking related syntax. This is useful and provides bit savings when the image has only one slice. Additionally, in one example, the SPS flag can be used to control the presence of image header extensions. Signaling such a flag in the SPS allows specifying that each image in the encoded video sequence has this property. Alternatively, in one example, the flag can be signaled in the PPS or image header. In one example, according to the techniques described herein, the related syntax of the sequence parameter set syntax structure and the image header syntax can be based on the syntax provided in Tables 11 and 12, respectively.

[0521] Table 11 Table 12 Regarding Tables 11 and 12, the semantics of the syntax elements can be based on the semantics provided above relative to Tables 3 and 5, where the semantics of the syntax elements sps_ph_flags_present_flag and pic_rpl_present_flag are based on the following: `sps_ph_flags_present_flag` equal to 1 indicates that the image header contains the marker syntax elements `pic_rpl_present_flag`, `pic_sao_enabled_present_flag`, `pic_alf_enabled_present_flag`, and `pic_dcblocking_filter_override_present_flag`, and that the image header contains an image header extension. `sps_alf_enabled_flag` equal to 0 indicates that the image header does not contain the marker syntax elements `pic_rpl_present_flag`, `pic_sao_enabled_present_flag`, `pic_alf_enabled present_flag`, and `pic_deblocking_filter_override_present_flag`, nor does it contain an image header extension.

[0522] A `pic_rpl_present_flag` value of 1 indicates that a reference image list signaling exists in the image header. A `pic_rpl_present_flag` value of 0 indicates that a reference image list signaling does not exist in the image header, and that the reference image list signaling may exist in the slice header of the image slice. If it does not exist, it is inferred that `pic_rpl_present_flag` is equal to 0.

[0523] For bitstream compliance requirements, the value of pic_rpl_present_flag should be equal to 0 when sps_id_rpl_present_flag is equal to 0 and the image associated with the image header is an IDR image.

[0524] It should be noted that, in one example, the syntax element `sps_ph_flags_present_flag` is not used to control the presence of image header extensions. In this case, `&&sps_ph_flags_present_flag` is not included in the `if(picture_header_extension_present_flag&&sps_ph_flags_present_flag)` condition, and the semantics of the syntax element `sps_ph_flags_present_flag` can be based on the following: A value of 1 for `sps_ph_flags_present_flag` indicates that the tag syntax elements `pic_rpl_present_flag`, `pic_sao_enabled_present_flag`, `pic_alf_enabled_present_flag`, and `pic_deblocking_filter_override_present_flag` are present in the image header. A value of 0 for `sps_alf_enabled_flag` indicates that the tag syntax elements `pic_rpl_present_flag`, `pic_sao_enabled_present_flag`, `pic_alf_enabled_present_flag`, and `pic_deblocking_filter_override_present_flag` are not present in the image header.

[0525] It should be noted that in some cases, `sps_ph_flags_present_flag` can be described as a flag indicating whether an image includes a single slice. Therefore, according to the techniques described herein, generally, an indication of whether an image includes a single slice can be used to indicate whether syntax is included in the image header or the corresponding slice header. That is, for example, whether it is necessary to indicate in the image header whether syntax exists in the slice header can be based on the indication of whether the image includes a single slice. For example, according to the techniques described herein, when an image includes a single slice, by default, redundant syntax between the image header and the corresponding slice header will be included in the slice header, and because redundant syntax will be included in the slice header by default, the image header will not include syntax indicating whether the syntax is included in the image header or the slice header (i.e., the existence of an indication syntax). It should be noted that the indication of whether an image includes a single slice can be based on syntax in the PPS (e.g., flags) or, for example, a condition indicated by the PPS syntax and `num_slices_in_pic_minus1` equals 0, or based on `no_pic_partition_flag` equals 1.

[0526] For example, a signal can be sent in SPS to notify a flag, such as `sps_ph_flags_present_flag`, and a signal can be sent in PPS to notify another flag, such as `pps_ph_flags_present_flag`. Furthermore, flags in SPS, such as `sps_ph_flags_present_flag`, can be used to control the existence of `pic_rpl_present_flag`, `pic_sao_enabled_present_flag`, and `pic_alf_enabled_present_flag`, while flags in PPS, such as `pps_ph_flags_present_flag`, can be used to control the existence of `pic_deblocking_filter_override_present_flag` and, in the condition `if(picture_header_extension_present_flag&&pps_ph_flags_present_flag)`, to control the existence of image header extensions.

[0527] In one example, according to the techniques described herein, the more_rbsp_data() function can be used to signal the image header extension data instead of explicitly indicating the length of the extension, as provided in Table 12, for example. That is, in one example, the relevant syntax for the image header syntax used to signal the image header extension data can be based on the syntax provided in Table 12A, or in one example, on the syntax provided in Table 12B.

[0528] Table 12A Table 12B Regarding Tables 12A to 12B, the semantics of the syntax elements can be based on the semantics provided above, wherein the semantics of the syntax elements ph_extension_flag and ph_extension_data_flag are based on the following: A ph_extension_flag value of 0 indicates that the ph_extension_data_flag syntax element does not exist in the image header RBSP syntax structure. A ph_extension_flag value of 1 indicates that the ph_extension_data_flag syntax element exists in the image header RBSP syntax structure.

[0529] The `ph_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 `ph_extension_data_flag` syntax elements.

[0530] It should be noted that in the example corresponding to Table 12A, the syntax element piece_header_extension_present_flag can be removed from the PPS, and in the example corresponding to Table 12B, the syntax element picture_header_extension_present_flag can be included in the PPS so that when there is no extension, it is not necessary to send the flag in the picture header.

[0531] As mentioned above, in JVET-P2001, it is inefficient to signal the subpic ID length in the SPS syntax element sps_subpic_id_len_minus1 and in each picture header the syntax element ph_subpic_id_len_minus1. In one example, according to the technique described herein, instead of signaling the subpic ID length in the picture header, the length signaled from the parameter set is used. That is, in one example, according to the technique described herein, the syntax element ph_subpic_id_len_minus1 is not included in the picture header syntax structure, and in one example, the semantics of ph_subpic_id[i] can be based on the following: ph_subpic_id[i] specifies the subpick ID of the i-th subpick. The length of the ph_subpic_id[i] syntax element is sps_subpic_id_len_minus1 + 1 bits.

[0532] In SPS, the syntax element `sps_subpic_id_len_minus1` is conditionally signaled based on `if(sps_subpics_id_present_flag)` but not on `if(sps_subpics_id_signalling_present_flag)`. That is, the syntax element `sps_subpic_id_len_minus1` can immediately follow `if(sps_subpics_id_present_flag){`.

[0533] In one example, the semantics of ph_subpic_id[i] can be based on the following: ph_subpic_id[i] specifies the subpick ID of the i-th subpick. The length of the ph_subpic_id[i] syntax element is pps_or_pli_subpic_id_len_minus1 + 1 bits.

[0534] In this context, in one example, the relevant syntax of the image parameter set syntax structure can be based on the syntax provided in Table 13, according to the techniques described in this paper.

[0535] Table 13 Regarding Table 13, the semantics of the syntax elements can be based on the semantics provided above relative to Table 4, where the semantics of the syntax elements pps_or_ph_subpic_id_signalling_present_flag and pps_or_ph_subpic_id_len_minus1 are based on the following: A flag of 1 for `pps_or_ph_subpic_id_signalling_present_flag` indicates that a signal notification `pps_or_ph_subpic_id_lcn_minus1` will be sent in PPS. A flag of 0 for `pps_or_ph_subpic_id_signalling_present_flag` indicates that a signal notification `pps_or_ph_subpic_id_len_minus1` will not be sent in PPS.

[0536] For bitstream compliance requirements, when sps_subpic_id_present_flag is 0 or sps_subpic_id_signalling_present_flag is 1, pps_or_ph_subpic_id_signalling_present_flag should be equal to 0.

[0537] The increment of 1 in `pps_or_ph_subpic_id_len_minus1` specifies the number of bits used to represent the syntax elements `pps_subpic_id[i]` (if present) and `ph_subpic_id[i]` (if present). The value of `pps_or_ph_subpic_id_len_minus1` should be in the range of 0 to 15 (inclusive).

[0538] For bitstream compliance requirements, the value of pps_or_phsubpic_id_len_minus1 should be the same for all PPS referenced by encoded images within CVS.

[0539] In one example, according to the techniques described herein, one or more of the techniques described above with respect to Tables 10 to 13 can be combined. For example, if LMCS is enabled for an image, LMCS can be turned on or off on a per-slice basis and / or a scaling list can be selected on a per-slice basis, and / or a signal can be sent in the SPS to notify a flag, and a flag can be used in the image header to control the presence of syntax in the image header, and / or the syntax element ph_subpic_id_len_minus1 is not included in the image header syntax structure.

[0540] It should be noted that JVET-P2001 requires each encoded picture to have exactly one picture header. Making slices self-contained entities, i.e., independent of any other NAL unit (assuming the parameter set is already available) from the same access unit, has advantages. For example, this improves error robustness because slices can be processed independently even if the picture header is lost and therefore not received. In one example, according to the technique described herein, instead of sending the picture header syntax structure in the picture header NAL unit, the picture header syntax structure can be repeated in each slice header. In one example, this can be controlled based on a new flag indicating whether the picture header is included in the slice header.

[0541] As provided in Table 2 above, NAL units may include PH_NUT. A NAL unit marked PH_NUT is a picture header NAL unit, and each picture is required to contain exactly one PH_NUT, which must precede all VCLNAL units of the picture. In earlier drafts and standards of VVC (i.e., HEVC and AVC), picture headers did not exist; therefore, picture attributes (e.g., picture attributes related to random access) were repeated across all slices of the picture, even though it was required that the value be the same across all slices. In one example, according to the techniques described herein, to provide a cleaner design, the corresponding picture-level information can be provided in the picture header NAL unit instead of repeating this information across all slices of the picture. This design also improves the processing and analysis of access units because random access attributes can be determined at the picture header NAL unit preceding all slice NAL units, rather than having to parse information from a single unit within a slice NAL unit to make that determination. Therefore, according to the technique described herein, in one example, various slice NAL unit types (e.g., those in Table 2) can be changed to picture header NAL unit types, and only one NAL unit type may exist for a coded slice. Table 14 shows examples of NAL unit types according to the technique described herein, where various slice NAL unit types are changed to picture header NAL unit types, and only one NAL unit type exists for a coded slice. It should be noted that, according to the technique described herein, when NAL units from two different bitstreams are combined to form a new access unit for a new bitstream, if the picture header types in the two bitstreams are different, the combined access unit should (i.e., may be required) use at least a restrictive picture header. For example, in one example, if the picture header in one bitstream is a trailing picture and the picture header in the other bitstream is an IDR picture, the combined bitstream should use a trailing picture header to allow all slice types and prediction structures.

[0542] Table 14 For example, according to the technique described herein, the slice type can be removed from the slice header and instead provided in the NAL unit header using a different nal_unit_type value. Table 15 shows an example of NAL unit types according to the technique described herein, where the slice type is removed from the slice header and provided in the NAL unit header. It should be noted that one benefit of including slice type information in the NAL unit header rather than the slice header is that it makes it easier for the extractor and other network entities to identify independently decodeable regions. Another benefit of including slice type information in the NAL unit header rather than the slice header is that using the available values ​​of nal_unit_type instead of having a separate syntax element in the slice header is more bit-efficient, as the slice header currently consumes one to three bits, depending on the slice type.

[0543] Table 15 Regarding Table 15, it should be noted that the syntax element slice_type is removed from slice header(), the variable SliceType is used to replace all occurrences of slice_type, and the following can be added to the semantics of the syntax element nal_unit_type: When nal_unit_type is less than or equal to 2, the variable SliceType is derived as follows: SliceType = nal_unit_type Furthermore, regarding Table 15, the corresponding image header syntax is provided in Table 16: Table 16 Regarding Table 16, the semantics of syntax elements can be based on the semantics provided above, where the semantics of the syntax element pic_rpl_present_flag are based on the following: A `pic_rpl_present_flag` value of 1 indicates that a reference picture list signaling exists in the PH (Picture View). A `pic_rpl_present_flag` value of 0 indicates that a reference picture list signaling does not exist in the PH, and that the reference picture list signaling may exist in the slice header of a picture slice. When `pic_rpl_present_flag` does not exist, it is inferred that it is equal to 0.

[0544] In addition, the following text can be removed from the semantics of nal unit type: For any specific image's VCL NAL unit, the following applies: - 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 units of the picture or PU.

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

[0546] Additionally, the syntax element mixed_nalu_types_in_pic_flag can be removed from PPS because different picture types are no longer indicated in the NAL unit header of the slice, and therefore it is always possible to mix NAL units from different bitstreams (if they otherwise meet all the requirements for enabling merging).

[0547] In one example, according to the techniques described in this paper, in order to support CRA images in a hybrid access unit, in addition to extracting sub-images from the bitstream and decoding the sub-images into independent bitstreams through appropriate rewriting of the parameter set, the following can also be applied to the slices and PU: For each slice with a nal_unit_type value nalUnitTypeA from IDR_W_RADL to CRA_NUT (inclusive of end values), 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: - The slice should belong to the subpic A, and the corresponding subpic treated as pic_flag[i] is equal to 1.

[0548] - A slice should not belong to a subpicture of a picA that contains a VCL NAL unit with a nal_unit_type that is not equal to nalUnitTypeA.

[0549] - For all PUs in CLVS that are ordered after the current picture in decoding and output order, neither RefPicList[0] nor RefPicList[1] of the slices in subpicA should include any picture in the active entry that is ordered before picA in decoding order.

[0550] For example, the following can be applied to slices and PUs, with stricter constraints on IDR images and more lenient constraints only allowed on CRA images: For each slice with a nal_unit_type value nalUnitTypeA from IDR_W_RADL to CRA_NUT (inclusive of end values), 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: - The slice should belong to the subpic A, and the corresponding subpic treated as pic_flag[i] is equal to 1.

[0551] - A slice should not belong to a subpicture of a picA that contains a VCL NAL unit with a nal_unit_type that is not equal to nalUnitTypeA.

[0552] - If nalUnilTvpcA equals CRA: For all PUs in CLVS that are ordered in decoding and output order after the current image, neither RefPicList[0] nor RefPicList[1] of the slices in subpicA should include any images in the active entry that are ordered in decoding order before picA.

[0553] - Otherwise: For all PUs in CLVS that are ordered after the current image in decoding order, neither RefPicList[0] nor RefPicList[1] of the slices in subpicA should include any images in the active entry that are ordered before picA in decoding order.

[0554] It should be noted that encoding each image with a single slice is common practice, and it is highly desirable to support this use case with minimal overhead. Specifically, for example, it is desirable to allow support for sending a single NAL unit for each image. Based on the NAL unit types provided in Table 2, it is required to send at least two NAL units for each image (i.e., one image header NAL unit and at least one encoded slice NAL unit). To more effectively support the common practice of each image including a single slice, in one example, according to the techniques described herein, a new NAL unit type can be defined for encoding images, and the encoded image can consist of an image header, a slice header, and a slice data syntax structure plus syntax elements indicating the image type (e.g., IDR, CRA, trailing image). This means that a signal can be sent in a single NAL unit to indicate an encoded image with only one slice, which significantly reduces the overhead associated with the start code (or NAL unit length field), the NAL unit header bytes, and rbsp_trailing_bits(). Table 17 provides examples of NAL unit types according to the techniques described herein, where NAL unit types for encoding images exist.

[0555] Table 17 Regarding Table 17, Table 18 shows the corresponding picture layer rbsp() syntax structure, Table 19 shows the corresponding relevant parts of the picture header structure() syntax structure, and Table 20 shows the corresponding slice_header() syntax structure.

[0556] Table 18 Table 19 Table 20 Regarding Tables 18 to 20, the semantics can be based on the semantics provided above, where the semantics of the syntax element pic_nal_type is based on the following: pic_nal_type indicates the corresponding Nal cell type of the image.

[0557] The value of NalType is exported as follows: NalType = (nal_unit_type = = CODED_PIC) ? pic_nal_type : nal_unit_type For example, Table 21 shows the corresponding relevant parts of the picture_header_structure() syntax structure.

[0558] Table 21 Regarding Table 21, the variable NalType is also used to more effectively signal the image header. Regarding Table 21, the semantics can be based on the semantics provided above, where the semantics of the syntax element gdr_pic_flag are based on the following: A value of 1 for `gdr_pic_flag` indicates that the image associated with the PH is a GDR image, while a value of 0 indicates that the image associated with the PH is not a GDR image. If `gdr_pic_flag` does not exist, it is assumed that the value of `gdr_pic_flag` is equal to `(NalType == GDR_NUT ? 1 : 0)`.

[0559] It should be noted that in JVET-P2001, the ALF and SAO parameters can be signaled in the PH or in the slice header, but signaling cannot be sent in both locations simultaneously for the same image. It is asserted that indicating whether signaling is used in the image header or the slice header at the PPS level is sufficient. This provides bit savings because it eliminates the need to send information about where the information will be present at each image. Table 22 shows the corresponding relevant parts of the pic_parameter_set_rbsp() syntax structure, Table 23 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, and Table 24 shows the corresponding relevant parts of the slice_header() syntax structure, where the PPS indicates whether signaling is used for the ALF and SAO parameters in the image header or the slice header.

[0560] Table 22 Table 23 Table 24 Regarding Tables 22 to 24, the semantics of the syntax elements can be based on the semantics provided above, wherein the semantics of the syntax elements pps_sao_enabled_present_in_pic_header_flag and pps_alf_enabled_present_in_pic_header_flag are based on the following: A value of 1 for `pps_sao_enabled_present_in_pic_header_flag` indicates that SAO-related syntax elements can exist in the image header but not in the slice header. A value of 0 for `pps_sao_enabled_present_in_pic_header_flag` indicates that SAO-related syntax elements can exist in the slice header but not in the image header.

[0561] A value of 1 for pps_alf_enabled_present_in_pic_header_flag indicates that ALF-related syntax elements can exist in the image header but not in the slice header. A value of 0 for pps_alf_enabled_present_in_pic_header_flag indicates that ALF-related syntax elements can exist in the slice header but not in the image header.

[0562] In one example, according to the techniques described herein, an SPS-level flag can be used to indicate whether virtual boundaries are enabled (i.e., allowed) in the encoded video sequence. When virtual boundaries are not enabled, there is no need to send signals in the SPS or picture header to indicate information related to virtual boundaries. This provides bit savings when virtual boundaries are not used and facilitates detection of whether virtual boundaries are used. Table 25 shows the corresponding relevant parts of the seq_parameter_set_rbsp() syntax structure, and Table 26 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, where an SPS-level flag is used to indicate whether virtual boundaries are enabled in the encoded video sequence.

[0563] Table 25 Table 26 Regarding Tables 25 and 26, the semantics of the syntax elements can be based on the semantics provided above, wherein the semantics of the syntax element `sps_virtual_boundaries_enabled_flag` is based on the following: A value of 1 for `sps_virtual_boundaries_enabled_flag` indicates that virtual boundaries can be used, and the syntax related to virtual boundaries exists in SPS and may also exist in the header of an image referencing SPS. A value of 0 for `sps_virtual_boundaries_enabled_flag` indicates that virtual boundaries are not used, and the syntax related to virtual boundaries does not exist in SPS and is not present in the header of an image referencing SPS.

[0564] It should be noted that in JVET-P2001, the Reference Picture List (RPL) parameter can be signaled either in the PH or in the slice header (but signaling cannot be sent in both locations simultaneously for the same picture). It is asserted that indicating at the PPS level whether signaling is used for the RPL parameter in the picture header or the slice header is sufficient. This provides bit savings because it will not be necessary to send information about where the information will be present at each picture. Table 27 shows the corresponding relevant parts of the pic_parameter_set_rbsp() syntax structure, Table 28 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, and Table 29 shows the corresponding relevant parts of the slice_header() syntax structure, where PPS-level flags are used to indicate whether signaling is used for the RPL parameter in the picture header or the slice header.

[0565] Table 27 Table 28 Table 29 Regarding Tables 27 to 29, the semantics of the syntax elements can be based on the semantics provided above, wherein the semantics of the syntax element pps_rpl_enabled_present_in_pic_header_flag is based on the following: The setting `pps_rpl_enabled_present_in_pic_header_flag` to 1 indicates that the reference image list related syntax elements (pic_rpl_sps_flag[i], pic_rpl_idx[i], pic_poc_lsb_lt[i][j], pic_delta_poc_msb_present_flag[i][j], pic_delta_poc_msb_cycle_lt[i][j]) can exist in the image header, and the corresponding reference image list related syntax elements (slice_rpl_sps_flag[i], slice_rpl_idx[i], slice_poc_lsb_lt[i][j], slice_delta_poc_msb_present_flag[i][j], slice delta_pocmsb cycle lt[i][j]) do not exist in the slice header. This indicates that `pps rpl enabled present in`. A value of 0 for `pic_header_flag` indicates that the reference image list related syntax elements (slice_rpl_sps_flag[i], slice_rpl_idx[i], slice_poc_lsb_lt[i][j], slice_delta_poc_msb_present_flag[i][j], slice_delta_poc_msb_cycle_lt[i][j]) can exist in the slice header, and the corresponding reference image list related syntax elements (pic_rpl_sps_flag[i], pic_rpl_idx[i], pic_poc_lsb_lt[i][j], pic_delta_poc_msb_present_nag[i][j], pic_delta_poc_msb_cycle_lt[i][j]) do not exist in the image header.

[0566] For example, Table 30 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, in which PPS-level markers are used to signal the RPL parameter in the picture header or in the slice header.

[0567] Table 30 It should be noted that in JVET-P2001, an indication of whether TMVP is used is provided in the picture header, but information related to the reference picture used for predicting motion vectors, i.e., the juxtaposed picture, is provided in the slice header, even though the same juxtaposed picture is required in all slice headers. In one example, according to the technique described herein, when RPL information is provided in the picture header, the juxtaposed picture information is indicated in the picture header. Table 31 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, and Table 32 shows the corresponding relevant parts of the slice_header() syntax structure, where PPS-level flags are used to signal the RPL parameters in the picture header or slice header.

[0568] Table 31 Table 32 Regarding Table 31, the semantics of the syntax elements can be based on the semantics provided above, where the semantics of the syntax elements pic_collocated_from_l0_flag and pic_collocated_ref_idx are based on the following: `pic_collocated_from_l0_flag` equal to 1 specifies that the juxtaposed images used for time motion vector prediction are sourced from reference image list 0. `pic_collocated_from_l0_flag` equal to 0 specifies that the juxtaposed images used for time motion vector prediction are sourced from reference image list 1.

[0569] The following applies when pic_collocated_from_10_flag is not present: - If rpl1 _idx_present flag equals 0, then it is inferred that the value of pic_collocated_from_10_flag is equal to 1.

[0570] - Otherwise (rpll idx present equals 1), infer that the value of pic_collocated_from_10_flag is equal to pps_collocated_from_10_idc - 1.

[0571] Pic_collocated_refidx specifies the reference index for the juxtaposed images used for temporal motion vector prediction.

[0572] When pic_collocatcd_from_l0_flag equals 1, pic_collocatcd_ref_idx refers to the image in list 0, and pic_collocated_ref_idx should be in the range of 0 to num ref entries[ 0 ][ PicRplsIdx[ 0]] -1 (inclusive).

[0573] When pic_collocated_from_l0_flag equals 0, collocated_ref_idx refers to the image in list 1, and the value of pic_collocated_ref_idx should be in the range of 0 to num_ref_entries[1][PicRplsIdx[1]] - 1 (inclusive).

[0574] If pic_collocated_ref_idx does not exist, it is inferred that the value of pic_collocated_ref_idx is equal to 0.

[0575] Regarding Table 32, the semantics of the syntax elements can be based on the semantics provided above, where the semantics of the syntax elements slice_collocated_from_l0_flag and slice_collocated_ref_idx are based on the following: A slice_collocated_from_l0_flag value of 1 specifies that the juxtaposed images used for time motion vector prediction are sourced from reference image list 0. A slice_collocated_from_l0_flag value of 0 specifies that the juxtaposed images used for time motion vector prediction are sourced from reference image list 1.

[0576] The following applies when slice_collocated_from_l0_flag is not present: - If pic_rpl_present_flag is equal to 1, then it is inferred that slice_collocated_from_l0_flag is equal to pic_collocated_from_l0_flag.

[0577] Otherwise, if slice_type is not equal to B, then it is inferred that the value of slice_collocated_from_l0_flag is equal to 1.

[0578] Otherwise, it is inferred that the value of slice_collocated_from_l0_flag is equal to pps_collocated_from_l0_idc - 1.

[0579] `slice_collocated_ref_idx` specifies the reference index for the juxtaposed images used for temporal motion vector prediction.

[0580] When slice_type equals P or when slice_type equals B and slice_collocated_from_10_flag equals 1, slice_collocated_ref_idx refers to the image in list 0, and the value of slice_collocated_ref_idx should be in the range of 0 to NumRefIdxActive[0]-1 (inclusive).

[0581] When slice_type equals B and slice_collocated_from_10_flag equals 0, slice_collocated_ref_idx refers to the image in list 1, and the value of slice_collocated_ref_idx should be in the range of 0 to NumRendxActive[1]-1 (inclusive).

[0582] The following applies when slice_collocated_ref_idx does not exist: - If pic_rpl_present_flag equals 1, it is inferred that slice_collocated_ref_idx equals pic_collocated_ref_idx.

[0583] - Otherwise, it is assumed that the value of slice_collocated_ref_idx is equal to 0.

[0584] Bitstream compliance requirements: for all slices of an encoded image, the image referenced by slice_collocated_ref_idx should be the same.

[0585] For bitstream compliance requirements, the reference image referenced by slice_collocated_ref_idx and the current image should have the same resolution, and RefPicIsScaled[ slice_collocated_from_10_flag? 0 : 1 ][ slice_collocatcd_ref_idx ] should be equal to 0.

[0586] It should be noted that in JVET-P2001, the partition constraint override signaling in the picture header includes different parameters for intra-slice and inter-slice, and when partition_constraints_override_flag equals 1, there are parameters for both intra-slice and inter-slice. Encoding pictures using only intra-slice or only inter-slice is very common. One example is when a picture is encoded with a single slice. Another example is an IRAP picture requiring only intra-slice components. In one example, according to the techniques described herein, two different flags can be used to indicate partition override: partition_constraints_override_intra_slice_flag, which applies to intra-slice, and partition_constraints_override_inter_slice_flag, which applies to inter-slice. Table 33 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, where the two different flags are used to indicate partition override.

[0587] Table 33 Regarding Table 33, the semantics of the syntax elements can be based on the semantics provided above, where the semantics of the syntax elements partition_constraints_override_intra_slice_flag and partition_constraints_override_inter_slice_flag are based on the following: A partition_constraints_override_intra_slice_flag value of 1 indicates that partition constraints for intra-slice operations exist in the partition property (PH). A partition constraints override intra-slice flag value of 0 indicates that partition constraints for intra-slice operations do not exist in the PH. When these constraints do not exist, it is assumed that the value of partition_constraints_override_intra_slice_flag is 0.

[0588] A partition_constraints_override_inter_slice_flag value of 1 indicates that partition constraints for inter-slice operations exist in the partition property (PH). A partition constraints override inter-slice flag value of 0 indicates that partition constraints for inter-slice operations do not exist in the PH. When they do not exist, it is inferred that the partition constraints override inter-slice flag value is 0.

[0589] For example, the syntax in Table 33 can be combined with the syntax in Tables 18 to 20, and the NalUnitType variable can be used to conditionally enable the partition_constraints_override_inter_slice_flag to exist, preventing the signaling of this syntax element from being sent in pictures that are not allowed to contain inter-slices. Table 34 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure.

[0590] Table 34 Regarding Table 34, the semantics of grammatical elements can be based on the semantics provided above.

[0591] It should be noted that in JVET-P2001, the qp delta and chroma qp offset signaling in the picture header includes different parameters for intra-slice and inter-slice, and parameters exist for both intra-slice and inter-slice when cu_qp_delta_enabled_flag and pps_cu_chroma_qp_offset_list_enabled_flag are each equal to 1. Encoding pictures using only intra-slice or only inter-slice is very common. One example is when a picture is encoded with a single slice. Another example is an IRAP picture that requires only intra-slice. These two events, along with the partition constraint overwrite flags, constitute the three parts of the picture header, where it would be beneficial to know whether the picture includes only intra-slice, only intra-slice, or both intra-slice and inter-slice. In one example, according to the techniques described herein, two flags indicating whether intra-slice and inter-slice are possible in the picture are included in the picture header. Table 35 shows the corresponding relevant parts of the picture_header_rbsp() syntax structure, where two different markers are used to indicate whether intra-frame slices and inter-frame slices may exist in the picture.

[0592] Table 35 Regarding Table 35, the semantics of the syntax elements can be based on the semantics provided above, where the semantics of the syntax elements no_intra_parameters_flag and no_inter_parameters_flag are based on the following: A value of 1 for `no_intra_parameters_flag` indicates that the parameters `cu qp delta` and `chroma qp offset` used for partitioning constraint overriding within intra-slices do not exist in the PH. A value of 0 for `no_intra_parameters_flag` indicates that the parameters `cu qp delta` and `chroma qp offset` used for partitioning constraint overriding within intra-slices exist in the PH.

[0593] A `no_inter_parameters_flag` value of 1 indicates that the parameters `cu_qp_delta` and `chroma_qp_offset` used for partitioning constraint overriding in inter-frame slices do not exist in the PH. A `no_inter_parameters_flag` value of 0 indicates that the parameters `cu_qp_delta` and `chroma_qp_offset` used for partitioning constraint overriding in inter-frame slices exist in the PH. When they do not exist, the value of `no_inter_parameters_flag` is presumed to be 0.

[0594] For example, you can send signals to no_intra_parameters_flag and no_inter_parameters_flag unconditionally within the if conditions provided below (i.e., without considering the other party as a condition).

[0595] For example, the order of no_intra_parameters_flag and no_inter_parameters_flag can be swapped as follows: If it does not exist, it is inferred that the value of no_intra_parameters_flag is equal to 0.

[0596] For example, syntactic elements can be represented by their reciprocals. Table 36 shows the corresponding relevant parts of the picture_header_rbsp() syntactic structure.

[0597] Table 36 Regarding Table 36, the semantics of the syntax elements can be based on the semantics provided above, where the semantics of the syntax elements intra_parameters_flag and inter_parameters_flag are based on the following: An intra_parameters_flag value of 1 indicates that the parameters cu qp delta and chroma qp offset for partitioning constraint overriding exist in the PH. An intra_parameters_flag value of 0 indicates that the parameters cu qp delta and chroma qp offset for partitioning constraint overriding do not exist in the PH.

[0598] An inter_parameters_flag value of 1 indicates that the parameters cu qp delta and chroma qp offset used for partitioning constraint overriding in inter-frame slices do not exist in PH. An inter_parameters_flag value of 0 indicates that the parameters cu qp delta and chroma qp offset used for partitioning constraint overriding in inter-frame slices do not exist in PH. When they do not exist, the value of inter_parameters_flag is inferred to be 1.

[0599] For example, `intra_parameters_flag` and `inter_parameters_flag` can be swapped as shown below. If they do not exist, the value of `intra_parameters_flag` is inferred to be 1.

[0600] For example, signals can be sent unconditionally to intra_parameters_flag and inter_parameters_flag within the if condition provided below (i.e., without conditional on the other party).

[0601] For example, the syntax in Table 36 can be combined with the syntax in Tables 18 to 20, and the `inter_parameters_flag` can exist only in images that can contain inter-frame slices. Table 37 shows the corresponding relevant parts of the `picture_header_rbsp()` syntax structure.

[0602] Table 37 Regarding Table 37, the semantics of the syntax elements can be based on the semantics provided above, where the semantics of the syntax elements intra_parameters_flag and inter_parameters_flag are based on the following: An inter_parameters_flag value of 1 indicates that the parameters cu qp delta and chroma qp offset used for partitioning constraint overriding in inter-frame slices do not exist in PH. An inter_parameters_flag value of 0 indicates that the parameters cu qp delta and chroma qp offset used for partitioning constraint overriding in inter-frame slices do not exist in PH. When they do not exist, the value of inter_parameters_flag is inferred to be 0.

[0603] An intra_parameters_flag value of 1 indicates that the parameters cu qp delta and chroma qp offset for partitioning constraint overriding of intra-slices exist in the PH. An intra_parameters_flag value of 0 indicates that the parameters cu qp delta and chroma qp offset for partitioning constraint overriding of intra-slices do not exist in the PH. When they do not exist, it is assumed that the value of intra_parameters_flag is equal to 1.

[0604] In this way, source device 102 represents an example of a device configured to: send a signal to indicate whether an encoded picture includes exactly one slice, and when the indication indicates that the encoded picture includes exactly one slice, send a signal in the slice header to indicate one or more syntax elements, and not send a signal in the picture header to indicate the presence of a redundant syntax element in the picture header corresponding to the one or more syntax elements in the slice header.

[0605] 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 Peripheral Component Fast 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.

[0606] 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 The C chip set or any other logical and physical structure that can be used to interconnect peer devices. The data decapsulator 123 can be configured to receive and parse any of the example syntax structures described herein.

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

[0608] Figure 6 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 thus may 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 37. 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 37.

[0609] exist Figure 6In the example shown, the video decoder 600 includes an entropy decoding unit 602, an inverse quantization unit 604, an inverse transform 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.

[0610] like Figure 6 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 6 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 6 As shown, the inverse quantization unit 604 and the transform 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.

[0611] See you again Figure 6The 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 6 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 an indication of whether an encoded picture includes exactly one slice, and when the indication indicates that the encoded picture includes exactly one slice, to infer the value of a presence indicator in the picture header such that the inferred value indicates that one or more redundant syntax elements in the picture header are included in the slice header.

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

[0613] 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 is accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. 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 directly 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.

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

[0615] The techniques disclosed herein can be implemented in various devices or apparatuses, including wireless handsets, integrated circuits (ICs), or IC sets (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.

[0616] 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 performed by circuitry (typically one or more integrated circuits). Circuitry designed to perform the functions described in this specification may include general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), 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, controller, microcontroller, or 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 producing integrated circuits that replace current integrated circuits, integrated circuits produced using such technologies can also be used.

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

[0618] <Cross-reference> This non-provisional patent application claims priority to provisional applications 62 / 926,299, filed October 25, 2019, 62 / 944,217, filed December 5, 2019, and 62 / 952,255, filed December 21, 2019, pursuant to 35 USC § 119, the entire contents of which are incorporated herein by reference.

Claims

1. A device comprising one or more processors, said one or more processors being configured to: Receive image header, among which, The image header includes common information shared by all slices of an coded image associated with the image header contained in the image unit; Parse the first syntax element in the image header, wherein the first syntax element specifies whether to enable luminance mapping with chroma scaling for the current image; Receive a slice header, wherein the slice header includes a flag indicating whether the image header is included in the slice header; and Based on the value of the first syntax element, the second syntax element in the slice header is conditionally parsed, wherein the second syntax element specifies whether to enable luminance mapping with chroma scaling for the current slice.

2. The device according to claim 1, wherein the device is a video decoder.

3. A device including one or more processors, said one or more processors being configured to: Generate image headers, where... The image header includes information common to all slices of an coded image associated with the image header contained in the image unit, wherein the image header includes a first syntax element specifying whether luminance mapping with chroma scaling is enabled for the current image; and Generate a slice header, wherein the slice header includes a flag indicating whether the image header is included in the slice header, the slice header conditionally includes a second syntax element based on the value of the first syntax element, and the second syntax element specifies whether to enable luminance mapping with chroma scaling for the current slice.

4. The device according to claim 3, wherein the device is a video encoder.

5. A computer-readable recording medium, characterized in that, The computer-readable recording medium stores a program, the program being configured to cause a computer to: Receive an image header, wherein the image header includes information common to all slices of an coded image associated with the image header contained in the image unit; Parse the first syntax element in the image header, wherein the first syntax element specifies whether to enable luminance mapping with chroma scaling for the current image; Receive a slice header, wherein the slice header includes a flag indicating whether the image header is included in the slice header; and Based on the value of the first syntax element, the second syntax element in the slice header is conditionally parsed, wherein the second syntax element specifies whether to enable luminance mapping with chroma scaling for the current slice.

Images