Encoder and decoder, encoding method and decoding method for versatile spatial partitioning of coded image

Abstract

To provide an encoding method, a decoding method, and an apparatus for reconstructing an image of a video.SOLUTION: A video decoder 151 comprises: an interface 160 for receiving an encoded video signal; and a data decoder 170 for reconstructing an image of a video by decoding encoded image data using display data. The image is partitioned into a plurality of coding areas, each coding area being located within the image. Each of the coding areas includes one or more coding tree units of a plurality of coding tree units being located within the image. The data decoder 170 decodes the encoded image data according to an order of one or more coding areas including two or more coding tree units, by using the display data including information on a coding order of the one or more coding areas including two or more coding tree units.SELECTED DRAWING: Figure 1b

Description

[Technical field]

[0001] The present invention relates to video encoding and video decoding, in particular to an encoder and decoder, an encoding method and a decoding method for various spatial partitions of a coded image. [Background technology]

[0002] H.265 / HEVC is a video codec that already offers tools to improve or even enable parallel processing in the encoder and / or decoder. For example, HEVC supports the subdivision of an image into an array of tiles that are coded independently of each other. Another concept supported by HEVC is related to WPP, according to which CTU rows or CTU lines of an image can be processed in parallel from left to right, for example in stripes, if some minimum CTU offset is respected in the processing of successive CTU lines (CTU=coding tree unit). However, it would be desirable to have a video codec at hand that supports the parallel processing capabilities of a video encoder and / or video decoder even more efficiently. In the next section "State-of-the-art VCL partitioning" we explain the introduction of state-of-the-art VCL partitioning (VCL = Video Coding Layer).

[0003] Usually, in video coding, the coding process of an image sample requires smaller partitions, where the sample is divided into several rectangular regions for joint processing such as prediction or transform coding. Therefore, the image is divided into blocks of a certain size that is constant during the encoding of a video sequence. In H.264 / AVC, a standard fixed size block of 16x16 samples, the so-called macroblock, is used. In the state-of-the-art HEVC standard (see [1]), there are coding tree blocks (CTBs) or coding tree units (CTUs) of maximum size 64x64 samples. In the detailed description of HEVC, the more general term CTU is used for such kind of blocks. The CTUs are processed in a raster scan order starting with the top left CTU and processing the CTUs of the image linearly to the bottom right CTU.

[0004] The coded CTU data is organized into a kind of container called a slice, which originally meant a segment of an image that contained one or more contiguous CTUs.

[0005] In the following subsection "Segmenting an image using slices" we explain how slices are used for segmentation of the coded data. From another point of view, the whole picture can also be defined as one large segment, so the term slice still applies, as is conventional. In addition to the coded image samples, slices also contain additional information related to the coding process of the slice itself, which is placed in the so-called slice header.

[0006] According to the state of the art, the VCL also features techniques for fragmentation and spatial partitioning. Such partitioning can be applied to video coding for various reasons, such as handling load balancing in parallelization, size matching of CTUs in network transmission, and error mitigation, as will be explained in more detail below. The next subsection, "Segmenting an Image Using Slices," describes segmenting an image using slices.

[0007] Since the H.263 standard, sequences of data representing consecutive blocks in a particular scan order can be organized into groups called slices. Typically, dependencies between CTUs of different slices of an image are forbidden, e.g. in terms of prediction and entropy coding, so that individual slices in an image can be reconstructed independently.

[0008] Figure 2 shows image segmentation by slices in raster scan order. The size of a slice is determined by the number of CTUs (coding tree units) and the size of each coded CTU belonging to the slice, as shown in Figure 2. Figure 2 includes 50 CTUs, e.g., CTU21, CTU24 and CTU51.

[0009] In the next subsection "Segmenting an Image Using Tiles", segmenting an image using tiles is described with reference to Figure 3. Figure 3 includes 50 CTUs, e.g., CTU23, CTU27 and CTU41.

[0010] Tiles are a concept introduced in HEVC that is very similar to the Flexible Macroblock Ordering (FMO) added to H.264 / AVC. The tile concept allows you to divide an image into a number of rectangular regions.

[0011] Thus, a tile is the result of dividing the original image into a specified number of rows and columns of a specified height and width, respectively, as shown in Figure 3. As a result, tiles in an HEVC bitstream must have a common boundary that forms a regular grid. In the next subsection, “Use cases and drawbacks of state-of-the-art partitioning”, we discuss the use cases and drawbacks of state-of-the-art partitioning with reference to Figures 4 and 5.

[0012] Figure 4 shows tile-based 360° video streaming with unequal resolutions. In 360° video streaming, viewport adaptive streaming technology, called tile-based 360° video streaming, has attracted attention. The main idea is to provide a 360° video composed of multiple tiles with various resolutions. Thus, depending on the current viewport, the client downloads some tiles that match the viewport in high resolution and other tiles outside the viewport in low resolution, as shown in Figure 4.

[0013] On the client side, the receiver combines these downloaded tiles at different resolutions into a single HEVC bitstream. The downloaded tiles, on the other hand, can no longer be described as tiles in the HEVC syntax, because they do not share the same boundary in the overall picture, and the granularity of the tiles in the original stream is different. For example, see the dashed lines above and below the low-resolution part in Figure 4. This can only be expressed as a slice boundary in the HEVC syntax, since there is no corresponding boundary in the high-resolution part on the left.

[0014] Another scenario where more flexible image segmentation is beneficial is low-latency conversational applications. Image segmentation is also used to parallelize the decoding / encoding. In some cases, this parallelization is the only way to achieve real-time decoding / encoding. One can imagine a video conferencing scenario where there are two people in a photo. FIG. 5 shows the flexible division of coding regions.

[0015] Perhaps a good image partitioning that can be used to achieve a fair load distribution (in terms of coding complexity) could be the one shown in Figure 5. However, in this scenario, a rectangular tiling grid is required, which does not provide the desired flexibility in tiling.

[0016] Another main objective of segmentation (using slices) is error robustness. If some slices of an image are lost, it does not prevent the reconstruction of the successfully received slices, and therefore outputs a partially reconstructed image that can be further used as a reference image in the temporal prediction process of the next image. This feature is very important in transmission systems with high error rates or where the content of each image is very important. On the other hand, there are also transmission schemes, e.g. dynamic adaptive streaming over HTTP like MPEG DASH, that feature error detection and mitigation techniques at the transport layer (TCP / IP) and where buffer stalls are the solution for transmission errors until a successful retransmission. In such scenarios, introducing additional dependencies may undermine error resilience. State-of-the-art slice and tile partitions are also inflexible in that respect. Summary of the Invention [Problem to be solved by the invention]

[0017] It is an object of the present invention to provide an improved concept for video encoding and video decoding.

[0018] The object of the present invention is solved by a video encoder according to claim 1, a video decoder according to claim 57, a system according to claim 113, a video encoding method according to claim 114, a video decoding method according to claim 115, a computer program according to claim 116 and an encoded video signal according to claim 117. [Means for solving the problem]

[0019] A video encoder for encoding an image by generating an encoded video signal is provided. The video encoder includes a data encoder configured to encode an image of a video into encoded image data, the data encoder further configured to generate instruction data. The video encoder further includes a signal generator configured to generate an encoded video signal including the encoded image data and the instruction data. The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions is located within the image, each of the plurality of coding regions includes one or more coding tree units of a plurality of coding tree units located within the image, the data encoder is configured to encode the image in dependence on the plurality of coding regions, and the data encoder is configured to generate the instruction data such that the instruction data includes information regarding the plurality of coding regions. One or more coding regions of the multiple coding regions include two or more coding tree units of the multiple coding tree units, and each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of the coding region, and the data encoder is configured to encode the image depending on the coding order of the one or more coding regions including two or more coding tree units, and the data encoder is configured to generate instruction data such that the instruction data includes information regarding the coding order of the one or more coding regions including the two or more coding tree units.

[0020] Further provided is a video decoder for decoding an encoded video signal comprising encoded image data and instruction data for an image of the video to reconstruct an image of the video, the video decoder comprising an interface configured to receive the encoded video signal and a data decoder configured to reconstruct the image of the video by decoding the encoded image data using the instruction data, the image being divided into a plurality of coding regions, each coding region of the plurality of coding regions being located within the image, each of the plurality of coding regions comprising one or more coding tree units of a plurality of coding tree units located within the image, the data decoder configured to decode the encoded image in dependence on the plurality of coding regions, the instruction data comprising information regarding the plurality of coding regions. One or more coding regions of the plurality of coding regions include two or more coding tree units of the plurality of coding tree units, and each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of the coding region, and the data decoder is configured to decode the encoded image data according to the coding order of the one or more coding regions including two or more coding tree units using instruction data, the instruction data including information regarding the coding order of the one or more coding regions including the two or more coding tree units. Further provided is a method for encoding an image by generating an encoded video signal, the method comprising: - encoding the images of the video into coded image data; - generating instruction data; and - generating an encoded video signal including encoded image data and instruction data; Includes.

[0021] The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions being located within the image, each of the plurality of coding regions comprising one or more coding tree units of a plurality of coding tree units located within the image, the encoding of the image is performed in dependence upon the plurality of coding regions, and the generating of the instruction data is performed such that the instruction data comprises information regarding the plurality of coding regions, one or more coding regions of the plurality of coding regions comprising two or more coding tree units, each coding region of the one or more coding regions comprising two or more coding tree units indicates a coding order of the two or more coding tree units of said coding regions, the encoding of the image is performed in dependence upon the plurality of coding regions, and the generating of the instruction data is performed such that the instruction data comprises information regarding the coding order of the one or more coding regions comprising two or more coding tree units.

[0022] Further provided is a method for decoding an encoded video signal comprising encoded image data and indicative data of an image of the video to reconstruct an image of the video, the method comprising: - receiving an encoded video signal; and -reconstructing an image of the video by decoding the encoded image data using the instruction data Includes.

[0023] The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions is located within the image, each of the plurality of coding regions includes one or more coding tree units of a plurality of coding tree units located within the image, and performing, using the instruction data, decoding image data encoded in dependence on the plurality of coding regions, the instruction data including information regarding the plurality of coding regions, one or more coding regions of the plurality of coding regions includes two or more coding tree units of the plurality of coding tree units, each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of said coding region, and performing, using the instruction data, decoding image data encoded in dependence on the coding order of the one or more coding regions including two or more coding tree units, the instruction data including information regarding the coding order of the one or more coding regions including two or more coding tree units. Furthermore, a computer program is provided for carrying out one of the above methods when executed on a computer or signal processor.

[0024] Further provided is an encoded video signal for encoding an image, wherein the encoded video signal comprises encoded image data and instruction data, the image being divided into a plurality of coding regions, each coding region of the plurality of coding regions being located within the image, each of the plurality of coding regions comprising one or more coding tree units of a plurality of coding tree units located within the image, the image being encoded in dependence on the plurality of coding regions, the instruction data comprising information regarding the plurality of coding regions, one or more coding regions of the plurality of coding regions comprising two or more coding tree units, each coding region of the one or more coding regions comprising two or more coding tree units indicating a coding order for the two or more coding tree units of said coding region, the image being encoded in dependence on a coding order for the one or more coding regions comprising two or more coding tree units, and the instruction data comprising information regarding the coding order of the one or more coding regions comprising two or more coding tree units. In the following, embodiments of the invention are explained in more detail with reference to the following figures: [Brief description of the drawings]

[0025] [Figure 1a] 1 illustrates a video encoder for encoding an image by generating an encoded video signal according to an embodiment; [Figure 1b] 1 shows a video decoder for decoding an encoded video signal comprising encoded image data and indication data of an image of a video to reconstruct an image of the video according to an embodiment; [Figure 1c] 1 illustrates a system according to an embodiment. [Diagram 2] 1 shows image segmentation by slices in raster scan order. [Diagram 3]1 illustrates image division using tiles. [Figure 4] Shown is tile-based 360° video streaming with unequal resolution. [Diagram 5] 1 shows flexible coding region division. [Figure 6] 1 illustrates a bitstream containing a single image of one implicit coding region according to an embodiment. [Figure 7] 13 illustrates a bitstream containing a single image of four coding regions according to another embodiment. [Figure 8] 13 illustrates spatial subdivision of an image with a single CA on top and three CAs on the bottom according to an embodiment. [Figure 9] 13 illustrates spatial subdivision of an image with five coding regions according to another embodiment. [Figure 10] 1 illustrates two coding regions, one of which consists of non-contiguous CTUs, including a border CTU of an image, according to an embodiment. [Figure 11] 1 illustrates coding region signaling at the sub-region (CTU) level according to an embodiment. [Figure 12] 1 illustrates CTU scan order and spatial referencing for CTU_dependency_offset_id=1 according to an embodiment. [Figure 13] 13 illustrates another CTU scan order and spatial references for CTU_dependency_offset_id=2 according to another embodiment. [Figure 14] 1 illustrates a coding region in Z-scan CTU order, according to an embodiment. [Figure 15] 13 illustrates the derivation of an implicit CTU scan direction according to another embodiment. [Figure 16] 1 illustrates a coding region in different CTU scanning directions, according to an embodiment. [Figure 17] 1 illustrates dependent coding regions with inter-region prediction option, according to an embodiment. [Figure 18]1A-1D show parallel processing of dependent coding regions according to an embodiment ((A) CTU raster scan; (B) CTU diagonal scan). [Figure 19] 4A-4C show execution order and inter-CA dependencies according to an embodiment ((A) dependency-driven; (B) lockstep). [Figure 20] 1 illustrates a deblocking filter process at a CA boundary for a CA order, according to an embodiment. [Figure 21] 1 illustrates a deblocking filter employing CA-to-CA filtering with hatched filter regions, according to an embodiment. [Figure 22] Although it shows a bitstream consisting of a single image with one coding region, the CA is fragmented into multiple transport units. [Diagram 23] It shows a bitstream consisting of a single image of multiple coding regions, where each CA has its own transport unit. [Figure 24] It shows a bitstream containing a single image of multiple coding regions, but with each CA fragmented into multiple transport units. [Diagram 25] 1 illustrates a generalized presentation of a block surrounded by a region, according to an embodiment. [Figure 26] 1 illustrates an example of an image divided into tiles, bricks, and rectangular slices, according to an embodiment, where the image is divided into 4 tiles, 11 bricks, and 4 rectangular slices. [Figure 27] 1 shows an image that is hierarchically partitioned according to an embodiment, where in a first step a first partition of the image is obtained in the horizontal and vertical directions, and in a second step a second partition of the image is obtained only in the horizontal direction. [Figure 28] 1 shows an image that is hierarchically partitioned according to another embodiment, where in a first step a first partition of the image is obtained in the horizontal and vertical directions, and in a second step a second partition of the image is obtained only in the vertical direction. [Figure 29]1 shows an image that is hierarchically partitioned according to a further embodiment, where in a first step a first partition of the image is obtained in the horizontal direction only, and in a second step a second partition of the image is obtained in the vertical direction only. [Diagram 30] 1 shows an image that is hierarchically partitioned according to a still further embodiment, where in a first step a first partition of the image is obtained in the vertical direction only, and in a second step a second partition of the image is obtained in the horizontal direction only. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] FIG. 1a shows a video encoder 101 for encoding images by generating an encoded video signal according to an embodiment.

[0027] The video encoder 101 comprises a data encoder 110 configured to encode the images of the video into encoded image data. The data encoder 110 is further configured to generate instruction data.

[0028] Furthermore, the video encoder 101 comprises a signal generator 120 configured to generate an encoded video signal including encoded image data and instruction data.

[0029] The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions is located within the image, and each of the plurality of coding regions includes one or more coding tree units of a plurality of coding tree units located within the image. The data encoder 110 is configured to encode the image dependent on the plurality of coding regions, and the data encoder 110 is configured to generate the instruction data such that the instruction data includes information regarding the plurality of coding regions.

[0030] One or more coding regions of the plurality of coding regions include two or more coding tree units of the plurality of coding tree units, and each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of said coding region. The data encoder 110 is configured to encode the image depending on the coding order of the one or more coding regions including two or more coding tree units. Furthermore, the data encoder 110 is configured to generate the instruction data, such that the instruction data includes information regarding the coding order of the one or more coding regions including two or more coding tree units.

[0031] FIG. 1b shows a video decoder 151 for decoding an encoded video signal comprising encoded image data and indication data of an image of a video to reconstruct an image of the video according to an embodiment. The video decoder 151 comprises an interface 160 arranged to receive the encoded video signal.

[0032] Additionally, the video decoder 151 comprises a data decoder 170 configured to reconstruct the images of the video by decoding the encoded image data using the instruction data.

[0033] The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions being located within the image, and each of the plurality of coding regions including one or more coding tree units of a plurality of coding tree units located within the image. Using the instruction data, the data decoder 170 is configured to decode image data encoded in dependence on the plurality of coding regions, the instruction data including information regarding the plurality of coding regions.

[0034] One or more coding regions of the plurality of coding regions include two or more coding tree units of the plurality of coding tree units, and each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of the coding region. Using the instruction data, data decoder 170 is configured to decode the encoded image data depending on the coding order of the one or more coding regions including two or more coding tree units, and the instruction data includes information regarding the coding order of the one or more coding regions including two or more coding tree units.

[0035] According to an embodiment, the video decoder 151 of FIG. 1b may be configured to output images of the video to, for example, an output device, for example a display of a television, a computer, a mobile phone, or the like.

[0036] Fig. 1c shows a system according to an embodiment. The system comprises a video encoder 101 according to Fig. 1a. Furthermore, the system comprises a video decoder 151 according to Fig. 1b. The video encoder 101 of FIG. 1a is configured to generate an encoded video signal. The video decoder 151 of FIG. 1b is configured to decode the encoded video signal to reconstruct the video images. In the next section, "Versatile Image Segmentation Using Coding Regions," we discuss versatile image segmentation using coding regions. The next subsection, "Coding Region," describes the coding region.

[0037] Going beyond current state-of-the-art partitioning schemes such as tiles, embodiments present a more flexible concept of spatial domain definition, which may be called, for example, coding domains (CAs). This is an advantageous concept for spatially partitioning an image into rectangular regions. The use of coding domains makes the partitioning more flexible, allowing individual regions to have their own domain-specific coding characteristics.

[0038] A coding region is defined by the dimensions and location of a particular region (width, height, position) and how the data in the region should be processed. Signaling can be done in terms of low-level coding process specifications or in terms of higher-level parameters such as scan order, scan direction, scan start, etc.

[0039] 6 shows a bitstream containing a single image with one implicitly coded region according to an embodiment. (NAL=Network Abstraction Layer; NALUH=Network Abstraction Layer Unit Header; SH=Slice Header) FIG. 7 shows a bitstream containing a single image with four coding regions according to another embodiment.

