JP2020061701A - Dynamic image coding device and dynamic image decoding device - Google Patents

Abstract

To flexibly set the unit of the size of a tile when tiles are decoded in a size other than an integral multiple of a CTU unit, and to provide loop filter processing that is efficient when an effective region of a CTU is small.SOLUTION: A dynamic image decoding device divides an image into tiles and decodes a dynamic image in a tile unit, and comprises: a header information decoding unit that decodes header information from a coded stream and calculates tile information; a tile decoding unit that decodes coded data for each tile and creates decoded images of the tiles; and a compositing unit that composites the decoded images of the tiles with reference to the tile information to create a display image. The tiles each include an area overlapping an adjacent tile, and the compositing unit performs filter processing on a plurality of pixel values of pixels in the overlapping areas of the tiles, and creates the display image by using the pixel values of the decoded images of the tiles and the pixel values on which the filter processing is performed.SELECTED DRAWING: Figure 23

Description

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

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

  As a specific moving image coding method, for example, a method proposed in H.264 / AVC or HEVC (High-Efficiency Video Coding) can be cited.

  In such a moving image coding method, an image (picture) that constitutes a moving image is a slice obtained by dividing the image, and a coding tree unit (CTU: Coding Tree Unit) obtained by dividing the slice. ), A coding unit obtained by dividing the coding tree unit (sometimes called a coding unit (CU)), and a transform unit (TU: obtained by dividing the coding unit). CU is encoded / decoded for each CU.

  Further, in such a moving image coding method, a predicted image is usually generated based on a locally decoded image obtained by coding / decoding an input image, and the predicted image is generated from the input image (original image). The prediction error obtained by the subtraction (sometimes referred to as "difference image" or "residual image") is encoded. As a method of generating a predicted image, inter-screen prediction (inter prediction) and intra-screen prediction (intra prediction) can be mentioned.

  As a method of dividing a screen into a plurality of units and performing parallel processing, a method of dividing into a slice, a CTU line (wavefront segment), and a tile is known. The method of dividing into tiles has conventionally been limited to division in CTU units.

  In addition, Non-Patent Document 1 is cited as a technique of recent video encoding and decoding.

"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 limitation that the tile size is an integral multiple of CTU, and it is possible to divide it into the same size for load balancing and configure tiles that match the face size of 360-degree video. There is a problem of difficulty.

  In addition, when the loop filter processing is performed when the effective area of the CTU is small at the screen edge or tile edge, there is a problem that the information overhead for the loop filter is large and the performance is not improved.

  Therefore, the present invention has been made in view of the above problems, and an object of the present invention is to provide tile division and an efficient loop filter process that are not limited to an integral multiple of CTU.

  A moving image decoding apparatus according to an aspect of the present invention is a moving image decoding apparatus that divides an image into tiles, divides tiles into CTUs, and decodes moving images in units of CTUs. The header decoding unit includes a header decoding unit that decodes tile unit information indicating a unit of size, and a CT decoding unit that makes the tile a CTU, and the header decoding unit uses the tile unit information to derive the tile upper left position and the tile size. Is characterized by.

It is a figure which shows the hierarchical structure of the data of an encoding stream. It is a figure which shows the example of division of CTU. It is a figure explaining a tile. It is a syntax table regarding tile information and the like. It is a schematic diagram showing the composition of a moving picture decoding device. It is a flowchart explaining a schematic operation of the moving image decoding apparatus. It is a flow chart explaining operation of a CT information decoding part. It is a figure which shows the structural example of the syntax table of CTU and QT information. It is a figure which shows the structural example of the syntax table of MT (Multi Tree) information. It is a figure which shows the structural example of the syntax table of MT (Multi Tree) information. It is a figure explaining the tile division in a non-CTU size. It is a figure explaining the tile division in a non-CTU size. It is a syntax configuration of encoded slice data. It is a flowchart which shows operation | movement of the loop filter part of this embodiment. This is an example of ALF syntax. It is a figure explaining SAO. This is an example of SAO syntax. It is a block diagram of SAO and ALF. It is a block diagram which shows the structure of a moving image encoding device. It is the figure which showed the structure of the transmission apparatus which mounts the moving image encoding apparatus which concerns on this embodiment, and the receiving apparatus which mounts the moving image decoding apparatus. (a) shows a transmitter equipped with a moving picture coding device, and (b) shows a receiver equipped with a moving picture decoding device. It is the figure which showed the structure of the recording device which mounts the moving image encoding apparatus which concerns on this embodiment, and the reproducing | regenerating apparatus which mounts a moving image decoding device. (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. It is a schematic diagram showing composition of an image transmission system concerning this embodiment. It is another example of a syntax table regarding tile information and the like. It is another example of a syntax table regarding tile information and the like. It is another example of a syntax table regarding tile information and the like. It is another example of a syntax table regarding tile information and the like. It is a figure which shows the syntax structural example of coded slice data and CTU information. It is a figure which shows the structural example of the syntax table of QT information. It is a figure which shows the structural example of the syntax table of MT information. It is a figure which shows the syntax structural example of CTU information. It is a syntax structure of encoded tile data. It is a figure which shows the structural example of the syntax table of CTU and QT information. It is a figure which shows the structural example of the syntax table of MT (Multi Tree) information. It is a figure which shows the structural example of the syntax table of CTU and QT information. It is a figure explaining the formula which transform | converts from a coordinate system in a tile to a coordinate system in a screen, and derives an on-off flag of ALF. It is a figure which shows the syntax structural example of CTU information. It is another example of a syntax table regarding tile information and the like. It is a schematic diagram showing composition of a merge prediction parameter derivation part. It is a figure which shows the example of the process which refers to the motion vector in a reference picture as a temporal motion vector. It is a figure which shows the relationship of the object CTU and the motion vector reference range in case a reference picture and an object picture are the same tile division.

(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 an image. The image transmission system 1 is configured to include a moving image encoding device (image encoding device) 11, a network 21, a moving image decoding device (image decoding device) 31, and a moving image display device (image display device) 41. .

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

  The network 21 transmits the encoded stream Te generated by the moving image encoding device 11 to the moving image decoding device 31. The network 21 is the Internet, a wide area network (WAN: Wide Area Network), a small network (LAN: Local Area Network), or a combination thereof. The network 21 is not necessarily a bidirectional communication network, but may be a unidirectional communication network that transmits broadcast waves such as terrestrial digital broadcasting and satellite broadcasting. Further, the network 21 may be replaced with 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 coded streams Te transmitted by the network 21 and generates one or a plurality of decoded images Td.

  The moving image display device 41 displays all or part of one or a plurality of decoded images Td generated by the moving image decoding device 31. The moving image display device 41 includes 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. Further, when the video decoding device 31 has high processing capability, it displays an image with high image quality, and when it has only lower processing capability, it displays an image that does not require high processing capability or display capability. .

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

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

  x? y: z is a ternary operator that takes y when x is true (other than 0) and z when x is false (0).

  Clip3 (a, b, c) is a function that clips c to a value greater than or equal to a and less than or equal to b. Returns a if c <a, returns b if c> b, and otherwise. Is a function that returns c (however, 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 (rounding down after the decimal point).

<Structure of encoded stream Te>
Prior to a detailed description of the moving picture coding apparatus 11 and the moving picture decoding apparatus 31 according to the present embodiment, data of a coded stream Te generated by the moving picture coding apparatus 11 and decoded by the moving picture decoding apparatus 31. The structure will be described.

  FIG. 1 is a diagram showing a hierarchical structure of data in the encoded stream Te. The coded stream Te illustratively includes a sequence and a plurality of pictures forming the sequence. (A) to (f) of FIG. 1 are 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, respectively. It is a figure which shows the data, the coding tree unit contained in coding slice data, and the coding unit contained in a coding tree unit.

(Encoded video sequence)
In the encoded video sequence, a set of data referred to by the moving picture decoding apparatus 31 in order to decode the sequence SEQ to be processed is defined. As shown in FIG. 1A, the sequence SEQ includes a video parameter set (Video Parameter Set), a sequence parameter set SPS (Sequence Parameter Set), a picture parameter set PPS (Picture Parameter Set), a picture PICT, and additional extension. Information SEI (Supplemental Enhancement Information) is included.

  The video parameter set VPS is a set of coding parameters common to a plurality of moving pictures in a moving picture composed of a plurality of layers and a plurality of layers included in the moving picture and coding parameters related to individual layers. Sets are defined.

  The sequence parameter set SPS defines a set of coding parameters that the moving image decoding apparatus 31 refers to in order to decode the target sequence. For example, the width and height of the picture are specified. There may be a plurality of SPSs. In that case, one of the plurality of SPSs is selected from the PPS.

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

(Encoded picture)
In the coded picture, a set of data referred to by the video decoding device 31 in order to decode the picture PICT to be processed is defined. As shown in FIG. 1B, the picture PICT includes slice 0 to slice NS-1 (NS is the total number of slices included in the picture PICT).

  In addition, hereinafter, when it is not necessary to distinguish each of the slice 0 to the slice NS-1, the suffix of the reference numeral may be omitted. The same applies to other data that is included in the coded stream Te described below and has a subscript.

(Encoding slice)
In the encoded slice, a set of data referred to by the video decoding device 31 in order to decode the slice S to be processed is defined. A slice includes a slice header and slice data, as shown in FIG. 1 (c).

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

  The slice types that can be designated by the slice type designation information include (1) an I slice that uses only intra prediction during encoding, (2) a unidirectional prediction that uses encoding during prediction, or a P slice that uses intra prediction. (3) B slices using unidirectional prediction, bidirectional prediction, or intra prediction at the time of encoding can be given. Note that inter prediction is not limited to uni-prediction and bi-prediction, and a larger number of reference pictures may be used to generate a prediction image. Hereinafter, when referred to as P and B slices, they refer to slices including blocks that can use inter prediction.

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

(Encoded slice data)
In the encoded slice data, a set of data referred to by the moving image decoding apparatus 31 in order to decode the slice data to be processed is defined. The slice data includes a CTU as shown in FIG. 1 (d). The CTU is a block of a fixed size (for example, 128x128) that constitutes a slice, and is sometimes referred to as a maximum coding unit (LCU).

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

wPict = pic_width_in_luma_samples
hPict = pic_height_in_luma_samples
FIG. 3B is a diagram showing the coding and decoding order of the CTU when the picture is divided into tiles. The number described in each tile is TileId (the identifier of the tile in the picture), and the number TileId may be assigned to the tile in the picture from the upper left to the lower right in raster scan order. In addition, the CTU is processed in the raster scan order from the upper left to the lower right in each tile, and when the processing in one tile is completed, the CTU in the next tile is processed.

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

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

The parameter tile_parameters () regarding the tile is notified by the PPS (pic_parameter_set_rbsp ()) shown in FIG. 4 (b). Hereinafter, to notify the parameter means to include the parameter in the encoded data (bit stream), the moving image encoding device encodes the parameter, and the moving image decoding device decodes the parameter. As shown in FIG. 4C, tile_parameters () is notified of tile information tile_info () when tile_enabled_flag indicating whether or not a tile exists is 1. When tile_enabled_flag is 1, the independent_tiles_flag (independent_decoding_tile_flag) indicating whether the tile can be independently decoded over a plurality of temporally consecutive pictures is notified. When independent_tiles_flag is 0, the tile is decoded by referring to the adjacent tile in the reference picture (cannot be independently decoded). When independent_tiles_flag is 1, decoding is performed without referring to the adjacent tiles in the reference picture. When tiles are used, decoding is performed without referring to adjacent tiles in the current picture regardless of the value of independent_tiles_flag, and thus 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 tile group or tile. The independent_tiles_flag is independent (no inter-picture reference) when 1 and dependent (inter-picture reference) when 0, but 0 and 1 may be reversed flags. For example, a tile-time inter-picture reference enable flag tile_inpicture_ref_enabled_flag may be a flag that is independent when 0 and is a subordinate when 1 is set.
As shown in FIG. 4C, when independent_tiles_flag is 0, loop_filter_across_tiles_enable_flag indicating ON / OFF of the loop filter at the tile boundary applied to the reference picture is transmitted (present). When independent_tiles_flag is 1, loop_filter_across_tiles_enable_flag may be always 0 without being transmitted (present).

  When the 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 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 as shown in FIG. 4D, for example. 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 indicating whether or not the picture is tiled as evenly as possible. If the value of uniform_spacing_flag is 1, the width and height of each tile of the picture are as equal as possible in the given size, and the number of horizontal and vertical tiles in the picture and the minimum unit of tiles. The tile width and height are derived from the (tile unit identifier) (tile_unit_width_idc, tile_unit_height_idc) in the moving image coding device and moving image decoding device (header decoding unit 3020).

  The header decoding unit 3020 derives tile minimum units wUnitTile and hUnitTile from the tile unit identifiers tile_unit_width_idc and tile_unit_height_idc (details will be described later).

wUnitTile = 1 << (log2CbSize + tile_unit_width_idc)
hUnitTile = 1 << (log2CbSize + tile_unit_height_idc)
The header decoding unit 3020 derives the number of tiles M and N 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 that it is 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 derive 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 derive 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
When the value of uniform_spacing_flag is 0, the width and height of each tile of the picture are set individually. In the moving picture coding device, the width of each tile column_width_in_unit_minus1 [i] (wTile in FIG. 3 is expressed in units of wUnitTile) and height row_height_in_unit_minus1 [i] (hTile in FIG. 3 is expressed in units of hUnitTile). Value) is encoded 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 edge may be simply set as follows when 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 screen edge is appropriately processed by padding, cropping, or the like so that the processing unit matches the minimum unit of tile or the minimum CU size.

  The tile at the position (m, n) is also represented by the identifier TileId, and TileId may be calculated as follows.

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

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

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

(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, wUnitTile = ctuWidth, and when tile_unit_width_idc = 0, hUnitTile = ctuHeight. Here, ctuWidth is the width of the CTU and ctuHeight is the height of the CTU.

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

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)
Here, 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, which defines the minimum CU size, and the syntax element log2_diff_max_min_luma_coding_block_size, which is the logarithm of the difference between the CU size and the minimum CU size, as follows. May 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
When the tile unit identifier! = 0, the tile unit may be set to a constant multiple of the minimum size of the coding unit CU (exponentiation of 2).

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 determines the tile unit. For example, by setting it to 1, 2, or 3, the tile unit is set to 4, 8, or 16 times the minimum CU size. For example, when the CU size is 4, it is set to 8, 16, 32. Further, the maximum value may be clipped so as to be the CTU size.

(Setting method 2)
The tile information is tile unit identifiers tile_unit_width_idc in the range of 0 to a predetermined number, and the unit of the tile size 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 width and height of the CTU are equal squares, the above is equivalent to decoding tile_unit_size_idc and setting as follows. Hereinafter, since it is self-evident, the description of the case of only the square is omitted.

wUnitTile = hUnitTile = ctuSize >> tile_unit_size_idc
The tile unit identifier may not be explicitly encoded, and the tile unit may be set to be a constant multiple of the minimum size of the encoding unit CU (power of 2).

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

wUnitTile = min (ctuWidth, 1 << (log2CbSize + Log2DiffTileUnitSize))
hUnitTile = min (ctuHeight1 << (log2CbSize + Log2DiffTileUnitSize))
(Setting method 3)
The tile information is a number of tile unit identifiers ranging from 0 to a predetermined range, and the unit of tile size is 1 << (log2 (CTU size)- Tile unit identifier) is set. 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)
Here, log2CtuWidthY = log2 (ctuWidth) and log2CtuHeightY = log2 (ctuHeight).

  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)
