JP7281890B2 - Video encoding device and video decoding device - Google Patents

Description

TECHNICAL FIELD Embodiments of the present invention relate to a moving image decoding device and a moving image encoding device.

A moving image encoding device that generates encoded data by encoding a moving image and a moving image that generates a decoded image by decoding the encoded data in order to efficiently transmit or record the moving image An image decoding device is used.

Examples of specific moving image coding methods include methods proposed in H.264/AVC and HEVC (High-Efficiency Video Coding).

In such a video coding method, the images (pictures) that make up the video are divided into slices obtained by dividing the image, and coding tree units (CTU: Coding Tree Units) obtained by dividing the slices. ), a coding unit obtained by dividing the coding tree unit (also called a coding unit (CU)), and a transform unit obtained by dividing the coding unit (TU: Transform Unit), and encoded/decoded for each CU.

Further, in such a video encoding method, a predicted image is normally generated based on a locally decoded image obtained by encoding/decoding an input image, and the predicted image is generated from the input image (original image). The prediction error obtained by subtraction (sometimes called the "difference image" or "residual image") is encoded. Inter-prediction and intra-prediction are methods for generating predicted images.

As a method of dividing a screen into a plurality of units and performing parallel processing, a method of dividing into slices, CTU lines (wavefront segments), and tiles is known. Conventionally, the method of dividing into tiles was limited to dividing into CTU units.

In addition, Non-Patent Document 1 can be cited as a technique of video encoding and decoding in recent years.

"Algorithm Description of Joint Exploration Test Model 7", JVET-G1001, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, 2017-08-19

As explained above, there is a limit that the tile size is an integer multiple of the CTU, and it is possible to divide it into equal sizes for load balancing and configure tiles that match the face size of the 360-degree video. There is a difficult issue.

Also, if the tile size is not limited to an integer multiple of the CTU size, referencing the motion vector of the reference picture for temporal motion vector referencing may result in referencing motion vectors from many positions across the CTU boundary. There is a problem that there is

Also, if the tile size is not limited to an integral multiple of the CTU size, there is a problem that multiple lines may be referenced across the CTU boundary in multiline intra prediction.

Therefore, the present invention has been made in view of the above problems, and its object is to provide tile division, efficient temporal motion vector reference, and multi-line intra prediction without restrictions on integral multiples of CTU. be.

A video decoding device according to an aspect of the present invention includes a header information decoding unit that decodes a tile size that is an integer multiple of a tile unit size, and a quadtree, binary tree, and ternary tree using the in-picture coordinates and the tile size. The CT partitioning unit that performs multi-tree partitioning of the tree compares the in-picture coordinates yColBrInPic of the reference block with the virtual CTU coordinates yVirCtbB derived from the in-picture coordinates of the target picture to determine the referability of the reference block. It is characterized by comprising a temporal motion prediction unit that derives a motion vector. Also, a header information decoding unit that decodes a tile size that is an integer multiple of the tile unit size, and a CT division unit that performs multi-tree division of a quadtree, a binary tree, and a ternary tree using the in-picture coordinates and the tile size. and an intra-prediction unit that converts intra-picture coordinates to intra-tile coordinates and determines CTU boundaries.

FIG. 3 is a diagram showing the hierarchical structure of data in an encoded stream; FIG. 4 is a diagram showing an example of CTU division; It is a figure explaining a tile. It is a syntax table regarding tile information and the like. 1 is a schematic diagram showing the configuration of a video decoding device; FIG. 4 is a flowchart for explaining schematic operations of a video decoding device; 4 is a flowchart for explaining the operation of a CT information decoding unit; FIG. 4 is a diagram showing a configuration example of a syntax table of CTU and QT information; FIG. 4 is a diagram showing a configuration example of a syntax table of MT (Multi Tree) information; FIG. 4 is a diagram showing a configuration example of a syntax table of MT (Multi Tree) information; FIG. 10 is a diagram for explaining tile division in a non-CTU size; FIG. 10 is a diagram for explaining tile division in a non-CTU size; It is a syntax configuration of encoded slice data. FIG. 10 is a diagram showing a reference range when referring to motion vectors of reference pictures while performing virtual CTU line restriction; FIG. 10 is a flowchart when referring to a motion vector of a reference picture while performing virtual CTU line restriction; FIG. FIG. 10 is a diagram showing a reference range when referring to motion vectors of reference pictures while performing virtual CTU line restriction; FIG. 10 is a flowchart when referring to a motion vector of a reference picture while performing virtual CTU line restriction; FIG. FIG. 4 is a diagram showing reference positions of reference pictures in temporal motion derivation (temporal motion vector derivation); It is a block diagram which shows the structure of a video encoding apparatus. 1 is a diagram showing the configuration of a transmitting device equipped with a moving image encoding device and a receiving device equipped with a moving image decoding device according to an embodiment; FIG. (a) shows a transmitting device equipped with a moving image encoding device, and (b) shows a receiving device equipped with a moving image decoding device. 1 is a diagram showing configurations of a recording device equipped with a moving image encoding device and a reproducing device equipped with a moving image decoding device according to an embodiment; FIG. (a) shows a recording device equipped with a moving image encoding device, and (b) shows a reproducing device equipped with a moving image decoding device. 1 is a schematic diagram showing the configuration of an image transmission system according to this embodiment; FIG. FIG. 11 is another example of a syntax table for tile information, etc. FIG. FIG. 11 is another example of a syntax table for tile information, etc. FIG. FIG. 11 is another example of a syntax table for tile information, etc. FIG. FIG. 11 is another example of a syntax table for tile information, etc. FIG. FIG. 4 is a diagram showing a syntax configuration example of encoded slice data and CTU information; FIG. 4 is a diagram showing a configuration example of a syntax table of QT information; FIG. 10 is a diagram showing a configuration example of a syntax table of MT information; FIG. 10 is a diagram showing a syntax configuration example of CTU information; It is a syntax configuration of encoded tile data. FIG. 4 is a diagram showing a configuration example of a syntax table of CTU and QT information; FIG. 4 is a diagram showing a configuration example of a syntax table of MT (Multi Tree) information; FIG. 4 is a diagram showing a configuration example of a syntax table of CTU and QT information; FIG. 4 is a diagram for explaining the operation of determining intra reference lines according to CTU boundaries within a tile in multiline intra prediction; FIG. 10 is a flowchart for explaining the operation of determining intra reference lines according to CTU boundaries within a tile in multiline intra prediction; FIG. FIG. 10 is a flowchart for explaining the operation of determining intra reference lines according to CTU boundaries within a tile in multiline intra prediction; FIG. FIG. 4 is a schematic diagram showing the configuration of a merge prediction parameter deriving unit; FIG. 10 is a diagram illustrating an example of processing for referring to a motion vector in a reference picture as a temporal motion vector; FIG. 10 is a diagram showing the relationship between a target CTU and a motion vector reference range when a reference picture and a target picture are divided into the same tiles; It is a figure which shows the syntax structure in multi-line intra prediction. 10 is a flowchart showing MPM derivation processing when dividing a picture into tiles of sizes not limited to integral multiples of CTU; 10 is a flowchart showing MPM derivation processing when dividing a picture into tiles of sizes not limited to integral multiples of CTU;

(First embodiment)
Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 22 is a schematic diagram showing the configuration of the image transmission system 1 according to this embodiment.

The image transmission system 1 is a system that transmits an encoded stream obtained by encoding an encoding target image, decodes the transmitted encoded stream, and displays the image. The image transmission system 1 includes a moving image coding device (image coding device) 11, a network 21, a moving image decoding device (image decoding device) 31, and a moving image display device (image display device) 41. .

An image T is input to the moving image encoding device 11 .

The network 21 transmits the encoded stream Te generated by the video encoding device 11 to the video decoding device 31 . The network 21 is the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), or a combination thereof. The network 21 is not necessarily a two-way communication network, and may be a one-way communication network that transmits broadcast waves such as terrestrial digital broadcasting and satellite broadcasting. Also, the network 21 may be replaced by a storage medium such as a DVD (Digital Versatile Disc: registered trademark) or a BD (Blue-ray Disc: registered trademark) that records the encoded stream Te.

The moving image decoding device 31 decodes each of the encoded streams Te transmitted by the network 21 and generates one or more decoded images Td.

The moving image display device 41 displays all or part of one or more decoded images Td generated by the moving image decoding device 31 . The moving image display device 41 includes, for example, a display device such as a liquid crystal display or an organic EL (Electro-luminescence) display. The form of the display includes stationary, mobile, HMD, and the like. In addition, when the moving image decoding device 31 has high processing power, it displays an image with high image quality, and when it has only lower processing power, it displays an image that does not require high processing power and display power. .

<operator>
The operators used in this specification are described below.

>> is a right bit shift, << is a left bit shift, & is a bitwise AND, | is a bitwise OR, |= is an OR assignment operator, and || indicates a logical sum.

x?y:z is a ternary operator that takes y if x is true (not 0) and z if x is false (0).

! indicates an operation that converts 0 to 1 and anything other than 0 to 0.

Clip3(a,b,c) is a function that clips c to values greater than or equal to a and less than or equal to b, if c<a returns a, if c>b returns b, otherwise is a function that returns c (where a<=b).

abs(a) is a function that returns the absolute value of a.

Int(a) is a function that returns the integer value of a.

floor(a) is a function that returns the largest integer less than or equal to a.

ceil(a) is a function that returns the largest integer greater than or equal to a.

a/d represents division of a by d (truncated after the decimal point).

<Structure of encoded stream Te>
Prior to a detailed description of the video encoding device 11 and the video decoding device 31 according to the present embodiment, data of the encoded stream Te generated by the video encoding device 11 and decoded by the video decoding device 31 I will explain the structure.

FIG. 1 is a diagram showing the hierarchical structure of data in an encoded stream Te. The encoded stream Te illustratively includes a sequence and a plurality of pictures that constitute the sequence. (a) to (f) of FIG. 1 respectively show a coded video sequence that defines a sequence SEQ, a coded picture that defines a picture PICT, a coded slice that defines a slice S, and a coded slice that defines slice data. FIG. 3 is a diagram showing data, a coding tree unit included in the coded slice data, and a coding unit included in the coding tree unit;

(encoded video sequence)
The encoded video sequence defines a set of data that the video decoding device 31 refers to in order to decode the sequence SEQ to be processed. A sequence SEQ consists of a video parameter set and a sequence parameter set SPS, as shown in Fig. 1(a).
(Sequence Parameter Set), picture parameter set PPS (Picture Parameter Set), picture PICT, and supplemental enhancement information SEI (Supplemental Enhancement Information).

A video parameter set VPS is a set of coding parameters common to multiple video images, multiple layers included in the video image, and coding parameters related to individual layers. Sets are defined.

The sequence parameter set SPS defines a set of coding parameters that the video decoding device 31 refers to in order to decode the target sequence. For example, the width and height of the picture are defined. A plurality of SPSs may exist. In that case, one of a plurality of SPSs is selected from the PPS.

The picture parameter set PPS defines a set of coding parameters that the video decoding device 31 refers to in order to decode each picture in the target sequence. For example, it includes a quantization width reference value (pic_init_qp_minus26) used for picture decoding and a flag (weighted_pred_flag) indicating application of weighted prediction. A plurality of PPSs may exist. In that case, one of a plurality of PPSs is selected from each picture in the target sequence.

(coded picture)
The encoded picture defines a set of data that the video decoding device 31 refers to in order to decode the picture PICT to be processed. A picture PICT includes slices 0 to NS-1 (NS is the total number of slices included in the picture PICT), as shown in FIG. 1(b).

In the following description, if there is no need to distinguish between slices 0 to NS-1, the suffixes may be omitted. The same applies to other data with subscripts that are included in the encoded stream Te described below.

(coded slice)
The encoded slice defines a set of data that the video decoding device 31 refers to in order to decode the slice S to be processed. A slice includes a slice header and slice data, as shown in FIG. 1(c).

The slice header includes a coding parameter group that the video decoding device 31 refers to in order to determine the decoding method for the target slice. Slice type designation information (slice_type) that designates a slice type is an example of a coding parameter included in a slice header.

Slice types that can be specified by the slice type specifying information include (1) I slices that use only intra prediction during encoding, (2) P slices that use unidirectional prediction or intra prediction during encoding, (3) B slices using uni-prediction, bi-prediction, or intra-prediction during encoding. Note that inter prediction is not limited to uni-prediction and bi-prediction, and a predicted image may be generated using more reference pictures. Hereinafter, when referred to as P and B slices, they refer to slices containing blocks for which inter prediction can be used.

Note that the slice header may include a reference (pic_parameter_set_id) to the picture parameter set PPS.

(encoded slice data)
For encoded slice data, a video decoding device is used to decode slice data to be processed.
A set of data referenced by 31 is defined. The slice data includes CTU, as shown in FIG. 1(d). A CTU is a block of a fixed size (for example, 128x128) that forms a slice, and is also called a Largest Coding Unit (LCU).

(tile)
FIG. 3A is a diagram showing an example in which a picture is divided into N tiles (rectangles with solid lines; the figure shows an example of N=9). The tile is further divided into multiple CTUs (dashed rectangles). As shown in the center of FIG. 3(a), the upper left coordinate of the tile is (xTile, yTile), the width is wTile, and the height is hTile. Also, the width of the picture is described as wPict, and the height as hPict. Information about the number of tile divisions and size is called tile information, and the details will be described later. The units of xTile, yTile, wTile, hTile, wPict, and hPict are pixels. For the width and height of the picture, pic_width_in_luma_samples and pic_height_in_luma_samples notified by sequence_parameter_set_rbsp() (referred to as SPS) shown in FIG. 4(a) are set.

wPict = pic_width_in_luma_samples
hPict = pic_height_in_luma_samples
FIG. 3(b) is a diagram showing the encoding and decoding order of CTUs when a picture is divided into tiles. The number described in each tile is TileId (identifier of the tile within the picture), and the number TileId may be assigned to the tiles within the picture in raster scan order from top left to bottom right. Also, CTUs are processed within each tile in raster scan order from upper left to lower right, and when processing within one tile is completed, CTUs within the next tile are processed.

FIG. 3(c) is a diagram showing tiles that are continuous in the time direction. As shown in FIG. 3(c), a video sequence is composed of a plurality of pictures that are continuous in the time direction. A tile sequence is composed of one or more time tiles that are consecutive in the time direction. Tile(n, tk) of w in the figure represents a tile of TileId=n at time tk. Note that a CVS (Coded Video Sequence) in the figure is a group of pictures from an intra picture to the picture immediately preceding another intra picture in decoding order.

FIG. 4 is an example of syntax related to tile information and the like.

The PPS (pic_parameter_set_rbsp()) shown in FIG. 4(b) notifies the parameter tile_parameters() regarding the tile. Hereinafter, to notify a parameter means to include the parameter in the encoded data (bitstream). The video encoding device encodes the parameter, and the video decoding device decodes the parameter. As shown in FIG. 4(c), tile information tile_info() is notified to tile_parameters() when tile_enabled_flag indicating whether or not a tile exists is 1. Also, when tile_enabled_flag is 1, an independent_tiles_flag (independent_decoding_tile_flag) indicating whether tiles can be decoded independently over a plurality of temporally consecutive pictures is notified. If independent_tiles_flag is 0, tiles are decoded with reference to adjacent tiles in the reference picture (cannot be decoded independently). If independent_tiles_flag is 1, decode without referring to adjacent tiles in the reference picture. When using tiles, decoding is performed without referring to adjacent tiles in the current picture regardless of the value of independent_tiles_flag, so multiple tiles can be decoded in parallel. This independent_tiles_flag flag may be a flag independent_decoding_picture_region_flag for each region such as each tile group or each tile. Although independent_tiles_flag is 1 for independent (no inter-picture reference) and 0 for dependent (with inter-picture reference), 0 and 1 may be reversed. For example, the tile-in-picture referable flag tile_inpicture_ref_enabled_flag may be a flag that is independent when 0 and dependent when 1.
As shown in FIG. 4(c), when independent_tiles_flag is 0, loop_filter_across_tiles_enable_flag, which indicates ON/OFF of the loop filter at the tile boundary applied to the reference picture, is transmitted (presented). When independent_tiles_flag is 1, loop_filter_across_tiles_enable_flag may always be 0 without presenting it.

When tiles are processed independently through the sequence, the independent tile flag independent_tiles_flag may be notified by SPS as shown in FIG. 4(a).

The tile information tile_info() is, for example, num_tile_columns_minus1, num_tile_rows_minus1, tile_unit_width_idc, tile_unit_height_idc, uniform_spacing_flag, column_width_in_unit_minus1[i], row_height_in_unit_minus1[i], as shown in FIG. 4(d). Here, num_tile_columns_minus1 and num_tile_rows_minus1 are values obtained by subtracting 1 from the number of tiles M and N in the horizontal and vertical directions in the picture, respectively. uniform_spacing_flag is a flag that indicates whether the picture is tiled as evenly as possible. When the value of uniform_spacing_flag is 1, an identifier that indicates the number of horizontal and vertical tiles in the picture and the minimum unit of tiles so that the width and height of each tile in the picture are equal as much as possible in units of a given size. From (tile unit identifier) (tile_unit_width_idc, tile_unit_height_idc), the width and height of the tile are derived in the video encoding device and the video decoding device (header decoding unit 3020).

The header decoding unit 3020 derives minimum tile units (tile unit sizes) wUnitTile and hUnitTile from the tile unit identifiers tile_unit_width_idc and tile_unit_height_idc (details will be described later). A tile whose unit size is not limited to an integral multiple of the CTU size is hereinafter referred to as a flexible tile.

wUnitTile = 1<<(log2CbSize+tile_unit_width_idc)
hUnitTile = 1<<(log2CbSize+tile_unit_height_idc)
The header decoding unit 3020 derives the numbers M and N of tiles in the horizontal and vertical directions in the picture as follows. M is numTileColumns and N is numTileRows.

M = num_tile_columns_minus1+1
N = num_tile_rows_minus1+1
numTileColumns = M = num_tile_columns_minus1+1
numTileRows = N = num_tile_columns_minus1+1
The header decoding unit 3020 derives the tile size as follows so as to be a multiple of the minimum tile size (minimum unit) wUnitTile and hUnitTile. Here, wPictInUnitTile and hPictInUnitTile are values representing wPict and hPict in units of wUnitTile and hUnitTile, respectively.

wPictInUnitTile = ceil(wPict/wUnitTile)
hPictInUnitTile = ceil(hPict/hUnitTile)
wTile[m] = ceil(wPictInUnitTile/M)*wUnitTile (0<=m<M)
hTile[n] = ceil(hPictInUnitTile/N)*hUnitTile (0<=n<N)
Alternatively, the header decoding unit 3020 may be derived by the following formula.

wTile[m] = floor(wPict/M/wUnitTile)*wUnitTile (0<=m<M)
hTile[n] = floor(hPict/N/hUnitTile)*hUnitTile (0<=n<N)
Alternatively, the header decoding unit 3020 may be derived by the following formula.

for(m=0;m<M;m++)
wTile[m] = ((m+1)*wPictInUnitTile/Mm*wPictInUnitTile/M)*wUnitTile
for(n=0;n<N;n++)
hTile[n] = ((n+1)*hPictInUnitTile/Nn*hPictInUnitTile/N)*hUnitTile
If the value of uniform_spacing_flag is 0, the width and height of each tile in the picture are set individually. In the video encoding device, each tile has a width column_width_in_unit_minus1[i] (wTile in FIG. 3 expressed in units of wUnitTile) and a height row_height_in_unit_minus1[i] (hTile in FIG. 3 expressed in units of hUnitTile). value) for each tile. The header decoding unit 3020 of the video decoding device decodes the tile sizes wTile[m] and hTile[n] for each tile based on the encoded (column_width_in_unit_minus1[], row_width_in_unit_minus1[]) as follows.

wTile[m] = (column_width_in_unit_minus1[m]+1)*wUnitTile (0<=m<M-1)
hTile[n] = (row_height_in_unit_minus1[m]+1)*hUnitTile (0<=n<N-1)
wTile[M-1] = ceil((wPict-sum_m(wTile[m]))/wUnitTile)*wUnitTile
hTile[N-1] = ceil((hPict-sum_n(hTile[n]))/hUnitTile)*hUnitTile
Here, sum_m(wTile[m]) represents the sum of wTile(0<=m<M-1), and sum_n(hTile[n]) represents the sum of hTile(0<=n<N-1).

Alternatively, wTile[M-1] and hTile[N-1] at the screen edges may simply be as follows if the picture size is not an integral multiple of the minimum unit of tiles.

wTile[M-1] = wPict-sum_m(wTile[m])
hTile[N-1] = hPict-sum_n(hTile[n])
However, in this case, it is desirable that the edges of the screen are appropriately processed by padding or cropping so that the processing unit matches the minimum unit of tiles or the minimum CU size.

Note that the tile at position (m,n) is also represented by an identifier TileId, which may be calculated as follows.

TileId = n*M+m
Alternatively, if the TileId is known, (m,n) indicating the position of the tile may be calculated from the TileId.

m = TileId%M
n = TileId/M
The header decoding unit 3020 decodes tile unit information indicating the unit of tile size. When the minimum units of tile width and height are wUnitTile and hUnitTile, the tile width and height are set to integral multiples of wUnitTile and hUnitTile, respectively.

For example, the header decoding unit 3020 decodes tile_unit_width_idc and tile_unit_height_idc as tile unit identifiers from the encoded data. The tile size unit may be a constant multiple (including 1) of the minimum size of the coding unit CU. If the CTU is a square with the same width and height, only the tile_unit_size_idc may be decoded to set tile_unit_height_idc=tile_unit_width_idc=tile_unit_size_idc to derive the tile size unit. At this time, tile_unit_width_idc and tile_unit_height_idc may be read as tile_unit_size_idc in the following specification (in this case, wUnitTile=hUnitTile=UnitTileSizeY).

(Setting method 1)
When the tile unit identifier is 0, the header decoding unit 3020 sets the tile size unit as the CTU unit. Specifically, when tile_unit_width_idc=0, set wUnitTile=ctuWidth, and when tile_unit_width_idc=0, set hUnitTile=ctuHeight. where ctuWidth is the width of the CTU and ctuHeight is the height of the CTU.

Furthermore, the header decoding unit 3020 may set the tile size unit to be a constant multiple of the minimum size of the coding unit CU, as described below, when the tile unit identifier is other than 0. .