[0040] If no partitioning is applied, the image implicitly contains one coding region (CA), see Fig. 6. This can be a default coding region with predefined features. Fig. 7 shows the subdivision of an image into multiple CAs. In an embodiment, the data encoder 110 of FIG. 1a may be configured, for example, to divide an image into multiple coding regions.

[0041] Figure 8 illustrates a spatial subdivision of an image with a single coding area (CA) on top and three CAs on the bottom, according to an embodiment. Each square in Figures 8 and 9 represents a coding tree unit (CTU). Although Figures 8 and 9 illustrate a CTU having a square shape, the CTU may have, for example, a rectangle or any other shape in other examples.

[0042] As can be seen in Figures 8 and 9, each coding region in Figures 8 and 9 extends in a rectangle in the image. Additionally, in Figures 8 and 9, each CTU extends in a rectangle in the image.

[0043] Thus, according to an embodiment, each coding region of the plurality of coding regions may extend, for example, rectangularly in the image. Each coding tree unit of the one or more coding tree units of each of the plurality of coding regions may extend, for example, rectangularly in the image. FIG. 9 shows the spatial subdivision of an image with five coding regions according to another embodiment. One of the key advantages of CA partitioning is: Figures 8 and 9 show two examples of the new partitioning concept.

[0044] In some use cases, CA partitioning can be achieved that is not possible with tiles, and CA partitioning results in less partitioning. As can be seen from the tile-based partitioning in Figure 3, to create three separate regions (Tile4, Tile5, Tile6) at the bottom of the image, three additional regions (Tile1, Tile2, Tile3) must be coded at the top of the image. As shown in Figure 8, using coding regions, the top region can be coded as one coding region CA1. And the partitioning shown in Figure 9 cannot be achieved via tiles either, because CA1, CA2, and CA3 do not have the same height.

[0045] According to an embodiment, each of the multiple coding tree units may have, for example, a horizontal position in the image and a vertical position in the image. Figures 8 and 9 show horizontal positions of CTUs 1 to 10 and vertical positions of CTUs 1 to 5. Of course, in such an embodiment, the positions do not have to start at 1 and the step from one horizontal or vertical position to the next position is 1. Instead, other starting positions and other steps from CTU to CTU are possible. The size of the step from one CTU to the next for the vertical positions may be different from the size of the step from one CTU to the next for the horizontal positions. The new division of FIG. 9 can be characterized, for example, as follows:

[0046] In such an embodiment, (Alternative 1) a first coding region of the plurality of coding regions may, for example, include a first coding tree unit having a first vertical position that is identical to a second vertical position of a different second coding tree unit of a different second coding region of the plurality of coding regions, a third coding tree unit of the first coding region having a third vertical position that is different from the vertical position of any other coding tree unit of the second coding region, and a fourth coding tree unit of the second coding region having a fourth vertical position that is different from the vertical position of any other coding tree unit of the first coding region.

[0047] Or, (Alternative 2) a first coding region of the plurality of coding regions may, for example, include a first coding tree unit having a first horizontal position that is identical to a second horizontal position of a different second coding tree unit of a different second coding region of the plurality of coding regions, and a third coding tree unit of the first coding region having a third horizontal position that is different from the horizontal positions of any other coding tree units of the second coding region, and a fourth coding tree unit of the second coding region having a fourth horizontal position that is different from the horizontal positions of any other coding tree units of the first coding region. Figure 9 satisfies Alternative 1.

[0048] CA2 is composed of CTU91. CTU91 has vertical position 3. CTU96 in CA4 is also at vertical position 3. CTU92 in CA2 has vertical position 2. No CTU in CA4 has vertical position 2 (because CA4's vertical positions are in the range 3-5). Additionally, CTU97 in CA4 has vertical position 4. No CTU in CA2 has vertical position 4 (because CA2's vertical positions are in the range 1-3). In contrast, Figure 8 does not satisfy Alternative 1 and does not satisfy Alternative 2. Alternative 1:

[0049] Only CA2, CA3, and CA4 are at the same vertical position (range 3-5). CA1 does not have the same vertical position as any other coding region. However, CA2 does not have a vertical position that differs from any other vertical position of coding regions CA3 or CA4. The same is true for CA3 and CA4 with respect to CA2, CA4, and CA2, CA3, respectively. Alternative 2: CA2, CA3, and CA4 do not have CTUs at the same horizontal position.

[0050] In contrast, CTU 81 in CA1 is at the same horizontal position (3) as CTU 86 in CA2. Moreover, because the horizontal positions of CA2 range from 1 to 4, none of the CTUs in CA2 is at horizontal position 6 as CTU 82 in CA1. However, because the horizontal positions of the CTUs in CA2 range from 1 to 4 and the horizontal positions of the CTUs in CA1 range from 1 to 10, no CTU in CA2 is at a different horizontal position than any of the other CTUs in CA1. For similar reasons, the same can be said about CA3 and CA4 with respect to CA1. Therefore, the division in FIG. 8 does not satisfy alternative 1 and does not satisfy alternative 2.

[0051] The signaling mechanisms for some CA parameters related to fragmentation and scan order are presented in the sub-subsection "General Properties of Coding Regions".

[0052] Spatially, a coding region covers a certain number of CTUs. Flexible placement of CAs is one of the features of some embodiments. Several variations on this are suggested, both explicit signaling and hierarchical methods outside the VCL. Also, signaling within the VCL can be used if bitstream fragmentation is not used. A detailed description of CA placement is provided in the sub-subsection "Coding Region Size and Placement".

[0053] In addition to the segment placement, embodiments provide a new flexible processing or scanning order of CTUs within a coding region, the details of which are given in the sub-subsection "CTU Scanning Order."

[0054] One other invented feature is that within a single image, one CA can be independent and / or dependent on other coding regions, as described in the sub-subsection "Dependent Coding Regions".

[0055] The newly proposed methods, when used in combination, provide new opportunities for high levels of parallelism: spatial image domain parallelism can be performed in a more efficient manner, as detailed in the sub-subsection "Coding Domain Parallelism". Error resilience aspects are described in the sub-subsection "Error Resilience Aspects." To summarize the above concepts:

[0056] According to an embodiment, each coding area of ​​a plurality of coding areas may exhibit spatial characteristics including a position, a width, and a height of the coding area, the width and height of the coding area depending on a rectangular extension of the coding area, and the position of the coding area depending on the position of the coding area within the image.

[0057] In an embodiment, a first height of a first one of the plurality of coding regions may be different from a second height of a second one of the plurality of coding regions, for example, or a first width of a first one of the plurality of coding regions is different from a second width of a second one of the plurality of coding regions.

[0058] According to an embodiment, the data encoder 110 may be configured to generate the instruction data, for example, such that the information regarding the plurality of coding regions includes information regarding spatial characteristics of each coding region of the plurality of coding regions.

[0059] In an embodiment, the data encoder 110 may be configured to generate the instruction data such that the information regarding the multiple coding regions includes, for example, a position, a width, and a height of each coding region of the multiple coding regions.

[0060] According to an embodiment, the data encoder 110 may be configured to, for example, encode image data of an image portion of each of the plurality of coding areas independently of encoding image data of the image portion of any other coding area of ​​the plurality of coding areas to obtain encoded image data.

[0061] In an embodiment, the data encoder 110 may be configured to encode the image, for example, by encoding image data of an image portion in each coding area of ​​a plurality of coding areas to obtain encoded image data. The data encoder 110 may be configured to encode image data of at least one image portion of the plurality of coding areas such that encoding the image data of at least one of the plurality of coding areas is dependent on encoding the image data of at least another one of the plurality of coding areas.

[0062] In an embodiment, data encoder 110 may be configured to determine a coding order for each one of one or more coding regions that includes, for example, two or more coding tree units.

[0063] According to an embodiment, the data encoder 110 may be configured to determine the coding order, for example, for each one of the one or more coding regions by selecting a scan order from two or more scan orders for each one of the one or more coding regions.

[0064] In an embodiment, the signal generator 120 may be configured to generate the encoded video signal, for example, such that the encoded video signal includes a bitstream, the bitstream including encoded image data and instruction data.

[0065] Similarly, according to an embodiment, each coding region of the plurality of coding regions may exhibit spatial characteristics including a position, a width, and a height of the coding region, the width and height of the coding region depending on the rectangular extension of the coding region, and the position of the coding region depending on the position of the coding region within the image. Data decoder 170 may be configured to decode the encoded image data, for example, depending on the spatial characteristics of the plurality of coding regions.

[0066] In embodiments, a first height of a first one of the plurality of coding regions may be different from a second height of a second one of the plurality of coding regions, for example, or a first width of a first one of the plurality of coding regions is different from a second width of a second one of the plurality of coding regions.

[0067] According to an embodiment, the data decoder 170 may be configured to decode the encoded image data using information in the instruction data regarding spatial characteristics of the multiple coding regions.

[0068] According to an embodiment, the data decoder 170 may be configured to decode image data that has been encoded using information in the instruction data for the multiple coding regions, for example, where the information regarding the multiple coding regions includes the position, width, and height of each coding region of the multiple coding regions.

[0069] According to an embodiment, data decoder 170 may be configured to decode the encoded image data of each of the multiple coding regions, for example, independently of decoding the encoded image data of any other coding region of the multiple coding regions.

[0070] According to an embodiment, data decoder 170 may be configured, for example, to decode encoded image data of at least one of a plurality of coding regions, the decoding of the encoded image data of the at least one of the plurality of coding regions being dependent on the decoding of encoded image data of at least another of the plurality of coding regions.

[0071] According to an embodiment, the data decoder 170 may be configured to decode image data that has been encoded using a coding order of a respective one of one or more coding regions that includes, for example, two or more coding tree units, the coding order of the respective one of the one or more coding regions being indicated by instruction data.

[0072] According to an embodiment, data decoder 170 may be configured to decode image data encoded using, for example, an indication of a scan order from two or more scan orders for a respective one of the one or more coding regions, and the instruction data may include an indication of the scan order for the respective one of the one or more coding regions.

[0073] According to an embodiment, interface 160 may be configured to receive, for example, a bitstream, the bitstream including encoded image data and instruction data. The next sub-subsection, "General Properties of Coding Regions," describes general properties of coding regions.

[0074] General information about coding regions is concentrated in so-called coding region sets (CAS), which are high-level parameter sets that can be solved outside of the VCL and affect the whole sequence or parts of a sequence, e.g. an image. x = video, sequence, image…

[0075] [Table 1]

[0076] Table 2-1 [Table 2]

[0077] coding_area_explicit_positioning_flag If true, coding_area_top_left_CTU_address is present in the bitstream, otherwise the default implicit CA positioning is used. num_coding_areas_minus1 The number of coding areas signaled in the bitstream.

[0078] dependent_coding_areas_enabled_flag If true, indicates that the CAs that follow the bitstream are dependent on each other in the order they appear in the bitstream, otherwise the CAs are treated as independent areas.

[0079] coding_areas_CTU_wise_dependent_flag If true, indicates that CTU-wise dependencies between adjacent CAs are handled with CTU-wise processing that interleaves CA processing, otherwise CAs are processed individually in a fixed order.

[0080] coding_area_no_slices_flag If true, indicates one slice per CA. This means that EOS_flag and CTU_start_address are not present in the bitstream. CAs are instead addressed by CA_idx, which is a fixed length code derived from ceil(log2(num_coding_areas_minus1+1)). Otherwise the default slice syntax is present in the bitstream.

[0081] coding_area_CTU_scan_flag If true, indicates that the CTU scan parameters are present in the bitstream. A flexible CTU scanning strategy is described in the subsection "CTU Scan Order". coding_area_CTU_scan_type_idx Maps to the scan type table (raster scan, diagonal scan).

[0082] coding_area_CTU_scan_start_left_flag[i] If present and true if the i-th CA consists of multiple CTUs per CTU line, indicates that CTU scanning should start at the leftmost CTU in the CA. Otherwise, CTU scanning for the i-th CA starts at the rightmost CTU.

[0083] coding_area_CTU_scan_start_top_flag[i] If present if the i-th CA consists of multiple CTUs per CTU column, and if true, indicates whether to start the CTU scan at the top CTU row in the CA. Otherwise, the CTU scan for the i-th CA starts at the bottom of the CTUs in the CA.

[0084] coding_area_CTU_scan_direction_flag[i] Present if the i-th CA contains at least two CTU rows and two CTU columns, indicating the starting scan direction of the CTU scan. If true, the scan direction of the i-th CA starts from horizontal. Otherwise, the scan is vertical. To summarize the above concepts:

[0085] In an embodiment, the data encoder 110 may be configured to generate the indication data, such that the indication data may include information for each coding area regarding whether the address of the top left coding tree unit is specified. A specific example may be, for example, coding_area_explicit_positioning_flag. If true, coding_area_top_left_CTU_address is present in the bitstream. Otherwise, the default implicit CA positioning is used.

[0086] According to an embodiment, the data encoder 110 may be configured to generate the indication data, such that the indication data may include information regarding the number of the plurality of coding regions or the number of the plurality of coding regions minus 1, or the number of the plurality of coding regions minus 2. A particular example may be, for example, the num_coding_areas_minus1 field mentioned above.

[0087] According to an embodiment, the data encoder 110 may be configured to generate the instruction data such that the instruction data indicates, for example, for one of the multiple coding regions that follows another one of the multiple coding regions, whether one of the multiple coding regions depends on another one of the multiple coding regions. A particular example may be, for example, dependent_coding_areas_enabled_flag, which, if true, may indicate, for example, that subsequent CAs in the bitstream are dependent on each other in the order in which they appear in the bitstream, and otherwise the CAs are treated as independent regions.

[0088] According to an embodiment, the data encoder 110 may be configured to generate the indication data, such that the indication data indicates whether exactly one slice of the plurality of slices is assigned to exactly one coding region of the plurality of coding regions. A specific example may be, for example, the coding_area_no_slices_flag mentioned above.

[0089] According to an embodiment, the data encoder 110 may be configured to generate the instruction data such that the instruction data indicates whether the instruction data includes information on how to scan within each of one or more coding tree units of a plurality of coding areas. A particular example may be, for example, the coding_area_CTU_scan_flag mentioned above.

[0090] According to an embodiment, the data encoder 110 may be configured to generate the instruction data, for example, such that the instruction data indicates how to scan within each of one or more coding tree units of a plurality of coding areas. A specific example may be, for example, coding_area_CTU_scan_type_idx, which maps to a scan type table. The scan type may be, for example, a raster scan, and / or, for example, a diagonal scan, etc.

[0091] In an embodiment, data encoder 110 may be configured to generate the indication data, for example, such that the indication data indicates, for each of a plurality of coding regions, whether the coding region includes a plurality of coding tree units.

[0092] According to an embodiment, data encoder 110 may be configured to generate the indication data, such that the indication data indicates, for one of the multiple coding areas, whether the coding tree unit scan is to start at the leftmost coding tree unit or whether the coding tree unit scan is to start at the rightmost coding tree unit. A specific example may be, for example, coding_area_CTU_scan_start_left_flag[i], as described above.

[0093] According to an embodiment, data encoder 110 may be configured to generate the indication data, such that for one of the multiple coding regions, the indication data indicates whether the coding tree unit scan starts from the top coding tree unit row of the coding region or whether the coding tree unit scan starts from the bottom coding tree unit row of the coding region. A particular example may be, for example, coding_area_CTU_scan_start_top_flag[i], as described above.

[0094] According to an embodiment, the data encoder 110 may be configured to generate the instruction data, for example, such that the instruction data indicates whether the coding tree unit scan is to start horizontally or the coding tree unit scan is to start vertically for one of the multiple coding areas. A specific example may be, for example, coding_area_CTU_scan_direction_flag[i], which may be present, for example, when the i-th CA includes at least two CTU rows and two CTU columns and indicates the starting scan direction of the CTU scan. If it is true than the scan direction of the i-th CA, it may start, for example, in the horizontal direction, otherwise the scan may be, for example, vertical scan.

[0095] Similarly, according to an embodiment, the data decoder 170 may be configured to decode the encoded image data using information for each coding region regarding, for example, whether the address of the top-left coding tree unit is specified, and the instruction data may, for example, include said information.

[0096] According to an embodiment, the data decoder 170 is configured to decode the encoded image data using information regarding, for example, the number of the multiple coding regions or the number of the multiple coding regions minus 1, or the number of the multiple coding regions minus 2, and the instruction data may, for example, include said information.

[0097] According to an embodiment, the data decoder 170 may be configured to decode the encoded image data using information indicating, for example, for one of the multiple coding regions that follows another of the multiple coding regions whether one of the multiple coding regions depends on another of the multiple coding regions, and the instruction data may, for example, include said information.

[0098] In an embodiment, data decoder 170 may be configured to decode encoded image data using information indicating, for example, whether exactly one slice of the plurality of slices is assigned to exactly one coding region of the plurality of coding regions, and the instruction data may, for example, include said information.

[0099] According to an embodiment, data decoder 170 may be configured to decode encoded image data using information regarding whether the instruction data includes, for example, information on how to scan within each of one or more coding tree units of a plurality of coding regions, and the instruction data may include, for example, said information.

[0100] In an embodiment, data decoder 170 may be configured to decode encoded image data using information regarding how to scan within each of one or more coding tree units of a plurality of coding regions, and the instruction data may include, for example, said information.

[0101] According to an embodiment, the data decoder 170 may be configured to decode the encoded image data using information indicating, for example, for each of a plurality of coding regions, whether the coding region includes a plurality of coding tree units, and the indication data may, for example, include said information.

[0102] In an embodiment, data decoder 170 may be configured to decode encoded image data using information indicating, for example, for one of a plurality of coding regions, whether a coding tree unit scan begins at a left-most coding tree unit or whether a coding tree unit scan begins at a right-most coding tree unit, and the instruction data may include, for example, said information.

[0103] In an embodiment, data decoder 170 may be configured to decode encoded image data using information indicating, for example, for one of a plurality of coding regions, whether the coding tree unit scan begins at the top coding tree unit row of the coding region or whether the coding tree unit scan begins at the bottom coding tree unit row of the coding region, and the instruction data may include, for example, said information.

[0104] In an embodiment, data decoder 170 may be configured to decode encoded image data using information indicating, for example, for one of a plurality of coding regions, whether a coding tree unit scan begins in a horizontal direction or whether a coding tree unit scan begins in a vertical direction, and the instruction data may include, for example, said information. The sub-subsection below, "Size and Arrangement of Coding Regions," describes the size and arrangement of coding regions.

