Image decoding device, image decoding method, image encoding device, image encoding method, computer program

Abstract

To provide a technique which decreases a code amount of a bit stream by decreasing redundant syntax.SOLUTION: A value of a first flag is 1, and a second flag which is a flag decoded from a picture parameter set of a bit stream and a flag relating to the mode of the slice indicates that a mode in which a slice is rectangular regarding is used. In a state where a plurality of rectangular regions are included in a horizontal direction or a vertical direction in a slice of a target included in an image, the number of information pieces for identifying a leading position of code data in a bock row is identified for the slice of the target. The code data of the block row is decoded based on at least the identified number of information for identifying the identified leading position and the information for identifying the leading position.SELECTED DRAWING: Figure 1

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. The 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 by 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 encoding method adopted in HEVC. That is, each syntax element is binarized to generate a binary signal. For each syntax element, a generation probability is given in advance as a table (hereinafter referred to as a generation probability table), and the binary signal is arithmetically encoded based on the generation probability table. This generation probability table is used as decoding information for subsequent symbol decoding 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, the decoding means that decodes from the bitstream a first flag relating to the activation of parallel processing, first information used to identify the first rectangular region to be processed among the multiple rectangular regions included in a slice of the image, second information used to identify the last rectangular region to be processed among the multiple rectangular regions, and third information corresponding to the number of blocks in the vertical direction of the rectangular region in the image, and the value of the first flag is 1, and the picture parameters of the bitstream A second flag, which is a flag decoded from a set and is a flag relating to the slice mode, indicates that a mode in which the slice is rectangular is used, and the target slice included in the image includes a plurality of rectangular regions in the horizontal or vertical direction, and the decoding means includes a number of pieces of information for identifying the starting position of the block row code data for the target slice based on the first information, the second information and the third information, wherein the decoding means decodes the block row code data based on at least the number of pieces of information for identifying the starting position identified by the decoding means and the pieces of information for identifying 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 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 terms of basic blocks into sub - blocks, performs intra - prediction which is intra - frame prediction or inter - prediction which is inter - frame prediction for each sub - block, and generates a predicted image. Intra - prediction across blocks (intra - prediction using pixels of blocks in other blocks) and prediction of motion vectors across blocks (prediction of motion vectors using motion vectors of blocks in 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 method, prediction mode, motion vectors, etc., together with the prediction error.

[0016] The transform and quantization unit 105 orthogonally transforms the prediction error for each sub - block 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 the transform coefficients, and further inverse - orthogonally transforms the reproduced transform coefficients to reproduce the 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 de - blocking filter and sample - adaptive offset on the reproduced image, and outputs the image (filtered image) subjected to the in - loop filter processing.

[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 and bricks. 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, Figure 8(b) shows examples of how the input image is divided into tiles, bricks, and slices. 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, the tile is a 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 ID of the brick. The input image is further divided into slices containing bricks corresponding to BID=0-2, slices containing bricks corresponding to BID=3, slices containing bricks corresponding to BID=4, slices containing bricks corresponding to BID=5-8 and 10-12, and slices containing bricks corresponding to BID=9 and 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] Furthermore, PPS 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. 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. In other words, it indicates that each slice is composed of only one brick.

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

[0054] Here, the range of i is 0 to num_slices_in_pic_minus1. However, since the index of the top-left brick of the first slice in the frame is fixed as 0, top_left_brick_idx[0] of the first slice is not encoded. In this embodiment, the range of i for top_left_brick_idx[i] and bottom_right_brick_idx_delta[i] is set to 0 to num_slices_in_pic_minus1, but it is not limited to this. For example, the bottom-right brick of the last slice (the num_slices_in_pic_minus1 slice) is fixed as the brick with the largest BID. Therefore, bottom_right_brick_idx_delta[num_slices_in_pic_minus1] does not need to be encoded. Furthermore, the bricks contained in slices other than the last slice have already been identified from top_left_brick_idx[i] and bottom_right_brick_idx_delta[i] of slices other than the last slice. Therefore, the bricks contained in the last slice can be identified as all bricks not included in the previous slices. In that case, the top-left brick of the last slice can be identified as the brick with the smallest BID among the remaining bricks. Thus, top_left_brick_idx[num_slices_in_pic_minus1] does not need to be encoded. Doing so further reduces the number of bits in the header.

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

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

[0057] 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).

[0058] 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).

[0059] `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]`.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0076] Furthermore, in this embodiment, since one slice contains multiple bricks, single_brick_per_slice_flag in slice data division information 0 is 0. Also, in this embodiment, since a slice contains multiple tiles in a rectangle, rect_slice_flag is 1. As shown in Figure 8(b), the number of slices in the input image is 5, so num_slices_in_pic_minus1 is 4.

