System and method for signaling parameter in video coding

Abstract

To provide a method for signaling a tile set parameter of a coding video.SOLUTION: In a method for signaling a tile setting parameter, a value of a syntax element is signaled in a network abstraction layer (NAL) unit, and indicates that a tile set layer syntax structure is contained in the NAL unit. The method is for signaling a value of one or more tile set parameter contained in the tile set layer syntax structure.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] TECHNICAL FIELD This disclosure relates to video coding, and more specifically, to techniques for signaling tile set parameters for coded video. [Background technology]

[0002] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, laptop or desktop computers, tablet computers, digital recording devices, digital media players, video gaming devices, cellular telephones, including so-called smartphones, medical imaging devices, and the like. Digital video can be encoded according to a video encoding standard. The video encoding standard can incorporate video compression techniques. Examples of video encoding 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), Rec. 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-T H.265 are currently under consideration for the development of the next generation video encoding standard. For example, the ITU-T Video Coding Experts Group (VCEG) and ISO / IEC (Moving Picture Experts Group (MPEG), collectively referred to as the Joint Video Exploration Team (JVET), are considering the potential need for standardization of future video coding technologies with compression capabilities significantly exceeding those of the current HEVC standard. The Joint Exploration Model 7 (JEM 7), Algorithm Description of Joint Exploration Test Model 7 (JEM 7), ISO / IEC JTC1 / SC29 / WG11 Document: JVET-G1001, July 2017, Torino, IT, describes coding features under collaborative test model study by JVET as having the potential to improve video coding technology beyond the capabilities of ITU-T H.265, and is incorporated herein by reference. It is 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 contained in JEM 7 and the implementation of the JEM reference software. Additionally, in response to the "Joint Call for Proposals on Video Compression with Capabilities beyond HEVC" jointly issued by VCEG and MPEG, multiple descriptions of video coding have been proposed by various groups at the 10th Meeting of ISO / IEC JTC1 / SC29 / WG11 16-20 April 2018, San Diego, CA. As a result of the multiple descriptions of video coding, a draft text of a video coding specification was described in "Versatile Video Coding (Draft 1)," 10th Meeting of ISO / IEC JTC1 / SC29 / WG11 16-20 April 2018, San Diego, CA, document JVET-J1001-v2, which is incorporated herein by reference and referred to as JVET-J1001. “Versatile Video Coding (Draft 2),” 11th Meeting of ISO / IEC JTC1 / SC29 / WG11 10-18 July 2018, Ljubljana, SI, document JVET-K1001-v5, which is incorporated by reference herein and referred to as JVET-K1001, is an updated version of JVET-J1001.

[0003] Video compression techniques reduce data requirements for storing and transmitting video data by exploiting inherent redundancy in a video sequence. Video compression techniques may subdivide a video sequence into successively smaller portions (i.e., groups of frames within a video sequence, frames within groups of frames, slices within frames, coding tree units (e.g., macroblocks) within slices, coding blocks within coding tree units, etc.). Intra-prediction coding techniques (e.g., within a picture (spatial)) and inter-prediction techniques (i.e., between pictures (temporal)) may be used to generate difference values ​​between a unit of video data to be coded and a reference unit of video data. The difference values ​​may be referred to as residual data. The residual data may be coded as quantized transform coefficients. Syntax elements may associate the residual data with the reference coding units (e.g., intra-prediction mode index, motion vectors, and block vectors). The residual data and syntax elements may be entropy coded. The entropy coded residual data and syntax elements may be included in a compliant bitstream. The compliant bitstream and associated metadata may be formatted according to a data structure. Summary of the Invention

[0004] In one embodiment, a method for signaling slice parameters includes signaling a value for a syntax element of a network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit; signaling a presence flag in a slice parameter structure included in the slice layer syntax structure; determining, based on the presence flag, whether one of one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header; and when the one of the one or more slice parameters is determined based on the slice layer syntax structure, determining a value included in the slice layer syntax structure for the one of the one or more slice parameters, wherein the one or more slice parameters is collocated_from_10_flag, and when a value of nal_unit_type indicates that a picture layer syntax structure picture header is present, a plurality of syntax elements of the picture header are present, and when a value of nal_unit_type indicates that a picture parameter set is present, a plurality of syntax elements of the picture parameter set are present.

[0005] In one embodiment, a method for decoding video data includes parsing a value for a syntax element of a network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit; parsing a presence flag in a slice parameter structure included in the slice layer syntax structure; determining whether one of one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header based on the presence flag; when the one of the one or more slice parameters is determined based on the slice layer syntax structure, determining a value included in the slice layer syntax structure for the one or more slice parameters; and generating video data based on the determined value for the one of the one or more slice parameters, wherein the one or more slice parameters is collocated_from_10_flag, and when a value of a picture layer syntax structure nal_unit_type indicates that a picture layer syntax structure picture header is present, a plurality of syntax elements of the picture header are present, and when a value of the nal_unit_type indicates that a picture parameter set is present, a plurality of syntax elements of the picture parameter set are present.

[0006] In one embodiment, a device for encoding video data includes one or more processors and one or more non-transitory computer-readable storage media coupled to the one or more processors, the non-transitory computer-readable storage media being configured to, when executed by at least one of the one or more processors, signal to the device a value for a syntax element of a network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit, signal a presence flag in a slice parameter structure included in the slice layer syntax structure, and determine, based on the presence flag, whether one of one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header. and when the one of the one or more slice parameters is determined based on the slice layer syntax structure, determining a value included in the slice layer syntax structure for the one of the one or more slice parameters, wherein the one or more slice parameters is collocated_from_10_flag, and when a value of nal_unit_type indicates that a picture layer syntax structure picture header is present, multiple syntax elements of the picture header are present, and when a value of nal_unit_type indicates that a picture parameter set is present, multiple syntax elements of the picture parameter set are present.

[0007] In one embodiment, a device for decoding video data includes one or more processors and one or more non-transitory computer-readable storage media coupled to the one or more processors, the one or more processors being configured to, when executed by at least one of the one or more processors, cause the device to: parse values ​​for syntax elements of a network abstraction layer unit, the syntax elements indicating that a slice layer syntax structure is included in the network abstraction layer unit; parse a presence flag in a slice parameter structure included in the slice layer syntax structure; determine, based on the presence flag, whether one of one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header; and determine whether one of the one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header. determining values ​​included in the slice layer syntax structure for the one or more slice parameters when the one of is determined based on the slice layer syntax structure; and generating video data based on the determined values ​​for the one of the one or more slice parameters, wherein the one or more slice parameters is collocated_from_10_flag, and when a value of nal_unit_type indicates that a picture layer syntax structure picture header is present, multiple syntax elements of the picture header are present, and when the value of nal_unit_type indicates that a picture parameter set is present, multiple syntax elements of the picture parameter set are present. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a block diagram illustrating an example of a system that can be configured to encode and decode video data in accordance with one or more techniques of this disclosure. [Diagram 2] FIG. 2 is a conceptual diagram illustrating encoded video data and corresponding data structures in accordance with one or more techniques of this disclosure. [Diagram 3]FIG. 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. [Figure 4] FIG. 4 is a conceptual diagram illustrating one 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. [Diagram 5] FIG. 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. [Figure 6] FIG. 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. [Figure 7] FIG. 7 is a conceptual diagram illustrating encoded video data and corresponding data structures in accordance with one or more techniques of this disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Generally, this disclosure describes various techniques for encoding video data. Specifically, this disclosure describes techniques for signaling tile set parameters for encoded video. Signaling tile set parameters according to the techniques described herein may be particularly useful for improving video distribution system performance by reducing transmission bandwidth and / or facilitating parallelization of video encoders and / or decoders. It should be noted that although the techniques of this disclosure are described with respect to ITU-T H.264, ITU-T H.265, JVET-J1001, and JVET-K1001, the techniques of this disclosure are generally applicable to video coding. For example, the encoding techniques described herein can be incorporated into video coding systems (including video coding systems based on future video coding standards) that include block structures, intra-prediction techniques, inter-prediction techniques, transform techniques, filtering techniques, and / or entropy coding techniques other than those included in ITU-T H.265. Thus, references to ITU-T H.264, ITU-T H.265, JVET-J1001, and JVET-K1001 are for illustrative purposes and should not be construed to limit the scope of the technology described herein. Furthermore, it should be noted that the incorporation by reference of a document herein should not be construed to be limiting or to create ambiguity with respect to the terms used herein. For example, if an incorporated reference provides a definition of a term that differs from that of another incorporated reference, and / or if that term is used herein, then that term should be construed to broadly include each corresponding definition and / or to include each specific definition instead.

[0010] In one embodiment, the device includes one or more processors configured to signal values ​​for syntax elements in the network abstraction layer unit indicating that a tile set layer syntax structure is included in the network abstraction layer unit, and to signal values ​​for one or more tile set parameters included in the tile set layer syntax structure.

[0011] In one embodiment, a non-transitory computer-readable storage medium includes instructions recorded thereon that, when executed, cause one or more processors of the device to signal a value for a syntax element in a network abstraction layer unit indicating that a tile set layer syntax structure is included in the network abstraction layer unit, and to signal a value for one or more tile set parameters included in the tile set layer syntax structure.

[0012] In one embodiment, the apparatus includes means for signaling a value for a syntax element in the network abstraction layer unit indicating that a tile set layer syntax structure is included in the network abstraction layer unit, and means for signaling a value for one or more tile set parameters included in the tile set layer syntax structure.

[0013] In one embodiment, the device includes one or more processors configured to parse values ​​for syntax elements in the network abstraction layer unit that indicate that a tile set layer syntax structure is included in the network abstraction layer unit, parse values ​​for one or more tile set parameters included in the tile set layer syntax structure, and generate video data based on the parsed values ​​for the one or more tile set parameters.

[0014] In one embodiment, a non-transitory computer-readable storage medium includes instructions recorded thereon that, when executed, cause one or more processors of the device to parse values ​​for syntax elements in a network abstraction layer unit that indicates that a tile set layer syntax structure is included in the network abstraction layer unit, parse values ​​for one or more tile set parameters included in the tile set layer syntax structure, and generate video data based on the parsed values ​​for the one or more tile set parameters.

[0015] In one embodiment, the apparatus includes means for parsing values ​​for syntax elements in a network abstraction layer unit indicating that a tile set layer syntax structure is included in the network abstraction layer unit, means for parsing values ​​for one or more tile set parameters included in the tile set layer syntax structure, and means for generating video data based on the parsed values ​​for the one or more tile set parameters.

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

[0017] Video content typically includes video sequences that consist of a series of frames. A series of frames may also be referred to as a group of pictures (GOP). Each video frame or picture may include one or more slices, which in turn include multiple video blocks. A video block includes an array of pixel values ​​(sometimes called samples) that may be predictively coded. The video blocks may be ordered according to a scan pattern (e.g., raster scan). A video encoder performs predictive coding on the video blocks and their subdivisions. ITU-T H.264 specifies macroblocks that include 16x16 luma samples. ITU-T H.265 specifies a similar Coding Tree Unit (CTU) structure (which may also be referred to as Largest Coding Unit (LCU)), but a picture may be divided into equal-sized CTUs, where each CTU may include a Coding Tree Block (CTB) with 16x16, 32x32, or 64x64 luma samples. As used herein, the term video block may generally refer to a region of a picture, or more specifically, to a maximal array of pixel values ​​that can be predictively coded, its subdivisions, and / or corresponding structures. Furthermore, according to ITU-T H.265, each video frame or picture may be partitioned to contain one or more tiles, where a tile is a sequence of coding tree units that corresponds to a rectangular region of the picture.

[0018] In ITU-T H.265, a CTU is composed of a respective CTB for each component of video data (e.g., luma (Y) and chroma (Cb and Cr)). Furthermore, in ITU-T H.265, a CTU may be divided according to a quad-tree (QT) division structure, so that the CTBs of a CTU are divided into coding blocks (CBs). That is, in ITU-T H.265, a CTU may be divided into quad-tree leaf nodes. According to ITU-T H.265, one luma CB, together with two corresponding chroma CBs and related syntax elements, is called a coding unit (CU). In ITU-T H.265, the minimum allowed size of a CB may be signaled. In ITU-T H.265, the smallest minimum allowed size of a luma CB is 8x8 luma samples. In ITU-T H.265, the decision to code a picture region using intra prediction or inter prediction is made at the CU level.

[0019] In ITU-T H.265, a CU is associated with a prediction unit (PU) structure with root in the CU. In ITU-T H.265, the PU structure allows for splitting the luma CB and chroma CB for the purpose of generating corresponding reference samples. That is, in ITU-T H.265, the luma CB and chroma CB can be split into respective luma and chroma prediction blocks (PBs), where a PB includes a block of sample values ​​to which the same prediction is applied. In ITU-T H.265, the CB can be split into 1, 2, or 4 PBs. ITU-T H.265 supports PB sizes from 64×64 samples 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 divided into 4 square PBs (i.e., intra prediction PB size types include M×M or M / 2×M / 2, where M is the height and width of the square CB). In addition to square PBs, ITU-T H.265 supports rectangular PBs for inter prediction, where the CB can be bisected vertically or horizontally to form the PBs (i.e., inter prediction PB types include M×M, M / 2×M / 2, M / 2×M, or M×M / 2). It should be noted that ITU-T H.265 also supports four asymmetric PB divisions for inter prediction, where the CB is divided into two PBs at a quarter of the height (at the top or bottom) or width (at the left or right) of the CB (i.e., asymmetric divisions include M / 4×M left, M / 4×M right, M×M / 4 top, and M×M / 4 bottom). Using intra prediction data (e.g., intra prediction mode syntax element) or inter prediction data (e.g., motion data syntax element) corresponding to the PB, reference sample values ​​and / or predicted sample values ​​for the PB are generated.

[0020] JEM specifies a CTU with a maximum size of 256x256 luma samples. JEM specifies a quad-tree plus binary tree (QTBT) block structure. In JEM, the QTBT structure allows a quad-tree leaf node to be further split by a binary tree structure (BT). That is, in JEM, the binary tree structure allows a quad-tree leaf node to be split vertically or horizontally recursively. Thus, the binary tree structure in JEM allows square leaf nodes and rectangular leaf nodes, each of which contains one CB. As shown in FIG. 2, a picture included in a GOP may contain multiple slices, each slice containing a sequence of CTUs, and each CTU may be split according to the QTBT structure. In JEM, the CB is used in prediction without any additional splitting. That is, in JEM, the CB may be a block of sample values ​​to which the same prediction is applied. Thus, the JEM QTBT leaf node may be similar to the PB in ITU-T H.265.

[0021] Intra prediction data (e.g., intra prediction mode syntax element) or inter prediction data (e.g., motion data syntax element) can relate the PU to a corresponding reference sample. The residual data can include a respective array of difference values ​​corresponding to each component of the video data (e.g., luma (Y) and chroma (Cb and Cr)). The residual data can 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, can be applied to the pixel difference values ​​to generate transform coefficients. It should be noted that in ITU-T H.265, a CU can be further subdivided into transform units (TUs). That is, the array of pixel difference values ​​may be subdivided to generate transform coefficients (e.g., four 8×8 transforms may be applied to a 16×16 array of residual values ​​corresponding to a 16×16 luma CB), and such a subdivision may be referred to as a Transform Block (TB). The transform coefficients may be quantized according to a quantization parameter (QP). The quantized transform coefficients (which may be referred to as level values) may be entropy coded according to an entropy coding technique (e.g., content adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), probability interval partitioning entropy coding (PIPE), etc.). Furthermore, syntax elements, such as syntax elements indicating prediction modes, may also be entropy coded. The entropy coded and quantized transform coefficients and the corresponding entropy coded syntax elements may form a compliant bitstream that can be used to regenerate video data.A binarization process can be performed on syntax elements as part of the entropy encoding process. Binarization refers to the process of converting syntax values ​​into a series of one or more bits. These bits are sometimes called "bins."

