System and method for signaling parameters in video coding

Abstract

The present invention provides a method for signaling tile set parameters of encoded video and a non-temporary computer-readable recording medium. [Solution] A method for signaling tile setting parameters, wherein the value of a syntax element indicating that the tileset layer syntax structure is included in the NAL unit is signaled in the Network Abstraction Layer (NAL) unit, and the value of one or more tileset parameters included in the tileset layer syntax structure is signaled.

Description

Technical Field

[0001] The present disclosure relates to video encoding, and more particularly to techniques for signaling tile set parameters of encoded video.

Background Art

[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 phones including so-called smartphones, and medical imaging devices. Digital video can be encoded according to video coding standards. Video coding standards can incorporate video compression techniques. Examples of video coding standards include ISO / IEC MPEG-4 Visual and ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC), and High-Efficiency Video Coding (HEVC). HEVC is described in High-Efficiency Video Coding (HEVC), Rec. ITU-T H.265 (December 2016), which is incorporated herein by reference and referred to herein as ITU-T H.265. Extensions and improvements to ITU-T H.265 are currently being considered in relation to the development of next-generation video coding standards. For example, the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Moving Picture Experts Group (MPEG) (collectively referred to as the Joint Video Exploration Team (JVET)) are considering the potential need for standardization of future video coding technologies that have 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 that have the potential to improve video coding technologies beyond the capabilities of ITU-T H.265, and these are incorporated herein by reference. Note that the coding features of JEM 7 are implemented using the JEM reference software.As used herein, the term JEM may collectively refer to the implementation of the algorithms and JEM reference software included in JEM 7. Furthermore, in response to the "Joint Call for Proposals on Video Compression with Capabilities beyond HEVC" jointly issued by VCEG and MPEG, several descriptions of video coding were 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 these several descriptions of video coding, a draft text of the video coding specification is 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. The document "Versatile Video Coding (Draft 2)," referred to as JVET-K1001, "11th Meeting of ISO / IEC JTC1 / SC29 / WG11, 10-18 July 2018, Ljubljana, SI, document JVET-K1001-v5," incorporated as reference herein, is an updated version of JVET-J1001.

[0003] Video compression techniques reduce the data requirements for storing and transmitting video data by leveraging the inherent redundancy in video sequences. Video compression techniques can subdivide video sequences into successively smaller parts (i.e., groups of frames in a video sequence, frames within groups of frames, slices within frames, coded tree units (e.g., macroblocks) within slices, coded blocks within coded tree units, etc.). Intra-predictive coding techniques (e.g., within a picture (spatial)) and inter-predictive techniques (i.e., between pictures (temporal)) can be used to generate difference values ​​between units of video data being coded and reference units of video data. These difference values ​​are sometimes called residual data. Residual data can be coded as quantized transformation coefficients. Syntax elements can associate residual data with reference coded units (e.g., intra-predictive mode indices, motion vectors, and block vectors). Residual data and syntax elements can be entropi-encoded. Entropi-encoded residual data and syntax elements can be included in a compliant bitstream. The compliant bitstream and associated metadata may be formatted according to a data structure. [Overview of the Initiative]

[0004] In one embodiment, a method for decoding slice information for decoding video data includes the steps of: receiving a slice header syntax structure corresponding to a slice of the video data, wherein the slice comprises an integer number of tiles; parsing from the slice header syntax structure a first syntax element that identifies the number of tiles in the slice, wherein the slice header syntax structure is included in a slice layer syntax structure, and the slice layer syntax structure includes a slice trailing bit syntax structure that includes cabac_zero_word; and conditionally parsing from the slice header syntax structure a second syntax element that identifies a list of reference images for collated images for time motion vector prediction, based on whether a time motion vector predictor is available.

[0005] In one embodiment, a method for encoding slice information for generating video data includes the steps of: determining a slice header syntax structure corresponding to a slice of video data, wherein the slice comprises an integer number of tiles; encoding a first syntax element in the slice header syntax structure that identifies the number of tiles in the slice, wherein the slice header syntax structure is included in a slice layer syntax structure, wherein the slice layer syntax structure includes a slice trailing bit syntax structure that includes cabac_zero_word; and conditionally encoding a second syntax element in the slice header syntax structure that identifies a list of reference images for collated images for time motion vector prediction, based on whether a time motion vector predictor is available.

[0006] In one embodiment, a non-temporary computer-readable recording medium storing video data is configured such that the video data is decoded by a method for decoding slice information. The method includes the steps of: receiving a slice header syntax structure corresponding to a slice of the video data, wherein the slice comprises an integer number of tiles; parsing from the slice header syntax structure a first syntax element that identifies the number of tiles in the slice, wherein the slice header syntax structure comprises a slice layer syntax structure, the slice layer syntax structure comprises a slice trailing bit syntax structure containing cabac_zero_word; and conditionally parsing from the slice header syntax structure a second syntax element that identifies a list of reference images for collated images for time motion vector prediction, based on whether a time motion vector predictor is available. [Brief explanation of the drawing]

[0007] [Figure 1] Figure 1 is a block diagram showing an example of a system that can be configured to encode and decode video data according to one or more of the technologies of this disclosure. [Figure 2] Figure 2 is a conceptual diagram showing encoded video data and corresponding data structures according to one or more techniques of this disclosure. [Figure 3] Figure 3 is a conceptual diagram showing a data structure that encapsulates encoded video data and corresponding metadata according to one or more of the techniques of this disclosure. [Figure 4] Figure 4 is a conceptual diagram showing an example of components that may be included in an implementation of a system that can be configured to encode and decode video data according to one or more of the technologies of this disclosure. [Figure 5] Figure 5 is a block diagram showing an example of a video encoder that can be configured to encode video data according to one or more of the technologies of this disclosure. [Figure 6]Figure 6 is a block diagram showing an example of a video decoder that can be configured to decode video data according to one or more of the techniques of this disclosure. [Figure 7] Figure 7 is a conceptual diagram showing encoded video data and corresponding data structures according to one or more techniques of this disclosure. [Modes for carrying out the invention]

[0008] In general, this disclosure describes various techniques for encoding video data. Specifically, this disclosure describes techniques for signaling tileset parameters for encoded video. Signaling tileset parameters using the techniques described herein may be particularly useful in improving the performance of video distribution systems by reducing transmission bandwidth and / or facilitating the parallelization of video encoders and / or decoders. While the techniques of this disclosure are described in relation to ITU-T H.264, ITU-T H.265, JVET-J1001 and JVET-K1001, it should be noted that the techniques of this disclosure are generally applicable to video encoding. For example, the encoding techniques described herein can be incorporated into video encoding systems (including video encoding systems based on future video encoding standards) that include block structures other than those included in ITU-T H.265, intra-prediction techniques, inter-prediction techniques, transformation techniques, filtering techniques, and / or entropy coding techniques. Therefore, references to ITU-T H.264, ITU-T H.265, JVET-J1001, and JVET-K1001 are for illustrative purposes only and should not be construed as limiting the scope of the technology described herein. Furthermore, it should be noted that incorporations of documentary references herein should not be construed as limiting or creating ambiguity with respect to the terminology used herein. For example, if an incorporated reference gives a different definition of a term than that of another incorporated reference, and / or if that term is used herein, that term should be construed to broadly include each of the corresponding definitions and / or to include each of the specific definitions instead.

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

[0010] In one embodiment, a non-temporary computer-readable storage medium includes a record instruction therein, which, when executed, causes one or more processors of the device to signal values ​​for syntax elements within a network abstraction layer unit and values ​​for one or more tileset parameters included in the tileset layer syntax structure, indicating that the tileset layer syntax structure is included in the network abstraction layer unit.

[0011] In one embodiment, the apparatus includes means for signaling values ​​for syntax elements within a network abstraction layer unit, indicating that the tileset layer syntax structure is included in the network abstraction layer unit, and means for signaling values ​​for one or more tileset parameters included in the tileset layer syntax structure.

[0012] In one embodiment, the device includes one or more processors configured to parse values ​​for syntax elements within a network abstraction layer unit, indicating that the tileset layer syntax structure is contained within the network abstraction layer unit; parse values ​​for one or more tileset parameters contained within the tileset layer syntax structure; and generate video data based on the parsed values ​​for one or more tileset parameters.

[0013] In one embodiment, a non-temporary computer-readable storage medium includes instructions recorded therein, which, when executed, cause one or more processors of the device to parse values ​​for syntax elements within a network abstraction layer unit indicating that the tileset layer syntax structure is included in the network abstraction layer unit, parse values ​​for one or more tileset parameters included in the tileset layer syntax structure, and generate video data based on the parsed values ​​for one or more tileset parameters.

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

[0015] Details of one or more embodiments are described in the accompanying drawings and the following specification. Other features, purposes, and advantages will be evident from the specification and drawings, as well as from the claims.

[0016] Video content typically includes a video sequence consisting of a series of frames. A series of frames is sometimes also called a group of pictures (GOP). Each video frame or picture may contain one or more slices, and a slice may contain multiple video blocks. A video block contains an array of pixel values ​​(sometimes called samples) that can be predictively encoded. Video blocks can be ordered according to a scanning pattern (e.g., raster scanning). A video encoder performs predictive coding on the video blocks and their subdivisions. ITU-T H.264 specifies a macroblock containing 16x16 luma samples. ITU-T H.265 specifies a similar coding tree unit (CTU) structure (which may also be called a Largest Coding Unit (LCU)), where a picture can be divided into CTUs of equal size, and each CTU may contain a coding tree block (CTB) with 16x16, 32x32, or 64x64 luma samples. As used herein, the term video block may generally refer to an area of ​​a picture, or more specifically, to the largest array of predictably encodeable pixel values, its subdivisions, and / or corresponding structures. Furthermore, according to ITU-T H.265, each video frame or picture may be partitioned to include one or more tiles, where a tile is a sequence of encoding tree units corresponding to a rectangular area of ​​the picture.

