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. A method for the technique includes receiving a slice header syntax structure; determining whether the slice header syntax structure includes a picture header syntax structure; and if the slice header syntax structure includes the picture header syntax structure, parsing a first syntax element specifying a picture parameter set identifier from the picture header syntax structure, and parsing a second syntax element specifying a picture order count from the picture header syntax structure.

Description

[0001] This application is a divisional application of the Chinese patent application "System and method for sending signal notification of picture information in video encoding" (application number: 202080058277.3) with an application date of August 20, 2020. Technical Field

[0002] The present disclosure relates to video coding, and more particularly to techniques for signaling picture information of encoded video. Background Art

[0003] Digital video capabilities may be incorporated into a variety of devices, including digital televisions, laptop or desktop computers, tablet computers, digital recording devices, digital media players, video gaming devices, cellular phones (including so-called smart phones), medical imaging devices, and the like. Digital video may be encoded according to a video coding standard. A video coding standard defines the format of a conforming bitstream that encapsulates the coded video data. A conforming bitstream is a data structure that can be received and decoded by a video decoding device to generate reconstructed video data. A video coding standard may incorporate 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 High Efficiency Video Coding (HEVC), Recommendation ITU-T H.265, December 2016, which is incorporated herein by reference and is referred to herein as ITU-T H.265. Extensions and improvements to ITU-TH.265 are currently under consideration to develop the next generation of 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 techniques with compression capabilities significantly exceeding the current HEVC standard. The Joint Exploration Model 7 (JEM7), the algorithmic description of the Joint Exploration Test Model 7 (JEM 7), ISO / IEC JTC1 / SC29 / WG11 document: JVET-G1001 (July 2017, Torino, Italy), incorporated herein by reference, describes the coding features under investigation by JVET under the Joint Test Model, which is a potential enhanced video coding technology that exceeds 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 may collectively refer to the algorithms in JEM 7 as well as the specific implementations of the JEM reference software. In addition, in response to the "Joint Call for Proposals on Video Compression with Capabilities beyond HEVC" jointly issued by VCEG and MPEG, at the 10th meeting of ISO / IEC JTC1 / SC29 / WG11 held in San Diego, CA from April 16 to 20, 2018, various groups proposed multiple descriptions of video coding tools.Based on the various descriptions of the video coding tools, the final initial draft text of the video coding specification is described in "Versatile Video Coding (Draft 1)" document JVET-J1001-v2 at the 10th meeting of ISO / IEC JTC1 / SC29 / WG11 held in San Diego, California, April 16-20, 2018, which is incorporated herein by reference and is referred to as JVET-J1001. The current development of the next generation video coding standard by JVET and MPEG is known as the Versatile Video Coding (VVC) project. "Versatile Video Coding (Draft 6)" at the 15th meeting of ISO / IEC JTC1 / SC29 / WG11 held in Gothenburg, Sweden, July 3-12, 2019 (document JVET-O2001-vE, which is incorporated herein by reference and is referred to as JVET-O2001) represents the current version of the draft text of the video coding specification corresponding to the VVC project.

[0004] Video compression technology can reduce the data requirements for storing and transmitting video data. Video compression technology can reduce data requirements by exploiting the redundancy inherent in video sequences. Video compression technology can subdivide a video sequence into successively smaller parts (i.e., a group of pictures within a video sequence, pictures within a group of pictures, regions within pictures, sub-regions within regions, etc.). Intra-frame prediction coding techniques (e.g., spatial prediction techniques within pictures) and inter-frame prediction techniques (i.e., techniques (time) between pictures) can be used to generate the difference between the unit video data to be encoded and the reference unit of the video data. The difference can be referred to as residual data. The residual data can be encoded as quantized transform coefficients. Syntax elements can involve residual data and reference coding units (e.g., intra-frame prediction mode indexes and motion information). The residual data and syntax elements can be entropy encoded. Entropy-encoded residual data and syntax elements can be included in the data structure that forms a compliant bitstream. Summary of the invention

[0005] In one example, a method for decoding picture information for decoding video data is provided, the method comprising: receiving a slice header syntax structure; determining whether the slice header syntax structure includes a picture header syntax structure; and if the slice header syntax structure includes the picture header syntax structure, parsing a first syntax element specifying a picture parameter set identifier from the picture header syntax structure, and parsing a second syntax element specifying a picture sequence count from the picture header syntax structure.

[0006] In one example, a device is provided that includes one or more processors configured to: receive a slice header syntax structure; determine whether the slice header syntax structure includes a picture header syntax structure; and if the slice header syntax structure includes the picture header syntax structure, parse a first syntax element specifying a picture parameter set identifier from the picture header syntax structure, and parse a second syntax element specifying a picture sequence count from the picture header syntax structure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] Figure 2 is a conceptual diagram illustrating encoded video data and corresponding data structures in accordance with one or more techniques of this disclosure.

[0009] Figure 3 is a conceptual diagram illustrating a data structure that encapsulates encoded video data and corresponding metadata in accordance with one or more techniques of this disclosure.

[0010] Figure 4 is a conceptual diagram illustrating an example of components that may be included in an implementation of a system that may be configured to encode and decode video data in accordance with one or more techniques of this disclosure.

[0011] Figure 5 is a block diagram illustrating an example of a video encoder that may be configured to encode video data in accordance with one or more techniques of this disclosure.

[0012] Figure 6 is a block diagram illustrating an example of a video decoder that may be configured to decode video data in accordance with one or more techniques of this disclosure. DETAILED DESCRIPTION

[0013] In general, the present disclosure describes various techniques for encoding video data. Specifically, the present disclosure describes techniques for signaling picture information of encoded video data. It should be noted that although the techniques of the present disclosure are described with respect to ITU-T H.264, ITU-T H.265, JEM and JVET-O2001, the techniques of the present disclosure can be generally applied to video encoding. For example, in addition to those techniques included in ITU-T H.265, JEM and JVET-O2001, the encoding techniques described herein can be incorporated into video encoding systems (including video encoding systems based on future video encoding standards), including video block structures, intra-frame prediction techniques, inter-frame prediction techniques, transform techniques, filtering techniques and / or other entropy encoding techniques. Therefore, references to ITU-T H.264, ITU-T H.265, JEM and / or JVET-O2001 are for descriptive purposes and should not be interpreted as limiting the scope of the techniques described herein. In addition, it should be noted that the incorporation of references herein is for descriptive purposes and should not be construed as limiting or creating ambiguity regarding the terms used herein. For example, where a definition of a term provided in an incorporated reference differs from that provided 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.

[0014] In one example, a method of decoding video data includes: sending a signaling flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally sending a signaling one or more syntax elements in a slice header based on the value of the flag.

[0015] In one example, a device includes one or more processors configured to: send a signaling flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally send a signaling one or more syntax elements in a slice header based on the value of the flag.

[0016] In one example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause one or more processors of a device to: signal a flag in a sequence parameter set having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally signal one or more syntax elements in a slice header based on the value of the flag.

[0017] In one example, an apparatus includes: means for signaling a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and means for conditionally signaling one or more syntax elements in a slice header based on the value of the flag.

[0018] In one example, a method of decoding video data includes: parsing a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally parsing one or more syntax elements in a slice header based on the value of the flag.

[0019] In one example, a device includes one or more processors configured to: parse a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally parse one or more syntax elements in a slice header based on the value of the flag.

[0020] In one example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed, cause one or more processors of a device to: parse a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally parse one or more syntax elements in a slice header based on the value of the flag.

[0021] In one example, an apparatus includes: means for parsing a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and means for conditionally parsing one or more syntax elements in a slice header based on the value of the flag.

[0022] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

[0023] The video content includes a video sequence consisting of a series of frames (or pictures). A series of frames may also be referred to as a group of pictures (GOP). Each video frame or picture may be divided into one or more regions. The region may be defined according to a basic unit (e.g., a video block) and a set of rules defining the region. For example, the rule defining the region may be that the region must be an integer number of video blocks arranged in a rectangle. In addition, the video blocks in the region may be sorted according to a scanning mode (e.g., a raster scan). As used herein, the term "video block" may generally refer to a region of a picture, or may more specifically refer to a maximum array of sample values ​​that may be predictively encoded, its sub-partitions, and / or corresponding structures. In addition, the term "current video block" may refer to a region of a picture 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, a pixel value may be described as a sample value comprising a corresponding component of video data, which may also be referred to as a color component (e.g., brightness (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" may be used interchangeably. Additionally, in some cases, a pixel or sample may be referred to as a pel. A video sampling format (which may also be referred to as a chroma format) may define the number of chroma samples included in a video block relative to the number of luma samples included in the video block. For example, for a 4:2:0 sampling format, the sampling rate of the luma component is twice the sampling rate of the chroma components in both the horizontal and vertical directions.

[0024] The video encoder may perform predictive coding on a video block and its sub-partitions. A video block and its sub-partitions may be referred to as a node. ITU-T H.264 specifies a macroblock including 16×16 luma samples. That is, in ITU-T H.264, a picture is segmented into macroblocks. ITU-T H.265 specifies a similar coding tree unit (CTU) structure (which may be referred to as a maximum coding unit (LCU)). In ITU-T H.265, a picture is segmented into CTUs. In ITU-T H.265, for a picture, the CTU size may be set to include 16×16, 32×32, or 64×64 luma samples. In ITU-T H.265, a CTU consists of a corresponding coding tree block (CTB) for each component of the video data, such as luma (Y) and chroma (Cb and Cr). It should be noted that a video having one luma component and two corresponding chroma components may be described as having two channels, i.e., a luma channel and a chroma channel. In addition, in ITU-T H.265, CTUs can be divided according to a quadtree (QT) partitioning structure, which allows the CTBs of a CTU to be divided into coding blocks (CBs). That is, in ITU-T H.265, CTUs can be divided into quadtree leaf nodes. According to ITU-T H.265, a luma CB together with two corresponding chroma CBs and associated syntax elements is called a coding unit (CU). In ITU-TH.265, a signal can be sent to notify the minimum allowed size of a CB. In ITU-T H.265, the minimum allowed minimum size of a luma CB is 8×8 luma samples. In ITU-T H.265, the decision to encode a picture area using intra prediction or inter prediction is made at the CU level.

[0025] In ITU-T H.265, a CU is associated with a prediction unit (PU) structure having its root at the CU. In ITU-T H.265, the PU structure allows the partitioning of luma CB and chroma CB to generate corresponding reference samples. That is, in ITU-T H.265, the luma CB and chroma CB can be partitioned into corresponding luma prediction blocks and chroma prediction blocks (PBs), where the PBs include blocks of sample values ​​to which the same prediction is applied. In ITU-T H.265, the CB can be divided into 1, 2, or 4 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 prediction, where the CB can form a PB or the CB can be partitioned into four square PBs. In ITU-T H.265, in addition to square PBs, rectangular PBs are also supported for inter prediction, where the CB can be halved vertically or horizontally to form a PB. Furthermore, it should be noted that in ITU-T H.265, for inter prediction, four asymmetric PB partitions are supported, where a CB is divided into two PBs at one quarter of the height (top or bottom) or width (left or right) of the CB. Intra prediction data (e.g., intra prediction mode syntax element) or inter prediction data (e.g., motion data syntax element) corresponding to the PB is used to generate reference and / or prediction sample values ​​for the PB.

[0026] JEM specifies a CTU with a maximum size of 256×256 luma 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 the 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-O2001, CTUs are divided according to a quadtree plus multi-type tree (QTMT or QT+MTT) structure. The QTMT in JVET-O2001 is similar to the QTBT in JEM. However, in JVET-O2001, in addition to indicating binary partitioning, the multi-type tree can also indicate the so-called ternary (or ternary tree (TT)) partitioning. The ternary partitioning divides a block into three blocks vertically or horizontally. In case of vertical TT splitting, the block is split at one quarter of its width from the left edge and at one quarter of its width from the right edge, and in case of horizontal TT splitting, the block is split at one quarter of its height from the top edge and at one quarter of its height from the bottom edge.

[0027] As described above, each video frame or picture may be divided into one or more regions. For example, according to ITU-T H.265, each video frame or picture may be divided into one or more slices, and further divided into one or more tiles, wherein each slice includes a CTU sequence (e.g., arranged in raster scan order), and wherein the tile is a CTU sequence 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 starting from an independent slice segment and containing all subsequent subordinate slice segments (if any) before the next independent slice segment (if any). Slice segments (such as slices) are CTU sequences. Therefore, in some cases, the terms "slice" and "slice segment" may be used interchangeably to indicate a sequence of CTUs arranged in raster scan order. In addition, it should be noted that in ITU-T H.265, a tile may be composed of CTUs contained in more than one slice, and a slice may be composed of CTUs contained in more than one tile. However, ITU-T H.265 specifies that one or both of the following conditions should 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.

[0028] Regarding JVET-O2001, a slice needs to consist of an integer number of bricks, rather than just an integer number of CTUs. It should be noted that in JVET-O2001, the slice design does not include slice segments (i.e., there are no independent / dependent slice fragments). In JVET-O2001, a brick is a rectangular CTU row area within a specific tile in a picture. In addition, in JVET-O2001, a tile can be divided into multiple bricks, each brick consisting of one or more CTU rows within a tile. Tiles that are not divided into multiple bricks are also referred to as bricks. However, bricks that are true subsets of tiles are not referred to as tiles. Therefore, in some video coding techniques, slices that include a group of CTUs that do not form a rectangular area of ​​a picture may or may not be supported. In addition, it should be noted that in some cases, a slice may need to consist of an integer number of complete tiles, and in this case, the slice is referred to as a tile group. The techniques described herein may be applicable to bricks, slices, tiles, and / or tile groups. Figure 2 is a conceptual diagram showing an example of a picture group including slices. Figure 2 In the example shown, Pic3 is shown to include two slices (ie, slice 0 and slice 1). Figure 2 In the example shown, slice 0 includes one brick, brick 0, and slice 1 includes two bricks, brick 1 and brick 2. It should be noted that in some cases, slice 0 and slice 1 may meet the requirements of a tile and / or tile group and be classified as a tile and / or tile group.

[0029] For intra-frame prediction coding, the intra-frame prediction mode may specify the location of the reference sample within the picture. In ITU-TH.265, the possible intra-frame prediction modes defined include a plane (ie, surface fitting) prediction mode, a DC (ie, flat overall average) prediction mode, and 33 angular prediction modes (predMode:2-34). In JEM, the possible intra-frame prediction modes defined include a plane prediction mode, a DC prediction mode, and 65 angular prediction modes. It should be noted that the plane prediction mode and the DC prediction mode may be referred to as non-directional prediction modes, and the angular prediction mode may be referred to as a directional prediction mode. It should be noted that the techniques described herein may be generally applicable regardless of the number of possible prediction modes defined.

[0030] For inter-frame prediction coding, a reference picture is determined, and a motion vector (MV) identifies samples in the reference picture that are used to generate a prediction for the current video block. For example, the current video block may be predicted using reference sample values ​​located in one or more previously coded pictures, and a motion vector is used to indicate the position of the reference block relative to the current video block. The motion vector may describe, for example, the horizontal displacement component of the motion vector (i.e., the MV x ), the vertical displacement component of the motion vector (i.e., MV y) and the resolution of the motion vector (e.g., quarter pixel precision, half pixel precision, one pixel precision, two pixel precision, four pixel precision). Previously decoded pictures (which may include pictures output before or after the current picture) may be organized into one or more reference picture lists and identified using reference picture index values. In addition, in inter-frame prediction coding, uni-prediction refers to generating predictions using sample values ​​from a single reference picture, and bi-prediction refers to generating predictions using corresponding sample values ​​from two reference pictures. That is, in uni-prediction, a single reference picture and a corresponding motion vector are used to generate a prediction for the current video block, while in bi-prediction, a first reference picture and a corresponding first motion vector and a second reference picture and a corresponding second motion vector are used to generate a prediction for the current video block. In bi-prediction, corresponding sample values ​​are combined (e.g., added, rounded and cropped, or averaged according to weights) to generate a prediction. Pictures and their regions may be classified based on what types of prediction modes are available for encoding their video blocks. That is, for a region with a B type (e.g., a B slice), bi-prediction, uni-prediction, and intra-prediction modes can be utilized, for a region with a P type (e.g., a P slice), uni-prediction and intra-prediction modes can be utilized, and for a region with an I type (e.g., an I slice), only an intra-prediction mode can be utilized. As described above, a reference picture is identified by a reference index. For example, for a P slice, there may be a single reference picture list RefPicList0, and for a B slice, there may be a second independent reference picture list RefPicList1 in addition to RefPicList0. It should be noted that for uni-prediction in a B slice, one of RefPicList0 or RefPicList1 may be used to generate a prediction. Furthermore, it should be noted that during the decoding process, when decoding of a picture starts, a reference picture list is generated from a previously decoded picture stored in a decoded picture buffer (DPB).

[0031] In addition, the coding standard may support various motion vector prediction modes. Motion vector prediction enables the value of the motion vector for the current video block to be derived based on another motion vector. For example, a set of candidate blocks with associated motion information can be derived from the spatial neighboring blocks and the temporal neighboring blocks of the current video block. In addition, 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), so-called "merge" mode, and "skip" and "direct" motion reasoning. In addition, other examples of motion vector prediction include advanced temporal motion vector prediction (ATMVP) and space-time motion vector prediction (STMVP). For motion vector prediction, both the video encoder and the 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.

[0032] As described above, for inter-frame prediction coding, reference samples in a previously encoded picture are used to encode a video block in the current picture. Previously encoded pictures that can be used as references when encoding the current picture are called reference pictures. It should be noted that the decoding order does not necessarily correspond to the picture output order, i.e., the temporal order of pictures in a video sequence. In ITU-T H.265, when a picture is decoded, it is stored in a decoded picture buffer (DPB) (which may be referred to as a frame buffer, a reference buffer, a reference picture buffer, etc.). In ITU-T H.265, pictures stored in the DPB are removed from the DPB when they are output and are no longer needed for encoding subsequent pictures. In ITU-T H.265, the determination of whether the picture should be removed from the DPB is called once for each picture after decoding the slice header, i.e., at the beginning of decoding the picture. For example, the reference Figure 2 , Pic3 is shown as referring to Pic2. Similarly, Pic4 is shown as referring to Pic1. Figure 2, assuming the number of pictures corresponds to the decoding order, the DPB will be filled as follows: after decoding Pic1, the DPB will include {Pic1}; at the start of decoding Pic2, the DPB will include {Pic1}; after decoding Pic2, the DPB will include {Pic1, Pic2}; at the start of decoding Pic3, the DPB will include {Pic1, Pic2}. Pic3 will then be decoded with reference to Pic2, and after decoding Pic3, the DPB will include {Pic1, Pic2, Pic3}. At the start of decoding Pic4, pictures Pic2 and Pic3 will be marked for removal from the DPB because they are not required for decoding Pic4 (or any subsequent pictures, not shown), and assuming that Pic2 and Pic3 have been output, the DPB will be updated to include {Pic1}. Pic4 will then be decoded with reference to Pic1. The process of marking pictures to remove them from the DPB can be called reference picture set (RPS) management.

[0033] As described above, intra prediction data or inter prediction data is used to generate reference sample values ​​for a block of sample values. The difference between the sample values ​​included in the current PB or another type of picture area structure and the associated reference samples (e.g., those generated using prediction) can be referred to as residual data. The residual data may include a corresponding difference array corresponding to each component of the video data. The residual data may be in the pixel domain. A transform such as a discrete cosine transform (DCT), a discrete sine transform (DST), an integer transform, a wavelet transform, or a conceptually similar transform may be applied to the difference array to generate transform coefficients. It should be noted that in ITU-T H.265 and JVET-O2001, a CU is associated with a transform unit (TU) structure having its root at the CU level. That is, in order to generate transform coefficients, the array of difference values ​​may be divided (e.g., four 8×8 transforms may be applied to a 16×16 residual value array). For each component of the video data, such a subdivision of the difference value may be referred to as a transform block (TB). It should be noted that in some cases, a core transform and a subsequent secondary transform may be applied (in a video encoder) to generate transform coefficients. For the video decoder, the order of transforms is reversed.

[0034] The quantization process can be performed directly on the transform coefficients or residual sample values ​​(for example, in the case of palette coding quantization). Quantization approximates the transform coefficients by limiting the amplitude to a set of specified values. Quantization essentially scales the transform coefficients to change the amount of data required to represent a set of transform coefficients. Quantization can include dividing the transform coefficients (or the values ​​obtained by adding the offset value to the transform coefficients) by the quantization scaling factor and any associated rounding function (for example, rounding to the nearest integer). The quantized transform coefficients can be referred to as coefficient level values. Inverse quantization (or "dequantization") can include multiplying the coefficient level value with the quantization scaling factor, as well as any reciprocal rounding or offset addition operations. It should be noted that, as used herein, the term quantization process may refer to dividing by the scaling factor to generate the level value in some cases, and may refer to multiplying by the scaling factor to restore the transform coefficient in some cases. That is, the quantization process may refer to quantization in some cases, and may refer to inverse quantization in some cases. In addition, it should be noted that although the quantization process is described in some of the examples below with respect to arithmetic operations associated with decimal notation, such description is for illustrative purposes and should not be construed as limiting. For example, the techniques described herein can be implemented in devices that use binary operations, etc. For example, the multiplication and division operations described herein can be implemented using shift operations, etc.

[0035] The quantized transform coefficients and syntax elements (e.g., syntax elements indicating the coding structure of the video block) may be entropy encoded according to an entropy coding technique. The entropy coding process includes 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 partitioning entropy coding (PIPE), etc. The entropy-encoded quantized transform coefficients and the corresponding entropy-encoded syntax elements may form a compliant bitstream that can be used to reproduce video data at a video decoder. An entropy coding process, such as CABAC, may include binarizing the syntax elements. Binarization refers to the process of converting the value of a syntax element 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 the 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 example of CABAC, for a particular bin, the context provides a maximum probability state (MPS) value of the bin (i.e., the MPS of the bin is one of 0 or 1), and a probability value that the bin is an MPS or a minimum probability state (LPS). For example, the context may indicate that the MPS of the bin 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 value of the previously encoded bin including the bin in the current syntax element and the previously encoded syntax element. For example, the values ​​of syntax elements associated with neighboring video blocks may be used to determine the context of the current bin.

[0036] For the formulas used in this article, the following arithmetic operators can be used:

[0037] Additionally, the following math functions are available:

[0038] Log2(x), the base 2 logarithm of x;

[0039]

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

[0041] With respect to the exemplary syntax used herein, the following definitions of logical operators may be applied:

[0042] x&&y Boolean logical "AND" of x and y

[0043] x||y Boolean logical OR of x and y

[0044] !Boolean logic "NO"

[0045] x ? y : z If x is TRUE or not equal to 0, it evaluates to y; otherwise, it evaluates to z.

[0046] Additionally, the following relational operators can be applied:

[0047] Furthermore, it should be noted that among the syntax descriptors used in this document, the following descriptors may be applied:

[0048] - b(8): A byte (8 bits) with any bit pattern. The parsing of this descriptor is specified by the return value of the function read_bit(8).

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

[0050] - se(v): signed integer order 0 Exp-Golomb coded syntax element, starting from the leftmost bit.

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

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

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

[0054] - ue(v): unsigned integer 0th order Exp-Golomb coded syntax element, starting from the leftmost bit.

[0055] As described above, the video content includes a video sequence consisting of a series of frames (or pictures), and each video frame or picture can be divided into one or more regions. A coded video sequence (CVS) can be encapsulated (or structured) as a series of access units, each of which includes video data configured as a network abstraction layer (NAL) unit. It should be noted that in some cases, an access unit may be required to accurately contain a coded picture. The bitstream can be described as including a sequence of NAL units that form one or more CVSs. It should be noted that the multi-layer extension enables video presentation to include a base layer and one or more additional enhancement layers. For example, the base layer can enable the presentation of a video presentation with a basic quality level (e.g., high-definition presentation and / or a 30Hz frame rate), and the enhancement layer can enable the presentation of a video presentation with an enhanced quality level (e.g., ultra-high-definition rendering and / or a 60Hz frame rate). The enhancement layer can be encoded by referring to the base layer. That is, for example, the picture in the enhancement layer can be encoded (e.g., using an inter-layer prediction technique) by referring to one or more pictures in the base layer (including a scaled version thereof). Each NAL unit may include an identifier indicating the video data layer with which the NAL unit is associated. It should be noted that 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). Layers can also be encoded independently of each other. In this case, there may be no inter-layer prediction between the two layers.

