Image encoding device, image decoding device, image encoding method, image decoding method

Abstract

To provide an image decoding device and an image decoding method, an image encoding device and an image encoding method, and a program for reducing redundant syntax to reduce a code amount of bit streams.SOLUTION: When a value of a first flag is 1 and a second flag indicates that a second mode is used, on the basis of an address of a slice, first information corresponding to the number of blocks in a vertical direction of a rectangular region, and second information on the number of rectangular regions included in the slice, an image decoding device specifies, for the slice, the number of pieces of information for specifying a head position of encoding data in a block row. The image decoding device decodes third information on the size of an image from bit streams, and decodes the encoding data in the block row on the basis of the specified number of pieces of information for specifying the head position and the information for specifying the head position.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to image encoding / decoding technology.

Background Art

[0002] As an encoding method for compression recording of moving images, the HEVC (High Efficiency Video Coding) encoding method (hereinafter referred to as HEVC) is known. In HEVC, in order to improve encoding efficiency, a basic block having a size larger than a conventional macroblock (16×16 pixels) is adopted. This basic block having a large size is called a CTU (Coding Tree Unit), and its size is up to 64×64 pixels at maximum. A CTU is further divided into sub-blocks which are units for performing prediction and conversion.

[0003] Also in HEVC, it is possible to divide a picture into a plurality of tiles or slices and perform encoding. There is little data dependency between each tile or slice, and encoding / decoding processing can be performed in parallel. One of the great advantages of tile and slice division is that processing can be executed in parallel using a multi-core CPU or the like, and the processing time can be shortened.

[0004] Also, each slice is encoded by a conventional binary arithmetic coding method adopted in HEVC. That is, each syntax element is binarized to generate a binary signal. Each syntax element is given a generation probability in advance as a table (hereinafter referred to as a generation probability table), and the binary signal is arithmetic-coded based on the generation probability table. This generation probability table is used as decoding information for decoding subsequent codes during decoding. During encoding, it is used as encoding information for subsequent encoding. And every time encoding is performed, the generation probability table is updated based on statistical information as to whether the encoded binary signal is a symbol with a higher generation probability.

[0005] HEVC also has a technique called Wavefront Parallel Processing (WPP) for parallel processing of entropy coding and decoding. In WPP, a table of occurrence probabilities at the time a block at a predetermined position is coded is applied to the leftmost block of the next row, thereby suppressing a decrease in coding efficiency and enabling parallel coding of blocks on a row-by-row basis. To enable parallel processing on a block-row basis, the slice header encodes entry_point_offset_minus1, which indicates the starting position of each block row in the bitstream, and num_entry_point_offsets, which indicates the number of such entries. Patent Document 1 discloses a technology related to WPP.

[0006] In recent years, efforts have been made to internationally standardize a more efficient encoding scheme as a successor to HEVC. The Joint Video Experts Team (JVET) was established between ISO / IEC and ITU-T, and standardization is underway for the Versatile Video Coding (VVC) encoding scheme. In VVC, it is being considered to further divide tiles into rectangles (bricks) composed of multiple block rows. Then, slices are configured to contain one or more bricks. [Prior art documents] [Patent Documents]

[0007] [Patent Document 1] Japanese Patent Publication No. 2014-11638 [Overview of the project] [Problems that the invention aims to solve]

[0008] In VVC, the bricks that make up a slice can be derived in advance, and the number of basic block rows contained within each brick can also be derived from other syntax. Therefore, the number of entry_point_offset_minus1, which indicates the starting position of the basic block rows belonging to the slice, can be derived without using num_entry_point_offset. Consequently, num_entry_point_offset becomes redundant syntax. This invention provides a technique to reduce the amount of code in a bitstream by reducing redundant syntax. [Means for solving the problem]

[0009] One embodiment of the present invention is an image decoding device that decodes an image from a bitstream obtained by encoding an image including a rectangular region containing one or more block rows consisting of multiple blocks, wherein the device decodes a first flag relating to the activation of parallel processing, decodes a second flag from the picture parameter set of the bitstream indicating whether a first mode in which the slice is rectangular is used or a second mode relating to the slice that is different from the first mode is used, decodes first information from the picture parameter set corresponding to the number of blocks in the vertical direction of the rectangular region in the image, decodes second information from the slice header of the bitstream indicating the number of rectangular regions included in the slice in the image, and in the case where the image contains multiple rectangular regions and the second flag indicates that the second mode is used The device comprises: a decoding means for decoding the address of a slice from the slice header; and a identifying means for specifying the number of pieces of information for specifying the starting position of the coded data of a block row for the slice, based on the address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular region, and the second information the number of rectangular regions included in the slice, when the value of the first flag is 1 and the second flag indicates that the second mode is used; the decoding means decodes a third information relating to the size of the image from the bitstream; and the decoding means decodes the coded data of the block row based on at least the number of pieces of information for specifying the starting position specified by the identifying means and the information for specifying the starting position. [Effects of the Invention]

[0010] According to the configuration of the present invention, the amount of code in the bitstream can be reduced by reducing redundant syntax. [Brief explanation of the drawing]

[0011] [Figure 1] A block diagram showing an example of the functional configuration of an image encoding device. [Figure 2] A block diagram showing an example of the functional configuration of an image decoding device. [Figure 3] A flowchart illustrating the encoding process of an input image by an image encoding device. [Figure 4] A flowchart illustrating the bitstream decoding process by an image decoding device. [Figure 5] A block diagram showing an example of a computer device's hardware configuration. [Figure 6] A diagram showing an example of a bitstream format. [Figure 7] A diagram showing an example of how to segment an input image. [Figure 8] A diagram showing an example of how to segment an input image. [Figure 9] A diagram showing the relationship between tiles and slices. [Modes for carrying out the invention]

[0012] The embodiments will be described in detail below with reference to the attached drawings. Note that the following embodiments do not limit the invention as defined in the claims. While the embodiments describe multiple features, not all of these features are essential to the invention, and the features may be combined in any way. Furthermore, in the attached drawings, identical or similar configurations are given the same reference numerals, and redundant descriptions are omitted.

[0013] [First Embodiment] First, an example of the functional configuration of the image encoding device according to this embodiment will be explained using the block diagram in Figure 1. The image division unit 102 receives the input image to be encoded. The input image may be images of each frame that make up a moving image, or it may be a still image. The image division unit 102 divides the input image into "one or more tiles". A tile is a set of consecutive basic blocks that cover a rectangular area within the input image. The image division unit 102 further divides each tile into one or more bricks. A brick is a rectangular area (a rectangular area containing one or more block rows consisting of multiple blocks smaller than or equal to a tile) composed of one or more rows of basic blocks (basic block rows) within a tile. The image division unit 102 further divides the input image into slices composed of "one or more tiles" or "one or more bricks within one tile". A slice is the basic unit of encoding, and header information such as information indicating the type of slice is added to each slice. Figure 7 shows an example of dividing the input image into 4 tiles, 4 slices, and 11 bricks. The top-left tile is divided into one brick, the bottom-left tile into two bricks, the top-right tile into five bricks, and the bottom-right tile into three bricks. The left slice is configured to contain three bricks, the top-right slice into two bricks, the right-center slice into three bricks, and the bottom-right slice into three bricks. The image division unit 102 outputs size information as division information for each of the tiles, bricks, and slices that have been divided in this way.

[0014] The block division unit 103 divides the image of a basic block row (basic block row image) output from the image division unit 102 into multiple basic blocks and outputs the image of each basic block (block image) to the next stage.

[0015] The prediction unit 104 divides an image in basic block units into sub-blocks, performs intra prediction which is intra-frame prediction or inter prediction which is inter-frame prediction in sub-block units, and generates a predicted image. Intra prediction across blocks (intra prediction using pixels of blocks of other blocks) and prediction of motion vectors across blocks (prediction of motion vectors using motion vectors of blocks of other blocks) are not performed. Further, the prediction unit 104 calculates and outputs a prediction error from the input image and the predicted image. Also, the prediction unit 104 outputs information necessary for prediction (prediction information), such as information on sub-block division methods, prediction modes, motion vectors, etc., together with the prediction error.