[0022] As mentioned above, intra prediction data or inter prediction data is used to generate reference sample values ​​for a block of sample values. The difference between a sample value included in the current PB or another type of picture region structure and an associated reference sample (e.g., a reference sample generated using prediction) may be referred to as residual data. As mentioned above, intra prediction data or inter prediction data may associate a region of a picture (e.g., a PB or a CB) with a corresponding reference sample. For intra prediction coding, an intra prediction mode may specify the location of the reference sample within the picture. In ITU-T H.265, the defined possible intra prediction modes include a planar (i.e., surface-fit) prediction mode (predMode:0), a DC (i.e., flat global averaging) prediction mode (predMode:1), and a 33-angle prediction mode (predMode:2-34). In JEM, the defined possible intra prediction modes include a planar prediction mode (predMode:0), a DC prediction mode (predMode:1), and a 65-angle prediction mode (predMode:2-66). It should be noted that the planar and DC prediction modes may be referred to as non-directional prediction modes, and the angular prediction modes may be referred to as directional prediction modes. It should be noted that the techniques described herein may be generally applicable regardless of the number of possible prediction modes defined.

[0023] For inter-predictive coding, a motion vector (MV) identifies reference samples in pictures other than the picture of the video block to be coded, thereby exploiting temporal redundancy in the video. For example, a current video block may be predicted from a reference block(s) located in a previously coded frame(s), and a motion vector may be used to indicate the location of the reference block. The motion vector and associated data may describe, for example, a horizontal component of the motion vector, a vertical component of the motion vector, a resolution for the motion vector (e.g., quarter-pixel accuracy, half-pixel accuracy, full pixel accuracy, double pixel accuracy, four pixel accuracy), a prediction direction, and / or a reference picture index value. Additionally, coding standards, such as, for example, ITU-T H.265, may support motion vector prediction. Motion vector prediction allows a motion vector to be specified using the motion vectors of neighboring blocks. Examples of motion vector prediction include advanced motion vector prediction (AMVP), temporal motion vector prediction (TMVP), the so-called "combined" mode, as well as "skip" and "direct" motion estimation. In addition, JEM supports advanced temporal motion vector prediction (ATMVP), spatial-temporal motion vector prediction (STMVP), a special merge mode based on frame rate up-conversion (FRUC) technology, the pattern match motion vector derivation (PMMVD) mode, and affine transform motion compensation prediction.

[0024] The residual data may include respective arrays of difference values ​​corresponding to respective components 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 array of difference values ​​to generate transform coefficients. In ITU-T H.265, a CU is associated with a transform unit (TU) structure with its root at the CU level. That is, in ITU-T H.265, an array of difference values ​​may be subdivided (e.g., four 8×8 transforms may be applied to a 16×16 array of residual values) for the purpose of generating transform coefficients, as described above. It should be noted that ITU-T H.265 does not necessarily require the TB to be aligned to the PB.

[0025] Note that in JEM, the residual values ​​corresponding to CB are used to generate transform coefficients without further division. That is, in JEM, the QTBT leaf node can be similar to both PB and TB in ITU-T H.265. In JEM, a core transform and a subsequent secondary transform can be applied (at the video encoder) to generate transform coefficients. For the video decoder, the order of transforms is reversed. Furthermore, in JEM, whether or not a secondary transform is applied to generate transform coefficients can depend on the prediction mode.

[0026] A quantization process may be performed on the transform coefficients. Quantization approximates the transform coefficients with amplitudes limited to a particular set of values. Quantization may be used to vary the amount of data required to represent a group of transform coefficients. Quantization may be achieved by division of the transform coefficients by a scaling factor and any associated rounding function (e.g., rounding to the nearest integer). The quantized transform coefficients may be referred to as coefficient level values. Inverse quantization (or "dequantization") may include multiplication of coefficient level values ​​by a scaling factor. It should be noted that as used herein, the term quantization process may refer in some cases to division by a scaling factor to generate level values, or in some cases to multiplication by a scaling factor to recover the transform coefficients. That is, the quantization process may refer in some cases to quantization and in some cases to inverse quantization.

[0027] For the formulas used herein, the following arithmetic operators may be used:

[0028] [Table 1] In addition, the following mathematical functions can be used:

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

[0030]

number

[0031] With respect to the example syntax used herein, the following definitions of logical operators may apply:

[0032] x&&y The Boolean logic "product" of x and y x||y The Boolean "union" of x and y ! Boolean logic "no" x?y:zIf x is true or not equal to 0, then evaluate the value of y, else evaluate the value of z.

[0033] In addition, the following relational operators may be applied:

[0034] [Table 2] Furthermore, in the syntax descriptors used herein, it should be noted that the following descriptors may apply:

[0035] -b(8): A byte (8 bits) containing a bit string of arbitrary pattern. The parsing process of this descriptor is specified by the return value of the function read_bit(8).

[0036] -f(n): a fixed pattern bit string with n bits written left bit first (left to right). The parsing process of this descriptor is specified by the return value of the function read_bit(n).

