GB2584723A

GB2584723A - Method, device, and computer program for coding and decoding a picture

Info

Publication number: GB2584723A
Application number: GB1908535.6A
Authority: GB
Inventors: Ouedraogo Naël; Nassor Eric
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-06-13
Filing date: 2019-06-13
Publication date: 2020-12-16
Also published as: GB201908535D0

Abstract

A method for encoding a picture comprising a data array with a first dimension and a second dimension, comprising: partitioning the data array into a set of rectangular tiles in which all tiles have a side of length equal to the size of the first dimension of the data array; and partitioning at least one of the tiles into a set of rectangular bricks. All bricks of the set have a side of length equal to the size of the side of the tile to which the bricks belong in the second dimension of the data array. The first and second dimensions may be the height and width respectively of the picture, so that the tiles form one row of rectangular columns and each tile contains one column of rectangular bricks. The method further comprises obtaining a brick scanning order information and using it to encode each brick of the picture. Syntax elements, relating to brick scanning order and brick partitioning, may be associated with the encoded picture. A corresponding decoding method, computer program and signal are disclosed.

Description

METHOD, DEVICE, AND COMPUTER PROGRAM FOR CODING AND DECODING A

PICTURE

FIELD OF THE INVENTION

The present invention relates to a method, a device, and a computer program for encoding and decoding pictures.

BACKGROUND OF THE INVENTION

To encode an image, a technique often used is to partition it into picture portions which are then encoded independently of each other. The whole is then grouped together to form the encoded image. The decoding of the image is then carried out in the opposite direction by decoding the encoded picture portions and then assembling the result of the decoding to reconstitute the initial image.

The compression of video relying on block-based video encoding is used in most coding systems like HEVC (High Efficiency Video Coding), or the emerging VVC (Versatile Video Coding) standards.

In these encoding systems, a video is composed of a sequence of frames or pictures or images or samples which may be displayed at several different times. In the case of multi-layered video (for example scalable, stereo, 3D videos), several pictures may be decoded to compose the resulting image to display at one instant. A picture can also be composed of different image components. For instance, for encoding the luminance, the chrominance or depth information.

Typically, these encoding systems rely on several partitioning techniques for each picture. Historically, a partitioning technique was based on a grid of tiles. A tile is a picture part, generally with a rectangular shape, in which the file boundaries break spatial encoding dependencies, i.e., the encoding does not depend on information from picture part outside the tile.

Then, for technical reasons outside the scope of this text, it appears that it was advantageous to introduce brick partitioning. A brick is a subset, of rectangular shape, of a file or, in other words, a tile comprises a set of bricks.

SUMMARY OF THE INVENTION

However, the introduction of the two levels of partitioning has created complexity in the encoding organization of the different elements with the need to add parameters into the encoded bit stream resulting from the encoding method in order for a decoder to understand the relationship between all entities.

The present invention has been devised to address one or more of the foregoing concerns.

In a first example embodiment, a method for encoding a picture comprising a data array with a first dimension and a second dimension, comprises partitioning the data array into a set of rectangular tiles in which all tiles have a side of length equal to the size of the first dimension of the data array, partitioning at least one of the tiles into a set of rectangular bricks in which all bricks of the set have a side of length equal to the size of the side of the tile to which the bricks belong in the second dimension of the data array, obtaining a brick scanning order information, and then encoding the picture by encoding each brick based on the obtained brick scanning order information.

Accordingly, the method advantageously reduces the number of syntax elements required to describe the partitioning in comparison to the prior art. In addition, the resulting bit stream size is reduced.

This embodiment may comprise other features, alone or in combination, such as: the first dimension is associated with the height of the picture and the second dimension is associated with the width of the picture, so that the tiles form one row of rectangular columns and each tile contains one column of rectangular bricks; the set of files comprises n tiles, n being a strictly positive integer, the sizes of at least n-1 tiles in the second dimension being equal; -for at least one tile of the set of tiles, the sizes of the bricks contained in the file are equal in the first dimension; the brick partition is identical for all the tiles; the encoding of the picture comprises defining a first syntax element associated with the encoded picture, said syntax element comprising the brick scanning order information; the encoding of the picture further comprises defining a second syntax element associated with at least one tile and describing the brick partitioning of the at least one tile; the brick partitioning is only defined in the second syntax element associated with a reference tile when the brick partition is identical for several tiles of the set; the reference file corresponds to a first file in a tile scanning order; - when the brick partitioning of the tile is identical to the brick partitioning of a previous tile in a tile scanning order, the second syntax element associated with the tile contains a reference to the second syntax element of the previous tile; - the brick scanning order information includes a scan order across the tiles in which the bricks are encoded by following a raster scan direction, or includes a scan order within the tile in which all bricks of a file are encoded before encoding the bricks of the following file; when the scan order across the tiles is such that the bricks are encoded by following a raster scan direction, the brick partitioning is constrained so that it forms a grid of bricks; the method comprises further, after partitioning the tiles, defining at least one slice comprising a set of adjacent bricks; - the slice forms a rectangular shape comprising bricks of at least two tiles, the bricks of at least one tile forming a subset of the set of bricks partitioning the tile; the slice is defined in the first syntax element by reference to the first brick and to the last brick in the brick scanning order of the set of bricks part of the slice; and/or the data array is partitioned into a set of rectangular slices such that the first brick of a slice of the set is encoded after the bricks of the previously encoded slices.

Among the advantages of these features, the partitioning of a picture in files and bricks is unique for a given pattern of regions; the compression rate of the bit stream is higher for repetitive brick patterns across the files; the number of syntax elements is reduced and thus the size of the partitioning description is likely to decrease; the tile and brick partitioning is uncoupled from the processing order; a consistent scanning order is ensured.

According to a second aspect of the invention, there is provided a method for decoding an encoded picture comprising at least tiles and bricks, comprising: determining a tile partitioning of the encoded picture, determining a brick partitioning of the encoded picture, obtaining a brick scanning order information, decoding each coded brick of the encoded picture, constructing the picture by assembling the decoded bricks based on the brick partitioning, the tile partitioning, and the obtained brick scanning order information.

This embodiment may comprise other features, alone or in combination, such as: the determining of a file partitioning comprises reading syntax elements for determining number of tiles and widths of tiles; -the determining of a brick partitioning comprises determining a brick partitioning for each file; the determining of a brick partitioning comprises reading syntax elements describing a partitioning of a reference tile, said partitioning corresponding to a brick pattern; -if the syntax elements comprise only one brick pattern, the brick partitioning forms a grid; - the determining of a brick partitioning further comprises determining a brick pattern index for each brick pattern and determining an association of the brick pattern index with a tile index, then the partitioning of the tile associated to the tile index is described by the brick pattern associated to the brick pattern index; and/or - the brick scan order consists in scanning each brick of the picture horizontally across the tile boundaries.

According to a third aspect of the invention, there is provided a computer program product for a programmable apparatus, the computer program product comprises a sequence of instructions for implementing each of the steps of the methods here above when loaded into and executed by the programmable apparatus.

According to a fourth aspect of the invention, there is provided a non-transitory computer-readable storage medium storing instructions of a computer program for implementing each of the steps of the methods described above.

According to a fifth aspect of the invention, there is provided a device comprising a processing unit configured for carrying out some or all of the steps of the methods described above.

According to a sixth aspect of the invention, there is provided a signal carrying an encoded picture, the encoded picture comprising at least a syntax element comprising partitioning data of the picture into files and bricks and a brick scanning order information of said bricks, as resulting from the method described above.

According to a seventh aspect of the invention, there is provided a media storage device storing a signal carrying an encoded picture, the encoded picture comprising at least syntax elements comprising partitioning data of the picture into tiles and bricks and a brick scanning order information of said bricks, as resulting from the method described above.

The second, third, fourth, fifth, sixth and seventh aspects of the present invention have advantages similar to the first above-mentioned aspect.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system".

Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer-readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g., a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figures 1A, 1B and 1C illustrate some partitioning of a picture in encoding systems; Figure 2 illustrates the organization of the bit stream in the exemplary encoding system VVC; Figure 3 illustrates a regular or uniform partitioning of a frame into 25 regions; Figure 4 illustrates a 3x3 partitioning of a picture; Figure 5 illustrates an example of file and brick partitioning; Figure 6 illustrates an example of a partitioning for a brick scanning algorithm; Figure 7 illustrates an example of a partitioning into 6 bricks and 3 tiles; Figure 8 illustrates the main processing steps of an encoder; Figure 9 illustrates the main processing steps of a decoder; and, Figure 10 illustrates a schematic block diagram of a computing device.

DETAILED DESCRIPTION OF THE INVENTION

The compression of a video sequence relies on several partitioning techniques for each picture. Figures 1A to 1C illustrate some partitioning in encoding systems, as understood by the inventors. The pictures 101 and 102 are divided into coding tree units (CTUs) illustrated by the dotted lines. A CTU is the elementary unit of encoding and decoding. For example, the CTU can encode an area of 128 by 128 pixels.

A Coding Tree Unit (CTU) could also be named block, macro block, coding unit. It can encode simultaneously the different image components or it can be limited to only one image component.

As illustrated by Figure 1A, the picture can be partitioned according to a grid of tiles, illustrated by the thin solid lines. The tiles are picture parts, thus regions of pixels that may be defined independently of the CTU partitioning. The boundaries of files and the boundaries of the CTU may be different although, more generally, a tile may also correspond to a sequence of CTUs, as in the represented example, meaning that the boundaries of tiles and CTUs coincide.

Tiles definition provides that file boundaries break the spatial encoding dependencies. This means that encoding of a CTU in a tile is not based on pixel data from another tile in the picture.

Some encoding systems, like for example WC, provide the concept of slices. This mechanism allows the partitioning of the picture into one or several groups of files. Each slice is composed of one or several files. Two different kinds of slices are provided as illustrated by pictures 101 and 102. A first mode of slice partitioning is restricted to slices forming a rectangular area in the picture. Picture 101 illustrates the partitioning of a picture into six different rectangular slices. A second mode of slice partitioning is restricted to successive tiles in raster scan order. Picture 102 illustrates the partitioning of a picture into three different slices composed of successive tiles in raster scan order.

Tile 103 belongs to slice (0) in picture 101 or picture 102. Rectangular slice mode is a structure of choice for dealing with regions of interest in a video. A slice can be encoded in the bit stream as one or several NAL (Network Abstraction Layer) units. A NAL unit is a logical unit of data for the encapsulation of data in the encoded bit stream. In the example of VVC encoding system, a slice is encoded as a single NAL unit. When a slice is encoded in the bit stream as several NAL units, each NAL unit of the slice is a Slice Segment. A slice segment includes a slice segment header that contains the encoding parameters of the slice segment. The header of the first segment NAL unit of the slice contains all the encoding parameters of the slices. The slice segment header of the subsequent NAL units of the slice may contain fewer parameters than the first NAL unit.

