Video encoding device, video decoding device, and integrated circuit

Abstract

To solve the problem in which: HEVC are designed for tiles, wave front parallel processing, and slices; however, the uses of these tools are not exclusive to each other, which complicates processing.SOLUTION: A moving image decoding apparatus comprises a decoding unit that decodes a flag indicating whether synchronization processing on CABAC is performed, a one-bit syntax element, and a bit string for byte alignment. When the value of the flag is 1, the bit string for byte alignment is decoded on the basis of whether a CTU is at the last of a tile group or a CTU is at the last of a CTU row.SELECTED DRAWING: Figure 31

Description

Technical Field

[0001] Embodiments of the present invention relate to a moving image decoding apparatus, a moving image encoding apparatus, and an integrated circuit.

Background Art

[0002] In order to efficiently transmit or record a moving image, a moving image encoding apparatus that generates encoded data by encoding the moving image, and a moving image decoding apparatus that generates a decoded image by decoding the encoded data are used.

[0003] Specific moving image encoding methods include, for example, H.264 / AVC and HEVC (High-Efficiency Video Coding).

[0004] In such a moving image encoding method, an image (picture) constituting the moving image is managed by a hierarchical structure including a slice obtained by dividing the image, a coding tree unit (CTU: Coding Tree Unit) obtained by dividing the slice, a coding unit (sometimes called a coding unit (CU)) obtained by dividing the coding tree unit, and a transform unit (TU: Transform Unit) obtained by dividing the coding unit, and is encoded / decoded for each CU.

[0005] Also, in such a moving image encoding method, usually, a predicted image is generated based on a locally decoded image obtained by notifying an input image, and a prediction error (sometimes called a "difference image" or a "residual image") obtained by subtracting the predicted image from the input image (original image) is encoded. Examples of the method for generating the predicted image include inter-picture prediction (inter prediction) and intra-picture prediction (intra prediction).

[0006] Furthermore, methods for dividing the screen into multiple units for transmission include slicing, CTU row (wavefront parallel), and tiling. These will be referred to as segments below.

[0007] Furthermore, Non-Patent Document 1 is cited as a recent technology for video encoding and decoding, Non-Patent Document 2 discloses tile group technology, and Non-Patent Document 3 discloses specific syntax examples for tile groups. Non-Patent Document 4 discloses rectangular tile groups called rectangle tiles.

[0008] Furthermore, a wavefront parallelization technique for a substream (hereinafter referred to as a tile group) formed by combining multiple tiles into one is disclosed in Non-Patent Document 5. [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] "Versatile Video Coding (Draft 4)", JVET-M1001-v6, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 2019-03-09 [Non-Patent Document 2] "Tile groups for VVC", JVET-L0415, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 2018-09-25 [Non-Patent Document 3] "Spec text for the agreed starting point on slicing and tiling", JVET-L0686, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 2018-10-12 [Non-Patent Document 4] "AHG12: On Tile Grouping", JVET-M0853, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 2019-01-12 [Non-Patent Document 5] "AHG12: Wavefront processing in a tile group", JVET-M0070-v1, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 2019-01-03 [Overview of the project] [Problems that the invention aims to solve]

[0010] HEVC supports tiling, which divides a picture into rectangles; wavefront parallel processing (WPP), which divides it into rows of CTUs; and slicing, which divides it into sets of consecutive CTUs. However, a challenge exists in that the use of tiles, wavefronts, and slices is not mutually exclusive for a single region, leading to complex processing. Furthermore, since it does not support tile groups as described in Non-Patent Documents 2 and 3, when using tile or wavefront parallelization, it is only possible to encode the entry point indicating the starting position of the encoded data on a picture-by-picture basis, and it is not possible to encode on a group basis by dividing the screen.

[0011] While the tiles described in Non-Patent Documents 2 and 3 allow for notification of tiles in groups, they have limitations, such as not supporting wavefront parallel processing for high efficiency and high parallelism, or slicing to enable segment delimiters at arbitrary positions other than rectangles. Furthermore, it is not possible to switch segment types on a per-tile group basis.

[0012] Furthermore, the tiles described in Non-Patent Documents 2 and 3 define the tile division method on a picture-by-picture basis, making it impossible to change the width or height of the tiles on a picture-group basis.

[0013] Furthermore, while Non-Patent Document 5 discloses a method for wavefront parallelization within a tile group, it does not disclose the case where a tile group is defined in a PPS, as described in Non-Patent Document 1, and therefore, wavefront parallelization suitable for defining a tile group in a PPS cannot be achieved.

[0014] Therefore, the present invention has been made in view of the above problems, and its purpose is to simplify and streamline encoding and decoding processes by exclusively using tiles, wavefronts, and slices within a tile group. It also involves changing the width and height of tiles on a picture group basis. [Means for solving the problem]

[0015] A video decoding device according to one aspect of the present invention comprises a decoding unit that decodes a flag indicating whether or not Context-adaptive binary arithmetic coding (CABAC) synchronization processing is performed, a 1-bit syntax element, and a bit sequence for byte alignment, wherein if the value of the flag is 1, the bit sequence for byte alignment is decoded based on whether or not it is the last CTU in the tile group and whether or not it is the last CTU in the CTU row. Furthermore, a video decoding device according to one aspect of the present invention is a video decoding device that decodes encoded data of a tile group composed of one or more segments, in which a picture is divided into one or more rectangular regions, comprising a header decoding unit that decodes the number of tiles in the target tile group indicating whether the segments in the target tile group are rectangular tiles, CTU rows with a height of 1 CTU, or slices in units of CTU, a WPP enabled flag, and a slice enabled flag from the tile group header, wherein the header decoding unit decodes only those in a single tile group that have two or more tiles, a WPP enabled flag of 1, or a slice enabled flag of 1. [Brief explanation of the drawing]

[0016] [Figure 1] This is a schematic diagram showing the configuration of the image transmission system according to this embodiment. [Figure 2] This figure shows the configuration of a transmitting device equipped with a video encoding device and a receiving device equipped with a video decoding device according to this embodiment. (a) shows a transmitting device equipped with a video encoding device, and (b) shows a receiving device equipped with a video decoding device. [Figure 3] This figure shows the configuration of a recording device equipped with a video encoding device and a playback device equipped with a video decoding device according to this embodiment. (a) shows a recording device equipped with a video encoding device, and (b) shows a playback device equipped with a video decoding device. [Figure 4] This diagram shows the hierarchical structure of the encoded stream data. [Figure 5]It is a diagram showing an example of picture division. [Figure 6] It is a diagram explaining a tile group. [Figure 7] It is a flowchart explaining the encoding or decoding of the tile group of this embodiment. [Figure 8] It is a diagram explaining the tile group of this embodiment. [Figure 9] It is a schematic diagram showing the configuration of a moving image decoding device. [Figure 10] It is a flowchart explaining the schematic operation of a moving image decoding device. [Figure 11] It is a syntax table regarding tile information and the like. [Figure 12] It is a diagram showing the syntax configuration of the tile group of this embodiment. [Figure 13] It is a diagram explaining the tile group of this embodiment. [Figure 14] It is a diagram showing the syntax configuration of the picture parameter set of this embodiment. [Figure 15] It is an example of using different types of segments in units of tile groups (segment groups). [Figure 16] It is a diagram explaining the exclusive configuration of a tile segment and a CTU row segment. [Figure 17] It is a diagram explaining the operation of a header decoding unit in an exclusive configuration of a tile and a wavefront. [Figure 18] It is a diagram showing the syntax configuration of the tile group of this embodiment. [Figure 19] It is a diagram showing the syntax configuration of the tile group of this embodiment. [Figure 20] It is a diagram explaining the exclusive configuration of a tile segment and a slice segment. [Figure 21] It is a diagram showing the syntax configuration of the tile group of this embodiment. [Figure 22] It is a diagram explaining the exclusive configuration of a tile segment, a CTU row segment, and a slice segment. [Figure 23]This figure shows the syntax configuration of the tile group in this embodiment. [Figure 24] This is a block diagram showing the configuration of a video encoding device. [Figure 25] This figure shows the syntax configuration of the tile group in this embodiment. [Figure 26] This is a flowchart illustrating the general operation of a video decoding device. [Figure 27] This diagram illustrates tile groups, including rectangular tile groups. [Figure 28] This figure shows the syntax configuration of a parameter set in one embodiment of this model. [Figure 29] This diagram shows the syntax of a tile group header that includes a rectangular tile group. [Figure 30] This figure shows the relationship between a tile group and the tile-based CTU scan order of wavefront processing (CTU row segments) in one embodiment of this model. [Figure 31] This figure shows the syntax configuration of a tile group header in one embodiment of this model. [Figure 32] This figure shows the relationship between a tile group and the tile-based CTU scan order of wavefront processing (CTU row segments) in one embodiment of this model. [Figure 33] This figure shows the syntax configuration of a tile group header in one embodiment of this model. [Figure 34] This figure shows the syntax configuration of a tile group header in one embodiment of this model. [Figure 35] This is a diagram illustrating the operation of the header encoding unit 1110 and the header decoding unit 3020, which have an exclusive configuration of tiles and wavefronts. [Figure 36]This diagram shows the relationship between a tile group and wavefront processing (CTU row segment) in one embodiment of this product. TileGroup1 and 3 have a WPP enabled flag of 0 and are in tile-based CTU scan order, while TileGroup0, 2, and 4 have a WPP enabled flag of 1 and are in tile-group-based CTU scan order. [Figure 37] This is a flowchart illustrating the method for deriving the tile-based CTU scan order. [Figure 38] This is an example flowchart for deriving a CTU scan of an entire picture. (a) shows the case where the switching unit is a tile group, and (b) shows the case where the switching unit is a picture. [Figure 39] This figure shows the syntax configuration of a tile group header in one embodiment of this model. [Figure 40] This diagram shows the relationship between a tile group and wavefront processing (CTU row segment) in one embodiment of this product. [Figure 41] This figure shows the syntax configuration of a tile group header in one embodiment of this model. [Figure 42] This figure shows the syntax configuration of a picture parameter set in one embodiment of this product. [Modes for carrying out the invention]

[0017] (First embodiment) Embodiments of the present invention will be described below with reference to the drawings.

[0018] Figure 1 is a schematic diagram showing the configuration of the image transmission system 1 according to this embodiment.

[0019] Image transmission system 1 is a system that transmits an encoded stream containing an image to be encoded, decodes the transmitted encoded stream, and displays the image. Image transmission system 1 consists of a video encoding device (image encoding device) 11, a network 21, a video decoding device (image decoding device) 31, and a video display device (image display device) 41.

[0020] The video encoding device 11 receives image T as input.

[0021] Network 21 transmits the encoded stream Te generated by the video encoding device 11 to the video decoding device 31. Network 21 is the Internet, a wide area network (WAN), a local area network (LAN), or a combination thereof. Network 21 is not necessarily limited to a bidirectional communication network; it may also be a unidirectional communication network that transmits broadcast waves such as terrestrial digital broadcasting or satellite broadcasting. Furthermore, network 21 may be replaced by a storage medium that records the encoded stream Te, such as a DVD (Digital Versatile Disc: registered trademark) or a BD (Blu-ray Disc: registered trademark).

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

[0023] The video display device 41 displays all or part of one or more decoded images Td generated by the video decoding device 31. The video display device 41 includes a display device such as a liquid crystal display or an organic EL (electro-luminescence) display. Examples of display forms include stationary, mobile, and HMD (head-mounted display). Furthermore, if the video decoding device 31 has high processing power, it displays high-quality images, and if it has lower processing power, it displays images that do not require high processing power or display power.

[0024] <operators> The operators used in this specification are listed below.

[0025] >> is a right bit shift, << is a left bit shift, & is a bitwise AND, | is a bitwise OR, |= is the OR assignment operator, and || represents logical OR.

[0026] x?y:z is a ternary operator that takes y when x is true (non-zero) and z when x is false (0).

[0027] Clip3(a, b, c) is a function that clips c to a value between a and b, returning a if c < a, b if c > b, and c otherwise (where a <= b).

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

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

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

[0031] ceil(a) is a function that returns the smallest integer greater than or equal to a.

[0032] a / d represents the division of a by d (truncating the fractional part).

[0033] <Structure of Encoded Stream Te>[[]]END]] Prior to the detailed description of the moving image encoding device 11 and the moving image decoding device 31 according to this embodiment, the data structure of the encoded stream Te generated by the moving image encoding device 11 and decoded by the moving image decoding device 31 will be described.

[0034] Figure 4 is a diagram showing the hierarchical structure of data in the encoded stream Te. The encoded stream Te illustratively includes a sequence and a plurality of pictures constituting the sequence. Figures 4(a) to (f) respectively show an encoded video sequence that defines the sequence SEQ, an encoded picture that defines the picture PICT, an encoded tile group that defines a tile group, a segment (e.g., an encoded tile, a CTU row, a slice) that defines a tile, an encoded tree unit included in the segment, and an encoded unit included in the encoded tree unit.

[0035] (Encoded video sequence) In an encoded video sequence, a set of data that the video decoding device 31 references to decode the sequence SEQ to be processed is defined. As shown in Figure 4(a), the sequence SEQ includes a sequence parameter set (SPS), a picture parameter set (PPS), a picture (PICT), and supplemental enhancement information (SEI).

[0036] The Sequence Parameter Set (SPS) defines a set of encoding parameters that the video decoding device 31 references to decode the target sequence. For example, it defines information about the width, height, and shape of the picture, as well as information about whether the decoding tool is on or off. Multiple SPSs may exist. In that case, one of the SPSs is selected from the PPS.

[0037] The Picture Parameter Set (PPS) defines a set of encoding parameters that the video decoding device 31 references to decode each picture in the target sequence. For example, it includes information about the number of tiles, width, and height that make up the picture. Multiple PPSs may exist. In that case, one of the multiple PPSs is selected for each picture in the target sequence.

[0038] (Encoded picture) In the encoded picture, a set of data that the video decoding device 31 references to decode the picture PICT to be processed is defined. As shown in Figure 4(b), the picture PICT includes tile groups 0 to NTG-1 (where NTG is the total number of tiles included in the picture PICT).

[0039] (Segment, tile group) A segment is a unit used to divide and transmit a picture, and in encoded data, it is encoded and decoded as a byte-aligned bit sequence.

[0040] Tiles, CTU rows, and slices are segments used to divide and transmit a picture, respectively.

[0041] A segment group (tile group) is a group of segments, which are collections of CTUs, and can also be called a segment group. Each segment is a unit with the following characteristics and can be decoded in parallel. • On the screen, it corresponds to the set of CTUs. • Encoded data is aligned byte by byte. • Perform CABAC initialization at the beginning of the segment. • Predictions can be restricted between segments within the same picture (referencing other segments can be restricted). Prediction limitations include restrictions such as not performing intra-predictions using images of tiles other than the target tile when the segment is a tile, or similarly, not performing intra-predictions using images of slices other than the target slice when the segment is a slice.

[0042] If the segment is WPP, intra-prediction using images of CTU rows different from the target CTU row is partially permitted. Specifically, in WPP, the CTU rows above the target CTU row can be referenced. However, CTUs that exceed the horizontal coordinate of the target CTU cannot be referenced in the CTU rows above the target CTU row. Reference can also be turned on or off using a flag.

[0043] In tile groups (segment groups), encoding efficiency is improved by encoding a common header for each segment only once within the segment.

[0044] Figure 5 shows a picture divided into four tile groups, TileGr0 to TileGr3. A tile group can be further divided into one or more segments. The numbers after TileGr (0-3 in the figure) are tile group identifiers, assigned in raster scan order from the top left to the bottom right of the picture. Each tile group has a unique tile group identifier, which increases monotonically in the scan order.

[0045] Figure 6(a) illustrates tile addresses when the segment is a tile. The number after "Tile" in the figure is the address of the tile in the picture (TileAddrInPic). TileAddrInPic is set in raster scan order from the top left to the bottom right of the picture. In the figure, the tile group TileGr0 contains tiles Tile0, Tile1, Tile4, and Tile5. TileGr1 contains Tile2, Tile3, Tile6, and Tile7. TileGr2 contains Tile8 and Tile9. TileGr3 contains Tile10 and Tile11. When using TileAddrInPic as the tile address, the tile addresses within a tile group are not consecutive.

[0046] Figure 6(b) is another diagram illustrating tile addresses when the segment is a tile. The number after "Tile" in the figure is the address of the tile within the tile group (TileAddrInTG). TileAddrInTG is set in raster scan order from the top left to the bottom right of the tile group. In the figure, tile group TileGr0 contains tiles Tile0, Tile1, Tile2, and Tile3. TileGr1 contains Tile4, Tile5, Tile6, and Tile7. TileGr2 contains Tile8 and Tile9. TileGr3 contains Tile10 and Tile11. When using TileAddrInTG as the tile address, the tile addresses are consecutive within the tile group.

