Coding method, decoding method, and correspondence device

Abstract

To provide a decoding method and a decoding device of decoding a block of an image in response to a division mode, and a coding method and device.SOLUTION: The decoding method of decoding a block of an image comprises determining a context for decoding a syntax element designated within video data, which contributes to signaling a position of division in a block. The context is a function of the shape of a block expressed by a tuple of the width of the block and the height of the block. The method includes performing arithmetic decoding of a context base of the syntax element, in response to the determined context.SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001]

[0001] In the following, a method and a device for encoding a picture are disclosed. A corresponding decoding method and a decoding device are also disclosed. [Background technology]

[0002] To achieve high compression efficiency, video coding schemes typically use prediction and transformation to exploit spatial and temporal redundancy within the video content. Generally, intra- or inter-prediction is used to exploit intra- or inter-frame correlation, and then the difference between the original and predicted image, often denoted as the residual, is transformed, quantized, and entropy coded. To reconstruct the video, the compressed data is decoded by the inverse process corresponding to prediction, transformation, quantization, and entropy coding.

[0003] In HEVC coding (ITU-T H.265 Telecommunication standardization sector of ITU (10 / 2014), series H: audiovisual and multimedia systems, infrastructure of audiovisual services - coding of moving video, High efficiency video coding, Recommendation ITU-T H.265), a picture is partitioned into square-shaped coding tree units (CTUs) with a configurable size, typically 64x64, 128x128, or 256x256. CTUs are the root of a quadtree partition into coding units (CUs). For each CU, a prediction mode is signaled, indicating whether the CU is coded using intra- or inter-prediction. The coding units are partitioned into one or more prediction units (PUs), which form the root of a quadtree (also called a transform tree) partition into transform units (TUs). PUs can have a square or rectangular shape, while TUs have a square shape. Asymmetric subdivision of a CU into PUs is also possible in inter prediction, i.e., if a CU has size N×N, the PUs can have sizes N / 4×N, 3N / 4×M, N×N / 4, N×3N / 4, as shown in Figure 1. Each PU is assigned some prediction information, such as motion information, spatial intra prediction, etc.

[0004]

[0004] The Quad-Tree plus Binary-Tree (QTBT) coding tool ("Algorithm Description of Joint Exploration Test Model 3," Document JVET-C1001_v3, Joint Video Exploration Team of ISO / IEC JTC1 / SC29 / WG11, 3rd meeting, May 26–June 1, 2015, Geneva, Switzerland) is a new video coding tool that provides a more flexible CTU representation than the CU / PU / TU arrangement in the HEVC standard. The Quad-Tree plus Binary-Tree (QTBT) coding tool defines a coding tree that can partition coding units in both quad-tree and binary-tree forms. Such a coding tree representation of a coding tree unit is shown in Figure 2, where solid lines indicate quad-tree partitions and dashed lines indicate binary-tree partitions of CUs.

[0005]

[0005] The division of a CTU into coding units (CUs) is determined at the encoder side, for example, via a rate-distortion optimization procedure that consists in determining the QTBT representation of the CTU with the minimum rate-distortion cost. In the QTBT representation, the CUs have either a square or rectangular shape. The size of the coding unit is always a power of two, typically ranging from 4 to 128. As shown in Figure 3, the QTBT decomposition of a CTU involves two stages: the CTU is first divided into four CUs in a quadtree form, and then each quadtree leaf can be further divided into two CUs in a binary form or into four CUs in a quadtree form. In Figure 3, the solid lines represent the quadtree division, and the dashed lines represent the binary division implemented spatially within the quadtree leaf.

[0006]

[0006] With the QTBT representation, a CU is not further divided into PUs or TUs. In other words, once the division of a CTU is determined, each CU is considered as a single prediction unit and a single transform unit. However, such a QTBT representation only allows symmetric division of a CU, as shown in Figure 4. Figure 4 shows four division modes allowed by QTBT. The mode NO_SPLIT indicates that a CU is not further divided, the mode QT_SPLIT indicates that a CU is divided into four quadrants according to a quadtree, the mode HOR indicates that a CU is divided horizontally into two CUs of equal size, and the mode VER indicates that a CU is divided vertically into two CUs of equal size. Summary of the Invention

[0007]

[0007] A decoding method for decoding a block of an image, comprising the steps of: - determining a partition mode of a block within a set of partition modes; - dividing the block into at least two sub-blocks in response to a division mode; decoding each of the at least two sub-blocks; wherein the set of partition modes includes at least one partition mode that asymmetrically partitions a block into at least two sub-blocks.

[0008] 1. A decoding device configured to decode a block of an image, the device comprising: means for determining a partition mode of a block within a set of partition modes; means for dividing the block into at least two sub-blocks in response to a division mode; means for decoding each of the at least two sub-blocks; and the set of partition modes includes at least one partition mode that asymmetrically divides a block into at least two sub-blocks.

[0009]

[0009] A decoding device including a communication interface configured to access at least a stream and at least one processor, the at least one processor comprising: - determining a partition mode for a block of the image within a set of partition modes; - dividing the block into at least two sub-blocks in response to a division mode; Decrypt each of at least two sub-blocks from the accessed stream. and the set of partition modes includes at least one partition mode that asymmetrically partitions a block into at least two sub-blocks.

[0010] The following embodiments apply to the decoding method and decoding device disclosed above.

[0011] Advantageously, the determination of the split mode is made by: - decoding a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; - decoding a second syntax element (horAsymmetricSplitFlag, verAsymmetricSplitFlag) that specifies whether the block is split symmetrically or asymmetrically; - decoding a split mode syntax element (vertical / horizontal_asymmetric_type) if the second syntax element specifies that the block is split asymmetrically; Includes.

[0012]

[0011] According to certain characteristics, the second syntax element, either horAsymmetricSplitFlag or verAsymmetricSplitFlag, is decoded from a single bit.

[0013]

[0012] In a variant, the second syntax element (horAsymmetricSplitFlag or verAsymmetricSplitFlag) is decoded by context-based arithmetic coding using a single context that depends on the value that the second syntax element takes when decoding a block that precedes the current block in decoding order.

[0014] In a variant, the second syntax element horAsymmetricSplitFlag is decoded by context-based arithmetic coding using two contexts that depend on the number of sub-blocks located in the left-neighboring block whose height is less than or equal to ¼ of the height of the current block. In the same way, the second syntax element verAsymmetricSplitFlag is decoded by context-based arithmetic coding using two contexts that depend on the number of sub-blocks located in the top-neighboring block whose width is less than or equal to ¼ of the width of the current block.

[0015]

[0014] According to a further embodiment, the context proposed in one of the preceding embodiments is indexed either as a function of the depth value of the quadtree+binary tree associated with the current block or as a function of the width and height of the block.

[0016] According to a particular characteristic, the split mode syntax elements (vertical_asymmetric_type / horizontal_asymmetric_type) are decoded from a single bit.

[0017]

[0016] In a variant, a split mode syntax element (either vertical_asymmetric_type or horizontal_asymmetric_type) is decoded by context-based arithmetic coding using a single context that depends on the value that the split mode syntax element takes when decoding a block preceding the current block in decoding order.

[0018]

[0017] In a variant, the partition mode syntax element horizontal_asymmetric_type is decoded by context-based arithmetic coding using three contexts that depend on the presence in a block located to the left of the current block of a frontier that spatially coincides with the horizontal frontier of the current block obtained through selection of a horizontal asymmetric partition of the current block.

[0019]

[0018] In the same manner, the partition mode syntax element vertical_asymmetric_type is decoded by context-based arithmetic coding using three contexts that depend on the presence in blocks located above the current block of a frontier that spatially coincides with the vertical frontier of the current block obtained through selection of a vertical asymmetric partition of the current block.

[0020]

[0019] According to a further embodiment, the context proposed in one of the preceding embodiments is indexed either as a function of the depth value of the quadtree+binary tree associated with the current block or as a function of the width and height of the block.

[0021] In a variant, the determination of the split mode is Decoding the syntax element (merge_with_next_CU_flag) that indicates that the block is to be merged with the next block in decoding order Includes.

[0022] In certain embodiments, the block is one of a block of luma samples, a block of chroma samples, or a coding unit formed by one block of luma samples and two blocks of chroma samples.

[0023]

[0022] In certain embodiments, dividing the block into at least two sub-blocks in response to the division mode includes dividing the block horizontally into one sub-block of height h / 4 and one sub-block of height 3h / 4, where h is the height of the block.

[0024]

[0023] In certain embodiments, dividing the block into at least two sub-blocks in response to the division mode includes vertically dividing the block into one sub-block of width w / 4 and one sub-block of width 3w / 4, where w is the width of the block.

[0025]

[0024] A coding method for encoding a block of an image, comprising the steps of: - determining a partition mode of a block within a set of partition modes; - dividing the block into at least two sub-blocks in response to a division mode; encoding each of the at least two sub-blocks; and the set of partition modes includes at least one partition mode that asymmetrically divides a block into at least two sub-blocks.

[0026] 1. A coding device configured to encode a block of an image, comprising: means for determining a partition mode of a block within a set of partition modes; means for dividing the block into at least two sub-blocks in response to a division mode; means for encoding each of the at least two sub-blocks; and wherein the set of partition modes includes at least one partition mode that asymmetrically divides a block into at least two sub-blocks.

