JPWO2020011796A5 - - Google Patents

Description

The present invention relates to video encoding and video decoding, and in particular to encoders and decoders, encoding and decoding methods for diverse spatial partitioning of coded images.

H. H.265/HEVC is a video codec that already provides tools to improve or even enable parallelism in encoders and/or decoders. For example, HEVC helps subdivide an image into an array of independently encoded tiles. Another HEVC-assisted concept is related to WPP, according to which CTU lines of an image are processed if some minimum CTU offset is observed in processing consecutive CTU lines (CTU = Coding Tree Unit). Or the CTU lines can be processed in parallel from left to right, eg in stripes. However, it is desirable to have a video codec on hand that more efficiently assists the parallel processing capabilities of a video encoder and/or video decoder.
The next section "State of the art VCL partitioning" describes the introduction of state of the art VCL partitioning (VCL = Video Coding Layer).

Usually in video coding, the process of coding image samples requires smaller partitions in which the samples are divided into several rectangular regions for joint processing such as prediction and transform coding. Therefore, the image is divided into blocks of a certain size that is constant during the encoding of the video sequence. H. H.264/AVC uses standard fixed-size blocks of 16×16 samples, so-called macroblocks. The state-of-the-art HEVC standard (see [1]) has a coding tree block (CTB) or coding tree unit (CTU) of maximum size 64x64 samples. A detailed description of HEVC uses the more general term CTU for these types of blocks.
The CTUs are processed in raster scan order starting with the top left CTU and processing linearly through the CTUs of the image to the bottom right CTU.

Encoded CTU data is organized into a kind of container called a slice. Originally, a slice meant a segment containing one or more consecutive CTUs of an image.

The subsection "Image Segmentation Using Slices" below describes how slices are used for segmentation of coded data. From another point of view, the whole picture can also be defined as one large segment, so conventionally the term slice still applies. In addition to the coded image samples, a slice also contains additional information related to the coding process of the slice itself located in a so-called slice header.

According to the state of the art, the VCL (Video Coding Layer) also provides methods of fragmentation and spatial division. Such partitioning can be applied to video coding for various reasons, such as handling load balancing in parallelization, CTU size matching in network transmission, and error mitigation, for example, as described in more detail below. can.
The next subsection, "Image Segmentation Using Slices," describes image segmentation using slices.

H. Starting with the H.263 standard, sequences of data representing successive blocks in a particular scanning order can be organized into groups called slices. Since dependencies between CTUs in different slices of an image are usually forbidden, for example in terms of prediction and entropy coding, individual slices in an image can be reconstructed independently.

FIG. 2 illustrates image segmentation by slices in raster scan order. The size of a slice depends on the number of CTUs (Coding Tree Units) and the size of each coded CTU belonging to the slice, as shown in FIG. FIG. 2 includes 50 CTUs, eg, CTU21, CTU24 and CTU51.

The next subsection, "Image Segmentation Using Tiles," describes image segmentation using tiles with reference to FIG. FIG. 3 includes 50 CTUs, eg, CTU23, CTU27 and CTU41.

A tile is a concept introduced in HEVC, but this concept is It is very similar to Flexible Macroblock Ordering (FMO) added to H.264/AVC. The concept of tiles allows us to divide an image into several rectangular regions.

Thus, a tile is the result of dividing the original image into a specified number of rows and columns with a specified height and width, respectively, as shown in FIG. As a result, tiles in an HEVC bitstream need common boundaries that form a regular grid.
The next subsection, "Use Cases and Disadvantages of State-of-the-Art Partitioning," describes the use-cases and disadvantages of state-of-the-art partitioning with reference to FIGS.

FIG. 4 illustrates tile-based 360° video streaming with unequal resolutions. In 360° video streaming, the viewport adaptive streaming technology is called tile-based 360° video streaming and attracts attention. The main idea is to provide a 360° video composed of multiple tiles at various resolutions. Therefore, depending on the current viewport, the client downloads some tiles matching the viewport at high resolution and other tiles outside the viewport at low resolution, as shown in Figure 4. do.

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, cannot be described as tiles in the HEVC syntax. This is because these downloaded tiles do not share the same boundaries in the big picture and the granularity of the tiles in the original stream is different. See, for example, the dashed lines above and below the low resolution portion of FIG. This can only be expressed as a slice boundary in the HEVC syntax, since there is no boundary corresponding to the high resolution part on the left.

Another scenario where more flexible image segmentation is beneficial is low-latency conversational applications. Image segmentation is also used for decoding/encoding parallelization. In some cases, this parallelization is the only way to achieve real-time decoding/encoding. You can imagine a video conference scenario where two people are in the picture.
FIG. 5 shows flexible coding region partitioning.

Perhaps a good image partitioning that can be used to achieve fair load distribution (in terms of coding complexity) might be the one shown in FIG. However, in this scenario, the tiling does not have the desired flexibility as it requires a rectangular tiling grid.

Another main goal of segmentation (using slices) is error robustness. Loss of some slices of an image does not prevent the reconstruction of successfully received slices, so the partially reconstructed image is output for temporal prediction of the next image. It can be further used as a reference image in the process. 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, transmission schemes characterized by error detection and mitigation techniques at the transport layer (TCP/IP) and in which buffer stalls are the solution to transmission errors until a successful retransmission occurs, e.g., over HTTP such as MPEG DASH There is also dynamic adaptive streaming. In such scenarios, introducing additional dependencies can compromise error resilience. State-of-the-art slice and tile partitions are also inflexible in that regard.

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

The object of the present invention is 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 according to claim 115. Solved by a decoding method, a computer program according to claim 116 and an encoded video signal according to claim 117.

A video encoder is provided for encoding an image by generating an encoded video signal. The video encoder includes a data encoder configured to encode images of the video into encoded image data, the data encoder further configured to generate instruction data. Additionally, the video encoder comprises a signal generator configured to generate an encoded video signal including encoded image data and instruction data. The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions located within the image, each of the plurality of coding regions being one of a plurality of coding tree units located within the image. or a plurality of coding tree units, the data encoder is configured to encode an image in dependence on the plurality of coding regions, and the data encoder includes instruction data such that the instruction data includes information about the plurality of coding regions. is configured to generate 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 a plurality of coding regions indicates a coding order of two or more coding tree units of said coding region, and a data encoder performs one or more coding sequences including two or more coding tree units. The data encoder is configured to encode an image dependent on a coding order of regions, wherein the instruction data provides information about the coding order of one or more coding regions including two or more coding tree units. configured to generate instructional data.

Further, a video decoder is provided for decoding an encoded video signal including encoded image data and video image indication data to reconstruct a video image. A video decoder is configured to reconstruct images of the video by decoding the encoded image data using an interface configured to receive the encoded video signal and the instruction data. and a data decoder. The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions located within the image, each of the plurality of coding regions being one of a plurality of coding tree units located within the image. or multiple coding tree units, wherein the data decoder is configured to decode an encoded image in dependence on multiple coding regions, and the instruction data includes information about the multiple 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 a plurality of coding regions indicating a coding order of two or more coding tree units of said coding region, and a data decoder using indication data to determine two or more coding tree units; configured to decode encoded image data according to a coding order of one or more coding regions comprising the instruction data of the one or more coding regions comprising two or more coding tree units; Contains information about the coding order.
Additionally, a method is provided for encoding an image by generating an encoded video signal. This method
- encoding images of the video into encoded image data;
- generating instruction data; and
– includes generating a coded video signal containing coded image data and instructional data;

The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions located within the image, each of the plurality of coding regions being one of a plurality of coding tree units located within the image. or including a plurality of coding tree units, wherein the encoding of the image is performed in dependence on the plurality of coding regions, and generating the indication data is performed such that the indication data includes information about 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 a plurality of coding regions indicating a coding order of two or more coding tree units of said coding region, wherein encoding of an image is performed dependent on the plurality of coding regions to generate indication data; Doing is done so that the indication data includes information about the coding order of one or more coding regions comprising two or more coding tree units.

Further, a method is provided for decoding an encoded video signal including encoded image data and video image indication data to reconstruct a video image. This method
- receiving an encoded video signal; and - reconstructing an image of the video by decoding the encoded image data using the instruction data.

The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions located within the image, each of the plurality of coding regions being one of a plurality of coding tree units located within the image. or comprising a plurality of coding tree units and using the instruction data to decode the encoded image data dependent on the plurality of coding regions, the instruction data including information about 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 a plurality of coding regions indicating a coding order of two or more coding tree units of said coding region; decoding encoded image data dependent on a coding order of a plurality of coding regions, wherein the instruction data is a coding order of one or more coding regions including two or more coding tree units; Contains information about
Further provided is a computer program for performing one of the above methods when run on a computer or signal processor.

Further provided is an encoded video signal encoding the image, the encoded video signal comprising encoded image data and instruction data, wherein the image is divided into a plurality of coding regions, the plurality of coding regions is located in the image, each of the plurality of coding regions includes one or more coding tree units of the plurality of coding tree units located in the image, and the image is dependent on the plurality of coding regions and the instruction data includes information about the plurality of coding regions, one or more of the plurality of coding regions including two or more coding tree units of the plurality of coding tree units. , one or more coding regions comprising two or more coding tree units, each coding region indicating a coding order for the two or more coding tree units of said coding region; coded depending on the coding order of one or more coding regions containing more coding tree units, the indication data being the coding order of the one or more coding regions containing two or more coding tree units; Contains ordering information.
In the following, embodiments of the invention are described in more detail with reference to the following figures.

1 illustrates a video encoder for encoding an image by generating an encoded video signal, according to an embodiment; 1 illustrates a video decoder for decoding an encoded video signal including encoded image data and video image indication data to reconstruct a video image, according to an embodiment; 1 shows a system according to an embodiment; Fig. 3 shows image segmentation by slices in raster scan order; Fig. 4 illustrates segmentation of an image using tiles; Tile-based 360° video streaming with unequal resolution is shown. Fig. 3 shows flexible coding region division. 4 shows a bitstream containing a single image of one implicit coding region, according to an embodiment; Fig. 3 shows a bitstream containing a single image of four coding regions according to another embodiment; FIG. 4 illustrates spatial subdivision of an image with a single CA on top and three CAs on the bottom, according to an embodiment; FIG. Fig. 3 shows spatial segmentation of an image with 5 coding regions according to another embodiment; 2 shows two coding regions, one consisting of non-contiguous CTUs containing the border CTUs of the image, according to an embodiment; FIG. 3 illustrates coding regions signaling at the sub-region (CTU) level according to an embodiment; FIG. FIG. 11 illustrates CTU scan order and spatial referencing for CTU_dependency_offset_id=1, according to an embodiment; FIG. FIG. 12 illustrates another CTU scan order and spatial reference for CTU_dependency_offset_id=2, according to another embodiment; FIG. 4 illustrates coding regions in Z-scan CTU order, according to an embodiment; Figure 4 illustrates derivation of an implicit CTU scan direction according to another embodiment; 4 illustrates coding regions in different CTU scanning directions, according to an embodiment; 4 illustrates dependent coding regions with inter-region prediction option, according to an embodiment; 4 shows parallel processing of dependent coding regions according to embodiments ((A) CTU raster scan; (B) CTU diagonal scan). 4 shows execution order and inter-CA dependencies according to an embodiment ((A) Dependency Driven; (B) Lockstep). FIG. 11 illustrates a deblocking filter process at CA boundaries with respect to CA order, according to an embodiment; FIG. 4 shows a deblocking filter employing inter-CA filtering with hatched filter regions, according to an embodiment; It shows a bitstream consisting of a single image with one coding region, but the CA is fragmented into multiple transport units. A bitstream consisting of a single image of multiple coding regions is shown, but each CA has its own transport unit. A bitstream containing a single image of multiple coding regions is shown, but each CA is fragmented into multiple transport units. 4 illustrates a generalized presentation of blocks surrounded by regions, according to an embodiment; 4 shows 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; Fig. 3 shows an image that is hierarchically divided according to an embodiment, where in a first step a first division of the image is obtained in horizontal and vertical directions, and in a second step in horizontal direction; only to obtain the second division of the image. Fig. 3 shows a hierarchically segmented image according to another embodiment, wherein a first step yields a first segmentation of the image in horizontal and vertical directions, and a second step: Obtain a second division of the image in the vertical direction only. Fig. 3 shows a hierarchically segmented image according to a further embodiment, where in a first step only the horizontal direction results in a first segmentation of the image and in a second step only the vertical direction is obtained; , to obtain the second division of the image. Fig. 3 shows an image that is hierarchically segmented, in a first step only in the vertical direction, and in a second step, in the horizontal direction; only to obtain the second division of the image.

FIG. 1a shows a video encoder 101 for encoding an image by generating an encoded video signal, according to an embodiment.

Video encoder 101 comprises a data encoder 110 configured to encode images of a video into encoded image data. Further, data encoder 110 is configured to generate instruction data.

Additionally, video encoder 101 comprises a signal generator 120 configured to generate an encoded video signal including encoded image data and instruction data.

The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions located within the image, each of the plurality of coding regions being one of a plurality of coding tree units located within the image. Contains one or more coding tree units. Data encoder 110 is configured to encode an image in dependence on multiple coding regions, and data encoder 110 is configured to generate instruction data such that the instruction data includes information about the multiple coding regions. be.

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 plurality of coding regions indicates a coding order of two or more coding tree units of said coding region. Data encoder 110 is configured to encode an image dependent on the coding order of one or more coding regions comprising two or more coding tree units. Further, data encoder 110 is configured to generate the indication data such that the indication data includes information regarding the coding order of one or more coding regions including two or more coding tree units.

FIG. 1b shows a video decoder 151 for decoding an encoded video signal including encoded image data and video image indication data to reconstruct a video image, according to an embodiment.
Video decoder 151 comprises an interface 160 configured to receive encoded video signals.

Video decoder 151 further comprises a data decoder 170 configured to reconstruct images of the video by decoding encoded image data using the instruction data.