Here, 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.

  Note that the tile unit may be clipped to have 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, the tile width is always a multiple of 8, and the effect shown in (Setting method 5) is also obtained.

  Also, the unit size may be clipped to be 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, and the effect shown in (Setting method 5) is also obtained.

Furthermore, the range that tile_unit_width_idc can take may be limited. 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, tile_unit_width_idc is limited to 0 or more and log2 (ctuWidth) -log2 (minCTU) or less. That is, the moving image decoding apparatus can use the tile unit that is a multiple of minCTU by decoding the encoded data limited to 0 or more and log2 (ctuWidth) -log2 (minCTU) or less.

  Similarly, a tile unit that is a multiple of 8 can be used by decoding encoded data that is limited to 0 or more and log2 (ctuWidth) -log2 (8) = log2 (ctuWidth) -3 or less. In the case of a multiple of 16 or 32 instead of a multiple of 8, the above 3 (log2 (8)) may be set to 4, 5.

(Setting method 4)
The tile information is a number of tile unit identifiers ranging from 0 to a predetermined range, and the unit of the tile size is set by CTU size >> tile unit identifier so that the unit of the tile size is 1/2 of the CTU size. 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 the setting method 3 and the 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 a predetermined value TileUnit to wUnitTile and hUnitTile. The predetermined value TileUnit is preferably a multiple of 8, particularly any of 8, 16, and 32. 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
Here, TileUnit is a multiple of 8 such as 8 or 16, 32. If the tile unit is a multiple of 8, even if the bitDepth of the pixel is not a multiple of 8, such as 10 bits, the pixel data of the tile width can be a multiple of 8. As a result, even when the tiles are arranged in the memory, the tile boundaries are always byte (8 bit) boundaries, and when the tiles are arranged in the memory, no memory gap is required between the tiles. If there is no gap, the memory for the gap is unnecessary and continuous transfer is possible, so that the memory size can be reduced and high-speed transfer can be achieved. Furthermore, if it is a multiple of 16, 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 (for example, DDR).

  Further, 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 a predetermined value TileUnit to wUnitTile and hUnitTile. The predetermined value TileUnit is preferably the minimum CTU size (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, if 0, 1, 2, and 3, the minimum CTU sizes are 16, 32, 64, and 128, 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 or 32, which is consistent with (setting method 5).

  The minimum CTU size may be set by a profile or level that defines the function or ability of the moving picture decoding apparatus. Since the profile and level are used for negotiation between devices, they are transmitted in relatively higher parameter sets and headers, for example, SPS syntax elements profile_idc and level_idc.

  When the tile unit is a multiple of the minimum CTU size, the tile width is always a multiple of the minimum CTU size. Typically, when storing pictures in memory, memory allocation is optimized based on the limited range of CTU sizes (eg, 16, 32, 64). If the tile width is an integral multiple of the CTU size (exponential power of 2), the memory can be arranged even in the case of tiles by the same method as the picture, so that the image can be saved in memory and can be accessed at high speed.

(Setting method 7)
The tile information is a number of tile unit identifiers 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 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 unit of the tile size is set as the maximum CTU size >> tile unit identifier. In (Setting Method 8), the tile unit identifier is a logarithmic representation of a multiple (one power of 2) of the maximum CTU size. 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 by SPS instead of PPS. 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 tile unit (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 of the minimum value of the minimum unit of tile, and is an integer of 0 or more. Therefore, the minimum unit of tile 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 tile unit (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), a restriction is imposed on (Setting method 9) so that the minimum unit of tile size in the SPS does not exceed the CTU size in the SPS. Therefore, log2_diff_curr_min_unit_tile_size must be a value that satisfies 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 difference between the power of 2 of the maximum and minimum CTU sizes.

(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. 26A and 26D, 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), wUnitTile and hUnitTile are derived from TileUnit by referring to independent_tiles_flag. independent_tiles_flag = 1, that is, when each tile can be processed independently (without referring to other tiles), the tile unit (minimum unit) of the tile is set to be smaller than that otherwise. For example, in (setting method 5), the predetermined value TileUnit is set to 8 when independent_tiles_flag = 1, and the predetermined value TileUnit is set to 16 when independent_tiles_flag = 0.

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

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

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

  Independent_tiles_flag is 1, that is, in tiles that are independently decoded without referring to each other, tiles can be placed in memory independently (that is, there is no problem if a memory gap occurs between tiles), so a small value However, there is no problem in memory allocation. As a result, in the case of an independently decodable area, the tile size can be flexibly determined.

(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 the motion vector 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, when the unit of notifying the difference quantization parameter is 16x16, TileUnit = 16 is set.

(Setting method 14)
In (Setting method 14), the predetermined value TileUnit is set to an integer 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, the minimum unit of tile is set by the following formula.

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

(Step 1)
The screen width wPictInUnitTile, hPictInUnitTile in tile units (wUnitTile, hUnitTile) is derived from the minimum unit wUnitTile, hUnitTile of tiles and the screen width wPict, 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 coordinates (xTile, yTile) in the picture of the tile indicated by the position (col, row) in tile units. Hereinafter, the coordinates in the picture are the coordinates in the picture coordinate system where the upper left of the picture is (0, 0), and the coordinates in the tile are the coordinates of the tile coordinate system in which the upper left of each tile is (0, 0). Means coordinates. The tile column position col is looped from 0 to the number of tile columns numTileColumns-1, and the minimum unit wUnitTile is used to derive the X coordinate tx [col] and width tw [col] of each tile of each col. Similarly, the row position row of the tile is looped from 0 to the number of tile rows numTileRows-1 and the minimum unit hUnitTile is used to derive the Y coordinate ty [row] and height th [row] of each tile of each row. To do.

When the uniform_spacing_flag is 1, the tile information setting unit displays the screen with numTileColumns x
Divide tiles into numTileRows (= M x N) and derive tile sizes tw [col], th [row] and tile X coordinates tx [col], Y coordinates ty [row]. Specifically, as in the pseudo code below, tx [col] and tw [col] are derived using the picture width wPict and the number of tile columns numTileColumns, and the picture width hPict and the number of tile columns numTileRows Is used to derive ty [row] and th [row]. The values previously obtained as hTile and wTile described above may be used for ty and tw. It should be noted that the reason why min () is applied to wPict-tx [col] and tw [col] is to prevent the tile from becoming larger than the screen edge.

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 in the pseudo code below, tx [col] is derived using the picture width wPict and the tile column width wTile [col], and the picture height hPict and tile row height hTile are derived. Derive ty [row] using [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 sets the X coordinate tx [col], Y coordinate ty [row] and tile size tw [col], th [row] of the derived tile 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)]
In the following expressions, the temporary information is different, but the same operation is performed. Therefore, the tile information setting unit may perform the following operation.

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 ÷ CtbSizeY)
for (PicHeightInCtbsY = 0, j = 0; j <= num_tile_rows_minus1; j ++)
PicHeightInCtbsY + = Ceil (rowHeight [j] * TileUnitSizeY ÷ CtbSizeY)
The entire screen may be derived as follows.

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 (TileWidth [i] ÷ CtbSizeY).
TileHeightInCtbsY [i] = Ceil (TileHeight [i] ÷ CtbSizeY).
TileX [i] = TileColX [col]
TileY [i] = TileRowY [row]
TileXInCtbsY [i] = colBd [col]
TileYInCtbsY [i] = rowBd [row]
}
As described above, in the slice data (slice_segment_data ()), the tile information starting from the position (xTile, yTile) on the picture is notified in CTU units by using the tile information notified by the PPS shown in FIG. 4B. . Specifically, the 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 encoded 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 that is encoded in NAL (network abstraction layer) unit units. Further, the header decoding unit 3020 derives a tile (TileId) required for display from control information that is input from the outside and that indicates an image region to be displayed on a display or the like. Also, the header decoding unit 3020 extracts a coded tile required for display from the coded stream Te. The coded tile is divided into CTUs by the CT information decoding unit 3021 according to the syntax in the coded data and processed. The tile information is specifically calculated from the syntax of num_tile_columns_minus1, num_tile_rows_minus1, uniform_spacing_flag, column_width_in_unit_minus1 [i], row_height_in_unit_minus1 [i], etc., the number M of tiles in the horizontal direction, the number N of tiles in the vertical direction, and the width w of tiles. [m] and height hTile [n] etc.

  FIG. 11 shows an example in which tiles are divided by a value other than an integral multiple of the CTU size. FIG. 11A shows the technique of the present embodiment, which is a diagram in which a 1920x1080 HD image is divided into 4x3 tiles. In the present embodiment, when dividing into 4 × 3 tiles, all tiles can be divided into equal sizes (divided into 480 × 360), so that there is an effect that the load can be equally balanced among a plurality of processors and hardware. The tile size can be a size other than an integral multiple of CTU regardless of the picture boundary. FIG. 11 (b) is a diagram showing the CTU division of each tile. When dividing into CTUs, if the tile size is not an integral multiple of the CTU size, provide a crop offset area outside the tiles. In particular, as shown in TILE B, the CTU is divided based on the upper left of each tile. Therefore, the upper left coordinate of the CTU is not limited to an integral multiple of the CTU size.

  FIG. 12 is a diagram showing a case where each tile is further divided into CTUs. The picture is divided 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 CTU starts from the upper left of the tile. Therefore, a tile may end at a position other than an integral multiple of the CTU size on the right side and the lower side, but the CTU boundary and the tile boundary coincide on the left side and the upper side of the tile.

(Encoding tree unit)
In FIG. 1 (e), a set of data referred to by the video decoding device 31 in order to decode the CTU to be processed is defined. CTU is the basic coding process by recursive quadtree partitioning (QT (Quad Tree) partitioning), binary tree partitioning (BT (Binary Tree) partitioning) or ternary tree partitioning (TT (Ternary Tree) partitioning) It is divided into coding units CU, which are basic units. The BT partition and the TT partition are collectively called a multi-tree partition (MT (Multi Tree) partition). A tree-structured node obtained by recursive quadtree partitioning is called a coding node (Coding Node). Intermediate nodes of the quadtree, the binary tree, and the ternary tree are coding nodes, and the CTU itself is also defined as the uppermost coding node.

  The CT has, as CT information, a QT split flag (cu_split_flag) indicating whether or not to perform QT split, an MT split mode (split_mt_mode) indicating a split method of MT split, and an MT split direction (split_mt_dir) indicating a split direction of MT split. , MT split type (split_mt_type) indicating the split type of MT split. cu_split_flag, split_mt_flag, split_mt_dir, split_mt_type are transmitted for each coding node.

  When cu_split_flag is 1, the coding node is divided into four coding nodes (Fig. 2 (b)). When cu_split_flag is 0 and the split_mt_flag is 0, the coding node is not split and has one CU as a node (FIG. 2 (a)). The CU is the end node of the coding node and is not further divided. The CU is a basic unit of encoding processing.

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

  When 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 apparatus 31 for decoding the encoding unit to be processed is defined. Specifically, the CU includes a CU header CUH, a prediction parameter, a conversion parameter, a quantized conversion coefficient, and the like. The prediction mode etc. are specified in the CU header.

The prediction process may be performed in units of CU or may be performed in units of sub CUs obtained by further dividing the CU. When the CU and the sub CU have the same size, there is one sub CU in the CU. If the CU is larger than the size of the sub-CU, the CU is divided into sub-CUs. For example, CU is 8x8, sub CU is 4x4
In this case, the CU is divided into four sub CUs, which are divided into two horizontally and vertically.

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

  The transform / quantization process is performed in CU units, but the quantized transform coefficients may be entropy coded in subblock units such as 4 × 4.

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

(Structure of video decoding device)
The configuration of the moving picture decoding device 31 (FIG. 5) according to the present embodiment will be described.

  The moving image decoding device 31 includes a parameter decoding unit (prediction image decoding device) 302, a loop filter 305, a reference picture memory 306, a prediction parameter memory 307, a prediction image generation unit (prediction image generation device) 308, and inverse quantization / inverse transformation. It is configured to include a unit 311 and an addition unit 312. It should be noted that there is a configuration in which the loop filter 305 is not included in the moving image decoding device 31 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), and the CU decoding unit 3022 further includes a TU decoding unit 3024. Is equipped with.

(Decryption module)
The schematic operation of each module will be described below. The 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 the syntax element from the encoded data by the entropy encoding method such as CABAC based on the syntax element supplied from the supplier, and returns the decoded syntax element to the supplier. In the example shown below, the sources of the syntax elements are the CT information decoding unit 3021 and the CU decoding unit 3022.

(Basic flow)
FIG. 6 is a flowchart illustrating a schematic operation of the moving picture decoding apparatus 31.

  (S1100: Decoding of parameter set information) The header decoding unit 3020 decodes parameter set information such as VPS, SPS, PPS from the encoded data.

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

  Hereinafter, the moving image decoding apparatus 31 derives a decoded image of each CTU by repeating the processes of S1300 to S5000 for each CTU included in the target picture.

  (S1300: CTU information decoding) The CT information decoding unit 3021 decodes the CTU from the encoded data.

  (S1400: Decoding CT information) The CT information decoding unit 3021 decodes the CT from the encoded data.

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

  (S1510: CU information decoding) The CU decoding unit 3022 decodes CU information, prediction information, TU division flag split_transform_flag, CU residual flags cbf_cb, cbf_cr, cbf_luma, etc. from encoded data.

  (S1520: TU information decoding) The TU decoding unit 3024 decodes the QP update information (quantization correction value) and the quantization prediction error (residual_coding) from the encoded data when the TU includes a prediction error. 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: Prediction Image Generation) The prediction image generation unit 308 generates a prediction 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 an inverse quantization / inverse transform process for each TU included in the target CU.

  (S4000: Decoded image generation) The adder 312 adds the prediction image supplied from the prediction image generation unit 308 and the prediction error supplied from the inverse quantization / inverse conversion unit 311 to decode the target CU. Generate an image.

  (S5000: Loop Filter) The loop filter 305 applies a loop filter such as a deblocking filter, SAO, or ALF to the decoded image to generate a decoded image.