[0017] In ITU-T H.265, a CTU consists of a CTB for each component of video data (e.g., lumens (Y) and chromens (Cb and Cr)). Furthermore, ITU-T H.265 allows the CTU to be partitioned according to a quaternary tree (QT) partitioning structure, resulting in the CTU's CTBs being divided into coding blocks (CBs). That is, ITU-T H.265 allows the CTU to be partitioned into quaternary tree leaf nodes. According to ITU-T H.265, one lumen CB, along with two corresponding chromen CBs and associated syntax elements, is called a coding unit (CU). ITU-T H.265 allows signaling of the minimum acceptable size of a CB. In ITU-T H.265, the smallest minimum acceptable size of a lumen CB is 8x8 lumen samples. In ITU-T H.265, the decision to encode a picture region using intra-prediction or inter-prediction is made at the CU level.

[0018] In ITU-T H.265, a CU is associated with a prediction unit (PU) structure that has a root in the CU. ITU-T H.265 allows the PU structure to be divided into lumar CBs and chromar CBs for the purpose of generating corresponding reference samples. That is, ITU-T H.265 allows the lumar CB and chromar CB to be divided into their respective lumar and chromar prediction blocks (PBs), where each PB contains a block of sample values ​​to which the same prediction is applied. ITU-T H.265 allows a CB to be divided into 1, 2, or 4 PBs. ITU-T H.265 supports PB sizes from 64×64 samples to 4×4 samples. ITU-T H.265 supports square PBs for intra-prediction, where a CB can form a PB, or a CB can be divided into four 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 interprediction, where a CB can be bisected vertically or horizontally to form a PB (i.e., interprediction PB types include M×M, M / 2×M / 2, M / 2×M, or M×M / 2). Furthermore, ITU-T H.265 supports four asymmetric PB divisions for interprediction, where a CB is divided into two PBs by a quarter of its height (top or bottom) or width (left or right) (i.e., asymmetric divisions include M / 4×M left, M / 4×M right, M×M / 4 top, and M×M / 4 bottom). Reference sample values ​​and / or predicted sample values ​​for the PB are generated using intraprediction data (e.g., intraprediction mode syntax element) or interprediction data (e.g., motion data syntax element) corresponding to the PB.

[0019] JEM specifies a CTU with a maximum sample size of 256 × 256. JEM specifies a quartic-tree + binary-tree (QTBT) block structure. In JEM, the QTBT structure allows for further subdivision of quartic-tree leaf nodes by a binary-tree structure (BT). That is, in JEM, the binary-tree structure allows for recursive vertical or horizontal subdivision of quartic-tree leaf nodes. Thus, the binary-tree structure in JEM allows for square and rectangular leaf nodes, each leaf node containing one CB. As shown in Figure 2, a picture contained in a GOP can contain multiple slices, each slice containing a sequence of CTUs, and each CTU can be subdivided according to the QTBT structure. In JEM, CBs are used in predictions that do not involve any further subdivision. That is, in JEM, a CB may be a block of sample values ​​to which the same prediction is applied. Thus, a JEM QTBT leaf node may be similar to a PB in ITU-T H.265.

[0020] Intra-prediction data (e.g., intra-prediction mode syntax elements) or inter-prediction data (e.g., motion data syntax elements) can be used to associate a PU with a corresponding reference sample. Residual data can include arrays of difference values ​​corresponding to each component of the video data (e.g., lumens (Y) and chromians (Cb and Cr)). Residual data can be within the pixel region. Transformations such as discrete cosine transform (DCT), discrete sine transform (DST), integer transform, wavelet transform, or conceptually similar transforms can be applied to the pixel difference values ​​to generate transform coefficients. Note that in ITU-T H.265, a CU can be further subdivided into transform units (TTransform Units, TUs). That is, an array of pixel difference values ​​can be subdivided to generate transformation coefficients (for example, four 8x8 transformations can be applied to a 16x16 array of residual values ​​corresponding to a 16x16 Luma CB), and such subdivision is sometimes called a Transform Block (TB). The transformation coefficients can be quantized according to a quantization parameter (QP). The quantized transformation coefficients (sometimes called level values) can be entropi-coded according to entropy coding techniques (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, can also be entropi-coded. The entropi-coded and quantized transformation coefficients and the corresponding entropi-coded syntax elements can form a compliant bitstream that can be used to regenerate the video data.The binarization process can be performed on the syntax elements as part of the entropy coding process. Binarization refers to the process of converting a syntax value into a sequence of one or more bits. These bits may be referred to as "bins".

[0021] As described above, the intra-prediction data or inter-prediction data is used to generate reference sample values for a block of sample values. The difference between the sample values included in the current PB or another type of picture area structure and the associated reference samples (e.g., reference samples generated using prediction) may be referred to as residual data. As described above, the intra-prediction data or inter-prediction data can associate an area of a picture (e.g., a PB or a CB) with the corresponding reference samples. For intra-prediction coding, the intra-prediction mode can specify the positions of the reference samples within the picture. In ITU-T H.265, the defined possible intra-prediction modes include the planar (i.e., surface adaptation) prediction mode (predMode: 0), the DC (i.e., flat overall averaging) prediction mode (predMode: 1), and 33 angular prediction modes (predMode: 2 - 34). In JEM, the defined possible intra-prediction modes include the planar prediction mode (predMode: 0), the DC prediction mode (predMode: 1), and 65 angular prediction modes (predMode: 2 - 66). Note 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. Note that the techniques described herein may be generally applicable regardless of the number of defined possible prediction modes.

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

[0023] Residual data can include separate arrays of difference values ​​corresponding to each component of the video data. Residual data can be within the pixel region. Transformations such as the discrete cosine transform (DCT), discrete sine transform (DST), integer transform, wavelet transform, or conceptually similar transforms can be applied to the array of difference values ​​to generate transformation coefficients. In ITU-T H.265, a CU is associated with a transformation unit (TU) structure having a root at the CU level. That is, in ITU-T H.265, as described above, the array of difference values ​​can be subdivided for the purpose of generating transformation coefficients (for example, four 8x8 transforms can be applied to a 16x16 array of residual values). Note that in ITU-T H.265, it is not always necessary to align TBs to PBs.

[0024] Note that in JEM, the conversion coefficients are generated using the residual values ​​corresponding to the CB without further subdivision. That is, in JEM, the QTBT leaf node can be similar to both PB and TB in ITU-T H.265. In JEM, the conversion coefficients can be generated by applying the core transformation and subsequent secondary transformation (in the video encoder). For the video decoder, the order of transformations is reversed. Furthermore, in JEM, whether or not to apply the secondary transformation to generate the conversion coefficients may depend on the prediction mode.

[0025] A quantization process can be performed on transformation coefficients. Quantization approximates the transformation coefficients with an amplitude restricted to a specific set of values. Quantization may be used to vary the amount of data required to represent a group of transformation coefficients. Quantization can be achieved by dividing the transformation coefficients by a multiplier and any associated rounding function (e.g., rounding to the nearest integer). The quantized transformation coefficients are sometimes called coefficient level values. Inverse quantization (or "dequantization") may involve multiplying the coefficient level values ​​by a multiplier. Note that, as used herein, the term quantization process may, in some cases, refer to division by a multiplier that produces level values, or in other cases to multiplying by a multiplier that recovers the transformation coefficients. That is, the quantization process may, in some cases, refer to quantization, and in other cases to inverse quantization.

[0026] The following arithmetic operators may be used with respect to the expressions used herein.

[0027] [Table 1] Furthermore, the following mathematical functions can be used.

[0028] Log2(x) is the logarithm of x with base 2;

[0029]

number

[0030] The following definitions of logical operators may apply to the syntax examples used herein.

[0031] x&&y: Boolean "product" of x and y The Boolean "union" of x||yx and y ! Boolean logic: "No" If x?y:zx is true or not equal to 0, evaluate the value of y; otherwise, evaluate the value of z.

[0032] Furthermore, the following relational operators may also be applied:

[0033] [Table 2] Furthermore, it should be noted that the following descriptors may be applied to the syntax descriptors used herein.

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

[0035] -f(n): A fixed pattern bitstring using the n bits that were initially written (from left to right) as the left bit. The parsing process for this descriptor is specified by the return value of the function read_bit(n).

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

[0037] -ue(v): The left bit is the first, zero-order Exp-Golomb coding syntax element of an unsigned integer.

[0038] As described above, according to ITU-T H.265, each video frame or picture may be partitioned to contain one or more slices, and may be further partitioned to contain one or more tiles. Figure 2 is a conceptual diagram showing an example of a group of pictures containing slices. In the example shown in Figure 2, Pic4 is shown to contain two slices (i.e., Slice1 and Slice2), and each slice contains a sequence of CTUs (e.g., in raster scan order). A slice is a sequence of one or more slice segments, beginning with an independent slice segment and containing all subsequent dependent slice segments (if any), where it should be noted that 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 some cases in the embodiments described herein, the terms slice and slice segment may be used interchangeably to refer to a sequence of coding tree units. It should be noted that ITU-T H.265 states that a tile may consist of coding tree units contained within two or more slices, and a slice may consist of coding tree units contained within two or more tiles. However, ITU-T H.265 stipulates 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 within a tile belong to the same slice. Tilesets can be used to define boundaries for coding dependencies (e.g., intra-predictive dependencies, entropy coding dependencies, etc.), thereby enabling parallel processing in coding.

[0039] In ITU-T H.265, an encoded video sequence (CVS) may be encapsulated (or structured) as a sequence of access units, each access unit containing 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 should be 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 display to include a base layer and one or more additional enhancement layers. For example, a base layer may enable the provision of a video display with a basic level of quality (e.g., high-resolution rendering), and enhancement layers may enable the provision of a video display with an enhanced level of quality (e.g., ultra-high-resolution rendering). In ITU-T H.265, enhancement layers can be encoded by referencing the base layer. That is, for example, a picture in the enhancement layer may be encoded (e.g., using interpretation techniques) by referencing one or more pictures (including enlarged / reduced versions thereof) in the base layer. In ITU-T H.265, each NAL unit may include an identifier indicating the layer of video data to which the NAL unit is associated. Note that sub-bitstream extraction may refer to the process by 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 can be used to form a new compliant bitstream corresponding to a particular representation of video (e.g., a high-quality representation).

[0040] Referring to the example shown in Figure 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 the video coding characteristics. ITU-T H.265 defines a set of parameters that may be used to describe the video data characteristics and / or video coding characteristics. In ITU-T H.265, the parameter set may be encapsulated as a special type of NAL unit or signaled as a message. A NAL unit containing coded video data (e.g., slices) may be called a VCL (Video Coding Layer) NAL unit, and a NAL unit containing metadata (e.g., a set of parameters) may be called a non-VCL NAL unit. Furthermore, ITU-T H.265 allows for the signaling of Supplemental Enhancement Information (SEI) messages. In ITU-T H.265, SEI messages assist processes related to decoding, display, or other purposes, but SEI messages may not be required by 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 transmitted by some means other than being present in the bitstream (i.e., signaled out of band).

[0041] Figure 3 shows an example of a bitstream containing multiple CVSs, where each CVS is represented by a NAL unit contained within its respective access unit. In the embodiment illustrated in Figure 3, the non-VCL NAL units include their 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 within the NAL unit.

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

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

[0044] NumBytesInNalUnit specifies the size of a NAL unit in bytes. This value is necessary for decoding the NAL unit. Several forms of NAL unit boundary setting are required to enable NumBytesInNalUnit inference. One such boundary setting method is specified in Annex B of ITU-T H.265 for byte stream format. Other boundary setting methods may be specified outside this specification.

[0045] 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 format suitable for transport on various communication channels or storage media. All data is contained in NAL units, each of which contains an integer number of bytes. NAL units specify a general format for use in both packet-oriented and bitstream systems. The format of NAL units for both packet-oriented transport and byte streams 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 Annex B of ITU-T H.265.

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

[0047] RBSP includes a string of data bits (SODB) as follows:

[0048] -If SODB is empty (i.e., zero bits long), then RBSP is also empty.

[0049] - Otherwise, RBSP contains SODB as follows:

[0050] 1) The first byte of the RBSP contains the most significant and leftmost 8 bits of the SODB, the next byte of the RBSP contains the next 8 bits of the SODB, and so on until there are less than 8 bits of the SODB remaining.