[0056] refer to Figure 2In the example shown in , each video data slice included in Pic3 (i.e., slice 0 slice 1) is shown as being encapsulated in a NAL unit. In JVET-O2001, each of a video sequence, a GOP, a picture, a slice, and a CTU can be associated with metadata describing video coding attributes. JVET-O2001 defines parameter sets that can be used to describe video data and / or video coding attributes. Specifically, JVET-O2001 includes the following five types of parameter sets: decoding parameter set (DPS), video parameter set (VPS), sequence parameter set (SPS), picture parameter set (PPS), and adaptive parameter set (APS). In JVET-O2001, parameter sets can be encapsulated as special types of NAL units, or can be signaled as messages. A NAL unit including coded video data (e.g., a slice) can be referred to as a VCL (video coding layer) NAL unit, and a NAL unit including metadata (e.g., a parameter set) can be referred to as a non-VCL NAL unit. In addition, JVET-O2001 enables supplemental enhancement information (SEI) messages to be signaled. In JVET-O2001, SEI messages assist processes related to decoding, display, or other purposes, however, SEI messages may not be required to construct luma or chroma samples through the decoding process. In JVET-O2001, SEI messages may be signaled in the bitstream using non-VCL NAL units. In addition, SEI messages may be transmitted in a manner other than by being present in the bitstream (i.e., signaled out-of-band).

[0057] Figure 3 An example of a bitstream including a plurality of CVSs is shown, wherein the CVSs are represented by NAL units included in corresponding access units. Figure 3 In the example shown, the non-VCL NAL units include corresponding parameter set NAL units (i.e., sequence parameter set (SPS) and picture parameter set (PPS) NAL units), SEI message NAL units, and access unit delimiter NAL units. Figure 3 In JVET-O2001, HEADER is the NAL unit header. JVET-O2001 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-O2001.

[0058]

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

[0060] forbidden_zero_bit should be equal to 0.

[0061] nuh_reserved_zero_bit shall be equal to "0". The value of nuh_reserved_zero_bit may be specified by ITU-T IISO / IEC in the future as 1. A decoder shall ignore (i.e., remove from the bitstream and discard) NAL units with nuh_reserved_zero_bit equal to "1".

[0062] nuh_layer_id specifies the identifier of the layer to which the VCL NAL unit belongs or the identifier of the layer to which the non-VCL NAL unit applies.

[0063] The value of nah_layer_id shall be the same for all VCL NAL units of a coded picture. The value of nah_layer_id of a coded picture or layer access unit is the value of nah_layer_id of the VCL NAL unit of the coded picture or layer access unit.

[0064] nuh_temporal_id_plus1 minus 1 specifies the temporal identifier of the NAL unit. The value of nuh_temporalid_plus1 shall not be equal to 0.

[0065] The variable Temporalid is derived as follows:

[0066] TemporalId= nuh_temporal_id_plus1 - 1

[0067] When nal_unit_type is in the range of IDR_W_RADL to RSV IRAP VCL13 (inclusive), TemporalId shall be equal to 0.

[0068] When nal_unit_type is equal to STSA_NUT, TemporalId shall be equal to 0.

[0069] The value of TemporalId for all VCL NAL units of a layer access unit shall be the same. The value of TemporalId for a coded picture or layer access unit is the value of the Temporalid of the VCL NAL units of the coded picture or layer access unit. The value of TemporalId for a sub-layer representation is the maximum value of the TemporalId of all VCL NAL units in the sub-layer representation.

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

[0071] - If nal_unit_type is equal to DPS_NUT, VPS_NUT or SPS_NUT, TemporalId is equal to 0 and the TemporalId of the layer access unit containing the NAL unit shall be equal to 0.

[0072] - Otherwise, when nal_unit_type is not equal to EOS_NUT and is not equal to EOB_NUT, TemporalId shall be greater than or equal to the TemporalId of the layer access unit containing the NAL unit.

[0073] NOTE - When the NAL unit is a non-VCL NAL unit, the value of TemporalId is equal to the minimum of the TemporalId values ​​of all layer access units to which the non-VCL NAL unit applies. When nal_unit_type is equal to PPS_NUT or APS_NUT, TemporalId may be greater than or equal to the TemporalId of the containing layer access unit, because all PPS and APS may be included in the beginning of the bitstream, where the first coded picture has a TemporalId equal to 0. When nal_unit_type is equal to PREFIX_SEI_NUT or SUFFIX_SEI NUT, TemporalId may be greater than or equal to the TemporalId of the containing layer access unit, because a SEI NAL unit may contain information that applies to a subset of the bitstream that includes layer access units whose TemporalId values ​​are greater than the TemporalId of the layer access unit containing the SEI NAL unit.

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

[0075] NAL units with a nal_unit_type in the range of UNSPEC28 ... UNSPEC31 (inclusive), whose semantics are unspecified, shall not affect the decoding process specified in this specification.

[0076] Note - NAL unit types within the range of UNSPEC28 ... UNSPEC31 may be used as determined by the application. The decoding process for these values ​​of nal_unit_type is not specified in this specification. Since different applications may use these NAL unit types for different purposes, special attention must be paid when designing encoders that generate NAL units with these nal_unit_type values ​​and when designing decoders that interpret the content of NAL units with these nal_unit_type values. This specification does not define any management of these values. These nal_unit_type values ​​may only be used in contexts where the use of "conflicts" (i.e., the meaning of the NAL unit content of the same nal_unit_type value has different definitions) is not important, or is impossible or managed, for example, defined or managed in a control application or transport specification, or managed by controlling the environment in which the bitstream is distributed.

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

[0078] NOTE - This requirement allows for the definition of compatible extensions of this specification in the future.

[0079]

[0080]

[0081] NOTE—A clean random access (CRA) picture may have an associated RASL or RADL picture present in the bitstream.

[0082] NOTE - An Instantaneous Decoding Refresh (IDR) picture with nal_unit_type equal to IDR_N_LP does not have an associated leading picture present in the bitstream. An IDR picture with nal_unit_type equal to IDR_W_RADL does not have an associated RASL picture present in the bitstream, but may have an associated RADL picture in the bitstream.

[0083] The value of nal_unit_type shall be the same for all coded NAL units of a picture. A picture or layer access unit is said to have the same NAL unit type as the coded slice NAL unit of the picture or layer access unit.

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

[0085] - Every picture except the first picture in decoding order in the bitstream is considered to be associated with the previous IRAP picture in decoding order.

[0086] - When a picture is the leading picture of an IRAP picture, the picture shall be a RADL or RASL picture.

[0087] - When a picture is a trailer picture of an IRAP picture, the picture shall not be a RADL or RASL picture.

[0088] - RASL pictures shall not be present in the bitstream, these RASL pictures are associated with IDR pictures.

[0089] - RADL pictures shall not be present in the bitstream that are associated with an IDR picture with nal_unit_type equal to IDR_N_LP.

[0090] NOTE - Random access at the location of an IRAP access unit can be performed by discarding all access units preceding the IRAP access unit (and correctly decoding the IRAP picture and all subsequent non-RASL pictures in decoding order), provided that every parameter set (in the bitstream or by external means) is available when referenced.

[0091] - Any picture that precedes an IRAP picture in decoding order shall precede the TRAP picture in output order, and shall precede any RADL pictures associated with the IRAP picture in output order.

[0092] - Any RASL pictures associated with a CRA picture shall precede any RADL pictures associated with the CRA picture in output order.

[0093] - Any RASL pictures associated with a CRA picture shall follow, in output order, any IRAP pictures that precede the CRA picture in decoding order.

[0094] - If field_seq_flag is equal to 0, and the current picture is a leading picture associated with an IRAP picture, then the current picture shall precede all non-leading pictures associated with the same TRAP picture in decoding order. Otherwise, let picA and picB be the first leading picture and the last leading picture associated with the TRAP picture, respectively, in decoding order, there shall be at most one non-leading picture before picA in decoding order, and there shall be no non-leading pictures between picA and picB in decoding order.

[0095] It should be noted that, in general, for example, with respect to ITU-T H.265, an IRAP is a picture that does not reference any picture other than itself for prediction during its decoding process. Typically, the first picture in the decoding order in the bitstream must be an IRAP picture. In ITU-T H.265, an IRAP picture can be a broken link access (BLA) picture, a clean random access (CRA) picture, or an instantaneous decoding refresh (IDR) picture. ITU-T H.265 describes the concept of a leading picture, which is a picture that precedes the associated IRAP picture in the output order. ITU-T H.265 also describes the concept of a trailing picture, which is a non-IRAP picture that follows the associated IRAP picture in the output order. Trailing pictures associated with IRAP pictures are also after the IRAP picture in the decoding order. For IDR pictures, there is no need to reference trailing pictures that are decoded before the IDR picture. ITU-T H.265 specifies that a CRA picture may have a leading picture that follows the CRA picture in decoding order and contains inter-picture predictions that reference pictures decoded before the CRA picture. Therefore, when a CRA picture is used as a random access point, these leading pictures may not be decodable and are identified as random access skip leading (RASL) pictures. BLA pictures may also follow RASL pictures. When these RASL pictures are not decodable, that is, when the decoder starts its decoding process at the CRA point, these RASL pictures are always discarded for BLA pictures and for CRA pictures. Another type of picture that may follow an IRAP picture in decoding order and precede an IRAP picture in output order is a random access decodable leading (RADL) picture, which may not contain references to any pictures that precede the IRAP picture in decoding order.

[0096] As provided in Table 2, a NAL unit may include a sequence parameter set (SPS). Table 3 shows the syntax of the SPS provided in JVET-O2001.

[0097]

[0098]

[0099]

[0100]

[0101]

[0102]

[0103] Regarding Table 3, JVET-02001 provides the following semantics:

[0104] The SPS RBSP shall be available to the decoding process before it is referenced, included in at least one access unit with TemporalId equal to 0 or provided by external means, and the SPS NAL unit containing the SPS RBSP shall have a nuh_layer_id equal to the nuh_layer_id of the PPS NAL unit that references it.

[0105] All SPS NAL units with a particular value of sps_seq_parameter_set_id in a CVS shall have the same content.

[0106] When sps_decoding_parameter_set_id is greater than 0, it specifies the value of dps_decoding_parameter_set_id of the DPS referenced by the SPS. When sps_decoding_parameter_set_id is equal to 0, the SPS does not reference the DPS, and when decoding each CVS that references the SPS, the DPS is not referenced. The value of sps_decoding_parameter_set_id should be the same in all SPSs referenced by a coded picture in the bitstream.

[0107] 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 the SPS. When sps_video_parameter_set_id is equal to 0, the SPS does not reference the VPS, and when each CVS that references the SPS is decoded, the VPS is not referenced.

[0108] sps_max_sub_layers_minus1 plus 1 specifies the maximum number of temporal sub-layers that may be present in each CVS referencing the SPS. The value of sps_max_sub_layers_minus1 shall be in the range of 0 to 6, inclusive.

[0109] In bitstreams conforming to this version of this specification, sps_reserved_zero_5bits shall be equal to 0. Other values ​​of sps_reserved_zero_5bits are reserved for future use by ITU-T | ISO / IEC.

[0110] gdr_enabled_flag equal to 1 specifies that GDR pictures may be present in the CVS referencing the SPS. gdr_enabled_flag equal to 0 specifies that GDR pictures are not present in the CVS referencing the SPS.

[0111] sps_seq_parameter_set_id provides an identifier of the SPS for reference by other syntax elements. The value of sps_seq_parameter_set_id shall be in the range of 0 to 15 (inclusive).

[0112] As specified, chroma_format_idc specifies the chroma samples relative to the luma samples. The value of chroma_format_idc shall be in the range of 0 to 3, inclusive.

[0113] Separate_colour_plane_flag equal to 1 specifies that the three colour components of the 4:4:4 chroma format are coded separately. separate_colour_plane_flag equal to 0 specifies that the colour components are not coded separately. When separate_colour_plane_flag is not present, it is inferred to be equal to 0. When separate_colour_plane_flag is equal to 1, the coded picture consists of three separate components, each consisting of coded samples of one colour plane (Y, Cb or Cr) and using the monochrome coding syntax. In this case, each colour plane is associated with a specific colour_plane_id value.

[0114] Note - There is no dependency in the decoding process between colour planes with different values ​​of colour_plane_id. For example, the decoding process of a monochrome picture with one value of colour_plane_id does not use any data from monochrome pictures with different values ​​of colour_plane_id for inter prediction.

[0115] Depending on the value of separate_colour_plane_flag, the value of the variable ChromaArrayType is specified as follows:

[0116] - If separate_colour_plane_flag is equal to 0, ChromaArrayType is set equal to chroma_format_idc.

[0117] - Otherwise (separate_colour_plane_flag is equal to 1), ChromaArrayType is set equal to 0.

[0118] pic_width_x_in_luma_samples specifies the maximum width of each coded picture referencing the SPS, in units of luma samples. pic_width_max_in_luma_samples shall be equal to 0 and shall be an integer multiple of MinCbSizeY.

[0119] pic_height_max_in_luma_samples specifies the maximum height of each coded picture referencing the SPS, in units of luma samples. pic_height_max_in_luma_samples shall be equal to 0 and shall be an integer multiple of MinCbSizeY.

[0120] subpics_present_flag equal to 1 indicates that sub-picture parameters are present in the SPS RBSP syntax. subpics_present_flag equal to 0 indicates that sub-picture parameters are not present in the SPS RBSP syntax.

[0121] NOTE - When the bitstream is the result of a sub-bitstream extraction process and contains only a subset of the sub-pictures of the input bitstream to 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.

[0122] max_subpics_minus1 plus 1 specifies the maximum number of sub-pictures that may be present in the CVS. max_subpics_minus1 shall be in the range 0 to 254. The value 255 is reserved for future use by ITU-T | ISO / IEC.

[0123] subpic_grid_col_width_minus1 plus 1 specifies the width of each element of the sub-picture identifier grid in units of 4 samples. The length of the syntax element is Ceil(Log2(pic_width_max_in_luma_samples / 4)) bits.

[0124] The variable NumSubPicGridCols is derived as follows:

[0125] NumSubPicGridCols =

[0126] (pic_width_max_in_luma_samples + subpic_grid_colwidth_mi nus 1 * 4 +3) / (subpic_grid_col_width_minus1 * 4 + 4)

[0127] subpic_grid_row_height_minus1 plus 1 specifies the height of each element of the sub-picture identifier grid in units of 4 samples. The length of the syntax element is Ceil(Log2(pic_height_max_in_luma_samples / 4)) bits.

[0128] The variable NumSubPicGridRows is derived as follows:

[0129] NumSubPicGridRows =

[0130] (pic_height maxin_luma_samples + subpic_grid_row_height_minus1 *4 +3) / (subpic_grid_row_height_minus1 * 4 + 4)

[0131] subpic_grid_idx[i][j] specifies the subpicture index at grid position (i, j). The length of the syntax element is Ceil(Log2(max subpics minus1 + 1)) bits.

[0132] The variables SubPicTop[ subpic_grid_idx[ i ][ j ] ], SubPicLeft[ subpic_grid_idx[ i ][ j ] ], SubPicWidth[ subpic_grid_idx[ i ][ j ] ], SubPicHeight[ subpic_grid_idx[ i ][ j ] ], and NumSubPics are derived as follows:

[0133]

[0134] subpic_treated_as_pic_flag[i] equal to 1 specifies that the i-th subpicture of each coded picture in the CVS is treated as a picture in the decoding process that does not include in-loop filtering operations. subpic_treated_as_pic_flag[i] equal to 0 specifies that the i-th subpicture of each coded picture in the CVS is not treated as a picture in the decoding process that does not include in-loop filtering operations. When not present, the value of subpic_treated_as_pic_flag[i] is inferred to be equal to 0.

[0135] loop_filter_across_subpic_enabled_flag[ i ] equal to 1 specifies that the in-loop filtering operation may be performed across the boundaries of the i-th sub-picture of each coded picture in the CVS. loop_filter_across_subpic_enabled_flag[ i ] equal to 0 specifies that the in-loop filtering operation is not performed across the boundaries of the i-th sub-picture of each coded picture in the CVS. When not present, the value of loop_filter_across_subpic_enabled_pic_flag[ i ] is inferred to be equal to 1.

[0136] Bitstream conformance requires that the following constraints apply:

[0137] - For any two sub-pictures subpicA and subpicB, when the index of subpicA is less than the index of subpicB, any coded NAL unit of subPicA shall follow any coded NAL unit of subPicB in decoding order.

[0138] - The shape of sub-pictures shall be such that each sub-picture, when decoded, shall have its entire left border and entire top border consisting of the picture border or consisting of the borders of previously decoded sub-pictures.

[0139] bit_depth_luma_minus8 specifies the bit depth of the samples in the luma array BitDepthy and the luma quantization parameter range offset QpBdOffset as follows Y Values:

[0140] BitDepthy = 8 + bit_depth_luma_minus8

[0141] QpBdOffsety = 6 * bit_depth_luma_minus8

[0142] bit_depth_luma_minus8 should be in the range of 0 to 8, inclusive.

[0143] bit_depth_chroma_minus8 specifies the bit depth of the samples of the chroma array BitDepthc and the chroma quantization parameter range offset QpBdOffset as follows C Values:

[0144] BitDepth C = 8 + bit_dcpth_chroma_minus8

[0145] QpBdOffsetC = 6 * bit_depth_chroma_minus8

[0146] bit_depth_chroma_minus8 should be in the range of 0 to 8 (inclusive).

[0147] min_qp_prime_ts_minus4 specifies the minimum allowed quantization parameter for transform skip mode as follows:

[0148] QpPrimeTsMin = 4 + min_qp_prime_ts_minus4

[0149] log2_max_pic_order_cnt_lsb_minus4 specifies the value of the variable MaxPicOrderCntLsb used in the decoding process of the picture order count as follows:

[0150] MaxPicOrderCntLsb = 2 (log2_max_pic_order_cnt_lsb_minus4 + 4)

[0151] The value of log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, inclusive.

[0152] sps_sub_layer_ordering_info_present_flag equal to 1 specifies that sps_max_dec_pic_buffering_minus1[ i ], sps_max_num_reorder_pics[ i ], and sps_max_latency_increase_plus1[ i ] are present for sps_max_sub_layers_minus1 + 1 sublayers. sps_sub_layer_ordering_info_present_flag equal to 0 specifies that the values ​​of sps_max_dec_pic_buffering_minus1[ sps_max_sub_layers_minus1], sps_max_num_reorder_pics[sps_max_sub_layers_minus 1 ], and sps_max_latency_increase_plus1[ sps_max_sub_layers_minus1] apply to all sublayers. When not present, sps_sub_layer_ordering_info_present_flag is inferred to be equal to 0.

[0153] sps_max_dec_pic_buffering_minus1[i] plus 1 specifies the maximum required size of the decoded picture buffer of the CVS when HighestTid is equal to i, in units of picture storage buffers. The value of sps_max_dec_pic_buffering_minus1[i] shall be in the range of 0 to MaxDpbSize-1, inclusive, where MaxDpbSize is as specified elsewhere. When i is greater than 0, sps_max_dec_pic_buffering_minus1[1] shall be greater than or equal to sps_max_dec_pic_buffering_minus1[i - 1]. When sps_max_dec_pic_buffering_minus1[sps_max_sub_layers_minus1] is not present for i in the range of 0 to sps_max_sub_layers_minus1 - 1, inclusive, it is inferred to be equal to sps_max_dec_pic_buffering_minus1[sps_max_sub_layers_minus1] since sps_sub_layer_ordering_info_present_flag is equal to 0.

[0154] sps_max_num_reorder_pics[ i ] indicates the maximum allowed number of pictures that may precede any picture in the CVS in decoding order and follow that picture in output order when HighestTid is equal to i. The value of sps_max_num_reorder_pics[i] shall be in the range of 0 to sps_max_dec_pic_buffering_minus1[ i ], inclusive. When i is greater than 0, sps_max_num_reorder_pics[i] shall be greater than or equal to sps_max_num_reorder_pics[ i - 1 ]. When sps_max_num_reorder_pics[i] is not present for i in the range of 0 to sps_max_sub_layers_minus1 - 1, inclusive, it is inferred to be equal to sps_max_num_reorder_pics[ sps_max_sub_layers_minus1 ] since sps_sub_layer_ordering_info_present_flag is equal to 0.

[0155] sps_max_latency_increase_plus1[i] not equal to 0 is used to calculate the value of SpsMaxLatencyPictures[i], which specifies the maximum number of pictures that may precede any picture in the CVS in output order and follow that picture in decoding order when HighestTid is equal to i.

[0156] When sps_max_latency_increase_plus1[ i ] is not equal to 0, the value of SpsMaxLatencyPictures[ i ] is specified as follows:

[0157] SpsMaxLatencyPictures[ i =

[0158] sps_max_num_reorder_pics[i]+ sps_max_latency_increase_plus1[i]-1

[0159] When sps_max_latency_increase_plusi1[ i ] is equal to 0, no corresponding restriction is indicated.

[0160] The value of sps_max_latency_increase_plus1[ i] should be between 0 and 2. 32 When sps_max_latency_increase_plus1[ i ] is not present for i in the range of 0 to sps_max_sub_layers_minus1 - 1 (inclusive), it is inferred to be equal to sps_max_latency_increase_plus 1 [ sps_max_sub_layers_minus1] since sps_sub_layer_ordering_info_present_flag is equal to 0.

[0161] long_term_ref_pics_flag equal to 0 specifies that no LTRP is used for inter prediction of any coded picture in the CVS. long_term_ref_pics_flag equal to 1 specifies that LTRP may be used for inter prediction of one or more coded pictures in the CVS.

[0162] inter_layer_ref_pics_present_flag equal to 0 specifies that no LTRP is used for inter prediction of any coded picture in the CVS. inter_layerref pics_flag equal to 1 specifies that LTRP may be used for inter prediction of one or more coded pictures in the CVS. When sps_video_parameter_set_id is equal to 0, the value of inter_layer_ref_pics_present_flag is inferred to be equal to 0.

[0163] sps_idr_rp1_present_flag equal to 1 specifies that the reference picture list syntax element is present in the slice header of the IDR picture. sps_idr_rp1_present_flag equal to 0 specifies that the reference picture list syntax element is not present in the slice header of the IDR picture.

[0164] rpl1_same_as_rpl0_flag equal to 1 specifies that the syntax structures num_ref pic_lists_in_sps[ 1 ] and ref pic_list_struct(1, rplsIdx) do not exist and the following apply:

[0165] - The value of num_ref_pic_lists_in sps[ 1 ] is inferred to be equal to the value of num_ref_pic_lists_in_sps[ 0 ].

[0166] - The value of each of the syntax elements in ref_pic_list_struct(1, rplsIdx) is inferred to be equal to the value of the corresponding syntax element in ref_pic_list_stnict(0, rplsIdx) for rplsIdx in the range 0 to num_ref_pic_lists_in_sps[0]-1.

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

[0168] NOTE - For each value of listIdx (equal to 0 or 1), the decoder shall allocate memory for a total of num_ref_pic_lists_in_sps[ i ] + 1 ref_pic_list_struct(listIdx, rplsIdx) syntax structures, since there may be one ref_pic_list_struct(listIdx, rplsIdx) syntax structure signaled directly in the slice header of the current picture.

[0169] qtbtt_dual_tree_intra_flag equal to 1 specifies that, for I slices, each CTU is partitioned into coding units with 64×64 luma samples using implicit quadtree partitioning, 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 is not present, it is inferred to be equal to 0.

[0170] log2_ctu_size_minus5 plus 5 specifies the luma coding tree block size for each CTU. Bitstream conformance requires that the value of log2_ctu_size_minus5 is less than or equal to 2.

[0171] log2_min_luma_coding_block_size_minus2 plus 2 specifies the minimum luma coding block size.

[0172] The variables CtbLog2SizeY, CtbSizeY, MinCbLog2SizeY, MinCbSizeY, IbcBufWidthY, IbcBufWidthC, and Vsize are exported as follows:

[0173] CtbLog2SizeY = log2_ctu_size_minus5 + 5

[0174] CtbSizeY = 1 << CtbLog2SizeY

[0175] MinCbLog2SizeY = log2_min_luma_coding_block_sizeminus2 + 2

[0176] MinCbSizeY = 1 << MinCbLog2SizeY

[0177] IbcBufWidthY = 128 * 128 / CtbSizeY

[0178] IbcBufWidthC = IbcBufWidthY / SubWidthC

[0179] VSize = Min(64, CtbSizeY)

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

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

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

[0183] CtbWidthC = CtbSizeY / SubWidthC

[0184] CtbHeightC = CtbSizeY / SubHeightC

[0185] For log2BlockWidth in the range 0 to 4 and log2BlockHeight in the range 0 to 4 (inclusive), call the specified upper right diagonal and raster scan order array initialization procedures with 1 << log2BlockWidth and 1 << log2BlockHeight as inputs and assign the outputs to DiagScanOrder[log2BlockWidth][log2BlockHeight] and Raster2DiagScanPos[log2BlockWidthlog2BlockHeight].

[0186] For log2BlockWidth in the range 0 to 6 and log2BlockHeight in the range 0 to 6 (inclusive), call the specified horizontal and vertical traverse scan order array initialization procedures with 1 << log2BlockWidth and 1 << log2BlockHeight as input, and assign the output to HorTravScanOrder[log2BlockWidth][log2BlockHeight] and VerTravScanOrder[log2BlockWidth][log2BlockHeight].

[0187] partition_constraints_override_enabled_flag equal to 1 specifies that partition_constraints_override_flag is present in the slice header of the slices referencing the SPS. partition_constraints_override_enabled_flag equal to 0 specifies that partition_constraints_override_flag is not present in the slice header of the slices referencing the SPS.

[0188] sps_log2_diff_min_qt_min_cb_intra_slice_luma specifies the default difference between the base 2 logarithm of the minimum size in luma samples of the luma leaf blocks resulting from quadtree partitioning of a CTU and the base 2 logarithm of the minimum coding block size in luma samples of the luma CU in the slice whose slice_type is equal to 2(I) that references the SPS. This default difference can be overridden by slice_log2_diff_min_qt_min_cb_luma present in the slice header of the slice that references the SPS when partition_constraints_override_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 minimum size in luma samples of the luma leaf blocks resulting from quadtree partitioning of a CTU is derived as follows:

[0189] MinQtLog2SizeIntraY=sps_log2_diff_min_qt_min_cb_intra_slice_luma +MinCbLog2SizeY

[0190] sps_log2_diff_min_qt_min_cb_inter_slice specifies the default difference between the base 2 logarithm of the minimum size in luma samples of the luma leaf blocks resulting from quadtree partitioning of a CTU and the base 2 logarithm of the minimum luma coding block size in luma samples of the luma CU in the slice whose slice_type references the SPS equals 0 (B) or 1 (P). This default difference can be overridden by slice_log2_diff_min_qt_min_cb_luma present in the slice header of the slice referencing the SPS when partition_constraints_override_flag is equal to 1. The value of sps log2_diff_min_qt_min_cb_inter_slice should be in the range of 0 to CtbLog2SizeY - MinCbLog2SizeY, inclusive. The base 2 logarithm of the minimum size in luma samples of the luma leaf blocks resulting from quadtree partitioning of a CTU is derived as follows:

[0191] MinQtLog2SizenterY = sps_log2_diff_min_qt_min_cb_interslice +MinCbLog2SizeY

[0192] sps_max_mtt_hierarchy_depth_inter_slice specifies the default maximum hierarchical depth of coding units produced by multi-type tree partitioning of quadtree leaves in slices with slice_type equal to 0 (B) or 1 (P) that reference the SPS. When partition_constraints_override_flag is equal to 1, the default maximum hierarchical depth can be overwritten by slice_max_mtt_hierarchy_depth_luma present in the slice header of the slice that references the SPS. The value of sps_max_mtt_hierarchy_depth_inter_slice should be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.

[0193] sps_max_mtt_hierarchy_depth_intra_slice_luma specifies the default maximum hierarchy depth for coding units resulting from multi-type tree partitioning of quadtree leaves in slices with slice_type equal to 2 (I) that reference an SPS. The default maximum hierarchy depth may be overridden by slice_max_mtt_hierarchy_depth_luma in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_max_mtt_hierarchy_depth_intra_slice_luma shall be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive.

[0194] sps_log2_diff_max_bt_min_qt_intra_slice_luma specifies the default difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can be binary partitioned and the base-2 logarithm of the minimum size (width or height) in luma samples of luma leaf blocks resulting from quadtree partitioning of CTUs in slices that reference the SPS with slice_type equal to 2 (I). This default difference may be overridden by slice_log2_diff_max_bt_min_qt_luma present in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_max_bt_min_qt_intra_slice_luma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeIntraY, inclusive. When sps_log2_diff_max_bt_min_qt_intra_slice_luma is not present, the value of sps_log2_diff_max_bt_min_qt_intra_slice_luma is inferred to be equal to 0.

[0195] sps_log2_diff_max_tt_min_qt_intra_slice_luma specifies the default difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can use ternary partitioning and the base-2 logarithm of the minimum size (width or height) in luma samples of luma leaf blocks resulting from quadtree partitioning of CTUs in slices that reference the SPS with slice_type equal to 2 (I). This default difference can be overridden by slice_log2_diff_max_tt_min_qt_luma present in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_max_tt_min_qt_intra_slice_luma should be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeIntraY, inclusive. When sps_log2_diff_max_tt_min_qt_intra_slice_luma is not present, the value of sps_log2_diff_max_tt_min_qt_intra_slice_luma is inferred to be equal to 0.

[0196] sps_log2_diff_max_bt_min_qt_inter_slice specifies the default difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can use binary partitioning and the base-2 logarithm of the minimum size (width or height) in luma samples of luma leaf blocks resulting from quadtree partitioning of CTUs in slices with slice_type equal to 0 (B) or 1 (P) that reference the SPS. This default difference can be overridden by slice_log2_diff_max_bt_min_qt_luma present in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_max_bt_min_qt_inter_slice shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizelnterY, inclusive. When sps_log2_diff_max_bt_min_qt_inter_slice is not present, the value of sps_log2_diff_max_bt_min_qt_inter_slice is inferred to be equal to 0.

[0197] sps_log2_diff_max_tt_min_qt_inter_slice specifies the default difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can use ternary partitioning and the base-2 logarithm of the minimum size (width or height) in luma samples of luma leaf blocks resulting from quadtree partitioning of CTUs in slices with slice_type equal to 0 (B) or 1 (P) that reference the SPS. This default difference can be overridden by slice_log2_diff_max_tt_min_qt_luma present in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_inax_tt_min_qt_inter_slice should be in the range of 0 to CtbLog2SizeY-MinQtLog2SizeInterY, inclusive. When sps_log2_diff_max_tt_min_qt_inter_slice is not present, the value of sps_log2_diff_max_tt_min_qt_inter_slice is inferred to be equal to 0.

[0198] sps_log2_diff_min_qt_min_cb_intra_slice_chroma specifies the default difference between the base-2 logarithm of the minimum size in luma samples of chroma leaf blocks resulting from quadtree partitioning of chroma CTUs with treeType equal to DUAL_TREE_CHROMA and the base-2 logarithm of the minimum coding block size in luma samples of chroma CUs with treeType equal to DUAL_TREE_CHROMA in slices with slice_type equal to 2(I) referencing the SPS. This default difference may be overridden by slice_log2_diff_min_qt_min_cb_chroma present in the slice header of the slice referencing the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_min_qt_min_cb_intra_slice_chroma shall be in the range of 0 to CtbLog2SizeY - MinChLog2SizeY, inclusive. When not present, the value of sps_log2_diff_min_qt_min_cb_intra_slice_chroma is inferred to be equal to 0. The base-2 logarithm of the minimum size among luma samples of chroma leaf blocks resulting from quadtree partitioning of a CTU with treeType equal to DUAL_TREE_CHROMA is derived as follows:

[0199] MinQtLog2SizeIntraC=sps_log2_diff_min_qt_min_cb_intra_slice_chroma +MinCbLog2SizeY

[0200] sps_max_mtt_hierarchy_depth_intra_slice_chroma specifies the default maximum hierarchical depth of chroma coding units produced by multi-type tree partitioning of chroma quadtree leaves with treeType equal to DUAL_TREE_CHROMA in slices with slice_type equal to 2 (I) that reference the SPS. When partition_constraints_override_flag is equal to 1, the default maximum hierarchical depth can be overridden by slice_max_mtt_hierarchy_depth_chroma in the slice header of the slice that references the SPS. The value of sps_max_mtt_hierarchy_depth_intra_slice_chroma should be in the range of 0 to CtbLog2SizeY-MinCbLog2SizeY, inclusive. When not present, the value of sps_max_mtt_hierarchy_depth_intra_slice_chroma is inferred to be equal to 0.

[0201] sps_log2_diff_max_bt_min_qt_intra_slice_chroma specifies the default difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a chroma coded block that can be binary partitioned and the base-2 logarithm of the minimum size (width or height) in luma samples of chroma leaf blocks resulting from quadtree partitioning of chroma CTUs with treeType equal to DUAL_TREE_CHROMA in slices with slice_type equal to 2 (I) that reference the SPS. This default difference may be overridden by slice_log2_diff_max_bt_min_qt_chroma present in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_max_bt_min_qt_intra_slice_chroma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeIntraC, inclusive. When sps_log2_diff_max_bt_min_qt_intra_slice_chroma is not present, the value of sps_log2_diff_max_bt_min_qt_intra_slice_chroma is inferred to be equal to 0.

[0202] sps_log2_diff_max_tt_min_qt_intra_slice_chroma specifies the default difference between the base-2 logarithm of the maximum size (width or height) in luma samples of chroma coding blocks that can use ternary partitioning and the base-2 logarithm of the minimum size (width or height) in luma samples of chroma leaf blocks resulting from quadtree partitioning of chroma CTUs with treeType equal to DUAL_TREE_CHROMA in slices with slice_type equal to 2 (I) that reference the SPS. This default difference may be overridden by slice_log2_diff_max_tt_min_qt_chroma present in the slice header of the slice that references the SPS when partition_constraints_override_flag is equal to 1. The value of sps_log2_diff_max_tt_min_qt_intra_slice_chroma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeIntraC, inclusive. When sps_log2_diff_max_tt_min_qt_intra_slice_chroma is not present, the value of sps_log2_diff_max_tt_min_qt_intra_slice_chroma is inferred to be equal to 0.

[0203] sps_max_lumatransform_size_64_flag equal to 1 specifies that the maximum transform size in luma samples is equal to 64. sps_max_luma_transform_size_64_flag equal to 0 specifies that the maximum transform size in luma samples is equal to 32. When CtbSizeY is less than 64, the value of sps_max_luma_transform_size_64_flag shall be equal to 0.

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

[0205] MinTbLog2SizeY = 2

[0206] MaxTbLog2SizeY = sps_max_luma_transform_size_64_flag ? 6: 5

[0207] MinTbSizeY = 1 << MinTbLog2SizeY

[0208] MaxTbSizeY = 1 << MaxTbLog2SizeY

[0209] same_qp_table_for_chroma equal to 1 specifies that only one chroma QP mapping table is signaled and that this table applies to both Cb and Cr residuals and joint Cb-Cr residuals. same_qp_table_for_chroma equal to 0 specifies that three chroma QP mapping tables are signaled in the SPS. When same_qp_table_for_chroma is not present in the bitstream, the value of same_qp_table_for_chroma is inferred to be equal to 1.

[0210] num_points_in_qp_table_rainus1[ i ] plus 1 specifies the number of points used to describe the i-th chroma QP map table. The value of num_points_in_qp_table_minus1[ i ] shall be in the range of 0 to 63 + QpBdOffsetc, inclusive. When num_points_in_qp_table_minus1[ 0 ] is not present in the bitstream, the value of num_points_in_qp_table_minus1[ 0 ] is inferred to be equal to 0.

[0211] delta_qp_in_val_minus1[ i ][ j ] specifies the delta value used to derive the input coordinates of the j-th pivot point of the i-th chroma QP map. When delta_qp_in_val_minus1[ 0 ][ j ] is not present in the bitstream, the value of delta_qp in delta_qp in val_minus1[ 0 ][ j ] is inferred to be equal to 0.

[0212] delta_qp_out_val[ i ][ j ] specifies the delta 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 ] is not present in the bitstream, the value of delta_qp_out_val[ 0 ][ j ] is inferred to be equal to 0.

[0213] The i-th chroma QP mapping table ChromaQpTable[ i ] is derived as follows, where i = 0..same_qp_table_for_chroma? 0 : 2:

[0214]

[0215] When same_qp_table_for_chroma is equal to 1, ChromaQpTable[ 1 ][ k ] and ChromaQpTable[ 2 ][ k ] are set equal to ChromaQpTable[ 0 ][ k ], where k = -QpBdOffsetC..63.

[0216] Bitstream conformance requires that the values ​​of qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range -QpBdOffsetC to 63, inclusive, where i = 0..same_qp_table_for_chroma ? 02 and j = 0..num_points_in_qp_table_minus1[ i ].

[0217] sps_weighted_pred_flag equal to 1 specifies that weighted prediction may be applied to P slices referencing an SPS. sps_weighted_pred_flag equal to 0 specifies that weighted prediction is not applied to P slices referencing an SPS.

[0218] sps_weighted_bipred_flag equal to 1 specifies that explicit weighted prediction may be applied to B slices referencing the SPS. sps_weighted_bipred_flag equal to 0 specifies that explicit weighted prediction is not applied to B slices referencing the SPS.

[0219] sps_sao_enabled_flag equal to 1 specifies that the sample adaptive offset process is applied to the reconstructed picture after the deblocking filter process. sps_sao_enabled_flag equal to 0 specifies that the sample adaptive offset process is not applied to the reconstructed picture after the deblocking filter process.

[0220] sps_alf_enabled_flag equal to 0 specifies that the adaptive loop filter is disabled.

[0221] sps_alf enabled_flag equal to 1 specifies that the adaptive loop filter is enabled.

[0222] sps_transform_skip_enabled_flag equal to 1 specifies that transform_skip_flag may be present in the transform unit syntax. tsps_transform_skip_enabled_flag equal to 0 specifies that transform_skip_flag is not present in the transform unit syntax.

[0223] sps_bdpcm_enabled_flag equal to 1 specifies that intra_bdpcm_flag may be present in the coding unit syntax for intra coding units. sps_bdpcm_enabled_flag equal to 0 specifies that intra_bdpcm_flag is not present in the coding unit syntax for intra coding units. When not present, the value of sps_bdpcm_enabled_flag is inferred to be equal to 0.

[0224] sps_joint_cbcr_enabled_flag equal to 0 specifies that joint coding of chroma residual is disabled. sps_joint_cbcr_enabled_flag equal to 1 specifies that joint coding of chroma residual is enabled.

[0225] sps_ref_wraparound_enabled_flag equal to 1 specifies that horizontal wraparound motion compensation is applied in inter prediction. sps_ref wraparound_enabled_flag equal to 0 specifies that horizontal wraparound motion compensation is not applied. The value of sps_ref_wraparound_enabled_flag shall be equal to 0 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 that references the SPS.

[0226] sps_ref_wraparound_offset_minus1 plus 1 specifies the offset used to calculate the horizontal wrap position in MinCbSizeY luma samples. The value of ref_wriparound_offset_minus1 shall be in the range of (CtbSizeY / MinCbSizeY) + 1 to (pic_width_in_luma_samples / MinCbSizeY) - 1, inclusive, where pic_width_in_luma_samples is the value of pic_width_in_luma_samples in any PPS that references the SPS.

[0227] sps_temporal_mvp_enabled_flag equal to 1 specifies that slice_temporal_mvp_enabled_flag is present in the slice header of slices in the CVS with slice_type not equal to 1. sps_temporal_mvp_enabled_flag equal to 0 specifies that slice_temporal_mvp_enabled_flag is not present in the slice header and the temporal motion vector predictor is not used in the CVS.

[0228] sps_sbtmvp_enabled_flag equal to 1 specifies that a subblock based temporal motion vector predictor may be used in picture decoding in the CVS where all slices have slice_type not equal to 1. sps_sbtmvp_enabled_flag equal to 0 specifies that a subblock based temporal motion vector predictor is not used in the CVS. When sps_sbtmvp_enabled_flag is not present, it is inferred to be equal to 0.

[0229] sps_amvr_enabled_flag equal to 1 specifies that adaptive motion vector difference resolution is used in motion vector coding. amvr_enabled_flag equal to 0 specifies that adaptive motion vector difference resolution is not used in motion vector coding.

[0230] sps_bdof_enabled_flag equal to 0 specifies that bidirectional optical flow inter-frame prediction is disabled. sps_bdof_enabled_flag equal to 1 specifies that bidirectional optical flow inter-frame prediction is enabled.

[0231] sps_smvd_enabled_flag equal to 1 specifies that symmetric motion vector differences can be used in motion vector decoding. sps_smvd_enabled_flag equal to 0 specifies that symmetric motion vector differences are not used in motion vector encoding.

[0232] sps_dmvr_enabled_flag equal to 1 specifies that inter bi-prediction based on decoder motion vector modification is enabled. sps_dmvr_enabled_flag equal to 0 specifies that inter bi-prediction based on decoder motion vector modification is disabled.

[0233] sps_bdof_dmvr_slice_present_flag equal to 1 specifies that slice_disable_bdof_dmvr_flag is present in the slice header referencing the SPS.

[0234] sps_bdof_dmvr_slice_present_flag equal to 0 specifies that slice_disable_bdof_dmvr_flag is not present in the slice header referencing the SPS. When sps_bdof_dmvr_slice_present_flag is not present, the value of sps_bdof_dmvr_slice_present_flag is inferred to be equal to 0.

[0235] sps_mmvd_enabled_flag equal to 1 specifies that merge mode with motion vector difference is enabled. sps_mmvd_enabled_flag equal to 0 specifies that merge mode with motion vector difference is disabled.

[0236] sps_isp_enabled_flag equal to 1 specifies that intra prediction with sub-partitioning is enabled. sps_isp_enabled_flag equal to 0 specifies that intra prediction with sub-partitioning is disabled.

[0237] sps_mrl_enabled_flag equal to 1 specifies that intra prediction with multiple reference lines is enabled. sps_mrl_enabled_flag equal to 0 specifies that intra prediction with multiple reference lines is disabled.

[0238] sps_mip_enabled_flag equal to 1 specifies that matrix-based intra prediction is enabled. sps_mip_enabled_flag equal to 0 specifies that matrix-based intra prediction is disabled.

[0239] sps_cclm_enabled_flag equal to 0 specifies that cross-component linear model intra prediction from luma components to chroma components is disabled. sps_cclm_enabled_flag equal to 1 specifies that cross-component linear model intra prediction from luma components to chroma components is enabled. When sps_cclm_enabled_flag is not present, it is inferred to be equal to 0.

[0240] sps_cclm_colocated_chroma_flag equal to 1 specifies that the left up and down sampled luma samples in cross-component linear model intra prediction are co-located with the top left luma sample. sps_cclm_colocated_chroma_flag equal to 0 specifies that the left up and down sampled luma samples in cross-component linear model intra prediction are horizontally co-located with the top left luma sample, but vertically shifted by 0.5 luma sample units relative to the top left luma sample.

[0241] sps_mts_enabled_flag equal to 1 specifies that sps_explicit_ints_intra enabled_flag is present in the sequence parameter set RBSP syntax and sps_explicit_mts_inter_enabled_flag is present in the sequence parameter set RBSP syntax. sps_mts_enabled_flag equal to 0 specifies that sps_explicit_mts_intra_enabled_flag is not present in the sequence parameter set RBSP syntax and sps_explicit_mts_inter_enabled_flag is not present in the sequence parameter set RBSP syntax.

[0242] sps_explicit_mts_intra_enabled_flag equal to 1 specifies that tu_mts_idx may be present in transform unit syntax for intra coding units. sps_explicit_mts_intra_enabled_flag equal to 0 specifies that tu_mts_idx is not present in transform unit syntax for intra coding units. When not present, the value of sps_explicit_mts_intra_enabled_flag is inferred to be equal to 0.

[0243] sps_explicit_mts_inter_enabled_flag equal to 1 specifies that tu_mts_idx may be present in transform unit syntax for inter coding units. sps_explicit_mts_inter_enabled_flag equal to 0 specifies that tu_mts_idx is not present in transform unit syntax for inter coding units. When not present, the value of sps_explicit_mts_inter_enabled_flag is inferred to be equal to 0.

[0244] sps_sbt_enabled_flag equal to 0 specifies that sub-block transform for inter-predicted CUs is disabled. sps_sbt_enabled_flag equal to 1 specifies that sub-block transform for inter-predicted CUs is enabled.

[0245] sps_sbt_max_size_64_flag equal to 0 specifies that the maximum CU width and height for allowing sub-block transforms is 32 luma samples. sps_sbt_max_size_64_flag equal to 1 specifies that the maximum CU width and height for allowing sub-block transforms is 64 luma samples.

[0246] MaxSbiSize = Min(MaxTbSizeY, sps_sht_max_size_64_flag ? 64 : 32)

[0247] sps_affine_enabled_flag specifies whether affine model-based motion compensation can be used for inter-frame prediction. Specifies whether affine model-based motion compensation can be used for inter-frame prediction. If sps_affine_enabled_flag is equal to 0, the syntax should be constrained so that affine model-based motion compensation is not used in CVS, and inter_affine_flag and cu_affine_type_flag are not present in the coding unit syntax of CVS. Otherwise (sps_affine_enabled_flag is equal to 1), affine model-based motion compensation can be used in CVS.

[0248] sps_affine_type_flag specifies whether motion compensation based on a 6-parameter affine model can be used for inter prediction. If sps_affine_type_flag is equal to 0, the syntax should be constrained so that motion compensation based on a 6-parameter affine model is not used in the CVS, and cu_affine_type_flag is not present in the coding unit syntax in the CVS. Otherwise (sps_affine_type_flag is equal to 1), motion compensation based on a 6-parameter affine model can be used in the CVS. When not present, the value of sps_affine_type_flag is inferred to be equal to 0.

[0249] sps_affine_amvr_enabled_flag equal to 1 specifies that adaptive motion vector difference resolution is used in motion vector coding in affine inter mode. sps_affine_amvr_enabled_flag equal to 0 specifies that adaptive motion vector difference resolution is not used in motion vector coding in affine inter mode.

[0250] sps_affine_prof_enabled_flag specifies whether prediction correction using optical flow can be used for affine motion compensation. If sps_affine_prof_enabled_flag is equal to 0, optical flow is not applied to correct affine motion compensation. Otherwise (sps_affine_prof_enabled_flag is equal to 1), optical flow can be applied to correct affine motion compensation. When not present, the value of sps_affine_prof_enabled_flag is inferred to be equal to 0.

[0251] sps_palette_enabled_flag equal to 1 specifies that pred_mode_plt_flag may be present in the coding unit syntax. sps_palette_enabled_flag equal to 0 specifies that pred_mode_plt_flag is not present in the coding unit syntax. When sps_palette_enabled_flag is not present, it is inferred to be equal to 0.

[0252] sps_bcw_enabled_flag specifies whether bi-prediction with CU weights can be used for inter prediction. If sps_bcw_enabled_flag is equal to 0, the syntax should be constrained so that bi-prediction with CU weights is not used in CVS, and bcw_idx is not present in the coding unit syntax of CVS. Otherwise (sps_bcw_enabled_flag is equal to 1), bi-prediction with CU weights can be used in CVS.

[0253] sps_ibc_enabled_flag equal to 1 specifies that the IBC prediction mode may be used in decoding of pictures in CVS. sps_ibc_enabled_flag equal to 0 specifies that the IBC prediction mode is not used in CVS. When sps_ibc_enabled_flag is not present, it is inferred to be equal to 0.

[0254] sps_ciip_enabled_flag specifies that ciip_flag may be present in the coding unit syntax for inter coding units. sps_ciip_enabled_flag equal to 0 specifies that ciip_flag is not present in the coding unit syntax for inter coding units.

[0255] sps_fpel_mmvd_enabled_flag equal to 1 specifies that merge mode with motion vector differences is using integer sample precision. sps_fpel_mmvd_enabled_flag equal to 0 specifies that merge mode with motion vector differences may use fractional sample precision.