[0105] It is important to indicate how the coding regions are arranged in the image. Depending on the application, various targets are pursued that may affect the desired flexibility in the division of the image, such as the size and position of the CA. The layout can also be signaled in a higher level section of the bitstream, in order to use a temporarily fixed CA layout or to adjust the layout depending on the content over time.

[0106] For example, in the example provided in subsection "Partitioning an Image Using Tiles" for 360° Video Streaming, the CA is typically constant across the entire CVS (Coding Video Sequence) and its size only needs to accommodate partitions generated from different resolutions of the same content, e.g., as shown in Figure 4. In such cases, the most appropriate place for CA placement signaling is in high-level syntactic structures (see, e.g., VPS, SPS, PPS in HEVC), as described later in subsubsection "Embodiment A" and subsubsubsection "Embodiment B".

[0107] However, in other examples, such as subsection "Partitioning an Image Using Tiles for Load Balancing" (e.g., video conferencing scenarios), dynamic partitioning per image may be desirable. Furthermore, it may be found that the initial configuration selected for the CA is not optimal, and therefore the partitioning may need to be changed within the image (during encoding). In such cases, where the placement of the CA is not known in advance, signaling at the VCL (video coding layer in the slice payload) takes precedence over high-level signaling (in parameter sets), as described in sub-subsection "Embodiment C". In the following sub-sub-section "Embodiment A" signalling of location and size per sample or unit is described. Explicit CA positioning using the CTU start address to select the corresponding region:

[0108] Table 2-2 [Table 3] FIG. 10 illustrates two coding regions, one of which consists of non-contiguous CTUs, including an image border CTU, according to an embodiment.

[0109] In principle, the above syntax num_coding_areas_minus2 could define all but one CA and have the last CA as the remainder not covered by the previous CA, however this would allow a CA not to contain consecutive CTUs as shown in Figure 10, which may complicate the encoding / decoding process somewhat.

[0110] Therefore, we should add constraints to prohibit such cases and require the syntax to satisfy some constraints. For example, if there are four CTUs (CTU a , CTU b , CTU c , CTU d ) is given, and CTU b _addr-CTUa _addr=CAWidthInNumCTUs_minus1 and CTU c _addr-CTU a If _addr=CAHeightInNumCTUs_minus1, all CTUs and only those with the next CTU_address will be added to the remaining CA CTUs. x _addr=CTU a _addr+j+k*(CAWidthInNumCTUs_minus1+1), where j=0, CAWidthInNumCTUs_minus1, and k=0, CAHeightInNumCTUs_minus1.

[0111] Alternatively, syntax elements could be added (such as "non_contiguous_remaining_coding_unit_enabled_flag") that could indicate / constrain CAs to meet such conditions. Thus, some profiles could mandate that flag not be enabled to avoid the added complexity of non-contiguous CAs.

[0112] According to an embodiment, the data encoder 110 may be configured to generate the instruction data such that the instruction data includes non-contiguous information indicating, for example, whether at least one of the plurality of coding regions surrounds another one of the plurality of coding regions, or whether none of the plurality of coding regions surrounds another one of the coding regions. Figure 10 is a specific example, in which two coding regions CA1, CA2 are shown. The outer coding region CA1 surrounds the inner coding region CA2.

[0113] In Figure 10, CA1 surrounds CA2. The non_contiguous_remaining_coding_unit_enabled_flag can be used to provide an indication of each.

[0114] Similarly, in an embodiment, data decoder 170 may be configured to decode the encoded image data using non-contiguous information indicating, for example, whether at least one of the multiple coding regions surrounds another one of the multiple coding regions or whether none of the multiple coding regions surrounds another one of the coding regions, and the instruction data includes said information.

[0115] The syntax in the table above allows flexible signaling with CAs that are not multiples of the maximum coding unit (e.g. 128x128). This is beneficial for some applications. However, signaling the CA using sample units can use a lot of bits. Alternatively, the signaling can be done in CTUs to save bits. The problem is that it is not possible to signal sizes that are not multiples of the CTU. The proposed syntax below allows to solve this problem using some additional information.

[0116] Table 2-3 [Table 4]

[0117] The proposed signaling indicates whether the last CTU row and column of the CA contains a CTU of the specified maximum size or if the last CTU is smaller. If this is smaller, the size of the last CTU row and column of the CA is indicated.

[0118] However, if the size of the CA is not a multiple of the maximum CTU size (i.e. the last CTU in a row or column is smaller), the CA may have a smaller CTU than other CAs, leading to an image with a different number of CTUs per row or column. Such misalignment may be undesirable, since the storage of variables used for prediction in an image is usually addressed with CTU addresses, and a different number of CTUs per row or column may make CTU addressing infeasible or too complicated. Therefore, whenever a CA ends before a complete CTU (or a CTU of the maximum size), we should add the constraint that it should be aligned in the dimension (horizontal and / or vertical) where other adjacent CAs do not constitute a complete CTU.

[0119] Implicit positioning, starting recursively from the leftmost position of the topmost CTU row not covered by the coding area. In other words, for example, if coding_area_explicit_positioning_flag is set to 0 as shown in Table 2-4, no start address of the CA is given, only width and height, and the decoder must derive the start address of the i-th CA by finding the smallest CTU address not already covered by the 1..(i-1)-th CA.

[0120] In an embodiment, the data encoder 110 may be configured to generate the indication data, such that for a coding area, the indication data indicates whether a start address indicating one of one or more coding tree units of said coding area is indicated or whether a start address indicating said one of one or more coding tree units of said coding area is not indicated. A particular example may be, for example, the coding_area_CTU_start_address mentioned above.

[0121] Similarly, according to an embodiment, data decoder 170 may be configured to decode encoded image data using, for example, an indication of whether for a coding region a start address indicating one of one or more coding tree units of said coding region is indicated or whether a start address indicating said one of one or more coding tree units of said coding region is not indicated. If a start address indicating said one of one or more coding tree units of said coding region is not indicated, data decoder 170 may be configured to determine a start address indicating said one of one or more coding tree units of said coding region, for example, depending on a coding region width, depending on a coding height of said coding region and depending on a coding region scan direction of said coding region.

[0122] The syntax of both tables above consists of coding_area_start_address[i], which in principle simplifies the operation of the parser, but is to some extent "redundant" information that can simply be derived from the signal size. Thus, both tables could be the same as presented, but without that syntax element, and the address is derived as "the leftmost position of the topmost CTU row not covered by the coding area".

[0123] For higher image resolutions, additional step sizes may be useful to scale the width and height of the CA partitions and the positional code, if available.

[0124] Table 2-4 [Table 5] The final location and size of the CA shall be derived as follows:

[0125] coding_area_width_in_CTU=coding_area_width_in_units*(coding_area_unit_scaling_factor_minus1+1)

[0126] coding_area_height_in_CTU=coding_area_height_in_units*(coding_area_unit_scaling_factor_minus1+1)

[0127] pic_width_in_units=(pic_width_in_CTU+coding_area_unit_scaling_factor_minus1) / (coding_area_unit_scaling_factor_minus1+1) coding_area_CTU_start_address=(coding_area_unit_scaling_factor_minus1+1)

[0128] *((coding_area_start_address_in_units%pic_width_in_units)+(coding_area_CTU_start_address_unit / pic_width_in_units)*picture_width_in_CTU))

[0129] Table 2-5 [Table 6]

[0130] coding_area_scaling_factor_minus1 The scaling factor used to scale the CA position and size parameters

[0131] coding_area_top_left_CTU_address_in_units[i] Address of the CTU in the top left border of the CA. The address is specified in units and must be scaled according to coding_area_scaling_factor_minus1+1 to get the CTU address.

[0132] The width of the CA in coding_area_width_in_units[i] units must be scaled according to coding_area_scaling_factor_minus1+1 to get the CA width in CTU.

[0133] The height of the CA in coding_area_height_in_units[i] units must be scaled according to coding_area_scaling_factor_minus1+1 to get the width of the CA in CTU. To summarize the above concepts:

[0134] In an embodiment, data encoder 110 may be configured to generate the indication data, such that, for one of the multiple coding regions, the indication data indicates a coding area width in coding tree units that specifies a number of horizontally arranged coding tree units in one of the coding regions. A particular example may be, for example, coding_area_width_in_CTU, as described above.

[0135] According to an embodiment, the data encoder 110 may be configured to generate the indication data, such that for one of the multiple coding areas, the indication data indicates a coding area height in coding tree units that specifies a number of vertically arranged coding tree units in one of the coding areas. A particular example may be, for example, the coding_area_height_in_CTU mentioned above.

[0136] In an embodiment, data encoder 110 may be configured to generate instruction data, for example, for a coding region of a plurality of coding regions, such that the instruction data indicates whether a last coding tree unit in the horizontal direction in the coding region is smaller than another coding tree unit of the coding region that precedes the coding tree unit in the horizontal direction.

[0137] In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in a horizontal direction, the last coding tree unit in a horizontal direction being one of the plurality of last coding tree units in a horizontal direction. If the last coding tree unit in a horizontal direction in the coding region is smaller than another coding tree unit of the coding region preceding the last coding tree unit in a horizontal direction, each of the plurality of last coding tree units in a horizontal direction may have, for example, the same width.

[0138] According to an embodiment, the data encoder 110 may be configured to generate the instruction data, for example, for a coding region of a plurality of coding regions, such that the instruction data indicates whether a last coding tree unit in the vertical direction in the coding region is smaller than another coding tree unit of the coding region that precedes the coding tree unit in the vertical direction.

[0139] In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in a vertical direction, and the last coding tree unit in a vertical direction is one of the plurality of last coding tree units in a vertical direction. If the last coding tree unit in a vertical direction in the coding region is smaller than another coding tree unit of the coding region preceding the last coding tree unit in a vertical direction, each of the plurality of last coding tree units in a vertical direction may have, for example, the same height.

[0140] Similarly, in an embodiment, data decoder 170 may be configured to decode image data encoded using information indicating a coding region width in coding tree units that specifies, for example, for one of a plurality of coding regions, the number of horizontally arranged coding tree units within one of the coding regions, and the instruction data may include, for example, said information.

[0141] According to an embodiment, the data decoder 170 may be configured to decode image data encoded using information indicating a coding region height in coding tree units that specifies, for example, for one of a plurality of coding regions, a number of coding tree units arranged vertically within one of the coding regions, and the instruction data may, for example, include said information.

[0142] In an embodiment, data decoder 170 may be configured to decode encoded image data using information indicating, for example, for a coding region of a plurality of coding regions, whether a last coding tree unit in the horizontal direction in the coding region is smaller than another coding tree unit of the coding region that precedes the coding tree unit in the horizontal direction, and the instruction data may, for example, include said information.

[0143] In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in a horizontal direction, the last coding tree unit in a horizontal direction being one of the plurality of last coding tree units in a horizontal direction. If the last coding tree unit in a horizontal direction in the coding region is smaller than another coding tree unit of the coding region preceding the last coding tree unit in a horizontal direction, each of the plurality of last coding tree units in a horizontal direction may have, for example, the same width.

[0144] According to an embodiment, data decoder 170 may be configured to decode encoded image data using information indicating, for example, for a coding region of a plurality of coding regions, whether a last coding tree unit in the vertical direction in the coding region is smaller than another coding tree unit of the coding region that precedes the coding tree unit in the vertical direction, and the instruction data may, for example, include said information.

[0145] In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in a vertical direction, and the last coding tree unit in a vertical direction is one of the plurality of last coding tree units in a vertical direction. If the last coding tree unit in a vertical direction in the coding region is smaller than another coding tree unit of the coding region preceding the last coding tree unit in a vertical direction, each of the plurality of last coding tree units in a vertical direction may have, for example, the same height. The following sub-sub-subsection "Embodiment B" describes hierarchical sub-division by partitioning. In particular, two variations of hierarchical CA division are provided.

[0146] The first method is to transmit coding region partition position values ​​hierarchically in scaled CTU units, where the partition granularity depends on the CTU size.

[0147] Table 2-6 [Table 7]

[0148] Table 2-7 [Table 8]

[0149] A second variation of the hierarchical CA partitioning is to transmit the coding domain partition position values ​​in generally uniform units. The dimensions of the units can be derived by scaling the already analyzed original image size by a certain factor, which is also signaled in the parameter set. Here, the granularity of the partitioning is variable and depends on the size of the units selected on the encoder side.

[0150] Table 2-8 [Table 9]

[0151] Table 2-9 [Table 10]

[0152] The final location and size of the CA shall be derived as follows: UnitWidth=pic_width_in_luma_samples / PicWidthInUnits; UnitHeight=pic_height_in_luma_samples / PicHeightInUnits; CodingAreaWidth[AreaIdx]=CodingAreaWidthInUnits[AreaIdx]*UnitWidth CodingAreaHeight[AreaIdx]=CodingAreaHeightInUnits[AreaIdx]*UnitHeight CodingAreaPosX[AreaIdx]=CodingAreaPosUnitX[AreaIdx]*UnitWidth CodingAreaPosY[AreaIdx]=CodingAreaPosUnitY[AreaIdx]*UnitHeight

[0153] coding_area_start_address[AreaIdx]=CodingAreaPosY[AreaIdx]*PicWidthInCtbsY+CodingAreaPosX[AreaIdx]

[0154] The advantage of hierarchical CA partitioning is that in some partitioning scenarios, this method may require fewer bits of signaling, and furthermore, it enforces some alignment between CAs or groups of CAs that share some boundaries, which may be beneficial for some implementations. Signaling can be constrained to be only possible in the RAP and inherited from there for subsequent images.

[0155] An additional flag in the bitstream indicating that the layout is retransmitted, otherwise a previous CA layout is used, which can be further selected by the bitstream transmission index from the set of previously transmitted CA layouts. To summarise the above:

[0156] According to an embodiment, the data encoder 110 can be configured to generate the instruction data such that, for example, the information of the multiple coding regions includes information on how to divide the image one or more times to obtain the multiple coding regions by dividing the image one or more times. In an embodiment, the data encoder 110 may be configured to generate the indication data, for example, such that the indication data indicates a number of coding region division locations.

[0157] According to an embodiment, the data encoder 110 may be configured to generate the instruction data such that the instruction data indicates a plurality of coding region division locations as an ordered sequence, for example.

[0158] In an embodiment, the data encoder 110 may be configured to generate the instruction data, for example, such that the instruction data indicates a plurality of coding region division positions as a plurality of coding region division position values, each of the plurality of coding region division position values ​​depending on the width of the image or depending on the height of the image.

[0159] According to an embodiment, the data encoder 110 may be configured to generate the instruction data such that, for example, the information of the multiple coding regions includes information on how to hierarchically divide the image one or more times to obtain the multiple coding regions by hierarchically dividing the image one or more times.

[0160] Similarly, according to an embodiment, the data decoder 170 may be configured to decode the encoded image data using information on how to divide the image one or more times to obtain multiple coding regions by dividing the image one or more times, and the instruction data may, for example, include said information.

[0161] In an embodiment, the data decoder 170 may be configured to decode image data that has been encoded using information indicating multiple coding region division locations, and the instruction data may include, for example, said information.

[0162] In an embodiment, the data decoder 170 may be configured to decode image data encoded using information indicating, for example, a plurality of coding region division locations as an ordered sequence, and the instruction data may include, for example, said information.

[0163] In an embodiment, the data decoder 170 is configured to decode image data encoded using information indicating, for example, a plurality of coding region division positions as a plurality of coding region division position values, each of the plurality of coding region division position values ​​depending on the width of the image or depending on the height of the image, and the instruction data may, for example, include said information.

[0164] According to an embodiment, the data decoder 170 may be configured to decode image data encoded using information regarding the multiple coding regions, and the instruction data may, for example, include information on how to hierarchically divide the image one or more times to obtain the multiple coding regions by hierarchically dividing the image one or more times.

[0165] Further examples are now presented, in which the data encoder 110 can be configured to generate the instruction data such that, for example, the information of the multiple coding regions includes information on how to divide the image one or more times to obtain the multiple coding regions by dividing the image one or more times.

[0166] In particular, further examples are presented in which the data encoder 110 can be configured to generate instruction data such that, for example, the information of the multiple coding regions includes information on how to hierarchically divide the image one or more times to obtain the multiple coding regions by hierarchically dividing the image one or more times.

[0167] The data decoder 170 can also be configured to decode the encoded image data using information on how to divide the image one or more times to obtain multiple coding regions by dividing the image one or more times, further examples being provided with respect to the instruction data including, for example, said information.

[0168] In particular, further examples are provided, such as how the data decoder 170 can be configured to decode image data encoded using information regarding multiple coding regions, and the instruction data may include, for example, information on how to hierarchically divide the image one or more times to obtain multiple coding regions by hierarchically dividing the image one or more times.

[0169] Further examples are also presented of how instruction data of an encoded video signal may indicate, for example, how to divide an image one or more times to obtain multiple coding regions by dividing the image one or more times.

[0170] In addition, in particular, further examples are presented of how to hierarchically divide an image one or more times to obtain multiple coding regions by hierarchically dividing the image one or more times. In some embodiments, the data encoder 110 and / or the data decoder 170 may, for example, In a first step, the image is divided horizontally and vertically to obtain a first division of the image; In a second step, the first division of the image is divided horizontally (only) to obtain a second division of the image. It can be configured as follows.

[0171] In Figure 27, in a first step, an image is hierarchically partitioned horizontally and vertically to obtain a first partition (e.g., tile partition) of the image (Figure 27, step 1), and in a second step, it is partitioned only horizontally to obtain a second partition (e.g., brick partition) of the image (Figure 27, step 2). In some other embodiments, the data encoder 110 and / or the data decoder 170 may, for example, In a first step, the image is divided horizontally and vertically to obtain a first division of the image; In a second step, the first division of the image is divided (only) vertically to obtain a second division of the image. It can be configured as follows.

[0172] In Figure 28, an image is hierarchically partitioned horizontally and vertically in a first step to obtain a first partition (e.g., tile partition) of the image (Figure 28, step 1), and in a second step only vertically to obtain a second partition (e.g., brick partition) of the image (Figure 28, step 2). In some further embodiments, the data encoder 110 and / or the data decoder 170 may, for example, In a first step, the image is divided horizontally (only) to obtain a first division of the image, In a second step, the first division of the image is divided (only) vertically to obtain a second division of the image. It can be configured as follows.