[0051] 2) rbsp_trailing_bits() is located after SODB as follows:

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

[0053] ii) The next bit consists of a single rbsp_stop_one_bit equal to 1.

[0054] iii) If rbsp_stop_one_bit is not the last bit of the byte-aligned byte, then one or more rbsp_alignment_zero_bits exist to result in byte alignment.

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

[0056] Syntax structures possessing these RSP characteristics are indicated in the syntax table using the "_rbsp" suffix. These structures are carried within NAL units as the content of rbsp_byte[i] data bytes. The association between RBSP syntax structures and NAL units is as described in Table 3 of this specification.

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

[0058] emulation_prevention_three_byte is a byte equal to 0x03. If emulation_prevention_three_byte exists in the NAL unit, it should be discarded during the decryption process.

[0059] The last byte of the NAL unit is not equal to 0x00.

[0060] Within a NAL unit, the following 3-byte sequence cannot occur at any byte alignment position.

[0061] -0x000000 -0x000001 -0 x000002 Within a NAL unit, any 4-byte sequence starting with 0x000003, other than the sequences listed below, will not occur at any byte alignment position.

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

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

[0064] The forbidden_zero_bit is assumed to be equal to 0.

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

[0066] nuh_temporal_id_plus1-1 defines the time identifier for the NAL unit. The value of nuh_temporal_id_plus1 must not be equal to 0.

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

[0068] [Table 5] JPEG2026048812000007.jpg65148 For the sake of brevity, a complete description of each NAL unit type in ITU-T H.265 is not provided herein. However, refer to the relevant sections of ITU-T H.265.

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

[0070] [Table 6] JVET-K1001 defines the following for each syntax element shown in Table 4.

[0071] The forbidden_zero_bit is assumed to be equal to 0.

[0072] Regarding nal_unit_type, JVET-K1001 provides a place where NAL unit types should still be defined.

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

[0074] [Table 7] The basic definitions of each syntax element shown in Table 5 are as follows:

[0075] 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 should be in the range of 0 to 15, including both endpoints.

[0076] Chroma_format_idc defines chromosampling for lumasampling. The value of Chroma_format_idc should be in the range of 0 to 3, including both endpoints.

[0077] A separate_colour_plane_flag equal to 1 specifies that the three color components of the 4:4:4 chroma format are encoded separately, while a separate_colour_plane_flag equal to 0 specifies that the color components are not encoded separately. If separate_colour_plane_flag is not present, it is presumed to be equal to 0. When separate_colour_plane_flag is equal to 1, the encoded picture consists of three color components, each consisting of an encoded sample of one color plane (Y, Cb, or Cr), using the monochrome encoding syntax. In this case, each color plane is associated with a specific colour_plane_id value.

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

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

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

[0081] bit_depth_chroma_minus8 defines the bit depth and chroma quantization parameter range offset values ​​for the chroma array samples.

[0082] A qtbtt_dual_tree_intra_flag equal to 1 specifies that, with respect to an I slice, each CTU is divided into coding units with 64x64 luma samples using an implicit quad-tree partition, and these coding units are the root of a quad-tree syntax structure, which consists of two separate codings for luma and chroma.

[0083] log2_ctu_size_minus2+2 specifies the Luma-encoded tree block size for each CTU.

[0084] log2_min_qt_size_in_slices_minus2+2 defines the minimum luma size of leaf blocks resulting from a quaternary tree partition of a CTU in a slice of slice_type equal to 2(I).

[0085] log2_min_qt_size_inter_slices_minus2+2 specifies the minimum luma size of leaf blocks resulting from a quaternary tree partition of a CTU within a slice with slice_type equal to 0(B) or 1(P).

[0086] max_mtt_hierarchy_depth_inter_slices specifies the maximum hierarchy depth of coding units resulting from multi-type tree partitioning of quadruple tree leaves within a slice by slice_type equal to 0(B) or 1(P).

[0087] max_mtt_hierarchy_depth_intra_slices defines the maximum hierarchy depth of coding units resulting from multitype tree partitioning of quadruple tree leaves within a slice by slice_type equal to 2(I).

[0088] A sps_cclm_enabled_flag equal to 0 indicates that cross-component linear model intra-prediction from luminal to chroma components is disabled. A sps_cclm_enabled_flag equal to 1 indicates that cross-component linear model intra-prediction from luminal to chroma components is enabled.

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

[0090] A sps_sbtmvp_enabled_flag equal to 1 specifies that the subblock-based time-motion vector predictor may be used for decoding pictures by all slices with a slice_type type that is not equal to I in CVS. A sps_sbtmvp_enabled_flag equal to 0 specifies that the subblock-based time-motion vector predictor is not used in CVS. If sps_sbtmvp_enabled_flag does not exist, it is presumed to be equal to 0.

[0091] log2_sbtmvp_default_size_minus2 specifies an estimate of the syntax element log2_sbtmvp_active_size_minus2 in the slice header of slices with a slice_type that is not equal to I in CVS, when slice_sbtmvp_size_override_flag is equal to 0.

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

[0093] The 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 is constrained so 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 CVS coding unit syntax. Otherwise (sps_affine_enabled_flag is 1), affine model-based motion compensation can be used in CVS.

[0094] The sps_affine_type_flag specifies whether 6-parameter affine model-based motion compensation can be used for interpretation. If sps_affine_type_flag is equal to 0, the syntax is constrained so that 6-parameter affine model-based motion compensation is not used in CVS, and cu_affine_type_flag does not exist in the coding unit syntax in CVS. Otherwise (sps_affine_type_flag is equal to 1), 6-parameter affine model-based motion compensation can be used in CVS. If it does not exist, the value of sps_affine_type_flag is presumed to be equal to 0.

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

[0096] sps_mts_inter_enabled_flag stipulates that cu_mts_flag may be present in the remaining coding syntax for the intercoding unit. sps_mts_inter_enabled_flag equal to 0 stipulates that it is not present in the remaining coding syntax for the intercoding unit.

[0097] JVET-K1001 further provides the basic picture parameter set syntax. Table 6 shows the picture parameter set syntax for JVET-K1001.

[0098] [Table 8] JVET-K1001 defines the following for each syntax element shown in Table 6.