[0256] sps_triangle_enabled_flag specifies whether triangle-based motion compensation can be used for inter 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 CVS, and merge_triangle_split_dir, merge_triangle_idx0, and merge_triangle_idx1 are not present in the coding unit syntax of CVS. sps_triangle_enabled_flag equal to 1 specifies that triangle-based motion compensation can be used in CVS.

[0257] sps_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is used in CVS. sps_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is not used in CVS.

[0258] sps_lfnst_enabled_flag equal to 1 specifies that lfnst_idx may be present in the residual coding syntax for intra-coded units. sps_lfnst_enabled_flag equal to 0 specifies that lfnst_idx is not present in the residual coding syntax for intra-coded units.

[0259] sps_ladf_enabled_flag equal to 1 specifies that sps_nurn_ladf_intervals_minus2, sps_ladf_lowest_interval_qp_offset, sps_ladf qp_offset [ i ], and sps_ladf_delta_threshold_minus1 [ i ] are present in the SPS.

[0260] sps_num_ladf_intervals_minus2 plus 1 specifies the number of sps_ladf_delta_threshold_minus1[ i ] and sps_ladf_qp_offset i syntax elements present in the SPS. The value of sps_num_ladf_intervals_minus2 shall be in the range of 0 to 3, inclusive.

[0261] sps_ladf_lowest_interval_qp_offset specifies the offset used to derive the specified variable qP. The value of ps_ladf lowest_interval_qp_offset should be in the range of 0 to 63, inclusive.

[0262] sps_ladf_qp_offset[1] 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).

[0263] sps_ladf_delta_threshold_minus1[ i ] is used to calculate the value of SpsLadfIntervalLowerBound[ i ], which specifies the lower bound of the i-th interval of luminance intensity levels. The value of sps_ladf delta_threshold_minus1[ i ] should be between 0 and 2. BrtDepthY - 3 (inclusive of the end value).

[0264] Set the value of SpsLadflntervalLowerBound[ 0 ] equal to 0.

[0265] 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:

[0266] SpsLadflntervalLowerBound[i ​​+ 1] = SpsLadflntervalLowerBound[i] +sps_ladf_delta_threshold_minus1[i]+ 1

[0267] sps_scaling_list_enabled_flag equal to 1 specifies that the scaling list is used for the scaling process of transform coefficients. sps_scaling_list_enabled_flag equal to 0 specifies that the scaling list is not used for the scaling process of transform coefficients.

[0268] hrd_parameters_present_flag equal to 1 specifies that the syntax elements num_units_in_tick and time_scale and the syntax structure general_hrd_parameters() are present in the SPS RBSP syntax structure. general_hrd_parameters_present_flag equal to 0 specifies that the syntax elements num_units_in_tick and time_scale and the syntax structure general_hrd_parameters() are not present in the SPS RBSP syntax structure.

[0269] num_units_in_tick is the number of time units of a clock operating at a frequency time_scale Hz, which corresponds to one increment of the clock tick counter (called a clock tick). num_units_in_tick should be greater than 0. The clock tick in seconds is equal to the quotient of num_units_in_tick divided by time_scale. For example, when the picture rate of the video signal is 25 Hz, time_scale may be equal to 27,000,000 and num_units_in_tick may be equal to 1,080,000, and thus the clock tick may be equal to 0.04 seconds.

[0270] time_scale is the number of time units that pass in one second. For example, a time coordinate system that uses a 27MHz clock to measure time has a time_scale of 27,000,000. The value of time_scale should be greater than 0.

[0271] sub_layer_cpb_parameters_present_flag equal to 1 specifies that the syntax structure general_hrd_parameters() is present in the SPS RBSP and includes sub-layer represented HRD parameters with TemporalId in the range of 0 to sps_max_sub_layers_minus1, inclusive. sub_layer_cpb_parameters_present_flag equal to 0 specifies that the syntax structure general_hrd_parameters() is present in the SPS RBSP and includes sub-layer represented HRD parameters with TemporalId equal to sps_max_sub_layers_minus1.

[0272] vui_parameters_present_flag equal to 1 specifies that the syntax structure vui_parameters() is present in the SPS RBSP syntax structure. vui_parameters_present_flag equal to 0 specifies that the syntax structure vui_parameters() is not present in the SPS RBSP syntax structure.

[0273] sps_extension_flag equal to 0 specifies that the sps_extension_data_flag syntax structure is not present in the SPS RBSP syntax structure. sps_extension_flag equal to 1 specifies that the sps_extension_data_flag syntax structure is present in the SPS RBSP syntax structure.

[0274] sps_extension_data_flag can have any value. Its presence and value do not affect the conformance of the decoder to the profile specified in this version of this specification. Decoders conforming to this version of this specification should ignore all sps_extension_data_flag syntax elements.

[0275] As provided in Table 2, a NAL unit may include a picture parameter set (PPS). Table 4 shows the syntax of the PPS provided in JVET-O2001.

[0276]

[0277]

[0278]

[0279]

[0280]

[0281] Regarding Table 4, JVET-02001 provides the following semantics:

[0282] The PPS RBSP shall be available to the decoding process before it is referenced, included in at least one access unit with a TemporalId less than or equal to the TemporalId of the PPS NAL unit or provided by external means, and the PPS NAL unit containing the PPS RBSP shall have a nuh_layer_id equal to the nuh_layer_id of the coded slice NAL unit that references it.

[0283] All pps NAL units with a particular value of pps_pic_parameter set_id within an access unit shall have the same content.

[0284] pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements.

[0285] The value of pps_pic_parameter_set_id shall be in the range of 0 to 63, inclusive.

[0286] pps_seq_parameter_set_id specifies the value of sps_seq_parameter_set_id of the SPS. The value of pps_seq_parameter_set_id shall be in the range of 0 to 15 (inclusive). The value of pps_seq_parameter_set_id shall be the same in all PPSs referenced by coded pictures in the CVS.

[0287] pic_width_in_luma_samples specifies the width of each decoded picture that references the PPS, in units of luma samples. pic_width_in_luma_samples shall not be equal to 0, shall be an integer multiple of Max(8, MinCbSizeY), and shall be less than or equal to pic_width_max_in_luma_samples.

[0288] When subpics_present_flag is equal to 1, the value of pic_width_in_luma_samples shall be equal to pic_width_max_in_luma_samples.

[0289] pic_height_in_luma_samples specifies the height of each decoded picture that references the PPS, in units of luma samples. pic_height_in_luma_samples shall not be equal to 0 and shall be an integer multiple of Max(8, MinCbSizeY), and shall be greater than or equal to pic_height_max_in_luma_samples.

[0290] When subpics_present_flag is equal to 1, the value of pic_height_in_luma_samples shall be equal to pic_height_max_in_luma_samples.

[0291] Let refPicWidthInLumaSamples and refPicHeightInLumaSamples be the pic_width_in_luma_samples and pic_height_in_luma_samples, respectively, of the reference picture that references the current picture of this PPS. Bitstream conformance requires that all of the following conditions be met:

[0292] -pic_widthinluma_samples * 2 should be greater than or equal to refPicWidthInLumaSamples.

[0293] -pic_height_inJumasamples*2 should be greater than or equal to refPicHeightInLumaSamples.

[0294] -pic_width_in_luma_samples should be less than or equal to refPicWidthInLumaSamples * 8.

[0295] -pic_height_in_luma_samples should be less than or equal to refPicHeightInLumaSamples * 8.

[0296] The variables PicWidthlnCtbsY, PicHeightlnCtbsY, PicSizelnCtbsY, PicWidthlnMinCbsY, PicHeightInMinCbsY, PicSizeInMinCbsY, PicSizelnSamplesY, PicWidthlnSamplesC, and PicHeightInSamplesC are derived as follows:

[0297] PicWidthlnCtbsY = Ceil(pic_width_in_luma_samples ÷ CtbSizeY)

[0298] PicHeightlnCtbsY = Ceil(pic_height_in_lumasamples ÷ CtbSizeY)

[0299] PicSizenCtbsY PicWidthInCtbsY * PicHeightInCtbsY

[0300] PicWidthInMinCbsY = pic_width_in_luma_samples / MinCbSizeY

[0301] PicHeightInMinCbsY = pic_height_in_luma_samples / MinCbSizeY

[0302] PicSizeInMinCbsY = PicWidthInMinCbsY * PicHeightInMinCbsY

[0303] PicSizeInSamplesY = pic_width_in_luma_samples * pic_height_in_luma_samples

[0304] PicWidthInSamplesC = pic_width_in_luma_samples / SubWidthC

[0305] PicHeightInSamplesC = pic_height_in_luma_samples / SubHeightC

[0306] conformance_window_flag equal to 1 indicates that the conformance cropping window offset parameter follows immediately in the SPS. conformance_window_flag equal to 0 indicates that there is no conformance cropping window offset parameter.

[0307] conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset specify samples of the picture output from the decoding process in the CVS, based on the rectangular area specified in the coordinates of the picture to be output. When conformance_window_flag is equal to 0, conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset are inferred to be equal to 0.

[0308] The fitted crop window contains luma samples with horizontal picture coordinates from SubWidthC * conf_win_left_offset to pic_width_in_luma_samples - (SubWidthC * conf_win_right_offset + 1), and vertical picture coordinates from SubHeightC * conf_win_top_offset to pic_height_in_luma_samples - SubHeightC * conf_win_bottom_offset + 1), inclusive.

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

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

[0311] PicOutputWidthL = pic_width_in_luma_samples - SubWidthC * (conf_winright_offset + conf_win_left_offset)

[0312] PicOutputHeightL = pic_height_in_pic_size_units -

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

[0314] NOTE - The Fit Crop Window Offset parameters are only applied on output. All internal decoding processes are applied to the uncropped image size.

[0315] Let ppsA and ppsB be any two PPSs that reference the same SPS. Bitstream conformance requires that when ppsA and ppsB have the same values ​​of pic_width_in_luma_samples and pic_height_in_luma_samples, respectively, ppsA and ppsB shall have the same values ​​of conf_win_left_offset, conf_win_right_offset, conf_win_top_offset, and conf_win_bottom_offset, respectively.

[0316] output_flag_present_flag equal to 1 indicates that the pic_output_flag syntax element is present in the slice header referencing the PPS. output_flag_present_flag equal to 0 indicates that the pic_output_flag syntax element is not present in the slice header referencing the PPS.

[0317] single_tile_in_pic_flag equal to 1 specifies that there is only one tile in each picture referencing the PPS. single_tile_in_pic_flag equal to 0 specifies that there is more than one tile in each picture referencing the PPS.

[0318] Note - In case there is no further brick division within a tile, the entire tile is referred to as a brick. When a picture contains only a single tile without further brick division, the picture is referred to as a single brick.

[0319] Bitstream conformance requires that the value of single_tile_in_pic_flag shall be the same for all PPSs referenced by a coded picture within a CVS.

[0320] uniform_filespacing_flag equal to 1 specifies that tile column boundaries and identical tile row boundaries are uniformly distributed across the picture, and that the tile column boundaries and tile row boundaries are signaled using the syntax elements tile_cols_width_minus1 and tile_rows_height_minus1. uniform_tile_spacing_flag equal to 0 specifies that tile column boundaries and identical tile row boundaries may or may not be uniformly distributed across the picture, and that the tile column boundaries and tile row boundaries are signaled using the syntax elements num_tile_columns_minus1 and num_tile_rows_minus1 and a list of syntax elements tile_column_width_minus1[ i ] and tile_row_height_minus1[ i ]. When not present, the value of uniform_tile_spacing_flag is inferred to be equal to 1.

[0321] tile_cols_width_rainus1 plus 1 specifies the width of tile columns other than the rightmost tile column of the picture, in CTBs, when uniform_tile_spacing_flag is equal to 1. The value of tile_cols_width_minus1 shall be in the range of 0 to PicWidthInCtbsY - 1, inclusive. When not present, the value of tile_cols_width_minus1 is inferred to be equal to PicWidthInCtbsY - 1.

[0322] tile_rows_height_minus1 plus 1 specifies the height of tile rows other than the bottom tile row of the picture, in CTBs, when uniform_tile_spacing_flag is equal to 1. The value of tile_rows_height_minus1 shall be in the range of 0 to PicHeightlnCtbsY - 1, inclusive. When not present, the value of tile_rows_height_minus1 is inferred to be equal to PicHeightInCtbsY - 1.

[0323] num_tile_columns_minus1 plus 1 specifies the number of tile columns that partition the picture when uniform_tile_spacing_flag is equal to 0. The value of num_tile_columns_minus1 shall be in the range of 0 to PicWidthlnCtbsY - 1, inclusive. When single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is inferred to be equal to 0. Otherwise, when uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is inferred as specified.

[0324] num_tik_rows_minus1 plus 1 specifies the number of tile rows that partition the picture when uniform_tile_spacing_flag is equal to 0. The value of num_tile_rows_minus1 shall be in the range of 0 to PicHeightlnCtbsY - 1, inclusive. When single_tile_in_pic_flag is equal to 1, the value of num_tile_rows_minus1 is inferred to be equal to 0. Otherwise, when uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is inferred as specified.

[0325] The variable NumTileslnPic is set equal to (num_tile_columns_minus1+1)*(num_tile_rows_minus1+1).

[0326] When single_tile_in_pic_flag is equal to 0, NumTileslnPic should be greater than 1.

[0327] tile_column_width_minus1[[ i ]] plus 1 specifies the width of the i-th tile column in CTBs.

[0328] tile_row_height_mainus1[ i ] plus 1 specifies the height of the i-th tile row in CTBs.

[0329] brick_splitting_present_flag equal to 1 specifies that one or more tiles of a picture referencing a PPS may be split into two or more tiles. brick_splitting_present_flag equal to 0 specifies that tiles of a picture not referencing a PPS are split into two or more tiles.

[0330] num_tiles_in_pic_minus1 plus 1 specifies the number of slices in each picture referencing the PPS. The value of num_tiles_in_pic_minus1 shall be equal to NumTileslnPic - 1. When not present, the value of num_tiles_in_pic_minus1 is inferred to be equal to NumTileslnPic - 1.

[0331] brick_split_flag[[ i ]] equal to 1 specifies that the i th tile is split into two or more bricks. brick_split_flag[ i ] equal to 0 specifies that the i th tile is not split into two or more bricks. When not present, the value of brick_split_flag[ i ] is inferred to be equal to 0.

[0332] uniform_brick_spacing_flag[ i ] equal to 1 specifies that the horizontal brick border is uniformly distributed over the i-th tile and that the horizontal brick border is signaled using the syntax element brick_height_minus1[ i ]. uniform_brick_spacing_flag[ i ] equal to 0 specifies that the horizontal brick border may or may not be uniformly distributed over the i-th tile and that the horizontal brick border is signaled using the syntax element num_brick_rows_minus2[ i ] and the list of syntax elements brick_row_height_minus1[ i ][ j ]. When not present, the value of uniform_brick_spacing_flag[ i ] is inferred to be equal to 1.

[0333] brick_height_minus1[ i ] plus 1 specifies the height of the row of bricks in the i-th tile, excluding the bottom brick, in CTBs, when uniform_brick_spacing_flag[ i ] is equal to 1. When present, the value of brick_height_minus1 shall be in the range of 0 to RowHeight[ i ] - 2, inclusive. When not present, the value of brick_height_minus1[ i ] is inferred to be equal to RowHeight[ i ] - 1.

[0334] num_brick_rows_minus2[ i ] plus 2 specifies the number of bricks used to partition the i th tile when uniform_brick_spacing_flag[ i ] is equal to 0. When present, the value of num_brick_rows_minus2[ i ] shall be in the range of 0 to RowHeight[ i ] - 2, inclusive. When brick_split_flag[ i ] is equal to 0, the value of num_brick_rows_minus2[ i ] is inferred to be -1. Otherwise, when uniform_brick_spacing_flag[ i ] is equal to 1, the value of num_brick_rows_minus2[ i ] is inferred as specified.

[0335] brick_row_height_minus1[ i ][ j ] plus 1 specifies the height of the j-th brick in the i-th tile when uniform_tile_spacing_flag is equal to 0, in CTBs.

[0336] The following variables are exported and the values ​​of num_tile_columns_minus1 and num_tile_rows_minus1 are inferred when uniform_tile_spacing_flag is equal to 1, and the value of num_brick_rows_minus2[ i ] is inferred by invoking the specified CTB raster and brick scan conversion process when uniform_brick_spacing_flag[ i ] is equal to 1 for each i in the range 0 to NumTilesInPic - 1 (inclusive):

[0337] - list RowHeight[ j ], where j is in the range 0 to num_tile_rows_minus1 (inclusive), specifying the height of the j-th tile row in CTBs,

[0338] - List CtbAddrRsToBs[ ctbAddrRs ], where ctbAddrRs is in the range 0 to PicSizelnCtbsY - 1 (inclusive) and specifies the conversion from CTB addresses in the CTB raster scan of the picture to CTB addresses in the brick scan,

[0339] - List CtbAddrBsToRs[ctbAddrBs], where ctbAddrBs is in the range 0 to PicSizelnCtbsY - 1 (inclusive) and specifies the conversion from CTB addresses in the brick scan to CTB addresses in the CTB raster scan of the picture,

[0340] - ListBrickId[ctbAddrBs], where ctbAddrBs is in the range 0 to PicSizelnCtbsY - 1 (inclusive) and specifies the translation from CTB address in the brick scan to brick ID,

[0341] - List NumCtusInBrick[brickIdx], where brickIdx is in the range of 0 to NumBrickslnPic - 1, inclusive, which specifies the conversion from brick index to the number of CTUs in the brick,

[0342] - List FirstCtbAddrBs[brickIdx], where brickIdx is in the range of 0 to NumBricksInPic - 1 (inclusive), which specifies the translation from brick ID to CTB address in the brick scan of the first CTB in the brick.

[0343] single_brick_per_slice_flag equal to 1 specifies that each slice referencing this PPS includes one brick. single_brick_per_slice_flag equal to 0 specifies that a slice referencing this PPS may include more than one brick. When not present, the value of single_brick_per_slice_flag is inferred to be equal to 1.

[0344] rect_slice_flag equal to 0 specifies that the bricks within each slice are in raster scan order and that no slice information is signaled in the PPS. rect_slice_flag equal to 1 specifies that the bricks within each slice cover a rectangular area of ​​the picture and that slice information is signaled in the PPS. When brick_splitting_present_flag is equal to 1, the value of rect_slice_flag shall be equal to 1. When not present, rect_slice_flag is inferred to be equal to 1.

[0345] num_slices_in_pic_minus1 plus 1 specifies the number of slices in each picture that reference the PPS. The value of num_slices_in_pic_minus1 shall be in the range of 0 to NumBricksInPic - 1, inclusive. When not present and single_brick_per_slice_fiag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to NumBricksInPic - 1.

[0346] bottom_right_brick_idx_length_minus1 plus 1 specifies the number of bits used to represent the syntax element bottom_right_brick_idx_delta[ i ]. The value of bottom right_brick_idx_length_minus1 shall be in the range of 0 to Ceil(Log2(NumBricksInPic)) - 1, inclusive.

[0347] bottom_right_brick_idx_delta[ i ] specifies the difference between the brick index of the brick located at the bottom right corner of the i th slice and the brick index of the bottom right corner of the (i - 1) th slice, when i is greater than 0. bottom_right_brick_idx_delta[ 0 ] specifies the brick index of the bottom right corner of the 0 th slice. When single_brick_per_slice_flag is equal to 1, the value of bottom_right_brick_idx_delta[ i ] is inferred to be equal to 1. The value of BottomRightBrickIdx[num_slices_in_pic_minus1] is inferred to be equal to NumBricksInPic - 1. The length of the bottom_right_brick_idx_delta[ i ] syntax element is bottom_right_brick_idx_length_minus1 + 1 bits.

[0348] brick_idx_delta_sign_flag[ i ] equal to 1 indicates the positive sign of bottom_right_brick_idx_delta[ i ]. sign bottom_right_brick_idx_delta[ i ] equal to 0 indicates the negative sign of bottom_right_brick_idx_delta[ i ].

[0349] Bitstream conformance requires that a slice consist of either multiple complete tiles or sequentially consecutive complete bricks of just one tile.

[0350] The variables TopLeftBrickIdx[ i ], BottomRightBrickIdx[ i ], NumBricksInSlice[ i ], and BricksToSliceMap[ j ] that specify the brick index of the brick located at the top left corner of the i th slice, the brick index of the brick located at the bottom right corner of the i th slice, the number of bricks in the i th slice, and the brick-to-slice mapping are derived as follows:

[0351]

[0352] loop_filter_across_bricks_enabled_flag equal to 1 specifies that in-loop filtering operations may be performed across brick boundaries in pictures that reference a PPS. loop_filter_across_bricks_enabled_flag equal to 0 specifies that in-loop filtering operations are not performed across brick boundaries in pictures that reference a PPS. In-loop filtering operations include deblocking filter, sample adaptive offset filter, and adaptive loop filter operations. When not present, the value of loop_filter_across_bricks_enabled_flag is inferred to be equal to 1.

[0353] loop_filter_across_slices_enabled_flag equal to 1 specifies that in-loop filtering operations may be performed across slice boundaries in pictures referencing a PPS. loop_filter_across_slice_enabled_flag equal to 0 specifies that in-loop filtering operations are not performed across slice boundaries in pictures referencing a PPS. In-loop filtering operations include deblocking filter, sample adaptive offset filter, and adaptive loop filter operations. When not present, the value of loop_filter_across_slices_enabled_flag is inferred to be equal to 0.

[0354] signalled_slice_id_flag equal to 1 specifies that a slice ID for each slice is signaled. signalled_slice_id_flag equal to 0 specifies that slice IDs are not signaled. When rect_slice_flag is equal to 0, the value of signalled_slice_id_flag is inferred to be equal to 0.

[0355] NOTE - For a bitstream resulting from extraction for a sub-bitstream, when each picture in the bitstream contains a proper subset of slices included in a picture of the "original" bitstream, and the subset of included slices does not include the top-left slice of the picture in the "original" bitstream, the value of signalled_slice_id_flag in the PPS in the extracted bitstream must be equal to 1.

[0356] signalled_slice_id_length_minus1 plus 1 specifies the number of bits used to represent the syntax element slice_id[ i ] (when present) and the syntax element slice_address in the slice header. The value of signalled_slice_id_length_minus1 shall be in the range of 0 to 15, inclusive. When not present, the value of signalled_slice_id_length_minus1 is inferred to be equal to Ceil(Log2(Max(2, num_slices_in_pic_minus1 + 1))) - 1.

[0357] slice_id[ i ] specifies the slice ID of the i-th slice. The length of the slice_id[ i ] syntax element is signalled_slice_id_length_minus1+1 bits. When not present, for each i in the range 0 to num_slices_in_pic_minus1 (inclusive), the value of slice_id[ i ] is inferred to be equal to i.

[0358] entropy_coding_sync_enabled_flag equal to 1 specifies that a specific synchronization process of context variables is called before decoding the CTU of the first CTB in the CTB row in each brick in each picture that references the PPS, and a specific storage process of context variables is called after decoding the CTU of the first CTB in the CTB row in each brick in each picture that references the PPS. entropy_coding_sync_enabled_flag equal to 0 specifies that a specific synchronization process of context variables does not need to be called before decoding the CTU of the first CTB in the CTB row in each brick in each picture that references the PPS, and a specific storage process of context variables does not need to be called after decoding the CTU of the first CTB in the CTB row in each brick in each picture that references the PPS.

[0359] Bitstream conformance requires that the value of entropy_coding_sync_enabled_flag shall be the same for all PPSs referenced by coded pictures in a CVS.

[0360] cabac_init_present_flag equal to 1 specifies that cabac_init_flag is present in the slice header referencing the PPS. cabac_init_present_flag equal to 0 specifies that cabac_init_flag is not present in the slice header referencing the PPS.

[0361] num_ref id.x_default_active_minus1[ i ] plus 1 specifies the inferred value of the variable NumRefIdxActive[0] for P slices and B slices when i is equal to 0, with num_ref_idx_active_override_flag equal to 0, and specifies the inferred value of NumRefIdxActive[1] for B slices when i is equal to 1, with num_ref_idx_active_override_flag equal to 0. The value of num_ref_idx_default_active_minus1[ i ] shall be in the range of 0 to 14, inclusive.