(CTU decoding for tiles)
FIG. 13 is a diagram showing encoded slice data. The CT information decoding unit 3021 of the parameter decoding unit 302 sequentially processes the CTUs forming the slice (tile). Further, the CT information decoding unit 3021 refers to the CTU address tables CtbAddrToCtbX [] and CtbAddrToCtbY [] from the CTU raster scan address CtbAddrInRs of the target CTU by using the target CTU coordinate derivation unit (not shown), and the upper left coordinate ( xCtb, yCtb) is derived.

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 deriving unit.
The parameter decoding unit 302 decodes the flag end_of_slice_segment_flag indicating whether it is the end of the slice segment, increments the CTU address CtbAddrInTs by 1 (CtbAddrInTs ++) in preparation for the processing of the next CTU, and derives the address of the subsequent CTU. . Further, the CTU raster scan address corresponding to the subsequent CTU is derived (CtbAddrInRs = CtbAddrTsToRs [CtbAddrInTs]). Here, CtbAddrInTs is the tile scan address of the target CTU.

  The parameter decoding unit 302 is not the end of the slice segment (! End_of_slice_segment_flag), the tile is valid (tiles_enabled_flag), the tile ID of the subsequent CTU (TileId [CtbAddrInTs] or TildIdTbl [CtbAddrInTs]) and the tile ID of the CTU of the target CTU. When ([CtbAddrInTs-1]) is different, the end_of_subset_one_bit is decoded, and further the byte alignment bit (byte_alignment ()) is decoded.

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

  The condition for decoding end_of_subset_one_bit and byte_alignment () may be the condition shown in FIG. 27 (a). That is, the parameter decoding unit 302 decodes end_of_subset_one_bit and byte_alignment () when the tile is valid (tiles_enabled_flag) instead of the end of the slice segment (! End_of_slice_segment_flag).

  Here, the present embodiment is characterized by the method of deriving PicWidthInCtbsY in the case of tiles of sizes not limited to integer multiples of the CTU size. PicWidthInCtbsY means how many CTUs are included in the picture width. However, when the size of the effective area of the tile is not limited to an integral multiple of the CTU size as in the present embodiment, the effective area has the CTU size. The value of PicWidthInCtbsY is not necessarily equal to ceil (wPict / ctuWidth) because there can be multiple CTUs of less than 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]
The same applies to PicHeightInCtbsY, which is derived by the following method.

for (PicHeightInCtbsY = 0, j = 0; j <= num_tile_rows_minus1; j ++)
PicHeightInCtbsY + = tileHeightInCtus [j]
When the tile is limited to an integral multiple of the CTU size, it may be derived by the following method.

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

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

(Step 1)
The 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 deriving unit.

(Step 2)
The CTU address table deriving unit derives the first CTU raster scan address firstCtbAddrInRs [TileId] of the tile including the target CTU, and uses the number of CTUs included in the picture width PicWidthInCtbsY to determine the coordinates within the tile in units of CTU (xCtbInCtus , yCtbInCtus) is derived by the following formula
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 derivation unit multiplies the CTU size (ctuWidth, ctuHeight) and derives the in-tile coordinates (xCtbInTile, yCtbInTile) in pixel units by the following formula.

xCtbInTile = xCtbInCtus * ctuWidth
yCtbInTile = yCtbInCtus * ctuHeight
The logarithmic display of the CTU size may be used to derive the following.

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 in-tile coordinates (xCtbInTile, yCtbInTile) and the upper-left picture coordinates (xTile [TileId], yTile [TileId]) of the tile. Derive.

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

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

  The whole of the above process 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 = numTileCol
umns * numTileRows.

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

  The CT information decoding unit 3021 uses a target CTU coordinate deriving unit (not shown) to extract the CTU raster scan address CtbAddrInRs of the target CTU from the CTU unit X-coordinate (CTU col position) and the CTU unit Y-coordinate (CTU unit). Rx and ry which are the row position) of the target CTU and the CTU coordinate conversion tables CtbColToCtbX [] and CtbRowToCtbY [] are derived 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 modification. 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 unit)
The CTU coordinate conversion table deriving unit derives the CTU pixel unit coordinates (xCtb, yCtb) from the CTU unit X coordinate and the CTU unit Y coordinate (rx, ry) in the following steps by the following steps: CtbColToCtbX [ ], CtbRowToCtbY [] is derived.

  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 deriving unit derives the tile ID from the X coordinate rx in CTU units. At this time, this table is the same for all Y coordinates, so the Y coordinate in CTU units (row position of CTU) is set to 0. Therefore,
TileId = CtbAddrRsToTileID [rx]
Here, CtbAddrRsToTileID is a table derived by the tile ID table deriving unit.

(Step 2x)
The CTU coordinate conversion table deriving unit derives the first CTU raster scan address firstCtbAddrInRs [TileId] of the tile including the target CTU, and derives the in-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 the table firstCtbCol [] that derives 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 by the first tile address derivation unit as follows.

firstCtbCol [TileId] = firstCtbAddrInRs [TileId]% PicWidthInCtbsY
Next, the CTU coordinate conversion table derivation unit multiplies xCtbInCtus by the CTU size ctuWidth to derive the in-tile coordinate xCtbInTile in pixel units by 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 deriving unit stores the upper left X coordinate xCtb of the CTU regarding 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 tile upper left CTU.

xTileInCtus = firstCtbAddrInRs [TileId]% PicWidthInCtbsY
xCtb = ((rx-xTileInCtus) << log2CtuWidthY) + xTile [TileId]
Here, log2CtuWidthY = log2 (ctuWidth). Since the X coordinate xTileInCtus of the tile upper left CTU and the upper left X coordinate xCtb of the CTU are often referred to, it is possible to store the derived values in this way and use them, or to perform the above derivation each time it is referred. Good.

  The whole of the above process 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 regarding the X coordinate, the CTU coordinate conversion table deriving unit loops the Y coordinate ry in CTU units from 0 to num_tile_rows_minus1 and executes the following steps.

(Step 1y)
The CTU coordinate conversion table deriving 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 deriving unit.

(Step 2y)
The CTU coordinate conversion table deriving unit derives the first CTU raster scan address firstCtbAddrInRs [TileId] of the tile including the target CTU, and derives the in-tile coordinate yCtbInCtus in units of CTU by 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 the table firstCtbRow [] that derives 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 by the first tile address derivation unit as follows.

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

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

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

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

yTileInCtus = firstCtbAddrInRs [TileId] / PicWidthInCtbsY
yCtb = ((ry-yTileInCtus) << log2CtuHeightY) + yTile [TileId]
Where log2CtuHeightY = log2 (ctuHeight). Since the Y coordinate yTileInCtus of the tile upper left CTU and the upper left Y coordinate yCtb of the CTU are often referred to, it is possible to store the derived value in this way in the table and use it, or to perform the above derivation each time it is referenced. Good.

  The whole of the above process 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 a subscript in the above embodiment is derived with the tile scan order CTU position CtbAddrInTs as a subscript, and the subscript at the time of reference is also the tile scan. It is also possible to use the one converted into the forward CTU position. Similarly, the table with the tile scan order CTU position CtbAddrInTs as a subscript can also be configured by deriving the raster scan order CTU position CtbAddrInRs as a subscript and converting the subscript at the time of reference to the raster scan order CTU position as well. Is.

Table Ct that derives the tile scan order CTU address from the raster scan order CTU address
An example of deriving bAddrRsToTs [] is shown below in pseudo code. CtbAddrRsToTileId [] is a tile ID table for deriving a tile ID from the raster scan order CTU address derived by the tile ID table deriving 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, a moving image decoding apparatus that divides an image into CTUs and decodes a moving image in units of CTUs includes a CT information decoding unit that divides tiles into CTUs and recursively divides them into a raster scan of a target CTU. A header decoding unit (target CTU coordinate deriving unit) that derives the upper left coordinates 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 is provided with the derived target. Based on the upper left coordinates on the picture of the CTU, the target CTU is divided into coding trees, and a means for processing the coding tree when the in-tile coordinates of the lower right position of the divided CT are within the tile size. Prepare

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

(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 in-screen CTU address CtbAddrInRs.

(Step 2)
Derive the in-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
The pseudo code 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
}
(Top tile address derivation unit)
The leading tile address derivation unit derives the leading tile address table firstCtbAddrInRs [] in the following steps.

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

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

  The upper end position yCtbInCtus of the tile indicated by TileId in the CTU unit is derived from the lower end position bottomEdgePosInCtus [TileId] of the tile indicated by TileId and the height of the tile indicated by TileId in the CTU unit tileHeightInCtus [TileId].

xCtbInCtus = rightEdgePosInCtus [TileId] -tileWidthInCtus [TileId] +1
yCtbInCtus = bottomEdgePosInCtus [TileId] -tileHeightInCtus [TileId] +1
The CTU raster scan address CtbAddrInRs is derived from the in-screen position (xCtbInCtus, yCtbInCtus) of the upper left pixel of the tile in CTU units 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
The pseudo code 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
}
}
(Process of decrypting CT information)
The CT information decoding process will be described below with reference to FIGS. 7, 8 and 9. FIG. 7 is a flowchart explaining the operation of the CT information decoding unit 3021 according to the embodiment of the present invention. Further, FIG. 8 is a diagram showing a configuration example of a syntax table of CTU and QT information according to an embodiment of the present invention, and FIG. 9 is a syntax table of MT division information according to an embodiment of the present invention. It is a figure which shows the structural example. Another example of FIGS. 7 to 9 is shown in FIGS. 27 to 29.

  In the decoding of the syntax of coding_tree_unit () in FIG. 8 (a), CT information decoding derives the upper left coordinates (xCtb, yCtb) of the target CTU and recursively decodes the syntax of coding_quadtree (). The upper left coordinate (xCtb, yCtb) of the CTU is used as the initial value of the upper left coordinate (xCb, yCb) of the CT of coding_quadtree (). As another derivation method of (xCtb, yCtb), as shown in FIG. 27 (b), the derivation method may be changed depending on whether a tile is used (tile_enabled_flag is true) or not. That is, when using a tile, 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 upper left coordinates of the CTU in the tile are derived from the difference between the in-screen coordinates of the CTU in CTU units (rx, ry) and the in-screen coordinates of the tile in CTU units (TileXInCtbY, TileYInCtbY). , CTU size is applied (CtbLog2SizeY shifts to the left).

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 in-screen coordinates of the CTU in CTU units. In other words, the upper left coordinate of the CTU in the tile is the in-screen coordinate (rx
, ry) with CTU size (CtbLog2SizeY shifts to the left).

rx = CtbAddrInRs% PicWidthInCtbsY
ry = CtbAddrInRs / PicWidthInCtbsY
xCtb = rx << CtbLog2SizeY
yCtb = ry << CtbLog2SizeY
Further, even when tiles are not used, it is possible to perform processing without assuming that tiles are used, assuming that the entire screen is one tile.

(Decoding below CTU)
The CT information decoding unit 3021 decodes CT information from coded data and recursively decodes a coding tree CT (coding_quadtree). Specifically, the CT information decoding unit 3021 decodes the QT information and 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 logarithm of the CT size, which is the CT size, with 2 being the base, and cqtDepth is the CT depth (QT depth) that indicates the CT hierarchy. is there.

  (S1411) The CT information decoding unit 3021 determines whether the decoded CT information has a QT division flag. If there is a QT division flag, the process transitions to S1421, and 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, when tiles are used as in the following formula, split_cu_flag indicating whether or not to perform further quadtree partitioning 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 effective area (or tile coding area) and Height, MinCbLog2SizeY, is the logarithm of the minimum block size.

  If the coordinates x0 + (1 << log2CbSize) at the right edge of the block and y0 + (1 << log2CbSize) at the bottom edge are smaller than the coordinates xTile + wTile at the right edge and yTile + hTile at the bottom edge of the tile effective area, the target block is It exists in the tile effective area. When the block exists in the tile and the block size is larger than the minimum value (log2CbSize> MinCbLog2SizeY), the flag split_cu_flag indicating whether or not the block is further divided is notified. Split_cu_flag is set to 1 when the block is further split into quadtrees, and split_cu_flag is set to 0 when the block is not split into quadtrees.

  (S1422) In other cases, the CT information decoding unit 3021 omits decoding of the QT division flag split_cu_flag from the encoded data, and sets 0 to the QT division flag split_cu_flag.

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

(S1451) The CT information decoding unit 3021 performs QT division. Specifically, the CT information decoding unit 3021 is the logarithmic CT size log2CbSize-1 at the positions (x0, y0), (x1, y0), (x0, y1), and (x1, y1) of the CT depth cqtDepth + 1. Decode 4 CTs. Decode the CT with the lower right coordinates (xi-xTile [TileId], yi-yTile [TileId]) of each CT in the tile smaller than the tile size (wTile [TileId], hTile [TileId]). Conversely, any of the lower right coordinates (xi-xTile [TileId], yi + yTile [TileId]) of each CT is the tile size (wTile
CTs over [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), (x1, y1) of the divided CT are within 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)
In the above, for example, coding_quadtree (x1, y0, log2CbSize-1, cqtDepth + 1, wTile, hTile, xTile, yTile) which is a block located at (x1, y0) obtained by quadtree partitioning is , Is encoded or decoded when x1 is located in the tile as follows.

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

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

  Then, the CT information decoding unit 3021 updates the CT depth cqtDepth indicating the CT hierarchy and the logarithmic CT size log2CbSize as in the following equation.

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

  After the QT division is completed, the CT information decoding unit 3021 decodes the CT information from the encoded data, and recursively decodes the encoded tree CT (MT, coding_multitree (FIG. 9) or multi_type_tree (FIG. 29)). Specifically, the CT information decoding unit 3021 decodes the MT partition information, and 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 logarithm of CT width, log2CbHeight is the logarithm of CT height, and cbtDepth is the CT depth (MT depth) indicating the hierarchy of the multi-tree. Hereinafter, coding_multitree will be described.

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

  (S1481) The CT information decoding unit 3021 decodes the MT division flag split_mt_flag.

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