[0037] -u(n): An unsigned integer using n bits.

[0038] -ue(v): An unsigned integer zeroth order Exp-Golomb encoding syntax element, left bit first.

[0039] As mentioned above, according to ITU-T H.265, each video frame or picture may be partitioned to include one or more slices, and may further be partitioned to include one or more tiles. FIG. 2 is a conceptual diagram illustrating an example of a group of pictures including slices. In the example illustrated in FIG. 2, Pic4 is illustrated as including two slices (i.e., Slice1 and Slice2), each slice including a sequence of CTUs (e.g., in raster scan order). Note that a slice is a sequence of one or more slice segments starting with an independent slice segment and including all subsequent dependent slice segments (if any), where all subsequent dependent slice segments are followed by the next independent slice segment (if any) within the same access unit. A slice segment, like a slice, is a sequence of coding tree units. In the embodiments described herein, in some cases, the terms slice and slice segment may be used interchangeably to indicate a sequence of coding tree units. It should be noted that in ITU-T H.265, a tile may consist of coding tree units contained in more than one slice, and a slice may consist of coding tree units contained in more than one tile. However, ITU-T H.265 specifies that one or both of the following conditions must be met: (1) all coding tree units in a slice belong to the same tile, and (2) all coding tree units in a tile belong to the same slice. Tile sets can be used to define boundaries for coding dependencies (e.g., intra-prediction dependencies, entropy coding dependencies, etc.), which can enable parallelism in coding.

[0040] In ITU-T H.265, a coded video sequence (CVS) may be encapsulated (or structured) as a sequence of access units, each of which contains video data structured as a network abstraction layer (NAL) unit. In ITU-T H.265, a bitstream is described as containing a sequence of NAL units forming one or more CVSs. It is noted that ITU-T H.265 supports multi-layer extensions, including format range extension (RExt), scalability (SHVC), multi-view (MV-HEVC), and 3-D (3D-HEVC). Multi-layer extensions allow a video representation to include a base layer and one or more additional enhancement layers. For example, a base layer may enable the provision of a video representation having a basic level of quality (e.g., high-resolution rendering), and an enhancement layer may enable the provision of a video representation having an enhanced level of quality (e.g., ultra-high-resolution rendering). In ITU-T H.265, an enhancement layer may be encoded by reference to the base layer. That is, for example, a picture in an enhancement layer may be coded (e.g., using inter prediction techniques) by referencing one or more pictures in the base layer (including scaled versions thereof). In ITU-T H.265, each NAL unit may include an identifier indicating the layer of video data with which the NAL unit is associated. Note that sub-bitstream extraction may refer to a process in which a device receiving a compliant bitstream forms a new compliant bitstream by discarding and / or modifying data in the received bitstream. For example, sub-bitstream extraction may be used to form a new compliant bitstream that corresponds to a particular representation of the video (e.g., a higher quality representation).

[0041] With reference to the example shown in FIG. 2, each slice of video data contained in Pic4 (i.e., Slice1 and Slice2) is shown as being encapsulated in a NAL unit. In ITU-T H.265, each of the video sequences, GOPs, pictures, slices, and CTUs may be associated with metadata that describes video coding characteristics. ITU-T H.265 defines parameter sets that may be used to describe video data characteristics and / or video coding characteristics. In ITU-T H.265, the parameter sets may be encapsulated as special types of NAL units or signaled as messages. NAL units that contain coded video data (e.g., slices) may be referred to as VCL (Video Coding Layer) NAL units, and NAL units that contain metadata (e.g., parameter sets) may be referred to as non-VCL NAL units. In addition, ITU-T H.265 allows supplemental enhancement information (SEI) messages to be signaled. In ITU-T H.265, SEI messages aid in processes related to decoding, display, or other purposes, but may not be required for the decoding process to create luma or chroma samples. In ITU-T H.265, SEI messages may be signaled in the bitstream using non-VCL NAL units. Furthermore, SEI messages may be conveyed by some means other than by being present in the bitstream (i.e., signaled out-of-band).

[0042] Figure 3 shows an example of a bitstream containing multiple CVSs, which are represented by NAL units contained in the respective access units. In the embodiment illustrated in Figure 3, the non-VCL NAL units include respective parameter set units (i.e., video parameter set (VPS), sequence parameter set (SPS), and picture parameter set (PPS) units) and an access unit delimiter NAL unit. ITU-T H.265 defines NAL unit header semantics that specify the type of raw byte sequence payload (RBSP) data structure contained in the NAL unit.

[0043] Table 1 shows the syntax of common NAL units provided in ITU-T H.265 and further used in JVET-K1001.

[0044] [Table 3] ITU-T H.265 provides the following general NAL unit semantics:

[0045] NumBytesInNalUnit specifies the size of a NAL unit in bytes. This value is required for decoding of the NAL unit. To allow inference of NumBytesInNalUnit, some form of demarcation of NAL unit boundaries is required. One such demarcation method is specified in [ITU-T H.265 Annex B] for byte stream formats. Other methods of demarcation may be specified outside this specification.

[0046] NOTE 1 – The Video Coding Layer (VCL) is specified to efficiently represent the content of video data. The NAL is specified to format that data and provide header information in a manner suitable for transport over various communication channels or storage media. All data is contained in NAL units, each of which contains an integer number of bytes. The NAL unit specifies a general format for use in both packet-oriented and bitstream systems. The format of the NAL unit for both packet-oriented transport and byte stream is identical, except that each NAL unit may be preceded by a start code prefix and additional padding bytes in the byte stream format specified in [ITU-T H.265 Annex B].

[0047] rbsp_byte[i] is the i-th byte of the RBSP. The RBSP is specified as an ordered sequence of bytes as follows:

[0048] The RBSP contains a string of data bits (SODB) as follows:

[0049] - If the SODB is empty (i.e., zero bit length), then the RBSP is also empty.

[0050] - Otherwise, the RBSP contains the SODB as follows:

[0051] 1) The first byte of RBSP contains the (most significant, left-most) 8 bits of SODB, the next byte of RBSP contains the next 8 bits of SODB, and so on until less than 8 bits of SODB remain.

[0052] 2) rbsp_trailing_bits() exists after SODB as follows:

[0053] i) The first (most significant, left-most) bit of the final RBSP byte contains the remaining bits of the SODB (if any).

[0054] ii) The next bits consist of a single rbsp_stop_one_bit equal to 1.

[0055] iii) If the rbsp_stop_one_bit is not the last bit of a byte-aligned byte, then one or more rbsp_alignment_zero_bits must be present to provide byte alignment.

[0056] 3) One or more cabac_zero_word 16-bit syntax elements equal to 0x0000 may be present in the last RBSP, in some RBSP after the rbsp_trailig_bits().

[0057] Syntax structures that have these RSP properties are indicated in the syntax tables using the "_rbsp" suffix. These structures are carried within NAL units as the content of rbsp_byte[i] data bytes. The association of RBSP syntax structures with NAL units is as described in [Table 3 herein].

[0058] NOTE 2 - If the RBSP boundaries are known, a decoder can extract the SODB from the RBSP by concatenating the bits of the bytes of the RBSP, discarding the last (least significant, right-most) bit, rbsp_stop_one_bit, that is equal to 1, and discarding any subsequent (more significant, further right) bits that are equal to 0. The data required for the decoding process is contained in the SODB portion of the RBSP.

[0059] emulation_prevention_three_byte is a byte equal to 0x03. If emulation_prevention_three_byte is present in a NAL unit, it shall be discarded by the decoding process.

[0060] The last byte of a NAL unit shall not be equal to 0x00.

[0061] Within a NAL unit, the following three-byte sequence does not occur in any byte-aligned position:

[0062] -0x000000 -0x000001 -0x000002 Within a NAL unit, any 4-byte sequence starting with 0x000003 cannot occur in any byte-aligned position, other than the following sequences:

[0063] -0x00000300 -0x00000301 -0x00000302 -0x00000303 Table 2 shows the NAL unit header syntax defined in ITU-T H.265.

[0064] [Table 4] ITU-T H.265 specifies the following definitions for each syntax element shown in Table 2.

[0065] forbidden_zero_bit shall be equal to 0.

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

[0067] nuh_temporal_id_plus1-1 specifies a temporal identifier for the NAL unit. The value of nuh_temporal_id_plus1 must not be equal to 0.

[0068] nal_unit_type, nal_unit_type specifies the type of RBSP data structure included in the NAL unit. Table 3 shows the NAL unit types specified in ITU-T H.265.

[0069] [Table 5] For the sake of brevity, a complete description of each of the NAL unit types in ITU-T H.265 is not provided herein, however, reference is made to the relevant sections of ITU-T H.265.

[0070] As mentioned above, JVET-K1001 is a draft text of a video coding specification. Table 4 shows the syntax of the NAL unit header in JVET-K1001.

[0071] [Table 6] JVET-K1001 specifies the following definitions for each syntax element shown in Table 4.

[0072] forbidden_zero_bit shall be equal to 0.

[0073] Regarding nal_unit_type, JVET-K1001 provides a place where NAL unit types have yet to be defined.

[0074] JVET-K1001 further provides a basic sequence parameter set syntax. Table 5 shows the syntax of the sequence parameter set provided in JVET-K1001.

[0075] [Table 7] The basic definition of each syntax element shown in Table 5 is as follows:

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

[0077] Chroma_format_idc specifies the chroma sampling relative to the luma sampling. The value of Chroma_format_idc shall be in the range 0 to 3, inclusive.

[0078] separate_colour_plane_flag equal to 1 specifies that the three colour components of the 4:4:4 chroma format are coded separately, while separate_colour_plane_flag equal to 0 specifies that the colour components are not coded separately. If 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 colour components, each consisting of coded samples of one colour plane (Y, Cb or Cr), and uses the monochrome coding syntax. In this case, each colour plane is associated with a specific colour_plane_id value.

[0079] pic_width_in_luma_samples specifies the width of each decoded picture in units of luma samples.

[0080] pic_height_in_luma_samples specifies the height of each decoded picture in units of luma samples.

[0081] bit_depth_luma_minus8 specifies the bit depth of the samples in the luma array and the value of the luma quantization parameter range offset.

[0082] bit_depth_chroma_minus8 specifies the bit depth of the samples in the chroma array and the value of the chroma quantization parameter range offset.