[0362] rpl1_idx_present_flag equal to 0 specifies that ref_pic_list_sps_flag[1] and ref_pic_list_idx[1] are not present in the slice header. rpl1_idx_present_flag equal to 1 specifies that ref_pic_list_sps_flag[1] and ref_pic_list_idx[1] may be present in the slice header.

[0363] init_qp_minus26 plus 26 specifies the SliceQ of each slice that references the PPS PY When a non-zero slice_qp_delta is decoded, SliceQ is modified at the slice level. PY The value of init_qp_minus26 should be in the range of -(26 + QpBdOffsety) to +37, inclusive.

[0364] log2_transform_skip_max_size_minus2 specifies the maximum block size for transform skipping and should be in the range of 0 to 3.

[0365] When not present, the value of log2_transform_skip_max_size_minus2 is inferred to be equal to 0.

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

[0367] cu_qp_delta_enabled_flag equal to 1 specifies that the cu_qp_delta_subdiv syntax element is present in the PPS and that cu_qp_delta_abs may be present in the transform unit syntax. cu_qp_delta_enabled_flag equal to 0 specifies that the cu_qp_delta_subdiv syntax element is not present in the PPS and that cu_qp_delta_abs is not present in the transform unit syntax.

[0368] cu_gp_delta_subdiv specifies the maximum cbSubdiv value for coding units that transmit cu_qp_delta_abs and cu_qp_delta_sign_flag. The range of values ​​for cu_qp_delta_subdiv is specified as follows:

[0369] - If slice_type is equal to 1, the value of cu_qp_delta_subdiv shall be in the range of 0 to 2*(log2_ctu_size_minus2 - log2_min_qt_size intraslice_minus2 + MaxMttDepthY), inclusive.

[0370] - Otherwise (slice_type is not equal to 1), the value of cu_qp_delta_subdiv shall be in the range of 0 to 2*(log2_ctu_size_minus2 - log2_min_qt_size_inter slice_minus2 + MaxMttDepthY), inclusive.

[0371] When not present, the value of cu_qp_delta_subdiv is inferred to be equal to 0.

[0372] pps_cb_qp_offset and pps_cr_qp_offset are respectively specified for deriving Qp' Cb and Qp' Cr The brightness quantization parameter Qp' Y The values ​​of pps_cb_qp_offset and pps_cr_qp_offset shall be in the range of -12 to +12 (inclusive). When ChromaArrayType is equal to 0, pps_cb_qp_offset and pps_cr_qp_offset are not used in the decoding process and the decoder shall ignore their values.

[0373] pps_joint_cbcr_qp_offset specifies the offset used to derive Qp'CbCr The brightness quantization parameter Qp' Y The value of pps_joint_cbcr_qp_offset shall be in the range of -12 to +12, inclusive. When ChromaArrayType is equal to 0 or sps_joint_cbcr_enabled_flag is equal to 0, pps_joint_cbcr_qp_offset is not used in the decoding process and the decoder shall ignore its value.

[0374] pps_slice_chroma_qp_offsets_present_flag equal to 1 indicates that slice_cb_qp_offset and slice_cr_qp_offset syntax elements are present in the associated slice header. pps_slice_chroma_qp_offsets present_flag equal to 0 indicates that these syntax elements are not present in the associated slice header. When ChromaArrayType is equal to 0, pps_slice_chroma_qp_offsets_present_flag shall be equal to 0.

[0375] cu_chroma_qp_offset_enabled_flag equal to 1 specifies that cu_chroma_qp_offset_flag may be present in the transform unit syntax.

[0376] cu_chroma_qp_offset_enabled_flag equal to 0 specifies that cu_chroma_qp_offset_flag is not present in the transform unit syntax. When ChromaArrayType is equal to 0, bitstream conformance requires that the value of cu_chroma_cjp_offset_enabled_flag shall be equal to 0.

[0377] cu_chroma_qp_offset_subdiv specifies the maximum cbSubdiv value for the coding unit that transmits cu_chroma_qp_offset_flag. The value range of cu_chroma_qp_offset_subdiv is specified as follows:

[0378] - If slice_type is equal to 1, the value of cu_chroma_qp_offset_subdiv shall be in the range of 0 to 2 * (log2_ctu_size_minus2 - log2_min_qt_size_intra_slice_minus2 + MaxMttDepthY), inclusive.

[0379] - Otherwise (slice_type is not equal to 1), the value of eu_chromaqp_offset_subdiv shall be in the range of 0 to 2 * (log2_ctu_size_minus2 - log2_min_qt_size_intera_slice_minus2 + MaxMaDepthY), inclusive.

[0380] When not present, the value of cu_chroma_qp_offset_subdiv is inferred to be equal to 0.

[0381] chroma_qp_offset_list_len_minus1 plus 1 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 the SPS. The value of chroma_qp_offset_list_len_minus1 shall be in the range of 0 to 5, inclusive.

[0382] cb_qp_offset_list[ i ], cr_qp_offset_list[ i ] and joint_cbcr_qp_offset_list[ i ] specify the Qp' Cb , Qp' Cr and Qp' CbCr The values ​​of ch_qp_offset_list[ i ], cr_qp_offset_list[ i ], and joint_cbcr_qp_offset_list[ i ] should be in the range -12 to +12, inclusive.

[0383] pps_weighted_pred_flag equal to 0 specifies that weighted prediction is not applied to P slices that reference SPS. pps_weighted_pred_flag equal to 1 specifies that weighted prediction is applied to P slices that reference SPS. When sps_weighted_pred_flag is equal to 0, the value of pps_weighted_pred_flag shall be equal to 0.

[0384] pps_weighted_bipred_flag equal to 0 specifies that explicit weighted prediction is not applied to B slices referencing the PPS. pps_weighted_bipred_flag equal to 1 specifies that explicit weighted prediction is applied to B slices referencing the PPS. When sps_weighted_bipred_flag is equal to 0, the value of pps_weighted_bipred_flag shall be equal to 0.

[0385] deblocking_filter_control_present_flag equal to 1 specifies that the deblocking filter control syntax element is present in the PPS. deblocking_filter_control_present_flag equal to 0 specifies that the deblocking filter control syntax element is not present in the PPS.

[0386] deblocking_filter_override_enabled_flag equal to 1 specifies that deblocking_filter_override_flag is present in the slice header of the picture referencing the PPS. deblocking_filter_override_enabled_flag equal to 0 specifies that deblocking_filter_override_flag is not present in the slice header of the picture referencing the PPS. When not present, the value of deblocking_filter_override_enabled_flag is inferred to be equal to 0.

[0387] pps_deblocking_filter_thsabled_flag equal to 1 specifies that the operation of the deblocking filter should not be applied to slices referencing a PPS where slice_deblocking_filter_disabled_flag is not present. pps_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter should be applied to slices referencing a PPS where slice_deblocking_filter_disabled_flag is not present. When not present, the value of pps_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0388] pps_beta_offset_div2 and pps_te_offset_div2 specify the default deblocking parameter offsets (divided by 2) of 6 and tC applied to slices that reference the PPS, unless the default deblocking parameter offsets are overridden by the deblocking parameter offsets present in the slice header of the slice that references the PPS. The values ​​of pps_beta_offset_div2 and pps_tc_offset_div2 shall both be in the range of -6 to 6, inclusive. When not present, the values ​​of pps_beta_offset_div2 and pps_tc_offset_div2 are inferred to be equal to 0.

[0389] constant_slice_header_params_enabled_flag equal to 0 specifies that pps_dep_quant_enabled_idc, pps_ref_pic_list_sps_idc[ i ], pps_temporal_mvp_enable_idc, pps_mvd_l1_zero_idc, pps_collocated_from_l0_idc, pps_six_minus_max_num_merge_cand_plus1, pps_five_minus_max_num_subblock_merge_cand_plus1, and pps_max_num_merge_cand_minus_max_num_triangle_cand_minus1 are inferred to be equal to 0. constant_slice_header_params_enabled_flag equal to 1 specifies that these syntax elements are present in the PPS.

[0390] pps_dep_quant_enabled_idc equal to 0 specifies that the syntax element dep_quant_enabled_flag is present in the slice header of the slice referencing the PPS. pps_dep_quant_enabled_idc equal to 1 or 2 specifies that the syntax element dep_quant_enabled_flag is not present in the slice header of the slice referencing the PPS. pps_dep_quant_enabled_idc equal to 3 is reserved for future use by ITU-T | ISO / IEC.

[0391] pps_ref_pic_list_sps_idc[ i ] equal to 0 specifies that the syntax element ref_pic_list_sps_flag[ i ] is present in the slice header of the slice referencing the PPS. pps_ref_pic_list_sps_idc[ i ] equal to 1 or 2 specifies that the syntax element ref_pic_list_sps_flag[ i ] is not present in the slice header of the slice referencing the PPS. pps_ref_pic_list_sps_idc[ i ] equal to 3 is reserved for future use by ITU-T | ISO / IEC.

[0392] pps_temporal_mvp_enabled_idc equal to 0 specifies that the syntax element lice_temporal_mvp_enabled_flag is present in the slice header of slices with slice_type not equal to 1 in slices referencing the PPS. pps_temporal_mvp_enabled_idc equal to 1 or 2 specifies that slice_temporal_mvp_enabled_flag is not present in the slice header of slices referencing the PPS. pps_temporal_mvp_enabled_idc equal to 3 is reserved for future use by ITU-T | ISO / IEC.

[0393] pps_mvd_l1_zero_ide equal to 0 specifies that the syntax element mvd_l1_zero_flag is present in the slice header of the slice referencing the PPS. pps_mvd_l1_zero_idc equal to 1 or 2 specifies that mvd_l1_zero_flag is not present in the slice header of the slice referencing the PPS. pps_mvd_l1_zero_idc equal to 3 is reserved for future use by ITU-T | ISO / IEC.

[0394] pps_collocated_from_l0_idc equal to 0 specifies that the syntax element collocated_from_l0_flag is present in the slice header of the slice referencing the PPS. pps_collocated_from_l0_idc equal to 1 or 2 specifies that the syntax element collocated_from_l0_flag is not present in the slice header of the slice referencing the PPS. pps_collocated_from_l0_idc equal to 3 is reserved for future use by ITU-T | ISO / IEC.

[0395] pps_six_minus_max_num_merge_cand_plus1 equal to 0 specifies that six_minus_max_num_merge_cand is present in the slice header of the slice referencing the PPS. pps_six_minus_max_num_merge_cand_plus1 greater than 0 specifies that six_minus_max_num_merge_cand is not present in the slice header of the slice referencing the PPS. The value of pps_six_minus_max_num_merge_cand_plus1 shall be in the range of 0 to 6, inclusive.

[0396] pps_five_minus_max_num_subblock_merge_cand_plus1 equal to 0 specifies that five_minus_max_num_subblock_merge_cand is present in the slice header of the slice referencing the PPS. pps_five_minus_max_num_subblock_merge_cand_plus1 greater than 0 specifies that five_minus_max_num_subblock_merge_cand is not present in the slice header of the slice referencing the PPS. The value of pps_five_minus_max_num_subblock_merge_cand_plus1 shall be in the range of 0 to 6, inclusive.

[0397] pps_max_num_merge_cand_minus_max_num_triangle_cand_minus1 equal to 0 specifies that max_num_merge_cand_minus_max_num_triangle_cand is present in the slice header of the slice referencing the PPS. pps_max_num_merge_cand_minus_max_num_triangle_cand_minus1 greater than 0 specifies that max_num_merge_cand_minus_max_num_triangle_cand is not present in the slice header of the slice referencing the PPS. The value of pps_max_num_merge_cand_minus max_num_triangle_cand_minus1 shall be in the range of 0 to MaxNumMergeCand -1, inclusive.

[0398] pps_loop_filter_across_virtual_boundaries_disabled_flag equal to 1 specifies that in-loop filtering operations are disabled across virtual boundaries in pictures that reference the PPS. pps_loop_filter_across_virtual_boundaries_disabled_flag equal to 0 specifies that such disabling of in-loop filtering operations is not applied in pictures that reference the PPS. In-loop filtering operations include deblocking filter, sample adaptive offset filter, and adaptive loop filter operations. When not present, the value of pps_loopfilter_across_virtual_boundaries_disabled_flag is inferred to be equal to 0.

[0399] pps_num_ver_virtual_boundaries specifies the number of pps_virtual_boundaries_pos_x[ i ] syntax elements present in the PPS. When pps_virtual_boundariespos_x[ i ] is not present, it is inferred to be equal to 0.

[0400] pps_virtual_boundaries_pos_x[ i ] is used to calculate the value of PpsVirtualBoundariesPosX[ i ], which specifies the position of the i-th vertical virtual boundary in luma samples. pps_virtual_boundaries_pos_x[ i ] should be in the range of 1 to Ceil(pic_widthin_luma_samples ÷ 8) - 1, inclusive.

[0401] The positions of the vertical virtual boundaries PpsVirtualBoundariesPosX[ i ] are derived as follows:

[0402] PpsVirtualBoundariesPosX[ i ]= pps_virtual_boundariespos_x[ i ]* 8

[0403] The distance between any two vertical virtual boundaries should be greater than or equal to CtbSizeY luma samples.

[0404] pps_num_hor_virtual_boundaries specifies the number of pps_virtual_boundaries_pos_y[ i ] syntax elements present in the PPS. When pps_num_hor_virtual_boundaries is not present, it is inferred to be equal to 0.

[0405] pps_virtual_boundaries_pos_y[ i ] is used to calculate the value of PpsVirtualBoundariesPosY[ i ], which specifies the position of the i-th horizontal virtual boundary in luma samples. pps_virtual_boundaries_pos_y[ i ] should be in the range of 1 to Ceil(pic_height_in_luma_samples ÷ 8) - 1, inclusive.

[0406] The positions of the horizontal virtual boundaries PpsVirtualBoundariesPosY[ i ] are derived as follows:

[0407] PpsVirtualBoundariesPosY[ i ] = pps_virtual boundaries_pos_y[ i] * 8

[0408] The distance between any two horizontal virtual borders should be greater than or equal to CtbSizeY luma samples.

[0409] slice_header_extension_present_flag equal to 0 specifies that the slice header extension syntax element is not present in the slice header of the coded picture referencing the PPS. slice_header_extension_present_flag equal to 1 specifies that the slice header extension syntax element is present in the slice header of the coded picture referencing the PPS. slice_header_extension_present_flag shall be equal to 0 in bitstreams conforming to this version of the specification.

[0410] pps_extension_flag equal to 0 specifies that the pps_extension_data_flag syntax element is not present in the PPS RBSP syntax structure. pps_extension_flag equal to 1 specifies that the pps_extension_data_flag syntax element is present in the PPS RBSP syntax structure.

[0411] pps_extension_data_flag can have any value. Its presence and value do not affect the decoder's conformance to the profile specified in this version of this specification. Decoders conforming to this version of this specification should ignore all pps_extension_data_flag syntax elements.

[0412] As described above, pictures and their regions may be classified based on which types of prediction modes (e.g., B-type, P-type, or I-type) may be used to encode their video blocks. As provided in Table 2, a NAL unit may include an access unit delimiter. In JVET-O2001, an access unit delimiter is used to indicate the start of an access unit and the type of slices in a coded picture present in an access unit containing an access unit delimiter NAL unit. Table 5 shows the syntax of the access unit delimiter provided in JVET-O2001.

[0413]

[0414] Regarding the access_unit_delimiter_rbsp() syntax structure, JVET-O2001 provides the following semantics:

[0415] An access unit delimiter is used to indicate the start of an access unit and the types of slices in a coded picture that are present in the access unit containing the access unit delimiter NAL unit. There is no canonical decoding process associated with an access unit delimiter.

[0416] pic_type indicates that the slice_type values ​​of all slices of the coded pictures in the access unit containing the access unit delimiter NAL unit are the number of sets listed in Table 6 for a given value of pic_type. In bitstreams conforming to this version of this specification, the value of pic_type shall be equal to 0, 1, or 2. Other values ​​of pic_type are reserved for future use by ITU-T | ISO / IEC. Decoders conforming to this version of this specification shall ignore all reserved values ​​of pic_type.

[0417]

[0418] As provided in Table 2, a NAL unit may include a coded slice of a picture. The slice syntax structure includes a slice_header() syntax structure and a slice_data() syntax structure. Table 7 shows the syntax of a slice header provided in JVET-O2001.

[0419]

[0420]

[0421]

[0422]

[0423]

[0424] Regarding Table 7, JVET-O2001 provides the following semantics:

[0425] When present, the value of each of the slice header syntax elements slice_pic_parameter_set_id, non_reference_picture_flag, colour_plane_id, slice_pic_order_cnt_lsb, recovery_poc_cnt, no_output_of_prior_pics_flag, pic_output_flag, and slice_temporal_mvp_enabled_flag shall be the same in all slice headers of a coded picture.

[0426] The variable CuQpDeltaVal, which specifies the difference between the luma quantization parameter and its prediction for coding units containing cu_qp_delta_abs, is set equal to 0. The variable CuQpDeltaVal, which specifies the difference between the luma quantization parameter and its prediction for coding units containing cu_chroma_qp_offset_flag, is set equal to 0. Cb , Qp' Cr and Qp' CbCr The value of the variable CuQpOffset to use when the corresponding value of the quantization parameter Cb 、CuQpOffset Cr and CuQpOffset CbCr All are set equal to 0.

[0427] slice_pic_parameter_set_id specifies the value of pps_pic_parameter_set_id of the PPS in use. The value of slice_pic_parameter_set_id shall be in the range of 0 to 63, inclusive.

[0428] Bitstream conformance requires that the value of Temporaild of the current picture shall be greater than or equal to the value of TemporalId of the PPS with pps_pic_parameter_set_id equal to slice_pic_parameter_set_id.

[0429] slice_address specifies the slice address of the slice. When not present, the value of slice_address is inferred to be equal to 0.

[0430] If rect_slice_flag is equal to 0, the following applies:

[0431] - Slice address is the specified brick ID.

[0432] - The length of slice_address is Ceil(Log2 (NumBricksInPic)) bits.

[0433] -slice_address value should be in the range of 0 to NumBricksInPic - 1 (inclusive).

[0434] Otherwise (rect_slice_flag is equal to 1), the following applies:

[0435] -The slice address is the slice ID of the slice.

[0436] -The length of slice_address is signalled_slice_id_length_minus1 + 1 bits.

[0437] - If signalled_slice_id_flag is equal to 0, the value of slice_address shall be in the range of 0 to num_slices_in_pic_minus1, inclusive. Otherwise, the value of slice_address shall be in the range of 0 to 2. (signalled _slice_id_length_minus1 +1) - 1 (inclusive of the end value).

[0438] Bitstream conformance requires that the following constraints apply:

[0439] - The value of slice_address shall not be equal to the value of slice_address of any other coded slice NAL unit of the same coded picture.

[0440] - When rect_slice_flag is equal to 0, the slices of the picture shall be in the order of increasing values ​​of their slice addresses.

[0441] - The shape of the slices of a picture shall be such that each tile, when decoded, shall have its entire left and entire top borders consisting of the picture borders or of the borders of previously decoded tiles.

[0442] num_bricksin_slice_minus1, when present, specifies the number of bricks in the slice minus 1. The value of num_bricksin_slice shall be in the range of 0 to NumBrickslnPic - 1, inclusive. When rect_slice_flag is equal to 0 and single_brick_per_slice_flag is equal to 1, the value of num_bricksin_slice_minus1 is inferred to be equal to 0. When single_brick_per_slice_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to 0.

[0443] The variables NumBricksInCurrSlice specifying the number of bricks in the current slice and SliceBrickIdx[i] specifying the brick index of the i-th brick in the current slice are derived as follows:

[0444]

[0445] The variables SubPicIdx, SubPicLeftBoundaryPos, SubPicTopBoundaryPos, SubPicRightBoundaryPos, and SubPicBotBoundaryPos are derived as follows:

[0446]

[0447] non_reference_picture_flag equal to 1 specifies that the picture containing the slice must not be used as a reference picture. non_reference_picture_flag equal to 0 specifies that the picture containing the slice may or may not be used as a reference picture.

[0448] slice_type specifies the encoding type of the slice according to Table 8.

[0449]

[0450] When nal_unit_type is a value of nal_unit_type in the range of IDR_W_RADL to CRA_NUT (inclusive), and the current picture is the first picture in the access unit, slice_type shall be equal to 2.

[0451] When separate_colour_plane_flag is equal to 1, colour_plane_id specifies the colour plane associated with the current slice RBSP. The value of colour_plane_id shall 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.

[0452] Note - There is no dependency between the decoding processes of pictures with different colour_plane_id values.

[0453] slice_pic_order_cnt_lsb represents the picture order count modulo MaxPicOrderCntLsb of the current picture. The length of the slice_pic_order_cntisb syntax element is log2_max pic_order_cnt_lsb_minus4 + 4 bits. The value of slice_pic_order_cnt_lsh shall be in the range of 0 to MaxPicOrderCntLsb - 1, inclusive.

[0454] recovery_poc_cnt specifies the recovery point of the decoded picture in the output order. If there is a picture picA in the CVS that follows the current GDR picture in the decoding order and has a PicOrderCntVal equal to the PicOrderCntVal of the current GDR picture plus the value of recovery_poc_cnt, then the picture picA is called the recovery point picture. Otherwise, the first picture in the output order that has a PicOrderCntVal greater than the value of the current picture's PicOrderCntVal plus recovery_poc_cnt is called the recovery point picture. The recovery point picture should not be before the current GDR picture in the decoding order. The value of recovery_poc_cnt should be in the range of 0 to MaxPicOrderCntLsb - 1 (including the end value).

[0455] The variable RpPicOrderCntVal is derived as follows:

[0456] RpPicOrderCntVal - PicOrderCntVal + recovery_poc_cnt

[0457] no_output_of_prior_pics_flag affects the output of previously decoded pictures in the decoded picture buffer following the picture of the CLVSS that is not the first picture in the bitstream as specified.

[0458] pic_output_flag affects the decoded picture output and removal process according to the specification. When pic_output_flag is not present, it is inferred to be equal to 1.

[0459] ref_pic_list_sps_flag[ i ] equal to 1 specifies that reference picture list i for the current slice is derived based on one of the syntax structures in the ref pic_list_struct(listIdx, rplsIdx) syntax structure in the SPS (where listIdx is equal to i). ref_pic_list_sps_flag[ i ] equal to 0 specifies that reference picture list i for the current slice is derived based on the ref_pic_list_struct(listIdx, rplsIdx) syntax structure (where listIdx is equal to i), which is directly included in the slice header of the current picture.

[0460] When ref_pic_list_sps_flag[ i ] is not present, the following applies:

[0461] - If num_ref_pic_lists_in_sps[ i ] is equal to 0, the value of ref_pic_list_sps_flag[ i ] is inferred to be equal to 0.

[0462] - Otherwise (num_ref_pic_lists_insps[ i ] is greater than 0), if rpl1_idx_present_flag is equal to 0, the value of ref_pic_list_sps_flag[ 1 ] is inferred to be equal to ref_pic_list_sps_flag[ 0 ].

[0463] - Otherwise, the value of ref_pic_list_sps_flag[ i ] is inferred to be equal to pps_ref_pic_list_sps_idc[ i ] - 1.

[0464] ref_pic_list_idx[ i ] specifies the index into the list of ref_pic_list_struct(listIdx, rplsIdx) syntax structures included in the SPS for deriving the reference picture list i of the current picture, where listIdx is equal to i. The syntax element ref_pic_list_idx[ i ] is represented by Ceil(Log2(num_ref_pic_lists_in_sps[ i ])) bits. When not present, the value of ref_pic_list_idx[ i ] is inferred to be equal to 0. The value of ref_pic_list_idx[ i ] shall be in the range of 0 to num_ref_pic_lists_in_sps[ i ] - 1, inclusive. When ref_pic_list_sps_flag[ i ] is equal to 1 and num_ref_pic_lists_in_sps[ i ] is equal to 1, the value of ref_pic_list_idx[ i ] is inferred to be equal to 0. When ref_pic_list_sps_flag[ i ] is equal to 1 and rpl1_idx_present_flag is equal to 0, the value of ref_pic_list_idx[ 1 ] is inferred to be equal to ref_pic_list_idx[ 0 ].