[0027]

[0026] A coding device is disclosed that includes a communication interface configured to access at least a block of an image, designated a current block, and at least one processor. The at least one processor: - determining the partition mode of the block within the set of partition modes; - dividing the block into at least two sub-blocks in response to a division mode; -Encode each of at least two sub-blocks wherein the set of partition modes includes at least one partition mode that asymmetrically partitions a block into at least two sub-blocks.

[0028]

[0027] The following embodiments apply to the coding method and coding device disclosed above.

[0029] Advantageously, the determination of the split mode is - determining and encoding a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; - determining and encoding a second syntax element (horAsymmetricSplitFlag, verAsymmetricSplitFlag) that specifies whether the block is split symmetrically or asymmetrically; - if the second syntax element specifies that the block is split asymmetrically, determining and encoding a split mode syntax element (vertical_asymmetric_type / horizontal_asymmetric_type); Includes.

[0030] According to a particular characteristic, the second syntax element, either horAsymmetricSplitFlag or verAsymmetricSplitFlag, is coded using a single bit.

[0031]

[0030] In a variant, the second syntax element is coded by context-based arithmetic coding using a single context that depends on the value that the second syntax element takes when coding a block preceding the current block in coding order.

[0032] In a variant, the second syntax element horAsymmetricSplitFlag is coded by context-based arithmetic coding using two contexts that depend on the number of sub-blocks located in the left-neighboring block whose height is less than or equal to ¼ of the height of the current block. In the same way, the second syntax element verAsymmetricSplitFlag is coded by context-based arithmetic coding using two contexts that depend on the number of sub-blocks located in the top-neighboring block whose width is less than or equal to ¼ of the width of the current block.

[0033]

[0032] According to a further embodiment, the context proposed in one of the preceding embodiments is indexed either as a function of the depth value of the quadtree+binary tree associated with the current block or as a function of the width and height of the block.

[0034] According to a particular characteristic, the split mode syntax element (vertical_asymmetric_type / horizontal_asymmetric_type) is coded using a single bit.

[0035]

[0034] In a variant, the split mode syntax element is coded by context-based arithmetic coding using a single context that depends on the value that the split mode syntax element takes when coding the block preceding the current block in coding order.

[0036]

[0035] In a variant, the partition mode syntax element horizontal_asymmetric_type is encoded by context-based arithmetic coding using three contexts that depend on the presence in a block located to the left of the current block of a frontier that spatially coincides with the horizontal frontier of the current block obtained through selection of a horizontal asymmetric partition of the current block.

[0037]

[0036] In the same manner, the partition mode syntax element vertical_asymmetric_type is encoded by context-based arithmetic coding using three contexts that depend on the presence in a block located above the current block of a frontier that spatially coincides with the vertical frontier of the current block obtained through selection of a vertical asymmetric partition of the current block.

[0038]

[0037] According to a further embodiment, the context proposed in one of the preceding embodiments is indexed either as a function of the depth value of the quadtree+binary tree associated with the current block or as a function of the width and height of the block.

[0039] In another embodiment, the determination of the split mode is Determine and encode the syntax element (merge_with_next_CU_flag) that indicates that the block is to be merged with the next block in coding order. Includes.

[0040]

[0039] In an exemplary embodiment, the block is one of a block of luma samples, a block of chroma samples, or a coding unit formed by one block of luma samples and two blocks of chroma samples.

[0041]

[0040] In one embodiment, dividing the block into at least two sub-blocks in response to the division mode includes dividing the block horizontally into one sub-block of height h / 4 and one sub-block of height 3h / 4, where h is the height of the block.

[0042]

[0041] In one embodiment, dividing the block into at least two sub-blocks in response to the division mode includes vertically dividing the block into one sub-block of width w / 4 and one sub-block of width 3w / 4, where w is the width of the block.

[0043]

[0042] Also disclosed is a stream including coded data representing a block, wherein the coded data is obtained by determining a partitioning mode for the block within a set of partitioning modes, partitioning the block into at least two sub-blocks in response to the partitioning mode, and encoding each of the at least two sub-blocks into coded data, wherein the set of partitioning modes includes at least one partitioning mode that asymmetrically partitions the block into at least two sub-blocks.

[0044]

[0043] A non-transitory processor-readable medium is disclosed having a stream stored thereon, the stream including coded data representing a block, the coded data being obtained by determining a partitioning mode for the block within a set of partitioning modes, partitioning the block into at least two sub-blocks in response to the partitioning mode, and encoding each of the at least two sub-blocks into coded data, the set of partitioning modes including at least one partitioning mode that asymmetrically partitions the block into at least two sub-blocks.

[0045]

[0044] A transmission method is disclosed that includes transmitting coded data representing a block, wherein the coded data is obtained by determining a partitioning mode of the block within a set of partitioning modes, partitioning the block into at least two sub-blocks in response to the partitioning mode, and encoding each of the at least two sub-blocks into coded data, and the set of partitioning modes includes at least one partitioning mode that asymmetrically partitions the block into at least two sub-blocks.

[0046] Advantageously, the coded data is a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; a second syntax element (horAsymmetricSplitFlag, verAsymmetricSplitFlag) that specifies whether the block is split symmetrically or asymmetrically; - a partition mode syntax element (vertical / horizontal_asymmetric_type) if the second syntax element specifies that the block is to be partitioned asymmetrically Includes.

[0047] In a variant, the coded data includes a syntax element (merge_with_next_CU_flag) that indicates that the block is to be merged with the next block in coding order. [Brief explanation of the drawings]

[0048] [Figure 1]

[0047] FIG. 1 illustrates an asymmetric subdivision of a coding unit into prediction units according to the prior art. [Figure 2]

[0048] FIG. 1 illustrates the division of coding tree units into coding units according to the state of the art. [Figure 3]

[0048] FIG. 1 illustrates the division of coding tree units into coding units according to the state of the art. [Figure 4]

[0049] This figure shows the coding unit division modes defined by the Quad-Tree plus Binary-Tree coding tool. [Figure 5]

[0050] FIG. 1 illustrates an exemplary architecture of a transmitter configured to encode image blocks in a bitstream, according to a non-limiting embodiment. [Figure 6]

[0051] 12 illustrates an exemplary video encoder adapted to perform the encoding method of FIG. 7 and / or FIG. 11. [Figure 7]

[0052] 1 is a flow diagram illustrating a method for encoding blocks of an image in a bitstream, according to certain non-limiting embodiments. [Figure 8]

[0053] 10A and 10B are diagrams illustrating examples of asymmetric split modes according to the present principles; [Figure 9]

[0054] FIG. 10 illustrates an example of partitioning of CTUs into CUs according to present principles. [Figure 10]

[0055] FIG. 1 illustrates a graph representation of an encoding syntax. [Figure 11]

[0056] 1 is a flow diagram illustrating a method for encoding binomial split information of a current block according to a particular, non-limiting embodiment. [Figure 12]

[0057] FIG. 10 depicts an exemplary architecture of a receiver configured to decode image blocks from a bitstream to obtain decoded image blocks, according to a non-limiting embodiment. [Figure 13]

[0058] 16 is a block diagram illustrating an example video decoder adapted to perform the decoding methods of FIGS. 14 and / or 15. FIG. [Figure 14]

[0059] 1 is a flow diagram illustrating a method for decoding blocks of an image from a bitstream, according to certain non-limiting embodiments. [Figure 15]

[0060] 1 is a flow diagram illustrating a method for decoding a partition mode of a current block for a binomial partition, according to a particular, non-limiting embodiment. [Figure 16]

[0061] 1 illustrates the entropy coding process of a syntax element representing an asymmetric splitting mode in accordance with the present principles. [Figure 17] FIG. 10 illustrates the entropy coding process of a syntax element representing an asymmetric splitting mode in accordance with the present principles. [Figure 18]

[0062] FIG. 1 illustrates variations of the encoding syntax. DETAILED DESCRIPTION OF THE INVENTION

[0049]

[0063] It should be understood that the drawings and descriptions have been simplified to show elements relevant to a clear understanding of the present principles, while excluding, for the sake of clarity, many other elements found in typical encoding and / or decoding devices. While the terms "first" and "second" may be used to describe various elements herein, it should be understood that these elements should not be limited by these terms. These terms are used only to distinguish one element from another. Various methods are described above, each of which includes one or more steps or actions to achieve the described method. Unless a specific order of steps or actions is required for the correct operation of the method, the order and / or use of specific steps and / or actions can be varied or combined.

[0050]

[0064] A picture is an array of luma samples in monochrome format, or one array of luma samples and two corresponding arrays of chroma samples in 4:2:0, 4:2:2, and 4:4:4 color formats. Generally, a "block" addresses a specific area within the sample array (e.g., luma Y), and a "unit" includes co-located blocks of all coded color components (luma Y and possibly chroma Cb and chroma Cr). However, the term "block" is used herein to refer to either a block (e.g., CB) or a unit (e.g., CU).

[0051]