[0173] In Figure 29, in a first step, an image is hierarchically partitioned horizontally only to obtain a first partition (e.g., tile partition) of the image (Figure 29, step 1), and in a second step, it is partitioned vertically only to obtain a second partition (e.g., brick partition) of the image (Figure 29, step 2). In some still further embodiments, the data encoder 110 and / or the data decoder 170 may, for example, In a first step, the image is divided (only) vertically to obtain a first division of the image, In a second step, the first division of the image is divided horizontally (only) to obtain a second division of the image. It can be configured as follows.

[0174] In Figure 30, in a first step, an image is hierarchically partitioned only vertically to obtain a first partition (e.g., tile partition) of the image (Figure 30, step 1), and in a second step, it is partitioned only horizontally to obtain a second partition (e.g., brick partition) of the image (Figure 30, step 2).

[0175] In an embodiment, in the following code for the image parameter set RBSP syntax, the brick_split_flag[i] and num_brick_rows_minus1[i] parameters implement an exemplary method of how to hierarchically split an image one or more times to obtain multiple coding regions. An image can be divided into, for example, images, slices, tiles, bricks, and CTUs.

[0176] An image may be divided, for example, into one or more tile rows and one or more tile columns. A tile is a set of CTUs that covers a rectangular area of ​​the image. A tile is divided into one or more bricks, each of which consists of a number of rows of CTUs within the tile. A tile that is not divided into multiple bricks is also called a brick, although a brick that is a true subset of a tile is not called a tile. A slice contains the number of tiles of an image or the number of bricks of a tile.

[0177] Two modes of slicing are supported: raster scan slicing mode and rectangular slicing mode. In raster scan slicing mode, a slice contains a sequence of tiles in the tile raster scan of the image. In rectangular slicing mode, a slice contains multiple bricks of the image that collectively form a rectangular region of the image. The bricks in a rectangular slice are in the order of the brick raster scan of the slice.

[0178] Figure 26 shows an example of an image divided into tiles, bricks, and rectangular slices, in which the image is divided into 4 tiles (2 tile columns and 2 tile rows), 11 bricks (the top-left tile contains 1 brick, the top-right tile contains 5 bricks, the bottom-left tile contains 2 bricks, and the bottom-right tile contains 3 bricks), and 4 rectangular slices.

[0179] In the following, brick_split_flag[i] equal to 1 specifies that the i-th tile is split into two or more bricks. brick_split_flag[i] equal to 0 specifies that the i-th tile is not split into two or more bricks. If not present, the value of brick_split_flag[i] is inferred to be equal to 0.

[0180] Further, in the following, num_brick_rows_minus1[i]+1 specifies the number of bricks to divide the ith tile into if uniform_brick_spacing_flag[i] is equal to 0. If present, the value of num_brick_rows_minus1[i] shall range from 1 to RowHeight[i]-1. If brick_split_flag[i] is equal to 0, the value of num_brick_rows_minus1[i] is inferred to be equal to 0. Otherwise, if uniform_brick_spacing_flag[i] is equal to 1, the value of num_brick_rows_minus1[i] is inferred (e.g., as specified below for CTB raster scan, tile scan, and brick scan processes).

[0181] Thus, brick_split_flag[i] and num_brick_rows_minus1[i] implement an exemplary method of how to hierarchically split an image one or more times to obtain multiple coding regions. A tile may, for example, be split into two or more bricks, which may, for example, consist of several CTU columns. More specifically, the CTB raster scan, tile scan, and brick scan processes may be performed, for example, as follows.

[0182] The list colWidth[i], for i in the range 0 to num_tile_columns_minus1, is derived specifying the width of the i-th tile column in units of CTBs. If uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is inferred as follows: if(uniform_tile_spacing_flag){ remainingWidthInCtbsY=PicWidthInCtbsY i=0 while(remainingWidthInCtbsY>(tile_cols_width_minus1+1)){ colWidth[i++]=tile_cols_width_minus1+1 remainingWidthInCtbsY-=(tile_cols_width_minus1+1) } colWidth[i]=remainingWidthInCtbsY num_tile_columns_minus1=i }else{ colWidth[num_tile_columns_minus1]=PicWidthInCtbsY(6-1) for(i=0;i <num_tile_columns_minus1;i++){ colWidth[i]=tile_column_width_minus1[i]+1 colWidth[num_tile_columns_minus1]-=colWidth[i] } }

[0183] A list of j, RowHeight[j], ranging from 0 to num_tile_rows_minus1, is derived specifying the height of the jth tile row in units of CTBs. If uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is inferred as follows: if(uniform_tile_spacing_flag){ remainingHeightInCtbsY=PicHeightInCtbsY i=0 while(remainingHeightInCtbsY>(tile_rows_height_minus1+1)){ RowHeight[i++]=tile_rows_height_minus1+1 remainingHeightInCtbsY-=(tile_rows_height_minus1+1) } RowHeight[i]=remainingHeightInCtbsY num_tile_rows_minus1=i }else{ RowHeight[num_tile_rows_minus1]=PicHeightInCtbsY(6-2) for(j=0;j <num_tile_rows_minus1;j++){ RowHeight[j]=tile_row_height_minus1[j]+1 RowHeight[num_tile_rows_minus1]-=RowHeight[j] } }

[0184] The list tileColBd[i], for i in the range 0 to num_tile_columns_minus1+1, specifies the position of the i-th tile column boundary in units of CTBs and is derived as follows: for(tileColBd[0]=0,i=0;i<=num_tile_columns_minus1;i++) tileColBd[i+1]=tileColBd[i]+colWidth[i](6-3)

[0185] The list tileRowBd[j], for j in the range 0 to num_tile_rows_minus1+1, specifying the j-th tile row boundary positions in units of CTBs, is derived as follows: for(tileRowBd[0]=0,j=0;j<=num_tile_rows_minus1;j++) tileRowBd[j+1]=tileRowBd[j]+RowHeight[j](6-4)

[0186] The variable NumBricksInPic specifies the number of bricks in the image referring to the PPS, the lists of brickIdx BrickColBd[brickIdx], BrickRowBd[brickIdx], BrickWidth[brickIdx], and BrickHeight[brickIdx] in the range 0 to NumBricksInPic-1 are derived given the vertical brick border position in units of CTBs, the horizontal brick border position in units of CTBs, the brick width in units of CTBs, and the brick height in units of CTBs, and for each i in the range 0 to NumTilesInPic-1, if uniform_brick_spacing_flag[i] is equal to 1, the value of num_brick_rows_minus1[i] is inferred as follows:

[0187] for(brickIdx=0,i=0;i <NumTilesInPic;i++){ tileX=i%(num_tile_columns_minus1+1) tileY=i / (num_tile_columns_minus1+1) if(!brick_split_flag[i]) { BrickColBd[brickIdx]=tileColBd[tileX] BrickRowBd[brickIdx]=tileRowBd[tileY] BrickWidth[brickIdx]=colWidth[tileX] BrickHeight[brickIdx]=RowHeight[tileY](6-5) brickIdx++ }else{ if(uniform_brick_spacing_flag[i]){ remainingHeightInCtbsY=RowHeight[tileY] j=0 while(remainingHeightInCtbsY>(brick_height_minus1[i]+1)){ rowHeight2[j++]=brick_height_minus1[i]+1 remainingHeightInCtbsY-=(brick_height_minus1[i]+1) } rowHeight2[j]=remainingHeightInCtbsY num_brick_rows_minus1[i]=j }else{ rowHeight2[num_brick_rows_minus1[i]]=RowHeight[tileY] for(j=0;j<num_brick_rows_minus1[i];j++){ rowHeight2[j]=brick_row_height_minus1[i][j]+1 rowHeight2[num_brick_rows_minus1[i]]-=rowHeight2[j] } } for(rowBd2[0]=0,j=0;j<=num_brick_rows_minus1[i];j++) rowBd2[j+1]=rowBd2[j]+rowHeight2[j] for(j=0;j<num_brick_rows_minus1[i]+1;j++){ BrickColBd[brickIdx]=tileColBd[tileX] BrickRowBd[brickIdx]=tileRowBd[tileY]+rowBd2[j] BrickWidth[brickIdx]=colWidth[tileX] BrickHeight[brickIdx]=rowHeight2[j] brickIdx++ } } } NumBricksInPic=brickIdx

[0188] The list of ctbAddrRs, CtbAddrRsToBs[ctbAddrRs], in the range 0 to PicSizeInCtbsY-1, specifies the conversion from the CTB addresses of the image's CTB raster scan to the CTB addresses of the brick scan, and is derived as follows: for(ctbAddrRs=0;ctbAddrRs <PicSizeInCtbsY;ctbAddrRs++){ tbX=ctbAddrRs%PicWidthInCtbsY tbY=ctbAddrRs / PicWidthInCtbsY brickFound=FALSE for(bkIdx=NumBricksInPic-1,i=0;i <NumBricksInPic-1&&!brickFound;i++){ brickFound=tbX<(BrickColBd[i]+BrickWidth[i])&& tbY<(BrickRowBd[i]+BrickHeight[i]) if(brickFound)(6-6) bkIdx=i } CtbAddrRsToBs[ctbAddrRs]=0 for(i=0;i <bkIdx;i++) CtbAddrRsToBs[ctbAddrRs]+=BrickHeight[i]*BrickWidth[i] CtbAddrRsToBs[ctbAddrRs]+= (tbY-BrickRowBd[bkIdx])*BrickWidth[bkIdx]+tbX-BrickColBd[bkIdx] }

[0189] The list of ctbAddrBs, CtbAddrBsToRs[ctbAddrBs], in the range 0 to PicSizeInCtbsY-1, specifies the conversion from brick scan CTB addresses to image CTB raster scan CTB addresses, and is derived as follows: for(ctbAddrRs=0;ctbAddrRs <PicSizeInCtbsY;ctbAddrRs++)(6-7) CtbAddrBsToRs[CtbAddrRsToBs[ctbAddrRs]]=ctbAddrRs

[0190] The list of ctbAddrBs, BrickId[ctbAddrBs], in the range 0 to PicSizeInCtbsY-1, specifies the conversion from CTB addresses to brick IDs for the brick scan and is derived as follows: for(i=0,i <NumBricksInPic;i++) for(y = BrickRowBd[i];y <BrickRowBd[i]+BrickHeight[i];y++)(6-8) for(x = BrickColBd[i];x <BrickColBd[i]+BrickWidth[i];x++) BrickId[CtbAddrRsToBs[y*PicWidthInCtbsY+x]]=i

[0191] The list NumCtusInBrick[brickIdx] of brickIdx in the range 0 to NumBricksInPic-1 specifies the conversion from brick index to the number of CTUs in a brick, and is derived as follows: for(i=0;i <NumBricksInPic;i++)(6-9) NumCtusInBrick[i]=BrickWidth[i]*BrickHeight[i]

[0192] The list of brickIdx, FirstCtbAddrBs[brickIdx], in the range 0 to NumBricksInPic-1, specifies the conversion from brick ID to CTB address in the brick scan of the first CTB of a brick, and is derived as follows:

[0193] for(ctbAddrBs=0,brickIdx=0,brickStartFlag=1;ctbAddrBs <PicSizeInCtbsY;ctbAddrBs++){ if(brickStartFlag) { FirstCtbAddrBs[brickIdx]=ctbAddrBs(6-10) brickStartFlag=0 } brickEndFlag=(ctbAddrBs==PicSizeInCtbsY-1)|| (BrickId[ctbAddrBs+1]!=BrickId[ctbAddrBs]) if(brickEndFlag) { brickIdx++ brickStartFlag=1 } } Image Parameter Set RBSP Syntax

[0194] [Table 11] TIFF2025011204000013.tif229166TIFF2025011204000014.tif67166In the above code, the image parameter set RBSP semantics can be defined, for example, as follows:

[0195] The pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id shall be in the range of 0 to 63.

[0196] pps_seq_parameter_set_id specifies the value of sps_seq_parameter_set_id of the active SPS. The value of pps_seq_parameter_set_id shall be in the range of 0 to 15.

[0197] output_flag_present_flag is set to 1 to indicate that the pic_output_flag syntax element is present in the slice header that references the PPS. output_flag_present_flag is set to 0 to indicate that the pic_output_flag syntax element is not present in the slice header that references the PPS.

[0198] single_tile_in_pic_flag equal to 1 specifies that there is only one tile in each image that references the PPS. single_tile_in_pic_flag equal to 0 specifies that there are multiple tiles in each image that references the PPS.

[0199] Note - If there is no further division of bricks within a tile, then the whole tile is called a brick. If an image contains only one tile without any further division of bricks, then it is called a single brick. The value of single_tile_in_pic_flag shall be the same for all PPSs activated within a CVS.

[0200] uniform_tile_spacing_flag, when 1, specifies that the tile row borders are uniformly distributed across the image, similar to the tile column borders, and are signaled using the syntax elements tile_cols_width_minus1 and tile_rows_height_minus1. uniform_tile_spacing_flag, when 0, specifies that the tile row borders may or may not be uniformly distributed across the image, similar to the tile column borders, and may or may not be signaled using the syntax elements num_tile_columns_minus1 and num_tile_rows_minus1, and the list of syntax element pairs tile_column_width_minus1[i] and tile_row_height_minus1[i]. If not present, the value of uniform_tile_spacing_flag is inferred to be equal to 1.

[0201] tile_cols_width_minus1+1 specifies the width, in CTB units, of tile columns excluding the rightmost tile column of the image, when uniform_tile_spacing_flag is equal to 1. The value of tile_cols_width_minus1 shall range from 0 to PicWidthInCtbsY-1. If not present, the value of tile_cols_width_minus1 is inferred to be equal to PicWidthInCtbsY-1.

[0202] tile_rows_height_minus1+1 specifies the height of the tile rows, excluding the bottom tile row of the image, in units of CTBs, when uniform_tile_spacing_flag is equal to 1. The value of tile_rows_height_minus1 shall range from 0 to PicHeightInCtbsY-1. If not present, the value of tile_rows_height_minus1 is inferred to be equal to PicHeightInCtbsY-1.

[0203] num_tile_columns_minus1+1 specifies the number of tile columns to divide the image into if uniform_tile_spacing_flag is equal to 0. The value of num_tile_columns_minus1 shall range from 0 to PicWidthInCtbsY-1. If single_tile_in_pic_flag is equal to 1, the value of num_tile_columns_minus1 is inferred to be equal to 0. Otherwise, if uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is inferred (e.g., as specified above for CTB raster scan, tile scan, and brick scan processes).

[0204] num_tile_rows_minus1+1 specifies the number of tile rows to divide the image into if uniform_tile_spacing_flag is equal to 0. The value of num_tile_rows_minus1 shall range from 0 to PicHeightInCtbsY-1. If single_tile_in_pic_flag is equal to 1, the value of num_tile_rows_minus1 is inferred to be equal to 0. Otherwise, if uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is inferred (e.g., as specified below for CTB raster scan, tile scan, and brick scan processes).

[0205] The variable NumTilesInPic is set equal to (num_tile_columns_minus1+1)*(num_tile_rows_minus1+1). If single_tile_in_pic_flag is equal to 0, then NumTilesInPic shall be greater than 1. tile_column_width_minus1[i]+1 specifies the width of the i-th tile column in CTB units. tile_row_height_minus1[i]+1 specifies the height of the i-th tile row in CTB units.

[0206] When brick_splitting_present_flag is equal to 1, it specifies that one or more tiles of the image referencing the PPS may be split into two or more bricks. When brick_splitting_present_flag is equal to 0, it specifies that the tiles of the image referencing the PPS may not be split into two or more bricks.

[0207] When brick_split_flag[i] is equal to 1, it specifies that the i-th tile is split into two or more bricks. When brick_split_flag[i] is equal to 0, it specifies that the i-th tile is not split into two or more bricks. If not present, the value of brick_split_flag[i] is inferred to be equal to 0.

[0208] uniform_brick_spacing_flag[i] equal to 1 specifies that horizontal brick borders are uniformly distributed across the ith tile and are signaled using the syntax element brick_height_minus1[i]. uniform_brick_spacing_flag[i] equal to 0 specifies that horizontal brick borders may or may not be uniformly distributed across the ith tile and may or may not be signaled using the syntax element num_brick_rows_minus1[i] and the list of syntax elements brick_row_height_minus1[i][j]. If not present, the value of uniform_brick_spacing_flag[i] equal to 1 is inferred.

[0209] brick_height_minus1[i]+1 specifies the height of the brick row excluding the bottom brick of the ith tile in units of CTBs when uniform_brick_spacing_flag[i] is equal to 1. If present, the value of brick_height_minus1 shall range from 0 to RowHeight[i]-2 inclusive. If not present, the value of brick_height_minus1[i] is inferred to be equal to RowHeight[i]-1.

[0210] num_brick_rows_minus1[i]+1 specifies the number of bricks to divide the ith tile into if uniform_brick_spacing_flag[i] is equal to 0. If present, the value of num_brick_rows_minus1[i] shall range from 1 to RowHeight[i]-1. If brick_split_flag[i] is equal to 0, the value of num_brick_rows_minus1[i] is inferred to be equal to 0. Otherwise, if uniform_brick_spacing_flag[i] is equal to 1, the value of num_brick_rows_minus1[i] is inferred (e.g., as specified above for CTB raster scan, tile scan, and brick scan processes).

[0211] brick_row_height_minus1[i][j]+1 specifies the height of the jth brick in the ith tile in units of CTBs when uniform_tile_spacing_flag is equal to 0.

[0212] The following variables are derived: if uniform_tile_spacing_flag is equal to 1, the values ​​of num_tile_columns_minus1 and num_tile_rows_minus1 are inferred, and for each i in the range 0 to NumTilesInPic-1, if uniform_brick_spacing_flag[i] is equal to 1, the value of num_brick_rows_minus1[i] is inferred by invoking the CTB raster and brick scan conversion processes (e.g., as specified above for the CTB raster scan, tile scan, and brick scan processes).

[0213] A list of j, RowHeight[j], in the range -0 to num_tile_rows_minus1, specifying the height of the j-th tile row in CTB units.

[0214] CtbAddrRsToBs[ctbAddrRs], a list of CtbAddrRs ranging from -0 to PicSizeInCtbsY-1, specifying the conversion from CTB raster scan CTB addresses to brick scan CTB addresses for the image.

[0215] CtbAddrBsToRs[ctbAddrBs], a list of ctbAddrBs in the range -0 to PicSizeInCtbsY-1, specifying the conversion from brick scan CTB addresses to image raster scan CTB addresses.

[0216] BrickId[ctbAddrBs] is a list of ctbAddrBs ranging from -0 to PicSizeInCtbsY-1, specifying the conversion from CTB addresses to brick IDs for a brick scan.

[0217] NumCtusInBrick[brickIdx], a list of brickIdx ranging from -0 to NumBricksInPic-1, specifying the conversion from brick index to number of CTUs in a brick.