[0083] qtbtt_dual_tree_intra_flag equal to 1 specifies that for I slices, each CTU is divided into coding units with 64x64 luma samples using an implicit quadtree partition, and these coding units are the root of a quadtree syntax structure that is two separate codings for luma and chroma.

[0084] log2_ctu_size_minus2+2 specifies the luma coding tree block size of each CTU.

[0085] log2_min_qt_size_in_slices_minus2+2 specifies the minimum luma size of a leaf block resulting from a quad-tree partitioning of a CTU in a slice with slice_type equal to 2(I).

[0086] log2_min_qt_size_inter_slices_minus2+2 specifies the minimum luma size of a leaf block resulting from a quad-tree partitioning of a CTU within a slice with slice_type equal to 0 (B) or 1 (P).

[0087] max_mtt_hierarchy_depth_inter_slices specifies the maximum hierarchical depth of coding units resulting from a multi-type tree split of quad-tree leaves within a slice with slice_type equal to 0 (B) or 1 (P).

[0088] max_mtt_hierarchy_depth_intra_slices specifies the maximum hierarchical depth of coding units resulting from a multi-type tree split of quad-tree leaves within a slice with slice_type equal to 2(I).

[0089] sps_cclm_enabled_flag equal to 0 specifies that cross-component linear model intra prediction from luma to chroma components is disabled. sps_cclm_enabled_flag equal to 1 specifies that cross-component linear model intra prediction from luma to chroma components is enabled.

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

[0091] sps_sbtmvp_enabled_flag equal to 1 specifies that sub-block based temporal motion vector predictors may be used in decoding pictures with all slices having slice_type type not equal to I in the CVS. sps_sbtmvp_enabled_flag equal to 0 specifies that sub-block based temporal motion vector predictors are not used in the CVS. If sps_sbtmvp_enabled_flag is not present, it is inferred to be equal to 0.

[0092] log2_sbtmvp_default_size_minus2 specifies the estimated value of the syntax element log2_sbtmvp_active_size_minus2 in the slice header of slices with slice_type not equal to I in the CVS when slice_sbtmvp_size_override_flag is equal to 0.

[0093] sps_amvr_enabled_flag equal to 1 specifies that adaptive motion vector differential resolution is used in motion vector encoding. amvr_enabled_flag equal to 0 specifies that adaptive motion vector differential resolution is not used in motion vector encoding.

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

[0095] sps_affine_type_flag specifies whether 6-parameter affine model-based motion compensation can be used for inter prediction. If sps_affine_type_flag is equal to 0, the syntax shall be constrained such that 6-parameter affine model-based motion compensation 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), 6-parameter affine model-based motion compensation can be used in the CVS. If not present, the value of sps_affine_type_flag is inferred to be equal to 0.

[0096] sps_mts_intra_enabled_flag equal to 1 specifies that eu_mts_flag may be present in the remaining coding syntax for an intra-coded unit. sps_mts_intra_enabled_flag equal to 0 specifies that cu_mts_flag is not present in the remaining coding syntax for an intra-coded unit.

[0097] sps_mts_inter_enabled_flag specifies that cu_mts_flag may be present in the remaining coding syntax for an inter coding unit. sps_mts_inter_enabled_flag equal to 0 specifies that it is not present in the remaining coding syntax for an inter coding unit.

[0098] JVET-K1001 further provides a basic picture parameter set syntax. Table 6 shows the picture parameter set syntax of JVET-K1001.

[0099] [Table 8] JVET-K1001 specifies the following definitions for each syntax element shown in Table 6.

[0100] pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id shall be in the range 0 to 63, inclusive.

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

[0102] transform_skip_enabled_flag equal to 1 specifies that transform_skip_flag may be present in the remaining coding syntax. transform_skip_flag equal to 0 specifies that transform_skip_flag is not present in the remaining coding syntax.

[0103] JVET-K1001 further provides an access unit delimiter syntax. Table 7 shows the syntax of the access unit delimiter in JVET-K1001.

[0104] [Table 9] JVET-K1001 specifies the following definitions for each syntax element shown in Table 7.

[0105] pic_type indicates that the values ​​of slice_type for all slices of coded pictures in the access unit containing the access unit delimiter NAL unit are members of the set listed in Table 8 for a given value of pic_type. Values ​​of pic_type shall be equal to 0, 1, or 2 in bitstreams conforming to this version of this specification. Other values ​​of pic_type are reserved for future use. Decoders conforming to this version of this specification shall ignore reserved values ​​of pic_type.

[0106] [Table 10] Note that a B slice refers to a slice for which bi-predictive inter-prediction, uni-predictive inter-prediction, and intra-prediction are allowed, a P slice refers to a slice for which uni-predictive inter-prediction and intra-prediction are allowed, and an I slice refers to a slice for which only intra-prediction is allowed. Note that in some cases, B slices and P slices are collectively referred to as inter slices.

[0107] JVET-K1001 further provides an end of sequence syntax, an end of bitstream syntax, and a filler data syntax. Table 9 shows the end of sequence syntax provided in JVET-K1001, Table 10 shows the end of bitstream syntax provided in JVET-K1001, and Table 11 shows the end of bitstream syntax provided in JVET-K1001. [Table 11] [Table 12]

[0108] [Table 13] JVET-K1001 specifies the following definitions for each syntax element shown in Table 11.

[0109] ff_byte is a byte equal to 0xFF.

[0110] JVET-K1001 further provides a syntax for slice layers including a slice header. Table 12 shows the syntax for slice layers provided in JVET-JK001, and Table 13 shows the slice header provided in JVET-K1001. [Table 14]

[0111] [Table 15] JVET-K1001 specifies the following definitions for each syntax element shown in Table 13.

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

[0113] slice_address defines the address of the first CTB in a slice in a CTB raster scan of a picture.

[0114] slice_type specifies the coding type of the slice according to Table 14.

[0115] [Table 16] If nal_unit_type has a value inclusive of the two ends of the range [to be determined], i.e. the picture is an IRAP picture, slice_type shall be equal to 2.

[0116] log2_diff_ctu_max_bt_size specifies the difference between the luma CTB size and the maximum luma size (width or height) of a coding block that can be split using binary splitting.

[0117] sbtmvp_size_override_flag equal to 1 specifies that the syntax element log2_sbtmvp_active_size_minus2 is present for the current slice. sbtmvp_size_override_flag equal to 0 specifies that the syntax element log2_atmvp_active_size_minus2 is not present and log2_sbtmvp_size_active_minus2 is inferred to be equal to log2_sbtmvp_default_size_minus2.

[0118] log2_sbtmvp_active_size_minus2+2 specifies the value of the sub-block size used to derive the sub-block-based TMVP motion parameters for the current slice. If log2_sbtmvp_size_active_minus2 is not present, it is inferred to be equal to log2_sbtmvp_default_size_minus2. The variable is derived as follows:

[0119]

number

[0120] mvd_l1_zero_flag equal to 1 indicates that the mvd_coding(x0,y0,1) syntax structure is not parsed and MvdL1[x0][y0][compIdx] is set equal to 0, for compIdx=0 to 1. mvd_l1_zero_flag equal to 0 indicates that the mvd_coding(x0,y0,1) syntax structure is parsed.

[0121] collocated_from_10_flag equal to 1 specifies that the collocated picture used for temporal motion vector prediction is derived from reference picture list 0. collocated_from_10_flag equal to 0 specifies that the collocated picture used for temporal motion vector prediction is derived from reference picture list 1. If collocated_from_10_flag is not present, it is inferred to be equal to 1.

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

[0123]

number

[0124] dep_quant_enabled_flag equal to 0 specifies that dependent quantization is disabled. dep_quant_enabled_flag equal to 1 specifies that dependent quantization is enabled.

[0125] 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. If sign_data_hiding_enabled_flag is not present, it is inferred to be equal to 0.

[0126] JVET-K1001 further provides an RBSP tail bit syntax and a byte alignment syntax. Table 15 shows the RBSP tail bit syntax provided in JVET-K1001, and Table 16 shows the byte alignment syntax provided in JVET-K1001. [Table 17]

[0127] [Table 18] As mentioned above, according to ITU-T H.265, each video frame or picture may be partitioned to contain one or more tiles. In ITU-T H.265, the tile structure of a picture is signaled using a picture parameter set. Table 17 is a part of the syntax of the PPS specified in ITU-T H.265 that includes relevant syntax elements for signaling the tile structure.

[0128] [Table 19] ITU-T H.265 specifies the following definitions for each syntax element shown in Table 17.

[0129] A tiles_enabled_flag equal to 1 specifies that one or more tiles are present in each picture that references the PPS. A tiles_enabled_flag equal to 0 specifies that only one tile is present in each picture that references the PPS. It is a requirement of bitstream conformance that the value of tiles_enabled_flag be the same for all PPSs activated in the CVS.

[0130] num_tile_columns_minus1+1 specifies the number of tile columns the picture is partitioned into. num_tile_columns_minus1 ranges from 0 to PicWidthlnCtbsY-1, inclusive. If not present, the value of num_tile_columns_minus1 is inferred to be equal to 0.

[0131] num_tile_rows_minus1+1 specifies the number of rows of tiles that partition the picture. num_tile_rows_minus1 shall be in the range of 0 to PicHeightlnCtbsY-1, inclusive. If not present, the value of num_tile_rows_minus1 is inferred to be equal to 0. If tiles_enabled_flag is equal to 1, then num_tile_columns_minus1 and num_tile_rows_minus1 shall both be equal to 0.

[0132] uniform_spacing_flag equal to 1 specifies that tile column borders, and similarly tile row borders, are uniformly distributed across the entire picture. uniform_spacing_flag equal to 0 specifies that tile column borders, and similarly tile row borders, are not uniformly distributed across the entire picture, but are explicitly signaled using the syntax elements column_width_minus1[i] and row_height_minus1[i]. If not present, the value of uniform_spacing_flag is inferred to be equal to 1.

[0133] column_width_minus1[i]+1 specifies the width of the i-th tile column in units of coding tree blocks.

[0134] row_height_minus1[i]+1 specifies the height of the i-th tile row in units of coding tree blocks.

[0135] As mentioned above, JVET-K1001 does not provide a mechanism for signaling tile structure. This disclosure describes techniques for signaling the overall bitstream structure, including picture headers and tile set parameters.

[0136] FIG. 1 is a block diagram illustrating an example of a system that may be configured to encode (encode and / or decode) video image 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. As shown in FIG. 1, system 100 includes a source device 102, a communication medium 110, and a destination device 120. In the example shown in FIG. 1, source device 102 may include any device configured to encode video data and transmit the encoded video data to communication medium 110. Destination 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 destination 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, gaming consoles, medical imaging devices, and mobile devices including, for example, smartphones, cellular phones, personal gaming devices.