wUnitTile = (tile_unit_width_idc==0) ? ctuWidth : 1<<(log2CbSize+tile_unit_width_idc-1)
hUnitTile = (tile_unit_height_idc==0) ? ctuHeight : 1<<(log2CbSize+tile_unit_height_idc-1)
where log2CbSize=log2(minCU), minCU is the minimum size of the coding unit CU.

The CTU size ctuSize=ctuWidth=ctuHeight is derived by decoding the syntax element log2_min_luma_coding_block_size_minus3 that determines the minimum CU size and the syntax element log2_diff_max_min_luma_coding_block_size that indicates the CU size as a logarithm of the difference from the minimum CU size. can be

log2CbSize = log2_min_luma_coding_block_size_minus3+3
log2CtuSize = log2CbSize + log2_diff_max_min_luma_coding_block_size
minCU = 1 << log2CbSize
ctuSize = 1 << log2CtuSize
Note that when the tile unit identifier !=0, the tile unit may be set to a constant multiple (exponential power of 2) of the minimum size of the encoding unit CU.

wUnitTile = (tile_unit_width_idc==0) ? ctuWidth : 1<<(log2CbSize+ Log2DiffTileUnitSize)
hUnitTile = (tile_unit_height_idc==0) ? ctuHeight : 1<<(log2CbSize+ Log2DiffTileUnitSize)
Here, Log2DiffTileUnitSize is a constant that defines the tile unit. For example, setting to 1, 2, 3 will set the tile unit to 4, 8, 16 times the minimum CU size. For example, if the CU size is 4, it is set to 8, 16, and 32. Furthermore, the maximum value may be clipped to the CTU size.

(Setting method 2)
The tile information is a tile unit identifier tile_unit_width_idc with a number ranging from 0 to a predetermined range, and the tile size unit may be set as 1<<(log2(minCU)+tile unit identifier). That is, the header decoding unit 3020 may decode tile_unit_width_idc and tile_unit_height_idc (or tile_unit_size_idc) and set the tile unit as follows.

wUnitTile = 1<<(log2CbSize+tile_unit_width_idc)
hUnitTile = 1<<(log2CbSize+tile_unit_height_idc)
If the CTU is a square with the same width and height, the above is equivalent to decoding tile_unit_size_idc and setting it as follows. Since it is self-explanatory, a description of the case of only squares is omitted below.

wUnitTile = hUnitTile = ctuSize>>tile_unit_size_idc
Note that the tile unit may be set to a constant multiple (exponential power of 2) of the minimum size of the encoding unit CU without explicitly encoding the tile unit identifier.

wUnitTile = 1<<(log2CbSize+Log2DiffTileUnitSize)
hUnitTile = 1<<(log2CbSize+Log2DiffTileUnitSize)
Here, Log2DiffTileUnitSize is a constant that defines the tile unit. Furthermore, the maximum value is CTU
Can be clipped to size.

wUnitTile = min(ctuWidth,1<<(log2CbSize+Log2DiffTileUnitSize))
hUnitTile = min(ctuHeight1<<(log2CbSize+Log2DiffTileUnitSize))
(Setting method 3)
The tile information is a tile unit identifier with a number ranging from 0 to a predetermined range. tile unit identifier). That is, the header decoding unit 3020 may decode tile_unit_width_idc and tile_unit_height_idc (or tile_unit_size_idc) and set the tile unit as follows.

wUnitTile = 1<<(log2CtuWidthY-tile_unit_width_idc)
hUnitTile = 1<<(log2CtuHeightY-tile_unit_height_idc)
where log2CtuWidthY=log2(ctuWidth) and log2CtuHeightY=log2(ctuHeight).

Note that the width and height of the CTU size may be set to the same value.

wUnitTile = 1<<(log2CtuSize-tile_unit_width_idc)
hUnitTile = 1<<(log2CtuSize-tile_unit_height_idc)
where log2CtuSize=log2(ctuWidth)=log2(ctuHeight).
In this case, it is appropriate to call tile_unit_width_idc log2_diff_luma_tile_unit_size because the difference is expressed in logarithm.

It should be noted that it is also possible to clip so that the tile unit has a minimum size that is a multiple of 8 as follows.

wUnitTile = max(8, ctuWidth>>tile_unit_width_idc)
hUnitTile = max(8, ctuHeight >> tile_unit_height_idc)
As a result, since the tile width is always a multiple of 8, the effect shown in (setting method 5) is also exhibited.

Also, you can clip so that the unit size becomes the minCTU size as follows.

wUnitTile = max(minCTU, ctuWidth >> tile_unit_width_idc)
hUnitTile = max(minCTU, ctuHeight >> tile_unit_height_idc)
As a result, the tile width is always a multiple of the minimum size of the CTU, so the effect shown in (setting method 5) is also achieved.

Furthermore, the possible range of tile_unit_width_idc may be restricted. For example, if the minimum value of ctuWidth>>tile_unit_width_idc is minCTU,
ctuWidth >> tile_unit_width_idc >= minCTU
ctuWidth >= minCTU<< tile_unit_width_idc
ctuWidth >= minCTU * (1<<tile_unit_width_idc)
(1<<tile_unit_width_idc) <= ctuWidth/minCTU
tile_unit_width_idc <= log2(ctuWidth)-log2(minCTU)
Therefore, limit tile_unit_width_idc to 0 or more and log2(ctuWidth)-log2(minCTU) or less. That is, the video decoding device can use tile units that are multiples of minCTU by decoding encoded data limited to 0 or more and log2(ctuWidth)-log2(minCTU) or less.

Similarly, tile units that are multiples of 8 can be used by decoding encoded data limited to 0 or more and log2(ctuWidth)-log2(8)=log2(ctuWidth)-3 or less. In the case of multiples of 16 and 32 instead of multiples of 8, the above 3(log2(8)) should be changed to 4 and 5.

(Setting method 4)
The tile information is a tile unit identifier with a number ranging from 0 to a predetermined range, and the tile size unit is set by CTU size >> tile unit identifier so that the tile size unit is 1 divided by the CTU size multiplied by 2. It is characterized by That is, the header decoding unit 3020 may decode tile_unit_width_idc and tile_unit_height_idc (or tile_unit_size_idc) and set the tile unit as follows.

wUnitTile = ctuWidth >> tile_unit_width_idc
hUnitTile = ctuHeight>>tile_unit_height_idc
Since setting method 3 and setting method 4 have the same value, the method described in (setting method 3) can be used to limit tile_unit_width_idc and tile_unit_height_idc (or tile_unit_size_idc).

(Setting method 5)
The header decoding unit 3020 does not decode the tile unit identifiers (tile_unit_width_idc, tile_unit_height_idc), and sets the predetermined value TileUnit to wUnitTile, hUnitTile. Preferably, the predetermined value TileUnit is a multiple of 8, especially 8, 16 or 32. Tile information tile_info( ) is notified as shown in FIG. 23(d) instead of FIG. 4(d), and header decoding section 3020 decodes this tile information.

wUnitTile = TileUnit
hUnitTile = TileUnit
Here, TileUnit is 8 or a multiple of 8 such as 16 or 32. If the tile unit is a multiple of 8, the pixel data of the tile width can be a multiple of 8 even if the pixel bitDepth is not a multiple of 8, such as 10 bits. As a result, the tile boundary is always a byte (8-bit) boundary even when arranging the tiles in the memory, and no memory gap is required between the tiles when arranging the tiles in the memory. If there is no gap, the memory for the gap is not required, and continuous transfer is possible, so that the memory size can be reduced and high-speed transfer is possible. Furthermore, if it is a multiple of 16, the tile width data can always be a multiple of 128 bits (when bitDepth = 8 bits), and high-speed access is possible with burst access of many memories (eg DDR).

Furthermore, in the case of 16 and 32, there is an effect that it matches the minimum CTU size described later.

(Setting method 6)
The header decoding unit 3020 does not decode the tile unit identifiers (tile_unit_width_idc, tile_unit_height_idc), and sets the predetermined value TileUnit to wUnitTile, hUnitTile. The predetermined value TileUnit is preferably the minimum size of the CTU (minimum CTU size). In this case, the tile information tile_info( ) is notified as shown in FIG. 23(d) instead of FIG. 4(d), and the header decoding unit 3020 decodes this tile information.

wUnitTile = TileUnit
hUnitTile = TileUnit
TileUnit = 1<<(log2_min_luma_coding_tree_block_size_minus4+4)
Here, log2_min_luma_coding_block_size_minus4 is a value obtained by subtracting 4 from the power-of-2 representation of the minimum size of the CTU. For example, the minimum CTU sizes are 16, 32, 64, and 128 for 0, 1, 2, and 3, respectively. Note that log2_min_luma_coding_block_size_minus4, which determines the minimum CTU size, may be encoded with encoded data as a syntax element, or may be a constant. For example, in the case of a constant, the minimum CTU size is usually 16 and 32, so it matches (setting method 5).

The minimum CTU size may be set with a profile or level that defines the functions and capabilities of the video decoding device. Profiles and levels are used for negotiation between devices, so they are transmitted by relatively high-order parameter sets and headers, for example, SPS syntax elements profile_idc and level_idc.

If the tile unit is a multiple of the minimum CTU size, the tile width will always be a multiple of the minimum CTU size. Typically, memory allocation is optimized based on the limited range of possible CTU sizes (eg, 16, 32, 64) when pictures are stored in memory. If the tile width is an integer multiple (exponential power of 2) of the CTU size, memory can be allocated in the case of tiles in the same manner as for pictures, so there is an effect that memory can be saved and images can be accessed at high speed.

(Setting method 7)
The tile information is a tile unit identifier with a number ranging from 0 to a predetermined range, and 1<<(log2(minimum CTU size) + tile unit identifier). In (setting method 7), the tile unit identifier is a logarithmic representation of a multiple of the minimum CTU size. That is, the header decoding unit 3020 may decode tile_unit_width_idc and set the tile unit as follows.

wUnitTile = 1<<(log2CtuUnitSize+tile_unit_width_idc)
hUnitTile = 1<<(log2CtuUnitSize+tile_unit_height_idc)
Here, the minimum size of the CTU may be minCTU=ctuUnitSize=1<<(log2_min_luma_coding_tree_block_size_minus4+4), log2CtuUnitSize=log2_min_luma_coding_tree_block_size_minus4+4.

(Setting method 8)
The tile information is a number of tile unit identifiers ranging from 0 to a predetermined range, and the tile size unit is set by maximum CTU size >> tile unit identifier. In (setting method 8), the tile unit identifier is a logarithmic representation of a multiple of the maximum CTU size (1 times the power of 2). That is, the header decoding unit 3020 may decode tile_unit_width_idc and set the tile unit as follows.

wUnitTile = ctuUnitSize>>tile_unit_width_idc
hUnitTile = ctuUnitSize>>tile_unit_height_idc
(Setting method 9)
In (setting method 9), as shown in FIG. 24(a), tile_parameters( ) and tile information tile_info( ) are notified not by PPS but by SPS. As shown in FIG. 24(c), the minimum unit of tile is notified by log2_min_unit_tile_size_minus3. The header decoding unit 3020 decodes this tile information and derives the minimum unit of tile (wUnitTile, hUnitTile).

wUnitTile = 1<<(log2_min_unit_tile_size_minus3+3)
hUnitTile = 1<<(log2_min_unit_tile_size_minus3+3)
Here, log2_min_unit_tile_size_minus3 is a value obtained by subtracting 3 from the power-of-2 expression of the minimum value of the minimum unit of the tile, and is an integer of 0 or greater. Therefore, the minimum unit of tiles is 8 or more.

As another example, as shown in FIG. 25(a), only log2_diff_curr_min_unit_tile_size may be notified as tile information. log2_diff_curr_min_unit_tile_size is the difference between the minimum unit of tile size in the SPS and the minimum size of CTU. The header decoding unit 3020 decodes this tile information and derives the minimum unit of tile (wUnitTile, hUnitTile).

wUnitTile = 1<<( log2CtuSize + log2_diff_curr_min_unit_tile_size )
hUnitTile = 1<<( log2CtuSize + log2_diff_curr_min_unit_tile_size )
(Setting method 10)
In (setting method 10), in contrast to (setting method 9), there is a restriction that the minimum unit of the tile size in the SPS does not exceed the CTU size in the SPS. Therefore, log2_diff_curr_min_unit_tile_size must satisfy the following formula.

0<=log2_diff_curr_min_unit_tile_size<=log2_diff_max_min_luma_coding_block_size where log2_diff_max_min_luma_coding_block_size is the power-of-two difference between the maximum and minimum size of the CTU.

(Setting method 11)
In (setting method 11), as shown in FIG. 26, tile_parameters( ) and tile information tile_info( ) are notified by PPS. As shown in FIGS. 26(a) and (d), the minimum unit of tile is derived using the minimum size of CTU notified by SPS and the tile information (log2_diff_curr_min_unit_tile_size) notified by PPS. log2_diff_curr_min_unit_tile_size is the difference between the minimum unit of tile size and the minimum size of CTU. The header decoding unit 3020 decodes this tile information and derives wUnitTile and hUnitTile.

wUnitTile = 1<<(log2CtuSize+log2_diff_curr_min_unit_tile_size)
hUnitTile = 1<<(log2CtuSize+log2_diff_curr_min_unit_tile_size)
(Setting method 12)
In (setting method 12), the independent_tiles_flag is referenced to derive wUnitTile and hUnitTile for TileUnit. independent_tiles_flag = 1, ie if each tile can be processed independently (without referring to other tiles), set the tile unit (minimum unit) smaller than otherwise. For example, in (setting method 5), the predetermined value TileUnit is set to 8 when independent_tiles_flag=1, and set to 16 when independent_tiles_flag=0.

As another example, in (setting method 6), when independent_tiles_flag=1, a predetermined value TileUnit is set to a value equal to or less than the minimum size of the CTU (minimum CTU size), and when independent_tiles_flag=0, a predetermined value TileUnit to the minimum size of the CTU (minimum CTU size).

As another example, in (setting method 6), when independent_tiles_flag=1, the predetermined value TileUnit is set to a value equal to or smaller than the CTU size, and when independent_tiles_flag=0, the predetermined value TileUnit is set to the CTU size. For example, if independent_tiles_flag=1, a predetermined value TileUnit of 8, 16, or 32 is used, and if 0, the CTU size is used.

Alternatively, as another example, in (setting method 6), if independent_tiles_flag = 1, a predetermined value TileUnit is set to the minimum size of the CTU (minimum CTU size), and if independent_tiles_flag = 0, the predetermined value TileUnit is set to the CTU set to size.

If independent_tiles_flag is 1, that is, tiles that are decoded independently without referring to each other, the tiles can be arranged in memory independently (that is, there is no problem if memory gaps occur between tiles), so a small value However, there is no problem with memory allocation. As a result, in the case of independently decodable areas, the tile size can be determined flexibly.

(Setting method 13)
In (setting method 13), the predetermined value TileUnit is set according to the unit of other processing. For example, a prediction unit (sub CU) is set as a predetermined value TileUnit. Alternatively, the unit for storing motion vectors for TMVP is set as a predetermined value TileUnit. For example, if the motion vector storage unit for TMVP is 8x8, set TileUnit=8. Alternatively, the unit for updating the quantization parameter is set as a predetermined value TileUnit. For example, if the unit for reporting the differential quantization parameter is 16x16, set TileUnit=16.

(Setting method 14)
In (setting method 14), the predetermined value TileUnit is set to an integral multiple ctuSize of the minimum CTU size in the horizontal direction of the tile, and 8 or 16 in the vertical direction. The header decoding unit 3020 decodes this tile information. For example, use the following formula to set the minimum unit of tiles.

wUnitTile = ctuSize
hUnitTile = 8
(Tile information setting part)
The tile information setting unit sets the upper left coordinates (xTile, yTile) of the tile based on the minimum units wUnitTile and hUnitTile of the tile. Further, the tile information setting unit sets the width tileWidthInCtus (=TileWidthInCtbsY) and the height tileHeightInCtus (=TileHeightInCtbsY) in CTU units of the tile.

(Step 1)
The screen widths wPictInUnitTile and hPictInUnitTile in tile units (wUnitTile, hUnitTile) are derived from the minimum tile units wUnitTile and hUnitTile and the screen widths wPict and hPict.

wPictInUnitTile = divRoundUp(wPict,wUnitTile)
hPictInUnitTile = divRoundUp(hPict,hUnitTile)
where divRoundUp(x,y) = (x+y-1)/y
That is, it returns the smallest integer greater than or equal to x divided by y. That is, it may be ceil(x/y).

(Step 2)
The tile information setting unit derives the upper left coordinate (xTile, yTile) in the picture of the tile indicated by the tile position (col, row). Below, the coordinates within a picture are those in the picture coordinate system where the top left of the picture is (0, 0), and the coordinates within a tile are those in the tile coordinate system where the top left of each tile is (0, 0). means coordinates. Loop the tile column position col from 0 to the tile column number numTileColumns-1, and use the minimum unit wUnitTile to derive the X coordinate tx[col] and width tw[col] of each tile of each col. Similarly, loop the tile row position row from 0 to the number of tile rows numTileRows-1, and use the minimum unit hUnitTile to derive the Y coordinate ty[row] and height th[row] of each tile in each row. do.

When uniform_spacing_flag is 1, the tile information setting part divides the screen into numTileColumns x
Tiles are divided into numTileRows (= M x N), and tile sizes tw[col], th[row], tile X coordinates tx[col], Y coordinates ty[row] are derived. Specifically, as shown in the pseudo code below, the picture width wPict and the number of tile columns numTileColumns are used to derive tx[col] and tw[col], the picture width hPict and the number of tile columns numTileRows to derive ty[row] and th[row]. For ty and tw, the values previously obtained as the aforementioned hTile and wTile may be used. Note that min() is applied to wPict-tx[col] and tw[col] so that the tiles do not exceed the edge of the screen.

for(col=0; col <numTileColumns; col++)
{
tx[col] = wUnitTile*(col*wPictInUnitTile/numTileColumns)
tw[col] = wUnitTile*((col+1)*wPictInUnitTile/numTileColumns)-tx[col]
tw[col] = min(wPict-tx[col],tw[col])
}
for(row=0; row <numTileRows; row++)
{
ty[row] = hUnitTile*(row*hPictInUnitTile/numTileRows)
th[row] = hUnitTile*((row+1)*hPictInUnitTile/numTileRows)-ty[row]
th[row] = min(hPict-ty[row],th[row])
}
When the uniform_spacing_flag is 0, the tile information setting unit divides the screen using the tile sizes wTile(col) and hTile(row) and derives the X coordinate tx[col] and Y coordinate ty[row] of the tile. .
Specifically, as shown in the pseudocode below, the picture width wPict and the tile column width wTile[col] are used to derive tx[col], the picture height hPict, and the tile row height hTile Use [row] to derive ty[row].

for(col=0;col<numTileColumns-1;col++)
{
tw[col] = wTile[col] = (column_width_in_unit_minus1[col]+1)*wUnitTile
tx[col+1] = tx[col]+tw[col]
}
tw[numTileColumns-1] = wPict-tx[numTileColumns-1]
for(row=0;row<numTileRows-1;row++)
{
th[row] = hTile[row] = (column_height_in_unit_minus1[row]+1)*hUnitTile
ty[row+1] = ty[row]+th[row]
}
th[numTileRows-1] = hPict-ty[numTileRows-1]
The tile information setting unit converts the derived tile X coordinate tx[col], Y coordinate ty[row] and tile size tw[col], th[row] to the upper left coordinate xTile in the picture of the tile indicated by the tile ID. Store in [TileId], yTile[TileId], tile size wTile[TileId], hTile[TileId].

for(row=0;row<numTileRows;row++)
{
for(col=0;col<numTileColumns;col++)
{
TileId = row*numTileColumns+col
xTile[TileId] = tx[col]
yTile[TileId] = ty[row]
wTile[TileId] = tw[col]
hTile[TileId] = th[row]
tileWidthInCtus[TileId] = divRoundUp(tw[col],ctuWidth)
tileHeightInCtus[TileId] = divRoundUp(th[row],ctuHeight)
}
}
for(PicWidthInCtbsY=0,i=0;i<=num_tile_columns_minus1;i++)
PicWidthInCtbsY += tileWidthInCtus[i]
for(PicHeightInCtbsY=0,j=0;j<=num_tile_rows_minus1;j++)
PicHeightInCtbsY += tileHeightInCtus[j)]
It should be noted that the tile information setting unit may perform the following operations because the operation is the same even though the temporary variables are different in the expressions below.

if (uniform_spacing_flag) {
for (i=0; i<= num_tile_columns_minus1;i++)
colWidth[i] = ((i+1)*wPictInUnitTile)/(num_tile_columns_minus1+1)-(i*hPictInUnitTile)/(num_tile_columns_minus1+1))
for (j=0; j<= num_tile_rows_minus1;j++)
rowHeight[j] = ((j+1)*hPictInUnitTile)/(num_tile_rows_minus1+1)-(j*hPictInUnitTile)/(num_tile_rows_minus1+1))
else {
colWidth[num_tile_columns_minus1] = wPictInUnitTile
for (i=0; i<= num_tile_columns_minus1;i++) {
colWidth[i] = column_width_minus1[i]+1
colWidth[num_tile_columns_minus1]-=colWidth[i]
}
rowHeight[num_tile_rows_minus1] = hPictInUnitTile
for (j=0; j<= num_tile_rows_minus1;j++) {
rowHeight[j] = row_height_minus1[j]+1
rowHeight[num_tile_rows_minus1]-=rowHeight[j]
}
}
}
for (colX[0]=0,i=0; i <= num_tile_columns_minus1; i++)
colX[i+1] = colX[i]+colWidth[i]*wUnitTile
for (colY[0]=0,j=0; j <= num_tile_rows_minus1; j++)
colY[j+1] = colY[j]+colRow[j]*hUnitTile
for (colBd[0]=0,i=0; i <= num_tile_columns_minus1; i++)
colBd[i+1] = colBd[i]+Ceil(colWidth[i]*wUnitTile÷ctuWidth)
for (rowBd[0]=0,j=0; j <= num_tile_rows_minus1;j++)
rowBd[j+1] = rowBd[j]+Ceil(rowHeight[j]*hUnitTile÷ctuHeight)
for(PicWidthInCtbsY=0,i=0;i<=num_tile_columns_minus1; i++)
PicWidthInCtbsY += Ceil(colWidth[i]*TileUnitSizeY÷ctuSize)
for(PicHeightInCtbsY=0,j=0;j<=num_tile_rows_minus1;j++)
PicHeightInCtbsY += Ceil(rowHeight[j]*TileUnitSizeY÷ctuSize)
In addition, you may derive as follows in the whole screen.

