Image encoding device, image decoding device, image encoding method, and 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 an image encoding / decoding technique. [Background technology]

[0002] The High Efficiency Video Coding (HEVC) coding method (hereafter referred to as HEVC) is known as a coding method for compressing and recording moving images. To improve coding efficiency, HEVC uses basic blocks larger than conventional macroblocks (16x16 pixels). These large basic blocks are called Coding Tree Units (CTUs) and can be up to 64x64 pixels in size. CTUs are further divided into sub-blocks, which serve as units for prediction and transformation.

[0003] Furthermore, HEVC allows a picture to be divided into multiple tiles or slices for encoding. There is little data dependency between tiles or slices, making it possible to perform encoding and decoding processes in parallel. One of the major advantages of dividing a picture into tiles and slices is that it can be processed in parallel on a multi-core CPU, etc., reducing processing time.

[0004] Furthermore, each slice is coded using the conventional binary arithmetic coding method adopted in HEVC. That is, each syntax element is binarized to generate a binary signal. A table of occurrence probabilities (hereinafter referred to as the occurrence probability table) is provided for each syntax element, and the binary signal is arithmetically coded based on the occurrence probability table. This occurrence probability table is used as decoding information for decoding the subsequent code during decoding. During encoding, it is used as coding information for the subsequent encoding. Then, each time coding is performed, the occurrence probability table is updated based on statistical information indicating whether the coded binary signal is a symbol with a high occurrence probability.

[0005] HEVC also has a technique for parallel processing of entropy encoding and decoding called Wavefront Parallel Processing (hereinafter referred to as WPP). WPP applies a table of occurrence probabilities at the time of encoding processing of a block at a predetermined position to the leftmost block of the next row, thereby enabling parallel encoding processing of blocks row by row while suppressing a decrease in encoding efficiency. To enable parallel processing on a block row basis, 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 block rows, are coded in the slice header. Patent Document 1 discloses technology related to WPP.

[0006] In recent years, efforts have been initiated to internationally standardize a more efficient coding method as a successor to HEVC. The Joint Video Experts Team (JVET) was established between ISO / IEC and ITU-T, and standardization is underway as the Versatile Video Coding (VVC) coding method (hereafter referred to as VVC). VVC considers further dividing tiles into rectangles (bricks) consisting of multiple block rows. A slice is then configured to contain one or more bricks. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-11638 Summary of the Invention [Problem to be solved by the invention]

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

[0009] One aspect of the present invention is an image decoding device that decodes an image including a rectangular area including one or more block rows each consisting of a plurality of blocks from a bitstream obtained by encoding the image, the image decoding device decoding a first flag related to enabling parallel processing, decoding a second flag from a picture parameter set of the bitstream that indicates whether a first mode in which slices are rectangular is used or a second mode for slices that is different from the first mode is used, decoding first information corresponding to the number of blocks in the rectangular area in the vertical direction from the picture parameter set, and decoding second information regarding the number of rectangular areas included in a slice of the image from a slice header of the bitstream, and when the image includes a plurality of rectangular areas and the second flag indicates that the second mode is used, decoding the first flag related to enabling parallel processing from a picture parameter set of the bitstream. and an identification means, when the value of the first flag is 1 and the second flag indicates that the second mode is to be used, for identifying the number of pieces of information for identifying the starting position of 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 area, and the second information on the number of rectangular areas included in the slice, wherein the decoding means decodes third information regarding the size of the image from the bitstream, and the decoding means decodes the coded data of the block row based at least on the number of pieces of information for identifying the starting position identified by the identification means and the 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 drawings]

[0011] [Figure 1] FIG. 1 is a block diagram showing an example of the functional configuration of an image encoding device. [Figure 2] FIG. 1 is a block diagram showing an example of the functional configuration of an image decoding device. [Figure 3] 10 is a flowchart of an input image encoding process performed by the image encoding device. [Figure 4] 10 is a flowchart of a bitstream decoding process performed by an image decoding device. [Figure 5] FIG. 1 is a block diagram showing an example of the hardware configuration of a computer device. [Figure 6] FIG. 10 is a diagram showing an example of a bitstream format. [Figure 7] FIG. 10 is a diagram showing an example of dividing an input image. [Figure 8] FIG. 10 is a diagram showing an example of dividing an input image. [Figure 9] FIG. 1 is a diagram showing the relationship between tiles and slices. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the claimed invention. Although multiple features are described in the embodiments, not all of these multiple features are necessarily essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same reference numerals are used to designate the same or similar components, and redundant explanations will be omitted.

[0013] [First embodiment] First, an example of the functional configuration of an image encoding device according to this embodiment will be described using the block diagram in FIG. 1. An input image to be encoded is input to the image division unit 102. The input image may be an image of each frame constituting a moving image, or 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 covering a rectangular area in 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 including one or more block rows each consisting of multiple blocks each the same size as a tile) consisting 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, each consisting of one or more tiles or one or more bricks within a 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. FIG. 7 shows an example of dividing an input image into four tiles, four slices, and 11 bricks. The upper left tile is divided into one brick, the lower left tile into two bricks, the upper right tile into five bricks, and the lower right tile into three bricks. The left slice is configured to contain three bricks, the upper right slice into two bricks, the center right slice into three bricks, and the lower right slice into three bricks. The image division unit 102 outputs information about the size of each of the tiles, bricks, and slices divided in this way as division information.

[0014] The block dividing unit 103 divides the image of the basic block row (basic block row image) output from the image dividing unit 102 into a plurality of basic blocks, and outputs the image (block image) in units of basic blocks to the subsequent stage.

[0015] The prediction unit 104 divides an image in basic block units into sub-blocks, and performs intra-frame prediction or inter-frame prediction on a sub-block basis to generate a predicted image. Intra-prediction across bricks (intra-prediction using pixels of blocks in other bricks) and motion vector prediction across bricks (motion vector prediction using motion vectors of blocks in other bricks) are not performed. Furthermore, the prediction unit 104 calculates and outputs a prediction error from the input image and predicted image. The prediction unit 104 also outputs information required for prediction (prediction information), such as the sub-block division method, prediction mode, and motion vectors, along with the prediction error.