[0465] The variable RplsIdx[ i ] is derived as follows:

[0466] RplsIdx[ i ] = ref_pic_list_sps_flag[ i ]? ref_pic_list_idx [i]: num_ref_pic_lists_in_sps[ i]

[0467] slice_poc_lsb_lt[ i ][ j ] specifies the picture order count modulo MaxPicOrderCntLsb value of the j-th LTRP entry in the i-th reference picture list. The length of the slice_poc_lsb_lt[ i ][ j ] syntax element is log2_max_pic_order_cnt_lsb_minus4 + 4 bits.

[0468] The variable PocLsbLt[i][j] is derived as follows:

[0469] PocLsbLt[ i ][ j ] = ltrp_in_slice_header_flag[ i ][ RplsIdx[ i ] ]?

[0470] slice_poc_lsb_lt[i ][j ] : rpls_poc_lsb_lt[ listIdx ][ RplsIdx[ i ]][ j ]

[0471] delta_poc_msb_present_flag[ i ][ j ] equal to 1 specifies that delta_poc_msb_cycle_lt[ i ][ j ] is present. delta_poc_msb_present_flag[ i ][ j ] equal to 0 specifies that delta_poc_msb_cycle_lt[ i ][ j ] is not present.

[0472] Let prevTid0Pic be the previous picture in decoding order that has the same nuh_layer_id as the current picture, has TemporalId equal to 0 and is not a RASL or RADL picture. Let setOfPrevPocVals be the set consisting of:

[0473] -PicOrderCntVal of prevTid0Pic,

[0474] - the PicOrderCntVal of each picture referenced by an entry in RefPicList[ 0 ] or RefPicList[ 1 ] of prevTid0Pic and having the same nuh_layer_id as the current picture,

[0475] - PicOrderCntVal of each picture after prevTid0Pic in decoding order, with the same nuh_layer_id as the current picture and before the current picture in decoding order.

[0476] When there is more than one value in setOfPrevPocVals for which the value modulo MaxPicOrderCntLsb is equal to PocLsbLt[ i ][ j ], the delta_poc_msb present_flag[ i ][ j ] value shall be equal to 1.

[0477] delta_poc_msb_cycle_ld[i][j] specifies the value of FullPocLt[i][j] as follows:

[0478]

[0479] The value of delta_poc_msb_cycle_lt[ i ][ j ] shall be between 0 and 2. (32 - log2_max_pic_order_cntisb_minus4 - 4) When not present, delta_poc_msb_cycle_lt[ i ][ j ] is inferred to be equal to 0.

[0480] num_ref_idx_active_override_flag equal to 1 specifies that the syntax element num_ref_idx_active_minus1[0] is present for P slices and B slices, and the syntax element num_ref_idx_active_minus1[1] is present for B slices. num_ref_idx_active_override_flag equal to 0 specifies that the syntax elements num_ref_idx_active_minus1[0] and num_ref_idx_active_minus1[1] are not present. When not present, the value of num_ref_idx_active_override_flag is inferred to be equal to 1.

[0481] num_ref_idx_active_minus1[ i ] is used to derive the variable NumRefIdxActive[ i ] as specified in Equations 7 through 98. The value of num_ref_idx_active_minus1[ i ] shall be in the range of 0 to 14, inclusive.

[0482] For i equal to 0 or 1, when the current slice is a B slice, num_ref_idx_active_override_flag is equal to 1 and num_ref_idx_active_minus1[ i ] does not exist, num_ref_idx_active_minus1[ i ] is inferred to be equal to 0.

[0483] When the current slice is a P slice, num_ref_idx_active_override_flag is equal to 1, and num_ref_idx_active_minus1[0] does not exist, num_ref_idx_active_minus1[0] is inferred to be equal to 0.

[0484] The variable NumRefIdxActive[i] is derived as follows:

[0485]

[0486] A value of NumRefIdxActive[i] - 1 specifies the maximum reference index of reference picture list i that can be used to decode the slice. When the value of NumRefIdxActive[i] is equal to 0, the reference index of reference picture list i is not available for decoding the slice.

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

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

[0489] partition_constraints_override_flag equal to 1 specifies that partition constraints parameters are present in the slice header. partition_constraints_override_flag equal to 0 specifies that partition constraints parameters are not present in the slice header. When not present, the value of partition_constraints_override_flag is inferred to be equal to 0.

[0490] slicelog2_diff_min_qt_min_cb_luma specifies the difference between the base-2 logarithm of the minimum size in luma samples of the luma leaf blocks resulting from quadtree partitioning of the CTU and the base-2 logarithm of the minimum coding block size in luma samples of the luma CU in the current slice. The value of slice_log2_diff_min_qt_min_cb_luma should be in the range of 0 to CtbLog2SizeY - MinCbLog2SizeY, inclusive. When not present, the value of slice_log2_diff_min_qt_min_cb_luma is inferred as follows:

[0491] - If slice_type is equal to 2 (I), the value of slice_log2_diff_min_qt_min_cbluma is inferred to be equal to sps_log2_diff_min_qt_min_cb_intra_slice_luma.

[0492] - Otherwise (slice_type is equal to 0 (B) or 1 (P)), the value of slice_log2_diff_min_qt_min_eb_luma is inferred to be equal to sps_log2_diff_min_qt_min_cb_inter_slice.

[0493] slice_max_mtt_hierarchy_depth_luma specifies the maximum hierarchy depth of coding units resulting from multi-type tree partitioning of quadtree leaves in the current slice. The value of slice_max_mtt_hierarchy_depth_luma shall be in the range of 0 to CtbLog2SizeY - MinCbLog2SizeY, inclusive. When not present, the value of slice_max_mtt_hierarchy_depth_luma is inferred as follows:

[0494] - If slice_type is equal to 2 (I), the value of slice_max_mtt_hierarchy_depth_luma is inferred to be equal to sps_max_mtt_hierarchy_depth_intra_slice_luma.

[0495] - Otherwise (slice_type is equal to 0 (B) or 1 (P)), the value of slice_max_mtt_hierarchy_depth_luma is inferred to be equal to sps_max_mtt_hierarchy_depth_inter_slice.

[0496] slice_log2_diff_max_bt_min_qt_luma specifies the difference between the base 2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can be split using binary partitioning and the base 2 logarithm of the minimum size (width or height) in luma samples of a luma leaf block resulting from quadtree partitioning of the CTU in the current slice. The value of slicelog2_diff_max_bt_min_qt_luma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeY, inclusive. When not present, the value of slice_log2_diff_max_bt_min_qt_luma is inferred as follows:

[0497] - If slice_type is equal to 2 (I), the value of slice_log2_diff_max_bt_min_qt_luma is inferred to be equal to sps_log2_diff_max_bt_min_qt_intra_slice_luma.

[0498] - Otherwise (slice_type is equal to 0 (B) or 1 (P)), the value of slice_log2_diff_max_bt_min_qt_luma is inferred to be equal to sps_log2_diff_max_bt_min_qt_inter_slice.

[0499] slice_log2_diff_max_tt_min_qt_luma specifies the difference between the base 2 logarithm of the maximum size (width or height) in luma samples of a luma coding block that can use ternary partitioning and the base 2 logarithm of the minimum size (width or height) in luma samples of a luma leaf block resulting from quadtree partitioning of the CTU in the current slice. The value of slice_log2_diff_max_bt_min_qt_luma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeY, inclusive. When not present, the value of slice_log2_diff_max_bt_min_qt_luma is inferred as follows:

[0500] - If slice_type is equal to 2 (I), the value of slice_log2_diff_max_tt_min_qt_luma is inferred to be equal to sps_log2_diff_max_tt_min_qt_intra_slice_luma.

[0501] - Otherwise (slice_type is equal to 0 (B) or 1 (P)), the value of slice_log2_diff_max_tt_min_qt_luma is inferred to be equal to sps_log2_diff_max_tt_min_qt_inter_slice.

[0502] slice_log2_diff_min_qt_min_cb_chroma specifies the difference between the base 2 logarithm of the minimum size in luma samples of chroma leaf blocks resulting from quadtree partitioning of chroma CTUs with treeType equal to DUAL_TREE_CHROMA and the base 2 logarithm of the minimum coding block size in luma samples of chroma CUs with treeType equal to DUAL_TREE_CHROMA in the current slice. The value of slice_log2_diff_min_qt_min_cb_chroma shall be in the range of 0 to CtbLog2SizeY - MinCbLog2SizeY, inclusive. When not present, the value of slice_log2_diff_min_qt_min_cb_chroma is inferred to be equal to sps_log2_diff_min_qt_min_cb_intra_slice_chroma.

[0503] slice_max_mtt_hierarchy_depth_chroma specifies the maximum hierarchical depth of coding units produced by multi-type tree partitioning of quadtree leaves with treeType equal to DUAL_TREE_CHROMA in the current slice. slice_max_mtt_hierarchy_depth_chroma should be within CtbLog2SizeY - MinCbLog2SizeY (inclusive). When not present, slice_max_mtt_hierarchy_depth_chroma is inferred to be equal to sps_max_mtt_hierarchy_depth_intra_slices_chroma.

[0504] slice_log2_diff_max_bt_min_qt_chroma specifies the difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a chroma coded block that can be binary split and the base-2 logarithm of the minimum size (width or height) in luma samples of a chroma leaf block resulting from quadtree splitting of a chroma CTU with treeType equal to DUAL_TREE_CHROMA in the current slice. The value of slice_log2_diff_max_bt_min_qt_chroma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeC, inclusive. When not present, the value of slice_log2_diff_max_bt_min_qt_chroma is inferred to be equal to sps_log2_diff_max_bt_min_qt_intra_slice_chroma.

[0505] slice_log2_diff_max_tt_min_qt_chroma specifies the difference between the base-2 logarithm of the maximum size (width or height) in luma samples of a chroma coded block that can be partitioned using ternary partitioning and the base-2 logarithm of the minimum size (width or height) in luma samples of a chroma leaf block resulting from quadtree partitioning of a chroma CTU with treeType equal to DUAL_TREE_CHROMA in the current slice. The value of slice_log2_diff_max_tt_min_qt_chroma shall be in the range of 0 to CtbLog2SizeY - MinQtLog2SizeC, inclusive. When not present, the value of slice_log2_diff_max_tt_min_qt_chroma is inferred to be equal to sps_log2_diff_max_tt_min_qt_intra_slice_chroma.

[0506] The variables MinQtLog2SizeY, MmQtLog2Size C, MinQtSizeY, MinQtSizeC, MaxBtSizeY, MaxBtSizeC, MinBtSizeY, MaxTtSizeY, MaxTtSizeC, MinTtSizeY, MaxMttDepthY and MaxMttDepthC are derived as follows:

[0507] MinQtLog2SizeY = MinCbLog2SizeY + slice_log2_diff_min_qt_min_cb_luma

[0508] MinQtLog2SizeC = MinCbLog2SizeY + slice_log2_diff_min_qt_min_cb_chroma

[0509] MinQtSizeY = 1 << MinQtLog2SizeY

[0510] MinQtSizeC = 1 << MinQtLog2SizeC

[0511] MaxBtSizeY = 1 << (MinQtLog2SizeY + slice_log2_diff_max_bt_min_qt_luma)

[0512] MaxBtSizeC = 1 << (MinQtLog2SizeC + slice_log2_diff_max_bt_min_qt_chroma)

[0513] MinBtSizeY = 1 << MinCbLog2SizeY

[0514] MaxTtSizeY = 1 << (MinQtLog2SizeY + slice_log2_diff_max_tt_min_qt_luma)

[0515] MaxTtSizeC = 1 << (MinQtLog2SizeC + slice_log2_diff_max_tt_min_qt_chroma)

[0516] MinTtSizeY = 1 << MinCbLog2SizeY

[0517] MaxMttDepthY = slice_max_mtt_hierarchy_depth_luma

[0518] MaxMttDepthC = slice_max_mtt_hierarchy_depth_chroma

[0519] slice_temporal_mvp_enabled_flag specifies whether the temporal motion vector predictor can be used for inter prediction. If slice_temporal_mvp_enabled_flag is equal to 0, the syntax elements of the current picture should be constrained so that the temporal motion vector predictor is not used in the decoding of the current picture. Otherwise (slice_temporal_mvp_enabled_flag is equal to 1), the temporal motion vector predictor can be used in the decoding of the current picture.

[0520] When slice_temporal_mvp_enabled_flag is not present, the following applies:

[0521] - When sps_temporal_mvp_enabled_flag is equal to 0, the value of slice_temporal_mvp_enabled_flag is inferred to be equal to 0.

[0522] - Otherwise (sps_temporal_mvp_enabled_flag is equal to 1), the value of slice_temporal_mvp_enabled_flag is inferred to be equal to pps_temporal_mvp_enabled_idc - 1.

[0523] mvd_l1_zero_flag equal to 1 indicates that the mvd_coding(x0, y0, 1) syntax structure is not parsed, MvdLl[x0][y0][compIdx] and MvdL1[x0][y0][cpIdx][compIdx] are set equal to 0, where compldx = 0..1 and cpldx = 0..2. mvd_l1_zero_flag equal to 0 indicates that the mvd_coding(x0, y0, 1) syntax structure is parsed. When not present, the value of mvd_l1_zero_flag is inferred to be equal to pps_mvd_l1_zero_idc - 1.

[0524] cabac_init_flag specifies the method for determining the initialization table used in the initialization process for context variables. When cabac_init_flag is not present, it is inferred to be equal to 0.

[0525] collocated_from_l0_flag equal to 1 specifies that the collocated picture used for temporal motion vector prediction originates from reference picture list 0. collocated_from_l0_flag equal to 0 specifies that the collocated picture used for temporal motion vector prediction originates from reference picture list 1. When collocated_from_l0_flag is not present, the following applies:

[0526] - If slice_type is not equal to B, the value of collocated_from_l0_flag is inferred to be equal to 1.

[0527] - Otherwise (slice_type is equal to B), the value of collocated_from_l0_flag is inferred to be equal to pps_collocated_from_l0_idc - 1.

[0528] collocated_ref_idx specifies the reference index of the collocated picture used for temporal motion vector prediction.

[0529] 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 picture in list 0, and the value of collocated_ref_idx shall be in the range of 0 to NumRefldxActive[0] - 1 (inclusive).

[0530] When slice_type is equal to B and collocated_from_10_flag is equal to 0, collocated_ref_idx refers to the picture in list 1, and the value of collocated_ref_idx shall be in the range of 0 to NumRefldxActive[ 1 ] −1 (inclusive).

[0531] When collocated_ref_idx does not exist, the value of collocated_ref_idx is inferred to be equal to 0.

[0532] Bitstream conformance requires that the picture referenced by collocated_ref_idx shall be the same for all slices of a coded picture. Bitstream conformance requires that the resolution of the reference picture referenced by collocated_ref_idx and the current picture shall be the same.

[0533] six_minus_max_num_merge_cand specifies the maximum number of merge motion vector prediction (MVP) candidates supported in a slice minus 6. The maximum number of merge MVP candidates MaxNumMergeCand is derived as follows:

[0534] MaxNumMergeCand = 6 - six_minus_max_num_merge_cand

[0535] The value of MaxNumMergeCand shall be in the range of 1 to 6, inclusive. When not present, the value of six_minus_max_num_merge_cand is inferred to be equal to pps_six_minus_max_num_merge_cand_plus1 - 1.

[0536] five_minus_max_num_subblock_merge_cand specifies the maximum number of subblock-based merge motion vector prediction (MVP) candidates supported in a slice minus 5.

[0537] When five_minus…max_num_subblock_merge_cand does not exist, the following applies:

[0538] - If sps_affine_enabled_flagg is equal to 0, the value of five_minus_max_num subblockmerge_cand is inferred to be equal to 5 - (sps_sbtmvp_enabled_flag && slice_temporal_mvp_enabled_flag).

[0539] - Otherwise ((sps_affine_enabled_flag is equal to 1), the value of five_minus_max__num_subblock_merge_cand is inferred to be equal to pps_five_minus _max_nurn_subbIock_mcrge_cand plus 1 - 1.

[0540] The maximum number of sub-block-based merge MVP candidates MaxNumSubblockMergeCand is derived as follows:

[0541] MaxNumSubblockMergeCand = 5 - five_minus_max_num_subblock_merge_cand

[0542] The value of MaxNumSubblockMergeCand should be in the range of 0 to 5 (inclusive).

[0543] slice_fpel_mmvd_enabled_flag equal to 1 specifies that merge mode with motion vector differences in the current slice uses integer sample precision. slice_fpel_mmvd_enabled_flag equal to 0 specifies that merge mode with motion vector differences in the current slice may use fractional sample precision. When not present, the value of slice_fpel_mmvd_enabled_flag is inferred to be equal to 0.

[0544] slice_disable_bdof_dmvr_flag equal to 1 specifies that either bidirectional optical flow inter prediction and decoder motion vector correction based inter bi prediction are enabled in the current slice. slice_disable_bdof_dmvr_flag equal to 0 specifies that bidirectional optical flow inter prediction and decoder motion vector correction based inter bi prediction may or may not be enabled in the current slice. When slice_disable_bdof_dmvr_flag is not present, the value of slice_disable_bdof_dmvr_flag is inferred to be equal to 0.

[0545] max_num_merge_cand_minus_max_num_triangle_cand specifies the maximum number of triangle merge mode candidates supported in a slice minus MaxNumMergeCand.

[0546] When max_num_merge_cand_rninus_max_num_triangle_cand does not exist, sps_triangle_enabled_flag is equal to 1, and MaxNumMergeCand is greater than or equal to 2, max_num_merge_cand_minus_max_num_triangle_cand is inferred to be equal to pps_max_num_merge_cand_minus_max_num_triangle_cand_minus1 + 1. The maximum number of triangle merge mode candidates MaxNumTriangleMergeCand is derived as follows:

[0547] MaxNumTriangleMergeCand =

[0548] MaxNumMergeCand - max_num_merge_cand_minus_max_num_triangle_cand

[0549] When max_num_merge_cand_minus_max_num_triangle_cand is present, the value of MaxNumTriangleMergeCand shall be in the range of 2 to MaxNumMergeCand, inclusive.

[0550] When max_num_merge_cand_minus_max_num_triangle_cand is not present (sps_triangle_enabled_flag is equal to 0 or MaxNumMergeCand is less than 2), MaxNumTriangleMergeCand is set equal to 0.

[0551] When MaxNumTriangleMergeCand is equal to 0, the triangle merge mode is not allowed for the current slice.

[0552] slice_six_minus_max_num_ibc_merge_cand specifies the maximum number of IBC merge block vector prediction (BVP) candidates supported in a slice minus 6. The maximum number of IBC merge BVP candidates MaxNumlbcMergeCand is derived as follows:

[0553] MaxNumlbcMergeCand = 6 - slice_six_minus_max_num_ibc_merge_cand

[0554] The value of MaxNumlbcMergeCand should be in the range of 1 to 6 (inclusive).

[0555] slice_joint_cbcr_sign_flag specifies whether the co-located residual samples of the two chroma components have inverted signs in a transform unit with tu_joint_cbcr_residual_flag[ x0 ][ y0 ] equal to 1. When tu_joint_cbcr_residual_flag[ x0 ][ y0 ] is equal to 1 for the transform unit, slice_joint_cbcr_sign_flag equal to 0 specifies that the sign of each residual sample of the Cr (or Cb) component is the same as the sign of the co-located Cb (or Cr) residual sample, and slice_joint_cbcr_sign_flag equal to 1 specifies that the sign of each residual sample of the Cr (or Cb) component is the inverted sign of the co-located Cb (or Cr) residual sample.

[0556] slice_qp_delta specifies the Qp to be used for the coding blocks in the slice Y The initial value of until modified by the value of CuQpDeltaVal in the coding unit layer. py The initial value of the quantization parameter SliceQ PY Export as follows:

[0557] SliceQ PY = 26 + init_qp_minus26 + slice_qp_delta

[0558] SliceQ PY The value should be within –QpBdOffset Y to +63 inclusive.

[0559] When determining Qp' Cb slice_cb_qp_offset specifies the difference to be added to the value of pps_cb_qp_offset when quantizing the value of the parameter. The value of slice_cb_qp_offset shall be in the range of -12 to +12, inclusive. When slice_cb_qp_offset is not present, it is inferred to be equal to 0. The value of pps_cb_qp_offset + slice_cb_qp_offset shall be in the range of -12 to +12, inclusive.

[0560] When determining Qp' Crslice_cr_qp_offset specifies the difference to be added to the value of pps_cb_qp_offset when quantizing the value of the parameter. The value of slice_cr_qp_offset shall be in the range of -12 to +12, inclusive. When slice_cr_qp_offset is not present, it is inferred to be equal to 0. The value of pps_cr_qp_offset + slice_cr_qp_offset shall be in the range of -12 to +12, inclusive.

[0561] When determining Qp' CbCr When slice_joint_cbcr_qp_offset is not present, it is inferred to be equal to 0. The value of ppsjoint_cbcr_qp_offset + slice_joint_cbcr_qp_offset shall be in the range of -12 to +12, inclusive.

[0562] slice_sao_luma_flag equal to 1 specifies that SAO is enabled for luma components in the current slice, and slice_sao_luma_flag equal to 0 specifies that SAO is disabled for luma components in the current slice. When slice_sao_luma_flag is not present, it is inferred to be equal to 0.

[0563] slice_sao_chroma_flag equal to 1 specifies that SAO is enabled for the chroma components in the current slice, slice_sao_chroma_flag equal to 0 specifies that SAO is disabled for the chroma components in the current slice. When slice_sao_chroma_flag is not present, it is inferred to be equal to 0.

[0564] slice_alf_enabled_flag equal to 1 specifies that the adaptive loop filter is enabled in the slice and may be applied to the Y, Cb or Cr color components. slice_alf_enabled_flag equal to 0 specifies that the adaptive loop filter is disabled for all color components in the slice.

[0565] slice_num_alf_aps_ids_luma specifies the number of ALF APS referenced by the slice. The value of slice_num_alf_aps_ids_luma shall be in the range of 0 to 7 (inclusive).

[0566] 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 unit with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_luma[ i ] shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0567] For intra slices and slices in IRAP pictures, slice_alf_aps_id_luma[ i ] shall not reference ALF APS associated with other pictures than the picture containing the intra slice or the IRAP picture.

[0568] slice_alf_chroma_idc equal to 0 specifies that the adaptive loop filter is not applied to the Cb and Cr color components. slice_alf_chroma_idc equal to 1 indicates that the adaptive loop filter is applied to the Cb color component. slice_alf_chroma_idc equal to 2 indicates that the adaptive loop filter is applied to the Cr color component. slice_alf_chroma_idc equal to 3 indicates that the adaptive loop filter is applied to the Cb and Cr color components. When slice_alf_chroma_idc is not present, it is inferred to be equal to 0.

[0569] 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 units with aps_params_type equal to ALF_APS and adaptation_parameter_set_id equal to slice_alf_aps_id_chroma shall be less than or equal to the TemporalId of the coded slice NAL units.

[0570] For intra slices and slices in IRAP pictures, slice_alf_aps_id_chroma shall not reference an ALF APS associated with other pictures than the picture containing the intra slice or the IRAP picture.

[0571] dep_quant_enabled_flag equal to 0 specifies that dependency quantization is disabled. dep_quant_enabled_flag equal to 1 specifies that dependency quantization is enabled. When not present, the value of dep_quant_enabled_flag is inferred to be equal to pps_dep_quant_enable_idc - 1.

[0572] sign_data_hiding_enabled_flag equal to 0 specifies that sign bit hiding is disabled. sign_data_hiding_enabled_flag equal to 1 specifies that sign bit hiding is enabled. When sign_data_hiding_enabled_flag is not present, it is inferred to be equal to 0.

[0573] deblocking_filter_override_flag equal to 1 specifies that deblocking parameters are present in the slice header. deblocking_filter_override_flag equal to 0 specifies that deblocking parameters are not present in the slice header. When not present, the value of deblocking_filter_override_flag is inferred to be equal to 0.

[0574] slice_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the current slice. slice_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the current slice. When slice_deblocking_filter_disabled_flag is not present, it is inferred to be equal to pps_deblocking_filter_disabled_flag.