[0077] For slice 0, top_left_brick_idx[0] is not encoded because it is trivial to be 0, and bottom_right_brick_idx_delta[0] is 2 (=2-0). For slice 1, top_left_brick_idx[1] is 3, and bottom_right_brick_idx_delta[1] is 0 (=3-3). For slice 2, top_left_brick_idx[2] is 4, and bottom_right_brick_idx_delta[2] is 0 (=4-4). For slice 3, top_left_brick_idx[3] is 5, and bottom_right_brick_idx_delta[3] is 7 (=12-5). For slice 4, top_left_brick_idx[4] is 9, and bottom_right_brick_idx_delta[4] is 4 (=13-9). As mentioned above, top_left_brick_idx[4] and bottom_right_brick_idx_delta[4] do not need to be encoded.

[0078] Furthermore, for entry_point_offset_minus1[], the encoding unit 110 encodes (the size of the encoded data of the (j-1)th basic block row in the slice minus 1) as entry_point_offset_minus1[j-1]. The number of entry_point_offset_minus1[] in the slice is equal to (the number of basic block rows in the slice minus 1). In this embodiment, since bottom_right_brick_idx_delta[0] is 2, it can be seen that slice 0 consists of bricks with BID=0 to 2.

[0079] Here, brick_height_minus1[0] is 2 and tile_rows_height_minus1 is 5. As a result, the number of basic block rows for bricks corresponding to BID=0 and the number of basic block rows for bricks corresponding to BID=1 are both brick_height_minus1[0]+1=3. Also, the number of basic block rows for bricks corresponding to BID=2 is tile_rows_height_minus1+1=6. Therefore, the number of basic block rows for slice 0 is 3+3+6=12. Thus, the range of j is 0 to 10.

[0080] For slice 1, top_left_brick_idx[1] is 3 and bottom_right_brick_idx_delta[1] is 0, indicating that it consists of bricks with BID=3. Also, since brick_row_height_minus1[2][0] is 1, the number of basic block rows in slice 1 (bricks with BID=3) is 2. Therefore, the range of j is only 0.

[0081] For slice 2, we can see that it consists of bricks with BID=4, since top_left_brick_idx[2] is 4 and bottom_right_brick_idx_delta[2] is 0. Also, brick_row_height_minus1[2][0] is 1, num_brick_rows_minus1[2] is 1, and tile_rows_height_minus1 is 5. Thus, the number of basic block rows in slice 2 (bricks with BID=4) is {(tile_rows_height_minus1+1)-(brick_row_height_minus1[2][0]+1)}=4. Therefore, the range of j is 0 to 2.

[0082] Slice 3 consists of bricks with BIDs of 5-8 and 10-12. Since tile_rows_height_minus1 is 5, we can see that the basic number of block rows for bricks with BIDs of 8 and 10 is 6 (=tile_rows_height_minus1+1). Also, since brick_height_minus1[3] is 1, we can see that the basic number of block rows for bricks with BIDs of 5-7 is 2 (=brick_height_minus1[3]+1). Also, since brick_height_minus1[7] is 2, we can see that the basic number of block rows for bricks with BIDs of 11 and 12 is 3 (=brick_height_minus1[7]+1). Therefore, the total number of basic block rows for all bricks that make up slice 3 is 2+2+2+6+6+3+3=24. Thus, the range of j is 0-22.

[0083] Slice 4 consists of bricks with BID=9 and bricks with BID=13. Since tile_rows_height_minus1 is 5, the number of basic block rows for each of the bricks with BID=9 and BID=13 is 6 (=tile_rows_height_minus1+1). Therefore, the sum of the number of basic block rows for all the bricks that make up slice 4 is 6+6=12. Thus, the range of j is 0 to 10.

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

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

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

[0087] 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 is encoded, and it is possible to generate a bitstream from which such information can be derived.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0101] In step S401, the separation and decoding unit 202 separates information related to decoding processing and coded data related to coefficients from the input bit stream and sends them to the decoding unit 203. Also, the separation and decoding unit 202 decodes the coded data of the header of the bit stream. More specifically, the separation and decoding unit 202 decodes basic block data division information, tile data division information, block data division information, slice data division information, basic block row data synchronization information, basic block row data position information, etc. in FIG. 6 to generate division information. Then, the separation and decoding unit 202 outputs the generated division information to the image reproduction unit 205. Also, the separation and decoding unit 202 reproduces the coded data of the picture data in units of basic blocks and outputs it to the decoding unit 203.