[0065] In the following sections, the terms "reconstructed" and "decoded" may be used interchangeably. Usually, but not necessarily, "reconstructed" is used on the encoder side, and "decoded" is used on the decoder side.

[0052] encoding device

[0066] FIG. 5 illustrates an exemplary architecture of a transmitter 200 configured to encode image blocks in a bitstream, according to a non-limiting embodiment.

[0053]

[0067] The transmitter 200 includes one or more processors 2000, which may include, for example, a CPU, a GPU, and / or a DSP (an English acronym for digital signal processor), along with internal memory 2030 (e.g., RAM, ROM, and / or EPROM). The transmitter 200 includes one or more communication interfaces 2010 (e.g., a keyboard, a mouse, a touchpad, a webcam), each adapted to display output information and / or allow a user to input commands and / or data (e.g., streams), and a power supply 2020, which may be external to the transmitter 200. The transmitter 200 may also include one or more network interfaces (not shown). The encoder module 2040 represents a module that may be included within a device to perform coding functions. Furthermore, the encoder module 2040 may be implemented as a separate element of the transmitter 200 or may be incorporated within the processor(s) 2000 as a combination of hardware and software, as known to those skilled in the art.

[0054]

[0068] The image blocks may be obtained from a source. According to different embodiments, the source may be: - Local memory, such as video memory, RAM, flash memory, hard disk, - a storage interface, for example an interface to a mass storage, ROM, optical disk, or magnetic support; a communication interface, for example a wired interface (e.g. a bus interface, a wide area network interface, a local area network interface) or a wireless interface (e.g. an IEEE 802.11 interface or a Bluetooth interface), - image capture circuitry (e.g., sensors such as CCD (i.e., charge-coupled device) or CMOS (i.e., complementary metal-oxide semiconductor) sensors); It can be, but is not limited to this.

[0055]

[0069] According to different embodiments, the bitstream can be sent to a destination. By way of example, the bitstream is stored in a remote or local memory, such as a video memory or RAM, or a hard disk. In variants, the bitstream is sent to a storage interface, such as an interface to a mass storage, a ROM, a flash memory, an optical disk, or a magnetic support, and / or transmitted via a communications interface, such as a point-to-point link, a communications bus, a point-to-multipoint link, or an interface to a broadcast network.

[0056]

[0070] According to an exemplary, non-limiting embodiment, the transmitter 200 further includes a computer program stored in the memory 2030. The computer program includes instructions that, when executed by the transmitter 200, specifically the processor 2000, enable the transmitter 200 to perform the encoding method described with reference to FIG. 7 and / or FIG. 11. According to a variant, the computer program is stored external to the transmitter 200 on a non-transitory digital data support, for example, on an external storage medium such as a HDD, a CD-ROM, a DVD, a read-only and / or DVD drive, and / or a DVD Read / Write drive, all known in the art. Thus, the transmitter 200 includes a mechanism for reading the computer program. Furthermore, the transmitter 200 can access one or more USB-type storage devices (e.g., "memory sticks") via a corresponding Universal Serial Bus (USB) port (not shown).

[0057]

[0071] According to an exemplary and non-limiting embodiment, the transmitter 200 includes: -Mobile devices and a communication device; -Gaming devices and -A tablet (or tablet computer) and -Laptop and -A still camera, -Video camera and - a coding chip or device / apparatus; a still image server; -Video servers (e.g. broadcast servers, video-on-demand servers, or web servers) It can be, but is not limited to this.

[0058]

[0072] FIG. 6 illustrates an exemplary video encoder 400 adapted to perform the encoding methods of FIGS. 7 and / or 11. The encoder 400 is an example of the transmitter 200 or can be part of such a transmitter 200. To encode a video sequence having one or more pictures, the pictures may be partitioned into square-shaped coding tree units (CTUs) of configurable size. A contiguous set of coding tree units may be grouped into slices. A CTU is the root of QTBT partitioning into coding units. In the exemplary encoder 400, pictures are encoded by the encoder modules described below. Each block is coded using either intra or inter mode. When a block is coded in intra mode, the encoder 400 performs intra prediction (module 460). In inter mode, motion estimation (module 475) and motion compensation (module 470) are performed. The encoder decides whether intra or inter mode should be used to code the block (module 405) and indicates the intra / inter decision by a prediction mode flag. A residual is calculated by subtracting a predicted sample block (also called a predictor) from the original image block (module 410).

[0059]

[0073] For example, a block is predicted from reconstructed neighboring samples in intra mode, while inter prediction is performed by motion compensation of reference blocks stored in the reference picture buffer 480.

[0060]

[0074] The residual is transformed (module 425) and quantized (module 430). The quantized transform coefficients as well as motion vectors and other syntax elements are entropy coded (module 445) to output a bitstream. The encoder can also skip the transform and apply quantization directly to the untransformed residual signal. The encoder can also bypass both the transform and quantization, i.e., the residual is coded directly without applying the transform or quantization processes. In direct PCM coding, no prediction is applied and block samples are coded directly into the bitstream.

[0061]

[0075] The encoder includes a decoding loop, which decodes coded blocks to provide references for further prediction. Quantized transform coefficients are dequantized (module 440) and inverse transformed (module 450) to decode the residual. Image blocks are reconstructed by combining the decoded residual with predicted sample blocks (module 455). An in-loop filter (465) can be applied to the reconstructed picture, for example to perform deblocking / sample adaptive offset (SAO) filtering to reduce coding artifacts. The filtered image is stored in a reference picture buffer 480.

[0062] Encoding method

[0076] FIG. 7 depicts a flow diagram of a method for encoding blocks of an image in a bitstream according to a particular, non-limiting embodiment.

[0063]

[0077] The method begins at step S200. In step S210, a transmitter, such as encoder 400, accesses a block of an image. The block has size w×h, where w is its width (in pixels) and h is its height (in pixels). The block is one of a coding block of luma samples, a coding block of chroma samples, or a coding unit formed by one coding block of luma samples and two coding blocks of chroma samples. In step S220, the transmitter determines a partitioning mode for the accessed block within a set of partitioning modes. In a particular embodiment, the determined partitioning mode is the partitioning mode that achieves the minimum rate-distortion cost within the set of partitioning modes. In accordance with present principles, the set of partitioning modes includes at least one asymmetric partitioning mode. FIG. 8 illustrates an example of such an asymmetric partitioning mode. In a first embodiment, the at least one asymmetric partitioning mode illustrates horizontally dividing the block into one sub-block of height h / 4 and one sub-block of height 3h / 4. The sub-block of height h / 4 is either above (mode HOR_UP) or below (mode HOR_DOWN) the sub-block of height 3h / 4. In another embodiment, at least one asymmetric splitting mode indicates vertically splitting the block into one sub-block of width w / 4 and one sub-block of width 3w / 4. The sub-block of width w / 4 is either to the left (mode VER_LEFT) or to the right (mode VER_RIGHT) of the sub-block of width 3w / 4. In a particular embodiment, the set of splitting modes includes all of the splitting modes shown in FIG. 8. In a variant embodiment, at least one asymmetric splitting mode indicates splitting the block either horizontally or vertically into sub-blocks whose size is not a power of two, for example, the size in width w or height h is 3·2 n is equal to the number of pixels, where n is an integer.

[0064]

[0078] In a variant, the set of partition modes includes the partition modes defined by QTBT and shown in Figure 4 in addition to at least one asymmetric partition mode. If the partition mode indicates that the block is not to be further partitioned (e.g., partition mode = NO_SPLIT), the block is coded in step S250.

[0065]

[0079] Otherwise, in step S230, the transmitter divides the accessed block into at least two sub-blocks in response to the determined division mode.

[0066]

[0080] In step S240, the transmitter encodes at least two sub-blocks in the bitstream. The encoding of the at least two sub-blocks may include recursively applying steps S220 to S250 for each of the at least two sub-blocks. The recursive splitting ends when the block is not to be split further, for example because a split mode NO_SPLIT is determined in step S220. In this case, the block is encoded in step S250 by applying the following steps: - applying the same prediction to the samples of said block to obtain a predicted block. - determining a residual block from said predicted block and said block; - applying the same transformation to the samples of said residual block to obtain a transformed block. - encoding, e.g., quantizing and entropy coding, said transformed blocks in a bitstream; Partition information indicating how the blocks are divided is also coded in the bitstream.

[0067]

[0081] The method ends in step S260.

[0068]

[0082] Advantageously, 3·2 nIn accordance with the present principles, a coding unit having a width or height equal to 3×2 may be selected by an encoder. In this case, intra- and / or inter-prediction of rectangular blocks having a size that is a multiple of 3 may be performed. Furthermore, coding units having a width or height equal to 3×2 may be selected by an encoder. n A 2D transform with a subsequent transform coefficient entropy coding process may also be performed.

[0069]

[0083] These additional coding unit topologies help to have a coding structure that spatially matches the structure and discontinuities contained in the original signal. An example of partitioning a CTU into CUs according to the present principles is shown in Figure 9. In this figure, quadtree partitioning is represented by solid lines, and binary partitioning (symmetric and asymmetric) is represented by dashed lines. Such partitioning (especially the gray CUs) cannot be obtained using the partitioning defined in HEVC or QTBT. The addition of the asymmetric partitioning mode in the case of binary partitioning improves coding efficiency by better matching the structure and discontinuities contained in the original signal.