[0137] 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 equipment that may be useful for facilitating 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 enable access to the World Wide Web, e.g., the Internet. The network may operate according to a combination of one or more telecommunications protocols. The telecommunications protocols may include proprietary aspects and / or standardized telecommunications protocols. Examples of standardized telecommunications protocols include Digital Video Broadcasting (DVB) standards, Advanced Television Systems Committee (ATSC) standards, Integrated Services Digital Broadcasting (ISDB) standards, Data Over Cable Service Interface Specification (DOCSIS) standards, Global System Mobile Communications (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.

[0138] 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 a form of electrically programmable memory (EPROM) or electrically erasable and programmable memory (EEPROM). The storage device(s) may include memory cards (e.g., Secure Digital (SD) memory cards), internal / external hard disk drives, and / or internal / external solid state drives. Data may be stored on the storage device according to a defined file format.

[0139] FIG. 4 is a conceptual diagram illustrating an example of components that may be included in one implementation of system 100. In the exemplary implementation shown in FIG. 4, 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. The implementation shown in FIG. 4 represents an example of a system that may be configured to enable digital media content, such as movies, live sporting events, and data and applications and their associated media presentations, to be distributed to and accessed by multiple computing devices, such as computing devices 402A-402N. In the example shown in FIG. 4, computing devices 402A-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, the computing devices 402A-402N may be equipped for wired and / or wireless communication 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. Additionally, the computing devices 402A-402N may include desktop, laptop, or tablet computers, gaming consoles, mobile devices, including, for example, "smart" phones, cellular phones, and personal gaming devices.

[0140] Television service network 404 is an example of a network configured to enable delivery of digital media content, which may include television services. For example, television service network 404 may include a public terrestrial television network, a public or subscription-based satellite television service provider network, and a public or subscription-based cable television provider network and / or an over the top service provider or an Internet service provider. It should be noted that, in some embodiments, television service network 404 may be primarily used to enable the provision of television services, but television service network 404 may also enable the provision of other types of data and services based on any combination of telecommunication protocols described herein. Furthermore, it should be noted that in some embodiments, television service network 404 may enable bidirectional communication between television service provider site 406 and one or more of computing devices 402A-402N. Television service network 404 may include any combination of wireless communication media 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 equipment that may be useful for facilitating communication between various devices and sites. The television service network 404 may operate according to a combination of one or more telecommunications protocols. The telecommunications protocols may include proprietary aspects and / or standardized telecommunications protocols. Examples of standardized telecommunications 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.

[0141] Referring again to FIG. 4, the television service provider site 406 can be configured to distribute television services over the television service network 404. For example, the television service provider site 406 can 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 can be configured to receive transmissions including television programs over satellite uplinks / downlinks. Additionally, as shown in FIG. 4, the television service provider site 406 can be in communication with a wide area network 408 and can be configured to receive data from content provider sites 412A-412N. It should be noted that in some implementations, the television service provider site 406 can include a television studio from which content can originate.

[0142] The wide area network 408 may include a packet-based network and may operate according to a combination of one or more telecommunications protocols. The telecommunications protocols may include proprietary aspects and / or standardized telecommunications protocols. Examples of standardized telecommunications protocols include Global System Mobile Communications (GSM) standards, code division multiple access (CDMA) standards, 3rd Generation Partnership Project (3GPP) standards, European Telecommunications Standards Institute (ETSI) standards, European Standards (EN), IP standards, Wireless Application Protocol (WAP) standards, and Institute of Electrical and Electronics Engineers (IEEE) standards, such as, for example, one or more of the IEEE 802 standards (e.g., Wi-Fi). The wide area network 408 may include any combination of wireless communication media 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 equipment that may be useful for facilitating communication between various devices and sites. In one embodiment, 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 telecommunications protocols. The local area network 410 may be distinguished from the wide area network 408 based on the level of access and / or physical infrastructure. For example, the local area network 410 may include a secure home network.

[0143] Referring again to FIG. 4, the content provider sites 412A-412N represent examples of sites that may provide multimedia content to the television service provider site 406 and / or the computing devices 402A-402N. For example, the content provider sites may include a studio having one or more studio content servers configured to provide multimedia files and / or streams to the television service provider site 406. In one embodiment, the content provider sites 412A-412N may be configured to provide multimedia content using an IP suite. For example, the content provider sites may be configured to provide multimedia content to receiving devices according to the Real Time Streaming Protocol (RTSP), HTTP, or the like. Additionally, the content provider sites 412A-412N may be configured to provide data, including hypertext-based content, or the like, over the wide area network 408 to one or more of the receiving devices, the computing devices 402A-402N, and / or the television service provider site 406. The content provider sites 412A-412N may include one or more web servers. The data provided by the data provider sites 412A-412N may be defined according to a data format.

[0144] Referring again to FIG. 1, source device 102 includes video source 104, video encoder 106, data encapsulator 107, and 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 video camera and a storage device operatively 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 that a video decoder can receive and from which to regenerate the video data.

[0145] Aspects of the compliant bitstream may be defined according to a video encoding standard. When generating a compliant bitstream, the video encoder 106 may compress the video data. The compression may be lossy (perceptible or imperceptible to a viewer) or lossless. FIG. 5 is a block diagram illustrating an example video encoder 500 that may implement techniques for encoding video data described herein. It should be noted that while the example video encoder 500 is shown having separate functional blocks, such illustration is for illustrative 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 realized using any combination of hardware, firmware, and / or software implementations.

[0146] The video encoder 500 may perform intra-prediction and inter-prediction coding of picture regions, and may therefore be referred to as a hybrid video encoder. In the example shown in FIG. 5, the video encoder 500 receives a source video block. In some examples, the source video block may include a portion of a picture that is partitioned according to a coding structure. For example, the source video data may include a macroblock, a CTU, a CB, a subdivision thereof, and / or another equivalent coding unit. In some examples, the video encoder 500 may be configured to perform additional subdivision of the source video block. It should be noted that the techniques described herein are generally applicable to video coding, regardless of how the source video data is partitioned before and / or during encoding. In the example shown in FIG. 5, the video encoder 500 includes an adder 502, a transform coefficient generator 504, a coefficient quantizer 506, an inverse quantization and transform coefficient processor 508, an adder 510, an intra-prediction processor 512, an inter-prediction processor 514, a filter unit 516, and an entropy encoder 518. As shown in FIG. 5, a video encoder 500 receives source video blocks and outputs a bitstream.

[0147] In the example shown in FIG. 5, the video encoder 500 may generate residual data by subtracting a predictive video block from a source video block. Selection of the predictive video block is described in more detail below. The adder 502 represents a component configured to perform this subtraction operation. In one example, the subtraction of the video blocks is performed 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, to the residual block or a subdivision thereof (e.g., four 8×8 transforms may be applied to a 16×16 array of residual values) to generate a set of residual transform coefficients. The transform coefficient generator 504 may be configured to perform any and all combinations of transforms included in the family of discrete triangular transforms, including approximations of the discrete triangular transform. The transform coefficient generator 504 may output the transform coefficients to a coefficient quantizer 506. The coefficient quantizer 506 may be configured to perform quantization of the transform coefficients. The quantization process may reduce the bit depth associated with some or all of the coefficients. The degree of quantization may change the rate distortion (i.e., video bit rate vs. quality) of the encoded video data. The degree of quantization may be modified by adjusting a quantization parameter (QP). The quantization parameter may be determined based on slice level values ​​and / or CU level values ​​(e.g., CU delta QP value). The QP data may include any data used to determine a QP for quantizing a particular set of transform coefficients. As shown in FIG. 5, the quantized transform coefficients (which may also be referred to as level values) are output to an 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 transform to generate reconstructed residual data. As shown in FIG. 5, the reconstructed residual data may be added to a prediction video block at an adder 510. In this manner, the encoded video block may be reconstructed, and the resulting reconstructed video block may be used to evaluate the encoding quality for a given prediction, transform, and / or quantization.The video encoder 500 may be configured to perform multiple encoding passes (e.g., performing encoding while varying one or more of prediction, transformation parameters, and quantization parameters). The rate-distortion or other system parameters of the bitstream may be optimized based on evaluation of the reconstructed video blocks. Additionally, the reconstructed video blocks may be stored and used as references for predicting subsequent blocks.

[0148] Referring again to FIG. 5, the intra-predictor 512 may be configured to select an intra-prediction mode for the video block to be coded. The intra-predictor 512 may be configured to evaluate a frame and determine an intra-prediction mode to use to code a current block. As discussed above, possible intra-prediction modes may include a planar prediction mode, a DC prediction mode, and an angular prediction mode. Additionally, it should be noted that in some examples, the prediction mode for the chroma components may be inferred from the prediction mode for the luma prediction mode. The intra-predictor 512 may select the intra-prediction mode after performing one or more coding passes. Additionally, in one embodiment, the intra-predictor 512 may select the prediction mode based on a rate distortion pass. As shown in FIG. 5, the intra-predictor 512 outputs intra-prediction data (e.g., syntax elements) to the entropy encoder 518 and the transform coefficient generator 504. As discussed above, the transform performed on the residual data may be mode-dependent (e.g., a secondary transform matrix may be determined based on the prediction mode).

[0149] Referring again to FIG. 5, the inter prediction processor 514 may be configured to perform inter prediction coding on the current video block. The inter prediction processor 514 may be configured to receive a source video block and calculate a motion vector for the PU of the video block. The motion vector may indicate the displacement of the PU of the video block in the current video frame relative to a predictive block in a reference frame. The inter prediction coding may use one or more reference pictures. Furthermore, the motion prediction may be uni-predictive (using one motion vector) or bi-predictive (using two motion vectors). The inter prediction processor 514 may be configured to select a predictive block by calculating pixel differences determined, for example, by sum of absolute difference (SAD), sum of square difference (SSD), or other difference measurement method. As described above, the motion vector may be determined and determined according to the motion vector prediction. The inter prediction processor 514 may be configured to perform motion vector prediction as described above. The inter prediction processor 514 may be configured to generate a predictive block using the motion prediction data. For example, the inter prediction processor 514 may place the prediction video block in a frame buffer (not shown in FIG. 5). Note that the inter prediction processor 514 may be further configured to apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values ​​for use in motion prediction. The inter prediction processor 514 may output motion prediction data for the calculated motion vectors to the entropy encoder 518.

[0150] Referring back to FIG. 5, the filter unit 516 receives the reconstructed video block and the coding parameters and outputs modified reconstructed video data. The filter unit 516 may be configured to perform deblocking and / or Sample Adaptive Offset (SAO) filtering. SAO filtering is a non-linear amplitude mapping that can be used to improve reconstruction by adding an offset to the reconstructed video data. It should be noted that, as shown in FIG. 5, the intra-prediction unit 512 and the inter-prediction unit 514 may receive the modified reconstructed video block via the filter unit 216. The entropy encoder 518 receives the quantized transform coefficients and prediction syntax data (i.e., intra-prediction data, motion prediction data). It should be noted that in some examples, the coefficient quantizer 506 may perform a scan of a matrix including the quantized transform coefficients before the coefficients are output to the entropy encoder 518. In other examples, the entropy encoder 518 may perform a scan. The entropy encoder 518 may be configured to perform entropy encoding according to one or more of the techniques described herein. As such, the video encoder 500 represents one example of a device configured to generate encoded video data according to one or more techniques of this disclosure.

[0151] Referring back to Fig. 1, the data encapsulator 107 may receive the encoded video data and generate a compliant bitstream, such as a series of NAL units, according to a defined data structure. A device receiving the compliant bitstream may regenerate the video data therefrom. Furthermore, as mentioned above, sub-bitstream extraction may refer to a process in 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 conforming bitstream may be used instead of the term compliant bitstream.

[0152] In one embodiment, data encapsulator 107 can be configured to generate syntax according to one or more of the techniques described herein. Note that data encapsulator 107 need not be located within the same physical device as video encoder 106. For example, the functions described as being performed by video encoder 106 and data encapsulator 107 may be distributed among the devices shown in FIG.

[0153] In one embodiment, a picture may be divided into tile sets and tiles, where a tile set is a sequence of tiles and a tile is a sequence of coding tree units. A tile set may cover a rectangular area of ​​a picture. FIG. 7 shows an example of a picture divided into six tile sets. In the example shown in FIG. 7, each tile set is rectangular. Each tile set may have a different number of tiles arranged in a different number of tile columns and rows. In another embodiment, each tile set may have the same number of tiles. In addition, the number of tile columns and the number of tile rows in each tile set may be changed in each picture. A flag may be signaled to indicate that the number of tile columns and the number of tile rows in each tile set are fixed in the coded video sequence. It is noted that a "tile set" may instead be referred to as a "slice". Thus, the terms "tile set" or "tile set" and "slice" may be used interchangeably.

[0154] As mentioned above, Table 4 shows the general NAL unit syntax provided in JVET-K1001. As further mentioned above, JVET-K1001 provides a place where NAL unit types are yet to be defined. However, it should be noted that document JVET-K0325, "On High Level Syntax Starting Point", 11th Meeting of ISOTEC JTC1 / SC29 / WG11 10T8 July 2018, Ljubljana, SI, which is incorporated by reference herein and referred to as JVET-K0325, provides NAL unit types that are added to JVET-K1001. In one embodiment, in accordance with the techniques described herein, data encapsulator 107 may be configured to signal one or more of the NAL unit types included in Table 18.

[0155] [Table 20] With respect to Table 18, the following can be defined:

[0156] Intra Random Access Point (IRAP) picture: A coded picture in which each VCL NAL unit has nal_unit_type equal to IRAP_NUT.

[0157] Non-IRAP picture: A coded picture in which each VCL NAL unit has nal_unit_type equal to NON_IRAP_NUT.

[0158] Signaling the picture header as a NAL unit is shown in Table 18. Signaling syntax parameters in the picture header and overriding them in the tile set header can allow for bit savings and still support flexibility. In some embodiments, in accordance with the techniques herein, the same picture header may apply to multiple pictures. This can provide additional bit savings. Having the picture header as its own NAL unit makes it easier for multiple pictures to reference the same picture header.

[0159] The tile parameter related header may have the following aspects: 1. it may apply to more than one tile, e.g. a tile set or collection of tiles, so it may be a tile set header, and / or 2. it may selectively override some of the parameters from the picture header, if necessary. This may be controlled by a set of presence flags in the tile set header.

[0160] Note that in an alternative embodiment, PICH_NUT may be a non-VCL NAL unit that is activated for each picture / tile set. For example, the NAL unit table in this case may be as shown in Table 18A.

[0161] [Table 21] In one embodiment, the following definitions of tiles, tile columns, tile rows, and tile sets may be used: Note that the words "tile set" and "tile set" are used interchangeably and may mean the same thing.

[0162] Tile: A rectangular region of Coded Tree Blocks (CTBs) within a particular tile column and a particular tile row in a picture.

[0163] Tile column: A rectangular region of a CTB with a height equal to the height of the picture and a width specified by a syntax element in the picture parameter set.

[0164] Tile Row: A rectangular region of a CTB with a height specified by a syntax element in the picture parameter set and a width equal to the width of the picture.

[0165] Tile Set: A collection of one or more tiles. In one embodiment, a tile set shall be rectangular in shape. A tile set may only contain an integer number of contiguous tiles. In one embodiment of a tile set, each tile must be contiguous with other tiles along the column or row dimension, or the tile set must have only one tile.

[0166] In one embodiment, NONIRAP_NT may be the coded non-IRAP tile set tileset_layer_rbsp() and IRAP_NUT may be the coded IRAP tile set tileset_layer_rbsp(). The bitstream resulting from the sub-bitstream extraction process that extracts only data for the IRAP tile set can be decoded independently. The first picture or subpicture of this extracted bitstream that corresponds to a tile set is an IRAP picture or subpicture.

[0167] Table 19 shows an example of tileset_layer_rbsp() syntax that may be signaled by data encapsulator 107 in accordance with the techniques herein.

[0168] [Table 22] Table 20 shows an example of a tileset_header() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0169] [Table 23] With respect to Table 20, each syntax element may be based on the following definition:

[0170] ts_pic_header_id specifies the value of pic_header_id in the picture header that applies to this tile set. The value of ts_pic_header_id must be between 0 and 2, inclusive. 32 Must be in the range -1.

[0171] tile_set_id defines the tile set identifier for this tile set.

[0172] first_tile_id defines the TileId (tile identifier) ​​of the first tile in the tile set, using the identifier tile_set_id present in the tileset_data() that follows this tileset_header().

[0173] num_tiles_in_setdata defines the number of tiles in the tile set, determined by the identifier tile_set_id present in the tileset_data() that follows this tileset_header().

[0174] Table 21 shows an example of a tileset_header() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0175] [Table 24] With respect to Table 21, each syntax element may be based on the following definition:

[0176] ts_pic_header_id specifies the value of pic_header_id in the picture header that applies to this tile set. The value of ts_pic_header_id must be between 0 and 2, inclusive. 32 Must be in the range -1.

[0177] first_tile_set_id specifies the tile set identifier of the first tile set in the tileset_data() following the tileset_header().

[0178] num_tile_set_ids_minus1+1 defines the number of tilesets that exist in the tileset_data() following this tileset_header().

[0179] first_tile_id_in_first_tileset specifies the TileId (tile identifier) ​​of the first tile in the first tileset that exists in the tileset_data() following this tileset_header().

[0180] num_tiles_in_setdata_in_last_tileset specifies the number of tiles in the last tileset that are present in the tileset_data() following this tileset_header().

[0181] Table 22 shows an example of a tileset_header() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0182] [Table 25] With respect to Table 22, each syntax element may be based on the following definition:

[0183] first_tile_set_id defines the tile set identifier for the first tile set in the tileset_data() following this tileset_header().

[0184] num_tile_set_ids_minus1+1 defines the number of tilesets that exist in the tileset_data() following this tileset_header().

[0185] first_tile_id_in_first_tileset specifies the TileId (tile identifier) ​​of the first tile in the first tileset that exists in the tileset_data() following this tileset_header().

[0186] num_tiles_in_setdata_in_first_tileset specifies the number of tiles in the first tileset that are present in the tileset_data() following this tileset_header().

[0187] num_tiles_in_setdata_in_last_tileset specifies the number of tiles in the last tileset that are present in the tileset_data() following this tileset_header().

[0188] Table 22A shows an example of tileset_header() syntax that may be signaled by data encapsulator 107 in accordance with the techniques herein. In this example, only the full integer number of tilesets is included in the tileset_data(). This requires fewer fiber syntax elements in the tileset_header().

[0189] [Table 26] With respect to Table 22A, each syntax element may be based on the following definitions:

[0190] first_tile_set_id specifies the tile set identifier of the first tile set in the tileset_data() following the tileset_header().

[0191] num_tile_set_ids_minus1+1 defines the number of tilesets that exist in the tileset_data() following this tileset_header().

[0192] Table 23 shows an example of tileset_coding_parameters() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0193] [Table 27] With respect to Table 23, each syntax element may be based on the following definition:

[0194] tileset_log2_diff_ctu_max_bt_size_present_flag equal to 1 defaults to tileset_log2_diff_ctu_max_bt_size being present. tileset_log2_diff_ctu_max_bt_size_present_flag equal to 0 defaults to tileset_log2_diff_ctu_max_bt_size not being present. If not present, tileset_log2_diff_ctu_max_bt_size is inferred to be equal to the log2_diff_ctu_max_bt_size from the pic_header() structure corresponding to ts_pic_header_id of this tileset_header() active for this tileset.

[0195] tileset_log2_diff_ctu_max_bt_size specifies the difference between the luma CTB size and the maximum luma size (width or height) of a coding block that can be split using binary partitioning for this tileset. The semantics of log2_diff_ctu_max_bt_size apply outside tilesets.

[0196] tileset_sbtmvp_size_override_flag_present_flag equal to 1 specifies that tileset_sbtmvp_size_override_flag is present, and log2_tileset_sbtmvp_active_size_minus2 is present if tileset_sbtmvp_size_override_flag is equal to 1. tileset_sbtmvp_size_override_flag_present_flag equal to 0 specifies that tileset_sbtmvp_size_override_flag and log2_tileset_sbtmvp_active_size_minus2 are not present. If not present, tileset_sbtmvp_size_override_flag_present_flag and log2_tileset_sbtmvp_active_size_minus2 are inferred to be equal to sbtmvp_size_override_flag and log2_sbtmvp_active_size_minus2, respectively, from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() that is active for this tileset.