for(i = 0; i <NumTilesInPic; i++ ) {
col = i % ( num_tile_columns_minus1 + 1 )
row = i / ( num_tile_columns_minus1 + 1 )
TileWidth[i] = colWidth[col] * TileUnitSizeY
TileHeight[ i ] = rowHeight[ row ] * TileUnitSizeY
TileWidthInCtbsY[i] = Ceil(wTile[i] ÷ ctuSize)
TileHeightInCtbsY[ i ] = Ceil( hTile [ i ] ÷ ctuSize )
TileX[i] = TileColX[col]
TileY[i] = TileRowY[row]
TileXInCtbsY[ i ] = colBd[ col ]
TileYInCtbsY[ i ] = rowBd[ row ]
}
where TileUnitSizeY=wUnitTile=hUnitTile
As described above, slice data (slice_segment_data()) uses the tile information notified by the PPS shown in FIG. . Specifically, each tile is divided into CTUs (width ctuWidth, height ctuHeight) as the upper left coordinates (0, 0) of each tile starting from (xTile, yTile) on the picture, and the coded data of each CTU coding_quadtree () may be notified.

The header decoding unit 3020 decodes header information from an encoded stream Te that is input from the outside and encoded in units of NAL (network abstraction layer) units. Also, the header decoding unit 3020 derives a tile (TileId) necessary for display from externally input control information indicating an image area to be displayed on a display or the like. Also, the header decoding unit 3020 extracts encoded tiles necessary for display from the encoded stream Te. The encoded tiles are divided into CTUs and processed by the CT information decoding unit 3021 according to the syntax in the encoded data. Specifically, the tile information is calculated from syntax such as num_tile_columns_minus1, num_tile_rows_minus1, uniform_spacing_flag, column_width_in_unit_minus1[i], row_height_in_unit_minus1[i], etc. [m] and height hTile[n] and so on.

FIG. 11 is an example of dividing tiles by non-integer multiples of the CTU size. FIG. 11(a) is a diagram of the technology of the present embodiment, in which a 1920×1080 HD image is divided into 4×3 tiles. In this embodiment, when dividing into 4x3 tiles, all tiles can be divided into equal sizes (divided into 480x360), so there is an effect of equally load-balancing a plurality of processors and hardware. Tile sizes can be other than integer multiples of CTU regardless of picture boundaries. FIG. 11(b) is a diagram showing CTU division of each tile. When dividing into CTUs, if the tile size is not an integral multiple of the CTU size, a crop offset area is provided outside the tiles. Specifically, as shown in TILE B, the CTU is split relative to the top left of each tile. Therefore, the upper left coordinate of the CTU is not limited to integer multiples of the CTU size.

FIG. 12 is a diagram showing a case where each tile is further divided into CTUs. The picture divides the picture into 2x2 tiles, but each tile is further divided into CTUs. In this embodiment, as shown in the figure, when dividing each tile into CTUs, the division is performed so that the CTUs start from the upper left corner of the tile. Therefore, on the right and bottom sides of the tiles, the tiles may end at positions other than integer multiples of the CTU size, but on the left and top sides of the tiles, the CTU and tile boundaries coincide.

(encoding tree unit)
FIG. 1(e) defines a set of data that the video decoding device 31 refers to in order to decode the CTU to be processed. CTU uses recursive quad tree partitioning (QT (Quad Tree) partitioning), binary tree partitioning (BT (Binary Tree) partitioning), or ternary tree partitioning (TT (Ternary Tree) partitioning) as the basis of coding processing. It is divided into coding units CU, which are similar units. BT partitioning and TT partitioning are collectively called multi-tree partitioning (MT (Multi Tree) partitioning). A node of a tree structure obtained by recursive quadtree partitioning is called a coding node. Intermediate nodes of quadtrees, binary trees, and ternary trees are coding nodes, and the CTU itself is defined as a top-level coding node. QT division, BT division, and TT division are collectively called CT division.

CT includes, as CT information, a QT splitting flag (cu_split_flag) indicating whether to perform QT splitting, an MT splitting mode (split_mt_mode) indicating a splitting method of MT splitting, and an MT splitting direction (split_mt_dir) indicating the splitting direction of MT splitting. , including an MT split type (split_mt_type) that indicates the split type of the MT split. cu_split_flag, split_mt_flag, split_mt_dir and split_mt_type are transmitted for each encoding node.

If cu_split_flag is 1, the encoding node is split into four encoding nodes (FIG. 2(b)). When cu_split_flag is 0 and split_mt_flag is 0, the encoding node is not split and has one CU as a node (Fig. 2(a)). A CU is a terminal node of an encoding node and is not split any further. A CU is a basic unit of encoding processing.

When split_mt_flag is 1, the coding node is MT-split as follows. When split_mt_type is 0, the encoding node is split horizontally into two encoding nodes when split_mt_dir is 1 (Fig. 2(d)), and when split_mt_dir is 0, the encoding node is vertically split into two encoding nodes. It is divided (Fig. 2(c)). When split_mt_type is 1 and split_mt_dir is 1, the encoding node is horizontally split into 3 encoding nodes (Fig. 2(f)). (Fig. 2(e)).

If the CTU size is 64x64 pixels, the CU size is 64x64 pixels, 64x32 pixels, 32x64 pixels, 32x32 pixels, 64x16 pixels, 16x64 pixels, 32x16 pixels, 16x32 pixels, 16x16 pixels, 64x8 pixels, 8x64 pixels. , 32x8 pixels, 8x32 pixels, 16x8 pixels, 8x16 pixels, 8x8 pixels, 64x4 pixels, 4x64 pixels, 32x4 pixels, 4x32 pixels, 16x4 pixels, 4x16 pixels, 8x4 pixels, 4x8 pixels, and 4x4 pixels. .

(encoding unit)
As shown in FIG. 1(f), a set of data referred to by the moving picture decoding device 31 for decoding the encoding unit to be processed is defined. Specifically, a CU is composed of a CU header CUH, prediction parameters, transform parameters, quantized transform coefficients, and the like. A prediction mode and the like are defined in the CU header.

Prediction processing may be performed in units of CUs or may be performed in units of sub-CUs obtained by further dividing a CU. If the CU and sub-CU sizes are equal, there is one sub-CU in the CU. If the CU is larger than the sub-CU size, the CU is split into sub-CUs. For example, if the CU is 8x8 and the sub-CU is 4x4, the CU is divided into 4 sub-CUs consisting of 2 horizontal divisions and 2 vertical divisions.

There are two types of prediction (prediction mode): intra prediction and inter prediction. Intra prediction is prediction within the same picture, and inter prediction is prediction processing performed between different pictures (for example, between display times, between layer images).

Transformation/quantization processing is performed in units of CUs, but the quantized transform coefficients may be entropy-encoded in units of subblocks such as 4x4.

(prediction parameter)
A predicted image is derived from the prediction parameters associated with the block. The prediction parameters include prediction parameters for intra prediction and inter prediction.

(Configuration of video decoding device)
The configuration of the video decoding device 31 (FIG. 5) according to this embodiment will be described.

The video decoding device 31 includes a parameter decoding unit (predictive image decoding device) 302, a loop filter 305, a reference picture memory 306, a prediction parameter memory 307, a predicted image generating unit (predictive image generating device) 308, inverse quantization/inverse transform. It includes a unit 311 and an addition unit 312 . Note that the moving image decoding device 31 may have a configuration in which the loop filter 305 is not included in accordance with the moving image encoding device 11 described later. The parameter decoding unit 302 further includes an entropy decoding unit 301, a header decoding unit 3020, a CT information decoding unit 3021, and a CU decoding unit 3022 (prediction mode decoding unit). It has

(decryption module)
The general operation of each module will be described below. A parameter decoding unit 302 decodes parameters such as header information, division information, prediction information, and quantized transform coefficients.

The entropy decoding unit 301 decodes syntax elements from binary data. More specifically, the entropy decoding unit 301 decodes syntax elements from data encoded by an entropy encoding method such as CABAC based on the syntax elements supplied from the supply source and returns them to the supply source. In the example shown below, the supply sources of the syntax elements are the CT information decoding unit 3021 and the CU decoding unit 3022.

(Basic flow)
FIG. 6 is a flow chart for explaining a schematic operation of the video decoding device 31. As shown in FIG.

(S1100: Parameter Set Information Decoding) Header decoding section 3020 decodes parameter set information such as VPS, SPS, and PPS from encoded data.

(S1200: Slice Information Decoding) Header decoding section 3020 decodes the slice header (slice information) from the encoded data.

Thereafter, video decoding device 31 derives a decoded image of each CTU by repeating the processing from S1300 to S5000 for each CTU included in the target picture.

(S1300: CTU Information Decoding) CT information decoding section 3021 decodes CTU from encoded data.

(S1400: CT Information Decoding) CT information decoding section 3021 decodes CT from encoded data.

(S1500: CU Decoding) CU decoding section 3022 executes S1510 and S1520 to decode CU from encoded data.

(S1510: CU information decoding) CU decoding section 3022 decodes CU information, prediction information, TU split flag split_transform_flag, CU residual flag cbf_cb, cbf_cr, cbf_luma, etc. from encoded data.

(S1520: TU information decoding) TU decoding section 3024 decodes QP update information (quantization correction value) and quantization prediction error (residual_coding) from encoded data when prediction error is included in TU. Note that the QP update information is a difference value from the quantization parameter prediction value qPpred, which is the prediction value of the quantization parameter QP.

(S2000: Generate Predicted Image) The predicted image generation unit 308 generates a predicted image for each block included in the target CU based on the prediction information.

(S3000: Inverse Quantization/Inverse Transform) The inverse quantization/inverse transform unit 311 executes inverse quantization/inverse transform processing for each TU included in the target CU.

(S4000: Generate decoded image) The adder 312 adds the predicted image supplied from the predicted image generation unit 308 and the prediction error supplied from the inverse quantization/inverse transform unit 311, thereby decoding the target CU. Generate an image.

(S5000: Loop Filter) Loop filter 305 generates a decoded image by applying loop filters such as deblocking filter, SAO, and ALF to the decoded image.

(decoding of CTU in case of tiles)
FIG. 13 is a diagram showing encoded slice data. A CT information decoding unit 3021 of the parameter decoding unit 302 sequentially processes CTUs forming a slice (tile). Furthermore, the CT information decoding unit 3021 uses a target CTU coordinate derivation unit (not shown) to refer to the CTU address tables CtbAddrToCtbX[] and CtbAddrToCtbY[] from the CTU raster scan address CtbAddrInRs of the target CTU, and the upper left coordinate ( xCtb, yCtb).

xCtb = CtbAddrToCtbX[CtbAddrInRs]
yCtb = CtbAddrToCtbY[CtbAddrInRs]
The CT information decoding unit 3021 decodes the coding tree coding_quadtree(xCtb, yCtb, log2CbSize, cqtDepth) whose root is the target CTU from the coded data by recursive processing.

Here, CtbAddrToCtbX and CtbAddrToCtbY are tables derived by the CTU address table derivation unit.
The parameter decoding unit 302 decodes the flag end_of_slice_segment_flag indicating whether or not it is the end of the slice segment, increments the CTU address CtbAddrInTs by 1 (CtbAddrInTs++) in preparation for processing the next CTU, and derives the address of the subsequent CTU. . Further derive the CTU raster scan address corresponding to the subsequent CTU (CtbAddrInRs = CtbAddrTsToRs[CtbAddrInTs]). where CtbAddrInTs is the tile scan address of the target CTU.

Parameter decoding unit 302 is not the end of the slice segment (!end_of_slice_segment_flag), the tile is enabled (tiles_enabled_flag), the tile ID of the subsequent CTU (TileId[CtbAddrInTs] or TildIdTbl[CtbAddrInTs]) and the CTU tile ID of the target CTU If ([CtbAddrInTs-1]) is different, decode end_of_subset_one_bit and then decode the bit for byte alignment (byte_alignment()).

Furthermore, the parameter decoding unit 302 supports wavefronts that perform parallel processing in units of CTU lines in addition to tiles, and if the wavefront flag entropy_coding_sync_enabled_flag is 1 and the subsequent CTU is the head of the CTU line (CtbAddrInRs%PicWidthInCtbsY==0 ), end_of_subset_one_bit, and the bit for byte alignment (byte_alignment()) may be decoded.

The conditions for decoding end_of_subset_one_bit and byte_alignment( ) may be the conditions shown in FIG. 27(a). That is, the parameter decoding unit 302 decodes end_of_subset_one_bit and byte_alignment( ) if tiles are enabled (tiles_enabled_flag) instead of the end of the slice segment (!end_of_slice_segment_flag).

Here, this embodiment is characterized by a method of deriving PicWidthInCtbsY for tiles of sizes not limited to integral multiples of the CTU size. PicWidthInCtbsY means how many CTUs are included in the picture width. The value of PicWidthInCtbsY is not always equal to ceil(wPict/ctuWidth), as there may be multiple CTUs with less than the size. As described above, the parameter decoding unit 302 of this embodiment derives PicWidthInCtbsY by the following method.

for(PicWidthInCtbsY=0,i=0;i<=num_tile_columns_minus1;i++)
PicWidthInCtbsY += tileWidthInCtus[i]
PicHeightInCtbsY is the same and is derived by the following method.

for(PicHeightInCtbsY=0,j=0;j<=num_tile_rows_minus1;j++)
PicHeightInCtbsY += tileHeightInCtus[j]
If the tiles are limited to integer multiples of the CTU size, the following method may be used for derivation.

PicWidthInCtbsY = Ceil(wPict/ctuWidth)
PicHeightInCtbsY = Ceil(hPict/ctuHeight)
The division (/) here is decimal precision.

(CTU address table derivation part)
The CTU address table deriving unit derives CTU address tables CtbAddrToCtbX[], CtbAddrToCtbY[] for deriving CTU coordinates (xCtb, yCtb) from CTU raster scan addresses (CtbAddrInRs) by the following steps.

(Step 1)
A tile ID (TileId) is derived from the CTU raster scan address CtbAddrInRs of the target CTU.

TileId = CtbAddrRsToTileID[CtbAddrInRs]
Here, CtbAddrRsToTileID is a table derived by the tile ID table derivation unit.

(Step 2)
The CTU address table derivation unit derives the first CTU raster scan address firstCtbAddrInRs[TileId] of the tile containing the target CTU, and uses the number of CTUs PicWidthInCtbsY included in the picture width to calculate the intra-tile coordinates (xCtbInCtus , yCtbInCtus) is derived by
xCtbInCtus = (CtbAddrInRs-firstCtbAddrInRs[TileId])%PicWidthInCtbsY
yCtbInCtus = (CtbAddrInRs-firstCtbAddrInRs[TileId])/PicWidthInCtbsY
Here, firstCtbAddrInRs is a table for deriving the leading CTU raster scan address of the tile indicated by the tile ID, and is derived by the leading tile address deriving unit.

The CTU address table deriving unit multiplies the CTU size (ctuWidth, ctuHeight) to derive the pixel unit intra-tile coordinates (xCtbInTile, yCtbInTile) using the following formula.

xCtbInTile = xCtbInCtus*ctuWidth
yCtbInTile = yCtbInCtus*ctuHeight
Note that the CTU size may be derived using logarithmic representation as follows.

xCtbInTile = xCtbInCtus<<CtbLog2SizeY
yCtbInTile = yCtbInCtus<<CtbLog2SizeY
(Step 3)
The CTU address table derivation unit calculates the upper left coordinates (xCtb, yCtb) of the CTU in the picture from the sum of the coordinates in the tile (xCtbInTile, yCtbInTile) and the coordinates in the picture of the upper left of the tile (xTile[TileId], yTile[TileId]). derive

xCtb = xTile[TileId]+xCtbInTile
yCtb = yTile[TileId]+yCtbInTile
(Step 4)
The CTU address table derivation unit stores the CTU upper left coordinates (xCtb, yCtb) for the last derived CtbAddrInRs in the table.
CtbAddrToCtbX[CtbAddrInRs] = xCtb
CtbAddrToCtbY[CtbAddrInRs] = yCtb
The above processing can also be expressed as follows using the position of the upper left CTU of the tile (xTileInCtus, yTileInCtu).

xTileInCtus = firstCtbAddrInRs[TileId] % PicWidthInCtbsY
yTileInCtus = firstCtbAddrInRs[TileId] / PicWidthInCtbsY
xCtb = (((CtbAddrInRs-xTileInCtus)%tileWidthInCtus[TileId])<<log2CtuWidthY)+xTile[TileId]
yCtb = (((CtbAddrInRs-yTileInCtus)/tileWidthInCtus[TileId])<<log2CtuHeightY)+yTile[TileId]
where log2CtuWidthY=log2(ctuWidth) and log2CtuHeightY=log2(ctuHeight). Since the position of the upper left CTU of the tile (xTileInCtus, yTileInCtu) and the upper left coordinates of the CTU (xCtb, yCtb) are often referred to, the derived values may be stored in a table and used. Also, the above derivation may be performed each time reference is made.

The whole of the above processing is shown below in pseudo code.

for (CtbAddrInRs=0;CtbAddrInRs<numCtusInFrame;CtbAddrInRs++)
{
TileId = CtbAddrRsToTileID[CtbAddrInRs]
xCtb = xTile[TileId]+((CtbAddrInRs-firstCtbAddrInRs[TileId])%PicWidthInCtbsY)* ctuUWidth
yCtb = yTile[TileId]+((CtbAddrInRs-firstCtbAddrInRs[TileId])/PicWidthInCtbsY) * ctuHeight
CtbAddrToCtbX[CtbAddrInRs] = xCtb
CtbAddrToCtbY[CtbAddrInRs] = yCtb
}
Here, numCtusInFrame is the number of CTUs in one picture, and numCtusInFrame=numTileColumns*numTileRows.

(Decoding/modification example of CTU for tiles)
Regarding the method of decoding the CTU of the tile described above, another method may be used for deriving xCtb and yCtb without using the CTU address tables CtbAddrToCtbX[] and CtbAddrToCtbY[]. For example:

The CT information decoding unit 3021 uses a target CTU coordinate deriving unit (not shown) to obtain the target CTU's CTU raster scan address CtbAddrInRs from the target CTU's CTU unit X coordinate (col position of CTU) and CTU unit Y coordinate (CTU rx and ry, which are the row position of the CTU), and refer to the CTU coordinate conversion table CtbColToCtbX[], CtbRowToCtbY[] to derive the upper left coordinates (xCtb, yCtb) of the target CTU.

rx = CtbAddrInRs % PicWidthInCtbsY
ry = CtbAddrInRs / PicWidthInCtbsY
xCtb = CtbColToCtbX[rx]
yCtb = CtbRowToCtbY[ry]
The coding_tree_unit() in FIG. 30(a) is an example of syntax using the derivation method of this modified example. The upper left coordinate (xCtb, yCtb) of the target CT is derived using the CTU coordinate conversion table, and the upper left coordinate (xCtb, yCtb) is passed to coding_quadtree(). As shown in FIG. 30(b), the derivation method may be changed depending on whether the tile is available (tile_enabled_flag is true) or not.

(CTU coordinate conversion table derivation part)
The CTU coordinate conversion table deriving unit creates a CTU coordinate conversion table CtbColToCtbX[ ], derive CtbRowToCtbY[].

The CTU coordinate conversion table derivation unit loops the X coordinate rx in CTU units from 0 to num_tile_columns_minus1 and executes the following steps.

(Step 1x)
The CTU coordinate conversion table derivation unit derives a tile ID from the X coordinate rx in CTU units. At this time, since this table is the same for all Y coordinates, the Y coordinate in CTU units (the row position of CTU) is set to 0. therefore,
TileId = CtbAddrRsToTileID[rx]
Here, CtbAddrRsToTileID is a table derived by the tile ID table derivation unit.

(Step 2x)
The CTU coordinate conversion table deriving unit derives the first CTU raster scan address firstCtbAddrInRs[TileId] of the tile containing the target CTU, and derives the intra-tile coordinate xCtbInCtus in units of CTU by the following formula.

xCtbInCtus = rx - firstCtbAddrInRs[TileId] % PicWidthInCtbsY
Here, firstCtbAddrInRs is a table for deriving the leading CTU raster scan address of the tile indicated by the tile ID, and is derived by the leading tile address deriving unit.

Alternatively, it may be derived as follows using a table firstCtbCol[ ] for deriving the CTU unit X coordinate (col position) of the head CTB of the tile indicated by the tile ID.

xCtbInCtus = rx - firstCtbCol[TileId]
The table firstCtbCol[] is derived as follows by the leading tile address deriving unit.

firstCtbCol[TileId] = firstCtbAddrInRs[TileId] % PicWidthInCtbsY
Next, the CTU coordinate conversion table deriving unit multiplies xCtbInCtus by the CTU size ctuWidth to derive the in-tile coordinate xCtbInTile in units of pixels using the following formula.

xCtbInTile = xCtbInCtus*ctuWidth
(Step 3x)
The CTU coordinate conversion table deriving unit derives the upper left X coordinate xCtb of the CTU in the picture from the sum of the in-tile X coordinate xCtbInTile and the in-picture coordinate xTile[TileId] of the tile upper left X coordinate.

xCtb = xTile[TileId]+xCtbInTile
(Step 4x)
Finally, the CTU coordinate conversion table derivation unit stores the upper left X coordinate xCtb of the CTU with respect to the derived rx in the table.

CtbColToCtbX[rx] = xCtb
The above processing can also be expressed as follows using the X coordinate xTileInCtus of the upper left CTU of the tile.

xTileInCtus = firstCtbAddrInRs[TileId] % PicWidthInCtbsY
xCtb = ((rx-xTileInCtus)<<log2CtuWidthY)+xTile[TileId]
where log2CtuWidthY=log2(ctuWidth). Since the X coordinate xTileInCtus of the upper left CTU of the tile and the upper left X coordinate xCtb of the CTU are often referred to, the derived values may be stored in a table and used in this way, or the above derivation may be performed each time the reference is made. good.

The whole of the above processing is shown below in pseudo code.

for ( col=0; col<=num_tile_columns_minus1; col++ )
{
TileId = CtbAddrRsToTileID[col]
xCtb = xTile[TileId]+((rx-firstCtbAddrInRs[TileId])%PicWidthInCtbsY)* ctuWidth
CtbColToCtbX[col] = xCtb
}
Similar to the table for X coordinates, the CTU coordinate conversion table derivation loops the Y coordinate ry in CTU units from 0 to num_tile_rows_minus1 and performs the following steps.