[0099] pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id should be in the range of 0 to 63, including both endpoints.

[0100] pps_seq_parameter_set_id specifies the value of sps_seq_parameter_set_id in SPS. The value of pps_seq_parameter_set_id must be in the range of 0 to 15, including both endpoints.

[0101] A transform_skip_enabled_flag equal to 1 indicates that transform_skip_flag may be present in the rest of the coding syntax. A transform_skip_flag equal to 0 indicates that transform_skip_flag is not present in the rest of the coding syntax.

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

[0103] [Table 9] JVET-K1001 defines the following for each syntax element shown in Table 7.

[0104] pic_type indicates that the slice_type value for all slices of an encoded picture within an access unit, including the access unit delimiter NAL unit, is a member of the set listed in Table 8 for a given value of pic_type. The value of pic_type shall be equal to 0, 1, or 2 in a bitstream 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 the reserve values ​​of pic_type.

[0105] [Table 10] Note that a B-slice refers to a slice where bipredictive interprediction, unipredictive interprediction, and intraprediction are permitted; a P-slice refers to a slice where unipredictive interprediction and intraprediction are permitted; and an I-slice refers to a slice where only intraprediction is permitted. Note that in some cases, B-slices and P-slices are collectively referred to as inter-slices.

[0106] JVET-K1001 further provides sequence termination syntax, bitstream termination syntax, and filler data syntax. Table 9 shows the sequence syntax terminations provided in JVET-K1001, Table 10 shows the bitstream syntax terminations provided in JVET-K1001, and Table 11 shows the bitstream syntax terminations provided in JVET-K1001. [Table 11] [Table 12]

[0107] [Table 13] JVET-K1001 defines the following for each syntax element shown in Table 11.

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

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

[0110] [Table 15] JVET-K1001 defines the following for each syntax element shown in Table 13.

[0111] `slice_pic_parameter_set_id` specifies the value of `pps_pic_parameter_set_id` for the PPS currently in use. The value of `slice_pic_parameter_set_id` must be in the range of 0 to 63, including both extreme values.

[0112] The slice_address specifies the address of the first CTB within a slice during a picture CTB raster scan.

[0113] The `slice_type` parameter specifies the encoding type of the slice according to Table 14.

[0114] [Table 16] If nal_unit_type has a value that includes both ends of the range to be determined, i.e., if the picture is an IRAP picture, then slice_type shall be equal to 2.

[0115] log2_diff_ctu_max_bt_size defines the difference between the luma CTB size and the maximum luma size (width or height) of an encoded block that can be partitioned using binary partitioning.

[0116] A sbtmvp_size_override_flag equal to 1 defaults to the existence of the syntax element log2_sbtmvp_active_size_minus2 for the current slice. A sbtmvp_size_override_flag equal to 0 defaults to the absence of the syntax element log2_atmvp_active_size_minus2 and the assumption that log2_sbtmvp_size_active_minus2 is equal to log2_sbtmvp_default_size_minus2.

[0117] log2_sbtmvp_active_size_minus2+2 defaults to the subblock size value used to derive the subblock-based TMVP motion parameters for the current slice. If log2_sbtmvp_size_active_minus2 does not exist, it is inferred to be equal to log2_sbtmvp_default_size_minus2. The variable is derived as follows:

[0118]

number

[0119] A 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 to 0 for compIdx=0~1. A mvd_l1_zero_flag equal to 0 indicates that the mvd_coding(x0,y0,1) syntax structure is parsed.

[0120] A collocated_from_10_flag equal to 1 defaults to the collocated picture used for time motion vector prediction being derived from reference picture list 0. A collocated_from_10_flag equal to 0 defaults to the collocated picture used for time motion vector prediction being derived from reference picture list 1. If collocated_from_10_flag does not exist, it is inferred to be equal to 1.

[0121] six_minus_max_num_merge_cand defines the maximum number of Merge Motion Vector Prediction (MVP) candidates supported within a slice, which is subtracted from 6. The maximum number of merge MVP candidates, MaxNumMergeCand, is derived as follows:

[0122]

number

[0123] A dep_quant_enabled_flag equal to 0 defaults to dependent quantization being disabled. A dep_quant_enabled_flag equal to 1 defaults to dependent quantization being enabled.

[0124] A sign_data_hiding_enabled_flag equal to 0 defaults to sign bit hiding being disabled. A sign_data_hiding_enabled_flag equal to 1 defaults to sign bit hiding being enabled. If sign_data_hiding_enabled_flag does not exist, it is presumed to be equal to 0.

[0125] JVET-K1001 further provides RBSP tail bit syntax and 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]

[0126] [Table 18] As described 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 shows a portion of the PPS syntax specified in ITU-T H.265, including the relevant syntax elements for signaling the tile structure.

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

[0128] A `tiles_enabled_flag` equal to 1 defaults to one or more tiles existing within each picture referencing a PPS. A `tiles_enabled_flag` equal to 0 defaults to exactly one tile existing within each picture referencing a PPS. The bitstream conformance requirement is that the value of `tiles_enabled_flag` is the same for all PPS activated within the CVS.

[0129] num_tile_columns_minus1+1 specifies the number of tile columns that partition the picture. num_tile_columns_minus1 is in the range of 0 to PicWidthlnCtbsY-1, including both ends. If it does not exist, the value of num_tile_columns_minus1 is assumed to be equal to 0.

[0130] num_tile_rows_minus1+1 specifies the number of tile rows that partition the picture. num_tile_rows_minus1 should be in the range of 0 to PicHeightlnCtbsY-1, including both ends. If it does not exist, the value of num_tile_rows_minus1 is assumed to be equal to 0. If tiles_enabled_flag is equal to 1, both num_tile_columns_minus1 and num_tile_rows_minus1 are assumed to be equal to 0.

[0131] A uniform_spacing_flag equal to 1 specifies that tile column boundaries and similarly tile row boundaries are uniformly distributed across the entire picture. A uniform_spacing_flag equal to 0 specifies that tile column boundaries and similarly tile row boundaries 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 it is not present, the value of uniform_spacing_flag is inferred to be equal to 1.

[0132] `column_width_minus1[i]+1` defines the width of the i-th tile column in units of the coding tree block.

[0133] row_height_minus1[i]+1 defines the height of the i-th tile row in units of the coding tree block.

[0134] As stated above, JVET-K1001 does not provide a mechanism for signaling the tile structure. This disclosure describes a technique for signaling the overall bitstream structure, including the picture header and tile set parameters.

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

[0136] The communication medium 110 may include any combination of wireless and wired communication mediums and / or storage devices. Examples of the communication medium 110 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, such as the Internet. The network may operate according to a combination of one or more telecommunications protocols. The telecommunications protocols may include proprietary forms and / or standardized telecommunications protocols. Examples of standardized telecommunications protocols include the Digital Video Broadcasting (DVB) standard, the Advanced Television Systems Committee (ATSC) standard, the Integrated Services Digital Broadcasting (ISDB) standard, the Data Over Cable Service Interface Specification (DOCSIS) standard, the Global System Mobile Communications (GSM) standard, the Code Division Multiple Access (CDMA) standard, the 3rd Generation Partnership Project (3GPP) standard, the European Telecommunications Standards Institute (ETSI) standard, the Internet Protocol (IP) standard, the Wireless Application Protocol (WAP) standard, and the Institute of Electrical and Electronics Engineers (IEEE) standard.

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

[0138] Figure 4 is a conceptual drawing showing an example of components that may be included in one implementation of System 100. In the exemplary implementation shown in Figure 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 Figure 4 represents an example of a system that may be configured to enable digital media content, such as movies and live sporting events, as well as 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 Figure 4, computing devices 402A-402N may include any devices configured to receive data from one or more of the television service network 404, the wide area network 408, and / or the local area network 410. For example, the computing devices 402A to 402N may be equipped for wired and / or wireless communication, and may be configured to receive services through one or more data channels, and may include televisions including so-called smart TVs, set-top boxes, and digital video recorders. Furthermore, the computing devices 402A to 402N may include mobile devices including desktop, laptop, or tablet computers, game consoles, e.g., "smartphones," cellular phones, and personal gaming devices.

[0139] Television service network 404 is an example of a network configured to enable the distribution 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 subscriber-based satellite television service provider network, and a public or subscriber-based cable television provider network and / or an over-the-top service provider or internet service provider. In some embodiments, television service network 404 may be used primarily to enable the provision of television services, but it should be noted that television service network 404 may also enable the provision of other types of data and services based on any combination of the telecommunications protocols described herein. Furthermore, it should be noted that in some embodiments, television service network 404 may enable bidirectional communication between a television service provider site 406 and one or more of the computing devices 402A to 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, radio transmitters and receivers, routers, switches, repeaters, base stations, or any other equipment that may be useful to facilitate communication between various devices and sites. The television service network 404 may operate according to a combination of one or more telecommunications protocols. The telecommunications protocols may include proprietary forms and / or standardized telecommunications protocols. Examples of standardized telecommunications protocols include the DVB standard, ATSC standard, ISDB standard, DTMB standard, DMB standard, Data Over Cable Service Interface Specification (DOCSIS) standard, HbbTV standard, W3C standard, and UPnP standard.

[0140] Referring again to Figure 4, the television service provider site 406 can be configured to deliver television services via the television service network 404. For example, the television service provider site 406 may include one or more broadcasters, 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, via satellite uplink / downlink. Furthermore, as shown in Figure 4, the television service provider site 406 can communicate with the wide area network 408 and can be configured to receive data from content provider sites 412A-412N. Note that in some embodiments, the television service provider site 406 may include a television studio from which content can be transmitted.