[0197] tileset_sbtmvp_size_override_flag equal to 1 specifies that the syntax element log2_tileset_sbtmvp_active_size_minus2 is present for the current tileset. sbtmvp_size_override_flag equal to 0 specifies that the syntax element log2_tileset_sbtmvp_active_size_minus2 is not present, and defaults to log2_tileset_sbtmvp_size_active_minus2 being inferred to be equal to log2_sbtmvp_size_active_minus2.

[0198] log2_tileset_sbtmvp_active_size_minus2+2 specifies the value of the subblock size used to derive the subblock-based TMVP motion parameters for the current tile set. If log2_tileset_sbtmvp_size_active_minus2 is not present, it is inferred to be equal to log2_sbtmvp_size_active_minus2. The variable is derived as follows:

[0199] Log2SbtmvpSize=log2_tileset_sbtmvp_size_active_minus2+2 Tileset_tmvp_info_present_flag equal to 1 specifies that tileset_temporal_mvp_enabled_flag, tileset_mvd_l1_zero_flag, and tileset_collocated_from_10_flag may be present. Tileset_tmvp_info_present_flag equal to 0 specifies that tileset_temporal_mvp_enabed_flag, tileset_mvd_l1_zero_flag, and tileset_collocated_from_10_flag are not present. If not present, tileset_temporal_mvp_enabled_flag, tileset_mvd_l1_zero_flag, and tileset_collocated_from_10_flag are inferred to be equal to pic_temporal_mvp_enabed_flag, mvd_l1_zero_flag, and collocated_from_10_flag, respectively, from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() that is active for this tileset.

[0200] tileset_temporal_mvp_enabled_flag specifies whether a temporal motion vector predictor can be used for inter prediction of the current tile set. If tileset_temporal_mvp_enabled_flag is equal to 0, the syntax elements of the current tile set shall be constrained such that a temporal motion vector predictor is not used for decoding of the current tile set. Otherwise (tileset_temporal_mvp_enabled_flag is equal to 1), a temporal motion vector predictor may be used for decoding of the current tile set. If not present, the value of tileset_temporal_mvp_enabled_flag is inferred to be equal to the pic_temporal_mvp_enabled_flag from the pic_header() structure corresponding to ts_pic_header_id in tileset_header() for this tileset that is active for this tileset.

[0201] tileset_mvd_l1_zero_flag equal to 1 indicates that the mvd_coding(x0,y0,1) syntax structure is not parsed and MvdL1[x0][y0][compIdx] is set equal to 0, for compIdx=0 to 1. mvd_l1_zero_flag equal to 0 indicates that the mvd_coding(x0,y0,1) syntax structure is parsed for the current tileset.

[0202] tileset_collocated_from_10_flag equal to 1 specifies that, for the current tile set, the collocated pictures used for temporal motion vector prediction are derived from reference picture list 0. collocated_from_10_flag equal to 0 specifies that, for the current tile set, the collocated pictures used for temporal motion vector prediction are derived from reference picture list 1. If tileset_collocated_from_10_flag is not present, it is inferred to be equal to the collocated_from_10_flag from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() active for this tileset.

[0203] A tileset_six_minus_max_num_merge_present_flag equal to 1 defaults to tileset_six_minus_max_num_merge_cand being present. A tileset_six_minus_max_num_merge_present_flag equal to 0 defaults to tileset_six_minus_max_num_merge_cand not being present. If not present, tileset_six_minus_max_num_merge_cand is inferred to be equal to six_minus_max_num_merge_cand from the pic_header() structure corresponding to ts_pic_header_id of this tileset_header() active for this tileset.

[0204] Tileset_six_minus_max_num_merge_cand specifies the maximum number of merge motion vector prediction (MVP) candidates supported in the current tile set subtracted from 6. The maximum number of merge MVP candidates, MaxNumMergeCand, is derived as follows:

[0205]

number

[0206] A tileset_dep_quant_info_present_flag equal to 1 specifies that the tileset_dep_quant_enabled_flag is present. A tileset_dep_quant_info_present_flag equal to 0 specifies that the tileset_dep_quant_enabled_flag is not present. If not present, the tileset_dep_quant_enabled_flag is inferred to be equal to the dep_quant_enabled_flag from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() that is active for this tileset.

[0207] tileset_dep_quant_enabled_flag equal to 0 defaults to dependent quantization being disabled for the current tileset. tileset_dep_quant_enabled_flag equal to 1 defaults to dependent quantization being enabled for the current tileset.

[0208] A tileset_sign_data_hiding_enabled_flag equal to 0 defaults to sign bit hiding being disabled for the current tileset. A tile_sign_data_hiding_enabled_flag equal to 1 defaults to sign bit hiding being enabled for the current tileset. If tile_sign_data_hiding_enabled_flag is not present, it is inferred to be equal to the sign_data_hiding_enabled_flag from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() that is active for this tileset.

[0209] Table 24 shows an example of tileset_data() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0210] [Table 28] With respect to Table 24, each syntax element may be based on the following definition:

[0211] end_of_tileset_flag equal to 0 specifies that another CTU follows in the tile set. end_of_tileset_flag equal to 1 specifies the end of the tile set slice, i.e. that no further CTUs follow in the tile set.

[0212] Table 25 shows an example of rbsp_tileset_trailing_bits() syntax that may be signaled by data encapsulator 107 in accordance with the techniques herein.

[0213] [Table 29] Table 26 shows an example of pic_header_rbsp() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0214] [Table 30] Table 27 shows an example of pic_header() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0215] [Table 31] With respect to Table 24, each syntax element may be based on the following definition:

[0216] pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id shall be in the range 0 to 63, inclusive.

[0217] The pic_header_id identifies a picture header for reference by other syntax elements. The value of pps_pic_parameter_set_id shall be between 0 and 2, inclusive. 32 It is assumed to be in the range of -1.

[0218] picture_type indicates the coding type of the picture according to Table 28. Values ​​of pic_type shall be equal to 0, 1, or 2 in bitstreams conforming to this version of this specification. Other values ​​of pic_type are reserved for future use. Decoders conforming to this version of this specification shall ignore reserved values ​​of pic_type.

[0219] [Table 32] log2_diff_ctu_max_bt_size specifies the difference between the luma CTB size and the maximum luma size (width or height) of a coding block that can be split using binary splitting.

[0220] sbtmvp_size_override_flag equal to 1 specifies that the syntax element log2_sbtmvp_active_size_minus2 is present for the current slice, and sbtmvp_size_override_flag equal to 0 specifies that the syntax element log2_atmvp_active_size_minus2 is not present and log2_sbtmvp_size_active_minus2 is inferred to be equal to log2_sbtmvp_default_size_minus2.

[0221] log2_sbtmvp_active_size_minus2+2 specifies the value of the sub-block size used to derive the sub-block-based TMVP motion parameters for the current slice. If log2_sbtmvp_size_active_minus2 is not present, it is inferred to be equal to log2_sbtmvp_default_size_minus2. The variable is derived as follows:

[0222] Log2SbtmvpSize=log2_sbtmvp_size_active_minus2+2 pic_temporal_mvp_enabled_flag specifies whether a temporal motion vector predictor can be used for inter prediction of the current picture. If pic_temporal_mvp_enabled_flag is equal to 0, the syntax elements of the current picture shall be constrained such that a temporal motion vector predictor is not used for decoding of the current picture. Otherwise (pic_temporal_mvp_enabled_flag is equal to 1), a temporal motion vector predictor may be used for decoding of the current picture. If not present, the value of pic_temporal_mvp_enabled_flag is inferred to be equal to 0.

[0223] mvd_l1_0_flag equal to 1 indicates that the mvd_coding(x0,y0,1) syntax structure is not parsed and MvdL1[x0][y0][compIdx] is set equal to 0, for compIdx=0 to 1. mvd_l1_zero_flag equal to 0 indicates that the mvd_coding(x0,y0,1) syntax structure is parsed.

[0224] collocated_from_10_flag equal to 1 specifies that the collocated picture used for temporal motion vector prediction is derived from reference picture list 0. collocated_from_10_flag equal to 0 specifies that the collocated picture used for temporal motion vector prediction is derived from reference picture list 1. If collocated_from_10_flag is not present, it is inferred to be equal to 1.

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

[0226] MaxNumMergeCand=6-six_minus_max_num_merge_cand The value of MaxNumMergeCand shall be in the range of 1 to 6, inclusive.

[0227] dep_quant_enabled_flag equal to 0 specifies that dependent quantization is disabled. dep_quant_enabled_flag equal to 1 specifies that dependent quantization is enabled.

[0228] 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. If sign_data_hiding_enabled_flag is not present, it is inferred to be equal to 0.

[0229] Note that in one embodiment, one or more syntax elements in pic_header() may be signaled with PPS_NUT instead of PICH_NUT.

[0230] Table 29 shows an example of rbsp_pic_header_trailing_bits() syntax that may be signaled by a data encapsulator 107 in accordance with the techniques herein.

[0231] [Table 33] Note that in some embodiments, a picture header can apply to one or more pictures. Additionally, in some embodiments, parameters in a picture header can be overridden for a tile set according to tile set parameters. In some example cases, certain restrictions may apply for overriding parameters in a picture header for a tile set.

[0232] As mentioned above, in ITU-T H.265, some or all of the tile structure, i.e., one or more tile and / or tile set related parameters for a picture, are signaled using a picture parameter set. In one embodiment, in accordance with the techniques herein, the tile structure may be signaled within a picture parameter set, which is identified in the picture_header() as provided above. In another embodiment, some or all of the tile structure, i.e., one or more tile and / or tile set related parameters, may be signaled within a sequence parameter set (SPS).

[0233] In this manner, source device 102 represents an example of a device configured to signal values ​​for syntax elements within a network abstraction layer unit that indicate that a tile set layer syntax structure is included in the network abstraction layer unit, and to signal values ​​for one or more tile set parameters that are included in the tile set layer syntax structure.

[0234] Referring again to FIG. 1, interface 108 may include any device configured to receive data generated by data encapsulator 107 and transmit and / or store the data on a communications 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 capable of transmitting and / or receiving information. Additionally, interface 108 may include a computer system interface that may allow files to be stored on a storage device. For example, interface 108 may include a Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) bus protocols, a proprietary bus protocol, a Universal Serial Bus (USB) protocol, an I / O protocol, or any other type of device ...2 C, or any other logical and physical structure that can be used to interconnect peer devices.