(S1490) If the MT division flag split_mt_flag is other than 0, the CT information decoding unit 3021 advances to S149.
Transition to 1. In other cases, the CT information decoding unit 3021 does not divide the target CT and ends the process (shifts to CU decoding).

  (S1491) The CT information decoding unit 3021 performs MT division. The flag split_mt_dir indicating the direction of MT division and the syntax element split_mt_type indicating whether the MT division is a binary tree or a ternary tree are decoded. 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) in the binary tree and (x0, y1), (x0, y2) or (x1, y0), (x2, y0) in the binary tree. Is. Here, when the upper left coordinate (x0, y0) of the head CT is outside the tile, the division itself is not performed, so it is assumed that (x0, y0) is always within the tile.

  When the MT division type split_mt_type is 0 (two divisions) and the MT division direction split_dir_flag is 1 (horizontal division), the CT information decoding unit 3021 decodes the following two CTs (BT division information decoding). Decode a CT in which the lower coordinate y1-yTile [TileId] of CT (x0, y1) in the tile is less than the tile size hTile [TileId]. On the contrary, CTs in which the lower coordinate y1-yTile [TileId] of each CT in the tile is larger 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 division direction split_dir_flag is 0 (vertical division), the following two CTs are decoded (BT division information decoding). Decode a CT whose right coordinate x1-xTile [TileId] of CT (x1, y0) in the tile is less than the tile size wTile [TileId]. On the contrary, the CT whose right coordinate x1-xTile [TileId] of each CT in the tile is equal to or larger than the tile size wTile [TileId] is 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 equation.

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

log2CbWidth = log2CbWidth-1
log2CbHeight = log2CbHeight-1
If the MT division type split_mt_type indicates 1 (3 divisions), the CT information decoding unit 3021 decodes 3 CTs (TT division information decoding).

  When the MT division direction split_dir_flag is 1 (horizontal division), the following three CTs are decoded. Decode a CT in which the lower coordinate yi-yTile [TileId] of each CT (x0, yi) of i = 0, 1 in the tile is less than the tile size hTile [TileId]. On the contrary, the CT whose bottom coordinate yi-yTile [TileId] of each CT in the tile is equal to or larger than the tile size hTile [TileId] is 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 division information decryption). A CT in which the right coordinate xi-xTile [TileId] of each CT (xi, y0) at i = 0, 1 in the tile is less than the tile size wTile [TileId] is decoded. On the contrary, the CT whose right coordinate xi-xTile [TileId] of each CT in the tile is equal to or larger than the tile size wTile [TileId] is 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 equations.

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 the BT partition information decoding starting from S1471 or the TT partition information decoding using the updated upper left coordinate, the width and height of the CT, and the MT depth even in the lower CT. To do.

  When the MT division flag split_mt_flag is 0, that is, when neither QT division nor MT division is performed, the CT information decoding unit 3021 uses CU (coding_unit (x0, y0, log2CbSize, cqtDepth)) in the CU decoding unit 3022. To decrypt.

  As described above, the upper left coordinate (xTile, yTile) of the tile is subtracted from the upper left coordinate (xi, yi) of each CU expressed in the in-screen coordinate system to derive the upper left coordinate of the in-tile coordinate system. By comparing with the tile size (wTile, yTile), 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, there is an effect that it is possible to efficiently perform CU division without decoding useless division flags and useless CT.

(Another example of tile division)
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 encoded data is configured using units in which the tiles are grouped. The upper left coordinates of the tile are xTile and yTile, and the width and height of the tile are wTile and hTile. The CTU address ctbAddrInTs of the first tile is derived from the table FirstCtbAddrTs that stores the first position of the tile and the tile_group_address of the tile group position. Decode the CTU from 0 to num_tiles_in_tile_group_minus1. num_tiles_in_tile_group_minus1 is a value obtained by subtracting 1 from the number of tiles in the picture. Decode end_of_tile_one_bit and byte alignment bit byte_alignment () at the end of the tile.

  FIG. 31B shows an example of decoding each CTU using the CTU position CtbAddrInTile in the tile coordinate system. From the raster scan position CtbAddrInTile in units of CTU in the tile and the size TileWidthInCtus in units of CTU of the tile, the position (rx, ry) in units of CTU in the tile and the position (xCtb, yCtb) in units of pixel in the tile are derived. Using the derived CTU position in the tile coordinate system, the CTU is decoded as follows. The raster position CtbAddrInTile in units of CTU in the tile may be derived by subtracting the tile start position FirstCtbAddrTs from the CTU position CtbAddrInTs in screen units.

CtbAddrInTile = CtbAddrInTs-FirstCtbAddrTs [tile_group_id]
In addition, the on / off flag alf_ctb_flag [0] [rx] [ry], which indicates whether to perform the ALF processing of the luminance using the position (rx, ry) in the tile coordinate system, and the ALF processing of the color difference (Cb, Cr) The on / off flags alf_ctb_flag [1] [rx] [ry] and alf_ctb_flag [2] [rx] [ry] indicating whether or not to perform may be derived in tile units or tile group units. As described above, by encoding and decoding the on / off flag indicating whether or not to perform the ALF process in tile units, and deriving using the coordinate system (tile coordinate system) in tile units (tile group units), Even when extracting encoded data (bitstream) of some tiles in the screen to generate a bitstream of one image, it is possible to perform ALF processing without rewriting the syntax related to ALF. Play.

(Decoding below CTU)
The operation of the CT information decoding unit 3021 when decoding the syntax tables of FIGS. 7, 32, and 33 will be described. Using the in-tile coordinate system whose origin is the coordinates of the upper left corner of the tile in this configuration, derive the CTU coordinates (xCtb, yCtb) and recursively use CT information and tile size (wTile, yTile) based on the CTU coordinates and tile size (wTile, yTile). Decode MT division information and CT information.

  First, the CT information decoding unit 3021 decodes CT information from encoded data and recursively decodes an encoded 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 the decoded CT information has a QT division flag. If there is a QT division flag, the process transitions to S1421, and 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 equation, when using tiles, consider whether the upper left coordinates (x0, y0) of the CT in the tile coordinate system and the tile size are taken into consideration and whether further quadtree partitioning is performed. The 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) at the right end of the block and y0 + (1 << log2CbSize) at the bottom end are less than or equal to the tile width wTile and tile height hTile,
(x0 + (1 << log2CbSize) <= wTile [TileId])? 1: 0) +
((y0 + (1 << log2CbSize) <= hTile [TileId])? 1: 0)> = 2
Or, if the coordinate x0 + (1 << log2CbSize) at the right end of the block is the tile width wTile or less and the CT size is the maximum BT size MaxBtSizeY or more,
(x0 + (1 << log2CbSize) <= wTile [TileId])? 1: 0) +
(((1 << log2CbSize) <= MaxBtSizeY)? 1: 0))> = 2
Or, if the coordinate y0 + (1 << log2CbSize) at the bottom of the block is the tile height hTile or less and the CT size is the maximum BT size MaxBtSizeY or more,
(y0 + (1 << log2CbSize) <= hTile [TileId])? 1: 0) +
(((1 << log2CbSize) <= MaxBtSizeY)? 1: 0))> = 2
In the case of, the QT split flag qt_split_cu_flag is decoded from the encoded data.

  (S1422) CT information decoding unit 3021 omits decoding of the QT division flag qt_split_cu_flag from the encoded data in other cases, and the QT division flag qt_split_cu_flag is set to the following using the tile size (wTile, hTile). To derive.

  If any of the following is true, 1 is derived for qt_split_cu_flag.

x0 + (1 <<log2CbSize)> wTile [TileId] && (1 <<log2CbSize)> MaxBtSizeY
y0 + (1 <<log2CbSize)> hTile [TileId] && (1 <<log2CbSize)> MaxBtSizeY
If all of the following are true, derive 1 for qt_split_cu_flag.

x0 + (1 <<log2CbSize)> wTile [TileId]
y0 + (1 <<log2CbSize)> hTile [TileId]
(1 <<log2CbSize)> MinQtSizeY
In cases other than the above, 1 is derived for qt_split_cu_flag.

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

  If the CT lower coordinate exceeds the tile size height and the CT size exceeds the maximum BT division size MaxBtSizeY, it is always divided (1 is derived for qt_split_cu_flag).

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

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

  (S1451) The CT information decoding unit 3021 performs QT division. Specifically, the CT information decoding unit 3021 is a logarithmic CT size log2CbSize-1 at the positions (x0, y0), (x1, y0), (x0, y1), and (x1, y1) of the CT depth cqtDepth + 1. Decode 4 CTs. The lower right coordinates (xi-xTile [TileId], yi + yTile [TileId]) of each CT in the tile are decoded with the tile size (wTile [TileId], hTile [TileId]) or less. Conversely, a CT in which any of the lower right coordinates (xi, yi) of each CT is larger than 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), and (x1, y1) of the divided CT are within 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, obtained by quadtree partitioning, coding_quadtree (x1, y0, log2CbSize-1, cqtDepth + 1), which is a block located at (x1, y0), is as follows where x1 is in the tile: If it is located, it is encoded or decoded.

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

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

  Then, the CT information decoding unit 3021 updates the CT depth cqtDepth indicating the CT hierarchy and the logarithmic CT size log2CbSize as in the following equation.

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

  After the QT division is completed, 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 uses the in-tile coordinates and the tile size to decode the MT partition information, and the target CT multi_type_tree (x0, y0, CbWidth, CbHeight, mttDepth, depthOffset, partIdx, treeType). Decrypt. Note that CbWidth is the width of the CT, CbHeight is the height of the CT, and mttDepth is the CT depth (MT depth) indicating the hierarchy of the multi-tree.

  (S1471) The CT information decoding unit 3021 determines whether the decoded CT information has an MT division flag (division information, that is, mtt_split_cu_flag, mtt_split_cu_vertical_flag, mtt_split_cu_binary_flag). According to the following determination, if there is the MT division flag, the process proceeds to S1481. In other cases, 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, allowBtSplit is false (FALTH).
・ CbSize <= MinBtSizeY
・ CbWidth> MaxBtSizeY
・ CbHeight> MaxBtSizeY
・ MttDepth> = MaxMttDepth + depthOffset
In addition to the above, if all of the following are true, allowBtSplit is false.
・ BtSplit = SPLIT_BT_VER
・ Y0 + cbHeight> hTile [TileId]
In addition to the above, if all of the following are true, allowBtSplit is false.
・ BtSplit = SPLIT_BT_HOR
・ X0 + cbWidth> wTile [TileId]
In addition to the above, if all of the following are true, allowBtSplit is false.
・ MttDepth> 0
・ PartIdx = 1
・ MttSplitMode [x0] [y0] [mttDepth? 1] = parallelTtSplit
In cases other than the above, allowBtSplit is true.
・ AllowBtSplit = TRUE
Here, cbSize and parallelTtSplit are set as follows.

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

If any of the following is true, allowTtSplit (allowTtSplirHor, allowTtSplirVer) is set to false (FALTH).
・ CbSize <= 2 * MinTtSizeY
・ CbWidth> MaxTtSizeY
・ CbHeight> MaxTtSizeY
・ MttDepth> = MaxMttDepth + depthOffset
・ X0 + cbWidth> wTile [TileId]
・ Y0 + cbHeight> hTile [TileId]
In cases other than the above, allowTtSplit (allowTtSplirHor, allowTtSplirVer) is set to true.
・ AllowTtSplit = TRUE
Here, cbSize is set as follows.

In case of SPLIT_TT_VER (allowSplitTtVer), cbSize = cbWidth
If SPLIT_TT_HOR (allowSplitTtHor), cbSize = cbHeight
That is, whether or not to encode the MT division flag is determined according to whether the CT right coordinate exceeds the tile size width or the CT lower 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, and derives it as follows.

If any of the following is true, 1 is derived to mtt_split_cu_flag.
・ X0 + cbWidth> wTile [TileId]
・ X0 + cbHeight> hTile [TileId]
In cases other than the above, 0 is derived in mtt_split_cu_flag. That is, when the right edge and lower edge coordinates of the CT in the tile coordinates exceed the tile size, the MT division flag is not decoded.

  That is, whether to encode the TT division flag is determined according to whether the CT right coordinate exceeds the tile size width or the CT lower coordinate exceeds the tile size height.

  (S1490) When the MT division flag split_mt_flag is other than 0, the CT information decoding unit 3021 transitions to S1491. In other cases, the CT information decoding unit 3021 does not divide the target CT and ends the process (shifts to CU decoding).