[0016] The transform and quantization unit 105 orthogonally transforms a prediction error in sub-block units to obtain transform coefficients, and quantizes the obtained transform coefficients to obtain quantization coefficients. The inverse quantization and inverse transform unit 106 inverse quantizes the quantization coefficients output from the transform and quantization unit 105 to reproduce transform coefficients, and further inverse orthogonally transforms the reproduced transform coefficients to reproduce a prediction error.

[0017] The frame memory 108 functions as a memory for storing the reproduced image. The image reproduction unit 107 appropriately refers to the frame memory 108 based on the prediction information output from the prediction unit 104 to generate a predicted image, and generates and outputs a reproduced image from the predicted image and the input prediction error.

[0018] The in-loop filter unit 109 performs in-loop filter processing such as deblocking filters and sample adaptive offsets on the reproduced image, and outputs an image (filtered image) subjected to the in-loop filter processing. [[ID=*13]]

[0019] The encoding unit 110 generates coded data (encoded data) by encoding the quantization coefficients output from the transform and quantization unit 105 and the prediction information output from the prediction unit 104, and outputs the generated coded data.

[0020] The integrated coding unit 111 generates header code data using the division information output from the image division unit 102, and generates and outputs a bitstream containing the generated header code data and the code data output from the coding unit 110. The control unit 199 controls the operation of the entire image coding device and controls the operation of each functional unit of the image coding device.

[0021] Next, the encoding process for an input image by an image encoding device having the configuration shown in Figure 1 will be described. In this embodiment, for the sake of simplicity, only the intra predictive coding process will be described, but it is not limited to this and can also be applied to inter predictive coding. Furthermore, in this embodiment, for the sake of a more specific explanation, the block division unit 103 will be described as dividing the basic block row image output from the image division unit 102 into units of "basic blocks having a size of 64 × 64 pixels".

[0022] The image splitting unit 102 divides the input image into tiles, bricks, and slices. An example of the input image splitting by the image splitting unit 102 is shown in Figure 8. In this embodiment, as shown in Figure 8(a), an input image with a size of 1152 × 1152 pixels is divided into nine tiles (each tile has a size of 384 × 384 pixels). Each tile is assigned an ID (tile ID) in raster order from the top left, with the tile ID of the top left tile being 0 and the tile ID of the bottom right tile being 8.

[0023] Furthermore, examples of tile, brick, and slice division in the input image are shown in Figure 8(b). As shown in Figure 8(b), the tile with tile ID=0 and the tile with tile ID=7 are divided into two bricks (each brick having a size of 384×192 pixels). The tile with tile ID=2 is divided into two bricks (the upper brick has a size of 384×128 pixels, and the lower brick has a size of 384×256 pixels). The tile with tile ID=3 is divided into three bricks (each brick having a size of 384×128 pixels). The tiles with tile IDs=1,4,5,6,8 are not divided into bricks (equivalent to dividing one tile into one brick), and as a result, tile=brick. Each brick is assigned an ID from top to bottom in the raster order of the tiles. The BID shown in Figure 8(b) is the brick ID. The input image is also divided into slices 0 to 4. Slice 0 is the slice containing the brick corresponding to BID=0, slice 1 is the slice containing the brick corresponding to BID=1, slice 2 is the slice containing the brick corresponding to BID=2, slice 3 is the slice containing the bricks corresponding to BID=3 to 10, and slice 4 is the slice containing the bricks corresponding to BID=11 to 13. Each slice is also assigned an ID from top to bottom in the raster order of the slices; for example, slice 0 refers to the slice with ID=0, and slice 4 refers to the slice with ID=4.

[0024] The image division unit 102 then outputs size information for each of the divided tiles, bricks, and slices as division information to the integrated encoding unit 111. The image division unit 102 also divides each brick into basic block row images and outputs these divided basic block row images to the block division unit 103.

[0025] The block division unit 103 divides the basic block row image output from the image division unit 102 into multiple basic blocks and outputs the block image (64 x 64 pixels), which is an image of a basic block unit, to the subsequent prediction unit 104.

[0026] The prediction unit 104 divides the image in basic block units into subblocks, determines an intra-prediction mode such as horizontal prediction or vertical prediction for each subblock unit, and generates a predicted image from the determined intra-prediction mode and encoded pixels. Furthermore, the prediction unit 104 calculates a prediction error from the input image and the predicted image, and outputs the calculated prediction error to the conversion / quantization unit 105. The prediction unit 104 also outputs information such as the subblock division method and intra-prediction mode as prediction information to the encoding unit 110 and the image playback unit 107.

[0027] The transformation / quantization unit 105 performs an orthogonal transformation (orthogonal transformation processing corresponding to the size of the subblock) on the prediction error output from the prediction unit 104 in subblock units to obtain transformation coefficients (orthogonal transformation coefficients). The transformation / quantization unit 105 then quantizes the obtained transformation coefficients to obtain quantization coefficients. The transformation / quantization unit 105 then outputs the obtained quantization coefficients to the encoding unit 110 and the inverse quantization / inverse transformation unit 106.

[0028] The inverse quantization / inverse transformation unit 106 inversely quantizes the quantization coefficients output from the transformation / quantization unit 105 to reconstruct the transformation coefficients, and then performs an inverse orthogonal transformation on the reconstructed transformation coefficients to reconstruct the prediction error. The inverse quantization / inverse transformation unit 106 then outputs the reconstructed prediction error to the image reproduction unit 107.

[0029] The image playback unit 107 generates a predicted image by appropriately referring to the frame memory 108 based on the prediction information output from the prediction unit 104, and generates a playback image from the predicted image and the prediction error input from the inverse quantization / inverse transform unit 106. The image playback unit 107 then stores the generated playback image in the frame memory 108.

[0030] The in-loop filter unit 109 reads the playback image from the frame memory 108 and performs in-loop filtering on the read playback image, such as deblocking filtering and sample adaptive offsetting. The in-loop filter unit 109 then stores (restores) the image that has undergone the in-loop filtering back into the frame memory 108.

[0031] The encoding unit 110 generates coded data by entropy coding the quantization coefficients output from the transformation / quantization unit 105 and the predicted information output from the prediction unit 104. The method of entropy coding is not specifically defined, but Golomb coding, arithmetic coding, Huffman coding, etc., can be used. The encoding unit 110 then outputs the generated coded data to the integrated encoding unit 111.

[0032] The integrated encoding unit 111 generates header code data using the division information output from the image division unit 102, and generates and outputs a bitstream by multiplexing the generated header code data with the code data output from the encoding unit 110. The output destination of the bitstream is not limited to a specific destination; it may be output (stored) in the internal or external memory of the image encoding device, or it may be transmitted to an external device that can communicate with the image encoding device via a network such as a LAN or the Internet.

[0033] Next, Figure 6 shows an example of the format of the bitstream output by the integrated encoding unit 111 (coded data encoded by the VVC image encoding device). The bitstream in Figure 6 includes a sequence parameter set (SPS), which is header information containing information related to sequence encoding. The bitstream in Figure 6 also includes a picture parameter set (PPS), which is header information containing information related to picture encoding. The bitstream in Figure 6 also includes a slice header (SLH), which is header information containing information related to slice encoding. The bitstream in Figure 6 also includes coded data for each brick (brick 0 to brick (N-1) in Figure 6).

[0034] SPS contains image size information and basic block data division information. PPS contains tile data division information (tile division information), brick data division information (brick division information), slice data division information 0 (slice division information), and basic block row data synchronization information. SLH contains slice data division information 1 and basic block row data position information.

[0035] First, let's explain SPS. SPS includes information 601, pic_width_in_luma_samples, and information 602, pic_height_in_luma_samples, as image size information. pic_width_in_luma_samples represents the horizontal size (number of pixels) of the input image, and pic_height_in_luma_samples represents the vertical size (number of pixels) of the input image. In this embodiment, since the input image in Figure 8 is used as the input image, pic_width_in_luma_samples = 1152 and pic_height_in_luma_samples = 1152. SPS also includes information 603, log2_ctu_size_minus2, as basic block data division information. log2_ctu_size_minus2 represents the size of the basic block. The number of pixels in the vertical and horizontal directions of the basic block is given by 1 << (log2_ctu_size_minus2 + 2). In this embodiment, the size of the basic block is 64 x 64 pixels, so the value of log2_ctu_size_minus2 is 4.