[0016] The transform / quantization unit 105 performs an orthogonal transform on the prediction errors in sub-block units to obtain transform coefficients, and quantizes the obtained transform coefficients to obtain quantized coefficients. The inverse quantization / inverse transform unit 106 inverse quantizes the quantized coefficients output from the transform / quantization unit 105 to regenerate transform coefficients, and further performs an inverse orthogonal transform on the regenerated transform coefficients to regenerate the prediction errors.

[0017] The frame memory 108 functions as a memory for storing reconstructed images. The image reconstruction unit 107 generates a predicted image by appropriately referencing the frame memory 108 based on the prediction information output from the prediction unit 104, and generates and outputs a reconstructed image from the predicted image and the input prediction error.

[0018] The in-loop filter unit 109 performs in-loop filtering such as deblocking filtering and sample adaptive offset on the reconstructed image, and outputs an image that has undergone the in-loop filtering (filtered image).

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

[0020] 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 bit stream including the generated header code data and the code data output from the encoding unit 110. The control unit 199 controls the operation of the entire image encoding device, and controls the operation of each functional unit of the image encoding device.

[0021] Next, a description will be given of the encoding process for an input image performed by the image encoding device having the configuration shown in Fig. 1. In this embodiment, for ease of explanation, only intra-prediction encoding process will be described, but the present invention is not limited to this and can also be applied to inter-prediction encoding process. Furthermore, for the purpose of specific explanation, this embodiment will be described assuming that the block dividing unit 103 divides the basic block row image output from the image dividing unit 102 into units of "basic blocks having a size of 64 x 64 pixels."

[0022] The image division unit 102 divides the input image into tiles, bricks, and slices. An example of division of an input image by the image division unit 102 is shown in FIG. 8. In this embodiment, as shown in FIG. 8(a), an input image having a size of 1152 × 1152 pixels is divided into nine tiles (each tile has a size of 384 × 384 pixels). An ID (tile ID) is assigned to each tile in raster order starting 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] An example of dividing an input image into tiles, bricks, and slices is shown in Figure 8(b). As shown in Figure 8(b), tiles with tile ID = 0 and tile ID = 7 are divided into two bricks (each brick is 384 x 192 pixels). Tile with tile ID = 2 is divided into two bricks (the upper brick is 384 x 128 pixels, and the lower brick is 384 x 256 pixels). Tile with tile ID = 3 is divided into three bricks (each brick is 384 x 128 pixels). Tiles with tile ID = 1, 4, 5, 6, and 8 are not divided into bricks (equivalent to dividing one tile into one brick), resulting in a tile = brick. Each brick is assigned an ID in order from top to bottom within the raster order. 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 a slice containing a brick corresponding to BID=0, slice 1 is a slice containing a brick corresponding to BID=1, and slice 2 is a slice containing a brick corresponding to BID=2. Slice 3 is a slice containing bricks corresponding to BID=3 to 10, and slice 4 is a slice containing bricks corresponding to BID=11 to 13. Each slice is also assigned an ID in order from top to bottom among the slices in raster order; 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 information about the size of 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 the divided basic block row images to the block division unit 103.

[0025] The block dividing unit 103 divides the basic block row image output from the image dividing unit 102 into a plurality of basic blocks, and outputs block images (64×64 pixels) that are images in basic block units to the prediction unit 104 at the subsequent stage.

[0026] The prediction unit 104 divides an image in units of basic blocks into sub-blocks, determines an intra-prediction mode such as horizontal prediction or vertical prediction for each sub-block, and generates a predicted image from the determined intra-prediction mode and encoded pixels. The prediction unit 104 also calculates a prediction error from the input image and predicted image, and outputs the calculated prediction error to the transformation and 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 reproduction unit 107.

[0027] The transform and quantization unit 105 performs orthogonal transform (orthogonal transform processing corresponding to the size of the sub-block) on the prediction errors output from the prediction unit 104 in sub-block units to obtain transform coefficients (orthogonal transform coefficients).The transform and quantization unit 105 then quantizes the obtained transform coefficients to obtain quantization coefficients.The transform and quantization unit 105 then outputs the obtained quantization coefficients to the coding unit 110 and the inverse quantization and inverse transform unit 106.

[0028] The inverse quantization and inverse transform unit 106 inverse quantizes the quantized coefficients output from the transform and quantization unit 105 to regenerate transform coefficients, and then performs inverse orthogonal transform on the regenerated transform coefficients to regenerate prediction errors. The inverse quantization and inverse transform unit 106 then outputs the regenerated prediction errors to the image reproduction unit 107.

[0029] The image reproduction 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 reproduced image from the predicted image and the prediction error input from the inverse quantization and inverse transform unit 106. The image reproduction unit 107 then stores the generated reproduced image in the frame memory 108.

[0030] The in-loop filter unit 109 reads the reconstructed image from the frame memory 108 and performs in-loop filtering such as deblocking filtering and sample adaptive offset on the read reconstructed image. The in-loop filter unit 109 then stores (restores) the image that has been subjected to the in-loop filtering in the frame memory 108 again.

[0031] The encoding unit 110 generates coded data by entropy coding the quantized coefficients output from the transform / quantization unit 105 and the prediction information output from the prediction unit 104. There is no particular specification as to the entropy coding method, but Golomb coding, arithmetic coding, Huffman coding, etc. can be used. The encoding unit 110 then outputs the generated coded data to the integrated coding 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 bit stream by multiplexing the generated header code data with the code data output from the encoding unit 110. The output destination of the bit stream is not limited to a specific output destination, and the bit stream may be output (stored) in a memory inside or outside the image encoding device, or 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, Fig. 6 shows an example of the format of the bitstream (VVC-based coded data coded by the image coding device) output by the integrated coding unit 111. The bitstream in Fig. 6 includes a sequence parameter set (SPS), which is header information including information related to the coding of a sequence. The bitstream in Fig. 6 also includes a picture parameter set (PPS), which is header information including information related to the coding of a picture. The bitstream in Fig. 6 also includes a slice header (SLH), which is header information including information related to the coding of a slice. The bitstream in Fig. 6 also includes coded data for each brick (brick 0 to brick (N-1) in Fig. 6).