(S1491) The CT information decoding unit 3021 performs MT division. If BT split or TT split is possible (allowSplitBtHor || allowSplitTtHor) || (allowSplitBtVer || allowSplitTtVer), decode the flag mtt_split_cu_vertical_flag that indicates the MT split direction. If both BT and TT splits are possible in the decrypted split method mtt_split_cu_vertical_flag ((allowSplitBtVer && allowSplitTtVer && mtt_split_cu_vertical_flag) || (allowSplitBtHor
&& allowSplitTtHor &&! mtt_split_cu_vertical_flag) decodes a syntax element mtt_split_cu_binary_flag 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 a binary tree and (x0, y1), (x0, y2) or (x1, y0), (x2, y0) for a binary tree. is there. Here, when the upper left coordinate (x0, y0) of the head CT is outside the tile, the division itself is not performed, so it is assumed that (x0, y0) is always within the tile.

The CT information decoding unit 3021 sets the MT division type split_mt_type to 0 (two divisions) and the MT division direction s.
When plit_dir_flag is 1 (horizontal division), the following two CTs are decoded (BT division information decoding). Decode a CT in which the lower coordinate y1 of CT (x0, y1) in the tile is less than the tile size hTile [TileId]. On the contrary, CTs in which the lower coordinate y1 of each CT in the tile is the tile size hTile [TileId] or more 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 division direction split_dir_flag is 0 (vertical division), the following two CTs are decoded (BT division information decoding). Decode CT in which the right coordinate x1 of CT (x1, y0) in the tile is less than the tile size wTile [TileId]. On the contrary, a CT in which the right coordinate x1 of each CT in the tile is the tile size wTile [TileId] or more is 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, log2CbWidth or log2CbHeight is updated as the following formula.

CbWidth = CbWidth / 2
CbHeight = CbHeight / 2
If the MT division type split_mt_type indicates 1 (3 divisions), the CT information decoding unit 3021 decodes 3 CTs (TT division information decoding).

  When the MT division direction split_dir_flag is 1 (horizontal division), the following three CTs are decoded. Decode a CT in which the lower coordinate yi of each CT (x0, yi) of i = 0, 1 in the tile is less than the tile size hTile [TileId]. On the contrary, the CT whose lower coordinate yi of each CT in the tile is equal to or larger than the tile size hTile [TileId] is 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 division direction split_dir_flag is 1 (vertical division), the following three CTs are decoded (TT division information decoding). A CT in which the right coordinate xi of each CT (xi, y0) at i = 0, 1 within a tile is less than the tile size wTile [TileId] is decoded. On the contrary, the CT whose right coordinate xi of each CT in the tile is the tile size wTile [TileId] or more is 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 equations.

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 the BT partition information decoding starting from S1471 or the TT partition information decoding using the updated upper left coordinate, the width and height of the CT, and the MT depth even in the lower CT. To do.

  Further, when the MT division flag split_mt_flag is 0, that is, when neither QT division nor MT division is performed, the CT information decoding unit 3021 uses the CU (coding_unit (x0, y0, cbWidth, cbHeight, treeType )) Is decrypted.

  As described above, the division flag is decoded and each CT is decoded by comparing the upper left coordinates (xi, yi) of each CU represented in the tile with the tile size (wTile, yTile). As a result, even when the tile size is not an integral multiple of the CTU size, there is an effect that it is possible to efficiently perform CU division without decoding useless division flags and useless CT. Further, by performing the CU division using the in-tile coordinate system, it is possible to perform the CU division by a simple process without performing the conversion from the in-screen coordinate system to the in-tile coordinate system. Play.

  Further, the parameter decoding unit 302 is configured to include an inter prediction parameter decoding unit 303 and an intra prediction parameter decoding unit 304 (not shown). The predicted image generation unit 308 is configured to include an inter predicted image generation unit 309 and an intra predicted image generation unit 3021 (not shown).

  The entropy decoding unit 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 the inter prediction parameter decoding unit 303. To do. Also, the intra prediction parameters (luminance prediction mode IntraPredModeY, color difference prediction mode IntraPredModeC) are output to the intra prediction parameter decoding unit 304. The entropy decoding unit 301 outputs the quantized transform coefficient to the inverse quantization / inverse transform unit 311.

(Merge prediction)
FIG. 38 (a) is a schematic diagram showing the configuration of the merge prediction parameter derivation unit 3036 according to the present embodiment. The merge prediction parameter derivation unit 3036 includes a merge candidate derivation unit 30361 and a merge candidate selection unit 30362. The merge candidate is configured to include the prediction list use flag predFlagLX, the motion vector mvLX, and the reference picture index refIdxLX, and is stored in the merge candidate list. An index is assigned to the merge candidate stored in the merge candidate list according to a predetermined rule.

  The merge candidate derivation unit 30361 derives a merge candidate by using the motion vector of the decoded adjacent block and the reference picture index refIdxLX as they are. In addition, the merge candidate derivation unit 30361 may apply a spatial merge candidate derivation process, a temporal merge candidate derivation process, a combined merge candidate derivation process, a zero merge candidate derivation process, and a spatiotemporal merge candidate derivation process, 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 use flag predFlagLX, motion vector mvLX, reference picture index refIdxLX) stored in the prediction parameter memory 307 according to a predetermined rule, and merges them. Set as a candidate. The reference picture is specified by, for example, adjacent blocks within a predetermined range from the target block (for example, the left edge L, the left lower edge BL, the upper left edge AL, the upper edge A, and all the blocks that respectively contact the upper right edge AR of the target block). (Or some). Each merge candidate is called L, BL, AL, A, AR.

(Time merge candidate derivation process)
As the temporal merge derivation process, the merge candidate derivation unit 30361 reads the prediction parameter of the lower right CBR of the target block or the block C in the reference image including the center coordinates from the prediction parameter memory 307 as a merge candidate, and merges it. Store in candidate list mergeCandList [].

  FIG. T1 is a diagram showing blocks C and CBR in the reference image. In addition to the merge candidate list mergeCandList [] giving priority to the block CBR, 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, the motion vector of the block C is predicted. Add to vector candidates. By adding the motion vector of the colocated block, which is likely to have different motion, as a prediction candidate, the choice of the prediction vector is increased and the coding efficiency is improved. The method of specifying the reference image may be, for example, the reference picture index refIdxLX specified in the slice header or the smallest reference picture index refIdxLX of adjacent blocks.

  For example, the merge candidate derivation unit 30361 may derive the position of the block C (xColCtr, yColCtr) and the position of the block CBR (xColCBr, yColCBr) by the following formula.

xColCtr = xPb + (bW >> 1)
yColCtr = yPb + (bH >> 1)
xColCBr = xPb + bW
yColCBr = yPb + bH
Here, (xPb, yPb) is the upper left coordinate of the target block, and (bW, bH) is the width and height of the target block. If the block CBR is available, the merge candidate COL is derived using the motion vector of the block CBR. If block CBR is not available, block C is used to derive COL.

(Structure of derivation process of tile boundary for time merge)
It is preferable that the merge candidate derivation unit 30361 manages the motion vector in the reference memory in units of CTB lines and fetches only the range necessary for the target CTU into the internal memory. At this time, the merge candidate derivation unit 30361 does not use CBR when the position (xColCBr, yColCBr) of the block CBR exceeds the target CTU line so that the area other than the fetched area is not accessed, and the block C is processed by the following process. To use.

  Hereinafter, a processing example of processing the upper left coordinates of the target block using the in-tile coordinates will be described. In the following process, by (yCb >> CtbLog2SizeY) == (yColBr >> CtbLog2SizeY), if it is determined to be the same CTU line, the reference position (xRef, yRef) uses (xColBr, yColBr), otherwise (xColCtr, yColCtr) is used. Furthermore, access may be restricted to 8 * 8 units by shifting left by 3 bits after shifting right by 3 bits as in the example below. When referring to the motion vector on 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 coordinate. This operation is performed even before the quantization (shift) of the reference position. You can come later.

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

xRef = ((xColBr >> 3) << 3) + xTile [TileId]
yRef = ((yColBr >> 3) << 3) + yTile [TileId]
}
else {
// Use (xColCtr, yColCtr) to refer to the motion vector of the reference picture. 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 is equal to the tile division of the target picture. In this case, the CTU coordinate in the screen can be derived from the CTU coordinate in the target picture and the CTU coordinate in the reference picture. Further, when managing the MV memory for each CTU line in the tile, it is difficult to refer to the MV memory of the CTU line that is not in the tile even if it is in the screen. Therefore, in this embodiment, the reference range is limited to 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])) {
// Use (xColBr, yColBr) to refer to the motion vector of the reference picture. For example, see (xRef, yRef) below.

xRef = ((xColBr >> 3) << 3) + xTile [TileId]
yRef = ((yColBr >> 3) << 3) + yTile [TileId]
}
else {
// Use (xColCtr, yColCtr) to refer to the motion vector of the reference picture. For example,
xRef = ((xColCtr >> 3) << 3) + xTile [TileId]
yRef = ((yColCtr >> 3) << 3) + yTile [TileId]
}
Further, the above processing may be performed in the case of independent tiles (independent_tiles_flag = 1).

  As the coordinate system, use the in-tile coordinates (xCbInTile, yCbInTile) with the upper left corner of the tile as the origin, so that each reference position exceeds the tile size (wTile, yTile) as the coordinate system so as not to refer to the range beyond the tile boundary. In some cases it is appropriate not to refer. Further, when referring to the 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 coordinate. As shown in FIG. 31 to FIG. 34, by performing the CT division on the in-tile coordinates, the upper left coordinates of the prediction block are derived by the in-tile coordinates, and the position to be referred to in the temporal prediction is determined. This has the effect of easily determining whether or not it is.

An example of processing when processing the upper left coordinates of the target block using the in-screen coordinates is shown. Unlike the case of processing using the in-tile coordinate system, after subtracting the tile upper left coordinate and converting it to in-tile coordinates (yColBr-yTile, xColBr-xTile), compare with the tile size (wTile, hTile). , It is determined whether the tile size is exceeded. Also in the tile boundary determination, by shifting the target block position (yCb-yTile [TileId]) and the reference block position (yColBr-yTile [TileId]) in the tile coordinates to the right by the logarithm CtbLog2SizeY of the CTU size. Make a decision.

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 is equal to the tile division of the target picture. In this case, in the present embodiment, the reference range is limited to within the tile. 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 prediction block from the in-screen coordinates to the in-tile coordinates, it is possible to easily determine whether or not the prediction block is within the tile range and whether or not it falls on the CTU boundary.

  The loop filter 305 is a filter provided in the coding loop and removes block distortion and ringing distortion to improve image quality. The 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 at a predetermined position for each target picture and each target CU.

The prediction parameter memory 307 stores the prediction parameter in a predetermined position 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. Further, the predicted image generation unit 308 reads the reference picture from the reference picture memory 306. The predicted image generation 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, the reference picture block is a set of pixels on the reference picture (which is usually called a block because it is a rectangle), and is an area referred to for generating a predicted image.

  The inverse quantization / inverse transform unit 311 dequantizes the quantized transform coefficient input from the entropy decoding unit 301 to obtain a transform coefficient. These quantized transform coefficients are DCT (Discrete Cosine Transform, Discrete Cosine Transform), DST (Discrete Sine Transform, Discrete Sine Transform), KLT (Karyhnen Loeve Transform, Karhunen-Loeve Transform) for prediction error in encoding processing. Is a coefficient obtained by performing frequency conversion and quantizing. The inverse quantization / inverse transform unit 311 performs inverse frequency transform such as inverse DCT, inverse DST, and inverse KLT on the obtained transform coefficient to calculate a prediction error. The inverse quantization / inverse transformation unit 311 outputs the prediction error to the addition unit 312.

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

  FIG. 14 is a flowchart showing the operation of the header decoding unit 3020 used in the loop filter 305 (SAO unit 3052, ALF unit 3053) of this embodiment. As shown in FIG. 14 (a), the loop filter unit of this embodiment performs the following operation.

  S30500: The header decoding unit 3020 determines whether or not the effective area of the block (target CTU) targeted by the loop filter is smaller than a predetermined size. When the effective area is equal to or larger than the predetermined size, the process proceeds to S30501. When the effective area of the target CTU is less than the predetermined size, the subsequent processing is omitted, the block loop filter information in block units is not decoded, and the processing ends.

  S30501: The header decoding unit 3020 decodes information (block loop filter information) on a loop filter that performs processing in block units. The loop filter information may include on / off information.

  S30502: The loop filter 305 determines whether or not the on / off flag decoded by the header decoding unit 3020 is on. If it is on, the process proceeds to S30503, and if it is off, the process ends.

  S30503: The loop filter 305 performs filter processing using the block loop filter information on the target block when the on / off flag is on.

  The SAO unit 3052 described below may limit the use of the edge offset when the effective area of the target block is small as shown in FIG. 14 (b).

  S30520: The header decoding unit 3020 determines whether or not the effective area of the block (target CTU) targeted by the loop filter is smaller than a predetermined size. When the effective area is equal to or larger than the predetermined size, the process proceeds to S30501. When the effective area of the target CTU is less than the predetermined size, the subsequent processing is omitted and the processing ends.

  S30521: The header decoding unit 3020 decodes the SAO edge offset information when the SAO type is edge offset.

  S30522: The loop filter 305 determines whether or not the on / off flag decoded by the header decoding unit 3020 is on. If it is on, the process proceeds to S30523, and if it is off, the process ends.

  S30523: The loop filter 305 performs filter processing using the block loop filter information on the target block when the on / off flag is on.

  As described above, the processing of the loop filter can be omitted only in the case of the edge offset using the peripheral pixels of the filter target pixel. In the case of band offset that does not use peripheral pixels, the loop filter process may not be omitted.

(SAO part 3052)
The loop filter unit 305 may include a SAO unit (SAO unit 3052). SAO is a process using SAO parameters notified for each CTU, and has an effect of removing ringing distortion and quantization distortion. The SAO unit 3052 generates the SAO-decoded image P_SAO by performing the SAO process on the input image.

  The SAO unit 3052 decodes information (SAO unit) of the loop filter that performs processing in CTU units when the effective area of the target CTU is equal to or larger than a predetermined size. When the effective area of the target CTU is less than the predetermined size, the loop filter information (SAO unit) in CTU units is not decoded, and the loop filter processing (SAO processing in this case) in CTU units is not performed.

  For example, the SAO unit 3052 may derive the effective area (wActBlk, hActBlk) of the target CTU from the screen size when tiles are not used.

wActBlk = Min (ctuWidth, wPict-xCtb)
hActBlk = Min (ctuHeight, hPict-yCtb)
When the tile is used, the SAO unit 3052 determines the effective area (wActBlk, hActBlk) of the target CTU from the tile size, the upper left coordinate of the tile in the in-screen coordinate system, and the upper left coordinate of the target CTU in the in-screen coordinate system. May be derived. Further, even when tiles are not used, the same processing may be performed assuming that the screen is one tile.

wActBlk = Min (ctuWidth, xTile [TileId] + wTile [TileId] -xCtb)
hActBlk = Min (ctuHeight, yTile [TileId] + hTile [TileId] -yCtb)
As shown in FIG. 8, the SAO unit 3052 decodes the SAO unit when the effective area (wActBlk, hActBlk) of the target area is equal to or larger than a predetermined size (MinSaoSize).

wActBlk> = MinSaoSize &&hActBlk> = MinSaoSize
The valid area determination formula may be wActBlk + hActBlk> = MinSaoSize, log2 (wActBlk) + log2 (hActBlk)> = MinSaoSize, wActBlk * hActBlk> = MinSaoSize.

  The threshold value of MinSaoSize may be set to a larger value as the quantization parameter QP increases. Further, the threshold may have an upper limit and a lower limit as follows.

MinSaoSize = Clip3 (16, CtuSize / 2, (QP + 32) / 2)
As shown in Fig. 34, the CTU coordinates (xCtb, yCtb) are coordinates with the tile upper left as the origin, that is, the tile area coordinates (xCtb, yCtb) and tile size (wTile, hTile) are used to calculate the effective area using the following formula. May be determined.

wActBlk = Min (ctuWidth, wTile [TileId] -xCtb)
hActBlk = Min (ctuHeight, hTile [TileId] -yCtb)
In this case, the SAO unit 3052 (header decoding unit 3020) uses a CTU filter flag that indicates whether or not to perform filter processing in CTU units when the width or height of the effective area of the target CTU is equal to or larger than a predetermined minimum size. When a certain sao_type_idx is decoded and the size is less than the minimum size, the decoding of the CTU filter flag is omitted and a value (0) indicating that filtering is not performed is set.

(SAO unit)
FIG. 17 is a diagram showing the syntax of the SAO unit (denoted as sao_unit () in FIG. 17) of the coded stream according to the present embodiment. The SAO unit is notified for each CTU, and includes SAO offset information sao_offset () and merge control information (sao_merge_left_flag, sao_merge_up_flag) of the SAO offset information as syntax elements. sao_merge_left_flag is a flag indicating whether or not the SAO offset information of the target CTU is copied from the left adjacent CTU of the target CTU. The sao_merge_up_flag is a flag indicating whether or not to copy the SAO offset information of the target CTU from the upper adjacent CTU of the target CTU.