[0235] 1, destination 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 capable of receiving and / or transmitting information. Additionally, interface 122 may include an interface for a computer system that allows a compliant video bitstream to be obtained from a storage device. For example, interface 122 may include interfaces for PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, I / O protocols, and the like. 2 C, or any other logical and physical structures that may be used to interconnect peer devices. Data decapsulator 123 may be configured to receive and parse any of the example syntax structures described herein.

[0236] The video decoder 124 may include any device configured to receive a bitstream (e.g., an MCTS sub-bitstream extraction) and / or an acceptable variant thereof and regenerate video data therefrom. The display 126 may include any device configured to display video data. The 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. The display 126 may include a high-definition display or an ultra-high-definition display. Although in the example shown in FIG. 1, the video decoder 124 is described as outputting data to the display 126, it should be noted that the video decoder 124 may be configured to output video data to various types of devices and / or subcomponents thereof. For example, the video decoder 124 may be configured to output video data to any communication medium as described herein.

[0237] FIG. 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. In one embodiment, the video decoder 600 may be configured to decode transform data and recover residual data from transform coefficients based on the decoded transform data. The video decoder 600 may be configured to perform intra-prediction 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 listed in Tables 1-27 above. The video decoder 600 may perform video decoding based on the values ​​of the parsed syntax elements. For example, different video decoding techniques may be performed based on whether a picture is of a particular type.

[0238] In the example shown in FIG. 6, the video decoder 600 includes an entropy decoder 602, an inverse quantizer and transform coefficient processor 604, an intra-predictor 606, an inter-predictor 608, an adder 610, a post-filter 612, and a reference buffer 614. The video decoder 600 may be configured to decode video data in a manner consistent with a video encoding system. It should be noted that while the example video decoder 600 is shown with separate functional blocks, such illustration is for illustrative purposes only and is not intended to limit the video decoder 600 and / or its subcomponents to a particular hardware or software architecture. The functionality of the video decoder 600 may be realized using any combination of hardware, firmware, and / or software implementations.

[0239] As shown in FIG. 6, the entropy decoding unit 602 receives an entropy coded bitstream. The entropy decoding unit 602 may be configured to decode syntax elements and quantized coefficients from the bitstream according to a reciprocal process of the entropy coding process. The entropy decoding unit 602 may be configured to perform entropy decoding according to any of the entropy coding techniques described above. The entropy decoding unit 602 may determine values ​​of syntax elements in the coded bitstream in accordance with a video coding standard. As shown in FIG. 6, the entropy decoding unit 602 may determine quantization parameters, quantized coefficient values, transform data, and prediction data from the bitstream. In the embodiment shown in FIG. 6, the inverse quantization and transform coefficient processing unit 604 receives the quantization parameters, quantized coefficient values, transform data, and prediction data from the entropy decoding unit 602, and outputs reconstructed residual data.

[0240] Referring again to FIG. 6, the reconstructed residual data may be provided to the adder 610, which may add the reconstructed residual data to a predictive video block to generate reconstructed video data. The predictive video block may be determined according to a predictive video technique (i.e., intra prediction and inter-frame prediction). The intra prediction processor 606 may be configured to receive the intra prediction syntax element and obtain the predictive video block from a reference buffer 614. The reference buffer 614 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 modes described above. The inter prediction processor 608 may receive the inter prediction syntax element and generate a motion vector to identify a predictive block in one or more reference frames stored in the reference buffer 616. The inter prediction processor 608 may potentially perform interpolation based on an interpolation filter to generate a motion compensated block. The syntax element may include an identifier of an interpolation filter to be used for motion prediction having sub-pixel accuracy. The inter-prediction processor 608 may use an interpolation filter to calculate interpolated values ​​for sub-integer pixels of the 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. It should be noted that in some examples, the post-filter unit 614 may further be configured to perform proprietary optional filtering (e.g., visual enhancement such as mosquito noise reduction). As shown in FIG. 6, the reconstructed video blocks may be output by the video decoder 600.In this manner, video decoder 600 represents an example of a device configured to parse values ​​for syntax elements in a network abstraction layer unit that indicate that a tile set layer syntax structure is included in the network abstraction layer unit, parse values ​​for one or more tile set parameters included in the tile set layer syntax structure, and generate video data based on the parsed values ​​for the one or more tile set parameters.

[0241] In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored or transmitted as one or more instructions or code on a computer-readable medium and executed by a hardware-based processor. A computer-readable medium may include a computer-readable storage medium, which corresponds to a tangible medium, such as a data storage medium or a communication medium, including any medium that facilitates the transfer of a computer program from one place to another, for example according to a communication protocol. In this manner, a computer-readable medium may generally correspond to (1) a non-transitory tangible computer-readable storage medium, or (2) a communication medium, such as a signal or carrier wave. A data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

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

[0243] The 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 gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, as used herein, the term "processor" may refer to any of the foregoing structures, or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided in dedicated hardware and / or software modules configured to encode and decode, or incorporated into a composite codec. Also, the techniques may be implemented entirely in one or more circuit or logic elements.

[0244] The techniques of this disclosure can be implemented in a wide 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 illustrated in this disclosure to highlight functional aspects of devices configured to perform the disclosed techniques, but need not necessarily be realized by different hardware units. Rather, as previously described, the various units may be combined into a codec hardware unit or may be provided by a collection of interoperating hardware units, including one or more processors as previously described, along with suitable software and / or firmware.

[0245] Furthermore, each functional block and various functions of the base station device and terminal device used in each of the above-mentioned implementations can be realized or performed by an electric circuit, which is generally an integrated circuit or a plurality of integrated circuits. The circuit designed to perform the functions described herein may comprise a general-purpose processor, a digital signal processor (DSP), an application specific or general-purpose application integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, or individual hardware components, or a combination thereof. The general-purpose processor may be a microprocessor, or the processor may be a conventional processor, controller, microcontroller, or state machine. The general-purpose processor or each circuit described above may be composed of digital circuits or analog circuits. Furthermore, if an integrated circuit technology that replaces current integrated circuits appears due to the advancement of semiconductor technology, integrated circuits using this technology can also be used.

[0246] In one embodiment, a method for signaling a tile set parameter includes signaling a value for a syntax element in a network abstraction layer unit indicating that a tile set layer syntax structure is included in the network abstraction layer unit, and signaling values ​​for one or more tile set parameters included in the tile set layer syntax structure.

[0247] In one embodiment, a method for decoding video data includes parsing a value for a syntax element in a network abstraction layer unit indicating that a tile set layer syntax structure is included in the network abstraction layer unit, parsing values ​​for one or more tile set parameters included in the tile set layer syntax structure, and generating video data based on the parsed values ​​for the one or more tile set parameters.

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

[0249] <Cross reference> This patent application claims priority under 35 U.S.C. 35 U.S.C. § 119 to Provisional Application No. 62 / 734,232, filed September 20, 2018, the entire contents of which are incorporated herein by reference.

Claims

1. 1. A method for signaling slice parameters, comprising: signaling a value for a syntax element of the network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit; and signaling a presence flag in a slice parameter structure included in the slice layer syntax structure; determining, based on the presence flag, whether one of the one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header; determining, for the one of the one or more slice parameters, a value included in the slice layer syntax structure when the one of the one or more slice parameters is determined based on the slice layer syntax structure; the one or more slice parameters are collocated_from_10_flag, When the value of nal_unit_type indicates the presence of a picture layer syntax structure picture header, a plurality of syntax elements of the picture header are present, and when the value of nal_unit_type indicates the presence of a picture parameter set, a plurality of syntax elements of the picture parameter set are present. method.

2. The method of claim 1 , wherein the slice layer syntax structure includes a slice header, and a value of nal_unit_type in the picture header and a value of nal_unit_type in the picture parameter set are different.

3. 1. A method for decoding video data, comprising the steps of: parsing a value for a syntax element of the network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit; parsing a presence flag in a slice parameter structure included in the slice layer syntax structure; determining, based on the presence flag, whether one of the one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header; determining, for the one or more slice parameters, a value included in the slice layer syntax structure when the one of the one or more slice parameters is determined based on the slice layer syntax structure; generating video data based on the determined value for the one of the one or more slice parameters; the one or more slice parameters are collocated_from_10_flag, when the value of nal_unit_type indicates the presence of a picture layer syntax structure picture header, a number of syntax elements of the picture header are present, and when the value of nal_unit_type indicates the presence of a picture parameter set, a number of syntax elements of the picture parameter set are present.

4. The method of claim 3 , wherein the slice layer syntax structure includes a slice header, and a value of nal_unit_type in the picture header is different from a value of nal_unit_type in a picture parameter set.

5. 1. A device for encoding video data, comprising: one or more processors; one or more non-transitory computer-readable storage media coupled to the one or more processors, the storage media being configured to, when executed by at least one of the one or more processors, cause the device to: signaling a value for a syntax element of the network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit; and signaling a presence flag in a slice parameter structure included in the slice layer syntax structure; determining, based on the presence flag, whether one of the one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header; determining, for the one of the one or more slice parameters, a value included in the slice layer syntax structure when the one of the one or more slice parameters is determined based on the slice layer syntax structure; a storage medium including one or more computer-readable instructions for executing the one or more slice parameters are collocated_from_10_flag, When the value of nal_unit_type indicates the presence of a picture layer syntax structure picture header, multiple syntax elements of the picture header are present, and when the value of nal_unit_type indicates the presence of a picture parameter set, multiple syntax elements of the picture parameter set are present.

6. 1. A device for decoding video data, comprising: one or more processors; one or more non-transitory computer-readable storage media coupled to the one or more processors, the storage media, when executed by at least one of the one or more processors, causing the device to: parsing a value for a syntax element of the network abstraction layer unit indicating that a slice layer syntax structure is included in the network abstraction layer unit; parsing a presence flag in a slice parameter structure included in the slice layer syntax structure; determining, based on the presence flag, whether one of the one or more slice parameters is determined based on the slice layer syntax structure or based on a picture header; determining, when the one of the one or more slice parameters is determined based on the slice layer syntax structure, a value included in the slice layer syntax structure for the one or more slice parameters; generating video data based on the determined value for the one of the one or more slice parameters; a storage medium including one or more computer-readable instructions for causing the the one or more slice parameters are collocated_from_10_flag, When the value of nal_unit_type indicates the presence of a picture layer syntax structure picture header, multiple syntax elements of the picture header are present, and when the value of nal_unit_type indicates the presence of a picture parameter set, multiple syntax elements of the picture parameter set are present.

Images