[0102] In this embodiment, the division of the input image, which is the source of the bit stream coding, is the division shown in FIG. 8. Information related to the input image, which is the source of the bit stream coding, and its division can be derived from the division information.

[0103] From pic_width_in_luma_samples included in the image size information, it can be specified 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 specified that the vertical size (height) of the input image is 1152 pixels.

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

[0105] Also, since single_tile_in_pic_flag of the tile data division information is 0, it can be specified that the input image is divided into a plurality of tiles. And since uniform_tile_spacing_flag is 1, it can be specified that each tile has the same size (excluding the edges).

[0106] Furthermore, since tile_cols_width_minus1=5 and tile_rows_height_minus1=5, we can determine that each tile is composed of 6x6 basic blocks. In other words, we can determine that each tile is composed of 384x384 pixels. Since the input image is 1152x1152 pixels, it can be seen that the input image is divided into 9 tiles, 3 horizontally and 3 vertically, and encoded.

[0107] Furthermore, since brick_splitting_present_flag=1 in the brick data splitting information, it can be determined that at least one tile in the input image is split into multiple bricks.

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

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

[0110] 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)).

[0111] 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)).

[0112] 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).

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

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

[0115] 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).

[0116] 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).

[0117] 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).

[0118] 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).

[0119] 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).

[0120] 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).

[0121] 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).

[0122] 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).

[0123] 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).

[0124] 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).

[0125] 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).

[0126] 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).

[0127] 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).

[0128] 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).

[0129] 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).

[0130] Next, we identify the bricks contained in each slice. Since num_slices_in_pic_minus1 = 4, we can determine that there are 5 slices in the input image. Furthermore, the corresponding brick can be identified from the slice_address of the slice being processed. That is, if slice_address is N, we know that the slice being processed is slice N.

[0131] In the case of slice 0, bottom_right_brick_idx_delta[0] is 2. This allows us to identify that the bricks included in slice 0 are those contained within the rectangular region enclosed by the coordinates of the top-left boundary of the BID=0 brick and the coordinates of the bottom-right boundary of the BID=2 brick. Since the coordinates of the top-left boundary of the BID=0 brick are (0,0) and the bottom-right boundary of the BID=2 brick is (12,6), we can identify that the bricks included in slice 0 are BID=0 to BID=2 bricks.

[0132] In the case of slice 1, since top_left_brick_idx[1] is 3 and bottom_right_brick_idx_delta[1] is 0, we can identify that the bricks included in slice 1 are bricks with BID=3.

[0133] In the case of slice 2, since top_left_brick_idx[2] is 4 and bottom_right_brick_idx_delta[2] is 0, we can identify that the brick included in slice 2 is a brick with BID=4.

[0134] In the case of slice 3, top_left_brick_idx[3] is 5 and bottom_right_brick_idx_delta[3] is 7. The coordinates of the top-left boundary of the brick with BID=5 are (0,6) and the coordinates of the bottom-right boundary of the brick with BID=12 are (12,18). Therefore, bricks that fall within the region with top-left coordinates (0,6) and bottom-right coordinates (12,18) can be identified as belonging to slice 3. As a result, it can be identified that bricks corresponding to BID=5~8 and 10~12 are included in slice 3. The coordinates of the bottom-right boundary of the brick corresponding to BID=9 are (18,12) and the coordinates of the bottom-right boundary of the brick corresponding to BID=13 are (18,18). Since both are outside the range of slice 3, they are judged not to belong to slice 3.

[0135] In the case of slice 4, top_left_brick_idx[4] is 9 and bottom_right_brick_idx_delta[4] is 4. The coordinates of the top-left boundary of the brick with BID=9 are (12,6) and the coordinates of the bottom-right boundary of the brick with BID=13 are (18,18). Therefore, bricks contained in the region with top-left coordinates (12,6) and bottom-right coordinates (18,18) can be identified as belonging to slice 4. As a result, it can be identified that the bricks corresponding to BID=9 and 13 are included in slice 4. Here, the coordinates of the top-left boundary of the brick corresponding to BID=10 are (0,12), the coordinates of the top-left boundary of the brick corresponding to BID=11 are (6,12), and the coordinates of the top-left boundary of the brick corresponding to BID=12 are (6,15). Therefore, all of these are outside the range of slice 4 and are judged not to belong to slice 4.