[0047] (Encoded tile group) An encoded tile group defines a set of data that the video decoding device 31 references to decode the tile group to be processed. As shown in Figure 4(c), the tile group includes a tile group header and tile group data. Furthermore, trailing data for byte alignment (rbsp_tile_group_trailing_bits) may be included after the tile group data.

[0048] Figure 7 is a flowchart illustrating the encoding or decoding of tile groups in this embodiment. The components that perform each step are shown in Figures 9 and 24 and will be described later.

[0049] S2001: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes the tile group header.

[0050] S2002: The CT information encoding unit 1111 or the CT information decoding unit 3021 encodes or decodes the tile group data.

[0051] S2003: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes the trailing data. The trailing data may include a bit sequence for byte alignment. It may also include a bit sequence indicating a delimiter before the byte alignment.

[0052] The tile group header contains a set of encoding parameters for determining the decoding method for the target tile group, as well as parameters common to the tiles in the tile group. Tile group data consists of encoded data for one or more segments included in the tile group. A segment consists of CTUs. If a segment is a tile, the tile group data consists of one or more encoded tiles.

[0053] (Tile group header) The tile group header may include tile group type information (tile_group_type).

[0054] The tile group types that can be specified by the tile group type specification information include: (1) I-tile groups that use only intra-prediction during encoding; (2) P-tile groups that use unidirectional or intra-prediction during encoding; and (3) B-tile groups that use unidirectional, bidirectional, or intra-prediction during encoding. Note that inter-prediction is not limited to single or bidirectional prediction, and prediction images may be generated using more reference pictures. Hereinafter, when referring to P-tile groups and B-tile groups, it refers to tile groups that include blocks on which inter-prediction can be used.

[0055] The tile group header may also include a reference to the picture parameter set PPS (tile_group_pic_parameter_set_id).

[0056] (Encoded tile) In an encoded tile, a set of data is defined that the video decoding device 31 references to decode the tile to be processed. As shown in Figure 4(d), the tile includes a CTU. A CTU is a fixed-size (e.g., 128x128) block that makes up the tile, and is sometimes called a Largest Coding Unit (LCU).

[0057] (Tiles, WPP, slices) Figure 8(a) shows an example of dividing the tile group TileGr0 into multiple tiles Tile0 to Tile3 (thick solid rectangles). A tile is a rectangular segment composed of one or more CTUs. The address of each CTU (CTU address ctbAddrTs in tile scan order) is set from the top left to the bottom right of each tile in raster scan order.

[0058] Figure 8(b) shows an example of dividing a tile group into multiple CTU rows. As shown in the figure, a CTU row is a segment composed of a collection of CTUs, each with a height equal to the CTU height and a width equal to the segment width. As will be described later, the segments of a CTU row are used in WPP.

[0059] Figure 8(c) shows an example of dividing a tile group into a set of consecutive CTUs. As shown in the figure, a slice is a segment composed of a set of CTUs.

[0060] (Code tree unit) Figure 4(e) defines the set of data that the video decoding device 31 references to decode the CTU to be processed. The CTU is divided into coding units CU, which are the basic units of encoding processing, by recursive quad tree partitioning (QT), binary tree partitioning (BT), or ternary tree partitioning (TT). BT and TT partitioning together are called multi-tree partitioning (MT). The nodes of the tree structure obtained by recursive quad tree partitioning are called coding nodes. The intermediate nodes of quad trees, binary trees, and ternary trees are coding nodes, and the CTU itself is defined as the highest-level coding node.

[0061] (Encoding Unit) As shown in Figure 4(f), a set of data that the video decoding device 31 references to decode the encoding unit to be processed is defined. Specifically, the CU consists of a CU header, prediction parameters, transformation parameters, quantization transformation coefficients, etc. The CU header defines the prediction mode, etc.

[0062] (Configuration of the video decoding device) The configuration of the video decoding device 31 (Figure 9) according to this embodiment will be described below.

[0063] The video decoding device 31 includes a parameter decoding unit (predictive image decoding device) 302, a loop filter 305, a reference picture memory 306, a prediction parameter memory 307, a prediction image generation unit (predictive image generation device) 308, an inverse quantization / inverse transform unit 311, and an adder 312. Note that, in accordance with the video encoding device 11 described later, there is also a configuration in the video decoding device 31 that does not include the loop filter 305. The parameter decoding unit 302 further includes an entropy decoding unit 301, a header decoding unit 3020, a CT information decoding unit 3021, and a CU decoding unit 3022, and the CU decoding unit 3022 further includes a TU decoding unit 3024.

[0064] (Decryption module) The following describes the general operation of each module. The parameter decoding unit 302 performs decoding processing of parameters such as header information, partitioning information, prediction information, and quantization conversion coefficients.

[0065] The entropy decoding unit 301 decodes syntax elements from binary data. More specifically, the entropy decoding unit 301 decodes syntax elements from encoded data using an entropy coding scheme such as CABAC, based on syntax elements input from the supplier, and returns them to the supplier. In the example shown below, the suppliers of syntax elements are the CT information decoding unit 3021 and the CU decoding unit 3022.

[0066] (Basic Flow) Figure 10 is a flowchart illustrating the general operation of the video decoding device 31.

[0067] (S1100: Parameter set information decoding) The header decoding unit 3020 decodes parameter set information such as SPS and PPS, as well as tile information, from the encoded data.

[0068] Information regarding the number of tile divisions and size is called tile information. The tile width ColWidth and height RowHeight are derived using the picture width PicWidthInCtbsY and height PicHeightInCtbsY, and the number of horizontal and vertical tiles within the picture NumTileColumns and NumTileRows. The units of ColWidth, RowHeight, PicWidthInCtbsY, and PicHeightInCtbsY are CTU. The header decoding unit 3020 derives the following using the picture's pixel-level width pic_width_in_luma_samples, height pic_height_in_luma_samples, and the value log2_ctu_size_minus2, which is the logarithm of the CTU size minus 2. pic_width_in_luma_samples, pic_height_in_luma_samples, and log2_ctu_size_minus2 are notified (signed) by sequence_parameter_set_rbsp() (referred to as SPS) in Figure 11(a). Hereinafter, "notifying" certain information means including certain information in the encoded data (bitstream), the video encoding device encodes that information, and the video decoding device decodes that information.

[0069] ctuWidth = ctuHeight = 1<<(log2_ctu_size_minus2+2) PicWidthInCtbsY = Ceil(pic_width_in_luma_samples / ctuWidth) PicHeightInCtbsY = Ceil(pic_height_in_luma_samples / ctuHeight) Division ( / ) here is performed with decimal precision.

[0070] The number of horizontal and vertical tiles in a picture, NumTileColumns and NumTileRows, are notified by PPS (pic_parameter_set_rbsp()) in Figure 11(b). For example, the tile information may be single_tile_in_pic_flag, num_tile_columns_minus1, num_tile_rows_minus1, uniform_tile_spacing_flag, tile_column_width_minus1[i], and tile_row_height_minus1[i]. Here, single_tile_in_pic_flag is a flag indicating whether or not the picture contains multiple tiles; if it is 1, there is one tile in the picture, and the picture is equivalent to a tile. If it is 0, the picture contains multiple tiles. num_tile_columns_minus1 and num_tile_rows_minus1 are the number of horizontal and vertical tiles in the picture, NumTileColumns and NumTileRows, respectively, minus 1. The `uniform_spacing_flag` flag indicates whether or not the picture is tiled as evenly as possible.

[0071] The header decoding unit 3020 derives the number of horizontal and vertical tiles in the picture, NumTileColumns and NumTileRows, and the total number of tiles in the picture, NumTilesInPic, as follows.

[0072] NumTileColumns = num_tile_columns_minus1+1 NumTileRows = num_tile_rows_minus1+1 NumTilesInPic = NumTileColumns*NumTileRows The header decoding unit 3020 may derive the tile size using the following formula.

[0073] for(m=0;m <NumTileColumns;m++) ColWidth[m] = (m + 1) * PicWidthInCtbsY / NumTileColumns - m * PicWidthInCtbsY / NumTileColumns for (n = 0; n < NumTileRows; n++) RowHeight[n] = (n + 1) * PicHeightInCtbsY / NumTileRows - n * PicHeightInCtbsY / NumTileRows When the value of uniform_spacing_flag is 0, the width and height of each tile of the picture are set individually. In the moving image encoding device, the width ColWidth[m] and height RowHeight[n] of each tile are encoded for each tile. The header decoding unit 3020 of the moving image decoding device decodes ColWidth[m] and RowHeight[n] for each tile as follows.

[0074] ColWidth[m] = tile_column_width_minus1[m] + 1 (0 <= m < NumTileColumns - 1) RowHeight[n] = tile_row_height_minus1[m] + 1 (0 <= n < NumTileRows - 1) ColWidth[NumTileColumns - 1] = PicWidthInCtbsY - sum_m(ColWidth[m]) RowHeight[NumTileRows - 1] = PicHeightInCtbsY - sum_n(RowHeight[n]) Here, sum_m(ColWidth[m]) represents the sum of ColWidth[m] (0 <= m < NumTileColumns - 1), and sum_n(RowHeight[n]) represents the sum of RowHeight[n] (0 <= n < NumTileRows - 1).

[0075] (S1200: Decoding of tile group information) The header decoding unit 3020 decodes the tile group header (tile group information) from the encoded data.

[0076] Figure 12(a) shows the syntax for the tile group header of an encoded tile group. The tile group header notifies tile_group_pic_parameter_set_id, tile_group_address, num_tiles_in_tile_group_minus1, tile_group_type, and entry_point(). tile_group_pic_parameter_set_id is the picture parameter set identifier pps_pic_parameter_set_id of the picture containing the tile group. tile_group_address is the tile address of the first tile in the tile group and is a value in the range of 0 to NumTilesInPic-1. The tile_group_address of tile groups contained in the same picture will have different values. num_tiles_in_tile_group_minus1+1 indicates the number of tiles in the tile group. tile_group_type indicates the encoding type of the tile group (I-tile group, P-tile group, B-tile group). entry_point() is the syntax for the entry point, and an example is shown in Figure 12(b).

[0077] The parameter decoding unit 302 first decodes tile_group_pic_parameter_set_id. Next, if the number of tiles in the tile group, NumTilesInPic, is greater than 1, it decodes tile_group_address and num_tiles_in_tile_group_minus1. Otherwise (NumTilesInPic==1), it sets tile_group_address and num_tiles_in_tile_group_minus1 to 0. Next, it decodes tile_group_type.

[0078] The parameter decoding unit 302 decodes offset_len_minus1 and NumEntryPoint entry points entry_point_offset_minus1[i] if the tile group contains multiple tiles (num_tiles_in_tile_group_minus1>0). If the segment is a tile, NumEntryPoint is set to num_tiles_in_tile_group_minus1. If there is only one tile in the tile group (num_tiles_in_tile_group_minus1=0), the parameter decoding unit 302 does not decode the entry points.

[0079] The entry point is the starting address of the segment in the encoded data (for example, the byte offset position with the starting point of the tile group header to which the target segment belongs or the starting point of the preceding segment as the zero point), or the starting address of each tile if the segment is a tile. entry_point_offset_minus1[i]+1 may also be the difference between the (i+1)th entry point and the i-th entry point in the encoded data. The 0th entry point is the starting address of the tile group header (the position of the starting point of the tile group header, i.e., the zero point) and is not notified. offset_len_minus1+1 is the number of bits representing entry_point_offset_minus1[i].

[0080] If we denote the byte-level offset position of the starting point on the encoded data of the tile group header to which the target segment belongs as firstByte[k], and the byte-level offset position of the segment end as lastByte[k], then we can derive it from entry_point_offset_minus1[i] as follows.

[0081] firstByte[k] = Σ(entry_point_offset_minus1[n-1]+1) Σ represents the sum from n=1 to k.

[0082] The video decoding device 31 then derives a decoded image for each CTU by repeating the processing from S1300 to S5000 for each CTU included in the target picture.

[0083] (S1300: CTU information decoding) The CT information decoding unit 3021 decodes the CTU from the encoded data. The CT (Coding Tree) information includes the division information of the coding tree.

[0084] Figure 12(c) shows an example of the syntax of tile group data for an encoded tile group. In tile group data, the CTU data coding_tree_unit() of the tile group is encoded or decoded, and a fixed segment termination bit end_of_tile_one_bit is encoded or decoded at the end of the segment.

[0085] The CT information decoding unit 3021, when the segment is a tile, decodes the fixed value end_of_tile_one_bit at the CTU at the end of the tile (bottom right of the tile) and decodes the bit sequence byte_alignment() for byte alignment. Note that decoding of byte_alignment() may be limited to cases where i is less than num_tiles_in_tile_group_minus1. In other words, for the last segment in a tile group (i == num_tiles_in_tile_group_minus1), decoding of byte_alignment() can be omitted because trailing data for byte alignment is decoded afterward.

[0086] The CT information decoding unit 3021 sets tileIdx to tile_group_address. tileIdx is the tile identifier, and tile_group_address is the tile address of the first tile in the tile group. To identify each tile in the tile group using tileIdx, the CT information decoding unit 3021 increments tileIdx by 1 each time a tile is processed.

[0087] The CT information decoding unit 3021 uses tileIdx and FirstCtbAddrTs[] to derive the CTU address ctbAddrTs for the tile scan order within the tile using the following formula. A tile scan is a scanning method in which processing proceeds sequentially from the top left to the bottom right of the tile.

[0088] ctbAddrTs = FirstCtbAddrTs[tileIdx] FirstCtbAddrTs[] is a table that translates tileIdx to the first CTU address of the tile, and is derived as follows:

[0089] for (ctbAddrTs=0,tileIdx=0,tileStartFlag=1; ctbAddrTs <PicSizeInCtbsY; ctbAddrTs++) { if (tileStartFlag) { FirstCtbAddrTs[tileIdx] = ctbAddrTs tileStartFlag = 0 } tileEndFlag = (ctbAddrTs==PicSizeInCtbsY-1) || (TileId[ctbAddrTs+1]!=TileId[ctbAddrTs]) if(tileEndFlag) { tileIdx++ tileStartFlag = 1 } } Here, TileId[] is a table that converts CTU addresses in tile scan order to tile identifiers. An example is shown below.

[0090] for (j=0,tileIdx=0; j<=num_tile_rows_minus1; j++) for (i=0; i<=num_tile_columns_minus1; i++,tileIdx++) for (y=RowBd[j]; y <RowBd[j+1]; y++) for (x=ColBd[i]; x <ColBd[i+1]; x++) TileId[CtbAddrRsToTs[y*PicWidthInCtbsY+x]] = TileIdx Here, RowBD[] and ColBD[] are tables that store the maximum vertical coordinates of each tile row and the maximum horizontal coordinates of each tile column, and are expressed in CTU units. An example is shown below.

[0091] For (RowBd[0]=0,j=0; j<=num_tile_rows_minus1; j++) RowBd[j+1] = RowBd[j]+RowHeight[j] For (ColBd[0]=0,i=0; i<=num_tile_columns_minus1; i++) ColBd[i+1] = ColBd[i]+ColWidth[i] (Method 1 for deriving the CTU scan order within a picture) Furthermore, CtbAddrRsToTs[] is a table that converts CTU addresses in raster scan order within a picture to CTU addresses in tile scan order. The CT information decoding unit 3021 may derive CtbAddrRsToTs[] by the following process. This derivation method corresponds to the CTU scan order when raster scanning is performed within a picture in tile order, and then raster scanning is performed within the tiles in CTU order. Note that CTU may also be called CTB. The CTU scan order may also be called the CTB scan order.

[0092] for (ctbAddrRs=0; ctbAddrRs <PicSizeInCtbsY; ctbAddrRs++) { tbX = ctbAddrRs%PicWidthInCtbsY tbY = ctbAddrRs / PicWidthInCtbsY for(i=0; i<=num_tile_columns_minus1; i++) if(tbX>=ColBd[i]) tileX = i for(j=0; j<=num_tile_rows_minus1; j++) if(tbY>=RowBd[j]) tileY = j CtbAddrRsToTs[ctbAddrRs] = 0 for(i=0; i <tileX; i++) CtbAddrRsToTs[ctbAddrRs] += RowHeight[tileY]*ColWidth[i] for(j=0; j <tileY; j++) CtbAddrRsToTs[ctbAddrRs] += PicWidthInCtbsY*RowHeight[j] CtbAddrRsToTs[ctbAddrRs] += (tbY-RowBd[tileY])*ColWidth[tileX]+tbX-ColBd[tileX] } (Method 0 for deriving the CTU scan order within a picture) The CT information decoding unit 3021 uses ctbAddrTs and CtbAddrTsToRs[] to derive the CTU address ctbAddrRs in raster scan order using the following formula.