The image is divided into a plurality of coding regions, each coding region of the plurality of coding regions located within the image, each of the plurality of coding regions being one of a plurality of coding tree units located within the image. Contains one or more coding tree units. Using the instruction data, the data decoder 170 is configured to decode the encoded image data dependent on the multiple coding regions, the instruction data including information about the multiple 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 plurality of coding regions indicates a coding order of two or more coding tree units of said coding region. Using the instruction data, data decoder 170 is configured to decode encoded image data dependent on the coding order of one or more coding regions comprising two or more coding tree units. , the indication data includes information about the coding order of one or more coding regions including two or more coding tree units.

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

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.
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 an image of the video.
The next section, Versatile Image Segmentation Using Coding Regions, describes versatile image segmentation using coding regions.
The next subsection, "Coding Regions," describes coding regions.

Beyond current state-of-the-art partitioning schemes such as tiles, embodiments present the concept of a more flexible spatial domain definition, which may be called, for example, a coding domain (CA). This is an advantageous concept for spatially dividing an image into rectangular regions. Using coding regions makes the partitioning more flexible, allowing individual regions to have their own region-specific coding characteristics.

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

FIG. 6 shows a bitstream containing a single image with one implicit coding 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.

If no segmentation is applied, the image implicitly contains one coding area (CA), see FIG. This can be a default coding area with predefined functionality. FIG. 7 shows the subdivision of the image into multiple CAs.
In embodiments, data encoder 110 of FIG. 1a may be configured, for example, to divide an image into multiple coding regions.

FIG. 8 illustrates spatial segmentation of an image with a single coding area (CA) on top and three CAs on the bottom, according to an embodiment. Each square in FIGS. 8 and 9 represents a coding tree unit (CTU). 8 and 9 show CTUs having a square shape, CTUs may, for example, have a rectangular or any other shape in other examples.

As can be seen in FIGS. 8 and 9, each coding region in FIGS. 8 and 9 extends rectangularly within the image. Furthermore, in FIGS. 8 and 9, each CTU extends rectangularly in the image.

Thus, according to embodiments, each coding region of the plurality of coding regions may, for example, extend 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, for example, extend rectangularly in the image.
FIG. 9 shows spatial segmentation of an image with 5 coding regions according to another embodiment.
One of the key advantages of CA splitting is the following. Figures 8 and 9 show two examples of the new partitioning concept.

In some use cases, splitting on CA can be achieved, which is not possible with tiles, and splitting CA results in less splitting. As can be seen from the tile-based segmentation in Figure 3, to create three separate regions (Tile4, Tile5, Tile6) at the bottom of the image, three additional regions (Tile1, Tile2, Tile3) are created at the top of the image. Must be encoded. As shown in FIG. 8, using coding areas, the top area can be encoded as one coding area CA1. Also, the division shown in FIG. 9 cannot be achieved through tiles either, because CA1, CA2, and CA3 are not the same height.

According to embodiments, each of the multiple coding tree units may, for example, have a horizontal position within the image and a vertical position within the image. 8 and 9 show the horizontal positions of CTUs 1-10 and the vertical positions of CTUs 1-5. Of course, such an embodiment need not start with a position of 1 and step by 1 from one horizontal or vertical position to the next. Alternatively, other starting positions and other steps from CTU to CTU are possible. The step size from one CTU to the next for vertical positions may be different than the step size from one CTU to the next for horizontal positions.
The new partitioning of FIG. 9 can be characterized, for example, as follows.

In such embodiments, (alternative 1) the first coding region of the plurality of coding regions may include, for example, a first coding tree unit having a first vertical position, which is the plurality of coding regions and the third coding tree unit of the first coding region is the same as the second vertical position of the different second coding tree unit of the different second coding region of the second coding region. and the fourth coding tree unit in the second coding region has a third vertical position different from the vertical position of any other coding tree unit in the first coding region. It has a fourth vertical position that also differs from the vertical position.

Or (alternative 2) a first coding region of the plurality of coding regions may include, for example, a first coding tree unit having a first horizontal position, which is a different second coding region of the plurality of coding regions. Identical to a second horizontal position of a different second coding tree unit of the coding region, and the third coding tree unit of the first coding region corresponds to any other coding tree of the second coding region. The fourth coding tree unit of the second coding region has a third horizontal position that also differs from the horizontal position of the unit, and the fourth coding tree unit of the second coding region differs from the horizontal position of any other coding tree unit of the first coding region. It has a fourth horizontal position.
FIG. 9 satisfies alternative 1.

CA2 is composed of CTU91. The vertical position of CTU 91 is three. CA4's CTU 96 is also at vertical position 3; The vertical position of CTU 92 in CA2 is two. None of the CTUs in CA4 are at vertical position 2 (because the vertical positions of CA4 are in the range 3-5). In addition, the CTU 97 of CA4 is at vertical position 4. None of the CTUs in CA2 are at vertical position 4 (because the vertical positions of CA2 range from 1 to 3).
In contrast, FIG. 8 does not meet alternative 1 and does not meet alternative 2.
Alternative 1:

Only CA2, CA3, and CA4 have the same vertical position (ranging from 3 to 5). CA1 does not have the same vertical position as any other coding region. However, CA2 has no vertical position different from any other vertical position of coding areas CA3 or CA4. The same is true for CA2, CA4 and CA2, CA3 respectively for CA3 and CA4.
Alternative 2:
CA2, CA3, and CA4 do not have CTUs in the same horizontal position.

In contrast, CTU 81 of CA1 is at the same horizontal position (3) as CTU 86 of CA2. In addition, none of the CA2 CTUs are at the horizontal position 6 of the CA1 CTU 82, since the horizontal positions of CA2 range from 1 to 4. However, since the horizontal positions of the CTUs of CA2 range from 1 to 4 and the horizontal positions of the CTUs of CA1 range from 1 to 10, the CA2 There is no CTU for
For similar reasons, the same is true for CA3 and CA4 with respect to CA1.
Therefore, the partitioning of FIG. 8 does not satisfy alternative 1 and does not satisfy alternative 2.

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

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

In addition to segment placement, embodiments provide a new flexible processing or scanning order of CTUs within the coding region. Details of this approach are provided in the sub-subsection "CTU Scanning Order".

One other invented feature is that within a single image, one CA is independent and/or dependent from other coding regions, as described in the sub-section "Dependent Coding Regions". It is what you can do.

The combined use of the newly proposed methods opens up new opportunities for high-level parallelism. Parallel processing of the spatial image domain can be performed in a more efficient manner, as detailed in the subsection "Parallel Processing of the Coding Domain".
Aspects of error resilience are described in the sub-section "Aspects of Error Resilience."
A summary of the above concepts:

According to embodiments, each coding region of a plurality of coding regions may exhibit spatial characteristics including a position, width and height of said coding region, wherein said width and height of said coding region are defined by a rectangle of said coding region. and the position of the coding region depends on the position of the coding region in the image.

In embodiments, a first height of a first one of the plurality of coding regions may be different than a second height of a second one of the plurality of coding regions, for example. Alternatively, a first width of a first one of the plurality of coding regions is different than a second width of a second one of the plurality of coding regions.

According to embodiments, the data encoder 110 may be configured to generate said indication data, for example, such that the information about the plurality of coding regions includes information about the spatial characteristics of each coding region of the plurality of coding regions. .

In embodiments, data encoder 110 may be configured to generate indication data such that, for example, the information about the plurality of coding regions includes the position, width, and height of each coding region of the plurality of coding regions. .

According to an embodiment, the data encoder 110 may, for example, encode an image of each of the plurality of coding regions independently of encoding image data of image portions of any other of the plurality of coding regions. It may be configured to encode the image data of the portion to obtain encoded image data.

In an embodiment, data encoder 110 may encode the image by, for example, encoding image data for portions of the image within each coding region of the plurality of coding regions to obtain encoded image data. Can be configured. Data encoder 110 may, for example, encode the plurality of coding regions such that encoding image data of at least one of the plurality of coding regions depends on encoding image data of at least another one of the plurality of coding regions. may be configured to encode image data of at least one of the image portions of the coding regions.

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

According to an embodiment, data encoder 110, for example, for each one of the one or more coding regions, converts the scan order from two or more scan orders for each one of the one or more coding regions. The selection may be configured to determine the coding order.

In an embodiment, signal generator 120 produces an encoded video signal such that, for example, the encoded video signal comprises a bitstream, and the bitstream comprises encoded image data and instruction data. can be configured as

Similarly, according to an embodiment, each coding region of a plurality of coding regions may exhibit spatial characteristics including position, width and height of said coding region, wherein the width and height of said coding region are determined by said coding region. Depending on the rectangular extension of the region, the position of the coding region depends on the position of the coding region within the image. Data decoder 170 may, for example, be configured to decode the encoded image data depending on the spatial characteristics of multiple coding regions.

In embodiments, a first height of a first one of the plurality of coding regions may be different than a second height of a second one of the plurality of coding regions, for example. Or the first width of the first one of the plurality of coding regions is different than the second width of the second one of the plurality of coding regions.

According to embodiments, data decoder 170 may be configured to decode the encoded image data using information in the indicative data regarding the spatial properties of multiple coding regions.

According to an embodiment, data decoder 170 extracts information in the indication data of the plurality of coding regions, for example, the information about the plurality of coding regions includes the position, width and height of each coding region of the plurality of coding regions. may be configured to decode image data encoded using .

According to an embodiment, data decoder 170 may, for example, decode the code of each of the plurality of coding regions independently from decoding the encoded image data of any other of the plurality of coding regions. may be configured to decode encoded image data.

According to embodiments, the data decoder 170 may be configured, for example, to decode encoded image data of at least one of the plurality of coding regions, wherein the encoding of the at least one of the plurality of coding regions is Decoding the encoded image data depends on decoding encoded image data in at least another one of the plurality of coding regions.

According to an embodiment, data decoder 170 decodes image data encoded using a respective one coding order of one or more coding regions, eg, comprising two or more coding tree units. wherein the coating order of each one of the one or more coding regions is indicated by instructional data.

According to embodiments, data decoder 170 decodes image data encoded using scan order indications from, for example, two or more scan orders for each one of one or more coding regions. and the instruction data may include a scanning order instruction for each one of the one or more coding regions.

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

General information about coding regions is concentrated in so-called coding region sets (CAS). CAS can be solved outside the VCL with a high-level set of parameters, affecting the entire sequence or parts of the sequence, eg, images.
x = video, sequence, image...

Table 2-1

coding_area_explicit_positioning_flag If true, coding_area_top_left_CTU_address is present in the bitstream, otherwise default implicit CA positioning is used num_coding_areas_minus1 Number of coding areas signaled in the bitstream

dependent_coding_areas_enabled_flag If true, indicates that the CAs following the bitstream are mutually dependent in the order in which they appear in the bitstream. Otherwise, CA is treated as an independent domain.

coding_areas_CTU_wise_dependent_flag If true, indicates that CTU dependencies between adjacent CAs are handled in per-CTU processing that interleaves CA processing. Otherwise, CAs are processed individually in a fixed order.

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, a fixed length code derived from ceil(log2(num_coding_areas_minus1+1)). Otherwise, the default slice syntax is present in the bitstream.

coding_area_CTU_scan_flag If true, indicates that the CTU scan parameter is present in the bitstream. A flexible CTU scanning approach is described in the subsection "CTU Scanning Order".
coding_area_CTU_scan_type_idx Mapped to scan type table (raster scan, diagonal scan).

coding_area_CTU_scan_start_left_flag[i] Present if the ith CA consists of multiple CTUs per CTU line, if true indicates to start the CTU scan at the leftmost CTU in the CA. Otherwise, the i-th CA CTU scan starts from the rightmost CTU.

coding_area_CTU_scan_start_top_flag[i] Present if the i-th CA consists of multiple CTUs per CTU column, if true indicates whether to start the CTU scan at the top CTU row in the CA. Otherwise, the i-th CA's CTU scan starts at the CA's CTU bottom.

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

In an embodiment, the data encoder 110 is configured to generate the indication data, eg, such that the indication data may include information for each coding region, eg, whether the upper left coding tree unit is addressed. can be A particular example could be, for example, the coding_area_explicit_positioning_flag. If true, coding_area_top_left_CTU_address is present in the bitstream. Otherwise, default implicit CA positioning is used.

According to an embodiment, the data encoder 110 may, for example, determine whether the indication data is 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. may be configured to generate instructional data such that it may include information about A specific example may be, for example, the num_coding_areas_minus1 field described above.

According to an embodiment, data encoder 110 may, for example, indicate whether the data indicates whether one of the plurality of coding regions depends on another one of the plurality of coding regions. may be configured to generate indication data to indicate for said one of a plurality of coding regions following said another one of . A particular example may be, for example, dependent_coding_areas_enabled_flag, which when true may, for example, indicate that the CAs following the bitstream are dependent on each other in the order in which they appear in the bitstream; , are treated as independent regions.

According to an embodiment, the data encoder 110, for example, indicates whether 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. may be configured to generate the instructional data. A specific example could be, for example, the coding_area_no_slices_flag mentioned above.

According to an embodiment, the data encoder 110 may, for example, specify whether the indication data includes information on how to scan within each of one or more coding tree units of the plurality of coding regions. , may be configured to generate the indicative data. A specific example may be, for example, the coding_area_CTU_scan_flag mentioned above.

According to an embodiment, data encoder 110 generates instruction data such that, for example, the instruction data indicates how to scan within each of the one or more coding tree units of the plurality of coding regions. can be configured. A specific example could be, for example, coding_area_CTU_scan_type_idx, which maps to a scan type table. The scan type can be, for example, raster scan, and/or, for example, diagonal scan.

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

According to an embodiment, data encoder 110 determines whether coding tree unit scanning starts at the leftmost coding tree unit or whether coding tree unit scanning starts at the rightmost coding tree unit, for example, for one of the plurality of coding regions. It may be configured to generate the indication data such that the indication data indicates whether to start with the tree unit. A specific example may be, for example, coding_area_CTU_scan_start_left_flag[i] above.

According to an embodiment, data encoder 110 determines, for example, for one of a plurality of coding regions, whether the coding tree unit scan starts from the top coding tree unit row of the coding region or whether the coding tree unit The scanning may be configured to generate indication data such that the indication data indicates whether to start from the bottom coding tree unit row of the coding region. A specific example may be, for example, coding_area_CTU_scan_start_top_flag[i] above.