[0070]

[0084] An exemplary syntax for encoding binary split information within a bitstream is defined in Tables 1 and 2. This syntax defines how various items of information are coded. The syntax elements btSplitFlag and btSplitOrientation used to encode the binary split modes defined in QTBT remain unchanged. The first syntax element, btSplitFlag, indicates whether the block (CU or CB) is split, and if so, the second syntax element, btSplitOrientation, indicates whether the block is split horizontally or vertically. The QTBT syntax is modified by adding new syntax elements that indicate the new split modes in Figure 8. Tables 1 and 2 are example syntaxes according to the present principles, with modifications to the QTBT syntax indicated in italics. Figure 10 is a graphical representation of the syntax defined in Tables 1 and 2. The added syntax elements are indicated by dashed lines in Figure 10. Syntax elements from QTBT are indicated by solid lines in Figure 10.

[0071]

[0085] The new syntax elements indicate whether the binomial partitioning is asymmetric and, if so, which asymmetric binomial partitioning mode is used. More precisely, the horAsysmmetricFlag and verAsysmmetricFlag syntax elements indicate whether the partitioning mode is asymmetric or not for the blocks to be binomial partitioned in the case of horizontal and vertical partitioning, respectively.

number

number

[0072] In a particular embodiment, the syntax elements horAsysmmetricFlag and

number

number

[0073]

[0086] FIG. 11 depicts a flow diagram of a method for encoding binomial split information of a current block according to a specific, non-limiting embodiment using the modified syntax defined in Tables 1 and 2.

[0074]

[0087] Only the steps related to binomial split mode encoding of the current block are depicted in Figure 11. The method begins at step S2000. At step S2010, a transmitter 200, such as encoder 400, accesses the current block.

[0075]

[0088] In step S2020, the sender 200 checks whether a binomial partition is allowed for the current block. This typically consists in checking whether the width (w) of the current block or the height (h) of the current block is greater than a first threshold (minBTSize). A typical minimum rectangular block size in width or height is minBTSize=4. If not, the block is not partitioned and no other syntax elements related to the partition are coded.

[0076]

[0089] If not (binary splitting is allowed), then in step S2030, a first flag (btSplitFlag) is encoded to indicate whether the current block is split or not. An example btSplitFlag can take the value 1 or True to indicate that the current block is split, and the value False or 0 to indicate that the current block is not split. In step S2040, the transmitter 200 checks whether the first flag indicates that the current block is split or not.

[0077]

[0090] In step S2040, if the first flag indicates that the current block is not split (eg, because btSplitFlag=False), no other syntax elements related to splitting are coded.

[0078]

[0091] Otherwise, if in step S2040 the first flag indicates that the current block is split (e.g., because btSplitFlag=True), then in step S2050 the transmitter 200 determines whether horizontal, vertical, asymmetric horizontal, and asymmetric vertical split modes are allowed for the current block.

[0079]

[0092] As an example, vertical split mode is allowed if the condition (w>minBTSize && w%3≠0) is true, where % is the modulo operator: w%3 returns the remainder after division of w by 3. Typically, minBTSize may be equal to 4, and vertical split mode is allowed if w is equal to 8, 16, or 32.

[0080]

[0093] In this case, the vertical_allowed parameter can be set to the value 1 or true. As an example, horizontal split mode is allowed if the condition (h>minBTSize && h%3≠0) is true. In this case, the horizontal_allowed parameter can be set to the value 1 or true. As an example, vertical asymmetric split mode is allowed if the condition vertical allowed && w>8 is true. As an example, a horizontally asymmetric split mode is allowed if the condition horizontal allowed && h>8 is true. Thus, typical allowable block widths or heights resulting from asymmetric horizontal or vertical divisions are 16 / 4=4, 16*3 / 4=12, 32 / 4=8, 32*3 / 4=24.

[0081]

[0094] In this embodiment, if a block has already been split asymmetrically, we do not allow further splitting of the block in a direction where the block has a size that is a multiple of 3. Furthermore, some restriction on the block size is imposed to allow asymmetric splitting of the block. Typically, the block size must be greater than 8. In this case, the smallest block size that is a multiple of 3 is 12.

[0082]

[0095] In certain embodiments, the size is 3.2 in one direction. n , a binomial division of a block equal to n ≥ 1 is allowed along that direction if the block to be divided has a size that is a multiple of 2. This means that the division of a block can lead to a block size of 3. For example, a block 12x4 can be divided into two sub-blocks, each with a size of 6x4.

[0083]

[0096] In another particular embodiment, an asymmetric division of a block is allowed if its size exceeds 8 and is a power of 2. For example, this allows an asymmetric division of a block with size 8x4 into two sub-coding units with sizes 6x4 and 2x4. This may be possible specifically for chroma components if the QTBT tool allows block sizes down to 2. In that case, the condition vertical allowed && w>8 is the condition vertical allowed && w≧8. Similarly, in that case, the condition horizontal allowed && w>8 is the horizontal condition allowed && is replaced with w≧8.

[0084]

[0097] In step S2060, the transmitter 200 checks whether both horizontal split mode and vertical split mode are allowed. If so, in step S2070, a syntax element (btSplitOrientation) is coded to indicate the binary split orientation (horizontal or vertical). If either horizontal split or vertical split is not allowed, this syntax element (btSplitOrientation) is not coded. In this latter case, the binary split orientation is inferred at the decoder side as follows: If horizontal split is not allowed, btSplitOrientation is inferred to be equal to VER. Otherwise, if vertical split is not allowed, btSplitOrientation is inferred to be equal to HOR.

[0085]

[0098] Then, in step S2080 (for horizontal splitting) or step S2090 (for vertical splitting), the transmitter 200 checks whether asymmetric splitting mode is allowed along this orientation. If not, no further syntax elements related to splitting are coded. In this latter case, the binary splitting mode is inferred to be HOR or VER at the decoder side, depending on the btSplitOrientation value.

[0086]

[0099] Otherwise, a syntax element (horAsymmetricSplitFlag or verAsymmetricSplitFlag) is coded to indicate whether asymmetric splitting is used for the current block (in step S2082 or S2092).

[0087]

[0100] As an example, horAsymmetricSplitFlag (respectively, verAsymmetricSplitFlag) may take the value 1 or True to indicate that the current block is split asymmetrically, or may take the value False or 0 to indicate that the current block is not split asymmetrically. In step S2084 (respectively, S2094), transmitter 200 checks whether the current block is split asymmetrically horizontally (respectively, vertically).

[0088]

[0101] If asymmetric splitting is not used (e.g., horAsymmetricSplitFlag is False in step S2084 or verAsymmetricSplitFlag is False in step S2094), no further syntax elements related to splitting are coded. If asymmetric splitting is used (horAsymmetricSplitFlag is True in step S2084 or verAsymmetricSplitFlag is True in step S2094), another syntax element (horizontal_asymmetric_type or vertical_asymmetric_type) is coded (in step S2086 or S2096) to indicate the asymmetric splitting mode of the current block.

[0089]

[0102] The horizontal_asymmetric_type can take the values ​​HOR_UP or HOR_DOWN, and the vertical_asymmetric_type can take the values ​​VER_LEFT or VER_RIGHT.

[0090]

[0103] The method ends in step S2100.

[0091] Decryption device

[0104] FIG. 12 illustrates an exemplary architecture of a receiver 100 configured to decode image blocks from a bitstream to obtain decoded image blocks, according to a non-limiting embodiment.

[0092]

[0105] The receiver 100 includes one or more processors 1000, which may include, for example, a CPU, a GPU, and / or a DSP (an English acronym for digital signal processor), along with internal memory 1030 (e.g., RAM, ROM, and / or EPROM). The receiver 100 includes one or more communication interfaces 1010 (e.g., a keyboard, a mouse, a touchpad, a webcam), each adapted to display output information and / or allow a user to input commands and / or data (e.g., decoded image blocks), and a power supply 1020, which may be external to the receiver 100. The receiver 100 may also include one or more network interfaces (not shown). The decoder module 1040 represents a module that may be included within a device to perform decoding functions. Furthermore, the decoder module 1040 may be implemented as a separate element of the receiver 100 or may be incorporated within the processor(s) 1000 as a combination of hardware and software, as known to those skilled in the art.

[0093]

[0106] The bitstream may be obtained from a source. According to different embodiments, the source may be: - Local memory, such as video memory, RAM, flash memory, hard disk, - a storage interface, for example an interface to a mass storage, ROM, optical disk, or magnetic support; a communication interface, for example a wired interface (e.g. a bus interface, a wide area network interface, a local area network interface) or a wireless interface (e.g. an IEEE 802.11 interface or a Bluetooth interface), - picture capture circuitry (e.g., sensors such as CCD (i.e., charge-coupled device) or CMOS (i.e., complementary metal-oxide semiconductor) sensors); It can be, but is not limited to this.

[0094]