(Step 1y)
The CTU coordinate conversion table derivation unit derives a tile ID from the Y coordinate ry in CTU units. At this time, since this table is the same for all X coordinates, the X coordinate in CTU units (col position of CTU) is set to 0. therefore,
TileId = CtbAddrRsToTileID[ry*PicWidthInCtbsY]
Here, CtbAddrRsToTileID is a table derived by the tile ID table derivation unit.

(Step 2y)
The CTU coordinate conversion table deriving unit derives the first CTU raster scan address firstCtbAddrInRs[TileId] of the tile containing the target CTU, and derives the intra-tile coordinate yCtbInCtus in units of CTUs using the following formula.

yCtbInCtus = ry - firstCtbAddrInRs[TileId] / PicWidthInCtbsY
Here, firstCtbAddrInRs is a table for deriving the leading CTU raster scan address of the tile indicated by the tile ID, and is derived by the leading tile address deriving unit.

Alternatively, it may be derived as follows using a table firstCtbRow[] for deriving the CTU unit Y coordinate (row position) of the head CTB of the tile indicated by the tile ID.

yCtbInCtus = ry - firstCtbRow[TileId]
The table firstCtbRow[] is derived as follows by the leading tile address deriving unit.

firstCtbRow[TileId] = firstCtbAddrInRs[TileId] / PicWidthInCtbsY
Next, the CTU coordinate conversion table deriving unit multiplies yCtbInCtus by the CTU size ctuHeight to derive the in-tile coordinate yCtbInTile in units of pixels using the following formula.

yCtbInTile = yCtbInCtus*ctuHeight
(Step 3y)
The CTU coordinate conversion table derivation unit derives the upper left Y coordinate yCtb of the CTU in the picture from the sum of the intra-tile Y coordinate yCtbInTile and the intra-picture coordinate yTile[TileId] of the tile upper left Y coordinate.

yCtb = yTile[TileId]+yCtbInTile
(Step 4y)
Finally, the CTU coordinate conversion table derivation unit stores the derived upper left Y coordinate yCtb of the CTU related to ry in the table.

CtbRowToCtbY[ry] = yCtb
The above processing can also be expressed as follows using the y-position yTileInCtus of the upper left CTU of the tile.

yTileInCtus = firstCtbAddrInRs[TileId] / PicWidthInCtbsY
yCtb = ((ry-yTileInCtus)<<log2CtuHeightY)+yTile[TileId]
where log2CtuHeightY=log2(ctuHeight). Since the Y coordinate yTileInCtus of the upper left CTU of the tile and the Y coordinate yCtb of the upper left CTU of the CTU are often referred to, the derived values may be stored in a table and used in this way, or the above derivation may be performed each time the reference is made. good.

The whole of the above processing is shown below in pseudo code.

for ( row=0; row<=num_tile_rows_minus1; row++ )
{
TileId = CtbAddrRsToTileID[row*PicWidthInCtbsY]
yCtb = yTile[TileId]+((ry-firstCtbAddrInRs[TileId])/PicWidthInCtbsY)* ctuHeight
CtbRowToCtbY[row] = yCtb
}
Since CtbAddrInTs and CtbAddrInRs can be converted to each other, the table with the raster scan order CTU position CtbAddrInRs as the subscript is derived from the tile scan order CTU position CtbAddrInTs as the subscript, and the subscript at the time of reference is also the tile scan It is also possible to configure using the forward CTU positions converted. Similarly, a table with tile scan order CTU positions CtbAddrInTs as subscripts can be derived using raster scan order CTU positions CtbAddrInRs as subscripts, and the subscripts at the time of reference can also be converted to raster scan order CTU positions and configured. is.

An example of deriving a table CtbAddrRsToTs[] for deriving a tile-scan order CTU address from a raster-scan order CTU address is shown below in pseudocode. CtbAddrRsToTileId[ ] is a tile ID table that derives the tile ID from the raster scan order CTU address derived by the tile ID table derivation unit.

for( ctbAddrRs = 0; ctbAddrRs <numCtusInFrame; ctbAddrRs++ ) {
tileId = CtbAddrRsToTileId[ ctbAddrRs ]
tbX = ctbAddrRs % PicWidthInCtbsY
tbY = ctbAddrRs / PicWidthInCtbsY
CtbAddrRsToTs[ ctbAddrRs ] = 0
for( t = 0; t <tileId; t++ ) {
CtbAddrRsToTs[ctbAddrRs] += TileWidthInCtbsY[tileId]*TileHeightInCtbsY[tileId]
}
CtbAddrRsToTs[ctbAddrRs] += (tbY-TileYInCtbsY[tileId])*TileWidthInCtbsY[tileId]+
tbX-TileXInCtbsY[tileId]
}
With the above configuration, the moving image decoding device that divides an image into CTUs and decodes a moving image in units of CTUs includes a CT information decoding unit that divides a tile into CTUs and divides it recursively, and raster scans the target CTU. A header decoding unit (target CTU coordinate derivation unit) for deriving the upper left coordinate on the picture of the target CTU by referring to the size of one or more tiles from the address, and the CT information decoding unit includes the derived target a means for dividing a target CTU into a coding tree based on the upper left coordinate on the picture of the CTU, and processing the coding tree when the intra-tile coordinate of the lower right position of the divided CT is within the tile size; Prepare.

In a video decoding device that divides an image into tiles and decodes the video in units of tiles,
A header decoding unit (target CTU coordinate deriving unit) that refers to a CTU address table that derives the upper left coordinate of the target CTU from the raster scan address of the target CTU, and derives the CTU address table from the size of one or more tiles. header decoder (CTU address table derivation unit).

(Tile ID table derivation unit)
The tile ID table derivation unit derives the tile ID table CtbAddrRsToTileID[] in the following steps.

(Step 1)
Derive the tile coordinates (columnIdx, rowIdx) of the CTU corresponding to the intra-screen CTU address CtbAddrInRs.

(Step 2)
Derive the screen tile ID from the tile coordinates (columnIdx, rowIdx).

TileId = rowIdx*numTileColumns+columnIdx
where numTileColumns is the number of horizontal tiles in the picture.

(Step 3)
The derived tile ID is stored in the tile ID table CtbAddrRsToTileID[].

CtbAddrRsToTileID[CtbAddrInRs] = TileId
Pseudocode for the above process is shown below.

for(CtbAddrInRs=0;CtbAddrInRs<numCtusInFrame;CtbAddrInRs++)
{
for(col=0;col<numTileColumns;col++)
{
if(CtbAddrInRs%PicWidthInCtbsY<=rightEdgePosInCtus[col])
{
columnIdx = col
break
}
}
for(row=0;row<numTileRows;row++)
{
if(CtbAddrInRs/PicWidthInCtbsY<=bottomEdgePosInCtus[row*numTileColumns])
{
rowIdx = row
break
}
}
CtbAddrRsToTileID[CtbAddrInRs] = rowIdx*numTileColumns+columnIdx
}
(leading tile address derivation unit)
The first tile address derivation unit uses the following steps to obtain the first tile address table firstCtbAd
Derive drInRs[].

(Step 1)
For the TileId corresponding to (col, row) in tile unit coordinates, refer to the width tileWidthInCtus[i] in CTU units of each tile i (0<=i<col) up to the col column, and refer to the tile indicated by TileId. Derive the right edge position rightEdgePosInCtus[TileId] in CTU units. Similarly, refer to the height tileHeightInCtus[j] in CTU units of each tile j (0<=j<row) up to the row column, and derive the bottom position bottomEdgePosInCtus[TileId] in CTU units of the tile indicated by TileId. .

(Step 2)
The left edge position xCtbInCtus of the tile indicated by TileId in CTU units is derived from the right edge position in CTU units of the tile indicated by TileId rightEdgePosInCtus[TileId] and the width of the tile indicated by TileId in CTU units tileWidthInCtus[TileId].

The top position yCtbInCtus of the tile indicated by TileId in CTU units is derived from the bottom edge position bottomEdgePosInCtus[TileId] in CTU units of the tile indicated by TileId and the height tileHeightInCtus[TileId] in CTU units of the tile indicated by TileId.

xCtbInCtus = rightEdgePosInCtus[TileId]-tileWidthInCtus[TileId]+1
yCtbInCtus = bottomEdgePosInCtus[TileId]-tileHeightInCtus[TileId]+1
A CTU raster scan address CtbAddrInRs is derived from the screen position (xCtbInCtus, yCtbInCtus) of the tile upper left pixel indicated by TileId.

CtbAddrInRs = yCtbInCtus*PicWidthInCtbsY+xCtbInCtus
Here, tileWidthInCtus[] and tileHeightInCtus[] are derived by the tile information setting unit.

(Step 3)
Store the derived CTU address in the first tile address table firstCtbAddrInRs[]
firstCtbAddrInRs[TileId] = CtbAddrInRs
Pseudocode for the above process is shown below.

for(row=0; row <numTileRows; row++)
{
for(col=0; col <numTileColumns; col++)
{
TileIdx = row*numTileColumns+col;
rightEdgePosInCTU = 0;
for(i=0; i <= col; i++)
{
rightEdgePosInCTU += tileWidthInCtus[row*numTileColumns+i]
}
rightEdgePosInCtus[TileId] = rightEdgePosInCTU-1
bottomEdgePosInCTU = 0;
for(i=0 ;i <= row; i++)
{
bottomEdgePosInCTU += tileHeightInCtus[i*numTileColumns+col]
}
bottomEdgePosInCtus[tileId] = bottomEdgePosInCTU-1
xCtbInCtus = rightEdgePosInCtus[TileId]-tileWidthInCtus[TileId]+1
yCtbInCtus = bottomEdgePosInCtus[TileId]-tileHeightInCtus[TileId]+1
CtbAddrInRs = yCtbInCtus*PicWidthInCtbsY+xCtbInCtus
firstCtbAddrInRs[TileId] = CtbAddrInRs
}
}
(Processing of CT information decoding)
The CT information decoding process will be described below with reference to FIGS. 7, 8, and 9. FIG. FIG. 7 is a flow chart explaining the operation of the CT information decoding unit 3021 according to one embodiment of the present invention. FIG. 8 is a diagram showing a configuration example of a syntax table of CTU and QT information according to one embodiment of the present invention, and FIG. 9 is a syntax table of MT division information according to one embodiment of the present invention. It is a figure which shows the structural example of. Another example of FIGS. 7-9 is shown in FIGS. 27-29.

CT information decoding in decoding the syntax of coding_tree_unit() in FIG. 8(a) derives the upper left coordinates (xCtb, yCtb) of the target CTU, and recursively decodes the syntax of coding_quadtree(). Use the upper left coordinates (xCtb, yCtb) of the CTU for the initial value of the upper left coordinates (xCb, yCb) of CT in coding_quadtree(). As another derivation method of (xCtb, yCtb), as shown in FIG. 27(b), the derivation method may be changed depending on whether tiles are used (tile_enabled_flag is true) or not. That is, when using tiles, the CTU upper left coordinate (xCtb, yCtb) is derived from the sum of the tile upper left coordinate (xTile[TileId], yTile[TileId]) in the screen and the CTU upper left coordinate in the tile. In other words, the CTU upper left coordinate in the tile is derived from the difference between the CTU in-screen coordinates (rx, ry) in CTU units and the tile in-screen coordinates (TileXInCtbY, TileYInCtbY) in CTU units. , multiplied by the CTU size (left shift by CtbLog2SizeY).

CurrTileId = TileIdTbl[ CtbAddrInRs ]
xCtb = xTile[TileId]+(rx-TileXInCtbsY[CurrTileId]) <<CtbLog2SizeY
yCtb = yTile[TileId]+(ry-TileYInCtbsY[CurrTileId]) <<CtbLog2SizeY
Conversely, when tiles are not used, the CTU upper left coordinates (xCtb, yCtb) are derived from the on-screen coordinates of the CTU in CTU units. That is, the CTU upper left coordinate within the tile is obtained by multiplying the CTU screen coordinate (rx, ry) in CTU units by the CTU size (left shift by CtbLog2SizeY).

rx = CtbAddrInRs % PicWidthInCtbsY
ry = CtbAddrInRs / PicWidthInCtbsY
xCtb = rx << CtbLog2SizeY
yCtb = ry << CtbLog2SizeY
Also, even when tiles are not used, processing may be performed regardless of whether or not tiles are used, assuming that the entire screen is one tile.

(Decryption below CTU)
(CT division of flexible tiles using intra-picture coordinate system)
A CT information decoding unit 3021 decodes CT information from encoded data and recursively decodes a coding tree CT (coding_quadtree). Specifically, the CT information decoding unit 3021 decodes the QT information and decodes the target CT coding_quadtree (x0, y0, log2CbSize, cqtDepth). Note that (x0, y0) is the upper left coordinate of the target CT, log2CbSize is the logarithmic CT size that is the base 2 logarithm of the CT size, and cqtDepth is the CT depth (QT depth) that indicates the CT hierarchy. be.

(S1411) The CT information decoding unit 3021 determines whether or not the decoded CT information has a QT division flag. If there is a QT split flag, the process transitions to S1421; otherwise, the process transitions to S1422.

(S1421) The CT information decoding unit 3021 decodes the QT split flag (split_cu_flag) when it is determined that the logarithmic CT size log2CbSize is larger than MinCbLog2SizeY.
Here, as in the following formula, when using tiles, split_cu_flag indicating whether or not to perform further quadtree splitting is notified in consideration of the upper left coordinates (xCtb, yCtb) of the CTU and the tile size.

if (x0+(1<<log2CbSize)-xTile<=wT &&y0+(1<<log2CbSize)-yTile<=hT&&log2CbSize>MinCbLog2SizeY)
split_cu_flag[x0][y0]
where (x0,y0) is the upper left coordinate of the block, (xTile,yTile) is the upper left coordinate of the tile, log2CbSize is the logarithm of the block size, wT and hT are the width of the tile valid area (or tile encoding area) and The height, MinCbLog2SizeY, is the logarithm of the block's minimum size.

If the right edge coordinate x0+(1<<log2CbSize) and the bottom edge coordinate y0+(1<<log2CbSize) of the block are smaller than the right edge coordinate xTile+wTile and the bottom edge coordinate yTile+hTile of the tile valid area, the target block is Exists in the tile valid area. If the block exists within the tile and the block size is larger than the minimum value (log2CbSize>MinCbLog2SizeY), a flag split_cu_flag indicating whether to further split the block is notified. Set split_cu_flag to 1 if the block is to be further quadtree split, and set split_cu_flag to 0 if the block is not to be quadtree split.

(S1422) Otherwise, the CT information decoding unit 3021 omits decoding the QT split flag split_cu_flag from the encoded data and sets 0 to the QT split flag split_cu_flag.

(S1450) If the QT split flag split_cu_flag is other than 0, the process proceeds to S1451; otherwise, the process proceeds to S1471.

(S1451) The CT information decoding unit 3021 performs QT division. Specifically, the CT information decoding unit 3021 performs logarithmic CT size log2CbSize-1 Decode the four CTs of Decode CTs whose lower right coordinate (xi-xTile[TileId], yi-yTile[TileId]) of each CT within the tile is less than the tile size (wTile[TileId], hTile[TileId]). Conversely, any CT whose lower right coordinate (xi-xTile[TileId], yi+yTile[TileId]) is greater than or equal to the tile size (wTile[TileId], hTile[TileId]) is not decoded. That is, the CT information decoding unit 3021 recursively divides the target CTU into coding trees, and the upper left coordinates (x1, y0), (x0, y1), (x1, y1) of the divided CT are located in the target tile. , then process the coding tree.

coding_quadtree(x0,y0,log2CbSize-1,cqtDepth+1)
if (x1-xTile[TileId] < wTile[TileId])
coding_quadtree(x1,y0,log2CbSize-1,cqtDepth+1)
if (y1-yTile[TileId] < hTile[TileId])
coding_quadtree(x0,y1,log2CbSize-1,cqtDepth+1)
if (x1-xTile[TileId] < wTile[TileId] && y1-yTile[TileId] < hTile[TileId])
coding_quadtree(x1,y1,log2CbSize-1,cqtDepth+1)
Given the above, for example, coding_quadtree(x1,y0,log2CbSize-1,cqtDepth+1,wTile,hTile,xTile,yTile), a block located at (x1,y0) obtained by quadtree partitioning, is , is encoded or decoded if x1 lies within a tile as follows:

if (x1-xTile[TileId]<wTile[TileId])
coding_quadtree(x1,y0,log2CbSize-1,cqtDepth+1)
Here, (x0, y0) is the upper left coordinate of the target CT, and (x1, y1) is derived by adding 1/2 of the CT size (1<<log2CbSize) to (x0, y0) as shown in the following formula. be.

x1 = x0+(1<<(log2CbSize-1))
y1 = y0+(1<<(log2CbSize-1))
1<<N is equivalent to 2 to the Nth power (and so on).

Then, the CT information decoding unit 3021 updates the CT depth cqtDepth indicating the layer of CT and the logarithmic CT size log2CbSize as shown in the following formula.

cqtDepth = cqtDepth + 1
log2CbSize = log2CbSize-1
The CT information decoding unit 3021 continues QT information decoding starting from S1411 using the updated upper left coordinate, logarithmic CT size, and CT depth for lower CTs as well.

After the QT division, the CT information decoding unit 3021 decodes the CT information from the encoded data, and recursively decodes the coding tree CT (MT, coding_multitree (Fig. 9) or multi_type_tree (Fig. 29)). Specifically, the CT information decoding unit 3021 decodes the MT division information, the target CT coding_multitree (x0, y0, log2CbWidth, log2CbHeight, cbtDepth) or multi_type_tree (x0, y0, cbWidth, cbHeight, mttDepth, depthOffset, decrypt partIdx, treeType). Note that log2CbWidth is the logarithmic value of the CT width, log2CbHeight is the logarithmic value of the CT height, and cbtDepth is the CT depth (MT depth) indicating the hierarchy of the multitree. The coding_multitree is explained below.

(S1471) The CT information decoding unit 3021 determines whether or not the decoded CT information has an MT division flag (division information). If there is an MT division flag, the process transitions to S1481. Otherwise, the process proceeds to S1482.

(S1481) CT information decoding section 3021 decodes MT split flag split_mt_flag.

(S1482) The CT information decoding unit 3021 does not decode the MT split flag split_mt_flag from the encoded data, and sets it to 0.

(S1490) If the MT split flag split_mt_flag is other than 0, the CT information decoding unit 3021 transitions to S1491. Otherwise, the CT information decoding unit 3021 does not divide the target CT and ends the process (moves to CU decoding).

(S1491) The CT information decoding unit 3021 performs MT division. Decode the flag split_mt_dir indicating the direction of the MT split and the syntax element split_mt_type indicating whether the MT split is a binary tree or a ternary tree. The CT information decoding unit 3021 processes the coding tree when the upper left coordinate of the divided CT is within the target tile. The upper left coordinates of CT are (x0, y1) or (x1, y0) for binary trees, and (x0, y1), (x0, y2) or (x1, y0), (x2, y0) for ternary trees. is. If the upper left coordinates (x0, y0) of the top CT are outside the tile, the division itself is not performed, so (x0, y0) is always assumed to be inside the tile.

When the MT split type split_mt_type is 0 (two split) and the MT split direction split_dir_flag is 1 (horizontal split), the CT information decoding unit 3021 decodes the following two CTs (BT split information decoding). Decode CTs whose lower coordinates y1-yTile[TileId] of CT(x0, y1) in the tile are less than the tile size hTile[TileId]. Conversely, CTs whose lower coordinates y1-yTile[TileId] of each CT within the tile are equal to or greater than the tile size hTile[TileId] are not decoded.

coding_multitree(x0,y0,log2CbWidth,log2CbHeight-1,cbtDepth+1)
if (y1-yTile[TileId] < hTile[TileId])
coding_multitree(x0,y1,log2CbWidth,log2CbHeight-1,cbtDepth+1)
On the other hand, when the MT split direction split_dir_flag is 0 (vertical split), the following two CTs are decoded (BT split information decoded). Decode CTs whose right coordinate x1-xTile[TileId] of CT(x1, y0) in the tile is less than the tile size wTile[TileId]. Conversely, CTs whose right coordinate x1-xTile[TileId] of each CT within the tile is equal to or greater than the tile size wTile[TileId] are not decoded.

coding_multitree(x0,y0,log2CbWidth-1,log2CbHeight,cbtDepth+1)
if (x1-xTile[TileId] < wTile[TileId])
coding_multitree(x1,y0,log2CbWidth-1,log2CbHeight,cbtDepth+1)
Here, (x1, y1) is derived by the following formula.

x1 = x0+(1<<(log2CbWidth-1))
y1 = y0+(1<<(log2CbHeight-1))
Furthermore, update log2CbWidth or log2CbHeight as shown in the following formula.

log2CbWidth = log2CbWidth - 1
log2CbHeight = log2CbHeight-1
The CT information decoding unit 3021 decodes three CTs (TT split information decoding) when the MT split type split_mt_type indicates 1 (3 splits).

When the MT split direction split_dir_flag is 1 (horizontal split), the following three CTs are decoded. Decode CTs whose lower coordinates yi-yTile[TileId] of each CT (x0, yi) of i=0, 1 in the tile are less than the tile size hTile[TileId]. Conversely, CTs whose lower coordinates yi-yTile[TileId] of each CT within the tile are equal to or larger than the tile size hTile[TileId] are not decoded.

coding_multitree(x0,y0,log2CbWidth,log2CbHeight-2,cbtDepth+1)
if (y1-yTile[TileId] < hTile[TileId])
coding_multitree(x0,y1,log2CbWidth,log2CbHeight-1,cbtDepth+1)
if (y2-yTile[TileId] < hTile[TileId])
coding_multitree(x0,y2,log2CbWidth,log2CbHeight-2,cbtDepth+1)
On the other hand, when the MT split direction split_dir_flag is 1 (vertical split), the following three CTs are decoded (TT split information decoded). Decode CTs whose right coordinate xi-xTile[TileId] of each CT(xi, y0) of i=0, 1 in the tile is less than the tile size wTile[TileId]. Conversely, CTs whose right coordinate xi-xTile[TileId] of each CT within the tile is greater than or equal to the tile size wTile[TileId] are not decoded.

coding_multitree(x0,y0,log2CbWidth-2,log2CbHeight,cbtDepth+1)
if (x1-xTile[TileId] < wTile[TileId])
coding_multitree(x1,y0,log2CbWidth-1,log2CbHeight,cbtDepth+1)
if (x2-xTile[TileId] < wTile[TileId])
coding_multitree(x2,y0,log2CbWidth-2,log2CbHeight,cbtDepth+1)
Here, (x1, y1) and (x2, y2) are derived as in the following formulas.