[0218] FirstCtbAddrBs[brickIdx], a list of brickIdx in the range -0 to NumBricksInPic-1, specifying the brick ID to CTB address conversion in a brick scan of the first CTB in a brick.

[0219] If single_brick_per_slice_flag is 1, it specifies that each slice that references this PPS contains one brick. If single_brick_per_slice_flag is 0, it specifies that slices that reference this PPS may contain multiple bricks. If not present, the value of single_brick_per_slice_flag is inferred to be equal to 1.

[0220] rect_slice_flag equal to 0 specifies that the bricks in each slice are in raster scan order and slice information is not signaled in the PPS. rect_slice_flag equal to 1 specifies that the bricks in each slice cover a rectangular region of the image and slice information is signaled in the PPS. If not present, rect_slice_flag is inferred to be equal to 1.

[0221] num_slices_in_pic_minus1+1 specifies the number of slices in each picture that references the PPS. The value of num_slices_in_pic_minus1 shall range from 0 to NumBricksInPic-1. If not present and single_brick_per_slice_flag is equal to 1, the value of num_slices_in_pic_minus1 is inferred to be equal to NumBricksInPic-1.

[0222] top_left_brick_idx[i] specifies the brick index of the brick in the top-left corner of the ith slice. The value of top_left_brick_idx[i] shall be equal to the value of top_left_brick_idx[j] for some i not equal to j. If not present, the value of top_left_brick_idx[i] is inferred to be equal to i. The length of the top_left_brick_idx[i] syntax element is Ceil(Log2(NumBricksInPic) bits.

[0223] bottom_right_brick_idx_delta[i] specifies the difference between the brick index of the brick in the bottom-right corner of the ith slice and top_left_brick_idx[i]. If single_brick_per_slice_flag is equal to 1, the value of bottom_right_brick_idx_delta[i] is inferred to be equal to 0. The length of the bottom_right_brick_idx_delta[i] syntax element is Ceil(Log2(NumBricksInPic-top_left_brick_idx[i])) bits. A slice contains only a contiguous sequence of some complete tiles, or complete bricks of one tile.

[0224] The variables NumBricksInSlice[i] and BricksToSliceMap[j], which specify the number of bricks in the i-th slice and the mapping of bricks to slices, are derived as follows: NumBricksInSlice[i]=0 botRightBkIdx=top_left_brick_idx[i]+bottom_right_brick_idx_delta[i] for(j=0;j <NumBricksInPic;j++){ if(BrickColBd[j]>=BrickColBd[top_left_brick_idx[i]]&& BrickColBd[j]<=BrickColBd[botRightBkIdx]&& BrickRowBd[j]>=BrickRowBd[top_left_brick_idx[i]]&&(7-35) BrickRowBd[j]<=BrickRowBd[botRightBkIdx]){ NumBricksInSlice[i]++ BricksToSliceMap[j]=i } }

[0225] loop_filter_across_bricks_enabled_flag, when 1, specifies that in-loop filtering operations can be performed across brick boundaries of the image that references the PPS. When loop_filter_across_bricks_enabled_flag is 0, it specifies that in-loop filtering operations are not performed across brick boundaries of the image that references the PPS. In-loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filter operations. If not present, the value of loop_filter_across_bricks_enabled_flag is inferred to be equal to 1.

[0226] loop_filter_across_slices_enabled_flag, when 1, specifies that in-loop filtering operations can be performed across slice boundaries of the image that references the PPS. When loop_filter_across_slice_enabled_flag is 0, it specifies that in-loop filtering operations are not performed across slice boundaries of the image that references the PPS. In-loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filter operations. If not present, the value of loop_filter_across_slices_enabled_flag is inferred to be equal to 0.

[0227] signalled_slice_id_flag specifies that the slice ID of each slice is signaled when it is equal to 1. It specifies that the slice ID is not signaled when signalled_slice_id_flag is equal to 0. When rect_slice_flag is equal to 0, the value of signalled_slice_id_flag is inferred to be equal to 0.

[0228] signalled_slice_id_length_minus1+1 specifies the number of bits used to represent the syntax element slice_id[i], if present, and the syntax element slice_address in the slice header. The value of signalled_slice_id_length_minus1 shall be in the range from 0 to 15. If not present, the value of signalled_slice_id_length_minus1 is inferred to be equal to Ceil(Log2(num_slices_in_pic_minus1+1))-1.

[0229] slice_id[i] specifies the slice ID of the i-th slice. The length of the slice_id[i] syntax element is signalled_slice_id_length_minus1+1 bits. If not present, the value of slice_id[i] is inferred to be equal to i for each i in the range from 0 to num_slices_in_pic_minus1.

[0230] When entropy_coding_sync_enabled_flag is equal to 1, it specifies that a specific synchronization process of the context variables is invoked before decoding a CTU that contains the first CTB in a CTB row of each brick of each image that references a PPS, and a specific storage process of the context variables is invoked after decoding a CTU that contains the first CTB in a CTB row of each brick of each image that references a PPS. When entropy_coding_sync_enabled_flag is equal to 0, it specifies that a specific synchronization process of the context variables does not need to be invoked before decoding a CTU that contains the first CTB in a CTB row of each brick of each image that references a PPS, and that a specific storage process of the context variables may need to be invoked after decoding a CTU that contains the first CTB in a CTB row of each brick of each image that references a PPS, for example. The value of entropy_coding_sync_enabled_flag shall be the same for all PPSs activated within a CVS.

[0231] When cabac_init_present_flag is equal to 1, it specifies that cabac_init_flag is present in the slice header that references the PPS. When cabac_init_present_flag is equal to 0, it specifies that cabac_init_flag is not present in the slice header that references the PPS.

[0232] num_ref_idx_default_active_minus1[i]+1 specifies the estimate of the variable NumRefIdxActive[0] for P or B slices with num_ref_idx_active_override_flag equal to 0, if i is equal to 0, and specifies the estimate of NumRefIdxActive[1] for B slices with num_ref_idx_active_override_flag equal to 0, if i is equal to 1. The value of num_ref_idx_default_active_minus1[i] shall range from 0 to 14, inclusive.

[0233] When rpl1_idx_present_flag is equal to 0, it specifies that ref_pic_list_sps_flag[1] and ref_pic_list_idx[1] are not present in the slice header. When rpl1_idx_present_flag is equal to 1, it specifies that ref_pic_list_sps_flag[1] and ref_pic_list_idx[1] may be present in the slice header.

[0234] init_qp_minus26+26 is the SliceQp of each slice that references the PPS. Y Specifies the initial value of SliceQp. Y The initial value of is changed in the slice layer when a non-zero value of slice_qp_delta is decoded. The value of init_qp_minus26 is -(26+QpBdOffset Y ) to +37.

[0235] When transform_skip_enabled_flag is equal to 1, it specifies that transform_skip_flag may be present in the syntax of the transform unit. When transform_skip_enabled_flag is equal to 0, it specifies that transform_skip_flag is not present in the syntax of the transform unit.

[0236] log2_transform_skip_max_size_minus2 specifies the maximum block size used for transform skipping and shall range from 0 to 3. If not present, the value of log2_transform_skip_max_size_minus2 is inferred to be equal to 0. The variable MaxTsSize is set equal to 1 << (log2_transform_skip_max_size_minus2 + 2).

[0237] When cu_qp_delta_enabled_flag is equal to 1, it specifies that the cu_qp_delta_subdiv syntax element may be present in the PPS and cu_qp_delta_abs may be present in the translation unit syntax. When cu_qp_delta_enabled_flag is equal to 0, it specifies that the cu_qp_delta_subdiv syntax element is not present in the PPS and cu_qp_delta_abs is not present in the translation unit syntax.

[0238] cu_qp_delta_subdiv specifies the maximum cbSubdiv value for coding units that carry cu_qp_delta_abs and cu_qp_delta_sign_flag. The range of values ​​for cu_qp_delta_subdiv is specified as follows:

[0239] -When slice_type is equal to I, the value of cu_qp_delta_subdiv shall be in the range from 0 to 2*(log2_ctu_size_minus2-log2_min_qt_size_intra_slice_minus2+MaxMttDepthY).

[0240] - Otherwise (if slice_type is not equal to I), the value of cu_qp_delta_subdiv shall be in the range from 0 to 2*(log2_ctu_size_minus2-log2_min_qt_size_inter_slice_minus2+MaxMttDepthY). If not present, the value of cu_qp_delta_subdiv is inferred to be equal to 0.

[0241] [EDIT (BB): The problem here is that MaxMttDepthY is derived at the slice level. If partition_constraints_override_enabled_flag is equal to 1, then we need to parse the slice header to know the value of MaxMttDepthY.]

[0242] pps_cb_qp_offset and pps_cr_qp_offset are the offsets of Qp' Cb and Qp' Cr The luminance quantization parameter Qp' used to derive Y The values ​​of pps_cb_qp_offset and pps_cr_qp_offset shall be in the range of -12 to +12. If ChromaArrayType is equal to 0, pps_cb_qp_offset and pps_cr_qp_offset are not used in the decoding process and the decoder shall ignore their values.

[0243] pps_slice_chroma_qp_offsets_present_flag equal to 1 indicates that the slice_cb_qp_offset and slice_cr_qp_offset syntax elements are present in the associated slice header. pps_slice_chroma_qp_offsets_present_flag equal to 0 indicates that these syntax elements are not present in the associated slice header. If ChromaArrayType is equal to 0, pps_slice_chroma_qp_offsets_present_flag shall be equal to 0.

[0244] When weighted_pred_flag is equal to 0, it specifies that weighted prediction is not applied to the P slice. When weighted_pred_flag is equal to 1, it specifies that weighted prediction is applied to the P slice.

[0245] When weighted_bipred_flag is equal to 0, it specifies that default weighted prediction is applied to B slices. When weighted_bipred_flag is equal to 1, it specifies that weighted prediction is applied to B slices.

[0246] When deblocking_filter_control_present_flag is equal to 1, it specifies the presence of a deblocking filter control syntax element in the PPS. When deblocking_filter_control_present_flag is equal to 0, it specifies the absence of a deblocking filter control syntax element in the PPS.

[0247] If deblocking_filter_override_enabled_flag is equal to 1, it specifies that the deblocking_filter_override_flag is present in the slice header of the image that references the PPS. If deblocking_filter_override_enabled_flag is equal to 0, it specifies that the deblocking_filter_override_flag is not present in the slice header of the image that references the PPS. If not present, the value of deblocking_filter_override_enabled_flag is inferred to be equal to 0.

[0248] If pps_deblocking_filter_disabled_flag is 1, it specifies that the deblocking filter operation is not applied to slices that reference a PPS for which slice_deblocking_filter_disabled_flag is not present. If pps_deblocking_filter_disabled_flag is 0, it specifies that the deblocking filter operation is applied to slices that reference a PPS for which slice_deblocking_filter_disabled_flag is not present. If not present, the value of pps_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0249] pps_beta_offset_div2 and pps_tc_offset_div2 specify the default deblocking parameter offsets (divided by 2) for β and tC that shall be applied to slices that reference a PPS, if the default deblocking parameter offset is not overridden by a deblocking parameter offset present in the slice header of the slice that references the PPS. The values ​​of pps_beta_offset_div2 and pps_tc_offset_div2 shall both be in the range of -6 to 6. If not present, the values ​​of pps_beta_offset_div2 and pps_tc_offset_div2 are inferred to be equal to 0.

[0250] pps_loop_filter_across_virtual_boundaries_disabled_flag, when equal to 1, specifies that in-loop filtering operations are disabled across virtual boundaries of pictures that reference the PPS. pps_loop_filter_across_virtual_boundaries_disabled_flag, when equal to 0, specifies that such disabling of in-loop filtering operations does not apply to pictures that reference the PPS. In-loop filtering operations include deblocking filters, sample adapted offset filters, and adapted loop filter operations. If not present, the value of pps_loop_filter_across_virtual_boundaries_disabled_flag is inferred to be equal to 0.

[0251] pps_num_ver_virtual_boundaries specifies the number of syntax elements of pps_virtual_boundaries_pos_x[i] that are present in the PPS. If pps_num_ver_virtual_boundaries is not present, it is inferred to be equal to 0.

[0252] pps_virtual_boundaries_pos_x[i] is used to calculate the value of PpsVirtualBoundariesPosX[i], which specifies the position of the i-th vertical virtual boundary in units of luma samples. The number of bits used to represent pps_virtual_boundaries_pos_x[i] is Ceil(Log2(pic_width_in_luma_samples)-3). pps_virtual_boundaries_pos_x[i] shall range from 1 to Ceil(pic_width_in_luma_samples÷8)-1. The position of the vertical virtual boundary PpsVirtualBoundariesPosX[i] is derived as follows: PpsVirtualBoundariesPosX[i]=pps_virtual_boundaries_pos_x[i]*8(7-36) The distance between any two vertical virtual borders shall be at least CtbSizeY luma samples.

[0253] pps_num_hor_virtual_boundaries specifies the number of pps_virtual_boundaries_pos_y[i] syntax elements that are present in the PPS. If pps_num_hor_virtual_boundaries is not present, it is inferred to be equal to 0.

[0254] pps_virtual_boundaries_pos_y[i] is used to calculate the value of PpsVirtualBoundariesPosY[i], which specifies the position of the i-th horizontal virtual boundary in units of luma samples. The number of bits used to represent pps_virtual_boundaries_pos_y[i] is Ceil(Log2(pic_height_in_luma_samples)-3). pps_virtual_boundaries_pos_y[i] shall range from 1 to Ceil(pic_height_in_luma_samples÷8)-1. The position of the horizontal virtual boundary PpsVirtualBoundariesPosY[i] is derived as follows: PpsVirtualBoundariesPosY[i]=pps_virtual_boundaries_pos_y[i]*8(7-37) The distance between any two horizontal virtual borders shall be at least CtbSizeY luma samples.

[0255] When pps_extension_flag is equal to 0, it specifies that the pps_extension_data_flag syntax element is not present in the PPS RBSP syntax structure. When pps_extension_flag is equal to 1, it specifies that the pps_extension_data_flag syntax element is present in the PPS RBSP syntax structure.

[0256] pps_extension_data_flag MAY have any value. Its presence and value do not affect a decoder's conformance to the profile specified in this version of this specification. Decoders conforming to this version of this specification SHALL ignore all pps_extension_data_flag syntax elements. The following sub-sub-section "Embodiment C" describes signaling in a low-level syntax. As already mentioned, another option to express the layout of the CA is to use the VCL syntax in a more flexible way.

[0257] The layout of the coding area is determined by the evaluation of two new syntax elements area_line_stop_flag and area_column_stop_flag, while end_of_slice_flag may not be used.

[0258] The area_line_stop_flag is present in the bitstream at the end of the CTU coding process. It may happen that the next CTU in the diagonal scan order is located in a CTU line for which the previous area_line_stop_flag was not transmitted in the bitstream for the current slice and which is at least partially inside the image. If area_line_stop_flag is false, the current slice rectangle is extended by a new CTU row by the number of currently used CTU columns. If area_line_stop_flag is true, the slice height is fixed to the number of currently used CTU rows in the current slice.

[0259] Similarly, area_column_stop_flag is present in the bitstream at the end of the CTU coding process if the next CTU in the diagonal scan order is in a new CTU column for which no previous area_column_stop_flag was transmitted in the bitstream for the current slice and which is at least partially within the image. If area_column_stop_flag is false, the slice rectangle is extended by a new CTU column that contains the number of CTU rows currently used. If area_column_stop_flag is true, the slice width is fixed to the number of CTU columns currently used in the current slice. FIG. 11 shows signaling of coding regions at subarea (CTU) level according to an embodiment.

[0260] Once the slice rectangle is determined, the CTUs are processed in a specific scan order until all CTUs covered by the slice rectangle are processed. The span coding regions adjacent to the image borders are restricted not to exceed them due to the lack of explicit area_line_stop_flag and area_column_stop_flag respectively at the image borders. This can be seen in Figure 11, where area_line_stop_flag=1 and area_column_stop_flag=1 are not present near the image borders.

[0261] Implicit derivation of area_line_stop_flag=1 and area_column_stop_flag=1 using prior knowledge of CA size and position and image boundaries would save signaling overhead, but would prevent some bitstream manipulation, e.g., "coding region bitstream extraction" or "coding region bitstream aggregation", or in these cases would at least incur the overhead of additional processing of entropy coded data. Currently, for HEVC, Motion Constrained Tile Sets (MCTS) are defined that allow for both processes without further processing of entropy coded data. However, such a process may result in either an MCTS (respective CA) boundary becoming an image boundary, or an image boundary becoming an MCTS boundary (respective CA) and not an image boundary. Thus, the implicit derivation area_line_stop_flag=1 and area_column_stop_flag=1 should not allow enabling such features by requiring the presence of both syntax elements at all times, regardless of whether it is an image boundary or not, and whether other CAs have already been described. This can be done, for example, by the presence of a syntax element in the parameter set called "implicit_area_line_or_column_enabled_flag" or by making it dependent on the presence of an MCTS or "motion constraint coding region".

[0262] To summarise the above, according to an embodiment, the data encoder 110 may be configured to generate the indication data, for example, such that the information of the multiple coding regions includes one or more region sequence stop flags for a coding region of one or more coding regions, where if a region sequence stop flag of a coding region of one or more coding regions is set to a stop value, the region sequence stop flag may, for example, indicate a width of the coding region. Or, the data encoder 110 may be configured to generate the indication data, for example, such that the information of the multiple coding regions includes one or more region line stop flags for a coding region of one or more coding regions, where if a region line stop flag of a coding region of one or more coding regions is set to a stop value, the region line stop flag may, for example, indicate a height of the coding region.

[0263] According to an embodiment, the data encoder 110 may be configured to generate the indication data, for example, such that the indication data indicates whether an explicit signaling mode is active or whether the explicit signaling mode is inactive. If the explicit signaling mode is active and a coding tree unit of one or more coding tree units of a coding region is located at an image boundary of an image, the data encoder 110 may be configured to generate the indication data, for example, such that the indication data includes at least one of a region sequence stop flag and a region line stop flag of the coding tree unit. If the explicit signaling mode is inactive and the coding tree unit of one or more coding tree units of a coding region is located at the image boundary of an image, the data encoder 110 may be configured to generate the indication data, for example, such that the indication data does not include a region sequence stop flag of the coding tree unit and / or does not include a region line stop flag of the coding tree unit.