[0107] According to different embodiments, the decoded image blocks may be sent to a destination, for example a display device. By way of example, the decoded image blocks are stored in a remote or local memory, for example a video memory or RAM, or a hard disk. In variants, the decoded image blocks are sent to a storage interface, for example an interface to a mass storage, a ROM, a flash memory, an optical disk, or a magnetic support, and / or transmitted via a communications interface, for example a point-to-point link, a communications bus, a point-to-multipoint link, or an interface to a broadcast network.

[0095]

[0108] According to a specific, non-limiting embodiment, the receiver 100 further includes a computer program stored in the memory 1030. The computer program includes instructions that, when executed by the receiver 100, specifically the processor 1000, enable the receiver to perform the decoding method described with reference to FIG. 14 and / or FIG. 15. According to a variant, the computer program is stored external to the receiver 100 on a non-transitory digital data support, for example, on an external storage medium such as a HDD, a CD-ROM, a DVD, a read-only and / or DVD drive, and / or a DVD Read / Write drive, all known in the art. Thus, the receiver 100 includes a mechanism for reading the computer program. Furthermore, the receiver 100 can access one or more USB-type storage devices (e.g., "memory sticks") via a corresponding Universal Serial Bus (USB) port (not shown).

[0096]

[0109] According to an exemplary, non-limiting embodiment, receiver 100 includes: -Mobile devices and a communication device; -Gaming devices and -Set-top boxes and -TV set and -A tablet (or tablet computer) and -Laptop and -Video players, such as Blu-ray players, DVD players, -Display and -Decoding chip or decoding device / apparatus It can be, but is not limited to this.

[0097]

[0110] Figure 13 shows a block diagram of an exemplary video decoder 300 adapted to perform the decoding methods of Figures 14 and / or 15. The video decoder 300 is an example of, or may be part of, the receiver 100. In the exemplary decoder 300, the bitstream is decoded by a decoder module as described below. The video decoder 300 generally performs a decoding pass that is the reciprocal of the encoding pass performed by the video encoder 400 described in Figure 6.

[0098]

[0111] Specifically, the decoder input includes a video bitstream, which may be generated by the video encoder 400. The bitstream is first entropy decoded (module 330) to obtain transform coefficients, motion vectors, and other coded information. The transform coefficients are dequantized (module 340) and inverse transformed (module 350) to decode the residual. The decoded residual is then combined with a predicted sample block (also referred to as a predictor) to obtain a decoded / reconstructed image block (module 355). The predicted sample block may be obtained from intra-prediction (module 360) or motion-compensated prediction (i.e., inter-prediction) (module 375) (module 370). An in-loop filter (module 365) may be applied to the reconstructed image. The in-loop filter may include a deblocking filter and a SAO filter. The filtered image is stored in a reference picture buffer 380.

[0099] Decryption method

[0112] 14 illustrates a flow diagram of a method for decoding a block of an image from a bitstream according to a specific, non-limiting embodiment. The block is of size w×h, where w is its width in pixels and h is its height in pixels. The block is one of a block of luma samples, a block of chroma samples, or a coding unit formed by one block of luma samples and two blocks of chroma samples.

[0100]

[0113] The method begins at step S100. In step S110, a receiver 100, such as decoder 300, accesses a bitstream or a portion thereof representing the block to be decoded.

[0101]

[0114] In step S120, the receiver determines a partition mode for the block within the set of partition modes. The partition mode is, for example, decoded from the bitstream. According to the present principles, the set of partition modes includes at least one asymmetric partition mode. FIG. 8 shows examples of such asymmetric partition modes. In a first embodiment, the at least one asymmetric partition mode indicates a horizontal division of the block into one sub-block of height h / 4 and one sub-block of height 3h / 4. The sub-block of height h / 4 is either above (mode HOR_UP) or below (mode HOR_DOWN) the sub-block of height 3h / 4. In another embodiment, the at least one asymmetric partition mode indicates a vertical division of the block into one sub-block of width w / 4 and one sub-block of width 3w / 4. The sub-block of width w / 4 is either to the left (mode VER_LEFT) or to the right (mode VER_RIGHT) of the sub-block of width 3w / 4. In a particular embodiment, the set of partition modes includes all of the partition modes shown in FIG. 8. In a variant embodiment, at least one asymmetric division mode indicates dividing a block either horizontally or vertically into sub-blocks whose size is not a power of 2, e.g., the size in width or height is not a power of 3·2. n where n is an integer.

[0102]

[0115] In a variant, the set of split modes includes at least one asymmetric split mode plus the split modes defined by QTBT and shown in Figure 4. If the split mode indicates that the block is not to be split further (NO_SPLIT), the block is decoded in step S150.

[0103]

[0116] Otherwise, in step S130, the receiver divides the accessed block into at least two sub-blocks in response to the determined division mode.

[0104]

[0117] In step S140, the transmitter decodes each of the at least two sub-blocks. The decoding of the at least two sub-blocks may include recursively applying steps S120 to S140 to each of the at least two sub-blocks. The recursive splitting ends when the block is not to be split further, for example because a split mode NO_SPLIT is determined in step S120. In this case, the block is decoded in step S150 by applying the following steps: - decoding, e.g. entropy decoding and dequantizing, the transformed blocks of said sub-blocks; - applying the same transformation (the inverse of that used at the encoder side) to the samples of said decoded transformed block to obtain a residual block. applying the same prediction to the samples of said sub-blocks to obtain a predicted block. - reconstructing said sub-blocks from said predicted block and said residual block.

[0105]

[0118] The method ends in step S160.

[0106]

[0119] Partition information indicating how the blocks are divided is also decoded from the bitstream.

[0107]

[0120] FIG. 15 illustrates a flow diagram of a method for decoding the partition mode of the current block in the case of a binary partition, according to a specific, non-limiting embodiment using the modified syntax defined in Tables 1 and 2.

[0108]

[0121] Only the steps relevant to binomial split mode decoding of the current block are depicted in Figure 15. The method begins at step S1000. In step S1010, a receiver 100, such as decoder 300, accesses a bitstream or portion thereof representing the current block to be decoded.

[0109]

[0122] In step S1020, receiver 100 checks whether binary splitting is allowed for the current block being decoded. This typically consists in checking whether the width (w) of the current block or the height (h) of the current block is greater than a first threshold (minBTSize). A typical minimum rectangular block size in width or height is minBTSize=4. If binary splitting is not allowed, the block is not split (in step S1045, btSplitMode is set to NO_SPLIT) and other syntax elements related to splitting are not decoded.

[0110]

[0123] If not (binary splitting is allowed), in step S1030, a first flag (btSplitFlag) indicating whether the current block is split or not is decoded from the bitstream.

[0111]

[0124] In step S1040, receiver 100 checks whether the current block is split. If the current block is not split (e.g., btSplitFlag is False in step S1040), other syntax elements related to splitting are not decoded. In step S1045, btSplitMode is set to NO_SPLIT.

[0112]

[0125] If the current block is split (btSplitFlag is True in step S1040), then in step S1050, receiver 100 determines whether horizontal, vertical, asymmetric horizontal, and asymmetric vertical split modes are allowed for the current block. Step S1050 is the same as step S2050 in FIG. 11.

[0113]

[0126] In step S1060, receiver 100 checks whether both horizontal split mode and vertical split mode are allowed. If so, in step S1070, it decodes the syntax element (btSplitOrientation) to indicate the binary split orientation (horizontal or vertical). If either horizontal split or vertical split is not allowed, this syntax element (btSplitOrientation) is not decoded. In this latter case, in step S1065, it infers the binary split orientation. If horizontal split is not allowed, it infers btSplitOrientation to be equal to VER. Otherwise, if vertical split is not allowed, it infers btSplitOrientation to be equal to HOR.

[0114]

[0127] Receiver 100 then checks in step S1080 (for horizontal split) or step S1090 (for vertical split) whether asymmetric splitting is allowed along this orientation. If not, no further syntax elements related to splitting are decoded. In this latter case, the binary splitting mode is inferred to be HOR or VER depending on the btSplitOrientation value (btSplitMode is set to btSplitOrientation in step S1085).

[0115]

[0128] If not, a syntax element (horAsymmetricSplitFlag or verAsymmetricSplitFlag) indicating whether asymmetric splitting is used for the current block is decoded (at step S1082 or S1092). In step S1084 (respectively, S1094), receiver 100 checks whether the current block is asymmetrically split horizontally (respectively, vertically).

[0116]

[0129] If asymmetric splitting is not used (horAsymmetricSplitFlag or verAsymmetricSplitFlag is not True), no further syntax elements related to splitting are decoded. If asymmetric splitting is used (horAsymmetricSplitFlag or verAsymmetricSplitFlag is True), the syntax element indicating the asymmetric splitting mode of the current block (horizontal_asymmetric_type or vertical_asymmetric_type) is decoded (in step S1086 or S1096).

[0117]

[0130] The horizontal_asymmetric_type can take the values ​​HOR_UP or HOR_DOWN, and the vertical_asymmetric_type can take the values ​​VER_LEFT or VER_RIGHT.

[0118]

[0131] If horizontal_asymmetric_type takes the value HOR_UP, then the binomial split mode (btSplitMode) is set equal to HOR_UP.

[0119]

[0132] If horizontal_asymmetric_type takes the value HOR_DOWN, then the binomial split mode is set equal to HOR_DOWN.

[0120]