[0034] The SPS contains image size information and basic block data division information. The PPS contains tile data division information, which is division information for tiles, brick data division information, which is division information for bricks, slice data division information 0, which is division information for slices, and basic block row data synchronization information. The SLH contains slice data division information 1 and basic block row data position information.

[0035] First, the SPS will be described. The 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, the input image of FIG. 8 is used as the input image, so pic_width_in_luma_samples = 1152 and pic_height_in_luma_samples = 1152. The 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 a basic block is expressed as 1<<(log2_ctu_size_minus2 + 2). In this embodiment, the size of a basic block is 64×64 pixels, so the value of log2_ctu_size_minus2 is 4.

[0036] Next, the PPS will be described. The PPS includes information 604 to 607 as tile data division information. Information 604 is single_tile_in_pic_flag, which indicates whether the input image has been divided into multiple tiles and coded. When single_tile_in_pic_flag=1, this indicates that the input image has not been divided into multiple tiles and coded. On the other hand, when single_tile_in_pic_flag=0, this indicates that the input image has been divided into multiple tiles and coded.

[0037] Information 605 is information that is included in the tile data division information when single_tile_in_pic_flag=0. Information 605 is uniform_tile_spacing_flag, which indicates whether each tile has the same size. When uniform_tile_spacing_flag=1, it indicates that each tile has the same size, and when uniform_tile_spacing_flag=0, it indicates that tiles of different sizes exist.