[0136] In this embodiment, the bricks included in slice 4, the last slice of the input image, were identified from top_left_brick_idx[4] and bottom_right_brick_idx_delta[4], but are not limited to this. It has already been derived that the bricks included in slices 0 to 3 are BID=0 to 2, BID=3, BID=4, BID=5 to 8, and 10 to 12, respectively, and it has been derived that the input image consists of 14 bricks with BID=0 to 13. Therefore, it is possible to identify that the bricks included in the last slice are the remaining bricks with BID=9 and 13. Thus, even if top_left_brick_idx[4] and bottom_right_brick_idx_delta[4] are not encoded, it is possible to identify the bricks included in the last slice. In this way, a bitstream with a reduced number of bits in the header portion can be decoded.

[0137] Furthermore, the entropy_coding_sync_enabled_flag=1 in the basic block row data synchronization information. This indicates that entry_point_offset_minus1[j-1], which represents (the size of the coded data of the (j-1)th basic block row in the slice - 1), is encoded in the bitstream. The number of these entries is the number of basic block rows in the slice being processed - 1.

[0138] In this embodiment, as described above, since each brick belonging to a slice can be identified, the number of entries_point_offset_minus1[j] encoded is the sum of the basic block row numbers of the bricks belonging to the slice minus 1.

[0139] For slice 0, the sum of the number of basic block rows in the brick corresponding to BID=0 (3) + the number of basic block rows in the brick corresponding to BID=1 (3) + the number of basic block rows in the brick corresponding to BID=2 (6) is (3 + 3 + 6 = 12) - 1 = 11. Therefore, for slice 0, entry_point_offset_minus1[] of 11 is encoded. In this case, the range of j is 0 to 10.

[0140] For slice 1, the number of basic block rows in the brick corresponding to BID=3 is (2)-1=1. Therefore, for slice 1, entry_point_offset_minus1[] of 1 is encoded. In this case, the range of j is 0 only.

[0141] In the case of slice 2, the number of basic block rows in the brick corresponding to BID=4 is (4)-1=3. Therefore, for slice 3, 3 entry_point_offset_minus1[] is encoded. In this case, the range of j is 0 to 2.

[0142] For slice 3, the sum of the number of basic block rows in the bricks corresponding to BID=5~8 and 10~12 is (2+2+2+6+6+3+3=24)-1=23. Therefore, for slice 3, 23 entry_point_offset_minus1[] is encoded. In this case, the range of j is 0~22.

[0143] In the case of slice 4, the sum of the number of basic block rows in the brick corresponding to BID=9 (6) + the number of basic block rows in the brick corresponding to BID=13 (6) is (6 + 6 = 12) - 1 = 11. Therefore, for slice 4, 11 entry_point_offset_minus1[] is encoded. In this case, the range of j is 0 to 10.

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

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

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

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

[0148] 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 image with the in-loop filtering applied to the frame memory 206.

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

[0150] Note that 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.

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

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

[0153] 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).

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

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

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

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

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

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

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

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

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

[0163] (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.

[0164] 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]

[0165] 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, A decoding means that decodes from the bitstream the following: first information indicating an integer value n equal to the result of subtracting 1 from the number of slices contained in the image; first flag relating to the activation of parallel processing; second information used to identify the first rectangular region to be processed among a plurality of rectangular regions contained in a target slice which is the i-th slice (where i is a certain integer value) in the image; third information used to identify the last rectangular region to be processed among the plurality of rectangular regions; and fourth information corresponding to the number of blocks in the vertical direction of the rectangular regions in the image. The value of the first flag is 1, and the second flag, which is a flag decoded from the picture parameter set of the bitstream and is a flag relating to the slice mode, indicates that a mode in which the slice is rectangular is used, and the target slice included in the image includes a plurality of rectangular regions in at least the horizontal or vertical direction, and the identification means for the target slice, based at least the second information, the third information and the fourth information, identifies the number of syntax elements used to identify the starting position of the coded data of a block row. Equipped with, If the target slice in the image is the nth corresponding slice, the third information is not decoded from the bitstream. The number of syntax elements identified by the aforementioned identification means are included in the slice header of the bitstream, Intra prediction is available for the blocks in the aforementioned image. An image decoding device characterized by the following features.

2. The decoding means is The image decoding device according to claim 1, characterized in that it is capable of decoding each block row in the rectangular region in parallel.

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

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

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 second information is decoded from the picture parameter set of the bitstream.

7. The image decoding apparatus according to claim 1, characterized in that the third information is decoded from the picture parameter set of the bitstream.

8. The image decoding apparatus according to claim 1, characterized in that the fourth information is decoded from the picture parameter set of the bitstream.

9. The image decoding apparatus according to claim 1, characterized in that the first rectangular region to be processed among the plurality of rectangular regions included in the target slice is the rectangular region in the upper left corner of the plurality of rectangular regions, and the last rectangular region to be processed among the plurality of rectangular regions included in the target slice is the rectangular region in the lower right corner of the plurality of rectangular regions.