[0036] Next, let's explain PPS. PPS includes information 604-607 as tile data division information. Information 604 is single_tile_in_pic_flag, which indicates whether the input image is divided into multiple tiles and encoded. If single_tile_in_pic_flag=1, it indicates that the input image is not divided into multiple tiles and encoded. On the other hand, if single_tile_in_pic_flag=0, it indicates that the input image is divided into multiple tiles and encoded.

[0037] Information 605 is included in the tile data partitioning information when single_tile_in_pic_flag=0. Information 605 is uniform_tile_spacing_flag, which indicates whether each tile has the same size or not. If uniform_tile_spacing_flag=1, it indicates that each tile has the same size, and if uniform_tile_spacing_flag=0, it indicates that there are tiles with different sizes.

[0038] Information 606 and 607 are included in the tile data partitioning information when uniform_tile_spacing_flag=1. Information 606 is tile_cols_width_minus1, which represents (the number of basic horizontal blocks of the tile - 1). Information 607 is tile_rows_height_minus1, which represents (the number of basic vertical blocks of the tile - 1). The number of tiles in the horizontal direction of the input image is obtained as the quotient when the number of basic horizontal blocks of the input image is divided by the number of basic horizontal blocks of the tile. If a remainder occurs as a result of this division, the number obtained by adding 1 to the quotient is considered the "number of tiles in the horizontal direction of the input image". Similarly, the number of tiles in the vertical direction of the input image is obtained as the quotient when the number of basic vertical blocks of the input image is divided by the number of basic vertical blocks of the tile. If a remainder occurs as a result of this division, the number obtained by adding 1 to the quotient is considered the "number of tiles in the vertical direction of the input image". The total number of tiles in the input image can be calculated by multiplying the number of horizontal tiles in the input image by the number of vertical tiles in the input image.

[0039] Note that if uniform_tile_spacing_flag=0, it means that there are tiles of different sizes from the others, so the number of tiles in the horizontal direction of the input image, the number of tiles in the vertical direction of the input image, and the width and height of each tile are used as the sign.

[0040] PPS also includes information 608-613 as brick data splitting information. Information 608 is brick_splitting_present_flag. If brick_splitting_present_flag=1, it indicates that one or more tiles in the input image are split into multiple bricks. On the other hand, if brick_splitting_present_flag=0, it indicates that each tile in the input image is composed of a single brick.

[0041] Information 609 is included in the brick data splitting information when brick_splitting_present_flag=1. Information 609 is brick_split_flag[] for each tile, indicating whether or not the tile is split into multiple bricks. The brick_split_flag[] indicating whether the i-th tile is split into multiple bricks is denoted as brick_split_flag[i]. If brick_split_flag[i]=1, it indicates that the i-th tile is split into multiple bricks, and if brick_split_flag[i]=0, it indicates that the i-th tile is made up of a single brick.

[0042] Information 610 is uniform_brick_spacing_flag[i], which indicates whether the sizes of the bricks constituting the i-th tile are the same when brick_split_flag[i]=1. If brick_split_flag[i]=0 for all i, then information 610 is not included in the brick data splitting information. Information 610 includes uniform_brick_spacing_flag[i] for i that satisfy brick_split_flag[i]=1. If uniform_brick_spacing_flag[i]=1, it indicates that the sizes of the bricks constituting the i-th tile are the same. On the other hand, if uniform_brick_spacing_flag[i]=0, it indicates that there is a brick among the bricks constituting the i-th tile that is of a different size from the others.

[0043] Information 611 is included in the brick data partitioning information when uniform_brick_spacing_flag[i]=1. Information 611 is brick_height_minus1[i], which indicates (the number of base blocks in the vertical direction of the brick in the i-th tile - 1).

[0044] The number of basic blocks in the vertical direction of a brick can be determined by dividing the number of pixels in the vertical direction of the brick by the number of pixels in the vertical direction of the basic block (64 pixels in this embodiment). The number of bricks that make up a tile is obtained as the quotient when the number of basic blocks in the vertical direction of the tile is divided by the number of basic blocks in the vertical direction of the brick. If a remainder occurs as a result of this division, the number obtained by adding 1 to the quotient is taken as the "number of bricks that make up the tile". For example, suppose the number of basic blocks in the vertical direction of the tile is 10 and the value of brick_height_minus1 is 2. In this case, the tile will be divided into four bricks from top to bottom: a brick with 3 basic block rows, a brick with 3 basic block rows, a brick with 3 basic block rows, and a brick with 1 basic block row.

[0045] Information 612 is num_brick_rows_minus1[i], which represents (the number of bricks making up the i-th tile - 1) for i satisfying uniform_brick_spacing_flag[i]=0.

[0046] In this embodiment, when uniform_brick_spacing_flag[i]=0, num_brick_rows_minus1[i], which represents (the number of bricks constituting the i-th tile - 1), is included in the brick data partitioning information. However, this is not the only way to do so.

[0047] For example, when brick_split_flag[i]=1, we assume that the number of bricks constituting the i-th tile is 2 or greater. Then, we may encode num_brick_rows_minus2[i], which represents (number of bricks constituting the tile - 2), instead of num_brick_rows_minus1[i]. In this way, the number of bits in the syntax indicating the number of bricks constituting the tile can be reduced. For example, if the tile is composed of 2 bricks and num_brick_rows_minus1[i] is Golomm encoded, 3 bits of data, "010", representing "1", are encoded. On the other hand, if num_brick_rows_minus2[i], which represents (number of bricks constituting the tile - 2), is Golomm encoded, 1 bit of data, "0", representing 0, is encoded.

[0048] Information 613 is brick_row_height_minus1[i][j], which represents (the number of basic vertical blocks of the j-th brick in the i-th tile minus 1) for i satisfying uniform_brick_spacing_flag[i]=0. brick_row_height_minus1[i][j] is encoded as many times as num_brick_rows_minus1[i]. If the above-mentioned num_brick_rows_minus2[i] is used, brick_row_height_minus1[i][j] is encoded as many times as num_brick_rows_minus2[i]+1. The number of basic vertical blocks of the bottom brick in a tile can be found by subtracting the sum of "brick_row_height_minus1+1" from the number of basic vertical blocks in that tile. For example, suppose the number of basic vertical blocks in a tile is 10, num_brick_rows_minus1 is 3, and brick_row_height_minus1 is 2, 1, and 2. In this case, the number of basic vertical blocks in the bottom brick of that tile will be 10 - (3 + 2 + 3) = 2.

[0049] PPS also includes information 614-618 as slice data partitioning information 0. Information 614 is single_brick_per_slice_flag. If single_brick_per_slice_flag=1, it indicates that all slices in the input image are composed of a single brick. In other words, it indicates that each slice is composed of only one brick. On the other hand, if single_brick_per_slice_flag=0, it indicates that one or more slices in the input image are composed of multiple bricks.

[0050] Information 615 is rect_slice_flag, which is included in slice data partitioning information 0 when single_brick_per_slice_flag=0. rect_slice_flag indicates whether the tiles contained in the slice are raster-order or rectangular. Figure 9(a) shows the relationship between tiles and slices when rect_slice_flag=0, indicating that the tiles within the slice are encoded in raster order. On the other hand, Figure 9(b) shows the relationship between tiles and slices when rect_slice_flag=1, indicating that multiple tiles within the slice are rectangular.

[0051] Information 616 is num_slices_in_pic_minus1, which is included in slice data partitioning information 0 when rect_slice_flag=1 and single_brick_per_slice_flag=0. num_slices_in_pic_minus1 represents (number of slices in the input image - 1).

[0052] Information 617 is top_left_brick_idx[i], which indicates the index of the top-left brick of each slice (the i-th slice) in the input image.

[0053] Information 618 is bottom_right_brick_idx_delta[i], which represents the difference between the index of the top-left brick and the index of the bottom-right brick in the i-th slice of the input image. Here, "the top-left brick in the i-th slice of the input image" is the brick that is processed first in that slice. Also, "the bottom-right brick in the i-th slice of the input image" is the brick that is processed last in that slice. However, since the index of the top-left brick in the first slice in the frame is fixed at 0, top_left_brick_idx[0] of the first slice is not encoded.