[0093] ctbAddrRs = CtbAddrTsToRs[ctbAddrTs] CtbAddrTsToRs[] is a table that converts CTU addresses in tile scan order to CTU addresses in raster scan order, and is derived as follows.

[0094] for (ctbAddrRs=0; ctbAddrRs <PicSizeInCtbsY; ctbAddrRs++) CtbAddrTsToRs[CtbAddrRsToTs[ctbAddrRs]] = ctbAddrRs The derivation of CtbAddrTsToRs[] and CtbAddrTsToRs[] is performed by the CT information encoding unit 1111 in the video encoding device 11. Alternatively, it may be performed by the header encoding unit 1110 and the header decoding unit 3020.

[0095] Alternatively, you can derive CtbAddrTsToRs[] first, and then use CtbAddrTsToRs[] to derive CtbAddrRsToTs[] using the following formula.

[0096] for (ctbAddrTs=0; ctbAddrTs <PicSizeInCtbsY; ctbAddrTs++) CtbAddrRsToTs[CtbAddrTsToRs[ctbAddrTs]] = ctbAddrTs The CT information decoding unit 3021 decodes each CTU within the tile in the order of the tile scan, and after decoding all CTUs is complete, it decodes the end_of_tile_one_bit.

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

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

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

[0100] (S1520: TU information decoding) The TU decoding unit 3024 decodes the QP update information (quantization correction value) and the quantization prediction error (residual_coding) from the encoded data if the TU contains a prediction error. The QP update information is the difference from the quantization parameter prediction value qPpred, which is the predicted value of the quantization parameter QP.

[0101] (S2000: Predictive image generation) The predictive image generation unit 308 generates a predictive image for each block included in the target CU based on the prediction information.

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

[0103] (S4000: Decoded image generation) The adder 312 generates a decoded image of the target CU by adding the predicted image supplied from the predicted image generation unit 308 and the prediction error supplied from the inverse quantization / inverse transformation unit 311.

[0104] (S5000: Loop filter) Loop filter 305 applies loop filters such as a deblocking filter, SAO, and ALF to the decoded image to generate a decoded image.

[0105] (Variation 1) Example of changing the tile size for each tile group In the example above, the width and height of the tiles were defined on a picture-by-picture (PPS) basis. However, Modification 1 describes an example where the tile size is flexibly set for each tile group that divides the picture.

[0106] Figure 13 shows an example of dividing a picture into four tile groups, TileGr0 to TileGr3, and then further dividing each tile group into individual tiles. Unlike the tile division in Figure 6, a key feature is that different tile widths and heights are set for each tile group. The numbers after "Tile" in the figure represent the address of the tile within the tile group (TileAddrInTG). In the figure, tile group TileGr0 contains tiles Tile0, Tile1, Tile2, and Tile3. TileGr1 contains Tile4 and Tile5. TileGr2 contains Tile6, Tile7, and Tile8. TileGr3 contains Tile9.

[0107] Figure 14 shows an example of the syntax for Modification 1. As shown in the figure, the syntax may be, for example, single_tile_group_in_pic_flag, num_tile_group_columns_minus1, num_tile_rows_group_minus1, tile_group_column_width_minus1[i], tile_group_row_height_minus1[i].

[0108] Here, single_tile_group_in_pic_flag is a flag indicating whether the picture contains multiple tile groups. If it is 1, there is one tile group in the picture, and the picture is equivalent to a tile group. If it is 0, the picture contains multiple tile groups. num_tile_group_columns_minus1 and num_tile_group_rows_minus1 are the number of horizontal and vertical tile groups in the picture, NumTileGrColumns and NumTileGrRows, respectively, minus 1.

[0109] Next, the tile syntax is notified for each tile group. For example, for each tile in the j-th tile group, single_tile_in_pic_flag[j], num_tile_columns_minus1[j], num_tile_rows_minus1[j], uniform_tile_spacing_flag[j], tile_column_width_minus1[j][i], and tile_row_height_minus1[j][i] are notified. The meaning of each syntax is the same as the syntax in Figure 11(b).

[0110] The header decoding unit 3020 derives the width and height (in CTU units) of the j-th tile group as follows:

[0111] TileGrWidthInCtbsY[j] = Ceil((tile_group_column_width_minus1[j]+1) / ctuWidth) TileGrHeightInCtbsY[j] = Ceil((tile_group_rows_height_minus1[j]+1) / ctuHeight) The header decoding unit 3020 derives the number of horizontal and vertical tile groups in the picture, NumTileGrColumns and NumTileGrRows, and the total number of tile groups in the picture, NumTileGrsInPic, as follows.

[0112] NumTileGrColumns = num_tile_group_columns_minus1+1 NumTileGrRows = num_tile_group_rows_minus1+1 NumTilesGrsInPic = NumTileGrColumns*NumTileGrRows The header decoding unit 3020 derives the number of horizontal and vertical tiles in the j-th tile group, NumTileColumns[j], NumTileRows[j], and the total number of tiles in the tile group, NumTilesInPic[j], as follows.

[0113] NumTileColumns[j] = num_tile_columns_minus1[j]+1 NumTileRows[j] = num_tile_rows_minus1[j]+1 NumTilesInPic[j] = NumTileColumns[j]*NumTileRows[j] The header decoding unit 3020 decodes the width ColWidth[j][m] and height RowHeight[j][n] of each tile in the j-th tile group as follows.

[0114] ColWidth[j][m] = tile_column_width_minus1[j][m]+1 (0<=m <NumTileColumns[j]-1) RowHeight[j][n] = tile_row_height_minus1[j][m]+1 (0<=n<NumTileRows[j]-1) ColWidth[j][NumTileColumns[j]-1] = TileGrWidthInCtbsY[j]-sum_m(ColWidth[j][m]) RowHeight[j][NumTileRows[j]-1] = TileGrHeightInCtbsY[j]-sum_n(RowHeight[j][n]) Here, sum_m(ColWidth[j][m]) represents the sum of ColWidth[j][m] (0<=m<NumTileColumns[j]-1), and sum_n(RowHeight[j][n]) represents the sum of RowHeight[j][n] (0<=n<NumTileRows[j]-1).

[0115] In Variation 1, the syntax of the tile group header and tile group data is the same as that in FIGS. 12(a) and 12(c), but the method for deriving the table TileId[] that converts the CTU address in the tile scan order to a tile identifier is different. The method for deriving this table in Variation 1 is shown below.

[0116] for (k=0; k<NumTileGrRows; k++) for (l=0; l<NumTileGrColumns; l++) for (j=0,tileIdx=0; j<=num_tile_rows_minus1[k]; j++) for(i=0; i<=num_tile_columns_minus1[l]; i++,tileIdx++) for(y=RowBd[k][j]; y<RowBd[k][j+1]; y++) for(x=ColBd[l][i]; x<ColBd[l][i+1]; x++) TileId[CtbAddrRsToTs[y*PicWidthInCtbsY+x]] = TileIdx The rest of the processing in the header decoding unit 3020 is the same as in the example above where the width and height of the tiles are defined in PPS.

[0117] As described above, by encoding or decoding the syntax indicating the width and height of each tile group, it becomes possible to use tiles of different sizes for each tile group, enabling more flexible tile division.

[0118] (Wavefront parallel processing) Wavefront Parallel Processing (WPP) enables parallel coding or decoding of a large number of segments while minimizing the decrease in coding efficiency by using CTU rows as segments.

[0119] (Exclusive configuration within a segment group) Figure 15 shows an example of using different types of segments on a tile group (segment group) basis. In this example, TileGr0 and TileGr1 use tiles as segments, TileGr2 uses CTU rows as segments, and TileGr3 uses slices as segments.

[0120] In subsequent embodiments, the segment type is restricted to one within a segment group (tile group), and tiles, CTU rows, and slices are processed exclusively. That is, within a single tile group (segment group), only one of the following can be enabled: a tile segment (multiple tile segments), a CTU row segment, or a slice segment. For example, within a single tile group, only either a tile or a CTU row can be enabled. Enabling a tile as described above means that a tile group consists of two or more tiles (dividing the tile group into two tiles above it).

[0121] (Variation 2) Processing when a segment can consist of tiles and CTU rows. Variation 2 describes how a segment can be either a tile or a CTU row, and how to use either a tile or a CTU on a tile group basis.

[0122] Figure 16 illustrates the mutually exclusive configuration of tile segments and CTU row segments.

[0123] The `entropy_coding_sync_enabled_flag` flag indicates whether or not a CTU row is treated as a segment (whether WPP is performed) (WPP enabled flag). When a CTU row is treated as a segment, CABAC synchronization is performed. That is, the CABAC state at the time the second CTU of the CTU row above is completed is used to initialize the CABAC of the first CTU of the CTU row. As shown in the diagram, if `num_tiles_in_tile_group_minus1` is greater than 0, i.e., if there are multiple tiles, `entropy_coding_sync_enabled_flag` can only take the value 0. In this case, only multiple tiles are enabled. If `num_tiles_in_tile_group_minus1` is 0, i.e., if there is one tile, `entropy_coding_sync_enabled_flag` can take the value 1. In this case, only multiple CTU rows (wavefronts) are enabled. Finally, if num_tiles_in_tile_group_minus1 is 0 and entropy_coding_sync_enabled_flag is 0, it means there is only one tile in the tile group. As will be discussed later, slicing may be enabled in this case.

[0124] Furthermore, if entropy_coding_sync_enabled_flag is 1, the CABAC initialization of the first CTU in the CTU row may be performed using the CABAC state at the time the first CTU processing of the CTU row above has finished.

[0125] The above configuration has the effect of allowing the entry points for tiles and wavefronts to be shared within a single tile group (within a segment group).

[0126] Furthermore, it has the effect of enabling tiles (multiple tiles) in one tile group and wavefronts in another tile group.

[0127] In the second variation, to achieve mutual exclusion between tiles and wavefronts, the entropy_coding_sync_enabled_flag flag is notified when the number of tiles in a tile group is 1 (the tile group and the tile are the same, i.e., multiple tiles are not enabled in the target tile group), thereby making the CTU row available as a segment. Otherwise (the tile group contains multiple tiles), the tile is used as a segment. Therefore, when a picture is divided into four tile groups as shown in Figure 5, each tile group can be divided into multiple tiles as shown in Figure 8(a), into multiple CTU rows as shown in Figure 8(b), or the tile group can consist of a single tile (there is one tile in the tile group and it is not divided by a CTU row).

[0128] To encode or decode multiple tiles or multiple CTU rows contained within a tile group in parallel, the starting address (entry point) of the tile or CTU row is encoded or decoded in the tile group header.

[0129] Figure 17 illustrates the operation of the header encoding unit 1110 and the header decoding unit 3020 in a configuration that includes an exclusive configuration of tiles and wavefronts. Figure 18(a) shows the syntax configuration of the tile group header to be encoded and decoded in this embodiment.

[0130] As shown in the flowchart and syntax configuration in the figure, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag if num_tiles_in_tile_group_minus1 is 0 (YES in S3001), i.e., if there is one tile in the tile group (S3002). Otherwise, it sets entropy_coding_sync_enabled_flag to 0 (WPP off).

[0131] if (num_tiles_in_tile_group_minus1 == 0) entropy_coding_sync_enabled_flag else entropy_coding_sync_enabled_flag=0 Figure 18(b) shows the syntax configuration of the entry point. In the figure, TileGrHeightInCtbsY is the height of the tile group in CTU units, and num_tiles_in_tile_group_minus1 is the number of tiles in the tile group minus 1.

[0132] The header encoding unit 1110 or the header decoding unit 3020 derives the number of entry points, NumEntryPoint. If the segment included in the tile group uses WPP (when entropy_coding_sync_enabled_flag=1), NumEntryPoint is set to the number of CTU rows included in the tile group minus 1 (here, TileGrHeightInCtbsY-1).

[0133] NumEntryPoint = TileGrHeightInCtbsY-1 Otherwise, set NumEntryPoint to the number of tiles in the tile group minus 1 (in this case, num_tiles_in_tile_group_minus1).

[0134] NumEntryPoint=num_tiles_in_tile_group_minus1 The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes the entry point information (offset_len_minus1 and NumEntryPoint entries of entry_point_offset_minus1) when NumEntryPoint is greater than 0.

[0135] Figure 18(c) shows the syntax structure of the tile group data. coding_tree_unit() is the encoded data of the CTU contained in the CTU row. end_of_subset_one_bit is a flag indicating the end of the segment.

[0136] The CT information encoding unit 1111 or the CT information decoding unit 3021 encodes or decodes the target CTU coding_tree_unit() in a loop processing (loop variable i) that processes tiles within a tile group, and further in a loop processing (loop variable j) that deals with CTUs within a tile.

[0137] The CT information encoding unit 1111 or the CT information decoding unit 3021 derives ctbAddrInTile using ctbAddrTs and FirstCtbAddrTs[] in the following formula: ctbAddrInTile is the address of the current CTU within the tile, ctbAddrTs is the address of the current CTU in the tile scan order, and FirstCtbAddrTs[] is the address of the first CTU in the tile group.

[0138] ctbAddrInTile = ctbAddrTs-FirstCtbAddrTs[tile_group_address] In a configuration where the CTU (coding_tree_unit()) is decoded by looping through the CTUs within a tile from 0 to the number of tiles in the tile group, NumCtusInTile[tileIdx], using a loop variable index j, then ctbAddrInTile = j.

[0139] The CT information encoding unit 1111 or the CT information decoding unit 3021 encodes or decodes end_of_subset_one_bit after decoding of the CTU line is complete, if WPP is enabled. end_of_subset_one_bit is the bit to be inserted at the end of the CTU line. Whether or not it is the end of the CTU line is determined by the following formula.

[0140] entropy_coding_sync_enabled_flag && (CtbAddrInTile+1)%TileWidthInCtbsY==0 In other words, the CT information decoding unit 3021 decodes the fixed value end_of_subset_one_bit at the right end of the CTU row after CTU decoding when (entropy_coding_sync_enabled_flag && (CtbAddrInTile+1)%TileWidthInCtbsY==0), that is, when entropy_coding_sync_enabled_flag is 1. Alternatively, if the target CTU is at the beginning (left end) of the CTU row, the same process can be performed by decoding the bit sequence indicating the end of the segment (in this case, the CTU row) before encoding or decoding the target CTU coding_tree_unit(). For example, before the target CTU coding_tree_unit(), the end_of_subset_one_bit may also be encoded or decoded by checking entropy_coding_sync_enabled_flag && ((CtbAddrInTile)%TileWidthInCtbsY)==0 && CtbAddrInTile!=0.

[0141] The CTU width of the target tile, TileWidthInCtbsY, can also be derived as follows. TileWidthInCtbsY = ColWidth[tileIdx % (num_tile_columns_minus1 + 1) ] Here, tileIdx is the raster scan position of the target tile. num_tile_columns_minus1 is the number of rows in the tile's picture. tileIdx % (num_tile_columns_minus1 + 1) derives the CTU row position of the tile. The width of the target tile in CTU units is derived by referencing ColWidth[] using the tile's CTU row position as an index.

[0142] Alternatively, tileIdx can be derived using the table TgTileIdx[i], which calculates the tile index (tileIdx) within a picture from the tile address i within a group of tiles. In this case, TileWidthInCtbsY = ColWidth[TgTileIdx[i]%(num_tile_columns_minus1+1)]] Expressed using the loop variable j, which is the tile index within the tile group, the CT information encoding unit 1111 or the CT information decoding unit 3021 may encode or decode the end_of_subset_one_bit, which is the bit sequence indicating the end of a segment (in this case, a CTU row), after encoding or decoding the target CTU coding_tree_unit(), if the following equation holds true.