[0264] Similarly, in an embodiment, data decoder 170 may be configured to decode image data that was encoded using information for, for example, a plurality of coding regions, the information including one or more region line stop flags for a coding region of one or more coding regions, where if a region line stop flag for a coding region of one or more coding regions is set to a stop value, the region line stop flag may indicate, for example, a width of the coding region. Or, data decoder 170 may be configured to decode image data that was encoded using information for, for example, a plurality of coding regions, the information being one or more region line stop flags for a coding region of one or more coding regions, where if a region line stop flag for a coding region of one or more coding regions is set to a stop value, the region line stop flag may indicate, for example, a height of the coding region.

[0265] According to an embodiment, the data decoder 170 may be configured to decode the encoded image data, for example, using an indication in the instruction data indicating whether the explicit signaling mode is active or whether the explicit signaling mode is inactive. If the explicit signaling mode is inactive and a coding tree unit of one or more coding tree units of a coding region is located at said image border of an image, the data decoder 170 may be configured to decode the encoded image data, for example, depending on an image border image. The next sub-subsection, "CTU Scanning Order," describes the CTU scanning order. The next sub-sub-section, "Raster Scanning," describes raster scanning.

[0266] If an image is divided into multiple CAs, the traditional raster scan method can be applied to the CTU processing scheme. Using this method, and knowing the division scheme of the whole image via coding regions, the CTUs of the whole image can be processed line by line. This kind of processing was already possible with tiles in HEVC. Therefore, in this case, the flexibility of the CTU processing scheme is maintained.

[0267] Thus, according to an embodiment, the coding order of each coding region of one or more coding regions that include two or more coding tree units may depend, for example, on a raster scan, and data encoder 110 may be configured to generate instruction data, for example, such that the instruction data indicates that a raster scan was used to encode each coding region of one or more coding regions that include two or more coding tree units.

[0268] Similarly, according to an embodiment, the coding order of each coding region of the one or more coding regions comprising two or more coding tree units may depend on a raster scan, and data decoder 170 may be configured to decode image data encoded depending on the raster scan, and data decoder 170 may be configured to receive information indicating that a raster scan was used to encode each coding region of the one or more coding regions comprising two or more coding tree units, and the instruction data may, for example, include said information. The next sub-sub-section, "Diagonal Scanning," describes diagonal scanning.

[0269] However, traditional raster scan ordering has limitations in the availability of spatial references. To improve this, in an embodiment, diagonal scan is used as an additional CTU processing scheme.

[0270] To derive the diagonal scan, we use a generalized treatment of dependencies on upper CTU lines from [2]: CTU_dependency_offset_id([2]).

[0271] CTU Xref,Yref The block corresponding to CTU is available for reference. Xref,Yref The current CTU Xcur,Ycur can be used to predict, when the reference is unconstrained, e.g., outside another slice, tile, or image, and the following conditions hold: -For WPP:

number

[0272]

number

number

[0273]

number

[0274]

number

[0275] Using the above upper neighbor block offset constraints, the CTU processing order can be derived. The resulting various CTU scans are variations of the diagonal scan with a particular slant or angle, where the slant is given by a fixed value, controlled by a syntax element transmitted in the bitstream, or derived from a syntax element already present in the bitstream. FIG. 12 shows CTU scan order and spatial referencing for CTU_dependency_offset_id=1 according to an embodiment. FIG. 13 shows another CTU scan order and spatial references for CTU_dependency_offset_id=2 according to another embodiment.

[0276] Various types of CTU scans can be generated, as shown below in Figures 12 and 13. The default scan direction is diagonally down from left to right and can be generated by the following algorithm (Matlab®): Slope=CTU_dependency_offset_id-1;