[0054] Furthermore, PPS includes information 619 encoded as basic block row data synchronization information. Information 619 is entropy_coding_sync_enabled_flag. When entropy_coding_sync_enabled_flag=1, the table of occurrence probabilities at the time of processing the basic block at a predetermined position in the basic block row adjacent to it is applied to the leftmost block. This enables parallel processing of entropy coding and decoding on a basic block row basis.

[0055] Next, we will explain SLH. SLH contains encoded information 620-621 as slice data division information 1. Information 620 is slice_address, which is included in slice data division information 1 when rect_slice_flag=1 or the number of bricks in the input image is 2 or more. When rect_slice_flag=0, slice_address indicates the BID of the first slice, and when rect_slice_flag=1, it indicates the number of the current slice.

[0056] Information 621 is num_bricks_in_slice_minus1, which is included in slice data partitioning information 1 when rect_slice_flag=0 and single_brick_per_slice_flag=0. num_bricks_in_slice_minus1 represents (number of bricks in the slice - 1).

[0057] SLH contains information 622 as basic block row data position information. Information 622 is entry_point_offset_minus1[]. When entropy_coding_sync_enabled_flag=1, entry_point_offset_minus1[] is encoded and included in the basic block row data position information a number of times equal to (number of basic block rows in the slice - 1).

[0058] `entry_point_offset_minus1[]` represents the entry point of the coded data for a basic block row, i.e., the starting position of the coded data for that basic block row. `entry_point_offset_minus1[j-1]` indicates the entry point of the coded data for the j-th basic block row. The starting position of the coded data for the 0th basic block row is omitted because it is the same as the starting position of the coded data for the slice to which that basic block row belongs. Then, {the size of the coded data for the (j-1)th basic block row - 1} is encoded as `entry_point_offset_minus1[j-1]`.

[0059] Next, the encoding process of the input image by the image encoding device in this embodiment (the generation process of a bitstream having the configuration shown in Figure 6) will be explained according to the flowchart in Figure 3.

[0060] First, in step S301, the image splitting unit 102 splits the input image into tiles, bricks, and slices. The image splitting unit 102 then outputs information about the size of each of the split tiles, bricks, and slices as splitting information to the integrated encoding unit 111. The image splitting unit 102 also splits each brick into basic block row images and outputs these divided basic block row images to the block splitting unit 103.

[0061] In step S302, the block division unit 103 divides the basic block row image into multiple basic blocks and outputs the block images, which are images of each basic block, to the subsequent prediction unit 104.

[0062] In step S303, the prediction unit 104 divides the image in basic block units output from the block division unit 103 into subblocks, determines an intra-prediction mode for each subblock, and generates a predicted image from the determined intra-prediction mode and encoded pixels. Furthermore, the prediction unit 104 calculates a prediction error from the input image and the predicted image, and outputs the calculated prediction error to the conversion / quantization unit 105. The prediction unit 104 also outputs information such as the sub-block division method and intra-prediction mode as prediction information to the encoding unit 110 and the image playback unit 107.

[0063] In step S304, the transformation / quantization unit 105 orthogonally transforms the prediction error output from the prediction unit 104 in subblock units to obtain transformation coefficients (orthogonal transformation coefficients). The transformation / quantization unit 105 then quantizes the obtained transformation coefficients to obtain quantization coefficients. The transformation / quantization unit 105 then outputs the obtained quantization coefficients to the encoding unit 110 and the inverse quantization / inverse transformation unit 106.

[0064] In step S305, the inverse quantization / inverse transformation unit 106 inversely quantizes the quantization coefficients output from the transformation / quantization unit 105 to reconstruct the transformation coefficients, and then performs an inverse orthogonal transformation on the reconstructed transformation coefficients to reconstruct the prediction error. The inverse quantization / inverse transformation unit 106 then outputs the reconstructed prediction error to the image reproduction unit 107.

[0065] In step S306, the image playback unit 107 generates a predicted image by appropriately referring to the frame memory 108 based on the prediction information output from the prediction unit 104, and generates a playback image from the predicted image and the prediction error input from the inverse quantization / inverse transform unit 106. The image playback unit 107 then stores the generated playback image in the frame memory 108.

[0066] In step S307, the encoding unit 110 generates coded data by entropy encoding the quantization coefficients output from the transformation / quantization unit 105 and the predicted information output from the prediction unit 104.

[0067] Here, if entropy_coding_sync_enabled_flag=1, the probability table obtained when processing the basic block at a predetermined position in the adjacent basic block row above is applied before processing the basic block at the leftmost position of the next basic block row. In this embodiment, we will explain assuming that entropy_coding_sync_enabled_flag=1.

[0068] In step S308, the control unit 199 determines whether the encoding of all basic blocks in the slice has been completed. If the result of this determination is that the encoding of all basic blocks in the slice has been completed, the process proceeds to step S309. On the other hand, if there are still basic blocks in the slice that have not been encoded (unencoded basic blocks), the process proceeds to step S303 in order to encode the unencoded basic blocks.

[0069] In step S309, the integrated encoding unit 111 generates header code data using the division information output from the image division unit 102, and generates and outputs a bitstream containing the generated header code data and the code data output from the encoding unit 110.

[0070] When the input image is divided as shown in Figure 8, the tile data division information will have single_tile_in_pic_flag set to 0 and uniform_tile_spacing_flag set to 1. Also, tile_cols_width_minus1 will be 5 and tile_rows_height_minus1 will be 5.

[0071] The brick_splitting_present_flag for brick data splitting information is 1. Also, the tiles corresponding to tile IDs 1, 4, 5, 6, and 8 are not split into bricks. Therefore, brick_split_flag[1], brick_split_flag[4], brick_split_flag[5], brick_split_flag[6], and brick_split_flag[8] are 0. Also, the tiles corresponding to tile IDs 0, 2, 3, and 7 are split into bricks. Therefore, brick_split_flag[0], brick_split_flag[2], brick_split_flag[3], and brick_split_flag[7] are 1.

[0072] Furthermore, the tiles corresponding to tile IDs 0, 3, and 7 are all divided into bricks of the same size. Therefore, uniform_brick_spacing_flag[0], uniform_brick_spacing_flag[3], and uniform_brick_spacing_flag[7] are all 1. For the tile corresponding to tile ID 2, the size of the brick for BID=3 is different from the size of the brick for BID=4. Therefore, uniform_brick_spacing_flag[2] is 0.

[0073] brick_height_minus1[0] is 2, and brick_height_minus1[3] is 1. Also, brick_height_minus1[7] is 2. Note that brick_height_minus1 is encoded when uniform_brick_spacing is 1.

[0074] brick_row_height_minus1[2][0] is 1. Note that if we encode the syntax of num_brick_rows_minus2[2] instead of num_brick_rows_minus1[2], the value will be 0.

[0075] Furthermore, in this embodiment, since one slice contains multiple bricks, single_brick_per_slice_flag in slice data partitioning information 0 is 0. Also, in this embodiment, since a slice contains multiple tiles in raster order (a slice contains tiles arranged in raster order), rect_slice_flag is 0.

[0076] In this case, as slice data partitioning information in SLH, the first BID in the slice (the smallest BID among the BIDs of the bricks in that slice) is first encoded as slice_address.

[0077] For slice 0, the BID of the first brick in slice 0, "0", is encoded as slice_address. For slice 1, the BID of the first brick in slice 1, "1", is encoded as slice_address. For slice 2, the BID of the first brick in slice 2, "2", is encoded as slice_address. For slice 3, the BID of the first brick in slice 3, "3", is encoded as slice_address. For slice 4, the BID of the first brick in slice 4, "11", is encoded as slice_address.

[0078] Then, the number of bricks contained in each slice is encoded as num_bricks_in_slice_minus1. Since slice 0 contains only the brick corresponding to BID=0 (only a single brick), num_bricks_in_slice_minus1 for slice 0 is 0. Since slice 1 contains only the brick corresponding to BID=1 (only a single brick), num_bricks_in_slice_minus1 for slice 1 is 0. Since slice 2 contains only the brick corresponding to BID=2 (only a single brick), num_bricks_in_slice_minus1 for slice 2 is 0. Since slice 3 contains bricks corresponding to BID=3 to 10 (8 bricks), num_bricks_in_slice_minus1 for slice 3 is 7. Since the bricks included in slice 4 are the bricks corresponding to BID=11~13 (3 bricks), num_bricks_in_slice_minus1 corresponding to slice 4 is 2.