According to an embodiment, data encoder 110 determines whether the coding tree unit scan is started horizontally or the coding tree unit scan is started vertically, for example, for one of the plurality of coding regions. may be configured to generate the instruction data such that the instruction data indicates the . A particular example may be, for example, coding_area_CTU_scan_direction_flag[i], which is present, for example, if the i-th CA contains at least 2 CTU rows and 2 CTU columns, indicating the starting scan direction of the CTU scan. obtain. If it is true than the scanning direction of the i-th CA, it may eg start in the horizontal direction, otherwise the scanning may eg be a vertical scanning.

Similarly, according to an embodiment, data decoder 170 is configured to decode the encoded image data using, for example, information in each coding region regarding whether the upper left coding tree unit is addressed. and the instruction data may include, for example, said information.

According to an embodiment, data decoder 170 uses information regarding, for example, the number of coding regions or the number of coding regions minus one, or the number of coding regions minus two. and the instruction data may include, for example, said information.

According to an embodiment, data decoder 170 determines, for example, whether one of the plurality of coding regions depends on another one of the plurality of coding regions. may be configured to decode the encoded image data using information indicative of one of the plurality of coding regions following, the instruction data may include, for example, said information.

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

According to an embodiment, data decoder 170 may, for example, use information as to whether the indication data includes information as to how to scan within each of one or more coding tree units of, for example, multiple coding regions. It may be configured to decode encoded image data, and the instruction data may, for example, include said information.

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

According to an embodiment, data decoder 170 is configured, for example, for each of multiple coding regions to decode encoded image data using information indicating whether the coding region includes multiple coding tree units. and the instruction data may include, for example, said information.

In an embodiment, data decoder 170 determines whether coding tree unit scanning starts at the leftmost coding tree unit, or whether coding tree unit scanning starts at the rightmost coding tree unit, for example, for one of the plurality of coding regions. may be configured to decode encoded image data using information indicating whether to start with, the indicating data may include, for example, said information.

In an embodiment, data decoder 170 determines, for example, for one of a plurality of coding regions, whether coding tree unit scanning starts at the top coding tree unit row of the coding region, or whether coding tree unit scanning It may be configured to decode the encoded image data using information indicating whether to start at the bottom coding tree unit row of the coding region, and the indication data may include, for example, said information. .

In an embodiment, data decoder 170 determines, for example, whether coding tree unit scanning starts in the horizontal direction or whether coding tree unit scanning starts in the vertical direction, for one of the plurality of coding regions. may be configured to decode encoded image data using information indicative of, the instruction data may, for example, include said information.
The Coding Region Size and Placement subsection below describes the size and placement of the coding region.

It is important to show how the coding regions are arranged in the image. Depending on the application, different targets are pursued, such as CA size and position, which may affect the desired flexibility in image segmentation. Layouts can also be sent in high-level sections of the bitstream in order to use temporarily fixed CA layouts or adjust layouts over time depending on content.

For example, in the example provided in the 360° Video Streaming subsection "Image Division Using Tiles", CA is typically constant across a CVS (coding video sequence) and its size is e.g. It is only necessary to accommodate partitions generated from different resolutions of the same content, as shown in . In such cases, the most appropriate place for CA placement signaling is the high-level Syntax structure (see, for example, HEVC VPS, SPS, PPS).

However, in other cases, such as the subsection "Segmenting Images Using Tiles" for load balancing (such as video conferencing scenarios), dynamic per-image splitting may be desirable. Furthermore, it may be found that the initial configuration chosen for CA is not optimal, and so may require changes in the image (during encoding) of the segmentation. In such cases where CA placement is not known a priori, at the VCL (Video Coding Layer within the Slice Payload), as described in sub-subsubsection "Embodiment C", the signaling is ) takes precedence over high-level signaling.
In sub-sub-section "Embodiment A" below, the signaling of position and size per sample or unit is described.
Explicit CA positioning using the CTU start address to select the corresponding region:

図１０は、実施形態による、画像境界ＣＴＵを含む１つが非連続ＣＴＵからなる、２つのコーディング領域を示している。 Table 2-2

FIG. 10 shows two coding regions, one consisting of a non-contiguous CTU containing an image boundary CTU, according to an embodiment.

In principle, the above syntax num_coding_areas_minus2 can define all but one CA and have the last CA as the remainder not covered by the previous CA. However, this allows the CA to not contain consecutive CTUs, as shown in FIG. 10, which can complicate the encoding/decoding process somewhat.

Therefore, we should add constraints to forbid such cases and require syntax to satisfy some constraints. For example, given four CTUs (CTU _a , CTU _b , CTU _c , CTU _d ) corresponding to the upper left, upper right, lower left and lower right CTUs of CA, CTU _b _addr−CTU _a _addr=CAWidthInNumCTUs_minus1 and CTU _c ＿ａｄｄｒ－ＣＴＵ _ａ ＿ａｄｄｒ＝ＣＡＨｅｉｇｈｔＩｎＮｕｍＣＴＵｓ＿ｍｉｎｕｓ１すると、すべてのＣＴＵおよび次のＣＴＵ＿ａｄｄｒｅｓｓを有するもののみが、残りのＣＡ ＣＴＵ _ｘ ＿ａｄｄｒ＝ＣＴＵ _ａ ＿ａｄｄｒ＋ｊ＋ｋ＊（ＣＡＷｉｄｔｈＩｎＮｕｍＣＴＵｓ＿ｍｉｎｕｓ１＋１）、ｊ＝０、ＣＡＷｉｄｔｈＩｎＮｕｍＣＴＵｓ＿ｍｉｎｕｓ１、およびｋ＝０、ＣＡＨｅｉｇｈｔＩｎＮｕｍＣＴＵｓ＿ｍｉｎｕｓ１にwill belong.

Alternatively, a syntax element (such as "non_contiguous_remaining_coding_unit_enabled_flag") can be added that can indicate/constrain CAs to meet such conditions. Therefore, some profiles may mandate that the flag is not enabled to prevent the added complexity of non-consecutive CA.

According to an embodiment, data encoder 110 determines, for example, whether the indication data indicates whether at least one of the plurality of coding regions surrounds another one of the plurality of coding regions, or whether any of the plurality of coding regions surrounds another of the plurality of coding regions. may be configured to generate the indication data to include non-contiguous information indicating whether to not enclose one of the . FIG. 10 is a specific example, showing two coding areas CA1, CA2. The outer coding area CA1 surrounds the inner coding area CA2.

In FIG. 10, CA1 surrounds CA2. A non_contiguous_remaining_coding_unit_enabled_flag can be used to provide the respective indication .

Similarly, in an embodiment, data decoder 170 determines whether, for example, at least one of the plurality of coding regions surrounds another one of the plurality of coding regions, or any of the plurality of coding regions is a coding region. It may be configured to decode the encoded image data using discontinuity information indicating whether to not surround another one of them, the indication data including said information.

The syntax in the table above allows flexible signaling with CAs that are not multiples of the largest coding unit (eg 128x128). This is useful for some applications. However, using sample units to signal CA may use many bits. Alternatively, signaling can be performed in the CTU to save bits. The problem is that we cannot signal sizes that are not multiples of the CTU. The suggested syntax below can solve this problem with some additional information.

Table 2-3

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

However, if the CA size is not a multiple of the maximum CTU size (i.e. the last CTU in the row or column is smaller), the CA may have smaller CTUs than the other CAs, so the row or column This can lead to images with different numbers of CTUs per image. Since the stores of variables used for prediction in images are usually addressed by CTU addresses, and different numbers of CTUs per row or column can make CTU addressing infeasible or too complicated, Such mismatch may be undesirable. Therefore, whenever a CA ends before a complete CTU (or the CTU of the largest-sized CTU), it aligns in a dimension (horizontal or/and vertical) in which no other adjacent CA constitutes a complete CTU. should add a constraint that should be

Implicit positioning recursively starting from the leftmost position of the topmost CTU row not covered by the coding region. In other words, for example, if the coding_area_explicit_positioning_flag is set to 0 as shown in Table 2-4, the starting address of the CA is not indicated, only the width and height are indicated, and the decoder is 1 . . The starting address of the i-th CA must be derived by looking for the smallest CTU address not yet covered by the (i-1)-th CA.

In an embodiment, data encoder 110 determines whether, for example, for a coding region, indication data is indicated with a starting address indicating one of one or more coding tree units of said coding region, or one of said coding region. It may be configured to generate indication data to indicate whether a starting address indicative of said one of the one or more coding tree units is not indicated. A specific example may be, for example, the coding_area_CTU_start_address mentioned above.

Similarly, according to an embodiment, data decoder 170 determines, for example, whether, for a coding region, a starting address indicating one of one or more coding tree units of said coding region is indicated, or It may be configured to decode encoded image data using an indication of whether a starting address indicative of said one of the one or more coding tree units is not indicated. If no starting address indicating said one of the one or more coding tree units of said coding region is indicated, data decoder 170 may determine the coding height of said coding region depending on, for example, the width of said coding region. Depending and depending on a coding region scanning direction of said coding region, it may be arranged to determine a starting address indicative of said one of one or more coding tree units of said coding region.

The syntax for both tables above consists of coding_area_start_address[i]. This in principle simplifies the operation of the parser, but is somewhat "redundant" information that can be simply derived from the signal size. So 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 region" .

For higher order image resolutions, additional step sizes may help scale the width and height of the CA partition, and the location code if available.

最終的なＣＡの位置とサイズは、次のように導出されるものとする。 Table 2-4

The final CA position and size shall be derived as follows.

coding_area_width_in_CTU=coding_area_width_in_units*(coding_area_unit_scaling_factor_minus1+1)

coding_area_height_in_CTU = coding_area_height_in_units * (coding_area_unit_scaling_factor_minus1+1)

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)

*((coding_area_start_address_in_units%pic_width_in_units)+(coding_area_CTU_start_address_unit/pic_width_in_units) *picture_width_in_CTU))

Table 2-5

coding_area_scaling_factor_minus1 Scaling factor used to scale CA position and size parameters

coding_area_top_left_CTU_address_in_units[i] Address of CTU at top left boundary of CA. Addresses are specified in units and must be scaled according to coding_area_scaling_factor_minus1+1 to get the CTU address.

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

The height of CA in Coding_area_height_in_units[i] units shall be scaled according to coding_area_scaling_factor_minus1+1 to obtain the width of CA in CTU.
To summarize the above concepts:

In an embodiment, data encoder 110, for example, for one of the plurality of coding regions, uses a coding region width in coding tree units that specifies the number of horizontally arranged coding tree units in one of the coding regions. may be configured to generate the instruction data such that the instruction data indicates the . A specific example may be, for example, the coding_area_width_in_CTU mentioned above.

According to an embodiment, the data encoder 110, for example, for one of a plurality of coding regions, uses a coding region of coding tree units that specifies the number of vertically arranged coding tree units within one of the coding regions. may be configured to generate the indication data such that the indication data indicates the height of the . A particular example may be, for example, the coding_area_height_in_CTU mentioned above.

In an embodiment, data encoder 110 may, for example, for a coding region of a plurality of coding regions, determine if the last coding tree unit in the coding region in the horizontal direction is different from the coding region that precedes the coding tree unit in the horizontal direction. may be configured to generate the indication data such that the indication data indicates whether it is less than the coding tree unit of .

In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in the horizontal direction, and the last coding tree unit in the horizontal direction is one of the last coding tree units in the horizontal direction. One. If the last coding tree unit in the horizontal direction in the coding region is less than the another coding tree unit in the coding region preceding the last coding tree unit in the horizontal direction, then a plurality of last coding tree units in the horizontal direction Each of the coding tree units can have the same width, for example.

According to an embodiment, the data encoder 110 may, for example, for a coding region of a plurality of coding regions, determine if the vertically last coding tree unit within the coding region is the coding tree unit of the coding region that vertically precedes the coding tree unit. It may be configured to generate the indication data such that the indication data indicates whether it is less than another coding tree unit.

In a particular embodiment, the coding region may include, for example, a plurality of vertically last coding tree units, wherein the vertically last coding tree unit is one of the plurality of vertically last coding tree units. One. if the last coding tree unit in the vertical direction in the coding region is less than the another coding tree unit in the coding region preceding the last coding tree unit in the vertical direction, then a plurality of last vertical coding tree units Each of the coding tree units can have the same height, for example.

Similarly, in an embodiment, data decoder 170 may, for example, for one of a plurality of coding regions, specify the number of coding tree units arranged horizontally within one of the coding regions. It may be configured to decode encoded image data using information indicative of the coding region width, and the indication data may, for example, include said information.

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

In an embodiment, data decoder 170 may, for example, determine, for a coding region of a plurality of coding regions, that the last coding tree unit in the coding region in the horizontal direction is different from the coding region that precedes the coding tree unit in the horizontal direction. The encoded image data may be decoded using information indicating whether the coding tree unit is smaller than the coding tree unit, and the indication data may include, for example, said information.

In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in the horizontal direction, and the last coding tree unit in the horizontal direction is one of the last coding tree units in the horizontal direction. One. If the last coding tree unit in the horizontal direction in the coding region is less than the another coding tree unit in the coding region preceding the last coding tree unit in the horizontal direction, then a plurality of last coding tree units in the horizontal direction Each of the coding tree units can have the same width, for example.

According to an embodiment, data decoder 170 may, for example, for a coding region of a plurality of coding regions, determine if the vertically last coding tree unit within said coding region is the coding region of said coding region that vertically precedes said coding tree unit. Information indicating whether it is smaller than another coding tree unit may be used to decode the encoded image data, and the indication data may, for example, include said information.

In a particular embodiment, the coding region may include, for example, a plurality of vertically last coding tree units, wherein the vertically last coding tree unit is one of the plurality of vertically last coding tree units. is one. if the last coding tree unit in the vertical direction in the coding region is less than the another coding tree unit in the coding region preceding the last coding tree unit in the vertical direction, then a plurality of last vertical coding tree units Each of the coding tree units can have the same height, for example.
The following sub-sub-sub-section "Embodiment B" describes hierarchical sub-division by partitioning.
In particular, two variations of hierarchical CA partitioning are provided.