In such a case, the first slice segment is an independent slice segment and the subsequent segments are dependent slice segments.

Sometimes a picture could be partitioned into several regions that may be independently encoded as layers (e.g., a VVC or HEVC layers). Each layer could be independently encoded. When combined, the pictures of the layers may form a new picture of greater size equal to the size of the combination of the layers. Consequently, a picture may be divided into layers, each layer defining a grid of tiles and being spatially divided into slices. Tiles and slices may be defined at the picture level or at the layer level.

In this text, a sub picture represents a picture portion that covers a rectangular region of a picture and/or represents a layer. Each sub picture may have different sizes and encoding parameters. The sub picture may also represent a spatial sub part of the picture as well as a layer sub part of the picture.

Therefore, the definition used in this text is larger than the definition of OMAF v2 ISO/IEC 23090-2, in which a sub-picture is a portion of a picture that represents a spatial subset of the original video content, which has been split into spatial subsets before video encoding at the content production side. A sub picture is for example one or more slices.

Figure 1B illustrates an example of partitioning of a picture into sub pictures. For instance, different tile grid and slice partitioning may be defined for each sub picture.

Tiles represent sub-portions of the picture. Slices are sub-portion groups. In Figure 1B, the picture 104 is subdivided in 24 sub pictures including the sub pictures 105 and 106. These two sub pictures further describe a tile grid and a partitioning into slices similar to pictures 101 and 102 of Figure 1A.

Figure 1C illustrates an example of partitioning using brick partitioning. Each tile may comprise a set of bricks. A brick is a contiguous set of CTUs forming one line in the tile. For example, the frame 107 of Figure 10 is divided into 25 files. Each tile contains exactly one brick except the ones in the rightmost column of tiles that contain two bricks per tile. For instance, the tile 108 contains two bricks 109 and 110. When brick partitioning is employed, the slice contains either bricks from one file or several bricks from other tiles. In other words, the VOL NAL units are a set of bricks instead of a set of tiles.

Figure 2 illustrates the organization of the bit stream in the exemplary encoding system VVC.

A bit stream 200 according to the VVC encoding system is composed of an ordered sequence of syntax elements and encoded data. The syntax elements and encoded data are placed into NAL units 201-207. There are different NAL unit types. The network abstraction layer provides the ability to encapsulate the bit stream into different protocols, like RTP/IP, standing for Real Time Protocol / Internet Protocol, ISO Base Media File Format, etc. The network abstraction layer also provides a framework for packet loss resilience.

NAL units are divided into VOL (Video Coding Layer) NAL units and non-VOL NAL units. The VOL NAL units contain the actual encoded video data. The non-VOL NAL units contain additional information. This additional information may be parameters needed for the decoding of the encoded video data or supplemental data that may enhance usability of the decoded video data. NAL units 207 correspond to a slice (or slice segment when present) and constitute the VOL NAL units of the bit stream. Different NAL units 201-206 correspond to different parameter sets and supplemental enhancement information (SEI). These NAL units are non-VOL NAL units. The VPS (Video Parameter Set) NAL unit 202 contains parameters defined for the whole video, and thus the whole bit stream. The DPS (Decoder Parameter Set) NAL unit 201 may define parameters more static than the parameters in the VPS. In other words, the parameters of DPS change less frequently than the parameters of the VPS. The SPS (Sequence Parameter Set) NAL unit 203 contains parameters defined for a video sequence. In particular, the SPS NAL unit may define the sub pictures of the video sequences. TABLE 1 (all tables are placed in the Appendix at the end of the specification) shows the syntax elements of the SPS.

In TABLE 1, the descriptor column gives the encoding of a syntax element, u(1) means that the syntax element is encoded using one bit, ue(v) means that the syntax element is encoded using unsigned integer 0-th order Exp-Golomb-coded syntax element with the left bit first that is variable length encoding.

The syntax element num_sub_pics_minus1 specifies the number of sub pictures in a picture of the video sequence. Next, sub_pic_id_len_minus1 represents the number of bits used to encode the sub_pic_id[i] syntax elements. There are as many sub_pic_id[i] as sub pictures in each picture of the video sequence. The sub_pic_id[i] syntax element is a sub picture identifier. The sub_pic_treated_as_pic_flag[i] syntax element indicates whether the sub picture boundaries should be treated as picture boundaries except for the loop filtering process. The sub_pic_x offset[i], sub_pic_y_offset[i] specifies the location of the first pixel of the sub picture with reference to the picture referential. The sub_pic_width_in_luma_samples[i] and sub_pic_height_in_luma_samples[i] syntax elements indicate respectively the width and the height of the sub picture.

When using sub picture layer partitioning, the decoding layout of the different layers may be described in a Parameter Set unit such as the VPS or the DPS NAL units or in a SEI NAL unit. The identifier of the sub picture layer may be for example a NAL unit layer identifier.

The PPS (Picture Parameter Set) NAL unit 204 contains parameters defined for a picture or a group of pictures. The APS (Adaptation Parameter Set) NAL unit 205 contains parameters for loop filters typically the Adaptive Loop Filter (ALF) and the reshaper model (or luma mapping with chroma scaling model) that are defined at the slice level. The bit stream may also contain SEI (Supplemental Enhancement Information) NAL unit 206.

The syntax of the SEI NAL unit consists of a set of SEI message elements (TABLE 2). One SEI message contains a payload type syntax element (payload_type_byte in the TABLE 2) that specifies the type of the SEI message.

Depending on this type, the SEI payload of the message contains a set of syntax elements. Parameters in the SEI payload provide additional information that may be used by a decoder or ignored when the payload type is unknown.

The periodicity of occurrence of these parameter sets in the bit stream is variable. A VPS that is defined for the whole bit stream needs to occur only once in the bit stream. By contrast, an APS that is defined for a slice may occur once for each slice in each picture. Actually, different slices may rely on the same APS and thus there is generally fewer APS than slices in each picture. When a picture is divided into sub pictures, a PPS may be defined for each sub picture or a group of sub pictures.

Each of the VCL NAL units 207 contains a tile or a portion of tile. Typically, the VCL NAL units may correspond to one slice or to a slice segment. Figure 2 refers to slices as an example but also applies to slice segments. A slice may correspond to the whole picture or sub picture, a single tile (or brick) or a plurality of tiles (or bricks). A slice is composed of a slice header 210 and a raw byte sequence payload, RBSP, 211 that contains the tiles or bricks.

The slice index is the index of the slice in the picture in raster scan order. For example, in Figure 1A, the number in a ring represents the slice index for each slice. Slice 103 has a slice index of 0.

The slice identifier is a value, meaning an integer or any bit sequence, which is associated with a slice. Typically, the PPS contains the association for each slice between the slice index and the slice identifier for one or several pictures. For example, in Figure 1, the slice 103 with slice index 0 can have a slice identifier of '345'.

The slice address is a syntax element present in the header of the slice NAL unit. The slice address may refer to the slice index, to the slice identifier or even to the tile or group index. In the latter case, it will be the index of the first brick in the slice. The semantic of the slice address is defined by several flags present in one of the Parameters Set NAL units. In the example of slice 103 in Figure 1A, the slice address may be the slice index 0, the slice identifier 345 or the brick index 0.

The slice index, identifier and address are used to define the partitioning of the picture into slices. The slice index is related with the location of the slice in the picture.

The decoder parses the slice address in the slice NAL unit header and uses it to locate the slice in the picture and determine the location of the first sample in the NAL unit. When the slice address refers to the slice identifier, the decoder uses the association indicated by the PPS to retrieve the slice index associated with the slice identifier and thus determine the location of the slice and of the first sample in the NAL unit.

The syntax of the PPS as given in the current version of VVC is illustrated in

TABLE 3

The descriptor column gives the encoding of a syntax element, u(1) means that the syntax element is encoded using one bit, ue(v) means that the syntax element is encoded using unsigned integer 0-th order Exp-Golomb-coded syntax element with the left bit first that is variable length encoding. The syntax elements num_tile_columns_minusl and num_tile_rows_minus1 respectively indicate the number of file columns and rows in the picture. When the file grid is not uniform (uniform_tile_spacing_flag equal 0) the syntax element tile_column_width_minus10 and tile_row_height_minus10 specify the widths and heights of each column and row of the tile grid.

The slice partitioning is expressed with the following syntax elements: The syntax element single_tile_in_pic_flag states whether the picture contains a single tile. In other words, there is only one tile.

single_brick_per_slice_flag states whether each slice contains a single brick.

In other words, all the bricks of the picture belong to a different slice when this flag is true.

The syntax element rect_slice_flag indicates that slices of the pictures form a rectangular shape as represented in the picture 201.

When present, the syntax element num_slices_in_pic_minus1 is equal to the number of rectangular slices in the picture minus one.

Syntax elements top_left_brick_idx[] and bottom_right_brick_idx[] are arrays that respectively specify the first brick (top left) and the last (bottom right) brick in a rectangular slice. Theses arrays are indexed by slice index.

The slice identifiers are specified when the signalled_slice_id_flag is equal to 1. In this case, the signalled_slice_id_length_minus1 syntax element indicates the number of bits used to encode each slice identifier value. The slice_id0 table is indexed by slice index and contains the identifier of the slice. When the signalled_slice_id_flag equal to 0 the slice_id is indexed by slice index and contains the slice index of the slice.

The slice header comprises the slice address according to the following syntax in the current VVC version (TABLE 4).

When the slice is not rectangular, the slice header indicates the number of bricks in the slice NAL unit with the help of num_bricks_in_slice_minus1 syntax element.

Each brick 220 contains a set of encoded data corresponding to one or more encoding unit data 240 In a variant, the video sequence includes sub pictures; the syntax of the slice header is illustrated in TABLE 5.

The slice header includes the slice_sub_pic_id syntax element which specifies the identifier (i.e., corresponding to one of the sub_pic_id[ i] defined in the SPS) of the sub pictures it belongs to. As a result, all the slices that share the same slice_sub_pic_id in the video sequence belong to the same sub picture.

Embodiment 1 The inventors provide method embodiments for modifying the partitioning and to provide alternative syntaxes that advantageously reduce the number of syntax elements required to describe the partitioning in comparison to examples above. In addition, the resulting bit stream size is reduced. The provided methods also provide different scanning orders so that the processing order of the different regions is independent of the partitioning pattern.