[0079] Next, the basic block row data position information is encoded as entry_point_offset_minus1[j-1], which is the value of (size of the coded data of the (j-1)th basic block row in the slice - 1) sent from the encoding unit 110. The number of entry_point_offset_minus1 in the slice is equal to (number of basic block rows in the slice - 1).

[0080] Slice 0 consists of a single brick (corresponding num_bricks_in_slice_minus1=0), and brick_height_minus1[0]=2. Therefore, the number of basic block rows in this brick is brick_height_minus1[0]+1=3 (where j ranges from 0 to 1).

[0081] Slice 1 consists of a single brick (corresponding num_bricks_in_slice_minus1=0), brick_height_minus1[0]=2, and tile_rows_height_minus1=5. Therefore, the number of basic block rows in this brick is tile_rows_height_minus1-brick_height_minus1[0]=3 (where j ranges from 0 to 1).

[0082] Slice 2 consists of a single brick (corresponding num_bricks_in_slice_minus1=0) and brick_height_minus1[1]=5. Therefore, the number of basic block rows in this brick is brick_height_minus1[1]+1=6 (where j ranges from 0 to 4).

[0083] In the case of slice 3, the corresponding slice_address is 3 and the corresponding num_bricks_in_slice_minus1 is 7. Therefore, slice 3 consists of bricks (8 bricks) corresponding to BID=3 to 10 (=slice_address + num_bricks_in_slice_minus1). The number of basic block rows in slice 3 is the sum of the number of basic block rows of the bricks corresponding to each of BID=3 to 10.

[0084] The number of basic block rows for a brick corresponding to BID=3 is brick_row_height_minus1[2][0]+1=2, since brick_row_height_minus1[2][0]=1.

[0085] The number of basic block rows in a brick corresponding to BID=4 can be derived as follows: brick_row_height_minus1[2][0]=1, num_brick_rows_minus1[2]=1, and tile_rows_height_minus1=5. Therefore, the number of basic block rows in a brick corresponding to BID=4 is tile_rows_height_minus1-brick_row_height_minus1[2][0]=4.

[0086] Since brick_height_minus1[3]=1, the number of basic block rows for each of the BIDs from 5 to 7 can be seen as brick_height_minus1[3]+1=2.

[0087] Since tile_rows_height_minus1 = 5, the number of basic block rows for each of the BIDs from 8 to 10 can be seen as tile_rows_height_minus1 + 1 = 6.

[0088] Therefore, the number of basic block rows in slice 3 can be derived as the sum of the number of basic block rows in bricks corresponding to BID=3 to 10 (2+4+2+2+2+6+6+6) = 30. The range of j is 0 to 28.

[0089] In the case of slice 4, the corresponding slice_address is 11 and the corresponding num_bricks_in_slice_minus1 is 2. Therefore, slice 4 consists of bricks (3 bricks) corresponding to BID=11~13 (=slice_address + num_bricks_in_slice_minus1). The number of basic block rows in slice 4 is the sum of the number of basic block rows of the bricks corresponding to each of BID=11~13.

[0090] Since brick_height_minus1[7]=2, the number of basic block rows for each of the BID=11 to 12 bricks can be seen as brick_height_minus1[7]+1=3.

[0091] The number of basic block rows in a brick corresponding to BID=13 is tile_rows_height_minus1+1=6, since tile_rows_height_minus1=5.

[0092] Therefore, the number of basic block rows in slice 4 can be derived as the sum of the number of basic block rows in bricks corresponding to BID=11 to 13 (3+3+6) = 12. The range of j is 0 to 10.

[0093] This process determines the number of basic block rows in each slice. In this embodiment, the number of entry_point_offset_minus1 can be derived from other syntax, so it is not necessary to encode num_entry_point_offset and include it in the header as in the conventional method. Therefore, according to this embodiment, the amount of data in the bitstream can be reduced.

[0094] In step S310, the control unit 199 determines whether the encoding of all basic blocks in the input image has been completed. If the result of this determination is that the encoding of all basic blocks in the input image has been completed, the process proceeds to step S311. On the other hand, if there are still basic blocks in the input image that have not yet been encoded, the process proceeds to step S303, and the subsequent processing is performed on the basic blocks that have not yet been encoded.

[0095] In step S311, the in-loop filter unit 109 performs in-loop filtering on the regenerated image generated in step S306 and outputs the image after the in-loop filtering has been applied.

[0096] Thus, according to this embodiment, it is not necessary to encode and include in the bitstream information indicating how many pieces of information indicating the starting position of the coded data of the basic block row of the brick are encoded, and it is possible to generate a bitstream from which such information can be derived.

[0097] [Second Embodiment] This embodiment describes an image decoding device that decodes a bitstream generated by the image encoding device according to the first embodiment. Note that requirements common to the first embodiment, such as the bitstream configuration, are as described in the first embodiment and will therefore not be explained here.

[0098] An example of the functional configuration of the image decoding device according to this embodiment will be explained using the block diagram in Figure 2. The separation and decoding unit 202 acquires the bitstream generated by the image encoding device according to the first embodiment. The method of acquiring the bitstream is not limited to a specific method. For example, the bitstream may be acquired directly or indirectly from the image encoding device via a network such as a LAN or the Internet, or the bitstream stored inside or outside the image decoding device may be acquired. The separation and decoding unit 202 then separates the coded data related to the decoding process and coefficients from the acquired bitstream and sends it to the decoding unit 203. The separation and decoding unit 202 also decodes the coded data of the bitstream header. In this embodiment, the header information related to the division of the image, such as the size of tiles, bricks, slices, and basic blocks, is decoded to generate division information, and the generated division information is output to the image playback unit 205. In other words, the separation and decoding unit 202 operates in the reverse order of the integrated encoding unit 111 in Figure 1.

[0099] The decoding unit 203 decodes the coded data output from the separation decoding unit 202 to reconstruct the quantization coefficients and prediction information. The inverse quantization / inverse transform unit 204 performs inverse quantization on the quantization coefficients to generate transform coefficients, and then performs an inverse orthogonal transform on the generated transform coefficients to reconstruct the prediction error.

[0100] Frame memory 206 is a memory for storing image data of the reproduced picture. The image playback unit 205 generates a predicted image by appropriately referring to frame memory 206 based on the input prediction information. The image playback unit 205 then generates a reproduced image from the generated predicted image and the prediction error reproduced by the inverse quantization / inverse transform unit 204. The image playback unit 205 then identifies and outputs the positions of tiles, bricks, and slices in the input image based on the division information input from the separation / decoding unit 202 for the reproduced image.

[0101] The in-loop filter unit 207, like the in-loop filter unit 109 described above, performs in-loop filtering, such as deblocking filtering, on the regenerated image and outputs an image that has undergone in-loop filtering. The control unit 299 controls the operation of the entire image decoding device and controls the operation of each functional part of the image decoding device described above.

[0102] Next, the bitstream decoding process using an image decoding device having the configuration shown in Figure 2 will be described. In the following description, the bitstream will be input to the image decoding device on a frame-by-frame basis, but it is also possible to input a bitstream of a single frame of still images to the image decoding device. Furthermore, in this embodiment, only intra-predictive decoding will be described for the sake of simplicity, but it is not limited to this and can also be applied to inter-predictive decoding.

[0103] The separation / decoding unit 202 separates coded data related to the decoding process and coefficients from the input bitstream and sends it to the decoding unit 203. The separation / decoding unit 202 also decodes the coded data of the bitstream header. More specifically, the separation / decoding unit 202 decodes the basic block data division information, tile data division information, brick data division information, slice data division information 0, basic block row data synchronization information, basic block row data position information, etc., as shown in Figure 6, to generate division information. The separation / decoding unit 202 then outputs the generated division information to the image playback unit 205. The separation / decoding unit 202 also plays back the coded data of the basic block units of the picture data and outputs it to the decoding unit 203.

[0104] The decoding unit 203 decodes the coded data output from the separation decoding unit 202 to reconstruct the quantization coefficients and prediction information. The reconstructed quantization coefficients are output to the inverse quantization / inverse transform unit 204, and the reconstructed prediction information is output to the image reconstruction unit 205.