[0141] A wide area network 408 includes a packet-based network and can operate according to a combination of one or more telecommunications protocols. These telecommunications protocols may include proprietary forms and / or standardized telecommunications protocols. Examples of standardized telecommunications protocols include the Global System Mobile Communications (GSM) standard, the Code Division Multiple Access (CDMA) standard, the 3rd Generation Partnership Project (3GPP) standard, the European Telecommunications Standards Institute (ETSI) standard, European standards (EN), IP standards, the Wireless Application Protocol (WAP) standard, and Institute of Electrical and Electronics Engineers (IEEE) standards such as one or more of the IEEE 802 standards (e.g., Wi-Fi). A 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 includes a packet-based network and may 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.

[0142] Referring again to Figure 4, the content provider sites 412A-412N represent examples of sites that can provide multimedia content to the television service provider site 406 and / or computing devices 402A-402N. For example, a content provider site 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, a content provider site may be configured to provide multimedia content to a receiving device according to a Real-Time Streaming Protocol (RTSP), HTTP, etc. Furthermore, the content provider sites 412A-412N may be configured to provide data, including hypertext-based content, to one or more of the receiving devices, computing devices 402A-402N, and / or television service provider sites 406 via a wide area network 408. The content provider sites 412A-412N may include one or more web servers. The data provided by data provider sites 412A to 412N can be defined according to the data format.

[0143] Referring again to Figure 1, the source device 102 includes a video source 104, a video encoder 106, a data encapsulation device 107, and an interface 108. The video source 104 can include any device configured to capture and / or store video data. For example, the video source 104 can include a video camera and a storage device operably coupled thereto. The video encoder 106 can include any device configured to receive video data and generate a compliant bitstream representing the video data. The compliant bitstream may refer to a bitstream that a video decoder receives and from which video data can be regenerated.

[0144] The form of the compliant bitstream can be defined according to the video encoding standard. When generating a compliant bitstream, the video encoder 106 can compress the video data. The compression can be lossy (perceptible or unperceptible to the viewer) or lossy. Figure 5 is a block diagram showing an example of a video encoder 500 that can implement the techniques for encoding video data described herein. Although the example video encoder 500 is shown to have separate functional blocks, it should be noted that such examples are for illustrative purposes only and do not limit the video encoder 500 and / or its subcomponents to any particular hardware or software architecture. The functions of the video encoder 500 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0145] The video encoder 500 may perform intra-predictive coding and inter-predictive coding of picture regions and may therefore be referred to as a hybrid video encoder. In the example shown in Figure 5, the video encoder 500 receives a source video block. In some examples, the source video block may include portions of a picture that have been divided according to an coding structure. For example, the source video data may include macroblocks, CTUs, CBs, their subdivisions, and / or other equivalent coding units. In some examples, the video encoder 500 may be configured to perform additional subdivisions of the source video block. It should be noted that the techniques described herein are generally applicable to video coding regardless of how the source video data is divided before and / or during coding. In the example shown in Figure 5, the video encoder 500 includes an adder 502, a conversion coefficient generator 504, a coefficient quantization unit 506, an inverse quantization and conversion coefficient processing unit 508, an adder 510, an intra-predictive processing unit 512, an inter-predictive processing unit 514, a filter unit 516, and an entropy coding unit 518. As shown in Figure 5, the video encoder 500 receives a source video block and outputs a bitstream.

[0146] In the example shown in Figure 5, the video encoder 500 can generate residual data by subtracting a predicted video block from a source video block. The selection of the predicted video block is described in detail below. The adder 502 represents a component configured to perform this subtraction operation. In one example, the subtraction of video blocks is performed in the pixel region. The transformation coefficient generator 504 applies a transformation, such as a discrete cosine transform (DCT), a discrete sine transform (DST), or a conceptually similar transformation, to the residual block or its subdivision (for example, four 8x8 transformations can be applied to a 16x16 array of residual values) to generate a set of residual transformation coefficients. The transformation coefficient generator 504 can be configured to perform any and all combinations of transformations included in the family of discrete triangular transforms, including approximations of discrete triangular transforms. The transformation coefficient generator 504 can output the transformation coefficients to the coefficient quantizer 506. The coefficient quantizer 506 can be configured to perform quantization of the transformation coefficients. The quantization process can reduce the bit depth associated with some or all of the coefficients. Depending on the degree of quantization, the rate distortion of the encoded video data (i.e., the bitrate versus quality of the video) may change. The degree of quantization can be modified by adjusting the quantization parameter (QP). The quantization parameter can be determined based on slice level values ​​and / or CU level values ​​(e.g., CU delta QP values). The QP data may include any data used to determine the QP that quantizes a particular set of transformation coefficients. As shown in Figure 5, the quantized transformation coefficients (which may also be called level values) are output to the inverse quantization and transformation coefficient processing unit 508. The inverse quantization and transformation coefficient processing unit 508 can be configured to apply inverse quantization and inverse transformation to generate restored residual data. As shown in Figure 5, in the adder 510, the restored residual data can be added to the predicted video block. In this way, the encoded video block can be restored, and the resulting restored video block can be used to evaluate the encoding quality for a given prediction, transformation, and / or quantization.The video encoder 500 can be configured to perform multiple encoding passes (for example, performing encoding while changing one or more of the prediction, transformation, and quantization parameters). Bitstream rate distortion or other system parameters can be optimized based on the evaluation of the recovered video blocks. Furthermore, the recovered video blocks can be stored and used as references for predicting subsequent blocks.

[0147] Referring again to Figure 5, the intra-prediction processing unit 512 can be configured to select an intra-prediction mode for the video block to be encoded. The intra-prediction processing unit 512 can be configured to evaluate the frame and determine which intra-prediction mode to use in order to encode the current block. As described above, possible intra-prediction modes may include a planar prediction mode, a DC prediction mode, and an angular prediction mode. Furthermore, it should be noted that in some examples, the prediction mode for the chroma component can be inferred from the prediction mode for the luma prediction mode. The intra-prediction processing unit 512 may select an intra-prediction mode after performing one or more encoding passes. Furthermore, in one embodiment, the intra-prediction processing unit 512 may select a prediction mode based on a rate distortion path. As shown in Figure 5, the intra-prediction processing unit 512 outputs intra-prediction data (e.g., syntax elements) to the entropy encoding unit 518 and the transformation coefficient generator 504. As described above, the transformation performed on the residual data may be mode-dependent (e.g., a quadratic transformation matrix can be determined based on the prediction mode).

[0148] Referring again to Figure 5, the interprediction processing unit 514 can be configured to perform interprediction coding for the current video block. The interprediction processing unit 514 can be configured to receive a source video block and calculate the motion vector for the video block relative to the PU. The motion vector can indicate the displacement of the PU of the video block in the current video frame relative to the prediction block in the reference frame. Interprediction coding can use one or more reference pictures. Furthermore, the motion prediction can be single prediction (using one motion vector) or dual prediction (using two motion vectors). The interprediction processing unit 514 can be configured to select prediction blocks by calculating pixel differences determined, for example, by the sum of absolute difference (SAD), the sum of squared difference (SSD), or other difference measurement methods. As described above, the motion vectors can be determined and judged according to the motion vector prediction. The interprediction processing unit 514 can be configured to perform motion vector prediction as described above. The interprediction processing unit 514 can be configured to generate prediction blocks using the motion prediction data. For example, the interpretation processing unit 514 can place prediction video blocks within a frame buffer (not shown in Figure 5). Note that the interpretation processing unit 514 can be further configured to apply one or more interpolation filters to the recovered residual blocks to calculate pixel values ​​less than integers for use in motion prediction. The interpretation processing unit 514 can output motion prediction data for the calculated motion vectors to the entropy encoding unit 518.

[0149] Referring again to Figure 5, the filter unit 516 receives the reconstructed video blocks and coding parameters and outputs the modified reconstructed video data. The filter unit 516 can be configured to perform deblocking and / or Sample Adaptive Offset (SAO) filtering. SAO filtering is a nonlinear amplitude mapping that can be used to improve reconstruction by adding an offset to the reconstructed video data. Note that, as shown in Figure 5, the intra-prediction processing unit 512 and the inter-prediction processing unit 514 can receive the modified reconstructed video blocks via the filter unit 216. The entropy coding unit 518 receives the quantized transformation coefficients and prediction syntax data (i.e., intra-prediction data, motion prediction data). Note that in some examples, the coefficient quantization unit 506 can perform a scan of the matrix containing the quantized transformation coefficients before the coefficients are output to the entropy coding unit 518. In other examples, the entropy coding unit 518 can perform the scan. The entropy coding unit 518 can be configured to perform entropy coding in accordance with one or more of the techniques described herein. Thus, the video encoder 500 represents an example of a device configured to generate coded video data in accordance with one or more of the techniques of this disclosure.

[0150] Referring again to Figure 1, the data encapsulation unit 107 can receive 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 can regenerate video data from it. Furthermore, as described above, sub-bitstream extraction may refer to the process by which a device receiving an ITU-T H.265 compliant bitstream forms a new ITU-T H.265 compliant bitstream by discarding and / or modifying data in the received bitstream. Note that the term compliant bitstream may be used instead of the term compliant bitstream.