(Sao_type_idx)
sao_type_idx is an identifier that represents an offset type that indicates whether SAO is on or off and the type of SAO. There are roughly two types of offset types: edge offset (EO) and band offset (BO). The EO is a process of adding any one of a plurality of offsets to the pixel value of the target pixel according to the difference between the pixel value of the target pixel and the pixel values of the peripheral pixels. BO is a process of adding any one of a plurality of offsets to the pixel value of the target pixel according to the target pixel value.
-Sao_type_idx = 0 indicates that SAO is not performed on the SAO pre-decoded image in the target CTU.
-Sao_type_idx = 2 indicates that EO is performed on the SAO pre-decoded image in the target CTU. In EO, sao_eo_class indicating the reference pixel position is encoded.
-Sao_type_idx = 1 indicates that BO is performed on the SAO pre-decoded image in the target CTU. In the BO, sao_band_position that specifies the left end position of the pixel value band to be processed is encoded.

(SaoOffsetVal)
In the process of SAO in the present embodiment, the absolute value of offset sao_offset_abs and code sao_offset_sign are included in the encoded stream, and the SAO unit 3052 derives and uses the offset value SaoOffsetVal actually used from sao_offset_abs and sao_offset_sign.

SaoOffsetVal [cIdx] [rx] [ry] [i + 1] = (1-2 * sao_offset_sign [cIdx] [rx] [ry] [i]) * sao_offset_abs [cIdx] [rx] [ry] [i] <<log2OffsetScale (Formula SAO-1)
Here, log2OffsetScale is a quantization parameter used when quantizing the offset, and values such as 0, 1, 2 are normally used. cIdx is an index indicating a color component, and for example, cIdx = 0 (luminance), 1 (color difference Cb), and 2 (color difference Cr).

  Also, sao_offset_sign is encoded as a parameter for deriving the sign of the offset value added to each derived pixel. The sao_offset_sign is encoded when the added offset value is other than 0.

  FIG. 18 (a) shows a block diagram of the SAO unit 3052. The SAO unit 3052 includes a category setting unit 1001, an offset information storage unit 1002, and an offset addition unit 1003.

(Category setting unit 1001)
The category setting unit 1001 sets the category of each pixel position corresponding to the offset type sao_type_idx. Also, the offset SaoOffsetVal is derived, and the category and offset are output to the offset addition unit 1003. When sao_type_idx is 0, the category is not calculated.

  When sao_type_idx is 2 (EO), the category setting unit 1001 sets sao_eo_class to the offset class class indicating the edge classification shown in FIG. 16 (a). The class corresponds to the reference pixel direction viewed from the target pixel and is used for selecting the reference pixel. When class = 0, the pixels on the left and right of the target pixel X are set to the reference pixels a and b, when class = 1, the pixels above and below the target pixel X are set to a and b, and when class = 2, The upper left and lower right pixels of the target pixel X are set in a and b, and when class = 3, the lower left and upper right pixels of the target pixel x are set in a and b.

  Next, the difference sign (rec [x] -rec [a]) and sign (rec [x] -rec [b]) between the target pixel x and the pixel values of the two reference pixels a and b specified by class are calculated. Use to derive edgeIdx.

edgeIdx = sign (rec [x] -rec [a]) + sign (rec [x] -rec [b]) + 2 (Formula SAO-5)
sign (x) = 1 (x> 0)
= 0 (x = 0)
= -1 (x <0)
Here, rec [x] represents the decoded pixel value of pixel x. The category cat is calculated from this edgeIdx.

cat = (edgeIdx == 2)? 0: edgeIdx + 1 (edgeIdx <= 2) (Formula SAO-6)
= edgeIdx (edgeIdx> 2)
FIG. 16 (b) shows the magnitude relationship between the target pixel value x indicated by the category cat and the reference pixels a and b when class = 0. The black circle is the target pixel x, the white circle on the left side of x is the reference pixel a, and the white circle on the right side of x is the reference pixel b, and the vertical direction represents the magnitude relationship of the pixel values.

  When sao_type_idx is 1 (BO), the category setting unit 1001 divides the pixel values of 0 to 2 ^ bitDepth-1 into bands as shown in FIG. 16 (c). The category setting unit 1001 sets four consecutive bands from the band indicated by the band offset position (sao_band_position) decoded by the entropy decoding unit 301 to 1 to 4 of the category cat.

cat = (rec [x] [y] >> bandShift) -sao_band_position + 1 (Formula SAO-7)
if (cat <= 0 || cat> 4) cat = 0
Here, rec [x] [y] is the pixel value of the SAO pre-decoded image, and bandShift is log2 (bandW).

  Further, the offset SaoOffsetVal of (Equation SAO-1) is derived, and the category cat and the offset SaoOffsetVal are output to the offset addition unit 1003.

(Offset adder 1003)
The offset addition unit 1003 adds the offset SaoOffsetVal to the pixel value recPicture [] [] of the input image (deblocked decoded image P_DB or local decoded image P) and sets it as the pixel value of the filtered decoded image P_FL.

saoPicture [x] [y] = Clip3 (0, (1 << bitDepth) -1, recPicture [x] [y] + SaoOffsetVal [cIdx] [rx] [ry] [edgeIdx or bandIdx])
(ALF part 3053)
The loop filter unit 305 may include an ALF unit (ALF unit 3053). ALF is a process that uses ALF parameters notified for each CTU, and is effective in removing various coding noises. The ALF unit 3053 generates an ALF-processed decoded image P_ALF by performing an ALF process on the input image (for example, the decoded image, the DF-processed decoded image, or the SAO-processed decoded image).

  FIG. 18 (b) shows a block diagram of the ALF unit 3053. The ALF unit 3053 includes a filter information storage unit 30531 and an ALF filter processing unit 30532.

  The ALF unit 3053 decodes information (ALF unit) of a loop filter that performs processing in CTU units when the effective area of the target CTU is equal to or larger than a predetermined size. When the effective area of the target CTU is smaller than the predetermined size, the loop filter information (ALF unit) in units of CTU is not decoded, and the loop filter processing in units of CTU (ALF processing here) is not performed.

  For example, the ALF unit 3053 may derive the effective area (wActBlk, hActBlk) of the target CTU from the screen size when tiles are not used.

wActBlk = Min (ctuWidth, wPict-xCtb)
hActBlk = Min (ctuHeight, hPict-yCtb)
When the tile is used, the ALF unit 3053 determines the effective area (wActBlk, hActBlk) of the target CTU from the tile size, the upper left coordinate of the tile of the in-screen coordinate system, and the upper left coordinate of the target CTU of the in-screen coordinate system. You may derive it. Further, even when tiles are not used, the same processing may be performed assuming that the screen is one tile.

wActBlk = Min (ctuWidth, xTile [TileId] + wTile [TileId] -xCtb)
hActBlk = Min (ctuHeight, yTile [TileId] + hTile [TileId] -yCtb)
Here, TileId is the tile ID of the tile including the target CTU.

  As shown in FIG. 8, the ALF unit 3053 decodes the ALF unit when the effective area (wActBlk, hActBlk) of the target block is equal to or larger than a predetermined size (MinAlfSize).

wActBlk> = MinAlfSize &&hActBlk> = MinAlfSize
The expression for determining the effective area may be wActBlk + hActBlk> = MinAlfSize, log2 (wActBlk) + log2 (hActBlk)> = MinAlfSize, wActBlk * hActBlk> = MinAlfSize.

  As shown in Fig. 34, the CTU coordinates (xCtb, yCtb) are coordinates with the tile upper left as the origin, that is, the tile area coordinates (xCtb, yCtb) and tile size (wTile, hTile) are used to calculate the effective area using the following formula. May be determined.