[0105] The inverse quantization / inverse transformation unit 204 performs inverse quantization on the input quantization coefficients to generate transformation coefficients, and then performs an inverse orthogonal transformation on the generated transformation coefficients to reconstruct the prediction error. The reconstructed prediction error is output to the image reconstruction unit 205.

[0106] The image playback unit 205 generates a predicted image by appropriately referencing the frame memory 206 based on the prediction information input from the separation and decoding unit 202. The image playback unit 205 then generates a reconstructed image from the generated predicted image and the prediction error reconstructed by the inverse quantization and inverse transform unit 204. The image playback unit 205 then identifies the shape of the reconstructed image, such as a tile, brick, or slice as shown in Figure 7, and its position in the input image, based on the division information input from the separation and decoding unit 202, and outputs (stores) it in the frame memory 206. The image stored in the frame memory 206 is used as a reference during prediction.

[0107] The in-loop filter unit 207 performs in-loop filtering, such as deblocking filtering, on the playback image read from the frame memory 206, and outputs (stores) the in-loop filtered image back into the frame memory 206.

[0108] The control unit 299 outputs the reconstructed image stored in the frame memory 206. The output destination of the reconstructed image is not limited to a specific destination. For example, the control unit 299 may output the reconstructed image to a display device of the image decoding device and have the display device display the reconstructed image. Alternatively, the control unit 299 may transmit the reconstructed image to an external device via a network such as a LAN or the Internet.

[0109] Next, the bitstream decoding process by the image decoding device according to this embodiment (bitstream decoding process having the configuration shown in Figure 6) will be explained according to the flowchart in Figure 4.

[0110] In step S401, the separation / decoding unit 202 separates coded data related to the decoding process and coefficients from the input bitstream and sends it to the decoding unit 203. The separation / decoding unit 202 also decodes the coded data of the bitstream header. More specifically, the separation / decoding unit 202 decodes the basic block data division information, tile data division information, brick data division information, slice data division information, basic block row data synchronization information, basic block row data position information, etc., as shown in Figure 6, to generate division information. The separation / decoding unit 202 then outputs the generated division information to the image playback unit 205. The separation / decoding unit 202 also plays back the coded data of the basic block units of the picture data and outputs it to the decoding unit 203.

[0111] In this embodiment, the input image, which is the source of the bitstream encoding, is divided as shown in Figure 8. Information related to the input image, which is the source of the bitstream encoding, and its division can be derived from the division information.

[0112] From pic_width_in_luma_samples included in the image size information, it can be determined that the horizontal size (width) of the input image is 1152 pixels. Also, from pic_height_in_luma_samples included in the image size information, it can be determined that the vertical size (height) of the input image is 1152 pixels.

[0113] Also, since log2_ctu_size_minus2 = 4 in the basic block data division information, the size of the basic block can be derived as 64×64 pixels from 1<<log2_ctu_size_minus2+2.

[0114] Also, since single_tile_in_pic_flag = 0 in the tile data division information, it can be determined that the input image is divided into multiple tiles. And since uniform_tile_spacing_flag = 1, it can be determined that each tile has the same size (excluding the edges).

[0115] Also, since tile_cols_width_minus1 = 5 and tile_rows_height_minus1 = 5, it can be determined that each tile is composed of 6×6 basic blocks. That is, it can be determined that each tile is composed of 384×384 pixels. Since the input image is 1152×1152 pixels, it can be seen that the input image is divided into and encoded into 9 tiles, 3 horizontally and 3 vertically.

[0116] Also, since brick_splitting_present_flag = 1 in the brick data division information, it can be determined that at least one tile in the input image is divided into multiple bricks.

[0117] Furthermore, brick_split_flag[1], brick_split_flag[4], brick_split_flag[5], brick_split_flag[6], and brick_split_flag[8] are all 0. This allows us to identify that the tiles corresponding to tile IDs 1, 4, 5, 6, and 8 are not divided into bricks. In this embodiment, since the number of basic block rows for all tiles is 6, we can see that the number of basic block rows for the bricks of the tiles corresponding to tile IDs 1, 4, 5, 6, and 8 is also 6.

[0118] On the other hand, brick_split_flag[0], brick_split_flag[2], brick_split_flag[3], and brick_split_flag[7] are all 1. This allows us to determine that the tiles corresponding to tile IDs 0, 2, 3, and 7 are divided into bricks. Also, uniform_brick_spacing_flag[0], uniform_brick_spacing_flag[3], and uniform_brick_spacing_flag[7] are all 1. This allows us to determine that the tiles corresponding to tile IDs 0, 3, and 7 are all divided into bricks of the same size.

[0119] Furthermore, both brick_height_minus1[0] and brick_height_minus1[7] are 2. Thus, it can be determined that the number of basic vertical blocks of bricks within each tile, whether it is the tile corresponding to tile ID=0 or the tile corresponding to tile ID=7, is 3. Furthermore, it can be determined that the number of bricks within each tile, whether it is the tile corresponding to tile ID=0 or the tile corresponding to tile ID=7, is 2 (= basic block row of the tile (6) / basic vertical blocks of bricks within the tile (3)).

[0120] Furthermore, brick_height_minus1[3] is 1. Thus, it can be determined that the number of basic vertical blocks of bricks within the tile corresponding to tile ID=3 is 2. It can also be determined that the number of bricks within the tile corresponding to tile ID=3 is 3 (= number of basic block rows of the tile (6) / number of basic vertical blocks of bricks within the tile (2)).

[0121] For the tile corresponding to tile ID=2, num_brick_rows_minus1[2]=1 indicates that the tile is composed of two bricks. Also, uniform_brick_spacing_flag[2]=0. This indicates that the tile corresponding to tile ID=2 contains bricks of a different size from the others. Furthermore, brick_row_height_minus1[2][0]=1, brick_row_height_minus1[2][1]=3, and the number of base vertical blocks for all tiles is 6. This indicates that the tile corresponding to tile ID=2 is composed of, from top to bottom, a brick with a base vertical block count of 2, and a brick with a base vertical block count of 4. Note that brick_row_height_minus1[2][1]=3 may be left unencoded. If there are two bricks in a tile, it is possible to determine the height of the second brick from the height of the tile and the height of the first brick in the tile (brick_row_height_minus1[2][0]=1).

[0122] Furthermore, since single_brick_per_slice_flag=0 in slice data partitioning information 0, it can be determined that at least one slice is composed of multiple bricks. In this embodiment, when uniform_brick_spacing_flag[i]=0, num_brick_rows_minus1[i], which indicates (the number of bricks constituting the i-th tile - 1), is included in the brick data partitioning information. However, it is not limited to this.

[0123] For example, when brick_split_flag[i]=1, we assume that the number of bricks constituting the i-th tile is 2 or greater. Then, we can decode num_brick_rows_minus2[i], which represents (number of bricks constituting the tile - 2), instead of num_brick_rows_minus1[i]. In this way, we can decode a bitstream with a reduced number of bits in the syntax indicating the number of bricks constituting the tile.

[0124] Next, we determine the coordinates of the top-left and bottom-right boundaries of each brick. The coordinates are expressed using the top-left corner of the input image as the origin, and the horizontal and vertical positions of the basic block. For example, the coordinates of the top-left boundary of the third basic block from the left and the second from the top are (3,2), and the coordinates of the bottom-right boundary are (4,3).

[0125] The coordinates of the top-left boundary of the BID=0 brick within the tile corresponding to tile ID=0 are (0,0). The number of basic block rows for a BID=0 brick is 3, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (3,3).

[0126] The coordinates of the top-left boundary of the BID=1 brick within the tile corresponding to tile ID=0 are (0,3). The number of basic block rows for a BID=1 brick is 3, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (6,6).

[0127] The coordinates of the top-left boundary of the tile corresponding to tile ID=1 (the brick with BID=2) are (6,0). The number of basic block rows for the brick with BID=2 is 6, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (12,6).

[0128] The coordinates of the top-left boundary of the brick with BID=3 within the tile corresponding to tile ID=2 are (12,0). Since the number of basic block rows for a brick with BID=3 is 2, the coordinates of the bottom-right boundary are (18,2).