The person skilled in the art understands that the following disclosed embodiments can be combined depending on the objective to achieve.

In its most general understanding, the method for encoding a picture comprising a data array with a first dimension and a second dimension, comprises: partitioning the data array into a set of rectangular tiles in which all tiles have a side of length equal to the size of the first dimension of the data array, partitioning at least one of the rectangular tiles into a set of rectangular bricks in which all bricks of the set have a side of length equal to the size of the side of the tile to which the bricks belong in the second dimension of the data array, obtaining a brick scanning order information, and then encoding the picture by encoding each brick based on the obtained brick scanning order.

Typically, the first dimension is associated with the height of the picture and the second dimension is associated with the width of the picture, so that the tiles form one row of rectangular columns and each tile contains one column of rectangular bricks. The following examples will use this type of spatial organization.

However, the person skilled in the art will be able, without particular technical difficulties, to transpose the given examples so that columns are replaced by rows and rows by columns.

"Partition" is used in its usual definition, i.e., each element of the data array, respectively a tile, belongs to one and only one tile, respectively brick. In a particular case, the set of files may be limited to one file which is thus equal to the data array and/or the set of bricks limited to one brick which is thus equal to the tile.

Embodiment 2 The tile partitioning consists in replacing the file grid partitioning by a one row partitioning. In other words, each frame of the video sequence is divided into file columns. The file column spacing is either uniform, i.e., the column widths are equally divided across the picture width, i.e., the sizes of the tiles in the second dimension are equal.

The width of the columns is specified in the bit stream.

Each column is then divided into at least one region of contiguous CTUs. In a variant, the set of CTUs forms an integer number of rows of the tile column. Each of this set of CTUs forms a brick. The boundaries of bricks and tiles break the prediction mechanisms within a single picture. As result, one CTU from one brick cannot use data from a CTU of other bricks.

The bricks can be uniformly spaced across the tile height i.e., across the picture height, i.e., for at least one tile of the set of files, the sizes of the bricks contained in the tile are equal in the first dimension. Another option is to use a different spacing distribution by defining the heights of each bricks in the tile, except the last one that can be deduced from the tile height and the heights of previous bricks.

In embodiment 2, a flag indicates that brick distribution is uniform across the picture height and thus the same for all the tile columns, i.e., the brick partition is identical for all the tiles. This corresponds to the definition of a grid of bricks in the picture. In addition, the method allows the definition of different distributions of bricks for the tile columns. It includes the specification of different uniform distribution across the file columns (typically, a different number of bricks in each tile column).

The description of the tile and brick partitioning takes place for example in one Parameter Set typically the PPS. In a variant, the tile and brick partitioning are handled by another Parameter Set for sub pictures. For example, TABLE 6 shows the syntax elements of the PPS with the following semantics for the syntax elements: The specification of the tile columns is based on the uniform_tile_spacing_flag, and tile_cols_width_minus1 syntax elements when the tiles are uniformly distributed across the picture. Otherwise, the number of tile columns is specified by num_tile_columns_minus1 plus 1 and the width in CTB of each column is specified by tile_column_width_minusl[ i] plus 1 for the i-th column. The number of tiles (represented by NumTilesInPic variable in VVC specification) is thus equal to the number of tile columns in the picture. Thus, the variable NumTilesInPic is set equal to (num_tile_columns_minus1 + 1).

single_brick_in_picflag equal to 1 specifies that there is only one brick in each picture referring to the PPS. single_file_in_pic_flag equal to 0 specifies that there is more than one brick in each picture referring to the PPS.

uniform_tile_spacing_flag equal to 1 specifies that file column boundaries are distributed uniformly across the picture and signaled using the syntax elements tile_cols_width_minust uniform_tile_spacing_flag equal to 0 specifies that tile column boundaries may or may not be distributed uniformly across the picture and signaled using the syntax elements num_tile_columns_minusl and a list of syntax element tile_column_width_minus1[ i]. When not present, the value of uniform_tile_spacing_flag is inferred to be equal to 1.

uniform_brick_rows_flag (or uniform_brick_spacing_all_tiles_flag) equal to 1 specifies that horizontal brick boundaries are distributed uniformly across all the tiles of the picture and signaled using brick_rows_height_minust uniform_brick_rows_flag (or uniform_brick_spacing_all_tiles_flag) equal to 0 specifies that horizontal brick boundaries may or may not be distributed uniformly across all the tiles of the pictures and the presence of uniform_brick_spacing_flag[ i].

When uniform_brick_rows_flag (or uniform_brick_spacing_all_tiles_flag) is equal to 1, brick_rows_height_minusi plus 1 specifies the height of all the bricks of the picture excluding the last brick of each tile columns.

When uniform_brick_rows_flag (or uniform_brick_spacing_all_tiles_flag) is equal to 0, uniform_brick_spacing_flag[ i] indicates whether the bricks of the i-th tile are distributed uniformly across the i-th file. In such a case (the flag equals 1), the height of the bricks except the last one is specified by brick_height_minusl plus 1. Otherwise (the flag equals 0), the number of bricks in the i-th tile is specified by num_brick_rows_minusl[i] plus 1. The size of the j-th bricks in the i-th tile is equal to brick_row_height_minusl[ i][ j] plus 1.

The uniform_brick_spacing_flag[ i], num_brick_rows_minusii] and brick_row height_minusl[ i][ j] forms the brick splitting patterns parameters.

An advantage of this embodiment 2 is that the frame partitioning into tiles and bricks is unique for a given pattern of regions. For example, Figure 3 is an example of partitioning a frame into 25 regions. With the prior art, this partitioning may be represented as either a 5x5 tile grid with 1 brick per tile or a 3x5 tile grid with 2 bricks per tile except for the last tile row, or a 2x5 tile grid with 4 bricks per tile for the first tile row and one brick per file for the last one. By contrast, the partitioning of the proposed method is unique and consists in a 5 tile rows and 5 bricks per tile column.

TABLE 7 is a variant of the syntax elements of the PPS.

In this variant, the syntax elements are reordered to reduce the number of loops and thus reduce the computation cost of the parsing of the PPS.

Embodiment 3 In embodiment 3, the brick partitioning includes a flag to indicate that the brick partitioning is the same (identical) for all the tiles. In this embodiment, the bricks may or may not be uniformly distributed. When the partitioning is unique for all files, the brick partitioning is specified only for the first tile column. The partitioning for the remaining tile columns is not present and inferred equal to the brick partitioning of the first tile column. When the first column contains a set of bricks uniformly distributed across the tile (uniform_brick_spacing_flag[0] equal 1) and the brick partitioning is identical, the brick partitioning is uniform and identical for all the tiles of the picture, which is equivalent to the previous embodiment.

TABLE 8 gives an example of the syntax elements for embodiment 3.

In the table, the semantics of the new syntax elements is the following: identical_brick_splitting_patternflag equal to 1 indicates that the brick partitioning is the same within each tile column. The brick partitioning patterns is specified once for the first file column (i is equal 0 in the for loop across the files). The values of uniform_brick_spacing_flag[ i], brick_height_minus1[ i], num_brick_rows_minus1[ i] and brick_row height_minus1[ i][ j] are absent and inferred equal to the values of uniform_brick_spacing_flag[ 0], brick_height minus1[ 0], num_brick_rows_minus1[ 0] and brick_row_height_minusl[ 0][ j].

identical_brick_splitfing_pattern_flag equal to 0 indicates that the brick partitioning may or may not be the same within each tile column. The brick partitioning of the i-th tile is specified by of uniform_brick_spacing_flag[ i], brick_height_minusl[ i], num_brick_rows_minus1[ i] and brick_row_height_minus1[ i][ j] when present.

Embodiment 4 In another embodiment, the specification of brick partitioning indicates that the brick partitioning of the current tile is the same as the previous tile column in raster scan order. In such a case, the syntax elements that described the brick partitioning of the current tile are inferred equal to the previous tile and are skipped from the actual bit stream. An advantage is that the compression rate of the bit stream is higher for repetitive brick patterns across the tile columns.

In a variant, the tile partitioning includes several rows or files. In such a case, the method may indicate that the brick partitioning of the previous tile On raster scan order) is reused for the current tile. However, this method is less efficient since the tile and brick partitioning is not unique compared to the previous embodiments.

The description of the file and brick partitioning takes place for example in one Parameter Set typically the PPS. In a variant, the file and brick partitioning is handled by another Parameter Set for sub pictures. For example, the syntax of the PPS includes the syntax elements of TABLE 9.

With the following semantics for the new syntax elements uniform_brick_spacing_alltilesflag (or uniform_brick_gridflag) equal to 1 specifies that horizontal brick boundaries are distributed uniformly across all 35 the tiles of the picture and signaled using brick_rows_height_minus1.

uniform_brick_spacing_all_tiles_flag (or uniform_brick_grid_flag) equal to 0 specifies that horizontal brick boundaries may or may not be distributed uniformly across all the tiles of the pictures and the presence of reuse_brick_split_pattern[ i] and uniform_brick_spacing_flag[ i]. In a variant, this flag is not present when the number of tiles in the picture equal to 1. In such a case, the uniform distribution of bricks in the single tile is specified by uniform_brick_spacing_flag[ i] for i equal 0. reuse_brick_split_pattern[ i] equal to 1 specifies that the brick partitioning of the i-th tile is the same as the previous file (of index equal to i minus 1). In such a case, uniform_brick_spacing_flag[ i], brick_height_minus1[ i], num_brick_rows_minus1[ 10 i] and brick_row_height_minus1[ i][ j] are absent. The value of uniform_brick_spacing_flag[ i], brick_height_minus1[ i], num_brick_rows_minus1[ i] and brick_row height_minus1[ i][ j] are inferred equal to uniform_brick_spacing_flag[ 1], brick_height_minusl[ i-1], num_brick_rows_minus1[ i-1] and brick_row height_minus1[ i-1][ j] . reuse_brick_split_pattern[ i] equal to 0 specifies that the brick partitioning of the i-th tile may or may not be the same as the previous tile. The uniform_brick_spacing_flag[ i] and either brick_height_minus1[ i] or num_brick_rows_minus1[ i] and brick_row_height_minus1[ i][ j] are present.

When not present reuse_brick_split_pattern[ i] is inferred equal to 0.