The first method is to hierarchically transmit the coding region division position values in scaled CTU units. Here, the division granularity depends on the CTU size.

Table 2-6

Table 2-7

A second variation of hierarchical CA partitioning is to send the coding region partitioning position values in generally uniform units. The dimension of the unit can be derived by scaling the original image size already parsed by a certain factor. This is also signaled in the parameter set. Here, the granularity of division is various and varies depending on the size of the unit selected on the encoder side.

Table 2-8

Table 2-9

The final CA position and size 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

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

An advantage of hierarchical CA partitioning is that in some partitioning scenarios, this method may require fewer bits for signaling. In addition, some alignment is performed between CAs or groups of CAs that share some boundaries. This may be beneficial for some implementations.
Signaling is only possible in RAP and can be constrained to be inherited from it for subsequent images.

Additional flag in the bitstream indicating that the layout will be retransmitted. Otherwise, a previous CA layout is used that can be further selected by the bitstream transmission index from the set of previously transmitted CA layouts.
To summarize the above:

According to an embodiment, the data encoder 110, for example, the information of the multiple coding regions is divided once or multiple times to obtain multiple coding regions by dividing the image once or multiple times. It can be configured to generate the instruction data to include information about.
In embodiments, the data encoder 110 may be configured to generate the indication data, for example, such that the indication data indicate multiple coding region division positions.

According to embodiments, data encoder 110 may be configured to generate the indication data such that, for example, the indication data indicates a plurality of coding region division positions as an ordered sequence.

In an embodiment, the data encoder 110 may be configured to generate the instruction data such that the instruction data indicates the plurality of coding region division positions as the plurality of coding region division position values, for example, the plurality of coding region division position values. Each depends on the width of the image or depends on the height of the image.

According to an embodiment, the data encoder 110 hierarchically divides the image into multiple coding regions, for example, the information of the multiple coding regions, by hierarchically dividing the image one or more times. The instruction data can be configured to include information on how to split one or more times.

Similarly, according to an embodiment, data decoder 170 encodes using information about 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 include, for example, said information.

In an embodiment, the data decoder 170 may be configured to decode encoded image data using, for example, information indicating a plurality of coding region division positions, and the instruction data may include, for example, said information. .

In an embodiment, data decoder 170 may be configured to decode encoded image data using, for example, information indicating a plurality of coding region division positions as an ordered sequence, wherein the instruction data may be, for example, Said information may be included.

In an embodiment, the data decoder 170 is configured, for example, to decode encoded image data using information indicating the coding region division positions as coding region division position values, the coding region division positions Each of the split position values depends on the width of the image or depends on the height of the image, and the indication data may include said information, for example.

According to an embodiment, data decoder 170 may be configured to decode encoded image data using information about multiple coding regions, and divide the image into multiple coding regions by hierarchically dividing the image one or more times. It includes information about how to divide the image hierarchically one or more times to obtain coding regions, and the instruction data may include, for example, said information.

Further examples will now be presented. Data encoder 110 may, for example, ensure that the information of the multiple coding regions includes information about how to divide the image one or more times to obtain multiple coding regions by dividing the image one or more times. , which can be configured to generate instruction data to

In particular, a further example is that the data encoder 110 may, for example, divide the information of the multiple coding regions hierarchically one-by-one through the image to obtain multiple coding regions by hierarchically dividing the image one or more times. It is presented as being configurable to generate instructional data to include information on how to divide one or more times.

The data decoder 170 also converts the encoded image data using information about how to divide the image one or more times to obtain multiple coding regions by dividing the image one or more times. Further examples are given as to what can be configured to decode and the instructional data includes, for example, said information.

In particular, further examples are provided, e.g., how data decoder 170 can be configured to decode encoded image data using information about multiple coding regions so that the image can be processed one or more times. It includes information about how to hierarchically divide the image once or multiple times to obtain multiple coding regions by hierarchically dividing it once, and the instruction data may include, for example, said information.

Yet a further example is how the encoded video signal instruction data divides the image once or more times to obtain multiple coding regions, for example by dividing the image once or more times. It is presented as to how it can be shown.

More particularly, further examples are presented for methods of hierarchically dividing an image one or more times to obtain multiple coding regions by hierarchically dividing the image one or more times. .
In some embodiments, data encoder 110 and/or data decoder 170 may, for example,
- in a first step, split the image horizontally and vertically to obtain a first split of the image;
- In a second step, it may be arranged to split the first division of the image horizontally (only) to obtain a second division of the image.

In FIG. 27, the image is hierarchically split horizontally and vertically in a first step to obtain a first split (eg, tile split) of the image (FIG. 27, step 1), and , in a second step only horizontally to obtain a second division of the image (eg a division of bricks) (FIG. 27, step 2).
In some other embodiments, data encoder 110 and/or data decoder 170 may, for example,
- in a first step, split the image horizontally and vertically to obtain a first split of the image;
- In a second step, it may be arranged to vertically (only) divide the first division of the image to obtain a second division of the image.

In FIG. 28, the image is hierarchically split horizontally and vertically in a first step to obtain a first split (eg, tile split) of the image (FIG. 28, step 1), and , in a second step only the vertical direction is split to obtain a second split of the image (eg a split of bricks) (FIG. 28, step 2).
In some further embodiments, data encoder 110 and/or data decoder 170 may, for example,
- in a first step, split the image horizontally (only) to obtain a first split of the image;
- In a second step, it may be arranged to vertically (only) divide the first division of the image to obtain a second division of the image.

In FIG. 29, the image is hierarchically partitioned horizontally only in a first step to obtain a first partition (eg, tile partition) of the image (FIG. 29, step 1); In step 2, only the vertical direction is split to obtain the second split of the image (eg split of bricks) (Fig. 29, step 2).
In some still further embodiments, data encoder 110 and/or data decoder 170 may, for example,
- in a first step, split the image vertically (only) to obtain a first split of the image;
- In a second step, it may be arranged to split the first division of the image horizontally (only) to obtain a second division of the image.

In FIG. 30, the image is hierarchically partitioned in a first step only vertically to obtain a first partition (eg, tile partition) of the image (FIG. 30, step 1); In step 2, only the horizontal direction is split to obtain the second split of the image (eg splitting of bricks) (Fig. 30, step 2).

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

An image can be divided into, for example, one or more tile rows and one or more tile columns. A tile is a series of CTUs covering a rectangular area of the image.
A tile is divided into one or more bricks, each brick consisting of a number of rows of CTUs within the tile.
Tiles that are not divided into multiple bricks are also called bricks. However, bricks, which are true subsets of tiles, are not called tiles.
A slice contains the number of tiles of an image or the number of bricks of a tile.

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

FIG. 26 shows an example of an image divided into tiles, bricks and rectangular slices. In it, the image has 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, the bottom right tile contains 3 bricks), and 4 rectangular slices.

In the following, if brick_split_flag[i] equals 1, we specify that the i-th tile is split into two or more bricks. If brick_split_flag[i] is equal to 0, it specifies that the i-th tile is not split into more than one brick. If not present, the value of brick_split_flag[i] is assumed to be equal to zero.

Further below, num_brick_rows_minus1[i]+1 specifies the number of bricks dividing the i-th tile 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 assumed to be equal to 0. Otherwise, if uniform_brick_spacing_flag[i] equals 1, the value of num_brick_rows_minus1[i] is inferred (eg, as specified below for CTB raster scan, tile scan, and brick scan processes).

Therefore, 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 divided into two or more bricks, which may consist, for example, of several columns of CTUs.
In more detail, the CTB raster scan, tile scan, and brick scan processes may be implemented, for example, as follows.

A list colWidth[i] of i ranging from 0 to num_tile_columns_minus1 is derived specifying the width of the ith tile column in units of CTB, and if uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is guessed.
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]
}
}

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 CTB, and if uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is inferred to.
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]
}
}

A list tileColBd[i] of i ranging from 0 to num_tile_columns_minus1+1, specifying the location of the i-th tile column boundary in units of CTB, 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)

A list tileRowBd[j] of j ranging from 0 to num_tile_rows_minus1+1, specifying the location of the boundary of the jth tile row in units of CTB, 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)

The variable NumBricksInPic specifies the number of bricks in the image that reference the PPS, and a list of brickIdx ranging from 0 to NumBricksInPic-1 BrickColBd[brickIdx], BrickRowBd[brickIdx], BrickWidth[brickIdx], and Given the position of the vertical brick boundary in units of CTB, the position of the horizontal brick boundary in units of CTB, the width of the brick in units of CTB, and the height of the brick in units of CTB, and For each i ranging from 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.

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

A list CtbAddrRsToBs[ctbAddrRs] of ctbAddrRs ranging from 0 to PicSizeInCtbsY-1, specifying the conversion of CTB raster-scan CTB addresses to brick-scan CTB addresses of the image, 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]
}

A list CtbAddrBsToRs[ctbAddrBs] of ctbAddrBs ranging from 0 to PicSizeInCtbsY-1, specifying the conversion from brick-scan CTB addresses to CTB raster-scan CTB addresses of the image, is derived as follows.
for (ctbAddrRs=0; ctbAddrRs<PicSizeInCtbsY; ctbAddrRs++) (6-7)
CtbAddrBsToRs[CtbAddrRsToBs[ctbAddrRs]]=ctbAddrRs

The list BrickId[ctbAddrBs] of ctbAddrBs ranging from 0 to PicSizeInCtbsY-1 is derived as follows, specifying the conversion of brickscan CTB addresses to brick IDs.
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

A list NumCtusInBrick[brickIdx] of brickIdx ranging from 0 to NumBricksInPic-1 is derived as follows, specifying a transformation from brick index to number of CTUs of bricks.
for (i=0; i<NumBricksInPic; i++) (6-9)
NumCtusInBrick[i]=BrickWidth[i]*BrickHeight[i]

A list of brickIdx ranging from 0 to NumBricksInPic-1 FirstCtbAddrBs[brickIdx] is derived as follows, specifying the brick ID to CTB address conversion at the brick scan of the brick's first CTB.

for (ctbAddrBs=0, brickIdx=0, brickStartFlag=1; ctbAddrBs<PicSizeInCtbsY; ctbAddrBs++) {
if (brickStartFlag) {
FirstCtbAddrBs[brickIdx]=ctbAddrBs(6-10)
brick Start Flag = 0
}
brickEndFlag=(ctbAddrBs==PicSizeInCtbsY-1)||
(BrickId[ctbAddrBs+1]!=BrickId[ctbAddrBs])
if(brickEndFlag) {
brickIdx++
brick Start Flag=1
}
}
Image parameter set RBSP syntax

上記のコードでは、画像パラメータセットＲＢＳＰセマンティクスは、例えば次のように定義できる。

In the code above, the image parameter set RBSP semantics can be defined, for example, as follows.

pps_pic_parameter_set_id identifies the PPS for reference by other syntax elements. The value of pps_pic_parameter_set_id shall range from 0 to 63.

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 range from 0 to 15.

If output_flag_present_flag is 1, it indicates that the pic_output_flag syntax element is present in the slice header referencing the PPS. If output_flag_present_flag is 0, it indicates that the pic_output_flag syntax element is not present in the slice header referencing the PPS.

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

Note - if no further bricks are split within the tile, the entire tile is called a brick. If the image contains only one tile with no further brick divisions, it is called a single brick.
The value of single_tile_in_pic_flag shall be the same for all PPSs activated in CVS.

If uniform_tile_spacing_flag is 1, it specifies that tile row boundaries, like tile column boundaries, are uniformly distributed across the image and are signaled using the syntax elements tile_cols_width_minus1 and tile_rows_height_minus1. If uniform_tile_spacing_flag is 0, tile row boundaries as well as tile column boundaries may or may not be uniformly distributed across the image, and syntax elements num_tile_columns_minus1 and num_tile_rows_minus1, and syntax element pair tile_column_width_minus1[i] and tile_ht_ht_ht_ht_ht Specifies that it may or may not be signaled using the list of [i].
If not present, the value of uniform_tile_spacing_flag is assumed to be equal to one.

tile_cols_width_minus1+1 specifies the width, in units of CTB, of tile columns except for 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 assumed to be equal to PicWidthInCtbsY-1.

tile_rows_height_minus1+1 specifies the height of the tile rows except the tile rows at the bottom of the image in units of CTB when the 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 assumed to be equal to PicHeightInCtbsY-1.

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 assumed to be equal to 0. Otherwise, if uniform_tile_spacing_flag is equal to 1, the value of num_tile_columns_minus1 is inferred (eg, as specified above for CTB raster scan, tile scan, and brick scan processes).

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 assumed to be equal to 0. Otherwise, if uniform_tile_spacing_flag is equal to 1, the value of num_tile_rows_minus1 is inferred (eg, as specified below for CTB raster scan, tile scan, and brick scan processes).

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, NumTilesInPic shall be greater than 1.
tile_column_width_minus1[i]+1 specifies the width of the i-th tile column in units of CTB.
tile_row_height_minus1[i]+1 specifies the height of the ith tile row in units of CTB.

If brick_splitting_present_flag is equal to 1, it specifies that one or more tiles of the image referencing the PPS can be split into two or more bricks. If the brick_splitting_present_flag is 0, it specifies that the tiles of the image referencing the PPS are not split into two or more bricks.

If brick_split_flag[i] equals 1, it specifies that the i-th tile is split into two or more bricks. If brick_split_flag[i] is equal to 0, it specifies that the i-th tile is not split into more than one brick. If not present, the value of brick_split_flag[i] is assumed to be equal to zero.

Uniform_brick_spacing_flag[i] equal to 1 specifies that horizontal brick boundaries are uniformly distributed across the i-th tile, signaled using the syntax element brick_height_minus1[i]. If uniform_brick_spacing_flag[i] is 0, the horizontal brick boundaries may or may not be evenly distributed across the i-th tile, and the Specifies that it may or may not be signaled with a list. If not present, the value of uniform_brick_spacing_flag[i] is assumed to be equal to one.

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

num_brick_rows_minus1[i]+1 specifies the number of bricks dividing the i-th tile if uniform_brick_spacing_flag[i] equals zero. 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 assumed 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 (eg, as specified above for CTB rasterscan, tilescan, and brickscan processes).

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