[0133] If vertical_asymmetric_type takes the value VER_LEFT, then the binomial split mode is set equal to VER_LEFT.

[0121]

[0134] If horizontal_asymmetric_type takes the value VER_LEFT, then the binomial split mode is set equal to VER_LEFT.

[0122]

[0135] The method ends in step S1100.

[0123] Entropy coding and decoding of syntax elements

[0136] The new syntax elements verAsymmetricSplitFlag and horAsymmetricSplitFlag can be coded differently. In a first embodiment, verAsymmetricSplitFlag (respectively, horAsymmetricSplitFlag) is coded using a single bit in the bitstream. This is optimal if and only if the symmetric and asymmetric splitting modes have equal probability, i.e., verAsymmetricSplitFlag (respectively, horAsymmetricSplitFlag) has a probability of 0.5 being equal to true. In that case, the average amount of information carried by each of these syntax elements is equal to 1 bit, and fixed-length coding using 1 bit is optimal.

[0124]

[0137] In most practical cases, the symmetric and asymmetric splitting modes are likely not equally probable. Therefore, according to another embodiment, context-based arithmetic coding is used to encode the syntax elements verAsymmetricSplitFlag and horAsymmetricSplitFlag. Context-based arithmetic coding includes context modeling and arithmetic coding. In a particular embodiment, context-based arithmetic coding can include binarization of the syntax elements before context modeling. Binarization and arithmetic coding are well known from previous coding schemes (e.g., H.264 and HEVC). Context modeling estimates the probability of each syntax element based on some context and applies it symmetrically on the encoder and decoder sides. The following embodiments disclosed with respect to entropy coding also apply to entropy decoding. Therefore, new contexts are defined for the new syntax elements horAsymmetricFlag and verAsymmetricFlag.

[0125]

[0138] In this embodiment, two simple contexts are used, each associated with a syntax element, horAsymmetricFlag and verAsymmetricFlag. Each of these contexts depends only on the value taken by the associated syntax element itself in the past (i.e., when encoding the block preceding the current block in coding order). Therefore, this asymmetric splitting mode information can be coded over an average amount of information approaching the first-order entropy of the random variable represented by the considered syntax element. Therefore, these syntax elements are coded over less than one bit on average, even if the statistical distribution of these flags is not uniform. In this variant of context-based coding, the contexts used for horAsymmetricFlag and verAsymmetricFlag are identical. Indeed, the coding of these two syntax elements can share the same context. This should be efficient, assuming that the probability of horAsymmetricFlag being TRUE or FALSE and knowing that the current block is binomial split in the horizontal direction is close to the probability of verAsymmetricFlag being TRUE or FALSE and knowing that the current block is binomial split in the vertical direction.

[0126]

[0139] In a third embodiment, the syntax elements verAsymmetricSplitFlag and horAsymmetricSplitFlag are entropy coded as a function of some context information about the split configuration already determined in the preceding neighboring block. When asymmetric splitting is used for the current block, one of the two sub-blocks has a size equal to 1 / 4 of the size of the current block in width or height. This means that the original signal of the current block contains some spatial activity or discontinuity, and it is worthwhile to split the current block in terms of coding efficiency. Such high spatial activity or discontinuity is likely also present in the neighboring block preceding the current block in coding order.

[0127]

[0140] The context is defined to encode the asymmetric split syntax element as a function of the number of sub-blocks with a size equal to or smaller than 1 / 4 of the size of the current block along the considered split orientation, which takes the following form for horizontal and vertical asymmetric split contexts, respectively: -nbQuarterHeightSubCU=in the left adjacent block

number

[0128]

[0141] According to equation (1), two different contexts are used for coding the horAsymmetricSplitFlag syntax element: If the value nbQuarterHeightSubCU is strictly greater than 0, then the first context (with index 0) is used to code the binary symbol corresponding to horAsymmetricSplitFlag. In the opposite case, if the value nbQuarterHeightSubCU is equal to 0, then the second context (with index 1) is used to code the binary symbol corresponding to horAsymmetricSplitFlag.

[0129]

[0142] The left-neighboring block corresponds to a block whose height is equal to or greater than the height of the current block and whose right boundary has an x-coordinate equal to the x-coordinate of the left boundary of the current block minus 1. The left-neighboring block may be divided into one or more sub-blocks in the height direction. -nbQuarterWidthSubCU=in the upper adjacent block

number

[0130]

[0143] According to equation (2), two different contexts are used to code the verAsymmetricSplitFlag syntax element: If the value nbQuarterWidthSubCU is strictly greater than 0, the first context (with index 0) is used to code the binary symbol corresponding to verAsymmetricSplitFlag. In the opposite case, if the value nbQuarterWidthSubCU is equal to 0, the second context (with index 1) is used to code the binary symbol corresponding to verAsymmetricSplitFlag.

[0131]

[0144] An upper neighboring block corresponds to a block whose width is equal to or greater than the width of the current block and whose bottom boundary has a y coordinate equal to the y coordinate of the top boundary of the current block minus 1. An upper neighboring block may be divided into one or more sub-blocks in the width direction.

[0132]

[0145] According to another embodiment, the context used to code the asymmetric split flags verAsymmetricSplitFlag and horAsymmetricSplitFlag is determined as a function of the presence of a neighboring block having a size equal to or greater than half the size of the current block in width and height, respectively. This takes the following form: First, the context used to code the coding of the element horAsymmetricSplitFlag is determined as follows: - Determine whether the block located to the left of the top left corner of the current CU has a height that is more than half the height of the current block. - Determine whether the block located to the left of the bottom left corner of the current CU has a height that is more than half the height of the current block. If one of the above tests is positive, give horAsymmetricSplitCtxt the value 0. - If not, give horAsymmetricSplitCtxt a value of 1.

[0133]

[0146] Similarly, the context used to code the coding of the element verAsymmetricSplitFlag is determined as follows: - Determine whether the block located above the top left corner of the current CU has a width greater than 1 / 2 the width of the current block. - Determine whether the block located above the top right corner of the current CU has a width greater than 1 / 2 the width of the current block. If one of the above tests is positive, give verAsymmetricSplitCtxt the value 0. -If not, give verAsymmetricSplitCtxt a value of 1.

[0134]

[0147] According to a further embodiment, several separate contexts are used to code / decode horAsymmetricSplitFlag and verAsymmetricSplitFlag according to the slice type (INTRA or INTER). Within INTER slices, the context determination method described above is used. Within INTRA slices, for horAsymmetricSplitFlag and verAsymmetricSplitFlag, respectively, a single context is used to capture the statistical behavior of these two flags, regardless of the contextual block size information available when coding / decoding these flags.

[0135]

[0148] The advantage of this embodiment is that it better models the statistical dependency between the coded flags and neighboring block information, especially in INTER slices, which lowers the rate cost associated with coding these flags.

[0136]

[0149] According to a further embodiment, the contexts proposed in one of the preceding embodiments are indexed as a function of the depth value of the quadtree+binary tree associated with the current block. Thus, a separate set of contexts is used for each depth level in the quadtree+binary tree representation of the CTU. Advantageously, more accurate contexts are used to model the statistical behavior of the syntax elements being coded / decoded.

[0137]

[0150] In a third embodiment, two different sets of contexts are used to perform context-adaptive coding of the syntax elements horAsymmetricSplitFlag and verAsymmetricSplitFlag. The sets of contexts are therefore denoted as follows: ·horAsymmetricSplitFlagCtx[0..1] ·verAsymmetricSplitFlagCtx[0..1]

[0138]

[0151] In this embodiment, the contexts are indexed by the depth of the processed block in the quadtree+binary tree CTU representation, and therefore the above two sets of contexts are further indexed based on depth level. ·horAsymmetricSplitFlagCtx[0...maxDepth][0..1] ·verAsymmetricSplitFlagCtx[0...maxDepth][0..1] Here, maxDepth represents the maximum depth of a block, where depth means the sum of the quadtree depth and binary tree depth of the current block.

[0139]

[0152] According to a further embodiment, the contexts proposed in one of the preceding embodiments are indexed as a function of the block shape, i.e., width and height. This means that a separate set of contexts is used for each possible coding size tuple (w, h). An advantage of this embodiment is an even improved context for modeling the statistical behavior of the syntax elements being coded / decoded. Advantageously, more accurate contexts are used to model the statistical behavior of the syntax elements being coded / decoded.

[0140]

[0153] In this embodiment, the context is indexed by the log2 of the width and the log2 of the height of the block. ·horAsymmetricSplitFlagCtx[0...maxLog2CUHeight][0..1] ·verAsymmetricSplitFlagCtx[0...maxLog2CUWidth][0..1] where maxLog2CUWidth and maxLog2CUHeight represent the log2 of the maximum possible block width and block height equal to a power of two.

[0141]

[0154] As asymmetric splitting can only be applied to block sizes equal to a power of two, the context is associated with block sizes equal to a power of two.

[0142]

[0155] The new syntax elements horizontal_asymmetric_type or vertical_asymmetric_type may be coded differently: In a first embodiment, horizontal_asymmetric_type (respectively vertical_asymmetric_type) is coded with a single bit in the bitstream.

[0143]