10. The image decoding apparatus according to claim 1, characterized in that the size of each of the plurality of blocks forming the block row is determined from a fifth piece of information decoded from the sequence parameter set in the bitstream.

11. The image decoding apparatus according to claim 10, 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 fifth information.

12. The image decoding apparatus according to claim 1, characterized in that the image includes a plurality of slices from the 0th slice to the nth slice.

13. The image decoding apparatus according to claim 12, characterized in that the 0th slice is the slice in the upper left corner of the image, and the nth slice is the slice in the lower right corner of the image.

14. The image decoding apparatus according to claim 1, characterized in that each of the plurality of blocks forming the block row corresponds to a CTU (Coding Tree Unit) and is divisible into a plurality of subblocks.

15. 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 that decodes from the bitstream the following: first information indicating an integer value n equal to the result of subtracting 1 from the number of slices contained in the image; first flag relating to the activation of parallel processing; second information used to identify the first rectangular region to be processed among a plurality of rectangular regions contained in the target slice which is the i-th slice (where i is a certain integer value) in the image; third information used to identify the last rectangular region to be processed among the plurality of rectangular regions; and fourth information corresponding to the number of blocks in the vertical direction of the rectangular regions in the image. The value of the first flag is 1, and the second flag, which is a flag decoded from the picture parameter set of the bitstream and is a flag relating to the slice mode, indicates that a mode in which the slice is rectangular is used, and the target slice included in the image includes a plurality of rectangular regions in at least the horizontal or vertical direction, and the identification step of the target slice is to identify the number of syntax elements used to identify the starting position of the block row code data, based at least the second information, the third information and the fourth information, It has, If the target slice in the image is the nth corresponding slice, the third information is not decoded from the bitstream. The number of syntax elements identified by the aforementioned specific step are included in the slice header of the bitstream. Intra prediction is available for the blocks in the aforementioned image. An image decoding method characterized by the following:

16. An image encoding device for encoding an image that includes a rectangular region containing one or more block rows consisting of multiple blocks, An encoding means for encoding into a bitstream: first information indicating an integer value n equal to the result of subtracting 1 from the number of slices contained in the image; first flag relating to the activation of parallel processing; second information used to identify the first rectangular region to be processed among a plurality of rectangular regions contained in a target slice which is the i-th slice (where i is a certain integer value) in the image; third information used to identify the last rectangular region to be processed among the plurality of rectangular regions; and fourth information corresponding to the number of blocks in the vertical direction of the rectangular region in the image. The value of the first flag is 1, and the second flag, which is a flag encoded in the picture parameter set of the bitstream and is a flag relating to the slice mode, indicates that a mode in which the slice is rectangular is used, and the target slice included in the image includes a plurality of rectangular regions in at least the horizontal or vertical direction, and the identification means for the target slice, based at least the second information, the third information and the fourth information, identifies the number of syntax elements used to identify the starting position of the coded data of a block row. Equipped with, If the target slice in the image is the nth corresponding slice, the third information is not encoded in the bitstream. The number of syntax elements identified by the aforementioned identification means are included in the slice header of the bitstream, Intra prediction is available for the blocks in the aforementioned image. An image coding device characterized by the following:

17. An image encoding method for encoding an image that includes a rectangular region containing one or more block rows consisting of multiple blocks, An encoding step that encodes into a bitstream: first information indicating an integer value n equal to the result of subtracting 1 from the number of slices contained in the image; first flag relating to the activation of parallel processing; second information used to identify the first rectangular region to be processed among a plurality of rectangular regions contained in the target slice which is the i-th slice (where i is a certain integer value) in the image; third information used to identify the last rectangular region to be processed among the plurality of rectangular regions; and fourth information corresponding to the number of blocks in the vertical direction of the rectangular region in the image. The value of the first flag is 1, and the second flag, which is a flag encoded in the picture parameter set of the bitstream and is a flag relating to the slice mode, indicates that a mode in which the slice is rectangular is used, and the target slice included in the image includes a plurality of rectangular regions in at least the horizontal or vertical direction, and the identification step of the target slice is to identify the number of syntax elements used to identify the starting position of the block row's coded data, based at least the second information, the third information, and the fourth information. It has, If the target slice in the image is the nth corresponding slice, the third information is not encoded in the bitstream. The number of syntax elements identified by the aforementioned specific step are included in the slice header of the bitstream. Intra prediction is available for the blocks in the aforementioned image. An image encoding method characterized by the following.

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

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

Images