If the following variables are derived and uniform_tile_spacing_flag is equal to 1 then 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_flask[bricks_g][bricks_i] is equal to 1 is inferred by invoking the CTB raster and brickscan conversion process (eg, as specified above for the CTB rasterscan, tilescan, and brickscan processes).

A list RowHeight[j] of j ranging from -0 to num_tile_rows_minus1. Specifies the height of the jth tile row in units of CTB.

A list CtbAddrRsToBs[ctbAddrRs] of CtbAddrRs ranging from -0 to PicSizeInCtbsY-1. Specifies the conversion from the CTB raster scan CTB address of the image to the brick scan CTB address.

A list CtbAddrBsToRs[ctbAddrBs] of ctbAddrBs ranging from -0 to PicSizeInCtbsY-1. Specifies the conversion from a brick scan CTB address to a CTB raster scan CTB address of the image.

A list BrickId[ctbAddrBs] of ctbAddrBs ranging from -0 to PicSizeInCtbsY-1. Specifies the conversion from Brickscan CTB address to Brick ID.

A list NumCtusInBrick[brickIdx] of brickIdx ranging from -0 to NumBricksInPic-1. Specifies the conversion from brick index to number of CTUs in the brick.

A list of brickIdx ranging from -0 to NumBricksInPic-1 FirstCtbAddrBs[brickIdx]. Specifies the brick ID to CTB address translation on the brick scan of the first CTB in the brick.

A single_brick_per_slice_flag of 1 specifies that each slice that references this PPS contains one brick. If single_brick_per_slice_flag is 0, it specifies that slices referencing this PPS may contain multiple bricks. If not present, the value of single_brick_per_slice_flag is assumed to be equal to one.

If rect_slice_flag is equal to 0, it specifies that the bricks within 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 area of the image and slice information is signaled in the PPS. If not present, rect_slice_flag is assumed to be equal to one.

num_slices_in_pic_minus1+1 specifies the number of slices in each picture referencing 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 equals 1, the value of num_slices_in_pic_minus1 is assumed to be equal to NumBricksInPic-1.

top_left_brick_idx[i] specifies the brick index of the brick in the top left corner of the i th slice. Let the value of top_left_brick_idx[i] be equal to the value of top_left_brick_idx[j] for any i not equal to j. If not, the value of top_left_brick_idx[i] is assumed to be equal to i. The length of the syntax element of top_left_brick_idx[i] is Ceil(Log2(NumBricksInPic) bits.

bottom_right_brick_idx_delta[i] specifies the difference between the brick index of the brick in the lower 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 assumed to be equal to 0. The length of the syntax element of bottom_right_brick_idx_delta[i] is Ceil(Log2(NumBricksInPic-top_left_brick_idx[i])) bits.
A slice contains only a few complete tiles, or a continuous sequence of complete bricks of a tile.

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
}
}

If loop_filter_across_bricks_enabled_flag is 1, it specifies that in-loop filtering operations can be performed across the boundaries of bricks in images that reference the PPS. If loop_filter_across_bricks_enabled_flag is 0, it specifies that in-loop filtering operations are not performed across the boundaries of bricks in images that reference the PPS. In-loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filtering operations. If not present, the value of loop_filter_across_bricks_enabled_flag is assumed to be equal to one.

If loop_filter_across_slices_enabled_flag is 1, it specifies that in-loop filtering operations can be performed across slice boundaries for images referencing the PPS. If loop_filter_across_slice_enabled_flag is 0, it specifies that in-loop filtering operations are not performed across slice boundaries for images that reference the PPS. In-loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filtering operations. If not present, the value of loop_filter_across_slices_enabled_flag is assumed to be equal to zero.

If the signaled_slice_id_flag is 1, it specifies that the slice ID of each slice is signaled. If the signaled_slice_id_flag is equal to 0, it specifies that the slice ID is not signaled. If rect_slice_flag is equal to 0, the value of signaled_slice_id_flag is assumed to be equal to 0.

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

slice_id[i] specifies the slice ID of the i-th slice. The length of the slice_id[i] syntax element is signaled_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 0 to num_slices_in_pic_minus1.

If entropy_coding_sync_enabled_flag is equal to 1, then before decoding the CTU containing the first CTB in the row of CTBs of each brick of each image referencing the PPS, a specific synchronization process of context variables is invoked for each image referencing the PPS. specifies that a particular storage process for context variables is invoked after decoding the CTU containing the first CTB of the row of CTBs for each brick of . if entropy_coding_sync_enabled_flag is equal to 0, then there is no need to invoke a context variable specific synchronization process before decoding, for example, a CTU containing the first CTB of a row of CTBs of each brick of each image that references the PPS; and Specifies that a particular storage process for context variables may need to be called, for example, after decoding a CTU containing the first CTB of a row of CTBs for each brick of each image that references the PPS.
The value of entropy_coding_sync_enabled_flag shall be the same for all PPSs activated in CVS.

If cabac_init_present_flag is equal to 1, it specifies that cabac_init_flag is present in the slice header that references the PPS. If cabac_init_present_flag is equal to 0, it specifies that cabac_init_flag is not present in slice headers referencing PPS.

num_ref_idx_default_active_minus1[i]+1 specifies an estimate of the variable NumRefIdxActive[0] for the P or B slice when i equals 0 and num_ref_idx_active_override_flag equals 0, and when i equals 1 the B slice equals num_ref_active_override_0 specifies the estimated value of NumRefIdxActive[1]. The value of num_ref_idx_default_active_minus1[i] shall range from 0 to 14.

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

init_qp_minus26+26 specifies the initial value of SliceQp _Y for each slice that references the PPS. The initial value of SliceQp _Y is modified at the slice layer when a non-zero value of slice_qp_delta is decoded. The value of init_qp_minus26 shall range from -(26+QpBdOffset _Y ) to +37.

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

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

If cu_qp_delta_enabled_flag is equal to 1, it specifies that the cu_qp_delta_subdiv syntax element is present in the PPS and cu_qp_delta_abs may be present in the transform unit syntax. If 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 transform unit syntax.

cu_qp_delta_subdiv specifies the maximum cbSubdiv value of 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.

- If slice_type is equal to I, then the value of cu_qp_delta_subdiv shall be in the range 0 to 2*(log2_ctu_size_minus2−log2_min_qt_size_intra_slice_minus2+MaxMttDepthY).

- Else (if slice_type is not equal to I, the value of cu_qp_delta_subdiv shall be in the range 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 assumed to be equal to zero.

[Edit (BB): The problem here is that MaxMttDepthY is derived at the slice level. If the partition_constraints_override_enabled_flag is equal to 1, then the slice header needs to be parsed to know the value of MaxMttDepthY. ]

pps_cb_qp_offset and pps_cr_qp_offset specify the offset to the luminance quantization parameter _Qp'Y used to derive _Qp'Cb and _Qp'Cr , respectively. The values of pps_cb_qp_offset and pps_cr_qp_offset shall range from -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 ignores their values.

If pps_slice_chroma_qp_offsets_present_flag is 1, it indicates that the slice_cb_qp_offset and slice_cr_qp_offset syntax elements are present in the associated slice header. If pps_slice_chroma_qp_offsets_present_flag is 0, it 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.

If weighted_pred_flag is equal to 0, it specifies that weighted prediction is not applied to P slices. If weighted_pred_flag is equal to 1, it specifies that weighted prediction is applied to P slices.

If weighted_bipred_flag is equal to 0, it specifies that default weighted prediction is applied to B slices. If weighted_bipred_flag is equal to 1, it specifies that weighted prediction is applied to B slices.

If blocking_filter_control_present_flag is equal to 1, it specifies the presence of the PPS deblocking filter control syntax element. If blocking_filter_control_present_flag is equal to 0, it specifies that there is no deblocking filter control syntax element in the PPS.

If blocking_filter_override_enabled_flag is equal to 1, it specifies that blocking_filter_override_flag is present in the slice header of the image that references the PPS. If blocking_filter_override_enabled_flag is equal to 0, it specifies that there is no blocking_filter_override_flag in the slice header of the image that references the PPS. If not present, the value of blocking_filter_override_enabled_flag is assumed to be equal to zero.

If pps_deblocking_filter_disabled_flag is 1, it specifies that the deblocking filter operation is not applied to slices that refer to PPSs for which the 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 refer to PPSs for which the slice_deblocking_filter_disabled_flag is not present. If not present, the value of pps_deblocking_filter_disabled_flag is assumed to be equal to zero.

pps_beta_offset_div2 and pps_tc_offset_div2 are the default deblocking parameter offsets for β and tC to be applied to slices referencing the PPS, unless the default deblocking parameter offsets are overridden by deblocking parameter offsets present in the slice header of the slice referencing the PPS. Specifies the deblocking parameter offset (divide by 2). 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 assumed to be equal to zero.

If pps_loop_filter_across_virtual_boundaries_disabled_flag is 1, it specifies that in-loop filtering operations are disabled across the virtual boundaries of the image referencing the PPS. If pps_loop_filter_across_virtual_boundaries_disabled_flag is equal to 0, it specifies that no such disabling of in-loop filtering operations is applied to images referencing the PPS. In-loop filtering operations include deblocking filters, sample adaptive offset filters, and adaptive loop filtering operations. If not present, the value of pps_loop_filter_across_virtual_boundaries_disabled_flag is assumed to be equal to zero.

pps_num_ver_virtual_boundaries specifies the number of syntax elements of pps_virtual_boundaries_pos_x[i] that exist in the PPS. If pps_num_ver_virtual_boundaries does not exist, it is assumed to be equal to 0.

pps_virtual_boundaries_pos_x[i] is used to calculate the value of PpsVirtualBoundariesPosX[i]. This specifies the location 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). Let pps_virtual_boundaries_pos_x[i] 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 boundaries shall be greater than or equal to CtbSizeY luma samples.

pps_num_hor_virtual_boundaries specifies the number of syntax elements of pps_virtual_boundaries_pos_y[i] that exist in the PPS. If pps_num_hor_virtual_boundaries does not exist, it is assumed to be equal to 0.

pps_virtual_boundaries_pos_y[i] is used to calculate the value of PpsVirtualBoundariesPosY[i]. It specifies the location of the ith 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). Let pps_virtual_boundaries_pos_y[i] 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 boundaries shall be greater than or equal to CtbSizeY luma samples.

If pps_extension_flag is 0, it specifies that no pps_extension_data_flag syntax element is present in the syntax structure of the PPS RBSP. If pps_extension_flag is equal to 1, it specifies that the pps_extension_data_flag syntax element is present in the syntax structure of the PPS RBSP.

Any value can be specified for pps_extension_data_flag. Its presence and value do not affect a decoder's conformance to the profiles specified in this version of this specification. Decoders conforming to this version of this specification shall ignore all pps_extension_data_flag syntax elements.
Sub-sub-subsection "Embodiment C" below describes signaling in the low-level syntax.
As already mentioned, another option for laying out the CA is to use the in-VCL syntax in a more flexible way.

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

The area_line_stop_flag is present in the bitstream at the end of the CTU coding process. The next CTU in diagonal scan order may be located in a CTU line for which the previous area_line_stop_flag has not been sent in the current slice's bitstream and which is at least partially within the image. If area_line_stop_flag is false, the current slice rectangle is extended with a new CTU row with the number of CTU columns currently in use. If area_line_stop_flag is true, the slice height is fixed to the number of CTU rows currently used in the current slice.

Similarly, the area_column_stop_flag is present in the bitstream at the end of the CTU coding process. The case where the next CTU in diagonal scan order is in a new CTU column, for which the previous area_column_stop_flag has not been sent in the bitstream of the current slice and which is at least partially within the image. If area_column_stop_flag is false, the slice rectangle is extended with a new CTU column containing the number of CTU rows currently in use. 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 illustrates coding region signaling at the sub-area (CTU) level according to an embodiment.

Once the slice rectangle is determined, the CTUs are processed in a particular scan order until all CTUs covered by the slice rectangle have been processed. Due to the lack of explicit area_line_stop_flag and area_column_stop_flag at image boundaries, respectively, span-coding regions adjacent to image boundaries are constrained not to exceed them. This can be confirmed in FIG. In that, area_line_stop_flag=1 and area_column_stop_flag=1 are not near the border of the image.

Implicitly deriving area_line_stop_flag=1 and area_column_stop_flag=1 using prior knowledge of the size and position of the CA and image boundaries saves signaling overhead, but requires some bitstream manipulation, e.g. prevent "bitstream extraction" and "coding domain bitstream aggregation", or in these cases at least incur additional processing overhead for entropy-encoded data. Currently, for HEVC, a Motion Constrained Tileset (MCTS) is defined that allows for both processes without further processing of the entropy coded data. However, such a process either causes the MCTS (each CA) boundary to become the image boundary, or the image boundary becomes the MCTS boundary (each CA) and not the image boundary. Therefore, the implicit derivations area_line_stop_flag=1 and area_column_stop_flag=1 always require the presence of both syntax elements, regardless of whether it is an image boundary and whether another CA has already been described. should not allow such features to be enabled. 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 existence of MCTS or "motion constrained coding regions".

To summarize the above, according to an embodiment, the data encoder 110 may, for example, configure the coding region information such that the information for the plurality of coding regions includes one or more region sequence stop flags for the coding regions of the one or more coding regions. , wherein if a coding region sequence stop flag of one or more coding regions is set to a stop value, the region sequence stop flag is for example the Width can be indicated. Alternatively, data encoder 110 is configured to generate indication data such that, for example, the information for the plurality of coding regions includes one or more region line stop flags for the coding regions of the one or more coding regions. and a coding region line stop flag of one or more coding regions is set to a stop value, said region line stop flag may for example indicate the height of said coding region.

According to an embodiment, the data encoder 110 is configured to generate the indication data, for example such that the indication data indicates whether the explicit signaling mode is active or whether the explicit signaling mode is inactive. can be configured to If the explicit signaling mode is active and a coding tree unit of one or more coding tree units of the coding region is located at a picture boundary of the picture, data encoder 110 may, for example, determine whether the indication data is the The indication data may be configured to include at least one of a region column stop flag and a region line stop flag. If the explicit signaling mode is inactive and the coding tree units of one or more coding tree units of a coding region are located at the image boundaries of an image, data encoder 110 may, for example, determine whether the indication data indicates the coding tree It may be configured to generate indication data not to include region column stop flags of units and/or not to include region line stop flags of said coding tree units.