[0156] This is optimal only if the horizontal_asymmetric_type or vertical_asymmetric_type syntax elements have equal probability.

[0144]

[0157] According to another embodiment, context-based arithmetic coding is used to code the syntax elements horizontal_asymmetric_type or vertical_asymmetric_type. In this embodiment, two simple contexts are used, which are associated with each syntax element horizontal_asymmetric_type or vertical_asymmetric_type, respectively. Each of these contexts depends only on the value taken by the relevant syntax element itself in the past (e.g., when encoding a preceding block in coding order). In this variant of context-based coding, the contexts used for horizontal_asymmetric_type and vertical_asymmetric_type can be identical. Thus, the coding of these two syntax elements can share the same context. This should be efficient, assuming that the probability of horizontal_asymmetric_type being TRUE or FALSE and knowing that the current block is binomially asymmetric in the horizontal direction is close to the probability of vertical_asymmetric_type being TRUE or FALSE and knowing that the current block is binomially asymmetric in the vertical direction.

[0145]

[0158] In a third embodiment, these syntax elements horizontal_asymmetric_type or vertical_asymmetric_type are entropy coded as a function of some context information about the partitioning configuration already determined in the preceding neighboring block, as shown in Figures 16 and 17. For horizontal asymmetric partitioning, if the partitioning frontier in the previous block to the left of the current block (F1 in Figure 16) is present and spatially coincides with the horizontal frontier that would appear in the current block via the selection of the horizontal asymmetric partitioning, the probability of using this asymmetric partitioning in the current block is increased.

[0146]

[0159] This principle is illustrated in Figure 16. On the left side of this figure, a candidate HOR_UP partition mode is being evaluated within a current block, and the neighboring block on the left has not been partitioned. The probability of using the HOR_UP partition mode for the current block in this case is lower than in the case shown on the right side of Figure 16. Indeed, in this latter case, the neighboring block was coded using a partitioning configuration that includes a horizontal frontier that would be propagated into the current block by the selection of the HOR_UP partition mode. The selection of the HOR_UP partition mode for the current block is more likely to occur in this case than in the previous case shown on the left side of Figure 16.

[0147]

[0160] This principle is also illustrated in Figure 17 in the case of vertical asymmetric partitioning. The VER_RIGHT partitioning mode has a higher probability of being used to code the current block in the case shown on the right of Figure 17 than in the case on the left of Figure 17, because the right case propagates the vertical frontier F2 to the current block from the neighboring block located above it.

[0148]

[0161] Based on this principle, the following contexts are used for the syntax elements

number

number

number

number

[0149] According to equation (3), there are three different contexts:

number

number

number

number

number

number

number

number

[0150] The following contexts apply to the syntax element

number

number

number

number

[0151] According to equation (3), there are three different contexts:

number

number

number

number

number

number

number

number

[0152] According to another embodiment, the syntax element

number

number

number

Number

Number

Number

Number

Number

Number

Number

Number

[0154] <0****888><0****889><0****890>

Number

Number

Number

number

[0155]

[0162] The advantage of this embodiment is that it better models the statistical dependency between the coded flags and neighboring block information, especially in INTER slices, which lowers the rate cost associated with coding these flags.

[0156]

[0163] According to a further embodiment, the contexts proposed in one of the preceding embodiments are indexed as a function of the depth value of the quadtree+binary tree associated with the current block. This means that a separate set of contexts is used for each depth level in the quadtree+binary tree representation of the CTU. The same principles apply as defined for the verAsymmetricSplitFlag and horAsymmetricSplitFlag syntax elements. An advantage of this embodiment is more accurate contexts used to model the statistical behavior of the syntax elements being coded / decoded.

[0157]

[0164] According to a further embodiment, the contexts proposed in one of the preceding embodiments are indexed as a function of the coding unit's shape, i.e., width and height. This means that a separate set of contexts is used for each possible coding size tuple (w, h). The same principles apply as defined for the verAsymmetricSplitFlag and horAsymmetricSplitFlag syntax elements. The advantage of this embodiment is further improved contexts for modeling the statistical behavior of the syntax elements being coded / decoded.

[0158] Syntax Variants of Tables 1 and 2

[0165] Variations on the syntax defined in Tables 1 and 2 are shown in Table 3, including: - Identifying, for the current block, whether it can be spatially merged with an adjacent block to form an asymmetric sub-block of the parent block. The parent block can be the parent block of the current block (case 1) or the parent block of the current block's parent (case 2). This step is performed identically on the encoder and decoder sides.

[0159]

[0166] An example of Case 1 is shown at the top of Figure 18. In this figure, the upper sub-block, shaded in grey, can be merged with the next sub-block to form an asymmetric part of the parent of the current block.

[0160]

[0167] An example of Case 2 is shown at the bottom of Figure 18. The current block is the gray-shaded block. In this figure, the current block can be merged with the next sub-block (named nextSubCU in Figure 18) to form an asymmetric part of the block, called CU' in Figure 18. -Size 3·2 n To form an asymmetric block with , we code a syntax element called merge_with_next_CU for the current block, which indicates whether it should be merged with the next block in processing order.

[0161]

[0168] To support this embodiment with minimal changes to the initial QTBT coding syntax, the QTBT syntax is unchanged for coding binary tree and binary split modes. [Table 3] Table 3

[0162]

[0169] A new syntax element called "merge_with_next_CU_flag" is introduced before block coding when a block is not split. This flag indicates that the block involved is not yet coded at this stage of the bitstream, but will be merged with the next block in scan order. This depends on the current binomial split orientation.

number

number

[0163]

[0170] The advantage of this embodiment is that it significantly reduces the amount of QTBT syntax modifications required to support asymmetric coding units.

[0164]

[0171] The embodiment disclosed with respect to Figure 18 also applies to the decoder side, where the syntax element merge_with_next_CU_flag is decoded to recover the asymmetric block.

[0165]

[0172] The implementations described herein may be embodied in, for example, a method or process, an apparatus, a software program, a data stream, or a signal. Even if discussed only in the context of a single form of implementation (e.g., discussed only as a method or device), the implementation of the discussed features may also be embodied in other forms (e.g., a program). An apparatus may be implemented in, for example, appropriate hardware, software, and firmware. A method may be implemented in, for example, an apparatus such as a processor, which generally refers to processing devices including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include, for example, communication devices such as computers, cell phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end users.

[0166]

[0173] Implementations of the various processes and features described herein may be implemented in a variety of different devices or applications, particularly, for example, devices or applications. Examples of such devices include encoders, decoders, post-processors that process output from decoders, pre-processors that provide input to encoders, video coders, video decoders, video coders, web servers, set-top boxes, laptops, personal computers, cell phones, PDAs, and other communication devices. As will be apparent, the devices may be mobile and even located in moving vehicles.

[0167]

[0174] Furthermore, methods may be implemented by instructions executed by a processor, and such instructions (and / or data values ​​produced by an embodiment) may be stored on a processor-readable medium such as, for example, an integrated circuit, a software carrier, or other storage device such as, for example, a hard disk, a compact diskette ("CD"), an optical disk (e.g., a DVD, often called a digital versatile disk or digital video disk), a random access memory ("RAM"), or a read-only memory ("ROM"). The instructions may form an application program tangibly embodied on the processor-readable medium. The instructions may be, for example, in hardware, firmware, software, or a combination thereof. The instructions may be found, for example, in an operating system, a separate application, or a combination of the two. Thus, a processor may be characterized, for example, as both a device configured to execute a process and a device that includes a processor-readable medium (e.g., a storage device) having instructions for executing a process. Furthermore, a processor-readable medium may store data values ​​produced by an embodiment in addition to or instead of instructions.

[0168]

[0175] As will be apparent to those skilled in the art, embodiments can produce a variety of signals formatted to carry information that can be stored or transmitted, for example. The information can include, for example, instructions for performing a method or data produced by one of the described embodiments. For example, a signal can be formatted to carry, as data, rules for writing or reading syntax of the described embodiments, or to carry, as data, the actual syntax values ​​written by the described embodiments. Such a signal can be formatted, for example, as an electromagnetic wave (e.g., using the radio frequency portion of the spectrum) or a baseband signal. Formatting can include, for example, encoding a data stream and modulating a carrier wave with the encoded data stream. The information carried by the signal can be, for example, analog or digital information. The signal can be transmitted over a variety of different wired or wireless links, as is known. The signal can be stored on a processor-readable medium.

[0169]

[0176] Multiple embodiments have been described. Nevertheless, it should be understood that various modifications may be made. For example, elements of different embodiments may be combined, supplemented, modified, or removed to create other embodiments. Moreover, those skilled in the art will understand that other structures and processes may be substituted for the disclosed structures and processes, such that the resulting embodiment performs at least substantially the same function(s), in at least substantially the same way(s), to achieve at least substantially the same result(s) as the disclosed embodiments. Accordingly, the above and other embodiments are contemplated by this application.

Claims