[0575] slice_beta_offset_div2 and slice_tc_offset_div2 specify the deblocking parameter offsets of 6 and tC for the current slice (divided by 2). The values ​​of slice_beta_offset_div2 and slice_tc_offset_div2 shall both be in the range of -6 to 6, inclusive. When not present, the values ​​of slice_beta_offset_div2 and slice_tc_offset_div2 are inferred to be equal to pps_beta_offset_div2 and pps_tc_offset_div2, respectively.

[0576] slice_lmcs_enabled_flag equal to 1 specifies that luma mapping with chroma scaling is enabled for the current slice. slice_lmcs_enabled_flag equal to 0 specifies that luma mapping with chroma scaling is disabled for the current slice. When slice_lmcs_enabled_flag is not present, it is inferred to be equal to 0.

[0577] slice_lmcs_aps_id specifies the adaptation_parameter_set_id of the LMCS APS referenced by the slice. The TemporalId of the APS NAL unit with aps_params_type equal to LMCS_APS and adaptation_parameter_set_id equal to slice_lmcs_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit. When present, the value of slice_lmcs_aps_id shall be the same for all slices of a picture.

[0578] slice_chroma_residual_scale_flag equal to 1 specifies that chroma residual scaling is enabled for the current slice. slice_chroma_residual_scale_flag equal to 0 specifies that chroma residual scaling is not enabled for the current slice. When slice_chroma_residual_scale_flag is not present, it is inferred to be equal to 0.

[0579] 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. slice_scaling_list_present_flag equal to 0 specifies that the scaling list data for the current picture is the derived default scaling list data specified in clause 7.4.3.16. When not present, the value of slice_scaling_list_present_flag is inferred to be equal to 0.

[0580] slice_scaling_list_aps_id specifies the adaptation_parameter_set_id of the scaling list APS. The TemporalId of the APS NAL unit with aps_params_type equal to SCALING_APS and adaptation_parameter_set_id equal to slice_scaling_list_aps_id shall be less than or equal to the TemporalId of the coded slice NAL unit.

[0581] When present, the value of slice_scaling_list_aps_id shall be the same for all slices of the picture.

[0582] When entry_point_offsets_present_flag is equal to 1, the variable NumEntryPoints specifying the number of entry points in the current slice is derived as follows:

[0583]

[0584] offset_len_minus1 plus 1 specifies the length of the entry point_offset_minusl[ i ] syntax element in bits. The value of offset_len_minusl shall be in the range of 0 to 31, inclusive.

[0585] entry_point_offset__minus1[ i ] plus 1 specifies the i-th entry point offset 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 subset index values ​​range from 0 to NumEntryPoints (inclusive). The first byte of the slice data is considered to be byte 0. When present, the anti-race bytes present in the slice data portion of the coded slice NAL unit are counted as part of the slice data for subset identification purposes. Subset 0 consists of bytes 0 to entry_point_offset_minus1[ 0 ] (inclusive) of the coded 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 coded slice data, where firstByte[ k ] and lastByte[ k ] are defined as:

[0586]

[0587] The last subset (where the subset index equals NumEntryPoints) consists of the remaining bytes encoding the slice data.

[0588] When entropy_coding_sync_enabled_flag is equal to 0, each subset shall consist of all coded bits of all CTUs within the same brick in the slice, and the number of subsets (i.e., the value of NumEntryPoints + l) shall be equal to the number of bricks in the slice.

[0589] When entropy_coding_sync_enabled_flag is equal to 1, each subset k (where k is in the range 0 to NumEntryPoints, inclusive) shall 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) shall be equal to the total number of tile-specific luma CTU rows in the slice.

[0590] slice_header_extension_length specifies the length of the slice header extension data in bytes, excluding the bits used to signal the slice_header_extension_length itself. The value of slice_header_extension_length shall be in the range of 0 to 256, inclusive. When not present, the value of slice_header_extension_length is inferred to be equal to 0.

[0591] slice_header_extension_data_byte can have any value. A decoder conforming to this version of this specification shall ignore the value of slice_header_extension_data_byte. Its value does not affect the conformance of a decoder to the profile specified in this version of this specification.

[0592] Signaling metadata describing the video coding attributes provided in JVET-02001 is less than ideal. Specifically, as described above, in some cases, an access unit may be required to accurately contain a coded picture. In addition, it may be necessary to signal the access unit delimiter at the beginning of each access unit. Therefore, it may be necessary to signal the access unit delimiter at the beginning of each picture. As described above, in WET-02001, the access unit delimiter is encapsulated in the NAL unit. Therefore, signaling the access unit delimiter for each picture requires signaling at least 3 bytes for each picture (i.e., 2 bytes for the NAL unit header and 1 byte for access_unit_delimiter_rbsp()), which may be inefficient, especially for relatively low bit rate applications. In addition, as described above, in JVET-02001, the slice design does not include slice segments (i.e., there are no independent / dependent slice segments). However, slices within the same picture can include redundant information. For example, referring to Table 7, in JVET-O2001, for each slice in a picture, slice_pic_parameter_set_id is signaled. However, slice_pic_parameter_set_id needs to be the same for each slice included in the picture. Therefore, the slice header in WET-O2001 may be inefficient because it may include unnecessary redundant information, such as picture information that is the same for all slices within a picture. The present disclosure describes techniques for efficiently signaling picture information.

[0593] Figure 1 1 is a block diagram illustrating an example of a system that may be configured to encode (e.g., encode and / or decode) video data in accordance with one or more techniques of this disclosure. System 100 represents an example of a system that may encapsulate video data in accordance with 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 the encoded video data via communication medium 110 and decode the encoded video data. 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, laptop or tablet computers, game consoles, medical imaging devices, and mobile devices (including, for example, smart phones, cellular phones, personal gaming devices).

[0594] The communication medium 110 may include any combination of wireless and wired communication media and / or storage devices. The communication medium 110 may include coaxial cables, fiber optic cables, twisted pair cables, 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. The communication medium 110 may include one or more networks. For example, the 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 telecommunication protocols. The telecommunication protocol may include proprietary aspects and / or may include standardized telecommunication protocols. Examples of standardized telecommunication protocols include digital video broadcasting (DVB) standards, advanced television system committee (ATSC) standards, integrated service digital broadcasting (ISDB) standards, cable data service interface specifications (DOCSIS) standards, global mobile communication systems (GSM) standards, code division multiple access (CDMA) standards, 3rd Generation Partnership Project (3GPP) standards, European Telecommunications Standards Institute (ETSI) standards, Internet Protocol (IP) standards, wireless application protocol (WAP) standards, and Institute of Electrical and Electronics Engineers (IEEE) standards.

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

[0596] Figure 4 is a conceptual diagram illustrating examples of components that may be included in a specific implementation of system 100. Figure 4 In the exemplary implementation shown, system 100 includes one or more computing devices 402A-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-412N. Figure 4The specific implementations shown in represent examples of systems that may be configured to allow digital media content (such as movies, live sporting events, etc.) and data and applications associated therewith and media presentations 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 television service network 404, wide area network 408, and / or local area network 410. For example, computing devices 402A to 402N may be equipped for wired and / or wireless communications and may be configured to receive services over one or more data channels, and may include televisions, including so-called smart televisions, set-top boxes, and digital video recorders. In addition, computing devices 402A to 402N may include desktop computers, laptops or tablet computers, game consoles, mobile devices (including, for example, "smart" phones, cellular phones, and personal gaming devices).

[0597] The television service network 404 is an example of a network configured to enable distribution of digital media content that may include television services. For example, the television service network 404 may include a public air television network, a public or subscription-based satellite television service provider network, and a public or subscription-based cable television provider network and / or a cloud or Internet service provider. It should be noted that, although in some examples, the television service network 404 may be primarily used to allow the provision of television services, the 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. In addition, it should be noted that in some examples, the television service network 404 may allow two-way communication between the television service provider site 406 and one or more of the computing devices 402A to 402N. The television service network 404 may include any combination of wireless and / or wired communication media. The television service network 404 may include coaxial cables, fiber optic cables, twisted pair cables, 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. The television service network 404 may operate according to a combination of one or more telecommunications protocols. The telecommunication protocol may include proprietary aspects and / or may include standardized telecommunication protocols. Examples of standardized telecommunication protocols include the DVB standard, the ATSC standard, the ISDB standard, the DTMB standard, the DMB standard, the Data Over Cable Service Interface Specification (DOCSIS) standard, the HbbTV standard, the W3C standard, and the UPnP standard.

[0598] Reference again Figure 4, the television service provider site 406 may be configured to distribute television services via the television service network 404. For example, the television service provider site 406 may include one or more broadcast stations, cable television providers or satellite television providers, or Internet-based television providers. For example, the television service provider site 406 may be configured to receive transmissions (including television programs) via satellite uplink / downlink. In addition, as Figure 4 As shown, television service provider site 406 may be in communication with wide area network 408 and may be configured to receive data from content provider sites 412A through 412N. It should be noted that in some examples, television service provider site 406 may include a television studio and the content may originate from the television studio.

[0599] The wide area network 408 may include a packet-based network and operate according to a combination of one or more telecommunication protocols. The telecommunication protocol may include proprietary aspects and / or may include standardized telecommunication protocols. Examples of standardized telecommunication protocols include 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 European Standard (EN), the IP standard, the Wireless Application Protocol (WAP) standard, and the Institute of Electrical and Electronics Engineers (IEEE) standard, such as one or more IEEE 802 standards (e.g., Wi-Fi). The wide area network 408 may include any combination of wireless and / or wired communication media. The wide area network 408 may include coaxial cables, fiber optic cables, twisted pair cables, Ethernet cables, 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. In one example, the wide area network 408 may include the Internet. The local area network 410 may include a packet-based network and operate according to a combination of one or more telecommunication protocols. The local area network 410 may be distinguished from the wide area network 408 based on access levels and / or physical infrastructure. For example, the local area network 410 may include a secure home network.

[0600] Reference again Figure 4, content 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 having one or more studio content servers, which are configured to provide multimedia files and / or streams to television service provider sites 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 a real-time streaming protocol (RTSP), HTTP, etc. In addition, content provider sites 412A to 412N may be configured to provide data including hypertext-based content, etc. to one or more of receiver devices 402A to 402N and / or 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 data provider sites 412A to 412N may be defined according to a data format.

[0601] Reference 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 operably coupled thereto. Video encoder 106 may include any device configured to receive video data and generate a compliant bitstream representing the video data. A compliant bitstream may refer to a bitstream from which a video decoder can receive and reproduce video data. Various aspects of a compliant bitstream may be defined according to a video coding standard. When generating a compliant bitstream, video encoder 106 may compress the video data. The compression may be lossy (perceptible or imperceptible to the viewer) or lossless. Figure 5 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 illustrated as having different functional blocks, such illustration is intended for descriptive purposes and does not limit the video encoder 500 and / or its subcomponents to a particular hardware or software architecture. The functionality of the video encoder 500 may be implemented using any combination of hardware, firmware, and / or software implementations.

[0602] The video encoder 500 can perform intra-frame prediction encoding and inter-frame prediction encoding of a picture region and thus can be referred to as a hybrid video encoder. Figure 5In the example shown, the video encoder 500 receives a source video block. In some examples, the source video block may include picture regions that have been divided according to a coding structure. For example, the source video data may include macroblocks, CTUs, CBs, sub-partitions thereof, and / or additional equivalent coding units. In some examples, the video encoder 500 may be configured to perform additional subdivisions of the source video block. It should be noted that the techniques described herein are generally applicable to video encoding regardless of how the source video data is divided before and / or during encoding. 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, video encoder 500 receives source video blocks and outputs a bitstream.

[0603] exist Figure 5 In the example shown, the video encoder 500 can generate residual data by subtracting the predicted video block from the source video block. The selection of the predicted video block is described in detail below. The summer 502 represents a component configured to perform the subtraction operation. In one example, the subtraction of the video block occurs in the pixel domain. The transform coefficient generator 504 applies a transform such as a discrete cosine transform (DCT), a discrete sine transform (DST), or a conceptually similar transform (for example, four 8×8 transforms can be applied to a 16×16 residual value array) to the residual block or its sub-partition to generate a residual transform coefficient set. The transform coefficient generator 504 can be configured to perform any and all combinations of transforms included in the discrete triangular transform series, including its approximation. 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 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 a quantization parameter (QP). The quantization parameter can be determined based on a slice level value and / or a CU level value (e.g., a CU delta QP value). The QP data may include any data used to determine the QP used to quantize a particular set of transform coefficients. Figure 5 As shown, the quantized transform coefficients (which may be referred to as level values) are output to the inverse quantization and transform coefficient processing unit 508. The inverse quantization and transform coefficient processing unit 508 may be configured to apply inverse quantization and inverse transformation to generate reconstructed residual data. Figure 5As shown, at the summer 510, the reconstructed residual data can be added to the predicted video block. In this way, the encoded video block can be reconstructed, and the resulting reconstructed video block can be used to evaluate the coding quality of a given prediction, transformation and / or quantization. The video encoder 500 can be configured to perform multiple encoding rounds (e.g., performing encoding while changing one or more of the prediction, transformation parameters and quantization parameters). The rate distortion or other system parameters of the bit stream can be optimized based on the evaluation of the reconstructed video block. In addition, the reconstructed video block can be stored and used as a reference for predicting subsequent blocks.

[0604] Reference again Figure 5 , the intra-frame prediction processing unit 512 may be configured to select an intra-frame prediction mode for a video block to be encoded. The intra-frame prediction processing unit 512 may be configured to evaluate a frame and determine an intra-frame prediction mode for encoding a current block. As described above, possible intra-frame 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 may be inferred based on the prediction mode of the luma prediction mode. The intra-frame prediction processing unit 512 may select an intra-frame prediction mode after performing one or more encoding rounds. Furthermore, in one example, the intra-frame prediction processing unit 512 may select a prediction mode based on a rate-distortion analysis. As Figure 5 As shown, the intra prediction processing unit 512 outputs intra prediction data (eg, syntax elements) to the entropy coding unit 518 and the transform coefficient generator 504. As described above, the transform performed on the residual data may be mode dependent (eg, a secondary transform matrix may be determined based on the prediction mode).

[0605] Reference again Figure 5 , the inter-frame prediction processing unit 514 may be configured to perform inter-frame prediction encoding for the current video block. The inter-frame prediction processing unit 514 may be configured to receive a source video block and calculate a motion vector of a PU of the video block. The motion vector may indicate the displacement of a PU of a video block within a current video frame relative to a prediction block within a reference frame. Inter-frame prediction encoding may use one or more reference pictures. In addition, motion prediction may be unidirectional prediction (using one motion vector) or bidirectional prediction (using two motion vectors). The inter-frame prediction processing unit 514 may be configured to select a prediction block by calculating a pixel difference determined by, for example, the sum of absolute differences (SAD), the sum of square differences (SSD), or other difference metrics. As described above, a motion vector may be determined and specified based on motion vector prediction. As described above, the inter-frame prediction processing unit 514 may be configured to perform motion vector prediction. The inter-frame prediction processing unit 514 may be configured to generate a prediction block using motion prediction data. For example, the inter-frame prediction processing unit 514 may locate a prediction video block within a frame buffer ( Figure 5). It should be noted that the inter-frame prediction processing unit 514 may be further configured to apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values ​​for motion estimation. The inter-frame prediction processing unit 514 may output the motion prediction data of the calculated motion vector to the entropy coding unit 518.

[0606] like Figure 5 As shown, filter unit 516 receives the reconstructed video blocks and encoding parameters and outputs modified reconstructed video data. Filter unit 516 may 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 reconstruction by adding an offset to the reconstructed video data. It should be noted that Figure 5 As shown, the intra prediction processing unit 512 and the inter prediction processing unit 514 may receive the modified reconstructed video block via the filter unit 516. The entropy coding unit 518 receives the quantized transform coefficients and the prediction syntax data (i.e., the intra prediction data and the motion prediction data). It should be noted that in some examples, the coefficient quantization unit 506 may 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 may perform the scan. The entropy coding unit 518 may be configured to perform entropy coding according to one or more of the techniques described herein. As such, the video encoder 500 represents an example of a device configured to generate encoded video data according to one or more techniques of the present disclosure.

[0607] Reference again Figure 1 , the data encapsulator 107 can receive the encoded video data and generate a compliant bitstream according to a defined data structure, for example, a sequence of NAL units. A device receiving the compliant bitstream can reproduce the video data therefrom. In addition, as described 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 the term compliant bitstream. In one example, the data encapsulator 107 can be configured to generate syntax according to one or more techniques described herein. It should be noted that the data encapsulator 107 does not necessarily have to be located in the same physical device as the video encoder 106. For example, the functions described as being performed by the video encoder 106 and the data encapsulator 107 can be distributed in Figure 4 in the device shown.

[0608] As described above, signaling metadata describing video coding attributes provided in JVET-O2001 is less than ideal. In one example, according to the techniques herein, one or more syntax elements currently signaled in a slice header may be signaled in an access unit delimiter. This may provide bit savings when a picture consists of multiple slices, which improves coding efficiency. Table 9 shows an exemplary syntax for an access unit delimiter, and Table 10 shows an exemplary syntax for a corresponding slice header according to an example of the techniques herein.

[0609]

[0610]

[0611]

[0612] With respect to Table 9, in one example, the semantics may be based on the following:

[0613] An access unit delimiter is used to indicate the start of an access unit and the types of slices in a coded picture present in the access unit containing the access unit delimiter NAL unit.

[0614] pic_type indicates that the slice_type values ​​of all slices of the coded pictures in the access unit containing the access unit delimiter NAL unit are the number of sets listed in Table 6 for a given value of pic_type. In bitstreams conforming to this version of this specification, the value of pic_type shall be equal to 0, 1, or 2. Other values ​​of pic_type are reserved for future use by ITU-T | ISO / IEC. Decoders conforming to this version of this specification shall ignore all reserved values ​​of pic_type.

[0615] pic_parameter_set_id specifies the value of pps_pic_parameter_set_id of the PPS in use. The value of pic_paranaeter_set_id shall be in the range of 0 to 63, inclusive. Bitstream conformance requires that the value of Temporand of the current picture shall be greater than or equal to the value of Temporand of the PPS with pps_pic_parameter_set_id equal to pic_parameter_set_id.

[0616] non_reference_picture_flag equal to 1 specifies that the picture must not be used as a reference picture. non_reference_picture_flag equal to 0 specifies that the picture may or may not be used as a reference picture.

[0617] When separate_colour_plane_flag is equal to 1, colour_plane_id specifies the colour plane associated with the current picture. The value of colour_plane_id shall be in the range 0 to 2, inclusive. colour_plane_id values ​​0, 1 and 2 correspond to the Y, Cb and Cr planes, respectively.

[0618] Note - There is no dependency between the decoding processes of pictures with different colour_plane_id values.

[0619] pic_order_cnt_lsb specifies the picture order count modulo MaxPicOrderCntLsb of the current picture. The length of the slice_pic_order_cnt_lsb syntax element is log2 max pic_order_cnt_lsb_minus4 + 4 bits. The value of slice_pic_order_cnt_lsb shall be in the range of 0 to MaxPicOrderCntLsb - 1, inclusive.

[0620] pic_output_flag affects the decoded picture output and removal process according to the specification. When pic_output_flag is not present, it is inferred to be equal to 1.

[0621] In another example, with respect to the access unit delimiter shown in Table 9, in one example, only some of the syntax elements shown in Table 9 may be signaled in the access unit delimiter. For example, in one example, only the syntax elements non_reference_picture_flag and pic_output_flag may be present in the access unit delimiter.

[0622] In another example, more syntax elements may be signaled in the access unit delimiter than shown in Table 9. For example, in one example, any syntax elements in the slice header that are the same for all slices of a picture may be signaled in the access unit delimiter.

[0623] Additionally, in one example, the relative order of syntax elements in an access unit delimiter may be different compared to that shown in Table 9. For example, in one example, pic_parameter_set_id may be the first syntax element signaled in an access unit delimiter.

[0624] With respect to Table 9, in one example, the semantics may be based on the semantics provided above with respect to Table 7.

[0625] Referring to Table 7 and Table 9, in one example, according to the techniques of this document, the syntax element slice_pic_order_cnt_lsb can be the first element in the slice header, that is, slice_pic_order_crut_lsb can be the syntax element immediately following "slice_header() {.". It should be noted that in IV-ET-02001, the syntax element slice_pic_order_cnt_lsb is signaled for all picture types including TDR pictures. In one example, according to the techniques of this document, an additional requirement may be that in one CVS, the PicOrderCntVal values ​​of any two coded pictures with the same nuh_layer_id value should not be the same. Furthermore, in one example, in this case, an additional requirement may be that when present, the value of slice_pic_order_cnt_lsb should be the same in all slice headers of a coded picture. It should be noted that moving slice_pic_order_cnt_lsb to the first element in the slice header and requiring slice_pic_order_cnt_lsb to be the same in all slice headers of a coded picture allows a video decoder to check and determine that a change in value compared to a previous slice indicates that the slice belongs to a new picture.

[0626] In another example, the syntax element slice_pic_order_ent_lsb may be signaled so that it appears in the slice header as an element after the slice_pic_parameter_set_id syntax element and before other syntax elements. In one example, this may be as shown in Table 10A below:

[0627]

[0628] In one example, the steps of detecting a new picture based on the syntax shown in Table 10A may be as follows:

[0629] - Parse the value of slice_pic_parameter_set_id. This can be ignored or used as follows: If it is a different value from the previous slice, then this is the first slice of the picture, since all slices of a picture must use the same PPS.

[0630] - Parse the value of slice_pic_order_cnt_lsb. If it is a different value from the previous slice, then this is the first slice of the picture, since all slices of a picture must have the same slice_pic_order_cnt_lsb value.

[0631] You can also use the following steps during the detection of new images:

[0632] - At the start of a coded video sequence (CVS), the SPS will be parsed and log2_max_pic_order_cnt_lsb_minus4 will be parsed. Then from this point on, since log2_max_pic_order_cnt_lsb_minus4 is the same for the entire CVS, parsing slice_pic_order_cnt_lsb can proceed without further checks and / or parsing slice_pic_parameter_set_id in every slice of that CVS.

[0633] In one example, according to the techniques of this article, a marker can be added to the SPS that specifies that each picture that references the SPS includes exactly one slice. In one example, the marker can be encoded as a u(1) syntax element. In one example, the semantics of the marker can be based on the following:

[0634] single_slice_in_pic_flag equal to 1 specifies that each picture referencing this SPS includes exactly one brick. single_brick_per_slice_flag equal to 0 specifies that pictures referencing this SPS may include more than one brick.

[0635] It should be noted that a picture can reference an SPS by referencing a PPS, and a PPS can reference an SPS.

[0636] With respect to Table 3, in one example, according to the techniques herein, single_slice_in_pic_flag may be immediately preceded by the syntax element pic_width_max_in_luma_samples. In one example, single_slice_in_pic_flag may be immediately followed by the syntax element pic_height_max_in_luma_samples. In another example, single_slice_in_pic_flag may be signaled at a different location in the SPS.

[0637] It should be noted that when single_slice_in_pic_flag or another flag or syntax element specifies that each picture referencing an SPS includes exactly one slice, the following requirements may be specified:

[0638] If single_slice_in_pic_flag is equal to 1 in the SPS of a picture reference of a CVS, all access units in the CVS consist of zero or one access unit delimiter NAL unit and one or more layer access units (in increasing order of nuh_layer_id).

[0639] Otherwise (single_slice_in_pic_flag is equal to 0), all access units in the CVS consist of one access unit delimiter NAL unit and one or more layer access units (in increasing order of nuh_layer_id).

[0640] Furthermore, in one example, single_slice_in_pic_flag is included in the SPS and precedes the syntax element subpics_present_flag, then the presence of subpics_present_flag may depend on the value of single_slice_in_pic_flag, so that when single_slice_in_pic_flag is equal to 1, it does not need to be signaled. This may be achieved, for example, using the following syntax, as follows:

[0641]

[0642] In the semantics of subpics_present_flag, the following may be added: When not present, the value of subpics_present_flag is inferred to be equal to 0.

[0643] Furthermore, when single_slice_in_pic_flag etc. is included in the SPS, in the slice header, when it is ensured that there is only one slice, there is no need to signal the slice address. That is, in one example, the presence of the syntax element slice_address can be adjusted as follows:

[0644]