[0277] A=repmat(1:NumCTUColumns,NumCTURows,1)+repmat((0:NumCTUColumns:(NumCTUColumns*(NumCTURows-1)))',1,NumCTUColumns) scan=zeros(1,numel(A));%raster scan idxes scanXY=zeros(2,numel(A)); idx=1; x=1;y=1; while not(all(size(A)==[yx])) if y<=NumCTURows&&x<=NumCTUColumns %scan it scan(idx) = A(y,x); scanXY(:,idx)=[x,y]'; idx=idx+1; else %ignore it end if x>Slope if y <NumCTURows x=x-Slope; y=y+1; else x=x+(NumCTURows-1)*Slope+1; y=1; end else if y==1 x=x+1; else if x<=Slope||y==NumCTURows x=x+(y-1)*Slope+1; y=1; end end end end %scan it scan(idx) = A(y,x); scanXY(:,idx)=[x,y]'; idx=idx+1; Below is an example scan and spatial referencing availability for several CTU_dependency_offset_id values: To summarise the above:

[0278] According to an embodiment, the coding order of the coding regions of one or more coding regions including two or more coding tree units may depend on a scan order that depends on a tilt indicating an angle, for example. After encoding a first one of the two or more coding tree units of the coding region, the data encoder 110 may be configured to determine a second one of the two or more coding tree units in the coding region, for example, depending on a position of the first one of the coding tree units of the coding region, depending on other coding tree units of the coding region that have not been encoded, and depending on a tilt. The data encoder 110 may be configured to encode the second one of the two or more coding tree units, for example.

[0279] In an embodiment, the data encoder 110 is configured, for example, to determine a second one of two or more coding tree units in a coding region, and the arrow is defined by a starting point and a slope, where the starting point may be the position of the first one of the coding tree units in the coding region and points to the position of the second one of the two or more coding tree units.

[0280] According to an embodiment, the data encoder 110 may be configured to generate the instruction data, such that the instruction data indicates that a diagonal scan was used to encode each coding region of one or more coding regions that include two or more coding tree units, for example.

[0281] Similarly, according to an embodiment, the coding order of the coding regions of one or more coding regions including two or more coding tree units may depend on a scan order that depends on a tilt indicating an angle, for example. The instruction data may include, for example, said information of a coding region, in which, after encoding a first one of the two or more coding tree units of a coding region, the data decoder 170 may be configured to determine a second one of the two or more coding tree units in the coding region, for example, depending on a position of the first one of the coding tree units of the coding region, depending on other coding tree units of the coding region that have not been decoded, and depending on a tilt. The data decoder 170 may be configured to decode, for example, said second one of the two or more coding tree units.

[0282] According to an embodiment, the data decoder 170 may be configured to determine a second one of the two or more coding tree units in the coding region, e.g., as an arrow defined by a starting point and a slope. The starting point may be, e.g., the position of the first one of the coding tree units in the coding region, and points to the position of the second one of the two or more coding tree units.

[0283] In an embodiment, the data decoder 170 may be configured to receive information indicating data indicating that a diagonal scan was used to encode each coding region of one or more coding regions that include two or more coding tree units, and the indication data may include, for example, the information. The next sub-sub-section, "Z-Scan," describes Z-Scan. FIG. 14 shows coding regions in Z-scan CTU order, according to an embodiment.

[0284] In such an embodiment, instead of the proposed diagonal scan, a Z-scan can be used for the CTU scan order, as defined in HEVC.

[0285] According to an embodiment, the coding order of a coding region including five or more coding tree units may, for example, depend on a scan order, which may depend on a first angle being 0°, a second angle being 135°, and a third angle being 45°.

[0286] After encoding the first coding tree unit of the coding region, data encoder 110 may, for example, be configured to determine a second coding tree unit of the coding tree region, such that a first arrow having a first starting point at the position of the first coding tree unit in the coding region encloses a first angle that is 0° with respect to a predefined direction, and the first arrow points to the second coding tree unit in the coding region, and data encoder 110 is configured to encode the second coding tree unit of the coding region.

[0287] After encoding the second coding tree unit of the coding region, data encoder 110 may, for example, be configured to determine a third coding tree unit of the coding tree region, such that a second arrow having a second starting point at the position of the second coding tree unit in the coding region encloses a second angle that is 135° relative to the predefined direction, and the second arrow points to the third coding tree unit in the coding region, and data encoder 110 is configured to encode the third coding tree unit of the coding region.

[0288] After encoding the third coding tree unit of the coding region, data encoder 110 may, for example, be configured to determine a fourth coding tree unit of the coding tree region, such that a third arrow having a third starting point at the position of the third coding tree unit in the coding region encloses a first angle that is 0° with respect to the predefined direction, and the third arrow points to the fourth coding tree unit in the coding region, and data encoder 110 is configured to encode the fourth coding tree unit of the coding region.

[0289] In a particular embodiment, after encoding the fourth coding tree unit of the coding region, data encoder 110 may be configured to determine a fifth coding tree unit of the coding tree region, such that a fourth arrow having a fourth starting point at the position of the fourth coding tree unit in the coding region encloses a third angle that is 45° relative to the predefined direction, and the fourth arrow points to the fifth coding tree unit in the coding region, and data encoder 110 is configured to encode the fifth coding tree unit of the coding region.

[0290] In an embodiment, the data encoder 110 may be configured to generate the instruction data such that the instruction data indicates that a z-scan was used to encode each of one or more coding regions that include five or more coding tree units, for example.

[0291] Similarly, according to an embodiment, the coding order of a coding region including five or more coding tree units may depend, for example, on a scan order, which may depend on the first angle being 0°, the second angle being 135°, and the third angle being 45°.

[0292] After decoding the first coding tree unit of the coding region, data decoder 170 may, for example, be configured to determine a second coding tree unit of the coding tree region, such that a first arrow having a first starting point at the position of the first coding tree unit in the coding region encloses a first angle that is 0° with respect to a predefined direction, and the first arrow points to the second coding tree unit in the coding region, and data decoder 170 is configured to decode the second coding tree unit of the coding region.

[0293] After decoding the second coding tree unit of the coding region, data decoder 170 may, for example, be configured to determine a third coding tree unit of the coding tree region, such that a second arrow having a second starting point at the position of the second coding tree unit in the coding region encloses a second angle that is 135° relative to the predefined direction, and the second arrow points to the third coding tree unit in the coding region, and data decoder 170 is configured to decode the third coding tree unit of the coding region.

[0294] After decoding the third coding tree unit of the coding region, data decoder 170 may, for example, be configured to determine a fourth coding tree unit of the coding tree region, such that a third arrow having a third starting point at the position of the third coding tree unit in the coding region encloses a first angle that is 0° with respect to the predefined direction, and the third arrow points to the fourth coding tree unit in the coding region, and data decoder 170 is configured to decode the fourth coding tree unit of the coding region.

[0295] In a particular embodiment, after decoding the fourth coding tree unit of the coding region, data decoder 170 may be configured to determine a fifth coding tree unit of the coding tree region, such that a fourth arrow having a fourth starting point at the position of the fourth coding tree unit in the coding region encloses a third angle that is 45° relative to the predefined direction, and the fourth arrow points to the fifth coding tree unit in the coding region, and data decoder 170 is configured to decode the fifth coding tree unit of the coding region.

[0296] According to an embodiment, the data decoder 170 may be configured to receive information indicating that a z-scan was used to encode each of one or more coding regions that include, for example, five or more coding tree units, and the instruction data may include, for example, said information. The next sub-sub-section, "Scanning Direction," describes scanning direction.

[0297] In another embodiment, the scan direction can be flexible, ranging for example from diagonally down from right to left, diagonally up from right to left respectively, or diagonally up from left to right. The scan direction can be transmitted in the bitstream using a new syntax element CTU_scan_direction or can be derived from syntax elements already present in the bitstream.

[0298] In another embodiment, the scan direction is derived by evaluating the immediate neighborhood of the first slice CTU addressed by coding_area_start_address, under strict slice order constraints.

[0299] If the first slice CTU has an adjacent CTU neighbor at its bottom boundary, or if the first slice CTU is located in the bottom CTU line of the image, has no adjacent neighbor on the right, and is not located in the rightmost CTU column, the CTU scan is an upper-right scan.

[0300] If the first slice CTU has an adjacent CTU neighbor at its bottom boundary, or if the first slice CTU is located in the bottom CTU line of the image and has an adjacent neighbor on the right side or is located in the rightmost column of the image, the CTU scan is an up-left scan.

[0301] Otherwise, if a CTU neighbor is available to the right of the first slice CTU or if the first slice CTU is located in the rightmost column of the image, the scan is bottom-left. In all other cases, the CTU scan is bottom-right. FIG. 15 illustrates the derivation of an implicit CTU scan direction according to another embodiment.

[0302] In such another embodiment, the derivation scheme of the above invention is further improved by evaluating the number of available CTU neighbors along the potential coding region boundary. For example, the first slice CTU is at the top left position of the CTU neighbor, and the scan can be a bottom-right scan or a bottom-right scan, so the available possible (if the CA dimension is unknown) CTU neighbors along the coding region boundary in the vertical and horizontal directions are summed separately. If the sum of the vertical neighbors exceeds the number of horizontal CTU neighbors, a bottom-right scan is used. Otherwise, the scan is a bottom-right scan. This derivation scheme is illustrated in FIG. 15 using a raster scan.

[0303] In another embodiment, the above inventive derivation scheme and refinements are used to form an ordered list of possible scans, where an index is sent at slice level to select the CTU scan. Furthermore, if different diagonal scans are used in the image, the CTU_dependency_offset_id needs to be coded in the slice header. FIG. 16 illustrates coding regions for different CTU scanning directions according to an embodiment. In particular, FIG. 16 shows an example of using different scan directions within an image. To summarise the above:

[0304] According to an embodiment, the coding order of one or more coding regions including two or more coding tree units may depend on a scan order including, for example, one or more scan directions. After encoding a first coding tree unit of the coding region, the data encoder 110 may be configured to determine a second coding tree unit of the coding tree region, for example, depending on a position of the first coding tree unit and depending on a first one of one or more scan directions, and the data encoder 110 is configured to encode the second coding tree unit of the coding region.

[0305] In an embodiment, the data encoder 110 may be configured to generate the instruction data, such that the instruction data indicates the scan order, including, for example, one or more scan directions.

[0306] According to an embodiment, the data encoder 110 may be configured to derive the scan direction of one or more scan directions, for example, by evaluating the immediate neighborhood of the first coding tree unit of the coding region. If there are coding tree unit neighbors of two or more coding tree units adjacent to the bottom boundary of the first coding tree unit, or if the first coding tree unit is located in a coding tree unit row at the bottom of the image, has no adjacent neighbors to the right, and is not located in a right-most coding tree unit column, the scan direction may be, for example, a top-right scan. If there are coding tree unit neighbors of two or more coding tree units adjacent to the bottom boundary of the first coding tree unit, or if the first coding tree unit is located in a coding tree unit row at the bottom of the image, has an adjacent neighbor to the right, or is located in a right-most column of the image, the scan direction may be, for example, a top-left scan. If coding tree unit neighbors of two or more coding tree units to the right of the first coding tree unit are available, or if the first coding tree unit is located in the rightmost column of the image, the scanning direction may be, for example, left-downward. Otherwise, the scanning direction may be, for example, right-downward.

[0307] In an embodiment, the data encoder 110 may be configured to generate the instruction data, for example, such that the instruction data indicates an index of one or more scan directions that indicates a selected scan direction.

[0308] Similarly, according to an embodiment, the coding order of one or more coding regions including two or more coding tree units may depend on a scan order including, for example, one or more scan directions. After decoding a first coding tree unit of the coding region, data decoder 170 may be configured to determine a second coding tree unit of the coding tree region depending on a first one of one or more scan directions, for example, depending on a position of the first coding tree unit, and data decoder 170 may be configured to decode the second coding tree unit of the coding region.

[0309] In an embodiment, data decoder 170 may be configured to receive information indicative of the scan order, including, for example, one or more scan directions, where instruction data may include, for example, said information.

[0310] According to an embodiment, the data decoder 170 may be configured to derive the scan direction of one or more scan directions, for example, by evaluating the immediate neighborhood of the first coding tree unit of the coding region. If there are coding tree unit neighbors of two or more coding tree units adjacent to the bottom boundary of the first coding tree unit, or if the first coding tree unit is located in a coding tree unit row at the bottom of the image, has no adjacent neighbors to the right, and is not located in a right-most coding tree unit column, the scan direction may be, for example, a top-right scan. If there are coding tree unit neighbors of two or more coding tree units adjacent to the bottom boundary of the first coding tree unit, or if the first coding tree unit is located in a coding tree unit row at the bottom of the image, has an adjacent neighbor to the right, or is located in a right-most column of the image, the scan direction may be, for example, a top-left scan. If coding tree unit neighbors of two or more coding tree units to the right of the first coding tree unit are available, or if the first coding tree unit is located in the rightmost column of the image, the scanning direction may be, for example, left-downward. Otherwise, the scanning direction may be, for example, right-downward.

[0311] In an embodiment, the data decoder 170 may be configured to receive information indicating, for example, an index indicating a selected scan direction of one or more scan directions, and the instruction data may include, for example, said information. Dependent coding regions are discussed in the sub-subsection "Dependent Coding Regions" below. FIG. 17 illustrates dependent coding regions with inter-region prediction option according to an embodiment.

[0312] In such an embodiment, within an image, one coding region may depend on another coding region to exploit spatial prediction capabilities. In this case, a specific processing order of the regions may be required, for example, to facilitate deterministic operation. This can be done, for example, by signaling the order of the regions using a new syntax element area_order_idx in each CA that explicitly determines the order of the dependency. Alternatively, the order of the dependency can be derived directly from the order of the CAs signaled in the coding_area_arrangement() syntax. See the sub-subsection "Size and arrangement of coding regions".

[0313] The values ​​of area_order_idx can be interpreted as follows: Areas with high area_order_idx values ​​depend on areas with low area_order_idx values ​​and vice versa. To summarise the above:

[0314] In an embodiment, data encoder 110 may be configured to encode an image, for example, by encoding image data of the image in each coding area of ​​a plurality of coding areas to obtain encoded image data. Data encoder 110 may be configured to encode image data of at least one image of the plurality of coding areas such that encoding the image data of at least one of the plurality of coding areas is dependent on encoding the image data of at least another one of the plurality of coding areas.

[0315] Similarly, in an embodiment, data decoder 170 may be configured, for example, to decode encoded image data of at least one of a plurality of coding regions, where the decoding of the encoded image data of at least one of the plurality of coding regions is dependent on the decoding of the encoded image data of the at least another one of the plurality of coding regions. The following sub-subsection "Parallel Processing of Coding Regions" describes parallel processing of coding regions.

[0316] Coding regions can also aid in parallel processing. An obvious use case for parallelization is the use of multiple independent coding regions. In this case, dependencies on parsing or reconstructing the constructed CTUs of one CA onto any of the other CAs are prohibited, and adjacent CUs assigned to another CA are treated as not referenceable. In this case, post-processing filters may be applied to CAs individually or per picture, depending on the filter_over_ca_boundaries_flag. This syntax element works the same as the loop_filter_across_tiles_enabled_flag used in HEVC. FIG. 18 shows parallel processing of dependent coding regions according to an embodiment ((A) CTU raster scan; (B) CTU diagonal scan).

[0317] For dependent coding regions, the processing scheme shown in Fig. 18 can be used to exploit spatial dependencies in the image and reduce possible artifacts at the boundaries between regions. Using inter-CA dependencies may, for example, require a clear order of CTU processing, resulting in reliable availability of CTUs from neighboring CAs.

[0318] The order in which the CAs are processed may be implicitly specified by the order in which the CAs are transmitted in the bitstream, and the order of the CAs may also be explicitly specified by the symbols transmitted in the bitstream. The two main CTU implementation concepts are shown in FIG. FIG. 19 shows the execution order and inter-CA dependencies according to the embodiment ((A) dependency-driven; (B) lockstep). The lockstep pipeline is described below.

[0319] The pipeline concept assumes parsing and reconstruction and / or post-filtering following a lock-step execution scheme. Global events are used to initiate execution steps of CTUs in each thread, and in each step, a single CTU is processed in each CA. This scheme guarantees maximum throughput at the expense of unavailable CTU lookups, as shown in Figure 19(B). In this case, directly adjacent CTUs in the first and second CAs are processed simultaneously, so lookups in either direction are not possible. However, when strict lockstep execution is enforced, additional inter-CA dependencies become available, as indicated by the light blue arrows. In the following, the concept of dependency-driven is explained.

[0320] This concept relies on the local availability of inter-CA CTU neighbors. If a reference CTU of an adjacent neighbor CA is not available, although it should be available for reference, the execution of this particular CA will be stopped until the reference CTU becomes available by completing each analysis reconstruction. This can be seen, for example, in Fig. 19(A) where the processing of the second CA is stopped in the fifth execution step because the reference CTU of the first CA is processed in the fifth execution step and is the earliest available in the sixth execution step.

[0321] Furthermore, parallel processing can be extended to the operation of post-processing filters using the dependent CA processing scheme. In case of CTU internal boundaries (CU boundaries), a default filter process can be applied. In contrast, CTU boundaries are filtered when the second CTU in the processing order is filtered, so that the filter strength at the boundaries can be determined and samples for filtering are available. This rule also applies to CA cross-boundary filtering, if CA cross-boundary filtering is enabled or in case of dependent CA. Deblocking filters that reach beyond the CTU boundaries are processed in an analogous way, when analysis and reconstruction are performed taking into account the availability of reference CTUs in neighboring CAs. If a CTU of a neighboring CA is available, the parts of the area that were not pre-filtered are filtered in the current filtering process. FIG. 20 illustrates a deblocking filter process on a CA boundary for a CA order, according to an embodiment. FIG. 21 illustrates a deblocking filter employing CA-to-CA filtering in the hatched filter region, according to an embodiment.

[0322] As shown in FIG. 21, in the first processing step, only the CTU(1) of the first CA can be filtered. The filtering of this CTU is limited to the inner boundary because no CTU neighbors are available. In the second execution step, the second CTU of the first CA filters its inner boundary and the CTU boundary to the first CTU of the first CA. In addition, the bottom left CTU of the second CA is filtering its inner boundary and the CA that overlaps with the CTU boundary of the first CTU of the first CA. One effect of this parallel processing is to enable low-latency operation of the deblocking filter. The deblocking of the cross-CA boundary filtering can start before the entire CA is decoded, thereby reducing the overall processing time before the image region can use the reference image for further images. The next sub-subsection, "Error Resilience Aspects," describes error resilience aspects.

[0323] As discussed in the "State of the Art VCL Partitioning" section, error resilience is a desirable feature of video coding when the application's storage or transport mechanism is unreliable. However, many applications exist today, such as HTTP streaming, that may require less error resilience, e.g., RTP / UDP streaming with packet loss or general broadcast channels with bit or burst errors. For HTTP streaming, the coded video is typically segmented in n*GOP units, and missing segments trigger buffer stalls at the receiver until the respective segments are successfully retransmitted. In the latter scenario, it is desirable to introduce further dependencies within the coded data to improve coding efficiency gains while losing some error resilience. For example, the aspect of scan order derivation based on neighboring CAs described in the sub-subsection "Scanning Direction" may require, for example, the availability of neighboring CAs at the receiver before the current CA can be correctly decoded. Thus, such techniques should only be used when limited error resilience is acceptable. Similarly, aspects related to dependent coding regions, such as sub-subsection "Dependent Coding Regions", introduce dependencies that affect error resilience, as well as parallelization aspects and processing order as described in sub-subsection "Parallel Processing of Coding Regions". Other state-of-the-art techniques in this regard must deal with the same trade-offs, such as intra-picture translation-compensated prediction, such as IBC in HEVC SCC, or other intra-prediction techniques that promote samples in pictures that are further away from the current block and would otherwise be regular intra-predictions. Also, at the sequence level, there are further techniques known to improve coding efficiency at the expense of impact on error resilience, such as sharing the state of entropy coding entities, such as CABAC context models across pictures.

[0324] In systems incorporating the transmission of coded video, information about the degree of error resilience offered by the coded video stream can be utilized in various ways. For example, a media-aware middlebox can trigger an early retransmission, or an end device can choose among error concealment strategies, such as frame-level slice-based error concealment by copying frame subsections, buffering until a successful retransmission, or skipping the decoding of parts of the bitstream (individual AUs, AUs associated with a PPS, etc., AUs associated with an SPS or forming a CVS). It is therefore desirable to indicate to a middlebox or a client end device the degree of error resilience offered by the coded video stream. Another use of the degree of error concealment in a coded video sequence is for a service operator to determine whether a particular coded stream is suitable for an envisaged transmission system. For example, a stream encoded for HTTP streaming may perform poorly if transmitted over a satellite channel prone to burst errors.

[0325] Currently, this information is not easily accessible in streams coded using modern codecs, since a myriad of parameters determine the error resilience. Take for example the non-exhaustive list of examples above. Some individual parameters may be derived from a set of parameters, others may require high-level parsing, e.g. on a picture-by-picture basis, while others may even require low-level parsing. Also, most of the investigated parameters are limited in scope, although they are not signaled with information about the encoder's decisions for the rest of the coded video sequence. For example, splitting decisions may happen by chance from picture to picture. A corrupted stream may not contain the required information.

[0326] Embodiments provide an easily accessible indication of the degree of error resilience of a coded video sequence. Some embodiments provide coding constraints for the coded video on error resilience and related tools that affect error mitigation strategies. A middlebox or client end device can interpret the indication as an assurance that the video encoder has excluded certain options from a decision space that would otherwise affect error resilience. A service provider can interpret the information regarding which transmission system the coded stream is suitable for. In an embodiment, a single flag in an easily accessible high level syntax of the coded video is provided, for example, as follows:

[0327] [Table 12]

[0328] sps_error_resiliency_enabled_flag indicates the error resiliency state of the coded video sequence. If sps_error_resiliency_flag is 1, it indicates that no SPS active in the CVS activates the use of [CodingToolSetC] and no PPS or AU active in the CVS activates the use of [CodingToolSetB]. If sps_error_resiliency_flag is 0, there is no such indication.

[0329] Alternatively, embodiments provide an index into a predefined list of error resilience states in an easily accessible high-level syntax of the coded video, as follows:

[0330] [Table 13] sps_error_resiliency_enabled_idx indicates the error resiliency status of the coded video sequence according to the following table:

[0331] [Table 14] AU = Access Unit; PPS = Picture Parameter Set; SPS = Sequence Parameter Set, CVS coded video sequence

[0332] where the lists [CodingToolSetA], [CodingToolSetB], and [CodingToolsSetC] are defined as follows:

[0333] CodingToolSetA consists of tools that impair error resilience at the image level, i.e., by introducing dependencies within an image that prevent successful decoding when parts of the image are lost, such as dependent CA.

[0334] CodingToolSetB consists of tools that impair error resilience at a multi-picture level (i.e., the scope of the PPS), i.e., using tools after an erroneous picture, such as joint entropy coding of multiple pictures, e.g., pictures belonging to the top temporal layer of a GOP, to introduce dependencies between any of the pictures that reference the PPS, preventing successful decoding of the pictures that reference the PPS.

[0335] CodingToolsSetC consists of tools that impair error resilience at the sequence level (i.e., the scope of the SPS), i.e., they introduce dependencies between all images within the random access period, making it impossible to successfully decode any image that references the SPS using tools following an erroneous image until the random access point starts a new CVS, such as initialization of quantizer scaling matrices, entropy coding, etc. In a further embodiment of the invention, the different modes of instruction are not linked to a syntactic structure that activates a toolset.

[0336] [Table 15]

[0337] Furthermore, the extent of CodingToolSetB is indicated by additional signaling indicating the extent in terms of the amount of images following in coding order from the first image. CodingToolSetB in this embodiment thus includes tools that impair error resilience at a multi-image level (each image being represented by a scope display), i.e. they introduce dependencies between the represented images, thus preventing successful decoding of any of the images using the toolset following the erroneous image, e.g. images belonging to the highest temporal layer such as a GOP, of the joint entropy coding of multiple images.

[0338] To summarize the above, according to an embodiment, the data encoder 110 may be configured to generate the instruction data, such that the instruction data may include, for example, information regarding the error resilience of the coded video sequence.

[0339] In an embodiment, the information regarding error resilience may, for example, indicate one of three or more different states regarding the error resilience of the coded video sequence.

[0340] Similarly, according to an embodiment, the data decoder 170 may be configured to receive information indicative of, for example, the error resilience of the coded video sequence. The data decoder 170 may be configured to decode the coded image data in dependence on, for example, the information indicative of the error resilience of the coded video sequence.

[0341] In an embodiment, the information regarding error resilience may, for example, indicate one of three or more different states regarding the error resilience of the coded video sequence.

[0342] In a particular embodiment, a first state of the three or more different states may indicate, for example, that the access unit is not error resilient. A second state of the three or more different states may indicate, for example, that the first plurality of access units of a picture parameter set is not error resilient. A third state of the three or more different states may indicate, for example, that the second plurality of access units of a sequence parameter set is not error resilient.

[0343] In another particular embodiment, the information regarding the error resilience may indicate, for example, one of four or more different states regarding the error resilience of the coded video sequence. A first state of the four or more different states may indicate, for example, that the error resilience is impaired at the picture level, impaired at the multi-picture level, and impaired at the sequence level. A second state of the four or more different states may indicate, for example, that the error resilience is impaired at the picture level, impaired at the multi-picture level, but not impaired at the sequence level. A third state of the four or more different states may indicate, for example, that the error resilience is impaired at the picture level, but not impaired at the multi-picture level, and not impaired at the sequence level. And a fourth state of the four or more different states may indicate, for example, that the error resilience is not impaired at the picture level, not impaired at the multi-picture level, and not impaired at the sequence level. The next subsection, "Fragmentation of Coding Region Data," describes fragmentation of coding region data. Similar to tiles, CAs can also be fragmented for the transport layer. In this case, there are no restrictions. Possible use cases are shown in Figures 22, 23, and 24. Figure 22 shows a bitstream consisting of a single image of one coding domain, but with CA fragmented into multiple transport units. Figure 23 shows a bitstream consisting of a single image of multiple coding regions, but with each CA having its own transport unit. FIG. 24 shows a bitstream containing a single image of multiple coding regions, but with each CA fragmented into multiple transport units. In the next subsection, "Coding for Sub-region Spatial Predictor Management", the coding for sub-region spatial predictor management is described. FIG. 25 illustrates a generalized presentation of a block surrounded by a region, according to an embodiment. In a generalized approach, a coding block can be surrounded by eight main spatial regions, see FIG. The next sub-subsection, "General predictor management," describes general predictor management.

[0344] Candidates from all eight neighbor regions can be incorporated into the predicted candidate list. They can each be selected for availability in a straightforward manner. For CTU, for example, a subdivision into subblocks can be configured with a specific subblock processing order, and the subblock order can be adjusted depending on the specific availability scenario. For example, if only neighbors AD, D, DC, and C are available, the subblocks adjacent to these neighbors should be processed first.

[0345] In summary, according to an embodiment, the data encoder 110 can be configured to encode a coding tree unit of a plurality of coding tree units located in an image, for example, depending on one or more coding tree units of eight adjacent coding tree units of the plurality of coding tree units located in the image, the eight adjacent coding tree units being adjacent to said coding tree unit.

[0346] Similarly, in an embodiment, the data decoder 170 may be configured to decode a coding tree unit of a plurality of coding tree units located in an image, for example, depending on one or more coding tree units of eight adjacent coding tree units of the plurality of coding tree units located in the image, the eight adjacent coding tree units being adjacent to the coding tree unit. The next sub-subsection, "Neighbor spatial compatibility," describes neighbor spatial compatibility.

[0347] Some specific neighborhood scenarios allow for a conventional sub-block processing order by adapting some of the predictors or regions of the corresponding neighbors. In an embodiment, the adaptation may include, for example, a rotation of the corresponding neighbor regions and, if necessary, a coding block in stages in 90° steps. For example, in the figure, if only neighbors AD, D, DC, C, and BC are available, a rotation of these neighbors and, if necessary, a 180° rotation of the coding block can be performed. This may be a logical rotation or a memory operation such as transforming buffered data, such as samples or syntax elements, to a new buffered state. The coordinate transformation can also include horizontal or vertical flipping, which leads to a different ordering of the prediction candidates.

[0348] In summary, in an embodiment, the data encoder 110 may be configured to encode a coding tree unit of a plurality of coding tree units located within an image, for example, by shifting a coding tree unit of the eight adjacent coding tree units to another one of the eight adjacent coding tree units.

[0349] Similarly, according to an embodiment, the data decoder 170 may be configured to decode a coding tree unit of a plurality of coding tree units located within an image, for example, by shifting a coding tree unit of the eight adjacent coding tree units to another one of the eight adjacent coding tree units. The next sub-subsection "Concept of Replacing Unavailable Neighbors" describes the concept of replacing unavailable neighbors.

[0350] In some cases, spatial neighbors are not available for prediction. In such cases, the derivation algorithm either uses various neighbors that are available for prediction, or the algorithm uses some kind of fallback to derive a value, either using values ​​explicitly transmitted in the bitstream or derived from previously coded symbols or reconstructed values.

[0351] In particular embodiments, spatial neighbors that are unavailable for prediction may be replaced by neighbors from the spatial neighborhood below the current block, for example, if available. Otherwise, if there is no spatial predictor below the current block available, a default fallback is used.

[0352] In the following, the term "bottom-left extension" in this context is defined as the block immediately to the left and to the right of the current block, according to the definition of 0, except for the special case where the bottom-left sample of the current block is in the bottom sample row of the current CTU. In this special case, the bottom-left extension neighbor of the current block is the block to the top right of the CTU in the next CTU line, which can be used for prediction according to the proposed block dependency offset. For example, the current state-of-the-art standard 0 QP prediction scheme uses the following derivation scheme for a given fallBackQP: A=(isLeftCUavailble ?CULeftQP:fallBackQP) B=(isAboveCUavailble ?CUAboveQP:fallBackQP) PredictedQP=(A+B+1)>>1

[0353] In a particular embodiment, the prediction scheme is extended to use the QP of the bottom-left extended CU if the left CU responds. The above CUs are not available for prediction, but the bottom-left extended CUs are. If neither the normal neighbor CU nor the bottom-left extended CU is available for prediction, the fallBackQP is used instead to derive the values ​​of A and B, respectively.

[0354] A=(isLeftCUavailble ?CULeftQP:(isExtendedBelowLeftCUavailble ?CUExtendedBelowLeftQP:fallBackQP))

[0355] B=(isAboveCUavailble ?CUAboveQP:(isExtendedBelowLeftCUavailble ?CUExtendedBelowLeftQP:fallBackQP)) PredictedQP=(A+B+1)>>1 However, this kind of prediction scheme is universal and can be applied to any prediction scheme that uses prediction data from left and right neighbors. especially, derivation of CABAC CTX CU split_flag derivation of CABAC CTX affine_flag derivation of CABAC CTX skip_flag derivation of CABAC CTX imv_flag derivation of CABAC CTX bt_split_flag derivation of CABAC CTX intra_nn_flag

[0356] Furthermore, the invented prediction scheme can also be used in canonical decoding processes to derive specific predictors, such as the derivation process of motion vector components and reference indices, or the derivation process of luma intra prediction modes.

[0357] In summary, according to an embodiment, the eight adjacent coding tree units are a first neighborhood, and the data encoder 110 can be configured to encode the coding tree unit of the plurality of coding tree units, for example, by shifting a third coding tree unit of another eight adjacent coding tree units of a second neighborhood to a second coding tree unit of the eight adjacent coding tree units of the first neighborhood, and if the second coding tree unit of the eight adjacent coding tree units of the first neighborhood is unavailable, the other eight adjacent coding tree units of the second neighborhood are adjacent to the second coding tree unit.

[0358] Similarly, in an embodiment, the eight adjacent coding tree units may be, for example, a first neighborhood, and the data decoder 170 may be configured to decode the coding tree unit of the plurality of coding tree units located in the image, for example, by shifting a third coding tree unit of another eight adjacent coding tree units of a second neighborhood to a second coding tree unit of the eight adjacent coding tree units of the first neighborhood, and if the second coding tree unit of the eight adjacent coding tree units of the first neighborhood is unavailable, the other eight adjacent coding tree units of the second neighborhood are adjacent to the second coding tree unit.

[0359] Further provided is an encoded video signal for encoding an image, wherein the encoded video signal comprises encoded image data and instruction data, the image being divided into a plurality of coding regions, each coding region of the plurality of coding regions being located within the image, each of the plurality of coding regions comprising one or more coding tree units of a plurality of coding tree units located within the image, the image being encoded in dependence on the plurality of coding regions, the instruction data comprising information regarding the plurality of coding regions, one or more coding regions of the plurality of coding regions comprising two or more coding tree units, each coding region of the one or more coding regions comprising two or more coding tree units indicating a coding order for the two or more coding tree units of said coding region, the image being encoded in dependence on the coding order of the one or more coding regions comprising two or more coding tree units, and the instruction data comprising information regarding the coding order of the one or more coding regions comprising two or more coding tree units.

[0360] According to an embodiment, each coding region of the plurality of coding regions extends rectangularly in the image, and each coding tree unit of the one or more coding tree units of each of the plurality of coding regions extends rectangularly in the image.

[0361] In an embodiment, each of the plurality of coding tree units has a horizontal position in the image and a vertical position in the image, where a first coding region of the plurality of coding regions includes a first coding tree unit having a first vertical position that is identical to a second vertical position of a different second coding tree unit of a different second coding region of the plurality of coding regions, a third coding tree unit of the first coding region has a third vertical position that is different from the vertical position of any other coding tree unit of the second coding region, and a fourth coding tree unit of the second coding region has a third vertical position that is different from the vertical position of any other coding tree unit of the first coding region. a fourth vertical position different from the vertical position of a second coding tree unit of a different second coding region of a different second coding region of the plurality of coding regions, or a first coding region of the plurality of coding regions includes a first coding tree unit having a first horizontal position that is identical to a second horizontal position of a different second coding tree unit of a different second coding region of the plurality of coding regions, a third coding tree unit of the first coding region has a third horizontal position different from the horizontal position of any other coding tree unit of the second coding region, and a fourth coding tree unit of the second coding region has a fourth horizontal position different from the horizontal position of any other coding tree unit of the first coding region.

[0362] According to an embodiment, each coding area of ​​a plurality of coding areas may exhibit spatial characteristics including a position, a width, and a height of the coding area, the width and height of the coding area depending on a rectangular extension of the coding area, and the position of the coding area depending on the position of the coding area within the image.

[0363] A first height of a first one of the plurality of coding regions may differ from a second height of a second one of the plurality of coding regions, or a first width of a first one of the plurality of coding regions may differ from a second width of a second one of the plurality of coding regions. According to an embodiment, the instructions may include, for example, information regarding spatial characteristics of each coding region of the plurality of coding regions. In an embodiment, the instruction data may include, for example, a position, width, and height of each coding region of the multiple coding regions.

[0364] According to an embodiment, image data of an image portion of each of the plurality of coding regions may be coded independently of coding image data of the image portion of any other coding region of the plurality of coding regions to obtain coded image data in the coded video signal.

[0365] In an embodiment, the image portion may be encoded, for example, by encoding image data of the image portion in each coding area of ​​a plurality of coding areas to obtain encoded image data, and the image data of at least one of the plurality of coding areas may be encoded within the encoded video signal such that encoding the image data of at least one of the plurality of coding areas is dependent on encoding image data of at least another one of the plurality of coding areas. According to an embodiment, the encoded video signal may, for example, comprise a bitstream, the bitstream comprising encoded image data and instruction data.

[0366] In an embodiment, the indication data may include, for example, information for each coding region as to whether the address of the top left coding tree unit is specified.

[0367] According to an embodiment, the instruction data may, for example, comprise information regarding the number of the plurality of coding regions or the number of the plurality of coding regions minus one, or the number of the plurality of coding regions minus two.

[0368] In an embodiment, the instruction data may indicate, for example, whether one of the plurality of coding regions depends on another of the plurality of coding regions, for said one of the plurality of coding regions that follows said another of the plurality of coding regions.

[0369] According to an embodiment, the indication data may indicate, for example, whether exactly one slice of the plurality of slices is assigned to exactly one coding region of the plurality of coding regions.

[0370] In an embodiment, the instructional data may indicate, for example, whether the instructional data includes information regarding how to scan within each of one or more coding tree units of a plurality of coding regions.

[0371] According to an embodiment, the instruction data may, for example, indicate how to scan within each of one or more coding tree units of a plurality of coding regions.

[0372] In an embodiment, the indication data may, for example, indicate, for each of a plurality of coding regions, whether the coding region includes a plurality of coding tree units.

[0373] According to an embodiment, the instruction data may indicate, for example, for one of the multiple coding regions, whether the coding tree unit scan begins at the leftmost coding tree unit or whether the coding tree unit scan begins at the rightmost coding tree unit.

[0374] In an embodiment, the instruction data may indicate, for example, for one of the multiple coding regions, whether the coding tree unit scan begins at an upper coding tree unit row of the coding region or whether the coding tree unit scan begins at a lower coding tree unit row of the coding region.

[0375] In an embodiment, the instruction data may indicate, for example, for one of the multiple coding regions, whether a coding tree unit scan is to be initiated horizontally or whether a coding tree unit scan is to be initiated vertically.

[0376] According to an embodiment, the instruction data may indicate non-contiguous information indicating, for example, whether at least one of the multiple coding regions surrounds another one of the multiple coding regions, or whether none of the multiple coding regions surrounds another one of the coding regions.

[0377] According to an embodiment, the instruction data may, for example, indicate, for one of the multiple coding regions, a coding region width in coding tree units specifying the number of coding tree units arranged horizontally within one of the coding regions.

[0378] In an embodiment, the instruction data may, for example, indicate, for one of a plurality of coding regions, the height of the coding region in coding tree units specifying a number of coding tree units that are vertically positioned within one of the coding regions.

[0379] According to an embodiment, the indication data may, for example, indicate for a coding region of a plurality of coding regions whether a last coding tree unit in the horizontal direction in the coding region is smaller than another coding tree unit of the coding region that horizontally precedes the coding tree unit.

[0380] In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in a horizontal direction, the last coding tree unit in a horizontal direction being one of the plurality of last coding tree units in a horizontal direction. If the last coding tree unit in a horizontal direction in the coding region is smaller than another coding tree unit of the coding region preceding the last coding tree unit in a horizontal direction, each of the plurality of last coding tree units in a horizontal direction may have, for example, the same width.

[0381] In an embodiment, the indication data may, for example, indicate, for a coding region of a plurality of coding regions, whether a vertically last coding tree unit in the coding region is smaller than another coding tree unit of the coding region that vertically precedes the coding tree unit.

[0382] In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in a vertical direction, and the last coding tree unit in a vertical direction is one of the plurality of last coding tree units in a vertical direction. If the last coding tree unit in a vertical direction in the coding region is smaller than another coding tree unit of the coding region preceding the last coding tree unit in a vertical direction, each of the plurality of last coding tree units in a vertical direction may have, for example, the same height.

[0383] In an embodiment, the indication data indicates, for a coding region, whether a start address indicating one of one or more coding tree units of said coding region is indicated, or whether a start address indicating said one of the one or more coding tree units of said coding region is not indicated.

[0384] According to an embodiment, the instructional data may indicate how to divide the image one or more times to obtain multiple coding regions, for example by dividing the image one or more times. In an embodiment, the instruction data may, for example, indicate multiple coding region division locations. According to an embodiment, the instruction data may, for example, indicate a number of coding region division locations as an ordered sequence.

[0385] In an embodiment, the instruction data may, for example, indicate a plurality of coding region division positions as a plurality of coding region division position values, each of which depends on the width of the image or depends on the height of the image.

[0386] According to an embodiment, the instruction data may indicate how to hierarchically divide the image one or more times to obtain multiple coding regions, for example by hierarchically dividing the image one or more times.

[0387] In an embodiment, the instruction data may, for example, include one or more region sequence stop flags for a coding region of one or more coding regions, where if a region sequence stop flag of a coding region of one or more coding regions is set to a stop value, the region sequence stop flag may, for example, indicate a width of the coding region, or the instruction data may, for example, include one or more region line stop flags for a coding region of one or more coding regions, where if a region line stop flag of a coding region of one or more coding regions is set to a stop value, the region line stop flag may, for example, indicate a height of the coding region.

[0388] According to an embodiment, the indication data may, for example, indicate whether an explicit signaling mode is active or whether an explicit signaling mode is inactive. If the explicit signaling mode is active and a coding tree unit of one or more coding tree units of a coding region is located at an image border of an image, the indication data may, for example, include at least one of a region sequence stop flag and a region line stop flag of said coding tree unit. If the explicit signaling mode is inactive and said coding tree unit of one or more coding tree units of a coding region is located at said image border of an image, the indication data does not include a region sequence stop flag of said coding tree unit and / or does not include a region line stop flag of said coding tree unit.

[0389] According to an embodiment, the coding order of each coding region of the one or more coding regions comprising two or more coding tree units depends on raster scanning, and the instruction data includes information that can indicate, for example, that raster scanning was used to encode each coding region of the one or more coding regions comprising two or more coding tree units.

[0390] In an embodiment, the instruction data includes information that may indicate, for example, that a diagonal scan was used to encode each coding region of one or more coding regions that include two or more coding tree units.

[0391] In an embodiment, the instruction data may indicate that a z-scan was used to encode each of one or more coding regions that include, for example, five or more coding tree units. In an embodiment, the instructional data may indicate a scan order including, for example, one or more scan directions.

[0392] According to an embodiment, for example, the indication data may indicate, for example, an index that may indicate a selected scan direction of one or more scan directions. In an embodiment, the instruction data comprises information regarding the error resilience of the coded video sequence.

[0393] According to an embodiment, the information regarding error resilience may, for example, indicate one of three or more different states regarding the error resilience of the coded video sequence.

[0394] In an embodiment, a first state of the three or more different states may indicate, for example, that the access unit is not error resilient. A second state of the three or more different states may indicate, for example, that the first plurality of access units of the picture parameter set is not error resilient. A third state of the three or more different states may indicate, for example, that the second plurality of access units of the sequence parameter set is not error resilient.

[0395] In another embodiment, the information regarding the error resilience may indicate, for example, one of four or more different states regarding the error resilience of the coded video sequence. A first state of the four or more different states may indicate, for example, that the error resilience is impaired at the picture level, impaired at the multi-picture level, and impaired at the sequence level. A second state of the four or more different states may indicate, for example, that the error resilience is impaired at the picture level, impaired at the multi-picture level, but not impaired at the sequence level. A third state of the four or more different states may indicate, for example, that the error resilience is impaired at the picture level, but not impaired at the multi-picture level, and not impaired at the sequence level. And a fourth state of the four or more different states may indicate, for example, that the error resilience is not impaired at the picture level, not impaired at the multi-picture level, and not impaired at the sequence level.

[0396] Although some aspects have been described in the context of an apparatus, it will be apparent that these aspects also represent a description of a corresponding method, with blocks or devices corresponding to method steps or features of method steps. Similarly, aspects described in the context of a method step also represent a description of a corresponding block or item or function of a corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be performed by such an apparatus.

[0397] Depending on the particular implementation requirements, embodiments of the present invention can be implemented in hardware or software, or at least partially in hardware, or at least partially in software. Implementation can be performed using a digital storage medium, such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, flash memory, etc., on which electronically readable control signals are stored and which cooperate (or can cooperate) with a programmable computer system to perform the respective method. Thus, the digital storage medium can be computer readable.

[0398] Some embodiments according to the invention include a data carrier having electronically readable control signals capable of cooperating with a programmable computer system to cause one of the methods described herein to be performed.

[0399] In general, embodiments of the present invention can be implemented as a computer program product with program code that operates to perform one of the methods when the computer program product is run on a computer. The program code may for example be stored on a machine readable carrier. Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier.

[0400] In other words, an embodiment of the inventive method is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0401] A further embodiment of the inventive method is therefore a data carrier (or digital storage medium, or computer readable medium) comprising the computer program for performing one of the methods described herein recorded thereon. The data carrier, digital storage medium, or recorded medium is typically tangible and / or non-transitory.