1. 1. A decoding method for decoding a block of an image, comprising: - determining a partition mode for said block within a set of partition modes, said set of partition modes including at least one partition mode that asymmetrically divides said block into at least two sub-blocks; - dividing said block into at least two sub-blocks in response to said division mode; - decoding each of said at least two sub-blocks; and determining the division mode includes: - decoding a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; - decoding a second syntax element (horAsymmetrySplitFlag, verAsymmetrySplitFlag) that specifies whether the block is split symmetrically or asymmetrically; - decoding a partition mode syntax element (vertical_asymmetric_type / horizontal_asymmetric_type) if said second syntax element specifies that said block is partitioned asymmetrically; A decoding method comprising:

2. 1. A decoding device configured to decode a block of an image, comprising: - means for determining a partition mode for said block within a set of partition modes, said set of partition modes comprising at least one partition mode that asymmetrically divides said block into at least two sub-blocks; - means for dividing said block into at least two sub-blocks in response to said division mode; means for decoding each of said at least two sub-blocks; and the means for determining the split mode comprises: - decoding a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; - decoding a second syntax element (horAsymmetrySplitFlag, verAsymmetrySplitFlag) that specifies whether the block is split symmetrically or asymmetrically, - Decode a partition mode syntax element (vertical_asymmetric_type / horizontal_asymmetric_type) if the second syntax element specifies that the block is partitioned asymmetrically a decryption device configured to:

3. Decoding the second syntax element includes: - determining a context for decoding the second syntax element, the context being a function of the size of a neighboring block relative to the size of a current block, the size being a width or a height; - performing a context-based arithmetic decoding of the second syntax element in response to the determined context; 3. The method of claim 1 or the device of claim 2, comprising:

4. 4. The method or device of claim 3, wherein the context is a function of the number of sub-blocks in a neighboring block having a size less than one-quarter of the size of the block, the size being a width or a height.

5. When the block is divided horizontally, determining the context for decoding the second syntax element comprises: - determining the number of sub-blocks in the neighboring block located to the left of said block that has a height less than ¼ of the height of said block; - if said number is equal to 0, get the first context, otherwise get the second context; 5. The method or device of claim 4, comprising:

6. When the block is divided vertically, determining the context for decoding the second syntax element comprises: - determining the number of sub-blocks in adjacent blocks located above said block that have a width less than 1 / 4 of the width of said block; - if said number is equal to 0, get the first context, otherwise get the second context; 6. The method of any one of claims 4 to 5 or the device of any one of claims 4 to 5, comprising:

7. 4. The method or device of claim 3, wherein the context is a function of the presence of neighboring blocks having a size greater than half the size of the block, the size being a width or a height.

8. Decoding the split mode syntax element includes: - determining whether the frontiers in neighboring blocks of said block are aligned with the frontiers resulting from asymmetrically dividing said block; - determining a context for decoding the split mode syntax element, the context being a function of determining whether frontiers in neighboring blocks of the block are aligned with frontiers resulting from asymmetric splitting of the block; - performing a context-based arithmetic decoding of the split mode syntax element in response to the determined context; 8. The method of claim 1 or any one of claims 3 to 7 or the device of any one of claims 2 to 7, comprising:

9. If the block is split horizontally, decoding the split mode syntax element comprises: - determining whether the frontier in the neighboring block located to the left of said block is aligned with the frontier resulting from a horizontally asymmetric division of said block; - determining a context for decoding the split mode syntax element, the context being a function of determining whether a frontier in a neighboring block located to the left of the block is aligned with a frontier resulting from a horizontally asymmetric split of the block; - performing a context-based arithmetic decoding of the split mode syntax element in response to the determined context; 8. The method of claim 1 or any one of claims 3 to 7 or the device of any one of claims 2 to 7, comprising:

10. If the block is split vertically, decoding the split mode syntax element comprises: - determining whether the frontier in a neighboring block located above said block is aligned with the frontier resulting from a vertically asymmetric division of said block; - determining a context for decoding the split mode syntax element, the context being a function of determining whether a frontier in a neighboring block located above the block is aligned with a frontier resulting from a vertical asymmetric split of the block; - performing a context-based arithmetic decoding of the split mode syntax element in response to the determined context; 8. The method of claim 1 or any one of claims 3 to 7 or the device of any one of claims 2 to 7, comprising:

11. Decoding the split mode syntax element includes: - determining a context for decoding the split mode syntax element, the context being a function of a size of a first neighboring block of the block relative to a size of a second neighboring block of the block, the size being a width or a height; - performing a context-based arithmetic decoding of the split mode syntax element in response to the determined context; 8. The method of claim 1 or any one of claims 3 to 7 or the device of any one of claims 2 to 7, comprising:

12. 1. A coding method for encoding a block of an image, comprising the steps of: - determining a partition mode for said block within a set of partition modes, said set of partition modes including at least one partition mode that asymmetrically divides said block into at least two sub-blocks; - dividing said block into at least two sub-blocks in response to said division mode; - encoding each of said at least two sub-blocks; and determining the division mode includes: - determining and encoding a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; - determining and encoding a second syntax element (horAsymmetrySplitFlag, verAsymmetrySplitFlag) that specifies whether the block is split symmetrically or asymmetrically; - determining and encoding a partition mode syntax element (vertical_asymmetric_type / horizontal_asymmetric_type) if the second syntax element specifies that the block is partitioned asymmetrically; Including, how to code.

13. 1. A coding device configured to encode a block of an image, comprising: - means for determining a partition mode for said block within a set of partition modes, said set of partition modes comprising at least one partition mode that asymmetrically divides said block into at least two sub-blocks; - means for dividing said block into at least two sub-blocks in response to said division mode; means for encoding each of said at least two sub-blocks; and the means for determining a split mode includes: - determining and encoding a first syntax element (btSplitOrientation) that specifies whether the block is split vertically or horizontally; - determining and encoding a second syntax element (horAsymmetrySplitFlag, verAsymmetrySplitFlag) that specifies whether the block is split symmetrically or asymmetrically; - if the second syntax element specifies that the block is split asymmetrically, determine and encode the split mode syntax element (vertical_asymmetric_type / horizontal_asymmetric_type) 1. A coding device configured to:

14. The encoding of the second syntax element comprises: - determining a context for the encoding of said second syntax element, said context being a function of the size of a neighboring block relative to the size of the current block, said size being a width or a height; - performing a context-based arithmetic coding of said second syntax element in response to said determined context; 14. The method of claim 12 or the device of claim 13, comprising:

15. 15. The method or device of claim 14, wherein the context is a function of the number of sub-blocks in a neighboring block having a size less than one-quarter of the size of the block, the size being a width or a height.

16. When the block is divided horizontally, determining the context for encoding the second syntax element comprises: - determining the number of sub-blocks in the neighboring block located to the left of said block that has a height less than ¼ of the height of said block; - if said number is equal to 0, get the first context, otherwise get the second context; 16. The method or device of claim 15, comprising:

17. When the block is divided vertically, determining the context for encoding the second syntax element comprises: - determining the number of sub-blocks in adjacent blocks located above said block that have a width less than 1 / 4 of the width of said block; - if said number is equal to 0, get the first context, otherwise get the second context; 17. The method of any one of claims 15 to 16 or the device of any one of claims 15 to 16, comprising:

18. 15. A method or device according to claim 14, wherein the context is a function of the presence of neighboring blocks having a size greater than half the size of the block, the size being a width or a height.

19. The encoding of the split mode syntax element comprises: - determining whether the frontiers in neighboring blocks of said block are aligned with the frontiers resulting from asymmetrically dividing said block; - determining a context for encoding the partition mode syntax element, the context being a function of determining whether frontiers in neighboring blocks of the block are aligned with frontiers resulting from asymmetric partitioning of the block; - performing a context-based arithmetic coding of said split mode syntax element in response to said determined context; 19. The method of any one of claims 12 or 14 to 18 or the device of any one of claims 13 to 18, comprising:

20. If the block is partitioned horizontally, the encoding of the partition mode syntax element is: - determining whether the frontier in the neighboring block located to the left of said block is aligned with the frontier resulting from a horizontally asymmetric division of said block; - determining a context for encoding the partition mode syntax element, the context being a function of determining whether a frontier in a neighboring block located to the left of the block is aligned with a frontier resulting from a horizontally asymmetric partition of the block; - performing a context-based arithmetic coding of said split mode syntax element in response to said determined context; 19. The method of any one of claims 12 or 14 to 18 or the device of any one of claims 13 to 18, comprising:

21. If the block is partitioned vertically, the encoding of the partition mode syntax element is: - determining whether the frontier in a neighboring block located above said block is aligned with the frontier resulting from a vertically asymmetric division of said block; - determining a context for encoding the partition mode syntax element, the context being a function of determining whether a frontier in a neighboring block located above the block is aligned with a frontier resulting from a vertical asymmetric partition of the block; - performing a context-based arithmetic coding of said split mode syntax element in response to said determined context; 19. The method of any one of claims 12 or 14 to 18 or the device of any one of claims 13 to 18, comprising:

22. The encoding of the split mode syntax element comprises: - determining a context for encoding the partition mode syntax element, the context being a function of a size of a first neighboring block of the block relative to a size of a second neighboring block of the block, the size being a width or a height; - performing a context-based arithmetic coding of said split mode syntax element in response to said determined context; 19. The method of any one of claims 12 or 14 to 18 or the device of any one of claims 13 to 18, comprising:

Images