[0645] It should be noted that regulating the presence of the syntax element slice_address on single_slice_in_pic_flag may result in bit savings and ensure that single_slice_in_pic_flag is not a non-normative syntax element.

[0646] Furthermore, in one example, when single_slice_in_pic_flag etc. is included in the SPS, in the slice header, the presence of the syntax element num_bricks_in_slice_minus1 may be conditioned and the value of the syntax element inferred based on single_slice_in_pic_flag. For example, num_bricks_in_slice_minus1 may be conditionally signaled as follows:

[0647]

[0648] The semantics are as follows:

[0649] num_bricks_in_slice_minus1, when present, specifies the number of bricks in the slice minus 1. The value of num_bricks_in_slice_minus1 shall be in the range of 0 to NumBricksInPic - 1, inclusive. When rect_slice_flag is equal to 0 and single_brick_per_slice_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to 0. When single_brick_per_slice_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to 0. When single_slice_in_pic_flag is equal to 1, the value of num_bricks_in_slice_minus1 is inferred to be equal to NumBricksInPic - 1.

[0650] It should be noted that, based on the value of single_slice_in_pic_flag being equal to 1, there may be other ways of describing and / or specifying the inference of the value of num_bricks_in_slice_minus1 being equal to NumBricksInPic - 1.

[0651] In addition, in one example, when single_slice_in_pic_flag, etc. are included in the SPS in the PPS, the presence of the syntax elements num_slices_in_pic_minus1, bottom_right_brick_idx_length_nainus1, bottom_right_brick_idx_deltan[i], brick_idx_delta_sign_flag[i] may be adjusted and the values ​​may be inferred based on single_slice_in_ouc_flag. For example, bottom_right_brick_idx_length_minus1, bottom_right_brick_iclx_deltafil, brick_idx_delta_sign_flag[i] may be conditionally signaled as follows:

[0652]

[0653] The following modifications are made to the semantics relative to the semantics provided above with respect to Table 4:

[0654] num_slices_in_pic_minus1 plus 1 specifies the number of slices in each picture that reference the PPS. The value of num_slices_in_pic_minus1 shall be in the range of 0 to NumBrickslnPic-1, inclusive. When not present and single_brick_per_slice_flag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to NumBrickslnPic-1.

[0655] When not present and single_slice_in_pic_flag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to 0.

[0656] It should be noted that there may be other syntax elements in the PPS, where the presence or derived values ​​of these other syntax elements depend on the value of single_slice_in_pic_flag.

[0657] In one example, a marker may be added to the PPS that specifies that each picture referencing the PPS includes exactly one slice. In one example, the marker may be encoded as a u(1) syntax element. In one example, the semantics of the marker may be based on the following:

[0658] single_slice_inpic_flag equal to 1 specifies that each picture referencing this PPS includes exactly one tile. single_slice_in_pic_flag equal to 0 specifies that pictures referencing this PPS may include more than one tile.

[0659] With respect to Table 4, in one example, in accordance with the techniques herein, single_slice_inpic_flag may be immediately preceded by the syntax element single_tide_in_pic_flag. In one example, single_slice_in_pic_flag may be immediately followed by the syntax element single_tile_in_pic_flag. It should be noted that when single_slice_in_pic_flag is included in a PPS, a conformance constraint may be defined such that the same single_slice_inpic_flag value is provided for all PPSs in a CVS. Since it is not possible to encode multiple sub-pictures without also being able to encode multiple slices, in one example, it is also proposed to signal subpic_present_flag only when single_slice_in_pic_flag is equal to 0.

[0660]

[0661] Referring to Table 9, in one example, according to the techniques of this document, access_unit_delimiter_rbsp() may include a syntax element that specifies the value of vps_video_parameter_set_id of the VPS referenced by the access unit delimiter. Table 11 shows an example of access_unit_delimiter_rbsp() including a syntax element that specifies the value of vps_video_parameter_set_id of the VPS referenced by the access unit delimiter.

[0662]

[0663] With respect to Table 11, the semantics may be based on the semantics provided above with respect to Table 9, where the semantics of the syntax element aud_video_parameter_set_id is based on the following:

[0664] aud_video_parameter_set_id specifies the value of vps_video_parameter_set_id of the VPS referenced by the access unit delimiter when greater than 0. When aud_video_parameter_set_id is equal to 0, the access unit delimiter does not reference a VPS, and the VPS is not referenced when decoding a slice. The value of aud_video_parameter_set_id shall be equal to the value of sps_video_parameter_set_id in the SPS with sps_decoding_parameter_set_id equal to pps_seq_parameter_set_id for each slice of the VCL NAL units in the access unit.

[0665] Alternatively, in one example, only syntax elements that are common to all VCL NAL units of an access unit may be moved to the access unit delimiter. This may for example include syntax elements: pic_order_cnt_lsb, colour_plane_id, non_reference_picture_flag. In this case, the check iflvps_max_layers_minus1=0 || aud_video_parameter_set_id == 0) is not performed.

[0666] In one example, according to the techniques herein, the order of NATs, units, and coded pictures and their association with layer access units and access units may be based on the following:

[0667] A layer access unit consists of one coded picture and zero or more non-VCL NAL units. An access unit consists of an access unit delimiter NAL unit and one or more layer access units (in increasing order of nuh_layer_id).

[0668] The access unit delimiter NAL unit shall have the nuh_layer_id value equal to vps_layer_id[ 0 ].

[0669] In another example: an access unit delimiter NAL unit shall have nuh_layer_id value equal to 0.

[0670] The access unit delimiter NAL unit shall have a TemporalId equal to the TemporalId of the layer access unit with nuh_layer_id equal to vps_layer_id[ 0 ].

[0671] In another example, an access unit delimiter NAL unit should have a TemporalId equal to the TemporalId of the access unit containing the NAL unit.

[0672] Additionally, in one example, the TemporalId of an access unit may be defined as one of the following options:

[0673] 1. Bitstream conformance may require that the TemporalId of an access unit be the same for all VCL NAL units of an access unit. The value of the TemporalId of a coded picture or access unit is the value of the TemporalId of the VCL NAL unit of the coded picture or access unit.

[0674] 2. Allow different TemporalIds to be used for different layer access unit VCL NAL units. Define the minimum or maximum TemporalId value of the VCL NAL unit of a layer access unit as the value of the TemporalId of the access unit.

[0675] The first access unit in the bitstream starts with the first NAL unit of the bitstream. Each access unit starts with an access unit delimiter NAL unit. There shall be at most one access unit delimiter NAL unit in any access unit.

[0676] The order of coded pictures and non-VCL NAL units within a layer access unit or access unit shall obey the following constraints:

[0677] - When any DPS NAL units, VPS NAL units, SPS NAL units, PPS NAL units, APS NAL units, prefix SET NAL units, NAL units with a nal_unit_type in the range of RSV_NVCL_25 .. RSV_NVCL_26, or NAL units with a nal_unit_type in the range of UNSPEC28 .. UNSPEC29 are present in a layer access unit, they shall not follow the last VCL NAL unit of the layer access unit.

[0678] - In a layer access unit, a NAL unit with nal_unit_type equal to SUFFIX_SET_NUT or RSV_NVCL_27 or in the range of UNSPEC30..UNSPEC31 shall not precede the first VCL NAL unit of the layer access unit.

[0679] - When an end of sequence NAL unit is present in an access unit, this unit shall be the last NAL unit among all NAL units within the access unit except the end of bitstream NAL unit (when present).

[0680] - When the end of a bitstream NAL unit is present in an access unit, this unit shall be the last NAL unit in the access unit.

[0681] Referring to Table 10, in one example, according to the techniques herein, slice_header() may conditionally signal syntax elements based on vps_max_layers_minus1. Table 12 shows an example of a slice_header() syntax structure that conditionally signals syntax elements based on vps_max_layers_minus1.

[0682]

[0683]

[0684] In one example, the condition if(vps_max_layers_minus1>0) in Table 12 above may be replaced by:

[0685] if(vps_max_layers_minus1>0 && aud_video_parameter_set_id !=0)

[0686] In one example, a syntax element may be included in an access unit delimiter syntax structure and may be introduced in the access unit delimiter, the syntax element specifying whether certain syntax elements are present in the access unit delimiter syntax structure or in the slice header syntax structure. Tables 13 and 14 show examples of access unit delimiter syntax structures and corresponding slice header syntax structures, wherein the syntax element au_lpicture_header_flag specifies whether certain syntax elements are present in the access unit delimiter syntax structure or in the slice header syntax structure.

[0687]

[0688]

[0689]

[0690] With respect to Table 13 and Table 14, the semantics may be based on the semantics provided above, where the semantics of the syntax element aud_picture_header_flag is based on the following:

[0691] aud_picture_header_flag equal to 1 specifies that pic_paramter_set_id, non_reference_picture_flag, colour_plane_id, pic_order_count_lsb, and pic_output_flag are present in the access unit delimiter (AUD). aud_picture_header_flag_equal equal to 0 specifies that these syntax elements are present in the slice header of the picture.

[0692] In one example, it may be desirable to require aud_picture_header_flag to be equal to 0 when vps_max_layers_minus1 is greater than 0.

[0693] In another example:

[0694] aud_picture_heacler_flag equal to 1 specifies that pic_paramter_set_id, non_reference_picture_flag, colour_plane_id (when separate_colour_plane_flag is equal to 1), pic_order_count_lsb, and pic_output_flag (when output_flag_present_flag is equal to 1) are present in the AUD. aud_picture_header_flag equal to 0 specifies that these syntax elements are present in the slice header of the picture.

[0695] In another example, a syntax structure called pic_header0 may be signaled. The syntax structure may only include syntax elements that need to have the same value in all slices of a picture. In one example, pic_header() may have the following syntax in Table 15 and semantics.

[0696]

[0697] When the pic_header0 syntax structure is present in the access unit delimiter, the term current picture refers to the picture in the access unit with nuh_layer_id equal to vps_layer_id[ 0 ]. When the pic_header() syntax structure is present in the slice header, the term current picture refers to the picture of which the current slice is a part. ph_pic_parameter_set_id specifies the value of pps_pic_parameter_set_id of the PPS of the slice of the current picture. The value of slice_ph_pic_parameter_set_id shall be in the range of 0 to 63, inclusive.

[0698] Bitstream conformance requires that the value of TemporalId of the current picture shall be greater than or equal to the value of TemporalId of the PPS with pps_pic_parameter_set_id equal to slice_pic_parameter_set_id. non_reference_picture_flag equal to 1 specifies that the current picture must not be used as a reference picture. non_reference_picture_flag equal to 0 specifies that the current picture may or may not be used as a reference picture.

[0699] When separate_colour_plane_flag is equal to 1, colour_plane_id specifies the colour plane associated with the current picture. The value of colour_plane_id shall be in the range 0 to 2, inclusive. colour_plane_id values ​​0, 1 and 2 correspond to the Y, Cb and Cr planes, respectively.

[0700] Note - There is no dependency between the decoding processes of pictures with different colour_plane_id values.

[0701] ph_pic_order_cnt_lsb specifies the picture order count modulo MaxPicOrderCntLsb of the current picture. The length of the slice_pic_order_cnt_lsb syntax element is log2_max_pic_order_cnt_lsb_minus4+4 bits. The value of ph_pic_order_cnt_lsb shall be in the range of 0 to MaxPicOrderCntLsb - 1, inclusive.

[0702] pic_output_flag affects the decoded picture output and removal process according to the specification. When pic_output_flag is not present, it is inferred to be equal to 1.

[0703] In another example, the syntax element aud_pic_header_flag may be added to the AUD NAL unit syntax structure, as provided in Table 16 below. When aud_pic_header_flag is equal to 1, the pic_header() syntax structure is present in the AUD NAL unit (and not present in the slice header of the picture).

[0704]

[0705] In one example, the following semantics may be used for the syntax element aud_pic_header_flag.

[0706] auci_pic_header_flag equal to 1 specifies that the pic_header() syntax structure is present in the AUD. aud_pic_header_flag equal to 0 specifies that the pic_header() syntax structure is present in all slice headers in the access unit. The value of aud_pic_header_flag is inferred to be equal to 0 when no AUD NAL unit is present in the access unit.

[0707] The slice header may be modified as provided in Table 17:

[0708]

[0709] In one example, it may be desirable to require aud_picture_header_flag to be equal to 0 when vps_max_layers_minus1 is greater than 0.

[0710] In this manner, source device 102 represents an example of a device configured to: signal a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally signal one or more syntax elements in a slice header based on the value of the flag.

[0711] Reference again Figure 1, interface 108 may include any device configured to receive data generated by data encapsulator 107 and transmit and / or store the data to a communication medium. Interface 108 may include a network interface card such as an Ethernet card, and may include an optical transceiver, a radio frequency transceiver, or any other type of device that can send and / or receive information. In addition, interface 108 may include a computer system interface that enables files to be stored on a storage device. For example, interface 108 may include support for peripheral component interconnect (PCI) and high-speed peripheral component interconnect (PCIe) bus protocols, proprietary bus protocols, universal serial bus (USB) protocols, I 2 C's chipset, or any other logical and physical structure that can be used to interconnect peer devices.

[0712] Reference again Figure 1 , target device 120 includes interface 122, data decapsulator 123, video decoder 124, and 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, a radio frequency transceiver, or any other type of device that can receive and / or send information. In addition, interface 122 may include a computer system interface that allows retrieval of a compliant video bitstream from a storage device. For example, interface 122 may include a computer system that supports PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, I 2 The data decapsulator 123 may be configured to receive and parse any of the example grammatical structures described herein.

[0713] Video decoder 124 may include any device configured to receive a bitstream (e.g., sub-bitstream extraction) and / or acceptable variants 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, the video decoder 124 is described as outputting data to a display 126, but the video decoder 124 can be configured to output video data to various types of devices and / or subcomponents thereof. For example, the video decoder 124 can be configured to output video data to any communication medium, as described herein.

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

[0715] exist Figure 6 In the example shown, the video decoder 600 includes an entropy decoding unit 602, an inverse quantization unit 604, an inverse transform coefficient processing unit 606, an intra-frame prediction processing unit 608, an inter-frame prediction processing unit 610, a summer 612, a post-filter unit 614, and a reference buffer 616. The video decoder 600 can be configured to decode video data in a manner consistent with a video encoding system. 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 subcomponents to a specific hardware or software architecture. The functionality of the video decoder 600 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0716] like Figure 6 As shown, the entropy decoding unit 602 receives an entropy-encoded bitstream. The entropy decoding unit 602 may be configured to decode syntax elements and quantized coefficients from the bitstream according to a process that is inverse to the entropy encoding process. The entropy decoding unit 602 may be configured to perform entropy decoding according to any of the entropy encoding techniques described above. The entropy decoding unit 602 may determine the values ​​of syntax elements in the encoded bitstream in a manner consistent with the video coding standard. Figure 6 As shown, the entropy decoding unit 602 can determine the quantization parameter, the quantization coefficient value, the transformation data and the prediction data from the bit stream. Figure 6 As shown, the inverse quantization unit 604 and the inverse transform coefficient processing unit 606 receive the quantization parameters, quantization coefficient values, transform data and prediction data from the entropy decoding unit 602, and output reconstructed residual data.

[0717] See again Figure 6, the reconstructed residual data may be provided to the summer 612. The summer 612 may add the reconstructed residual data to the predicted video block and generate the reconstructed video data. The predicted video block may be determined according to a predictive video technique, namely intra prediction and inter prediction. The intra prediction processing unit 608 may be configured to receive an intra prediction syntax element and retrieve the predicted video block from a reference buffer 616. The reference buffer 616 may include a memory device configured to store one or more frames of video data. The intra prediction syntax element may identify an intra prediction mode, such as the intra prediction mode described above. The inter prediction processing unit 610 may receive the inter prediction syntax element and generate a motion vector to identify a predicted block in one or more reference frames stored in the reference buffer 616. The inter prediction processing unit 610 may generate a motion compensated block, possibly performing interpolation based on an interpolation filter. An identifier of an interpolation filter for motion estimation with sub-pixel precision may be included in the syntax element. The inter prediction processing unit 610 may use an interpolation filter to calculate interpolated values ​​of sub-integer pixels of a reference block. The post filter unit 614 may be configured to perform filtering on the reconstructed video data. For example, the post filter unit 614 may 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 may be configured to perform dedicated arbitrary filtering (e.g., visual enhancement, such as mosquito noise removal). Figure 6 As shown, the video decoder 600 can output a reconstructed video block. In this way, the video decoder 600 represents an example of a device configured to: parse a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally parse one or more syntax elements in a slice header based on the value of the flag.

[0718] In one or more examples, the functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or codes on or transmitted via a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or propagation media including any medium that facilitates the transmission of a computer program from one place to another, for example, according to a communication protocol. Thus, computer-readable media 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. The 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, codes, and / or data structures for implementing the techniques described in the present disclosure. A computer program product may include a computer-readable medium.

[0719] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, flash memory, or any other medium that can be used to store the required program code in the form of instructions or data structures and can be accessed by a computer. Moreover, any connection is appropriately referred to as a computer-readable medium. For example, if a coaxial cable, optical fiber cable, twisted pair, digital subscriber line (DSL) or wireless technology such as infrared, radio and microwave is used to transmit instructions from a website, server or other remote source, then the coaxial cable, optical fiber cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals or other transient media, but are directed to non-transient tangible storage media. As used herein, disks and optical disks include compact disks (CDs), laser disks, optical optical disks, digital versatile disks (DVDs), floppy disks and Blu-ray disks, wherein disks usually copy data magnetically, while optical disks use lasers to copy data optically. The above combination should also be included in the scope of computer-readable media.

[0720] Instructions may 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 logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein may refer to any of the aforementioned structures or any other structure suitable for implementing the techniques described herein. In addition, in some aspects, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a combined codec. Moreover, these techniques may be implemented entirely in one or more circuits or logic elements.

[0721] The techniques of the present disclosure may be implemented in a variety of devices or apparatuses, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chipset). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed techniques, but do not necessarily need to be implemented by different hardware units. Instead, as described above, the various units may be combined in a codec hardware unit, or provided by a collection of interoperating hardware units including one or more processors as described above, in combination with appropriate software and / or firmware.

[0722] In addition, each functional block or various features of the base station equipment and terminal equipment used in each of the above embodiments can be implemented or executed by a circuit (usually an integrated circuit or multiple integrated circuits). The circuit designed to perform the functions described in this specification may include a general-purpose processor, a digital signal processor (DSP), a dedicated or general-purpose integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device or a discrete hardware component or a combination thereof. The general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, a controller, a microcontroller or a state machine. The general-purpose processor or each of the above circuits may be configured by a digital circuit, or may be configured by an analog circuit. In addition, when a technology for making an integrated circuit that replaces the current integrated circuit appears due to advances in semiconductor technology, the integrated circuit produced by the technology can also be used.

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

[0724] <Overview>

[0725] In one example, a method for signaling picture information is provided, the method comprising: signaling a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally signaling one or more syntax elements in a slice header based on the value of the flag.

[0726] In one example, a method for decoding picture information for decoding video data is provided, the method comprising: parsing a flag in a sequence parameter set, the flag having a value indicating whether each picture referencing the sequence parameter set includes exactly one slice; and conditionally parsing one or more syntax elements in a slice header based on the value of the flag.

[0727] In one example, the method is provided wherein the one or more syntax elements in the slice header include a syntax element indicating a slice address.

[0728] In one example, the method is provided wherein the one or more syntax elements in the slice header include a syntax element indicating a number of tiles in a slice.

[0729] In one example, the method is provided wherein the syntax element having a value specifying a picture order count is the first syntax element in the slice header.

[0730] In one example, an apparatus is provided that includes one or more processors configured to perform any and all combinations of the steps.

[0731] In one example, the apparatus is provided, wherein the apparatus comprises a video encoder.

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

[0733] In one example, a system is provided that includes: a device that includes a video encoder; and the device that includes a video decoder.

[0734] In one example, an apparatus is provided, comprising: means for performing any and all combinations of the steps.

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

[0736] In one example, a method for decoding picture information for decoding video data is provided, the method comprising: receiving a slice header syntax structure; determining whether the slice header syntax structure includes a picture header syntax structure; and if the slice header syntax structure includes the picture header syntax structure, parsing a first syntax element specifying a picture parameter set identifier from the picture header syntax structure, and parsing a second syntax element specifying a picture sequence count from the picture header syntax structure.

[0737] In one example, the method is provided, where, when the slice header syntax structure includes the picture header syntax structure, a third syntax element specifying whether the current picture is a reference picture is further parsed from the picture header syntax structure.

[0738] In one example, a method is provided, which, when the slice header syntax structure includes the picture header syntax structure, further determines whether the picture header syntax structure includes a picture output marker syntax element, and when the picture header syntax structure includes the picture output marker syntax element, parses the picture output marker syntax element from the picture header syntax structure.

[0739] In one example, the method is provided wherein determining whether the picture header syntax structure includes the picture output flag syntax element is based on a value of a current flag.

[0740] In one example, the method is provided wherein determining whether the slice header syntax structure includes the picture header syntax structure is based on a value of a flag.

[0741] In one example, a device is provided that includes one or more processors configured to: receive a slice header syntax structure; determine whether the slice header syntax structure includes a picture header syntax structure; and if the slice header syntax structure includes the picture header syntax structure, parse a first syntax element specifying a picture parameter set identifier from the picture header syntax structure, and parse a second syntax element specifying a picture sequence count from the picture header syntax structure.

[0742] In one example, the device is provided, where the slice header syntax structure includes the picture header syntax structure, wherein the one or more processors are further configured to parse a third syntax element specifying whether the current picture is a reference picture from the picture header syntax structure.

[0743] In one example, the device is provided, wherein the one or more processors are further configured to: determine whether the picture header syntax structure includes a picture output marker syntax element when the slice header syntax structure includes the picture header syntax structure; and parse the picture output marker syntax element from the picture header syntax structure when the picture header syntax structure includes the picture output marker syntax element.

[0744] In one example, the apparatus is provided wherein the one or more processors determine whether the picture header syntax structure includes the picture output flag syntax element based on a value of a current flag.

[0745] In one example, the apparatus is provided wherein the one or more processors determine whether the slice header syntax structure includes the picture header syntax structure based on a value of a flag.

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

[0747] <Cross Reference>

[0748] This nonprovisional patent application claims priority under 35 U.S.C. § 119 to provisional application 62 / 890,523, filed on August 22, 2019, and provisional application 62 / 905,307, filed on September 24, 2019, the entire contents of which are hereby incorporated by reference.

Claims

1. A device comprising one or more processors, wherein the one or more processors are configured to: receiving a picture header syntax structure, wherein the picture header syntax structure is conditionally included in a slice header syntax structure based on a value of a first flag; in, The picture header syntax structure includes: The first syntax element specifies the value of the picture parameter set identifier of the picture parameter set in use. The second syntax element specifies whether the current picture has never been used as a reference picture. A third syntax element specifies the least significant bit information of the picture sequence count of the current picture, and A fourth syntax element affects a decoded picture output and removal process based on a value of a second flag specifying the presence of the fourth syntax element.

2. A device comprising one or more processors, wherein the one or more processors are configured to: generating a picture header syntax structure, wherein the picture header syntax structure is conditionally included in a slice header syntax structure based on a value of a first flag; in, The picture header syntax structure includes: The first syntax element specifies the value of the picture parameter set identifier of the picture parameter set in use. The second syntax element specifies whether the current picture has never been used as a reference picture. A third syntax element specifies the least significant bit information of the picture sequence count of the current picture, and A fourth syntax element affects a decoded picture output and removal process based on a value of a second flag specifying the presence of the fourth syntax element.

3. A non-transitory computer readable medium storing a program that causes a processor to perform the following operations: receiving a picture header syntax structure, wherein the picture header syntax structure is conditionally included in a slice header syntax structure based on a value of a first flag; in, The picture header syntax structure includes: The first syntax element specifies the value of the picture parameter set identifier of the picture parameter set in use. The second syntax element specifies whether the current picture has never been used as a reference picture. A third syntax element specifies the least significant bit information of the picture sequence count of the current picture, and A fourth syntax element affects a decoded picture output and removal process based on a value of a second flag specifying the presence of the fourth syntax element. The device of claim 1 , wherein the device is a video decoder.

5. The device of claim 2, wherein the device is a video encoder.

Images