Similarly, in an embodiment, data decoder 170 may be configured to decode encoded image data using, for example, information about multiple coding regions, wherein the information is one or more coding regions. and one or more region string stop flags of the coding regions of the one or more coding regions are set to a stop value, the region string stop flag is, for example, It may indicate the width of the coding region. Alternatively, data decoder 170 may be configured, for example, to decode encoded image data using information of multiple coding regions, wherein the information is one for one coding region of one or more coding regions. one or more region line stop flags, and if the coding region region line stop flags of one or more coding regions are set to a stop value, then the region line stop flags are, for example, the high can show that

According to an embodiment, data decoder 170 uses, for example, an indication in the indication data indicating whether the explicit signaling mode is active or whether the explicit signaling mode is inactive to encode may be configured to decode the processed image data. If the explicit signaling mode is inactive and the coding tree units of one or more coding tree units of the coding region are located at said picture boundary of a picture, data decoder 170 may for example rely on the picture boundary picture to , may be configured to decode the encoded image data.
The next sub-subsection, "CTU Scan Order," describes the CTU scan order.
The next sub-subsub-section, "Raster Scanning," describes raster scanning.

If the image is divided into multiple CAs, conventional raster scanning schemes can be applied to the CTU processing scheme. Using this method and knowing the partitioning scheme of the entire image via the coding regions, the CTUs of the entire image can be processed line by line. This kind of processing was already possible with HEVC tiles. Therefore, in this case the flexibility of the CTU processing scheme is preserved.

Thus, according to an embodiment, the coding order of each coding region of one or more coding regions comprising two or more coding tree units may depend, for example, on raster scanning, and data encoder 110 may, for example, , to generate indication data, such that the indication data indicates that raster scanning was used to encode each coding region of one or more coding regions comprising two or more coding tree units. can be configured to

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 raster scanning, and data decoder 170 may depend on raster scanning. Configurable to decode image data that has been encoded dependently, data decoder 170 is configured to encode each coding region of one or more coding regions comprising two or more coding tree units. It may be configured to receive information indicating that raster scanning was used, and the indication data may include, for example, said information.
The next sub-sub-subsection, "Diagonal Scanning," describes diagonal scanning.

However, conventional raster scan ordering limits the availability of spatial references. To remedy this, in embodiments diagonal scanning is used as an additional CTU processing scheme.

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

A block corresponding to CTU _{Xref, Yref} is available for reference, then CTU _{Xref, Yref} is available for prediction of the current CTU _{Xcur, Ycur} , then reference is not restricted, e.g., another slice, tile , or outside the image where the following conditions apply:
- For WPP:

－順次処理順序の場合：

- For sequential processing order:

または

or

ここで、Ｘ_ｒｅｆ、Ｙ_ｒｅｆ、Ｘ_ｃｕｒ、Ｙ_ｃｕｒはＣＴＵの位置の座標である。

where X _ref , Y _ref , X _cur , Y _cur are the coordinates of the CTU location.