x1 = x0+(1<<(log2CbWidth-2))
y1 = y0+(1<<(log2CbHeight-2))
x2 = x0+(3<<(log2CbWidth-2))
y2 = y0+(3<<(log2CbHeight-2))
The CT information decoding unit 3021 continues BT division information decoding or TT division information decoding starting from S1471 using the updated upper left coordinate, width and height of CT, and MT depth in the lower CT. do.

Further, when the MT split flag split_mt_flag is 0, that is, when neither QT splitting nor MT splitting is performed, the CT information decoding unit 3021 performs CU (coding_unit (x0, y0, log2CbSize, cqtDepth)) in the CU decoding unit 3022 to decrypt.

Hereinafter, the intra-screen coordinate system refers to using the luminance upper left coordinates of the target block based on the upper left coordinates of the target screen, and the intra-tile coordinate system refers to the luminance of the target block based on the upper left coordinates of the target tile. It is also possible to use upper left coordinates.

As described above, the tile upper left coordinates (xTile, yTile) are subtracted from the upper left coordinates (xi, yi) of each CU expressed in the in-screen coordinate system to derive the upper left coordinates in the tile coordinate system, which are then converted to Decode the split flag and decode each CT by comparing with the tile size (wTile, hTile). As a result, even when the tile size is not an integral multiple of the CTU size, it is possible to efficiently perform CU partitioning without decoding unnecessary partition flags and unnecessary CTs.

(another example of tiling)
Another example of tile division will be described using the syntax table of FIG. In this example, the screen is divided into rectangular tiles, and the coded data is formed using the tiles as a group. The top left coordinates of the tile are xTile, yTile, and the width and height of the tile are wTile, hTile. The CTU address ctbAddrInTs of the leading tile is derived from the table FirstCtbAddrTs storing the leading position of the tile and the position tile_group_address of the tile group. Decode tiles from 0 to num_tiles_in_tile_group_minus1. num_tiles_in_tile_group_minus1 is the number of tiles in the picture minus one. Decode CTUs from 0 to NumCtusInTile[tileIdx] for each tile indicated by TileId. At the end of the tile, decode the end_of_tile_one_bit and the byte alignment bit byte_alignment(). Also, the CTU is decoded using the CTU position j in the tile as an argument of coding_tree_unit. j is set as the value of CtbAddrInTile.

FIG. 31(b) shows an example of decoding each CTU using the CTU position CtbAddrInTile in the tile coordinate system. From the raster scan position CtbAddrInTile in CTU units in the tile and the size TileWidthInCtus in CTU units of the tile, the position in CTU units in the tile (rx, ry) and the position in pixel units in the tile (xCtb, yCtb) are derived. Using the derived CTU position in the intra-tile coordinate system, decode the CTU as follows. Note that the raster position CtbAddrInTile in units of CTU within a tile may be derived by subtracting the start position FirstCtbAddrTs of the tile from the CTU position CtbAddrInTs in units of screen.

CtbAddrInTile = CtbAddrInTs - FirstCtbAddrTs[tile_group_id]
(Decryption below CTU)
(CT division of flexible tiles using intra-tile coordinate system)
The operation of CT information decoding section 3021 when decoding the syntax tables of FIGS. 7, 32, and 33 will be described. CTU coordinates (xCtb, yCtb) are derived using the intra-tile coordinate system with the coordinates of the upper left corner of the tile of this configuration as the origin, and CT information and Decode the MT division information and decode the CT information.

First, the CT information decoding unit 3021 decodes the CT information from the encoded data, and recursively decodes the coding tree CT (coding_quadtree). Specifically, the CT information decoding unit 3021 decodes the QT information and decodes the target CT coding_quadtree (x0, y0, log2CbSize, cqtDepth, treeType).

(S1411) The CT information decoding unit 3021 determines whether or not the decoded CT information has a QT division flag. If there is a QT split flag, the process transitions to S1421; otherwise, the process transitions to S1422.

(S1421) The CT information decoding unit 3021 decodes the QT split flag (qt_split_cu_flag) when it is determined that the logarithmic CT size log2CbSize is larger than MinCbLog2SizeY.
Here, as shown in the following formula, when tiles are used, the upper left coordinates (x0, y0) of CT in the tile coordinate system and the tile size are taken into account to indicate whether or not to perform further quadtree division. qt_split_cu_flag is notified.

if ((((x0+(1<<log2CbSize) <= wTile[TileId])?1:0)+
((y0+(1<<log2CbSize) <= hTile[TileId])?1:0)+
(((1<<log2CbSize) <= MaxBtSizeY)?1:0)) >= 2 &&
log2CbSize > MinQtLog2SizeY)
qt_split_cu_flag[x0][y0]
In other words, if both the coordinates x0+(1<<log2CbSize) of the right edge of the block and the coordinates y0+(1<<log2CbSize) of the bottom edge of the block are less than the tile width wTile and the tile height hTile,
(x0+(1<<log2CbSize) <= wTile[TileId])?1:0)+
((y0+(1<<log2CbSize) <= hTile[TileId])?1:0)>=2
Alternatively, if the coordinate x0+(1<<log2CbSize) of the right end of the block is less than the tile width wTile and the CT size is greater than the maximum BT size MaxBtSizeY,
(x0+(1<<log2CbSize) <= wTile[TileId])?1:0)+
(((1<<log2CbSize) <= MaxBtSizeY)?1:0)) >= 2
Alternatively, if the coordinate y0+(1<<log2CbSize) of the bottom edge of the block is less than the tile height hTile and the CT size is greater than the maximum BT size MaxBtSizeY,
(y0+(1<<log2CbSize) <= hTile[TileId])?1:0)+
(((1<<log2CbSize) <= MaxBtSizeY)?1:0)) >= 2
, decode the QT split flag qt_split_cu_flag from the encoded data.

(S1422) In other cases, the CT information decoding unit 3021 omits decoding the QT split flag qt_split_cu_flag from the encoded data, and sets the QT split flag qt_split_cu_flag to the following using the tile size (wTile, hTile). We derive

Derive 1 in qt_split_cu_flag if any of the following are true:

x0+(1<<log2CbSize) > wTile[TileId] &&(1<<log2CbSize)> MaxBtSizeY
y0+(1<<log2CbSize) > hTile[TileId] &&(1<<log2CbSize)> MaxBtSizeY
Derive 1 in qt_split_cu_flag if all of the following are true:

x0+(1<<log2CbSize) > wTile[TileId]
y0+(1<<log2CbSize) > hTile[TileId]
(1<<log2CbSize) > MinQtSizeY
Otherwise, derive 1 in qt_split_cu_flag.

That is, when the CT right coordinate exceeds the tile size width and the CT size exceeds the maximum BT split size MaxBtSizeY, the tile is always split (qt_split_cu_flag is derived to 1).

When the CT bottom coordinate exceeds the tile size height and the CT size exceeds the maximum BT split size MaxBtSizeY, it must be split (qt_split_cu_flag is derived to 1).

Even when the CT lower right coordinate exceeds the tile size, it is always split (1 is derived to qt_split_cu_flag).

(S1450) If the QT split flag split_cu_flag is other than 0, the process proceeds to S1451; otherwise, the process proceeds to S1471.

(S1451) The CT information decoding unit 3021 performs QT division. Specifically, the CT information decoding unit 3021 performs logarithmic CT size log2CbSize-1 Decode the four CTs of The lower right coordinate of each CT within the tile (xi-xTile[TileId], yi+yT
ile[TileId]) is less than or equal to the tile size (wTile[TileId], hTile[TileId]). Conversely, CTs whose lower right coordinates (xi, yi) are larger than the tile size (wTile[TileId], hTile[TileId]) are not decoded. That is, the CT information decoding unit 3021 recursively divides the target CTU into coding trees, and the upper left coordinates (x1, y0), (x0, y1), and (x1, y1) of the divided CT are in the target tile. , then process the coding tree.

coding_quadtree(x0,y0,log2CbSize-1,cqtDepth+1)
if (x1 < wTile[TileId])
coding_quadtree(x1,y0,log2CbSize-1,cqtDepth+1)
if (y1 < hTile[TileId])
coding_quadtree(x0,y1,log2CbSize-1,cqtDepth+1)
if (x1 < wTile[TileId] && y1 < hTile[TileId])
coding_quadtree(x1,y1,log2CbSize-1,cqtDepth+1)
In the above, for example, coding_quadtree(x1,y0,log2CbSize-1,cqtDepth+1), which is a block located at (x1,y0) obtained by quadtree partitioning, x1 is in the tile as follows Encoded or decoded if located.

if (x1<wTile[TileId])
coding_quadtree(x1,y0,log2CbSize-1,cqtDepth+1)
Here, (x0, y0) is the upper left coordinate of the target CT, and (x1, y1) is derived by adding 1/2 of the CT size (1<<log2CbSize) to (x0, y0) as shown in the following formula. be.

x1 = x0+(1<<(log2CbSize-1))
y1 = y0+(1<<(log2CbSize-1))
1<<N is equivalent to 2 to the Nth power (and so on).

Then, the CT information decoding unit 3021 updates the CT depth cqtDepth indicating the layer of CT and the logarithmic CT size log2CbSize as shown in the following formula.

cqtDepth = cqtDepth + 1
log2CbSize = log2CbSize-1
The CT information decoding unit 3021 continues QT information decoding starting from S1411 using the updated upper left coordinate, logarithmic CT size, and CT depth for lower CTs as well.

After the QT division, the CT information decoding unit 3021 decodes the CT information from the encoded data, and recursively decodes the encoded tree CT (MT, multi_type_tree). Specifically, the CT information decoding unit 3021 decodes the MT division information using the intra-tile coordinates and the tile size, and converts the target CT multi_type_tree (x0, y0, CbWidth, CbHeight, mttDepth, depthOffset, partIdx, treeType) into Decrypt. Note that CbWidth is the CT width, CbHeight is the CT height, and mttDepth is the CT depth (MT depth) indicating the hierarchy of the multi-tree.

(S1471) The CT information decoding unit 3021 determines whether or not the decoded CT information has an MT split flag (split information: mtt_split_cu_flag, mtt_split_cu_vertical_flag, mtt_split_cu_binary_flag). Based on the determination below, if there is an MT division flag, the process proceeds to S1481. Otherwise, the process proceeds to S1482.

(allowSplitBtVer || allowSplitBtHor || allowSplitTtVer || allowSplitTtHor)
&&(x0+cbWidth<=wTile[TileId])&&(y0+cbHeight<=hTile[TileId])
Here, allowSplitBtVer and allowSplitBtHor are derived by the following processing.

If any of the following is true, let allowBtSplit be false (FALTH).
・cbSize <= MinBtSizeY
・cbWidth > MaxBtSizeY
・cbHeight > MaxBtSizeY
・mttDepth >= MaxMttDepth + depthOffset
Except for the above, if all of the following are true, then allowBtSplit is false.
・btSplit = SPLIT_BT_VER
・y0 + cbHeight > hTile[TileId]
Except for the above, if all of the following are true, then allowBtSplit is false.
・btSplit = SPLIT_BT_HOR
・x0 + cbWidth > wTile[TileId]
Except for the above, if all of the following are true, then allowBtSplit is false.
・mttDepth > 0
・partIdx = 1
・MttSplitMode[ x0 ][ y0 ][ mttDepth - 1 ] = parallelTtSplit
Otherwise, let allowBtSplit be true.
・allowBtSplit = TRUE
Here cbSize and parallelTtSplit are set as follows.

For SPLIT_BT_VER(allowSplitBtVer), cbSize=cbWidth, parallelTtSplit= SPLIT_TT_VER
If SPLIT_BT_HOR(allowSplitBtHor) then cbSize=cbHeight, parallelTtSplit=SPLIT_TT_HOR
Note that allowSplitTtVer and allowSplitTtHor are derived by the following processing.

If any of the following is true, let allowTtSplit(allowTtSplirHor, allowTtSplirVer) be false (FALTH).
・cbSize <= 2 * MinTtSizeY
・cbWidth > MaxTtSizeY
・cbHeight > MaxTtSizeY
・mttDepth >= MaxMttDepth + depthOffset
・x0 + cbWidth > wTile[TileId]
・y0 + cbHeight > hTile[TileId]
Otherwise, let allowTtSplit(allowTtSplirHor, allowTtSplirVer) be true.
・allowTtSplit = TRUE
Here cbSize is set as follows.

If SPLIT_TT_VER(allowSplitTtVer) then cbSize=cbWidth
If SPLIT_TT_HOR(allowSplitTtHor) then cbSize=cbHeight
That is, whether or not to encode the MT division flag is determined depending on whether the CT right coordinate exceeds the tile size width or the CT bottom coordinate exceeds the tile size height.

(S1481) The CT information decoding unit 3021 decodes the MT split flag mtt_split_cu_flag.

(S1482) The CT information decoding unit 3021 does not decode the MT split flag mtt_split_cu_flag from the encoded data, but derives it as follows.

Derive 1 in mtt_split_cu_flag if any of the following is true:
・x0 + cbWidth > wTile[TileId]
・x0 + cbHeight > hTile[TileId]
Otherwise, derive 0 in mtt_split_cu_flag. That is, if the right and bottom coordinates of CT in the tile coordinates exceed the tile size, the MT division flag is not decoded.

That is, whether or not to encode the TT division flag is determined depending on whether the CT right coordinate exceeds the tile size width or the CT bottom coordinate exceeds the tile size height.

(S1490) If the MT split flag split_mt_flag is other than 0, the CT information decoding unit 3021 transitions to S1491. Otherwise, the CT information decoding unit 3021 does not divide the target CT and ends the process (moves to CU decoding).