[0143] if(entropy_coding_sync_enabled_flag && ( (j+1) % ColWidth[ TgTileIdx[ i ] % (num_tile_columns_minus1 + 1) ] = = 0 ) ) { end_of_subset_one_bit The CT information encoding unit 1111 or the CT information decoding unit 3021 encodes or decodes the fixed value end_of_subset_one_bit when j == NumCtusInTile[tileIdx] - 1 (when it is the last CTU in the tile group).

[0144] Furthermore, except for the last segment of the tile group (except when encoding trailing data immediately), the CT information encoding unit 1111 or the CT information decoding unit 3021 decodes a byte-aligned bit sequence after end_of_subset_one_bit. Note that j < NumCtusInTile[tileIdx] - 1 represents CTUs other than the last CTU in the segment, i < num_tiles_in_tile_group_minus1 represents segments other than the last segment, and the union of the two can be used to determine CTUs other than the last segment of the tile group.

[0145] FIG. 25 is a diagram showing another syntax configuration of tile group data in an exclusive configuration of tiles and wavefronts. The tile group header and the entry point configuration are the same as those in FIGS. 18(a) and (b). In the figure, in addition to end_of_subset_one_bit representing the end of WPP as a fixed-value segment end bit notified at the end of the segment, end_of_tile_one_bit representing the end of the tile is included. FIG. 26 is a flowchart showing the operation of the CT information decoding unit 3021 decoding the syntax of FIG. 25.

[0146] Set the identifier of the tile (S2602).

[0147] Perform the processing of S2604 to S2624 for each tile (loop variable i) in the tile group. Note that when WPP is on, the tile group consists of one tile, and the tile group and the tile are equal. As described above, even in a configuration where WPP is on when the tile group is composed of one tile, it may also be a configuration where it is one tile when WPP is on.

[0148] Set the starting CTU address of the tile group (S2604).

[0149] ctbAddrInTile = ctbAddrTs - FirstCtbAddrTs[tile_group_address] In the loop processing (loop variable j) for the CTU within the tile, the CTU address within the tile is set (S2606), and the target CTU is decoded (S2608).

[0150] WPP is enabled, and whether it is the last CTU in the CTU line is determined by, for example, the following formula (S2610).

[0151] entropy_coding_sync_enabled_flag && ((CtbAddrInTile+1)%TileWidthInCtbsY)==0 If WPP is enabled and it is the last CTU in the CTU row, proceed to S2612. Otherwise, proceed to the next CTU decoding process. As already explained, you can also use the loop variable j that indicates the CTU address within the tile to derive CtbAddrInTile=j and TileWidthInCtbsY = ColWidth[ TgTileIdx[ i ] % (num_tile_columns_minus1 + 1) ]. Alternatively, before encoding or decoding the target CTU coding_tree_unit(), you can encode or decode end_of_subset_one_bit by checking entropy_coding_sync_enabled_flag && ((CtbAddrInTile)%TileWidthInCtbsY)==0 && CtbAddrInTile!=0.

[0152] Decode end_of_subset_one_bit (S2612). end_of_subset_one_bit is the bit to insert at the end of the CTU line.

[0153] Whether or not it is the last CTU of the tile can be determined, for example, by the following formula (S2614).

[0154] j <NumCtusInTile[tileIdx]-1 If it is the last CTU in the tile group, proceed to the next CTU decoding process. Otherwise, decode the bit sequence for byte alignment (S2616).

[0155] The process from S2606 to S2616 is repeated until all CTUs within the tile have been processed.

[0156] Determine whether WPP is off or not (S2618). If WPP is not off, terminate the process. If WPP is off, proceed to S2620.

[0157] Decode end_of_tile_one_bit. end_of_tile_one_bit is the bit inserted at the end of the tile (S2620).

[0158] Determine whether it is the last tile in the tile group (S2622). If it is the last tile in the tile group, terminate the process. Otherwise, decode the bit sequence of the byte alignment (S2624).

[0159] Repeat the above process until all tiles in the tile group have been processed.

[0160] In addition, the CT information encoding unit 1111 performs a process in which "decoding" in Figure 26 is replaced with "encoding".

[0161] As explained in Figure 18, the determination in (S2610) and the processing in (S2612) may also be derived as follows. Expressed using the loop variable j, which is the tile index within the tile group, the CT information encoding unit 1111 or the CT information decoding unit 3021 may encode or decode the end_of_subset_one_bit, which is the bit sequence indicating the end of the segment (in this case, the CTU row), after encoding or decoding the target CTUcoding_tree_unit(), if the following equation holds true.

[0162] if(entropy_coding_sync_enabled_flag && ( (j+1) % ColWidth[ TgTileIdx[ i ] % (num_tile_columns_minus1 + 1) ] = = 0 ) ) { end_of_subset_one_bit In the above process, when using WPP (entropy_coding_sync_enabled_flag==1), a segment end bit and byte alignment are inserted at the end of each CTU row, but the byte alignment is omitted for the last CTU row corresponding to the end of the tile group (j==NumCtusInTile[tileIdx]-1). In WPP mode, a tile group is composed of CTU rows, so the end of the tile group is the end of the last CTU row. When not using WPP (entropy_coding_sync_enabled_flag==0), a segment end bit and byte alignment are inserted at the end of the tile, but the byte alignment is omitted for the last tile group (i==num_tiles_in_tile_group_minus1). This is to avoid duplication with the byte alignment inserted in the trailing data (rbsp_tile_group_trailing_bits) in a configuration that includes trailing data for byte alignment after the tile group data, as explained in Figure 4(c). In configurations where byte alignment is not performed on trailing data, byte alignment may be inserted at the end of a tile group or within the data of the tile group.

[0163] In Figures 25 and 26, the wavefront and tiles can be clearly distinguished by distinguishing between the bit inserted at the end of a CTU row in the wavefront (end_of_subset_one_bit) and the bit inserted at the end of a tile in the tile (end_of_tile_one_bit).

[0164] As described above, by using either tiles or CTU rows on a tile group basis, multiple processes with parallel processing capabilities can be exclusively executed within a single tile group, resulting in good encoding efficiency. Furthermore, since entry points can be used in common for tiles and CTU rows, and it is known whether the entry point for each tile group refers to the starting address of a tile or the starting address of a CTU row, processing is simplified.

[0165] Figure 19 shows another example of the syntax configuration of the tile group header to be encoded and decoded in this embodiment. As shown in the figure, entropy_coding_sync_enabled_flag may be encoded and decoded first, and num_tiles_in_tile_group_minus1 may be notified when entropy_coding_sync_enabled_flag is 0, i.e., WPP is off. In this case, the header encoding unit 1110 and the header decoding unit 3020 encode or decode entropy_coding_sync_enabled_flag, and encode or decode num_tiles_in_tile_group_minus1 if NumTilesInPic is greater than 1 and entropy_coding_sync_enabled_flag is 0. Otherwise (NumTilesInPic is 1 or less, or entropy_coding_sync_enabled_flag is 1), the header encoding unit 1110 and the header decoding unit 3020 set num_tiles_in_tile_group_minus1 to 0.

[0166] (Variation 3) Processing when a segment can take the form of tiles and slices Variation 3 describes a case where either tiles or slices are used exclusively as segments within a tile group.

[0167] Figure 20 illustrates the mutually exclusive configuration of tile segments and slice segments.

[0168] `slice_enabled_flag` is a flag that indicates whether or not to use a slice as a segment (to use a slice). Note that CABAC is initialized at the beginning of the slice. As shown in the diagram, if `num_tiles_in_tile_group_minus1` is greater than 0, that is, if there are multiple tiles in the tile group, `slice_enabled_flag` can only take 0. In this case, only tiles are enabled. If `num_tiles_in_tile_group_minus1` is 0, that is, if there is one tile in the tile group, `slice_enabled_flag` can take 1. In this case, only slices are enabled. Finally, if `num_tiles_in_tile_group_minus1` is 0 and `entropy_coding_sync_enabled_flag` is 0, there is one tile in the tile group. In this case, WPP may be enabled.

[0169] In variation 3, if the number of tiles in a tile group is 1 (the tile group and the tile are the same), a slice can be used as a segment; otherwise (the tile group contains multiple tiles), a tile is used as a segment. For example, if a picture is divided into four tile groups as shown in Figure 5, each tile group may be divided into multiple tiles as shown in Figure 8(a), or into multiple slices as shown in Figure 8(c). It may also be divided into a single tile. In other words, if there is only one tile in a tile group and it is not divided into CTU rows or slices, the tile group contains one tile.

[0170] In slices, a slice can be terminated at any position within a CTU by notifying the end of the CTU's encoded data with an end_of_slice_segment_flag, which indicates whether or not it is the end of the segment. Segments of variable size within a CTU are called slice segments. For example, slices are used when it is desired to delimit segments within a specified number of bits. Furthermore, for the purpose of parallel decoding of slices, a marker (unique code, start code) may be inserted at the beginning of each slice. By using a marker, the video decoding device can search for the starting position of each slice on the bitstream and identify its position. In a configuration where a marker is inserted at the beginning of a slice, the tile group may be terminated each time a slice is inserted (i.e., when end_of_slice_segment_flag is 1). In this configuration, since the tile group contains one slice, the tile group header is always added to the beginning of the slice and acts as a marker.

[0171] When encoding or decoding the beginning of a slice using a marker, a unique code, such as "0x00000100" (32 bits), may be inserted before the slice, and the video decoder may search for the beginning of the slice in the encoded data by scanning the encoded data beforehand.

[0172] To process tiles and slices in parallel, the starting address (entry point) of a tile may be notified in the tile group header. Figure 21(a) shows an example of a tile group header. In Figure 21, the slice_enabled_flag is notified. slice_enabled_flag is a flag that indicates whether or not to slice the tile.

[0173] The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes slice_enabled_flag if num_tiles_in_tile_group_minus1 is 0, i.e., there is one tile in the tile group. Otherwise, it sets slice_enabled_flag to 0 (slice off).

[0174] It is also acceptable to configure the system so that num_slices_in_tile_minus1 is not notified in the tile group header.

[0175] The order of encoding and decoding the number of tiles (num_tiles_in_tile_group_minus1) and the slice-enabled flag (slice_enabled_flag) is not limited to the above. The following processing may also be used.

[0176] (Slice, tile) When notifying the slice enable flag slice_enabled_flag and the number of tiles num_tiles_in_tile_group_minus1 in that order, the following processing is performed: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes slice_enabled_flag in the tile group header. If slice_enabled_flag is 0, encodes or decodes num_tiles_in_tile_group_minus1. If num_tiles_in_tile_group_minus1 and slice_enabled_flag are not decoded, set them to 0.

[0177] The header encoding unit 1110 and the header decoding unit 3020 derive NumEntryPoint. NumEntryPoint is the number of entry points, and if tiles are used, it is set to num_tiles_in_tile_group_minus1. The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes the entry point information (offset_len_minus1 and NumEntryPoint entries of entry_point_offset_minus1) if NumEntryPoint is greater than 0.

[0178] If the slice is on, the CT information decoding unit 3021 decodes the end_of_slice_segment_flag after decoding one CTU. The end_of_slice_segment_flag is the bit to be inserted at the end of the CTU row.

[0179] Figure 21(c) shows an example of the syntax of tile group data for an encoded tile group. The figure shows a configuration in which end_of_slice_segment_flag is encoded or decoded after decoding 1CTU is complete. end_of_slice_segment_flag is a flag that indicates whether or not it is the end of the slice; if it is 1, it is the end of the slice, otherwise it is not the end of the slice.

[0180] As described above, by using either tiles or slices on a tile group basis, multiple processes with parallel processing capabilities can be executed exclusively within a single tile group, resulting in high efficiency.

[0181] (Modification 4) Processing when using an entry point in a slice The following example shows a configuration in which the starting position of a slice on a bitstream is specified by encoding or decoding the starting address of the slice as the entry point.

[0182] To process tiles and slices in parallel, the starting addresses (entry points) of tiles and slices are notified in the tile group header. In the example tile group header shown in Figure 21(a), num_slices_in_tile_minus1 may be notified after slice_enabled_flag. num_slices_in_tile_minus1 is the number of slices in a tile minus 1.

[0183] Furthermore, the syntax of the entry point is shown in Figure 21(b). Figure 21(c) shows a configuration in which slice_enabled_flag and num_slices_in_tile_minus1 are used to derive NumEntryPoint.

[0184] The header decoding unit 3020 decodes slice_enabled_flag and num_slices_in_tile_minus1 if num_tiles_in_tile_group_minus1 is 0, i.e., there is one tile in the tile group. Otherwise, it sets slice_enabled_flag to 0 (slice off).

[0185] The header decoding unit 3020 derives NumEntryPoint. NumEntryPoint is the number of entry points; if slices are used, num_slices_in_tile_minus1 is set, and if tiles are used, num_tiles_in_tile_group_minus1 is set. If NumEntryPoint is greater than 0, the header decoding unit 3020 decodes the entry point information (offset_len_minus1 and NumEntryPoint entries of entry_point_offset_minus1).

[0186] Other processes are the same as in Modification 2.

[0187] Next, we will explain tile group data.

[0188] Figure 21(c) shows an example of the syntax of tile group data for an encoded tile group. Figure 21(c) shows a configuration in which end_of_slice_segment_flag is encoded or decoded after decoding of 1 CTU is complete. end_of_slice_segment_flag is a flag (bit) that indicates whether or not it is the end of the slice; if it is 1, it is the end of the slice, otherwise it is not the end of the slice.

[0189] If the slice is turned on, the CT information decoding unit 3021 decodes the end_of_slice_segment_flag after decoding one CTU is complete.

[0190] As described above, by using either tiles or slices on a tile group basis, multiple processes with parallel processing capabilities can be executed exclusively within a single tile group, resulting in high efficiency. Furthermore, entry points can be used in common for tiles and slices, and since it is known whether the entry point for each tile group refers to the starting address of a tile or the starting address of a slice, processing is simplified. Alternatively, the start of a slice can be indicated by a unique marker without using an entry point.

[0191] (Modification 5) Segmentation using tiles, CTU rows, and slices Modification 5 describes an example of setting tiles, CTU rows, and slices mutually exclusive. Figure 22 is a diagram illustrating the mutually exclusive configuration of tile segments, CTU row segments, and slice segments. As shown in the figure, Modification 5 takes one of the following cases within a tile group: there are multiple tile segments, there are CTU row segments, there are slice segments, or there is a single segment (referred to here as a tile) within the tile group.

[0192] More specifically, a tile group can be configured to use tiles when it contains multiple tiles, and to use CTU rows or slices when it consists of only one tile. If a tile group consists of only one tile and neither CTU rows nor slices are used, the tile group is configured as a single tile.

[0193] (Configuration that notifies in the following order: number of tiles, WPP enabled flag, slice enabled flag) Figure 23(a) shows an example of a tile group header. In the figure, the entropy_coding_sync_enabled_flag is notified when the number of tiles is 1, and the slice_enabled_flag is notified when entropy_coding_sync_enabled_flag is 0 (WPP off).

[0194] The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag if num_tiles_in_tile_group_minus1 is 0. Next, if entropy_coding_sync_enabled_flag is 0, it encodes or decodes slice_enabled_flag. If num_tiles_in_tile_group_minus1 is not 0, it sets entropy_coding_sync_enabled_flag and slice_enabled_flag to 0. If num_tiles_in_tile_group_minus1 is 0 and entropy_coding_sync_enabled_flag is not 0, it sets slice_enabled_flag to 0.

[0195] Other processing is the same as in the example where the segment is only tiles.

[0196] Figure 23(b) shows an example of the syntax of tile group data for an encoded tile group. As shown in the figure, in this embodiment, when the segment is a tile or a CTU row (wavefront), the end_of_subset_one_bit, which is always 1, is encoded or decoded at the end of the segment. When the segment is a slice, the end_of_slice_segment_flag, which can take the values ​​of 0 or 1, is encoded or decoded to indicate whether the CTU is the end of the segment. The method for encoding or decoding the end_of_subset_one_bit has already been explained in Figure 18(c), so the explanation is omitted. Similarly, the method for encoding or decoding the end_of_slice_segment_flag has already been explained in Figure 21(c), so the explanation is omitted.

[0197] As described above, by using tiles, CTU rows, and slices exclusively on a tile group basis, the encoding and decoding processes of segments can be simplified. This also has the effect of clearly defining the start and end points of segments. For example, it eliminates situations where a segment is the beginning of a slice, the beginning of a tile, and the beginning of a CTU row all at the same time.

[0198] The encoding and decoding order of the tile count (num_tiles_in_tile_group_minus1), the WPP enable flag (entropy_coding_sync_enabled_flag), and the slice enable flag (slice_enabled_flag) is not limited to the above. They may also be processed as follows.

[0199] (Tiles, slices, WPP) When notifying num_tiles_in_tile_group_minus1, slice_enabled_flag, and entropy_coding_sync_enabled_flag in that order, the following processing is performed: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes num_tiles_in_tile_group_minus1. If num_tiles_in_tile_group_minus1 is 0, it encodes or decodes slice_enabled_flag. Next, if slice_enabled_flag is 0, it encodes or decodes entropy_coding_sync_enabled_flag. If num_tiles_in_tile_group_minus1, entropy_coding_sync_enabled_flag, and slice_enabled_flag are not decoded, they are each set to 0.

[0200] (WPP, tile, slice) When notifying entropy_coding_sync_enabled_flag, num_tiles_in_tile_group_minus1, and slice_enabled_flag in that order, the following processing is performed: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag in the tile group header. If entropy_coding_sync_enabled_flag is 0, encodes or decodes num_tiles_in_tile_group_minus1. Next, if num_tiles_in_tile_group_minus1 is 0, encodes or decodes slice_enabled_flag. If num_tiles_in_tile_group_minus1, entropy_coding_sync_enabled_flag, and slice_enabled_flag are not decoded, they are each set to 0.

[0201] (WPP, slice, tile) When notifying entropy_coding_sync_enabled_flag, slice_enabled_flag, and num_tiles_in_tile_group_minus1 in that order, the following processing is performed: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag in the tile group header. If entropy_coding_sync_enabled_flag is 0, encodes or decodes slice_enabled_flag. Next, if slice_enabled_flag is 0, encodes or decodes num_tiles_in_tile_group_minus1. If num_tiles_in_tile_group_minus1, entropy_coding_sync_enabled_flag, and slice_enabled_flag are not decoded, they are each set to 0.

[0202] (Slice, Tile, WPP) When notifying slice_enabled_flag, num_tiles_in_tile_group_minus1, and entropy_coding_sync_enabled_flag in that order, the following processing is performed: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes slice_enabled_flag in the tile group header. If slice_enabled_flag is 0, encodes or decodes num_tiles_in_tile_group_minus1. Next, if num_tiles_in_tile_group_minus1 is 0, encodes or decodes entropy_coding_sync_enabled_flag. If num_tiles_in_tile_group_minus1, entropy_coding_sync_enabled_flag, and slice_enabled_flag are not decoded, they are each set to 0.

[0203] (Slice, WPP, Tile) When notifying slice_enabled_flag, entropy_coding_sync_enabled_flag, and num_tiles_in_tile_group_minus1 in that order, the following processing is performed: The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes slice_enabled_flag in the tile group header. If slice_enabled_flag is 0, encodes or decodes entropy_coding_sync_enabled_flag. Next, if entropy_coding_sync_enabled_flag is 0, encodes or decodes num_tiles_in_tile_group_minus1. If num_tiles_in_tile_group_minus1, entropy_coding_sync_enabled_flag, and slice_enabled_flag are not decoded, they are each set to 0.

[0204] The entropy decoding unit 301 outputs the inter-prediction parameters to the inter-prediction parameter decoding unit 303. It also outputs the intra-prediction parameters to the intra-prediction parameter decoding unit 304. Furthermore, it outputs the quantization conversion coefficients to the inverse quantization / inverse conversion unit 311.

[0205] The entropy decoding unit 301 comprises a CABAC initialization unit 3011, a CABAC decoding unit 3012, an initialization table 3013, and a spatial prediction storage unit 3015 (including a spatial prediction table 3016). The spatial prediction storage unit 3015 stores the CABAC state in its internal spatial prediction table 3016. The stored CABAC state is referenced when decoding segments other than the target segment, such as subsequent segments of the target picture, and is used to initialize the CABAC state. The CABAC decoding unit 3012 decodes the syntax from the encoded data (bitstream) according to the stored CABAC state.

[0206] The entropy decoding unit 301 initializes the CABAC state at the beginning of a segment using the CABAC initialization unit 3011. The CABAC state includes, for example, StateIdx, which indicates the probability state for each context; MpsVal, which indicates whether 0 or 1 is more likely; and the coefficient StatCoeff. The context is defined for each element of the binary sequence (a sequence consisting of 0s and 1s) that constitutes the syntax. CABAC (Context-adaptive binary arithmetic coding) estimates the probability of encoding to 0 or 1 for each context and encodes the binary based on that probability. At this time, it is necessary to set the initial value of the probability StateIdx and MpsVal, and this is called CABAC initialization. TableStateIdx, TableMpsVal, and TableStatCoeff are tables composed of StateIdx, MpsVal, and StatCoeff.

[0207] The CABAC initialization unit 3011 initializes the CABAC state using the initialization table at the top-left CTU of the tile if the segment is a tile. If the segment is a CTU row (entropy_coding_sync_enabled_flag is 1, WPP), it initializes the leftmost CTU row using the CABAC state stored in the spatial prediction storage unit 3015. In the case of WPP, the CABAC state of the second CTU of each CTU row is stored in the spatial prediction storage unit 3015 and used in subsequent segments. If the segment is a slice (slice_enabled_flag is 1), the CABAC state may be initialized using the initialization table. Here, the tile boundary may be determined by whether the tile identifiers of adjacent CTUs are different (TileId[CtbAddrTs]!=TileId[CtbAddrTs-1]). Here, the leftmost column of a CTU row can also be determined by (CtbAddrInTile%TileWidthInCtbsY==0). Furthermore, the beginning of a slice can be determined by whether the CTU address CtbAddrRs matches the CTU address at the beginning of the slice (CtbAddrRs==slice_segment_address).

[0208] (Configuration that initializes at the beginning of the CTU row for each tile in the tile group) This section describes an example of raster scanning CTUs within individual tiles in a tile group and performing CABAC initialization at the beginning (leftmost) of the CTU row within the tile.

[0209] In this embodiment, the entropy decoding unit 301, upon completion of parsing the CTU syntax, if the WPP enabled flag is 1, stores the CABAC state (for example, state TableStateIdx0Wpp, state TableStateIdx1Wpp, and the MPS value TableMpsValWpp) in storage at a position 1 CTU from the beginning of the CTU row of each tile in the tile group (ctbAddrInTile % TileWidthInCtbsY == 1). TableStateIdx0Wpp and TableStateIdx1Wpp represent the state of the CTU at the beginning of the CTU row one step above the target CTU and the state of the next CTU.

[0210] However, the CTU address within a tile can also be derived as follows.

[0211] ctbAddrInTile = ctbAddrTs-FirstCtbAddrTs[tile_group_address] Alternatively, when looping through the CTUs by incrementing the number of CTUs within a tile from j=0 to the number of CTUs in the tile minus 1, the loop variable j can be used as ctbAddrInTile.

[0212] Furthermore, in this embodiment, the entropy decoding unit 301 may, at the end of parsing the CTU syntax, save the CABAC state (for example, state TableStateIdx0Wpp, state TableStateIdx1Wpp, and the MPS value TableMpsValWpp) to storage if the WPP enabled flag is 1 and the tile ID of the 1CTU position from the beginning of the CTU row on the screen (CtbAddrInRs % PicWidthInCtbsY==1) or the current position (TileId[CtbAddrInTs]) is different from the tile ID of the 2nd position in raster order (TileId[CtbAddrRsToTs[CtbAddrInRs-2]]).

[0213] Furthermore, to achieve even lower latency, the CABAC state may be saved when the CTU row of the tile is at its starting position (ctbAddrInTile % TileWidthInCtbsY == 0).

[0214] For example, when the entropy decoding unit 301 according to this embodiment finishes parsing the CTU syntax, if the WPP enabled flag is 1 and the tile ID of the starting position of the CTU row in the screen (CtbAddrInRs % PicWidthInCtbsY==1) or the current position (TileId[ CtbAddrInTs ]) is different from the tile ID of the previous position in raster order (TileId[ CtbAddrRsToTs[CtbAddrInRs-1]]), the CABAC state (for example, state TableStateIdx0Wpp, state TableStateIdx1Wpp, and the MPS value TableMpsValWpp) may be saved to storage.

[0215] Furthermore, in this embodiment, if the WPP enabled flag is 1, the entropy decoding unit 301 may be initialized using the CABAC state stored in storage at the first CTU (CtbAddrInRs % PicWidthInCtbsY == 0) of the CTU row of each tile in the tile group.

[0216] Also, when the WPP valid flag is 1, the entropy decoding unit 301 according to the present embodiment may perform initialization using the CABAC state held in the storage if the leading CTU in the next CTU line (CtbAddrInRs % PicWidthInCtbsY == 0) or the tile ID at the current position (TileId[ CtbAddrInTs]) is different from the tile ID at the position one before in raster order (TileId[ CtbAddrRsToTs[CtbAddrInRs-1]]).

[0217] (Configuration for initializing at the start of each CTU row in each tile group) Here, an example of performing CABAC initialization at the start (left end) of each CTU row in the tile group by raster scanning the CTUs in the tile group will be described.

[0218] When the parsing of the CTU syntax ends, the entropy decoding unit 301 according to the present embodiment stores the CABAC state (for example, state TableStateIdx0Wpp, state TableStateIdx1Wpp, and the value of MPS TableMpsValWpp) in the storage when the WPP valid flag is 1 and at the position of 1 CTU (ctbAddrInTileGroup % TileGroupWidthInCtbsY == 1) from the start of each CTU row of each tile in the tile group.

[0219] However, the CTU address within the tile group may be derived as follows ctbAddrInTileGroup = ctbAddrTs - FirstCtbAddrTs[tile_group_address] Also, when performing loop processing on CTUs by incrementing the CTUs within the tile from j = 0 to the number of CTUs within the tile group - 1, the loop variable j may be used as ctbAddrInTileGroup.

[0220] In order to achieve lower latency, the CABAC state may be saved when the leading position of the CTU rows in a tile (ctbAddrInTileGroup % TileGroupWidthInCtbsY == 0).

[0221] For example, when the parsing of the CTU syntax ends, and the WPP enable flag is 1 and the leading position of the CTU rows in the tile group (ctbAddrInTileGroup % TileGroupWidthInCtbsY == 0), the entropy decoder 301 according to this embodiment may save the CABAC state (for example, state TableStateIdx0Wpp, state TableStateIdx1Wpp, and the value of MPS TableMpsValWpp) to storage.

[0222] Also, when the WPP enable flag is 1, the entropy decoder 301 according to this embodiment may perform initialization using the CABAC state held in storage at the leading CTU (ctbAddrInTileGroup % TileGroupWidthInCtbsY == 0) of the CTU rows in the tile group.

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

[0224] (Rectangular tile group) Figure 27 illustrates a tile group that includes a rectangular tile group. A tile group is a technique for transmitting a picture by dividing it into multiple tiles and then grouping those tiles together. By transmitting tiles in groups and transmitting the header as a unit, the header overhead can be reduced. Furthermore, even when extracted at the tile group level, the tile group can be divided into tiles, enabling parallel processing. Tile groups can be rectangular tile groups or non-rectangular tile groups, which are identified as 1 or 0 using the syntax element rect_tile_group_flag, described later.

[0225] A rectangular tile group groups tiles according to the definition of a parameter set, and allows for the setting of tile regions that are not necessarily contiguous in raster scan order. Furthermore, it has the feature of allowing the extraction of specific tiles or tile groups without rewriting the tile group header. In contrast, non-rectangular tile groups (contiguous tiles) group tiles according to the definition of the tile group header and are limited to tiles that are contiguous in raster scan order.

[0226] Figure 27(a) shows a tile group when it is not a rectangular tile group (rect_tile_group_flag==0). When it is not a rectangular tile group, the syntax element num_tiles_in_tile_group_minus1 is transmitted, which indicates the number of tiles to be grouped as a tile group. num_tiles_in_tile_group_minus1+1 tiles are grouped. In Figure 27(a), an example is shown where, if there are 3x2 tiles, the first three consecutive tiles become TileGroup0, the next two consecutive tiles become TileGroup1, and the next tile becomes TileGroup2.

[0227] Figure 27(b) shows a tile group when it is a rectangular tile group (rect_tile_group_flag==1). In the case of a rectangular tile group, the syntax elements top_left_tile_idx, which indicates the tile located in the upper left of the rectangular area, and bottom_right_tile_idx, which indicates the tile located in the lower right, are transmitted, and the tiles represented by these two elements are grouped together. Figure 27(b) shows an example where, in the case of a 3x2 tile arrangement, the 2x2 tile on the left becomes TileGroup0, the 1x1 tile becomes TileGroup2, and the 1x1 tile becomes TileGroup2.

[0228] Figure 28 shows the syntax configuration of the parameter set of a tile group in one embodiment of this model.

[0229] The `single_tile_in_pic_flag` flag indicates whether there is one tile in the picture. If `single_tile_in_pic_flag==1`, the entire picture is treated as a single tile, and no further syntax elements are transmitted.

[0230] num_tile_columns_minus1 and num_tile_rows_minus1 are syntax elements transmitted when single_tile_in_pic_flag==0, and they indicate the number of columns and rows of tiles in the picture.

[0231] `uniform_tile_spacing_flag` is a syntax element that indicates whether or not to implicitly derive the size of each tile from the number of columns and rows of the tile. If `uniform_tile_spacing_flag==1`, the tile size is implicitly derived.

[0232] tile_column_width_minus1 and tile_row_height_minus1 are syntax elements that are transmitted when uniform_tile_spacing_flag==0 and explicitly indicate the width and height of the tile size.

[0233] `single_tile_per_tile_group_flag` is a syntax element that indicates whether or not one tile is used per tile group. If `single_tile_per_tile_group_flag` does not appear in the encoded data (for example, `single_tile_in_pic_flag=1`), `single_tile_per_tile_group_flag` may be derived as 1 (infer rule 1).

[0234] `rect_tile_group_flag` is a syntax element that indicates whether or not to use rectangular tile groups as tile groups. If `rect_tile_group_flag=1`, it indicates that rectangular tile groups will be used. In this case, information about the tile groups (`num_tile_groups_in_pic_minus1`, `top_left_tile_idx`, `bottom_right_tile_idx`) is transmitted in the picture parameter set. If `single_tile_per_tile_group_flag` is 1, i.e., one tile is used per tile group, then `rect_tile_group_flag` is not decoded from the encoded data, and `rect_tile_group_flag` is derived as 1 (infer rule 2).

[0235] num_tile_groups_in_pic_minus1 is a syntax element that indicates the number of tile groups in the picture. For each tile group, the tiles included in the tile group are specified by transmitting top_left_tile_idx and bottom_right_tile_idx. In PPS, if the number of tiles in a tile group is specified as 1 (single_tile_per_tile_group_flag is 1), num_tile_groups_in_pic_minus1 is not decoded. If num_tile_groups_in_pic_minus1 is not decoded (does not appear), num_tile_groups_in_pic_minus1 is set to 0.

[0236] `top_left_tile_idx` is a syntax element that indicates the index of the top-left tile in a tile group. `bottom_right_tile_idx` is a syntax element that indicates the index of the bottom-right tile in a tile group.

[0237] The encoded data for a tile group consists of header information tile_group_header() and data information tile_group_data(). As shown in Figure 29, tile_group_header() transmits information common to the tiles in the tile group. For tiles, the syntax elements tile_group_address and num_tiles_in_tile_group_minus1 may also be included. Here, tile_group_address is included if it is not a rectangular tile group and indicates the index of the first tile in the tile group. num_tiles_in_tile_group_minus1 is included if it is not a rectangular tile group and indicates the number of tiles in the tile group. If it is not a rectangular tile group, the tile group consists of num_tiles_in_tile_group_minus1+1 consecutive tiles.

[0238] In addition, as a syntax element common to tile groups, tile_group_type may be included. tile_group_type corresponds to slice_type in the conventional coding syntax and identifies whether the tile group consists of only intra prediction coded data or inter prediction coded data. Even in the inter prediction coded data, it may be possible to identify a P picture that generates a predicted image from one reference picture and a B picture that generates a predicted image from two or more reference pictures.

[0239] (Tile Group and WPP Enable Flag) Both the tiles and WPP (CTU rows) in the tile group divide the tile group into segments and perform parallel processing in segment units. Intra prediction between segments is basically prohibited for tiles and basically permitted for CTU rows. Except for the beginning of the tile group, an entry point for indicating the byte position of the bitstream is transmitted at the beginning of the segment.

[0240] The configurations include the following. · Syntax for notifying the WPP enable flag entropy_coding_sync_enabled_flag · Value restriction or decoding restriction of the WPP enable flag · CTU scan order within the tile group (tile-based CTU scan order (tile scan) or tile-group-based CTU scan order) Hereinafter, the configuration for notifying the WPP enable flag entropy_coding_sync_enabled_flag in the tile group will be described, and then the configuration for notifying the entropy_coding_sync_enabled_flag in the picture parameter set will be described. The value restriction or decoding restriction of the WPP enable flag and the CTU scan order will be described as sub-configurations of each configuration.

[0241] <Configuration for Transmitting the WPP Enable Flag in the Tile Group> Figure 30 shows the relationship between a tile group and wavefront processing (CTU row segment) in one embodiment of this model. Here, the CTU scan order is the tile scan order, and the CTU raster scan is performed on a tile-by-tile basis. In this figure, when there are 4x3 tiles in the picture, the leftmost 2x3 tiles are configured as TileGroup0, the upper right 2x1 tiles as TileGroup1, the 1x1 tiles as TileGroup2, the 1x1 tiles as TileGroup3, and the 1x2 tiles as TileGroup4. TileGroup2, which consists of 1x1 tiles, is a tile group with wavefront processing (WPP) enabled. In other words, TileGroup2 is further divided into segments consisting of CTU rows within the tile (tile group) and encoded. Note that the tile index in the picture is assigned in the order of the raster scan.

[0242] Figure 31 shows the syntax configuration of a tile group and wavefront processing header in one embodiment of this model. The same parts as the syntax elements described in Figure 29 are omitted from the explanation. In this embodiment, when there is one tile in the tile group, the entropy_coding_sync_enabled_flag is included in the encoded data and transmitted.

[0243] The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes information about tiles included in a tile group using a parameter set or tile group header. Specifically, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes top_left_tile_idx and bottom_right_tile_idx when rect_tile_group_flag=1, and decodes tile_group_address and num_tiles_in_tile_group_minus1 when rect_tile_group_flag=0.

[0244] The header encoding unit 1110 and the header decoding unit 3020 derive the number of tiles in the tile group, NumTilesInTileGroup, from top_left_tile_idx and bottom_right_tile_idx using the following pseudocode when rect_tile_group_flag=1. Specifically, by dividing the difference between the top-left tile index and the bottom-right tile index, deltaTileIdx, by the number of tile rows in the picture (num_tile_columns_minus1 + 1), they derive the number of tile rows (number of tiles vertically) NumTileRowsInTileGroupMinus1 and the number of tile columns (number of tiles horizontally) NumTileColumnsInTileGroupMinus1. NumTilesInTileGroup is derived from the product of the number of tiles horizontally and the number of tiles vertically. Specifically, we derive the difference deltaTileIdx[i] between the top-left tile index top_left_tile_idx[i] and the bottom-right tile index bottom_right_tile_idx[i]. I is the identifier of the tile group. deltaTileIdx[i] = bottom_right_tile_idx[i]-top_left_tile_idx[i] Next, we derive the number of tiles in the horizontal and vertical directions of the tile group from the difference deltaTileIdx[i] and the number of tiles in the horizontal direction within the picture (num_tile_columns_minus1+1). Here, we derive the value by subtracting 1 from the number of tiles. NumTileRowsInTileGroupMinus1[i] = (deltaTileIdx[i] / (num_tile_columns_minus1+1)) NumTileColumnsInTileGroupMinus1[i] = (deltaTileIdx[i]%(num_tile_columns_minus1+1)) Finally, the number of tiles in a tile group, NumTilesInTileGroup[i], is derived from the product of the tile width and height of the tile group. NumTilesInTileGroup[i] = (NumTileRowsInTileGroupMinus1[i]+1)* (NumTileColumnsInTileGroupMinus1[i]+1) For example, in the example in Figure 30, the picture is a 4x3 tile, so num_tile_columns_minus1+1=4. The top-left tile index top_left_tile_idx[i] and the bottom-right tile index bottom_right_tile_idx[i] of each tile group i = 0..4 are as follows. top_left_tile_idx[0] = 0, bottom_right_tile_idx[0] = 9 top_left_tile_idx[1] = 2, bottom_right_tile_idx[1] = 3 top_left_tile_idx[2] = 6, bottom_right_tile_idx[2] = 6 top_left_tile_idx[3] = 7, bottom_right_tile_idx[3] = 11 top_left_tile_idx[4] = 10, bottom_right_tile_idx[4] = 10 Therefore, TileGroup0 is NumTileRowsInTileGroupMinus1[0] = deltaTileIdx[0] = bottom_right_tile_idx[0]-top_left_tile_idx[0] / (num_tile_columns_minus1+1) = (9-0) / 4 = 2 NumTileColumnsInTileGroupMinus1[0] = (9-0)%4 = 1 NumTilesInTileGroup[0] = (1+1)*(2+1) =6 TileGroup1 is NumTileRowsInTileGroupMinus1[1] = (3-2) / 4 = 0 NumTileColumnsInTileGroupMinus1[1] = (3-2)%4 = 1 NumTilesInTileGroup[1] = (0+1)*(1+1) = 2 This is derived. TileGroup2 is NumTileRowsInTileGroupMinus1[2] = (6-6) / 4 = 0 NumTileColumnsInTileGroupMinus1[2] = (6-6)%4 = 0 NumTilesInTileGroup[2] = (0+1)*(0+1) = 1 This is derived. TileGroup3 is NumTileRowsInTileGroupMinus1[3] = (11-7) / 4 = 1 NumTileColumnsInTileGroupMinus1[3] = (11-7)%4 = 0 NumTilesInTileGroup[2] = (1+1)*(0+1) = 2 This is derived. TileGroup4 is NumTileRowsInTileGroupMinus1[4] = (10-10) / 4 = 0 NumTileColumnsInTileGroupMinus1[4] = (10-10)%4 = 0 NumTilesInTileGroup[4] = (0+1)*(0+1) = 1 This is derived.

[0245] Furthermore, the header encoding unit 1110 and the header decoding unit 3020 may derive the index TgTileIdx[tIdx] of the tile in the tile group as follows. Here, TgTileIdx[tIdx] is a table that derives the index tileIdx of the tile in the picture from the index tIdx of the tile in the tile group.

[0246] tileGroupIdx = 0 while( tile_group_address != rect_tile_group_id[ tileGroupIdx ] ) tileGroupIdx++ NumTilesInCurrTileGroup = NumTilesInTileGroup[tileGroupIdx] tileIdx = top_left_tile_idx[tileGroupIdx] for(j=0, tIdx=0; j<(NumTileRowsInTileGroupMinus1[tileGroupIdx]+1); j++, tileIdx+=num_tile_columns_minus1+1) { for(i=0, currTileIdx=tileIdx; i<(NumTileColumnsInTileGroupMinus1[tileGroupIdx]+1); i++, currTileIdx++, tIdx++) { TgTileIdx[tIdx] = currTileIdx } } The header encoding unit 1110 and the header decoding unit 3020, when rect_tile_group_flag==0, derive the number of tiles in the tile group NumTilesInTileGroup and the index of the tile within the tile group TgTileIdx[tIdx] from num_tiles_in_tile_group_minus1 using the following pseudocode.

[0247] NumTilesInTileGroup = num_tiles_in_tile_group_minus1+1 TgTileIdx[0] = tile_group_address for(i=1; i <NumTilesInTileGroup; i++) TgTileIdx[i] = TgTileIdx[i-1]+1 Furthermore, the header encoding unit 1110 and the header decoding unit 3020 may derive the number of tiles included in the target tile group using the following formula at the time of encoding and decoding the tile group header using the following formula.

[0248] NumTilesInCurrTileGroup = rect_tile_group_flag ? NumTilesInTileGroup[tileGroupIdx] : (num_tiles_in_tile_group_minus1+1) The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes the entropy_coding_sync_enabled_flag when the number of tiles included in the tile group, NumTilesInCurrTileGroup, is 1.

[0249] As shown in Figure 30, within the picture, scanning is performed in the order of each tile group. Within each tile group, each tile is scanned in raster order, and within each tile, the CTB (CTU) is scanned in raster order (tile scan). The method for deriving the above tile scan order is the same as already explained in (Method for deriving the CTU scan order within the picture 1). In tile groups with WPP off (entropy_coding_sync_enabled_flag==0) (TileGroup0, TileGroup1, TileGroup3, TileGroup4), segments are tile units, while in tile group with WPP on (entropy_coding_sync_enabled_flag==1) (TileGroup2), segments are CTU row units within a tile. Entry points are encoded or decoded in all segments except the first segment of a tile group. That is, in a tile group with WPP off, there are tile-1 entry points, and with WPP on, there are tile-1 entry points (number of CTU rows within a tile). Entry points are indicated at the positions shown in Figure 30.

[0250] The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes NumEntryPoint (= number of CTU rows in the tile group TileGroupHeightInCtbsY-1) entry points when WPP is on (entropy_coding_sync_enabled_flag==1). When WPP is off (entropy_coding_sync_enabled_flag==0), it encodes or decodes NumEntryPoint (= number of tiles in the tile group NumTilesInCurrTileGroup-1) entry points. The number of entry points may also be derived using the following formula.

[0251] Here, if the number of tiles included in the target tile group is 1, the number of CTU rows included in the target tile group, TileGroupHeightInCtbsY (the height of the target tile in CTU units, TileHeightInCtbsY), can be derived using the following formula.

[0252] ctbAddrInTs = FirstCtbAddrTs[tileIdx] CtbAddrInRs = CtbAddrTsToRs[ctbAddrInTs] tbX = CtbAddrInRs % PicWidthInCtbsY tbY = CtbAddrInRs / PicWidthInCtbsY for(j=0; j<=num_tile_rows_minus1; j++) if(tbY>=RowBd[j]) tileY = j TileGroupHeightInCtbsY = RowHeight[tileY] TileGroupHeightInCtbsY is also called the CTU number, which indicates the height of a tile group, or the CTU number, which indicates the height of a tile.

[0253] Furthermore, to account for cases where there is more than one tile in a tile group, the height of the tile group, represented by the number of CTUs (TileGroupHeightInCtbsY), can be derived by adding the heights (RowHeight) of each tile in the tile group, as follows: For example, add the height of each tile (RowHeight) by the number of tiles in the tile group (NumTileRowsInTileGroupMinus1[tileGroupIdx]+1).

[0254] tbX = CtbAddrInRs % PicWidthInCtbsY tbY = CtbAddrInRs / PicWidthInCtbsY for(j=0; j<=num_tile_rows_minus1; j++) if(tbY>=RowBd[j]) tileY = j TileHeightInCtbsY = RowHeight[tileY] TileGroupHeightInCtbsY = 0 for(j=0; j<(NumTileRowsInTileGroupMinus1[tileGroupIdx]+1; j=j+1) TileGroupHeightInCtbsY += RowHeight[tileY+j] Here, tileY is a value that indicates the position of the top-left tile of the target tile group within the picture (or sub-picture), and can be derived using the method described above. Note that tileY is a value per tile.

[0255] (Derivation of TileGroupWidthInCtbsY) The CTU number TileGroupWidthInCtbsY, which indicates the width of a tile group, can also be derived as follows: For example, add the height ColWidth of each tile by the number of tiles equal to the width of the tile group (NumTileColsInTileGroupMinus1[tileGroupIdx]+1).

[0256] tbX = CtbAddrInRs % PicWidthInCtbsY tbY = CtbAddrInRs / PicWidthInCtbsY for(i=0; i<=num_tile_columns_minus1; i++) if(tbX>=ColBd[i]) tileX = i TileWidthInCtbsY = ColWidth [tileX] TileGroupWidthInCtbsY = 0 for(j=0; j<(NumTileColsInTileGroupMinus1[tileGroupIdx]+1; j=j+1) TileGroupWidthInCtbsY += ColWidth[tileX+j] Here, tileX is a value that indicates the position of the top-left tile of the target tile group within the tile-level picture (or sub-picture), and may be derived using the method described above.

[0257] As a result of the above configuration, it is possible to share the entry points for tiles and wavefronts within a single tile group (within a segment group).

[0258] Furthermore, it has the effect of enabling tiles (multiple tiles) in one tile group and wavefronts in another tile group.

[0259] (Configuration that enables WPP when there is a rectangular tile group or 1 tile) Figure 32 shows the relationship between a tile group and wavefront processing (CTU row segment) in one embodiment of this model. In the example in Figure 30, WPP was only available when there was one tile in the tile group, but in this example, WPP is available for rectangular tile groups or when there is one tile in the tile group. This figure shows an example where a rectangular tile group is enabled and WPP is enabled for TileGroup0, TileGroup2, and TileGroup4. In TileGroup0 and TileGroup4, multiple tiles are included in the tile group, but WPP is turned on within each tile. Regardless of whether WPP is on or off, the tile group is scanned tile by tile in raster order, and then the CTU is scanned within each tile in raster order (tile scan order).

[0260] Figure 33 shows the syntax configuration of a tile group and wavefront processing header in one embodiment of this model. Figure 35(a) illustrates the operation of the header encoding unit 1110 and the header decoding unit 3020, which have an exclusive configuration of tiles and wavefronts.

[0261] As shown in the syntax configuration and flowchart in the figure, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag (S3002) if the number of tiles in the picture is 1 (single_tile_in_pic_flag==1), or if it is a rectangular tile group (rect_tile_group_flag==1), or if NumTilesInCurrTileGroup==1 (YES in S3001). Otherwise, entropy_coding_sync_enabled_flag is set to 0 (WPP off).

[0262] if (single_tile_in_pic_flag || rect_tile_group_flag || NumTilesInCurrTileGroup==1) entropy_coding_sync_enabled_flag As shown in Figure 32, within the picture, each tile group is scanned sequentially. Within each tile group, each tile is scanned in raster scan order, and within each tile, the CTUs are scanned in raster scan order. In tile groups with WPP off (entropy_coding_sync_enabled_flag==0) (TileGroup1, TileGroup3), the segment is tile-level, and in tile groups with WPP on (entropy_coding_sync_enabled_flag==1) (TileGroup0, TileGroup2, TileGroup4), the segment is CTU row-level within a tile. Except for the first segment of a tile group, the entry point is encoded or decoded. That is, in tile groups with WPP off, there are the number of tiles - 1 entry points, and when WPP is on, there are the number of CTU rows within a tile - 1 entry points. The entry points are as shown in Figure 32.

[0263] The header encoding unit 1110 or the header decoding unit 3020 encodes or decodes the product of the number of horizontal tiles in the tile group (NumTileColumnsInTileGroupMinus1+1) and the number of CTU rows (TileGroupHeightInCtbsY) minus 1 entry points when WPP is on (entropy_coding_sync_enabled_flag==1). When WPP is off (entropy_coding_sync_enabled_flag==0), it encodes or decodes the number of tiles in the tile group (NumTilesInCurrTileGroup-1) entry points. The number of entry points may also be derived using the following formula.

[0264] NumEntryPoint = entropy_coding_sync_enabled_flag ? (NumTileColumnsInTileGroupMinus1+1)*TileGroupHeightInCtbsY-1 : NumTilesInCurrTileGroup-1 The above configuration allows for further division and processing of tiles within a tile group into segments of CTU rows, which has the effect of increasing the number of parallel processes.

[0265] Furthermore, since it is possible to choose whether or not to further divide the tiles within a tile group into CTU row segments, this allows for flexible selection of the degree of parallelism.

[0266] Furthermore, since dividing tiles within a tile group into CTU row segments is limited to rectangular tile groups or when the number of tiles in a tile group is 1, this prevents the processing from becoming complicated when the tile group is not rectangular by dividing it into CTU row segments.

[0267] (Configuration that enables WPP in the case of rectangular tile groups) Figure 34 shows the syntax configuration of a tile group and wavefront processing header in one embodiment of this model. Figure 35(b) illustrates the operation of the header encoding unit 1110 and the header decoding unit 3020 in a configuration having an exclusive configuration of tiles and wavefronts.

[0268] As shown in the figure, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag if the number of tiles in the picture is 1 (single_tile_in_pic_flag==1) or a rectangular tile group (rect_tile_group_flag==1) (S3011) (S3012). Otherwise, entropy_coding_sync_enabled_flag is set to 0 (WPP off).

[0269] if (single_tile_in_pic_flag || rect_tile_group_flag) entropy_coding_sync_enabled_flag Furthermore, the header decoding unit 3020 may derive rect_tile_group_flag as 1 if single_tile_in_pic_flag is 1. For example, if single_tile_per_tile_group_flag does not appear in the encoded data (for example, single_tile_in_pic_flag=1), single_tile_per_tile_group_flag may be derived as 1, and if single_tile_per_tile_group_flag is present, rect_tile_group_flag may be derived as 1. In this case, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes entropy_coding_sync_enabled_flag (S3012) if it is a rectangular tile group (rect_tile_group_flag==1). Otherwise, entropy_coding_sync_enabled_flag is set to 0 (WPP off).

[0270] if (rect_tile_group_flag) entropy_coding_sync_enabled_flag The above configuration allows for further division and processing of tiles within a tile group into segments of CTU rows, which has the effect of increasing the number of parallel processes.

[0271] Furthermore, since the ability to divide tiles within a tile group into CTU row segments is limited to rectangular tile groups, this prevents the processing from becoming complicated when the tile group is not rectangular, by avoiding the need to divide it into CTU row segments. (Tile-based CTU scan order) Figure 37 is a flowchart illustrating the method for deriving the tile-based CTU scan order. The CT information decoding unit 3021 (or parameter decoding unit 302) or the CT information encoding unit 1111 (or header encoding unit 1110) may derive CtbAddrRsToTs[] by the following process.

[0272] (S201) tileGroupTLCol = top_left_tile_idx[i] % (num_tile_columns_minus1+1) tileGroupTLRow = top_left_tile_idx[i] / (num_tile_columns_minus1+1) tileGroupXInCtbY = 0 tileGroupYInCtbY = 0 for (j=0; j <tileGroupTLCol; j++) tileGroupXInCtbY = tileGroupXInCtbY+ColWidth[j] for (j=0; j <tileGroupTLRow; j++) tileGroupYInCtbY = tileGroupYInCtbY+RowHeight[j] tileYInCtb = tileGroupYInCtbY (S202) for (row=0; row<=NumTileRowsInTileGroupMinus1[i]; row++) { / / TileRasterScanInTileGroup tileYInCtb = tileYInCtb+RowHeight[tileGroupTLRow+row] tileXInCtb = tileGroupXInCtbY for (col=0; col<=NumTileColsInTileGroupMinus1[i]; col++) { / / TileRasterScanInTileGroup tileXInCtb = tileXInCtb+ColWidth[tileGroupTLCol+col] (S203) for (y=0; y<RowHeight[tileGroupTLRow+row]; y++) { / / CtbRasterScan in Tile for (x=0; x<ColWidth[tileGroupTLCol+col]; x++) { / / CtbRasterScan in Tile (S204) ctbAddrRs = (x+tileXInCtb)+(y+tileYInCtb)*PicHeightInCtbsY (S205) CtbAddrRsToTs[ctbAddrRs] = ctbAddrTs CtbAddrTsToRs[ctbAddrTs] = ctbAddrRs (S206) ctbAddrTs++ } } } } S201: Derive the top-left tile addresses tileGroupTLCol and tileGroupTLRow for the tile group. Derive the top-left CTU addresses tileGroupXInCtbY and tileGroupYInCtbY for the tile group.

[0273] S202: Raster scan the tiles of the target tile group using the tile-level height (NumTileRowsInTileGroupMinus1) and tile-level width (NumTileColumnsInTileGroupMinus1) of the tile group.

[0274] S203: Raster scan the CTUs within a tile using the tile's height (ColHeight) and ColWidth (ColWidth) in CTU units.

[0275] S204: The raster scan CTU address ctbAddrRs within the picture of the target CTU is derived from the X coordinate (x + tileGroupXInCtbY) and Y coordinate (y + tileGroupYInCtbY) of the CTU unit within the picture.

[0276] S205: Store the CTU address in a table that associates ctbAddrRs and ctbAddrTs. Here, both CtbAddrRsToTs[] and CtbAddrTsToRs[] are derived, but it is also possible to derive only one (for example, CtbAddrRsToTs[]) and then use (method 0 for deriving the CTU scan order in the picture) to derive the other (CtbAddrTsToRs[]).

[0277] S206: Increment ctbAddrTs by 1.

[0278] In this example, WPP is enabled for rectangular tile groups or when there is only one tile in a tile group. Figure 36 shows an example where WPP is enabled for rectangular tile groups, TileGroup0, TileGroup2, and TileGroup4. Also, when WPP is enabled for a rectangular tile group, the CTUs are scanned in raster scan order within the tile group, rather than scanning within each tile in raster scan order. In other words, the scan order for the 2x3 tiles of TileGroup0 is as follows. When WPP is off, the tile group is scanned tile by tile in raster order, and then the CTUs are scanned in raster order within each tile. When WPP is on, the CTUs are scanned for each tile group without distinguishing between tiles within the tile group. For example, if the CTUs in a picture are arranged in raster order as follows, and each tile consists of 3x3 CTUs, 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 When WPP is off, the CTU scan order for TileGroup0 is as follows:

[0279] 0 1 2 12 13 14 24 25 26 3 4 5 15 16 17 27 28 29 36 37 38 48 49 50 60 61 62 39 40 41 51 52 53 63 64 65 72 73 74 84 85 86 96 97 98 75 76 77 87 88 89 99 100 101 When WPP is enabled, the CTU scan order for TileGroup0 is as follows:

[0280] 0 1 2 3 4 5 12 13 14 15 16 17 24 25 26 27 28 29 36 37 38 39 40 41 48 49 50 51 52 53 60 61 62 63 64 65 72 73 74 75 76 77 84 85 86 87 88 89 96 97 98 99 100 101 Figure 39 shows the syntax configuration of a tile group and a wavefront processing header in one embodiment of this model.

[0281] Furthermore, the header encoding unit 1110 and the header decoding unit 3020 may derive the number of tiles included in the target tile group using the following formula at the time of encoding and decoding the tile group header using the following formula.

[0282] NumTilesInCurrTileGroup = rect_tile_group_flag ? NumTilesInTileGroup[ tileGroupIdx ] : (num_tiles_in_tile_group_minus1 + 1) The header encoding unit 1110 and the header decoding unit 3020 encode or decode the entropy_coding_sync_enabled_flag when the number of tiles in the picture is 1 (single_tile_in_pic_flag==1), or when it is a rectangular tile group (rect_tile_group_flag==1), or when the number of tiles included in the tile group, NumTilesInCurrTileGroup, is 1.

[0283] if (single_tile_in_pic_flag || rect_tile_group_flag || NumTilesInCurrTileGroup == 1) entropy_coding_sync_enabled_flag Furthermore, the header encoding unit 1110 and the header decoding unit 3020 may be configured to encode or decode the entropy_coding_sync_enabled_flag when the number of tiles in the picture is 1 (single_tile_in_pic_flag==1) or when it is a rectangular tile group (rect_tile_group_flag==1).

[0284] if (single_tile_in_pic_flag || rect_tile_group_flag) entropy_coding_sync_enabled_flag (Method 2 for deriving the CTU scan order within a picture: Tile group-based CTU scan order) If the entropy_coding_sync_enabled_flag notified in the picture parameter set is on, the CT information decoding unit 3021 may derive CtbAddrRsToTs[] by the following process. In this derivation method, the CTU scan order is derived by scanning within the picture in tile group order (TileGroupLoop) and then raster scanning within the tile group in CTU order (CtbRasterScan in TileGroup). Figure 38(b) shows a flowchart of this configuration. If the entropy_coding_sync_enabled_flag notified on a picture-by-picture basis is off, CtbAddrRsToTs[] is derived using the tile-based CTU scan order, as already explained in Method 1 for Deriving the CTU Scan Order within a Picture.

[0285] With the above configuration, when WPP is enabled and a tile group consists of multiple tiles, changing the CTU scan order allows a single area containing tiles within a tile group to be divided into CTU row segments. This improves performance by avoiding unnecessary division of tile groups. Furthermore, because the segmentation of tiles and WPP (CTU rows) is mutually exclusive within a tile group, processing is simplified.

[0286] The structure of the tile group header is as shown in Figure 41(a), and is the same as in Figure 39 except that it does not include entropy_coding_sync_enabled_flag. That is, the number of entry points is derived using the following formula.

[0287] NumEntryPoint = entropy_coding_sync_enabled_flag ? TileGroupHeightInCtbsY-1 : NumTilesInCurrTileGroup-1 <Configuration for transmitting the WPP enable flag via parameter set> The following describes a configuration in which the WPP enable flag is notified via a parameter set rather than the tile group header. This configuration has the common effect of allowing determination of whether parallel segment decoding is possible before decoding the tile group. Furthermore, because the use of WPP is selected on a picture-by-picture basis, the location of the entry point is clearly defined across the entire screen. Additionally, it facilitates capability exchange between the video decoding device and the video encoding device or image transmission system.

[0288] (Parameter set transmission + tile-based CTU scan) Figure 42 shows the syntax configuration of a tile group and wavefront processing parameter set in one embodiment of this model. In this configuration, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes one entropy_coding_sync_enabled_flag in the picture in the parameter set, rather than in the tile group header.

[0289] Figure 40 shows the relationship between a tile group and wavefront processing (CTU row segment) in one embodiment of this model. Figure 40 shows an example where WPP is used for all tile groups, TileGroup0, TileGroup1, TileGroup2, TileGroup3, and TileGroup4. In this configuration, the use of WPP is selected on a picture-by-picture basis, which has the effect of simplifying the processing of the decoding device.

[0290] In this embodiment, a tile-based scan (scanning is performed on tiles within a tile group, and CTUs are scanned within the tiles) is performed, as described in Method 1 for deriving the CTU scan order within the picture and in Figure 37. Therefore, a tile group is divided into segments having the width of the horizontal tiles included in the tile group and the height of the CTUs. The number of segments in a tile group is the product of the number of horizontal tiles (NumTileColumnsInTileGroupMinus1+1) and the number of CTU rows (TileGroupHeightInCtbsY). The structure of the tile group header is as shown in Figure 41(b), and does not notify entropy_coding_sync_enabled_flag. Instead, it refers to the entropy_coding_sync_enabled_flag in the picture parameter set. Here, the number of segments - 1 entry points are decoded.

[0291] NumEntryPoint = entropy_coding_sync_enabled_flag ? (NumTileColumnsInTileGroupMinus1+1)*TileGroupHeightInCtbsY-1 : NumTilesInCurrTileGroup-1 In this configuration, whether or not a tile group is rectangular can be identified by the picture parameter set, which has the effect of allowing us to know whether parallel decoding of segments is possible before decoding the tile group.

[0292] Furthermore, in a decoding device that decodes encoded data restricted to setting entropy_coding_sync_enabled_flag to 1 only when the number of tiles in a picture is 1 or the number of tiles in a tile group is 1, the following number of entry points are decoded as shown in the configuration in Figure 41(a).

[0293] NumEntryPoint = entropy_coding_sync_enabled_flag ? TileGroupHeightInCtbsY-1 : NumTilesInCurrTileGroup-1 In this case, the effect is that tiles and CTU row segments can be processed exclusively within the tile group.

[0294] (Parameter set transmission + tile-based CTU scan + rectangular tile group configuration 3) In the case of a tile group containing two or more tiles (tile index i), a video decoding device that decodes encoded data with entropy_coding_sync_enabled_flag[i] always set to 1 has the effect of exclusively processing tiles and CTU row segments within the tile group.

[0295] In this configuration, a tile group is divided into segments with CTU height. The number of segments in a tile group is equal to the number of CTU rows (TileGroupHeightInCtbsY). The structure of the tile group header is as shown in Figure 41(a), and it refers to the entropy_coding_sync_enabled_flag in the picture parameter set without including entropy_coding_sync_enabled_flag. Here, we decode entry points of the number of segments minus 1 (TileGroupHeightInCtbsY-1).

[0296] NumEntryPoint = entropy_coding_sync_enabled_flag ? TileGroupHeightInCtbsY-1 : NumTilesInCurrTileGroup-1 (Parameter set transmission + tile group-based CTU scan order) The following describes a configuration in which the WPP enable flag is notified via a parameter set rather than the tile group header, and when the WPP enable flag is 1, the CTU scan order within the tile group is changed from the tile-based CTU scan order to the tile group-based CTU scan order.

[0297] (Parameter set transmission + tile group-based CTU scan order) Figure 42 shows the syntax configuration of a tile group and wavefront processing parameter set in one embodiment of this model. In this configuration, the header encoding unit 1110 or the header decoding unit 3020 encodes or decodes one entropy_coding_sync_enabled_flag in the picture in the parameter set, rather than in the tile group header.

[0298] In this configuration, tile groups are divided into segments with CTU height. The number of segments in a tile group is equal to the number of CTU rows (TileGroupHeightInCtbsY). The structure of the tile group header is as shown in Figure 41(a), and it refers to the entropy_coding_sync_enabled_flag in the picture parameter set without including entropy_coding_sync_enabled_flag. Here, entry points of the number of segments minus 1 (TileGroupHeightInCtbsY - 1) are decoded.

[0299] NumEntryPoint = entropy_coding_sync_enabled_flag ? TileGroupHeightInCtbsY-1 : NumTilesInCurrTileGroup-1 The reference picture memory 306 stores the decoded image of the CU generated by the adder 312 at a predetermined location for each target picture and target CU.

[0300] The prediction parameter memory 307 stores prediction parameters at predetermined locations for each CTU or CU to be decoded. Specifically, the prediction parameter memory 307 stores the parameters decoded by the parameter decoding unit 302 and the prediction mode predMode separated by the entropy decoding unit 301.

[0301] Prediction parameters and other information are input to the prediction image generation unit 308. The prediction image generation unit 308 also reads a reference picture from the reference picture memory 306. The prediction image generation unit 308 generates a block or subblock of prediction image using the prediction parameters and the reference picture (reference picture block). Here, a reference picture block is a collection of pixels on the reference picture (usually rectangular, hence called a block), and is the area referenced to generate the prediction image.

[0302] The inverse quantization / inverse transformation unit 311 inversely quantizes the quantization transformation coefficients input from the entropy decoding unit 301 to obtain the transformation coefficients. These quantization transformation coefficients are obtained by quantizing the prediction error in the encoding process by performing a frequency transformation such as the Discrete Cosine Transform (DCT). The inverse quantization / inverse transformation unit 311 performs an inverse frequency transformation such as the inverse DCT on the obtained transformation coefficients to calculate the prediction error. The inverse quantization / inverse transformation unit 311 outputs the prediction error to the summing unit 312.

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

[0304] (Configuration of the video encoding device) Next, the configuration of the video encoding device 11 according to this embodiment will be described. Figure 24 is a block diagram showing the configuration of the video encoding device 11 according to this embodiment. The video encoding device 11 is composed of a prediction image generation unit 101, a subtraction unit 102, a transformation / quantization unit 103, an inverse quantization / inverse transformation unit 105, an addition unit 106, a loop filter 107, a prediction parameter memory 109, an encoding parameter determination unit 110, a parameter encoding unit 111, and an entropy encoding unit 104.

[0305] The predictive image generation unit 101 generates a predictive image for each CU, which is a region obtained by dividing each picture of image T. The predictive image generation unit 101 operates in the same way as the predictive image generation unit 308, which has already been described.

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

[0307] The conversion / quantization unit 103 calculates conversion coefficients by frequency conversion for the prediction error input from the subtraction unit 102, and derives quantized conversion coefficients by quantization. The conversion / quantization unit 103 outputs the quantized conversion coefficients to the entropy coding unit 104 and the inverse quantization / inverse conversion unit 105.

[0308] The inverse quantization / inverse transformation unit 105 is the same as the inverse quantization / inverse transformation unit 311 (Figure 9) in the video decoding device 31. The calculated prediction error is output to the summing unit 106.

[0309] The parameter coding unit 111 includes a header coding unit 1110, a CT information coding unit 1111, a CU coding unit 1112 (predictive mode coding unit), an entropy coding unit 104, and an inter-predictive parameter coding unit 112 and an intra-predictive parameter coding unit 113 (not shown). The CU coding unit 1112 further includes a TU coding unit 1114.

[0310] The following describes the general operation of each module. The parameter coding unit 111 performs encoding processing on parameters such as header information, partitioning information, prediction information, and quantization conversion coefficients.

[0311] The CT information encoding unit 1111 encodes QT, MT (BT, TT) division information, etc.

[0312] The CU encoding unit 1112 encodes CU information, prediction information, TU partitioning flag, CU residual flag, etc.

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

[0314] The entropy coding unit 104 converts the syntax elements input from the source into binary data, generates coded data using an entropy coding scheme such as CABAC, and outputs it. In the example shown in Figure 24, the sources of the syntax elements are the CT information coding unit 1111 and the CU coding unit 1112.

[0315] The addition unit 106 generates a decoded image by adding the pixel values ​​of the predicted image of the block input from the predicted image generation unit 101 and the prediction error input from the inverse quantization / inverse transform unit 105 for each pixel. The addition unit 106 stores the generated decoded image in the reference picture memory 109.

[0316] The loop filter 107 applies a deblocking filter, SAO, and ALF to the decoded image generated by the summing unit 106. Note that the loop filter 107 does not necessarily have to include the three types of filters mentioned above.

[0317] The prediction parameter memory 108 stores the prediction parameters generated by the coding parameter determination unit 110 in predetermined locations for each target picture and CU.

[0318] The reference picture memory 109 stores the decoded images generated by the loop filter 107 at predetermined locations for each target picture and CU.

[0319] The coding parameter determination unit 110 selects one set from among several sets of coding parameters. The coding parameters are the QT, BT, or TT segmentation information, prediction parameters, or parameters that are to be coded and generated in relation to these. The prediction image generation unit 101 generates a prediction image using these coding parameters.

[0320] The coding parameter determination unit 110 calculates the RD cost value, which indicates the amount of information and coding error, for each of the multiple sets, and selects the set of coding parameters that minimizes the cost value. As a result, the entropy coding unit 104 outputs the selected set of coding parameters as a coded stream Te. The coding parameter determination unit 110 stores the determined coding parameters in the prediction parameter memory 108.

[0321] Furthermore, some parts of the video encoding device 11 and video decoding device 31 in the above-described embodiment, such as the entropy decoding unit 301, parameter decoding unit 302, loop filter 305, prediction image generation unit 308, inverse quantization / inverse transformation unit 311, addition unit 312, prediction image generation unit 101, subtraction unit 102, transformation / quantization unit 103, entropy encoding unit 104, inverse quantization / inverse transformation unit 105, loop filter 107, encoding parameter determination unit 110, and parameter encoding unit 111, may be implemented using a computer. In that case, a program for realizing this control function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be loaded into a computer system and executed. Hereinafter, "computer system" refers to a computer system built into either the video encoding device 11 or the video decoding device 31, and includes hardware such as an OS and peripheral devices. Furthermore, "computer-readable recording media" refers to portable media such as flexible disks, magneto-optical disks, ROMs, and CD-ROMs, as well as storage devices such as hard disks built into computer systems. In addition, "computer-readable recording media" may also include those that dynamically hold programs for a short period of time, such as communication lines used when transmitting programs over networks such as the Internet or communication lines such as telephone lines, and those that hold programs for a certain period of time, such as volatile memory inside computer systems that act as servers or clients in such cases. Moreover, the above-mentioned programs may be for the purpose of realizing some of the functions described above, and may also be programs that can realize the aforementioned functions in combination with programs already recorded in the computer system.

[0322] Furthermore, some or all of the video encoding device 11 and video decoding device 31 in the above-described embodiment may be implemented as an integrated circuit such as an LSI (Large Scale Integration). Each functional block of the video encoding device 11 and video decoding device 31 may be individually implemented as a processor, or some or all of them may be integrated into a single processor. In addition, the method of implementing the integrated circuit is not limited to LSIs; it may also be implemented using dedicated circuits or general-purpose processors. Furthermore, if an integrated circuit technology that can replace LSIs emerges due to advances in semiconductor technology, an integrated circuit using that technology may be used.

[0323] Although one embodiment of this invention has been described in detail above with reference to the drawings, the specific configuration is not limited to that described above, and various design changes can be made without departing from the spirit of this invention.

[0324] [Application Examples] The video encoding device 11 and video decoding device 31 described above can be installed and used in various devices that transmit, receive, record, and play back video. The video may be natural video captured by a camera or the like, or it may be artificial video (including CG and GUI) generated by a computer or the like.

[0325] First, with reference to Figure 2, we will explain how the aforementioned video encoding device 11 and video decoding device 31 can be used for transmitting and receiving video.

[0326] Figure 2(a) is a block diagram showing the configuration of the transmitter PROD_A equipped with the video encoding device 11. As shown in Figure 2(a), the transmitter PROD_A includes an encoding unit PROD_A1 that obtains encoded data by encoding video, a modulation unit PROD_A2 that obtains a modulated signal by modulating a carrier wave with the encoded data obtained by the encoding unit PROD_A1, and a transmitter PROD_A3 that transmits the modulated signal obtained by the modulation unit PROD_A2. The video encoding device 11 described above is used as this encoding unit PROD_A1.

[0327] The transmitting device PROD_A may further include a camera PROD_A4 for capturing moving images, a recording medium PROD_A5 for recording the moving images, an input terminal PROD_A6 for receiving moving images from an external source, and an image processing unit A7 for generating or processing images, as sources for supplying moving images to the encoding unit PROD_A1. Figure 2(a) illustrates a configuration in which the transmitting device PROD_A includes all of these components, but some may be omitted.

[0328] The recording medium PROD_A5 may contain unencoded video footage, or it may contain video footage encoded using a recording encoding method different from the transmission encoding method. In the latter case, a decoding unit (not shown) may be interposed between the recording medium PROD_A5 and the encoding unit PROD_A1 to decode the encoded data read from the recording medium PROD_A5 according to the recording encoding method.

[0329] Figure 2(b) is a block diagram showing the configuration of the receiver PROD_B equipped with the video decoding device 31. As shown in Figure 2(b), the receiver PROD_B includes a receiver PROD_B1 that receives a modulated signal, a demodulation unit PROD_B2 that obtains encoded data by demodulating the modulated signal received by the receiver PROD_B1, and a decoding unit PROD_B3 that obtains a video by decoding the encoded data obtained by the demodulation unit PROD_B2. The video decoding device 31 described above is used as this decoding unit PROD_B3.

[0330] The receiving device PROD_B may further include a display PROD_B4 for displaying the video, a recording medium PROD_B5 for recording the video, and an output terminal PROD_B6 for outputting the video to the outside, as recipients of the video output from the decoding unit PROD_B3. Figure 2(b) illustrates a configuration in which the receiving device PROD_B includes all of these, but some may be omitted.

[0331] The recording medium PROD_B5 may be for recording unencoded video, or it may be encoded using a recording encoding method different from the transmission encoding method. In the latter case, it is preferable to interpose an encoding unit (not shown) between the decoding unit PROD_B3 and the recording medium PROD_B5, which encodes the video acquired from the decoding unit PROD_B3 according to the recording encoding method.

[0332] The transmission medium for transmitting the modulated signal may be wireless or wired. Furthermore, the transmission method for transmitting the modulated signal may be broadcasting (referring here to a transmission method where the destination is not predetermined) or communication (referring here to a transmission method where the destination is predetermined). In other words, the transmission of the modulated signal may be achieved by wireless broadcasting, wired broadcasting, wireless communication, or wired communication.

[0333] For example, a terrestrial digital broadcasting station (broadcasting equipment, etc.) / receiving station (television receiver, etc.) is an example of a transmitting device PROD_A / receiving device PROD_B that transmits and receives modulated signals wirelessly. Similarly, a cable television broadcasting station (broadcasting equipment, etc.) / receiving station (television receiver, etc.) is an example of a transmitting device PROD_A / receiving device PROD_B that transmits and receives modulated signals via wired broadcasting.

[0334] Furthermore, servers (such as workstations) and clients (such as television sets, personal computers, and smartphones) for internet-based VOD (Video On Demand) services and video sharing services are examples of transmitting devices PROD_A and receiving devices PROD_B that transmit and receive modulated signals via communication (typically, either wireless or wired transmission is used as the transmission medium in a LAN, and wired transmission is used in a WAN). Here, personal computers include desktop PCs, laptop PCs, and tablet PCs. Smartphones also include multi-function mobile phones.

[0335] Furthermore, the video sharing service client has the function of decrypting encoded data downloaded from the server and displaying it on the screen, as well as the function of encoding video images captured by the camera and uploading them to the server. In other words, the video sharing service client functions as both a transmitting device PROD_A and a receiving device PROD_B.

[0336] Next, with reference to Figure 3, we will explain how the aforementioned video encoding device 11 and video decoding device 31 can be used for recording and playing back video.

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

[0338] The recording medium PROD_M may be (1) a type built into the recording device PROD_C, such as an HDD (Hard Disk Drive) or SSD (Solid State Drive), (2) a type connected to the recording device PROD_C, such as an SD memory card or USB (Universal Serial Bus) flash memory, or (3) a type loaded into a drive device (not shown) built into the recording device PROD_C, such as a DVD (Digital Versatile Disc: registered trademark) or BD (Blu-ray Disc: registered trademark).

[0339] Furthermore, the recording device PROD_C may also include a camera PROD_C3 for capturing moving images, an input terminal PROD_C4 for receiving moving images from an external source, a receiving unit PROD_C5 for receiving moving images, and an image processing unit PROD_C6 for generating or processing images, as sources of moving images to be input to the encoding unit PROD_C1. Figure 3(a) illustrates a configuration in which the recording device PROD_C includes all of these components, but some may be omitted.

[0340] The receiving unit PROD_C5 may receive unencoded video footage, or it may receive encoded data encoded using a transmission encoding scheme different from the recording encoding scheme. In the latter case, it is preferable to interpose a transmission decoding unit (not shown) between the receiving unit PROD_C5 and the encoding unit PROD_C1 to decode the encoded data encoded using the transmission encoding scheme.

[0341] Examples of such recording devices PROD_C include DVD recorders, BD recorders, and HDD (Hard Disk Drive) recorders (in this case, the input terminal PROD_C4 or the receiver PROD_C5 is the main source of moving images). Camcorders (in this case, the camera PROD_C3 is the main source of moving images), personal computers (in this case, the receiver PROD_C5 or the image processing unit C6 is the main source of moving images), and smartphones (in this case, the camera PROD_C3 or the receiver PROD_C5 is the main source of moving images) are also examples of such recording devices PROD_C.

[0342] Figure 3(B) is a block diagram showing the configuration of the playback device PROD_D equipped with the video decoding device 31 described above. As shown in Figure 3(b), the playback device PROD_D includes a reading unit PROD_D1 that reads encoded data written to the recording medium PROD_M, and a decoding unit PROD_D2 that obtains a video by decoding the encoded data read by the reading unit PROD_D1. The video decoding device 31 described above is used as this decoding unit PROD_D2.

[0343] The recording medium PROD_M may be (1) a type built into the playback device PROD_D, such as an HDD or SSD; (2) a type connected to the playback device PROD_D, such as an SD memory card or USB flash memory; or (3) a type loaded into a drive device (not shown) built into the playback device PROD_D, such as a DVD or BD.

[0344] Furthermore, the playback device PROD_D may also include a display PROD_D3 for displaying the video, an output terminal PROD_D4 for outputting the video externally, and a transmission unit PROD_D5 for transmitting the video, as recipients of the video output from the decoding unit PROD_D2. Figure 3(b) illustrates a configuration in which the playback device PROD_D includes all of these components, but some may be omitted.

[0345] The transmitting unit PROD_D5 may transmit unencoded video footage, or it may transmit encoded data encoded using a transmission encoding scheme different from the recording encoding scheme. In the latter case, it is preferable to interpose an encoding unit (not shown) between the decoding unit PROD_D2 and the transmitting unit PROD_D5 to encode the video footage using the transmission encoding scheme.

[0346] Examples of such playback devices PROD_D include DVD players, BD players, and HDD players (in this case, the output terminal PROD_D4 to which a television receiver is connected becomes the main destination for the video). Other examples of such playback devices PROD_D include television receivers (in this case, the display PROD_D3 becomes the main destination for the video), digital signage (also called electronic billboards or electronic display boards, etc., where the display PROD_D3 or the transmitter PROD_D5 becomes the main destination for the video), desktop PCs (in this case, the output terminal PROD_D4 or the transmitter PROD_D5 becomes the main destination for the video), laptop or tablet PCs (in this case, the display PROD_D3 or the transmitter PROD_D5 becomes the main destination for the video), and smartphones (in this case, the display PROD_D3 or the transmitter PROD_D5 becomes the main destination for the video).

[0347] (Hardware implementation and software implementation) Furthermore, each block of the video decoding device 31 and video encoding device 11 described above may be implemented in hardware by logic circuits formed on an integrated circuit (IC chip), or it may be implemented in software using a CPU (Central Processing Unit).

[0348] In the latter case, each of the above devices includes a CPU that executes instructions for the program that realizes each function, a ROM (Read Only Memory) that stores the program, a RAM (Random Access Memory) that loads the program, and a storage device (recording medium) such as memory that stores the program and various data. Furthermore, the objective of the embodiment of the present invention can also be achieved by supplying each of the above devices with a recording medium on which the program code (executable program, intermediate code program, source program) of the control program of each of the above devices, which is software that realizes the above functions, is recorded in a way that can be read by a computer, and the computer (or CPU or MPU) reads and executes the program code recorded on the recording medium.

[0349] Examples of recording media that can be used include tapes such as magnetic tapes and cassette tapes, magnetic disks such as floppy disks and hard disks, optical disks such as CD-ROMs (Compact Disc Read-Only Memory), MO disks (Magneto-Optical discs), MDs (Mini Discs), DVDs (Digital Versatile Discs), CD-Rs (CD Recordable), and Blu-ray Discs (Blu-ray Discs: registered trademarks), cards such as IC cards (including memory cards) and optical cards, semiconductor memories such as mask ROMs, EPROMs (Erasable Programmable Read-Only Memory), EEPROMs (Electrically Erasable and Programmable Read-Only Memory: registered trademarks), and flash ROMs, or logic circuits such as PLDs (Programmable logic devices) and FPGAs (Field Programmable Gate Arrays).

[0350] Furthermore, each of the above devices may be configured to be connectable to a communication network, and the program code may be supplied via the communication network. This communication network is not particularly limited, as long as it is capable of transmitting the program code. For example, the Internet, intranet, extranet, LAN (Local Area Network), ISDN (Integrated Services Digital Network), VAN (Value-Added Network), CATV (Community Antenna television / Cable Television) communication network, Virtual Private Network, telephone line network, mobile communication network, satellite communication network, etc., can be used. Also, the transmission medium constituting this communication network is not limited to a specific configuration or type, as long as it is capable of transmitting the program code. For example, it can be used with wired connections such as IEEE (Institute of Electrical and Electronic Engineers) 1394, USB, power line carriers, cable TV lines, telephone lines, and ADSL (Asymmetric Digital Subscriber Line) lines, as well as wireless connections such as IrDA (Infrared Data Association), infrared (like remote controls), Bluetooth®, IEEE 802.11 wireless, HDR (High Data Rate), NFC (Near Field Communication), DLNA (Digital Living Network Alliance®), mobile phone networks, satellite lines, and terrestrial digital broadcasting networks. Furthermore, embodiments of the present invention can also be realized in the form of computer data signals embedded in a carrier wave, where the above program code is embodied through electronic transmission.

[0351] The embodiments of the present invention are not limited to those described above, and various modifications are possible within the scope of the claims. That is, embodiments obtained by combining technical means that have been appropriately modified within the scope of the claims are also included in the technical scope of the present invention.

[0352] (Cross-reference of related applications) This application claims priority over Japanese Patent Application No. 2019-021630, filed on February 8, 2019, and Japanese Patent Application No. 2019-057031, filed on March 25, 2019, and all of their contents are included in this document by reference. [Industrial applicability]

[0353] Embodiments of the present invention can be suitably applied to a video decoding device that decodes encoded data from image data, and a video encoding device that generates encoded data from image data. Furthermore, they can be suitably applied to the data structure of encoded data generated by the video encoding device and referenced by the video decoding device. [Explanation of symbols]

[0354] 11. Video Encoding Device 31. Video Decoder 101, 308 Predictive Image Generation Unit 104 Entry lobby encoding unit (encoding unit) 107, 305 Loop Filter 111 Parameter coding section 301 Entropy Decoder 302 Parameter decoding unit (splitting unit) 3020 Header Decoding Section 3021 CT Information Decoding Unit 3022 CU Decoding Unit 109, 306 Reference picture memory 108, 307 Prediction parameter memory 105, 311 Inverse Quantization / Inverse Transformation Section 102 Subtraction Unit 103 Conversion / Quantization Section 104 Entropy coding unit 106 Addition section 110 Encoding parameter determination unit 1110 Header Encoding Section 1111 CT information encoder 1112 CU Symbolization Section

Claims

1. In a video decoding device that decodes encoded data, It includes a flag indicating whether or not Context-adaptive binary arithmetic coding (CABAC) synchronization is performed, a 1-bit syntax element, and a bit sequence for byte alignment, and a decoding unit that decodes these. If the value of the aforementioned flag is 1, A video decoding device characterized in that the bit sequence for byte alignment is decoded when it is the last CTU in a CTU row, rather than the last CTU in a tile group.

2. The motion image decoding apparatus according to claim 1, characterized in that the bit sequence for byte alignment is omitted in the last CTU of the tile group.

3. In a video encoding device that generates encoded data, It comprises a flag indicating whether or not Context-adaptive binary arithmetic coding (CABAC) synchronization processing is performed, a 1-bit syntax element, and an encoding unit that encodes a bit sequence for byte alignment. If the value of the aforementioned flag is 1, A video encoding device characterized in that the bit sequence for byte alignment is encoded when it is the last CTU in a CTU row, rather than the last CTU in a tile group.

4. In an integrated circuit that decodes encoded data, It includes a flag indicating whether or not Context-adaptive binary arithmetic coding (CABAC) synchronization is performed, a 1-bit syntax element, and a bit sequence for byte alignment, and a decoding unit that decodes these. If the value of the aforementioned flag is 1, An integrated circuit characterized in that the bit sequence for byte alignment is decoded when it is the last CTU in a CTU row, rather than the last CTU in a tile group.

Images