[0038] Information 606 and information 607 are information included in the tile data division information when uniform_tile_spacing_flag=1. Information 606 is tile_cols_width_minus1, which indicates (the number of basic blocks in the horizontal direction of the tile - 1). Information 607 is tile_rows_height_minus1, which indicates (the number of basic blocks in the vertical direction 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 blocks in the horizontal direction of the input image is divided by the number of basic blocks in the horizontal direction of the tile. If this division leaves a remainder, the quotient is added by 1 to determine 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 blocks in the vertical direction of the input image is divided by the number of basic blocks in the vertical direction of the tile. If this division leaves a remainder, the quotient is added by 1 to determine the "number of tiles in the vertical direction of the input image." Additionally, the total number of tiles in the input image can be calculated by multiplying the number of tiles in the horizontal direction of the input image by the number of tiles in the vertical direction of the input image.

[0039] When uniform_tile_spacing_flag=0, tiles of different sizes are included, 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 vertical and horizontal sizes of each tile are coded.

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

[0041] Information 609 is information that is included in the brick data split information when brick_splitting_present_flag=1. Information 609 is brick_split_flag[] that indicates, for each tile, whether the tile is split into multiple bricks. brick_split_flag[] that indicates whether the i-th tile is split into multiple bricks is represented as brick_split_flag[i]. When brick_split_flag[i]=1, it indicates that the i-th tile is split into multiple bricks, and when brick_split_flag[i]=0, it indicates that the i-th tile is composed of a single brick.

[0042] Information 610 is uniform_brick_spacing_flag[i] indicating whether the size of each brick constituting the i-th tile is the same when brick_split_flag[i]=1. If brick_split_flag[i]=0 for all i, information 610 is not included in the brick data division information. Information 610 includes uniform_brick_spacing_flag[i] for i that satisfies brick_split_flag[i]=1. When uniform_brick_spacing_flag[i]=1, this indicates that the size of each brick constituting the i-th tile is the same. On the other hand, when uniform_brick_spacing_flag[i]=0, this indicates that there is a brick that is a different size from the others among the bricks constituting the i-th tile.

[0043] Information 611 is information that is included in the brick data division information when uniform_brick_spacing_flag[i] = 1. The information 611 is brick_height_minus1[i] that indicates (the number of basic 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 calculated 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 constituting 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 this division leaves a remainder, the quotient plus 1 is used as the "number of bricks constituting 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 is divided into four bricks, from top to bottom: a brick with three basic block rows, a brick with three basic block rows, a brick with three basic block rows, and a brick with one basic block row.

[0045] The information 612 is num_brick_rows_minus1[i] indicating (the number of bricks constituting the i-th tile - 1) for i that satisfies uniform_brick_spacing_flag[i]=0.

[0046] In this embodiment, when uniform_brick_spacing_flag[i]=0, num_brick_rows_minus1[i] indicating (the number of bricks constituting the i-th tile - 1) is included in the brick data division information. However, this is not limited to this.

[0047] For example, assume that the number of bricks constituting the i-th tile is two or more when brick_split_flag[i]=1. Then, num_brick_rows_minus2[i], which indicates (the number of bricks constituting the tile - 2), may be encoded instead of num_brick_rows_minus1[i]. This reduces the number of syntax bits indicating the number of bricks constituting the tile. For example, if the tile is composed of two bricks and num_brick_rows_minus1[i] is Golomb-encoded, three bits of data, "010," indicating "1," are encoded. On the other hand, if num_brick_rows_minus2[i], which indicates (the number of bricks constituting the tile - 2), is Golomb-encoded, one bit of data, "0," indicating "0," is encoded.

[0048] Information 613 is brick_row_height_minus1[i][j], which indicates (the number of basic blocks in the vertical direction of the j-th brick in the i-th tile - 1) for i that satisfies uniform_brick_spacing_flag[i] = 0. The number of brick_row_height_minus1[i][j] is coded as many times as num_brick_rows_minus1[i]. Note that when the above-mentioned num_brick_rows_minus2[i] is used, the number of brick_row_height_minus1[i][j] is coded as many times as num_brick_rows_minus2[i] + 1. The number of basic blocks in the vertical direction 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 blocks in the vertical direction of the tile. For example, assume that the number of basic blocks in the vertical direction of a tile = 10, num_brick_rows_minus1 = 3, and brick_row_height_minus1 = 2, 1, 2. In this case, the number of basic blocks in the vertical direction of the bottom brick in the tile is 10 - (3 + 2 + 3) = 2.

[0049] The PPS also includes information 614 to 618 as slice data division information 0. Information 614 is single_brick_per_slice_flag. When single_brick_per_slice_flag=1, it indicates that all slices in the input image are made up of a single brick. In other words, it indicates that each slice is made up of only one brick. On the other hand, when single_brick_per_slice_flag=0, it indicates that one or more slices in the input image are made up of multiple bricks.

[0050] Information 615 is rect_slice_flag, which is information included in slice data division information 0 when single_brick_per_slice_flag=0. rect_slice_flag indicates whether the tiles included in the slice are in 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 coded 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 information included in slice data division information 0 when rect_slice_flag=1 and single_brick_per_slice_flag=0. num_slices_in_pic_minus1 indicates (the number of slices in the input image−1).

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

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

[0054] The PPS also contains coded information 619 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 adjacent basic block row above is applied to the leftmost block. This enables parallel processing of entropy encoding and decoding on a basic block row basis.

[0055] Next, the SLH will be described. The SLH contains coded information 620 to 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 when the number of bricks in the input image is two or more. When rect_slice_flag=0, slice_address indicates the BID of the beginning of the slice, and when rect_slice_flag=1, it indicates the number of the current slice.

[0056] Information 621 is num_bricks_in_slice_minus1 that is included in slice data division information 1 when rect_slice_flag=0 and single_brick_per_slice_flag=0. num_bricks_in_slice_minus1 indicates (the number of bricks in a slice - 1).

[0057] The SLH includes information 622 as basic block row data position information. The information 622 is entry_point_offset_minus1[]. When entropy_coding_sync_enabled_flag=1, entry_point_offset_minus1[] is coded and included in the basic block row data position information for the number of (the number of basic block rows in the slice - 1).

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

[0059] Next, the encoding process of an input image by the image encoding device of this embodiment (the process of generating a bitstream having the configuration of FIG. 6) will be described with reference to the flowchart of FIG.

[0060] First, in step S301, the image division unit 102 divides the input image into tiles, bricks, and slices. Then, the image division unit 102 outputs information about the size of 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 the divided basic block row images to the block division unit 103.

[0061] In step S302, the block dividing unit 103 divides the basic block row image into a plurality of basic blocks, and outputs block images, which are images in units of basic blocks, to the prediction unit 104 at the subsequent stage.

[0062] In step S303, the prediction unit 104 divides the basic block-based image output from the block division unit 103 into sub-blocks, determines an intra-prediction mode for each sub-block, and generates a predicted image from the determined intra-prediction mode and encoded pixels. The prediction unit 104 then calculates a prediction error from the input image and predicted image, and outputs the calculated prediction error to the transformation and 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 reproduction unit 107.

[0063] In step S304, the transform / quantization unit 105 orthogonally transforms the prediction errors output from the prediction unit 104 in units of sub-blocks to obtain transform coefficients (orthogonal transform coefficients). The transform / quantization unit 105 then quantizes the obtained transform coefficients to obtain quantized coefficients. The transform / quantization unit 105 then outputs the obtained quantized coefficients to the coding unit 110 and the inverse quantization / inverse transform unit 106.

[0064] In step S305, the inverse quantization and inverse transform unit 106 inverse quantizes the quantized coefficients output from the transform and quantization unit 105 to regenerate transform coefficients, and then performs inverse orthogonal transform on the regenerated transform coefficients to regenerate prediction errors. The inverse quantization and inverse transform unit 106 then outputs the regenerated prediction errors to the image reproduction unit 107.

[0065] In step S306, the image reproduction 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 reproduced image from the predicted image and the prediction error input from the inverse quantization and inverse transform unit 106. The image reproduction unit 107 then stores the generated reproduced image in the frame memory 108.

[0066] In step S307, the encoding unit 110 performs entropy encoding on the quantized coefficients output from the transform / quantization unit 105 and the prediction information output from the prediction unit 104 to generate coded data.

[0067] Here, when entropy_coding_sync_enabled_flag=1, the occurrence probability table at the time when the basic block at a predetermined position in the adjacent basic block row above is processed is applied before processing the leftmost basic block in the next basic block row. In this embodiment, the description will be given assuming that entropy_coding_sync_enabled_flag=1.

[0068] In step S308, the control unit 199 determines whether or not encoding of all basic blocks in the slice has been completed. If the result of this determination is that encoding of all basic blocks in the slice has been completed, the process proceeds to step S309. On the other hand, if there are basic blocks in the slice that have not yet been encoded (uncoded basic blocks), the process proceeds to step S303 to encode the uncoded 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 bit stream including the generated header code data and the code data output from the encoding unit 110.

[0070] 8, in the tile data division information, single_tile_in_pic_flag is 0 and uniform_tile_spacing_flag is 1. In addition, tile_cols_width_minus1 is 5 and tile_rows_height_minus1 is 5.

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

[0072] Also, tiles corresponding to tile ID=0, 3, 7 are all divided into bricks of the same size. However, uniform_brick_spacing_flag[0], uniform_brick_spacing_flag[3], uniform_brick_spacing_flag[7] are all 1. For the tile corresponding to tile ID=2, the size of the brick with BID=3 is different from the size of the brick with BID=4. However, 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 the above syntax for num_brick_rows_minus2[2] is coded instead of num_brick_rows_minus1[2], the value becomes 0.

[0075] In this embodiment, since one slice includes multiple bricks, single_brick_per_slice_flag in slice data division information 0 is 0. In this embodiment, since a slice includes multiple tiles in raster order (a slice includes tiles arranged in raster order), rect_slice_flag is 0.

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

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

[0078] Then, the number of bricks contained in each slice is coded as num_bricks_in_slice_minus1. Since the only bricks contained in slice 0 are those corresponding to BID=0 (only a single brick), num_bricks_in_slice_minus1 corresponding to slice 0 is 0. Since the only bricks contained in slice 1 are those corresponding to BID=1 (only a single brick), num_bricks_in_slice_minus1 corresponding to slice 1 is 0. Since the only bricks contained in slice 2 are those corresponding to BID=2 (only a single brick), num_bricks_in_slice_minus1 corresponding to slice 2 is 0. Since the only bricks contained in slice 3 are those corresponding to BID=3 to 10 (8 bricks), num_bricks_in_slice_minus1 corresponding to slice 3 is 7. Since the bricks included in slice 4 are the bricks corresponding to BID=11 to 13 (three 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 (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 (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, 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 (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 (j ranges from 0 to 4).

[0083] For slice 3, the corresponding slice_address = 3 and the corresponding num_bricks_in_slice_minus1 = 7. Slice 3 is composed 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 BID = 3 to 10.

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

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

[0086] Since the number of basic block rows of the bricks corresponding to BID=5 to 7 is brick_height_minus1[3]=1, it can be seen that brick_height_minus1[3]+1=2.

[0087] The number of basic block rows of bricks corresponding to each of BID=8 to 10 is tile_rows_height_minus1=5, so it can be seen that 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 of 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 = 11 and the corresponding num_bricks_in_slice_minus1 = 2. Therefore, slice 4 is composed of bricks (3 bricks) corresponding to BID = 11 to 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 BID = 11 to 13.

[0090] The number of basic block rows of the bricks corresponding to BID=11 to 12 is brick_height_minus1[7]=2, so it can be seen that brick_height_minus1[7]+1=3.

[0091] Since the number of basic block rows of the brick corresponding to BID=13 is tile_rows_height_minus1=5, it can be seen that the number of basic block rows is tile_rows_height_minus1+1=6.

[0092] Therefore, the number of basic block rows in slice 4 can be derived as the sum of the number of basic block rows of the 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 there is no need to encode num_entry_point_offset and include it in the header as in the past. 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 or not encoding of all basic blocks in the input image has been completed. If the result of this determination is that 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 basic blocks in the input image that have not yet been encoded, the process proceeds to step S303, and subsequent processes are 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 reconstructed image generated in step S306, and outputs the image that has undergone the in-loop filtering.

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

[0097] [Second embodiment] In this embodiment, an image decoding device that decodes a bitstream generated by the image encoding device according to the first embodiment will be described. Note that the same requirements as those in the first embodiment, such as the bitstream configuration, are the same as those in the first embodiment, and therefore will not be described again.

[0098] An example of the functional configuration of an image decoding device according to this embodiment will be described with reference to the block diagram of FIG. 2. The separate decoding unit 202 acquires a bitstream generated by the image encoding device according to the first embodiment. The method for acquiring the bitstream is not limited to a specific acquisition 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 may be acquired from a bitstream stored inside or outside the image decoding device. The separate decoding unit 202 then separates coded data related to information about the decoding process and coefficients from the acquired bitstream and sends the separated data to the decoding unit 203. The separate decoding unit 202 also decodes coded data in the header of the bitstream. In this embodiment, the separate decoding unit 202 decodes header information related to image division, such as the size of tiles, bricks, slices, and basic blocks, to generate partition information, and outputs the generated partition information to the image reproduction unit 205. In other words, the separate decoding unit 202 performs the reverse operation of the integrated encoding unit 111 in FIG. 1.

[0099] The decoding unit 203 reproduces the quantized coefficients and prediction information by decoding the coded data output from the separate decoding unit 202. The inverse quantization and inverse transform unit 204 performs inverse quantization on the quantized coefficients to generate transform coefficients, and performs inverse orthogonal transform on the generated transform coefficients to reproduce the prediction error.

[0100] The frame memory 206 is a memory for storing image data of the reconstructed picture. The image reconstruction unit 205 generates a predicted image by appropriately referencing the frame memory 206 based on the input prediction information. The image reconstruction 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 reconstruction unit 205 then identifies the positions of tiles, bricks, and slices in the input image based on the partition information input from the separation decoding unit 202, and outputs the reconstructed image.

[0101] The in-loop filter unit 207 performs in-loop filtering such as deblocking filtering on the reconstructed image, similar to the in-loop filter unit 109, and outputs the 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 unit of the image decoding device.

[0102] Next, a bitstream decoding process by an image decoding device having the configuration shown in Fig. 2 will be described. In the following, a bitstream is described as being input to the image decoding device in units of frames, but a bitstream of a still image for one frame may also be input to the image decoding device. In addition, in this embodiment, for ease of explanation, only intra-prediction decoding process will be described, but the present invention is not limited to this and can also be applied to inter-prediction decoding process.

[0103] The separate decoding unit 202 separates information related to the decoding process and coded data related to coefficients from the input bitstream and sends the separated data to the decoding unit 203. The separate decoding unit 202 also decodes coded data in the bitstream header. More specifically, the separate decoding unit 202 decodes basic block data partition information, tile data partition information, brick data partition information, slice data partition information 0, basic block row data synchronization information, basic block row data position information, etc. in FIG. 6 to generate partition information. The separate decoding unit 202 then outputs the generated partition information to the image reproduction unit 205. The separate decoding unit 202 also reproduces coded data for each basic block of the picture data and outputs the reproduced coded data to the decoding unit 203.

[0104] The decoding unit 203 decodes the coded data output from the separate decoding unit 202 to reproduce the quantized coefficients and prediction information. The reproduced quantized coefficients are output to the inverse quantization and inverse transform unit 204, and the reproduced prediction information is output to the image reproduction unit 205.

[0105] The inverse quantization and inverse transform unit 204 performs inverse quantization on the input quantized coefficients to generate transform coefficients, and performs inverse orthogonal transform on the generated transform coefficients to regenerate prediction errors. The regenerated prediction errors are output to the image regeneration unit 205.

[0106] The image reproduction unit 205 generates a predicted image by appropriately referencing the frame memory 206 based on the prediction information input from the separate decoding unit 202. The image reproduction unit 205 then generates a reproduced image from the generated predicted image and the prediction error reproduced by the inverse quantization and inverse transform unit 204. The image reproduction unit 205 then specifies the shape of tiles, bricks, and slices as shown in FIG. 7 and their positions in the input image for the reproduced image based on the partition information input from the separate decoding unit 202, and outputs (stores) them to 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 reconstructed image read from the frame memory 206 , and outputs (stores) the image that has undergone in-loop filtering to the frame memory 206 .

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

[0109] Next, the decoding process of a bitstream by the image decoding device according to this embodiment (the decoding process of a bitstream having the configuration shown in FIG. 6) will be described with reference to the flowchart of FIG.

[0110] In step S401, the separate decoding unit 202 separates information related to the decoding process and coded data related to coefficients from the input bitstream and sends the separated data to the decoding unit 203. The separate decoding unit 202 also decodes coded data in the bitstream header. More specifically, the separate decoding unit 202 decodes basic block data partition information, tile data partition information, brick data partition information, slice data partition information, basic block row data synchronization information, basic block row data position information, etc. in FIG. 6 to generate partition information. The separate decoding unit 202 then outputs the generated partition information to the image reproduction unit 205. The separate decoding unit 202 also reproduces coded data for each basic block of the picture data and outputs the reproduced coded data to the decoding unit 203.

[0111] In this embodiment, the input image from which the bitstream is coded is divided as shown in Fig. 8. Information relating to the input image from which the bitstream is coded 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 of the basic block data partition information is 4, 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 of the tile data partition information is 0, it can be determined that the input image is divided into multiple tiles. And since uniform_tile_spacing_flag is 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 9 tiles, 3 horizontally and 3 vertically, and encoded.

[0116] Also, since brick_splitting_present_flag of the brick data partition information is 1, 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 0. This makes it possible 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 of all tiles is 6, it can be seen that the number of basic block rows of bricks in the tiles corresponding to tile IDs=1, 4, 5, 6, and 8 is 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 identify 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 identify that the tiles corresponding to tile IDs = 0, 3, and 7 are all divided into bricks of the same size.

[0119] Furthermore, brick_height_minus1[0] and brick_height_minus1[7] are both 2. Therefore, it can be specified that the number of basic blocks of bricks in the vertical direction within the tile corresponding to tile ID=0 and the tile corresponding to tile ID=7 is 3. It can also be specified that the number of bricks in the tile corresponding to tile ID=0 and the tile corresponding to tile ID=7 is 2 (= number of basic block rows in the tile (6) / number of basic blocks in the vertical direction within the tile (3)).

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

[0121] For the tile corresponding to tile ID=2, num_brick_rows_minus1[2]=1, which indicates that the tile is composed of two bricks. Furthermore, uniform_brick_spacing_flag[2]=0. This indicates that the tile corresponding to tile ID=2 has a brick of a different size than the others. Furthermore, brick_row_height_minus1[2][0]=1, brick_row_height_minus1[2][1]=3, and the number of basic blocks in the vertical direction for all tiles is 6. This indicates that the tile corresponding to tile ID=2 is composed, from top to bottom, of a brick with two basic blocks in the vertical direction and a brick with four basic blocks in the vertical direction. Note that brick_row_height_minus1[2][1]=3 may not be coded. If there are two bricks in a tile, the height of the second brick can be calculated 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 division information 0, it can be determined that at least one slice is made up of multiple bricks. In this embodiment, when uniform_brick_spacing_flag[i]=0, num_brick_rows_minus1[i] indicating (the number of bricks making up the i-th tile - 1) is included in the brick data division information. However, this is not limitative.

[0123] For example, assume that the number of bricks constituting the i-th tile is 2 or more when brick_split_flag[i] = 1. Then, num_brick_rows_minus2[i], which indicates (the number of bricks constituting the tile - 2), may be decoded instead of num_brick_rows_minus1[i]. In this way, it is possible to decode a bitstream with a reduced number of syntax bits indicating the number of bricks constituting the tile.

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

[0125] The coordinates of the upper left boundary of the brick with BID=0 in the tile corresponding to tile ID=0 are (0,0). The number of basic block rows of the brick with BID=0 is 3, and the number of basic blocks in the horizontal direction of all tiles is 6, so the coordinates of the lower right boundary are (3,3).

[0126] The coordinates of the upper left boundary of the brick with BID=1 in the tile corresponding to tile ID=0 are (0,3). The number of basic block rows of the brick with BID=1 is 3, and the number of basic blocks in the horizontal direction of all tiles is 6, so the coordinates of the lower right boundary are (6,6).

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

[0128] The coordinates of the upper left boundary of the brick with BID=3 in the tile corresponding to tile ID=2 are (12,0). The number of basic block rows of the brick with BID=3 is 2, so the coordinates of the lower right boundary are (18,2).

[0129] The coordinates of the upper left boundary of the brick with BID=4 in the tile corresponding to tile ID=2 are (12,2). The number of basic block rows of the brick with BID=4 is 4, so the coordinates of the lower right boundary are (18,6).

[0130] The coordinates of the upper left boundary of the brick with BID=5 in the tile corresponding to tile ID=3 are (0,6). The number of basic block rows of the brick with BID=5 is 2, so the coordinates of the lower right boundary are (6,8).

[0131] The coordinates of the upper left boundary of the brick with BID=6 in the tile corresponding to tile ID=3 are (0,8). The number of basic block rows of the brick with BID=6 is 2, so the coordinates of the lower right boundary are (6,10).

[0132] The coordinates of the upper left boundary of the brick with BID=7 in the tile corresponding to tile ID=3 are (0,10). The number of basic block rows of the brick with BID=7 is 2, so the coordinates of the lower right boundary are (6,12).

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

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

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

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

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

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

[0139] Next, identify the bricks contained in each slice. For slice 0, slice_address is 0 and num_bricks_in_slice_minus1 is 0, so slice 0 is composed 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, slice_address is 2 and num_bricks_in_slice_minus1 is 0, so 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 to 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 to 13 (=slice_address+num_bricks_in_slice_minus1).

[0144] Also, 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 coded as entry_point_offset_minus1[j-1]. The number of such entries is (the number of basic block rows in the slice to be processed - 1).

[0145] For slice 0, the number of basic block rows of the brick with BID=0 that constitutes 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 brick with BID=1 that constitutes 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 brick with BID=2 that constitutes 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 bricks with BID=3 to 10 that constitute slice 3 is 2+4+2+2+2+6+6+6=30, and the range of j is 0 to 28.

[0146] For slice 4, the total number of basic block rows of the bricks with BID=11 to 13 that make up slice 4 is 3+3+6=12, so the range of j is 0 to 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 past. Since the start position of the data for each basic block row is known, parallel decoding can be performed for each basic block row. The segmentation information derived by the separation decoding unit 202 is sent to the image reproduction unit 205, and is used in step S404 to identify the position of the processing target within the input image.

[0148] In step S402, the decoding unit 203 reproduces the quantized coefficients and prediction information by decoding the coded data separated by the separate decoding unit 202. In step S403, the inverse quantization and inverse transform unit 204 performs inverse quantization on the input quantized coefficients to generate transform coefficients, and performs inverse orthogonal transform on the generated transform coefficients to reproduce the prediction errors.

[0149] In step S404, the image reproduction unit 205 generates a predicted image by appropriately referencing the frame memory 206 based on the prediction information input from the decoding unit 203. The image reproduction 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 reproduction unit 205 then identifies the positions of the tiles, bricks, and slices in the input image based on the partition information input from the separation decoding unit 202, synthesizes the reconstructed image at those positions, and outputs (stores) the image to 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 the result of this determination is that all basic blocks of the input image have been decoded, the process proceeds to step S406. On the other hand, if there are basic blocks in the input image that have not yet been decoded, the process proceeds to step S402, where the decoding process is performed on the basic blocks that have not yet been decoded.

[0151] In step S406, the in-loop filter unit 207 performs in-loop filtering on the reconstructed image read from the frame memory 206, and outputs (stores) the image that has undergone in-loop filtering to the frame memory 206.

[0152] In this way, according to this embodiment, it is possible to decode an input image from a "bitstream that does not include information indicating how many pieces of information indicating the starting positions of basic block rows that a brick has are encoded" generated by the image encoding device according to the first embodiment.

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

[0154] [Third embodiment] 1 and 2 may be implemented by hardware, or some of them may be implemented by software. In the latter case, the functional units except for the frame memory 108 and the frame memory 206 may be implemented by software (computer program). A computer device capable of executing such a computer program can be applied to the above-mentioned image encoding device and image decoding device.

[0155] An example of the hardware configuration of a computer device applicable to the above image encoding device and image decoding device will be described using the block diagram of Fig. 5. Note that the hardware configuration shown in Fig. 5 is merely an example of the hardware configuration of a computer device applicable to the above image encoding device and image decoding device, and can be changed / modified as appropriate.

[0156] The CPU 501 executes various processes using computer programs and data stored in the RAM 502 and the ROM 503. As a result, the CPU 501 controls the operation of the entire computer device, and also executes or controls the processes described above as being performed by the image encoding device and the image decoding device. In other words, the CPU 501 can function as each functional unit (except for the frame memory 108 and the frame memory 206) shown in Figures 1 and 2.

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

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

[0159] Display unit 505 is configured with a liquid crystal screen, a touch panel screen, or the like, and can display the processing results of CPU 501 as images, text, etc. Note that display unit 505 may also be a device such as a projector that projects images and text.

[0160] The external storage device 506 is a large-capacity information storage device such as a hard disk drive, etc. The external storage device 506 stores an operating system (OS), computer programs and data for causing the CPU 501 to execute or control the processes described above as those performed by the image encoding device and image decoding device.

[0161] The computer programs stored in the external storage device 506 include computer programs for causing the CPU 501 to execute or control the functions of each functional unit in Figures 1 and 2 except for the frame memory 108 and the frame memory 206. The data stored in the external storage device 506 also includes the information described above as known information, 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 under the control of the CPU 501 and are then processed by the CPU 501 .

[0163] The frame memory 108 included in the image encoding device in FIG. 1 and the frame memory 206 included in the image encoding device in FIG. 2 can be implemented using a memory device such as the RAM 502 or the external storage device 506 described above.

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

[0165] Note that the specific numerical values ​​used in the above description are used for the purpose of providing a specific description, and are not intended to limit the above-described embodiments to these numerical values. Furthermore, some or all of the above-described embodiments may be combined as appropriate. Furthermore, some or all of the above-described embodiments may be selectively used.

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

[0167] The invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the spirit and scope of the invention. Accordingly, the following claims are appended to apprise the public of the scope of the invention. [Explanation of symbols]

[0168] 102: Image division unit 103: Block division unit 104: Prediction unit 105: Transformation and quantization unit 106: Inverse quantization and inverse transformation unit 107: Image reproduction unit 108: Frame memory 109: In-loop filter unit 110: Encoding unit 111: Integrated encoding unit

Claims

1. 1. An image decoding device that decodes an image including a rectangular area including one or more block rows each consisting of a plurality of blocks from a bitstream obtained by encoding the image, the image comprising: decoding means for decoding a first flag related to enabling parallel processing, decoding a second flag from a picture parameter set of the bitstream indicating whether a first mode in which slices are rectangular or a second mode in which slices can have a shape different from a rectangle is used, decoding first information corresponding to the number of blocks in the vertical direction of a rectangular area in the image from the picture parameter set, decoding second information corresponding to the number of rectangular areas included in a slice in the image from a slice header of the bitstream, and decoding an address of a slice from the slice header when the image includes a plurality of rectangular areas and the second flag indicates that the second mode is used; an identification means, when the value of the first flag is 1 and the second flag indicates that the second mode is to be used, for identifying the number of syntax elements used to identify the start position of coded data of a block row for the slice, based on an address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular area in the image, and the second information indicating the number of rectangular areas included in the slice in the image; Equipped with a size of each of the plurality of blocks forming the block row is determined from third information decoded from a sequence parameter set in the bitstream, and the number of the syntax elements specified by the specifying means is included in the slice header of the bitstream; Each of the blocks forming the block row corresponds to a coding tree unit (CTU).

1. An image decoding device comprising:

2. 2. The image decoding device according to claim 1, wherein the first flag is an entropy_coding_sync_enabled_flag.

3. 2. The image decoding device according to claim 1, wherein the second flag is a rect_slice_flag.

4. 2. The image decoding device according to claim 1, wherein the syntax element is entry_point_offset_minus1.

5. The image decoding device according to claim 1 , wherein information about the number of syntax elements is not signaled in the bitstream.

6. 2. The image decoding device according to claim 1, wherein the size of each of the plurality of blocks is derived by arithmetically shifting 1 to the left by a value obtained by adding a predetermined value to the third information.

7. 2. The image decoding device according to claim 1, wherein each of the plurality of blocks forming the block row can be divided into smaller blocks.

8. 2. The image decoding device according to claim 1, wherein each of the plurality of blocks can have a size of 64x64.

9. 2. The image decoding device according to claim 1, wherein fourth information corresponding to a width of the image is decoded from the bitstream.

10. 1. An image decoding method for decoding an image including a rectangular area including one or more block rows each including a plurality of blocks from a bitstream obtained by encoding the image, the method comprising: a decoding step of decoding a first flag related to enabling parallel processing, decoding a second flag from a picture parameter set of the bitstream indicating whether a first mode in which slices are rectangular or a second mode in which slices can have shapes other than rectangular is used, decoding first information corresponding to the number of blocks in the vertical direction of rectangular areas in the image from the picture parameter set, decoding second information corresponding to the number of rectangular areas included in a slice in the image from a slice header of the bitstream, and decoding an address of a slice from the slice header when the image includes multiple rectangular areas and the second flag indicates that the second mode is used; an identifying step, when the value of the first flag is 1 and the second flag indicates that the second mode is to be used, of identifying the number of syntax elements used to identify the start position of coded data of a block row for the slice, based on an address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular area in the image, and the second information indicating the number of rectangular areas included in the slice in the image; and a size of each of the plurality of blocks forming the block row is determined from third information decoded from a sequence parameter set in the bitstream, and the number of the syntax elements specified in the specifying step is included in the slice header of the bitstream; Each of the blocks forming the block row corresponds to a coding tree unit (CTU).

1. An image decoding method comprising:

11. An image encoding device that encodes an image including a rectangular area including one or more block rows each including a plurality of blocks, encoding means for encoding a first flag related to enabling parallel processing, encoding a second flag indicating whether a first mode in which slices are rectangular or a second mode in which slices can have a shape different from a rectangle is used into a picture parameter set of a bitstream, encoding first information corresponding to the number of blocks in the vertical direction of a rectangular area in the image into the picture parameter set, encoding second information indicating the number of rectangular areas included in a slice of the image into a slice header of the bitstream, and encoding an address of a slice into the slice header when the image includes a plurality of rectangular areas and the second flag indicates that the second mode is used; an identification means, when the value of the first flag is 1 and the second flag indicates that the second mode is to be used, for identifying the number of syntax elements used to identify the start position of coded data of a block row for the slice, based on an address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular area in the image, and the second information indicating the number of rectangular areas included in the slice in the image; Equipped with third information for determining a size of each of the plurality of blocks forming the block row is coded in a sequence parameter set in the bitstream, and the number of the syntax elements specified by the specifying means is included in the slice header of the bitstream; Each of the blocks forming the block row corresponds to a coding tree unit (CTU). An image encoding device comprising:

12. 1. An image coding method for coding an image including a rectangular area including one or more block rows each including a plurality of blocks, comprising: an encoding process for encoding a first flag related to enabling parallel processing, encoding a second flag indicating whether a first mode in which slices are rectangular or a second mode in which slices can have a shape different from a rectangle is used into a picture parameter set of a bitstream, encoding first information corresponding to the number of blocks in the vertical direction of a rectangular area in the image into the picture parameter set, encoding second information indicating the number of rectangular areas included in a slice of the image into a slice header of the bitstream, and encoding an address of a slice into the slice header when the image includes a plurality of rectangular areas and the second flag indicates that the second mode is used; an identifying step, when the value of the first flag is 1 and the second flag indicates that the second mode is to be used, of identifying the number of syntax elements used to identify the start position of coded data of a block row for the slice, based on an address of the slice, the first information corresponding to the number of blocks in the vertical direction of the rectangular area in the image, and the second information indicating the number of rectangular areas included in the slice in the image; and third information for determining the size of each of the plurality of blocks forming the block row is coded in a sequence parameter set in the bitstream, and the number of the syntax elements specified in the specifying step is included in the slice header of the bitstream; Each of the blocks forming the block row corresponds to a coding tree unit (CTU).

1. An image coding method comprising:

13. A computer program for causing a computer to execute the image decoding method according to claim 10.

14. A computer program for causing a computer to execute the image coding method according to claim 12.

Images