wActBlk = Min (ctuWidth, wTile [TileId] -xCtb)
hActBlk = Min (ctuHeight, hTile [TileId] -yCtb)
In this case, the ALF unit 3053 decodes alf_ctu_flag, which is a CTU filter flag indicating whether to perform filter processing in CTU units when the width or height of the effective area of the target CTU is equal to or larger than a predetermined minimum size, When the size is less than the minimum size, decoding of the CTU filter flag alf_ctu_flag is omitted, and a value (0) indicating that filtering is not performed is set.

  FIG. 15 is a diagram showing the syntax of the ALF unit (denoted as alf_unit () in FIG. 15) of the encoded stream according to the present embodiment. The ALF unit is notified for each CTU and includes ALF unit alf_param () and ALF unit merge control information (alf_merge_left_flag, alf_merge_up_flag) as syntax elements. alf_merge_left_flag is a flag indicating whether or not to copy the ALF unit of the target CTU from the left adjacent CTU of the target CTU. alf_merge_up_flag is a flag indicating whether or not to copy the ALF unit of the target CTU from the upper adjacent CTU of the target CTU. Further, the ALF unit may copy the information of the ALF unit of the CTU at another position regardless of the upper adjacent CTU and the left adjacent CTU, or the information of the ALF database (ALF table) holding the separately provided ALF unit.

  The ALF unit 3053 decodes the filter coefficient when performing the filtering process (when alf_ctu_flag = 1). The decoded filter coefficient is stored in the filter information storage unit 30531 and can be reused according to the merge control information. Even when alf_ctu_flag = 1, when the merge control information performs the merge, the filter coefficient stored in the filter information storage unit 30531 is read and used. Here, an example of decoding a filter coefficient of i = 0..24 as a 5x5 filter coefficient will be described, but the filter shape is not limited to 5x5, and 9x7, 7x7 diamond, 5x5 diamond, 9x5 cross, 9x7 cross + 3x3 rhombus And so on. Alternatively, 25/2 + 1 = 13 filter coefficients may be transmitted by using rotational symmetry.

  Specifically, the syntax alf_coeff_abs [cIdx] [rx] [ry] [i] indicating the absolute value and the syntax alf_coeff_sign [cIdx] [rx] [ry] [i] indicating the sign are decoded, and (rx, The filter coefficient alf_coeff [cIdx] [i] indicated by the position of (ry) is derived.

alf_coeff [cIdx] [i] = alf_coeff_abs [cIdx] [rx] [ry] [i] * (1-2 * alf_coeff_sign [cIdx] [rx] [ry] [i])
The ALF filter processing unit 30532 performs filter processing by product-sum calculation. Further, addition, shift, and clipping may be performed after the product-sum calculation as described below. Here, x, y represents the coordinates of the pixel to be filtered in the target CTU, and x = xCtb..xCtb + wActBlk-1, y = yCtb..yCtb + hActBlk-1 is filtered for x, y in the range. Is done.

alfPicture [x] [y] = Clip3 (0, (1 << bitDepth) -1, Σ (recPicture [x + i% 5-2] [y + i / 5-2] * alf_coeff [cIdx] [i] +128) >> 8)
Here, Σ is addition up to i = 0..24. Further, 128 and 8 are offset and shift processing when the offset is transmitted in a fixed 8-bit decimal number, and may be changed depending on the accuracy of the offset. In addition to the product-sum calculation, the offset term (bias term) may be further transmitted as an ALF parameter. For example, the bias term may be transmitted as a parameter of i = 25.

  The threshold value of MinAlfSize may be set to a larger value as the quantization parameter QP increases. Further, the threshold may have an upper limit and a lower limit as follows.

MinAlfSize = Clip3 (16, CtuSize / 2, (QP + 32) / 2)
According to the SAO unit 3052 or the ALF unit 3053, a CTU filter processing unit (SAO unit 3052 or CTU unit that performs filter processing in CTU units in a moving image decoding apparatus that divides tiles into CTU units and decodes moving images in CTU units. ALF part 3053) is provided, and the width or height of the CTU ends with a size smaller than the predetermined CTU size (ctuWidth, ctuHeight), and the effective area (wActBlk, hActBlk) is different from the predetermined CTU size (ctuWidth, ctuHeight). If the width wActBlk or the height hActBlk of the effective area (actual CTU size) of the target CTU is equal to or larger than a predetermined minimum size (MinSaoSize, MinAlfSize), the CTU filter processing unit performs the filter processing, and the minimum When the size is less than the size, the CTU filter processing unit does not perform the filter processing.

  The header decoding unit 3020 decodes the CTU filter flag indicating whether or not to perform the filtering process in units of CTU, and when the width or height of the effective area of the target CTU is equal to or larger than a predetermined minimum size, the CTU filter is used. When the flag is decoded and the size is less than the minimum size, the decoding of the CTU filter flag is omitted and a value (0) indicating that filtering is not performed is set.

As described above, in a small CTU, the SAO unit and the ALF unit are not transmitted, and the code amount of the loop filter can be reduced, so that the coding efficiency is improved. Conversely, since the effect of the loop filter is proportional to the area to be applied, even with a small CTU, even if the SAO unit or ALF unit is transmitted, the effect of the overhead of the code amount cannot be expected and the effect becomes negative. There is, and you can prevent this.

(Modification)
When the screen is composed of multiple tiles, there is a tile boundary within the screen. When performing loop filter processing on a tile boundary, it is necessary to convert the coordinate system from the in-tile coordinate system to the in-screen coordinate system (Fig. 35).

  CTU unit in the screen, which is obtained by adding the CTB coordinate (rx, ry) in the CTU unit in the tile coordinate system to the tile upper left coordinate (TileXInCtbY [TileId], TileXInCtbX [TileId]) in the CTU unit in the screen. The coordinates (tx, ty) are derived and the ALF on / off flag alf_ctb_flag [cIdx] [tx] [ty] and cIdx = 0..2 are decoded in this unit (Fig. 36).

tx = rx + TileXInCtbY [TileId]
ty = ry + TileYInCtbY [TileId]
As described above, when the filter parameter (for example, alf_ctb_flag) is stored in the encoded data in units of CTU or CU, the coordinates in the in-screen coordinate system are converted from the in-tile coordinate system to the in-screen coordinate system. By storing the filter parameters in the table indexed by (tx, ty), you can easily access the filter parameters when filtering tile boundaries, even if the screen consists of multiple tiles. This has the effect of enabling processing.

  Further, the coordinates are converted from the in-tile coordinate system to the in-screen coordinate system, and processing is performed on the screen. For example, the coordinates in the tile (xCtbInTile, yCtbInTile) are converted to the coordinates in the screen (xCtbInPic, yCtbInPic) by the following formula.

xCtbInPic = xCtbInTile + xTile [TileId]
yCtbInPic = yCtbInTile + yTile [TileId]
Further, the CTU upper left coordinate in the screen may be derived from the coordinates (rx, ry) in the CTU unit in the tile coordinate system by the following formula, and the filtering process may be performed on each pixel of each CTB of each tile.

xCtb = (rx << CtbLog2SizeY) + xTile [TileId]
yCtb = (ry << CtbLog2SizeY) + yTile [TileId]
As described above, by converting from the in-tile coordinate system to the in-screen coordinate system, and performing the loop filter process, even when the screen is composed of multiple tiles, the tile unit is repeatedly processed by repeating the process. The effect that filter processing can be performed on the boundary is achieved. By this, even when a part of tiles is extracted, the tile boundary can be filtered by repeating the process for each tile.

  Whether or not to perform the loop filter process on the tile boundary may be switched using a flag for each screen, each tile group, or each tile. Here, an example of switching with loop_filter_across_tiles_enabled_flag will be described.

  If loop_filter_across_tiles_enabled_flag is 1 (true), the pixel referred to by the target pixel (coordinates (x, y)) of the loop filter process may belong to a tile different from the tile to which the coordinates (x, y) belong. On the other hand, if loop_filter_across_tiles_enabled_flag is 0 (false), the pixel referred to by the target pixel (x, y) of the loop filter process must not belong to the tile different from the tile to which the coordinate (x, y) belongs.

The loop filter unit 107 (deblocking filter unit, SAO unit 3052 or ALF filter processing unit 30532) of the present embodiment, the coordinates indicating the position of the reference pixel is clipped in the range of the tile in advance, the reference pixel is derived, and the filter Perform processing.

  The following is an example in which the ALF filter processing including the coordinate clipping processing is expressed in pseudo code. The reference pixel buffer (recPicture) is referenced using a value obtained by clipping the coordinates (x + i% 5-2, y + i / 5-2) indicating the position of the reference pixel.

if (tile_enabled_flag &&! loop_filter_across_tiles_enabled) {
for (sum = 0, i = 0; i <= 24; i ++) {
hx = Clip3 (TileX [TileId], TileX [TileId] + TileWidth [TileId] -1, x + i% 5-2)
vy = Clip3 (TileY [TileId], TileY [TileId] + TileHeight [TileId] -1, y + i / 5-2)
sum + = (recPicture [hx] [vy] * alf_coeff [cIdx] [i] + (1 << (coeffBits-1))) >> coeffBits
}
} else {
sum = Clip3 (0, (1 << bitDepth) -1, Σ (recPicture [x + i% 5-2] [y + i / 5-2] * alf_coeff [cIdx] [i] + (1 << ( coeffBits-1))) >> coeffBits)
}
alfPicture [x] [y] = Clip3 (0, (1 << bitDepth) -1, sum) If loop_filter_across_tilesenabled is set to true only when tile_enabled_flag is true, instead of condition (tile_enabled_flag &&! loop_filter_across_tiles_enabled) It may be (! Loop_filter_across_tiles_enabled).

  Further, although the clipping process (Clip3 () function) is used as the reference constraint method for the pixels outside the tile here, the padding process may be performed in the buffer (recPicture) storing the reference pixel value. In that case, the same value as the pixel of the coordinate inside the tile may be stored in advance as the pixel value of the coordinate outside the tile in recPicture. However, it is desirable to copy the recPicture to a temporary buffer so that the original recPicture image is not destroyed. It is realized by using the pixel value refPicture [ti] [tj] at the following position (ti, tj) as the pixel value at the reference pixel position (i, j). That is, it is realized by clipping the reference position at the positions of the boundary pixels on the top, bottom, left, and right of the tile.

ti = Clip3 (TileX [TileId], TileX [TileId] + TileWidth [TileId] -1, i)
tj = Clip3 (TileY [TileId], TileY [TileId] + TileHeight [TileId] -1, j)
Further, loop_filter_across_tiles_enabled_flag is a flag common to all tile boundaries, but a plurality of flags may be used in order to separately control tile boundaries into a plurality of types. An example is shown in FIG.

  FIG. 37 (a) is an example of syntax using loop_filter_across_vertical_tile_boundary_enabled_flag and loop_filter_across_horizontal_tile_boundary_enabled_flag instead of loop_filter_across_tiles_enabled_flag. When loop_filter_across_vertical_tile_boundary_enabled_flag is true, it indicates that pixels included in tiles horizontally adjacent to each other can be referred to beyond the tile boundary in the vertical direction. When loop_filter_across_horizontal_tile_boundary_enabled_flag is true, it indicates that pixels included in vertically adjacent tiles can be referenced beyond the horizontal tile boundary. The following is pseudo code that represents ALF filtering.

if (tile_enabled_flag) {
for (sum = 0, i = 0; i <= 24; i ++) {
if (loop_filter_across_vertical_tile_boundary_enabled_flag) {
hx = x + i% 5-2
} else {
hx = Clip3 (TileX [TileId], TileX [TileId] + TileWidth [TileId] -1, x + i% 5-2)
}
if (loop_filter_across_horizontal_tile_boundary_enabled_flag) (
vy = y + i / 5-2
} else {
vy = Clip3 (TileY [TileId], TileY [TileId] + TileHeight [TileId] -1, y + i / 5-2)
}
sum + = (recPicture [hx] [vy] * alf_coeff [cIdx] [i] + (1 << (coeffBits-1))) >> coeffBits
}
} else {
sum = Clip3 (0, (1 << bitDepth) -1, Σ (recPicture [x + i% 5-2] [y + i / 5-2] * alf_coeff [cIdx] [i] + (1 << ( coeffBits-1))) >> coeffBits)
}
alfPicture [x] [y] = Clip3 (0, (1 << bitDepth) -1, sum)
According to the processing of the pseudo code, when the loop_filter_across_vertical_tile_boundary_enabled_flag is true, the reference pixel position in the horizontal direction is restricted, that is, the clip processing is not performed, and the clip processing is performed only when it is false. Similarly, when loop_filter_across_horizontal_tile_boundary_enabled_flag is true, it is limited to the reference pixel position in the vertical direction, that is, clipping processing is not performed, and is performed only when it is false.

  FIG. 37 (b) is an example of syntax that uses loop_filter_across_top_left_tile_boundary_enabled_flag and loop_filter_across_bottom_right_tile_boundary_enabled_flag instead of loop_filter_across_tiles_enabled_flag. When loop_filter_across_top_left_tile_boundary_enabled_flag is true, it indicates that the pixel can be referenced beyond the upper boundary and the left boundary of the target tile. When loop_filter_across_bottom_right_tile_boundary_enabled_flag is true, it indicates that the pixel can be referred to beyond the lower boundary and the right boundary of the target tile. The following is pseudo code that represents the ALF filtering process at this time.

if (tile_enabled_flag) {
for (sum = 0, i = 0; i <= 24; i ++) {
if (loop_filter_across_top_left_tile_boundary_enabled_flag) {
min_hx = 0
min_vy = 0
} else {
min_hx = TileX [TileId]
min_vy = TileY [TileId]
}
if (loop_filter_across_bottom_right_tile_boundary_enabled_flag) {
max_hx = pic_width_in_luma_samples-1
max_vy = pic_height_in_luma_samples-1
} else {
max_hx = TileX [TileId] + TileWidth [TileId] -1
max_vy = TileY [TileId] + TileHeight [TileId] -1
}
hx = Clip3 (min_hx, max_hx, x + i% 5-2)
vy = Clip3 (min_vy, max_vy, y + i / 5-2)
}
sum + = (recPicture [hx] [vy] * alf_coeff [cIdx] [i] + (1 << (coeffBits-1))) >> coeffBi
ts
}
} else {
sum = Clip3 (0, (1 << bitDepth) -1, Σ (recPicture [x + i% 5-2] [y + i / 5-2] * alf_coeff [cIdx] [i] + (1 << ( coeffBits-1))) >> coeffBits)
}
alfPicture [x] [y] = Clip3 (0, (1 << bitDepth) -1, sum)
According to the above pseudo code, when the loop_filter_across_top_left_tile_boundary_flag is true, the reference pixel of the ALF can be acquired beyond the upper boundary and the left boundary of the target tile. Therefore, the minimum value (min_hx, min_vy) that the coordinates (x + i% 5-2, y + i / 5-2) of the reference pixel can take is set to (0, 0). When false, the minimum value (min_hx, min_hy) that the coordinate (x + i% 5-2, y + i / 5-2) of the reference pixel can take is the upper left coordinate of the tile including the target CTU ( TileX [TileId], TileY [TileId]). By clipping the X and Y coordinates using the minimum value set in this way, it is possible to control whether or not the positions of the reference pixels in the left and upper directions are restricted within the tile including the target CTU. On the other hand, when loop_filter_across_bottom_right_tile_boundary_flag is true, the reference pixel of ALF can be acquired beyond the lower boundary and the right boundary of the target tile, so the coordinates of the reference pixel (x + i% 5-2, y + i / 5- The maximum value (max_hx, max_vy) that can be taken in 2) is set to the size of the picture (pic_width_in_luma_samples-1, pic_height_in_luma_samples-1). If false, the maximum possible value (max_hx, max_hy) of the reference pixel coordinates (x + i% 5-2, y + i / 5-2) is the lower right coordinate of the tile containing the target CTU. It is set to (TileX [TileId] + TileWidth [TileId] -1, TileY [TileId] + TileHeight [TileId] -1). By clipping the X and Y coordinates using the maximum value set in this way, it is possible to control whether or not the positions of the reference pixels in the lower and right directions are restricted within the tile including the target CTU. Note that coeffBits is a number indicating the bit precision of the filter coefficient.

Fig. 37 (c) illustrates loop_filter_across_top_tile_boundary_enabled_flag, loop_filter_across_bottom_tile_boundary_enabled_flag, loop_filter_across_left_tile_boundary_enabled_flag, and a loop_filter_across_right_tile_boundary_boundary_enabled_flag, which is an example of syntax_enabled_flag, instead of loop_filter_across_tiles_enabled_flag. If each is true, it indicates that the pixel can be referenced beyond the upper, lower, left, and right boundaries of the target tile boundary. When the value is false, the clipping process is performed so that the coordinate value is within the target tile. The following is pseudo code that represents ALF filtering at this time:
if (tile_enabled_flag) {
for (sum = 0, i = 0; i <= 24; i ++) {
if (loop_filter_across_top_tile_boundary_enabled_flag) {
min_vy = 0
} else {
min_vy = TileY [TileId]
}
if (loop_filter_across_bottom_tile_boundary_enabled_flag) {
max_vy = pic_height_in_luma_samples-1
} else {
max_vy = TileY [TileId] + TileHeight [TileId] -1
}
if (loop_filter_across_left_tile_boundary_enabled_flag) {
min_hx = 0
} else {
min_hx = TileX [TileId]
}
if (loop_filter_across_right_tile_boundary_enabled_flag) {
max_hx = pic_width_in_luma_samples-1
} else {
max_hx = TileX [TileId] + TileWidth [TileId] -1
}
hx = Clip3 (min_hx, max_hx, x + i% 5-2)
vy = Clip3 (min_vy, max_vy, y + i / 5-2)
}
sum + = (recPicture [hx] [vy] * alf_coeff [cIdx] [i] + (1 << (coeffBits-1))) >> coeffBits
}
} else {
sum = Clip3 (0, (1 << bitDepth) -1, Σ (recPicture [x + i% 5-2] [y + i / 5-2] * alf_coeff [cIdx] [i] + (1 << ( coeffBits-1))) >> coeffBits)
}
alfPicture [x] [y] = Clip3 (0, (1 << bitDepth) -1, sum)
According to the above pseudo code, it is possible to control in more detail whether reference is possible beyond the target tile boundary. When loop_filter_across_top_tile_boundary_enabled_flag is true, the minimum value min_vy that the Y coordinate of the reference pixel can take is set to 0. When false, the minimum value min_vy that can be taken by the Y coordinate of the reference pixel is set to TileY [TileId] which is the upper left Y coordinate of the tile including the target CTU. When loop_filter_across_bottom_tile_boundary_enabled_flag is true, the maximum value max_vy that can be taken by the Y coordinate of the reference pixel is set to pic_height_in_luma_samples-1. In the case of false, the maximum value max_vy that can be taken by the Y coordinate of the reference pixel is set to TileY [TileId] + TileHeight [TileId] -1 which is the lower right Y coordinate of the tile including the target CTU. When loop_filter_across_left_tile_boundary_enabled_flag is true, the minimum value min_hx that can be taken by the X coordinate of the reference pixel is set to 0. If false, the minimum value min_hx that can be taken by the X coordinate of the reference pixel is set to TileX [TileId] that is the upper left X coordinate of the tile including the target CTU. When loop_filter_across_right_tile_boundary_enabled_flag is true, the maximum value max_hx that the X coordinate of the reference pixel can take is set to pic_width_in_luma_samples-1. If false, the maximum value max_hx that can be taken by the X coordinate of the reference pixel is set to TileX [TileId] + TileWidth [TileId] -1, which is the lower right X coordinate of the tile including the target CTU. By clipping the X and Y coordinates using the minimum value set in this way, whether to limit the position of the reference pixel in each of the up, down, left, and right directions within the tile that includes the target CTU is independently determined. You can control.

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

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

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

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

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

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

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

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

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

  The TU encoding unit 1114 encodes QP update information (quantization correction value) and quantization prediction error (residual_coding) when the TU includes a prediction error.

  The entropy coding unit 104 converts the syntax element supplied from the 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 sources of syntax elements are the CT information encoding unit 1111 and the CU encoding unit 1112. Syntax elements include 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, flag_rem_selected. , Rem_selected_mode, rem_non_selected_mode,), quantized transform coefficients, and the like.

  The addition unit 106 adds the pixel value of the prediction image of the block input from the prediction image generation unit 101 and the prediction error input from the inverse quantization / inverse conversion 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.

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

  The prediction parameter memory 108 stores the prediction parameter generated by the coding parameter determination unit 110 in a predetermined position for each target picture and CU.

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

  The coding parameter determination unit 110 selects one set from among a plurality of sets of coding parameters. The coding parameter is the above-mentioned QT, BT or TT partition information, a prediction parameter, or a parameter to be coded generated in association with these. The predicted image generation unit 101 generates a predicted image using these coding parameters.

  The coding parameter determination unit 110 calculates the RD cost value indicating the size of the information amount 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 squared error multiplied by the coefficient λ. The code amount is the information amount of the coded stream Te obtained by entropy coding the quantization error and the coding parameter. The squared error is the sum of squares of the prediction errors calculated by the subtraction unit 102. The coefficient λ is a real number larger than zero that is set in advance. The coding parameter determination unit 110 selects the set of coding parameters that minimizes the calculated cost value. As a result, the entropy coding unit 104 outputs the selected set of coding parameters as the coded stream Te. The coding parameter determination unit 110 stores the determined coding parameter in the prediction parameter memory 108.

  Note that the moving picture coding device 11 and a part of the moving picture 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 predicted image generation unit 308, the inverse quantization / inverse. The conversion unit 311, the addition unit 312, the predicted image generation unit 101, the subtraction unit 102, the conversion / quantization unit 103, the entropy coding unit 104, the dequantization / inverse conversion unit 105, the loop filter 107, the coding parameter determination unit 110. The parameter coding unit 111 may be realized by a computer. In that case, the program for realizing the control function may be recorded in a computer-readable recording medium, and the program recorded in the recording medium may be read by a computer system and executed. It should be noted that the “computer system” mentioned here is a computer system built in either the moving picture coding apparatus 11 or the moving picture decoding apparatus 31, and includes an OS and hardware such as peripheral devices. Further, the “computer-readable recording medium” refers to a portable medium such as a flexible disk, a magneto-optical disk, a ROM, a CD-ROM, or a storage device such as a hard disk built in a computer system. Further, "computer-readable recording medium" means a program that dynamically holds a program for a short time, such as a communication line when transmitting the program through a network such as the Internet or a communication line such as a telephone line. In this case, a volatile memory inside the computer system that serves as a server or a client that holds the program for a certain period of time may be included. Further, the above program may be one for realizing some of the functions described above, and may be one that can realize the above functions in combination with a program already recorded in the computer system.

  Further, part or all of the moving picture coding device 11 and the moving picture decoding device 31 in the above-described embodiments may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each functional block of the moving picture coding device 11 and the moving picture decoding device 31 may be individually made into a processor, or a part or all of them may be integrated and made into a processor. Further, the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. In addition, when a technique for forming an integrated circuit that replaces LSI appears due to the progress of semiconductor technology, an integrated circuit according to the technique 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, and various design changes and the like without departing from the scope of the present invention. It is possible to

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

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

  In the video decoding device according to the 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 one 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 the aspect of the present invention, the minimum unit of the tile size is derived by using a minimum CTU size and a difference value between the minimum unit of the tile size and the minimum CTU size. To do.

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

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

  In the moving image decoding apparatus according to the aspect of the present invention, the minimum unit of tile size is the minimum unit of tile size that does not exceed the CTU size.

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

  In the moving image decoding apparatus according to an aspect of the present invention, the predetermined value is set such that when each tile can be processed independently, the minimum unit of tile is set to be smaller than that when the tile is not processed.

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

  A moving picture coding apparatus according to an aspect of the present invention is a moving picture coding apparatus that divides an image into tiles, divides the tiles into CTUs, and encodes the moving picture in units of CTUs. A header encoding unit that sets a unit to a predetermined value, and a CT information encoding unit that encodes a CTU to generate an encoded stream, and the header encoding unit uses a minimum unit of tile size. The feature is that the upper left position of the tile and the tile size are derived.