When uniform_brick_spacing_flag[ i] is equal to 1, the bricks of the i-th tile are uniformly distributed across the i-th tile and have a height equal to brick_height_minus1[ i] plus 1 excluding the bottom brick. Otherwise (uniform_brick_spacing_flag[ i] is equal to 0) the bricks of the i-th tile may or may not uniformly distributed across the i-th tile. The number of bricks in the tile is equal to num_brick_rows_minus1[ i] plus 1. The height of the j-th brick of the i-th tile is equal to brick_row height_minus1[ i][ j] plus 1.

In a variant, the syntax of the PPS is modified to reduce the number of for loops across the tile columns. The new syntax is the following and the semantics remains the same (TABLE 10).

In a variant, when the number of bricks in each tile column equals 0, an encoder may indicate that the bricks are not distributed uniformly, by setting uniform_brick_rows_flag or/and uniform_brick_spacing_flag[ i] equal to O. Indeed, it can then specify that the number of bricks is equal 1 (num_brick_rows_minus1 equal 0) instead of specifying the height of the brick which is equal to the height of Picture. The description is more efficient since the length in bits of the picture height is greater than the single bit used to code the number of bricks in the tile.

Quantitative study of these embodiments An advantage of embodiment 3 is that the number of syntax elements is reduced and thus the size of the partitioning description is likely to decrease.

For example, it can be shown that a HD video sequence (1920x1080) represents a grid of 15x9 CTB of 128x128 pixels. A regular or uniform partitioning of the frame into 25 regions is represented in Figure 3.

In the prior art, we may use a regular tile grid partitioning of 5 columns and 5 rows and one brick per tile. Each tile has a size of 3x2 (except the last line) CTBs.

TABLE 11 details the value and the length in bits of each syntax element to describe the brick and tile partitioning.

In an exemplary embodiment, the 25 regions of the Figure 4 are represented by 5 tile columns. Each tile column uses the same brick pattern.

TABLE 12 details the value and the length in bits of each syntax element for this embodiment.

The lengths in bits of the two partitionings is identical in this example.

In yet another example, the frame of Figure 1C is divided into a regular tile partitioning of 5 columns and 5 rows with one brick per tile except the tiles in the last column which are split into 2 bricks.

The TABLE 13 details the value and the length in bits of each syntax element to describe the brick and tile partitioning with the prior art. The tile and brick partitioning represents a length of 43 bits.

TABLE 14 details the value and the length in bits of each syntax element to describe the brick and tile partitioning in an exemplary embodiment of Figure 1C in which the 25 regions are represented by 5 tile columns. Each tile column uses the same brick pattern excluding the last one.

The tile and brick partitioning represents a length of 15 bits which shows an improved compression rate.

Embodiment 5 In another embodiment, the possibility to reuse the brick splitting pattern of the previous tile column is extended to allow reference to any of the previous tile columns. The syntax elements that describe the brick splitting pattern include new syntax elements to indicate the index of the tile column which defines the brick splitting pattern to reuse. Since the second tile column brick pattern is necessarily predicted from the first file column, the index is encoded only from the third file column. In one variant, the index is specified relatively to the index of the current tile to reduce the size of the index.

For instance, the PPS defines the following syntax elements to describe the file and brick partitioning according to TABLE 15.

In TABLE 15, reuse_brick_split_column_idx_delta_minus1 [ i] plus 1 specifies the difference between the index of the i-th tile (i.e., the index equals i) and the index of the tile for which the brick splitting pattern is reused. The index of this tile is computed with the following equation: ReferenceTilelndex= i -(reuse_brick_split_column_idx delta_minus1 [i] + 1).

The reuse_brick_split_column_idx_delta_minus1 [ i] syntax element is encoded using Exp-Golomb with order 0. In a variant, the syntax element is encoded using fixed length coding. For example, the length in bits of the code is equal to Ceil( Log2( i)) bits which is equal to the minimal bits required to encode all possible values of the code for the i-th tile.

In another embodiment, the tile and brick partitioning specifies one or more brick splitting patterns for the sequence. Each tile column refers to an index of the brick splitting patterns to indicate its brick splitting partitioning.

For example, the tile and brick partitioning syntax elements are provided in 20 the PPS as in TABLE 16.

With the following semantics: num_brick_patterns_minusl plus 1 is equal to the number of brick splitting patterns described in the PPS. The value of num_brick_patterns_minus1 should be in the range of 0 to num_tile_columns_minusl.

uniform_brick_spacing_flag[ i] equal to 1 specifies that horizontal brick boundaries are distributed uniformly across the tile for the i-th brick pattern and signaled using the syntax element brick_height_minus1[ i]. uniform_brick_spacing_fiag[ i] equal to 0 specifies that horizontal brick boundaries may or may not be distributed uniformly across the file for the i-th brick pattern and signaled using the syntax element num_brick_rows_minus1[ i] and a list of syntax elements brick_row_height_minus1[ ][ j]. When not present, the value of uniform_brick_spacing_flag[ i] is inferred to be equal to 1.

brick_height_minusl[ i] plus 1 specifies the height of the brick rows excluding the bottom brick in the tile for the i-th brick pattern in units of CTBs when uniform_brick_spacing_flag[ i] is equal to 1. When present, the value of brick_height_minus1 shall be in the range of 0 to PicHeightl nCtbsY -2, inclusive. When not present, the value of brick_height_minus1[ i] is inferred to be equal to PicHeightInCtbsY -1, wherein PicHeightInCtbsY is the height in CTBs of the picture.

num_brick_rows_minusl[ i] plus 1 specifies the number of bricks partitioning the i-th brick pattern when uniform_brick_spacing_flag[ ] is equal to 0. When present, the value of num_brick_rows_minusff i] shall be in the range of 1 to PicHeightInCtbsY-1, inclusive. When not present, the value of num_brick_rows_minus1 [ i] is inferred to be equal to the ceiling of the picture height in CTBs divided by the height of the bricks (brick_height_minus1[i] + 1) which corresponds to the following equation: Ceil(PicHeig htl nCtbsY /( brick_height_minus1[i] + 1)).

brick_row_height_minusl[ i][ j] plus 1 specifies the height of the j-th brick in the tile for the i-th brick pattern in units of CTBs.

brick_layout[i] is the index of the brick pattern that specifies the brick partitioning of the i-th tile. When not present, brick_layout[i] is inferred equal to 0. The length of brick_layout[i] is equal to Ceil( Log2 (num_brick_patterns_minus1+1)) bits which is the minimal number of bits required to represent all possible indexes of brick patterns. In a variant, brick_layout[i] is encoded using Exp-Golomb with order 0.

Embodiment 6 As disclosed in the beginning of this specification, the normative processing order of the bricks depends on the type of the partitioning, in the prior art. For example, when the frame of the Figure 4 is partitioned in a 3x3 tile grid with one brick per file, the normative decoding order of the bricks is 400, 401, 402, 403, 404, 405, 406, 407 and finally 408. In another example the frame is partitioned in a 2x3 file grid, the first file row is constituted by the bricks 400 to 402 and the second tile row contains the bricks 403 to 408. In such a case, the normative decoding order of the bricks is 400, 401, 402, 403, 406, 404, 407, 405 and finally 408.

In embodiment 6, the processing order of the bricks is explicitly specified in the VVC bit stream. The processing order information specifies the order of scanning of the tile and bricks in the picture within each slice.

The scan order of the tiles in each slice of the frame is the processing order of the file columns within a picture or a slice. Typically, the tile columns are processed in raster scan order from the left-most tile column to the rightmost column. The first tile starts with the index 0 and thus the last tile of the frame has an index equal to the number of tiles minus one in the frame. In a variant, the tile scan order is from right to left.

When the partitioning consists in a single-column and multiple file rows, the tile scan order if for example from top to bottom.

The brick scan order is the processing order of the bricks within a slice. The order of processing of the bricks is scan order across the tile columns boundaries or within the tile columns.

When the brick scanning order is within tile columns, it consists in processing the brick from the first brick of the first file until the last brick of the tile in ascending order of first CTU in the brick. Then, it continues with the first brick of the next tile (in tile scan order) until the last brick of the next tile. The processing continues until the last tile of the slice When the brick scanning order is across the file boundaries, the scan principle consists in processing the bricks from left to right in the slice (or in the picture when there is a single slice per picture) by processing each tile in tile scan order. 15 The frame of Figure 4 is partitioned into three file columns; each tile column containing three bricks of same size. In a first example, the processing order information indicates the scan order is across the tile columns boundaries. The processing order of the bricks is thus 400, 401, 402, 403, 404, 405, 406, 407 and finally 408. In another example, the processing order information indicates the raster scan is within the tile columns. The processing order of the bricks is thus 400, 403, 406, 401, 404, 407, 402, 405 and finally 408.

In a variant, each brick is associated with one index (the brick index) in raster scan order across tile columns boundaries. As a result, the index of the brick 400 is 0 and is 3 for the brick 401. The processing order information is a list of brick indexes that indicates expected processing order of the bricks.

For example, the list is (400, 401, 402, 403, 406, 404, 407, 405, 408) to use the same processing order as described in the example above with a 2x3 file grid in the prior art.

An advantage of this method is to uncouple the tile and brick partitioning and the processing order.

In one example, the processing order information is specified in a Parameter Set NAL unit such as the PPS. The processing order information contains brick_picture_raster_scan_orderflag flag. brick_picture_raster_scan_order flag is defined prior to the tile and brick partitioning syntax element. When equal to 0, the index of the bricks is defined in raster scan order across the tile columns. When equal to 1, the index of the bricks i defined in raster scan order within each tile column, starting from the leftmost tile column.

In a variant, the processing order information contains the syntax elements 5 of TABLE 17.

The syntax elements semantics of TABLE 17 is the following: brick_scanning_order flag equal to 1 indicates the processing order of the bricks is different than the raster scan order and the presence of the brick_scanning_order[ i]. brick_scanning_order flag equal to 0 indicates the absence of the brick_scanning_order[ i].