(S1491) The CT information decoding unit 3021 performs MT division. If BT splitting or TT splitting is possible (allowSplitBtHor || allowSplitTtHor ) || ( allowSplitBtVer || allowSplitTtVer )), decode the flag mtt_split_cu_vertical_flag indicating the direction of MT splitting. If both BT splitting and TT splitting are possible in the decrypted splitting method mtt_split_cu_vertical_flag (( allowSplitBtVer && allowSplitTtVer && mtt_split_cu_vertical_flag ) || ( allowSplitBtHor
&& allowSplitTtHor && !mtt_split_cu_vertical_flag) decodes the syntax element mtt_split_cu_binary_flag which indicates whether the MT split is a binary tree or a ternary tree. The CT information decoding unit 3021 processes the coding tree when the upper left coordinate of the divided CT is within the target tile. The upper left coordinate of CT is (x0, y1) or (x1, y0) in a binary tree, or (x0, y1), (x0, y2) or (x1, y0), (x2, y0) in a ternary tree. be. If the upper left coordinates (x0, y0) of the top CT are outside the tile, the division itself is not performed, so it is assumed that (x0, y0) is always inside the tile.

When the MT split type split_mt_type is 0 (two split) and the MT split direction split_dir_flag is 1 (horizontal split), the CT information decoding unit 3021 decodes the following two CTs (BT split information decoding). Decode CTs whose lower coordinate y1 of CT(x0,y1) in the tile is less than the tile size hTile[TileId]. Conversely, CTs whose bottom coordinate y1 of each CT within the tile is equal to or greater than the tile size hTile[TileId] are not decoded.

multi_type_tree(x0,y0,cbWidth,cbHeight/2,mttDepth,depthOffset,0,treeType)
if (y1 < hTile[TileId])
multi_type_tree(x0,y1,cbWidth,cbHeight/2,mttDepth+1,depthOffset,1,treeType)
On the other hand, when the MT split direction split_dir_flag is 0 (vertical split), the following two CTs are decoded (BT split information decoded). Decode CTs whose right coordinate x1 of CT(x1,y0) within the tile is less than the tile size wTile[TileId]. Conversely, CTs whose right coordinate x1 of each CT within the tile is greater than or equal to the tile size wTile[TileId] are not decoded.

multi_type_tree(x0,y0,cbWidth/2,cbHeight,mttDepth+1,depthOffset,0,treeType)
if (x1 < wTile[TileId])
multi_type_tree(x1, y0, cbWidth/2, cbHeightY, mttDepth+1, depthOffset, 1, treeType) where (x1, y1) is derived by the following formula.

x1 = x0 + (cbWidth/2)
y1 = y0 + (cbHeight/2)
Furthermore, update log2CbWidth or log2CbHeight as shown in the following formula.

CbWidth = CbWidth/2
CbHeight = CbHeight/2
When the MT split type split_mt_type indicates 1 (3 splits), the CT information decoding unit 3021
Decode one CT (TT division information decoding).

When the MT split direction split_dir_flag is 1 (horizontal split), the following three CTs are decoded. Decode CTs whose bottom coordinate yi of each CT (x0, yi) of i=0, 1 in the tile is less than the tile size hTile[TileId]. Conversely, CTs whose bottom coordinate yi of each CT within the tile is equal to or larger than the tile size hTile[TileId] are not decoded.

multi_type_tree(x0,y0,cbWidth,cbHeight/4,mttDepth+1,depthOffset,0,treeType)
if (y1 < hTile[TileId])
multi_type_tree(x0,y1,cbWidth,cbHeight/2,mttDepth+1,depthOffset,1,treeType)
if (y2 < hTile[TileId])
multi_type_tree(x0,y2,cbWidth,cbHeight/4,mttDepth+1,depthOffset,2,treeType)
On the other hand, when the MT split direction split_dir_flag is 1 (vertical split), the following three CTs are decoded (TT split information decoded). Decode CTs whose right coordinate xi of each CT (xi, y0) of i=0, 1 in the tile is less than the tile size wTile[TileId]. Conversely, CTs whose right coordinate xi of each CT within the tile is equal to or greater than the tile size wTile[TileId] are not decoded.

multi_type_tree(x0,y0,cbWidth/4,cbHeight,mttDepth+1,depthOffset,0,treeType)
if (x1 < wTile[TileId])
multi_type_tree(x1,y0,cbWidth/2,cbHeight,mttDepth+1,depthOffset,1,treeType)
if (x2 < wTile[TileId])
multi_type_tree(x2,y0,cbWidth/4,cbHeight,mttDepth+1,depthOffset,2,treeType)
Here, (x1, y1) and (x2, y2) are derived as in the following formulas.

x1 = x0 + (cbHeight/4)
y1 = y0 + (3*cbHeight/4)
x2 = x0 + (cbWidth/4)
y2 = y0 + (3*cbWidth/4)
The CT information decoding unit 3021 continues BT division information decoding or TT division information decoding starting from S1471 using the updated upper left coordinate, width and height of CT, and MT depth in the lower CT. do.

In addition, when the MT split flag split_mt_flag is 0, that is, when neither QT splitting nor MT splitting is performed, the CT information decoding unit 3021 causes the CU decoding unit 3022 to perform CU (coding_unit(x0, y0, cbWidth, cbHeight, treeType )).

As described above, by comparing the upper left coordinates (xi, yi) of each CU expressed in a tile with the tile size (wTile, hTile), the division flag is decoded and each CT is decoded. As a result, even when the tile size is not an integral multiple of the CTU size, it is possible to efficiently perform CU partitioning without decoding unnecessary partition flags and unnecessary CTs. In addition, by performing CU division using the in-tile coordinate system, there is a further effect that CU division can be performed with simple processing without conversion from the in-screen coordinate system to the in-tile coordinate system. play.

Also, parameter decoding section 302 includes inter prediction parameter decoding section 303 and intra prediction parameter decoding section 304 (not shown). The predicted image generator 308 includes an inter predicted image generator 309 and an intra predicted image generator 310 (not shown).

(Multi-line intra prediction in flexible tiles)
FIG. 35 is a diagram showing multiline intra prediction. Intra prediction parameter decoding unit 304
And the intra prediction parameter encoding unit 113 decodes or encodes the multiline intra prediction parameters. The intra prediction image generation unit 310 selects which line to refer to among the reference pixels adjacent to the target block boundary according to the syntax element intra_luma_ref_idx. For example, as shown in FIG. 35(a), if intra_luma_ref_idx is 0, 1, 2, the index IntraLumaRefLineIdx (refIdx) indicating the line of the reference picture is set to 0, 1, 3. In other words, the 0, 1, and 3 lines are referenced in order of proximity to the target block.

FIG. 35(b) shows the case where the Y coordinate of the target block touches the CTU boundary. In this case, infer 0 without decoding the syntax element intra_luma_ref_idx.

FIG. 36 is a flowchart showing multiline intra prediction processing when a picture is divided into tiles of sizes not limited to integral multiples of the CTU. FIG. 41(a) is an example of a syntax table.

S4001: The header decoding unit 3020 and the header encoding unit 1110 decode or encode the tile size in units of the CTU size or smaller (the tile size is not limited to an integral multiple of the CTU size). For example, as described above, tile_unit_size_idc may be decoded to derive tile unit sizes wUnitTile or hUnitTile, and tile sizes that are multiples of wUnitTile or hUnitTile may be decoded.

S4002: The CT information decoding unit 3021 and CT information encoding unit 1111 (CT division unit) perform CT division using the intra-tile coordinate system. For example, CT division is performed using the syntax configurations shown in FIGS. 31 to 33 as already described. At this time, the upper left coordinate of CT (x0, y0), that is, the argument of QT division coding_quadtree (x0, y0, …), MTT division multi_type_tree (x0, y0, …) is the tile upper left coordinate as the origin Use the coordinates to be Also, the split syntaxes qt_split_cu_flag and mtt_split_cu_flag refer to the tile coordinates (x0, y0) and the tile sizes wTile and hTile to determine whether decoding or encoding is to be performed.

S4004: The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 use the coordinate values (x0, y0) of the target block in the intra-tile coordinate system to determine whether the target block is below the CTU boundary. judge. If (y0 % ctuSize) > 0, determine below the CTU boundary. If the target block is below the CTU boundary, the process transitions to S4005 to decode or encode the intra reference line index intra_luma_ref_idx. Otherwise, if the target block is in contact with the CTU boundary, 0 is derived (infer) without decoding intra_luma_ref_idx.

S4005: The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 decode or encode the intra reference line index intra_luma_ref_idx.

In addition, in intra prediction, in addition to intra reference line index intra_luma_ref_idx, flag intra_luma_mpm_flag indicating whether it is one of estimated intra prediction modes MostProbableMode (MPM), index intra_luma_mpm_idx for selecting MPM, intra prediction when not MPM The index intra_luma_mpm_remainder indicating the mode may be further decoded or encoded.

Using the derived IntraLumaRefLineIdx (refIdx), the intra prediction image generation unit 310 derives reference picture samples p[x][y] in the following range.

p[x][y] with x = -1-refIdx, y = -1-refIdx..refH-1 and x = -refIdx..refW-1, y =
-1-refIdx
Here, refW and refH are derived by the following formulas.

refW = (nTbH>nTbW) ? (nTbW+(nTbH>>whRatio)+Ceil(nTbH/32)) : (nTbW*2)
refH = (nTbW>nTbH) ? (nTbH+(nTbW>>whRatio)+Ceil(nTbW/32)) : (nTbH*2)
where nTbW and nTbH are the sizes of the target block, whRatio is a value derived by Min(Abs(Log2(nTbW/nTbH), 2) and increases as the aspect ratio of the target block size increases. The value is 0 for a square, 1 for a ratio of nTbH:nTbW of 1:2, and 2 for a ratio of 1:4.

The intra predicted image generation unit 310 generates predicted images predSamples using the reference picture samples p[x][y]. For example, the planar mode may be derived by the following formula.
predV[x][y] = ((nTbH-1-y)*p[x][-1]+(y+1)*p[-1][nTbH])<<Log2(nTbW)
predH[x][y] = ((nTbW-1-x)*p[-1][y]+(x+1)*p[nTbW][-1])<<Log2(nTbH)
predSamples[x][y] = (predV[x][y]+predH[x][y]+nTbW*nTbH)>>(Log2(nTbW)+Log2(nTbH)+1)
According to the intra-prediction parameter decoding unit 304 and the intra-prediction parameter encoding unit 113 configured as described above, the tile size that is an integer multiple of the tile unit size is decoded or encoded, and the quadtree, By performing multi-tree partitioning of a binary tree and a ternary tree, and determining the CTU boundary using the coordinates within the tile (the upper left coordinate of the target block based on the upper left coordinate of the target tile), the tile size is reduced to the CTU. Even if the number is not an integer multiple, multi-line intra prediction can be easily performed at the CTU boundary without using an additional line memory.

FIG. 37 is a flowchart showing multiline intra prediction processing when a picture is divided into tiles of sizes not limited to integral multiples of the CTU. FIG. 41(b) is an example of a syntax table.

S4101: The header decoding unit 3020 and the header encoding unit 1110 decode or encode the tile size in units of the CTU size or less (the tile size is not limited to an integral multiple of the CTU size). For example, as described above, tile_unit_size_idc may be decoded to derive tile unit sizes wUnitTile or hUnitTile, and tile sizes that are multiples of wUnitTile or hUnitTile may be decoded.

S4102: The CT information decoding unit 3021 and CT information encoding unit 1111 (CT division unit) perform CT division using the intra-picture coordinate system. For example, CT division is performed using the syntax configurations shown in FIGS. 27 to 29 as already described. At this time, the upper left coordinate of CT (x0, y0), that is, the argument of QT division coding_quadtree (x0, y0, …), MTT division multi_type_tree (x0, y0, …) is the picture upper left coordinate as the origin Use the coordinates to be Also, the split syntaxes qt_split_cu_flag and mtt_split_cu_flag are determined by referring to the in-picture coordinates (x0, y0), tile upper left coordinates xTile, yTile, and tile sizes wTile, hTile. for example
if (x1-xTile[TileId] < wTile[TileId])
coding_quadtree( x1, y0, log2CbSize-1, cqtDepth+1, treeType)
if (y1-yTile[TileId] < hTile[TileId])
coding_quadtree( x0, y1, log2CbSize-1, cqtDepth+1, treeType)
Thus, CT division may be performed based on the intra-tile coordinates derived by subtracting the tile upper left coordinates from the intra-picture coordinates.

S4103: The intra-prediction parameter decoding unit 304 and the intra-prediction parameter encoding unit 113 convert from intra-picture coordinates to intra-tile coordinates. The intra-tile coordinates (x0-xTile, y0-yTile) are derived by subtracting the upper left tile coordinates (xTile, yTile) in the intra-picture coordinates from the intra-picture coordinates (x0, y0). At this time, only the Y coordinate may be derived.

S4104: The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 use the coordinate values (x0-xTile, y0-yTile) of the target block in the intra-tile coordinate system to determine that the target block is below the CTU boundary. Determine whether or not It is determined to be below the CTU boundary if ((y0-yTile)%ctuSize)>0. If it is below the CTU boundary, the process transitions to S4105 to decode or encode the intra reference line index intra_luma_ref_idx. Otherwise, if the target block is in contact with the CTU boundary, intra_luma_ref_idx is derived (infer) as 0 without being decoded. In other words, using the upper left coordinate (xCb, yCb) of the upper left luminance block with respect to the upper left coordinate of the target tile, which is the coordinate value of the target block in the intra-tile coordinate system, the CTU boundary determination is performed with (yCb%ctuSize)>0. good too.

S4105: The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 decode or encode the intra reference line index intra_luma_ref_idx.

In intra prediction, in addition to the intra reference line index intra_luma_ref_idx, the flag intra_luma_mpm_flag indicating whether or not it is MPM, the index intra_luma_mpm_idx for selecting MPM, and the index intra_luma_mpm_remainder indicating the intra prediction mode when not MPM are further decoded or encoded. may be changed. In other words, using the upper left coordinate (xCb, yCb) of the luminance block with respect to the upper left coordinate of the target tile, which is the coordinate value of the target block in the intra-tile coordinate system, the CTU boundary determination can be performed with (yCb%ctuSize) > 0. good.

The intra predicted image generation unit 310 derives reference picture samples p[x][y] using IntraLumaRefLineIdx (refIdx), and derives a predicted image from the derived reference picture samples p[x][y].

According to the intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 configured as described above, the tile size that is an integer multiple of the tile unit size is decoded or encoded, and the intra-picture coordinates, tile upper left coordinates, and tile size are used to decode or encode the tile size. Perform multi-tree partitioning of quadtrees, binary trees, and ternary trees, and convert intra-picture coordinates (upper left coordinates of the target block based on the upper left coordinates of the target picture) to intra-tile coordinates (upper left coordinates of the target tile). (upper left coordinates of the target block) to determine the CTU boundary, even if the tile size is not an integral multiple of the CTU, it is possible to accurately determine the CTU boundary without using additional line memory. , multi-line intra prediction is possible.

(MPM derivation)
The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 determine the positions (xNbA , yNbA) and (xNbB, yNbB) are derived below.

(xNbA, yNbA) = (xCb-1, yCb+cbHeight-1)
(xNbA, yNbA) = (xCb+cbWidth-1, yCb-1)
The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 derive adjacent intra prediction modes candIntraPredModeA and candIntraPredModeB, which are intra prediction modes of blocks A and B, respectively. Specifically, when X=A or B, the planar mode is set to the adjacent intra prediction modes (candIntraPredModeA, candIntraPredModeB) when at least one of the following conditions is true.
・The X position (xNbX, yNbX) is outside the screen or outside the tile and is not available.
・Prediction mode CuPredMode of X position (xNbX, yNbX) is not intra (MODE_INTRA).
• X is the upper neighbor block B, and the Y coordinate of X (yCb) is above the CTU boundary.

In cases other than the above, the intra prediction mode at the X position (xNbX, yNbX) is set as the adjacent prediction mode. Note that CTU boundary determination for flexible tiles will be described later.

candIntraPredModeX = IntraPredModeY[xNbX][yNbX]
The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 may derive the MPM list candModeList using the following formula.
First, derive the initial list by the following formula.
candModeList[ 0 ] = candIntraPredModeA
candModeList[ 1 ] = !candIntraPredModeA
candModeList[ 2 ] = INTRA_ANGULAR50
candModeList[ 3 ] = INTRA_ANGULAR18
candModeList[ 4 ] = INTRA_ANGULAR46
candModeList[ 5 ] = INTRA_ANGULAR54
If candIntraPredModeB and candIntraPredModeA are equal, do the following.

If candIntraPredModeA is greater than 1, update the list as follows. Entries 3, 4, and 5 store intra prediction modes of -1, +1, and -2 for candIntraPredModeA.
candModeList[ 0 ] = candIntraPredModeA
candModeList[ 1 ] = INTRA_PLANAR
candModeList[ 2 ] = INTRA_DC
candModeList[ 3 ] = 2+((candIntraPredModeA+62)%65)
candModeList[ 4 ] = 2+((candIntraPredModeA-1)%65)
candModeList[ 5 ] = 2+((candIntraPredModeA+61)%65)
Otherwise (if candIntraPredModeB and candIntraPredModeA are not equal), store the two adjacent prediction modes in entries 0 and 1.
candModeList[ 0 ] = candIntraPredModeA
candModeList[ 1 ] = candIntraPredModeB
biggerIdx = candModeList[0]>candModeList[1] ? 0 : 1
Furthermore, if both candIntraPredModeA and candIntraPredModeB are greater than 1 (when both two neighboring prediction modes are Angular prediction (directional prediction)), update the list as follows.
candModeList[ 2 ] = INTRA_PLANAR
candModeList[ 3 ] = INTRA_DC
In addition, if candModeList[biggerIdx]-candModeList[!biggerIdx] is 64 or 1 (i.e. the difference between the two adjacent prediction modes is -1 or 1), do the following and add to entries 4 and 5 the adjacent prediction modes Stores the -2, +2 intra prediction modes of .
candModeList[ 4 ] = 2+((candModeList[biggerIdx]+62)%65)
candModeList[ 5 ] = 2+((candModeList[biggerIdx]-1)%65)
candModeList[biggerIdx]-If candModeList[!biggerIdx] is 64 or other than 1, do the following and store -1 and +1 intra prediction modes of adjacent prediction modes in entries 4 and 5.
candModeList[ 4 ] = 2+((candModeList[biggerIdx]+61)%65)
candModeList[ 5 ] = 2+(candModeList[biggerIdx]%65)
Otherwise, if the sum of candIntraPredModeA and candIntraPredMode is 2 or more (if the two adjacent prediction modes are not DC mode and planar mode), do the following. The 3, 4 and 5 entries store the -1, +1 and -2 intra prediction modes of the adjacent prediction modes.
candModeList[ 2 ] = !candModeList[!biggerIdx]
candModeList[ 3 ] = 2+((candModeList[biggerIdx]+62)%65)
candModeList[ 4 ] = 2+((candModeList[biggerIdx]-1)%65)
candModeList[ 5 ] = 2+((candModeList[biggerIdx]+61)%65)
(Derivation of adjacent intra prediction mode in MPM derivation in flexible tiles)
FIG. 42 is a flowchart showing MPM derivation processing when a picture is divided into tiles of sizes not limited to integral multiples of the CTU. S5001 and S5002 are the same processing as S4001 and S4002, so description thereof is omitted.

S5004: The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 use the coordinate values (xCb, yCb) of the target block in the intra-tile coordinate system to determine that the Y coordinate yCb of the adjacent block X is above the CTU boundary. Determine if there is

(yCb-1)<((yCb>>CtbLog2SizeY)<<CtbLog2SizeY)
In addition to the above determination formulas, a case where any of the following determination formulas is true may be added.
・The position of X is outside the screen or outside the tile and is not available.
・Prediction mode CuPredMode of X position (xNbX, yNbX) is not intra (MODE_INTRA).

S5005: Set the intra prediction mode of the X position (xNbX, yNbX) to the adjacent prediction mode.

candIntraPredModeX = IntraPredModeY[xNbX][yNbX]
The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 set the adjacent intra prediction modes (candIntraPredModeA, candIntraPredModeB) to the planar mode when the following conditions are true.
• X is the upper neighbor block B and the Y coordinate of X (yCb) is above the CTU boundary.

According to the intra-prediction parameter decoding unit 304 and the intra-prediction parameter encoding unit 113 configured as described above, the tile size that is an integer multiple of the tile unit size is decoded or encoded, and the quadtree, By performing multi-tree partitioning of a binary tree and a ternary tree, and determining the CTU boundary using the coordinates in the tile (the upper left coordinate of the target block based on the upper left coordinate of the target tile), the tile size is the CTU size Even if it is not an integer multiple of , it is possible to derive the MPM without using a line memory.

FIG. 43 is a flowchart showing MPM derivation processing when a picture is divided into tiles of sizes not limited to integral multiples of the CTU. S5101, S5102, and S5103 are the same processing as S4101, S4102, and S4103, so description thereof is omitted.

S5104: The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 calculate the Y coordinate (yCb- yTile) is above the CTU boundary.

(yCb-yTile-1) <((yCb-yTile)>>CtbLog2SizeY)<<CtbLog2SizeY
In addition to the above determination formulas, a case where any of the following determination formulas is true may be added.
・The position of X is outside the screen or outside the tile and is not available.
・Prediction mode CuPredMode of X position (xNbX, yNbX) is not intra (MODE_INTRA).

S5105: Set the intra prediction mode of the X position (xNbX, yNbX) to the adjacent prediction mode.

candIntraPredModeX = IntraPredModeY[xNbX][yNbX]
The intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 set the adjacent intra prediction modes (candIntraPredModeA, candIntraPredModeB) to the planar mode when the following conditions are true.
X is the upper neighbor block B, and the Y coordinate of X (yCb) is above the CTU boundary.

According to the intra prediction parameter decoding unit 304 and the intra prediction parameter encoding unit 113 configured as described above, the tile size that is an integer multiple of the tile unit size is decoded or encoded, and the intra-picture coordinates, tile upper left coordinates, and tile size are used to decode or encode the tile size. Multi-tree partitioning of quadtree, binary tree, and ternary tree is performed, and the coordinates in the picture are converted to the coordinates in the tile, and the CTU boundary is determined, even if the tile size is not an integral multiple of the CTU. , MPM derivation is possible without using line memory.

Entropy decoding section 301 outputs inter prediction parameters (prediction mode predMode, merge flag merge_flag, merge index merge_idx, inter prediction identifier inter_pred_idc, reference picture index refIdxLX, prediction vector index mvp_LX_idx, difference vector mvdLX) to inter prediction parameter decoding section 303. do. Also, intra prediction parameters (luminance prediction mode IntraPredModeY, color difference prediction mode IntraPredModeC) are output to intra prediction parameter decoding section 304 . The entropy decoding unit 301 outputs the quantized transform coefficients to the inverse quantization/inverse transform unit 311 .

(CCLM prediction)
The intra prediction image generation unit 310 (CCLM prediction unit) may perform CCLM prediction (Chroma Component Liner Model) that linearly predicts color difference from luminance. In CCLM prediction, the linear prediction relationship between luminance and chrominance (linear prediction parameters a, b) is derived for adjacent pixels (upper and left adjacent pixels) of the target block. *Derived by the relational expression of x+b. More specifically, the pixel value pDsY[x][y] obtained by downsampling the luminance and the prediction parameter a,
A color difference prediction image predSamples[][] is derived from b and a predetermined shift value k by the following equation.

predSamples[x][y] = Clip1C(((pDsY[x][y]*a)>>k)+b)
(CCLM prediction in flexible tiles)
As already explained, the tile size is decoded or encoded as an integer multiple of the tile unit size TileUnitSizeY. The CT division unit uses the intra-picture coordinate system to perform multi-tree division of quadtrees, binary trees, and tri-trees using intra-picture coordinates, tile upper left coordinates, and tile sizes. Alternatively, the intra-tile coordinate system is used to perform multi-tree partitioning of quadtrees, binary trees, and ternary trees using intra-tile coordinates and tile sizes.

The CCLM prediction unit performs CTU boundary determination using the upper left coordinates (xCbC, yCbC) of the chrominance block with respect to the upper left coordinates of the target tile, which are the coordinate values of the target block in the intra-tile coordinate system.

bCTUboudary = yCbC &((1<<(CtbLog2SizeY-1)-1))
In addition, the following may be derived in consideration of samples other than 4:2:0 where luminance and color difference are sampled at 2:1. If SubHeightC is the luminance and chrominance sample ratio,
bCTUboudary = (SubHeightC==2) ? (yCbC &((1<<(CtbLog2SizeY-1)-1)) : ((1<<(CtbLog2SizeY)-1))
bCTUboudary = yCbC &((1<<(CtbLog2SizeY-1)-(SubHeightC-1)))
Alternatively, switching may be performed using chroma_format_idc.

Alternatively, the luminance upper left coordinate (xCb, yCb) in the tile may be used to derive the following formula.

bCTUboudary = yCb &((1<<(CtbLog2SizeY))-1)
Here, the upper left coordinate (xCbC, yCbC) of the upper left chrominance block may be derived from the upper left luminance block coordinate (xCb, yCb) with reference to the tile upper left coordinate.

Multi-tree partitioning of quadtree, binary tree, and ternary tree is performed using the coordinates in the picture, the upper left coordinate of the tile, and the tile size, and the luminance upper left coordinate (xCbInPic, yCbInPic ) and the luminance upper left coordinates (xTile, yTile) of the target tile with reference to the upper left coordinates of the target screen, the upper left luminance block coordinates (xCb, yCb) in the tile may be derived.

xCb = xCbInPic-xTile[TileId]
yCb = yCbInPic-yTile[TileId]
In addition, when using the intra-tile coordinate system and using the intra-tile coordinates and the tile size to perform multi-tree partitioning of quadtrees, binary trees, and tri-trees, the upper left coordinate of the target block is used as it is (xCb, yCb).

The CCLM prediction unit derives the adjacent luminance image pTopDsY by the following procedure. The CCLM predictor is derived by the following formula for x=1..nTbW-1 when the upper pixel is available (availT = TRUE) and not at the CTU boundary (bCTUboundary = FALSE). That is, when bCTUboundary=FALSE, two lines pY[x][-1] and pY[x][-2] of pY[x][y] are used.
pTopDsY[x] = (pY[2*x-1][-2]+pY[2*x-1][-1]+2*pY[2*x][-2]+2*pY[2 *x][-1]+pY[2*x+1][-2]+pY[2*x+1][-1]+4)>>3
Here, pY[][] is the luminance image adjacent to the target block.

If the upper left coordinate is available, it may be further derived by the following formula.
pTopDsY[0]=(pY[-1][-2]+pY[-1][-1]+2*pY[0][-2]+2*pY[0][-1]+pY[ 1][-2]+pY[1][-1]+4)>>3
If upper left adjacent coordinates (coordinates with negative x and y subscripts) are not available, they may be derived by the following equations.
pTopDsY[0] = (pY[0][-2]+pY[0][-1]+1)>>1
The CCLM prediction unit derives the adjacent luminance image pTopDsY by the following procedure. The CCLM predictor is derived by the following formula for x=1..nTbW-1 if the upper pixel is available (availT = TRUE) and is the CTU boundary (bCTUboundary = TRUW).
pTopDsY[x] = (pY[2*x-1][-1]+2*pY[2*x][-1]+pY[2*x+1][-1]+2)>>2
That is, if bCTUboundary=TRUE, only one line of pY[x][-1] out of pY[x][y] is used.

If the upper left adjacent coordinates are available, they may be further derived by the following equations.
pTopDsY[0] = (pY[-1][-1]+2*pY[0][-1]+pY[1][-1]+2)>>2
If the upper left adjacent coordinates are not available, it may be further derived by the following formula.
pTopDsY[0] = pY[0][-1]
The CCLM predictor further derives an adjacent luminance image pLeftDsY[].

The CCLM prediction unit derives the minimum value MinLuma and the maximum value MaxLuma of the adjacent luminance image pTopDsY and the chrominance pixel values ChromaForMinLuma and ChromaForMaxLuma at that position.

The CCLM prediction unit derives the slope a by dividing the difference between ChromaForMinLuma and ChromaForMaxLuma by the difference between MinLuma and MaxLuma. More specifically, for integer arithmetic, the CCLM parameter a is derived by the following equation.

shift = (BitDepthC>8) ? BitDepthC-9 : 0
add = shift ? 1<<(shift-1) : 0
diff = (MaxLuma-MinLuma+add)>>shift
k = 16
If diff is positive, the CCLM predictor derives a using the following formula, otherwise a=0.

div = ((ChromaForMaxLuma-ChromaForMinLuma)*(Floor((65536*65536)/diff)-Floor(65536/diff)*65536)+32768)>>16
a = (((ChromaForMaxLuma-ChromaForMinLuma)*Floor(65536/diff)+div+add)>>shift)
Furthermore, the CCLM predictor derives b.
b = ChromaForMinLuma-((a*MinLuma)>>k)
According to the CCLM prediction unit configured as described above, a tile size that is an integral multiple of the tile unit size is decoded or encoded, and a quadtree, binary tree, or ternary tree is generated using the in-picture coordinates, the tile upper left coordinate, and the tile size. multi-tree division is performed to convert the in-picture coordinates to in-tile coordinates (upper-left coordinates of the target block based on the upper-left coordinates of the target tile) to determine the CTU boundary, or use the in-tile coordinates to determine the 4 Multi-tree partitioning of branch tree, binary tree, and ternary tree is performed, and CTU boundary determination is performed using coordinates within the tile. As a result, even when the tile size is not an integral multiple of the CTU, CCLM prediction is possible without using line memory.

(merge prediction)
FIG. 38(a) is a schematic diagram showing the configuration of the merge prediction parameter derivation unit 3036 according to this embodiment. The merge prediction parameter derivation unit 3036 includes a merge candidate derivation unit 30361 and a merge candidate selection unit 30362 . Note that the merge candidate includes a prediction list usage flag predFlagLX, a motion vector mvLX, and a reference picture index refIdxLX, and is stored in the merge candidate list. The merge candidates stored in the merge candidate list are assigned indices according to a predetermined rule.

The merge candidate derivation unit 30361 derives merge candidates using the motion vectors of the decoded neighboring blocks and the reference picture index refIdxLX as they are. In addition, the merge candidate derivation unit 30361 may apply spatial merge candidate derivation processing, temporal merge candidate derivation processing, joint merge candidate derivation processing, zero merge candidate derivation processing, and spatio-temporal merge candidate derivation processing, which will be described later.

(Spatial merge candidate derivation process)
As the spatial merge candidate derivation process, the merge candidate derivation unit 30361 reads the prediction parameters (prediction list usage flag predFlagLX, motion vector mvLX, reference picture index refIdxLX) stored in the prediction parameter memory 307 according to a predetermined rule, and merges the prediction parameters. set as a candidate. The method of specifying a reference picture is, for example, all blocks adjacent to the target block within a predetermined range (for example, the left edge L, the lower left edge BL, the upper left edge AL, the upper edge A, and the upper right edge AR of the target block). or part). Call each merge candidate L, BL, AL, A, AR.

(Temporal merge candidate derivation process, temporal motion vector derivation process)
As a temporal merge derivation process, the merge candidate derivation unit 30361 reads out the prediction parameters of the block C in the reference image including the lower right CBR of the target block or the center coordinates from the prediction parameter memory 307 and uses them as merge candidates. Store in candidate list mergeCandList[].

FIG. 18 is a diagram showing blocks C and CBR in the reference image. Add the block CBR (block BR) to the merge candidate list mergeCandList[] with priority, and if the block CBR does not have a motion vector (for example, an intra-prediction block) or if the block CBR is located outside the picture, block C Add the motion vector to the vector predictor candidates. By adding the motion vectors of collocated blocks that are highly likely to have different motions as prediction candidates, the number of choices for prediction vectors increases, and coding efficiency increases. The method of specifying the reference picture may be, for example, the reference picture index refIdxLX specified in the slice header, or the minimum one of the reference picture indices refIdxLX of adjacent blocks.

For example, the merge candidate derivation unit 30361 may derive the position of block C (xColCtr, yColCtr) and the position of block CBR (xColBr, yColBr) using the following formulas.

xColCtr = xCb+(bW>>1)
yColCtr = yCb+(bH>>1)
xColBr = xCb+bW
yColBr = yCb + bH
Here, (xCb, yCb) are the upper left coordinates of the target block, and (bW, bH) are the width and height of the target block. Note that bW and bH are also described as cbWidth and cbHeight.
If the block CBR is available, the motion vector of the block CBR is used to derive the merging candidate COL. If block CBR is not available, block C is used to derive COL.

(Configuration of time merge candidate derivation processing for tile boundaries)
The merge candidate derivation unit 30361 (temporal motion prediction unit, temporal motion vector derivation unit) preferably manages the motion vectors in the reference memory in units of CTU lines and fetches only the range required for the target CTU into the internal memory. be. At this time, the merging candidate deriving unit 30361 does not use the block BR when the position (xColBr, yColBr) of the block CBR exceeds the target CTU line so as not to access any area other than the fetched area, and performs the following processing. take advantage of

A processing example of processing the upper left coordinates of the target block using the intra-tile coordinates will be described below. In the following process, (yCb>>CtbLog2SizeY)==(yColBr>>CtbLog2SizeY), if it is determined to be the same CTU line, use (xColBr, yColBr) as the reference position (xRef, yRef), otherwise Use (xColCtr, yColCtr). Furthermore, as shown in the example below, the access may be restricted to 8*8 units by performing a 3-bit left shift after a 3-bit right shift. When referring to a motion vector in the reference picture memory, the upper left coordinate of the tile is added to the reference position to derive the reference position of the in-screen coordinates. You can do it later.

xColBr = xCbInTile + cbWidth
yColBr = yCbInTile + cbHeight
xColCtr = xCbInTile + (cbWidth>>1)
yColCtr = yCbInTile + (cbHeight>>1)
if (((yCb>>CtbLog2SizeY)==(yColBr>>CtbLog2SizeY)) &&(yColBr<hPict)&&(xColBr<wPict)) {
// Reference the motion vector of the reference picture using (xColBr, yColBr). For example, see (xRef, yRef) below.

xRef = ((xColBr>>3)<<3)+xTile[TileId]
yRef = ((yColBr>>3)<<3)+yTile[TileId]
}
else {
// Reference the motion vector of the reference picture using (xColCtr, yColCtr). for example,
xRef = ((xColCtr>>3)<<3)+xTile[TileId]
yRef = ((yColCtr>>3)<<3)+yTile[TileId]
}
FIG. 40 shows the case where the tile division of the reference picture and the tile division of the target picture are the same. In this case, the CTU coordinates within the screen can be derived from the CTU coordinates within the target picture and the CTU coordinates within the reference picture. Also, when managing the MV memory for each CTU line within a tile, it is difficult to refer to the MV memory of a CTU line that is within the screen but not within the tile. Therefore, in this embodiment, the reference range is limited within the tile. It is shown in FIG. 39(a).

xColBr = xCbInTile + cbWidth
yColBr = yCbInTile + cbHeight
xColCtr = xCbInTile+(cbWidth>>1)
yColCtr = yCbInTile+(cbHeight>>1)
if (((yCb>>CtbLog2SizeY)==(yColBr>>CtbLog2SizeY)) &&(yColBr<hTile[TileId])&&
(xColBr<wTile[TileId])) {
// Reference the motion vector of the reference picture using (xColBr, yColBr). For example, see (xRef, yRef) below.

xRef = ((xColBr>>3)<<3)+xTile[TileId]
yRef = ((yColBr>>3)<<3)+yTile[TileId]
}
else {
// Reference the motion vector of the reference picture using (xColCtr, yColCtr). for example,
xRef = ((xColCtr>>3)<<3)+xTile[TileId]
yRef = ((yColCtr>>3)<<3)+yTile[TileId]
}
Also, the above process may be performed for independent tiles (independent_tiles_flag=1).

In order not to refer to the range beyond the tile boundary, use the coordinates within the tile (xCbInTile, yCbInTile) with the origin at the upper left of the tile as the coordinate system for the prediction block, and each reference position exceeds the tile size (wTile, hTile). In some cases, it is appropriate not to refer to it. Furthermore, when referring to the motion vector on the reference picture memory, the tile upper left coordinates are added to the reference position to derive the reference position of the in-screen coordinates. As shown in FIGS. 31 to 34, by performing CT division with intra-tile coordinates, the upper left coordinate of the prediction block is derived with intra-tile coordinates, and by determining the position referred to in temporal prediction, There is an effect that it can be easily determined whether or not.

A processing example of processing the upper left coordinates of the target block using the in-screen coordinates is shown. Unlike when processing using the coordinate system within the tile, after subtracting the upper left coordinate of the tile and converting it to the coordinate within the tile (yColBr-yTile, xColBr-xTile), it is compared with the tile size (wTile, hTile). , determines whether the tile size is exceeded. Also, when determining the tile boundary, the position of the target block in the tile coordinates (yCb-yTile[TileId]) and the position of the reference block (yColBr-yTile[TileId]) are shifted right by the CTU size logarithm CtbLog2SizeY. make a judgment.

xColBr = xCbInPic+cbWidth
yColBr = yCbInPic+cbHeight
xColCtr = xCbInPic+(cbWidth>>1)
yColCtr = yCbInPic+(cbHeight>>1)
if ((((yCb-yTile[TileId])>>CtbLog2SizeY)==((yColBr-yTile[TileId])>>CtbLog2SizeY)) &&(yColBr<hPict)&&(xColBr<wPict)) {
xRef = ((xColBr>>3)<<3)
yRef = ((yColBr>>3)<<3)
}
else {
xRef = ((xColCtr>>3)<<3)
yRef = ((yColCtr>>3)<<3)
}
FIG. 40 shows the case where the tile division of the reference picture and the tile division of the target picture are the same. In this case, the reference range is limited within the tile in this embodiment. FIG. 39(b) shows an example of processing.

xColBr = xCbInPic+cbWidth
yColBr = yCbInPic+cbHeight
xColCtr = xCbInPic+(cbWidth>>1)
yColCtr = yCbInPic+(cbHeight>>1)
if ((((yCb-yTile[TileId])>>CtbLog2SizeY)==((yColBr-yTile[TileId])>>CtbLog2SizeY)) &&((yColBr-yTile[TileId])<hTile[TileId])&& ( (xColBr-xTile[TileId])<wTile[TileId])) {
xRef = ((xColBr>>3)<<3)
yRef = ((yColBr>>3)<<3)
}
else {
xRef = ((xColCtr>>3)<<3)
yRef = ((yColCtr>>3)<<3)
}
The above process may be performed for independent tiles.

By converting the coordinates of the predicted block from the intra-screen coordinates to the intra-tile coordinates, it is possible to easily determine whether or not the prediction block is within the tile range and whether or not it crosses the CTU boundary.

(Method using virtual CTU line)
FIG. 14 is a diagram showing a reference range when a virtual CTU line is set and a motion vector of a reference picture is referenced. In this configuration, the reference picture is divided into virtual CTU lines, and the motion vector of the virtual CTU line corresponding to the target block is referenced.

One configuration divides the reference picture into fixed CTU sizes and sets virtual CTU lines.

FIG. 15 is a flowchart showing the operation of the temporal motion prediction unit when an integer pixel picture is divided into tiles (flexible tiles) of sizes not limited to integer multiples of the CTU.

S3001: In-screen coordinate derivation The temporal motion prediction unit derives the CTU coordinates (xCtbInPic, yCtbInPic) of the in-screen coordinates, the lower right coordinates (xColBr, yColBr), and the center coordinates (xColCtr, yColCtr). In addition, when processing in the in-tile coordinate system, such as when CT division (multi-tree division such as QT, BT, TT) is not performed in the in-tile coordinate system, conversion from the in-tile coordinate system to the in-screen coordinate system can be omitted.
xCtbInPic = xCtbInTile+xTile[currTileId]
yCtbInPic = yCtbInTile+yTile[currTileId]
xColBrInPic = xCbInTile+cbWidth+xTile[currTileId]
yColBrInPic = yCbInTile+cbHeight+yTile[currTileId]
xColCtrInPic = xCbInTile+(cbWidth>>1)+xTile[currTileId]
yColCtrInPic = yCbInTile+(cbHeight>>1)+yTile[currTileId]
S3003: Judgment within Virtual CTU Line It is judged whether or not the in-screen lower right coordinates (xColBrInPic, yColBrInPic) are within the virtual CTU line. Here, the lower right coordinate (xColBrInPic, yColBrInPic) is the virtual CT
Determine if it is within the U line and within the screen.

Judgment formula = ((yColBrInPic>>CtbLog2SizeY) == (yVirCtb>>CtbLog2SizeY)) &&(yColBr<hPict)&&(xColBr<wPict)
S3004: Reference motion vector of reference picture The temporal motion prediction unit refers to the motion vector of the lower right coordinates when the determination formula is true. Here, the coordinates may be further thinned out in units such as 8x8 for reference.

((xColBrInPic>>3)<<3, (yColBrInPic>>3)<<3)
S3005: If the determination formula is false, refer to the motion vector of the center coordinates (xColCtrInPic, yColCtrInPic). Here, the coordinates may be further thinned out in units such as 8x8 for reference.

((xColCtrInPic>>3)<<3, (yColCtrInPic>>3)<<3)
Furthermore, before referring to the motion vector of the center coordinates, it may be determined whether or not the reference coordinates are within the virtual CTU line using the following determination formula.

Judgment formula = (yColCtrInPic>yVirCtbB)
FIG. 16 is a diagram showing a reference range when a virtual CTU line is set and a motion vector of a reference picture is referenced. In this configuration, the reference picture is divided into VBSize×VBSize size units (Log2VBSize=log2(VBSize)), and when viewed from the target CTU, this division position is set to the upper coordinate yCtbInPic of the reference CTU line. is set to the range of motion vectors that can be referenced from the reference picture.

FIG. 17 is a flowchart showing the operation of the temporal motion prediction unit when an integer pixel picture is divided into tiles (flexible tiles) of sizes not limited to integer multiples of the CTU.

S3001: In-screen coordinate derivation The temporal motion prediction unit derives the CTU coordinates (xCtbInPic, yCtbInPic) of the in-screen coordinates, the lower right coordinates (xColBr, yColBr), and the center coordinates (xColCtr, yColCtr). In addition, when processing is performed in the screen coordinate system, such as when CT division (multi-tree division such as QT, BT, TT) is not performed in the tile coordinate system, the screen coordinate system is changed from the tile coordinate system to the screen coordinate system. can be omitted.
xCtbInTile = (xCbInTile>>Log2VBSize)<<Log2VBSize
yCtbInTile = (yCbInTile>>Log2VBSize)<<Log2VBSize
xCtbInPic = xCtbInTile+xTile[currTileId]
yCtbInPic = yCtbInTile+yTile[currTileId]
xColBrInPic = xCbInTile+cbWidth+xTile[currTileId]
yColBrInPic = yCbInTile+cbHeight+yTile[currTileId]
xColCtrInPic = xCbInTile+(cbWidth>>1)+xTile[currTileId]
yColCtrInPic = yCbInTile+(cbHeight>>1)+yTile[currTileId]
S3002: Derivation of Virtual CTU Line Subsequently, the temporal motion prediction unit converts yCtbInPic into coordinates in VBSize units, and derives the upper coordinate yVirCtbT of the virtual CTU line. Also, the lower coordinate yVirCtbB of the position below by a predetermined size (here, the CTU size ctuSize) is set.
yVirCtbT = ((yCtbInPic>>VBLog2Size)<<VBLog2Size)
yVirCtbB = ((yCtbInPic>>VBLog2Size)<<VBLog2Size)+ctuSize
Note that if VBLog2Size is set to CtbLog2SizeY, the processing is the same as when the reference picture is divided into fixed CTU size units.
Although the reference range is limited to the CTU size in the above description, a larger size may be used. For example, the following formula is used to refer to a motion vector in a range of target CTU size+M pixels on a reference picture.
yVirCtbB = ((yCtbInPic>>VBLog2Size)<<VBLog2Size)+ctuSize+M
For example M=16.

S3003: Judgment within Virtual CTU Line The temporal motion prediction unit judges whether or not the lower right coordinate (xColBrInPic, yColBrInPic) of the in-screen coordinates is within the virtual CTU line. Here, it is further determined whether the lower right coordinates (xColBrInPic, yColBrInPic) are within the virtual CTU line and within the screen. If it is within the virtual CTU line, refer to the motion vector of that reference position (xColBrInPic, yColBrInPic).

Judgment formula = (yColBrInPic<yVirCtbB) &&(yColBr<hPict)&&(xColBr<wPict)
S3004: Reference motion vector of reference picture If the determination formula is true, the temporal motion prediction unit refers to the motion vector of the lower right coordinate of the reference picture. Here, the coordinates may be further thinned out in units such as 8x8 for reference.

((xColBrInPic>>3)<<3, (yColBrInPic>>3)<<3)
Although not shown, the following processing may be performed.

S3005: Reference picture motion vector reference 2
The temporal motion prediction unit refers to the motion vector of the center coordinates (xColCtrInPic, yColCtrInPic) of the reference picture when the determination formula is false. Here, the coordinates may be further thinned out in units such as 8x8 for reference.

((xColCtrInPic>>3)<<3, (yColCtrInPic>>3)<<3)
Furthermore, before referring to the motion vector of the center coordinates, it may be determined whether or not the reference coordinates are within the virtual CTU line using the following determination formula.

Judgment formula = (yColCtrInPic<yVirCtbB)
Pseudocode for the above processing is as follows.
if ((yColBrInPic<yVirCtbB) &&(yColBr<hPict)&&(xColBr<wPict)) {
Reference the motion vector using (xColBrInPic, yColBrInPic)
// For example, the following coordinates rounded to 8x8 units would work.

// ((xColBrInPic>>3)<<3, (yColBrInPic>>3)<<3)
}
else if (yColCtrInPic<yVirCtbB) { // Determine virtual CTU line boundary at block center
Reference motion vectors using (xColCtr, yColCtr)
// For example, the following coordinates rounded to 8x8 units would work.

// ((xColCtr>>3)<<3, (yColCtr>>3)<<3)
}
According to the above-configured temporal motion prediction unit, the in-picture coordinate yColBrInPic of the reference block and the virtual CTU coordinate yVirCtbB derived from the in-picture coordinate of the target picture are compared to determine the referability of the reference block. Here, in deriving the virtual CTU coordinates yVirCtbB, right shift and left shift by VBLog2Size are performed to make the virtual CTU coordinates integral multiples of VBSize. Furthermore, when the in-picture coordinate yColBrInPic of the reference block is smaller than the virtual CTU coordinate yVirCtbB derived from the in-picture coordinate of the target picture, the motion vector of the reference picture is referred to. As a result, even if the CTU sizes of the target picture and the reference picture are different, the range in which the motion vector is referred to in the reference picture is limited to the range of the virtual CTU line. It is possible to process, and it is effective in being able to process at high speed. Also, in setting the virtual CTU line, which is the range in which the motion vector is referenced in the reference picture, the CTU line can be set while maintaining the same position as the target CTU as much as possible.

(Modification)
In the above, the virtual CTU line is set with a granularity of VBSize x VBSize, but if the virtual CTU line granularity (e.g., 8 × 8, that is, VBSize = 8) is equal to or smaller than the CTU size granularity (ctuUnitSize), the virtual CTU line The shift processing for VBSize can be omitted in the derivation of .

FIG. 18 is a flowchart showing the operation of the temporal motion prediction unit when dividing an integer-pixel picture into tiles (flexible tiles) of sizes not limited to integer multiples of the CTU. In this example, shift processing is omitted. The virtual CTU line derivation in S3002 in this case may be the following operation.

The upper coordinate yVirCtbT of the virtual CTU line is derived from the in-screen coordinates of the target CTU coordinates. Here, when the target CTU coordinates are in-tile coordinates, the in-screen coordinates of the target CTU are added by adding the in-tile coordinates of the target CTU (target CTU coordinates in the tile coordinate system) and the in-screen coordinates of the tile to derive the in-screen coordinates of the target CTU. and process. Also, the lower coordinate yVirCtbB of the position lower by a predetermined size (here, the CTU size ctuSize) is set. The shift processing for VBSize is omitted here.
yVirCtbT = yCtbInPic
yVirCtbB = yCtbInPic + ctuSize
The pseudocode for the subsequent processing is as follows.
if ((yColBrInPic<yVirCtbB) &&(yColBr<hPict)&&(xColBr<wPict)) {
Reference the motion vector using (xColBrInPic, yColBrInPic)
// For example, the following coordinates rounded to 8x8 units would work.

// ((xColBrInPic>>3)<<3, (yColBrInPic>>3)<<3)
}
else if (yColCtrInPic<yVirCtbB) { // Determine virtual CTU line boundary at block center
Reference motion vectors using (xColCtr, yColCtr)
// For example, the following coordinates rounded to 8x8 units would work.

// ((xColCtr>>3)<<3, (yColCtr>>3)<<3)
According to the above-configured temporal motion prediction unit, the in-picture coordinate yColBrInPic of the reference block and the virtual CTU coordinate yVirCtbB derived from the in-picture coordinate of the target picture are compared to determine the referability of the reference block.

A loop filter 305 is a filter provided in the encoding loop, and is a filter that removes block distortion and ringing distortion to improve image quality. A loop filter 305 applies filters such as a deblocking filter, a sample adaptive offset (SAO), and an adaptive loop filter (ALF) to the decoded image of the CU generated by the addition unit 312 .

The reference picture memory 306 stores the decoded image of the CU generated by the adding unit 312 in a predetermined position for each target picture and target CU.

The prediction parameter memory 307 stores prediction parameters in predetermined positions for each CTU or CU to be decoded. Specifically, the prediction parameter memory 307 stores the parameters decoded by the parameter decoding unit 302, the prediction mode predMode separated by the entropy decoding unit 301, and the like.

A prediction mode predMode, a prediction parameter, and the like are input to the prediction image generation unit 308 . Also, the predicted image generation unit 308 reads a reference picture from the reference picture memory 306 . The predicted image generating unit 308 generates a predicted image of a block or sub-block using the prediction parameter and the read reference picture (reference picture block) in the prediction mode indicated by the prediction mode predMode. Here, a reference picture block is a set of pixels on a reference picture (usually rectangular and therefore called a block), and is an area referred to for generating a prediction image.

The inverse quantization/inverse transform unit 311 inversely quantizes the quantized transform coefficients input from the entropy decoding unit 301 to obtain transform coefficients. These quantized transform coefficients are converted to DCT (Discrete Cosine Transform), DST (Discrete Sine Transform), and KLT (Karyhnen Loeve Transform) for prediction errors in the encoding process. It is a coefficient obtained by performing frequency conversion such as , and quantizing it. The inverse quantization/inverse transform unit 311 performs inverse frequency transform such as inverse DCT, inverse DST, and inverse KLT on the obtained transform coefficients to calculate prediction errors. Inverse quantization/inverse transform section 311 outputs the prediction error to addition section 312 .

The addition unit 312 adds the predicted image of the block input from the predicted image generation unit 308 and the prediction error input from the inverse quantization/inverse transform unit 311 for each pixel to generate a decoded image of the block. The adder 312 stores the decoded image of the block in the reference picture memory 306 and also outputs it to the loop filter 305 .

(Configuration of video encoding device)
Next, the configuration of the video encoding device 11 according to this embodiment will be described. FIG. 19 is a block diagram showing the configuration of the video encoding device 11 according to this embodiment. The video encoding device 11 includes a predicted image generation unit 101, a subtraction unit 102, a transformation/quantization unit 103, an inverse quantization/inverse transformation unit 105, an addition unit 106, a loop filter 107, a prediction parameter memory (prediction parameter storage unit , frame memory) 108 , reference picture memory (reference image storage unit, frame memory) 109 , coding parameter determination unit 110 , parameter coding unit 111 and entropy coding unit 104 .

The predicted image generation unit 101 generates a predicted image for each CU, which is an area obtained by dividing each picture of the image T. FIG. The operation of the predicted image generation unit 101 is the same as that of the predicted image generation unit 308 already described, and the description thereof is omitted.

The subtraction unit 102 subtracts the pixel values of the predicted image of the block input from the predicted image generation unit 101 from the pixel values of the image T to generate a prediction error. Subtraction section 102 outputs the prediction error to transform/quantization section 103 .

Transform/quantization section 103 calculates transform coefficients by frequency transforming the prediction error input from subtraction section 102, and derives quantized transform coefficients by quantization. The transform/quantization unit 103 outputs the quantized transform coefficients to the entropy coding unit 104 and the inverse quantization/inverse transform unit 105 .

The inverse quantization/inverse transform unit 105 is the same as the inverse quantization/inverse transform unit 311 (FIG. 5) in the moving image decoding device 31, and description thereof is omitted. The calculated prediction error is output to addition section 106 .

Parameter coding section 111 includes header coding section 1110, CT information coding section 1111, CU coding section 1112 (prediction mode coding section), entropy coding section 104, and inter prediction parameter coding section 112 (not shown). An intra prediction parameter coding unit 113 is provided. CU encoding section 1112 further comprises TU encoding section 1114 .

The general operation of each module will be described below. A parameter encoding unit 111 performs encoding processing of parameters such as header information, division information, prediction information, and quantized transform coefficients.

CT information encoding section 1111 encodes QT, MT (BT, TT) division information and the like.

The CU encoding unit 1112 encodes CU information, prediction information, TU split flag split_transform_flag, CU residual flags cbf_cb, cbf_cr, cbf_luma, and the like.

TU encoding section 1114 encodes QP update information (quantization correction value) and quantization prediction error (residual_coding) when prediction error is included in TU.

The entropy coding unit 104 converts syntax elements supplied from a supply source into binary data, generates coded data by an entropy coding method such as CABAC, and outputs the coded data. In the example shown in FIG. 19, the supply sources of syntax elements are CT information encoding section 1111 and CU encoding section 1112 . The syntax elements are inter prediction parameters (prediction mode predMode, merge flag merge_flag, merge index merge_idx, inter prediction identifier inter_pred_idc, reference picture index refIdxLX, prediction vector index mvp_LX_idx, difference vector mvdLX), intra prediction parameters (prev_intra_luma_pred_flag, mpm_idx, rem_selected_mode_flag , rem_selected_mode, rem_non_selected_mode, ), quantized transform coefficients, and so on.

The addition unit 106 adds pixel values of the predicted image of the block input from the predicted image generation unit 101 and the prediction error input from the inverse quantization/inverse transform unit 105 for each pixel to generate a decoded image. The addition unit 106 stores the generated decoded image in the reference picture memory 109 .

A loop filter 107 applies a deblocking filter, SAO, and ALF to the decoded image generated by the adder 106 . Note that the loop filter 107 does not necessarily include the three types of filters described above, and may be configured with only a deblocking filter, for example.

The prediction parameter memory 108 stores the prediction parameters generated by the coding parameter determination unit 110 in predetermined positions for each current picture and CU.

The reference picture memory 109 stores the decoded image generated by the loop filter 107 in a predetermined position for each target picture and CU.

Coding parameter determination section 110 selects one set from a plurality of sets of coding parameters. The coding parameter is the above-described QT, BT or TT division information, prediction parameters, or parameters to be coded generated in relation to these. The predicted image generating unit 101 generates predicted images using these coding parameters.

Coding parameter determination section 110 calculates an RD cost value indicating the amount of information and the coding error for each of the plurality of sets. The RD cost value is, for example, the sum of the code amount and the value obtained by multiplying the squared error by the coefficient λ. The code amount is the information amount of the encoded stream Te obtained by entropy-encoding the quantization error and encoding parameters. The squared error is the sum of squares of the prediction errors calculated in subtraction section 102 . The coefficient λ is a preset real number greater than zero. Coding parameter determination section 110 selects a set of coding parameters that minimizes the calculated cost value. As a result, entropy encoding section 104 outputs the selected set of encoding parameters as encoded stream Te. Coding parameter determination section 110 stores the determined coding parameters in prediction parameter memory 108 .

Note that a part of the video encoding device 11 and the video decoding device 31 in the above-described embodiment, for example, the entropy decoding unit 301, the parameter decoding unit 302, the loop filter 305, the prediction image generation unit 308, the inverse quantization/inverse Transformation unit 311, addition unit 312, prediction image generation unit 101, subtraction unit 102, transformation/quantization unit 103, entropy coding unit 104, inverse quantization/inverse transformation unit 105, loop filter 107, coding parameter determination unit 110 , the parameter encoding unit 111 may be realized by a computer. In that case, a program for realizing this control function may be recorded in a computer-readable recording medium, and the program recorded in this recording medium may be read into a computer system and executed. The "computer system" here is a computer system built in either the moving image encoding device 11 or the moving image decoding device 31, and includes hardware such as an OS and peripheral devices. The term "computer-readable recording medium" refers to portable media such as flexible discs, magneto-optical discs, ROMs and CD-ROMs, and storage devices such as hard disks built into computer systems. Furthermore, "computer-readable recording medium" means a medium that dynamically stores a program for a short period of time, such as a communication line for transmitting a program via a network such as the Internet or a communication line such as a telephone line. In that case, it may also include a memory that holds the program for a certain period of time, such as a volatile memory inside a computer system that serves as a server or client. Further, the program may be for realizing part of the functions described above, or may be capable of realizing the functions described above in combination with a program already recorded in the computer system.

Also, part or all of the moving image encoding device 11 and the moving image decoding device 31 in the above-described embodiments may be realized as an integrated circuit such as LSI (Large Scale Integration). Each functional block of the moving image encoding device 11 and the moving image decoding device 31 may be processorized individually, or may be partially or wholly integrated and processorized. Also, the method of circuit integration is not limited to LSI, but may be realized by a dedicated circuit or a general-purpose processor. In addition, when an integrated circuit technology that replaces LSI appears due to advances in semiconductor technology, an integrated circuit based on this technology may be used.

Although one embodiment of the present invention has been described in detail above with reference to the drawings, the specific configuration is not limited to the above-described one, and various design changes and the like can be made without departing from the gist of the present invention. It is possible to

A video decoding device according to an aspect of the present invention is a video decoding device that divides an image into tiles, divides the tiles into CTUs, and decodes the video in units of CTUs, and is a minimum unit of tile size. to a predetermined value, and a CT information decoding unit that decodes the CTU from the encoded stream. The header decoding unit uses the minimum tile size unit to determine It is characterized by deriving

The moving picture decoding device according to an aspect of the present invention is characterized in that the predetermined value is a minimum CTU size.

In the video decoding device according to one aspect of the present invention, the predetermined value is an integral multiple of the minimum CTU size.

In the video decoding device according to one aspect of the present invention, the predetermined value is 8 or 16.

In the video decoding device according to an aspect of the present invention, the predetermined value is an integral multiple of the minimum CTU size in the horizontal direction and 8 or 16 in the vertical direction.

In the video decoding device according to an aspect of the present invention, the minimum unit of tile size is derived using a minimum CTU size and a difference value between the minimum unit of tile size and the minimum CTU size. do.

In the video decoding device according to an aspect of the present invention, the difference value is decoded from SPS encoded data.

In the video decoding device according to an aspect of the present invention, the difference value is decoded from PPS encoded data.

The moving image decoding device according to an aspect of the present invention is characterized in that the minimum unit of tile size does not exceed a CTU size.

In the video decoding device according to an aspect of the present invention, the predetermined value is set to a value less than the minimum CTU size when each tile can be processed independently, and set to the minimum CTU size otherwise. Characterized by

In the moving picture decoding device according to an aspect of the present invention, the predetermined value is characterized by setting the minimum unit of tiles to be smaller when each tile can be processed independently than in the other case.

In the video decoding device according to an aspect of the present invention, the predetermined value is set according to any one of sub-CU, motion vector storage unit for TMVP, and difference quantization parameter notification unit. .

A video encoding device according to an aspect of the present invention is a video encoding device that divides an image into tiles, divides the tiles into CTUs, and encodes the video in units of CTUs. A header encoding unit that sets the unit to a predetermined value, and a CT information encoding unit that encodes the CTU and generates an encoded stream. It is characterized by deriving the tile upper left position and the tile size.

[Application example]
The moving image encoding device 11 and the moving image decoding device 31 described above can be used by being installed in various devices for transmitting, receiving, recording, and reproducing moving images. The moving image may be a natural moving image captured by a camera or the like, or may be an artificial moving image (including CG and GUI) generated by a computer or the like.

First, it will be described with reference to FIG. 20 that the moving image encoding device 11 and the moving image decoding device 31 described above can be used for transmitting and receiving moving images.

FIG. 20(a) is a block diagram showing the configuration of a transmission device PROD_A equipped with the video encoding device 11. FIG. As shown in FIG. 20(a), the transmitting device PROD_A includes an encoding unit PROD_A1 that obtains encoded data by encoding a moving image, and modulates a carrier wave with the encoded data obtained by the encoding unit PROD_A1. and a transmitter PROD_A3 for transmitting the modulated signal obtained by the modulator PROD_A2. The video encoding device 11 described above is used as this encoding unit PROD_A1.

The transmission device PROD_A uses a camera PROD_A4 for capturing a moving image, a recording medium PROD_A5 for recording the moving image, an input terminal PROD_A6 for externally inputting the moving image, and , and an image processing unit A7 for generating or processing an image. FIG. 20(a) exemplifies the configuration in which the transmitter PROD_A has all of these, but some of them may be omitted.

The recording medium PROD_A5 may record an unencoded moving image, or record a moving image encoded by an encoding scheme for recording different from the encoding scheme for transmission. can be anything. In the latter case, a decoding unit (not shown) may be interposed between the recording medium PROD_A5 and the encoding unit PROD_A1 to decode the encoded data read from the recording medium PROD_A5 according to the recording encoding method.

FIG. 20(b) is a block diagram showing the configuration of the receiving device PROD_B equipped with the video decoding device 31. As shown in FIG. As shown in FIG. 20(b), the receiver PROD_B includes a receiver PROD_B1 that receives a modulated signal, a demodulator PROD_B2 that obtains encoded data by demodulating the modulated signal received by the receiver PROD_B1, and a demodulator PROD_B2. and a decoding unit PROD_B3 that obtains a moving image by decoding the encoded data obtained by PROD_B2. The video decoding device 31 described above is used as this decoding unit PROD_B3.

The receiving device PROD_B supplies the moving image output from the decoding unit PROD_B3 to a display PROD_B4 for displaying the moving image, a recording medium PROD_B5 for recording the moving image, and an output terminal for outputting the moving image to the outside. PROD_B6 may also be provided. FIG. 20(b) exemplifies a configuration in which the receiving device PROD_B has all of these, but some of them may be omitted.

The recording medium PROD_B5 may be for recording unencoded moving images, or may be encoded by a recording encoding scheme different from the transmission encoding scheme. may In the latter case, an encoding unit (not shown) may be interposed between the decoding unit PROD_B3 and the recording medium PROD_B5 to encode the moving image acquired from the decoding unit PROD_B3 according to the recording encoding method.

A transmission medium for transmitting the modulated signal may be wireless or wired. Further, the transmission mode for transmitting the modulated signal may be broadcasting (here, transmission mode in which the destination is not specified in advance), or communication (here, transmission mode in which the destination is specified in advance). aspect) may be used. That is, transmission of the modulated signal may be realized by any of wireless broadcasting, wired broadcasting, wireless communication, and wired communication.

For example, a digital terrestrial broadcasting station (broadcasting equipment, etc.)/receiving station (television receiver, etc.) is an example of a transmitting device PROD_A/receiving device PROD_B that transmits and receives a modulated signal by radio broadcasting. A broadcasting station (broadcasting equipment, etc.)/receiving station (television receiver, etc.) of cable television broadcasting is an example of a transmitting device PROD_A/receiving device PROD_B that transmits/receives a modulated signal by cable broadcasting.

In addition, servers (workstations, etc.) and clients (television receivers, personal computers, smartphones, etc.) for VOD (Video On Demand) services and video sharing services using the Internet are transmission devices that transmit and receive modulated signals through communication. This is an example of PROD_A/receiving device PROD_B (usually, in LAN, either wireless or wired transmission medium is used, and in WAN, wired transmission medium is used). Here, personal computers include desktop PCs, laptop PCs, and tablet PCs. Smartphones also include multifunctional mobile phone terminals.

A client of the video sharing service has a function of decoding encoded data downloaded from a server and displaying the data on a display, and a function of encoding a video captured by a camera and uploading it to the server. That is, the client of the video sharing service functions as both the transmitting device PROD_A and the receiving device PROD_B.

Next, it will be described with reference to FIG. 21 that the moving image encoding device 11 and the moving image decoding device 31 described above can be used for recording and reproducing moving images.

FIG. 21(a) is a block diagram showing the configuration of a recording device PROD_C equipped with the moving image encoding device 11 described above. As shown in FIG. 21(a), the recording device PROD_C has an encoding unit PROD_C1 that obtains encoded data by encoding a moving image, and writes the encoded data obtained by the encoding unit PROD_C1 to the recording medium PROD_M. and a writing unit PROD_C2. The video encoding device 11 described above is used as this encoding unit PROD_C1.

The recording medium PROD_M may be (1) a type built into the recording device PROD_C, such as a HDD (Hard Disk Drive) or SSD (Solid State Drive), or (2) an SD memory. It may be of a type connected to the recording device PROD_C, such as a card or USB (Universal Serial Bus) flash memory. Disc: registered trademark) may be loaded in a drive device (not shown) incorporated in the recording device PROD_C.

In addition, the recording device PROD_C includes a camera PROD_C3 for capturing the moving image, an input terminal PROD_C4 for inputting the moving image from the outside, and a receiving terminal for receiving the moving image as a supply source of the moving image to be input to the encoding unit PROD_C1. A unit PROD_C5 and an image processing unit PROD_C6 that generates or processes an image may be further included. FIG. 21(a) exemplifies the configuration in which the recording device PROD_C includes all of these, but some may be omitted.

Note that the receiving unit PROD_C5 may receive an unencoded moving image, or receive encoded data encoded by an encoding scheme for transmission that is different from the encoding scheme for recording. It may be something to do. In the latter case, it is preferable to interpose a decoding unit for transmission (not shown) that decodes encoded data encoded by an encoding method for transmission between the receiving unit PROD_C5 and the encoding unit PROD_C1.

Such a recording device PROD_C includes, for example, a DVD recorder, a BD recorder, an HDD (Hard Disk Drive) recorder, etc. (In this case, the input terminal PROD_C4 or the receiver PROD_C5 is the main supply source of moving images.) . In addition, a camcorder (in this case, the camera PROD_C3 is the main source of moving images), a personal computer (in this case, the receiver PROD_C5 or the image processing unit C6 is the main source of moving images), a smartphone (in this case, the camera PROD_C3 is the main source of moving images) In this case, the camera PROD_C3 or the receiver PROD_C5 is the main supply source of moving images) is also an example of such a recording device PROD_C.