[Application example]
The moving image encoding device 11 and the moving image decoding device 31 described above can be mounted and used in various devices that perform transmission, reception, recording, and reproduction of moving images. The moving image may be a natural moving image captured by a camera or the like, or 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 a moving image.

  FIG. 20 (a) is a block diagram showing a configuration of a transmission device PROD_A equipped with the moving image encoding device 11. As shown in FIG. 20 (a), the transmission device PROD_A has a coding unit PROD_A1 that obtains coded data by coding a moving image and a carrier wave with the coded data obtained by the coding unit PROD_A1. A modulator PROD_A2 that obtains a modulated signal and a transmitter PROD_A3 that transmits the modulated signal obtained by the modulator PROD_A2 are provided. The moving picture coding device 11 described above is used as the coding unit PROD_A1.

  The transmission device PROD_A is a camera PROD_A4 that captures a moving image, a recording medium PROD_A5 that records the moving image, an input terminal PROD_A6 for inputting the moving image from the outside, and a source of the moving image that is input to the encoding unit PROD_A1. An image processing unit A7 for generating or processing an image may be further provided. In FIG. 20 (a), a configuration in which all of these are included in the transmission device PROD_A is illustrated, but some of them may be omitted.

  The recording medium PROD_A5 may be a non-encoded moving image recorded, or a moving image encoded by a recording encoding method different from the transmission encoding method may be recorded. It may be one. In the latter case, a decoding unit (not shown) that decodes the encoded data read from the recording medium PROD_A5 according to the recording encoding method may be interposed between the recording medium PROD_A5 and the encoding unit PROD_A1.

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

  The receiving device PROD_B has a display PROD_B4 for displaying a moving image, a recording medium PROD_B5 for recording the moving image, and an output terminal for outputting the moving image to the outside as a supply destination of the moving image output by the decoding unit PROD_B3. PROD_B6 may be further provided. In FIG. 20 (b), a configuration in which the receiving device PROD_B is provided with all of them is illustrated, but a part thereof may be omitted.

  It should be noted that the recording medium PROD_B5 may be one for recording a non-encoded moving image, or may be one encoded by a recording encoding method different from the transmission encoding method. May be. In the latter case, an encoding unit (not shown) that encodes the moving image acquired from the decoding unit PROD_B3 according to the encoding method for recording may be interposed between the decoding unit PROD_B3 and the recording medium PROD_B5.

  The transmission medium that transmits the modulated signal may be wireless or wired. Further, the transmission mode for transmitting the modulated signal may be broadcast (here, it means a transmission mode in which the transmission destination is not specified in advance) or communication (here, transmission in which the transmission destination is specified in advance). Embodiment). That is, the transmission of the modulated signal may be realized by any of wireless broadcasting, wired broadcasting, wireless communication, and wired communication.

  For example, a terrestrial digital broadcasting broadcasting station (broadcasting equipment or the like) / receiving station (television receiver or the like) is an example of a transmitting device PROD_A / receiving device PROD_B that transmits and receives modulated signals by wireless broadcasting. Also, a broadcasting station (broadcasting facility etc.) / Receiving station (television receiver etc.) of cable television broadcasting is an example of a transmitting device PROD_A / receiving device PROD_B which transmits / receives a modulated signal by cable broadcasting.

  A server (workstation, etc.) / Client (TV receiver, personal computer, smartphone, etc.) for VOD (Video On Demand) services and video sharing services using the Internet is a transmission device that transmits and receives modulated signals by communication. This is an example of PROD_A / reception device PROD_B (generally, either wireless or wired is used as a transmission medium in LAN, and wired is used as a transmission medium in WAN). Here, the personal computer includes a desktop PC, a laptop PC, and a tablet PC. The smartphone also includes a multifunctional mobile phone terminal.

  The client of the moving image sharing service has a function of decoding the encoded data downloaded from the server and displaying it on the display, as well as a function of encoding the moving image captured by the camera and uploading it to the server. That is, the client of the moving image sharing service functions as both the transmission device PROD_A and the reception 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 a moving image.

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

  Note that the recording medium PROD_M may be (1) a type such as an HDD (Hard Disk Drive) or SSD (Solid State Drive) built in the recording device PROD_C, or (2) SD memory. It may be of a type that is connected to the recording device PROD_C, such as a card or a USB (Universal Serial Bus) flash memory, or (3) DVD (Digital Versatile Disc: registered trademark) or BD (Blu-ray). For example, a disc (registered trademark) or the like may be loaded in a drive device (not shown) incorporated in the recording device PROD_C.

  Further, the recording device PROD_C has a camera PROD_C3 for capturing a moving image, an input terminal PROD_C4 for externally inputting the moving image, and a receiving unit for receiving the moving image as a source of the moving image input to the encoding unit PROD_C1. The unit PROD_C5 and the image processing unit PROD_C6 for generating or processing an image may be further provided. In FIG. 21 (a), the recording device PROD_C is provided with all of them, but some of them may be omitted.

  Note that the receiving unit PROD_C5 may receive an uncoded moving image, or may receive encoded data encoded by a transmission encoding method different from the recording encoding method. It may be one that does. In the latter case, a transmission decoding unit (not shown) that decodes the encoded data encoded by the transmission encoding method may be interposed between the reception unit PROD_C5 and the encoding unit PROD_C1.

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

FIG. 21 (B) is a block showing a configuration of a reproduction device PROD_D equipped with the moving image decoding device 31 described above. As shown in FIG. 21 (b), the reproducing apparatus PROD_D obtains a moving image by decoding the read unit PROD_D1 that reads the encoded data written in the recording medium PROD_M and the encoded data read by the read unit PROD_D1. And a decryption unit PROD_D2. The moving picture decoding device 31 described above is used as this decoding unit PROD_D2.

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

  Also, the playback device PROD_D is a display PROD_D3 that displays a moving image, an output terminal PROD_D4 for outputting the moving image to the outside as a supply destination of the moving image output by the decoding unit PROD_D2, and a transmitting unit that transmits the moving image. PROD_D5 may be further provided. In FIG. 21 (b), a configuration in which the playback device PROD_D is provided with all of them is illustrated, but a part thereof may be omitted.

  The transmission unit PROD_D5 may be one that transmits an unencoded moving image, or transmits encoded data that has been encoded by a transmission encoding method different from the recording encoding method. It may be one that does. In the latter case, an encoding unit (not shown) that encodes a moving image by an encoding method for transmission may be interposed between the decoding unit PROD_D2 and the transmission unit PROD_D5.

  Examples of such a playback device PROD_D include 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 a main supply destination of the moving image). . Also, a television receiver (in this case, the display PROD_D3 is the main destination of the moving image), digital signage (also called an electronic signboard or electronic bulletin board, etc.) Desktop PC (in this case, the output terminal PROD_D4 or the transmitter PROD_D5 is the main destination of the moving image), laptop or tablet PC (in this case, the display PROD_D3 or the transmitter PROD_D5 is a moving image) An example of such a reproducing apparatus PROD_D is also a smartphone (in which the display PROD_D3 or the transmission unit PROD_D5 is the main destination of the moving image), and the like.

(Realization of hardware and software)
Further, each block of the moving picture decoding device 31 and the moving picture coding device 11 described above may be realized by hardware by a logic circuit formed on an integrated circuit (IC chip), or by a CPU (Central Processing). Unit), and may be realized by software.

In the latter case, each device has a CPU that executes instructions of a program that realizes each function, a ROM (Read Only Memory) that stores the program, and a RAM (Random Memory) that expands the program.
Access Memory), a storage device (recording medium) such as a memory for storing the program and various data. The object of the embodiment of the present invention is to record the program code (execution format program, intermediate code program, source program) of the control program of each device, which is software for realizing the above-described functions, in a computer-readable manner. This can also be achieved by supplying a medium to each of the above devices and causing the computer (or CPU or MPU) to read and execute the program code recorded in 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, and CD-ROMs (Compact Disc Read-Only Memory) / MO disks (Magneto-Optical discs). ) / MD (Mini Disc) / DVD (Digit
discs including optical discs such as al Versatile Discs / CD-Rs (CD Recordable) / Blu-ray Discs (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, PLD (Programmable logic device), FPGA (Field Programmable Gate Array), etc. It is possible to use the above logic circuits.

  Further, each of the above devices may be configured to be connectable to a communication network, and the program code may be supplied via the communication network. The communication network is not particularly limited as long as it can transmit the program code. For example, Internet, intranet, extranet, LAN (Local Area Network), ISDN (Integrated Services Digital Network), VAN (Value-Added Network), CATV (Community Antenna television / Cable Television) communication network, virtual private network (Virtual Private Network) Network), telephone network, mobile communication network, satellite communication network, etc. can be used. Further, the transmission medium that constitutes this communication network may be any medium that can transmit the program code, and is not limited to a specific configuration or type. For example, even if 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 network, satellite line, terrestrial digital broadcasting network, etc. It is also available wirelessly. The embodiment of the present invention can also be realized in the form of a computer data signal embedded in a carrier wave, in which the program code is embodied by electronic transmission.

  The embodiment of the present invention is not limited to the above-described embodiment, and various modifications can be made 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.

  The embodiments of the present invention are preferably applied to a moving image decoding device that decodes encoded data in which image data is encoded, and a moving image encoding device that generates encoded data in which image data is encoded. be able to. Further, it can be suitably applied to the data structure of encoded data generated by the moving image encoding device and referred to by the moving image decoding device.

11 Moving Image Encoding Device 31 Moving Image Decoding Devices 101, 308 Predicted Image Generating Unit 104 Entropy Encoding Unit (Encoding Unit)
107, 305 Loop filter 111 Parameter coding unit 301 Entropy decoding unit 302 Parameter decoding unit (division unit)
3036 merge prediction parameter derivation unit 30361 merge candidate derivation unit 30361 (temporal motion prediction unit)
30362 Merge candidate selection unit 30362

Claims (5)

  In the temporal motion prediction unit that derives the lower right position (xBr, yBr) or the center position (xCtr, yCtr) as the reference position for referencing the motion vector of temporal prediction from the coordinates (xPb, yPb) of the target block The block coordinates (xPb, yPb) are coordinates with the tile upper left as the origin, and it is determined whether the reference position (xBr, yBr) or the center position (xCtr, yCtr) exceeds the tile size, and the tile size is A moving image decoding apparatus characterized by not referring to a motion vector for temporal prediction when the number exceeds.   In the temporal motion prediction unit that derives the lower right position (xBr, yBr) or the center position (xCtr, yCtr) as the reference position for referencing the motion vector of temporal prediction from the coordinates (xPb, yPb) of the target block The block coordinates (xPb, yPb) are coordinates with the tile upper left as the origin, and it is determined whether the reference position (xBr, yBr) or the center position (xCtr, yCtr) exceeds the tile size, and the tile size is A moving image decoding apparatus characterized by not referring to a motion vector for temporal prediction when the number exceeds. In the SAO processing unit, if the width of the effective area in the CTU is smaller than the predetermined width, or if the height of the effective area in the CTU is smaller than the predetermined height,
A moving image decoding apparatus that does not decode the CTU parameter of SAO, sets the SAO processing flag of CTU to 0, and does not perform filter processing. In the ALF processing unit, the width of the effective area in the CTU is smaller than the predetermined width, or the height of the effective area in the CTU is smaller than the predetermined height,
A video decoding device that does not decode the ALF CTU parameter, sets the CTU ALF processing flag to 0, and does not perform filter processing. In the ALF processing, when the peripheral pixel that is referred to for processing the target pixel has a flag that allows it to belong to a tile different from the tile to which the target pixel belongs, is invalid,
A moving image decoding apparatus for deriving a peripheral pixel to be referenced by clipping coordinates when deriving a peripheral pixel to be referenced into a tile to which a symmetrical pixel belongs.

Images