Using the upper neighbor block offset constraint above, the CTU processing order can be derived. The various resulting CTU scans are variations of the diagonal scan with specific tilts or angles, the tilts being given by fixed values, controlled by syntax elements sent in the bitstream, or Derived from syntax elements already present in the bitstream.
FIG. 12 shows the CTU scan order and spatial reference for CTU_dependency_offset_id=1, according to an embodiment.
FIG. 13 shows another CTU scan order and spatial reference for CTU_dependency_offset_id=2, according to another embodiment.

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

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)==[y x]))
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<NumCTU Rows
x = x-Slope;
y=y+1;
else
x = x + (NumCTU Rows - 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 are exemplary scan and spatial reference availability for some CTU_dependency_offset_id values.
To summarize the above:

According to embodiments, the coding order of the coding regions of one or more coding regions comprising two or more coding tree units may depend on a scan order dependent on, for example, a slope indicating an angle. After encoding the first one of the two or more coding tree units of the coding region, data encoder 110 may, for example, determine the position of the first one of the coding tree units of the coding region. and depending on other coding tree units in said coding region that are not encoded and depending on a slope, determine a second one of two or more coding tree units in the coding region. can be configured to Data encoder 110 may, for example, be configured to encode said second one of two or more coding tree units.

In an embodiment, data encoder 110 is configured, for example, to determine a second one of two or more coding tree units in the coding region, the arrow being defined by the starting point and the slope. , the starting point can be a first one position of a coding tree unit within a coding region and refers to a second one position of two or more coding tree units.

According to an embodiment, data encoder 110 may, for example, determine that diagonal scanning was used to encode each coding region of one or more coding regions comprising two or more coding tree units. It may be configured to generate the indicative data as indicated by the indicative data.

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

According to an embodiment, data decoder 170 determines the second one of the two or more coding tree units within the coding region, eg, the arrow defined by the starting point and the slope. can be configured as A starting point can be, for example, a first one position of a coding tree unit within a coding region and refers to a second one position of two or more coding tree units.

In an embodiment, data decoder 170 may, for example, provide information indicating that diagonal scanning was used to encode each coding region of one or more coding regions comprising two or more coding tree units. It may be configured to receive instructional data, which may include, for example, said information.
The next sub-sub-subsection, "Z-scan," describes Z-scan.
FIG. 14 shows coding regions in Z-scan CTU order, according to an embodiment.

In such embodiments, a Z-scan can be used for the CTU scan order instead of the suggested diagonal scan. Z-scan is defined in HEVC.

According to embodiments, the coding order of a coding region comprising 5 or more coding tree units may for example depend on a scanning order, said scanning order depending on the first angle being 0°, It may depend on the second angle being 135° and on the third angle being 45°.

After encoding a 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 within the coding region A first arrow with a first starting point at the position of the first coding tree unit of encloses a first angle that is 0° with respect to the predefined direction, and the first arrow points within the coding region and data encoder 110 is configured to encode the second coding tree unit of the coding region.

After encoding a second coding tree unit of the coding region, data encoder 110 may be configured, for example, to determine a third coding tree unit of the coding tree region, such that within the coding region A second arrow having a second starting point at a second coding tree unit position of encloses a second angle that is 135° with respect to the predefined direction, the second arrow pointing to the coding Refers to the third coding tree unit within a region, and data encoder 110 is configured to encode the third coding tree unit of the coding region.

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

In a particular embodiment, after encoding a fourth coding tree unit of said coding region, data encoder 110 may be configured to determine a fifth coding tree unit of said coding tree region, so that , a fourth arrow having a fourth starting point at a position of a fourth coding tree unit within said coding region encloses a third angle that is 45° with respect to said predefined direction; An arrow of 4 points to the fifth coding tree unit in the coding region, and data encoder 110 is configured to encode the fifth coding tree unit in the coding region.

In an embodiment, data encoder 110 provides data indicating that z-scans were used to encode each of one or more coding regions comprising, for example, five or more coding tree units. As shown, it can be configured to generate indicative data.

Similarly, according to embodiments, the coding order of a coding region comprising more than 5 coding tree units may depend, for example, on a scanning order, said scanning order being such that the first angle is 0°. may depend on the second angle being 135° and may depend on the third angle being 45°.

After decoding a 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 within the coding region A first arrow with a first starting point at the position of the first coding tree unit encloses a first angle that is 0° with respect to the predefined direction, and the first arrow points within the coding region. Refers to the second coding tree unit, and data decoder 170 is configured to decode the second coding tree unit of the coding region.

After decoding a 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 within the coding region A second arrow with a second starting point at the second coding tree unit encloses a second angle that is 135° with respect to the predefined direction, the second arrow pointing to the coding region data decoder 170 is configured to decode the third coding tree unit of the coding region.

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

In a particular embodiment, after decoding a fourth coding tree unit of said coding region, data decoder 170 may be configured to determine a fifth coding tree unit of said coding tree region, such that: A fourth arrow with a fourth starting point of the location of a fourth coding tree unit within the coding region encloses a third angle that is 45° with respect to the predefined direction; arrow points to the fifth coding tree unit in a coding region, and data decoder 170 is configured to decode the fifth coding tree unit in the coding region.

According to an embodiment, data decoder 170 indicates that a z-scan was used to encode each of one or more coding regions comprising, for example, 5 or more coding tree units. It may be configured to receive information, and the instructional data may include, for example, said information.
The next sub-subsub-section, "Scan Direction," describes scan direction.

In another embodiment, the direction of scanning may be flexible, ranging, for example, diagonally downward from right to left, diagonally upward from right to left respectively, or diagonally upward from left to right. The scan direction can be sent in the bitstream using the new syntax element CTU_scan_direction, or it can be derived from syntax elements already present in the bitstream.

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

If there is a CTU neighbor adjacent to the bottom boundary of the first slice CTU, or the first slice CTU is located at the bottom CTU line of the image, has no right adjacent neighbor, and is not located in the rightmost CTU column Then the CTU scan is an up-right scan.

If there is a CTU neighbor adjacent to the bottom boundary of the first slice CTU OR the first slice CTU is located at the bottom CTU line of the image and has a right adjacent neighbor OR is located in the rightmost column of the image If so, the CTU scan is a top-left scan.

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

In another such embodiment, the derivation scheme of the above invention is further refined by evaluating the number of available CTU neighbors along potential coding region boundaries. For example, the first slice CTU is at the upper left position of the CTU neighbor and the scan could be a lower right scan or a lower-right scan, thus vertically and horizontally along the boundaries of the coding region. , the CTU neighbors that may be available (if the dimensions of the CA are unknown) are summed separately. If the sum of vertical neighbors exceeds the number of horizontal CTU neighbors, bottom-right scanning is used. Otherwise, the scan is a bottom right scan. This derivation scheme is illustrated in FIG. 15 using raster scanning.

In another embodiment, the derivation schemes and refinements of the above invention are used to form an ordered list of possible scans whose indices are sent at the slice level to select CTU scans. In addition, CTU_dependency_offset_id should be coded in the slice header if different diagonal scans are used in the image.
FIG. 16 shows coding regions for different CTU scan directions, according to an embodiment.
In particular, FIG. 16 shows an example of using different scanning directions within an image.
To summarize the above:

According to embodiments, the coding order of the coding regions of one or more coding regions comprising two or more coding tree units may depend on the scanning order comprising, for example, one or more scanning directions. After encoding the first coding tree unit of said coding region, the data encoder 110, for example, depending on the position of the first coding tree unit and the first one of one or more scan directions. and data encoder 110 is configured to encode the second coding tree unit of the coding region. .

In embodiments, data encoder 110 may be configured to generate instructional data such that, for example, the instructional data indicates said scanning order comprising one or more scanning directions.

According to an embodiment, the data encoder 110 is configured to derive one or more scan directions, e.g. by evaluating adjacent neighbors of a first coding tree unit of said coding region. obtain. 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 the first coding tree unit is located in the bottom coding tree unit row of the image; If there is no neighbor to the right and it is not located in the rightmost coding tree unit column, the scan direction may be, for example, a top-right scan. If the first coding tree unit has coding tree unit neighbors of two or more coding tree units adjacent to its bottom boundary, or the first coding tree unit is located in the bottom coding tree unit row of the image However, if there is a neighbor to the right or is located in the rightmost column of the image, then the scan direction may be, for example, a left-up 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, scan The direction can be, for example, downward to the left. Otherwise, the scan direction may be, for example, downward and to the right.

In embodiments, data encoder 110 may be configured to generate the indication data, for example, such that the indication data indicates an index indicating the selected scan direction of the one or more scan directions.

Similarly, according to embodiments, the coding order of the coding regions of one or more coding regions comprising two or more coding tree units is dependent on the scanning order comprising, for example, one or more scanning directions. can. After decoding the first coding tree unit of the coding region, the data decoder 170 selects a first one of one or more scan directions, for example depending on the position of the first coding tree unit. As such, data decoder 170 may be configured to determine a second coding tree unit of the coding tree region, and data decoder 170 may, for example, be configured to decode the second coding tree unit of the coding region.

In embodiments, data decoder 170 may be configured to receive information indicative of said scanning order including, for example, one or more scanning directions, wherein indication data may, for example, include said information.

According to an embodiment, the data decoder 170 is configured to derive one or more scanning directions, e.g. by evaluating adjacent neighbors of the first coding tree unit of said coding region. obtain. 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 the first coding tree unit is located in the bottom coding tree unit row of the image; If there is no neighbor to the right and it is not located in the rightmost coding tree unit column, the scan direction may be, for example, a top-right scan. If the first coding tree unit has coding tree unit neighbors of two or more coding tree units adjacent to its bottom boundary, or the first coding tree unit is located in the bottom coding tree unit row of the image However, if there is a neighbor to the right or is located in the rightmost column of the image, then the scan direction may be, for example, a left-up 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, scan The direction can be, for example, downward to the left. Otherwise, the scan direction may be, for example, downward and to the right.

In an embodiment, the data decoder 170 may be configured to receive, for example, information indicating an index indicating the selected scanning direction of the one or more scanning directions, and the indication data may include, for example, said information. .
The "Dependent Coding Regions" subsection below describes dependent coding regions.
FIG. 17 shows dependent coding regions with an inter-region prediction option, according to an embodiment.

In such embodiments, one coding region may depend on another coding region to exploit spatial prediction capabilities within the image. In this case, a particular processing order of regions may be required, for example, to facilitate deterministic operation. This can be done, for example, by signaling the order of the areas using a new syntax element area_order_idx in each CA that explicitly determines the order of dependencies. Alternatively, the dependency order can be derived directly from the CA order signaled in the coding_area_arrangement( ) syntax. See sub-section "Size and Placement of Coding Regions".

The value of area_order_idx can be interpreted as follows. That is, areas with high area_order_idx values depend on areas with low area_order_idx values and vice versa.
To summarize the above:

In an embodiment, data encoder 110 is configured to encode the image, for example, by encoding image data of the image in each coding region of the plurality of coding regions to obtain encoded image data. can do. Data encoder 110 may, for example, encode the plurality of coding regions such that encoding image data of at least one of the plurality of coding regions depends on encoding image data of at least another one of the plurality of coding regions. may be configured to encode image data of at least one of the coding regions of the image.

Similarly, in an embodiment, data decoder 170 may be configured, for example, to decode encoded image data of at least one of the plurality of coding regions; Decoding the encoded image data depends on decoding the encoded image data of said at least another one of the plurality of coding regions.
The following sub-section, "Coding Domain Parallelism," describes coding domain parallelism.

Coding regions can also support parallel processing. An obvious use case for parallelization is the use of multiple independent coding regions. In this case, dependencies for parsing or reconstructing one CA's configured CTU into any other CA are prohibited, and adjacent CUs assigned to another CA are treated as non-referenceable. will be In this case, the post-processing filter can be applied to CA individually or image by image, 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 illustrates parallel processing of dependent coding regions according to embodiments ((A) CTU raster scan; (B) CTU diagonal scan).

For dependent coding regions, the processing scheme shown in FIG. 18 can be used to exploit spatial dependencies in the image and reduce artifacts that can occur at boundaries between regions. The use of inter-CA dependencies may, for example, require an explicit ordering of CTU processing. The result is reliable availability of CTUs from neighboring CAs.

The order of processing CAs may be implied by the order of CAs sent in the bitstream. In addition, the order of CAs can also be specified explicitly 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.

The pipeline concept presupposes analysis and reconstruction and/or post-filtering according to a lockstep execution scheme. A global event is used to initiate each thread's CTU execution step, where each step processes a single CTU at each CA. This scheme guarantees maximum throughput at the expense of unavailable CTU references, as shown in FIG. 19(B). In this case, the immediately adjacent CTUs of the first and second CAs are processed simultaneously and cannot be referenced in either direction.
However, when strict lockstep execution is applied, additional inter-CA dependencies become available, as indicated by the light blue arrows.
The following describes the concept of dependency-driven.

This concept relies on the local availability of inter-CA CTU neighbors. If it should be available for reference, but the reference CTU of an adjacent neighbor CA is not available, execution of this particular CA stops until the reference CTU is available by completing each parsing reconstruction. This is because, for example, the reference CTU of the first CA is processed in the fifth execution step and is earliest available in the sixth execution step, so processing of the second CA stops in the fifth execution step. can be seen in FIG. 19(A).

In addition, parallel processing can be extended to post-processing filter operations using dependent CA processing schemes. For CTU inner boundaries (CU boundaries), the 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 the samples available for filtering. This rule also applies to CA cross-boundary filtering if CA cross-boundary filtering is enabled or for dependent CA. Deblocking filters arriving beyond CTU boundaries are treated in an analogue manner when analysis and reconstruction are performed considering the availability of reference CTUs at neighboring CAs. If CTUs of neighboring CAs are available, the portion of the previously unfiltered region is filtered in the current filtering process.
FIG. 20 shows a deblocking filter process on CA boundaries for CA order, according to an embodiment.
FIG. 21 shows a deblocking filter employing inter-CA filtering in the hatched filter region, according to an embodiment.

As shown in FIG. 21, in the first processing step, only CTU(1) of the first CA can be filtered. This filtering of CTUs is restricted to the inner boundary since no CTU neighbors are available. In a second execution step, the second CTU of the first CA filters its internal boundaries and the CTU boundaries to the first CTU of the first CA. In addition, the lower left CTU of the second CA is filtering CAs that overlap its inner boundary with the CTU boundary of the first CTU of the first CA. One advantage of this parallel processing is that it allows low-delay operation of the deblocking filter. Deblocking of cross-CA boundary filtering can start before the entire CA is decoded, thereby reducing the overall processing time before image regions can use reference images for further images. can be shortened.
The next sub-section, "Aspects of Error Resilience," describes aspects of error resilience.

As discussed in the "State of the art VCL partitioning" section, error resilience is a desirable feature of video coding when an application's storage or transport mechanisms are unreliable. However, many applications such as HTTP streaming exist today and are less resilient to errors, for example RTP/UDP streaming with packet loss or general broadcast channels with bit or burst errors. Sometimes. 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 segment is successfully retransmitted. be. In the latter scenario, it is desirable to introduce further dependencies within the coded data in order to improve coding efficiency gains while losing some error resilience features. For example, in the aspect of scan order derivation based on neighboring CAs, described in the sub sub-subsection "Scan Direction", for example, before the current CA can be correctly decoded, the neighboring CAs at the receiver side Availability may be required. Therefore, such techniques should only be used where limited error resilience is acceptable. Similarly, in aspects relating to dependent coding regions, such as the sub-subsection "Dependent Coding Regions", dependencies affecting error resilience, and in the sub-subsection "Parallel Processing of Coding Regions" The parallelization aspects and processing orders described are introduced. Other state-of-the-art in this regard must deal with the same trade-offs. For example, intra-picture translation-corrected prediction, such as IBC in HEVC SCC, and other intra-prediction techniques that promote samples in the picture that are further away from the current block, resulting in normal intra-prediction. Also, at the sequence level, there are additional techniques known to improve coding efficiency at the expense of impacting error resilience. For example, sharing the state of entropy coding entities such as the CABAC context model over images.

In systems incorporating coded video transmission, information about the degree of error resilience provided by the coded video stream can be exploited in a variety of ways. For example, a media-aware middlebox can trigger an early retransmission, or an end device can choose among error concealment strategies, e.g., frame-level slice-based error concealment by copying frame subsections or retransmission. or skipping decoding of parts of the bitstream (individual AUs, AUs associated with PPSs, etc., AUs associated with SPSs or forming a CVS) until successful. Therefore, it is desirable to indicate to the middlebox or client end device the degree of error resilience that the encoded video stream provides. Another use of error concealment in coded video sequences is for service operators to determine whether a particular coded stream is suitable for an envisaged transmission system. For example, a stream encoded for HTTP streaming may have poor performance when sent over satellite channels that are prone to burst errors.

Currently, this information is not easily accessible in streams coded using modern codecs, as a myriad of parameters determine error resilience. For example, take the non-exhaustive list of examples above. Some individual parameters may be derived from a set of parameters, while others may require high-level parsing, e.g., image-based, while other parameters may e.g. It may even require low-level parsing. Also, most of the investigated parameters do not signal information about encoder decisions for the rest of the coded video sequence, but are limited in scope. For example, the splitting decision can happen by chance from image to image. Corrupted streams may not contain the information you need.

Embodiments provide a readily accessible indication of the degree of error resilience of a coded video sequence. Some embodiments provide coding constraints for coded video on associated tools that affect error resilience and error mitigation strategies. A middlebox or client-end device can interpret the instructions as ensuring that the video encoder has excluded certain options from the decision space that would otherwise affect error resilience. The service provider can interpret information about which transmission system the coded stream is suitable for.
In embodiments, a single flag in the easily accessible high-level syntax of encoded video is provided, for example:

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

Alternatively, embodiments provide an index into a predefined list of error resilience states in an easily accessible high-level syntax of encoded video, as follows.

ｓｐｓ＿ｅｒｒｏｒ＿ｒｅｓｉｌｉｅｎｃｙ＿ｅｎａｂｌｅｄ＿ｉｄｘは、次の表に従って、コード化されたビデオシーケンスのエラーの回復力の状態を示す。

sps_error_resiliency_enabled_idx indicates the error resiliency status of the coded video sequence according to the following table.

ＡＵ＝アクセスユニット；ＰＰＳ＝画像パラメータセット；ＳＰＳ＝シーケンスパラメータセット、ＣＶＳコード化ビデオシーケンス

AU = access unit; PPS = picture parameter set; SPS = sequence parameter set, CVS coded video sequence

Here, the lists [CodingToolSetA], [CodingToolSetB], and [CodingToolsSetC] are defined as follows.

CodingToolSetA consists of tools that compromise error resilience at the image level. That is, it introduces dependencies in the image that prevent successful decoding if part of the image is lost, such as dependent CA.

CodingToolSetB consists of tools that compromise error resilience at multiple image levels (ie, PPS scopes). That is, using a tool after the erroneous image, such as joint entropy coding of multiple images, e.g. images belonging to the top temporal layer of a GOP, to introduce dependencies between any of the images referencing the PPS. to prevent successful decoding of images that reference the PPS.

CodingToolsSetC consists of tools that compromise error resilience at the sequence level (ie, the scope of the SPS). That is, they introduce dependencies between all images within the random access period, and they cause erroneous images until the random access point starts a new CVS such as quantizer scaling matrix, entropy coding initialization, etc. Use the tool according to to prevent successful decoding of any image that references the SPS.
In a further embodiment of the invention, the different modes of instruction are not linked to the syntactic structure that activates the toolset.

In addition, the extent of CodingToolSetB is indicated by additional signaling indicating the extent in terms of images following the first image in coding order. Thus, CodingToolSetB in this embodiment contains tools that impair error resilience at multiple image levels (each image being shown by a scope display), i.e., they introduce dependencies between the shown images and as a result prevents successful decoding of any joint entropy coding of multiple images, such as images belonging to the highest temporal layer such as GOP, using the toolset following the erroneous image.

To summarize the above, according to embodiments, data encoder 110 may generate instruction data such that, for example, the instruction data may include information about the error resilience of the encoded video sequence. can be configured.

In embodiments, the error resilience information may indicate, for example, one of three or more different error resilience states of the encoded video sequence.

Similarly, according to embodiments, data decoder 170 may be configured to receive information indicative of, for example, the error resilience of the encoded video sequence. Data decoder 170 may, for example, be configured to decode the coded image data in dependence on information indicative of the error resilience of the coded video sequence.

In embodiments, the error resilience information may indicate, for example, one of three or more different error resilience states of the encoded video sequence.

In particular embodiments, a first state of three or more different states may indicate, for example, that the access unit is not error resilient. A second state of three or more different states may indicate, for example, that the first plurality of access units of the image's parameter set is not error resilient. A third state of 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.

In another particular embodiment, the error resilience information may indicate, for example, one of four or more different error resilience conditions of the coded video sequence. A first state of four or more different states may indicate, for example, that error resilience is compromised at the image level, compromised at the multi-image level, and compromised at the sequence level. A second state of four or more different states may indicate, for example, that error resilience is compromised at the image level, is compromised at the multi-image level, but is not compromised at the sequence level. A third state of four or more different states, for example, indicates that error resilience is compromised at the image level, but error resilience is not compromised at the multiple image level and not at the sequence level. obtain. A fourth state of four or more different states may also indicate, for example, that error resilience is not compromised at the image level, is not compromised at the multi-image level, and is not compromised at the sequence level.
The next subsection, "Data Fragmentation in the Coding Region," describes data fragmentation in the coding region.
Similar to tiles, CAs can also be fragmented for the transport layer. In this case there are no restrictions. Possible uses are shown in FIGS. 22, 23 and 24. FIG.
FIG. 22 shows a bitstream consisting of a single image of one coding region, but the CA is fragmented into multiple transport units.
FIG. 23 shows a bitstream consisting of a single image of multiple coding regions, but each CA has 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.
The next subsection, "Coding for Sub-Region Spatial Predictor Management," describes coding for sub-region spatial predictor management.
FIG. 25 shows a generalized presentation of blocks surrounded by regions, according to an embodiment.
In a generalized approach, a coding block can be bounded by eight major spatial regions. Please refer to FIG.
The next sub-subsection, "General Predictor Management," describes general predictor management.

Candidates from all eight neighbor regions can be incorporated into the predictive candidate list. They can each select their availability in a simple way. For a CTU, for example, it can be constructed by sub-dividing into sub-blocks in a particular sub-block processing order, and depending on the particular availability scenario, the order of the sub-blocks can be adjusted. For example, if only neighbors AD, D, DC, and C are available, the sub-blocks adjacent to these neighbors should be processed first.

In summary, according to an embodiment, the data encoder 110 may rely on one or more coding tree units, eg, eight adjacent coding tree units of a plurality of coding tree units located in an image. to encode a coding tree unit of a plurality of coding tree units located in an image, wherein eight adjacent coding tree units are adjacent to said coding tree unit.

Similarly, in an embodiment, data decoder 170 may, for example, rely on one or more coding tree units of eight adjacent coding tree units of a plurality of coding tree units located in the image to It may be configured to decode a coding tree unit of a plurality of coding tree units located in an image, and eight adjacent coding tree units are adjacent to said coding tree unit.
The next sub-section, "Neighbor Spatial Matching," describes neighbor spatial matching.

Some specific neighborhood scenarios allow conventional sub-block processing orders by some adaptation of the corresponding neighbor's regions or predictors. In embodiments, adaptation may include, for example, rotation of regions of corresponding neighbors, and may include coding blocks stepwise by 90° steps, if desired. For example, in the figure, if only neighbors AD, D, DC, C, and BC are available, a rotation of these neighbors and optionally 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 into a new buffered state.
Coordinate transformations can also include horizontal or vertical flips. This leads to different prediction candidate orders.

In summary, in an embodiment, data encoder 110 may, for example, shift a coding tree unit of eight adjacent coding tree units to another one of the eight adjacent coding tree units. It may be configured to code a coding tree unit of the located plurality of coding tree units.

Similarly, according to an embodiment, data decoder 170 may, for example, shift a coding tree unit of eight adjacent coding tree units to another one of the eight adjacent coding tree units to generate image may be configured to decode a coding tree unit of a plurality of coding tree units located within.
The next sub-subsection, "Concept of Unusable Neighbor Replacement," describes the concept of unavailable neighbor replacement.

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

In certain embodiments, spatial neighbors that are not available for prediction may be replaced by neighbors from the spatial neighbors below the current block, if available, for example.
Otherwise, if there is no spatial predictor below, the current block is available. Default fallback is used.

In the following, the term "bottom left extension" in this context refers to the definition of 0s immediately to the bottom left of the current block, except for the special case where the bottom left sample of the current block is in the bottom sample row of the current CTU. is defined as a block according to In this special case, the current block's lower-left extended neighbor is the upper-right block of the CTU of 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 particular fallBackQP.
A = (isLeftCUavailable?CULeftQP: fallBackQP)
B = (isAboveCUavailable?CUAboveQP: fallBackQP)
Predicted QP = (A+B+1)>>1

In certain embodiments, the prediction scheme is extended to use the QP of the lower left extended CU if the left CU responds. The CU above cannot be used for prediction, but the CU in the lower left extension can be used for prediction. If neither the regular neighbor CU nor the lower left extended CU is available for prediction, fallBackQP is used instead to derive the values for A and B respectively.

A = (isLeftCUavailable?CULeftQP: (isExtendedBelowLeftCUavailable?CUExtendedBelowLeftQP:fallBackQP))

B = (isAboveCUavailable?CUAboveQP: (isExtendedBelowLeftCUavailable?CUExtendedBelowLeftQP:fallBackQP))
Predicted QP = (A+B+1)>>1
However, this kind of prediction scheme is universal and applicable to all prediction schemes using 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

Furthermore, the invented prediction scheme can also be used in the canonical decoding process to derive specific predictors. For example, a motion vector component and reference index derivation process, or a luma intra prediction mode derivation process can be mentioned.

In summary, according to an embodiment, said eight neighboring coding tree units are in a first neighborhood, and data encoder 110 may, for example, select the third neighboring coding tree unit of another eight neighboring coding tree units in a second neighborhood. coding tree unit of a plurality of coding tree units by shifting a coding tree unit of a first neighboring coding tree unit to a second coding tree unit of eight adjacent coding tree units; If the second coding tree unit of the eight neighboring coding tree units of the first neighborhood is unavailable, the another eight neighboring coding tree units of the second neighborhood neighbor the second coding tree unit. is doing.

Similarly, in an embodiment, eight adjacent coding tree units may be, for example, a first neighborhood, and data decoder 170 may determine, for example, a third adjacent coding tree unit of another eight adjacent coding tree units in a second neighborhood, for example. a coding tree unit of a plurality of coding tree units located in an image by shifting a coding tree unit of a first neighboring coding tree unit to a second coding tree unit of eight neighboring coding tree units. and if the second coding tree unit of the eight neighboring coding tree units of the first neighborhood is not available, the other eight neighboring coding tree units of the second neighborhood are the second coding tree units Adjacent to tree unit.

Further provided is an encoded video signal encoding the image, wherein the encoded video signal includes encoded image data and instruction data, the image is divided into a plurality of coding regions and a plurality of coding regions is provided. Each coding region of the region is located within the image, each of the plurality of coding regions includes one or more coding tree units of the plurality of coding tree units located within the image, and the image is divided into the plurality of coding regions. dependently encoded, the indication data including information about the plurality of coding regions, one or more coding regions of the plurality of coding regions indicating two or more coding tree units of the plurality of coding tree units; each coding region of one or more coding regions comprising two or more coding tree units, each coding region indicating a coding order for two or more coding tree units of said coding region; or depending on the coding order of one or more coding regions including two or more coding tree units; Contains information about the coding order.

According to embodiments, 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. Extend.

In an embodiment, each of the plurality of coding tree units has a horizontal position within the image and a vertical position within the image, wherein the first coding region of the plurality of coding regions is a plurality of a first coding tree unit having a first vertical position identical to a second vertical position of a different second coding tree unit of a different second coding region of the coding region; has a third vertical position different from the vertical position of any other coding tree unit in the second coding region; and a fourth coding tree unit in the second coding region The tree unit has a fourth vertical position different from the vertical position of any other coding tree unit of the first coding region, or the first coding region of the plurality of coding regions is the plurality of coding regions a first coding tree unit having a first horizontal position identical to a second horizontal position of a different second coding tree unit of a different second coding region of the first coding region; The three coding tree units have a third horizontal position different from the horizontal positions of any other coding tree units in the second coding region, and a fourth coding tree unit in the second coding region. has a fourth horizontal position that is different from the horizontal position of any other coding tree unit of the first coding region.

According to embodiments, each coding region of a plurality of coding regions may exhibit spatial characteristics including a position, width and height of said coding region, wherein said width and height of said coding region are defined by a rectangle of said coding region. and the position of the coding region depends on the position of the coding region in the image.

The first height of the first one of the plurality of coding regions is different from the second height of the second one of the plurality of coding regions, or the first height of the plurality of coding regions is A first width of one may be different than a second width of a second one of the plurality of coding regions.
According to embodiments, the indication may include, for example, information regarding spatial properties of each coding region of the plurality of coding regions.
In embodiments, the indication data may include, for example, the position, width, and height of each coding region of the plurality of coding regions.

According to an embodiment, the image data for each image portion of the plurality of coding regions is encoded independently of encoding the image data for the image portion of any other coding region of the plurality of coding regions. encoded image data in the encoded video signal may be obtained.

In an embodiment, the image portion is encoded, for example, by encoding the image data of the image portion within each coding region of the plurality of coding regions to obtain encoded image data, resulting in a plurality of image data for an image portion of at least one of the coding regions, wherein encoding the image data of the at least one of the plurality of coding regions encodes image data of at least another one of the plurality of coding regions; It can be encoded within the encoded video signal as it depends on the encoding.
According to embodiments, an encoded video signal may include, for example, a bitstream, which includes encoded image data and instructional data.

In embodiments, the indication data may include, for example, information for each coding region as to whether the upper left coding tree unit is addressed.

According to embodiments, the instruction data may include information regarding, for example, 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. .

In an embodiment, the indication data, for example, indicates whether one of the plurality of coding regions depends on another one of the plurality of coding regions. The one of the following coding regions can be indicated.

According to embodiments, 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.

In embodiments, the indication data may indicate, for example, whether the indication data includes information regarding how to scan within each of the one or more coding tree units of the plurality of coding regions.

According to embodiments, the instruction data may indicate, for example, how to scan within each of the one or more coding tree units of the plurality of coding regions.

In embodiments, the indication data may indicate, for example, for each of multiple coding regions, whether the coding region includes multiple coding tree units.

According to an embodiment, the indication data is, for example, for one of the plurality of coding regions, the coding tree unit scanning is to start at the leftmost coding tree unit or the coding tree unit scanning is to start at the rightmost coding tree unit. You can indicate whether it starts with

In an embodiment, the indication data indicates, for example, for one of the plurality of coding regions, whether the coding tree unit scan starts at a coding tree unit row at the top of the coding region, or whether the coding tree unit scan can indicate whether it starts at the bottom coding tree unit line of the .

In an embodiment, the indication data indicates, for example, whether coding tree unit scanning is to be started horizontally or coding tree unit scanning is to be started vertically for one of the plurality of coding regions. can be done.

According to embodiments, the indication data may, for example, indicate whether at least one of the plurality of coding regions surrounds another one of the plurality of coding regions, or whether any of the plurality of coding regions surrounds another one of the plurality of coding regions. Non-contiguous information can be indicated to indicate whether or not to enclose.

According to an embodiment, the indication data is, for example, for one of the plurality of coding regions, the coding region of the coding tree unit specifying the number of coding tree units arranged horizontally within one of the coding regions. can indicate the width of

In an embodiment, the indication data is, for example, for one of the plurality of coding regions, a coding region within a coding tree unit specifying a number of coding tree units arranged vertically within one of the coding regions. can indicate the height of

According to an embodiment, the indication data is, for example, for a coding region of a plurality of coding regions, the last coding tree unit in said coding region is the last coding tree unit in said coding region horizontally preceding said coding tree unit. It can indicate whether it is smaller than another coding tree unit.

In a particular embodiment, the coding region may include, for example, a plurality of last coding tree units in the horizontal direction, and the last coding tree unit in the horizontal direction is one of the last coding tree units in the horizontal direction. is one. If the last coding tree unit in the horizontal direction in the coding region is less than the another coding tree unit in the coding region preceding the last coding tree unit in the horizontal direction, then a plurality of last coding tree units in the horizontal direction Each of the coding tree units can have the same width, for example.

In an embodiment, the indication data is, for example, for a coding region of a plurality of coding regions, the vertically last coding tree unit in said coding region is another coding tree unit in said coding region that vertically precedes said coding tree unit. It can indicate whether it is smaller than the coding tree unit.

In a particular embodiment, the coding region may include, for example, a plurality of vertically last coding tree units, wherein the vertically last coding tree unit is one of the plurality of vertically last coding tree units. is one. if the last coding tree unit in the vertical direction in the coding region is less than the another coding tree unit in the coding region preceding the last coding tree unit in the vertical direction, then a plurality of last vertical coding tree units Each of the coding tree units can have the same height, for example.

In an embodiment, the indication data is 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 one or more coding trees of said coding region is indicated. Indicates whether a starting address indicating said one of the units is not indicated.

According to embodiments, the instruction 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 embodiments, the indication data may indicate, for example, a plurality of coding region division positions.
According to embodiments, the indication data may indicate, for example, a plurality of coding region division positions as an ordered sequence.

In embodiments, the indication data may indicate, for example, the multiple coding region splitting positions as multiple coding region splitting position values, each of the multiple coding region splitting position values depending on the width of the image or Height dependent.

According to embodiments, the instruction data indicates 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. be able to.

In embodiments, the indication data may include, for example, one or more region-sequence stop flags for the coding regions of the one or more coding regions, and the region-sequence stop flags for the coding regions of the one or more coding regions. The region column stop flag may for example indicate the width of the coding region if the flag is set to a stop value. Alternatively, the indication data may include, for example, one or more region line stop flags for the coding regions of the one or more coding regions, wherein the region line stop flags for the coding regions of the one or more coding regions are When set to a stop value, the region line stop flag may indicate, for example, the height of the coding region.

According to embodiments, the indication data may indicate, for example, whether the 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 a picture boundary of a picture, the indication data are e.g. At least one of the region line stop flags may be included. 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 indication data is a region column stop flag of the coding tree unit. and/or does not include the region line stop flag of said coding tree unit.

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 is raster scan dependent, and the indication data is e.g. Contains information that can indicate that raster scanning was used to encode each coding region of one or more coding regions containing many coding tree units.

In embodiments, the indication data may indicate, for example, that diagonal scanning was used to encode each coding region of one or more coding regions comprising two or more coding tree units. including information that can be

In embodiments, the indication data may indicate that a z-scan was used to encode each of one or more coding regions comprising, for example, five or more coding tree units. .
In embodiments, the instructional data may indicate a scan order including, for example, one or more scan directions.

According to embodiments, for example, the indication data may indicate an index that may indicate, for example, the selected scanning direction of one or more scanning directions.
In embodiments, the indication data includes information about the error resilience of the encoded video sequence.

According to embodiments, the error resilience information may indicate, for example, one of three or more different error resilience conditions of the coded video sequence.

In embodiments, a first state of three or more different states may indicate, for example, that the access unit is not error resilient. A second state of three or more different states may indicate, for example, that the first plurality of access units of the image's parameter set is not error resilient. A third state of 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.

In another embodiment, the error resilience information may indicate, for example, one of four or more different states of error resilience of the encoded video sequence. A first state of four or more different states may indicate, for example, that error resilience is compromised at the image level, compromised at the multi-image level, and compromised at the sequence level. A second state of four or more different states may indicate, for example, that error resilience is compromised at the image level, is compromised at the multi-image level, but is not compromised at the sequence level. A third state of four or more different states, for example, indicates that error resilience is compromised at the image level, but error resilience is not compromised at the multiple image level and not at the sequence level. obtain. A fourth state of four or more different states may also indicate, for example, that error resilience is not compromised at the image level, is not compromised at the multi-image level, and is not compromised at the sequence level.

Although some aspects have been described in the context of apparatus, it is clear that these aspects also represent descriptions of corresponding methods, where blocks or devices correspond to method steps or features of method steps. Similarly, aspects described in the context of method steps also represent descriptions of corresponding blocks or items or functions of the corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus such as, for example, a microprocessor, programmable computer, or electronic circuitry. In some embodiments, one or more of the most critical method steps may be performed by such apparatus.

Depending on certain implementation requirements, embodiments of the invention can be implemented in hardware or software, or at least partially in hardware, or at least partially in software. Implementations can be performed using digital storage media such as floppy disks, DVDs, Blu-rays, CDs, ROMs, PROMs, EPROMs, EEPROMs, flash memories, etc., containing electronically readable control signals, and the respective It cooperates (or can cooperate) with a programmable computer system so that the method is performed. As such, a digital storage medium may be computer readable.

Some embodiments according to the present invention include a data carrier having electronically readable control signals operable to cooperate with a programmable computer system to perform one of the methods described herein. including.

Generally, embodiments of the 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. Program code may be stored, for example, in a machine-readable carrier.
Another embodiment includes a computer program stored on a machine-readable carrier for performing one of the methods described herein.

In other words, an embodiment of the method of the present invention is therefore a computer program having program code for performing one of the methods described herein when the computer program is run on a computer.

A further embodiment of the method of the invention is therefore a data carrier (or digital storage medium or computer readable medium) having recorded on it a computer program for performing one of the methods described herein. A data carrier, digital storage medium, or recorded medium is typically tangible and/or non-transitory.

A further embodiment of the method of the invention is therefore a data stream or sequence of signals representing a computer program for performing one of the methods described herein. A data stream or series of signals may be configured to be transferred over a data communication connection such as, for example, the Internet.

Further embodiments include processing means, such as a computer or programmable logic device, configured or adapted to perform one of the methods described herein.
A further embodiment includes a computer installed with a computer program for performing one of the methods described herein.

A further embodiment according to the present invention provides a device or system configured to transfer (e.g., electronically or optically) a computer program for performing one of the methods described herein to a receiver. include. A receiver can be, for example, a computer, mobile device, memory device, or the like. A device or system may include, for example, a file server for transferring computer programs to receivers.

In some embodiments, programmable logic devices (eg, field programmable gate arrays) can 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 method is preferably performed by any hardware device.

The devices described herein can be implemented using a hardware device, or using a computer, or using a combination of hardware devices and computers.

The methods described herein can be performed using hardware devices, or using computers, or using a combination of hardware devices and computers.

The above-described embodiments are merely illustrative of the principles of the 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 the intention, therefore, to be limited only by the scope of the immediate patent claims and not by the specific details presented in the description and explanation of the embodiments herein.

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.

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

Images