FIG. 21(B) is a block showing the configuration of a playback device PROD_D equipped with the video decoding device 31 described above. As shown in FIG. 21(b), the playback device PROD_D obtains a moving image by reading out the encoded data written in the recording medium PROD_M and decoding the encoded data read by the reading unit PROD_D1. and a decoding unit PROD_D2. The video decoding device 31 described above is used as this decoding unit PROD_D2.

Note that the recording medium PROD_M may be (1) a type built into the playback device PROD_D, such as an HDD or SSD, or (2) an SD memory card, USB flash memory, or the like. It may be of a type that is connected to the playback device PROD_D, or (3) like a DVD or BD, it may be loaded into a drive device (not shown) built into the playback device PROD_D. good.

Further, the playback device PROD_D includes a display PROD_D3 for displaying the moving image, an output terminal PROD_D4 for outputting the moving image to the outside, and a transmission unit for transmitting the moving image, as destinations to which the moving image output by the decoding unit PROD_D2 is supplied. PROD_D5 may also be provided. FIG. 21(b) exemplifies a configuration in which the playback device PROD_D includes all of these, but some may be omitted.

The transmission unit PROD_D5 may transmit an unencoded moving image, or transmit encoded data encoded by an encoding scheme for transmission different from the encoding scheme for recording. It may be something to do. In the latter case, it is preferable to interpose an encoding unit (not shown) that encodes a moving image using an encoding method for transmission between the decoding unit PROD_D2 and the transmitting unit PROD_D5.