[0129] The coordinates of the top-left boundary of the brick with BID=4 within the tile corresponding to tile ID=2 are (12,2). Since the number of basic block rows for a brick with BID=4 is 4, the coordinates of the bottom-right boundary are (18,6).

[0130] The coordinates of the top-left boundary of the brick with BID=5 within the tile corresponding to tile ID=3 are (0,6). Since the number of basic block rows for the brick with BID=5 is 2, the coordinates of the bottom-right boundary are (6,8).

[0131] The coordinates of the top-left boundary of the brick with BID=6 within the tile corresponding to tile ID=3 are (0,8). Since the number of basic block rows for the brick with BID=6 is 2, the coordinates of the bottom-right boundary are (6,10).

[0132] The coordinates of the top-left boundary of the brick with BID=7 within the tile corresponding to tile ID=3 are (0,10). Since the number of basic block rows for the brick with BID=7 is 2, the coordinates of the bottom-right boundary are (6,12).

[0133] The coordinates of the top-left boundary of the tile corresponding to tile ID=4 (the brick with BID=8) are (6,6). The number of basic block rows for the brick with BID=8 is 6, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (12,12).

[0134] The coordinates of the top-left boundary of the tile corresponding to tile ID=5 (the brick with BID=9) are (12,6). The number of basic block rows for the brick with BID=9 is 6, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (18,12).

[0135] The coordinates of the top-left boundary of the tile corresponding to tile ID=6 (a brick with BID=10) are (0,12). The number of basic block rows for a brick with BID=10 is 6, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (6,18).

[0136] The coordinates of the top-left boundary of the brick with BID=11 within the tile corresponding to tile ID=7 are (6,12). The number of basic block rows for the brick with BID=11 is 3, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (12,15).

[0137] The coordinates of the top-left boundary of the brick with BID=12 within the tile corresponding to tile ID=7 are (6,15). The number of basic block rows for the brick with BID=12 is 3, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (12,18).

[0138] The coordinates of the top-left boundary of the tile corresponding to tile ID=8 (the brick with BID=13) are (12,12). The number of basic block rows for the brick with BID=13 is 6, and the number of basic horizontal blocks for all tiles is 6, so the coordinates of the bottom-right boundary are (18,18).

[0139] Next, we identify the bricks contained in each slice. For slice 0, since slice_address is 0 and num_bricks_in_slice_minus1 is 0, we can see that slice 0 consists only of bricks with BID=0.

[0140] For slice 1, slice_address is 1 and num_bricks_in_slice_minus1 is 0, so we can see that slice 1 consists only of bricks with BID=1.

[0141] For slice 2, since slice_address is 2 and num_bricks_in_slice_minus1 is 0, we can see that slice 2 consists only of bricks with BID=2.

[0142] For slice 3, slice_address is 3 and num_bricks_in_slice_minus1 is 7. Therefore, it can be seen that slice 3 is composed of bricks with BID=3~10 (=slice_address+num_bricks_in_slice_minus1).

[0143] For slice 4, slice_address is 11 and num_bricks_in_slice_minus1 is 2. Therefore, it can be seen that slice 4 is composed of bricks with BID=11~13 (=slice_address+num_bricks_in_slice_minus1).

[0144] Furthermore, entropy_coding_sync_enabled_flag is 1. Therefore, it can be seen that (the size of the coded data of the (j-1)th basic block row in the slice - 1) is encoded as entry_point_offset_minus1[j-1]. The number of such entries is (the number of basic block rows in the slice being processed - 1).

[0145] For slice 0, the number of basic block rows of the BID=0 bricks that make up slice 0 is 3, so 3-1=2, and the range of j is 0 to 1. For slice 1, the number of basic block rows of the BID=1 bricks that make up slice 1 is 3, so 3-1=2, and the range of j is 0 to 1. For slice 2, the number of basic block rows of the BID=2 bricks that make up slice 2 is 6, so 6-1=5, and the range of j is 0 to 4. For slice 3, the total number of basic block rows of the BID=3 to 10 bricks that make up slice 3 is 2+4+2+2+2+6+6+6=30, so the range of j is 0 to 28.

[0146] For slice 4, the total number of basic block rows for the BID=11~13 bricks that make up slice 4 is 3+3+6=12, so the range of j is 0~10.

[0147] As a result, the number of entry_point_offset_minus1 can be derived from other syntax without encoding num_entry_point_offset as in the conventional method. Since the starting position of the data in each basic block row is known, decoding can be performed in parallel for each basic block row. The segmentation information derived from the separation / decoding unit 202 is sent to the image playback unit 205 and used in step S404 to identify the position of the object to be processed within the input image.

[0148] In step S402, the decoding unit 203 decodes the code data separated by the separation decoding unit 202 to reconstruct the quantization coefficients and prediction information. In step S403, the inverse quantization / inverse transform unit 204 performs inverse quantization on the input quantization coefficients to generate transform coefficients, and then performs an inverse orthogonal transform on the generated transform coefficients to reconstruct the prediction error.

[0149] In step S404, the image playback unit 205 generates a predicted image by appropriately referring to the frame memory 206 based on the prediction information input from the decoding unit 203. The image playback unit 205 then generates a reconstructed image from the generated predicted image and the prediction error reconstructed by the inverse quantization / inverse transform unit 204. The image playback unit 205 then identifies the positions of tiles, bricks, and slices in the input image based on the division information input from the separation / decoding unit 202, synthesizes them at those positions, and outputs (stores) them in the frame memory 206.

[0150] In step S405, the control unit 299 determines whether all basic blocks of the input image have been decoded. If, as a result of this determination, all basic blocks of the input image have been decoded, the process proceeds to step S406. On the other hand, if there are still basic blocks in the input image that have not yet been decoded, the process proceeds to step S402, where the decoded basic blocks are decoded.

[0151] In step S406, the in-loop filter unit 207 performs in-loop filtering on the playback image read from the frame memory 206, and outputs (stores) the in-loop filtered image back into the frame memory 206.

[0152] Thus, according to this embodiment, an input image can be decoded from a bitstream generated by the image encoding device according to the first embodiment, which does not contain information indicating how many pieces of information indicating the starting position of the basic block rows of a brick are encoded.

[0153] The image encoding device according to the first embodiment and the image decoding device according to the second embodiment may be separate devices. Alternatively, the image encoding device according to the first embodiment and the image decoding device according to the second embodiment may be integrated into a single device.

[0154] [Third Embodiment] Each functional unit shown in Figures 1 and 2 may be implemented in hardware, but some may be implemented in software. In the latter case, each functional unit except for frame memory 108 and frame memory 206 may be implemented in software (computer program). A computer device capable of executing such a computer program can be applied to the image encoding device and image decoding device described above.

[0155] An example of a computer device hardware configuration applicable to the above-mentioned image encoding and decoding devices will be explained using the block diagram in Figure 5. Note that the hardware configuration shown in Figure 5 is merely one example of a computer device hardware configuration applicable to the above-mentioned image encoding and decoding devices, and can be modified or altered as appropriate.

[0156] The CPU 501 executes various processes using computer programs and data stored in the RAM 502 and ROM 503. In this way, the CPU 501 controls the operation of the entire computer system and executes or controls the processes described above as being performed by the image encoding and decoding devices. In other words, the CPU 501 can function as one of the functional units shown in Figures 1 and 2 (excluding frame memory 108 and frame memory 206).

[0157] RAM 502 has areas for storing computer programs and data loaded from ROM 503 and external storage device 506, and areas for storing data received from external sources via I / F 507. RAM 502 also has a work area used by CPU 501 when executing various processes. In this way, RAM 502 can provide various areas as needed. ROM 503 stores computer device configuration data and startup programs, etc.

[0158] The operation unit 504 is a user interface such as a keyboard, mouse, or touch panel screen, and allows the user to input various instructions to the CPU 501 through user operation.

[0159] The display unit 505 consists of an LCD screen or a touch panel screen, and can display the processing results from the CPU 501 as images or text. The display unit 505 may also be a device such as a projector that projects images or text.

[0160] The external storage device 506 is a large-capacity information storage device such as a hard disk drive. The external storage device 506 stores the OS (operating system) and computer programs and data that cause the CPU 501 to execute or control the aforementioned processes performed by the image encoding device and image decoding device.