brick_scanning_order[ i] specifies the decoding order index of the i-th brick. The length of brick_scanning_order[ i] is Ceil ( Log2(NumBricksInPic -1). In a variant, the value is encoded using Exp-Golomb code of 0 order.

In another embodiment, the brick_picture_raster_scan_order flag value is inferred from the value of the slice mode. When raster scan slice mode is used, brick_picture_raster_scan_order_flag is inferred equal to 1 and when rectangular slice mode is used, brick_picture_raster_scan_orderflag is inferred equal to 0. This means that the processing order of the bricks in raster scan slice mode is across tile columns while it is within tile columns in rectangular slice mode. An advantage of this embodiment is to ensure a consistent scanning order when slices are in raster scan mode which implies that frames are expected to be processed from left to right independently of the tile and brick partitioning. On the other hand, in a rectangle slice mode, there is a high probability that the encoder and the decoder process the images by regions corresponding to each slice. In such a case, it makes sense that processing order of bricks is not necessarily raster scan. Moreover, using a processing order within the tile columns enables some partitioning constraints to be avoided as explained in the following paragraphs.

In a variant, the brick_picture_raster_scan_orderflag is inferred equal to 1 when the frame contains a single slice per frame.

In a variant, the brick scanning order is predetermined by the codec format.

In such a case, the value of the processing order information is inferred from the specification constraints.

A common practice in video encoding and decoding is to encode the CTBs in a single pass. Some loop filters such as the deblocking filter is applied on decoded samples of the CTB. CTB are processed in raster scan order in each brick. As a result, when decoding one CTB, the neighboring CTBs on the right and bottom are not decoded. On the contrary, the top and left CTB if any (in the same brick) have been already decoded. For this reason, it is common to filter top and left boundaries of the current CTB just after the decoding of the samples.

As a result, it is a constraint of the bit stream that the pixels above (and respectively on the left) the top (and respectively on the left) boundaries of each CTB are decoded prior to current CTB (in decoding order). The tile, brick and slice partitioning and scanning should ensure that this constraint is valid.

As a result, in one embodiment some constraints apply depending on the processing order of the bricks.

In one embodiment, the brick processing order is scan across file columns. It is a constraint of the encoding to generate a brick partitioning and scanning that ensures that top and left boundaries of a brick are shared with bricks prior to the current brick in raster scan ordering. For example, Figure 5 is an example of tile and brick partitioning. The first tile column contains a single brick 500, the second tile column contains two bricks 501 and 503 and finally the last columns contains a single brick 502. In such a case, the brick processing order starting by 500, 501, 502 and then 503 infringes the constraint previously described. Indeed, the brick 502 has boundaries partially common with the brick 503 which is after brick 502 in this scan order.

On the other hand, the bricks are processed in raster scan order within the tile columns. With reference to the same example, the processing order of the bricks is 500, 501, 503 and finally 502. In such a case, the constraint is valid for the tile partitioning. More generally, the constraint is always fulfilled, since the top boundary of a brick is necessarily shared by a previous brick by design of the partitioning and the scanning. In addition, since the bricks are defined within each column and since each column is processed in raster scan order (from left to right), the left boundary of a brick is necessary a file boundary This tile boundary is by construction shared with a previous file and thus with one or several bricks prior to the current one. It can be concluded that the constraint is always valid when the bricks are processed in raster scan order within the tile column.

In one embodiment, the brick processing order is a scan across the tile columns. The scan principle consists in processing the bricks from left to right in the slice (or in the picture when there is a single slice per picture). The brick scanning must ensure that the constraints on brick is always valid.

Two alternative bricks scanning algorithms may be used. The first algorithm aims at processing as many as possible bricks in current file before processing the following tile. The number of bricks processed in current tile is equal to the maximum number of consecutive bricks in current tile such that the sum of their heights is below the height of the processed bricks in previous tile. This ensures the brick constraint. The maximum number of bricks is the number of bricks that verify the brick constraint. For instance, it is all the bricks of the tile until the last brick in the tile that has a left boundary fully shared with one of the previously processed bricks in previous tile. The subsequent bricks in the file have thus a left boundary not fully shared with previously processed bricks in previous tile.

The second algorithm is similar to the previous one. The main difference is that it aims at processing the lowest number of bricks in current tile before processing the following file instead of processing the maximum number of bricks. This algorithm prioritizes the processing of a full line of CTU, while the first one gives the priority to the processing of the maximum number of bricks in each tile before continuing with the next tile.

For example, in the Figure 6, the processing order of the bricks is 600, 602, 603, 604, 606, 607, 601, 605 and finally 608 with first algorithm; while it is 600, 602, 606, 603, 607, 604, 601, 605, 608 with the second algorithm.

The brick constraint (and therefore the brick scan order) needs to be controlled in particular when the brick boundaries of a previous (on the left) tile column are missing in current tile column. For this reason, in another embodiment it is a requirement that the boundaries in one tile column are present in the subsequent tile column when the processing order of the bricks is a scan across the file columns boundaries. The subsequent file column may define new brick boundaries in addition. As a result, the syntax elements that describe the brick partitioning takes into account this requirement. In practice, when defining the brick partitioning of each tile column, it is considered that the brick boundaries of previous tile columns are still present. The new brick boundaries add to the ones defined for the previous tile columns.

An advantage of this embodiment for scan order of the bricks across the tile is that it is always possible to process the entire picture width on a height equal to the height of any brick of the first tile column.

For example, the PPS comprises the syntax elements as in TABLE 18.

With the following semantics: additional_brickflag[ i] equal to 1 indicates the presence of additional brick partitioning of the i-th tile columns that complements the brick partitioning specified 5 for the (i-1)-th tile column when >0 and signals the presence of uniform_brick_spacing_flag[ i] and optionally of either brick_height_minus1[ i] or num_brick_rows_minus1[ i] and brick_row_height_minus1[ i][ j]. additional_brickflag[ i] equal to 0 indicates the absence of additional brick partitioning of the i-th tile columns. The value of uniform_brick_spacing_flag[ i] and optionally of 10 either brick_height_minus1[ i] or num_brick_rows_minus1[ i] and brick_row height_minus1[ i][ j] are inferred equal to uniform_brick_spacing_flag[ i -1] and optionally of either brick_height_minusl[ i -1] or num_brick_rows_minus1[ i -1] and brick_row_height minus1[ i -1][j]. When absent, addifional_brickflag[ i] is inferred equal to 1.

In a variant, addifional_brick_flag[ i] value is inferred equal to brick_picture_raster_scan_order_flag. As a result, when the brick scan is a scan across the tile boundaries, the brick constraint is valid. This variant improves the compressions of the bitstream since additional_brick_flag[ i] is not encoded.

In a variant, the brick partitioning is constrained for raster scan slice mode so that it forms a grid of bricks. In such a case, the brick scan across the file columns is simplified: the bricks are processed in raster scan, brick row after brick row. For example, when brick partitioning is described as a set of brick patterns, this constraint is equivalent to add the requirement that the number of brick patterns is equal to 1 (num_brick_patterns_minusl equals 0) for rectangular slice mode (rect_slice_flag equal 0).

Embodiment 7 The slice scan order is the processing order of the slices in the picture. On the decoder side, it may coincide with the order of the slice in the bitstream. In other words, if the slice order in the bitstream is different than the slice scan order, the bitstream may not be conformant.

The slice partitioning in raster scan slice mode consists in adding consecutive bricks in brick scan order within the same slice. When the brick processing order is a scan across tile columns, the constraint on brick partitioning and scanning described above applies. In particular, the brick scan order must validate the constraints on the bricks boundaries described previously. The slice scan order is by ascending order of the first brick in each slice accordingly to the brick scan order.

When the brick processing order is raster scan within tile columns, the slice contains a set of consecutive bricks. No brick partitioning constraint is necessary. The slice scanning order consists in adding the bricks of the tile starting by the top brick up to the bottom brick within the tile column. The scanning of the tile columns is made in tile scan order, typically from the left to right in the picture. In other words, it consists in processing the bricks vertically column by column.

The rectangular slice mode consists in forming a slice as a set of adjacent bricks forming a rectangular shape. In comparison with the prior art, it is possible to add two (or more) bricks from two different tile columns even if the two (or more) bricks are a subset of the bricks forming the files. In other words, the slice contains two subparts of the two tile columns instead of the entire tiles. The number of possible partitions in slices is thus increased which make it possible to define more complex ROI patterns.

In rectangular slice mode, the slices are defined by the indexes of the top left and the bottom right brick of the slice. For example, Figure 6 is a frame split into 6 bricks and 3 tile columns. In rectangular slice mode, a slice may contain the bricks 600, 601 and 603. In such a case, the top left brick index of the slice is the index of the brick 600 (which is 0); the bottom right brick index of the slice is the index of the brick 603, which is 2 (resp. 3) when the processing order of the brick is within (resp. across) the tile columns. It is not possible to define a slice composed of the bricks 600 and 601 since it does not form a rectangular shape.

When rectangular slice mode is used, the following constraint applies to ensure correct processing of the slices in a single pass. The constraint is that top and left boundaries of a slice must be shared with previously decoded slice.

In one example, the frame of the Figure 7 contains 4 slices. The first slice contains the brick 700. The second slice contains the brick 701, the third slice contains the brick 702 and the last slice contains the bricks 703 and 704.

If the scan order of the slices is by ascending order of the first brick in each slice accordingly to the brick scan order. When the brick scan is raster scan within the tile columns, the slice #4 (i.e., the one that contains bricks 703 and 704) is provided in the bit stream prior to the slice #3 (which contains the brick 702). In such a case, the constraint is unfulfilled since the top boundary of the slice #4 is shared with slice #3 which is provided after the slice #4.

On the other hand, if the brick scan is a scan across the tile columns, it is likely that the slice #3 is provided prior to slice #4. In this case, the constraint is valid and the processing of the slice can be done in a single pass.

For this reason, in one embodiment the scan order of the slices is provided in the PPS. For instance, the PPS includes a syntax element which is equal to 0 when the scan order of the slices is by ascending order of the first brick in each slice with a brick scan within the tile columns. The flag is equal to 1 when scan order of the slices is by ascending order of the first brick in each slice with a brick scan across the tile columns.

In a variant, the processing order of the slices is described by a list of slice indexes provided in the PPS.

In yet another variant, the processing order of the slices is the order of description of the slices in the PPS.

In yet another variant, the processing order of the slices is the scan order of the first brick following the scan order of the bricks in the picture. For example, the slice mode is raster scan and the brick scan is across tile columns. In such a case, slice scan order is the scan order of the first brick of each slice with a scan of the bricks across tile columns. In rectangular slice mode, the brick scan is within the tile columns. In this case, slice scan order is the scan order of the first brick of each slice with a scan of the bricks within the tile columns.

It is a requirement for the encoder to ensure that the slice partitioning constraint is valid for the processing order of slices described in the PPS.

In a variant, the tile and brick partitioning differs depending on the scan order of the slices. In rectangular (resp. raster scan) slice mode, the tiles are defined as columns (resp. as rows) and bricks represent a horizontal (resp. vertical) partitioning of the file. This variant simplifies the scan of the bricks in each file. Indeed, in raster scan mode the scan of the bricks is horizontal within the file boundaries, and in rectangular mode, the scan of the bricks is vertical within the file boundaries.

Embodiment 8 The Figure 8 illustrates the main processing steps of an encoder according to the preceding embodiments.

In a step 800, a tile partitioning of the pictures is determined. For instance, the encoder defines the number of columns so that each region of interest of the video is covered by at least one tile column. In another example, the encoder is encoding an omnidirectional video where each file column corresponds to a predetermined field of view in the video. The tile partitioning of the picture in tile columns is typically represented in a parameter set NAL unit, for example a PPS according to the syntax presented in reference to Figure 2.

In the step 801, a brick partitioning of each tile column is determined. For instance, the encoder defines a set of bricks so that each brick covers one region of interest in the tile columns. In an alternative, the number and the height of the bricks are predetermined for each tile column.

In a step 802, one or more slices are defined, each slice comprising one or more bricks. In a particular embodiment, raster scan slice mode is used. Each slice is defined to encapsulate a predetermined number of consecutive bricks in the picture. The brick processing order is defined for instance as a scan across the file columns. In such a case, the encoder checks in step 803 whether the constraint on the brick boundaries is valid. If not, the encoder adapts the brick partitioning and scanning so that the constraint is valid for all bricks of the frame.

In a variant, the encoder uses rectangular slice mode. In a step 802, the encoder defines one or more slices covering rectangular shapes. For instance, each region of interest may be covered by one (or more) slices and the remaining part is covered by one or more slices. A slice processing order is predetermined and the encoder checks in step 804 whether the slice partitioning constraint is valid. In particular, the slice NAL unit may be reordered to conform with the decoding order of the slice described in the PPS.

Finally, the tile, brick and slice partitioning is described in a non-VCL NAL unit such as the PPS. The parameter sets NAL unit is encoded in step 804.

In a step 805, the samples of each slice are encoded according to the parameters defined in the different parameter sets.

A complete bit stream is generated comprising both the non-VCL NAL units corresponding to the different parameter sets and the VOL NAL units corresponding to the encoded data of the different slices.

Embodiment 9 In its most general embodiment, a method for decoding an encoded picture comprising at least encoded tiles and encoded bricks, said method comprising: determining a tile partitioning of the encoded picture, determining a brick partitioning of the encoded picture, decoding each coded brick of the encoded picture, constructing the picture by assembling the decoded bricks according to the brick and tile partitioning.

Figure 9 illustrates, with more detail, the main processing steps of the decoder.

The decoder parses the bit stream to determine (in a step 900) the Parameter Set NAL units that include a set of parameters which initializes the decoder. In particular, they include syntax elements which describe the tile, brick and slice partitioning information.

In a step 901 (resp. 902), the decoder determines the tile (resp. brick) partitioning of a picture or each sub picture of the picture when present. This information is obtained from a parameter set NAL unit, from the PPS NAL unit, for example. Typically, it can be one of the PPS of one of the previous embodiments. The syntax elements of the PPS are parsed and decoded to determine the number of tile columns and their widths. For each tile column the brick partitioning is determined. In particular, when the brick partitioning is described as set of bricks patterns, if the number of patterns is equal to one, the brick partitioning forms a grid of bricks in the frame. Otherwise, for each tile of the frame, the decoder determines the index (brick_layout) of the brick pattern associated with the tile index. Then it partitions the tile columns as described by the corresponding brick split pattern.

During this step, the decoder also determines the brick scan order of the brick accordingly to the processing order determined from the PPS. The processing order information can be inferred or explicitly defined.

For instance, the decoder computes an array (e.g., BrickScan[i] for i in the range of 0 to the number of bricks in the picture) that associates an index of the brick described in the PPS with a scan order.

When the brick scan order is within tile columns, the brick index is the same as the order of description of the bricks in the PPS. Indeed, the bricks are described in a scan order corresponding the brick scan within file columns. The algorithm to generate the BrickScan [ i] array is for example as in the pseudo-code of the TABLE 19, wherein NumBricksInPic is the total number of bricks in the picture: When the brick scan order is across the tile columns, the pseudo-algorithm to generate the BrickScan[ i] is thus the following.

In one embodiment, the number of brick patterns is equal to one. The frame is divided into a grid of bricks. The brick scan index consists thus in scanning each brick of the frame horizontally across the tile boundaries. The algorithm to generate the BrickScan[ i] array is for example as in the pseudo-code of TABLE 20, wherein NumBricksTile is the number of bricks in each tile (it is the same in each tile) and NumTilesInPic is the number of tiles in the picture.

When the number of brick patterns is greater than one, the scan algorithm of the bricks across the tile boundaries is more complex.

In one embodiment, the brick scan consists in scanning as many as possible bricks in current tile before processing the following tile. The number of bricks processed in current file is equal to the maximum number of consecutive bricks in current file such that the sum of their heights is below the height of the processed bricks in previous tile.

This ensures the brick constraint. This algorithm corresponds in one example to the pseudo-code of TABLE 21 that fills the BrickScan[ i] array,wherein NumTilesInPic is the number of tiles in the picture, FirstBrickldx[i] is the brick index of the first brick of the i-th file, and BrickRowBd [ i] is an array that specifies the bottom boundary location in units of CTU of the i-th brick in the frame. The function GetBrickNextTile fills the BrickScan [ i 15] array with the maximum number of bricks from the tile with an index equal to fileldx parameter, each brick verifying the brick constraint. For example, the algorithm of this function is represented by the pseudo-code of TABLE 22.

In another embodiment, the brick scan consists in scanning the lowest number of possible bricks in current tile before processing the following tile. In such a case, the algorithm to fill the BrickScan[ i] is for example the pseudo-code as in TABLE 23.

The function GetBrickNextTile2 fills the BrickScan [ i] array with the lowest number of bricks from the tile with an index equal to tileldx parameter, each brick verifying the brick constraint. Then, it repeats the same process for the next tile. The algorithm of this function is as in TABLE 24.

The scan order of the CTBs in each brick is represented by the CtbAddrRsToBs[ ctbAddrRs] array, for ctbAddrRs ranging from 0 to PicSizel nCtbsY -1, inclusive. It specifies the conversion from a CTB address in CTB raster scan of a picture to a CTB address in brick scan. The pseudo-code of TABLE 25 is an example of algorithm to fill the CtbAddrRsToBs array, wherein BrickColBd[i], BrickRowBd[i], BrickWidth[i] and BrickHeight[i] are respectively, the location of the right boundary of the i-th brick in CTB units, the location of the bottom boundary of the i-th brick in CTB units, the width in CTB units of the i-thbrick, and the height in CTB units of the i-th brick; PicSizeInCtbY is the number of CTB units in the picture;PicWidthInCtbsYs the width in CTB units of the picture.

In a step 903, the decoder determines the number of slices associated with an item of identification information of each sub picture when present.

In a step 904, the decoder decodes the VCL NAL units corresponding to the slices according to the parameters determined in the previous steps. The decoding order of the slice is the order of the slice in the bitstream.

In one embodiment, when the decoding order of the slice is explicitly specified in the PPS, the decoder may reorder the slice NAL units to conform with the decoding order provided the PPS.

Figure 10 is a schematic block diagram of a computing device 1000 for implementation of one or more embodiments of the invention. The computing device 1000 may be a device such as a microcomputer, a workstation or a light portable device.

The computing device 1000 comprises a communication bus 1002 connected to: -a central processing unit (CPU) 1004, such as a microprocessor; -a random access memory (RAM) 1008 for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method for encoding pictures, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port, for example; -a read-only memory (ROM) 1006 for storing computer programs for implementing embodiments of the invention; -a network interface 1012 that is, in turn, typically connected to a communication network 1014 over which digital data to be processed are transmitted or received. The network interface 1012 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 1004; -a user interface (UI) 1016 for receiving inputs from a user or to display information to a user; -a hard disk (HD) 1010; -an I/O module 1018 for receiving/sending data from/to external devices such as a video source or display.

The executable code may be stored either in read only memory 1006, on the hard disk 1010 or on a removable digital medium for example such as a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 1012, in order to be stored in one of the storage means of the communication device 1000, such as the hard disk 1010, before being executed.

The central processing unit 1004 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 1004 is capable of executing instructions from main RAM memory 1008 relating to a software application after those instructions have been loaded from the program ROM 1006 or the hard disk (HD) 1010, for example. Such a software application, when executed by the CPU 1004, causes the steps of the flowcharts shown in the previous figures to be performed. In this embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

Although the present invention has been described herein above with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a person skilled in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged or combined, where appropriate.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "and" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

APPENDIX

seq_parameter_set_rbsp( ) i Descriptor sps max stab layers minusl u(3) sps_reserved_zerosibits u(5) profile_ er_level( sps max sub layers minus I) sps seq parameter set id ue(v) b -I num slit, pies minus' ne(v) sub pic id len minusl u 1 if( num_ sub_pics_minusl > 0) for( i = 0; i <= aum_sub_pies_minus 1) I sub_ pk id [ 1] if( num sub pics minusl > 0) f sub_pickreated_as_picihigl i I u(1) sub_pie_x_olitset[ i] ue(v) sub pie v offset[ 1] ne(v) sub pie width in Ionia samples i] nth° sub pie height in lunut samples[ 1] ue(v) i [---i

TABLE 1

sei message( ) { Descriptor payloadType = 0 do I payload type byte u(8) payloadType += payload type byte I while (payload type byte = = OxFF) payloadSize = 0 do [ payload_size_byte u(8) payloadSize += payload size byte 1 while (payload_size_byte = = Ox1,1, ) sei payload( payloadType, payloadSize)

TABLE 2

pie parameter set rbsp( ) i Descriptor pps pic parameter set id ue(v) pps_seq_parameter_set_id ue(v) output flag present flag u(1) single_tile_in_pic_flag u(1) if( !single tile in pie flag) f uniform tile spacing flag 11(1) if( uniform tile spacinn flag) { tile_cols_width_minusl ue(v) I else i num tile columns minusl ue(v) brick splitting_present flag 11(1) for( i = 0; i < NunaTilesInPic; i++ ) { if(! uniform tile spacinn Ilan) { tile column width minusll 1] ue(v) if (brick splitting present flag && i > 0) { reuse brick split pattern[ ] u(1) inreuse_brick_split_pattern1 i I) reuse_brick_split_column_idx [ii ue(v) if(brick splitting present flag && !reuse brick split patternl i _I) { brick split flag [ i] if(Jhrick_split_flagl i I) I uniform brick spacing_flag[ 1] u(1) if( uniform_briek_spacing_flagl i I) brick_height_minusl Iii ue(v) else { num_brick_rows_minusl I i I ue(v) for( j = 0:j < num brick rows minus 1 [ i]; j++ ) brick row height minusl[ i j[ j] ue(v)

I l

I

single_brick_per_slice_flag u(1) if( !single_brick_per_sliee_flag) rect_slice_flag u(1) if( rect_sliee_flag Sr& Isingle_briek_per_slice_flag) { num slices in pic minus] ue(v) for( i = 0; i <= num slices in pie minus!: i++ ) { if( i > 0) top left brick idx[ i] u(v) bottom right brick idx delta [ ii u(v) loop_filter_across_bricks_enabled_flag u(1) if( loop filter across bricks enabled flag) loop_filter_ateross_sliees_enabled_flag u(1) ) if( reet_slice_flag) { signalled slice id flag u(1) if( signalled slice id flag) { signalled_slice_id Jength_minusl ue(v) for( i = 0; i <= num_sliees_i n_pie_rni nus 1; i++ ) slice id[ i] u(v) I 1// Additional syntax elements not represented rbsp trailing bits( )

TABLE 3

slice header( ) { Descriptor slice pic parameter set id ue(v) if( rect slice flag I I NumBricksInPic > 1) slice address u(v) if( !rect slice flag && !single brick per slice flag) num_bricks_in_slice _tninusl ue(v) [* * *]

TABLE 4

slice header( ) f Descriptor slice pic parameter set id ue(v) slice_sub_pic_id u(v) if( rect slice flag I I NumBricksInSubPic > 1) slice address u(v) [..]

TABLE 5

pic parameter set rbsp( ) I Descriptor pps pic parameter set id ue(v) ll ll if( lsingle_brick_in_pic_flag) { uniform_tile_spacing_flag u(1) if( uniform tile spacing tlag) { tile_cols_width_minusl ue(v) 1 else 1 num_tile_columns_minusl ue(v) for( i = 0 < num tile columns minus1; i++ ) tile column width minusll i] ue(v)

I

uniform brick rows flag u(1) if(uniform briCk FOWS flag) f brick rows height minusl ue(v) I else { for( i = 0; i < NunifilesIM'ic; i++ ) { uniform brick spacing flag[ii u(1) if( uniform brick spacii lag[ i] ) brick height minusl[ 1] ue(v) else { num brick rows minusll i i ue(v) for( j = 0;j < num brick rows minusl [ i]; j++ ) brick row height minusl[ i][ j] ue(v) )

I i***1

TABLE 6

pie parameter set rbsp( ) { Descriptor pps pic parameter set id ue(v) 1...1 if( !single_briek_in_pic_flag) { uniform_tile_spacing_flag u(1) if( uniform tile spacin2 tlag) tile_cols_width_minusl ue(v) else num_tile_columns_minusl ue(v) uniform brick rows flag u(1) if(uniform brick rows flag) brick rows height minusl ue(v) for( i = 0; i < NuniTilesInPie; i++ ) { if(!uniforrn tile spacing flag) tile_column_width_minusl I i I ue(v) if( uniformbrick rows tlag) { uniform_brick_spacing_flagl i I u(1) if( uniform brick spacing flag{ i] ) brick height minusl [ i] ue(v) else { num brick rows minusl[ i] ue(v) for( j = 0; j < num buck rows minusl { i 1; j++ ) brick row height minusl [ i][ j] ue(v) [---]

TABLE 7

pic parameter set rbsp( ) i Descriptor pps pic parameter set id ue(v) pps_seq_parameter_set_id ue(v) output flag present flag u(1) single_tile_in_pic_flag u(1) if( !single brick in pie flag) { uniform tile spacing flag 11(1) if( uniform tile spacing flag) { tile_cols_width_minusl ue(v) I else i num tile columns minusl ue(v) identical brick spitting pattern Hag 11(1) for( i = 0; i < NumTilesInPie: i++ ) { if(! uniform tile spacing flag) { tile column width minusl[ i] ue(v) if(!identical brick spl ng pattern flag II i == 0) { uniform brick spacing flag[ii u(1) if( uniform_hrick_spacing_flagl i I) brick height minusl[ i] ue(v) else { num brick rows minusl[ i] ue(v) for( j = 0; j < num_brick_rows_minusl I i l; j++ ) brick row height minusl[ i][ j] ue(v) [...] rbsp trailing bits( )

TABLE 8

pic parameter set rbsp( ) 1 Descriptor pps pic parameter set id ue(v) 1...1 if( !single_brick_in_pic_flag) { uniform_tile_spacing_flag u(1) if( uniform tile spacin2 tlag) { tile_cols_width_minusl ue(v) 1 else I num_tile_columns_minusl ue(v) for( i = 0 < num tile columns minus1; i++ 1 tile column width minusl[ i] ue(v) uniform brick spacing_all tiles flag u(1) if( uniform brick spacing all tiles flag) I brick rows height minusl ue(v) I else { for( i = 0; i < NunifilesIrWic; i++ ) { if ( i > 0) reuse brick split pattern[ ii u(1) if( !reuse brick split pattern[ i]) { uniform brick spachig flag[ii u(1) if( uniform brick spackle flag{ i i) brick height minusl[ i] ue(v) else { num brick rows minusl[ i] ue(v) for( j = 0; j < num brick rows minus{ { i 1; j++ ) brick row height minusl[ i][ j] ue(v) ] I-1

TABLE 9

pie parameter set rbsp( ) { Descriptor pps pic parameter set id ue(v) 1...1 if( !singfe_briek_in_pic_flag) { uniform_tile_spacing_flag u(1) if( uniform tile spacin2 tlag) tile_cols_width_minusl ue(v) else num_tile_columns_minusl ue(v) uniform brick rows flag u(1) if(uniform brick rows flag) brick rows height minusl ue(v) for( i = 0; i < NumTilesInPic; i++ ) { if(!uniforrn tile spacing flag) tile_column_width_minusl I i I ue(v) if( uniformbrick rows tlitg) { if ( i >0) reuse_brick_split_patternr Ii u(1) if( !reuse brick split pattern[ i]) { uniform brick spacing_flag[ 1] u(1) if( uniform brick spacing flag[ i] ) brick height minus1[ii ue(v) else { num brick rows minusl [ i] ue(v) for( j = 0:j < num brick rows minus 1 [ i] ; j++ ) brick row height minusl [ii [I] ue(v)

I ] [...]

TABLE 10

Value Length in bits uniform tile spacing flag 1 1 if( uniform tile spacing flag) I tile cols width minusl 2 3 tile_rows_height_minusl 1 3 ) else f num tile columns minusl num tile rows minusl for( i = 0; i < num tile columns minusl ++ ) tile colunm width minusil i] for( i = 0; i < nunutile_rows_mi nus I; i++ ) tile row height minusl[ i] brick splitting present flag 0 1

TABLE 11

Value Length in bits uniform_tile_spacing_flag 1 1 if( uniform_rile_spacing_flag) I tile_cols_width_minusl 2 3 1 else { num_tile_columns_minusl for( i = 0; i < num tile columns minus I; i++ ) tile_column_width_minusl I i I uniform brick spacing flag 1 1 if( uniform brick spacine tlae) l brick rows height minusl 1 3 [ ]

TABLE 12

Value Length in bits uniform tile spacing_flag 1 1 if( unifonn tile spacing flau) { tile cols width minusl 2 _ tile rows height minusl 1 3 } else { num tile eolunms minusl num tile rows minusl for( i = 0; i < num tile columns minusl; i++ ) tile_eolumn_width_minusl I i I for( i = 0:1< num tile rows minus' ++ ) tile row height minusl [ i] brick splitting present flag 1 1 for( i = 0: brick splitting present flag && I < NumTilesInPic; i++ ) { 25 iterations brick split flag[ ii 0 or 1 1* 25 = 25 if( brick_split_flagl l I) { 5 flags equal I uniform brick spacing flag[ i] 1 1*5 = 5 if( uniform_brick_spaeing_flagl i I) brick height minusl [ i] 0 1*5 = 5 else { num brick rows minusl[ i] for( j = 0: j < num_brick_mws_minusl I i I: j++ ) brick row height minusl [ i][ j]

I l

TABLE 13

Value Length in bits uniform tile spacing flag 1 1 if( uniform tile spacing flag) { tile cols width minusl 2 3 1 else { num_tile_columns_minusl for( i = 0; i < nunutile_eolumns_minusl; i++ ) tile column width minusil i] uniform_brick_spacing_flag 0 1 if( uniform_briek_spacing_flag) { brick_rows_height_minusl 1 else { for( i = 0; i < NtunTilesInPic; i++ ) { 5 iterations if ( i> 0) reuse_brick_split_pattern[ ii 1 for tiles 1-3 0 for tile 4 4 if( !reuse_brick_split_pattern[ ii) { uniform brick spacing flag[ i] 1 for tiles 0 and 4 2 if( uniform brick spacing tlag[ i] ) brick_height_minusl I i I 1 for tile 0 0 for tile 4 4 else f num brick rows minusfl i] for( j = 0:j < num brick rows minusl [ i]; j++ ) brick row height minusl [ i][ j]

TABLE 14

pic parameter set rbsp( ) { Descriptor pps pic parameter set id ue(v) 1...1 if( !single_brick_in_pic_flag) { uniform_tile_spacing_flag u(1) if( uniform tile spacin2 tlag) tile_cols_width_minusl ue(v) else num_tile_columns_minusl ue(v) uniform brick rows flag u(1) if(uniform brick rows flag) brick rows height minusl ue(v) for( i = 0; i < NumTilesInPic; i++ ) { if(!uniform tile spacing flag) tile_column_width_minusl I i I ue(v) if( uniformbrick rows tlag) { if ( i >0) reuse brick split pattern[ ii u(1) if(reuse brick split pattern[ ] &SE i> 1) reuse_brick_split_column_idx_delta_minusl [ i] ue(v) else { uniform brick spacing_flag] ii u(1) if uniform brick spacing tlag[ i] ) brick height minusil] ue(v) else { num brick rows minusl [ii ue(v) for( j = 0;j < num brick rows minusI[ i] ; j++ ) brick_row_height_minusi I i III I ue(v) [...]

TABLE 15

pic parameter set rbsp( ) 1 Descriptor pps pic parameter set id ue(v) 1...1 if( !single_brick_in_pic_flag) { uniform_tile_spacing_flag u(1) if( uniform tile spacimz tlag) tile_cols_width_minusl ue(v) else num_tile_columns_minusl ue(v) num brick patterns minusl ue(v) for( i = 0; i < num brick patterns minus1+1 ++ ) f uniform brick spacing flag[ 1] u(1) if( uniform brick spacing_flag[ i 1) brick height minusl[ i] ue(v) else { num brick rows minusl[ i] ue(v) for( j = 0; j < num_brick_rows_minusl I i I; j++ ) brick row height minusl [ i][ j] ue(v) for( i = 0; i < NumTilesInPic; i++ ) 1 if(!uniform tile spacing flag) tile column width minusl[ i] ue(v) if(num brick patterns minusl > 0) brick layout[i] u(v) I-1 [

TABLE 16

pic parameter set rbsp( ) 1 Descriptor pps pic parameter set id ue(v) 1...1 if( !single_brick_in_pic_flag) { 1.-1 brick scanning order flag u(1) if(brick scanning order flag) { for( i = 0; i < NumBlicksfriPic; i++ ) { brick_scanning_orderl ii u(v) ) f...1

I

TABLE 17

pie parameter set rbsp( ) { Descriptor pps pic parameter set id ue(v) 1...1 if( !sinriletile_in_pie_flarz) { uniform_tile_spacing_flag u(1) if( uniform tile spacin2 tlag) tile_cols_width_minusl ue(v) else num_tile_columns_minusl ue(v) uniform brick rows flag u(1) if(uniform brick rows flag) brick rows height minusl ue(v) for( i = 0; i < NuniTilesInPic; i++ ) { if(!uniforrn tile spacing flag) tile_column_width_minusl I i I ue(v) if( uniformbrick rows tlitg) { if ( i >0) additional_brick_splitting_flagr Ii u(1) if( addition brick spl ng Luz [ i]) { uniform brick spacing_flag[ 1] u(1) if( uniform brick spacing flag{ i] ) brick height minus1[ii ue(v) else { num brick rows minusl [ i] ue(v) for( j = 0:j < num brick rows minus 1 { i]; j++ ) brick row height minusl [ii [I] ue(v)

I [...]

TABLE 18

for (lit i = 0; i < NumBricksInPic; i++) BrickScan[ i] = i

TABLE 19

bIdx -0 -For (i e; i < NumBricksInTile; i++) { for (j = 0; j < NumTilesInPic; i++) 1 BrickScan[bIdx] = j * NumBricksInTile + i bIdx++

TABLE 20

-For (i=0; NumTilesInPic; i++) f currentBrick[i] = FirstBrickIdx[i] brickIdx = 0 while (brickIdx < NumBricksInPic) BrickScan[brickIdx] = currentBrick[0] currentBrick[e]++ brickIdx++ for (1=1; NumTilesInPic; i++) { BrickAdded = GetBrickNextTil"brickIdx, BrickScan, I. currentBrick, BrickRowBd[BrickScan[brickIdx-i]]) if ( !BrickAdded) break

TABLE 21

bee! GetBrickN t (brickIdx, BrickScan, tileIdx, currentBrick, RowBdMax) if (BrickRowBd[currentBrick[tileIdx] > RowBdMax) return false; kthile(BrickRowBd[currentBrick[tileIdx]] <= RowBdMax) BrickScan[brickIdx] = currentBrick[tileIdx] ; brickIdx++; If (BrickRowBd[currentBrick[tileIdx] == PicHeightInCtbsY) f return true; eilse { currentBrick[tileIdx] ++; return true;

TABLE 22

for (i=0; NumTilesInPic; i++) f currentBrick[i] = FirstBrickIdx[i] brickIdx = 0 while (brickIdx < NumBricksInPic) BrickScan[brickIdx] = currentBrick[0] brickIdx++ GetBrickNeTiim2(brickIdx, BrickScan, 1, currentBrick, BrickRowBd[BrickScan[brickIdx-l]]) If (BrickRowBd[currentBrick[0]] == PicHeightInCtbsY) f break else f currentBrick[0]

TABLE 23

void GetBrickNextTile(brickIdx, BrickScan, tileIdx, currentBrick, RowBdMax) Ic(BrickRowBd[currentBrick[tileIdx]] <= RowBdMax) BrickScan[brickIdx] = currentBrick[tileIdx] brickIdx++ if (tileIdx + I < NumTilesInPic) GetBrickNextTiie(brickIdx, BrickScan, tileIdx+a, currentBrick, BrickRowBd[brickScan[brickIdx-1]]) IF (BrickRowBd[currentBrick[tileIdx]] == PicHeightInCtbsY) f rEturri; currentBrick[tileIdx] ++ r'eturn;

TABLE 24

for( ctbAddrRs = 0; ctbAddrRs < PicSizeInCtbsY; ctbAddrRs++ ) f tbX = ctbAddrRs % PicWidthInCtbsY tbY = ctbAddrRs / PicWidthInCtbsY brickFound -FALSE for( bkIdx = NumBricksInPic -1, i = u; i < NumBricksInPic -1 && !brickFound; i++ ) f brickFound = tbX < ( BrickColBd[ i] + BrickWidth[ i] ) && tbY < ( BrickRowBd[ i] + BrickHeight[ i] ) if( brickFound) bkIdx = i CtbAddrRsToBs[ ctbAddrRs] = i = 0 while (BrickScan[i] != bkIdx) { CtbAddrRsToBs[ ctbAddrRs] += BrickHeight[ BrickScan[i] ] * BrickWidth[ BrickScan[i] ] i++ CtbAddrRsToBs[ ctbAddrRs] += ( tbY -BrickRowBd[ bkIdx] ) * BrickWidth[ bkIdx] + tbX -BrickColBd[ bkIdx]

TABLE 25

Claims

CLAIMS1. A method for encoding a picture comprising a data array with a first dimension and a second dimension, said method comprising: partitioning the data array into a set of rectangular tiles in which all tiles have a side of length equal to the size of the first dimension of the data array, partitioning at least one of the tiles into a set of rectangular bricks in which all bricks of the set have a side of length equal to the size of the side of the file to which the bricks belong in the second dimension of the data array, obtaining a brick scanning order information, and then encoding the picture by encoding each brick based on the obtained brick scanning order information.
2. The method according to claim 1, wherein the first dimension is associated with the height of the picture and the second dimension is associated with the width of the picture, so that the tiles form one row of rectangular columns and each tile contains one column of rectangular bricks.
3. The method according to claim 1 or 2, wherein the set of tiles comprises n tiles, n being a strictly positive integer, the sizes of at least n-1 files in the second dimension being equal.
4. The method according to claim 1, 2 or 3, wherein, for at least one tile of the set of tiles, the sizes of the bricks contained in the file are equal in the first dimension.
5. The method according to claim 1, 2, 3 or 4, wherein the brick partition is identical for all the files.
6. The method according to claim 1, 2, 3, 4 or 5, wherein the encoding of the picture comprises defining a first syntax element associated with the encoded picture, said syntax element comprising the brick scanning order information.
7. The method according to claim 6, wherein the encoding of the picture further comprises defining a second syntax element associated with at least one tile and describing the brick partitioning of the at least one tile.
8. The method according to claim 7, wherein the brick partitioning is only defined in the second syntax element associated with a reference tile when the brick partition is identical for several tiles of the set.
9. The method according to claim 8, wherein the reference tile corresponds to a first tile in a tile scanning order.
10. The method according to claim 7, wherein, when the brick partitioning of the tile is identical to the brick partitioning of a previous tile in a tile scanning order, the second syntax element associated with the file contains a reference to the second syntax element of the previous tile.
11. The method according to any one of claims 1 to 10, wherein the brick scanning order information includes a scan order across the tiles in which the bricks are encoded by following a raster scan direction or includes a scan order within the tile in which all bricks of a tile are encoded before encoding the bricks of the following tile.
12. The method according to claim 11, wherein, when the scan order across the tiles is such that the bricks are encoded by following a raster scan direction, the brick partitioning is constrained so that it forms a grid of bricks.
13. The method according to any one of claims 1 to 12, wherein the method comprises further, after partitioning the tiles, defining at least one slice comprising a set of adjacent bricks.
14. The method according to claim 13, wherein the slice forms a rectangular shape comprising bricks of at least two tiles, the bricks of at least one tile forming a subset of the set of bricks partitioning the tile.
15. The method according to claim 14, wherein the slice is defined in the first syntax element by reference to the first brick and to the last brick in the brick scanning order of the set of bricks part of the slice.
16. The method according to claim 15, wherein the data array is partitioned into a set of rectangular slices such that the first brick of a slice of the set is encoded after the bricks of the previously encoded slices.
16. A method for decoding an encoded picture comprising at least tiles and bricks, said method comprising: determining a tile partitioning of the encoded picture, determining a brick partitioning of the encoded picture, obtaining a brick scanning order information, decoding each coded brick of the encoded picture, constructing the picture by assembling the decoded bricks based on the brick partitioning, the file partitioning, and the obtained brick scanning order information.
18. The method according to claim 17, wherein the determining of a tile partitioning comprises reading syntax elements for determining a number of tiles and widths of the tiles.
19. The method according to claim 17 or 18, wherein the determining of a brick partitioning comprises determining a brick partitioning for each tile.
20. The method according to one of claims 17 to 19, wherein the determining of a brick partitioning comprises reading syntax elements describing a partitioning of a reference tile, said partitioning corresponding to a brick pattern.
21. The method according to claim 20, wherein if the syntax elements comprise only one brick pattern, the brick partitioning forms a grid.
22. The method according to claim 20, wherein the determining of a brick partitioning further comprises determining a brick pattern index for each brick pattern and determining an association of the brick pattern index with a tile index, then the partitioning of the tile associated to the tile index is described by the brick pattern associated to the brick pattern index.
23. The method according to claim 22, wherein the brick scan order consists in scanning each brick of the picture horizontally across the tile boundaries.
24. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing each of the steps of the methods according to any one of claims 1 to 23 when loaded into and executed by the programmable apparatus.
25. A non-transitory computer-readable storage medium storing instructions of a computer program for implementing each of the steps of the methods according to any one of claims 1 to 23.
26. A device comprising a processing unit configured for carrying out each of the steps of the methods according to any one of claims 1 to 23.
27. A signal carrying an encoded picture, the encoded picture comprising at least syntax elements comprising partitioning data of the picture into tiles and bricks and a brick scanning order information of said tiles and bricks, as resulting from the method according to any one of claims 1 to 16.
28. A media storage device storing a signal carrying an encoded picture, the encoded picture comprising at least syntax elements comprising partitioning data of the picture into tiles and bricks and a brick scanning order information of said tiles and bricks, as resulting from the method according to any one of claims 1 to 16.