Such a playback device PROD_D includes, for example, a DVD player, a BD player, an HDD player, etc. (In this case, the output terminal PROD_D4 to which a television receiver or the like is connected is the main supply destination of moving images.) . In addition, television receivers (in this case, display PROD_D3 is the main supply of moving images), digital signage (also called electronic signboards, electronic bulletin boards, etc.), and display PROD_D3 or transmission unit PROD_D5 is the main supply of moving images. first), desktop PC (in this case, output terminal PROD_D4 or transmitter PROD_D5 is the main destination of the video), laptop or tablet PC (in this case, display PROD_D3 or transmitter PROD_D5 An example of such a playback device PROD_D is a smartphone (in this case, the display PROD_D3 or the transmission unit PROD_D5 is the main destination of moving images).

(Hardware realization and software realization)
Further, each block of the moving image decoding device 31 and the moving image encoding device 11 described above may be realized in hardware by a logic circuit formed on an integrated circuit (IC chip), or may be implemented by a CPU (Central Processing Unit). Unit) may be used for software implementation.

In the latter case, each of the above devices has a CPU that executes the instructions of the program that implements each function, a ROM (Read Only Memory) that stores the above program, and a RAM (Random Memory) that expands the above program.
Access Memory), and a storage device (recording medium) such as a memory for storing the above program and various data. An object of the embodiments of the present invention is a computer-readable record of the program code (executable program, intermediate code program, source program) of the control program for each of the above devices, which is software for realizing the above functions. It can also be achieved by supplying a medium to each of the devices described above and causing the computer (or CPU or MPU) to read and execute the program code recorded on the recording medium.

Examples of the recording medium include tapes such as magnetic tapes and cassette tapes, magnetic disks such as floppy (registered trademark) disks/hard disks, CD-ROMs (Compact Disc Read-Only Memory)/MO disks (Magneto-Optical discs). ) / MD (Mini Disc) / DVD (Digital Versatile Disc) / CD-R (CD Recordable) / Discs including optical discs such as Blu-ray Disc (registered trademark), IC cards (including memory cards) / cards such as optical cards, mask ROM / EPROM (Erasable Programmable Read-Only Memory) / EEPROM (Electrically Erasable and Programmable Read-Only Memory: registered trademark) / semiconductor memory such as flash ROM, or PLD (Programmable logic device ) and logic circuits such as FPGA (Field Programmable Gate Array) can be used.

Further, each device may be configured to be connectable to a communication network, and the program code may be supplied via the communication network. This communication network is not particularly limited as long as it can transmit the program code. Internet, intranet, extranet, LAN (Local Area Network), ISDN (Integrated Services Digital N
network), VAN (Value-Added Network), CATV (Community Antenna television/Cable Television) communication network, Virtual Private Network, telephone line network, mobile communication network, satellite communication network, etc. . Also, the transmission medium constituting this communication network is not limited to a specific configuration or type as long as it can transmit the program code. For example, even wired such as IEEE (Institute of Electrical and Electronic Engineers) 1394, USB, power line carrier, cable TV line, telephone line, ADSL (Asymmetric Digital Subscriber Line) line, infrared rays such as IrDA (Infrared Data Association) and remote control , BlueTooth (registered trademark), IEEE802.11 wireless, HDR (High Data Rate), NFC (Near Field Communication), DLNA (Digital Living Network Alliance: registered trademark), mobile phone networks, satellite circuits, terrestrial digital broadcasting networks, etc. Also available wirelessly. Embodiments of the invention may also be implemented in the form of a computer data signal embedded in a carrier wave, with the program code embodied in electronic transmission.

The embodiments of the present invention are not limited to the embodiments described above, and various modifications are possible within the scope of the claims. That is, the technical scope of the present invention also includes embodiments obtained by combining technical means appropriately modified within the scope of the claims.

INDUSTRIAL APPLICABILITY Embodiments of the present invention are preferably applied to a moving image decoding device that decodes encoded image data and a moving image encoding device that generates encoded image data. be able to. Also, the present invention can be suitably applied to the data structure of encoded data generated by a video encoding device and referenced by a video decoding device.

11 moving image encoding device 31 moving image decoding devices 101 and 308 predicted image generation unit 104 entropy encoding unit (encoding unit)
107, 305 loop filter 111 parameter coding unit 1111 CT information coding unit (CT division unit)
112 inter prediction parameter coding unit 113 intra prediction parameter coding unit (intra prediction unit)
301 entropy decoding unit 302 parameter decoding unit (dividing unit)
3021 CT information decoding unit (CT dividing unit)
303 inter prediction parameter decoding unit 304 intra prediction parameter decoding unit (intra prediction unit)
308 predicted image generation unit 309 inter predicted image generation unit 310 intra predicted image generation unit 3036 merge prediction parameter derivation unit 30361 merge candidate derivation unit (temporal motion prediction unit)
30362 merge candidate selector

Claims (7)

a derivation unit for deriving a tile index;
a CT splitting unit that performs quadtree splitting , binary tree splitting , or triple tree splitting ;
a merge candidate deriving unit that stores temporal motion vectors, which are merge candidates of the target block, in a merge candidate list ;
Deriving the Y coordinate of the lower right position of the target block by adding the height of the target block to the Y coordinate of the target block,
Deriving virtual coordinates using the coordinates of the target tile specified by the tile index and the CTU size,
a temporal motion prediction unit that compares the Y coordinate of the lower right position of the target block with the virtual coordinates to determine the possibility of referring to the lower right reference block;
The video decoding device , wherein when the lower right reference block can be referenced, the temporal motion vector as the merge candidate is derived using the motion vector of the lower right reference block . when the Y coordinate of the lower right position is above the virtual coordinates , the temporal motion vector that is the merge candidate is derived using the motion vector of the lower right reference block;
2. If the Y coordinate of the lower right position is not above the virtual coordinate , the temporal motion vector as the merging candidate is derived using the motion vector of the central reference block. 3. The video decoding device according to . The virtual coordinates are derived by adding the CTU size to second virtual coordinates derived by converting the Y coordinate of the target block into coordinates of a predetermined unit VBSize. The moving picture decoding device according to claim 1. 4. The virtual coordinates are derived by right-shifting the Y-coordinate of the target block by a logarithmic value of the predetermined unit VBSize and then left-shifting the logarithmic value. The video decoding device described. a header information decoding unit that decodes a tile size that is an integral multiple of the tile unit size;
an intra prediction unit that determines CTU boundaries using intra-tile coordinates;
further comprising
2. The moving image according to claim 1, wherein the CT division unit performs quadtree division , binary tree division , or ternary tree division using intra-tile coordinates and tile sizes. decryption device. a header information decoding unit that decodes a tile size that is an integral multiple of the tile unit size;
an intra prediction unit that converts from intra-picture coordinates to intra-tile coordinates and determines a CTU boundary;
further comprising
2. The method according to claim 1, wherein the CT partitioning unit performs quadtree partitioning, binary tree partitioning , or triple tree partitioning using intra-picture coordinates , tile upper left coordinates, and tile sizes. The video decoding device described. a derivation unit for deriving a tile index;
a CT splitting unit that performs quadtree splitting , binary tree splitting , or triple tree splitting ;
a merge candidate deriving unit that stores temporal motion vectors, which are merge candidates of the target block, in a merge candidate list ;
Deriving the Y coordinate of the lower right position of the target block by adding the height of the target block to the Y coordinate of the target block,
Deriving virtual coordinates using the coordinates of the target tile specified by the tile index and the CTU size,
a temporal motion prediction unit that compares the Y coordinate of the lower right position of the target block with the virtual coordinates to determine the possibility of referring to the lower right reference block;
The video encoding device , wherein when the lower right reference block can be referenced, the temporal motion vector as the merge candidate is derived using the motion vector of the lower right reference block .

Images