[0151] In one embodiment, the data encapsulation device 107 may be configured to generate syntax according to one or more techniques described herein. It should be noted that the data encapsulation device 107 does not need to be located in the same physical device as the video encoder 106. For example, the functions described as being performed by the video encoder 106 and the data encapsulation device 107 may be distributed between the devices shown in Figure 4.

[0152] In one embodiment, a picture may be divided into tilesets and tiles, where a tileset is a sequence of tiles and a tile is a sequence of encoded tree units. A tileset can cover a rectangular area of ​​a picture. Figure 7 shows an example of a picture divided into six tilesets. In the example shown in Figure 7, each tileset is rectangular. Each tileset may have a different number of tiles arranged in columns and rows of different numbers of tiles. In another embodiment, each tileset may have the same number of tiles. In addition, the number of tile columns and tile rows in each tileset may vary in each picture. A flag can be signaled to indicate that the number of tile columns and tile rows in each tileset is fixed in the encoded video sequence. Note that "tileset" may instead be called "slice". Therefore, the terms "tileset" or "tileset" and "slice" may be used interchangeably.

[0153] As described above, Table 4 shows the general NAL unit syntax provided in JVET-K1001. Furthermore, as mentioned above, JVET-K1001 provides a place where NAL unit types should still be defined. However, it should be noted that the document JVET-K0325, “On High Level Syntax Starting Point,” 11th Meeting of ISOTEC JTC1 / SC29 / WG11 10T8 July 2018, Ljubljana, SI, which is incorporated herein by reference and referred to as JVET-K0325, provides additional NAL unit types to JVET-K1001. In one embodiment, according to the technique described herein, the data encapsulation device 107 may be configured to signal one or more of the NAL unit types included in Table 18.

[0154] [Table 20] Regarding Table 18, the following can be defined:

[0155] Intra Random Access Point (IRAP) Picture: An encoded picture in which each VCL NAL unit has a nal_unit_type equal to IRAP_NUT.

[0156] Non-IRAP picture: An encoded picture in which each VCL NAL unit has a nal_unit_type equal to NON_IRAP_NUT.

[0157] Table 18 shows how to signal a picture header as a NAL unit. Signaling syntax parameters within the picture header and overriding them within the tileset header allows for bit savings while still supporting flexibility. In some embodiments, according to the technique herein, the same picture header may be applied to multiple pictures. This can provide additional bit savings. Having a picture header as its own NAL unit makes it easy for multiple pictures to reference the same picture header.

[0158] A tile parameter-related header may have the following characteristics: 1. It can be applied to two or more tiles, for example, a tileset or a collection of tiles, and therefore it can be a tileset header; and / or, 2. It can selectively override some of the parameters from the picture header as needed. This can be controlled by a set of presence flags within the tileset header.

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

[0160] [Table 21] In one embodiment, the following definitions of tile, tile column, tile row, and tile set may be used. Note that the words "tile set" and "tile set" are used interchangeably and may mean the same thing.

[0161] Tile: A rectangular area of ​​encoded tree blocks (CTBs) within a specific tile column and tile row in a picture.

[0162] Tile row: A rectangular area of ​​the CTB having a height equal to the height of the picture and a width specified by the syntax element in the picture parameter set.

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

[0164] A tile set is a collection of one or more tiles. In one embodiment, the tile set is rectangular in shape. A tile set may contain only an integer number of consecutive tiles. In one embodiment of a tile set, each tile must be consecutive with other tiles along a column or row dimension, or the tile set may contain only one tile.

[0165] In one embodiment, NONIRAP_NT may be an encoded non-IRAP tileset tileset_layer_rbsp(), and IRAP_NUT may be an encoded IRAP tileset tileset_layer_rbsp(). The bitstream obtained by a sub-bitstream extraction process that extracts only the data for the IRAP tileset can be decoded independently. The first picture or sub-picture of this extracted bitstream corresponding to the tileset is an IRAP picture or sub-picture.

[0166] Table 19 shows an example of the tileset_layer_rbsp() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0167] [Table 22] Table 20 shows an example of the tileset_header() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0168] [Table 23] Regarding Table 20, each syntax element may be defined as follows:

[0169] ts_pic_header_id defaults to the pic_header_id value of the picture header applied to this tileset. The value of ts_pic_header_id is between 0 and 2, including the two extreme values. 32 It must be within the range of -1.

[0170] `tile_set_id` is the default tile set identifier for this tileset.

[0171] first_tile_id specifies the TileId (tile identifier) ​​of the first tile in the tileset, which is determined by the identifier tile_set_id found in tileset_data() that follows tileset_header().

[0172] `num_tiles_in_setdata` specifies the number of tiles in the tileset, determined by the identifier `tile_set_id` found within `tileset_data()` following `tileset_header()`.

[0173] Table 21 shows an example of tileset_header() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0174] [Table 24] With respect to Table 21, each syntax element may be defined as follows:

[0175] ts_pic_header_id defaults to the pic_header_id value of the picture header applied to this tileset. The value of ts_pic_header_id is between 0 and 2, including the two extreme values. 32 It must be within the range of -1.

[0176] `first_tile_set_id` specifies the tile set identifier for the first tile set in `tileset_data()`, which follows `tileset_header()`.

[0177] num_tile_set_ids_minus1+1 specifies the number of tilesets present in the tileset_data() that follows this tileset_header().

[0178] first_tile_id_in_first_tileset specifies the TileId (tile identifier) ​​of the first tile in the first tileset, which is located within the tileset_data() that follows this tileset_header().

[0179] `num_tiles_in_setdata_in_last_tileset` specifies the number of tiles in the last tileset present in the `tileset_data()` following this `tileset_header()`.

[0180] Table 22 shows an example of the tileset_header() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0181] [Table 25] Regarding Table 22, each syntax element may be defined as follows:

[0182] `first_tile_set_id` specifies the tile set identifier for the first tile set in `tileset_data()` that follows `tileset_header()`.

[0183] num_tile_set_ids_minus1+1 specifies the number of tilesets present in the tileset_data() that follows this tileset_header().

[0184] first_tile_id_in_first_tileset specifies the TileId (tile identifier) ​​of the first tile in the first tileset, which is located within the tileset_data() that follows this tileset_header().

[0185] num_tiles_in_setdata_in_first_tileset specifies the number of tiles in the first tileset present in the tileset_data() that follows this tileset_header().

[0186] `num_tiles_in_setdata_in_last_tileset` specifies the number of tiles in the last tileset present in the `tileset_data()` following this `tileset_header()`.

[0187] Table 22A shows an example of the tileset_header() syntax that can be signaled by the data encapsulation device 107 according to the art of this specification. In this example, only the complete integer number of tilesets is included in tileset_data(). This is because fewer fiber syntax elements are required in tileset_header().

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

[0189] `first_tile_set_id` specifies the tile set identifier for the first tile set in `tileset_data()`, which follows `tileset_header()`.

[0190] num_tile_set_ids_minus1+1 specifies the number of tilesets present in the tileset_data() that follows this tileset_header().

[0191] Table 23 shows an example of the tileset_coding_parameters() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0192] [Table 27] Regarding Table 23, each syntax element may be defined as follows:

[0193] A tileset_log2_diff_ctu_max_bt_size_present_flag equal to 1 defaults to the existence of tileset_log2_diff_ctu_max_bt_size. A tileset_log2_diff_ctu_max_bt_size_present_flag equal to 0 defaults to the absence of tileset_log2_diff_ctu_max_bt_size. If it does not exist, 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 the ts_pic_header_id of this tileset_header() active for this tileset.

[0194] `tileset_log2_diff_ctu_max_bt_size` defines the difference between the luma CTB size and the maximum luma size (width or height) of an encoded block that can be partitioned using the binary partitioning of this tileset. The semantics of `log2_diff_ctu_max_bt_size` apply to non-tilesets as well.

[0195] A tileset_sbtmvp_size_override_flag_present_flag equal to 1 stipulates that tileset_sbtmvp_size_override_flag exists, and if tileset_sbtmvp_size_override_flag is equal to 1, then log2_tileset_sbtmvp_active_size_minus2 also exists. A tileset_sbtmvp_size_override_flag_present_flag equal to 0 stipulates that neither tileset_sbtmvp_size_override_flag nor log2_tileset_sbtmvp_active_size_minus2 exists. If they do not exist, tileset_sbtmvp_size_override_flag_present_flag and log2_tileset_sbtmvp_active_size_minus2 are presumed to be equal to sbtmvp_size_override_flag and log2_sbtmvp_active_size_minus2 from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() that is active for this tileset, respectively.

[0196] A tileset_sbtmvp_size_override_flag equal to 1 specifies that the syntax element log2_tileset_sbtmvp_active_size_minus2 exists for the current tileset. A sbtmvp_size_override_flag equal to 0 specifies that the syntax element log2_tileset_sbtmvp_active_size_minus2 does not exist and specifies that log2_tileset_sbtmvp_size_active_minus2 is inferred to be equal to log2_sbtmvp_size_active_minus2.

[0197] 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 tileset. If log2_tileset_sbtmvp_size_active_minus2 does not exist, it is inferred to be equal to log2_sbtmvp_size_active_minus2. The variable is derived as follows:

[0198] Log2SbtmvpSize=log2_tileset_sbtmvp_size_active_minus2+2 A tileset_tmvp_info_present_flag equal to 1 defaults to the possibility of the presence of tileset_temporal_mvp_enabled_flag, tileset_mvd_l1_zero_flag, and tileset_collocated_from_10_flag. A tileset_tmvp_info_present_flag equal to 0 defaults to the absence of tileset_temporal_mvp_enabed_flag, tileset_mvd_l1_zero_flag, and tileset_collocated_from_10_flag. If they do not exist, tileset_temporal_mvp_enabled_flag, tileset_mvd_l1_zero_flag, and tileset_collocated_from_10_flag are presumed to be equal to pic_temporal_mvp_enabed_flag, mvd_l1_zero_flag, and collocated_from_10_flag from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() that is active for this tileset, respectively.