[0161] The computer programs stored in the external storage device 506 include computer programs that cause the CPU 501 to execute or control the functions of each functional unit, excluding frame memory 108 and frame memory 206 in Figures 1 and 2. The data stored in the external storage device 506 also includes the known information described above, as well as various information related to encoding and decoding.

[0162] Computer programs and data stored in the external storage device 506 are loaded into the RAM 502 as appropriate, according to the control of the CPU 501, and become subject to processing by the CPU 501.

[0163] The frame memory 108 in the image encoding device of Figure 1 and the frame memory 206 in the image encoding device of Figure 2 can be implemented using memory devices such as the RAM 502 and the external storage device 506 mentioned above.

[0164] I / F507 is an interface for data communication with external devices. For example, when a computer device is applied to an image encoding device, the image encoding device can output the generated bitstream to the outside via I / F507. Similarly, when a computer device is applied to an image decoding device, the image decoding device can receive the bitstream via I / F507. The image decoding device can also transmit the result of decoding the bitstream to the outside via I / F507. The CPU 501, RAM 502, ROM 503, operation unit 504, display unit 505, external storage device 506, and I / F507 are all connected to the bus 508.

[0165] The specific numerical values ​​used in the above description are for illustrative purposes only and are not intended to limit the embodiments described above to these values. Furthermore, some or all of the embodiments described above may be combined as appropriate. Also, some or all of the embodiments described above may be used selectively.

[0166] (Other embodiments) The present invention can also be realized by supplying a program that implements one or more of the functions of the above-described embodiments to a system or device via a network or storage medium, and by having one or more processors in the computer of that system or device read and execute the program. It can also be realized by a circuit (e.g., an ASIC) that implements one or more functions.

[0167] The invention is not limited to the embodiments described above, and various modifications and variations are possible without departing from the spirit and scope of the invention. Accordingly, claims are attached to disclose the scope of the invention. [Explanation of Symbols]

[0168] 102: Image segmentation unit 103: Block segmentation unit 104: Prediction unit 105: Transformation / quantization unit 106: Inverse quantization / inverse transform unit 107: Image playback unit 108: Frame memory 109: In-loop filter unit 110: Encoding unit 111: Integrated encoding unit

Claims

1. An image decoding device that decodes an image from a bitstream obtained by encoding an image that includes a rectangular region containing one or more block rows consisting of multiple blocks, Decoding means that decodes a first flag relating to the activation of parallel processing, decodes a second flag from the picture parameter set of the bitstream indicating whether a first mode in which the slice is rectangular is used or a second mode in which the slice can have a shape other than a rectangle is used, decodes first information from the picture parameter set corresponding to the number of blocks in the vertical direction of the rectangular region in the image, decodes second information from the slice header of the bitstream indicating the number of rectangular regions included in the slice in the image, and decodes the address of the slice from the slice header when the image includes multiple rectangular regions and the second flag indicates that the second mode is used, When the value of the first flag is 1 and the second flag indicates that the second mode is used, the identification means for the slice determines the number of syntax elements used to determine the starting position of the block row of coded data, based on the address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular region in the image, and the second information the number of rectangular regions included in the slice in the image. Equipped with, The size of each of the multiple blocks forming the block row is determined from third information decoded from the sequence parameter set in the bitstream, and the number of syntax elements identified by the identification means is included in the slice header of the bitstream. Each of the multiple blocks forming the aforementioned block row corresponds to a Coding Tree Unit (CTU). An image decoding device characterized by the following features.

2. The image decoding apparatus according to claim 1, characterized in that the first flag is entropy_coding_sync_enabled_flag.

3. The image decoding device according to claim 1, characterized in that the second flag is rect_slice_flag.

4. The image decoding apparatus according to claim 1, characterized in that the syntax element is entry_point_offset_minus1.

5. The image decoding apparatus according to claim 1, characterized in that the information on the number of syntax elements is not signaled to the bitstream.

6. The image decoding apparatus according to claim 1, characterized in that the size of each of the plurality of blocks is derived by arithmetic left shifting by 1 with a value that is the result of adding a predetermined value to the third information.

7. The image decoding apparatus according to claim 1, characterized in that each of the plurality of blocks forming the block row can be divided into smaller blocks.

8. The image decoding device according to claim 1, characterized in that each of the plurality of blocks may have a size of 64 x 64.

9. The image decoding apparatus according to claim 1, characterized in that a fourth piece of information corresponding to the width of the image is decoded from the bitstream.

10. An image decoding method for decoding an image from a bitstream obtained by encoding an image that includes a rectangular region containing one or more block rows consisting of multiple blocks, A decoding step comprising: decoding a first flag relating to the activation of parallel processing; decoding a second flag from the picture parameter set of the bitstream indicating whether a first mode in which the slice is rectangular is used or a second mode in which the slice can have a shape other than a rectangle is used; decoding first information from the picture parameter set corresponding to the number of blocks in the vertical direction of the rectangular region in the image; decoding second information from the slice header of the bitstream indicating the number of rectangular regions included in the slice in the image; and decoding the address of the slice from the slice header when the image includes multiple rectangular regions and the second flag indicates that the second mode is used. When the value of the first flag is 1 and the second flag indicates that the second mode is used, the identification step of the slice is to identify the number of syntax elements used to identify the starting position of the block row code data, based on the address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular region in the image, and the second information the number of rectangular regions included in the slice in the image. It has, The size of each of the multiple blocks forming the block row is determined from third information decoded from the sequence parameter set in the bitstream, and the number of syntax elements identified by the specific step is included in the slice header of the bitstream. Each of the multiple blocks forming the aforementioned block row corresponds to a Coding Tree Unit (CTU). An image decoding method characterized by the following:

11. An image encoding device for encoding an image that includes a rectangular region containing one or more block rows consisting of multiple blocks, Encoding means for encoding a first flag relating to the activation of parallel processing, encoding a second flag in the picture parameter set of the bitstream indicating whether a first mode in which the slice is rectangular is used or a second mode in which the slice can have a shape other than a rectangle is used, encoding first information corresponding to the number of blocks in the vertical direction of the rectangular region in the image in the picture parameter set, encoding second information of the number of rectangular regions included in the slice in the image in the slice header of the bitstream, and encoding the address of the slice in the slice header when the image includes multiple rectangular regions and the second flag indicates that the second mode is used, When the value of the first flag is 1 and the second flag indicates that the second mode is used, the identification means for the slice determines the number of syntax elements used to determine the starting position of the block row of coded data, based on the address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular region in the image, and the second information the number of rectangular regions included in the slice in the image. Equipped with, Third information for determining the size of each of the multiple blocks forming the block row is encoded in a sequence parameter set in the bitstream, and the number of syntax elements identified by the identification means is included in the slice header of the bitstream. Each of the multiple blocks forming the aforementioned block row corresponds to a Coding Tree Unit (CTU). An image coding device characterized by the following:

12. An image encoding method for encoding an image that includes a rectangular region containing one or more block rows consisting of multiple blocks, Encoding steps include: encoding a first flag related to the activation of parallel processing; encoding a second flag in the picture parameter set of the bitstream indicating whether a first mode in which the slice is rectangular is used or a second mode in which the slice can have a shape other than a rectangle is used; encoding first information corresponding to the number of blocks in the vertical direction of the rectangular region in the image in the picture parameter set; encoding second information indicating the number of rectangular regions included in the slice in the image in the slice header of the bitstream; and encoding the address of the slice in the slice header when the image includes multiple rectangular regions and the second flag indicates that the second mode is used; When the value of the first flag is 1 and the second flag indicates that the second mode is used, the identification step of the slice is to identify the number of syntax elements used to identify the starting position of the block row code data, based on the address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular region in the image, and the second information the number of rectangular regions included in the slice in the image. It has, Third information for determining the size of each of the multiple blocks forming the block row is encoded in a sequence parameter set in the bitstream, and the number of syntax elements identified by the specific step is included in the slice header of the bitstream. Each of the multiple blocks forming the aforementioned block row corresponds to a Coding Tree Unit (CTU). An image encoding method characterized by the following.

13. A computer program for causing a computer to perform the image decoding method described in claim 10.

14. A computer program for causing a computer to perform the image encoding method described in claim 12.

Images