[0402] A further embodiment of the inventive method is therefore a data stream or a sequence of signals representing the computer program for performing one of the methods described herein, the data stream or sequence of signals may for example be adapted to be transferred via a data communication connection, such as the Internet.

[0403] A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein. A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0404] Further embodiments according to the invention include an apparatus or system configured to transfer (e.g. electronically or optically) a computer program for performing one of the methods described herein to a receiver. The receiver may be, for example, a computer, a mobile device, a memory device, etc. The apparatus or system may, for example, include a file server for transferring the computer program to the receiver.

[0405] In some embodiments, a programmable logic device (e.g., a field programmable gate array) may be used to perform some or all of the functions of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by any hardware apparatus.

[0406] The apparatus described herein may be implemented using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0407] The methods described herein can be performed using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer.

[0408] The above-described embodiments merely illustrate the principles of the present invention. It is understood that modifications and variations of the arrangements and details described herein will be apparent to those skilled in the art. It is therefore intended to be limited only by the scope of the immediate patent claims, and not by the specific details presented as descriptions and explanations of the embodiments herein.

[0409] References [1] ISO / IEC, ITU-T. High efficiency video coding. ITU-T Recommendation H.265 | ISO / IEC 23008 10 (HEVC), edition 1, 2013; edition 2, 2014.

[0410] [2] European Patent Application, Application No. EP 18165249.6; filed on 29 March 2018.

Claims

1. A video decoder (151) for decoding an encoded video signal comprising encoded picture data and indication data of pictures of a video to reconstruct said pictures, comprising: an interface (160) configured to receive the encoded video signal; a data decoder (170) configured to reconstruct the pictures of the video by decoding the encoded picture data using the instruction data; Including, the picture is divided into a plurality of coding regions, each coding region of the plurality of coding regions being arranged within the picture, each of the plurality of coding regions comprising two or more coding tree units of a plurality of coding tree units arranged within the picture, and using the instruction data, the data decoder (170) is configured to decode the encoded picture data in dependence on the plurality of coding regions, the instruction data comprising information of the plurality of coding regions; one or more coding regions of the plurality of coding regions include two or more coding tree units of the plurality of coding tree units, each coding region of the one or more coding regions including two or more coding tree units indicating a coding order of the two or more coding tree units of the coding region, and using the instruction data, the data decoder (170) is configured to decode the encoded picture data in dependence on the coding order of the one or more coding regions including two or more coding tree units, the instruction data including information regarding the coding order of the one or more coding regions including two or more coding tree units; A video decoder (151), wherein the instruction data includes information indicating at least one of whether exactly one slice of a plurality of slices is assigned to exactly one coding region of the plurality of coding regions and / or whether the coding region includes multiple coding tree units.

2. 2. The video decoder of claim 1, wherein the data decoder (170) is configured to decode the encoded picture data using information indicating a plurality of coding region partition positions as a plurality of coding region partition position values, each of the plurality of coding region partition position values ​​depending on a width of the picture or depending on a height of the picture, and the indication data includes the information.

3. A video encoder (101) for encoding pictures by generating an encoded video signal, comprising: a data encoder (110) configured to encode pictures of a video into encoded picture data, the data encoder (110) further configured to generate instruction data; and a signal generator (120) configured to generate the encoded video signal including the encoded picture data and the instruction data; Including, the picture is divided into a plurality of coding regions, each coding region of the plurality of coding regions being arranged within the picture, each of the plurality of coding regions including two or more coding tree units of a plurality of coding tree units arranged within the picture, the data encoder (110) is configured to encode the picture depending on the plurality of coding regions, and the data encoder (110) is configured to generate the instruction data such that the instruction data includes information of the plurality of coding regions; one or more coding regions of the plurality of coding regions include two or more coding tree units of the plurality of coding tree units, each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of the coding region, the data encoder (110) is configured to encode the picture depending on the coding order of the one or more coding regions including two or more coding tree units, and the data encoder (110) is configured to generate the instruction data such that the instruction data includes information regarding the coding order of the one or more coding regions including two or more coding tree units, A video encoder (101), wherein the instruction data indicates at least one of whether exactly one slice of a plurality of slices is assigned to exactly one coding region of the plurality of coding regions and / or, for each of the plurality of coding regions, whether the coding region includes multiple coding tree units.

4. 4. The video encoder of claim 3, wherein the data encoder is configured to generate the instruction data such that the instruction data indicates a plurality of coding region division positions as a plurality of coding region division position values, each of the plurality of coding region division position values ​​depending on the width of the picture or depending on the height of the picture.

5. 1. A method for decoding an encoded video signal comprising encoded picture data and indication data of pictures of a video to reconstruct said pictures, the method comprising: receiving the encoded video signal; reconstructing the pictures of the video by decoding the encoded picture data using the instruction data; and Including, the picture is divided into a plurality of coding regions, each coding region of the plurality of coding regions being arranged within the picture, each of the plurality of coding regions including two or more coding tree units of a plurality of coding tree units arranged within the picture, and decoding the encoded picture data using the instruction data is performed in dependence on the plurality of coding regions, and the instruction data includes information of the plurality of coding regions; one or more coding regions of the plurality of coding regions includes two or more coding tree units of the plurality of coding tree units, each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of the coding region, and decoding the encoded picture data using the instruction data is performed depending on the coding order of the one or more coding regions including two or more coding tree units, the instruction data including information regarding the coding order of the one or more coding regions including two or more coding tree units; A method according to claim 1, wherein the instruction data includes information indicating at least one of whether exactly one slice of a plurality of slices is assigned to exactly one coding region of the plurality of coding regions and / or whether the coding region includes a plurality of coding tree units.

6. 1. A method for encoding a picture by generating an encoded video signal, comprising: encoding pictures of a video into coded picture data; generating instruction data; generating the encoded video signal including the encoded picture data and the instruction data; Including, the picture is divided into a plurality of coding regions, each coding region of the plurality of coding regions being arranged in the picture, each of the plurality of coding regions including two or more coding tree units of a plurality of coding tree units arranged in the picture, encoding the picture is performed in dependence on the plurality of coding regions, and generating the instruction data is performed such that the instruction data includes information of the plurality of coding regions; one or more coding regions of the plurality of coding regions include two or more coding tree units of the plurality of coding tree units, each coding region of the one or more coding regions including two or more coding tree units indicates a coding order of the two or more coding tree units of the coding region, encoding the picture is performed depending on the coding order of the one or more coding regions including two or more coding tree units, and generating the instruction data is performed such that the instruction data includes information regarding the coding order of the one or more coding regions including two or more coding tree units; A method according to claim 1, wherein the instruction data indicates at least one of whether exactly one slice of a plurality of slices is assigned to exactly one coding region of the plurality of coding regions and / or, for each of the plurality of coding regions, whether the coding region includes a plurality of coding tree units.

7. A computer program which, when executed on a computer or signal processor, implements the method according to claim 5 or 6.

8. each coding region of the plurality of coding regions extends rectangularly within the picture; 2. The video decoder of claim 1, wherein each coding tree unit of the one or more coding tree units of each of the plurality of coding regions extends rectangularly within the picture.

9. 2. The video decoder of claim 1, wherein the data decoder is configured to decode the encoded picture data using information indicating, for one of the plurality of coding regions, a height of the coding region in coding tree units that specifies a number of coding tree units arranged vertically within one of the coding regions, and the instruction data includes the information.

10. each coding region of the plurality of coding regions extends rectangularly within the picture; The video encoder of claim 3 , wherein each coding tree unit of the one or more coding tree units of each of the plurality of coding regions extends rectangularly within the picture.

11. 4. The video encoder of claim 3, wherein the data encoder is configured to generate the instruction data such that, for one of the plurality of coding regions, the instruction data indicates a height of the coding region in coding tree units that specifies a number of coding tree units arranged vertically within one of the coding regions.

Images