[0199] The tileset_temporal_mvp_enabled_flag determines whether time-motion vector predictors can be used for interpretation of the current tileset. If tileset_temporal_mvp_enabled_flag is equal to 0, the syntax elements of the current tileset are constrained so that time-motion vector predictors cannot be used for decoding the current tileset. Otherwise (tileset_temporal_mvp_enabled_flag is equal to 1), time-motion vector predictors can be used for decoding the current tileset. If it does not exist, the value of tileset_temporal_mvp_enabled_flag is inferred to be equal to the pic_header() structure corresponding to the ts_pic_header_id of the tileset_header() for this tileset, which is active for this tileset.

[0200] A 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 to 0 for compIdx=0~1. A tileset_mvd_l1_zero_flag equal to 0 indicates that the mvd_coding(x0,y0,1) syntax structure is parsed for the current tileset.

[0201] A tileset_collocated_from_10_flag equal to 1 defaults to the current tileset being derived from reference picture list 0 for the collocated picture used for time motion vector prediction. A tileset_collocated_from_10_flag equal to 0 defaults to the current tileset being derived from reference picture list 1 for the collocated picture used for time motion vector prediction. If tileset_collocated_from_10_flag does not exist, 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.

[0202] A tileset_six_minus_max_num_merge_present_flag equal to 1 defaults to the existence of tileset_six_minus_max_num_merge_cand. A tileset_six_minus_max_num_merge_present_flag equal to 0 defaults to the absence of tileset_six_minus_max_num_merge_cand. If it does not exist, tileset_six_minus_max_num_merge_cand is presumed to be equal to the six_minus_max_num_merge_cand from the pic_header() structure corresponding to the ts_pic_header_id of this tileset_header() active for this tileset.

[0203] `tileset_six_minus_max_num_merge_cand` specifies the maximum number of Merge Motion Vector Prediction (MVP) candidates supported in the current tileset, which is subtracted from 6. The maximum number of merge MVP candidates, `MaxNumMergeCand`, is derived as follows:

[0204]

number

[0205] A tileset_dep_quant_info_present_flag equal to 1 defaults to the existence of tileset_dep_quant_enabled_flag. A tileset_dep_quant_info_present_flag equal to 0 defaults to the absence of tileset_dep_quant_enabled_flag. If it does not exist, 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.

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

[0207] 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 does not exist, 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.

[0208] Table 24 shows an example of the tileset_data() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0209] [Table 28] Regarding Table 24, each syntax element may be defined as follows:

[0210] An end_of_tileset_flag equal to 0 defaults to another CTU continuing within the tileset. An end_of_tileset_flag equal to 1 defaults to the end of the tileset slice, i.e., no further CTUs continuing within the tileset.

[0211] Table 25 shows an example of the rbsp_tileset_trailing_bits() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0212] [Table 29] Table 26 shows an example of pic_header_rbsp() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0213] [Table 30] Table 27 shows an example of pic_header() syntax that can be signaled by the data encapsulation device 107 according to the technology of this specification.

[0214] [Table 31] Regarding Table 24, each syntax element may be defined as follows:

[0215] pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id should be in the range of 0 to 63, including both endpoints.

[0216] pic_header_id identifies the picture header for reference by other syntax elements. The value of pps_pic_parameter_set_id is between 0 and 2, including both end values. 32 It is assumed to be within the range of -1.

[0217] `picture_type` indicates the encoding type of the picture according to Table 28. The value of `pic_type` shall be equal to 0, 1, or 2 in a bitstream conforming to this version of this specification. Other values ​​for `pic_type` are reserved for future use. Decoders conforming to this version of this specification shall ignore the reserve values ​​for `pic_type`.

[0218] [Table 32] log2_diff_ctu_max_bt_size defines the difference between the luma CTB size and the maximum luma size (width or height) of an encoded block that can be partitioned using binary partitioning.

[0219] A sbtmvp_size_override_flag equal to 1 defaults to the existence of the syntax element log2_sbtmvp_active_size_minus2 for the current slice, while a sbtmvp_size_override_flag equal to 0 defaults to the absence of the syntax element log2_atmvp_active_size_minus2 and the assumption that log2_sbtmvp_size_active_minus2 is equal to log2_sbtmvp_default_size_minus2.

[0220] log2_sbtmvp_active_size_minus2+2 defaults to the subblock size value used to derive the subblock-based TMVP motion parameters for the current slice. If log2_sbtmvp_size_active_minus2 does not exist, it is inferred to be equal to log2_sbtmvp_default_size_minus2. The variable is derived as follows:

[0221] Log2SbtmvpSize=log2_sbtmvp_size_active_minus2+2 The `pic_temporal_mvp_enabled_flag` flag determines whether the time-motion vector predictor can be used for interpretation of the current picture. If `pic_temporal_mvp_enabled_flag` is equal to 0, the syntax elements of the current picture are constrained so that the time-motion vector predictor cannot be used for decoding the current picture. Otherwise (if `pic_temporal_mvp_enabled_flag` is equal to 1), the time-motion vector predictor can be used for decoding the current picture. If it is not present, the value of `pic_temporal_mvp_enabled_flag` is presumed to be equal to 0.

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

[0223] The collocated_from_10_flag equal to 1 defaults that the collocated picture used for temporal motion vector prediction is derived from reference picture list 0. The collocated_from_10_flag equal to 0 defaults that the collocated picture used for temporal motion vector prediction is derived from reference picture list 1. If the collocated_from_10_flag does not exist, it is assumed to be equal to 1.

[0224] six_minus_max_num_merge_cand defaults the maximum number of merge motion vector prediction (MVP) candidates supported within a slice that is subtracted from 6. The maximum number of merge MVP candidates, MaxNumMergeCand, is derived as follows.

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

[0226] The dep_quant_enabled_flag equal to 0 defaults that dependent quantization is disabled. The dep_quant_enabled_flag equal to 1 defaults that dependent quantization is enabled.

[0227] A sign_data_hiding_enabled_flag equal to 0 defaults to sign bit hiding being disabled. A sign_data_hiding_enabled_flag equal to 1 defaults to sign bit hiding being enabled. If the sign_data_hiding_enabled_flag does not exist, it is presumed to be equal to 0.

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

[0229] Table 29 shows an example of the rbsp_pic_header_trailing_bits() syntax that may be signaled by the data encapsulation device 107 according to the techniques herein.

[0230] [Table 33] Note that in some embodiments, the picture header can be applied to one or more pictures. Further, in some embodiments, parameters within the picture header can be overwritten for a tile set according to tile set parameters. In some exemplary cases, specific restrictions may apply to overwrite parameters within the picture header for a tile set.

[0231] As described above, in ITU-T H.265, some or all of the tile structure, i.e., one or more tile and / or tileset-related parameters relating to a picture, are signaled using a picture parameter set. In one embodiment, according to the art herein, the tile structure may be signaled within a picture parameter set, which is identified in picture_header() as provided above. In another embodiment, some or all of the tile structure, i.e., one or more tile and / or tileset-related parameters, may be signaled within a sequence parameter set (SPS).

[0232] In this way, source device 102 represents an example of a device configured to signal values ​​for syntax elements within a network abstraction layer unit, indicating that the tileset layer syntax structure is included in the network abstraction layer unit, and to signal values ​​for one or more tileset parameters included in the tileset layer syntax structure.

[0233] Referring again to Figure 1, interface 108 may include any device configured to receive data generated by the data encapsulation unit 107 and transmit and / or store that data in a communication medium. Interface 108 may include a network interface card such as an Ethernet card, and may include an optical transceiver, a radio frequency transceiver, or any other type of device capable of transmitting and / or receiving information. Furthermore, interface 108 may include a computer system interface that can enable the storage of files on a storage device. For example, interface 108 may include Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) bus protocols, proprietary bus protocols, Universal Serial Bus (USB) protocol, and I2 The chipset may include support for C, or any other logical and physical structures that can be used to interconnect peer devices.

[0234] Referring again to Figure 1, the target device 120 includes an interface 122, a data deencapsulation device 123, a video decoder 124, and a display 126. Interface 122 can include any device configured to receive data from a communication medium. Interface 122 can include a network interface card such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device capable of receiving and / or transmitting information. Furthermore, interface 122 can include an interface for a computer system that enables the acquisition of a compliant video bitstream from a storage device. For example, interface 122 can support PCI and PCIe bus protocols, proprietary bus protocols, USB protocols, etc. 2 The chipset may include C, or any other logical and physical structures that can be used to interconnect peer devices. The data deencapsulation device 123 may be configured to receive and parse any of the exemplary syntax structures described herein.

[0235] The video decoder 124 may include any device configured to receive a bitstream (e.g., MCTS subbitstream extraction) and / or an acceptable variation thereof, and to regenerate video data therefrom. The display 126 may include any device configured to display the video data. The display 126 may include one of various display devices, such as a liquid crystal display (LCD), plasma display, organic light-emitting diode (OLED) display, or another type of display. The display 126 may include a high-resolution display or an ultra-high-resolution display. In the example shown in Figure 1, the video decoder 124 is described as outputting data to the display 126, but it should be noted that the video decoder 124 can be configured to output video data to various types of devices and / or their subcomponents. For example, the video decoder 124 may be configured to output video data to any communication medium as described herein.

[0236] Figure 6 is a block diagram showing an example of a video decoder that can be configured to decode video data using one or more of the techniques of this disclosure. In one embodiment, the video decoder 600 may be configured to decode transformed data and to reconstruct residual data from transformed coefficients based on the decoded transformed data. The video decoder 600 may be configured to perform intra-predictive decoding and inter-predictive decoding, and for that purpose may be referred to as a hybrid decoder. The video decoder 600 may be configured to parse any combination of syntax elements listed in Tables 1 to 27 above. The video decoder 600 can perform video decoding based on the values ​​of the parsed syntax elements. For example, different video decoding techniques may be performed based on whether the picture is of a particular type.

[0237] In the example shown in Figure 6, the video decoder 600 includes an entropy decoding unit 602, an inverse quantization unit and conversion coefficient processing unit 604, an intra-prediction processing unit 606, an inter-prediction processing unit 608, an adder 610, a post-filter unit 612, and a reference buffer 614. The video decoder 600 can be configured to decode video data in accordance with a video coding system. Although the example video decoder 600 is shown to have separate functional blocks, such examples are for illustrative purposes only and should not be used to limit the video decoder 600 and / or its sub-components to any particular hardware or software architecture. The functionality of the video decoder 600 can be implemented using any combination of hardware, firmware, and / or software implementations.

[0238] As shown in Figure 6, the entropy decoding unit 602 receives the entropy-encoded bitstream. The entropy decoding unit 602 can be configured to decode syntax elements and quantized coefficients from the bitstream according to a reciprocal process, the reverse of the entropy encoding process. The entropy decoding unit 602 can be configured to perform entropy decoding according to any of the entropy encoding techniques described above. The entropy decoding unit 602 can determine the values ​​of syntax elements in the encoded bitstream in accordance with a video encoding standard. As shown in Figure 6, the entropy decoding unit 602 can determine quantization parameters, quantized coefficient values, transformation data, and prediction data from the bitstream. In the embodiment shown in Figure 6, the inverse quantization unit and transformation coefficient processing unit 604 receive quantization parameters, quantized coefficient values, transformation data, and prediction data from the entropy decoding unit 602 and output the recovered residual data.

[0239] Referring again to Figure 6, the recovered residual data may be provided to the adder 610, which can add the recovered residual data to a prediction video block to generate the recovered video data. The prediction video block can be determined according to prediction video techniques (i.e., intra-prediction and inter-frame prediction). The intra-prediction processing unit 606 may be configured to receive an intra-prediction syntax element and retrieve a prediction 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 mode described above. The inter-prediction processing unit 608 may receive an inter-prediction syntax element, generate a motion vector, and identify a prediction block in one or more reference frames stored in the reference buffer 616. The inter-prediction processing unit 608 may optionally perform interpolation based on an interpolation filter to generate a motion-compensated block. The syntax element may include an identifier for an interpolation filter that will be used for motion prediction with sub-pixel accuracy. The interpretation processing unit 608 can use an interpolation filter to calculate interpolated values ​​for sub-integer pixels of the reference block. The post-filter unit 614 can be configured to perform filtering on the restored video data. For example, the post-filter unit 614 can be configured to perform deblocking and / or sample-adaptive offset (SAO) filtering based on parameters defined in the bitstream. Furthermore, it should be noted that in some examples, the post-filter unit 614 can be configured to perform its own arbitrary filtering (e.g., visual enhancement such as mosquito noise reduction). As shown in Figure 6, the restored video blocks can be output by the video decoder 600.In this way, the video decoder 600 represents an example of a device configured to parse values ​​for syntax elements within a network abstraction layer unit, indicating that the tileset layer syntax structure is contained within the network abstraction layer unit; parse values ​​for one or more tileset parameters contained within the tileset layer syntax structure; and generate video data based on the parsed values ​​for one or more tileset parameters.

[0240] In one or more examples, the described functions can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions can be stored or transmitted as one or more instructions or codes on a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium can include computer-readable storage media corresponding to tangible media such as data storage media or communication media, including any medium that facilitates the transfer of computer programs from one place to another according to a communication protocol. In this way, the computer-readable medium can generally correspond to (1) non-temporary tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. The data storage medium can be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes, and / or data structures for implementing the technology described in this disclosure. Computer program products can include computer-readable media.

[0241] For example, non-limitingly, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage devices, magnetic disk storage devices, other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and that are accessible by a computer. Also, any connection is appropriately called 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, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. However, it should be understood that computer-readable media and data storage media do not include connections, carriers, signals, or other transient media, but instead refer to non-transient tangible storage media. In the present invention, "disk" and "disc" include Compact Disc (CD), Laser Disc, Optical Disc, Digital Versatile Disc (DVD), Floppy Disc, and Blu-ray® Disc, where a disk typically reproduces data magnetically, and a disc reproduces data optically using a laser. The above combinations must also fall within the range of computer-readable media.

[0242] Instructions can be executed by one or more processors, such as 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. Therefore, as used herein, the term “processor” may refer to any of the aforementioned structures or any other structure suitable for implementing the technology described herein. In addition, in some embodiments, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a composite codec. Furthermore, this technology can be fully implemented within one or more circuits or logic elements.

[0243] The technology disclosed herein can be implemented in a wide variety of devices or apparatus, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). While various components, modules, or units are shown in this disclosure to highlight functional aspects of devices configured to perform the disclosed technology, it is not necessarily required that they be implemented by different hardware units. Rather, as stated above, the various units may be combined with a codec hardware unit, or provided by a set of interoperable hardware units, including one or more of the aforementioned processors, along with suitable software and / or firmware.

[0244] Furthermore, the functional blocks and various functions of the base station equipment and terminal equipment used in each of the above-described implementations can generally be realized or executed by an integrated circuit or an electrical circuit which is a combination of integrated circuits. Circuits 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 gates 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 consist of digital circuits or analog circuits. Furthermore, if advances in semiconductor technology lead to the emergence of integrated circuit technologies that replace current integrated circuits, integrated circuits using these technologies will also become available.

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

[0246] In one embodiment, a method for signaling tileset parameters includes signaling values ​​for syntax elements within a network abstraction layer unit to indicate that the tileset layer syntax structure is included in the network abstraction layer unit, and signaling values ​​for one or more tileset parameters included in the tileset layer syntax structure.

[0247] In one embodiment, a method for decrypting video data includes parsing a value for a syntax element in a network abstraction layer unit that indicates that a tile set layer syntax structure is included in the network abstraction layer unit, parsing a value 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] <Cross-reference> This application is a new divisional application based on Japanese Patent Application No. 2024-193482 (hereinafter referred to as the “’482 application”), which is further a divisional application based on Japanese Patent Application No. 2021-515669 (hereinafter referred to as the “’669 application”). Further, the ’669 application claims the priority of Provisional Application No. 62 / 734,232 filed on September 20, 2018 under 35 U.S.C. § 119, and the entire content thereof is incorporated herein by reference.

Claims

1. A method for decrypting slice information for decoding video data, comprising the following steps: A step of receiving a slice header syntax structure corresponding to a slice of the video data, wherein the slice includes an integer number of tiles; A step of parsing a first syntax element that identifies the number of tiles in the slice from the slice header syntax structure, wherein the slice header syntax structure is included in a slice layer syntax structure, and the slice layer syntax structure includes a slice trailing bit syntax structure that includes cabac_zero_word; and A step of conditionally parsing from the slice header syntax structure a second syntax element that identifies a list of reference images for collated images for time motion vector prediction, based on whether or not a time motion vector predictor is available.

2. A step of receiving a picture header syntax structure corresponding to an image including the slice of the video data; A step of parsing a third syntax element from the picture header syntax structure that indicates whether or not the time motion vector prediction is enabled in the aforementioned image; and The step of parsing from the picture header syntax structure a fourth syntax element indicating a list of reference images for the collated image for the time motion vector prediction, based on whether the time motion vector predictor is available; If the second syntax element is not present, it is assumed that the second syntax element is equivalent to the fourth syntax element. The method according to claim 1.

3. A method for encoding slice information to generate video data, comprising the following steps: A step of determining a slice header syntax structure corresponding to a slice of video data, wherein the slice includes an integer number of tiles; A step of encoding a first syntax element that identifies the number of tiles in the slice into the slice header syntax structure, wherein the slice header syntax structure is included in a slice layer syntax structure, and the slice layer syntax structure includes a slice trailing bit syntax structure that includes cabac_zero_word; and A step of conditionally encoding a second syntax element within the slice header syntax structure that identifies a list of reference images for collated images for time motion vector prediction, based on whether or not a time motion vector predictor is available.

4. A non-temporary computer-readable recording medium for storing video data, The aforementioned video data is decoded by a method for decoding slice information. The above method is characterized by comprising the following steps, and is a recording medium: A step of receiving a slice header syntax structure corresponding to a slice of the video data, wherein the slice includes an integer number of tiles; A step of parsing a first syntax element that identifies the number of tiles in the slice from the slice header syntax structure, wherein the slice header syntax structure is included in a slice layer syntax structure, and the slice layer syntax structure includes a slice trailing bit syntax structure that includes cabac_zero_word; and A step of conditionally parsing from the slice header syntax structure a second syntax element that identifies a list of reference images for collated images for time motion vector prediction, based on whether or not a time motion vector predictor is available.

Images